認証付き暗号

認証付き暗号（AE: Authenticated Encryption あるいは AEAD: Authenticated Encryption with Associated Data) とは、データの秘匿性、完全性、および認証性を同時に提供する暗号利用モードである。利用の容易な API ひとつでこうした特性が提供されるうえ、復号すると同時に完全性も検証される。

AE の必要性が明らかになったのは、秘匿用モードと認証用モードを安全に合成するのが困難であろうとの報告による。[1][2] このことは、実際に運用されているプロトコルやアプリケーションにおいて認証の不適切な実装や実装の欠如によって、実用的な攻撃経路がいくつも入りこんできたことで実証されている (SSL/TLS はその一例である)。[3]

2000年にCharanjit Jutlaによって発表された IACBC および Integrity Aware Parallelizable Mode（英語版） によってこの分野の研究が活発となった[4]。6種類の異なるモード (OCB 2.0、Key Wrap、CCM、EAX、Encrypt-then-MAC (EtM) および GCM) が ISO/IEC 19772:2009 によって標準化され[5]、さらにNISTによって開発がすすめられた[6]。Sponge functions can be used in duplex mode to provide authenticated encryption.[7]

AE モードの典型的な API は次のような関数を提供する:

• 暗号化
  • 入力: 平文、鍵、場合によりヘッダ — これは平文で、暗号化はされないが認証保護の対象である;
  • 出力: 暗号文、認証タグ (MAC)
• 復号
  • 入力: 暗号文、鍵、認証タグ、場合によりヘッダ;
  • 出力: 平文、あるいは、認証タグが暗号文とヘッダに合致しない場合はエラー

ヘッダ部はネットワークや記録の目的で使われるメタデータの認証や完全性保護のためにあるので、秘匿する必要はなく、認証する必要がある。

秘匿性と完全性の保護に加えて、認証付き暗号は平文既知性 (PA: plaintext awareness) を備えており、選択暗号文攻撃に対して安全である。この種の攻撃で敵は、よく考えられた暗号文を "復号オラクル" に渡して復号結果を分析することで、暗号システムの攻略ヒント (たとえば秘密鍵に関する情報など) を得ようとする。認証付き暗号システムは不適切に細工された暗号文を識別して復号を拒否することができる。これはつまり、適切に暗号化アルゴリズムを使って生成しない限り暗号文の復号要求を防ぐということであり、適切に生成したということは平文をすでに知っているということを意味する。適切に実装されていれば、これにより攻撃者がすでに知っている以上の有用な情報を復号オラクルで取り出せないようになる。

共通鍵ブロック暗号で使うための認証付き暗号専用のモードも数多く開発されているが、一般的に認証付き暗号は、暗号システムとメッセージ認証符号 (MAC) を組み合わせて構成する。その場合、暗号システムは選択平文攻撃のもとで強秘匿性を有し、MAC 関数は選択メッセージ攻撃のもとで偽造不可でなければならない。Bellare and Namprempre (2000) はこうしたプリミティブの組み合わせを三通り考察し、暗号と MAC 双方の関数が必要な性質を満たす場合は、メッセージを暗号化してから暗号文に MAC を計算すること (EtM: Encrypt-then-MAC) で適応的選択暗号文攻撃に対し安全であることを実証した。

2013年には、認証付き暗号モードの設計を推進するためのコンペが発表された[8]。

認証付き暗号の手法

Encrypt-then-MAC (EtM)

はじめに平文を暗号化し、暗号文から MAC を計算する。暗号文と MAC を連結して送信される。ISO/IEC 19772:2009 に準拠する標準的な手法[5]。IPSecなどで利用される。これは AE で最高水準の安全性を達成できる唯一の手法であるが、その達成のためには使用する MAC が「強偽造不可」(Strongly Unforgeable)[9] でなければならない。2014年11月に、TLS および DTLS の拡張として EtM を定義する RFC 7366 が勧告された。

Encrypt-and-MAC (E&M)

平文から MAC を計算し、平文はそのまま暗号化される。暗号文と MAC を連結して送信される。SSHや Grain 128a などで利用される。E&M 自体は強偽造不可だと証明されていないが[9]、この手法でも少しの修正で SSH を強偽造不可にすることは可能である^[要出典][10]^[出典無効]。

MAC-then-Encrypt (MtE)

平文から MAC を計算し、平文と MAC を連結した状態で暗号化される。暗号文（暗号化された平文と暗号化された MAC を含む）が送信される。SSL/TLS などで利用される。MtE 自体は強偽造不可だと証明されていないが[9]、SSL/TLS 実装は Krawczyk により強偽造不可であることが証明されている。SSL/TLS は、MtE と同時に使用するエンコーディングのおかげで事実上安全である[11]。

関連項目

• 暗号利用モード
• NIST: Modes Development
• Counter with CBC-MAC (CCM mode)
• CWC mode
• OCB mode
• EAX mode
• Galois/Counter Mode (GCM)
• signcryption

脚注

• Bellare, M.; Namprempre, C. (2000), T. Okamoto, ed., “Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm”, Extended abstract in Advances in Cryptology: Asiacrypt 2000 Proceedings, Lecture Notes in Computer Science (Springer-Verlag) 1976: 531, doi:10.1007/3-540-44448-3_41, ISBN 978-3-540-41404-9 

出典

1. "伝統的な (秘匿のみの) 暗号方式とメッセージ認証符号 (MAC) をくっつけようとするとき、みんなは幾分まずいやり方をしていた", in: M. Bellare, P. Rogaway, D. Wagner. “A Conventional Authenticated-Encryption Mode”. NIST. March 12, 2013閲覧。
2. "ちょっとうっかりしただけで、安全な暗号方式と安全な MAC を結合したのに危険な認証付き暗号方式になってしまいかねない", in: T. Kohno, J. Viega, and D. Whiting. “The CWC Authenticated Encryption (Associated Data) Mode”. NIST. March 12, 2013閲覧。
3. “Failures of secret-key cryptography”. Daniel J. Bernstein. March 12, 2013閲覧。
4. Jutla, Charanjit S. (2000年8月1日). “Encryption Modes with Almost Free Message Integrity”. Cryptology ePrint Archive: Report 2000/039. IACR. 2013年3月16日閲覧。
5. ^ “Information technology -- Security techniques -- Authenticated encryption”. 19772:2009. ISO/IEC. March 12, 2013閲覧。
6. “Encryption modes development”. NIST. April 17, 2013閲覧。
7. The Keccak Team. “Duplexing The Sponge”. November 30, 2013閲覧。
8. “CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness”. March 12, 2013閲覧。
9. ^ “Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm”. M. Bellare and C. Namprempre. April 13, 2013閲覧。
10. “OpenSSH 6.1 からの変更点”. 春山征吾. December 1, 2013閲覧。
11. “The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)”. H. Krawczyk. April 13, 2013閲覧。