TLS/SSLの暗号利用に関する現状と課題について
NTT情報流通プラットフォーム研究所
情報セキュリティプロジェクト
神田 雅透

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

Internet Week 2008にてどのように変わったか？
（あるいは変わらなかったか？）

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

SSL/TLSは暗号化技術？
「暗号化はSSLで」の一言で片づけられていないか～ どんな暗号を使っているか認識されていないのに「適切な設定」がなされているか ～FAQでの説明

しかし、実際には
SSL/TLSで利用可能な暗号
共通鍵暗号

ブロック暗号

ストリーム暗号
公開鍵暗号
デジタル署名
ハッシュ関数

RC2(40), DES (40,56), Triple DES, IDEA,
AES, Camellia, SEED
RC4(40, 128)
RSA, ECDH, DH
RSA, DSS(DSA), ECDSA
MD5, SHA-1, SHA-256, SHA-384, SHA-512
20091125 Internet Week 2009説明資料

これらのうちどれを使うかはサーバとブラウザが事前にネゴシエーションして決定
設定によって実際の暗号化に使われる暗号が異なる（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

SSL/TLSの概要
 ハンドシェイクで使用する暗号アルゴリズムを決定
Client (ブラウザ)(RSA,DSA, DH), (MD5,SHA-1),(RC4, DES, TDES, AES, Camelliaなど){利用可能な暗号アルゴリズム一覧}
サーバSSL証明書の検証{使用する暗号アルゴリズム,

Pre Master Secret 生成

暗号アルゴリズムの決定

サーバSSL証明書}{暗号化された Pre Master Secret}

サーバSSL証明書の公開鍵で暗号化

秘密鍵で復号
Pre Master Secret 生成
Master Secret 生成

Master Secret 生成
Session Key生成

Server (Webサーバ){ハンドシェイク終了通知}

Session Key生成{ハンドシェイク終了通知}

暗号化データ通信
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

OpenSSLで利用可能な暗号アルゴリズム
サーバ認証なし

輸出規制対応SSL2.0対応
DES-CBC3-MD5

CAMELLIA256-SHA

RC4-SHA

ADH-CAMELLIA256SHA

EXP-DES-CBC-SHA

DHE-RSA-CAMELLIA256-SHA

IDEA-CBC-SHA

ADH-CAMELLIA128SHA

EXP-EDH-RSA-DES- IDEA-CBC-MD5CBC-SHA

DHE-DSS-CAMELLIA256-SHA

RC4-MD5

ADH-AES256-SHA

EXP-EDH-DSS-DES- RC4-MD5CBC-SHA

AES256-SHA

DES-CBC-SHA

ADH-AES128-SHA

EXP-RC4-MD5

RC2-CBC-MD5

DHE-RSA-AES256-SHA

EDH-RSA-DESCBC-SHA

ADH-DES-CBC3SHA

EXP-RC2-CBC-SHA

DES-CBC-MD5DHE-DSS-AES256-SHA

EDH-DSS-DESCBC-SHA

ADH-RC4-MD5

EXP-ADH-DESCBC-SHA

EXP-RC4-MD5ADH-DES-CBC-SHA

EXP-ADH-RC4-MD5

EXP-RC2-CBC-MD5

CAMELLIA128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128SHA
AES128-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA

SSLで利用する暗号アルゴリズムとして
これらの中のどれかが一つをサーバが選択する

EDH-DSS-DES-CBC3-SHA
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

ブラウザが利用する暗号のデフォルト優先順位
IE8
IE7
Vista1 XP3 Vista2 Vista1 XP3
ECDHE_RSA_WITH_RC4_128_SHA
ECDHE_RSA_WITH_AES_256_CBC_SHAECDHE_RSA_WITH_AES_128_CBC_SHAECDHE_ECDSA_WITH_RC4_128_SHA
ECDHE_ECDSA_WITH_AES_256_CBC_SHAECDHE_ECDSA_WITH_AES_128_CBC_SHA
ECDH_RSA_WITH_AES_256_CBC_SHA
ECDH_ECDSA_WITH_AES_256_CBC_SHA
RSA_WITH_RC4_128_SHA
RSA_WITH_RC4_128_MD5
RSA_WITH_CAMELLIA_256_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
RSA_WITH_3DES_EDE_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
DHE_DSS_WITH_AES_256_CBC_SHA
DHE_DSS_WITH_AES_128_CBC_SHA
DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL2_RC4_128_WITH_MD5
SSL2_DES_192_EDE3_CBC_WITH_MD5
SSL2_RC2_CBC_128_CBC_WITH_MD5

87878765656521312312321421431221410911420091125 Internet Week 2009説明資料

10911109112
134IE6
XP3 XP221374562137456FX3XP213214111127825249102633315541661830

FX2Safari3.2
XP2 Vista2 XP310281178169556193218121720272143341324109117456（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所新年早々のホットな話題 = MD5証明書偽造 =“MD5 Considered Harmful Today-Creating a rogue CA certificate”
Root CA

＠CCC 2008 (Chaos Communication Congress, 2008.12.30)
R-CA Certification
R-CA public key

R-CA sig
ブラウザに標準で入っている証明書

中間CA

R-CA Certification

A-CA Certification

R-CA Certification

X-CA Certification

R-CA public key

A-CA public key

R-CA public key

X-CA public key

R-CA sig下位CA

出典：日経パソコンより

サーバ
証明書

R-CA sig

R-CA sig

R-CA sig

R-CA Certification

A-CA Certification
X-CA

Shop Certification

R-CA public key

A-CA public key
X-CA

Shop public key

R-CA sig

R-CA sig

20091125 Internet Week 2009説明資料

A-CA
X-CA sig（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

MD5(Merkle-Damgard構造)の衝突
 衝突攻撃：2004年Wangらにより発見

MD5(M)=MD5(M*)となる(M,M*)を見つける
 選択プレフィックス衝突探索：2007年Stevensらが発見
任意の(P,P*)に対しMD5(P|M)=MD5(P*|M*)となる(M,M*)を求める
IVP

IV1

M

IV2Mn

ハッシュ値

ΔIV2 = 0

P*

IV*1

M*

Mn

2008年： PにRoot CAをだますためのダミー情報、P*に公開鍵を含む偽造情報を入れて選択プレフィックス衝突探索手法を実行し中間CA EE証明書を偽造。PS3 200台で約1日
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

MD5を使った偽造SSL証明書
 何が問題だったのか？

MD5の耐衝突性が脆弱
ルートCAが決める「シリアルナンバー」「有効期限」が予測可
ブラウザが無視するコメント領域が存在

MD5で
ハッシュ

バージョン
シリアル番号
発行者情報
有効期限

ルートCAが決定

予測

主体者情報

主体者
公開鍵情報

主体者情報

この部分を使って証明書申請

拡張フィールド
署名

バージョン
シリアル番号
発行者情報
有効期限

MD5でハッシュ値が一致攻撃者が設定する情報

バージョン
シリアル番号
発行者情報
有効期限
主体者情報
主体者
公開鍵情報
拡張フィールド

主体者
公開鍵情報
拡張フィールド

署名付け替え20091125 Internet Week 2009説明資料

衝突を起こすようにデータ操作

ブラウザが無視する
コメント領域
署名（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

実際にどうなっているのか検証 調査対象：

政府・公共系サイト及び金融系サイトの各トップページからたどることができるSSLサーバ
政府・公共系：約145サーバ、金融系：約135サーバ
 調査期間：2008年10～11月／2009年5～6月
 調査内容：サーバ証明書の状況（有効期限、アルゴリズム、鍵長等）
暗号選択設定の状況（接続可能なアルゴリズム）
ブラウザでの実際の接続状況（IE6, IE7, Firefox3）
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

サーバ証明書の状況 （アルゴリズムと有効期限）
政府・公共系サーバ

内側：2008年11月
外側：2009年 6月

金融系サーバ

有意に減少

GPKI
集約効果

EVSSL効果2009年6月時点で利用されている証明書の有効期限

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

サーバでの暗号設定 ～受入可能な主な暗号～
政府・公共系サーバ 2008年11月

2009年6月

CRYPTRECで推奨されている設定2008

2003
特許訴訟リスクを有する暗号
鍵長56ビットの暗号サーバの正当性検証を要求しない
鍵長40ビットの暗号脆弱性があるバー
ジョン
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

サーバでの暗号設定 ～受入可能な主な暗号～
金融系サーバ2008年11月

2009年6月

CRYPTRECで推奨されている
設定
2008

2003
特許訴訟リスクを有する暗号
鍵長56ビットの暗号サーバの正当性検証を要求しない
鍵長40ビットの暗号脆弱性があるバー
ジョン
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

Internet Explorer 7 (Win XP)での接続
政府・公共系サーバ

内側：2008年11月
外側：2009年 6月

金融系サーバ

今まで使っていたデータは誤りでしたm(._.)m

RC4はSHA1ではなくMD5でした。XP SP3でも同様
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

Firefox 3 (Win XP)での接続
政府・公共系サーバ

金融系サーバ内側：2008年11月
外側：2009年 6月

AESの暗号設定状況と実際の接続での逆転現象
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

Internet Explorer 7 (Win Vista)での接続
政府・公共系サーバ

外側：2009年 6月

金融系サーバ

AESは使われるけども、AES128のほうが優先
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

AESが利用される設定になっているか
政府・公共系サーバ

金融系サーバ
内側：2008年11月
外側：2009年 6月

設定変更してもAESの利用率はほとんど変わっていない
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

SSLサーバ証明書と暗号のバランス
AES256-SHAで接続しているサーバに限定
政府・公共系サーバ

内側：2008年11月
外側：2009年 6月

金融系サーバ

AESを使っているサーバだから証明書も、とはなっていない
20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

SSLの調査結果から整合的に暗号設定が行われている形跡が見いだせない～ 暗号アルゴリズム設定がベンダ任せになっていませんか ～「暗号化はAES256ビット」なのに「鍵交換は512ビットRSA」
 RC4で接続といってもSHA1を使っているとは限らない
 AESを使えるようにしたのにMD5のサーバ証明書のまま
 同じ企業内のサーバであっても設定内容に一貫性がない
 どの暗号アルゴリズムが選択されたかブラウザ（クライアント）からは確認できない

せっかく設定を変えたのに・・・設定失敗
AESを使えるようにしたらSSL2.0やEXPも利用可能になった
 「AES256-SHA1」が使えるはずなのに「RC4-MD5」を選択20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

SSLの調査結果からSSL証明書の中身を確認しているか？
更改できるタイミングが何回もあったはずなのにMD5のSSL証明書が未だに健在
 MD5や署名長は変わっても、鍵交換用RSAの鍵長は変わらない

SSL証明書の期限切れを起こすことが意外と多い

出典：日経情報ストラテジー
http://itpro.nikkeibp.co.jp/article/NEWS/20080918/315052/

20091125 Internet Week 2009説明資料

再調査中に3件の期限切れを発見（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

まとめ
SSLサーバの暗号設定マニュアルのようなものを整備～ 暗号の説明というより作業マニュアルとして反映 ～ 利用するciphersuiteを設定するための作業マニュアル
 SSLサーバ証明書を発行・更新手続きするための作業マ

ニュアル
 作業マニュアルを利用させるためのルール化

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

例えば NIST SP800-52

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

例えば NIST SP800-44

20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

CRYPTREC推奨SSL/TLSに対する（たぶん国内唯一の）公式ガイドライン
2003年2月決定の電子政府推奨暗号リストに基づく推奨
公開鍵暗号
（署名）

RSA 1024 bit以上
DSA 1024 bit以上
ECDSA 160 bit 以上

SHA-1

2008年3月発行の電子政府推奨暗号の利用方法に関するガイドブックに記載の推奨

RSA 1024 bit以上
DH 1024 bit以上
ECDH 160 bit以上

SHA-1

RSA 2048 bit以上
DSA 2048 bit以上
ECDSA 224 bit 以上

SHA-1*

公開鍵暗号
（鍵共有）

公開鍵暗号
（署名）

AES 128 bit以上
Camellia 128 bit以上
3-key Triple DES
128-bit RC4

RSA 2048 bit以上
DH 2048 bit以上
ECDH 192 bit以上

SHA-1*

共通鍵暗号

公開鍵暗号
（鍵共有）
共通鍵暗号

AES 128 bit以上
Camellia 128 bit以上

MD5はこの時点ですでに推奨ではなかった

20091125 Internet Week 2009説明資料* 利用は推奨されないが、変更できるようになった場合には暗号切替等を検討することを推奨

RC4とTriple DESも推奨から外されている（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所

カナダ政府の推奨20091125 Internet Week 2009説明資料（ｃ）日本電信電話株式会社
情報流通プラットフォーム研究所