[OLPC-devel] Secure BIOS on the OLPC

[Krishna Sankar (ksankar)]

One more thought - AM not sure we should leave the update bios to the kids. Possibly under the supervision of an adult, teacher et al would be a good idea. One way or other, the little ones need to learn good security practices, that is appropriate to their level. 

Another question - do we have incremental download of some sort, especially as the device is inherently intermittently connected.

Cheers
<k/>

> -----Original Message-----
> From: devel-bounces at laptop.org 
> [mailto:devel-bounces at laptop.org] On Behalf Of Ivan Krstic
> Sent: Sunday, August 27, 2006 2:11 PM
> To: devel at laptop.org
> Cc: Mark J. Foster
> Subject: [OLPC-devel] Secure BIOS on the OLPC
> 
> [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
>