AES暗号|高速・堅牢、世界標準の共通鍵暗号

AES暗号

AES暗号は米国標準の共通鍵ブロック暗号であり、ブロック長128-bit、鍵長128/192/256-bitに対応する。有限体上の線形変換と非線形置換を組み合わせた構造を持ち、128-bit鍵で10ラウンド、192-bitで12ラウンド、256-bitで14ラウンドの処理を行う。暗号強度と実装効率のバランスが良く、組込み機器からクラウドまで広く利用され、TLSやIPsec、ディスク暗号、ファームウェア保護などの基盤をなす。

基本構造と処理手順

AES暗号は16バイトの状態配列に対して、SubBytes(S-boxによる非線形置換)、ShiftRows(行シフト)、MixColumns(列方向の線形混合)、AddRoundKey(ラウンド鍵とのXOR)を繰り返す。初回のAddRoundKeyの後、最終ラウンドではMixColumnsを省く。鍵から各ラウンド鍵を生成するKey ScheduleはRconとワード回転・S-box適用を用いる。これらはGF(2^8)上の演算で定義され、実装ではルックアップ表や命令セット拡張により高速化される。

暗号モードと利用文脈

ブロック暗号はモード選択が安全性を左右する。ECBは同一平文ブロックが同一暗号文となるため非推奨である。CBCは初期化ベクトル(IV)を要し、パディングを伴う。CTRはカウンタを暗号化してストリーム化し、ランダムアクセスや並列化に適する。GCMはCTRとGHASHを組み合わせたAEADで、機密性と完全性を同時に提供する。ディスク暗号にはXTSが用いられ、ブロック位置に依存するトゥイークで構造的露出を抑える。

初期化ベクトル/ノンスの管理

CTR/GCMではノンスの重複が致命的であるため一意性を厳格に保証する。GCMでの12バイトノンスはカウンタと組み合わせて管理し、衝突を避ける設計(例:デバイスID+カウンタ)を採る。CBCではIVを予測不可能かつ再利用しないよう生成する。乱数はCS-PRNG(例:DRBG)やTRNGに基づく高品質ソースを用いる。

パディングとデータ長

CBCなどブロック整列を要するモードではPKCS#7などのパディング方式を用いる。一方、CTR/GCMはストリーム的に動作するためパディング不要で、可変長データに適する。設計時はデータ境界とAAD(Authenticated Additional Data)の扱いを明確化し、取り違いによる改ざん検知失敗を防ぐ。

鍵管理とライフサイクル

暗号の安全性は鍵管理に依存する。鍵生成は高エントロピー源から行い、派生にはKDF(例:HKDF)を用いる。鍵はセキュアエレメントやTPM、HSMに格納し、権限分離したKMSで配布・ローテーション・失効を運用する。長期運用では鍵分割(Shamir方式など)やバックアップの審査、監査証跡の保持が重要である。

実装最適化と命令拡張

汎用CPUではAES-NIやARMv8 Crypto Extensionsが利用可能で、SubBytesやMixColumnsを命令レベルで最適化できる。テーブル参照実装は高速だがキャッシュ副作用によるサイドチャネルの懸念があるため、タイミング一定の手法やビットスライス、命令拡張の活用が推奨される。組込みではDMA併用、パイプライニング、インライン化などでレイテンシと電力を両立させる。

サイドチャネル対策

定時間実装、ブランチ削減、キャッシュヒットの均一化、マスク化、電磁/消費電流ノイズ対策、フォールト挿入検知(冗長計算・タグ付け)を組み合わせて実装漏えいを抑制する。

典型的な攻撃面と耐性

AES暗号自体は現在、既知の実用的な差分・線形攻撃に耐性を示す。一方で、実装不備に起因するパディングオラクル、ノンス再利用、タグ未検証、タイミング/キャッシュ攻撃は現実的である。設計ではAEAD採用、タグ検証の一定時間化、失敗時の挙動統一、ノンス一意性保証を徹底する。

標準・適合性と相互運用

AES暗号はFIPS 197で規定され、運用モードはNIST SP 800-38A(CBC/CTR等)、SP 800-38D(GCM)、SP 800-38E(XTS)に整理される。相互運用のためKAT(Known Answer Test)で実装検証を行い、TLSやIPsec、IEEE規格等のプロファイルに従う。FIPS 140検証やCC認証を求める場合はモジュール境界、エントロピー、自己診断の要件を満たす。

用途と設計指針

通信路ではTLSにおけるAES-GCMが主流で、低遅延とAEADの利点を活かす。保存データではXTSがファイル/ディスク向けに適し、メタデータ保護やキー分離を行う。ファームウェア配布やOTAでは署名と暗号を分離し、更新処理はロールバック保護と併用する。制約環境では鍵長128-bit+GCMを基準とし、要件に応じて256-bitを検討する。

実装チェックリスト

  • ノンス/IVの一意性と生成法を仕様化する
  • AEADのタグ検証失敗時に情報漏えいのないエラー処理を行う
  • 命令拡張の有無で実装方針(テーブル/ビットスライス)を選ぶ
  • 鍵はKMS/SE/TPM等で保護し、ローテーション手順を定義する
  • 既知ベクトルでKATを実施し回帰試験に組み込む

よくある誤り

ECB使用、GCMノンス再利用、タグ未検証、CBCでの予測可能IV、エラー文言の差異によるオラクル化、テーブル駆動によるデータ依存タイミング、乱数源の不足などは重大な欠陥となる。設計段階から仕様・実装・運用の各層でガイドラインとレビュー体制を整え、形式検証やファジングを併用することが望ましい。

コメント(β版)