【実務・中級編】オンチェーンKYC/AMLの実装とプライバシー保護のトレードオフ – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

オンチェーンKYCのジレンマ：ZKPで「匿名性と規制」を両立させる現場の知恵

現場のエンジニア諸君、お疲れ様。SCADA/OTの現場でPLCのパッチを当てた翌日に、Web3のコントラクト監査に飛び込むような忙しい日々を送っていることだろう。

今回は、Web3開発において最も頭を悩ませる「オンチェーンKYC/AMLとプライバシー保護」という矛盾したテーマについて話そう。規制当局は「透明性（誰が何をしたか教えろ）」を要求し、ユーザーは「プライバシー（俺の資産を監視するな）」を叫ぶ。この板挟みの中で、我々が取るべき最適解は一つだ。「ゼロ知識証明（ZKP）を用いた証明書の発行」だ。

なぜ「生のデータ」をオンチェーンに置いてはいけないのか

多くのジュニアエンジニアが犯す最大のミスは、氏名やパスポート番号をハッシュ化してオンチェーンに保存することだ。

「ハッシュ化しているから大丈夫です」？それはセキュリティとは言わない。ただの「読みにくい平文」だ。攻撃者は、漏洩したオフチェーンのデータベースとオンチェーンのハッシュ値を突き合わせる（レインボーテーブル攻撃やブルートフォース）だけで、瞬時に個人を特定する。

真のセキュリティは、「オンチェーン上に個人情報を一切存在させない」ことから始まる。

ZKPによる解決：証明の検証のみを行う

ユーザーの個人情報はオフチェーン（オンプレのセキュアなDBやIPFS）に保持し、オンチェーンには「そのユーザーが法的にクリーンであるという証明（ZK-Proof）」のみを書き込む。これにより、コントラクトは「誰か」を知る必要はなく、「条件を満たしているか」だけを検証できる。

実装サンプル：Circom（ZKP回路）の概念

ZKPの実装には Circom や SnarkJS を使うのが業界標準だ。ここでは、「年齢が18歳以上であること」を証明する回路の簡略版を示す。

// 18歳以上であることを証明する回路
pragma circom 2.0.0;

template AgeVerifier() {
    signal input age;      // 実際の年齢（秘密）
    signal input threshold; // 18という定数
    signal output isAdult;  // 検証結果

    // ここでageがthreshold以上かを数学的に証明する
    // 実際には比較演算を制約に変換する
    isAdult <== (age >= threshold);
}

component main = AgeVerifier();

攻撃の盲点：検証ロジックをバイパスされる「再利用攻撃」

さて、ここからが本題だ。ZKPを導入したとしても、実装の甘さを突かれると即死する。最も危険なのが、「証明の再利用（Replay Attack）」だ。

攻撃者は、ある正当なユーザーの proof を傍受し、自分のウォレットアドレスと紐付けて再送信する。コントラクト側で「この証明は誰のものか」を厳格に管理していない場合、攻撃者は他人のKYCステータスを拝借して不正取引を行う。

セキュアなコントラクト実装（Solidity）

対策として、証明に nullifier（一意な識別子）と address を組み込む必要がある。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract KYCVerifier {
    // すでに使用された証明を記録する（リプレイ攻撃対策）
    mapping(bytes32 => bool) public usedNullifiers;

    function verifyAndTransact(
        uint256[2] memory a,
        uint256[2][2] memory b,
        uint256[2] memory c,
        uint256 nullifier, // 一意なID
        address userAddress
    ) public {
        // 1. 証明が既に使われていないかチェック
        bytes32 nullifierHash = keccak256(abi.encodePacked(nullifier, userAddress));
        require(!usedNullifiers[nullifierHash], "この証明は既に使われています");

        // 2. ここでGroth16などのZKP検証関数を実行する
        // bool isValid = verifier.verifyProof(a, b, c, inputs);
        // require(isValid, "証明が不正です");

        // 3. 使用済みとしてマーク
        usedNullifiers[nullifierHash] = true;
        
        // 4. 以降、本来の処理（送金など）を実行
    }
}

運用現場での「最後の砦」：WAFとログ管理

コードが完璧でも、インフラがガバガバなら意味がない。Web3フロントエンドからのAPI呼び出しに対し、Nginxでレートリミットをかけ、異常なアクセスパターンを検知する設定は必須だ。

# Nginx設定例: KYC検証APIへのブルートフォース対策
limit_req_zone $binary_remote_addr zone=kyc_limit:10m rate=1r/s;

server {
    location /api/v1/request-kyc-proof {
        limit_req zone=kyc_limit burst=5 nodelay;
        # 不審なユーザーエージェントを弾く設定も忘れずに
        if ($http_user_agent ~* (python-requests|curl)) {
            return 403;
        }
    }
}

最後に：セキュリティは「性悪説」で考えろ

現場のインシデントハンドリングで学んだのは、「設計書通りに動くユーザーは存在しない」ということだ。

1. オフチェーンデータの保護： KYCデータは最高レベルの暗号化（AES-256-GCM等）で保管せよ。
2. 監査ログ： 誰がどの証明をいつ生成したか、オフチェーン側にも完全な監査証跡を残せ。
3. 継続的な監視： オンチェーン上の Events を監視し、不自然な検証リクエストが集中した瞬間に自動停止するサーキットブレーカーを組み込め。

Web3の世界では、一度流出した個人情報は取り返しがつかない。技術的なトレンドを追うのも大切だが、まずは「どうすれば攻撃者のコストを最大化できるか」という視点を常に忘れないでほしい。

健闘を祈る。何かあればまた相談してくれ。