初期化ベクトルとは？暗号化に必要な理由・IV再利用の危険性・AES-GCMでの正しい使い方を徹底解説｜サイバーセキュリティ.com

  1. ホーム /
  2. コラム /
  3. 初期化ベクトルとは？暗号化に必要な理由・IV再利用の危険性・AES-GCMでの正しい使い方を徹底解説
             

初期化ベクトルとは？暗号化に必要な理由・IV再利用の危険性・AES-GCMでの正しい使い方を徹底解説



「AESで暗号化するとき、IVって何を設定すればいいの？」「同じパスワードで暗号化しても毎回異なる暗号文になるのはなぜ？」「CBC・CTR・GCMモードでIVの扱い方が違うと聞いたけど何が違う？」——暗号化の実装で必ずぶつかる概念が「初期化ベクトル（IV）」です。

初期化ベクトル（IV：Initialization Vector）とは、ブロック暗号の暗号化モードで暗号化処理の初期状態を決めるために使われる値です。同じ平文を同じ鍵で暗号化しても、毎回異なるIVやNonceを使うことで異なる暗号文を生成できます。これにより、攻撃者が暗号文のパターンから平文を推測するリスクを下げられます。

ただし、IVに求められる性質は暗号化モードによって異なります。CBCモードでは予測困難なランダムIVが重要で、CTRやGCMでは同じ鍵で再利用しない一意なNonceとしての性質が特に重要です。

初期化ベクトル（IV）とは？

初期化ベクトル（IV：Initialization Vector）とは、ブロック暗号の暗号化処理において、最初の状態を決めるために使われる値です。暗号化の「スタート地点」を変えることで、同じ平文・同じ鍵でも異なる暗号文を生成できるようにします。

たとえば、同じメッセージを同じ鍵で暗号化する場合でも、毎回異なるIVを使えば暗号文は異なります。これにより、「同じ暗号文が出ているから、同じ内容が送られている」といったパターン解析を防ぎやすくなります。

「サイコロで決めるスタート地点」のたとえ
初期化ベクトルは「暗号化という迷路を解く際の、サイコロで決めたスタート地点」のようなものです。同じ迷路（暗号化アルゴリズム）・同じ解き方（鍵）を使っても、スタート地点（IV）が毎回違えば、通る道（暗号化の過程）も結果（暗号文）も変わります。攻撃者は「同じスタート地点から始まれば同じ道を通る」という性質を悪用できるため、IVを適切に変えることが重要です。
IV
2024.9.8
IV（Initialization Vector）は、暗号化プロセスで使用される初期値で、データの暗号化をより安全にするために使用されます。暗号化アルゴリズムの特性により、同じ平文（暗号化前のデータ）を複数回暗号化すると、同じ暗号文（暗号化

初期化ベクトルの基本的な性質

IVには、主に以下のような性質が求められます。

  • 予測困難性・一意性：CBCでは予測困難なIVが重要で、CTR/GCMでは同じ鍵で同じIV/Nonceを再利用しないことが最重要
  • 再利用しないこと：同じ鍵で同じIVを使い回すと、暗号化モードによっては深刻な情報漏えいや改ざんにつながる
  • 秘密性は不要：IVは秘密にする必要はなく、暗号文と一緒に保存・送信できる
  • サイズはモードに依存：CBCではAESのブロックサイズに合わせて128ビット（16バイト）のIVを使い、AES-GCMでは96ビット（12バイト）のIV/Nonceが推奨される
鍵長とIV長は別の概念
AES-128やAES-256の「128」「256」は鍵長を表します。一方、IVの長さは暗号化モードによって決まります。たとえば、AES-CBCではAESのブロックサイズである16バイトのIVを使い、AES-GCMでは12バイトのNonceが一般的に推奨されます。

初期化ベクトルが必要な理由：同一平文問題

ECBモード（IVなし）の問題点

ECB（Electronic Codebook）モードは、IVを使わない最も単純な暗号化モードです。各ブロックを独立して同じ鍵で暗号化します。

ECBモードの問題
ECBモードでは、同じ平文ブロックは常に同じ暗号文ブロックになります。たとえば、同じ鍵で同じデータを何度暗号化しても、同じ暗号文が生成されます。そのため、攻撃者は暗号文の繰り返しパターンから、元データの構造や内容の一部を推測できる場合があります。画像をECBで暗号化しても輪郭や模様が残ってしまう「ECBペンギン」の例は、この問題を説明する代表的な教材として知られています。

IVを使う場合（CBCモードなど）の改善

IVを使うCBCモードでは、最初のブロックの平文をIVとXOR演算してから暗号化します。その後の各ブロックには、直前の暗号文ブロックを使って連鎖的に暗号化します。

同じ平文でも異なるIVを使えば、以下のような効果があります。

  • 最初のXOR演算の結果が異なる
  • 最初の暗号文ブロックが異なる
  • 後続ブロックへの連鎖も異なる
  • 結果として、同じ平文でも異なる暗号文が生成される

これにより、攻撃者が暗号文の一致や繰り返しから平文のパターンを推測しにくくなります。

暗号化モード別のIVの役割

IVの役割や必要な性質は、暗号化モードごとに異なります。特にCBC、CTR、GCMでは扱い方が大きく違うため、実装時には注意が必要です。

CBCモード（Cipher Block Chaining）

CBCモードは、IVを使って最初のブロックをランダム化する暗号化モードです。過去に広く使われてきましたが、改ざん検知を別途行う必要があるため、現在はGCMなどのAEADモードが選ばれることも増えています。

  • IVの役割：最初のブロックの平文とXOR演算して暗号化を開始する初期値
  • IVの要件：予測困難なランダム値。同一鍵で同じIVを再利用しない
  • IVのサイズ：AES-CBCでは16バイト
  • IVの送信方法：暗号文の先頭に平文で付加して保存・送信できる
  • 注意点：IVが予測可能な場合、特定条件下で平文推測の足がかりになる場合がある。改ざん検知にはHMACなどの認証が必要

CTRモード（Counter）

CTRモードでは、IVはカウンター値の初期値、またはNonceとして機能します。ブロック暗号でカウンター値を暗号化してキーストリームを生成し、そのキーストリームと平文をXORして暗号文を作ります。

  • IV/Nonceの役割：カウンターの開始値として機能し、キーストリーム生成に使われる
  • IV/Nonceの要件：同じ鍵で絶対に再利用しない
  • メリット：並列処理しやすく、ランダムアクセスにも向いている
  • 注意点：同じ鍵・同じIV/Nonceを再利用すると、同じキーストリームが再利用される
CTRモードでIV再利用が危険な理由
CTRモードで同じ鍵・同じIV/Nonceを再利用すると、同じキーストリームが生成されます。その結果、暗号文同士のXORから平文同士の関係が漏れ、一方の平文が既知または推測可能な場合に、もう一方の平文も復元されるおそれがあります。鍵そのものが直ちに漏れるというより、暗号化されたデータの機密性が大きく損なわれる点が問題です。

GCMモード（Galois/Counter Mode）

GCMモードは、CTRモードをベースに認証機能を追加したAEAD（Authenticated Encryption with Associated Data）方式です。暗号化と改ざん検知を同時に実現できるため、現在の多くの用途で推奨されやすいモードです。

  • IV/Nonceの役割：CTRモードと同様にカウンターの初期値として使われ、認証タグの生成にも関係する
  • IV/Nonceの要件：同じ鍵で再利用しない。再利用は厳禁
  • 推奨サイズ：AES-GCMでは96ビット（12バイト）のIV/Nonceが推奨される
  • メリット：暗号化と認証（改ざん検知）を同時に実現できる
  • 注意点：IV/Nonceを再利用すると、平文情報の漏えいや認証タグの偽造につながる可能性がある
GCMでNonce再利用が危険な理由
GCMで同じ鍵・同じIV/Nonceを再利用すると、暗号化部分ではCTRモードと同様に同じキーストリームが再利用されます。さらに、認証タグの安全性にも影響し、条件によっては改ざん検知が破られる可能性があります。GCMでは「同じ鍵でNonceを再利用しない」ことが極めて重要です。

ECBモード（IV不使用）

ECBモードではIVを使用しません。同じ平文ブロックが常に同じ暗号文ブロックになるため、暗号文のパターンから情報が漏れる可能性があります。現在のセキュリティ要件では、一般的なデータ暗号化にECBモードを使うべきではありません。

モード IV/Nonceの役割 IV/Nonceのサイズ（AES） 再利用 推奨度
ECB 不使用 — — ❌ 使用非推奨
CBC 最初のブロックのXOR値 128ビット（16バイト） 禁止。予測困難なIVが必要 ⚠️ 条件付きで使用可。認証を別途組み合わせる
CTR カウンターの初期値 設計・ライブラリに依存 厳禁 ○ 使用可。ただし認証を別途組み合わせる
GCM Nonce。暗号化と認証タグ生成に関係 96ビット（12バイト）推奨 厳禁 ✅ 現代的な用途で推奨されやすい（AEAD）

初期化ベクトル・Nonce・Saltの違い

IVと似た概念として「Nonce」と「Salt」があります。いずれもランダム値・一意な値として使われることがありますが、目的と使われる文脈が異なります。

概念 正式名称 目的 秘密性 主な使用場面
IV Initialization Vector 暗号化処理の初期状態を決める。同じ平文でも異なる暗号文を生成しやすくする 不要（公開可） AES-CBC、AES-CTRなどの暗号化モード
Nonce Number used once 一度しか使わない値。CTR/GCMではキーストリームや認証タグ生成に関係する 不要（公開可） AES-GCM、AES-CTR、認証プロトコル、リプレイ攻撃対策
Salt — パスワードハッシュに付加し、同じパスワードでも異なるハッシュ値にする 不要（DBに保存可） bcrypt、Argon2、PBKDF2などのパスワードハッシュ
IVとNonceの関係
GCMやCTRモードでは、IVのことをNonceと呼ぶことが多く、実質的に近い意味で使われます。厳密には、IVは「暗号化の初期状態を決める値」、Nonceは「一度しか使わない値」という概念です。CTRやGCMでは、IVにNonceとしての一意性が強く求められます。

脆弱なIVの実装例と攻撃手法

IVの再利用

IVの再利用は、暗号化モードによっては非常に危険です。特にCTRやGCMでは、同じ鍵と同じIV/Nonceを再利用すると、同じキーストリームが再利用され、機密性や改ざん検知が破綻するおそれがあります。

Two-Time Pad問題
CTRモードでは、キーストリームと平文をXORして暗号文を生成します。同じ鍵・同じIVを使うと同じキーストリームが生成されます。攻撃者が2つの暗号文を入手した場合、暗号文同士をXORすることで平文同士のXORが得られます。片方の平文が既知または推測可能であれば、もう一方の平文も推測される可能性があります。

予測可能なIVの使用

CBCモードでは、IVが予測可能な場合、特定条件下で平文推測の足がかりになることがあります。代表例として、TLS 1.0のCBCモードにおけるBEAST攻撃が知られています。

BEAST攻撃は、前のレコードの最後の暗号文ブロックが次のレコードのIVとして使われるというTLS 1.0の仕様上の性質を悪用し、Cookieなどの機密情報を推測する可能性を示した攻撃です。

固定IVの使用

「IV = 0x00000000…」のような固定値や定数を使うと、同じ鍵・同じ平文に対して同じ暗号文が生成されやすくなります。これは、暗号文のパターン解析につながります。

特に、同じデータ構造や同じメッセージを繰り返し暗号化する場合、攻撃者に「同じ内容が送られている」ことを推測される可能性があります。

脆弱な乱数生成器の使用

`Math.random()`（JavaScript）や `rand()`（C言語）など、暗号論的に安全ではない乱数生成器でIVを生成すると、攻撃者にIVが予測される可能性があります。

IVやNonceを生成する場合は、OSや暗号ライブラリが提供するCSPRNG（暗号論的に安全な乱数生成器）を使用する必要があります。

IVの正しい生成・管理方法

正しいIVの生成（言語別の例）

Python（AES-GCMの場合）

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# AES-GCMでは96ビット（12バイト）のNonceが一般的

nonce = os.urandom(12)

# AES-256の場合は32バイトの鍵

key = os.urandom(32)

aesgcm = AESGCM(key)

# plaintextはbytes型

ciphertext = aesgcm.encrypt(nonce, plaintext, None)

# nonceは秘密ではないため、暗号文と一緒に保存・送信する

data = nonce + ciphertext

Java（AES-GCMの場合）

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import java.security.SecureRandom;

SecureRandom random = new SecureRandom();

byte[] iv = new byte[12]; // AES-GCMでは96ビット（12バイト）が一般的
random.nextBytes(iv);

Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");

GCMParameterSpec spec = new GCMParameterSpec(128, iv); // 認証タグ長128ビット
cipher.init(Cipher.ENCRYPT_MODE, key, spec);

byte[] ciphertext = cipher.doFinal(plaintext);

IVの正しい管理原則

  • CSPRNGを使う：`os.urandom()`、`SecureRandom`、`crypto.getRandomValues()` などを使う
  • 同じ鍵でIV/Nonceを再利用しない：暗号化するたびに新しい値を使う
  • IVは暗号文と一緒に保存・送信する：IVは秘密ではないため、暗号文の先頭に付加して保管できる
  • GCMでは96ビットNonceを優先する：ライブラリの推奨に従い、12バイトのNonceを使う
  • 同じ鍵で大量に暗号化しない：大量の暗号化を行う場合は、Nonce衝突やライブラリの利用上限を考慮して鍵更新を設計する
  • 暗号化だけでなく認証も行う：CBCやCTRを使う場合は、HMACなどで改ざん検知を組み合わせる
  • ライブラリの高レベルAPIを使う：独自実装を避け、実績ある暗号ライブラリの推奨設定を使う

IVに関連する被害・注意事例2選

事例1：WEPの短いIVと鍵ストリーム再利用の問題

IVの扱いを誤った代表的な事例が、無線LAN暗号方式WEPです。WEPでは、共通鍵に24ビットのIVを組み合わせてRC4の鍵ストリームを生成します。しかし、24ビットのIVは短く、同じIVが再利用されやすいという問題がありました。

同じ鍵と同じIVが再利用されると、同じ鍵ストリームが生成され、攻撃者が複数の暗号文を比較することで、平文や鍵に関する情報を推測しやすくなります。この問題により、WEPは現在では安全な無線LAN暗号方式とは見なされていません。

この事例は、IVが秘密であるかどうかよりも、「同じ鍵で再利用しないこと」「十分な長さと一意性を確保すること」が重要であることを示しています。

WEP
2024.9.8
WEP（Wired Equivalent Privacy）は、Wi-Fiなどの無線LANネットワークを保護するために設計された初期の暗号化プロトコルで、通信を有線接続と同程度のプライバシーとセキュリティで守ることを目標としています。1997

事例2：TLS 1.0のCBC実装とBEAST攻撃

BEAST攻撃は、TLS 1.0のCBCモードにおけるIVの扱いに関連する代表的な攻撃です。TLS 1.0では、前のレコードの最後の暗号文ブロックが次のレコードのIVとして使われるため、攻撃者がIVを予測できる状況がありました。

攻撃者が中間者の立場で通信を観測し、さらに被害者のブラウザに選択平文を送らせることができる場合、Cookieなどの機密情報を推測できる可能性が示されました。この問題は、CBCモードにおいてIVが予測可能になることの危険性を示した重要な事例です。

現在では、TLS 1.2以降でAES-GCMなどのAEADモードを利用する構成や、TLS 1.3への移行が一般的に推奨されています。古いTLS 1.0/1.1やCBCベースの脆弱な設定を残さないことが重要です。

よくある質問（FAQ）

Q. IVは必ず秘密にする必要がありますか？

いいえ。IVは秘密にする必要はありません。暗号文と一緒に平文で保存・送信して構いません。一般的な実装では、暗号文の先頭にIVやNonceを付加して保存します。

重要なのは、IVの秘密性ではなく、暗号化モードに応じた予測困難性や一意性です。特にCTRやGCMでは、同じ鍵で同じIV/Nonceを再利用しないことが重要です。

Q. 同じIVを使い回すと何が起きますか？

暗号化モードによって問題の深刻さが異なります。CBCモードでは、同じ鍵・同じIVで同じ平文を暗号化すると同じ暗号文になり、パターン解析のリスクが高まります。

CTRモードやGCMモードでは、同じ鍵・同じIV/Nonceを再利用すると同じキーストリームが再利用されます。その結果、暗号文同士の関係から平文情報が漏れたり、GCMでは認証タグの偽造につながったりする可能性があります。

Q. AES-GCMで推奨されるIVのサイズは何バイトですか？

AES-GCMでは、96ビット（12バイト）のIV/Nonceが推奨されます。96ビット以外のサイズも利用できる場合がありますが、内部処理やセキュリティ特性が変わるため、ライブラリや標準仕様で推奨される12バイトを使うのが一般的です。

ただし、12バイトのNonceを使えば無制限に暗号化できるわけではありません。同じ鍵で大量の暗号化を行う場合は、Nonceの衝突確率やライブラリ・プロトコルの利用上限を考慮し、一定量を超える前に鍵を更新する設計が必要です。

Q. IVとNonceは同じものですか？

概念的に近いですが、厳密には異なります。IVは「暗号化の初期状態を設定する値」、Nonceは「Number used once（一度しか使わない値）」を意味します。

CTRやGCMモードでは、IVのことをNonceと呼ぶことが多く、実質的に近い意味で使われます。一方、CBCモードでは歴史的にIVと呼ばれることが多く、予測困難なランダム値としての性質が重要になります。

Q. Saltとは何が違いますか？

Saltは、主にパスワードハッシュで使われる値です。同じパスワードでも異なるハッシュ値になるようにし、レインボーテーブル攻撃を防ぐ目的で使われます。

IVやNonceは、暗号化処理の初期状態や一意性を確保するために使われます。どちらも秘密にする必要はない点では似ていますが、使われる文脈と目的が異なります。

Q. TLSではIVをどのように扱っていますか？

TLS 1.3では、AES-GCMやChaCha20-Poly1305などのAEAD暗号スイートが使われ、アプリケーション開発者がIVを直接管理することは通常ありません。TLSライブラリに任せ、古いTLS 1.0/1.1や脆弱な暗号スイートを無効化することが重要です。

TLS 1.0のCBCモードでは、IVの扱いに関連するBEAST攻撃が知られています。現在のWebサーバー運用では、TLS 1.2以上、できればTLS 1.3を有効化し、古いプロトコルや暗号スイートを無効化することが推奨されます。

まとめ

初期化ベクトル（IV）とは、ブロック暗号の暗号化処理において、初期状態を決めるために使われる値です。同じ平文・同じ鍵でも、IVやNonceを適切に変えることで異なる暗号文を生成し、暗号文のパターン解析を防ぎやすくします。

IVは秘密にする必要はなく、暗号文と一緒に保存・送信できます。ただし、暗号化モードごとに必要な性質が異なります。CBCでは予測困難なIVが重要で、CTRやGCMでは同じ鍵でIV/Nonceを再利用しないことが最重要です。

ECBモードはIVを使わず、同じ平文ブロックが同じ暗号文ブロックになるため、現在の一般的なデータ暗号化では使用すべきではありません。CBCを使う場合はHMACなどの認証と組み合わせ、可能であればAES-GCMなどのAEADモードを利用するのが一般的です。

開発者は、CSPRNGでIV/Nonceを生成し、同一鍵での再利用を避け、暗号文と一緒に保存・送信する設計を行う必要があります。特にAES-GCMでは、96ビット（12バイト）のNonceを使い、同じ鍵で大量の暗号化を行う場合は鍵更新や利用上限を考慮しましょう。

IVの扱いを誤ると、WEPのように鍵ストリームの再利用が問題になったり、TLS 1.0のBEAST攻撃のように予測可能なIVが攻撃に利用されたりする可能性があります。暗号化の安全性はアルゴリズムだけでなく、IVやNonceの正しい生成・管理に大きく依存します。

関連コラム（あわせて、以下の記事もよく読まれています）

製品・サービス（当該コラムの内容に関連する製品・サービスはこちら）

SNSでもご購読できます。