この記事は、 CAMPFIRE Advent Calendar 2025 の6日目の記事 の一部です。連載記事の全体は、「第0回 暗号技術の基礎を学ぶ連載記事一覧」を参照してください。
前回は暗号技術の基礎として、暗号技術の目的、暗号技術の分類、安全性モデルについて見てきました。今回は共通鍵暗号に焦点を当てます。
HTTPSでのWebアクセス、メールの暗号化、VPN通信などで共通鍵暗号が使われ、やり取りされるデータを保護しています。共通鍵暗号は大きなメッセージやデータの暗号化に利用されており、通信でやり取りされるデータだけでなく、ストレージの暗号化などの目的でも利用されています。
今回は、こうした多くの場面で利用されている共通鍵暗号について見ていきます。
※この記事は、文章案の作成や表現の調整、内容の検証や修正のサポート等に生成AIを利用しています。
目次
2.1 共通鍵暗号の概要
2.2 ストリーム暗号とブロック暗号
2.3 DESとAESの概要
2.4 暗号モードの概要
2.5 暗号の安全性と鍵管理
2.6 現実世界での応用例
2.7 まとめ
2.1 共通鍵暗号の概要
共通鍵暗号とは
共通鍵暗号は、データの暗号化において多くの場面で利用されている暗号技術です。最大の特徴は「暗号化と復号で同じ鍵を使う」ことです。この性質から、共通鍵暗号は対称鍵暗号とも呼ばれます。
共通鍵暗号の強みは高速な処理です。現代のコンピュータでAES-256を実行すると、1秒間に数GBのデータを処理できます。ビット演算を中心とした設計により、CPUやハードウェアが直接サポートしやすく、公開鍵暗号の数百倍から数千倍の速度となるため、大容量データの暗号化に向いています。
一方で、この技術には大きな課題があります。それが鍵配布問題です。
通信相手と秘密のメッセージをやり取りするには、まず同じ鍵を安全に共有する必要があります。現代ではこの問題を主に3つの方法で解決しています。公開鍵暗号による鍵交換(Diffie-Hellman鍵交換など)、物理的な鍵配布(安全な経路での事前配布)、PKI(公開鍵基盤)による信頼できる第三者機関の活用です。特にインターネット通信では、公開鍵暗号を使った鍵交換が使われています。
2.2 ストリーム暗号とブロック暗号
共通鍵暗号には、データの処理方法によってストリーム暗号とブロック暗号の2つのアプローチがあります。
ストリーム暗号は「流れるように、リアルタイムで」、ブロック暗号は「ブロック単位で確実に」データを処理します。
ストリーム暗号
ストリーム暗号は、データを1ビットまたは1バイト単位で暗号化します。データが到着した瞬間に即座に暗号化できます。
\begin{align}
\text{平文(ビット/バイト列)}&: P_1\ \ P_2\ \ P_3\ \ P_4\ \ P_5\ \ P_6\ \dots \\
\text{鍵ストリーム(ビット/バイト列)}&: K_1\ \ K_2\ \ K_3\ \ K_4\ \ K_5\ \ K_6\ \dots \\
\text{暗号文(ビット/バイト列)}&: C_1\ \ C_2\ \ C_3\ \ C_4\ \ C_5\ \ C_6\ \dots
\end{align}
アルゴリズム定義
暗号化アルゴリズム
- 入力: 平文ビット列 $m_1, m_2, \dots, m_n$、秘密鍵 $k$
- 出力: 暗号文ビット列 $c_1, c_2, \dots, c_n$
-
動作:
- 鍵 $k$ から鍵ストリーム $k_1, k_2, \dots, k_n$ を生成
- 各ビットを XOR: $c_i = m_i \oplus k_i$
復号アルゴリズム
- 入力: 暗号文ビット列 $c_1, c_2, \dots, c_n$、秘密鍵 $k$
- 出力: 平文ビット列 $m_1, m_2, \dots, m_n$
-
動作:
- 鍵 $k$ から同じ鍵ストリーム $k_1, k_2, \dots, k_n$ を生成
- 各ビットを XOR: $m_i = c_i \oplus k_i = (m_i \oplus k_i) \oplus k_i$
ストリーム暗号の強み
ストリーム暗号の強みはリアルタイム性です。データが到着した瞬間に暗号化できるため、バッファリングが不要で処理遅延を最小化できます。動画配信や音声通話のような、遅延が許されないアプリケーションに向いています。また、大きなブロックを保持する必要がないためメモリ効率も良く、実装も比較的シンプルであることが多い暗号技術です。
具体的なストリーム暗号
具体的なストリーム暗号の例として、RC4、ChaCha20、KCipher-2を紹介します。
RC4
RC4 は1990年代から2000年代にかけて、SSL/TLSで広く使用されていたストリーム暗号でした。シンプルさと高速性から、多くのシステムで採用されました。しかし、2000年代に入って脆弱性が次々と発見され、現在では使用が推奨されていません。無線LANで利用されていたWEPもRC4を利用していたため、置き換えが進みました。
ChaCha20
RC4の後継として登場したのがChaCha20です。GoogleのDaniel J. Bernsteinによって設計され、現在ではGoogle ChromeやOpenSSHなど、多くのモダンなシステムで採用されています。ChaCha20の特徴は、ソフトウェア実装でも非常に高速で、かつ高い安全性を提供することです。
KCipher-2
2007年に九州大学とKDDI研究所から発表されたストリーム暗号アルゴリズムが KCipher-2 です。2012年に国際標準化されており、マシンパワーの低いモバイルデバイス向けなどの用途が期待されています。
攻撃手法と対策
ストリーム暗号に対する攻撃手法は、主にブルートフォース(全数探索)、鍵ストリームの再利用、鍵ストリーム生成器の弱点を突くものに大別されます。
ブルートフォース攻撃(Brute Force Attack)
最も基本的な攻撃手法が、ブルートフォース攻撃です(この後に紹介するブロック暗号でも同じです)。攻撃者は全ての可能な鍵を順次試行し、正しい鍵を見つけ出すまで続けます。この攻撃の複雑度は鍵長に指数的に依存し、鍵長が $n$ ビットの場合、最大 $2^n$ 回の試行が必要です。
現代のコンピュータの能力を考慮すると、128ビット以上の鍵長が推奨されます。
鍵ストリーム再利用攻撃(Stream Reuse Attack)
最も危険な攻撃手法の一つが鍵ストリームの再利用です。同じ鍵ストリーム $k_1, k_2, \ldots, k_n$ で異なる平文 $m_1$ と $m_2$ を暗号化すると、暗号文は $c_1 = m_1 \oplus k$ と $c_2 = m_2 \oplus k$ となります。この時、攻撃者が両方の暗号文を入手できれば、
$$
C_1 \oplus C_2 = (P_1 \oplus K) \oplus (P_2 \oplus K) = P_1 \oplus P_2
$$
となり、平文の差分が直接露出してしまいます。
この攻撃を防ぐためには、一意なnonce(Number used once、一度だけ使われる数)やIV(Initialization Vector) を使用して、同じ鍵でも異なる鍵ストリームを生成する必要があります。重要なのは、同じ鍵とnonceのペアを二度と再利用しないことです。nonceは予測可能でも構いませんが、各暗号化に対して一意でなければなりません。また、鍵の適切な管理と更新も重要です。
統計的攻撃(Statistical Attack)
鍵ストリーム生成器が真の乱数ではなく擬似乱数生成器である場合、生成される鍵ストリームに統計的な偏りが生じる可能性があります。攻撃者は大量の暗号文を収集し、その統計的性質を分析することで鍵ストリームの予測を試みます。
この攻撃に対する対策として、暗号学的に安全な擬似乱数生成器(CSPRNG) の使用が不可欠です。CSPRNGは、出力の統計的性質が真の乱数と区別できないことを保証します。
ブロック暗号
ブロック暗号は、固定長のブロック(通常128ビット)単位でデータを暗号化します。データを一定のサイズに分割して確実に処理していく方式です。
\begin{align}
\text{平文(ブロックごと)}&: |\ P_1\ |\ \ P_2\ | \ P_3\ |\ \dots\ | \\
\text{暗号化処理(ブロックごと)}&: |\ E_1\ |\ E_2\ |\ E_3\ |\ \dots\ | \\
\text{暗号文(ブロックごと)}&: |\ C_1\ |\ C_2\ |\ C_3\ |\ \dots\ |
\end{align}
アルゴリズム定義
暗号化アルゴリズム
- 入力: 平文ブロック $P$(固定長)、秘密鍵 $K$
- 出力: 暗号文ブロック $C$(同じ固定長)
-
動作:
- 平文ブロック $P$ に対して鍵 $K$ を使用した複雑な置換・転置処理
- $C = E_K(P)$($E_K$ は鍵 $K$ による暗号化関数)
復号アルゴリズム
- 入力: 暗号文ブロック $C$、秘密鍵 $K$
- 出力: 平文ブロック $P$
-
動作:
- 暗号文ブロック $C$ に対して鍵 $K$ を使用した逆変換処理
- $P = D_K(C)$($D_K$ は鍵 $K$ による復号関数)
ブロック暗号の強み
ブロック暗号の強みは確実性と汎用性です。固定長のブロックで処理するため、各ブロックに対して同じ強度の暗号化を適用でき、様々な暗号モードと組み合わせられます。AESをはじめ、多くの標準暗号がブロック暗号として設計されています。
有名なブロック暗号:DESとAES
DES(Data Encryption Standard) は1977年に標準化された最初の民間向けブロック暗号でした。64ビットブロック、56ビット鍵という仕様で、当時としては画期的な技術でした。しかし、コンピュータ技術の進歩により、56ビット鍵は次第に脆弱になっていきました。
DESの後継として2001年に標準化されたのがAES(Advanced Encryption Standard) です。128ビットブロック、128/192/256ビット鍵という仕様で、現代の計算能力に対しても十分な安全性を提供しています。AESは現在、世界中で最も広く使用されている暗号アルゴリズムの一つです。
攻撃手法と対策
ブロック暗号に対する攻撃手法は、数学的な理論攻撃と物理的な実装攻撃に分類されます。これらの攻撃は、暗号アルゴリズムの設計段階と実装段階の両方で考慮する必要があります。
ブルートフォース攻撃
ストリーム暗号と同等の攻撃をブロック暗号でも適用する攻撃手法です。詳細はストリーム暗号のセクションを参照してください。
ショートカット攻撃(Shortcut Attack)
ショートカット攻撃は、暗号アルゴリズムの数学的構造や設計上の弱点を利用して、ブルートフォース攻撃よりも効率的に鍵を破る攻撃手法の総称です。この攻撃では、暗号アルゴリズムの内部構造を詳細に分析し、鍵の取りうる値の範囲を効率的に絞り込むことで、計算量を大幅に削減します。
ショートカット攻撃の例として、差分解読法や、線形解読法があります。
差分解読法(Differential Cryptanalysis)
差分解読法は、BihamとShamirによって1990年に発見されたブロック暗号に対する攻撃手法です。この攻撃では、特定の差分を持つ平文ペアを選択し、対応する暗号文の差分パターンを分析することで、鍵の部分的な情報を取得します。
実は1970年時点でDESのもととなる暗号技術で耐性があるように設計されていたため、DESではブルートフォース攻撃より効率的な解読はできません。また、1990年に発見されて以降はAESを含め、ブロック暗号ではこの攻撃への耐性があるように設計されています。
線形解読法(Linear Cryptanalysis)
線形解読法は、松井氏によって1993年に発表された攻撃手法です。この攻撃では、ブロック暗号で利用されるS-boxと呼ばれる非線形変換に対して線形近似を見つけ出し、その近似式の成立確率を利用して鍵の情報を取得します。そのためS-boxが線形変換に近似できない(線形変換からできる限り遠い)ように設計することが重要です。
サイドチャネル攻撃(Side-Channel Attack)
サイドチャネル攻撃は、暗号アルゴリズムの実装時に発生する物理的な情報漏洩を利用する攻撃です。暗号処理時の電力消費、処理時間、電磁波漏洩、キャッシュアクセスパターンなどが攻撃の対象となります。
電力解析攻撃(Power Analysis)では、暗号処理時の電力消費パターンを分析することで、内部処理の情報を取得します。単純電力解析(SPA)と差分電力解析(DPA)の2種類があり、特にDPAは統計的手法を用いて微弱な電力変動から鍵情報を抽出します。
タイミング攻撃(Timing Attack)では、暗号処理の実行時間の違いを利用します。条件分岐やキャッシュヒット・ミスによる処理時間の変動から、内部状態や鍵の情報を推測します。
これらの攻撃に対する対策として、定時間実装、電力解析対策、電磁波シールド、キャッシュ無効化などが重要です。また、実装段階でのセキュリティ評価も不可欠です。
タイムメモリトレードオフ手法(Time-Memory Trade-off Attack)
タイムメモリトレードオフ手法は、Hellmanによって1980年に提案された攻撃手法で、時間とメモリのトレードオフを利用して暗号攻撃の効率を向上させる手法です。この手法は、事前計算によるメモリ使用量の増加と引き換えに、実行時の計算時間を大幅に短縮します。
具体的な例としてHellmanのタイムメモリトレードオフ攻撃や、Rainbow Table攻撃があります。
ブロック暗号の理論的保証の限界
これらの攻撃をすべて防げば、ブロック暗号は完全に安全になるのでしょうか?
現代のブロック暗号(AESなど)は、現在知られている攻撃手法に対して高い安全性を提供していますが、理論的に完全な安全性を保証することは不可能です。
そのため、理論的な面で破られていないかだけでなく、どの程度今後も安全と言えるかということ、つまり「どの程度、安全性に対して余裕を持たせられているか?」ということを考える必要があります。
セキュリティマージン(Security Margin) とは、暗号アルゴリズムの設計において、理論的な攻撃手法に対してどれだけの余裕を持って設計されているかを示す指標です。
セキュリティマージンは、以下の式で表現されます。
$$セキュリティマージン=仕様のラウンド数−攻撃で破れるラウンド数$$
ラウンド数を増やすことは、暗号処理でどの程度情報を混ぜたり、非線形性(予測しづらい変換)を暗号結果全体に広げることへつながり、攻撃者がより予測しにくくなります。このようなことから、現在攻撃で敗れるラウンド数よりどれだけ仕様上のラウンド数が大きいかが、安全性に対する余裕を示す尺度の1つとなっています。
理論的保証の限界と実用的対応
ブロック暗号には、未知の攻撃手法の発見可能性、計算量的困難性の仮定への依存、実装とアルゴリズムの分離といった理論的限界があります。そのため、現代の暗号では理論的な完璧さではなく、実用的な安全性を追求します。AESのような標準暗号は、十分なセキュリティマージンを持ち、定期的な安全性評価と更新によって安全性を提供しています。
比較とまとめ
| 項目 | ストリーム暗号 | ブロック暗号 |
|---|---|---|
| 処理単位 | 1ビット〜1バイト | 固定ブロック(通常128ビット) |
| 遅延 | 低遅延 | ブロック単位での遅延 |
| 用途 | リアルタイム通信 | ファイル暗号化、多様な用途 |
| 実装 | 比較的シンプル | 暗号モードの選択が重要 |
2.3 DESとAESの概要
1970年代に誕生したDESは画期的な技術でしたが、コンピュータの計算能力の向上により安全性が脅かされるようになりました。2001年のAES標準化により、現代ブロック暗号はAESへと移行していきます。
DES(Data Encryption Standard)
DESは1977年にNISTによって標準化された最初の民間向けブロック暗号です。
仕様
- ブロック長: 64ビット
- 鍵長: 56ビット(実質)※ 64ビット鍵のうち8ビットはパリティビット
- ラウンド数: 16ラウンド
DESの構造
DESはFeistel構造と呼ばれる設計パターンを採用しています。
各ラウンドでは、ブロックを左右32ビットずつに分割し、右半分に複雑な変換を施してから左半分とXORを取る操作を繰り返します。
Feistel構造は、Horst Feistelが1970年代に考案した暗号設計手法です。暗号化と復号が同じアルゴリズムで実現できるのが特徴で、DESの他にも多くのブロック暗号(Camellia、MISTY1、SEEDなど)で採用されています。
Feistel構造では、各ラウンドで以下の処理を行います。
- ブロック分割: 64ビットのブロックを左右32ビットずつに分割($L_i$, $R_i$)
- 右半分の処理: 右半分$R_i$をラウンド関数$f$で処理
- XOR演算: 処理結果と左半分$L_i$をXOR
- 左右交換: 次のラウンドのために左右を交換
$i$番目のラウンドの処理は以下のように表されます。
\begin{align}
&L_i = R_{i-1} \\
&R_i = L_{i-1} \oplus f(k_i, R_{i-1}) \\
\\
&L_i, R_i:i番目ラウンドの左右32ビット \\
&k_i:i番目ラウンドの部分鍵 \\
&f:ラウンド関数
\end{align}
DESのラウンド関数$f$ は以下の処理から構成されます。
- 拡張置換(E-box): 32ビットを48ビットに拡張
- 鍵加算: 48ビットの部分鍵とのXOR
- S-box置換: 8個のS-boxによる6ビットから4ビットへの変換
- P-box置換: 32ビットの置換
Feistel構造の強み
暗号化と復号で同じアルゴリズムを使えるため、実装コストを削減できます。設計時はラウンド関数Fの設計に集中でき、十分なラウンド数により高い安全性を実現します。ハードウェア・ソフトウェア両方で効率的に実装可能です。
また、Feistel構造の優れた点は、復号時も同じアルゴリズムを逆順で適用するだけで動きます。この構造により、DESは実装コストを大幅に削減できます。
DESの問題点
DESには、現代利用するには問題があります。鍵長とブロック長の不足です。
鍵長は56ビットであり、現在のコンピュータでは数時間でブルートフォース攻撃が可能となっています。また、ブロック長は64ビットであり、一部の攻撃に対して脆弱であることが知られています。
DESの根本的問題と対策
DESの根本的な問題は、鍵長の不足と設計時代の制約にあります。鍵長の問題については、トリプルDESといった「DESを複数回繰り返すことで安全性を高める」手法や、DESXといった鍵長を増やす手法が考えられました。しかしながら、どちらもDESそのものの構造上の問題は解決していません。また性能や安全性において、暗号技術として最適化されているとは言えません。
DESについては上記以外にも、NSA(米国家安全保障局: 米国で諜報を行う組織)が関与したことにより、アルゴリズムとしては強化されたことがわかっているものの、鍵長についてはIBMで設計されていたときよりも短くされた経緯があります。これは「NSAの意向による『解読のしやすさ』のため」だったと言われています。こうした状況から、DESについては、現在まで見つかっていないものの、NSAによる構造へのバックエンド(裏口)が設けられた可能性を疑う声もありました。
次セクションで見ていくAESでは、DESの教訓を活かし、十分な鍵長と現代の各攻撃手法に対する対策を組み込んで設計されています。
AES(Advanced Encryption Standard)
DESの後継として、2001年にNISTによって標準化されたのがAESです。アルゴリズムの正式名称はRijndael(ラインダール)といいます。
仕様
- ブロック長: 128ビット
- 鍵長: 128ビット、192ビット、256ビットから選択
- ラウンド数: 鍵長に応じて10/12/14ラウンド
AESの構造
AESは SPN構造(Substitution-Permutation Network) を採用しています。
各ラウンドでは、以下の処理を行います。
- SubBytes: S-boxによる非線形変換
- ShiftRows: 行のシフト操作
- MixColumns: 列の混合操作(最終ラウンドでは省略)
- AddRoundKey: ラウンド鍵と内部状態のXOR
SPN構造(Substitution-Permutation Network)は、置換処理(Substitution)と転置処理(Permutation)を交互に繰り返すことで高い安全性を実現する暗号設計手法です。Feistel構造とは異なるアプローチで、AESなどの現代的なブロック暗号で採用されています。
SPN構造の強み
置換と転置の組み合わせにより、1ビットの変化が全体に急速に拡散します。また、各処理が独立して実行できるため並列処理が可能で、各処理の役割が明確なため数学的に安全性を証明しやすい構造です。
Feistel構造との比較
| 項目 | Feistel構造 | SPN構造 |
|---|---|---|
| 暗号化・復号 | 同じアルゴリズム | 異なるアルゴリズム |
| 拡散性 | 段階的 | 高速 |
| 並列性 | 制限的 | 高い |
| 設計 | ラウンド関数に集中 | 各処理を独立設計 |
| 実装 | ハードウェアに有利 | ソフトウェアに有利 |
AESでのSPN構造の実装
AESでは、SPN構造を以下のように実装しています。
- 置換層: SubBytes(S-box置換)
- 転置層: ShiftRows + MixColumns(行シフト + 列混合)
- 鍵加算層: AddRoundKey(ラウンド鍵と内部状態のXOR)
この構造により、AESは高い安全性と効率的な実装を両立しています。
AESの優位性
AES-256では事実上ブルートフォース攻撃が不可能で、ハードウェア・ソフトウェア両方で高速実装が可能です。128/192/256ビットの3つの鍵長から用途に応じて選択でき、世界中で採用されている標準暗号として高い信頼性を持っています。
攻撃手法と安全性
AESは、DESの教訓を活かして設計された現代の標準暗号であり、現在知られている攻撃手法に対して高い安全性を提供しています。しかし、理論的な攻撃手法と安全性について理解することは重要です。
AESの鍵長は128ビット、192ビット、256ビットから選択可能であり、現在の技術ではブルートフォース攻撃は実現不可能です。AES-128の場合、鍵空間は $2^{128} \approx 3.4 \times 10^{38}$ 通りとなります。さらに、AES-256の場合、鍵空間は $2^{256} \approx 1.2 \times 10^{77}$ 通りとなり、物理的に不可能な計算量となります。このため、十分な鍵長の選択により、ブルートフォース攻撃に対する安全性が確保されています。
また、AESは設計段階で差分解読法や線形解読法を考慮しており、攻撃は非常に困難です。
DESからAESへの移行
| 項目 | DES | AES |
|---|---|---|
| 標準化年 | 1977年 | 2001年 |
| ブロック長 | 64ビット | 128ビット |
| 鍵長 | 56ビット | 128/192/256ビット |
| 構造 | Feistel | SPN |
| 現在の状況 | 非推奨 | 現行標準 |
| 主な用途 | レガシーシステム | あらゆる用途 |
この移行により、現代の高い計算能力に対しても十分な安全性を持つ暗号システムが実現されました。
2.4 暗号モードの概要
ブロック暗号を実際に使用する際、単一のブロック暗号だけでは複数のブロックを安全に暗号化できません。そこで重要になるのが暗号モードです。
なぜ暗号モードが必要なのか
AESなどのブロック暗号は、同じ平文ブロックに対して常に同じ暗号文ブロックを生成します。この性質により、攻撃者がパターンから情報を推測できてしまいます。
平文1: "Hello World!!!!!" → 暗号文1: "A1B2C3D4E5F6G7H8"
平文2: "Hello World!!!!!" → 暗号文2: "A1B2C3D4E5F6G7H8" (同じ!)
画像ファイルを暗号化した場合、同じ色の部分が同じ暗号文になり、元の画像の輪郭が透けて見えてしまいます。暗号モードは、この問題を解決するための手法です。


引用元 https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
著作権者 左: Larry Ewing(lewing@isc.tamu.edu) and The GIMP , 右: Larry Ewing and User:Lunkwill
主要な暗号モード
1. ECB(Electronic Codebook)モード
最もシンプルなモードですが、実用では使用すべきではありません。
このモードの問題として、同じ平文ブロックが常に同じ暗号文ブロックになるため、ブロック単位でのパターンが見え、平文の統計的性質が暗号文に反映される点があります。
2. CBC(Cipher Block Chaining)モード
前のブロックの暗号文を次のブロックの暗号化に使用するモードです。
前のブロックの暗号文が後のブロックに影響する連鎖効果により、ECBの問題を解決します。初期化ベクトル(IV)でランダムな値を使い、最初のブロックを初期化します。前のブロックの結果が必要なため順次処理となり、並列化は困難です。1ビットの誤りが2ブロックに影響するエラー伝播の問題がありますが、広く採用されている実績があります。
3. CTR(Counter)モード
カウンタ値を暗号化してストリーム暗号として使用するモードです。
各ブロックが独立して処理できるため並列処理が可能で、高速です。任意の位置から復号でき、エラー伝播もなく、パディングも不要です。ブロック暗号をストリーム暗号として利用します。
注意点として、カウンタ値と鍵の組み合わせを絶対に再利用してはいけません。同じ鍵で異なるメッセージを暗号化する場合、カウンタの管理が重要です。
4. GCM(Galois/Counter Mode)モード
暗号化と認証を同時に提供 する AEAD(Authenticated Encryption with Associated Data) モードです。
GCMモードは、CTRモードによる暗号化と、GHASHと呼ばれる認証関数を組み合わせたモードです。GHASHは、Galois(ガロア)体$GF(2^{128})$上の演算を用いてメッセージ認証コード(メッセージ認証コードの詳細は第3回参照)を生成します。Galois体は有限体の一種で、暗号技術において高速な演算を実現するための数学的構造です。GHASHは、暗号文と関連データ(AAD)を入力として受け取り、認証タグを生成することで、データの改ざん検出を可能にします。
暗号化と同時にメッセージ認証も実現し、機密性と完全性の両方を提供します。ハードウェア実装で非常に高速で、Galois体演算の並列処理が可能です。暗号化しないが認証したいデータ(関連データ)も保護できます。TLS 1.3などモダンなプロトコルで標準採用されており、ネットワーク通信に最適です。
暗号モードの比較
| モード | 安全性 | 並列化 | エラー伝播 | 用途 |
|---|---|---|---|---|
| ECB | ❌ 低い | ✅️ 可能 | ✅️ なし | ❌ 使用禁止 |
| CBC | ✅️ 高い | ❌ 不可 | ❌ あり | ✅️ ファイル暗号化 |
| CTR | ✅️ 高い | ✅️ 可能 | ✅️ なし | ✅️ 高速通信 |
| GCM | ✅️ 最高 | ✅️ 可能 | ✅️ なし | ✅️ TLS通信 |
2.5 暗号の安全性と鍵管理
暗号技術の安全性は、アルゴリズムの設計だけでなく、鍵管理の質によって大きく左右されます。どのような暗号アルゴリズムでも、鍵の管理が重要になります。
鍵長と安全性の関係
暗号の安全性は主に鍵長によって決まります。鍵長が長いほど、ブルートフォース攻撃(全ての鍵を試す攻撃)に必要な計算量が指数的に増加します。これは数学的に保証された事実です。
計算量の比較
| 鍵長 | 可能な鍵の数 | ブルートフォース攻撃時間(仮定) |
|---|---|---|
| 56ビット(DES) | $2^{56} \approx 7.2 \times 10^{16}$ | 数時間〜数日 |
| 128ビット(AES-128) | $2^{128} \approx 3.4 \times 10^{38}$ | 宇宙の寿命より長い |
| 256ビット(AES-256) | $2^{256} \approx 1.2 \times 10^{77}$ | 物理的に不可能 |
なぜDESが危険になったのか
1977年のDES制定時、56ビット鍵は十分安全とされていました。しかし、現在ではその安全性は不十分であり、容易に攻撃を許してしまうものとなっています。
- コンピュータ性能の向上: コンピュータの処理能力が飛躍的に向上
- 専用ハードウェア: 1998年にEFF(Electronic Frontier Foundation)がDES Crackerを製作し、22時間でDES鍵を破った
- クラウドコンピューティング: 現在では数時間、低コストでDESを破ることが可能
鍵管理の重要性
どんなに強力な暗号アルゴリズムを使用しても、鍵管理が不適切であれば安全性は保たれません。
鍵管理のライフサイクル
鍵生成では、暗号学的に安全な擬似乱数生成器(CSPRNG) を使用し、十分な不確実性(エントロピー)を持つ鍵を生成します。ハードウェア乱数生成器やOS提供の乱数機能を活用します。また、鍵長(セキュリティパラメータ) を適切に設定することで、効率性と安全性のバランスを決定する必要があります。
鍵の保管には、鍵の階層化(鍵を別の鍵で暗号化し、階層的にする)、分散管理(一定以上の数を集めなければ鍵を復元できないようにして分散して管理)、システムから切り離した場所(ICカード等)での管理などがあります。これらは鍵をそのまま保管するより安全ですが、デメリットも存在します。鍵の階層化はマスタ鍵と呼ばれる最上位の鍵の管理が問題になります。また、分散管理は複数の箇所に保管された情報が必要となります。また、ICカード等は物理的に盗難される、ICカードから秘密鍵の情報を抜き取られるなどの可能性もあります。
鍵配布については、暗号化通信とは別の安全な経路、Diffie-Hellman鍵交換などの鍵交換プロトコル、または公開鍵暗号基盤(PKI) を活用して配布します。
鍵使用の際には、必要最小限の範囲 でのみ鍵を使用し(最小権限原則)、同一の鍵の過度な使用を避けます。
鍵は長期間同じものを使い続けることなく定期更新を行い、鍵漏洩の疑いがある場合は即座に緊急更新します。
最後に、不要になった鍵はメモリやストレージから完全に削除し、機密データの痕跡を残さないようします。鍵消去用のコマンドの実行や鍵のビットパターンの検索と消去を実施します。
モード選択がセキュリティに与える影響
暗号モードの選択は、セキュリティに直接影響します。ECBモードは同じ平文ブロックが常に同じ暗号文ブロックになるため、パターンが露出し統計的攻撃が可能になります。実用では絶対に使用すべきではありません。
一方、GCMモードは暗号化と認証を同時に実現し、改ざん検出機能も備えているため、現代の通信プロトコルで標準採用されています。用途に応じて、ファイル暗号化ではCBCモード(完全性は別途MAC)、高速通信ではCTRモード(完全性は別途MAC)、TLS通信ではGCMモード(暗号化と認証を同時実現)を選択します。
2.6 現実世界での応用例
共通鍵暗号は、私たちの身の回りの多くの技術で実際に活用されています。具体的な応用例を見ていきましょう。
TLS通信におけるAES-GCM
TLS(Transport Layer Security) は、HTTPSやその他の安全な通信プロトコルの基盤となる技術です。
TLS 1.3での暗号化フロー
大量のWebトラフィックを効率的に処理できる高速性、データの改ざんを検出できる認証機能等の理由からAES-GCMが選ばれています。Webブラウジング時のHTTPS通信、APIサーバとの通信、モバイルアプリの通信などで広く使われています。
VPNとディスク暗号化
VPN(Virtual Private Network)
VPNでは、インターネット上に安全なトンネルを構築するために共通鍵暗号が使用されます。
代表的なVPNプロトコル
- OpenVPN: AES-CBC、AES-GCMなど
- IPsec: AES-CTR + HMAC-SHA256
- WireGuard: ChaCha20-Poly1305
ディスク暗号化
ストレージ全体の暗号化では、特殊な暗号モードが使用されます。
XTS-AES(XEX-based tweaked-codebook mode with ciphertext stealing)
- セクタベース: ディスクのセクタ単位で暗号化
- 並列処理: 高速なランダムアクセスが可能
- 改ざん検出: セクタ改ざんに対する一定の保護
実装例
- BitLocker(Windows): AES-XTS
- FileVault(Mac OS): AES-XTS
- LUKS(Linux): AES-XTS
- Android暗号化: AES-256-XTS
無線LAN(Wi-Fi)のセキュリティ
WPA2のCCMP
CCMP(Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) は、実質的にAES-CCMモードの実装です。
CCMPの特徴
- AESベース: 128ビットAESを使用
- CTR暗号化: データ部分の暗号化
- CBC-MAC: メッセージ認証コード付与
なお、WPA3では、より強力な暗号化として、AES-256とSAE(Simultaneous Authentication of Equals)が導入されています。
IoTデバイスでの軽量暗号
IoT(Internet of Things) デバイスでは、限られた計算資源での暗号化が求められます。
軽量ブロック暗号の例
- AES-128: 比較的軽量で広く対応
- ChaCha20: ソフトウェア実装で高速
- PRESENT: 非常に軽量(64ビットブロック)
クラウドストレージの暗号化
クラウドサービスでは、大規模なデータ暗号化が必要です。
Amazon S3の暗号化例
Amazon S3では、サーバサイドでの暗号化(SSE) とクライアントサイドでの暗号化(CSE) があります。SSEには、SSE-S3とSSE-KMSなどがあり、SSE-S3はAES-256による暗号化機能で、透過的な暗号化・復号が特徴です。SSE-KMSはAWS KMSが鍵を管理することが特徴で、鍵管理の柔軟性や追跡性の高さが特徴になります。CSEでもAWS KMSを利用した鍵管理が可能ですが、SSEと異なり、暗号化・復号処理はクライアントサイドの責務となります。
Google Cloudの暗号化
Google Cloud では、デフォルトで保存データに対する暗号化としてAES-256(GCM)が利用されます。一方で、詳細な制御のため、多層的な鍵管理を実現するエンベロープ暗号化も提供されています。
2.7 まとめ
今回は共通鍵暗号について、その基本概念から実世界での応用まで見てきました。
共通鍵暗号は暗号化と復号に同じ鍵を使用し、圧倒的な高速性が特徴です。一方で鍵配布問題という課題があり、現代では公開鍵暗号と組み合わせて解決しています。
ストリーム暗号は逐次処理で低遅延、ブロック暗号は固定ブロック処理で汎用性が高く、用途に応じて使い分けます。ブロック暗号であるDESは56ビット鍵の限界により現在は安全性が不足しており、AESが主に利用されています。
暗号モードは、ECB(使用禁止)、CBC(従来の標準)、CTR(並列処理可能)、GCM(暗号化+認証)があり、現代ではGCMが最適解とされています。適切な鍵管理と暗号モードの選択が、安全性を実現します。
TLS通信、VPN、ディスク暗号化、無線LANなど、共通鍵暗号は現代のディジタルインフラで広く活用されています。
共通鍵暗号は公開鍵暗号とともによく知られている機密性を担保する暗号技術の一つかと思いますが、その背景にある理論や安全性に対する理解を深められたかと思います。
次回:完全性と認証
次回は「第3回 ハッシュ関数とメッセージ認証コード(MAC)」です。今回の共通鍵暗号が「機密性」を担当するのに対し、次回は「完全性」と「認証」を扱います。
参考文献
書籍
- 暗号技術のすべて(IPUSIRON 著 | 翔泳社)
- 安全な暗号をどう実装するか 暗号技術の新設計思想(Jean-Philippe Aumasson 著、Smoky 翻訳、IPUSIRON、 藤田亮 監訳 | マイナビ出版)
Web
- RFC 6071 - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
- OpenVPN Community Wiki | OpenVPN Cipher Negotiation (Quick reference)
- RFC 5288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS
- WLAN Security – Cryptography and Network
- What is Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP)?
- WireGuard
- source.android.com | File-based encryption
- BitLocker Overview | Microsoft Learn
- FileVaultの概要 - Apple サポート (日本)
- Chapter 19. Encrypting block devices using LUKS | Red Hat Documentation
- サーバー側の暗号化によるデータの保護 - Amazon Simple Storage Service
- クライアント側の暗号化を使用したデータの保護 - Amazon Simple Storage Service
- デフォルトの保存データの暗号化 | Google Cloud Documentation
- エンベロープ暗号化 | Google Cloud Documentation



