Google Code Prettify

2009年7月21日

Linux でボリュームを暗号化する (3) - 性能比較

ボリュームを暗号化する上で気になることは、どれくらいIOの性能が落ちるかである。

普通にそこら辺にある2台でベンチを取ってみた。

  • ASUS M2NPV-VM / Athlon64X2 3800+ (2GHz) / DDR2-533 1G x 4
  • EPIA-EN12000EG (C7 1.2GHz) / DDR2-533 1G
暗号化するのは、ちゃっと起動用とは別に確保してた SATA 320G HDD(ST3320620AS) を使った。次いでなので、VIA PadLock の有無も比較してみた。

測定は hdparm -t を使って3回で最も良い値を使った。

読み込み速度(MB/sec)
M2NPV-VM (2GHz) - 素74.82
M2NPV-VM (2GHz) - cryptoあり71.650.96
M2NPV-VM (1GHz) - cryptoあり36.100.48
EPIA-EN12000EG - 素76.04
EPIA-EN12000EG - cryptoあり/PadLock 有43.260.57
EPIA-EN12000EG - cryptoあり/PadLock 無12.640.17

格段に劣化する訳では無さそうで、 ファイルシステムが絡めば DiskIO と暗号化処理が並列化しそうなので、 気にならない程度に落ち着くのかなぁ。。。

あと VIA PadLock は結構効果があり、in-order 1.2G だけだと非力なのかぁ?

Intel Atom だとどの程度になるか気になるなぁ〜。。。それとも Atom 系に AES-NIが実装されるのを気長に待つ方がいいのかなぁ。。。

修正(2009/09/08)

Athlon64X2 は cpufreq の ondemand governor を使ってたため、どうも結果が怪しかったので、クロックを固定して再度計測し直した。

結果、Athlon64X2に関しては 結構クロック周波数に比例した性能であり、2GHz 程度の性能があれば汎用CPUには苦にならないようである。C7は PadLock を使うとやっと一人前であるが、他を凌駕する性能とかは無さそうだなぁ。。。

2009年7月20日

Linux でボリュームを暗号化する (2) - LVMの保護

最近は、起動用の小容量HDD/SSDと複数データ用の大容量HDDの組み合わせでPCを組んでいる。SSDが手頃な価格になれば、その傾向も大きくなると思う。起動用のHDDの暗号化は、手法が多く、それぞれに結構面倒設定が多いし、どんどん新しい手法が出てきそうだし、枯れるまで様子見の方がいいかなと思う。なので、データ用の大容量HDDを暗号化することのみを考える。

次のサイトを参考に設定した。

PC
- 起動用 HDD/SDD
  /dev/sda
- データ用 大容量HDD (今はこっちだけ暗号化)
  /dev/sdb
古いデータの消去とパーティションの作成

新品のHDDを買ってきたのならば必要は無いが、念のため古いデータを乱数で上書きする。全容量を一つのパーティションに割り当てる構成にする。

# shred -n 3 -v /dev/sdb
# echo "0,,8e" | sfdisk -D /dev/sdb
LUKSパーティションの作成

LUKSパーティションには2種類のキースロットを割り当てる

  1. パスフレーズ(難解で長文なもの)を使う奴 -- 運用上何かと必要
  2. キーファイルを使う奴

# cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdb1
...
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: <= パスフレーズを入力
Verify passphrase: <= パスフレーズを入力
...
# mkdir -m 700 /etc/luks
# dd if=/dev/random of=/etc/luks/data01.key bs=1 count=32
# chmod 400 /etc/luks/data01.key
# cryptsetup luksAddKey /dev/sdb1 /etc/luks/data01.key
Enter LUKS passphrase: <= パスフレーズを入力
key slot 0 unlocked.
...
起動時にキーファイルを使って自動的に開始する設定

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-sdb1 /dev/sdb1 /etc/luks/data01.key luks
...

後は再起動するか、次のコマンドで暗号化を開始しとく。

# cryptdisks_start crypt-sdb1
VGの作成

出来上がったブロックデバイスを使って、LVMを組めば良く。

# pvcreate /dev/mapper/crypt-sdb1
  Physical volume "/dev/mapper/crypt-sdb1" successfully created
# vgcreate Data01 /dev/mapper/crypt-sdb1
  Volume group "Data01" successfully created

Volume Group が作成まで出来れば、あとは普通のLVMの使い方そのものなので、略。。。

まとめ

キーファイルを起動用ディスク内に保存することで、データ用ディスクが単体で切り離された場合にデータが保護できるようになるし、先頭ブロックの1MBくらいを消去することで完全に破棄することも可能になる。

これで 1T級HDD の破棄する場合のデータ消去が簡単になるんかいなぁ!?

2009年7月16日

Linux でボリュームを暗号化する (1) - swapの保護

Linux のブロックデバイスの暗号化は結構昔から行われている。鍵の管理が貧弱なので、使ってはいなかった。初回に選んだパスワードを未来永劫使うのは、どう考えても高リスクだろう。

諸々の要求に応える為に、Linuxでは LUKS(Linux Unified Key Setup) という珠玉の成果がある。コイツを使えば、パスワードの変更だけでなく、複数のパスワードを持つことも出来るという有り難い代物。

再三設定してるので、ちょっとメモっとかないと、禿げの進行が年2ミリ位 早くなってしますので、取り敢えず書いとく。

swapの暗号化

LUKSと言いながら、そうでないものを最初に書くのは何だが、メモリのベタ情報を swap から平文で読まれたくない人は、必ずすべき設定ですね。。。

Debian の cryptsetup 付属の文書 /usr/share/doc/cryptsetup/README.Debian.gz のそのまんまですねぇ。

現在のスワップの無効化

先ず、現在のシステムで /dev/sda2 が swap デバイスとして、swapを無効化し、中身を全消去する(新品で何にも書かれていない場合は、消さなくても構わない)。

# swapoff -a
# shred -n 1 /dev/sda2
設定ファイルを変更する

/etc/crypttab

# <target> <source>  <key file>  <options>
crypt-swap /dev/sda2 /dev/random swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
...
/etc/fstab
...
/dev/mapper/crypt-swap none swap sw 0 0
...

暗号化スワップの有効化
# cryptdisks_start crypt-swap
# swapon -a

仮想化環境のゲストOSはメモリ割当が少ない場合が多々あるので、要設定かと思う。

何でも無いが、Linux KVM 上のゲストOSの乱数エントロピーが溜まるの遅くないかぁ。時々、暗号化スワップの開始で4〜5分くらい止まることがときどきある。。。

おやぁ、virtio_rng とか言うモジュールがあるなぁ。。。あるよなぁ。。。コイツが kvm-85 ではまだサポートされていないからなのかぁ。。。KVM に virtio_blk, virtio_net, kvm-clock, virtio_rng の四つ揃えば、準仮想化と変わらんなぁ。。。取り敢えず、待つべし!

2009年7月9日

debian lenny の kvm はバグってる?

以前 Ubuntu に乗り換え宣言したのだが、マイナーなパッケージが無かったり、古いままだったり(まぁコミュニティーベースだから仕方ない)で、Debian lenny に再度乗り換えた。

一番の難点は、、、言わないのが約束だなぁ。

Debian lenny だと kvm-72 がパッケージングされているので、サクサクインストールして使えるのだが、どうも2個以上のゲストOSを立ち上げると何故だか次のメッセージをだしてゲストOSがフリーズしてしまう。

 BUG: soft lockup - CPU#0 stuck for 4096s!

なんすかねぇ?

症状としては、下記のバグ報告と同じっぽい。

で、kvm-84 だと直ってるらしい。。。

ぐふぅ。取り敢えずは、適当に sid からkvm/libvirtのソースパッケージを取ってきてビルドして諸々更新したら、複数のゲストOSがフリーズせずに安定した、、、気がする。

またもや debian squeeze 待ちかなぁ

2009年7月7日

HDDの内容を全部消去する

掃除をしたら多量にPATAのHDDも出てきた。

今まで簡単に特殊なドライバでサクサク開封して磁性体に多量の傷を付けて不燃ゴミにしていた。 個人で使っていたもので重要な機密とかが入ってる訳ではないが、少々心もとない。

shred を使って2回の乱数埋めと1回のゼロクリアでHDDの内容を全消去するのが、簡便で良い方法らしい。

# shred -n 3 -z -v /dev/hdb

だが、本当に遅い!

Debian/lenny のバージョンの GNU shred どうも必要な乱数全部を /dev/urandom から読み込むため、乱数生成の帯域で制限されてるっぽい。

shredのあれこれ』 によれば、coreutils-5 では利用する乱数は内部で生成しており、coreutils-6 から /dev/urandom から利用する形になり、6倍遅くなったよという。。。つまり別の乱数発生器の openssl rand を使えと。

で、使ってみたが、、、途中で終ってしまいます。。。

なんでやぁ!!

暫し、熟考の結果 openssl rand の引数は int32_t だったらしく、100Gとかの HDD の消去とかには使えないですなぁ。。。。次のようにすれば完遂できますなぁ

# mkfifo rnd
# while true ; do openssl rand  $((2**31-1)) ; done > rnd &
# shred --random-source=rnd -n 3 -z -v /dev/hdb

大体、上の方法で 300G で 10時間くらい?

ここまではバットノウハウの話。

coreutils の git レポジトリをつらつら流し見たところ。

と言う訳で、coreutils 7.3 からは coreutils-5 の頃の内部乱数(ISAAC)生成が復活し、パス数のデフォルトが 3 pass になるという。

要するに、shred を何も考えずに使った奴が勝者!

それよりも、320G HDD が8台もある敗北者の僕は 100MB/secくらいでるハードウェア乱数生成ボードが欲しい。。。

久しぶりの投稿

かなり期間が空いてしまったが、ブログを再開してみようと思う。 2013年3月が直前の投稿だったが、頻繁に更新していた時期が 2011年11月までなので、8年間ぶりとなる。 8年間なにをしていたのかと言えば、2回転職して未だにIT技術者の職を得ている。 その...