Remote Booting Using a Wireless Network Card?

Eboneye asks: "I have been assigned to a project to figure out how to make a diskless portable workstation (laptop) boot through a wireless connection. The idea is to have a stateless client that stores no local data (for security purposes). The only totally network boot stuff I have found uses PXE extensions. I have seen nothing like this in a PCMCIA card, much less a -wireless- PCMCIA card. For the proof of concept, we'll boot from a read only device, but of course during the setup phase use media to create a boot image on a boot server. I am currently looking at a couple different products that will provide a booting service. Ultimately, the goal is a to have a wireless tablet that can use different PCMCIA wireless adapters to connect to different LANs. Because of the specialized concerns of tablet PCs the solution has to be Windows compatible (sorry, Linux). Has anyone seen or worked on remote boot through wireless? Any experiences, gotchas, or suggestions for ways to solve this are welcome."

Comments

For security.

[fogof]

Wireless security is really bad. Ok. By wireless I mean 802.11b (aka WiFi).
You should maybe think of 802.11a . Which is a wireless standard that is more buisness oriented (High bandwidth) hell of a lot better encription.

WiFi uses WEP (wired equivilant protocol(?)) to encrypt every packet that is send out. WEP, is know to have many weaknesses. There haev been many document exploits (airsnort is one of them). And any script kiddy can use it without using the keyboard.

Hence. I would recomend 802.11a and not WiFi

Re:For security.

[phoenix_rizzen]

For a business that may already have some 802.11b gear, it'd be best to wait for 802.11g. It uses most of the algorithms from 802.11a for bandwidth and encryption, but it is compatible with 802.11b, making their existing investment in wireless technology useful.

802.11a also doesn't have the greatest range, especially indoors. 802.11b and 802.11g have much better range (and 802.11g has the same throughput as 802.11a).

Re:For security.

[Funsize]

WEP is an optional part of 802.11.

That's both 802.11a and 802.11b...BOTH can use WEP. To my knowledge 802.11a does not have any additional security measures over 802.11b in the spec. However, many cards being released implement an additional standard called 802.1x, which is better than WEP, but has also been criticised as being insecure. Also some cards (actually many cards these days) have been released with vendor-specific additions to WEP, such as longer keys...any card that claims 128- or 156-bit encryption is one of these. This doesn't really help though, since the flaw in WEP that causes it to be insecure means that doubling the encryption key length only DOUBLES the time that it takes to crack. So if it takes 1 hr to crack WEP at 64 bits, it only takes 2 hrs. to crack WEP at 128 bits.

This is in contrast to secure encrytion where a brute force attack doubles with every additional bit in the key, i.e. 1 hr at 64 bits -> 18446744073709551616 hrs. at 128 bits.

Also users should note that in WEP the first 24 bits of the key ARE NOT SECRET. So a 64-bit WEP key is really only 40 bit encrytion (but they wont tell you that on the box of your network card!)

Don't bother

[duffbeer703]

You obviously haven't put enough thought into this.

A scheme like this, where you have to wait for a boot image to traverse a network, kinda defeats the purpose of tablet pcs.

If you are doing this for security, use applications that utilize strong encyrption. Playing games like this at the OS level is not the appropriate place to do this.

Other read-only options

[Ratbert42]

There are other read-only options. A boot floppy (not likely today, especially in a tablet), a bootable image on CD-R (hard to create, apparently can't work with NT/2000/XP but can work with 95/98/Me and of course, Linux/BSD), a hard drive rigged to be read-only, or a flash/rom memory disk.

Re:Other read-only options

[Anonymous Coward]

Bootable CDs like ERD Commander work well, and Windows PE will boot from read-only media.

encrypt the drive

[linuxbert]

There are several products out there that will encrypt the contents of the entire hdd, and require authentication to boot and decrypt the device.
if the unit goes missing, all the person who finds it can do is replace the drive, cause they woint get squat off the secured one.

I beleive 1 or 2 of these products are fips 140 certified

Re:encrypt the drive

[brightertimes]

Yes, you may find bestcrypt very good for this job.

It's available at www.jetico.com and you can make a file that it will load that will make a "virtual drive" *and* it is available for linux and windows. They also have server options too.

One of the things I found which was handy is that you can have your regular password on the encryption file and then a "secret password" too.

This is handy lets say for some reason you got ordered at gun point to reveal the password. Great, reveal it. Give them the original password and then can see all the data put in that bit. But you got the secret password and it can have lots of other data in it... :).

Infact the goodthing is you cannot tell if there is a secret container held in the file.

Encryption such as blowfish, twofish, gost and more equal some very good encryption levels. Also, the encryption code is "open" so you can do your own security audit if you need :)

Hope that helps, I don't work for them. But I use their products, Check it out.

let me get this straight...

[kevin lyda]

you want to boot off a wireless card on a windows portable computer for security reasons?

well, i suppose you didn't say you wanted good/high security. "security reasons" could mean "we want crap, swiss cheese-like insecurity."

not sure of an answer there, but good luck with that.

Re:let me get this straight...

[Anonymous Coward]

if i'd have mod points you'd get a "-1 failed attemp to karma whore"

Re:let me get this straight...

[kevin lyda]

oh come on. it's like he's asking for a lighting solution with an even output over the visible spectrum for his clear glass fountain that uses water with a high concentration of bleach "for color reasons."

could you honestly call a system secure that contains wireless network nodes running windows? and you have to answer that question without hallucinagenic drugs or resorting to philosophic ponderings on what words/time/reality mean.

Why make it bootable?

[sQuEeDeN]

It seems like it would be waaaaay easier to do thin clients, like our friends in Largo, Florida. Remote booting brings a host of problems:

First: security. Any authentication to get the boot image would, natrually, have to happen before the image was downloaded, so the Client would have to be able to haddle any encryption protocols before anything useful even happened. Unless you have a powerful system operating pre-boot, that is gonna be really insecure, especially over wireless, comprende? Imagine if the boot image was intercepted? I can't think of how that would be good.


Also, the simple fact that consolidation is typically more economic. One Big Server (could be running linux with crossover[whoring]) is typically easier to maintain than a remo.te, full-fledged laptop. So, read the story on Largo (about the thin clients, rather than the Linux bit) and think about it--decide if you really, really have to make it bootable--be sure you can't or are unwilling to go thin.

Serious security issues with 802.11b

[TheSHAD0W]

I strongly recommend you do NOT attempt this using the 802.11b protocol.

Let's assume you set up your wireless network PROPERLY; it has a gateway machine which restricts communications within your internal network, with that gateway being the only machine accessible to your wireless network. Your intent would be for your wireless machines to have nothing accessible, except to that gateway. Your remote machines would use an encrypted tunnel to log onto that gateway.

By remote-booting, you've destroyed that paradigm. A remotely-booting client would have no resources able to establish that encrypted tunnel, so you would not be able to boot through that gateway. Okay, fine, so let's say you put the boot image on the gateway machine outside the tunnel, or on a second server provided just for that purpose.

Now you have a brand new security hole... First off, an attacker doesn't need any security codes to grab a copy of your boot image; and that boot image, in order to establish your encrypted tunnels, would give the attacker, if not direct access to the gateway, at least valuable information narrowing down your security window. Having individual passwords users have to enter to log on might help things, but doesn't close the hole...

Since the link the booting PC would by definition be unencrypted, an attacker could spoof the wireless gateway for the period of time during when a wireless machine was booting, substituting a modified copy of the boot image. The result would be an insecure client, in which, if a password is entered, it could be forwarded to the attacker; or that machine might act as its own gateway, from the attacker through the insecure machine onto your network.

Re:Serious security issues with 802.11b

[addaon]

Precisely. You need some physical media for the encryption key, unless you're doing this entirely unencrypted, a decidedly bad idea. The way I would do this is to stick a 802.11 card, permanently, in each tablet, and issue people a usbkey storage device (www.usbkeydrive.com, for instance... pricier ones available). You could either give this to each employee, or have them check them out the same way they would have checked out a pc card under your plan. These keys are bootable in most machines (the advantage over using a pc card hard drive, which may or may not be bootable depending on your hardware); what you want to do is put on each a small bootable OS, the information necessary to form your VPN or however you're dealing with security, and nothing else. (At this point, you'll wish you could use linux, as it will require a smaller key, and be cheaper. But you'll survive with windows). Of course, there are still problems with this; you're not truly remote booting, just using a read-only boot disk. But it may be sufficient.

The next step up in complexity, as well as power, is to again use a usbkey to boot, but boot into linux. Have it boot from the read-only keychain, use the (unique) information on each key to establish the connection, etc, and then start X-Windows and rdesktop (linux remote desktop client), connecting to a remote windows server. It would be quite easy to secure the tablet so that the linux distribution is secure, and again you have a unique key to secure the connection. From the users point of view, they're working on a local windows machine, although from your point of view they're remotely logged on to another box.

These are just the first two ideas that came to mind. As the parent said, though, you need some kind of local storage for encrypted booting. I highly recommend a usbkey from one brand or another, as they're relatively cheap, absurdly robust, and quite convenient. And once you're allowing even a bit of storage, make it a useful amount, and boot locally off a secured disk, rather than trying to get the hardware to do something it's not supposed to do. Remote booting, keep in mind, just uses some ROM code to boot the computer and then moves control elsewhere. I'm pretty sure you won't find a system ROM or an 802.11 ROM that does what you need; instead, you're going to have to attach a boot ROM of some kind, and a usb key is about as good as it gets.

Oh, one final point, to make this make sense. Most of the usb keys have a read-only switch that can be latched, which makes them appear as read-only mass storage devices to the OS. Once you write the key, you can physically remove the switch (I've done this to several usb keys) to make it quite inconvenient to write to them again. It is possible to write to them either by opening them up and reconnecting the switch, or by writing a custom driver which ignores that the device is read-only (it turns out that, even in read-only mode, the keys I've worked with do honor writes), but neither of these methods is very convenient. It depends just how much security you need.

Re:Serious security issues with 802.11b

[Anonymous Coward]

You say that the attacker could "substitute a modified copy of the boot image" by spoofing the -- "by definition unencrypted" -- link the booting PC uses. But this link is NOT by definition unencrypted, because in addition to a MAC address, a wireless 802.11b card could very well have an internal password it uses to authenticate itself whilst supporting a crypto protocol riding on top of 802.11. The fact that such a crypto protocol is not natively supported in hardware makes this link only de facto unencrypted -- not by definition.

Re:Serious security issues with 802.11b

[TheSHAD0W]

You're right, I'm sorry... I should not have said the system was unencrypted, but that the system had unacceptably weak encryption.

But you say it yourself -- a higher level crypto protocol wouldn't be supported in hardware. It also can't be supported in software, because during boot there IS no software loaded. (Unless your system's BIOS supports such things, which I doubt.) So therefore, at boot time, this operation would be unacceptably insecure.

Consider your security model

[Piquan]

I have been assigned to a project to figure out how to make a diskless portable workstation (laptop) boot through a wireless connection. The idea is to have a stateless client that stores no local data (for security purposes).

What's the model here? Does somebody walk into a secure facility, pick one up, use it to do some eyes-only investigation, and return it when they leave? What are you trying to secure against? Tampering, or somebody walking off with the data? The solution often depends on the threat model.

If your threat model is to prevent against tampering, then you may be better off exploring other options. For example, have you considered read-only media? How about having the tablets re-ghosted when they're returned, before they're re-issued? That can be done in an automated fashion without a whole lot of hassle-- primarily through the PXE extensions you've already investigated, combined with hardware at the docking stations.

If you're trying to keep people from walking off with data, then diskless isn't going to be the way to go. A lot of data gets left in RAM after power is removed. (See Gutman, P., "Secure Deletion of Data from Magnetic and Solid-State Memory," Proceedings of the Sixth USENIX Security Symposium, July 1996, or do a Google search for "RAM remanence".) You may have seen some computers-- notably the old Macs-- that would power up with their last display still on the screen!

Also, if you have a totally stateless box driven by a wireless LAN, then some shmuck can easily sit in a van a half-mile away with his laptop and find out everything you're wanting to keep private. Stateless booting means that your encryption has to be bootstrapped! A lot of naive ways of doing this exist, such as sending a root filesystem with encryption keys already on it. Some of these open themselves up to passive attacks. Even more sophisticated techniques, such as DH, still are totally vulnerable to active attacks (like the guy in the van pretending to be one of your tablets asking to be bootstrapped).

I seriously suggest you rethink your security model. The Windows compatibility is a big problem. It keeps some of the latest crypto filesystems, etc. from becoming part of the solution. Something based on VNC, Citrix, Windows Terminal Server, etc. may be helpful: make sure the computer doesn't know more than it's telling the visitor. Also, these small programs will tend to re-use the same part of memory repeatedly, making RAM remanence slightly less of an issue.

Wireless? Security?

[Anonymous Coward]

You say you're going with this setup for security reasons. Wireless stuff isn't known for its security. Booting issues aside (I have yet to see a 802.11b card that will do netbooting, but it might be possible with other cards/protocols), do you want you data to be transmitted wirelessly for anyone with an antenna to pick up? I assume you're going to encrypt it before sending it over the wireless connection. If you're going to encrypt it anyways, why go to the trouble and added complexity of building a custom remote-booting, diskless, wireless system? A laptop with a 802.11b card and a shitload of encryption software would be about as secure, and a hundred times simpler.

Remote boot & Windows don't mix

[_LORAX_]

Windows 98 first edition was the last version of Windows that was able to "remote boot" off of a server without a local harddrive and even that was amazingly difficult to setup. The only way you will get "Windows" is through terminal server.

Good news is that linux does support a vast array of windows applications and "Work alike" alternatives.

Re:Remote boot & Windows don't mix

[Anonymous Coward]

It could be done with an abstraction driver which hides the network card from the OS and uses it exclusively to provide a virtual network card and a virtual harddisk via something like "network block device". Last time I checked there was at least one commercial product which worked that way and supported modern Windows versions.

You need a CardBus card, not PCCard/PCMCIA

[AdamBa]

I actually worked on remote install of Windows 2000 when I was at Microsoft. Remote install meant you only booted setup off the network, then installed to a local hard drive. But it's not a huge step from there to remote boot, although Windows 2000 doesn't support that (don't know about XP and future products).

In terms of PXE hardware, you probably want a CardBus card, not a PCCard (which is what PCMCIA was renamed to). PCCard is 16 bit data path and cards are identified by a 64-character text string or something usly like that...PCCard is 32 bit data path and devices appear like PCI devices and are identified like PCI devices (I forget the details, but it's something like a 16-bit manufacturer ID and a 16-bit ID for that particular type of card).

Back in early 2000 or so, we had a PXE-compliant CardBus network adapter (not wireless, but that shouldn't matter to the software level) in our lab that would do remote install of Windows 2000. In fact we had to make zero changes to the code, it worked like any PXE-compliant PCI network card. So if you could find a PXE-compliant CardBus wireless network adapter, you should be able to do a remote install of Windows 2000/XP on it today. Of course this requires setting up a Windows server to hand out the images, etc. which there is undoubtedly a Microsoft white paper on somewhere.

- adam

Try linux bios...

[tchuladdiass]

Assuming your tablet pc's have a supported chipset, you can replace the system bios using the "linux bios" project. This replaces the system bios with a modified linux boot image. It can in turn chain-load either another linux distribution, or load another OS such as win2k. The advantage of this is that you can embed a public key in the bios image that would then be used to authenticate a signed boot image that would be downloaded to ram via a utility under linux. This will fix man-in-the-middle attacks upon bootup. And, you can configure the boot image to do whatever you need.

Perhaps you should consider rdesktop / citrix ...

[Craig Ringer]

since nt4 and cousins (eg XP tablet ed) are not network-boot friendly unless you can throw a REALLY large amount of money at Microsoft.

citrix connections can be encrypted, prevent the user from storing local data, are vaguely efficient, come up really fast, and have the facility for proper user authentication that you couldn't really do with network booting.

However, I presume you have a reason not to use citrix/termserv, most likely since you'll need "tablet pc" OS features or similar that won't work over citrix.

This being the case, I'd put a preliminary comment at "no can do" with the basic OS and tools. Microsoft might well have the "XP remote boot tools" hidden away somewhere - good luck finding them though. I'd be budgeting for tens/hundreds of thousands of dollars in customization by MS or a big sol'n provider with an inside channel to MS.

LTSP already support wireless remote bootinging

[prpplague]

http://www.ltsp.org/instructions-3.0.html

I have had a Linux tablet PC for two years.

[SHEENmaster]

It works fine; 0 complaints from me.

Considering how much space winshit takes up, and the innability for specialised projects to modify it you are faced with a serious challenge.

If I had to do it, I would install Linux on the tablet pc with an svgalib client for VNC or terminal server. It will enforce "on premisis" use. VNC supports SSL if you need security.

Make sure to use every available security option and see if you can get modified 802.11a cards "shifted" to another frequency. It won't be perfect, but it will be more effective than WEP.

Two answers

[Anonymous Coward]

There are two answers, on two levels.

First of all, it might be possible. If you can convince your tablet PCs to configure the wireless cards, you might be able to get DHCP/TFTP going. PXE might not be enough, especially if you have multiple SSIDs in some areas (which you'd almost have to have to get complete coverage of a large area). If your tablet PCs have an EFI BIOS, or if using an EFI boot disk isn't out of the question, you might have an easier time of it.

Also, if you can't find a PXE-compliant wireless card, you'll probably have to write drivers for EFI or for some minimal bootstrap OS (like DOS) that you'd load on the local hard drive.

On the second level, the spec you've chosen makes me question whether you know what you're doing. Saying "no local data for security" isn't a bad idea, but I wonder what rigor you need that won't allow local bootstrap. Especially when that same rigor falls down completely by insisting on netbooting over an insecure wireless link. It's no accident that you're finding it difficult to find PXE-compliant wireless cards; there's no demand because wireless isn't secure enough to trust for booting over.

I suspect that you've got a set of very workable goals, but you've written an impossible spec to meet those goals. Sit down and think about it again, or possibly hire someone who's done what you're doing before.

Diskless Boot for Windows 2K/XP/XPEmbedded

[BXPMan]

We found a product called BXP that allows us to boot Windows W2K/XP using PXE. The technique used differs from how Linux remote boots. Instead of downloading an image it emulates a local physical disk drive over the wire by I/O redirection during BIOS & post-OS startup - then block-oriented SCSI driver continues drive emulation. Effect is it only loads what is needed on demand. This eliminates the huge download and RAM requirements if working with the whole image. Boot times on 100Mbs are comparable to disk based system 1:30sec - boot read burst requires 20-60Meg of data depending on drivers & services and O/S- even supports things like multicast fastboot of multiple machines simultaneously. We use a small application that modifies the PXE database and can boot Windows 2000/XP or Linux from network selectively. We are in a unique situation - technical university where we need to often switch O/S and be able to rapidly reconfigure many 100's of PCs - network boot effectively provides this. Mode called "WriteProtected" allows a fully unrestricted desktop that reverts to original on next boot - this way we can always guarantee that the machine will boot on next power on. Regards wireless - I too would like to see a wireless CardBus 802.11a PXE option. Most of the cost and inflexibilty in our systems is in the wiring. As many mentioned PXE support on CardBus or PCMCIA is non-existent. Vendor says they will have this support in future when wireless vendors build-in PXE support. My understanding is that in a unreleased secure version they incorporate firmware that encrypts the protocol from the BIOS stage through O/S bootup. Then switch to IPSec mechanisms built into Windows O/S.