JNSA「セキュリティしんだん」

（13）SSL再考（2014年12月19日）

セコム株式会社　IS研究所
コミュニケーションプラットフォームディビジョン
暗号・認証基盤グループ
主任研究員　島岡政基

1.暗号技術に対する攻撃の本格化

2009年のTLS再ネゴシエーション問題[renego2009]をはじめ近年SSL/TLSの脆弱性が話題となることが増えてきた。中でも2011年のBEAST[beast2011]、CRIME[crime2012]にはじまり、2013年の Lucky13[lucky2013]やRC4マルチセッション攻撃[rc4 2013]、今年に入ってからのPOODLE[poodle2014]などは、いずれもサイドチャネル攻撃や選択平文攻撃など暗号技術に特有の攻撃手法が応用された本格的な事例である。従来のバッファオーバーフローやコードインジェクションなどのような実行コードに対する攻撃だけでなく、暗号技術に対してもより本格的な攻撃が行われるようになった象徴的な事例と言ってよいだろう。

こうした攻撃手法の変化は、サーバ管理者にも様々な混乱をもたらした。今回の一連の攻撃は、実装依存ではなく、通信プロトコルや暗号アルゴリズムに対する攻撃であるため、その影響範囲は広範となり、実質的にSSL/TLSを利用するシステムのほとんどが対象となったと考えられる。

本稿では、これらの脆弱性報告・攻撃が盛んになってきた背景について分析するとともに、これらから浮き彫りとなった課題を整理し、今後の備えについて考える。

2.SSL/TLSへの攻撃が本格化してきた背景

こうした脆弱性報告・攻撃が盛んになってきた背景はいくつか考えられるが、SSL/TLSに対する攻撃利得の増大と攻撃コストの低下によってセキュリティバランスが大きく崩れてきた点は無視できないだろう。本節ではこれら2点に着目して分析する。

2-1. 攻撃成功時の利得増大

SSL/TLSのコモディティ化が進んだことで、より機微な情報がより多くのノード間で交換されるようになり、攻撃成功時の利得は以前よりも遥かに大きくなってきた。また、各システムのSSL/TLSへの依存度が高まることで、SSL/TLSへのパッチ適用や仕様変更に対して機敏な対応が難しくなってきたなどの課題も挙げられる。特にSSL/TLSは通信プロトコルなので、例えばサーバ側でパッチ適用や仕様変更した結果、クライアントとの通信に支障をきたす可能性もある。SSL/TLSへの依存度が強い、即ちSSL/TLS通信ができなくなると致命的なサービスにおいては、こうしたパッチ適用や仕様変更を回避する傾向が強まることになる。これは攻撃機会の長期化を意味し、間接的に攻撃利得の増大に拍車をかける要素と言えるだろう。

2-2. 攻撃障壁の低下

攻撃障壁の中でも典型的な攻撃コストの低下については、計算機性能や通信技術の進化が寄与しているが、基本的な計算機性能の向上はいわゆるムーアの法則に示されるようにほぼ予測可能であり、これは暗号技術の耐用年数を評価する際にも織り込み済みである。これまでとの大きな違いは、クラウドコンピューティングによってスパコン並みの計算環境が容易に利用可能になった点にある。

もともと暗号技術の耐用年数を評価するにあたっては、計算機性能の向上に関する予測を踏まえた上で、十数年から数十年後における世界トップレベルのスパコンをフル稼働させて数年程度の計算量が必要となるように評価されている。そして、従来であればこうしたスパコンはそもそも利用者が限られており、攻撃者が同程度の計算環境を確保できるようになるにはそれからさらに一定の歳月が必要になるだろうという暗黙の前提があった。しかしながら、最近のクラウドコンピューティングを支える分散計算技術の急激な発展によって、資金さえあればすぐに誰でもスパコン並みの計算環境を入手できるようになり、時間の問題を金銭で解決出来るようになった。

さらに、大量の通信が日常的となったことにより、暗号技術に対する攻撃が容易になった、ということも無視できない。暗号解読とは、図 1のように暗号鍵を与えられないまま何らかの方法で平文や暗号鍵（の一部）を復元する攻撃であり、一般的には大量の暗号文などを収集解析することで平文や暗号鍵を求める。ここで大量の暗号文など解析対象を如何に効率よく収集できるかが攻撃のポイントとなる。前述の一連の攻撃ではいずれも大量のHTTPS通信を収集し、得られた暗号文などから従来よりも効率的に解読を行うといった攻撃を実現するものである。もちろん前述の通りこの攻撃を実現するには一定の計算量が必要となるよう、いずれの暗号技術も設計されているわけだが、図2のようにシチュエーションを限定することでより少ない計算量での解読が可能となる。

従来の暗号技術に対する攻撃では、このシチュエーションがおよそ現実的ではないことが多く、従って実質的な脅威になり得なかったが、今回の一連の攻撃ではこれら既知の攻撃手法におけるシチュエーションを図3（※）のようにより現実的なシナリオにした、という点で共通している。現実的な攻撃シチュエーションを考案するには、 SSL/TLSプロトコルの具体的な利用シーンと暗号技術の両者について高度な知識が必要とされるため、これまでなかなか攻撃手法の改良は進まなかったが、前述のような攻撃障壁の低下が、こうした攻撃手法の改良を加速される大きな動機付けになったのではないかと考えられる。
※解説のために単純化した例であり，BEASTやPOODLEなど特定の攻撃の説明ではない


図1 オーソドックスな攻撃	図2 典型的な差分攻撃	図3 TLSへの差分攻撃の応用（イメージ）
【図を拡大する】

このように、SSL/TLSのコモディティ化による攻撃利得の拡大と、計算機性能や通信技術の進化による攻撃障壁の低下によってSSL/TLSのセキュリティバランスは大きく崩れ、これが近年のSSL/TLSに対する高度な攻撃の動機付けになっていると言えるだろう。

3.浮き彫りとなった課題

こうした一連の攻撃から浮き彫りとなった課題がいくつかある。

3-1. 暗号技術の設定の複雑さ（とベストプラクティス不在）による混乱

SSL/TLSで暗号化通信を実現するには、公開鍵証明書による認証に加えて、
　1）通信に利用するプロトコルの種類とバージョン（SSL v3.0やTLS v1.0など）
　2）暗号化通信を行うために共通鍵を交換するための鍵交換アルゴリズム（DHやRSAなど）、
　3）通信データの暗号化に用いる共通鍵暗号アルゴリズム（および鍵長）（DESやRC4、 AESなど）、
　4）共通鍵暗号による暗号化手順とも言える利用モード（CBCやGCMなど）、
　5）通信データの認証に用いるハッシュ関数（MD5やSHA-1、 SHA-256など）
をそれぞれ決める必要がある。このうちプロトコルバージョンを除く2）～5）はまとめて暗号スィートと呼ばれる。暗号スィートの実装はサーバとクライアントでそれぞれ異なる場合があるため、通信開始時のハンドシェイクにおいてサーバ・クライアント間で、それぞれが利用可能な暗号スィートのリストを交換することによって、通信中に利用する暗号スィートを決定する。サーバ管理者はアクセスするクライアントの種類や要求されるセキュリティレベルなど利用シーンに応じてこれを適切に設定しておくことが求められるが、前述1）～5）の組み合わせはRFCに規定されたものだけで300通りを越えており、利用シーンに応じた適切な設定をするには暗号技術に関する知識が必要となってしまう。このため、一般的なサーバ管理者においては（動作に支障がない限りは）初期設定のまま使っているケースが大半である。

こうした状況の中、前述の一連の暗号技術に対する脆弱性の発見により、特定の利用モードや共通鍵暗号アルゴリズムを回避する設定が求められるようになった。しかし、300種類以上の暗号スィートの組み合わせから適切な組み合わせリストを構成するには、暗号技術に関する十分な理解が求められ、個々のサーバ管理者が対応することは容易ではない。

一方で、適切な暗号スィートの選択は難しいものの、利用シーンの違いはそれほど多様ではなく、例えば接続性よりも安全性を優先したいサイトや、安全性よりも接続性を優先したいサイトなどに大別できると考えられる。このため、適切な暗号スィートの選択さえ済めば共有知とすることが可能であり、いわゆるベストプラクティスの早期確立が混乱の収束に向けた有効なアプローチと考えられる。

3-2. 多様な動作環境における実装状況の網羅的な整理

SSL/TLSが通信プロトコルである以上、前節で設定したサーバ側の暗号スィート群にクライアントのサポートする暗号スィートが含まれていなければ暗号化通信は実現できない。つまり、暗号スィートの選択を間違えるとクライアントによっては通信ができなくなる問題が発生する。クライアントがサポートする暗号スィートをきちんと把握できていればこの問題は回避可能だが、この把握が非常に難しいのが現状である。

フィーチャーフォンにおいては市場に普及しているほとんどの端末がSSL/TLSに対応しているが、実装状況として公開されているのはプロトコルバージョン程度にとどまり、暗号スィートまでは公開していないのが現状である。このため、暗号スィートを変更することで接続できなくなる機種がどの程度あるかをサーバ管理者が事前に把握することは極めて難しい状態にある。これらフィーチャーフォンの時代は、主要な機能や仕様などは移動体通信事業者が指定しつつも細かな実装は端末ベンダに任されており、共通鍵暗号の利用モードなども端末ベンダに任されていた部分と考えられる。そして、昨今のスマートフォンへの流れにおいて日本の携帯電話端末ベンダは統廃合が著しく、下手をすると対応状況の照会先がない、というケースがあっても不思議ではないだろう。

スマートフォンやタブレットのようなスマートデバイスにおいても、現時点では幸い携帯電話端末に比較すればまだ実装が新しいために影響は少ないものの、数年前の機種は既にアップデートの対象外であることも珍しくない。またAndroidやiOSなどの機能進化が著しい状況であることを含めて考えれば、いずれ暗号スィートのような詳細な実装の対応状況を誰も把握できなくなることは時間の問題であろう。

PCブラウザにおいても、マイクロソフトが2013年1月にRC4のサポートを停止するアップデートを配信し[microsoft2013]、ChromeではSHA-1を利用する一部のサーバ証明書に対して2014年11月以降警告を表示するようになるなど[chrome2014]、サーバ管理者はこれらの動向についても合わせて把握していくことが求められるようになってきた。

このようにSSL/TLSがコモディティ化するとともにその動作環境も多様化が進む一方で、その実装状況が把握できない状態では、設定変更を行うということは接続性の低下を招く場合があり、またPCブラウザのように自動更新されるものでは設定変更を行わずとも接続できなくなる場合も出てくる。今後暗号技術に対する攻撃が本格化し暗号スィートの設定見直しを迫られた場合に、こうした実装状況の把握が困難な状態は、脆弱性対応による影響の見積もりを難しくさせたり、代替暗号技術への移行を鈍らせる。

4. 今後の備え

4-1. 暗号技術のベストプラクティス確立

今後SSL/TLSに対する攻撃の本格化が進めば、利用する暗号スィートについてもその都度適切に見直す必要が出てくると考えられる。これには暗号技術に対する適切な理解が欠かせないため、専門家を集めてベストプラクティスを発行・改訂できる体制を確立しておくことが重要となってくるだろう。CRYPTREC（※）では、暗号技術活用委員会の運用ガイドラインWGにおいて、SSL/TLSに関するベストプラクティスの策定に取り組んでいるところである。もし今後SSL/TLS以外の分野でも同様の状況となった場合には、そこでの暗号技術利用シーンが数種類程度に収束するのであれば、SSL/TLS同様に専門家らによるベストプラクティスを確立することが迅速かつ適切な対応につながるものと考えられる。
※総務省及び経済産業省が共同で運営する暗号技術検討会（Cryptography Research and Evaluation Committees）

4-2. 多様な実装状況の把握

サーバ管理者が実装状況を把握して、暗号技術の攻撃に対する適切なリスク評価を行えるようにするためには、機器・端末ベンダからの情報公開は欠かせない。特に情報通信技術の中で用いられる暗号技術は、通信環境（サーバ、クライアント、回線網など）に応じて実装が多様化する一方で、利用シーンにおいては相互接続性が求められるため、機器への実装が多様化する中でその実装状況を把握しておく必要がある。

従来であればこうした役割は移動体通信事業者が担っていたが、それでも暗号技術の詳細までは把握していなかったという問題がある。また、スマートフォンのようにワールドワイドでプラットフォームが共通化されたことで、海外端末の流入とともに移動体通信事業者主導型の端末開発が縮小傾向にあるなど、移動体通信事業者のあり方も変わってきており、この問題については新たな解決策を講じる必要があるだろう。例えば、行政から機器・端末ベンダに情報公開なり報告なりを義務付ける、業界団体などで実装状況に関する情報や調査結果を集約管理する、などいくつかアプローチは考えられるが、どのようなアプローチがよいかは筆者も確信がない。