Bitfrost

It has been suggested that this article or section be merged with OLPC Bitfrost. (Discuss)

Bitfrost is the OLPC security platform. A non-technical introduction to the security problems we're attempting to solve, and our goals and principles in doing so, follow on this page. They're taken from the complete Bitfrost specification (or the local wiki version), which we invite you to peruse and discuss on the public OLPC security mailing list.

Introduction and summary

In 1971, AT&T programmers Ken Thompson and Dennis Ritchie released the first version of UNIX. The operating system, which started in 1969 as an unpaid project called UNICS, got a name change and some official funding by Bell Labs when the programmers offered to add text processing support. Many of the big design ideas behind UNIX persist to this day: popular server operating systems like Linux, FreeBSD, and a host of others all share much of the basic UNIX design.

The 1971 version of UNIX supported the following security permissions on user files:

• non-owner can change file (write)
• non-owner can read file
• owner can change file (write)
• owner can read file
• file can be executed
• file is set-uid

These permissions should look familiar, because they are very close to the same security permissions a user can set for her files today, in her operating system of choice. What's deeply troubling — almost unbelievable — about these permissions is that they've remained virtually the only real control mechanism that a user has over her personal documents today: a user can choose to protect her files from other people on the system, but has no control whatsoever over what her own programs are able to do with her files.

In 1971, this might have been acceptable: it was 20 years before the advent of the Web, and the threat model for most computer users was entirely different than the one that applies today. But how, then, is it a surprise that we can't stop viruses and malware now, when our defenses have remained largely unchanged from thirty-five years ago?

The crux of the problem lies in the assumption that any program executing on a system on the user's behalf should have the exact same abilities and permissions as any other program executing on behalf of the same user. 1971 was seven years before the first ever international packet-switched network came into existence. And the first wide-area network using TCP/IP, the communication suite used by the modern Internet, wasn't created until 1983, twelve years after Thompson and Ritchie designed the file permissions we're discussing. The bottom line is that in 1971, there was almost no conceivable way a program could "come to exist" on a computer except if the account owner — the user — physically transported it to a machine (for instance, on punched tape), or entered it there manually. And so the "all or nothing" security approach, where executing programs have full control over their owner's account, made quite a lot of sense: any code the user executed, she ipso facto trusted for all practical purposes.

Fast forward to today, and the situation couldn't be more different: the starkest contrast is perhaps the Web, where a user's web browser executes untrusted scripting code on just about every web page she visits! Browsers are growing increasingly complex sandboxing systems that try to restrict the abilities of such web scripts, but even the latest browser versions are still fixing bugs in their scripting engine implementations. And don't forget e-mail: anyone can send a user an executable program, and for many years the users' instinctive reaction was to open the attachment and run the program. Untrusted code is everywhere, and the only defense seems to be tedious user training and anti-virus software — the latter assuming it's fully updated, and assuming the anti-virus makers have had time to deconstruct each latest virus and construct a defense for it.

Most technologies and approaches that constitute the Bitfrost platform do not represent original research: they have been known in the security literature for years, some of them have been deployed in the field, and others are being tested in the lab. What makes the OLPC XO laptops notable, however, is that they represent the first time that all these security measures have been carefully put together on a system slated to be introduced to tens or hundreds of millions of users. The laptops are also possibly the first time that a mainstream computing product has been willing to give up compatibility with legacy programs in order to achieve strong security. As an example, you'll find that talk about anti-virus and anti-spyware technology is conspicuously absent from the Bitfrost specification, because the security platform on the XO laptops largely renders these issues moot.

We have set out to create a system that is both drastically more secure and provides drastically more usable security than any mainstream system currently on the market. One result of the dedication to usability is that there is only one protection provided by the Bitfrost platform that requires user response, and even then, it's a simple 'yes or no' question understandable even by young children. The remainder of the security is provided behind the scenes. But pushing the envelope on both security and usability is a tall order, and it's important to note that we have neither tried to create, nor do we believe we have created, a "perfectly secure" system. Notions of perfect security in the real world are foolish, and we distance ourselves up front from any such claims.

The Bitfrost approach

Principles

Open design

The laptop's security must not depend upon a secret design implemented in hardware or software.

No lockdown

Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control.

No reading required

Security cannot depend upon the user's ability to read a message from the computer and act in an informed and sensible manner. While disabling a particular security mechanism may require reading, a machine must be secure out of the factory if given to a user who cannot yet read.

Unobtrusive security

Whenever possible, the security on the machines must be behind the scenes, making its presence known only through subtle visual or audio cues, and never getting in the user's way. Whenever in conflict with slight user convenience, strong unobtrusive security is to take precedence, though utmost care must be taken to ensure such allowances do not seriously or conspicuously reduce the usability of the machines. As an example, if a program is found attempting to violate a security setting, the user will not be prompted to permit the action; the action will simply be denied. If the user wishes to grant permission for such an action, she can do so through the graphical security center interface.

Goals

No user passwords

With users as young as 5 years old, the security of the laptop cannot depend on the user's ability to remember a password. Users cannot be expected to choose passwords when they first receive computers.

No unencrypted authentication

Authentication of laptops or users will not depend upon identifiers that are sent unencrypted over the network. This means no cleartext passwords of any kind will be used in any OLPC protocol and Ethernet MAC addresses will never be used for authentication.

Out-of-the-box security

The laptop should be both usable and secure out-of-the-box, without the need to download security updates when at all possible.

Limited institutional PKI

The laptop will be supplied with public keys from OLPC and the country or regional authority (e.g. the ministry or department of education), but these keys will not be used to validate the identity of laptop users. The sole purpose of these keys will be to verify the integrity of bundled software and content. Users will be identified through an organically-grown PKI without a certified chain of trust — in other words, our approach to PKI is KCM, or key continuity management.

No permanent data loss

Information on the laptop will be replicated to some centralized storage place so that the student can recover it in the event that the laptop is lost, stolen or destroyed.

If this subject matter interests you, please read the complete Bitfrost specification, join the OLPC security mailing list, share your thoughts, and join the discussion.

Current Status

The Bitfrost specification is being implemented in phases. The current status (Release 8.1.0 / Update.1) is reflected in the following notes.

In regard to the threat model (Chapter 7):

7.1 Damaging the machine: We have robust protection for the firmware; the most substantive threat to the NAND is to fill the disk. We have somewhat awkward means of recovery for this; a reflash is always an option. There is no current protection against Network and RAM attacks, but again, a reflash would remedy any problem.

7.2 Compromising privacy: We have not exposed in the UI the ability to mark entries as private; it is used in some limited circumstances, giving some evidence that the underlying mechanism is working.

7.3 Damaging the user's data: System files are well protected from benign user Activities (with the exception of Terminal and Journal), but there is as yet no substantive protection for user files.

7.4 Doing bad things to other people: We as yet have no communications security; Activities can be spoofed--we are not yet able to sign activities, but this remains a goal; the running system is not yet well protected.

7.5 Impersonating the user: We've not yet implemented an authenticated identity service. We do have public keys, but not a secure path to using them.

Protections (Chapter 8):

8.1 P_BIOS_CORE: Yes.

8.2 P_BIOS_COPY: ??

8.3 P_SF_CORE: Safe from benign Activities (Journal and Terminal and malicious activities masquerading as the Journal or as Terminal remain risks)

8.4 P_SF_RUN: Reflash is the current best option.

8.5 P_NET: Prototyped, but needs more investigation (See http://cr.yp.to/unix/disablenetwork.html for details)

8.6 P_NAND_RL: JFFS2 journaling, bad block detection, etc. prevents total Flash burnout.

8.7 P_NAND_QUOTA: Quotas for activity instances have been prototyped, but are not in Update.1

8.8 P_MIC_CAM: LED protection complete; Permissions included in developer builds, but not in release builds.

8.9 P_CPU_RL: Was prototyped, but not currently in any builds

8.10 P_RTC: Activities cannot update the RTC, but it is still accessible from the shell

8.11 P_DSP_BG: No

8.12 P_X: No

8.13 P_IDENT: No

8.14 P_SANDBOX: Yes

8.15 P_DOCUMENT: Infrastructure in place, but not implemented

8.16 P_DOCUMENT_RO: No

8.17 P_DOCUMENT_RL: No

8.18 P_DOCUMENT_BACKUP: Actively being worked on.

8.19 P_THEFT: Qualified yes. Has some dependencies on reliable network access to make this practical. NNTP protections are not in place. Active Kill not on the current roadmap

8.20 P_SERVER_AUTH: Same caveat about UUID access to local filesystem; OpenID work is has not been implemented

8.21 P_PASSWORD: Not exposed to the UI