JP2023543456A - 認証システムおよび方法 - Google Patents

認証システムおよび方法 Download PDF

Info

Publication number
JP2023543456A
JP2023543456A JP2023519324A JP2023519324A JP2023543456A JP 2023543456 A JP2023543456 A JP 2023543456A JP 2023519324 A JP2023519324 A JP 2023519324A JP 2023519324 A JP2023519324 A JP 2023519324A JP 2023543456 A JP2023543456 A JP 2023543456A
Authority
JP
Japan
Prior art keywords
verifier
puf
transaction
party
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023519324A
Other languages
English (en)
Inventor
デイヴィーズ，ジャック，オーウェン
ライト，クレイグ，スティーヴン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nchain Holdings Ltd
Original Assignee
Nchain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nchain Holdings Ltd filed Critical Nchain Holdings Ltd
Publication of JP2023543456A publication Critical patent/JP2023543456A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3278—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response using physically unclonable functions [PUF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

目標者の目標コンピュータ設備によって：物理的複製不能関数PUFを含むPUFモジュールによって生成されたレスポンスから導出される暗号鍵を得る段階であって、前記レスポンスは、前記PUFモジュールに入力された対応するチャレンジに応答して前記PUFに基づいて前記PUFモジュールによって生成されたものであり、前記暗号鍵または対応する公開鍵を含む鍵情報は検証者に対しても利用可能にされる、段階と；発行者から、実行されるべき前記計算を指定する計算要求を受信する段階と；前記計算要求に応答して、計算結果を生成するために前記計算を実行する段階と；前記計算結果を含むメッセージに、前記暗号鍵を用いて署名する段階と；署名されたメッセージをブロックチェーン上に記録されるように送信することによって、前記署名されたメッセージを前記検証者に対して利用可能にする段階とを実行することを含む。

Description

本開示は、チャレンジとたとえば物理的複製不能関数（physically unclonable function、PUF）からレスポンスのシステムに基づく素性検証を実行するプロセスに関する。
物理的複製不能関数（PUF）は、決定論的だが予測不可能な物理現象を含む関数を指す技術用語である。PUFは解きに物理的ランダム関数とも称される。PUFは「チャレンジ」と称される入力を受け取り、チャレンジおよびPUFによって用いられる物理現象に依存して対応する「レスポンス」〔応答〕と称される出力を生成する。PUFは時に強弱に分類される。強いPUFは、多数の異なるチャレンジについてのそれぞれの応答を生成することができ、典型的にはチャレンジの任意の値を受けることができる。弱いPUFは、単一の応答または少数の応答のみについてレスポンスを生成することができる（典型的には、チャレンジは任意の値を取ることはできない）。換言すれば、強いPUFは多数のチャレンジ‐レスポンス・ペアをもち（大きなチャレンジ‐レスポンス空間をもつ）、一方、弱いPUFは単一のチャレンジ‐レスポンス・ペアまたは限られた数のチャレンジ‐レスポンス・ペアをもつ（小さな、または限られたチャレンジ‐レスポンス空間）。ある定義によれば、弱いPUFの応答数は、チャレンジ・ビットの数に関して線形である、あるいはより一般には、他のパラメータに関して線形より速くは増大しない。
強いPUFの既知の例は任意的なPUFである。たとえば、任意的なPUFは、レーザーと、光センサーと、泡もしくは媒質中にセットされた他のそのような欠陥をもつソリッドな光学媒質とを有していてもよい。レーザーは、制御可能な角度で光学媒質を通じて照射され、回折または散乱パターンを生成する（これは、媒質中の泡または欠陥の効果である）。センサーは、このパターンを感知するように構成される。チャレンジは、レーザーの角度であり、レスポンスは感知されたパターンに基づいて生成される。
弱いPUFの一例は、SRAM PUFである。この場合、チャレンジはSRAM（静的ランダムアクセスメモリ）をオンにすることである。あるSRAMと別のSRAMとの間でのわずかな製造上の差のため、SRAMセルは電源投入の際、0/1状態の一意的なパターンになり、これは個々のSRAMの特徴的なフィンガープリントをなす。PUFは電源投入の際にこれをレスポンスとして出力するように構成される。
PUFは、暗号アルゴリズムにおける使用などのための（たとえば文書に署名するまたは文書を暗号化するための）鍵を生成する手段として使用できる。PUFの別の応用は、PUFを組み込んでいるコンピュータ装置などの装置の識別用である。所与のチャレンジについての期待されるレスポンスが以前に決定されていれば、後刻、検証者は、そのチャレンジをもって目標装置にチャレンジして、目標装置が期待されるレスポンスを与えるかどうかをチェックし、それにより目標装置が期待されるレスポンスに関連付けられている装置であるかどうかをチェックすることができる。
限られたチャレンジ・レスポンス空間のため、PUFへの入出力（i/o）インターフェースは、一当事者または制約された数の当事者のみに制約される傾向がある（たとえば、一のまたは限られた数の信頼される当事者のみが、物理的にまたは法的に、PUFへのアクセスを承認される、またはPUFのインターフェースがパスワード保護などされてもよい）。すなわち、問題の当事者または諸当事者のみが、チャレンジを提出するために必要とされるPUFへの入力およびそこから応答が受領される出力へのアクセスを得ることができる。他方、強いPUFについては、強いPUFへのi/oインターフェースは、多数のまたは制限されない数の当事者にとって広く利用可能にされてもよく、かかる当事者のすべてが必ずしも既知または信頼される当事者ではない。理由は、チャレンジ・レスポンス空間が十分に大きいため、敵がチャレンジ-レスポンス・ペアのすべてを列挙することは現実的に可能ではなく、よって、敵がPUFに自由にアクセスできても、弱いPUFのように、列挙とPUFののぞき見を許容することによってその安全性を損なうことはないはずであるということである。
ある異なる技術分野において、ブロックチェーンは、分散式ピアツーピア（P2P）ネットワーク（下記では「ブロックチェーン・ネットワーク」と称される）における複数のノードのそれぞれにおいてブロックチェーンの複製コピーが維持され、広く公開される分散式のデータ構造の形をいう。ブロックチェーンはデータのブロックのチェーンを含み、各ブロックは一つまたは複数のトランザクションを含む。いわゆる「コインベース・トランザクション」以外の各トランザクションは、一つまたは複数のコインベース・トランザクションにさかのぼる一つまたは複数のブロックにまたがっていてもよいシーケンスにおける先行トランザクションをポイントする。コインベース・トランザクションについてのちにさらに論じる。ブロックチェーン・ネットワークに提出されるトランザクションは新しいブロックに含められる。新しいブロックは、しばしば「マイニング」〔採掘〕と称されるプロセスによって生成される。採掘は、前記ノードのうちの複数のノードのそれぞれが「作業証明」を実行するために競争する、すなわちブロックチェーンの新しいブロックに含められるのを待っている、順序付けられ有効確認されたペンディング・トランザクションの定義された集合の表現に基づく暗号学的パズルを解くことに関わる。ブロックチェーンはいくつかのノードにおいて剪定されてもよく、ブロックの公開は単なるブロック・ヘッダの公開を通じて達成できる。
ブロックチェーンにおけるトランザクションは、以下の目的のうちの一つまたは複数のために使用されてもよい：デジタル資産（すなわち、いくつかのデジタル・トークン）を伝達する、エントリーの集合を仮想化された台帳またはレジストリにおいて順序付ける、タイムスタンプ・エントリーを受領し処理する、およびまたはインデックス・ポインタを時間的に順序付ける。ブロックチェーンはまた、該ブロックチェーンの上に追加的な機能を上乗せするためにも活用できる。たとえば、ブロックチェーン・プロトコルは、追加的なユーザー・データまたはデータに対するインデックスをトランザクションに格納することを許容してもよい。単一のトランザクション内に格納できる最大データ容量に、あらかじめ指定された制限はなく、よって、ますます複雑なデータが組み込まれることができる。たとえば、これは、ブロックチェーン内に電子文書を格納するために使用されてもよく、オーディオまたはビデオ・データでもよい。
ブロックチェーン・ネットワークのノード（しばしば「マイナー」〔採掘者〕と称される）は、のちにより詳細に述べる分散式のトランザクション登録および検証プロセスを実行する。まとめると、このプロセスの間、ノードはトランザクションを有効確認し、ブロック・テンプレート中に挿入する。該ブロック・テンプレートについて、それらのノードは有効な作業証明解を識別しようとする。ひとたび有効が解が見出されたら、新しいブロックがネットワークの他のノードに伝搬させられる。こうして、各ノードは新しいブロックをブロックチェーン上に記録できる。トランザクションをブロックチェーン上に記録させるためには、たとえばユーザー（ブロックチェーン・クライアント・アプリケーション）は、伝搬させるために、そのトランザクションをネットワークのノードのうちの一つに送る。そのトランザクションを受信したノードは、有効確認されたトランザクションを新しいブロックに組み込む作業証明解を見出すために競争する。各ノードは、同じノード・プロトコルを施行するように構成され、それは、トランザクションが有効であるための一つまたは複数の条件を含むであろう。無効なトランザクションは伝搬させられたり、ブロックに組み込まれたりすることはない。トランザクションが有効確認され、それによりブロックチェーン上に受けいれられるとすると、そのトランザクション（任意のユーザー・データを含む）は、ブロックチェーン・ネットワークにおける各ノードにおいて、変更不能な公開レコードとして登録され、インデックス付けされたままとなる。
作業証明パズルを解くのに成功して最新ブロックを生成するノードは、典型的には、「コインベース・トランザクション」と呼ばれる、デジタル資産のある額、すなわちある数のトークンを分配する新しいトランザクションを報酬として与えられる。無効なトランザクションの検出および拒否は、競合するノードの行動によって施行される。それらのノードは、ネットワークのエージェントとして機能し、不正を報告し、ブロックするインセンティブをもつ。情報の広範な公開は、ユーザーたちがノードのパフォーマンスを絶えず監査することを許容する。単なるブロック・ヘッダの公開は、参加者が、ブロックチェーンの継続的な完全性を保証することを許容する。
「出力ベースの」モデル（時にUTXOベースのモデルと称される）では、所与のトランザクションのデータ構造は、一つまたは複数の入力および一つまたは複数の出力を含む。任意の消費可能な出力は、進行するトランザクションのシーケンスから導出可能なデジタル資産の額を指定する要素を含む。消費可能な出力は解きにUTXO（unspent transaction output［未使用トランザクション出力］）と称される。出力はさらに、該出力の将来の償還のための条件を指定するロック・スクリプトを含んでいてもよい。ロック・スクリプトは、デジタル・トークンまたは資産を有効確認し、移転するために必要な条件を定義する述語である。トランザクション（コインベース・トランザクション以外）の各入力は、先行トランザクションにおけるそのような出力へのポインタ（すなわち参照）を含み、さらに、ポイントされた出力のロック・スクリプトをロック解除するためのロック解除スクリプトを含んでいてもよい。よって、一対のトランザクションを考え、第1および第2のトランザクション（または「目標」トランザクション）と呼ぶことにする。第1のトランザクションは、デジタル資産の額を指定する少なくとも一つの出力と、該出力をロック解除する一つまたは複数の条件を定義するロック・スクリプトを含む。第2の、目標トランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む少なくとも一つの入力を含む。
そのようなモデルでは、第2の、目標トランザクションがブロックチェーンにおいて伝播および記録されるべくブロックチェーン・ネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、ロック解除スクリプトが第1のトランザクションのロック・スクリプトにおいて定義されている前記一つまたは複数の条件をすべて満たしていることである。もう1つは、第1のトランザクションの出力が、別の以前の有効なトランザクションによってすでに償還されていないことである。これらの条件のいずれかに従って目標トランザクションが無効であると判断したノードは、そのトランザクションを（有効なトランザクションとして）伝播させたり（ただし、無効なトランザクションを登録する可能性はある）、ブロックチェーンに記録されるべく新しいブロックに含めたりしない。
代替的なタイプのトランザクション・モデルは、アカウント・ベースのモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行トランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照して、移転されるべき額を定義する。すべてのアカウントの現在の状態は、ブロックチェーンとは別の諸ノードによって保存され、常に更新される。
本開示では、分散式コンピューティング・アプリケーションなどにおいて、発行者によって発行された計算を実行したと主張する目標者〔ターゲット・パーティー〕の素性〔アイデンティティ〕を検証するための機構においてPUFが用いられることができることが認識される。
本開示のある側面によれば、計算を実行するコンピュータ実装される方法が提供される。本方法は、前記計算を実行するコンピュータ設備である目標者の目標コンピュータ設備によって：物理的複製不能関数PUFを含むPUFモジュールによって生成されたレスポンスから導出される暗号鍵を得る段階であって、前記レスポンスは、前記PUFモジュールに入力された対応するチャレンジに応答して前記PUFに基づいて前記PUFモジュールによって生成されたものであり、前記暗号鍵または対応する公開鍵を含む鍵情報は検証者に対しても利用可能にされる、段階と；発行者から、実行されるべき前記計算を指定する計算要求を受信する段階と；前記計算要求に応答して、計算結果を生成するために前記計算を実行する段階と；前記計算結果を含むメッセージに、前記暗号鍵を用いて署名する段階と；署名されたメッセージをブロックチェーン上に記録されるように送信することによって、前記署名されたメッセージを前記検証者に対して利用可能にする段階とを実行することを含む。
目標者は、（標榜される）計算結果を含む前記メッセージに署名することを要求されるので、目標者の素性が追跡でき、これは、目標者が偽りの計算結果を返す意欲をなくさせる。諸実施形態において、署名の検証は、検証者によって結果が有効であると宣言されるための条件であってもよい。たとえば、これは、目標者が計算毎の支払いシナリオにおいて支払いを受けるための条件であってもよい
検証者は発行者と同じ当事者であってもなくてもよい。
諸実施形態において、署名された計算結果はブロックチェーン上に記録されてもよい。検証者または発行者は、トランザクションのペイロードにおいて署名された結果を含むトランザクションを用いて、目標者に支払いをしてもよい。
本開示の実施形態の理解を助け、そのような実施形態がどのように実施されうるかを示すために、単に例として、以下の添付図面を参照する。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録されうるトランザクションのいくつかの例を概略的に示している。 PUFのチャレンジおよびレスポンスを概略的に示している。 PUFを有するシステムの概略ブロック図である。 Aは、本願で開示される実施形態による拡大PUFの概略ブロック図である。Bは、非拡大動作モードでの該拡大PUFの概略ブロック図である。 チャレンジ‐レスポンス・ペアの配布における信頼されるサードパーティーまたは公開媒体に関わるシステムの概略図である。 本願に開示された実施形態による検証プロセスの概略フローチャートである。 A～Cは、本願に開示された実施形態による、マスター・チャレンジから一組のチャレンジを生成する方法を概略的に示している。 チェーン上でレスポンス・データを記録する方法を概略的に示している。 本願で開示される諸実施形態による、計算を実行したと主張する当事者の素性の検証を可能にする方法を示す概略フローチャートである。
人間と機械の両方のための鍵生成システムやプライバシーを保護する素性システムなどのシステムの堅牢性は、物理的複製不能関数（PUF）の関与によって改善される可能性がある。これらは、互いにまたはブロックチェーンなどの公開システムと相互作用している当事者〔パーティー〕および／または自律的機械でありうる。
これらの関数は、物理的な系に基づいており、物理的なデバイスの製造におけるランダムで決定不能かつ反復不可能な変動を前提として保護されており、人間の素性とそのデバイスとの間に確立されるリンクを強化したり、さらにデバイス自体についての偽造不可能な一意的な素性を確立したりするために使用できる。
文献では、PUFは弱いタイプと強いタイプに分類され、それらの異なる特性によって分類されている。以下の1つの側面によると、これらのタイプの両方のPUFの利点をもつ実用的なPUFデバイスを記述するための一般化された拡張PUF（extended PUF、ePUF）フレームワークが提供されている。つまり、ePUFは、実用的なままであり、実装するためのコスト効率が高いままでありながら、諸アプリケーションにおいて使用される幅広い範囲のチャレンジ‐レスポンス・ペアを生成しうる。
より一般的には、PUFおよびチャレンジ‐レスポンス・ペアの管理に関連するさまざまな側面が本願で開示されている。これらの異なる側面は、個別に、または任意の組み合わせで使用できる。これらはたとえば下記を含む：
I. PUFのチャレンジ‐レスポンス空間を拡大するための拡大PUF（expanded PUF）；
II. ePUFデバイスを使用して人間および／またはデバイスの素性を確立するためのブロックチェーンに関知しないプロトコルのセット；
III. ブロックチェーンを活用してこれらの素性プロトコルを改善するためのフレームワーク；
IV. チャレンジ-レスポンス・ペアを軽量に保存する技術；
V. ePUFデバイスの多様な問題への一連の新規な応用。たとえば、単純化された支払い検証（simplified payment verification、SPV）プロセスのためおよびデバイスによる検証可能な計算のためのKYCの実装など。
1. 物理的複製不能関数（PUF）‐序論
物理的複製不能関数（physically unclonable function、PUF）という用語は、汎用のランダム関数として機能する物理的なシステムおよびデバイスのクラスを指す。これらのPUFは、しばしばサブミクロン・スケールでの物理的特性によって一意的に特徴付けられており、つまり、物理的刺激を用いてそれらの特性をプローブすることによって、それぞれを一意的に識別し、検証することができる。
高いレベルでは、PUFは、チャレンジをレスポンスにマッピングする関数と考えることができる。これらのペアは、しばしばチャレンジ‐レスポンス・ペア（challenge-response pair、CRP）と呼ばれる。そのようなマップFを記述するために、次のような記法を使用できる。
F: C→R ∀(C,R)∈ΦF
ここで、C、Rはそれぞれチャレンジおよびレスポンスを表し、ΦFはPUFによって生成できる(C,R)の形のすべてのチャレンジ‐レスポンス・ペアの集合である。
PUFの一意的な物理的特性は、典型的には、シリコン・チップなどの物理的なデバイスの製造に固有のランダムなプロセス変動の結果である。PUFについて典型的に行われる仮定は次のとおりである：
1.どのような形の解析によっても物理系のパラメータを完全に決定することは困難である；
2.物理系のパラメータは、PUFとして使用されるデバイスのもとの製造業者を含め、どの当事者も知らない。この仮定は、しばしば製造業者耐性（manufacturer-resistance）と呼ばれる。
これらの仮定により、PUFは、任意のチャレンジに対して予測不可能であるが決定論的なレスポンスを生成するために使用できる。このチャレンジ‐レスポンス・プロセスは、図3に示されるように、PUFを物理的なブラックボックスのように扱う。
図3は、物理的なブラックボックスとしてモデル化されたPUF 302を示す。提出者103Sは、PUF 302への入力としてチャレンジCを提出し、応答してPUF 302は対応するレスポンスRを生成する。提出者は、PUF 302自体が実装されているデバイスと同じであっても、異なるデバイスであってもよい提出者のコンピュータデバイス（図示せず）などのデバイスから、チャレンジを提出する。
提出者103Sは、目標者またはデバイスの素性にリンクされた期待されるレスポンスの集合を確立するためのセットアップ・フェーズ（例は後述）の一部として、チャレンジ-レスポンス（CR）ペアを生成する当事者でありうる。または、提出者103Sは、生成されたレスポンスが期待されるレスポンスと一致することを検証し、それによりPUF 302を有する目標デバイスまたはPUFを所有する目標者の素性を検証するために、後の検証フェーズにおいてチャレンジを提出する検証者でありうる。
別の例のシナリオでは、提出者103Sは、ブロックチェーン・アプリケーションなどの暗号アプリケーションにおいて（たとえば、ブロックチェーン・トランザクションに署名するために）使用するために、生成されたレスポンスを鍵または鍵を生成するためのシードとして使用することを望む当事者でありうる。
図4は、PUF 302へのインターフェースの例を含むシステムを示す。システムは、プロセッサ402とPUF 302を有する。インターフェースは、メモリに記憶され、プロセッサ402上で動作するように構成されたインターフェース論理404を有する。インターフェース論理404が記憶されるメモリは、一つまたは複数の記憶媒体（たとえば、磁気ディスクやテープなどの磁気媒体、またはROM、EPROM、EEPORM、フラッシュメモリ、SRAM、DRAMなどの電子媒体）を使用する一つまたは複数のメモリ・ユニットを有していてもよい。プロセッサ402は、一つまたは複数の処理ユニット（たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、暗号プロセッサなどのアプリケーション固有またはアクセラレータ・プロセッサ）を有していてもよい。また、インターフェース論理404が、代わりに、部分的または全体的に専用のハードウェア回路、またはPGAやFPGAなどの構成可能または再構成可能な回路で実装できることも除外されない。
提出者103Sは、デバイス（図示せず）を使用して、インターフェース論理404を介してPUF 302にチャレンジCを提出する。提出者103Sが使用するデバイスは、たとえば、コンピュータ・デバイスであってもよく、外部コンピュータ・デバイス、またはプロセッサ402が実装されている同じコンピュータ・デバイスのいずれであってもよい。次いで、PUF 302は、対応するレスポンスRをインターフェース論理404を介して提出者302のデバイスに返す。後により詳細に論じるいくつかの実施形態では、インターフェース論理404は、PUF 302へのアクセスをある種の当事者（たとえば、パスワード、PINまたは生体認証情報などの認識された資格情報を提示できる当事者）のみに制約するアクセス制御論理406を有していてもよい。および／または、プロセッサ402を有するデバイスへの物理的なインターフェースが、たとえば、許諾された人員のみがアクセスできる部屋や複合施設に位置していたり、または鍵のかかった箱やキャビネットに保管されていたりするなどして、制約されていてもよい。しかしながら、代替システムでは、インターフェース論理404は、任意の当事者がチャレンジを照会するために利用可能にされてもよい。
PUFのチャレンジ-レスポンス・プロセスは、選択されたレスポンスからこれらのチャレンジを抽出することによって、擬似ランダムなデータ値の生成を許容する。たとえば、PUFは鍵生成器として、暗号で使用されるランダムな繰り返し可能データを抽出するために使用されることができる。PUF 302は決定論的かつ繰り返し可能な仕方で動作するため、複数の別々の機会に同じチャレンジが与えられると、PUFは同一のレスポンスを与えることに注意されたい。
PUFとして使用できる多数の異なる物理系があり、これらの系を使用したPUFの多くの異なる実装がある。PUFの例解用の例は、気泡を含む光学媒体であり、これは、レーザーによってプローブされると、（i）レーザーの位置および（ii）光学媒体の微小スケールのパラメータによって決定論的に決定される応答回折または「スペックル」パターンを生じる。
1.1. PUFのクラス
1.1.1 弱いPUF: 弱いPUFは、小さなチャレンジ-レスポンス空間をもつことによって特徴付けられ、多くは単一のチャレンジをもつだけである。よって、CRP空間のサイズは｜ΦF｜＝1となる。一般に、弱いPUFのチャレンジ-レスポンス空間は、O(n)のオーダーであると考えられる。ここで、nはPUF内の、制御不能な製造変動の影響を受けるコンポーネントの数である。
弱いPUFの場合は、典型的には、PUFのレスポンスへのアクセスが制約されていることも想定される。これは、弱いPUFによってサービスされるCRPの数が少ないため、敵対者が合理的な時間内にそのようなペアをすべて列挙する可能性があり、そのためPUFの挙動をエミュレートするまたは「なりすます」可能性があるためである。この制約は、弱いPUFの挙動を論じるときに、制約されたチャレンジ‐レスポンス・インターフェース（restricted challenge-response interface）と呼ばれることがある。
これらの特性により、弱いPUFは、暗号アプリケーションにおいて鍵生成器として使用するのに最も自然に適している。この場合、PUFによって生成される1つ（または少数）のCRPは、デバイス上の不揮発性メモリ（NVM）の暗号化のためまたはHMAC対称鍵としての使用のためなど、暗号動作のための秘密鍵として使用されうる。そのような場合、実行される暗号プロセスのセキュリティとPUF自体のセキュリティの両方のために、PUFの応答から導出される鍵は秘密に保たれ、デバイスの所有者のみが知っている必要がある。
弱いPUFの顕著で広く実装されている例は、SRAM PUFである。ここで、「SRAM」という用語は「静的ランダムアクセスメモリ」を指す。SRAM PUFの設計は、SRAMチップの「電源投入された」状態における変動を活用しており、SRAMチップはそれぞれ、チップの電源投入時にチップ内のSRAMセルが「0」状態にあるかまたは「1」状態にあるかの変動により、一意的なフィンガープリントをもつ。
この場合、PUFをプローブする1つの固定モードがあり（すなわち、SRAMチップの電源を入れることによる）、よって単一のCRPしかないため、PUF構築は弱いと見なされる。この場合、唯一の「チャレンジ」はSRAMチップに電力を供給することであり、レスポンスは電源投入された状態から導出される一意的なフィンガープリントである。レスポンスの秘匿性を保証するためのアクセス制御は、SRAM PUFが使用されているデバイスで使用されている既存のメモリ・アクセス制御ポリシーまたは機構、またはデバイスで採用されている代替機構を使用して実装することもできる。
SRAM PUFの場合など、一部のPUF実装の一つの特徴は、同じチャレンジが条件および時間によって変わらない仕方で同じレスポンスを与えることを保証するための、PUFによって生成されるレスポンスにおける誤り訂正の使用である。そのような誤り訂正技術の詳細は当業者には知られている。場合によっては、誤り訂正プロセスは、PUFデバイスが初期に「登録される」ことを要求してもよい。誤り訂正を容易にするために、後でオンデマンドで生成されるレスポンスと組み合わされるヘルパー・データのソースを提供するためである。
1.1.2.強いPUF: 弱いPUFとは対照的に、強いPUFは、利用できる可能なチャレンジ‐レスポンス・ペア（CRペアまたはCRP）の大きな空間をもつことによって特徴付けられる。CRPのこの大きな空間は、敵対者が強いPUFのドメイン内のチャレンジ‐レスポンス・ペアすべてを多項式時間で列挙することが現実的に不可能であると考えられることを意味する。この特性は、強いPUFは一般に、保護されていないチャレンジ‐レスポンス・インターフェースを有していてもよいことを意味する。敵対者がPUFに自由にアクセスできても、弱いPUFの場合のように、PUFの列挙およびなりすましを可能にすることによってセキュリティを損なうことはないためである。このクラスのPUFは、ΦFの大きな部分集合を知っている敵対者の観点からでさえも、予測不可能なレスポンスを生成するとも言われており、これは、強いPUFは大きなドメインをもつ暗号学的ハッシュ関数のように動作することを意味する。
しかしながら、強いPUFには、チャレンジCを提示されたときにPUFによってレスポンスRのみが与えられるべきであり、その過程でPUFの内部稼働や動作に関する他の情報が漏洩されるべきではないという制約がある。この制約は、敵対者がPUFの挙動の土台となる物理系を特徴付けようとして用いうるさまざまな解析攻撃を緩和するためのものである。これらは、文献ではしばしばモデリング攻撃と呼ばれる。
弱いPUFと同様に、一部の強いPUF構築は、デバイスによって生成されるレスポンスの正確さを保証するために誤り訂正技術に依拠することがある。
強いPUFの主な既存の用途は、内在的なチャレンジ-レスポンス機構を使用してシステム認証および識別を容易にすることである。これらの機構は、直接2者間の共有された秘密としてCRPの生成に関わるプロトコルに依拠しており、しばしば、少なくとも一方の当事者が相手の認証トークンとして使用されるべく、事前にCRPのテーブルを生成する必要がある（初期セットアップ）。
強いPUF実装の最初期の例の1つは、光PUFシステムであった。この構築では、PUFは、製造の変動の結果としてランダムに分散された物理的欠陥を含む光学媒体を含み、該欠陥が入射光を散乱する。このPUF構築は、光散乱媒体に向けられたレーザー・ビームによってプローブされることができる。この場合、入射ビームの方向と偏光がチャレンジを形成し、観測された散乱パターンがPUFレスポンスとして取られる。
しかしながら、この強いPUF構築は、測定デバイスがPUFデバイスの残りの部分から分離されており、半導体コンポーネントと直接統合することも困難であるという事実のため、実装するのが複雑である。これは、装置自体に関連するコストと、装置の可搬性の欠如に加えてのことであり、日常的な用途のための有用性が低下する。
その後、これらの問題のいくつかを克服する、調停者PUF（arbiter PUF、APUF）として知られる電気統合された強いPUFが提案されている。この構築は、信号の多重化を利用し、電気コンポーネントにおけるランタイム遅延を活用する。他の多くの強いPUF構築が並行して提案されているが、多くは広汎な使用のための実際的な好適性を欠いており、多くはセキュリティおよび潜在的な攻撃ベクトルに関する関連する弱点をもつ。たとえば、非常に問題の多い潜在的な攻撃は中間者攻撃であり、攻撃者は平文で提出されたチャレンジを傍受し、証明付き計算を偽装することができる。
1.1.3. 制御されたPUF: 制御されたPUF（controlled PUF、CPUF）として知られる第3のクラスのPUFは、既存の強いPUF構築を改善するが、構成要素ブロックとして使用する。これらのPUFは強いPUFを取り、PUFへのアクセスを制約する追加の制御論理を適用する。これにより、保護されていないチャレンジ‐レスポンス・インターフェースをもつ可能性がある非制御の強いPUFと区別される。
図4に示されるように、今やより大きなPUFデバイスの一部となっているPUFに適用される制御論理406は、PUF 302自体へのアクセスを仲介しうる。これは、制御論理コンポーネント406が、PUFにどのチャレンジが提示されるかを制約したり、その後のレスポンスがユーザーにどのように明かされるかを制御したりできることを意味する。
CPUF構築では、好ましくは、制御論理コンポーネント406は強いPUFコンポーネント内に埋め込まれるか、または強いPUFコンポーネントによって包み込まれるべきである。CPUFのある定義によると、分離不可能な仕方でPUFに物理的にリンクされているアルゴリズム（つまり、アルゴリズムを迂回しようとする試みは、PUFの破壊につながる）を介してのみアクセスできる場合、PUFは制御されると言われる。この埋め込みにより、制御論理のプローブはかなり難しくなるはずである。
これにより、PUFコンポーネントと制御論理コンポーネントの間に相互に有益な関係が確立され、それぞれが相手に対するあるタイプの攻撃を緩和するようになる。つまり、PUFデバイス自体の内部に制御論理をカプセル化することで、物理的または侵襲的な攻撃から制御論理を保護する。そのような攻撃は、PUFコンポーネントに修復不可能な損傷を与え、その応答を変更するからである。一方、制御論理は、CRPまたはPUF自体の基礎となる内部の物理系に関するその他の情報を抽出しようとするプロトコル・レベルの攻撃からPUFコンポーネントを自然に保護する。
CPUFの用途は強いPUFとほぼ同じだが、より堅牢な仕方で達成できる。特に、証明付き計算と実行の証明（certified computations and proof of execution）は、上記で概説した諸プロトコルを用いて簡単に達成できる。
強い調停者PUF（APUF）の設計を拡張したCPUFの初期の例は、制御論理とAPUFが異なるタイプの攻撃から互いを相互に保護するように、既に説明した仕方で制御論理がAPUF自体と絡み合わされることを要求していた。制御されたAPUF設計は、システムの過渡的な応答を組み込むことによって、集積回路（IC）からの単一の静的応答からCRPの大きな集合を生成する。
制御されたPUFのもう1つの既知の例は、PUF-FSM構築である。これは、APUFコンポーネント自体のチャレンジ‐レスポンス・インターフェースへのアクセスを制約する制御論理として機能する有限状態マシン（finite state machine、FSM）との関連で強いPUF（実際にはAPUF）を有する。
1.2. ディスカッション
1.2.1. 実用性（practicality）: 実用的かつ軽量でありながら、標準的な相補型金属‐酸化物半導体（CMOS）コンポーネントと統合できる強いPUFを製造することは、非常に困難であることが文献で認められている。対照的に、SRAM PUFのような弱いPUFは製造コストが低く、トリビアルな仕方で集積回路アーキテクチャーと組み合わせることができる。
1.2.2. PUFに対する攻撃: いくつかの異なる攻撃が提案され、研究されており、異なる攻撃が特定のPUF構築またはクラスを標的にすることがある。最も広く知られている攻撃タイプのいくつかを次に挙げる。
・MITM攻撃―これらの攻撃は、制御されていない強いPUFを標的としており、特に証明付き計算（certified computation）のために使用されるとき、敵対者がPUFの応答を偽装するまたはなりすますために平文で行われるチャレンジを傍受しうる。
・モデリング攻撃―これらの攻撃は、APUFなどの多くの強いPUF構築に対する脆弱性を証明している。
・選択チャレンジ攻撃―これらの攻撃は強いPUFにも影響し、CPUFアーキテクチャーに移行する動機の一部となっている。
また、さまざまなPUF設計には他の問題もある。たとえば、場合によっては一意性が欠如しているため、問題のPUFシステムのセキュリティを損なう活用が発生している。
1.2.3 セキュリティ・モデル: PUF構築のセキュリティ・モデルは、いくつかの類似点を共有する傾向がある。たとえば、それらのCRPのもとになるランダムなプロセスまたは製造上の変動が製造業者耐性があるという仮定や、解析手段によってPUFの物理系を特徴付けることが困難であるという仮定などである。ただし、上記の3つの主要なPUFクラスについてのセキュリティ・モデルには、いくつかの相違点もある。
・弱いPUF―弱いPUFのセキュリティは、そのCRPが秘密に保たれるという想定に依拠しており、そうでない場合はデバイスを列挙して偽装することができる。これは、暗号学的動作のためにエントロピーのソースを提供し、そのエントロピーの記憶を安全にするために弱いPUFが使用できるが、その過程において実際のCRPレスポンス・データ自体は公には明らかにされないことを意味する。
・強いPUF―強いPUFのセキュリティは、そのCRP空間がチャレンジ・ビット数に関して指数関数的になる傾向があるという事実に依存しており、よって、空間全体の列挙は合理的な時間枠では実際上実行不能である。これは、強いPUFのCRPレスポンスが、弱いPUFの場合とは異なり、デバイスによって明らかにされることができることを意味する。
・制御されたPUF―制御されたPUFのセキュリティは、プロトコル・レベルの攻撃から保護する制御論理と、物理的な攻撃から保護するPUF自体の組み合わせによって決定される。
弱いPUFと区別する、強いPUFの2つの特性は次のとおりである。第一に、強いPUFはCRPの大きな集合をもつ。これは、強いPUFは大きなチャレンジ空間ΦFをもち、弱いPUFは典型的には、1つ（または少数）のチャレンジしか利用可能でないことを意味する。さらに、強いPUFは、任意のおよびすべての既知のCRPに関して予測不可能であると見なされる。つまり、任意の数のCRPを知っていても、新しいチャレンジのレスポンスを予測する上で何の利点もない。
第二に、強いPUFは、保護されていないチャレンジ-レスポンス・インターフェースをもつことができる。所与の強いPUFは、チャレンジ-レスポンス・インターフェースへのアクセスを制約するためのアクセス制御論理を必要としないという想定がされる。これは、PUFへの物理的なアクセスをもつ任意の当事者が、PUFまたはその物理的特性に関する追加情報を明らかにすることなく、任意にチャレンジを適用し、レスポンスを得ることができることを意味する。
制御されたPUFは、保護されたチャレンジ-レスポンス・インターフェースを有するが、強いPUFのような大きなチャレンジ-レスポンス空間も有する。
2. 拡大PUF（ePUF）
下記は、ベースPUF 302の所与のCRペアから複数の二次CRペアを生成することにより、PUFのチャレンジ‐レスポンス（CR）空間を拡大するシステムおよび方法を開示する。これは、ここでは「拡大PUF（expanded PUF）」または「ePUF」と呼ばれることがある。この発想は、たとえば、典型的な強いPUF機構の複雑さや非実用性（たとえば、光PUFはレーザー、光媒体、センサーを必要とする）なしに、1つまたは限られた数の内在的CRペアのみをもつ弱いPUFのチャレンジ-レスポンス空間を拡大するために使用できる。しかしながら、原則として、開示された技術は、より一般に、弱い、強い、制御されているなどにかかわらず、任意のベースPUFのCRペアの数を拡大するため、または、難読化もしくは再利用性などの他の目的のために任意のPUFのCRペアを変換するために使用できる。
図5Aは、ここに開示された実施形態に従った拡大PUF（ePUF）500を示す。ePUF 500は、たとえば従来の弱いPUFでありうる構成要素ベースPUF 302を含む。ePUF 500はさらに、変換関数502、たとえば暗号学的ハッシュ関数（たとえばSHA256など）のようなハッシュ関数を含む。ePUF 500はまた、図4に関連して議論されているインターフェース論理404と同様だが、追加のインターフェース機能をもっていてもよいインターフェース論理404’を含む。インターフェース論理404’と変換関数502は、たとえば、メモリに格納され、プロセッサ402（図4に示されるようなものだが、インターフェース404’の追加機能および変換関数502を実行する）上で動作するように構成されたソフトウェア、たとえば埋め込まれたファームウェアにおいて実装されてもよい。インターフェース機能404’と変換論理504が格納されるメモリは、一つまたは複数の記憶媒体（たとえば、磁気ディスクやテープなどの磁気媒体、またはROM、EPROM、EEPORM、フラッシュメモリ、SRAM、DRAM、ヒューズ・ラッチなどの電子媒体）を使用する一つまたは複数のメモリ・ユニットを有していてもよい。それらが実行されるプロセッサは、一つまたは複数の処理ユニット（たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、暗号プロセッサなどのアプリケーション固有またはアクセラレータ・プロセッサ）を有していてもよい。また、インターフェース論理404'および／または変換関数502が、代わりに、部分的または全体的に専用のハードウェア回路、またはPGAやFPGAなどの構成可能または再構成可能な回路で実装できることも除外されない。
インターフェース論理404’は、変換関数502に動作上結合され、任意的に、ベースPUF 302にも結合される。ベースPUF 302は、変換関数に動作上結合される。インターフェース論理404’は、提出者103Sのデバイス（図5Aには示されていない）から入力を受け取り、それに出力を提供するように構成されている。提出者のデバイスはたとえばコンピュータ・デバイスであり、ePUF 500が実装されているのと同じデバイスまたは外部デバイスでありうる。提出者103Sは、ePUF 500を使用してセットアップを実行し、将来の参照のために素性にリンクされるチャレンジおよび期待されるレスポンスの集合を生成する当事者であってもよく、または、後に該PUFを使用して、生成されたレスポンスが以前に確立された期待されるレスポンスと一致するかどうかを検証する検証者であってもよい（または、検証者に提供するレスポンスを生成する被チャレンジ者）。別の例示的応用では、提出者103Sは、ePUF 500を使用して、鍵としてまたは鍵を生成するためのシードとして使用するためのレスポンスを生成してもよい。たとえば、これは、メッセージを暗号化するまたはメッセージに署名する、たとえばブロックチェーン・トランザクションの一部に署名するための暗号鍵として使用できる。
ベースPUF 302は、入力として「一次」チャレンジCwを受信することに対応して、出力として「一次」レスポンスRwを生成するように動作可能である。ここでいう「一次」チャレンジ‐レスポンス（CR）ペアは、ベースとなる構成要素PUF 302のベースまたは「ネイティブ」の（すなわち、内在的な）CRペアを指す。いくつかの実施形態では、ベースPUF 302は、弱いPUFのように、単一のチャレンジCwに応答して単一のベース（すなわち、一次）レスポンスCwのみを生成することができるものでもよい。
動作中、インターフェース論理404’は、少なくとも「二次」チャレンジCiを含むチャレンジ・データ（チャレンジ入力）を提出者103Sのデバイスから受信する。また、一次（ベース）チャレンジCwは、一次（ベース）レスポンスRwを生成するために、ベースPUF 302に入力される。実施形態では、提出者103Sは、ePUF 500に入力されるチャレンジ・データにベース・チャレンジCwを含めることを要求され、インターフェース論理404'は、一次レスポンスRwを生成するために、これをベースPUF 302にルーティングする。しかしながら、他の実施形態では、一次チャレンジCwがメモリ、ヒューズ・ラッチまたは専用回路などの内部ソースからベースPUF 302に入力されることは排除されない。いずれにせよ、変換関数502は、入力として、a）提出者からの入力チャレンジ・データにおいて受信される二次チャレンジCi、およびb）ベースPUF 302によって生成される一次レスポンスRwを受信するように構成される。変換関数502は、これらの組み合わせを、変換関数502に入力されたCiおよびRwのその特定の組み合わせに対応する一意的なそれぞれの「二次」レスポンスRiに、決定論的にマッピングするように構成された関数である。二次チャレンジ・レスポンス・ペアがここで「二次」と呼ばれるのは、部分的に一次レスポンスRwに基づいて生成され、一次（ベース）CRペアの上に階層化されるという意味においてである。これらは、「拡大層」または「補足」チャレンジおよびレスポンスと呼ぶこともできる。
実施形態では、変換関数502はハッシュ関数、たとえばSHAまたはDSAハッシュ関数のような暗号学的ハッシュ関数を含む。ハッシュ関数の使用方法には少なくとも二つの異なる方法がある。一つ目では、変換関数502は原像のハッシュを含み、原像は受信された二次チャレンジCiと生成された一次レスポンスの組み合わせ（たとえば連結）を含む。すなわち、Ri＝H(Ci||Rw)である。または、より一般的には、原像は他の要素も含むことができ、および／または連結以外の別の形の組み合わせも含むことができる。
第2の、代替的なアプローチでは、変換関数502は原像のハッシュを含み、原像は受信された二次チャレンジを含み、ハッシュ関数は生成された一次レスポンスを用いて初期化される。すなわち、Ri＝H(Ci)である。ここでHはRwによって初期化される。あるいはまた、より一般的には、Hの原像は、少なくともCiを含む限り、他の要素も含むことができる。Rwによって初期化されることは、ハッシュ関数Hによって定義される、原像の出力へのマッピング自体がRwに依存することを意味する。前の事例では、Hによって引き起こされる原像の出力へのマッピングはRwに依存せず、むしろ原像がRwに依存する。すなわち、前の段落では、原像はRwが依存しており、この段落ではHのみがRwに依存する。
より一般的には、原則として、ePUF 500によって受け入れられるドメイン内の可能な各Ciについて、CiとRwの組み合わせをRiのそれぞれの値に決定論的かつ一意的にマッピングする限り、任意の関数が使用できる。
二次チャレンジCiは、多くの異なる可能な値のうちの任意のものを取ることができ、変換関数502は、それらを、特定の受信された二次チャレンジCiの値と一次レスポンスRwの値に基づいて、二次レスポンスRiのそれぞれの値にマップする。よって、ePUF 502は、所与の一次（ベース）CRペアのCR空間を複数の二次CRペアに拡大することができる。諸実施形態では、Ciは使用される変数によってサポートされる値の範囲内の任意の値を取ることができる（たとえば、32ビット整数の場合、2^32個の値のうちの任意のものを取ることができる）。
いくつかの実施形態では、ePUF 500は、図5Bに示されるように、代替的な動作モードで動作することができてもよい。この場合、インターフェース論理404’は、入力チャレンジ・データが一次チャレンジCwのみを含むことを検出する。これに応じて、受信されたCwの値をベースPUF 302にルーティングし、結果として得られた一次レスポンスRwを提出者103Sのデバイスにルーティングする。つまり、この実施形態では、ePUF 500は「レガシー」または「非拡大」モードでも動作可能である。
任意的に、用途に依存して、インターフェース論理404'は、許諾された当事者にマップされていると認識する資格情報（たとえば、パスワード、PINまたは生体認証入力）を提示できる当事者にのみアクセスを承認するなどによって、限られた数の可能な提出者103Sだけにアクセスを制約するアクセス制御論理406を含んでいてもよい。この場合、ePUF 500はCPUFの一形態と考えることができる。あるいはまた、ePUF 500への物理的インターフェースは、ePUF 500を含むデバイスを、限られた一組の当事者のみがアクセスを許されている部屋または敷地内に保管すること、または、ロックされたボックス、キャビネット、または部屋に保管したりすることなどによって、法的に、または物理的に保護されることができる。この場合、ePUF 500は、拡大された弱いPUFの一種と考えることができる。
PUFへのインターフェースに対するそのような物理的制約に対する代替または追加として、一次チャレンジへのアクセスを制約することによって、アクセスが制約されてもよい。たとえば、目標者103T（後述する「アリス」）がCwを知っている唯一の当事者であってもよい。
ただし、別の代替として、インターフェース論理404'へのアクセスは制約されなくてもよい。たとえば、任意の当事者がインターネット経由で自由に照会できる。この場合、ePUF 500は、弱いベースPUF機構を拡大して作成された一種の強いPUF 502と考えることができる。
図5Aに示される構成は、本願で拡大PUF（ePUF）と呼ばれる、新しいハイブリッド・クラスのPUFデバイスを提供する。これは、後で示すような多くの用途のための枠組みとして一般的に使用されうる。
ePUFは、図5Aに示されるように、連携する次の3つのモジュールを有する物理デバイスまたはシステムとして定義されうる：内在的に弱いPUFのようなベースPUF 302；暗号ハッシュ関数などの変換関数502；インターフェース論理モジュール404’。前述したように、ePUF 500は、暗号学的ハッシュ関数などの変換関数404’を導入することによって、通常のPUF 302に対して「拡大」されうる。それは、ベースの弱いPUF 302についての一意的なチャレンジ空間ΦFのサイズを、｜ΦF｜～1から、｜ΦF｜≫1に増大させるからである。サイズは、従来に代わり、弱いPUFの物理系ではなく、ハッシュ関数の選択によって制限される。
強いPUFの大きなCRP空間と弱いPUFの実用性を組み合わせたシステムを実現するという発想自体は、以前にも追究されていた。複数のFPGAベースの弱いPUFを組み合わせた動作において使用し、強いPUFの性格をもつシステムを作ることが知られている。ここでの意図は、部分的に、ベースの弱いPUFのCRP空間を「拡大」することである。しかしながら、この性質の既存の構築は実際上は限られている。前述のFPGA設計の場合、システムはFPGA上に構築されなければならず、依然として比較的低いCRP空間（～210）の制限を受ける。
ここで開示されるePUF設計は、既存の弱いPUF 302に対して、インターフェース論理コンポーネント404’と暗号学的ハッシュ関数（または他のそのような変換関数）502を追加するだけで済むという点で、きわめて軽量に設計されている。たとえば、SRAM PUFが広く使用されている弱いPUF 302として選択された場合、残りの二つのモジュール404’、502の追加は、たとえばソフトウェア（たとえばファームウェア）における小さなアルゴリズムまたは比較的単純なハードウェア回路として実装され、著しいオーバーヘッドを生じることはないはずである。さらに、ePUF 500の可能な出力の空間は、選択されたハッシュまたは変換関数502の範囲に拡張され、これは上記よりもかなり大きい。たとえば、SHA-256ハッシュ関数が選択された場合、可能な出力（したがって、CRP）の空間はすぐに2256－1に増加し、ハッシュ関数モジュール自体を埋め込む以上にハードウェアのオーバーヘッドをスケールする必要はない。
図5Aは、拡大PUF（ePUF）500のための概略的な設計を示している。暗号学的ハッシュ関数が使用される実施形態は、ePUF 500がそのCRPが予測不可能であるという特性をもつことも意味し、これは強いPUFシステムについても当てはまる。
ePUFデバイスの制御論理要素406は、この構築において一般化されてもよい。制御論理406は、たとえば、用途にとって適切であれば、SRAM PUFと同様に、単に物理セキュリティとして実装されてもよい。
あるいはまた、制御論理モジュール406は、CPUFで使用されるものと同様のソフトウェア制御モジュールとして実装されてもよい。ここで、それは実際には、前述のカプセル化の相互のセキュリティの利点を提供するために、PUFデバイス自体に埋め込まれる。ただし、特にePUFの設計をCPUFの設計から区別するポイントは、制御論理をこのように実装する厳密な要件がないことである。
制御モジュール406への侵襲的な攻撃が、ePUF設計における弱いPUFコンポーネント302の挙動を必然的に変更することは、必ずしも想定される必要はない。代わりに、この要素の実装はケースバイケースで選択されうる。
2.1. ePUFsについてのチャレンジおよびレスポンス
ePUFに対応するチャレンジ‐レスポンス・ペア(C,R)∈ΦFの集合は、次のように定義されうる：
ΦF＝{(Cw,Rw),(C1,R1),(C2,R2),…,(CN,RN)},
F: Ci→Ri, ∀i∈(1,N)
Fw: Cw→Rw
ここで、(Cw,Rw)は弱いPUF 302のベースとなるチャレンジおよびレスポンスに対応する特権CRPであり、マップFwは弱いPUFの一意的な物理的特性によって定義される。ペア(Cw,Rw)は、ここではePUFのベース・ペアまたは一次ペアと呼ばれることがある。マップFは逆に、ePUFのために選択された暗号学的ハッシュ関数によって定義される。図5のA～Bは、ePUF 500からの応答の抽出を示しており、（図5のB）ではチャレンジはCwのみであり、（図5のA）ではチャレンジはCiも含む。
拡大PUFのいくつかの実施形態では、図5のAに示されるように、すべてのチャレンジCi、i∈{1,2,…,N}にはベース・チャレンジCWが伴う必要があり、ベース・レスポンスRwは他のすべてのレスポンスRiを生成するプロセスに組み込まれる。
ePUFを使用して汎用CRPを生成するための図5のAに示されているプロセスは、ベース・チャレンジ‐レスポンス・ペア(Cw,Rw)を、このベースとなる秘密ペアを他の任意のチャレンジCiに適用することによってこのベースとなる秘密ペアを拡張することによって、使用するように設計されている。ePUFからCRPを生成するために使用されるアルゴリズムは、それが決定論的な仕方でベース・ペア(Cw,Rw)を使用することを条件として、特定の用途に合わせて調整されうる。getResponse()と記される、そのようなアルゴリズムの簡単な例は、次のように書ける。
getResponse():
入力: Challenge〔チャレンジ〕
1. ユーザー／クライアントからchallengeを取得
2. チェック challenge==Cw?
i. そうである場合：
1. Cwを用いて弱いPUFモジュールをプローブしてRwを得る
2. Response〔レスポンス〕←Rwと置く
ii. そうでない場合：
1. ChallengeをCwおよびCiコンポーネントに分離
2. Cwを用いて弱いPUFモジュールをプローブしてRwを得る
3. CiおよびRwをハッシュ関数モジュールに送る
4. hash(Ci,Rw,H)を計算
5. Response←hash(Ci,Rw,H)と置く
3. Responseを返す
出力: Response
関数hash(Ci,Rw,H)は、暗号学的ハッシュ関数Hを使用してハッシュ・ダイジェストを計算するために使用される汎用関数である。関数hash()は、単純な場合では単にH(Ci||Rw)を計算するなどにより、いくつかの仕方で実装でき、あるいは負担の重い計算H(Ci)Rwによって実装されることもできる（ここでは値Rwはハッシュ関数Hの初期ベクトルとして使用されている）。いずれにせよ、hash()の出力はCiとRwの両方に依存する。
図5のAおよびBの図は、ePUF 500が、任意的に制御論理モジュール406を含むインターフェース論理404’を備えていてもよいことを示している。実施形態では、レスポンスを生成する際に取る2つの可能な経路があり、図5のBの経路は、チャレンジが単にCwである場合に使用され、図5のAの経路は、チャレンジがCwが伴っている新しい値Ciである場合に使用される。これは決定論的である。
開示されたePUF設計は、次の利点および／またはその他のいずれかを提供するために使用されうる。
・選択されたハッシュ関数のドメインおよび範囲によって定義される大きなCRP空間。
・PUF自体から制御論理を分離する柔軟性。
・弱いPUFのセキュリティ・プリミティブ。
これは、ユーザーがePUFデバイスをCPUFデバイスと同様に使用できることを意味するが、PUFへの制御されたアクセスは、（I）弱いPUFのベースCRP (Cw,Rw)を安全に記憶することと、（II）PUFデバイスへの物理的アクセスを意図されたユーザーのみに制約することの両方を含む。
このモデルでは、ベース・ペア(Cw,Rw)はマスターキーのように機能し、そこから(Ci,Ri)の形のきわめて多数の他のCRPが導出されることができ、Ciは外部またはサードパーティーによって提出されてもよい。
2.2. ePUFの用途
ePUFデバイスの考えられる用途（使用事例）は、大まかには少なくとも2つの主要なカテゴリーに分類できる。
1. 素性を活動または計算動作にリンクすること；および
2. 暗号学的演算のための鍵生成器として機能すること。
用途（1）は既存の強いPUFによって最も普通に実装されるものであり、（2）は既存の弱いPUFによって最も普通に実装されるものである。ePUF構築がそれぞれの特性を組み合わせるという事実は、ePUFがいずれの用途にも等しく好適であるとして扱われてもよいことを意味する。用途（1）では、利点は、一般に、ほとんどの強いPUFまたは制御されたPUFよりも、ePUFを使用して、実際上、はるかに簡単にそのような用途を実装しうるということである。
3. 素性リンケージ・システム
このセクションでは、PUFデバイスに人間またはマシンの素性をリンクするための一般的なフレームワークが開示される。
諸実施形態は、拡大PUF（ePUF）を使用してもよい。ここでの意図は、堅牢でありながら高度に一般化された柔軟な素性システム〔アイデンティティ・システム〕を提供するPUFアーキテクチャーを定式化することである。そのようなシステムは、多くの異なる使用事例に転用できる。この構築において捕捉しようと目指している特性は次のとおりである：
・強いPUFに匹敵する大きなCRP空間；
・弱いPUFに匹敵する実用性；
・CPUFよりも柔軟な制御論理。
ePUF設計は、一連の素性確立プロトコルにおいて使用されるPUFのための基本モデルとして使用できる。諸実施形態は、プロセスにおけるエンドユーザーまたはマシンの独立性を許容しうる。ePUFを使用するために転用されることもできる既存の方式が、セットアップ中に信頼されるサードパーティーがPUFデバイスに直接アクセスことに依拠しているところ、ePUFベースの提案されたシステムは、セットアップ中にサードパーティーが該デバイスにローカルにまたは直接アクセスする必要なしに、PUFデバイスのエンドユーザーが代わりに素性を確立し、そこから先の認証に参加することを許容しうる。
いくつかの実装は、公開ブロックチェーンを導入することによって、これらの素性リンケージ・プロトコルの堅牢性を改善し、かかるプロトコルをさらに拡張することができる。ここで採用されうる2つの概念は、（A）改竄防止のCRP管理システムとしてブロックチェーンを使用すること、および（B）素性リンケージ・プロトコルにおいて使用される要求‐応答メッセージを仲介するためのタイムスタンピング・サービスとしてブロックチェーン・ネットワークを使用し、効率的な失効システムを提供することである。
図6は、本願に開示される実施形態による、素性リンケージおよび検証のための例示的なシステムを示している。図7は対応する方法を示す。
システムは、PUFモジュール603、目標者103Tのコンピュータ設備102T、レスポンス・データ・ストア601を有する。PUFモジュール603は、図5のAおよびBに関連して前述したようにePUF 500を有するか、あるいはまた、図3および図4に関連して前述したように、従来のPUF 302またはPUFに従来のインターフェース論理404を加えたものを有するだけであってもよい。レスポンス・データ・ストア601は、サードパーティー・コンピュータ設備602の一部であって、信頼されるサードパーティーによって管理されてもよく、あるいは、その代わりにブロックチェーンなどの分散式のピアツーピア記憶媒体であってもよい。サードパーティー設備602は、たとえば、一つまたは複数の地理的サイトに位置する一つまたは複数のサーバー・ユニットを有するサーバー設備を含んでいてもよい（クラウド・ストレージ技術自体は、当技術分野で知られている）。システムは、さらに検証者103Vのコンピュータ設備102Vを含んでいてもよく、あるいは、いくつかの代替的な場合には、検証者はPUFモジュール603、目標者のコンピュータ設備102T、またはサードパーティーのコンピュータ設備602と直接対話してもよい。
検証者103V、目標者103T、またはサードパーティーのいずれであれユーザーまたは当事者103などのアクションへのここでの言及は、その当事者がその当事者のコンピュータ設備102を通じて行動している可能性をカバーする。簡潔のため、これは必ずしも毎回明示的に述べられないが、暗黙的にカバーされていると理解される。これは、A）アクションが、その当事者によるコンピュータ設備への手動のユーザー入力によって、または該入力の制御のもとでトリガーされること、またはB）アクションがその当事者に代わってコンピュータ設備によって自動的に実行されることの両方をカバーする（当事者があるアクションを実行すると言うことは、必ずしも、その当事者の人間のユーザーがそのアクションを手動で起こさせることを意味するのではなく、その代わり、その当事者の設備がその当事者に代わって自律的にアクションを実行することを意味する可能性がある）。疑いを避けるために、当事者は、単一の個人またはグループまたは人々または組織、たとえば、会社、慈善団体、政府機関、地方自治体または学術機関を指しうることにも注意されたい。
目標者103Tのコンピュータ設備102Tは、レスポンス・データ・ストア601に（たとえば、サードパーティー設備602への接続によって）動作上接続されてもよい。検証者103Vのコンピュータ設備102Vは、レスポンス・データ・ストア601に（たとえば、サードパーティー設備602への接続によって）動作上接続されてもよい。目標者103Tのコンピュータ設備102Tは、検証者103Vのコンピュータ設備102Vに動作上接続されてもよい。これらの接続のいずれも、一つまたは複数のネットワーク、たとえばインターネットや携帯電話ネットワークなどの一つまたは複数の広域ネットワークを介して形成されてもよい。諸実施形態において、これらの接続のいずれも、たとえば問題の2当事者間で共有される共有秘密に基づいて確立される、それぞれの安全なチャネルを介して形成されてもよい。本稿において、2者〔2当事者〕がチャレンジを送信するまたはレスポンスを受信するなどによって何らかの仕方で通信すると言われる場合は常に、これらの通信がそれぞれのコンピュータ設備（102V、102T;102T、602;または102V、602）の間の何らかの好適な直接的またはネットワーク接続を介して実行されうる可能性をカバーしていることが理解される。簡潔のために、これは必ずしも毎回明示的に述べられないが、暗黙的にカバーされていると理解される。
目標者103Tは、PUFモジュール603に基づいて素性が検証される当事者、またはPUFモジュール603に基づいて検証されるデバイスを所有しているか、または他の仕方で該デバイスについて責任をもっているか、または該デバイスに関連付けられている当事者である。検証者103Vは、検証を実行する当事者である。複数の検証者103Vがあってもよい（そのそれぞれがそれぞれのコンピュータ設備102Vを通じて行動しうる）が、図解の簡単のため、図6には1つだけが示されている。PUFモジュール603は、目標者103Tが所有していてもよい。それは、目標者のコンピュータ設備103Tに組み込まれていてもよく、あるいはたとえば周辺機器として、またはローカルネットワーク経由でそれに接続されていてもよく、または組み合わせでもよい（たとえば、インターフェース論理404/404'はコンピュータ設備103T上に実装されることができ、PUF 302は外部の周辺機器であることができる）。あるいはまた、PUFモジュール603は信頼されるサードパーティーが所有していてもよい。それは、サードパーティーのコンピュータ設備602に組み込まれていてもよく、あるいはたとえば周辺機器として、またはローカルネットワーク経由でそれに接続されていてもよく、または組み合わせでもよい（たとえば、インターフェース論理404/404'はサードパーティーのコンピュータ設備602上に実装されることができ、PUF 302は外部の周辺機器であることができる）。
一般に、目標者103T、検証者103Vまたはサードパーティーのうちの任意のものが、図3、図4、および図5に関連して前述した提出者の役割を果たすことができる。目標者103T、検証者103Vまたはサードパーティーのうちの任意のものが、提出者の役割を果たしてもよく、またはPUFモジュール603を使用して一つまたは複数のCRペアの集合を確立し、それらを後の検証フェーズで使用するために目標者103Tの素性にリンクするセットアップ者の役割を果たしてもよい。いくつかの具体的な例示的なシナリオが、後に詳しく論じられる。
レスポンス・データ・ストア601は、セットアップ・フェーズにおいてPUFモジュール603によって生成されたレスポンス・データを記憶する。データ・ストア601は、このレスポンス・データを、目標者103Tまたは目標者103Tのデバイスでありうる目標の素性の証拠と関連付けて記憶する。検証者103Vはレスポンス・データ・ストア601へのアクセスをもち、後刻、検証フェーズの間に、これを使用して、目標の素性を検証できる。これを行うために、検証者103Vは、セットアップ・フェーズにおいて使用されたチャレンジの集合に以前含まれていたチャレンジCiに対するレスポンスRiを生成するよう目標にチャレンジする。目標が、レスポンス・データ・ストア601に記憶されているものに従って期待されるレスポンスを生成できる場合、これは目標がPUFモジュール603を所有しているまたは制御していることの証拠となり、よって、セットアップ・フェーズにおいて素性が捕捉された同じ当事者であると想定されうる。
代替的な変形では、レスポンス・データ・ストア601は、たとえばレスポンスをシードとして使用して、セットアップ・フェーズにおいて生成されたレスポンス（単数または複数）に基づいて生成された、一つまたは複数のそれぞれの公開鍵‐秘密鍵ペアのうちの一つまたは複数の公開鍵を記憶しうる。目標が後に秘密鍵のいずれかを使用してあるメッセージ（たとえば、文書またはブロックチェーン・トランザクション）に署名する場合、検証者はレスポンス・データ・ストア601から対応する公開鍵を使用して署名を検証できる。そのような変形では、「レスポンス・データ」という用語は、必ずしもレスポンスRiの明示的な値や証跡ではなく、レスポンスRiから導出されたデータをカバーする、より広い意味で使用されていることに注意されたい。
レスポンス・データ・ストア601は、公衆にアクセス可能であってもよく、またはアクセスは少なくとも一の検証者103Vを含む一または複数の当事者の限定された集合のみに制約されてもよい。それは、サードパーティー・システム602に、またはピアツーピア方式でホストされてもよく、あるいはまた、目標者103Tのコンピュータ設備102Tまたは検証者103Vのコンピュータ設備102Vにおいて実装されてもよい。
図7を参照すると、この方法はセットアップ・フェーズ702と検証フェーズ704の2つのフェーズを含む。セットアップ・フェーズでは、ステップ710で、セットアップ当事者として機能する目標者103Tまたはサードパーティーのいずれかが、PUFモジュール603に一つまたは複数のチャレンジCi（i＝1…n、ここで、n≧1）の集合を提出する。これらは、ePUF 500が使用される場合における二次チャレンジである。目標者103TがPUFモジュール603を所有しており、セットアップを実行している場合、チャレンジCiは目標者103Tによって生成されるか、またはサードパーティー・システム602または検証者103Vから受信されることができる。サードパーティーがPUFモジュール603を所有しており、セットアップを実行している場合、チャレンジはサードパーティー・システム602によって生成されるか、または目標者103Tまたは検証者103Vから受信されることができる。いずれにせよ、応答して、PUFモジュール603はPUF 302/500に基づいて対応するレスポンスRiの集合を生成する。これらは、ePUF 500の場合における二次レスポンスである。このようにして、本方法は、CRペアの集合{Ci,Ri}を生成する。
諸実施形態において、PUFモジュール903へのアクセスは、目標者103T（およびもし異なる当事者であれば設定者）のみがレスポンスRiへのアクセスを得られるように制約される。これは、パスワード、PIN、生体認証データなどの認識された資格情報を提示できる当事者にのみアクセスを承認しうるアクセス制御論理404または404’によって達成できる。および／または、PUFモジュール603への物理的なインターフェースへのアクセスは、該PUFモジュールをロックされた容器、キャビネット、または部屋に保管することなどによって、物理的に保護されうる；または、ある種の人員のみがアクセスを許されている部屋または複合施設にPUFモジュール603を保管することなどにより、法的に保護されてもよい。別の代替または追加の制約として、ePUF 501の場合、一次チャレンジCwの知識は、目標者103T（および諸実施形態では、別のセットアップ当事者として機能する信頼されるサードパーティー）のみがCwを知るように制約されてもよい。
ステップ720では、この方法は、レスポンス・データ・ストア601にレスポンス・データを記憶することを含む。諸実施形態において、記憶されたレスポンス・データは、生成された諸CRペア{Ci,Ri}のレコードを含む。各CRペアのレコードは、そのペアの対応するチャレンジCiを示す仕方で格納されたそれぞれのレスポンスRiのレコードを含む。諸実施形態において、各レスポンスRiの格納されたレコードは、そのレスポンスの明示的な値、すなわちRiの実際の値を含み、この値は、レコードを読むことができる検証者103Vに対して明示的に開示される。値は、平文で格納されてもよく、あるいは検証者が値を解読するための解読鍵をもっている場合は暗号化されてもよいが、それでも、格納された値は、検証者103Vに明示的に開示されるという意味で、本稿での目的のためには、明示的な値であると言われる。あるいはまた、レスポンスのレコードは、Riの決定論的変換を含む、レスポンスRiの「証跡」を含むこともできる。例は、ハッシュH(Ri)またはダブルハッシュH2(Ri)の値を格納することであろう。これにより、検証者は、レスポンスR'iの値がストアに記録された値と同じかどうかを、R’iに適用される同じ変換（たとえば、H(R’i)またはH2(R’i)）が前記証跡と一致するかどうかを検査することによって、検証できる。これは、レスポンスRiの実際の値が開示されないという利点がある。したがって、本方法のこの変形は、ストア601がブロックチェーンなどの公開の媒体である場合に特に有用でありうる。ただし、暗号化はもう一つの可能性であろう。
レスポンス・データが暗号化された形式で記憶されている場合、各レスポンス・データ（たとえば、各CRペア）は個別に暗号化されてもよく、解読するにはそれぞれ異なる解読鍵が必要になる。あるいはまた、レスポンス・データの部分集合または全体集合（たとえば所与の目標者103TについてのすべてのCRペア）が一緒に暗号化されてもよく、その場合、全部が、同じ鍵を用いてグループとして一緒に解読可能になる。
レスポンス・データ、たとえばCRペアは、目標の素性の証拠と関連付けてレスポンス・データ・ストア601に記憶される。たとえば、目標者103Tは、セットアップの一部として、パスポートなどの識別情報を一つまたは複数生成するように要求されてもよい。レスポンス・データに関連付けてレスポンス・データ・ストア601に保持されている証拠は、レスポンス・データに関連付けて明示的に記憶されているこの情報自体のコピーを含みうる（平文で、または検証者103にとってアクセス可能な暗号化された形で）。あるいはまた、レスポンス・データ・ストア601が信頼されるサードパーティーまたは検証者103V自身によって管理されている場合、レスポンス・データが特定の素性に関連付けレスポンス・データ・ストア601に登録されているという事実だけでは十分な証拠と見なすことができる（セットアップ当事者およびレスポンス・データ・ストア601を管理する当事者、たとえば信頼されるサードパーティーがセットアップ時に目標者の識別情報を好適に検査したと検証者103Vが信頼していることを前提としている）。
検証フェーズ704では、ステップ730で、検証者103Vがレスポンス・データ・ストアにアクセスし、検証動作において使用するレスポンス・データを決定する。諸実施形態では、複数の潜在的な検証者103Vがあり、それぞれに前記CRペアのうちの一つまたは複数のCRペアの異なるそれぞれの部分集合が割り当てられる。すなわち。レスポンス・データ・ストア601は、所与の検証者103Vに対して、その当事者に割り当てられたCRペア（単数または複数）の期待されるレスポンス（単数または複数）Riを開示するだけである。たとえば、この方式は、信頼されるサードパーティー・システム602によって管理されてもよい。そのような方式は、有利なことに、CRペアを別個に保ち、ある検証側103Vが別の検証者に対して目標であるふりをすることができない。ただし、ストア601へのアクセスを与えられたすべての検証者103Vが信頼されている場合には、これは本質的ではない。
諸実施形態では、検証者103Vは初期には使用するチャレンジを知らず、対応するレスポンス・データ（たとえば、レスポンスまたは証跡）とともにデータ・ストア601からアクセスすることによってこれを決定する。あるいはまた、検証者103Vは使用することを意図するチャレンジを事前に知っており、データ・ストア601においてどのレスポンス・データがこれにマッピングされているかを検索するためにこれを使う。
検証者103V（または実際には任意の当事者）がレスポンス・データおよび／またはチャレンジを決定するためなどにブロックチェーンからのデータにアクセスするシナリオでは、ブロックチェーンにアクセスすることは、ブロックチェーン・ネットワークのノードに直接問い合わせることによって、または、ブロックチェーン・データをキャッシュする、または、ブロックチェーン・データへのアクセスを求める当事者に代わって問い合わせ〔クエリー〕を仲介する中間サービスに問い合わせることによって間接的に、実行されうる。たとえば、検証者103Vは、ブロックチェーン・ネットワーク106に直接接続されていないが、単にレスポンスに関連したデータを、そしておそらくはマークル証明をも与えることがある別のサービス・プロバイダーからのデータにアクセスすることができる。
ステップ740で、検証者103Vは、PUFモジュール603を所有または制御している目標者103TにチャレンジCiを提出する。これは、ステップ730で検証者103Vがレスポンス・データ・ストア601からアクセスしたレコードのいずれかに対応するチャレンジである。なお、信頼されるサードパーティーがセットアップ時にPUFモジュール603を所有していたシナリオでは、セットアップ・フェーズ702から検証フェーズ704までの間に、PUFモジュール603が信頼されるサードパーティーから目標者103Tに物理的に渡されてもよい。
提出されたチャレンジCiに応答して、PUFモジュール603は対応するレスポンスRiを生成し、目標者103Vがこれを検証者に返す。ステップ750で、検証者は、受信したレスポンスRiが、ステップ730でレスポンス・データ・ストア601からアクセスしたレスポンス・データに従って期待されるレスポンスと整合するかどうかを検査する。
前述のように、セットアップ・ステップ702を実行する当事者は、目標者103Tまたはレスポンス・データ（たとえばCRペア）を記憶している信頼されるサードパーティーであってもよい。さらなる変形では、これらのステップは、信頼されるオラクルなどの別の調整役の当事者によって実行されてもよい（諸実施形態においてデータ・ストア610を有するサードパーティー・コンピュータ設備602を運用している前記当事者以外の別のサードパーティー〔第三者〕）。そのような実施形態では、データ・ストア601は、（異なるサードパーティーの）サードパーティー・システム602、またはブロックチェーンなどの公開のピアツーピア媒体でありうる。および／または、さらに別の変形では、PUFモジュール603への入力を実行する当事者と出力を受け取る当事者の間に分離が設けられてもよい。
また、レスポンス・データ・ストア601にレスポンスRiが記録される仕方には、少なくとも二つの可能性がある。第一のものは、単にRiの実際の値そのものを明示的に記憶することである。この場合、ステップ750は単に、（セットアップ702時に確立された）記憶されている値を、（検証フェーズ704において）提出されたチャレンジCiに応答して今受信された値R’i（レスポンスRiの標榜される値）と比較することを含む。それらが一致する場合、方法はステップ760に分岐し、目標者103Tの素性が検証済みであると宣言される。それ以外の場合、方法はステップ770に分岐し、目標者103Tの素性が検証されていないと宣言される。
第2の可能性は、Riの証跡のみがレスポンス・データ・ストア601に記憶されることである（たとえば、ハッシュまたはダブルハッシュ）。この場合、検証者103Vは、検証フェーズ704において目標者103Tから受信したレスポンスR’iに対して、証跡を生成するために使用されたのと同じ変換を適用する。これが記憶されている証跡と一致する場合、方法はステップ760に分岐し、目標者103Tの素性が検証されたと宣言される。それ以外の場合、方法はステップ770に分岐し、目標者103Tの素性が検証されていないと宣言される。
レスポンス・データ・ストア601では、対応するチャレンジCiが記録された各レスポンスRiに関連付けられていると示される仕方には、少なくとも二つの可能性がある。第一のものは、単に各CRペア{Ci,Ri}の明示的な値を記憶すること、すなわちRiとCiの実際の値を（平文でまたは暗号化して）記憶することである。あるいはまた、ここに開示されている諸実施形態による、第2のより軽量な仕方は、マスター・チャレンジCmを記憶することであり、そこから所定の決定論的なチャレンジ導出関数fに従ってチャレンジCiが導出できる。
このことは図8Aに示されている。各レスポンスRiは、それぞれのインデックスと関連付けて記憶される。関数fは、レスポンス・データ・ストア601に記憶されているか、または検証者103Vに事前に知られている。いずれにせよ、検証者103Vは、マスター・チャレンジCmを関数fに入力し、レスポンスRiのうち少なくとも一つのインデックスiに対応するチャレンジCiを決定する。次に、検証者103Vは、このチャレンジCiを使用して目標を検証する。
そのようないくつかの実施形態では、関数fは識別情報806の関数であってもよく、該識別情報は単一の識別情報であってもよく、複数の識別情報802（たとえば、パスポート情報、母親の旧姓、指紋情報）の組み合わせ804（たとえば連結）であってもよい。これは、目標者103Tの識別情報を含むことができる。これにより、特定の目標者103Tに固有のチャレンジCiの集合が可能になり、これはセキュリティ上の理由で有利である。たとえば、異なる目標者のためのチャレンジ集合を生成するために同じサードパーティー・システム602が使用される場合、一意性が重要になる可能性があるためである。目標者103Tのパスポート情報や母親の旧姓などの個人識別情報を使用することは、本人がすでに知っているまたは有しているものであり、非公開にする傾向があるため、よい選択肢である。
代替的または追加的に、識別情報（identification information）806は、検証者103Vの識別情報（identification information）を含んでいてもよく、そのためfは特定の検証者103Vの素性〔アイデンティティ〕（identity）の関数になる。これは、特定の検証者103Vに一つまたは複数の特定のチャレンジの特定の部分集合を割り当てるために使用でき、それにより、異なる検証者103Vは、検証704において使用する異なるチャレンジCiが与えられる。
いくつかの実施形態では、マスター・チャレンジCmがどのように形成されるかに関係なく、チャレンジCiはチェーン式にマスター・チャレンジCmにマッピングされうる。それにより、図8Bに示されるように、C1＝f(Cm)、C2＝f(C1)などとなる。つまり、第1のチャレンジC1は、マスター・チャレンジCmに関数fを適用することによって決定され、次に、第2のチャレンジC2は、第1のチャレンジに同じ関数fを適用することによって決定される、などとなる。例として、fはハッシュ関数を含みうる。
別の変形では、図8Cに示されるように、チャレンジCiは階層式にマスター・チャレンジCmにマッピングされてもよい。これについては、後で詳しく論じる。
チェーン式のアプローチは、f()がルート鍵以外のデータを必要としない場合、より軽量で、ルート情報からの回復もより容易である。階層式導出の場合、ツリー内のインデックスが追加されるが、これはC_m,H(C_m)、H(H(C_m))…のような単純なチェーンについては必要ない。ここでたとえば、f()は単にハッシュ関数である。
f()の形式にかかわらず、またはマスター・チャレンジが識別情報および／またはその他の情報を含むかどうかにかかわらず、諸実施形態において、マスター・チャレンジCmは、セットアップ702中に、目標者103Tからサードパーティー・システム602によって受信されてもよい。その後、サードパーティーは、受信したマスター・チャレンジを、検証704における将来の使用のために、データ・ストア601に（たとえば、ローカルにまたはチェーン上で）記憶する。あるいはまた、サードパーティー・システム602は、目標者103TからチャレンジCiの集合を受信し、たとえば関数f()の逆関数を適用することによって、そこからマスター・チャレンジCmを導出する。これらのアプローチの変形では、サードパーティー・システム602は、識別情報、マスター・チャレンジ、またはチャレンジの集合を、目標者103T以外の他の場所から、たとえば、オラクルまたは調整役の当事者（図示せず）から受信してもよい。そのようなアプローチの組み合わせも使用できる（たとえば、1つの識別情報が目標者から受信され、1つが他の場所から得られる）。あるいは、さらなる代替では、サードパーティーが関与せず、目標者103Tが自分でマスター・チャレンジをチェーン上に（または、他のピアツーピア公開媒体に）記憶する。
図7の方法のさらなる変形では、レスポンス・データ・ストア601に記憶されたレスポンス・データは、セットアップ時に生成されたCRペア（単数または複数）のレコードを含まなくてもよい。代わりに、レスポンス・データは、公開‐秘密鍵ペアの公開鍵、またはそのような公開鍵の集合を含んでいてもよく、ここでは、前記一つまたは複数の鍵ペアのそれぞれは、セットアップ・フェーズ702からのそれぞれのPUFレスポンスRiに基づいて生成されたものである。たとえば、レスポンスRiは、公開‐秘密鍵ペア生成アルゴリズムにおけるシードとして使用されてもよい。そのような実施形態では、方法は図7に記載されているように進むが、ステップ730で検証者は記憶されている公開鍵の一つにアクセスし、ステップ740で検証者103Vは目標のPUFモジュール603に入力されるチャレンジCiを提出しない点が異なる。代わりに、検証者103Vは、目標によって署名された（と標榜される）メッセージ（たとえば、文書、ファイル、またはブロックチェーン・トランザクションの一部）を取得する。このメッセージは、目標者103Tによって送られてきたものであってもよく、または検証者103Vはブロックチェーンまたはウェブサイトなどの公開媒体からそれに自律的にアクセスすることができる。いずれにせよ、ステップ750では、検査は、ストア601からアクセスされた公開鍵を使用して、メッセージに適用された署名を検証することを含む（それ自体は当技術分野でよく知られている既知の公開‐秘密鍵署名検証技術に基づいている）。
ここで、下記は、本願で開示された実施形態による、ePUFまたはより一般的にPUFのためのいくつかの例示的な素性確立および検証プロトコルを記述する。証明者アリス（目標者103T）と検証者ボブ（検証者103V）を考える。PUF素性システムには、少なくとも3つの異なるチャレンジ・タイプがある。以下では例としてePUFについて説明するが、より一般的には任意のPUFデバイスが使用できる（PUFモジュール603を有する任意のデバイス）。
1. リモートPUFチャレンジ―検証者は、ボブによって提出されたチャレンジに対するアリスからのレスポンスを要求することによって、リモートで証明者にチャレンジする。このモードは、検証者が証明者のPUFから期待されるレスポンス（単数または複数）を知っており、また、PUFが正当な所有者によって所有されていることを前提としている。
2. ローカルPUFチャレンジ―検証者は、アリスによって制御されるPUFデバイスと対話することによって、ローカルに証明者にチャレンジする。このモードは、検証者が証明者の素性については何かを知っているが、そのPUFの挙動については何も知らないことを前提としている。
3. 暗号化チャレンジ―検証者は、認証された公開鍵に証明可能な仕方でリンクされている鍵を用いてメッセージに署名することなどによって証明者の素性に関連する何らかの暗号学的要件を満たすように証明者にチャレンジする。
タイプ1とタイプ2の場合、チャレンジは証明者と検証者の両方の観点からPUFモジュール603に明示的に依存する。これらの場合、チャレンジ、ひいては対応する検証プロセスは、本来的にPUFデバイス（たとえばアリスのコンピュータ設備102TなどのPUFモジュール603を有するデバイス）の動作にリンクされている。このような場合、物理的な状態が一意的に素性に束縛されることができるというPUFデバイスの特性を使用しており、よって、PUFは使用される素性システムにおいて中心的な役割を果たす。
「リモート」と「ローカル」という用語は、特に、チャレンジを行う時点での検証者と証明者のPUFとの間の相互作用を指していることに注意されたい。これは、リモート・チャレンジ・プロトコルが、事前に証明者と検証者の間のローカルな相互作用に関わるセットアップ・フェーズをもつことを妨げるものではない。
ただし、ケース3の場合、チャレンジおよび検証プロセスは、証明者の観点からのPUFデバイスに関連する必要があるだけである。検証は、チャレンジへのレスポンスを生成する際に証明者によってPUFが使用されたか否かを検証者が知ることに依存しない。この場合、方法は、デバイス自体に素性を結びつけることにおける有用性ではなく、単に、アリスのための鍵生成器としてのPUFの有用性を使っている。
以下では、前述の3つの動作モードのそれぞれにおける素性システムについて、セットアップおよび検証ならびに任意的な更新および失効プロセスについての例示的実装が提供される。諸実施形態では、一般的な信頼されるサードパーティーが、PUFベースの素性システムに関連するプロセスに関与する。これは、そのような素性システムが、素性および関連する資格情報に対する完全性および信頼を意味のある形で保証するために、そのような第三者を必要とする傾向があるためである。そのようなシステムにおいて個人の素性が確立されて使用される場合、問題となる信頼されるサードパーティーは、認証局、政府エージェント、または銀行などの金融サービス・プロバイダーであってもよい。
機械または非人間エンティティについて素性が確立される場合、サードパーティーは、デバイス製造業者、発行者、規制当局、またはその他の関連する行為者でありうる。このケースは、モノのインターネット（IoT）またはさらにはモノのブロックチェーン（BoT）パラダイムに特に好適であり、何らかの目標を達成するためにタスクや計算を協調的に実行しうるデバイスのネットワークの異なるメンバーに素性が割り当てられる。
3.1. リモートPUFシステム
3.1.1. セットアップ: リモートPUFチャレンジの場合、証明者にチャレンジCを提出する検証者は、期待されるレスポンスを事前に知っていると仮定する。つまり、この場合のセットアップ・プロセスは、アリスと別の当事者との間に、後でアリスの素性を認証するために使用できる共有された秘密を導出するために使用できるCRP（すなわち、少なくとも1つ）の集合を確立する必要がある。
アリスが、前述のように素性を確立するために装備された一般的なサードパーティーとこの共有された秘密を確立し、このサードパーティーが後でアリスとの検証プロセスに参加する検証者であってもなくてもよいとする。検証者が素性を確立するサードパーティーと異なる場合は、検証者は共有される秘密（単数または複数）のために使用される関連するCRP情報をサードパーティーから取得しうるとする。
ここでは、セットアップ・フェーズのために2つの異なるオプションがあり、常にアリスがPUFデバイスへのアクセスをもつ唯一の当事者であるかどうか、または信頼されるサードパーティーもセットアップ・フェーズ中にのみPUFデバイスへのアクセスをもつかどうかによって分類される。
ケース1: アリスが単独でPUFへのアクセスをもつ
1. ePUFデバイスが製造され、アリスに配布される。
2. アリスは、信頼されるサードパーティーに連絡することによって、自分の素性を自分のePUFデバイスにリンクすることを申請する。
i. サードパーティーはアリスのための識別アカウントを確立し、アリスの素性の証明を要求する。
ii. アリスは、関連する身分証明文書または資格情報をサードパーティーに提供する。
iii. サードパーティーがアリスの素性を検証する。
3. アリスとサードパーティーは、残りのセットアップ・プロセスのために安全な通信チャネルを確立する（たとえば標準的なディフィー・ヘルマン鍵交換を介して）：
i. アリスとサードパーティーは、それぞれ公開鍵PA、PTを交換する。
ii. アリスとサードパーティーは独立して、残りのセットアップ通信のための一過性の秘密をS＝SA・PT＝PA・STとして確立する。
iii. アリスとサードパーティーは、Sによってセキュリティ保護されたチャネル、たとえばAESで暗号化されたチャネルを通じて通信を開始する。
4. サードパーティーは、アリスにチャレンジC1,C2,…,Cnの集合を安全なチャネルを通じて送信する。
5. アリスは、ePUFデバイスからのレスポンスR1,R2,…,Rnを取得する。
6. アリスは、安全なチャネルを通じてレスポンスR1,R2,…,Rnをサードパーティーに送信する。
7. サードパーティーは、アリスの素性アカウントに対して応答CRP集合{(C1,R1),(C2,R2),…,(Cn,Rn)}を保存する。
ケース2: セットアップ中にサードパーティーがPUFにアクセスする
1. サードパーティーは、ベース・ペアとハッシュ関数の知識をもっている。たとえば、ePUFデバイスが製造され、信頼されるサードパーティー*に配布される。
2. サードパーティーはデバイスからベースCRP（Cw,Rw）を取得する。
3. アリスはサードパーティーに連絡することによって素性リンクされたePUFデバイスを申請する。これは、セキュリティ保護されていない通信チャネルを通じて行われてもよい。
i. サードパーティーは、アリスについての識別アカウントを確立し、アリスの素性の証明を要求する。
ii. アリスは、関連する身分証明文書または資格情報をサードパーティーに提供する。
iii. サードパーティーがアリスの素性を検証し、ePUFデバイスおよびそのベース・ペア（Cw,Rw）をアリスのアカウントに割り当てる。共有される秘密はこのCRPである、またはこのCRPから導出されるものである。
４. サードパーティーがePUFデバイスをアリスに送る。
（*デバイスはまずアリスに配布され、その後アリスから送られてもよい。ただし、ほとんどの場合、デバイスが直接サードパーティーに配布されるほうが理にかなっている。たとえば、デバイスがスマート・デビット・カードである場合、カードは製造業者から発行銀行に送られ、次いでPUFのセットアップ後に発行銀行から顧客のアリスに送られてもよい。）
セットアップ・プロトコルは、アリスと信頼されるサードパーティーとの間で、共有される秘密（単数または複数）を確立し、それが後に検証プロセス中にアリスの素性（またはPUFを含んでいるデバイス）を認証するために使用される。これらのケースは、どちらもアリスと信頼されるサードパーティーとの間の安全な通信を含むことが望ましいという点でも似ている。
ただし、2つのケースの違いは、ケース1が安全な通信チャネルを確立することによって安全な通信を達成するのに対し、ケース2は物理的なセキュリティによってそれを達成するということである。
ケース1とケース2の2つのプロトコルでそれぞれ注意すべきもう1つの違いは、ケース2の場合、信頼されるサードパーティーがPUFなしでアリスと同じ数のCRPを導出できるのに対し、ケース1の場合、このパーティーは固定数のペアを記憶する必要があることである。
これは、PUFデバイスをもつユーザーをセットアップするための既存のプロトコルに対する、ケース2の利点である。信頼されるサードパーティーが任意の数のCRPをリモートで生成することを許容するからである。これに対し、既存のプロトコルでは、信頼されるサードパーティーは、そうするためにエンドユーザーまたはデバイス製造業者のいずれかと協力する必要がありうる。ケース1でも、アリスが安全なチャネルを通じてベース・ペア(Cw,Rw)をボブに送信する（サードパーティーが悪意のある仕方でベース・ペアを使用しないことを信頼して）ステップが追加されれば、同じ技術的利点が達成されうる。
セットアップ・フェーズにおける安全な通信の使用は、検証プロセスなどの将来の通信をセキュリティ保護されていないチャネルで伝送されることを許容することに注意されたい。これは、検証の時点で双方の当事者がオンラインになっている必要があるなど、より少数の技術的制限で検証が行われることを許容するという利点があり、この1回限りのセットアップ・プロセスにおける追加的な安全な通信オーバーヘッドが必要になるだけである。
3.1.2. 検証: リモートPUF検証モードでは、セットアップ・フェーズにおいて2つの異なるケースがあったことを想起されたい。これは、以下に詳述するように、わずかに異なるリモート検証プロトコルに反映されている。
ケース1: アリスが単独でPUFへのアクセスをもつ
1. ボブが、(C1,R1)などの未使用のCRPを、セットアップの際にアリスとサードパーティーによって確立された集合{(C1,R1),(C2,R2),…,(Cn,Rn)}から取得する。
i. ボブも信頼されるサードパーティーである場合は、ボブは単に前記集合からある要素を取得する。
ii. ボブが信頼されるサードパーティーでない場合は、ボブはアリスについての未使用のCRPを要求することによってサードパーティーと通信する。
2. ボブはアリスにチャレンジC1を送る。
3. アリスは自分のePUFデバイスから候補レスポンスR'1を取得し、ボブに送信する。
4. ボブはR'1==R1かどうかを検証する。
i. そうである場合、検証は合格である。
ii. そうでない場合、検証は失敗である。
5. その後、ペア(C1,R1)は信頼されるサードパーティーによって除去され、残りのチャレンジ‐レスポンス・ペアの集合{(C2,R2),(C3,R3),…,(Cn,Rn)}が残る。
ステップ1.ii.において、CRPの単回使用という性質により、任意のボブにとって特定のCRPを使用してアリスに「なりすます」ことは不可能であることに注意されたい。信頼されるサードパーティーは、それぞれの与えられた状況における各ペアの使用を単にモニタリングすればよく、認証試行ごとに新しいCRPを使用するべきであるためである。
ケース2: セットアップ中にサードパーティーがPUFにアクセスした
1. ボブは、検証のための新しいチャレンジCを生成する。これはランダムに行われてもよく、あるいは他の何らかのデータ（たとえば、既知のKYCデータ、生体認証、画像）から決定論的に行われてもよい。
2. ボブはアリスにチャレンジCを送信する。
3. アリスは候補レスポンスR'を自分のePUFデバイスから取得し、それをボブに送信する。
4. ボブは期待されるレスポンスRを取得する。
i. ボブが前記信頼されるサードパーティーである場合、ボブはR＝hash(C,Rw,H)を計算することによって直接、レスポンスを計算することができる*。
ii. ボブが前記信頼されるサードパーティーでない場合、ボブはCを前記サードパーティーにを送信し、レスポンスRを要求する。
5. ボブはR'==Rかどうかを検証する。
i. そうである場合、検証は合格である。
ii. そうでない場合、検証は失敗である。
（*これは、サードパーティーがセットアップ・プロトコル中にベース・ペア（Cw,Rw）を取得した（ケース2）ためであり、そのことはRwがサードパーティーに知られていることを含意する。また、ハッシュ関数も、誰にもでなくても、少なくとも前記サードパーティーには知られていると想定されている。すなわち、ハッシュ関数はSHA-256のような公開標準である。）
3.1.3. 更新: 検証（およびその他の有用なプロトコル、たとえばログイン）におけるCRPの単回使用という性質を与えられて、アリスおよびサードパーティーが新しいCRPを確立するためのプロセスをも指定することが望ましいことがありうる。
ケース1: アリスは、単独でPUFへのアクセスをもつ。この場合、セットアップにおけるのと同様に、アリスとサードパーティー間でチャレンジと応答を伝送するために、別の安全なチャネルが確立される。アリスは、S＝H(Ri)などの形の共有される秘密を確立するために(Ci,Ri)の形の少なくとも1つの残りのCRPをもつ、またはDH鍵交換からの以前の共有された秘密S＝SA・PT＝PA・STへのアクセスをもつとする。
1. アリスとサードパーティーは、共有される秘密Sを使用して、安全な通信チャネルを確立する。これは多くの仕方で導出されることができ、プロトコルはこれに関知しない。
2. サードパーティーは、アリスにチャレンジC1,C2,…,Cnの集合を安全なチャネルを通じて送信する。
3. アリスは、ePUFデバイスからレスポンスR1,R2,…,Rnを取得する。
4. アリスは、安全なチャネルを通じてレスポンスR1,R2,…,Rnをサードパーティーに送信する。
5. サードパーティーは、アリスの素性アカウントに対してレスポンスCRP集合{(C1,R1),(C2,R2),…,(Cn,Rn)}を記憶する。
なお、少なくともステップ2～5は、セットアップ・ステップ4～7と同じである。
アリスがチャネルを通じてサードパーティーに（Cw,Rw）を伝えることについては、前述のコメントも参照されたい。
ケース2: セットアップ中にサードパーティーがPUFにアクセスした。この場合、サードパーティーはベース・ペア(Cw,Rw)とハッシュ関数H()の両方の知識をもっているため、間接的に任意の数のCRPを生成できる。つまり、この場合、対話的な更新の必要性はない。
3.1.4. 失効: 素性システムのさらなる部分は、特定のePUFデバイスを、もはや素性目的のために使用されないよう失効させるためのものであってもよい。失効プロセスは単純で、（i）ユーザー、アリスとは独立したサードパーティーによる失効、または（ii）失効要求として伝達されるアリスによる失効のいずれかとして実行できる。
第1のケースでは、ePUFなどを含む技術的手段は必要ない。第2のケースでは、ePUFに固有のプロトコルや解決策は必要ない。第1のケースにおいて失効が必要になる好例は、アリスがePUFを含む物理的なデバイスを紛失した場合、または物理的なデバイスが何らかの仕方で危殆化された場合であるためである。
ただし、アリスがまだデバイスを物理的な制御を有していて、失効プロセスにおいて任意的にePUFを活用することが望まれる場合は、アリスとサードパーティーが確立したCRPのうちの一つ（またはその導出された共有される秘密）を使用してアリスの要求が認証されるようことが規定されてもよい。これはたとえば、CRPレスポンスまたは秘密をそれぞれの場合の鍵として使用する、HMACまたは暗号化されたメッセージによってである。ただし、前述の理由により、これはシステムの厳密な要件とは見なされない。
3.2. ローカルPUFシステム
3.2.1. セットアップ: ローカルPUFのために使用できるセットアップは、リモートPUFのためのセットアップと全く同じであるが、ローカルとリモートの場合の違いは、以下の検証ステップがどのように実行されるかにある。
3.2.2. 検証: このシナリオでは、検証はローカルに実行されている。つまり、検証プロセスは、証明者（アリス）と検証者（ボブ）の両方が同じ物理的な位置にあることを要求する。
このシナリオは、たとえば、アリスが自分のePUFデバイスを使用してローカルに捜査当局と対話することが法的に要求されている裁判所の手続きに（人間の素性について）、または、システムの管理者が特定のデバイスの応答をローカルで明示的にチェックしたいことがありうる場合にIoTシステムの分析が実行される場合に（デバイスの素性について）、有意でありうる。また、支払いシナリオにも有意でありうる。
そのようなプロセスが適用可能な他のシナリオは、クラッシュ後の車両の診断を含みうる。ここで、当局はどのデジタル・コンポーネントが命令を発したかを決定することを望む。この場合、入力Cは何らかの環境条件またはダイナミクス条件であってもよく、応答Rはデバイスによって与えられた命令の一部であろう。
以下に概説されるローカルなPUF検証プロトコルと先のリモートPUF検証プロトコルの違いは、このローカル・プロトコルは、検証者がePUFの応答を事前に知っていることを前提としないということである。つまり、ローカル検証プロセス中に生成された応答は、検証者にとって事前に利用可能ではない。
ただし、このシナリオでは、検証プロセスにおいて使用されるチャレンジは何らかの仕方で意味がある可能性が高い。たとえば、素性がその埋め込まれたePUFコンポーネントのベース・ペア(Cw,Rw)であると見なすことができる機械を考える。検証プロセスは、所与の入力Cから以前に出力Rを生成したのがこの特定のデバイスであったことを検証するために、実行されうる。
1. ボブが、問題のCRP（C,R）に基づいて、ePUFデバイスに提出する関連するチャレンジCを取得する。
2. ボブがePUFデバイスへのアクセスを得る。
3. ボブがePUFデバイスを使用して候補レスポンスR'＝hash(C,Rw,H)を生成する。
4. ボブがR'==Rかどうかを検証する。
i. もしそうであれば、検証は合格である。
ii. もしそうでなければ、検証は失敗である。
これらのシナリオでは、ボブは候補レスポンスR’を事前に知らず、むしろ、今PUFデバイスから受信しているレスポンスが以前に生成されたレスポンスと一致することを検証している。たとえば、これは、優勢でありレスポンスを生成した人（アリス）またはデバイスが、今そこにある（たとえば法定にいる）人またはデバイスと同じであることを検証するために使用できる。たとえば、デジタル・コンポーネントの例では、これは、Rの生成時に、何らかの入力チャレンジCに基づいて前記命令を発するように構成されていただろう。たとえば、デバイスが自動運転車で、コンポーネントが「前の車が近すぎる」というデータから導出される、または該データを含むチャレンジを受信した場合、レスポンスRが生成され、Rによってトリガーされて、コンポーネントはブレーキを適用する前記命令を発する。よって、遡及的な診断検証では、検証者は車が減速したと考え、条件が実際に、その応答をトリガーする「前の車が近すぎた」というものであったことを検証することを望む。
3.2.3. 更新: そのシナリオにおける主要な違いは検証にのみ当てはまるため、更新されたCRPを生成するプロセスは、リモート・ケースについて提案されたのと同じ論理に従うことができる。
3.2.4 失効: リモート失効について記載されているのと同じ技法がここでも有効である。
3.3. 暗号学的PUFシステム
3.3.1 セットアップ: この場合、アリスは標準的な暗号手段を使用して、ただしそのプロセスにおいてePUFデバイスを使用して、サードパーティーと素性を確立する。
このシナリオでは、サードパーティーは任意的に、このプロセスにおいてePUFが使用されたことを知っていてもよい。同様に、この仕方で確立された素性について、素性の検証者は、ePUFデバイスが素性検証プロセスに関与していることを知っていてもいなくてもよい。要するに、以下のプロトコルは、デバイスの所有者であるアリスが、ePUFデバイスが素性システムに関与していることを知っていることを規定するだけである。
1. ePUFデバイスが製造され、アリスに配布される。
2. アリスが、信頼されるサードパーティーに連絡することによって暗号学的素性を確立することを申請する。
i. サードパーティーがアリスについての識別アカウントを確立し、アリスの素性の証明を要求する。
ii. アリスが、関連する身分証明文書または資格情報をサードパーティーに提供する。
iii. サードパーティーがアリスの素性を検証する。
3. アリスは、自分の素性への暗号学的リンクを確立するための、たとえば自分のCRPを使用して認証された非対称鍵ペアを確立するための暗号方法を選択する。
i. サードパーティーがアリスから公開鍵PAを取得する。ここで、PA＝sA・GはEC鍵ペアである。
ii. サードパーティーは、アリスが秘密鍵sAを使用してメッセージmに（たとえばECDSAにより）署名することを要求する。
iii. アリスがECDSA署名Sig(PA,m)を生成し、サードパーティーに送信する。
iv. サードパーティーが署名を検証する。
4. 署名が有効である場合、サードパーティーはアリスの素性に対して鍵PAを認証する。
ステップ3は、ユーザーが選択した暗号方式を使用することに関わるが、このプロセスに関与する関連する鍵は、アリスだけが知っているCRPレスポンスから導出されるものであると想定する。上で選んだ例では、これは秘密鍵SAが、SA＝H(R)のように、特定のePUFレスポンスから導出されることを意味する。
3.3.2 検証: 暗号学的な場合は、先に詳述した暗号学的セットアップ・フェーズの間に確立された暗号情報を使用して素性検証が実行される。この場合、セットアップ時にアリスの素性に対して、認証されたEC非対称鍵ペアが確立された例を取り、今、その鍵を検証のために使用する。
ただし、以下のプロトコルは、任意の他の暗号方式のために簡単に適応させることができる。それは単に、適宜、既存のセットアップおよび検証プロトコルをそれらの方式のために置き換えることによる。ここでの違いは、セットアップおよび検証プロセスのための安全な鍵生成器としてePUFデバイスを使用することである。これは、保持者アリスにとって、悪意のある危殆化のリスクを軽減する。
1. ボブが、素性にリンクされた情報PA、たとえば認証された鍵を取得する。
i. ボブが前記信頼されるサードパーティーである場合、ボブは単にアリスのアカウントからPAを取得する。
ii. ボブが前記信頼されるサードパーティーでない場合、ボブは前記サードパーティーと通信し、アリスについての認証された公開鍵を要求する。
2. ボブはアリスが署名するメッセージmを選択し、アリスに送信する。
3. アリスがメッセージmに対する署名を生成する。
i. アリスが自分の認証された鍵で署名することを望む場合、アリスは署名Sig(PA,m)を生成する。
ii. アリスが単回使用の派生鍵で署名することを望む場合、アリスは署名Sig(Pα,m)を生成する。ここで、Pα＝PA＋H(d)・Gおよびdは何らかの単回使用のデータである*。
4. アリスは署名をボブに送信する。この時点で、ボブがデータdをまだ知らない場合は、アリスはデータdも送信してもよい。
5. ボブは、PA（および該当する場合はd）を使用して、公開鍵に対して署名を検証する。
i. 署名検証が合格であれば、素性検証は合格である。
ii. 署名検証が失敗であれば、素性検証は失敗である。
（*このデータは、検証に関係していてもよい。たとえば、インボイス・メッセージまたは生体認証のファジー・マッチング・データである。データdはボブまたはアリスによって選択されうる。あるいはまた、dはアリスとボブが知っている共有された秘密であってもよく、たとえばディフィー・ヘルマン鍵交換および／またはHMACを使用して導出されてもよい。
上記の暗号学的検証プロセスは、素性がECまたはPGP鍵などの同様の暗号プリミティブを用いて確立された場合に、前のセクションで説明したように、独立して確立された素性にも適用されてもよい。
3.3.3. 更新: ここでアリスの素性を更新するプロセスは、鍵生成においてePUFデバイスの使用に依存せず、よって、ここで何らかの特定の方法を規定する必要はない。代わりに、PAなどの認証された鍵を更新するための標準的な方法が使用されうる。
単に、ePUFは、任意の要求される署名または既存のプロセス（単数または複数）によって必要とされるその他の暗号プロセスのための鍵生成に関与すると想定されうる。
3.3.4. 失効: 同様に、ここで特定の失効プロトコルを規定する必要はなく、標準的な機構に従う。ここでもまた、ePUFは関連する暗号操作のための鍵生成器としてバックグラウンドで関与すると想定されてもよい。
3.4. 独立したPUF機構
3.4.1 セットアップ: ePUFデバイスを使用して素性を確立する独立したケースでは、エンティティがいかなるサードパーティーからも独立して人間の素性（human identity）を、または閉じたシステム内でのデバイスの素性を確立することを望むシナリオを考える。このプロセスに関与する唯一の当事者は、ePUFデバイスの「所有者」であり、後の検証時に最終的な証明者となるアリスである。
ケース1: アリスが人間の素性を確立する
1. アリスがePUFデバイスを取得する。
2. アリスがチャレンジCを用いてePUFをプローブする。
3. アリスがePUFからレスポンスRを取得する。
4. アリスが自分についての素性を確立するためにペア(C,R)を使用する。
i. アリスは、認証されていない素性鍵PAを確立するために暗号セットアップを使用してもよい。
ii. アリスは、自身の素性に対して自分の素性鍵を公開する。
5. アリスは、レスポンスのダブルハッシュH2(R)などの、自分のCRPに対する証跡を公開することを望んでもよい。
アリスが自分についての「自己主権型（self-sovereign）」素性〔自己主権型アイデンティティ〕を確立するこのケースは、アリスだけが制御するデバイスについて一意的であり再現可能なデバイス識別子を提供することにおいてある程度有用である。ただし、そのような素性システムに信頼されるサードパーティーが存在しないため、検証者は後で、証明者の素性と証明者のデバイスの間のリンクを信頼する必要がある。これは、現実世界では非常に限られた用途になる可能性がある。
ケース2: アリスがデバイスについての素性を確立した
1. アリスがePUFデバイスを取得する。
2. アリスがチャレンジCでePUFをプローブする。
3. アリスがePUFからレスポンスRを取得する。
4. アリスがペア(C,R)を使用して、自分のシステム内で前記デバイスについての素性を確立する：
i. アリスがペア(C,R)を自分のデバイスにマップする。
ii. アリスが自分のすべてのデバイスとCRPマッピングのデータベースを保持する。
5. アリスは、レスポンスのダブルハッシュH2(R)などの自分のCRPへの証跡を公開することを望んでもよい。
デバイスについての「自己主権」素性を作成する上記の例では、管理者がそのシステム内の種々のデバイスを識別しようとするだけの閉じたシステム内では、この設計が非常に有用でありうることがわかる。これは、後で他者に対して証跡を示す（attest）ためにも有用でありうる。ただし、セットアップの間に信頼されるサードパーティーがないため、シナリオによっては、デバイスが変更されていないことを外部の検証者に納得させることにおいて、証明者は制限される。
なお、ケース1とケース2は同じプロセスであるが、意図される目的が異なると見なされてもよい。したがって、ケース1とケース2は、まとめて、人間またはマシンについての「自己主権」素性を生成するための方法と解釈されてもよい。ここで、後者の場合、システム管理者（たとえばIoTシステムにおけるアリス）自身が信頼されるエンティティである。どちらの場合も、アリスは信頼されるエンティティである。
3.4.2 検証: このケースについての検証プロセスは、所与のチャレンジでePUFデバイスをプローブし、その応答を検査するだけの簡単なものである。外部の当事者に対して該素性を証明するために、この上に、外部の当事者のためのさらなる複雑な証明または証拠が構築される必要がある場合がある。
3.4.3 更新: このケースについての更新プロセスは、単にセットアップ・プロセスの繰り返しであり、管理者（この場合はアリス）が転送使用のために追加的なCRPを列挙する。
3.4.4. 失効: このシナリオでは、このプロセスにはサードパーティーが関与していないため、素性失効の唯一のタイプは、管理者（アリス）が独自に素性を失効させたい場合である。これは、失効が、アリスによるePUFデバイスの使用の停止と、そのCRPの彼女のデータベースからのパージという単純なものでありうることを意味する。
後のセクションでは、この自己主権の失効が、後刻外部の当事者を納得させうるよう、ブロックチェーン証跡および証拠付けによってより堅牢にできる方法が開示される。
3.5. 素性ベースのCRP管理
上記、特にリモートのPUFベースの素性システムでは、セットアップおよび検証プロトコルにおいて素性を認証するために使用されるCRPの単回使用の性質が、関与する当事者にとってCRP管理の課題を呈する。
たとえば、信頼されるサードパーティーがセットアップ中にPUFデバイスにアクセスしない場合、前記サードパーティーが将来の検証のために保存するために、多くのCRPが列挙される{(C1,R1),(C2,R2),…,(Cn,Rn)}ことが望まれることがありうる。さらに、ePUF自体が、チャレンジのレスポンスへの決定論的な擬似ランダム・マッピングとして機能するため、レスポンスは相互に無関係に見える。そのため、信頼されるサードパーティーがそのユーザーまたはクライアントについてのCRPの諸集合を一覧にして保存する負担は、多数のユーザーにサービスする必要がある場合、すぐにスケーリングの問題を呈する。
図8Aは、ここに開示された実施形態に従って、識別データからの課題の決定論的な導出を示している。
そのような実施形態によれば、信頼されるサードパーティーに対する負担の問題に対処するために、CRP管理は主にチャレンジC1,C2,…,Cnの生成において扱われる。ここでの発想は、チャレンジは単一のマスター・チャレンジ、またはマスター・チャレンジが導出されるもとになるマスター・データから決定論的に（そして可能性としては階層的に）導出されるべきであるということである。この概念は、信頼されるサードパーティー（または別の関連する当事者）がマスター・データのみを使って関連するすべてのチャレンジを回復することを許容するように設計されているという点で、単回使用のビットコイン鍵を管理するための階層型決定論的（hierarchical deterministic、HD）ウォレットの使用と似ており、マスター・データは、ビットコインのシナリオでは「ウォレット・シード（wallet seed）」と呼ばれている。
そのようないくつかの実施形態では、前の諸セクションで提案されたような素性システムにおいてどのCRPが使用されるかを決定するための大きな範囲のチャレンジを生成するためのマスター・データとして、アリス（目標者103T）の識別データ806が使用される。識別データ自体は、種々のデータ要素802の組み合わせ804を含むことができるが、組み合わせにおいては、次の特性を持つことが好ましい：
・一意性―識別データは、それが関連するエンティティに固有である；
・秘密性―識別データは、それが関連するエンティティ（またはその所有者）のみに知られる。
識別データの構成要素の簡単な例は、パスポート番号、国民保険番号、名前、生年月日、またはセキュリティ質問への回答（たとえば母親の旧姓）、またはデバイス識別の場合はシリアル番号および製造情報を含みうる。しかしながら、指紋や顔認識データのような、より高度な技術的手段によって得られたデータも使用されうると認識されている。これらは一意性を保つために、ファジィマジック（fuzzy-magic）技術を使用して抽出されてもよい。
諸実施形態において、チャレンジの集合が導出されるもとになるマスター入力として使用される「識別データ」は、上記のうちの複数を含んでいてもよい。この理由の1つは、前の諸セクションにおけるプロトコルの一部がサードパーティーおよび／または外部検証者とチャレンジを共有することに依拠することを考慮して、情報ができるだけ多くの信頼されるサードパーティーに関して秘密性を保持することを保証するためである。複数のコンポーネントを含む識別データは、どのサードパーティーにとっても証明者アリスの同意なしに完全に複製するのは、より困難になる。
識別データを使用して決定論的にCRPを生成する機構が図8Aに示されている。識別データの構成要素部分は、まずプロセス「A」（804）によって組み合わされる。これは、連結、ビットごとの演算（たとえばXOR）、または他の任意の関連する組み合わせ操作でありうる。この操作は生データを難読化された形に変換することによって秘匿性を保持しようとしうることを注意しておく。
次いで、識別用データは、ハッシュ関数または同様のプロセスによってマスター・チャレンジCmに変換される。最後に、マスター・チャレンジは、導出関数f()を使用して単回使用チャレンジC1,C2,…,Cnのシーケンスを決定論的に導出するために使用される。諸実施形態において、図8Bに示されるように、導出関数f()は、ハッシュ関数とナンス（nonce）の注入を含んでいてもよく、相続く各チャレンジはCi＝SHA256(Ci-1,i)として生成される。ここで、iがナンスのはたらきをする。
プロセスA、識別データからのチャレンジCmの生成、および導出関数f()はみな、特定の実装のニーズに応じて構成されうる。
図8Cは、別の特定の例、すなわち、チャレンジの階層的かつ決定論的な導出を示している（レスポンスは図示していない）。図8Bに示されるように、マスターCmから階層式に単回使用のチャレンジCiを導出することが望ましい場合がある。この場合、前のケースのように、特定のチャレンジの生成が前のチャレンジのすべてに依存する必要がないという事実によって、CRP管理はさらに改善される。
素性データに基づくチャレンジの決定論的導出の使用は、素性プロトコルにおける、証明者アリスと信頼されるサードパーティーの両方にとっての記憶オーバーヘッドを削減される。どの当事者も、単に識別用データ（またはその部分集合）を記憶し、必要に応じて必要なチャレンジを再計算することが可能である。
さらに、アリスは、各識別サービスに対して留保するまたは共有することを望む情報の量を選ぶことによって、自分のプライバシーを調整するオプションももつ。トレードオフは、自分自身でより多くのデータを記憶することがありうるということである。
4. ブロックチェーン・システムの例
以下は、本開示のある種の実施形態で採用されうる例示的なブロックチェーン・システムを説明する。「アリス」および「ボブ」は、単に2当事者の任意の名前であり、アリスとボブは、このセクションでは、必ずしも前のセクションまたは後のセクションと同じ役割を果たすとは限らないことに注意されたい。
いくつかの実施形態では、PUFの出力に基づくレスポンス・データは、たとえば前セクションで論じたように、チェーン上に格納されてもよい。チェーン上に格納されたレスポンス・データは、実際のレスポンス自体の形を取ってもよく、または、ハッシュもしくはダブルハッシュ（いわゆる証跡またはハッシュ・コミット）のような変換の形を取ってもよく、PUFレスポンスから導出された公開‐秘密鍵ペアの公開鍵であってもよい。チェーン上のレスポンス・データがどのような形をとるにせよ、それは、別の、検証者が、素性の証拠として提示された目標応答または署名が期待されるとおりであるかどうかをチェックできるようにするものである。さらなる実施形態では、ブロックチェーンは、チャレンジ-レスポンス・ペアを、更新するまたは失効させるなど管理する手段として使用されてもよい。
以下は、そのような機能を実装するために使用されうるブロックチェーン・システムの例について説明する。
4.1. 例示的なシステムの概観
図1は、ブロックチェーン150を実装する例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、典型的にはインターネットなどの広域インターネットワークを含みうる。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア（P2P）ネットワーク106を形成するように構成されうる複数のブロックチェーン・ノード104を含む。図示されていないが、ブロックチェーン・ノード104はほぼ完全なグラフとして構成されてもよい。したがって、各ブロックチェーン・ノード104は他のブロックチェーン・ノード104に高度に接続されている。
各ブロックチェーン・ノード104はピアのコンピュータ設備を含み、ノード104のうちの異なるものは異なるピアに属する。各ブロックチェーン・ノード104は、一つまたは複数のプロセッサ、たとえば一つまたは複数の中央処理装置（CPU）、アクセラレータ・プロセッサ、特定用途向けプロセッサおよび／またはフィールドプログラマブルゲートアレイ（FPGA）、および他の設備、たとえば特定用途向け集積回路（ASIC）を含む処理装置を含む。各ノードはメモリ、すなわち、非一時的なコンピュータ可読媒体またはメディアの形でのコンピュータ可読記憶も含む。メモリは、一つまたは複数のメモリ媒体、たとえばハードディスクのような磁気媒体；ソリッドステートドライブ（SSD）、フラッシュメモリまたはEEPROMのような電子媒体；および／または光ディスクドライブのような光学媒体を使用する一つまたは複数のメモリ・ユニットを含みうる。
ブロックチェーン150は、データ151のブロックのチェーンを含み、ブロックチェーン150のそれぞれのコピーが、分散型またはブロックチェーン・ネットワーク106内の複数のブロックチェーン・ノード104のそれぞれで保持される。前述のように、ブロックチェーン150のコピーを保持することは、必ずしもブロックチェーン150を完全に記憶していることを意味しない。代わりに、各ブロックチェーン・ノード150が各ブロック151のブロックヘッダ（後述）を格納する限り、ブロックチェーン150はデータを剪定されてもよい。チェーン内の各ブロック151は、一つまたは複数のトランザクション152を含み、ここで、このコンテキストにおけるトランザクションは一種のデータ構造を指す。データ構造の性質は、トランザクション・モデルまたは方式の一部として使用されるトランザクション・プロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して1つの特定のトランザクション・プロトコルを使用する。ある一般的なタイプのトランザクション・プロトコルでは、各トランザクション152のデータ構造は、少なくとも1つの入力と少なくとも1つの出力を含む。各出力は、デジタル資産の量を表す額をプロパティとして指定し、その例は、該出力が暗号学的にロックされているユーザー103である（ロック解除され、それにより償還または使用されるために、そのユーザーの署名またはその他の解を必要とする）。各入力は前のトランザクション152の出力をポイントし、それによりトランザクションをリンクする。
各ブロック151は、チェーンにおける前に作成されたブロック151をポイントバックするブロック・ポインタ155をも含んでおり、それにより諸ブロック151に対して逐次順を定義する。各トランザクション152（コインベース・トランザクションを除く）は、前のトランザクションへのポインタを含んでおり、それにより諸トランザクションの諸シーケンスに対して順序を定義する（注：トランザクションのシーケンス152は分岐できる）。ブロック151のチェーンは、チェーンにおける最初のブロックであった創生ブロック（genesis block、Gb）153までさかのぼる。チェーン150における初期の一つまたは複数のもとのトランザクション152は、先行トランザクションではなく、創生ブロック153をポイントしていた。
各ブロックチェーン・ノード104は、トランザクション152を他のブロックチェーン・ノード104に転送し、それによりトランザクション152をネットワーク106全体に伝播させるように構成されている。各ブロックチェーン・ノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成されている。各ブロックチェーン・ノード104は、ブロック151に組み込まれるのを待っているトランザクション152の順序付けられた集合（または「プール」）154をも維持している。順序付きプール154は、しばしば「mempool」と呼ばれる。ここでのこの用語は、いかなる特定のブロックチェーン、プロトコル、またはモデルに限定することも意図されていない。これは、ノード104が有効として受け入れたトランザクションであって、そのためにノード104は同じ出力を使用しようとする他のいかなるトランザクションも受け入れない義務があるトランザクションの順序付けられた集合を指す。
所与の現在のトランザクション152jにおいて、その（または各）入力は、トランザクションのシーケンスにおける先行トランザクション152iの出力を参照するポインタを含み、現在のトランザクション152jにおいてこの出力が償還または「使用」されることを指定する。一般に、先行トランザクションは、順序集合154内の任意のトランザクションまたは任意のブロック151でありうる。先行トランザクション152iは、現在のトランザクション152jが作成される時点で、またはネットワーク106に送信される時点でさえも、必ずしも存在している必要はない。ただし、現在のトランザクションが有効になるためには、先行トランザクション152iが存在し、有効確認される必要がある。よって、ここでいう「先行」とは、必ずしも時間的シーケンスにおける作成または送信の時刻ではなく、ポインタによってリンクされた論理シーケンスにおける先行するもののことであり、よって、必ずしもトランザクション152i、152jが順序外に作成または送信されることを排除するわけではない（孤立（orphan）トランザクションに関する後述の議論を参照）。先行トランザクション152iは、同等に、前のトランザクションまたは先行者トランザクションと呼ぶこともできる。
現在のトランザクション152jの入力は、たとえば、入力許諾、たとえば先行トランザクション152iの出力がロックされているユーザー103aの署名をも含む。そして、現在のトランザクション152jの出力は、新しいユーザーまたはエンティティ103bに暗号学的にロックされることができる。よって、現在のトランザクション152jは、先行トランザクション152iの入力において定義された額を、現在のトランザクション152jの出力において定義された新しいユーザーまたはエンティティ103bに移転できる。場合によっては、トランザクション152は複数のユーザーまたはエンティティ間で入力額を分割するために複数の出力をもつことがある（おつりを与えるために、そのうちの一人がもとのユーザーまたはエンティティ103aであってもよい）。場合によっては、トランザクションは複数の入力をもつことができ、一つまたは複数の先行トランザクションの複数の出力からの額を集め、現在のトランザクションの一つまたは複数の出力に再配分することもできる。
ビットコインのような出力ベースのトランザクション・プロトコルによると、個人ユーザーまたは組織などの当事者103が新しいトランザクション152jを（手動で、またはその当事者によって用いられる自動化されたプロセスによって）実施しようとするとき、実施者（enacting party）は新しいトランザクションをそのコンピュータ端末102から受信者に送信する。実施者または受信者は、最終的にはこのトランザクションを（今日では典型的にはサーバーまたはデータセンターであるが、原理的には他のユーザー端末でもよい）ネットワーク106のブロックチェーン・ノード104の一つまたは複数に送信する。また、新しいトランザクション152jを実施する当事者103が、トランザクションをブロックチェーン・ノード104の一つまたは複数に直接送信し、場合によっては受信者に送信しないことも除外されない。トランザクションを受信したブロックチェーン・ノード104は、各ブロックチェーン・ノード104で適用されるブロックチェーン・ノード・プロトコルに従って、そのトランザクションが有効かどうかをチェックする。ブロックチェーン・ノード・プロトコルは、典型的には、新しいトランザクション152j内の暗号学的署名が、トランザクション152の順序付けられたシーケンスにおける前のトランザクション152iに依存する期待される署名と一致することをチェックするよう、ブロックチェーン・ノード104に要求する。そのような出力ベースのトランザクション・プロトコルでは、これは、新しいトランザクション152jの入力に含まれる当事者103の暗号学的署名またはその他の許諾が、新しいトランザクションが割り当てる先行トランザクション152iの出力において定義された条件と一致することをチェックすることを含んでいてもよく、この条件は、典型的には、少なくとも、新しいトランザクション152jの入力における暗号学的署名またはその他の許諾が、新しいトランザクションの入力がリンクされている前のトランザクション152iの出力をロック解除することをチェックすることを含む。条件は、少なくとも部分的には、先行トランザクション152iの出力に含まれるスクリプトによって定義されてもよい。あるいはまた、単にブロックチェーン・ノード・プロトコルだけによってフィックスされてもよく、あるいはこれらの組み合わせに起因することもある。いずれにせよ、新しいトランザクション152jが有効であれば、ブロックチェーン・ノード104は、それをブロックチェーン・ネットワーク106内の一つまたは複数の他のブロックチェーン・ノード104に転送する。これらの他のブロックチェーン・ノード104は、同じブロックチェーン・ノード・プロトコルに従って同じテストを適用し、新しいトランザクション152jを一つまたは複数のさらなるノード104に転送する、などとなる。このようにして、新しいトランザクションはブロックチェーン・ノード104のネットワーク全体に伝播される。
出力ベースのモデルでは、所与の出力（たとえばUTXO）が割り当てられる（たとえば使用される）かどうかの定義は、ブロックチェーン・ノード・プロトコルに従って、別の、先のトランザクション152jの入力によってすでに有効に償還されているかどうかである。トランザクションが有効であるためのもう一つの条件は、それが償還しようとする先行トランザクション152iの出力が、別のトランザクションによってまだ償還されていないことである。ここでもまた、有効でない場合、トランザクション152jは伝播されず（無効としてフラグが立てられ、警告のために伝播されるのでない限り）、ブロックチェーン150に記録もされない。これは、トランザクション主体が同じトランザクションの出力を複数回割り当てようとする二重使用に対する防護となる。一方、アカウント・ベースのモデルは、アカウント残高を維持することによって二重使用に対して防護する。ここでもまたトランザクションの定義された順序があるため、アカウント残高は常に単一の定義された状態をもつ。
トランザクションを有効確認することに加えて、ブロックチェーン・ノード104は、一般にマイニングと呼ばれるプロセスにおいて、トランザクションのブロックを最初に作成するよう競争する。これは「作業証明（proof-of-work）」によってサポートされる。ブロックチェーン・ノード104において、ブロックチェーン150に記録されたブロック151にまだ出現していない有効なトランザクションの順序付けられたプール154に新しいトランザクションが追加される。次いで、諸ブロックチェーン・ノードは、暗号学的パズルを解くことを試みることによって、トランザクションの順序付けられた集合154から、トランザクション152の新しい有効なブロック151を組み立てようと競争する。典型的には、これは、「ナンス」値を探すことであって、ナンスがペンディング・トランザクションの順序付けられたプール154の表現と連結されてハッシュされたときに、ハッシュの出力が所定の条件を満たすようにすることを含む。たとえば、所定の条件は、ハッシュの出力がある所定の数の先行ゼロをもつことであってもよい。これは単に作業証明パズルの一つの具体的なタイプであり、他のタイプが除外されないことに注意されたい。ハッシュ関数の特性は、その入力に関して予測不可能な出力をもつことである。したがって、この検索はブルートフォースによってしか実行できないため、パズルを解こうとしている各ブロックチェーン・ノード104においてかなりの量の処理資源を消費する。
パズルを解く最初のブロックチェーン・ノード104は、これをネットワーク106にアナウンスし、その解を証明として提供し、それはその後、ネットワーク内の他のブロックチェーン・ノード104によって簡単にチェックできる（ハッシュに対する解が与えられれば、それによりハッシュの出力が条件を満たすことを確認するのは簡単である）。最初のブロックチェーン・ノード104は、ブロックを、該ブロックを受け入れ、よってプロトコル規則を強制する他のノードの閾値コンセンサースに伝播させる。その後、トランザクションの順序付けられた集合154は、各ブロックチェーン・ノード104によってブロックチェーン150における新しいブロック151として記録される。チェーン内の以前に作成されたブロックn-1を指すブロック・ポインタ155も、新しいブロック151nに割り当てられる。作業証明解を作成するために必要な、たとえばハッシュの形でのかなりの量の労力は、最初のノード104がブロックチェーン・プロトコルの規則に従うという意図を示す。そのような規則は、トランザクションが以前に有効確認されたトランザクションと同じ出力を割り当てる場合（二重使用としても知られる）に、トランザクションを有効として受け入れないことを含む。ひとたび作成されると、ブロック151は、ブロックチェーン・ネットワーク106内の各ブロックチェーン・ノード104において認識され、維持されるため、修正できない。また、ブロック・ポインタ155も、諸ブロック151に逐次順を強制する。諸トランザクション152は、ネットワーク106内の各ブロックチェーン・ノード104における順序付けられたブロックに記録されるため、これにより、トランザクションの変更不能な公開台帳が提供される。
パズルを解こうとして常に競争している種々のブロックチェーン・ノード104は、

いつ解を探し始めたか、またはトランザクションが受信された順序に依存して、任意の所与の時点において未公開トランザクションのプール154の異なるスナップショットに基づいてそうしている可能性がある。誰であろうとそれぞれのパズルを最初に解く人は、どのトランザクション152がどの順序で次の新しいブロック151nに含まれるかを定義し、未公開トランザクションの現在のプール154が更新される。その後、諸ブロックチェーン・ノード104は、未公開トランザクションの新しく定義された順序付けられたプール154からブロックを作成しようと競争を続ける。発生する可能性のある「フォーク」を解決するためのプロトコルも存在する。フォークとは、2つのブロックチェーン・ノード104が互いに非常に短い時間内にパズルを解き、そのためブロックチェーンの競合するビューが諸ノードの間で伝播されるものである。かいつまんでいうと、どちらであれフォークの最も長く伸びた分枝が、決定版ブロックチェーン150となる。同じトランザクションが両方のフォークに現れるため、これはネットワークのユーザーやエージェントには影響を与えないはずであること注意されたい。
ビットコイン・ブロックチェーン（およびほとんどの他のブロックチェーン）によれば、新しいブロック104の構築に成功したノードは、デジタル資産の追加的な定義された量を分配する新しい特別な種類のトランザクション（あるエージェントまたはユーザーから別のエージェントまたはユーザーにデジタル資産のある額を移転するエージェント間またはユーザー間トランザクションではない）において、デジタル資産の追加的な受け入れられた額を新たに割り当てる能力を与えられる。この特別なタイプのトランザクションは、通例「コインベース・トランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」と呼ばれることもある。それは典型的には、新しいブロック151nの最初のトランザクションを形成する。作業証明は、新しいブロックを構築するノードが、この特別なトランザクションが後に償還されることを許容するプロトコル規則に従う意図を示す。ブロックチェーン・プロトコル規則は、この特別なトランザクションが償還されうるようになるまでに、たとえば100ブロックのような成熟期間を要求することがある。しばしば、通常の（非生成）トランザクション152は、その出力の一つにおいて追加的なトランザクション料金も指定する。これは、そのトランザクションが公開されたブロック151nを作成したブロックチェーン・ノード104にさらに報酬を与えるためである。この料金は通常、「トランザクション料金」と呼ばれ、のちに論じられる。
トランザクションの有効確認および公開に関与する資源のために、典型的には、少なくとも各ブロックチェーン・ノード104は、一つまたは複数の物理的なサーバー・ユニットを含むサーバー、またはさらにはデータセンター全体の形をとる。しかしながら、原理的には、任意の所与のブロックチェーン・ノード104は、ユーザー端末または一緒にネットワーク接続されたユーザー端末のグループの形を取ることができる。
各ブロックチェーン・ノード104のメモリは、ブロックチェーン・ノード・プロトコルに従ってそれぞれの役割（単数または複数）を果たし、トランザクション152を処理するために、ブロックチェーン・ノード104の処理装置上で動作するように構成されたソフトウェアを記憶している。ここでブロックチェーン・ノード104に帰されるいかなるアクションも、それぞれのコンピュータ設備の処理装置上で動作するソフトウェアによって実行されうることが理解されるであろう。ノード・ソフトウェアは、アプリケーション層の一つまたは複数のアプリケーション、またはオペレーティングシステム層やプロトコル層などのより下位の層、またはこれらの任意の組み合わせで実装されうる。
また、ネットワーク101には、消費ユーザーの役割の複数の当事者103のそれぞれのコンピュータ設備102も接続されている。これらのユーザーは、ブロックチェーン・ネットワーク106と対話することはできるが、トランザクションの有効確認やブロックの構築には参加しない。これらのユーザーまたはエージェント103の一部は、トランザクションにおいて送信者および受信者として機能してもよい。他のユーザーは、必ずしも送信者または受信者として機能せずに、ブロックチェーン150と対話してもよい。たとえば、一部の当事者は、ブロックチェーン150のコピーを記憶する記憶エンティティとして機能してもよい（たとえば、ブロックチェーン・ノード104からブロックチェーンのコピーを取得した）。
当事者103の一部または全部は、異なるネットワーク、たとえばブロックチェーン・ネットワーク106の上にオーバーレイされたネットワークの一部として接続されてもよい。ブロックチェーン・ネットワークのユーザー（しばしば「クライアント」と呼ばれる）は、ブロックチェーン・ネットワーク106を含むシステムの一部であると言われてもよいが、これらのユーザーは、ブロックチェーン・ノードに要求される役割を果たしていないため、ブロックチェーン・ノード104ではない。代わりに、各当事者103は、ブロックチェーン・ノード106に接続する（すなわち、ブロックチェーン・ノード106と通信する）ことによって、ブロックチェーン・ネットワーク106と対話し、それによりブロックチェーン150を利用することができる。2当事者103とそれぞれの設備102が、例解目的のために示されている：第1の当事者103aとその対応するコンピュータ設備102a、第2の当事者103bとその対応するコンピュータ設備102bである。ずっと多くのそのような当事者103とそれぞれのコンピュータ設備102が存在し、システム100に参加している可能性があることは理解されるだろうが、便宜上それらは図示されていない。各当事者103は個人または組織でありうる。純粋に例解のために、ここでは第1の当事者103aはアリスと呼ばれ、第2の当事者103bはボブと呼ばれるが、これは限定するものではなく、ここでのアリスまたはボブへの言及はそれぞれ「第1の当事者」および「第2の当事者」に置き換えることができることが理解されよう。
各当事者103のコンピュータ設備102は、一つまたは複数のプロセッサ、たとえば一つまたは複数のCPU、GPU、他のアクセラレータ・プロセッサ、特定用途向けプロセッサ、および／またはFPGAを含むそれぞれの処理装置を含む。各当事者103のコンピュータ設備102はさらにメモリ、すなわち、非一時的なコンピュータ可読媒体またはメディアの形のコンピュータ可読記憶を含む。メモリは、一つまたは複数のメモリ媒体、たとえばハードディスクのような磁気媒体；SSD、フラッシュメモリまたはEEPROMのような電子媒体；および／または光ディスクドライブのような光学媒体を使用する一つまたは複数のメモリ・ユニットを含みうる。各当事者103のコンピュータ設備102上のメモリは、処理装置上で動作するように構成された少なくとも一つのクライアント・アプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶している。ここで所与の当事者103に帰されているいかなるアクションも、それぞれのコンピュータ設備102の処理装置上で実行されるソフトウェアを使用して実行されうることが理解されるであろう。各当事者103のコンピュータ設備102は、少なくとも一つのユーザー端末、たとえばデスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチのようなウェアラブルデバイスを含む。所与の当事者103のコンピュータ設備102は、ユーザー端末を介してアクセスされるクラウドコンピューティング資源など、一つまたは複数の他のネットワーク接続された資源をも含んでいてもよい。
クライアント・アプリケーション105は、初期に、任意の所与の当事者103のコンピュータ設備102に好適なコンピュータ可読記憶媒体またはメディア上で提供されうる、たとえばサーバーからダウンロードされてもよく、またはリムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクまたはテープ、CDもしくはDVD ROMなどの光ディスク、またはリムーバブル光学ドライブなどのリムーバブル記憶デバイス上で提供される。
クライアント・アプリケーション105は、少なくとも「ウォレット」機能を含む。これには主に二つの機能がある。その一つは、それぞれの当事者103がトランザクション152を作成し、許諾（たとえば署名）し、一つまたは複数のビットコイン・ノード104に送信して、ブロックチェーン・ノード104のネットワーク全体に伝播され、それによりブロックチェーン150に含められるようにすることである。もう一つは、それぞれの当事者に、現在所有しているデジタル資産の額を報告することである。出力ベースのシステムでは、この第2の機能は、問題の当事者に属するブロックチェーン150全体に散在するさまざまな152トランザクションの出力において定義された額を照合することを含む。
注：さまざまなクライアント機能は、所与のクライアント・アプリケーション105に統合されているものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりに、ここで説明されているどのクライアント機能も、たとえばAPIを介してインターフェースをもつ、または一方が他方へのプラグインであるなどの、二つ以上の異なるアプリケーションのスイートにおいて実装されてもよい。より一般的には、クライアント機能は、アプリケーション層またはオペレーティングシステムなどのより下位の層、またはこれらの任意の組み合わせで実装できる。以下では、クライアント・アプリケーション105に関して説明されるが、これは限定するものではないことが理解される。
各コンピュータ設備102上のクライアント・アプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーン・ノード104の少なくとも一つに動作上結合されている。これは、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信できるようにする。また、クライアント105は、それぞれの当事者103が受信者であるトランザクションについてブロックチェーン150に照会するために（あるいは実際にはブロックチェーン150における他の当事者のトランザクションを検査するため；諸実施形態において、ブロックチェーン150は、その公開の可視性を通じて部分的にトランザクションの信頼を提供する公共施設であるからである）、ブロックチェーン・ノード104に連絡することもできる。各コンピュータ設備102上のウォレット機能は、トランザクション・プロトコルに従ってトランザクション152を定式化して送信するように構成されている。前述のように、各ブロックチェーン・ノード104は、ブロックチェーン・ノード・プロトコルに従ってトランザクション152を有効確認し、ブロックチェーン・ネットワーク106全体に伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクション・プロトコルとノード・プロトコルは互いに対応しており、所与のトランザクション・プロトコルは所与のノード・プロトコルと一緒になって、所与のトランザクション・モデルを実装する。ブロックチェーン150におけるすべてのトランザクション152について同じトランザクション・プロトコルが使用される。ネットワーク106におけるすべてのノード104によって同じノード・プロトコルが使用される。
所与の当事者103、たとえばアリスがブロックチェーン150に含められるべき新しいトランザクション152jを送信することを望む場合、アリスは関連するトランザクション・プロトコルに従って（自分のクライアント・アプリケーション105におけるウォレット機能を使用して）該新しいトランザクションを定式化する。次いで、アリスは自分が接続されている一つまたは複数のブロックチェーン・ノード104にクライアント・アプリケーション105からトランザクション152を送信する。たとえば、これは、アリスのコンピュータ102に最もよく接続されているブロックチェーン・ノード104である可能性がある。任意の所与のブロックチェーン・ノード104は、新しいトランザクション152jを受け取ると、ブロックチェーン・ノード・プロトコルおよびそれぞれの役割に従ってそれを処理する。これは、新しく受け取ったトランザクション152jが「有効」であるためのある種の条件を満たしているかどうかをまずチェックすることを含み、その例についてはまもなく詳しく論じられる。いくつかのトランザクション・プロトコルでは、有効確認のための条件は、トランザクション152に含まれるスクリプトによって、トランザクションごとに構成可能であってもよい。あるいはまた、条件は単にノード・プロトコルの組み込み機能であってもよく、またはスクリプトとノード・プロトコルの組み合わせによって定義されてもよい。
新しく受信したトランザクション152jが有効と見なされるためのテストに合格することを条件として（すなわち、「有効確認される」ことを条件として）、トランザクション152jを受信する任意のブロックチェーン・ノード104は、そのブロックチェーン・ノード104において維持されているトランザクションの順序付けられ集合154に、新しい有効確認されたトランザクション152を追加する。さらに、トランザクション152jを受信する任意のブロックチェーン・ノード104は、有効確認されたトランザクション152をネットワーク106内の先の一つまたは複数の他のブロックチェーン・ノード104に伝播させる。各ブロックチェーン・ノード104は同じプロトコルを適用するため、トランザクション152jが有効であるとすると、このことは、そのトランザクションがまもなくネットワーク106全体に伝播されることを意味する。
ひとたび所与のブロックチェーン・ノード104において維持されているペンディング・トランザクションの順序付けられたプール154に受け入れられると、そのブロックチェーン・ノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンに関する作業証明パズルを解こうとして競争を開始する。（他のブロックチェーン・ノード104がトランザクションの異なるプール154に基づいてパズルを解こうとしていることがありうるが、誰であれ先に到達したものが最新のブロック151に含まれるトランザクションの集合を定義することを想起されたい。最終的には、あるブロックチェーン・ノード104が、アリスのトランザクション152jを含む順序付けられたプール154の一部についてのパズルを解く。）ひとたび新しいトランザクション152jを含むプール154について作業証明が行われたら、それは変更不能な仕方でブロックチェーン150における諸ブロック151の一つの一部になる。各トランザクション152は以前のトランザクションへのポインタを含むため、トランザクションの順序も変更不能な仕方で記録される。
異なるブロックチェーン・ノード104は、所与のトランザクションの異なるインスタンスを最初に受け取る可能性があり、そのため、どのインスタンスが「有効」であるかについて競合するビューをもつことがあるが、これは一つのインスタンスが新しいブロック151において公開されるまでであり、その時点で、すべてのブロックチェーン・ノード104は、公開されたインスタンスが唯一の有効なインスタンスであることに同意する。あるブロックチェーン・ノード104が、あるインスタンスを有効として受け入れ、その後、第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーン・ノード104はこれを受け入れる必要があり、最初に受け入れたインスタンス（すなわちブロック151において公開されていないもの）を破棄する（すなわち無効として扱う）ことになる。
いくつかのブロックチェーン・ネットワークによって運用される別のタイプのトランザクション・プロトコルは、アカウント・ベースのトランザクション・モデルの一部として、「アカウント・ベース」のプロトコルと呼ばれることがある。アカウント・ベースの場合、各トランザクションは、過去のトランザクションのシーケンスにおける先行トランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移転される額を定義する。すべてのアカウントの現在状態は、そのネットワークの諸ノードによって、ブロックチェーンに別個に記憶され、常に更新される。そのようなシステムでは、諸トランザクションは、前記アカウントの現行トランザクション勘定（running transaction tally）（「ポジション」とも呼ばれる）を使用して順序付けられる。この値は、送信者によって暗号学的署名の一部として署名され、トランザクション参照計算（transaction reference calculation）の一部としてハッシュされる。さらに、任意的なデータ・フィールドもトランザクションで署名されてもよい。このデータ・フィールドは、たとえば該データ・フィールドに前のトランザクションIDが含まれている場合、該前のトランザクションをポイントしてもよい。
4.2 UTXOベースのモデル
図2は、例示的なトランザクション・プロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152（「Tx」と略す）は、ブロックチェーン150の基本的なデータ構造である（各ブロック151は一つまたは複数のトランザクション152を含む）。以下は、出力ベースまたは「UTXO」ベースのプロトコルを参照して説明される。しかしながら、これは、すべての可能な実施形態に対して限定するものではない。例示的なUTXOベースのプロトコルがビットコインを参照して記述されるが、これは同じように他の例示的なブロックチェーン・ネットワークで実装されてもよいことを注意されたい。
UTXOベースのモデルでは、各トランザクション（「Tx」）152は、一つまたは複数の入力202および一つまたは複数の出力203を含むデータ構造を含む。各出力203は、未使用のトランザクション出力（UTXO）を含んでいてもよく、これは、別の新しいトランザクションの入力202のためのソースとして使用できる（UTXOがまだ償還されていない場合）。UTXOは、デジタル資産の量〔額〕を指定する値を含む。これは、分散式台帳上でのトークンの設定された数を表す。UTXOは、他の情報の中でも、それが由来するところのトランザクションのトランザクションIDをも含んでいてもよい。トランザクション・データ構造はまた、入力フィールド（単数または複数）202および出力フィールド（単数または複数）203のサイズのインジケータを含んでいてもよいヘッダ201を含んでいてもよい。ヘッダ201はまた、トランザクションのIDを含んでいてもよい。諸実施形態において、トランザクションIDは、トランザクション・データ（トランザクションID自体を除く）のハッシュであり、ノード104に提出された生のトランザクション152のヘッダ201に格納される。
アリス103aは、問題のデジタル資産の量をボブ103bに移転するトランザクション152jを作成したいとする。図2において、アリスの新しいトランザクション152jは、「Tx1」とラベル付けされている。これは、シーケンスにおいて先行するトランザクション152iの出力203においてアリスにロックされているデジタル資産のうちのある量を取り、その少なくとも一部をボブに移転する。先行するトランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、単に任意のラベルである。これらは、必ずしも、Tx0がブロックチェーン151における最初のトランザクションであること、または、Tx1がプール154におけるすぐ次のトランザクションであることを意味しない。Tx1は、アリスにロックされた未使用出力203を依然として有する、任意の先行する（すなわち先立つ）トランザクションを遡ってポイントすることができる。
先行するトランザクションTx0は、アリスがその新しいトランザクションTx1を作成する時点において、または少なくともアリスがそれをネットワーク106に送信する時点までに、すでに検証され、ブロックチェーン150のブロック151に含められてもよい。それは、その時点ですでにブロック151のうちの1つに含まれてもよく、あるいは、順序付けられた集合154内でまだ待機していてもよく、その場合、まもなく新しいブロック151に含まれることになる。あるいはまた、Tx0およびTx1が一緒に生成されてネットワーク106に送信されることができ、あるいはさらには、ノード・プロトコルが「オーファン」トランザクションをバッファリングすることを許容する場合にはTx0がTx1の後に送信されることもできる。本明細書においてトランザクションのシーケンスの文脈で使用される「先行」および「後続」という用語は、トランザクション中に指定されたトランザクション・ポインタ（どのトランザクションがどの他のトランザクションをポイントするかなど）によって定義されるシーケンスにおけるトランザクションの順序のことをいう。それらの用語は、「先行者」および「後継者」または「先立つ」および「子孫」、「親」および「子」などに等しく置き換えることができる。これは、必ずしもそれらが作成される、ネットワーク106に送られる、または任意の所与のブロックチェーン・ノード104に到達する順序を意味するわけではない。にもかかわらず、先行トランザクション（先立つトランザクションまたは「親」）をポイントする後続トランザクション（子孫トランザクションまたは「子」）は、親トランザクションが有効確認されない限り、有効確認されない。親より先にブロックチェーン・ノード104に到着する子は、オーファンとみなされる。オーファンは、ノード・プロトコルおよび／またはノード挙動に依存して、破棄されてもよく、あるいは親を待つために、ある時間にわたってバッファリングされてもよい。
先行するトランザクションTx0の一つまたは複数の出力203のうちの1つは、本明細書でUTXO0とラベル付けされる特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の量を指定する値と、ロック・スクリプトとを含む。ロック・スクリプトは、後続のトランザクションが有効確認されるため、よってUTXOが正常に償還されるために、後続のトランザクションの入力202においてロック解除スクリプトによって満たされなければならない条件を定義する。典型的には、ロック・スクリプトは、前記量を特定の当事者（それが含まれているトランザクションの受益者）にロックする。すなわち、ロック・スクリプトは、ロック解除条件を定義し、典型的には、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされている当事者の暗号署名を含むという条件を含む。
ロック・スクリプト（別名scriptPubKey）は、ノード・プロトコルによって認識されるドメイン固有の言語で書かれたコードである。そのような言語の特定の例は、ブロックチェーン・ネットワークによって使用される「Script」（大文字のS）と呼ばれる。ロック・スクリプトは、トランザクション出力203を使用するためにどんな情報が必要とされるか、たとえば、アリスの署名を要求することを指定する。トランザクションの出力には、ロック解除スクリプトが現れる。ロック解除スクリプト（別名scriptSig）は、ロック・スクリプト基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で書かれたコードである。たとえば、ボブの署名を含んでいてもよい。ロック解除スクリプトは、トランザクションの入力202に現れる。
よって、図示した例では、Tx0の出力203におけるUTXO0は、ロック・スクリプト[Checksig PA]を含み、これは、UTXO0が償還されるために（厳密には、UTXO0を償還しようとする後続のトランザクションが有効であるために）、アリスの署名Sig PAを要求する。[Checksig PA]は、アリスの公開鍵・秘密鍵のペアからの公開鍵PAの表現（すなわちハッシュ）を含む。Tx1の入力202は、Tx1を指す（たとえば、諸実施形態ではトランザクションTx0全体のハッシュであるそのトランザクションID、TxID0によって）ポインタを含む。Tx1の入力202は、Tx0の任意の他の可能な出力の中でそれを識別するために、Tx0内のUTXO0を識別するインデックスを含む。Tx1の入力202は、さらに、鍵ペアからのアリスの秘密鍵をデータの所定の部分（暗号学において時に「メッセージ」と呼ばれる）に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig PA>を含む。有効な署名を提供するためにアリスによって署名される必要があるデータ（または「メッセージ」）は、ロック・スクリプトによって、またはノード・プロトコルによって、またはこれらの組み合わせによって定義されうる。
新しいトランザクションTx1がブロックチェーン・ノード104に到着すると、ノードはノード・プロトコルを適用する。これは、ロック解除スクリプトがロック・スクリプトにおいて定義されている条件を満たしているかどうかをチェックするために、ロック・スクリプトとロック解除スクリプトを一緒に実行する（この条件は一つまたは複数の基準を含みうる）。諸実施形態において、これは、2つのスクリプトを連結することを含む：
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<…>」は、データをスタック上に置くことを意味し、「[…]」はロック・スクリプト（この例ではスタックベースの言語）に含まれる関数である。同じことだが、スクリプトを連結するのではなく、共通のスタックを用いてスクリプトが順次実行されてもよい。いずれにせよ、一緒に実行されたとき、それらのスクリプトは、Tx0の出力におけるロック・スクリプトに含まれるアリスの公開鍵PAを使用して、Tx1の入力におけるロック解除スクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するためには、データの期待される部分自体（「メッセージ」）も含める必要がある。諸実施形態において、署名されたデータは、Tx1の全体を含む（よって、データの署名された部分がすでに内在的に存在するので、データの署名された部分を平文で指定する別個の要素が含まれる必要はない）。
公開‐秘密暗号による認証の詳細は、当業者にはおなじみであろう。基本的には、アリスが自分の秘密鍵を用いてメッセージに署名した場合、アリスの公開鍵と平文でのそのメッセージを与えられると、ノード104のような別のエンティティは、そのメッセージがアリスによって署名されたものであるはずであると認証することができる。署名することは、典型的には、メッセージをハッシュし、ハッシュに署名し、それを署名としてメッセージにタグ付けし、それにより、公開鍵の任意の保持者が署名を認証することを可能にする。よって、本稿における、ある特定のデータまたはトランザクションの一部に署名することなどへの任意の言及は、諸実施形態においては、そのデータまたはトランザクションの一部のハッシュに署名することを意味することができる。
Tx1のロック解除スクリプトが、Tx0のロック・スクリプトにおいて指定された一つまたは複数の条件を満たす場合（示した例では、アリスの署名がTx1において提供され、認証された場合）、ブロックチェーン・ノード104は、Tx1が有効であるとみなす。このことは、ブロックチェーン・ノード104がTx1をペンディング・トランザクションの順序付けられたプール154に追加することを意味する。ブロックチェーン・ノード104は、ネットワーク106全体に伝搬されるよう、トランザクションTx1をネットワーク106内の一つまたは複数の他のブロックチェーン・ノード104にも転送する。ひとたびTx1が有効確認され、ブロックチェーン150に含められると、これは、Tx0からのUTXO0を使用済みとして定義する。Tx1は、未使用のトランザクション出力203を使用する場合にのみ有効でありうることに留意されたい。別のトランザクション152によってすでに使用された出力を使用しようとする場合、たとえ他のすべての条件が満たされていても、Tx1は無効となる。よって、ブロックチェーン・ノード104は、先行するトランザクションTx0における参照されたUTXOがすでに使用されているかどうか（すなわち、すでに別の有効なトランザクションへの有効な入力を形成しているかどうか）もチェックする必要がある。これが、ブロックチェーン150がトランザクション152に関する定義された順序を課すことが重要である理由の1つである。実際上は、所与のブロックチェーン・ノード104は、トランザクション152が使用されたUTXO 203をマークする別個のデータベースを維持してもよいが、最終的には、UTXOが使用されたかどうかを定義するのは、ブロックチェーン150内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
所与のトランザクション152のすべての出力203において指定された総量が、そのすべての入力202によってポイントされた総量よりも大きい場合、これは、ほとんどのトランザクション・モデルにおいて無効性の別の根拠である。したがって、そのようなトランザクションは、伝搬されたり、ブロック151に含められたりすることはない。
UTXOベースのトランザクション・モデルでは、所定のUTXOが全体として使用される必要があることに注意されたい。使用されるUTXOにおいて定義されている量のうち、別の量が使用される一方で一部を「残しておく」ことはできない。ただし、UTXOからの前記量は、次のトランザクションの複数の出力のあいだで分割できる。たとえば、Tx0におけるUTXO0において定義された量は、Tx1における複数のUTXOの間で分割できる。よって、アリスがボブにUTXO0で定義された量のすべてを与えることを望まない場合、残りを使って、Tx1の第2の出力において自分自身におつりを与えたり、あるいは別の当事者に支払ったりすることができる。
実際上は、アリスは通例、アリスのトランザクションをブロック151に含めることに成功するビットコイン・ノード104のための手数料を含める必要もある。アリスがそのような手数料を含めない場合、Tx0は諸ブロックチェーン・ノード104によって拒否される可能性があり、よって、技術的には有効であるが、伝播され、ブロックチェーン150に含められない可能性がある（ノード・プロトコルは、ブロックチェーン・ノード104が望まない場合には、トランザクション152を受け入れるよう強制しない）。いくつかのプロトコルでは、トランザクション手数料は、独自の別個の出力203を必要としない（すなわち、別個のUTXOを必要としない）。その代わりに、所与のトランザクション152の入力（単数または複数）202によってポイントされる総量と出力（単数または複数）203において指定される総量との間の任意の差は、トランザクションを公開するブロックチェーン・ノード104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1は1つの出力UTXO1しかもたないとする。UTXO0において指定されたデジタル資産の量がUTXO1において指定された量より多い場合、その差はUTXO1を含むブロックを生成する作業証明競争に勝つノード104によって割り当てられてもよい。しかしながら、代替的または追加的に、トランザクション152のUTXO 203のうちの独自のものにおいてトランザクション手数料が明示的に指定できることは必ずしも除外されない。
アリスおよびボブのデジタル資産は、ブロックチェーン150内の任意のところで任意のトランザクション152において、両者にロックされたUTXOからなる。よって、典型的には、所与の当事者103の資産は、ブロックチェーン150を通じて、さまざまなトランザクション152のUTXO全体に分散される。ブロックチェーン150内のどこにも、所与の当事者103の総残高を定義する1つの数は記憶されていない。それぞれの当事者にロックされ、別の前進（onward）トランザクションにまだ使用されていないすべてのさまざまなUTXOの値を一緒に照合することは、クライアント・アプリケーション105におけるウォレット機能の役割である。これは、ビットコイン・ノード104のいずれかに記憶されているブロックチェーン150のコピーを問い合わせることによってできる。
スクリプト・コードは、概略的に（すなわち、厳密な言語を使わずに）表現されることが多いことに注意されたい。たとえば、特定の関数を表すためにオペレーション・コード（オペコード）を使用してもよい。「OP_....」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロック・スクリプトの先頭においてOP_FALSEが先行する場合、トランザクション内にデータを格納し、それによりブロックチェーン150において変更不能な形で該データを記録することができるトランザクションの使用不能な（unspendable）出力を生成する、Script言語のオペコードである。たとえば、該データは、ブロックチェーンに格納することが望まれる文書を含むことができる。
典型的には、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。諸実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名する。いくつかの実施形態において、所与のトランザクションについて、署名は、トランザクション入力の一部、および諸トランザクション出力のうちのいくつかまたは全部に署名する。署名される出力の特定の部分はSIGHASHフラグに依存する。SIGHASHフラグは通例、署名の末尾に含まれる4バイトのコードであり、どの出力が署名されるか（よって、署名の時点において固定されるか）を選択する。
ロック・スクリプトは、典型的にはそれぞれのトランザクションがロックされる当事者の公開鍵を含んでいるという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には対応する署名を供給するという事実を指して「scriptSig」と呼ばれることがある。しかしながら、より一般には、UTXOが償還されるための条件が署名を認証することを含むことは、ブロックチェーン150のすべてのアプリケーションにおいて必須ではない。より一般的には、スクリプト言語を使用して、一つまたは複数の条件を定義することができる。よって、より一般的な用語である「ロック・スクリプト」および「ロック解除スクリプト」が好まれることがある。
4.3.サイド・チャネル
図1に示されるように、アリスとボブのそれぞれのコンピュータ設備102a、120b上のクライアント・アプリケーションは、追加的な通信機能を有していてもよい。この追加的な機能は、アリス103aがボブ103bと別のサイド・チャネル107を確立することを可能にする（いずれかの当事者またはサードパーティーの刺激により）。サイド・チャネル107は、ブロックチェーン・ネットワークとは別にデータの交換を可能にする。そのような通信は、「オフチェーン」通信と呼ばれることもある。たとえば、これは、当事者の一方がそれをネットワーク106にブロードキャストすることを選択するまで、トランザクション（まだ）がブロックチェーン・ネットワーク106に登録されることも、チェーン150にはいることもなく、アリスとボブの間でトランザクション152を交換するために使用されてもよい。このようにしてトランザクションを共有することは、「トランザクション・テンプレート」を共有することと呼ばれることもある。トランザクション・テンプレートは、完全なトランザクションを形成するために必要とされる一つまたは複数の入力および／または出力を欠いていてもよい。代替的または追加的に、サイド・チャネル107は、鍵、交渉された額または条件、データ内容などのような、他のトランザクション関連データを交換するために使用されてもよい。
サイド・チャネル107は、ブロックチェーン・ネットワーク106と同じパケット交換ネットワーク101を介して確立されてもよい。代替的または追加的に、サイド・チャネル301は、モバイル・セルラー・ネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、さらにはアリスとボブのデバイス102a、102bの間の直接の有線または無線リンクを介して確立されてもよい。一般に、本稿のどこかで言及されているサイド・チャネル107は、データを「オフチェーン」で、つまりブロックチェーン・ネットワーク106とは別個に交換するための、一つまたは複数のネットワーク技術または通信媒体を介した任意の一つまたは複数のリンクを含むことができる。複数のリンクが使用されている場合、オフチェーンリンクのバンドルまたはコレクション全体は、サイド・チャネル107と呼ばれることがある。したがって、アリスとボブがサイド・チャネル107を通じてある種の情報やデータなどを交換すると言われている場合、これは必ずしもこれらのすべてのデータが厳密に同じリンク、またはさらには同じタイプのネットワークを通じて送信される必要があることを意味しないことに注意されたい。
サイド・チャネル107は、アリスやボブなどの当事者間の安全でプライベートなオフチェーン通信を可能にするために、既知の安全な通信技術を用いる安全なチャネルを含んでいてもよい。たとえば、安全なチャネルは、安全なチャネルを通じて通信する当事者間で共有される共有秘密に基づいていてもよい。そのようなチャネルは、たとえば、検証者103Vと目標者103Tの間で通信するために使用されてもよい。たとえば、検証者103Vが目標者によって保持されておるPUF 302/500にチャレンジを提出し、対応する応答を受信できるようにするためである。
5. ブロックチェーン・ベースのPUF ID証明
前の節で述べたように、応答の記録となるレスポンス・データは、信頼されるサードパーティー・システム602を用いるのではなく、公開のブロックチェーンに記憶されてもよい。レスポンス・データは、セットアップ時に決定されたデータであり、後に、目標者103T（「アリス」）による目標の素性の主張を試験するために、検証者103V（「ボブ」）によって使用されうる。ここでもまた、アリスとボブは単に任意のラベルであり、アリスとボブは、必ずしも、セクション4で与えられたブロックチェーン・システムの一般的概観（そこではボブはアリスのトランザクションの出力を消費していた）と同じ役割ではないことに注意されたい。
前述のように、所与のCRペア{Ci,Ri}についてのレスポンス・データは、（チェーンに記憶されているか、他の場所に記憶されているかにかかわらず）下記のいずれかを含んでいてもよく、それはセットアップ・フェーズ702において決定され、検証者103Vによる将来の参照のために記憶される：
i）チャレンジCiおよび／またはレスポンスRiの（平文でのまたは暗号化された）明示的な値、または
ii）マスター・チャレンジCmにリンクされたレスポンスRiの明示的な値（マスター・チャレンジから、それぞれのレスポンスRiについての特定のチャレンジCiが導出できる）、または
iii）レスポンスRiの証跡（たとえばハッシュまたはダブルハッシュ）とチャレンジCiの明示的な値、または
iv）マスター・チャレンジCmにリンクされたレスポンスRiの証跡（たとえばハッシュまたはダブルハッシュ）（マスター・チャレンジから、それぞれのレスポンスRiについての特定のチャレンジCiが導出できる）、または
v）レスポンスRiから導出された公開‐秘密鍵ペアの公開鍵。
図9に示されるように、どのような形を取るにせよ、セットアップ・フェーズ702において、そのようなレスポンス・データ901がブロックチェーン150に記録されたトランザクション152Sの出力203に格納されることができる。これは、以下ではストレージ・トランザクションと呼ばれることがある。たとえば、上記のセクション4で論じられている技法を使用して、チェーン上に記録されてもよい。ここでもまた、該セクションのアリスが必ずしも目標者103Tではなく、該セクションのボブが必ずしも検証者103Vではないことに注意されたい――実際、現在アリスと呼ばれている目標者103Tは、チェーン上に記録されるストレージ・トランザクション152Sを定式化して送信する者であってもよい。別の例として、信頼されるサードパーティーが、セットアップ時に生成されるレスポンス・データ901を含めることによって完成する、目標者103Tについてのストレージ・トランザクションのテンプレートを定式化して、チェーン上に記録されるように転送してもよい。目標者103Tは、ストレージ・トランザクション152Sを、ブロックチェーン・ネットワーク106を通じて伝播されるようブロックチェーン・ノード104のいずれかに直接送信してもよく、あるいは信頼されるサードパーティーなどの別の当事者を介して間接的に送信してもよい。さらに別の例として、目標者103Tは、自分のレスポンス・データ901を信頼されるサードパーティーに送信し、信頼されるサードパーティーがそれをストレージ・トランザクション152中に定式化して、チェーンに記録されるように送信してもよい。
レスポンス・データ901は、ストレージ・トランザクション152Sの使用不能な出力に格納されてもよい。たとえば、これは、Scriptプロトコルを使用している場合は、OP_RETURN、またはOP_FALSEおよびその後のOP_RETURNによって使用不能にされてもよい（BTCやBCHのような一部のブロックチェーン・プロトコルでは、OP_RETURNを含めると出力が使用不能になるが、BSVのような他のプロトコルでは、出力を使用不能にするためにOP_FALSEとOP_RETURNの両方が必要である）。BTC（Bitcoin［ビットコイン］）、BTC（Bitcoin Cash［ビットコイン・キャッシュ］）、およびBSV（Bitcoin Satoshi Vision［ビットコイン・サトシ・バージョン］）は、前述のブロックチェーン・システムの異なる例示的実装である。
あるいはまた、レスポンス・データ901はストレージ・トランザクション152Sの使用可能な出力に埋め込まれてもよい。たとえば、これは、OP_FALSEなしでOP_RETURNを含めることによって、使用可能に保つことができる。別の例として、OP_DROPコードの直前に含めることによって、使用可能なロック・スクリプトにデータを埋め込むことができる。これはBTC、BCH、BSVにも同様に適用される。
諸実施形態では、所与の目標者103Tの複数の異なるCRペア{Ci,Ri}のセットのレスポンス・データ901が格納されうる。これらは、ストレージ・トランザクション152の同じ出力203に格納されても、または異なる出力203に格納されてもよく、または一部が同じ出力、一部が異なる出力という組み合わせであってもよい。それらは、同じストレージ・トランザクション152Sに格納されてもよく、または異なるCRペアのレスポンス・データ901は異なるストレージ・トランザクション152Sに格納されてもよく、または一部は同じトランザクション、一部は異なるトランザクションという組み合わせであってもよい。
なお、オンチェーンの格納は必ずしもアカウント・ベースのモデルに限定されない。代替的な展開では、レスポンス・データ901は、アカウント・ベースのモデルの一つまたは複数のトランザクションの一つまたは複数のスマート・コントラクトに格納することができる。
検証フェーズ704では、検証者103Vが目標の素性を検証したい場合、検証者103Vは、特定のCRペアに対応するレスポンス・データ901をストレージ・トランザクション152Sから取得するために、ブロックチェーン150にアクセスする。諸実施形態において、これは、検証者103Vに、特定のチャレンジCiに対応するレスポンスRi、またはそのレスポンスRiの証跡（たとえばハッシュまたはダブルハッシュ）を与える。検証者103Vはまた、目標者103VにチャレンジCiを提出し、応答して、目標者103T（またはそのデバイス）が受信したチャレンジCiをPUFモジュール603に入力することによって生成するレスポンスR’i（であると標榜されるもの）を受信する。次いで、検証者103Vは、返されたレスポンスR’iをチェーン上のストレージ・トランザクション152Sから取得されたバージョンを比較するか、または受信されたレスポンスに対して、証跡のために使用されたのと同じ変換（たとえばH(R’i)またはH2(R’i)）を適用し、これをチェーン上のストレージ・トランザクション152Sから取得された証跡と比較する。どちらの仕方でも、比較が一致を与える場合は、目標が検証される。
検証者103Vがブロックチェーン150にアクセスするのは、ブロックチェーン・ネットワーク106のノード104のいずれかを介してである、または代替的に、任意の外部当事者からレスポンス・データを取得することによってである。外部当事者は、そのデータ（すなわち、トランザクション）がブロックチェーンに含まれていることのマークル証明をも提供してもよい。
レスポンス・データ901がブロックチェーン150のような公開媒体に格納されている実施形態では、実際のレスポンス値Ri自体は公開でまたは無制約に開示されないことが望ましいことがありうる。そうしないと、悪意のある任意の当事者がチェーン上のRiを参照し、Ciでチャレンジされた場合に目標者103Tであると偽ることができる。そのため、チェーン上に保持されているレスポンス・データ901としてはRiの証跡（たとえばH(Ri)またはH2(Ri)）のみを格納するか、またはRiの明示的な値を格納するが暗号化された形とすることが好ましいことがありうる。または、場合によっては証跡が暗号化された形でチェーン上に格納されることができる。
複数の検証者が存在する可能性がある場合、Riまたはその証跡を暗号化された形で格納することで、目標者103Tまたは信頼されるサードパーティーは、どの検証者103VがどのCRペアに対応する格納データ901を取得できるかを制御できる。これは、あるレスポンス・データ901のための解読鍵を所与の検証者にのみ与え、別のレスポンス・データ901のための解読鍵を別の検証者にのみ与えることによって達成できる。解読鍵の配布は、目標者103Tまたは信頼されるサードパーティーによって管理できる。各検証者または検証者の部分集合は、レスポンス・データ901（たとえばCRペア）のそれぞれの部分集合にアクセスするための一つまたは複数の解読鍵の独自の部分集合を与えられる。好ましくはそれらの部分集合は互いに排他的であるが、他の実装では重なりがあってもよい（たとえば、同じ組織内の異なるグループがCRペアの重複する部分集合へのアクセスをもつことができる）。
これの変形として、レスポンス・データ901（たとえばCRペア）がオンチェーンではなくサードパーティーのシステム602に格納されている場合、解読鍵を配布する代わりに（またはそれに加えて）、各検証者がCRペアの自分自身の部分集合（またはより一般にはレスポンス・データ）に対するアクセスを得るだけであることを保証するために、他の手段が用いられてもよい。たとえば、信頼されるサードパーティーのシステム602は、各検証者について、パスワードで保護されたアカウントを維持してもよく、検証者は自分のチャレンジ（単数または複数）へのアクセスを得るためにこれにログインすることが求められ、自分自身のCRペア（単数または複数）へのアクセスのみが与えられる。
そのような方式は、セキュリティ上有利でありうる。所与のCRペアのレスポンスRiが一検証者103Vに開示される場合、同じCRペアは別の検証者103Vのためには使用されないことが望ましい場合がある。そうしないと、第1の検証者103Vは、今既知となったレスポンスRiを使用して、別の検証者に対して自分が目標者103Tであると見せかけることができる。ただし、レスポンス・データ901へのアクセスをもつすべての潜在的な検証者103Vが信頼されている場合は、これを防ぐための措置を講じることは必須ではない。
さらなる変形では、チェーンに格納されたレスポンス・データ901は、対応するレスポンスRiに基づいて（たとえば、それを種として使って）セットアップ時に生成される公開‐秘密鍵ペアの公開鍵である、目標者103Tの公開鍵の形式をとることができる。この場合、検証者103Vは、ストレージ・トランザクション152Sからの公開鍵にアクセスし、それを使用して、対応する秘密鍵を用いて目標者103Tによって署名されたメッセージを検証する。場合によっては、異なる公開鍵が異なる検証者103Vによる使用のために割り当てることができるように、公開鍵は暗号化された形式でチェーンに格納されることができる。
図9にも示されているように、出力（たとえばUTXOベース）モデルを用いる実施形態では、これは、CRペア（またはそこから導出された鍵）を管理するための効率的な機構を提供するために活用されうる。ここでの管理は、CRペアまたは鍵を更新するまたは失効させる（たとえばひとたび（検証において使用されて）消費されたら）ことを含みうる。
これを行うために、新しい修正子トランザクション152Mがブロックチェーン150に記録される。これは、失効または更新されるべきレスポンス・データ901が格納されているストレージ・トランザクション152Sの出力203のいずれかをポイントする入力202をもつ。これは、その出力を「使用する」、「償還する」、または「割り当てる」と呼ばれることがある（ただし、これは必ずしも金銭的価値の移転を含意するものではないことに注意されたい）。これは、検証者103Vによって認識されたレイヤー2プロトコルのレベルでは、ポイントされたストレージ・トランザクション152Sまたは出力203におけるレスポンス・データ901がもはや使用されないことを意味する。修正子トランザクション152M自体が、自分の出力の一つにレスポンス・データ901’を含む場合、これは、新しいレスポンス・データ901’が以前のレスポンス・データ901の置換（たとえば、新しいCRペア）を表すことを表していると解釈される。検証者が、検証操作において使用するレスポンス・データを見つけるためにブロックチェーン150にアクセスする場合、置換されたバージョン（the replaced version）ではなく、更新されたバージョン（the updated version）901’を使用する。一方、修正子トランザクション152Uが置換レスポンス・データ901を含まない場合、それは、単にストレージ・トランザクション152Sにおけるレスポンス・データ901またはそれがポイントする出力203を失効させると解釈される。
いくつかの実施形態では、レスポンス・データ901はストレージ・トランザクション152Sの使用可能な出力に埋め込まれており、レスポンス・データ901（たとえばCRペア）が格納されている特定の出力203を使用する（すなわち、割り当てるまたは償還する）ことによって、失効または更新されうる。そのようないくつかの実施形態では、異なるCRペアに対応する異なるレスポンス・データ901が、同じストレージ・トランザクション203の個々の出力203に格納され、個々に呼び出されたり更新されたりしてもよい。
他の実施形態では、レスポンス・データ901は、ストレージ・トランザクション152Sの使用不能な出力に格納され、ストレージ・トランザクション152Sの異なる使用可能な出力を消費する（すなわち、割り当てるまたは償還する）ことによって、失効されたり更新されたりしうる。いくつかのそのような実施形態では、複数の異なるCRペアに対応する複数のストレージデータ901（同じまたは異なる使用不能な出力に格納）は、同じトランザクション152Sの同じ使用可能な出力を消費することによって、失効されたり更新されたりしうる。
例示的な使用事例として、CRペアに対応するレスポンス・データ901のレコードは、ひとたび消費されると、すなわち検証において使用されると、失効されたり更新されたりしうる。これは、レスポンス・データ901がRiの明示的なレコードであるか、証跡であるか、またはRiから導出された公開鍵であるかによらず、当てはまる。いずれにせよ、これはセキュリティ上の理由から有利でありえ、よって、今や世界に公開されたレスポンス・データは再び使用可能になることはない。
修正子トランザクション152Mが定式化され、目標者103Tによってチェーンに記録されるように送信されることができる。それは、伝搬するようブロックチェーン・ノード104に直接送信されてもよく、または中間当事者を介して間接的にノード104に送信されてもよい。あるいはまた、信頼されるサードパーティーがテンプレート・トランザクションを送信し、それを目標者が（たとえば、置換レスポンス・データ901’に署名するおよび／または置換レスポンス・データ901’を追加することによって）完成させて、チェーン上に記録されるよう、直接または間接的にノード104に転送してもよい。別の可能性として、信頼されるサードパーティーが修正子トランザクション152Mを定式化することができ（可能性としては、テンプレート、または、たとえば置換レスポンス・データ901’を含む目標者103Tから送信された何らかのデータに基づいて）、その後、信頼されるサードパーティーが、チェーン上に記録されるよう、修正子トランザクション152Mをノード104に送信してもよい。これらのオプションはすべて、ストレージ・トランザクション152Sがブロックチェーン150に記録される方法にも適用されうることに注意されたい。
上記で論じたさまざまな概念によると、i）素性（または公開鍵などの他の関連情報）をUTXOにリンクし、このUTXOの使用状態（spend-state）を素性クレデンシャル〔資格情報〕のための有効性のプロキシとして使用し；ii）セットアップ、失効、更新、検証などの効率的な素性管理動作を実行するための一連のトランザクションを確立するためのシステムが提供される。プロセスは、すべての当事者が常に互いに通信する必要があるのではなく、すべての当事者がブロックチェーンを参照して、CRPが消費される、または素性が失効させられる時を確認できるため、通信の数が削減されるという点でより効率的である。
そのような技法は、たとえば、検証において使用されるCRPデータを処理するためにサードパーティーのKYC（know your customer［顧客本人確認］）プロバイダーに頼るのを最小限に抑えることによって、以前に示したように、素性をPUFデバイスにリンクするためのフレームワークを拡張するために使用されうる。この目標は、KYCプロバイダーの役割、あるいはむしろ一部の機能を公開のブロックチェーンで部分的に置き換えることによって達成されうる。それにより、ユーザーは、サードパーティーとは無関係に、ePUFデバイスに関連する独自の素性資格情報をインスタンス化できる。
素性システムにおける信頼されるサードパーティーの役割は必ずしも完全に回避されるわけではないが、いずれにしても、素性管理のプロセスが改善でき、それにより、プロセスにおけるその関与と関連する負担が少なくとも軽減される。
5.1. PUF素性のUTXOセットへのリンク
前の諸セクションで論じたような、ブロックチェーンの使用が素性システムを改善できる第1の側面は、公開ブロックチェーンの未使用トランザクション出力セット（UTXOセット）を使用して、PUF素性に関連するCRPを管理することによる。
このセクションでは、CRPをUTXOセットのメンバーにマッピングし、「使用済み」または「未使用」状態としてのそのステータスを、それぞれの特定のCRPが素性検証プロセスにおいて消費されたかどうかの指示として使う2つの異なる例示的な機構を示す。第1の機構は、CRPデータを使用可能なUTXOに埋め込むことに関わり、第2の機構は、CRPデータを使用可能なUTXOとペアリングすることに関わる。いずれの場合も、CRPまたは問題の素性に関連する追加的なデータも、任意的にシステムに含められてもよい。
5.1.1. 使用可能なUTXOへの埋め込み: 第1の機構は、CRPを使用可能なUTXOにバインドするものである。使用可能なUTXOは、その条件が将来の入力によって満たされることができるスクリプトを含むトランザクション出力であり、よって、将来の使用トランザクション〔支出トランザクション〕（spending transaction）によって消費できる。
そのような埋め込みを実装するには多くの異なるオプションがあるが、我々の目的のためには、これは一般的に少なくとも、次のロック・スクリプトからなる：
[Checksig P] OP_RETURN <Rep(C,R)>
ここで、[Checksig P]は標準的な公開鍵ハッシュに対する支払い（pay-to-public-key-hash、P2PKH）ロック・スクリプトであり、Rep(C,R)は特定のチャレンジ‐レスポンス・ペア(C,R)の表現である。
このロック・スクリプトは、単に、使用トランザクション上で有効な署名SigPを提供することによってロックを解除できる。ここで、署名は公開鍵Pに対して有効であると見なされる。オペコードOP_RETURNに続く任意のデータは使用トランザクションを有効確認するときに考慮されず、よって、このデータは任意として扱われ、ブロックチェーン有効確認者に関してフォーマットされていなくてもよいことに注意する必要がある。
上記のスクリプトにおけるOP_RETURNコードに続くデータは、チャレンジ-レスポンス・ペア(C,R)の表現Rep(C,R)である。この表現は、問題の使用事例に依存して、さまざまな仕方で作成できる。ただし、賢明な例は、PUFを所有する証明者アリスだけが知っている鍵kを使用してCRPを暗号化する（encrypt）ことであろう。この場合、次のいずれかの表現を使用できる。
Rep(C,R)＝Encrypt(C,k)
Rep(C,R)＝Encrypt(R,k)
Rep(C,R)＝Encrypt(C||R,k)
これらの表現は、アリスが、自分のUTXOに含まれていたチャレンジ、レスポンス、またはCRPをそれぞれ後で取得または証明することを許容する。
追加的なスクリプト障害（encumbrances）: 前に示した基本的なロック・スクリプトを拡張して、将来、出力を使用する入力スクリプトに対する追加的な条件を含めることが可能である。そのような追加条件の賢明な例は、次のスクリプトであろう：
[Checksig P][Hash Puzzle H2(R)] OP_RETURN<Rep(C,R)>
ここで[Hash Puzzle H2(R)]＝OP_HASH160<H(R)>OP_EQUALである。他のハッシュ関数オペコードを使用してもよいことに注意されたい。この修正されたスクリプトは、今や、公開鍵Pについての有効な署名を提供することに加えて、チャレンジRのハッシュを明らかにすることを使用者に要求する。ここでの発想は、いくつかのシナリオでは、これは、使用者が問題のチャレンジRに関連する情報H(R)を知っているという知識証明のために使用できるということである。
トランザクション・モデル: 使用されるトランザクション・ロック・スクリプトの厳密な構造が決定されているとすれば、CRPを記憶し、証跡を残し（attest）、管理するすべとして、これらのスクリプトを含むトランザクションをどのように構造化するかについて選択を行うことができる。
ここでは、CRPと関連するロック・スクリプトを一対一でUTXOにマッピングすることが開示される。つまり、そのようなスクリプトを含むすべてのUTXOは、特定のPUFデバイスに関連するちょうど1つのCRPに対応する。
次いで、これらのUTXOをトランザクションに編成する方法について、いくつかのオプションがある。最も可能性の高い可能なオプションは次のとおりである：
1. トランザクションごとに1つのCRP。
2. トランザクションごとに1つのCRP集合。
3. トランザクションごとに1つのPUF。
第1のオプションは、遺言書の更新など、使用頻度が非常に低いPUFなどのためのいくつかの場合において適用可能でありえ、複数のCRPが明らかに相互にリンクされていないという利点がある。これは、あるCRPの消費および曝露（revelation）が他のどのCRPとも独立して明かされることができるため、極端なプライバシーが必要とされる状況でも有用でありうる。
下記の表1のトランザクションは、第1のオプションの例示的実装である。トランザクションは単一の入出力のみを含み、よって、各CRPは異なるトランザクションに含まれることがわかる。その出力が使用されると、このトランザクションの素性システムにとっての有意性は、監査目的以外では事実上終了する。
Figure 2023543456000002
第2のオプションは、多くのCRPが単一のトランザクションにおいてそれぞれのUTXOにマップピングされるので、CRP消費の期待される頻度がかなり高い、銀行カードなどの使用事例のために、より望ましいことがありうる。下記の表2のトランザクションは、これがどのように達成されるかを示している。
アリスによって生成されたものである可能性が高い入力署名は、出力の集合全体に対して署名させられることができる。これは、諸UTXOの、異なるCRP自体への一対一のマッピングを維持しつつ、1つの公開鍵PAから多くのUTXO、よって多くのCRPへの一対多のリンクを提供する。また、再使用を避けるために、各出力/CRPは独自の関連付けられた公開鍵（すべてアリスが所有）をもつことも想定されている。
Figure 2023543456000003
上記のオプションは、時間とともにCRP集合
を更新する実施形態とうまく統合することもでき、更新された集合が生成されるたびに、その集合のために新しいトランザクションが発行されることができる。さらに、並列な独立した（すなわち関連しないオンチェーンの）トランザクションを介して、同じPUFについて、同時に複数の異なるCRP集合を生成して発行することもできる。複数の異なる信頼されるサードパーティー（たとえば異なる銀行）と素性を確立するために有用でありうる。その際、素性はいずれも独立して確立されるが、それでも同じPUFによってアンカーされる。
単一のPUFを表すために単一のトランザクションが使用されるという第3のオプションは、単にオプション2をより制約したバージョンであり、更新は可能ではない。これは、PUFを含むデバイスが特定の「寿命」を与えられている場合に適用可能でありうる。ここで、デバイスは、ユーザーに新しいデバイスを発行される前には、事前に決定された数の認証のために使用できるだけである。
5.1.2. 使用可能なUTXOとのペアリング
使用可能なUTXO内にCRPを埋め込むことに対するある代替は、単にCRPをこれらの出力とペアリングすることである。この場合、デジタル証明書に関する既存の業績との違いは、アリスがどんなサードパーティーからも独立して素性の証跡を残すことを望む可能性があるため、トランザクションがアリスによって構築され署名されうるということである。
Figure 2023543456000004
上の図では、n個のCRPに関連する2n個の出力を含む例示的なトランザクションを見ることができる。これにより、各使用可能な出力はCRPのうちの1つにマッピングでき、CRP表現自体が対応する使用不能な出力（たとえば、OP_FALSE OP_RETURN）に含まれている。また、諸CRPを諸トランザクションおよび諸UTXOに編成するための3つの可能な変形は、ここでも同様に適用されることに注意しておくべきである。
5.1.3. ディスカッション
CRP管理に対する利点: 諸CRPを諸UTXOにマッピングするという概念は、前の諸セクションからの素性プロトコルのユーザーについてのCRP管理および処理を大幅に改善することができる。一つの利点は、CRPの格納および検索をブロックチェーン・ネットワーク106と、ブロックチェーン・ネットワーク106からの信頼できる取り出しを容易にできるサービス・プロバイダーに部分的にオフロードできることである。
特定のPUFのすべての「ライブ」CRPを諸UTXOにマッピングすることによって、素性システム内の所与のPUFにとって現在利用可能であるCRPに関する正確な情報のためにUTXOセットの状態を照会することによって、CRP更新プロセスを改善することができる。
説明してきたブロックチェーンとUTXO-CRPマッピング規約を利用した単純なプロセスの例は次のようなものである：
1. アリスがPUFデバイスを取得し、CRPの集合を(C1,R1),(C2,R2),…,(Cn,Rn)として列挙する。
2. アリスは表2に示されるようなトランザクションTxIDCRP-Setを生成し、ブロックチェーン・ネットワークにブロードキャストする。
3. アリスは、自分の素性をサードパーティーと認証するために、複数のCRPを時間の経過とともに消費する。
4. アリスは、今、今後1週間についての自分の期待される活動をカバーするのに十分なCRPをもっているかどうかをチェックすることを望む。
1. アリスは、ブロックチェーン・ノード104、またはSPVに似たサービス・プロバイダーに問い合わせ、TxIDCRP-SetのどのUTXOが現在未使用であるかを尋ねる。
2. ブロックチェーン・ノードまたはサービス・プロバイダーは、まだ未使用のトランザクションTxIDCRP-Setの出力の数をもって応答する。
5. 返された数が不十分である場合、アリスは自分の信頼されるサードパーティーと素性更新プロセスを実行するか、または独立して確立された素性のためにさらなるCRPを列挙することができる。それ以外の場合、アリスはアクションを行わない。
埋め込みかペアリングか: CRPを使用可能な出力内に埋め込むか、単に出力とペアリングするかの選択は、アリスに、これらのケースを区別する2つの異なる利点の間の選択権を与える。
CRPが使用可能な出力内に埋め込まれる場合、これはブロックチェーン・ネットワーク106を維持するブロックチェーン・ノード104に、これらの出力のデータをすぐ利用可能な状態に保つインセンティブを与える。これは、アリスの問い合わせへの応答がより速くなる可能性があり、さらに重要なことに、ブロックチェーン・ノードは、これらのトランザクション出力の生データをアリスに返すことができる可能性が高くなることを意味する。
以前に論じたように、CRPの表現Rep(C,R)は、チャレンジ、レスポンス、またはその両方の生の（または難読化された）データを含むように含まれている場合、これは、アリスが、ブロックチェーン・ネットワーク106から関連情報を取り出すことができることを意味する。これは、アリスはローカル・ストレージを置き換え、ブロックチェーン150を用いてより軽量なシステムを運用することを許容する。使用可能な出力にデータを埋め込むことは、それに関係なくアリスのデータが高い可用性をもつ可能性を高めるためである。
対照的に、CRPが使用可能な出力とペアリングされているだけである場合、アリスは自分にとって利用可能なCRPがいくつかるかを判別できるだけであり、必ずしもビットコイン・ノードから表現データ自体を取り出すことはできないことがありうる。これは、アリスが自分のCRP集合をローカルに維持しない場合、アリスはブロックチェーン・ノード・ネットワーク106の外部のエージェントに相談する必要があることを意味しうる。
ダブルハッシュの使用: 上記の例示的実装では、ダブルハッシュH2(Data)が、何らかのDataのオンチェーン表現として使用できることが示される。このようにダブルハッシュを使用する理由は、それがシングルハッシュがオンチェーンで明かされることも許容し、原理的にある当事者がH(Data)を知っているという知識証明のように作用し、シングルハッシュはDataに関連付けられている。
これは、たとえば、たとえば、PUF素性状況において有用でありうる。ここで、H2(R)は、H(R)を提供するサードパーティーによって満たされることができる（アリスがRの実際の値を彼らと共有していた場合）使用障害（spending encumbrance）としてアリスによってオンチェーンで記録される。
マルチパーティー署名: このセクションにおいて詳細に説明されているトランザクションは、アリスによるPUF素性の証跡を残すこと（attestation）を支援するために、複数の異なる当事者からのより多くの署名を含みうる可能性もある。たとえば、アリスとサードパーティーの素性プロバイダーの両方が、アリスの素性の検証者の信頼を改善する方法として、CRPトランザクションの入力（単数または複数）に署名することが望ましいことがありうる。これは、カウンターサインする者が、ブロックチェーン・トランザクションに署名するために使用されるアリスの公開鍵（単数または複数）の証跡を示すことができる認証機関である場合に、特に有意である。単に複数の署名（すなわち「マルチシグ（multi-sig）」）の代わりとして、たとえば閾値署名または鍵分割技術（たとえば、シャミル秘密共有［Shamir Secret Sharing］）によって、複数の当事者が署名プロセスに含められてもよい。
5.2. トランザクションを使用した効率的な素性管理
前述のようなPUFベースの素性システムとの関連でブロックチェーンが使用されうる追加的な方法は、PUFデバイスによってセキュリティ保護された素性鍵またはトークンを失効させる効率的な手段としてである。
デジタル証明書管理に関してなされたこれまでの業績において、オンチェーンで証明書を発行し、失効させることが知られており、対応する証明書検証プロセスがこれに付随している。アリスが自分のPUFベースの素性に対してオンチェーンで証跡を残す（attest）ときに、アリスが認証機関と協力する用意があるシナリオを考える。アリスが自分の素性についての証明書をオンチェーンで登録するプロセスは次のとおりである：
1. 認証局（CA）がアリスの素性を検証する。
2. CAが証明書トランザクションを生成する。このトランザクションは、次の入力および出力をもつ。
a. 入力: CAの署名および公開鍵を含むロック解除スクリプトをもつCAのUTXO。
b. 出力1: P2PKHロック・スクリプト。
c. 出力2: アリスの公開鍵を含むOP_RETURN出力。
3. トランザクションはブロードキャストされ、ひとたびマイニングされると、CAはアリスにトランザクションID TXIDCTX-PKAを提供する。
このプロセスのつまるところは、アリスと認証局が協力して、CAによって署名された、使用不能な出力を含むトランザクションを生成することである。該使用不能な出力は、アリスの公開鍵に関する証明書と、CAが該証明書を失効させるために使用できる、該証明書とペアになった使用可能な出力とを含む。
ここに開示されている諸実施形態は、上記のデジタル証明書のために概説された方法と、前述の方法の1つのようなPUFベースの素性を確立する方法のハイブリッドを使用する。ここでPUF素性システムに追加された要素は、汎用の信頼されるサードパーティー（CAに類似）が、UTXOを消費することによって、CRPまたは関連する公開鍵を「失効させる」〔取り消す〕（revoke）ことができるようにするためのものである。
信頼されるサードパーティーがアリスの公開鍵に関する証明書を失効させる場合は、先に論じた暗号学的素性確立に関連している。
オンチェーンで格納されるまたは証跡を示される（attested）CRペア（CRP）の場合、ここで開示される諸実施形態は、ひとたび認証プロセスにおいて使用された後に、信頼されるサードパーティーがCRPを失効させることを許容する方式を提供する。例示的な方法が次に示される。
1. アリスと信頼されるサードパーティーは、（たとえば前述のような）素性セットアップ・プロトコルを実行する。
2. アリスと信頼されるサードパーティーは、今、1で生成された、またはステップ1の後に今、取得可能になっているCRPの管理のためにブロックチェーンを使用することを望む。
a. アリスは、CRPをトランザクション出力にマップするCRPマッピング・トランザクションTxIDCRP-Setを作成する。これは下記の表4に示される。
b. アリスと信頼されるサードパーティーの両方がTxIDCRP-Setに署名する。
3. CRPマッピング・トランザクションTxIDCRP-Setは、ブロックチェーン・ブロックにおいてブロードキャストおよび公開される。
Figure 2023543456000005
このプロセスで作成されるマッピング・トランザクションは上記の表4に示される。これは、前に表2に示したCRPマッピング・トランザクションに非常に似ているが、信頼されるサードパーティーとアリスの両方が入力に署名すること、およびCRPにマッピングされたUTXOのそれぞれが、将来のトランザクションにおいて使用することによって、信頼されるサードパーティーによって失効させられることができる点が異なる。
これは、CRPの失効が、直接通信なしに処理されることを許容し、TTPがユーザーの代わりに失効を実行でき、それはさらに、システムにおけるアリスの負担を軽減し、アリスの素性管理を一層軽量化することを許容するという利点がある。
6. 認証可能な計算
本開示は、分散コンピューティング・シナリオなどにおいて、計算を実行したと称する目標者の素性の検証を可能にするためのシステム、方法、および対応するソフトウェアを提供する。
図10は、目標者103T（後に「作業者」とも呼ばれる）によって、その当事者のコンピュータ設備102Tを使用することによって実行されうる、計算結果の認証を可能にする仕方で計算を実行する方法を示している。ここでの計算結果の認証とは、計算を実行したと称する目標者の素性〔アイデンティティ〕（identity）を検証することを意味する。
ステップ1010で、目標者103Tは、少なくとも、PUFモジュール603によって生成されたレスポンスから導出された公開‐秘密鍵ペアの秘密鍵を取得する。PUFモジュール603は、単にPUF 302を含んでいてもよく、あるいは先に論じたePUF 501のような、PUF 302を含む拡大されたPUFベースの関数を含んでいてもよい。いずれにせよ、レスポンスは、PUFモジュールに入力された対応するチャレンジに依存して、PUFモジュール603によってPUF 301を使用して生成される。公開鍵と秘密鍵のペアは、秘密鍵と対応する公開鍵を含み、秘密鍵でメッセージに署名することによって作成された署名を検証するために使用できる。
諸実施形態において、標的者は公開鍵と秘密鍵の両方を取得する。たとえば、鍵ペアが標的者のコンピュータ設備102Tで生成される、またはサードパーティー（たとえば先に述べたサードパーティー・システム602）によって生成され、標的者103Tに送信されるためである。
公開鍵は検証者103Vに対して利用可能にされる。これが実装されうる方法はいくつかある。たとえば、諸実施形態において、公開鍵は検証者103Vによってアクセス可能な公開鍵記憶媒体に記憶される。たとえば、問題のデータ記憶媒体は、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装されてもよい。これは、前述のサードパーティー設備602におけるデータ・ストア601であってもよく、あるいは、同じサードパーティーまたは異なるサードパーティーの別個のシステムであってもよい。別の例として、それを介して公開鍵が検証者103Vに対して利用可能にされるデータ記憶媒体は、ブロックチェーンなどのピアツーピアの公開媒体を含んでいてもよく、これは前述したのと同じブロックチェーン150であっても、あるいは異なるものであってもよい。公開鍵は、目標者103Tまたは目標者103Tの代理として行動する信頼されるサードパーティー（たとえばサードパーティー・システム602の運用者）によって公開鍵記憶媒体に記憶されてもよい。ブロックチェーンの場合、「記憶」はノード104によって記憶されるように送信することを意味しうる。
他の代替では、公開鍵は検証者103Vに直接送信されてもよく、たとえば、インターネットやモバイル・セルラー・ネットワークなどのネットワークを通じて検証者103Vに送信されてもよい。公開鍵は、目標者103Vによって検証者103Vに送信されてもよく、あるいはここでもまた、目標者の代理として行動するサードパーティー（たとえば、システム602の運用者）によって送信されてもよい。
公開鍵の取得は、目標者が計算要求を受信する前のセットアップ・フェーズにおいて実行され、公開鍵が検証者にとって利用可能にされてもよい。これは、PUFモジュール603によって生成されたレスポンスが鍵ペアを生成するために使用される場合、前述のセットアップ・フェーズ702であってもよい。
PUFモジュール603は、信頼されるサードパーティー（たとえば、先に論じたサードパーティー・システム602の運用者）の制御下にあってもよく（たとえば、所有されていてもよく）、信頼されるサードパーティーは、目標者103Tのための公開鍵と秘密鍵のペアを生成し、少なくとも公開鍵を目標者103Tに送信する（たとえば、インターネットやモバイル・セルラー・ネットワークなどのネットワークを通じて、またはドングルなどを物理的に送ることによって）。
これの変形として、公開鍵の前記取得は下記を含んでいてもよい：目標者103に代わって前記レスポンスを生成するためにPUFモジュール603にチャレンジを入力した信頼されるサードパーティーから、目標者103TがレスポンスRを受け取り；次いで、目標者103Tが、信頼されるサードパーティーから受け取ったレスポンスに基づいて、目標者の設備102Tにおいて公開‐秘密鍵を生成する。
問題のサードパーティーは、目標者103Tに対して秘密鍵を利用可能にする同じサードパーティーであっても、異なるサードパーティーであってもよい。
あるいは、別のオプションとして、PUFモジュール603は、レスポンスを生成するようチャレンジをPUFモジュール603に入力しうる発行者または検証者103Vの制御下にあってもよい（たとえば、所有されていてもよい）。発行者または検証者は、公開‐秘密鍵ペアを導出して公開鍵を目標者103Tに送信してもよく、あるいは目標者103Tが公開‐秘密鍵ペアを導出するよう、目標者103Tにレスポンスを送信してもよい。
さらなる代替的な諸実装では、PUFモジュール603は、自分自身で公開‐秘密鍵ペアを生成する目標者103Tの制御下にあってもよい（たとえば、所有されていてもよい）。この場合、公開鍵の前記取得は、目標者103Tが、レスポンスを生成してローカルで公開秘密鍵ペアを導出するために、自分自身でPUFモジュール603へのチャレンジの入力を実行することを含む。
そのようないくつかの実施形態では、目標者のコンピュータ設備102Tは、自己完結した目標デバイスの形をとってもよい。PUFモジュール603は、目標デバイス102Tと同じ筐体内に組み込まれていてもよく、あるいは、PUFモジュール603は、ネットワークではなくケーブルによって目標デバイス102Tに接続されている外部周辺機器に実装されてもよい。
ステップ1020では、目標者103Tは発行者（たとえば、計算毎の支払いシステムにおいて計算を委託する当事者）から計算要求を受信する。発行者は、検証者103Vであってもよく、または、検証者103Vがその代理として行動している異なる当事者であってもよい。発行者は、後にアウトソーシング者とも呼ばれることがある。
計算要求を受信するために、諸実施形態において、目標者103Tは電子広告媒体にアクセスして、広告された要求を積極的にポーリングする必要がある場合がある。広告媒体は、サードパーティーのサーバー設備、たとえば前述のサードパーティー設備602のデータ・ストア601において実装されることができ；あるいは、ブロックチェーン（たとえば前述のブロックチェーン150）のようなピアツーピアの公開媒体であることもできる。電子広告媒体は、公開鍵および／または秘密鍵を記憶して、検証者および目標者103V、103Tに対して利用可能にするために使用されるものと同じ記憶媒体であってもよく、あるいは異なる媒体であってもよい。
別の変形では、発行者は、目標者が広告媒体をポーリングする必要なく、計算要求を目標者103Tにプッシュしてもよい。たとえば、発行者は、目標者103Tを含む複数の潜在的な作業者に要求をブロードキャストしてもよく、あるいは目標者103Tに特定的に、目標を絞った要求を送信してもよい。
どのような手段によって計算要求が受信されても、諸実施形態において、目標者103Tは、目標者103Tが要求を受け入れ、要求された計算を実行することを確証するために、確認応答（acknowledgement）を発行者に返送してもよい。
ステップ1030では、計算要求において指定された計算を目標者103Tが（自分のコンピュータ設備102T上で）実行する。これは、たとえば地球外生命体の探索、または複雑な数学的問題に対する解の探索、または癌などの病状の治療の探索など、問題となっている用途によって必要とされる事実上任意の計算でありうる。この計算は、より広範な分散式コンピューティング・アプリケーションの一部であってもよく、目標コンピュータ設備102Tは、要求された計算が構成部分となる、より広範な計算に関与する複数の異なる当事者の複数のコンピュータ設備のうちの一つにすぎないことがありうる。
ステップ1040では、目標者103Tは、計算の結果を含むメッセージに署名する。メッセージは、前述の秘密鍵を用いて署名される。いくつかの実施形態では、署名されたメッセージは、追加的な情報、たとえば、計算が実行された（たとえば完了された）時刻を示すタイムスタンプをも含んでいてもよい。諸実施形態において、署名されたメッセージは、ブロックチェーン150に記録されるべきブロックチェーン・トランザクションの一部または全部を含んでいてもよい。
メッセージの署名は、メッセージと秘密鍵を暗号学的署名アルゴリズムに入力することを含み、該暗号署名アルゴリズムは、メッセージと秘密鍵に基づいて署名を生成する。これは時に、メッセージ「に対する」署名と呼ばれる。そのようなアルゴリズムのさまざまな例は、それ自体は当技術分野で既知である。その後、署名はメッセージにタグ付けされ、メッセージの署名付きバージョンを形成する。
諸実施形態において、目標者103Tは計算の結果を暗号化してもよい。これは、計算結果のみを暗号化すること、あるいはメッセージ全体を暗号化すること（メッセージが単に結果だけではない場合）を含みうる。暗号化は、署名の前または後に適用されうる。いずれの場合も、暗号化は暗号化鍵を使用して実行され、解読するには対応する解読鍵が必要である。さまざまな好適な暗号化アルゴリズムは、それ自体では当技術分野で既知である。解読鍵は、暗号化鍵と解読鍵が同じ鍵である対称暗号化鍵（たとえばAES）の鍵、または暗号化鍵と解読鍵が異なる非対称方式（たとえばRSA）の解読鍵でありうる。
そのような実施形態では、解読鍵は、検証者103Vおよび／または発行者にとって、目標者103Tまたはサードパーティー（たとえばサードパーティー・システム602の運用者）のいずれかから入手可能にされる。後者の場合、これは、開示される方法の何らかの他のサードパーティー動作を実行するものと同じまたは異なるサードパーティーでありうる。解読鍵は、解読鍵記憶媒体（たとえばサードパーティーのサーバー、またはブロックチェーンなどのピアツーピア媒体）を介して検証者103Vおよび／または発行者に利用可能にされてもよく、または検証者103Vに直接送信されてもよい。前者の場合、これは秘密鍵、公開鍵および／または広告に使用されるのと同じまたは異なる媒体でありうる。
諸実施形態において、検証者および／または発行者が、解読鍵へのアクセスをもつ唯一の当事者（単数または複数）である場合がある。あるいはまた、解読鍵をもつ当事者の制約されたグループのメンバー（単数または複数）である場合もある。
諸実施形態において、対称暗号化／解読鍵または非対称鍵ペアは、PUFモジュール603に別のチャレンジ（署名に使用される鍵を生成するために使用されるのとは異なるチャレンジ）を入力することによって導出されてもよい。これは、目標者103T、検証者103V、発行者または信頼されるサードパーティーによって実行されうる。
ステップ1050では、署名されたメッセージが出力され、検証者103Vに対して（また、諸実施形態では同じまたは異なる当事者でありうる発行者に対しても利用可能にされる。これを行うための可能な機構は多数ある。諸実施形態において、目標者103Tは、単に署名されたメッセージを検証者103Vに（および任意的には、もし異なる当事者であれば発行者にも）直接、たとえばインターネットまたはモバイル・セルラー・ネットワークなどのネットワークを通じて送信してもよい。あるいはまた、目標者103Vは、署名されたメッセージを、検証者103Vにとって（および任意的には、もし異なる当事者であれば発行者にとっても）アクセス可能なデータ記憶媒体に記憶してもよい（または記憶させてもよい）。このデータ記憶媒体は、サードパーティーのサーバー設備（一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含む）、たとえば、前述のサードパーティー・システム602のデータ・ストア601において実装されることができる。あるいは、署名されたメッセージを伝えるために使用されるデータ記憶媒体は、ブロックチェーン、たとえば前述のブロックチェーン150のような公開のピアツーピア媒体でもよい。いずれにしても、これは広告、公開鍵および／または暗号化鍵のいずれかを伝えるために使用されるものと同じ記憶媒体であってもよいし、あるいは異なる媒体であってもよい。ブロックチェーンの場合、「記憶」とは、ブロックチェーン・ネットワーク106のノード104に直接送信するか、またはノードに転送する一つまたは複数の中間当事者を介して送信することによって、ブロックチェーンに格納されるように送信することを意味しうる。
また、検証者103Vと発行者（計算要求を発行した当事者）が異なる当事者である場合、署名されたメッセージまたは計算結果を発行者に通信する手段は、必ずしも、署名されたメッセージを検証者に通信するために使用される手段と同じである必要はないことにも注意されたい。あるいは、検証者103Vは署名されたメッセージまたは計算結果を発行者に転送してもよく、あるいはその逆を行ってもよい。さらに別の変形では、目標者103Tは、署名されたメッセージまたは計算結果を、計算結果の消費者であるさらに別の消費当事者に送信することができる。
どのような方法であれ、検証者103Vは署名されたメッセージと公開鍵を取得し、その後、検証者103Vは公開鍵を使用して、署名されたメッセージを認証する（すなわち、メッセージが問題の公開鍵に対応する秘密鍵で署名されたことをテストすることによって、署名者の素性を検証する）ことができる。これを行うためのさまざまな好適な署名認証アルゴリズムは、それ自体は当技術分野で既知である。諸実施形態において、検証者は、前記認証を条件として（すなわち、メッセージが目標者103Tによって署名されたことを検証することを条件として）、目標者への支払いをリリースさせてもよい。別の代替的または追加的な例として、検証者103は、前記認証を条件として、計算結果を発行者または消費者に転送するだけでもよく、あるいは検証されたレスポンスの集合に含めるだけでもよい。
ある具体的な実施形態では、目標者103Tは、署名されたメッセージを、テンプレート・ブロックチェーン・トランザクションに含め、テンプレート・トランザクションを検証者103Vに送信することによって検証者103Vに通信する。署名されたメッセージは、テンプレート・トランザクションの一部または全部を含むことができる。たとえば、計算結果が目標トランザクションのペイロードに含められてもよく、次いで目標者103Tがテンプレート・トランザクションに署名するか、あるいは、メッセージは、署名されてテンプレート・トランザクションのペイロードに含められる、より小さなもの（たとえば、計算結果だけ、または該結果とタイムスタンプ）であってもよい。いずれにせよ、検証者103Vは、これを受信すると、署名を検証し、それを条件としてテンプレート・トランザクションを完了して、それを、ブロックチェーン150に記録されるよう、転送する。トランザクションを完了することは、少なくとも検証者103Vの署名を加えることを含みうる。検証者103Vは、完全なトランザクションをブロックチェーン・ネットワークのノード104に直接送信してもよく、あるいはブロックチェーン・ネットワーク106に転送する一つまたは複数の中間当事者を介して送信してもよい。
注：上記は非対称の公開‐秘密鍵ペアを用いて記載されているが、これは限定するものではない。より一般的には、ここでの公開鍵および秘密鍵への言及は、任意の非対称または対称認証方式の暗号鍵に一般化されうる。署名する場合、「公開鍵」は、非対称な公開‐秘密鍵ペアの公開鍵または対称認証方式の鍵を含むことができる。署名を検証する場合、「秘密鍵」は、それぞれ非対称な公開‐秘密鍵ペアの対応する秘密鍵または対称方式の同じ鍵を含むことができる。
署名するために使用される「鍵ペア」は、非対称および対称の署名方式を許容するよう「暗号鍵（cryptographic key）」に広げられるべきである。
諸実施形態において、記述された技法はアウトソーシング〔外部委託〕される計算のために使用できる。たとえば、大量の計算資源を必要とする計算タスクが委任され、多くの作業者エンティティの間で分散されるエッジ・コンピューティングの概念は、それ自体は分散ネットワークやシステムの文脈でよく知られている。これは、文献ではしばしば「グリッド・コンピューティング」または「フォグ・コンピューティング」とも呼ばれる。
また、この種のアウトソーシングされる計算が、作業者がタスクに計算資源を寄与することを補償するために、計算毎の支払いベースで作業者エンティティの間で分配されることが一般的である。アウトソーシングされる計算に、アウトソース元からの支払いを導入することには、2つの課題がある。
１．悪意のある作業者が、利益を得るために誤った計算を提出しようとする可能性がある；
２．悪意のあるアウトソースが、正しい計算について誠実な作業者への支払いを怠る可能性がある。
これらの問題に取り組むためにさまざまな方式が提案されているが、多くは特定のタイプの計算タスクに限定されている。さらに、支払いを提供するためのブロックチェーン・ベースの支払いシステムの使用が以前の研究で提案されている。
ここに開示されている実施形態では、そのようなアウトソーシングされた計算を仲介するための基盤として、ブロックチェーン150を使用する技術が提供され、そこでは、デバイス素性を実行されている計算に結びつける手段としてPUFデバイスの使用が導入されている。ここでの意図は、悪意のある作業者やアウトソースが不誠実に行動することを思いとどまらせるよう、これらの動作に証拠付けと素性リンクを追加することである。
6.1 例示的なプロトコル
先に論じたように、エッジ・コンピューティング・アプリケーションの一部として実行される計算の完了のために、PUFデバイスが使用されてもよい。ここでの発想は、割り当てられた計算結果を算出することを受け持つデバイスは、PUFレスポンスから導出される暗号鍵を使用して計算結果に署名することも求められるということである。
これは、作業者（この場合はPUF対応デバイス）によって実行された計算の結果が、作業者デバイス自体の素性に暗号的にリンクされることを保証する。これにより、アウトソース元と作業者の間で紛争が発生した場合には、計算結果に対する署名が証拠として使用されうるので、エッジ・コンピューティングが、より高いレベルの監査性および透明性をもって実装されうる。
計算結果がデバイスによって署名されるという事実は、作業者が支払いのために誤った結果を提供するインセンティブを失わせる。これらの誤った結果が今や、計算中に使用されるデバイスにリンクされることができる鍵によって署名されるからである。
さらに、これがアウトソース元に与える法的保証のため、アウトソース元は、計算自体の正確さを検証したり、最初の作業者によって与えられた解を複数の異なる作業者が裏付けるのを待ったりする必要なく、より迅速に計算についての関連する支払いを提供できる可能性がある。これは、部分的には、アウトソース元が、たとえ結果自体を検証できなくても、結果に対する署名を検証することはできるという事実のためである。
エッジ・コンピューティング・シナリオにおいてPUFデバイスを使用する例示的なプロセスは次のように与えられる：
1. アウトソース元がジョブπを広告する。
2. 作業者はジョブを受け入れ*、PUF対応デバイス上で解／結果σを計算する：
i. 結果σがデバイスによって計算される。
ii. 署名鍵Pworkが、PUFデバイスのレスポンスに基づいて生成される。
2. 署名Sig(Pwork,σ)が、前記結果に対して生成される。
3. 作業者が、以下を含むビットコイン・トランザクションを構築する：
i. 前記結果の表現（たとえば平文σまたはPUFレスポンスを使用して暗号化される）**。
ii. 前記結果に対する署名Sig(Pwork,σ)。
iii. 作業者に支払う支払い出力。
4. 作業者は、部分的に署名されたトランザクションをアウトソース元に送信する。
5. アウトソース元はトランザクションに署名して完了させ、その計算についての支払いとしてビットコイン・ネットワークにブロードキャストする。これは次の場合にのみ行われる：
i. アウトソース元が署名Sig(Pwork,σ)を検証できる。
ii. そうでない場合、アウトソース元は署名せず、トランザクションは不完全なままになる。負担された資金は、タイムアウト期間後にアウトソース元に返される。
*「ジョブを受け入れ」ることは、アウトソース元と作業者の間の通信を含んでいてもよく、また、アウトソース元と検証者の両方を必要とするタイムロックされた出力を作成することを含んでいてもよい。
**すなわち。Enc(σ,R)である。Rは、s＝H(R)を導出するために使用されるものと同じである必要はない。
上記のプロトコルでは、作業者がアウトソース元に有効な署名を提供していれば、アウトソース元は該署名をすぐに有効確認することができ、作業者は、計算の完了時に、計算について支払いを受けることができる。
プロセスの初期の部分、特にステップ2では、作業者とアウトソース元が資金にマルチシグ（または同様の）出力を負わせる（encumber）必要があることがあり、その場合は、資金をロック解除するために両者が署名に参加する必要がある。これは、次の表Aに示されるように、ジョブ受け入れ（job acceptance）トランザクションTxIDJAを作成することによって行うことができる。このトランザクションは、アウトソース元の資金を、使用するにはアウトソース元と作業者の両方の署名を必要とする出力にロックする。そのようなシナリオでの標準的な手順と同様に、好適なロックタイムに従って、資金をアウトソース元に送り返す返金（refund）トランザクションTxIDRefundも作成するべきである。
Figure 2023543456000006
 表A. エッジ・コンピューティング・ジョブを開始するために使用されうるジョブ受け入れトランザクションの例。
ジョブπが初期化された後、作業者は解σを見つけるためにジョブに自由に取り組むことができ、ここでは計算はPUF対応デバイスによって実行されると仮定する。デバイスは、ひとたび解を計算したら、その結果に対する署名Sig(Pwork,σ)を生成する必要がある。
署名されたメッセージは結果σを含む必要があるが、タイムスタンプやナンスなどの他のデータをも追加で含んでいてもよいことに注意されたい。あるいはまた、署名されたメッセージは、結果σを含むブロックチェーン・トランザクションの一部であってもよい。
メッセージに署名するために使用される鍵は、PUFデバイスから導出される必要がある。たとえば、署名がECDSA署名である場合、鍵swork＝H(R)はチャレンジCに対するPUFの何らかのレスポンスRから導出されてもよく、署名はPwork＝swork・Gとして定義されたEC公開鍵に対して検証されてもよい。
次いで、作業者は、計算結果σの表現、結果に対する署名Sig(Pwork,σ)、および提供された計算作業について作業者に報酬を与える出力を含む部分的に完成したトランザクションを生成する。これらの部分的に完成したトランザクションは、次いで、アウトソース元に返送される必要がある。完成させて（すなわち、トランザクションに対する自分自身の署名を提供することによって）、TxIDSigned-Compを作成するためである。次いで、TxIDSigned-Compは、ブロックチェーン・ネットワーク106にブロードキャストされることができる。
完成されたトランザクションTxIDSigned-Compは、ステップ2の間にアウトソース元と作業者の公開鍵に以前に負わされていた（encumbered）アウトソース元の資金を使用する。したがって、このトランザクションは少なくとも2つの入力署名（または少なくとも2つの公開鍵に依存する署名）を含み、1つはアウトソース元によって制御され、1つは作業者によって制御される。
結果の表現と結果に対する署名は、OP_FALSE OP_RETURN出力内など、作業者に支払う出力とは別個の出力内に含められてもよい。代替的な実装では、署名Sig(Pwork,σ)と表現は、支払いと同じ出力に含められてもよい。さらに、署名Sig(Pwork,σ)は入力署名として含められてもよく、ここで、トランザクション出力における結果の表現は、この入力署名によって署名されたメッセージの一部である。
表Bおよび表Cにはそれぞれ、TxIDSigned-Compの2つの可能な変形が示されている。第1の場合では、結果に対する署名が入力として含まれ、作業者への支払い出力は、前記結果の暗号化されたバージョンに対して別個である。ここで使用される暗号化鍵は、PUFレスポンスRから導出されてもよく、これは、Pworkの前の生成において使用された同じレスポンスである必要はない。
Figure 2023543456000007
 表B. もとの計算を受け持つPUFによって署名された計算結果を含むトランザクションの例。ここで、署名は諸ブロックチェーン・ノードによって検証されるECDSA署名である。Pworkは、トランザクションの入力にあるものとは異なる公開鍵（やはりアウトソース元が所有する）であってもよいことに注意されたい。すなわち、向上したプライバシーのために、2つの鍵PworkおよびP'workがあることになる。
可能なTxIDSigned-Compの第2の例では、結果に対する明示的な署名が出力に含まれるが、出力は作業者に支払うために使用されるものと同じである。
Figure 2023543456000008
 表C. もとの計算を受け持つPUFによって署名された計算結果を含むトランザクションの代替的な例。ここでは、署名は追加的なスクリプト・データとして含まれている。
6.2 例示的なシナリオ
この機構を利用しうるある例示的なシナリオは、複数のIoTデバイスを有するホーム・セキュリティ・システムであり、1つのデバイスはスマート・ロックであり、他のデバイスは複数のビデオ・カメラである。
セキュリティ・システムは、ビデオ・カメラによって記録および分析されたビデオに基づいてドアをロックするか、またはロック解除するかについて、スマート・ロックが決定をすることができることに依拠する。これは典型的には、スマート・ロックへのサービスとしてこの計算を提供するよう諸カメラが統合されることができるよう、ロックとビデオ・カメラが同じエンティティによって製造される必要があることを意味する。
ただし、このシナリオでは、メーカーAからのスマート・ロックを、みな別のメーカーBによって作られる諸ビデオ・カメラの関連で使用されることを許容することによって、柔軟性を改善することが望まれることがありうる。これを達成するために、メーカーBのビデオ・カメラは、ビデオを捕捉して処理するように構成されている。ここで、ビデオの処理は、突然の動きがあるかどうかをチェックすること、または顔認識を実行することを、計算毎の支払いベースでのメーカーAのスマート・ロックのためのサービスとして、含んでいてもよい。
誰かが家へのアクセスしようとするとき、スマート・ロックは、ドアの前の人に関する顔認識を実行するようビデオ・カメラのネットワークにジョブを提出する。顔認識タスクが最初の完了に際して、最初に完了した成功したビデオ・カメラは、結果を、署名されたビットコイン・トランザクションの一部としてスマート・ロックに提出する。応答して、スマート・ロックは署名を検証し、その真実性に基づいてドアをロック解除するかどうかを決定する。
ビデオ・カメラのネットワークに関与させることにより、これは、複数のビデオカメラメーカーB、C、Dなどがそれぞれ前記カメラのうちの1つを提供し、顔認識を実行する最初となるべく競争することを許容する。ここで、最初に成功した完了のみが検証される。
7. 結論
開示された技術の他の変形または使用事例は、本願での開示が与えられると、当業者に明白になりうる。開示の範囲は、記載された実施形態によって限定されず、付随する請求項によってのみ限定される。
たとえば、上記のいくつかの実施形態は、ビットコイン・ネットワーク106、ビットコイン・ブロックチェーン150、ビットコイン・ノード104の観点で記述されている。しかしながら、ビットコイン・ブロックチェーンはブロックチェーン150の一つの具体例であり、上記の説明は一般的にどのブロックチェーンにも適用されうることが理解されるだろう。つまり、本発明はビットコイン・ブロックチェーンに限定されるものではない。より一般的には、上記のビットコイン・ネットワーク106、ビットコイン・ブロックチェーン150、ビットコイン・ノード104への言及は、それぞれブロックチェーン・ネットワーク106、ブロックチェーン150、ブロックチェーン・ノード104への言及で置き換えられてもよい。ブロックチェーン、ブロックチェーン・ネットワーク、および／またはブロックチェーン・ノードは、上記のように、ビットコイン・ブロックチェーン150、ビットコイン・ネットワーク106、およびビットコイン・ノード104の記述された特性の一部またはすべてを共有しうる。
本発明の好ましい実施形態では、ブロックチェーン・ネットワーク106はビットコイン・ネットワークであり、ビットコイン・ノード104は、少なくとも、ブロックチェーン150のブロック151を作成、公開、伝播、および格納する、記述された機能のすべてを実行する。これらの機能の一つまたは一部のみを実行し、全部は実行しない他のネットワーク・エンティティ（またはネットワーク要素）が存在する可能性は排除されない。つまり、ネットワーク・エンティティは、ブロックを作成および公開せずにブロックを伝播および／または格納する機能を実行する場合がある（これらのエンティティは、好ましいビットコイン・ネットワーク106のノードとは見なされないことを想起されたい）。
本発明の他の実施形態では、ブロックチェーン・ネットワーク106はビットコイン・ネットワークではなくてもよい。これらの実施形態では、ノードがブロックチェーン150のブロック151を作成、公開、伝播、および格納する機能の少なくとも一つまたはいくつかを実行しうるが全部は実行しないことは除外されない。たとえば、それらの他のブロックチェーン・ネットワークでは、「ノード」は、ブロック151を作成および公開するように構成されているが、それらのブロック151を格納するおよび／または他のノードに伝播させることはしないネットワーク・エンティティを指すために使用されてもよい。
より一般的には、上記の「ビットコイン・ノード」104という用語への言及は、「ネットワーク・エンティティ」または「ネットワーク要素」という用語に置き換えられてもよい。そのようなエンティティ／要素は、ブロックを作成、公開、伝播、および格納する役割の一部または全部を実行するように構成される。そのようなネットワーク・エンティティ／要素の機能は、ブロックチェーン・ノード104に関して前述したのと同じ仕方でハードウェアで実装されてもよい。
上記の実施形態は、単に例として説明されていることが理解されよう。より一般的には、以下の陳述のいずれか一つまたは複数による方法、装置、またはプログラムが提供されうる。
〔陳述１〕
計算を実行するコンピュータ実装される方法であって、当該方法は、前記計算を実行するコンピュータ設備である目標者の目標コンピュータ設備によって：物理的複製不能関数PUFを含むPUFモジュールによって生成されたレスポンスから導出される暗号鍵を得る段階であって、前記レスポンスは、前記PUFモジュールに入力された対応するチャレンジに応答して前記PUFに基づいて前記PUFモジュールによって生成されたものであり、前記暗号鍵または対応する公開鍵を含む鍵情報は検証者に対しても利用可能にされる、段階と；発行者から、実行されるべき前記計算を指定する計算要求を受信する段階と；前記計算要求に応答して、計算結果を生成するために前記計算を実行する段階と；前記計算結果を含むメッセージに、前記暗号鍵を用いて署名する段階と；署名されたメッセージをブロックチェーン上に記録されるように送信することによって、前記署名されたメッセージを前記検証者に対して利用可能にする段階とを実行することを含む、方法。
〔陳述２〕
前記発行者が前記検証者である、陳述１に記載の方法。
〔陳述３〕
前記署名されたメッセージを送信することは：前記目標者が前記署名されたメッセージを含むテンプレート・ブロックチェーン・トランザクションを定式化し；前記目標者が前記テンプレート・ブロックチェーン・トランザクションを前記検証者に送信し、それにより前記検証者に前記メッセージの前記署名を検証させ、それに依存して少なくとも前記検証者の署名で署名することによって前記テンプレート・トランザクションを完成させ、完成されたトランザクションを前記ブロックチェーンに記録されるよう転送させることを含む、陳述１または２に記載の方法。
〔陳述４〕
前記メッセージは前記テンプレート・トランザクションの少なくとも一部を含む、陳述３に記載の方法。
〔陳述５〕
前記完成されたトランザクションは、ひとたび前記ブロックチェーンに記録されたら前記計算について前記目標者に支払いをする、陳述３または４に記載の方法。
〔陳述６〕
前記完成されたトランザクションは、前記ブロックチェーン上の資金調達トランザクションの出力をポイントする入力と、前記資金調達トランザクションの前記出力から前記目標者に、前記発行者の少なくとも一部の資金を割り当てる出力とを含むことによって、前記目標者に支払いをするものであり、ここで、前記資金調達トランザクションの前記出力は、指定されたタイムアウト期間後に前記目標者に割り当てられなかった場合に、前記資金が前記発行者に移転し戻されることを可能にするタイムアウト条件を含む、陳述５に記載の方法。
〔陳述７〕
前記暗号鍵を得ることが実行され、前記目標者が前記計算要求を受信する前のセットアップ・フェーズにおいて、前記鍵情報が前記検証者に対して利用可能にされる、陳述１ないし６のうちいずれか一項に記載の方法。
〔陳述８〕
前記得ることは：前記発行者、検証者または信頼されるサードパーティーから前記レスポンスを受信することを含み、前記チャレンジは、前記目標者に代わって、前記発行者、検証者または信頼されるサードパーティーによって、前記レスポンスを生成するために前記PUFモジュールに入力されたものであり、前記公開‐秘密鍵ペアの生成は、受信された前記レスポンスに基づく、陳述１ないし７のうちいずれか一項に記載の方法。
〔陳述９〕
前記得ることは：前記発行者、検証者または信頼されるサードパーティーから前記公開鍵を受信することを含み、前記チャレンジは、前記目標者に代わって、前記レスポンスを生成し、前記暗号鍵ペアを導出するために前記発行者、検証者または信頼されるサードパーティーによって前記PUFに入力されたものである、陳述１ないし７のうちいずれか一項に記載の方法。
〔陳述１０〕
前記サードパーティーが前記鍵情報を前記検証者に対して利用可能にする、陳述８または９に記載の方法。
〔陳述１１〕
前記得ることが：前記目標者が、前記チャレンジの前記PUFモジュールへの入力を実行して前記レスポンスを生成し、前記目標者によって前記暗号鍵を導出することを含む、陳述１ないし７のうちいずれか一項に記載の方法。
〔陳述１２〕
前記目標コンピュータ設備が自己完結した目標デバイスの形をとり；前記PUFモジュールが前記目標デバイスと同じ筐体内に組み込まれているか、または前記PUFモジュールが前記目標デバイスにネットワークではなくケーブルによって接続されている外部周辺機器において実装されている、陳述１１に記載の方法。
〔陳述１３〕
当該方法が、前記目標者が前記鍵情報を前記検証者に対して利用可能にすることを含む、陳述１１または１２または陳述１ないし９のうちいずれか一項に記載の方法。
〔陳述１４〕
前記鍵情報を前記検証者に対して利用可能にすることが：前記鍵情報を前記検証者に送信することを含む、陳述１ないし１３のうちいずれか一項に記載の方法。
〔陳述１５〕
前記鍵情報を前記検証者に対して利用可能にすることが：前記鍵情報を、前記検証者にとってアクセス可能な鍵情報記憶媒体に、前記目標者または目標コンピュータ設備の素性にリンクされて記憶することを含む、陳述１ないし１３のうちいずれか一項に記載の方法。
〔陳述１６〕
前記鍵情報記憶媒体が、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装されている、陳述１５に記載の方法。
〔陳述１７〕
前記鍵情報記憶媒体がブロックチェーンまたは他のピアツーピア公開媒体である、陳述１６に記載の方法。
〔陳述１８〕
前記暗号鍵が、前記秘密鍵と対応する公開鍵を含む非対称公開‐秘密鍵ペアの秘密鍵を含み、前記鍵の公開‐秘密鍵ペアが前記レスポンスから導出され、前記検証者に対して利用可能にされる前記鍵情報が前記公開鍵を含む、陳述１ないし１７のうちいずれか一項に記載の方法。
〔陳述１９〕
前記暗号鍵が対称認証方式の鍵を含み、前記検証者に対して利用可能にされる前記鍵情報も該暗号鍵を含む、陳述１ないし１７のうちいずれか一項に記載の方法。
〔陳述２０〕
解読するために解読鍵を必要とするように前記計算結果を暗号化することを含み、前記計算結果は暗号化された形でのみ前記検証者に対して利用可能にされ、前記解読鍵は前記検証者および／または発行者に対して利用可能にされる、陳述１ないし１９のうちいずれか一項に記載の方法。
〔陳述２１〕
前記暗号化は、前記秘密鍵で署名する前に前記計算結果を暗号化することを含む、陳述２０に記載の方法。
〔陳述２２〕
前記暗号化は、前記秘密鍵で署名した後に前記メッセージを暗号化することを含む、陳述２０に記載の方法。
〔陳述２３〕
前記解読鍵は、前記PUFモジュールまたは別のPUFモジュールによって、該PUFモジュールに前記目標者、検証者、発行者、または信頼されるサードパーティーによって入力された別のチャレンジに応答して生成される別のレスポンスから導出される、陳述２０ないし２２のうちいずれか一項に記載の方法。
〔陳述２４〕
当該方法は、前記目標者が前記別のレスポンスを入力して前記別のチャレンジを生成し、前記解読鍵を導出することを含む、陳述２３に記載の方法。
〔陳述２５〕
前記目標者が前記解読鍵を前記検証者および／または発行者に対して利用可能にすることを含む、陳述２０ないし２４のうちいずれか一項に記載の方法。
〔陳述２６〕
前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を前記検証者および／または発行者に送信することを含む、陳述２０ないし２５のうちいずれか一項に記載の方法。
〔陳述２７〕
前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を、前記検証者および／または発行者にとってアクセス可能な解読鍵記憶媒体に記憶することを含む、陳述２０ないし２５のうちいずれか一項に記載の方法。
〔陳述２８〕
前記解読鍵記憶媒体は、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装される、陳述２７に記載の方法。
〔陳述２９〕
前記解読鍵記憶媒体はブロックチェーンまたは他のピアツーピア公開媒体である、陳述２７に記載の方法。
〔陳述３０〕
前記計算要求の受信が、電子広告媒体にアクセスして前記計算要求を取得することを含む、陳述１ないし２９のうちいずれか一項に記載の方法。
〔陳述３１〕
前記電子広告媒体がサードパーティーのサーバー設備または前記検証者のコンピュータ設備において実装されている、陳述３０に記載の方法。
〔陳述３２〕
前記電子広告媒体はブロックチェーンまたは他のピアツーピア公開媒体である、陳述３０に記載の方法。
〔陳述３３〕
前記計算を受け入れる受け入れ信号を、前記目標者から前記検証者に送信することを含む、陳述１ないし３２のうちいずれか一項に記載の方法。
〔陳述３４〕
前記目標コンピュータ設備が、分散コンピューティングを実行する分散コンピューティングシステムに関わる複数のコンピュータ設備のうちの1つであり、前記計算は前記分散コンピューティングの一部である、陳述１ないし３３のうちいずれか一項に記載の方法。
〔陳述３５〕
前記分散コンピューティングは計算毎の支払いベースで実行され、前記検証者が前記鍵情報に基づいて前記目標者の署名を検証することを条件に、前記目標者は前記計算の実行について支払いを受け取る、陳述３４に記載の方法。
〔陳述３６〕
メッセージが前記目標コンピュータ設備において前記計算を実行した時間を示すタイムスタンプをさらに含む、陳述１ないし３５のうちいずれか一項に記載の方法。
〔陳述３７〕
前記PUFモジュールは、PUFと決定論的な変換関数を有しており：前記PUFにベース入力を入力して対応するベース出力を生成し；前記レスポンスを生成するために、生成されたベース出力との関連で前記チャレンジを前記変換関数に入力する
ことによって、前記レスポンスを生成するように構成されており、前記変換関数は前記チャレンジおよび前記生成されたベース出力の関数である、陳述１ないし３６のうちいずれか一項に記載の方法。
〔陳述３８〕
一つまたは複数のメモリ・ユニットを含むメモリと；一つまたは複数の処理ユニットを含む処理装置とを有するコンピュータ設備であって、前記メモリは前記処理装置で実行されるように構成されたコードを記憶し、前記コードは前記処理装置上のときに陳述１ないし３７のうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ設備。
〔陳述３９〕
非一時的なコンピュータ可読媒体に具現されたコンピュータ・プログラムであって、一つまたは複数のプロセッサで実行されたとき、陳述１ないし３７のうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ・プログラム。
〔陳述１A〕
計算を実行するコンピュータ実装される方法であって、当該方法は、前記計算を実行するコンピュータ設備である目標者の目標コンピュータ設備によって：物理的複製不能関数PUFを含むPUFモジュールによって生成されたレスポンスから導出される公開‐秘密鍵ペアの少なくとも秘密鍵を得る段階であって、前記レスポンスは、前記PUFモジュールに入力された対応するチャレンジに応答して前記PUFに基づいて前記PUFモジュールによって生成されたものであり、前記公開‐秘密鍵ペアは前記秘密鍵および対応する公開鍵を含み、前記公開鍵は検証者に対して利用可能にされる、段階と；発行者から、実行されるべき前記計算を指定する計算要求を受信する段階と；前記計算要求に応答して、計算結果を生成するために前記計算を実行する段階と；前記計算結果を含むメッセージに、前記秘密鍵を用いて署名する段階と；署名されたメッセージを前記検証者に対して利用可能にする段階とを実行することを含む、方法。
〔陳述２A〕
前記発行者が前記検証者である、陳述１Aに記載の方法。
〔陳述３A〕
前記署名されたメッセージを利用可能にすることは：前記署名されたメッセージを、前記検証者によってアクセス可能なデータ記憶媒体に記憶することを含む、陳述１Aまたは２Aに記載の方法。
〔陳述４A〕
前記データ記憶媒体は、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装される、陳述３Aに記載の方法。
〔陳述５A〕
前記データ記憶媒体はピアツーピア公開媒体である、陳述３Aに記載の方法。
〔陳述６A〕
前記ピアツーピア公開媒体はブロックチェーンである、陳述５Aに記載の方法。
〔陳述７A〕
前記署名されたメッセージを前記検証者に対して利用可能にすることは：前記目標者が前記署名されたメッセージを含むテンプレート・ブロックチェーン・トランザクションを定式化し；前記目標者が前記テンプレート・トランザクションを前記検証者に送信し、それにより前記検証者に前記メッセージの前記署名を検証させ、それに依存して少なくとも前記検証者の署名で署名することによって前記テンプレート・トランザクションを完成させ、完成されたトランザクションをブロックチェーンに記録されるよう転送させることを含む、陳述１Aないし６Aのうちいずれか一項に記載の方法。
〔陳述８A〕
前記メッセージは前記テンプレート・トランザクションの少なくとも一部を含む、陳述７Aに記載の方法。
〔陳述９A〕
前記完成されたトランザクションは、ひとたび前記ブロックチェーンに記録されたら前記計算について前記目標者に支払いをする、陳述７Aに記載の方法。
〔陳述１０A〕
前記完成されたトランザクションは、前記ブロックチェーン上の資金調達トランザクションの出力をポイントする入力と、前記資金調達トランザクションの前記出力から前記目標者に、前記発行者の少なくとも一部の資金を割り当てる出力とを含むことによって、前記目標者に支払いをするものであり、ここで、前記資金調達トランザクションの前記出力は、指定されたタイムアウト期間後に前記目標者に割り当てられなかった場合に、前記資金が前記発行者に移転し戻されることを可能にするタイムアウト条件を含む、陳述９Aに記載の方法。
〔陳述１１A〕
前記公開鍵を得ることが実行され、前記目標者が前記計算要求を受信する前のセットアップ・フェーズにおいて、前記公開鍵が前記検証者に対して利用可能にされる、陳述１Aないし１０Aのうちいずれか一項に記載の方法。
〔陳述１２A〕
前記得ることは：前記発行者、検証者または信頼されるサードパーティーから前記レスポンスを受信することを含み、前記チャレンジは、前記目標者に代わって、前記発行者、検証者または信頼されるサードパーティーによって、前記レスポンスを生成するために前記PUFモジュールに入力されたものであり、前記公開‐秘密鍵ペアの生成は、受信された前記レスポンスに基づく、陳述１Aないし１１Aのうちいずれか一項に記載の方法。
〔陳述１３A〕
前記得ることは：前記発行者、検証者または信頼されるサードパーティーから前記公開鍵を受信することを含み、前記チャレンジは、前記目標者に代わって、前記レスポンスを生成し、前記公開‐秘密鍵ペアを導出するために前記発行者、検証者または信頼されるサードパーティーによって前記PUFに入力されたものである、陳述１ないし１１のうちいずれか一項に記載の方法。
〔陳述１４A〕
前記サードパーティーが前記公開鍵を前記検証者に対して利用可能にする、陳述１２Aまたは１３Aに記載の方法。
〔陳述１５A〕
前記得ることが：前記目標者が、前記チャレンジの前記PUFモジュールへの入力を実行して前記レスポンスを生成し、前記目標者によって前記公開秘密鍵ペアを導出することを含む、陳述１Aないし１２Aのうちいずれか一項に記載の方法。
〔陳述１６A〕
前記目標コンピュータ設備が自己完結した目標デバイスの形をとり；前記PUFモジュールが前記目標デバイスと同じ筐体内に組み込まれているか、または前記PUFモジュールが前記目標デバイスにネットワークではなくケーブルによって接続されている外部周辺機器において実装されている、陳述１５Aに記載の方法。
〔陳述１７A〕
当該方法が、前記目標者が前記公開鍵を前記検証者に対して利用可能にすることを含む、陳述１５Aまたは１６Aまたは陳述１２Aに記載の方法。
〔陳述１８A〕
前記公開鍵を前記検証者に対して利用可能にすることが：前記公開鍵を前記検証者に送信することを含む、陳述１Aないし１７Aのうちいずれか一項に記載の方法。
〔陳述１９A〕
前記公開鍵を前記検証者に対して利用可能にすることが：前記公開鍵を、前記検証者にとってアクセス可能な公開鍵記憶媒体に、前記目標者または目標コンピュータ設備の素性にリンクされて記憶することを含む、陳述１Aないし１７Aのうちいずれか一項に記載の方法。
〔陳述２０A〕
前記公開鍵記憶媒体が、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装されている、陳述１９Aに記載の方法。
〔陳述２１A〕
前記公開鍵記憶媒体がブロックチェーンまたは他のピアツーピア公開媒体である、陳述２０Aに記載の方法。
〔陳述２２A〕
解読するために解読鍵を必要とするように前記計算結果を暗号化することを含み、前記計算結果は暗号化された形でのみ前記検証者に対して利用可能にされ、前記解読鍵は前記検証者および／または発行者に対して利用可能にされる、陳述１Aないし２１Aのうちいずれか一項に記載の方法。
〔陳述２３A〕
前記暗号化は、前記秘密鍵で署名する前に前記計算結果を暗号化することを含む、陳述２２Aに記載の方法。
〔陳述２４A〕
前記暗号化は、前記秘密鍵で署名した後に前記メッセージを暗号化することを含む、陳述２２Aに記載の方法。
〔陳述２５A〕
前記解読鍵は、前記PUFモジュールまたは別のPUFモジュールによって、該PUFモジュールに前記目標者、検証者、発行者、または信頼されるサードパーティーによって入力された別のチャレンジに応答して生成される別のレスポンスから導出される、陳述２２Aないし２４Aのうちいずれか一項に記載の方法。
〔陳述２６A〕
当該方法は、前記目標者が前記別のレスポンスを入力して前記別のチャレンジを生成し、前記暗号化‐解読鍵ペアを導出することを含む、陳述２２Aないし２６Aのうちいずれか一項に記載の方法。
〔陳述２７A〕
前記目標者が前記解読鍵を前記検証者および／または発行者に対して利用可能にすることを含む、陳述２２Aないし２６Aのうちいずれか一項に記載の方法。
〔陳述２８A〕
前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を前記検証者および／または発行者に送信することを含む、陳述２２Aないし２７Aのうちいずれか一項に記載の方法。
〔陳述２９A〕
前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を、前記検証者および／または発行者にとってアクセス可能な解読鍵記憶媒体に記憶することを含む、陳述２２Aないし２６Aのうちいずれか一項に記載の方法。
〔陳述３０A〕
前記解読鍵記憶媒体が、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装されている、陳述２９Aに記載の方法。
〔陳述３１A〕
前記解読鍵記憶媒体がブロックチェーンまたは他のピアツーピア公開媒体である、陳述２９Aに記載の方法。
〔陳述３２A〕
前記計算要求の受信が、電子広告媒体にアクセスして前記計算要求を取得することを含む、陳述１Aないし３１Aのうちいずれか一項に記載の方法。
〔陳述３３A〕
前記電子広告媒体がサードパーティーのサーバー設備または前記検証者のコンピュータ設備において実装されている、陳述３２Aに記載の方法。
〔陳述３４A〕
前記電子広告媒体はブロックチェーンまたは他のピアツーピア公開媒体である、陳述３２Aに記載の方法。
〔陳述３５A〕
前記計算を受け入れる受け入れ信号を、前記目標者から前記検証者に送信することを含む、陳述１Aないし３４Aのうちいずれか一項に記載の方法。
〔陳述３６A〕
前記目標コンピュータ設備が、分散コンピューティングを実行する分散コンピューティングシステムに関わる複数のコンピュータ設備のうちの1つであり、前記計算は前記分散コンピューティングの一部である、陳述１Aないし３５Aのうちいずれか一項に記載の方法。
〔陳述３７A〕
前記分散コンピューティングは計算毎の支払いベースで実行され、前記検証者が前記公開鍵に基づいて前記目標者の署名を検証することを条件に、前記目標者は前記計算の実行について支払いを受け取る、陳述３６Aに記載の方法。
〔陳述３８A〕
メッセージが前記目標コンピュータ設備において前記計算を実行した時間を示すタイムスタンプをさらに含む、陳述１Aないし３７Aのうちいずれか一項に記載の方法。
〔陳述３９A〕
前記PUFモジュールは、PUFと決定論的な変換関数を有しており：前記PUFにベース入力を入力して対応するベース出力を生成し；前記レスポンスを生成するために、生成されたベース出力との関連で前記チャレンジを前記変換関数に入力する
ことによって、前記レスポンスを生成するように構成されており、前記変換関数は前記チャレンジおよび前記生成されたベース出力の関数である、陳述１Aないし３８Aのうちいずれか一項に記載の方法。
〔陳述４０A〕
一つまたは複数のメモリ・ユニットを含むメモリと；一つまたは複数の処理ユニットを含む処理装置とを有するコンピュータ設備であって、前記メモリは前記処理装置で実行されるように構成されたコードを記憶し、前記コードは前記処理装置上のときに陳述１Aないし３９Aのうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ設備。
〔陳述４１A〕
非一時的なコンピュータ可読媒体に具現されたコンピュータ・プログラムであって、一つまたは複数のプロセッサで実行されたとき、陳述１Aないし３９Aのうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ・プログラム。

Claims (39)

  1. 計算を実行するコンピュータ実装される方法であって、当該方法は、前記計算を実行するコンピュータ設備である目標者の目標コンピュータ設備によって：
    物理的複製不能関数PUFを含むPUFモジュールによって生成されたレスポンスから導出される暗号鍵を得る段階であって、前記レスポンスは、前記PUFモジュールに入力された対応するチャレンジに応答して前記PUFに基づいて前記PUFモジュールによって生成されたものであり、前記暗号鍵または対応する公開鍵を含む鍵情報は検証者に対しても利用可能にされる、段階と；
    発行者から、実行されるべき前記計算を指定する計算要求を受信する段階と；
    前記計算要求に応答して、計算結果を生成するために前記計算を実行する段階と；
    前記計算結果を含むメッセージに、前記暗号鍵を用いて署名する段階と；
    署名されたメッセージをブロックチェーン上に記録されるように送信することによって、前記署名されたメッセージを前記検証者に対して利用可能にする段階と
    を実行することを含む、方法。
  2. 前記発行者が前記検証者である、請求項１に記載の方法。
  3. 前記署名されたメッセージを送信することは：
    前記目標者が前記署名されたメッセージを含むテンプレート・ブロックチェーン・トランザクションを定式化し；
    前記目標者が前記テンプレート・ブロックチェーン・トランザクションを前記検証者に送信し、それにより前記検証者に前記メッセージの前記署名を検証させ、それに依存して少なくとも前記検証者の署名で署名することによって前記テンプレート・トランザクションを完成させ、完成されたトランザクションを前記ブロックチェーンに記録されるよう転送させることを含む、
    請求項１または２に記載の方法。
  4. 前記メッセージは前記テンプレート・トランザクションの少なくとも一部を含む、請求項３に記載の方法。
  5. 前記完成されたトランザクションは、ひとたび前記ブロックチェーンに記録されたら前記計算について前記目標者に支払いをする、請求項３または４に記載の方法。
  6. 前記完成されたトランザクションは、前記ブロックチェーン上の資金調達トランザクションの出力をポイントする入力と、前記資金調達トランザクションの前記出力から前記目標者に、前記発行者の少なくとも一部の資金を割り当てる出力とを含むことによって、前記目標者に支払いをするものであり、ここで、前記資金調達トランザクションの前記出力は、指定されたタイムアウト期間後に前記目標者に割り当てられなかった場合に、前記資金が前記発行者に移転し戻されることを可能にするタイムアウト条件を含む、請求項５に記載の方法。
  7. 前記暗号鍵を得ることが実行され、前記目標者が前記計算要求を受信する前のセットアップ・フェーズにおいて、前記鍵情報が前記検証者に対して利用可能にされる、請求項１ないし６のうちいずれか一項に記載の方法。
  8. 前記得ることは：
    前記発行者、検証者または信頼されるサードパーティーから前記レスポンスを受信することを含み、前記チャレンジは、前記目標者に代わって、前記発行者、検証者または信頼されるサードパーティーによって、前記レスポンスを生成するために前記PUFモジュールに入力されたものであり、前記公開‐秘密鍵ペアの生成は、受信された前記レスポンスに基づく、
    請求項１ないし７のうちいずれか一項に記載の方法。
  9. 前記得ることは：
    前記発行者、検証者または信頼されるサードパーティーから前記公開鍵を受信することを含み、前記チャレンジは、前記目標者に代わって、前記レスポンスを生成し、前記暗号鍵ペアを導出するために前記発行者、検証者または信頼されるサードパーティーによって前記PUFに入力されたものである、
    請求項１ないし７のうちいずれか一項に記載の方法。
  10. 前記サードパーティーが前記鍵情報を前記検証者に対して利用可能にする、請求項８または９に記載の方法。
  11. 前記得ることが：
    前記目標者が、前記チャレンジの前記PUFモジュールへの入力を実行して前記レスポンスを生成し、前記目標者によって前記暗号鍵を導出することを含む、請求項１ないし７のうちいずれか一項に記載の方法。
  12. 前記目標コンピュータ設備が自己完結した目標デバイスの形をとり；
    ・前記PUFモジュールが前記目標デバイスと同じ筐体内に組み込まれているか、または
    ・前記PUFモジュールが前記目標デバイスにネットワークではなくケーブルによって接続されている外部周辺機器において実装されている、
    請求項１１に記載の方法。
  13. 当該方法が、前記目標者が前記鍵情報を前記検証者に対して利用可能にすることを含む、請求項１１または１２または請求項１ないし９のうちいずれか一項に記載の方法。
  14. 前記鍵情報を前記検証者に対して利用可能にすることが：前記鍵情報を前記検証者に送信することを含む、請求項１ないし１３のうちいずれか一項に記載の方法。
  15. 前記鍵情報を前記検証者に対して利用可能にすることが：前記鍵情報を、前記検証者にとってアクセス可能な鍵情報記憶媒体に、前記目標者または目標コンピュータ設備の素性にリンクされて記憶することを含む、請求項１ないし１３のうちいずれか一項に記載の方法。
  16. 前記鍵情報記憶媒体が、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装されている、請求項１５に記載の方法。
  17. 前記鍵情報記憶媒体がブロックチェーンまたは他のピアツーピア公開媒体である、請求項１６に記載の方法。
  18. 前記暗号鍵が、非対称公開‐秘密鍵ペアの秘密鍵を含み、前記非対称公開‐秘密鍵ペアは前記秘密鍵と対応する公開鍵を含み、前記鍵の公開‐秘密鍵ペアが前記レスポンスから導出され、前記検証者に対して利用可能にされる前記鍵情報が前記公開鍵を含む、請求項１ないし１７のうちいずれか一項に記載の方法。
  19. 前記暗号鍵が対称認証方式の鍵を含み、前記検証者に対して利用可能にされる前記鍵情報も該暗号鍵を含む、請求項１ないし１７のうちいずれか一項に記載の方法。
  20. 解読するために解読鍵を必要とするように前記計算結果を暗号化することを含み、前記計算結果は暗号化された形でのみ前記検証者に対して利用可能にされ、前記解読鍵は前記検証者および／または発行者に対して利用可能にされる、請求項１ないし１９のうちいずれか一項に記載の方法。
  21. 前記暗号化は、前記秘密鍵で署名する前に前記計算結果を暗号化することを含む、請求項２０に記載の方法。
  22. 前記暗号化は、前記秘密鍵で署名した後に前記メッセージを暗号化することを含む、請求項２０に記載の方法。
  23. 前記解読鍵は、前記PUFモジュールまたは別のPUFモジュールによって、該PUFモジュールに前記目標者、検証者、発行者、または信頼されるサードパーティーによって入力された別のチャレンジに応答して生成される別のレスポンスから導出される、請求項２０ないし２２のうちいずれか一項に記載の方法。
  24. 当該方法は、前記目標者が前記別のレスポンスを入力して前記別のチャレンジを生成し、前記解読鍵を導出することを含む、請求項２３に記載の方法。
  25. 前記目標者が前記解読鍵を前記検証者および／または発行者に対して利用可能にすることを含む、請求項２０ないし２４のうちいずれか一項に記載の方法。
  26. 前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を前記検証者および／または発行者に送信することを含む、請求項２０ないし２５のうちいずれか一項に記載の方法。
  27. 前記解読鍵を前記検証者および／または発行者に対して利用可能にすることが：前記解読鍵を、前記検証者および／または発行者にとってアクセス可能な解読鍵記憶媒体に記憶することを含む、請求項２０ないし２５のうちいずれか一項に記載の方法。
  28. 前記解読鍵記憶媒体は、一つまたは複数の物理サイトにある一つまたは複数のサーバー・ユニットを含むサードパーティーのサーバー設備において実装される、請求項２７に記載の方法。
  29. 前記解読鍵記憶媒体はブロックチェーンまたは他のピアツーピア公開媒体である、請求項２７に記載の方法。
  30. 前記計算要求の受信が、電子広告媒体にアクセスして前記計算要求を取得することを含む、請求項１ないし２９のうちいずれか一項に記載の方法。
  31. 前記電子広告媒体がサードパーティーのサーバー設備または前記検証者のコンピュータ設備において実装されている、請求項３０に記載の方法。
  32. 前記電子広告媒体はブロックチェーンまたは他のピアツーピア公開媒体である、請求項３０に記載の方法。
  33. 前記計算を受け入れる受け入れ信号を、前記目標者から前記検証者に送信することを含む、請求項１ないし３２のうちいずれか一項に記載の方法。
  34. 前記目標コンピュータ設備が、分散コンピューティングを実行する分散コンピューティングシステムに関わる複数のコンピュータ設備のうちの1つであり、前記計算は前記分散コンピューティングの一部である、請求項１ないし３３のうちいずれか一項に記載の方法。
  35. 前記分散コンピューティングは計算毎の支払いベースで実行され、前記検証者が前記鍵情報に基づいて前記目標者の署名を検証することを条件に、前記目標者は前記計算の実行について支払いを受け取る、請求項３４に記載の方法。
  36. メッセージが前記目標コンピュータ設備において前記計算を実行した時間を示すタイムスタンプをさらに含む、請求項１ないし３５のうちいずれか一項に記載の方法。
  37. 前記PUFモジュールは、PUFと決定論的な変換関数を有しており：
    ・前記PUFにベース入力を入力して対応するベース出力を生成し；
    ・前記レスポンスを生成するために、生成されたベース出力との関連で前記チャレンジを前記変換関数に入力する
    ことによって、前記レスポンスを生成するように構成されており、前記変換関数は前記チャレンジおよび前記生成されたベース出力の関数である、
    請求項１ないし３６のうちいずれか一項に記載の方法。
  38. 一つまたは複数のメモリ・ユニットを含むメモリと；
    一つまたは複数の処理ユニットを含む処理装置と
    を有するコンピュータ設備であって、前記メモリは前記処理装置で実行されるように構成されたコードを記憶し、前記コードは前記処理装置上のときに請求項１ないし３７のうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ設備。
  39. 非一時的なコンピュータ可読媒体に具現されたコンピュータ・プログラムであって、一つまたは複数のプロセッサで実行されたとき、請求項１ないし３７のうちいずれか一項に記載の方法を実行するように構成されている、コンピュータ・プログラム。
JP2023519324A 2020-09-30 2021-08-31 認証システムおよび方法 Pending JP2023543456A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2015541.2A GB2599416A (en) 2020-09-30 2020-09-30 Authentication system and method
GB2015541.2 2020-09-30
PCT/EP2021/073964 WO2022069133A1 (en) 2020-09-30 2021-08-31 Authentication system and method

Publications (1)

Publication Number Publication Date
JP2023543456A true JP2023543456A (ja) 2023-10-16

Family

ID=73005643

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023519324A Pending JP2023543456A (ja) 2020-09-30 2021-08-31 認証システムおよび方法

Country Status (8)

Country Link
US (1) US20230336366A1 (ja)
EP (1) EP4169208A1 (ja)
JP (1) JP2023543456A (ja)
KR (1) KR20230073236A (ja)
CN (1) CN116235460A (ja)
GB (1) GB2599416A (ja)
TW (1) TW202217610A (ja)
WO (1) WO2022069133A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112487380B (zh) * 2020-12-16 2024-04-05 江苏国科微电子有限公司 一种数据交互方法、装置、设备及介质
CN112906057B (zh) * 2021-03-18 2023-09-01 上海零数众合信息科技有限公司 一种可信构建链上隐私链上交易的计算方法
TWI818733B (zh) * 2022-09-19 2023-10-11 林藎誠 共享服務加密系統及裝置
CN117278330B (zh) * 2023-11-21 2024-03-12 国网江西省电力有限公司电力科学研究院 一种电力物联网设备网络的轻量级组网与安全通信方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11271759B2 (en) * 2018-09-05 2022-03-08 Arizona Board Of Regents On Behalf Of Northern Arizona University Secure digital signatures using physical unclonable function devices with reduced error rates
EP3935586A1 (en) * 2019-03-04 2022-01-12 nChain Licensing AG Method of using a blockchain

Also Published As

Publication number Publication date
CN116235460A (zh) 2023-06-06
US20230336366A1 (en) 2023-10-19
TW202217610A (zh) 2022-05-01
EP4169208A1 (en) 2023-04-26
KR20230073236A (ko) 2023-05-25
GB2599416A (en) 2022-04-06
WO2022069133A1 (en) 2022-04-07
GB202015541D0 (en) 2020-11-11

Similar Documents

Publication Publication Date Title
US20230336366A1 (en) Authentication system and method
US20230360047A1 (en) Verification system and method
US20230362019A1 (en) Physically unclonable functions storing response values on a data store
US20240015033A1 (en) Physically unclonable functions
US20230379175A1 (en) Challenge-response protocol based on physically unclonable functions
US20230370288A1 (en) Physically unclonable functions storing response values on a blockchain
WO2022218629A1 (en) Blockchain based system and method
JP2024506738A (ja) ＰＵＦおよびブロックチェーンベースのＩｏＴイベントレコーダおよび方法