暗号理論基礎 • 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. 基礎知識チェック

設問 - Level 1

暗号技術が実現する情報の4つの特性をすべて挙げてください。
共通鍵暗号方式と公開鍵暗号方式の最も大きな違いは何か？
共通鍵暗号方式における「鍵配送問題」とは具体的にどのような問題か？
公開鍵暗号方式で、データを暗号化する際に使用する鍵は公開鍵か秘密鍵か？
ハッシュ関数に求められる「一方向性」とは、どのような特性を指すか？
デジタル署名を作成する際、データのハッシュ値をどの鍵で暗号化するか？
現在の共通鍵暗号の標準として広く利用されているアルゴリズムは何か？
公開鍵暗号であるRSAの安全性の数学的根拠となっている問題は何か？
TLSハンドシェイクにおいて、最終的なデータ通信の暗号化に利用されるのは、共通鍵暗号と公開鍵暗号のどちらか？
デジタル署名によって保証される主要なセキュリティ要件を2つ挙げてください。

設問 - Level 2

セキュリティ対策は、リスクを完全にゼロにするまで講じるべきである。この考え方は正しいか？その理由も簡潔に述べよ。
AESはDESや3DESと比較して、なぜ現在の共通鍵暗号の標準として推奨されるのか？その理由を、それぞれのアルゴリズムの課題と関連付けて説明せよ。
公開鍵暗号であるECCが、IoTやスマートカードといったリソース制限のある環境で特に有利とされるのはなぜか？RSAと比較して説明せよ。
TLSハンドシェイクにおける「ハイブリッド暗号化」とは何か？その目的と具体的な流れを説明せよ。
ハッシュ関数に求められる「衝突耐性」とは何か？もしハッシュ関数が衝突耐性を持たない場合、デジタル署名にはどのような問題が生じる可能性があるか？
公開鍵基盤（PKI）において、認証局（CA）と証明書の役割は何か？デジタル署名の有効性を保証する上で、これらがどのように機能するかを簡潔に説明せよ。
暗号プロトコル実装における「IV（初期化ベクトル）の再利用」がなぜ危険とされるのか、具体的にどのような攻撃につながる可能性があるか説明せよ。
SSHなどのリモート接続プロトコルで、認証付きDH（Diffie-Hellman）鍵交換が中間者攻撃（MITM攻撃）に対して有効な対策となるのはなぜか？
「PQC（Post-Quantum Cryptography）」とは何か？なぜPQCの研究・標準化が緊急の課題となっているのか、その背景を説明せよ。
セキュリティ対策を講じる際、「アルゴリズムの選定」と「ライブラリの信頼性」はそれぞれどのような重要性を持つか？具体例を交えて説明せよ。

回答 - Level 1

機密性、完全性、認証、否認防止。
共通鍵暗号方式は暗号化と復号に同一の鍵を使用するが、公開鍵暗号方式は異なる鍵（公開鍵と秘密鍵）を使用する。
通信相手と安全な方法で事前に共通鍵を共有する必要があるという問題。
公開鍵。
ハッシュ値から元のデータを復元することができない（不可逆である）特性。
送信者の秘密鍵。
AES（Advanced Encryption Standard）。
大きな整数の素因数分解問題。
共通鍵暗号（例: AES）。
改ざん防止（完全性）と否認防止（本人性の証明）。

回答 - Level 2

誤り。リスクを完全にゼロにすることは現実的に不可能であり、費用対効果を考慮した上で許容可能なレベルまでリスクを低減する対策が重要となる。
DESは鍵長が短く総当たり攻撃に脆弱であるため淘汰された。3DESはDESを3回適用することで安全性を高めたが、効率が悪いという課題があった。AESは、より長く安全な鍵長（128/192/256bit）と高い処理性能を両立しているため、これらの課題を克服し現行の標準として推奨される。
ECCは、RSAと同等の安全性をより短い鍵長で実現できるため、計算リソースやメモリ容量が限られたIoTデバイスやスマートカードなどでも効率的に安全性を確保できる点で有利である。
ハイブリッド暗号化とは、公開鍵暗号と共通鍵暗号を組み合わせて利用する方式。公開鍵暗号の鍵配送の容易さと、共通鍵暗号の高速性を両立させる。具体的には、まず公開鍵暗号（サーバの公開鍵）を用いて安全に共通鍵を共有し、その後の実際のデータ通信は高速な共通鍵暗号で行う。
衝突耐性とは、異なる入力データから同じハッシュ値が生成されにくい特性。衝突耐性がない場合、攻撃者が元の文書と同じハッシュ値を持つ別の（不正な）文書を作成できる可能性がある。これにより、攻撃者が作成した不正な文書に対して、正規の署名を流用し、あたかも正規の文書であるかのように偽装する「署名偽造」が可能となる。
認証局（CA）は、公開鍵が正当な持ち主のものであることを保証する第三者機関。証明書（X.509）は、公開鍵に所有者情報とCAの署名を付与したもので、公開鍵の正当性を証明する。デジタル署名の有効性を検証する際、受信者は証明書内のCAの署名を検証することで、公開鍵が信頼できるものであることを確認し、その公開鍵で署名を検証する。
IVの再利用は、ブロック暗号のCBCモードなどで特に危険である。同じ鍵とIVで異なる平文を暗号化すると、暗号文の一部から平文の関係性が推測されたり、既知平文攻撃によって平文が特定されたりする可能性がある。これにより、機密性が損なわれる恐れがある。
認証付きDH鍵交換では、DH鍵交換で共有された共通鍵に加えて、サーバ証明書などを用いて通信相手（サーバ）が正当な相手であることを認証する。これにより、中間者攻撃者がDH鍵交換に割り込んで偽の鍵を共有しようとしても、その認証情報が偽物であることが露見するため、MITM攻撃を防ぐことができる。
PQCは「耐量子計算機暗号」とも呼ばれ、量子コンピュータが実用化された場合でも安全性を維持できる暗号技術を指す。現在の主要な公開鍵暗号（RSAやECCなど）は、ショアのアルゴリズムなどの量子アルゴリズムによって効率的に解読される可能性があるため、将来的な量子コンピュータの脅威に備え、PQCの研究・標準化が緊急の課題となっている。

アルゴリズムの選定: 脆弱性が発見されているDESやSHA-1のような古いアルゴリズムではなく、AES-256やSHA-3のような、現在安全とされているアルゴリズムを選ぶことが重要。これにより、理論的な安全性基盤を確保する。
ライブラリの信頼性: 暗号アルゴリズム自体は安全でも、実装するライブラリにバグや設計ミスがあれば脆弱性が生じる。OpenSSLやBoringSSLなど、広く利用され、セキュリティレビューが頻繁に行われている信頼性の高いライブラリを選び、常に最新の状態に保つことで、実装レベルでの脆弱性を低減できる。