「Cryptography(暗号技術)」の現状について考える(前編):その脆弱さとHeartbleed脆弱性

「Cryptography(暗号技術)」は、2014年に入ってから狙われ続けているように見受けられますが、実際のところ、暗号技術は常に攻撃にさらされており、そのために日々進化し続けていると言えるかもしれません。暗号技術に対して常に注意を払う必要があると認識を持つことは良いことです。なぜなら、暗号技術への脅威は、今年 4月に発覚した脆弱性「Heartbleed」のように非常に破壊力があり、RC4 や MD5、SHA1、Dual_EC_DRBG といったさまざまな暗号アルゴリズムは、以前から「問題」を抱えています。個人的には、このようなアルゴリズムはもはや利用すべきでないと考えています。

■暗号技術は信頼できるか
暗号技術は、芸術であり科学です。良い暗号アルゴリズムもしくは、プロトコルを作成するための数学の多くは堅固かつ繊細です。おそらく、堅牢なアルゴリズムを作成するための情報理論や統計、アルゴリズムを熟知している人は、世界でも数十人でしょう。こうした人たちは希少な存在であっても、「cryptanalysis(暗号解読)」にはおそらく適していません。暗号解読とは、暗号設計の対局にあるもので、つまり暗号を突破する技術です。安全な暗号アルゴリズムを作成するためには、暗号作成および暗号解読の両方の知識が必要です。

安全な暗号もしくは暗号アルゴリズムを作成する決定性がまだないため、創造性も必要となります。一方向ハッシュ関数である MD5 といった使い勝手のいいアルゴリズムは、これまでの知識から得た直感を基に、その後の厳密な解析を経て作成されました。アルゴリズムが作成されるたびに、攻撃は成功するまで続き、その結果が設計に反映されます。そしてようやく、その時の水準において、創造性と精巧さの面で十分に堅牢であると考えられるアルゴリズムが作成されます。

しかしそれでも、こうしたアルゴリズムは最後には破られます。例えば、2004年には、MD5 と SHA1 は「collision resistant(衝突耐性)」でないことが明らかになりました。衝突耐性は、ハッシュアルゴリズムをデジタル証明書に利用する場合に必要条件とされているものです。この脆弱性は、それ以前の研究では脆弱性利用の攻撃に利用されないとされていました。

この 2004年の研究により、Webサイト利用を安全にする SSL/TLSプロトコルはさらに攻撃を受けました。MD5 は現在も、「Crossbear」の SSLプロジェクトからのデータに基づき、SSL/TLS のデジタル証明書に利用されています。MD5 に存在する脆弱性の一部は緩和されたと考えられていますが、攻撃が巧妙になっているため、MD5 の使用はまだ推奨できません。さらに心配なことには、SSL/TLS のデジタル証明に必要とされている基準を満たす実践的で安全性を証明する「cryptographic hash function(暗号学的ハッシュ関数)」が存在するかもわかっていません。別の目的で MD5 を使用しているユーザもいますが、どのような目的で MD5 を利用しているかを理解していれば問題ないでしょう。

今回、この記事から学んでほしいのは、暗号技術は進化し、ユーザはその最新技術に直接的または間接的に対応していかなければならないということです。例えば、Microsoft は、2016年以降、SHA1 を使用したデジタル証明書を拒否すると発表しています。Microsoft のユーザにとっては、これは良いニュースでしょう。少なくとも、これによりユーザは保護されます。セキュリティに強いソフトウェア企業もあれば、そうでないところもあります。どの企業を選ぶかが、セキュリティに影響を与えます。

■暗号技術の脆弱さ
暗号の裏にある数学は、かなり繊細で特殊なため、どんなアルゴリズムも安全に実装するのは困難です。もし「プログラマ免許証」というものがあるならば、暗号技術がそれに当たるでしょう。暗号の実装にあまりにも多くの脆弱性が確認されているため、可能な限り信頼できるオープンソースを実装するか、その数学に通じている暗号作成者にプログラミングを発注すべきです。暗号技術の第一人者である「Victor Shoup」は、自身の C++ライブラリを管理しています。なぜなら、セキュリティを考慮せずに作成されたライブラリを利用するのは不安を感じるからです。

そして、Heartbleed脆弱性が発覚しました。OpenSSL は SSL/TLSプロトコルと関連アルゴリズムのオープンソース実装です。OpenSSL は、暗号技術がどのように実装されるべきかの指針であり、そうでなくてはなりません。しかし、Heartbleed 脆弱性が発覚しました。この単純な脆弱性の本当の悲劇は、脆弱性が存在していたことではなく、この脆弱性が 2年以上も発覚しなかったことです。これは、変更点が公開され、直ちに相互評価がなされるオープンソースプロジェクトでは起こるはずのないことです。

当然の反応として、Unix系オープンソースである「OpenBSD」のコミュニティは、OpenSSL の管理に対する不安を示唆し、OpenSSL を分岐して「LibreSSL」を作成すると伝えました。OpenBSDプロジェクトの最初の活動が、従来のプラットフォームコードの多くを取り除くことだったと考えると、LibreSSL は、近いうちに OpenBSD専用のライブラリになるでしょう。なお、LibreSSL はすでに VMS上で実行できません。このようなことが頻繁に起こり、2つのオープンソースが差異が大きくなって、セキュリティ更新プログラムの共有が難しくなる段階に達すると、手も足も出なくなります。Unix用メールサーバソフトウェア「Postfix」は「Sendmail」の肥大化に対応して作成されましたが、結局は Sendmail と同じぐらいに肥大化し、不具合がわずかに少ないだけでした。これが LibreSSL がたどる運命でしょうか。

Heartbleed脆弱性は、OpenSSL の実際の暗号技術とは関係がないことを指摘しておかなければなりません。Heartbleed脆弱性はセキュリティ上に深刻な問題を引き起こしましたが、このような問題は、ほぼどのソフトウェアにも起こりうることを示しています。

後編では、ハードウェアの暗号技術の安全性などについて述べます。

参考記事:

  • The State of Cryptography in 2014, Part 1: On Fragility and Heartbleed
    by Morton Swimmer (Senior Threat Researcher)
  •  翻訳:品川 暁子(Core Technology Marketing, TrendLabs)