AES-256-GCM：iPhoneのファイルを守る認証付き暗号の標準

TL;DR

AES-256-GCMは、1つの鍵とメッセージごとに一意のノンスを使ってデータを暗号化し、その完全性を検証する認証付き暗号アルゴリズムです。NIST標準で定義され、最新のiPhoneでハードウェアアクセラレーションに対応し、TLS 1.3、WireGuard、Signalで使用されています。AppVaultでは、ファイルごとに96ビットの一意ノンス、PBKDF2で導出した鍵をSecure Enclaveでラップし、ネットワーク通信なしでAES-256-GCMを適用します。

AES-256-GCMは単一のアルゴリズムではありません。256ビット鍵のAdvanced Encryption Standard（AES）とGalois/Counter Mode（GCM）という2つの標準の組み合わせです。これらが一体となって、機密性と完全性検証を1パスで提供する認証付き暗号方式を形成します。TLS 1.3、WireGuard、Signal、iOSのファイルレベル暗号化でデフォルトの暗号として採用されています。その仕組みを理解することが重要なのは、AES-256-GCMのセキュリティ上の失敗のほとんどが暗号そのものの破壊ではなく、実装上のミスに起因するからです。

ブロック暗号の基礎——「256ビット鍵」の意味、鍵空間が総当たり攻撃で破られない理由、2001年にNISTがAESを選定した経緯——については、平易な言葉で解説した「AES-256暗号とは？」を先にお読みください。本記事では特にGCMモードに焦点を当てて詳しく解説します。

ブロック暗号：AES-256

AESは、NISTのFIPS 197で標準化された対称ブロック暗号です。128ビットのブロックを処理し、鍵長は128、192、256ビットをサポートします。AES-256は256ビット鍵を使用し、14ラウンドの置換・転置操作を実行します。各ラウンドでは、SubBytes（Sボックスによる非線形置換）、ShiftRows（バイト転置）、MixColumns（GF(2^8)上の行列乗算）、AddRoundKey（マスター鍵から導出したラウンド鍵とのXOR）の4つの変換を適用します。

AES-256のセキュリティマージンは高いです。既知の最良の暗号解読攻撃は、ラウンド数を減らした変種（例：7ラウンドのAES-128）や、現実の使用には当てはまらない関連鍵モデルに対するものです。完全な14ラウンドのAES-256に対しては、実効鍵長を256ビット未満に減らす実用的な攻撃は存在しません。このため、AES-256は米国国家安全保障局（NSA）により極秘データの使用が承認されています。

AES-256は、事実上すべての最新CPUでハードウェアアクセラレーションに対応しています。IntelおよびAMDプロセッサにはAES-NI命令が含まれています。Apple Silicon（MシリーズおよびAシリーズチップ）には、AES、SHA、GCM操作を高速化するARM Crypto Extensionsが搭載されています。iPhoneでは、10MBのファイルのAES-256暗号化がミリ秒単位で完了します。

モード：Galois/Counter Mode（GCM）

ブロック暗号は一度に1ブロックしか暗号化できません。128ビットより長いメッセージを暗号化するには、動作モードが必要です。NIST SP 800-38Dで規定されたGCMは、暗号化用のカウンターモード変種と認証用のユニバーサルハッシュ関数（GHASH）を組み合わせた認証付き暗号モードです。同じ構成はIETF RFC 5116でAEADプリミティブとして登録されています。

GCMは2つのフェーズで動作します。まず、平文をAESカウンターモードで暗号化します。128ビットのカウンターをブロックごとにインクリメントし、AESで暗号化して平文とXORすることで暗号文を生成します。初期カウンター値はノンス（使い捨て番号）と1から始まるカウンターから導出されます。次に、暗号文と関連データ（認証は必要だが暗号化は不要なメタデータ）をGHASHに入力します。GHASHはGF(2^128)上の多項式評価です。GHASHの出力をAESで暗号化して認証タグを生成します。

結果として得られる出力は、暗号文と128ビットの認証タグ（デフォルト長、短縮可能）です。受信側はタグを再計算して比較することで復号します。タグが一致すればデータは真正です。一致しなければ、受信側はデータを拒否しなければなりません。

GCMは並列処理が可能です。カウンターモードでは複数ブロックを同時に暗号化できるため、ハードウェアアクセラレーションで高いスループットを実現できます。ARM Crypto Extensionsを搭載したiPhoneでは、AES-256-GCMは毎秒数ギガビットの速度で暗号化できます。

ノンスの規律：最も一般的な失敗ポイント

AES-256-GCMにはノンスが必要です。標準では96ビットのノンスを指定しています。ノンスは、同じ鍵で行う暗号化ごとに一意でなければなりません。同じ鍵でノンスを再利用すると、攻撃者はGHASH認証鍵（H）を復元し、任意のメッセージを偽造できるようになります。

数学は容赦ありません。2つの暗号文が同じノンスと鍵を共有している場合、2つのGHASH出力のXORから平文のXORが明らかになります。そこから攻撃者はHを復元し、任意の暗号文に対して有効なタグを生成できます。これは理論上の攻撃ではありません。実際に悪用された事例があり、最も有名なのは2015年の「Nonce-Disrespecting Adversaries」論文で、複数のTLS実装にノンス再利用の脆弱性が発見されました。

正しい対策は、同じ鍵の下でノンスを決して再利用しないことです。実際には、ランダムなノンスを生成するか（96ビットで2^96通りの可能性があるが、誕生日の限界により、衝突確率を無視できるようにするにはランダムノンスで2^32メッセージ以上を暗号化すべきではない）、メッセージごとに一意であることが保証された決定論的カウンターを使用します。

AppVaultはファイルごとに一意の96ビットノンスを使用します。ノンスは暗号学的に安全な乱数生成器（iOSのSecRandomCopyBytes）で生成され、暗号文とともに保存されます。各ファイルが独自のノンスを持ち、鍵はインストールごとに導出されSecure Enclaveでラップされるため、ノンス再利用のリスクは排除されます。

ハードウェアアクセラレーション：なぜ重要なのか

AES-256-GCMはソフトウェアでは計算負荷が高くなります。特にGF(2^128)上のGHASH乗算はハードウェアサポートなしでは非常に高コストです。最新のCPUには、AESラウンドとGHASH操作を1サイクルで実行する専用命令が含まれています。

iPhoneでは、ARM Crypto Extensionsに以下が含まれます：

• AES命令（AESE、AESD、AESMC、AESIMC）：AES暗号化または復号の1ラウンドを実行。
• GHASH命令（多項式乗算用のPMULL/PMULL2）：GHASH計算を高速化。

Apple SiliconのSecure Enclaveには、メインCPUに鍵を公開せずにデータを暗号化できる専用のAESエンジンが含まれています。AppVaultはSecure Enclaveを使用してファイル暗号鍵をラップし、メインCPUが侵害されても鍵が保護されるようにしています。

ハードウェアアクセラレーションがなければ、AES-256-GCMはTLSハンドシェイクや動画ストリーミングのようなリアルタイムアプリケーションには遅すぎるでしょう。アクセラレーションがあれば、オーバーヘッドは無視できます。

AES-256-GCMが使われる場所

AES-256-GCMはTLS 1.3のデフォルト暗号スイート（TLS_AES_256_GCM_SHA384）です。TLS 1.3を使用するすべてのHTTPS接続がこれに依存しています。最新のVPNプロトコルであるWireGuardは、AES-256-GCM（またはハードウェアAESがないデバイスではChaCha20-Poly1305）を使用します。暗号化メッセージアプリSignalは、メディアファイルの暗号化にAES-256-GCMを使用しています。iOSはData Protectionのファイルレベル暗号化にAES-256-GCMを使用しています。

AES-256-GCMの普及は偶然ではありません。NIST標準であり、ハードウェアアクセラレーションに対応し、暗号コミュニティでよく理解されています。認証付き暗号を必要とするあらゆるアプリケーションにとって安全なデフォルトです。

他の認証付き暗号モードとの比較

AES-256-GCMは唯一のAEADモードではありません。ChaCha20-Poly1305は、特にハードウェアAESアクセラレーションがないデバイスで人気のある代替手段です。ChaCha20はストリーム暗号（ブロック暗号ではない）であり、Poly1305はGHASHと同様の多項式ハッシュです。ChaCha20-Poly1305はソフトウェアではAES-256-GCMよりも高速ですが、AES-NI搭載ハードウェアではAES-256-GCMの方が高速です。

AES-256-CCM（Counter with CBC-MAC）もNIST標準のAEADモードですが、並列処理ができずGCMより低速です。CCMは一部のIoTや無線プロトコルで使用されていますが、TLSや最新のアプリケーションのほとんどはGCMを好みます。

AES-256-GCM-SIVはノンス再利用に耐性のある変種で、ノンスが再利用されても（2つのメッセージが等しいことだけを明らかにし、平文は漏らさない）穏やかに劣化します。標準のGCMより低速で、広く展開されていません。

ほとんどのアプリケーションでは、AES-256-GCMが適切な選択です。正しく実装されれば、高速で標準的、かつ安全です。

AppVaultによるAES-256-GCMの実装

AppVaultは、保管庫に保存されるすべてのファイルにAES-256-GCMを使用します。実装は以下の手順に従います。

1. 鍵導出：ユーザーのパターンロックは、60万回の反復とインストールごとの128ビットソルトを用いたPBKDF2-SHA256で256ビットのマスター鍵に変換されます。この鍵は暗号化に直接使用されることはありません。
2. Secure Enclaveによるラッピング：マスター鍵はSecure Enclaveに送られ、チップの外に出ることのない新しい鍵（「ラッピング鍵」）が生成されます。Enclaveはマスター鍵をラッピング鍵で暗号化し、ラップされた鍵をメインCPUに返します。平文のマスター鍵はメモリからゼロで消去されます。
3. ファイル暗号化：ファイルごとに、SecRandomCopyBytesを使用して新しい96ビットノンスが生成されます。ラップされた鍵はSecure Enclave内でアンラップされ、AES-256-GCMでファイルを暗号化するために使用されます。暗号文とノンスはストレージに書き込まれます。認証タグは暗号文に追加されます。
4. カタログ暗号化：ファイルのリスト（名前、日付、サイズ）でさえ、同じマスター鍵から導出された別の鍵でAES-256-GCM暗号化されます。つまり、デバイスに生のアクセス権を持つ攻撃者は、ファイルの数さえも特定できません。

その結果、2つのファイルが同一の平文を含んでいても、同じ暗号文になることはありません。Secure Enclaveにより、暗号鍵がメインオペレーティングシステムに露出することは決してありません。また、AppVaultはネットワーク通信を一切行わないため、鍵や暗号文を漏洩させる可能性のあるサーバーは存在しません。

AES-256-GCMの限界

AES-256-GCMはすべてを保護するわけではありません。実装がタイミングや消費電力を漏洩する場合、サイドチャネル攻撃に対して脆弱です。特にGHASH計算はタイミング攻撃に敏感であり、定数時間実装が必要です。AppleのCoreCryptoライブラリは定数時間のAES-256-GCM実装を提供しており、AppVaultはそのライブラリを使用しています。

AES-256-GCMは前方秘匿性を提供しません。鍵が漏洩すると、過去のすべての暗号文が復号可能になります。前方秘匿性はプロトコルレベル（例：TLS 1.3は一時的Diffie-Hellman鍵交換を使用）で達成されるものであり、暗号自体の特性ではありません。AppVaultは鍵をデバイス上に保持し、決して送信しないことでこれを緩和しています。

AES-256-GCMは量子耐性がありません。グローバーアルゴリズムにより、AES-256の実効鍵長が256ビットから128ビットに低下します。十分に大規模な量子コンピュータがあれば破られる可能性があります。しかし、そのような量子コンピュータは現存せず、今後10年以内の実現も見込まれていません。長期的な秘密には、CRYSTALS-Kyberのような耐量子暗号が標準化されつつあります。

AES-256-GCMは、ゴムホース暗号解読や物理的なデバイス押収に対しては保護しません。攻撃者があなたのiPhoneに物理的にアクセスし、ロック解除を強制できる場合、いかなる暗号もファイルを保護できません。AppVaultの脅威モデルは、デバイスがあなたの管理下にあることを前提としています。

AppVaultがAES-256-GCMを選んだ理由

AppVaultがAES-256-GCMを選んだのは、最新のすべてのiPhoneでハードウェアアクセラレーションに対応し、最も広く展開されている認証付き暗号アルゴリズムだからです。標準化され、ピアレビューを受け、世界最大のセキュリティプロトコルから信頼されています。これにより、AppVaultはバッテリーを消耗することなくファイルを高速に暗号化でき、完全性検証により保存されたファイルが改ざんされていないことを保証します。

代替のChaCha20-Poly1305も安全であり、ハードウェアAESが利用できない場合（例：古いデバイス）の特定の操作にはAppVaultも使用しています。しかし、iOSでのファイル暗号化にはAES-256-GCMが自然な選択です。

AppVault内のすべてのファイルは、AES-256-GCM、一意のノンス、そしてパターンロックから導出されSecure Enclaveでラップされた鍵で暗号化されています。完全な暗号スタックは、AES-256-GCM暗号化のページに、NIST FIPS 197、NIST SP 800-38D、Appleのプラットフォームセキュリティガイドへの引用とともに文書化されています。脅威モデルのページでは、このアーキテクチャが防御するものと防御しないものを説明しています。ゼロ知識アーキテクチャのページでは、AppVaultがあなたのデータを決して見ない理由を説明しています。