From: D Yuniskis on 6 Jul 2010 14:19 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 6 Jul 2010 15:49 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 6 Jul 2010 16:18 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 :> )
First
|
Prev
|
Pages: 1 2 3 4 Prev: CY7C68013A:ezusb.sys driver receives a trash data Next: STM32 and USB examples |