The
One Laptop Per Child project will, if
successful, place special laptop computers into the hands of millions of
children all over the world. Most of these children will have never worked
with a computer before. The consequences of providing Linux-based systems
to this many children are likely to be huge. If this project is done
right, these kids will grow up seeing free software as the preferred thing
to use. Done wrong, it could turn them (and the adults around them)
against Linux in a big way.
Many aspects of the OLPC systems are interesting; one of those is that they
will use LinuxBIOS
as their onboard, boot-time firmware. LinuxBIOS will bring a high degree
of flexibility to the system, and some complexity as well. There is a real
possibility that, as the result of some late bug or security problem, an
in-field upgrade to LinuxBIOS will be called for. In addition, some users
may want to hack on the firmware and install their own version - after all,
the source is available. For both reasons, the OLPC systems will be able
to rewrite their BIOS on demand.
There is a potential problem there, however. If it is too easy to rewrite
the BIOS, no end of unpleasant things could happen. In the worst case,
some sort of OLPC-based worm could, over a brief period, turn all online
systems into expensive bricks. Or, perhaps even worse, the mass
implantation of a low-level back door could be performed. For this reason,
the OLPC design requires the user to give explicit permission before the
BIOS can be rewritten. In particular, a specific sequence of keys on the
keyboard must be held down before rewriting the BIOS will be possible.
Ivan Krstić has recently been thinking about the BIOS issue; in
particular, he is worried that the keyboard-based interlock still leaves
the system open to phishing attacks. The target user base for the OLPC,
remember, will be very young. If something pops up on their screen telling
them to push a certain set of keys, some of them may well do it. Adults
may be immune
to this sort of attack, but children need to be treated with more care.
So Ivan floated
a proposal for a different way of doing things. It does away with the
keyboard interlock; instead, the operating system is always forbidden to
rewrite the BIOS. The BIOS, however, can rewrite itself, and would do so
upon finding a new BIOS image in a specific place in the filesystem. That
image would have to be cryptographically signed, however, so attackers
would, presumably, be unable to get a new BIOS image written. Ivan says:
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.
Some who responded were not entirely happy with this approach, however.
The potential for performing BIOS upgrades (even if properly signed)
without the user's knowledge or consent is troubling. If a bug is found in
the signature verification code, the fully automated mass bricking scenario
becomes real again. Users who want to put in their own version of the BIOS
will be frustrated - they cannot be given the signing key without
compromising the entire mechanism (though this problem can be mitigated
through the addition of a unique key for each system). Some countries may
be unwilling to buy
and distribute the OLPC systems without the ability to create and install
their own BIOS images. And so on; see the
list archive for the full discussion thread.
There was no obvious consensus reached on the list - and no immediate
decision to change the OLPC hardware design. It is an issue requiring some
additional thought, however. The OLPC systems are designed, in general, to
be easy to fix when a user breaks things - they are meant to be
experimented with. A BIOS-level bricking, however, is decidedly not easy
to fix; it is not a scenario which can be allowed to come about. So it will
be interesting to see what solution the OLPC designers arrive at in the
end.
(Update: the OLPC project has decided to implement the new mechanism as originally described in the article).
Comments (18 posted)
Ross Anderson's well regarded book
Security Engineering is now available online. From Bruce Schneier's introduction:
Security engineering is different from any other kind of programming. It's a point I made over and over again: in my own book, Secrets and Lies, in my monthly newsletter Crypto-Gram, and in my other writings. And it's a point Ross makes in every chapter of this book. This is why, if you're doing any security engineering ... if you're
even thinking of doing any security engineering, you need to read this book. It's the
first, and only, end-to-end modern security design and engineering book ever written.
Comments (6 posted)
