【第37回】UbuntuでもBitLockerのようなストレージ暗号化を実現してみよう

　日本時間の10月13日未明にUbuntuの最新版である「 Ubuntu 23.10(コード名：Mantic Minotaur) 」がリリースされた。その後、技術以外の事情でデスクトップ用のインストーラはいったん取り下げになったが、日本時間の10月17日には再リリースされている。

　さて、23.10のデスクトップ版では 実験的機能 として「TPMベースの全ストレージ暗号化(Full Disk Encryption: FDE )」が導入されている。これは何かと言うと、ルートファイルシステムが含まれるストレージパーティション全体を暗号化し、なおかつ起動時の復号のためのパスワード入力をTPMによって自動化したものだ。WindowsでいうところのBitLockerだと思えば良い。これによりストレージを抜き取られて情報を盗まれるといった問題に対処できる。今回はこのFDEを、古いUbuntuでも実現してみよう。

Ubuntu 22.04 LTSでもインストール時にストレージの暗号化設定を行なえる

FDEができること/できないこと

　情報とは常に盗まれる存在である。あなたにとって重要度が高いかどうかに関係なく盗まれる。たとえあなた自身がなんの価値もない存在だとしても、とりあえずあなたの情報は盗まれる。よって現在では、常に情報やそれが保存された媒体が何らかの方法で盗まれうるものだという前提で行動することが望ましい。

　そんな世知辛い世の中において、スマートフォンやPCのストレージは「盗まれたくない」類の情報の倉庫と言えるだろう。たとえば何かのサービスに対するパスワードもしくはそのハッシュといったセキュリティに関わるデータ、サイトのブックマークやアクセス履歴といった個人の行動に関わるデータなどなど、「見られたくない」だろうデータが多く保存されている。たとえ「見られても問題ない」と思うものしか保存していなかったとしても、「じゃあ、中身を見せてください」と言われて見せられるかは別の話だ。

　よってストレージは暗号化されていることが望ましい。最近はスマートフォンだけでなく、Windows PCも購入時点で暗号化されていることが多い。しかしながらUbuntuを含むLinuxに関しては、今の時点では暗号化されているほうが稀だ。これはLinuxがインストール済みのマシンが少ないことに加えて、インストール時にセットアップする手間や起動時の復号する手間が増えることなどから避けられているという事情もある。用途によってセキュリティよりも速度が優先されるケースもあるだろう。

Windowsの場合はメーカー製のPCだとプレインストールされた状態ですでにBitLockerが有効化されており、初回起動時に必要なセットアップと回復キーのMicrosoftサイトへの保存が行なわれたりする

　たとえばデスクトップ版のUbuntuは、10年近く前からインストール時点でストレージの暗号化ができるようになっていた。しかしながら、これはあくまでオプション扱いであり、ほとんどのユーザーは暗号化せずに利用している。実際のところ、暗号化を有効化した場合は起動のたびに「ストレージの復号時」と「ログイン時」の2回パスワードを入力しなくてはならないという面倒さもある。そのへんも含めて安全性よりも「面倒くささ」が勝ってしまっていたのだろう。

　さて、冒頭で説明したようにUbuntu 23.10では実験的機能として「 TPMベースの全ストレージ暗号化 」が導入された。これまで存在した全ストレージ暗号化に加えて「 TPMを利用した起動時の自動復号 」の設定も行なわれることになる。

　TPM(Trusted Platform Module)とは、データの暗号化・復号やハッシュ値の計算・結果の不揮発領域への保存などを送るセキュリティモジュールだ。ここに復号用のキーを保存しておくことで、そのTPMモジュールが接続されたマシンでのみ、自動的に復号を行なえるようになる。これにより「2回パスワードを入力」という手間から解放されるのだ。さらに従来の「Secure Boot」とTPMを活用した「Measured Boot」を組み合わせることで、確実に特定のマシンでのみ起動できるストレージにできる。

最近はCPU/SoCなどに組み込まれたファームウェアTPM(fTPM)なんてのもあり、メニューからオン/オフできたりする。図のIntel PTTもそんなfTPMの1つだ。また仮想マシン向けに完全にソフトウェアで実装されたswTPMなんてものもある。

　ただしTPMを用いて自動復号している場合、ストレージ単体の盗難には強い耐性があるが、PCまるごと盗難された場合はその限りではないことに注意しよう。

　たとえばUbuntuの場合、カーネルが起動したあとのルートファイルシステムをマウントする際にストレージの復号を行なう必要がある。つまりログイン画面が出た時点では、復号は完了しているのだ。もちろんログインしないとPCは使えないし、カーネルのコマンド文字列が変わると復号できず、シングルユーザーモードもファイルシステムをマウントできないと動かないようになっているため、「ログインパスワードを知らない」とPCが使えないことには変わりはない。ただ、言い方を変えると「ログインパスワードさえなんとかなれば、ストレージにアクセスできる」ということになる。

　TPMベースの暗号化はあくまで「盗難時の情報漏えいの リスクを下げる 」だけである点に注意が必要だ。盗難しないほうが良いことは言わずもがな。特に過去に出先において、財布や鍵やメガネやスマートフォンや携帯ゲーム機や傘などのいずれかを紛失したことがある人は、当然PCも忘れうるものとして日頃から気をつけておこう。

　さて、Ubuntu 23.10のTPMベースの全ストレージ暗号化に話を戻す。Ubuntu 23.10の実装は少し特殊な仕組みをとっている。

• カーネルはsnapパッケージ版が使われる
• カーネルとinitramfsは単一バイナリとなる
• GRUBメニューはsnapdが管理する

　いわゆる「/boot/」領域ががっつり変わっているのだ。これは組み込み向けのUbuntu Coreと実装を揃えて、仕組みを流用するための措置となっている。あくまで「実験的機能」としているのは、これらの仕組みによって現時点ではいくつかの制約事項が存在するからだ。

　具体的には「DKMSなどを利用した追加のカーネルモジュールは使えない」などが最たるものだろう。あとは「仮想マシン上では使えない」という不具合も見つかっている。これらの制約から、現時点ではUbuntu 23.10のTPMベースの全ストレージ暗号化を使用するのはおすすめしない。もちろん、より致命的な不具合に積極的に遭遇することしか得られない栄養を摂取したいという、特殊な性癖の方にはおすすめだ。

「EXPERIMENTAL」に加えて「Warning」も付いているように、現時点ではいろいろ試験が足りていない機能である

　ところで「TPMを使わない」タイプの全ストレージ暗号化であれば、前述したようにこれまでも存在していた。上図で言うところの「LVMを使用する」にチェックすることで選択できる、「セキュリティのためにディスクを暗号化し」の部分だ。こちらの機能は上記のような制約はないし、仮想マシンでも使えるし、幅広くとは言わないまでもそれなりのユーザーが使用している。とりあえずストレージを暗号化したいなら、こちらの方法がおすすめだ。

　ちなみにここまでなんの注釈もなく「全ストレージ(Full Disk)」と表現したが、これは「システム用のストレージ全体」を意味している。「ストレージ全体」ではないことに注意しよう。これは従来のファイル単位の暗号化やホームディレクトリのようなフォルダ単位の暗号化に対比した用語となっている。

　たとえばブートローダーなどが保存されるESP(EFI System Partiton)は、UEFIファームウェアが読み込めるファイルシステムでないといけない。一般的なUEFIファームウェアは暗号化ストレージに対応していないことが多いため、このパーティションを暗号化できない。

　また、Ubuntuの場合はブートローダー(GRUB)がアクセスするカーネルなどが保存されているパーティションも暗号化しない設定になっている。暗号化されるのはルートファイルシステムが保存されるパーティションだけだ。うっかり「/boot」ディレクトリなどに機密データを置いてしまうと、暗号化の対象にならないので気をつけよう。

FDEのための事前準備

　前置きが長くなったが、ここからはUbuntu 22.04 LTSを用いてストレージを暗号化してみよう。ここからは22.04のスクリーンショットを例示するが、ほかのリリースでも同じ手順で設定が可能だ。

　UbuntuでFDEを実現するためには、ほとんどのケースにおいて「 Ubuntuの再インストール 」が必要になる。これはWindowsのBitLockerに対するかなり大きな欠点だ。Ubuntuの場合、通常のインストールだとファイルシステムとしてext4を直接ストレージの上に構築する。それに対して暗号化ストレージの場合は、LUKS(Linux Unified Key Setup)を用いてブロックデバイス単位で暗号化を行なった上で、その上にLVM(Logical Volume Manager)を用いて論理ボリュームを構築し、その上に必要なファイルシステムを構築する形になっているからだ。

暗号化前のストレージと暗号化後のストレージの構成は大きく異なる

　うまくやれば既存のUbuntuを残したまま暗号化ストレージへと移行することも不可能ではないが、それなりの知識と経験と運が必要だ。素人にはおすすめしないし、玄人も本番環境ではやらない。本サイトの読者なら、どうせ予備になっている(名誉のために付記すると、決して余っているわけではない)PCの1台や2台はあると思うので、まずはそちらで試してみると良いだろう。既存のPCに再インストールするなら重要なデータのバックアップをお忘れなく。バックアップについては第18回や第20回を参照してほしい。

　では、まず通常の手順でUbuntuをインストールしよう。これは本連載の第0回とも言うべき「人気Linuxディストリビューション、Ubuntuを触ってみよう！」が参考になる。連載が続くと、こういう定番手順のリファレンスが増えて便利だ。最後のは連載の外だけれども。

　インストール時に気をつけるべきポイントは次の3点。

• インストールの最初の画面では「Ubuntuを試す」を選択する
• インストーラを起動して「インストールの種類」でいったん止める
• インストール完了後に再起動するまえに回復キーを別の場所に保存する

　「Ubuntuをインストール」ではなく「Ubuntuを試す」にするのは、回復キー(復号パスワードを忘れた時のリカバリ用の鍵)を保存する必要があるためだ。インストーラの不揮発領域や別途USBストレージを用意できるなら、「Ubuntuをインストール」でも問題ないが、それがない場合は「Ubuntuを試す」を選択した上でホームディレクトリに保存し、インストール作業が完了後・再起動前に回復キーをrsyncコマンドか何かでネットワーク越しの別のデバイスに移動する必要がある。

　それではインストール手順を見ていこう。

インストールの最初のステップでは「Ubuntuをインストール」を選ぶ

「インストールの種類」まで進んだら「高度な機能」ボタンを押す

「新しいUbuntuのインストールにLVMを使用する」を選択した上で「安全のため新しいUbuntuのインストールを暗号化する」にチェックを入れてOKを押す

「高度な機能」ボタンの右に選択結果が表示される

セキュリティキーを入力する。さらに「Enable recovery key」をチェックすることで回復キーも生成できる

　セキュリティーキーは起動時に入力する復号パスワードだ。これはLUKSのメタデータを復号するために使われるパスワードで、できるだけ長く複雑なものが望ましいが、手動で入力できる程度の長さでもあったほうが良い。

　それに対して「Recovery key」は、パスワードを忘れた時などの「最後の回復策」として使われる。自動生成されるため、それを保存しておこう。手動でコピーもできなくはないが、それなりに長い(48文字の)数列である。数十年前であれば「ふっかつのじゅもん」を間違えずに覚えられた人でも、数列となると難儀することだろう。よって間違えずに保存するためにも、ファイルにダウンロードしておくことが大事だ。

　ダウンロードボタンを押すと、保存場所を指定できる。USBストレージなどがあるならそれを接続して場所を指定すると良いだろう。ただしファイルが保存されるのはインストールが進んだあとなので、完了するまではストレージは接続したままにする必要がある。また、図のように「/home/ubuntu」の下だと、再起動すると消えてしまう。その場合は、インストール後の再起動する前に別のマシンにコピーすることを忘れないように。インストール完了後の次のダイアログで再起動させないことが重要だ。

インストール後のこのダイアログが表示されたら「試用を続ける」を選択する

　あとはrsyncなりscpなりで別のマシンにコピーしよう。

$ rsync recovery.key ユーザー名@サーバーアドレス:

　Windowsしかないなら、インストーラが動いていたUbuntu側にOpenSSHサーバーを入れてしまうというのも手だ、「sudo apt update && sudo apt install -y openssh-server」を実行する。さらに「passwd」コマンドを実行して、Ubuntuのインストーラ用アカウント(ubuntu)のパスワードを設定する。あとはWindows側でPowerShellを起動し、「scp ubuntu@UbuntuのIPアドレス:recovery.key .」とすればWindowsにコピーできる。

　回復キーの退避ができたら、今度こそ再起動する。再起動するとPCのロゴが表示されるタイミングで次のようにパスワードの入力が求められるはずだ。

復号用のパスワード入力画面

パスワードを間違えるとこのようにエラーとなって先に進まない

　ここでパスワードを入力すれば起動が継続し、今度はログイン画面のパスワードを入力することになる。ちなみに端末からlsblkなどを実行すると暗号化デバイスがどれかを確認できる。

$ lsblk
(中略)
sda              8:0    0    50G  0 disk

├─sda1           8:1    0   512M  0 part  /boot/efi
├─sda2           8:2    0   1.7G  0 part  /boot
└─sda3           8:3    0  47.8G  0 part
  └\─sda3_crypt 253:0    0  47.8G  0 crypt
    ├─vgubuntu-root
    │          253:1    0  45.9G  0 lvm   /var/snap/firefox/common/host-hunspell
    │                                     /
    └─vgubuntu-swap_1
               253:2    0   1.9G  0 lvm   [SWAP]

「ディスク」アプリだとこのような表示になる。ちょっと分かりにくい

ClevisとTPMで起動時に自動的に復号させる

　全ストレージ暗号化を行なうと、起動の度に2回のパスワード入力が必要になる。これは大変煩わしい。特にモニターとキーボードがつながっていないネットワークの先のマシンだと、まずはそれを接続するところから始めないといけない。

　そこで出てくるのが「Clevis」という自動復号フレームワークと、PCに接続されたTPMだ。Clevisを使うと、ストレージの復号キーをTPM内に保存でき、起動時に自動的にTPMから取り出せるようになる。これによりそのTPMとは異なるマシンでは、セキュリティキーか回復キーを入力しない限りは復号できない。さらにTPMを利用する際のパラメータとして後述する「PCR値」を設定することで、起動時のパラメータが変化したら、自動復号を行なえないようにできる。

　ちなみにClevisは外部プラグインを使うことで、YubiKeyなどを利用して暗号化ストレージを復号できるようだ。ノートPCのストレージを暗号化するなら、YubiKeyなどと組み合わせたほうがより安全になるかもしれない。

　まずはTPMデバイスの有無を確認しよう。これは単に「/dev/tpmX」が存在するかを確認し、そのバージョンが2.0以上であることを確認する。

$ ls /dev/tpm*
/dev/tpm0  /dev/tpm0rm
$ cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device

　TPMにはさまざまな機能が備わっているが、今回ポイントとなるのが「 PCR(Platform Configuration Register) 」だ。これはTPMにおける不揮発領域で、主に「Measured Boot」を実現するために使われる。

　たとえばPCR0から5にはUEFI/BIOSを含む初期化時のコードなどの計測結果が、PCR7にはSecure Boot関連の計測結果が保存される。またPCR8からPCR15はソフトウェア側で自由に使えて、たとえばGRUBだとPCR8に実行した各種コマンドやカーネル引数などの文字列の計測結果、PCR9にロードしたバイナリの計測結果が保存されていたりする。どんなバイナリ・文字列を使ったかを計測しつつ起動するから「Measured Boot」というわけだ。

　このPCRの値は、実行するコードやバイナリ、文字列などが変わったら当然変わりうる。ClevisのTPM機能ではこのPCR値を用いて、復号用のキーを暗号化してTPMに保存する。つまり PCR値が変わってしまうと自動復号は動かなくなる 。たとえばPCR0やPCR1などをClevisで使っていると、BIOSが更新されると自動復号が行なえなくなる。よってどのPCR値を使うかは重要となるのだ。

　単に自動復号するだけなら不要だが、システムでどんなPCRが使われているかを確認したいなら、「tpm2-tools」パッケージをインストールしよう。

$ sudo apt install tpm2-tools
$ sudo tpm2 pcrread
(中略)
  sha256:
    0 : 0x49D8970927F120B277A109FE384C7A88C88261FD730AE744411B749EFDC3D397
    1 : 0xF82E4E333FD3737D84A31553F688C2AE4E122439B0D6651979D4D674B19051E7
    2 : 0x85F63D955975FBD1CA4E934B32B93BF93F4D685FCBB43FE580055169B757FD6E
    3 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
    4 : 0x37622F99DAE9461E3BF5090FF097D2C475DDFAA301E58AE1EE47156136368753
    5 : 0x43A5C46EDCDB07C5ECE39D76CD886ED0A60D674E44DCB285E2650FC36B9187F1
    6 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
    7 : 0x0C437709E375F7AFDB8ABBC2A4A824FC294FF44C07AA4F992AD711D796199FDB
    8 : 0xD232A0D60C56887FDF37226719BDEBF987BCA61648C296D45FFCF90F943DA643
    9 : 0x6FEACE53231F2CDE448603D50F8DF45E4F73E8023D8E1ECF6E121FD46782F5BF
    10: 0x7E2455B281DBECA1D21E546B1A5883560AD365D95FA9619CAB1F104761312C65
    11: 0x0000000000000000000000000000000000000000000000000000000000000000
    12: 0x0000000000000000000000000000000000000000000000000000000000000000
    13: 0x0000000000000000000000000000000000000000000000000000000000000000
    14: 0x306F9D8B94F17D93DC6E7CF8F5C79D652EB4C6C4D13DE2DDDC24AF416E13ECAF
    15: 0x0000000000000000000000000000000000000000000000000000000000000000
    16: 0x0000000000000000000000000000000000000000000000000000000000000000
    17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    23: 0x0000000000000000000000000000000000000000000000000000000000000000

　UbuntuだとPCR0からPCR10とPCR14が使われていることが分かる。PCR0-7までは主にUEFI/BIOSが使用していて、PCR8/9はGRUBが使っている。PCR10はLinuxカーネルのIMA(Integrity Measurement Architecture)機能によるものだ。これは次の方法で確認できる。

$ sudo head /sys/kernel/security/ima/ascii_runtime_measurements
10 09ac3abe63ffafba995a702c0a5cc2cabd3ec4d1 ima-ng sha1:c732fa8242867ac4f958658507759e8ef78970bb boot_aggregate

　上記だとboot_aggregateしか保存されていないが、環境によってはもっといろいろ保存されているかもしれない。PCR14はGRUBを起動するための「shim」が保存する領域で、主にMOK(Machine Owner Key)というマシン固有のSecure Boot用の鍵などを保存する際に変更される。shimはPCR4やPCR7にも影響しているようだ。

　Ubuntuの場合、Secure Bootは必須にすべきなのでPCR7が前提として、カーネルの起動パラメータが変えられていないことを保証するために、PCR8やPCR14あたりも入れておくと良いだろう。

実際にClevisをインストールしてみる

　それでは実際にClevisをシステムにインストールしよう。今回はinitramfsの中でLUKS上に構築されたルートファイルシステムをTPMを使って復号するため、次のパッケージが必要になる。依存関係によってClevisもインストールされる。

$ sudo apt install clevis-luks clevis-tpm2 clevis-initramfs

　次にLUKSのボリュームをClevisを使ってTPMに「バインド」する。「LUKSのボリューム」は前述のlsblkコマンドで実行した時に「crypt」と表示されたブロックデバイスの親デバイスだ。今回の例だと「sda3(/dev/sda3)」となる。

$ sudo clevis luks bind -d /dev/sda3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7,8,14"}'
Enter existing LUKS password: (インストール時に設定した復号用のセキュリティキーを入力)

　これで準備はできた。実際にLUKSに新しい鍵が追加されたかどうかを確認してみよう。LUKSの鍵情報はcryptsetupコマンドで確認できる。

$ sudo cryptsetup luksDump /dev/sda3
(前略)
Keyslots:
  0: luks2  セキュリティキーのスロット
     (略)
  1: luks2  リカバリーキーのスロット
     (略)
  2: luks2  Clevisで登録したキーのスロット
     (略)
Tokens:
  0: clevis
        Keyslot:    2
       (略)

　上記のようにキースロットの2に今回登録した鍵が追加されていることが分かる。ちなみにLUKSの鍵の追加や無効化はこのcryptsetupコマンドで行なえるので、いざというときのために覚えておくと良いだろう。

　最後にinitramfsを更新しておく。これによりカーネルが起動した際に、initramfsの中で自動的にTPM2を使った復号処理を行なってくれるというわけだ。実はUbuntuの場合、Clevisパッケージのインストール時に自動的に実施してくれるため実行する必要はないのだが、念の為やっておいても良いだろう。

$ sudo update-initramfs -u

　さっそく再起動してみよう。実はこの設定でもLUKSのパスワード入力画面は表示される。ここでエンターキーを押したり、少し放置しておくと自動的に先に進むので安心してほしい。これで自動的な復号の準備完了だ。

　試しに自動起動できなくなる設定にしてみよう。今回の場合PCR7・8・14にバインドした。これはつまりSecure Bootの設定かGRUBの設定が変わると、自動復号はされないことを意味する。よってGRUBの設定を変えて、カーネルに適当なコマンドラインを追加してみよう。

　いくつか方法はあるが、今回はGRUBのメニューから設定することにする。まずはマシンの電源を切ろう。次に電源を入れたらESCキーを連打する。次の図のような画面になれば成功だ。

起動時にESCキーを連打するとGRUBメニューが表示される

　もし「grub>」のような画面になった場合は、「normal」と入力し、エンターキーを押したら、直後に一度だけESCキーを押すと上記のメニューになるはずだ。

　GRUBメニューが表示されたら「Ubuntu」が選択された状態で「e」キーを押すと、編集画面に入る。カーソルキーで「linux」で始まる行に移動し、末尾に「–」を追加してみよう。

編集画面でlinuxの行の末尾に「–」を付けてみる

　ちなみにこの「–」はカーネルの起動パラメータとinitのパラメータをわける識別子であり、それ単体では何も意味をなさない。入力が終わったら「Ctrl-x」で起動する。そうすると自動復号は行なわれず、パスワード入力画面で止まるはずだ。これによりGRUBの設定を編集して起動すると、自動復号されないことがわかった。

　ちなみに今回のようにPCR8を対象にしていると、GRUBの設定を編集しただけで自動復号できなくなる。もし必要があって編集した場合、つまり永続的に編集を反映するつもりの場合は、編集して再起動したあとに次のようにバインドしている鍵を再生成すると良い。

$ sudo clevis luks regen -d /dev/sda3 -s 2
Regenerating binding (device /dev/sda3, slot 2):
Pin: tpm2, Config: '{"hash":"sha256","key":"ecc","pcr_bank":"sha256","pcr_ids":"7,8,14"}'
Do you want to proceed? [ynYN] y  デバイス・スロット番号・PCRが合っていたらここでyと入力する
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:295:Esys_Unseal_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish ErrorCode (0x0000099d)
ERROR: Esys_Unseal(0x99D) - tpm:session(1):a policy check failed
ERROR: Unable to run tpm2_unseal
Unsealing jwk from TPM failed!  PCR値が変わっていたらここはエラーとなるのでパスワード入力して復号する
Enter existing LUKS password:(インストール時に設定した復号用のセキュリティキーを入力)
Binding regenerated successfully

　設定後に再起動したら自動復号が復活しているはずだ。Windowsユーザーでも稀に遭遇するようだが、TPM/PCRの何らかの理由で変わった結果、セキュリティキーが必要になることは起こりうる。PCRが変わったということは、「意図しない変更」は攻撃を受けた可能性も否めないものの、たとえば直近でGRUBやカーネル、ドライバのパッケージが更新されたとか、BIOSを更新したということであれば、それによって特定のPCRの値が変わってしまったのかもしれない。このあたりは必要に応じて、パスワードを入力して起動するしかないだろう。

　よって、TPMで自動復号できるようになったからと言って、パスワード(セキュリティキー)を忘れて良いということにはならない。安心のためにも、マシンが起動できなくても確認できる場所にパスワードを保存しておくようにしよう。

　説明が長くなってしまったが、これでTPMによる自動復号の設定は完了だ。仮にストレージだけ盗まれたとしても中身まで盗まれる可能性は下がるし、PC単位で紛失したとしても、ログインパスワードが十分に強力であればすぐに奪われる心配はなくなる。とは言え、どんなにソフトウェア的にセキュアにしたところで、物理的な脆弱性を備えていたらあまり意味はない。普段から紛失・盗難が起きないように心がけることが一番重要だろう。

　さて、そんなことを書いていたら飲み会に呼ばれたので、PCはリュックに入れておいて、ちょっとだけ泥酔してくることにしよう。