SSL/TLS, SSH で利用されている公開鍵の多くが意図せず他のサイトと秘密鍵を共有している問題

インターネット上の IPv4 アドレスを広範囲にスキャンして、SSL/TLS, SSH で利用されている公開鍵証明書および DSA 署名を収集したところ、SSL/TLS では5.57% (714,243アドレス)、SSH では9.60% (981,166アドレス) が、意図せず他のサイトと秘密鍵を共有していることが報告されています。その原因は機器出荷時のデフォルト鍵を利用しているケースと、鍵生成時に擬似乱数生成モジュールのエントロピー不足であることが指摘されています。善意で提供されているオンライン鍵チェックサービスにより公開鍵が脆弱かどうかチェックできますので、必要な場合には早急に対策を実施してください。


USENIX Security Symposium は、毎年実践的な研究発表が行われる場で、本年は8月6日から10日にかけて、米国 Redmond にて他のワークショップとともに開催されました。本稿では、USENIX Security ’12 にて Best Paper Award を受賞した論文[1]Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman, “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” … Continue readingの紹介を行います。

この論文では、インターネット上の IPv4 の port 番号 443 (SSL/TLS) と 22 (SSH) を広範囲にスキャンして、SSL/TLS, SSH で利用されている公開鍵証明書および DSA 署名を収集したところ、その多くのサイトが他のサイトと同じ公開鍵・秘密鍵を利用していたという結果を報告しています。異なる IP アドレスで同じ公開鍵・秘密鍵を利用しているケースのすべてが問題であるということではありませんが、第三者と同じ秘密鍵を意図せず使用している事例もあることが警告されています。この状況を鑑み、著者らはオンライン鍵チェックサービスを提供しています[2]https://factorable.net。実際に利用している公開鍵が脆弱かどうかチェックできますので、もし脆弱鍵を利用していることが判明した場合には、鍵を更新することをお勧めします。

この論文によると、SSL/TLS に呼応する1280万 IP アドレスのうち61%が、SSH に呼応する1020万 IP アドレスのうち65%が、他のいずれかの IP アドレスと同じ公開鍵・秘密鍵 (このような状況の鍵を Repeated keys と呼んでいます) を利用しているとのことです。もちろんこれらのすべてに問題があるわけではなく、意図的に複数 IP アドレスで同じ鍵を利用しているケースもあります。例えば、負荷分散のため DNS ラウンドロビン等の技術を用いて同じ FQDN に複数の IP アドレスを割り当てているケースや、ホスティングサービスでの共用サーバなどがそれらに該当します。また SSL/TLS の利用においては、複数の FQDN に対して同じ鍵や公開鍵証明書を共有するワイルドカード証明書の利用もこれに該当します。

他のいずれかの IP アドレスと同じ鍵を利用している IP アドレスのうち、SSL/TLS では5.57% (714,243アドレス) が、SSH では9.60% (981,166アドレス) が危険な状態に置かれていると報告されています。これらの脆弱鍵 (Vulnerable repeated keys) を利用しているために危険に晒されているサイトのうち、機器出荷時のデフォルト鍵を SSL/TLS において利用していると思われるケースが、少なくとも5.23% (670,391アドレス) も見つかっています。出荷時のデフォルト鍵を利用しているデバイスのほとんどがネットワーク機器や組み込み機器で、著者らは現在60のベンダーに連絡を取っているとのことです。そのうち20のベンダーからはなんらかの回答がありましたが、アドバイザリ[3]https://factorable.net/advisories.htmlを出したのは3ベンダーのみという状況です。また、この研究とは別に、ネットワーク製品においてデフォルト鍵を利用する脆弱性に関するアドバイザリが公開されたこともあります[4]F5 BIG-IP remote root authentication bypass Vulnerability https://www.trustmatta.com/advisories/MATTA-2012-002.txt

これらの機器以外に、Apache Web サーバや Citrix リモートアクセスサーバでもデフォルト鍵を利用している事例が報告されています。そのうち38の証明書が、ブラウザで信頼されている認証機関から発行されたものでした。その中には Fortune 500 にリストされている企業、保険会社、法律事務所、公共交通機関、米軍などが含まれており、著者らはできるだけこれらの組織に連絡を取るようにしているとのことです。

本論文では、このような状況が発生した原因の一つとして「世の中の広く出回っている擬似乱数生成モジュールに問題がある」という点を指摘しています。鍵生成や署名生成時に利用する擬似乱数生成モジュールのエントロピーが不足しているために、十分な鍵空間から鍵を生成していないことから、秘密鍵を共有してしまっているという主張です。前述の SSL/TLS において脆弱鍵を利用している5.57%のホストのうち、出荷時デフォルト鍵利用の5.23%を除く0.34% (43,852アドレス) のサイトが、鍵生成時に擬似乱数生成モジュールのエントロピー不足が原因であると報告されています。

この擬似乱数生成モジュールのエントロピーが不足することに起因する問題は、Debian の OpenSSL における脆弱性[5]Debian Security Advisory, DSA-1571-1 openssl — predictable random number generator http://www.debian.org/security/2008/dsa-1571などで既に報告されています。Debian のあるバージョンにおける OpenSSL を使って鍵生成を行った場合、極端に少ない鍵空間からしか秘密鍵を導出していないという問題がありました。2008年にアドバイザリが発行されていたにも関わらず、今もなお脆弱鍵を利用しているサイトが SSL/TLS では0.03% (4,147アドレス)、SSH では0.52% (53,141アドレス) 存在していることが報告されています。

さらに著者らは各エンティティに応じていくつかの対策について推奨しています。

  • デバイス製造者
    • ビルトインされたデフォルト鍵や証明書をユーザが利用できる状態にしない。
    • 十分なエントロピーを確保するためにハードウェアよる擬似乱数生成器を利用する。
  • エンドユーザ
    • デバイスが出荷されたときに格納されているデフォルト鍵や最初にブートされた際に生成される鍵を利用せず、十分なエントロピーを確保できる他の環境下で生成した鍵を利用する。
    • 自ら生成した鍵が脆弱かどうか、つまり既に他のユーザに利用されている鍵かどうかをチェックする。
  • 公開鍵証明書発行機関
    • カスタマーが提示した公開鍵をチェックし、脆弱鍵の場合には証明書を発行しない。

今後の研究として DH や ECDSA など他の暗号アルゴリズムにおける調査だけでなく、機器ブート時に生成される擬似乱数の偏りが問題になりそうな別のケース (TCP シーケンス番号など) についても調査対象としたいという方向性を示して会場での発表を締めくくっています。


秘密鍵を共有していることによる影響

今回の論文で指摘されたような機器のデフォルト鍵を利用している場合、他の同機種を持つユーザも同じ秘密鍵を持つ可能性が高くなります。また、意図せず第三者と秘密鍵を共有してしまった場合には、同じ秘密鍵を持つ者に悪用され、以下のような問題が発生する可能性があります。

  • 暗号化された通信データが復号されてしまう。
    • Cookie やログイン時に用いたパスワードなどの情報を搾取できる場合、復号可能であったデータ自体の漏洩にとどまらない。
  • SSL/SSH サーバのなりすましをされてしまう。
    • 公衆無線 LAN など DNS 情報が信頼できない環境では、不正サイトであるにも関わらず正当なサイトのように見えてしまう。
  • 許可していないユーザにログインされてしまう。
  • 署名を偽造されてしまう。
    • コード署名偽造の場合、当該組織による署名が付与された正当なプログラムとして OS が受け入れることにより、不正プログラムをインストールされてしまう。

幸いなことに、現時点では意図して秘密鍵を見つけ出せるものではありませんが、同じ秘密鍵を持つ第三者がいる可能性のある鍵を利用している場合には、現在利用中の鍵を更新して別の鍵を利用することをお勧めします。著者らが善意で提供しているオンライン鍵チェックサービスで、公開鍵が脆弱かどうかチェックできます。このように、脆弱な公開鍵は外部から判定することができる問題であり、攻撃者も同様な情報を入手することができることに注意して、対策が必要な場合には早急に対策を実施してください。

「多くの公開鍵が他のユーザと秘密鍵を共有してしまっている」という指摘は、今年2月に別のチームから行われていて、通称 RwWr 論文として公開されています[6]Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter, “Ron was wrong, Whit is right” http://eprint.iacr.org/2012/064。さらにまもなく開催される CRYPTO2012 にて RwWr 論文と同じ著者らによって発表される見込み[7]Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter “Public Keys” http://www.iacr.org/conferences/crypto2012/abstracts/session11-2.htmlであり、USENIX Security ’12 で発表された本論文との視点や主張の違いが注目されています。後日 CRYPTO2012 での発表の様子を報告する予定にしております。

脚注

脚注
1 Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman, “Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices” https://www.usenix.org/conference/usenixsecurity12/mining-your-ps-and-qs-detection-widespread-weak-keys-embedded-devices
2 https://factorable.net
3 https://factorable.net/advisories.html
4 F5 BIG-IP remote root authentication bypass Vulnerability https://www.trustmatta.com/advisories/MATTA-2012-002.txt
5 Debian Security Advisory, DSA-1571-1 openssl — predictable random number generator http://www.debian.org/security/2008/dsa-1571
6 Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter, “Ron was wrong, Whit is right” http://eprint.iacr.org/2012/064
7 Arjen K. Lenstra, James P. Hughes, Maxime Augier, Joppe W. Bos, Thorsten Kleinjung, Christophe Wachter “Public Keys” http://www.iacr.org/conferences/crypto2012/abstracts/session11-2.html

シェアする