Bootstrapping secure communications

PXE, and BOOTP / DHCP, is pretty promiscuous. The machine being booted up is not selective to the boot image sent to it nor to the server sending the image.

There are two kinds of attack to consider:

a) An unauthorized client attempts to get an authorized image, b) An unauthorized server attempts to feed a fake image.

The MAC spoofing applies to a).

The problem is much the same as in HTTPS. You may need to verify both the server and the client. To do this, you need to install in a client both an individual client key and the common server key, so the basic PXE boot code is not sufficient.

The keys have to be exchanged in a secure way, either with asymmetric encryption or challenge-response exchange with symmetric encryption.

Just my .02 EUR.

--

Tauno Voipio
tauno voipio (at) iki fi

The good, old, chicken and egg prob

Are the devices physically secure? If not the there is always a risk

Do a PXE boot and once up and running use a smartcard or other physical dev to auth the connection to the net?

What is your secure network anyway? Do you have 802.1x or anything?

It's a prototype anyway, so how extreme are the lengths you need to go to?

Glyn

Op Fri, 02 Jul 2010 05:19:33 +0200 schreef D Yuniskis :

"I have" is the keyword here. You have control over the network. Physical control for wired communications is easy; for any wireless-only boxen you could put them in a shielded room.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

I've gotta ask, is this a theoretical problem or are you really concerned with someone hacking your prototype?

What kind of a prototype environment would you have that you'd be worried about spoofed MAC addresses?

As others have pointed out, physical security should be the first goal.

Assuming you really are concerned with someone hacking your prototype network, wouldn't it be enough just to

*detect* a rouge PXE server? That should be easy enough.

Likewise, it should be possible to detect that your PXE server has downloaded and validated one and only one good image to each MAC address. With the existence of a spoofed MAC, there should ultimately be more than one.

Finally, you could have a honeypot node. It could be running an app that would look like a node wanting to PXE boot, then validating the boot code it gets and sounding an alarm if it's suspect. In fact, the PXE server should be able to run a process that detects other suspicious PXE servers. You could even bait them with an inert boot and see who responds...

Exactly.

I.e., I can do exactly what I want *iff* I can control the code that (always) executes on the node. If I open the door for "anything" to creep in, then there is no (?) way to make any guarantees thereafter.

In my understanding of PXE, MAC spoofing only applies to a. But, relying on MAC as an authentication mechanism for *anything* leaves you open to spoofing. E.g., if you wrote a PXE replacement that "hard coded" the MAC of the server from which it expects to retrieve it's boot image, you're just as vulnerable.

It's like delivering keys in sealed envelopes -- but, handing them to some guy you met on the street immediately outside their intended destination (i.e., *he* can peek inside the envelope and thwart all your security to date)

Yes. The boot code does this. The problem lies in my trying to treat a PXE loaded image in the same way as a "locally resident" image. I.e., trying to get something for nothing :-/

The fact that there is *nothing* that I can do in this environment to keep *any* secrets. :<

No, they aren't secure but the "local" threat isn't a problem. I am mainly concerned about the nodes that operate wirelessly as it would be easy for an outsider (literally) to inject traffic at IPL that would *invisibly* compromise a node and/or the system.

Yeah, but anything that can intercept that PXE boot request and substitute some *other* executable image then has unhindered access to that physical/secure device (unless you rely on an organic memory module being nearby to participate in the process :> )

The prototype will be deployed in a production environment for alpha and beta testing. Thereafter, it will be used to gather metrics on the various algorithms deployed within it. As well as to see what sort of attacks are waged against it (including "red team" activities) and how it copes in those scenarios.

I figure it will sit in place for the better part of a year before production hardware is committed. Thereafter, it may survive another year or two as a "well instrumented test bed".

The wireless stuff is the problem. I'd have to get the clients in the same faraday cage as the antenna (not going to happen :< ).

I think I just have to abandon the idea of using a stock PXE boot loader and write something from scratch. Maybe steal a few "CMOS" locations for the "secret". Or, add a CF device as a temporary measure (I really don't want to spend much effort on a throw-away design...)

I worry about theory only to the extent that it affects

*practice*. :>

The fact that all *runtime* communications are encrypted should suggest that there is value to the information being exchanged between nodes. :> And, there is value in knowing that the information is unalterable.

I'm not worried about the *wired* nodes. There, the only threat is "insiders". Aside from a soon-to-be-fired employee, the insiders have more to lose than to *gain* (when offset with "risk")

The wireless nodes are the problem areas.

How do you do that -- since the nodes have no local store? You can't rely on the server being "in earshot" of the rogue server. Any other node can be compromised, reset and returned to operation without anyone being the wiser for it...

An image needs to be downloaded each time the device is reset/rebooted. Do you propose to have a side-channel whereby the device informs the server of each of these reboots, etc.? Otherwise, how does the PXE server know that this *second* PXE boot request is just as legitimate as the *first*?

Again, that only applies to the portions of the network that this server can *see*. Unless you put the entire thing in a Faraday box (which eliminates the need for worrying about bogus servers), there is no way to prevent "node X" from seeing a rogue PXE server that the *real* PXE server would be aware of.

If everything followed the rules, there'd be no need for worrying about the "CAN'T HAPPEN"s :-/

Yes.. so your wired nodes are 'secure' Your wireless nodes are not in a secure environment? Is it possible to run to run them via a VPN onto the secure het, after which normal PXE can happen? I'm not sure you can PXE with wireless 802..etc - never heard of it, but fine over a bridged network.

You didn't answer what kind of secure network you have - if you can use commodity VPN to bridge these 'wireless' nodes, then you should be sorted - and still able to PXE, no?

Glyn

Yes -- assuming I can trust the existing nodes and protect against physical wiretap, etc.

No. RF doesn't like boundaries.

I'd need something (executable) *at* the nodes before PXE, right?

Currently, everything is SSL. But, that has proven to be clumsy (some of the original design criteria proved unnecessary). New thinking is to strip all that out and move the encryption to a lower layer in the stack -- get it out of the application layer to clean up the application itself. Maybe move to IPv6 at the same time (more "future safe"?)

In the linked video they mention https, but maybe that never happened. iSCSI may have what you need.

If your client boxes will boot from USB put a small boot and preloader on the USB stick. Have this use a SSL connection to a known valid host to download a trusted kernel image. You can have the boot host validate the client certs. Have the client validate a digital sig of the kernel. The level of complexity just depends on how paranoid you think you need to be for a test setup.

I had to do what you are attempting years ago and a simple net boot wont work for all cases. The wireless nodes throw in more problems.

--
Joe Chisolm
Marble Falls, Tx.

Yes. Though I was advocating burying it inside the device(s) on a CF device. Less likely to be removed and/or "swapped" with some other node's.

And, I guess I could even burn the private key into the CF device (instead of trying to shoehorn it into the CMOS). It would just change a few bytes... (though it would make it painfully obvious *where* the keys were stored in the devices!)

I recently did a small in house project with a SSD. For a given size I found the CF a lot more expensive than USB or a SD card. I went with one of those SD to ATA converters. For USB get one of those extender cables that take the mother board USB connectors out the back of the case. Something like this:

B00004Z5NH

Take it apart and use the cable internally. This will allow you to put the USB stick inside the case. A little piece of double sided tape will mount it to the side of the case.

Create the partition smaller than the full device and use the last sector for the key (or something similar).

But if you do not have physical security of the node all bets are off anyway. Second, if a hacker gets into the box you have a much bigger security problem than having a key stored on the device. You could obfuscate the sensitive info by hashing along with the mac address. Analyze the security threats - you may be starting down the rabbit hole when you dont need to.

--
Joe Chisolm
Marble Falls, Tx.

I'm not worried about that for prototype. Have lots of 4G CF cards gathering dust... :> More than big enough for a "secure boot loader".

Ah, good idea! Means I can add the key *after* burning N copies of the image.

Can't be worried about that. Security from "knowledgeable insiders" is too hard to come by. E.g., even a "clerk" could conspire with a savvy *outsider* to log the cleartext of a session while the outsider logs the ciphertext, etc. Or, install a "tap" on any of the nodes, etc.

I don't have to worry about "outsiders" getting their hands on any devices directly.

Biggest concern is someone sitting "within earshot" and listening and probing with impunity. Semiresidential area -- not many metal buildings. So, someone could hide in plain sight and leisurely probe the system over a period of days, weeks, months. Want to make it unprofitable (time-wise) to do so and hope he/she opts to go for the obvious "buy someone off" approach... :>

I think writing a secure bootloader and putting it inside each box (even the wired nodes... why not?) gets around most of the issues without burdening the implementation unduly.

Put the secure loader in the wired nodes also, keep all nodes the same.

With the secure boot loader and SSL you can make it unprofitable for the prober. But "profitable" depends on the value of the data you are shipping on the secure channel. I did a project where we were shipping data to a moving wireless device. Usually had less than 1 minute of communications, but the wireless device would "see" a base station every

5 minutes or so. SSL was a problem so we encrypted the data and sent it in "chunks". We had a complicated method where we would update the encryption keys each day. The idea was *when* someone broke the wireless encryption the resulting data was still useless without a *lot* of cpu cycles in post processing. By that time the value of the data was zero.

--
Joe Chisolm
Marble Falls, Tx.

Agreed. Exceptions end up becoming *holes*.

Of course! Weakest link is always personnel -- either failing to follow "established procedures" *or* falling prey to bribery.

In the production hardware, we can arrange for per-node secrets to be updated ("in flash") as part of the normal operations. (with suitable key exchange procedure).

In our case, data doesn't get stale very quickly so bigger keys are indicated. :< Some of the protocols had to be reworked as they were leaky -- to easy to *infer* the content of particular traffic.

(my head hurts :> )