ラップトップに重要なデータを入れて持ち運ぶのって怖いよね〜。 電車に置き忘れたらどうしようとか、盗まれたらどうしようとか、 まあ、最近は起動パスワードに加えて指紋認証だのといろいろあったりするけれども、 ディスクを取り出してアナライズされたらどうだとか、 いろいろありそうだし。 普通の人でも、メールの内容だけで結構アレな内容が入っているはず。
と、考えるとそこでファイルシステムやディスクの暗号化となるわけです。 ファイルシステムやディスクを暗号化するとすると、 とにかくディスク全部を暗号化するというポリシーが一つあると思うけれども、 ラップトップマシンの使われ方を考えるといろいろ問題があります。
たとえば、サスペンドから快適にレジュームするためには、 サスペンド状態から戻ってきたときに、 ファイルシステムが見えなくなっていては困ります。 かといって、 暗号化したファイルシステムを見えた状態のままサスペンドして持ち歩くのでは、 あまり意味がありません。 また、ディスク全体を暗号化すると、 それなりに性能や電池の持続時間に響くと思われます。
なので、 重要なデータのみを暗号化することが望ましいという結論になるかと思われます。 ここでは、いつも端末に使っている FreeBSD 5.X の標準機能である、 gbde(4) [GEOM-Based Disk Encryption] を使って、 ファイルシステム上のディスクイメージファイルを、 新たな暗号化ファイルシステムとしてマウントし、 それをユーザの利用時だけ簡単にマウント・アンマウント出来るような機構を設定してみました。
このような構成を取ることによって、一カ所にまとめた重要データを、 任意のタイミング、かつ簡単な操作で、 ディスク上では暗号化した状態のまま扱うことが可能となります。
イメージとしては、画面上に暗号化ファイルシステム利用開始と暗号化ファイルシステム利用終了のアイコンを作り、 重要なデータを利用する際や利用が終わった際にこれをクリックしてパスワードなどを打ち込めば、適切な処理が行われるということを想定しました。 具体的な画面は次のような感じです。
さて、それではやってみましょう。 gbde(4) と md(4) の組合わせに関してはこのあたりの手順を参考にした上で、 より使いやすくしてみました。
以下の手順は、FreeBSD 5.3 で行っています (なお、FreeBSD 4.X では gbde(4) は使えません)。 まずは、イメージファイルを用意しましょう。ディレクトリのポリシーとして、 「/usr/home/cryptfs」というディレクトリを作り、 そこにさらに「/usr/home/crypfts/ユーザ名」のディレクトリを掘ることで、 マウントポイントとします。また、イメージファイルのファイル名は、 「/usr/home/cryptfs/ユーザ名.img」とします。
ここでは仮に、10GB のイメージファイルを作りましょう。 また、誤操作で消去や書き込みが出来てはまずいので、 schg フラグやパーミッションの設定などをきちんとしておきましょう。 ユーザ名はここでは仮に hosokawa を使っています。 この例と容量を変更したければ、 dd の行の count= のあとにメガバイト単位で書くだけです。
# mkdir -p /usr/home/cryptfs/hosokawa # dd if=/dev/zero of=/usr/home/cryptfs/hosokawa.img bs=1024k count=10240 10240+0 records in 10240+0 records out 10737418240 bytes transferred in 569.743953 secs (18846042 bytes/sec) # chmod 600 /usr/home/cryptfs/hosokawa.img # chflags schg /usr/home/cryptfs/hosokawa.img # ls -lo total 10490900 -rw------- 1 root wheel schg 10737418240 3 12 12:49 hosokawa.img
上記手順で chflags と chmod が逆ではないかとの指摘があり、 修正しました (すでに上の手順は修正済み)。 どうもありがとうございました。(2005/07/28 追記)
そして、md(4) でイメージファイルをディスクのように見せかけます。
# mdconfig -a -t vnode -u 9 -f /usr/home/cryptfs/hosokawa.img # ls /dev/md* /dev/md9 /dev/mdctl
ここで、gbde(4) をこの仮想ディスクに適用します。 次のように gbde(8) コマンドを打ち込むと、 ちょうど vipw(8) のように、gbde(4) の設定が vi で編集可能となります。
# gbde init /dev/md9 -i -L /usr/home/cryptfs/md9
この設定で、一カ所だけ編集する必要がある場所があります。 下に示す sector_size の値を、512 から 2048 に増やしてください (2048 は UFS/UFS2 のフラグメントサイズ)。 この変更を行わないと、大幅に gbde(4) の性能が悪化します。
# Sector size is the smallest unit of data which can be read or written. # Making it too small decreases performance and decreases available space. # Making it too large may prevent filesystems from working. 512 is the # minimum and always safe. For UFS, use the fragment size # sector_size = 512
ということで、この行を次のように書き換えます。
sector_size = 2048
セーブして vi を終了させると、パスフレーズを尋ねてくるので入力します。 これが、ファイルシステム利用時に用いるパスフレーズになります (設定後に、複数のキーを追加登録可能です)。
Enter new passphrase: パスフレーズを入力 Reenter new passphrase: 再度確認入力
以上でイメージファイル上の gbde(4) の初期化は出来ました。 次はファイルシステムとして初期化が必要です。 まずはこの gbde(4) ディスクを有効化しましょう。
# ls /dev/md* /dev/md9 /dev/mdctl # gbde attach /dev/md9 -l /usr/home/cryptfs/md9 Enter passphrase: パスフレーズを入力 # ls /dev/md* /dev/md9 /dev/md9.bde /dev/mdctl
gbde(4) で作られた /dev/md9.bde が自動的に devfs 上に出現しています。 このデバイスを UFS2 + softupdates でフォーマットして、 さらにマウントしてみましょう。
# newfs -U -O2 /dev/md9.bde /dev/md9.bde: 10160.5MB (20808704 sectors) block size 16384, fragment size 2048 using 56 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, ...(略)... 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520 # mount /dev/md9.bde /usr/home/cryptfs/hosokawa # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 253678 124742 108642 53% / devfs 1 1 0 100% /dev /dev/ad0s1d 253678 6422 226962 3% /tmp /dev/ad0s1f 92273224 79570546 5320822 94% /usr /dev/ad0s1e 634606 105798 478040 18% /var linprocfs 4 4 0 100% /usr/compat/linux/proc /dev/md9.bde 10072750 4 9266926 0% /usr/home/cryptfs/hosokawa
暗号化ファイルシステムが /usr/home/cryptfs/hosokawa にマウントされたことが分かります。 そこで、このディレクトリの権限をユーザ hosokawa (グループ: staff) に設定します。
# chown hosokawa:staff /usr/home/cryptfs/hosokawa
さて、仕上げに一般ユーザ (ここでは hosokawa) 権限で、 Wanderlust で使うメールのディレクトリである ~/Mail と ~/.elmo を暗号化ファイルシステムにコピーします。データのコピーを行い、 シンボリックリンクで旧データを置き換えます (安定運用を確認できたあとで、~/Mail.old と ~/.elmo.old は消しましょう)。
hosokawa% cd /usr/home/cryptfs/hosokawa hosokawa% (cd ; tar cf - Mail .elmo) | tar xfp - hosokawa% cd hosokawa% mv Mail Mail.old hosokawa% mv .elmo .elmo.old hosokawa% ln -s ../cryptfs/hosokawa/Mail . hosokawa% ln -s ../cryptfs/hosokawa/.elmo .
ここに nullfs mount などではなくシンボリックリンクを使うのは結構ミソで、 シンボリックリンクにすることで、 暗号化ファイルシステムをマウント解除したいときに、 多くの場合問題なくマウント解除できます。 一応、Wanderlust だけを終了させてから解除する習慣にしていますが、 Wanderlust を立ち上げた状態でもマウント解除できることを確認しています。
この状態で初期化は済んでいるので、 この暗号化ファイルシステムを利用したい場合は、 次のように入力すれば利用可能です。
# mdconfig -a -t vnode -u 9 -f /usr/home/cryptfs/hosokawa.img # gbde attach /dev/md9 -l /home/cryptfs/md9 Enter passphrase: パスフレーズを入力 # mount /dev/md9.bde /home/cryptfs/hosokawa
利用解除は以下の手順で可能です。
# umount /home/cryptfs/hosokawa # gbde detach /dev/md9 # mdconfig -d -u 9
毎回これを入力するのは面倒なので、スクリプトにしてしまいましょう (一般ユーザでの実行のために ports/security/sudo が必要です)。
以下の自動化スクリプトに関しては、 その後アップデートしました。 詳しくは 2005 年 5 月 1 日 『GBDEによるノートPC暗号化その後』へ。 ということで、こちらまで読み飛ばしてください。 (2005/05/07 追記)
利用開始用スクリプト ~/bin/gbdeattach.sh は以下の通り。 マウントされているかどうかの判断に /usr/home/cryptfs/hosokawa/Mail ディレクトリを用いています。
#!/bin/sh if [ ! -d /usr/home/cryptfs/hosokawa/Mail ] ; then if sudo mdconfig -a -t vnode -u 9 -f /usr/home/cryptfs/hosokawa.img ; then sudo gbde attach /dev/md9 -l /usr/home/cryptfs/md9 if [ -c /dev/md9.bde ] ; then sudo mount /dev/md9.bde /usr/home/cryptfs/hosokawa else echo "Cannot init gbde." sudo mdconfig -d -u 9 sleep 1 fi fi fi
利用解除スクリプト ~/bin/gbdedetach.sh は以下の通り。
#!/bin/sh [ -d /usr/home/cryptfs/hosokawa/Mail ] && \ sudo umount /usr/home/cryptfs/hosokawa && \ sudo gbde detach /dev/md9 && \ sudo mdconfig -d -u 9
最後に、これらのスクリプトをキックするランチャを、 gnome2 の機能を用いて作成します。
いい加減な性能測定をしてみました。/dev/zero の書き込み、読み込み 100MB です。 CPU は Pentium III 1.15GHz の ThinkPad X24 ですので、 Pentium 4 などを使えばもっと良くなるでしょう。 ざっと見た感じ、書き込みは 1/10、読み込みは 1/2 という感じの性能です。
hosokawa% cd hosokawa% dd if=/dev/zero of=hoge bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.970781 secs (26407298 bytes/sec) hosokawa% cd Mail hosokawa% dd if=/dev/zero of=hoge bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 45.970754 secs (2280963 bytes/sec) hosokawa% cd hosokawa% dd if=hoge of=/dev/null bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 4.111557 secs (25503137 bytes/sec) hosokawa% cd Mail hosokawa% dd if=hoge of=/dev/null bs=1024k count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 8.756830 secs (11974379 bytes/sec)
実際に使った感覚としては、メールを POP で取り込む場合は、 私の場合 SPAM フィルタ (popfile) がほとんどの負荷を占めているので、 性能低下はあまり感じません。 また、メールを読む場合はそれほど性能が落ちないので、 ごくごく普通に使えています。
ということで、 少なくともメールスディレクトリとしての利用に性能的な不満は感じていません。 安定度としても、とりあえず 1 週間ほど使っていますが、 今のところ全くトラブルはありません。
そこそこ安定運用に入ったように思えるので、 メール以外にもその他重要そうなデータは、 どんどんこのファイルシステムに突っ込んでいます。 クリック一発 (+ パスワード) で簡単にデータに鍵を掛けられるので、 なかなか便利、便利。
別に技術的にそれほど難しいわけじゃないけど、 ここまで暗号化するならバックアップも暗号化したいよね。 でも実際にバックアップディスク全体を GBDE にすると、 Pentium 4 でも結構性能的に辛そうな感じになります。 暗号化に関しては、バックアップ先も暗号化に関して言えば同じ構成 (暗号化部分、非暗号化部分) でバックアップを取ったほうが良さそう、 という感じになりつつあります。
また、Linux に関しても、 同様の機構は loopback filesystem のような形式で出来ると思います。