---
title: 暗号と認証のサーベイ
tags:  #開運研修  
author: [サイボウズ開発本部](https://www.docswell.com/user/cybozu-tech)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/9J29LZ31ER.jpg?width=480
description: 2026年エンジニア新人研修の資料です。
published: August 13, 26
canonical: https://www.docswell.com/s/cybozu-tech/K27JW6-cybozu-crypto2026
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/9J29LZ31ER.jpg)

暗号と認証のサーベイ
サイボウズ・ラボ 光成滋生
2026/04/ サイボウズ新人研修
1 / 43


# Page. 2

![Page Image](https://bcdn.docswell.com/page/DEY4QR14JM.jpg)

自己紹介
サイボウズ・ラボで暗号と高速化のR&D
ID : @herumi
2021 『暗号と認証のしくみと理論...』執筆
2024 『Binary Hacks Rebooted』寄稿 / 『笑わない数学』暗号理論監修
2025 早稲田大学情報基幹理工学部「セキュリティ基礎講義」担当
OSS活動
2024 (Xbyakで) Google Open Source Peer Bonus受賞
2024 (mcl/blsで) Ethereum Foundation PSE (Privacy + Scaling Explorations) Grant獲得x2
2016~2025 Microsoft MVP C++, Developer Security受賞
2 / 43
最近はLLVMの定数整数除算最適化アルゴリズムの改善など


# Page. 3

![Page Image](https://bcdn.docswell.com/page/VJNYKD2678.jpg)

スライドの目的
暗号と認証の基礎を学ぶ
情報セキュリティ
暗号化
署名
認証
認可
ID連携
FIDO2
TLS1.3
3 / 43


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE9PVG1RJ3.jpg)

情報セキュリティとは
ネットショッピングにおける望ましい状態
自分がどんな商品を買ったか他人に知られない
商品の値段や送付先が勝手に書き換えられない
いつでも買い物ができる
盗聴不可
×
情報セキュリティの三要素
機密性 (confidentiality)
許可されてない人が情報にアクセスできないこと
完全性 (integrity)
情報が改竄されたり消えたりせずに正確に存在すること
可用性 (availability)
許可された人が必要なときに情報にアクセスできること
改竄不可
×
故障耐性 ○
×
4 / 43


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE8DPV4GED.jpg)

情報セキュリティと暗号技術
JIS Q 27000
日本の産業の標準化のために定められた国家規格
日本産業標準調査会JISCが調査審議を行う
暗号技術との関係
情報セキュリティを守るには様々な技術が必要
その中で暗号化・認証・署名・改竄検知・否認防止などの技術を総称して暗号技術という
情報セキュリティの三要素と関連する暗号技術
要件
求められる特性
暗号技術の例
機密性
データの秘匿
暗号化・認証
完全性
データの正確さ
メッセージ認証符号・署名
可用性 データへのアクセスを担保する
秘密分散
5 / 43


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LELM156X7R.jpg)

追加された要件
真正性 (authenticity)
ユーザや、システムなどが本当にその人やものであり、偽物が紛れていないこと
本当に当事者であることを確認する
責任追及性 (accountability)
システムに対して誰が、いつ、何をしたのかを正確に記録して問題が起きたときに原因を追求
できること
否認防止 (non-repudiation)
なんらかの操作を後でなかったことにされないようにすること
信頼性 (reliability)
システムが不具合無く正確に動作していること
6 / 43


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4JMYW353JW.jpg)

問題
次は何を満たし、何を満たさないか
1. 正当な送信者からのデータが伝送中に破損 （機密性以外の観点で）
2. 不正者が送信した完全なデータ （機密性以外の観点で）
3. 正当な送信者からのデータが伝送中に傍受されて中身が漏洩
4. 年に一度メンテナンスで数日間止まるシステム
答え
1. 真正性: ○, 完全性:×
2. 真正性: ×, 完全性:○
3. 真正性: ○, 機密性:×
4. 可用性: × （停止期間が長い）, 信頼性:○ （予定通りに動作）
7 / 43


# Page. 8

![Page Image](https://bcdn.docswell.com/page/PJR9YQ3R79.jpg)

暗号 (encryption)
情報を第三者が見てもわからないようにする技術
情報セキュリティの機密性を守るために最も重要な要素
暗号化と復号
平文: 変換前の情報
暗号化: 平文を第三者が見てもわからないように変換すること
平⽂
暗号文: 変換された情報
今⽇はいい
復号: 暗号文を元の平文に戻すこと
天気
鍵
暗号（化）鍵: 暗号化に必要な情報
復号鍵: 復号に必要な情報
復号鍵は厳重に管理する必要がある（＝秘密鍵）
暗号化鍵
暗号化
復号
暗号⽂
*********
*******
復号鍵
8 / 43


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PEXQG54YJX.jpg)

暗号の種類
秘密鍵暗号・対称鍵暗号
復号鍵=暗号鍵＝秘密鍵
秘密鍵は当事者の間だけの秘密
公開鍵暗号（化方式）: PKE (Public Key Encryption)
復号鍵≠暗号鍵=公開鍵
復号鍵は秘密だが暗号鍵は他人に見せてもよい
実は昨今, 普通の人が使う場面はほとんど無い（ブラウザ, スマホ, マイナンバーカード, ssh）
暗号技術と暗号
暗号技術はデータを守る技術の総称
暗号（化）は暗号技術のうち、主に機密性に関わる技術
暗号技術のことを「暗号」ということも多いので文脈で判断
9 / 43


# Page. 10

![Page Image](https://bcdn.docswell.com/page/3EK946Z4ED.jpg)

認証 (Authentication)
完全性や真正性に関わる技術
パスワードによる認証
他人が推測できない複雑なものを決めて使う
適当な単語を複数並べて長くする
パスワードマネージャを利用する（それが攻撃されるリスクはある）
Webサービスごとに異なるパスワードを使う
同じパスワードを使い回すとあるサービスが攻撃を受けてパスワードが漏洩したとき
別のサービスに不正ログインされる危険性
秘密の質問
設定が必要なサービスもまだ多い
「出身地は?」など答えを推測されやすいものが多い
パスワードを複雑にしてもこちらを攻撃されると無意味
10 / 43
ランダムな答えを設定するのが望ましい


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L73WL6DD75.jpg)

そのほかの認証
ワンタイムパスワード (OTP: One Time Password)
一度だけ使うパスワード（時間依存なのはTOTP : Time-based OTP）
銀行などが物理的なハードウェアを顧客に配布してそれを入力
最近はスマートフォンアプリに表示される値を利用する傾向
静脈認証・指紋認証
生体情報を利用した認証
専用ハードウェアが必要
クライアント証明書
会社などから支給されたデータをブラウザやOSに登録する
登録したブラウザからしかアクセスできない
後の講義で
11 / 43


# Page. 12

![Page Image](https://bcdn.docswell.com/page/87DKNVP2JG.jpg)

認証の種類
一長一短
認証の種類 記憶する必要 紛失の危険性 コスト 紛失・漏洩時の対策
例
パスワード
知識認証
ある
ある
低
容易
パスフレーズ
指紋認証
虹彩認証
生体認証
無い ある（怪我など） 高
困難
静脈認証
顔認証
TOTP生成器
所有物認証 無い
ある
高
容易
USBトークン
電子証明書
12 / 43


# Page. 13

![Page Image](https://bcdn.docswell.com/page/VJPK5VNLE8.jpg)

MAC (Message Authentication Code)
データの改竄を検証できる仕組み
認証やデータの真正性の検証に利用される
手順
予めAとBの間で秘密鍵 を共有しておく
Aはデータ と秘密鍵 からMAC値 を計算し
データ とMAC値 をBに送る
Bは受け取ったデータ と からMAC値 を計算し
なら改竄されていないと判断し受理する
特徴
秘密鍵 を知らない人は受理できる や を作れない
暗号化ではないので盗聴者は と を見られる
s
A
s
s
B
m
MAC
MAC
t
t
13 / 43


# Page. 14

![Page Image](https://bcdn.docswell.com/page/2EVVPZK6EQ.jpg)

署名
秘密鍵を共有しなくてもデータの改竄を検証できる仕組み
鍵生成
署名者Aが署名鍵（秘密鍵） と検証鍵（公開鍵） を生成
署名
Aがデータ から署名鍵 を用いて署名 を作成
検証
検証者Bは
の組の正当性を確認
A
特徴
B
Gen
sk
vk
m
Verify
Sig
偽造防止: に対して正当な
は署名者Aしか作れない
が正当ならAが を承認したことを示す
公開鍵暗号PKC (Public Key Cryptography)の一種ではあるが暗号化(PKE)ではない
署名はMACの上位互換だが遅い
σ
1 or 0
14 / 43


# Page. 15

![Page Image](https://bcdn.docswell.com/page/57GLP4Q2EL.jpg)

FIDO（Fast IDentity Online）
多要素認証を扱いやすくするための規格
WebAuthn (Web Authentication)
署名を用いたパスワードレスな認証
ブラウザやスマホ・専用ハードウェアで実現
2018年Yahooが生体認証を利用したログインとしてWebAuthnを導入
パソコンやスマホの安全な領域に署名鍵（秘密鍵）の情報を保持
利用するときに顔認証や指紋認証などで本人確認
最近は署名鍵を複数のデバイスで安全に共有する機能もある
15 / 43


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4EQY2GK9JP.jpg)

多要素認証と攻撃・対策の変化
認証の種類を複数、組み合わせる（組合せる）
知識認証 ＋ 生体認証 or 知識認証 ＋ 所有物認証など
2要素認証 2FA (2 Factor Authentication) などと呼ばれる
スマホのパスワードマネージャがTOTPに対応して普及する
スマホが壊れたときの復旧対策が必要
偽URLを伴うフィッシング詐欺の横行
偽URLが記載されたメールをクリックして2FAを実行してしまう
URLに自分でパスワードやTOTPを入力したら危険
Appleのパスキーなど
スマホが壊れたときの対策として署名鍵を（クラウド上で復号できない形で）クラウドに保存
署名鍵の一元管理のリスクよりもフィッシング詐欺・スマホの紛失対策を優先
16 / 43


# Page. 17

![Page Image](https://bcdn.docswell.com/page/KJ4WL5KR71.jpg)

認可 (Authorization)
アクセス制御
ユーザの属性に応じてシステムへのアクセス権を決める
「認証」は本人であることの確認
「認可」はその人が何をしてよいかの決定（アクセス制御）
本人を認証した後に行う
17 / 43


# Page. 18

![Page Image](https://bcdn.docswell.com/page/LE1YLWXV7G.jpg)

OAuth
他のサービスに自分の情報へのアクセスを許可する仕組み
あるサービスAに（privateに）写真を登録
別のサービスBでその写真を利用したい
BによるAへのアクセスを許可したい
AのIDとパスワードをBに教えないで
readだけ許可したい
OAuthの流れ
1. BのアプリYが認可サーバにアクセス権を要求
2. ユーザ認証とアクセスの許諾
3. 認可コードを発行
4. アプリYが認可コードを使ってAからアクセストークンを取得
5. アプリYがアクセストークンを使ってAにアクセス
18 / 43


# Page. 19

![Page Image](https://bcdn.docswell.com/page/GEWGV6N3J2.jpg)

SSO (Single Sign-On)
一度のログインで複数のサービスを利用できる仕組み
社内ネットワークで複数サービスがあるとき, それぞれにパスワードを管理するのは大変
WebサービスでGoogleやFacebookなどの著名なサービスを利用して別サービスにログイン
主な実現方法
手法
Kerberos
SAML
OIDC
主な用途
社内ネットワーク 企業Web / SaaS モダンWeb / API
主なクライアント
OS・ドメイン ブラウザ中心 ブラウザ・アプリ中心
エンティティ（登場人物）
KDC
IdP / SP
IdP / RP
技術要素
対称鍵
XML署名
JWT署名
トークン種類
Ticket
Assertion
IDトークン
19 / 43
トークンは細部は違うが概ね認証結果を相手に伝えるための証明の役割


# Page. 20

![Page Image](https://bcdn.docswell.com/page/47ZL4Y3GJ3.jpg)

Kerberos認証
スケーラビリティと安全性のためにKDCに認証と鍵管理を集約
WindowsのActive Directoryなどで利用されている
登場人物
クライアント(Client)
KDC (Key Distribution Center)
認証サーバAS (Authentication Server)
クライアントごとの秘密鍵 を管理し, クライアントの本人認証を行う
TGT (Ticket Granting Ticket)を発行する
チケット発行サーバTGS (Ticket Granting Server)
TGTを受理してサービスチケット（認証情報・セッション鍵を含む）を発行する
ASとTGSは論理的には別だが多くの実装で同一KDC（同じ鍵管理・信頼境界を持つ）
SS (Service Server): 実際にサービスを提供するサーバ
20 / 43
SSの鍵はKDCに登録されている


# Page. 21

![Page Image](https://bcdn.docswell.com/page/YJ6W3DXQJV.jpg)

Kerberos認証の流れ
クライアント⇔AS
K_{c,tgs}: 一時鍵
K_{c,ss}: 一時鍵
K_{tgs,ss}: 長期鍵
パスワードからKDF (Key Derivation Function) を用いて を生成
TGTはTGSに見せるための一時チケット
ID, 有効期限, セッション鍵など
クライアント⇔TGS
TGTと認証子（タイムスタンプ含む）を送る
リプレイ耐性をもたせるため
クライアントはサービスチケットを見れない
クライアント⇔SS
サービスチケットと認証子を検証する
特徴
Client
AS (KDC)
TGS (KDC)
SS
① AS交換（TGT取得）
クライアントID‧タイムスタンプ
Enc(s, TGT) + Enc(s_i, K_{c,tgs})
② TGS交換（サービスチケット取得）
Enc(s, TGT) + Enc(K_{c,tgs},
Enc(K_{tgs,ss},
認証⼦) + サービスID
サービスチケット) + Enc(K_{c,tgs}, K_{c,ss})
③ AP交換（サービス利⽤）
Enc(K_{tgs,ss},
サービスチケット) + Enc(K_{c,ss}, 認証⼦)
Enc(K_{c,ss},
この構造により①は最初のログイン時のみ実行すればよい
以降は②と③だけで複数のSSを利用できるのでSSOを実現できる
タイムスタンプ)
21 / 43


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GJ5ML3X2J4.jpg)

OpenID Connect (OIDC)
ID連携技術
あるWebサービスのログイン画面にある別のサービスの「○○でログイン」ボタン
OAuth 2.0 (2012) は認可の仕組み
OpenID: ユーザ認証のみ (2005-2007): 事実上廃止でOIDCとは別物
OpenID Connect = OAuth 2.0 ＋ 認証 ＋ IDトークン
OAuthは「認可（何をしてよいか）」/OIDCは「認証（だれであるか）」を扱う
用語
IDトークン: ユーザの属性情報 (claim) を含むJWT (JSON Web Token: ジョット)
JWT: 改竄検知 (HMAC, 署名) 対応
IdP (Identity Provider): 認証してIDトークンとアクセストークンを発行
IDトークン: ログイン用（本人確認証）, アクセストークン: APIアクセス用
RP (Relying Party): IDトークンを検証し, アクセストークンを取得してログインを実現 22 / 43


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LE3WL6X1E5.jpg)

Authorization Code Flow (1/2)
ユーザ認証・登録の流れ
（IdPからブラウザに戻るデータ）が含むもの
state : CSRF (Cross-Site Request Forgery) 対策の乱数
CSRF: ユーザの意図しない動作を強制させる攻撃
攻撃者の認可コードを使わせないようにする
認可レスポンス時点で検証
nonce : リプレイ攻撃対策の乱数
一度しか使わない (number used once)
盗聴されたIDトークンを再利用させない
IDトークン検証時に検証（次ページ）
ユーザは何の情報を提供することに認可するかに同意
CODE : 認可コード（有効期限の短い乱数）を含む
GRANT : 認可コード, クライアントの情報を含む
RESP
ブラウザ
RP
1.
IdP
登録開始
「○○で登録」をクリック
2.
認可リクエスト
認可エンドポイント（IdPが提供）へリダイレクト
RESP
認可リクエスト送信
3.
認証と同意
ログイン画⾯表⽰
認証情報⼊⼒
ユーザー認証
同意画⾯表⽰(プロフィール情報の共有)
同意
4.
認可レスポンス
リダイレクトURI + 認可コード
CODE
認可コード送信
5.
トークンリクエスト
パラメータ検証
state
トークンエンドポイントへリクエスト
GRANT
6.
トークンレスポンス
23 / 43


# Page. 24

![Page Image](https://bcdn.docswell.com/page/8EDKNV2K7G.jpg)

Authorization Code Flow (2/2)
トークンレスポンスの続き
IdPが認可コードを検証しIDトークン, アクセストークンを発行
RPはIDトークンの署名と nonce を検証
署名の検証に必要な検証鍵（公開鍵）はIdPが提供
OpenID Configurationから取得 e.g. Google
検証鍵はそこに記載された jwks_uri で配布
アクセストークンを用いてユーザ情報を取得
sub : RPごとに異なるユーザ識別子 (Subject)
RPを越えてユーザを識別・追跡させないため
sub をキーとしてアカウント発行・登録
ユーザーは「IDを預ける」のではなく、IdPが発行した
IDトークン（本人確認証）をRPに渡す
ブラウザ
RP
6.
IdP
トークンレスポンス
認可コード検証
トークン + アクセストークン
ID
JWT
トークン検証とユーザー情報取得
7. ID
トークン検証(署名、nonce等)
ID
アクセストークン
ユーザー情報(JSON)
等
sub, name, email
8.
アカウント作成
ユーザーアカウント作成
セッション作成
ログイン完了‧ホーム画⾯表⽰
24 / 43


# Page. 25

![Page Image](https://bcdn.docswell.com/page/V7PK5V13J8.jpg)

SAML (Security Assertion Markup Language)
主に企業向けID連携技術
IdP (Identity Provider): ユーザを認証して認証結果を発行する
例: 社内認証基盤、Entra ID、Okta など
SP (Service Provider): 認証結果を受け取り、ログインを成立させるサービス
例: 社内の業務システム、Salesforce、Google Workspace など
OIDCのRP相当
Assertion: IdPが発行する「このユーザは認証済みである」という主張
IdPの署名鍵で署名されたXML形式のデータ
OIDCのIDトークン相当
主に以下を含む：
ユーザ識別子 (NameID): メールアドレス・社員番号など（OIDCのsub相当）
認証した事実
有効期限, 属性情報（メールアドレスなど）
25 / 43


# Page. 26

![Page Image](https://bcdn.docswell.com/page/2JVVPZYNJQ.jpg)

SAML Login Flow
Web SSOのユーザ認証の概要
ブラウザ
IdPがユーザ認証してAssertionを発行する
Assertion/ResponseをIdPの署名鍵で署名する
Assertionはブラウザ経由でSPへ直接渡される
SPはIdPの検証鍵で署名を検証する
Assertionには短い有効期限がある
Replay攻撃対策
どのSP向けかの情報を含む
他のSPで使い回しができない
主流は認可コードのような中継トークンが無い
SP
IdP
① アクセス
② IdP へリダイレクト（認証リクエスト）
② 認証リクエスト転送
③ ログイン画⾯
③ 認証情報⼊⼒
④ Assertion ⽣成（署名付き）
⑤ Assertion をブラウザ経由で返送
⑤ Assertion を POST
⑥ Assertion 検証（署名‧有効期限‧Audience）
⑥ ログイン完了
特徴
IdP / SP 間で明示的な信頼関係を構築し, 企業向けSSOで広く使われている
XMLベースで設定項目が多く, 運用がやや重い
26 / 43


# Page. 27

![Page Image](https://bcdn.docswell.com/page/5EGLP495JL.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4JQY2GWL7P.jpg)

Vernam暗号
排他的論理和 を利用した暗号
ビットの平文 に対して同じ長さの
ビットの秘密鍵（01からなる乱数） を準備する
暗号文を
とする
秘密鍵が1のところだけ平文の0と1を反転する
復号も暗号文 に対して秘密鍵が1のところだけ反転
特徴
情報理論的に安全（絶対に破れない）だが
暗号文と同じサイズの秘密鍵が必要
平文が1GiBなら1GiBの秘密鍵
乱数は1回しか使ってはいけない
→ 普通は使えない
暗号化
平⽂ 01100
1のところだけ
ビット反転
暗号⽂10101
秘密鍵 11001
復号
暗号⽂10101
秘密鍵 11001
平⽂ 01100
28 / 43


# Page. 29

![Page Image](https://bcdn.docswell.com/page/K74WL5K5E1.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/LJ1YLWX2EG.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GJWGV6N272.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/4EZL4Y3473.jpg)

認証つき暗号
AEAD (Authenticated Encryption with Associated Data)
秘密鍵による暗号化と認証を同時に行う仕組み
平文 と追加データ , ナンス と秘密鍵 から暗号文 とタグ を生成
秘密鍵
の共有
AES-GCM, ChaCha20-Poly1305 などがある
s
歴史
共通鍵暗号とMACは別々に安全性の研究
ブロック暗号AES-CBC+HMACが広く使われていたが
2011年のBEAST攻撃により、TLS1.3ではストリーム暗号のみに
s
m, n, d
AEAD
c, t
s
(n, d, c, t)
復号と検証
正当ならmを出⼒
不正なら何も出⼒しない
32 / 43


# Page. 33

![Page Image](https://bcdn.docswell.com/page/Y76W3DXG7V.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/G75ML3XX74.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/9J29LZXQER.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/DEY4QR8YJM.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/VJNYKDQR78.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE9PVGDZJ3.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE8DPV5YED.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LELM15Y97R.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4JMYW3NVJW.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/PJR9YQDW79.jpg)

マイナンバーカード
公的個人認証サービス
署名用電子証明書
「基本4情報（氏名・住所・生年月日・性別）＋個人の検証鍵」にCAが署名したもの
マイナンバーカードは証明書を耐タンパー性のハードウェアに格納
いろいろなシーンで使ってほしい by デジタル庁
利用者証明用電子証明書（本人の認証用）には基本4情報は含まれない
利用時の手順
1. なんらかの文書に署名鍵で署名する（要 署名用電子証明書のパスワード）
2. 「文書 + 署名 + 署名用電子証明書」を相手に送る
3. 相手はCAの検証鍵で署名用電子証明書の正しさを確認
4. 署名用電子証明書に含まれる検証鍵で文書の正しさを確認
ユーザの証明書が失効されていないかの検証も必要
42 / 43


# Page. 43

![Page Image](https://bcdn.docswell.com/page/PEXQG51VJX.jpg)

まとめ
TLS1.3の流れ
DH鍵共有によりクライアント・サーバ間で秘密鍵を共有
それを元にAEAD（ストリーム暗号+MAC）を使って暗号化通信
サーバ証明書に含まれる署名の検証鍵やCAの検証鍵で中間者攻撃を防止
サーバ証明書はCAを含むPKIによって管理
参考
イラストで正しく理解するTLS 1.3の暗号技術
RSA署名を正しく理解する
2025 早稲田大学情報基幹理工学部「セキュリティ基礎講義」
43 / 43