変更要約: 初版
2.1暗号技術
共通鍵暗号・公開鍵暗号・ハイブリッド暗号の使い分け、代表的な公開鍵暗号であるRSAと楕円曲線暗号（ECC/ECDSA）、鍵を安全に共有するDiffie-Hellman（DH）鍵交換とPFS（Perfect Forward Secrecy）、そして暗号の危殆化に備えるCRYPTREC暗号リスト・SSL/TLS暗号設定ガイドラインを学びます。
情報処理安全確保支援士として通信基盤やアプリケーションの暗号方式を設計・レビューする場面では、「暗号アルゴリズムを知っている」だけでは不十分で、性能要件・鍵配送の安全性・前方秘匿性（過去の通信の保護）といった業務上の制約から、最適な暗号方式の組み合わせを選び取る判断力が問われます。この節では共通鍵・公開鍵それぞれの得意分野を押さえたうえで、なぜ実際の通信路ではその両方を組み合わせる「ハイブリッド暗号」が使われるのか、そして鍵交換方式が長期的な安全性にどう影響するのかを、意思決定の視点で学びます。
2.1.1共通鍵暗号・公開鍵暗号・ハイブリッド暗号
- 共通鍵暗号（対称鍵暗号）＝暗号化と復号に同じ鍵を使う方式。AESなどが代表例で、演算が軽く大量データの暗号化に向くが、通信相手ごとに鍵を安全に配送する手段が別途必要になる（鍵管理の負荷が課題）。
- 公開鍵暗号（非対称鍵暗号）＝暗号化用の公開鍵と復号用の秘密鍵が別々の方式。鍵配送問題を解決できる（公開鍵は誰に渡しても安全）が、共通鍵暗号に比べて演算負荷が重く大量データの暗号化には不向き。
- ハイブリッド暗号＝公開鍵暗号で共通鍵（セッション鍵）を安全に配送し、実際のデータ本体は軽量な共通鍵暗号で暗号化する方式。TLSなど実際の通信プロトコルの大半がこの組み合わせを採用し、「鍵配送の安全性」と「大量データ処理の性能」を両立させる。
2.1.2RSAと楕円曲線暗号（ECC/ECDSA）
- RSA＝大きな合成数の素因数分解の困難性を安全性の根拠とする公開鍵暗号。長年の実績があり広く使われるが、同等の安全性を得るには鍵長を長くする必要があり、演算負荷や証明書サイズが大きくなりやすい。
- 楕円曲線暗号（ECC）＝楕円曲線上の離散対数問題の困難性を安全性の根拠とする公開鍵暗号。RSAより短い鍵長で同等の安全性を実現でき、モバイル端末やIoT機器など演算資源が限られる環境での性能面で有利。デジタル署名への応用がECDSA。
「RSA＝素因数分解の困難性」「ECC＝楕円曲線上の離散対数問題の困難性」「ECCはRSAより短い鍵長で同等強度」の対比が最頻出です。性能制約が厳しい（IoT・モバイル・大量の証明書発行）ならECC、実績・互換性を優先するならRSA、という判断軸を押さえましょう。
2.1.3Diffie-Hellman鍵交換とPFS（Perfect Forward Secrecy）
- Diffie-Hellman（DH）鍵交換＝通信の両者が公開情報だけをやり取りしながら、第三者には分からない共通の秘密鍵をその場で導出できる方式。鍵そのものを送らずに共有できる点が特徴。
- PFS（Perfect Forward Secrecy／前方秘匿性）＝サーバの長期秘密鍵が将来漏えいしても、過去に記録・傍受された通信内容までは復号されない性質。セッションごとに一時的な鍵ペアを使うDHE（一時DH）やECDHE（一時楕円曲線DH）を使うことでPFSを実現できる。
あるSaaS事業者のセキュリティ担当者が、顧客の機微データを扱うAPI基盤のTLS設定を見直しているとします。要件は次の3つです——(1) 将来サーバ証明書の秘密鍵が万一漏えいしても、過去に傍受・記録された通信が復号されないようにしたい（regulatorからの要求）、(2) 多数のIoTゲートウェイ機器（演算資源が限られる）も接続するため鍵長を抑えつつ十分な強度を確保したい、(3) 大量のAPIリクエスト本体は高スループットで暗号化・復号したい。まず(1)は静的なDH/RSA鍵交換ではなくECDHE（一時楕円曲線DH鍵交換）を使ってPFSを実現することで満たせます——セッションごとに使い捨ての鍵ペアを生成するため、長期鍵が後から漏えいしても過去のセッション鍵は再現できません。(2)はIoTゲートウェイの演算資源制約から、証明書の公開鍵アルゴリズムにRSAではなくECC（ECDSA署名）を選ぶことで、同等の安全性をより短い鍵長・軽い演算で実現できます。(3)は公開鍵暗号（ECDHEで交換した鍵）で確立したセッション鍵を使い、実データ本体はAESなどの共通鍵暗号で暗号化するハイブリッド構成とすることで、公開鍵暗号の安全性と共通鍵暗号の高速性を両立させます。まとめると、この担当者は「TLS 1.2/1.3でECDHE鍵交換＋ECDSA証明書＋AES本体暗号」という構成を選ぶことになり、これは性能制約・前方秘匿性・鍵配送の安全性という3つの要件をすべて満たす判断です。加えて、採用する暗号アルゴリズムと鍵長はCRYPTREC暗号リストやSSL/TLS暗号設定ガイドラインに記載された推奨方式から選定し、危殆化した旧世代の方式（鍵長の短いRSAや旧バージョンのSSL等）は使わないことも忘れてはならない。
| 要件 | 適した方式 | 理由 |
|---|---|---|
| 前方秘匿性（過去の通信を守りたい） | ECDHE / DHE（一時鍵交換） | セッションごとに使い捨て鍵を生成し長期鍵漏えいの影響を遮断 |
| 演算資源が限られる（IoT・モバイル） | ECC/ECDSA | RSAより短い鍵長で同等強度・軽い演算 |
| 大量データの高速暗号化 | 共通鍵暗号（AES等）とのハイブリッド構成 | 公開鍵暗号は鍵配送のみに使い本体は軽量な共通鍵暗号で処理 |
ひっかけ： 「静的なRSA鍵交換でもTLSの機密性は確保できるので前方秘匿性の要件も満たす」は誤りです——静的RSA鍵交換は長期秘密鍵が漏えいすると過去に記録された通信も遡って復号されてしまうため、PFSを満たしません。PFSが必須の要件であればECDHE/DHEなどの一時鍵交換を選ぶ必要があります。また「暗号アルゴリズムは一度安全と判断されたら未来永劫使い続けてよい」も誤り＝計算機資源の進歩や新たな解読法により暗号は危殆化するため、CRYPTREC暗号リスト等を定期的に確認し、危殆化した方式から計画的に移行する運用が必要です。
2.1.4この節のまとめ
- 共通鍵暗号は高速だが鍵配送が課題、公開鍵暗号は鍵配送を解決するが低速。両者を組み合わせるハイブリッド暗号が実際の通信の基本形
- RSA＝素因数分解の困難性、ECC/ECDSA＝楕円曲線上の離散対数問題の困難性で、ECCは短い鍵長で同等強度
- 前方秘匿性（PFS）が必要ならECDHE/DHE（一時鍵交換）を選び、暗号方式は危殆化に備え定期的に見直す
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. あるサービスのTLS基盤を担当するセキュリティ担当者が、「サーバ証明書の秘密鍵が将来漏えいしても、過去に傍受・保存された通信内容は復号されないようにしたい」という規制要件に対応する必要がある。最も適した鍵交換方式はどれか。
Q2. 演算資源が限られるIoTゲートウェイ機器を多数接続するシステムで、サーバ証明書の公開鍵暗号アルゴリズムを選定している。RSAと比較したときの楕円曲線暗号（ECC/ECDSA）の利点として最も適切なものはどれか。
Q3. ある組織が長年運用してきたシステムで、鍵長の短いRSA鍵や旧バージョンのSSLがいまだに使われていることが監査で判明した。この状況に対する最も適切な今後の運用方針はどれか。