DePIN機器のなりすまし対策｜リモートアテステーションで複製・盗難機器を見抜く

あるDePINのネットワークが、センサー機器を各地の運用者に配り、集めたデータに応じて報酬を払っています。運営チームが本番を前に洗い出すと、報酬をだまし取る手口がいくつも見つかりました。

• 正規の機器のファイルシステムを複製し、ソフトウェアで作った別の機器を、正規の機器として登録する。
• 盗まれた機器や、廃棄したはずの機器が、報酬を受け取り続ける。
• 正規の機器から、偽のセンサー値や位置を送る。

手口ごとに、突かれている場所が違います。鍵をまねる手口もあれば、正規の鍵のまま偽の値を送る手口もあります。そのため、1つの確認だけでは全部を防げません。そこで、3つの問いを分けて確かめます。

1. 誰の鍵か：機器の識別（device identity）
2. 中身は正規のソフトウェアか：リモートアテステーション
3. 価値ある仕事をしたか：業務上の証明

3つは別々に検証し、別々の責任者に持たせます。それが出発点です。

リモートアテステーション（Remote Attestation）は、「正規の鍵を持つ機器が、承認済みのハードウェア・ファームウェアの状態で動いている」かを判断する材料です。位置情報やセンサー値が本物か、1台の物理機器が1つだけ存在するか、報酬に値する仕事を終えたかまでは、自動では証明できません。3つ目の手口は、別の仕組みで防ぎます。

以下では、このネットワークの責任者・設計者・運用担当が決めることを順に追います。鍵の持たせ方、検証の役割分担、機器の状態の管理、ブロックチェーンに置く範囲、障害のときの動きです。DePINの仕組みそのものは「DePIN学習ロードマップ」から基礎を確認できます。

機器のIDは、番号ではなく機器の中の鍵で決める

管理画面の連番やMACアドレスは、検索用の識別子にはなります。ただ、それだけでは、接続してきた相手が本当にその機器だとは証明できません。

DePINの機器の識別は、次のものを結び付けた関係です。

• 機器の中で守られた秘密鍵と公開鍵、その鍵を発行・登録した根拠
• ハードウェアの型番、所有者・運用者（operator）、ファームウェアの系列
• 今、使ってよい状態か

決めることと、誤ったときに起きることは次のとおりです。

鍵をSecure Element、TPM、TEEなどで守るかは、どんな攻撃を想定するか（脅威モデル）で決めます。大事なのは製品名ではありません。攻撃者がOSの権限や、機器に物理的に触れる機会を得たとき、鍵を取り出したり複製したりできるか。更新のときにも、信頼のつながりを保てるか。この2点です。

TCGのDICE Attestation Architectureは、機器の識別と、階層的なアテステーション（layered attestation）を扱う参照仕様の1つです（Trusted Computing Group: DICE Attestation Architecture）。

証拠を出す側・判定する側・使う側を分ける

IETFのRATS（Remote ATtestation procedureS）Architectureは、役割を次のように分けています（RFC 9334: RATS Architecture）。

• 機器（Attester）：証拠（Evidence）を作って出す
• 検証サーバー（Verifier）：Evidenceを、判定の方針と基準値（Reference Values）で評価する
• 受付・報酬のシステム（Relying Party）：検証結果を使って、業務の処理を決める

このほか、機器の製造元などが保証情報（Endorsements）を出します。承認済みファームウェアのハッシュなどは、基準値として検証サーバーに渡します。

ポイントは、Evidenceの暗号の検証と、業務の判断を分けることです。接続を許すか、データを受け入れるか、報酬を払うかは、検証とは別に決めます。不合格の機器は、隔離の状態へ移します。

DePINでは、機器の状態を複数の主体で共有する登録台帳も加わります。台帳を含めると、分ける役割は4つです。

それぞれの入力と出力は、後半の「実装する人向けの詳細」にまとめました。

EAT（Entity Attestation Token）は、機器・ハードウェア・ソフトウェアについての主張（claim）を運ぶ標準の形式です（RFC 9711: Entity Attestation Token）。EATを使っても、どの主張を信じ、どの値なら合格とするかは、検証サーバーと判定方針が決めることです。トークンの形式を決めただけでは、信頼の仕組みはできあがりません。

登録から廃棄まで、機器の状態をどう管理するか

本番では、「アテステーションの成功／失敗」の2つだけでは足りません。製造、初回登録、通常の稼働、更新の猶予、隔離、復旧、失効、廃棄を、それぞれ状態として決めます。状態を移すのは誰か、移したら何が起きるかも決めます。

怪しい機器も、すぐには没収しません。まず隔離し、新しいデータを受け入れず、報酬を保留します。

隔離から稼働に戻すには、再イメージ化（ソフトウェアを入れ直すこと）、鍵の更新、現地確認をしたうえで、もう一度検証します。状態ごとの担当と細かな遷移は、後半にまとめました。

ファームウェアの更新では、新しい基準値を先に配ります。そのうえで、旧版も受け入れる期間、元の版へ戻す条件、緊急の失効を決めます。

NIST SP 800-193は、プラットフォームのファームウェアについて、保護・検知・安全な復旧を一組で扱っています（NIST SP 800-193: Platform Firmware Resiliency Guidelines）。アテステーションで異常に気づいても、復旧の道がなければ、大量の現地交換が生まれるだけです。交換や廃棄の運用は「DePIN機器の保守・交換・廃棄」も参照してください。

古い証拠の使い回しを、どう防ぐか

過去に合格したEvidenceを送り直せると、侵害された後の機器でも、正常に見せかけられます。

そこで検証サーバーは、予測できないnonceを問い（challenge）として送ります。機器は、nonceと測定値を一緒に署名して返します。こうすれば、送り直しを見抜けます。TPMを使う問いと応答（challenge-response）型の手順でも、新しいnonceが求められています（RFC 9684: CHARRA YANG Data Model）。

ただし、nonceだけでは決まらないことがあります。センサー値がいつ取られたか、別の要求向けのEvidenceが流用されていないか、です。そのため、Evidenceや署名の対象に、少なくとも次のものを含めます。

• 機器の鍵ID、nonce、ファームウェアの測定値
• 起動回数または安全な時刻の区切り（epoch）
• 要求の目的と、対象データのまとまりのダイジェスト

検証サーバーは、nonceが1回きりで期限内かを管理します。受付・報酬のシステムは、検証結果を想定外の用途に使い回しません。含める値の例は後半に載せました。

ブロックチェーンには何を置くか

アテステーションの検証に使う情報を見てみます。証明書チェーン、製造元の保証情報、ファームウェアの測定値、詳しいイベントログは、容量が大きく、更新も頻繁です。機器や設置場所を推測できる情報も含みます。

そのため、暗号の検証をスマートコントラクトだけで行う必要はありません。

現実的なのは、検証サーバーをオフチェーンに置く構成です。コントラクトは、次のことを確かめる役に絞ります。検証結果を出してよい検証サーバーか、どの判定方針か、結果の期限、機器の利用状態です。

1つの企業が、機器、検証サーバー、報酬の計算をすべて運用し、外部と共有する台帳が要らないなら、署名付きのデータベースとPKIで足りることがあります。

ブロックチェーンを使う理由は、アテステーションがあることではありません。互いに独立した主体が、同じ失効の状態や検証結果を、確かめられる形で共有する必要があるときです。

障害のとき、止めすぎず、残しすぎないためには

検証サーバーの停止をすべて「機器の不正」と扱うと、正常な機器のデータまで止まります。かといって、直近の成功結果をいつまでも使うと、侵害された機器が残ります。

そこで失敗の原因を分け、どこまで待てるかと、業務上の処理を決めます。

失敗ごとに何を材料に見分けるかは、後半にまとめました。

最後の行が、冒頭の3つ目の手口です。正規の機器が偽のデータを送る問題は、アテステーションでは防げません。データ品質の検証と報酬不正の扱いは「DePINのデータ品質と報酬不正対策」で扱っています。実在するネットワークでの例は「Helium」の解説を参照してください。

RFC 9334も、3つの失敗を別々に扱っています。Evidenceの不合格、受付・報酬のシステムの判定方針での不合格、検証サーバーに届かないこと、です。アテステーションは許可を決めるための材料であり、障害のときの業務判断そのものではありません。

TPM向けのRIV（Remote Integrity Verification）の仕様は、この流れを具体的にしています。TPMのEvidenceはTPMの中の鍵で署名され、検証サーバーが判定方針で評価し、意思決定へ渡します（RFC 9683: Remote Integrity Verification）。

採用する前に、5つの試験を通す

1. 複製試験：ファイルシステムを複製した別の機器が、同じ識別情報として通らないことを確かめます。
2. 再送試験：過去のEvidence、検証結果、データのまとまりを送り直し、拒否されることを確かめます。
3. 更新試験：新旧ファームウェアの重なる期間、元の版へ戻す操作、基準値の誤配布から復旧できることを確かめます。
4. 障害試験：検証サーバー、失効情報の配信、ブロックチェーンのRPCが止まっても、二重の報酬や機器の一斉失効が起きないことを確かめます。
5. 限界試験：正規のファームウェアから偽のセンサー値を送ったとき、アテステーション以外の検証で見つけて保留できることを確かめます。

Secure ElementやTEEの追加費用は、次のものと比べて決めます。複製で得られる不正な利益、現地交換の費用、機器の寿命、ファームウェアの更新頻度です。

業務上のリスクに比べてアテステーションが重すぎる場合は、軽い構成から始める手もあります。ハードウェアで守ったクライアント証明書、署名付きの更新、サーバー側の異常検知です。

3つを分けておけば、障害のときに判断できる

冒頭の3つの問いに戻ります。識別は「誰の鍵か」、リモートアテステーションは「どの環境・ソフトウェアの状態か」、業務上の証明は「価値ある仕事をしたか」に答えます。3つを1つの「機器の証明」にまとめると、どれが失敗したのかを見分けられません。すると障害のときに、何を拒否し、何を保留し、誰が復旧するかを判断できなくなります。

実装の前に、次の責任者を別々に割り当てます。

• 鍵の発行・失効
• Evidenceの評価
• 基準値の更新
• 接続の許可
• データの受け入れ
• 報酬の確定

そのうえで、オンチェーンには、独立した主体の間で共有する最小の状態だけを置きます。AIエージェントに機器を操作させる場合の委任の設計は「AIエージェントとIoT機器のID設計」で扱っています。DePIN全体のカテゴリと評価軸は「DePIN完全マップ 2026」で確認できます。

実装する人向けの詳細

役割ごとの入力と出力

• Attester：計測値・nonceから、署名付きのEvidenceを生成
• Verifier：Evidence、Endorsements、Reference Values、評価の方針から、検証結果（Attestation Result）を生成
• Relying Party：検証結果と業務上の判定方針から、処理を決定
• 登録台帳・レジャー：共有すべき最小の状態を保持

状態遷移の全体

Evidenceと検証結果に結び付ける値

Evidence = Sign_attestation_key(
  device_key_id,
  nonce,
  measurements,
  boot_epoch,
  purpose,
  hash(data_batch)
)

AttestationResult = Verifier(
  Evidence,
  endorsements,
  reference_values,
  appraisal_policy_version
)

この例は通信上の形式ではなく、欠かせない結び付けを確かめるためのものです。実装では、TPM Quote（TPMが署名して出す測定値の報告）、EAT、製造元固有のレポートなど、採用するハードウェアが安全に作れる形式にします。

失敗を見分ける材料

• Verifierのタイムアウト：署名検証の前の通信失敗、複数リージョンの稼働状況
• Evidenceの再送：nonceの再利用、epoch、結果の期限
• 未知のファームウェア：配布台帳、署名、型番、測定値
• ルート鍵・製造元の鍵の失効：証明書チェーン、失効情報、対象の製造ロット
• アテステーションは合格だがデータが異常：近隣のセンサー、物理的な上限、時間・空間の相関

XTELAができること

私たちは、機器・バックエンド・ブロックチェーンをまたぐ脅威モデル、機器の識別のライフサイクル、VerifierとRelying Partyの責任分界、状態遷移を設計し、複製・再送・更新失敗を注入するPoCとして実装しています。貴社の機器と報酬の仕組みに合わせ、どこまでをハードウェアで守り、どこからをデータ検証に任せるかを一緒に決められます。個別の要件の整理はお問い合わせからご相談ください。

参考資料

• IETF RFC 9334: Remote ATtestation procedureS (RATS) Architecture
• IETF RFC 9711: The Entity Attestation Token (EAT)
• IETF RFC 9683: Remote Integrity Verification of Network Devices Containing TPMs
• IETF RFC 9684: A YANG Data Model for Challenge-Response-Based Remote Attestation
• Trusted Computing Group: DICE Attestation Architecture
• NIST SP 800-193: Platform Firmware Resiliency Guidelines

資料の確認日と注意：IETF・NISTの仕様は2026年9月24日に確認しました（TCGの資料は2026年8月13日確認）。一般的な技術設計の解説であり、ハードウェアの安全性の保証や法的な判断に代わるものではありません。