はじめに：コードの「見た目」ではなく「挙動の物理的痕跡」を狙う
ペネトレーションテストの現場において、多くのジュニアテスターや開発者は「認証ロジックの脆弱性」といえば、SQLインジェクション、不十分なセッション管理、あるいは平文でのトークン受け渡しといった、アプリケーション層のロジックの破綻ばかりを探しがちだ。しかし、真に洗練されたレッドチームは、コードが論理的に正しく見えたとしても、そこで処理を実行する「ハードウェアの物理的制約」に目を向ける。その代表例が、今回取り上げるサイドチャネル攻撃（特にタイミング攻撃）である。
現代のWebアプリケーション、APIゲートウェイ、あるいはマイクロサービスの認証モジュールにおいて、パスワードハッシュの検証やAPIキー、JWTの署名検証における文字列比較は、セキュリティの最後の砦である。しかし、多くの開発者は「結果が真か偽か」に囚われ、その比較処理がどのようなCPUサイクルを消費しているかという低レイヤのメモリ挙動に無頓着だ。
本稿では、文字列比較のわずかな実行時間の差から秘密情報を復元するタイミング攻撃のメカニズムを解剖し、脆弱なコードがなぜ生まれるのかという根本原因から、完全に安全な定数時間比較（Constant-time comparison）の実装、そしてそれを担保するための静的・動的監査手法に至るまで、実戦的な知見を交えて徹底的に解説する。
—
1. タイミング攻撃のメカニズム：なぜ「1バイトの一致」が漏洩するのか
タイミング攻撃の原理は極めてシンプルでありながら、数学的かつ物理的な必然に基づいている。攻撃者は、ターゲットのエンドポイントに対して大量のリクエストを送信し、それぞれレスポンスにかかる時間（ラウンドトリップタイム、あるいはサーバ側の処理時間）をミリ秒、あるいはマイクロ秒単位で計測する。
脆弱性の根本原因は、多くの汎用的な文字列比較関数（C言語の strcmp() や、多くの高水準言語における通常の == 演算子など）が採用している「早期脱出（Short-circuit evaluation）」にある。
// 脆弱な文字列比較の概念実装（早期脱出の罠）
int vulnerable_compare(const char *s1, const char *s2) {
while (*s1 && *s2) {
if (*s1 != *s2) {
return 0; // 不一致を発見した瞬間に処理を打ち切る
}
s1++;
s2++;
}
return (*s1 == *s2);
}この実装では、比較対象の文字列が先頭から一致しているバイト数が多いほど、ループの実行回数が増え、処理時間が長くなる。
例えば、真のAPIキーが a3f8... である場合、攻撃者が推測で a000... を送信した場合は最初の1バイトで不一致となり即座に処理が終了する。しかし、a300... を送信した場合、最初の2バイトが一致するため、CPUは次のバイトの比較まで処理を進め、わずかに処理時間が延びる。
この統計的な時間の差異を、数千〜数万回のサンプリングと統計解析（ノイズの除去と分散分析）によって抽出することで、攻撃者は1バイトずつ秘密情報を特定していく。ネットワークジッター（遅延の揺らぎ）が大きなインターネット経由であっても、リクエストの集計と機械学習的なアプローチを組み合わせることで、このシグナルを捉えることは十分に可能である。
—
2. 脆弱な実装と安全な定数時間比較（Constant-time comparison）のアーキテクチャ
タイミング攻撃を防ぐための唯一にして絶対の解決策が、「定数時間比較（Constant-time comparison）」である。これは、入力された文字列が一致していようがしていなかろうが、常に全く同じ命令数、同じメモリアクセス パターン、同じ実行時間を強制するアルゴリズムを指す。
ここでは、実務で頻繁に利用されるPHPおよびNode.jsを例に、脆弱な実装とセキュアな実装のコントラストを示す。
PHPにおける実装例
PHPでは、標準でタイミング攻撃対策が施された関数が用意されているが、古いコードベースでは依然として危険な == や strcmp() が使われている。
<?php
/**
* 脆弱な実装：通常の文字列比較演算子
* 理由: 最初の不一致の時点で比較を中断するため、タイミング攻撃に脆弱
*/
function insecure_token_check(string $input_token, string $valid_token): bool {
// 危険: 攻撃者はレスポンス時間の差から有効なトークンを推測可能
return $input_token === $valid_token;
}
/**
* 安全な実装：定数時間比較
* 理由: hash_equals() は入力の長さに依存せず、常に一定の時間で比較を実行する
*/
function secure_token_check(string $input_token, string $valid_token): bool {
// 文字列の長さが異なる場合の情報漏洩を防ぐため、事前に長さを揃えるか、
// hash_equalsは内部でタイミング攻撃を防ぐセーフティネットを持つ
return hash_equals($valid_token, $input_token);
}
?>Node.js (JavaScript) における実装例
Node.js環境においても、crypto モジュールが提供する専用の関数を使用しなければならない。
const crypto = require('crypto');
/**
* 脆弱な実装：通常の厳密等価演算子
* 理由: V8エンジンの最適化や文字列の長さ、一致箇所によって処理時間が変動する
*/
function insecureCompare(input, secret) {
return input === secret; // 攻撃のターゲットになる
}
/**
* 安全な実装：定数時間比較
* 理由: crypto.timingSafeEqual を使用し、バッファの比較を一定時間で行う
*/
function secureCompare(input, secret) {
// バッファの長官が異なる場合にエラーを吐くため、事前にレングスチェックを行うが、
// 長さの比較自体によるタイミングリークを最小限に抑える配慮が必要
const inputBuffer = Buffer.from(input);
const secretBuffer = Buffer.from(secret);
if (inputBuffer.length !== secretBuffer.length) {
// 長さが違う場合でも、処理時間を一定に近づけるためのダミー処理を入れるなどの工夫が求められることもある
return false;
}
return crypto.timingSafeEqual(inputBuffer, secretBuffer);
}—
3. セキュリティアーキテクトのための監査と防御のベストプラクティス
コードレベルでの定数時間比較の導入だけでは、現代の複雑な分散システムにおけるサイドチャネルリスクを完全に排除することはできない。テックリードやセキュリティアーキテクトは、システム全体を俯瞰した多層防御（Defense-in-Depth）を構築する必要がある。
1. キャッシュヒットとデータベースレイヤの盲点
アプリケーションコードで hash_equals を使用していても、データベースのクエリレベルでタイミングリークが発生している場合がある。
例えば、SQLの WHERE username = 'admin' AND password_hash = '...' というクエリにおいて、インデックスの有無や、パスワードハッシュの照合順序（Collation）、さらには存在しないユーザー名に対するパスワード検証の有無（ユーザー列挙攻撃とタイミング攻撃の複合）によってレスポンス時間が変わることがある。
対策: 認証失敗時は、有効なユーザーであっても無効なユーザーであっても、ハッシュ計算（例: Argon2idやPBKDF2のダミー実行）を含めて完全に同一の処理フローと応答時間を返すように設計する。
2. APIゲートウェイとプロキシ層のジッター対策
クラウド環境（AWS, GCP, Azure等）やコンテナオーケストレーション（Kubernetes）上では、ネットワークのルーティングやCPUスロットリングによってマイクロ秒単位の計測がノイズにかき消されると考えがちだが、攻撃者は数万〜数百万回のリクエストを非同期で送り込み、統計的ノイズをフィルタリングする高度なツール（例: Timing-Attack 系のフレームワーク）を使用する。
対策:
- 認証エンドポイントに対しては、レスポンスタイムに意図的なランダム遅延（Jitter）を付与するか、レートリミットを厳格に適用し、高頻度な計測リクエスト自体をブロックする。
- WAF（Web Application Firewall）やAPI Gateway層で、異常なリクエストパターン（同一IPからの微小な差分を持つ大量のペイロード送信など）を検知するルールを実装する。
3. 静的解析（SAST）とCI/CDパイプラインへの組み込み
開発者のヒューマンエラーによって、将来的に脆弱な文字列比較が再導入されることを防ぐため、CI/CDパイプラインにセキュリティ Linterを組み込むべきである。
SonarQubeやSemgrepなどの静的解析ツールを使用し、カスタムルールを定義して == や strcmp が認証関連のモジュールで使用されている箇所をビルド時に自動検知し、強制的にビルドを失敗させる仕組みを構築することが、組織的アプローチとして極めて有効である。
—
おわりに：物理的現実に向き合うエンジニアリング
セキュリティの歴史は、論理的なバグ（メモリ破壊や論理欠陥）の克服から始まり、現在ではハードウェアの物理的特性そのものを攻撃ベクトルとするサイドチャネル攻撃の領域へとシフトしている。
「動けばいい」「結果が合っていればいい」という旧来のエンジニアリングマインドは、現代の高度な脅威アクターの前では致命的なアキレス腱となる。我々テックリードやセキュリティスペシャリストは、コードの表面的な美しさではなく、それがCPU、メモリ、そしてネットワークという物理世界にどのような痕跡を残すのかという「低レイヤの現実」に常に意識を向けてアーキテクチャを設計し続けなければならない。
コメント