Downloaded 60 times
![© 2015 Kenji Urushima All rights reserved.
Markle Audit Path(マークル監査パス)とは
o
nm
i j k l
a b c d e
d0 d1 d2 d3 d4
リーフデータ
(=証明書チェイン)
f
d5
g
d6
h
d7
Pathとはリーフデータが木に含
まれていることを証明するため
のノードハッシュ値のリスト
例えばリーフd3が含まれ
ることを証明したいとする
とき、Pathは[c, i, n]とな
り、[c, i, n]とd3さえあれ
ば下から順にルートハッ
シュを計算できる。
① d3からdを計算できる
② c、dからj
③ i、jからm
④ m、nからルートo
別途与えられるルートハッ
シュと一致すれば、d3は
木に含まれる証明となる。](https://image.slidesharecdn.com/ct201506120941-150623143728-lva1-app6891/85/Certificate-Transparency-SSL-23-320.jpg)
![© 2015 Kenji Urushima All rights reserved.
(参考)ChromiumのCT関連ソースコード
出典：https://chromium.googlesource.com/
chromium/src/+/master/net/cert
ct_*.[ch]
• 6つのサーバー用のECC公開鍵などある
• 検証はあまりまともに実装されてなさそう](https://image.slidesharecdn.com/ct201506120941-150623143728-lva1-app6891/85/Certificate-Transparency-SSL-39-320.jpg)
Uploaded byKenji Urushima
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
2015年6月12日に有志で行なったCertificate Transparencyに関する勉強会の資料です。
Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論
- 1. © 2015 KenjiUrushima All rights reserved. Certificate Transparencyによる SSLサーバー証明書公開監査情報と その課題の議論 (資料公開版) Certificate Transparency有志勉強会 協賛：すみだセキュリティ勉強会/JNSA PKI相互運用WG 於：トレンドマイクロ株式会社(新宿)本社会議室 2015年6月12日(金) JNSA PKI相互運用WG 漆嶌賢二
- 2. © 2015 KenjiUrushima All rights reserved. • Certificate Transparency(CT)とは • Google ChromeでのCTの表示 • CTの構造 • CTの課題整理の議論 今日のアジェンダ
- 3.
- 4.
- 5.
- 6. Certificate Transparencyとは(2) ü 2011年、DigiCertやComodoなどで google.comドメイン不正証明書が 発行されイラクの通信が盗聴 その対策の一環として提案。 ü 2011年のGoogleの人の論文に基づく ü 実験RFC 6962になった(準拠不要?) ü Google Chromeのみが実験に対応 ü Chromeは1月〜EV証明書の必須要件に ü DigiCert, GlobalSignが先行対応 ü 他の海外認証ベンダも対応中 © 2015 Kenji Urushima All rights reserved.
- 7.
- 8. Google ChromeではEV証明書にはCT必須 参考： Improve the Security of EV Certificates (19 Mar 2014 by Ben Laurie of Google) https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo0ODhjNGRlOTIyMzYwNTcz • 利用者、サーバー管理者は何もしなくてよい。 • 有効期限が2015年1月1日を超える証明書 はCTがログサーバーに登録されていなければ ならない。 • 発行済みのEV証明書は2015年1月時点で GoogleがCTログサーバーに(全て)登録 • 2015年2月1日以降、CTの無いEV証明書 はEV表示をしない。 © 2015 Kenji Urushima All rights reserved.
- 9. 目に見える Certificate Transparencyとは (Chrome、DigiCert等が対応) © 2015Kenji Urushima All rights reserved.
- 10. CT対応じゃないサイト(=ほとんどのサイト) 例の出典 https://jp-businessstore.symantec.com/qq2/symantec/index.asp 鍵を右クリック 「公開監査記録がない」 ＝ Certificate Transparency 非対応のサイト ©2015 Kenji Urushima All rights reserved.
- 11. CT対応のサイト(=GlobalSign or DigiCert) 例の出典 https://www.digicert.com/鍵を右クリック 「公開監査が可能」 ＝ Certificate Transparency 対応のサイト © 2015 Kenji Urushima All rights reserved.
- 12. CT対応のサイト(=GlobalSign or DigiCert) Signed Certificate Timestamp (SCT) (RFC 3161とは無関係の CTログエントリに対する署名情報) DigiCert、GlobalSignには 見慣れない拡張が！！ (embeddedSCT) 「SCTを証明書に入れる」とい うことは「証明書発行の前に SCTが必要」という事© 2015 Kenji Urushima All rights reserved.
- 13. SCTの入った証明書の発行 プレ証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 1.3.6.1.4.1.11129..2.4.3= ASN.1 NULL ・プレ用中間CAの署名 予定の証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 ・中間CAの署名 シリアルや有効期限を含め事前に発行予定の証明 書データ(TBSCertificate)が必須だが、証明書発 行前にシリアルを含めそのような情報が認証局に あることは問題ではないか。 ルート認証局 発行する証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 embedSCT拡張 =SCT ・中間CAの署名 中間認証局 プレ用認証局 拡張鍵使用目的= CT(1.3.6.1.4.1.11129.2.4.4) © 2015 Kenji Urushima All rights reserved. ログサーバー 認証局 ウェブサイト ウェブブラウザ ①プレ証明書 ②プレ証明書 (SCT付) ③サーバー証明書 (SCT付) ④SSL/TLS通信 (SCT付証明書)
- 14. 世界に配置された CTログサーバー(リポジトリ) © 2015 KenjiUrushima All rights reserved.
- 15. © 2015 KenjiUrushima All rights reserved. ログサーバー(2015年2月当時) 2015年2月頃は Googleは世界2拠点でログサーバーをテスト運用していた Googleは3拠点を計画、他の組織がログサーバーを提供してもよいと Googleは言っているが当時は他になかった https://ct.googleapis.com/pilot/ https://ct.googleapis.com/aviator/ ルートCA数：352 SSL証明書数：660万枚 日次増分：約8千枚 ルートCA数：352 SSL証明書数：660万枚 日次増分：約8千枚 SSLPulse調査対象15万 枚を遥かに凌ぐ。当然EV 証明書以外も含まれる。
- 16. © 2015 KenjiUrushima All rights reserved. ログサーバー(2015年6月現在：6つ) ChromiumのCTサイトでCTログサーバー一覧を公開 Google以外もある 7,676,296 6,938,450 82,058 4,958,583 10,812 4,341 出典：https://www.chromium.org/Home/chromium-security/certificate-transparency Chromiumのソースコードに掲載されている https://chromium.googlesource.com/chromium/src/+/master/net/cert/ct_known_logs_static.h
- 17. © 2015 KenjiUrushima All rights reserved. Google Pilot CT Logエントリ数の推移(2015年2月〜6月) 現在、777万枚のSSL証明書 1.1万枚/日でリニアに増加 ミシガン大のZmapによる全IPアドレ ス調査などと比較して圧倒的に効率的 にSSLサーバー証明書が回収可能 20515年3月 4月 5月 6月
- 18. CTログの構成要素 © 2015 KenjiUrushima All rights reserved.
- 19. © 2015 KenjiUrushima All rights reserved. CTログの構成要素 SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ a1.jpサーバ証明書 中間CA証明書 ルートCA証明書 リーフデータ(=証明書チェイン) or ログエントリ Signed Certificate TimeStamp (SCT) ID番号 ログ名/ID 監査時刻(登録時刻) SHA256wECDSA署名値 署名 Signed Tree Head タイプ 生成日時 ツリーのサイズ(リーフ数) ルートのSHA256ハッシュ値 SHA256wECDSA署名値 Markle Hash 下位ノードに対するハッシュ値 署名
- 20. © 2015 KenjiUrushima All rights reserved. 追記のみを許すと主張しているログデータ全体の構造 (実際には技術的に 「追記のみ」を保証されない) SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ a1.jpサーバ証明書 中間CA証明書 ルートCA証明書 特徴 ① ハッシュ計算とマークル木により 追加だけしかできない(append only) ② ハッシュ計算とマークル木により 途中改竄はできない ③ Bitcoinのマークル木と似ている ④ ログエントリとは証明書チェインの事 ⑤ 一部のデータはGoogleのECC鍵で 署名される リーフ データ (=証明書 チェイン) Signed Certificate TimeStamp (SCT) ID番号 ログ名/ID 監査時刻(登録時刻) SHA256wECDSA署名値 SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ SHA256 ハッシュ
- 21. CTのマークルハッシュ木 © 2015 KenjiUrushima All rights reserved.
- 22. © 2015 KenjiUrushima All rights reserved. マークル木の成長(証明書 が登録されると木が成長する) i e a d1 b c d2 リーフ データ (=証明書 チェイン) Signed Certificate TimeStamp (SCT) d d3 f d4 m k h d5 j d6 o l d7 n d8 g 登録のアニメーション STH STH STH STH
- 23. © 2015 KenjiUrushima All rights reserved. Markle Audit Path(マークル監査パス)とは o nm i j k l a b c d e d0 d1 d2 d3 d4 リーフデータ (=証明書チェイン) f d5 g d6 h d7 Pathとはリーフデータが木に含 まれていることを証明するため のノードハッシュ値のリスト 例えばリーフd3が含まれ ることを証明したいとする とき、Pathは[c, i, n]とな り、[c, i, n]とd3さえあれ ば下から順にルートハッ シュを計算できる。 ① d3からdを計算できる ② c、dからj ③ i、jからm ④ m、nからルートo 別途与えられるルートハッ シュと一致すれば、d3は 木に含まれる証明となる。
- 24. © 2015 KenjiUrushima All rights reserved. Markle Tree Hash(MTH)の計算方法 g fe a b c d d0 d1 d2 d3 EWEL97g… ①子供が2ついるノード ②子供にリーフを1つ持つ 末端ノード この２つでハッシュ値の計 算方法が違う wDblrkB… /NeD2RV… h6Wo6zv… /6/EpTp…6eIbVFV… c = MTH({d(2)}) = SHA-256(0x00 || d2_leaf_input) e = SHA-256(0x01 || a || b)
- 25. © 2015 KenjiUrushima All rights reserved. TLSサーバーからクライアントへSCTを渡す3つの方法(参考) ①SSLサーバー証明書の embedSCT拡張に含める (最も一般的？) ②TLSハンドシェイクの signed_certificate_timest amp型TLS拡張に含める (対応実装は無い?) ③TLSハンドシェイクの status型TLS拡張のOCSP staplingに含める (対応実 装は無い?) ほぼこの方式 しか使わない 対応実装 無し 対応実装 無し
- 26. www.digicert.com - embeddedSCT X.509v3拡張value OCTET STRING 00 EF 00 76 00 A4 B9 09 90 B4 18 58 14 87 BB 13 A2 CC 67 70 0A 3C 35 98 04 F9 1B DF B8 E3 77 CD 0E C8 0D DC 10 00 00 01 49 10 FA BD 89 00 00 04 03 00 47 30 45 02 20 66 D7 67 79 F4 AA D3 B8 C6 9F 03 01 BF CD EC 83 36 D4 C8 4F C1 45 D5 D9 FD 16 54 AD 6F 75 22 A1 02 21 00 B8 95 F1 43 03 DF A4 11 04 3C 24 13 D8 81 69 24 9D D2 04 96 4D AD 53 3D 9D 6A 24 14 32 4D CC 91 00 75 00 68 F6 98 F8 1F 64 82 BE 3A 8C EE B9 28 1D 4C FC 71 51 5D 67 93 D4 44 D1 0A 67 AC BB 4F 4F FB C4 00 00 01 49 10 FA BD 79 00 00 04 03 00 46 30 44 02 20 11 34 9A 59 2C 9D 3B D3 8B 9A 58 18 37 24 55 F3 9D 0E CA 98 96 6B 8F C7 A2 E4 D8 BF 00 CE 40 FD 02 20 11 24 11 AB 62 7F B2 88 F0 6D 70 C0 FD A0 65 B5 B6 03 46 1F 10 30 ED F5 6D 7E 89 7B BA 20 32 64 Google Pilot log Name Google Pilot log ID Google Aviator log Name Google Aviator log ID Google Pilot log Sig Google Aviator log Sig 2014年10月15日水曜日 8:25:08 JST 2014年10月15日水曜日 8:25:08 JST 証明書に組込まれたSignedCertificateTimestampの構造 なぜ、SCT等一連のデータ構造はASN.1になっていた方が取扱いが容易だった © 2015 Kenji Urushima All rights reserved.
- 27. © 2015 KenjiUrushima All rights reserved. 公開ログサーバーへの RESTAPIインタフェース 基本的にRESTAPIで公開サーバーにアクセスできる (例) POST https://ct.googleapis.com/ct/v1/コマンド クライアント 証明書チェインの追加 POST add-chain 発行前証明書のチェインの追加 POST add-pre-chain 署名木ヘッドの取得 GET get-sth 署名木ヘッドのマークル一貫性証明の取得 GET get-sth-consistency リーフハッシュによるマークル監査証明の取得 GET get-proof-by-hash エントリ群の取得 GET get-entries 受理されたルート証明書群の取得 GET get-roots エントリとマークル監査証明の取得 GET get-entry-and-proof REST→ JSON←
- 28. © 2015 KenjiUrushima All rights reserved. 本家 www.certificate-transparency.org サイト ① CTの解説 ② ツールのソースコード ③ 仕様(RFC 6962) ④ プレゼン資料
- 29. © 2015 KenjiUrushima All rights reserved. GoogleのAdam Langley氏のImperialVioletブログの Certificate Transparencyに関する記事 ① CTの解説 ② Go言語によるサンプル プログラム https://www.imperialviolet.org/2011/11/29/certtransparency.html https://www.imperialviolet.org/2012/11/06/certtrans.html https://www.imperialviolet.org/2013/08/01/ctpilot.html
- 30. Certificate Transparencyの 課題整理(議論) © 2015Kenji Urushima All rights reserved. ① そもそも信頼できる監査情報なのか? ② 仕組み/データとして信頼できるのか? ③ プライバシー懸念があるのでは？
- 31. © 2015 KenjiUrushima All rights reserved. CTで保持されている公開監査情報は意味があるのか？ 持っている情報は ・証明書チェーン ・登録時刻 のみ CTログ サーバー 悪意のある者がCTを使うことがある • 不正発行した証明書を登録することができる • 正しく発行されたものと区別がつかない 結局、CTログにあるから健全とは限らない • ログサーバー自体が監査を受けていない • どのようなポリシーでログ登録されるか不明 • 健全なログかどうかわからない • 不正発行された証明書が登録されているかもれない • CT導入前に発行され、今CTに登録されている証明書 は監査の網をすりぬけた証明書 • CT管理者はいつでもCTログDBの改ざんが可能(後述)
- 32. © 2015 KenjiUrushima All rights reserved. ② CTの仕組みやデータが信頼できるものか？ ビットコインのブロックチェイン、マークル木を真似て作って いるようだが「追記のみ」のデータベースに「全くなっていない」 g e a b c d0 d1 d2 CTは追加のみのデータベースだと主張するが・・・ g fe a b c d d0 d1 d2 d3 g e a b c d0 d1 d2 d1を改ざんするなら b, e, gを再計算し署名 d3を追加するなら d, f, gを計算し署名 CT管理者のECC秘密鍵があれ ば、ハッシュと署名の再計算は 可能。CT管理者は改ざんし放 題で事実上のビッグブラザーに なっている。 改ざん 追加
- 33. © 2015 KenjiUrushima All rights reserved. ③ CTにはプライバシーの懸念があるのでは？ HTTPSウェブサイト aaa.com CTログサーバー ①TLS アクセス ②aaa.comの SCT付 証明書 ③aaa.comが CTログにあるか、 正しいか、検証 CTサーバー管理者は今、CT に登録されている数百万のサ イトに対する全世界からのア クセス情報を、公開監査ログ 検証の名目で収集できる可能 性がある。 本来、利用者とaaa.com しか知り得なかった情報 OCSP staplingによるプライバシー懸念と全く同種の問題がCTでも起きる
- 34. © 2015 KenjiUrushima All rights reserved. ④ プレ証明書の運用を入れることで 認証局は高リスクに プレ証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 1.3.6.1.4.1.11129..2.4.3= ASN.1 NULL ・プレ用中間CAの署名 予定の証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 ・中間CAの署名 ルート認証局 発行する証明書 ・シリアル ・発行者 ・有効期間 ・主体者 ・拡張領域 CRLDP,SAN等 embedSCT拡張 =SCT ・中間CAの署名 中間認証局 プレ用認証局 拡張鍵使用目的= CT(1.3.6.1.4.1.11129.2.4.4) • 認証局を追加することで認証 局は運用コスト大幅増 • 事前にシリアル、有効期間な どが同じ証明書を発行するこ とは、CAの監査的にも良くな い。 • プレ認証局の運用監査はどう するのか？(コスト増) • プレ認証局から「不正証明 書」が発行されるリスクが非 常に高まる。 • パス検証で「未知のクリティ カル拡張」を正しく扱えない ブラウザは、不正な証明書を 受け入れてしまう可能性があ る。 CTのメリットはほぼ無いのに 「認証局の不正を生みやすい高 コストな環境」を作っている。
- 35. © 2015 KenjiUrushima All rights reserved. ⑤ (追記)CTに関する最新の動向(2016.06.24) • RFC 6962bis – Certificate Transparencyが準備され始めていている • https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ • CT運用の十分な実績、実装ができたためExperimentalから Standard Trackに移すことを画策している • Standard Trackになったら、すべてのブラウザ、すべてのサーバー がこれに対応していく方向になる • 次のiOS9でCertificate Transparencyをサポートすると公表した http://gizmodo.com/one-big-list-of-the-new-privacy-and-security-features-i-1710332864 https://twitter.com/FredericJacobs/status/608003625617604608 • Chromeだけでなく、他のブラウザも対応し始めた さらに、とてもまずい状況になった
- 36. © 2015 KenjiUrushima All rights reserved. (参考) Chromium Forumでの議論 Google Chromium開発のSecurity/ Crypto TeamのRyan Sleeviのフォー ラム投稿 • 同じChroiumベースのOperaからの CTに対する批判を受けたもの • 「Googleに悪意が無いこと」を9 ページに渡る長文で弁明したが、論 点がはっきりせず、健全に運用され ていること、信頼できる仕組みであ ることは証明されていないようだ。 https://groups.google.com/a/chromium.org/forum/ #!msg/ct-policy/Udh1ddi1MrY/Ij-p0o1mP5gJ
- 37. © 2015 KenjiUrushima All rights reserved. 不完全なChromiumのCT Logの運用ポリシー Google Chromiumプロジェクトには CTログのポリシーが定められている が • 認証局はPwCなど必要な外部 運用監査をしているが • CTについては何もシステム監査 するつもりは無さそう • 精神論で「完全性を維持」と言って いるだけで、誰もその運用を担保で きない。 • 正しく運用されていた事を示す方法 がない。 • CTのEC鍵管理も不明確 https://www.chromium.org/Home/chromium- security/certificate-transparency/log-policy
- 38. © 2015 KenjiUrushima All rights reserved. (参考)IETFのCT wikiページ 出典：http://trac.tools.ietf.org/wg/trans/trac/wiki 今は大した情報はないが今後に期待？？？ (CT検索系のオンラインツールが整備されそう)
- 39. © 2015 KenjiUrushima All rights reserved. (参考)ChromiumのCT関連ソースコード 出典：https://chromium.googlesource.com/ chromium/src/+/master/net/cert ct_*.[ch] • 6つのサーバー用のECC公開鍵などある • 検証はあまりまともに実装されてなさそう
- 40. © 2015 KenjiUrushima All rights reserved. 主張 Certificate Transparencyは仕組 み的にも、運用的にも「証明書の有 効性」などの何かを証明できるよう な仕組みにはなっていない。そのよ うな仕組みを信頼の起点とするのは、 非常に問題があるのではないか。
- 41.
- 42. (参考)Certificate Transparencyの課題整理メモ ① そもそも何を監査しているのか不明 i. 保管しているのは「ただの」証明書チェーンと登録時刻 ii. 正当な発行によるものかそうでないかは不明 iii. 誰でもログサーバーに登録でき不正なもの登録可？ iv. 結局CTにおいてあるもので監査できるのは何なのか？ v. 誤った登録があった際に、これを取り消す仕組みがない。 vi. 複数登録があった際に、どちらが正しいのかを知る術がな い。 vii. そもそも、証明書の失効情報だけで充分なのでは？ ② CTの運用監査は誰がするのか？ i. ログサーバーに使う楕円秘密鍵管理は適切か？ ii. 認証局は第三者機関の運用監査を受けることになっている のに iii. 誰も監査する予定はなく、監査スキームも明らかでない？ © 2015 Kenji Urushima All rights reserved.
- 43. (参考)Certificate Transparencyの課題整理メモ(2) ③ CTログ管理事業者を信用できるのか？ i. CT運営者が意図的にCTにログを登録させないことはできる(CT八 分) ii. CT運営者がCTを意図的に改竄することはあるかもしれない。 ⑤ CT運営者を信用できるのか？(2) i. OCSP staplingと同じプライバシー懸念。サイトにアクセスするた 度にSCTを検証するためにログサーバーにアクセスする。ログサー バーを管理するCT運営者は「どのIPからどのサイトにアクセスが あったか」を全て保持できプライバシーの懸念がある。 ii. ChromiumベースのOperaもGoogleに対してCTの懸念を表明して いる。 © 2015 Kenji Urushima All rights reserved.