Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論

© 2015 Kenji Urushima All rights reserved.
Certificate Transparencyによる
SSLサーバー証明書公開監査情報と
その課題の議論 (資料公開版)　　　
Certificate Transparency有志勉強会
協賛：すみだセキュリティ勉強会/JNSA PKI相互運用WG
於：トレンドマイクロ株式会社(新宿)本社会議室
2015年6月12日(金)
JNSA PKI相互運用WG 漆嶌賢二

• Certificate Transparency(CT)とは
• Google ChromeでのCTの表示
• CTの構造
• CTの課題整理の議論
今日のアジェンダ

Certificate Transparency って
ご存知ですか？

某S社、曰く
透かし入り証明書
某D社、曰く
証明書の透明性とか
透かし入り証明書とか
出典：
http://www.digicert.ne.jp/topics/CertificateTransparency.html
出典：
http://www.symantec.com/ja/jp/page.jsp?id=ssl-certificate-transparency

Certificate Transparency とは
認証局が「ポカ」やって不正なSSL
サーバー証明書が発行されたとしても、
それが「監査情報」を公開することに
よって、その発行が正当なものかどう
か判断できるようにする仕組みらしい。
「透かし入り証明書」などではなく、
「証明書発行監査の透明性(公開性)」とでも呼ぶべき

Certificate Transparencyとは(2)
ü  2011年、DigiCertやComodoなどで
　google.comドメイン不正証明書が
　発行されイラクの通信が盗聴
　その対策の一環として提案。
ü  2011年のGoogleの人の論文に基づく
ü  実験RFC 6962になった(準拠不要?)
ü  Google Chromeのみが実験に対応
ü  Chromeは1月〜EV証明書の必須要件に
ü  DigiCert, GlobalSignが先行対応
ü  他の海外認証ベンダも対応中

PKI解説サイトのImperialVioletで有名な
Adam Langley氏の2011年の論文
参考出典：http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf
DigiCert等の認証局の運用の誤りの問
題を受けて公表された論文
全ての認証局から発行される証明書に
ついて、「本当に認証局が意図して発
行したのかという監査情報を公開する
ようにし、利用者はこれを見て証明書
が正しく発行されたものか判断できる
仕組みの必要性を説いた。」
私見だが、CTの意義は今でも同意で
きない。認証局は運用監査を受けてい
るし、運用で誤った証明書なら失効す
れば良いだけ。　→　ただ、これが実
験RFCになり、実装までしてしまった。

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表示をしない。

目に見える
Certificate Transparencyとは
(Chrome、DigiCert等が対応)
　　　

CT対応じゃないサイト(=ほとんどのサイト)
例の出典
https://jp-businessstore.symantec.com/qq2/symantec/index.asp
鍵を右クリック
「公開監査記録がない」
＝
Certificate Transparency
非対応のサイト

CT対応のサイト(=GlobalSign or DigiCert)
例の出典
https://www.digicert.com/鍵を右クリック
「公開監査が可能」
＝
Certificate Transparency
対応のサイト

CT対応のサイト(=GlobalSign or DigiCert)
Signed Certificate Timestamp (SCT)
(RFC 3161とは無関係の
CTログエントリに対する署名情報)
DigiCert、GlobalSignには
見慣れない拡張が！！
(embeddedSCT)
「SCTを証明書に入れる」とい
うことは「証明書発行の前に
SCTが必要」という事© 2015 Kenji Urushima All rights reserved.

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
中間認証局
プレ用認証局
拡張鍵使用目的=
　CT(1.3.6.1.4.1.11129.2.4.4)
ログサーバー
認証局
ウェブサイト
ウェブブラウザ
①プレ証明書 ②プレ証明書
　(SCT付)
③サーバー証明書
　(SCT付)
④SSL/TLS通信
　(SCT付証明書)

世界に配置された
CTログサーバー(リポジトリ)
　　　

ログサーバー(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
証明書以外も含まれる。

ログサーバー(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

Google Pilot CT Logエントリ数の推移(2015年2月〜6月)
現在、777万枚のSSL証明書
1.1万枚/日でリニアに増加
ミシガン大のZmapによる全IPアドレ
ス調査などと比較して圧倒的に効率的
にSSLサーバー証明書が回収可能
20515年3月
4月
5月
6月

CTログの構成要素
　　　

CTログの構成要素
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
a1.jpサーバ証明書
中間CA証明書
ルートCA証明書
リーフデータ(=証明書チェイン)
or ログエントリ
Signed Certificate TimeStamp (SCT)
ID番号
ログ名/ID
監査時刻(登録時刻)
SHA256wECDSA署名値
署名
Signed Tree Head
タイプ
生成日時
ツリーのサイズ(リーフ数)
ルートのSHA256ハッシュ値
Markle Hash
下位ノードに対するハッシュ値
署名

追記のみを許すと主張しているログデータ全体の構造
(実際には技術的に
「追記のみ」を保証されない)
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
a1.jpサーバ証明書
中間CA証明書
ルートCA証明書
特徴
①  ハッシュ計算とマークル木により
追加だけしかできない(append only)
②  ハッシュ計算とマークル木により
途中改竄はできない
③  Bitcoinのマークル木と似ている
④  ログエントリとは証明書チェインの事
⑤  一部のデータはGoogleのECC鍵で
署名される
リーフ
データ
(=証明書
チェイン)
Signed
Certificate
TimeStamp
(SCT)
ID番号
ログ名/ID
監査時刻(登録時刻)
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ
SHA256
ハッシュ

CTのマークルハッシュ木
　　　

マークル木の成長(証明書
が登録されると木が成長する) 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

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は
木に含まれる証明となる。

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)

TLSサーバーからクライアントへSCTを渡す3つの方法(参考)
①SSLサーバー証明書の
embedSCT拡張に含める
(最も一般的？)
②TLSハンドシェイクの
signed_certificate_timest
amp型TLS拡張に含める
(対応実装は無い?)
③TLSハンドシェイクの
status型TLS拡張のOCSP
staplingに含める (対応実
装は無い?)
ほぼこの方式
しか使わない
対応実装
無し
対応実装
無し

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になっていた方が取扱いが容易だった

公開ログサーバーへの
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←

本家 www.certificate-transparency.org サイト
① CTの解説
② ツールのソースコード
③ 仕様(RFC 6962)
④ プレゼン資料

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

Certificate Transparencyの
課題整理(議論)
　　　
① そもそも信頼できる監査情報なのか?
② 仕組み/データとして信頼できるのか?
③ プライバシー懸念があるのでは？

CTで保持されている公開監査情報は意味があるのか？
持っている情報は
・証明書チェーン
・登録時刻
のみ
CTログ
サーバー
悪意のある者がCTを使うことがある
•  不正発行した証明書を登録することができる
•  正しく発行されたものと区別がつかない
結局、CTログにあるから健全とは限らない
•  ログサーバー自体が監査を受けていない
•  どのようなポリシーでログ登録されるか不明
•  健全なログかどうかわからない
•  不正発行された証明書が登録されているかもれない
•  CT導入前に発行され、今CTに登録されている証明書
は監査の網をすりぬけた証明書
•  CT管理者はいつでもCTログDBの改ざんが可能(後述)

② 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管理者は改ざんし放
題で事実上のビッグブラザーに
なっている。
改ざん
追加

③ CTにはプライバシーの懸念があるのでは？
HTTPSウェブサイト
aaa.com
CTログサーバー
①TLS
　アクセス
②aaa.comの
　SCT付
　証明書
③aaa.comが
　CTログにあるか、
　正しいか、検証
　
CTサーバー管理者は今、CT
に登録されている数百万のサ
イトに対する全世界からのア
クセス情報を、公開監査ログ
検証の名目で収集できる可能
性がある。
本来、利用者とaaa.com
しか知り得なかった情報
OCSP staplingによるプライバシー懸念と全く同種の問題がCTでも起きる

④ プレ証明書の運用を入れることで
　　認証局は高リスクに
プレ証明書
・シリアル
・発行者
・有効期間
・主体者
・拡張領域
　CRLDP,SAN等
1.3.6.1.4.1.11129..2.4.3=
ASN.1 NULL
・プレ用中間CAの署名
予定の証明書
・シリアル
・発行者
・有効期間
・主体者
・拡張領域
　CRLDP,SAN等
ルート認証局
発行する証明書
・シリアル
・発行者
・有効期間
・主体者
・拡張領域
　CRLDP,SAN等
　embedSCT拡張
　　=SCT
中間認証局
プレ用認証局
拡張鍵使用目的=
　CT(1.3.6.1.4.1.11129.2.4.4)
•  認証局を追加することで認証
局は運用コスト大幅増
•  事前にシリアル、有効期間な
どが同じ証明書を発行するこ
とは、CAの監査的にも良くな
い。
•  プレ認証局の運用監査はどう
するのか？(コスト増)
•  プレ認証局から「不正証明
書」が発行されるリスクが非
常に高まる。
•  パス検証で「未知のクリティ
カル拡張」を正しく扱えない
ブラウザは、不正な証明書を
受け入れてしまう可能性があ
る。
CTのメリットはほぼ無いのに
「認証局の不正を生みやすい高
コストな環境」を作っている。

⑤ (追記)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だけでなく、他のブラウザも対応し始めた
さらに、とてもまずい状況になった

(参考) 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

不完全なChromiumのCT Logの運用ポリシー
Google Chromiumプロジェクトには
CTログのポリシーが定められている
が
•  認証局はPwCなど必要な外部
運用監査をしているが
•  CTについては何もシステム監査
するつもりは無さそう
•  精神論で「完全性を維持」と言って
いるだけで、誰もその運用を担保で
きない。
•  正しく運用されていた事を示す方法
がない。
•  CTのEC鍵管理も不明確
https://www.chromium.org/Home/chromium-
security/certificate-transparency/log-policy

(参考)IETFのCT wikiページ
出典：http://trac.tools.ietf.org/wg/trans/trac/wiki
今は大した情報はないが今後に期待？？？
(CT検索系のオンラインツールが整備されそう)

(参考)ChromiumのCT関連ソースコード
出典：https://chromium.googlesource.com/
chromium/src/+/master/net/cert
ct_*.[ch]
•  6つのサーバー用のECC公開鍵などある
•  検証はあまりまともに実装されてなさそう

主張
Certificate Transparencyは仕組
み的にも、運用的にも「証明書の有
効性」などの何かを証明できるよう
な仕組みにはなっていない。そのよ
うな仕組みを信頼の起点とするのは、
非常に問題があるのではないか。

ご清聴ありがとうございました

(参考)Certificate Transparencyの課題整理メモ
①  そもそも何を監査しているのか不明
i.  保管しているのは「ただの」証明書チェーンと登録時刻
ii.  正当な発行によるものかそうでないかは不明
iii.  誰でもログサーバーに登録でき不正なもの登録可？
iv.  結局CTにおいてあるもので監査できるのは何なのか？
v.  誤った登録があった際に、これを取り消す仕組みがない。
vi.  複数登録があった際に、どちらが正しいのかを知る術がな
い。
vii.  そもそも、証明書の失効情報だけで充分なのでは？
②  CTの運用監査は誰がするのか？
i.  ログサーバーに使う楕円秘密鍵管理は適切か？
ii.  認証局は第三者機関の運用監査を受けることになっている
のに
iii.  誰も監査する予定はなく、監査スキームも明らかでない？

(参考)Certificate Transparencyの課題整理メモ(2)
③  CTログ管理事業者を信用できるのか？
i.  CT運営者が意図的にCTにログを登録させないことはできる(CT八
分)
ii.  CT運営者がCTを意図的に改竄することはあるかもしれない。
⑤  CT運営者を信用できるのか？(2)
i.  OCSP staplingと同じプライバシー懸念。サイトにアクセスするた
度にSCTを検証するためにログサーバーにアクセスする。ログサー
バーを管理するCT運営者は「どのIPからどのサイトにアクセスが
あったか」を全て保持できプライバシーの懸念がある。
ii.  ChromiumベースのOperaもGoogleに対してCTの懸念を表明して
いる。

Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論

Semelhante a Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論 (20)

Último

Último (9)

Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論