久保
博
|
|
Debian Project か ら 発 表 さ れ た Debian セ キ ュリ テ ィ勧 告 の DSA–1571 は 、 OpenSSL の脆弱性に関するものでした。 こ の勧告に端を発っした脆弱性の問題は、 他の Debian セキュリティ勧告とはやや異なる波紋を社会に投げかけ、 遂には日本べサ イン社がプレスリリースを発表するまで社会的影響が広がりました。 これを機会に、 OpenSSL とサーバー証明書について、 ユーザーの視点で仕組みを解説します。
2008 年 5 月 14 日「Debian セキュリティ勧告」 に、 OpenSSL の脆弱性情報が発表されました。
Debian システムで、 バージョン 0.9.8c-1 以降の OpenSSL で作成された、 暗号鍵に関するデータは捨て て作り直す必要があります。 さらに、 影響を受ける Debian システムで、 署名や本人認証の目的で使われ た全ての DSA 鍵は脆弱であると考えてください。 デジタル署名アルゴリズムは、 署名生成時の秘密の乱 数の値に依存しているからです。
これにより、 脆弱性を抱えた OpenSSL を使って生成された電子署名の鍵は、 脆弱であるものと認識され、 それには SSL で 利用される X.509 のサーバー証明書も含まれていました。
複数の商用の X.509 証明書の認証局から、 DSA-1571 のためのサーバー証明書再発行について、 声明が発表されま し た 。
5 月 16 日日本クロストラスト Debian に含まれる OpenSSL の脆弱性への対応に関するお知ら せ*1 。
5 月 19 日サイバートラスト サーバー証明書の再発行が無料であることをアピール。 *2
5 月 20 日日本ベリサイン 「日本ベリサイン、 Linux OS の脆弱性による影響を受けたお客様に、 電子証明書を再発行」 *3。
5 月 21 日 Comodo COMODO OFFERS FREE REPLACEMENT CERTIFICATE TO ANY INDIVIDUALS AFFECTED BY DEBIAN VULNERABILITY FLAW*4 .
5 月 22 日グローバルサイン 脆弱性について注意喚起した上で、 サーバー証明書の再発行がもともと無料であることさりげなくアピー ル*5 。
まずは、 OpenSSL とベリサインなどの認証局との関係を解き明かす為、 まず、 サーバー証明書について解説し ます。
電 子 署 名 と は 、 電 子 情 報 に 対 し て 付 加 す る 特 殊 な 情 報 で す 。 電 子 署 名 が 拠 り 所 と す る 重 要 な 技 術 に 、 「公 開 鍵 暗 号 」 が あり、 暗 号化する鍵と復号する鍵が別々で、 しかも、 片方は一般に公開しても構わないようにできています。 電子署名を施す署名者 A さんは、 秘密の情報 SA (秘密鍵) と公開情報 PA (公開鍵) を用意します。 また、 署名されるデジタル情報を M としておき ます。
A さんが A さんにしか作れないモノを作れば、 A さんが確かに A さんであることを示せます。
A さんしか知らない SA を使って、 電子署名を施すと、 署名をした人が確かに A さんであることが示せま す。 なお、 A さん以外の人がそれを確認するには、 PA を使います。
A さんがあることを表明しました。 その表明文に A さんしか知らない SA を使って、 電子署名を施すと、 確かに A さんがそれを表明したことが示せます。 なお、 A さん以外の人がそれを確認するには、 PA を使い ます。
M の電子署名 σ を与える関数を f とすると、
 | (1) |
電子証明書は、 このように構成されます。 簡潔にまとめると、 電子証明書の概念上の構成要素は
です。
X さんの公開鍵 PX が、 確かに X さんのものであることを表明する電子文書が公開鍵証明書です。 「PX が、 確かに X さん のものである」 という叙述を mX とすると、 認証局 C がその文書を発行する場合は、 式（1） の M に PX と mX の組 (PX,mX) を、 SA に SC を代入したものになります。
 | (2) |
こうして、 ある公開鍵で別の公開鍵を署名する、 という関係が生まれました。 これは連鎖させることができます。 矢印-→ で電子署名する関係を表すと、
 | (3) |
のような関係を持たせることができるわけです。 PC は、 認証局の公開鍵で、 予め信頼できると分かっているものとすれば、 P1,P2,P3,P4,…はすべて信頼できることになります。
実用上は、 単に「公開鍵 PA が A さんに属する」 ということだけでなく、 他の述語も一緒に署名されます。 例えば、 「B と いう会社は、 実在する会社で、 住所は XXX です。 」 のような表明です。
世の中で広く使われている公開鍵の証明書のひとつは、 X.509 と言う規格に従ったもので す*6 。 もともと、 国連の下位機関である国際電気通信連合 (ITU) が定めた勧告です。 その中で、 頭に X が付く勧告は、 「X シリーズ勧告」 の呼ばれていて、 データ通信網に関する勧告が分類されていま す*7 。 X.509 では、 X.500 識別名を利 用した公開鍵証明書を定めています*8 。
ディレクトリサービスと言うのは、 階層的な名前から、 それに対応するオブジェクトとその属性とを記憶し、 検索できるよう にしたシステムです。 「階層的な名前」 というものの例を挙げてみると、
のようものです。 X.500 では、 例 1 のような階層的な名前をうまく扱えるようになっていて、 京都府向日市の仮想八百屋さんで ある八百竹は、 X.500 風に書くと、
C=JP, ST=Kyoto, L=Mukou, CN=Yaotake
になります。
SSL およびその後継の TLS[4]では、 通信の最初のハンドシェイクで X.509 の公開鍵証明書を交換します。 そのうちサーバー からクライアントへ向けて送信される SSL のサーバー証明書は、 クライアント (ブラウザ) から見て、 相手のサーバーが確かに 自分がアクセスしようとしているサーバーなのかどうかを確認する根拠を提供するのが一つの役目です。 そのために、 サーバー 証明書には次の情報が含まれています。
これらの情報は、 認証局にサーバー証明書の発行を依頼する際にサーバー運営者が認証局に提出する証明書署名要求 (Certificate Signing Request 略して CSR) に最初に記述します。 なお、 各認証局毎に細かい差異がありま す*9 。 詳 しくは、 各認証局の CPS (Certification Practice Statement) や CP (Certificate Policy) という公開された文書に書いてある こともあります。
また、 サーバー証明書に含まれる公開鍵が署名だけでなく暗号化にも使える場合は、 SSL のセッション鍵を交換する為にも 使われます。
公開鍵証明書に含まれている公開鍵が暗号学的に有効であるためには、
が揃っている必要がありますが、 時には証明書発行後に、 これらの条件が破れてしまうこともあります。
X.509 を中心とした PKI (Public Key Infrastructure) の設計では、 このような事態も想定されてます。 です ので、 必ず証明書には有効期限が定められていて、 時代遅れの証明書がいつまでも出回らないようにしてい ます。
また、 もしも、 これらの条件を満たさなくなった「もう使えない」 証明書が発生したら、 認証局にその旨を申し出ます。 する と、 認証局は、 その証明書を「失効リスト(Certificate Revocation List 略して CRL)」 に掲載します。 CRL は、 認 証局が配布していて、 どこで手に入れたら良いかは、 公開鍵証明書の中に予め、 cRLDistributionPoints と いう属性で示してあります。 最近目にする証明書では、 ほとんどの場合 http で始まる URL が書かれてい ますが、 サーバー証明書の設計上は LDAP のディレクトリサーバーで配布することも想定されているよう です。
なお、 CRL に掲載されるのは、 失効した証明書の Serial Number という属性値と失効した日付です。 CN (即ち、 サーバー 証明書のホスト名) は載っていませんので、 どのサーバーの証明書が失効したかは、 CRL を見ただけでは分かりま せん。
SSL のサーバーを構築する上で OpenSSL のパッケージが関係する処理をざっと挙げると
があります。 DSA–1571 は、 乱数の質が悪く、 鍵の組の生成で容易に推定できる範囲でしか乱数を生成していなかった、 という ことが問題になっていましたので、 4.3.5節の条件 3 が満たされなくなった、 と言うのが DSA–1571 から発生した問題 です。
サーバー証明書の秘密鍵が暴かれることことで成立する攻撃には、 次のようなものが考えられます。
1, 2 は、 安全な公開鍵に変更すれば、 変更後は安全になります。
3 に関しては、 サーバー管理者が脆弱な公開鍵を SSL で使うことを止め、 安全な公開鍵に交換したとしても、 公開鍵を変更 する前に脆弱な公開鍵を攻撃者が入手していれば、 成立します。 但し、 サーバー管理者が認証局に申請して脆弱な公開鍵を失効 させてくれれば、 脆弱な公開鍵が CRL に掲載されます。 ほぼすべての認証局は、 CPS などで失効手続きについて規定してお り、 失効申請の窓口も完備しているはずですので、 サーバー管理者さえしっかりしていてくれれば、 脆弱な公開鍵を失効はして もらえます。 ですので、 あとは、 クライアント側が CRL を入手できれば、 3 の攻撃を回避することもできるわけ です。
クライアントの立場で SSL のサーバーを利用する場合、 すなわち、 https で始まる URL のサイトに訪問する場合に は、 4.4.8節で説明する事項に合意の上、 なるべく新しい CRL を入手し、 お手元のブラウザに取り込みま しょう。
すると、 ブラウザが CRL と照合してサーバー証明書の有効性を確認してくれます。
現在は、 認証局は CRL を web サーバーで提供することが多いです。 ですので、 配布元の URL が分かれば web ブラウザで取 得することができます。
また、 Iceweasel*11 は、 CRL の URL へアクセスすると、 自動的にローカルで管理している失効リストに追加しようとします。
SSL のページにアクセスして、 表示されたページの上で右クリックすると、 メニューが表示されます。 ここで [ページの情報の 表示] を選択し、 [セキュリティ ] タブを選択し、 [表示] を選択します。 すると、 別窓に証明書ビューアが立ち上がります。 ここ で [詳細] タブを選択します。 [証明書のフィールド]-[CRL Distribution Point ] を選ぶと、 CRL がどこで配布されているかが 表 示 さ れ ま す 。
のような情報がか書かれていますので、 この URL をアドレスバーに張り付けてアクセスします。 すると、 「証明書失効リスト (CRL) が正常に取得・更新されました」 というポップアップウィンドウが表示され、 さらにその下に「この CRL の自動更新 は無効になっています。 自動更新を有効にしますか？」 あるいは「この CRL の自動更新は有効になっています。 自動 更新の設定を表示しますか？」 と表示されます。 今後も自動更新したい場合は、 自動更新を有効にしておき ます。
[設定 (N)]—[詳細]—[暗号化]—[失効リスト (R)] で、 CRL の管理画面が出てきます。
|
|
世界中の CRL は集中管理されていませんし、 配布方法もまちまちです。 また、 認証局の web ページ を見ても、 その認証局が配布している CRL を分かり易くまとめていることは少ないですし、 CRL の ファイルへのリンクは示さずに、 Serial Number で検索するフォームを設置している認証局もありま す*12 。 結 局、 その認証局が配布している証明書の cRLDistributionPoints を見ないと CRL のありかが分からないことも珍しくありま せん。
しかし、 更に真面目に調べ出すと、 とてもたくさんの CRL が公開されていることが分かります。
このような状況なので、 SSL の通信に先立って CRL を網羅的に入手することは容易なことではありません。 表1 に、 いくつかの認証局の CRL の一覧ページの URL を、 表 2 に個別の CRL の URL を載せておき ます。
CRL のかわりに、 Online Certificate Status Protocol[6] (略して OCSP) を使って、 SSL or TLS の通信時にリアルタイムで 証明書の有効性を問い合わせる方法もあります。 Iceweasel では、 [設定 (N)]—[詳細]—[暗号化]—[検証 (V)] で、 OCSP の設定 画面が出てきます。 ここには、
という設定があります。 業界再大手の Verisign の発行するサーバー証明書には Authority Information Access に問い合わせの URL が載っているようですが、 認証局によって載せていないこともあります。
一般に、 認証局が発行したサーバー証明書を信頼することと、 CRL や OCSP を利用してサーバー証明書の状態を確認する際 には、 認証局の責任の範囲に対する何らかの法的な合意を求められると思われますが、 そのことを web サイトに掲載している 認証局 [12]もあれば、 そうでない認証局もあります。
例えば、 日本の業界最大手の日本ベリサインが発行するサーバー証明書に対する CRL と OCSP を利用する際には、 事前に 「日本ベリサイン依拠当事者規約[9]」 に合意することが求められています。
また、 その文書も、 依拠当事者規約[11]やその英語名称の Relying Party Agreement[10][13]である認証局もあれば、 CPS[12][14]である認証局もあります。
SSL のサーバー証明書について、 簡単に解説しました。 特に、 サーバー証明書に含まれる公開鍵が漏洩したり脆弱であること が明らかになった場合に採られる証明書の失効の手続きの仕組みについて解説しました。
AddTrust 社の配布する CRL である http://www.addtrust.com/crl/publicroot.crl を取得して表示する 場合: