要約

  • RFC 3268はTLSの交渉方式を置き換えず、従来のメニューにAESの暗号スイート識別子を12個加えた。6種類の鍵交換・認証方式に、2種類の鍵長を組み合わせた数だ。
  • AES-256という名前だけでは相手の認証も前方秘匿性も得られない。そこはハンドシェイクの選択と実装に左右される。

AESを交渉するには共通の名前が要った

AESが標準になっても、それだけでTLSの接続相手が同じ設定を選べるわけではない。両者が共有するパラメーター名が必要だった。TLS 1.0にはすでに仕組みがある。クライアントはClientHelloに暗号スイートの一覧を載せ、サーバーは対応する一つを選ぶ。RFC 2246でスイートとは、鍵交換、データ暗号、メッセージ認証を束ねた組み合わせを指した。

2002年6月のRFC 3268は、その仕組みにAES-CBCとHMAC-SHA-1を載せた。だが追加したのは「AES」という一択ではない。RSA、DSSまたはRSA証明書を使う静的DH、DSSまたはRSA署名付きの一時的なDHE、そして匿名DHという6つの系統を定義し、それぞれに128ビットと256ビットのAES鍵を用意した。結果は12個のスイート識別子である。

名前の違いは単なる互換性ではない。RSA、認証済みDH、匿名DHでは相手を信頼する根拠が違う。DHEは一時鍵を再利用せず安全に破棄し、過去の出力を漏らさない乱数を使えば前方秘匿性を提供できる。匿名DHは認証を提供せず、中間者攻撃に弱い。別の手段で双方が同じTLS Finishedメッセージに結び付いていると確認できない限り、その穴はAESでは埋まらない。

AESには128、192、256ビットの鍵長があるが、RFCはスイート名の増殖を抑えるため128と256だけを採用した。全スイートが使うAESのブロック長は128ビットで、鍵が長くてもブロックは大きくならない。CBCとHMAC内のSHA-1も同じパッケージの一部だった。「AES」は組み合わせの一部しか表していない。

互換性を保つ代わりに選択肢は増えた

RFCの導入部は、当時のDHEスイートが主にTriple-DESで、適切とはいえない短い鍵の輸出用バリエーションもあったと説明する。AESはClientHelloやTLS 1.0のネゴシエーションを変えずに加えられた。そのかわり各組み合わせに登録名、番号、ポリシー、実装上の責任が生まれた。

レジストリへの登録は、製品の対応、優先選択、実際の接続での交渉を示すものではない。後続の設計には変化が見える。TLS 1.2では多くのスイート名が鍵交換まで含んでいたが、TLS 1.3ではスイートがAEADとハッシュを指し、鍵交換グループと署名アルゴリズムを別々に交渉する。RFC 3268はAES採用だけでなく、TLSが選択責任をどこに置いてきたかを示す史料でもある。

この歴史から読めるのは、暗号方式、鍵長、認証、鍵交換、レコード保護を分けて評価せよということだ。暗号スイートは交渉済みの一式である。名前の一語だけを安全性の評決と見なすと、接続全体ではなく部品を見てしまう。

参照資料