2013-07-20

完全に秘密を守るコンピューターシステムを求めて

朝風呂に浸かりながら、今の私の知識を総動員して完全に秘密を守るコンピューターシステムを求めたらどうなるだろうかと、ぼんやりと考えていた。その内容を書きだしてみる。

今は政府や犯罪組織の諜報機関が暗躍する時代であるから、コンピューターシステムが利用者の秘密を守れるかどうかを考慮することはとても重要だ。たとえば、私が「もはやソフトウェア特許という害悪を日本から除くには、暴力革命しかない」などと考えて、その実行計画をコンピューターを使って以下のように練ったとする。

「日本の市町村の中で、ハーグ陸戦条約第25条に基づく無防備都市宣言を条例で定めようという動きがある。もし、実際にこのような条例を可決する市町村が出た場合、すぐさま安全ピンと果物ナイフとピストル型ライターで武装して侵攻する。すでに発した無防備都市宣言により、一切の抵抗なく、無血で占領できるはずである。占領後、すみやかに軍による暫定政権を発足させ、日本国から独立を宣言し、ソフトウェア特許を廃止させる」

おお、あくまで例文であり、私が本当に計画しているものではないが、我ながら何と恐ろしい計画だ。この緻密かつ完璧な計画がバレてしまったら、筆者は内乱罪で死刑になってしまうかもしれない。(もっとも、その前にこのような事態を可能にする条例を可決した地方議員に内乱罪が適用されるだろうが)。なんとかしてこの危険な計画書の存在を隠さねば。

あるいは、政府が国際条約、憲法、法律に反する行為をしている場合を告発する場合にも、セキュアなシステムは重要になる。

大原則として、セキュリティを重視した結果、使い勝手が悪くなってはならないということがある。使い勝手の悪いシステムを使わされる人間は、必ず楽をしようと考える。その結果、セキュリティがないがしろになる。したがって、このセキュアなシステムは、既存のコンピューターシステムと何ら変わりなく、人間にとっては通過的に使える必要がある。

この記事では、とくに物理的な攻撃に対して耐えるシステムを考える。ストレージ全体を暗号化しておけば、単にコンピューターが盗まれた場合、秘密を保てる。問題なのは、物理的な攻撃により、システムを改変された場合だ。これは、例えばキーロガーなどをひそかにしこみ、利用者が安全だと信じている環境の操作、たとえばパスフレーズ入力だとかを、ひそかに記録することができる。

ハードウェアは信用できない

本の虫: ハードウェアの信用

まずハードウェアだ。ハードウェアは信用できない。これは、ハードウェアを検証する方法がほぼ存在しないがためである。たとえ、設計図がすべて公開されていたとしても、現物のハードウェアが、設計図通りに製造されている保証がないためである。検証する準備だけでも、パッケージをひっぺがし、回路を走査型電子顕微鏡で撮影するところからはじめなければならない。しかもこれは検証する以前の検証環境の構築作業であり、検証ではない。

ハードウェアは信用できない。したがって、ハードウェアによるセキュリティに頼ってはならない。たとえば、HDDやSSDやUSBドライブのようなストレージハードウェア自体に備わった暗号機能は、使ってはならない。信用できないからである。ストレージには暗号文を渡すべきである。たとえストレージに悪意ある機能が仕掛けられていたとしても、暗号文ではどうしようもない。

ハードウェアは信用できないし、信用してはいけない。とはいえ、普通の個人は、専用Fabを所有していないし、シリコンに回路を刻めるほど器用な手先もしていない。したがって、やはり市販のハードウェアを使わなければならない。たとえバックドアが仕掛けられていても、悪用が難しいハードウェアと、悪用が簡単なハードウェアがある。たとえば、CPUにバックドアを仕掛けるのは難しい。その発動条件はどうするのか。例えばレジスタを特定の値にして特定の並びの命令を実行とかにするのか。それはかなりバレやすい。あるいは、内部にこっそりと不揮発メモリを組み込んでおいて、その値次第でバックドア発動条件を変えるような実装も考えられる。こちらは少し発見が厄介だ。

マザーボードは少し難しい。EFIでは、マザーボード自体に少量の不揮発メモリが内蔵されていることが規格上要求されている。したがって、マザーボードに不揮発メモリが組み込んであっても、あまり怪しまれない。フラッシュメモリの技術向上により、キーボードからの入力ぐらいなら、何年分も記録しておけるような量の不揮発メモリが組み込まれて、悪用されたならば脅威だ。そのようなマザーボードをしばらく使わせておき、後で回収してパスフレーズを調べるようなことが可能になってしまう。

プリンターは、一切信用してはならない。現状では、プリンターを所有するのは危険だ。なぜか。ほぼすべての現行のプリンターは、印刷に秘密のドットパターンをすりこませている。このドットパターンは、肉眼では確認できないほど微小だが、プリンターの固有番号や印刷日時といった情報をエンコードできるほどの情報量を持っている。したがって、プリンターとは、印刷物から、プリンターの個体が特定され、身元特定にもつながるハードウェアであり、セキュリティ上の脅威だ。また、プリンターのドライバーには不自由なバイナリブロブを必要とするものが多いのも危険だ。

バイナリブロブといえば、GPUも問題だ。バイナリブロブは、物理的なプロセッサーよりは検証が容易だとはいえ、やはり検証が難しいという点で脅威となる。利用にバイナリブロブ、とくにカーネルモジュールとして読み込まれるようなバイナリブロブが必要なハードウェアは避けなければならない。

ほとんどのセキュリティ上の対策は、ソフトウェアで行うべきである。ソフトウェアはハードウェアより検証がしやすい。たとえストレージやNICに悪意ある機能が実装されていたとしても、暗号文しか渡さず、またハードウェアから直接他のハードウェアを操作できなければ、それほどの害はない。

たとえハードウェアの実装に悪意がなかったとしても、実装が正しくない可能性がある。たとえば、IntelのSSDの暗号機能に不具合があり、実際には暗号化できていなかったとして、リコールされたことがある。

Intel, Kingston Issue SSD Recalls Due to Defective Encryption Chips

ハードウェアは検証だけでなく、修正もしにくいのだ。

さて、ソフトウェアについて考える前に、今一度、物理的な脅威について考えなければならない。コンピューター以外の脅威だ。

例えば、諜報機関は、読者のコンピューターを使う部屋に、盗聴、盗撮の装置を隠して設置するかもしれない。もしそのような装置が設置された場合、ディスプレイに映された内容や、キーボードの押し下げられたキー、あるいは声に出して唱えたパスフレーズが筒抜けになってしまう。コンピューターを使う前には、盗聴、盗撮の装置が仕掛けられていないか確認し、またそのような装置の死角となる場所で操作し、またみだりに秘密の内容を読み上げないように注意する必要がある。

ソフトウェア

ソフトウェアを考える上で問題になるのは、ハードウェアのファームウェアだ。現代の多くのハードウェアは、もはや単なる物理的な機械ではなく、動作にソフトウェアが必要になる。このようなハードウェアにROMや、あるいは書き換え可能なフラッシュメモリに格納されているファームウェア、あるいはハードウェアを使う際にOSから読み込ませないといけないファームウェアは、自由ソフトウェアであることが望ましい。しかし、現状では、ほとんどのファームウェアはバイナリブロブである。

さて、ようやくOSに入る。OSは当然、完全に自由なソフトウェアで構成されているべきである。ここで問題になるのは、誰を信用すべきかということだ。

OSのあらゆる部分を、全て自前で構築するのは非現実的だし、個人でできることではない。セキュリティアップデートに対応するだけで日が暮れてしまい、コンピューターを使っての作業に割ける時間がなくなってしまう。したがって、誰か他人の手で保守されているシステムに頼るべきだ。世の中には、すべてを利用者の環境でコンパイルする電力の無駄遣いなGNU/Linuxベースのディストロや、あるいは利用者に設定ファイルを書かせて詳細に設定させる漢らしいGNU/Linuxベースのディストロもある。しかし、これらとて、やはり他人が提供するシステムであり、結局誰か他人を信頼しなければならないことに変わりはない。

ストレージすべては、LUKSとLVMのような、通過的な仕組みを使って、全体を暗号化するべきだ。特定のディレクトリだけ、特定のファイルだけの暗号化ではだめだ。なぜなら、そのような個別の暗号化は煩わしく、利用者に楽をさせたがる理由を与えてしまうからだ。利用者に何も明示的に行動させない、通過的な暗号化が好ましい。

さらに、OSを構成するプログラムデータを暗号化しないということは、たとえば諜報機関にOSの一部を差し替える攻撃を許してしまう。コンピューターの設置されている場所にひそかに侵入し、こっそりとカーネルやシェルやテキストエディターのような重要なプログラムを差し替える。これにより、利用者による操作をこっそりと記録する。あとでコンピューターを盗めば、記録からパスフレーズから秘密の計画から何でも筒抜けだ。したがって、ストレージ全体を暗号化する必要がある。

GNU/LinuxベースのOSで、ストレージ全体の暗号化をする際に、唯一暗号化できないのが、/bootだ。これは現在のハードウェアの都合上、どうしようもない。ただし、/bootは非常に小さいため、容易にハッシュチェックを行える点が救いだ。

また、セキュアブートの仕組みを使い、マイクロソフト鍵とマザーボードベンダーによって出荷時に設定された鍵を無効化し、自前の鍵を登録し、OSをすべて自前の鍵で署名するという方法もある。これは、ハードウェアとファームウェアがセキュアブートを正しく実装していれば、だいぶ効果的だ。ただし、これは物理的なアクセスへの対策にはならないので、あまり意味はない。

あるいは、/bootをコンピューターに常時接続するストレージには格納しないという方法もある。たとえば、/bootはUSBメモリーに格納しておき、コンピューターを起動する際には、そのUSBメモリーを使う。こうすれば、諜報機関がコンピューターに物理的にアクセスして、/bootを改変するという攻撃を防ぐことができる。このUSBメモリーは首から下げ、あるいはパンツの中に入れるなどして、メシを食ってようとクソしてようと、常に肌身離さず保管すること。

その他の身の安全を図る手段

国家の悪事を内部告発する者は、常に不当不法な方法で処分されてきた。特にそのような始末から身の安全を図るための方法も考えておくべきだ。

異性との接触を避ける

過去の多くの内部告発者が、異性と接触しているという点で避難されてきた。「ひそかに情を通じ、これを利用して」というわけだ。異性との接触は生殖活動に必須であり、全員が行う必要はないとはいえ、種としての人間を絶滅させないためには、誰かが行わなければならない行為であるはずなのだが、なぜか異性との接触が出てきた時点で、その内部告発者の他の面や、内部告発の内容が完全に無視され、そのことのみに注目が集まることが多い。また、異性との接触を理由にした逮捕監禁が、非常に多く行われている。

このため、安全のために、我々は異性との接触を避けなければならない。もし、異性が強引に接触を試みてきた場合、諜報機関の手先だとみなし、全力で逃走しなければならない。また、録画、録音のような証拠も残すべきだろう。

暴露できる秘密の可能性を残す。

多くの内部告発者は、いざという時のために、爆弾を残している。まだ暴露しない秘密を保有し、もし自分の身に何かが起こった場合は、秘密が暴露される仕組みを作り上げている。もしハッタリでなければの話だが。

これを可能にするには、秘密爆弾を暗号化して公開し、複合鍵を信頼できる他人に預ける。その他人は、自分の身に何かが起こった場合、少なくとも複合鍵を世間一般に公開出来るだけの時間的猶予を持つものでなければならない。

もし、自分の身に何かが起こる前に複合鍵を公開されたくないが、そこまでの信頼に足る人物がいない場合、秘密共有の仕組みを使い、鍵を分散することもできる。複合鍵を秘密共有で暗号化し、その秘密共有鍵を3人に託し、三人の鍵が揃わなければ複合鍵が得られないようにするとか、10人に託し、その内の任意の5人の鍵が揃わなければ複合鍵の暗号が解けなかったりという仕組みにできる。

このような秘密共有の自由なソフトウェアによる実装として、ssss: Shamir's Secret Sharing Schemeがある。Debianならパッケージ化もされており、apt-get install ssssでコンパイル済みのバイナリをインストールできる。このソフトウェアはその名の通り、Shamirという人が考案した数学的に機能する秘密共有の仕組みを実装したものだ。

以上、色々と妄想はしてみたものの、どうもあるxkcdの話が思い出されてならない。5ドルのレンチはどこに売っているのだろうか。

本の虫: xkcd: セキュリティ

xkcd: Security

暗号ヲタの妄想:
「奴のラップトップは暗号化されてやがる。百万ドルのクラスタ組んで解読しようぜ」
「いやダメだ。これは4096bit RSAだ」
「クソ、我々の邪悪な計画もここまでか」

現実に起こりうること:
「奴のラップトップは暗号化されてやがる。パスワード吐くまで、この5ドルのレンチで傷めつけてやれ」
「了解」

2 comments:

  1. 「セキュリティ上で最も脆いのは人間である。」という当たり前の結論になりましたね。

    ReplyDelete
  2. その一文だけでよかったかもしれません。

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.