[coreboot] LinuxBIOS/coreboot and security
philipp at marek.priv.at
Wed Jan 30 17:40:24 CET 2008
Well, thanks everybody for the comments.
I'll try again; I hope that I can clarify my wishes.
The situation is as follows:
There are device being installed and handed out, that should be as secure as
possible. That includes data theft (personal or otherwise sensitive data) and
unauthorized changes to the system (only to be allowed by the administrator).
The user should be able to run the preinstalled applications, and use network
connectivity *in some locations* only - against the "certified" network,
which presumably uses IPSEC, 802.1x and similar things.
Some of the problems are easily solved - encrypt the harddisk with a key from
a smartcard, and outsiders have a tough time.
The point that I've arrived at now is
- having a machine,
- have a matching token,
- and know the PIN.
For first-order approximation that attack specifics only match an user - or
someone that gets "reminded" to help, so again securing against the knowledge
of an user.
Torsten Duwe wrote:
> On Monday 28 January 2008, Philipp Marek wrote:
> > 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.
Now the easiest way is permissions - like 0700 for /etc/shadow, and so on.
Boot disks are solved in some way by not allowing booting from external media;
that helps against a knoppix, and even a vmware using the harddisk can be
> > - Using some operating system unencrypted - boot from a CD.
> > - Protect the boot order - reset the CMOS.
> > - Store important information in the CMOS.
> Neither is this.
No, this should illustrate my thoughts ... so you can tell me *where* I'm
> Coreboot will unconditionally launch its payload, so your interest should go
That's ok. It's a "normal" OS that has to be started.
> Maybe you are also caught up too much in the conventional boot
That's possible, and that's why I'm asking here!
I don't know that many ways to boot a machine - use ROM; use a BIOS and
another medium; and that's it.
Is there some easy solution I don't see?
And just storing everything in ROM is a bit ... costly, and doesn't help
against *getting* the secrets.
Using some cheap substitute like flash memory only moves the problem from one
location to another ...
> why does the password need to be stored in CMOS RAM and not on
Why did I think about the CMOS? If *all* sensitive information is stored on
the harddisk, you just put a camera on the plane, watch the password entry
(or get it acoustically or however), disassemble everything, and get all data
by a purely static analysis.
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.
> Yes. Surveillance is indeed a very promising way for tamper prevention.
> Another way without direct surveillance would be installing an alarm
> system with a really loud acoustic signal. If the signal is guaranteed
> to be heard outside the room, you don't need surveillance inside the
> room. That option may help in case direct surveillance is prohibited by
Yes, that's some option for a fixed location. For notebooks that need to be
taken on some journey, it might be opened in some cellar ... and if the first
blow is against the speakers, it won't work anyway.
Part of that problem might be that all current machines use DRAM - if there
was an option to use SRAM, suspend-to-ram might have enough time between
charges that the machine would be booted once - and never shut down.
[ Yes, I know about freezing the RAM, and putting it in some analyser ... but
that's an hardware issue again. ]
To summarize: Most of the problems are physical security.
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)
More cannot be solved in software - for more you'd need triggers for "case
opened" etc. that immediately clear the CMOS.
[ And that's another reason to use the CMOS - it's *much* easier cleared
than some harddisk sector. ]
Sorry for the long post - I hope I could answer some questions.
Thank you for your help!
More information about the coreboot