Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
TLS 1.3 で学ぶ暗号技術
Search
Naoki MATSUMOTO
March 11, 2023
Technology
0
480
TLS 1.3 で学ぶ暗号技術
2023/3/11 情報科学若手の会春の陣2023
Naoki MATSUMOTO
March 11, 2023
Tweet
Share
More Decks by Naoki MATSUMOTO
See All by Naoki MATSUMOTO
Rootless な環境における eBPF の活用
mt2naoki
3
810
Mewz on libkrun
mt2naoki
1
740
詳解 bypass4netns: Rootless Containers Network の仕組みと高速化
mt2naoki
2
810
QUIC の仕組み(Handshake)
mt2naoki
1
450
bypass4netns: Accelerating TCP/IP Communications in Rootless Containers
mt2naoki
0
230
Rootless コンテナはいいぞ
mt2naoki
2
790
コンテナ技術における最新の研究動向
mt2naoki
15
11k
Zig で TLS1.3 を実装している話
mt2naoki
0
210
Efficient Container Image Updating in Low-bandwidth Networks with Delta Encoding
mt2naoki
0
1.6k
Other Decks in Technology
See All in Technology
データ基盤の管理者からGoogle Cloud全体の管理者になっていた話
zozotech
PRO
0
340
マルチモーダル基盤モデルに基づく動画と音の解析技術
lycorptech_jp
PRO
4
510
リリース2ヶ月で収益化した話
kent_code3
1
190
Claude CodeでKiroの仕様駆動開発を実現させるには...
gotalab555
3
890
LIFF CLIとngrokを使ったLIFF/LINEミニアプリのお手軽実機確認
diggymo
0
230
2025新卒研修・HTML/CSS #弁護士ドットコム
bengo4com
3
13k
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
140
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2k
AIエージェントを現場で使う / 2025.08.07 著者陣に聞く!現場で活用するためのAIエージェント実践入門(Findyランチセッション)
smiyawaki0820
6
630
SRE新規立ち上げ! Hubbleインフラのこれまでと展望
katsuya0515
0
160
データエンジニアがクラシルでやりたいことの現在地
gappy50
3
850
Foundation Model × VisionKit で実現するローカル OCR
sansantech
PRO
0
290
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Faster Mobile Websites
deanohume
308
31k
We Have a Design System, Now What?
morganepeng
53
7.7k
Statistics for Hackers
jakevdp
799
220k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Typedesign – Prime Four
hannesfritz
42
2.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
870
Building an army of robots
kneath
306
45k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Transcript
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