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