[coreboot] LinuxBIOS/coreboot and security
c-d.hailfinger.devel.2006 at gmx.net
Sat Jan 26 01:33:55 CET 2008
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 .
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.
More information about the coreboot