SSL証明書は安全なのか?~Comodo/DigiNotar事件を振り返って
ベリサインが最新動向など解説
ベリサイン SSL製品本部 プロダクトマーケティングチーム アシスタントマネージャーの上杉謙二氏 |
日本ベリサイン株式会社は8日、「認証局の安全性とSSLサーバー証明書の暗号強度」と題した説明会を開催した。2011年は認証局(CA)でのハッキング事件が相次いだ。認証局を取り巻く環境はどうなっているのか、証明書は安全といえるのか――。
●Comodo/DigiNotar事件を振り返って
SSLサーバー証明書は、認証局と呼ばれる証明書発行機関の独自の審査基準に基づいて作成される。Webブラウザにはあらかじめ認証局のルート証明書が登録されており、認証局から発行された証明書をWebサーバーにインストールし、Webブラウザが証明書情報を参照することで、Webサーバー間の安全な通信が実現する。
2011年には、英Comodo、オランダDigiNotarという認証局において、ハッキングによって偽造証明書が発行されるなどの侵害事件が起きた。Webの根源的な安全性にかかわる認証局での事件だったため、業界に多大な影響を及ぼした。
2011年3月に起きたComodoの事件では、Comodoが委託するイタリアの登録局(RA)がハッキングされた。登録局とは証明書発行申請者の情報を確認し、証明書を発行しても問題がないか審査を行う機関である。この結果を受けて、発行局(IA)が実際の証明書発行を行う。1つの認証局が登録局と発行局を兼ねる場合もあるが、Comodoの場合は登録局の業務を外部に委託していたのだ。
この登録局と発行局では、SSLサーバー証明書の認証を簡素化し、自動発行を行っていたため、結果としてGmail、Skype、Mozilla、Microsoftアップデートなどの偽造証明書が発行されてしまった。つまり、事件の原因は「登録局のセキュリティ対策・設備などの脆弱性」と「SSL発行基準の脆弱性」だったといえるが、幸いなことに実害らしき実害は報告されていないという。
一方、2011年8月に起きたDigiNotarの事件では、システムへのパスを不正に入手し侵入した何者かが証明書を発行するための情報を盗み出し、偽造証明書が発行されてしまった。このケースでは事件発覚後、WebブラウザベンダーがDigiNotarのルート証明書を失効・削除したことで、オランダ政府や金融機関のWebサイトにアクセスできなくなった。このため影響も大きく、日本に本社のあるグローバルサインなどもその余波を受けたとされる。ルート証明書を削除されたことで、DigiNotarは事業が立ち行かなくなり、破たんに追いやられたことも大きなインパクトとなった。この場合の原因も「不正アクセスを許した認証局のセキュリティ対策」「設備などの脆弱性」にあったと報告されている。
Comodo事件の概要 | DigiNotar事件の概要 |
残念なことに認証局へのハッキングは成否はともかく頻繁に発生している。ベリサインも2010年にハッキングを受けていたことが明らかになっている。この件については「当時の米VeriSignの企業内ネットワークが対象で、商用システムとは別に運用され、インフラも規定も手順も異なるものだったため、サーバー証明書やDNSなどの商用システムは一切影響受けていない」とのことだが、認証局がその役割の重要性から最も攻撃される対象の1つであることは間違いない。
では、認証局は本当に安全なのか。証明書は信頼できるのか。ベリサイン SSL製品本部 プロダクトマーケティングチーム アシスタントマネージャーの上杉謙二氏は「発生した一連の事件は、SSL通信の仕組みや暗号アルゴリズムに傷があったわけではなく、認証局が不正な証明書の発行を許してしまったことに起因している。つまり、信頼できる証明書とは、認証局としてのPDCAを順守して発行されるのが絶対条件になる」と話す。
認証局としてのPDCAとは、CPS(Certification Practice Statement:認証実施規定)の策定【Plan】と、それに基づく日々の認証業務【Do】、内部・外部監査【Check】、日々の業務トレーニングやインフラへの積極的な投資【Action】のことで、Comodoは【Check】に、DigiNotarは【Action】に不備があったと見られる。技術的な脆弱性ではなく、運用に問題があったために今回の事件は起きてしまった。今後もWebを安全に使っていくためには、認証局はこれまで以上に、安全性に向けた基本的な取り組みに努力する必要があるというわけだ。
ベリサインでもPDCAすべてでさまざまな取り組みが行われている。例えば、CPSのほかにも、より詳細を取り決めたValidation Planや、物理・人・鍵管理の角度から規定したセキュリティポリシーが存在する。
物理セキュリティは、認証局の所在地を非公開にしていることをはじめ、厳密な入退室権限、一定以上のセキュリティが求められるスペースには複数人分必要となる生体認証、認証関連システムにおける4段階の物理セキュリティなどが設定されている。また、鍵管理も別々に分離したパーツを分離保有させる「シークレット・シェアリング」といった手法を導入するなど、極めて厳重に防備されている。
最も肝心な【Check】【Action】においても、定期的な脆弱性アセスメントや年次の外部監査(ISAE3402)を実施。セキュリティ部門と有識者による委員会を設置し、セキュリティの有効性の確認や、インシデントについて社内共有ルールのドキュメント化などを行っているという。
「こうした取り組みを継続することが、認証局として唯一有効な対策だろう」(上杉氏)。
ベリサインのPDCAの取り組み |
●新しい業界標準化の動き
認証局を超えた業界としての動きも始まっている。主要な認証局、Webブラウザベンダーが名を連ね、この問題に当たる業界団体・CA Browser Forumにおいて、認証局が証明書を発行するのに必要な技術、認証、ライフサイクル管理、監査などの必須事項を取りまとめた「Baseline Requirement(BR)」が策定されたのだ。
同団体の同様の動きとしては、EV SSL証明書のガイドライン化が過去にあった。証明書発行を申請する企業・団体の実在性をより厳格に確認するために、その認証ルールを細かく定めたものだ。しかし、今回のBRに比べると、EV SSLの時は影響範囲が限定的で、従って今回のBRはより普遍的なものといえる。
説明会ではBRの取り決めのうち主だったものが紹介された。1つ目は、予約アドレス・プライベートドメイン名への証明書の発行停止(2015年11月1日より)と強制失効(2016年10月より)について(BR章番号9.2.1)で、例えば企業内のイントラ用ドメインなどに対して証明書を発行できないようにするという。
2つ目は長期有効証明書の停止に関して(BR章番号9.4)で、有効期限60カ月を超える証明書は2012年7月以降、有効期限39カ月を超える証明書は2015年4月以降発行できないとされた。
また、運用面においても、認証局は証明書の失効を24時間365日体制で受け付けなくてはならない(BR章番号13.1.4)、認証業務をすべてか一部でも行うサードパーティは認証局と同じレベルでトレーニングや文書保持をしなくてはならない(BR章番号14.1.2)、認証業務を一部でも請け負う登録局は必要な監査を受けなければならない(BR章番号17.5)などが定められた。これらはまさにComodo/DigiNotar事件を受けてのものだろう。
BR発行による主な変更点 | 各変更のタイムライン |
●取り残されたSHA-1もついに新旧交代へ
暗号アルゴリズム新旧交代の概要 |
Comodo/DigiNotar事件は技術的な原因ではなく運用的なものと前述したが、では技術的な対策はどうなのか。心配は無用だ。SSLの暗号強度を維持するための取り組みも着々と進んでいる。
暗号強度というと「暗号アルゴリズムの2010年問題」が思い出される。米国政府で使用する暗号アルゴリズムを決定するNISTが、「弱い」暗号技術の使用を2010年末までとしたことに端を発する問題だ。
日本ではそれより少し遅い2013年を新旧交代の時期としているが、AESがFIPS、ISO/IECの標準規格として採用されたり、RSA 1024ビットの代替方式であるRSA 2048ビットが主流になりつつあるなど、業界での対応も進んでいる。
唯一取り残されていたのがハッシュ関数だった。従来のSHA-1がすでに強度が「弱い」とされつつも、移行のハードルが高いがために、2010年以降も利用可能となっていたのだ。しかしこれについても、ついに新旧交代の兆しが見えた。ベリサインが国内認証事業者としては初めて、SHA-2(256ビット)を署名アルゴリズムに利用したSSLサーバー証明書の発行を決めたのだ。提供時期は2月下旬を予定。現在利用中の証明書と並行して、SHA-2のSSLサーバー証明書への移行に必要な検証を実施できるとしている。
●今回の経験を生かして
SSLはWebになくてはならない技術である。Webのサービスが増え、企業のシステムもWebアプリケーション化が進む昨今では、より一層その重要性が増しているといえる。特に偽造証明書が作成されるという事態は、フィッシングサイトでの悪用はもちろん、通信の秘匿性へのダメージすら可能性として浮上し、決してあってはならないことだ。Comodo/DigiNotar事件はその警鐘ともなった。セキュリティに特効薬はないが、各認証局は業界を挙げて、今回の経験を生かしていってほしい。
関連情報
(川島 弘之)
2012/2/9 18:06
-ページの先頭へ-