[OLPC-devel] Secure BIOS on the OLPC

[John R. Hogerhuis]

On Mon, 2006-08-28 at 23:46 -0400, Ivan Krstić wrote:
> Carl-Daniel Hailfinger wrote:
> > And it fully automates bricking of thousands of machines if the key
> > is ever compromised. 
> 
> If 3 separately kept private keys, two of which will live in a bank
> vault, are compromised.
> 

I'm sorry, bank vault? For your scheme to work you have to sign the
binaries with a key that works on all units. Bank vault or not the key
enters human hands. The problem there is not physical security but a
"trust the programmers" issue.

> > Flashing a new BIOS against the will of the user
> > is *evil* (and generates quite a lot of bad publicity if you look at
> > the Playstation Portable forced firmware upgrades).
> 
> I'm not familiar with these (I'll read up on them), but I imagine they
> change actual user-visible system functionality in some way? That's
not
> what any of our BIOS upgrades will do.
> 

You're not familiar with evil? How about hubris. Engineers are not
perfect. No perfect upgrade system has ever been designed / implemented.
Most likely, yours isn't either so any system which is required to be
perfect is broken by requirement.

> In principle, though, I agree with you. Power users never considered
> upgrades that do things behind their backs a feature. But I think
you'll
> find the exact opposite holds for most computer users, and this
becomes
> particularly compelling when many of your users are too young to be
able
> to make a reasonable decision about whether to agree or disagree with
a
> security prompt.
> 

I think the kids are going to have to make decisions about whether to
disagree or agree with maintenance system prompts. How to make critical
operations have sufficient gravitas for a 6 year old... that is a
question for the psychology and child development folks. One hopes that
it can be answered since 6 year olds can read and so they may be
presuaded to do Bad Things by those who do understand this (phishing).

The other side of the coin is that for this case not only do we need to
persuade kids not to do dangerous things, but for a traditional upgrade
we need to persuade them to be complicit in machine maintenance.

So in the context of email, phishing, the internet, et al I think we
need to solve the problem of communicating with 6 year olds anyway.
Maybe the child development experts tell us that upgrade can't be
completed by a 6 year old. Maybe the parents need to get involved or the
upgrade doesn't happen. Or even better, they need to bring the laptop to
school and the teacher gives them a code that lets them perform the
operation.

Again, this is where we need to get specialists in child development
involved. I don't think we jump to the conclusion that we HAVE to do
automatic firmware upgrades without user complicity.


> Finally, remember that BIOS flashing is really a fully opaque
operation.
> While software upgrades tell you things like "I want to upgrade
version
> x of this software to version y, here's what will be different", how
do
> you see this happening for BIOS upgrades? In other words, in what
cases
> does the user know enough about the system to be able to
authoritatively
> refuse a BIOS upgrade?
> 

First, by definition those that do understand what is happening are in a
position to authoritatively refuse. Not every kid will be in this
category, but some will.

In any event the point Carl-Daniel was making is that we want to prevent
mass bricking of units. Fully automated upgrade permits mass bricking in
a way that requiring user assent does not.

All it takes for this to become a nightmare is for ONE of then following
(well, in addition to an actual attack)

a) your design to be flawed (or do we assume your design is perfect
because we didn't find any bugs)
b) the implementation to be flawed (or do we assume perfect programmers
or QA)
c) escape of the keys (or do we assume a programmer would never violate
NDA)
d) cracking of the keys (or do we assume that it cannot be done)

The history of such systems in our industry says one of these is going
to happen. Generally even when I have seen automatic upgrade systems for
firmware on embedded devices, the devices are not designed to be
connected to the open internet. Usually they are expected to be on a
corporate network behind a firewall. General purpose laptops and
computers are almost never set up for automatic upgrades even for
non-power-users.

Even if signed binaries end up being the way the project chooses, I
still think that human complicity should be required.

That doesn't necessarily mean a prompt like "If you would like to
upgrade your BIOS hold down keys and click OK," it's more like "UPGRADE
Some new stuff needs to be put on your computer. Enter the code your
teacher gave you so that these changes can be made and then hold down
the spacebar." Or something.

> > Once you make these provisions, how are you going to be sure a worm
> > author doesn't use them? "Hey, I'm a kid wanting to hack the BIOS,
can
> > I have a signing key?"
> 
> Developer signing keys are issued for each machine individually, based
> on the serial number.
> 
> > There should remain at least one way to flash a
> > non-signed BIOS without resorting to a soldering iron. Possibly
> > require a USB keyfob to be plugged in or something
> > (like the original solution with keypress).
> 
> I've been toying with the same idea. Let me think about that some
more.
> 

I would like to see this too for the openness issue.

-- John.