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
松本直樹
March 11, 2023
Technology
0
140
TLS 1.3 で学ぶ暗号技術
2023/3/11 情報科学若手の会春の陣2023
松本直樹
March 11, 2023
Tweet
Share
More Decks by 松本直樹
See All by 松本直樹
Rootless コンテナはいいぞ
mt2naoki
2
120
コンテナ技術における最新の研究動向
mt2naoki
15
10k
Zig で TLS1.3 を実装している話
mt2naoki
0
84
Efficient Container Image Updating in Low-bandwidth Networks with Delta Encoding
mt2naoki
0
700
Accelerating TCP/IP Communications in Rootless Containers by Socket Switching
mt2naoki
0
1.1k
Capability Based Network Access Control for Smart Home Devices
mt2naoki
0
86
Capabilityモデルに基づくスマートホームデバイスのネットワークアクセス制御
mt2naoki
0
97
実行環境の隔離技術に関する調査
mt2naoki
0
50
Other Decks in Technology
See All in Technology
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
310
20240418_Google ColabにLLMが搭載されたようなのでPython x データ分析の勉強方法を考えてみる
doradora09
0
140
LLM開発・活用の舞台裏@2024.04.25
yushin_n
1
340
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
300
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
290
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
Delivering Millions of Messages within seconds @ Duolingo
pelelgrino
0
350
現代CSSフレームワークの内部実装とその仕組み
poteboy
7
3.6k
Python と Snowflake はズッ友だょ!~ Snowflake の Python 関連機能をふりかえる ~
__allllllllez__
1
120
アクセス制御にまつわる改善 / Improving access control
itkq
0
550
On Your Data を超えていく!
hirotomotaguchi
2
690
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
130
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
We Have a Design System, Now What?
morganepeng
43
6.8k
Scaling GitHub
holman
457
140k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
241
1.2M
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
GraphQLとの向き合い方2022年版
quramy
32
12k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
244
20k
The MySQL Ecosystem @ GitHub 2015
samlambert
243
12k
Git: the NoSQL Database
bkeepers
PRO
422
63k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
Fireside Chat
paigeccino
21
2.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