暗号化はバイトを隠し、認証はそれを証明する
機密性と完全性は別々の性質であり、後者なしに前者を持つことはあり得ます。データを隠すだけの暗号方式は、渡されたものを何でも復号します——攻撃者が途中で改変したバイトも含めて——そして何事もなかったかのように、その結果をアプリケーションに渡します。
認証付き暗号化は、そのすき間を閉じます。暗号文とあわせて認証タグを生成し、タグが一致しなければ復号はきっぱりと失敗します。保管庫にとって、これは聞こえる以上に重要です。もう一方の選択肢は、改変されたファイルを黙って表示することだからです。
AES-GCM が実際に兼ね備えるもの
AES-GCM は、両方の性質を一度に提供する、確立された構成の1つです。AES をカウンターモードで暗号化し、暗号文に対して認証タグを計算するので、単一の操作で機密性と改ざん検出を実現します。
この構成は、その入力の良し悪しに左右されます。ある鍵のもとで暗号化のたびに一意のノンスを使うこと、そしてその鍵が正しく導出・保管されることに依存します。そのどちらも、アルゴリズム名を挙げるだけでは保証されません。
ノンス管理が静かな失敗の様式である理由
ノンスは、同じ鍵に対して決して繰り返してはならない値です。カウンターモードの構成でそれを再利用すると、そのモードが与えるはずの保証が損なわれ、暗号化された記録同士の関係が露出し得ます。
これはどんなストアの掲載情報も触れない実装の細部であり、それ以外は標準的な設計が誤る、より一般的な様式の1つです。技術文書を公開しているどの保管庫にも、尋ねてよい正当な質問です。
鍵導出と鍵の保管は別々の制御
入力したものから鍵を導出することは1つの問題であり、アプリが閉じている間、その導出した鍵を安全に保つことは別の問題です。保管庫は前者をうまくやりつつ、後者をまずくやることがあり得ます。
これを、2つの答えを持つ2つの問いとして扱ってください。どの関数が、どれだけのコストで認証情報を鍵素材に変えるのか、そして、その結果できた鍵はセッションの間どこに存在するのか。プラットフォームの鍵保管は、まさに後者に答えるために存在します。
文書で探すべきもの
- 鍵の長さだけでなく、名前の付いた認証付き暗号化の構成。
- 暗号化ごとのノンスの一意性についての記述。
- ファイル本体と並んでファイル名やメタデータが保護されるかどうか。
- 鍵導出と鍵の保管が、別々の仕組みとして説明されていること。
- 認証の不一致時に、部分的・最善努力の表示ではなく、明確に失敗すること。
主張を批判的に読む
- 256ビットの鍵というラベルを、完全な設計と同一視すること。
- アルゴリズムが標準だからと、ノンス管理を無視すること。
- 認証付き暗号化がロック解除された画面を守ると思い込むこと——守りません。
認証がカバーしないもの
改ざん検出は、保管庫が管理する記録に適用されます。保管庫を離れたコピーについては、復号された結果を観測する侵害されたオペレーティングシステムについては、あるいはファイルが開いている間に画面を読む人については、何も語りません。
認証付き暗号化は、保存状態のデータに関する保証です。強力な保証であり、そして狭い保証です。
Leo はまず、機微でないデータでテストします。「技術文書に、名前の付いた認証付き暗号化の構成があるか探す」。次に Leo は2つ目の確認手順に従います。「ファイル本体と並んで、ファイル名やメタデータが保護されるかを確認する」。この架空のシナリオは判断の流れを示すものであり、製品テストの報告ではありません。
- 256ビットの鍵というラベルを完全な設計と同一視すること
- ノンス管理を無視すること
- 暗号化がロック解除された画面を守ると思い込むこと
AES-GCM は削除を防ぎますか？
いいえ。機密性と完全性を守るもので、可用性を守るものではありません。
認証は利用者のログインを意味しますか？
ここでは、アカウントへのサインインではなく、暗号学的な完全性の認証を意味します。