TLS1.3をざっと理解する サイボウズ・ラボ 光成滋生 2025/04/25 サイボウズ新人研修 1 / 24 

自己紹介 サイボウズ・ラボで暗号と高速化のR&D ID : @herumi 2021 『暗号と認証のしくみと理論...』執筆 2024 『Binary Hacks Rebooted』寄稿 / 『笑わない数学』暗号理論監修 OSS活動 2024 (Xbyakで) Google Open Source Peer Bonus受賞 2024 (mcl/blsで) Ethereum Foundation PSE (Privacy + Scaling Explorations) Grant獲得x2 2024 Microsoft MVP C++, Developer Security受賞 2 / 24 

スライドの目的 暗号技術の基礎を学ぶ TLS1.3で使われる暗号技術の用語と目的を理解する 共通鍵暗号 メッセージ認証コード AEAD DH鍵共有 署名 PKI 3 / 24 

盗聴不可 改竄不可 1000 円の⽀払い 1000 円の⽀払い 10000 円の⽀払い 本物 偽物 身の回りの暗号 ブラウザでの暗号通信 パソコン・スマートフォンからブラウザを使った Webサイトへのアクセス 情報収集・SNS・買い物・ビデオ会議など HTTPS（HTTP over TLS）を使った通信 URLが「https://」で始まるもの TLS (Transport Layer Security) 様々な暗号技術の組み合わせ 通信内容が盗聴されない 通信内容が改竄されない 通信相手が本物であることを確認できる 4 / 24 

クライアント サーバ 署名の検証 鍵共有開始 鍵共有開始 暗号化開始 / 公開鍵証明書‧署名送信 暗号化開始 / 公開鍵証明書‧署名送信 本来の暗号化通信 本来の暗号化通信 クライアント サーバ TLS1.3の大まかな流れ 鍵共有 クライアントとサーバが秘密の鍵を共有する 署名 サーバが本当に正しいサーバであることを示す AEAD 共有した秘密鍵を用いて改竄不可能な暗号通信を行う 解説の流れ AEAD → 鍵共有 → 署名 5 / 24 

暗号化の用語 暗号化と復号 暗号化 : 読めるデータ（平文） を暗号化して 読めないデータ（暗号文） に変換する から の情報は（サイズ以外）得られない 復号 : 暗号文 を元のデータ に戻す 暗号鍵と復号鍵 暗号鍵 : 暗号化に使う補助データ 復号鍵 : 復号につかう補助データ 誰にも見せてはいけない（秘密鍵） 共通鍵暗号 「暗号鍵＝復号鍵」である暗号化方式 6 / 24 

平⽂ 01100 秘密鍵 11001 暗号⽂10101 1 のところだけ ビット反転 暗号化 復号 秘密鍵 11001 暗号⽂10101 平⽂ 01100 Vernam暗号 排他的論理和 を利用した暗号 ビットの平文 に対して ビットの乱数 を準備して（ が秘密鍵） 暗号文を とする 復号は 特徴 情報理論的に安全（絶対に破れない）だが 暗号文と同じサイズの秘密鍵が必要 平文が1GiBなら1GiBの秘密鍵 乱数は1回しか使ってはいけない 2回使うと情報が漏れる（何故?） 秘密鍵を安全に送れるならその方法で平文を送れば? 7 / 24 

疑似乱数とストリーム暗号 疑似乱数生成器PRNG (Pseudo Random Number Generator) 初期値 (seed) をに入れると好きなだけ長い乱数が確定的に得られる装置・アルゴリズム s : seed PRNG r : 乱数 010010011010100... 本当の乱数ではないが本当の乱数であるかのように見える いろいろな乱数試験をパスする必要あり PRNGを使ったストリーム暗号 PRNGを使って乱数 を生成し、Vernam暗号に適用する 秘密鍵は乱数生成器の初期値 に利用する（128ビットとか256ビットとか） Vernam暗号の情報的安全性は無いが扱いやすい 乱数生成器の性能に安全性が依存（計算量的安全性） 8 / 24 

改竄攻撃 ストリーム暗号はビット反転に弱い 暗号文 の特定のビットだけ反転できる 攻撃者がデータのある場所が yes/no を表す1ビットだと知っていたら 復号できなくても平文を操作できる m : 平⽂ 001101 r : 乱数 010010 ⊕ c : 暗号⽂ 011111 通信 c' : 暗号⽂ 011 0 11 攻撃者 3 ビット⽬を反転 r : 乱数 010010 ⊕ m' : 平⽂ 001 0 01 改竄を検知する必要がある ハッシュ関数を使う 任意の大きさのデータを固定長の値（ハッシュ値）に変換する関数 9 / 24 

12 4 31 8 11 12 17 9 22 27 24 14 23 41 ハッシュ関数 に望まれる性質 1. 元の値が分からない が与えられたとき を求めるのは難しい より強く が与えられたときに となる （第二原象）を求めるのが困難 2. 同じハッシュ値になるペアを見つけるのが難しい となる （衝突）を求めるのが困難 イメージ 籠の中にいろいろな数字が書かれたボールが沢山 1. 1個ボールを取り出し、それに書かれた数字と同じボールを探す 2. なんでもいいから同じ数字が書かれた2個のボールを探す 前者より後者がずっと簡単だがどちらも困難なことを要求 10 / 24 

メッセージ認証コード データの改竄を検証できる仕組み MAC (Message Authentication Code) 予めアリスとボブの間で秘密鍵 を共有しておく 手順 アリスはデータ と秘密鍵 から MAC値（タグ） を計算する アリスはデータ とMAC値 をボブに送る ボブは受け取ったデータ とMAC値 を使って 改竄されていないかを検証する -- 暗号化ではないので盗聴者は と を見られる は秘密鍵を知るアリスしか作れない 11 / 24 

AES ブロック暗号の一種 共通鍵の一種でブロック単位（e.g. 128ビット）で暗号化する 暗号利用モード ブロックを秘密鍵で暗号化するといつも同じ暗号文のブロック ナンス（一度しか使わない数）などを組み合わせて毎回異なる暗号文にする必要がある CTR (Counter Mode) ナンスとカウンタを暗号化して疑似乱数を生成し、ストリーム暗号として利用 12 / 24 

認証つき暗号 AEAD (Authenticated Encryption with Associated Data) 秘密鍵による暗号化と認証を同時に行う仕組み 暗号化だけでは解読できなくても改竄される可能性がある 暗号化と暗号文が改竄されていないこと・本人が送ってきたことの検証を同時に行う AES-GCM, ChaCha20-Poly1305 などがある 歴史 共通鍵暗号（ブロック暗号・ストリーム暗号）とMACは別々に安全性の研究 組み合わせて利用 → 最初から合わせて設計 ブロック暗号の応用であるCBCモードは広く使われていたが2011年のBEAST攻撃により、 現在はストリーム暗号が主流（TLSではストリーム暗号のみ） 13 / 24 

公開鍵暗号（化 ） PKE 署名 鍵共有 準同型暗号 MPC ZKP ... 暗号技術全般 公開鍵暗号PKC 共通鍵暗号 ハッシュ関数 MAC ... 盗聴可能な経路で秘密の情報を共有 鍵共有の必要性 ストリーム暗号もMACも事前に秘密鍵の共有が必要 盗聴可能な経路でどうやって? 公開鍵暗号 PKC (Public Key Cryptography) 秘密情報と公開情報の組み合わせを利用した暗号技術全般 鍵共有はPKCの一種 / 暗号化ではない 公開鍵と秘密鍵を組み合わせた公開鍵暗号化方式 PKE(Public Key Encryption) と区別する TLS1.3では基本的にPKEは使われない 14 / 24 

DH (Diffie-Hellman) 鍵共有 楕円曲線を用いたDH鍵共有 現在主流の方式 楕円曲線とは? 「楕円」でも「曲線」でもない「楕円曲線」という一つの用語 どちらかというと「浮輪の表面」 複素数的な曲線なので2次元 楕円曲線上の点同士は足し算・引き算ができる など 15 / 24 

ボブ アリス ボブ アリス 秘密鍵 a を⽣成し A = aP とする 秘密鍵 b を⽣成し B = bP とする 共有鍵 K = aB を計算 共有鍵 K = bA を計算 A を送信 B を送信 楕円DH鍵共有 セットアップ 楕円曲線 と, 倍すると0になる点 を選んでおく 共有 アリスは乱数 を選び を送信 ボブは乱数 を選び を送信 アリスは を ボブは を計算して同じ値を共有 秘密情報と公開情報 通信経路を流れるのは , , , はアリス、ボブのそれぞれが秘密に保持 16 / 24 

それで安全なのか? 攻撃者（盗聴者）が持つ情報 楕円曲線と点 , , 攻撃者が欲しい情報 現状 現在のスパコンが何台あっても , , などを求められないと信じられている 高性能な量子計算機が登場すると破られることが知られている 耐量子計算機暗号PQC（Post-Quantum Cryptography) 量子計算機に対しても安全な現在のコンピュータで実行できる暗号技術 2024年 ML (Module Lattice)-KEMというPQCのPKE, 鍵共有方式が標準化された 17 / 24 

鍵共有+AEADでOKか? 盗聴するだけの経路なら安全 攻撃者が積極的にデータを改竄するなら安全ではない 中間者攻撃 AITM (Atattack In The Middle) 攻撃者が中間に入って公開情報を改竄する DH鍵共有に対するAITM TLSではその対策にPKCの一種である署名（MACの上位互換）を使う 18 / 24 

鍵⽣成する 署名する 検証する データm 署名鍵s 検証鍵S 署名σ OK or NG 署名者 検証者 署名 署名の流れ 鍵生成 署名者が署名鍵 と検証鍵 を生成 は誰にも見せてはいけない秘密鍵. は公開鍵 署名 データ から署名鍵 を用いて署名 を作成 検証 検証者は の組の正当性を確認 偽造防止 に対して正当な は署名者しか作れない 正当な署名 は署名者が を承認したことを示す ビットコインは楕円曲線を用いた署名を利用 19 / 24 

署名の方式の種類 RSAの落とし戸つき一方向性関数 を利用したもの FDH (Full Domain Hash)-RSA署名（使われていない） RSA PKCS1-v1_5（最も普及している）, RSASSA-PSS（より安全） 楕円曲線を利用したもの ECDSA, EdDSA BLS署名, BBS+署名（EthereumやVerifiable Credentialsなどで） 楕円曲線の同種写像ベース（PQCの候補として現在活発に研究されている） 注意 FHD-RSA方式の説明がいわゆる「メッセージのハッシュ値を秘密鍵で暗号化」 他の方式はこの説明には合致しないので一般の署名の説明として使うべきではない 情報技術者試験でこれを答えさせる問題が出ていたが去年は不備扱い（今後は出ない?） 20 / 24 

サーバ証明書 cybozu.com サーバの検証鍵S CA の 署名鍵s' で 署名したσ' サーバ証明書 サーバの検証鍵とFQDN（ドメイン名）の紐付け 署名の検証鍵 だけではその正しさを確認できない とサーバ(FQDN)の関連づけが必要 信頼のおける第三者にそれを保証してもらう 信頼のおける第三者 = 認証局CA (Certificate Authority) サーバ証明書 1. 認証局CAが署名鍵 と検証鍵 を準備する 2. サーバが署名鍵 と検証鍵 を準備する 3. CAにサーバ証明書の発行を依頼する i. CAが申請者とFQDNの正しさを確認する ii. CAが で(FQDN, , 有効期限, etc.)に署名をする (FQDN, , 有効期限, ..., σ')がサーバ証明書 21 / 24 

サーバの 署名鍵で署名したσ ClientHello, etc. サーバ証明書 cybozu.com サーバの検証鍵S CA の 署名鍵で 署名したσ' TLS1.3での使われ方 プロトコルの流れ クライアントはサーバにDH鍵共有のデータを送信 サーバはDH鍵共有されたデータを元にAEADの準備 それまでの通信データと証明書に署名鍵 で署名 → σ これらをすべて暗号化して送信 クライアント CAの検証鍵 でサーバ証明書を検証 サーバ証明書に含まれるサーバの検証鍵 で 通信全体を確認 → 攻撃されていないことを確認 22 / 24 

公開鍵基盤 PKI (Public Key Infrastructure) 公開鍵の管理 クライアントは認証局CAの検証鍵 をどうやって持っておく? その認証局の証明書の検証は、更に別の他の認証局の検証鍵で検証... 最終的な証明書（ルート証明書）は正しいものとして予め（ブラウザが）持っておく PKI 沢山の証明書を相互認証しながら発行・破棄・管理する仕組み 23 / 24 

まとめ TLS1.3の流れ DH鍵共有によりクライアント・サーバ間で秘密鍵を共有 それを元にAEAD（ストリーム暗号+MAC）を使って暗号化通信 サーバ証明書に含まれる署名の検証鍵やCAの検証鍵で中間者攻撃を防止 サーバ証明書はCAを含むPKIによって管理 参考 イラストで正しく理解するTLS 1.3の暗号技術 RSA署名を正しく理解する 24 / 24