[OLPC-devel] Secure BIOS on the OLPC

[Ivan Krstić]

[This is important, and your comments are requested -- please read.]

While working on the OLPC security policy and threat model, I spent some
time thinking about how we're going to perform BIOS updates.

In the unprotected scenario, the kernel is able to write a new BIOS
directly to the SPI flash. Our threat model assumes that the kernel
could be completely compromised, which is why we need hardware-level
protection: otherwise, a worm could go and brick the BIOS of every
Internet and mesh-reachable OLPC laptop before we blinked.

The solution that's been devised and worked on (before I got involved)
is to hand control of the SPI #WE line to the EC, which would require
that a combination of keys is physically pressed before allowing a SPI
flash write. This would mean that worms are no longer a viable attack
vector: all SPI flashing requires physical user interaction.

I argue that this solution is deeply flawed for three reasons:

* while it stops a worm-type attack, it does nothing against phishing,
where the kids will be convinced to hold the buttons down while a
malicious BIOS gets flashed

* it allows any BIOS to be flashed, so long as the keys are pressed,
when in reality there's no direct need to support non-OLPC BIOSes

* it requires the kids' cooperation for legitimate upgrades, which means
the kids suddenly need to distinguish between legitimate and
illegitimate upgrades, or fall prey to phishing

After spending about 18 hours looking at various secure BIOS solutions,
involving anything from TPM hardware to complicated secure BIOS
payloads, I thought the above solution, while flawed, is the best we can
do.

At some unpleasant hour of the morning last night, I had a flash of
inspiration, and I think I've solved this in a much better way. Here's how:

1. The EC code is tweaked to remove the keys-pressed requirement.
Instead, the EC boots with the SPI #WE enabled, but can receive a
special instruction that permanently disables the line until the EC is
rebooted (without the ability to re-enable it until then).

2. When a new BIOS is to be flashed, it is written by the system upgrade
facility (or a worm or an attacker) to a pre-determined location on the
NAND, say /boot/new-bios.

3. The LB payload we ship is changed: when mounting the NAND to kexec
the regular kernel, LB first checks for the existence of the
/boot/new-bios file.

If the file is present, the LB payload verifies that the binary is
cryptographically signed by OLPC. This is all done within the known-good
LB payload.

If the signature verification fails, LB deletes /boot/new-bios and
continues. If verification succeeds, LB flashes the file into the SPI
flash (remember, the EC started with #WE enabled).

4. Fully regardless of the previous-step, LB always signals the EC to
disable the SPI #WE before kexecing the regular kernel.

Voila. This is now a completely secure BIOS solution which requires no
TPM, allows fully automatic upgrades without the user's cooperation
(such as pressing keys), and fully protects both against phishing and
automated attacks -- in fact, it's vector-independent. The design also
allows provisions to be made for kids that are brave enough to want to
hack their BIOSes, as well as for countries which want to offer
additional non-OLPC BIOSes.

If you see any problems with this solution, please point them out right
away, since I'd like to ask Mark and Ray to implement the necessary EC
changes as soon as possible.

Cheers,

-- 
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D