【実務・中級編】サイドチャネル攻撃（タイミング攻撃）に対する定数時間(Constant-time)実装 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

その「比較処理」が命取りになる：サイドチャネル攻撃と「定数時間実装」の極意

現場でコードレビューをしていると、未だに「文字列比較」の危うさを軽視しているエンジニアに出くわす。特に認証トークンやAPIキー、HMACの検証部分だ。

「if ($user_input === $stored_hash) なんて、どこにでもある普通のコードじゃないか」

そう思った君こそ、今日の話を深く聞いてほしい。君が書いたその一行が、実は攻撃者に「秘密鍵をミリ秒単位で漏洩させる」ためのオープンな扉になっているかもしれないのだから。

1. なぜ「普通の比較」が危険なのか？（タイミング攻撃の正体）

一般的なプログラミング言語の文字列比較関数（== や === など）は、「不一致が見つかった瞬間に処理を打ち切る（ショートサーキット）」という最適化を行っている。

例えば、"secret_key" と "sccccc..." を比較する場合、最初の 's' が一致すれば次の文字へ進むが、2文字目で不一致が出れば、そこで比較を終了する。つまり、「合っている文字数が多いほど、処理時間がわずかに長くなる」という特性がある。

攻撃者はこのわずかな「時間のゆらぎ」を統計的に計測する。何万回、何十万回とリクエストを送り、応答時間の差を分析すれば、総当たり攻撃（ブルートフォース）をせずとも、一文字ずつ確実に秘密鍵を特定できてしまう。これが「タイミング攻撃（Timing Attack）」の恐ろしさだ。

2. 「定数時間（Constant-time）」という鉄壁の防御策

この攻撃を防ぐ唯一の解法が「定数時間実装」だ。これは、「入力が何であっても、処理にかかる時間を常に一定にする」というアルゴリズムのこと。たとえ最初の文字が間違っていようが、最後の文字が間違っていようが、必ず全ての文字を比較し終えてから結果を返す。

現場で使える具体的な実装例を見ていこう。

PHPでの実装例：hash_equals を使う

PHPの場合、自分でロジックを書く必要はない。標準関数に hash_equals が用意されている。これこそが、内部で定数時間での比較を保証してくれるプロの道具だ。

<?php
// 安全な検証サンプル
$userInput = $_POST['api_key']; // ユーザーからの入力
$storedKey = get_api_key_from_vault(); // 保存された秘密鍵

/**
 * 危険な書き方：
 * if ($userInput === $storedKey) { ... }
 * これだとタイミング攻撃に晒される
 */

// 安全な書き方：
// hash_equals は、入力文字列の長さが異なっても一定時間で処理を完了する
if (hash_equals($storedKey, $userInput)) {
    // 認証成功
    echo "Access Granted.";
} else {
    // 認証失敗
    echo "Invalid Credentials.";
}

Node.js (JavaScript) での実装例：crypto.timingSafeEqual

Node.js環境であれば crypto モジュールの timingSafeEqual を使う。注意点は、比較するバッファの長さが等しい必要があることだ。長さが違う場合は、先に長さをチェックして適当なダミー値を比較するなどして、処理時間を揃える工夫が必要になる。

const crypto = require('crypto');

function safeCompare(input, stored) {
    const inputBuffer = Buffer.from(input);
    const storedBuffer = Buffer.from(stored);

    // 長さが違うことを悟られないよう、ダミーのバッファを作るなどの配慮が必要
    if (inputBuffer.length !== storedBuffer.length) {
        return false;
    }

    // 定数時間で比較を行う
    return crypto.timingSafeEqual(inputBuffer, storedBuffer);
}

3. 実践：運用現場で「盲点」を潰すために

コードレベルの対策はわかった。しかし、インフラエンジニアやSREとしての視点も忘れてはならない。

1. WAFによるレート制限:
タイミング攻撃には大量のリクエストが必要だ。NginxやAWS WAFで、同一IPからの短時間のリクエストを徹底的に絞ることは、サイドチャネル攻撃への強力な「時間稼ぎ」になる。

# Nginxでのレート制限設定例（/api/auth への攻撃を防ぐ）
    limit_req_zone $binary_remote_addr zone=auth_limit:10m rate=1r/s;
    
    location /api/auth {
        limit_req zone=auth_limit burst=5 nodelay;
        # ... 後続の設定
    }

2. ログの正規化:
アプリケーション側で「ユーザーが存在しません」と「パスワードが違います」をレスポンスやログで明確に分けると、これもまた攻撃者のヒントになる。認証エラー時は常に汎用的なメッセージを返し、処理時間も一定に保つのが鉄則だ。

最後に：セキュリティは「泥臭さ」の積み重ね

「そんな細かいことまで？」と思うかもしれない。だが、世界中のハッカーは、まさにその「細かいこと」の積み重ねでシステムを陥落させている。

暗号技術は完璧な数学理論の上に成り立っているが、それを実装する君たちのコードには常に「物理的な制約（時間）」が付きまとう。その物理的な隙間を埋めるのが、プロのエンジニアの矜持だ。

今日から、プロジェクト内の == や === を見直してみてほしい。「これは認証に使っているか？」「秘密鍵を扱っているか？」と。その問いかけ一つで、君のシステムは一歩、堅牢な城壁に近づくはずだ。