鍵の使い方を比較する

通信が暗号化されていることと、正しい相手へ接続していることは同じではありません。ハッシュが一致することと、誰が作ったかが分かることも違います。暗号、ハッシュ、署名、証明書を役割から整理し、それらを組み合わせるTLSの流れを理解しましょう。

守りたい性質から仕組みを選ぶ

性質	仕組みと限界
機密性	許された相手だけが内容を読めるよう暗号化する
完全性	改変を検知する。期待値や鍵の信頼が必要
相手の確認	公開鍵を相手と結び付け、対応する秘密鍵の所持を確認する
可用性	必要時に利用できること。暗号化だけで停止や過負荷を防げるわけではない

一つの仕組みで全部を保証しようとしないことが出発点です。保存ファイルの暗号化、ソフトウェアへの署名、Web通信のTLSは、守る対象と信頼する鍵が異なります。

共通鍵暗号と公開鍵暗号

共通鍵暗号は送信側と受信側が共有する秘密鍵を用います。大量のデータを効率よく保護する用途に向きますが、通信相手へ秘密鍵をどう安全に共有するかが課題です。鍵が漏れればその鍵で保護する範囲へ影響します。

公開鍵方式は公開してよい鍵と秘密にする鍵の組を使います。公開鍵暗号で相手へ秘密を送るなら相手の公開鍵で暗号化し、相手だけが秘密鍵で復号します。電子署名では署名者が秘密鍵で署名を作り、受信者が公開鍵で検証します。ただし署名を単なる「秘密鍵で暗号化」と説明すると、方式の役割を混同します。

鍵の使い方を比較する

目的と処理する場所を対応付けて読みます。

ここでの公開鍵暗号は暗号化の用途です。公開鍵の仕組みには鍵共有や署名もあり、同じ名前でも用途は違います。どの当事者の鍵を、どの処理に使うかを毎回確かめます。

算法名は用途と対応付ける

算法・方式の例	用途と読み方
AES	共通鍵暗号の算法。安全な利用にはモード・鍵・nonce等の条件も必要
RSA	公開鍵方式の一例。暗号化用と署名用の処理・符号化を区別する
ECDHE	楕円曲線の一時鍵を用いた鍵共有。大きなデータの暗号化そのものではない
ECDSA	楕円曲線を使う電子署名の方式
SHA-256	ハッシュ関数。単体の高速計算だけでパスワードを保存しない

実装では算法の名前だけを指定して独自に組み合わせるのでなく、適切な方式を提供する標準的なライブラリを利用します。共通鍵の長さと公開鍵の長さは、同じ数値なら同じ強度という関係ではありません。

ハッシュとメッセージ認証

ハッシュはデータから固定形式の値を計算する仕組みです。内容が違えば値が変わることを利用して比較しますが、秘密鍵を使わない通常のハッシュだけでは作成者を証明できません。攻撃者がファイルと期待値の両方を置き換えられるなら、一致しても真正性の根拠は弱くなります。

MACは秘密鍵を使って改変の有無などを確認する値を生成する仕組みです。HMACはハッシュ関数を利用したMACです。共通の秘密を持つ相手の間で確認できますが、同じ鍵を持つ当事者なら作成できるため、第三者に署名者を示す電子署名とは役割が違います。

TLSで使うAEADは、暗号化に加え、暗号文と付随する情報の認証を扱います。nonce（その暗号処理に用いる一度限りの値）について、同じ鍵との組合せを繰り返さないなど、方式の前提も重要です。暗号算法が強くても、乱数生成・鍵の使い回し・保管・実装の不備で安全性が崩れます。

ハッシュの特性と、鍵のライフサイクル

ハッシュの原像計算の困難さは、与えられた値から一致する入力を探しにくい性質です。衝突耐性は、同じ値になる異なる入力の組を探しにくい性質です。出力の長さは有限なので、理論上衝突が全くないとは言いません。用途に必要な性質と、安全性が評価された方式を選びます。

鍵は生成、配布・登録、保管、利用、更新、無効化・廃棄まで管理します。秘密鍵の利用権限とバックアップを限定し、誰がいつ何のために使ったか記録します。侵害が疑われた場合は影響範囲を確認し、鍵の交換だけでなく古い鍵への信頼を停止する手順も必要です。

電子署名が証明する範囲

電子署名の検証は、受信データと署名が対応すること、および信頼した公開鍵に対応する秘密鍵で署名されたことの確認に役立ちます。公開鍵が本当に誰のものかを別の仕組みで確認する必要があります。署名があるだけでファイルの処理内容が安全だとは言えません。

署名者の秘密鍵が侵害されれば、不正な内容へ正しく検証される署名が作られる可能性があります。署名が成立した事実と、本人の意図・安全な内容・鍵の非侵害を分けて考えます。ソフトウェア配布の信頼範囲はサプライチェーンの記事で応用します。

PKIと証明書チェーン

PKIは公開鍵と主体の対応を証明書などで管理する基盤です。CAは証明書を発行する認証局です。証明書には主体、公開鍵、有効期間などが入り、発行者の署名で結び付けられます。Web接続では接続先名との一致と用途も確認します。

サーバ証明書の署名を中間CAの公開鍵で確かめ、その中間CAの証明書をさらに上位で確かめる、というチェーンをたどります。最終的な信頼の基点は、利用者の環境にあらかじめ信頼されたルートなどのトラストアンカーです。ルートが自己署名していることだけで、信頼できる主体になるわけではありません。

証明書の信頼をたどる

1. 中間CA証明書に署名
2. サーバ証明書に署名

矢印は発行・署名の関係です。検証する側はサーバから信頼の基点へたどります。

架空の接続先はapp.example.comです。証明書の名前が別のホストだけを示すなら、チェーンの署名が正しくても接続先の確認は不成立です。有効期間内でも鍵が侵害されれば失効が必要で、失効情報の確認方法と、確認できない場合の動作は利用環境に依存します。

確認項目	失敗する例
チェーンと信頼の基点	知らないCAで終わる、必要な中間証明書がない
名前	接続したホスト名と証明書の対象名が合わない
期間・用途	期限切れ、サーバ認証に適した用途でない
失効	有効期間内でも侵害等によって無効化されている

証明書は通常公開してよい情報です。証明書を受け取っただけでは、その相手が秘密鍵を持つと確認したことにはなりません。実際の通信手続で、公開鍵に対応する秘密鍵を使えることを示す必要があります。

失効情報の確認：CRLとOCSP

CRLは失効した証明書の情報をまとめたリスト、OCSPは対象証明書の状態を問い合わせるためのプロトコルです。どちらも更新時刻や取得・検証の条件を確認します。OCSP staplingでは、サーバが取得した署名付きの状態情報をTLSの接続時に渡すことで、クライアント側の直接問い合わせを減らせます。

失効情報を取得できない場合に接続を続けるか止めるかは、実装・設定・要件で変わります。確認失敗を必ず安全な拒否になると決め付けず、対象環境の挙動を確かめます。サーバの期限更新、時刻の同期、必要な中間証明書の配布も運用上の確認点です。

TLS1.3：相手確認と共有鍵で通信する

TLSは通信路を保護するプロトコルです。HTTPSはHTTPをTLSで保護した通信です。ここでは通常の証明書認証と一時的な鍵共有を使うTLS1.3の概略を扱います。再開接続やPSK、0-RTT、クライアント証明書を使う方式は条件が異なり、図はそれらすべてを表すものではありません。

TLS1.3の基本的な流れ

証明書認証を使う概略図です。サーバのFinishedを含む複数メッセージと鍵導出を本文で補います。

ClientHelloとServerHelloで方式と鍵共有の情報などを交換し、共有秘密から用途別の鍵を導出します。証明書とCertificateVerifyによる署名で接続先の鍵と通信の文脈を結び付け、Finishedでハンドシェイクの完全性などを確認します。サーバもFinishedを送ります。アプリケーションデータは導出した共通鍵を用いて保護します。

TLS1.3では、古いRSA鍵輸送のように「サーバの公開鍵で通信の共通鍵を暗号化して送る」と説明しません。通常の一時鍵共有では、一時的な秘密値から双方が共有秘密を計算します。サーバの証明書用秘密鍵と通信データ保護用の鍵は役割が異なります。

前方秘匿性は、長期の秘密鍵が後で漏れても、適切に運用された一時鍵共有の過去の通信が直ちに復号されない性質です。あらゆるTLS方式に無条件であるとは言えず、PSKだけの鍵共有などの条件を区別します。0-RTTデータには再送攻撃の懸念があり、振込など重複実行が困る操作を無条件に流す設計は避けます。

TLSの終端と、守られない範囲

ロードバランサでTLSを終端すると、クライアントから終端までと、終端からアプリまでの通信は別の区間です。後半を平文にすれば、その区間の盗聴・改変への対策は別に必要です。外側のHTTPSという表示だけで全区間の暗号化を断定できません。

TLSはDBに保存した平文、権限設定ミス、SQLi、XSS、利用者端末や終端サーバの侵害まで解決しません。正しい相手と保護された経路で通信しても、相手側の処理が不適切なら被害は生じます。通信経路、保存先、アプリの処理を分けて対策を確認します。

text

クライアント --TLS--> LB --別の通信--> アプリ
確認：LB以降もTLSか、認証する相手は誰か
証明書鍵：サーバの認証・署名のため
通信の鍵：共有秘密から導出してデータを保護
保管：秘密鍵の利用権限・使用記録・更新を管理

演習1：受信者へ暗号化

条件：AがBだけに読めるファイルを公開鍵暗号で送る。

問い：どの鍵で暗号化し、どの鍵で復号するか。

解答例：Bの公開鍵で暗号化し、Bの秘密鍵で復号する。

根拠と誤答の確認：Aの秘密鍵で暗号化するという答えは署名と混同しています。

演習2：署名の向き

条件：Aがファイルへ署名し、Bが検証する。

問い：使う鍵を答える。

解答例：Aの秘密鍵で署名を作り、信頼するAの公開鍵で検証する。

根拠と誤答の確認：検証者Bの公開鍵では署名者Aとの対応を確認できません。

演習3：証明書の名前

条件：接続先はapp.example.com。証明書はother.example.comだけを対象とする。

問い：チェーンが正しければ接続を受け入れてよいか。

解答例：よくない。証明書の対象名が接続先名と一致しないため。

根拠と誤答の確認：署名チェーンと接続先名の確認は別々に必要です。

演習4：有効期間と失効

条件：証明書の期限は来年だが、対応する秘密鍵が漏えいした。

問い：期限内なので利用を継続してよいか。

解答例：よくない。侵害した鍵の利用を止め、証明書の失効と鍵・証明書の交換を行う。

根拠と誤答の確認：期限内という条件は鍵が侵害されていない証明ではありません。

演習5：終端後の区間

条件：利用者からLBはTLS、LBからアプリは平文。

問い：全区間がTLSで守られると言えるか。

解答例：言えない。LBでTLSが終端し、アプリまでの区間は別途保護する必要がある。

根拠と誤答の確認：HTTPSの接続先と実際の終端位置を見ます。

演習6：TLS1.3の鍵

条件：通常の証明書認証と一時鍵共有を用いる。

問い：通信データの鍵は証明書の公開鍵で暗号化して送るのか。

解答例：そうではない。一時鍵共有で得た共有秘密から通信保護用の鍵を導出する。

根拠と誤答の確認：証明書の公開鍵は相手確認の署名検証に用います。旧来のRSA鍵輸送の説明を持ち込みません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。技術仕様とIPAの公開資料を照合し、特定年度の問題本文を前提にせず学べる構成にしています。

暗号・署名・PKI・TLS｜鍵と証明書の役割を通信の流れで理解する