TLS 1.3 で学ぶ暗号技術 2023/3/11 情報科学若手の会春の陣2023 松本直樹(京都大学 情報学研究科) 1

本発表のスコープ 「研究発表」と言うより、「知見共有」な発表です • ICT に関連する研究やプログラムを開発する人 • 通信の安全性が担保される仕組みを知りたい人 • 暗号技術に興味はあるが、あまり詳しくない人 「専門家向けではない、ゆるめ」の発表を目指しています 2

前回までのあらすじ 第 55 回情報科学若手の会(2022年9月) の LT より 3

ちなみに Zig の std に TLS 1.3 実装が生えました 4

TLS (Transport Layer Security) TLS (Transport Layer Security) • 通信における認証及び暗号化を提供するプロトコル → なりすましや、第三者が盗み見できない • HTTPS や QUIC において利用されている • TLS 1.3 (RFC 8446) が最新 • TLS 1.2 はまだ使える • TLS 1.1 以前は脆弱性が存在するため利用してはならない 5

TLS 1.3 における通信の大まかな流れ お互いに鍵を交換→認証→ハンドシェイク完了→データ交換 クライアント サーバー 通信しましょう パラメータこんな感じで 承知しました パラメータと 正しいサーバーであること の証明を共に送ります 正しいサーバーだね パラメタから鍵の生成した OKです！ じゃ、通信開始で！ 暗号化したデータです (データを復号し) なるほど (データを復号し) へー 暗号化したデータです 6

TLS 1.3 の詳細な特徴 • ハンドシェイクの整理・機能追加 • 通常ハンドシェイクにおけるメッセージ往復回数の削減 TLS 1.2 まで → 2往復、 TLS 1.3 → 1.5 往復 • セッション再開ハンドシェイクの整理 • 0-RTT ハンドシェイクの追加 • 利用できる暗号スキーマの整理 • 危殆化した暗号スキーマの廃止(RC4, MD5等) • 楕円曲線暗号や認証付き暗号(AES-GCM 等)の利用が標準となる • 前方秘匿性(PFS) を担保する鍵交換のみサポート ※PFS: ある時点で鍵交換における秘密鍵の情報の漏洩が生じても、それ以前の暗号化されたデータは復号できない こと • 安全性自体が形式的に検証された有名なプロトコルとしては初めて 7

つまり？ TLS 1.3 の直接的な嬉しさ • ハンドシェイクに必要なメッセージ往復回数の削減 → TLS のハンドシェイクに要する時間が短くなる = UX の改善 • 利用されるアルゴリズムの整理 → 危殆化したアルゴリズムは含まれないため、より安全に • PFS のサポート → 秘密鍵漏洩時の被害を最小限にできるため、より安全に 8

利用される暗号技術 • 鍵交換アルゴリズム • TLSセッションで利用される鍵の交換に利用するアルゴリズム • TLS 1.3 ではDiffie-Hellmanを利用する(=PFSを実現) • 署名アルゴリズム(デジタル署名) • メッセージの真正性を検証するためのアルゴリズム • TLS 1.3 では楕円曲線やRSA暗号による署名を用いる • 暗号化アルゴリズム • アプリケーションのデータを暗号化するアルゴリズム • TLS1.3 では改ざんを検出できる認証付き暗号(AEAD)を利用 9

前方秘匿性(Perfect Forward Secrecy) 前方秘匿性:暗号化鍵の共有に使われている秘密鍵が漏えいしたとしても、 過去に暗号化された通信データは解読されないことを指す → 漏洩前までのデータは将来にわたって機密性が守られる セッション #1 セッション #2 セッション #N セッション #N+1 ・・・ セッション #N+2 漏洩！ 漏洩した情報ではデータを復号できない 漏洩した通信は影響を受ける 10

鍵交換アルゴリズム 暗号化に利用する共通鍵を交換するアルゴリズム → 第三者にはバレないように2者間で共通鍵を共有する TLS 1.3 では Diffie-Hellman 鍵共有アルゴリズムを用いる クライアント サーバー 暗号化に共通鍵が必要 暗号化されたデータ 暗号化されたデータ ？ 何かしらの方法で鍵を 共有する必要がある 11

Diffie-Hellman(DH) による鍵の交換 Diffie-Hellman: 2者間で鍵自体を共有することなく鍵を共有する手法 • 𝑔𝑎 𝑚𝑜𝑑 𝑝から 𝑎 を求めることは困難である(離散対数問題) • 中間者攻撃には脆弱であり、認証を行う仕組みが必要 12 Alice Bob 公開パラメータ: g, p(素数) を共有 秘密鍵: a 秘密鍵: b 𝑔𝑎 𝑚𝑜𝑑 𝑝 𝑔𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝が共有される

DH だと何が嬉しい？ • 別の秘密鍵を利用することなく鍵を共有できる • 盗聴する第三者は共有された鍵を得ることが困難である → PFS を担保できる • 中間者攻撃に対しては脆弱 → 正しい相手であるか検証する必要がある Alice Bob 秘密鍵: a 秘密鍵: b 𝑔𝑎 𝑚𝑜𝑑 𝑝 𝑔𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝が共有される Mallory 𝑔𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝が共有される e で書き換え 13

署名アルゴリズム(デジタル署名) 送信されたメッセージが確かに本人によるものであることを保証する → なりすましや第三者による改ざんを検知できる DH と組み合わせて、共有された鍵が本人によるものであることを確認する Alice Bob メッセージ + 署名 自分の秘密鍵で メッセージを署名 Bob の公開鍵で検証 検証 OK ! 改ざんされたメッセージ + 署名 Mallory Bob の公開鍵で検証 検証 失敗 → Bobじゃないな？ 14

RSA暗号による署名(RFC 8017) 公開鍵暗号である RSA暗号を用いたデジタル署名が有名 (注: 署名 ≠ 暗号化) • 署名手法にはいくつかあり、RSASSA-PKCS1-v1_5 を取り上げる メッセージ 暗号学的 ハッシュ関数 エンコード 𝑥: 入力, 𝑦: 出力 𝑦 = 𝑥𝑑 𝑚𝑜𝑑 𝑛 𝑑: 秘密鍵, 𝑒: 公開鍵, 𝑛: 法 (𝑒 と 𝑛 は公開) とする 署名 署名 EMSA-PKCS1-V1_5-ENCODE RSASP1 検証 𝑥: 入力, 𝑦: 出力 𝑦 = 𝑥𝑒 𝑚𝑜𝑑 𝑛 RSAVP1 メッセージ 暗号学的 ハッシュ関数 エンコード EMSA-PKCS1-V1_5-ENCODE 署名 一致すれば 検証成功 15

公開鍵基盤(PKI) 署名の検証には相手の公開鍵(と n)が必要 → 本人の正しい公開鍵を手に入れるにはどうすればよいのか？ 公開鍵基盤(Public Key Infrastructure): 正しい公開鍵であることを担保する基盤 • 署名の検証に必要な情報一式を「証明書」として配布 • 「認証局(CA)」が証明書に署名する • CA の証明書はさらに上位のCAにより署名される(最上位のCAはルートCAと呼ばれる) サーバー証明書 認証局 発行 自分の秘密鍵で 証明書を署名 16

公開鍵基盤(PKI) 認証局の正しさはどうやって検証するのか？ → さらに上位の認証局が認証局の証明書を署名する 最上位の認証局(ルートCA)の証明書を 各クライアントに配布する 署名して発行 署名して発行 自分で署名(自己署名) 各クライアントに配布 中間CA ルートCA 証明書 17

暗号化アルゴリズム データを暗号化し、機密性を担保するアルゴリズム • AES 等のいわゆる共通鍵暗号 TLS 1.3 では復号結果の正しさを保証する認証付き暗号を用いる クライアント サーバー この部分 暗号化されたデータ 暗号化されたデータ DHによる鍵交換 デジタル署名を用いた認証 18

認証付き暗号(AEAD) Authenticated Encryption with Associated Data(AEAD) • データの機密性と完全性(正しさ)を担保する • 普通の共通鍵暗号では、復号結果が正しいか判断できない • 復号時に認証を行い、失敗すると復号失敗とする cipher, tag = AEAD_Enc(plain, ad, key, nonce) tag: 認証用のタグ, ad: 暗号化はされないが認証はされるデータ plain = AEAD_Dec(cipher, tag, ad, key, nonce) • TLS 1.3 では AES-GCM と Chacha20-Poly1305 が主に利用される 19

まとめ TLS 1.3 には以下の暗号技術が用いられている • 鍵交換アルゴリズム: 鍵の安全な共有 • 署名アルゴリズム: データの真正性の担保 • 暗号化アルゴリズム: データの機密性の担保 複数の暗号技術を組み合わせることで安全性を担保 それぞれの「何を保証できるのか/できないのか」の理解が重要 20