Baseline Requirementとは？
2011年に偽造証明書が発行されるという事件がありました。
発行されてしまったのはComodo社とDigiNotar社の偽造証明書。
Comodo社のケースではGmailやskypeなどの偽造証明書が、
DigiNotar社のケースではなんと531件の偽造証明書が発行されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。
どうしてそのような事件が起きてしまったのでしょう？
まずComodo社のケースから見てみましょう。
認証局(CA)は、
申請者の情報を確認し発行する前の審査を行う登録局(RA)と
審査の結果を受けて証明書発行のみ行う発行局(IA)に分かれます。
1つの認証局が両方を行う場合もありますが、
Comodo社では事件の起きた2011年時点では登録局の業務を外部に委託しており、
Comodo社では認証を簡素化するために自動発行を行っていたため、
登録局がハッキングされ偽造証明書が発行されてしまいました。
一方、DigiNotar社では、ComodoHackerと名乗る人物が
DigiNotar社のシステムへのパスを不正に入手、
証明書を発行のための情報を得て偽造証明書を発行しました。
GoogleなどのWebブラウザには認証局が自ら署名して発行する
ルート証明書があらかじめ組み込まれています。
このルート証明書を使ってコンピュータはwebサイトに発行されている
証明書が正しいものなのか確認しています。
今回のケースでは偽造証明書は、ルート証明書が登録されているDigiNotar社の
証明書として不正に発行されてしまっていたため、信頼できる証明書として扱われてしまっていました。
なぜ偽造証明書に気づいたかというと、Google ChromeがGoogleのサイトのみ
各ページの証明書を発行するルート認証局の一覧を所持する機能をサポートしていたため、
偽のGmailのページにつけられたDigiNotarの証明書に対してセキュリティ警告したためでした。
それまでに実に531件もの偽造証明書が発行されてしまったため、
Google Chromeを始めとするWebブラウザベンダーによって
DigiNotar社のルート証明書がリストから削除されてしまい、
DigiNotar社は事業継続が困難になり倒産に追い込まれてしまいました。
実は、原則的には認証局は誰でも作ることが出来ます。
各認証局ごとに安全性への取り組みは異なりますが、
信頼できる証明書とは認証局が考える「PDCA」を遵守して発行される必要があります。
PとはPlan(企画・計画)。
認証局はそれぞれの証明書を発行する際の運用規定をまとめたCPSを制作し、
ホームページ上でまとめています。
DとはDo(実行)。
CPSに従って運用を行います。
CとはCheck(評価)。
定期的にセキュリティの脆弱性アセスメントを行い結果を監査報告します。
また、外部監査も行います。
AとはAction(改善・見直し) 。
セキュリティの促進やインシデント(問題)が起こった時のルールのドキュメント化などを行います。
ベリサインではこのようにCPSによって認証の運用規定を作成し、運用を行っています。
しかし、ComodoやDigiNotarの偽造証明書発行事件が起こってしまいました。
事件が起きた当時、業界全体での運用規定をまとめた文書の作成を行う議論が進んでいましたが、
この事件がおきたことで議論が加速し、
業界全体での運用規定をまとめた文書、Baseline Requirementが調印されることとなりました。
Baseline RequirementはCA Browser Forumによって制定されました。
Baseline Requirementは、それまでCPSによってそれぞれが定めていた運用規定を
業界でまとめた初の試みで、2012年の7月から発行されます。
ベリサインやジオトラスト、グローバルサインや、IEやsafari等の主要なCAとブラウザベンダーが
サインをしているため、Baseline Requirementに準拠しない場合は
ブラウザの信頼されるルート証明書から除外される可能性があります。
Baseline RequirementはベリサインのHPにて近日公開予定のようです。
Comments: 0