Hello everybody!
First I have to admit that while I occasionally followed the progress of LinuxBIOS I don't really know that much about it, so please forgive me if that discussion is already over and done with.
My question is this. I'd like to secure machines against the people that should work with them [1].
In most BIOSes I can set the boot order to "harddisk only". (coreboot too, right?). That doesn't help if someone has access to the machine and can reset the CMOS.
Encrypting the harddisk is another way, but if someone installs a trojan/keylogger or uses
Now my idea was: - Set the boot order and a BIOS password - Encrypt the harddisk, (print the key and store it somewhere safe), and derive the key from some passphrase (and/or smartcard, etc.) *and* CMOS data.
As soon as I get, say, 128bit of entropy there, eg. by the salted MD5 hash of the BIOS password, it's suddenly a great bit harder to get into the machine. If the machine has an intrusion detection, the better; and if the BIOS overwrites the password as soon as a changed harddisk (by serial number and SHA1 of bootsector?) is detected, it is a really good solution.
The only possible way to attack that'd be left is on the order of cutting holes in the case, and using a logic analyser to get the CMOS values of the motherboards' bus and similar ... and that is likely to raise questions.
Ad 1: I know that that's impossible to achieve fully, like DRM. But if there is some easy way to set the bar higher - then why not?
Thank you for all remarks, ideas and answers! Happy weekend!
Phil
Hi Philipp,
On 25.01.2008 12:50, Philipp Marek wrote:
My question is this. I'd like to secure machines against the people that should work with them [1].
Ah. Classic DRM.
In most BIOSes I can set the boot order to "harddisk only". (coreboot too, right?). That doesn't help if someone has access to the machine and can reset the CMOS.
Who says you have to store the settings in battery-backed NVRAM?
Encrypting the harddisk is another way, but if someone installs a trojan/keylogger or uses
A hardware keylogger will catch the admin in almost all cases.
Now my idea was:
- Set the boot order and a BIOS password
- Encrypt the harddisk, (print the key and store it somewhere safe), and derive the key from some passphrase (and/or smartcard, etc.) *and* CMOS data.
So what? I need less than 5 minutes of hardware access to your machine to break that scheme if I know the scheme well enough. If I have no idea about the scheme, it will probably take me two sessions of 5 minutes with a few days in between.
As soon as I get, say, 128bit of entropy there, eg. by the salted MD5 hash of the BIOS password, it's suddenly a great bit harder to get into the machine. If the machine has an intrusion detection, the better; and if the BIOS overwrites the password as soon as a changed harddisk (by serial number and SHA1 of bootsector?) is detected, it is a really good solution.
OK, maybe 10 minutes.
The only possible way to attack that'd be left is on the order of cutting holes in the case, and using a logic analyser to get the CMOS values of the motherboards' bus and similar ... and that is likely to raise questions.
Why do you assume someone wants to sniff the bus if he simply can remove all power to the machine, open the case, replace the BIOS, boot and dump the data, power down, replace the BIOS again, close the case, power up with the original BIOS. Circumvention successful.
Ad 1: I know that that's impossible to achieve fully, like DRM. But if there is some easy way to set the bar higher - then why not?
It's basically the same old questions as with most soft/hardware security mechanisms: How much more difficult do you want to make it for the user to circumvent security? Do you assume the user is unskilled, moderately or extremely skilled? How about access to lab equipment? Are you willing to invest many hours to increase time-to-breakin a few minutes? Do you control (manufacture) the hardware?
There is no easy way to set the bar higher. It will almost always cost you a lot more time to secure a machine than it takes the user to break it.
Sorry to disappoint you, but the problem is a minefield littered with the bodies of failed attempts.
Regards, Carl-Daniel
On Saturday 26 January 2008, Carl-Daniel Hailfinger wrote:
Hi Philipp,
On 25.01.2008 12:50, Philipp Marek wrote:
My question is this. I'd like to secure machines against the people that should work with them [1].
Ah. Classic DRM.
DRM does not work. The only use I can think of is a student pool at the university.
Do you control (manufacture) the hardware?
Even that does not help. Ask M$ about a thing called "Ex-box" (or so...)
There is no easy way to set the bar higher. It will almost always cost you a lot more time to secure a machine than it takes the user to break it.
Not if it's under surveillance, like a student's computer pool room, subject to unannounced inspection. In that scenario cases with a single screw have proven themselves. That screw is then chained and locked.
HTH, Torsten
On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote:
My question is this. I'd like to secure machines against the people that should work with them [1].
Ah. Classic DRM.
DRM does not work.
I think this is because it tries to provide an all-encompassing solution to a generic problem.
"Securing machines against the user" is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions.
//Peter
On Sunday 27 January 2008, Peter Stuge wrote:
On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote:
DRM does not work.
I think this is because it tries to provide an all-encompassing solution to a generic problem.
No, because it tries to provide a technical solution to a social phenomenon percieved as a problem.
"Securing machines against the user" is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions.
Yepp. A defense strategy needs an attack scenario first.
Torsten
Hello everybody!
On Sunday 27 January 2008, Peter Stuge wrote:
On Sun, Jan 27, 2008 at 11:32:26PM +0100, Torsten Duwe wrote:
DRM does not work.
I think this is because it tries to provide an all-encompassing solution to a generic problem.
No, because it tries to provide a technical solution to a social phenomenon percieved as a problem.
"Securing machines against the user" is also very generic. If you can be more specific, Phillip, perhaps we can offer some suggestions.
Yepp. A defense strategy needs an attack scenario first.
I'm fully aware that *every* security can be broken - it's always a question of how much money/time gets invested (both by the defender, and the attacker).
The scenario is to protect the system installation against the user. - Using some operating system unencrypted - boot from a CD. - Protect the boot order - reset the CMOS. - Store important information in the CMOS.
That's my thoughts by now.
Of course, you'd need a dead-man switch in the case (that deletes the CMOS), but that's available in quite some cases - just connect the cable to the right motherboard position, and you're find (if it's the correct switch - close/open).
Simply substituting the BIOS with another one won't be so easy.
If it's a notebook, possibly a hardened one, getting to the motherboard might mean some work - and tripping the intrusion detection.
All I'm asking for is a BIOS password, that gets stored as a salted hash in a fixed location in the CMOS - then a system installation process can write some generated value there, and use that for harddisk encryption.
Securing the hardware is necessary, too - but there coreboot won't help me :-)
Thank you for your answers!
Regards,
Phil
On Monday 28 January 2008, Philipp Marek wrote:
Yepp. A defense strategy needs an attack scenario first.
The scenario is to protect the system installation against the user.
That's not an attack scenario.
- 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.
Coreboot will unconditionally launch its payload, so your interest should go there. Maybe you are also caught up too much in the conventional boot process; why does the password need to be stored in CMOS RAM and not on disk? Without knowing exactly what you are trying to protect against ( I know -- "the user" ) we cannot tell.
Torsten
On Mon, Jan 28, 2008 at 11:16:01AM +0100, Torsten Duwe wrote:
Without knowing exactly what you are trying to protect against ( I know -- "the user" ) we cannot tell.
What I think Torsten is getting at is that it would be beneficial to think about what user actions you want the system to be able to handle.
//Peter
On 27.01.2008 23:32, Torsten Duwe wrote:
On Saturday 26 January 2008, Carl-Daniel Hailfinger wrote:
Hi Philipp,
On 25.01.2008 12:50, Philipp Marek wrote:
My question is this. I'd like to secure machines against the people that should work with them [1].
Ah. Classic DRM.
DRM does not work.
Single-chip solutions with an embedded TPM at least make attacks really difficult.
The only use I can think of is a student pool at the university.
Or maybe a company wants to secure their machines against their employees.
Do you control (manufacture) the hardware?
Even that does not help. Ask M$ about a thing called "Ex-box" (or so...)
Agreed. However, if somebody manufactures the hardware, he has a lot more options to make tampering difficult than someone whi simply sticks a board in a case and tries to solve the problem in software.
There is no easy way to set the bar higher. It will almost always cost you a lot more time to secure a machine than it takes the user to break it.
Not if it's under surveillance, like a student's computer pool room, subject to unannounced inspection. In that scenario cases with a single screw have proven themselves. That screw is then chained and locked.
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.
Regards, Carl-Daniel
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
Ok, I'm not going to get too far into this, because I'm no real security expert, but:
On Jan 30, 2008 11:40 AM, Philipp Marek philipp@marek.priv.at wrote:
- 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 ...
I think what he was trying to say is that if you give coreboot, say, a FILO payload set up to boot from some medium, with no support for any other medium, then there's no switch you can throw, short of flashing a new bios onto the board. You can do the same thing with a linux kernel, use that to unconditionally kexec to a specific medium, or with large enough flash, you could store the entire kernel in flash.
-Corey
On Wednesday 30 January 2008 Corey Osgood wrote:
Ok, I'm not going to get too far into this, because I'm no real security expert, but:
...
I think what he was trying to say is that if you give coreboot, say, a FILO payload set up to boot from some medium, with no support for any other medium, then there's no switch you can throw, short of flashing a new bios onto the board. You can do the same thing with a linux kernel, use that to unconditionally kexec to a specific medium, or with large enough flash, you could store the entire kernel in flash.
OK, that's a possible way..
Although for development and support it might be good to be able to boot from other media; that would have to be password-protected (per-machine), and then I'm back where I started.
[ And having different images for development and release is not what I'd like, TBH. ]
But it's surely something to think about.
Thank you!
Regards,
Phil
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
On Wednesday 30 January 2008, Corey Osgood wrote:
I think what he was trying to say is that if you give coreboot, say, a FILO payload set up to boot from some medium, with no support for any other medium, then there's no switch you can throw, short of flashing a new bios onto the board.
Exactly. With FILO or grub2 as payload you can enforce the loading of a kernel from disk with specified arguments. This will also allow (re-) installation after entering a password. This is secure until someone uses a screwdriver and opens the case.
You can use the TPM (if you have one) then. This is secure until someone uses a soldering iron.
You can manufacture your own fully integrated chips with TPMs. These will be secure until someone uses the on-chip equivalent of a soldering iron: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
And so on, and so on... How much time and money are you willing to spend?
Torsten
Also keep in mind another important thing: don't federate your opponents.. (and don't create new ones!) Don't forget that the first Xbox platform was cracked because people wished to run Linux on that hardware, it was not the feat of some "warez crackers".. When people will think that is morally acceptable to circumvent "security mesures" because these block their legitimate use (or perceived as this..) is game over.. Don't design your solution as a magical "silver bullet" making your platform universally hacker-proof in any possible situation. Security is only effective when one carefully integrate it in every critical component of the system and when all the possible use cases are evaluated. This implies that the "security perimeter" must be very well defined and understood. Practically, IMHO this mean that these kind of "platform security mesures" can work only for very specific "appliances" (in other words designed for a very specific use, eg "game console", "dvd player", etc..)
Just my 2 (euro-)cents Florentin
Quoting Torsten Duwe duwe@lst.de:
On Wednesday 30 January 2008, Corey Osgood wrote:
I think what he was trying to say is that if you give coreboot, say, a FILO payload set up to boot from some medium, with no support for any other medium, then there's no switch you can throw, short of flashing a new bios onto the board.
Exactly. With FILO or grub2 as payload you can enforce the loading of a kernel from disk with specified arguments. This will also allow (re-) installation after entering a password. This is secure until someone uses a screwdriver and opens the case.
You can use the TPM (if you have one) then. This is secure until someone uses a soldering iron.
You can manufacture your own fully integrated chips with TPMs. These will be secure until someone uses the on-chip equivalent of a soldering iron: http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
And so on, and so on... How much time and money are you willing to spend?
Torsten
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Wednesday 30 January 2008, Philipp Marek wrote:
There are device being installed and handed out,
-> You're doomed :-) As Peter pointed out already.
that should be as secure as possible.
This will make them as expensive as possible, see below.
[...]
Neither is this.
No, this should illustrate my thoughts ... so you can tell me *where* I'm wrong.
Attack scenarios are evil things an opponent can do, like * boot from his own CD * exchange the hard disk * run a fake login screen and wait for the admin * ... Think of as many as you can and then take countermeasures. Then think about counter-countermeasures and so on, until the benefit for the attacker isn't worth it any more. That's security.
Torsten
-
Carl-Daniel Hailfinger -
Corey Osgood -
Florentin Demetrescu -
Peter Stuge -
Philipp Marek -
Torsten Duwe