特表2024-506738ＰＵＦおよびブロックチェーンベースのＩｏＴイベントレコーダおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-14
(54)【発明の名称】ＰＵＦおよびブロックチェーンベースのＩｏＴイベントレコーダおよび方法
(51)【国際特許分類】
H04L 9/10 20060101AFI20240206BHJP
G06F 21/86 20130101ALI20240206BHJP
G06F 21/55 20130101ALI20240206BHJP
【ＦＩ】
H04L9/10 Z
G06F21/86
G06F21/55 320
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023549922
(86)(22)【出願日】2022-01-18
(85)【翻訳文提出日】2023-10-11
(86)【国際出願番号】 EP2022050955
(87)【国際公開番号】W WO2022175001
(87)【国際公開日】2022-08-25
(31)【優先権主張番号】2102283.5
(32)【優先日】2021-02-18
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ジャック・オーウェン・デイヴィーズ
(72)【発明者】
【氏名】クレイグ・スティーヴン・ライト
(57)【要約】
本明細書に開示される第1の態様によれば、PUFモジュールと、チャレンジをPUFモジュールに入力し、返ってくる応答を受信するための、安全を保証されていないチャネルの少なくとも一部を提供する1つまたは複数の外層コンポーネントとを備えるデバイスが提供される。PUFモジュールの内部ロジックは、ログ媒体、たとえば、ブロックチェーンにチャレンジおよび/または応答の記録を自動的にロギングするように構成されているロギングメカニズムを備える。第2の態様によれば、ブロックチェーン上に記録されるべき第1のメッセージを送信するステップと、第1のメッセージが改ざんなしにブロックチェーン上に記録されていることをチェックするためのクエリを提出するステップと、そうであることを条件として、ブロックチェーン上に記録されるべき第2のメッセージングトランザクションを送信するステップとを含む方法が提供される。第1および第2の態様は、一緒に、または独立して、使用され得る。
【特許請求の範囲】
【請求項1】
デバイスであって、物理複製困難関数(PUF)と、入力チャレンジを受信し、前記入力チャレンジの確定関数である出力応答を出力するように構成されている内部PUFインターフェースロジックとを含むPUFモジュールであって、前記確定関数が前記PUFを含む、PUFモジュールと、
前記PUFモジュールの前記内部PUFインターフェースロジックに前記入力チャレンジを入力し、前記内部PUFインターフェースロジックによって出力されて返ってくる前記出力応答を受信するための安全を保証されていないチャネルの少なくとも一部を提供する1つまたは複数の外層コンポーネントと
を備え、
前記1つまたは複数の外層コンポーネントのうちの少なくとも1つは、悪意あるプロセスによる前記入力チャレンジおよび/または出力応答の改ざんの影響を受けやすいが、前記内部PUFインターフェースロジックを含む前記PUFモジュールは、前記デバイスのハウジング内に封入され、前記1つまたは複数の外層コンポーネントから分離され、前記悪意あるプロセスによる改ざんから保護され、
前記内部PUFインターフェースロジックは、前記入力チャレンジおよび/または出力応答の記録をログ媒体に自動的にロギングするように構成されているロギングメカニズムを備える、デバイス。
【請求項2】
前記内部PUFインターフェースロジックは、前記デバイスのプロセッサ上で実行されるファームウェアにおいて部分的にまたは全体的に実装される、請求項1に記載のデバイス。
【請求項3】
前記ファームウェアは、リードオンリメモリ(ROM)に部分的にまたは全体的に記憶される、請求項2に記載のデバイス。
【請求項4】
ファームウェアは、安全なカーネルにおいて部分的にまたは全体的に実装される、請求項1または2に記載のデバイス。
【請求項5】
前記内部PUFインターフェースロジックは、固定関数ハードウェア回路において実装される、請求項1から4のいずれか一項に記載のデバイス。
【請求項6】
前記少なくとも1つの外層コンポーネントは、前記デバイスの外部のソースから前記入力チャレンジを入力するため、および/または前記デバイスの外部の宛先へ前記出力応答を供給するための外部インターフェースを備え、前記少なくとも1つの外層コンポーネントが影響を受けやすい前記悪意あるプロセスは、前記ソースと前記外部インターフェースとの間での前記入力チャレンジおよび/または出力応答の妨害および改ざんを含む、請求項1から5のいずれか一項に記載のデバイス。
【請求項7】
前記ソースは、前記デバイスにローカルであり、前記外部インターフェースは、ネットワークを通じた伝送なしに前記入力チャレンジを受信するように動作可能である、請求項6に記載のデバイス。
【請求項8】
前記ソースは、前記デバイスのリモートにあり、前記外部インターフェースは、ネットワークを介して前記ソースから前記入力チャレンジを受信するように動作可能である、請求項6に記載のデバイス。
【請求項9】
専用PUFデバイスを備える、請求項6から8のいずれか一項に記載のデバイス。
【請求項10】
前記少なくとも1つの外層コンポーネントは、前記デバイスの前記ハウジング内のプロセッサ上で実行するアプリケーションを備え、前記アプリケーションは、前記入力チャレンジを生成するように構成され、
前記少なくとも1つの外層コンポーネントが影響を受けやすい前記悪意あるプロセスは、前記入力チャレンジを改ざんするために前記アプリケーションと同じプロセッサ上で実行されるマルウェアを含む、請求項1から8のいずれか一項に記載のデバイス。
【請求項11】
前記内部PUFインターフェースロジックは、前記アプリケーションとは別のプロセッサ上で実行するように構成される、請求項10に記載のデバイス。
【請求項12】
前記内部PUFインターフェースロジックは、前記アプリケーションと同じプロセッサ上で、しかしながら安全なプロセッサの特権付きドメイン内で実行するように構成される一方、前記アプリケーションは、アプリケーションドメイン内で実行する、請求項10に記載のデバイス。
【請求項13】
前記デバイスは、イベントデータレコーダ(EDR)を備え、前記アプリケーションは、EDRアプリケーションを備える、請求項10から12のいずれか一項に記載のデバイス。
【請求項14】
前記アプリケーションは、前記EDRが監視するように構成されるシステムの結果を生成するように構成され、前記EDRは、前記結果と、前記出力応答を前記結果にマッピングするタグとを記録するように構成される、請求項13に記載のデバイス。
【請求項15】
前記タグは、前記出力応答で前記結果に署名することによって生成される暗号署名、または前記結果および前記出力応答の関数として生成されるハッシュベースのメッセージ認証コード(HMAC)を含む、請求項14に記載のデバイス。
【請求項16】
前記入力チャレンジは、前記システムの状態が監視されていることを表す、前記アプリケーションによって使用される意味のあるデータを含む、請求項14または15に記載のデバイス。
【請求項17】
前記結果は、前記データに依存する、請求項16に記載のデバイス。
【請求項18】
前記EDRは、車両のためのEDRであり、前記EDRが監視するように構成される前記システムは、前記車両のシステムを含む、請求項14から17のいずれか一項に記載のデバイス。
【請求項19】
前記1つまたは複数の外層コンポーネントは、前記PUFモジュールと同じハウジングにおいて実装される、請求項1から18のいずれか一項に記載のデバイス。
【請求項20】
前記PUFモジュールは、拡張PUFモジュールを含み、前記入力チャレンジは、二次チャレンジであり、前記出力応答は、二次応答であり、前記内部PUFインターフェースロジックは、一次応答を生成するために前記PUF内にチャレンジを入力し、前記二次応答を前記一次応答および前記二次チャレンジの決定論的変換として決定するように構成される、請求項1から19のいずれか一項に記載のデバイス。
【請求項21】
前記決定論的変換は、ハッシュ関数を含む、請求項20に記載のデバイス。
【請求項22】
前記内部PUFインターフェースロジックは、前記入力チャレンジを前記PUFに直接的に入力し、入力応答の関数として前記出力応答を前記PUFから直接的に受信するように構成される、請求項1から19のいずれか一項に記載のデバイス。
【請求項23】
前記ログ媒体は、前記デバイスのローカルメモリを含む、請求項1から22のいずれか一項に記載のデバイス。
【請求項24】
前記ローカルメモリは、改ざん防止メモリ、1回だけ書き込み可能なメモリである、および/または前記内部PUFインターフェースロジックに埋め込まれる、請求項23に記載のデバイス。
【請求項25】
前記内部PUFインターフェースロジックが記録をロギングするように構成される前記ログ媒体は、前記デバイスの外部の公的にアクセス可能な媒体を含む、請求項1から24のいずれか一項に記載のデバイス。
【請求項26】
前記内部PUFインターフェースロジックが前記記録をロギングするように構成される前記公的にアクセス可能な媒体は、ブロックチェーンを含む、請求項25に記載のデバイス。
【請求項27】
前記内部PUFインターフェースロジックは、個々の入力チャレンジの入力に応答して前記記録のロギングをリアルタイムで実施するように構成される、請求項1から26のいずれか一項に記載のデバイス。
【請求項28】
前記内部PUFインターフェースロジックは、定期的な時間窓の各インスタンスの間、任意の受信される入力チャレンジおよび/または生成される出力応答を定期的にロギングするように構成される、請求項1から27のいずれか一項に記載のデバイス。
【請求項29】
前記内部PUFインターフェースロジックは、個々の入力チャレンジの入力に応答して前記記録をローカルメモリにリアルタイムでロギングするように、および、公的にアクセス可能な媒体への定期的なロギングを実施するように構成される、請求項23、25、および27のいずれか一項に従属する請求項28に記載のデバイス。
【請求項30】
前記ロギングメカニズムは、前記公的にアクセス可能な媒体に一旦ロギングされると、前記ロギングされたチャレンジおよび/または応答を前記ローカルメモリから定期的にクリアするようにさらに構成される、請求項29に記載のデバイス。
【請求項31】
前記ロギングメカニズムは、個々の入力チャレンジの入力に応答して前記記録を公的にアクセス可能な媒体にリアルタイムでロギングするように構成される、請求項25、または請求項25に従属する請求項26から30のいずれか一項に記載のデバイス。
【請求項32】
前記内部PUFインターフェースロジックは、少なくとも前記入力チャレンジの前記記録をロギングするように構成される、請求項1から31のいずれか一項に記載のデバイス。
【請求項33】
前記内部PUFインターフェースロジックは、少なくとも前記出力応答の前記記録をロギングするように構成される、請求項1から32のいずれか一項に記載のデバイス。
【請求項34】
ロギングメカニズムは、前記記録を、そのロギングのために、パケット内に出力するように構成され、前記パケットは、前記記録を含む前記パケットの少なくとも一部に適用される前記ロギングメカニズムの暗号鍵に基づいて生成される署名をさらに含む、請求項1から33のいずれか一項に記載のデバイス。
【請求項35】
前記パケットは、ブロックチェーントランザクションを含み、前記記録は、前記ブロックチェーントランザクションの出力に含まれており、
前記署名は、前記ブロックチェーントランザクションの入力に含まれている、請求項26に従属する請求項34に記載のデバイス。
【請求項36】
請求項1から35のいずれか一項に記載のデバイスを使用する方法であって、前記入力チャレンジおよび/または出力応答の記録が前記ログ媒体にロギングされた後、前記PUFモジュールに候補応答を生成させ、前記安全を保証されていないチャネルを介して前記候補応答を返すために、前記1つまたは複数の外層コンポーネントの前記安全を保証されていないチャネルを介して前記デバイスに候補チャレンジを入力するステップと、
前記ログ媒体にロギングされた元の入力チャレンジの記録に対して前記候補チャレンジをチェックすることによって、および/または、前記ログ媒体にロギングされた元の出力応答の記録に対して前記候補応答をチェックすることによって、改ざんの証拠をチェックするステップと
を含む、方法。
【請求項37】
前記チェックするステップは、前記候補チャレンジが、前記ログ媒体に記録された際の入力チャレンジの記録に一致することをチェックすることを少なくとも含む、請求項36に記載の方法。
【請求項38】
前記内部PUFインターフェースロジックは、前記候補応答の記録をロギングするようにさらに構成され、前記チェックするステップは、前記候補応答の前記ロギングされた記録が、前記デバイスに入力された際の前記候補応答に一致することをチェックすることを少なくとも含む、請求項36または37に記載の方法。
【請求項39】
前記チェックするステップは、前記候補応答が、前記ログ媒体に記録された際の前記元の出力応答の記録に一致することをチェックすることを少なくとも含む、請求項36から38のいずれか一項に記載の方法。
【請求項40】
前記方法は、請求項14またはそれに従属する任意のデバイス請求項のデバイスを使用する方法であり、前記方法は、候補結果に基づいて前記タグを検証することによって、前記デバイスが、前記結果をもたらしたデバイスであることを検証するステップを含む、請求項36から39のいずれか一項に記載の方法。
【請求項41】
1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置と
を備え、前記メモリは、前記処理装置上で実行するように構成されているコードを記憶し、前記コードは前記処理装置において請求項36から40のいずれか一項に記載の前記方法を実行するように構成される、コンピュータ機器。
【請求項42】
非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されると、請求項36から40のいずれか一項に記載の前記方法を実行するように構成されているコンピュータプログラム。
【請求項43】
コンピュータ実装方法であって、第1のエンティティによって、ブロックチェーン上に記録されるべき第1のメッセージングトランザクションを送信するステップであって、前記第1のメッセージングトランザクションは、第1のメッセージ、および、第2のエンティティが前記ブロックチェーン上の前記第1のメッセージを識別することができるように、前記第1のメッセージを前記第2のエンティティに向けるそれぞれの情報を含む、ステップと、
前記第1のメッセージが改ざんなしに前記ブロックチェーン上に記録されていることをチェックするためのクエリを提出するステップと、
前記第1のメッセージが、前記クエリに従って、改ざんなしに前記ブロックチェーン上に記録されていることが決定されるという条件で、前記ブロックチェーン上に記録されるべき第2のメッセージングトランザクションを送信するステップであって、前記第2のメッセージングトランザクションは、第2のメッセージ、および、前記第2のエンティティが前記ブロックチェーン上の前記第1のメッセージを識別することができるように、前記第2のメッセージを第2のエンティティに向けるそれぞれの情報を含む、ステップと
を含む、コンピュータ実装方法。
【請求項44】
前記第1のメッセージングトランザクションは、第1の資金トランザクションの出力を指し示す入力を含み、前記第2のメッセージングトランザクションは、第2の資金トランザクションの出力を指し示す入力を含み、前記第1のメッセージングトランザクションの任意の出力を指し示す入力を含まない、請求項43に記載の方法。
【請求項45】
前記第1のメッセージおよび前記第2のメッセージは、2つ以上のメッセージのシーケンスにおける連続メッセージであり、各々が前記シーケンス内に関連インデックスを有し、
各々が前記ブロックチェーン上に記録されるべき前記第1のエンティティによるそれぞれのメッセージングトランザクションにおいて送信され、
各々のメッセージングトランザクションが、前記第2のエンティティが前記ブロックチェーン上のメッセージを識別することを可能にするそれぞれの情報を含み、
各メッセージ内の前記それぞれの情報は、i)関連インデックスと、ii)前記シーケンス内の第1のフラグまたは先行フラグとの関数であるフラグを含み、
前記関数の形態は、前記第1のエンティティおよび前記第2のエンティティの各々に知られており、
前記方法は、前記第1のエンティティおよび前記第2のエンティティが前記第1のメッセージの前記フラグに合意し、これにより、それらが、前記関数の前記形態、前記第1のフラグ、および各メッセージの前記関連インデックスに基づいて、前記メッセージのシーケンスを使用して前記ブロックチェーンを介して連続して通信することを可能にする初期セットアップフェーズを含む、請求項43または44に記載の方法。
【請求項46】
1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置と
を備え、前記メモリは、前記処理装置上で実行するように構成されているコードを記憶し、前記コードは前記処理装置において請求項43から45のいずれか一項に記載の前記方法を実行するように構成される、コンピュータ機器。
【請求項47】
非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されると、請求項43から45のいずれか一項に記載の前記方法を実行するように構成されているコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の1つの態様は、物理複製困難関数、すなわちPUFの分野に関する。別の態様は、ブロックチェーンを介した安全な通信に関する。
【背景技術】
【0002】
物理複製困難関数(PUF)は、決定論的であるが予測不可能な物理現象を含む関数を指す用語である。PUFは、ときには物理的乱数関数とも称される。PUFは、「チャレンジ」と称される入力を受け取り、チャレンジおよびPUFによって採用される物理現象に応じて、対応する「応答」と称される出力を生成する。PUFは、ときには強いPUFと弱いPUFに分類される。強いPUFは、多数の異なるチャレンジに対してそれぞれの応答を生成することができ、典型的には、チャレンジの任意の値を取ることができる。弱いPUFは、単一の応答のみ、または少数の応答に対して応答を生成することができる(典型的には、チャレンジは任意の値を取ることができない)。言い換えると、強いPUFは多数のチャレンジ応答ペア(challenge-response pair)を有し(それは大きなチャレンジ応答空間を有し)、その一方で、弱いPUFは単一のチャレンジ応答ペアまたは限られた数のチャレンジ応答ペア(小さいまたは限られたチャレンジ応答空間)を有する。一定義によれば、弱いPUFは、チャレンジビットの数に対して線形に増大する多数の応答、またはより一般的には、チャレンジビットの数もしくは任意の他のパラメータに対して線形以上に増大しない応答を有する(言い換えると、弱いPUFは、そのチャレンジ応答空間をスケールアップさせることができない、すなわち、最大でもチャレンジ応答空間は線形にスケーリングする)。
【0003】
強いPUFの知られている例は、光学的PUFである。たとえば、光学的PUFは、レーザー、光学センサ、および気泡または他のそのようなアーティファクトが媒体中にセットされた固体光学媒体を含み得る。レーザーは、制御可能な角度で光学媒体を通して照射され、回折または散乱パターン(媒体中の気泡またはアーティファクトの効果である)を生成する。センサは、このパターンを感知するように配置構成される。チャレンジは、レーザーの角度であり、応答は、感知されたパターンに基づき生成される。
【0004】
弱いPUFの例は、SRAM PUFである。この場合、チャレンジは、SRAM(スタティックランダムアクセスメモリ)の電源を入れることである。SRAM毎に製造上のわずかな違いがあるので、電源投入時にSRAMセルが0/1状態の固有のパターンに入り、それにより個々のSRAMの特徴的なフィンガープリントを形成する。PUFは、これを電源投入後の応答として出力するように構成される。
【0005】
PUFは、暗号アルゴリズムにおいて使用する(たとえば、文書に署名する、または暗号化する)などのための鍵を生成する手段として使用され得る。PUFの別の用途は、PUFを組み込んだコンピュータデバイスなどのデバイスの識別である。所与のチャレンジに対する期待される応答が以前に決定されている場合、検証者は、後でターゲットデバイスにチャレンジを挑み、それが期待される応答を与えるかどうかをチェックし、それによってターゲットデバイスが期待される応答に関連付けられているデバイスであるかどうかをチェックすることができる。
【0006】
チャレンジ応答空間が限られているので、弱いPUFへの入力出力(i/o)インターフェースは、1つまたは限られた数の当事者のみに制限される傾向がある(たとえば、1つまたは限られた数の信頼できる当事者のみがPUFへのアクセスを物理的にまたは合法的に付与され得るか、またはPUFへのインターフェースがパスワード保護されるか、または同様のことが行われ得る)。すなわち、注目する1人または複数の当事者のみが、チャレンジを提出する必要があるPUFへの入力および返された応答の受け取りに使用される出力へのアクセスを得ることができる。その一方で、強いPUFでは、強いPUFへのi/oインターフェースは、多数の、または無制限の数の当事者に対して広く利用可能にされ得るが、それらのすべてが必ずしも、知られている当事者または信頼できる当事者とは限らない。その理由は、チャレンジ応答空間が十分に大きく、敵対者がチャレンジ応答ペアのすべてを列挙することは実行不可能であり、したがって、敵対者がPUFに自由にアクセスする能力は、弱いPUFの場合のように、PUFの列挙およびスプーフィングを許すことによってそのセキュリティを損なうことはないはずだからである。
【0007】
異なる技術分野では、ブロックチェーンは、ブロックチェーンの複製が分散ピアツーピア(P2P)ネットワーク(以下、「ブロックチェーンネットワーク」と称される)内の複数のノードの各々において維持され、広く公開される分散データ構造の一形態を指す。ブロックチェーンは、データのブロックのチェーンを含み、各ブロックは、1つまたは複数のトランザクションを含む。いわゆる「コインベーストランザクション」以外の、各トランザクションは、1つまたは複数のコインベーストランザクションに遡る1つまたは複数のブロックにまたがり得るシーケンス内の前のトランザクションを指す。コインベーストランザクションについては後述する。ブロックチェーンネットワークに提出されたトランザクションは、新しいブロックに含まれる。新しいブロックは、しばしば「マイニング」と称されるプロセスによって作成され、このプロセスは複数のノードの各々が「プルーフオブワーク」を実行することを競う、すなわち、ブロックチェーンの新しいブロックに入れられるのを待つ順序付けられ承認された保留トランザクションの定義されたセットの表現に基づく暗号パズルを解くことを競い合うことを伴う。ブロックチェーンはいくつかのノードのところで剪定されることがあり、ブロックの公開は単なるブロックヘッダの公開を通じて達成され得ることに留意されたい。
【0008】
ブロックチェーンにおけるトランザクションは、デジタル資産(すなわち、多数のデジタルトークン)を伝達すること、仮想化台帳(virtualised ledger)またはレジストリ内の一連のエントリを順序付けること、タイムスタンプエントリを受信して処理すること、および/またはインデックスポインタを時間順序付けする(time-order)ことのうちの1つまたは複数の目的に使用され得る。ブロックチェーンは、また、ブロックチェーンの上に追加の機能を層化するために利用され得る。たとえば、ブロックチェーンプロトコルは、追加のユーザデータまたはデータへのインデックスをトランザクション内に記憶することを可能にし得る。単一のトランザクション内に記憶できる最大データ容量には事前指定された制限はなく、したがって次第により複雑になってゆくデータが組み込まれ得る。たとえば、これは、ブロックチェーンに電子文書を、またはオーディオもしくはビデオデータを記憶するために使用できる。
【0009】
ブロックチェーンネットワークのノード(「マイナー」と称されることが多い)は、分散トランザクション登録および検証プロセスを実行するが、これについては後でさらに詳しく説明することにする。要約すると、このプロセスにおいてノードはトランザクションを承認し、それをブロックテンプレートに挿入し、これに対して有効なプルーフオブワークの解を識別することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに伝播され、それにより各ノードがブロックチェーン上に新しいブロックを記録することを可能にする。ブロックチェーンにトランザクションを記録させるために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)はトランザクションをネットワークのノードの1つに送信し、伝播される。トランザクションを受信したノードは、承認されたトランザクションを新しいブロックに組み込むプルーフオブワークの解を見つけるために競争し得る。各ノードは同じノードプロトコルを強制するように構成されており、これにはトランザクションが有効であるための1つまたは複数の条件を含み得る。無効なトランザクションは伝播されることも、ブロックに組み込まれることもない。トランザクションが承認され、それによってブロックチェーン上に受け入れられたと仮定すると、トランザクション(任意のユーザデータを含む)は、不変の公開記録としてブロックチェーンネットワーク内のノードの各々に登録され、インデックスを付けられたままとなる。
【0010】
最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは、典型的には、デジタル資産の額、すなわちトークンの数を分配する「コインベーストランザクション」と呼ばれる新しいトランザクションで報われる。無効なトランザクションの検出および拒否は、ネットワークのエージェントとして活動する競合ノードの活動によって強制され、違法行為を報告しブロックするインセンティブを与えられる。情報が広く公開されることは、ユーザがノードのパフォーマンスを継続的に監査することを可能にする。単なるブロックヘッダの公開は、参加者がブロックチェーンの継続的整合性を確実にすることを可能にする。
【0011】
「出力ベース」モデル(ときにはUTXOベースモデルと称される)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。任意の消費可能出力は、進行中の一連のトランザクションから導出可能なデジタル資産の額を指定する要素を含む。消費可能出力は、ときにはUTXO(「未使用トランザクション出力」)と称される。出力は、出力の将来の償還のための条件を指定するロックスクリプトをさらに含んでもよい。ロックスクリプトは、デジタルトークンまたは資産を承認して移転するために必要な条件を定義する述語である。(コインベーストランザクション以外の)トランザクションの各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち参照)を含み、さらに、指し示された出力のロックスクリプトをロック解除するためのロック解除スクリプトを含み得る。そこで、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「ターゲット」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定する少なくとも1つの出力を含み、出力をロック解除する1つまたは複数の条件を定義するロックスクリプトを含む。第2のターゲットトランザクションは、第1のトランザクションの出力へのポインタを含む少なくとも1つの入力と、第1のトランザクションの出力をロック解除するためのロック解除スクリプトとを含む。
【0012】
そのようなモデルでは、第2のターゲットトランザクションがブロックチェーンネットワークに送信されてブロックチェーンに伝播され記録されるときに、各ノードで適用される有効性の基準の1つは、ロック解除スクリプトが第1のトランザクションのロックスクリプトで定義された1つまたは複数の条件のすべてを満たすことである。もう1つは、第1のトランザクションの出力が、別の以前の有効なトランザクションによってすでに償還されていないことである。これらの条件のいずれかに従ってターゲットトランザクションが無効であることを発見したノードは、それを(有効なトランザクションとして、しかし場合によっては無効なトランザクションを登録するために)伝播することも、ブロックチェーンに記録されるべき新しいブロックにそれを含めることもしない。
【0013】
トランザクションモデルの代替的タイプはアカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別のノードによって記憶され、常に更新される。
【発明の概要】
【発明が解決しようとする課題】
【0014】
PUFは、イベントデータレコーダ(EDR)(ときには「ブラックボックス」レコーダとも称される)などのデバイス内に埋め込まれ得る。たとえば、これは、特定の結果をもたらしたデバイスのアイデンティティを論証するために、後で捜査または訴訟手続中に使用され得る。しかしながら、デバイスが、たとえばサービス妨害攻撃における、または捜査または手続を妨害するための、チャレンジまたは応答の悪意ある改ざん(manipulation)の影響を受けやすいことがあるという潜在的な問題が存在する。たとえば、スクランブラがデバイスの入力および/もしくは出力に置かれ得、これによりチャレンジをデバイスに入力される前に変換するか、もしくはデバイスによって出力される応答を変換し、または、マルウェアがデバイス上にインストールされ得、これによりそのような変換を内部で実施する。そのような悪意ある改ざんが発生したかどうかを立証する手段を提供することが望ましい。
【課題を解決するための手段】
【0015】
本明細書に開示される第1の態様によれば、PUFモジュールおよび1つまたは複数の外層コンポーネントを備えるデバイスが提供される。PUFモジュールは、物理複製困難関数(PUF)、および、入力チャレンジを受信し、入力チャレンジの確定関数である出力応答を出力するように配置構成されている内部PUFインターフェースロジック、を備え、確定関数はPUFを含む。1つまたは複数の外層コンポーネントは、PUFモジュールの内部インターフェースロジックに入力チャレンジを入力し、内部インターフェースロジックによって出力されて返ってくる出力応答を受信するための、安全を保証されていないチャネルの少なくとも一部を提供する。外層コンポーネントのうちの少なくとも1つは、悪意あるプロセスによる入力チャレンジおよび/または出力応答の改ざんの影響を受けやすいが、内部PUFインターフェースロジックを含むPUFモジュールは、デバイスのハウジング内に封入され、1つまたは複数の外層コンポーネントから分離され、および故に、悪意あるプロセスによる改ざんから保護される。内部PUFインターフェースロジックは、入力チャレンジおよび/または出力応答の記録をログ媒体に自動的にロギングするように配置構成されているロギングメカニズムを備える。
【0016】
実施形態において、ログ媒体は、デバイスのローカルメモリ、たとえば、改ざん防止メモリ、1回だけ書き込み可能なメモリ、および/またはインターフェースロジック内に埋め込まれているメモリを含み得る。代替的に、ログ媒体は、デバイスの外部の公的にアクセス可能な媒体、たとえば、ブロックチェーンを含み得る。
【0017】
PUFデバイスがオンチェーンで記録をログするとき、または任意の他の送信当事者もしくはデバイスがブロックチェーンを介して受信者と通信しようとするときのいずれかにおいて発生し得る別の潜在的な脆弱性は、通信が、送信者とブロックチェーンとの間で妨害および改ざんされ得ることである。
【0018】
本明細書に開示される第2の態様によれば、第1のエンティティによって、a)ブロックチェーン上に記録されるべき第1のメッセージングトランザクションを送信するステップであって、第1のメッセージングトランザクションは、第1のメッセージ、および、第2のエンティティがブロックチェーン上の第1のメッセージを識別することができるように、第1のメッセージを第2のエンティティに向けるそれぞれの情報を含む、ステップと、b)第1のメッセージが改ざんなしにブロックチェーン上に記録されていることをチェックするためのクエリを提出するステップと、c)第1のメッセージが、前記クエリに従って改ざんなしにブロックチェーン上に記録されていることが決定されるという条件で、ブロックチェーン上に記録されるべき第2のメッセージングトランザクションを送信するステップであって、第2のメッセージングトランザクションは、第2のメッセージ、および、第2のエンティティがブロックチェーン上の第1のメッセージを識別することができるように、第2のメッセージを第2のエンティティに向けるそれぞれの情報を含む、ステップと、を含む、コンピュータ実装方法が提供される。
【0019】
第1および第2の態様は、一緒に、または互いと独立して、使用され得る。
【0020】
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、添付の図面が参照される。
【図面の簡単な説明】
【0021】
【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。
【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例の概略を例示する図である。
【図3】PUFのチャレンジおよび応答の概略を例示する図である。
【図4】PUFを含むシステムの概略ブロック図である。
【図5A】本明細書において開示されている実施形態による拡張PUFの概略ブロック図である。
【図5B】非拡張動作モードにおける拡張PUFの概略ブロック図である。
【図6】チャレンジ応答ペアの配布に信頼できる第三者または出版メディアが関与するシステムの概略図である。
【図7】本明細書において開示される実施形態による検証プロセスの概略フローチャートである。
【図8A】本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。
【図8B】本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。
【図8C】本明細書において開示されている実施形態により、マスターチャレンジからチャレンジのセットを生成する方法の概略を例示する図である。
【図9】チェーン上の応答データの記録する方法の概略を例示する図である。
【図10】埋め込みPUFモジュールを備えるデバイスの概略ブロック図である。
【図11】ブロックチェーン上に記録をロギングするPUFデバイスを示す概略ブロック図である。
【図12】安全でないチャネルおよびブロックチェーンを介した通信を示す概略ブロック図である。
【図13】安全でないチャネルに関わる通信に対して保護を提供するシステムの概略ブロック図である。
【発明を実施するための形態】
【0022】
人間と機械の両方に対する鍵生成システムおよびプライバシー保護アイデンティティシステムなどのシステムのロバスト性は、物理複製困難関数(PUF)の関与によって改善され得る。これらは、互いにやり取りしている当事者および/もしくは自律的機械、またはブロックチェーンなどの公共システムであってもよい。
【0023】
これらの関数は、物理的システムに基づき、物理的デバイスの製造においてランダムな、決定不可能な、および再現不可能な変動があるという仮定によって保証され、人間のアイデンティティとそのデバイスとの間に確立されたリンクを強化するために、またはさらにデバイスそれ自体の偽造不可能な一意のアイデンティティを確立するために使用され得る。
【0024】
文献では、PUFは弱いタイプと強いタイプとに分類され、その異なる特性によって分類される。以下のいくつかの実施形態において、これらのタイプのPUFの両方の利点を有する実用的なPUFデバイスを記述するための一般化拡張PUF(ePUF)フレームワークも提供される。すなわち、ePUFは、実装のために実用性および費用効率を維持しながら、アプリケーションで使用される大きな範囲のチャレンジ応答ペアを生成し得る。
【0025】
より一般的に、PUFおよびチャレンジ応答ペアの管理に関係する様々な態様が本明細書において開示される。これらの異なる態様は、個別に、または任意の組合せで使用されてよい。これらは、たとえば、以下のものを含む。
I. PUFのチャレンジ応答空間を拡張するための拡張PUF、
II. ePUFデバイスを使用することによって人間および/またはデバイスのアイデンティティを確立するためのブロックチェーンにとらわれないプロトコルのセット、
III. ブロックチェーンを活用することによってこれらのアイデンティティプロトコルを改善するためのフレームワーク、
IV. チャレンジ応答ペアの軽量記憶のための技術、
V. PUFベースのモジュールとの使用のためのイベントロギングシステムおよび方法、ならびに
VI. 簡易決済検証(SPV)プロセスのための、およびデバイスによる検証可能計算のための、KYCの実装などの、様々な問題に対するePUFデバイスの新規性のあるアプリケーションのセット。
I. PUFのチャレンジ応答空間を拡張するための拡張PUF、
II. ePUFデバイスを使用することによって人間および/またはデバイスのアイデンティティを確立するためのブロックチェーンにとらわれないプロトコルのセット、
III. ブロックチェーンを活用することによってこれらのアイデンティティプロトコルを改善するためのフレームワーク、
IV. チャレンジ応答ペアの軽量記憶のための技術、
V. PUFベースのモジュールとの使用のためのイベントロギングシステムおよび方法、ならびに
VI. 簡易決済検証(SPV)プロセスのための、およびデバイスによる検証可能計算のための、KYCの実装などの、様々な問題に対するePUFデバイスの新規性のあるアプリケーションのセット。
【0026】
1. 物理複製困難関数(PUF)-前置き
物理複製困難関数(PUF)という用語とは、汎用確率関数として働く物理的システムおよびデバイスのクラスを指す。これらのPUFは、多くの場合にサブミクロンスケールの、その物理的特性によって一意的に特徴付けられ、これは物理的刺激を用いてその特性を調べることによって一意的に識別され、検証され得る。高いレベルでは、PUFをチャレンジを応答にマッピングする関数と考えることができ、そのペアは多くの場合にチャレンジ応答ペア(CRP)と称される。記法
F:C->R∀(C,R)∈ΦF
を使用してそのようなマッピングFを記述することができ、
C、Rはチャレンジおよび応答をそれぞれ表し、ΦFはPUFによって生成され得る形式(C,R)のすべてのチャレンジ応答ペアの集合である。
物理複製困難関数(PUF)という用語とは、汎用確率関数として働く物理的システムおよびデバイスのクラスを指す。これらのPUFは、多くの場合にサブミクロンスケールの、その物理的特性によって一意的に特徴付けられ、これは物理的刺激を用いてその特性を調べることによって一意的に識別され、検証され得る。高いレベルでは、PUFをチャレンジを応答にマッピングする関数と考えることができ、そのペアは多くの場合にチャレンジ応答ペア(CRP)と称される。記法
F:C->R∀(C,R)∈ΦF
を使用してそのようなマッピングFを記述することができ、
C、Rはチャレンジおよび応答をそれぞれ表し、ΦFはPUFによって生成され得る形式(C,R)のすべてのチャレンジ応答ペアの集合である。
【0027】
PUFの一意的な物理的特性は、典型的には、シリコンチップなどの、物理的デバイスの製造に固有のランダムなプロセス変動の結果である。PUFに関して典型的になされる仮定は、以下の通りである。
1. 物理的システムのパラメータを任意の形式の解析によって完全に決定することは困難である。
2. 物理的システムのパラメータは、PUFとして使用されるデバイスの正規製造業者を含む、いかなる当事者にも知られていない。この仮定は、多くの場合に、製造業者耐性(manufacturer-resistance)と称される。
1. 物理的システムのパラメータを任意の形式の解析によって完全に決定することは困難である。
2. 物理的システムのパラメータは、PUFとして使用されるデバイスの正規製造業者を含む、いかなる当事者にも知られていない。この仮定は、多くの場合に、製造業者耐性(manufacturer-resistance)と称される。
【0028】
これらの仮定は、PUFが任意のチャレンジに対して予測不可能でありしかも決定論的である応答を生成するために使用されることを可能にする。このチャレンジ応答プロセスでは、図3に例示されているように、PUFを物理的ブラックボックスのように取り扱う。
【0029】
図3は、物理的ブラックボックスとしてモデル化されたPUF302を示す。提出者103Sは、チャレンジCをPUF302への入力として提出し、それに応答してPUF302は対応する応答Rを生成する。提出者は、提出者のコンピュータデバイス(図示せず)などのデバイスからチャレンジを提出するが、これはPUF302それ自体が実装されているデバイスと同じまたは異なるデバイスであり得る。
【0030】
提出者103Sは、ターゲット当事者またはデバイスのアイデンティティにリンクされている期待される応答のセットを確立するためのセットアップフェーズ(後述の例)の一部としてチャレンジ応答(CR)ペアを生成する当事者であり得る。または、提出者103Sは、生成された応答が期待された応答と一致することを検証するために、後の検証フェーズでチャレンジを提出する検証者であり得、したがって、PUF302を含むターゲットデバイスまたはPUFを所持するターゲット当事者のアイデンティティを検証することが可能である。
【0031】
別の例示的なシナリオでは、提出者103Sは、ブロックチェーンアプリケーションなどの暗号アプリケーションにおいて使用するための鍵、または鍵を生成するためのシードとして、生成済み応答を使用する(たとえば、ブロックチェーントランザクションに署名するため)ことを望む当事者であり得る。
【0032】
図4は、PUF302へのインターフェースの一例を備えるシステムを示している。システムは、プロセッサ402およびPUF302を備える。インターフェースは、メモリに記憶され、プロセッサ402上で実行するように配置構成されている、インターフェースロジック404を備える。インターフェースロジック404が記憶されるメモリは、1つもしくは複数の記憶媒体(たとえば、磁気ディスクもしくはテープなどの磁気媒体、またはROM、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAMなどの電子媒体)を採用する1つもしくは複数のメモリユニットを含み得る。プロセッサ402は、1つもしくは複数の処理ユニット(たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、もしくは暗号プロセッサなどのアプリケーション固有またはアクセラレータプロセッサ)を備え得る。また、インターフェースロジック404が、代わりに、専用ハードウェア回路、またはPGAもしくはFPGAなどの構成可能もしくは再構成可能な回路において部分的にもしくは全体的に実装されることが可能であることも除外されない。
【0033】
提出者103Sは、デバイス(図示せず)を使用して、インターフェースロジック404を介してチャレンジー(challengee)CをPUF302に提出する。提出者103Sによって使用されるデバイスは、たとえば、外部コンピュータデバイスまたはプロセッサ402が実装されている同じコンピュータデバイスのいずれかのコンピュータデバイスとすることが可能である。次いで、PUF302は、対応する応答Rを、インターフェースロジック404を介して提出者302のデバイスに戻す。後でより詳細に説明されている、いくつかの実施形態において、インターフェースロジック404は、PUF302へのアクセスを何人かの当事者、たとえば、パスワード、PIN、または生体測定情報などの認識された資格情報を提示することができる当事者のみに制限するアクセス制御ロジック406を含んでよい。および/または、プロセッサ402を備えるデバイスへの物理的インターフェースは、許可された人員のみがアクセス権を有する部屋または複合体内に配置されること、または鍵の掛かった箱またはキャビネット内に保管されることなどによって、制限され得る。しかしながら、代替的システムでは、インターフェースロジック404は、任意の当事者がチャレンジで問い合わせるために利用可能にされ得る。
【0034】
PUFのチャレンジ応答プロセスは、選択された応答からこれらのチャレンジを抽出することによって、擬似乱数データ値の生成を可能にする。たとえば、PUFは、暗号で使用するべきランダムな再現性のあるデータを抽出するための鍵生成器として使用することができる。PUF302は、複数の別々の機会に同じチャレンジを与えられたときにPUFが同一の応答をもたらすような、決定論的で再現可能な方法で働くことに留意されたい。
【0035】
PUFとして使用され得る多くの異なる物理的システムがあり、またこれらのシステムを使用するPUFの多くの異なる実装形態が存在する。PUFの例示的な例は、気泡を含む光学的媒体であり、これはレーザーで探査されたときに、(i)レーザーの位置、(ii)光学的媒体の小規模パラメータによって決定論的に決定される応答回折または「スペックル」パターンを生成する。
【0036】
1.1. PUFのクラス
1.1.1 弱いPUF:弱いPUFは、小さいチャレンジ応答空間を有することによって特徴付けられ、多くはCRP空間のサイズが|ΦF|=1であるような単一のチャレンジしか有しない。一般に、弱いPUFに対するチャレンジ応答空間は、0(n)のオーダーであると考えられ、nは制御不可能な製造ばらつきの影響を受けやすいPUFにおけるコンポーネントの数である。
1.1.1 弱いPUF:弱いPUFは、小さいチャレンジ応答空間を有することによって特徴付けられ、多くはCRP空間のサイズが|ΦF|=1であるような単一のチャレンジしか有しない。一般に、弱いPUFに対するチャレンジ応答空間は、0(n)のオーダーであると考えられ、nは制御不可能な製造ばらつきの影響を受けやすいPUFにおけるコンポーネントの数である。
【0037】
弱いPUFの場合、典型的には、PUFの応答へのアクセスが制限されることも仮定される。これは、弱いPUFによるサービスを受けるCRPの数が少ないので、敵対者が妥当な時間内にすべてのそのようなペアを列挙し得、したがってPUFの挙動を模倣するか、または「スプーフィング」し得るからである。この制限は、ときには、弱いPUFの挙動を説明するときに制限されたチャレンジ応答インターフェースと称される。
【0038】
これらの特性により、弱いPUFは、鍵生成器として暗号アプリケーションで使用するのに最も自然に適していることになり、PUFによって生成された1つの(または少数の)CRPは、デバイス上の不揮発性メモリ(NVM)を暗号化することまたはHMAC対称鍵として使用することなど、暗号化操作用の秘密鍵として使用され得る。そのような場合、PUFの応答から導出される鍵は、実行される暗号化プロセスおよびPUFそれ自体の両方のセキュリティのために秘密にされ、デバイスの所有者にのみ知られていなければならない。
【0039】
弱いPUFの顕著な、広く実装されている例は、SRAM PUFであり、「SRAM」という用語は、「スタティックランダムアクセスメモリ」を指す。SRAM PUFの設計は、SRAMチップの「電源オン」状態のばらつきを活用し、各々チップ内のSRAMセルがチップの電源オン時に「0」状態または「1」状態であるばらつきによる固有のフィンガープリントを有する。
【0040】
この場合、PUF構成は、PUFを探査するための固定モード(すなわち、SRAMチップの電源投入による)が1つあり、したがって単一のCRPのみであるので、弱いと考えられる。この場合、唯一無二の「チャレンジ」はSRAMチップに電力を供給することであり、応答はその電源オン状態から導出される一意的なフィンガープリントである。応答の機密性を確実にするためのアクセス制御は、SRAM PUFが使用されるデバイス上の適所の既存のメモリアクセス制御ポリシーもしくはメカニズム、またはデバイス上で採用されている代替的メカニズムを使用して実装することもできる。
【0041】
SRAM PUFの場合など、いくつかのPUF実装形態の特徴は、同じチャレンジが条件および時間に関して不変の方式で同じ応答をもたらすことを確実にするためにPUFによって生成される応答における誤り訂正を使用することである。そのような誤り訂正技術の詳細は、当業者に知られている。いくつかの場合において、誤り訂正プロセスは、PUFデバイスが最初に「登録」され、誤り訂正を円滑にするためにオンデマンドで後から生成される応答と組み合わされるヘルパーデータのソースを提供することを必要とすることがある。
【0042】
1.1.2. 強いPUF:弱いPUFとは対照的に、強いPUFは、利用され得る可能なチャレンジ応答ペア(CR-ペア、またはCRP)の大きな空間を有することによって特徴付けられる。CRPのこの大きな空間は、敵対者が強いPUFのドメイン内のチャレンジ応答ペアのすべてを多項式時間内に列挙することが不可能であると考えられることを意味する。この特性は、強いPUFが一般に保護されていないチャレンジ応答インターフェースを有し得ることを意味するが、それは、敵対者がPUFに自由にアクセスすることができても、弱いPUFの場合のように、PUFの列挙およびスプーフィングを許すことによってセキュリティを損なうことはないからである。PUFのこのクラスは、ΦFの大きな部分集合を知っている敵対者の観点からであっても、予測不可能な応答を生成するとも言われ、このことは、強いPUFが大きなドメインを有する暗号ハッシュ関数により似た働きをすることを意味する。
【0043】
しかしながら、強いPUFには、チャレンジCを提示されたときに応答RのみがPUFによって与えられるべきであり、プロセスにおいてPUFの内部動作または操作に関する他の情報が漏洩されるべきでないという制限が課せされる。この制限は、敵対者がPUFの挙動を支える物理的システムを特徴付けることを試み得る様々な分析的攻撃を軽減することである。これらは、文献ではモデリング攻撃と称されることが多い。
【0044】
弱いPUFと同様に、いくつかの強いPUF構成は、デバイスによって生成される応答の正確さを保証するために誤り訂正技術に依存し得る。
【0045】
強いPUFの主な既存のアプリケーションは、固有のチャレンジ応答メカニズムを使用してシステムの認証および識別を円滑にすることである。これらのメカニズムは、直接的に2人の当事者間の共有秘密としてCRPの作成を伴うプロトコルに依存しており、多くの場合に、少なくとも一方の当事者が、他方の当事者に対する認証トークンとして使用される時間(初期セットアップ)より前にCRPのテーブルを生成する必要がある。
【0046】
強いPUFの実装形態の最も初期の例の1つは、光学的PUFシステムであった。この構成では、PUFは、入射光を散乱させる、製造上のばらつきの結果の、ランダムに分布する物理的欠陥を収容する光学的媒体を含む。このPUFは、光学散乱媒体に向けられたレーザービームによって探査され得る。この場合、入射ビームの方向および偏光は、チャレンジを形成し、観察された散乱パターンは、PUFの応答とみなされる。
【0047】
しかしながら、この強いPUF構成は、測定デバイスがPUFデバイスの残りの部分から分離しており、半導体コンポーネントと直接的に一体化することが困難であるという事実から、実装が複雑である。これは、装置それ自体に関連付けられるコストに加わり、配置構成のポータビリティの欠如が日常的な用途に対する実用性を低下させる。
【0048】
アービターPUF(APUF)として知られている、電気的な一体化された強いPUFが、それ以降に提案されており、これはこれらの問題点のいくつかを克服するものとなっている。この構成は、信号多重化を利用し、電気コンポーネントにおける実行時遅延を活用する。多くの他の強いPUF構成が、並行して提案されているが、その多くは広く使用するための実用的な適合性を欠き、また多くがセキュリティおよび潜在的攻撃ベクトルに関する関連付けられている弱点を有している。たとえば、非常に問題となる潜在的攻撃は、中間者攻撃であり、攻撃者は平文で提出されたチャレンジを傍受し、保証計算をスプーフィングすることができる。
【0049】
1.1.3. 制御されたPUF:制御されたPUF(CPUF)として知られている、第3のクラスのPUFは、既存の強いPUF構成を改良したものであるが、それらをビルディングブロックとして使用している。これらのPUFは、強いPUFを取り、PUFへのアクセスを制限する追加の制御ロジックを適用し、他の場合にはそれらを未保護チャレンジ応答インターフェースを有し得る制御されない強いPUFから区別する。
【0050】
図4に示されているように、今やより大きなPUFデバイスの一部である、PUFに適用される制御ロジック406は、PUF302それ自体へのアクセスを媒介し得る。これは、制御ロジックコンポーネント406が、どのチャレンジがPUFに提示されるかを制限し、さらにはその後の応答がどのようにユーザに明らかにされるかを制御できることを意味する。
【0051】
CPUF構成において、好ましくは、制御ロジックコンポーネント406は、強いPUFコンポーネント内に埋め込まれるか、またはそれによって包まれるべきである。CPUFの一定義によれば、PUFは、不可分の方法でPUFに物理的にリンクされているアルゴリズムを介してのみアクセスできる場合(すなわち、アルゴリズムを回避する試みがPUFの破壊につながる)、制御されていると言われる。この埋め込みは、制御ロジックの探査をかなり難しくするべきである。
【0052】
これは、PUFコンポーネントと制御ロジックコンポーネントとの間に、各々他方に対するある種の攻撃を軽減するような相互に有益な関係を確立する。すなわち、制御ロジックをPUFデバイスそれ自体内にカプセル化することは、これがPUFコンポーネントを取り返しが付かないほどに破損し、その応答を改変するので制御ロジックを物理的または侵略的攻撃から保護するが、制御ロジックは、PUFコンポーネントをCRPまたはPUFそれ自体の基盤となる内部物理的システムに関する他の情報を抽出するプロトコルレベルの攻撃から自然に保護する。
【0053】
CPUFの用途は強いPUFとほぼ同じであるが、よりロバストな方式で達成され得る。特に、保証された計算と実行証明は、上で概略を述べたプロトコルで簡単に達成できる。
【0054】
強いアービターPUF(APUF)の設計を拡張したCPUFの初期の例は、制御ロジックがすでに説明された方式でAPUFそれ自体と絡み合うことを必要とし、制御ロジックおよびAPUFは異なるタイプの攻撃から互いを相互に保護する。制御APUF設計は、システムの過渡応答を組み込むことによって集積回路(IC)からの単一の静的応答からCRPの大きなセットを生成する。
【0055】
制御されたPUFの別の知られている例は、PUF-FSM構成である。これは、強いPUF(実際にはAPUF)を、APUFコンポーネントそれ自体のチャレンジ応答インターフェースへのアクセスを制限する制御ロジックとして働く有限状態機械(FSM)と併せて含む。
【0056】
1.2. 議論
1.2.1. 実用性:実用的で軽量でありながら、標準的な相補型金属酸化膜半導体(CMOS)コンポーネントと一体化可能でもある、強いPUFを生成することは、非常に困難であることは文献において認められている。対照的に、SRAM PUFなどの弱いPUFは、生成が安価であり、集積回路アーキテクチャと組み合わせることができることは自明であり得る。
1.2.1. 実用性:実用的で軽量でありながら、標準的な相補型金属酸化膜半導体(CMOS)コンポーネントと一体化可能でもある、強いPUFを生成することは、非常に困難であることは文献において認められている。対照的に、SRAM PUFなどの弱いPUFは、生成が安価であり、集積回路アーキテクチャと組み合わせることができることは自明であり得る。
【0057】
1.2.2. PUFに対する攻撃:提案され、研究されてきた多くの異なる攻撃があり、異なる攻撃は特定のPUF構成またはクラスをターゲットとし得る。最も広く知られている攻撃タイプのいくつかが以下にリストされている。
・ MITM攻撃-これらの攻撃は、PUFの制御されていない強いPUFをターゲットにし、敵対者は、特に保証計算に使用されるときに、PUFの応答を偽装するか、またはスプーフィングするために平文で行われるチャレンジを傍受し得る。
・ モデリング攻撃-これらの攻撃は、APUFなどの、多くの強いPUF構成に対する脆弱性を証明している。
・ 選択チャレンジ攻撃-これらの攻撃も、強いPUFに影響を及ぼし、CPUFアーキテクチャに向かうことに対する動機の一部である。
・ MITM攻撃-これらの攻撃は、PUFの制御されていない強いPUFをターゲットにし、敵対者は、特に保証計算に使用されるときに、PUFの応答を偽装するか、またはスプーフィングするために平文で行われるチャレンジを傍受し得る。
・ モデリング攻撃-これらの攻撃は、APUFなどの、多くの強いPUF構成に対する脆弱性を証明している。
・ 選択チャレンジ攻撃-これらの攻撃も、強いPUFに影響を及ぼし、CPUFアーキテクチャに向かうことに対する動機の一部である。
【0058】
また、様々なPUF設計には、いくつかの場合において一意性の欠如など他の問題もあり、これは注目しているPUFシステムのセキュリティを害する弱点を突くことを許してしまう。
【0059】
1.2.3 セキュリティモデル:PUFのセキュリティモデルは、CRPが発生するランダムなプロセスまたは製造ばらつきが製造業者耐性を有するという仮定、およびPUFの物理的システムを解析的手段によって特徴付けることが困難であるという仮定など、いくつかの類似性を共有する傾向を有する。しかし、3つの主要なPUFクラスのセキュリティモデルには、いくつかの違いもある。
・ 弱いPUF-弱いPUFのセキュリティは、そのCRPが秘密に保たれるという仮定に依存しており、そうでなければデバイスは列挙され偽装され得る。これは、弱いPUFが暗号操作のためのエントロピーのソースおよびそのエントロピーの安全な記憶を提供するために使用され得るが、実際のCRP応答データそれ自体はプロセスにおいて公に明らかにされることはない。
・ 強いPUF-強いPUFのセキュリティは、そのCRP空間がチャレンジビットの数に対して指数関数的に増大する傾向があり、したがって空間全体を列挙することは合理的な時間枠内では実行不可能であるという事実に依存している。これは、強いPUFのCRP応答は、弱いPUFの場合とは異なり、デバイスによって明らかにされ得る。
・ 制御されたPUF-制御されたPUFのセキュリティは、プロトコルレベル攻撃から保護する、制御ロジックと、物理的攻撃から保護する、PUFそれ自体との組合せによって決定される。
・ 弱いPUF-弱いPUFのセキュリティは、そのCRPが秘密に保たれるという仮定に依存しており、そうでなければデバイスは列挙され偽装され得る。これは、弱いPUFが暗号操作のためのエントロピーのソースおよびそのエントロピーの安全な記憶を提供するために使用され得るが、実際のCRP応答データそれ自体はプロセスにおいて公に明らかにされることはない。
・ 強いPUF-強いPUFのセキュリティは、そのCRP空間がチャレンジビットの数に対して指数関数的に増大する傾向があり、したがって空間全体を列挙することは合理的な時間枠内では実行不可能であるという事実に依存している。これは、強いPUFのCRP応答は、弱いPUFの場合とは異なり、デバイスによって明らかにされ得る。
・ 制御されたPUF-制御されたPUFのセキュリティは、プロトコルレベル攻撃から保護する、制御ロジックと、物理的攻撃から保護する、PUFそれ自体との組合せによって決定される。
【0060】
強いPUFと弱いPUFを区別する2つの特性は次の通りである。第一に、強いPUFはCRPの大きな集合を有する。これは、強いPUFが大きなチャレンジ空間ΦFを有することを意味し、弱いPUFは、典型的には、1つ(または数個)のチャレンジしか利用できない。強いPUFは、さらに、任意のおよびすべての知られているCRPに関して予測不可能であると考えられる。言い換えると、任意の数のCRPの知識は、新しいチャレンジの応答を予測する上で有利でない。
【0061】
第二に、強いPUFは、保護されていないチャレンジ応答インターフェースを有することができる。所与の強いPUFは、チャレンジ応答インターフェースへのアクセスを制限するためにアクセス制御ロジックを必要としない、という仮定がなされる。これは、PUFに物理的にアクセスできる任意の当事者が、PUFまたはその物理的特性に関する任意の追加情報を明らかにすることなく、任意に、チャレンジを適用し、応答を取得し得ることを意味する。
【0062】
制御されたPUFは、保護されたチャレンジ応答インターフェースを有しているが、強いPUFのように大きなチャレンジ応答空間も有する。
【0063】
2. 拡張PUF(ePUF)
次に、ベースPUF302の所与のCRペアから複数の二次CRペアを生成することによって、PUFのチャレンジ応答(CR)空間を拡張するためのシステムおよび方法を開示する。これは、本明細書において、「拡張PUF」、または「ePUF」と称され得る。この考え方は、たとえば、典型的な強いPUFメカニズム(レーザー、光学媒体、およびセンサを必要とする光学的PUFなど)の複雑さまたは非実用性なしで、1つまたは限られた数の固有CRペアのみを有する弱いPUFのチャレンジ応答空間を拡大するために使用することも可能である。しかしながら、原理上、開示された技術は、より一般的に、弱い、強い、制御された、または他の何であろうと、任意のベースPUFのCRペアの数を拡張するために、または難読化または再利用性などの他の目的のために任意のPUFのCRペアを変換するために使用することも可能である。
次に、ベースPUF302の所与のCRペアから複数の二次CRペアを生成することによって、PUFのチャレンジ応答(CR)空間を拡張するためのシステムおよび方法を開示する。これは、本明細書において、「拡張PUF」、または「ePUF」と称され得る。この考え方は、たとえば、典型的な強いPUFメカニズム(レーザー、光学媒体、およびセンサを必要とする光学的PUFなど)の複雑さまたは非実用性なしで、1つまたは限られた数の固有CRペアのみを有する弱いPUFのチャレンジ応答空間を拡大するために使用することも可能である。しかしながら、原理上、開示された技術は、より一般的に、弱い、強い、制御された、または他の何であろうと、任意のベースPUFのCRペアの数を拡張するために、または難読化または再利用性などの他の目的のために任意のPUFのCRペアを変換するために使用することも可能である。
【0064】
図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などの構成可能もしくは再構成可能な回路において部分的にもしくは全体的に実装されることが可能であることも除外されない。
【0065】
インターフェースロジック404'は、変換関数502に動作可能に結合され、任意選択でベースPUF302にも結合される。ベースPUF302は、変換関数に動作可能に結合される。インターフェースロジック404'は、提出者103Sのデバイス(図5Aに図示せず)、たとえば、ePUF500が実装されているのと同じデバイスまたは外部デバイスである可能性もある、コンピュータデバイスから入力を受け取り、そのデバイスに出力を提供するように配置構成される。提出者103Sは、ePUF500を使用して、セットアップを実行し、将来の参照のためにアイデンティティにリンクされるべきチャレンジおよび期待される応答のセットを生成する当事者である可能性があるか、または後でPUFを使用して、生成された応答が以前に確立された期待される応答と一致するかどうかを検証する検証者(または、検証者に提供する応答を生成するチャレンジー)である可能性もある。別の例示的なアプリケーションでは、提出者103Sは、鍵として使用するための応答を生成するために、または鍵を生成するためのシードとして、ePUF500を使用する可能性もある。たとえば、これは、メッセージを暗号化するか、または署名する、たとえば、ブロックチェーントランザクションの一部に署名するために暗号鍵として使用される可能性もある。
【0066】
ベースPUF302は、入力として「一次」チャレンジCwを受信することに対応して、出力として「一次」応答Rwを生成するように動作可能である。本明細書における「一次」チャレンジ応答(CR)ペアは、ベース、構成PUF302のベースまたは「ネイティブ」(すなわち、固有)CRペアを指す。いくつかの実施形態において、ベースPUF302は、弱いPUFのように単一のチャレンジCwに応答して単一のベース(すなわち、一次)応答Cwのみを生成することができるものとしてよい。
【0067】
動作時に、インターフェースロジック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ペアの上に層化されるという意味で本明細書において「二次」と称され得る。これらは、また、「拡張層」または「補足」チャレンジおよび応答と呼ばれ得る。
【0068】
実施形態において、変換関数502は、ハッシュ関数、たとえば、SHAまたはDSAハッシュ関数などの暗号学的ハッシュ関数を含む。ハッシュ関数を使用することができる少なくとも2つの異なる方法がある。第1に、変換関数502は、プリイメージのハッシュを含み、プリイメージは、受信された二次チャレンジCiと生成された一次応答との組合せ(たとえば連結)を含む。すなわち、Ri=H(Ci| |Rw)である。または、より一般的には、プリイメージは、同様に他の要素、および/または連結以外の別の形式の組合せを含み得る。
【0069】
第2の代替的アプローチでは、変換関数502は、プリイメージのハッシュを含み、プリイメージは、受信された二次チャレンジを含み、ハッシュ関数は、生成された一次応答で初期化される。すなわち、Ri=H(Ci)であり、HはRwによって初期化される。または、ここでもまた、より一般的には、Hのプリイメージは、少なくともCiを含む限り、他の要素も含むことが可能である。Rwによって初期化されることは、ハッシュ関数Hによって定義される出力へのプリイメージのマッピングそれ自体がRwに依存することを意味する。
【0070】
前の場合には、Hによって引き起こされる出力へのプリイメージのマッピングは、Rwに依存せず、むしろ、プリイメージは、Rwに依存する。すなわち、前の段落ではプリイメージはRwに依存し、この段落ではHのみがRwに依存する。
【0071】
より一般的にはそれでも、原理上、ePUF500によって収容されるドメイン内の各可能なCiについて、CiおよびRwの組合せをRiのそれぞれの値に決定論的に、また一意的にマッピングする限り、任意の関数が使用され得る。
【0072】
二次チャレンジCiは、多数の異なる可能な値のうちのどれでも取ることができ、変換関数502は、それらの値を、特定の受信された二次チャレンジCiの値および一次応答Rwの値に基づき、二次応答Riのそれぞれの値にマッピングする。したがって、ePUF502は、所与の一次(ベース)CRペアのCR空間を複数の二次CRペアに拡張することができる。実施形態において、Ciは、使用される変数によってサポートされる値の範囲内の任意の値を取ることができる(たとえば、32ビット整数であれば、232値のいずれかを取ることができる)。
【0073】
いくつかの実施形態において、ePUF500は、図5Bに示されているように、代替的動作モードで動作できるものとしてよい。この場合、インターフェースロジック404'は、入力チャレンジデータが一次チャレンジーCwのみを含むことを検出する。これに応答して、Cwの受信された値をベースPUF302にルーティングし、結果として得られる一次応答Rwを提出者103Sのデバイスにルーティングする。言い換えると、この実施形態では、ePUF500は、「レガシー」または「非拡張」モードで動作することもできる。
【0074】
任意選択で、アプリケーションに応じて、インターフェースロジック404'は、アクセス制御ロジック406を含むものとしてよく、これは限定された数の可能な提出者103Sのみへのアクセスを、認可された当事者にマッピングされていると認識する資格情報(たとえば、パスワード、PIN、または生体測定入力)を提示できる当事者にのみアクセスを付与することなどによって、制限する。この場合、ePUF500は、CPUFの一形態と考えることも可能である。
【0075】
代替的に、ePUF500を備えるデバイスを、当事者の限られた集合のみがアクセスを許可される部屋もしくは構内に保持するか、または鍵の掛かっている箱、キャビネット、または部屋内に保持することなどによって、ePUF500への物理的インターフェースは合法的にまたは物理的に保護され得る。この場合、ePUF500は、一種の拡張された弱いPUFのように考えることが可能である。
【0076】
PUFへのインターフェースに対するそのような物理的制限の代替として、またはそれに加えて、アクセスは、一次チャレンジへのアクセスを制限することによって制限されてもよい。たとえば、ターゲット当事者103T(「アリス」、後述)は、Cwを知っている唯一の当事者であり得る。
【0077】
しかしながら、別の代替的手段として、インターフェースロジック404'へのアクセスは、制限され得ない、たとえば、任意の当事者がインターネットを介して自由に問い合わせ得る。この場合、ePUF500は、弱いベースPUFメカニズムを拡張することによって作成された一種の強いPUF502のように考えることが可能である。
【0078】
図5Aに示されている配置構成は、本明細書において拡張PUF(ePUF)と称されるPUFデバイスの新しいハイブリッドクラスを提供し、これは後で提示されるような、多くのアプリケーションのためのフレームワークとして一般的に使用され得る。
【0079】
ePUFは、本質的に弱いPUFなどのベースPUF302、暗号学的ハッシュ関数などの変換関数502、およびインターフェースロジックモジュール404'の3つのモジュールを併せて含む、図5Aに示されているような、物理的デバイスまたはシステムとして定義され得る。説明されているように、ePUF500は、暗号学的ハッシュ関数などの変換関数404'を導入することによって、正規のPUF302に関して「拡張」され得るが、それは、一意的なチャレンジ空間ΦFのサイズを、ベースの弱いPUF302に対する|ΦF|約1から、弱いPUFの物理的システムではなくむしろハッシュ関数の選択によって代わりに制約される|ΦF|>>1まで増やすからである。
【0080】
強いPUFの大きなCRP空間と弱いPUFの実用性とを組み合わせたシステムを実現する考え方は、それ自体、以前に調査されている。複数のFPGAベースの弱いPUFを組合せ動作で使用して、強いPUFの特徴を有するシステムを形成することが知られている。ここでの意図は、部分的に、ベースの弱いPUFのCRP空間を「拡張」することである。しかしながら、この性質を有する既存の構成は、実際には限られている。上述のFPGA設計の場合、システムは、FPGA上に構築されなければならず、依然として比較的低いCRP空間(約210)の影響を受ける。
【0081】
本明細書で開示するePUF設計は、既存の弱いPUF302にインターフェースロジックコンポーネント404'と暗号学的ハッシュ関数(または他のそのような変換関数)502を追加するだけで済むという点で、極めて軽量であるように設計されている。たとえば、SRAM PUFが広く使用されている弱いPUF 302として選択される場合、2つの残りのモジュール404'、502の追加は、著しいオーバーヘッドを生じるべきでなく、たとえば、ソフトウェア(たとえば、ファームウェア)で小さなアルゴリズムとして、または比較的単純なハードウェア回路として実装される。さらに、ePUF500の可能な出力の空間は、選択されたハッシュまたは変換関数502の範囲まで拡張され、これは、上記よりも相当に大きい。たとえば、SHA-256ハッシュ関数が選択された場合、可能な出力(したがってCRP)の空間は、直ちに2256-1まで増大され、ハッシュ関数モジュールそれ自体を埋め込むことを超えてハードウェアオーバーヘッドをスケーリングする必要がない。
【0082】
図5Aは、拡張PUF(ePUF)500のための概略設計を示している。暗号学的ハッシュ関数が使用される実施形態は、ePUF500が、そのCRPが予測不可能であるという特性を有することも意味し、これは、強いPUFシステムの場合も同様である。
【0083】
ePUFデバイスの制御ロジック要素406も、この構成で一般化され得る。制御ロジック406は、たとえば、これがアプリケーションに適切である場合に、SRAM PUFに類似する、物理的セキュリティとして単純に実装され得る。
【0084】
代替的に、制御ロジックモジュール406は、CPUFとともに使用されているものと似たソフトウェア制御モジュールとして実装されてもよく、これは、実際、PUFデバイスそれ自体の中に埋め込まれ、前に説明されたカプセル化の相互セキュリティ上の利点を提供する。
【0085】
しかしながら、このePUF設計を特にCPUF設計と区別するここでの1つのポイントは、このように実装されるべき制御ロジックに対する厳密な要件がないことである。
【0086】
制御モジュール406に対する侵襲的な攻撃が、ePUF設計における弱いPUFコンポーネント302の挙動を必ず変化させると必ずしも仮定される必要はない。その代わりに、この要素の実装形態は、ケースバイケースで選択され得る。
【0087】
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から応答を抽出することを示している。
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から応答を抽出することを示している。
【0088】
拡張PUFのいくつかの実施形態において、すべてのチャレンジCi、i∈{1,2,...,N }には、ベースチャレンジCwが付随しなければならず、ベース応答Rwは、図5Aに示されているように、すべての他の応答Riを生成するためのプロセスに組み込まれる。
【0089】
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
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
【0090】
関数hash(Ci,Rw,H)は、暗号学的ハッシュ関数Hを使用して、ハッシュダイジェストを計算するために使用される汎用関数である。関数hash()は、単純な場合にはH(Ci||Rw)を単に計算することなど、多数の方法で実装され得るか、または値Rwがハッシュ関数Hの初期ベクトルとして使用されている面倒な計算
【0091】
【数1】
【0092】
によって実装されることも可能である。いずれにせよ、hash()の出力は、CiおよびRwの両方に依存する。
【0093】
図5Aおよび図5Bの図は、ePUF500が、任意選択で制御ロジックモジュール406を含む、インターフェースロジック404'を備え得ることを示している。実施形態において、応答を生成する際に取るべき可能な経路が2つあり、図5Bの経路は、チャレンジが単純にCwであるときに使用され、図5Aの経路は、チャレンジが、Cwに付随する新しい値Ciであるときに使用される。これは決定論的である。
【0094】
開示されているePUF設計は、次の利点および/または他の利点のいずれかを提供するために使用され得る。
・ 選択されたハッシュ関数のドメインおよび範囲によって定義される、大きなCRP空間。
・ 制御ロジックをPUFそれ自体から分離する柔軟性。
・ 弱いPUFのセキュリティプリミティブ。
・ 選択されたハッシュ関数のドメインおよび範囲によって定義される、大きなCRP空間。
・ 制御ロジックをPUFそれ自体から分離する柔軟性。
・ 弱いPUFのセキュリティプリミティブ。
【0095】
これは、ユーザがePUFデバイスをCPUFデバイスと同様に使用できることを意味するが、PUFへの制御されたアクセスは、(I)弱いPUFのベースCRP(Cw,Rw)を安全に記憶することと、(II)PUFデバイスへの物理的アクセスを対象ユーザのみに制限することの両方を含む。このモデルでは、ベースペア(Cw,Rw)はマスターキーのように働き、そこから形式(Ci,Ri)の極めて多数の他のCRPが導出され得、Ciは外部または第三者によって提出され得る。
【0096】
2.2. ePUFのアプリケーション
ePUFデバイスの可能なアプリケーション(ユースケース)は、少なくとも以下の2つに大別される。
1. アイデンティティを活動または計算操作にリンクすること、および
2. 暗号操作のための鍵生成器として機能すること。
ePUFデバイスの可能なアプリケーション(ユースケース)は、少なくとも以下の2つに大別される。
1. アイデンティティを活動または計算操作にリンクすること、および
2. 暗号操作のための鍵生成器として機能すること。
【0097】
アプリケーション(1)は既存の強いPUFによって最も一般的に実装され、アプリケーション(2)は既存の弱いPUFによって最も一般的に実装される。ePUF構成は各々の特性を組み合わせたものであるという事実は、いずれのアプリケーションにも等しく適切に取り扱われ得る。アプリケーション(1)では、利点は、最も強いまたは制御されたPUFに比べて、実際にePUFを使用してはるかに容易にそのようなアプリケーションを実装し得る点である。
【0098】
3. アイデンティティリンクシステム
この節では、人間または機械のいずれかのアイデンティティをPUFデバイスにリンクするための汎用フレームワークが開示されている。
この節では、人間または機械のいずれかのアイデンティティをPUFデバイスにリンクするための汎用フレームワークが開示されている。
【0099】
実施形態では、拡張PUF(ePUF)を使用し得る。意図はここでは、ロバストでありながら高度に一般化された柔軟なアイデンティティシステムを提供するPUFアーキテクチャを定式化することであり、これは多くの異なるユースケースに再利用することができる。われわれがこれの構成において目指す特性は以下の通りである。
・ 強いPUFのものに匹敵する大きいCRP空間、
・ 弱いPUFのものに匹敵する実用性、および
・ CPUFのものよりも柔軟な制御ロジック。
・ 強いPUFのものに匹敵する大きいCRP空間、
・ 弱いPUFのものに匹敵する実用性、および
・ CPUFのものよりも柔軟な制御ロジック。
【0100】
ePUF設計は、様々なアイデンティティ確立プロトコルで使用されるPUFに対する基礎モデルとして使用され得る。実施形態は、プロセスにおけるエンドユーザまたはマシンの独立を可能にし得る。ePUFを使用するために再利用されてもよい既存のスキームが、セットアップ時にPUFデバイスに直接的にアクセスする信頼できる第三者に依存している場合、ePUFベースの提案されたシステムは、第三者がセットアップ時にデバイスにローカルでまたは直接的にアクセスすることを必要とすることなく、PUFデバイスのエンドユーザがその代わりにアイデンティティを確立し、以降の認証に参加することを可能にし得る。
【0101】
いくつかの実装形態は、パブリックブロックチェーンを導入することによってこれらのアイデンティティリンクプロトコルのロバスト性を改善し、さらに拡張し得る。ここで採用され得る2つの概念は、(A)改ざん防止CRP管理システムとしてのブロックチェーンの使用、および(B)アイデンティティリンクプロトコルにおいて使用される要求-応答メッセージを仲介し、効率的失効システムを提供するためのタイムスタンプサービスとしてのブロックチェーンネットワークの使用である。
【0102】
【0103】
システムは、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と直接的にやり取りしてもよい。
【0104】
本明細書における、ユーザまたは当事者103の活動もしくは同様のものに関する言及は、検証者103V、ターゲット当事者103T、または第三者かどうかに関係なく、当事者がその当事者のコンピュータ機器102を通して活動している可能性を含む。簡潔にするため、これは、必ずしも毎回明示的に述べる必要はないが、暗黙のうちに含まれていると理解される。これは、A)活動が、当事者によるコンピュータ機器への手動ユーザ入力によってトリガされるか、もしくはその制御下で実行されるか、またはB)活動が、当事者に代わってコンピュータ機器によって自動的に実行される(当事者が活動を実行すると言うことは、必ずしもその当事者の人間ユーザがその活動を手動で引き起こすことを意味しないが、当事者の機器がその当事者に代わって自律的に活動を実行することを意味する)の両方の可能性を対象とする。疑念を避けるために、当事者は、単一の個人またはグループまたは人々または組織、たとえば企業、慈善団体、政府機関、または自治体もしくは学術機関を指し得ることにも留意されたい。
【0105】
ターゲット当事者103Tのコンピュータ機器102Tは、応答データストア601に動作可能に接続され得る(たとえば、第三者機器602への接続によって)。検証者103Vのコンピュータ機器102Vは、応答データストア601に動作可能に接続され得る(たとえば、第三者機器602への接続によって)。ターゲット当事者103Tのコンピュータ機器102Tは、検証当事者103Vのコンピュータ機器102Vに動作可能に接続され得る。これらの接続のいずれかは、1つまたは複数のネットワーク、たとえばインターネットまたはモバイルセルラーネットワークなどの1つまたは複数のワイドエリアネットワークを介して形成されてもよい。実施形態では、これらの接続のいずれかは、それぞれの安全なチャネルを介して形成される、たとえば、注目している2人の当事者間で共有される共有秘密に基づき確立され得る。本明細書において、2人の当事者が、チャレンジを送信するか、または返ってくる応答を受信することなど、何らかの方法で通信を行うと言われる場合には、これらの通信が、それぞれのコンピュータ機器(102V、102T、102T、602、または102V、602)の間の任意の好適な直接もしくはネットワーク接続を介して実行され得る可能性を含むと理解される。簡潔にするため、これは、必ずしも毎回明示的に述べる必要はないが、暗黙のうちに含まれていると理解される。
【0106】
ターゲット当事者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は外部周辺機器となり得る)。
【0107】
一般に、ターゲット当事者103T、検証者103V、または第三者のいずれかが、図3、図4、および図5に関してすでに説明されている提出者の役割を担うものとしてよい。ターゲット当事者103T、検証者103V、または第三者のいずれかが、提出者の役割を担うか、またはPUFモジュール603を使用して設定者の役割を担い、1つまたは複数のCRペアのセットを確立し、後の検証フェーズで使用するためにそれらをターゲット当事者103Tのアイデンティティにリンクし得る。いくつかの特定の例示的なシナリオが、後でより詳細に説明される。
【0108】
応答データストア601は、PUFモジュールによって生成された応答データを設定フェーズで記憶する。データストア601は、この応答データを、ターゲット当事者103Tまたはターゲット当事者103Tのデバイスであり得る、ターゲットのアイデンティティの証拠に関連して記憶する。検証者103Vは、応答データストア601へのアクセス権を有し、これを使用して、検証フェーズにおいて後からターゲットのアイデンティティを検証することができる。これを行うために、検証者103Vは、セットアップフェーズで使用されたチャレンジのセットに以前に含まれていたチャレンジCiに対する応答Riを生成するようにターゲットにチャレンジを行う。ターゲットが、応答データストア601に記憶されている内容に従って期待される応答を生成できる場合、これは、ターゲットがPUFモジュール603を所持しているかまたは制御していることの証拠となり、したがって、セットアップフェーズでアイデンティティが捕捉された同じ当事者であると仮定され得る。
【0109】
一代替的変更形態において、応答データストア601は、セットアップフェーズで生成された応答に基づき、たとえば応答をシードとして使用して、生成された、1つまたは複数のそれぞれの公開鍵-秘密鍵ペアの1つまたは複数の公開鍵を記憶し得る。ターゲットが後で秘密鍵の1つを使用してメッセージ(たとえば、文書またはブロックチェーントランザクション)に署名する場合、検証者は、応答データストア601からの対応する公開鍵を使用して署名を検証することができる。そのような変更形態において、「応答データ」という用語は、必ずしも応答Riの明示的な値または証明ではない、応答Riから導出されるデータを扱うためにより広い意味で使用されていることに留意されたい。
【0110】
応答データストア601は、公的にアクセス可能であり得るか、またはアクセスは、少なくとも1つの検証者103Vを含む1人または複数の当事者の限られたセットにのみ制限され得る。それは、第三者システム602上で、もしくはピアツーピア方式でホストされ得るか、または代替的に、ターゲット当事者103Tのコンピュータ機器102Tもしくは検証者103Vのコンピュータ機器102Vにおいて実装され得る。
【0111】
図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}のセットを生成する。
【0112】
実施形態では、PUFモジュール903へのアクセスは、ターゲット当事者103T(および異なる当事者であれば設定当事者)だけが応答Riへのアクセス権を取得することができるように制限される。これは、パスワード、PIN、生体測定データなどの認識済み資格情報を提示することができる当事者にのみアクセス権を付与し得るアクセス制御ロジック404または404'によって達成されることが可能である。および/または、PUFモジュール603との物理的インターフェースへのアクセスは、鍵を掛けられた容器、キャビネット、または部屋に保管することなどによって物理的に保護され得るか、または特定の人員のみがアクセスを許される部屋もしくは複合施設にPUFモジュール603を保管することなどにより法律的に保護され得る。別の代替的または追加の制限として、ePUF501の場合に、一次チャレンジCwの知識が制限されてよく、それにより、ターゲット当事者103T(および実施形態では、別個のセットアップ当事者として活動する信頼できる第三者)のみがCwを知る。
【0113】
ステップ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がブロックチェーンなどの公開媒体である場合に特に有用であり得る。しかしながら、暗号化も別の可能性であろう。
【0114】
応答データが暗号化済み形式で記憶される場合、各応答データ(たとえば、各CRペア)は、個別に暗号化され得、各々復号するために異なるそれぞれの復号鍵を必要とする。代替的に、応答データのサブセットまたはセット全体(たとえば、所与のターゲット当事者103Tに対するすべてのCRペア)は一緒に暗号化され、すべては同じ鍵でグループとして一緒に復号可能であり得る。
【0115】
応答データ、たとえばCRペアは、ターゲットのアイデンティティの証拠と関連して応答データストア601に記憶される。たとえば、ターゲット当事者103Tは、セットアップの一部として、パスポートなどの、1つまたは複数の識別情報を生成することを必要とし得る。応答データと関連して応答データストア601に保持される証拠は、応答データに関連して明示的に記憶される(平文または検証者103にとってアクセス可能な暗号化済み形式で)この情報それ自体のコピーを含むことが可能である。代替的に、応答データストア601が信頼できる第三者または検証者103Vそれ自身によって管理される場合に、応答データが特定のアイデンティティに関連して応答データストア601に登録されているという単なる事実は、十分な証拠とみなされ得る(仮定は、検証者103Vがセットアップ当事者および応答データストア601を管理する当事者、たとえば信頼できる第三者が、セットアップ時にターゲット当事者の識別情報を適切にチェックしたことを信頼するという仮定である)。
【0116】
検証フェーズ704では、ステップ730において、検証者103Vは、応答データストアにアクセスし、検証操作で使用する応答データを決定する。実施形態において、複数の潜在的検証者103Vが存在し、各々CRペアの1つまたは複数の異なるそれぞれのサブセットを割り当てられる。すなわち、応答データストア601は、所与の検証者103Vに対して、その当事者に割り当てられたCRペアの期待される応答Riのみを開示する。たとえば、このスキームは、信頼できる第三者システム602によって管理され得る。そのようなスキームは、有利には、一方の検証者103Vが他方の当事者に対してターゲットであるふりをすることができないように、CRペアを分離して保持する。しかしながら、ストア601へのアクセスを付与されたすべての検証者103Vが信頼できる当事者である場合、これは不可欠ではない。
【0117】
実施形態において、検証者103Vは、自分が使用しようとしているチャレンジを最初は知らず、対応する応答データ(たとえば、応答または証明)とともにデータストア601からアクセスすることによってこれを決定する。代替的に、検証者103Vは、自分が使用することを意図しているチャレンジを予め知っており、これを使用して、データストア601においてどの応答データがこれにマッピングされるかを調べる。
【0118】
検証者103V(または実際には任意の当事者)が、応答データおよび/またはチャレンジを決定することなどのために、ブロックチェーンからデータにアクセスするシナリオにおいて、ブロックチェーンにアクセスすることは、ブロックチェーンネットワークのノードに直接的に問い合わせるか、または間接的に、ブロックチェーンデータをキャッシュするもしくはブロックチェーンデータへのアクセスを求める当事者に代わって問い合わせを仲介する中間サービスに問い合わせるかのいずれかによって実行され得る。たとえば、検証者103Vは、ブロックチェーンネットワーク106に直接的に接続されていない別のサービスプロバイダからデータにアクセスすることも可能であるが、応答関係データ、およびおそらくマークル証明も、与えるだけであるかもしれない。
【0119】
ステップ740において、検証者103Vは、PUFモジュール603を所持しているかまたは管理しているターゲット当事者103TにチャレンジCiを提出する。これは、検証者103Vがステップ730において応答データストア601からアクセスした記録のうちの1つに対応するチャレンジである。セットアップ時に信頼できる第三者がPUFモジュール603を所持していたシナリオでは、PUFモジュール603は、セットアップフェーズ702と検証フェーズ704との間に信頼できる第三者からターゲット当事者103Tに物理的に渡され得る。
【0120】
提出されたチャレンジCiに応答して、PUFモジュール603は、対応する応答Riを生成し、ターゲット当事者103Vは、検証者にそれを返す。ステップ750において、検証者は、受信された応答Riが、ステップ730で応答データストア601からアクセスされた応答データに従って期待される応答と一致するかどうかをチェックする。
【0121】
前述のように、セットアップステップ702を実行する当事者は、ターゲット当事者103Tまたは応答データ(たとえばCRペア)を記憶する信頼できる第三者である可能性もある。さらなる変更形態において、これらのステップは、信頼できるOracleなどの別の調整者(実施形態では、データストア610を備える第三者コンピュータ機器602を実行する、当事者以外の別の第三者)によって実行されることが可能である。そのような実施形態において、データストア601は、(異なる第三者の)第三者システム602、またはブロックチェーンなどの公開ピアツーピア媒体とすることが可能である。および/または、なおもさらなる変更形態において、PUFモジュール603への入力を実行する当事者と、出力を受け取る当事者との間の分離が提供されることも可能である。
【0122】
また、前述のように、応答Riが応答データストア601に記録される方式に対して少なくとも2つの可能性がある。これの第1は、単純に、Riそれ自体の実際の値を明示的に記憶することである。この場合、ステップ750は、単純に、記憶された値(セットアップ702で確立された)と、(検証フェーズ704において)提出されたチャレンジCiに応答して現在受信されている値R'i(応答Riの意図された値)を比較することを含む。それらが一致する場合、方法は、ステップ760に分岐し、そこでターゲット当事者103Tのアイデンティティが検証されたと宣言される。そうでなければ、方法は、ステップ770に分岐し、そこでターゲット当事者103Tのアイデンティティが検証されていないと宣言される。
【0123】
第2の可能性は、Riの証明のみが応答データストア601に記憶されることであり、たとえば、ハッシュまたはダブルハッシュである。この場合、検証者103Vは、検証フェーズ704でターゲット当事者103Tから返信された応答R'iに、証明を生成するために使用された同じ変換を適用する。これが記憶されている証明と一致する場合、方法は、ステップ760に分岐し、そこでターゲット当事者103Tのアイデンティティが検証されたと宣言される。そうでなければ、方法は、ステップ770に分岐し、そこでターゲット当事者103Tのアイデンティティが検証されていないと宣言される。
【0124】
応答データストア601において、対応するチャレンジCiが各記録された応答Riと関連付けられていると指示される方式に対して少なくとも2つの可能性がある。第1は、単純に、各CRペア{Ci,Ri}の明示的な値を記憶すること、すなわちRiおよびCiの実際の値を(平文でまたは暗号化してのいずれかで)記憶することである。代替的に、第2の、より軽量の方法は、チャレンジCiが所定の決定論的チャレンジ導出関数fに従って導出され得るマスターチャレンジCmを記憶することである。
【0125】
これは、図8Aに例示されている。各応答Riは、それぞれのインデックスに関連して記憶される。関数fは、応答データストア601に記憶されているか、または検証者103Vに予め知られているかのいずれかである。いずれにせよ、検証者103Vは、マスターチャレンジCmを関数fに入力して、応答Riの少なくとも1つのインデックスiに対応するチャレンジCiを決定する。次いで、検証者103Vは、このチャレンジCiを使用してターゲットを検証する。
【0126】
いくつかのそのような実施形態において、関数fは、また、識別情報806の関数であってもよく、これは、単一の識別情報または複数の識別情報802(たとえば、パスポート情報、母親の旧姓および指紋情報)の組合せ804(たとえば、連結)であってもよい。これは、ターゲット当事者103Tの識別情報を含み得る。これは、特定のターゲット当事者103Tに特有のチャレンジCiのセットを使用可能にし、これは、たとえば、同じ第三者システム602が異なるターゲット当事者に対するチャレンジセットを生成するために使用される場合に、一意性が重要となる場合があるので、セキュリティ上の理由から有利である。ターゲット当事者103Tのパスポート情報または母親の旧姓などの個人識別情報を使用することは、それがターゲット当事者がすでに知っており、有しており、秘密にする傾向がある何かなので、良い選択肢である。
【0127】
代替的に、またはそれに加えて、識別情報806は、検証者103Vの識別情報を含むものとしてよく、それによりfは特定の検証者103Vのアイデンティティの関数である。これは、1つまたは複数の特定のチャレンジの特定のサブセットを特定の検証者103Vに割り当てるために使用される可能性もあり、それにより異なる検証者103Vは検証704において使用する異なるチャレンジCiを与えられる。
【0128】
いくつかの実施形態では、マスターチャレンジCmがどのように形成されるかにかかわらず、チャレンジCiは、連鎖方式でマスターチャレンジCmにマッピングされるものとしてよく、図8Bに示されているように、C1=f(Cm)、C2=f(C1)などとなる。言い換えると、第1のチャレンジC1は、マスターチャレンジCmに関数fを適用することによって決定され、次いで、第2のチャレンジC2は、第1のチャレンジに同じ関数fを適用することによって決定され、というように続く。一例として、fはハッシュ関数を含み得る。
【0129】
別の変更形態において、図8Cに示されているように、チャレンジCiは、階層方式でマスターチャレンジCmにマッピングされ得る。これは後でさらに詳しく説明される。
【0130】
連鎖アプローチは、より軽量であり、また、f()がルート鍵以外の任意のデータを必要としない場合にルート情報からより容易に回復することもできる。階層的導出の場合、木におけるインデックスが追加されることになり、このような単純なチェーンC_m,H(C_m),H(H(C_m))...に対して必要なく、たとえば、f()はハッシュ関数にすぎない。
【0131】
f()の形式、またはマスターチャレンジが識別情報および/または他の情報を含むかどうかにかかわらず、実施形態において、マスターチャレンジCmは、セットアップ702においてターゲット当事者103Tから第三者システム602によって受信され得る。次いで、第三者は、検証704で将来使用するために、受信されたマスターチャレンジをデータストア601(たとえば、ローカルまたはチェーン上のいずれか)に記憶する。代替的に、第三者システム602は、ターゲット当事者103TからチャレンジCiのセットを受信し、たとえば関数f()の逆数を適用することによってそこからマスターチャレンジCmを導出する。これらのアプローチの変更形態において、第三者システム602は、識別情報、マスターチャレンジまたはチャレンジのセットを、ターゲット当事者103T以外の別のところから、たとえばOracleまたは調整者(図示せず)から受信し得る。そのようなアプローチの組合せが使用されることも可能である(たとえば、一方の識別情報がターゲット当事者から受信され、もう一方は別のところから取得される)。または、さらなる代替的形態において、第三者は関与せず、ターゲット当事者103Tは、マスターチャレンジをチェーン上に自分自身で(または他の何らかのピアツーピア公開媒体で)記憶する。
【0132】
図7の方法のさらなる変更形態において、応答データストア601に記憶されている応答データは、セットアップにおいて生成されたCRペアの記録を含み得ない。その代わりに、応答データは、公開鍵-秘密鍵ペアの公開鍵、またはそのような公開鍵のセットを含んでよく、1つまたは複数の鍵ペアの各々は、セットアップフェーズ702からのそれぞれのPUF応答Riに基づき生成された。たとえば、応答Riは、公開鍵秘密鍵ペア生成アルゴリズムにおけるシードとして使用されてもよい。そのような実施形態において、方法は図7に述べられているように進行するが、ただしステップ730で検証者が記憶されている公開鍵の1つにアクセスし、ステップ740で検証者103VがターゲットのPUFモジュール603に入力されるべきチャレンジCiを提出しないことを除く。その代わりに、検証者103Vは、ターゲットによって(意図して)署名されたメッセージ(たとえば、文書、ファイル、またはブロックチェーントランザクションの一部)を取得する。このメッセージは、ターゲット当事者103Tによって自分に送信される可能性があるか、または検証者103Vは、ブロックチェーンまたはウェブサイトなどの公開媒体から自律的にそれにアクセスすることも可能である。いずれにせよ、ステップ750において、チェックは、ストア601からアクセスされた公開鍵を使用してメッセージに適用された署名を検証することを含む(それ自体、当技術分野において周知の、知られている公開鍵秘密鍵署名検証技術に基づく)。
【0133】
次に、本明細書において開示されている実施形態によりより一般的にePUFまたはPUFに対するいくつかの例示的なアイデンティティ確立および検証プロトコルを説明する。証明者アリス(ターゲット当事者103T)および検証者ボブ(検証者103V)を考察する。PUFアイデンティティシステムには少なくとも3つの異なるチャレンジタイプがある。たとえば、以下はePUFに関して説明されるが、より一般的には、任意のPUFデバイスが使用されることが可能である(PUFモジュール603を含む任意のデバイス)。
1. リモートPUFチャレンジ-検証者は、ボブによって提出されたチャレンジに対するアリスからの応答を要求することによって、リモートで証明者にチャレンジを行う。このモードでは、検証者が、証明者のPUFからの期待される応答を知っており、またPUFが正当な所有者によって所有されていることを仮定する。
2. ローカルPUFチャレンジ-検証者は、アリスによって制御されるPUFデバイスとやり取りすることによって、ローカルで証明者にチャレンジを行う。このモードでは、検証者が証明者のアイデンティティについて何かを知っているが、そのPUFの挙動については何も知らないと仮定する。
3. 暗号化チャレンジ-検証者は、認証済み公開鍵に証明可能にリンクされている鍵でメッセージに署名することなどによって、証明者のアイデンティティに関係する何らかの暗号化要件を満たすように証明者にチャレンジを行う。
1. リモートPUFチャレンジ-検証者は、ボブによって提出されたチャレンジに対するアリスからの応答を要求することによって、リモートで証明者にチャレンジを行う。このモードでは、検証者が、証明者のPUFからの期待される応答を知っており、またPUFが正当な所有者によって所有されていることを仮定する。
2. ローカルPUFチャレンジ-検証者は、アリスによって制御されるPUFデバイスとやり取りすることによって、ローカルで証明者にチャレンジを行う。このモードでは、検証者が証明者のアイデンティティについて何かを知っているが、そのPUFの挙動については何も知らないと仮定する。
3. 暗号化チャレンジ-検証者は、認証済み公開鍵に証明可能にリンクされている鍵でメッセージに署名することなどによって、証明者のアイデンティティに関係する何らかの暗号化要件を満たすように証明者にチャレンジを行う。
【0134】
タイプ1および2の場合、チャレンジは、証明者および検証者の両方の観点からPUFモジュール603に明示的に依存する。これらの場合におけるチャレンジ、およびしたがって対応する検証プロセスは、PUFデバイス(PUFモジュール603を含むデバイス、たとえばアリスのコンピュータ機器102T)の動作に本質的にリンクされている。これらの場合に、われわれは物理的状態がアイデンティティに一意的にバインドされているというPUFデバイスの特性を使用しており、したがって、PUFは、利用されているアイデンティティシステムにおいて中心的役割を果たす。
【0135】
「リモート」および「ローカル」という用語は、チャレンジを行うときの検証者と証明者のPUFとの間の相互のやり取りを特に指していることに留意されたい。これは、リモートチャレンジプロトコルが前もって証明者と検証者との間のローカルな相互のやり取りを伴うセットアップフェーズを有することを排除するものではない。
【0136】
しかしながら、ケース3では、チャレンジおよび検証プロセスは、証明者の観点からPUFデバイスに関係しているだけでよい。検証は、チャレンジに対する応答を生成する際にPUFが証明者によって使用されているかどうかを検証者が知ることに依存しない。この場合、この方法は、アイデンティティをデバイスそれ自体にリンクする際の有用性のためではなくむしろ、アリスに対する鍵生成器としてPUFの有用性を単純に使用している。
【0137】
次に、例示的な実装形態が、上述の3つの動作モードの各々におけるアイデンティティシステムに対するセットアップおよび検証、ならびに任意の更新、ならびに失効プロセスについて提供される。実施形態において、一般的な信頼できる第三者が、PUFベースのアイデンティティシステムに関係するプロセスに関与している。これは、そのようなアイデンティティシステムが、アイデンティティおよび関係する資格証明の完全性および信頼性を意味のある形で保証するために、そのような第三者を必要とする傾向があるからである。個人のアイデンティティがそのようなシステムにおいて確立され使用されるべきである場合、注目している信頼できる第三者は、認証局、政府機関、または銀行などの金融サービスプロバイダであってよい。
【0138】
アイデンティティが、機械または非人間エンティティに対して確立されるべきである場合、第三者は、デバイス製造業者、発行者、規制当局、またはその他の関連する主体であってよい。このケースは、モノのインターネット(IoT)またはさらにはモノのブロックチェーン(BoT)パラダイムに特に適しており、アイデンティティは、何らかの目標を達成するためにタスクまたは計算を協調して実行し得るデバイスのネットワークの異なるメンバーに割り当てられるべきである。
【0139】
3.1. リモートPUFシステム
3.1.1. セットアップ:リモートPUFチャレンジの場合、チャレンジCを証明者に提出する検証者は、期待される応答Rを前もって知っていると仮定する。これは、この場合のセットアッププロセスは、後でアリスのアイデンティティを認証するために使用できる当事者の間の共有秘密を導出するために使用され得るアリスと別の当事者との間のCRPのセット(すなわち、少なくとも1つ)を確立しなければならないことを意味する。
3.1.1. セットアップ:リモートPUFチャレンジの場合、チャレンジCを証明者に提出する検証者は、期待される応答Rを前もって知っていると仮定する。これは、この場合のセットアッププロセスは、後でアリスのアイデンティティを認証するために使用できる当事者の間の共有秘密を導出するために使用され得るアリスと別の当事者との間のCRPのセット(すなわち、少なくとも1つ)を確立しなければならないことを意味する。
【0140】
アリスは、前述のように、アイデンティティを確立するために備えられる一般的な第三者とのこの共有秘密を確立し、この第三者は、後でアリスと検証プロセスに参加する検証者であってもなくてもよい、と仮定する。検証者がアイデンティティ確立第三者とは異なる場合、検証者は第三者から共有秘密に使用される関連するCRP情報を取得し得ると仮定する。
【0141】
ここでセットアップフェーズに対して、アリスがいつでもPUFデバイスにアクセスできる唯一の当事者であるかどうか、または信頼できる第三者がセットアップフェーズにおいてのみPUFデバイスへのアクセス権も有していてもよいかどうかによって分類される、2つの異なる選択肢がある。
【0142】
ケース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)}を記憶する。
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)}を記憶する。
【0143】
ケース2:第三者はセットアップ時にPUFにアクセスする。
1. 第三者は、ベースペアおよびハッシュ関数の知識を有している。たとえば、ePUFデバイスは製造され、信頼できる第三者*に配布される。
2. 第三者は、デバイスからベースCRP(Cw,Rw)を取得する。
3. アリスは、第三者と連絡を取ることによってアイデンティティリンクされたePUFデバイスを申請する。これは、安全を保証されていない通信チャネル上で行われ得る。
i. 第三者は、アリスに対する識別アカウントを確立し、アリスのアイデンティティの証明を要求する。
ii. アリスは、関連する識別文書または資格証明書を第三者に供給する。
iii. 第三者はアリスのアイデンティティを検証し、ePUFデバイスおよびそのベースペア(CW,RW)をアリスのアカウントに割り当てる。共有秘密は、このCRPであるか、またはこのCRPから導出された秘密である。
4. 第三者は、ePUFデバイスをアリスに送る。
1. 第三者は、ベースペアおよびハッシュ関数の知識を有している。たとえば、ePUFデバイスは製造され、信頼できる第三者*に配布される。
2. 第三者は、デバイスからベースCRP(Cw,Rw)を取得する。
3. アリスは、第三者と連絡を取ることによってアイデンティティリンクされたePUFデバイスを申請する。これは、安全を保証されていない通信チャネル上で行われ得る。
i. 第三者は、アリスに対する識別アカウントを確立し、アリスのアイデンティティの証明を要求する。
ii. アリスは、関連する識別文書または資格証明書を第三者に供給する。
iii. 第三者はアリスのアイデンティティを検証し、ePUFデバイスおよびそのベースペア(CW,RW)をアリスのアカウントに割り当てる。共有秘密は、このCRPであるか、またはこのCRPから導出された秘密である。
4. 第三者は、ePUFデバイスをアリスに送る。
【0144】
(*デバイスは、最初にアリスに配布され、次いでアリスによって送られてもよい。しかしながら、ほとんどの場合において、デバイスが第三者に直接配布される方がより道理にかなっている。たとえば、デバイスがスマートデビットカードである場合、カードは製造業者から発行銀行に送られ、次いで発行銀行から顧客であるアリスにPUFセットアップに従って送られ得る。)
【0145】
セットアッププロトコルは、検証プロセスにおいて後でアリスのアイデンティティ(またはPUFを含むデバイス)を認証するために使用されるべきアリスと信頼できる第三者との間の共有秘密を確立する。また、これらのケースは、両方とも好ましくはアリスと信頼できる第三者との間の安全な通信を伴うという点で類似している。
【0146】
しかしながら、2つのケースの間の違いは、ケース1が安全な通信チャネルを確立することによって安全な通信を達成するのに対して、ケース2は物理的セキュリティを用いてそれを達成する点である。
【0147】
それぞれケース1およびケース2における2つのプロトコルの間の注目すべきもう1つの違いは、ケース2では、信頼できる第三者がアリスと同じ数のCRPをPUFなしで導出できるが、ケース1ではこの第三者は固定された数のペアを記憶していなければならない点である。
【0148】
これは、PUFデバイスを用いてユーザをセットアップする既存のプロトコルに勝るケース2の利点であり、それは信頼される第三者がリモートで任意の数のCRPを生成することを可能にするからであるが、既存のプロトコルでは、信頼される第三者はそうするためにエンドユーザまたはデバイス製造業者のいずれかと協力する必要があり得る。同じ技術的利点は、ケース1において、アリスがベースペア(Cw,Rw)をセキュリティチャネル上でボブに送信する(第三者が悪意を持ってベースペアを使用しないことを信頼する)ステップが追加された場合に達成され得る。
【0149】
セットアップフェーズで安全な通信を使用することは、検証プロセスなどの将来の通信が安全を保証されていないチャネル上で伝送されることを可能にすることに留意されたい。これは、検証時に両当事者がオンラインである必要があるなどの、技術的制限を少なくして検証が行われることを可能にする利点を有し、この1回限りのセットアッププロセスで追加の安全な通信オーバーヘッドのみを必要とする。
【0150】
3.1.2. 検証:リモートPUF検証モードでは、以下に詳述されるように、わずかに異なるリモート検証プロトコルに反映されている、セットアップフェーズにおける2つの異なるケースがあったことを思い出して欲しい。
【0151】
ケース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. ボブは、(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)}を残す。
【0152】
ステップ1.ii.では、CRPの一回使用という性質が、任意のボブが特定のCRPを使用してアリスに「なりすます」ことは可能でないことを確実にするが、それは、信頼できる第三者が各所与の状況において各ペアの使用を単純に監視することができ、またすべての認証の試行に対して新鮮なCRPを使用すべきであるからであることに留意されたい。
【0153】
ケース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であれば、検証は不合格である。
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であれば、検証は不合格である。
【0154】
(*これは、セットアッププロトコル(ケース2)で第三者がベースペア(CW,RW)を取得したからであり、これはRWが彼らに知られていることを意味する。また、ハッシュ関数Hは、全員でなくとも少なくとも第三者に知られている、すなわちSHA-256などの公的標準であることが仮定される)。
【0155】
3.1.3. 更新:検証(およびログインなどの他の有用なプロトコル)における1回限りの使用という性質が与えられた場合に新鮮なCRPを確立するアリスおよび第三者に対するプロセスを指定することも望ましいことがあり得る。
【0156】
ケース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と同一であることに留意されたい。
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と同一であることに留意されたい。
【0157】
アリスがチャネル上で第三者に(Cw,Rw)を伝えることに関して前のコメントも参照されたい。
【0158】
ケース2:第三者はセットアップ時にPUFにアクセスした。この場合、第三者はベースペア(Cw,Rw)およびハッシュ関数H()の両方の知識を有しているので、任意の数のCRPを間接的に生成することができる。これは、この場合にインタラクティブな更新に対する要件がないことを意味する。
【0159】
3.1.4. 失効:アイデンティティシステムのさらなる部分は、取り消されるべき特定のePUFデバイスに対するものであり得、したがってアイデンティティ目的にはもはや使用されない。失効プロセスは単純であり、(i)ユーザであるアリスから独立した、第三者による失効、または(ii)失効要求として伝えられたアリスによる失効のいずれかとして実行され得る。
【0160】
第1のケースは、ePUFまたは他の何らかのものを伴ういかなる技術的手段をも必要としない。第2のケースは、ePUFに特有のプロトコルまたは解を必要としないが、それは第1のケースにおける失効の必要性の好例は、アリスがePUFを含む物理的なデバイスを紛失した場合、またはそれが何らかの形で損なわれた場合だからである。
【0161】
しかしながら、アリスがまだデバイスの物理的制御を有していて、任意選択で失効プロセスにおいてePUFを活用することが望まれている場合に、アリスの要求が、HMACまたは各ケースにおいてCRP応答または秘密を鍵として使用する暗号化済みメッセージなどを用いるなどしてアリスおよび第三者が確立したCRP(またはその導出された共有秘密)の1つを使用して認証されることが規定され得る。しかしながら、上述の理由から、これは決してシステムの厳密な要件とはみなされない。
【0162】
3.2. ローカルPUFシステム
3.2.1. セットアップ:ローカルPUFに採用できるセットアップは、リモートPUFのセットアップと全く同じであるが、ローカルのケースとリモートのケースとの違いは、以下で検証ステップがどのように実行されるかである。
3.2.1. セットアップ:ローカルPUFに採用できるセットアップは、リモートPUFのセットアップと全く同じであるが、ローカルのケースとリモートのケースとの違いは、以下で検証ステップがどのように実行されるかである。
【0163】
3.2.2. 検証:このシナリオでは、検証はローカルで実行されている。これは、検証プロセスが証明者(アリス)および検証者(ボブ)の両方が同じ物理的な場所にいることを必要とすることを意味する。
【0164】
このシナリオは、たとえば、アリスがePUFデバイスを使用してローカルで調査をインタラクティブに操作することが法的に要求されている場合、またはIoTシステムの分析が(デバイスのアイデンティティに関して)実行されるべきであり、システムの管理者が特定のデバイスの応答をローカルで明示的にチェックすることを望む可能性がある場合に、訴訟手続き(人間のアイデンティティに関して)に関連し得る。これは決済シナリオに関連する場合もある。
【0165】
そのようなプロセスが適用可能である他のシナリオは、衝突後の車両に関する診断を含む可能性があり、当局はどのデジタルコンポーネントが命令を発行したかを正確に決定することを望む。この場合、入力Cは何らかの環境条件または動的条件であり得、応答Rはデバイスによって与えられた命令の一部である。
【0166】
以下で概要が述べられている、ローカルPUF検証プロトコルと以前のリモートPUF検証プロトコルとの違いは、このローカルプロトコルが、検証者がePUFの応答に関する知識を前もって有していると仮定していない点である。言い換えると、ローカル検証プロセスにおいて生成される応答は、事前に検証者に利用可能ではない。
【0167】
しかしながら、このシナリオでは、検証プロセスで使用されるチャレンジが何らかの形で意味を有する可能性がある。たとえば、アイデンティティが組み込み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であれば、検証は不合格である。
1. ボブは、注目するCRP(C,R)に基づき、ePUFデバイスに提出する関連するチャレンジCを取得する。
2. ボブは、ePUFデバイスへのアクセス権を得る。
3. ボブはePUFデバイスを使用して、候補応答R'=hash(C,Rw,H)を生成する。
4. ボブはR'==Rであるかどうかを検証する。
i. yesであれば、検証は合格である。
ii. noであれば、検証は不合格である。
【0168】
これらのシナリオでは、ボブは前もって候補応答R'を知っているのではなく、むしろPUFデバイスから今受信した応答が、以前に生成された応答と一致することを検証している。たとえば、これは、応答を生成した人物(アリス)または優勢なデバイスが、今いる(たとえば、法廷内にいる)同一人物またはデバイスであることを検証するために(たとえば、法廷内で)使用され得る。たとえば、デジタルコンポーネントの例では、これは何らかの入力されたチャレンジCに基づきRを生成した後に命令を発行するように構成されているであろう。たとえば、デバイスが自動運転車であり、コンポーネントが「前の車が近すぎる」というデータから導出された、またはそのデータを含むチャレンジを受信する場合、応答Rが生成され、Rはブレーキをかける命令を発行するようにコンポーネントをトリガする。したがって、遡及的診断検証では、検証者は、車が減速したと信じ、条件が実際に「前方の車が近すぎる」がその応答をトリガする条件であったことを検証することを望んでいる。
【0169】
3.2.3. 更新:更新されたCRPを生成するプロセスは、リモートケースについて提出されたのと同じロジックに従うことができるが、このシナリオの鍵となる違いは、検証にのみ適用されるからである。
【0170】
3.2.4. 失効:リモートの失効について説明したのと同じ技術がここでも有効である。
【0171】
3.3. 暗号化PUFシステム
3.3.1 セットアップ:この場合、アリスは、標準的な暗号化手段を使用して第三者とアイデンティティを確立するが、そのプロセスではePUFデバイスを使用する。
3.3.1 セットアップ:この場合、アリスは、標準的な暗号化手段を使用して第三者とアイデンティティを確立するが、そのプロセスではePUFデバイスを使用する。
【0172】
このシナリオにおいて、第三者は、任意選択で、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をアリスのアイデンティティと突き合わせて証明する。
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をアリスのアイデンティティと突き合わせて証明する。
【0173】
ステップ3は、ユーザの選択の暗号方式を使用することを伴うが、われわれはこのプロセスに関与する関連する鍵がアリスにのみ知られているCRP応答の派生鍵であると仮定する。上で選択された例では、秘密鍵SAは、SA=H(R)など特定のePUF応答Rから導出されることを意味する。
【0174】
3.3.2 検証:暗号化ケースでは、アイデンティティ検証は、前に詳述された暗号化セットアップフェーズにおいて確立された暗号化情報を使用して実行される。この場合、われわれは、セットアップ時にアリスのアイデンティティに対して認証済みEC非対称鍵ペアが確立され、その鍵を使用して検証することを例に取り上げる。
【0175】
しかしながら、以下のプロトコルは、適切な場合に、他の暗号化スキームにも、既存のセットアップおよび検証のプロトコルをそれらのスキームで置き換えるだけで簡単に適合されることが可能である。ここでの違いは、セットアッププロセスおよび検証プロセスに対して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. 署名検証に不合格であった場合、アイデンティティ検証にも不合格である。
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. 署名検証に不合格であった場合、アイデンティティ検証にも不合格である。
【0176】
(*このデータは、インボイスメッセージ、または生体測定ファジィマッチングデータなどの、検証に関係し得る。データdは、ボブまたはアリスによって選択され得る。代替的に、dは、アリスおよびボブに知られている共有秘密であってもよい、たとえば、ディフィー-ヘルマン鍵交換および/またはHMACを使用して導出され得る)。
【0177】
上記の暗号検証プロセスは、アイデンティティがECまたはPGP鍵などの類似の暗号プリミティブを用いて確立された場合に、前の節で説明されているように、独立して確立されたアイデンティティに適用され得る。
【0178】
3.3.3. 更新:ここでのアリスのアイデンティティを更新するプロセスは、鍵生成におけるePUFデバイスの使用に依存しないので、そのようなものとして、ここで特定の方法を規定する必要はない。その代わりに、PAなどの認証済み鍵を更新するための標準的な方法が使用され得る。
【0179】
既存のプロセスで必要とされる署名または他の暗号化プロセスについては、ePUFが鍵生成に関与することが単純に仮定され得る。
【0180】
3.3.4. 失効:同様に、ここで特定の失効プロトコルを規定する必要はなく、標準メカニズムに従う。もう一度繰り返すが、ePUFは、関連する暗号操作の鍵生成者としてバックグラウンドで関与すると仮定されてもよい。
【0181】
3.4. 独立したPUFメカニズム
3.4.1 セットアップ:ePUFデバイスを使用してアイデンティティを確立する独立したケースでは、エンティティが、任意の第三者から独立した人間のアイデンティティ、または閉じたシステム内のデバイスアイデンティティのいずれかを確立することを望むシナリオを考察する。このプロセスに関与する唯一の当事者は、ePUFデバイスの「所有者」であり、後の検証で最終的に証明者となる、アリスである。
3.4.1 セットアップ:ePUFデバイスを使用してアイデンティティを確立する独立したケースでは、エンティティが、任意の第三者から独立した人間のアイデンティティ、または閉じたシステム内のデバイスアイデンティティのいずれかを確立することを望むシナリオを考察する。このプロセスに関与する唯一の当事者は、ePUFデバイスの「所有者」であり、後の検証で最終的に証明者となる、アリスである。
【0182】
ケース1:アリスは、人間のアイデンティティを確立する。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分自身に対するアイデンティティを確立する。
i. アリスは、暗号化セットアップを使用して、非認証アイデンティティ鍵PAを確立し得る。
ii. アリスは、自分のアイデンティティに対して自分のアイデンティティ鍵を公開する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分自身に対するアイデンティティを確立する。
i. アリスは、暗号化セットアップを使用して、非認証アイデンティティ鍵PAを確立し得る。
ii. アリスは、自分のアイデンティティに対して自分のアイデンティティ鍵を公開する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
【0183】
アリスが自分自身のために「自己主権型」アイデンティティを確立するこのケースは、アリスだけが制御するデバイスに対して一意的で再現可能なデバイス識別子を提供する点である程度有用である。しかしながら、そのようなアイデンティティシステムに信頼できる第三者がいないことは、検証者が証明者のアイデンティティと証明者のデバイスとの間のリンクを後で信頼しなければならないことを意味する。これは、現実世界では非常に限られたアプリケーションを有し得る。
【0184】
ケース2:アリスはデバイスに対するアイデンティティを確立した。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分のシステム内のデバイスに対するアイデンティティを確立する。
i. アリスは、ペア(C、R)を自分のデバイスにマッピングする。
ii. アリスは、すべての自分のデバイスおよびCRPマッピングのデータベースを保持する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
1. アリスは、ePUFデバイスを取得する。
2. アリスはチャレンジCでePUFを探査する。
3. アリスはePUFから応答Rを取得する。
4. アリスは、ペア(C、R)を使用して、自分のシステム内のデバイスに対するアイデンティティを確立する。
i. アリスは、ペア(C、R)を自分のデバイスにマッピングする。
ii. アリスは、すべての自分のデバイスおよびCRPマッピングのデータベースを保持する。
5. アリスは、応答のダブルハッシュH2(R)などの、自分のCRPに対する証明を公開することを望み得る。
【0185】
上記のケースでは、われわれはデバイスに対する「自己主権型」アイデンティティを作成する場合に、設計は閉じたシステム内で非常に有用であり、管理者はシステム内の異なるデバイスを単純に識別することに注意を向けることは分かるであろう。これは、後々の他の人への証明にも役立ち得る。しかしながら、セットアップ時に信頼できる第三者がいないことは、なおも、シナリオによっては、デバイスが変更されていないことを外部検証者に納得させる上で、証明者を制限する。
【0186】
ケース1およびケース2は、同じプロセスであるが、異なる意図された目的を有する考えられ得ることに留意されたい。したがって、ケース1およびケース2は、人間または機械に対する「自己主権型」アイデンティティを生成するための方法として一緒にみなされるものとしてよく、後者のケースでは、システム管理者(IoTシステムにおけるアリスなど)はそれ自身信頼できるエンティティである。両方のケースにおいて、アリスは信頼されるエンティティである。
【0187】
3.4.2 検証:この場合の検証プロセスは、所与のチャレンジでePUFデバイスを探査し、その応答を検査するのと同じくらい単純である。外部当事者に対するより複雑な証明または証拠が、アイデンティティを証明するために、この上にさらに構築され得る。
【0188】
3.4.3 更新:この場合の更新プロセスは、単純にセットアッププロセスの繰り返しであり、管理者(この場合はアリス)は前方での使用のために追加のCRPを列挙する。
【0189】
3.4.4. 失効:このシナリオでは、アイデンティティの失効の唯一のタイプは、管理者(アリス)が独立してアイデンティティを取り消すことを望む場合であるが、それはこのプロセスに関与する第三者がいないからである。これは、失効が、ePUFデバイスのアリスの使用中止およびCRPのデータベースのパージと同じくらい単純であり得ることを意味する。
【0190】
後の節で、この自己主権失効がブロックチェーンの証明および証拠提示によってよりロバストにされ得る方法が開示されており、それにより、後で外部の当事者を納得させ得る。
【0191】
3.5. アイデンティティベースのCRP管理
上記の、特にリモートPUFベースのアイデンティティシステムでは、セットアップおよび検証プロトコルでアイデンティティを認証するために使用されるCRPの1回使用の性質は、関与する当事者に対してCRP管理チャレンジを提示する。
上記の、特にリモートPUFベースのアイデンティティシステムでは、セットアップおよび検証プロトコルでアイデンティティを認証するために使用されるCRPの1回使用の性質は、関与する当事者に対してCRP管理チャレンジを提示する。
【0192】
たとえば、信頼できる第三者がセットアップ時にPUFデバイスにアクセスしない場合、将来の検証のために第三者に対して多くのCRP{(C1, R1),(C2, R2), ..., (Cn, Rn)}が列挙されることが望ましい場合がある。さらに、ePUFそれ自体が応答へのチャレンジの決定論的擬似ランダムマッピングとして機能するので、応答は相互に無関係であるように見える。したがって、信頼できる第三者がそのユーザまたはクライアントのためにCRPのセットを表にし、記憶する負担は、それらが多数のユーザにサービスを提供しなければならない場合にたちまちスケーリング問題をもたらす。
【0193】
図8Aは、本明細書において開示されている実施形態による識別データからのチャレンジの決定論的導出を例示している。
【0194】
そのような実施形態によれば、信頼できる第三者への負担の問題に対処するために、CRP管理は、チャレンジC1、C2、...,Cnの生成において主に扱われる。ここでの考え方は、チャレンジは、単一のマスターチャレンジ、またはマスターチャレンジが導出されるマスターデータから決定論的に(および場合によっては階層的にも)導出されるべきであるというものである。この概念は、1回使用のビットコイン鍵を管理するための階層的決定論的(HD)ウォレットの使用に、信頼できる第三者(または別の関連する当事者)がビットコインのシナリオにおいて「ウォレットシード」と呼ばれるマスターデータのみを使用してすべての関連するチャレンジを回復することを可能にするように設計されているという点で類似している。
【0195】
いくつかのそのような実施形態において、アリス(ターゲット当事者103T)の識別データ806は、前の節で提案されたものなどのアイデンティティシステムでどのCRPが使用されるかを決定するための広範囲にわたるチャレンジを生成するマスターデータとして使用される。識別データそれ自体は、異なるデータ要素802の組合せ804を含み得るが、組合せにおいて、それらは好ましくは次の特性を有する。
・ 一意性-識別データは、それが関係するエンティティに対して一意的である。
・ 秘密性-識別データは、それが関係するエンティティ(またはその所有者)のみに知られている。
・ 一意性-識別データは、それが関係するエンティティに対して一意的である。
・ 秘密性-識別データは、それが関係するエンティティ(またはその所有者)のみに知られている。
【0196】
識別データの構成要素の単純な例は、パスポート番号、国民保険番号、氏名、生年月日、または秘密の質問に対する回答(たとえば、母親の旧姓)、またはデバイス識別の場合にはシリアル番号および製造情報を含み得る。しかしながら、一意性を保存するためにファジーマジック技術を使用して抽出され得る、指紋または顔認識データなどの、より高度な技術的手段によって取得されるデータも使用され得ると認識されている。
【0197】
実施形態において、チャレンジのセットが導出されるマスター入力として使用される「識別データ」は、上記の多様性を含み得る。これに対する理由の1つは、前の節のプロトコルのいくつかが第三者および/または外部検証者とチャレンジを共有することに依存しているとした場合にできるだけ多くの信頼できる第三者に関する秘密を情報が保持することを確実にすることである。複数のコンポーネントを含む識別データは、証明者アリスの同意なしに任意の第三者が完全に複製することは困難であろう。
【0198】
識別データを使用して決定論的にCRPを生成するためのメカニズムが図8Aに示されている。識別データの構成部分は、第1に、プロセス「A」(804)によって組み合わされ、これは、連結、ビット演算(たとえば、XOR)または任意の他の関連する組合せ演算であってもよく、この演算は、生データを難読形式に変換することによってプライバシーを保持することを求めるものとしてよいことに留意されたい。
【0199】
次いで、識別データは、ハッシュ関数または類似のプロセスを用いて、マスターチャレンジCmに変換される。最後に、マスターチャレンジは、導出関数f()を使用して、1回使用チャレンジC1、C2、...、Cnのシーケンスを決定論的に導出するために使用される。実施形態において、図8Bに示されているように、導出関数f()は、ハッシュ関数およびノンスの注入を含むものとしてよく、それにより各連続チャレンジは、Ci=SHA256(Ci-1,i)として生成され、iはノンスとして働く。
【0200】
プロセスA、識別データからのチャレンジCmの生成、および導出関数f()はすべて、特定の実装形態の必要性に応じて構成され得る。
【0201】
図8Cは、別の特定の例、すなわち、チャレンジの階層的で決定論的な導出を示す(応答は描かれていない)。図8Bに示されているように、階層的方式でマスターCmから1回使用のチャレンジCiを導出することが望ましい場合がある。この場合、CRP管理は、特定のチャレンジの生成が、前のケースのように、前のチャレンジのすべてに依存する必要がないという事実によってさらに改善される。
【0202】
アイデンティティデータに基づくチャレンジの決定論的導出の使用は、アイデンティティプロトコルにおける証明者アリスおよび信頼できる第三者の両方に対するストレージオーバーヘッドを低減する。いずれの当事者も、識別データ(またはそのサブセット)のみを記憶し、必要なチャレンジを、必要に応じて必要なときに、再計算することが可能である。
【0203】
さらに、アリスは、各識別サービスと望むだけ多くの情報を保留するか、または共有することを選択することによって自分のプライバシーを手直しするオプションも有するが、より多くのデータを自分で保存し得るトレードオフもある。
【0204】
4. 例示的なブロックチェーンシステム
次に、本開示のいくつかの実施形態において採用され得る例示的なブロックチェーンシステムを説明する。「アリス」および「ボブ」は、2つの当事者に対する任意の名前にすぎず、アリスおよびボブは、この節では前の節または次の節と必ずしも同じ役割を有するわけではない。
次に、本開示のいくつかの実施形態において採用され得る例示的なブロックチェーンシステムを説明する。「アリス」および「ボブ」は、2つの当事者に対する任意の名前にすぎず、アリスおよびボブは、この節では前の節または次の節と必ずしも同じ役割を有するわけではない。
【0205】
いくつかの実施形態において、PUFの出力に基づく応答データは、たとえば前の節で説明されているように、チェーン上に記憶され得る。チェーン上に記憶された応答データは、実際の応答それ自体、またはハッシュもしくはダブルハッシュ(いわゆる証明もしくはハッシュコミット)などの応答の変換、またはPUF応答から導出された公開鍵-秘密鍵ペアの公開鍵の形態をとり得る。オンチェーン応答データがどのような形態をとるにせよ、それは、別の検証者が、アイデンティティの証拠として提示されるターゲット応答または署名が期待通りであるかどうかをチェックすることを可能にする何かである。さらなる実施形態において、ブロックチェーンは、チャレンジ応答ペアを、更新するかまたは取り消すなど、管理する手段として使用され得る。
【0206】
次に、そのような特徴を実装するために使用され得るブロックチェーンシステムの一例を説明する。
【0207】
4.1. 例示的システム概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、典型的にはインターネットなどのワイドエリアインターネットワークを備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)ネットワーク106を形成するように配置構成され得る複数のブロックチェーンノード104を含む。例示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフとして配置構成され得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104と高度に接続されている。
図1は、ブロックチェーン150を実装するための例示的なシステム100を示している。システム100は、パケット交換ネットワーク101、典型的にはインターネットなどのワイドエリアインターネットワークを備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内にピアツーピア(P2P)ネットワーク106を形成するように配置構成され得る複数のブロックチェーンノード104を含む。例示されていないが、ブロックチェーンノード104は、ほぼ完全なグラフとして配置構成され得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104と高度に接続されている。
【0208】
各ブロックチェーンノード104は、ピアのコンピュータ機器を含み、ノード104のうちの異なるノードは異なるピアに属す。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば1つまたは複数の中央演算処理装置(CPU)、アクセラレータプロセッサ、特定用途プロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途集積回路(ASIC)などの他の機器を含む処理装置を含む。各ノードは、また、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読記憶装置を含む。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光学媒体を採用する1つまたは複数のメモリユニットを含み得る。
【0209】
ブロックチェーン150は、データのブロック151を含み、ブロックチェーン150のそれぞれのコピーは、分散型またはブロックチェーンネットワーク106内の複数のブロックチェーンノード104の各々において維持される。上述のように、ブロックチェーン150のコピーを維持することは、必ずしもブロックチェーン150を完全に記憶することを意味しない。その代わりに、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(後述)を記憶する限りブロックチェーン150はデータを剪定され得る。チェーン内の各ブロック151は、1つまたは複数のトランザクション152を含み、この文脈でのトランザクションは、一種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、全体を通して1つの特定のトランザクションプロトコルを使用する。トランザクションプロトコルの1つの共通のタイプにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力と少なくとも1つの出力とを含む。各出力は、財産としてのデジタル資産の数量を表す額を指定し、その一例は、出力が暗号学的にロックされている(ロックを解除し、それによって償還または支出されるためにそのユーザの署名または他の解を必要とする)ユーザ103である。各入力は、先行するトランザクション152の出力を指し示し、それによってトランザクションをリンクする。
【0210】
各ブロック151は、また、ブロック151に順序を定義するように、チェーン内の以前に作成されたブロック151を指すブロックポインタ155を含んでいる。各トランザクション152(コインベーストランザクション以外の)は、トランザクションのシーケンスに順序を定義するように、前のトランザクションを指すポインタを含む(注:トランザクションのシーケンス152は分岐することが許されている)。ブロック151のチェーンは、チェーン内の最初のブロックであったジェネシスブロック(Gb)153にまで遡る。チェーン150内の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくむしろジェネシスブロック153を指していた。
【0211】
ブロックチェーンノード104の各々は、トランザクション152を他のブロックチェーンノード104に転送し、それによってトランザクション152をネットワーク106全体に伝播するように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード104は、また、ブロック151内に組み込まれるのを待っているトランザクション152の順序付けられたセット(または「プール」)154を維持する。順序付けられたプール154は、「mempool」と称されることが多い。本明細書のこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図されていない。それは、ノード104が有効であるとして受け入れたトランザクションの順序付けられたセットを指し、それに対してノード104は、同じ出力を消費することを試みる任意の他のトランザクションを受け入れないようにする義務がある。
【0212】
所与の現在のトランザクション152jにおいて、その(または各)入力は、トランザクションのシーケンス内の先行するトランザクション152iの出力を参照するポインタを含み、この出力が現在のトランザクション152jにおいて償還されるかまたは「消費」されるべきであることを指定する。一般に、先行するトランザクションは、順序付きセット154または任意のブロック151内の任意のトランザクションである可能性がある。先行するトランザクション152iは、現在のトランザクション152jが作成されるか、またはさらにはネットワーク106に送信された時点では必ずしも存在している必要はないが、現在のトランザクションが有効であるためには先行するトランザクション152iが存在し、承認される必要がある。したがって、本明細書における「先行する」は、必ずしも時間的シーケンスにおける作成または送信の時点ではない、ポインタによってリンクされた論理的シーケンス内の先行要素を指し、したがって、トランザクション152i、152jが順序から外れて作成されるか、または送信されることを必ずしも排除しない(オーファントランザクションに関する以下の説明を参照)。先行するトランザクション152iは、等しく前のトランザクションまたは先行トランザクションと呼ばれることも可能である。
【0213】
本トランザクション152jの入力は、また、入力認可、たとえば先行するトランザクション152iの出力がロックされているユーザ103aの署名も含む。次に、本トランザクション152jの出力は、新規ユーザまたはエンティティ103bに暗号的にロックされ得る。本トランザクション152jは、したがって、本トランザクション152jの出力で定義されるように先行するトランザクション152iの入力で定義された額を新規ユーザまたはエンティティ103bに転送することができる。いくつかの場合において、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、釣り銭を渡すために元のユーザまたはエンティティ103aである可能性もある)の間で入力額を分割するために複数の出力を有し得る。いくつかの場合において、トランザクションは、1つまたは複数の先行するトランザクションの複数の出力から金額を集め、現在のトランザクションの1つまたは複数の出力に再分配するための複数の入力を有することもできる。
【0214】
ビットコインなどの出力ベースのトランザクションプロトコルによれば、個人ユーザまたは組織などの当事者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のネットワーク全体に伝播される。
【0215】
出力ベースモデルでは、所与の出力(たとえばUTXO)が割り当てられた(たとえば消費された)かどうかの定義は、ブロックチェーンノードプロトコルに従って、別の、前方のトランザクション152jの入力によってまだ有効に償還されているかどうかである。トランザクションが有効であるための別の条件は、償還することを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ償還されていないことである。ここでもまた有効でない場合、トランザクション152jは伝播されないか(警告のために無効であるとフラグが立てられ伝播されない限り)、またはブロックチェーン150に記録されない。これは、トランザクション実行者が同じトランザクションの出力を複数回割り当てようとする二重支払いから保護するものである。その一方で、アカウントベースモデルは、勘定残高を維持することによって二重支払いを防止する。ここでもまたトランザクションの定められた順序があるので、勘定残高はどの時点においても単一の定義済み状態を有する。
【0216】
トランザクションを承認することに加えて、ブロックチェーンノード104は、「プルーフオブワーク」によってサポートされる、マイニングと一般的に称されるプロセスでトランザクションのブロックを最初に作成するものとなる競争を行う。ブロックチェーンノード104では、新規トランザクションが、ブロックチェーン150上に記録されたブロック151内にまだ出現していない有効なトランザクションの順序付けられたプール154に追加される。次いで、ブロックチェーンノードは、暗号パズルを解くことを試みることによってトランザクション152の新しい有効なブロック151を、トランザクション154の順序付けられたセットから組み立てる競争をする。典型的には、これは、「ノンス」を探索することであって、ノンスが保留トランザクション154の順序付けられたプールの表現と連結されハッシュされたときにハッシュの出力が所定の条件を満たすような、探索することを含む。たとえば、所定の条件は、ハッシュの出力が特定の事前定義済みの数の先行ゼロを有することであり得る。これは1つの特定のタイプのプルーフオブワークパズルにすぎず、他のタイプは排除されない。ハッシュ関数の特性は、入力に対して予測不可能な出力を有するという性質である。したがって、この探索は総当りによってのみ実行することができ、したがって、パズルを解こうとしている各ブロックチェーンノード104において処理リソースの実質的な量が消費される。
【0217】
パズルを解いた最初のブロックチェーンノード104は、これをネットワーク106に発表し、ネットワーク内の他のブロックチェーンノード104が容易にチェックできる証明として解を提供する(ハッシュの解が与えられれば、それがハッシュの出力を条件に合致させることをチェックするのは容易である)。最初のブロックチェーンノード104は、ブロックを受け入れる他のノードの閾値コンセンサスにブロックを伝播し、したがって、プロトコルルールを強制する。次いで、トランザクション154の順序付けられたセットは、ブロックチェーンノード104の各々によってブロックチェーン150内に新しいブロック151として記録されるようになる。ブロックポインタ155も、チェーン内の以前に作成されたブロック151n-1を指す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要な、たとえばハッシュの形態の、著しい量の労力は、ブロックチェーンプロトコルのルールに従う第1のノード104の意向をシグナリングする。そのようなルールは、以前に承認されたトランザクションと同じ出力を割り当てる場合にトランザクションを有効なものとして受け入れないことを含むが、これは他の場合には二重支払いとしても知られている。作成された後、ブロック151は、ブロックチェーンネットワーク106内のブロックチェーンノード104の各々で認識され維持されるので、修正できない。ブロックポインタ155は、また、ブロック151に順序を課す。トランザクション152は、ネットワーク106内の各ブロックチェーンノード104において順序付けられたブロックに記録されるので、これはしたがって、トランザクションの不変の公開台帳を提供する。
【0218】
任意の所与の時点でパズルを解く競争をしている異なるブロックチェーンノード104は、解を探し始めた時期またはトランザクションが受信された順序に応じて、任意の所与の時点でまだ公開されていないトランザクション154のプールの異なるスナップショットに基づきそうするものとしてよいことに留意されたい。それぞれのパズルを最初に解いた者は、どのトランザクション152が次の新しいブロック151nに含まれ、どの順序で含まれるかを定義し、未公開トランザクションの現在のプール154は更新される。次いで、ブロックチェーンノード104は、未公開トランザクション154の新規に定義された順序付きプールからブロックを作成する競争をする、というように続ける。また、2つのブロックチェーンノード104がブロックチェーンの対立する見解がノード104間で伝播されるような互いの非常に短い時間内にパズルを解く場合である、発生し得る任意の「フォーク」を解決するためのプロトコルも存在する。要するに、フォークのどの分岐が最も長く成長しても、決定的なブロックチェーン150になる。これは同じトランザクションが両方のフォークに出現するときにネットワークのユーザまたはエージェントに影響を及ぼしてはならないことに留意されたい。
【0219】
ビットコインブロックチェーン(およびほとんどの他のブロックチェーン)によれば、新しいブロック104を首尾よく構成したノードは、デジタル資産の追加の定められた量を分配する新しい特殊な種類のトランザクションにおいてデジタル資産の追加の受け入れられた額を新しく割り当てる能力を付与される(1人のエージェントまたはユーザから別のエージェントまたはユーザへデジタル資産の額を転送するエージェント間、またはユーザ間のトランザクションとは対照的に)。この特別なタイプのトランザクションは通常「コインベーストランザクション」と称されるが、「開始トランザクション」または「生成トランザクション」と呼ばれることもある。これは、典型的には、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、新しいブロックを構築するノードが、この特別なトランザクションが後で償還されることを可能にするプロトコルルールに従うという意向をシグナリングする。ブロックチェーンプロトコルルールでは、この特別なトランザクションが償還され得る前に償還期限、たとえば100ブロック分を必要とし得る。多くの場合に、正規の(非生成)トランザクション152は、また、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を払うために出力の1つで追加のトランザクション手数料を指定する。この手数料は、通常、「トランザクション手数料」と称され、以下で説明する。
【0220】
トランザクションの承認および公開に関与するリソースに起因して、典型的には、ブロックチェーンノード104の少なくとも各々は、1つまたは複数の物理的サーバユニットを含むサーバ、またはさらにはデータセンター全体の形態をとる。しかしながら、原理上、任意の所与のブロックチェーンノード104は、ユーザ端末またはネットワーク接続されたユーザ端末のグループの形態をとることも可能である。
【0221】
各ブロックチェーンノード104のメモリは、ブロックチェーンノードプロトコルに従ってそれぞれの1つまたは複数の役割を遂行し、トランザクション152を処理するためにブロックチェーンノード104の処理装置上で実行するように構成されているソフトウェアを記憶する。本明細書においてブロックチェーンノード104に帰される任意の活動は、それぞれのコンピュータ機器の処理装置上で実行されるソフトウェアによって実行され得ることは理解されるであろう。ノードソフトウェアは、アプリケーション層、またはオペレーティングシステム層もしくはプロトコル層などの下位層、またはこれらの任意の組合せにおける1つまたは複数のアプリケーションで実装され得る。
【0222】
また、ネットワーク101に接続されているのは、消費ユーザの役割を担う複数の当事者103の各々のコンピュータ機器102である。これらのユーザは、ブロックチェーンネットワーク106とインタラクティブにやり取りし得るが、トランザクションを承認することまたはブロックを構築することに参加することはない。これらのユーザまたはエージェント103のいくつかは、トランザクションにおける送信者および受信者として働き得る。他のユーザは、必ずしも送信者または受信者として活動することなくブロックチェーン150とインタラクティブにやり取りし得る。たとえば、いくつかの当事者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得している)ストレージエンティティとして働き得る。
【0223】
当事者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の当事者」と置き換えてもよいことは理解されるであろう。
【0224】
各当事者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つまたは複数の他のネットワーク接続リソースも備え得る。
【0225】
クライアントアプリケーション105は、たとえばサーバからダウンロードされた、好適なコンピュータ可読記憶媒体上で任意の所与の当事者103のコンピュータ機器102に最初に提供され得るか、または取り外し可能SSD、フラッシュメモリキー、取り外し可能EEPROM、取り外し可能磁気ディスクドライブ、磁気フロッピーディスクもしくはテープなどの取り外し可能記憶デバイス、CDまたはDVD ROMなどの光ディスク、または取り外し可能光学式ドライブなど、で提供され得る。
【0226】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を備える。これは、主に2つの機能性を有する。これらのうちの1つは、それぞれの当事者103が、トランザクション152を作成し、認可し(たとえば署名し)、1つまたは複数のビットコインノード104に送信して、次いでブロックチェーンノード104のネットワーク全体に伝播させ、それによってブロックチェーン150に含まれることを可能にすることである。他は、それぞれの当事者に、現在所有しているデジタル資産の額を報告することである。出力ベースシステムでは、この第2の機能は、ブロックチェーン150全体に散らばる様々なトランザクション152の出力において定められた、注目する当事者に属す金額を照合することを含む。
【0227】
注:様々なクライアント機能が所与のクライアントアプリケーション105に統合されていると説明され得るが、これは必ずしも限定するものではなく、その代わりに本明細書において説明されている任意のクライアント機能が、代わりに、2つまたはそれ以上の異なるアプリケーションの組、たとえば、APIを介してインターフェースされるか、または一方が他方へのプラグインされるもので実装され得る。より一般的には、クライアント機能は、アプリケーション層、またはオペレーティングシステムなどの下位層、またはこれらの任意の組合せで実装されることも可能である。次に、クライアントアプリケーション105に関して説明されるが、これは限定的なものではないことは理解されるであろう。
【0228】
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がネットワーク106にトランザクション152を送信することを可能にする。クライアント105は、また、それぞれの当事者103が受信者である任意のトランザクションについてブロックチェーン150を問い合わせる(または実施形態ではブロックチェーン150は、一部はその公共の可視性を通してトランザクションに信頼を提供する公共の施設であるので、実際にブロックチェーン150内の他の当事者のトランザクションを検査する)ためにブロックチェーンノード104と連絡を取ることができる。各コンピュータ機器102上のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を定式化し送信するように構成される。上で述べたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を承認し、ブロックチェーンネットワーク106全体に伝播させるためにトランザクション152を転送するように構成されたソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルと一緒になり、一緒に所与のトランザクションモデルを実装する。同じトランザクションプロトコルは、ブロックチェーン150内のすべてのトランザクション152に使用される。同じノードプロトコルは、ネットワーク106内のすべてのノード104によって使用される。
【0229】
所与の当事者103、たとえばアリスは、ブロックチェーン150に含まれるべき新しいトランザクション152jを送信することを望むときに、アリスは、関連するトランザクションプロトコルに従って(アリスのクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを定式化する。次いで、アリスは、クライアントアプリケーション105から、自分が接続されている1つまたは複数のブロックチェーンノード104にトランザクション152を送信する。たとえば、これはアリスのコンピュータ102に最もよく接続されているブロックチェーンノード104である可能性もある。任意の所与のブロックチェーンノード104が新規トランザクション152jを受信したときに、これは、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従ってそれを処理する。これは、新しく受信されたトランザクション152jが「有効」であるためのある条件を満たすかどうかを最初にチェックすることを含むが、その例は、まもなくより詳細に説明される。いくつかのトランザクションプロトコルでは、検証のための条件は、トランザクション152に含まれるスクリプトによってトランザクション毎に構成可能であり得る。
【0230】
代替的に、この条件は、単純にノードプロトコルの組み込み機能であるか、またはスクリプトとノードプロトコルとの組合せによって定義されることも可能である。
【0231】
新たに受信されたトランザクション152jが有効とみなされることについてのテストに合格するという条件で(すなわち、それが「承認される」という条件で)、トランザクション152jを受信する任意のブロックチェーンノード104は、そのブロックチェーンノード104で維持されているトランザクション154の順序付けられたセットに新しい承認されたトランザクション152を追加する。さらに、トランザクション152jを受信した任意のブロックチェーンノード104は、承認されたトランザクション152をネットワーク106内の1つまたは複数の他のブロックチェーンノード104に前方伝播される。各ブロックチェーンノード104は同じプロトコルを適用するので、次いで、トランザクション152jが有効であると仮定すると、これは、それがすぐにネットワーク106全体にわたって伝播されることを意味する。
【0232】
所与のブロックチェーンノード104で維持されている保留トランザクション154の順序付けられたプールに入るのを許された後、そのブロックチェーンノード104は、新しいトランザクション152を含むそれぞれのプール154の最新バージョンでプルーフオブワークパズルを解く競争を開始する(他のブロックチェーンノード104はトランザクション154の異なるプールに基づきパズルを解こうとしている可能性があるが、最初にそこに辿り着いた者が最新のブロック151に含まれるトランザクションの集合を定義するということを覚えておこう。最終的にブロックチェーンノード104は、アリスのトランザクション152jを含む順序付けられたプール154の一部に対するパズルを解くことになる。)新規トランザクション152jを含むプール154に対してプルーフオブワークが行われた後、それは、不変的に、ブロックチェーン150内のブロック151のうちの1つの一部となる。各トランザクション152は、以前のトランザクションを指すポインタを含み、したがってトランザクションの順序もまた、不変的に記録される。
【0233】
異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスを最初に受信し、したがって、インスタンスが新しいブロック151において公開される、すべてのブロックチェーンノード104が公開されたインスタンスが唯一の有効インスタンスであると合意する時点より前に、どのインスタンスが「有効」であるかについて対立する見解を有することがある。ブロックチェーンノード104が1つのインスタンスを有効なものとして受け入、次いで第2のインスタンスがブロックチェーン150に記録されていることを発見した場合、そのブロックチェーンノード104はこれを受け入れなければならず、最初に受け入れたインスタンス(すなわち、ブロック151で公開されていないもの)を破棄する(すなわち、無効として扱う)ことになる。
【0234】
いくつかのブロックチェーンネットワークによって運用されるトランザクションプロトコルの代替的タイプは、アカウントベーストランザクションモデルの一部として、「アカウントベース」プロトコルと称され得る。アカウントベースのケースでは、各トランザクションは、過去のトランザクションのシーケンス内において先行するトランザクションのUTXOを参照することによって振替金額を定義するのではなく、むしろ絶対的な口座残高を参照することによって振替金額を定義する。すべての口座の現在の状態は、ブロックチェーンとは別の、そのネットワークのノードによって記憶され、常に更新される。そのようなシステムでは、トランザクションは、口座の実行中トランザクション集計(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者によって署名され、トランザクション参照計算の一部としてハッシュ化される。それに加えて、任意のデータフィールドもトランザクションにおいて署名され得る。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合に、以前のトランザクションを指してもよい。
【0235】
4.2. UTXOベースモデル
図2は、トランザクションプロトコルの例を例示している。これは、UTXOベースプロトコルの一例である。トランザクション152(「Tx」と略記)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースプロトコルを参照して説明される。しかしながら、これは、すべての可能な実施形態に限定されない。例示的なUTXOベースプロトコルは、ビットコインを参照しつつ説明されるが、他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
図2は、トランザクションプロトコルの例を例示している。これは、UTXOベースプロトコルの一例である。トランザクション152(「Tx」と略記)は、ブロックチェーン150の基本的なデータ構造である(各ブロック151は1つまたは複数のトランザクション152を含む)。以下は、出力ベースまたは「UTXO」ベースプロトコルを参照して説明される。しかしながら、これは、すべての可能な実施形態に限定されない。例示的なUTXOベースプロトコルは、ビットコインを参照しつつ説明されるが、他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
【0236】
UTXOベースモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202、および1つまたは複数の出力203を含むデータ構造を備える。各出力203は、(UTXOがまだ償還されていない場合に)別の新しいトランザクションの入力202のソースとして使用され得る、未使用トランザクション出力(UTXO)を含み得る。UTXOは、デジタル資産の額を指定する値を含む。これは、分散台帳上のトークンの設定された数を表す。UTXOは、また、他の情報の中で、その元となったトランザクションのトランザクションIDも含み得る。トランザクションデータ構造は、また、入力フィールド202および出力フィールド203のサイズのインジケータを含み得る、ヘッダ201を備え得る。ヘッダ201は、また、トランザクションのIDを含むものとしてよい。実施形態において、トランザクションIDは、トランザクションデータのハッシュ(トランザクションIDそれ自体を除く)であり、ノード104に提出された生のトランザクション152のヘッダ201に記憶される。
【0237】
たとえば、アリス103aが、注目しているデジタル資産の額をボブ103bに転送するトランザクション152jを作成することを望んでいる。図2において、アリスの新規トランザクション152jは「Tx1」とラベル付けされている。これは、シーケンス内の先行するトランザクション152iの出力203においてアリスにロックされているデジタル資産の額を取り、これの少なくとも一部をボブに転送する。先行するトランザクション152iは、図2において「Tx0」とラベル付けされている。Tx0およびTx1は、任意のラベルにすぎない。これらは、必ずしも、Tx0がブロックチェーン151の最初のトランザクションであることも、Tx1がプール154内のすぐ次のトランザクションであることも意味しない。Tx1は、アリスにロックされた未使用の出力203を依然として有する任意の先行する(すなわち前の)トランザクションを指すことも可能である。
【0238】
先行するトランザクションTx0は、アリスが新規トランザクションTx1を作成する時点、または少なくともネットワーク106に送信する時点までに、すでに正当性を確認され、ブロックチェーン150のブロック151に含まれているものとしてよい。それは、その時点でブロック151のうちの1つにすでに含まれているか、または順序付けられたセット154においてまだ待機しているものとしてよく、その場合、それはすぐに新しいブロック151に含まれることになる。代替的に、Tx0およびTx1は、一緒に作成されてネットワーク106に送信される可能性があるか、またはTx0は、ノードプロトコルが「オーファン」トランザクションのバッファリングを可能にする場合にTx1の後に送信され得ることすら可能である。トランザクションのシーケンスの文脈で本明細書において使用されている「先行する」および「後続の」という言い回しは、トランザクションで指定されたトランザクションポインタ(どのトランザクションがどの他のトランザクションを指しているか、など)によって定義されるようなシーケンス内のトランザクションの順序を指している。これらは、等しく、「先行要素」および「後続要素」、または「前要素」および「子孫」、「親」および「子」、またはそのようなものと置き換えられることも可能である。これは、必ずしも、それらが作成され、ネットワーク106に送信され、または任意の所与のブロックチェーンノード104に到着する順序を暗示するものではない。それでもなお、先行するトランザクション(前のトランザクションまたは「親」)を指す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが承認されるまで、また承認がなされない限り、承認されない。親よりも先にブロックチェーンノード104に到着した子は、オーファンとみなされる。それは、ノードプロトコルおよび/またはノードの挙動に応じて、親を待つために廃棄されるか、または一定時間バッファリングされ得る。
【0239】
先行するトランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされている、特定のUTXOを含む。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが承認され、したがってUTXOが首尾良く償還されるために後続のトランザクションの入力202のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトとを含む。典型的には、ロックスクリプトは、金額を特定の当事者(それが含まれるトランザクションの受益者)にロックする。すなわち、ロックスクリプトは、典型的には、後続のトランザクションの入力におけるロック解除スクリプトが、先行するトランザクションがロックされている当事者の暗号署名を含む条件を含む、ロック解除条件を定義する。
【0240】
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有言語で書かれたコードの断片である。このような言語の特定の例は、ブロックチェーンネットワークで使用される「Script」(大文字のS)と呼ばれる。ロックスクリプトは、たとえばアリスの署名の要件など、トランザクション出力203を消費するために必要な情報を指定する。ロック解除スクリプトは、トランザクションの出力内に出現する。ロック解除スクリプト(別名scriptSig)は、ロックスクリプトの基準を満たすために必要な情報を提供するドメイン固有言語で書かれたコードの断片である。たとえば、これはボブの署名を含み得る。ロック解除スクリプトは、トランザクションの入力202内に出現する。
【0241】
したがって、例示されている例では、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>をさらに含む。有効な署名を提供するためにアリスによって署名される必要があるデータ(または「メッセージ」)は、ロックスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
【0242】
新規トランザクションTx1がブロックチェーンノード104に到着すると、そのノードは、ノードプロトコルを適用する。これは、ロックスクリプトおよびロック解除スクリプトを一緒に実行して、ロック解除スクリプトがロックスクリプトで定義されている条件(ここで、この条件は1つまたは複数の基準を含み得る)を満たすかどうかをチェックすることを含む。実施形態では、これは、2つのスクリプトを次のように連結することを含む。
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロックスクリプト(この例ではスタックベースの言語)によって構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなくむしろ、共通のスタックにより、他方の後にスクリプトを次々に実行され得る。いずれにせよ、一緒に実行したときに、スクリプトは、Tx0の出力内にあるロックスクリプトに含まれるような、アリスの公開鍵PAを使用して、Tx1の入力内にあるロック解除スクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するために、データそれ自体の期待される部分(「メッセージ」)も含まれる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、すでに本質的に存在しているので、データの署名された部分を平文で指定する別の要素が含まれる必要はない)。
<Sig PA> <PA> || [Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロックスクリプト(この例ではスタックベースの言語)によって構成される関数である。同等に、スクリプトは、スクリプトを連結するのではなくむしろ、共通のスタックにより、他方の後にスクリプトを次々に実行され得る。いずれにせよ、一緒に実行したときに、スクリプトは、Tx0の出力内にあるロックスクリプトに含まれるような、アリスの公開鍵PAを使用して、Tx1の入力内にあるロック解除スクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。この認証を実行するために、データそれ自体の期待される部分(「メッセージ」)も含まれる必要がある。実施形態において、署名されたデータは、Tx1の全体を含む(したがって、すでに本質的に存在しているので、データの署名された部分を平文で指定する別の要素が含まれる必要はない)。
【0243】
公開秘密暗号による認証の詳細は、当業者には馴染み深いものであろう。基本的に、アリスが自分の秘密鍵を使用してメッセージを署名している場合、アリスの公開鍵および平文のメッセージが与えられれば、ノード104などの別のエンティティは、メッセージがアリスによって署名されたに違いないと認証することができる。署名は、典型的には、メッセージをハッシュ化し、ハッシュに署名し、これを署名としてメッセージにタグ付けすることを含み、したがって公開鍵の保有者は誰でも署名を認証することができる。したがって、特定のデータ部分またはトランザクションの一部などに署名するという本明細書の言及は、実施形態において、そのデータ部分またはトランザクションの一部のハッシュに署名することを意味し得ることに留意されたい。
【0244】
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内の別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
【0245】
所与のトランザクション152のすべての出力203で指定された総額が、そのすべての入力202によって指されている総額よりも大きい場合、これはほとんどのトランザクションモデルにおいて無効であることに対する別の基準である。したがって、そのようなトランザクションは伝播されず、ブロック151に含まれることもない。
【0246】
UTXOベーストランザクションモデルでは、所与のUTXOは全体として消費される必要があることに留意されたい。UTXOにおいて定義された金額の一部を、別の部分が消費されている間に、消費済みとして「残す」ことはできない。しかしながら、UTXOからの金額は、次のトランザクションの複数の出力の間に分割され得る。たとえば、Tx0のUTXO0で定義されている金額は、Tx1における複数のUTXOの間に分割され得る。したがって、アリスがボブにUTXO0で定義された金額のすべてを与えたくない場合、アリスは、残りをTx1の第2の出力で自分自身に釣り銭を渡すか、または他の当事者に支払うために使用することができる。
【0247】
実際には、アリスは、通常、自分のトランザクション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つにおいて明示的に指定されることが可能であることは、必ずしも除外されない。
【0248】
アリスおよびボブのデジタル資産は、ブロックチェーン150内のどこかにある任意のトランザクション152において彼らにロックされたUTXOからなる。したがって、典型的には、所与の当事者103の資産は、ブロックチェーン150全体における様々なトランザクション152のUTXO全体を通して散らばっている。所与の当事者103の総残高を定義する1つの数がブロックチェーン150内のどこかに記憶されているわけではない。それぞれの当事者にロックされ、別の前方のトランザクションでまだ消費されていないすべての様々なUTXOの値をまとめて照合するのはクライアントアプリケーション105内のウォレット機能の役割である。ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーに問い合わせることによってこれを行うことができる。
【0249】
スクリプトコードは、多くの場合に概略として表現される(すなわち、正確な言語を使用しない)ことに留意されたい。たとえば、特定の機能を表現するためにオペレーションコード(opcode)を使用してもよい。「OP_...」は、Script言語の特定のオペコードを指す。一例として、OP_RETURNは、ロックスクリプトの始めにOP_FALSEが先行するときに、トランザクション内にデータを記憶することができるトランザクションの消費不可能な出力を作成し、それによってデータをブロックチェーン150内に不変的に記録する、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を含み得る。
【0250】
典型的には、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態において、これは楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、特定のデータに署名するものである。いくつかの実施形態において、所与のトランザクションについて、署名は、トランザクション入力の一部と、トランザクション出力の一部または全部に署名する。署名する出力の特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、通常、どの出力が署名される(したがって、署名の時点で固定される)かを選択する署名の最後に含まれる4バイトコードである。
【0251】
ロックスクリプトは、これが典型的にはそれぞれのトランザクションがロックされる当事者の公開鍵を含むという事実を指して、「scriptPubKey」と呼ばれることがある。ロック解除スクリプトは、典型的には対応する署名を提供するという事実を指す「scriptSig」と呼ばれることがある。しかしながら、より一般的に、ブロックチェーン150のすべてのアプリケーションにおいて、UTXOが償還されるための条件が署名を認証することを含むことは不可欠でない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用されることが可能である。したがって、より一般的な用語である「ロックスクリプト」および「ロック解除スクリプト」が好まれ得る。
【0252】
4.3. サイドチャネル
図1に示されているように、アリスおよびボブのコンピュータ機器102a、102bの各々の上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、アリス103aが、ボブ103bと(いずれかの当事者または第三者の扇動で)別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークから離れてデータを交換することを可能にする。そのような通信は、ときには「オフチェーン」通信と称される。たとえば、これは、当事者の一方がネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されることなく、またはチェーン150上を進むことなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。このようにトランザクションを共有することは、ときには、「トランザクションテンプレート」を共有すると称される。トランザクションテンプレートは、完全なトランザクションを形成するために必要な1つまたは複数の入力および/または出力を欠いている場合がある。代替的に、またはそれに加えて、サイドチャネル107は、鍵、交渉された金額または条件、データコンテンツなどの任意の他のトランザクション関係データを交換するために使用され得る。
図1に示されているように、アリスおよびボブのコンピュータ機器102a、102bの各々の上のクライアントアプリケーションは、それぞれ、追加の通信機能を備え得る。この追加の機能は、アリス103aが、ボブ103bと(いずれかの当事者または第三者の扇動で)別個のサイドチャネル107を確立することを可能にする。サイドチャネル107は、ブロックチェーンネットワークから離れてデータを交換することを可能にする。そのような通信は、ときには「オフチェーン」通信と称される。たとえば、これは、当事者の一方がネットワーク106にブロードキャストすることを選択するまで、トランザクションが(まだ)ブロックチェーンネットワーク106に登録されることなく、またはチェーン150上を進むことなく、アリスとボブとの間でトランザクション152を交換するために使用され得る。このようにトランザクションを共有することは、ときには、「トランザクションテンプレート」を共有すると称される。トランザクションテンプレートは、完全なトランザクションを形成するために必要な1つまたは複数の入力および/または出力を欠いている場合がある。代替的に、またはそれに加えて、サイドチャネル107は、鍵、交渉された金額または条件、データコンテンツなどの任意の他のトランザクション関係データを交換するために使用され得る。
【0253】
サイドチャネル107は、ブロックチェーンネットワーク106と同じパケット交換ネットワーク101を介して確立され得る。代替的に、またはそれに加えて、サイドチャネル301は、モバイルセルラーネットワークなどの異なるネットワーク、またはローカルワイヤレスネットワークなどのローカルエリアネットワーク、またはアリスのデバイス102aとボブのデバイス102bとの間の直接的な有線またはワイヤレスリンクを介してであっても確立され得る。一般的に、本明細書のどこかで参照されているサイドチャネル107は、「オフチェーン」で、すなわちブロックチェーンネットワーク106とは別に、データを交換するための1つまたは複数のネットワーク技術または通信媒体を介した任意の1つまたは複数のリンクを含み得る。複数のリンクが使用される場合、オフチェーンリンクのバンドルまたはコレクションは全体としてサイドチャネル107と称され得る。したがって、アリスおよびボブが、サイドチャネル107上で、いくつかの情報またはデータまたは類似のものを交換すると言われる場合に、これは必ずしもこれらのデータのすべての部分が全く同じリンクまたは同じタイプのネットワーク上で送信されなければならないことを暗示するものではないことに留意されたい。
【0254】
サイドチャネル107は、アリスとボブなどの当事者間の安全で秘密に保たれたオフチェーン通信を可能にするために知られている安全な通信技術を採用する安全なチャネルを含み得る。たとえば、安全なチャネルは、安全なチャネル上で通信する当事者間で共有される共有秘密に基づき得る。そのようなチャネルは、たとえば、検証者103Vがターゲット当事者によって保有されているPUF302/500にチャレンジを提出し、対応する応答を受信することを可能にするなど、検証者103Vとターゲット当事者103Tとの間の通信に使用され得る。
【0255】
5. ブロックチェーンベースのPUFアイデンティティ証明
前の節で述べたように、応答の記録として働く応答データは、信頼できる第三者システム602を採用するのではなくむしろ、パブリックブロックチェーンに記憶され得る。応答データは、セットアップ時に決定されたデータであり、後に検証者103V(「ボブ」)がターゲット当事者103T(「アリス」)によるターゲットのアイデンティティのアサーションをテストするために使用され得る。ここでもまたアリスおよびボブは単なる任意のラベルであり、アリスおよびボブは、第4節で与えられたブロックチェーンシステムの一般的概要(ボブがアリスのトランザクションの出力を消費していた場合)と同じ役割をここで必ずしも有していないことに留意されたい。
前の節で述べたように、応答の記録として働く応答データは、信頼できる第三者システム602を採用するのではなくむしろ、パブリックブロックチェーンに記憶され得る。応答データは、セットアップ時に決定されたデータであり、後に検証者103V(「ボブ」)がターゲット当事者103T(「アリス」)によるターゲットのアイデンティティのアサーションをテストするために使用され得る。ここでもまたアリスおよびボブは単なる任意のラベルであり、アリスおよびボブは、第4節で与えられたブロックチェーンシステムの一般的概要(ボブがアリスのトランザクションの出力を消費していた場合)と同じ役割をここで必ずしも有していないことに留意されたい。
【0256】
前に説明されているように、所与のCRペア{Ci,Ri}に対する応答データ(チェーン上に記憶されていようと、他の場所に記憶されていようと)は、セットアップフェーズ702で決定され、検証者103Vによる将来参照のために記憶されるように、次のいずれかを含み得る。
i)チャレンジCiおよび/または応答Riの明示的な値(平文または暗号化のいずれか)、または
ii)それぞれの応答Riに対する特定のチャレンジCiが導出され得るマスターチャレンジCmにリンクされた応答Riの明示的な値、または
iii)チャレンジCiの明示的な値とともに応答Riの証明(たとえばハッシュもしくはダブルハッシュ)、または
iv)それぞれの応答Riに対する特定のチャレンジが導出され得るマスターチャレンジCmにリンクされた応答Riの証明(たとえば、ハッシュもしくはダブルハッシュ)、または
v)応答Riから導出された公開鍵-秘密鍵ペアの公開鍵。
i)チャレンジCiおよび/または応答Riの明示的な値(平文または暗号化のいずれか)、または
ii)それぞれの応答Riに対する特定のチャレンジCiが導出され得るマスターチャレンジCmにリンクされた応答Riの明示的な値、または
iii)チャレンジCiの明示的な値とともに応答Riの証明(たとえばハッシュもしくはダブルハッシュ)、または
iv)それぞれの応答Riに対する特定のチャレンジが導出され得るマスターチャレンジCmにリンクされた応答Riの証明(たとえば、ハッシュもしくはダブルハッシュ)、または
v)応答Riから導出された公開鍵-秘密鍵ペアの公開鍵。
【0257】
図9に示されているように、どのような形態をとろうと、セットアップフェーズ702において、そのような応答データ901は、ブロックチェーン150上に記録されたトランザクション152Sの出力203に記憶され得る。これは、以下では、記憶トランザクションと称されることがある。これは、たとえば、上記の第4節で説明された技術を使用してチェーン上に記録されてもよく、ここでもまたその節におけるアリスは必ずしもターゲット当事者103Tではなく、その節におけるボブは必ずしも検証者103Vではないことに留意されたい--実際には、現在アリスと称されている、ターゲット当事者103Tは、チェーン上に記録されるべき記憶トランザクション152Sを定式化して送信する者であってよい。別の例として、信頼できる第三者は、ターゲット当事者103Tに対する記憶トランザクションのテンプレートを定式化し、セットアップ時に生成された応答データ901を含めることによって完成し、次いでチェーン上に記録されるように転送するものとしてよい。ターゲット当事者103Tは、ブロックチェーンネットワーク106を通して伝播されるようにブロックチェーンノード104のうちの1つに直接的に記憶トランザクション152Sを送信し得るか、または信頼できる第三者などの他の当事者を介して間接的に送信し得る。さらに別の例として、ターゲット当事者103Tは、その当事者の応答データ901を信頼できる第三者に送信し、信頼できる第三者は記憶トランザクション152内に定式化し、チェーン上に記録されるように送るものとしてよい。
【0258】
応答データ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)は、前に説明されているブロックチェーンシステムの異なる例示的な実装形態である。
【0259】
代替的に、応答データ901は、記憶トランザクション152Sの消費可能出力内に埋め込まれ得る。たとえば、これは、OP_FALSEなしでOP_RETURNを含めることによって消費可能な状態に保たれることが可能である。別の例として、OP_DROPコードの直前にそれを含めることによって消費可能ロックスクリプトにデータを埋め込むことができる。これは、BTC、BCH、およびBSVに等しく適用されるであろう。
【0260】
実施形態において、所与のターゲット当事者103Tの複数の異なるCRペア{Ci,Ri}のセットの応答データ901が記憶され得る。これらは、記憶トランザクション152の同じ出力203もしくは異なる出力203、または同じ出力にいくつか、異なる出力にいくつかという組合せで、記憶され得る。これらは、同じ記憶トランザクション152Sに記憶され得るか、または異なるCRペアの応答データ901が異なる記憶トランザクション152Sに記憶され得るか、または同じトランザクションにいくつか、異なるトランザクションにいくつかという組合せで記憶され得る。
【0261】
オンチェーン記憶は、必ずしもアカウントベースモデルに限定されないことに留意されたい。代替的な展開では、応答データ901は、アカウントベースモデルの1つまたは複数のトランザクションの1つまたは複数のスマートコントラクトに記憶され得る。
【0262】
検証フェーズ704において、検証者103Vがターゲットのアイデンティティを検証することを望むときに、検証者は、記憶トランザクション152Sから特定の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から取り出された証明と比較する。いずれにせよ、この比較により一致が得られれば、ターゲットは検証される。
【0263】
検証者103Vは、ブロックチェーンネットワーク106のノード104の1つを介して、または代替的にそのデータ(すなわちトランザクション)がブロックチェーンに含まれることのマークル証明も提供し得る、任意の外部当事者から応答データを取得することによってブロックチェーン150にアクセスし得る。
【0264】
応答データ901がブロックチェーン150などの公開媒体に記憶される実施形態において、実際の応答値Riそれ自体が公に、または無制限に、開示されないことが望ましい場合がある。そうでなければ、任意の悪意のある当事者がチェーン上のRiを見ることができ、次いで、Ciでチャレンジされた場合にターゲット当事者103Tのふりをすることができる。したがって、その代わりに、Riの証明(たとえば、H(Ri)またはH2(Ri))のみをチェーン上に保持される応答データ901として記憶するか、またはRiの明示的な値を、ただし暗号化形式で記憶することが好ましい場合がある。または、いくつかの場合において、証明は、暗号化形式でチェーン上に記憶されることも可能である。
【0265】
複数の検証者が潜在的にいる場合、Riまたはその証明を暗号化形式で記憶することは、ターゲット当事者103Tまたは信頼できる第三者がどの検証者103VがCRペアのうちのどれに対応する記憶データ901を取得することができるかを制御することを可能にする。これは、特定の応答データ901の復号鍵を所与の検証者のみに与え、別の応答データ901の復号鍵を別の検証者のみに与えることによって達成され得る。復号化鍵の配布は、ターゲット当事者103Tまたは信頼できる第三者によって管理されることも可能である。各検証者または検証者のサブセットは、応答データ901のそれぞれのサブセット(たとえばCRペア)にアクセスするための1つまたは複数の復号鍵のそれ自身のサブセットを与えられる。好ましくは、サブセットは互いに排他的である。しかしながら、他の実装形態では、それらは重複する可能性もある(たとえば、同じ組織内の異なるグループは、CRペアの重複するサブセットへのアクセス権を有することも可能である)。
【0266】
これの変更形態として、応答データ901(たとえばCRペア)がオンチェーンではなく第三者システム602に記憶される場合、復号鍵を配布する代わりに(あるいはそれに加えて)、各検証者がCRペア(またはより一般的には応答データ)のそれ自身のサブセットへのアクセス権のみを得ることを確実にするように他の手段が採用されてもよい。たとえば、信頼できる第三者システム602は、各検証者に対するパスワード保護アカウントを維持し、それらはチャレンジへのアクセス権を得るためにログインする必要があり、そのアカウントは、それ自身のCRペアへのアクセス権のみを与える。
【0267】
そのようなスキームは、セキュリティに関して有利であり得る。所与のCRペアの応答Riが1人の検証者103Vに開示されるべきである場合、同じCRペアが別の検証者103Vに使用されないことが望ましい場合がある。そうでない場合、最初の検証者103Vが、今知られている応答Riを使用して、別の検証者に対して、自分がターゲット当事者103Tであるふりをすることも可能である。しかしながら、応答データ901へのアクセス権を有するすべての潜在的検証者103Vが信頼できる場合、これを防止するための措置をとることは不可欠なことではない。
【0268】
さらなる変更形態において、チェーン上に記憶された応答データ901は、対応する応答Riに基づき(たとえば、それをシードとして使用して)セットアップ時に生成される公開鍵-秘密鍵ペアの公開鍵である、ターゲット当事者103Tの公開鍵の形態をとることも可能である。この場合、検証者103Vは、記憶トランザクション152Sから公開鍵にアクセスし、それを使用して、対応する秘密鍵でターゲット当事者103Tによって署名されたメッセージを検証する。いくつかの場合において、公開鍵は、異なる検証当事者103Vによる使用のために異なる公開鍵が割り当てられ得るように暗号化形式でチェーン上に記憶されることも可能である。
【0269】
図9にも示されているように、出力(たとえばUTXOベース)モデルを採用する実施形態では、これは、CRペア(またはそこから導出される鍵)を管理するための効率的なメカニズムを提供するために利用され得る。管理は、ここでは、たとえば、すでに消費された(検証で使用された)後に、CRペアまたは鍵を更新するか、または取り消すことを含むものとしてよい。
【0270】
これを行うために、新しいモディファイアトランザクション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を単純に取り消すとみなされる。
【0271】
いくつかの実施形態において、応答データ901は、記憶トランザクション152Sの消費可能な出力に埋め込まれ、応答データ901(たとえばCRペア)が記憶されている特定の出力203を消費する(すなわち、割り当てるかまたは償還する)ことによって、取り消されるかまたは更新され得る。いくつかのそのような実施形態において、異なるCRペアに対応する異なる応答データ901が、同じ記憶トランザクション203の個別の出力203に記憶され、個別に取り消されるか、または更新され得る。
【0272】
他の実施形態では、応答データ901は、記憶トランザクション152Sの消費不可能な出力に記憶され、記憶トランザクション152Sの異なる消費可能な出力を消費する(すなわち、割り当てるかまたは償還する)ことによって、取り消されるか、または更新され得る。いくつかのそのような実施形態において、複数の異なるCRペア(同じまたは異なる消費不可能な出力に記憶されている)に対応する複数の記憶データ901は、同じトランザクション152Sの同じ消費可能な出力を消費することによって取り消されるか、または更新され得る。
【0273】
例示的なユースケースとして、CRペアに対応する応答データ901の記録は、それが消費された、すなわち検証で使用された後に、取り消されるか、または更新され得る。これは、応答データ901がRiの明示的な記録であろうと、証明であろうと、Riから導出された公開鍵であろうと適用され得る。いずれにせよ、これはセキュリティ上の理由から有利であり得、現在世界に放出された応答データはもはや再び使用可能にはならない。
【0274】
モディファイアトランザクション152Mは、ターゲット当事者103Tによってチェーン上に記録されるように定式化されて送信され得る。これは、伝播するために直接的にブロックチェーンノード104に、または間接的に、中間当事者を介してノード104に送信されることも可能である。代替的に、信頼できる第三者は、ターゲット当事者が完了するためのテンプレートトランザクションを送信し(たとえば、署名および/または置換応答データ901'の追加によって)、次いで直接的にまたは間接的に、ノード104に転送してチェーン上に記録するものとしてよい。別の可能性として、信頼できる第三者は、モディファイアトランザクション152Mを(場合によってはテンプレートまたはたとえば置換応答データ901'を含むターゲット部分103Tから送られた何らかのデータに基づき)定式化し、次いで信頼できる第三者は、モディファイアトランザクション152Mをノード104に送信してチェーン上に記録させ得る。これらのオプションはすべて、記憶トランザクション152Sがブロックチェーン150に記録される方法にも同様に適用され得ることに留意されたい。
【0275】
上で説明されている様々な概念によれば、したがって、i)アイデンティティ(または公開鍵などの他の関係する情報)をUTXOにリンクし、このUTXOの消費状態をアイデンティティ資格情報の有効性に対するプロキシとして使用し、およびii)セットアップ、失効、更新、および検証などの効率的なアイデンティティ管理操作を実行するトランザクションのセットを確立するためのシステムが提供される。このプロセスは、すべての当事者が常に互いに通信する必要があるのではなくむしろ、すべての当事者がブロックチェーンを参照していつCRPが消費されたか、またはいつアイデンティティが取り消さされたかを確認することができるので、通信回数が低減されるという点で効率的である。
【0276】
そのような技術は、たとえば、検証で使用されるCRPデータを処理するための第三者KYC(know your customer)プロバイダへの依存を最小限度に抑えることによって、前に提示されているように、PUFデバイスにアイデンティティをリンクするようにフレームワークを拡張するために使用され得る。この目標は、KYCプロバイダの役割、またはむしろその機能の一部をパブリックブロックチェーンで部分的に置き換えることによって達成され得、これにより、ユーザは、任意の第三者から独立して、ePUFデバイスに関係する、それ自身のアイデンティティ資格情報をインスタンス化し得る。
【0277】
アイデンティティシステムにおける信頼できる第三者の役割は、必ずしも完全に避けられるわけではないが、いずれにしても、アイデンティティ管理のプロセスは改善され、プロセスへの関与、およびそれにかかる関係する負担は少なくとも低減され得る。
【0278】
5.1. UTXOセットへのPUFアイデンティティのリンク
ブロックチェーンの使用が前の節で説明されているようなアイデンティティシステムを改善することができる第1の態様は、PUFアイデンティティに関係するCRPを管理するためにパブリックブロックチェーンの未使用トランザクション出力セット(UTXOセット)を使用することによるものである。
ブロックチェーンの使用が前の節で説明されているようなアイデンティティシステムを改善することができる第1の態様は、PUFアイデンティティに関係するCRPを管理するためにパブリックブロックチェーンの未使用トランザクション出力セット(UTXOセット)を使用することによるものである。
【0279】
この節では、CRPをUTXOセットのメンバーにマッピングし、「消費済み」または「未使用」状態としてのそれらのステータスを各特定のCRPがアイデンティティ検証プロセスにおいて消費されたかどうかの指標として使用するために、2つの異なる例のメカニズムが開示されている。第1のメカニズムは、消費可能UTXOにCRPデータを埋め込むことを伴い、第2のメカニズムは、消費可能UTXOにそれらをペアリングすることを伴う。いずれの場合も、CRP、または注目するアイデンティティ、に関係する追加データも、任意選択でシステムに含まれ得る。
【0280】
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)の表現である。
[Checksig P] OP_RETURN <Rep(C, R)>
[Checksig P]は標準的なpay-to-public-key-hash (P2PKH)ロックスクリプトであり、Rep(C、R)は特定のチャレンジ応答ペア(C,R)の表現である。
【0281】
このロックスクリプトは、単純に消費トランザクション上で有効な署名Sig Pを提供することによってロック解除されるものとしてよく、署名は公開鍵Pに対して有効と考えられる。オペコードOP_RETURNに続く任意のデータは、消費トランザクションを承認する際に考慮されず、したがってこのデータはブロックチェーンバリデータに関して任意のものとして扱われ、書式なしであってよいことに留意されたい。
【0282】
上記のスクリプト内の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).
Rep(C, R) = Encrypt(C, k),
Rep(C, R) = Encrypt(R, k),
Rep(C, R) = Encrypt(C || R, k).
【0283】
これらの表現は、アリスが自分のUTXOに含まれていたチャレンジ、応答、またはCRPのいずれかを、それぞれ、後で取り出すか、または証明することを可能にする。
【0284】
追加のスクリプトのエンカンバランス:前に示されている基本的なロックスクリプトを拡張して、将来、出力を消費する入力スクリプトの追加条件を含めることが可能である。そのような余分な条件の賢明な例は、次のスクリプトであろう。
[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)を知っているという知識証明に使用され得るというものである。
[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)を知っているという知識証明に使用され得るというものである。
【0285】
トランザクションモデル:使用されるべきトランザクションロックスクリプトの正確な構造が判定されているとすると、次いで、CRPを記憶し、証明して管理する方法として、これらのスクリプトを含むトランザクションをどのように構造化するかに関する選択を行うことができる。
【0286】
本明細書では、CRP、および関連するロックスクリプトをUTXOに一対一でマッピングすることが開示されている。言い換えると、そのようなスクリプトを含むすべてのUTXOは、特定のPUFデバイスに関係するちょうど1つのCRPに対応する。
【0287】
次いで、これらのUTXOをトランザクションにどのように編成するかについていくつかのオプションがある。最もあり得そうなオプションは、次の通りである。
1. トランザクション毎に1つのCRP。
2. トランザクション毎に1つのCRPセット。
3. トランザクション毎に1つのPUF。
1. トランザクション毎に1つのCRP。
2. トランザクション毎に1つのCRPセット。
3. トランザクション毎に1つのPUF。
【0288】
第1のオプションは、いくつかの場合において、遺言書を書き換えるなどの、使用頻度が非常に低いPUFなどに対して適用可能であり得、複数のCRPが互いに明らかにリンクしていないという利点を有する。これは、1つのCRPの消費および暴露が他のものとは無関係に明らかにされ得るので、極端なプライバシーが必要な場合にも有用であり得る。
【0289】
以下のTable 1(表1)のトランザクションは、第1のオプションの例示的な実装形態である。トランザクションは、単一の入力および出力のみを含み、したがって各CRPは異なるトランザクションに含まれることが分かる。その出力が消費されたときに、このトランザクションのアイデンティティシステムへの関連性は、監査目的以外では事実上終了する。
【0290】
【表1】
【0291】
第2のオプションは、多数のCRPが各々単一のトランザクションにおいてそれぞれのUTXOにマッピングされるオプションであり、CRP消費の期待度数がかなり高い銀行カードなどのユースケースにはより望ましいものであり得る。以下のTable 2(表2)におけるトランザクションは、これがどのように達成され得るかを示している。
【0292】
アリスによって生成された可能性の高い、入力署名は、出力のセット全体にわたって署名するものであり得ることに留意されたい。これは、1つの公開鍵PAから多数のUTXO、したがって多数のCRPへの一対多のリンクを提供するが、UTXOから異なるCRPそれ自体への一対一マッピングを維持する。また、再利用を回避するために、各出力/CRPはそれ自体の関連付けられた公開鍵(すべてアリスによって所有される)を有していると仮定される。
【0293】
【表2】
【0294】
上に示されているオプションは、CRPセットを時間とともに更新する実施形態ともうまく統合され得、更新済みセットが生成されるたび毎に、そのセットに対して新規トランザクションが発行され得る。それに加えて、並列の独立した(すなわち、チェーン上で関連しない)トランザクションを介して、同じPUFに対する複数の異なるCRPセットを同時に生成し、発行することもできる。これは、複数の異なる信頼できる第三者(たとえば、異なる銀行)とでアイデンティティを確立するために有用であり得、それによりアイデンティティは両方とも独立して確立されるが、同じPUFによってまだ固定されている。
【0295】
第3のオプションは、単一のトランザクションが単一のPUFを表すために使用されるオプションであり、単純にオプション2のより制限されたバージョンであり、更新は可能でない。これは、PUF包含デバイスが特定の「寿命」を与えられ、ユーザに新しいデバイスが発行される前に所定の数の認証にのみ使用され得る場合に適用可能であり得る。
【0296】
5.1.2. 消費可能UTXOとのペアリング
CRPを消費可能UTXO内に埋め込む代替的手段は、単純にそれらをこれらの出力とペアリングすることである。この場合、電子証明書に関する既存の研究との違いは、アリスが第三者とは無関係にアイデンティティを証明することを望んでいる可能性があるので、トランザクションはアリスによって構築し署名され得る点である。
CRPを消費可能UTXO内に埋め込む代替的手段は、単純にそれらをこれらの出力とペアリングすることである。この場合、電子証明書に関する既存の研究との違いは、アリスが第三者とは無関係にアイデンティティを証明することを望んでいる可能性があるので、トランザクションはアリスによって構築し署名され得る点である。
【0297】
【表3】
【0298】
上の図では、n個のCRPに関係する2n個の出力を含む例示的なトランザクションが示されており、これにより、各消費可能出力は、CRPの1つにマッピングされ、CRP表現それ自体は対応する消費不可能出力に含まれている(たとえば、OP_FALSE OP_RETURN)。また、CRPをトランザクションおよびUTXOに編成するための3つの可能な変更形態が、ここでも同様に適用されることに留意されたい。
【0299】
5.1.3. 議論
CRP管理への利点:CRPをUTXOにマッピングする概念は、前の節からのアイデンティティプロトコルのユーザにとって、CRP管理および取り扱いを著しく改善することができる。利点は、CRPの記憶およびルックアップをブロックチェーンネットワーク106、およびそこからの信頼できる取り出しを円滑にすることができるサービスプロバイダに部分的にオフロードすることができる点である。
CRP管理への利点:CRPをUTXOにマッピングする概念は、前の節からのアイデンティティプロトコルのユーザにとって、CRP管理および取り扱いを著しく改善することができる。利点は、CRPの記憶およびルックアップをブロックチェーンネットワーク106、およびそこからの信頼できる取り出しを円滑にすることができるサービスプロバイダに部分的にオフロードすることができる点である。
【0300】
特定のPUFの「ライブ」CRPのすべてをUTXOにマッピングすることによって、アイデンティティシステムにおいて所与のPUFに現在利用可能であるCRPに関する正確な情報に関してUTXOセットの状態を問い合わせることによってCRP更新プロセスを改善することが可能である。
【0301】
ブロックチェーンおよび、これまでに説明した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を列挙することができる。そうでない場合、アリスは何もしない。
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を列挙することができる。そうでない場合、アリスは何もしない。
【0302】
埋め込み対ペアリング:CRPを消費可能出力内に埋め込むか、または単純に出力とペアリングするかの選択は、アリスに、これらのケースを区別する2つの異なる利点間で選ぶ選択肢をアリスに与える。
【0303】
CRPが消費可能な出力内に埋め込まれる場合、これは、これらの出力のデータを容易に利用可能であるように維持するために、ブロックチェーンネットワーク106を維持する、ブロックチェーンノード104にインセンティブを与える。これは、アリスの問い合わせに対する応答がより速くなり得、より決定的なことは、ブロックチェーンノードがこれらのトランザクション出力の生データをアリスに提供し直すことができる可能性がより高いことを意味する。
【0304】
前に説明されているように、CRPの表現Rep(C,R)が、チャレンジ、応答、またはその両方の生(または難読化)データを含むように含まれる場合に、これは、アリスがブロックチェーンネットワーク106から関連情報を取り出すことができることを意味する。これは、アリスが消費可能な出力にデータを埋め込むことで、自分のデータが何であれ高可用性を有する可能性が高まるので、ローカルストレージを置き換え、ブロックチェーン150でより軽量なシステムを運用することを可能にする。
【0305】
対照的に、CRPが消費可能出力とペアリングされているだけである場合、アリスは、自分に利用可能なCRPの数を決定することしかできないが、必ずしも表現データそれ自体をビットコインノードから取り出すわけではないこともあり得る。これは、アリスがCRPセットをローカルに維持しない場合に、アリスがブロックチェーンノードネットワーク106の外部のエージェントに相談しなければならないことを意味し得る。
【0306】
ダブルハッシュの使用:上記の例示的な実装形態において、ダブルハッシュH2(Data)は、何らかのDataのオンチェーン表現として使用され得ることが示されている。このようにしてダブルハッシュを使用する理由は、シングルハッシュもオンチェーンで暴露されることを可能にし、当事者がH(Data)を知っており、次いで、Dataに接続されているという知識証明のように原理的に動作する点にある。
【0307】
これは、たとえば、アリスがRの実際の値を共有している場合に、H2(R)はH(R)を提供する第三者によって満たされ得る消費エンカンブランスとしてアリスによってオンチェーンで記録されるPUF-アイデンティティ状況で有用であり得る。
【0308】
複数当事者署名:この節で詳述されたトランザクションは、PUFアイデンティティをアリスが証明するのを助けるために、複数の異なる当事者からの、より多くの署名を含み得ることももっともらしい。たとえば、アリスのアイデンティティにおける検証者の信頼を改善する方法としてアリスおよび第三者アイデンティティプロバイダの両方がCRPトランザクションの入力に署名することが望ましい場合がある。これは、副署者が、ブロックチェーントランザクションに署名するために使用されるアリスの公開鍵を証明することができる認証局である場合に、特に関連性がある。複数の当事者は、単なる複数の署名(すなわち「multi-sig」)の代替としてたとえば閾値署名または鍵分割技術(たとえばシャミア秘密共有)を用いて署名プロセスに含まれ得る。
【0309】
5.2. トランザクションを使用する効率的アイデンティティ管理
ブロックチェーンが、前に提示されているような、PUFベースアイデンティティシステムと併せて使用され得る追加の方法は、PUFデバイスによって安全を保証されたアイデンティティ鍵またはトークンを取り消す効率的な手段としての方法である。
ブロックチェーンが、前に提示されているような、PUFベースアイデンティティシステムと併せて使用され得る追加の方法は、PUFデバイスによって安全を保証されたアイデンティティ鍵またはトークンを取り消す効率的な手段としての方法である。
【0310】
デジタル証明書管理に関する先行研究では、チェーン上で証明書を発行し、取り消すことが知られており、対応する証明書検証プロセスがこれに付随している。アリスが、PUFベースアイデンティティをオンチェーンで証明するときに、喜んで認証局と協力するシナリオを考える。アリスがオンチェーンで自分のアイデンティティに対する証明書を登録するプロセスは、次の通りである。
1. 認証局(CA)は、アリスのアイデンティティを検証する。
2. CAは、証明書トランザクションを作成する。このトランザクションは、次の入力および出力を有する。
a. 入力:CAの署名および公開鍵を含むロック解除スクリプトを有するCAのUTXO。
b. 出力1:P2PKHロックスクリプト。
c. 出力2:アリスの公開鍵を含むOP_RETURN出力。
3. トランザクションはブロードキャストされ、マイニングされた後、CAはアリスにトランザクションID
1. 認証局(CA)は、アリスのアイデンティティを検証する。
2. CAは、証明書トランザクションを作成する。このトランザクションは、次の入力および出力を有する。
a. 入力:CAの署名および公開鍵を含むロック解除スクリプトを有するCAのUTXO。
b. 出力1:P2PKHロックスクリプト。
c. 出力2:アリスの公開鍵を含むOP_RETURN出力。
3. トランザクションはブロードキャストされ、マイニングされた後、CAはアリスにトランザクションID
【0311】
【数2】
【0312】
を提供する。
【0313】
このプロセスは、アリスと認証局とが協力して、CAによって署名され、アリスの公開鍵の証明書を含む1つの消費不可能出力およびCAが証明書を取り消すために使用することができる証明書とペアリングされた消費可能出力を含むトランザクションを生成することで終わる。
【0314】
本明細書において開示されている実施形態は、上記のデジタル証明書について概要を述べた方法と、前に説明されている方法のうちの1つなどの、PUFベースアイデンティティを確立する方法とのハイブリッドを使用する。ここでPUFアイデンティティシステムに追加される要素は、一般的な信頼できる第三者(CAに類似する)が、UTXOを消費することによってCRP、または関係する公開鍵を「取り消す」ことができる要素である。
【0315】
信頼できる第三者がアリスの公開鍵上の証明書を取り消すケースは、前に説明されている暗号化アイデンティティの確立に関係する。
【0316】
チェーン上に記憶されるか、または証明されたCRペア(CRP)の場合、本明細書において開示されている実施形態は、認証プロセスで使用された後に信頼できる第三者がCRPを取り消すことを可能にするスキームを提供する。例示的な方法は、次の通りである。
1. アリスおよび信頼できる第三者は、アイデンティティセットアッププロトコルを実施する(たとえば、前述のように)。
2. 次にアリスおよび信頼できる第三者は、1において生成された、またはステップ1の後に現在取得可能なCRPの管理のためにブロックチェーンを使用することを望む。
a. アリスはCRPをトランザクション出力にマッピングするCRPマッピングトランザクションTxIDCRP-Setを作成する。これは、以下のTable 4(表4)に示されている。
b. アリスおよび信頼できる第三者は、両方ともTxIDCRP-Setに署名する。
3. CRPマッピングトランザクションTxIDCRP-Setは、ブロックチェーンブロックでブロードキャストされ公開される。
1. アリスおよび信頼できる第三者は、アイデンティティセットアッププロトコルを実施する(たとえば、前述のように)。
2. 次にアリスおよび信頼できる第三者は、1において生成された、またはステップ1の後に現在取得可能なCRPの管理のためにブロックチェーンを使用することを望む。
a. アリスはCRPをトランザクション出力にマッピングするCRPマッピングトランザクションTxIDCRP-Setを作成する。これは、以下のTable 4(表4)に示されている。
b. アリスおよび信頼できる第三者は、両方ともTxIDCRP-Setに署名する。
3. CRPマッピングトランザクションTxIDCRP-Setは、ブロックチェーンブロックでブロードキャストされ公開される。
【0317】
【表4】
【0318】
このプロセスで作成されたマッピングトランザクションは、上のTable 4(表4)に示されている。これは、前にTable 2(表2)に示されたCRPマッピングトランザクションに非常によく似ているが、信頼できる第三者およびアリスの両方が入力に署名する点と、CRPにマッピングされたUTXOの各々が信頼できる第三者によって将来のトランザクションで消費することによって取り消され得る点が異なる。
【0319】
これは、CRPの失効が直接通信なしで処理されることを可能にし、TTPがユーザに代わって失効を実行するものとしてよく、これによりシステムにおけるアリスの負担をさらに軽減し、アリスのアイデンティティ管理をなおいっそう軽量化できるという点で有利である。
【0320】
6.イベントログ
図10は、埋め込みPUFモジュール603を伴うデバイス1000の例を示す。実施形態において、このPUFモジュール603は、PUF302、変換関数502、およびインターフェースロジック404'を備える、前に説明されているePUF500を備え得る。代替的に、ePUF500は、PUF302およびインターフェースロジック404'だけ(変換関数502なし)を備え得る。デバイス1000は、1つまたは複数の外層コンポーネント1002をさらに備える。これらは、1つまたは複数のハードウェアおよび/またはソフトウェアコンポーネントを備え得る。外層コンポーネント1002は、たとえば、デバイス1000と外部ソースとの間の通信のための外部インターフェースを備え得る。外部インターフェースは、たとえば、デバイスへの有線接続を行うためのポート、またはワイヤレス接続を形成するためのワイヤレス送受信機を備え得る。加えて、または代替的に、外層コンポーネント1002は、たとえばデバイスのアプリケーション目的を実施するための、デバイス1000のプロセッサ上で実行するアプリケーションを備え得る。外層コンポーネント1002はまた、固定関数ハードウェアにおいて実装される1つまたは複数のコンポーネントを備え得る。
図10は、埋め込みPUFモジュール603を伴うデバイス1000の例を示す。実施形態において、このPUFモジュール603は、PUF302、変換関数502、およびインターフェースロジック404'を備える、前に説明されているePUF500を備え得る。代替的に、ePUF500は、PUF302およびインターフェースロジック404'だけ(変換関数502なし)を備え得る。デバイス1000は、1つまたは複数の外層コンポーネント1002をさらに備える。これらは、1つまたは複数のハードウェアおよび/またはソフトウェアコンポーネントを備え得る。外層コンポーネント1002は、たとえば、デバイス1000と外部ソースとの間の通信のための外部インターフェースを備え得る。外部インターフェースは、たとえば、デバイスへの有線接続を行うためのポート、またはワイヤレス接続を形成するためのワイヤレス送受信機を備え得る。加えて、または代替的に、外層コンポーネント1002は、たとえばデバイスのアプリケーション目的を実施するための、デバイス1000のプロセッサ上で実行するアプリケーションを備え得る。外層コンポーネント1002はまた、固定関数ハードウェアにおいて実装される1つまたは複数のコンポーネントを備え得る。
【0321】
例として、デバイス1000は、ときにはブラックボックスレコーダとも称されるイベントデータレコーダ(EDR)の形態をとり得る。これは、たとえば、自動車または飛行機などの車両における使用のために設計されるEDRであり得る。この場合、外層コンポーネント1002は、デバイス1000のプロセッサ上で実行するEDRアプリケーションを備え得る。しかしながら、これは、単に一例にすぎず、他の実施形態において、デバイス1000は、代わりに、汎用コンピュータデバイス、またはアイデンティティを立証するための専用PUFデバイスなど、他の形態をとり得るということを理解されたい。
【0322】
PUFモジュール603は、デバイス1000のハウジング1001内(すなわち、内側に)埋め込まれ、すなわち、ハウジング1001によって完全に封入される。PUFモジュール603は、デバイス1000を物理的に分解することなく、アクセスが、インターフェースロジック404'への入力を介する以外に、PUFモジュール603の挙動に影響を及ぼすために付与されないように、物理的に構成される。いくつかの実施形態において、ハウジング1001は、好適な鍵または組合せなしでのPUFモジュール603へのアクセスを防ぐ物理的なロックを備え得る。代替的に、ハウジングは、永久的に密封され得る。
【0323】
PUFモジュール603が埋め込まれるハウジング1001はまた、PUFモジュール603と同じハウジング1001内に外層コンポーネント1002のうちの1つまたは複数を取り囲み得る。外部ソースへの有線接続を行うためのポートなどの外部インターフェースの場合、インターフェースは、ハウジング1001と外側との間の物理的インターフェースに位置し得る。デバイスのプロセッサ上で実行するアプリケーションの場合、問題のプロセッサは、ハウジング1001によって封入され得るが、外部ソースからの外部入力を受け入れるためなど、外部インターフェースを介してアクセス可能であり得る。
【0324】
代替的または追加的に、PUFモジュール603が封入されるハウジング1001は、PUFモジュール603を外層コンポーネントから内部で分離する、デバイス1000内の内側ケーシングを備え得る。しかしながら、これは、すぐに論じられる他の方策が、PUFモジュール603を外層コンポーネント1002から物理的および/または論理的に分離するためにとられ得るため、必須ではない。
【0325】
PUFモジュール603のインターフェースロジック404'は、後でより詳細に論じられるロギングメカニズム1004を備える。インターフェースロジック404'は、任意選択で、前に論じられるようなアクセス制御ロジック406も含み得る。いずれにせよ、ロギングメカニズム1004および任意のアクセス制御ロジック406を含むインターフェースロジック404'は、外層コンポーネント1002のうちのいずれかのいかなる悪意ある改ざんもPUFモジュール603の内部機能に影響を及ぼさないように、外層コンポーネント1002から分離されたままである。インターフェースロジック404'は、ファームウェアもしくは固定関数ハードウェア回路(すなわち、専用回路)のいずれか、またはファームウェアおよび固定関数ハードウェア回路の組合せにおいて実装される。ファームウェアの場合、本目的では、これは、i)永久メモリ(リードオンリメモリ(ROM))に書き込まれるか、ii)デバイスを物理的に分解することなしに、メモリへの外部インターフェースを伴わずに、ハウジング1001内に埋め込まれることによって外部アクセスから物理的に保護されるメモリに記憶されるか、iii)コンテンツが制限されたプロセスを介してのみ更新され得るメモリに記憶されるか、のいずれかである、ソフトウェア(コンピュータ可読コード)を意味する。たとえば、後者の場合、インターフェースロジック404'のハードウェアは、オペレータがパスワード、PIN、暗号鍵、またはバイオメトリック情報などの1つまたは複数の必要とされる資格情報を提示することができる場合、ファームウェアが記憶されるメモリを更新するためにアクセスを唯一許可するように、ハードウェアにおいて、構成され得る。
【0326】
そのような制限が置かれる限り、任意のそのようなファームウェアが記憶されるメモリは、1つまたは複数の記憶媒体(たとえば、磁気ディスクもしくはテープなどの磁気媒体、またはROM、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAM、などの電子媒体)を採用する1つまたは複数のメモリユニットを含む、任意の好適な形態をとり得る。任意のファームウェアが実行されるプロセッサは、1つまたは複数の処理ユニット(たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、もしくは暗号プロセッサなどのアプリケーション固有またはアクセラレータプロセッサ)を含み得る。別のオプションは、ファームウェアが、PGAまたはFPGAなどの構成可能または再構成可能な回路において実装され得ることである(FPGAの場合、再構成するのに制限されたアクセスを有する)。
【0327】
変換関数502が採用される実施形態において(ePUF500の場合のように)、これは、ハードウェアまたはファームウェアにおいても実装され得る。PUFインターフェースロジック404'について上で述べられるようなものと同じ実装に関するコメントは、変換関数502にも適用する。
【0328】
外層コンポーネント1002がアプリケーションを備える場合、アプリケーションが記憶されるメモリもまた、1つまたは複数の記憶媒体(たとえば、磁気ディスクもしくはテープなどの磁気媒体、またはROM、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAM、などの電子媒体)を採用する1つまたは複数のメモリユニットを含む、任意の好適な形態をとり得る。アプリケーションが実行されるプロセッサもまた、1つまたは複数の処理ユニット(たとえば、CPUなどの汎用プロセッサ、またはGPU、DSP、もしくは暗号プロセッサなどのアプリケーション固有またはアクセラレータプロセッサ)を含む、任意の好適な形態をとり得る。別のオプションは、外層102のアプリケーション機能が、専用ハードウェア回路、またはPGAもしくはFPGAなどの構成可能もしくは再構成可能な回路において部分的にもしくは全体的に実装され得ることである。
【0329】
実施形態において、外層1002のアプリケーションは、PUFモジュール603のファームウェアとは別のプロセッサ上で実行される。外層プロセッサ上で実行されるソフトウェアは、インターネットから更新をダウンロードすること、または有線接続を介して更新をインストールすることなどによって、外部インターフェースを介して更新可能であり得る。しかしながら、ファームウェアは、更新可能ではない場合があるか、またはいくつかの実施形態において、オペレータが必要とされる資格情報を提示することができる場合にのみ更新可能であり得る。別のオプションは、ファームウェアが、アプリケーションと同じプロセッサ上で、しかしながら安全なプロセッサの特権付きドメイン内で実行されることである(その一方で、アプリケーションは、別のアプリケーションドメイン内で実行される)。たとえば、インターフェースロジック404'のファームウェアは、たとえばROMに記憶される、安全なカーネルの一部として実装され得る。この場合、プロセッサは、ブートされるとき、カーネル(特権付きドメイン)を実行することによって開始し、これによりプロセッササイクルをアプリケーション空間(アプリケーションドメイン)内で実行するアプリケーションへ委譲することができるように構成されるが、プロセッサは、アプリケーションプロセスがカーネルを上書きすること、または委譲されたサイクル数の後に実行がカーネルに戻ることを自律的に防ぐことがないように、ハードウェアにおいて構成される。そのような安全な(特権付き)ドメインを実装するための好適な安全な処理技術の詳細は、それ自体が当業者に知られている。
【0330】
どんな手段が実装されるにしろ、動作中、インターフェースロジック404'は、入力チャレンジを外層1002から受信する。たとえば、これは、アプリケーションから、または外部インターフェースを介して、または外部インターフェースおよびアプリケーションを介して、入力チャレンジを受信することを含み得る。故に、外層1002は、入力チャレンジを受信するためのチャネルの少なくとも一部を提供する。入力チャレンジのソースは、外層1002内で実行されるアプリケーション、または外部ソースであり得る。後者の場合、外部ソースは、入力チャレンジをデバイス1000の外部インターフェースに直接的に入力するローカル、またはネットワークを介して入力チャレンジをデバイス1000の外部インターフェースに送信するリモートであり得る。入力チャレンジのソースは、人間のユーザ、または外部コンピュータ機器などの別のデバイスもしくはシステムであり得る。
【0331】
インターフェースロジック404'は、PUFモジュール603に、PUF302に応じて出力応答を生成させる。PUFモジュール603がePUF500の形態をとる場合、前に論じられるように、入力チャレンジは、二次チャレンジCiであり、出力応答は、二次応答Riである。この場合、インターフェースロジック404'は、二次チャレンジCiを変換関数502内へ入力し、一次チャレンジCwをPUF302内へ入力して、それが一次応答RwをPUF302に供給することを引き起こし、PUF302が二次応答Riを生成する。さらなる詳細については、ePUFに関する前の議論を再度参照されたい。
【0332】
しかしながら、代替の実施形態において、PUFモジュール603は、ePUF500の形態をとる必要はない。たとえば、PUFモジュール603は、単にPUF302およびインターフェースロジック404'を備え得る。この場合、インターフェースロジック404'は、単純に、変換関数502なしに入力チャレンジをPUF302内へ直接的に入力し、入力チャレンジの直接関数としてPUF302から返ってくる出力応答を受信する。
【0333】
いずれにせよ、インターフェースロジック404'は、ソースと同じユーザ、デバイス、またはシステムを含み得る宛先に、または異なる宛先に、または両方に、出力チャレンジを返すように配置構成される。宛先は、外層1002内のアプリケーションを含み得る。代替的に、または追加的に、宛先は、出力応答が、外層1002の外部インターフェースを介して、またはアプリケーションおよび外部インターフェースを介して送信される外部宛先を含み得る。外部宛先の場合、宛先は、ローカル(応答を直接的に受信する)またはリモート(外部ネットワークを介して応答を受信する)であり得る。宛先がローカルであるにしろ、リモートであるにしろ、外層1002は、故に、チャネルの少なくとも一部を提供し、これを介して出力応答が宛先に供給される。外部宛先の場合、宛先は、人間のユーザ、または外部コンピュータ機器などの別のデバイスもしくはシステム(図示せず)を含み得る。
【0334】
デバイス1000内へのPUFモジュール603の包含は、デバイス1000のアイデンティティもしくはデバイスを所有している当事者の検証、またはデバイスによってもたらされる結果の検証を可能にする。
【0335】
たとえば、前の信頼できるセットアップフェーズ702において、デバイス1000が、検証当事者103Vまたは信頼できる第三者サービス202(たとえば、先の議論を参照)のいずれかにより、その応答Rを特定のチャレンジCに登録したシナリオを考える。その後、捜査もしくは訴訟手続またはそのようなものの間、捜査中の検討下の、または手続きの一部として提示される、候補デバイスが、信頼できるセットアップフェーズにおいて前に登録されたものと同じデバイス1000であるかどうかを立証することが所望され得る。これを行うために、検証当事者103V(たとえば、捜査官、弁護士、または裁判所職員)は、セットアップ中に使用されたものと同じチャレンジCをデバイス1000に入力し、それがもたらす候補結果R'がセットアップフェーズにおいて元々登録された結果Rと同じであるかどうかを決定することができる。
【0336】
別のシナリオにおいて、前の応答は、本来、セットアップフェーズの一部として登録される必要はない。代わりに、デバイス1000は、何らかのイベントの際に結果を生成するように構成され得、その時間からのPUFモジュール603の応答Rは、結果にリンクまたはマッピングされ得る。結果は、たとえば、外層コンポーネント1002のうちの1つまたは外層コンポーネント1002によって監視されているシステムの状態であり得るか、またはこれを表し得る。たとえば、デバイス1000がEDRである例において、結果は、自動車、飛行機、または船などの搭載コンピュータなど、監視されているシステムによって生成される信号であり得る。いくつかのそのような実施形態において、応答Rを生成するために入力されるチャレンジCは、結果を生成した状況に関する1つの意味のあるデータであり得る。たとえば、チャレンジは、自動車の前面の距離センサなど、車両の搭載センサからの信号であり得る。対応する結果は、EDRデバイス1000によって監視されている搭載コンピュータによって適用される、ブレーキをかけよという命令であり得る。外層1002内のEDRアプリケーションは、結果を応答Rにリンクまたはマッピングするタグを生成するように、ならびに結果およびタグをEDRアプリケーションの記憶場所に記録するように構成される。タグは、実装形態に応じて、いくつかの可能な方式で生成され得る。たとえば、タグは、結果に署名するために暗号鍵としてRを使用することによって生成される暗号署名であり得るか、またはそれは、Rおよび結果に基づいたハッシュベースのメッセージ認証コード(HMAC)であり得る。デジタル署名技術、HMAC、およびそのようなものの詳細は、それ自体が当該技術分野において知られている。
【0337】
その後、捜査または訴訟手続中、記録された結果が実際に特定のEDR1000によって生成されたかどうかを立証することが所望され得る。これを行うために、候補チャレンジC'が、PUFモジュール603内へ入力され、対応する候補応答R'を生成する。記録されたタグ(たとえば、署名またはHMAC)が、今生成されたR'に基づいて認証される場合、これは、記録された結果がEDRによって生成されたことを立証する。
【0338】
たとえば、自動車事故などの何らかの事件に関与したアリスの自動車からのEDRの例を考える。チャレンジCは、たとえば、自動車の前面の距離センサからの読み取りであり得る。結果は、Cに基づいて生成され得る。この例では、それは、読み取りが低すぎた(前部の物体が近すぎる)ためにブレーキをかけるという搭載コンピュータからの決定であり得る。Cはまた、PUFモジュール603(たとえば、ePUF)に入力される。PUFモジュールは、CおよびPUF302に基づいて応答Rを生成する。Rは、必ずしも、それ自体が意味のあるものではない。しかしながら、結果は、たとえば、署名を生成することによって、結果にRで署名することによって、またはHMACを計算することによって(結果R)、Rにマッピングされる。より一般的には、チャレンジ、結果のいずれか、または両方は、監視されているシステム(自動車もしくは他の車両の搭載コンピュータにしろ、または任意の種類のEDRによって監視され得る任意の他のシステムであるにしろ)の測定値、状況、または他のそのような状態に依存し得る。たとえば、結果とは違ってチャレンジは、結果が状態の値に依存しない任意の場合において、状態に依存し得る。これの1つの例は、EDRによって計算される結果が単なるタイムスタンプまたはインデックス(たとえば、基本的なデータ記録目的のため)である場合であり、それは、測定値または状態の値を知る必要がないことを意味し、タイムスタンプは、システムクロックまたは増分カウンタのようなものから派生され得る。
【0339】
実施形態において、外層1002内のEDRアプリケーションは、少なくとも、署名された結果、および署名またはHMACを記録する。いくつかのそのような実施形態において、それは、Cが結果を引き起こした現実世界のデータを表す場合、Cも同様に記録し得る。たとえば、結果は、搭載コンピュータがブレーキをかけたことであり得、Cは、自動車の前面の距離センサからの信号であり得る。その後、自動車事故捜査において、または訴訟もしくはそのようなものにおいて、ボブは、EDR1000を手にしており、実際にはアリスのEDRによって生成された証拠として今提示されている記録された結果を実証することを望む。これを行うために、ボブは、外層1002を介してPUFモジュール603内に、結果を引き出した候補チャレンジC'を入力し(たとえば、低い距離読み出しを入力する)、応答R'を観察する。記録された署名またはHMACが、今生成されたR'に基づいて認証される場合、これは、記録された結果がアリスのEDRによって生成されたことを立証する。故に、PUFモジュール603は、それが、イベント時に存在したEDRと実際に同じであったこと、それが、Cまたは外部状況を前提として特定の結果を引き出したことをチェックすることを可能にする。Cが状況に依存せず、結果のみが依存するとしても、(C,R)を使用してHMACを認証することが依然として可能であり、Rは、タグを生成するために使用される鍵、たとえば、HMAC鍵またはそのようなものである(Cが、条件から派生されたか否か、またはこれに依存したか否かにかかわりなく)。これは、単に自動車のEDRに当てはまるだけでなく、より一般的には、任意の種類のシステムを監視するための任意の種類のEDRに当てはまる。
【0340】
より一般的には、外層1002内に必ず記録される必要がある特定のものなど存在しない。外層1002は、任意選択で、結果、応答、タグを出力するか、これらのいずれも出力しないか、これらの3つすべてを出力し得る。たとえば、ブラックボックスレコーダは、動作時に必ずしも何かを放出する必要はなく、それは、後で捜査されるまでチャレンジまたは測定値などを取り込む「書き込み専用」システムのように作用するだけである。
【0341】
実装形態が何であるにしても、チャレンジが、外層コンポーネント1002のうちの少なくとも1つ(たとえば、アプリケーションおよび/または外部インターフェース)を介してPUFモジュール603に入力され、対応する応答が、それが出力されるステージが何であるにしろ、外層コンポーネント1002のうちの少なくとも1つを介して出力されるという潜在的な問題が存在する。これは、後の捜査/手続中、および任意の初期セットアップフェーズにおいて、または結果が元々生成された時、の両方に当てはまる。述べたように、外層コンポーネントは、入力チャレンジを受信し、出力応答を出力するための安全でないチャネルの少なくとも一部を形成する。これは、ソースおよび/または宛先がデバイス1000の内部であるか、外部であるかにかかわりなく当てはまる。したがって、このチャネルは、中間者(MiM)サービス妨害(DoS)攻撃、またはおそらくは、捜査下の当事者(アリス)による自身への捜査を阻止するための悪意ある挙動にさえ、受け入れ得る。たとえば、何者かが、EDRの外部インターフェースにスクランブラをひそかに取り付け得るか、または、EDRアプリケーションと干渉する何らかのマルウェアをダウンロードした可能性がある。これらのいずれかが、入力チャレンジの値を、それがPUFモジュール603に入力される前に改ざんし得るか、または出力応答の値をPUF603によって出力された後に改ざんし得る。これは、元のイベント時(たとえば、EDRがアリスの自動車内にあった)、または検証時(捜査/手続中)のいずれかで起こり得る。入力チャレンジのソースまたは出力応答の宛先が共にデバイス1000の外部およびリモートである場合、ソースとチャレンジを受信する当事者との間、およびその当事者とデバイス1000との間という、MiM攻撃の2つの潜在的な地点が存在する。
【0342】
そのような攻撃を本来止めることは不可能であり得るが、それが起こったことを検出することができることが望ましい。
【0343】
これを解決するために、本開示によれば、PUFモジュール603のインターフェースロジック404'は、ロギングメカニズム1004を備える。これは、入力チャレンジCがPUFモジュール603のインターフェースロジック404'に入力され、対応する出力応答Rが生成されるとき、Cおよび/または応答Rの記録をログ媒体1006に自動的にロギングするように構成される。すなわち、インターフェースロジック404'に入力される際の入力チャレンジC、および/またはインターフェースロジック404'によって出力される際の出力応答Rは、ログに記録される。
【0344】
Cおよび/またはRの記録は、Cおよび/またはRの明確な値を、明らかな形態または暗号化形態のいずれかで含み得る。代替的に、Cおよび/またはRの記録は、それらの値を明らかにしない、それぞれCおよび/またはRの変換、たとえば、Cおよび/またはRのハッシュまたはダブルハッシュである、Cおよび/またはRの証明を含み得る。証明の場合、これは、候補チャレンジC'および/または応答R'が、候補値に同じ変換を適用することによって、証明に対してチェックされることを可能にする。任意選択で、ログはまた、結果Rをその時に生成された結果(たとえば、ブレーキをかけるための信号)にマッピングするタグを含み得る。たとえば、実施形態において、ログは、タグおよびR自体を含み得る。
【0345】
PUFモジュール603は、デバイス1000内に埋め込まれている自己完結型モジュール、たとえば、EDR(ブラックボックス)として実装される。内部機能は、EDRの内部コンポーネントの残りから分離され、ハードウェア、もしくはROMから実行されるファームウェアなどのより安全な環境において、および/または安全なドメインにおいて実装されている。故に、悪意ある当事者は、PUFモジュール603自体の中で起こっているものは制御ロジックによって仲介されるために、これを改ざんすることはできないが、そのことは、外層1002または外層1002に供給される情報を改ざんすることによって引き起こされる変換された情報がPUFモジュール603に供給されることを止めるものではない。PUFモジュール603の内部ロジック1004によるCRペアのログは、そのような攻撃を立証するための手段を提供する。
【0346】
ログ媒体1006は、図10に示されるようにインターフェースロジック404'内に、または少なくともデバイス1000内に埋め込まれている内部メモリを備え得る。任意の好適なメモリ媒体、たとえば、EPROM、EEPROM、フラッシュメモリ、SRAM、DRAMなどの電子媒体、またはさらに磁気ディスクもしくはテープなどの磁気媒体が使用され得る。そのような実施形態において、メモリは、そのコンテンツがロギングメカニズム1006以外の任意のエンティティによって変更されることから保護されるように配置構成される。これは、たとえば、1回だけ書き込み可能で読み取りは何度も可能な(WORM)メモリ、または、たとえば、任意のタンパリングの証拠を残すように、もしくはそのコンテンツが承認された当事者によってのみ変更されることを可能にするように設計される、タンパープルーフメモリ(たとえば、メモリは、パスワード、PIN、鍵、または生体情報などの認識された資格情報を提示することができる当事者にのみ書き込みアクセスを許可するように、ハードウェアにおいて構成され得る)を使用することによって、なされ得る。代替的または追加的に、ログ1006のメモリは、デバイス1000の外側ハウジング1001、またはさらにデバイス1000内のPUFモジュール603の内部ケーシングなど、ハウジング内に物理的に埋め込まれることなどによって、テンパリングから物理的に保護され得る。場合によっては、ハウジングには、開けるために物理的な鍵または組合せを必要とする物理的なロックが装着され得る。
【0347】
さらに別の代替または追加のオプションにおいて、ログ媒体1006は、公開媒体を含み得る。これは、ブロックチェーンなどの不変の公開媒体を含み得る。しかしながら、変更可能な公開媒体、たとえば、ウェブ上での公開でさえ、ログを変更しようとするいかなる試みも公に目に見えるため、何らかの安全を提供する。そのような実施形態において、ロギングメカニズム1004は、公開ログ媒体1006にロギングされているCおよび/またはRの記録をアップロードすることを可能にするために、インターネットまたはモバイルセルラーネットワークなどのネットワークへの安全なインターフェースを装備する。
【0348】
ログ媒体1006がデバイス1000またはさらにインターフェースロジック404'の外部にある実施形態において、好ましくは、インターフェースロジック404'には、Cおよび/またはRの記録がデバイス1000と媒体1006との間で改ざんされることを防ぐために(または少なくとも、そのようなことが起こった場合に検出を可能にするために)、その記録を媒体1006に送信するための安全なチャネルが提供される。これは、任意の知られている暗号署名技術に基づいて、パケットにロギングされている記録を、記録に基づいて生成される暗号署名およびロギングメカニズム1004の鍵と一緒に出力するようにロギングメカニズム1004を配置構成することによって単純に実装され得る。ブロックチェーントランザクション152が、ロギングデータを同封するパケット(たとえば、ロギングされた記録をトランザクションの出力に置き、入力に署名を含む)として使用されている場合、ブロックチェーンネットワーク106は、この種の攻撃に対する追加の保護をもたらし、ブロックチェーントランザクション152が、その入力署名によって署名されるメッセージを変化させる任意の方式で変化される場合、トランザクションは、無効となり、オンチェーンには至らない。そのため、ログデータが入力署名によって署名される限り、ロギングデータがパブリッシング内でテンパリングされていなかったことを確実にするために必要とされるのは、それがオンチェーンに至ったことを検証することだけである(たとえば、マークル証明を供給することによって)。
【0349】
いくつかの実施形態において、ログ媒体1006は、ローカルの内部メモリおよび公開媒体の両方を含み得る。いくつかのそのような実施形態において、ロギングメカニズム1004は、最後の時間期間においてロギングされた直近のCRペアのバッチを公開媒体(たとえば、ブロックチェーン)に定期的にアップロードするために、出力応答を生成する時に、しかしながらさらに、時間期間あたり1回(たとえば、どのくらいの頻度で使用されるか、およびローカルメモリサイズに応じて、毎時間、毎日、毎週など)、CRペア(または記録がロギングされているものであれば何でも)をローカルメモリにロギングするように構成され得る。任意選択で、ロギングメカニズム1004は、それがバッチを公開媒体にアップロードする度に、ローカルに記憶されたCRペアをクリアし得る。これは、検証当事者103Vが、ローカルログを調べることによって潜在的な悪意ある挙動をリアルタイムで検出することを可能にする。これは、攻撃をそれらが発生してすぐに検出することができるために、望ましい場合がある。しかしながら、ログを公開媒体に定期的に記憶することはまた、すべてのCRペアをローカルログに永遠に保持する必要がないことにより、ローカルメモリを節約する。それはまた、ローカルメモリに対する攻撃に対して保護するのに役立ち、またさらには、ログは、デバイス1000への検証当事者の接続が切断されたとしても、公開媒体上で依然として利用可能である。
【0350】
さらなる代替または追加の実施形態において、ロギングされた記録は、PUFモジュール603によって実施される各チャレンジ-応答動作の後に、ブロックチェーンにリアルタイムで書き込まれ得る。これは、内部メモリ内のローカルロギングの代替として、またはこれに加えて、行われ得る。それは、ブロックチェーンへの記録のバッチの定期的なロギングの代替として、またはこれに加えて、行われ得る。
【0351】
どんな手段が実装されるにしろ、ログ媒体1006のコンテンツは、検証フェーズ中、たとえば、捜査または訴訟手続中、後で検証当事者103Vによって読み取られるために利用可能にされる。
【0352】
ログが検出するために使用され得る少なくとも2つの潜在的な攻撃が存在する。1つ目は、外層1002内またはソースとデバイス1000の外層との間のいずれかにおけるCの改ざんである。
【0353】
これに対してチェックする1つの方式は、検証当事者103V(ボブ)が外層1002内のマルウェアについてチェックするために捜査または手続中にログの挙動をチェックすることである。候補チャレンジC'が新規ログエントリC''において直ちに変換される場合、検証当事者103Vは、デバイスが現在感染しており、信頼することができない、故に、その証拠を使用することができないことを知る。
【0354】
別のチェックは、検証当事者103V(ボブ)が、候補チャレンジC'が過去のイベントのログにおいてロギングされている入力チャレンジCのうちの1つに等しいことをチェックすることである。そうである場合、すべてうまくいっているが、そうでない場合、これは、イベントが発生しなかったこと、入力チャレンジのソース(たとえば、自動車の例では距離センサ)が壊れていたこと、または入力チャレンジがイベント時にテンパリングされたこと、のうちのいずれかを意味し得る。文脈情報が、最初の2つの可能性を消去するために使用され得る。たとえば、目撃者が、イベントが発生したこと(たとえば、自動車事故)を立証し得、技術検査が、入力チャレンジのソース(たとえば、自動車距離センサ)が依然として機能していることを実証し得る。
【0355】
別の潜在的な攻撃は、デバイスの外層1002内または外層1002と宛先との間のいずれかにおける出力応答の改ざんである。これを検出するために、後に捜査/手続中、検証当事者103V(ボブ)は、問題となっている結果と関連して記録されたタグ(たとえば、署名またはHMAC)を認証するだけでなく、イベント時からのロギングされた応答Rが今生成された候補応答R'に一致することをチェックもする。それらが一致しない場合、それは、何らかの干渉があったことを意味するため、証拠は無視されなければならない(それは、どちらにしても、記録された結果がアリスのEDRまたはそのようなものによって生成されたか否かを証明しない)。同様のチェックが、一般的なアイデンティティ検証の場合に実施され得る。
【0356】
Cおよび/またはRの記録は、明確な値、または証明、たとえば、値のハッシュであり得るということに再び留意されたい。前者の場合、単純に一致についてチェックすることは、記録された値が候補値に等しいことをチェックすることを含む。しかしながら、証明の場合、一致についてチェックすることは、まず同じ変換(たとえば、ハッシュ)を候補値に適用し、次いで変換された候補値が記録された証明に一致することをチェックすることを含む。
【0357】
6.1 ローカルPUFシステム
例として、イベントログは、ローカルセットアップの場合(節3.2を参照)特定のアプリケーションを見つけて、対応する検証シナリオに関連する中間者攻撃の種類を防ぎ得る。チャレンジCを受信し、おそらくは何らかの計算を実施し、計算の結果および応答Rを含み得る応答を提供するように構成される、PUFモジュール603、たとえば、ePUF500を考える。
例として、イベントログは、ローカルセットアップの場合(節3.2を参照)特定のアプリケーションを見つけて、対応する検証シナリオに関連する中間者攻撃の種類を防ぎ得る。チャレンジCを受信し、おそらくは何らかの計算を実施し、計算の結果および応答Rを含み得る応答を提供するように構成される、PUFモジュール603、たとえば、ePUF500を考える。
【0358】
これの良い例は、PUFモジュール出力がHMAC(結果R)を含むハッシュ化メッセージ認証コード(HMAC)であり、応答Rは、対称HMAC鍵として使用され、メッセージは、実施された計算の結果である。
【0359】
しかしながら、このような状況において、およびイベント検証が、検証者103VにPUFモジュール603への物理的なアクセスを提供することを伴う場合、PUFモジュール603もその動作のログまたは記録を生成することが有益であり得る。これの理由は、PUFモジュール603(たとえば、IoTデバイス上の)と所望のチャレンジCをデバイスに提出する正当な所有者との間で安全を保証されていないチャレンジに対してMiM攻撃を実施する攻撃者が、これを、代替のチャレンジC'と置き換えることができる場合があり、それにより、所有者アリスがこれが起こったことに気付かないまま、デバイスにRの代わりに応答R'を生成させ、おそらくはこれを計算に使用するからである。
【0360】
ロギングメカニズム1004は、そのような攻撃を、攻撃が検証中に明らかにされるような方式で軽減するのに十分であり得る。われわれ、図10に示されるように、ログを生成するための処理要素およびログを記録するためのオンデバイスストレージ1006を含み得るため、ログは、特定のPUFモジュール603自体の設計に影響を及ぼす。
【0361】
1つの可能な実装形態において、設計内の汎用プロセッサが、結果を生成するために所望の計算を、ならびにログを生成するために必要なロジックを実施し得る。このセットアップは、ここでは、デバイスによって実施される動作のすべてが、なぜデバイスが予想外に行動し得るのかを照合するために検証プロセスと一緒に、記録および使用され得る。
【0362】
この「ローカル検証」シナリオにおいて、われわれは、将来の検証時間において、検証者103Vが、PUFモジュール603デバイスへの完全なアクセスを有して、その応答を調べることを前提としているということに留意されたい。ロギングシステムを特徴とするこの代替のセットアップは、その検証者103Vが、PUFモジュール603の所有者が検出し得なかった過去の中間者攻撃を検出することを可能にするためでる。検証者および所有者は、たとえば、クローズドIoTシステムの場合、同じ当事者であり得るということにも留意されたい。
【0363】
次の節では、われわれは、実施形態において、このロギングシステムが、公開ブロックチェーンをロギングプロセス内へ具体的に導入することによって、どのように強化され得るかを探索する。
【0364】
6.2 PUF完全性のためのブロックチェーンベースのイベントロギング
PUFベースのアイデンティティシステムを強化するためにブロックチェーンを使用するための本明細書に開示される別の態様は、上で述べた中間者攻撃のよりロバストな軽減を提供することにあり、われわれは、デバイスによって実施される動作を記録するためにPUFデバイスに組み込まれているロギングシステムの概念を導入した。
PUFベースのアイデンティティシステムを強化するためにブロックチェーンを使用するための本明細書に開示される別の態様は、上で述べた中間者攻撃のよりロバストな軽減を提供することにあり、われわれは、デバイスによって実施される動作を記録するためにPUFデバイスに組み込まれているロギングシステムの概念を導入した。
【0365】
この追加のログは、任意の当事者、アリス、ボブ、TTP、またはその他が、提出されたチャレンジCを修正して、修正されたチャレンジC'を形成すること(PUFデバイス1000により提供される応答R'が実際には期待される正しい応答Rに対応しないことを意味する)によって、何らかの形態の中間者攻撃を実施することを止めるための手段を提供することが意図される。
【0366】
ログは、トランジット内の(すなわち通信中の)チャレンジに対してなされるいかなる修正も検出されることを確実にすることによって、この問題を軽減する。しかしながら、これは、ログ自体が、それが上で概説した捜査再構築プロセス中に参考とされる前に、タンパリングされていないという仮定に基づいている。
【0367】
この懸念を解決するために、実施形態は、したがって、PUFデバイス1000の寿命の間、ログ自体の詳細をタンパリングおよび変更する悪意ある主体によるこの種の中間者攻撃に対するよりロバストなソリューションを提供する。
【0368】
これを達成するために、デバイス上にロギングされたデータは、ブロックチェーン150に提出される。好ましくは、これは、定期的に、およびおそらくは、図11に示されるように、2つの異なるタイムスケールで行われるべきである。
【0369】
そのような実施形態において、ログのコンテンツは、まず処理時(i)に提出され得、PUFデバイスによって受信される各動作(または要求)が、この動作または要求の記録を含むブロックチェーンにトランザクションを提出するようにデバイスをトリガする。図11に示されるように、これは、たとえば、要求内のチャレンジに対するPUF自体の関連応答を使用して有鍵化され得る、結果のHMACの形態で行われ得る。代替的に、結果は、暗号化され、同様の方式でブロックチェーンに書き込まれ得る。
【0370】
さらに、ログ全体は、(ii)オンデバイスストレージがパージされ得ること(デバイスのストレージオーバーヘッドを低減する)、およびメカニズムによる以前の証明が(i)後の時間点におけるログの状態と比較され得ること、の両方のために、ブロックチェーンに定期的に書き込まれ得る。同様に、このロギングは、HMAC、暗号化、または同様の手段により行われ得、われわれは、(i)または(ii)のいずれかを特定の記録方法に限定しない。データは、1つまたは複数のブロックチェーントランザクションに任意の好適な方式で記録され得る。
【0371】
リアルタイムに、および定期的なチェックポイントのようなものに基づいて、ログに記録される結果をミラーリングすることによって、われわれは、中間者攻撃がオンデバイスロギングシステムの悪意あるタンパリングに起因して検出されないリスクを最小限にすることができる。さらには、ロギングの第2の形態の周期性を注意深く選択すること(ii)により、システムは、そのようなタンパリングが発生していた可能性のある特定の時間窓の識別を可能にするはずである。この仮定は、信頼できるタイムスタンプサーバーとしてのブロックチェーンの使用に明白に依拠する。
【0372】
7. 安全を保証されていないチャネルを通じた安全な通信
上記説明は、PUFデバイス603がブロックチェーン150上に記録を安全にロギングできる実施形態を含んでいた。この考え方は、任意の送信エンティティ(当事者、または、PUFデバイスであるにしろその他であるにしろ、デバイス)が、たとえ送信者が送信者とブロックチェーン150との間で安全を保証されていないチャネルを使用しているとしても、ブロックチェーンを介して受信者と安全に通信することを可能にするまでに拡大され得る。この文脈において、安全を保証されていない(または安全ではない)とは、送信されているメッセージの妨害および改ざんに対して弱いことを意味する。
上記説明は、PUFデバイス603がブロックチェーン150上に記録を安全にロギングできる実施形態を含んでいた。この考え方は、任意の送信エンティティ(当事者、または、PUFデバイスであるにしろその他であるにしろ、デバイス)が、たとえ送信者が送信者とブロックチェーン150との間で安全を保証されていないチャネルを使用しているとしても、ブロックチェーンを介して受信者と安全に通信することを可能にするまでに拡大され得る。この文脈において、安全を保証されていない(または安全ではない)とは、送信されているメッセージの妨害および改ざんに対して弱いことを意味する。
【0373】
潜在的な問題は、図12に例証される。以下は、送信ユーザアリス103aおよび受信ユーザボブ103bに関連して説明されるものであり、送信ユーザアリス103aおよび受信ユーザボブ103bは、それぞれのコンピュータ機器102a、102bを使用してそれぞれの方法を実施していると仮定される。しかしながら、より一般的には、同じ教示が、任意の送信および受信エンティティに当てはまり得、それらの各々は、ユーザ機器102を使用する1つもしくは複数のユーザの当事者であり得るか、または代替的に、自律デバイスであり得る。
【0374】
通信媒体としてブロックチェーン150を介して2つのエンティティの間で通信することが知られている。図12に示されるように、送信者アリスは、対応するブロックチェーンネットワーク106によってブロックチェーン150上でトランザクションのペイロードに記録されるべきメッセージMを送信し、その結果として、受信者ボブは、ブロックチェーン150からメッセージを読むことができる。たとえば、メッセージMは、ロックスクリプト内でOP_RETURNまたはOP_PUSHDATAオペコードを使用することによって、トランザクションの出力に含まれ得る。アリスは、トランザクションを自分で定式化し、そのトランザクションをブロックチェーンネットワーク106に送信することによってメッセージMを送信し得るか、または、トランザクション内のメッセージをラッピングし、ブロックチェーンネットワーク106へと転送する何らかの中間エンティティにメッセージMを送信し得る。
【0375】
いずれにせよ、送信者アリスは、たとえば暗号を使用しない安全を保証されていないチャネル1100を介して、メッセージMをブロックチェーンネットワーク106へ向けて送信しなければならないことがある。このチャネルは、メッセージMを、それがブロックチェーンネットワーク106に到達する前に、別のメッセージM'へと変換する、またはそれを別のメッセージM'と置き換えることによってメッセージMを改ざんし得る悪意ある当事者による妨害に弱い場合がある。たとえチャネル1100が暗号化されるとしても、これは、悪意ある当事者がメッセージを改ざんすることを必ずしも防がない(悪意ある当事者は、元のメッセージが何を意味するかを知ることはできず、意味のある代替のメッセージM'を定式化することはできないが、これは、その当事者が、たとえば、サービス妨害攻撃の一部として、意味のないメッセージM'を送信することができないことは意味しない)。
【0376】
図13は、改ざんが発生したことをアリスに検出させ、その場合に安全を保証されていないチャネルを介して任意のさらなるメッセージを送信することを止めさせるメカニズムを提供することによって、この潜在的な問題を解決する配置構成を示す。
【0377】
アリスは、自分がボブに送信することを望む第1のメッセージMi=1を含む第1のトランザクションTx(Mi=1)を定式化することから始める。メッセージMiは、たとえば、それを出力のロックスクリプト内にOP_RETURNまたはOP_PUSHDATAと一緒に含むことなどによって、出力ベースの(たとえば、UTXOベースの)モデルでトランザクションの出力に含まれ得る。たとえば、それは、OP_RETURNおよびOP_FALSEを使用することなどによって、消費不可能な出力に含まれ得る。トランザクションは、ボブがオンチェーンで識別することができるボブのアドレス、またはボブがオンチェーンで監視しているフラグFを含むことなどによって、ボブに向けられる。アリスはまた、メッセージを含むトランザクションに署名する。すなわち、アリスは、アリスの鍵、および少なくともメッセージを含むトランザクションの部分の関数として、署名を生成し、トランザクション内に署名を含める。トランザクションペイロードを含むトランザクションに署名するための方法は、それ自体が当該技術分野において知られている。
【0378】
一旦形成されると、アリスは、ブロックチェーン150上のブロック151に記録されるように、ブロックチェーンネットワーク106のノード104に第1のトランザクションを送信する。アリスは、トランザクションを直接的に、または1つもしくは複数の中間者を介して、ノード104に送信し得る。いずれにせよ、アリスのコンピュータ102aとノード104との間のトランザクションのルートは、前に論じられるように、1つまたは複数の安全を保証されていないチャネル1100を含む。
【0379】
このチャネルを通じた第1のメッセージの可能な改ざんを検出するために、アリスは、オンチェーンで記録されている第1のメッセージを含む第1のトランザクションが期待通りであるかどうかをチェックするために、ブロックチェーン150をクエリする。アリスは、ブロックチェーンネットワーク106のノード104を直接的にクエリすること、または信頼できる中間サービスにクエリを提出することによってこれを行い得る。クエリは、メッセージのコピー、トランザクション識別子、またはトランザクション自体を返し得、アリスまたは信頼できるサービスが、これらを、送信されたメッセージ、トランザクションID、またはトランザクションに対して比較する。代替的に、クエリは、メッセージ、トランザクションID、またはトランザクションの証明、たとえばそれらのマークル証明、を返し得る。別の可能性として、アリスは、自分の署名をチェックし得る。どんな手段が実装されるにしろ、クエリは、こうして、アリスが、第1のメッセージが自分がそれを送信した形態で、オンチェーンで記録されているか否かをチェックすることを可能にする。そうでない場合、これは、第1のメッセージが妨害および改ざんされていることを示す。
【0380】
第1のメッセージM1は、アリスが上に説明されるものと同じ様式でブロックチェーン150を介してボブに送信することを意図する一連のメッセージMiの中の1番目であり得る。しかしながら、第2のメッセージM2(または任意の後続メッセージ)の送信は、メッセージがアリスとブロックチェーン150との間で改ざんされなかったという上述のチェックを条件とする。そうでない場合、アリスは、第2のメッセージM2または任意の後続メッセージを送信しない(少なくとも、安全性の問題の原因が解決されるまで)。実施形態において、クエリおよびチェック、ならびにさらなるメッセージのブロッキングは、アリスのコンピュータ機器102aによって自動的に実施される自動化ステップであり得る。アリスはまた、ボブに検出された改ざんを通知し得るため、ボブは、第1のメッセージM1を無視すべきことを知っている。いくつかの実施形態において、この通知ステップも自動化され得る。
【0381】
チェックが負の結果を返す、すなわち、メッセージが、前記クエリに基づいて、改ざんされていないことが決定された場合、アリスは、第2のメッセージM2、およびおそらくはさらなるメッセージMi=3,4…などを送信し得る。第2のメッセージM2は、第1のメッセージが第1のトランザクション内で送信されたのと同じ様式で、変更すべきこところは変更して、第2のトランザクションTx(M2)内で送信される。第2のトランザクションTx(M2)は、必ずしも第1のトランザクションTx(M1)を消費せず、必ずしも第1のトランザクションに依存して消費していない。そのため、出力ベースの(たとえば、UTXOベースの)トランザクションモデルでは、第2のトランザクションは、第1のトランザクションの出力(または第1のトランザクションと第2のトランザクションとの間の消費グラフ内の任意のトランザクションの出力)に向けた入力を必ずしも有さない。言い換えると、トランザクションは、ペイロード内でメッセージを通信するために使用されており、チェックは、たとえば、第1のトランザクションの出力を消費する前方の消費トランザクションを送信する前に、アリスが自分の変更についてチェックすることに及ぶだけではない。
【0382】
その一方で、チェックは、正の結果を返し得、すなわち、前記クエリに基づいて、メッセージは、改ざんされていることが決定された。言い換えると、障害ルートにおいて、アリスが受ける応答が、「いいえ、私はこのトランザクションを見たことがありません」、または「いいえ、私はこのトランザクションのためのマークル証明を所有していません」である場合、これは、アリスのトランザクションが妨害および変化され、その結果として、それがプロセスにおいて無効にされ、チェーンに至らなかったことを示唆する。この場合、アリスは、第2のメッセージM2を送信しない(または、少なくとも同じチャネルを介さずに)。実施形態において、これは、アリスのコンピュータ機器102a上で実行するソフトウェア105aによる第2のメッセージの送信を行う自動ブロックであり得る。
【0383】
故に、伝送メッセージのメッセージ完全性を確実にするための検証アルゴリズムの形態が提供される。何者かまたは何らかのデバイスAが、メッセージMを別の当事者Bに伝送することを望むが、それが妨害および変化され得ることを心配している場合、このアルゴリズムを使用して、メッセージが改ざんされなかったことを確信することができる。本方法は、伝送者および受信者の両方が読むことができるメッセージのためのアンカーポイントとしてブロックチェーンを使用するが、それは、Aがブロックチェーンから読むことができる場合、Aは、メッセージが、それが署名された瞬間から変わっていないことを確信することができるという追加のプロパティを有する。要約すると、アルゴリズムの実施形態は、以下のように、または同様に動作し得る。
1. 当事者Aおよび当事者Bは、安全でないチャネルを通じて伝送することを望む。
2. 当事者Aは、メッセージを作成し、ブロックチェーントランザクション内にパッケージし、トランザクションに署名する。
3.当事者Aは、トランザクションをブロックチェーンネットワークに提出する。当事者Aは、メッセージが修正されていないという証明についてブロックチェーンをクエリすることができる。たとえば、当事者Aは、自らのトランザクションのためのマークル証明を要求し得、これは、ボブが正しいメッセージを読むという確証として機能する。それは、証明としてプルーフオブワークを使用することから、マイナー(ノード)における信頼がなくても機能する。
4. 当事者Aは、自らが提出したトランザクションに対してマークル証明を検証することを試みる。
a. 成功の場合、当事者Aは、変更なしに後続メッセージを伝送し続ける。
b. そうでない場合、当事者Aは、中断/再提出(おそらく、異なるマイナーへ)などを行い、第1のメッセージが不成功であったことを示す新規メッセージを含むことができる。
1. 当事者Aおよび当事者Bは、安全でないチャネルを通じて伝送することを望む。
2. 当事者Aは、メッセージを作成し、ブロックチェーントランザクション内にパッケージし、トランザクションに署名する。
3.当事者Aは、トランザクションをブロックチェーンネットワークに提出する。当事者Aは、メッセージが修正されていないという証明についてブロックチェーンをクエリすることができる。たとえば、当事者Aは、自らのトランザクションのためのマークル証明を要求し得、これは、ボブが正しいメッセージを読むという確証として機能する。それは、証明としてプルーフオブワークを使用することから、マイナー(ノード)における信頼がなくても機能する。
4. 当事者Aは、自らが提出したトランザクションに対してマークル証明を検証することを試みる。
a. 成功の場合、当事者Aは、変更なしに後続メッセージを伝送し続ける。
b. そうでない場合、当事者Aは、中断/再提出(おそらく、異なるマイナーへ)などを行い、第1のメッセージが不成功であったことを示す新規メッセージを含むことができる。
【0384】
つまり、これは、たとえば、マークル証明の有効性に基づいて、通信チャネルにおいてどのように進めるかに関して、当事者Aが決定を下す(ステップ4)ための方式を提供する。
【0385】
実施形態において、改ざんについて同じチェックが、第3のトランザクションを送信するための条件として、変更すべきところは変更して、第2のトランザクションに適用され得る、というように続いていく。
【0386】
実施形態において、一連のメッセージMi=1,2,3,…は、たとえば、同じ通信全体の異なるパケットである、意味のある形でリンクされたコンテンツ(たとえば、書き込まれた文書、動画、または音声ファイルなど)を含み得る。
【0387】
実施形態において、メッセージMi自体と同様に、一連のトランザクションにおける各トランザクションもまた、それぞれのフラグFiを含み得る。ボブは、これを使用して、自分がブロックチェーン150を検査するときに、自分を対象にしたメッセージを識別することができる。代替的または追加的に、ボブのアドレスが、各トランザクションに含まれ得る。
【0388】
フラグFiは、どのメッセージが一連の一部を形成するのか、および一連におけるそれらの位置を識別するために、ボブによって使用され得る。実施形態において、フラグFiは、インデックス値iの関数であり得、インデックスiは、一連内での各メッセージの位置をインデックスする。これのために使用される関数は、アリスおよびボブの両方が事前に知っている既定の形態のものであり得る。
【0389】
いくつかのそのような実施形態において、一連のメッセージを通信する前の初期セットアップフェーズでは、アリスおよびボブは、安全なサイドチャネル107を通じて一連内の第1のフラグF1を確立し得る。アリスおよびボブは、一時的な安全なチャネル107をセットアップするためのリソースおよび能力を有し得るが、アリスおよびボブは、後でそれを使用し続けることができない場合がある。たとえば、安全を保証されたチャネル107は、たとえば、ディフィー-ヘルマン鍵交換を必要とする、暗号化されたチャネルであり得るが、アリスおよびボブは、後の通信時にこのチャネルを使用することができない場合がある。これは、たとえば、いずれかの当事者が、メッセージを通信する時に、ストレージまたはデバイス能力への限られたアクセスを有することになる場合、有用であり得る。たとえば、おそらく、ボブは、「切断(off the grid)」し、すべての電子デバイスを破壊したいと望むが、依然として、インターネットカフェに行き、フラグを使用しながらたまにブロックチェーンをチェックすることができる。その利点は、非常に強力なプライバシーである。別の例は、いずれかの当事者が、任意の時点でオフラインになる必要がある場合である。ブロックチェーンは、メッセージが送信される時点で受信者がオンラインであってもなくても通信が発生することを可能にすることにより、役立つ。
【0390】
セットアップフェーズは、アリスが第1のフラグをボブに送信すること、またはボブが第1のフラグをアリスに送信すること、またはアリスおよびボブが互いのプロトコルに従って第1のフラグを取り決めることを含み得る。共有の秘密を確立するためのプロトコルは、それ自体が当該技術分野において知られている。各フラグFiをインデックスiに関連付ける関数はまた、一連における第1のフラグF1または先行するフラグFi-1の関数であり得る。故に、安全なチャネル107は、初期セットアップフェーズにおいて一度使用される必要があるだけで、その後は、アリスおよびボブの両方が各連続フラグFiをインデックスiおよび第1のフラグまたは先行するフラグに関連付ける関数の形態を知っているため、アリスおよびボブは、代わりに、ブロックチェーン150を介して安全に通信することができ、ボブのみが、どのメッセージが一連の一部を形成し、それらがどんな順番で入るかを決定することができる。
【0391】
フラグFが使用されてもされなくても、ボブが、ブロックチェーン150上の自分を対象としたメッセージを識別する時、ボブはまた、アリスの公開鍵を使用して署名を認証し得る。しかしながら、署名だけが所望のレベルの安全性を必ずしも提供するのではなく、故に、第2のメッセージを見る前にチェーンにクエリする上記メカニズムは、署名の使用に加えて有用であり得るということを留意されたい。メッセージが改ざんされていた場合、多くの場合、それはトランザクションを無効にし、それは決してオンチェーンに至らない。そのため、そのような場合、ボブが、トランザクションがアリスによって行われたことを知っていると仮定すると、トランザクションがまさに現れるのをボブが見ることは、メッセージが「自分にとって」修正されていないことを知るには十分である。トランザクション(入力の可能性が高い)内の署名およびアリスの公開鍵をただ見ることでは、アリスがそれを作成したことを確信するには十分ではないが、ボブが自分で署名を検証する場合、ボブは確信することができる。そのため、この最後のステップは、ボブが自分に対するものであると思っているメッセージの出所がアリスからであったことを知っているとアサートするだけである。しかしながら、悪意ある当事者が、アリスのトランザクションを、悪意ある当事者の公開鍵で有効に署名された別のトランザクションと置き換え得る。そのようなトランザクションは、ブロックチェーンネットワーク106によって検証され、オンチェーンで記録される。ボブは、そのトランザクションに含まれる公開鍵に基づいて署名を検証し得るが、ボブが、その公開鍵がアリスの実際のアイデンティティとリンクされることを知らない場合、ボブは、メッセージが妨害されたかどうかが依然として分からない。すなわち、それがアリスの公開鍵であると確信しないことは、ボブが、メッセージが妨害されなかったことを確信することができないことを意味する。
【0392】
8. 結論
開示された技術の他の変更形態またはユースケースは、本明細書において開示を示した後に当業者にとって明らかになるであろう。本開示の範囲は、説明されている実施形態によって限定されず、付属の請求項によってのみ限定される。
開示された技術の他の変更形態またはユースケースは、本明細書において開示を示した後に当業者にとって明らかになるであろう。本開示の範囲は、説明されている実施形態によって限定されず、付属の請求項によってのみ限定される。
【0393】
たとえば、上記のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されてきた。しかしながら、ビットコインブロックチェーンはブロックチェーン150の特定の一例であり、上記の説明は、任意のブロックチェーンに一般的に適用され得ることは理解されるであろう。すなわち、本発明は、決してビットコインブロックチェーンに限定されるものではない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記の任意の参照は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104への参照で置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上で説明されているビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明されている特性のいくつかまたはすべてを共有し得る。
【0394】
本発明の好ましい実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成し、公開し、伝播し、および記憶する説明されている機能の少なくともすべてを実行する。これらの機能のうちの1つまたはいくつかだけを実行し、すべてを実行することはない他のネットワークエンティティ(またはネットワーク要素)があり得ることは除外されない。すなわち、ネットワークエンティティは、ブロックを作成し公開することなく、ブロックを伝播し、および/または記憶する機能を実行し得る(これらのエンティティは、好ましいビットコインネットワーク106のノードとは考えられないことを想起されたい)。
【0395】
本発明の他の実施形態では、ブロックチェーンネットワーク106は、ビットコインネットワークでなくてもよい。これらの実施形態において、ノードがブロックチェーン150のブロック151を作成し、公開し、伝播し、記憶する機能の少なくとも1つまたはいくつかを実行し得るが、すべてを実行するわけではないことは除外されない。たとえば、それらの他のブロックチェーンネットワークにおいて、「ノード」は、ブロック151を作成し、公開するように構成されているが、それらのブロック151を他のノードに記憶しおよび/または伝播することをしないネットワークエンティティを参照するために使用され得る。
【0396】
さらに一般的には、上記の用語「ビットコインノード」104への任意の参照は、用語「ネットワークエンティティ」または「ネットワーク要素」で置き換えられてもよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、伝播し、記憶する役割のいくつかまたはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104を参照しつつ上で説明されているのと同じ方法を用いてハードウェアで実装され得る。
【0397】
上記の実施形態は、例としてのみ説明されていることは理解されるであろう。より一般的には、次のステートメントのいずれか1つまたは複数による方法、装置、またはプログラムが提供され得る。
【0398】
ステートメント1.物理複製困難関数(PUF)、および、入力チャレンジを受信し、入力チャレンジの確定関数である出力応答を出力するように配置構成されている内部PUFインターフェースロジック、を含むPUFモジュールであって、確定関数がPUFを含む、PUFモジュールと、PUFモジュールの内部インターフェースロジックに入力チャレンジを入力し、内部インターフェースロジックによって出力されて返ってくる出力応答を受信するための安全を保証されていないチャネルの少なくとも一部を提供する1つまたは複数の外層コンポーネントと、を備え、外層コンポーネントのうちの少なくとも1つは、悪意あるプロセスによる入力チャレンジおよび/または出力応答の改ざんの影響を受けやすいが、内部PUFインターフェースロジックを含むPUFモジュールは、デバイスのハウジング内に封入され、1つまたは複数の外層コンポーネントから分離され、および故に、悪意あるプロセスによる改ざんから保護され、内部PUFインターフェースロジックは、入力チャレンジおよび/または出力応答の記録をログ媒体に自動的にロギングするように配置構成されているロギングメカニズムを備える、デバイス。
【0399】
ステートメント2.内部インターフェースロジックは、デバイスのプロセッサ上で実行されるファームウェアにおいて部分的にまたは全体的に実装される、ステートメント1に記載のデバイス。
【0400】
ステートメント3.ファームウェアは、リードオンリメモリ(ROM)に部分的にまたは全体的に記憶される、ステートメント2に記載のデバイス。
【0401】
ステートメント4.ファームウェアは、安全なカーネルにおいて部分的にまたは全体的に実装される、ステートメント1または2に記載のデバイス。
【0402】
ステートメント5.内部インターフェースロジックは、固定関数ハードウェア回路において実装される、ステートメント1から4のいずれかに記載のデバイス。
【0403】
ステートメント6.少なくとも1つの外層コンポーネントは、デバイスの外部のソースから入力チャレンジを受信するため、および/またはデバイスの外部の宛先へ出力応答を供給するための外部インターフェースを備え、少なくとも1つの外層コンポーネントが影響を受けやすい悪意あるプロセスは、ソースと外部インターフェースとの間での入力チャレンジおよび/または出力応答の妨害および改ざんを含む、ステートメント1から5のいずれかに記載のデバイス。
【0404】
ステートメント7.ソースは、デバイスにローカルであり、外部インターフェースは、ネットワークを通じた伝送なしに入力チャレンジを受信するように動作可能である、ステートメント6に記載のデバイス。
【0405】
ステートメント8.ソースは、デバイスのリモートにあり、外部インターフェースは、ネットワークを介してソースから入力チャレンジを受信するように動作可能である、ステートメント6に記載のデバイス。
【0406】
ステートメント9.専用PUFデバイスを備える、ステートメント6から8のいずれかに記載のデバイス。
【0407】
ステートメント10.少なくとも1つの外層コンポーネントは、デバイスのハウジング内のプロセッサ上で実行するアプリケーションを備え、アプリケーションは、入力チャレンジを生成するように構成され、少なくとも1つの外層コンポーネントが影響を受けやすい悪意あるプロセスは、入力チャレンジを改ざんするためにアプリケーションと同じプロセッサ上で実行されるマルウェアを含む、ステートメント1から8のいずれかに記載のデバイス。
【0408】
ステートメント11.内部インターフェースロジックは、アプリケーションとは別のプロセッサ上で実行するように配置構成される、ステートメント10に記載のデバイス。
【0409】
ステートメント12.内部インターフェースロジックは、アプリケーションと同じプロセッサ上で、しかしながら安全なプロセッサの特権ドメイン内で実行するように配置構成される一方、アプリケーションは、アプリケーションドメイン内で実行する、ステートメント10に記載のデバイス。
【0410】
ステートメント13.デバイスは、イベントデータレコーダ(EDR)を備え、アプリケーションは、EDRアプリケーションを含む、ステートメント10から12のいずれかに記載のデバイス。
【0411】
ステートメント14.アプリケーションは、EDRが監視するように構成されるシステムの結果を生成するように構成され、EDRは、結果、および出力応答を結果にマッピングするタグを記録するように構成される、ステートメント13に記載のデバイス。
【0412】
ステートメント15.タグは、出力応答で結果に署名することによって生成される暗号署名、または結果および出力応答の関数として生成されるハッシュベースのメッセージ認証コード(HMAC)を含む、ステートメント14に記載のデバイス。
【0413】
ステートメント16.入力チャレンジは、システムの状態が監視されていることを表す、アプリケーションによって使用される意味のあるデータを含む、ステートメント14または15に記載のデバイス。
【0414】
ステートメント17.結果は、前記データに依存する、ステートメント16に記載のデバイス。
【0415】
ステートメント18.EDRは、車両のためのEDRであり、EDRが監視するように構成されるシステムは、車両のシステムを含む、ステートメント13から17のいずれかに記載のデバイス。
【0416】
ステートメント19.1つまたは複数の外層コンポーネントは、PUFモジュールと同じハウジングにおいて実装される、ステートメント1から18のいずれかに記載のデバイス。
【0417】
ステートメント20.PUFモジュールは、拡張PUFモジュールを含み、入力チャレンジは、二次チャレンジであり、出力応答は、二次応答であり、内部PUFインターフェースロジックは、一次応答を生成するためにPUF内にチャレンジを入力し、二次応答を一次応答および二次チャレンジの決定論的変換として決定するように構成される、ステートメント1から19のいずれかに記載のデバイス。
【0418】
ステートメント21.決定論的変換は、ハッシュ関数を含む、ステートメント20に記載のデバイス。
【0419】
ステートメント22.インターフェースロジックは、入力チャレンジをPUFに直接的に入力し、入力応答の関数として出力応答をPUFから直接的に受信するように構成される、ステートメント1から19のいずれかに記載のデバイス。
【0420】
ステートメント23.ログ媒体は、デバイスのローカルメモリを含む、ステートメント1から22のいずれかに記載のデバイス。
【0421】
ステートメント24.前記ローカルメモリは、改ざん防止メモリ、1回だけ書き込み可能なメモリである、および/またはインターフェースロジックに埋め込まれる、ステートメント23に記載のデバイス。
【0422】
ステートメント25.PUFインターフェースロジックが記録をロギングするように構成されるログ媒体は、デバイスの外部の公的にアクセス可能な媒体を含む、ステートメント1から24のいずれかに記載のデバイス。
【0423】
ステートメント26.PUFインターフェースロジックが記録をロギングするように構成される公的にアクセス可能な媒体は、ブロックチェーンを含む、ステートメント25に記載のデバイス。
【0424】
ステートメント27.内部PUFインターフェースロジックは、個々の入力チャレンジの入力に応答して記録のロギングをリアルタイムで実施するように構成される、ステートメント1から26のいずれかに記載のデバイス。
【0425】
ステートメント28.内部PUFインターフェースロジックは、定期的な時間窓の各インスタンスの間、任意の受信される入力チャレンジおよび/または生成される出力応答を定期的にロギングするように構成される、ステートメント1から27のいずれかに記載のデバイス。
【0426】
ステートメント29.内部PUFインターフェースロジックは、個々の入力チャレンジの入力に応答して記録を前記ローカルメモリにリアルタイムでロギングするように、およびまた、公的にアクセス可能な媒体への定期的なロギングを実施するように構成される、少なくともステートメント23、25、および27に従属する、ステートメント28に記載のデバイス。
【0427】
ステートメント30.ロギングメカニズムは、公的にアクセス可能な媒体に一旦ロギングされると、ロギングされたチャレンジおよび/または応答をローカルメモリから定期的にクリアするようにさらに構成される、ステートメント29に記載のデバイス。
【0428】
ステートメント31.ロギングメカニズムは、個々の入力チャレンジの入力に応答して記録を公的にアクセス可能な媒体にリアルタイムでロギングするように構成される、ステートメント25、またはそれに従属する任意の後続ステートメントに記載のデバイス。
【0429】
ステートメント32.内部PUFインターフェースロジックは、少なくとも入力チャレンジの記録をロギングするように構成される、ステートメント1から31のいずれかに記載のデバイス。
【0430】
ステートメント33.内部PUFインターフェースロジックは、少なくとも出力応答の記録をロギングするように構成される、ステートメント1から32のいずれかに記載のデバイス。
【0431】
ステートメント34.ロギングメカニズムは、記録を、そのロギングのために、パケット内に出力するように構成され、パケットは、記録を含むパケットの少なくとも一部に適用されるロギングメカニズムの暗号鍵に基づいて生成される署名をさらに含む、ステートメント1から33のいずれかに記載のデバイス。
【0432】
ステートメント35.パケットは、ブロックチェーントランザクションを含み、記録は、ブロックチェーントランザクションの出力に含まれており、署名は、トランザクションの入力に含まれている、少なくともステートメント26に従属する、ステートメント34に記載のデバイス。
【0433】
ステートメント36.ステートメント1から35のいずれかに記載のデバイスを使用する方法であって、入力チャレンジおよび/または出力応答の記録がログ媒体にロギングされた後、PUFモジュールに候補応答を生成させ、安全を保証されていないチャネルを介して候補応答を返すために、外層の安全を保証されていないチャネルを介してデバイスに候補チャレンジを入力するステップと、ログ媒体にロギングされた元の入力チャレンジの記録に対して候補チャレンジをチェックすることによって、および/または、ログ媒体にロギングされた元の出力応答の記録に対して候補応答をチェックすることによって、改ざんの証拠をチェックするステップと、を含む、方法。
【0434】
ステートメント37.前記チェックするステップは、候補チャレンジが、ログ媒体に記録された際の入力チャレンジの記録に一致することをチェックすることを少なくとも含む、ステートメント36に記載の方法。
【0435】
ステートメント38.内部PUFインターフェースロジックは、候補応答の記録をロギングするようにさらに構成され、前記チェックするステップは、候補応答のロギングされた記録が、デバイスに入力された際の候補応答に一致することをチェックすることを少なくとも含む、ステートメント36または37に記載の方法。
【0436】
ステートメント39.前記チェックするステップは、候補応答が、ログ媒体に記録された際の元の出力応答の記録に一致することをチェックすることを少なくとも含む、ステートメント35から38のいずれかに記載の方法。
【0437】
ステートメント40.方法は、クレーム14またはそれに従属する任意のデバイスクレームのデバイスを使用する方法であり、方法は、候補結果に基づいてタグを検証することによって、デバイスが、結果をもたらしたデバイスであることを検証するステップを含む、ステートメント36から39のいずれかに記載の方法。
【0438】
ステートメント41:1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置とを備え、メモリは、処理装置上で実行するように配置構成されているコードを記憶し、コードは処理装置上にあるときにステートメント36から40のいずれかに記載の方法を実行するように構成される、コンピュータ機器。
【0439】
ステートメント42:非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されたときに、ステートメント36から40のいずれかに記載の方法を実行するように構成されているコンピュータプログラム。
【0440】
ステートメント43.第1のエンティティによって、ブロックチェーン上に記録されるべき第1のメッセージングトランザクションを送信するステップであって、第1のメッセージングトランザクションは、第1のメッセージ、および、第2のエンティティがブロックチェーン上の第1のメッセージを識別することができるように、第1のメッセージを第2のエンティティに向けるそれぞれの情報を含む、ステップと、第1のメッセージが改ざんなしにブロックチェーン上に記録されていることをチェックするためのクエリを提出するステップと、第1のメッセージが、前記クエリに従って改ざんなしにブロックチェーン上に記録されていることが決定されるという条件で、ブロックチェーン上に記録されるべき第2のメッセージングトランザクションを送信するステップであって、第2のメッセージングトランザクションは、第2のメッセージ、および、第2のエンティティがブロックチェーン上の第1のメッセージを識別することができるように、第2のメッセージを第2のエンティティに向けるそれぞれの情報を含む、ステップと、を含む、コンピュータ実装方法。
【0441】
ステートメント44.第1のメッセージングトランザクションは、第1の資金トランザクションの出力を指し示す入力を含み、第2のメッセージングトランザクションは、第2の資金トランザクションの出力を指し示す入力を含み、第1のメッセージングトランザクションの任意の出力を指し示す入力を含まない、ステートメント43に記載の方法。
【0442】
ステートメント45.第1および第2のメッセージは、2つ以上のメッセージのシーケンスにおける連続メッセージであり、各々がシーケンス内に関連インデックスを有し、各々がブロックチェーン上に記録されるべき第1のエンティティによるそれぞれのメッセージングトランザクションにおいて送信され、各々のメッセージングトランザクションが、第2のエンティティがブロックチェーン上のメッセージを識別することを可能にするそれぞれの情報を含み、各メッセージ内のそれぞれの情報は、i)関連インデックスおよびii)シーケンス内の第1のフラグまたは先行フラグの関数であるフラグを含み、関数の形態は、第1および第2のエンティティの各々に知られており、方法は、第1および第2のエンティティが第1のメッセージのフラグに合意し、これにより、それらが、関数の形態、第1のフラグ、および各メッセージのインデックスに基づいて、メッセージの前記シーケンスを使用してブロックチェーンを介して連続して通信することを可能にする、初期セットアップフェーズを含む、ステートメント43または44に記載の方法。
【0443】
ステートメント46:1つまたは複数のメモリユニットを含むメモリと、1つまたは複数の処理ユニットを含む処理装置とを備え、メモリは、処理装置上で実行するように配置構成されているコードを記憶し、コードは処理装置においてステートメント43から45のいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。
【0444】
ステートメント47.非一時的コンピュータ可読媒体上に具現化され、1つまたは複数のプロセッサ上で実行されるとき、ステートメント43から45のいずれかに記載の方法を実施するように構成されているコンピュータプログラム。
【符号の説明】
【0445】
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 変換ロジック
601 応答データストア
602 第三者コンピュータ機器
603 PUFモジュール
702 セットアップフェーズ
704 検証フェーズ
802 識別情報
804 組合せ
806 識別情報
901 応答データ
901' 応答データ
903 PUFモジュール
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 変換ロジック
601 応答データストア
602 第三者コンピュータ機器
603 PUFモジュール
702 セットアップフェーズ
704 検証フェーズ
802 識別情報
804 組合せ
806 識別情報
901 応答データ
901' 応答データ
903 PUFモジュール
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8A】
【図8B】
【図8C】
【図9】
【図10】
【図11】
【図12】
【図13】
【国際調査報告】