第115回IETF 参加報告 [第3弾] セキュリティエリア関連報告

先日公開した第115回IETF 参加報告 「[第1弾] ～全体概要・IABの動向ほか～」、「[第2弾] Hot RFC」に続いて、第3弾としてセキュリティエリアでの議論をご紹介します。今回のレポートは、仲野有登氏（KDDI総合研究所）にご執筆いただきました。

第115回IETF (IETF 115)における、セキュリティエリア関連報告として、CFRG、TLS、SAAGにおける議論を紹介します。

CFRG (Crypto Forum)

暗号関係を担当するグループで、4件の発表がありました。2件が共通鍵暗号に関するもの、2件が公開鍵暗号に関するものでした。

Encryption algorithm Rocca-S

筆者から、暗号方式Rocca-Sの提案を行いました。鍵回復攻撃・偽造攻撃に対して、256ビットセキュリティを実現した高速暗号であることを発表しました。状態更新をAESのラウンド関数とXORで構成することで高速な処理を実現しており、ソフトウェア実装においてAES-256-GCMの3倍以上高速であることをアピールし、今後の通信速度の向上にも対応可能な方式として普及をめざしていきます。

Classification of properties of AEAD modes

AEAD (Authenticated Encryption with Associated Data)の要件整理に関する発表で、CFRGでAEADをどのように扱っていくかについての議論が行われました。AEADは、メッセージの暗号化とメッセージ認証を同時に実現可能な暗号方式で、

• Nonce hiding
• Online
• Nonce misuse resistance
• Key commitment

など、さまざまな性質が検討されています。今後、それぞれに対して、定義、適用先、性質を満たすアルゴリズムを整理していく予定です。会場からは、非常に有益なドキュメントであり、利用したいとの意見が挙がっていました。チェアからも、Adoption callの提案がありました。

BBS Signatures

開示制御が可能で、ゼロ知識証明に対応したBBS署名についての発表でした。これまで実装があまり示されていなかったため、今回、実装を追加したことが発表されていました。hash-to-curveを利用することでメッセージ数に上限を設定する必要が生じており、2の48乗となる見込みであることが話されていました。また、課題として、Proofのテストベクトルが挙げられていました。これは、Proofに乱数要素を含むためテストベクトルの生成が難しいという問題で、解決策が募集されていました。

The use of NTRU

耐量子暗号として提案されている、NTRUの利用に関する発表でした。2022年7月に、米国国立標準技術研究所(NIST)が耐量子暗号の米国標準候補としてKyberを選定していますが、Kyberは特許技術であるため、自由に使えないという制限があります。NISTが権利保有者と交渉を進めていますが、いつ合意に至るかは現時点で不明です。そこで、Kyberと同程度の安全性を保つと考えられている、NTRUを利用することが提案されています。NTRUを選択した理由として、安全性に加えて、処理性能も十分であること、特許は有効期限を迎えており自由に使えるという点が挙げられていました。

TLS (Transport Layer Security)

TLSを担当するグループで、5件の発表がありました。そのうち、4件を紹介します。

8446bis

RFC 8446-bisの状況報告が行われ、多くの課題を解決したとの報告がありました。残っている課題として、Unsolicited Extensionsなど5件があります。

8447bis

RFC 8447がRFC 8447を廃止することになっており、混乱を招く可能性があるため、更新することが提案されました。この文書はIANA向けの文書なので、IANAにとって扱いやすいように対応するという結論になりました。もう一つの提案として、この文書中の表で、Recommended欄に新しく”D”を追加することが提案されました。DはSHOULD NOTあるいはMUST NOTを示すことになってい
ますが、どちらを指すかは文脈で判断することになっています。

Obsolete Key Exchange

TLSにおける鍵交換で、RSA方式の非推奨、安全でないFFDHEの制限、などを提案しています。この中で、FFDHEで利用している有限体が安全かどうかをクライアントで検証できないという課題があり、その解決策の議論で先に進めない状態に陥っています。そこで、すべてのFFDHEを非推奨にすること、もしくは有限体に関する要件を設定しないことが提案されています。すべてのFFDHEを非推奨とすることについて投票が実施され、賛成されました。

SSLKEYLOGFILE

SSLKEYLOGFILEは、TLSで利用される環境変数で、NSS (Network Security Services)で文書が公開されていますが、RFCとしてきちんと標準化することが提案されました。現時点の内容をRFCとし、IETFで変更を管理することが想定されています。TLS WGの項目として採用するかどうかについて投票が行われ、賛成多数となりました。この結果を受けて、Adoption callが出されています。

SAAG (Security Area Open Meeting)

SAAGは、セキュリティ・プライバシーに関する議論を担当するオープンフォーラムです。今回は4件の発表があり、そのうち3件を紹介します。

Implementation report from EDUROAM’s adoption of EAP/RADIUS

EDUROAMは、教育機関・研究機関向けに広く利用されているローミングサービスで、学生や研究者向けにインターネットサービスを提供しています。所属組織がIDプロバイダー、訪問先の組織がサービスプロバイダーに相当していて、訪問先の組織に接続しようとした場合に所属組織で認証が行われ、認証に成功すれば接続ができるようになっています。いくつかの課題が紹介されており、安全性に関するものとして、危殆化した技術を使っていることが紹介されていました。運用上の課題として、認証要求処理の効率化、有効期限切れのクレデンシャルを用いた接続要求の対処、などが紹介されていました。

Role of formal verification in the standards process

TLS1.3など、Formal verificationによって検証を実施しているが、今後も実施した方がいいのか、実施が必須なのか、などが議論されていました。

• 外部の専門家に依頼する必要があるため専門家との関係構築が重要である
• 攻撃者のモデルや検証の前提条件などがあり、証明が付いているからといってそれが完璧とは限らないことに注意が必要である
• プロトコルに証明を付けるのが必須になるのであれば、プロトコル設計の時からそれを意識して設計する必要がありそう

などの意見が挙がっていました。

HTTP message signatures

HTTP WGで検討されている課題についての、共有が行われました。HTTPメッセージの順序が入れ替わった場合でも正しく署名が検証できるよう、署名したデータの順番を平文で検証者に送信し、検証者で元の順番に並び替えを行ってから署名検証を実施することが提案されていました。中間者が署名を追加する場合にも、対応できるように検討されています。これによってサーバ<-> クライアントでメッセージの真正性を確保できるようになっています。セキュリティの専門家に対して、安全性評価と実装の依頼がされていました。

おわりに

今回もハイブリッド開催となり、多くの参加者が現地から参加し、活発な議論が行われていました。IETF 116もハイブリッド開催となることが発表されており、ますます活発に議論が行われ、セキュリティ関連分野が盛り上がることを期待しています。