TPMによるディスク暗号化の試験的サポートとその実装
「Ubuntu Desktop 23.10」の「Ubuntu Desktop Installer」で「TPM（Trusted Platform Module）」を利用したボリューム全体の暗号化（FDE）が試験的にサポートされました。
以下で「TPM」によるディスク暗号化の試験的サポートとその実装に関する情報が紹介されています。
「TPM」に依らずとも別の仕組みを用いて「FDE」を実現することもできます。Full Disk Encryption（FDE）
「Full Disk Encryption（FDE）」とは、ディスク（ボリューム）を暗号化することです。ディスクを暗号化する目的は、ディスク内に保存されているデータを暗号化することで、ストレージの紛失や不正アクセスによるデータの漏洩リスクを軽減することです。
Trusted Platform Module（TPM）
「Trusted Platform Module（TPM）」はセキュリティーで活用される仕組みであり、ストレージの暗号化など機密情報を保護する目的で活用されています。「Windows 11」のシステム要件でも話題になりました。
UbuntuとFDE
「TPM」による「FDE」の登場以前から「Ubuntu」では「FDE」をサポートしてきました。従来の「FDE」ではストレージのロックを解除するため、PC起動時にユーザーからパスフレーズを入力してもらう必要がありました。
しかし「TPM」による「FDE」では、ストレージのロックを解除するのに必要な機密情報が「TPM」によって管理されるため、パスフレーズを入力することなくストレージのロックを解除できます。
これにより使い勝手が向上しています。
またPC起動時の「TPM」との連携においてソフトウェアの検証も行われるため、「悪意あるメイド攻撃」からユーザーを保護する効果も得られます。
従来のFDE
それでは「TPM」を利用しない従来の「FDE」を見てみましょう。「Ubuntu」では「TPM」を利用しない従来の「FDE」に「Linux Unified Key Setup（LUKS）」を利用しています。
SSDやHDDなど一般的なユーザーが利用するストレージデバイスはブロックデバイスです。
「LUKS」はブロックレベルでディスクを暗号化する仕組みです。
この時「LUKS」による暗号化の主な流れは以下のようになります。
1. 暗号化の準備
「LUKS」でストレージを暗号化する場合、まずユーザーにパスフレーズもしくは鍵の入力を求めます。2. LUKSヘッダーの作成
次に安全性の高い暗号鍵を生成するため、計算コストのかかる処理を経て暗号鍵が生成されます。この時「1.」でユーザーが入力したパスフレーズは暗号鍵に直接使用されることはありません。
ここで生成された暗号鍵はマスター暗号鍵を暗号化するために使用されます。
またここで生成された暗号鍵は他に必要な情報とともに、暗号化するストレージの先頭に配置されるLUKSヘッダーに保存されます。
以上で「LUKS」による暗号化ストレージのセットアップは完了です。
3. Ubuntuの起動とロックの解除
さて「Ubuntu」が起動すると、「1.」でユーザーが入力したパスフレーズの入力を求める画面が「initrd」によって表示されます。ユーザーが入力したパスフレーズは、暗号化されたLUKSヘッダーを復号化し、LUKSヘッダーに保存された暗号鍵を取り出して、ストレージのロックを解除するために使用されます。
4. デバイスマッパーによる統合と透過的なアクセスの提供
暗号化されたストレージ（パーティションもしくはディスク全体）は、デバイスマッパーサブシステムを利用して、仮想ブロックデバイスと紐付けられます。アプリなどのソフトウェアは、この仮想ブロックデバイスを通じてデータの読み込みや書き込みを行います。
この時仮想ブロックデバイスは、暗号化ストレージにデータを書き込む時に、その場でデータ暗号化して暗号化ストレージにそのデータを保存します。
同様に仮想ブロックデバイスは、暗号化ストレージからデータを読み込む時に、その場で暗号化されたデータを復号化してソフトウェアに返します。
つまりアプリなどソフトウェアから見るとストレージの暗号化のことは意識せずに、通常のストレージのようにデータにアクセスできます。
5.柔軟なアルゴリズムとモード設定
「LUKS」では暗号の強度とパフォーマンスに影響を与えるアルゴリズムとモード設定を柔軟に設定・選択でき、利用目的に応じて柔軟なセキュリティー設定が可能です。ちなみに「Ubuntu」では、十分な評価を得ている「XTS-AES 256」を利用しています。
セキュリティーの強度はパスフレーズの強度に依存する
さて一連の過程を見て分かることは、この方法による「FDE」のセキュリティー強度は、「1.」でユーザーが入力したパスフレーズの強度に強く依存するということです。言い換えると短くて脆弱なパスフレーズでは、十分なセキュリティー強度は得られません。
TPMによるFDEの構成要素
上記の「TPM」を利用しない「LUKS」による「FDE」では「LUKS」が主役でした。しかし「TPM」による「FDE」では、複数の要素を組み合わせて「FDE」を実現します。
1. UEFIセキュアブート
セキュリティーで保護されていないPCでは、OS起動時のブートプロセスが脆弱になります。カーネルやハードウェア、周辺機器、ユーザー空間で動作するプロセスは起動時に初期化され利用可能になりますが、この時ブートファームウェアに脆弱性があった場合、その脆弱性をついた攻撃はこれらのソフトウェアも巻き込み連鎖的にシステム全体に影響を与える可能性があります。
その一例がブートキット（ルートキット）です。
ブートキットはブートプロセスの初期段階をターゲットとした悪意あるソフトウェアです。ブートキットはシステムを不正に制御し、OSやその他のソフトウェアよりも先に悪意あるコードを実行します。
そこで悪意あるコードによってシステムが侵害されていないことを検証するために、予め信頼できる検証可能な署名が施されたファームウェアやブートローダー、OS、カーネルなどブートプロセスで使用されるソフトウェアのみ実行できるように構成します。
これを実現する仕組みが、UEFIセキュアブートです。
2. TPM
「TPM」は先に紹介したとおり、機密情報を保護する目的で活用されるデバイスです。「TPM」はマザーボード上に実装されているハードウェアベースのセキュリティーコンポーネントです。
「TPM」は暗号鍵の生成や保存、管理、そしてセキュリティー関連のタスクを実行する非常に重要な役割を担うマイクロコントローラーです。
「TPM」が管理しているキーは、システムの認証やセキュアな通信、そして機密データの保護に活用できます。
さて「TPM」には「Platform Configuration Register（PCR）」と呼ばれる暗号学的ハッシュを保存する一連のレジスターがあります。
「PCR」には重要なシステムコンポーネントの測定値が保存されます。
これらのハッシュにより信頼のチェーンを作成でき、リモートでシステムを認証することも可能になり（Remote Attestation）、システムの完全性と信頼性を確保できるようになります。
3. ブートの計測
「PCR」ではブートプロセスにおいて使用される様々なコンポーネントを暗号学的に計測し、セキュアな記録やログを作成します。ファームウェアの初期化からOSカーネルの読み込みまで重要な時点において計測が実施されます。
この計測結果は各種コンポーネントの内容を一意に表すハッシュ値として「PCR」に保存されます。
ブートの計測では「TPM」の「PCR」を活用して測定値を安全に保存し、改ざんされないことを保証します。
この計測結果と期待される計測結果とを比較し、ブートプロセスで不正もしくは意図しない変更が発生したかどうかを確認し、改ざんや悪意あるソフトウェアによるシステムの侵害の可能性を検知することができます。
TPMによるFDEのアーキテクチャー
それでは「TPM」による「FDE」のアーキテクチャーを見てみましょう。TPMによるFDEの利点
「TPM」による「FDE」の利点は、ユーザーが起動時にパスフレーズを手動で入力する必要がなくなり、前述のセキュリティー強度をパスフレーズの依存から切り離すことができる点です。また企業では組織で利用するPCなどデバイスの暗号化の導入障壁が低くなり、大規模に展開されるデバイスの管理や運用効率の向上に期待できます。
また「TPM」に加えパスフレーズの導入も可能です。
パスフレーズを導入すれば攻撃者がオフラインで攻撃する「ブルートフォース攻撃」にも対抗できるようになります。
設計原則
さてこれらの利点を実現するために「TPM」による「FDE」の実装では、2つの主要な設計原則に依存しています。1つ目は、カーネルのコマンドラインを含む「FDE」の秘密鍵をEFI Stateにシール（封/封印）することです。
2つ目は、復号鍵へのアクセスは機密データへのアクセスが承認されているソフトウェアのみがアクセスできることです。
「initrd」はデバイス起動時にセキュアブートで保護された「kernel.efi」内で復号鍵のシールを解除します。
TPMによる鍵の保護
「TPM」には様々なオブジェクト（アイテム）を保護する4つの階層があります。「FDE」ではこの階層の内の1つ、ストレージ階層を利用します。
オブジェクトには様々な用途があります。
署名や鍵交換で利用される非対称の鍵や、対称的な暗号化や「HMAC」で使用される対称的な鍵、外部の機密データを保護するオブジェクト、他のオブジェクトを保護する目的で利用可能なストレージキーなど様々な用途を持つオブジェクトがあります。
これらのオブジェクトをどこかに格納する必要があるのですが、「TPM」が提供するストレージ容量は限られており、多くのオブジェクトはストレージキーにより暗号化され、「TPM」の外部に保存されます。
「Ubuntu」の「FDE」ではディスクの暗号鍵を「TPM」の外部に保存し、「TPM」のストレージ階層内でシールされたデータオブジェクトとして保護されます。
「TPM」は機密データへのアクセスが事前に承認されているブート環境だった場合、「initramfs」のコードから鍵をアクセスできるようにします。
その一方でブート環境で使用されるコンポーネントが変更されていた場合、「TPM」は鍵へのアクセスを拒否します。
これを実現するためには「TPM」に適切な認証ポリシーが必要になります。
TPMの認証ポリシー
「TPM」リソースでは機密情報にアクセス可能な条件を指定する認証ポリシーを作成でき、この認証ポリシーで「PCR」の値が事前に計算された値と一致していることを要求する認証ポリシーを作成できます。この認証ポリシーを利用して特定のブート環境のみが鍵にアクセスできるようにしています。
またこの認証ポリシーでは、ブート環境で使用されるコンポーネントが変更されていた場合、アクセスを拒否するように設定されています。
このコンポーネントには、ブートローダー、カーネル、「initramfs」のコード、セキュアブートの構成、カーネルのコマンドラインが含まれています。
Snapdの役割
通常「Ubuntu Dektop」ではカーネルなどPCの起動に使用されるソフトウェアはDebianパッケージ（.debパッケージ）で構成されています。「TPM」による「FDE」は「Ubuntu Core」と同じアーキテクチャーに基づいており、その設計や実装方針は「Ubuntu Core」と共有しています。
つまりブートローダー（shimとGRUB）やカーネルは、Snapパッケージで提供されます。
そしてこれらのSnapパッケージを管理する役割は「snapd」が担います。
ブートローダーとカーネルを超えた部分は従来の「Ubuntu Dektop」と同じ環境になります。
