Google trillianとCertificate Transparency
Google Security Blog よりデータの検証可能性に関するシステムについてブログポストが投稿された。
Merkle tree形式でappend-onlyにログを記録するソフトウェア
以下のようなInclusion proofやConsistency proofを利用可能
https://gyazo.com/edcf3c18464bcca258f4b23ce6934909
APIスキーマ
DBスキーマ
Google trillianを用いたアプリケーション例
Certificate Transparency
Go Checksum Database
go.sumファイルのソースコードチェックサム
特定のversionでコードへの変更が加えられていないことを検証可能に
サプライチェーン攻撃対策に向けた取り組み
Certificate Transparency (CT)
モチベーション:以下のようなCAに対する攻撃などにより不正な証明書が発行されていることを検証可能に
CAが意図しない証明書が誤発行されていないか(秘密鍵の不正アクセスなど)
ドメイン管理者にとって自ドメインの証明書が勝手に発行されていないか
--> 証明書発行時に、パブリックチェーン的に改ざん不可能で誰もが参照可能なプラットフォームにログとして残すことを強制すれば誰もが監視できる
ドメインオーナーは自身のドメインに紐づく証明書が不正に発行されていないかTrillian運用サーバー(ログサーバー)を監視
ブラウザはアクセスしているウェブサイトの証明書がTrillianにログとして記録されていることを検証
ログデータ自体はそれぞれの運用主体に分散しているのでCAは複数のログサーバに証明書ログを送信し、ブラウザは複数のSCT(timestamp)を検証することで、単一のログサーバーのトラストを避けるなど。
2015年~, chrome対応
Let's EncryptによるCT Log運用例
ChromeからのCT status
https://gyazo.com/61c25859efd8fdd80b3a23fde68bae36
フロー
PKIの仕組みでドメインオーナーからCAヘ証明書発行リクエスト
CAがprecertificateを発行しログへ送信(複数ログサーバーに送信してもok)
ログがsinged certificate timestamp(SCT)をつける ログサーバーがtrillianを運用
定期的に全ての新しい証明書をappendしてmerkle subtreeを生成し、それと元々のtreeから新しいrootを算出
MMD(24h)以内にCAにSCTとcommitment(署名ルート)をレスポンス
CAはdomain ownerに証明書を送信
ブラウザ
safari/chromeは2つ以上のSCTを要求
ドメインオーナーはモニタを通して自身のドメインの証明書が新しくログに登録されたことの通知を受けることができる
あくまで検証可能性でしかないので、ログサーバーからinclusion/consistency proofにより特定のドメイン証明書の探索を行う
https://gyazo.com/1b3d0ca201d9327fe9334bdb6c16dff8
References