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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Krstic > Sent: Sunday, August 27, 2006 2:11 PM > To: [email protected] > 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ć <[EMAIL PROTECTED]> | GPG: > 0x147C722D _______________________________________________ > Devel mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
