2023/3/11 情報科学若手の会春の陣2023
TLS 1.3 で学ぶ暗号技術2023/3/11 情報科学若手の会春の陣2023松本直樹(京都大学 情報学研究科)1
View Slide
本発表のスコープ「研究発表」と言うより、「知見共有」な発表です• 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者間で鍵自体を共有することなく鍵を共有する手法• 𝑔𝑎 𝑚𝑜𝑑 𝑝から 𝑎 を求めることは困難である(離散対数問題)• 中間者攻撃には脆弱であり、認証を行う仕組みが必要12Alice Bob公開パラメータ: g, p(素数) を共有秘密鍵: a 秘密鍵: b𝑔𝑎 𝑚𝑜𝑑 𝑝𝑔𝑏 𝑚𝑜𝑑 𝑝𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝 𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝𝑔𝑎𝑏 𝑚𝑜𝑑 𝑝が共有される
DH だと何が嬉しい？• 別の秘密鍵を利用することなく鍵を共有できる• 盗聴する第三者は共有された鍵を得ることが困難である→ PFS を担保できる• 中間者攻撃に対しては脆弱 → 正しい相手であるか検証する必要があるAlice Bob秘密鍵: a 秘密鍵: b𝑔𝑎 𝑚𝑜𝑑 𝑝𝑔𝑒 𝑚𝑜𝑑 𝑝𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝 𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝𝑔𝑎𝑒 𝑚𝑜𝑑 𝑝が共有されるMallory𝑔𝑏 𝑚𝑜𝑑 𝑝𝑔𝑒 𝑚𝑜𝑑 𝑝𝑔𝑏𝑒 𝑚𝑜𝑑 𝑝が共有されるe で書き換え13
署名アルゴリズム(デジタル署名)送信されたメッセージが確かに本人によるものであることを保証する→ なりすましや第三者による改ざんを検知できるDH と組み合わせて、共有された鍵が本人によるものであることを確認するAlice Bobメッセージ + 署名自分の秘密鍵でメッセージを署名Bob の公開鍵で検証検証 OK ! 改ざんされたメッセージ + 署名MalloryBob の公開鍵で検証検証 失敗→ 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
mt2naoki
megabitsenmzq
kentosuzuki
konboi
kubukoz
tatematsu_san
line_developers
eliasnogueira
tomohisa
orgachem
6onoda
asazutaiga
smashingmag
panda_program
jasonvnalue
dotmariusz
dougneiner
jonrohan
jacobian
holman
brettharned
marcelosomers
brad_frost
mthomps