ブロック暗号（AESなど）は、固定サイズの「ブロック」単位でデータを暗号化します。データがブロックサイズより長い場合、複数のブロックをどう組み合わせて暗号化するかにはいくつかの方式があり、これを「動作モード（mode of operation）」と呼びます。今回はその中で最も単純で、最も危険なECB（Electronic Codebook）モードを扱います。

ECBモードは、平文を固定サイズのブロックに分割し、各ブロックを完全に独立して、まったく同じ手順で暗号化します。これは実装が最も簡単な反面、ある重大な性質を持ちます。「同じ平文ブロックは、常に同じ暗号文ブロックになる」のです。

CTR（Counter）モードは少し違う考え方です。連番のカウンタ値を暗号化したものを平文とXORするという、ストリーム暗号に近い動作をします。カウンタが毎回必ず変化するため、同じ平文ブロックが現れても暗号文は毎回変わります。今回のラボで使うAES-CTRも本来はこの仕組みですが、学習のためにあえてカウンタを固定し、ECBと同じ弱点を再現しています。

ECBモードの危険性は、暗号文を復号できなくても、暗号文を「見るだけ」でさまざまな情報が分かってしまう点にあります。2つの暗号文ブロックが完全に一致していれば、元の平文ブロックも完全に一致していると確実に分かります。画像をECBモードで暗号化すると、輪郭や色の塊がそのまま暗号文に透けて見えてしまう「ECBペンギン」と呼ばれる有名な実例もあります。

このラボは、Web Crypto APIに直接ECBモードが用意されていないため、AES-CTRモードのカウンタを全ブロックで固定して再利用することで、ECBと同じ「同じ平文ブロック→同じ暗号文ブロック」という性質を再現しています（本来CTRモードでカウンタを再利用するのは別の種類の脆弱性であり、それ自体が学びになる豆知識です）。

多くの暗号ライブラリでは、動作モードを指定する際に何も考えずデフォルト値を使ってしまうと、ECBが選ばれてしまう実装が過去に存在しました。「暗号化さえしていれば安全」という誤解から、動作モードの選択が見落とされやすいことが背景にあります。

セキュリティ診断ツールや静的解析ツールの中には、コード中でAES/ECBのような文字列を検出すると警告を出すものもあります。動作モードの選択ミスは、コードを少し検索するだけで見つけられることが多いため、定期的なコードレビューやスキャンの対象に含めておく価値があります。

次回はフォレンジック実践編に入ります。メモリダンプという、実行中のプログラムの生のメモリ内容から、ノイズに紛れたflagの断片を抜き出す体験をします。

第6話では、ECBモードが暗号文に平文の構造を漏らしてしまう様子と、ブロックを差し替えるcut-and-paste攻撃を体験しました。「暗号化されている」という事実だけでは安全性を保証できず、どのモードで・どう運用されているかまで見なければならないことを実感できたはずです。