From: D Yuniskis on
Hi Joe,

Joe Chisolm wrote:
> On Tue, 06 Jul 2010 09:54:32 -0700, D Yuniskis wrote:
>
>> Joe Chisolm wrote:
>>> On Fri, 02 Jul 2010 12:43:52 -0700, D Yuniskis wrote:
>>>> 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...)
>>> 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.
>> 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.
>
> 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

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".

> 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:
> http://www.amazon.com/Belkin-Dual-Port-Motherboard-Adapter-10-Pin/dp/
> 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.
>
>> 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!)
>
> Create the partition smaller than the full device and use the last sector
> for the key (or something similar).

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

> But if you do not have physical security of the node all bets are off

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.

> 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.

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.
From: Joe Chisolm on
On Tue, 06 Jul 2010 11:19:45 -0700, D Yuniskis wrote:

<snip>

>
> 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.
From: D Yuniskis on
Hi Joe,

Joe Chisolm wrote:
> On Tue, 06 Jul 2010 11:19:45 -0700, D Yuniskis wrote:
>
>> 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.

Agreed. Exceptions end up becoming *holes*.

> 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

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

> 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.

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 :> )