ドライブにはハードウェア暗号化をうたうラベルが貼られています。接続してパスワードを設定すれば、あとはチップが処理してくれる――多くの人はそう信じています。実際、何百万台ものラップトップやワークステーションが、TCG Opal2規格に準拠したソリッドステートドライブ(SSD)でこの仕組みを採用しています。
Milan Brož氏と3人の同僚は、こうしたドライブを38台購入し、検証環境でテストを行いました。Brož氏は、ほとんどのLinuxシステムでディスク暗号化の設定に使われるツール「cryptsetup」のメンテナーです。ドライブはSamsung、Western Digital、Micron、Kioxiaなど各社製で、新品の在庫品とラップトップから取り外された中古品の両方が含まれていました。研究チームは各ドライブをブラックボックスとして扱い、Opal2仕様書が定めるコマンドのみを送信して検証しました。
結果、複数のドライブが基本的な項目で不合格となりました。
ドライブの何が問題だったのか
Lenovo製OEMドライブ2台は、全セクタを同一のtweak値で暗号化していました。AES-XTSは、ディスク上の位置によって同一データが異なる見た目になるよう、このtweak値に依存しています。ドライブ全体で値が1つしかなければ、同一の内容を2箇所に書き込んでも同一の暗号文が生成されてしまいます。つまり、ファイル内のパターンが暗号化データにそのまま残ってしまうのです。
同じ2台のドライブは、呼び出すたびに予測可能な連番を返す乱数生成器を搭載していました。あるSanDisk製SATAドライブは、特定のバイト値「0x8B」に偏った出力を返し、想定される頻度のおよそ2倍の頻度でこの値を出力していました。Opal2規格では全ドライブにこの乱数生成器の搭載を義務付けているものの、その品質については規定していません。
tweakの欠陥は、鍵変更によって本来消去されるはずだったデータの残留パターン情報を露出させるものですが、研究者らは実際に悪用される可能性は非常に限定的だと評価しています。一方、乱数生成器の弱さは、そこから鍵を取得するソフトウェアにとっては重要な問題です。研究チームはそうした製品を探しましたが、該当するものは見つかりませんでした。暗号化鍵そのものはドライブ内に保存されたままです。
リセットトークンにも独自の問題がありました。すべてのOpal2ドライブには、ラベルに印字されたコードでドライブを工場出荷時状態に初期化できる「PSID」が搭載されています。あるSanDisk製ドライブのロットでは、このコードが連番で生成されており、接頭辞と接尾辞が共通していました。1台のドライブのPSIDが判明すれば、番号をカウントアップするだけで隣接するドライブのPSIDも入手できてしまいます。さらに、他の6台のドライブは、有効なPSIDに任意の文字列を付け足しても正しいものとして受け入れてしまう仕様でした。
ベンダーはハードウェア暗号化を売り込むが、誰も検証していない
企業がOpal2ドライブを導入するのは、保存データの暗号化要件を満たすためです。購買担当者は仕様書に「ハードウェア暗号化」と書かれているのを見て、チェックを入れるだけです。このラベルとチップの実際の動作との間にあるギャップは、長年にわたり独立した第三者による検証を受けてきませんでした。
今回の調査は、複数ベンダーのOpal2ドライブを横断的に比較したセキュリティ検証としては初めてのものです。自己暗号化SSDに関する前回の大規模な公開研究は2019年に行われたきりでした。Samsung製ドライブの乱数生成器の偏りは、研究者がすでにリバースエンジニアリング済みだったドライブでさえ、これまで見過ごされていました。今回すべてを明らかにした手法は、中古SSDを購入してスクリプトを実行するという、いたってシンプルなものでした。
マーケティング上の表現も事態をさらに混乱させています。研究チームは当初50台以上のドライブから調査を始めましたが、そのうち12台は関連規格である「Pyrite2」にのみ対応するものだったため除外しました。Pyrite2はパスワードの照合を行うだけで、データ自体は平文のまま保存されます。それにもかかわらず、ベンダーはこうしたドライブを「ハードウェア暗号化」対応としてカタログに記載して販売しているのです。
情報開示は成果に結びつかなかった
Brož氏らのチームは、発見したすべてのセキュリティ問題を該当ベンダーに報告しました。Micronは、自社のCrucial T500に存在するセクタサイズのバグに対してファームウェア修正を提供しました。しかし、それ以外の報告はすべて「既知の問題で未修正」「サポート終了」、あるいは音沙汰なしという結果に終わりました。複数のベンダーは、暗号化ファームウェアの不具合を指摘されても、その機能自体を廃止扱いにし、顧客にはソフトウェア暗号化の利用を促すという対応を取っています。
ファームウェアの更新入手も依然として困難です。多くの場合、ベンダー提供のWindows専用ツールか起動用イメージが必要になります。Linux Vendor Firmware ServiceはOEMドライブの一部をカバーしていますが、それ以外はまだ存在しているサポートサイト頼みという状況です。
何が修正されたのか
このプロジェクトはコードの形で成果を公開しました。Opal2対応はcryptsetupに実装されました。シングルユーザーモードは、それに必要なLinuxカーネル側の変更とともに、次期リリースに向けて準備が進められています。研究チームはOpal Test Suiteも公開しており、誰でも同じ検証を自分のドライブに対して実行できるようになりました。
テストした中の3台のドライブは、実用的なディスク暗号化には使用できないという結果になりました。ドライブの管理者がユーザーのデータをロック解除できないようにする機能「シングルユーザーモード」についても、状況は同様です。この機能をうたうドライブは24台ありましたが、実際に十分な水準で対応していたのは14台にとどまりました。
現在のcryptsetupは、ドライブを信頼する前にシングルユーザーモードのファームウェアをチェックし、検証に失敗した場合はより安全な設定にフォールバックするようになっています。実務上の指針は、当初の販売文句とは正反対のものになりました。ドライブ自体の暗号化の上にソフトウェア暗号化を重ねがけし、ハードウェア側の機能は第二の防壁として位置づける、というものです。
データを暗号化すると謳うドライブは、他のセキュリティ対策と同様の厳しい精査を受けるべきです。そのための検証ツールは今やオープンソースとして誰でも利用でき、実際にそれを最初に適用しただけで、実データを保存している現場のマシンで壊れたファームウェアが発見されたのです。
翻訳元: https://www.helpnetsecurity.com/2026/07/21/hdd-self-encrypting-drive-security/
