[coreboot] LinuxBIOS/coreboot and security

[Philipp Marek]

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. 
Standard practice.
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 
disallowed.

> > - 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 
wrong.

> Coreboot will unconditionally launch its payload, so your interest should go 
> there. 
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  
> process; 
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 
> disk?
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.


Carl-Daniel wrote:
> 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
> law.
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) 
setup password.
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!


Regards,

Phil