ニュースレターNo.58/2014年11月発行

第90回IETF報告　暗号技術に関する動向

新しい楕円曲線の選定

第88回IETFのプレナリーでPervasive Surveillanceが取り上げられて以降、IETFでは、インターネットで標準的に使われる暗号をどう決めていくべきか、具体的には多くの候補の中からどういうプロセスを踏んで選んでいくべきなのかが、重要な論点になってきています。プロセスが不透明であると、国家によって盗聴可能な暗号がインターネットの標準の中に入れ込まれるのではないか、といった懸念も挙げられています。

Webブラウザなどで利用されている鍵交換アルゴリズムである、ECDH(Elliptic Curve Diffie-Hellman key exchange)などで利用されている楕円曲線として、米国国立標準技術研究所(National Institute of Standards and Technology; NIST)が規定している楕円曲線(以降、NIST曲線とする)が有名です。しかし、楕円曲線のパラメータを決定するプロセスが不透明などの理由で、NIST曲線への懸念を持っている人たちを中心に、NIST曲線以外をIETFとして選択しようという動きを受けて、2013年後半から徐々に議論が継続して行われています。

今回のIETFで行われた議論の中から、次に示す二つの項目について、情報を共有します。

1. 新しい楕円曲線を選定する上での要件

TLS(Transport Layer Security) WGは、Webなどで使われているSSL/TLSの標準化を行っているWGです。SSL/TLSで使われる暗号もTLS WGで決定されます。インターネットに関連する技術やプロトコルを中長期的な観点で研究を推進している、IRTF(Internet Research Task Force)にある暗号のグループであるCFRG(Crypto Forum Research Group)では、新しい楕円曲線を選定する際の要件を検討してほしいというTLS WGからの要請を受けて、

• NUMS Curves(Nothing Up My Sleeve Curves - バックドアのない楕円曲線)
• 高速化が期待できるCurve25519、Curve41417、E-512といった楕円曲線に関する提案
• 楕円曲線の基本的な安全性に関する考え方

に関する発表がありました。

これらの議論を受けて、TLS WGへの回答としてCFRG co-chairから、安全な楕円曲線が満たすべき要件が示されました。その要件は以下の通りです。

• 暗号装置の動作状況をさまざまな物理的手段で観察することにより、装置内部のセンシティブな情報を取得しようとする攻撃である、サイドチャネル攻撃に対する耐性があること
• 必須ではないが、Twist securityを有することが望ましい
• ECDHE、ECDSA(Elliptic Curve Digital Signature Algorithm)などの、楕円曲線暗号である既存のアルゴリズムをサポートできること
• 信頼できる曲線の決定プロセスに基づいて選択された楕円曲線であること
• 楕円曲線の形式について、Weierstrassのみの形式ではなく、その他の形式(Montgomery/Edwards/twisted Edwards)へ切り替え可能なこと

2. TLSプロトコルにおける楕円曲線の取り扱い

現在、TLSプロトコルで楕円曲線暗号の利用を規定している、RFC4492^※2があります。このRFCのステータスがInformationalではあるものの、現状の利用状況を踏まえてStandards TrackでのRFCを発行し、今後利用するTLSプロトコルでの、実装が必須であることを意味するMandatory To Implement(MTI)としてのCiphersuite^※3の中に、楕円曲線暗号を加えることについてコンセンサスが取られました。

新しい共通鍵暗号アルゴリズムの検討

現在のIETFでは、ChaCha20というストリーム暗号アルゴリズムと、使い捨て認証符号(One-time Message Authentication Code)であるPoly1305を組み合わせて、AEAD(Authenticated Encryption with Associated Data)を構成する暗号技術が提案されています。今回のIETFでは、CFRG、TLS WG、UTA(Using TLS in Applications) WGで、ChaCha20+Poly1305に関して提案されており、CFRGやTLS WGにおいて提案者から、ChaCha20+Poly1305は、以下のような利点があるとアピールされていました。

• OMAP 4460やSnapDragon S4 Proといった、タブレットやスマートフォンに搭載されているモバイル向けCPUにおいて、AES-GCMと比較してパフォーマンスが3倍程度優れている
• サイドチャネル攻撃の一種である、タイミング攻撃に対する対策が容易である

上記に示した利点や、Google ChromeおよびGoogle社の運用するサーバにおいて実装され、稼働していることがアピールされており、TLSプロトコルやIPsecプロトコルで、ChaCha20+Poly1305を利用するための標準化活動が精力的に行われているので、今後の動向に注目が必要だと思います。

□ TLS WGにおけるChaCha20+Poly1305の発表資料
http://www.ietf.org/proceedings/90/slides/slides-90-tls-2.pdf

□ CFRGにおけるChaCha20+Poly1305の発表資料
http://www.ietf.org/proceedings/90/slides/slides-90-cfrg-0.pdf

Pervasive Surveillance(大規模な盗聴行為)への技術的なアプローチ

大規模な盗聴行為への対策技術として、TLSプロトコルなどを用いたエンドツーエンドの暗号化や、「(Perfect) Forward Secrecy」といった、秘密鍵の情報が漏えいしたとしても、影響範囲をその鍵が利用されたセッションだけに限定する技術が検討されています。大規模な盗聴行為が行われると、暗号化された通信データを逐次解読することはできなくても、蓄積された通信データを解析することで、将来解読されてしまうリスクがあると言われているためです。

今回のIETFから、新たにTCPINC(TCP Increased Security) WGという、TCP通信のデータ暗号化や完全性を提供するための、TCP拡張を検討する会合が開催されました。このWGは、多くのTCP通信が暗号化されていないため大規模な盗聴行為に対して対策されていないところに注目し、TCP通信の暗号化をするということが検討されました。実現されると、今後の大規模な盗聴行為に対して、大きな効果を持つ技術になることが予想されます。以下に、tcpcryptの目的などを含めた発表資料のリンクを示しますので、参照いただけたらと思います。

□ tcpcryptの発表資料
http://www.ietf.org/proceedings/90/slides/slides-90-tcpinc-2.pdf

---

最後になりますが、今後のIETFにおいて、暗号技術を用いたプロトコルが多く検討され、重要性が今以上に増加することが予想されます。このような状況において、プロトコル自体の仕様を策定する段階で脆弱性を排除する手法などを検討する必要が、今後は出てくることが予想されます。最近の事例を挙げれば、暗号プロトコルとして広く利用されているSSL/TLSにおいて、仕様に起因する脆弱性が発見されて、実社会に与える影響が大きかったことからも、RFCの発行前に暗号プロトコルの安全性を評価する取り組みは、必要だと感じています。

(NTTソフトウェア株式会社 菅野哲)

---

※1 JPNIC News & Views vol.1152「第88回IETF報告 [第1弾] 全体会議報告」

https://www.nic.ad.jp/ja/mailmagazine/backnumber/2013/vol1152.html

※2 RFC4492“Elliptic Curve Cryptography(ECC) Cipher Suites for Transport Layer Security(TLS)”

http://www.ietf.org/rfc/rfc4492.txt

※3 Ciphersuite

SSL/TLSプロトコルで使用される、鍵交換、暗号化、メッセージ認証符号のそれぞれのアルゴリズムの組み合わせ