Hi Philipp,
On Wed, Jan 30, 2008 at 05:40:24PM +0100, Philipp Marek wrote:
There are device being installed and handed out, that should be as secure as possible.
I realize this is the most accurate way to describe your problem in natural language, but I'm afraid it's not possible to implement a security solution that delivers this, and anyone telling you otherwise will just want to take your money.
Security measures can only be implemented to protect against specific threats.
Conversely this also means that a sufficiently creative attacker can break any security scheme.
The trick is of course to make it too expensive even for creative attackers to break the security so that the cost is greater than the benefit. But this will not stop all attackers, in particular it will never stop a curious hacker. See e.g. Hack a Bike: http://www.ccc.de/hackabike/
The scenario is to protect the system installation against the user.
That's not an attack scenario.
But there are things on the box (encryption keys for wireless and other communications, etc.) that should even be kept secret against the people *using* the system - so that they cannot bring their own machines, and try to intrude into the rest of the network.
Yes that is understood, but the question is how competent and resourceful you expect them (the attacker) to be.
Regardless of how many smartcards you use, an attacker who gains possession of the system and the smartcards, and is able to work undisturbed with access to electron microscopes and other multi-million-EUR equipment, will be able to extract all your data.
Is there some easy solution I don't see?
No.
A lot can be learned from studying the game console security failures. There is a good paper about the Xbox, and a good presentation from 24C3 about the Xbox 360. They are highly recommended:
http://www.xbox-linux.org/wiki/17_Mistakes_Microsoft_Made_in_the_Xbox_Securi... http://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf http://events.ccc.de/congress/2007/Fahrplan/events/2279.en.html (recordings on the bottom of the page)
And just storing everything in ROM is a bit ... costly, and doesn't help against *getting* the secrets.
Security is always a compromise. Security is frequently expensive. The more resourceful attacks you want to protect against, the more expensive security will get.
A hypervisor in mask ROM gives good protection even against some resourceful attackers, but you must pay attention to every single instruction in that hypervisor code, as the 360 talk will show.
Now, if some encryption key is in the CMOS, you have to get that data alive - and that means you can't simply switch a jumper on the motherboard to enable booting from external data.
Uhm, what? Note that "CMOS" usually refers to the _non-volatile_ battery-backed RAM that is accessible alongside the real-time-clock in superio chips.
[ Yes, I know about freezing the RAM, and putting it in some analyser ... but that's an hardware issue again. ]
Also have a look at data remanence: http://www.cypherpunks.to/~peter/usenix01.pdf
I'd just hope that coreboot defines some locations in CMOS, that can be written by a installation process to define the boot order and a (hashed) setup password.
Adding a boot condition to a payload would be simple, but this is also very easy to defeat e.g. if the attacker is able to inject code on the bus.
More cannot be solved in software - for more you'd need triggers for "case opened" etc. that immediately clear the CMOS.
Right. More at: http://en.wikipedia.org/wiki/Tamper_resistance
On Wed, Jan 30, 2008 at 06:21:55PM +0100, Philipp Marek wrote:
Although for development and support it might be good
WATCH OUT. Now you are re-defining the security model. You are about to intentionally introduce a huge hole that cuts right through all your security, in order to make development easier. (Ie. to save money.) See the Xbox talks, or the PSP talk from 24C3. This is a sure way to lose the battle before it has even started.
[ And having different images for development and release is not what I'd like, TBH. ]
Alas, it is fundamental.
//Peter