Prev: CY7C68013A:ezusb.sys driver receives a trash data
Next: STM32 and USB examples
From: D Yuniskis on 4 Jul 2010 23:12
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"?)
From: Warren Block on 5 Jul 2010 19:08
D Yuniskis <not.going.to.be(a)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.
From: Joe Chisolm on 6 Jul 2010 02:30
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(a)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.
From: D Yuniskis on 6 Jul 2010 12:54
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.
From: Joe Chisolm on 6 Jul 2010 13:36
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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: CY7C68013A:ezusb.sys driver receives a trash data
Next: STM32 and USB examples