このページは、OLPCチームによってチェックされています。

翻訳された OLPC Bitfrost	原文
english \| español \| 日本語 +/-	変更

This is an on-going translation

System security on the One Laptop per Child's XO laptop

The Bitfrost security platform

我々はこの文書に関してのフィードバックなどを心から歓迎しており、特に次のフィードバックURLで登録することができる公衆のOLPC security mailing list (OLPCセキュリティ・メーリングリスト)をお勧めします。もし、コメントをプライベートにすることを強く好む場合は、書き置いてある著者のメールアドレス宛に連絡を取ってください。(もっと詳しい連絡先とメタデータはCredits(提供者)をご覧ください。)

これはスペックの最終バージョンではありません。この文書の内容はこれを今書いている時点でOLPCのセキュリティに関する思想を正確に考慮しています。しかし、生産の前にセキュリティモデルのある部分は変わるかもしれません。この文書はその様な変更を取り入れるためにアップデートされます。文書の最新バージョンはバージョン本家URLで見つける事ができます。

Introduction

Foreword

1971年にAT&Tの二人のプログラマー、Ken Thompson (ケン・トンプソン)とDennis Ritchie (デニス・リッチー)が初バージョンのUNIX(ユニックス)をリリースしました。そのオペレーティングシステムは1969年にUNICS(ユニックス)として収入なしのボランティアプロジェクトから始まりました。プログラマー達がテキストプロセッシング・サポートを加える申し出をした時に名前の変更とBell Labs (ベル・ラブス)からの正式な財政援助を得ました。UNIXの大まかなデザインの思いつきは現代まで残っています。人気のあるLinux (リナックス)、FreeBSD (フリーBSD)などのサーバ・オペレーティングシステムや、その他の様々なシステムは基本的に同じUNIX (ユニックス)のデザインを共用しています。

1971年バージョンのUNIX (ユニックス)はuser files (ユーザファイル)で以下のsecurity permissions (セキュリティパーミッション)をサポートしていました。

non-owner (ノンオウナー／非保有者)はファイルを'change'(チェンジ／変更)できる (write) (ライト／書き込み)
non-owner (ノンオウナー／非保有者)はファイルが'read'(リード／読む)できる
owner (オウナー／保有者)はファイルを'change'(チェンジ／変更)できる (write) (ライト／書き込み)
owner (オウナー／保有者)はファイルが'read'(リード／読む)できる
ファイルは'execute' (エクセキュート／実行)できる
ファイルは'set-uid' (setuid／セット・ユー・アイ・ディー)にする

これらのパーミッションはよく見たことがあるでしょう。その理由は、現在ユーザが使うオペレーティングシステムの上での、ファイルにセットできるセキュリティ・パーミッションにそっくりだからです。このパーミッションであまり信じられなくて大変心配なのは、それが昔から現在まで変わりなく、個人ドキュメントの上でユーザが手元に持っているほぼ唯一のコントロールメカニズムだからです。ユーザは同じシステムを共用する他のユーザからファイルを守る事はできますが、自分のプログラムがファイルでいったい何ができるとかのコントロールはまったくありません。

それは1971年には承知されたでしょう: ウェブが現れる20年前でしたし、ほとんどのコンピュータユーザに当てはまる脅威モデルも今とは全く違っていました。だが、しかし、我々の守りが35年間の間に何も変わっていない状態なので、未だにウィールスやマルウェアを止められないのは当然ではないでしょうか？

問題の原因はユーザの名で実行される全プログラムがユーザとまったく同じ機能と特権で実行されることです。 1971年は初のinternational packet-switched network(インターナショナル・パケットスイッチ・ネットワーク)が現れる7年前でした。そして、現在のインターネットが使うコミュニケーション・スーツTCP/IP (ティー・シー・ピー・アイ・ピー)を活用したwide-area network(ワイドエリア・ネットワーク)は1983年まで作られませんでした。これは我々がここで話すトンプソンとリッチーがデザインしたファイルパーミッションから12年後の出来事です。結論的に言うと、1971年ではアカウント保有者のユーザオウナーが肉体的に（例えば、パンチテープで）ファイルを移動するか、または手動で入力しない限りプログラムはコンピュータに存在する事は想像としてもありえませんでした。そのため、実行するプログラムが保有者のアカウントを全体的にコントロールすることできる、例えば、ユーザが実行するコードは実用性のためあらかじめ信用されるとかの"all or nothing"(すべてが無かの)タイプのセキュリティに対するアプローチが結果的に良識されることになったでしょう。

舞台を現代へ変えてみましょう、事態は極端に違っています。最も対照的なのは多分ユーザが尋ねる殆どのウェブページに置ける'untrusted scripting code'(アントラステッド・スクリプトコード／不信用スクリプトコード)がウェブブラウザによって実行される、ウェブの上でしょう。ブラウザはますますその様なウェブスクリプトの機能を制限する複雑なサンドボックス・システムになっています。しかし、未だに最新バージョンのブラウザはスクリプトエンジンの実装でバグフィックスを行っています。Ｅメールのことも忘れないでください。だれでもユーザ宛に実行ファイルを送りつけることができます。長い間、ユーザの本能的な行動はアタッチメントを開いてプログラムを作動することでした。'Untrusted code'(アントラステッド・コード／不信用コード)はあっちこっちにあり、唯一の防御方は退屈なユーザトレーニングとアンチウィールスだけなようです。後のアンチウィールスに関しては、それがアップデートされており、さらにアンチウィールスメーカーが各新登場ウィールスの分析をして対策を作る時間がある設定を予想した事情の上での話です。

Bitfrost(ビットフロスト)を構成するほとんどのテクノロジーは独特のリサーチではありません。それらは、セキュリティ関係の著述ではよく知られていますし、ある物はすでに実際の場で運用されており、研究所でテスト中の物もあります。OLPC XOラップトップに注目を集めるのは、初めてそれらのセキュリティ対策が十及び何百万人ものユーザを対象に使われるシステムで慎重に纏めて導入されることです。そして、そのラップトップは初めてメインストリームのコンピュータが、強いセキュリティを得るためにレガシープログラムへの互換性を自ら進んで諦めた例かもしれません。例として、アンチウィールスやアンチスパイウェア対策テクノロジーの話がビットフロスト・スペックから目立つように不在であるのに気づくでしょう。その理由は、XOラップトップのセキュリティプラットフォームがその様な問題をムート(議論必要なし)にするからです。

我々は、他の今、マーケットに出ているすべてのメインストリームシステムよりも大幅にセキュアで、大幅に上回るセキュリティでのユーザビリティ(使いやすさ)の両方を装備したシステムの構成を目指しました。ユーザビリティ(使いやすさ)へ取り込んだ一つのいいことは、ビットフロストのプラットフォームでユーザから応答が必要なプロテクションをただ一つに絞ることが出来たことです。その上でも、童子にでも理解できる、単なる'yes or no'(ハイかイイエ)の質問です。残りのセキュリティは目に見えない所で備えられています。しかし、セキュリティとユーザビリティ(使いやすさ)の両方を目指すにも限界があり、ここで本文の最終章でも繰り返して語るとても大切なことは、我々は決して"perfectly secure"(完璧なセキュリティ)などは作ろうともしなかったし、そのようなシステムが作られたとも信じてはいません。現実の世界で'perfect security'(完璧なセキュリティ)を完成させるなどのような考えはあまりにもばかげているので、そのような下らない主張からはきっぱりと遠ざかります。

Security and OLPC

セキュリティの上でOLPC XOラップトップはとてもユニークな環境にあります。それらは幼い子供たちに紹介される予定で、そのユーザの多くはコンピュータやインターネットなどに降れたことのない環境にいます。

その上、OLPCはマシンやその使用上でセキュリティ問題の際にすぐに対応できる小スケールのローカル配備をターゲットにしているのではなく、代わりに、いったんマシンが野性の世界へリリースされた後はセキュリティモデルの思い切った変更は難しいか不可能だと検討した方がいいでしょう。

マシンをロックダウンする経験はコーポレートやアカデミックの環境でよく存在します。しかしOLPCは現在にあるほとんどの一般知識を無効にする最後の制限があります。それは、OLPCは子供などが自分のマシンを自由自在に改造、カスタマイズ、そして、ハックすることが出きるよう、デザイン的に著しく順応性のあるプラットフォームを目指しているからです。

その結果、コンピュータのセキュリティポリシーは一つも我々の要求を満たす物がありません。代わりに、最年少ユーザにも当てはまり、利用できるプロテクションの中で最も最強を調達できる厳重なセキュリティポリシーをディフォルトに与えて出費します。しかしながら、ユーザがマシンにどれだけハックするかの興味に応じたセキュリティレベルの調節を可能にするため、関心あるユーザがその様なプロテクションをどれでも解除できるシンプルなグラフィカルインターフェースを用意します。

このアプローチはディフォルトで高セキュリティを可能にして、デジタルセキュリティの理解がないユーザでも守ってあげることができます。同じ時に、徐々に洗練していき、自分のマシンを取り扱う能力を上げようとしているユーザの妨げにもならないようにしています。

最後に、我々は'constructionist learning theories'(構成主義学習理論)に加入しているため、すべての子供たちがその内マシンをもっと自由に扱える洗練されたユーザレベルまで進むことを支援して行きたいです。しかしながら、被害を受ける可能性が存在する限り、(例、マシンが全然作動しなくなるとか、全データ損失を受けるなど) その可能性はこの進行に強い制止を与えることになります。そのせいで、ディフォルトセキュリティに集中するその上に、例えば、オペレーティングシステムをマルチソースからリカバーするとか、セントラルサーバへのバックアップなどの、損失からのささいなく恐ろしくない回復メカニズムの供給にも明白的に集中しています。

About this document

このドキュメントはラップトップが工場で生産され、そして、初めて子供に届けられ、その子供がラップトップを使い、最後に子供がラップトップを排除する意志を出す瞬間までの全ライフサイクルをカバーしています。全内容はshort section on our goals and principles(我々の目標や原理に付いての短いセクション)から始まり、なぜ我々が普通のラップトップやデスクトップマシンのセキュリティ上で、あまり明白ではない発想として受け止められるかもしれない様々な決断を出した理由の背景をお伝えする役目をします。

この文書はあまりテクニカル的に説明はしていませんがOLPCセキュリティモデルに関しては完全であります。この文書を補うために書かれた完全なるテクニカルな説明とコメントを揃えた別の説明書はただ今準備されている最中です。

Principles and goals

Principles

Open design (オープン・デザイン): ラップトップのセキュリティはハードウェアとソフトウェアの上での秘密性には絶対に頼らない。

No lockdown (ロックダウンなし): ディフォルトセッティングでラップトップのセキュリティシステムはユーザに様々な制限をユーザの行動に対してつけ加えますが、セキュリティシステムを解除する方法は必ず必要です。その場合、マシンは全コントロールをユーザに返します。

No reading required (読書必要なし): セキュリティはユーザのコンピュータから来るメッセージの正しい解読能力、そして、それを元に知識的で賢い行動をとる能力に頼ることはできない。セキュリティメカニズムを解除する時は、なにかを読まないといけませんでしょうが、まだ読むことができないユーザに与えれるマシンは出費される前からセキュアであるべきです。

Unobstrusive security (アンオブストリュシブ・セキュリティ／慎ましいセキュリティ): セキュリティはできるだけ裏で行われます。かすかな表示や音のヒントだけでその存在にやっと気づく程度で、決してユーザの邪魔にはなりません。ユーザの少しの便利さとの衝突の場合は、強いアンオブストリュシブ・セキュリティの方が優先になります。けど、そのような手配がひどく、または、派手にマシンの使いやすさを減らさないよう十分に気をつけなければなりません。例えば、もしプログラムがセキュリティセッティングを破ろうとしているなら、ユーザには行動を許可する確認は現れなく、ただ静かに拒否されます。もし、ユーザが行動に許可を与えたいなら、グラフィカルなセキュリティセンター・インターフェースを通して設定を変えることができます。

Goals

No user passwords (ユーザパスワード不必要): ユーザの年齢は5歳も満たない子供も対象にしているため、セキュリティの上でユーザがパスワードを覚える能力をあてにすることはできません。ユーザが最初にラップトップを受け取る時にパスワードの設定をするなどの行動は期待できないでしょう。

No unencrypted authentication (非暗号化された認証なし): ラップトップやユーザの認証はネットワークの上で非暗号化された状態で受信した識別子には頼らない。つまり、OLPCプロトコルでは、どんな所でも'cleartext passwords'(クリアテキスト・パスワード／可読テキスト・パスワード)は一切使わず、イーサネットMACアドレスは決して認証には使われません。

Out-of-the-box security (箱から出た状態でセキュリティ): ラップトップはセキュリティアップデートとかをダウンロードする必要なしで、箱から出た状態でセキュアでかつ有用でなければなりません。

Limited institutional PKI (リミテッド・インスティツーショナル・PKI|ピーケイアイ／限られた機関公開鍵基盤): ラップトップの公開鍵はOLPCと国家または地方自治区(例、文部省、教育省)が調達します。だが、これらの鍵はラップトップユーザの身分証明には使われません。このような鍵の唯一の目的は一緒に含まれたソフトウェアとコンテンツの'integrity'(インテグリティ／データの安全性)を検証するために使用されます。ユーザの認証は'certified chain of trust'(サーティファイド・チェイン・オブ・トラスト／認定信頼チェーン)なしの有機的に作られたPKIを通して行われます。すなわち、我々のPKIへのアプローチはKCM (ケーシーエム)、または、'key continuity management'(キー・コンティニュイティー・マネージメント／鍵継続管理)です。

No permanent data loss (ノー・パーマネント・データロス／永久的データ破損なし): ラップトップの中にあるデータは、もし、生徒がラップトップをなくしたり、盗まれたり、または、破壊された時にデータの回復を可能にするために、なんらかの'centralized storage place'(セントラライズド・ストレージ・プレース／中央記憶場所)にレプリケートされます。

Factory production

工場生産でビルトインされた'SPI flash chip'(SPI|エスピーアイ・フラッシュチップ)に一定の生産データが書き込まれています。そのチップは書き換え可能ですが、ハードウェアいじりをする意外は生産情報を破壊及び変更できない信用されたプロセスだけが書き換えすることができます。

生産データは二つのユニークな識別子があります：'SN'シリアル番号と'U#'ランダムに作られたUUID (汎用一意識別子)です。シリアル番号は順序正しく割り当てられてはいません。代わりに、整数のプールからランダムに選ばれています。生産プロセスはランダムシリアル番号と、最初に生産したラップトップは'1'とセットさた、実際のインクリメントするシリアル番号のマッピングをおこないます。このマッピングは機密ではありますが秘密ではなく、OLPCが保管しています。

ランダムマッピングの唯一の目的はシリアル番号を使って各国家の仕入れ量を分析する試みを阻止するためにあります。

ラップトップのUUID、'U#'はランダム32バイトのプリンタブルASCII識別子です。

ラップトップ生産後の診断ステージの一つで、診断ツールが全'U#'と'SN'と工場情報を含めた生産情報をOLPCサーバへおくります。この情報は万が一の接続性問題のために工場で持ち行列に並び、予想している事情内で失うことはまったくありません。

生産ラインの終わりでラップトップは'deactivated'(ディアクティベート／無効状態)にあります。その訳で、ユーザが使う前に発動時で'cryptographic activation process'(暗号アクティベーションプロセス／暗号発動プロセス)を行わないといけません。

Delivery chain security

OLPCはラップトップの出費をもとの製造工場から各国家までしか手配しません。各国家内の出費と調達はその国が受け持ちます。

OLPC生産量を仮定すると、進取の気性がある泥棒にとって配達チェーンは魅力のある攻撃ベクターになります。アクティベーション必要性は再販売する際に各個のラップトップでハードウェアいじりを行う必要があるので配達物盗みはあまり魅力的ではありません。下記にアクティベーション・プロセスの概略を説明します。

Arrival at school site and activation

各学校へラップトップがバッチとして出費される前に、国はOLPCが提供するソフトウェアを使いアクティベーションコードを生成します。この'activation list'(アクティベーション・リスト)は各(SN, UUID)タプルを参照されたラップトップのユニークなアクティベーション・コードへマップします。ラップトップが各学校宛にバッチとして分割されるときにアクティベーション・リストは各ラップトップ・バッチのために必要に応じてその国が生成します。ほかに言うとマスター・アクティベーション・リストはありません。

各ラップトップ・バッチのアクティベーション・リストはUSBドライブへロードされ、実際のラップトップ出費とは別のルートでターゲットする学校のプロジェクト'handler'(ハンドラー)へ配達されます。大抵の'handler'(ハンドラー)は先生か学校の管理人です。一つの学校へ送られたアクティベーション・リストで他のラップトップ・バッチを発動することはできません。

アクティベーション・リストUSBドライブが受け取られた時、それはOLPCが提供するスクール・サーバか、または、ワイヤレス・アクセス・ポイントに接続してそれなりのソフトウェアを走らせている別のサーバに差し込まれます。この役目を果たすサーバはどちらでも構わなく'activation server'(アクティベーション・サーバ)と呼ばれます。もし必要があれば発動されたXOラップトップもこの目的のために使うことができます。

それぞれの一致したラップトップ・バッチを受け取った後、学校のプロジェクト・ハンドラーは学校にいる子供たちにラップトップを手渡す作業の責任をとります。ラップトップは子供が受け取る時はまだ動作でないようになっています。子供がしないといけないのは、学校のアクティベーション・サーバのワイヤレス範囲内でラップトップの電源をつけることです。それが起こるとき、ラップトップはサーバに(SN, UUID)タプルをセキュア通信で伝え、タプルがアクティベーション・リストで探し出すことができるなら、サーバは対象になるラップトップに正しいアクティベーション・コードを返し、そうでなかったらエラーを返します。

無効なアクティベーション・コードか、また、エラーの場合ラップトップは次に発動できる前に1時間眠ります。もしアクティベーション・コードが有効だとラップトップは発動し'first-boot'(ファースト・ブート)スクリーンへブートします。もしマシンがなにかの理由で動作しないときは手動でテキスト・アクティベーション・コードを記入することもできます。

First boot

ファースト・ブートの際、プログラムは子供から名前を聞いた後に顔写真をとり、裏でECC key pair(ECCキー・ペア)を生成します。初めにキー・ペアはパスフレーズでは守られてはいなく、子供の名前と顔写真のサインに使われます。この情報とサインは子供の'digital identitiy'(デジタル・アイデンティティ／デジタル身分証明)となります。

ラップトップは(SN, UUID, digital identity(デジタル・アイデンティティ／デジタル身分証明))タプルをアクティベーション・サーバへ受信します。ラップトップとユーザのアイデンティティのマッピングは泥棒対策のために国か地方自治区が管理しますが、決してOLPCには届きません。

その後ラップトップは全セキュリティ・セッティング有効で普通にブートされます。

Software installation

There is a very important distinction between two broad classes of programs that execute on a running system, and this distinction is not often mentioned in security literature. There are programs that are purposely malicious, which is to say that they were written with ill intent from the start, such as with viruses and worms, and there are programs which are circumstantially malicious but otherwise benign, such as legitimate programs that have been exploited by an attacker while they're running, and are now being instrumented to execute code on behalf of the attacker via code injection or some other method.

This difference is crucial and cannot be understated, because it's a reasonable assumption that most software running on a normal machine starts benign. In fact, we observe that it is through exploitation of benign software that most malicious software is first introduced to many machines, so protecting benign software becomes a doubly worthy goal.

The protection of benign software is a keystone of our security model. We approach it with the following idea in mind: benign software will not lie about its purpose during installation.

To provide an example, consider the Solitaire game shipped with most versions of Microsoft Windows. This program needs:

no network access whatsoever
no ability to read the user's documents
no ability to utilize the built-in camera or microphone
no ability to look at, or modify, other programs

Yet if somehow compromised by an attacker, Solitaire is free to do whatever the attacker wishes, including:

read, corrupt or delete the user's documents, spreadsheets, music, photos and any other files
eavesdrop on the user via the camera or microphone
replace the user's wallpaper
access the user's website passwords
infect other programs on the hard drive with a virus
download files to the user's machine
receive or send e-mail on behalf of the user
play loud or embarassing sounds on the speakers

The critical observation here is not that Solitaire should never have the ability to do any of the above (which it clearly shouldn't), but that its creators know it should never do any of the above. It follows that if the system implemented a facility for Solitaire to indicate this at installation time, Solitaire could irreversibly shed various privileges the moment it's installed, which severely limits or simply destroys its usefulness to an attacker were it taken over.

The OLPC XO laptops provide just such a facility. Program installation does not occur through the simple execution of the installer, which is yet another program, but through a system installation service which knows how to install XO program bundles. During installation, the installer service will query the bundle for the program's desired security permissions, and will notify the system Security Service accordingly. After installation, the per-program permission list is only modifiable by the user through a graphical interface.

A benign program such as Solitaire would simply not request any special permissions during installation, and if taken over, would not be able to perform anything particularly damaging, such as the actions from the above list.

It must be noted here that this system only protects benign software. The problem still remains of intentionally malicious software, which might request all available permissions during installation in order to abuse them arbitrarily when run. We address this by making certain initially-requestable permissions mutually exclusive, in effect making it difficult for malicious software to request a set of permissions that easily allow malicious action. Details on this mechanism are provided later in this document.

As a final note, programs cryptographically signed by OLPC or the individual countries may bypass the permission request limits, and request any permissions they wish at installation time.

Software execution: problem statement

The threat model that we are trying to address while the machine is running normally is a difficult one: we wish to have the ability to execute generally untrusted code, while severely limiting its ability to inflict harm to the system.

Many computer devices that are seen or marketed more as embedded or managed computers than personal laptops or desktops (one example is AMD's PIC communicator) purport to dodge the issue of untrusted code entirely, while staving off viruses, malware and spyware by only permitting execution of code cryptographically signed by the vendor. In practice, this means the user is limited to executing a very restricted set of vendor-provided programs, and cannot develop her own software or use software from third party developers. While this approach to security certainly limits available attack vectors, it should be noted it is pointedly not a silver bullet. A computer that is not freely programmable represents a tremendous decrease in utility from what most consumers have come to expect from their computers—but even if we ignore this and focus merely on the technical qualifications of such a security system, we must stress that almost always, cryptographic signatures for binaries are checked at load time, not continually during execution. Thus exploits for vendor-provided binaries are still able to execute and harm the system. Similarly, this system fails to provide any protection against macro attacks.

As we mention in the introduction, this severely restricted execution model is absolutely not an option for the XO laptops. What's more, we want to explicitly encourage our users, the children, to engage in a scenario certain to give nightmares to any security expert: easy code sharing between computers.

As part of our educational mission, we're making it very easy for children to see the code of the programs they're running—we even provide a View Source key on the keyboard for this purpose—and are making it similarly easy for children to write their own code in Python, our programming language of choice. Given our further emphasis on collaboration as a feature integrated directly into the operating system, the scenario where a child develops some software and wishes to share it with her friends becomes a natural one, and one that needs to be well-supported.

Unfortunately, software received through a friend or acquaintance is completely untrusted code, because there's no trust mapping between people and software: trusting a friend isn't, and cannot be, the same as trusting code coming from that friend. The friend's machine might be taken over, and may be attempting to send malicious code to all her friends, or the friend might be trying to execute a prank, or he might have written—either out of ignorance or malice -- software that is sometimes malicious.

It is against this background that we've constructed security protections for software on the laptop. A one-sentence summary of the intent of our complete software security model is that it "tries to prevent software from doing bad things". The next chapter explains the five categories of 'bad things' that malicious software might do, and the chapter after that our protections themselves. And the chapter after it explains how each protection addresses the threat model.

Threat model: bad things that software can do

There are five broad categories of "bad things" that running software could do, for the purposes of our discussion. In no particular order, software can attempt to damage the machine, compromise the user's privacy, damage the user's information, do "bad things" to people other than the machine's user, and lastly, impersonate the user.

Damaging the machine

Software wishing to render a laptop inoperable has at least five attack vectors. It may try to ruin the machine's BIOS, preventing it from booting. It may attempt to run down the NAND chip used for primary storage, which—being a flash chip—has a limited number of write/erase cycles before ceasing to function properly and requiring replacement. Successful attacks on the BIOS or NAND cause hard damage to the machine, meaning such laptops require trained hardware intervention, including part replacement, to restore to operation. The third vector, deleting or damaging the operating system, is an annoyance that would require the machine to be re-imaged and reactivated to run.

Two other means of damaging the machine cause soft damage: they significantly reduce its utility. These attacks are performance degradation and battery drainage (with the side note that variants of the former can certainly cause the latter.)

When we say performance degradation, we are referring to the over-utilization of any system resource such as RAM, the CPU or the networking chip, in a way that makes the system too slow or unresponsive to use for other purposes. Battery drainage might be a side-effect of such a malicious performance degradation (e.g. because of bypassing normal power saving measures and over-utilization of power-hungry hardware components), or it might be accomplished through some other means. Once we can obtain complete power measurements for our hardware system, we will be aware of whether side channels exist for consuming large amounts of battery power without general performance degradation; this section will be updated to reflect that information.

Compromising privacy

We see two primary means of software compromising user privacy: the unauthorized sending of user-owned information such as documents and images over the network, and eavesdropping on the user via the laptops' built-in camera and microphone.

Damaging the user's data

A malicious program can attempt to delete or corrupt the user's documents, create large numbers of fake or garbage-filled documents to make it difficult for the user to find her legitimate ones, or attack other system services that deal with data, such as the search service. Indeed, attacking the global indexing service might well become a new venue for spam, that would thus show up every time the user searched for anything on her system. Other attack vectors undoubtedly exist.

Doing bad things to other people

Software might be malicious in ways that do not directly or strongly affect the machine's owner or operator. Examples include performing Denial of Service attacks against the current wireless or wired network (a feat particularly easy on IPv6 networks, which our laptops will operate on by default), becoming a spam relay, or joining a floodnet or other botnet.

Impersonating the user

Malicious software might attempt to abuse the digital identity primitives on the system, such as digital signing, to send messages appearing to come from the user, or to abuse previously authenticated sessions that the user might have created to privileged resources, such as the school server.

Protections

Here, we explain the set of protections that make up the bulk of the Bitfrost security platform, our name for the sum total of the laptop's security systems. Each protection listed below is given a concise uppercase textual label beginning with the letter P. This label is simply a convenience for easy reference, and stands for both the policy and mechanism of a given protection system.

Almost all of the protections we discuss can be disabled by the user through a graphical interface. While the laptop's protections are active, this interface cannot be manipulated by the programs on the system through any means, be it synthetic keyboard and mouse events or direct configuration file modification.

P_BIOS_CORE: core BIOS protection

The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in its section. This chip's purpose is to hold manufacturing information about the machine including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the stored BIOS is strictly controlled, in such a way that only a BIOS image cryptographically signed by OLPC can be flashed to the chip. The firmware will not perform a BIOS reflashing if the battery level is detected as low, to avoid the machine powering off while the operation is in progress.

A child may request a so-called developer key from OLPC. This key, bound to the child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she wishes, to accommodate the use case of those children who progress to be very advanced developers and wish to modify their own firmware.

P_BIOS_COPY: secondary BIOS protection

The inclusion of this protection is uncertain, and depends on the final size of the BIOS and firmware after all the desired functionality is included. The SPI flash offers 1MB of storage space; if the BIOS and firmware can be made to fit in less than 512KB, a second copy of the bundle will be stored in the SPI. This secondary copy would be immutable (cannot be reflashed) and used to boot the machine in case of the primary BIOS being unbootable. Various factors might lead to such a state, primarily hard power loss during flashing, such as through the removal of the battery from the machine, or simply a malfunctioning SPI chip which does not reflash correctly. This section will be updated once it becomes clear whether this protection can be included.

P_SF_CORE: core system file protection

The core system file protection disallows modification of the stored system image on a laptop's NAND flash, which OLPC laptops use as primary storage. While engaged, this protection keeps any process on the machine from altering in any way the system files shipped as part of the OLPC OS build.

This protection may not be disabled without a developer key, explained in P_BIOS_CORE section.

P_SF_RUN: running system file protection

Whereas #P_SF_CORE protects the stored system files, #P_SF_RUN protects the running system files from modification. As long as #P_SF_RUN is engaged, at every boot, the running system is loaded directly from the stored system files, which are then marked read-only.

When #P_SF_RUN is disengaged, the system file loading process at boot changes. Instead of loading the stored files directly, a COW (copy on write) image is constructed from them, and system files from that image are initialized as the running system. The COW image uses virtually no additional storage space on the NAND flash until the user makes modifications to her running system files, which causes the affected files to be copied before being changed. These modifications persist between boots, but only apply to the COW copies: the underlying system files remain untouched.

If #P_SF_RUN is re-engaged after being disabled, the boot-time loading of system files changes again; the system files are loaded into memory directly with no intermediate COW image, and marked read-only.

#P_SF_CORE and #P_SF_RUN do not inter-depend. If #P_SF_CORE is disengaged and the stored system files are modified, but #P_SF_RUN is engaged, after reboot no modification of the running system will be permitted, despite the fact that the underlying system files have changed from their original version in the OLPC OS build.

P_NET: network policy protection

Each program's network utilization can be constrained in the following ways:

Boolean network on/off restriction
token-bucketed bandwidth throttling with burst allowance
connection rate limiting
packet destination restrictions by host name, IP and port(s)
time-of-day restrictions on network use
data transfer limit by hour or day
server restriction (can bind and listen on a socket), Boolean and per-port

Reasonable default rate and transfer limits will be imposed on all non-signed programs. If necessary, different policies can apply to mesh and access point traffic. Additional restrictions might be added to this list as we complete our evaluation of network policy requirements.

P_NAND_RL: NAND write/erase protection

A token-bucketed throttle with burst allowance will be in effect for the JFFS2 filesystem used on the NAND flash, which will simply start delaying write/erase operations caused by a particular program after its bucket is drained. It is currently being considered that such a delay behaves as an exponential backoff, though no decision has yet been made, pending some field testing.

A kernel interface will expose the per-program bucket fill levels to userspace, allowing the implementation of further userspace policies, such as shutting down programs whose buckets remain drained for too long. These policies will be maintained and enforced by the system Security Service, a privileged userspace program.

P_NAND_QUOTA: NAND quota

To prevent disk exhaustion attacks, programs are given a limited scratch space in which they can store their configuration and temporary files, such as various caches. Currently, that limit is 5MB. Additionally, limits will be imposed on inodes and dirents within that scratch space, with values to be determined.

This does not include space for user documents created or manipulated by the program, which are stored through the file store. The file store is explained in a later section.

P_MIC_CAM: microphone and camera protection

At the first level, our built-in camera and microphone are protected by hardware: an LED is present next to each, and is lit (in hardware, without software control) when the respective component is engaged. This provides a very simple and obvious indication of the two being used. The LEDs turning on unexpectedly will immediately tip off the user to potential eavesdropping.

Secondly, the use of the camera and microphone require a special permission, requested at install-time as described in its chapter, for each program wishing to do so. This permission does not, however, allow a program to instantly turn on the camera and microphone. Instead, it merely lets the program ask the user to allow the camera or microphone (or both) to be turned on.

This means that any benign programs which are taken over but haven't declared themselves as needing the camera or microphone cannot be used neither to turn on either, NOR to ask the user to do so!

Programs which have declared themselves as requiring those privileges (e.g. a VOIP or videoconferencing app) can instruct the system to ask the user for permission to enable the camera and microphone components, and if the request is granted, the program is granted a timed capability to manipulate the components, e.g. for 30 minutes. After that, the user will be asked for permission again.

As mentioned in the chapter on installation, programs cryptographically signed by a trusted authority will be exempt from having to ask permission to manipulate the components, but because of the LEDs which indicate their status, the potential for abuse is rather low.

P_CPU_RL: CPU rate limiting

Foreground programs may use all of the machine's CPU power. Background programs, however, may use no more than a fixed amount—currently we're looking to use 10%—unless given a special permission by the user.

The Sugar UI environment on the XO laptops does not support overlapping windows: only maximized application windows are supported. When we talk about foreground and background execution, we are referring to programs that are, or are not, currently displaying windows on the screen.

P_RTC: real time clock protection

A time offset from the RTC is maintained for each running program, and the program is allowed to change the offset arbitrarily. This fulfills the need of certain programs to change the system time they use (we already have a music program that must synchronize to within 10ms with any machines with which it co-plays a tune) while not impacting other programs on the system.

P_DSP_BG: background sound permission

This is a permission, requestable at install-time, which lets the program play audio while it isn't in the foreground. Its purpose is to make benign programs immune to being used to play annoying or embarrassing loud sounds if taken over.

P_X: X window system protection

When manually assigned to a program by the user through a graphical security interface, this permission lets a program send synthetic mouse X events to another program. Its purpose is to enable the use of accessibility software such as an on-screen keyboard. The permission is NOT requestable at install-time, and thus must be manually assigned by the user through a graphical interface, unless the software wishing to use it is cryptographically signed by a trusted authority.

Without this permission, programs cannot eavesdrop on or fake one another's events, which disables key logging software or sophisticated synthetic event manipulation attacks, where malicious software acts as a remote control for some other running program.

P_IDENT: identity service

The identity service is responsible for generating an ECC key pair at first boot, keeping the key pair secure, and responding to requests to initiate signed or encrypted sessions with other networked machines.

With the use of the identity service, all digital peer interactions or communication (e-mails, instant messages, and so forth) can be cryptographically signed to maintain integrity even as they're routed through potentially malicious peers on the mesh, and may also be encrypted in countries where this does not present a legal problem.

P_SANDBOX: program jails

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.

Every program scratch space has three writable directories, called 'tmp', 'conf', and 'data'. The program is free to use these for temporary, configuration, and data (resource) files, respectively. The rest of the scratch space is immutable; the program may not modify its binaries or core resource files. This model ensures that a program may be restored to its base installation state by emptying the contents of the three writable directories, and that it can be completely uninstalled by removing its bundle (scratch space) directory.

P_DOCUMENT: file store service

Unlike with traditional machines, user documents on the XO laptop are not stored directly on the filesystem. Instead, they are read and stored through the file store service, which provides an object-oriented interface to user documents. Similar in very broad terms to the Microsoft WinFS design, the file store allows rich metadata association while maintaining traditional UNIX read()/write() semantics for actual file content manipulation.

Programs on the XO may not use the open() call to arbitrarily open user documents in the system, nor can they introspect the list of available documents, e.g. through listing directory contents. Instead, when a program wishes to open a user document, it asks the system to present the user with a 'file open' dialog. A copy-on-write version of the file that the user selects is also mapped into this scratch space—in effect, the file just "appears", along with a message informing the program of the file's path within the scratch space.

Unix supports the passing of file descriptors (fds) through Unix domain sockets, so an alternative implementation of #P_DOCUMENT would merely pass in the fd of the file in question to the calling program. We have elected not to pursue this approach because communication with the file store service does not take place directly over Unix domain sockets, but over the D-BUS IPC mechanism, and because dealing with raw fds can be a hassle in higher-level languages.

Benign programs are not adversely impacted by the need to use the file store for document access, because they generally do not care about rendering their own file open dialogs (with the rare exception of programs which create custom dialogs to e.g. offer built-in file previews; for the time being, we are not going to support this use case).

Malicious programs, however, lose a tremendous amount of ability to violate the user's privacy or damage her data, because all document access requires explicit assent by the user.

P_DOCUMENT_RO

Certain kinds of software, such as photo viewing programs, need access to all documents of a certain kind (e.g. images) to fulfill their desired function. This is in direct opposition with the #P_DOCUMENT protection which requires user consent for each document being opened—in this case, each photo.

To resolve the quandary, we must ask ourselves: "from what are we trying to protect the user?". The answer, here, is a malicious program which requests permission to read all images, or all text files, or all e-mails, and then sends those documents over the network to an attacker or posts them publicly, seriously breaching the user's privacy.

We solve this by allowing programs to request read-only permissions for one type of document (e.g. image, audio, text, e-mail) at installation time, but making that permission (#P_DOCUMENT_RO) mutually exclusive with asking for any network access at all. A photo viewing program, in other words, normally has no business connecting to the Internet.

As with other permissions, the user may assign the network permission to a program which requested #P_DOCUMENT_RO at install, bypassing the mutual exclusion.

P_DOCUMENT_RL: file store rate limiting

The file store does not permit programs to store new files or new versions of old files with a frequency higher than a certain preset, e.g. once every 30 seconds.

P_DOCUMENT_BACKUP: file store backup service

When in range of servers that advertise themselves as offering a backup service, the laptop will automatically perform incremental backups of user documents which it can later retrieve. Because of the desire to avoid having to ask children to generate a new digital identity if their laptop is ever lost, stolen or broken, by default the child's ECC keypair is also backed up to the server. Given that a child's private key normally has no password protection, stealing the primary backup server (normally the school server) offers the thief the ability to impersonate any child in the system.

For now, we deem this an acceptable risk. We should also mention that the private key will only be backed up to the primary backup server—usually in the school—and not any server that advertises itself as providing backup service. Furthermore, for all non-primary backup servers, only encrypted version of the incremental backups will be stored.

P_THEFT: anti-theft protection

The OLPC project has received very strong requests from certain countries considering joining the program to provide a powerful anti-theft service that would act as a theft deterrent against most thieves.

We provide such a service for interested countries to enable on the laptops. 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.

A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC oversight body in charge of the anti-theft service. The laptop will be marked stolen in the country's master database.

A thief might do several things with a laptop: use it to connect to the Internet, remove it from any networks and attempt to use it as a standalone machine, or take it apart for parts.

In the former case, the anti-theft daemon would learn that the laptop is stolen as soon as it's connected to the Internet, and would perform a hard shutdown and lock the machine such that it requires activation, described previously, to function.

We do not expect the machines will be an appealing target for part resale. Save for the custom display, all valuable parts of the XO laptops are soldered onto the motherboard.

To address the case where a stolen machine is used as a personal computer but not connected to the Internet, the anti-theft daemon will shut down and lock the machine if its cryptographic lease ever expires. In other words, if the country operates with 21-day leases, a normal, non-stolen laptop will get the lease extended by 21 days each day it connects to the Internet. But if the machine does not connect to the Internet for 21 days, it will shut down and lock.

Since this might present a problem in some countries due to intermittent Internet access, the leases can either be made to last rather long (they're still an effective theft deterrent even with a 3 month duration), or they can be manually extended by connecting a USB drive to the activation server. For instance, a country may issue 3-week leases, but if a school has a satellite dish failure, the country's OLPC oversight body may mail a USB drive to the school handler, which when connected to the school server, transparently extends the lease of each referenced laptop for some period of time.

The anti-theft system cannot be bypassed as long as #P_SF_CORE is enabled (and disabling it requires a developer key). This, in effect, means that a child is free to do any modification to her machine's userspace (by disabling #P_SF_RUN without a developer key), but cannot change the running kernel without requesting the key. The key-issuing process incorporates a 14-day delay to allow for a slow theft report to percolate up through the system, and is only issued if the machine is not reported stolen at the end of that period of time.

P_SERVER_AUTH: transparent strong authentication to trusted server

When in wireless range of a trusted server (e.g. one provided by OLPC or the country), the laptop can securely respond to an authentication challenge with its (SN, UUID) tuple. In addition to serving as a means for the school to exercise network access control—we know about some schools, for instance, that do not wish to provide Internet access to alumni, but only current students—this authentication can unlock extra services like backup and access to a decentralized digital identity system such as OpenID.

OpenID is particularly appealing to OLPC, because it can be used to perpetuate passwordless access even on sites that normally require authentication, as long as they support OpenID. The most common mode of operation for current OpenID identity providers is to request password authentication from the user. With an OpenID provider service running on the school server (or other trusted servers), logins to OpenID-enabled sites will simply succeed transparently, because the child's machine has been authenticated in the background by #P_SERVER_AUTH.

(For later implementation) P_PASSWORD: password protection

It is unclear whether this protection will make it in to generation 1 of the XO laptops. When implemented, however, it will allow the user to set a password to be used for her digital identity, booting the machine, and accessing some of her files.

Addressing the threat model

We look at the five categories of "bad things" software can do as listed in the corresponding chapter, and explain how protections listed in their chapter help. The following sections are given in the same order as software threat model entries in their chapter.

Damaging the machine

#P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from trusted sources. A child with a developer key may flash whichever BIOS she pleases, though if we are able to implement #P_BIOS_COPY, the machine will remain operational even if the child flashes a broken or garbage BIOS. Programs looking to damage the OS cannot do so because of #P_SANDBOX and #P_SF_RUN. Should a user with #P_SF_RUN disabled be tricked into damaging her OS or do so accidentally, #P_SF_CORE enables her to restore her OS to its initial (activated) state at boot time.

Programs trying to trash the NAND by exhausting write/erase cycles are controlled through #P_NAND_RL, and disk exhaustion attacks in the scratch space are curbed by #P_NAND_QUOTA. Disk exhaustion attacks with user documents are made much more difficult by #P_DOCUMENT_RL.

CPU-hogging programs are reined in with #P_CPU_RL. Network-hogging programs are controlled by policy via #P_NET.

Compromising privacy

Arbitrary reading and/or sending of the user's documents over the network is curbed by #P_DOCUMENT, while tagging documents with the program that created them addresses the scenario in which a malicious program attempts to spam the search service. Search results from a single program can simply be hidden (permanently), or removed from the index completely.

#P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches by software that purports to be a "viewer" of some broad class of documents.

#P_MIC_CAM makes eavesdropping on the user difficult, and #P_X makes it very hard to steal passwords or other sensitive information, or monitor text entry from other running programs.

Damaging the user's data

File store does not permit programs to overwrite objects such as e-mail and text which aren't opaque binary blobs. Instead, only a new version is stored, and the file store exposes a list of the full version history. This affords a large class of documents protection against deletion or corruption at the hands of a malicious program—which, of course, had to obtain the user's permission to look at the file in question in the first place, as explained in #P_DOCUMENT.

For binary blobs—videos, music, images—a malicious program in which the user specifically opens a certain file does have the ability to corrupt or delete the file. However, we cannot protect the user from herself. We point out that such deletion is constrained to only those files which the user explicitly opened. Furthermore, #P_DOCUMENT_BACKUP allows a final way out even in such situations, assuming the machine came across a backup server (OLPC school servers advertise themselves as such).

Doing bad things to other people

XO laptops will be quite unattractive as spam relays or floodnet clients due to network rate and transfer limits imposed on all non-signed programs by #P_NET. Despite the appeal of the XO deployment scale for spamming or flooding, we expect that a restriction to generally low-volume network usage for untrusted software—coupled with the great difficulty in writing worms or self-propagating software for XO machines—will drastically reduce this concern.

Impersonating the user

The design of the identity service, #P_IDENT, does not allow programs to ever come in direct contact with the user's cryptographic key pair, nor to inject information into currently-open sessions which are using the identity service for signing or encryption.

Miscellaneous

In addition to the protections listed above which each address some part of the threat model, permissions #P_RTC and #P_THEFT combine to offer an anti-theft system that requires non-trivial sophistication (ability to tamper with on-board hardware) to defeat, and #P_DSP_BG provides protection against certain types of annoying malware, such as the infamous 1989 Yankee Doodle virus.

Missing from this list

At least two problems, commonly associated with laptops and child computer users respectively, are not discussed by our threat model or protection systems: hard drive encryption and objectionable content filtering / parental controls.

Filesystem encryption

While the XO laptops have no hard drive to speak of, the data encryption question applies just as well to our flash primary storage. The answer consists of two parts: firstly, filesystem encryption is too slow given our hardware. The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC mode, using 100% of the available CPU power. This is about ten times less than the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4 increases encryption throughput to about 15 MB/s with large blocks at 100% CPU utilization, and is hence still too slow for general use, and provides questionable security. Secondly, because of the age of our users, we have explicitly designed the Bitfrost platform not to rely on the user setting passwords to control access to her computer. But without passwords, user data encryption would have to be keyed based on unique identifiers of the laptop itself, which lends no protection to the user's documents in case the laptop is stolen.

Once the Bitfrost platform supports the #P_PASSWORD protection, which might not be until the second generation of the XO laptops, we will provide support for the user to individually encrypt files if she enabled the protection and set a password for herself.

Objectionable content filtering

The Bitfrost platform governs system security on the XO laptops. Given that "objectionable content" lacks any kind of technical definition, and is instead a purely social construct, filtering such content lies wholly outside of the scope of the security platform and this document.

Laptop disposal and transfer security

The target lifetime of an XO laptop is five years. After this time elapses, the laptop's owner might wish to dispose of the laptop. Similarly, for logistical reasons, a laptop may change hands, going from one owner to another.

A laptop re-initialization program will be provided which securely erases the user's digital identity and all user documents from a laptop. When running in "disposal" mode, that program could also be made to permanently disable the laptop, but it is unclear whether such functionality is actually necessary, so there are no current plans for providing it.

Closing words

In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of the realm of Midgard, from venturing into Asgard, the realm of the gods. In effect, Bifröst is a powerful security system designed to keep out unwanted intruders.

This is not why the OLPC security platform's name is a play on the name of the mythical bridge, however. What's particularly interesting about Bifröst is a story that 12th century Icelandic historian and poet Snorri Sturluson tells in the first part of his poetics manual called the Prose Edda. Here is the relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur:

Then said Gangleri: "What is the way to heaven from earth?"

Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has it not been told thee, that the gods made a bridge from earth, to heaven, called Bifröst? Thou must have seen it; it may be that ye call it rainbow.' It is of three colors, and very strong, and made with cunning and with more magic art than other works of craftsmanship. But strong as it is, yet must it be broken, when the sons of Múspell shall go forth harrying and ride it, and swim their horses over great rivers; thus they shall proceed."

Then said Gangleri: "To my thinking the gods did not build the bridge honestly, seeing that it could be broken, and they able to make it as they would."

Then Hárr replied: "The gods are not deserving of reproof because of this work of skill: a good bridge is Bifröst, but nothing in this world is of such nature that it may be relied on when the sons of Múspell go a-harrying."

This story is quite remarkable, as it amounts to a 13th century recognition of the idea that there's no such thing as a perfect security system.

To borrow Sturluson's terms, we 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. We believe Bitfrost accomplishes this, though only once the laptops are deployed in the field will we be able to tell with some degree of certainty whether we have succeeded.

Credits

Author

Ivan Krstić
ivan AT laptop.org
One Laptop Per Child
http://laptop.org

Acknowledgments

Simson Garfinkel, a security consultant for OLPC, contributed to this document. This document also builds upon a growing body known as "HCI-SEC," the application of recent advances in the field of Human Computer Interaction to the important goals of computer security. More information about HCI-SEC can be found in the book "Security and Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in Garfinkel's PhD thesis, "Design Principles and Patterns for Computer Systems that are Simultaneously Secure and Usable" (MIT, 2005).

We acknowledge also a panel of reviewers that prefer to stay anonymous, who provided insightful comments and feedback on previous drafts of this document.

Metadata

Revision: Draft-19 - release 1
Timestamp: Wed Feb 7 00:50:57 UTC 2007
Feedback URL: http://mailman.laptop.org/mailman/listinfo/security
Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost

If the subject matter interests you, please join the OLPC security mailing list, share your thoughts, and join the discussion.

OLPC Bitfrost/lang-ja

Introduction

Foreword

Security and OLPC

About this document

Principles and goals

Principles

Goals

Factory production

Delivery chain security

Arrival at school site and activation

First boot

Software installation

Software execution: problem statement

Threat model: bad things that software can do

Damaging the machine

Compromising privacy

Damaging the user's data

Doing bad things to other people

Impersonating the user

Protections

P_BIOS_CORE: core BIOS protection

P_BIOS_COPY: secondary BIOS protection

P_SF_CORE: core system file protection

P_SF_RUN: running system file protection

P_NET: network policy protection

P_NAND_RL: NAND write/erase protection

P_NAND_QUOTA: NAND quota

P_MIC_CAM: microphone and camera protection

P_CPU_RL: CPU rate limiting

P_RTC: real time clock protection

P_DSP_BG: background sound permission

P_X: X window system protection

P_IDENT: identity service

P_SANDBOX: program jails

P_DOCUMENT: file store service

P_DOCUMENT_RO

P_DOCUMENT_RL: file store rate limiting

P_DOCUMENT_BACKUP: file store backup service

P_THEFT: anti-theft protection

P_SERVER_AUTH: transparent strong authentication to trusted server

(For later implementation) P_PASSWORD: password protection

Addressing the threat model

Damaging the machine

Compromising privacy

Damaging the user's data

Doing bad things to other people

Impersonating the user

Miscellaneous

Missing from this list

Filesystem encryption

Objectionable content filtering

Laptop disposal and transfer security

Closing words

Credits

Author

Acknowledgments

Metadata

Navigation menu

Search