[coreboot] LinuxBIOS/coreboot and security

[Peter Stuge]

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