The One Laptop Per Child platform was always going to present some
interesting security challenges. Millions of identical, network-attached
systems will be deployed into some remote parts of the world, where they
will be managed by people who are not security experts. The systems will
be obvious targets for theft, self-propagating malware, and the creation of
botnets. None of these activities feature highly on the OLPC project's
list of educational objectives, so it stands to reason that some
significant thought needs to go into how to prevent them.
The person charged with the OLPC's security thinking is Ivan Krstić. The
initial results of his work, done with help from Simson Garfinkel, have now
been posted with a request
for comments. Ivan and company have come up with a platform named
"Bitfrost," which, it is hoped, will keep OLPC systems out of trouble and
available for their owners. At this point, there is quite a bit of
information on what Bitfrost will do, but very little on how it will be
After an introduction on the shortcomings of the traditional Unix file
permissions model, the Bitfrost specification gets into the overriding
principles and goals. The principles are consistent with the approach the
OLPC project has taken so far: security cannot depend on hardware or
software design secrets, it must be possible for users to gain complete
control over the system, security cannot depend on the user being able to
read, and the security mechanism must be unobtrusive. "Unobtrusive" does
not mean that security won't ever get in the way; instead, it means that
the user will not be pestered by popups with security-related questions.
The associated goals include no user passwords, no unencrypted
authentication, a system which is secure when it is first powered on, a
very limited use of public-key encryption infrastructure, and no permanent
The process starts at manufacturing time, when each laptop will be equipped
with unique, randomly-generated serial and UUID numbers. The laptop starts
out in a non-functional, deactivated state; making it work involves the use
of a special activation key generated from the serial number and UUID.
The customer countries will have lists of serial and UUID numbers; from
those it will be able to create the activation keys. The plan is for these
keys to be generated in small batches and shipped, on a USB key, to the
destination schools. Once installed on a server there, the keys can be
used to enable the laptops sent specifically to that school. The purpose
here is to deter thieves who would grab pallets of laptops; without the
activation keys, those laptops would only be useful as spare parts.
There is an interesting step which happens once a laptop is activated and
On first boot, a program is run that asks the child for their name,
takes their picture, and in the background generates an ECC key
pair. The key pair is initially not protected by a passphrase, and
is then used to sign the child's name and picture. This information
and the signature are the child's 'digital identity'.
The laptop transmits the (SN, UUID, digital identity) tuple to the
activation server. The mapping between a laptop and the user's
identity is maintained by the country or regional authority for
anti-theft purposes, but never reaches OLPC.
The ability to locate the proper owner of an OLPC system has obvious
advantages; it should help to keep each laptop in the proper set of small
hands. On the other hand, the potential for a repressive government to
misuse this data seems real; it would be sad if the OLPC systems could not
be used for truly free communications without fear about who might be
At the BIOS level, security will be handled as described in this LWN article from last
August. The BIOS will only be rewritable when the new image has been
signed with a special cryptographic key. There will be "developer keys"
available which will enable a laptop's owner to reflash the BIOS, but, in
general, the children will not have that functionality available to them.
At the Linux level, security will be handled through a set of privileges
assigned to each installed program. Privileges look much like Linux
capabilities, but they are not capabilities; they are a new layer of
protections which will be implemented via some other means. Some of the
expected privileges will include:
- P_SF_CORE: the ability to modify the core software on the
system. This privilege is normally off, and cannot be enabled without
a special developer key. There is also P_SF_RUN, which
allows modification of the currently-running system software. This
privilege works by way of a copy-on-write filesystem mechanism;
software changes are saved as copies. This mechanism makes it easy to
revert the system to its initial state should the need arise.
- P_NET: a group of controls on network access. Programs can
be denied access to the net entirely, or they can have any of a wide
range of bandwidth, time-of-day, and destination restrictions applied
- P_MIC_CAM: programs can be granted (or denied) the ability to
use the camera and the microphone. There will also be LEDs (not
present on the current test systems) which will illuminate whenever
the camera or microphone are in use. So it should be difficult to use
an OLPC system to spy on its owner.
- There is a whole set of quotas designed to prevent a program from
using too much processor time, flash space, etc.
In addition, every program will be run in an isolated mode:
A program on the XO starts in a fortified chroot, akin to a BSD
jail, where its visible filesystem root is only its own constrained
scratch space. It normally has no access to system paths such as
/proc or /sys, cannot see other programs on the system or their
scratch spaces, and only the libraries it needs are mapped into its
scratch space. It cannot access user documents directly, but only
through the file store service, explained in the next section.
Again, details on just how the sandbox will be implemented are scarce for
now - though your editor has heard from Mr. Krstić that it will be
based on Linux-VServer.
The "file store service" is described as a sort of object-oriented
database for documents, "similar in very broad terms to the Microsoft
WinFS design". All access to files from programs goes by way of a
user dialog; there should be no way for a program to modify files outside
of its own scratch area without the user knowing about it.
There is also an optional anti-theft mechanism:
It works by running, as a privileged process that cannot be
disabled or terminated even by the root user, an anti-theft daemon
which detects Internet access, and performs a call-home request --
no more than once a day -- to the country's anti-theft servers. In
so doing, it is able to securely use NTP to set the machine RTC to
the current time, and then obtain a cryptographic lease to keep
running for some amount of time, e.g. 21 days. The lease duration
is controlled by each country.
If a machine has been reported as stolen, the "anti-theft server" will
instruct it to shut down hard and go back into the deactivated state. The
same thing will happen eventually if the stolen system is kept isolated
from the net. This mechanism should help to deter thefts; one can only
hope that it is sufficiently well designed that nobody figures out how to
trigger it as a denial of service attack.
The phone-home feature can be disabled - but only in the presence of
a developer key.
One feature which will not be built into the laptops is filesystem
encryption. The CPU in the OLPC XO laptop is simply too slow to perform
that task without bogging down the system entirely. This issue will be
reconsidered in the future. The OLPC developers have also explicitly
decided to stay out of the content-filtering business.
In summary, the security model developers have this to say:
[W]e believe we've imbued the OLPC security system with cunning and
more magic art than other similar works of craftmanship -- but not
for a second do we believe we've designed something that cannot be
broken when talented, determined and resourceful attackers go forth
harrying. Indeed, this was not the goal. The goal was to
significantly raise the bar from the current, deeply
unsatisfactory, state of desktop security.
If the implementation lives up to the specification, chances are that the
project will have achieved that goal. The OLPC platform is an ambitious
experiment from beginning to end, and its developers have, once again, not
wasted the opportunity to do something interesting with it. If the
security ideas incorporated into the OLPC systems work out as desired, it
would not be surprising to see at least some of them adopted by other
desktop environments. This could be another case where the OLPC project
creates benefits for a large group of people beyond its immediate target.
to post comments)