JP2024518523A - ウォレットアプリケーションのインスタンス化、およびｐｕｆデバイスを使用したブロックチェーントランザクションに署名するための鍵の導出 - Google Patents

ウォレットアプリケーションのインスタンス化、およびｐｕｆデバイスを使用したブロックチェーントランザクションに署名するための鍵の導出 Download PDF

Info

Publication number
JP2024518523A
JP2024518523A JP2023570001A JP2023570001A JP2024518523A JP 2024518523 A JP2024518523 A JP 2024518523A JP 2023570001 A JP2023570001 A JP 2023570001A JP 2023570001 A JP2023570001 A JP 2023570001A JP 2024518523 A JP2024518523 A JP 2024518523A
Authority
JP
Japan
Prior art keywords
puf
response
seed
challenge
blockchain
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
JP2023570001A
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 JP2024518523A publication Critical patent/JP2024518523A/ja
Pending legal-status Critical Current

Links

Classifications

    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0042—Universal serial bus [USB]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

チャレンジが物理複製困難関数(PUF)を有するPUFデバイスに入力される。デバイスは、対応する応答を生成する。ウォレットアプリケーションが、応答から決定されたシードを使用するためにインスタンス化され、インスタンス化は、ウォレットアプリケーションに関連してシードまたは応答の変換を格納することを含む。その後、ユーザが、シートを使用するための権利を示す情報をウォレットアプリケーションに供給し、ウォレットアプリケーションは、ウォレットアプリケーションに関連して格納されている変換に基づいて情報を検証すること応じて、かつそれによって情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成される。次いで、ブロックチェーントランザクションが、検証に応じてウォレットアプリケーションによって導出された子キーを使用して署名される。

Description

本開示は、物理複製困難関数(PUF)を有するPUFデバイスに関する。
物理複製困難関数(PUF)は、決定論的であるが予測不可能な物理現象を含む関数を指す用語である。PUFは、ときには物理的乱数関数とも称される。PUFは、「チャレンジ」と称される入力を受け取り、チャレンジおよびPUFによって採用される物理現象に応じて、対応する「応答」と称される出力を生成する。PUFは、ときには強いPUFと弱いPUFに分類される。強いPUFは、多数の異なるチャレンジに対してそれぞれの応答を生成することができ、典型的には、チャレンジの任意の値を取ることができる。弱いPUFは、単一の応答のみ、または少数の応答に対して応答を生成することができる(典型的には、チャレンジは任意の値を取ることができない)。言い換えると、強いPUFは多数のチャレンジ応答ペア(challenge-response pair)を有し(それは大きなチャレンジ応答空間を有し)、その一方で、弱いPUFは単一のチャレンジ応答ペアまたは限られた数のチャレンジ応答ペア(小さいまたは限られたチャレンジ応答空間)を有する。一定義によれば、弱いPUFは、チャレンジビットの数に対して線形に増大する多数の応答、またはより一般的には、チャレンジビットの数もしくは任意の他のパラメータに対して線形以上に増大しない応答を有する(言い換えると、弱いPUFは、そのチャレンジ応答空間をスケールアップさせることができない、すなわち、最大でもチャレンジ応答空間は線形にスケーリングする)。
強い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を参照することによって振替量を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替量を定義する。すべての口座の現在の状態は、ブロックチェーンとは別のノードによって記憶され、常に更新される。
本開示は、ウォレットアプリケーションをインスタンス化して、PUFデバイスを使用したブロックチェーントランザクションに署名するための鍵を導出するための方法を提供する。
本明細書に開示の一態様によれば、方法は、物理複製困難関数(PUF)を有するPUFモジュールを含むPUFデバイスに入力チャレンジを入力するステップを備える。PUFデバイスは、入力チャレンジと入力チャレンジの入力に応じたPUFとに基づいて対応する出力応答を生成するように構成される。方法は、入力チャレンジの入力に応じてPUFデバイスによって生成された出力応答から決定されたシードを使用するためにウォレットアプリケーションをインスタンス化するステップをさらに含む。このインスタンス化することは、ウォレットアプリケーションに関連してシードまたは出力応答の変換を格納することを含む。その後、ユーザがシードを使用する権利を示す情報をウォレットアプリケーションに供給し、ウォレットアプリケーションは、ウォレットアプリケーションに関連して格納されている変換に基づいて情報を検証すること応じて、かつそれによって情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成される。次いで、方法は、検証に応じてウォレットアプリケーションによって導出された子キーを使用してブロックチェーントランザクションに署名し、かつブロックチェーンに記録されるために署名済みブロックチェーントランザクションを送信するステップを含む。
したがって、PUFデバイスは、従来のハードウェアウォレットに代わって機能し、エントロピーのソースをディスク上に格納する必要がないという利点を有する。通常のハードウェアウォレットでは、鍵はデバイス上に格納され、通常はエアギャップされており、インターネットにはまったく接続されていない。次いで、所有者は、トランザクションへの署名や資金の移動が必要なときにデバイスを接続する。また、通常、ユーザがデバイス上に格納された鍵の使用を承認できるようにするパスワードまたはPINがある。PUFベースのハードウェアウォレットでは、通常のPINまたはパスワードがチャレンジに置き換わり、データ鍵が物理的なシステムの応答に置き換わる。本明細書に開示のPUFハードウェアウォレットは、既存のハードウェアウォレットと同じ機能を模倣することができるが、マスターキーをディスク上に格納せず、または少なくとも明らかな状態(in-the-clear)で格納しない。これにより、ハードウェアウォレットは依然としてある程度の危険にさらされている、記憶媒体に対する物理的な攻撃から保護される。
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、添付の図面が参照される。
ブロックチェーンを実装するためのシステムの概略ブロック図である。 ブロックチェーンに記録され得るトランザクションのいくつかの例の概略を例示する図である。 PUFのチャレンジおよび応答の概略を例示する図である。 PUFを含むシステムの概略ブロック図である。 本明細書において開示されている実施形態による拡張PUFの概略ブロック図である。 非拡張動作モードにおける拡張PUFの概略ブロック図である。 ブロックチェーンネットワークで使用するための鍵を生成するためのPUFデバイスを備えたシステムの概略ブロック図である。 PUFデバイスの別の形態を示す概略ブロック図である。 本明細書に開示の実施形態による、第1の方法を示すシグナリング図である。 本明細書に開示の実施形態による、第2の方法を示すシグナリング図である。
人間と機械の両方に対する鍵生成システムおよびプライバシー保護アイデンティティシステムなどのシステムのロバスト性は、物理複製困難関数(PUF)の関与によって改善され得る。これらは、互いにやり取りしている当事者および/もしくは自律的機械、またはブロックチェーンなどの公共システムであってもよい。
これらの関数は、物理的システムに基づき、物理的デバイスの製造においてランダムな、決定不可能な、および再現不可能な変動があるという仮定によって保証され、人間のアイデンティティとそのデバイスとの間に確立されたリンクを強化するために、またはさらにデバイスそれ自体の偽造不可能な一意のアイデンティティを確立するために使用され得る。
文献では、PUFは弱いタイプと強いタイプとに分類され、その異なる特性によって分類される。以下のいくつかの実施形態において、これらのタイプのPUFの両方の利点を有する実用的なPUFデバイスを記述するための一般化拡張PUF(ePUF)フレームワークも提供される。すなわち、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の応答を、ブロックチェーントランザクションに使用される HDウォレットなどのウォレットアプリケーションのシード(つまり、マスタエントロピー)として使用することである。ウォレットを使用するためには、たとえば、トランザクションに署名するための秘密鍵を再生成することによって、ユーザは次の2つのことが必要になる:ウォレットのエントロピーに対応する応答を引き出すための正しいチャレンジの知識、およびPUFデバイスの物理的制御。
この考え方は、典型的なハードウェアウォレットとは異なり、「鍵」またはエントロピーのソースをディスク上に格納する必要がないという利点を備えた新しいタイプのハードウェアウォレットを作成するために使用することができる。通常のハードウェアウォレットでは、鍵はデバイス上に格納され、通常はエアギャップされており、インターネットにはまったく接続されていない。次いで、所有者は、トランザクションへの署名や資金の移動が必要なときにデバイスを接続する。また、通常、ユーザがデバイス上に格納された鍵の使用を承認できるようにするパスワードまたはPINがある。PUFベースのハードウェアウォレットでは、通常のPINまたはパスワードがチャレンジに置き換わり、データ鍵が物理的なシステムの応答に置き換わる。
本明細書に開示のPUFハードウェアウォレットは、既存のハードウェアウォレットと同じ機能を模倣することができるが、マスターキーをディスク上に格納せず、または少なくとも明らかな状態で格納しない。これにより、ハードウェアウォレットは依然としてある程度の危険にさらされている、記憶媒体に対する物理的な攻撃から保護される。たとえば、ウォレットがトランザクションを実行するためにコンピュータにプラグインされている場合、PUFベースのウォレットが「送り専用(送信専用)」として構成され得る。このことは、PUFデバイスが、逆方向にコンピュータにインターフェースする必要がないことを意味する。実施形態では、PUFデバイスは加えて、ECDSA、あるいは、送信の準備ができたトランザクションを作成するためにデバイス上で他の暗号化動作を実行することができる。
図6Aは、本明細書に開示の実施形態のうちの1つのクラスによる、例示的なシステムの概略的ブロック図を与える。システムは、PUFデバイス600およびコンピュータ102を備える。
PUFデバイス600は、PUFモジュール302/500、コントローラ601、およびコンピュータ102に接続するためのデバイス間インターフェース603を備える。好ましくは、PUFデバイス600のこれらの構成要素は、すべて同じ内蔵型ハウジング(すなわち、ケーシング)に一体化されており、改ざんを防止するために密封またはロックすることができる。PUFデバイス600はまた、このハウジングに一体化された自身のビルトインユーザインターフェース(UI)602を備え得る。UI602は、たとえば、シンプルなキーパッドや専用機能のタッチスクリーンなど、1つまたは複数のユーザ入力手段を備え得る。PUFデバイス600は、専用のボックスもしくはドングル、またはウォレットアプリケーションをインスタンス化するための応答を生成する専用の機能を備えた他のそのような周辺機器の形態をとってもよい。
コンピュータ102は、1つまたは複数のコンピュータ端末やユニットを備えた任意の適切な形態を備える。たとえば、それは、デスクトップ、ラップトップ、タブレット、スマートフォン、あるいは、スマートウォッチやスマートグラスなどのウェアラブルコンピュータの形態をもとり得る。コンピュータ102はまた、たとえば、図1に関して後述するような任意の形態をとり得る。実施形態では、コンピュータ102は、図1に関連して簡単に説明するように、より大きなシステム内に配置され得る。コンピュータ102には、ウォレットアプリケーション605がインストールされ、ウォレットアプリケーション605は、図1の一般的なシステムに関して後述するウォレットアプリケーション105と同様であるが、図6Aおよび図7を参照して簡単に説明するように、PUFデバイス600からの応答に基づいてインスタンス化できる追加の特定の機能を備えている。コンピュータ102はまた、(後により詳細に再度説明することになるが)ブロックチェーン150上に記録されるためにトランザクション152を送信するために、ブロックチェーンネットワーク106に、直接または仲介者を介して代理で接続するためのネットワークインターフェース606を備える。この接続は、ブロックチェーンネットワーク106が重ねられた1つまたは複数の基盤のネットワークインフラストラクチャ(たとえば、インターネット)を介し得る。たとえば、ネットワークインターフェース606は、ワイヤレスルータに接続し、次いでインターネットに接続するためのWi-Fiトランシーバ、またはモバイルセルラーネットワークを介してインターネットに接続するためのモバイルセルラートランシーバー、あるいは電話回線や光ファイバなどを介してインターネットに接続するためのワイヤードモデムを備えることができる。
デバイス間インターフェース603/604は、好ましくは、直接ローカルインターフェースであってよく、本明細書では、任意の第3のデバイスが同時に接続できる任意のネットワークを介して接続しないことを意味する。ローカルインターフェースは、ワイヤードの非ネットワーク化インターフェースであってよい。たとえば、実施形態では、コンピュータ102のデバイス間インターフェース604は、USBポートまたはシリアルポートであってもよく、PUFデバイス603の対応するデバイス間インターフェース603は、それぞれUSBプラグまたはシリアルポートコネクタを備えてもよい。別の例として、PUFデバイス600のデバイス間インターフェース603は、バーコードまたはQRコード(登録商標)などのグラフィック形式で出力応答Rを表示するように構成されたスクリーンを備えてもよく、コンピュータ102のデバイス間インターフェース604は、カメラまたはスクリーンから応答Rのグラフィック形式を読み取るためのスキャナを備える。Bluetooth接続などの直接ペアリングされたRFインターフェース、またはWLANを介してなどネットワーク化された接続の可能性は排除されないが、これらのオプションは、PUFデバイス600が展開されたシナリオに応じて、より多くの傍受の機会を提供することがある。
実施形態では、PUFデバイスのデバイス間インターフェース603は、デバイス600からのデータの出力のみを許可し、入力を許可しない一方向インターフェース(送信専用)として構成される。実施形態では、UI602は、PUFデバイス600にデータを入力する唯一の手段である(ハウジングを分解することを除く)。
PUFデバイス600内では、コントローラ601は、PUFデバイス600の組み込みメモリに格納され、PUFデバイス601の組み込みプロセッサ上で実行されるように構成されたコード片(ソフトウェア、たとえば、ファームウェア)の形態をとってもよい。組み込みメモリは、1つまたは複数のメモリユニットを備えることができ、これは、ROM、EPROM、EEPROM、フラッシュメモリ、またはスタティックまたはダイナミックRAMなどの電子メモリ、または磁気ディスクやテープなどの磁気媒体など、任意の1つまたは複数の適切なメモリ媒体を採用することができる。組み込みプロセッサは、たとえば、CPUなどの汎用プロセッサ、または、GPU、DSP、暗号プロセッサなどのアプリケーション固有プロセッサなど、任意の適切な形態をとる任意の1つまたは複数の処理ユニットを備えることができる。他の実施形態では、コントローラ601は、専用のハードウェア回路、あるいはPGAやFPGAなどの構成可能もしくは再構成可能な回路、あるいはソフトウェアとハードウェアの任意の組み合わせの形で実装することさえできる。
動作中、コントローラ601は、ユーザ103から入力チャレンジを受け取る。実施形態では、これは、たとえば、ユーザはコードまたはニーモニックフレーズを入力するなど、ビルトインUI602を通じて入力される。たとえば、UI602はテンキーパッドを備えていてもよく、ユーザはチャレンジを数字で入力する、あるいは、UI602は、ユーザが、コントローラ601がPUFモジュール500/302への入力のために数値形式に変換するBIP32ニーモニックフレーズなどのニーモニックフレーズの形式でチャレンジを入力するための文字キーパッドを含んでもよい(PUFモジュールが、256ビットチャレンジなどの長い形式の入力チャレンジをとる場合、ニーモニックフレーズのオプションがより適切になることがある)。他の実施形態では、入力チャレンジが、PUFデバイス600の(または別の)デバイス間インターフェース603を介して別のデバイスから提供され得ることが排除されない。いずれにせよ、コントローラ601は、この入力チャレンジCをPUFモジュール302/500に転送し、PUFモジュール302/500は、これに応答して出力応答Rを生成する。次いで、コントローラ602は、それぞれのデバイス間インターフェース603、604を介して、この応答をコンピュータ102上のウォレットアプリケーション605に転送する。
実施形態では、PUFデバイス602内のPUFモジュールは、図5Aに関連して前述した拡張PUF(ePUF)500から構成され得る。この場合、図6AのPUFモジュール500に入力される入力チャレンジCは、二次チャレンジCiであり、出力応答Rは二次応答Riである。インターフェースロジック404’は、一次チャレンジCwを実際のPUF302に供給し、二次チャレンジCiを変換機能502に供給する。変換関数502は、これとPUFモジュール302の一次応答Rwを入力として受け取り、これらの組み合わせを二次応答Riにマッピングする。次いで、インターフェースロジック404’は、この二次応答RiをPUFモジュール500の出力応答Rとして出力する。次いで、ウォレットアプリケーション605は、出力応答Rを使用してシード(すなわち、マスターキーまたは親キー)を決定し、このシードに基づいて自身をインスタンス化する(後でより詳しく説明する)。
しかしながら、代替の実施形態では、PUFデバイス内のPUFモジュールは、単にプレーンPUF302であってもよい。この場合、ウォレットアプリケーション605をインスタンス化するために使用される入力チャレンジCおよび出力応答Rは、単にPUF302の一次CRペア(すなわち、ベースまたは固有のCRペア)である。
好ましくは、PUFモジュール500/302は、強力なPUFの能力、すなわち、複数のチャレンジ応答ペアをマッピングできる能力を提供し、ウォレットアプリケーション605をインスタンス化するために使用される入力チャレンジCおよび出力応答Rは、複数のCRペアのうちの1つを形成する。ePUF500の場合、PUF302自体は弱いPUFであってもよいが、ePUF502は、弱い機能を拡張して、単一の一次チャレンジ応答ペアCw、Rwから複数の二次チャレンジ応答ペアを生成できるようにする。したがって、ePUF500は、全体的に強力なPUFのように動作する。この場合、ウォレットアプリケーション605をインスタンス化するために使用される入力チャレンジCおよび出力応答Rは、二次ペアの1つである。しかし、代替として、PUFモジュールがそれ自体で単なるPUF302である実施形態では、このPUF302は、ウォレットアプリケーション605をインスタンス化するために使用されるペアがそのようなペアの1つである、複数の一次CRペアを有する強力なPUFであってもよい。弱いPUFを単に使用する可能性は排除されないが、強いPUFの利点は、ユーザ103がウォレットを紛失した場合、それを発見した悪意のある当事者が、ウォレットアプリケーション605がインスタンス化されたシードを使用するために必要な応答を生成するためにどのチャレンジを使用する必要があるかを判断できないことである。
PUFモジュール302/500がどのような形式をとるとしても、ウォレットアプリケーション605をインスタンス化するために使用されるシードを決定するために、実施形態では、ウォレットアプリケーションで使用されるシードのタイプとすでに同じ長さ(つまり、ビット長-ビットの数)である場合、出力応答Rは、単純にそのまま(変換されずに)シードとして使用されてもよい。代替的に、出力応答Rをシードに変換するために変換を適用することができる。たとえば、ウォレットアプリケーション105によって使用されるシード長が、PUFモジュール302/500によって出力される応答Rの長さと異なる場合、ウォレットアプリケーション605は、たとえば、256ビットから128ビットになど、応答Rの長さに適合する変換を適用する必要があることがある。このような変換の例としては、ハッシュ関数(入力の長さに関係なく固定長の値を出力する関数)、出力応答Rの端数を切り捨てたりパディングしたり、出力応答Rからnビットごとに取得したりする関数などが挙げられる。
出力応答Rからシードが(直接または変換を介して)どのような手段で決定されても、このシードは、ブロックチェーン150上に記録するための1つまたは複数のブロックチェーントランザクション152に署名するための少なくとも1つの子キーを導出するマスターキーまたは親キーとして使用され得る(たとえば、後でより詳細に説明する図1を参照)。親キーから子キーを導出するさまざまな子キー導出関数自体は、当技術分野で知られている。
これを行う前に、ウォレットアプリケーション605は、まずシードを用いて「インスタンス化」される。これは、ウォレットアプリケーション105に関連してコンピュータ102のメモリの一部に、ユーザがシードを使用する権利を持っていることを検証するために後で使用できる情報を格納することを意味する(すなわち、シードを使用して、トランザクションなどに暗号的に署名するための1つまたは複数の子キーを生成できる)。この一部の情報は、少なくとも2つのうちの1つである: A)シードまたはシードが決定される応答の一方向変換(ハッシュなど)、あるいは、B)シードまたは応答の暗号化されたバージョン。前者(A)は、シードまたは応答の「証明書」と呼ばれることがある。
A)の場合、ウォレットアプリケーション105を最初にインスタンス化するために使用された応答Rを生成するとき、ユーザは、応答Rを生成するためにPUFデバイス600に入力された対応する入力チャレンジCを記憶または格納する。ここでの格納は、紙に書き留めること、またはコンピュータ102または別のデバイス(たとえば、電話またはスマートウォッチなどの別個の個人用デバイス)のいずれかにデジタル的に格納することを意味し得る。ユーザは、数値形式のチャレンジにマッピングし直すことができるBIP32ニーモニックなどの便利なニーモニックの形式でチャレンジを記憶または格納できる。
その後、ユーザ103がブロックチェーントランザクション152に署名を望むとき、彼/彼女はコードを自分の脳、紙、またはデジタルストレージから思い出すか、または取り出し、それをPUFデバイス600に入力し直し(たとえば、ビルトインUI602を介して)、インスタンス化時に生成されたのと同じ応答Rを再生成する。いくつかの実施形態では、これは、フレーズを数値にマッピングし直すこと、およびUI602を介してその数値を入力すること、またはコントローラ601が数値形式のチャレンジにマッピングし直すニーモニックフレーズをUI602に入力することを含んでもよい。どのような手段でチャレンジが再入力されても、これにより、コントローラ601は、デバイス間インターフェース603、604を介して、コンピュータ102上のウォレットアプリケーション105に応答Rを再度出力する。これに応答して、ウォレットアプリケーション605は、インスタンス化の時点から元の証明書を生成するために使用されたのと同じ変換(たとえば、ハッシュ)を適用し、その結果を格納された証明書と比較する。それらが一致する場合、これは、ユーザがインスタンス化の際に使用された同じPUFデバイス600およびチャレンジCを所有していることを示し、したがって、現在存在するユーザが信頼され得る。次いで、ウォレットアプリケーション605は、ユーザが、最近生成された応答のインスタンスから新たに決定されたシードを使用して、少なくとも1つの子キーを導出することができるようにし、ユーザは、その子キーを使用して、ブロックチェーン150上での記録のために1つまたは複数のブロックチェーントランザクション152に署名することができる。
A)の場合、応答Rもシードも、いかなる形式でもコンピュータ102に格納されず、実際にはどこにも格納されないことが好ましい(証明書の生成後にコンピュータ102から削除される)。したがって、PUFデバイス600を所有し、元のチャレンジCを思い出せる当事者だけがシードを使用できる。
あまり好ましくない変形例では、ユーザ103は、応答Rまたはシードを記憶し、書き留め、または格納し、PUFデバイス600から再生成することなく、これをウォレットアプリケーション605に直接入力することができる。しかし、これは、ユーザが、記憶し、書き留め、または格納したものが侵害された場合、鍵を生成するためにPUFデバイス600を所有する必要がないため、安全性が低くなる。
B)の場合、ハッシュなどの証明書の代わりに、暗号化されたバージョンの応答またはシードが、ウォレットアプリケーション605に関連してコンピュータ102のメモリの一部に格納される。ウォレットアプリケーション105はまた、応答またはシードを復号化できるようにするためのパスワードまたはコードを決定し、これをコンピュータ102のUIを通じて(たとえばスクリーン上または音声で)ユーザに供給する。次いで、ユーザはこのパスワードまたはコードを記憶するか、書き留めるか、デジタル的に格納する(コンピュータまたは別のデバイス、たとえば電話やスマートウォッチなどの別の個人用デバイスのいずれかに)。その後、ユーザがトランザクションに署名するためにシードを使用したいとき、ユーザは、コンピュータ102のUIを介してウォレットアプリケーション605にパスワードまたはパスコードを入力する。いくつかの実施形態では、パスワード/コードは、ウォレットアプリケーション605が応答またはシードを復号するために使用する復号キーそのものであってもよい。代替的に、パスワードまたはコードは、ウォレットアプリケーションが復号キーと関連して格納する別個のデータであってもよく、ユーザが指定したパスワード/コードが格納されているパスワード/コード(またはその証明書)と一致する場合、復号キーを解放する。次いで、ウォレットアプリケーション605は、解放されたキーを使用して応答またはシードを復号し、これに基づいて、ユーザがシードを使用して、1つまたは複数のブロックチェーントランザクション152に署名するための少なくとも1つの子キーを導出できるようにする。
オプションとして、ユーザ103は、同様にウォレットアプリケーションに応答またはシードを供給することを要求される場合もある。彼らは、元のチャレンジCを記憶し、書き留め、またはデジタル的に格納することでこれを実行し、これをPUFデバイスに再入力して応答Rを再生成することができる。代替的に、安全性の低い使用例では、応答Rまたはシードを記憶し、書き留め、またはデジタル的に格納することができる。いずれにせよ、ウォレットアプリケーション605は、応答またはシードの復号化されたバージョンが、ユーザ103によって現在供給されているバージョンと一致することを確認できる(たとえば、現在PUFデバイス600に再度入力されているチャレンジのインスタンスに基づいて)。
好ましくは、応答Rもシードの非暗号化(明らかな状態(in-the-clear))バージョンは、コンピュータ102にも、実際にはどこにも格納されない(暗号化バージョンの生成後にコンピュータ102から削除される)。
シードを使用する権利を検証するためにどちらのアプローチ(たとえば、AまたはB)が使用されても、子キーが導出され、それを用いてブロックチェーントランザクション152が署名されると、ウォレットアプリケーション600は、適切なブロックチェーン150上に記録されるために署名済みトランザクションを送信することができる。コンピュータ102は、たとえば、Wi-Fiトランシーバやワイヤードモデムなど、この目的のためのネットワークインターフェース606をさらに備える。コンピュータ102は、ノード104がネットワーク全体にトランザクションを伝播するために、署名されたトランザクションをブロックチェーンネットワーク106(図1参照)のノード104の1つに直接送信することができる。代替的に、コンピュータ102は、1つまたは複数の中間当事者を介してトランザクションをノード104に送信することができる。たとえば、署名されたトランザクションは、アリス103aによって署名されたテンプレートトランザクションである可能性があるが、ブロックチェーンネットワーク106にブロードキャストする前に、ボブ103bによって一部の部分が完了する必要がある。この場合、アリス103aは、自分の署名を追加し、署名されたテンプレートをボブ103bに送信してボブの部分を追加し、その後、ボブは、トランザクションの完了したバージョンをブロックチェーンネットワーク106のノード104に転送することができる。
図7は、図6Aのようにウォレット操作がPUFデバイス600の外部にある方法の一例を示すシグナリング図である。ステップS1からS6はセットアップフェーズ701で実行され、ステップT1からT6は後続の支払いフェーズ702で実行される。
セットアップフェーズ701の開始時に、ステップS1で、ユーザ103は、ランダムチャレンジを、256ビットなどの特定のビット長の数値にマッピングされるニーモニックフレーズの形式で選択する。ステップS2で、ユーザ103は、ビルトインUI602を介してチャレンジをPUFデバイス600に入力する。たとえば、UI602は文字キーパッドを備えてもよく、ユーザは自分が選択した語句を入力してもよい。次いで、PUFデバイス600のコントローラ601は、入力チャレンジをPUFモジュール500/302に供給する。実施形態では、コントローラ601は、PUFモジュール500/302に入力する前に、チャレンジをニーモニック形式から数値形式に変換することができる。
ステップS3で、入力チャレンジに応答して、PUFモジュール500/302は対応する応答を出力し、コントローラ601はこれをそれぞれのデバイス間インターフェース603、604を介してコンピュータ102上のウォレットアプリケーション605に転送する。ステップS4で、応答は、たとえば、異なる長さの応答から固定シード長のシードを生成することによってシードに変換される。代替的に、使用されている鍵導出アルゴリズムに適した形式であれば、応答をそのままシードとして使用できる。
ステップS5では、ウォレットアプリケーション105が、たとえば、シードのハッシュなどの証明書を格納することによって、またはシードの暗号化されたバージョンを格納することによって、決定されたシードを用いてインスタンス化される。好ましくは、シードも応答自体も格納されないか、少なくとも明らかな状態で格納されない。ステップS6で、ユーザは、シードが決定された応答を生成するために使用されたチャレンジを安全に「格納」する。実施形態では、これは、ユーザがチャレンジを頭の中で(たとえば、ニーモニック形式で)記憶すること、または手で書き留めること、または(おそらく、別個の電話機またはウェアラブルデバイスなどのコンピュータ102とは別個のデバイス上、または施錠された金庫または保管箱に保管できるメモリキー上で)デジタル的に格納することを含んでもよい。
その後、支払いフェーズ702のステップT1で、ユーザ103は、たとえば、記憶からチャレンジを呼び出すか、書面またはチャレンジが保管されていたデジタルストレージからそれを読み取ることによって、格納されていたチャレンジを取り出す。ステップT2で、ユーザは、ステップT3で応答を再生成させてウォレットアプリケーション605に出力させるために、PUFデバイス600にチャレンジを再度入力する。これは、ステップS2からS3に関連して説明したのと同じ方法で行うことができる。
ステップT4で、ウォレットアプリケーション605は、新たに供給された応答のインスタンスから(候補)シードを決定し、これが実際にセットアップフェーズ701で最初に決定されたシードであることを確認する。これは、セットアップ段階で格納された証明書の生成に使用されたものと同じ変換(ハッシュ関数など)を新しく生成された応答のインスタンスに適用し、その結果が格納されている証明書と一致することを確認することによって実行できる。一致する場合、ウォレットアプリケーションはシードを使用して、実装に応じて適切な子キー導出関数を使用して少なくとも1つの子キーを導出する。
代替的に、インスタンス化が、証明書ではなくシードの暗号化されたバージョンを格納することを含む場合、ステップT4で、ユーザ103は、パスワードまたはパスコードを入力しなければならない、ここで、パスワードまたはパスコードは、復号キーまたは復号キーを解放する単語またはコードであり得る。いずれにせよ、ユーザ103が正しいパスワード/コードを供給した場合、ウォレットアプリケーション605はシードを復号し、それを新たに決定された候補シードと比較することができる。それらが一致するという条件で、ウォレットアプリケーションはシードを使用して、実装に応じて適切な子キー導出関数を使用して少なくとも1つの子キーを導出することができる。追加の条件として、ウォレットアプリケーション605は、ユーザに応答またはシードを再入力することを要求することもでき、ユーザは、元のチャレンジCを呼び出すかまたは検索し、応答Rを再生成するためにPUFデバイス600に再入力することによって行うことができる。
ステップT5で、ウォレットアプリケーション605は、導出された子キーを用いてブロックチェーントランザクション152に署名する。ステップT6で、ウォレットアプリケーション605は、ブロックチェーン150に記録される署名済みトランザクション152を送信する。
図6Bは、ウォレットアプリケーション605が他の構成要素と同じハウジング内のPUFデバイス600に一体化された図6Aのシステムの変形を示す。ウォレットアプリケーションは、PUFデバイス600の組み込みメモリの一部に格納され、PUFデバイス600の組み込みプロセッサ上で実行されるように構成される。あるいは代替的に、ウォレットアプリケーション605は、専用のハードウェア回路、PGAやFPGAなどの構成可能もしくは再構成可能な回路、あるいはハードウェアとソフトウェアの任意の組み合わせの形で実装することもできる。
図6Bの場合、システムは、コントローラ601が応答Rを出力するときに、内部インターフェースを介してウォレットアプリケーション605に直接出力することを除いて、図6Aに関連して既に説明したように構成され得る。また、シードまたはレスポンスの格納された変換-たとえば、証明書(たとえば、ハッシュ)または暗号化されたシード-は、コンピュータ102ではなく、PUFデバイス600の組み込みメモリの一部に格納される。ウォレットアプリケーション605にトランザクションに署名させるために、ユーザ103は、PUFデバイスのビルトインUI602を介してウォレットアプリケーションを制御することができる。ブロックチェーン150に記録される署名済みトランザクションを送信することになると、ウォレットアプリケーションは、コンピュータ102が、コンピュータ102のネットワークインターフェース606を介して、トランザクションをブロックチェーンネットワーク106に向けて転送するために、それぞれのデバイス間インターフェース603、604を介してコンピュータ102に出力することができる。代替的に、コンピュータ102が全く必要とされないように、ネットワークインターフェース606をPUFデバイス600のハウジングに一体化できる。
図8は、ウォレット動作がPUFデバイス600内で起こる方法の一例を示すシグナリング図である。この方法は、ステップE1からE5を含むセットアップフェーズ801と、ステップP1からP5を含む支払いフェーズ802を含む。
セットアップフェーズ801の開始時に、ステップE1でユーザ103はランダムチャレンジCを選択し、ステップE2でユーザ103はそのチャレンジをPUFデバイス600に入力する。これらのステップは、ステップS1～S2と同様に実行することができる。ステップE2は、PUFデバイス600に応答Rを生成させるが、これはコンピュータ102に送信する必要はなく、その代わりに、PUFデバイス600の内部で組み込みウォレットアプリケーション105を利用できるようにする。ステップE3で、組み込みウォレットアプリケーション105は、PUFデバイス600の内部で、応答Rからシードを決定する。ステップE4で、ウォレットアプリケーション605は、シードまたは応答の認証、またはシードまたは応答の暗号化されたバージョンを、PUFデバイス600の組み込みメモリの一部内に内部的に格納することによってインスタンス化される。
支払いフェーズ802では、ステップP1で、ユーザ103は、チャレンジCを思い出す、調べる、または読み込む。ステップP2で、ユーザ103はチャレンジをPUFデバイス600に再入力し、PUFモジュール500/302に応答Rを再生成させ、それをPUFデバイス600内の内部で組み込みウォレットアプリケーション605に供給させる。ユーザはまた、署名されるトランザクションを入力する(または、これは後で、ステップP3の後で行うこともできる)。ステップP3で、組み込みウォレットアプリケーションはシードから子キーを導出する(ステップP2でユーザがチャレンジを提供し、期待される応答が生成されたと仮定する)。ステップP4で、組み込みウォレットアプリケーション605は、子キーを使用してトランザクションに署名する。ステップP3～P4は依然としてPUFデバイス600内で内部的に実行される。ステップP5で、組み込みウォレットアプリケーション605は、ブロックチェーン150に記録される署名済みトランザクションを送信する。この送信は、コンピュータ102を介して、またはPUFデバイス600の組み込みネットワークインターフェースから直接行うことができる。
いくつかの実施形態では、鍵導出アルゴリズムはノンス値の関数でもある。この場合、ステップP2で、ユーザ103は、入力チャレンジCとともにノンス値をPUFデバイス600に入力することもできる。これにより、シードに基づいて一意のワンタイムキーを導出できるようになる。これは、考えられるすべての実装において必須ではなく、また、使用する場合、ノンスをユーザが提供する必要は必ずしもない(たとえば、デバイス上の増分カウンタであることがある)が、場合によっては、ユーザがキーの導出に使用されるノンスを指定することもある。
図6A/7および6B/8の両方の方法において、好ましくは、ユーザは、対応する応答Rではなく、使用された入力チャレンジCのみを格納、書き留め、または記憶し、その後、実際の子キーを導出するために必要になったときに、後で応答を再度生成するために、PUFデバイスを使用して再実行する。実施形態では、ユーザがRを書き留め、代わりにそれをウォレットアプリケーションに再入力することを阻止するものは何もないこともある-ウォレットアプリケーションは、Rがどのように導出されたのかを知らず、Rがデバイス外にどのように格納されたかを気にしない。ただし、ユーザはセキュリティ上の理由から、すなわち、攻撃者がPUFにアクセスせずにRを侵害するのを避けるために、Rを格納したり書き留めたりしないように奨励されている。
4. 例示的なブロックチェーンシステム
次に、図6Aまたは図6Bのシステムおよび図7または図8の方法が本開示のいくつかの実施形態において展開され得る、例示的なより広いブロックチェーンシステムを説明する。「アリス」および「ボブ」は、2つの当事者に対する任意の名前にすぎず、アリスおよびボブは、彼らが行い得るいくつかのシナリオにわたって、この節では前の節または次の節と必ずしも同じ役割を有するわけではない。
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、102bの各々の上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、アリス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. 結論
開示された技術の他の変更形態またはユースケースは、本明細書において開示を示した後に当業者にとって明らかになるであろう。本開示の範囲は、説明されている実施形態によって限定されず、付属の請求項によってのみ限定される。
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク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.物理複製困難関数(PUF)を有するPUFモジュールを含むPUFデバイスに入力チャレンジを入力するステップであって、PUFデバイスは、入力チャレンジと入力チャレンジの入力に応じたPUFとに基づいて対応する出力応答を生成するように構成される、ステップと、入力チャレンジの入力に応じてPUFデバイスによって生成された出力応答から決定されたシードを使用するためにウォレットアプリケーションをインスタンス化するステップであって、インスタンス化することは、ウォレットアプリケーションに関連してシードまたは出力応答の変換を格納することを含む、ステップと、その後、ユーザがシードを使用する権利を示す情報をウォレットアプリケーションに供給するステップであって、ウォレットアプリケーションは、ウォレットアプリケーションに関連して格納されている変換に基づいて情報を検証すること応じて、かつそれによって情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成される、ステップと、検証に応じてウォレットアプリケーションによって導出された子キーを使用してブロックチェーントランザクションに署名し、かつブロックチェーンに記録されるために署名済みブロックチェーントランザクションを送信するステップとを備える、方法。
ステートメント2.情報は、ユーザがPUFデバイスに入力チャレンジのインスタンスを再入力することによって生成された出力応答の再生成されたインスタンスを含む、請求項1に記載の方法。
ステートメント3.シードが、出力チャレンジに等しい、請求項1または2に記載の方法。
ステートメント4.シードが、出力チャレンジから導出される、請求項1または2に記載の方法。
ステートメント5.出力チャレンジからシードを導出することは、出力応答が異なる長さである、ウォレットアプリケーションに必要な固定シード長のシードを導出することを含む、請求項4に記載の方法。
ステートメント6.変換は、シードまたは出力応答のハッシュまたは他の一方向変換を含む証明書を有し、情報は、シードまたは出力応答の再提出されたインスタンスを含み、ウォレットアプリケーションによる検証は、i)シードまたは出力応答の再提出されたインスタンスに適用された同じ変換が、それぞれシードまたは出力応答の格納された証明書に等しいことを検証すること、あるいはii)出力応答の再提出されたインスタンスからシードを再決定するとともに、再決定されたシードに適用された同じ変換がシードの格納された証明書に等しいことを検証することのいずれかを含む、請求項1～5のいずれか一項に記載の方法。
ステートメント7.シードまたは出力応答の再提出されたインスタンスは、ユーザがPUFデバイスに入力チャレンジのインスタンスを再入力することによって生成された再生成されたインスタンスである、請求項6に記載の方法。
ステートメント8.変換は、シードまたは出力応答の暗号化バージョンを含み、情報は、パスワードまたはパスコードを含み、ウォレットアプリケーションによる検証は、供給されたパスワードまたはパスコードを検証するとともに、その条件に応じてシードまたは出力応答の暗号化バージョンを復号することを含む、請求項1～4のいずれか一項に記載の方法。
ステートメント9.パスワードまたはパスコードは、復号キーを含み、検証し、復号することは、供給された復号キーを使用して、シードまたは出力応答の暗号化バージョンを復号することを含む、請求項8に記載の方法。
ステートメント10.ウォレットアプリケーションは、ウォレットアプリケーションと関連して復号キーを格納し、パスワードまたはパスコードは、情報の異なる部分を有し、復号は、復号キーを解放して、供給されたパスワードまたはパスコードを検証する条件でシードまたは出力応答の暗号化バージョンを復号する、請求項8に記載の方法。
ステートメント11.情報は、シードまたは出力応答の再提出されたインスタンスをさらに含み、ウォレットアプリケーションによる検証は、復号されたシードまたは応答がシードまたは出力応答の再提出されたインスタンスにそれぞれ等しいことを検証することをさらに含む、請求項8～10のいずれか一項に記載の方法。
ステートメント12.シードまたは出力応答の再提出されたインスタンスは、ユーザがPUFデバイスに入力チャレンジのインスタンスを再入力することによって生成された再生成されたインスタンスである、請求項11に記載の方法。
ステートメント13.PUFモジュールは、PUFインターフェースロジックおよび決定論的変換関数を備える拡張PUFデバイスを含み、入力チャレンジは、二次チャレンジであり、出力応答は二次応答であり、インターフェースロジックは、一次チャレンジをPUFに入力して、PUFに一次応答を生成させるように構成され、変換関数は、二次チャレンジおよび一次応答の関数として二次応答を生成するように構成され、インターフェースは、PUFデバイスの出力応答として二次応答を返すように構成される、請求項1～12のいずれか一項に記載の方法。
ステートメント14.PUFモジュールがPUFのみから構成され、入力チャレンジおよび出力応答がそれぞれ、PUFの一次チャレンジおよび応答である、請求項1～12のいずれか一項に記載の方法。
ステートメント15.PUFモジュールは、複数の異なる可能なチャレンジ応答のペアを有し、入力チャレンジおよび出力応答が、複数のチャレンジ応答のペアの1つである、請求項13または14のいずれか一項に記載の方法。
ステートメント16.PUFを含むPUFデバイスは、内蔵型ハウジング内に収容されている、請求項1～15のいずれか一項に記載の方法。
ステートメント17.入力チャレンジを入力することは、PUFデバイスのハウジングに一体化されたビルトインユーザインターフェースを介して実行される、請求項16に記載の方法。
ステートメント18.PUFデバイスは、ユーザインターフェース以外の、データを受信するためのインターフェースを持たない、請求項16または17に記載の方法。
ステートメント19.ビルトインユーザインターフェースはキーボードを含む、請求項16または17に記載の方法。
ステートメント20.ウォレットアプリケーションが、PUFデバイスとは別個のハウジングに収容されたコンピュータ上にインストールされ、該コンピュータ上で実行され、シードの変換が、コンピュータ上に格納され、PUFデバイスは、ウォレットアプリケーションがシードの決定を実行するように、コンピュータ上のウォレットアプリケーションに出力応答を出力するために、コンピュータと通信するためのデバイス間インターフェースを備え、ユーザはコンピュータのユーザインターフェースを介して情報を入力し、ブロックチェーントランザクションは、コンピュータ上で署名され、かつブロックチェーン上に記録されるためにコンピュータから送信される、請求項16～19のいずれか一項に記載の方法。
ステートメント21.デバイス間インターフェースが、直接ローカルインターフェースである、請求項20に記載の方法。
ステートメント22.インターフェースが、-コンピュータのUSBポートを介してコンピュータに接続するためのUSBコネクタ、または-コンピュータのカメラまたはスキャナによって読み取られるための、出力応答をグラフィック形式で表示するように構成されたスクリーンの1つを含む、請求項19または21に記載の方法。
ステートメント23.ウォレットアプリケーションが、PUFデバイス内に一体化され、シードの変換が、PUFデバイス内に格納され、入力チャレンジを入力することは、PUFデバイスのハウジング内に一体化されたビルトインユーザインターフェースを介して実行され、ユーザは、PUFデバイスのビルトインユーザインターフェースを介して情報を入力し、ブロックチェーントランザクションは、PUFデバイス上で署名され、ブロックチェーンに記録されるために、PUFデバイスから送信される、請求項16～19のいずれか一項に記載の方法。
ステートメント24.ブロックチェーントランザクションは、PUFデバイスのローカルインターフェースを介して別個のコンピュータに送信され、次いで、コンピュータのネットワークインターフェースを介してさらに送信される、請求項23に記載の方法。
ステートメント25.ブロックチェーントランザクションは、PUFデバイス内に一体化されたネットワークインターフェースを介して直接送信される、請求項23に記載の方法。
ステートメント26.出力応答は、コンピュータ上に格納されず、あるいは少なくとも明らかな状態で格納されない、請求項20～25のいずれか一項に記載の方法。
ステートメント27.PUFデバイスのハウジングは、ロックされるか密封されている、請求項16～26のいずれか一項に記載の方法。
ステートメント28.出力応答は、どこにも格納されず、あるいは少なくとも明らかな状態で格納されない、請求項1～27のいずれか一項に記載の方法。
ステートメント29.入力チャレンジは、BIP32ニーモニックフレーズあるいは入力チャレンジの数値にマップされた他のニーモニックフレーズの形式で入力され、数値は、出力応答を生成するためにPUFデバイスによって使用される、請求項1～28のいずれか一項に記載の方法。
ステートメント30.同じハウジング内に一体化されたPUFデバイスであって、入力チャレンジを入力するための内蔵型ユーザインターフェースと、物理複製困難関数(PUF)モジュールであって、PUFデバイスは、入力チャレンジと入力チャレンジの入力に応じたPUFとに基づいて対応する出力応答を生成するように構成される、PUFモジュールと、1つまたは複数のメモリユニットを有する組み込みメモリと、組み込みメモリの一部に格納されたブロックチェーンウォレットアプリケーションを実行するように構成された組み込みプロセッサであって、ブロックチェーンウォレットアプリケーションは、PUFデバイスによって生成された出力チャレンジから決定されたシードを使用するためにインスタンス化されるように構成され、インスタンス化することが、組み込みメモリの一部にシードまたは出力応答の変換を格納する、組み込みプロセッサとを備え、ウォレットアプリケーションは、シードを使用する権利を示す情報をユーザから受信するようにさらに動作可能であり、ウォレットアプリケーションは、ウォレットアプリケーションに関連して格納されている変換に基づいて情報を検証すること応じて、かつそれによって情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成され、ウォレットアプリケーションは、検証に応じてウォレットアプリケーションによって導出された子キーを使用してブロックチェーントランザクションに署名するように動作可能であり、PUFデバイスは、ブロックチェーンに記録されるために署名済みブロックチェーントランザクションを送信するように構成されたデータインターフェースをさらに備える、PUFデバイス。
100 システム
101 パケット交換ネットワーク
102 コンピュータ機器
102a コンピュータ機器
102b コンピュータ機器
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 変換ロジック

Claims (30)

  1. 物理複製困難関数(PUF)を有するPUFモジュールを含むPUFデバイスに入力チャレンジを入力するステップであって、前記PUFデバイスは、前記入力チャレンジと前記入力チャレンジの入力に応じた前記PUFとに基づいて対応する出力応答を生成するように構成される、ステップと、
    前記入力チャレンジの前記入力に応じて前記PUFデバイスによって生成された前記出力応答から決定されたシードを使用するためにウォレットアプリケーションをインスタンス化するステップであって、前記インスタンス化することは、前記ウォレットアプリケーションに関連して前記シードまたは出力応答の変換を格納することを含む、ステップと、
    その後、ユーザが前記シードを使用する権利を示す情報を前記ウォレットアプリケーションに供給するステップであって、前記ウォレットアプリケーションは、前記ウォレットアプリケーションに関連して格納されている前記変換に基づいて前記情報を検証すること応じて、かつそれによって前記情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成される、ステップと、
    前記検証に応じて前記ウォレットアプリケーションによって導出された前記子キーを使用してブロックチェーントランザクションに署名し、かつブロックチェーンに記録されるために署名済みブロックチェーントランザクションを送信するステップと
    を備える、方法。
  2. 前記情報は、前記ユーザが前記PUFデバイスに前記入力チャレンジのインスタンスを再入力することによって生成された前記出力応答の再生成されたインスタンスを含む、請求項1に記載の方法。
  3. 前記シードが、前記出力チャレンジに等しい、請求項1または2に記載の方法。
  4. 前記シードが、前記出力チャレンジから導出される、請求項1または2に記載の方法。
  5. 前記出力チャレンジから前記シードを導出することは、前記出力応答が異なる長さである、前記ウォレットアプリケーションに必要な固定シード長のシードを導出することを含む、請求項4に記載の方法。
  6. 前記変換は、前記シードまたは出力応答のハッシュまたは他の一方向変換を含む証明書を有し、前記情報は、前記シードまたは出力応答の再提出されたインスタンスを含み、前記ウォレットアプリケーションによる検証は、i)前記シードまたは出力応答の前記再提出されたインスタンスに適用された同じ変換が、それぞれ前記シードまたは出力応答の前記格納された証明書に等しいことを検証すること、あるいはii)前記出力応答の前記再提出されたインスタンスから前記シードを再決定するとともに、前記再決定されたシードに適用された同じ変換が前記シードの前記格納された証明書に等しいことを検証することのいずれかを含む、請求項1～5のいずれか一項に記載の方法。
  7. 前記シードまたは出力応答の前記再提出されたインスタンスは、前記ユーザが前記PUFデバイスに前記入力チャレンジのインスタンスを再入力することによって生成された再生成されたインスタンスである、請求項6に記載の方法。
  8. 前記変換は、前記シードまたは出力応答の暗号化バージョンを含み、前記情報は、パスワードまたはパスコードを含み、前記ウォレットアプリケーションによる前記検証は、供給されたパスワードまたはパスコードを検証するとともに、その条件に応じて前記シードまたは出力応答の前記暗号化バージョンを復号することを含む、請求項1～4のいずれか一項に記載の方法。
  9. 前記パスワードまたはパスコードは、復号キーを含み、前記検証し、復号することは、前記供給された復号キーを使用して、前記シードまたは出力応答の前記暗号化バージョンを復号することを含む、請求項8に記載の方法。
  10. 前記ウォレットアプリケーションは、前記ウォレットアプリケーションと関連して復号キーを格納し、前記パスワードまたはパスコードは、情報の異なる部分を有し、前記復号は、前記復号キーを解放して、前記供給されたパスワードまたはパスコードを検証する条件で前記シードまたは出力応答の前記暗号化バージョンを復号する、請求項8に記載の方法。
  11. 前記情報は、前記シードまたは出力応答の再提出されたインスタンスをさらに含み、前記ウォレットアプリケーションによる前記検証は、前記復号されたシードまたは応答が前記シードまたは出力応答の前記再提出されたインスタンスにそれぞれ等しいことを検証することをさらに含む、請求項8～10のいずれか一項に記載の方法。
  12. 前記シードまたは出力応答の前記再提出されたインスタンスは、前記ユーザが前記PUFデバイスに前記入力チャレンジのインスタンスを再入力することによって生成された再生成されたインスタンスである、請求項11に記載の方法。
  13. 前記PUFモジュールは、前記PUFインターフェースロジックおよび決定論的変換関数を備える拡張PUFデバイスを含み、前記入力チャレンジは、二次チャレンジであり、前記出力応答は二次応答であり、前記インターフェースロジックは、一次チャレンジを前記PUFに入力して、前記PUFに一次応答を生成させるように構成され、前記変換関数は、前記二次チャレンジおよび一次応答の関数として前記二次応答を生成するように構成され、前記インターフェースは、前記PUFデバイスの前記出力応答として前記二次応答を返すように構成される、請求項1～12のいずれか一項に記載の方法。
  14. 前記PUFモジュールがPUFのみから構成され、前記入力チャレンジおよび出力応答がそれぞれ、前記PUFの一次チャレンジおよび応答である、請求項1～12のいずれか一項に記載の方法。
  15. 前記PUFモジュールは、複数の異なる可能なチャレンジ応答のペアを有し、前記入力チャレンジおよび出力応答が、前記複数のチャレンジ応答のペアの1つである、請求項13または14のいずれか一項に記載の方法。
  16. 前記PUFを含む前記PUFデバイスは、内蔵型ハウジング内に収容されている、請求項1～15のいずれか一項に記載の方法。
  17. 前記入力チャレンジを入力することは、前記PUFデバイスの前記ハウジングに一体化されたビルトインユーザインターフェースを介して実行される、請求項16に記載の方法。
  18. 前記PUFデバイスは、前記ユーザインターフェース以外の、データを受信するためのインターフェースを持たない、請求項16または17に記載の方法。
  19. 前記ビルトインユーザインターフェースはキーボードを含む、請求項16または17に記載の方法。
  20. 前記ウォレットアプリケーションが、前記PUFデバイスとは別個のハウジングに収容されたコンピュータ上にインストールされ、該コンピュータ上で実行され、前記シードの前記変換が、前記コンピュータ上に格納され、前記PUFデバイスは、前記ウォレットアプリケーションが前記シードの前記決定を実行するように、前記コンピュータ上の前記ウォレットアプリケーションに前記出力応答を出力するために、前記コンピュータと通信するためのデバイス間インターフェースを備え、ユーザは前記コンピュータのユーザインターフェースを介して前記情報を入力し、前記ブロックチェーントランザクションは、前記コンピュータ上で署名され、かつ前記ブロックチェーン上に記録されるために前記コンピュータから送信される、請求項16～19のいずれか一項に記載の方法。
  21. 前記デバイス間インターフェースが、直接ローカルインターフェースである、請求項20に記載の方法。
  22. 前記インターフェースが、
    - 前記コンピュータのUSBポートを介して前記コンピュータに接続するためのUSBコネクタ、または
    - 前記コンピュータのカメラまたはスキャナによって読み取られるための、前記出力応答をグラフィック形式で表示するように構成されたスクリーン
    の1つを含む、請求項19または21に記載の方法。
  23. 前記ウォレットアプリケーションが、前記PUFデバイス内に一体化され、前記シードの前記変換が、前記PUFデバイス内に格納され、前記入力チャレンジを入力することは、前記PUFデバイスの前記ハウジング内に一体化されたビルトインユーザインターフェースを介して実行され、ユーザは、前記PUFデバイスの前記ビルトインユーザインターフェースを介して前記情報を入力し、前記ブロックチェーントランザクションは、前記PUFデバイス上で署名され、前記ブロックチェーンに記録されるために、前記PUFデバイスから送信される、請求項16～19のいずれか一項に記載の方法。
  24. 前記ブロックチェーントランザクションは、前記PUFデバイスのローカルインターフェースを介して別個のコンピュータに送信され、次いで、前記コンピュータのネットワークインターフェースを介してさらに送信される、請求項23に記載の方法。
  25. 前記ブロックチェーントランザクションは、前記PUFデバイス内に一体化されたネットワークインターフェースを介して直接送信される、請求項23に記載の方法。
  26. 前記出力応答は、前記コンピュータ上に格納されず、あるいは少なくとも明らかな状態で格納されない、請求項20～25のいずれか一項に記載の方法。
  27. 前記PUFデバイスの前記ハウジングは、ロックされるか密封されている、請求項16～26のいずれか一項に記載の方法。
  28. 前記出力応答は、どこにも格納されず、あるいは少なくとも明らかな状態で格納されない、請求項1～27のいずれか一項に記載の方法。
  29. 前記入力チャレンジは、BIP32ニーモニックフレーズあるいは前記入力チャレンジの数値にマップされた他のニーモニックフレーズの形式で入力され、前記数値は、前記出力応答を生成するために前記PUFデバイスによって使用される、請求項1～28のいずれか一項に記載の方法。
  30. 同じハウジング内に一体化されたPUFデバイスであって、
    入力チャレンジを入力するためのビルトインユーザインターフェースと、
    物理複製困難関数(PUF)モジュールであって、前記PUFデバイスは、前記入力チャレンジと前記入力チャレンジの入力に応じた前記PUFとに基づいて対応する出力応答を生成するように構成される、PUFモジュールと、
    1つまたは複数のメモリユニットを有する組み込みメモリと、
    前記組み込みメモリの一部に格納されたブロックチェーンウォレットアプリケーションを実行するように構成された組み込みプロセッサであって、前記ブロックチェーンウォレットアプリケーションは、前記PUFデバイスによって生成された前記出力チャレンジから決定されたシードを使用するためにインスタンス化されるように構成され、前記インスタンス化することが、前記組み込みメモリの一部に前記シードまたは出力応答の変換を格納する、組み込みプロセッサとを備え、
    前記ウォレットアプリケーションは、前記シードを使用する権利を示す情報をユーザから受信するようにさらに動作可能であり、
    前記ウォレットアプリケーションは、前記ウォレットアプリケーションに関連して格納されている前記変換に基づいて前記情報を検証すること応じて、かつそれによって前記情報が検証されたという条件で、シードから少なくとも1つの子キーを導出するように構成され、
    前記ウォレットアプリケーションは、前記検証に応じて前記ウォレットアプリケーションによって導出された前記子キーを使用してブロックチェーントランザクションに署名するように動作可能であり、
    前記PUFデバイスは、ブロックチェーンに記録されるために署名済みブロックチェーントランザクションを送信するように構成されたデータインターフェースをさらに備える、PUFデバイス。
JP2023570001A 2021-05-12 2022-04-12 ウォレットアプリケーションのインスタンス化、およびｐｕｆデバイスを使用したブロックチェーントランザクションに署名するための鍵の導出 Pending JP2024518523A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2106721.0A GB2606709A (en) 2021-05-12 2021-05-12 PUF device
GB2106721.0 2021-05-12
PCT/EP2022/059690 WO2022238071A1 (en) 2021-05-12 2022-04-12 Wallet application instantiation, keys derivation for signing blockchain transactions using a puf device

Publications (1)

Publication Number Publication Date
JP2024518523A true JP2024518523A (ja) 2024-05-01

Family

ID=77338691

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023570001A Pending JP2024518523A (ja) 2021-05-12 2022-04-12 ウォレットアプリケーションのインスタンス化、およびｐｕｆデバイスを使用したブロックチェーントランザクションに署名するための鍵の導出

Country Status (7)

Country Link
EP (1) EP4338366A1 (ja)
JP (1) JP2024518523A (ja)
KR (1) KR20240005845A (ja)
CN (1) CN117296295A (ja)
GB (1) GB2606709A (ja)
TW (1) TW202244811A (ja)
WO (1) WO2022238071A1 (ja)

Also Published As

Publication number Publication date
GB2606709A (en) 2022-11-23
CN117296295A (zh) 2023-12-26
WO2022238071A1 (en) 2022-11-17
TW202244811A (zh) 2022-11-16
KR20240005845A (ko) 2024-01-12
EP4338366A1 (en) 2024-03-20

Similar Documents

Publication Publication Date Title
US20230336366A1 (en) Authentication system and method
JP2023545951A (ja) 検証システムおよび方法
US20230362019A1 (en) Physically unclonable functions storing response values on a data store
US20240015033A1 (en) Physically unclonable functions
US20240202718A1 (en) Blockchain based system and method
US20230379175A1 (en) Challenge-response protocol based on physically unclonable functions
US20230370288A1 (en) Physically unclonable functions storing response values on a blockchain
US20240232863A1 (en) Wallet application instantiation, keys derivation for signing blockchain transactions using a puf device
JP2024518523A (ja) ウォレットアプリケーションのインスタンス化、およびｐｕｆデバイスを使用したブロックチェーントランザクションに署名するための鍵の導出
JP2024506738A (ja) ＰＵＦおよびブロックチェーンベースのＩｏＴイベントレコーダおよび方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240213