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ć <[EMAIL PROTECTED]> 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ć <[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
