[OLPC-devel] Secure BIOS on the OLPC

[Tim Flavin]

Sounds like a good idea.  It will not protect against people
distributing an old BIOS with
a known exploit and will prevent students from experimenting with the
BIOS, but probably better than the current situation.

On 8/27/06, Ivan Krstić <krstic at solarsail.hcs.harvard.edu> wrote:
> [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
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>