JP2023543474A - 物理複製困難関数 - Google Patents

物理複製困難関数 Download PDF

Info

Publication number
JP2023543474A
JP2023543474A JP2023519749A JP2023519749A JP2023543474A JP 2023543474 A JP2023543474 A JP 2023543474A JP 2023519749 A JP2023519749 A JP 2023519749A JP 2023519749 A JP2023519749 A JP 2023519749A JP 2023543474 A JP2023543474 A JP 2023543474A
Authority
JP
Japan
Prior art keywords
party
challenge
response
puf
challenges
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
JP2023519749A
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 JP2023543474A publication Critical patent/JP2023543474A/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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/321—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 a third party or a trusted authority
    • 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
    • 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)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Document Processing Apparatus (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

検証者がターゲット当事者またはデバイスのアイデンティティを検証することを可能にする方法が提供される。この方法は、セットアップフェーズにおいて、データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力してPUFに基づき1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶することと、チャレンジのセットの指示をデータストアに記憶することとを含む。指示は、セット内のチャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジのセットが導出可能であるマスターチャレンジを含む。

Description

本開示は、物理複製困難関数、すなわちPUFの分野に関する。
物理複製困難関数(PUF)は、決定論的であるが予測不可能な物理現象を含む関数を指す用語である。PUFは、ときには物理的乱数関数とも称される。PUFは、「チャレンジ」と称されるインプットを受け取り、チャレンジおよびPUFによって採用される物理現象に応じて、対応する「応答」と称されるアウトプットを生成する。PUFは、ときには強いPUFと弱いPUFに分類される。強いPUFは、多数の異なるチャレンジに対してそれぞれの応答を生成することができ、典型的には、チャレンジの任意の値を取ることができる。弱いPUFは、単一の応答のみ、または少数の応答に対して応答を生成することができる(典型的には、チャレンジは任意の値を取ることができない)。言い換えると、強いPUFは多数のチャレンジ-応答ペア(challenge-response pair)を有し(それは大きなチャレンジ-応答空間を有し)、その一方で、弱いPUFは単一のチャレンジ-応答ペアまたは限られた数のチャレンジ-応答ペア(小さいまたは限られたチャレンジ-応答空間)を有する。一定義によれば、弱いPUFはチャレンジビット(challenge bit)の数において線形である多数の応答、またはより一般的に、他のパラメータにおいて線形以上には増大しない応答を有する。
強いPUFの知られている例は、光学的PUFである。たとえば、光学的PUFは、レーザー、光学センサー、および気泡または他のそのようなアーティファクトが媒体中にセットされた固体光学媒体を含み得る。レーザーは、制御可能な角度で光学媒体を通して照射され、回折または散乱パターン(媒体中の気泡またはアーティファクトの効果である)を生成する。センサーは、このパターンを感知するように配置構成される。チャレンジは、レーザーの角度であり、応答は、感知されたパターンに基づき生成される。
弱いPUFの例は、SRAM PUFである。この場合、チャレンジは、SRAM(スタティックランダムアクセスメモリ)の電源を入れることである。SRAM毎に製造上のわずかな違いがあるので、電源投入時にSRAMセルが0/1状態の固有のパターンに入り、それにより個々のSRAMの特徴的なフィンガープリントを形成する。PUFは、これを電源投入後の応答として出力するように構成される。
PUFは、暗号アルゴリズムにおいて使用する(たとえば、文書に署名する、または暗号化する)などのための鍵を生成する手段として使用され得る。PUFの別の用途は、PUFを組み込んだコンピュータデバイスなどのデバイスの識別である。所与のチャレンジに対する期待される応答が以前に決定されている場合、検証者は、後でターゲットデバイスにチャレンジを挑み、それが期待される応答を与えるかどうかをチェックし、それによってターゲットデバイスが期待される応答に関連付けられているデバイスであるかどうかをチェックすることができる。
チャレンジ応答空間が限られているので、弱いPUFへのインプット-アウトプット(i/o)インターフェースは、1つまたは限られた数の当事者のみに制限される傾向がある(たとえば、1つまたは限られた数の信頼できる当事者のみがPUFへのアクセスを物理的にまたは合法的に付与され得るか、またはPUFへのインターフェースがパスワード保護されるか、または同様のことが行われ得る)。すなわち、注目する1人または複数の当事者のみが、チャレンジを提出する必要があるPUFへのインプットおよび返された応答の受け取りに使用されるアウトプットへのアクセスを得ることができる。その一方で、強いPUFでは、強いPUFへのi/oインターフェースは、多数の、または無制限の数の当事者に対して広く利用可能にされ得るが、それらのすべてが必ずしも、知られている当事者または信頼できる当事者とは限らない。その理由は、チャレンジ応答空間が十分に大きく、敵対者がチャレンジ-応答ペアのすべてを列挙することは実行不可能であり、したがって、敵対者がPUFに自由にアクセスする能力は、弱いPUFの場合のように、PUFの列挙およびスプーフィングを許すことによってそのセキュリティを損なうことはないはずだからである。
異なる技術分野では、ブロックチェーンは、ブロックチェーンの複製が分散ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と称される)内の複数のノードの各々において維持され、広く公開される分散データ構造の一形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の、各トランザクションは、1つまたは複数のコインベーストランザクションに遡る1つまたは複数のブロックにまたがり得るシーケンス内の前のトランザクションを指す。コインベーストランザクションについては後述する。ブロックチェーンネットワークに提出されたトランザクションは、新しいブロックに含まれる。新しいブロックは、しばしば「マイニング」と称されるプロセスによって作成され、このプロセスは複数のノードの各々が「プルーフオブワーク」を実行することを競う、すなわち、ブロックチェーンの新しいブロックに入れられるのを待つ順序付けられ正当性確認された保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合うことを伴う。ブロックチェーンはいくつかのノードのところで剪定されることがあり、ブロックの公開は単なるブロックヘッダの公開を通じて達成され得ることに留意されたい。
ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、多数のデジタルトークン)を伝達すること、仮想化台帳(virtualised ledger)またはレジストリ内の一連のエントリを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間順序付けする(time-order)ことのうちの1つまたは複数の目的に使用され得る。ブロックチェーンは、また、ブロックチェーンの上に追加の機能を層化するために利用され得る。たとえば、ブロックチェーンプロトコルは、追加のユーザデータまたはデータへのインデックスをトランザクション内に記憶することを可能にし得る。単一のトランザクション内に記憶できる最大データ容量には事前指定された制限はなく、したがって次第により複雑になってゆくデータが組み込まれ得る。たとえば、これは、ブロックチェーンに電子文書を、またはオーディオもしくはビデオデータを記憶するために使用できる。
ブロックチェーンネットワークのノード(「マイナー」と称されることが多い)は、分散トランザクション登録および検証プロセスを実行するが、これについては後でさらに詳しく説明することにする。要約すると、このプロセスにおいてノードはトランザクションを正当性確認し、それをブロックテンプレートに挿入し、これに対して有効なプルーフオブワークの解を識別することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに伝播され、それにより各ノードがブロックチェーン上に新しいブロックを記録することを可能にする。ブロックチェーンにトランザクションを記録させるために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)はトランザクションをネットワークのノードの1つに送信し、伝播される。トランザクションを受信したノードは、正当性確認されたトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけるために競争し得る。各ノードは同じノードプロトコルを強制するように構成されており、これにはトランザクションが有効であるための1つまたは複数の条件を含み得る。無効なトランザクションは伝播されることも、ブロックに組み込まれることもない。トランザクションが正当性確認され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション(任意のユーザデータを含む)は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々に登録され、インデックスを付けられたままとなる。
最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは、典型的には、デジタル資産の額、すなわちトークンの数を分配する「コインベーストランザクション」と呼ばれる新しいトランザクションで報われる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして活動する競合ノードの活動によって強制され、違法行為を報告しブロックするインセンティブを与えられる。情報が広く公開されることは、ユーザがノードのパフォーマンスを継続的に監査することを可能にする。単なるブロックヘッダの公開は、参加者がブロックチェーンの継続的整合性を確実にすることを可能にする。
「アウトプットベース」モデル(ときにはUTXOベースモデルと称される)では、所与のトランザクションのデータ構造は、1つまたは複数のインプットおよび1つまたは複数のアウトプットを備える。任意の消費可能アウトプットは、進行中の一連のトランザクションから導出可能なデジタル資産の額を指定する要素を含む。消費可能アウトプットは、ときにはUTXO(「未使用トランザクションアウトプット」)と称される。アウトプットは、アウトプットの将来の償還のための条件を指定するロッキングスクリプトをさらに含んでもよい。ロッキングスクリプトは、デジタルトークンまたは資産を正当性確認して移転するために必要な条件を定義する述語である。(コインベーストランザクション以外の)トランザクションの各インプットは、先行するトランザクションにおけるそのようなアウトプットへのポインタ(すなわち参照)を含み、さらに、指し示されたアウトプットのロッキングスクリプトをロック解除するためのロック解除スクリプトを含み得る。そこで、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定する少なくとも1つのアウトプットを含み、アウトプットをロック解除する1つまたは複数の条件を定義するロッキングスクリプトを含む。第2のターゲットトランザクションは、第1のトランザクションのアウトプットへのポインタを含む少なくとも1つのインプットと、第1のトランザクションのアウトプットをロック解除するためのロック解除スクリプトとを含む。
そのようなモデルでは、第2のターゲットトランザクションがブロックチェーンネットワークに送信されてブロックチェーンに伝播され記録されるときに、各ノードで適用される有効性の基準の1つは、ロック解除スクリプトが第1のトランザクションのロッキングスクリプトで定義された1つまたは複数の条件のすべてを満たすことである。もう1つは、第1のトランザクションのアウトプットが、別の以前の有効なトランザクションによってすでに償還されていないことである。これらの条件のいずれかに従ってターゲットトランザクションが無効であることを発見したノードは、それを(有効なトランザクションとして、しかし場合によっては無効なトランザクションを登録するために)伝播することも、ブロックチェーンに記録されるべき新しいブロックにそれを含めることもしない。
トランザクションモデルの代替的タイプはアカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別のノードによって記憶され、常に更新される。
本明細書において開示されている一態様によれば、1人または複数の検証者が、ターゲット当事者またはターゲット当事者のデバイスを含むターゲットのアイデンティティを検証することを可能にするためのコンピュータ実装方法が提供される。この方法は、セットアップフェーズにおいて、データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力してPUFに基づき1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶することを含む。この方法は、チャレンジのセットの指示をデータストアに記憶することであって、指示は、セット内のチャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジのセットが導出可能であるマスターチャレンジを含む、記憶することと、それによって、応答データおよびそれぞれのチャレンジのうちの少なくとも1つを、後続の検証フェーズにおいてターゲットのアイデンティティを検証するために1人または複数の検証者に利用可能にすることとをさらに含む。各応答に対するそれぞれの応答データは、それぞれの応答それ自体またはそれから導出されたデータを含み得る。
したがって、この方法は、チャレンジ-応答(CR)ペアまたは同様のものを記憶する軽量の手段を提供し、これはすべての応答に対してチャレンジが明示的に記憶されることを必要としない。
実施形態において、マスターチャレンジは、ターゲットの識別情報、たとえば、ターゲット当事者のパスポート情報、生体測定情報、または秘密の個人情報(たとえば母親の旧姓)を含み得る。このようにして、複数の異なるターゲットに対してチャレンジの異なるセットが導出されることを可能にするなど、特定のターゲットに固有のチャレンジのセットが容易に提供され得る。識別情報は、ターゲット当事者がすでに知っているか、または安全(たとえば秘密)に保っている情報を含み得る。
実施形態において、データストアは、ブロックチェーンなどのピアツーピア公開媒体を備え得る。代替的に、データストアは、信頼できる第三者のコンピュータ機器(たとえば、1つまたは複数の地理的サイトで1つまたは複数のサーバユニットを備える、信頼できる第三者のサーバ)内に実装されることも可能である。
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、添付の図面が参照される。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例の概略を例示する図である。 PUFのチャレンジおよび応答の概略を例示する図である。 PUFを含むシステムの概略ブロック図である。 本明細書において開示されている実施形態による拡張PUFの概略ブロック図である。 非拡張動作モードにおける拡張PUFの概略ブロック図である。 チャレンジ-応答ペアの配布に信頼できる第三者または出版メディアが関与するシステムの概略図である。 本明細書において開示される実施形態による検証プロセスの概略フローチャートである。 本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。 本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。 本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。 チェーン上の応答データの記録する方法の概略を例示する図である。
人間と機械の両方に対する鍵生成システムおよびプライバシー保護アイデンティティシステムなどのシステムのロバスト性は、物理複製困難関数(PUF)の関与によって改善され得る。これらは、互いにやり取りしている当事者および/もしくは自律的機械、またはブロックチェーンなどの公共システムであってもよい。
これらの関数は、物理的システムに基づき、物理的デバイスの製造においてランダムな、決定不可能な、および再現不可能な変動があるという仮定によって保証され、人間のアイデンティティとそのデバイスとの間に確立されたリンクを強化するために、またはさらにデバイスそれ自体の偽造不可能な一意のアイデンティティを確立するために使用され得る。
文献では、PUFは弱いタイプと強いタイプとに分類され、その異なる特性によって分類される。以下の一態様によれば、これらのタイプのPUFの両方の利点を有する実用的なPUFデバイスを記述するための一般化拡張PUF(ePUF)フレームワークが提供される。すなわち、ePUFは、実装のために実用性および費用効率を維持しながら、アプリケーションで使用される大きな範囲のチャレンジ-応答ペアを生成し得る。
より一般的に、PUFおよびチャレンジ-応答ペアの管理に関係する様々な態様が本明細書において開示される。これらの異なる態様は、個別に、または任意の組合せで使用されてよい。これらは、たとえば、以下のものを含む。
I. PUFのチャレンジ-応答空間を拡張するための拡張PUF、
II. ePUFデバイスを使用することによって人間および/またはデバイスのアイデンティティを確立するためのブロックチェーンにとらわれないプロトコルのセット、
III. ブロックチェーンを活用することによってこれらのアイデンティティプロトコルを改善するためのフレームワーク、
IV. チャレンジ-応答ペアの軽量記憶のための技術、および
V. 簡易決済検証(SPV)プロセスのための、およびデバイスによる検証可能計算のための、KYCの実装などの、様々な問題に対するePUFデバイスの新規性のあるアプリケーションのセット。
1. 物理複製困難関数(PUF)-前置き
物理複製困難関数(PUF)という用語とは、汎用確率関数として働く物理的システムおよびデバイスのクラスを指す。これらのPUFは、多くの場合にサブミクロンスケールの、その物理的特性によって一意的に特徴付けられ、これは物理的刺激を用いてその特性を調べることによって一意的に識別され、検証され得る。高いレベルでは、PUFをチャレンジを応答にマッピングする関数と考えることができ、そのペアは多くの場合にチャレンジ-応答ペア(CRP)と称される。記法
F:C->R∀(C,R)∈ΦF
を使用してそのようなマッピングFを記述することができ、
C、Rはチャレンジおよび応答をそれぞれ表し、ΦFはPUFによって生成され得る形式(C,R)のすべてのチャレンジ-応答ペアの集合である。
PUFの一意的な物理的特性は、典型的には、シリコンチップなどの、物理的デバイスの製造に固有のランダムなプロセス変動の結果である。PUFに関して典型的になされる仮定は、以下の通りである。
1. 物理的システムのパラメータを任意の形式の解析によって完全に決定することは困難である。
2. 物理的システムのパラメータは、PUFとして使用されるデバイスの正規製造業者を含む、いかなる当事者にも知られていない。この仮定は、多くの場合に、製造業者耐性(manufacturer-resistance)と称される。
これらの仮定は、PUFが任意のチャレンジに対して予測不可能でありしかも決定論的である応答を生成するために使用されることを可能にする。このチャレンジ-応答プロセスでは、図3に例示されているように、PUFを物理的ブラックボックスのように取り扱う。
図3は、物理的ブラックボックスとしてモデル化されたPUF302を示す。提出者103Sは、チャレンジCをPUF302へのインプットとして提出し、それに応答してPUF302は対応する応答Rを生成する。提出者は、提出者のコンピュータデバイス(図示せず)などのデバイスからチャレンジを提出するが、これはPUF302それ自体が実装されているデバイスと同じまたは異なるデバイスであり得る。
提出者103Sは、ターゲット当事者またはデバイスのアイデンティティにリンクされている期待される応答のセットを確立するためのセットアップフェーズ(後述の例)の一部としてチャレンジ-応答(CR)ペアを生成する当事者であり得る。または、提出者103Sは、生成された応答が期待された応答と一致することを検証するために、後の検証フェーズでチャレンジを提出する検証者であり得、したがって、PUF302を含むターゲットデバイスまたはPUFを所持するターゲット当事者のアイデンティティを検証することが可能である。
別の例示的なシナリオでは、提出者103Sは、ブロックチェーンアプリケーションなどの暗号アプリケーションにおいて使用するための鍵、または鍵を生成するためのシードとして、生成済み応答を使用する(たとえば、ブロックチェーントランザクションに署名するため)ことを望む当事者であり得る。
図4は、PUF302へのインターフェースの一例を備えるシステムを示している。システムは、プロセッサ402およびPUF302を備える。インターフェースは、メモリに記憶され、プロセッサ402上で実行するように配置構成されている、インターフェースロジック404を備える。インターフェースロジック404が記憶されるメモリは、1つもしくは複数の記憶媒体(たとえば、磁気ディスクもしくはテープなどの磁気媒体、またはROM、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAMなどの電子媒体)を採用する1つもしくは複数のメモリユニットを含み得る。プロセッサ402は、1つもしくは複数の処理ユニット(たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、もしくは暗号プロセッサなどのアプリケーション固有またはアクセラレータプロセッサ)を備え得る。また、インターフェースロジック404が、代わりに、専用ハードウェア回路、またはPGAもしくはFPGAなどの構成可能もしくは再構成可能な回路において部分的にもしくは全体的に実装されることが可能であることも除外されない。
提出者103Sは、デバイス(図示せず)を使用して、インターフェースロジック404を介してチャレンジー(challengee)CをPUF302に提出する。提出者103Sによって使用されるデバイスは、たとえば、外部コンピュータデバイスまたはプロセッサ402が実装されている同じコンピュータデバイスのいずれかのコンピュータデバイスとすることが可能である。次いで、PUF302は、対応する応答Rを、インターフェースロジック404を介して提出者302のデバイスに戻す。後でより詳細に説明されている、いくつかの実施形態において、インターフェースロジック404は、PUF302へのアクセスを何人かの当事者、たとえば、パスワード、PIN、または生体測定情報などの認識された資格情報を提示することができる当事者のみに制限するアクセス制御ロジック406を含んでよい。および/または、プロセッサ402を備えるデバイスへの物理的インターフェースは、許可された人員のみがアクセス権を有する部屋または複合体内に配置されること、または鍵の掛かった箱またはキャビネット内に保管されることなどによって、制限され得る。しかしながら、代替的システムでは、インターフェースロジック404は、任意の当事者がチャレンジで問い合わせるために利用可能にされ得る。
PUFのチャレンジ-応答プロセスは、選択された応答からこれらのチャレンジを抽出することによって、擬似乱数データ値の生成を可能にする。たとえば、PUFは、暗号で使用するべきランダムな再現性のあるデータを抽出するための鍵生成器として使用することができる。PUF302は、複数の別々の機会に同じチャレンジを与えられたときにPUFが同一の応答をもたらすような、決定論的で再現可能な方法で働くことに留意されたい。
PUFとして使用され得る多くの異なる物理的システムがあり、またこれらのシステムを使用するPUFの多くの異なる実装形態が存在する。PUFの例示的な例は、気泡を含む光学的媒体であり、これはレーザーで探査されたときに、(i)レーザーの位置、(ii)光学的媒体の小規模パラメータによって決定論的に決定される応答回折または「スペックル」パターンを生成する。
1.1. PUFのクラス
1.1.1 弱いPUF:弱いPUFは、小さいチャレンジ-応答空間を有することによって特徴付けられ、多くはCRP空間のサイズが|ΦF|=1であるような単一のチャレンジしか有しない。一般に、弱いPUFに対するチャレンジ-応答空間は、0(n)のオーダーであると考えられ、nは制御不可能な製造ばらつきの影響を受けやすいPUFにおけるコンポーネントの数である。
弱いPUFの場合、典型的には、PUFの応答へのアクセスが制限されることも仮定される。これは、弱いPUFによるサービスを受けるCRPの数が少ないので、敵対者が妥当な時間内にすべてのそのようなペアを列挙し得、したがってPUFの挙動を模倣するか、または「スプーフィング」し得るからである。この制限は、ときには、弱いPUFの挙動を説明するときに制限されたチャレンジ-応答インターフェースと称される。
これらの特性により、弱いPUFは、鍵生成器として暗号アプリケーションで使用するのに最も自然に適していることになり、PUFによって生成された1つの(または少数の)CRPは、デバイス上の不揮発性メモリ(NVM)を暗号化することまたはHMAC対称鍵として使用することなど、暗号化操作用の秘密鍵として使用され得る。そのような場合、PUFの応答から導出される鍵は、実行される暗号化プロセスおよびPUFそれ自体の両方のセキュリティのために秘密にされ、デバイスの所有者にのみ知られていなければならない。
弱いPUFの顕著な、広く実装されている例は、SRAM PUFであり、「SRAM」という用語は、「スタティックランダムアクセスメモリ」を指す。SRAM PUFの設計は、SRAMチップの「電源オン」状態のばらつきを活用し、各々チップ内のSRAMセルがチップの電源オン時に「0」状態または「1」状態であるばらつきによる固有のフィンガープリントを有する。
この場合、PUF構成は、PUFを探査するための固定モード(すなわち、SRAMチップの電源投入による)が1つあり、したがって単一のCRPのみであるので、弱いと考えられる。この場合、唯一無二の「チャレンジ」は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を提示されたときに応答RのみがPUFによって与えられるべきであり、プロセスにおいてPUFの内部動作または操作に関する他の情報が漏洩されるべきでないという制限が課せされる。この制限は、敵対者がPUFの挙動を支える物理的システムを特徴付けることを試み得る様々な分析的攻撃を軽減することである。これらは、文献ではモデリング攻撃と称されることが多い。
弱いPUFと同様に、いくつかの強いPUF構成は、デバイスによって生成される応答の正確さを保証するために誤り訂正技術に依存し得る。
強いPUFの主な既存のアプリケーションは、固有のチャレンジ-応答メカニズムを使用してシステムの認証および識別を円滑にすることである。これらのメカニズムは、直接的に2人の当事者間の共有秘密としてCRPの作成を伴うプロトコルに依存しており、多くの場合に、少なくとも一方の当事者が、他方の当事者に対する認証トークンとして使用される時間(初期セットアップ)より前にCRPのテーブルを生成する必要がある。
強いPUFの実装形態の最も初期の例の1つは、光学的PUFシステムであった。この構成では、PUFは、入射光を散乱させる、製造上のばらつきの結果の、ランダムに分布する物理的欠陥を収容する光学的媒体を含む。このPUFは、光学散乱媒体に向けられたレーザービームによって探査され得る。この場合、入射ビームの方向および偏光は、チャレンジを形成し、観察された散乱パターンは、PUFの応答とみなされる。
しかしながら、この強いPUF構成は、測定デバイスがPUFデバイスの残りの部分から分離しており、半導体コンポーネントと直接的に一体化することが困難であるという事実から、実装が複雑である。これは、装置それ自体に関連付けられるコストに加わり、配置構成のポータビリティの欠如が日常的な用途に対する実用性を低下させる。
アービターPUF(APUF)として知られている、電気的な一体化された強いPUFが、それ以降に提案されており、これはこれらの問題点のいくつかを克服するものとなっている。この構成は、信号多重化を利用し、電気コンポーネントにおける実行時遅延を活用する。多くの他の強いPUF構成が、並行して提案されているが、その多くは広く使用するための実用的な適合性を欠き、また多くがセキュリティおよび潜在的攻撃ベクトルに関する関連付けられている弱点を有している。たとえば、非常に問題となる潜在的攻撃は、中間者攻撃であり、攻撃者は平文で提出されたチャレンジを傍受し、保証計算をスプーフィングすることができる。
1.1.3. 制御されたPUF:制御されたPUF(CPUF)として知られている、第3のクラスのPUFは、既存の強いPUF構成を改良したものであるが、それらをビルディングブロックとして使用している。これらのPUFは、強いPUFを取り、PUFへのアクセスを制限する追加の制御ロジックを適用し、他の場合にはそれらを未保護チャレンジ-応答インターフェースを有し得る制御されない強いPUFから区別する。
図4に示されているように、今やより大きなPUFデバイスの一部である、PUFに適用される制御ロジック406は、PUF302それ自体へのアクセスを媒介し得る。これは、制御ロジックコンポーネント406が、どのチャレンジがPUFに提示されるかを制限し、さらにはその後の応答がどのようにユーザに明らかにされるかを制御できることを意味する。
CPUF構成において、好ましくは、制御ロジックコンポーネント406は、強いPUFコンポーネント内に埋め込まれるか、またはそれによって包まれるべきである。CPUFの一定義によれば、PUFは、不可分の方法でPUFに物理的にリンクされているアルゴリズムを介してのみアクセスできる場合(すなわち、アルゴリズムを回避する試みがPUFの破壊につながる)、制御されていると言われる。この埋め込みは、制御ロジックの探査をかなり難しくするべきである。
これは、PUFコンポーネントと制御ロジックコンポーネントとの間に、各々他方に対するある種の攻撃を軽減するような相互に有益な関係を確立する。すなわち、制御ロジックをPUFデバイスそれ自体内にカプセル化することは、これがPUFコンポーネントを取り返しが付かないほどに破損し、その応答を改変するので制御ロジックを物理的または侵略的攻撃から保護するが、制御ロジックは、PUFコンポーネントをCRPまたはPUFそれ自体の基盤となる内部物理的システムに関する他の情報を抽出するプロトコルレベルの攻撃から自然に保護する。
CPUFの用途は強いPUFとほぼ同じであるが、よりロバストな方式で達成され得る。特に、保証された計算と実行証明は、上で概略を述べたプロトコルで簡単に達成できる。
強いアービターPUF(APUF)の設計を拡張したCPUFの初期の例は、制御ロジックがすでに説明された方式でAPUFそれ自体と絡み合うことを必要とし、制御ロジックおよびAPUFは異なるタイプの攻撃から互いを相互に保護する。制御APUF設計は、システムの過渡応答を組み込むことによって集積回路(IC)からの単一の静的応答からCRPの大きなセットを生成する。
制御されたPUFの別の知られている例は、PUF-FSM構成である。これは、強いPUF(実際にはAPUF)を、APUFコンポーネントそれ自体のチャレンジ-応答インターフェースへのアクセスを制限する制御ロジックとして働く有限状態機械(FSM)と併せて含む。
1.2. 議論
1.2.1. 実用性:実用的で軽量でありながら、標準的な相補型金属酸化膜半導体(CMOS)コンポーネントと一体化可能でもある、強いPUFを生成することは、非常に困難であることは文献において認められている。対照的に、SRAM PUFなどの弱いPUFは、生成が安価であり、集積回路アーキテクチャと組み合わせることができることは自明であり得る。
1.2.2. PUFに対する攻撃:提案され、研究されてきた多くの異なる攻撃があり、異なる攻撃は特定のPUF構成またはクラスをターゲットとし得る。最も広く知られている攻撃タイプのいくつかが以下にリストされている。
・ MITM攻撃-これらの攻撃は、PUFの制御されていない強いPUFをターゲットにし、敵対者は、特に保証計算に使用されるときに、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)
次に、ベースPUF302の所与のCRペアから複数の二次CRペアを生成することによって、PUFのチャレンジ-応答(CR)空間を拡張するためのシステムおよび方法を開示する。これは、本明細書において、「拡張PUF」、または「ePUF」と称され得る。この考え方は、たとえば、典型的な強いPUFメカニズム(レーザー、光学媒体、およびセンサーを必要とする光学的PUFなど)の複雑さまたは非実用性なしで、1つまたは限られた数の固有CRペアのみを有する弱いPUFのチャレンジ-応答空間を拡大するために使用することも可能である。しかしながら、原理上、開示された技術は、より一般的に、弱い、強い、制御された、または他の何であろうと、任意のベースPUFのCRペアの数を拡張するために、または難読化または再利用性などの他の目的のために任意のPUFのCRペアを変換するために使用することも可能である。
図5Aは、本明細書において開示されている実施形態による拡張PUF(ePUF)500を示している。ePUF500は、たとえば従来の弱いPUFである可能性もある、構成要素ベース(constituent base)PUF302を備える。ePUF500は、変換関数502、たとえば暗号学的ハッシュ関数(たとえばSHA256など)などのハッシュ関数をさらに含む。ePUF500は、また、インターフェースロジック404'を備え、これは、図4に関連して説明されているインターフェースロジック404と類似するものであってよいが、追加のインターフェース機能を有する。インターフェースロジック404'および変換関数502は、ソフトウェア、たとえば組み込みファームウェアで実装されてもよく、これはメモリに記憶され、プロセッサ402(図4に示すようなもの、ただしインターフェース404'および変換関数502の追加の機能を実行する)上で実行するように配置構成される。インターフェース関数404'および変換ロジック504が記憶されるメモリは、1つもしくは複数の記憶媒体(たとえば、磁気ディスクもしくはテープなどの磁気媒体、またはROM、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAM、ヒューズラッチ、などの電子媒体)を採用する1つもしくは複数のメモリユニットを含み得る。これらが実行されるプロセッサは、1つもしくは複数の処理ユニット(たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、もしくは暗号プロセッサなどのアプリケーション固有またはアクセラレータプロセッサ)を備え得る。また、インターフェースロジック404'および/または変換関数502が、代わりに、専用ハードウェア回路、またはPGAもしくはFPGAなどの構成可能もしくは再構成可能な回路において部分的にもしくは全体的に実装されることが可能であることも除外されない。
インターフェースロジック404'は、変換関数502に動作可能に結合され、任意選択でベースPUF302にも結合される。ベースPUF302は、変換関数に動作可能に結合される。インターフェースロジック404'は、提出者103Sのデバイス(図5Aに図示せず)、たとえば、ePUF500が実装されているのと同じデバイスまたは外部デバイスである可能性もある、コンピュータデバイスからインプットを受け取り、そのデバイスにアウトプットを提供するように配置構成される。提出者103Sは、ePUF500を使用して、セットアップを実行し、将来の参照のためにアイデンティティにリンクされるべきチャレンジおよび期待される応答のセットを生成する当事者である可能性があるか、または後でPUFを使用して、生成された応答が以前に確立された期待される応答と一致するかどうかを検証する検証者(または、検証者に提供する応答を生成するチャレンジー)である可能性もある。別の例示的なアプリケーションでは、提出者103Sは、鍵として使用するための応答を生成するために、または鍵を生成するためのシードとして、ePUF500を使用する可能性もある。たとえば、これは、メッセージを暗号化するか、または署名する、たとえば、ブロックチェーントランザクションの一部に署名するために暗号鍵として使用される可能性もある。
ベースPUF302は、インプットとして「一次」チャレンジCwを受信することに対応して、アウトプットとして「一次」応答Rwを生成するように動作可能である。本明細書における「一次」チャレンジ-応答(CR)ペアは、ベース、構成PUF302のベースまたは「ネイティブ」(すなわち、固有)CRペアを指す。いくつかの実施形態において、ベースPUF302は、弱いPUFのように単一のチャレンジCwに応答して単一のベース(すなわち、一次)応答Cwのみを生成することができるものとしてよい。
動作時に、インターフェースロジック404'は、提出者103Sのデバイスから少なくとも1つの「二次」チャレンジCiを含むチャレンジデータ(チャレンジインプット)を受け取る。それに加えて、一次(ベース)応答Rwを生成するために一次(ベース)チャレンジCwがベースPUF302に入力される。実施形態において、提出者103Sは、ePUF500に入力されるチャレンジデータにベースチャレンジCwを含める必要があり、インターフェースロジック404'は、一次応答Rwを生成するためにこれをベースPUF302へルーティングする。しかしながら、他の実施形態において、一次チャレンジCwが、メモリ、ヒューズラッチ、または専用回路などの内部ソースからベースPUF302に入力されることは除外されない。いずれにせよ、変換関数502は、インプットとして、a)提出者からの入力されたチャレンジデータで受信されたような二次チャレンジCi、およびb)ベースPUF302によって生成されるような一次応答Rwを受け取るように配置構成される。変換関数502は、これらのものの組合せを、決定論的に、変換関数502に入力されたCiおよびRwの特定の組合せに対応する一意的なそれぞれの「二次」応答Ri上にマッピングするように構成されている関数である。二次チャレンジ応答ペアは、一次応答Rwに一部は基づき生成される、一次(ベース)CRペアの上に層化されるという意味で本明細書において「二次」と称され得る。これらは、また、「拡張層」または「補足」チャレンジおよび応答と呼ばれ得る。
実施形態において、変換関数502は、ハッシュ関数、たとえば、SHAまたはDSAハッシュ関数などの暗号学的ハッシュ関数を含む。ハッシュ関数を使用することができる少なくとも2つの異なる方法がある。第1に、変換関数502は、プリイメージのハッシュを含み、プリイメージは、受信された二次チャレンジCiと生成された一次応答との組合せ(たとえば連結)を含む。すなわち、Ri=H(Ci| |Rw)である。または、より一般的には、プリイメージは、同様に他の要素、および/または連結以外の別の形式の組合せを含み得る。
第2の代替的アプローチでは、変換関数502は、プリイメージのハッシュを含み、プリイメージは、受信された二次チャレンジを含み、ハッシュ関数は、生成された一次応答で初期化される。すなわち、Ri=H(Ci)であり、HはRwによって初期化される。または、ここでもまた、より一般的には、Hのプリイメージは、少なくともCiを含む限り、他の要素も含むことが可能である。Rwによって初期化されることは、ハッシュ関数Hによって定義されるアウトプットへのプリイメージのマッピングそれ自体がRwに依存することを意味する。
前の場合には、Hによって引き起こされるアウトプットへのプリイメージのマッピングは、Rwに依存せず、むしろ、プリイメージは、Rwに依存する。すなわち、前の段落ではプリイメージはRwに依存し、この段落ではHのみがRwに依存する。
より一般的にはそれでも、原理上、ePUF500によって収容されるドメイン内の各可能なCiについて、CiおよびRwの組合せをRiのそれぞれの値に決定論的に、また一意的にマッピングする限り、任意の関数が使用され得る。
二次チャレンジCiは、多数の異なる可能な値のうちのどれでも取ることができ、変換関数502は、それらの値を、特定の受信された二次チャレンジCiの値および一次応答Rwの値に基づき、二次応答Riのそれぞれの値にマッピングする。したがって、ePUF502は、所与の一次(ベース)CRペアのCR空間を複数の二次CRペアに拡張することができる。実施形態において、Ciは、使用される変数によってサポートされる値の範囲内の任意の値を取ることができる(たとえば、32ビット整数であれば、232値のいずれかを取ることができる)。
いくつかの実施形態において、ePUF500は、図5Bに示されているように、代替的動作モードで動作できるものとしてよい。この場合、インターフェースロジック404'は、インプットチャレンジデータが一次チャレンジーCwのみを含むことを検出する。これに応答して、Cwの受信された値をベースPUF302にルーティングし、結果として得られる一次応答Rwを提出者103Sのデバイスにルーティングする。言い換えると、この実施形態では、ePUF500は、「レガシー」または「非拡張」モードで動作することもできる。
任意選択で、アプリケーションに応じて、インターフェースロジック404'は、アクセス制御ロジック406を含むものとしてよく、これは限定された数の可能な提出者103Sのみへのアクセスを、認可された当事者にマッピングされていると認識する資格情報(たとえば、パスワード、PIN、または生体測定インプット)を提示できる当事者にのみアクセスを付与することなどによって、制限する。この場合、ePUF500は、CPUFの一形態と考えることも可能である。
代替的に、ePUF500を備えるデバイスを、当事者の限られた集合のみがアクセスを許可される部屋もしくは構内に保持するか、または鍵の掛かっている箱、キャビネット、または部屋内に保持することなどによって、ePUF500への物理的インターフェースは合法的にまたは物理的に保護され得る。この場合、ePUF500は、一種の拡張された弱いPUFのように考えることが可能である。
PUFへのインターフェースに対するそのような物理的制限の代替として、またはそれに加えて、アクセスは、一次チャレンジへのアクセスを制限することによって制限されてもよい。たとえば、ターゲット当事者103T(「アリス」、後述)は、Cwを知っている唯一の当事者であり得る。
しかしながら、別の代替的手段として、インターフェースロジック404'へのアクセスは、制限され得ない、たとえば、任意の当事者がインターネットを介して自由に問い合わせ得る。この場合、ePUF500は、弱いベースPUFメカニズムを拡張することによって作成された一種の強いPUF502のように考えることが可能である。
図5Aに示されている配置構成は、本明細書において拡張PUF(ePUF)と称されるPUFデバイスの新しいハイブリッドクラスを提供し、これは後で提示されるような、多くのアプリケーションのためのフレームワークとして一般的に使用され得る。
ePUFは、本質的に弱いPUFなどのベースPUF302、暗号学的ハッシュ関数などの変換関数502、およびインターフェースロジックモジュール404'の3つのモジュールを併せて含む、図5Aに示されているような、物理的デバイスまたはシステムとして定義され得る。説明されているように、ePUF500は、暗号学的ハッシュ関数などの変換関数404'を導入することによって、正規のPUF302に関して「拡張」され得るが、それは、一意的なチャレンジ空間ΦFのサイズを、ベースの弱いPUF302に対する|ΦF|～1から、弱いPUFの物理的システムではなくむしろハッシュ関数の選択によって代わりに制約される|ΦF|>>1まで増やすからである。
強いPUFの大きなCRP空間と弱いPUFの実用性とを組み合わせたシステムを実現する考え方は、それ自体、以前に調査されている。複数のFPGAベースの弱いPUFを組合せ動作で使用して、強いPUFの特徴を有するシステムを形成することが知られている。ここでの意図は、部分的に、ベースの弱いPUFのCRP空間を「拡張」することである。しかしながら、この性質を有する既存の構成は、実際には限られている。上述のFPGA設計の場合、システムは、FPGA上に構築されなければならず、依然として比較的低いCRP空間(～210)の影響を受ける。
本明細書で開示するePUF設計は、既存の弱いPUF302にインターフェースロジックコンポーネント404'と暗号学的ハッシュ関数(または他のそのような変換関数)502を追加するだけで済むという点で、極めて軽量であるように設計されている。たとえば、SRAM PUFが広く使用されている弱いPUF 302として選択される場合、2つの残りのモジュール404'、502の追加は、著しいオーバーヘッドを生じるべきでなく、たとえば、ソフトウェア(たとえば、ファームウェア)で小さなアルゴリズムとして、または比較的単純なハードウェア回路として実装される。さらに、ePUF500の可能なアウトプットの空間は、選択されたハッシュまたは変換関数502の範囲まで拡張され、これは、上記よりも相当に大きい。たとえば、SHA-256ハッシュ関数が選択された場合、可能なアウトプット(したがってCRP)の空間は、直ちに2256-1まで増大され、ハッシュ関数モジュールそれ自体を埋め込むことを超えてハードウェアオーバーヘッドをスケーリングする必要がない。
図5Aは、拡張PUF(ePUF)500のための概略設計を示している。暗号学的ハッシュ関数が使用される実施形態は、ePUF500が、そのCRPが予測不可能であるという特性を有することも意味し、これは、強いPUFシステムの場合も同様である。
ePUFデバイスの制御ロジック要素406も、この構成で一般化され得る。制御ロジック406は、たとえば、これがアプリケーションに適切である場合に、SRAM PUFに類似する、物理的セキュリティとして単純に実装され得る。
代替的に、制御ロジックモジュール406は、CPUFとともに使用されているものと似たソフトウェア制御モジュールとして実装されてもよく、これは、実際、PUFデバイスそれ自体の中に埋め込まれ、前に説明されたカプセル化の相互セキュリティ上の利点を提供する。
しかしながら、このePUF設計を特にCPUF設計と区別するここでの1つのポイントは、このように実装されるべき制御ロジックに対する厳密な要件がないことである。
制御モジュール406に対する侵襲的な攻撃が、ePUF設計における弱いPUFコンポーネント302の挙動を必ず変化させると必ずしも仮定される必要はない。その代わりに、この要素の実装形態は、ケースバイケースで選択され得る。
2.1. ePUFに対するチャレンジおよび応答
ePUFに対応するチャレンジ-応答ペアの集合(C,R)∈ΦFは、次のように定義され得る。
ΦF={(Cw,Rw),(C1,R1),(C2,R2),..., (CN,RN)},
F:Ci→Ri, ∀i∈(1,N)
Fw:Cw→Rw
ここで、(Cw,Rw)は、弱いPUF302のベースチャレンジ-応答に対応する特権付きCRPであり、マップFwは、弱いPUFの一意的な物理的特性によって定義される。ペア(Cw,Rw)は、本明細書において、ePUFのベースまたは一次ペアと称されることがある。マップFは、逆に、ePUFに対して選択された暗号学的ハッシュ関数によって定義される。図5A～図5Bは、(図5B)チャレンジがCwのみであり、(図5A)チャレンジがCiも含んでいるePUF500から応答を抽出することを示している。
拡張PUFのいくつかの実施形態において、すべてのチャレンジCi、i∈{1,2,...,N }には、ベースチャレンジCwが付随しなければならず、ベース応答Rwは、図5Aに示されているように、すべての他の応答Riを生成するためのプロセスに組み込まれる。
ePUFを使用して汎用CRPを生成するための図5Aに描かれているプロセスは、任意の他のチャレンジCiに適用することによってこのベースシークレットペアリングを拡張することによってベースチャレンジ-応答ペア(Cw,Rw)を使用するように設計されている。ePUFからCRPを生成するために使用されるアルゴリズムは、決定論的な方法でベースペア(Cw,Rw)を使用することを条件として、特定の用途に合わせて手直しされ得る。そのようなアルゴリズムの単純な例は、getResponse()と表され、次のように書くことができる。
getResponse()
インプット:Challenge
1. ユーザ/クライアントからchallengeを取得する。
2. challenge==Cwであるかチェックする
i. yesならば:
1. Cwで弱いPUFモジュールを探査しRwを取得する
2. Response←Rwをセットする
ii. noならば:
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)を単に計算することなど、多数の方法で実装され得るか、または値Rwがハッシュ関数Hの初期ベクトルとして使用されている面倒な計算
によって実装されることも可能である。いずれにせよ、hash()のアウトプットは、CiおよびRwの両方に依存する。
図5Aおよび図5Bの図は、ePUF500が、任意選択で制御ロジックモジュール406を含む、インターフェースロジック404'を備え得ることを示している。実施形態において、応答を生成する際に取るべき可能な経路が2つあり、図5Bの経路は、チャレンジが単純にCwであるときに使用され、図5Aの経路は、チャレンジが、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構成は各々の特性を組み合わせたものであるという事実は、いずれのアプリケーションにも等しく適切に取り扱われ得る。アプリケーション(1)では、利点は、最も強いまたは制御された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は、図5Aおよび図5Bに関してすでに説明されているようなePUF500を備えるか、または代替的に、図3および図4に関してすでに説明されているような従来のPUF302またはPUFプラス従来のインターフェースロジック404を備えるだけであってもよい。応答データストア601は、第三者コンピュータ機器602の一部であり、信頼できる第三者によって管理されることも可能であるか、またはその代わりにブロックチェーンなどの分散型ピアツーピア記憶媒体である可能性もある。第三者機器602は、たとえば、1つまたは複数の地理的サイトに配置された1つまたは複数のサーバユニットを含むサーバ機器を含み得る(クラウドストレージ技術は、それ自体、当技術分野で知られている)。システムは、検証者103Vのコンピュータ機器102Vをさらに含み得るか、またはいくつかの代替的ケースでは、検証者は、PUFモジュール603、ターゲット当事者のコンピュータ機器102T、または第三者コンピュータ機器602と直接的にやり取りしてもよい。
本明細書における、ユーザまたは当事者103の活動もしくは同様のものに関する言及は、検証者103V、ターゲット当事者103T、または第三者かどうかに関係なく、当事者がその当事者のコンピュータ機器102を通して活動している可能性を含む。簡潔にするため、これは、必ずしも毎回明示的に述べる必要はないが、暗黙のうちに含まれていると理解される。これは、A)活動が、当事者によるコンピュータ機器への手動ユーザインプットによってトリガされるか、もしくはその制御下で実行されるか、またはB)活動が、当事者に代わってコンピュータ機器によって自動的に実行される(当事者が活動を実行すると言うことは、必ずしもその当事者の人間ユーザがその活動を手動で引き起こすことを意味しないが、当事者の機器がその当事者に代わって自律的に活動を実行することを意味する)の両方の可能性を対象とする。疑念を避けるために、当事者は、単一の個人またはグループまたは人々または組織、たとえば企業、慈善団体、政府機関、または自治体もしくは学術機関を指し得ることにも留意されたい。
ターゲット当事者103Tのコンピュータ機器102Tは、応答データストア601に動作可能に接続され得る(たとえば、第三者機器602への接続によって)。検証者103Vのコンピュータ機器102Vは、応答データストア601に動作可能に接続され得る(たとえば、第三者機器602への接続によって)。ターゲット当事者103Tのコンピュータ機器102Tは、検証当事者103Vのコンピュータ機器102Vに動作可能に接続され得る。これらの接続のいずれかは、1つまたは複数のネットワーク、たとえばインターネットまたはモバイルセルラーネットワークなどの1つまたは複数のワイドエリアネットワークを介して形成されてもよい。実施形態では、これらの接続のいずれかは、それぞれの安全なチャネルを介して形成される、たとえば、注目している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上で実装され得、PUF302は外部周辺機器となり得る)。代替的に、PUFモジュール603は、信頼できる第三者を十分に把握しているものとしてよい。これは、たとえば周辺機器として、もしくはローカルネットワーク、もしくは組合せを介して第三者コンピュータ機器602に接続されるか、または組み込まれ得る(たとえば、インターフェースロジック404/404'は第三者コンピュータ機器602上で実装され得、PUF302は外部周辺機器となり得る)。
一般に、ターゲット当事者103T、検証者103V、または第三者のいずれかが、図3、図4、および図5に関してすでに説明されている提出者の役割を担うものとしてよい。ターゲット当事者103T、検証者103V、または第三者のいずれかが、提出者の役割を担うか、またはPUFモジュール603を使用して設定者の役割を担い、1つまたは複数のCRペアのセットを確立し、後の検証フェーズで使用するためにそれらをターゲット当事者103Tのアイデンティティにリンクし得る。いくつかの特定の例示的なシナリオが、後でより詳細に説明される。
応答データストア601は、PUFモジュールによって生成された応答データを設定フェーズで記憶する。データストア601は、この応答データを、ターゲット当事者103Tまたはターゲット当事者103Tのデバイスであり得る、ターゲットのアイデンティティの証拠に関連して記憶する。検証者103Vは、応答データストア601へのアクセス権を有し、これを使用して、検証フェーズにおいて後からターゲットのアイデンティティを検証することができる。これを行うために、検証者103Vは、セットアップフェーズで使用されたチャレンジのセットに以前に含まれていたチャレンジCiに対する応答Riを生成するようにターゲットにチャレンジを行う。ターゲットが、応答データストア601に記憶されている内容に従って期待される応答を生成できる場合、これは、ターゲットがPUFモジュール603を所持しているかまたは制御していることの証拠となり、したがって、セットアップフェーズでアイデンティティが捕捉された同じ当事者であると仮定され得る。
一代替的変更形態において、応答データストア601は、セットアップフェーズで生成された応答に基づき、たとえば応答をシードとして使用して、生成された、1つまたは複数のそれぞれの公開鍵-秘密鍵ペアの1つまたは複数の公開鍵を記憶し得る。ターゲットが後で秘密鍵の1つを使用してメッセージ(たとえば、文書またはブロックチェーントランザクション)に署名する場合、検証者は、応答データストア601からの対応する公開鍵を使用して署名を検証することができる。そのような変更形態において、「応答データ」という用語は、必ずしも応答Riの明示的な値または証明ではない、応答Riから導出されるデータを扱うためにより広い意味で使用されていることに留意されたい。
応答データストア601は、公的にアクセス可能であり得るか、またはアクセスは、少なくとも1つの検証者103Vを含む1人または複数の当事者の限られたセットにのみ制限され得る。それは、第三者システム602上で、もしくはピアツーピア方式でホストされ得るか、または代替的に、ターゲット当事者103Tのコンピュータ機器102Tもしくは検証者103Vのコンピュータ機器102Vにおいて実装され得る。
図7を参照すると、この方法は、セットアップフェーズ702および検証フェーズ704の2つのフェーズを備える。セットアップフェーズでは、ステップ710において、セットアップ当事者として活動するターゲット当事者103Tまたは第三者のうちの一方が、1つまたは複数のチャレンジCi(i=1,...,n、ここでn>=1)のセットをPUFモジュール603に提出する。これらは、ePUF500が使用される場合における二次チャレンジである。ターゲット当事者103TがPUFモジュール603を保有し、セットアップを実行している場合、チャレンジCiは、ターゲット当事者103Tによって生成されるか、または第三者システム602もしくは検証者103Vから受信される可能性がある。第三者がPUFモジュール603を保有し、セットアップを実行している場合、チャレンジは、第三者システム602によって生成されるか、またはターゲット当事者103Tもしくは検証者103Vから受信される可能性がある。いずれにせよ、応答において、PUFモジュール603は、PUF302/500に基づき応答Riの対応するセットを生成する。これらは、ePUF500の場合に二次応答である。したがって、この方法は、CRペア{Ci,Ri}のセットを生成する。
実施形態では、PUFモジュール903へのアクセスは、ターゲット当事者103T(および異なる当事者であれば設定当事者)だけが応答Riへのアクセス権を取得することができるように制限される。これは、パスワード、PIN、生体測定データなどの認識済み資格情報を提示することができる当事者にのみアクセス権を付与し得るアクセス制御ロジック404または404'によって達成されることが可能である。および/または、PUFモジュール603との物理的インターフェースへのアクセスは、鍵を掛けられた容器、キャビネット、または部屋に保管することなどによって物理的に保護され得るか、または特定の人員のみがアクセスを許される部屋もしくは複合施設にPUFモジュール603を保管することなどにより法律的に保護され得る。別の代替的または追加の制限として、ePUF501の場合に、一次チャレンジCwの知識が制限されてよく、それにより、ターゲット当事者103T(および実施形態では、別個のセットアップ当事者として活動する信頼できる第三者)のみがCwを知る。
ステップ720において、方法は、応答データを応答データストア601に記憶することを含む。実施形態では、記憶された応答データは、生成されたCRペア{Ci,Ri}の記録を含む。各CRペアの記録は、ペアの対応するチャレンジCiを指示する方式で記憶されたそれぞれの応答Riの記録を含む。実施形態において、各応答Riの記憶されている記録は、記録を読むことができる検証者103Vに明示的に開示された、応答の明示的な値、すなわち、Riの実際の値を含む。値は、平文で記憶されるか、または検証者が値を復号するための復号鍵を有する場合に暗号化されることが可能であるが、それにもかかわらず、記憶された値は、それでも、検証者103Vに対して明示的に開示されるという意味で本明細書の目的に関して明示的値であると依然として言われる。代替的に、応答の記録は、Riの決定論的変換を含む、応答Riの「証明」を含むことも可能である。一例は、ハッシュH(Ri)またはダブルハッシュH2(Ri)の値を記憶することであろう。これは、検証者がR'iに適用される同じ変換(たとえば、H(R'i)またはH2(R'i))が証明と一致するかどうかをチェックすることによって応答R'iの値がストアに記録されているものと同じかどうかをチェックすることを可能にする。これは、応答Riの実際の値が開示されないという利点を有する。したがって、この方法のこの変更形態は、ストア601がブロックチェーンなどの公開媒体である場合に特に有用であり得る。しかしながら、暗号化も別の可能性であろう。
応答データが暗号化済み形式で記憶される場合、各応答データ(たとえば、各CRペア)は、個別に暗号化され得、各々復号するために異なるそれぞれの復号鍵を必要とする。代替的に、応答データのサブセットまたはセット全体(たとえば、所与のターゲット当事者103Tに対するすべてのCRペア)は一緒に暗号化され、すべては同じ鍵でグループとして一緒に復号可能であり得る。
応答データ、たとえばCRペアは、ターゲットのアイデンティティの証拠と関連して応答データストア601に記憶される。たとえば、ターゲット当事者103Tは、セットアップの一部として、パスポートなどの、1つまたは複数の識別情報を生成することを必要とし得る。応答データと関連して応答データストア601に保持される証拠は、応答データに関連して明示的に記憶される(平文または検証者103にとってアクセス可能な暗号化済み形式で)この情報それ自体のコピーを含むことが可能である。代替的に、応答データストア601が信頼できる第三者または検証者103Vそれ自身によって管理される場合に、応答データが特定のアイデンティティに関連して応答データストア601に登録されているという単なる事実は、十分な証拠とみなされ得る(仮定は、検証者103Vがセットアップ当事者および応答データストア601を管理する当事者、たとえば信頼できる第三者が、セットアップ時にターゲット当事者の識別情報を適切にチェックしたことを信頼するという仮定である)。
検証フェーズ704では、ステップ730において、検証者103Vは、応答データストアにアクセスし、検証操作で使用する応答データを決定する。実施形態において、複数の潜在的検証者103Vが存在し、各々CRペアの1つまたは複数の異なるそれぞれのサブセットを割り当てられる。すなわち、応答データストア601は、所与の検証者103Vに対して、その当事者に割り当てられたCRペアの期待される応答Riのみを開示する。たとえば、このスキームは、信頼できる第三者システム602によって管理され得る。そのようなスキームは、有利には、一方の検証者103Vが他方の当事者に対してターゲットであるふりをすることができないように、CRペアを分離して保持する。しかしながら、ストア601へのアクセスを付与されたすべての検証者103Vが信頼できる当事者である場合、これは不可欠ではない。
実施形態において、検証者103Vは、自分が使用しようとしているチャレンジを最初は知らず、対応する応答データ(たとえば、応答または証明)とともにデータストア601からアクセスすることによってこれを決定する。代替的に、検証者103Vは、自分が使用することを意図しているチャレンジを予め知っており、これを使用して、データストア601においてどの応答データがこれにマッピングされるかを調べる。
検証者103V(または実際には任意の当事者)が、応答データおよび/またはチャレンジを決定することなどのために、ブロックチェーンからデータにアクセスするシナリオにおいて、ブロックチェーンにアクセスすることは、ブロックチェーンネットワークのノードに直接的に問い合わせるか、または間接的に、ブロックチェーンデータをキャッシュするもしくはブロックチェーンデータへのアクセスを求める当事者に代わって問い合わせを仲介する中間サービスに問い合わせるかのいずれかによって実行され得る。たとえば、検証者103Vは、ブロックチェーンネットワーク106に直接的に接続されていない別のサービスプロバイダからデータにアクセスすることも可能であるが、応答関係データ、およびおそらくマークル証明も、与えるだけであるかもしれない。
ステップ740において、検証者103Vは、PUFモジュール603を所持しているかまたは管理しているターゲット当事者103TにチャレンジCiを提出する。これは、検証者103Vがステップ730において応答データストア601からアクセスした記録のうちの1つに対応するチャレンジである。セットアップ時に信頼できる第三者がPUFモジュール603を所持していたシナリオでは、PUFモジュール603は、セットアップフェーズ702と検証フェーズ704との間に信頼できる第三者からターゲット当事者103Tに物理的に渡され得る。
提出されたチャレンジCiに応答して、PUFモジュール603は、対応する応答Riを生成し、ターゲット当事者103Vは、検証者にそれを返す。ステップ750において、検証者は、受信された応答Riが、ステップ730で応答データストア601からアクセスされた応答データに従って期待される応答と一致するかどうかをチェックする。
前述のように、セットアップステップ702を実行する当事者は、ターゲット当事者103Tまたは応答データ(たとえばCRペア)を記憶する信頼できる第三者である可能性もある。さらなる変更形態において、これらのステップは、信頼できるOracleなどの別の調整者(実施形態では、データストア610を備える第三者コンピュータ機器602を実行する、当事者以外の別の第三者)によって実行されることが可能である。そのような実施形態において、データストア601は、(異なる第三者の)第三者システム602、またはブロックチェーンなどの公開ピアツーピア媒体とすることが可能である。および/または、なおもさらなる変更形態において、PUFモジュール603へのインプットを実行する当事者と、アウトプットを受け取る当事者との間の分離が提供されることも可能である。
また、前述のように、応答Riが応答データストア601に記録される方式に対して少なくとも2つの可能性がある。これの第1は、単純に、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と関連付けられていると指示される方式に対して少なくとも2つの可能性がある。第1は、単純に、各CRペア{Ci,Ri}の明示的な値を記憶すること、すなわちRiおよびCiの実際の値を(平文でまたは暗号化してのいずれかで)記憶することである。代替的に、本明細書において開示されている実施形態による、第2の、より軽量の方法は、チャレンジCiが所定の決定論的チャレンジ導出関数fに従って導出され得るマスターチャレンジCmを記憶することである。
これは、図8Aに例示されている。各応答Riは、それぞれのインデックスに関連して記憶される。関数fは、応答データストア601に記憶されているか、または検証者103Vに予め知られているかのいずれかである。いずれにせよ、検証者103Vは、マスターチャレンジCmを関数fに入力して、応答Riの少なくとも1つのインデックスiに対応するチャレンジCiを決定する。次いで、検証者103Vは、このチャレンジCiを使用してターゲットを検証する。
いくつかのそのような実施形態において、関数fは、また、識別情報806の関数であってもよく、これは、単一の識別情報または複数の識別情報802(たとえば、パスポート情報、母親の旧姓および指紋情報)の組合せ804(たとえば、連結)であってもよい。これは、ターゲット当事者103Tの識別情報を含み得る。これは、特定のターゲット当事者103Tに特有のチャレンジCiのセットを使用可能にし、これは、たとえば、同じ第三者システム602が異なるターゲット当事者に対するチャレンジセットを生成するために使用される場合に、一意性が重要となる場合があるので、セキュリティ上の理由から有利である。ターゲット当事者103Tのパスポート情報または母親の旧姓などの個人識別情報を使用することは、それがターゲット当事者がすでに知っており、有しており、秘密にする傾向がある何かなので、良い選択肢である。
代替的に、またはそれに加えて、識別情報806は、検証者103Vの識別情報を含むものとしてよく、それによりfは特定の検証者103Vのアイデンティティの関数である。これは、1つまたは複数の特定のチャレンジの特定のサブセットを特定の検証者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以外の別のところから、たとえばOracleまたは調整者(図示せず)から受信し得る。そのようなアプローチの組合せが使用されることも可能である(たとえば、一方の識別情報がターゲット当事者から受信され、もう一方は別のところから取得される)。または、さらなる代替的形態において、第三者は関与せず、ターゲット当事者103Tは、マスターチャレンジをチェーン上に自分自身で(または他の何らかのピアツーピア公開媒体で)記憶する。
図7の方法のさらなる変更形態において、応答データストア601に記憶されている応答データは、セットアップにおいて生成されたCRペアの記録を含み得ない。その代わりに、応答データは、公開鍵-秘密鍵ペアの公開鍵、またはそのような公開鍵のセットを含んでよく、1つまたは複数の鍵ペアの各々は、セットアップフェーズ702からのそれぞれのPUF応答Riに基づき生成された。たとえば、応答Riは、公開鍵秘密鍵ペア生成アルゴリズムにおけるシードとして使用されてもよい。そのような実施形態において、方法は図7に述べられているように進行するが、ただしステップ730で検証者が記憶されている公開鍵の1つにアクセスし、ステップ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デバイス(PUFモジュール603を含むデバイス、たとえばアリスのコンピュータ機器102T)の動作に本質的にリンクされている。これらの場合に、われわれは物理的状態がアイデンティティに一意的にバインドされているというPUFデバイスの特性を使用しており、したがって、PUFは、利用されているアイデンティティシステムにおいて中心的役割を果たす。
「リモート」および「ローカル」という用語は、チャレンジを行うときの検証者と証明者のPUFとの間の相互のやり取りを特に指していることに留意されたい。これは、リモートチャレンジプロトコルが前もって証明者と検証者との間のローカルな相互のやり取りを伴うセットアップフェーズを有することを排除するものではない。
しかしながら、ケース3では、チャレンジおよび検証プロセスは、証明者の観点からPUFデバイスに関係しているだけでよい。検証は、チャレンジに対する応答を生成する際にPUFが証明者によって使用されているかどうかを検証者が知ることに依存しない。この場合、この方法は、アイデンティティをデバイスそれ自体にリンクする際の有用性のためではなくむしろ、アリスに対する鍵生成器としてPUFの有用性を単純に使用している。
次に、例示的な実装形態が、上述の3つの動作モードの各々におけるアイデンティティシステムに対するセットアップおよび検証、ならびに任意選択の更新、ならびに失効プロセスについて提供される。実施形態において、一般的な信頼できる第三者が、PUFベースのアイデンティティシステムに関係するプロセスに関与している。これは、そのようなアイデンティティシステムが、アイデンティティおよび関係する資格証明の完全性および信頼性を意味のある形で保証するために、そのような第三者を必要とする傾向があるからである。個人のアイデンティティがそのようなシステムにおいて確立され使用されるべきである場合、注目している信頼できる第三者は、認証局、政府機関、または銀行などの金融サービスプロバイダであってよい。
アイデンティティが、機械または非人間エンティティに対して確立されるべきである場合、第三者は、デバイス製造業者、発行者、規制当局、またはその他の関連する主体であってよい。このケースは、モノのインターネット(IoT)またはさらにはモノのブロックチェーン(BoT)パラダイムに特に適しており、アイデンティティは、何らかの目標を達成するためにタスクまたは計算を協調して実行し得るデバイスのネットワークの異なるメンバーに割り当てられるべきである。
3.1. リモートPUFシステム
3.1.1. セットアップ:リモートPUFチャレンジの場合、チャレンジCを証明者に提出する検証者は、期待される応答Rを前もって知っていると仮定する。これは、この場合のセットアッププロセスは、後でアリスのアイデンティティを認証するために使用できる当事者の間の共有秘密を導出するために使用され得るアリスと別の当事者との間のCRPのセット(すなわち、少なくとも1つ)を確立しなければならないことを意味する。
アリスは、前述のように、アイデンティティを確立するために備えられる一般的な第三者とのこの共有秘密を確立し、この第三者は、後でアリスと検証プロセスに参加する検証者であってもなくてもよい、と仮定する。検証者がアイデンティティ確立第三者とは異なる場合、検証者は第三者から共有秘密に使用される関連するCRP情報を取得し得ると仮定する。
ここでセットアップフェーズに対して、アリスがいつでもPUFデバイスにアクセスできる唯一の当事者であるかどうか、または信頼できる第三者がセットアップフェーズにおいてのみPUFデバイスへのアクセス権も有していてもよいかどうかによって分類される、2つの異なる選択肢がある。
ケース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から導出された秘密である。
4. 第三者は、ePUFデバイスをアリスに送る。
(*デバイスは、最初にアリスに配布され、次いでアリスによって送られてもよい。しかしながら、ほとんどの場合において、デバイスが第三者に直接配布される方がより道理にかなっている。たとえば、デバイスがスマートデビットカードである場合、カードは製造業者から発行銀行に送られ、次いで発行銀行から顧客であるアリスにPUFセットアップに従って送られ得る。)
セットアッププロトコルは、検証プロセスにおいて後でアリスのアイデンティティ(またはPUFを含むデバイス)を認証するために使用されるべきアリスと信頼できる第三者との間の共有秘密を確立する。また、これらのケースは、両方とも好ましくはアリスと信頼できる第三者との間の安全な通信を伴うという点で類似している。
しかしながら、2つのケースの間の違いは、ケース1が安全な通信チャネルを確立することによって安全な通信を達成するのに対して、ケース2は物理的セキュリティを用いてそれを達成する点である。
それぞれケース1およびケース2における2つのプロトコルの間の注目すべきもう1つの違いは、ケース2では、信頼できる第三者がアリスと同じ数のCRPをPUFなしで導出できるが、ケース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. yesであれば、検証は合格である。
ii. noであれば、検証は不合格である。
5. ペア(C1,R1)は、その後、信頼できる第三者によって取り除かれ、残りのチャレンジ-応答ペアのセット{(C2,R2),(C3,R3),...,(Cn,Rn)}を残す。
ステップ1.ii.では、CRPの一回使用という性質が、任意のボブが特定のCRPを使用してアリスに「なりすます」ことは可能でないことを確実にするが、それは、信頼できる第三者が各所与の状況において各ペアの使用を単純に監視することができ、またすべての認証の試行に対して新鮮なCRPを使用すべきであるからであることに留意されたい。
ケース2:第三者がセットアップ時にPUFにアクセスした。
1. ボブは検証のために新鮮なチャレンジCを生成する。これはランダムに、または他の何らかのデータ(たとえば、知られているKYCデータ、バイオメトリクス、画像など)から決定論的に行われ得る。
2. ボブはチャレンジCをアリスに送信する。
3. アリスは自分のePUFデバイスから候補応答R'を取得し、ボブに送信する。
4. ボブは期待される応答Rを取得する。
i. ボブが信頼できる第三者である場合、ボブはR=hash(C,Rw,H)*を計算することによって応答を直接的に計算することができる。
ii. ボブが信頼できる第三者でない場合、ボブはCを第三者に送信し、応答Rを要求する。
5. ボブはR'==Rであるかどうかを検証する。
i. yesであれば、検証は合格である。
ii. noであれば、検証は不合格である。
(*これは、セットアッププロトコル(ケース2)で第三者がベースペア(CW,RW)を取得したからであり、これはRWが彼らに知られていることを意味する。また、ハッシュ関数Hは、全員でなくとも少なくとも第三者に知られている、すなわちSHA-256などの公的標準であることが仮定される)。
3.1.3. 更新:検証(およびログインなどの他の有用なプロトコル)における1回限りの使用という性質が与えられた場合に新鮮な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を活用することが望まれている場合に、アリスの要求が、HMACまたは各ケースにおいてCRP応答または秘密を鍵として使用する暗号化済みメッセージなどを用いるなどしてアリスおよび第三者が確立したCRP(またはその導出された共有秘密)の1つを使用して認証されることが規定され得る。しかしながら、上述の理由から、これは決してシステムの厳密な要件とはみなされない。
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. yesであれば、検証は合格である。
ii. noであれば、検証は不合格である。
これらのシナリオでは、ボブは前もって候補応答R'を知っているのではなく、むしろPUFデバイスから今受信した応答が、以前に生成された応答と一致することを検証している。たとえば、これは、応答を生成した人物(アリス)または優勢なデバイスが、今いる(たとえば、法廷内にいる)同一人物またはデバイスであることを検証するために(たとえば、法廷内で)使用され得る。たとえば、デジタルコンポーネントの例では、これは何らかの入力されたチャレンジCに基づきRを生成した後に命令を発行するように構成されているであろう。たとえば、デバイスが自動運転車であり、コンポーネントが「前の車が近すぎる」というデータから導出された、またはデータを含むチャレンジを受信した場合、応答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応答Rから導出されることを意味する。
3.3.2 検証:暗号化ケースでは、アイデンティティ検証は、前に詳述された暗号化セットアップフェーズにおいて確立された暗号化情報を使用して実行される。この場合、われわれは、セットアップ時にアリスのアイデンティティに対して認証済みEC非対称鍵ペアが確立され、その鍵を使用して検証することを例に取り上げる。
しかしながら、以下のプロトコルは、適切な場合に、他の暗号化スキームにも、既存のセットアップおよび検証のプロトコルをそれらのスキームで置き換えるだけで簡単に適合されることが可能である。ここでの違いは、セットアッププロセスおよび検証プロセスに対してePUFデバイスを安全な鍵生成器として使用することであり、これは保有者であるアリスに悪意ある危険を及ぼすリスクを低減する。
1. ボブは、アイデンティティリンク情報PA、たとえば、認証済み鍵を取得する。
i. ボブが信頼できる第三者である場合、ボブは単純にアリスのアカウントからPAを取り出す。
ii. ボブが信頼できる第三者でない場合、ボブは第三者と通信して、アリスに対する認証済み公開鍵を要求する。
2. ボブはアリスが署名するメッセージmを選択し、アリスに送信する。
3. アリスはメッセージmにわたる署名を生成する。
i. アリスが自分の認証済み鍵で署名することを望んでいる場合、署名Sig(PA,m)を生成する。
ii. アリスが1回使用導出済み鍵で署名することを望んでいる場合、アリスは署名Sig(Pα,m)を生成し、Pα=PA+H(d)・Gおよびdは何らかの1回使用データ*である。
4. アリスは署名をボブに送信する。この時点で、アリスは、また、データ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デバイスを使用してアイデンティティを確立する独立したケースでは、エンティティが、任意の第三者から独立した人間のアイデンティティ、または閉じたシステム内のデバイスアイデンティティのいずれかを確立することを望むシナリオを考察する。このプロセスに関与する唯一の当事者は、ePUFデバイスの「所有者」であり、後の検証で最終的に証明者となる、アリスである。
ケース1:アリスは、人間のアイデンティティを確立する。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分自身に対するアイデンティティを確立する。
i. アリスは、暗号化セットアップを使用して、非認証アイデンティティ鍵PAを確立し得る。
ii. アリスは、自分のアイデンティティに対して自分のアイデンティティ鍵を公開する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
アリスが自分自身のために「自己主権型」アイデンティティを確立するこのケースは、アリスだけが制御するデバイスに対して一意的で再現可能なデバイス識別子を提供する点である程度有用である。しかしながら、そのようなアイデンティティシステムに信頼できる第三者がいないことは、検証者が証明者のアイデンティティと証明者のデバイスとの間のリンクを後で信頼しなければならないことを意味する。これは、現実世界では非常に限られたアプリケーションを有し得る。
ケース2:アリスはデバイスに対するアイデンティティを確立した。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分のシステム内のデバイスに対するアイデンティティを確立する。
i. アリスは、ペア(C、R)を自分のデバイスにマッピングする。
ii. アリスは、すべての自分のデバイスおよびCRPマッピングのデータベースを保持する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
上記のケースでは、われわれはデバイスに対する「自己主権型」アイデンティティを作成する場合に、設計は閉じたシステム内で非常に有用であり、管理者はシステム内の異なるデバイスを単純に識別することに注意を向けることは分かるであろう。これは、後々の他の人への証明にも役立ち得る。しかしながら、セットアップ時に信頼できる第三者がいないことは、なおも、シナリオによっては、デバイスが変更されていないことを外部検証者に納得させる上で、証明者を制限する。
ケース1およびケース2は、同じプロセスであるが、異なる意図された目的を有する考えられ得ることに留意されたい。したがって、ケース1およびケース2は、人間または機械に対する「自己主権型」アイデンティティを生成するための方法として一緒にみなされるものとしてよく、後者のケースでは、システム管理者(IoTシステムにおけるアリスなど)はそれ自身信頼できるエンティティである。両方のケースにおいて、アリスは信頼されるエンティティである。
3.4.2 検証:この場合の検証プロセスは、所与のチャレンジでePUFデバイスを探査し、その応答を検査するのと同じくらい単純である。外部当事者に対するより複雑な証明または証拠が、アイデンティティを証明するために、この上にさらに構築される必要があり得る。
3.4.3 更新:この場合の更新プロセスは、単純にセットアッププロセスの繰り返しであり、管理者(この場合はアリス)は前方での使用のために追加のCRPを列挙する。
3.4.4. 失効:このシナリオでは、アイデンティティの失効の唯一のタイプは、管理者(アリス)が独立してアイデンティティを取り消すことを望む場合であるが、それはこのプロセスに関与する第三者がいないからである。これは、失効が、ePUFデバイスのアリスの使用中止およびCRPのデータベースのパージと同じくらい単純であり得ることを意味する。
後の節で、この自己主権失効がブロックチェーンの証明および証拠提示によってよりロバストにされ得る方法が開示されており、それにより、後で外部の当事者を納得させ得る。
3.5. アイデンティティベースのCRP管理
上記の、特にリモートPUFベースのアイデンティティシステムでは、セットアップおよび検証プロトコルでアイデンティティを認証するために使用されるCRPの1回使用の性質は、関与する当事者に対してCRP管理チャレンジを提示する。
たとえば、信頼できる第三者がセットアップ時にPUFデバイスにアクセスしない場合、将来の検証のために第三者に対して多くのCRP{(C1, R1),(C2, R2), ..., (Cn, Rn)}が列挙されることが望ましい場合がある。さらに、ePUFそれ自体が応答へのチャレンジの決定論的擬似ランダムマッピングとして機能するので、応答は相互に無関係であるように見える。したがって、信頼できる第三者がそのユーザまたはクライアントのためにCRPのセットを表にし、記憶する負担は、それらが多数のユーザにサービスを提供しなければならない場合にたちまちスケーリング問題をもたらす。
図8Aは、本明細書において開示されている実施形態による識別データからのチャレンジの決定論的導出を例示している。
そのような実施形態によれば、信頼できる第三者への負担の問題に対処するために、CRP管理は、チャレンジC1、C2、...,Cnの生成において主に扱われる。ここでの考え方は、チャレンジは、単一のマスターチャレンジ、またはマスターチャレンジが導出されるマスターデータから決定論的に(および場合によっては階層的にも)導出されるべきであるというものである。この概念は、1回使用のビットコイン鍵を管理するための階層的決定論的(HD)ウォレットの使用に、信頼できる第三者(または別の関連する当事者)がビットコインのシナリオにおいて「ウォレットシード」と呼ばれるマスターデータのみを使用してすべての関連するチャレンジを回復することを可能にするように設計されているという点で類似している。
いくつかのそのような実施形態において、アリス(ターゲット当事者103T)の識別データ806は、前の節で提案されたものなどのアイデンティティシステムでどのCRPが使用されるかを決定するための広範囲にわたるチャレンジを生成するマスターデータとして使用される。識別データそれ自体は、異なるデータ要素802の組合せ804を含み得るが、組合せにおいて、それらは好ましくは次の特性を有する。
・ 一意性-識別データは、それが関係するエンティティに対して一意的である。
・ 秘密性-識別データは、それが関係するエンティティ(またはその所有者)のみに知られている。
識別データの構成要素の単純な例は、パスポート番号、国民保険番号、氏名、生年月日、または秘密の質問に対する回答(たとえば、母親の旧姓)、またはデバイス識別の場合にはシリアル番号および製造情報を含み得る。しかしながら、一意性を保存するためにファジーマジック技術を使用して抽出され得る、指紋または顔認識データなどの、より高度な技術的手段によって取得されるデータも使用され得ると認識されている。
実施形態において、チャレンジのセットが導出されるマスターインプットとして使用される「識別データ」は、上記の多様性を含み得る。これに対する理由の1つは、前の節のプロトコルのいくつかが第三者および/または外部検証者とチャレンジを共有することに依存しているとした場合にできるだけ多くの信頼できる第三者に関する秘密を情報が保持することを確実にすることである。複数のコンポーネントを含む識別データは、証明者アリスの同意なしに任意の第三者が完全に複製することは困難であろう。
識別データを使用して決定論的にCRPを生成するためのメカニズムが図8Aに示されている。識別データの構成部分は、第1に、プロセス「A」(804)によって組み合わされ、これは、連結、ビット演算(たとえば、XOR)または任意の他の関連する組合せ演算であってもよく、この演算は、生データを難読形式に変換することによってプライバシーを保持することを求めるものとしてよいことに留意されたい。
次いで、識別データは、ハッシュ関数または類似のプロセスを用いて、マスターチャレンジCmに変換される。最後に、マスターチャレンジは、導出関数f()を使用して、1回使用チャレンジC1、C2、...、Cnのシーケンスを決定論的に導出するために使用される。実施形態において、図8Bに示されているように、導出関数f()は、ハッシュ関数およびノンスの注入を含むものとしてよく、それにより各連続チャレンジは、Ci=SHA256(Ci-1,i)として生成され、iはノンスとして働く。
プロセスA、識別データからのチャレンジCmの生成、および導出関数f()はすべて、特定の実装形態の必要性に応じて構成され得る。
図8Cは、別の特定の例、すなわち、チャレンジの階層的で決定論的な導出を示す(応答は描かれていない)。図8Bに示されているように、階層的方式でマスターCmから1回使用のチャレンジCiを導出することが望ましい場合がある。この場合、CRP管理は、特定のチャレンジの生成が、前のケースのように、前のチャレンジのすべてに依存する必要がないという事実によってさらに改善される。
アイデンティティデータに基づくチャレンジの決定論的導出の使用は、アイデンティティプロトコルにおける証明者アリスおよび信頼できる第三者の両方に対するストレージオーバーヘッドを低減する。いずれの当事者も、識別データ(またはそのサブセット)のみを記憶し、必要なチャレンジを、必要に応じて必要なときに、再計算することが可能である。
さらに、アリスは、各識別サービスと望むだけ多くの情報を保留するか、または共有することを選択することによって自分のプライバシーを手直しするオプションも有するが、より多くのデータを自分で保存し得るトレードオフもある。
4. 例示的なブロックチェーンシステム
次に、本開示のいくつかの実施形態において採用され得る例示的なブロックチェーンシステムを説明する。「アリス」および「ボブ」は、2つの当事者に対する任意の名前にすぎず、アリスおよびボブは、この節では前の節または次の節と必ずしも同じ役割を有するわけではない。
いくつかの実施形態において、PUFのアウトプットに基づく応答データは、たとえば前の節で説明されているように、チェーン上に記憶され得る。チェーン上に記憶された応答データは、実際の応答それ自体、またはハッシュもしくはダブルハッシュ(いわゆる証明もしくはハッシュコミット)などの応答の変換、またはPUF応答から導出された公開鍵-秘密鍵ペアの公開鍵の形態をとり得る。オンチェーン応答データがどのような形態をとるにせよ、それは、別の検証者が、アイデンティティの証拠として提示されるターゲット応答または署名が期待通りであるかどうかをチェックすることを可能にする何かである。さらなる実施形態において、ブロックチェーンは、チャレンジ-応答ペアを、更新するかまたは取り消すなど、管理する手段として使用され得る。
次に、そのような特徴を実装するために使用され得るブロックチェーンシステムの一例を説明する。
4.1. 例示的システム概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、典型的にはインターネットなどのワイドエリアインターネットワークを備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)ネットワーク106を形成するように配置構成され得る複数のブロックチェーンノード104を含む。例示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフとして配置構成され得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104と高度に接続されている。
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは異なるピアに属す。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば1つまたは複数の中央演算処理装置(CPU)、アクセラレータプロセッサ、特定用途プロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途集積回路(ASIC)などの他の機器を含む処理装置を含む。各ノードは、また、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読記憶装置を含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光学媒体を採用する1つまたは複数のメモリユニットを含み得る。
ブロックチェーン150は、データのブロック151を含み、ブロックチェーン150のそれぞれのコピーは、分散型またはブロックチェーンネットワーク106内の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味しない。その代わりに、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(後述)を記憶する限りブロックチェーン150はデータを剪定され得る。チェーン内の各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈でのトランザクションは、一種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して1つの特定のトランザクションプロトコルを使用する。トランザクションプロトコルの1つの共通のタイプにおいて、各トランザクション152のデータ構造は、少なくとも1つのインプットと少なくとも1つのアウトプットとを含む。各アウトプットは、財産としてのデジタル資産の数量を表す額を指定し、その一例は、アウトプットが暗号学的にロックされている(ロックを解除し、それによって償還または支出されるためにそのユーザの署名または他の解を必要とする)ユーザ103である。各インプットは、先行するトランザクション152のアウトプットを指し示し、それによってトランザクションをリンクする。
各ブロック151は、また、ブロック151に順序を定義するように、チェーン内の以前に作成されたブロック151を指すブロックポインタ155を含んでいる。各トランザクション152(コインベーストランザクション以外の)は、トランザクションのシーケンスに順序を定義するように、前のトランザクションを指すポインタを含む(注:トランザクションのシーケンス152は分岐することが許されている)。ブロック151のチェーンは、チェーン内の最初のブロックであったジェネシスブロック(Gb)153にまで遡る。チェーン150内の初期の1つまたは複数の元のトランザクション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が順序から外れて作成されるか、または送信されることを必ずしも排除しない(オーファントランザクションに関する以下の説明を参照)。先行するトランザクション152iは、等しく前のトランザクションまたは先行トランザクションと呼ばれることも可能である。
本トランザクション152jのインプットは、また、インプット認可、たとえば先行するトランザクション152iのアウトプットがロックされているユーザ103aの署名も含む。次に、本トランザクション152jのアウトプットは、新規ユーザまたはエンティティ103bに暗号的にロックされ得る。本トランザクション152jは、したがって、本トランザクション152jのアウトプットで定義されるように先行するトランザクション152iのインプットで定義された額を新規ユーザまたはエンティティ103bに転送することができる。いくつかの場合において、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、釣り銭を渡すために元のユーザまたはエンティティ103aである可能性もある)の間でインプット額を分割するために複数のアウトプットを有し得る。いくつかの場合において、トランザクションは、1つまたは複数の先行するトランザクションの複数のアウトプットから金額を集め、現在のトランザクションの1つまたは複数のアウトプットに再分配するための複数のインプットを有することもできる。
ビットコインなどのアウトプットベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの当事者103が、(手動または当事者によって採用される自動化プロセスによって)新規のトランザクション152jを制定することを望むときに、実施当事者は、そのコンピュータ端末102から受信者に新しいトランザクションを送信する。制定当事者または受信者は、最終的にこのトランザクションをネットワーク106のブロックチェーンノード104の1つまたは複数に送信する(現在では典型的にはサーバまたはデータセンターであるが、原理上、他のユーザ端末とすることも可能である)。また、新しいトランザクション152jを制定する当事者103が、このトランザクションをブロックチェーンノード104の1つまたは複数に直接的に送信し、いくつかの例では、受信者に送信しないことも排除されない。トランザクションを受信したブロックチェーンノード104は、ブロックチェーンノード104の各々で適用されるブロックチェーンノードプロトコルに従ってトランザクションが有効であるかどうかをチェックする。ブロックチェーンノードプロトコルは、典型的には、ブロックチェーンノード104が、新規トランザクション152jにおける暗号署名が、トランザクション152の順序付けられたシーケンス内の前のトランザクション152iに依存する、期待される署名と一致することをチェックすることを必要とする。そのようなアウトプットベースのトランザクションプロトコルにおいて、これは、新規トランザクション152jのインプットに含まれる当事者103の暗号署名または他の認可が、新規トランザクションが割り当てる先行するトランザクション152iのアウトプットにおいて定義された条件に一致することをチェックすることを含むものとしてよく、この条件は、典型的には、新規トランザクション152jのインプットにおける暗号署名または他の認可が、新規トランザクションのインプットがリンクされている前のトランザクション152iのアウトプットをロック解除することを少なくともチェックすることを含む。この条件は、前のトランザクション152iのアウトプットに含まれるスクリプトによって少なくとも部分的に定義され得る。代替的に、単純にブロックチェーンノードプロトコルだけで修正されるか、またはこれらの組合せに起因することもあり得る。いずれにせよ、新規トランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じテストを適用するので、新規トランザクション152jを1つまたは複数のさらなるノード104に転送する、というように続く。このようにして、新規トランザクションは、ブロックチェーンノード104のネットワーク全体に伝播される。
アウトプットベースモデルでは、所与のアウトプット(たとえばUTXO)が割り当てられた(たとえば消費された)かどうかの定義は、ブロックチェーンノードプロトコルに従って、別の、前方のトランザクション152jのインプットによってまだ有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、償還することを試みる先行するトランザクション152iのアウトプットが、別のトランザクションによってまだ償還されていないことである。ここでもまた有効でない場合、トランザクション152jは伝播されないか(警告のために無効であるとフラグが立てられ伝播されない限り)、またはブロックチェーン150に記録されない。これは、トランザクション実行者が同じトランザクションのアウトプットを複数回割り当てようとする二重支払いから保護するものである。その一方で、アカウントベースモデルは、勘定残高を維持することによって二重支払いを防止する。ここでもまたトランザクションの定められた順序があるので、勘定残高はどの時点においても単一の定義済み状態を有する。
トランザクションを正当性確認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、マイニングと一般的に称されるプロセスでトランザクションのブロックを最初に作成するものとなる競争を行う。ブロックチェーンノード104では、新規トランザクションが、ブロックチェーン150上に記録されたブロック151内にまだ出現していない有効なトランザクションの順序付けられたプール154に追加される。次いで、ブロックチェーンノードは、暗号パズルを解くことを試みることによってトランザクション152の新しい有効なブロック151を、トランザクション154の順序付けられたセットから組み立てる競争をする。典型的には、これは、「ノンス」を探索することであって、ノンスが保留トランザクション154の順序付けられたプールの表現と連結されハッシュされたときにハッシュのアウトプットが所定の条件を満たすような、探索することを含む。たとえば、所定の条件は、ハッシュのアウトプットが特定の事前定義済みの数の先行ゼロを有することであり得る。これは1つの特定のタイプのプルーフオブワークパズルにすぎず、他のタイプは排除されない。ハッシュ関数の特性は、インプットに対して予測不可能なアウトプットを有するという性質である。したがって、この探索は総当りによってのみ実行することができ、したがって、パズルを解こうとしている各ブロックチェーンノード104において処理リソースの実質的な量が消費される。
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に発表し、ネットワーク内の他のブロックチェーンノード104が容易にチェックできる証明として解を提供する(ハッシュの解が与えられれば、それがハッシュのアウトプットを条件に合致させることをチェックするのは容易である)。最初のブロックチェーンノード104は、ブロックを受け入れる他のノードの閾値コンセンサスにブロックを伝播し、したがって、プロトコルルールを強制する。次いで、トランザクション154の順序付けられたセットは、ブロックチェーンノード104の各々によってブロックチェーン150内に新しいブロック151として記録されるようになる。ブロックポインタ155も、チェーン内の以前に作成されたブロック151n-1を指す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要な、たとえばハッシュの形態の、著しい量の労力は、ブロックチェーンプロトコルのルールに従う第1のノード104の意向をシグナリングする。そのようなルールは、以前に正当性確認されたトランザクションと同じアウトプットを割り当てる場合にトランザクションを有効なものとして受け入れないことを含むが、これは他の場合には二重支払いとしても知られている。作成された後、ブロック151は、ブロックチェーンネットワーク106内のブロックチェーンノード104の各々で認識され維持されるので、修正できない。ブロックポインタ155は、また、ブロック151に順序を課す。トランザクション152は、ネットワーク106内の各ブロックチェーンノード104において順序付けられたブロックに記録されるので、これはしたがって、トランザクションの不変の公開台帳を提供する。
任意の所与の時点でパズルを解く競争をしている異なるブロックチェーンノード104は、解を探し始めた時期またはトランザクションが受信された順序に応じて、任意の所与の時点でまだ公開されていないトランザクション154のプールの異なるスナップショットに基づきそうするものとしてよいことに留意されたい。それぞれのパズルを最初に解いた者は、どのトランザクション152が次の新しいブロック151nに含まれ、どの順序で含まれるかを定義し、未公開トランザクションの現在のプール154は更新される。次いで、ブロックチェーンノード104は、未公開トランザクション154の新規に定義された順序付きプールからブロックを作成する競争をする、というように続ける。また、2つのブロックチェーンノード104がブロックチェーンの対立する見解がノード104間で伝播されるような互いの非常に短い時間内にパズルを解く場合である、発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどの分岐が最も長く成長しても、決定的なブロックチェーン150になる。これは同じトランザクションが両方のフォークに出現するときにネットワークのユーザまたはエージェントに影響を及ぼしてはならないことに留意されたい。
ビットコインブロックチェーン(およびほとんどの他のブロックチェーン)によれば、新しいブロック104を首尾よく構成したノードは、デジタル資産の追加の定められた量を分配する新しい特殊な種類のトランザクションにおいてデジタル資産の追加の受け入れられた額を新しく割り当てる能力を付与される(1人のエージェントまたはユーザから別のエージェントまたはユーザへデジタル資産の額を転送するエージェント間、またはユーザ間のトランザクションとは対照的に)。この特別なタイプのトランザクションは通常「コインベーストランザクション」と称されるが、「開始トランザクション」または「生成トランザクション」と呼ばれることもある。これは、典型的には、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後で償還されることを可能にするプロトコルルールに従うという意向をシグナリングする。ブロックチェーンプロトコルルールでは、この特別なトランザクションが償還され得る前に償還期限、たとえば100ブロック分を必要とし得る。多くの場合に、正規の(非生成)トランザクション152は、また、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を払うためにアウトプットの1つで追加のトランザクション手数料を指定する。この手数料は、通常、「トランザクション手数料」と称され、以下で説明する。
トランザクションの正当性確認および公開に関与するリソースに起因して、典型的には、ブロックチェーンノード104の少なくとも各々は、1つまたは複数の物理的サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかしながら、原理上、任意の所与のブロックチェーンノード104は、ユーザ端末またはネットワーク接続されたユーザ端末のグループの形態をとることも可能である。
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそれぞれの1つまたは複数の役割を遂行し、トランザクション152を処理するためにブロックチェーンノード104の処理装置上で実行するように構成されているソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰される任意の活動は、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることは理解されるであろう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける1つまたは複数のアプリケーションで実装され得る。
また、ネットワーク101に接続されているのは、消費ユーザの役割を担う複数の当事者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクティブにやり取りし得るが、トランザクションを正当性確認することまたはブロックを構築することに参加することはない。これらのユーザまたはエージェント103のいくつかは、トランザクションにおける送信者および受信者として働き得る。他のユーザは、必ずしも送信者または受信者として活動することなくブロックチェーン150とインタラクティブにやり取りし得る。たとえば、いくつかの当事者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得している)ストレージエンティティとして働き得る。
当事者103の何人かまたは全員は、異なるネットワーク、たとえばブロックチェーンネットワーク106の上に重ねられたネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ(多くの場合に「クライアント」と称される)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われ得るが、これらのユーザは、ブロックチェーンノードの必要な役割を実行しないのでブロックチェーンノード104ではない。その代わりに、各当事者103は、ブロックチェーンノード106に接続する(すなわち、通信する)ことによってブロックチェーンネットワーク106とインタラクティブにやり取りし、それによってブロックチェーン150を利用し得る。2つの当事者103およびそれぞれの機器102、すなわち第1の当事者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の当事者103bおよびそのそれぞれのコンピュータ機器102bが例示を目的として示されている。さらに多くのそのような当事者103およびそのそれぞれのコンピュータ機器102が存在し、システム100に参加し得るが、便宜上、それらは例示されていないことは理解されるであろう。各当事者103は、個人であっても組織であってもよい。純粋に例示を用いて、第1の当事者103aは本明細書ではアリスと称され、第2の当事者103bはボブと称されるが、これは限定するものではなく、本明細書におけるアリスまたはボブへの参照は、それぞれ「第1の当事者」および「第2の当事者」と置き換えてもよいことは理解されるであろう。
各当事者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえば1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを含むそれぞれの処理装置を備える。各当事者103のコンピュータ機器102は、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読記憶装置をさらに含む。このメモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光学媒体を採用する1つまたは複数のメモリユニットを含み得る。各当事者103のコンピュータ機器102上のメモリは、処理装置上で実行するように配置構成されている少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを含むソフトウェアを記憶する。本明細書において所与の当事者103に帰される任意の活動は、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行され得ることは理解されるであろう。各当事者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含む。所与の当事者103のコンピュータ機器102は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク接続リソースも備え得る。
クライアントアプリケーション105は、たとえばサーバからダウンロードされた、好適なコンピュータ可読記憶媒体上で任意の所与の当事者103のコンピュータ機器102に最初に提供され得るか、または取り外し可能SSD、フラッシュメモリキー、取り外し可能EEPROM、取り外し可能磁気ディスクドライブ、磁気フロッピーディスクもしくはテープなどの取り外し可能記憶デバイス、CDまたはDVD ROMなどの光ディスク、または取り外し可能光学式ドライブなど、で提供され得る。
クライアントアプリケーション105は、少なくとも「ウォレット」機能を備える。これは、主に2つの機能性を有する。これらのうちの1つは、それぞれの当事者103が、トランザクション152を作成し、認可し(たとえば署名し)、1つまたは複数のビットコインノード104に送信して、次いでブロックチェーンノード104のネットワーク全体に伝播させ、それによってブロックチェーン150に含まれることを可能にすることである。他は、それぞれの当事者に、現在所有しているデジタル資産の額を報告することである。アウトプットベースシステムでは、この第2の機能は、ブロックチェーン150全体に散らばる様々なトランザクション152のアウトプットにおいて定められた、注目する当事者に属す金額を照合することを含む。
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されていると説明され得るが、これは必ずしも限定するものではなく、その代わりに本明細書において説明されている任意のクライアント機能が、代わりに、2つまたはそれ以上の異なるアプリケーションの組、たとえば、APIを介してインターフェースされるか、または一方が他方へのプラグインされるもので実装され得る。より一般的には、クライアント機能は、アプリケーション層、またはオペレーティングシステムなどの下位層、またはこれらの任意の組合せで実装されることも可能である。次に、クライアントアプリケーション105に関して説明されるが、これは限定的なものではないことは理解されるであろう。
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がネットワーク106にトランザクション152を送信することを可能にする。クライアント105は、また、それぞれの当事者103が受信者である任意のトランザクションについてブロックチェーン150を問い合わせる(または実施形態ではブロックチェーン150は、一部はその公共の可視性を通してトランザクションに信頼を提供する公共の施設であるので、実際にブロックチェーン150内の他の当事者のトランザクションを検査する)ためにブロックチェーンノード104と連絡を取ることができる。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を定式化し送信するように構成される。上で述べたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を正当性確認し、ブロックチェーンネットワーク106全体に伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと一緒になり、一緒に所与のトランザクションモデルを実装する。同じトランザクションプロトコルは、ブロックチェーン150内のすべてのトランザクション152に使用される。同じノードプロトコルは、ネットワーク106内のすべてのノード104によって使用される。
所与の当事者103、たとえばアリスは、ブロックチェーン150に含まれるべき新しいトランザクション152jを送信することを望むときに、アリスは、関連するトランザクションプロトコルに従って(アリスのクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これはアリスのコンピュータ102に最もよく接続されているブロックチェーンノード104である可能性もある。任意の所与のブロックチェーンノード104が新規トランザクション152jを受信したときに、これは、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってそれを処理する。これは、新しく受信されたトランザクション152jが「有効」であるためのある条件を満たすかどうかを最初にチェックすることを含むが、その例は、まもなくより詳細に説明される。いくつかのトランザクションプロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによってトランザクション毎に構成可能であり得る。
代替的に、この条件は、単純にノードプロトコルの組み込み機能であるか、またはスクリプトとノードプロトコルとの組合せによって定義されることも可能である。
新たに受信されたトランザクション152jが有効とみなされることについてのテストに合格するという条件で(すなわち、それが「正当性確認される」という条件で)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104で維持されているトランザクション154の順序付けられたセットに新しい正当性確認されたトランザクション152を追加する。さらに、トランザクション152jを受信した任意のブロックチェーンノード104は、正当性確認されたトランザクション152をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に前方伝播される。各ブロックチェーンノード104は同じプロトコルを適用するので、次いで、トランザクション152jが有効であると仮定すると、これは、それがすぐにネットワーク106全体にわたって伝播されることを意味する。
所与のブロックチェーンノード104で維持されている保留トランザクション154の順序付けられたプールに入るのを許された後、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンでプルーフオブワークパズルを解く競争を開始する(他のブロックチェーンノード104はトランザクション154の異なるプールに基づきパズルを解こうとしている可能性があるが、最初にそこに辿り着いた者が最新のブロック151に含まれるトランザクションの集合を定義するということを覚えておこう。最終的にブロックチェーンノード104は、アリスのトランザクション152jを含む順序付けられたプール154の一部に対するパズルを解くことになる。)新規トランザクション152jを含むプール154に対してプルーフオブワークが行われた後、それは、不変的に、ブロックチェーン150内のブロック151のうちの1つの一部となる。各トランザクション152は、以前のトランザクションを指すポインタを含み、したがってトランザクションの順序もまた、不変的に記録される。
異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスを最初に受信し、したがって、インスタンスが新しいブロック151において公開される、すべてのブロックチェーンノード104が公開されたインスタンスが唯一の有効インスタンスであると合意する時点より前に、どのインスタンスが「有効」であるかについて対立する見解を有することがある。ブロックチェーンノード104が1つのインスタンスを有効なものとして受け入、次いで第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーンノード104はこれを受け入れなければならず、最初に受け入れたインスタンス(すなわち、ブロック151で公開されていないもの)を破棄する(すなわち、無効として扱う)ことになる。
いくつかのブロックチェーンネットワークによって運用されるトランザクションプロトコルの代替的タイプは、アカウントベーストランザクションモデルの一部として、「アカウントベース」プロトコルと称され得る。アカウントベースのケースでは、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別の、そのネットワークのノードによって記憶され、常に更新される。そのようなシステムでは、トランザクションは、口座の実行中トランザクション集計(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者によって署名され、トランザクション参照計算の一部としてハッシュ化される。それに加えて、任意選択のデータフィールドもトランザクションにおいて署名され得る。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合に、以前のトランザクションを指してもよい。
4.2. UTXOベースモデル
図2は、トランザクションプロトコルの例を例示している。これは、UTXOベースプロトコルの一例である。トランザクション152(「Tx」と略記)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は1つまたは複数のトランザクション152を含む)。以下は、アウトプットベースまたは「UTXO」ベースプロトコルを参照して説明される。しかしながら、これは、すべての可能な実施形態に限定されない。例示的なUTXOベースプロトコルは、ビットコインを参照しつつ説明されるが、他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
UTXOベースモデルでは、各トランザクション(「Tx」)152は、1つまたは複数のインプット202、および1つまたは複数のアウトプット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の1つまたは複数のアウトプット203のうちの1つは、ここではUTXO0とラベル付けされている、特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが正当性確認され、したがってUTXOが首尾良く償還されるために後続のトランザクションのインプット202のロック解除スクリプトによって満たされなければならない条件を定義するロッキングスクリプトとを含む。典型的には、ロッキングスクリプトは、金額を特定の当事者(それが含まれるトランザクションの受益者)にロックする。すなわち、ロッキングスクリプトは、典型的には、後続のトランザクションのインプットにおけるロック解除スクリプトが、先行するトランザクションがロックされている当事者の暗号署名を含む条件を含む、ロック解除条件を定義する。
ロッキングスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの断片である。このような言語の特定の例は、ブロックチェーンネットワークで使用される「Script」(大文字のS)と呼ばれる。ロッキングスクリプトは、たとえばアリスの署名の要件など、トランザクションアウトプット203を消費するために必要な情報を指定する。ロック解除スクリプトは、トランザクションのアウトプット内に出現する。ロック解除スクリプト(別名scriptSig)は、ロッキングスクリプトの基準を満たすために必要な情報を提供するドメイン固有言語で書かれたコードの断片である。たとえば、これはボブの署名を含み得る。ロック解除スクリプトは、トランザクションのインプット202内に出現する。
したがって、例示されている例では、Tx0のアウトプット203のUTXO0は、UTXO0が償還されるために(厳密には、UTXO0を償還することを試みる後続のトランザクションが有効であるために)アリスの署名Sig PAを必要とするロックスクリプト[Checksig PA]を備えている。[Checksig PA]は、アリスの公開鍵-秘密鍵ペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1のインプット202は、Tx1を指すポインタ(たとえば、実施形態ではトランザクション全体Tx0のハッシュである、そのトランザクションID、TxID0を用いて)を含む。Tx1のインプット202は、Tx0の任意の他の可能なアウトプットのうちからそれを識別するために、Tx0内でUTXO0を識別するインデックスを含む。Tx1のインプット202は、アリスが鍵ペアから秘密鍵をデータ(暗号では「メッセージ」と呼ばれることもある)の事前定義済み部分に適用することによって作成された、アリスの暗号署名を含むロック解除スクリプト<Sig PA>をさらに含む。有効な署名を提供するためにアリスによって署名される必要があるデータ(または「メッセージ」)は、ロッキングスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
新規トランザクションTx1がブロックチェーンノード104に到着すると、そのノードは、ノードプロトコルを適用する。これは、ロッキングスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロッキングスクリプトで定義されている条件(ここで、この条件は1つまたは複数の基準を含み得る)を満たすかどうかをチェックすることを含む。実施形態では、これは、2つのスクリプトを次のように連結することを含む。
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロッキングスクリプト(この例ではスタックベースの言語)によって構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなくむしろ、共通のスタックにより、他方の後にスクリプトを次々に実行され得る。いずれにせよ、一緒に実行したときに、スクリプトは、Tx0のアウトプット内にあるロッキングスクリプトに含まれるような、アリスの公開鍵PAを使用して、Tx1のインプット内にあるロック解除スクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するために、データそれ自体の期待される部分(「メッセージ」)も含まれる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、すでに本質的に存在しているので、データの署名された部分を平文で指定する別の要素が含まれる必要はない)。
公開秘密暗号による認証の詳細は、当業者には馴染み深いものであろう。基本的に、アリスが自分の秘密鍵を使用してメッセージを署名している場合、アリスの公開鍵および平文のメッセージが与えられれば、ノード104などの別のエンティティは、メッセージがアリスによって署名されたに違いないと認証することができる。署名は、典型的には、メッセージをハッシュ化し、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって公開鍵の保有者は誰でも署名を認証することができる。したがって、特定のデータ部分またはトランザクションの一部などに署名するという本明細書の言及は、実施形態において、そのデータ部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
Tx1のロック解除スクリプトがTx0のロッキングスクリプトで指定された1つまたは複数の条件を満たす場合(したがって、図示されている例では、アリスの署名がTx1で提供され認証された場合)、ブロックチェーンノード104はTx1を有効とみなす。これは、ブロックチェーンノード104が、Tx1を保留トランザクション154の順序付きプールに追加することを意味する。ブロックチェーンノード104は、また、トランザクションTx1をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に転送し、それによりネットワーク106全体にわたって伝播される。Tx1が正当性確認され、ブロックチェーン150に入れられた後、これは、Tx0からUTXO0を使用されたものとして定義する。Tx1は、それが未使用のトランザクションアウトプット203を消費する場合にのみ有効であり得ることに留意されたい。それが別のトランザクション152によってすでに消費されているアウトプットを消費することを試みた場合、Tx1は、他のすべての条件が満たされている場合であっても無効となる。したがって、ブロックチェーンノード104は、先行するトランザクションTx0において参照されているUTXOがすでに消費されているかどうか(すなわち、それがすでに別の有効なトランザクションへの有効なインプットを形成しているかどうか)をチェックする必要もある。これは、ブロックチェーン150がトランザクション152に定義された順序を課すことが重要である理由の1つである。実際に、所与のブロックチェーンノード104は、どのトランザクション152においてどのUTXO203が消費されたかをマークする別のデータベースを維持するものとしてよいが、UTXOが使用されたかどうかを定義するのは最終的にはそれがブロックチェーン150内の別の有効なトランザクションへの有効なインプットをすでに形成しているかどうかである。
所与のトランザクション152のすべてのアウトプット203で指定された総額が、そのすべてのインプット202によって指されている総額よりも大きい場合、これはほとんどのトランザクションモデルにおいて無効であることに対する別の基準である。したがって、そのようなトランザクションは伝播されず、ブロック151に含まれることもない。
UTXOベーストランザクションモデルでは、所与のUTXOは全体として消費される必要があることに留意されたい。UTXOにおいて定義された金額の一部を、別の部分が消費されている間に、消費済みとして「残す」ことはできない。しかしながら、UTXOからの金額は、次のトランザクションの複数のアウトプットの間に分割され得る。たとえば、Tx0のUTXO0で定義されている金額は、Tx1における複数のUTXOの間に分割され得る。したがって、アリスがボブにUTXO0で定義された金額のすべてを与えたくない場合、アリスは、残りをTx1の第2のアウトプットで自分自身に釣り銭を渡すか、または他の当事者に支払うために使用することができる。
実際には、アリスは、通常、自分のトランザクション104をブロック151に正常に入れるビットコインノード104に対する手数料を含める必要がある。アリスがそのような手数料を含めない場合、Tx0は、ブロックチェーンノード104によって拒絶され、したがって技術的には有効であるが、伝播されずブロックチェーン150に含まれ得ない(ノードプロトコルは、ブロックチェーンノード104にトランザクション152を受け入れることを、そうするのを望まない場合には強制しない)。いくつかのプロトコルでは、トランザクション手数料は、それ自身の別個のアウトプット203を必要としない(すなわち、別個のUTXOを必要としない)。その代わりに、インプット202によって指される総額と、所与のトランザクション152のアウトプット203において指定される総額との間の任意の差額が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO0へのポインタはTx1への唯一のインプットであり、Tx1は唯一のインプットUTXO1を有するとする。UTXO0で指定されたデジタル資産の額がUTXO1で指定された額よりも大きい場合、その差額は、UTXO1を含むブロックを作成するためにプルーフオブワークの競争に勝ったノード104によって割り当てられ得る。しかしながら、代替的に、またはそれに加えて、トランザクション手数料がトランザクション152のUTXO203のうちのそれ自身の1つにおいて明示的に指定されることが可能であることは、必ずしも除外されない。
アリスおよびボブのデジタル資産は、ブロックチェーン150内のどこかにある任意のトランザクション152において彼らにロックされたUTXOからなる。したがって、典型的には、所与の当事者103の資産は、ブロックチェーン150全体における様々なトランザクション152のUTXO全体を通して散らばっている。所与の当事者103の総残高を定義する1つの数がブロックチェーン150内のどこかに記憶されているわけではない。それぞれの当事者にロックされ、別の前方のトランザクションでまだ消費されていないすべての様々なUTXOの値をまとめて照合するのはクライアントアプリケーション105内のウォレット機能の役割である。ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
スクリプトコードは、多くの場合に概略として表現される(すなわち、正確な言語を使用しない)ことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(opcode)を使用してもよい。「OP_...」は、Script言語の特定のオペコードを指す。一例として、OP_RETURNは、ロッキングスクリプトの始めにOP_FALSEが先行するときに、トランザクション内にデータを記憶することができるトランザクションの消費不可能なアウトプットを作成し、それによってデータをブロックチェーン150内に不変的に記録する、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。
典型的には、トランザクションのインプットは、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名するものである。いくつかの実施形態において、所与のトランザクションについて、署名は、トランザクションインプットの一部と、トランザクションアウトプットの一部または全部に署名する。署名するアウトプットの特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、通常、どのアウトプットが署名される(したがって、署名の時点で固定される)かを選択する署名の最後に含まれる4バイトコードである。
ロッキングスクリプトは、これが典型的にはそれぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には対応する署名を提供するという事実を指す「scriptSig」と呼ばれることがある。しかしながら、より一般的に、ブロックチェーン150のすべてのアプリケーションにおいて、UTXOが償還されるための条件が署名を認証することを含むことは不可欠でない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用されることが可能である。したがって、より一般的な用語である「ロッキングスクリプト」および「ロック解除スクリプト」が好まれ得る。
4.3. サイドチャネル
図1に示されているように、アリスおよびボブのコンピュータ機器102a、120bの各々の上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、アリス103aが、ボブ103bと(いずれかの当事者または第三者の扇動で)別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークから離れてデータを交換することを可能にする。そのような通信は、ときには「オフチェーン」通信と称される。たとえば、これは、当事者の一方がネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されることなく、またはチェーン150上を進むことなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。このようにトランザクションを共有することは、ときには、「トランザクションテンプレート」を共有すると称される。トランザクションテンプレートは、完全なトランザクションを形成するために必要な1つまたは複数のインプットおよび/またはアウトプットを欠いている場合がある。代替的に、またはそれに加えて、サイドチャネル107は、鍵、交渉された金額または条件、データコンテンツなどの任意の他のトランザクション関係データを交換するために使用され得る。
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立され得る。代替的に、またはそれに加えて、サイドチャネル301は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはアリスのデバイス102aとボブのデバイス102bとの間の直接的な有線またはワイヤレスリンクを介してであっても確立され得る。一般的に、本明細書のどこかで参照されているサイドチャネル107は、「オフチェーン」で、すなわちブロックチェーンネットワーク106とは別に、データを交換するための1つまたは複数のネットワーク技術または通信媒体を介した任意の1つまたは複数のリンクを含み得る。複数のリンクが使用される場合、オフチェーンリンクのバンドルまたはコレクションは全体としてサイドチャネル107と称され得る。したがって、アリスおよびボブが、サイドチャネル107上で、いくつかの情報またはデータまたは類似のものを交換すると言われる場合に、これは必ずしもこれらのデータのすべての部分が全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを暗示するものではないことに留意されたい。
サイドチャネル107は、アリスとボブなどの当事者間の安全で秘密に保たれたオフチェーン通信を可能にするために知られている安全な通信技術を採用する安全なチャネルを含み得る。たとえば、安全なチャネルは、安全なチャネル上で通信する当事者間で共有される共有秘密に基づき得る。そのようなチャネルは、たとえば、検証者103Vがターゲット当事者によって保有されているPUF302/500にチャレンジを提出し、対応する応答を受信することを可能にするなど、検証者103Vとターゲット当事者103Tとの間の通信に使用され得る。
5. ブロックチェーンベースのPUFアイデンティティ証明
前の節で述べたように、応答の記録として働く応答データは、信頼できる第三者システム602を採用するのではなくむしろ、パブリックブロックチェーンに記憶され得る。応答データは、セットアップ時に決定されたデータであり、後に検証者103V(「ボブ」)がターゲット当事者103T(「アリス」)によるターゲットのアイデンティティのアサーションをテストするために使用され得る。ここでもまたアリスおよびボブは単なる任意のラベルであり、アリスおよびボブは、第4節で与えられたブロックチェーンシステムの一般的概要(ボブがアリスのトランザクションのアウトプットを消費していた場合)と同じ役割をここで必ずしも有していないことに留意されたい。
前に説明されているように、所与のCRペア{Ci,Ri}に対する応答データ(チェーン上に記憶されていようと、他の場所に記憶されていようと)は、セットアップフェーズ702で決定され、検証者103Vによる将来参照のために記憶されるように、次のいずれかを含み得る。
i)チャレンジCiおよび/または応答Riの明示的な値(平文または暗号化のいずれか)、または
ii)それぞれの応答Riに対する特定のチャレンジCiが導出され得るマスターチャレンジCmにリンクされた応答Riの明示的な値、または
iii)チャレンジCiの明示的な値とともに応答Riの証明(たとえばハッシュもしくはダブルハッシュ)、または
iv)それぞれの応答Riに対する特定のチャレンジが導出され得るマスターチャレンジCmにリンクされた応答Riの証明(たとえば、ハッシュもしくはダブルハッシュ)、または
v)応答Riから導出された公開鍵-秘密鍵ペアの公開鍵。
図9に示されているように、どのような形態をとろうと、セットアップフェーズ702において、そのような応答データ901は、ブロックチェーン150上に記録されたトランザクション152Sのアウトプット203に記憶され得る。これは、以下では、記憶トランザクションと称されることがある。これは、たとえば、上記の第4節で説明された技術を使用してチェーン上に記録されてもよく、ここでもまたその節におけるアリスは必ずしもターゲット当事者103Tではなく、その節におけるボブは必ずしも検証者103Vではないことに留意されたい--実際には、現在アリスと称されている、ターゲット当事者103Tは、チェーン上に記録されるべき記憶トランザクション152Sを定式化して送信する者であってよい。別の例として、信頼できる第三者は、ターゲット当事者103Tに対する記憶トランザクションのテンプレートを定式化し、セットアップ時に生成された応答データ901を含めることによって完成し、次いでチェーン上に記録されるように転送するものとしてよい。ターゲット当事者103Tは、ブロックチェーンネットワーク106を通して伝播されるようにブロックチェーンノード104のうちの1つに直接的に記憶トランザクション152Sを送信し得るか、または信頼できる第三者などの他の当事者を介して間接的に送信し得る。さらに別の例として、ターゲット当事者103Tは、その当事者の応答データ901を信頼できる第三者に送信し、信頼できる第三者は記憶トランザクション152内に定式化し、チェーン上に記録されるように送るものとしてよい。
応答データ901は、記憶トランザクション152Sの使用不可能アウトプット内に記憶され得る。たとえば、これは、OP_RETURN、またはOP_FALSEに続くOP_RETURNを用いて、Scriptプロトコルを使用する場合に使用不可能にされ得る(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は、アカウントベースモデルの1つまたは複数のトランザクションの1つまたは複数のスマートコントラクトに記憶され得る。
検証フェーズ704において、検証者103Vがターゲットのアイデンティティを検証することを望むときに、検証者は、記憶トランザクション152Sから1つの特定のCRペアに対応する応答データ901を取得するために、ブロックチェーン150にアクセスする。実施形態において、これは、検証者103Vに、特定のチャレンジCiに対応する応答Ri、またはその応答Riの証明(たとえば、ハッシュもしくはダブルハッシュ)を与える。検証者103Vは、また、チャレンジCiをターゲット当事者103Vに提出し、それに応答して、受信されたチャレンジCiをPUFモジュール603に入力することによってターゲット当事者103T(またはそのデバイス)が生成する(と主張された)応答R'iを受信する。次いで、検証者103Vは、返された応答R'iをチェーン上の記憶トランザクション152Sから取り出されたバージョンと比較するか、または証明に使用された受信済み応答に同じ変換(たとえばH(R'i)またはH2(R'i))を適用してこれをチェーン上の記憶トランザクション152Sから取り出された証明と比較する。いずれにせよ、この比較により一致が得られれば、ターゲットは検証される。
検証者103Vは、ブロックチェーンネットワーク106のノード104の1つを介して、または代替的にそのデータ(すなわちトランザクション)がブロックチェーンに含まれることのマークル証明も提供し得る、任意の外部当事者から応答データを取得することによってブロックチェーン150にアクセスし得る。
応答データ901がブロックチェーン150などの公開媒体に記憶される実施形態において、実際の応答値Riそれ自体が公に、または無制限に、開示されないことが望ましい場合がある。そうでなければ、任意の悪意のある当事者がチェーン上のRiを見ることができ、次いで、Ciでチャレンジされた場合にターゲット当事者103Tのふりをすることができる。したがって、その代わりに、Riの証明(たとえば、H(Ri)またはH2(Ri))のみをチェーン上に保持される応答データ901として記憶するか、またはRiの明示的な値を、ただし暗号化形式で記憶することが好ましい場合がある。または、いくつかの場合において、証明は、暗号化形式でチェーン上に記憶されることも可能である。
複数の検証者が潜在的にいる場合、Riまたはその証明を暗号化形式で記憶することは、ターゲット当事者103Tまたは信頼できる第三者がどの検証者103VがCRペアのうちのどれに対応する記憶データ901を取得することができるかを制御することを可能にする。これは、特定の応答データ901の復号鍵を所与の検証者のみに与え、別の応答データ901の復号鍵を別の検証者のみに与えることによって達成され得る。復号化鍵の配布は、ターゲット当事者103Tまたは信頼できる第三者によって管理されることも可能である。各検証者または検証者のサブセットは、応答データ901のそれぞれのサブセット(たとえばCRペア)にアクセスするための1つまたは複数の復号鍵のそれ自身のサブセットを与えられる。好ましくは、サブセットは互いに排他的である。しかしながら、他の実装形態では、それらは重複する可能性もある(たとえば、同じ組織内の異なるグループは、CRペアの重複するサブセットへのアクセス権を有することも可能である)。
これの変更形態として、応答データ901(たとえばCRペア)がオンチェーンではなく第三者システム602に記憶される場合、復号鍵を配布する代わりに(あるいはそれに加えて)、各検証者がCRペア(またはより一般的には応答データ)のそれ自身のサブセットへのアクセス権のみを得ることを確実にするように他の手段が採用されてもよい。たとえば、信頼できる第三者システム602は、各検証者に対するパスワード保護アカウントを維持し、それらはチャレンジへのアクセス権を得るためにログインする必要があり、そのアカウントは、それ自身のCRペアへのアクセス権のみを与える。
そのようなスキームは、セキュリティに関して有利であり得る。所与のCRペアの応答Riが1人の検証者103Vに開示されるべきである場合、同じCRペアが別の検証者103Vに使用されないことが望ましい場合がある。そうでない場合、最初の検証者103Vが、今知られている応答Riを使用して、別の検証者に対して、自分がターゲット当事者103Tであるふりをすることも可能である。しかしながら、応答データ901へのアクセス権を有するすべての潜在的検証者103Vが信頼できる場合、これを防止するための措置をとることは不可欠なことではない。
さらなる変更形態において、チェーン上に記憶された応答データ901は、対応する応答Riに基づき(たとえば、それをシードとして使用して)セットアップ時に生成される公開鍵-秘密鍵ペアの公開鍵である、ターゲット当事者103Tの公開鍵の形態をとることも可能である。この場合、検証者103Vは、記憶トランザクション152Sから公開鍵にアクセスし、それを使用して、対応する秘密鍵でターゲット当事者103Tによって署名されたメッセージを検証する。いくつかの場合において、公開鍵は、異なる検証当事者103Vによる使用のために異なる公開鍵が割り当てられ得るように暗号化形式でチェーン上に記憶されることも可能である。
図9にも示されているように、アウトプット(たとえばUTXOベース)モデルを採用する実施形態では、これは、CRペア(またはそこから導出される鍵)を管理するための効率的なメカニズムを提供するために利用され得る。管理は、ここでは、たとえば、すでに消費された(検証で使用された)後に、CRペアまたは鍵を更新するか、または取り消すことを含むものとしてよい。
これを行うために、新しいモディファイアトランザクション152Mがブロックチェーン150上に記録される。それは、取り消されるか、または更新されるべき応答データ901が記憶される記憶トランザクション152Sのアウトプット203のうちの1つを指すインプット202を有する。これは、そのアウトプットを「消費する」、「償還する」、または「割り当てる」と称されてもよい(ただし、これは必ずしも金銭的価値の移転を意味するものではないことに注意されたい)。これは、検証者103Vによって認識されるレイヤ2プロトコルのレベルでは、指し示された記憶トランザクション152Sまたはアウトプット203の応答データ901がもはや使用されないことを意味すると理解される。モディファイアトランザクション152Mそれ自体がそれ自身のアウトプットの1つに応答データ901'を含む場合、これは、新しい応答データ901'が以前の応答データ901の置き換え(たとえば、新しいCRペア)を表すことを意味するとみなされる。検証者が検証操作で使用する応答データを見つけるためにブロックチェーン150にアクセスする場合、置き換えられたバージョンではなくむしろ更新されたバージョン901'を使用することになる。他方で、モディファイアトランザクション152Uが置換応答データ901を含まない場合、それが指す記憶トランザクション152Sまたはアウトプット203において応答データ901を単純に取り消すとみなされる。
いくつかの実施形態において、応答データ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'の追加によって)、次いで直接的にまたは間接的に、ノード104に転送してチェーン上に記録するものとしてよい。別の可能性として、信頼できる第三者は、モディファイアトランザクション152Mを(場合によってはテンプレートまたはたとえば置換応答データ901'を含むターゲット部分103Tから送られた何らかのデータに基づき)定式化し、次いで信頼できる第三者は、モディファイアトランザクション152Mをノード104に送信してチェーン上に記録させ得る。これらのオプションはすべて、記憶トランザクション152Sがブロックチェーン150に記録される方法にも同様に適用され得ることに留意されたい。
上で説明されている様々な概念によれば、したがって、i)アイデンティティ(または公開鍵などの他の関係する情報)をUTXOにリンクし、このUTXOの消費状態をアイデンティティ資格情報の有効性に対するプロキシとして使用し、およびii)セットアップ、失効、更新、および検証などの効率的なアイデンティティ管理操作を実行するトランザクションのセットを確立するためのシステムが提供される。このプロセスは、すべての当事者が常に互いに通信する必要があるのではなくむしろ、すべての当事者がブロックチェーンを参照していつCRPが消費されたか、またはいつアイデンティティが取り消さされたかを確認することができるので、通信回数が低減されるという点で効率的である。
そのような技術は、たとえば、検証で使用されるCRPデータを処理するための第三者KYC(know your customer)プロバイダへの依存を最小限度に抑えることによって、前に提示されているように、PUFデバイスにアイデンティティをリンクするようにフレームワークを拡張するために使用され得る。この目標は、KYCプロバイダの役割、またはむしろその機能の一部をパブリックブロックチェーンで部分的に置き換えることによって達成され得、これにより、ユーザは、任意の第三者から独立して、ePUFデバイスに関係する、それ自身のアイデンティティ資格情報をインスタンス化し得る。
アイデンティティシステムにおける信頼できる第三者の役割は、必ずしも完全に避けられるわけではないが、いずれにしても、アイデンティティ管理のプロセスは改善され、プロセスへの関与、およびそれにかかる関係する負担は少なくとも低減され得る。
5.1. UTXOセットへのPUFアイデンティティのリンク
ブロックチェーンの使用が前の節で説明されているようなアイデンティティシステムを改善することができる第1の態様は、PUFアイデンティティに関係するCRPを管理するためにパブリックブロックチェーンの未使用トランザクションアウトプットセット(UTXOセット)を使用することによるものである。
この節では、CRPをUTXOセットのメンバーにマッピングし、「消費済み」または「未使用」状態としてのそれらのステータスを各特定のCRPがアイデンティティ検証プロセスにおいて消費されたかどうかの指標として使用するために、2つの異なる例のメカニズムが開示されている。第1のメカニズムは、消費可能UTXOにCRPデータを埋め込むことを伴い、第2のメカニズムは、消費可能UTXOにそれらをペアリングすることを伴う。いずれの場合も、CRP、または注目するアイデンティティ、に関係する追加データも、任意選択でシステムに含まれ得る。
5.1.1. 消費可能UTXOへの組み込み:第1のメカニズムは、CRPを、将来のインプットによって条件が満たされ得るスクリプトを含むトランザクションアウトプットであり、したがって将来の消費トランザクションによって消費され得る消費可能UTXOにバインドすることである。そのような埋め込みを実装するための異なるオプションは多数あるが、われわれの目的のために、これは一般的に、少なくとも次のロッキングスクリプトからなる。
[Checksig P] OP_RETURN <Rep(C, R)>
[Checksig P]は標準的なpay-to-public-key-hash (P2PKH)ロッキングスクリプトであり、Rep(C、R)は特定のチャレンジ-応答ペア(C,R)の表現である。
このロッキングスクリプトは、単純に消費トランザクション上で有効な署名Sig Pを提供することによってロック解除されるものとしてよく、署名は公開鍵Pに対して有効と考えられる。オペコードOP_RETURNに続く任意のデータは、消費トランザクションを正当性確認する際に考慮されず、したがってこのデータはブロックチェーンバリデータに関して任意のものとして扱われ、書式なしであってよいことに留意されたい。
上記のスクリプト内のOP_RETURNコードに続くデータは、チャレンジ-応答ペア(C,R)の表現Rep(C,R)である。この表現は、注目するユースケースに応じて、様々な方法で行うことも可能である。しかしながら、賢明な例は、PUFを所有する証明者アリスのみに知られている鍵kを使用してCRPを暗号化することであろう。この場合、われわれは次の表現のいずれも有することも可能である。
Rep(C, R) = Encrypt(C, k),
Rep(C, R) = Encrypt(R, k),
Rep(C, R) = Encrypt(C || R, k).
これらの表現は、アリスが自分のUTXOに含まれていたチャレンジ、応答、またはCRPのいずれかを、それぞれ、後で取り出すか、または証明することを可能にする。
追加のスクリプトのエンカンバランス:前に示されている基本的なロッキングスクリプトを拡張して、将来、アウトプットを消費するインプットスクリプトの追加条件を含めることが可能である。そのような余分な条件の賢明な例は、次のスクリプトであろう。
[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を証明して管理する方法として、これらのスクリプトを含むトランザクションをどのように構造化するかに関する選択を行うことができる。
本明細書では、CRP、および関連するロッキングスクリプトをUTXOに一対一でマッピングすることが開示されている。言い換えると、そのようなスクリプトを含むすべてのUTXOは、特定のPUFデバイスに関係するちょうど1つのCRPに対応する。
次いで、これらのUTXOをトランザクションにどのように編成するかについていくつかのオプションがある。最もあり得そうなオプションは、次の通りである。
1. トランザクション毎に1つのCRP。
2. トランザクション毎に1つのCRPセット。
3. トランザクション毎に1つのPUF。
第1のオプションは、いくつかの場合において、遺言書を書き換えるなどの、使用頻度が非常に低いPUFなどに対して適用可能であり得、複数のCRPが互いに明らかにリンクしていないという利点を有する。これは、1つのCRPの消費および暴露が他のものとは無関係に明らかにされ得るので、極端なプライバシーが必要な場合にも有用であり得る。
以下のTable 1(表1)のトランザクションは、第1のオプションの例示的な実装形態である。トランザクションは、単一のインプットおよびアウトプットのみを含み、したがって各CRPは異なるトランザクションに含まれることが分かる。そのアウトプットが消費されたときに、このトランザクションのアイデンティティシステムへの関連性は、監査目的以外では事実上終了する。
第2のオプションは、多数のCRPが各々単一のトランザクションにおいてそれぞれのUTXOにマッピングされるオプションであり、CRP消費の期待度数がかなり高い銀行カードなどのユースケースにはより望ましいものであり得る。以下のTable 2(表2)におけるトランザクションは、これがどのように達成され得るかを示している。
アリスによって生成された可能性の高い、インプット署名は、アウトプットのセット全体にわたって署名するものであり得ることに留意されたい。これは、1つの公開鍵PAから多数のUTXO、したがって多数のCRPへの一対多のリンクを提供するが、UTXOから異なるCRPそれ自体への一対一マッピングを維持する。また、再利用を回避するために、各アウトプット/CRPはそれ自体の関連付けられた公開鍵(すべてアリスによって所有される)を有していると仮定される。
上に示されているオプションは、CRPセットを時間とともに更新する実施形態ともうまく統合され得、更新済みセットが生成されるたび毎に、そのセットに対して新規トランザクションが発行され得る。それに加えて、並列の独立した(すなわち、チェーン上で関連しない)トランザクションを介して、同じPUFに対する複数の異なるCRPセットを同時に生成し、発行することもできる。これは、複数の異なる信頼できる第三者(たとえば、異なる銀行)とでアイデンティティを確立するために有用であり得、それによりアイデンティティは両方とも独立して確立されるが、同じPUFによってまだ固定されている。
第3のオプションは、単一のトランザクションが単一のPUFを表すために使用されるオプションであり、単純にオプション2のより制限されたバージョンであり、更新は可能でない。これは、PUF包含デバイスが特定の「寿命」を与えられ、ユーザに新しいデバイスが発行される前に所定の数の認証にのみ使用され得る場合に適用可能であり得る。
5.1.2. 消費可能UTXOとのペアリング
CRPを消費可能UTXO内に埋め込む代替的手段は、単純にそれらをこれらのアウトプットとペアリングすることである。この場合、電子証明書に関する既存の研究との違いは、アリスが第三者とは無関係にアイデンティティを証明することを望んでいる可能性があるので、トランザクションはアリスによって構築し署名され得る点である。
上の図では、n個のCRPに関係する2n個のアウトプットを含む例示的なトランザクションが示されており、これにより、各消費可能アウトプットは、CRPの1つにマッピングされ、CRP表現それ自体は対応する消費不可能アウトプットに含まれている(たとえば、OP_FALSE OP_RETURN)。また、CRPをトランザクションおよびUTXOに編成するための3つの可能な変更形態が、ここでも同様に適用されることに留意されたい。
5.1.3. 議論
CRP管理への利点:CRPをUTXOにマッピングする概念は、前の節からのアイデンティティプロトコルのユーザにとって、CRP管理および取り扱いを著しく改善することができる。利点は、CRPの記憶およびルックアップをブロックチェーンネットワーク106、およびそこからの信頼できる取り出しを円滑にすることができるサービスプロバイダに部分的にオフロードすることができる点である。
特定のPUFの「ライブ」CRPのすべてをUTXOにマッピングすることによって、アイデンティティシステムにおいて所与のPUFに現在利用可能であるCRPに関する正確な情報に関してUTXOセットの状態を問い合わせることによってCRP更新プロセスを改善することが可能である。
ブロックチェーンおよび、これまでに説明したUTXO-CRPマッピング規約を利用する単純なプロセスの例は次の通りである。
1. アリスはPUFデバイスを取得し、(C1,R1),(C2,R2),..., (Cn,Rn)のようにCRPのセットを列挙する。
2. アリスは、Table 2(表2)に示されているようなトランザクションTxIDCRP-Setを生成し、ブロックチェーンネットワークにブロードキャストする。
3. アリスは、第三者との自分のアイデンティティを認証するために時間をかけて複数のCRPを消費する。
4. アリスは、来週の予定される活動をカバーするのに十分な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に接続されているという知識証明のように原理的に動作する点にある。
これは、たとえば、アリスがRの実際の値を共有している場合に、H2(R)はH(R)を提供する第三者によって満たされ得る消費エンカンブランスとしてアリスによってオンチェーンで記録されるPUF-アイデンティティ状況で有用であり得る。
複数当事者署名:この節で詳述されたトランザクションは、PUFアイデンティティをアリスが証明するのを助けるために、複数の異なる当事者からの、より多くの署名を含み得ることももっともらしい。たとえば、アリスのアイデンティティにおける検証者の信頼を改善する方法としてアリスおよび第三者アイデンティティプロバイダの両方がCRPトランザクションのインプットに署名することが望ましい場合がある。これは、副署者が、ブロックチェーントランザクションに署名するために使用されるアリスの公開鍵を証明することができる認証局である場合に、特に関連性がある。複数の当事者は、単なる複数の署名(すなわち「multi-sig」)の代替としてたとえば閾値署名または鍵分割技術(たとえばシャミア秘密共有)を用いて署名プロセスに含まれ得る。
5.2. トランザクションを使用する効率的アイデンティティ管理
ブロックチェーンが、前に提示されているような、PUFベースアイデンティティシステムと併せて使用され得る追加の方法は、PUFデバイスによって安全を保証されたアイデンティティ鍵またはトークンを取り消す効率的な手段としての方法である。
デジタル証明書管理に関する先行研究では、チェーン上で証明書を発行し、取り消すことが知られており、対応する証明書検証プロセスがこれに付随している。アリスが、PUFベースアイデンティティをオンチェーンで証明するときに、喜んで認証局と協力するシナリオを考える。アリスがオンチェーンで自分のアイデンティティに対する証明書を登録するプロセスは、次の通りである。
1. 認証局(CA)は、アリスのアイデンティティを検証する。
2. CAは、証明書トランザクションを作成する。このトランザクションは、次のインプットおよびアウトプットを有する。
a. インプット:CAの署名および公開鍵を含むロック解除スクリプトを有するCAのUTXO。
b. アウトプット1:P2PKHロッキングスクリプト。
c. アウトプット2:アリスの公開鍵を含むOP_RETURNアウトプット。
3. トランザクションはブロードキャストされ、マイニングされた後、CAはアリスにトランザクションID
を提供する。
このプロセスは、アリスと認証局とが協力して、CAによって署名され、アリスの公開鍵の証明書を含む1つの消費不可能アウトプットおよびCAが証明書を取り消すために使用することができる証明書とペアリングされた消費可能アウトプットを含むトランザクションを生成することで終わる。
本明細書において開示されている実施形態は、上記のデジタル証明書について概要を述べた方法と、前に説明されている方法のうちの1つなどの、PUFベースアイデンティティを確立する方法とのハイブリッドを使用する。ここでPUFアイデンティティシステムに追加される要素は、一般的な信頼できる第三者(CAに類似する)が、UTXOを消費することによってCRP、または関係する公開鍵を「取り消す」ことができる要素である。
信頼できる第三者がアリスの公開鍵上の証明書を取り消すケースは、前に説明されている暗号化アイデンティティの確立に関係する。
チェーン上に記憶されるか、または証明されたCRペア(CRP)の場合、本明細書において開示されている実施形態は、認証プロセスで使用された後に信頼できる第三者がCRPを取り消すことを可能にするスキームを提供する。例示的な方法は、次の通りである。
1. アリスおよび信頼できる第三者は、アイデンティティセットアッププロトコルを実施する(たとえば、前述のように)。
2. 次にアリスおよび信頼できる第三者は、1において生成された、またはステップ1の後に現在取得可能なCRPの管理のためにブロックチェーンを使用することを望む。
a. アリスはCRPをトランザクションアウトプットにマッピングするCRPマッピングトランザクションTxIDCRP-Setを作成する。これは、以下のTable 4(表4)に示されている。
b. アリスおよび信頼できる第三者は、両方ともTxIDCRP-Setに署名する。
3. CRPマッピングトランザクションTxIDCRP-Setは、ブロックチェーンブロックでブロードキャストされ公開される。
このプロセスで作成されたマッピングトランザクションは、上のTable 4(表4)に示されている。これは、前にTable 2(表2)に示されたCRPマッピングトランザクションに非常によく似ているが、信頼できる第三者およびアリスの両方がインプットに署名する点と、CRPにマッピングされたUTXOの各々が信頼できる第三者によって将来のトランザクションで消費することによって取り消され得る点が異なる。
これは、CRPの失効が直接通信なしで処理されることを可能にし、TTPがユーザに代わって失効を実行するものとしてよく、これによりシステムにおけるアリスの負担をさらに軽減し、アリスのアイデンティティ管理をなおいっそう軽量化できるという点で有利である。
6. 結論
開示された技術の他の変更形態またはユースケースは、本明細書において開示を示した後に当業者にとって明らかになるであろう。本開示の範囲は、説明されている実施形態によって限定されず、付属の請求項によってのみ限定される。
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されてきた。しかしながら、ビットコインブロックチェーンはブロックチェーン150の特定の一例であり、上記の説明は、任意のブロックチェーンに一般的に適用され得ることは理解されるであろう。すなわち、本発明は、決してビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記の任意の参照は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への参照で置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上で説明されているビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明されている特性のいくつかまたはすべてを共有し得る。
本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成し、公開し、伝播し、および記憶する説明されている機能の少なくともすべてを実行する。これらの機能のうちの1つまたはいくつかだけを実行し、すべてを実行することはない他のネットワークエンティティ(またはネットワーク要素)があり得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成し公開することなく、ブロックを伝播し、および/または記憶する機能を実行し得る(これらのエンティティは、好ましいビットコインネットワーク106のノードとは考えられないことを想起されたい)。
本発明の他の実施形態では、ブロックチェーンネットワーク106は、ビットコインネットワークでなくてもよい。これらの実施形態において、ノードがブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたはいくつかを実行し得るが、すべてを実行するわけではないことは除外されない。たとえば、それらの他のブロックチェーンネットワークにおいて、「ノード」は、ブロック151を作成し、公開するように構成されているが、それらのブロック151を他のノードに記憶しおよび/または伝播することをしないネットワークエンティティを参照するために使用され得る。
さらに一般的には、上記の用語「ビットコインノード」104への任意の参照は、用語「ネットワークエンティティ」または「ネットワーク要素」で置き換えられてもよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割のいくつかまたはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104を参照しつつ上で説明されているのと同じ方法を用いてハードウェアで実装され得る。
上記の実施形態は、例としてのみ説明されていることは理解されるであろう。より一般的には、次のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供され得る。
ステートメント1。1人または複数の検証者が、ターゲット当事者またはターゲット当事者のデバイスを含むターゲットのアイデンティティを検証することを可能にするためのコンピュータ実装方法であって、この方法はセットアップフェーズにおいて、
データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力してPUFに基づき1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶することと、
チャレンジのセットの指示をデータストアに記憶することであって、指示は、セット内のチャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジのセットが導出可能であるマスターチャレンジを含む、記憶することと、
それによって、応答データおよびそれぞれのチャレンジのうちの少なくとも1つを、後続の検証フェーズにおいてターゲットのアイデンティティを検証するために1人または複数の検証者に利用可能にすることであって、各応答に対するそれぞれの応答データは、それぞれの応答またはそれから導出されたデータを含む、利用可能にすることとを含む、コンピュータ実装方法。
ステートメント2。データストアは、第三者コンピュータ機器内に実装される、ステートメント1に記載の方法。
ステートメント3。方法は、信頼できる第三者によって実行される、ステートメント1または2に記載の方法。
ステートメント4。第三者コンピュータ機器は、信頼できる第三者のコンピュータ機器である、ステートメント2に従属するステートメント3に記載の方法。
ステートメント5。セットアップ当事者はターゲット当事者であり、この方法はターゲット当事者から応答または応答データのセットを受信することを含み、記憶することはターゲット当事者から受信することに基づき応答データをデータストアに記憶することを含む、ステートメント3または4に記載の方法。
ステートメント6。ターゲット当事者が応答のセットを生成することを可能にするためにチャレンジのセットまたはマスターチャレンジを生成し、ターゲット当事者に送信する初期ステップを含む、ステートメント5に記載の方法。
ステートメント7。チャレンジのセットは、ターゲット当事者によって生成され、この方法はターゲット当事者からチャレンジのセットまたはマスターチャレンジを受信してマスターチャレンジをデータストアに記憶することを含む、ステートメント5に記載の方法。
ステートメント8。セットアップ当事者はターゲット当事者であり、この方法は、ターゲット当事者によって実行され、ターゲット当事者は応答データおよびマスターチャレンジを、応答または応答データのセット、およびマスターチャレンジを第三者コンピュータ機器に提出することによって前記記憶することを実行する、ステートメント2、またはそれに従属するステートメント3から7のいずれか、に記載の方法。
ステートメント9。ターゲット当事者と信頼できる第三者との間で安全なチャネルを、ターゲット当事者と信頼できる第三者との間で共有される共有秘密に基づき確立することを含み、ターゲット当事者と信頼できる第三者との間のマスターチャレンジまたはチャレンジのセットの受信または提出は、安全なチャネル上で実行される、ステートメント7または8に記載の方法。
ステートメント10。前記提出することは、応答のセットまたは応答データをネットワーク上で第三者システムに送信することを含む、ステートメント9に記載の方法。
ステートメント11。セットアップ当事者は、ターゲット当事者に代わってセットアップを実行し、次いでPUFモジュールをターゲット当事者に送信して、ターゲット当事者が1人または複数の検証者からのチャレンジに応答することを可能にする信頼できる第三者である、ステートメント3、またはそれに従属するステートメント4から10のいずれか、に記載の方法。
ステートメント12。データストアは、パブリックピアツーピア公開媒体である、ステートメント1または2に記載の方法。
ステートメント13。ピアツーピア公開媒体は、ブロックチェーンである、ステートメント12に記載の方法。
ステートメント14。マスターチャレンジは、ターゲットのアイデンティティに関係する1つまたは複数の識別情報を含むか、またはそれから導出される、識別データを含む、ステートメント1から13のいずれかに記載の方法。
ステートメント15。識別データは、ターゲット当事者の複数の識別情報の組合せを含むか、またはそれらから生成される、ステートメント14に記載の方法。
ステートメント16。方法は、信頼できる第三者によって実行され、1つまたは複数の識別情報を取得することに基づきマスターチャレンジデータを決定することを含む、ステートメント14または15に記載の方法。
ステートメント17。前記取得することは、ターゲット当事者から1つまたは複数の識別情報を受信することを含む、ステートメント16に記載の方法。
ステートメント18。方法は、ターゲット当事者によって実行され、マスターチャレンジを記憶することは、ターゲット当事者がマスターチャレンジを決定してそれがデータストアに記憶されるように送信すること、または1つもしくは複数の識別情報の少なくとも1つを信頼できる第三者に送信して、信頼できる第三者がマスターチャレンジを生成しそれをデータストアに記憶することを引き起こすこと、の一方を実行することを含む、ステートメント14または15に記載の方法。
ステートメント19。ターゲット当事者と信頼できる第三者との間で安全なチャネルを、ターゲット当事者と信頼できる第三者との間で共有される共有秘密に基づき確立することを含み、ターゲット当事者と信頼できる第三者との間の識別情報の受信または送信は、安全なチャネル上で実行される、ステートメント17または18に記載の方法。
ステートメント20。ターゲットは、データストアが応答データおよびマスターチャレンジの対応するセットを記憶する複数のターゲットのうちの1つであり、各マスターチャレンジは、対応するターゲットを検証する際に使用できるように、チャレンジのそれぞれのセットの導出を可能にする、ステートメント1から19のいずれかに記載の方法。
ステートメント21。各マスターチャレンジは、対応するターゲットの識別データを含む、ステートメント20に記載の方法。
ステートメント22。導出関数は、チャレンジのセットを順序付け形式で導出し、応答データの各々は、前記順序でチャレンジのうちの異なる1つのチャレンジを指定する識別子と関連して記憶され、したがって、異なるそれぞれの応答データをマスターチャレンジから導出可能なチャレンジのセットの異なるそれぞれのチャレンジにマッピングする、ステートメント1から21のいずれかに記載の方法。
ステートメント23。セットのチャレンジは、連鎖方式で導出可能であり、チャレンジのセットの第1のチャレンジは、導出関数をマスターチャレンジに適用することによって導出可能であり、前記セット内の各連続するチャレンジは、導出関数をセット内の先行するチャレンジに適用することによって導出可能である、ステートメント1から22のいずれかに記載の方法。
ステートメント24。セットのチャレンジは、階層的方式で導出可能であり、チャレンジのセットの第1のサブセットは、導出関数をマスターチャレンジに適用することによって導出可能であり、1つまたは複数の連続するサブセットの各々は導出関数を階層内でさらに遡るチャレンジの1つに適用することによって導出可能である、ステートメント1から22のいずれかに記載の方法。
ステートメント25。導出関数またはその指示も、データストアに記憶され、それによって導出関数またはその指示は1人または複数の検証者に利用可能にされる、ステートメント1から24のいずれかに記載の方法。
ステートメント26。導出関数は、検証者のうちの少なくとも1人に事前に知られており、少なくとも1人の検証者に利用可能にされるか、または指示されることを必要としない、ステートメント1から25のいずれかに記載の方法。
ステートメント27。1人または複数の検証者は、複数の検証者である、ステートメント1から26のいずれかに記載の方法。
ステートメント28。チャレンジのセットは複数のチャレンジであり、応答のセットはそれぞれの複数の応答である、ステートメント1から27のいずれかに記載の方法。
ステートメント29。記憶することは、応答データの1つまたは複数のそれぞれのサブセットのみを検証者の各々に利用可能にし、異なるサブセットは検証者のうちの異なる検証者に利用可能にされる、ステートメント28に記載の方法。
ステートメント30。サブセットは、互いに排他的である、ステートメント29に記載の方法。
ステートメント31。応答データ記録の各々は、それぞれの応答の明示的な値を含む、ステートメント1から30のいずれかに記載の方法。
ステートメント32。応答データ記録の値は、暗号化形式でのみデータストアに記憶される、ステートメント31に記載の方法。
ステートメント33。応答データ記録の1つまたは複数の複数のサブセットの各々は、個別に暗号化され、各サブセットは復号するために異なるそれぞれの復号鍵を必要とする、ステートメント32に記載の方法。
ステートメント34。異なるサブセットは、異なる検証者に復号鍵のうちの異なる復号鍵を配布することによって検証者のうちの異なる検証者に利用可能にされる、少なくともステートメント29に従属するステートメント33に記載の方法。
ステートメント35。応答データの各々は、それぞれの応答の証明のみを含み、応答の明示的な値を含まず、証明は、応答を開示しないが、ターゲットによって返されたそれぞれの応答のさらなるインスタンスに対して同じ変換を実行し、証明と比較することによってターゲットのアイデンティティを検証者が検証することを可能にするそれぞれの応答の変換を含む、ステートメント1から30のいずれかに記載の方法。
ステートメント36。変換は、ハッシュまたはダブルハッシュを含む、ステートメント35に記載の方法。
ステートメント37。PUFモジュールは、PUF、インターフェースロジック、および決定論的変換関数を備え、インターフェースロジックは、チャレンジのセットを受信し、対応する一次応答を生成するためにベースチャレンジをPUFに入力し、応答の前記セットのそれぞれの応答を生成するために生成済みベース応答と併せてチャレンジの受信済みセットの各々を変換関数に入力し、変換関数は受信済みセットからのそれぞれのチャレンジおよび生成済みベース応答の関数である、ことによって応答のセットの生成を引き起こす、ステートメント1から36のいずれかに記載の方法。
ステートメント38。1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置とを備え、メモリは、処理装置上で実行するように配置構成されているコードを記憶し、コードは処理装置上にあるときにステートメント1から37のいずれかに記載の方法を実行するように構成される、コンピュータ機器。
ステートメント39。非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、ステートメント1から37のいずれかに記載の方法を実行するように構成されているコンピュータプログラム。
ステートメント40。検証者がターゲット当事者またはターゲット当事者のデバイスを含むターゲットのアイデンティティを検証するコンピュータ実装方法であって、この方法は、検証者によって、データストアから、応答データ記録のセットのうちから1つの応答データにアクセスすることであって、各々はa)ターゲットに関連付けられている、物理複製困難関数、すなわちPUFを含むPUFモジュールにチャレンジを入力した結果得られる応答の値、またはb)応答の変換を含む証明、のいずれかを含む、アクセスすることと、データストアからマスターチャレンジにアクセスし、マスターチャレンジに導出関数を適用することによってチャレンジのセットの少なくとも1つのチャレンジを導出することと、ターゲットに、ターゲットへの少なくとも1つのチャレンジを含む要求を送信し、それに応答して応答のさらなるインスタンスを受信することと、比較を実行し、比較の結果一致が生じることを条件としてターゲットのアイデンティティを検証することであって、前記比較は、a)の場合に、応答の記憶されている値がさらなるインスタンスと一致し、b)の場合、証明がさらなるインスタンスに適用される同じ変換と一致していることを含む、実行し検証することとを含む、コンピュータ実装方法。
ステートメント41。導出関数の適用は、検証者のコンピュータ機器で導出関数を適用することを含む、ステートメント40に記載の方法。
ステートメント42。データストアは、第三者コンピュータ機器に実装され、導出関数の適用は、検証者が第三者コンピュータ機器で適用されるべき導出関数を要求することを含む、ステートメント40に記載の方法。
ステートメント43。1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置とを備え、メモリは、処理装置上で実行するように配置構成されているコードを記憶し、コードは処理装置上にあるときにステートメント40、41、または42に記載の方法を実行するように構成される、コンピュータ機器。
ステートメント44。非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、ステートメント40、41、または42のいずれかに記載の方法を実行するように構成されているコンピュータプログラム。
100 システム
101 パケット交換ネットワーク
102 機器
102a コンピュータ機器
102T コンピュータ機器
102V コンピュータ機器
103a ユーザ
103b 新規ユーザまたはエンティティ
103S 提出者
103T ターゲット当事者
103V 検証者
104 ブロックチェーンノード
105 クライアントアプリケーション
106 ピアツーピア(P2P)ネットワーク
107 サイドチャネル
150 ブロックチェーン
151 ブロック
151n ブロック
152 トランザクション
152i トランザクション
152j トランザクション
152M 新しいモディファイアトランザクション
152S 記憶トランザクション
152U モディファイアトランザクション
154 順序付けられたセット(または「プール」)
155 ブロックポインタ
201 ヘッダ
202 インプット
203 アウトプット
301 サイドチャネル
302 PUF
402 プロセッサ
404 インターフェースロジック
404' インターフェースロジック
406 アクセス制御ロジック
500 拡張PUF(ePUF)
502 変換関数
504 変換ロジック
601 応答データストア
602 第三者コンピュータ機器
603 PUFモジュール
702 セットアップフェーズ
704 検証フェーズ
802 識別情報
804 組合せ
806 識別情報
901 応答データ
901' 応答データ
903 PUFモジュール
本明細書において開示されている一態様によれば、1人または複数の検証者が、ターゲット当事者またはターゲット当事者のデバイスを含むターゲットのアイデンティティを検証することを可能にするためのコンピュータ実装方法が提供される。この方法は、セットアップフェーズにおいて、データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力してPUFに基づき1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶することを含む。この方法は、チャレンジのセットの指示をデータストアに記憶することであって、指示は、セット内のチャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジのセットが導出可能であるマスターチャレンジを含む、記憶することと、それによって、応答データおよびそれぞれのマスターチャレンジのうちの少なくとも1つを、後続の検証フェーズにおいてターゲットのアイデンティティを検証するために1人または複数の検証者に利用可能にすることとをさらに含む。各応答に対するそれぞれの応答データは、それぞれの応答それ自体またはそれから導出されたデータを含み得る。
ステートメント1。1人または複数の検証者が、ターゲット当事者またはターゲット当事者のデバイスを含むターゲットのアイデンティティを検証することを可能にするためのコンピュータ実装方法であって、この方法はセットアップフェーズにおいて、
データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力してPUFに基づき1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶することと、
チャレンジのセットの指示をデータストアに記憶することであって、指示は、セット内のチャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジのセットが導出可能であるマスターチャレンジを含む、記憶することと、
それによって、応答データおよびそれぞれのマスターチャレンジのうちの少なくとも1つを、後続の検証フェーズにおいてターゲットのアイデンティティを検証するために1人または複数の検証者に利用可能にすることであって、各応答に対するそれぞれの応答データは、それぞれの応答またはそれから導出されたデータを含む、利用可能にすることとを含む、コンピュータ実装方法。

Claims (44)

1人または複数の検証者が、ターゲット当事者または前記ターゲット当事者のデバイスを含むターゲットのアイデンティティを検証することを可能にするためのコンピュータ実装方法であって、前記方法はセットアップフェーズにおいて、
データストア内に、セットアップ当事者が1つまたは複数のチャレンジのそれぞれのセットを物理複製困難関数、すなわちPUFを含むPUFモジュールに入力して前記PUFに基づき前記1つまたは複数の応答を生成した結果生じる1つまたは複数の応答のセットの各々に対するそれぞれの応答データを記憶するステップと、
チャレンジの前記セットの指示を前記データストアに記憶するステップであって、前記指示は、前記セット内の前記チャレンジの各々の値を含まず、むしろマスターチャレンジに導出関数を適用することによってチャレンジの前記セットが導出可能である前記マスターチャレンジを含む、ステップと、
それによって、前記応答データおよび前記それぞれのチャレンジのうちの少なくとも1つを、後続の検証フェーズにおいて前記ターゲットの前記アイデンティティを検証するために前記1人または複数の検証者に利用可能にするステップであって、各応答に対する前記それぞれの応答データは、前記それぞれの応答またはそれから導出されたデータを含む、ステップとを含む、コンピュータ実装方法。
前記データストアは、第三者コンピュータ機器内に実装される、請求項1に記載の方法。
信頼できる第三者によって実行される、請求項1または2に記載の方法。
前記第三者コンピュータ機器は、前記信頼できる第三者のコンピュータ機器である、請求項2に従属する請求項3に記載の方法。
前記セットアップ当事者は前記ターゲット当事者であり、前記方法は前記ターゲット当事者から応答または応答データの前記セットを受信するステップを含み、記憶する前記ステップは前記ターゲット当事者から受信する前記ステップに基づき前記応答データを前記データストアに記憶するステップを含む、請求項3または4に記載の方法。
前記ターゲット当事者が応答の前記セットを生成することを可能にするためにチャレンジの前記セットまたはマスターチャレンジを生成し、前記ターゲット当事者に送信する初期ステップを含む、請求項5に記載の方法。
チャレンジの前記セットは、前記ターゲット当事者によって生成され、前記方法は、前記ターゲット当事者からチャレンジの前記セットまたは前記マスターチャレンジを受信して前記マスターチャレンジを前記データストアに記憶するステップを含む、請求項5に記載の方法。
前記セットアップ当事者は前記ターゲット当事者であり、前記方法は、前記ターゲット当事者によって実行され、前記ターゲット当事者は前記応答データおよびマスターチャレンジを、応答または応答データの前記セット、および前記マスターチャレンジを前記第三者コンピュータ機器に提出することによって記憶する前記ステップを実行する、請求項2、またはそれに従属する請求項3から7のいずれか一項、に記載の方法。
ターゲット当事者と信頼できる第三者との間で安全なチャネルを、前記ターゲット当事者と信頼できる第三者との間で共有される共有秘密に基づき確立するステップを含み、前記ターゲット当事者と信頼できる第三者との間の前記マスターチャレンジまたはチャレンジのセットの前記受信または提出は、前記安全なチャネル上で実行される、請求項7または8に記載の方法。
前記提出は、応答の前記セットまたは応答データをネットワーク上で前記第三者システムに送信することを含む、請求項9に記載の方法。
前記セットアップ当事者は、前記ターゲット当事者に代わって前記セットアップを実行し、次いで前記PUFモジュールを前記ターゲット当事者に送信して、前記ターゲット当事者が前記1人または複数の検証者からのチャレンジに応答することを可能にする前記信頼できる第三者である、請求項3、またはそれに従属する請求項4から10のいずれか一項、に記載の方法。
前記データストアは、パブリックピアツーピア公開媒体である、請求項1または2に記載の方法。
前記ピアツーピア公開媒体は、ブロックチェーンである、請求項12に記載の方法。
前記マスターチャレンジは、前記ターゲットの前記アイデンティティに関係する1つまたは複数の識別情報を含むか、またはそれから導出される、識別データを含む、請求項1から13のいずれか一項に記載の方法。
前記識別データは、前記ターゲット当事者の複数の識別情報の組合せを含むか、またはそれらから生成される、請求項14に記載の方法。
信頼できる第三者によって実行され、前記1つまたは複数の識別情報を取得することに基づき前記マスターチャレンジデータを決定するステップを含む、請求項14または15に記載の方法。
前記取得は、前記ターゲット当事者から前記1つまたは複数の識別情報を受信するステップを含む、請求項16に記載の方法。
前記方法は、前記ターゲット当事者によって実行され、前記マスターチャレンジの前記記憶は、前記ターゲット当事者が前記マスターチャレンジを決定してそれが前記データストアに記憶されるように送信すること、または前記1つもしくは複数の識別情報の少なくとも1つを信頼できる第三者に送信して、前記信頼できる第三者が前記マスターチャレンジを生成しそれを前記データストアに記憶することを引き起こすこと、の一方を実行するステップを含む、請求項14または15に記載の方法。
前記ターゲット当事者と信頼できる第三者との間で安全なチャネルを、前記ターゲット当事者と信頼できる第三者との間で共有される共有秘密に基づき確立するステップを含み、前記ターゲット当事者と信頼できる第三者との間の前記識別情報の前記受信または送信は、前記安全なチャネル上で実行される、請求項17または18に記載の方法。
前記ターゲットは、前記データストアが応答データおよびマスターチャレンジの対応するセットを記憶する複数のターゲットのうちの1つであり、各マスターチャレンジは前記対応するターゲットを検証する際に使用できるようにチャレンジのそれぞれのセットの導出を可能にする、請求項1から19のいずれか一項に記載の方法。
各マスターチャレンジは、前記対応するターゲットの識別データを含む、請求項20に記載の方法。
前記導出関数は、チャレンジの前記セットを順序付け形式で導出し、前記応答データの各々は、前記順序で前記チャレンジのうちの異なる1つのチャレンジを指定する識別子と関連して記憶され、したがって、異なるそれぞれの応答データを前記マスターチャレンジから導出可能なチャレンジの前記セットの異なるそれぞれのチャレンジにマッピングする、請求項1から21のいずれか一項に記載の方法。
前記セットの前記チャレンジは、連鎖方式で導出可能であり、チャレンジの前記セットの第1のチャレンジは、前記導出関数を前記マスターチャレンジに適用することによって導出可能であり、前記セット内の各連続するチャレンジは、前記導出関数を前記セット内の先行するチャレンジに適用することによって導出可能である、請求項1から22のいずれか一項に記載の方法。
前記セットの前記チャレンジは、階層的方式で導出可能であり、チャレンジの前記セットの第1のサブセットは、前記導出関数を前記マスターチャレンジに適用することによって導出可能であり、1つまたは複数の連続するサブセットの各々は前記導出関数を前記階層内でさらに遡る前記チャレンジの1つに適用することによって導出可能である、請求項1から22のいずれか一項に記載の方法。
前記導出関数またはその指示も、前記データストアに記憶され、それによって前記導出関数またはその指示は前記1人または複数の検証者に利用可能にされる、請求項1から24のいずれか一項に記載の方法。
前記導出関数は、前記検証者のうちの少なくとも1人に事前に知られており、前記少なくとも1人の検証者に利用可能にされるか、または指示されることを必要としない、請求項1から25のいずれか一項に記載の方法。
前記1人または複数の検証者は、複数の検証者である、請求項1から26のいずれか一項に記載の方法。
チャレンジの前記セットは複数のチャレンジであり、応答の前記セットはそれぞれの複数の応答である、請求項1から27のいずれか一項に記載の方法。
記憶する前記ステップは、前記応答データの1つまたは複数のそれぞれのサブセットのみを前記検証者の各々に利用可能にし、異なるサブセットは前記検証者のうちの異なる検証者に利用可能にされる、請求項28に記載の方法。
前記サブセットは、互いに排他的である、請求項29に記載の方法。
前記応答データ記録の各々は、前記それぞれの応答の明示的な値を含む、請求項1から30のいずれか一項に記載の方法。
前記応答データ記録の前記値は、暗号化形式でのみ前記データストアに記憶される、請求項31に記載の方法。
前記応答データ記録の1つまたは複数の複数のサブセットの各々は、個別に暗号化され、各サブセットは復号するために異なるそれぞれの復号鍵を必要とする、請求項32に記載の方法。
前記異なるサブセットは、異なる検証者に前記復号鍵のうちの異なる復号鍵を配布することによって前記検証者のうちの異なる検証者に利用可能にされる、少なくとも請求項29に従属する請求項33に記載の方法。
前記応答データの各々は、前記それぞれの応答の証明のみを含み、前記応答の明示的な値を含まず、前記証明は、前記応答を開示しないが、前記ターゲットによって返された前記それぞれの応答のさらなるインスタンスに対して同じ変換を実行し、前記証明と比較することによって前記ターゲットの前記アイデンティティを検証者が検証することを可能にする前記それぞれの応答の変換を含む、請求項1から30いずれか一項に記載の方法。
前記変換は、ハッシュまたはダブルハッシュを含む、請求項35に記載の方法。
前記PUFモジュールは、PUF、インターフェースロジック、および決定論的変換関数を備え、前記インターフェースロジックは、
- チャレンジの前記セットを受信し、
- 対応する一次応答を生成するためにベースチャレンジを前記PUFに入力し、
- 応答の前記セットの前記それぞれの応答を生成するために前記生成済みベース応答と併せてチャレンジの前記受信済みセットの各々を前記変換関数に入力し、前記変換関数は前記受信済みセットからの前記それぞれのチャレンジおよび前記生成済みベース応答の関数である、ことによって応答の前記セットの前記生成を引き起こす、請求項1から36のいずれか一項に記載の方法。
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置とを備え、前記メモリは、前記処理装置上で実行するように配置構成されているコードを記憶し、前記コードは前記処理装置上にあるときに請求項1から37のいずれか一項に記載の前記方法を実行するように構成される、コンピュータ機器。
非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、請求項1から37のいずれか一項に記載の前記方法を実行するように構成されているコンピュータプログラム。
検証者がターゲット当事者または前記ターゲット当事者のデバイスを含むターゲットのアイデンティティを検証するコンピュータ実装方法であって、前記検証者によって、
データストアから、応答データ記録のセットのうちから1つの応答データにアクセスするステップであって、各々はa)前記ターゲットに関連付けられている、物理複製困難関数、すなわちPUFを含むPUFモジュールにチャレンジを入力した結果得られる応答の値、またはb)前記応答の変換を含む証明、のいずれかを含む、ステップと、
前記データストアからマスターチャレンジにアクセスし、前記マスターチャレンジに導出関数を適用することによってチャレンジの前記セットの少なくとも1つのチャレンジを導出するステップと、
前記ターゲットに、前記ターゲットへの前記少なくとも1つのチャレンジを含む要求を送信し、それに応答して前記応答のさらなるインスタンスを受信するステップと、
比較を実行し、前記比較の結果一致が生じることを条件として前記ターゲットの前記アイデンティティを検証するステップであって、前記比較は、a)の場合に、前記応答の前記記憶されている値が前記さらなるインスタンスと一致し、b)の場合、前記証明が前記さらなるインスタンスに適用される同じ変換と一致していることを含む、ステップとを含む、コンピュータ実装方法。
前記導出関数の前記適用は、前記検証者のコンピュータ機器で前記導出関数を適用するステップを含む、請求項40に記載の方法。
前記データストアは、第三者コンピュータ機器に実装され、前記導出関数の前記適用は、前記検証者が前記第三者コンピュータ機器で適用されるべき前記導出関数を要求するステップを含む、請求項40に記載の方法。
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置とを備え、前記メモリは、前記処理装置上で実行するように配置構成されているコードを記憶し、前記コードは前記処理装置上にあるときに請求項40、41、または42に記載の前記方法を実行するように構成される、コンピュータ機器。
非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、請求項40、41、または42に記載の前記方法を実行するように構成されているコンピュータプログラム。
JP2023519749A 2020-09-30 2021-08-31 物理複製困難関数 Pending JP2023543474A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2015475.3A GB2599634A (en) 2020-09-30 2020-09-30 Physically unclonable functions
GB2015475.3 2020-09-30
PCT/EP2021/073961 WO2022069132A1 (en) 2020-09-30 2021-08-31 Physically unclonable functions

Publications (1)

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

Family

ID=73005642

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023519749A Pending JP2023543474A (ja) 2020-09-30 2021-08-31 物理複製困難関数

Country Status (8)

Country Link
US (1) US20240015033A1 (ja)
EP (1) EP4183102A1 (ja)
JP (1) JP2023543474A (ja)
KR (1) KR20230075483A (ja)
CN (1) CN116325653A (ja)
GB (1) GB2599634A (ja)
TW (1) TW202230397A (ja)
WO (1) WO2022069132A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220103348A1 (en) * 2020-09-28 2022-03-31 California Institute Of Technology Optical channel intensity streaming encryption
US11995497B1 (en) * 2023-01-09 2024-05-28 Hyundai Motor Company Method of detecting magnetization signal of physically unclonable functions device and magnetization signal detection sensor

Also Published As

Publication number Publication date
KR20230075483A (ko) 2023-05-31
TW202230397A (zh) 2022-08-01
US20240015033A1 (en) 2024-01-11
EP4183102A1 (en) 2023-05-24
GB2599634A (en) 2022-04-13
WO2022069132A1 (en) 2022-04-07
CN116325653A (zh) 2023-06-23
GB202015475D0 (en) 2020-11-11

Similar Documents

Publication Publication Date Title
US20230360047A1 (en) Verification system and method
US20230336366A1 (en) Authentication 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
JP2023543515A (ja) ブロックチェーン上に応答値を記憶する物理複製困難関数
JP2024515637A (ja) ブロックチェーンベースのシステムおよび方法
JP2024506738A (ja) ＰＵＦおよびブロックチェーンベースのＩｏＴイベントレコーダおよび方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230530