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