[OLPC-devel] Secure BIOS on the OLPC

[Tim Flavin]

On 8/27/06, Krishna Sankar <ksankar at doubleclix.net> wrote:
> Ivan,
>
>         Am going to take a quick look at it. Looks like basically you are
> talking about signing the binaries.
>
>         a)      How does the verification happen ? This is where the
> vulnerability will be.

How about re-using the Linux code that is used to verify signatures on
 loadable modules and binaries.

>         b)      Where would the certs be stored ?

In the BIOS kernel like the above implementation if you want them to
be updatable, or in the section of the SPI flash with the serial
numbers if you don't want them changed.

>         c)      Will we ship with an embedded cert ? If so, how can it be
> updated securely ?

Same way the BIOS is updated.

>         d)      Do we assume internet connectivity for cert verification as
> well as for CRLS et al ?

No cert is in the SPI flash.

>         e)      What else would this require in terms of infrastructure ?
> Connected to power ?

Don't do this on a low battery.

>         f)      AN unrelated question - if power fails in the middle, is
> there a reset option ?

See above.
>
>         Will ask more Q as I think of. I would rather document this, think
> through and then start implementing. I assume security, while crucial is not
> an immediate need. i.e. it should be available when the system is complete.
> (Of course, even if the implementation is done, we can tweak the protocols,
> mechanics and mechanisms later anyway)
>
> 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
> >
>
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>