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

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

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.

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

On Fri, 02 Jul 2010 12:40:46 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>Hi Glyn,
>
>Glyn Davies wrote:
>> D Yuniskis <not.going.to.be@seen.com> wrote:
>>

<Snip>

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

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

Glyn

Hi Jim,

Jim Stewart wrote:
> D Yuniskis wrote:
>>
>> I'm deploying a prototype of a distributed system to
>> benchmark some algorithms before committing to final
>> hardware.
>>
>> I have a large supply of 1GHz, 1GB diskless workstations
>> that I'll use (headless) as they are freely available,
>> small, reasonably (ha!) low power, etc. Almost everything
>> is written in portable languages so the fact that this
>> is x86 doesn't impact my codebase.
>>
>> For the prototype system, I'll deploy 30 of these.
>> Most will be 100BaseTX ethernet. Some will be 802.11g
>> or n. A single server hosts images.
>>
>> Since these are COTS boxes (and *diskless*), they are
>> indistinguishable from each other besides MAC. And,
>> MAC can be spoofed :-/
>>
>> I was originally thinking of PXE booting each box. Then,
>> letting that bootstrap bring up the *secure* network for
>> the rest of IPL (key exchange, etc.).
>>
>> But, I don't see any way that I can do this *without*
>> controlling the loading of the initial (PXE) image!
>> I.e., an attacker could intercept the PXE boot
>> request and force arbitrary code to be executed.
>> So, even if I added some local key storage, that
>> code could freely examine the key, reset the
>> processor and let the *next* PXE boot request go
>> through "as normal".
> 
>> It seems like I *must* make the PXE sequence secure
>> if I want to have any hope of the rest of the process
>> being secure (?). I.e., boot locally (add some sort
>> of medium) and implement my own form of PXE boot. :<
> 
> I've gotta ask, is this a theoretical problem or are
> you really concerned with someone hacking your prototype?

I worry about theory only to the extent that it affects
*practice*.  :>

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

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.

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

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.

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

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

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

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*?

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

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