Bootstrapping secure communications

Hi Glyn,

Glyn Davies wrote:

>>> Do a PXE boot and once up and running use a smartcard or other physical
>>> dev to auth the connection to the net?
>> 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  :> )
> 
> Yes.. so your wired nodes are 'secure'

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

> Your wireless nodes are not in a secure environment?

No.  RF doesn't like boundaries.

> Is it possible to run to run them via a VPN onto the secure het, after
> which normal PXE can happen?

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

> I'm not sure you can PXE with wireless 802..etc - never heard of it,
> but fine over a bridged network.
> 
>>> 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?
>> 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".
> 
> 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?

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"?)

D Yuniskis <not.going.to.be@seen.com> 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...)

http://en.wikipedia.org/wiki/GPXE

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

On Fri, 02 Jul 2010 12:43:52 -0700, D Yuniskis wrote:

> Hi Boudewijn,
> 
> Boudewijn Dijkstra wrote:
>> Op Fri, 02 Jul 2010 05:19:33 +0200 schreef D Yuniskis
>> <not.going.to.be@seen.com>:
>>> I'm deploying a prototype of a distributed system to benchmark some
>>> algorithms before committing to final hardware.
>>>
>>> I have
>> 
>> "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.
> 
> 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...)

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.

Hi Joe,

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.

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

On Tue, 06 Jul 2010 09:54:32 -0700, D Yuniskis wrote:

> Hi Joe,
> 
> 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
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).

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.

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.

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.

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