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
470
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
770
Mewz on libkrun
mt2naoki
1
670
詳解 bypass4netns: Rootless Containers Network の仕組みと高速化
mt2naoki
2
740
QUIC の仕組み(Handshake)
mt2naoki
1
400
bypass4netns: Accelerating TCP/IP Communications in Rootless Containers
mt2naoki
0
220
Rootless コンテナはいいぞ
mt2naoki
2
750
コンテナ技術における最新の研究動向
mt2naoki
15
11k
Zig で TLS1.3 を実装している話
mt2naoki
0
210
Efficient Container Image Updating in Low-bandwidth Networks with Delta Encoding
mt2naoki
0
1.5k
Other Decks in Technology
See All in Technology
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
280
Model Mondays S2E03: SLMs & Reasoning
nitya
0
220
2025-06-26 GitHub CopilotとAI駆動開発:実践と導入のリアル
fl_kawachi
1
190
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
120
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
2
630
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
150
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
250
WordPressから ヘッドレスCMSへ! Storyblokへの移行プロセス
nyata
0
250
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
150
Witchcraft for Memory
pocke
1
630
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
4
3.3k
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
800
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Navigating Team Friction
lara
187
15k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Site-Speed That Sticks
csswizardry
10
670
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Embracing the Ebb and Flow
colly
86
4.7k
Producing Creativity
orderedlist
PRO
346
40k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
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