FDEとは

FDEはFull Disk Encryptionの略で、ディスク全体を暗号化する仕組みのことです。暗号化するということは復号するということでもありますが、その際には直感的にパスワードが必要になるはずです。しかしそれは、起動するたびにパスワードを入力する必要があることを意味し、現実問題として面倒でやってられません。

Windowsでは、Windows 11の動作要件を満たしたPCに、TPMというセキュリティモジュールが搭載されています。このTPMの詳細については第846回をご覧ください。

このTPMを使用すれば起動するたびにパスワードを入力する必要がなくなるのでは、ということで、第783回で紹介したようにUbuntu 23.10から実験的機能として提供されてきました[1]。

それから幾年、来週リリース予定の26.04 LTSからはいよいよFDEが実用できそうな段階まできました。そこで今回はリリースに先だって紹介します。

なお、FDEはWindowsでいうところのBitLockerであるといいたいところですが、BitLocker以上にいろいろと気遣うことが多いです。そのあたりも見ていきましょう。

FDEの注意点

FDEの注意点は、何はなくともリカバリーキーを紛失しないということです。BitLockerでも同じなのですが、BitLockerの場合は上手にリカバリーキーを意識させないような仕組みになっていますが、FDEでははっきりと意識する必要があります。

そして、本記事の執筆段階では明らかになっていませんが、FDEを有効にした場合にUbuntuのアップグレードはできないかもしれないという覚悟は必要です。26.04はLTSなので標準サポートが5年間、Ubuntu ProのExpanded Security Maintenance (ESM)によってさらに5年間、Legacy Addonを含めるとさらに5年追加されます。ただ、ハードウェアの運用期間を考慮すると現実的な期間を超えるため、考慮しなくてもいいでしょう。

また特性上、自前でビルドしたカーネルモジュール（DKMSも含む）の使用はできません。ただしNVIDIAのドライバーに関しては例外ではあります。

そのほか、BitLockerのようにあとから解除はできません。使うのをやめたくなったら再インストールするしかありません。よってデータはなるべく手元のPCには保存せず、クラウドストレージサービス（Nextcloudも含め）に置くのが推奨となりますが、FDEを使う意義を問われると厳しいものがあります。

FDEの使いどころ

GNOMEのオンラインアカウント機能でファイルを同期すると、手元にはデータは全く残りません。メールをWebメールで運用すれば、ほぼ手元のPCには何も置かないという運用は可能です。このような運用であれば、FDEを使っても手元のデータを少なくすることはできます。

仮に第三者によってPCが取得され、ストレージ上のデータを読み取ろうとしたとき、その悪意ある者がUbuntuやLinuxに対して充分な知識がない可能性は極めて高いでしょう。それでもExt4形式であれば読み取れるかもしれませんし、LVM2形式を使用しているのであれば読み取られる可能性はさらに減るといっても0ではありません。

生成AIがこれだけ普及している昨今、断片的な情報からでもアクセスする方法にたどり着けてしまうことは充分考えられます。そのあたりはなんとも世知辛いところです。

このような事情を踏まえると、FDEを使用することは第三者によって読み取られる可能性を0にできることを意味します。何せ自分自身であってもリカバリーパスワードを紛失してしまえばアクセスできなくなるような代物です。

このメリットと、前述のデメリットをよく検討し、実際に運用するかを決定してください。もちろん所属する組織のルールとして決定している事項があれば、それに従うこととなります。換言すると、FDEを採用していないデバイスを使用できないというルールがあったとしても、Ubuntuを採用できることになります。

そもそも例を上げるまでもなく一番脆弱なのは人間なので、あくまでツールでセキュリティを向上するのは補助的なものである、という意識を持つことが何よりも重要と考えます。

FDEのセットアップ

FDEを有効にし、Ubuntu 26.04 LTS（開発版）をインストールします。

今回は例としてVirtualBoxの仮想マシンとしてインストールします。忘れずに「TPM」を「2.0」にし、「⁠セキュアブートを有効化」にチェックを入れてください（図1）。

通常どおりインストールを進め、「⁠暗号化とファイルシステム」で「ハードウェアベースのディスク暗号化を使用」を選択し、次へ進みます（図2）。

インストールがほぼ完了すると、「⁠リカバリーキーを保存してください」という画面に遷移します（図3）。

リカバリーキーをファイルとして保存するか、QRコードを表示するか、もちろん両方でもいいのですが、何らかの方法で保存します。

「ファイルに保存」はローカルのフォルダーには保存できないようになっており、NASへの保存か、今回は試していませんがUSBメモリー等への保存が強制されます（図4）。

NASは安全なところであると考えられるので、USBメモリー等の外部媒体よりは安全といえます。しかし前述のとおり一番脆弱なのは人間なので、カバーする方法はいろいろあるでしょう。

QRコードで保存するのも手です（図5）。

保存したら「安全なところにリカバリーキーを保存しました」にチェックを入れて「次へ」をクリックします。

前述のとおり、DKMSには原則として対応しないため、VirtualBox Guest Additionsのインストールはできません。

セキュリティセンターでのリカバリーキー管理

「セキュリティセンター」にリカバリーキーの管理機能が追加されました（図6）。

できることは、リカバリーキーの確認と変更です。

「Check recovery Key」をクリックするとリカバリーキーの入力欄が表示され、入力されたリカバリーキーが正しいかどうかの確認ができます（図7）。

どのような機会に利用すればいいのか考えあぐねてしまいますが、複数のリカバリーキーがあってどれが該当するかわからなくなった場合には便利かもしれません。

「Replace recovery key」は、リカバリーキーがわからなくなった場合に新しいリカバリーキーを発行するための機能です（図8）。

以前は現在のリカバリーキーを表示するコマンドもあったのですが、25.10からは使用できなくなったようです（図9）。

FDEだけではなく、「⁠Additional security」でパスフレーズとPINコードの設定もできます。しかし今回は紹介しません。

なお、セキュリティセンターが翻訳されていないのは翻訳自体が行われていないわけではなく、ソースコードに取り込むプルリクエストが処理されていないからです。おそらく26.04 LTSのリリース時点でも同様であろうという予想のもと、英語で紹介しています。

再起動時の問題

再起動するとリカバリーキーの入力を求められることがあります（図10）。

これはTPMのセキュリティ状態の変化によるものです。回避策として『電源のオフ』から『オン』を行うと、TPMの状態がリセットされ、通常どおり起動できます。どうしようもならない場合は強制終了する手もありますが、システム破損のリスクがあるため推奨しません。