【マンスリーレポート2004/01】電子証明書の有効期限切れが引き金、ベリサインのCRLサイトでのレスポンス遅延

──────────────────────────────〔Info〕─
Scan Monthly Report　Best Worst
http://www.ns-research.jp/c2/shop/books/p-sbw01.html

製品・サービス・業界動向業界動向

2004年2月23日（月） 12時00分

──────────────────────────────〔Info〕─
Scan Monthly Report　Best Worst
http://www.ns-research.jp/c2/shop/books/p-sbw01.html

ネットワークセキュリティ・インシデント年鑑2003
http://www.ns-research.jp/c2/shop/books/p-inc02.html
───────────────────────────────────

　今年初め、米・ベリサイン社が運営する証明書失効リスト取得のためのサイトへのダウンロード要求が急増し、一時、レスポンスの遅延が発生するという事故が起きた。この事故はなぜ起きたのか、その背景をリポートする。

>> CRLとは、その取得サイトとは…　単なるアクセス殺到の事故ではない

　今回の事故の概要を明らかにしておこう。日本時間2004年1月8日午前9時（グリニッジ標準時1月7日午前0時）から、ベリサインが運営する証明書失効リスト（Certificate Revocation List、以下、CRL）の取得サイトにアクセスが急増し、CRLを取得できないほどのレスポンスの遅延が発生したというものである。平たく言ってしまえば「アクセス殺到でサイトがパンクした」という事故ではあるが、「CRL」やその「CRL取得サイト」など、一般的には聞きなれない用語もあり、いったい何が原因で事故が起きたのか、具体的な影響はどのようなものだったのか、今後、このような事故が起きる可能性はあるのだろうか…。気になるところは数多い。そこにスポットをあててみよう。

　今回の事故の全容を理解するには、まず、インターネット上で安全な通信を実現するために広く利用されている「PKI（Public Key Infrastructure：公開鍵暗号基盤）」について知っておく必要があるだろう。PKIとは、暗号化と復号化の過程において、一対となる異なる2つの鍵を利用する方法で、片方の鍵で暗号化された情報は、それと対になる鍵でしか復号化できない仕組みである。つまり「公開鍵と秘密鍵」で暗号化と復号化をする通信の技術である。この公開鍵と秘密鍵は認証局が本人確認の上、電子証明書とともに発行するものである。例えば、ある人物XがYに業務提携に関する契約書など重要な文書を送る際には、まず、受け手側のYが認証局に申請して、公開鍵と秘密鍵のペアを取得する。次に、送信側のXは、Yから公開鍵を入手し、その公開鍵で機密文書を暗号化して送信。Yは公開鍵とペアの秘密鍵を使用すれば文書を復号化して読むことができるという仕組みだ。このPKIでは、文書は電子証明書とともに送られる。暗号化された文書とともに電子証明書が送られてくることで、通信相手の正当性をも確認することができるようになっているのだ。

>> キーワードとなる証明書と証明書失効リストとは

　今回の事故のキーワードのひとつは、この電子証明書である。証明書には有効期限があるのだ。もし有効期限が切れている証明書が使われていたらどうなるのか？そのようなことを想定してか、PKIによる証明書を利用したアプリケーションには、その証明書が有効なのか、期限切れで失効しているのかを確認する仕組みがあらかじめ取り込まれている。一般的な仕組みととしては、証明書を発行した認証局にアクセスして、失効した証明書のリスト＝証明書失効リスト（Certificate Revocation List、以下、CRL）を取得するものである。この場合、認証局のCRL取得サイトからダウンロードすることになる。利用者は、CRLを取得することで、証明書が失効していないかどうかを確認できるのである。

　今回の事故は、証明書の有効期限、それを確認するためのCRLとその取得のための作業が絡み合って発生したものである。具体的には、Windows XP、およびそれ以前の基本ソフトにおいて、MS CAPIベースで動作するサードパーティ製品のセキュリティパッチの一部に、2004年1月7日で有効期限が切れる特定のCRL（Class3SoftwarePublishers.crl）が含まれていたために発生した。期限が切れているため、アプリケーション側に組み込まれていたCRLを取得するための仕組みが自動的に「あれっ、おかしいな、CRLを取得してみよう」と一斉に動き出し、その結果、認証局のCRL取得サイトにCRLの更新版を取得しようとダウンロードの要求が殺到したのである。そのためにCRLのダウンロードのレスポンスに大幅な遅延が発生した。そして、このCRL取得サイト「crl.verisign.com」を運営していたのは、もちろん、ベリサインである。

【執筆：下玉利尚明】

（詳しくはScan Security Managementをご覧ください）
http://www.ns-research.jp/cgi-bin/ct/p.cgi?ssm01_netsec

《ScanNetSecurity》