暗号理論基礎 • Yu Tokunaga

概要

暗号理論は、情報セキュリティの基盤を構成する学問分野である。本章では、現代社会における暗号技術の理論的枠組みと実装技術について体系的に述べる。情報処理安全確保支援士試験（SC試験）において要求される暗号基盤の知識を網羅することを目的とする。

1. 暗号技術の目的と分類

暗号技術は、情報の以下の特性を実現するために用いられる：

機密性（Confidentiality）：第三者に見られないようにする
完全性（Integrity）：改ざんされていないことを保証する
認証（Authentication）：相手が本物であることを確認する
否認防止（Non-repudiation）：あとから「知らない」と言わせない

主な技術分類は以下のとおり：

共通鍵暗号方式（対称鍵暗号方式）
公開鍵暗号方式（非対称鍵暗号方式）
ハッシュ関数
デジタル署名
鍵交換プロトコル

2. 共通鍵暗号方式

共通鍵暗号（対称鍵暗号）は、暗号化と復号に同一の鍵を使用する方式であり、最も歴史のある暗号手法の一つです。現代でもVPNやストレージ暗号化など、大容量データの暗号処理には不可欠な存在です。

特徴と利点

高速かつ軽量：鍵の長さが比較的短く、アルゴリズム構造も単純なため、処理性能に優れる。
実装が安定している：多くのアルゴリズムが長年運用され、実装ノウハウやハードウェア最適化も進んでいる。
通信速度が要求されるシナリオに最適：VPN、ディスク暗号、VoIPなど、リアルタイム性のある場面に向く。

課題：鍵配送の壁

最大の問題は安全な鍵共有が前提となる点です。すなわち、通信相手と事前に安全な方法で「同じ鍵」を持っておかないと通信が成立しません。これは、「鍵配送問題」と呼ばれ、共通鍵方式単独でのスケーラビリティや機動性に限界をもたらします。

代表的アルゴリズムとその評価

アルゴリズム	特徴	評価
AES	鍵長128/192/256bit、ブロック長128bit	現行標準。高速・安全
DES	鍵長56bit	鍵長が短く総当たり攻撃に脆弱。非推奨
3DES	DESを3回連続適用	緩和策だが効率が悪く非推奨

特に**AES（Advanced Encryption Standard）**は、米国NISTによる標準として選定され、現代の共通鍵暗号の基盤となっています。安全性・効率性ともに高く、多くのプロトコル（TLS、IPsec、SSH等）でデフォルト暗号方式として採用されています。

攻撃手法と対策の視点

共通鍵暗号に対する代表的な攻撃には以下が挙げられます：

ブルートフォース攻撃（総当たり）：鍵長が短い場合は完全な探索が可能（→DESはこの理由で淘汰）
辞書攻撃：鍵が推測しやすい場合に成立。パスフレーズ由来の鍵に注意。
サイドチャネル攻撃：アルゴリズム自体ではなく、実装レベルの弱点（タイミング差、電力消費）を突く

対策例：

鍵長の十分な確保（AES-128以上）
安全な鍵管理（HSMなどの導入）
実装レベルでのサイドチャネル対策（定数時間演算など）

3. 公開鍵暗号方式（非対称鍵暗号）

公開鍵暗号方式は、1976年にDiffieとHellmanによって概念が発表された画期的な暗号方式であり、「鍵配送問題」を根本から解決した技術です。**一対の鍵（公開鍵と秘密鍵）**を用いて暗号化・復号、または署名・検証を行うことで、安全な通信路を持たない相手とでも安全なやり取りが可能になります。

🔑 基本原理

公開鍵：誰にでも公開できる鍵。暗号化や署名検証に使用。
秘密鍵：所有者だけが持つべき鍵。復号や署名生成に使用。

公開鍵で暗号化されたデータは、対応する秘密鍵でしか復号できない。また、秘密鍵で署名されたデータは、対応する公開鍵でのみ正当性を検証できる。この非対称性により、認証・機密性・否認防止といったセキュリティ要件が達成される。

🔧 技術的基盤：数学的困難性

公開鍵暗号は、特定の数学問題が現実的時間内に解けないことを前提に安全性が成立している。以下は主要なアルゴリズムとその根拠：

アルゴリズム	数学的困難性	特徴
RSA	大きな整数の素因数分解	歴史が長い。鍵長は2048bit以上が推奨
DSA	離散対数問題	デジタル署名専用
ECC	楕円曲線上の離散対数問題	同等の安全性をより短い鍵長で実現

例：RSA-2048と同等の安全性を、ECCでは256bit程度で実現できる。これにより、IoTやスマートカードといったリソース制限環境でも実用性がある。

🔄 公開鍵暗号の用途と限界

用途：

機密通信（暗号化）
デジタル署名
鍵交換（ハイブリッド暗号における共通鍵の配送）

限界：

計算コストが高い（特にRSA）
暗号化対象サイズが小さい
- 例：RSAは鍵サイズより大きなデータは暗号化不可
- → 実際には「共通鍵を暗号化する用途」が主

💡 ハイブリッド暗号化の実例：TLSハンドシェイク

サーバが公開鍵付き証明書をクライアントに送信
クライアントが共通鍵を生成し、サーバの公開鍵で暗号化して送信
サーバが秘密鍵で復号し、共通鍵を取得
以降は共通鍵（例：AES）で通信

このように、公開鍵暗号で鍵共有 → 共通鍵暗号で本通信という使い分けが現代の標準である。

🚨 試験・実務の注意点

鍵長が安全性に直結（NIST推奨：RSAは2048bit以上）
RSAのPKCS#1 v1.5パディングは攻撃されやすい（→OAEP推奨）
証明書失効リスト（CRL）やOCSPで公開鍵の正当性確認が必要
TLSやS/MIMEなど、証明書ベースのプロトコルとの連携が理解必須

4. ハッシュ関数

一方向性：元データに戻せない（不可逆）
衝突耐性：異なる入力が同じ出力にならない（べき）
改ざん検出・署名・パスワード保存などに使用

代表的アルゴリズム：

アルゴリズム	出力長	状態
SHA-256	256bit	現行主流
SHA-1	160bit	衝突実証済 →非推奨
MD5	128bit	非推奨
SHA-3	可変	NIST推奨

5. デジタル署名

デジタル署名は、文書や通信内容に「送信者の身元と改ざんの有無」を付与する技術です。手書きのサインに相当する機能を、電子的に実現することで、**改ざん防止（整合性）と否認防止（本人性の証明）**を提供します。

🧩 署名の技術的構造

送信者はデータにハッシュ関数を適用し、**要約（ハッシュ値）**を得る
このハッシュ値を秘密鍵で暗号化し、デジタル署名とする
受信者は公開鍵で署名を復号し、再計算したハッシュと一致するか検証する

この仕組みにより、「このデータは誰が作成し、改ざんされていない」ことが検証可能になる。

✍️ 実用プロトコルでの活用

用途	説明
S/MIME、PGP	電子メールの署名・暗号化（本人性＋改ざん防止）
ソフトウェア配布	インストーラやアップデートの正当性確認（署名検証）
電子契約	法的効力をもった意思表明としての署名（e-文書法）

🔑 署名とPKI（公開鍵基盤）

署名の有効性は、「その公開鍵が本当に本人のものか？」に依存します。ここで活用されるのが**PKI（Public Key Infrastructure）**です。

証明書（X.509）：公開鍵に所有者の情報と署名を付けたもの
CA（認証局）：信頼された第三者として証明書を発行
失効管理：CRLやOCSPで鍵の無効化チェックを行う

🧨 実装リスクと攻撃手法

リスク	内容
ハッシュ衝突	MD5やSHA-1で異なる文書が同じハッシュ → 署名偽造
ハッシュ長のトリミング	一部の署名検証処理が出力の一部しか見ない実装バグ
署名再利用攻撃	正しい署名を別文書に転用（同じハッシュ値なら成立）

→ 対策としては、SHA-256以上の使用、検証コードの堅牢性確保、タイムスタンプの付与（改ざん時刻の証明）などが挙げられる。

📌 試験対策の観点

デジタル署名のフロー（ハッシュ → 秘密鍵暗号 → 公開鍵検証）
攻撃パターン（衝突、再利用、なりすまし）
PKI構造と運用管理（CA、CRL、OCSPの役割）
実務プロトコルでの使われ方（S/MIME、コード署名）

6. 鍵交換プロトコル

目的：通信前に共通鍵を安全に共有する（共通鍵暗号の前提）

代表的手法：

プロトコル	概要
Diffie-Hellman	公開値を元に共通鍵を合成（離散対数に依存）
ECDH	楕円曲線ベースのDH。軽量で近年主流。
Ephemeral DH	一時鍵を用いた前方秘匿性確保（PFS）

※MITM（中間者攻撃）への対策として、認証付きDH（例：TLSにおけるECDHE＋証明書）を併用する。

7. 暗号プロトコルの実装と運用

暗号技術は、アルゴリズムの理論的安全性だけでは不十分であり、実装や構成のミスが致命的なセキュリティホールを生む。TLSやIPsec、SSHといった暗号プロトコルは、その実装と設定次第で安全にも危険にもなる。

🔒 主な暗号プロトコル

プロトコル	用途	解説
TLS/SSL	Web通信の暗号化（HTTPS）	TLS1.3が現行。証明書＋鍵交換＋共通鍵で構成
IPsec	IP層での暗号化	VPNなどで利用。IKEで鍵交換を行う
SSH	リモート接続の暗号化	公開鍵認証やパスワード、チャレンジ方式対応

⚠️ 実装上の落とし穴

パディングの誤り：PKCS#7やPKCS#1の扱いミスによる復号エラー漏洩
IV再利用：ブロック暗号の初期化ベクトルが固定 → 既知平文攻撃
乱数の偏り：鍵やノンスの予測が可能に
旧バージョン対応：SSLv3やRC4など、安全性が失われたアルゴリズムが残存
証明書検証の不備：自己署名や失効済証明書を受け入れるケース

🛡 安全な運用のために

アルゴリズムの選定：AES、SHA-256、ECDHEなど推奨技術のみを採用
ライブラリの信頼性：OpenSSLやBoringSSLのセキュリティ情報を常に監視
設定ガイドライン遵守：Mozilla SSL Configuration Generatorなどを参考に
監査とログ管理：証明書期限切れ、異常ハンドシェイク、鍵交換失敗などを検知・記録

📌 試験対策の観点

プロトコルの構造（TLSのハンドシェイク、SSHの鍵交換など）
実装失敗パターンとその原因・影響
安全な構成・設定のベストプラクティス
鍵管理と証明書ライフサイクル

8. 暗号技術の最新動向

PQC（Post-Quantum Cryptography）
- RSAやECCが量子計算機で破られるリスクへの対応
- NISTがCRYSTALS-Kyber等を標準化選定中
ハイブリッド暗号
- 公開鍵方式＋共通鍵方式の組み合わせ
- TLSハンドシェイクではこの形式が主流
軽量暗号
- IoT向け（リソース制限下でも使える）
- 例：PRESENT, LEA, Simon/Speck

9. 試験対策ポイント

各暗号方式の特徴／用途／脆弱性
公開鍵と共通鍵の使い分け／併用パターン
鍵交換と証明書（PKI）との関係
TLSのプロトコル構造（ハンドシェイク → 共通鍵合意 → 通信）
実装上の失敗パターン（IV再利用、乱数不足、アルゴリズムの固定など）
輸出規制（Wassenaar Arrangement）や国内暗号利用指針（CRYPTREC）