CRYPTREC Report 2013

no extension

8月に CRYPTREC Report 2013 が出てたのに気付かず。

あと CRYPTREC Report じゃないけど,昨年大騒ぎになった

も併せてどうぞ。

セキュリティ管理に関わっている人は最低でも「暗号技術評価委員会報告書」は読んでおくとよい。 ちなみに SSL/TLS と SHA-1 の暗号技術ガイドラインは「暗号技術評価委員会報告書」にも含まれている。

ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。

  1. 公開鍵暗号に関する安全性評価
  2. ハッシュ関数について
  3. FIPS PUB 186-4
  4. SP800-52 revision 1 と TLS 1.2
  5. perfect forward secrecy と forward secrecy
  6. SSL/TLS における DHE, DH, RSA の安全性評価
  7. 擬似乱数生成アルゴリズム Dual_EC_DRBG
  8. 軽量暗号

公開鍵暗号に関する安全性評価

昨年の Crypto 2012 で A.K. Lenstra らは、実社会に公開されている RSA 公開鍵証明書(X.509)に、異なる署名に同じ modulus が使われていたり、modulus が素因数分解できたりといった問題を指摘した。これに続き、 Asiacrypt 2013 において N. Heninger らは、台湾市民向けのスマートカードで利用される公開鍵証明書約300万件について、同じ問題点があることと、Coppersmith 攻撃によって新たな素因数分解が可能となったことを示した。
楕円曲線暗号に関しては、Asiacrypt 013 のランプセッションにおいて J.W. Bos らが、実際に暗号通信(TLS/SSH)で利用されている証明書を調べ、TLS 公開鍵の 4%(20 万個)、SSH公開鍵の 30%(40 万個)に同じものが使用されている問題点を確認した。また、Bitcoin において、同じ nonce の存在が利用されており、59 BTC が盗難されたとしている。
CRYPTREC Report 2013 暗号技術評価委員会報告書より

ということで,実装上の脆弱性が浮き彫りになった。 スマートカードのようにハードウェアに組み込むタイプのものは,いったん脆弱性や危殆化が発覚すると対処が難しい。 なので,やはり「事後」の対処がとても重要になってくる。(下手に隠蔽したり判断をミスったりすれば被害を拡大させてしまう)

ちなみに59BTCは290万円くらいらしい。

ハッシュ関数について

以前も述べたが FIPS PUB 202 (SHA-3 Standard) のドラフトが登場している(パブリックコメントは既に終了している)。

正式リリースは来年以降かな?

FIPS PUB 186-4

FIPS PUB 186-4 が登場している。

補助関数(ハッシュ関数、KDF、及び、擬似乱数生先の変更を認 成系、素数生成や楕円曲線生成等の基本的なアルゴリズム)を除いた、当該アルゴリズムを実装するための必要最小限の範囲において、パラメータ修正等の簡易な修正である。
CRYPTREC Report 2013 暗号技術評価委員会報告書より

とのこと。

SP800-52 revision 1 と TLS 1.2

近年の SSL/TLS への攻撃(BEAST, CRIME, TIME. BREACH, Lucky Thirteen, Renegotiation)や RC4 の危殆化を鑑み, TLS 1.2 へのアップデートが推奨されている。

推奨される設定として、TLS 1.0 より古いバージョンについては、新しいバージョンへアップデートすることが推奨される。TLS 1.0 については、CBC モードを用いた場合の脆弱性に対してパッチが提供されているため、Java 等のソフトウェアを最新版に更新した上で、CBC モードを選択することが推奨される。TLS 1.1 については、CBC モードを用いた場合の脆弱性が解消されていることから、CBC モードを選択することが推奨される。 TLS1.2 については、CBC モード、CCM モード、GCM モードが選択できるため、それらを使うことが推奨される。
CRYPTREC Report 2013 暗号技術評価委員会報告書より

NIST では SP800-52 revision 1 を発行し TLS 1.2 への対応を行うことを進めている。

“Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2,” the document says. “These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0.”
via NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015

ところでクライアント側はどうなっているだろう

主要ブラウザは TLS 1.2 のサポートを完了しているようだ。

  • Google Chrome は 30 から全プラットフォームで正式対応
  • Mozilla Firefox は 27 から全プラットフォームで正式対応
  • Internet Explorer は 11 から既定で有効になっている(Windows Vista および 2008(無印)は非対応)
  • Safari は 7 以降は全プラットフォームで対応
  • その他

いやぁ, WinXP(および IE6)がなくなってホンマによかったよ。 (でもうちのサイトに来るブラウザの UA 見てると IE6 っぽいのがいまだにワンサカ来るんだけど。 IE6 & WinXP ってどのくらい残ってるのかねぇ。ちなみにうちのサイトはもう IE8 以前は見捨ててますので。 IE9 もダメかな,多分。 Safari は確認する手段を持ってないので知らない振りをする

ちなみに Firefox で Google のサイトを見ると

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

と表示される。 つまり TLS 1.2 下で Perfect Forward Secrecy を満たす ECDHE 鍵交換方式を使い AES 128bit アルゴリズムで GCM モードにより暗号化している(HMAC には SHA256 を使用),ということになる。

あとは古い AOSP(Android Open Source Project)版ブラウザだよね。 AOSP 版ブラウザはもともと WebKit から fork したものだが, Google 自身は2012年以降サポートを打ち切っている(Chromium があるからね)。 ユーザ側としては Chrome 等を導入して AOSP 版ブラウザを使わないようにするしかない。 他にも AOSP 版ブラウザには「同一生成元ポリシー回避の脆弱性」が指摘されている。

perfect forward secrecy と forward secrecy

どうもドキュメントによって表記に揺れがあるらしい。

SP800-52 revision 1 では

Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the second mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. While support of these cipher suites is not required by these guidelines, it is strongly recommended.
via Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

とあり, perfect forward secrecy の表記になっている。 一方 RFC3268 では

At the same time the DHE ciphersuites are the only ones to offer forward secrecy.
via RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

とあり,こちらは forward secrecy の表記になっている。

さらに RFC4949 では

Ordinary forward secrecy vs. "perfect" forward secret: Experts disagree about the difference between these two. Some say there is no difference, and some say that the initial naming was unfortunate and suggest dropping the word "perfect". Some suggest using "forward secrecy" for the case where one long-term private key is compromised, and adding "perfect" for when both private keys (or, when the protocol is multi-party, all private keys) are compromised.
via RFC4949: Internet Security Glossary, Version 2

と書かれていて,両者の違いに一致した見解はないそうだ。 ちなみに SP800-52 revision 1 では perfect forward secrecy について

Perfect forward secrecy is the condition in which the compromise of a long-term private key used in deriving a session key subsequent to the derivation does not cause the compromise of the session key.
via Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

と定義している。 大雑把に言えば「長期的に使われる秘密鍵が漏洩しても、漏洩前のセッションで交換された鍵の秘密が漏れない」という解釈でいいようだ。

SSL/TLS における DHE, DH, RSA の安全性評価

TLS で使われる鍵交換方式である DH(Diffie-Hellman), DHE(ephemeral DH), RSA(RSAES-PKCS1-v1_5)を比較すると

DHE > DH > RSA

となるらしい。 これは

  • DHE: 安全な認証機能付き鍵交換であり,かつ Perfect Forward Secrecy を満たす
  • DH: 安全な認証機能付き鍵交換である
  • RSA: 安全な認証機能付き鍵交換ではない(ただし RSA-OAEP を使う場合は安全な認証機能付き鍵交換である)

ということらしい。 ちなみに CRYPTREC では RSAES-PKCS1-v1_5 は「運用監視暗号」としてリストされ,「利用実績があることから当面の利用を認める」という条件で利用可能である。

参考:

(CRYPTREC の「電子政府推奨暗号リスト」では,「鍵共有」用途としては DH および ECDH(Elliptic Curve Diffie–Hellman)しかリストアップされていない(推奨候補にも挙がってない)。 CRYPTREC において DHE や ECDHE(ephemeral ECDH)がどのような位置づけになるか,今後の動向が注目される)

擬似乱数生成アルゴリズム Dual_EC_DRBG

Dual_EC_DRBG については擬似乱数生成アルゴリズム Dual_EC_DRBG についてを参照していただきたいが,最新動向として SP800-90 A Rev. 1 (2nd Draft) が登場している。

このドラフトのパブリックコメントは2014年5月に締め切られている。

もともとこの脆弱性は2013年に Dual_EC_DRBG に NSA によるバックドアが仕込まれているという指摘からはじまったものだ。 NIST はこの脆弱性の修正に懸命になっているが,あまり芳しくないようである。

軽量暗号

軽量暗号についてはまだまだこれからのようだが,いわゆる IoT(Internet of Things)を考える際には外せない要素技術であるといえる。

軽量暗号の特徴は以下のとおり。

  • ハードウェア規模が小さい,低消費電力で動作,消費電力が少ない,低コスト
  • コードサイズが小さい,RAM が少ない
  • 低レイテンシ性,リアルタイム性

そして「軽量暗号の活用が期待されるアプリケーション」としては

  • RFID タグ,センサー,ワイヤレスセンサー
  • IC カード
  • 医療機器(体内埋め込みや携帯型など),ヘルスケア製品
  • スマートメータ
  • モバイル製品
  • バッテリ
  • 車, ITS システム

が挙がっている。 バッテリーかぁ。

車への応用は急務だろうね。 いまどきの車は ECU だらけだけどセキュリティに関してはこれからって感じだもんなぁ。

参考図書

photo
新版暗号技術入門 秘密の国のアリス
結城 浩
SBクリエイティブ株式会社 2013-12-04
評価

プログラマの数学 数学ガールの秘密ノート/整数で遊ぼう インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 数学ガールの秘密ノート/式とグラフ 数学ガール/ガロア理論

まさに入門書。暗号がどのような要素技術で成り立っているのか体系的に理解できる良書。

reviewed by Spiegel on 2014/09/18 (powered by G-Tools)