FiberによるArgon2id並行処理の極意と、Zend VM低レイヤから見たサイドチャネル攻撃耐性設計
PHPは長らく、単一リクエスト・単一スレッドの共有何も持たない（Shared-Nothing）アーキテクチャの範疇を出なかった。だが、PHP 8.1で導入されたFiber（ファイバー）は、そのZend VMの実行コンテキストをユーザーランドから明示的に切り替えることを可能にし、I/O待ちや重い演算のスケジューリングにおけるパラダイムシフトをもたらした。
本稿では、計算コストの極めて高いパスワードハッシュアルゴリズム「Argon2id」の処理をFiberによって非同期的に並行化し、かつ昨今のセキュリティアーキテクチャにおいて避けて通れないサイドチャネル攻撃（特にタイミング攻撃）に対する耐性をZend VMのメモリ構造とキャッシュレイヤの挙動から再定義する。
—
1. Zend VMにおけるFiberのコンテキストスイッチとメモリ管理の現実
まず、FiberがZend VM内部でどのように扱われているかを低レイヤの視点から直視せよ。一般的なOSスレッドとは異なり、Fiberは完全なユーザーランド・コルーチンである。
Zend Engine内部において、PHPの実行状態は `zend_execute_data` という巨大なスタックフレームの連結リストによって管理されている。通常の関数呼び出しや制御構造の遷移では、このスタックが連続的なメモリ領域（あるいはチャンク単位の割り当て）上で延伸・縮小する。しかし、Fiberが生成されると、そのFiber専用の `zend_fiber_context` がヒープ上に割り当てられ、独自のコールスタックと実行状態（`EG(vm_stack)` や `EG(current_execute_data)` の退避領域）を持つことになる。
[ PHP Request Lifecycle ]
│
├─ Main Execution Context (Zend VM Stack)
│ └─ Fiber::suspend() ──┐ (Registers are saved, VM state swapped)
│ │
└─ Fiber Context (Heap) ◄─┘
└─ Argon2id Computation (CPU-bound / Non-blocking simulation)
このコンテキストスイッチ自体は非常に軽量（数千クロックサイクル程度）であるが、誤解してはならないのは、PHPのFiberはプリエンプティブ（先占式）ではなく、協調的（協調マルチタスク）であるという点だ。CPUを完全に占有する重い演算（Argon2idのメモリハード関数など）を単一のFiber内で長々と実行すれば、イベントループをブロックし、他のFiberへ制御が移ることはない。
したがって、CPUバウンドな処理を並行化するためには、処理を適切なチャンクに分割し、明示的に `Fiber::suspend()` を呼び出してイベントループにコンテキストを返す設計が必要となる。
—
2. Argon2id並行化の実装パターンとイベントループの統合
以下のコードは、複数の重いパスワード検証またはハッシュ生成タスクを、Fiberベースの簡易的なイベントループを用いて非同期に（見せかけの並行処理として）処理する実例である。
/
class FiberScheduler
{
/ @var \SplQueue<\Fiber> /
private \SplQueue $queue;
public function __construct()
{
$this->queue = new \SplQueue();
}
public function add(\Fiber $fiber): void
{
$this->queue->enqueue($fiber);
}
public function run(): void
{
while (!$this->queue->isEmpty()) {
$fiber = $this->queue->dequeue();
if (!$fiber->isTerminated()) {
try {
// Fiberの実行を再開（または開始）
if (!$fiber->isStarted()) {
$fiber->start();
} else {
$fiber->resume();
}
// まだ終了していなければ再度キューの末尾に戻す（協調的マルチタスク）
if (!$fiber->isTerminated()) {
$this->queue->enqueue($fiber);
}
} catch (\Throwable $e) {
echo “Fiber Error: ” . $e->getMessage() . “\n”;
}
}
}
}
}
/
- Argon2idによる高コスト演算を模した非同期ワーカー
/
function createArgon2idWorker(string $password, string $identifier): \Fiber
{
return new Fiber(function () use ($password, $identifier) {
// Zend VMのメモリ空間上でハッシュパラメータを設定
$options = [
‘memory_cost’ => PASSWORD_ARGON2_DEFAULT_MEMORY_COST,
‘time_cost’ => PASSWORD_ARGON2_DEFAULT_TIME_COST,
‘threads’ => PASSWORD_ARGON2_DEFAULT_THREADS,
];
echo “[Worker: {$identifier}] 演算開始…\n”;
// 実際のpassword_hashは内部でC言語のlibsodium/crypt_argon2を呼び出すブロッキング処理。
// CPUバウンドなため、厳密な非同期化には処理の細分化や別プロセス/エクステンション連携が必要だが、
// ここではFiberによるコンテキストスイッチのフローを示す。
// 模擬的に負荷の高い処理の前にサスペンドを挟む構造を想定
Fiber::suspend();
$hash = password_hash($password, PASSWORD_ARGON2ID, $options);
echo “[Worker: {$identifier}] 演算完了. Hash生成成功.\n”;
return $hash;
});
}
// スケジューラの初期化と複数の重いタスクの登録
$scheduler = new FiberScheduler();
$scheduler->add(createArgon2idWorker(‘SecretPassword_A’, ‘Task-1’));
$scheduler->add(createArgon2idWorker(‘SecretPassword_B’, ‘Task-2’));
$scheduler->add(createArgon2idWorker(‘SecretPassword_C’, ‘Task-3’));
// イベントループの駆動
$start = microtime(true);
$scheduler->run();
$end = microtime(true);
printf(“全Fiberの処理が完了しました。実行時間: %.4f 秒\n”, $end – $start);
—
3. サイドチャネル攻撃（タイミング攻撃）への耐性設計
暗号処理、特にパスワードハッシュの照合や秘密情報の比較において最も脅威となるのがタイミング攻撃（Timing Attack）である。攻撃者は、処理にかかるマイクロ秒単位の実行時間の差異を観測し、内部の機密データ（ハッシュの一部一致具合やストレージ上の存在有無）を推測する。
Zend VMとCPUキャッシュの罠
PHPのコードレベルで `if ($input === $secret)` のような文字列比較を行った場合、通常の演算子は先頭から一致する文字数を比較し、不一致を見つけた時点で処理を打ち切る（短絡評価・早期リターン）。これが致命的なタイミングの差異を生む。
さらに、Argon2idはそのアルゴリズムの性質上、広大なメモリ領域（Memory-hard）をランダムアクセスするため、CPUのL1/L2/L3キャッシュミスやTLB（Translation Lookaside Buffer）ヒット率の変動が実行時間に直接影響を与える。これをマルチテナント環境のWebサーバー上でFiberを使って並行実行する場合、異なるFiber間でのキャッシュ汚染（Cache Contention）が新たなサイドチャネルのベクトルとなり得る。
堅牢な定数時間比較（Constant-Time Comparison）の実装
PHPにおいてタイミング攻撃を防ぐ唯一の正解は、データの中身や一致状況に関わらず、常に正確に同じ実行時間を保証する「定数時間比較」を行うことである。PHP 5.6以降、コアには `hash_equals()` が備わっている。これを低レイヤのセキュリティ要件に則って適用せよ。
/
class SecureVerifier
{
/
- タイミング攻撃およびサイドチャネルを意識した検証ロジック
/
public static function verify(string $knownHash, string $userInput): bool
{
// 1. まず通常のpassword_verifyを実行
// 注: password_verify自体は内部で定数時間に近い処理を行うよう設計されているが、
// ユーザー側の前処理やメタデータの比較でリークが起きる余地を排除する。
$isValid = password_verify($userInput, $knownHash);
// 2. ダミーのハッシュ検証を一定回数挟むことで、
// Fiberのコンテキストスイッチやキャッシュ挙動に起因するタイミングの揺らぎをカモフラージュする
// （高度なタイミング攻撃に対する防壁の一例）
self::mitigationPadding($userInput);
return $isValid;
}
private static function mitigationPadding(string $input): void
{
// 長さに依存しない固定的な負荷を与えることで外部からの観測を攪乱
$dummyHash = ‘$argon2id$v=19$m=65536,t=4,p=1$ZHVtbXlzYWx0ZHVtbXlzYWx0$DummyHashResultStringForTimingNormalization…’;
// あえて無駄な演算（定数時間比較のラッパー）を走らせる
hash_equals($dummyHash, hash(‘sha256’, $input));
}
}
—
4. OPcacheプリローディングとセキュリティ上の注意点
大規模なWebアプリケーションにおいて、Argon2idのラッパーやFiberスケジューラを含むクラス群をリクエストごとにディスクからパース・コンパイルするのは、Zend VMのコンテキストにおいて致命的なオーバーヘッドとなる。ここでOPcacheプリローディング（Preloading）が必須となる。
`php.ini` で `opcache.preload` を指定すると、サーバー起動時（`php-fpm` のマスタープロセス起動時）に指定スクリプトが読み込まれ、すべてのクラス定義や関数が共有メモリ（SHM）上に永続化される。
opcache.preload = /var/www/html/config/preload.php
opcache.preload_user = www-data
アーキテクトが警鐘を鳴らすべき「オブジェクトインジェクション」との危険な交差点
プリロードされたクラスは、全ワーカープロセス間で共有されるため、メモリ上の保護領域に常駐する。ここで、もしアプリケーションコードにPHPオブジェクト注入（PHP Object Injection: `unserialize()` の脆弱性）が存在した場合、その脅威は単なる単一リクエストの乗っ取りに留まらない。
攻撃者が悪意あるGadget Chain（既存のクラス群のデストラクタやマジックメソッド `__wakeup`, `__destruct` を連鎖させた攻撃コード）を構成可能な場合、プリロードされた強固なクラス群のメモリ空間を踏み台にして、Zend VMの実行権を完全に掌握される危険性が跳ね上がりに跳ね上がる。
- 対策:
1. ユーザーからの入力値を `unserialize()` に直接渡す愚を絶対に犯すな（JSON等の安全なシリアライザを使用せよ）。
2. プリロード対象のクラスには、マジックメソッド内での危険な動的メソッド呼び出し（`call_user_func` やプロパティの自動評価）を含めないこと。
—
5. チーフアーキテクトからの総括
Fiberによる非同期並行処理は、PHPをI/OバウンドなモダンWebアプリケーションの最前線へと押し上げる強力な武器である。しかし、そこにCPUバウンドかつ高セキュリティが要求されるArgon2id等の暗号処理を組み合わせる場合、Zend VMのスタック構造、イベントループの調停、そしてCPUキャッシュレベルのサイドチャネル攻撃への耐性をエンジニア自身が深く理解していなければならない。
フレームワークが隠蔽する抽象化の層を剥ぎ取り、低レイヤのメモリとプロセスの挙動までを掌握した者だけが、真に堅牢かつ高パフォーマンスなWebシステムを構築できる。コードの1行、コンテキストスイッチの1回に魂を込めよ。