Brigham Young UniversityのPhillip Hellewellが「[PATCH 0/12: eCryptfs] eCryptfs version 0.1」と題した、13部に分かれたPatchをLKMLにポストした。２００５年１１月２日のことである。最初のメールには、Patchではなくメッセージが書かれていた。
eCryptfs version 0.1
このパッチセットは、eCryptfsのバージョン0.1を構成するものである。我々はこれを、カーネルへ取り込みについてレビューを良くして貰うために、提示している。
eCryptfsは、スタック可能なファイルシステムである。Erez Zadokによって書かれたhttp://filesystems.org/のFiST(Stackable File System Language and Templates)で作られたCryptfsに基づいている。
eCryptfsは各ファイルのヘッダに暗号化のメタデータを格納する。このヘッダはOpenPGPのようなパケットを含んでいる(RFC 2440を参照)。これは、元々暗号化されているファイルの、ホスト間でのをコピーを可能にする。また、ファイル解読に必要な情報はすべて、ファイル自身に持たせている。eCryptfsは、利用者がファイルアクセスに必要なキーやパスフレーズを持つ限り、個々のファイルの暗号化と復号化を、ユーザスペース・アプリケーションに対して完全透過にすることを目的にしている。
Michael Halcrowは、2004年と2005年のオタワでのLinuxシンポジウムで、eCryptfsのプレゼンテーションを行った。今年のシンポジウム議事録の209ページ目から、かなり高度な全体説明を掲載している。（訳注：前々回のオタワのシンポジウムの議事録も参照可能である。Demands, Solutions, and Improvements for Linux Filesystem Securityというタイトルである）
このパッチセットは、今年の初めにLKMLに送ったeCryptfsよりも、かなりスリム化したバージョンであることに注意して欲しい。リリース0.1では、マウント全体に渡るpassphraseだけをサポートしている。これは、より高度なポリシーと公開鍵機能をマージする前に、eCryptfsを分析し、あるいはデバッグすることを簡単にする。
eCryptfsは、FSX(fsx NFS test)とConnectathon(Connectathon NFS Testsuite)(それぞれNFSの基本的、一般的な機能をテストするツール)を含む様々なテストの元で、まことに見事な実行ぶりを示すが、カーネルコンパイル時に発生するバグがある。我々は、VFS(Virtual FIle System)の権威者たちが与えてくれるような、何らかの残りのバグを追跡、あるいは修正できるあらゆる見識を評価するだろう。
eCryptfsはDavid Howellsの keyring を利用する。eCryptfsバージョン0.1は、マウント時に、ユーザセションの keyring にある、既存の認証トークンを期待している。これを行うコードを含んでいるtarballは、eCryptfsのSourceForgeサイト(ecryptfs-v0_1.tar.bz2)から入手可能である:
将来のリリースでは、ポリシーのサポートを持たせるだろう。それは必然的に、ファイルごとのpassphraseとファイルごとの公開鍵サポートを伴うことになるだろう。そのようなコードに興味を持っている人に対しては、SourceForgeの上のeCryptfs CVSのリポジトリで以下のように入手することを歓迎している。
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ecryptfs co -P ecryptfs
暗号化ファイルシステムのいろいろ
ここまで読んで、すでに過去あるのと似たようなものがまた出てきたと感じる方も多いと思う。実は筆者もそのように感じて調べてみた。何故、さらに新しい暗号化ファイルシステムの実装行われているのだろうか。ヒントは、前述のLinuxシンポジウムで発表した、Michael Halcrowの2004年１月の「Encrypted Filesystem」というメールにあった。少し古い話だが、前々会のオタワのLinuxシンポジウムでの彼の発表の約半年前のことである。このメールでは関連技術をほとんど網羅して紹介しているので、URLと若干の注釈をつけて引用することにする。
また、カーネル2.6のDevice-mapperを使用して実装した、「dm-cryptと2.6シリーズ・カーネルでパーティションを暗号化」の記事のdm-cryptがMichael Halcrowのメールに出てこないのは、このころはまだ無かったのか、有名ではなかったのかも知れない。そのほかにファイルシステムとして関連ありそうな技術としては、StegFS - A Steganographic File System for Linuxと、SFS - Self-certifying File Systemがある。StegFSはステガノグラフィ(Steganography)と呼ぶ電子透かしに似た技術を使って、他のデータやバックグラウンド情報の中に暗号化したデータを隠蔽する方法である。他の暗号化手法と異なるのは、暗号データの存在や暗号データに対するアクセスの有無を隠すことである。しかし開発サイトを見ると、開発は停滞している。SFSはその名の通り、ファイルシステム自体により強い信頼性を持たせるために、常時検証しながら通信を行うネットワーク・ファイルシステムであるので、暗号化は行わない。
Encrypted Filesystem
私は今年、Linuxの暗号化ファイルシステムに取り組まなければならない。私は様々なLUG(Linux User Group)を調査しており、現在既存の実装コードをテストし、再検討し、そして、それらのうちのいくつかを修正し始めたところである。私はまず、努力を集中させるアプローチをひとつに決めたい。また、どのアプローチが最も実現可能なものかについて、LKMLからフィードバックを得ることに興味を持っている。
これは個人やグループから受け取った経験やフィード・バックを元に、私が編集した要求機能の候補リストである。
- ルートファイルシステムに対するシームレスなアプリケーション
- ルートファイルシステム全体に対するレイヤ
- 最小限のオーバヘッドでの復号パスを持つ事
- 「暗号化済」、「復号化済」というようにファイルをマークして暗号レイヤに従って扱う
- Key->file 関連付け
- key->blkdev または key->directory に対する粒度 (granularity)
- 拡張属性中に管理情報を入れる代わりにディレクトリ中の暗号メタファイルは不要
- 拡張属性を知らないバックアップ・ユーティリティーを壊す場合がある
- 暗号化したファイル上のヘッダブロックに暗号メタデータを格納するときに別のモードを要求する場合がある
- 新しいファイルは作成したディレクトリで「暗号化のみ」とフラグ付けでき、デフォルトはディレクトリのメタデータで定義されたキーと共に暗号化される
- ファイルサイズ、実行許可ビットなどのファイル機密に関するできるだけ多くのメタデータを作る
- プラグインできる暗号(私はCTRモードの中でブロック暗号を使用することを気にかけない)
- PAMによる認証
- pam_usb
- Bluetooth
- Kerberos
- 一定の暗号化されたファイルアクセスを許可する前のグループメンバのPAMチェック
- キー管理を用意するためのRootplugベースのLSM(LSMが必要か?)
- 秘密キーの分割とm対nのスレショルド・サポート
- 暗号レイヤのハッキングを検知するための監査フラグに立てたファイル上のシグネチャ
- 復号化されたファイルにアクセスするためのアドホックなグループ
- ウェブブラウザを立上げるときには、デフォルトで能力継承マスクのようにグループメンバを落として、ブラウザを復号ファイルにアクセスさせない
- アクセス(アプリケーションアクセス要求中の明示的な)を許可する前のグループメンバのPAMモジュールチェック
- 暗号化されたファイル管理をサポートするユーザランド・ユーティリティ
- 「ヒント：暗号化しているので右クリック」のような共通のインタフェースで、ユーティリティを使用することができるnautilus と konquerorに対する拡張
- Distroインストール への統合
- 根幹的なファイルシステムがサポートするところでは透過性を分断
- バージョン付けとスナップショット（CVSのような振舞い）
- SE Linuxで動作させる設計
これらは全部が、必ずしも強い要求とまでは言えない暗号化ファイルシステムのための機能である。単に受け取っただけの提案であり、私はすべて実現可能であるとは確信してない。
私が知っている選択肢は次の通りである。
- NFSベース (CFS, TCFS)
- CFS（訳注：AT&T研究所のMatt Blazeが1993年に発表たUnix系OS用古典的なencrypting file system）は枯れている
- 性能問題
- UNIXセマンティック違反 (Violates UNIX semantics w/ hole behavior)
- シングルスレッド
- ユーザランド・ファイルシステム・ベース(EncFS+FUSE, CryptoFS+LUFS)
- 新しいソリューションだが、CFSのように十分テストされてはいない
- KDEチームはSSHFS+FUSEを使用
- Loopback (cryptoloop) encrypted block device
- カーネル中では枯れている
- ブロックデバイスに対する粒度がほとんどのインクリメンタルなバックアップ・アプリケーションを壊す
- LSMベース
- このアプローチは本当に可能だろうか？必用なフックは全部揃っているのだろうか？
- VFS(Virtual File System)の修正 (NCryptfsのようなスタッカブル・ファイルシステム)
- Erez Zadokは非常に低オーバヘッドだと断言
- フル実装はリリースされてない
- キー -> ディレクトリ の粒度
- プロセスが死んだ時キャッシュからクリアテキストページ追い出す
- 接続を保管するためにdcacheを使用
- 他にもエレガントな点があるがリリースされてない
私のゴールは「デスクトップ用の」暗号化されたファイルシステムを開発することである。プロセスの暗号化されたファイルに対するアクセスはすべて、ファイル解読するために認証を要求するようになる。私はこの機能をサポートするために、既にCFSをいくつか修正した。しかしCFSがこれに向かう最良のルートかどうかは、今のところはわからない。
私は、ロードされた時にマウントするすべてのルートファイルシステムに対して、透過的な暗号レイヤの役割を行うカーネルモジュールを書こうとしている。例えばext3パーティションの中にバラまいた暗号化ファイルを持つ場合があるが、それにはモジュール(と認証機構など‥‥)をロードした後にだけ、アクセス可能になるのである。
反応
このときのこのメールに対する反応は、ユーザランド・ファイルシステム・ベースを推奨する声もあったが、新しいファイルシステムの開発については上々といったところだった。返信したそれぞれが現状の暗号化ファイルシステムの状況に不満を持っていたようで、それが今回のリリースへの力になったようである。