認証付き暗号：AES-GCMとChaCha20-Poly1305

Authenticated Encryption（AE）は、基本的な問題を解決します。従来の暗号化は機密性、つまりデータを秘密に保つことだけを提供し、暗号文が改ざんされていないかは検証しません。攻撃者が暗号文のビットを反転させても、受信者は改変されたことを知らずに壊れたデータを復号してしまう可能性があります。Authenticated Encryption with Associated Data（AEAD）は、完全性と真正性を同時に保証し、暗号化された暗号文と、改変を検出する認証タグの両方を生成します。

AES-GCM（Galois/Counter Mode）は、暗号化用のAES-CTR（Counter Mode）と、完全性検証用のGMAC（Galois Message Authentication Code）という2つの要素を組み合わせます。AES-CTRはカウンタ値を暗号化し、それを平文とXORすることでキーストリームを生成します。そのため、CBCモードとは異なり、暗号化を並列化できます。GMACは、暗号文と関連データに対して認証タグを計算します。生成されたタグ（128ビット）は暗号文とともに送信され、1ビットでも変更されるとタグは無効になります。

AES-GCMでは、通常96ビット（12バイト）のnonce（number used once：一度だけ使用する数値）が必要です。nonceは、同じ鍵を使うすべての暗号化処理ごとに一意でなければなりません。秘密にする必要はありませんが、決して再利用してはいけません。AES-GCMでnonceを再利用すると、深刻な事態になります。同じ鍵とnonceで2つのメッセージを暗号化すると、攻撃者は暗号文同士をXORしてキーストリームを打ち消し、両方の平文を復元できる可能性があります。この脆弱性は「nonceの誤用」と呼ばれることがあり、実際に鍵の復元攻撃を引き起こしています。

AES-GCMでnonceを再利用すると、同じキーストリームが使われるため、攻撃者は C1 XOR C2 = P1 XOR P2（2つの平文のXOR）を計算できます。さらに、nonceの再利用によって認証鍵Hを復元できるため、攻撃者は任意のメッセージに対して有効な認証タグを偽造できます。これにより、機密性と完全性の両方が完全に破られます。Sony PS3などのシステムは、まさにこの攻撃の被害を受けました。対策は、CSPRNGで生成したランダムなnonceを使うか、決してリセットされない決定論的なカウンターを使うことです。

ChaCha20-Poly1305は、TLS 1.3で必須とされているもう1つのAEAD暗号です。ChaCha20はDaniel Bernsteinが設計したストリーム暗号で、加算・ローテーション・XOR（ARX）演算によってキーストリームを生成します。ルックアップテーブルを使わず、完全なconstant-timeで動作し、AESのハードウェアアクセラレーションに対応していないCPUでも非常に高速です。Poly1305はワンタイムMAC（メッセージ認証コード）で、暗号文から認証タグを計算します。両者を組み合わせることでAES-GCMと同等の安全性を実現しながら、モバイル端末やIoTデバイスでは大幅に高速に動作します。

現在のx86およびARM64のデスクトップ・サーバープロセッサには、AES-GCMを非常に高速にするAES-NIハードウェア命令が搭載されています。しかし、多くのモバイルやIoT向けプロセッサにはAES-NIがないため、ソフトウェア実装のAES-GCMは比較的低速です。ChaCha20-Poly1305は単純な算術演算によってソフトウェアで高速に動作するよう設計されており、ハードウェアアクセラレーションなしでもモバイル端末で同等の性能を実現できます。GoogleはまさにAndroidデバイス向けの代替方式としてChaCha20-Poly1305をTLSに追加し、現在ではTLS 1.3の主要な暗号スイートとなっています。

AEADの「AD」はAssociated Data（関連データ）を意味します。これは暗号化はされないものの認証される平文のメタデータです。これにより、パケットヘッダーやレコード種別フィールドのように読み取り可能な状態を保つ必要があるデータについても、改ざんから保護できます。TLS 1.3では、レコードヘッダーのバイト列がAEADの計算に関連データとして含まれます。攻撃者がヘッダー（たとえばレコード長）を変更すると、認証タグの検証に失敗し、接続が終了します。

AEADが標準になる前、暗号学者はEncrypt-then-MAC（EtM）を推奨していました。これは平文を暗号化した後、暗号文に対してMACを計算する方式です。安全な方式ですが、2つの別々の鍵を使って2つの処理を行う必要があります。AES-GCMのようなAEAD方式は、1つの鍵で両方の処理を組み合わせます。そのため実装が簡潔になり、古いTLSバージョン（CBC + HMAC）で使われていたMAC-then-Encrypt（MtE）が引き起こしていたパディングオラクル攻撃の一連の問題も解消できます。AEADを使うTLS 1.3では、これらの問題が完全に回避されています。

AES-128-GCMとAES-256-GCMはいずれもNISTに承認されており、古典コンピューターに対して安全だと考えられています。AES-128は128ビットの安全性を提供し、わずかに高速です。AES-256は256ビットの安全性を提供するため、将来の暗号解析や量子脅威に対する余裕が大きくなります。現在のほとんどの用途ではAES-128-GCMで十分ですが、政府の機密システム（NSA Suite B）ではAES-256が必要です。TLS 1.3は両方を提供しており、サーバーはセキュリティポリシーに応じて優先順位を設定できます。

AEAD暗号文を復号するとき、受信側は復号する前に認証タグを検証しなければなりません。手順は次のとおりです。受信した暗号文、鍵、nonceから期待されるタグを再計算し、constant-time比較関数を使って受信したタグと比較します。一致した場合に限り、復号を実行します。constant-time比較は非常に重要です。比較が最初に一致しなかったバイトで短絡終了すると、攻撃者はタイミングサイドチャネル攻撃によってバイト単位で有効なタグを偽造できます。早期終了型の比較を使うAEADライブラリには脆弱性があります。

AEADアルゴリズムは、現代のセキュリティで広く使われています。TLS 1.3はすべてのレコード暗号化にAES-GCMとChaCha20-Poly1305を使用し、WireGuard VPNはChaCha20-Poly1305だけを使用します。Signal Protocolはメッセージの暗号化にこれを使用し、QUIC protocol（HTTP/3の基盤）はAES-GCMを使用します。TLS_AES_256_GCM_SHA384のような暗号スイートを見かけた場合、SHA384は整合性機構ではなく鍵導出に使うHKDFのハッシュ関数を指します。整合性はGCMタグが処理します。

このレッスンで学んだCompTIA Security+（SY0-701）の概念を確認しましょう。

このレッスンでは、AEADアルゴリズムが認証タグによって機密性と完全性を同時に提供すること、暗号文の変更を検出できることを学びました。また、AES-GCMでnonceを再利用すると、キーストリームの復元や認証鍵の偽造が可能になるため深刻な結果を招くことから、暗号化ごとにnonceを一意にする必要があります。さらに、ChaCha20-Poly1305はAESのハードウェアアクセラレーションを利用できないデバイス向けの、性能効率に優れたAES-GCMの代替方式です。次は、パスワードを安全に保護するための鍵導出関数について学びます。