1. Certificate Transparency

Certificate Transparency

  • このエントリーをはてなブックマークに追加

Certificate Transparencyとはなにか

過去に当ブログでDANE, CAA, Certificate Pinningと、SSL/TLSにおける電子証明書の信頼性を高める新たな技術をご紹介してきましたが、今回は同じ目的で考案されたCertificate Transparency(CT)を取り上げたいと思います。

CTはCertificate Pinningと同様Googleによって考案され、2013年にRFC6962としてRFC化されました。
基本的な考え方はCertificate Pinningと同じ「ホワイトリスティング」です。正規に発行された証明書の情報を「Log」として登録し、TLSクライアントがサーバに接続する際にこの「Log」を参照することで証明書の正当性を検証できるようにしようというものです。

CTの特徴として、以下のようなポイントがあります。

  • Logへの証明書登録をOpenにし、誰でも証明書発行あるいは取得後すぐに登録が可能なようにしている
  • マークル木(Merkle tree)を使い、誰でもLogの完全性を簡単に検証できるようにしている
  • 認証局が、自局から意図せず発行された証明書がLogに登録されていないかモニターすることができる

なお、CTの立場はあくまでも証明書の信頼性を担保するための付加的な技術であり、証明書のパス検証やステータス確認については従来の技術に依存するということになっています。

実はChromeにはすでにサーバ証明書がCTに準拠している(=Logに登録されている)かどうかを表示する機能が実装されています。
CTのLogに登録されていない証明書の情報を表示すると、右図のように「公開監査記録がありません」と表示されます。
Logに登録されている証明書であれば、登録されている情報を見ることができます。

図1 ChromeにおけるCT情報の表示

CTの目的と構成要素

CTの公式ページでは、その目的は以下の3つであるとしています。

  • ドメイン所有者の証明が明確にされない状態で、CAがそのドメインに対して証明書を発行してしまうことを不可能(あるいは限りなく困難)にする
  • あらゆるドメイン所有者やCAが証明書の誤発行や不正発行を検知するためのオープンな監査とモニタリングのシステムを提供する
  • (可能な限り多くの)ユーザを、誤発行や不正発行された証明書による詐欺から守る

不正発行や誤発行された証明書の検知を正確に素早く行うことを可能とすることで、その証明書による被害を最小限にすることを目指しているのです。

CTを構成するコンポーネントは以下の3つです。

Log Ceritificate logは、「暗号的に担保され、誰でも監査可能で、追記のみが可能な証明書のレコードを維持管理するためのシンプルなネットワークサービス」です。ログはハッシュ木(Merkle tree)を使って、その完全性を誰もが検証できるようになっています。
Monitors Monitor(モニター)とは、「定期的にすべてのログサーバにコンタクトし、不審な証明書がないかどうかを監視する公的に運用されたサーバ」です。
例えば、認証局がMonitorとして定期的に、ログサーバに格納されている自認証局が発行したとされている証明書の情報にアクセスすることによって、意図しない証明書(=その認証局から不正に発行された証明書)の情報が格納されていないかどうかを確認することができます。
Auditors Auditorとは、「主に2つの機能を持つ軽量なソフトウェアコンポーネントである」とされています。2つの機能とは、「Logが正しく動作しており、暗号的に整合性が担保されていることを検証する」機能と、「特定の証明書がLogに記録されているかどうかを検証する」機能です。
RFC6962では、AuditorはTLSクライアントに統合されるであろうと書かれています。
ブラウザがTLSのクライアントとして動作する際、Auditorを使ってサーバ側の証明書が正常にLogに格納されているかを検証することによって、いわゆる「怪しい証明書」が使われているサイトかどうかを確認することができます。

Logには誰でも証明書の情報をPOSTできることになっていますが、主に想定されているのは認証局とWebサーバの管理者からのPOSTです。
Logに証明書をPOSTすると、Logからはsigned certificate timestamp(SCT)と呼ばれるデータが返されます。SCTは、maximum merge delay (MMD)と呼ばれる時間内にLogにPOSTされた証明書データが格納されることを保証するデータです。証明書の信頼者(Relying Party)であるブラウザなどのTLSクライアントは、サーバ側の証明書と一緒にデリバリされるSCTを使って、Logの中にその証明書のデータが登録されているかどうかを確認することができます。

SCTのデリバリ方法

上記で述べたように、TLSクライアントはSCTを入手することで、その証明書がLogに登録されているかを検査することができるようになります。
TLSクライアントへのSCTのデリバリの方法としては、以下の3種類が想定されています。

(1) 証明書の拡張領域(Extantion)にSCTを格納する

証明書にSCTを格納にてデリバリ
証明書にSCTを格納にてデリバリ

認証局が証明書を発行する際に証明書をLogに登録し、Logから返されたSCTを証明書の拡張領域に格納して証明書を発行します。
お気づきの方もいらっしゃるかもしれませんが、上記を言葉通りに受け止めると、証明書を発行する前に証明書をLogに登録しなければならなくなってしまいます。
このため、RFC6962では本物の証明書(便宜上「本番証明書」と呼びます)を発行する前に「事前証明書(precertificate)」を発行しそれをLogに登録しろと定義されています。
事前証明書とは、本番証明書と同じシリアル番号、サブジェクトDN、有効期間を持ち、同じ署名アルゴリズムで署名された証明書です。厳密には異なりますが、本番証明書からSCTが除かれたもの、と考えるとわかりやすいかもしれません。
RFCでは事前証明書は「本番証明書を発行する認証局が発行した証明書を持つ認証局(つまり本番証明書を発行するCAのサブCA)」あるいは「本番証明書を発行する認証局」から発行されなければならないとしています。 このことがちょっとした議論を呼んでいるのですが、それについては下記の囲みの中で触れたいと思います。

TLSクライアントは、サーバから証明書を受け取ると、通常の検証手順に加えてAuditorを使ってその証明書がLogに格納されているかどうか確認します。SCTは証明書の中に格納されていますので、そのほかに特別な情報は必要ありません。

実は上記の事前証明書についての要件が、3つのポイントについてちょっとした議論を呼びました。
1つ目のポイントは、エンドユーザ証明書を発行する認証局のサブCAとして事前証明書を発行する認証局を構築することの是非です。
通常エンドユーザ証明書を発行する認証局の証明書は「基本制約(Basic Constrains) 」という拡張領域を使用して、その下位にサブCAを作ることを制限しています。これはエンドユーザ証明書として発行した証明書を使用してサブCAのようにふるまい、勝手に証明書を発行されてしまうことを制限する意図があります。
事前証明書発行認証局をサブCAとして構築すると、上記の制約に反することとなってしまいます。
これについてRFC6962では「the log may relax standard validation rules to allow this」つまり、標準的なものよりも検証ルールを緩和するから大丈夫、と言っています。
2つ目のポイントは、事前証明書が流通していまい、本番証明書として使用される危険性がないかということです。この点についてRFCではクリティカル属性を持つ特別な「poison extension」を事前証明書の拡張領域に格納することにより、この拡張領域を解釈できないクライアントが事前証明書を信頼できないようにする、と言っています。
3つ目のポイントは、本番証明書を発行する認証局から事前証明書を発行した場合、RFC5280違反にならないか、ということです。
RFC5280は基本的な証明書と失効リストのプロファイル(格納項目)を定義したRFCです。この中で、同一認証局から発行される証明書はユニークなシリアル番号を持たなければならないとされています。
事前証明書と本番証明書が同じシリアル番号を持ち、同じ認証局から発行されるとこの規定に違反しないか、ということです。
これに対してGoogleは、開発者の質問に答える形で「本番証明書と事前証明書は同じサブジェクトDNを持っている(ので違う証明書ではない)」「事前証明書はpoison extensionによって有効な証明書として認識されない」という2点を挙げて、問題ないと説明しています。

上記いずれのポイントも、今までのPKIの実装からするとちょっと本筋とは外れた形になっていて、今までPKIの実装に携わってきた人たちからするとちょっと違和感がある部分でしょう。

(2) TLSのエクステンションにSCTを格納する

TLSエクステンションでSCTをデリバリ
TLSエクステンションでSCTをデリバリ

もう一つの選択肢は、TLSのサーバ側でハンドシェイク時にTLSのエクステンションとしてSCTを格納してクライアントのデリバリする方法です。
この方法をとる場合、Logへの格納をリクエストするのは認証局ではなく、Webサーバの管理者です。
証明書が発行されて手元に届いたら、Webサーバ管理者はLogへ証明書情報の格納をリクエストします。Logから返されたSCTを保管し、signed_certificate_timestampという拡張としてTLSハンドシェイクの際にクライアントに渡します。クライアントはハンドシェイクで渡された証明書とSCTからAuditorを使ってその証明書がLogに格納されているかどうか確認します。

(3) OCSPステイプリングを利用する

証明書にSCTを格納にてデリバリ
OCSPステイプリングでSCTをデリバリ

最後の選択肢は、OCSPステイプリングを使う方法です。
OCSPステイプリングというのは、OCSPの拡張の一つです。
通常TLSクライアントがWebサーバの証明書のステータスをOCSPによって確認する場合、TLSクライアントが自らOCSPサーバ(レスポンダ)に問い合わせを行います。OCSPステイプリングでは、TLSクライアントの代わりにWebサーバが自らの証明書のステータスをOCSPレスポンダに問い合わせ、その結果(OCSPレスポンス)をレスポンスの有効期間中保持します。クライアントから接続される際、TLSハンドシェイクのやり取りの中にこのOCSPレスポンスを「ホチキス止め(Stapling)」するようにしてクライアントに送ることによって、クライアントは自らがOCSPレスポンダに問い合わせることなく、Webサーバ証明書の有効性を確認することができます。

前置きが長くなってしまいましたが(機会があればOCSPステイプリングを含む失効情報のハンドリング方法についても改めて書いてみたいと思います。)、このホチキス止めされるOCSPレスポンスの中にSCTを格納してデリバリしようというのが最後の選択肢です。
認証局は証明書を発行すると同時に、その証明書情報の格納をLogにリクエストしてSCTを取得します。(1)の場合と違い、証明書にはSCTを格納しないので、Logへの格納要求は証明書発行後でよく、取得したSCTは証明書と紐づけられる形で認証局が保持しておきます。
Webサーバから、そのサーバの証明書のステータスについての問い合わせが認証局のOCSPレスポンダに送られると、認証局はステータスを示すOCSPレスポンスの中に該当するSCTを埋め込んで返します。Webサーバはそのレスポンスを保持しておきます。
このSCTが埋め込まれたOCSPレスポンスがTLSハンドシェイクの際にクライアントに送られ、クライアントはLogにその証明書情報が格納されているかどうかを確認することができるようになります。
認証局にとっては(1)のように証明書発行のロジックを複雑にする必要がないというメリットがある一方で、Webサーバ管理者は必ずOCSPステイプリングを有効にしなければならないというデメリットもあります。

さて、CTではどうしてOCSPステイプリングだけでSCTのデリバリをサポートするのでしょうか。OCSPレスポンスにSCTを埋め込むのであれば、なぜ通常のクライアントが問い合わせを行うOCSPではダメなのでしょう? 大きな要因として、Googleが通常のOCSPというプロトコルについてあまり良いものだと考えていないことが挙げられます。
Webページの表示までの時間が認証局の運用するOCSPレスポンダのパフォーマンスに大きく影響されること、また、OCSPのリクエストをトラックすることによってどのクライアントがどのようなWebページにアクセスしたのかをトレースすることができ、プライバシー上問題があるということなどから、GoogleはOCSPを使うべきではないとの考え方に立っており、実際にChromeの初期設定ではOCSPが無効化されています。
OCSPステイプリングであればこのようなパフォーマンスやプライバシーに関する懸念がないため、許容できると考えているのでしょう。

上記3点を比較した場合、(2)と(3)はWebサーバ管理者による設定が必要で、結果的にWebサーバごとに対応にばらつきが出る可能性があります。今のところの現実解としては、認証局が(1)に対応するしかないであろうというのが、各認証局及びGoogleの考えているところです。

ChromeのCT対応のロードマップ

Googleはすでに、ChromeにおけるCTへの対応のロードマップについて以下のようにアナウンスしています。

  • 2015年1月を超える有効期限を持つ(発行済みも含めた)すべてのEV証明書の情報は、少なくとも1つのLogに登録されなければならない
  • Googleは2015年1月1日に、発行済みのEV証明書でSCTが組み込まれていないもののホワイトリストを作成する
    (筆者注:つまりこの日以降に発行されるEV証明書についてはすべてSCTを取得しなければならないことを意味している)
  • 2015年2月1日をもって、Desktop版のChromeは、上記ホワイトリストに登録されておらず、かつCTに適応していないEV証明書についてはEV証明書であることの表示をしない。モバイル版ChromeについてはCTに適応していないEV証明書について、EV証明書であることの表示をしない。

上記を受けて、弊社を含めた各認証局は、現在EV証明書のCT準拠のための対応を行っています。

GlobalSignのCT対応について

GlobalSignでは、2014年末までにEVの証明書についてCTへの対応を完了する予定です。
また、その他の証明書についても、2015年の上半期までに対応を完了する予定です。

参考資料:
Certificate Transparency
RFC6962

  • このエントリーをはてなブックマークに追加

この記事を書きました

浅野 昌和

浅野 昌和
所属:GMOグローバルサイン グループ技術開発本部
>>浅野 昌和の記事一覧