可搬性の必要なデータの保全

計算機にあるデータの保全については、以前も[暗号化による物理的な防御](http://qiita.com/ynakayama/items/74096212b8177234be8a)であるとか、[遠隔地への多重管理](http://qiita.com/ynakayama/items/f4d8070130c964d53400)といった観点から調べてきました。

オフサイトへの物理的な運搬については、会社のセキュリティポリシーによって暗号化が義務付けられていたりと様々でしょうが、いずれにせよ盗難や紛失等で他者の手に渡っても解読が事実上不可能であることが必須要件です。暗号化に際しては一般的に市販の製品よりオープンソースソフトウェアのほうが優れていることが多くあります。

たとえば BitLocker は Microsoft Windows に搭載されている暗号化ソフトウェアですが、これを[解除することのできる業者も居る](https://twitter.com/sudo_vi/status/296488368508903424)という話もあります。一方で [TrueCrypt](http://truecrypt.sourceforge.net/) は FBI が復号に失敗したり、オープンソースソフトウェアなので[第三者が監査プロジェクトを立ち上げて現バージョンに大きな脆弱性が無いことを確認する](http://istruecryptauditedyet.com/)といった状況です。

## TrueCrypt を取り巻く状況

公式サイトに警告が表示され [BitLocker](http://ja.wikipedia.org/wiki/BitLocker) などの代替の方式への移行が示された TrueCrypt ですが、目紛るしく状況の変化を伝えるニュースが報じられています。

次のサイトに最新情報が続々と集まってきています。
http://truecrypt.ch/

これはスイス発のプロジェクトであり、万が一にも TrueCrypt 本家が継続しない場合、 fork & rename して開発を継続するといった旨のことが示唆されています。

オープンソースソフトウェアであるため、その重要性から保守していこうという力は強く働いているようです。開発者の警告に反し TrueCrypt は依然として安全に利用できるという情報もあります。次のサイトを参照してください。

TrueCrypt, the final release, archive
https://www.grc.com/misc/truecrypt/truecrypt.htm

最新の 7.1a もここから入手することができ、またソースコードなども次々と fork され GitHub などでホスティングされています。またハッシュなどは[こちら](https://defuse.ca/truecrypt-7.1a-hashes.htm)を参照することで正しいバイナリやソースコードであることを確認できます。

またそもそも TrueCrypt は実績の無いソフトウェアではなく、それどころか [AWS (Amazon Web Service) のバックエンドでも採用されている](http://docs.aws.amazon.com/AWSImportExport/latest/DG/encrypting-using-truecrypt.html)メジャーなテクノロジーです。これはある意味驚きですが、それだけ強力で信頼できるソフトウェアの証だと言えるでしょう。

こういった状況ですので、[データの物理的な暗号化のために TrueCrypt を利用](http://qiita.com/ynakayama/items/74096212b8177234be8a)していたとしても、もちろん最新の情報に対するキャッチアップは必要でしょうが、すぐにあわてる必要は無いと言えるでしょう。まずは監査プロジェクトの続報を待つべきです。

## LUKS / dm-crypt による可搬性の必要なデータの保全

さて、特定のプロダクトに依存してしまうことは、何らかのロックインを招いてしまいます。万が一にもそのテクノロジーが利用できなくなったときの代替を検討しておくべきです。

研究データのポータビリティについてはしばしば関心が集まります。たとえば他の研究所や離れた支社にデータを持ち歩く必要性に迫られることもあるでしょうし、業種によっては顧客の情報を預かることもあるでしょう。

[dm-crypt](http://en.wikipedia.org/wiki/Dm-crypt) は Linux カーネル 2.6 でマージされたディスク暗号化のためのサブシステムで LUKS という仕様に則ります。そもそも TrueCrypt もこの LUKS を利用しているわけなのですが、 GNU/Linux にて考えられる幾つかの暗号方式のなかでも[比較的高いパフォーマンスと安全性を誇ることが報告されています](http://sourceforge.jp/magazine/07/03/20/0056256)。

以前は [dm-crypt を利用して暗号化した領域を LVM の一部として組み込み](http://qiita.com/ynakayama/items/74096212b8177234be8a)ましたが、システムへの参加 / 離脱といった可搬性を考えると暗号化 + ext4 ファイルシステムによる単純なファイルシステムに分があります。今回は LUKS を利用してポータビリティの要求される記憶媒体上に ext4 ファイルシステムを生成します。

### LUKS ボリュームの生成

まずは今まで通り暗号化された領域を作ります。

```bash
cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 /dev/sdb
```

### LUKS ボリュームへの接続

次に LUKS ボリュームへ接続します。これも以前と同じです。 luksOpen サブコマンドによって /dev/mapper/[luks_name] が生成されます。

```bash
cryptsetup luksOpen /dev/sdb sdb_crypt
```

あとはこれを普通のデバイスとして利用すれば良いだけです。たとえばファイルシステムの生成は次のようにします。

```bash
mkfs -t ext4 /dev/mapper/sdb_crypt
```

### ファイルシステムのマウント

これをマウントして、普通にデータの読み書きをして利用します。

```bash
mount /dev/mapper/sdb_crypt ~/mnt/sdb
```

### ファイルシステムのアンマウントと LUKS ボリュームの解除

データの読み書きが終わったら、システムからメディアを取り外して持ち運ぶため、ファイルシステムのアンマウントをします。 luksClose サブコマンドで LUKS ボリュームがシステムから解消されます。

```bash
umount ~/mnt/sdb
cryptsetup luksClose sdb_crypt
```

システムからパスフレーズ無しで接続するための鍵ファイルの追加は LVM のときと同じです。また今までと同じく LUKS ボリュームの情報は luksdump サブコマンドで取得することができます。

```bash
cryptsetup luksDump /dev/sdb
```

またシステムの自動化のために LUKS ボリュームか否か判定したいときは
isLuks サブコマンドが使えます。これは LUKS であれば戻り値 0 を、そうでなければ 1 を返します。

```bash
cryptsetup isLuks /dev/sdb
```

## まとめ

TrueCrypt や dm-crypt を利用すればシステムから取り外して持ち歩くような記憶媒体を暗号化し安全に保護することができることがわかりました。データ分析においては内容にセンシティブな情報を含むことが多々ありますので、万が一にも情報漏洩の無いよう強力な暗号方式を使いこなせるようになりましょう。

## 参考

手動によるディレクトリの暗号化 - redhat カスタマーポータル
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories.html

暗号化ファイルシステムを使ってみる ～ LUKS 編 - いますぐ実践! Linuxシステム管理 / Vol.186
http://www.usupi.org/sysad/186.html