暗号の代表的な誤用パターン

Electronic Codebook（ECB）モードでは、各ブロックを同じ鍵で独立して暗号化します。同一の平文ブロックは、同一の暗号文ブロックになります。よく知られた例が「ECB penguin」です。ビットマップ画像をECBで暗号化すると、画像のブロックレベルの構造が保たれ、暗号文からペンギンの輪郭がはっきり見えてしまいます。ECBモードには意味的安全性がなく、実用的な暗号化目的には決して使用すべきではありません。

暗号プリミティブをゼロから実装することは、ソフトウェア開発で最も危険な行為の一つです。暗号には、攻撃者が存在する状況でも完全に正しく動作することが求められます。わずかなタイミング漏えい、パディング処理のオフバイワンエラー、セキュリティ要件の誤解などによって、通常のテストでは正しい動作と区別できない、悪用可能な脆弱性が生じる可能性があります。専門の暗号研究者でさえ実装を誤ることがあるため、アプリケーション開発者は十分に監査されたライブラリだけを使用してください。

MD5は2004年以降、衝突耐性が破られており、同じMD5ハッシュを持つ2つのファイルを作成することは計算上容易です。SHA-1に対する衝突攻撃は、GoogleのSHAttered攻撃によって2017年に実証され、同じSHA-1ハッシュを持つ2つのPDFファイルが生成されました。どちらもデジタル署名、コンテンツの完全性、パスワード保存、HMACなど、いかなるセキュリティ目的にも使用すべきではありません。最新のシステムではSHA-256、SHA-3、またはBLAKE2を使用してください。

セキュリティ目的でPRNGの出力を使用する場合に、time()やその他の予測可能な値をシードに使うと、重大な脆弱性になります。鍵が生成されたおおよその時刻を攻撃者が知っていれば、狭い時間範囲内のすべてのタイムスタンプを試してシードを総当たりし、鍵を復元できます。典型的な例として、Netscapeの初期バージョンではSSL鍵の生成に時刻とプロセスIDを使用していましたが、どちらも同じマシン上の攻撃者から観測可能でした。

Cのrand()、java.util.Random、Pythonのrandomモジュールは、統計的な品質をシミュレーション向けに設計された決定論的な線形合同法またはMersenne Twisterを使用しており、セキュリティ向けではありません。攻撃者は、これらの生成器から十分な量の出力を観測すると、内部状態を再構成して将来の出力をすべて予測できます。セキュリティ目的では、OSが提供するCSPRNGを使用してください。Pythonではsecrets.token_bytes()、Node.jsではcrypto.randomBytes()、Linuxでは/dev/urandomを使用します。

認証なしの暗号化で得られるのは機密性だけであり、完全性は保証されません。攻撃者は平文を読めなくても暗号文を変更でき、平文に予測可能な変化を引き起こす可能性があります（特にCTRモードやCBCモードで顕著です）。この可鍛性によって攻撃が可能になります。たとえば、暗号化された銀行取引を傍受した攻撃者は、平文を知らなくてもビットを反転させ、振込金額や送金先口座を変更できる可能性があります。必ず認証付き暗号（AEAD）を使用してください。

暗号鍵や初期化ベクトルをソースコードにハードコードすることは、重大な脆弱性です。ソースコードはバージョン管理リポジトリにコミットされることが多く、その中には公開リポジトリもあります。非公開リポジトリであっても、コードにアクセスできる人は誰でも鍵を取得できます。鍵をハードコードすると、すべてのインスタンスが同じ鍵を使用し、鍵のローテーションには再デプロイが必要になります。鍵は環境変数、シークレット管理システム（HashiCorp Vault、AWS Secrets Manager）、またはハードウェアセキュリティモジュールに保存してください。

同じ鍵で複数回暗号化する際に同じ初期化ベクトルを使用すると、重大な脆弱性が生じます。CTRモードでは、IVを再利用すると同じキーストリームが生成され、XORによって平文を復元できるようになります。CBCモードでは、IVを再利用すると、2つのメッセージが同じ平文ブロックで始まっているかどうかを攻撃者が検出できます。GCMでは、ノンス（IV）の再利用は致命的です（ノンス再利用のレッスンを参照してください）。暗号化するたびに新しいランダムなIVを生成し、復号に必要な情報とともに保存できるよう暗号文の先頭に付加してください。

MD5、SHA-256、その他の高速な暗号ハッシュでパスワードをハッシュ化して保存する方法は不十分です。現代のGPUは1秒あたり数十億回のSHA-256ハッシュを計算できるため、盗まれたハッシュデータベースに対するオフライン総当たり攻撃を極めて高速に実行できます。パスワードのハッシュ化には、bcrypt、scrypt、Argon2idのような、専用の低速でメモリハードな関数が必要です。これらは、専用ハードウェアを使っても総当たり攻撃に大きなコストがかかるよう設計されており、オフライン攻撃を計算上実行困難にします。

SSL/TLS証明書の検証を無効にすると（Pythonでssl.CERT_NONEを設定する、curlに-kを渡す、AndroidでtrustAllCerts=trueを設定するなど）、中間者攻撃に対する保護がなくなります。攻撃者は任意の証明書を提示して、すべての通信を傍受できます。この方法は、自己署名証明書のエラーを回避するために開発環境で使われますが、本番環境にもそのまま残ることが少なくありません。常に適切な証明書検証を行い、根本的な証明書の問題を正しく解決してください。

暗号関数は、戻り値や例外を通じて失敗を通知します。これらを無視すると、復号によって無意味なデータが生成された場合、検証に失敗した場合、鍵生成でエラーが発生した場合でも、無効な状態のまま処理が続行されます。OpenSSLのようなCベースのAPIでは、戻り値を無視することは特に危険です。プログラムが未初期化メモリを使って処理を続ける可能性があるためです。暗号関数からの戻り値はすべて確認し、失敗を安全に処理してください。

データの暗号化にECB（Electronic Codebook）モードを使うと安全でないのはなぜですか？

避けるべき主な誤用パターンは次のとおりです。ECBモードは決して使用しない（ブロックパターンが漏れるため）、暗号プリミティブを自分で実装しない、セキュリティ目的でMD5やSHA-1を使用しない、PRNGのシードにはtime()ではなくCSPRNGを使用する、セキュリティに関わるすべての乱数にCSPRNGを使用する、暗号化データは必ず認証する（AEAD）、鍵やIVをハードコードしない、暗号化ごとに新しいIVを生成する、パスワードには高速ハッシュではなくArgon2idを使用する、TLS証明書を必ず検証する、暗号関数の戻り値をすべて確認する、という原則です。