暗号と認証のサーベイ
>100 Views
August 13, 26
スライド概要
2026年エンジニア新人研修の資料です。
サイボウズ株式会社の主に開発本部の資料を公開するアカウントです。
関連スライド
各ページのテキスト
暗号と認証のサーベイ サイボウズ・ラボ 光成滋生 2026/04/ サイボウズ新人研修 1 / 43
自己紹介 サイボウズ・ラボで暗号と高速化の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の定数整数除算最適化アルゴリズムの改善など
スライドの目的 暗号と認証の基礎を学ぶ 情報セキュリティ 暗号化 署名 認証 認可 ID連携 FIDO2 TLS1.3 3 / 43
情報セキュリティとは ネットショッピングにおける望ましい状態 自分がどんな商品を買ったか他人に知られない 商品の値段や送付先が勝手に書き換えられない いつでも買い物ができる 盗聴不可 × 情報セキュリティの三要素 機密性 (confidentiality) 許可されてない人が情報にアクセスできないこと 完全性 (integrity) 情報が改竄されたり消えたりせずに正確に存在すること 可用性 (availability) 許可された人が必要なときに情報にアクセスできること 改竄不可 × 故障耐性 ○ × 4 / 43
情報セキュリティと暗号技術 JIS Q 27000 日本の産業の標準化のために定められた国家規格 日本産業標準調査会JISCが調査審議を行う 暗号技術との関係 情報セキュリティを守るには様々な技術が必要 その中で暗号化・認証・署名・改竄検知・否認防止などの技術を総称して暗号技術という 情報セキュリティの三要素と関連する暗号技術 要件 求められる特性 暗号技術の例 機密性 データの秘匿 暗号化・認証 完全性 データの正確さ メッセージ認証符号・署名 可用性 データへのアクセスを担保する 秘密分散 5 / 43
追加された要件 真正性 (authenticity) ユーザや、システムなどが本当にその人やものであり、偽物が紛れていないこと 本当に当事者であることを確認する 責任追及性 (accountability) システムに対して誰が、いつ、何をしたのかを正確に記録して問題が起きたときに原因を追求 できること 否認防止 (non-repudiation) なんらかの操作を後でなかったことにされないようにすること 信頼性 (reliability) システムが不具合無く正確に動作していること 6 / 43
問題 次は何を満たし、何を満たさないか 1. 正当な送信者からのデータが伝送中に破損 （機密性以外の観点で） 2. 不正者が送信した完全なデータ （機密性以外の観点で） 3. 正当な送信者からのデータが伝送中に傍受されて中身が漏洩 4. 年に一度メンテナンスで数日間止まるシステム 答え 1. 真正性: ○, 完全性:× 2. 真正性: ×, 完全性:○ 3. 真正性: ○, 機密性:× 4. 可用性: × （停止期間が長い）, 信頼性:○ （予定通りに動作） 7 / 43
暗号 (encryption) 情報を第三者が見てもわからないようにする技術 情報セキュリティの機密性を守るために最も重要な要素 暗号化と復号 平文: 変換前の情報 暗号化: 平文を第三者が見てもわからないように変換すること 平⽂ 暗号文: 変換された情報 今⽇はいい 復号: 暗号文を元の平文に戻すこと 天気 鍵 暗号（化）鍵: 暗号化に必要な情報 復号鍵: 復号に必要な情報 復号鍵は厳重に管理する必要がある（＝秘密鍵） 暗号化鍵 暗号化 復号 暗号⽂ ********* ******* 復号鍵 8 / 43
暗号の種類 秘密鍵暗号・対称鍵暗号 復号鍵=暗号鍵＝秘密鍵 秘密鍵は当事者の間だけの秘密 公開鍵暗号（化方式）: PKE (Public Key Encryption) 復号鍵≠暗号鍵=公開鍵 復号鍵は秘密だが暗号鍵は他人に見せてもよい 実は昨今, 普通の人が使う場面はほとんど無い（ブラウザ, スマホ, マイナンバーカード, ssh） 暗号技術と暗号 暗号技術はデータを守る技術の総称 暗号（化）は暗号技術のうち、主に機密性に関わる技術 暗号技術のことを「暗号」ということも多いので文脈で判断 9 / 43
認証 (Authentication) 完全性や真正性に関わる技術 パスワードによる認証 他人が推測できない複雑なものを決めて使う 適当な単語を複数並べて長くする パスワードマネージャを利用する（それが攻撃されるリスクはある） Webサービスごとに異なるパスワードを使う 同じパスワードを使い回すとあるサービスが攻撃を受けてパスワードが漏洩したとき 別のサービスに不正ログインされる危険性 秘密の質問 設定が必要なサービスもまだ多い 「出身地は?」など答えを推測されやすいものが多い パスワードを複雑にしてもこちらを攻撃されると無意味 10 / 43 ランダムな答えを設定するのが望ましい
そのほかの認証 ワンタイムパスワード (OTP: One Time Password) 一度だけ使うパスワード（時間依存なのはTOTP : Time-based OTP） 銀行などが物理的なハードウェアを顧客に配布してそれを入力 最近はスマートフォンアプリに表示される値を利用する傾向 静脈認証・指紋認証 生体情報を利用した認証 専用ハードウェアが必要 クライアント証明書 会社などから支給されたデータをブラウザやOSに登録する 登録したブラウザからしかアクセスできない 後の講義で 11 / 43
認証の種類 一長一短 認証の種類 記憶する必要 紛失の危険性 コスト 紛失・漏洩時の対策 例 パスワード 知識認証 ある ある 低 容易 パスフレーズ 指紋認証 虹彩認証 生体認証 無い ある（怪我など） 高 困難 静脈認証 顔認証 TOTP生成器 所有物認証 無い ある 高 容易 USBトークン 電子証明書 12 / 43
MAC (Message Authentication Code) データの改竄を検証できる仕組み 認証やデータの真正性の検証に利用される 手順 予めAとBの間で秘密鍵 を共有しておく Aはデータ と秘密鍵 からMAC値 を計算し データ とMAC値 をBに送る Bは受け取ったデータ と からMAC値 を計算し なら改竄されていないと判断し受理する 特徴 秘密鍵 を知らない人は受理できる や を作れない 暗号化ではないので盗聴者は と を見られる s A s s B m MAC MAC t t 13 / 43
署名 秘密鍵を共有しなくてもデータの改竄を検証できる仕組み 鍵生成 署名者Aが署名鍵（秘密鍵） と検証鍵（公開鍵） を生成 署名 Aがデータ から署名鍵 を用いて署名 を作成 検証 検証者Bは の組の正当性を確認 A 特徴 B Gen sk vk m Verify Sig 偽造防止: に対して正当な は署名者Aしか作れない が正当ならAが を承認したことを示す 公開鍵暗号PKC (Public Key Cryptography)の一種ではあるが暗号化(PKE)ではない 署名はMACの上位互換だが遅い σ 1 or 0 14 / 43
FIDO（Fast IDentity Online） 多要素認証を扱いやすくするための規格 WebAuthn (Web Authentication) 署名を用いたパスワードレスな認証 ブラウザやスマホ・専用ハードウェアで実現 2018年Yahooが生体認証を利用したログインとしてWebAuthnを導入 パソコンやスマホの安全な領域に署名鍵（秘密鍵）の情報を保持 利用するときに顔認証や指紋認証などで本人確認 最近は署名鍵を複数のデバイスで安全に共有する機能もある 15 / 43
多要素認証と攻撃・対策の変化 認証の種類を複数、組み合わせる（組合せる） 知識認証 ＋ 生体認証 or 知識認証 ＋ 所有物認証など 2要素認証 2FA (2 Factor Authentication) などと呼ばれる スマホのパスワードマネージャがTOTPに対応して普及する スマホが壊れたときの復旧対策が必要 偽URLを伴うフィッシング詐欺の横行 偽URLが記載されたメールをクリックして2FAを実行してしまう URLに自分でパスワードやTOTPを入力したら危険 Appleのパスキーなど スマホが壊れたときの対策として署名鍵を（クラウド上で復号できない形で）クラウドに保存 署名鍵の一元管理のリスクよりもフィッシング詐欺・スマホの紛失対策を優先 16 / 43
認可 (Authorization) アクセス制御 ユーザの属性に応じてシステムへのアクセス権を決める 「認証」は本人であることの確認 「認可」はその人が何をしてよいかの決定（アクセス制御） 本人を認証した後に行う 17 / 43
OAuth 他のサービスに自分の情報へのアクセスを許可する仕組み あるサービスAに（privateに）写真を登録 別のサービスBでその写真を利用したい BによるAへのアクセスを許可したい AのIDとパスワードをBに教えないで readだけ許可したい OAuthの流れ 1. BのアプリYが認可サーバにアクセス権を要求 2. ユーザ認証とアクセスの許諾 3. 認可コードを発行 4. アプリYが認可コードを使ってAからアクセストークンを取得 5. アプリYがアクセストークンを使ってAにアクセス 18 / 43
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 トークンは細部は違うが概ね認証結果を相手に伝えるための証明の役割
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に登録されている
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
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
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
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
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
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
TLS1.3 通信を暗号化するプロトコル 鍵共有 クライアントとサーバが秘密の鍵を共有する 署名検証 サーバが本当に正しいサーバであることを示す AEAD クライアント サーバ 鍵共有開始 暗号化開始 / 公開鍵証明書‧署名送信 署名の検証 本来の暗号化通信 共有した秘密鍵を用いて改竄不可能な暗号通信を行う 解説の流れ AEAD → 鍵共有 → 署名 27 / 43
Vernam暗号 排他的論理和 を利用した暗号 ビットの平文 に対して同じ長さの ビットの秘密鍵（01からなる乱数） を準備する 暗号文を とする 秘密鍵が1のところだけ平文の0と1を反転する 復号も暗号文 に対して秘密鍵が1のところだけ反転 特徴 情報理論的に安全（絶対に破れない）だが 暗号文と同じサイズの秘密鍵が必要 平文が1GiBなら1GiBの秘密鍵 乱数は1回しか使ってはいけない → 普通は使えない 暗号化 平⽂ 01100 1のところだけ ビット反転 暗号⽂10101 秘密鍵 11001 復号 暗号⽂10101 秘密鍵 11001 平⽂ 01100 28 / 43
疑似乱数とストリーム暗号 疑似乱数生成器PRNG (Pseudo Random Number Generator) 初期値 (seed) をに入れると好きなだけ長い乱数が確定的に得られる装置・アルゴリズム s : seed PRNG 乱数 r: 010010011010100... 本当の乱数ではないが本当の乱数であるかのように見える いろいろな乱数試験をパスする必要あり PRNGを使ったストリーム暗号 PRNGを使って乱数 を生成し、Vernam暗号に適用する 秘密鍵は乱数生成器の初期値 に利用する（128ビットとか256ビットとか） Vernam暗号の情報的安全性は無いが扱いやすい 乱数生成器の性能に安全性が依存（計算量的安全性） 29 / 43
改竄攻撃 ストリーム暗号はビット反転に弱い 暗号文 の特定のビットだけ反転できる 攻撃者がデータのある場所が yes/no を表す1ビットだと知っていたら 復号できなくても平文を操作できる 平⽂ m: 001101 乱数 r: 010010 ⊕ 暗号⽂ c: 011111 通信 攻撃者 3ビット⽬を反転 暗号⽂ c' : 011 0 11 ⊕ 平⽂ m' : 001 0 01 乱数 r: 010010 改竄を検知する必要がある MACを使う 30 / 43
AES ブロック暗号の一種 共通鍵の一種でブロック単位（e.g. 128ビット）で暗号化する 暗号利用モード ブロックを秘密鍵で暗号化するといつも同じ暗号文のブロック ナンス（一度しか使わない数）などを組み合わせて毎回異なる暗号文にする必要がある CTR (Counter Mode) ナンスとカウンタを暗号化して疑似乱数を生成し、ストリーム暗号として利用 31 / 43
認証つき暗号 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
盗聴可能な経路で秘密の情報を共有 鍵共有の必要性 AEADは事前に秘密鍵の共有が必要 盗聴可能な経路でどうやって? 公開鍵暗号 PKC (Public Key Cryptography) 暗号技術全般 秘密情報と公開情報の組み合わせを利用した暗号技術全般 公開鍵暗号 共通鍵暗号 鍵共有はPKCの一種 / 暗号化ではない ハッシュ関数 公開鍵暗号（化 ） 署名 公開鍵と秘密鍵を組み合わせた公開鍵暗号化方式 鍵共有 準同型暗号 PKE(Public Key Encryption) と区別する TLS1.3では基本的にPKEは使われない PKC PKE MAC ... MPC ZKP ... 33 / 43
楕円曲線を用いたDH鍵共有 ECDH (Elliptic Curve Diffie-Hellman) 鍵共有 現在主流の方式 楕円曲線とは? 「楕円」でも「曲線」でもない「楕円曲線」という一つの用語 どちらかというと「浮輪の表面」 複素数的な曲線なので2次元 楕円曲線上の点同士は足し算・引き算ができる など 34 / 43
楕円DH鍵共有 セットアップ 楕円曲線 と, 倍すると0になる点 を選んでおく 共有 アリスは乱数 ボブは乱数 アリスは ボブは を選び を選び を送信 を送信 を を計算して同じ値を共有 秘密情報と公開情報 通信経路を流れるのは , , , はアリス、ボブのそれぞれが秘密に保持 アリス ボブ 秘密鍵 a を⽣成し A = aP とする A を送信 秘密鍵 b を⽣成し B = bP とする B を送信 共有鍵 K = aB を計算 共有鍵 K = bA を計算 35 / 43
それで安全なのか? 攻撃者（盗聴者）が持つ情報 楕円曲線と点 , 攻撃者が欲しい情報 , 現状 現在のスパコンが何台あっても , , などを求められないと信じられている ECDH困難 高性能な量子計算機が登場すると破られることが知られている 耐量子計算機暗号PQC（Post-Quantum Cryptography) 量子計算機に対しても安全な現在のコンピュータで実行できる暗号技術 2024年 ML (Module Lattice)-KEMというPQCのPKE, 鍵共有方式が標準化された 2025年 Chrome, Edge, Safariなどで対応 36 / 43
鍵共有+AEADでOKか? 盗聴するだけの経路なら安全 攻撃者が積極的にデータを改竄するなら安全ではない 中間者攻撃 AITM (Atattack In The Middle) 攻撃者が中間に入って公開情報を改竄する DH鍵共有に対するAITM TLSではその対策にPKCの一種である署名を使う 37 / 43
署名の方式の種類 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
サーバ証明書 サーバの検証鍵と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
TLS1.3での使われ方 プロトコルの流れ クライアントはサーバにDH鍵共有のデータを送信 サーバはDH鍵共有されたデータを元にAEADの準備 それまでの通信データと証明書に署名鍵 で署名 → σ これらをすべて暗号化して送信 クライアント CAの検証鍵 でサーバ証明書を検証 サーバ証明書に含まれるサーバの検証鍵 で 通信全体を確認 → 攻撃されていないことを確認 サーバの 署名鍵で署名したσ の 署名鍵で 署名したσ' サーバ証明書 CA cybozu.com サーバの検証鍵S ClientHello, etc. 40 / 43
公開鍵基盤 PKI (Public Key Infrastructure) 公開鍵の管理 クライアントは認証局CAの検証鍵 をどうやって持っておく? その認証局の証明書の検証は、更に別の他の認証局の検証鍵で検証... 最終的な証明書（ルート証明書）は正しいものとして予め（ブラウザが）持っておく PKI 沢山の証明書を相互認証しながら発行・破棄・管理する仕組み 41 / 43
マイナンバーカード 公的個人認証サービス 署名用電子証明書 「基本4情報（氏名・住所・生年月日・性別）＋個人の検証鍵」にCAが署名したもの マイナンバーカードは証明書を耐タンパー性のハードウェアに格納 いろいろなシーンで使ってほしい by デジタル庁 利用者証明用電子証明書（本人の認証用）には基本4情報は含まれない 利用時の手順 1. なんらかの文書に署名鍵で署名する（要 署名用電子証明書のパスワード） 2. 「文書 + 署名 + 署名用電子証明書」を相手に送る 3. 相手はCAの検証鍵で署名用電子証明書の正しさを確認 4. 署名用電子証明書に含まれる検証鍵で文書の正しさを確認 ユーザの証明書が失効されていないかの検証も必要 42 / 43
まとめ TLS1.3の流れ DH鍵共有によりクライアント・サーバ間で秘密鍵を共有 それを元にAEAD（ストリーム暗号+MAC）を使って暗号化通信 サーバ証明書に含まれる署名の検証鍵やCAの検証鍵で中間者攻撃を防止 サーバ証明書はCAを含むPKIによって管理 参考 イラストで正しく理解するTLS 1.3の暗号技術 RSA署名を正しく理解する 2025 早稲田大学情報基幹理工学部「セキュリティ基礎講義」 43 / 43