Linux カーネルのリグレッション：サスペンド時に LUKS 暗号化キーが消去されない
Linux カーネルのリグレッション：サスペンド時に LUKS 暗号化キーが消去されない
Linux 6.9（2024 年 5 月）で導入されたリグレッションにより、サスペンド‑to‑RAM 中に LUKS ディスク暗号化キーがメモリに残り続け、これらのキーを消去するはずのセキュリティ機構が事実上無効化されました。この脆弱性により、ノートパソコンが電源オンのままサスペンド状態で押収された場合、コールドブート攻撃やその他の RAM ダンプ手法によって暗号化データが漏洩する恐れがあります。
根本原因：静かなリファクタリング失敗
暗号化キーはスレッド終了時に破棄されるべきという期待に反し、カーネル内のブロックデバイスアクセスのリファクタリングがキー消去ツールの失敗を静かに引き起こしました。この問題は、ブロックデバイスアクセスをファイルへ移植した特定のカーネルコミットに起因し、暗号化コードとの予期せぬ長距離相互作用が原因でした。
システムは通常通り動作し続け、ノートパソコンはエラーなくサスペンド・レジュームできたため、リグレッションは 2 年以上検出されませんでした。コミュニティメンバーが指摘するように、この種のセキュリティバグはシステムクラッシュや機能障害を引き起こさないため、自然に表面化しにくいのです。
発見と緩和策
この脆弱性は Ingo Blechschmidt がソースコード解析とメモリフォレンジックを組み合わせて発見しました。Debian 風の cryptsetup-suspend ツールを NixOS に統合しようとした際、ドキュメントではキーが削除されるはずとあるにもかかわらず、/proc/keys のエントリが残っていることに気付きました。QEMU 上で仮想マシンを起動しメモリをダンプしたところ、ボリュームキーが RAM に残っていることが確認されました。
現在の修正と回避策
- カーネルパッチ：物理ブロックデバイス上の暗号化ボリュームの一般的なケースに対応する 1 行のカーネルパッチが作成されました。ただし、仮想ループデバイスをカバーしていないため不完全であることが後に指摘されました。
- Cryptsetup の更新：
cryptsetupチームの Ondrej Kozina がカーネルバグを回避するワークアラウンドを開発しました。この修正はcryptsetup2.8.7 リリースに含まれる予定です。 - NixOS 実装：NixOS 向けに実験的な「セキュアサスペンド‑to‑RAM」プロジェクトがリリースされました。これは Pali Rohár が作成した古いカーネルパッチを復活させ、サスペンド時に LUKS キーを消去します。
- 代替電源状態：この脆弱性を懸念するユーザーは サスペンド‑to‑disk（ハイバーネーション） を利用できます。サスペンド‑to‑RAM と異なり、ハイバーネーションは RAM の内容を暗号化されたスワップパーティションに書き込み、メモリの電源をオフにするため、キーが平文のまま RAM に残りません。
脅威モデルと技術的背景
この修正が対象とする主な脅威は コールドブート攻撃 です。攻撃者が電源が入っている（ただしサスペンド状態の）マシンに物理的にアクセスし、RAM の内容をダンプして暗号化キーを取得する手法です。
メモリセキュリティに関するコミュニティの見解
このバグに関する技術的議論では、複数層のディフェンス・イン・デプス戦略が取り上げられました。
"CPU が対応しているなら、メモリ暗号化を有効にしてください… 平文は CPU パッケージを出ません。DIMM スワップ攻撃は無意味になります。"
他のユーザーは TPM の MemoryOverwriteRequestControl などの機能を利用して、ブート時にメモリが確実に消去されるよう提案しました。また、バグの範囲についても議論があり、cryptsetup luksSuspend は主に Debian 固有の拡張であり、上流 Linux のコア機能ではないため、影響は特定ディストリビューションに限定されるという意見も出ました。
修正の概要
| 方法 | セキュリティレベル | 使いやすさ |
|---|---|---|
| サスペンド‑to‑RAM（未パッチ） | 低（キーが RAM に残る） | 高 |
| サスペンド‑to‑RAM（パッチ適用） | 中（キーが消去される） | 高 |
| ハイバーネーション（サスペンド‑to‑Disk） | 高（RAM が電源オフ） | 中 |
| ハードウェアメモリ暗号化 | 非常に高 | 高 |