SSL 安 全 性 調 査 報 告 書 改 訂 第 2 版 2004 年 2 月 6 日 ( 株 )KDDI 研 究 所 1

Transcription

1 2

2 SSL 安 全 性 調 査 報 告 書 改 訂 第 2 版 2004 年 2 月 6 日 ( 株 )KDDI 研 究 所 1

3 2

4 3

5 目 次 0. はじめに SSL/TLS の 比 較 SSL 3.0 の 概 要 SSL レイヤ 構 造 CipherSpec/SecurityParameters Record Layer プロトコル Handshake プロトコル Alert プロトコル ChangeCipherSpec プロトコル Application Dataプロトコル SSL 3.0/TLS 1.0 の 比 較 MAC(Message Authentication Code:メッセージ 認 証 符 号 ) master_secret の 計 算 key_block 計 算 final_client_write_key および final_server_write_key の 計 算 Exportable encryption algorithms 使 用 時 の client_write_iv および server_write_iv の 計 算 ServerKeyExchange メッセージの Signature の 構 造 体 CertificateVerify メッセージで 使 用 されるハッシュ 計 算 Finished メッセージ CipherSpec(SSL)と SecurityParameters(TLS) Alert プロトコル その 他 TLS 拡 張 作 業 の 概 要 機 能 拡 張 認 証 方 式 の 拡 張 鍵 共 有 方 式 の 拡 張 暗 号 方 式 の 拡 張 その 他 SSL における 既 存 セキュリティホールとその 対 策 について 暗 号 方 式 上 のセキュリティホールとその 対 策 DSA のセキュリティホール

6 PKCS#1 のセキュリティホール PKCS#1 v.2.0 OAEP に 関 するセキュリティホールについて PKCS#1(v.1.5)に 対 する 適 用 的 選 択 暗 号 文 攻 撃 の 拡 張 CBC モードのパディング 方 式 における 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 その 他 の CBC パディングの 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 PKCS#1 V2.1 などの 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 SSL ソフトウェアに 対 するタイミング 攻 撃 プロトコル 上 のセキュリティホールとその 対 策 Man-in-the-middle attack Replay attack Version rollback attack Ciphersuite rollback attack Key-exchange algorithm rollback attack Cut-and-paste attack Short-block attack Dropping the change cipher spec message Attack against finished messages Traffic analysis Attack against a resuming session 実 装 上 のセキュリティホールとその 対 策 (2002 年 3 月 まで) Interner Explorer HTTPS certificate attack Bypassing Warnings For Invalid SSL Certificates In Netscape Navigator Multiple Vendor SSL Certificate Validation Vulnerability RSA BSAFE SSL-J Authentication Bypass Vulnerability OpenSSL PRNG Internal State Disclosure Vulnerability Microsoft IE SSL Spoofing Vulnerability Netscape Communicator Inconsistent SSL Certificate Warning Vulnerability OpenSSL Unseeded Random Number Generator Vulnerability IIS / Site Server Multithread SSLVulnerability NT IIS SSL DoS Vulnerability Netscape Navigater SSL における 疑 似 乱 数 の seed によるセッション 鍵 の 推 定 に よる 攻 撃 Microsoft IE 4.x, 5.x における Cached Web Credentials 問 題 その 他 SSL というキーワードで 検 索 されるが 直 接 SSL とは 関 係 のないセキュリテ ィホール

7 2.4. 実 装 上 のセキュリティホールとその 対 策 (2002 年 3 月 以 降 ) ASN.1 に 関 するセキュリティホール Buffer Over flowによる 脆 弱 性 ルート 証 明 書 配 送 の 問 題 表 示 の 不 具 合 が 実 質 上 のセキュリティホールになる 問 題 運 用 上 の 注 意 点 秘 密 鍵 や 証 明 書 などの 重 要 なファイルの 管 理 RandomSEED の 取 得 セッション 鍵 のライフタイム 使 用 するプロトコルバージョン 使 用 する 暗 号 アルゴリズム 証 明 書 検 証 ログ 警 告 通 知 その 他 設 定 パッチマネージメントについて 参 考 文 献

8 0. はじめに SSL は インターネットにおいて 最 も 利 用 されているセキュリティプロトコルである Web 上 の 暗 号 化 認 証 機 能 として 利 用 されており SSL を 用 いた 各 種 電 子 行 政 サービスや 民 間 のオンラインクレジット 決 済 サービスなどで 広 く 利 用 されている しかしながら SSL を 使 っているから 安 全 といった 認 識 が 蔓 延 しており SSL がどの 程 度 の 安 全 性 を 有 するの かを 客 観 的 に 調 査 評 価 した 試 みはあまり 見 られない 上 記 の 背 景 にともない 2001 年 度 に CRYPTREC 殿 の 仕 様 に 従 い SSL/TLS について (1) 暗 号 方 式 そのものの 安 全 性 (2)プロトコル(メカニズム)としての 安 全 性 (3) 実 装 に 関 する 安 全 性 (4) 運 用 上 の 安 全 性 といった 観 点 から これまで 報 告 されてきたセキ ュリティホールについて 調 査 を 行 った 約 2 年 経 過 した 2004 年 1 月 その 後 方 式 や 実 装 に 関 わる 新 たな 攻 撃 や 改 良 された 攻 撃 が 提 案 されている 従 って 本 調 査 では SSLVer3.0/TLS Ver1.0 以 上 を 対 象 とし 前 回 の 調 査 から 現 在 (2004 年 1 月 )に 至 るまでに 新 たに 発 見 公 開 されたセキュリティホールおよびその 対 処 法 を 調 査 することを 目 的 としている 具 体 的 には 前 回 の 調 査 の 後 報 告 されている SSL/TLS に 対 する 攻 撃 として サイドチャネル 攻 撃 タイミング 攻 撃 その 他 の 実 装 攻 撃 の 観 点 から 調 査 を 行 った 以 下 本 調 査 結 果 の 概 要 を 述 べる サイドチャネル 攻 撃 については SSL/TLS で 用 いられる 暗 号 化 のパディング(CBC パデ ィング)に 関 して バイト 単 位 の 固 定 のパディングパターンを 使 用 している 場 合 パディ ングの 正 当 性 チェックの 結 果 を 利 用 して 平 文 をバイト 単 位 で 逐 次 求 めることが 可 能 であ るという 攻 撃 手 法 が 存 在 する また RSA Encryption については これまで 報 告 された Bleichenbacher の PKCS#1(v.1.5)に 対 する 適 用 的 選 択 暗 号 文 攻 撃 を 改 良 した 実 用 的 な 攻 撃 手 法 が 提 案 されている いずれの 攻 撃 法 についても 対 策 が 提 案 され 最 新 のソフトウ ェアでは 対 処 がなされている そして PKCS#1(v.2.1)に 従 う EME-OAEP-DECODE 手 法 による 復 号 プロセスにおいて 攻 撃 者 が 平 文 の 一 部 のハミング 重 みを 集 めることにより 平 文 の 最 下 位 ビットを 露 呈 させ さらにその 情 報 から 所 望 の 平 文 を 得 るという 手 法 や RSA-KEM において 攻 撃 者 が 秘 密 鍵 のあるビットにフォールトを 故 意 に 起 こさせること により 秘 密 鍵 をビットごとに 露 呈 させる 手 法 も 提 案 されている しかし 前 者 はハミン グ 重 みに 対 する 電 力 サイドチャネル 攻 撃 を 後 者 は 秘 密 鍵 に 対 する 電 力 フォールトサイド チャネル 攻 撃 をそれぞれ 前 提 としているため SSL/TLS においては 実 用 的 な 攻 撃 手 法 では ない タイミング 攻 撃 については SSL のソフトウェアで 用 いられている RSA 実 装 において 高 速 化 を 目 的 として 用 いられる Montgomery reduction や Karatsuba 乗 算 法 に 起 因 し RSA 復 号 処 理 においてその 入 力 値 の 大 きさにより 処 理 ロジックが 異 なり タイミングアタ ックが 成 功 する 報 告 もなされている 本 アタックについても 対 策 が 提 案 されている 実 装 上 の 攻 撃 としては ASN.1 に 対 する 脆 弱 性 を 含 め Buffer Overflow に 関 するセキュリティ 7

9 ホールが 種 々 報 告 されており これらをまとめている また SSL/TLS プロトコルに 付 随 す る 証 明 書 管 理 技 術 におけるルート 証 明 書 の 更 新 手 法 の 課 題 や ブラウザの 表 示 に 関 する 不 具 合 が 実 質 上 の 攻 撃 につながる 問 題 も 記 載 している 報 告 されている 種 々のセキュリティ ホールについては 2004 年 2 月 19 日 現 在 パッチによる 対 策 がなされているが 脆 弱 性 公 開 存 在 しても 公 開 されない 場 合 や 公 開 からパッチが 提 供 までに 時 間 がかかるなど 問 題 が 残 っている その 他 運 用 上 の 対 策 として 最 新 パッチを 管 理 する 技 術 が 重 要 となるため 米 国 の NIST (National Institute of Standards and Technology)では セキュリティ 上 の 問 題 を 修 正 するパッチの 運 用 指 針 を 定 めた Procedures for Handling Security Patches を 発 行 して いる SSL/TLS とは 直 接 関 係 はないが 一 般 的 なソフトウェアの 運 用 の 課 題 として 本 文 書 の 概 要 を 述 べる これらの 調 査 結 果 は 2 章 以 降 において 2001 年 度 の 報 告 書 を 更 新 する 形 で 反 映 してい る SSL/TLS は ある 種 完 成 されたセキュリティプロトコルと 考 えられているが 2001 年 度 の 調 査 後 も Buffer Overflow 等 の 実 装 上 の 不 具 合 に 加 えて サイドチャネル 攻 撃 やタイ ミング 攻 撃 などの 新 たな 攻 撃 手 法 が 提 案 されているのが 実 状 である 従 って 電 子 政 府 な どの 各 種 システムで SSL/TLS を 安 全 に 利 用 するためには 今 後 も 継 続 的 に SSL/TLS の 安 全 性 について 監 視 を 行 い 脆 弱 性 に 関 する 正 確 な 知 識 をもち 最 新 の 対 策 を 施 すことが 望 まれる 本 調 査 報 告 がその 一 助 となれば 幸 いである 8

10 1. SSL/TLS の 比 較 SSL と TLS は プロトコル 構 造 や 提 供 する 機 能 に 関 して ほぼ 同 等 の 規 格 である 従 って 本 節 では 始 めに SSL の 概 要 を 述 べ その 後 SSL と TLS の 差 分 について 具 体 的 に 言 及 することとする 1.1. SSL 3.0 の 概 要 SSL レイヤ 構 造 SSL は OSI 参 照 モデルでいうところのセッション 層 (TCP/UDP の 直 上 )に 位 置 するプ ロトコルで 本 プロトコルを 用 いることにより 盗 聴 や 改 竄 を 防 止 できる 尚 1.1 節 において SSL と TLS が 同 じ 機 能 を 保 有 する 場 合 は SSL としてすべて 記 述 し た また 微 小 な 差 ( 例 えば プロトコルバージョンなどのパラメータ 値 等 )については SSL および TLS の 差 が 分 かるよう 明 記 した 明 確 な 機 能 の 差 については 1.2 節 に 示 す SSL は 図 に 示 すとおり 構 造 上 さらに 二 つのレイヤに 分 かれており 下 位 レイヤ には 上 位 層 / 下 位 層 からのデータの 分 割 / 組 立 圧 縮 / 伸 張 暗 号 化 / 復 号 化 を 行 う Record Layer プロトコルがある また 上 位 レイヤには Handshake Change Cipher Spec Alert Application Data の 四 つのプロトコルがあり 認 証 手 続 きや SSL で 通 信 するための ネゴシエーション 異 常 状 態 を 知 らせる 警 告 メッセージ 送 受 信 などの 機 能 を 有 する 9

11 SSLレイヤ 構 造 アプリケーション 層 プレゼンテーション 層 セッション 層 SSL トランスポート 層 ネットワーク 層 Handshake ( 含 むSecurity Param.) Change Cipher Spec Alert Application Data Record Layer Protocol データリンク 層 物 理 層 図 SSL レイヤ 構 造 10

12 送 信 時 においては Application Data Alert Handshake Change Cipher Spec のプロ トコルから 送 られるデータ メッセージはすべて Record Layer Protocol で 圧 縮 暗 号 化 の 処 理 を 行 い 通 信 相 手 に 送 信 される 受 信 時 では 逆 に Record Layer Protocol 解 凍 復 号 化 の 処 理 を 行 い 上 位 の 各 プロトコルに 引 き 渡 される Application Data プロトコルは さらに 上 位 レイヤのアプリケーションで 使 用 されるデー タを 送 受 信 する Handshake プロトコルでは サーバ クライアント 間 の 認 証 や 暗 号 化 方 式 鍵 の 値 や MAC 方 式 などのネゴシエーションを 行 う またこのプロトコルで 設 定 された 値 について 通 信 相 手 に Change Cipher Spec プロトコルはこの 値 の 使 用 開 始 を 通 知 するとともに Record Layer プロトコルにおいて 使 用 される CipherSpec/SecurityParameters にパラメータを セットする 各 プロトコルにおいて 何 らかの 異 常 があったときは Alert プロトコルに 通 知 する Alert プロトコルでは 異 常 状 態 に 応 じたメッセージを 通 信 相 手 に 送 信 し コネクション 切 断 など の 処 置 を 行 う 各 プロトコルは 節 以 降 で 説 明 する 11

13 CipherSpec/SecurityParameters CipherSpec(TLS では SecurityParameters)は SSL での 動 作 環 境 を 示 している これら は 構 造 体 の 形 を 呈 しているが この 構 造 体 そのものが 通 信 されることはなく 自 身 での 暗 号 処 理 や MAC 処 理 認 証 処 理 などで 参 照 する これらの 値 は Handshake プロトコルに おいて 暗 号 方 式 や 圧 縮 方 式 MAC 方 式 などが 決 定 されたときに 設 定 される CipherSpec と SecurityParameters の 構 造 体 および 違 いに 関 して 節 で 示 す Record Layer プロトコル Record Layer プロトコルでは 上 位 レイヤからデータが 渡 されると データサイズが 2 の 14 乗 バイトを 超 える 場 合 はそれを 超 えないように 分 割 し SSLPlaintext SSLCompressed SSLCiphertext の 順 に 処 理 を 行 い その 結 果 を 下 位 レイヤに 引 き 渡 す なお 受 信 したもの を 下 位 レイヤから 受 け 取 った 場 合 は 逆 の 手 順 で 上 位 レイヤに 引 き 渡 す 上 位 レイヤから 下 位 レイヤへのデータの 引 き 渡 しを 図 に 示 す SSLPlaintext SSLCompressed SSLCiphertext の 構 造 は 後 述 の 通 り どれも ProtocolVersion ContentType length fragment で 構 成 される このうち ProtocolVersion と ContentType は 同 じ 値 がそのまま 使 用 される 上 位 から 送 られたデータ メッセージはまず SSLPlaintext.fragment となる SSLPlaintext.fragment は Handshake プロトコルで 規 定 された 圧 縮 方 式 により 圧 縮 処 理 が 行 われ SSLCompressed.fragment となる SSLCompressed.fragment は Handshake プ ロトコルで 規 定 された 暗 号 化 MAC 方 式 により 暗 号 化 MAC 処 理 が 行 われ SSLCiphertext.fragment となり 下 位 レイヤに 引 き 渡 されていく lengthはsslplaintext SSLCompressed SSLCiphertext それぞれの fragment の 大 きさを 示 すことになる ただし 初 めてコネクションを 張 る 場 合 は まだサーバ クライアント 間 でのネゴシエー ションが 取 れていないので この 場 合 は 圧 縮 暗 号 化 MAC アルゴリズムがどれも 指 定 さ れていないタイプで 通 信 することにより Handshake プロトコルで 圧 縮 暗 号 化 MAC アルゴリズムのネゴシエーションを 取 る 12

14 上 位 レイヤからのデータ SSLPlaintext 圧 縮 あり? No Yes : 構 造 体 の 型 処 理 SSLPlaintext.fragment 圧 縮 Fˆ SSLCompressed MAC/ 暗 号 化? No Yes MAC 処 理 block 暗 号 化 方 式? null( 暗 号 化 なし) stream Padding 処 理 暗 号 化 暗 号 化 SSLCiphertext 下 位 レイヤへ 図 Record Layer での 圧 縮 / 暗 号 化 /MAC 処 理 フロー 13

15 以 下 uintαはαビットの 数 値 opque はデータ 列 ( 長 さは 構 造 体 の[ ] 内 の 値 )を 表 す (1)SSLPlaintext(TLS では TLSPlaintext) 準 備 : struct { 構 造 体 :struct{ uint8 major, minor; } ProtocolVersion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; ContentType type; ProtocolVersion version; uint16 length; opaque fragment[sslplaintext.length] } SSLPlaintext; 上 位 から 受 け 取 ったデータを Record Layer ではまず 上 記 に 示 す 構 造 体 の 形 にする type は 上 位 レイヤからどんなメッセージ データが 送 られてきたのかを 示 している version で は 使 用 するプロトコルバージョン(SSL 3.0 なら 3, 0 TLS 1.0 なら 3, 1 )が 明 記 さ れる length は 次 に 続 く 実 際 のデータ(またはメッセージ) 部 分 の 長 さを 示 しており 2 の 14 乗 バイトを 超 えない 値 になっている 最 後 の fragment は 上 位 からの 実 際 のデータ(ま たはメッセージ)となる (2)SSLCompressed(TLS では TLSCompressed) 構 造 体 :struct{ ContentType type; /* SSLPlaintext.type と 同 じ*/ ProtocolVersion version; /* SSLPlaintext.version と 同 じ*/ uint16 length; opaque fragment[sslcompressed.length] } SSLCompressed; SSLPlaintext から 圧 縮 アルゴリズムにしたがいデータ メッセージを 圧 縮 し SSLCompressed という 構 造 体 に 変 換 する 14

16 ここでは type version では SSLPlaintext での 値 をそのまま 用 いる length は 圧 縮 したあ とのデータ メッセージの 長 さを 示 す この 値 は 2 の 14 乗 バイトの 値 を 超 えない fragment は SSLPlaintext.fragment を 圧 縮 したものである fragment 展 開 時 には 2 の 14 乗 バイトを 超 えてはならず 超 えた 場 合 は alert において decompression failure で 応 答 し なければならない ここの 圧 縮 で 使 用 されるアルゴリズムは Handshake プロトコルで 規 定 される また 初 期 値 としては 非 圧 縮 方 式 (CompressionMethod.null)となっている 注 :SSL の Draft または TLS の RFC においては 非 圧 縮 方 式 のみしか 採 用 されていない ただし TLS の RFC においては 方 式 を 追 加 しても 構 わないことが 明 記 されている (3)SSLCiphertext(TLS では TLSCiphertext) 構 造 体 :struct{ ContentType type; /* SSLCompressed.type と 同 じ*/ ProtocolVersion version; /* SSLCompressed.version と 同 じ*/ uint16 length; select (CipherSpec.cipher_type){ case stream: GenericStreamCipher; case block: G enericblockcipher; } fragment; } SSLCiphertext; SSLCompressed は 暗 号 化 MAC 手 続 きを 経 て SSLCiphertext に 変 換 される 上 記 構 造 体 のうち type version は SSLCompressedtext と 同 じ length は 2 の 14 乗 バ イトを 超 えない fragment 長 をあらわす fragment は SSLCompressed.fragment を MAC 付 きで 暗 号 化 したものである 暗 号 化 の 方 法 は CipherSpec で 示 されている cipher_type および hash_size の 値 で 決 められる MAC の 計 算 方 法 は 節 を 参 照 のこと cipher_type が null( 暗 号 化 しない)または stream を 示 すとき 以 下 の 形 の 物 を 作 成 し これを Handshake プロトコルで 規 定 した 方 式 で 暗 号 化 したものを fragment とする stream-ciphered struct ( opaque content[sslcompressed.length]; opaque MAC[CipherSpec.hash_size]; } GenericStreamCipher; cipher_type が block の 場 合 content と MAC の 他 に 暗 号 化 するときに 長 さを 調 節 する 15

17 paddingおよびその 長 さを 示 す padding_length を 連 接 し それを 暗 号 化 した 物 を fragment とする block-ciphered struct ( opaque content[sslcompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[genericblockcipher.padding_length]; uint8 padding_length; } GenericBlockCipher; 両 方 式 の 場 合 も content と MAC(block の 場 合 はさらに padding padding 長 )を 連 接 し た 後 で 暗 号 化 する 16

18 Handshake プロトコル Handshake プロトコルはサーバ クライアント 間 の 認 証 や 暗 号 化 方 式 鍵 の 値 や MAC 方 式 などのネゴシエーションを 行 う ここで 通 信 されるプロトコルでは 以 下 のようなメッ セージのやりとりが 行 われる なお ChangeCipherSpec は Handshake とは 別 プロトコル となるので 節 で 説 明 を 行 う Handshake Protocol Step 1 Client H ello Client Server S e rv e r H e llo Step 2 Certificate S erver K ey Exchange CertificateR equest S e rv e r H e lo D one Certificate Step 3 Client K ey Exchange C e rtificate V erify C hange C ipher S pec Finished C hange C ipher S pec Step 4 Finished F Í ƒi ƒv ƒv ƒ ƒi ƒ ƒ ƒbƒz [ ƒw A pplication D ata 図 SSL の Handshake protocol 処 理 概 要 17

19 Handshake プロトコルは 次 の 構 造 体 を 持 つ enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange(12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType uint24 length; msg_type; select (HandshakeType) { } body; } Handshake; case hello_request: Hellorequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; msg_type はこのメッセージのタイプ length はメッセージのバイト 長 を 示 す body は 各 メッセージ 内 容 を 示 し これはメッセージのタイプによって 違 いがある 以 下 に メッセ ージタイプごとの body の 中 身 を 説 明 する 以 下 メッセージの 概 要 を 送 出 順 に 示 す 18

20 (1)HelloRequest これは 実 際 の Handshake プロトコルでの 手 続 きに 使 われるものでなく 再 手 続 きが 開 始 さ れるべきであることをサーバから 通 知 するメッセージである クライアントがこのメッセ ージを 受 け 取 っても 手 続 きを 開 始 する 義 務 はなく Alert プロトコルで no_renegotiation 応 答 (TLS のみ)または HelloRequest を 無 視 してもよい サーバがこのメッセージを 送 信 したのにもかかわらず クライアントから ClientHello メッセージが 送 信 されてこなかった 場 合 fatal レベルの Alert プロトコルで 応 答 し コネクションを 終 了 してもよい このメッセージは 次 のような 空 の 構 造 体 になっている struct { } HelloRequest; (2)ClientHello クライアントが 最 初 にサーバに 接 続 するときの 最 初 のメッセージが ClientHello である ま た HelloRequest の 応 答 としても 使 用 される クライアントは ClientHello を 送 信 したら ServerHello を 待 ち もし HelloRequest 以 外 のメッセージがサーバから 返 答 されたら fatal エラーとする このメッセージは 次 の 構 造 体 をとる 準 備 : struct { 構 造 体 :struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; opaque SessionID<0...32>; uint8 CipherSuit[2] ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<0...2^16-1>; CompressionMethod compression_methods<0...2^8-1>; } ClientHello; client_version は このセッションで 通 信 しようとするプロトコルのバージョンを 示 すもの で サポートする 最 新 のバージョン(SSL 3.0 なら 3,0 TLS 1.0 なら 3,1 )が 望 まし い random は 鍵 計 算 などで 使 用 されるもので UNIX 標 準 (32 ビット 表 示 )の 現 在 時 間 と 28 バイトの 乱 数 から 構 成 される session_id は 再 ネゴシエーション 時 のみ そのセッション ID が 示 される 新 規 セッション の 場 合 は 0x00 の 値 のみ 挿 入 する 19

21 cipher_suites はクライアントでサポートしている 暗 号 方 式 のリストを 示 す session_id に なんらかの 値 が 設 定 されているときは その ID でのセッションで 使 用 している 暗 号 方 式 も リストに 加 えなければならない compression_methods はクライアントによってサポートされている 圧 縮 方 式 のリストを 示 す これにはかならず CompressionMethod.null( 非 圧 縮 )を 必 ずリストに 加 えなければな らない 注 : compression_methods は Draft または RFC では 非 圧 縮 のみサポート (3)ServerHello ServerHello は ClientHello の 応 答 としてサーバから 送 信 されるメッセージである 基 本 的 な 構 造 体 は ClientHello と 似 ているが ClientHello においてサイズが 可 変 な 変 数 であった CipherSuite と CompressionMethod はサーバが 値 を 決 定 し ServerHello には session_id 以 外 のサイズが 可 変 な 変 数 は 存 在 しない もし ClientHello で 示 されているものがサーバで 採 用 できない 場 合 は Alert プロトコルの handshake_failure で 応 答 する 準 備 : struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; opaque SessionID<0...32>; uint8 CipherSuit[2] 構 造 体 :struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suites; CompressionMethod compression_methods; } ClientHello; server_version ではクライアントが 示 したもののうち 自 分 が 採 用 できる 最 上 位 のバージ ョンを 示 す random はサーバ 側 で 生 成 した 乱 数 で ClientHello.random とは 異 なる 値 である session_id は ClientHello で 値 が 示 されている 場 合 はその 値 を 新 規 セッションを 示 して いる 場 合 は 新 たなセッション ID を 発 行 する また 空 で 返 すこともでき セッションの 再 利 用 ができないことを 示 す cipher_suites compression_methods は ClientHello で 示 されたリストのうち 採 用 する 20

22 ものを 返 答 する (4)Certificate(サーバ 側 から) このメッセージは cipher_suites で 匿 名 方 式 でない 鍵 交 換 方 式 を 採 用 するときに サーバ 証 明 書 として 送 信 される ServerHello の 直 後 に 送 信 され 次 のような 構 造 体 を 持 つ 準 備 : opaque ASN.1Cert<1...2^24-1>; 構 造 体 :struct { ASN.1Cert certificate_list<0...2^24-1>; } Certificate; certificate_list はそのサーバ 証 明 書 からルート 証 明 機 関 の 証 明 書 にいたるまでの X.509v3 証 明 書 のリストを 示 す (5)ServerKeyExchange このメッセージはサーバからの Certificate(このメッセージが 送 られない 匿 名 ネゴシエー ションのときは ServerHello)の 直 後 に 送 信 され premaster_secret を 送 信 するのに 必 要 となる 暗 号 情 報 として 使 用 される このメッセージは 以 下 の 構 造 体 を 持 つ ただし * マークは SSL でのみ 採 用 されている fortezza に 関 するパラメータである 準 備 : enum {rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm; struct { opaque RSA_modulus<1...2^16-1>; opaque RSA_exponent<1...2^16-1>; } ServerRSAParams; struct { opaque DH_p<1...2^16-1>; opaque DH_g<1...2^16-1>; opaque DH_Ys<1...2^16-1>; } ServerDHParams; *struct { opaque r_s[128]; } ServerFortezzaParams; 21

23 構 造 体 :struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params; Signature signed_params; case rsa: ServerRSAParams params; Signature signed_params; * case fortezza_kea: ServerFortezzaParams params; }; } ServerKeyExchange; params は 鍵 交 換 に 必 要 となるパラメータで rsa diffie_hellman は 公 開 値 を 示 している (fortezza は 省 略 ) signed_params は(ランダム 値 を 連 接 させた)params にハッシュをかけ それに 署 名 をし たものである この 構 造 体 に 関 しては 節 で 示 す (6)CertificateRequest このメッセージは クライアントに 証 明 書 を 要 求 するときに ServerKeyExchange(このメ ッセージを 送 信 していないときはサーバからの Certificate)の 直 後 に 送 信 され 次 の 構 造 体 を 持 つ ただし * マークは SSL でのみ 採 用 されているパラメータである 準 備 : enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), *rsa_ephemeral_dh(5), *dss_ephemeral_dh(6), *fortezza_missi(20), (255) } CertificateType; opaque DistinguishedName<1...2^16-1>; 構 造 体 :struct { CertificateType certificate_types<1...2^8-1>; DistinguishedName certificate_authorities<3...2^16-1>; } CertificateRequest; certificate_types は 要 求 される 証 明 書 の 種 類 のリストを 示 す certificate_authorities は 受 理 できる 認 証 局 の DistinguishedName のリストを 示 す 22

24 (7)ServerHelloDone このメッセージは ServerHello から CertificateRequest までのうち 送 信 すべきものを 送 信 し 終 わった 後 に 送 信 するメッセージである サーバはこのメッセージを 送 信 後 クライ アントからの 応 答 を 待 つ クライアントは このメッセージを 受 信 するまでに 受 け 取 った すべてのメッセージから 応 答 すべきパラメータを 計 算 し 返 信 する このメッセージは 次 のような 空 の 構 造 体 になっている struct {}ServerHelloDone; (8)Certificate(クライアント 側 から) ServerHelloDone を 受 信 した 後 にクライアントが 最 初 に 送 信 することのできるメッセージ で サーバから CertificateRequest を 受 信 したときのみ クライアントから Certificate を 送 信 できる サーバからの 要 求 に 適 合 する 証 明 書 を 所 持 していない 場 合 は このメッセージの 代 わりに Alert プロトコルの no_certificate メッセージで 応 答 する 構 造 体 は(4)で 示 したものと 同 じである 23

25 (9)ClientKeyExchange クライアントからの Certificate の 直 後 (これを 送 信 しないときは ServerHelloDone 受 信 直 後 )に 送 信 され premaster_secret を 設 定 する このメッセージは 次 の 構 造 体 になって いる ただし * マークは SSL でのみ 使 用 されるパラメータである struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; * case fortezza_kea: FortezzaKeys; } exchage keys; } ClientKeyExchange; RSA: struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; Diffie-Hellman: enum {implicit, explicit} PublicValueEncoding; struct { select (PublicValueEncoding){ case implicit: struct { }; case explicit: opaque dh_yc<1...2^16-1>; } dh_public; } ClientDiffieHellmanPublic; 注 :クライアント 側 からの Certificate に 既 に 適 切 な 鍵 が 記 載 されている 場 合 は implicit 鍵 を 送 信 する 必 要 があるときは explicit 24

26 (10)CertificateVerify ClientHello からこのメッセージの 直 前 で 送 受 信 されたメッセージ 全 部 に 署 名 をしたものを このメッセージとして 送 信 する このメッセージの 構 造 体 は 次 のようになる struct { Signature signature; } CertificateVerify; signature の 内 容 は 1.2.6, 節 参 照 のこと (11)Finished このメッセージはサーバ クライアントとも ChangeCipherSpec の 直 後 に 送 信 され Handshake プロトコルの 手 続 きが 完 了 したことを 示 す 構 造 体 は 節 参 照 Alert プロトコル Alert プロトコルは SSL(または TLS)で 何 らかの 異 常 状 態 が 起 きたときにその 内 容 と 重 大 さを 相 手 に 通 知 するためのものである このプロトコルが 送 受 信 されたときは その 重 大 さに 応 じた 異 常 手 続 きを 行 うことになる このプロトコルの 構 造 体 を 以 下 に 示 す 準 備 : enum {warning(1), fatal(2), (255)} AlertLevel; 構 造 体 :struct { Alertlevel level; AlertDescription } Alert; description; levelは この Alertの 重 大 さを 示 し fatalの 場 合 は 直 ちにセッションを 閉 じることになる warning の 場 合 はクライアント サーバの 裁 量 で 手 続 きを 決 定 する description は Alert の 内 容 を 示 し これは 節 に 書 かれているメッセージが 用 意 され ている このうち close_notify メッセージは このメッセージを 投 げたコネクションでこ れ 以 上 の 送 信 を 行 わないことを 通 知 するものであり それ 以 外 のメッセージがエラー 警 告 を 示 すメッセージとなる 25

27 ChangeCipherSpecプロトコル ChangeCipherSpec プロトコルは Handshake プロトコルでの 手 続 き 中 に 送 信 される これ は Handshake プロトコルでネゴシエーションがとれたパラメータをもとに CipherSpec(ま たは SecurityParameters)などが 設 定 されるので このメッセージを 送 信 することにより 以 後 の 通 信 はこのパラメータを 使 った SSL(または TLS) 通 信 を 行 うことになる この 構 造 体 は 以 下 に 示 す struct { enum {change_cipher_spec(1), (255)} type; } ChangeCipherSpec; 基 本 的 に change_cipher_spec という 値 のみを 持 つ 構 造 体 で これを 送 信 したあとはネゴシ エーションの 取 れたパラメータを 使 用 して 通 信 を 行 う Application Data プロトコル Application Data プロトコルは これまで 示 したプロトコル 以 外 のものすべてで 上 位 レ イヤから 送 られるアプリケーションなどのデータを 送 るものである これは 特 別 な 構 造 体 を 持 つものでなく 上 位 からのデータをそのまま Record Layer プロトコルに 送 ることにな っている 26

28 1.2. SSL 3.0/TLS 1.0 の 比 較 SSL3.0 SSL3.0 と TLS1.0 の 主 な 相 違 点 としては 共 有 する 鍵 や 初 期 値 の 生 成 関 数 が 異 な る 図 に SSL3.0 における 鍵 生 成 の 生 成 シーケンスの 概 要 を 示 す 鍵 共 有 メカニズム を 用 いて 作 成 された 鍵 (pre_master_secret)は 一 方 向 性 関 数 により Master_secret が 作 成 され 同 様 の 一 方 向 性 関 数 を 用 いて key_block を 作 成 する Key_block のビット 列 は ClientHello.random pre_master_secter OWF master_secter OWF SeverHello.random key_block 分 割 client_write_mac_secret server_write_mac_secret client_write_key server_write_key MAC 用 の 鍵 暗 号 化 用 の 鍵 client_write_iv server_write_iv non-export ClientHello.random SeverHello.random 図 final_client_write_key final_server_write_key client_write_iv server_write_iv SSL/TLS における 鍵 生 成 手 順 exportable exportable CBC 暗 号 化 用 の 初 期 値 輸 出 仕 様 暗 号 化 用 の 鍵 輸 出 仕 様 CBC 暗 号 化 用 の 初 期 値 27

29 6つの MAC 鍵 暗 号 鍵 CBC 初 期 値 を 生 成 する ただし 輸 出 仕 様 においては 暗 号 化 鍵 および 初 期 値 の 生 成 が 北 米 仕 様 (non-export)と 異 なる 点 に 留 意 する 必 要 がある 以 下 各 相 違 点 の 詳 細 について 述 べる 注 : 文 中 の + は 文 字 の 連 接 XOR は 排 他 論 理 和 を 表 す MAC(Message Authentication Code:メッセージ 認 証 符 号 ) SSL MAC = hash(mac_write_secret + pad_2 + hash(mac_write_secret + pad_1 + seq_num + SSLCompressed.type + SSLCompressed.length + SSLCompressed.fragment)) TLS MAC = HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)) [ 解 説 ] SSL/TLS での MAC の 機 能 は Record Layer で 実 際 に 送 信 するデータ メッセージ(M) とそれにハッシュ 関 数 をかけたもの(C)を 送 信 し 受 信 側 で 受 信 したデータ メッセージ (M)にハッシュ 関 数 をかけ これと 受 信 したメッセージ(C)と 比 較 することで 改 ざん があったことを 発 見 するものである SSL/TLS とも 秘 密 鍵 に 相 当 する MAC_write_secret を 用 いてデータ メッセージをハッシ ュ 化 している SSLの MACの 計 算 は NMACのスキームと 同 一 の 方 式 となっており NMAC と 同 等 の 安 全 性 があるものと 考 えられる[27] 注 :SSL における MAC_write_secret は 後 述 の 節 で 示 されている key_block の write_mac_secret に 相 当 する TLS では RFC2104 に 規 定 された HMAC アルゴリズムを 使 用 している HMAC は NMAC アルゴリズムから 考 え 出 されたもので[27] HMAC の 安 全 性 は 使 用 しているハッシュ 関 数 の 安 全 性 に 依 存 しており そのハッシュ 関 数 が 安 全 であれば HMAC も 安 全 であること birthday attack への 耐 性 があることが RFC で 述 べられている 注 :HMAC HMAC_hash(secret, message) = hash(((secret + pad) XOR opad) + hash(((secret + pad) XOR ipad) + message)) pad: 指 定 バイト 列 を 作 るように secret の 終 わりまでゼロを 追 加 する 28

30 ipad: opad: 0x36 を 指 定 バイト 列 分 繰 り 返 した 文 字 列 0x5C を 指 定 バイト 列 分 繰 り 返 した 文 字 列 29

31 master_secret の 計 算 SSL master_secret = MD5(pre_master_secret + SHA( A + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA( BB + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA( CCC + pre_master_secret + ClientHello.random + ServerHello.random)) TLS master_secret = PRF(pre_master_secret, master secret, [ 解 説 ] ClientHello.random + ServerHello.random) master_secret は 後 述 する 鍵 の 計 算 や Handshake プロトコルなどで 使 用 される この 値 は SSL/TLS 共 に pre_master_secret ClientHello.random ServerHello.random の 値 か ら 48 バイト 列 の 数 値 が 導 出 される 導 出 関 数 において 相 違 点 がある SSL は 上 記 3 つの 値 および A BB CCC の 文 字 列 を 用 い ハッシュ 関 数 MD5 また は SHA で 計 算 したものを 連 接 することで master_secret を 導 出 している TLS は 新 たに 定 義 した 疑 似 乱 数 関 数 PRF を 定 義 し 上 記 3 つの 値 および master secret の 文 字 列 から master_secret を 導 出 している PRF を 説 明 するのに まず 次 の 関 数 を 定 義 する P_hash(a,b)=HMAC_hash(a,A(1)+b)+ HMAC_hash(a, A(2) + b) + ただし A(0) = b A(i) = HMAC_hash(a, A(i-1)) P_hash は 必 要 な 長 さのデータを 生 成 するまで 計 算 する 必 要 な 長 さの 出 力 が 得 られないと きは その 長 さを 超 えるまで 計 算 し 初 めて 超 えた 出 力 値 の 下 位 バイト 列 を 切 り 捨 てる この P_hash を 用 いて PRF は 次 のように 定 義 される PRF(secret, label, seed) =P_MD5(S1, label + seed) XOR P_SHA(S2, label + seed) ただし secret = S1 + S2 かつ S1 と S2 は 同 バイト 長 TLS では 48 バイト 列 の 数 値 を 作 成 するので PRF に 用 いられる P_MD5 P_SHA の 計 算 は それぞれ HMAC 処 理 を 3 回 繰 り 返 している 30

32 key_block 計 算 SSL key_block = MD5(master_secret + SHA( A + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA( BB + master_secret + ServerHello.random + ClientHello.random)) + MD5(master_secret + SHA( CCC + master_secret + ServerHello.random + ClientHello.random)) TLS key_block = PRF(master_secret, key expansion, SecurityParameters.server_random + SecurityParameters.client_random) [ 解 説 ] key_block は 次 の 6 種 類 の 値 を 得 るために 使 われる 値 である client_write_mac_secret[cipherspec.hash_size / SecurityParameters.hash_size] server_write_mac_secret[cipherspec.hash_size / SecurityParameters.hash_size] client_write_key[cipherspec.key_material / SecurityParameters. key_material_length] server_write_key[cipherspec.key_material / SecurityParameters. key_material_length] client_write_iv[cipherspec.iv_size] -- non-export server_write_iv[cipherspec.iv_size] --non-export 注 : 上 記 の[ ] 内 の 表 記 は SSL の 場 合 の それぞれの 値 のバイト 長 を 表 す TLS の 場 合 は CipherSpec SecurityParameters key_material key_material_length と 読 み 替 えること SecurityParameters.IV_size というメンバは 存 在 しない(1.2.9 節 参 照 ) また 最 後 二 つは non-export cipher のためにのみ 生 成 される Exportable の 場 合 は 節 を 参 照 のこと key_block を 上 記 6 種 類 の 値 になるように 仕 切 り 余 分 な 部 分 を 切 り 捨 てる この key_block の 導 出 関 数 に 相 違 点 がある SSL は master_secret ServerHello.random ClientHello.random および A BB CCC ( 以 下 必 要 分 だけ 続 く)の 文 字 列 を 用 い ハッシュ 関 数 MD5 または SHA で 計 算 したものを 連 接 することで key_block を 導 出 している 31

33 TLSは 疑 似 乱 数 関 数 PRFを 用 いて master_secret SecurityParameters.server_random SecurityParameters.client_random および key expansion の 文 字 列 から key_block を 導 出 している final_client_write_key および final_server_write_key の 計 算 SSL final_client_write_key = MD5(client_write_key + ClientHello.random + ServerHello.random) final_server_write_key = MD5(server_write_key + ServerHello.random + ClientHello.random) TLS final_client_write_key = PRF(client_write_key, client write key, SecurityParameters.client_random + SecurityParameters.server_random) final_server_write_key = PRF(server_write_key, server write key, SecurityParameters.client_random + SecurityParameters.server_random) [ 解 説 ] 本 計 算 は exportable が 指 定 されたときにのみ 付 加 的 に 処 理 される final_client_write_key final_server_write_key は 実 際 に 暗 号 鍵 として 使 用 される これらの 値 を 計 算 する 導 出 関 数 に 相 違 点 がある SSL は client_write_key ( または server_write_key ) ServerHello.random ClientHello.random を 用 い ハッシュ 関 数 MD5 で 計 算 し それぞれの 値 を 導 出 している TLS は 疑 似 乱 数 関 数 PRF を 用 いて client_write_key(または server_write_key) SecurityParameters.server_random SecurityParameters.client_random および client write key(または server write key) の 文 字 列 からそれぞれの 値 を 導 出 している 32

34 Exportable encryption algorithms 使 用 時 の client_write_iv および server_write_iv の 計 算 SSL client_write_iv = MD5(ClientHello.random + ServerHello.random) server_write_iv = MD5(ServerHello.random + ClientHello.random) TLS iv_block = PRF(, IV block, SecurityParameters.client_random + [ 解 説 ] iv_block = client_write_iv +server_write_iv ただし client_write_iv, server_write_iv 共 に SecurityParameters.IV_size バイト 長 SecurityParameters.server_random) Exportable encryption algorithms 使 用 時 は client_write_iv および server_write_iv を key_block とは 別 に 計 算 する 本 IV の 計 算 には master_secret は 用 いられていない こ のため セッションをタッピングする 第 3 者 が IV を 計 算 することが 可 能 である 点 で non-export より 安 全 性 が 劣 ると 考 えられる これらの 値 を 計 算 する 導 出 関 数 に 相 違 点 があ る SSL は ServerHello.random ClientHello.random を 用 い ハッシュ 関 数 MD5 で 計 算 し それぞれの 値 を 導 出 している TLS は 疑 似 乱 数 関 数 PRF を 用 いて SecurityParameters.server_random SecurityParameters.client_random および IV block の 文 字 列 からからそれぞれの 値 を 導 出 している このとき 関 数 PRF の 第 一 入 力 値 はゼロバイト 長 の 文 字 を 表 す 33

35 ServerKeyExchange メッセージの Signature の 構 造 体 SSL digitally-signed struct { TLS [ 解 説 ] select (SignatureAlgorithm){ }; case anonymous: struct{ }; case case } Signature rsa: opaque opaque dsa: opaque md5_hash[16]; sha_hash[20]; sha_hash[20]; select (SignatureAlgorithm){ case anonymous: struct {}; case }; case }; rsa: digitally-signed struct { dsa: } Signature; opaque opaque md5_hash[16]; sha_hash[20]; digitally-signed struct { opaque sha_hash[20]; ServerKeyExchange メッセージにおいて 署 名 アルゴリズムを 選 択 する 個 所 がある この アルゴリズムの 違 いにより md5_hash = MD5(ClientHello.random + ServerHello.random + ServerParams); sha_hash = SHA(ClientHello.random + ServerHello.random + ServerParams); enum {anonymous, rsa, dsa} SignatureAlgorithm; を 使 用 して 署 名 を 行 うが この 構 造 体 に 相 違 点 がある SSL では digitally-signed が 最 上 位 の 構 造 であるため 署 名 アルゴリズムが anonymous の 際 には 空 の 値 に 署 名 を 行 う 形 になり 署 名 アルゴリズム 上 問 題 になる 危 険 がある 34

36 この 問 題 を 回 避 するため TLS ではまず 署 名 アルゴリズムに 依 存 して digitally-signed の 要 否 を 指 定 できるようになっており anonymous の 場 合 に 空 の 値 に 署 名 を 行 わない CertificateVerify メッセージで 使 用 されるハッシュ 計 算 SSL CertificateVerify.signature.md5_hash = MD5(master_secret + pad_2 + MD5(handshake_messages + master_secret + pad_1)) CertificateVerify.signature.sha_hash = SHA(master_secret + pad_2 + SHA(handshake_messages + master_secret + pad_1)) TLS CertificateVerify.signature.md5_hash = MD5(handshake_messages) CertificateVerify.signature.sha_hash = SHA(handshake_messages) [ 解 説 ] CertificateVerify メッセージは 節 の signature 構 造 に 基 づいて 署 名 され クライア ント 証 明 書 の 検 証 を 行 うのに 使 用 される ClientHello からこのメッセージを 送 信 するまで の(CertificateVerify を 除 く) 送 受 信 されたすべての Handshake プロトコルメッセージを 連 鎖 したものを handshake_messages とし このメッセージをハッシュ 関 数 にかけて 署 名 を 行 う このときハッシュ 関 数 での 計 算 方 法 に 相 違 点 がある SSL は handshake_messages mastersecret(および pad_1 pad_2)を 用 いて 上 記 の 計 算 を 行 う TLS では 得 られた 値 に 署 名 を 施 した 物 が CertificateVerify メッセージとなることから master_secret を 連 接 する 必 要 がないことから 単 純 に handshake_messages のみをハッ シュ 関 数 にかける 演 算 に 変 更 されている 35

37 Finished メッセージ SSL struct { opaque opaque } Finished; TLS struct { [ 解 説 ] md5_hash[16]; sha_hash[20]; md5_hash = MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1)) sha_hash = SHA(master_secret + pad2 + ただし Sender = opaque } Finished; SHA(handshake_messages + Sender + master_secret + pad1)) Sender.client(クライアント 送 信 時 ) または Sender.server(サーバ 送 信 時 ) verify_data[12] verify_data = PRF(master_secret, finished_label, MD5(handshake_messages) + SHA(handshake_messages)) ただし finished_label = client finished (クライアント 送 信 時 ) または server finished (サーバ 送 信 時 ) Finished メッセージは 鍵 交 換 と 認 証 処 理 が 成 功 したことを 確 認 する ClientHello からこ のメッセージを 送 信 するまでの(Finished を 除 く) 送 受 信 されたすべての Handshake プ ロトコルメッセージを 連 結 したものを handshake_messages とし このメッセージから Finished メッセージを 導 出 する このときメッセージに 使 用 される 構 造 体 メンバの 個 数 お よび 計 算 に 使 用 する 導 出 関 数 に 相 違 点 がある SSL は 2 つのメンバを 持 ち handshake_messages mastersecret Sender(および pad1 pad2)を 用 いて 上 記 の 計 算 を 行 う TLS は 1 つのメンバを 持 ち handshake_messages mastersecret finished_label を 用 いて 上 記 の 計 算 を 行 う 36

38 CipherSpec(SSL)と SecurityParameters(TLS) SSL enum {stream, block} CipherType; enum {true, false} IsExportable; /* Exportable な 暗 号 方 式 か 否 か */ * enum {null, rc4, rc2, des, 3des, des40, fortezza } BulkCipherAlgorithm; enum {null, md5, sha} MAC Algorithm; struct { BulkCipherAlgorithm bulk_cipher_algorithm; MACAlgorithm mac_algorithm; CipherType cipher_type; IsExportable is_exportable; uint8 hash_size; * uint8 key_material; * uint8 IV_size; } CipherSpec; TLS * enum {null(0), (255)} CompressionMethod; * enum {server, client} ConnectionEnd; * enum {null, rc4, rc2, des, 3des, des40, idea} BulkCipherAlgorithm; enum {stream, block} CipherType; enum {true, false} IsExportable; /* Exportable な 暗 号 方 式 か 否 か */ enum {null, md5, sha} MACAlgorithm; struct { ConnectionEnd entity; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 key_size; * uint8 key_material_length; IsExportable is_exportable; MACAlgorithm mac_algorithm; uint8 hash_size; CompressionMethod compression_algorithm; * opque master_secret[48]; * opaque client_random[32]; * opaque server_random } SecurityParameters; 37

39 [ 解 説 ] CipherSpec と SecurityParameters はそれぞれ SSL/TLS による 通 信 において 使 用 される 暗 号 の 方 式 や 鍵 計 算 用 数 値 を 規 定 するものである それぞれの 構 造 体 において 相 違 点 が ある(またはどちらか 一 方 のみ 規 定 されている)メンバを 上 記 に 示 す( 相 違 点 のあるとこ ろに マークが 施 されている) BulkCipherAlgorithm で 規 定 される 暗 号 方 式 のうち SSL は 値 fortezza が 用 意 されて いるが TLS では fortezza をサポートしていないのでこの 値 は 存 在 しない TLS では 暗 号 方 式 IDEA に 予 め 対 応 できるように 値 idea が 用 意 されている SSL での key_material と TLS の key_material_length は 同 じ 用 途 で 用 いられている (1.2.3 節 参 照 ) TLS のみ 設 定 されている 値 のうち ConnectionEnd はクライアントかサーバかを 示 してお り SSL にはこれに 相 当 する 物 はない master_secret は SSL でも 計 算 され 用 いられて いる(1.2.2 節 参 照 ) client_random server_random compression_algorithm に 関 し ても SSL では ClientHello ServerHello で random の 数 値 や CompressionAlgorithm が 規 定 されている SSL のみ IV_size の 項 目 があり TLS には 規 定 されていない ただし TLS でも IV_size に 依 存 する 項 目 がある(1.2.3 節 参 照 ) 38

40 Alert プロトコル 両 方 式 unexpected_message(10), bad_record_mac(20), decompression_failure(30), handshake_failure(40), illegal_parameter(47)( 以 上 常 に fatal) SSL TLS [ 解 説 ] close_notify(0), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46)(warning または fatal) no_certificate(41)(warning または fatal) decryption_failed(21), record_overflow(22), unknown_ca(48), access_denied(49), decode_error(50), export_restriction(60), protocol_version(70), insufficient_security(71), internal_error(80) ( 以 上 常 に fatal) no_renegotiation(100)( 常 に warning) user_canceled(90) ( 一 般 的 に warning) decrypt_error(51)(warning または fatal) SSL/TLS においてなんらかのトラブルが 発 生 したときに それを 通 知 するものとして Alert プロトコルがある これは 節 で 示 す 構 造 体 を 持 ち どういった 障 害 が 発 生 したかを warning レベル fatal レベルと 合 わせて 示 してある 上 記 で 示 した 相 違 点 は 節 における AlertDescription に 関 する 物 である SSL で no_certificate とされていたものを TLS ではさらに 細 分 化 してトラブルの 原 因 を 特 定 しや すくなっている このとき AlertLevel が fatal となっているものは 常 にコネクションが 閉 鎖 される warning レベルのものは コネクションを 閉 鎖 するかどうかはクライアント またはサーバの 裁 量 で 決 めてよい また 常 に AlertLevel が 決 まっているものを 除 いて AlertLevel が 示 されていない Alert に 関 しては クライアントまたはサーバの 裁 量 で fatal または warning を 決 定 できる 39

41 その 他 SSL TLS Fortezza サポート IDEA の 記 述 なし Protocol Version = 3.0 Fortezza 非 サポート IDEA の 記 述 あり Protocol Version = 3.1 [ 解 説 ] その 他 で SSL と TLS とでは 上 記 の 相 違 点 がある 暗 号 方 式 Fortezza は SSL まではサポートされていたが TLS ではサポートされていない 暗 号 方 式 IDEA は SSL の Draft では 記 述 がないが TLS の RFC では 記 述 されている 個 所 がある(1.2.9 節 参 照 ) ただし これは Draft/RFC に 記 述 されているかされていない かだけの 問 題 であり SSL で IDEA がサポートされないわけではない 例 えば Apache-SSL では 規 定 されている 方 式 以 外 の 暗 号 方 式 も 後 から 組 み 込 むことができるという SSL プロ トコルの 性 質 を 利 用 して IDEA をサポートしている Protocol Version は SSL では 3.0 TLS では 3.1 となる Handshake プロトコルにおいて も ClientHello ServerHello で 示 されるバージョンの 上 限 は 上 記 の 値 となる 40

42 1.3. TLS 拡 張 作 業 の 概 要 TLS 拡 張 作 業 の 推 移 を 図 に 示 す 図 TLS 拡 張 作 業 の 推 移 41

43 TLS の 拡 張 作 業 は A)ワイヤレス モバイル 環 境 への 対 応 B) 新 規 暗 号 アルゴリズム の 追 加 C) 認 証 鍵 交 換 手 法 のバリエーション 追 加 D)プロトコルの 拡 張 に 大 別 され る TLS 自 身 については 現 在 も 改 訂 作 業 を 継 続 しており 2002 年 2 月 にドラフトが 発 表 される 予 定 である 以 下 各 拡 張 の 内 容 について 説 明 する 機 能 拡 張 [draft-ietf-tls-extensions-02] TLS Extensions 発 行 日 : 2001 年 12 月 さまざまな TLS 拡 張 方 法 のまとめたものである 本 ドラフトは draft-ietf-tls-wireless-00 をベースにして 内 容 を 拡 張 したものであり 携 帯 電 話 などのモバイル 環 境 ワイヤレス 通 信 での 使 用 や 仮 想 ホストへの SSL アクセス OCSP(Online Certificate Status Protocol) を 使 用 したサーバ 証 明 書 失 効 情 報 要 求 などを 規 定 している 以 下 にその 詳 細 を 記 述 する (1) Helloメッセージの 拡 張 以 下 の 様 々な 拡 張 によって 必 要 となるパラメータを 交 換 するために Client Hello 及 び Server Hell oをそれぞれ 以 下 のように 拡 張 する Client Hello struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-1>; CompressionMethod compression_methods<1..2^8-1>; Extension client_hello_extension_list<0..2^16-1>; } ClientHello; 42

44 Server Hello struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; Extension server_hello_extension_list<0..2^16-1>; } ServerHello; すなわち 各 Hello メッセージ 中 に 拡 張 パラメータの 記 述 領 域 Extension client_hello_ extension_list 及 び Extension server_hello_extension_list を 設 ける 拡 張 パラメータは 以 下 のように 記 述 する struct { ExtensionType extensiontype; opaque extension_data<0..2^16-1>; } Extension; 上 記 パラメータ 内 の Extension Type は 以 下 のように 記 述 する enum { server_name(0), max_fragment_size(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), (65535) } ExtensionType; 43

45 (2) ハンドシェイクプロトコル ハンドシェイクプロトコルに 後 述 の(5)に 対 応 するための CertificateURL と (8) に 対 応 するための CertificateStatus という 2 つのプロトコルを 追 加 する 従 って Handshake の 構 造 体 は 以 下 のようになる enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange( 16), finished(20), certificate_url(21), certificate_status(22), (255) } HandshakeType; struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* bytes in message */ select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case cli ent_key_exchange: ClientKeyExchange; case finished: Finished; case certificate_url: CertificateURL; case certificate_status: CertificateStatus; } body; } Handshake; 44

46 (3) Server name Indication 仮 想 ホストへのアクセスを 可 能 にするために client から ServerName を 送 信 できるよう に 拡 張 する Servername は client hello メッセージ 中 の Extension Type を server_name とし extension_data フィールドに 以 下 のような ServerNameList を 含 める これにより アドレスとサーバ 名 とでアクセス 対 象 を 特 定 できるため 1つのアドレスに 対 して 複 数 の Server を 稼 働 させることが 可 能 となる struct { NameType name_type; select (name_type) { case host_name: HostName; } } ServerName; enum { host_name(0), (255) } NameType; opaque HostName<1..2^16-1>; struct { ServerName server_name_list<1..2^16-1> } ServerNameList; (4) Maximum Fragment Size Negotiation ナローバンドなワイヤレス 環 境 に 対 応 するため 送 受 信 データのフラグメントサイズの 最 大 値 を 可 変 とする レコードサイズは Client Hello メッセージ 中 の Extension Type を max_fragment_size とし extension_data に 以 下 のように 記 述 する enum{ 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) } MaxFragmentSize; 45

47 (5) Client Certificate URLs モバイル 環 境 (WPKI:Wireless PKI) 等 への 適 用 を 考 慮 して Client の 証 明 書 をインター ネット 上 の Server から 取 得 できるように 拡 張 が 行 う Client Hello メッセージ 中 の Extension Type を client_certificate_url とし extension_data は 使 用 しない また Client は Certificate に 代 わりに CertificateURL メッセージを 送 信 する Server は この url 先 にアクセスし Clientの 証 明 書 を 取 得 する CertificateURLのメッセージフォーマットは 以 下 の 通 り struct { URLAndHash url_and_hash_list<1..2^16-1>; } CertificateURL; struct { opaque URL<1..2^16-1>; CertHash certificate_hash; } URLAndHash; opaque CertHash< 0..20>; (6) Trusted CA Indication 携 帯 端 末 などのモバイル 環 境 では 所 有 する CA のルート 鍵 が 限 定 されるため Client が 検 証 可 能 なルート 鍵 を Server に 通 知 する 必 要 がある 従 って Client Hello メッセージ 中 の Extension Type を trusted_ca_keys とし extension_data フィールドに 以 下 のメッセージ を 含 め 送 信 する Server は 送 られてきたリストに 対 応 する 証 明 書 を 返 信 するか エラー を 通 知 する struct { TrustedAuthority trusted_authorities_list<0..2^16-1>; } TrustedAuthorities; struct { IdentifierType identifier_type; select (identifier_type) { case pre_agreed: struct {}; case key_ha sh_sha: KeyHash; case x509_name: DistinguishedName; 46

48 case cert_hash: CertHash; } Identifier; } TrustedAuthority; enum { pre_agreed(0), key_hash_sha(1), x509_name(2), cert_hash(3), (255)} IdentifierType; opaque DistinguishedName<1..2^16-1>; opaque KeyHash[20]; (7) Truncated HMAC モバイル 環 境 等 での 利 用 を 考 慮 して HMAC 値 を 80bit に 縮 小 できるよう 拡 張 する Truncated HMAC を 使 用 する 場 合 には Client Hello メッセージ 中 の Extension Type を truncated_hmac とし extension_data は 空 とする (8) Certificate Status Request Client が OCSP を 用 いて Server の 証 明 書 の 失 効 状 態 を 確 認 できるように 拡 張 を 行 う Server は Client のリクエストに 対 して OCSP を 取 得 し 証 明 書 と 共 に 返 信 する OCSP のパラメータは Client Hello メッセージ 中 の Extension Type を status_request とし extension_data に 以 下 のような CertificateStatusRequest の 内 容 を 記 述 する struct { CertificateStatusType status_type; select (status_type) { case ocsp: OCSPStatusRequest; } } CertificateStatusRequest; enum { ocsp(1), 255) } CertificateStatusType; struct { Respond erid responder_id_list<0..2^16-1>; Extensions request_extensions; } OCSPStatusRequest; 47

49 opaque ResponderID<1..2^16-1>; opaque Extensions<0..2^16-1>; これに 対 し Server は Server Hello として Extension Type を status_request とし extension_data を 空 にしたメッセージを 返 す また Server は Certificate メッセージの 後 に CertificateStatus メッセージを 送 信 する CertificateStatus は 以 下 のように 記 述 す る struct { CertificateStatusType status_type; select (status_type) { case ocsp: OCSPResponse ocsp_response; } } CertificateStatus; opaque OCSPResponse<1..2^24-1>; [draft-ietf-tls-rfc2246-bis-05] The TLS Protocol Version 1.1 発 行 日 : 2003 年 6 月 現 在 策 定 中 CBC モードのサイドチャネル 攻 撃 に 対 する 対 策 PKCS#1(v.1.5)に 対 する 適 用 的 選 択 暗 号 文 攻 撃 に 対 する 対 策 D.Brumley らのタイミング 攻 撃 に 対 する 対 策 非 推 奨 暗 号 の 追 加 (40bits の 共 通 鍵 512bits の 署 名 鍵 )などのセキュリティ 向 上 を 意 図 した 改 定 作 業 が 中 心 となっている 48

50 認 証 方 式 の 拡 張 [draft-ietf-tls-attr-cert-00] TLS extensions for AttributeCertificate based authorization 発 行 日 : 1998 年 2 月 ハンドシェイクにおいて 属 性 証 明 書 (Attribute Certificate)をベースにした 認 証 を 行 うた めの TLS の 拡 張 方 法 を 記 述 している CertificateRequest を ACRequest に CertificateResponse を ACInfo に 置 き 換 えることで クライアントの Attribute Certificate を 送 信 する [draft-ietf-tls-delegation-01] TLS Delegation Protocol 発 行 日 : 2001 年 7 月 TLS を 使 用 して 代 理 証 明 書 (Proxy Certificate)または Kerberos 5 forwardable ticket の 委 譲 (delegation)を 行 うためのプロトコル 規 定 と そのための TLS の 拡 張 方 法 を 記 述 してい る TLS Record layer の 上 位 に TLS Delegation Protocol を 定 義 する [draft-ietf-tls-kerb-01] Kerberos Cipher Suites in Transport Layer Security (TLS) 発 行 日 : 2001 年 11 月 クライアントからサーバへの Kerberos チケット 委 譲 (delegation)をサポートするよう RFC2712 をアップデートしたものである CertificateRequest メッセージにサーバは realm name または forwarded ticket などの attribute を 含 める それに 対 して クライ アントの Certificate メッセージには delegated credential を 配 送 するための Kerberos KRB-CRED メッセージを 含 める 49

51 鍵 共 有 方 式 の 拡 張 [draft-ietf-tls-openpgp-01] Extensions to TLS for OpenPGP keys 発 行 日 : 2001 年 3 月 OpenPGP で 使 用 されている 証 明 書 公 開 鍵 アルゴリズム 共 通 暗 号 アルゴリズム ハッシ ュアルゴリズム 信 頼 モデルをサポートするよう TLS を 拡 張 する Certificate において 公 開 鍵 証 明 書 内 に OpenPGP 鍵 を 含 めるか 鍵 IDを 送 信 することにより 鍵 共 有 を 実 現 する cipher suites の 記 述 方 法 は 以 下 のとおり CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_SHA = { 0x01, 0x01 }; CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_SHA = { 0x01, 0x02 }; CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x03 }; CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_RMD = { 0x01, 0x04 }; CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_RMD = { 0x01, 0x05 }; CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x06 }; CipherSuite TLS_PGP_DHE_RSA_WITH_CAST_CBC_SHA = { 0x01, 0x10 }; CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_SHA = { 0x01, 0x20 }; CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_SHA = { 0x01, 0x21 }; CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x22 }; CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_RMD = { 0 x01, 0x23 }; CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_RMD = { 0x01, 0x24 }; CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x25 }; CipherSuite TLS_PGP_DSA_WITH_NULL_SHA = { 0x01, 0xF0 }; [draft-ietf-tls-srp-01] Using SRP for TLS Authentication 発 行 日 : 2001 年 6 月 SRP(Secure Remote Password)に 基 づいた 認 証 を TLS において 行 うための 拡 張 方 法 を 記 述 する 従 来 のユーザ ID/パスワードによる 認 証 を 利 用 しているアプリケーションにおいて 安 全 にこれらを 交 換 し さらに TLS を 利 用 して 通 信 データの 保 護 を 行 う Client Hello 中 にユーザ 名 と MD 値 のリストを 送 信 し Server Hello で サーバが 選 択 した MD 値 を 返 す この 値 と SRP パスワードファイルを 元 に pre-master 鍵 は 計 算 される cipher suites の 記 述 方 法 は 以 下 のとおり 50

52 CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_SHA = { 0x00,0x5B }; CipherSuite TLS_SRP_WITH_RC4_128_SHA = { 0x00,0x5C }; CipherSuite TLS_SRP_WITH_IDEA_CBC_SHA = { 0x 00,0x5D }; CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x5E }; CipherSuite TLS_SRP_WITH_RC4_128_MD5 = { 0x00,0x5F }; CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x60 }; [draft-ietf-tls-sharedkeys-02] Using SRP for TLS Authentication 発 行 日 : 2003 年 10 月 事 前 共 有 鍵 を 使 用 することで 公 開 鍵 暗 号 処 理 を 不 要 とする 方 式 について 記 述 している 具 体 的 には 事 前 共 有 鍵 などの 秘 密 共 有 情 報 から PRF(pseudorandom function)を 使 用 して master secret を 生 成 する 方 法 を 以 下 のように 定 めている master_secret = PRF(shared_secret, "shared secret", "")[0..47] 暗 号 方 式 の 拡 張 [draft-ietf-tls-56-bit-ciphersuites-01] 56-bit Export Cipher Suites For TLS 発 行 日 : 2001 年 7 月 56 ビット 暗 号 を 使 用 した cipher suites を TLS に 追 加 する 先 のドラフトである draft-ietf-tls-56-bit-ciphersuites-00 を2 年 半 ぶりにアップデートしたもので cipher suites の 追 加 削 除 を 行 っている 追 加 された cipher suites は 以 下 のとおり CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }; CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }; CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 }; CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }; CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }; 51

53 [draft-ietf-tls-seedhas-00] TLS Extension for SEED and HAS-160 発 行 日 : 2000 年 7 月 韓 国 の TTA が 制 定 したブロック 暗 号 SEED とハッシュアルゴリズム HAS-160 を TLS の cipher suites に 追 加 する cipher suites の 記 述 方 法 は 以 下 のとおり CipherSuite TLS_RSA_WITH_SEED_CBC_MD5 = { 0x00, 0x2C }; CipherSuite TLS_RSA_WITH_SEED_CBC_SHA = { 0x00, 0x2D }; CipherSuite TLS_RSA_WITH_SEED_CBC_HAS160 = { 0x00, 0x2E }; [draft-ietf-tls-misty1-01] Addition of MISTY1 to TLS 発 行 日 : 2001 年 3 月 三 菱 電 機 が 開 発 したブロック 暗 号 MISTY1 を TLS の cipher suites に 追 加 する cipher suites の 記 述 方 式 は 以 下 のとおり CipherSuite TLS_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x3B }; CipherSuite TLS_DH_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x3C }; CipherSuite TLS_DH_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x3D }; CipherSuite TLS_DHE_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x3E }; CipherSuite TLS_DHE_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x3F }; CipherSuite TLS_DH_anon_WITH_MISTY1_CBC_SHA = { 0x00,0x40 }; [draft-ietf-tls-camellia-01] Addition of the Camellia Encryption Algorithm to TLS 発 行 日 : 2001 年 5 月 NTT と 三 菱 電 機 で 共 同 開 発 されたブロック 暗 号 Camellia を TLS の cipher suites に 追 加 す る cipher suites の 記 述 方 式 は 以 下 のとおり CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x41 }; CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x42 }; CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x43 }; CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x44 }; 52

54 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x45 }; CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA = { 0x00,0x46 }; CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x47 }; CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x48 }; CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x49 }; CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x4A }; CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x4B }; CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA = { 0x00,0x4C }; [draft-ietf-tls-ciphersuite-06] AES Ciphersuites for TLS 発 行 日 : 2002 年 1 月 DES の 後 継 である AES(Advanced Encryption Standard)を TLS の cipher suites に 追 加 す る cipher suites の 記 述 方 式 は 以 下 のとおり CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0 x34 }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; 53

55 [draft-ietf-tls-ecc-01] ECC Cipher Suites for TLS 発 行 日 : 2001 年 3 月 楕 円 曲 線 暗 号 (Elliptic Curve Cryptography:ECC)を 署 名 (ECDSA) 及 び 鍵 交 換 (ECDH)と して 使 用 するための TLS のプロトコル 拡 張 と cipher suites の 追 加 を 行 う cipher suites の 記 述 方 式 は 以 下 のとおり CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x4B } CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x4C } CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x4D } CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x4E } CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA = { 0x00, 0x4F } CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x50 } CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x51 } CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x52 } CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x53 } CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x54 } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x55 } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x56 } CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x57 } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x58 } CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x59 } CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5A } 54

56 [draft-ietf-tls-ntru-00] NTRU Cipher Suites for TLS 発 行 日 : 2001 年 7 月 公 開 鍵 暗 号 方 式 である NTRU 暗 号 アルゴリズムと これを 使 用 した NSS 署 名 アルゴリズ ムを 鍵 交 換 方 式 として 使 用 するための TLS のプロトコル 拡 張 と cipher suites の 追 加 を 行 う Cipher suites の 記 述 方 式 は 以 下 のとおり CipherSuite TLS_NTRU_NSS_WITH_RC4_128_SHA = { 0x00, 0x61 } CipherSuite TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x62 } CipherSuite TLS_NTRU_NSS_WITH_AES_128_CBC_SHA = { 0x00, 0x63 } CipherSuite TLS_NTRU_NSS_WITH_AES_256_CBC_SHA = { 0x00, 0x64 } CipherSuite TLS_NTRU_RSA_WITH_RC4_128_SHA = { 0x00, 0x65 } CipherSuite TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x66 } CipherSuite TLS_NTRU_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x67 } CipherSuite TLS_NTRU_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x68 } その 他 [draft-ietf-tls-pathsec-00] TLS Pathsec Protocol 発 行 日 : 2001 年 9 月 TLS セションを 複 数 のサブセションに 分 割 し 3 つのチャネルを 使 用 することで クライ アントとサーバの 間 に 複 数 の 中 継 者 (intermediary)の 介 在 を 可 能 とする Client Hello 及 び Server Hello の Pathsec パラメータを 追 加 し Alert メッセージについても 追 加 を 行 う 55

57 2. SSL における 既 存 セキュリティホールとその 対 策 について 本 章 では SSL における 既 存 のセキュリティホール(あるいは 注 意 点 )について 1 暗 号 方 式 上 2プロトコル 上 3 実 装 上 4 運 用 上 の4つの 角 度 から 調 査 分 析 を 行 った こ こで 1 暗 号 方 式 2プロトコル 上 のセキュリティホールとは 方 式 の 仕 様 上 の 問 題 でセ キュリティホールとなりえるもので その 中 でも 純 粋 に 暗 号 方 式 に 関 連 するものを1に man-in-the-middle のような 通 信 に 関 わる 両 エンティティが 関 与 するプロトコル 手 順 上 の 問 題 について2に 分 類 した また3は 機 能 実 装 の 際 生 じる 問 題 で 主 に 不 具 合 と 考 え られる 4については SSL を 動 作 させる 際 に 指 定 可 能 な 構 成 情 報 やオペレーションなど に 関 する 問 題 に 類 する これらの1~4については その 被 害 影 響 の 重 大 さを 考 えると 重 要 度 の 優 劣 をつけるのは 困 難 と 考 える 2.1. 暗 号 方 式 上 のセキュリティホールとその 対 策 DSA のセキュリティホール 2000 年 11 月 IEEE P1363のworking groupの 会 合 において Bell Labの Bleichenbacher は DSA 署 名 方 式 において 各 々のメッセージに 対 して 乱 数 である 秘 密 鍵 を 生 成 する 際 に 偏 りがあることを 指 摘 した 本 偏 りは ある 特 定 の 領 域 から 選 択 する 可 能 性 は 他 の 領 域 に くらべて 高 い 出 現 確 立 となっていることが 判 明 し DSA の 強 度 を 著 しく 弱 めることを 指 摘 した 本 来 生 成 されるいかなる 乱 数 も 指 定 された 領 域 内 で 均 一 (uniform)であるべきで あるが DSA の 乱 数 生 成 なそうではなかった Bleichenbacher は DSS の Annex を 解 析 している 際 に 本 flaw を 発 見 するとともに 修 正 案 を 提 示 している( 詳 細 は 以 下 を 参 考 ) 本 flaw は 直 ちに 問 題 となることはないが 将 来 的 にメッセージの 完 全 性 に 問 題 が 生 じる 可 能 性 があると 指 摘 している 具 体 的 に アタックが 成 功 するためには アタックに 要 す る 時 間 (operation)は 2^64 メモリは 2^40 署 名 されたメッセージの 数 2^22 が 必 要 と なる DSA は DH の 鍵 交 換 において 公 開 鍵 を 保 証 するための 署 名 アルゴリズムとして 利 用 され ている 本 Flaw に 対 する 修 正 (パッチ)が 各 SSL 提 供 者 から 配 布 されている 詳 細 なセキュリティホールおよびその 対 策 は 以 下 のとおり DSS(FIPS186-2)の Annex.3 において k を 求 めるために 一 方 向 性 関 数 G(t,c)を 定 義 して いる G は Sha-1 あるいは DES を 用 いて 生 成 され 160bit の 乱 数 を 出 力 する 56

58 k を 求 めるために 具 体 的 に k = G(t,c) mod q を 計 算 するが q が 160bit の 素 数 であり G が 160bit の(すなわち [0.. q-1]より 若 干 大 き い)ため k に 偏 りが 生 じることがわかる したがって FIPS186-2 では Change Notice1 において 以 下 の 修 正 を 行 っている なお 秘 密 鍵 x を 用 いて m の 署 名 を 作 成 する 際 にも 同 様 の 修 正 がなされている [ 修 正 前 ] Algorithm: Step 1. Choose a secret initial value for the seed-key, KKEY. Step 2. In hexadecimal notation let t = EFCDAB89 98BADCFE C3D2E1F This is a cyclic shift of the initial value for H0 H1 H2 H3 H4 in the SHS. Step 3. For j = 0 to m - 1 do a. k = G(t,KKEY) mod q. b. Compute kj-1 = k-1 mod q. c. Compute rj = (gk mod p) mod q. d. KKEY = (1 + KKEY + k) mod 2 b. Step 4. Suppose M0,..., Mm-1 are the next m messages. For j = 0 to m - 1 do a. Let h = SHA-1(Mj). b. Let sj = (kj-1(h + xrj)) mod q. c. The signature for Mj is (rj,sj). Step 5. Let t = h. Step 6. Go to step 3. [ 修 正 後 ] Step 1. Choose a secret initial value for the seed -key, KKEY. Step 2. In hexadecimal notation let t = EFCDAB89 98BADCFE C3D2E1F This is a cyclic shift of the initial value for H0 H1 H2 H3 H4 in the SHS. Step 3. For j = 0 to m - 1 do 3.1 For i = 0 to 1 do a. wi = G(t, KKEY ) b. KKEY = (1 + KKEY + wi) mod 2b 57

59 3.2 k = (w0 w1) mod q 3.3 Compute kj-1 = k-1 mod q 3.4 Compute rj = (gk mod p) mod q Step 4. Suppose M0,..., Mm-1 are the next m messages. For j = 0 to m - 1 do a. Let h = SHA-1(Mj). b. Let sj = (kj-1(h + xrj)) mod q c. The signature for Mj is (rj, sj). Step 5. Let t = h Step 6. Go to step PKCS#1 のセキュリティホール 1998 年 の CRYPTO 98 において Bleichenbacher は 適 用 型 選 択 暗 号 文 攻 撃 に 対 し PKCS#1(v.1.5)が 脆 弱 性 を 有 することを 指 摘 した[24] それは サーバの 復 号 した 平 文 が PKCS#1(v.1.5)のフォーマットになっているかどうかにより クライアントに 返 すエラ ーメッセージが 異 なるという 脆 弱 性 である 本 攻 撃 は RSA による 数 百 万 の 暗 号 文 を PKCS#1(v.1.5)のフォーマットをチェックするオラクルに 送 ることにより 平 文 の 一 部 を 露 呈 させ さらにその 情 報 から 所 望 の 平 文 を 得 るという 手 法 である したがって 本 攻 撃 は million message attack とも 呼 ばれている 対 策 としては 証 明 可 能 安 全 性 を 有 し Plaintext aware padding である OAEP の 使 用 を 前 提 とした PKCS#1(v.2.0)を 利 用 することが 推 奨 される PKCS#1(v.1.5)における RSA を 用 いた 暗 号 化 フォーマット(PKCS-conforming)は 次 のとおりである EB = 00 BlockType PaddingString 00 DataBlock ここで EB は k bytes の 長 さを 有 し BlockType は 02 PaddingString は 少 なくとも 8 bytes 長 の 非 零 擬 似 乱 数 DataBlock は(k-11) bytes 以 下 の 暗 号 化 対 象 ( 例 えば premaster-secret) である ただし k は RSA の 公 開 鍵 n の byte 単 位 の 長 さを 表 している 本 フォーマットに 対 し RSA 暗 号 処 理 により 得 られる 暗 号 文 c は c = m e mod n となる ただし m は EB の 整 数 値 e は RSA の 公 開 鍵 を 表 している SSL では RSA に よる 鍵 交 換 プロトコルにおいて 暗 号 文 c をサーバに 送 信 する サーバは 受 け 取 った 暗 号 文 c が 正 しく 復 号 できたかどうかの 結 果 をクライアントに 返 信 する オラクルは 攻 撃 者 から 送 られてきた 暗 号 文 の 復 号 結 果 が PKCS-conforming であるかどう 58

60 かをチェックし その 結 果 を 攻 撃 者 に 返 す 役 割 をする オラクルを 用 いた 攻 撃 手 法 の 詳 細 は 以 下 のとおりである 攻 撃 者 は 上 記 の 暗 号 文 c に 対 し 以 下 の 計 算 により 得 られた c をオラクルに 送 る c ' = e cs オラクルにおける 復 号 結 果 は 次 のようになり オラクルは EB が PKCS-conforming である かどうかをチェックして 攻 撃 者 にその 結 果 を 返 す mod d d m' = c' mod n = c s mod n = ms mod n ただし EB は m の 暗 号 化 フォーマット d は RSA の 秘 密 鍵 を 表 している 約 1/2 16 の 確 率 で EB は 以 下 のような 復 号 結 果 となる EB = stuff ここで stuff は 一 般 的 に 不 正 な 復 号 結 果 になるが もともとの EB の 情 報 が 一 部 露 呈 し ていることになる さらに 攻 撃 者 は 次 のアルゴリズムを 用 いることにより EB を 得 ることができる Step 1: ブラインディング 整 数 cに 対 し 異 なるランダムな 整 数 s を 選 択 する オラクルにアクセスすることにより 0 e c( s 0 ) mod nが PKCS-conforming であるかどうかを 確 認 する 最 初 に 成 功 した s 0 に 対 し と 設 定 する ただし c0 0 M i 1 n e c( s ) 0 {[ E, F ]} E = 2B F = 3B 1 B = 2 8( k 2) mod n である Step 2: PKCS conforming 平 文 に 対 する 探 索 Step 2.a: 探 索 開 始 e i = 1ならば 暗 号 文 c( s ) mod n 1 が PKCS-conforming であるような なる 最 小 の 正 の 整 数 を 探 索 する Step 2.b: 1 つ 以 上 区 間 がある 場 合 の 探 索 > 1 i で i 1 s 1 n F + 1 e ( ) mod が i M における 区 間 数 が 少 なくとも 2 であるならば 暗 号 文 c s n 59

61 PKCS-conforming であるような なる 最 小 の 整 数 を 探 索 する Step 2.c: 1 つ 区 間 がある 場 合 の 探 索 M が 1 つの 区 間 ( [ i 1 PKCS-conforming になるまで かつ であるような 小 さい 整 数 Step 3: 解 の 集 合 の 制 限 化 s が 見 つかった 後 集 合 i i に 対 して M として 計 算 される Step 4: 解 の 計 算 i i M = { a, b] i } 1 r, s i M は s > s i i 1 e ( ) mod が )のみ 含 むならば 暗 号 文 c s n i r + i 2 bs 1 i n E + + E r n F r n 1 i i s < i b a を 選 択 する i all [ a, b] M i 1 U ( a, b, r ) and max a E +, s i as F bs E i i r n n rn, min b F +, s i M が 長 さ 1 の 1 つの 区 間 ( M i = {[ a, a] })だけを 含 むならば を 設 定 し m の 解 として m を 返 す そうでなければ と 設 定 し step 2 へ 戻 る m a( s ) c d 0 i i 1 mod n (mod n) PKCS#1 v.2.0 OAEP に 関 するセキュリティホールについて + 1 rn CRYPTO2001 において Manger は PKCS#1v2.0 に 方 式 上 のセキュリティホールがあ ることを 指 摘 した[21] PKCS#1 v2.0 における RSA をベースとする 暗 号 方 式 60

62 RSAES-OAEP は 選 択 暗 号 文 攻 撃 に 対 して 耐 性 を 有 することが 知 られているが RSA の 復 号 処 理 と OAEP のインテグリティチェックにおけるエラー 時 のメッセージが 異 なる 場 合 に 選 択 暗 号 文 攻 撃 が 可 能 となる 必 要 な 選 択 暗 号 文 の 個 数 は Bleichenbacher の PKCS#1 v1.5 に 対 する 同 様 の 攻 撃 に 比 べて 格 段 に 少 なく RSA 1024bit key の 場 合 約 1100 個 RSA 2048bit key の 場 合 約 2200 個 あれば 目 的 とする 暗 号 文 の 解 読 が 可 能 になること を 指 摘 している 本 セキュリティホールの 対 策 としては RSA 復 号 時 のエラーとインテグリティチェック 時 のエラーの 区 別 がつかないようエラーメッセージを 通 知 することで 回 避 できる PKCS#1 v2.1 において 本 修 正 がなされているが 実 行 時 間 によって そのエラーを 判 断 できないよ うにする 必 要 があることも 指 摘 している 攻 撃 の 概 要 は 以 下 のとおり 図 に 示 すように RSAES-OAEP の 復 号 処 理 は RSA の 復 号 処 理 を 行 った 後 integer-octet 変 換 を 行 い OAEP の integrity を 検 証 する 手 順 となっている ここで 一 般 的 に 法 n で 暗 号 処 理 を 行 う 対 象 としては 法 n より 小 さい 数 あるいは1octet 分 だけ 小 さい 数 となるので 最 上 octetが 00 に 設 定 される 攻 撃 はこの 性 質 を 利 用 して 行 う 処 理 的 には RSA の 復 号 処 理 を 行 った 結 果 が 上 記 の 範 囲 になっているかどうかを 検 証 し その 後 OAEP のインテグリティチェックを 行 う 従 って RSA 復 号 処 理 結 果 エラーと OAEP のインテグリティチェックエラーで 異 なるエラーメッセージを 出 力 する 場 合 これ を RSA 復 号 処 理 oracle として 利 用 する 攻 撃 者 が 暗 号 文 c に 対 する m= c^d (mod n)を 求 めたい 場 合 f を 選 択 し f^e c(mod n) を 計 算 し 上 記 oracle に 送 信 する Oracle は RSA の 復 号 処 理 を 行 い 上 記 の 復 号 結 果 f m を 得 る 上 記 f m が 上 で 述 べた 範 囲 にあるかどうかを 検 証 し その 結 果 を 要 求 者 に 返 送 する 攻 撃 者 はその oracle の 返 送 結 果 に 依 存 して f の 値 を 変 更 し oracle に 対 して 問 い 合 わせることで 最 終 的 に m の 値 が 求 まるという 適 応 型 選 択 暗 号 文 攻 撃 を 行 うものである 61

63 Hash HASH Parameter = Seed Hash Padding Secret MGF Mask1 Mask2 MGF 00 Plaintext RSA Ciphertext 図 RSAES-OAEP Decording PKCS#1(v.1.5)に 対 する 適 用 的 選 択 暗 号 文 攻 撃 の 拡 張 における Bleichenbacher の 攻 撃 は 暗 号 学 的 に 安 全 ではないが 実 用 的 な 攻 撃 ではな かった Klima Pokorny Rosa は 2003 年 Bleichenbacher の 攻 撃 を 拡 張 した 現 実 的 に 攻 撃 可 能 なサイドチャネル 攻 撃 を 提 案 した[34] そこでは SSL/TLS プロトコルに 利 用 されている PKCS#1(v.1.5)の 拡 張 フォーマットに 対 し サーバの 復 号 した 平 文 が 正 しい フォーマットであるとき その 平 文 に 含 まれるバージョン 値 をチェックした 結 果 から ク ライアントに 返 すエラーメッセージが 異 なるという 脆 弱 性 が 指 摘 されている 本 攻 撃 は 平 文 のフォーマットのチェックに 加 えて SSL/TLS のバージョン 値 もチェックするオラク ルを 用 いて 平 文 の 一 部 を 露 呈 させることにより Bleichenbacher の 攻 撃 と 同 様 の 手 法 を 利 用 できる 攻 撃 である さらに 本 攻 撃 は Bleichenbacher の 攻 撃 における 平 文 を 得 るアル ゴリズムを 改 良 することにより 実 用 的 な 攻 撃 となっている ランダムに 選 択 したインタ ーネット 上 のサーバに 対 し 2/3 のサーバに 現 実 的 な 処 理 時 間 にて 攻 撃 可 能 であるというテ 62

64 スト 結 果 も 紹 介 されている この 攻 撃 に 関 し 2003 年 3 月 19 日 OpenSSL 0.9.6b~0.9.6i 及 び 0.9.7a に 対 するセキュリティパッチが 公 開 されている SSL/TLS プロトコルにおける 暗 号 化 フォーマット(S-PKCS-conforming)は 次 のとおりで ある EB = 00 BlockType PaddingString 00 DataBlock ここで EB は k bytes の 長 さを 有 し BlockType は 02 PaddingString は(k-51) bytes 長 の 非 零 擬 似 乱 数 DataBlock は 48 bytes の 暗 号 化 対 象 ( 例 えば premaster-secret)であり 最 初 の 2 bytes が SSL/TLS のバージョン 値 になっている ただし k は RSA の 公 開 鍵 n の byte 単 位 の 長 さを 表 している 本 フォーマットに 対 し RSA 暗 号 処 理 により 得 られる 暗 号 文 c は c = m e mod n となる ただし m は EB の 整 数 値 e は RSA の 公 開 鍵 を 表 している SSL では RSA に よる 鍵 交 換 プロトコルにおいて 暗 号 文 c をサーバに 送 信 する サーバは 受 け 取 った 暗 号 文 c に 対 し 次 のように 動 作 する ⅰ)サーバは 復 号 された 平 文 が S-PKCS-conforming であるかどうかをチェックする その 結 果 平 文 が S-PKCS-conforming でなければ サーバは 新 しい premaster-secret をラン ダムに 生 成 する そして クライアントの Finished メッセージを 受 信 後 すぐに 通 信 は 切 断 される ⅱ)サーバは 各 S-PKCS-conforming 平 文 をチェックして SSL/TLS のバージョン 値 が 正 しいかどうかを 判 断 する( 現 在 のバージョンは 3.0 と 3.1 である) このバージョン 値 テス トに 失 敗 したら サーバは 区 別 可 能 なエラーメッセージを 出 す ただし テストは S-PKCS-conforming ではない 平 文 には 行 われない オラクル(bad-version-oracle: BVO)は 攻 撃 者 から 送 られてきた 暗 号 文 の 復 号 結 果 が S-PKCS-conforming であり かつ SSL/TLS のバージョン 値 が 正 しいかどうかをチェック し その 結 果 を 攻 撃 者 に 返 す 役 割 をする BVO を 用 いた 攻 撃 手 法 の 詳 細 は 以 下 のとおりである 攻 撃 者 は 上 記 の 暗 号 文 c に 対 し 以 下 の 計 算 により 得 られた c を BVO に 送 る c ' = e cs BVOにおける 復 号 結 果 は 次 のようになり BVOは EB が S-PKCS-conformingであるとき バージョン 値 が 正 しいかどうかをチェックして 攻 撃 者 にその 結 果 を 返 す mod d d m' = c' mod n = c s mod n = ms mod n ただし EB は m の 暗 号 化 フォーマット d は RSA の 秘 密 鍵 を 表 している 約 1/2 16 の 確 率 n 63

65 で EB は 以 下 のような 復 号 結 果 となる EB = stuff1 00 major minor stuff2 ただし major minor はそれぞれ SSL/TLS の major バージョン 値 minor バージョン 値 を 表 している ここで stuff1 と stuff2 は 一 般 的 に 不 正 な 復 号 結 果 になるが もともと の EB の 情 報 が 一 部 露 呈 していることになる さらに 攻 撃 者 は Bleichenbacher の 攻 撃 と 同 様 のアルゴリズムを 用 いることにより EB を 得 ることができる ただし 暗 号 化 フォーマットを S-PKCS-conforming オラクルを BVO E と F をそれぞれ E F = = = B B B + + k 3 1* k * ( * 256 k 4 1* k K K * ) + = 0 2 B k ( * ( ) / K ) と 置 き 換 えることとする また アルゴリズムの 各 ステップにおいて 次 の 手 法 や 性 質 により 攻 撃 の 効 率 化 が 行 われ ている ⅰ)step 2: Parallel-Threads Method Parallel-Threads Method は M i 1 における 複 数 の 区 間 に 対 して 多 重 処 理 を 行 う 手 法 であ e る この 手 法 は すべての 区 間 に 対 し 暗 号 文 cs mod nが S-PKCS-conforming であるよう な s の 探 索 を 行 い その s を 見 つけた 場 合 には その 都 度 全 区 間 の 更 新 及 び 不 要 な 区 間 の 消 去 を 行 うというものである ⅱ)step 2.b: Beta Method Beta Methodは 暗 号 文 cs e mod nが S-PKCS-conformingであるような sを 効 率 良 く 探 索 す e e る 手 法 である この 手 法 は c( s ) mod nと c( s n i j ) mod がともに S-PKCS-conforming であるような s i s j を 線 形 結 合 して 得 られた s に 対 し cs e mod nも S-PKCS-conforming であるという 性 質 を 利 用 している ⅲ)step 3: 範 囲 の 対 称 性 範 囲 の 対 称 性 は 暗 号 文 cs e mod nが S-PKCS-conforming であるような 大 きい sをより 小 さ い 値 に 変 換 するために 利 用 される 性 質 である この 変 換 は 対 称 性 を 保 存 しながら 平 文 の 取 りうる 値 の 範 囲 を 変 換 可 能 であるという 性 質 を 利 用 している 攻 撃 の 複 雑 性 は BVO コール 数 により 決 定 される 1200 個 の 暗 号 文 に 対 し 50%の 攻 撃 が 成 功 するのに 必 要 な BVO コール 数 として 次 のよう な 測 定 結 果 が 記 されており サーバの 公 開 鍵 の 法 は 長 さ 8 r ( r : 整 数 )bits を 使 用 すべき であると 述 べられている N = 1024 bits:13.34 million 以 下 64

66 N = 1025 bits:1.20 million 以 下 N = 2048 bits:19.9 million 以 下 N = 2049 bits:3.47 million 以 下 鍵 長 1024 bitsの RSAを 用 いた SSLサーバ(2x Pentium Ⅲ/1.4 GHz, 1GB RAM, 100 Mb/s, OS RedHat 7.2, Apache )における 攻 撃 テストとして 以 下 のような 結 果 が 記 されて いる 67.7 BVO calls/s 全 攻 撃 に 対 する 中 間 時 間 :54 時 間 42 分 さらに 常 に 成 功 するというわけではないが インターネット 上 の 611 個 の SSL/TLS サー バの 2/3 が BVO による 攻 撃 が 可 能 であることも 示 されている CBC モードのパディング 方 式 における 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 < 概 要 > CBC による 共 通 鍵 暗 号 化 処 理 には バイト 単 位 の 固 定 のパディングパターンを 使 用 してい る 場 合 パディングの 正 当 性 チェックの 結 果 を 利 用 して 平 文 をバイト 単 位 で 逐 次 求 める ことが 可 能 であるというセキュリティホールが 存 在 する 本 攻 撃 は パディングの 正 当 性 チェックの 結 果 を 処 理 時 間 の 違 いを 利 用 して 判 別 し 平 文 を 求 めるものである ある 条 件 下 において 正 しい 実 装 がなされていないすべての SSL 及 び TLS 実 装 に 対 して 理 論 上 は 適 用 可 能 である OpenSSL の 実 装 では 0.9.6i 及 び 0.9.7a 以 降 の 実 装 で 対 策 が 行 われてい る <CBC-PAD の 脆 弱 性 について> (a) 攻 撃 手 法 CBC-PAD[41]は RFC2040 で 規 定 されている 共 通 鍵 ブロック 暗 号 利 用 モードであり (RFC2040 では RC5 について 規 定 ) 以 下 のようなデータ 構 造 を 取 る Message Padding Length Length field は 1 バイト 固 定 で 与 えられており また Padding Field は Length 値 が 繰 り 返 される 構 成 となっている この 特 徴 を 利 用 して 以 下 のような 攻 撃 を 行 うことが 可 能 で あることが 報 告 されている[42] なお バイト 単 位 の 固 定 パターンでパディングする 方 式 に ついては 本 攻 撃 が 同 様 に 適 用 できる また 固 定 のパディング 方 式 のいくつかには 脆 弱 性 があることが 指 摘 されている[44][45] 65

67 攻 撃 には 以 下 の 5 種 類 の Oracle を 使 用 することで 段 階 的 に 行 う このとき b を 使 用 するブロック 暗 号 の block length (Byte) N を 暗 号 文 Y のブロック 数 とする Oracle O: パディングの 正 当 性 を 判 定 する Oracle 任 意 の 暗 号 文 入 力 に 対 して パディング 処 理 が 正 しいかどうか 判 定 を 行 い 正 しければ 1 を 正 しくなければ 0 を 返 す Check1: CBC-PAD で 暗 号 化 された 任 意 の 暗 号 文 Yのあるブロック Y_n の 任 意 の Byte y_i について 予 測 した 平 文 x_i が 正 しいかどうかの 判 定 を 行 う Check1 は 任 意 の i に 対 して 長 さ b- i のランダムな 暗 号 文 L と 長 さ i の 暗 号 文 R=r_i... r_b xor i... i( 各 r_i はバイト 単 位 ) から 生 成 される r=l R を 使 用 して r y_i なる 暗 号 文 を 生 成 してパディングの 正 当 性 を 判 定 する Oracle O に 入 力 する DecryptByte1: Check1 を 利 用 して y_i に 対 する 平 文 x_i を 求 める r_i+1,..., r_b は 既 知 であるとき(i は 1~b) r_i のすべての 値 に 対 して r_i... r_b を 作 成 して y_i と 共 に Check1 に 問 い 合 わ せを 行 う なお S.Vaudenay の 論 文 では Check1 と DecryptByte1 をまとめて Last Word Oracle(LWO)と 称 している DecryptBlock1: DecryptByte1 を 利 用 して 暗 号 文 Yのあるブロック Y_n を 求 める Y_n の 各 Byte である y_i ごとに DecryptByte1 を 呼 び 出 す S.Vaudenay の 論 文 では Block Decryption Oracle(BDO)と 称 する Decryption Oracle (DO): DecryptBlock1 を 利 用 して 暗 号 文 Y を 求 める Y の 各 ブロックである Y_n ごとに DecryptBlock1 を 呼 び 出 す 以 下 に 各 Oracle の 関 係 を 図 示 する 66

68 DO は BDO を N 回 呼 び 出 し BDO は DO の 各 呼 び 出 しに 対 して LWO を b 回 呼 び 出 す DecryptByte1 が Check1 を 2^8 回 呼 び 出 し Check1 は 各 呼 び 出 しに 対 して O を1 回 呼 び 出 す 従 って LWO は 全 体 として BDO の 各 呼 び 出 しに 対 して O を 2^8 回 呼 び 出 す 以 上 から 攻 撃 に 必 要 な 計 算 量 は O(2^8bN)であることが 判 る 本 攻 撃 は 暗 号 文 に 対 す る 平 文 を 1Byte 単 位 で 分 割 統 治 的 に 逐 次 求 めることができるため 全 数 探 索 よりも 計 算 量 は 小 さくなる 図 1 に 攻 撃 アルゴリズムを 示 す 平 文 x_1, x_2, x_3 を 推 測 して r_1, r_2, r_3 を 作 成 し Rr_1,r_2, r_3 とパディング(1,1,1 や 2,2,2)を xor したものを 第 一 ブロック 暗 号 文 y_1, y_2, y_3 を 第 二 ブロックとして 復 号 処 理 を 依 頼 し エラーメッセージから 推 測 が 正 しか ったかどうか 判 定 する 攻 撃 アルゴリズムからわかるように 本 脆 弱 性 は パディング 処 67

69 理 が ある 固 定 の 規 則 に 基 づいていることに 起 因 している 68

70 (b) 実 環 境 への 適 用 (a)で 述 べた 攻 撃 を 実 環 境 に 適 用 するためには 以 下 の 2 つの 条 件 が 必 要 である (1) 通 信 を 行 うあるエンティティに 対 して 任 意 の 回 数 の 問 い 合 わせが 可 能 である (2) パディングチェックの 結 果 を 攻 撃 者 は 与 えられる もしくは ある 優 位 性 を 持 って 推 測 できる 条 件 (1)については SSL/TLS 等 では パディングチェックが 失 敗 した 場 合 直 ちにセ ションが 切 断 され 共 有 鍵 の 更 新 が 行 われるため 連 続 して 複 数 回 の 問 い 合 わせを 行 う ことが 難 しい 従 って 暗 号 文 の 1Byte を 求 める 場 合 でも 2^-8 の 確 率 でしか 成 功 しない ところが 送 信 される 情 報 がパスワード 等 の 常 に 同 一 の 情 報 であれば 複 数 のセションに 渡 って 攻 撃 を 行 うことで 最 終 的 に 暗 号 文 に 対 する 平 文 を 得 ることができる S.Vaudenay は Oracle O を Bomb Oracle O (Check が Fail すると 使 用 不 可 能 になる)でモデル 化 し 議 論 を 行 っている 従 って 毎 回 固 定 の 平 文 に 対 する 暗 号 文 が 送 られるという 条 件 下 にお いては 条 件 (1)を 満 たし 攻 撃 は 可 能 である 条 件 (2)については WTLS 等 の 一 部 の 仕 様 では パディングエラーの 場 合 のエラーメ ッセージと メッセージ 認 証 子 がエラーになった 場 合 にエラーメッセージが 異 なるため ある 優 位 性 を 持 って 識 別 可 能 となっている ところが TLS 1.1(SSL 3.0 及 び TLS 1.0 は 脆 弱 性 あり)では 2つのエラーで 同 一 のエラーメッセージを 返 すため 通 常 の 方 法 では 攻 撃 者 は ある 優 位 性 を 持 って 識 別 することはできない <タイミング 攻 撃 を 利 用 した 攻 撃 > (a) 攻 撃 手 法 B.Canvel らは S.Vaudenay の 方 式 を 拡 張 することで TLS1.1 に 対 しても 攻 撃 可 能 である ことを 示 した[43] 具 体 的 には Oracle O を 処 理 時 間 を 返 す Oracle O へと 変 更 すること で Adversary を 構 成 する この 攻 撃 は パディングエラーでは ハッシュ 関 数 の 演 算 処 理 を 行 わないのに 対 し メッセージ 認 証 子 のエラーでは ハッシュ 関 数 の 演 算 処 理 を 行 う ため 処 理 時 間 に 差 が 生 じるという 特 性 を 利 用 したタイミング 攻 撃 である このとき 処 理 時 間 を 最 大 とするため 仕 様 上 許 す 範 囲 において Oracle への 入 力 暗 号 文 長 が 最 大 (TLS では 2^ Byte)となるように ランダムなデータ 列 f を 結 合 させる 従 って Oracle O は 入 力 暗 号 文 f r y に 対 して 処 理 時 間 T_m を 返 す B.Canvel らの 解 析 結 果 では パディングエラーとなる 場 合 の 処 理 時 間 の 期 待 値 μ_w は 21.57msec 分 散 σ_w は 1.86 であるのに 対 し メッセージ 認 証 子 エラーの 場 合 の 期 待 値 μ_r は 23.63msec 分 散 σ_r は 1.48 であった 従 って 複 数 回 の 試 行 を 行 い 精 度 を 高 めなければならない False Positive 69

71 70 あるいは False Negative である 可 能 性 は 試 行 回 数 n に 対 して 以 下 のように 指 数 関 数 的 に 減 少 する = n R σ µ τ ϕ ι = + n W σ µ τ ϕ ι. 2 1 ) ( 2 2 dt e x t x = π ϕ 判 定 は 以 下 のように 閾 値 に 基 づいて 行 う STOP: [ ] ι ι µ τ µ µ , W R T j j T ACCEPT: ι τ µ µ + > W R T j j T + + = τ µ µ σ τ ι log 2 W R. log 2 = τ µ µ σ τ ι W R τ + 1 τ 以 上 のことからエラーを 判 別 するのに 十 分 な 試 行 回 数 J は それぞれ 以 下 のようになる τ µ µ σ log ) ( W R J W + τ µ µ σ log ) ( W R J R

72 (b) 実 環 境 への 適 用 CBC-PAD を 使 用 して 毎 回 固 定 の 平 文 を 暗 号 化 して 送 信 しているエンティティに 対 しては 適 用 できる 可 能 性 がある しかしながら ネットワーク 上 の 遅 延 などが 存 在 する 実 環 境 に 対 しては どの 程 度 現 実 的 であるか 十 分 実 証 されてはいない しかしながら 本 攻 撃 に 対 する 対 策 は 非 常 に 容 易 であり 実 装 においては 対 策 を 講 じておくことが 望 ましい 例 え ば パディング 処 理 を 行 った 後 にメッセージ 認 証 子 を 付 加 するように 方 式 を 変 更 する 方 法 などが 考 えられる また OpenSSL 0.9.6i 及 び 0.9.7a 以 降 では パディング 処 理 が 失 敗 し た 場 合 ハッシュ 処 理 の 時 間 に 相 当 する 時 間 待 機 し その 後 エラーメッセージを 返 信 する 方 式 を 実 装 している このような 手 法 も 本 攻 撃 に 対 する 十 分 な 対 策 となる その 他 の CBC パディングの 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 で 指 摘 した 攻 撃 は 固 定 パターンのパディングを 行 っている 他 のパディング 方 式 を 使 用 した CBC モードにも 適 用 できるものである 攻 撃 が 成 功 するための 要 件 は パディング 処 理 の 結 果 をある 優 位 性 をもって 取 得 可 能 であるという 前 提 のもとで パディング 処 理 の 結 果 から 少 なくとも 1bit 以 上 の 情 報 を 確 定 できる ということである 特 に ソフトウェ ア 実 装 においては 効 率 性 の 観 点 から バイト 単 位 かつ 固 定 のパディング 処 理 を 行 うこと が 多 く 注 意 して 実 装 しなければならない 具 体 的 には 攻 撃 者 が Distinguisher を 構 成 で きないような 実 装 を 心 掛 けるべきである J.Black は いくつかのパディング 方 式 について M.Bellare らが 示 した 共 通 鍵 暗 号 操 作 モ ードにおける Semantic Security [46]を 満 たすかどうかの 評 価 を 行 った[44] ( 表 ) 表 Bit-oriented or Semantic Queries to Recover Plaintext Byte-oriented Security CBC-PAD Byte No 64b+lg(b) ESP-PAD Byte No 64b+lg(b) XY-PAD Byte No 64b+lg(b) OZ-PAD Bit No 2 8b-1 BOZ-PAD Byte No 64b+lg(b) PAIR-PAD Byte No 2 8b-1 ABYT-PAD Byte Yes N/A ABIT-PAD Bit Yes N/A b は 1ブロックあたりのバイト 数 ESP-PAD は IPSec-ESP で 使 用 されているパディング XY-PAD は メッセージ M に 対 して M XYYY...とバイト 単 位 でパディングする 方 式 X, Y は 固 定 値 OZ-PAD は メッセージ M に 対 して M とビット 単 位 でパディングする 方 式 71

73 BOZ-PAD は OZ-PAD をバイト 単 位 に 拡 張 したもの M 80, 00, 00,...とパディングす る PAIR-PAD は XY-PAD を 拡 張 したもので M XYYY..., M YXXX..., を 選 択 可 能 ABYT-PAD は メッセージ M の 最 下 位 バイトとは 異 なるバイト Y で M YYY,... とパ ディングする 方 式 Y は 最 下 位 バイト 以 外 からランダムに 選 択 可 能 ABIT-PAD は ABYT-PAD のビット 版 メッセージ M の 最 下 位 ビットと 異 なるビッ トでパディングする 方 式 上 記 の 表 において 少 なくとも Semantic Security を 満 たしていない 方 式 については 脆 弱 性 があると 判 断 できる 節 で 述 べたように 脆 弱 性 があるパディングの 使 用 が 直 ちに SSL の 脆 弱 性 につながる 訳 では 無 い なぜなら 節 で 述 べた 対 策 が SSL の 実 装 にお いて 行 われているからである しかしながら 安 全 なパディング 方 式 を 使 用 するほうがよ り 望 ましいと 考 えられる また K.G.Paterson らは RSA カンファレンスの Ciphers Track にて ISO 標 準 に 採 用 さ れている CBC モードのパディング 方 式 について 脆 弱 性 があり サイドチャネル 攻 撃 が 可 能 との 発 表 を 行 う 予 定 である[45] (2004 年 2 月 6 日 現 在 未 確 認 ) PKCS#1 V2.1 などの 脆 弱 性 を 利 用 したサイドチャネル 攻 撃 Klima と Rosa は 2002 年 次 の 3 つの 攻 撃 を 提 案 した[35] (1)RSAES-OAEP(PKCS#1 v.2.1)に 対 するサイドチャネル 攻 撃 (2)2.1.2 における Bleichenbacher の 攻 撃 と における Manger の 攻 撃 をそれぞれ 利 用 してサーバの 署 名 を 偽 造 する 攻 撃 (3)RSA-KEM に 対 するフォールトサイドチャネル 攻 撃 (1)の 攻 撃 は PKCS#1(v.2.1)に 従 う EME-OAEP-DECODE 手 法 による 復 号 プロセス において 攻 撃 者 が 平 文 の 一 部 のハミング 重 みを 集 めることにより 平 文 の 最 下 位 ビット を 露 呈 させ さらにその 情 報 から 所 望 の 平 文 を 得 るという 手 法 である (2)の 攻 撃 は RSA の 同 じ 秘 密 鍵 に 関 し 暗 号 方 式 における 復 号 鍵 と 署 名 方 式 における 署 名 鍵 を 同 時 に 使 用 す る 場 合 に 起 こる 脆 弱 性 を 利 用 した 手 法 である (3)の 攻 撃 は RSA-KEM において 秘 密 鍵 のあるビットにフォールトを 故 意 に 起 こさせることにより 秘 密 鍵 をビットごとに 露 呈 させる 手 法 である (2)の 攻 撃 に 関 しては や において 既 に 各 攻 撃 に 対 する 対 策 が 提 案 されている そして (1)の 攻 撃 はハミング 重 みに 対 する 電 力 サイドチャネル 攻 撃 を (3)の 攻 撃 は 秘 密 鍵 に 対 する 電 力 フォールトサイドチャネル 攻 撃 をそれぞれ 前 提 としているため SSL/TLS においては 実 用 的 な 攻 撃 手 法 ではない また フォールト 攻 撃 の 対 応 策 として 以 下 のことが 推 奨 されることも 記 述 されている 72

74 a) 秘 密 鍵 やプロセス 中 に 使 用 されるパラメータのインテグリティをチェックすること b) エラーメッセージの 範 囲 を 最 小 にすること c) フォールト 検 出 を 装 備 したプラットフォームや 補 正 用 の 設 備 (フォールトトレラントシ ステム)をできる 限 り 使 用 すること また (3)の 攻 撃 例 に 対 する 防 御 法 として d e x = y mod nと y = x mod n の 両 方 をチェックすることも 推 奨 されることも 記 されている 以 下 に 各 攻 撃 に 関 する 詳 細 を 述 べる (1)RSAES-OAEP(PKCS#1 v.2.1)に 対 するサイドチャネル 攻 撃 図 に RSAES-OAEP(PKCS#1 v.2.1)の 復 号 プロセスを 示 す この 復 号 プロセスに おいて MGF として 使 用 する SHA-1 に maskeddb の 値 を 入 力 する 際 の 処 理 に 脆 弱 性 が 存 在 する seed phash PS 01 M Manger s attack 0x00 maskedseed MGF seedmask DB dbmask EM = I2OSP (m) MGF side channel attack due MGF (SHA-1) maskeddb M = EME-OAEP-DECODE (EM, P) m = RSADP c = c ( ) d mod n 図 RSAES-OAEP Decoding(PKCS#1 v.2.1) w( W j = は SHA-1 に 入 力 する 最 後 のブロックを 分 割 した 32 bits の 一 部 の 変 数 )( i 7,8,9,10) 次 のとおりである 73

75 W W W W = = = = m m m m [14] [10] [6] [2] m m m m [13] [9] [5] [1] m m m m [8] [4] [12] m m [0] 00 ただし m j]( j = 0,,14) は 平 文 の j 番 目 のオクテットであり W i の 各 ビットを W i,31 W i,30 [ L W i,29 W i,0 と 表 す(m [0]が 最 下 位 オクテットである) このとき W )( i 8, 9,10) w( j = を W i のハミング 重 み(1 の 個 数 )とし 攻 撃 者 はこれらのハ ミング 重 みを 入 手 可 能 であるとする RSA 暗 号 処 理 c = m e mod n により 暗 号 文 c が 得 られる ただし m は 平 文 の 整 数 値 e は RSA の 公 開 鍵 を 表 している 暗 号 文 c は RSA 復 号 処 理 m = c d mod n = m ed m [7] [3] [11] mod n により 平 文 m に 復 号 される ただし d は RSA の 秘 密 鍵 を 表 している 攻 撃 者 は 上 記 の 暗 号 文 c に 対 し c' = c 2 e mod n を RSA 復 号 処 理 をさせ その 結 果 を m とする この 場 合 上 記 の 32 bits の 変 数 W i 及 びハミング 重 み w(w i )に 対 応 する 変 数 とハミング 重 みをそれぞれ W i w(w i )とする 攻 撃 者 はハミング 重 み w(w i )と w(w i )を 集 める 最 下 位 ビット W 10,8 が 0 のとき 最 下 位 ビット W 10,8 が 1 のとき との 値 を 返 される ただし 1" m ' = m >> 1 m' = ( m + n) >> 1 ">> は 右 に 1 bit シフトを 表 している W = 10,8 0 のとき w(w i )と w(w i )には w( W ' ) 8 w( W ' ) 9 = = w( W ' ) 10 = w( W ) 8 w( W ) 9 w( W ) 10 W W 8,0 9,0 W ,8 W W + 7,0 8,0 W 9,0 = w( W ) 10 + W 9,0 の 関 係 が 成 立 し それらの 可 能 な 関 係 は 表 のとおりになる 74

76 攻 撃 者 は 集 めたハミング 重 み w(w i )と w(w i )のそれぞれの 関 係 を 調 べ 表 のいずれ かの 関 係 を 満 足 している 場 合 には W = 10,8 であると 判 断 し いずれの 関 係 も 満 足 していなければ W = 10,8 であると 判 断 する この 誤 り 確 率 はおよそ である 最 下 位 ビット W 10,8 の 値 がわかれば 攻 撃 者 は[83]の 定 理 により 多 項 式 時 間 にて 平 文 を 得 る ことができる 表 w(w i )と w(w i )の 可 能 な 関 係 w(w 8 ) w(w 9 ) w(w 10 ) W 8 W 9 W 10,31 W 10,8 0 1 W 8 W 9 W 10,31 W 10,8 w(w 8 ) w(w 9 ) w(w 10 ) W 9,0 W 8,0 W 7,0 可 能 な 関 係 w(w 10 ) = w(w 10 ) w(w 9 ) = w(w 9 ) w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) w(w 9 ) = w(w 9 ) w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) w(w 9 ) = w(w 9 ) + 1 w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) w(w 9 ) = w(w 9 ) + 1 w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) + 1 w(w 9 ) = w(w 9 ) - 1 w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) + 1 w(w 9 ) = w(w 9 ) - 1 w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) + 1 w(w 9 ) = w(w 9 ) w(w 8 ) = w(w 8 ) w(w 10 ) = w(w 10 ) + 1 w(w 9 ) = w(w 9 ) w(w 8 ) = w(w 8 ) (2)2.1.2 における Bleichenbacher の 攻 撃 と における Manger の 攻 撃 をそれぞれ 利 用 してサーバの 署 名 を 偽 造 する 攻 撃 Bleichenbacher の 攻 撃 や Manger の 攻 撃 がそれぞれ PKCS#1(v.1.5)や PKCS#1(v.2.0) における 暗 号 化 に 対 して 成 功 する 場 合 には 署 名 に 同 じ RSA の 秘 密 鍵 を 用 いると 署 名 も 偽 造 することができるという 脆 弱 性 が 存 在 する 暗 号 化 と 署 名 に 同 じ 鍵 を 使 用 する 主 なアプリケーションの 例 として SSL プロトコルがあ る 75

77 PKCS#1(v.1.5)における 平 文 のフォーマットは 最 上 位 の 2 octets が であり 11 番 目 以 降 のオクテットに 00 が 現 れるフォーマットになっている PKCS#1(v.2.0)における 平 文 のフォーマットは 最 上 位 オクテットが 00 であるフォーマ ットになっている 各 フォーマットに 対 し RSA 暗 号 処 理 により 得 られる 暗 号 文 c は c = m e mod n となる Bleichenbacher の 攻 撃 や Manger の 攻 撃 に 使 用 されるオラクルは 攻 撃 者 から 送 られてき た 暗 号 文 の 復 号 結 果 が 上 記 の 各 フォーマットであるかどうかをチェックし その 結 果 を 攻 撃 者 に 返 す 役 割 をする 攻 撃 者 は 上 記 の 暗 号 文 c に 対 し 以 下 の 計 算 により 得 られた c を 各 オラクルに 送 る c ' = e cr オラクルにおける 復 号 結 果 は 次 のようになり オラクルは 正 しいフォーマットであるかど うかをチェックして 攻 撃 者 にその 結 果 を 返 す mod d d m' = c' mod n = c r mod n = mr mod n 各 攻 撃 において 攻 撃 者 はある 確 率 にて 正 しいフォーマットである 復 号 結 果 を 得 られる 平 文 の 情 報 が 一 部 露 呈 していることになるため 攻 撃 者 はもとの 平 文 m も 得 ることができ る このとき c をメッセージとし そのメッセージ c に 対 する 同 様 の 攻 撃 を 行 うことにより 署 名 m を 得 ることができる n (3)RSA-KEM に 対 するフォールトサイドチャネル 攻 撃 RSA-KEM において 受 信 者 が 復 号 して 得 られたメッセージのインテグリティをチェック した 結 果 により 送 信 者 に 返 すメッセージが 異 なるという 脆 弱 性 が 存 在 する 本 攻 撃 とし て 2 つの 例 を 挙 げる Receiver Oracle(RO)は メッセージ M のインテグリティチェックを 行 い 正 しければ yes 間 違 っていれば no を 出 力 する RSA confirmation oracle: RSA-CO d,n (r, y)は 次 のように 定 義 される RSA-CO d,n (r, y) (ANSWER = yes/no )の 手 順 1. K = KDF( r) : KDF - Key Derivation Function 2. C 0 = y 76

78 ' 2004/02/06 SSL 安 全 性 調 査 報 告 書 Ver.2 3. C 1 = DEM.Encrypt( K, M ) 4. C = C0 C1 5. 暗 号 文 C を RO に 送 る RO にて 続 きを 行 う a. 次 の 手 順 にて K = KEM.Decrypt( d, C0) を 計 算 する ⅰ. y = C0 < n かどうかチェックする そうでなければエラーが 起 こる d ⅱ. r' = y mod n を 計 算 する ⅲ. K ' = KDF( r' ) b. M ' = DEM.Decrypt( K ', C1) c. M のインテグリティチェックを 行 う d. チェックが 正 しければ RO は yes と そうでなければ RO は no と 応 答 する 6. RO の 応 答 が yes なら RSA-CO d,n (r, y)の 応 答 も yes そうでなければ RSA-CO d,n (r, y) の 応 答 も no である つまり 上 記 のオラクルは d r = y mod nのときいつでも yes d r y mod n のとき 1 に 近 い 確 率 で no を 返 すオラクルである 攻 撃 例 1 は 次 のとおりである 秘 密 鍵 d の i 番 目 のビット d(i)において 誤 りが 起 きたとき d d i ' = d + 2 if d ( i) = i ' = d 2 if d ( i) = なる d を step 5.a.ⅱにおいて d の 代 わりに 用 いることを 考 える d そのとき r = y mod nに 対 して α α d r = ( y mod n) if d ( i) = 0 d 1 r = ( y mod n) if d ( i) = 1 となる ただし I = 2 y I 1 α mod n α α 1 mod nである 攻 撃 者 は RSA-CO d,n を 利 用 して 次 の 手 順 を 繰 り 返 すことにより d(i)の 値 を 得 ることができ る 1. 0 < x < nなる x をランダムに 選 ぶ = e 2. y x mod n α 3. r = x mod n i 4. RSA-CO d,n (r, y)が yes を 返 すならば d ( i) = 0 そうでなければ d( i) = 1と 設 定 する 攻 撃 例 2 は 次 のとおりである

79 記 号 を 次 のように 定 義 する p: p = t 2 + 1なる 素 数 t: 小 さな 素 数 g: Z p *の 生 成 元 Z p *の 位 数 : d の 最 大 値 より 大 きい s = の 計 算 Step 1: 値 D d mod 2 s s d = b k = 1 d ( b k ) 2 とする ただし b は d の 2 進 形 のビット 数 d ( i) {0,1}(0 i b 1) である (p-1)が 2 i j で 割 り 切 れると 仮 定 し I = 2 J = 2 とおく それから と 定 義 する そのとき より r g g i r = g D( i ) d = d mod p b k i mod 2 ( p 1) / I d ( p 1) / I ( p 1) / I d ( p 1) / I d mod I ( p 1) / I D( i) [ ] [ ] [ ] [ ] となる D(i)の 値 は と 表 される 以 下 帰 納 法 にて 示 す i = 1 に 対 して (1)から が 成 立 する r の 定 義 から となるので r g g mod ( p 1) / I D ( i ) [ g ] mod p ( 1) ( p 1) / I D ( i) = i k = 1 d r p 1) [ g p ( / 2 ( p [ g ( i 1) / r p 1) [ g p ( / 2 ( ] 2 1) / ] 2 k ) 2 d ( 0 ) ] d i k mod mod p p d ( p 1) / 2 d (0 ) [ g ] mod p (2) ( 1) / 2 が 成 立 する ( g p 1) / 2 p 1 mod であり ( p 1) / 2 d ( 0 ) p [ g ] mod はビット d(0)に 依 存 してたった p 2 つの 可 能 な 値 をとりうる そこで d ( 0) = 1と 仮 定 して RSA-CO d,p (p-1, p-1)を 利 用 する p 78

80 オラクルが yes を 返 すなら d(0) = 1 そうでなければ d(0) = 0 と 設 定 する ある 0 < j < s に 対 して 値 D(j)を 知 っていると 仮 定 する (1)から が 成 立 する α d が 得 られる (3)の 右 辺 の 値 に 対 し ( p [ g 1) /( 2 J ) ] D ( j+ となるので 1) j r ( p 1) /( 2 J ) D ( j 1) [ g ] mod p (3) ( p 1) /( 2 J ) + = d j = ( ) 2 ( ) ( p [ g ( p 1) /( 2 1) d ( D ( j j J + 1) = とおくと d J ) α ( p ] [ g j ) ( p 1) /( 2 J [ g が 得 られる r の 定 義 を 用 いると 1) /( 2 ) mod 2 ] J ) D ( ] j D ) ( j ) j + 1 mod r p 1) J ( p d 1) j [ g p ( /( 2 ) ( ) ( [ g = α + D ( p [ g p 1) /( 2 J ) 1) / ] D 2 ( ( ] j d ) j ( ) j ) mod ( p [ g ( p 1) /( 2 J ) d d ( j ) ( p 1) /( 2 J ) D ( j ) ] ( p 1) [ g ] mod p (4) となる p J D j p J ここで d(j) = 0 と 推 測 し RSA - CO ([ g ] mod p, g mod ) を 利 用 p 1) /( 2 ( 1) /( 2 ) ( ) ( 1) /( 2 ) p, d p する オラクルが yes を 返 すなら d(j) = 0 そうでなければ d(j) = 1 と 設 定 する 以 上 の 帰 納 法 から = D(s) が 得 られる Ds Step 2: 値 = d mod t の 計 算 D t r p 1) t p ( / ( [ g を 満 足 する jを 見 つけるまであらゆる 値 j = 0, L, t 1をテストし 得 られた 値 を D t とする r の 定 義 を 用 いて [ g 1) / p 1) t d ] [ g p ( / ( t ] 1) / t j ] mod j mod と 書 き 直 し RSA - COd p ([ g p t j ] mod p, g p t mod ) 次 行 う オラクルが yes を 返 すとき D t = j と 設 定 する を = 0,, t 1 ( 1) / ( 1) / p, p p J ) ] D ( j L に 対 して 逐 j ) 79

81 Step 3: 値 d の 計 算 Step 1 と Step 2 により 合 同 式 d d D D s t mod 2 mod t が 得 られている s gcd( t, 2 ) = 1が 成 立 し 中 国 人 の 剰 余 定 理 によって 両 合 同 式 を 満 足 する s 0 d < t 2 なる ただひとつの 値 が 存 在 する d の 値 は 以 下 のようにして 計 算 できる 1. gcd( t, 2 ) = 1であるから γ 2 1 mod t なる 存 在 するただひとつの 値 γ を 計 算 する 2. v = ( D D ) γ mod t を 計 算 する t s s s s 3. = + s d v 2 Ds SSL ソフトウェアに 対 するタイミング 攻 撃 D.Brumley らは SSL で 使 用 されている RSA の 復 号 処 理 において タイミング 攻 撃 を 実 行 し 秘 密 鍵 を 復 元 する 攻 撃 を 提 案 している[37] さらに OpenSSL に 攻 撃 を 試 み 評 価 を 行 っている 本 攻 撃 は 以 下 の2つの 処 理 時 間 の 違 いが 攻 撃 に 利 用 可 能 である (1) Montgomery reduction における extra reduction の 発 生 回 数 (2) 多 倍 長 演 算 において Karatsuba が 選 択 されるか 否 か 通 常 RSA の 復 号 処 理 においては 法 N=pq の 演 算 を p, q について 個 別 に 行 い 中 国 人 剰 余 定 理 を 用 いて 結 合 させて 復 号 する ある g に 対 する g mod q の 演 算 においては g が q のべ き 乗 である 場 合 Montgomery reduction の extra reduction は 著 しく 減 少 する 従 って 暗 号 文 g の 復 号 処 理 においては g <qであれば 遅 く g >qであれば 速 い 一 方 Karatsuba は g <qにおいて 速 く g > qにおいて 遅 い ここで(1)を 使 用 する 方 式 を 例 にとり 説 明 する 今 q の 上 位 i-1 番 目 までが 求 められてい る 場 合 の i 番 目 の bit の 求 め 方 は 以 下 のようになる i-1 番 目 までは 求 めた 値 i 番 目 の 0 i+1 番 目 以 降 はすべて 0 とした 暗 号 文 g と i 番 目 を 1 にした g を 用 意 する そして 2つの 暗 号 文 の 復 号 を 依 頼 しその 処 理 時 間 の 差 を 計 測 する もし 処 理 時 間 の 差 が 大 きければ g <q<g が 成 立 しているので q の i 番 目 のビットは 1 である もし 処 理 時 間 の 差 が 小 さ ければ g <g < qが 成 立 しているので q の i 番 目 のビットは 1 である 以 上 のような 判 定 を 利 用 し q の 半 分 以 上 の 上 位 ビットを 求 め その 後 Coppersmith のアルゴリズム[47] により 完 全 な 因 数 分 解 を 実 行 して 秘 密 鍵 を 得 る 80

82 彼 らは Optimized, Unoptimaized 双 方 のコンパイルによって 生 成 した OpenSSL につい て 攻 撃 可 能 であり Unoptimized な OpenSSL においては 以 下 のクエリ( 復 号 要 求 )で 秘 密 鍵 が 求 められると 指 摘 している また LAN 環 境 においても 評 価 を 実 施 し ネ ットワーク 環 境 下 でも 攻 撃 可 能 であると 結 論 付 けている TLS 1.1 の RFC ドラフトにおい ては 本 攻 撃 に 対 する 対 策 が 明 記 されていることから 最 新 の 実 装 には 対 策 は 行 われてい ると 考 えられる 81

83 2.2. プロトコル 上 のセキュリティホールとその 対 策 以 下 に SSL3.0 プロトコルに 対 する 攻 撃 法 とその 対 策 を 列 挙 する Man-in-the-middle attack 攻 撃 者 がサーバ クライアントの 間 に 入 り サーバに 対 してはクライアント クライアン トに 対 してはサーバになりすまし 情 報 を 盗 聴 あるいは 改 竄 を 試 みる 攻 撃 方 法 である SSL には (1) 相 互 認 証 (2)サーバ 認 証 のみ (3) 匿 名 の3 種 類 の 認 証 モードがあり それらを 選 択 可 能 となっている (1) (2)の 場 合 公 開 鍵 証 明 書 を 使 用 し 公 開 鍵 が 正 当 であることの 検 証 が 行 われるため この 攻 撃 に 対 して 安 全 である しかしながら (3)の 場 合 には 一 般 的 な Man-in-the-middle 攻 撃 が 可 能 であり 利 用 することは 推 奨 されない Replay attack 攻 撃 者 はサーバやクライアントの 通 信 を 盗 聴 し それを 再 送 信 することによりなりすます 攻 撃 である 本 攻 撃 は 通 信 路 が 暗 号 化 されていたとしても 暗 号 化 後 のデータを 用 いる ため 実 行 可 能 である しかし SSLにおいては 鍵 交 換 方 式 ごとにそれぞれ 以 下 のような 対 策 を 講 じており 攻 撃 は 成 功 しない (i) RSA 認 証 RSA を 用 いる 場 合 鍵 交 換 とサーバ 認 証 は 同 時 に 行 われる 公 開 鍵 は server key exchage におけるサーバの 証 明 書 もしくは temporary RSA key に 含 まれる Temporary RSA key が 用 いられる 場 合 サーバによる RSA もしくは DSA 署 名 がされる 署 名 には ClientHello.random が 含 まれるため replay 攻 撃 はできない (ii) Diffie-Hellman Diffie-Hellman 鍵 交 換 を 用 いる 場 合 サーバは fixed Diffie- Hellman parameter を 含 む 証 明 書 を 用 いるか DSS もしくは RSA 署 名 されている temporary Diffie-Hellman parameter (ephemeral Diffie-Hellman)を 用 いる Temporary Diffie Hellman parameter は hello.random の 値 とともに 署 名 されるため replay 攻 撃 はできない また クライアントは 証 明 書 や 署 名 を 検 証 することにより paramater がサーバのものであることを 知 ることがで きる また シーケンス 番 号 については HMAC を 使 用 してその 正 当 性 を 保 証 しているため この 点 からも replay 攻 撃 は 困 難 であると 考 えられる 82

84 Version rollback attack 攻 撃 者 が SSL3.0 に 対 応 しているサーバ クライアントに 対 して SSL2.0 やそれ 以 下 の Version で 通 信 を 行 うように 強 制 する 攻 撃 法 である 3.0 以 上 のサーバは non-random PKCS#1 block type 2 message padding を 使 用 しているため 攻 撃 を 検 出 することが 可 能 である しかし 攻 撃 者 が 暗 号 化 鍵 を 総 当 たり 攻 撃 により 解 読 し アプリケーションによ り 設 定 されている 待 ち 時 間 以 内 に 新 しい ENCRYPTED- KEY- DATA を 代 わりに 送 るこ とができれば 攻 撃 は 成 功 する しかしながら 本 攻 撃 についても 鍵 長 を 長 く 取 ることで 防 ぐことが 可 能 である Ciphersuite rollback attack 攻 撃 者 が サーバ クライアントの hello メッセージに 含 まれる ciphersuite を 改 ざんし 鍵 長 が 短 く 弱 い 暗 号 方 式 や メッセージ 認 証 なしなど 攻 撃 者 が 望 む ciphersuite をサーバ クライアントに 強 制 する 攻 撃 法 である 本 攻 撃 は SSL2.0 においては 有 効 な 攻 撃 方 法 であ ったが SSL3.0 においては change cipher spec, alert messaを ge除 くすべてのメッセー ジについて master_secret を 使 用 して HMAC を 作 成 し それを finished メッセージにて 交 換 し メッセージ 認 証 を 行 うため 成 功 しない Key-exchange algorithm rollback attack 攻 撃 者 は server key exchange メッセージ 内 の KeyExchangeAlgorithm が 署 名 対 象 デー タとなっていないことを 利 用 し このフィールドを 改 ざんし man-in-the-middle attack を 成 功 させる 攻 撃 方 法 である 攻 撃 においては サーバには ephemeral Diffie-Hellman 鍵 交 換 アルゴリズムを クライアントには RSA を 使 用 させるよう 改 ざんする すなわち 攻 撃 者 は 以 下 のような 手 順 によって サーバ クライアント 双 方 の pre_master_secret を 取 得 する (C をクライアント S をサーバ M を 攻 撃 者 とし {}x は x で 署 名 することを 表 す ) [client hello:] 1. C M:SSL_RSA_ 1. M S:SSL_DHE_RSA_ [server hello:] 2. S M:SSL_DHE_RSA_ 2. M C:SSL_RSA [server key exchange:] 83

85 3. S M:{p,g,y}Ks 3. M C:{p,g,y}Ks [Client key exchange:] 4. C M:k g mod p 4. M S:g x mod p クライアントCは k を サーバSは g xy mod p を pre_master_secret とする 攻 撃 者 Mは その 両 方 を 所 持 することができる 従 って 偽 の finished メッセージを 容 易 に 作 成 することが 可 能 であり man-in-the-middle attack は 成 功 する Cut-and-paste attack 別 セッションなどで 盗 聴 した 暗 号 文 をセッション 中 でやり 取 りされる ciphertext に 継 接 ぎ する 攻 撃 方 法 である 例 えば 暗 号 文 中 にある hostname を 別 のセッションで 入 手 した 暗 号 化 された hostnameで 置 き 換 える その 結 果 復 号 化 したクライアントは 別 の hostname を 得 るため その 改 ざんされたアドレスにアクセスを 行 ったり DNS lookup やエラーメッ セージなどを 平 文 で 送 信 したりする 可 能 性 がある 攻 撃 者 は アクセス 先 にトラップを 仕 掛 けたり 送 信 された 平 文 を 盗 聴 したりすることで 重 要 な 情 報 を 得 ることが 可 能 となる 本 攻 撃 法 は IPSec などに 対 しては 有 効 な 攻 撃 方 法 であると 提 案 されたが[26] SSL3.0 は 暗 号 化 鍵 をセッションごとに 作 成 するため 攻 撃 が 成 功 することはない Short-block attack 本 攻 撃 法 は Bellovin が IPSec に 対 して 考 案 した 攻 撃 法 [26]であり 最 後 のメッセージブロ ックが1byte の 平 文 とランダムパディングから 構 成 されている 場 合 の 実 行 可 能 な 攻 撃 法 で ある 攻 撃 者 は 上 記 のメッセージブロックを 用 意 した 既 知 の 暗 号 文 / 平 文 対 の 暗 号 文 で 置 き 換 える データを 受 け 取 る 側 は 復 号 化 しパディングを 除 いた 状 態 で TCP チェックサ ムによって 検 証 を 行 うため もし 使 用 した 暗 号 文 のメッセージブロックに 相 当 する 部 分 が 正 しくなければ エラーパケットとして 破 棄 される 推 測 した 暗 号 文 が 正 しかった 場 合 に は ACK が 返 信 されるため これを 利 用 して 正 しい 平 文 を 求 めることができる 従 って 利 用 する 既 知 暗 号 文 / 平 文 対 の 数 は 高 々2 8 程 度 である SSL3.0 においては パディングは アプリケーションレイヤーで 行 われ また ACK を 返 すような 処 理 は 行 われないため 本 攻 撃 はほとんど 不 可 能 であると 考 えられる 84

86 Dropping the change cipher spec message 本 攻 撃 方 法 は change cipher spec が finished メッセージの 認 証 対 象 データでないことを 利 用 して 攻 撃 者 がこのメッセージを 削 除 することによって 送 信 先 の cipher spec の 更 新 を 阻 害 し finished メッセージやそれ 以 降 のデータをメッセージ 認 証 なしに 設 定 する 攻 撃 方 法 である これは Change cipher spec を 受 信 しない 場 合 cipher spec はデフォルトの 状 態 ( 暗 号 化 メッセージ 認 証 ともに null)のまま 更 新 されないためである なお 本 攻 撃 は master_secret を 取 得 する 攻 撃 ではないため ciphersuite を 暗 号 化 なし のパラメ ータに 設 定 した 場 合 にのみ 実 行 可 能 である 攻 撃 の 手 順 は 以 下 のようになる (C をクライ アント S をサーバ M を 攻 撃 者 とし {}kはkを 使 用 して MAC 値 を 付 加 することを 表 す ) 1. C M:[change cipher spec] 2. C M:[finished:]{a}k 2. M S:[finished:]a 3. S M:[change cipher spec] 4. S M:[finished:]{a}k 4. M C:[finished:]a 5. C M:{m}k 5. M S:m 以 上 の 手 順 によって Client Server 共 に メッセージ 認 証 なし の 状 態 でメッセージを 受 信 するため 攻 撃 者 はクライアント サーバ 間 でやりとりされるメッセージを 自 由 に 改 ざんできるようになる 本 攻 撃 は 常 に 暗 号 化 あり の ciphersuite を 選 択 することで 防 ぐことが 可 能 である なお TLS においても 同 様 の 脅 威 が 存 在 する Attack against finished messages finished メッセージに 中 には master_secret が 含 まれているため 同 時 に 多 くのセッション を 張 り finished メッセージを 多 数 収 集 することで master_secret を 推 測 できる 可 能 性 があ る finished メッセージは adhoc-mac と 呼 ばれる MAC 計 算 によって 求 められているが 暗 号 化 なし の ciphersuite を 選 択 していた 場 合 には finished メッセージに 含 まれる master_secret 以 外 のパラメータは 容 易 に 推 測 可 能 であり finished メッセージを 収 集 する ことで master_secret を 求 めることができる 可 能 性 がある TLS においては adhoc-mac は HMAC と 呼 ばれる 方 式 に 変 更 されており master_secret が 攻 撃 者 によって 求 められ る 可 能 性 は ほとんど 無 いと 考 えられる 85

87 Traffic analysis 攻 撃 者 が 流 れているデータを 解 析 することによって IP アドレス URL のデータ 長 html のデータ 長 を 知 ることが 可 能 である 本 攻 撃 は 暗 号 文 を 盗 聴 し そのデータ 長 から 平 文 のデータ 長 を 推 測 することによって 重 要 なデータを 推 測 する 攻 撃 法 である SSL では ブロック 暗 号 においてはパディング 長 を 設 定 するフィールドが 存 在 するため このフィー ルドを 利 用 しパディング 長 をランダム 化 することによって 攻 撃 を 防 ぐことが 可 能 である しかしながら ストリーム 暗 号 方 式 ではパディング 長 を 設 定 する 項 目 がないため Traffic analysis によって 暗 号 文 のデータ 長 から 平 文 のデータ 長 を 推 測 することは 容 易 に 可 能 であ る このことを 利 用 して 攻 撃 者 はURL 長 html ファイル 長 などの 情 報 を 知 ることがで きる これらの 情 報 が 漏 洩 することが 直 ちに 重 大 な 脅 威 とはなり 得 ないが 攻 撃 者 にとっ ては 情 報 取 得 の 足 がかりとなるため 注 意 を 要 する Attack against a resuming session 1 度 確 立 されたセッションが 休 止 状 態 になり その 後 再 び 接 続 されるときには 新 しい ClientHello.randam, ServerHello.randam が 前 セッションの master_secret を 使 用 した MAC がクライアント サーバ 間 で 交 換 される 従 って master_secret を 知 らない 攻 撃 者 は なりすまし 攻 撃 を 行 うことはできないと 考 えられる 86

88 2.3. 実 装 上 のセキュリティホールとその 対 策 (2002 年 3 月 まで) 以 下 に 現 在 報 告 されている 実 装 上 のセキュリティホールとその 対 策 を 示 す また SSL や TLS というキーワードで 検 索 されるが 直 接 SSL の 脆 弱 性 ではないセキュリティホールも 参 考 のため 示 す Interner Explorer HTTPS certificate attack (Internet Explore rの HTTPS(SSL)に 対 する 攻 撃 ) Bypassing Warning For Invalid SSL Certificates In Internet Explorer 攻 撃 をうけるソフトウェアおよびそのバージョン: Microsoft Internet Explorer 4.0 Microsoft Internet Explorer 5.0 Microsoft Internet Explorer 6.0 内 容 : 攻 撃 者 ( 不 正 なサーバ)はクライアントに 対 して 不 正 な 証 明 書 の 警 告 をなくすことができ る ここで 不 正 な 証 明 書 とは クライアントがアクセスするホスト 名 とは 異 なるホスト 名 が 記 載 された 証 明 書 である ただし この 証 明 書 は 正 当 な CA により 発 行 されたものでなけ ればならない 詳 細 : Internet Explorer における 以 下 の2 点 の 欠 陥 により 攻 撃 が 可 能 となる (1) 初 めてホストに SSL を 用 いてアクセスするとき 証 明 書 の 検 証 は 行 われるが それ 以 降 同 一 のホストに 対 して 検 証 を 行 わない (2) HTML ファイルに 含 まれるイメージタグやフレームに HTTPS を 用 いるファイルがリン クされている 場 合 証 明 書 におけるホスト 名 の 検 証 を 行 わない ( 証 明 書 そのものの 検 証 は 行 う ) 例 えば HTTP や HTTPS の 通 信 において< img src = width=1 height=1 >という 記 述 によ って 対 象 のファイルが GET される 場 合 HTTPS 通 信 を 行 いサーバ 証 明 書 の 正 当 性 を 検 証 するが 証 明 書 に 記 載 されているホスト 名 とアクセスするホスト 名 の 比 較 を 行 わない 攻 撃 者 はクライアントに(2)を 用 いて 不 正 な 証 明 書 を 受 理 させる 次 に(1)により 不 正 な 証 明 書 をもつホストと SSL 通 信 を 行 わせることができる 対 策 : パッチを 当 てることにより 証 明 書 記 載 のホスト 名 とアクセスするホスト 名 が 異 なる 場 合 は 警 告 を 出 すようにする 87

89 Bypassing Warnings For Invalid SSL Certificates In Netscape Navigator (Netscape Navigato r において 不 正 な SSL 証 明 書 に 対 する 警 告 を 迂 回 する 攻 撃 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Netscape Communicator 4.0 Netscape Communicator4.05 Netscape Communicator4.06 Netscape Communicator4.07 Netscape Communicator4.5 Netscape Communicator4.51 Netscape Communicator4.6 Netscape Communicator4.61 Netscape Communicator 4.7 Netscape Communicator, 4.72 内 容 : 攻 撃 者 ( 不 正 なサーバ)はクライアントに 対 して 不 正 な 証 明 書 の 警 告 をなくすことがで きる 不 正 な 証 明 書 とは クライアントがアクセスするホスト 名 とは 異 なるホスト 名 が 記 載 された 証 明 書 である ただし この 証 明 書 は 正 当 な CA により 発 行 されたものでなければ ならない 詳 細 : Netscape Navigator における 以 下 の 欠 陥 により 攻 撃 が 可 能 となる (1) 初 めてホストに SSL を 用 いてアクセスするとき 証 明 書 の 検 証 が 行 われるが それ 以 降 同 一 のホストに 対 して 検 証 を 行 われない (2) 証 明 書 に 記 載 されたホスト 名 と クライアントがアクセスするホスト 名 の IP アドレ スを 比 較 するが ホスト 名 の 比 較 が 行 わない 攻 撃 者 はあらかじめ1つの IP アドレスに 複 数 のホスト 名 を 割 り 当 てる そして (2)に より 特 定 の IP アドレスにアクセスさせて 証 明 書 を 受 理 させ (1)によりクライアントに IP は 上 記 のホストと 等 しいが 異 なるホスト 名 が 記 載 された 証 明 書 をもつホストと HTTPS 通 信 を 行 わせることができる ただし 攻 撃 者 は DNS スプーフもしくは 不 正 な DNS サー バを 用 いなければならない 攻 撃 できない 対 策 : パッチを 当 てることにより 認 証 を 行 う 際 の 確 認 を IP アドレスではなくホスト 名 で 行 うよ うにする 88

90 Multiple Vendor SSL Certificate Validation Vulnerability ( 複 数 のブラウザにおける SSL 認 証 の 脆 弱 性 ) 攻 撃 を 受 けるソフトウェアおよびそのバージョン: Links Links0.96 University of Kansas Lynx2.7 University of Kansas Lynx 2.8 University of Kansas Lynx 2.84 W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M W3M 0.2 W3M W3M W3M W3M W3M W3M 内 容 : W3M,Lynx,Links などブラウザの 初 期 のバージョンは SSL が 実 装 されているが 証 明 書 検 証 機 能 が 実 装 されていない このことから 攻 撃 者 は 正 規 のサーバになりすますことができる また man-in-the-middle attack も 可 能 である 対 策 : 認 証 機 能 を 実 装 する 89

91 RSA BSAFE SSL-J Authentication Bypass Vulnerability (RSA BSAFE SSL-J における 認 証 迂 回 の 脆 弱 性 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Cisco icdn 2.0 RSA Security BSAFE SSL-J SDK Cisco icdn 2.0 RSA Security BSAFE SSL-J SDK RSA Security BSAFE SSL-J SDK 3.1 Cisco icdn には 脆 弱 性 はない 内 容 : SSL においてクライアント 認 証 が 行 われる 場 合 攻 撃 者 はクライアント 認 証 を 迂 回 しサーバ にアクセスすることができる 詳 細 : RSA BSAFE は RSA 社 によって 開 発 された 暗 号 化 ソフトウェア 開 発 環 境 である この 問 題 は BSAFE-J をもちいて SSL 通 信 を 行 うプログラムを 作 成 し プログラムの 中 でクライアント 認 証 を 行 う 場 合 に 発 生 する SSL において 同 一 のクライアントによる 連 続 したセッションは 一 度 クライアント 認 証 が 行 われるが それ 以 降 の 通 信 においてキャッシュされ 留 ため クラ イアント 認 証 が 行 われない RSA BSAFE-J3.x はこの SSL セッションキャッシュに 不 具 合 が あり 認 証 されていないクライアントが 認 証 されているクライアントになりすまし 認 証 されたクライアントだけにアクセスを 許 すデータにアクセスできる 可 能 性 がある セッシ ョンキャッシュの 不 具 合 は クライアントが handshake しているときエラーが 起 こった 場 合 に 発 生 する エラーが 起 こったときセッション ID は 破 棄 されるべきであるがキャッシュ に 保 存 されてしまう そして 次 にクライアントが SSL によってアクセスする 際 にクライ アント 認 証 が 行 われずに 通 信 が 開 始 される 対 策 : 不 具 合 の 修 正 90

92 OpenSSL PRNG Internal State Disclosure Vulnerability (OpenSSL の 疑 似 乱 数 生 成 器 (PRNG)の 内 部 状 態 を 暴 露 する 攻 撃 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: OpenSSL Project OpenSSL 0.9.1c OpenSSL Project OpenSSL 0.9.2b OpenSSL Project OpenSSL OpenSSL Project OpenSSL OpenSSL Project OpenSSL OpenSSL Project OpenSSL Frederik Vermeulen QMail tls.patch OpenSSL Project OpenSSL SSLeay SSLeay SSLeay SSLeay 0.9 SSLeay SSLeay 内 容 : 攻 撃 者 が SSL に 用 いられる 乱 数 生 成 器 の 内 部 状 態 を 知 ることができる 内 部 状 態 から 疑 似 乱 数 を 推 測 しセッション 鍵 を 推 測 できる 可 能 性 がある ただし OpenSSL を 用 いた 一 般 的 な アプリケーションにおいてこの 問 題 は 発 生 しない 詳 細 : SSL の 実 装 において 乱 数 生 成 のために 疑 似 乱 数 生 成 器 を 用 いる 上 記 の OpenSSL における 疑 似 乱 数 生 成 器 には 設 計 上 の 欠 陥 が 存 在 しており 攻 撃 者 は 1byte の PRNG 要 求 を 数 百 回 を 行 うことにより PRNG の 内 部 状 態 を 再 構 成 することができる 内 部 状 態 は2つの 変 数 md, state によって 決 められる md はハッシュ 関 数 の 出 力 によって 決 められる 連 鎖 的 な 値 である(160bit) そして state は md より 大 きな 値 であり 暗 号 化 されている 疑 似 乱 数 を 生 成 する 際 に md は 以 前 の 値 の 半 分 と state の 一 部 からなる 値 をハッシュす ることにより 得 られる しかし md 生 成 の 入 力 における 半 分 の 値 は PRNG の 出 力 の 半 分 の 値 と 同 じ 値 である また state から 得 られる 値 は PRNG 出 力 として 要 求 されるバイト 数 に 依 存 するものである このことから 攻 撃 者 は 簡 単 な brute-force 解 析 により 内 部 状 態 を 再 構 成 できる 対 策 : md を 更 新 する 際 に 以 前 の md の 値 をすべてハッシュする また state からの 値 は PRGN に 要 求 されるバイト 数 と 独 立 な 値 とする 91

93 Microsoft IE SSL Spoofing Vulnerability (Internet Explorer の SSL なりすまし 攻 撃 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Microsoft Internet Explorer 5.01 Microsoft Internet Explorer 5.0.1SP1 Microsoft Internet Explorer 5.0.1SP2 Microsoft Internet Explorer 5.5 Microsoft Internet Explorer 5.5SP1 Microsoft Internet Explorer 5.5SP2 以 降 問 題 はない 内 容 : 攻 撃 者 は 他 のサイトになりすますことができる 詳 細 : Internet Explorer を 用 いてブラウジングする 場 合 ユーザはアクセスしているサイトの 情 報 をアドレスバーから 知 ることになる しかし 上 記 の Intermet Explorer はフレームや JavaScript などを 用 いることによりアドレスバーに 任 意 の 文 字 列 を 表 示 できる 欠 陥 が 存 在 する これにより 攻 撃 者 は 見 かけ 上 別 のサイトになりすますことができる よって 攻 撃 者 はアドレスバーのアドレスと SSL の 証 明 書 に 記 載 されているアドレスが 異 なる SSL 通 信 を 行 える 対 策 : 不 具 合 の 修 正 92

94 Netscape Communicator Inconsistent SSL Certificate Warning Vulnerability (Netscape Communicator の 不 正 な SSL 証 明 書 に 対 する 警 告 を 迂 回 する 攻 撃 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Netscape Communicator 4.0 Netscape Communicator 4.5 Netscape Communicator Netscape Communicator 4.6 Netscape Communicator Netscape Communicator 4.7 Netscape Communicator Netscape Communicator 内 容 : 攻 撃 者 は Netscape Navigato r を 使 用 するクライアントに 対 して 不 正 な SSL の 証 明 書 の 警 告 をなくすことができる 詳 細 : 上 記 のバージョンの Netscape Navigator は 不 正 なサーバ 証 明 書 を 受 け 取 ったとき hostname does not match name in certificate" という 警 告 を 表 示 する しかし このときユーザが continue ボタンをクリックすると それ 以 降 その Netscape のセッションにおいて ホスト 名 や IP アドレスが 異 なる 証 明 書 を 受 理 してしまう 対 策 : 不 具 合 の 修 正 93

95 OpenSSL Unseeded Random Number Generator Vulnerability (OpenSSL の seed をなしの 疑 似 乱 数 の 脆 弱 性 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: OpenSSL Project OpenSSL 0.9.1c OpenSSL Project OpenSSL 0.9.2b OpenSSL Project OpenSSL OpenSSL Project OpenSSL OpenSSL Project OpenSSL において 修 正 されている 内 容 : 攻 撃 者 が SSL に 用 いられる 乱 数 生 成 器 において seed によって 初 期 化 されない 可 能 性 がある これにより 疑 似 乱 数 を 推 測 しセッション 鍵 を 推 測 できる 可 能 性 がある 詳 細 : OpenSSL はクライアントがサーバと SSL/TLS の handshake を 初 期 化 する 時 にSSL_connect() という 関 数 を 用 いる この 関 数 は 疑 似 乱 数 生 成 器 を seed によって 確 実 に 初 期 化 しないため 完 全 な 疑 似 乱 数 生 成 器 ではなくなってしまう この 問 題 は qmail の 非 公 式 パッチ tls.patch において 知 られている このパッチにおいて 乱 数 生 成 器 は seed を 使 っていない 対 策 : SSL_connect()において 疑 似 乱 数 生 成 器 を seed によって 初 期 化 する 94

96 IIS / Site Server Multithread SSL Vulnerability (ISS サーバのマルチスレッド SSL における 脆 弱 性 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Microsoft IIS Cisco Building Broadband Service Manager Cisco Call Manger 1.0,2.0,3.0 + Cisco ICS Cisco IP/VC Cisco Unity Server 2.0,2.2,2.3,2.4 + Cisco uone 1.0,2.0,3.0,4.0 + Microsoft BackOffice 4.0,4.5 + Microsoft Windows NT 4.0 Option Pack Microsoft Site Server Commerce Edition Microsoft IIS Microsoft Windows NT 4.0 Microsoft Site Server Commerce Edition Microsoft BackOffice 4.0,4.5 + Microsoft Commercial Internet System Microsoft Site Server Commerce Edition 3.0 内 容 : 特 定 の 条 件 下 において サーバがクライアントに 暗 号 文 を 平 文 のまま 送 ってしまう 詳 細 : IIS4 の SSL ISAPI フィルタにはクライアントに 暗 号 文 を 平 文 のまま 送 ってしまう 脆 弱 性 が ある この 欠 陥 はフィルタが 同 じスレッドで 動 作 していることが 原 因 である 高 負 荷 状 態 において 複 数 スレッドのクライアントアプリケーションが 接 続 した 場 合 サーバは 暗 号 化 せずにデータを 送 信 してしまい 接 続 を 終 了 する この 際 に もし 攻 撃 者 が 通 信 を 盗 聴 し ていたならば 通 信 を 平 文 のまま 受 け 取 ることができる 対 策 : 不 具 合 の 修 正 95

97 NT IIS SSL DoS Vulnerability (NT 上 の IIS において SSL によるの DoS 攻 撃 が 可 能 になる 脆 弱 性 ) 攻 撃 をうけるソフトウェアおよびそのバージョン: Microsoft IIS Microsoft Windows NT Microsoft Windows NT 4.0SP1,SP2,SP3,SP4,SP5,SP6,SP6a Microsoft IIS Cisco Building Broadband Service Manager Cisco Call Manger 1.0,2.0,3.0 + Cisco ICS Cisco IP/VC Cisco Unity Server 2.0,2.2,2.3,2.4 + Cisco uone 1.0,2.0,3.0,4.0 + Microsoft BackOffice 4.0,4.5 + Microsoft Windows NT 4.0 Option Pack 内 容 : NT サーバ 上 の SSL を 実 装 した IIS は DoS 攻 撃 を 受 ける 可 能 性 がある 詳 細 : 上 記 の IIS は SSL 通 信 を 要 求 されたページとそうでないページの 違 いを 区 別 できない.こ れにより URL の http という 文 字 列 を https に 変 えることによりサーバはすべてのコ ンテンツを 暗 号 化 しようとする このように 攻 撃 者 が https 要 求 をすることによりサーバ の CPU 使 用 率 を 100%とし サーバを 極 端 な 速 度 低 下 や 機 能 停 止 にさせることができる 対 策 : 不 具 合 の 修 正 96

98 Netscape Navigater SSL における 疑 似 乱 数 の seed によるセッション 鍵 の 推 定 に よる 攻 撃 攻 撃 をうけるソフトウェアおよびそのバージョン: Netscape Navigator 1.1 Netscape Navigator2.0 以 降 には 問 題 はない 内 容 : 攻 撃 者 はクライアント サーバ 間 の 通 信 を 盗 聴 することによりセッション 鍵 を 推 定 できる 可 能 性 がある これにより 通 信 の 内 容 を 知 ることができる 可 能 性 がある 詳 細 : この 攻 撃 は 1996 年 に Ian Goldberg と David Wagner によって 発 見 された Netscape Navigator の SSL において challenge-data と secret を 生 成 するための 使 われる 乱 数 生 成 器 の seed は 時 間 の 秒 とマイクロ 秒 pid と ppid の 組 み 合 わせにより 作 られる 以 下 に 疑 似 乱 数 生 成 器 の seed を 生 成 する 関 数 と seed から challenge message や 秘 密 情 報 を 生 成 する 関 数 を 示 す NG_CreateContext(){ (seconds, microseconds) = time of day; /* Time elapsed since 1970 */ pid = process ID; ppid = parent process ID; a = mklcpr(microseconds); b = mklcpr(pid + seconds + (ppid << 12)); seed = MD5(a, b); } mklcpr(x) /* not cryptographically significant; shown for compl eteness */{ return ((0xDEECE66D * x + 0x2BBB62DC) >> 1); } 図 Seed を 生 成 する 関 数 97

99 RNG_GenerateRandomBytes() x = MD5(seed); seed = seed + 1; return x; global variable challenge, secret_key; create_key() RNG_CreateContext(); tmp = RNG_GenerateRandomBytes(); tmp = RNG_GenerateRandomBytes(); challenge = RNG_GenerateRandomBytes(); secret_key = RNG_GenerateRandomBytes(); 図 Challenge message と 秘 密 情 報 を 生 成 する 関 数 攻 撃 者 が Netscape Navigato r が 起 動 されているマシンにアカウントをもつ 場 合 時 間 は time デーモン daytime デーモンや tcpdump の 値 から 推 測 できる また pid,ppid は ps コ マンドにより 容 易 に 得 ることができる よって 攻 撃 者 はマイクロ 秒 の 推 測 (10^6 回 の 計 算 ) 程 度 で seed を 推 測 で 着 る また 攻 撃 者 が Netscape Navigator が 起 動 されているマシンにアカウントを 持 たない 場 合 以 下 の 情 報 により 攻 撃 者 は brute force より 大 幅 に 少 ない 計 算 量 で seed を 推 測 できる 時 間 は 20bit であり pid,ppid は 15bit であり (pid+(ppid<<12))は 27bit である こ れらをあわせると 47bit となり 128bit に 比 べ 大 幅 に 少 ない 攻 撃 者 は 時 間 をある 程 度 知 ることができる ppid は X-windows のメニューから 起 動 された 場 合 1 である ppidが1ではない 場 合 pid より 少 し 小 さい 値 である 個 人 用 のワークステーションの 場 合 pid や ppid は 小 さい 値 である 攻 撃 されるホストに sendmail が 起 動 されている 場 合 その pid は message-id に 含 まれる ことが 多 い この pid をもちいることにより Netcape Navigator の pid 推 測 が 少 し 容 易 になる MS-DOS の 場 合 pid ppid はない よって seed に 使 われていない 可 能 性 がある 疑 似 乱 数 生 成 器 は 接 続 されている 間 seed を 変 えない 対 策 : 疑 似 乱 数 生 成 アルゴリズムの 変 更 98

100 Microsoft IE 4.x, 5.x における Cached Web Credentials 問 題 攻 撃 を 受 けるソフトウェアおよびそのバージョン: MicrosoftInternetExplorer 4.x MicrosoftInternetExplorer 5.x prior to version 5.5 内 容 : SSL 通 信 の 場 合 のみに 用 いられるユーザ ID とパスワードが 盗 まれる 可 能 性 がある 詳 細 : 基 本 認 証 を 使 用 して ユーザがセキュリティで 保 護 された Web ページを 認 証 する 場 合 IE は 使 用 されたユーザ ID とパスワードをキャッシュする この 機 能 により ユーザが 同 じ サイトを 認 証 するときに ユーザ ID とパスワードを 入 力 する 手 間 を 省 くことができる この ID とパスワードは 暗 号 化 されていない 場 合 は 平 文 で 通 信 路 を 送 信 されることになる 一 般 的 に 安 全 なサイトは SSL をもちいることによりパスワードが 平 文 で 送 信 されることが ないように 設 計 されている しかし 上 記 のバージョンの IE は HTTP と HTTPS の 区 別 をせ ずに ID とパスワードを 送 信 するため HTTPS において 暗 号 化 されて 送 信 されるべき ID とパ スワードが HTTP の 場 合 でも 送 信 されてしまう 攻 撃 者 は HTTPS 通 信 を HTTP 通 信 に 置 き 換 えることができた 場 合 ネットワークを 盗 聴 することによりパスワードを 盗 むことができ る 対 策 : 不 具 合 の 修 正 99

101 その 他 SSL というキーワードで 検 索 されるが 直 接 SSL とは 関 係 のないセキュリテ ィホール 以 下 に Cert/CC などセキュリティサイトにおいて SSL というキーワードで 検 索 した 場 合 検 索 されるが SSL や TLS のセキュリティホールとは 関 係 のないセキュリティホールを 示 す (1)CERT/CC SSH デーモン,RSAREF2 ライブラリ,Buffer Overflow 問 題 概 要 RSAREF2 中 の 脆 弱 性 により,ネットワーク 経 由 で 任 意 のコードを 実 行 することが 可 能 とな る 出 典 CA (December 13, 1999),CIAC K-011 (December 21, 1999) 解 説 RSAREF2 の 脆 弱 性 は 暗 号 ライブラリの 問 題 であり SSL 固 有 の 問 題 ではない また 上 記 の 脆 弱 性 は Core SDI ( 報 告 されたものであるが こ のときのサンプルとしては sshd が 用 いられており 実 行 されるための 条 件 として(1) sshd が 実 行 されていること(2)sshd のライブラリとして RSAREF2 が 用 いられているこ との 2 点 が 挙 げられている つまり sshd の 脆 弱 性 と RSAREF2 の 脆 弱 性 を 組 み 合 わせな ければこの 攻 撃 を 実 行 することはできない もし 仮 に SSL の 実 装 において 不 具 合 があり かつ RSAFER2 を 用 いた 場 合 に 脆 弱 性 が 発 生 する 可 能 性 があるが そのような 例 は 確 認 さ れていない (2)Microsoft IIS 4.0/5.0 Session ID Cookie 生 成 における 脆 弱 性 概 要 SSL で 保 護 されたサイトに 対 する Session ID cookie を, 悪 意 のあるユーザに 不 正 に 取 得 されてしまう. 出 典 MS (October 23, 2000),CIAC L-010 (October 24, 2000) 解 説 この 脆 弱 性 は IIS のセッション ID(SSL のセッション ID とは 異 なるもの)の 不 具 合 である IIS がセッション ID を Cookie を 用 いて 管 理 する 場 合 HTTP と HTTPS を 区 別 しないため HTTPS で 暗 号 化 して 共 有 したセッション ID がその 後 もし HTTP で 通 信 した 場 合 平 文 で 送 信 され る 脆 弱 性 である ただし このセッションIDは SSL のセッション ID とはことなるもので ある (3) Microsoft Corporation の 名 を 騙 った 証 明 書 100

102 概 要 VeriSign 社 から,2001 年 1 月 29 日 および 30 日,VeriSign Class 3 (VeriSign Commercial Software Publishers CA)により 署 名 された"Microsoft Corporation" の 名 前 の 記 載 され た 偽 のデジタル 証 明 書 が 2 枚 発 行 された. 出 典 CA (March 22, 2001) 解 説 この 偽 のデジタル 証 明 書 は SSL においてもちいられる 証 明 書 ではなく マイクロソフト のコード 署 名 にもちいられる 証 明 書 である つまり IE を 利 用 しているときにマイクロソ フトによって 署 名 されたコード( 実 行 可 能 なプログラム)とみせかけた 任 意 のコードを 作 成 することができる 脆 弱 性 である ただし 前 述 のように SSL には 一 切 関 係 がない (4)Webシステムにおける 不 正 なHTMLタグ 問 題 概 要 SSL セッションにおいて, 正 規 の HTML タグ(HTML を 記 述 するための 符 号 )の 中 に, 悪 意 を 持 った HTML タグ( 例 えば,Java スクリプトなど)を 紛 れ 込 ませる. 出 典 CA (February 2, 2000),CIAC K-021 (February 3, 2000) 解 説 これは 一 般 的 にクロスサイトスクリプティングと 呼 ばれる 問 題 である SSL の 有 無 に 関 係 なくこの 脆 弱 性 は 存 在 する クロスサイトスクリプティングの 詳 細 は 本 書 の 範 囲 外 であ るので 記 載 しない (5)Cisco VPN3000 Concentrator における TELNET の 脆 弱 性 概 要 Cisco VPN 3000 series concentrators 上 で 動 作 する SSL と telnet サービスの 脆 弱 性 に より,DoS 攻 撃 をかけられるとシステムがリブートする. 出 典 CIAC L-068 (April 6, 2001) 解 説 CiscoVPN が SSL と Telnet を 正 しく 処 理 できない 脆 弱 性 であり SSL のプロトコルや 実 装 とは 直 接 関 係 ない 101

103 2.4. 実 装 上 のセキュリティホールとその 対 策 (2002 年 3 月 以 降 ) ASN.1 に 関 するセキュリティホール [ 概 要 ] ASN.1(Abstract Syntax Notation 1)は 通 信 プロトコルを 記 述 するために 用 いられるもの である SSL/TLS において X.509 証 明 書 のエンコードやプロトコル 記 述 に 用 いられてい る ASN.1 をバイナリデータにエンコードする 方 法 として BER(Basic Encoding Rules) CER(Canonical Encoding Rules) DER(Distinguished Encoding Rules)などが 存 在 する 一 般 に 用 いられる BER DER は 将 来 の 拡 張 にも 対 応 するため 汎 用 的 であるが 実 装 には 適 していない そのため 実 装 上 においてセキュリティホールを 誘 発 する 原 因 となる [ 詳 細 ] 背 景 ASN.1 の 脆 弱 性 はフィンランドの Oulu 大 学 セキュアプログラミンググループ (University Secure Programming Group : OUSPG)によって 発 見 された[57] OUSPG で はプロトコルの 様 々なフィールドに 例 外 データを 挿 入 することにより プロトコル 実 装 の 頑 強 性 を 検 査 する 研 究 を 行 っている 対 象 プロトコルとして WAP HTTP LDAPv3 SNMPv1 SIP などの 調 査 を 行 い 脆 弱 性 を 発 見 している 特 に SNMP(Simple Network Management Protocol)に 関 して MIB 情 報 に 対 しても 調 査 を 行 った MIB 情 報 は ASN.1 により 記 述 される OID(Object Identifier)である MIB 情 報 に 対 する 調 査 の 結 果 複 数 の 脆 弱 性 が 発 見 された 前 述 のように ASN.1 は SNMP の MIB だけでなく 幅 広 く 利 用 されてお り X.509 の 証 明 書 にも 利 用 されている そこで 他 の ASN.1 により 記 述 されるプロトコ ルににおいて 同 様 の 脆 弱 性 の 存 在 が 危 惧 されている ASN.1 の BER エンコード 問 題 点 ASN.1 は ISO と ITU-T によって 規 定 されており 本 来 の 目 的 は 通 信 のプロトコルを 記 述 するための PDU(Protocol Data Unit)の 定 義 であるが 階 層 的 なデータの 表 現 のために 使 用 できる BER は 汎 用 的 なエンコードとするため 各 フィールドのサイズが 可 変 である 可 変 サイズのフィールドは 汎 用 的 にエンコードする 方 法 としては 有 効 であるが 実 装 にお いては 有 効 ではない フィールドが 可 変 長 の 汎 用 的 な ASN.1/BER エンコーダー デコーダ ーを 実 装 する 場 合 注 意 深 く 実 装 しなければ 特 定 の 入 力 に 対 してリソースが 枯 渇 し DoS(Denial of Service) 状 態 や BoF(Buffer Overflow)が 発 生 する 可 能 性 がある ASN.1 における BER によるエンコードの 詳 細 ASN.1 の BER によるエンコードは 図 のように 規 定 される データの 種 類 (Identifier) データの 長 さ(Length) データの 内 容 (Contents)が 順 に 格 納 される Identifier octets にはエンコードされた ASN.1 のタグ Length octets にはエンコードされた Contents 102

104 octets のバイト 数 など,Contents octets にはエンコードされたデータ End-of-contents octets は Length octets が Infinite 形 式 の 場 合 存 在 し 規 定 のエンコードをされたデータが 入 る Figure2 形 式 を 使 用 する 場 合 End-of-content octets まで 任 意 のサイズの content を 格 納 することができるためサイズが 可 変 である また Identifier octets は 図 に 示 すよう に Figure 3 の low tag number (31 より 小 さい 場 合 )ではサイズが 固 定 であるが Figure 4 の high tag number ではエンコードすることにより 任 意 のサイズを 指 定 できる さらに Length octets は short form (127 より 小 さい)ではサイズが 固 定 であるが long form では エンコードすることにより 任 意 のサイズを 指 定 できる Identifier octets Length octets Contents octets The number of octets in the contents octets (see ) X.690_F1 Figure 1 Structure of an encoding Identifier octets Length octets Contents octets End-of-contents octets Indicates that the contents octets are terminated by end of contents octets (see ) Indicates that there are no further encodings in the contents octets X.690_F2 Figure 2 An alternative constructed encoding 図 ASN.1 BERエンコードの 構 造 [58] 103

105 Identifier octet Bits Class P/C Tag number 0 = Primitive 1 = Constructed X.690_F3 Figure 3 Identifier octet (low tag number) Subsequent octets Leading octet 2nd octet Last octet Class P/C = Number of tag X.690_F4 Figure 4 Identifier octets (high tag number) 図 Identifier octetsの 構 造 [58] OpenSSL の ASN.1 脆 弱 性 に 関 して OpenSSL における ASN.1 の BER エンコードにおける 脆 弱 性 は 複 数 回 報 告 されている はじめに 2002 年 7 月 30 日 に Adi Stav <[email protected]>, James Yonan <[email protected]>それぞれによって 個 別 に 発 見 された OpenSSL の Adversary[59]によると 脆 弱 性 は 以 下 のとおりである Length octetsがc 言 語 におけるデータのサイズとして sizeof(long)に 示 され るサイズを 越 すとき asn1_get_length() 関 数 が 与 えられたバッファーの 大 き さを 越 えてしまうことにより DoS を 発 生 する 次 に 2003 年 9 月 30 日 に NISCC によって 発 見 された[60] OpenSSL の Adversary[61] によると 脆 弱 性 の 詳 細 は 以 下 の 4 点 である 1,2,3 はクライアント 証 明 書 に 関 するもので あるため リモートからの 実 行 は 不 可 能 であるが 4 によりリモートから SSL 接 続 できる サーバに 対 して 攻 撃 が 可 能 となる 104

106 1. ASN.1の 構 造 としては 正 しいが ASN.1パーザーが 無 効 と 判 断 する 入 力 が 行 われたとき 該 当 する 構 造 体 の 一 部 が 正 しく 開 放 されない そのため DoS 状 態 に 陥 らせることができる また 任 意 のコードの 実 行 ができる 可 能 性 が あると 報 告 されている 2. long form のタグを 正 しく 解 釈 できないため 境 界 を 超 えて 読 み 取 りが 実 行 される そのため リモートからサーバを DoS 状 態 に 陥 らせることができ る 3. デバッグモードにおいて 公 開 鍵 のデコードエラーを 無 視 するように 設 定 し ているとき 不 正 な 公 開 鍵 証 明 書 の 公 開 鍵 に 対 するエラー 確 認 が 行 われな い そのため 不 正 な 公 開 鍵 (NULL)によりサービス 不 能 に 陥 らせることが できる ただし 通 常 はデバックモードに 設 定 されていない 4. プロトコルハンドリングにおけるエラーによって サーバは 特 別 要 求 しない ときにクライアント 証 明 書 をパーズする これ 自 身 は 特 に 言 及 される 脆 弱 性 ではないが 上 記 の 脆 弱 性 を 用 いることにより クライアント 認 証 を enable にしない SSL/TLS サーバにも 攻 撃 ができる さらに 2003 年 11 月 4 日 NISCC によって 以 下 の 脆 弱 性 が 報 告 された[62] OpenSSL の Adversary[63]によると 脆 弱 性 は 以 下 のとおりである OpenSSL では 任 意 のコードを 実 行 できることはないと 主 張 している[63]が NISCC では 任 意 のコードを 実 行 できる 可 能 性 があると 主 張 している[62] ASN.1 としては 構 造 としては 正 しいが 大 きな 繰 り 返 し 構 造 を 正 しく 処 理 で きない そのため OpenSSL におけるクライアント 証 明 書 などの ASN.1 構 造 においてそのような 値 を 設 定 することにより リモートから SSL/TLS サーバ をサービス 不 能 に 陥 らせることができる このように OpenSSL において ASN.1 に 関 する 脆 弱 性 は 度 重 なり 報 告 されている 前 述 のように ASN.1 のエンコードはセキュリティホールを 発 生 させやすいため 今 後 も 発 生 する 可 能 性 がある 攻 撃 の 実 行 可 能 性 Buffe Overflow による 脆 弱 性 は 理 論 上 攻 撃 が 成 功 する 可 能 性 があれば 報 告 されるが す べての 攻 撃 が 実 行 可 能 であるとは 限 らない 上 記 脆 弱 性 に 関 しては 任 意 のコードを 実 行 できる exploit code(セキュリティホールを 実 証 するためのプログラム)は 今 回 の 調 査 の 範 囲 では 公 開 されていないが DoS を 発 生 させる exploit code は 2004 年 1 月 15 日 bugtraq メ ーリングリストに 投 稿 された[64] また 任 意 のコードを 実 行 できる exploit codeは 存 在 し ないことが 証 明 されたわけではないため 予 断 を 許 さない SSL/TLS 以 外 のプロトコルにおける 問 題 ASN.1 は SNMP SSL/TLS だけでなく 広 く 利 用 されている SNMP の MIB および SSL/TLS 以 外 の 脆 弱 性 として SIP(Session Initiation Protocol)[65] および 105

107 SMIME(PKCS#7)[66]において 報 告 されている また 今 後 も ASN.1 を 利 用 する 他 のプロ トコルにおいて 脆 弱 性 が 発 見 される 可 能 性 が 高 い さらに Microsoft 社 の OS である Windows においても 脆 弱 性 が 発 見 された [67] [ 対 策 ] 脆 弱 性 が 発 見 された 場 合 脆 弱 性 に 対 処 するための 修 正 プログラムが 公 開 される した がって 以 下 の 3 点 の 対 策 をすべきである 脆 弱 性 に 関 する 情 報 を 継 続 的 に 収 集 すること 脆 弱 性 修 正 プログラムが 存 在 する 場 合 は 早 期 に 適 用 すること 最 新 バージョンのソフトウ ェアを 利 用 すること 脆 弱 性 を 利 用 した 攻 撃 が 行 われたかどうか 監 視 すること また SSL/TLS を 用 いて 認 証 するとき 認 証 相 手 に 脆 弱 性 が 存 在 するとき 最 悪 の 場 合 には 秘 密 鍵 が 漏 洩 している 可 能 性 があるため 認 証 結 果 は 信 用 できない 106

108 Buffer Overflow による 脆 弱 性 [ 概 要 ] Buffer Overflow による 脆 弱 性 は 主 に C 言 語 におけるプログラム 不 具 合 が 原 因 となり DoS を 発 生 させることや 任 意 のコードを 実 行 させることができる 前 回 報 告 以 降 にも 多 く の 実 装 において 同 種 の 脆 弱 性 が 発 見 されている [ 詳 細 ] 脆 弱 性 リスト 前 回 以 降 2002 年 1 月 から 2004 年 1 月 まで 報 告 された 脆 弱 性 として に bugtraq[69] に 登 録 されている SSL に 関 する 脆 弱 性 を 表 に 示 す 本 稿 ではそれらの 攻 撃 を 以 下 のように 分 類 した この 中 で Buffer Overflow など 実 装 におけるメモリ 関 連 の 不 具 合 が 10 件 報 告 され ている このような 不 具 合 により DoS を 発 生 させることや 任 意 のコードを 実 行 することが できる 可 能 性 がある 種 類 DoS Execute ASN.1 Side channel Other 内 容 Buffer Overflowなどにより DoSを 発 生 する 攻 撃 Buffer Overflow などにより 任 意 のコードを 実 行 する 攻 撃 節 にて 説 明 した 攻 撃 節 から 節 にて 説 明 した 攻 撃 その 他 の 攻 撃 Buffer Overflow の 問 題 点 Buffer Overflow が 存 在 し 任 意 のコードが 実 行 できるとき プロトコル 実 装 における 仮 定 が 崩 れ るため 安 全 性 は 保 証 されない そして 最 悪 の 場 合 サーバの 秘 密 鍵 が 漏 洩 する 可 能 性 がある 攻 撃 の 実 行 可 能 性 前 述 のように Buffer Overflow の 脆 弱 性 存 在 し 任 意 のコードが 実 行 できる 可 能 性 が 報 告 されたとしても 攻 撃 が 実 行 可 能 とは 限 らない しかしながら 上 記 リストの 脆 弱 性 のな かで 任 意 のコードを 実 行 する Exploite code などが 公 開 されている[70] [71] 実 際 にこのコ ードをコンパイルすることにより 特 定 のバージョンの SSL/TLSサーバに 対 して 任 意 のコー ドを 実 行 できることが 確 認 されている さらに このコードを 利 用 したワーム Slapper[72] も 確 認 されている [ 対 策 ] 脆 弱 性 が 発 見 された 場 合 脆 弱 性 に 対 処 するための 修 正 プログラムが 公 開 される した がって 以 下 の 3 点 の 対 策 をすべきである 107

109 脆 弱 性 に 関 する 情 報 を 継 続 的 に 収 集 すること 脆 弱 性 修 正 プログラムが 存 在 する 場 合 は 早 期 に 適 用 すること 最 新 バージョンのソフトウ ェアを 利 用 すること 脆 弱 性 を 利 用 した 攻 撃 が 行 われたかどうか 監 視 すること また SSL/TLS を 用 いて 認 証 するとき 認 証 相 手 に 脆 弱 性 が 存 在 するとき 最 悪 の 場 合 に は 秘 密 鍵 が 漏 洩 している 可 能 性 があるため 認 証 結 果 は 信 用 できない 108

110 表 bugtraqに 投 稿 された 脆 弱 性 一 覧 bid name url cve published category CAN Jan 2004 remote DoS 9376 Jabber Server SSL Handling Denial of Service Vulnerability 8970 OpenSSL ASN.1 Large Recursion Remote Denial Of Service Vulnerability 8746 OpenSSL SSLv2 Client_Master_Key Remote Denial Of Service Vulnerability CAN Nov 2003 ASN.1 CVE-MAP-NOMATCH 2-Oct 2003 remote DoS 8732 OpenSSL ASN.1 Parsing Vulnerabilities CVE-MAP-NOMATCH 30-Sep 2003 ASN.1 CAN Jul 2003 Other 8134 Apache Web Server SSLCipherSuite Weak CipherSuite Renegotiation Weakness 7148 OpenSSL Bad Version Oracle Side Channel Attack Vulnerability 7101 OpenSSL Timing Attack RSA Private Key Information Disclosure Vulnerability CAN Mar 2003 Side channel CAN Mar 2003 Side channel 6884 OpenSSL CBC Error Information Leakage Weakness CAN Feb 2003 Other 5875 Ximian Evolution SSL Man-In-The-Middle CAN Oct 2002 Other 5791 HP VirtualVault Apache mod_ssl Denial Of Service Vulnerability 5778 Microsoft Internet Explorer SSL Certificate Expiration Vulnerability 5690 ssldump PreMasterSecret Buffer Overflow Vulnerability 5693 ssldump SSLv2 Challenge Buffer Underflow Vulnerability 5361 OpenSSL Kerberos Enabled SSLv3 Master Key Exchange Buffer Overflow Vulnerability 5362 OpenSSL SSLv3 Session ID Buffer Overflow Vulnerability 5363 OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability 5364 OpenSSL ASCII Representation Of Integers Buffer Overflow Vulnerability 5366 OpenSSL ASN.1 Parsing Error Denial Of Service Vulnerability 4189 Apache mod_ssl/apache-ssl Buffer Overflow Vulnerability CVE-MAP-NOMATCH 25-Sep 2002 remote DoS CVE-MAP-NOMATCH 23-Sep 2002 Other CVE-MAP-NOMATCH 11-Sep 2002 Execute CVE-MAP-NOMATCH 11-Sep 2002 Execute CAN Jul 2002 Execute CAN Jul 2002 Execute CAN Jul 2002 Execute CAN Jul 2002 Execute CAN Jul 2002 ASN.1 CVE Feb 2002 Execute 3803 Multiple Vendor SSL Certificate Validation CVE-MAP-NOMATCH 3-Jan 2002 Other 109

111

112 ルート 証 明 書 配 送 の 問 題 [ 概 要 ] SSL/TLS に 付 随 する 問 題 として SSL/TLS に 用 いる 証 明 書 の 管 理 の 問 題 がある Microsoft 社 の Windows OSはソフトウェアの 不 具 合 を 修 正 するために Windows Update という 機 能 を 備 えている この 機 能 はコンピュータおよびソフトウェアの 状 態 を スキャンし ソフトウェアの 不 具 合 修 正 や 機 能 追 加 を 自 動 的 に 行 う 機 能 である Windows の 最 新 バージョンである Windows XP 以 降 では SSL/TLS にも 利 用 されるルート 証 明 書 を Windows Update を 利 用 して 配 信 している [ 詳 細 ] Windows update によるルート 証 明 書 配 送 Microsoft 社 の 技 術 解 説 サイト TechNet に 以 下 のニュースが 掲 載 された[75][76] 記 事 の 内 容 を 以 下 に 転 載 する つまり SSL/TLS に 利 用 される 公 開 鍵 証 明 書 のルート 証 明 書 が Windows Update によって 配 信 される しかも この 配 信 がセキュリティダイアログや 警 告 なしに 行 われる ルート 配 信 プロセスにおける 変 更 新 しいルート 証 明 書 の 従 来 の 登 録 方 法 は Microsoft Internet Explorer で はもう 使 用 できません マイクロソフトによって 承 認 された 新 しいルート はすべて Windows Update を 通 じて Windows XP クライアントで 利 用 することができます ユーザがセキュリティ 保 護 された Web サイト (つ まり HTTPS を 使 用 ) にアクセスしたり セキュリティ 保 護 された 電 子 メ ール (つまり S/MIME) を 読 んだり あるいは 新 しいルート 証 明 書 を 使 用 する Active X コントロールをダウンロードしたりする 場 合 Windows XP 証 明 書 チェーン 照 合 ソフトウェアが 適 切 な Windows Update ロケー ションをチェックして 必 要 なルート 証 明 書 をダウンロードします これ はユーザ 側 ではシームレスに 実 行 され セキュリティ ダイアログ ボック スや 警 告 などは 一 切 表 示 されません ダウンロードもバックグラウンドで 自 動 的 に 行 われます 新 しいルートは Windows Update ダウンロード ファイルを 通 じて Windows 2000 Windows NT Windows 95 Windows 98 および Windows Millennium Edition (ME) クライアントで 利 用 できるようにな ります この 件 に 関 して Bruce Schneier 氏 は Web サイトにて 以 下 のようにコメントしている [77] 111

113 New Microsoft Root Certificate Program "New root certificates are no longer available with Microsoft Internet Explorer. Any new roots accepted by Microsoft are available to Windows XP clients through Windows Update. When a user visits a secure Web site (that is, by using HTTPS), reads a secure (that is, S/MIME), or downloads an ActiveX control that uses a new root certificate, the Windows XP certificate chain verification software checks the appropriate Windows Update location and downloads the necessary root certificate. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes." This is the kind of thing that worries me. What exactly is this process. What happens when it fails. Why does everyone have to trust a root certificate, just because Microsoft does. And if the user doesn't see any security dialog boxes or warnings, the effects of any failure are likely to be catastrophic. For a while now I have talked about the differences between vulnerability and risk. Something can be very vulnerable, but not risky because there is so little at stake. As Microsoft continues to centralize security, authentication, permissions, etc., risk rises dramatically because the effect of a single vulnerability is magnified. 実 際 の Windows Update 実 際 に Windows Update において ルート 証 明 書 のアップデート という 項 目 が 表 示 さ れる セキュリティ 修 正 プログラムと 同 様 にルート 証 明 書 が 存 在 するため 一 般 のユーザ は 重 要 な 情 報 が 更 新 されていることを 認 識 できない Windows update の 詳 細 情 報 には 以 下 のように 記 載 されている ルート 証 明 書 のアップデート このアップデートによって コンピュータ 上 のルート 証 明 書 の 一 覧 が Microsoft Root Certificate Program の 一 部 として 弊 社 が 認 可 した 最 新 の 一 覧 に 更 新 されます コンピュータに 新 たにルート 証 明 書 を 追 加 することによ って セキュリティで 保 護 された Web のブラウズ 電 子 メール およびコ ード 配 信 アプリケーションをより 広 範 囲 に シームレスに 利 用 できます こ のアップデートには Verisign 社 Thawte 社 およびアイルランドの Post.Trust 社 からのルート 証 明 書 が 含 まれています 問 題 点 Microsoft 社 が Windows Update のセキュリティに 関 する 詳 細 情 報 を 正 確 に 公 開 してい ない 点 が 問 題 である Windows XP 証 明 書 チェーン 照 合 ソフトウェアが 適 切 な Windows Update ロケーションをチェックして 必 要 なルート 証 明 書 をダウンロードする 処 理 の 詳 112

114 細 が 公 開 されておらず 第 三 者 によって 検 証 できない また [78]の URL のファイルを 実 行 すると Windows Updateと 同 様 の 効 果 があり ルート 証 明 書 が 更 新 される つまり [78] に 示 すファイルの 実 行 が Windows Update によるルート 証 明 書 更 新 そのものである さら に Microsoft 社 は Windows Update の 一 部 を Akamai Technologies, Inc.[80]に 委 託 して いる 大 量 のユーザにコンテンツを 配 信 するとき Akamai Technologies, Inc.などのコン テンツ 配 信 サービスを 利 用 することは 有 効 であるが 安 全 性 を 考 慮 する 必 要 がある [ 対 策 ] Microsoft 社 を 信 頼 せず 自 らルート 証 明 書 を 更 新 する 場 合 は 以 下 の 操 作 をすればよい [79] (1) コントロール パネルの [プログラムの 追 加 と 削 除 ]を 開 きます (2) [Windows コンポーネントの 追 加 と 削 除 ] をクリックします (3) [ルート 証 明 書 の 更 新 ] チェック ボックスをオフにします (4) [ 次 へ] [ 完 了 ] の 順 にクリックします 113

115 表 示 の 不 具 合 が 実 質 上 のセキュリティホールになる 問 題 [ 概 要 ] ユーザが SSL/TLS による 通 信 を 行 うとき サーバが 正 当 であることや 通 信 路 が 暗 号 化 されていることを 確 認 する 方 法 は ユーザーインターフェースの 表 示 を 見 ることが 一 般 的 である SSL クライアントの 表 示 に 不 具 合 が 存 在 する 場 合 実 質 上 の 攻 撃 が 成 立 する 場 合 がある Microsoft 社 の Web ブラウザである Internet Explorer には 報 告 時 点 (2004 年 1 月 26 日 )において 不 具 合 が 存 在 した これにより 実 質 上 サーバになりすます 攻 撃 が 可 能 となる [ 詳 細 ] Basic 認 証 における 不 具 合 Microsoft 社 の Web ブラウザである Internet Explorer を 含 む 多 くのブラウザにはアド レスバー 表 示 の 不 具 合 が 確 認 されている 通 常 Basic 認 証 を 行 う 場 合 以 下 のような URL にアクセスすることにより domain にユーザ 名 user にて Basic 認 証 によるアクセス ができる しかしながら [81]によると 以 下 のような URL にアクセスすると domain1 にア クセスしながら アドレスバーには domain2 が 表 示 される 場 合 がある さらに [82]によると 以 下 のような URL にアクセスすると アドレスバー ステータス バーを 含 めて domain2 が 表 示 される <nul>は^a などの nul 文 字 さらに 以 下 のような javascript を 用 いることにより アドレスバーに domain2 を 表 示 させることが できる <a href="domain1" onclick="location.href=unescape(' return false;">domain1 </a> 問 題 点 通 常 ユーザが SSL/TLS により Web サイトを 認 証 するとき ステーテスバー アドレス バー プロパティなどのユーザーインターフェースを 見 ることによりサイトが 正 しいこと を 確 かめる したがって ステーテスバー アドレスバー プロパティを 偽 装 することが できるとき 実 質 上 のなりすまし 攻 撃 につながる 可 能 性 がある 114

116 攻 撃 の 実 行 可 能 性 上 記 exploit を Internetexplorer に 対 して 実 行 したところ アドレスバー ステー タスバー プロパティ には と 表 示 された [ 対 策 ] マイクロソフト 社 から 対 応 する 修 正 プログラムが 公 開 されている また サーバ 認 証 の 際 に アドレスバー ステータスバー プロパティ の 他 に 証 明 書 を 確 認 する 方 法 が 有 効 である ただし 証 明 書 表 示 インターフェースに 不 具 合 がないことが 前 提 である 115

117 2.5. 運 用 上 の 注 意 点 本 節 では SSL 機 能 を 持 つサーバ 及 びクライアントを 使 用 する 上 での 各 種 設 定 方 法 など 運 用 方 法 と それに 伴 うセキュリティについて 考 察 を 行 う サーバプログラムとしては Web サーバである Apache に SSL 機 能 を 追 加 する 代 表 的 なモジュールである mod_ssl を 対 象 とし 調 査 を 行 った ここでmod_ssl は OpenSSL を 実 装 形 式 にしたものである ま た クライアントプログラムとしてブラウザを 用 い 代 表 的 なブラウザである Internet Explorer Netscape Navigator を 調 査 対 象 とした バージョンは 現 在 最 も 使 用 されている Internet Explorer5.5 Netscape Navigator 4.7.x を 中 心 に 調 査 を 行 った 秘 密 鍵 や 証 明 書 などの 重 要 なファイルの 管 理 SSL を 使 用 時 には 秘 密 鍵 や 証 明 書 といったファイルを 管 理 する 場 所 を 指 定 する 例 えば mod_ssl ではサーバの 証 明 書 や 秘 密 鍵 を 管 理 するファイルを 指 定 する 命 令 (SSLCertificateFile filename, SSLCertificateKeyFile filename) Server Certificate Chain を 管 理 するファイルを 指 定 する 命 令 (SSLCertificateChainFile filename) クライ アントに 関 する CA の 証 明 書 を 管 理 するディレクトリやファイルを 指 定 する 命 令 (SSLCACertificatePath directory, SSLCACertificateFile filename) CRL を 管 理 する ディレクトリやファイルを 指 定 する 命 令 (SSLCARevocationPath directory, SSLCARevocationFile filename)が 該 当 する これらの 命 令 にデフォルト 値 はなく ディレクトリやファイル 名 を 指 定 する ファイルは PEM エンコーディングされているので 盗 聴 は 難 しいと 思 われる サーバの 秘 密 鍵 を 管 理 と その 他 証 明 書 関 連 ファイルの 管 理 とはセキュリティレベルが 異 なる サーバの 秘 密 鍵 は 暗 号 化 され 第 3 者 に 露 呈 しない 値 を 改 竄 されない ファイ ルを 容 易 にアクセスされ 消 去 できないといった 安 全 性 が 保 障 されている 必 要 があるともに 運 用 面 でも 秘 密 鍵 の 作 成 や 更 新 は セキュリティ 管 理 者 に 限 定 したオペレーションとな るようパスワードやハードウェアトークンによって 保 護 されているべきである 一 方 上 記 の 証 明 書 関 連 ファイルは 秘 密 鍵 ほど 厳 重 な 管 理 をする 必 要 が 必 ずしも 要 求 されない 証 明 書 や CRL は 一 般 的 に 公 開 された 情 報 であるため 暗 号 化 の 必 要 がない また 証 明 書 や CRL 自 身 には CA の 署 名 が 付 与 されているためそれ 自 身 改 竄 される 恐 れも 無 い しかしながら 不 正 に 消 去 され 本 来 失 効 している 証 明 書 が 有 効 であると 誤 った 判 断 がな されないよう 不 正 消 去 に 対 する 対 策 を 講 じる 必 要 がある 116

118 RandomSEED の 取 得 乱 数 生 成 時 に 疑 似 乱 数 生 成 器 を 用 いるとき その SEED となるソースを 与 える 必 要 がある 例 えば mod_ssl ではソースとなるファイルや そのソースを 生 成 するプログラムなどを 指 定 する 命 令 (SSLRandomSeed context source [bytes])が 該 当 する SEED の 生 成 法 にデフォルト 値 はなく 命 令 によって 指 定 する context にはいつその SEED を 求 めるかを 指 定 するもので OpenSSL 起 動 時 (startup)か SSL 接 続 直 前 (connect)を 指 定 する source で SEED の 生 成 方 法 を 指 示 する これには 以 下 の 指 示 がある builtin は 最 小 CPU サイクルを 用 いるもので 十 分 な 擬 似 乱 数 性 を 有 していると 考 えられ るため 実 用 上 問 題 とならない file:/path/to/source はデバイスなどのファイルを 用 いるもので 通 常 /dev/random や /dev/urandom などが 使 われる /dev/urandom はすぐに 任 意 サイズの 値 を 返 すが 乱 数 生 成 用 のエントロピー 保 持 量 が 足 りない 場 合 は 現 在 保 持 している 値 のハッシュ 値 で 返 すこ とになる /dev/random の 方 は 必 ず 乱 数 値 で 返 すが エントロピー 保 持 量 が 足 りないとき は 蓄 積 されるまでブロックされる 安 全 性 の 高 さを 求 めるならエントロピーの 高 い /dev/random が 望 ましいが サーバの 接 続 数 や 通 信 速 度 が 制 限 されてしまう 問 題 点 がある exec:/path/to/program は SEED 生 成 用 用 プログラムを 指 定 するもので AT&T の truerand などを 使 うときに 指 示 する サーバ 独 自 の 暗 号 方 式 を 用 いる 場 合 そのプログラ ムが 安 全 であれば 最 も 安 全 な 方 式 といえるが 一 般 的 なユーザが 独 自 にプログラムを 作 る べきではない 現 在 のところ builtin または file:/dev/(u)random による 乱 数 における 攻 撃 法 が 発 見 されていないのでこれらの 方 式 の 利 用 が 推 奨 される セッション 鍵 のライフタイム mod_ssl では 頻 繁 に 生 じる 同 一 トランザクションを 高 速 に 処 理 するため セッション 情 報 をメモリ 上 に 展 開 し 保 持 するセッションキャッシュ 機 構 が 実 装 されている ここで セッションキャッシュとは 一 人 のユーザの 時 間 的 に 連 続 する 接 続 や 複 数 の TCP コネ クションによる 接 続 を 一 つの SSL セッションとみなし セッション ID を 付 与 することに より 同 じセッション 鍵 (master secret)を 使 う 技 術 であり セキュリティの 観 点 らかは SSL における 実 効 上 のセッション 鍵 のライフタイムに 相 当 する ( 通 常 のブラウザは 4 つ の TCP コネクションにより 接 続 する )セッションキャッシュが 用 いられる 場 合 ハンドシ ェイクプロトコルは 省 略 される 以 下 にその 図 を 示 す 117

119 新 規 セッション 確 立 既 存 セッション 再 開 サーバ クライアント サーバ クライアント Client Hello Client Hello Server Hello Server Certificate* Server Key Exchange* Certificate Request* Server Hello Done Server Hello Change Cipher Spec Finished Change Cipher Spec Finished Client Certificate* Clinet Key Exchange アプリケーションデータ 交 換 Certificate Verify* Change Cipher Spec Finished Change Cipher Spec Finished アプリケーションデータ 交 換 図 セッションキャッシュが 用 いられる 場 合 の handshakeprotocol このセッションキャッシュは 安 全 性 を 考 慮 して 一 定 時 間 毎 に 更 新 される mod_ssl ではセ ッションをキャッシュしておく 有 効 期 限 を 決 める 命 令 があり(SSLSessionCacheTimeout sec.) 指 定 秒 で 新 たなセッションに 更 新 されることになる この 値 が 小 さい 方 が 頻 繁 に 鍵 交 換 されるので 安 全 になるが 小 さすぎるとサーバに 負 荷 がかかり 通 信 が 遅 くなる こ の 命 令 ではデフォルト 値 が 300 秒 になっている 共 通 鍵 鍵 暗 号 の 鍵 を 300 秒 で 解 読 もしく は 盗 みだすことは 極 めて 困 難 であるため 安 全 性 の 面 では 妥 当 な 値 が 設 定 されているとい える 一 般 的 な 場 合 セキュリティと 性 能 を 考 慮 してもう 少 し 大 きな 値 に 設 定 してもよい ただし 最 大 値 は 24 時 間 ( 秒 )である 参 考 のため 以 下 にサーバとして mod_ssl クライアントとして Netscape4.7 を 用 いた 場 合 の サーバ 側 のトレースを 示 す ここでは 説 明 のためセッション 鍵 のライフタイムは 20 秒 に 設 定 した 20 秒 ごとにセッション 鍵 (セッション ID)が 更 新 されていることが 分 かる 118

120 使 用 するプロトコルバージョン 現 在 多 くのサーバプログラム 及 びブラウザプログラムにおいて SSL Vetsion2.0, SSL Version 3.0, TLS Version1.0 のどれもがサポートされており どのプロトコルを 使 用 する かを 利 用 者 が 選 択 可 能 となっている サーバ 用 プログラムである mod_ssl においては SSLProtocol という 設 定 項 目 で 設 定 を 行 う デフォルト 値 は SSLProtocol all となってお り すべてのプロトコルをサポートする 状 態 となっている 従 って アクセスしてくるク ライアントがサポートしているプロトコルの 内 最 新 のものが 使 用 されることになる (TLS>SSL3.0>SSL2.0) 一 方 クライアント 側 においても 同 様 の 設 定 項 目 が 存 在 する Internet Explorer5.5 に おいては PCT SSL2.0 SSL3.0 TLS1.0 が 選 択 可 能 となっており デフォルトの 状 態 では SSL2.0 及 び SSL3.0 が 使 用 可 能 となっている また Netscape Navigator 4.7.x においては SSLv2.0 SSLv3.0 が 選 択 可 能 となってお り デフォルトの 状 態 では SSLv2.0 及 び SSLv3.0 が 使 用 可 能 となっている いくつかのセキュリティホールが 指 摘 されている SSL 2.0 をサーバ クライアントソフ ト 共 に デフォルトで 使 用 可 能 となっているが ソフトウェアを 実 際 に 運 用 する 際 には 使 用 不 可 に 設 定 するのが 望 ましい 特 に 現 在 インターネット 上 の SSL を 使 用 するほとん どのサイトは SSL3.0 に 対 応 していることから クライアント 側 のブラウザは SSL2.0 を 使 用 不 可 に 設 定 して 使 用 すべきであると 考 えられる 使 用 する 暗 号 アルゴリズム サーバ 側 においては 多 くの 実 装 において 使 用 する 暗 号 アルゴリズムについて 鍵 交 換 認 証 暗 号 化 ハッシュ 関 数 を 個 々に 使 用 可 能 使 用 不 可 能 を 設 定 可 能 である mod-ssl においては SSLCipherSuite によって 設 定 を 行 うが 鍵 交 換 は RSA DHwithRSA DHwithDSS Ephemeral DH 認 証 は NULL( 認 証 なし) RSA DSS DH 暗 号 化 は NULL DES 3DES RC4 RC2 IDEA ハッシュ 関 数 は MD5 SHA1 SHA からそれぞれ 選 択 し CipherSuite を 作 成 する また Aliases として ADH(Anonymous DH 鍵 交 換 はDHを 選 択 し 認 証 は NULL にする 設 定 と 同 様 )や LOW(128bit 未 満 の 鍵 長 を 持 つ 暗 号 を 使 用 ) MEDIUM(128bit の 鍵 長 を 持 つ 暗 号 を 使 用 ) HIGH( 鍵 長 168bit の 3DES を 使 用 )などを 使 用 した 設 定 も 可 能 である デフォルト 値 は ADH を 除 いた 認 証 鍵 交 換 方 式 と NULL を 除 くすべての 暗 号 方 式 すべてのハッシュ 関 数 が 使 用 可 能 と なっている 119

121 一 方 クライアント 側 であるブラウザであるが Internet Explorer5.5 においては Fortezza の 使 用 の 有 無 が 選 択 できるのみである (デフォルトは 使 用 可 能 ) また Netscape Navigator 4.7.x においては SSLv2.0 SSLv3.0 でそれぞれ 異 なる 設 定 が 可 能 であり SSLv2.0 においてはすべての 暗 号 方 式 が SSLv3.0 においては 暗 号 化 なし 以 外 のすべての 暗 号 方 式 が 使 用 可 能 となっている サーバの 利 用 用 途 にもよるが 認 証 なし 暗 号 化 なし などを 選 択 することは 推 奨 さ れない 暗 号 についても 可 能 であれば 128bit 以 上 の 鍵 長 を 持 つ 暗 号 を 使 用 することが 望 ましいと 考 えられる また traffic analysis attack を 防 ぐためには 少 なくともストリー ム 暗 号 (RC4)を 用 いないことが 望 ましい 証 明 書 検 証 mod_ssl の 証 明 書 検 証 に 関 する 設 定 は クライアント 認 証 を 行 うか 否 かを 指 定 する 命 令 (SSLVerifyClient level )と 中 間 証 明 機 関 (intermediate certificate issuer)の 最 大 数 を を 指 定 する 命 令 (SSLVerifyDepth number)により 行 われる SSLVerifyClient は 因 数 と して none:クライアント 証 明 書 を 要 求 しない optional:クライアントが 証 明 書 を 提 示 してもよい 提 示 された 場 合 にその 検 証 を 行 う require:クライアント 証 明 書 を 要 求 する optional_no_ca:クライアントは 証 明 書 を 提 示 してもよい 提 示 された 場 合 その 検 証 を 行 わない を 選 択 できる デフォルトでは none に 設 定 されており 必 要 に 応 じて require を 設 定 す ればよい optional および optional_no_ca は 試 験 を 行 うときなどに 用 いる SSLVerifyClient は 因 数 として level( 整 数 )を 選 択 できる この level は 中 間 証 明 機 関 を 許 可 する 最 大 数 である デフォルトでは 1 と 設 定 されている つまり 0(: 自 己 証 明 書 ) もしくは1(:クライアントの 公 開 鍵 の 証 明 書 そのもの)がサーバに 事 前 登 録 されている 必 要 がある 自 己 証 明 書 については サーバに 登 録 時 に 通 常 CA が 行 うようなクライアン トに 対 する 身 元 確 認 を 行 った 上 で サーバの 自 己 責 任 において そのクライアント 証 明 書 を 登 録 するという 運 用 の 前 提 が 必 要 である また 値 はルート CA として 登 録 する CA の 証 明 書 に 依 存 して 決 定 すればよい また mod_ssl は CRL を 自 動 的 に 更 新 する OCSP のような 機 能 がない CRL は で 説 明 し たディレクトリに 保 存 しなければならない よって 定 期 的 に CRL を 更 新 する 必 要 があ る ただし CRL 更 新 プログラムをユーザが 作 成 する 場 合 不 具 合 により CRL を 改 ざん 120

122 されないよう 管 理 する 必 要 がある Ineternet Explorer の 証 明 書 検 証 に 関 する 設 定 は 個 人 ほかの 人 中 間 証 明 機 関 信 頼 できるルート 証 明 機 関 を 設 定 ができ サーバ 証 明 書 はあらかじめ Microsft 社 によってベリ サインなどの 有 名 な CA のルート 証 明 書 が 複 数 インストールされている クライアント 認 証 を 受 けるために 必 要 なクライアント 証 明 書 は 個 人 のタブからインポートする 必 要 がある この 際 にセキュリティレベルを 設 定 する 必 要 がある ここで ルート 証 明 書 はあらかじめ 登 録 されているが 知 識 のあるユーザはどのルート 証 明 書 が 登 録 されているのか 確 認 して おくべきである ユーザのセキュリティポリシー(どの 証 明 書 を 信 用 するか)をブラウザ ベンダーが 必 ずしも 反 映 していないからである また CRL の 管 理 は 行 われているが OCSP のようなリアルタイムな 確 認 は 行 われていない ユーザは 頻 繁 に CRL をダウンロ ードしてインストールする 必 要 があり 非 常 に 面 倒 であり 実 際 に 活 用 されていないことが 問 題 である よって OCSP や CRL の 自 動 的 なインストールする 機 能 を 実 装 すべきであ る Netscape Navigator の 証 明 書 検 証 機 能 に 関 する 設 定 も Ineternet Explore rと 同 様 の 設 定 ができる ただし ルート 証 明 書 の 種 類 は 異 なる ここでも どのルート 証 明 書 が 登 録 さ れているか 確 認 するべきである 個 人 の 証 明 書 を 登 録 する 場 合 パスワードを 設 定 した 方 が 望 ましいが そのパスワードの 管 理 に 気 をつける 必 要 がある また CRL の 管 理 はここで も 行 われているが OCSP は 実 装 されていない よって Internet Explorer と 同 様 のこと がいえる また 調 査 対 象 外 ではあるが Netscape6.x には CRL や OCSP が 実 装 されてい るが 仕 様 しづらく さらに 改 善 する 必 要 がある ログ SSL でのログに 関 する 設 定 を 行 う 例 えば mod_ssl では ログファイルの 格 納 場 所 を 指 定 する 命 令 (SSLLog filename)や ログレベルを 指 定 する 命 令 (SSLLogLevel level) が 該 当 する これらの 命 令 では 格 納 場 所 のデフォルト 値 はなく レベルのデフォルト 値 は none( 規 定 無 し)となっている 単 にログの 出 力 に 関 する 設 定 であり ログファイルを 第 三 者 に 閲 覧 されたくない 場 合 は アクセスされない 場 所 に 管 理 するなどすればよく 特 にセキュリ ティの 脅 威 になることはない 警 告 通 知 クライアント 側 で 表 示 される 警 告 の 有 無 について 利 用 者 は 設 定 可 能 である Internet Explorer5.5 においては リダイレクト 保 護 付 き/ 保 護 なしサイト 間 移 動 無 効 な 証 明 書 121

123 についての 警 告 の 有 無 を 選 択 できる デフォルト 値 はすべて あり である また Netscape Navigator においては 暗 号 化 サイトに 入 るとき 出 るとき 暗 号 化 / 非 暗 号 化 の 混 ざったページを 表 示 するとき 非 暗 号 化 情 報 を 送 信 するとき について 警 告 通 知 を 行 うように 設 定 可 能 である デフォルトは すべて あり となっている 設 定 可 能 な 警 告 はいずれも 重 要 な 警 告 であり すべて 通 知 するように 設 定 すべきである 特 に 保 護 ( 暗 号 化 )されたサイトと 保 護 ( 暗 号 化 )されないサイト 間 を 移 動 する 際 に 警 告 が 出 ることは 利 用 者 が 保 護 されていないサイトを 保 護 されていると 誤 解 しないため にも 重 要 な 警 告 メッセージであるといえる その 他 設 定 SSL ではその 他 いろいろな 設 定 が 行 えるようになっている 例 えば mod_ssl ではオプシ ョンな 設 定 を 行 う 命 令 (SSLOptions [+-]option)があり 引 数 に 様 々なオプションを 指 定 できる これには CGI/SSI 環 境 変 数 に 関 係 する 設 定 を 行 うもの(StdEnvVars, CompatEnvVars, ExportCertData) クライアントの X509 証 明 書 を HTTP Basic Authorization のユーザネームに 変 更 するもの(FakeBasicAuth) 不 許 可 すべきアクセス は 強 制 的 にアクセス 不 許 可 するもの(StrictRequire) 再 ネゴシエーションの 最 適 化 に 関 するもの(OptRenegotiate)がある これらはデフォルトではどのオプションも 指 定 されておらず オプション 使 用 時 またはオ プション 解 除 時 に 指 定 することになる 122

124 パッチマネージメントについて パッチと 呼 ばれる 修 正 プログラムを 迅 速 かつ 正 確 に 現 行 ソフトウェアに 対 して 適 用 する ことは ソフトウェアの 運 用 においてもっとも 重 要 な 作 業 のひとつである このような パッチのマネージメントは 組 織 内 に 専 門 の 部 署 を 設 けるほうが 望 ましい 米 国 の NIST(National Institute of Standards and Technology)は セキュリティ 上 の 問 題 を 修 正 するパッチの 運 用 指 針 を 定 めた Procedures for Handling Security Patches という 文 書 を 発 行 している この 文 書 においては 組 織 内 の Patch and Vulnerability Group (PVG) を 設 け PVG が 主 体 となってパッチの 運 用 をする 方 針 を 打 ち 出 している ( 図 ) 図 パッチマネージメントの 流 れ 123

125 PVG は 以 下 のような 業 務 を 行 う 組 織 が 使 用 しているソフトウェア ハードウェアに 関 するデータベースを 管 理 する 脆 弱 性 やパッチの 情 報 を 収 集 し パッチの 存 在 を 確 認 する パッチの 適 用 順 序 に 優 先 順 位 をつける 組 織 固 有 のパッチ データベースを 作 成 する パッチのテストを 行 う システム 管 理 者 に 脆 弱 性 情 報 とパッチを 提 供 する スキャニングによって パッチの 適 用 状 態 を 検 証 する システム 管 理 者 を 教 育 する 文 書 においては 脅 威 の 深 刻 さの 度 合 いや 適 用 するシステムの 重 要 性 パフォーマンス や 機 能 の 低 下 の 有 無 費 用 等 の 観 点 から 総 合 的 に 判 断 して パッチの 適 用 の 有 無 作 業 の 優 先 順 位 を 決 める 必 要 があるとしている パッチや 脆 弱 性 情 報 の 入 手 元 としては ベンダ ーのサイト 及 びメーリングリスト 第 三 者 の Web サイト メーリングリスト 及 びニュース グループ CVE[48] CERT/CC[51] NIST ICAT Vulnerability Index[49] NIPC(National Infrastructure Protection Center)[50] FedCIRC (Federal Computer Incident Response Center)[52]が 挙 げられている 対 応 する 日 本 のサイトとしては 日 本 ネットワークセキュリティ 協 会 (JNSA)[55] 情 報 処 理 推 進 機 構 (IPA)セキュリティセンター[56]などがある また SSL の 関 する 情 報 の 収 集 においては OpenSSL のサイトや 各 種 OS の 提 供 サイトも 参 照 することが 望 まし い 124

126 参 考 文 献 [1] A. Freier, P. Karlton, and P. Kocher, The SSL Protocol Version 3.0, [2] T. Dierks, A. Freier, The TLS Protocol Version 1.0, [3] Josh Benaloh, Butler Lampson, Daniel Simon, Terence Spies, and Bennet Yee, The Private Communication Technology Protocol, [4] Kipp E.B. Hickman, SSL 2.0 PROTOCOL SPECIFICATION, [5] Simon Blake-Wilson, Magnus Nystrom, David Hopwood, Jan Mikkelsen, and Tim Wright, TLS Extensions, [6] Simon Blake-Wilson, and Magnus Nystrom, Wireless Extensions to TLS, [7] Stephen Farrell, TLS extensions for AttributeCertificate based authorization, [8] K. Jackson, S. Tuecke, and D. Engert, TLS Delegation Protocol, [9] A. Medvinsky, and M. Hur, Addition of Kerberos Cipher Suites to Transport Layer Security (TLS), [10] Matthew Hur, Joseph Salowey, Cisco Systems, and Ari Medvinsky, Kerberos Cipher Suites in Transport Layer Security (TLS), [11] W. Price, and M. Elkins, Extensions to TLS for OpenPGP keys, [12] D. Taylor, Using SRP for TLS Authentication, [13] [13]John Banes, and Richard Harrington, 56-bit Export Cipher Suites For TLS, [14] Joo-won Jung, and ChangHee Lee, TLS Extension for SEED and HAS-160, [15] H. Ohta, and H. Tsuji, Addition of MISTY1 to TLS, 125

127 [16] S. Moriai, Addition of the Camellia Encryption Algorithm to TLS, [17] Pete Chown, AES Ciphersuites for TLS, [18] Simon Blake-Wilson, Tim Dierks, and Chris Hawk, ECC Cipher Suites for TLS, [19] Ari Singer, NTRU Cipher Suites for TLS, [20] Joseph Hui, TLS Pathsec Protocol, [21] J. Manger A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS#1 v2.0 CRYPTO 01 LNCS 2139 pp , Aug 2001 [22] Bleichenbacher Discovery Q&A, [23] On OAEP, PSS, and S/MIME, [24] D. Bleichenbacher, Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1, Advances in Cryptology-CRYPTO '98, LNCS vol Springer-Verlag, [25] David Wagner and Bruce Schneier, Analysis of the SSL 3.0 protocol, The Second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp Revised April 15, [26] Steven M. Bellovin, Problem Areas for the IP Security Protocols, Proceedings of the Sixth USENIX Security Symposium, Usenix Association, 1996, pp [27] M. Bellare, R.Canetti, and H. Krawczyk, Keying Hash Functions for Message Authentication, Advances in Cryptology-CRYPT 96 Proceedings, Springer-Verlag, 1996, pp [28] Ralf S. Engelschall, mod_ssl, [29] Microsoft Corporation, Internet Explorer 5.5, [30] Netscape, Netscape Navigator 4.7.3, [31] The Apache Software Foundation, Apache, [32] Ben Laurie, and Adam Laurie, Apache-SSL, [33] SecurityFocus, BUGTRAQ, [34] V. Klima, O. Pokorny and T. Rosa, Attacking RSA-based Sessions in SSL/TLS, IACR Cryptology eprint Archive: Report 2003/052. [35] V. Klima and T. Rosa, Further Results and Considerations on Side Channel 126

128 Attacks on RSA, in Proc. of CHES 02, [36] J,Jonsson, B.Kaliski, On the Security of RSA Encryption in TLS, in Proc. of CRYPTO 02, pp , [37] D.Brumley, and D.Boneh, Romote Timing Attacks are Practical, in Proc. of the 12 Usenix UNIX Security Symposium, USENIX, th [38] P.Junod, On the Optimality of Linear, Differential, and Sequential Distinguishers, in Proc. of EUROCRYPT 03, pp.17-32, [39] P.Kocher, Timing Attacks on Implementations of Diffie -Hellman, RSA, DSS, and other Systems, in Proc. of CRYPTO 96, pp , [40] B.Moller, Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures, [41] R.Baldwin, R.Rivest, The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms, RFC 2040, [42] S.Vaudenay, Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS..., in Proc. of EUROCRYPT 02, LNCS, No.2332, pp , [43] B.Canvel, A.Hiltgen, S.Vaudenay, and M.Vuagnoux, Password Interception in a SSL/TLS Channel, CRYPTO 2003, LNCS, No.2729, pp , [44] J.Black, and H.Urtubia, Side-Channel Attacks on Symmetric Encryption Schemes: The Case for Authenticated Encryption, in Proc. of 11th USENIX Security Symposium 2002, pp , [45] K.G.Paterson, and A.Yau, Padding Oracle Attacks on the ISO CBC Mode Encryption Standard, In, Proc., CT-RSA04, [46] M.Bellare, A.Desai, E.Jokipii, and P.Rogaway, A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation, in Proc. of the 38 Symposium on Foundations of Computer Science, IEEE, th [47] D.Coppersmith, Small solutions to polynomial equations and low exponent RSA vulnerabilities, Journal of Cryptology, 10: , [48] Common Vulnerability and Exposure (CVE), [49] NIST ICAT Vulnerability Index, [50] National Infrastructure Protection Center, [51] CERT/CC, [52] Federal Computer Incident Response Center (FedCIRC), [53] JPCERT/CC, [55] 日 本 ネットワークセキュリティ 協 会 (JNSA), [56] 情 報 処 理 推 進 機 構 セキュリティセンター, 127

129 [57] PROTOS Test-Suite: c06-snmpv1, [58] ASN.1 encoding rules Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ITU-T Rec. X.690 (2002) ISO/IEC :2002 [59] OpenSSL Security Adversary, 30 July [60] NISCC Vulnerability Advisory /OpenSSL, 30 September [61] OpenSSL Security Adversary, 30 September [62] NISCC Vulnerability Advisory /OpenSSL2, 4 November [63] OpenSSL Security Adversary, 04 November [64] OpenSSL ASN.1 parsing bugs PoC / brute forcer, Jan [65] PROTOS Test-Suite: c07-sip, [66] Securityfocus Multiple Vendor S/MIME ASN.1 Parsing Denial of Service Vulnerabilities, [67] Microsoft Security Bulletin MS04-007, ASN.1 Vulnerability Could Allow Code Execution (828028), [68] [69] Bugtraq [70] openssl-too-open, [71] openssl sslv3 session_id overrun exploit, exp.txt [72] slapper worm html [73] Microsoft Windows Update, [74] Microsoft Windows Update, [75] Microsoft ルート 証 明 書 プログラム, [76] Microsoft Root Certificate Program, 128

130 [77] New Microsoft Root Certificate Program, [78] ool/rootsupd_882a0a0d36fe385b042edec58e1f0e7715bda1bb.exe [79] Microsoft TechNet 信 頼 されたルート 証 明 機 関 証 明 書 の 自 動 更 新 を 無 効 にするには, /standard/sag_cmprocsautorootoff.asp [80] Akamai Technologies, Inc. [81] Internet Explorer URL parsing vulnerability [82] IE ホゥル : NUL 文 字 攻 撃 で URL 表 示 捏 造 可 能, [83] Internet Explorer 用 の 累 積 的 なセキュリティ 修 正 プログラム (832894) (MS04-004) [84] A security update is available that modifies the default behavior of Internet Explorer for handling user information in HTTP and in HTTPS URLs, [85] J. Håstad and M. Näslund, The Security of Individual RSA Bits, in Proc. of FOCS 98, pp ,

131 KDDI R&D Laboratories Inc