★☆★JNSAメールマガジン 第37号 2014.6.13.☆★☆

こんにちは
JNSAメールマガジン 第37号 をお届けします。

今日の東京では久しぶりに晴れ間がのぞきましたが、ところにより雷雨の地域もあったようです。まだまだ梅雨のまっただ中、傘を持たないで外出するわけにはいかないですね。

さて、今回は暗号技術をテーマとした連載リレーコラムの2回目となります。
「信頼のおける暗号技術」というテーマで、株式会社インターネットイニシアティブの須賀祐治様に寄稿いただきました。


【連載リレーコラム(2):テーマ「暗号技術」】
「信頼のおける暗号技術」
(株式会社インターネットイニシアティブ 須賀 祐治)

先週木曜夜にOpenSSLにおける新しい脆弱性の情報が飛び込んできました*1。今頃 Heartbleed Bug の報道が新しく取り上げられているのかと勘違いした人も居たほど「またかぁ(ハァ)」というのが正直な現場の声ではないでしょうか。4月に発覚したHeartbleedの件では、実際に国内でも被害が報告されたこともあり、かなり大々的に報道されました。一方で先週発覚した脆弱性は、サーバ・クライアントともにOpenSSLのライブラリを利用していること、攻撃が成功するためにMITMの状況にいる必要があるなどの制約条件が多いものでした。しかし影響範囲は限定的であったにも関わらず、当初温度感の高い報道がなされているように感じました。「10年以上も放置」という事実もそれに拍車をかけていたと考えられます。

今回の問題は、ハンドシェイクメッセージの送受信において状態遷移のチェックさえ行っていれば、プロトコル上あり得ない箇所でインジェクションされたChangeCipherSpecメッセージをはじくことが出来ました。このチェックは特別なものではなく非常に簡易なものあってもこの攻撃は起こり得ません。HeartbleedBugのエンバグと同じタイミングである1.0.1系にて、新しい機能が追加される際に呼び覚ましてしまったバグであると認識されています。

OpenSSLは広く利用されている暗号ライブラリのひとつであり多くの目に触れられてきたものです。それにも関わらず今回の問題がこれまで発覚しなかったのは、オープンソースの潜在的な問題に依るものであることを再認識させられた方も多いと思います。また、利用者自身がよく理解していない新機能(例:Heartbeatプロトコル)をパッケージのデフォルトのまま利用してしまった側にも問題があるとも言えます。今後、OpenSSLに対する関心の高まりをうまく利用することで問題解決の方向に向けていくのか、しっかりとしたサポートの得られる商用製品に移行するのかについては考えが分かれるところですが、いずれにせよ見直しをするきっかけを与えてくれたと言えます。前者の一例として、OpenSSLを枯れた安全な技術として利用したいというニーズに対しては、絶妙なコンパイルフラグの調整を皆が協力して精査することで可能になるかもしれないことを挙げておきます。

■対策するのか?しないのか?

先日、前述した2つの脆弱性をよく知る関係者からの指摘を受けて驚いたことがあります。Heartbleed BugのCVSS Base pointがかなり低いものであったということです。CVSS *2 は脆弱性評価指標の一方式で、当該脆弱性の「ヤバさ」を数値化することで、対策が必要かどうかを判断する一つの指標となっています。毎日公表される膨大な脆弱性情報から本当に対策が必要なものがどれであるかを、ある程度の精度でフィルタすることには役立つかもしれません。しかし直感的にも実際にも影響が大きいと認識されていたHeartbleed Bugは先週報告されたCCS Injectio攻撃よりもCVSS Base Scoreとしては低く評価されています。

ある脆弱性情報を受けて実際に対策が必要かどうかを判定する際にはCVSSなどの数値だけに頼らず、より詳細にその脆弱性を読み解く必要が出てきます。ソースコードの精査も含む実証実験だけでなく、場合によってはアカデミアから出てくる研究論文までさかのぼり、実際に起こりうる問題と影響範囲、その確度などを確定していく必要が出てきます。そのあとでこの脆弱性に対する対策方針とスケジュールを立案していきます。

これはかなり極端な事例と思われる方もいらっしゃるかもしれません。しかし「パッチがすでに公開されていてそれをあてるだけ」のマネージメント手法では、オープンソースの問題で指摘したように問題の中身・本質を十分理解しないままであることを認識しなければなりません。もちろん、報道の「アツさ」だけを判断材料にすることも問題です。特に暗号技術に起因または関連する脆弱性の場合には、この傾向が大きいように思います。アカデミアからの論文はチンプンカンプンだからと言って逃げることなく、正しく判断していく必要があります。そのための技術者連携方法として主要カンファレンスの読破会や暗号プロトコル評価技術コンソーシアム *3 という組織も立ち上がっていますので、ご興味のある方はコンタクトしてみて下さい。

■最近のトレンド(私見)

次に最近よく目にする暗号技術に関連する脆弱性の傾向に触れておきます。具体的には以下の2つのカテゴリです。
(1)擬似乱数生成器の問題
(2)X.509証明書の検証時の不備

(1)は暗号技術で用いられるランダムデータに関する件です。擬似乱数生成モジュールは生成される値に偏りがないこと、予測できないという性質が必要です。もしそれが満たされていない場合には、公開鍵ペア生成時に秘密鍵が予測される*4、セッション鍵が予測される、署名生成時に秘密鍵が暴露してしまう *5 等の問題が生じてしまいます。これらの問題は例えば昨年11月に開催された ACMCCS2013 *6 で randomness セッションが組まれるなどアカデミアでも流行りの研究だということが分かります。

(2)はSSL/TLSなどで利用されている公開鍵証明書に関する件です。先月開催されたIEEE S&P2014 *7ではSSL/TLSセッションが組まれており、やはり同じように盛んに研究が進められている分野であると言えます。S&P2014 では併設ワークショップも含めSSL/TLSに関連する5件の発表が行われており、不正な証明書やSSL/TLSサーバの設定不備に関する調査報告3件、2009年に発覚した Renegotiation 機能の問題と同類のプロトコル脆弱性の報告1件、そして(2)に挙げたようにX.509証明書の検証時の不備に関する報告1件がありました。最後の1件は昨年に引き続き同じチームがBest Practical PaperAwardを受賞しているなど非常に現実的な問題を取り扱っています。フランケン証明書*8はその名の通り、流通している様々な証明書のパーツを組み合わせて出来上がる証明書のことで、これを大量に作成し検証モジュールに対してFuzzingすることでモジュールの問題点を洗い出しており、いくつかの商用製品において脆弱性が発見されています。

(1)(2)ともに今後も同様の問題が露呈することが予想されます。特にOpenSSL以外のマイナーなモジュールへの展開が見込まれており、どのような組み合わせでシステム・サービスを構築しても、潜在的には同じようなバグが埋め込まれている可能性があることを知った上で利用しないといけません。さらに暗号アルゴリズムそのものも経年劣化だけでなく、突発的な攻撃手法の公開により急に安全でなくなるかもしれないことを理解した上で暗号技術を利用していく必要があります。

最後に、暗号技術に関連する脆弱性の整理方法として、暗号危殆化・設計・実装・運用の問題という4つのカテゴリに分類する方法(2012年12月までの事例も併記)も紹介しておきます*9。また、暗号研究者と暗号利用者のギャップを埋めていくWorkshop on Real-World Cryptography などの試みも見受けられるようになりました。JNSAや他の組織からも日本発で同じようなアクティビティが出来ればと常に考えています。ご興味のある方はお気軽にお声がけ頂ければと思います。

*1 CVE-2014-0224 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0224
*2 Common Vulnerability Scoring System
*3 https://www.cellos-consortium.org/jp/
*4 PKI Day 2012, 公開鍵使い回し問題 https://www.jnsa.org/seminar/pki-day/2012/data/PM02_suga.pdf
*5 例えばBitcoinのアプリケーション時の擬似乱数生成モジュールの不備問題 bitcoin.org, "Android Security Vulnerability"
http://bitcoin.org/en/alert/2013-08-11-android
*6 http://www.sigsac.org/ccs/CCS2013/program/agenda/index.html
*7 http://www.ieee-security.org/TC/SP2014/program.html
*8 Frankencert - Adversarial Testing of Certificate Validation in SSL/TLS Implementations
https://github.com/sumanj/frankencert
*9 IIJ, IIR vol.18 1.4.3 暗号技術を用いたプロトコル・実装に多発している問題の整理とあるべき姿
http://www.iij.ad.jp/company/development/report/iir/pdf/iir_vol18_infra.pdf



#連載リレーコラム、ここまで
<お断り>本稿の内容は著者の個人的見解であり、所属企業及びその業務と関係するものではありません。



【部会・WG便り】
★「2013年度 情報セキュリティ市場調査報告書」を公開しました。
 https://www.jnsa.org/result/2014/surv_mrk/index.html
★「2013年度 情報セキュリティ対策マップ検討WG活動報告書」を公開しました。
 https://www.jnsa.org/result/2014/std_map/index.html
★シンギュラリティ調査WGでは、6/23(月)に勉強会を開催します。
 ※会場が変更になりました。すでにお申込みいただいている方はご注意ください。
「トランセンデンス」の予備知識〜人類の未来を左右するシンギュラリティとは〜
 日 時: 2014年6月23日(月)19:00〜21:00
 会 場: TKP虎ノ門会議室 カンファレンスルーム3B
      http://tkptora.net/access.shtml
 主 催: 日本ネットワークセキュリティ協会
 共 催: 科学技術特異点協会
 参加費: 無料
 お申込みはJNSA事務局jnsa-mailまでお願いします。
★以下のワーキンググループでは新メンバーを募集中です。
 参加希望の方は事務局までご連絡ください。
  <アイデンティティ管理WG>
  <スマートフォン活用セキュリティポリシーガイドライン策定WG>
★6月10日に開催しました「JNSA2013年度活動報告会」は盛況のうちに終了
 いたしました。多数のご来場ありがとうございました。
 発表資料をウェブサイトに公開中です。
 https://www.jnsa.org/seminar/2014/0610/

【事務局からの連絡、お知らせ】
★今年度もセキュリティコンテスト「SECCON」を開催します。
 https://www.jnsa.org/seccon/
 ・6/28(土)開催 入門者限定CTFワークショップ「CTF for Beginners」申込受付中 
  http://2014.seccon.jp/2014_06_CTF_for_Beginners.html
 ・6/29(日)開催 女性限定CTFイベント「CTF for GIRLS」申込受付中 
  http://2014.seccon.jp/2014_06_CTF_for_GIRLS.html 

 協賛企業も同時募集中です。スポンサーメニューをご用意していますのでJNSA事務局までお問合せください。

★登録情報にご変更がある方がいらっしゃいましたら、事務局までご一報をお願いいたします。

☆コラムに関するご意見、お問い合わせ等はJNSA事務局までお願いします。
jnsa-mail

*************************************
JNSAメールマガジン 第37号 
発信日:2014年6月13日
発行: JNSA事務局 jnsa-mail
*************************************
Copyright (C)  Japan Network Security Association. All rights reserved.