CRYPTREC Report 2013
8月に CRYPTREC Report 2013 が出てたのに気付かず。
あと CRYPTREC Report じゃないけど,昨年大騒ぎになった
も併せてどうぞ。
セキュリティ管理に関わっている人は最低でも「暗号技術評価委員会報告書」は読んでおくとよい。 ちなみに SSL/TLS と SHA-1 の暗号技術ガイドラインは「暗号技術評価委員会報告書」にも含まれている。
ここでは「暗号技術評価委員会報告書」で挙がっている主なトピックを紹介する。
- 公開鍵暗号に関する安全性評価
- ハッシュ関数について
- FIPS PUB 186-4
- SP800-52 revision 1 と TLS 1.2
- perfect forward secrecy と forward secrecy
- SSL/TLS における DHE, DH, RSA の安全性評価
- 擬似乱数生成アルゴリズム Dual_EC_DRBG
- 軽量暗号
公開鍵暗号に関する安全性評価
ということで,実装上の脆弱性が浮き彫りになった。 スマートカードのようにハードウェアに組み込むタイプのものは,いったん脆弱性や危殆化が発覚すると対処が難しい。 なので,やはり「事後」の対処がとても重要になってくる。(下手に隠蔽したり判断をミスったりすれば被害を拡大させてしまう)
ちなみに59BTCは290万円くらいらしい。
ハッシュ関数について
以前も述べたが FIPS PUB 202 (SHA-3 Standard) のドラフトが登場している(パブリックコメントは既に終了している)。
正式リリースは来年以降かな?
FIPS PUB 186-4
FIPS PUB 186-4 が登場している。
とのこと。
SP800-52 revision 1 と TLS 1.2
近年の SSL/TLS への攻撃(BEAST, CRIME, TIME. BREACH, Lucky Thirteen, Renegotiation)や RC4 の危殆化を鑑み, TLS 1.2 へのアップデートが推奨されている。
NIST では SP800-52 revision 1 を発行し TLS 1.2 への対応を行うことを進めている。
- NIST Revises Guide to Use of Transport Layer Security (TLS) in Networks
- Publication Citation: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations
- NIST SP 800-52 Revision 1 Recommends TLS 1.2 by Jan. 1, 2015 | Threatpost | The first stop for security news
ところでクライアント側はどうなっているだろう
主要ブラウザは 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
どうもドキュメントによって表記に揺れがあるらしい。
とあり, perfect forward secrecy
の表記になっている。
一方 RFC3268 では
とあり,こちらは forward secrecy
の表記になっている。
さらに RFC4949 では
と書かれていて,両者の違いに一致した見解はないそうだ。
ちなみに SP800-52 revision 1 では perfect forward secrecy
について
と定義している。 大雑把に言えば「長期的に使われる秘密鍵が漏洩しても、漏洩前のセッションで交換された鍵の秘密が漏れない」という解釈でいいようだ。
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 だらけだけどセキュリティに関してはこれからって感じだもんなぁ。