JP2022549070A - ブロックチェーン上に認証済みデータを格納するコンピュータにより実施される方法及びシステム - Google Patents

Abstract

ブロックチェーンに認証済みデータを格納する方法が開示される。前記方法は、第１ブロックチェーントランザクション（Tx１）を生成するステップであって、第１ブロックチェーントランザクション（Tx１）は、暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データを含む第１アウトプット（Output３）と、前記第１公開鍵に関連する第１データと、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により前記第１データ及び前記第１公開鍵に適用される第１デジタル署名とを含む、ステップを含む。前記第１ブロックチェーントランザクションは、前記ブロックチェーンにブロードキャストされる。

Description

本開示は、ブロックチェーン上に認証済みデータを格納するコンピュータにより実施される方法及びシステムに関する。

＜序論＞
認証局（Certificate authority(CA)）は、デジタルアセットの信頼できる及び正当な所有権を保証し、デジタル証明書の発行を通じてユーザアイデンティティに公開鍵をリンクする。デジタル証明書は、安全なウェブブラウジングの不可欠な部分であり、インターネット上の機密情報のセキュアな交換を可能にする。デジタル空間で生じる商業的及び社会的活動の比率が増大している。例えば、２０１７年の全世界の小売eコマースの売上高は２．３兆ドルであり、２０２１年までに４．８兆ドルに達すると予測されている［“Global Retail E-Commerce Market Size ２０１４-２０２１,” Statista, ２０１９, https://www.statista.com/statistics/３７９０４６/worldwide-retail-e-commerce-sales/］。これは、認証局及びデジタル証明書により支えられる安全なウェブブラウジングにおける信頼の普及によってのみ可能になっている。デジタルアセットの移転を含む任意の商業的活動は、同じレベルの信頼を要求し、暗号法だけに依存することはできない。

ブロックチェーンエコシステム内では、エンティティは、秘密／公開鍵ペアを用いて変名で（pseudonymously）価値を交換する。相互作用するとき、エンティティに対して彼らのアイデンティティを開示することは本来要求されない。これは必要なプライバシの特徴であるが、潜在的なビジネス及び消費者にとって明らかなセキュリティ上のリスクを提示する。現在、非常に少数のソフトウェア実装及びデジタルアセット交換しか、公開鍵が「現実世界」のアイデンティティに安全にリンクできることを保証するための十分に強力なKYC（know-your-customer）プロトコルを有しない。KYCのための工業標準又はアイデンティティ管理のためのオンチェーン方法の開発には僅かな進捗しかない。結果として、支払人及び受取人は、安全であるために、中央エンティティの同じソフトウェアにより管理されるウォレットを使用することに制限される。

ブロックチェーンアーキテクチャは、セキュアな鍵管理以外にオフチェーンのセキュリティプロトコルに依存することなく、アイデンティティ証明書のオンチェーンでの発行及び管理をサポートするために十分強力である。更に、セキュリティ及びデータ完全性と結合されたブロックチェーンデータを読み出す比較的低いコストは、証明書プロバイダのための既存の方法に対して有意な経済的利点を提供する。

＜序章＞
＜デジタル証明書＞
デジタル証明書は、公開鍵の所有権を証明するために使用される。X.５０９は、現在、公開鍵証明書の標準的フォーマットである。図１は、各属性の説明と共に、最新バージョン（v３）のデータ構造を示す。デジタル証明書は、信頼するパーティが、被証明公開鍵に対応する秘密鍵に関して生成された署名又はアサーション（assertion）を信頼することを可能にする。

発行者は、認証局（certificate authority (CA)）として知られており、証明書の最後のフィールドに署名を提供する。CAは、自身の秘密鍵を使用して、ハッシュアルゴリズムの識別子を含むX.５０９標準の全部の他のフィールドのハッシュから生成されたメッセージダイジェストに署名する。この署名済みダイジェストは、証明書の中の最終エントリとして現れる。

デジタル証明書の検証は、発行者の署名処理と同様である。示されたハッシュアルゴリズムは、CAの署名を除く証明書内の全部のフィールドからダイジェストを生成するために使用される。CAの公開鍵は、次に、同封されたメッセージダイジェストを取得するために証明書の末尾にある署名を検証するために使用される。全部のフィールドのハッシュが同封されたダイジェストに等しい場合、証明書は、有効であり改ざんされていないと考えられる。

留意すべきことに、X.５０９証明書の全ての署名について、２つの公開鍵アルゴリズムが関連する。つまり、CAにより保護されるサブジェクトの公開鍵、及び証明書が署名されるアルゴリズムである。これらのアルゴリズムは互いに独立であり、以下に更に詳述されるように、認証済み公開鍵は、１６０ビット楕円曲線方式に属することができ、証明書は、RSA２０４８ビットアルゴリズムにより署名されることができる。[C. Paar and J. Pelzl, Understanding Cryptography, Berlin: Springer, ２０１０].
＜CAエコシステム＞
CAは、デジタル証明書を発行するエンティティである。CAは、証明書のサブジェクト（所有者）及び証明書に依存するパーティにより信頼される信頼できる第三者として機能する。CAは、通常、HTTPS（World Wide Webのためのセキュアなブラウシンジプロトコル）で使用される証明書に署名するか、又は文書の電子署名のための各国政府によるIDカードを発行しなければならない[https://en.wikipedia.org/wiki/Certificate_authority]。

CAは、組織の内部又は外部にあることができる。商業的CAは、証明書の発行に課金する。幾つかの一般的な外部CAは、Symantec (以前のVerisign)、Digicert、Comodo、Geotrust及びEquifaxを含む[https://slideplayer.com/slide/４２５４４１２/]。Let’s Encrypt [https://letsencrypt.org/getting-started/]は、オープンソースCA、及びMozilla、Cisco、Facebook、Chrome、等の多くの企業により支援される共同イニシアチブである。それは高いセキュリティを提供するが、無料証明書の欠点は、保証や追加機能に欠けることである。上位CAの比較レビューは、[https://premium.wpmudev.org/blog/ssl-certificate-authorities-reviewed/]にある。

小さな組織は管理された／ホスティングされたCAサービスを使用する傾向があるが、政府機関や中規模組織は、彼ら自身の内部CAを展開することが多い（例えば、Windows ServerにおけるCertificate Services、GoogleのGoogle Trust Services、GlobalSign Root CA-R２）。この場合、証明書の信頼は、それを発行した組織に基づく[https://sachi７３blog.wordpress.com/２０１３/１１/２１/x５０９-certificate-asymmetric-encryption-and-digital-signatures/]。

図２は、デジタル証明書８の発行者のための外部（商業的）CA６に、証明書署名要求（certificate signing request (CSR)）４を提供するクライアント（サブジェクト）２の処理を示す。CSRは、サブジェクト名１０、公開鍵１２、及び使用されるアルゴリズム（以下に詳述するように、大多数がRSAを使用する）を含む。秘密１３－公開１２鍵ペア１６の公開鍵１２は、クライアント２により生成され、秘密鍵１４は秘密鍵ストア１８内に保護される。公開鍵１２は、CSR４の中でCA６に提出される。CA６は、クライアントのアイデンティティを検証し、クライアントの公開鍵１２に（CAの秘密鍵により）X.５０９フォーマットを用いて署名する。署名済みデジタル証明書８は、次に、クライアント２に発行される。

＜信頼のチェーン＞
CAエコシステムは、信頼の階層的チェーンを用いてスケーラブル且つ信頼できるように生成される。所謂Root CAは、チェーンの基礎を形成するアンカーとして機能する。Root CAは、自身の証明書発行負荷を、下位（中間）CAに渡り分散する。下位CAは、彼らの負荷を発行CAに分散するかも知れない。留意すべきことに、通常、エンドエンティティとRoot CAとの間のチェーン内に少なくとも１つの中間証明書があるが、１つより多くが存在することができる。

ブランチの末端のCAは、クライアントと相互作用して、デジタル証明書を発行する。この階層的アプローチは、エコシステムの能力、管理可能性、及び回復力を向上する。下位CAは、専門家機能、異なるアプリケーションをサポートするために、又は領域的分離を導入するために、異なる組織領域の細分化を可能にする。例えば、異なる法域で活動する政策局（policy authorities (Policy CAs)）が確立されることができる[https://www.ncipher.com/resources/research-reports-and-white-papers/securing-your-pki]。CAは、CAの代わりに個人又は組織のアイデンティティチェックを実行する登録局（Registration Authority (RA)）を使用することを選択してもよい。留意すべきことに、RAは実際には任意の証明書に署名／発行しない[https://www.tutorialspoint.com/cryptography/public_key_infrastructure.htm]。

図３は、CAの階層構造からもたらされる証明書信頼チェーンを示す。Root CAは、ルート証明書に自己署名し、CAとしての自身のアイデンティティを検証する。下位CAは、Root CAにより署名及び発行された中間証明書を通じて認証される。前者は、エンドエンティティ証明書を発行して、チェーン内の最終CA（発行CA、Issuing CA）を認証する。信頼するパーティは、チェーン内の任意のレベルで証明書を信頼することを選択できる。その結果、彼らは、自動的にチェーンの更に下位の全部の証明書を信頼する。

＜鍵管理＞
＜PKIエコシステム＞
公開鍵基盤（public key infrastructure (PKI)）は、暗号データセキュリティのための拡張可能な枠組みを提供し、デジタル証明書及び公開鍵を生成し、管理し、分配し、使用し、格納し、及び廃止するためのハードウェア、ソフトウェア、ポリシ、処理、及び手順のセットを包含する。CAは、階層的信頼チェーンを通じて、この暗号のチェーン＞枠組みのセキュリティを支えることにより、PKIのコアコンポーネントとして機能する。PKIのアプリケーションは、公開されているウェブサイト、VPN、エンタープライズユーザ認証、装置認証、クラウドベースアプリ、電子メールセキュリティ及びモバイル認証のために、SSL/TLS証明書を含む[https://www.ncipher.com/resources/research-reports-and-white-papers/securing-your-pki]。

理想的な世界では、１つのCA、従って１つの信頼ソースが存在する。更に、異なるRoot CAの下で動作し及び彼らのそれぞれのRoot公開鍵を有するデジタル証明書を発行する複数のCAが存在する。これは、複数のPKIをもたらす。２つの加入者Alice及びBobが異なるCAを使用する、つまり、AliceがSymantecを使用し、Symantec公開鍵を有し、一方、BobがEquifaxを使用し、Equifax公開鍵を有する場合を検討する。Bobは彼のデジタル証明書をAliceへ送信する。AliceはEquifax公開鍵を所有していないが、Aliceは、Bobの証明書を検証して、彼の認証済み公開鍵を抽出する必要がある。

これを解決するために、各Root CAは、全部の他のRoot CAの証明書を維持していなければならない。各CAは、廃止リストのような、他のCAからの他の有用な情報を保持することもできる。図４は、個々のRoot CAの間でPKIがどのようにマッピングされるかを示す。両矢印は、X及びYが互いに証明書に署名していることを示す[https://slideplayer.com/slide/４２５４４１２/]。

加入者は、従って、彼らのCAと契約して、別のCAの公開鍵を含む証明書を取得する。Alice及びBobの例では、Bobは、Aliceに、署名書Symantec<<Equifax>>及びEquifax<<Bob>>を送信する。Aliceは、Symantecの公開鍵を使用してSymantec<<Equifax>>を検証し、Equifaxの公開鍵を抽出してEquifax<<Bob>>を検証する。Aliceは、次に、Bobの認証済み公開鍵を抽出することができる。この処理は、証明書チェーン（certificate chaining）として知られる。

＜鍵ペア＞
デジタル証明書は、以下のアルゴリズムのうちの１つにより署名される：
Rivest－Shamir－Adleman (RSA)アルゴリズム：RSAは、第１公開鍵暗号システムのうちの１つであり、デジタル証明書において最も広く使用されている。そのセキュリティは、大きな整数因数分解の難しさに関連しており、従って、セキュアな乱数生成器を必要としない。RSAは、DSAと比べて、署名検証では速いが、署名生成では遅い［https://askubuntu.com/questions/３６３２０７/what-is-the-difference-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses/３６３２２１］。

Digital Signature Algorithm (DSA)：DSAは、デジタル署名のためのUS標準である。それは、RSAと同じ鍵サイズを使用するが、離散対数問題に基づく。アルゴリズムのセキュリティは、DSAを導出するために使用される乱数生成器の強度に依存し、署名の生成ではRSAより速いが、それらを検証するのは遅い[https://askubuntu.com/questions/３６３２０７/what-is-the-difference-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses/３６３２２１]。

Elliptic Curve Digital Signature Algorithm (ECDSA)：ECDSAは、DSAの楕円曲線実装であり、楕円曲線上の（２つのうちの１つの）座標による表現のために、計算上軽量である[https://askubuntu.com/questions/３６３２０７/what-is-the-difference-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses/３６３２２１]。それは、通常、暗号システムのエントロピーに対する同じ感度を共有するので、DSAよりもセキュアであると考えられる[https://security.stackexchange.com/questions/１７８９５８/what-are-the-differences-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses?noredirect=１&lq=１]。楕円曲線暗号法（Elliptic Curve Cryptography (ECC)）に基づき、ECDSAは、より小さい鍵サイズについて、RSAと同じレベルのセキュリティを提供する。ECC２５６ビット証明書は、３０７２ビットRSA鍵と等価である[https://www.digicert.com/ecc.htm]。これらの小さいが強力な鍵は、同じレベルのセキュリティについてECC証明書で少ないデータしか送信されないので、計算能力の効率的な使用を可能にする。ECC証明書は、従って、モバイルプラットフォームのために好適である。少ないCPU及びメモリ要件は、ネットワーク性能も向上する。留意すべきことに、ECCは計算効率の点で利益を提供するが、ECDSA署名の検証は、計算集約的タスクになり、幾つかの装置ではRSAより遅くなることがある[https://www.digicert.com/ecc.htm]。

＜HDウォレット＞
決定性鍵は、単一の「シード（seed）」値から初期化された秘密鍵である[A.M.Antonopoulos, “Chapter５,” in Mastering Bitcoin, California, O’Reilly, ２０１７, pp.９３-９８]。シードは、マスタ秘密－公開鍵ペアを生成するために使用されるランダムに生成された数値である。決定性鍵は、互いに関連付けられ、シード鍵により完全に復元可能である。図５に示されるように、HDウォレット２０は、最も一般的な決定性鍵導出方法である。HDウォレットでは、マスタ鍵２２の形式の親鍵がシード鍵２４から生成され、それがまた、子鍵２６のシーケンスを生成し、子鍵がまた孫鍵２８のシーケンスを生成し、以下同様である。それらの導出の更なる詳細は以下に与えられる。このツリーのような構造は、図５に示され、鍵のセキュリティ及び復元の点で、幾つかの鍵を管理するための強力なメカニズムである。ユーザは、対応する秘密鍵を有しないで、公開鍵のシーケンスを生成できる。より少ないシークレットしか格納される必要がないので、暴露されるリスクが低い。更に、鍵が失われ／壊れた場合には、それらはシード鍵２４から復元できる。

＜シークレット値分布＞
２者間、つまりAliceとBobとの間のシークレット値分布については、国際特許出願公開WO２０１７/１４５０１６に技術的仕様が記載されており、その概要がいかに提供される。
１．Aliceがメッセージを生成し、それをハッシングする。
２．Aliceが、ハッシング済みメッセージを用いて、EC加算により２次秘密－公開鍵ペアを生成する。
３．Aliceは、彼女の２次秘密鍵により署名されたハッシング済みメッセージをBobに送信する。
４．Bobは、Aliceの署名を検証する。
５．Bobは、ハッシング済みメッセージを用いて、EC加算により２次秘密－公開鍵ペアを生成する。
６．AliceとBobは、今や２人とも、それぞれ他方の２次公開鍵を計算することができる。
７．AliceとBobは、彼らの個々の２次秘密鍵を、それぞれ他方の２次公開鍵により乗算して、共有シークレットを導出する（交換法則）。
８．ハッシング済みメッセージをハッシングすること（及びハッシング済みメッセージのハッシュをハッシングすること、等）は、共有シークレットの階層構造の生成を可能にする。ここでは、元のメッセージのみが知られている必要がある。

例えば上述のタイプのデジタル証明書をブロックチェーンに格納することが望ましいことがある。

したがって、本開示によると、添付の請求項において定められる方法が提供される。

ブロックチェーンに認証済みデータを格納する方法であって、前記方法は、
第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションの第１アウトプットは、暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データを含み、前記第１ブロックチェーントランザクションは、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名された第１デジタル署名を含み、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
前記第１ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
を含む方法が提供され得る。

ブロックチェーンに格納された認証済みデータを検証する方法であって、前記方法は、
（ｉ）暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データと、（ｉｉ）ブロックチェーントランザクションに格納された第１デジタル署名と、を識別するステップであって、前記ブロックチェーントランザクションの第１アウトプットは前記第１データを含み、前記第１デジタル署名は、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
前記第２公開鍵により前記第１デジタル署名を検証するステップと、
を含む方法が提供され得る。

第１参加者と第２参加者との間で暗号システムの公開鍵を共有する方法であって、前記第１参加者は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１秘密鍵を有し、前記第２参加者は、前記暗号システムの第２秘密鍵及び第２公開鍵を含む第２秘密／公開鍵ペアの前記第２秘密鍵を有し、第１デジタル署名は第３秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第１データを含むインプットを有し、第２デジタル署名は、前記第３秘密鍵により署名され、前記第２デジタル署名は、前記第２公開鍵に関連する第２データを含むインプットを有し、
前記方法は、
前記第１参加者により、前記第１秘密鍵及び前記第２公開鍵により、共通シークレットを決定するステップであって、前記共通シークレットは、前記第２秘密鍵及び前記第１公開鍵によっても決定できる、ステップと、
前記第１参加者により、前記第１公開鍵及び前記共通シークレットに基づき、前記暗号システムの少なくとも１つの更なる公開鍵を決定するステップと、
方法が提供され得る。

暗号システムの少なくとも１つの秘密鍵を生成する方法であって、第１デジタル署名は、第２秘密鍵により署名され、前記第１デジタル署名は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１公開鍵に関連する第１データを含むインプットを有し、
前記方法は、
前記第１秘密鍵及び決定性秘密鍵に基づき、前記暗号システムの少なくとも１つの第３秘密鍵を生成するステップ、を含む方法が提供され得る。

プロセッサと、プロセッサによる実行の結果として、システムに本願明細書に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、を含むシステムが提供され得る。

実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、本願明細書に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体が提供され得る。

本開示による種々の実施形態は、図面を参照して説明される。
デジタル証明書のデータ構造の図である。 デジタル証明書を発行するための処理を示す。 デジタル証明書を発行する際の信頼のチェーンを示す。 複数のルート認証局の間の公開鍵基盤（PKI）のマッピングを示す。 階層決定論的（hierarchical deterministic (HD)）ウォレットにおける決定性鍵の木のような構造の図である。 ブロックチェーン上のデジタル証明書の記憶を示す。 ブロックチェーンに格納されたデジタル証明書のデータ構造を示す。 デジタル証明書を含むブロックチェーントランザクションを示す。 図８のブロックチェーントランザクションの更新バージョンを示す。 図９のデジタル証明書のタイムロックバージョンを示す。 秘密鍵の知識のゼロ知識証明を示す。 認証済みHDウォレットのための秘密鍵の導出を示す。 認証済みデータを格納するためのブロックチェーン上のトランザクションのチェーンの使用を示す。 図１３の構成を含むルートトランザクションを示す。 図１３の構成の中間トランザクションを示す。 オフチェーンに格納されたデジタル証明書及びブロックチェーンに格納されたデジタル証明書のフィールドの比較を示す。 サービスプロバイダのためのデジタル証明書を生成し及び参照する処理を示す。 種々の実施形態が実装できるコンピューティング環境を示す概略図である。

＜オンチェーンのデジタル証明書＞
＜CA階層構造＞
図１に示すフォーマットの標準的なデジタル証明書は、ブロックチェーンに埋め込むことができる。ここで、図６に示される簡略化された２ティアCA階層構造が想定される。ここで、ルートCA３０と、単一の管轄を表すポリシCA３２のような１つの下位CAとが存在する。ポリシCA３２は、複数の発行CAの公開鍵に署名して、図３による信頼のチェーンを形成する。発行CA３４は、異なるユーザ及び装置と相互作用し、自身の親CAの代わりにデジタル証明書３６を発行する。以下の章では、ユーザの公開鍵のCAへの登録、結果として生じるデジタル証明書の発行を説明する。証明書の検証、更新、及び失効も検討される。

＜デジタル証明書＞
＜デジタル証明書のフォーマット＞
ブロックチェーンデジタル証明書プロトコルでは、証明書メタデータは、証明書発行者により署名されたトランザクションのOP_RETURN（証明可能な状態で使用不可能である）アウトプットに含まれる。証明書データ構造は、図１に示されるX.５０９標準と同じ、又は冗長データ（つまり、ブロックチェーンプラットフォームに本来既に存在するデータ）を除去するよう変更されてよい。

図７は、例示的なブロックチェーンデジタル証明書を示す。提案のデータ構造は、X.５０９と同様である画、幾つかの留意すべき相違点を有する。新しいデータ構造の重要性は、それが、ブロックチェーンプラットフォームの中で現実世界のアイデンティティを表すための新たな標準を確立する手段であることである。

OP_RETURNペイロード内の最初の４バイトは、デジタル証明書識別プレフィックスである。ブロックチェーンを監視している装置は、証明書データを検索するとき、そのプレフィックスをクエリする。プレフィックスの例は以下を含む：
BDC:０x４２４４４３０a
CER:０x４３４５５２０a
BCT:０x４２４３５４０a
ここで、３文字の略語は、ASCIIを用いて１６進数に変換される。

３２バイトのユニークなIDが、証明書に割り当てられる。これは、残りの証明書データの連結をハッシングすることにより生成される。

証明書データは、チェーン上のCAを識別する３つのフィールドにより開始する。これらのフィールドは、CAの発行する中間及びルート証明書へのポインタを含む。これらの更なる詳細は後述される。

次の２つのフィールドは、証明書有効期間を符号化する。

続く４個のフィールドは、証明書サブジェクトデータを符号化し、「現実世界の」名称、装置、及び発行CAにより使用されるサブジェクト識別子（任意）を含む。

最後の２つのフィールドは、証明書に含まれる追加の不特定メタデータを許容する（任意）。

留意すべきことに、X.５０９標準に存在する「署名（Signature）」及び「署名アルゴリズム識別子（Signature algorithm identifier）」フィールドは、ブロックチェーン証明書には明らかに含まれない。これは、（ECDSAに基づく）署名フィールドがトランザクションインプットに既に存在するからである。この冗長な情報を除去することは、チェーン上のデータ記憶効率を向上する。

全体では、ブロックチェーンデジタル証明書は、３５２～１４０８バイトのOP_RETURN空間を必要とする。

＜登録及び発行＞
AliceがCSRをオフチェーンで商業的CAに提出すると仮定する。続いて、CAの代わりに動作するRAは、Aliceのアイデンティティについて必要なチェックを実行する。この情報が検証され、発行CAへと通信されると、後者は、以下の設定（Setup）アルゴリズムに従い、オンチェーントランザクションを設定することにより、応答する。

Setup
Aliceが、デジタル署名方式のための彼女の公開鍵PK_AをCAにより認証させたいとする。

PK_Aの証明書はTxID_CTX-PKAである。

所謂、証明書トランザクション（certificate transaction (CTX)）は、図８に示される。図８は、公開鍵を認証するためにCAにより生成されたトランザクションID、つまりTxID_CTX-PKAを有するCTXを示す。トランザクションへのインプットは、発行CA（Issuing CA）のUTXOを含み、これによりオンチェーンのCAへのリンクを生成する。第１アウトプットは、発行CAにより選択された独立公開鍵へのP２PKH(pay to public key hash)である。このアウトプットは、CTXがUTXOセットの中に現れることを保証し、Aliceの公開鍵の直接的な有効性チェックを可能にする（検証に関連して後述される）。

Setupアルゴリズムの中の第２アウトプットは、Aliceの公開鍵、及び彼女のCAが署名した公開鍵を、両方ともOP_RETURNの証明可能な状態の使用不可能アウトプット内に含む。ここで、アルゴリズムは、トランザクションの第２アウトプット内にデジタル証明書全体を含むよう変更される。証明書は、OP_RETURNのアウトプットの中に、標準化され認識されたフォーマットで、CAの署名と一緒に、Aliceの公開鍵情報を含む。図８のCTXがマイニングされた後に、CAは、Aliceに、Aliceの証明書が埋め込まれたトランザクションID、つまりTxID_CTX-PKAを発行する。Aliceは、後に、彼女のアイデンティティをオンチェーンで検証したいと望む任意の信頼するパーティを、この証明書トランザクションIDへ向けることができる。

ブロックチェーンデジタル証明書内の公開鍵PK_Aは、ハッシュ関数により難読化される。これは、オンチェーンのプライバシを提供するのに非常に役立つが、依然として、オフチェーンで公開鍵を知る者は誰でも、それをハッシュダイジェストにリンクできる。これは、ブロックチェーンデジタル証明書が、標準的なデジタル証明書より柔軟であることも許容する。

＜検証＞
Aliceのデジタル署名は、彼女の認証済み公開鍵を通じて検証できる。検証処理の第１部分は、以下の検証（Verification）アルゴリズムを採用し、それにより、トランザクションIDがUTXOセットの中に存在することをチェックすることにより、初期有効性チェックが実行される。

Verification
Aliceからのデジタル署名を検証するために、ユーザは、彼女の公開鍵を先ず検証する必要がある。

第２アウトプット内で提供された情報がAliceの公開鍵を認証することを検証するために、Verificationアルゴリズムは、X.５０９証明書内のコンテンツを検証するよう拡張される必要がある。更新されたアルゴリズムは以下の通りである：

ブロックチェーンプラットフォーム上のトランザクションは、基礎にある楕円曲線暗号システムを用いて、それらの生成者により署名される。CTXは、CAの秘密鍵によりデジタル方式で署名される。これは、X.５０９証明書の最終エントリ（CAの署名）を冗長にする。同様に、デジタル証明書をブロックチェーントランザクションに埋め込むことは、全部のトランザクションがECDSAを用いて署名されるので、X.５０９標準における署名アルゴリズム識別子のフィールドを無価値にする。従って、デジタル証明書に埋め込まれたデータは、ブロックチェーンプラットフォームに固有の暗号法の情報を用いて最適化できる。

＜更新及び取り消し＞
デジタル証明書は、更新及び取り消し（Revocation及びUpdate）のための以下の処理に従い、書き換えられ、取り消されることができる。

Revocation
Aliceの公開鍵を取り消すために、CAは、PK_Aを参照するCTXの第１アウトプットを使用する。これが、検証処理のステップ２を失敗させるからである。

Update
公開鍵が更新される必要があるシナリオがある。例えば、Aliceは彼女の秘密鍵を紛失してしまう、又は彼女の秘密鍵が損傷してしまう。

Aliceが新しい公開鍵PK_A-newをCAに提出し、CAが、Aliceは実際に彼女が主張している人であると確信することを想定する。

取り消しのために、CAは、CTXの第１アウトプットを単に使用するだけでよく、その結果、検証アルゴリズムのステップ２が失敗する。デジタル証明書を更新するために、以下の図９に示されるように、トランザクションインプットを用いて前のCTX IDにリンクする新しいCTXが生成され得る。図９は、更新された公開鍵PK_A-new(x-y=Tx手数料)を認証するために、CAにより生成されたトランザクションID、つまりTxID_CTX-PKA-newを有するCTXを示す。留意すべきことに、CA、ユーザ、又は複数パーティの取り消し方式に依存して取り消しメカニズムを調整することが望ましい、異なる使用例がある。

＜証明書満了（時限鍵）＞
各デジタル証明書は、図１及び７のデータ構造に示されるように、その有効期間に関する情報を含む。この情報を抽出することにより、証明書トランザクション（CTX）アウトプットのロックスクリプトに、変数として、時間が追加できる。それにより、擬似的に自律的な証明書満了／更新を組み込むようスクリプトの機能を拡張する。

OP_CHECKLOCKTIMEVERIFY (CLTV)を用いて、デジタル証明書を含むCTXは、特定の時間にトランザクションを使用することにより、期限切れにされることができる。時間は、UNIX（登録商標）、又は将来できにブロック高に同期されることができる。これは、任意の時間同期された装置が、「時限」鍵により検証され／無効化されることができることを意味する。

ユーザがCSRを商業的CAに提出するとき、彼らは、特定時間まで有効のままであるために、証明書の関連支払いを転送する。（nLockTime又はCLTVを用いて）スクリプト内のこの情報を符号化することにより、署名済みCTXは、特定の時間量が経過するまで、UTXOセットから除去できない（使用できない）。

＜オンチェーン方法＞
図１０は、以下に概説される方法を伴うCTXを示す。トランザクションは、更新された公開鍵PK_A-new(x-y=Tx手数料)を認証するためにCAにより生成されたトランザクションID、つまりTxID_CTX-PKA-newを有する。UTXO登録は、UTXOが特定の満了日まで使用できないことを保証するCLTVオペコードを含む。

ステップ１：証明書発行者は、証明書トランザクションCTXを生成する。満了日は、データ<expiry time>を用いて第１アウトプット（UTXO registration output）へと符号化される。
ステップ２：発行されると、デジタル証明書は、満了日に達しUTXOが使用可能になるまで、有効である。
ステップ３：<expiry time>が経過すると、PK_CA ^Issueは、UTXOを使用可能になり、それにより証明書を取り消す。

留意すべきことに、この方法は、依然として、取り消しを保証するために、証明書発行者PK_CA ^Issueによる能動的参加を必要とする。

＜認証済みウォレット＞
ウォレットは、鍵／アドレスの集合である。標準的なブロックチェーンユーザは、通常、彼らのアドレスを更新して、彼らの全部の資金が１つの場所に置かれないように、及び彼らの秘密鍵がトランザクション署名を生成するために繰り返し使用されないようにする。大部分の（セキュアな）ウォレットソフトウェア実装は、ユーザからの入力無しに、使い捨て鍵のシーケンスを自動的に生成する。このアプリケーションレイヤ制約の倍には、エンドユーザが日毎に要求し得る全ての単一の鍵に署名することをCAに要求するのは現実的ではない。

代わりに、トランザクションで直接使用されるのではなく、代わりにウォレットアドレスの派生パスで使用される公開鍵のために、証明書を発行することにより、ウォレット全体に対して単一のデジタル証明書が発行され得る。

＜階層構造の鍵＞
これまで、ブロックチェーン上位の個々の鍵ペアを認証するために、デジタル証明書の実装が説明された。セキュリティの理由から、ユーザの資金に損害を与えるのを防ぐために、鍵を周期的に更新し及びリフレッシュすることが強く推奨される。ブロックチェーンユーザが彼らの鍵を管理し及び更新する一般的な方法は、HDウォレット（上述した）内の階層構造の鍵の使用を通じる。PKIの階層構造とHDウォレットの階層構造との間の違いを強調することが重要である。前者は（Root CA鍵から開始して）デジタル署名された鍵を通じて確立され、後者は、（マスタ鍵から開始して）階層構造の鍵の決定論的生成を通じて生成される。

２つのパーティ間で鍵を共有するとき、国際特許出願公開WO２０１７/１４５０１６に記載されたシークレット値分配技術の使用が追加で検討されてよい。この方法は、（関連する２つのパーティにのみ知られている）シークレットであり元の共有シークレットからシークレットを生成する効率的な方法である共有鍵の階層構造を設定するかを記載する。ここでも、PKIでの階層構造と、元の共有シークレットのシーケンシャルハッシュから生成されるシークレット鍵の階層構造との間の違いが強調される。

これらの微妙な違いが与えられると、異なる技術は、同じ作業量で階層構造の鍵のシステムにいて親（マスタ又はRoot）鍵の所望の特徴を推定するために結合されることができる。例えば、HDウォレットは、ECDSA鍵ペアの準同型特性をオンチェーンで利用する。この特性は、全部の子／孫鍵の証明書をHDウォレット内の認証済みマスタ鍵から推定することにより、更に利用されることができる。これは、共有シークレット鍵の階層構造へと拡張することもできる。階層構造の鍵のこの暗示的品質は、認証済みウォレットの概念を導入することにより以下に説明される。

＜決定論に基づく鍵更新＞
Method:
Aliceは決定論的ウォレットを所有するとする。彼女は公開鍵P_CA ^AをCAに登録する。P_CA ^Aを登録し及びデジタル証明書を発行する方法が、以下に説明される。Aliceは、P_CA ^Aを自由にブロードキャストしてよい。彼女は、P_CA ^Aを用いる署名を決して生成しない。

決定論的ウォレット設計を用いて、彼女は子鍵を生成する。

P_A１=P_CA ^A+P_１'
P_A２=P_CA ^A+P_２'
．．．
ここで、P_１',P_２',…は、Aliceにのみ知られているシードに基づく決定性鍵である。秘密鍵は、関連するsk_A１=sk_CA ^A+sk_１’でもある。

Aliceは、トランザクションに署名することにより、P_A１,P_A２,…を用いて支払いを行う。彼女は、公開鍵あたり１つの署名のみを使用している。

誰かがAliceの鍵にチャレンジ（challenge）する場合、彼女は、P_A１=P_CA ^A+P_１'であること、及び署名SigP_１’を提供することにより彼女がP_１'=S_１'・Gの秘密鍵を知っていることを証明することができる。これは、P_A１.により署名されたものと異なるメッセージでなければならないことに留意する。

P_A１及びP_１’の２つの署名は、AliceがP_CA ^Aに対応する秘密鍵を知っていることを証明する。

Features:
Aliceは、１つの公開鍵がCAにより認証されることを要求するだけである。全ての他の鍵は、証明可能な状態でリンクできる。

P_CA ^Aは、ネットワークに自由にブロードキャストされ得る。それは、トランザクションに署名するために使用されない。

決定論的ウォレットの慣習は、本開示の実施形態として使用されている。しかしながら、本開示はそれに限定されない。P_A１=P_CA ^A+P_１’が必要なだけであり、ここで、P_１'=S_１'・G秘密鍵がAliceに知られる。

分解を使用して、P_A１=P_CA ^A+P_１’はスクリプト内で検証でき、興味深い支払い条件が可能になる。

＜認証済み鍵更新＞
上述の決定論に基づく鍵更新を提供する方法は、HDウォレットに拡張できる。決定論的に導出された鍵の基本セットとしてP_１',P_２',…を使用する代わりに、基本セットは、例えばBIP００３２プロトコルを用いて導出されたウォレットである。ウォレットを認証する方法は、単に、HDウォレットにより生成された全ての鍵に認証済み公開鍵を追加することである。

＜HDウォレット＞
ユーザは、先ず、シードS、通常は１２ワードのフレーズを選択する。マスタノード（又はマスタ秘密鍵）は、次に、１～５００００ラウンドの間のHMAC-SHA５１２を用いてシードから導出される。マスタ鍵から、全てのウォレットアドレスが生成される。

ここで、iはアカウント番号を表し、jは鍵番号を表し、HはSHA２５６ハッシュ関数である（鍵導出方法の詳細については、[https://github.com/bitcoin/bips/blob/master/bip-００３２.mediawiki]を参照する）。対応する公開鍵は、秘密鍵をsecp２５６k１生成元（generator）により乗算することにより、計算される。

＜認証済みHDウォレット＞
ウォレットを認証するために、ユーザは、ウォレット内の全ての鍵にsk_CAを追加するだけでよい。新しい認証済み鍵は、以下の形式である。

対応する公開鍵により、

図１２は、認証済みHDウォレットの導出パスを示す。認証済み鍵の所有権を証明するために、HDウォレットのユーザは、上述の決定論に基づく鍵更新処理におけるステップ４に従うことができ、対応するP_i及びP_i’からのメッセージに署名する。或いは、代替として、ゼロ知識署名プロトコルは、上述の通りであることができる。

＜分析＞
この方法は、認証済みウォレットからの鍵を、デジタル証明書を発行した公開鍵に暗号的にリンクさせることを可能にする。この方法の鍵の特徴は以下の通りである。
認証済み鍵は保護される。
CAに対する要件は最小限である。
更に、ウォレット全体を認証することがウォレット秘密鍵に定数を追加するだけでよいので、エンドユーザに対する要件も最小限である。結果として、導出パスは、従って、基本的に変更されず、更なるセキュリティ考察が必要である。

＜認証済み支払いチャネル＞
デジタル証明書はKYCを有効にするために重要であるが、それらは、認証済みパーティのプライバシを低下させる望ましくない効果を有し得る。例えば、誰かの現実のアイデンティティを公開鍵にリンクするオンチェーンデジタル証明書は、その人の経済的活動を誰でも監視できるようにする。幾つかの場合には、取引するパーティは、最初にデジタル証明書の発行を通じて、信頼を確立したいと望み得る。しかし、信頼が確立されると、公衆から彼らのアドレスを難読化することができない。認証済み支払いチャネルは、セキュア且つプライベートな方法でエンティティのペアが取引することを可能にすることにより、この問題を解決する。

＜Setup＞
AliceとBobは、有効デジタル証明書を呼ばれる鍵を有しなければならない。これらは、P_CA ^A及びP_CA ^Bと呼ばれる。デジタル証明書が要求され、その結果、Alice及びBobは、支払いチャネルを生成する前に、それぞれ他方の現実世界アイデンティティを検証することが可能である。デジタル証明書の発行及びリスレッシュのための正確なメカニズムが、以上に説明された。

＜オンチェーン方法＞
ステップ１：Alice及びBobは、楕円曲線Diffie Hellmanを用いて共有シークレットを生成する。
ステップ１a:Aliceは、彼女のシークレット鍵をBobの公開鍵で乗算する。

ステップ１b：Bobは、彼のシークレット鍵をAliceの公開鍵で乗算する。

以下が分かる：

ステップ１c：共有シークレットは、一緒に導出された楕円曲線点のz座標である。

Sは、Aliceの秘密鍵（sk_CA ^A）及びBobの公開鍵（P_CA ^B）の両方、又はその逆を知っている者だけにより導出可能である。
ステップ２：共有シークレットは、シークレット鍵のハッシュチェーンを生成するために使用される。

これは、共有シークレットシードを用いる決定性鍵生成パスの単なる一例である。国際特許出願公開WO２０１７/１４５０１６に記載されているような他の方法が使用可能である。留意すべきことに、実際には、決定論的ウォレットは、HMAC（hash-based message authentication codes）を使用して、秘密鍵を生成する。本開示の目的のために、HMAC()及びH()は同義的であり、鍵を生成するために使用される正確な関数は実装の詳細であると考えられる。
ステップ３：更新公開鍵は、N番目のシークレット鍵から開始して生成される。

留意すべきことに、更新鍵は、追加のセキュリティのために、s_Nから開始しs_１で終了するよう、逆方向に導出される。
ステップ４：Alice及びBobの両者は、これらの更新鍵を用いてインデックス付きアドレスのシーケンスを生成する。

Alice及びBobは、今や、支払いを送信及び受信すべきインデックス付き公開鍵アドレスのシーケンスを有する。鍵は共有シークレットを用いて導出されるので、支払いチャネルの中のアドレスは、Alice及びBobにのみ知られ、彼らがセキュアな支払いチャネルを確立することを可能にし、それによりプライバシを保証する。

＜分析＞
認証済み支払いチャネル（Certified Payment Channel）アルゴリズムは、シークレット共有及び決定性鍵更新を結合し、及びそのセキュリティモデルはECC及びハッシュ関数の両方に依存する。攻撃者が単一の更新鍵（P_kに対するs_k）を決定できたとしても、彼らはs_k+１又はP_k+１を決定できない。

この方法の例示的な使用例は、ケーブルテレビサービスのようなpay-as-you-goストリーミングサービスであり、それにより支払いチャネルが加入者と供給者との間に確立される。初期の信頼を確立するために、サービスユーザは、支払いアドレスが実際にサービスプロバイダに属することを確かめなければならない。逆に、サービスプロバイダは、支払いを各顧客IDにリンクできる必要がある。セキュリティ及び柔軟性の両方の目的のために、認証済み支払いチャネルアルゴリズムは、プロバイダ及びユーザの両者のために複数の鍵を生成し、彼らのトランザクション情報を保証し、一方で、オンチェーンで第三者から難読化されたままにする。

＜認証済み鍵の証明（attesting）＞
＜デジタル署名＞
認証済み鍵の所有権は、２つのデジタル署名、つまりP_１'について１つ及びP_１について１つ(P_A１=P_CA ^A+P'_１)を提供することにより、容易に実証できる。例えば、Carolは、Aliceが認証済み公開鍵P_CA ^Aの所有者であることを検証したいと望む。しかしながら、Aliceは、sk_CA ^Aによりメッセージに直接署名することを望まない。彼女は、以下のアルゴリズムを使用できる。
ステップ１：Carolは、AliceへメッセージMを送信する。これは、ランダムに生成されたビット列であってよい。
ステップ２：Aliceは、メッセージMに対して２つの署名により応答する。

ここで、Sig_P１'(M)はP_１’について有効であり、Sig_PA１(M)はP_A１.について有効である。署名が有効である場合、これは、Aliceがsk_A１及びsk_１’を知っていることを証明する。
ステップ３：Carolは、以下を検証できる。

Carolは、従って、Aliceがsk_CA ^Aを知っていると推定できる。

＜jハッシュプレイメージ＞
sk_CA ^Aの知識を提供するためのより効率的な方法は、P_A１のための１つの署名、及びP_１’に対する秘密鍵を生成するハッシュプレイメージを提供することである。以下に留意すべきである。

ここで、Nは、支払いチャネル／ウォレット内の鍵の数である。

＜アルゴリズム（鍵証明（key attestation）方法２）＞
ステップ１：Carolは、AliceへメッセージMを送信する。これは、ランダムに生成されたビット列であってよい。
ステップ２：Aliceは、H^N-１(S)及び以下の署名を送信することにより応答する：

３つの情報ピースの全部が、Aliceはsk_A１,sk_１’及びk_２’を知っていることを証明する。
ステップ３：Carolは、以下を検証できる。

そして、以下を推定する：

Carolは、従って、Aliceがsk_CA ^Aを知っていると推定できる。

留意すべきことに、この方法は、前の方法より、P_１’について多くの秘密情報を開示するので、暗号法上あまりセキュアではない。しかしながら、それは、Carolにとってより効率的な検証を可能にする。効率の向上は、Carolが決定性鍵のチェーンを決定でき、それに依存してハッシュプレイメージが提供され、それにより多数の署名を検証可能にするという点で生じる。

＜ゼロ知識証明＞
S_１’の知識を証明するために署名を提供する代わりとして（及び密接な関係P_CA ^Aにより）、Aliceは、彼女が秘密鍵S_１’を知っていることのゼロ知識証明を提供できる。P_１'=S_１'・GとなるようなS_１’の知識を証明するための（AliceとBobとの間の）ゼロ知識プロトコルは、以下の通りである。

＜アルゴリズム（鍵証明（key attestation）方法３）＞
Setup:
システムの公衆に知られた共有パラメータは：E(group),n(order),G(ECgeneratorpoint)である。

Method:

ステップ１～５は、図１１に示される。図１１では、太字で強調表示された全ての値は秘密に保たれ、全ての下線を付された値は開示され／公開される。

検証の完全性（Completeness of verification）：
r及びcが与えられると、ステップ５の式のLHSがRHSに等しいことがチェックできる。

有限体楕円曲線の代数学上の特性により、秘密鍵をセキュアにマスクし、及び依然として楕円曲線演算を用いて所有権を証明することが容易である。しかしながら、S_１’についてのゼロ知識証明の更なる重要な特徴は、ランダムチャレンジの発行者（Bob）のみが署名により確信できることである。

この理由は、W,c及びrが生成される／受信される順序（W→c→r）が証明自体の部分であることである。言い換えると、ランダムなr∈Z_n及びc∈Z_nを選択すること、従って、検証式（ステップ５）が真であるとして検証されるよう、Wを計算することが容易である。結果として、Bobは、Aliceにより生成されたデータを取り入れ、AliceがS_１’を知っていると他の誰かを確信させることができない。これは、メッセージに対する単一の署名が複数の検証者に署名者が秘密鍵を所有していると確信させることができるデジタル署名と異なる。

＜拡張＞
＜オンチェーンのPKI＞
ブロックチェーンは、CA鍵及びルート証明書を公開登録するために使用できる。現在３つの主要なPKI標準が、ブロックチェーンアーキテクチャに固有のトランザクションインプット及びアウトプットを用いてブロックチェーン上で容易に複製できる。

＜オンチェーンのCA PKI＞
この方法では、CAは、複数の秘密／公開鍵ペアを生成できるウォレットを有すると仮定される。デジタル証明書を発行するためのPKIは、３つの鍵を必要とする：

CAは、ブロックチェーントランザクションを用いて、これらの３つの鍵を階層構造にリンクできる。

図１３～１５は、ブロックチェーン上のトランザクションを用いる方法を示し、P_CA ^Root,P_CA ^S及びP_CA ^Issueの間のリンクを説明する。ルート鍵を含むトランザクションは、OP_RETURN内に又はScriptPubKey自体の中にルート証明書を含まなければならない（OP_PUSHDATAx <Certificate byte size> <Certificate> OP_DROP）。ルート証明書は自己署名されるので、それは、ブロックチェーンの独立に検証可能なデータ、つまり、ルート公開鍵を見付けることができるCAのウェブサイトを含まなければならない。

Registration:
ステップ１：CAは、図１４に示されるように、P_CA ^Rootにより署名された１つのインプット及び３つのアウトプットを有するトランザクションTx１を生成する。１つのアウトプットは、P_CA ^Rootにより使用でき、取り消しツールを提供する。第２アウトプットは、下位鍵P_CA ^Subを含むP２PK(Pay-to-public-key)である。留意すべきことに、これは、下位鍵に署名することと等価である。第３アウトプットは、ルート証明書のシリアル化形式を含むOP_RETURNである。

ステップ２：P_CA ^Subを登録するために、CAは、図１５に示されるように、Tx１からの第２アウトプットを使用する、P_CA ^Subにより署名された１つのインプットを有するトランザクションTx２を生成する。Tx２は３つのアウトプットを有する。第１アウトプットは、P_CA ^Subにより使用でき、取り消しツールを提供する。第２アウトプットは、下位鍵P_CA ^Issueを含むP２PK(Pay-to-public-key)である。留意すべきことに、これは、発行鍵に署名することと等価であり、証明可能な状態で発行鍵をルート鍵にリンクする。第３アウトプットは、中間鍵登録証明書のシリアル化形式を含むOP_RETURNである。

ステップ３：最終ステップとして、CAは、Tx３を生成することにより、P_CA ^Issueを登録する。Tx３は、図１３に示されるように、Tx２からの第２アウトプットを使用する、P_CA ^Issueにより署名された１つのインプットを有する。Tx３は２つのアウトプットを有する。第１アウトプットは、鍵取り消しの場合に、P_CA ^Issueにより使用できる。第２アウトプットは、CAデータを含む発行鍵登録証明書のシリアル化形式を含むOP_RETURNである。

ステップ４：３つの全部のトランザクションが、ブロックチェーン上に発行される。対応する未使用アウトプットは、UTXOセット内で見付けることができる。トランザクションは、一緒に、ブロックチェーンのPKI信頼チェーンを形成する。

ルート証明書メタデータは、Tx１noOP_RETURNに含まれる。Tx全体（OP_RETURNデータを含む）は、ルート鍵により署名される。中間証明書メタデータは、Tx２のOP_RETURNに含まれ、下位鍵により署名される。

Verification:
デジタル証明書による認可を要求する任意の後続のトランザクションについて、登録の証明は、UTXOセットの中の３つのアウトポイントへの１０８バイトの参照になる。この参照から、誰もが、P_CA ^Issueを（ブロックチェーンを介して）P_CA ^Root及びルート証明書にリンクするパスを構成できる。これはまた、信頼できるCAに関連付けられる。

ステップ１：検証者は、各トランザクション（Tx１～３）からのアウトプット（Output)１がUTXOセット内にあることをチェックする。３つのアウトポイントの何れかが存在しない場合、検証は失敗する。
ステップ２：検証者は次に、Tx１～３の完全なトランザクションデータを要求し、チェックする。
Tx３のインプットは、Tx２からのアウトプット２を使用する。
Tx２のインプットは、Tx１からのアウトプット２を使用する。
ステップ３：検証者は次に、Tx１のOP_RETURN内のデータをパースして、ルート証明書を調べる（デジタル証明書を１６進データに符号化するための実際の方法はここに記載されないが、多くの方法が存在する）。

ルート証明書は、信頼の基礎を形成し、何からのオフブロックメカニズムにより信頼できるようにされる。CAに関する情報は、非ブロックチェーンに関連するセキュリティデータと一緒に、ここに含まれるべきである。

Revocation:
PKI階層構造内の任意の鍵を取り消すために、CAは、単に、その鍵により署名されたトランザクションからのアウトプット１を使用するだけでよい。これは、UTXOセットからの登録の証拠を含むトランザクションへの任意の参照を除去し、従って、UTXOセットを検索することにより鍵の検証が子パイする。

留意すべきことに、階層構造内の任意の鍵の取り消しは、更に下にある全部の鍵の取り消しをもたらす。これは、UTXOセットからの任意の登録Tx参照の除去が、その鍵からルート鍵及びルート証明書へのリンクを破壊するからである。

＜分析＞
UTXOメンバとOP_RETURNアウトプットとブロックチェーントランザクションの署名とを結合することは、鍵／証明書階層構造をブロックチェーン上にマッピングするセキュア且つ安価な方法を提供する。図１６は、CA信頼チェーンの中の証明書の鍵フィールドのリスト、及びブロックチェーンPKIにおけるTｘ内の同様のものを示す。図１３は、ブロックチェーンPKIにおける信頼のチェーンを示す。

＜使用例＞
＜専用SPV（simplified payment verification）ノード＞
ユーザがウォレットを「現実世界の」アイデンティティデータにリンクすることを可能にすることは、デジタルアセットと引き換えに差－ビスを提供できる専用SPVノードを確立する可能性を開く。トークン化（Tokenized）プロトコルは、例えば、ブロックチェーントランザクションの形式で要求を処理し応答を発行する専用ノードソフトウェアを有するが、その主なタスクはトークンアセットの自動管理である。

専用SPVノードは、デジタル署名及び自身のCTXへの参照を提供することにより、任意の相互作用の始めに、自身を顧客に容易に識別させることができる。結果として、顧客は、このノードにより使用される公開鍵の信頼性を常に独立に検証できる。これは、特に、相互作用が高価な移転を要求する、又は専用ノードへ送信される情報が機密である場合、重要である。

例えば、サービスプロバイダ（Sam）は、彼自身を顧客（Carol）に識別可能にしたいと望む。方法の高レベルの説明は以下の通りである。

＜サービスプロバイダのアイデンティティ検証＞
ステップ１：発行CAは、Samを彼の公開鍵にリンクするCTXを生成する。この証明書は、Samのアイデンティティデータを、認証局PKI階層構造への参照と共に含む。証明書発行者が信頼できる第三者であり、誰でも発行者のルート証明書を認証できると仮定する。
ステップ２：Carolは、彼に任意の（ランダムな）メッセージを送信することにより、Samとの相互作用を開始する。
ステップ３：彼ら自身を識別するために、サービスプロバイダは、CTXを参照する３２バイトTXIDと一緒に、Carolにより送信されたメッセージのためのECDSA署名を提供する。
ステップ４：Carolは、CTXを検索すること及びデジタル証明書の中の公開鍵を用いて署名をチェックすることにより、Samのアイデンティティを検証できる。

方法は、以下の図１７に示される。

図１８を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の図示のシステムのうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、データサーバ、ウェブサーバ、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置として使用するために構成されてよい。図１８に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ＲＯＭ）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。

プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。

バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。

ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。

ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。

１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイサブシステム、プリンタ、又は音声出力装置のような非視覚ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。

記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、ＣＤ－ＲＯＭ、又はＤＶＤ、又はＢｌｕｅ－Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。

コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。さらに、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。従って、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図１８に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図１８に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。

上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素又はステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、そのような要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化されてよい。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。

＜列挙される例示的な実施形態＞
本開示の実施形態の例は、以下の項の観点で記載できる。
（項１）ブロックチェーンに認証済みデータを格納する方法であって、前記方法は、
第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションの第１アウトプットは、暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データを含み、前記第１ブロックチェーントランザクションは、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名された第１デジタル署名を含み、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
前記第１ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
を含む方法。
（項２）少なくとも１つの第２ブロックチェーントランザクションを生成するステップであって、前記第２ブロックチェーントランザクションの第１アウトプットは、暗号システムの第３秘密鍵と第３公開鍵とを含む第３秘密／公開鍵ペアの第３公開鍵に基づく第３データを含み、前記第２ブロックチェーントランザクションは、暗号システムの第４秘密鍵と第４公開鍵とを含む第４秘密／公開鍵ペアの第４秘密鍵により署名された第２デジタル署名を含み、前記第２デジタル署名は、前記第３公開鍵に関連する第４データを含むインプットを有する、ステップと、
前記第２ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
を更に含む項１に記載の方法。
（項３）前記第２ブロックチェーントランザクションの前記第１アウトプットは、前記第３データ、前記第４データ、及び前記第２デジタル署名を含み、前記第２デジタル署名は、前記第３データを含むインプットを有する、項２に記載の方法。
（項４）前記第２ブロックチェーントランザクションのインプットは、前記第１ブロックチェーントランザクションのアウトプットに対応する、項２又は３に記載の方法。
（項５）前記第２ブロックチェーントランザクションの前記インプットは、前記第２秘密鍵により署名されたデジタル署名を含む、項４に記載の方法。
（項６）前記第４データは、前記第２ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第３公開鍵に関連するデータに、一方向関数を適用することにより導出される、項２～５のいずれか一項に記載の方法。
（項７）前記第２ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第４公開鍵と異なる、項２～６のいずれか一項に記載の方法。
（項８）前記第３公開／秘密鍵ペア及び決定性秘密／公開鍵ペアから、少なくとも１つの更なる公開／秘密鍵ペアを生成するステップ、を更に含む項２～７のいずれか一項に記載の方法。
（項９）前記第２ブロックチェーントランザクションの第３アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能である、項２～８のいずれか一項に記載の方法。
（項１０）前記第２ブロックチェーントランザクションの前記第３アウトプットはタイムロックされる、項９に記載の方法。
（項１１）前記第１公開鍵及び前記第４公開鍵は、同じ公開鍵である、項２～１０のいずれか一項に記載の方法。
（項１２）前記第２公開鍵及び前記第４公開鍵は、同じ公開鍵である、項２～１０のいずれか一項に記載の方法。
（項１３）前記第３データは、前記第３公開鍵を含むデータに、一方向関数を適用することにより導出される、項２～１２のいずれか一項に記載の方法。
（項１４）前記第１データは、前記第１公開鍵を含むデータに、一方向関数を適用することにより導出される、項１～１３のいずれか一項に記載の方法。
（項１５）更新された第１ブロックチェーントランザクションを生成するステップであって、前記更新された第１ブロックチェーントランザクションの第１アウトプットは、更新された第１公開鍵に基づく更新された第１データを含み、前記更新された第１ブロックチェーントランザクションは、前記第２秘密鍵により署名された更新された第１デジタル署名を含み、前記更新された第１デジタル署名は、前記更新された第１公開鍵に関連する更新された第２データを含むインプットを有する、ステップと、
前記更新された第１ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
を更に含む項１～１４のいずれか一項に記載の方法。
（項１６）前記更新された第１ブロックチェーントランザクションの前記第１アウトプットは、前記更新された第１データ、前記更新された第２データ、及び前記更新された第１デジタル署名を含み、前記更新された第１デジタル署名は、前記更新された第２データを含むインプットを有する、項１５に記載の方法。
（項１７）前記第１ブロックチェーントランザクションの前記第１アウトプットは、前記第１データ、前記第２データ、及び前記第１デジタル署名を含み、前記第１デジタル署名は、前記第２データを含むインプットを有する、項１～１６のいずれか一項に記載の方法。
（項１８）前記第２データは、前記第１ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第１公開鍵に関連するデータに、一方向関数を適用することにより導出される、項１～１７のいずれか一項に記載の方法。
（項１９）前記第１ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第２公開鍵と異なる、項１～１８のいずれか一項に記載の方法。
（項２０）少なくとも１つの前記第１アウトプットは、使用不可能アウトプットである、項１～１９のいずれか一項に記載の方法。
（項２１）前記第１ブロックチェーントランザクションの第１インプットは、前記第２秘密鍵により署名されたデジタル署名を含む、項１～２０のいずれか一項に記載の方法。
（項２２）前記第１ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能である、項１～２１のいずれか一項に記載の方法。
（項２３）前記第１ブロックチェーントランザクションの前記第２アウトプットはタイムロックされる、項２２に記載の方法。
（項２４）前記第１ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第２公開鍵と異なる、項１～２３のいずれか一項に記載の方法。
（項２５）前記第１公開／秘密鍵ペア及び決定性秘密／公開鍵ペアから、少なくとも１つの更なる公開／秘密鍵ペアを生成するステップ、を更に含む項１～２４のいずれか一項に記載の方法。
（項２６）少なくとも１つの前記更なる秘密鍵により及び前記対応する決定性秘密鍵により署名されたデジタル署名を提供するステップ、を更に含む項８又は２５に記載の方法。
（項２７）少なくとも１つの前記更なる秘密鍵により署名されたデジタル署名を提供するステップと、
前記対応する決定性秘密鍵に関連するデータを提供するステップと、
を更に含む項８又は２５のいずれか一項に記載の方法。
（項２８）前記対応する決定性秘密鍵は、前記対応する決定性秘密鍵に関連する前記データに、一方向関数を適用することにより導出される、項２７に記載の方法。
（項２９）検証者に、前記決定性鍵の暗号化バージョンに及び前記検証者により選択された値に基づき、前記決定性秘密鍵の知識の証明を提供するステップ、を更に含む項８又は項２５～２８のいずれか一項に記載の方法。
（項３０）第１パーティと第２パーティとの間で、前記第１パーティの秘密鍵及び前記第２パーティの公開鍵に基づくシークレット値を共有するステップであって、前記シークレットは、前記第１パーティの公開鍵及び前記第２パーティの秘密鍵からも決定できる、ステップ、を更に含む項１～２９のいずれか一項に記載の方法。
（項３１）データに一方向関数を繰り返し適用することにより、複数の決定性鍵を決定するステップ、を更に含む項１～３０のいずれか一項に記載の方法。
（項３２）更新されるべき秘密鍵は、前記更新された鍵への一方向関数の適用に基づく、項３１に記載の方法。
（項３３）前記第１ブロックチェーントランザクションの前記第１アウトプットは、オフチェーンのデータの位置を示す位置データを含む、項１～３２のいずれか一項に記載の方法。
（項３４）ブロックチェーンに格納された認証済みデータを検証する方法であって、前記方法は、
（ｉ）暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データと、（ｉｉ）ブロックチェーントランザクションに格納された第１デジタル署名と、を識別するステップであって、前記ブロックチェーントランザクションの第１アウトプットは前記第１データを含み、前記第１デジタル署名は、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
前記第２公開鍵により前記第１デジタル署名を検証するステップと、
を含む方法が提供され得る。
（項３５）前記ブロックチェーントランザクションの前記第１アウトプットは、前記第１データ、前記第２データ、及び前記第１デジタル署名を含み、前記第１デジタル署名は、前記第１データを含むインプットを有する、項３４に記載の方法。
（項３６）少なくとも１つの前記第１アウトプットは、使用不可能アウトプットであり、
前記方法は、
前記使用不可能アウトプットから、前記第１デジタル署名及び前記第１公開鍵を識別するステップ、を更に含む項３４又は３５に記載の方法。
（項３７）前記第２データは、前記ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第１公開鍵に関連するデータに、一方向関数を適用することにより導出され、
前記方法は、前記第２データ及び前記第１アウトプットに含まれる前記データを識別するステップと、
前記第１アウトプットに含まれる前記データに前記一方向関数を適用するステップと、
結果として生じるデータが前記第１データに対応することを検証するステップと、
を更に含む項３４～３６のいずれか一項に記載の方法。
（項３８）前記トランザクションに対応する、前記ブロックチェーン上の識別データにより、前記ブロックチェーントランザクションを識別するステップ、を更に含む項３４～３７のいずれか一項に記載の方法。
（項３９）前記第１データは、前記第１公開鍵に基づくデータに、一方向関数を適用することにより導出される、項３４～３８のいずれか一項に記載の方法。
（項４０）前記ブロックチェーントランザクションが未使用であるかどうかを決定するステップ、を更に含む項３４～３９のいずれか一項に記載の方法。
（項４１）ブロックチェーンへの前記ブロックチェーントランザクションの提出に続いて、前記第１デジタル署名は、前記第２公開鍵により検証される、項３４～４０のいずれか一項に記載の方法。
（項４２）第１参加者と第２参加者との間で暗号システムの公開鍵を共有する方法であって、前記第１参加者は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１秘密鍵を有し、前記第２参加者は、前記暗号システムの第２秘密鍵及び第２公開鍵を含む第２秘密／公開鍵ペアの前記第２秘密鍵を有し、第１デジタル署名は第３秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第１データを含むインプットを有し、第２デジタル署名は、前記第３秘密鍵により署名され、前記第２デジタル署名は、前記第２公開鍵に関連する第２データを含むインプットを有し、
前記方法は、
前記第１参加者により、前記第１秘密鍵及び前記第２公開鍵により、共通シークレットを決定するステップであって、前記共通シークレットは、前記第２秘密鍵及び前記第１公開鍵によっても決定できる、ステップと、
前記第１参加者により、前記第１公開鍵及び前記共通シークレットに基づき、前記暗号システムの少なくとも１つの更なる公開鍵を決定するステップと、
方法。
（項４３）前記暗号システムは、楕円曲線暗号システム又はデジタル署名アルゴリズムに基づく暗号システムである、項４２に記載の方法。
（項４４）少なくとも１つの前記更なる公開鍵は、前記第１公開鍵と、前記共通シークレットに基づき決定論的関数の適用により決定された決定性鍵と、に基づき決定される、項４２又は４３に記載の方法。
（項４５）前記決定論的関数は、一方向関数である、項４４に記載の方法。
（項４６）前記第１公開鍵と、前記共通シークレットに基づくデータへの前記決定論的関数の繰り返し適用により決定された複数の決定性鍵と、に基づき、複数の前記更なる公開鍵を決定するステップ、を更に含む項４４又は４５に記載の方法。
（項４７）少なくとも１つの前記更なる公開鍵に対応する秘密鍵により署名された第１署名を提供することと、少なくとも１つの対応する前記決定性鍵に関連するデータを提供することとにより、前記第１秘密鍵の所有権を証明するステップ、を更に含む項４４～４６のいずれか一項に記載の方法。
（項４８）少なくとも１つの前記決定性秘密鍵に対応する秘密鍵は、前記対応する決定性鍵に関連する前記データに、一方向関数を適用することにより導出される、項４７に記載の方法。
（項４９）ゼロ知識証明により、前記第１秘密鍵の所有権を証明するステップ、を更に含む項４２～４８のいずれか一項に記載の方法。
（項５０）準同型特性を有する暗号システムのそれぞれの秘密鍵に基づき、デジタル署名ペアを提供することにより、前記第１秘密鍵の所有権を証明するステップであって、前記それぞれの秘密鍵は、前記第１秘密鍵により互いに関連付けられる、ステップ、を更に含む項４２～４９のいずれか一項に記載の方法。
（項５１）前記第１デジタル署名は、第１ブロックチェーントランザクションに含まれる、項４２～５０のいずれか一項に記載の方法。
（項５２）前記第２デジタル署名は、第２ブロックチェーントランザクションに含まれる、項４２～５１のいずれか一項に記載の方法。
（項５３）暗号システムの少なくとも１つの秘密鍵を生成する方法であって、第１デジタル署名は、第２秘密鍵により署名され、前記第１デジタル署名は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１公開鍵に関連する第１データを含むインプットを有し、
前記方法は、
前記第１秘密鍵及び決定性秘密鍵に基づき、前記暗号システムの少なくとも１つの第３秘密鍵を生成するステップ、を含む方法。
（項５４）前記暗号システムは、楕円曲線暗号システム又はデジタル署名アルゴリズムに基づく暗号システムである、項５３に記載の方法。
（項５５）少なくとも１つの前記決定性秘密鍵は、決定論的関数をデータに適用することにより決定される、項５３又は５４に記載の方法。
（項５６）前記決定論的関数は、一方向関数である、項５５に記載の方法。
（項５７）データに前記決定論的関数を繰り返し適用することにより決定される複数の前記決定性鍵を決定するステップ、を更に含む請求項５５又は５６に記載の方法。
（項５８）少なくとも１つの前記第３秘密鍵により署名されたデジタル署名を提供することと、少なくとも１つの対応する前記決定性秘密鍵に関連するデータを提供することとにより、前記第１秘密鍵の所有権を証明するステップ、を更に含む項５３～５７のいずれか一項に記載の方法。
（項５９）ゼロ知識証明により、前記第１秘密鍵の所有権を証明するステップ、を更に含む項５３～５８のいずれか一項に記載の方法。
（項６０）準同型特性を有する暗号システムのそれぞれの秘密鍵に基づき、デジタル署名ペアを提供することにより、前記第１秘密鍵の所有権を証明するステップであって、前記それぞれの秘密鍵は、前記第１秘密鍵により互いに関連付けられる、ステップ、を更に含む項５３～５９のいずれか一項に記載の方法。
（項６１）前記第１デジタル署名は、第１ブロックチェーントランザクションに含まれる、項６０に記載の方法。
（項６２）前記第２デジタル署名は、第２ブロックチェーントランザクションに含まれる、項６０又は６１に記載の方法。
（項６３）コンピュータにより実装されるシステムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに項１～６２のいずれか一項に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、
を含むシステム。
（項６４）実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、項１～６２のいずれか一項に記載の方法の実施形態を実行させる、非一時的コンピュータ可読記憶媒体。

＜参考文献＞
Reference Author, date, name and location
[1]“Global Retail E-Commerce Market Size 2014-2021,” Statista, 2019. [Online]. Available: https://www.statista.com/statistics/379046/worldwide-retail-e-commerce-sales/ [Accessed 5 June 2019].
[2][Online]. Available: https://slideplayer.com/slide/4254412/ [Accessed 11 April 2019].
[3]C. Paar and J. Pelzl, Understanding Cryptography, Berlin: Springer, 2010.
[4][Online]. Available: https://en.wikipedia.org/wiki/Certificate_authority [Accessed 11 April 2019].
[5][Online]. Available: https://letsencrypt.org/getting-started/ [Accessed 11 April 2019].
[6][Online]. Available: https://premium.wpmudev.org/blog/ssl-certificate-authorities-reviewed/ [Accessed 11 April 2019].
[7][Online]. Available: https://sachi73blog.wordpress.com/2013/11/21/x509-certificate-asymmetric-encryption-and-digital-signatures/ [Accessed 11 April 2019].
[8][Online]. Available: https://www.ncipher.com/resources/research-reports-and-white-papers/securing-your-pki [Accessed 11 April 2019].
[9][Online]. Available: https://www.tutorialspoint.com/cryptography/public_key_infrastructure.htm [Accessed 11 April 2019].
[10][Online]. Available: https://en.wikipedia.org/wiki/Chain_of_trust#/media/File:Chain_of_trust.svg [Accessed 11 April 2019].
[11][Online]. Available: https://askubuntu.com/questions/363207/what-is-the-difference-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses/363221 [Accessed 11 April 2019].
[12][Online]. Available: https://security.stackexchange.com/questions/178958/what-are-the-differences-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses?noredirect=1&lq=1 [Accessed 11 April 2019].
[13][Online]. Available: https://www.digicert.com/ecc.htm [Accessed 11 April 2019].
[14]A. M. Antonopoulos, “Chapter 5,” in Mastering Bitcoin, California, O’Reilly, 2017, pp. 93-98
[15][Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [Accessed 11 April 2019].

Claims (64)

1. ブロックチェーンに認証済みデータを格納する方法であって、前記方法は、
   第１ブロックチェーントランザクションを生成するステップであって、前記第１ブロックチェーントランザクションの第１アウトプットは、暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データを含み、前記第１ブロックチェーントランザクションは、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名された第１デジタル署名を含み、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
   前記第１ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
   を含む方法。
2. 少なくとも１つの第２ブロックチェーントランザクションを生成するステップであって、前記第２ブロックチェーントランザクションの第１アウトプットは、暗号システムの第３秘密鍵と第３公開鍵とを含む第３秘密／公開鍵ペアの第３公開鍵に基づく第３データを含み、前記第２ブロックチェーントランザクションは、暗号システムの第４秘密鍵と第４公開鍵とを含む第４秘密／公開鍵ペアの第４秘密鍵により署名された第２デジタル署名を含み、前記第２デジタル署名は、前記第３公開鍵に関連する第４データを含むインプットを有する、ステップと、
   前記第２ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
   を更に含む請求項１に記載の方法。
3. 前記第２ブロックチェーントランザクションの前記第１アウトプットは、前記第３データ、前記第４データ、及び前記第２デジタル署名を含み、前記第２デジタル署名は、前記第３データを含むインプットを有する、請求項２に記載の方法。
4. 前記第２ブロックチェーントランザクションのインプットは、前記第１ブロックチェーントランザクションのアウトプットに対応する、請求項２又は３に記載の方法。
5. 前記第２ブロックチェーントランザクションの前記インプットは、前記第２秘密鍵により署名されたデジタル署名を含む、請求項４に記載の方法。
6. 前記第４データは、前記第２ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第３公開鍵に関連するデータに、一方向関数を適用することにより導出される、請求項２～５のいずれか一項に記載の方法。
7. 前記第２ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第４公開鍵と異なる、請求項２～６のいずれか一項に記載の方法。
8. 前記第３公開／秘密鍵ペア及び決定性秘密／公開鍵ペアから、少なくとも１つの更なる公開／秘密鍵ペアを生成するステップ、を更に含む請求項２～７のいずれか一項に記載の方法。
9. 前記第２ブロックチェーントランザクションの第３アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能である、請求項２～８のいずれか一項に記載の方法。
10. 前記第２ブロックチェーントランザクションの前記第３アウトプットはタイムロックされる、請求項９に記載の方法。
11. 前記第１公開鍵及び前記第４公開鍵は、同じ公開鍵である、請求項２～１０のいずれか一項に記載の方法。
12. 前記第２公開鍵及び前記第４公開鍵は、同じ公開鍵である、請求項２～１０のいずれか一項に記載の方法。
13. 前記第３データは、前記第３公開鍵を含むデータに、一方向関数を適用することにより導出される、請求項２～１２のいずれか一項に記載の方法。
14. 前記第１データは、前記第１公開鍵を含むデータに、一方向関数を適用することにより導出される、請求項１～１３のいずれか一項に記載の方法。
15. 更新された第１ブロックチェーントランザクションを生成するステップであって、前記更新された第１ブロックチェーントランザクションの第１アウトプットは、更新された第１公開鍵に基づく更新された第１データを含み、前記更新された第１ブロックチェーントランザクションは、前記第２秘密鍵により署名された更新された第１デジタル署名を含み、前記更新された第１デジタル署名は、前記更新された第１公開鍵に関連する更新された第２データを含むインプットを有する、ステップと、
    前記更新された第１ブロックチェーントランザクションを前記ブロックチェーンにブロードキャストするステップと、
    を更に含む請求項１～１４のいずれか一項に記載の方法。
16. 前記更新された第１ブロックチェーントランザクションの前記第１アウトプットは、前記更新された第１データ、前記更新された第２データ、及び前記更新された第１デジタル署名を含み、前記更新された第１デジタル署名は、前記更新された第２データを含むインプットを有する、請求項１５に記載の方法。
17. 前記第１ブロックチェーントランザクションの前記第１アウトプットは、前記第１データ、前記第２データ、及び前記第１デジタル署名を含み、前記第１デジタル署名は、前記第２データを含むインプットを有する、請求項１～１６のいずれか一項に記載の方法。
18. 前記第２データは、前記第１ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第１公開鍵に関連するデータに、一方向関数を適用することにより導出される、請求項１～１７のいずれか一項に記載の方法。
19. 前記第１ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第２公開鍵と異なる、請求項１～１８のいずれか一項に記載の方法。
20. 少なくとも１つの前記第１アウトプットは、使用不可能アウトプットである、請求項１～１９のいずれか一項に記載の方法。
21. 前記第１ブロックチェーントランザクションの第１インプットは、前記第２秘密鍵により署名されたデジタル署名を含む、請求項１～２０のいずれか一項に記載の方法。
22. 前記第１ブロックチェーントランザクションの第２アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能である、請求項１～２１のいずれか一項に記載の方法。
23. 前記第１ブロックチェーントランザクションの前記第２アウトプットはタイムロックされる、請求項２２に記載の方法。
24. 前記第１ブロックチェーントランザクションの第３アウトプットは、所定の公開鍵に対応する秘密鍵により使用可能であり、前記所定の公開鍵は、前記第２公開鍵と異なる、請求項１～２３のいずれか一項に記載の方法。
25. 前記第１公開／秘密鍵ペア及び決定性秘密／公開鍵ペアから、少なくとも１つの更なる公開／秘密鍵ペアを生成するステップ、を更に含む請求項１～２４のいずれか一項に記載の方法。
26. 少なくとも１つの前記更なる秘密鍵により及び前記対応する決定性秘密鍵により署名されたデジタル署名を提供するステップ、を更に含む請求項８又は２５のいずれか一項に記載の方法。
27. 少なくとも１つの前記更なる秘密鍵により署名されたデジタル署名を提供するステップと、
    前記対応する決定性秘密鍵に関連するデータを提供するステップと、
    を更に含む請求項８又は２５のいずれか一項に記載の方法。
28. 前記対応する決定性秘密鍵は、前記対応する決定性秘密鍵に関連する前記データに、一方向関数を適用することにより導出される、請求項２７に記載の方法。
29. 検証者に、前記決定性鍵の暗号化バージョンに及び前記検証者により選択された値に基づき、前記決定性秘密鍵の知識の証明を提供するステップ、を更に含む請求項８又は請求項２５～２８のいずれか一項に記載の方法。
30. 第１パーティと第２パーティとの間で、前記第１パーティの秘密鍵及び前記第２パーティの公開鍵に基づくシークレット値を共有するステップであって、前記シークレットは、前記第１パーティの公開鍵及び前記第２パーティの秘密鍵からも決定できる、ステップ、を更に含む請求項１～２９のいずれか一項に記載の方法。
31. データに一方向関数を繰り返し適用することにより、複数の決定性鍵を決定するステップ、を更に含む請求項１～３０のいずれか一項に記載の方法。
32. 更新されるべき秘密鍵は、前記更新された鍵への一方向関数の適用に基づく、請求項３１に記載の方法。
33. 前記第１ブロックチェーントランザクションの前記第１アウトプットは、オフチェーンのデータの位置を示す位置データを含む、請求項１～３２のいずれか一項に記載の方法。
34. ブロックチェーンに格納された認証済みデータを検証する方法であって、前記方法は、
    （ｉ）暗号システムの第１秘密鍵と第１公開鍵とを含む第１秘密／公開鍵ペアの第１公開鍵に基づく第１データと、（ｉｉ）ブロックチェーントランザクションに格納された第１デジタル署名と、を識別するステップであって、前記ブロックチェーントランザクションの第１アウトプットは前記第１データを含み、前記第１デジタル署名は、暗号システムの第２秘密鍵と第２公開鍵とを含む第２秘密／公開鍵ペアの第２秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第２データを含むインプットを有する、ステップと、
    前記第２公開鍵により前記第１デジタル署名を検証するステップと、
    を含む方法。
35. 前記ブロックチェーントランザクションの前記第１アウトプットは、前記第１データ、前記第２データ、及び前記第１デジタル署名を含み、前記第１デジタル署名は、前記第１データを含むインプットを有する、請求項３４に記載の方法。
36. 少なくとも１つの前記第１アウトプットは、使用不可能アウトプットであり、
    前記方法は、
    前記使用不可能アウトプットから、前記第１デジタル署名及び前記第１公開鍵を識別するステップ、を更に含む請求項３４又は３５に記載の方法。
37. 前記第２データは、前記ブロックチェーントランザクションの前記第１アウトプットに含まれ前記第１公開鍵に関連するデータに、一方向関数を適用することにより導出され、
    前記方法は、前記第２データ及び前記第１アウトプットに含まれる前記データを識別するステップと、
    前記第１アウトプットに含まれる前記データに前記一方向関数を適用するステップと、
    結果として生じるデータが前記第１データに対応することを検証するステップと、
    を更に含む請求項３４～３６のいずれか一項に記載の方法。
38. 前記トランザクションに対応する、前記ブロックチェーン上の識別データにより、前記ブロックチェーントランザクションを識別するステップ、を更に含む請求項３４～３７のいずれか一項に記載の方法。
39. 前記第１データは、前記第１公開鍵に基づくデータに、一方向関数を適用することにより導出される、請求項３４～３８のいずれか一項に記載の方法。
40. 前記ブロックチェーントランザクションが未使用であるかどうかを決定するステップ、を更に含む請求項３４～３９のいずれか一項に記載の方法。
41. ブロックチェーンへの前記ブロックチェーントランザクションの提出に続いて、前記第１デジタル署名は、前記第２公開鍵により検証される、請求項３４～４０のいずれか一項に記載の方法。
42. 第１参加者と第２参加者との間で暗号システムの公開鍵を共有する方法であって、前記第１参加者は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１秘密鍵を有し、前記第２参加者は、前記暗号システムの第２秘密鍵及び第２公開鍵を含む第２秘密／公開鍵ペアの前記第２秘密鍵を有し、第１デジタル署名は第３秘密鍵により署名され、前記第１デジタル署名は、前記第１公開鍵に関連する第１データを含むインプットを有し、第２デジタル署名は、前記第３秘密鍵により署名され、前記第２デジタル署名は、前記第２公開鍵に関連する第２データを含むインプットを有し、
    前記方法は、
    前記第１参加者により、前記第１秘密鍵及び前記第２公開鍵により、共通シークレットを決定するステップであって、前記共通シークレットは、前記第２秘密鍵及び前記第１公開鍵によっても決定できる、ステップと、
    前記第１参加者により、前記第１公開鍵及び前記共通シークレットに基づき、前記暗号システムの少なくとも１つの更なる公開鍵を決定するステップと、
    方法。
43. 前記暗号システムは、楕円曲線暗号システム又はデジタル署名アルゴリズムに基づく暗号システムである、請求項４２に記載の方法。
44. 少なくとも１つの前記更なる公開鍵は、前記第１公開鍵と、前記共通シークレットに基づき決定論的関数の適用により決定された決定性鍵と、に基づき決定される、請求項４２又は４３に記載の方法。
45. 前記決定論的関数は、一方向関数である、請求項４４に記載の方法。
46. 前記第１公開鍵と、前記共通シークレットに基づくデータへの前記決定論的関数の繰り返し適用により決定された複数の決定性鍵と、に基づき、複数の前記更なる公開鍵を決定するステップ、を更に含む請求項４４又は４５に記載の方法。
47. 少なくとも１つの前記更なる公開鍵に対応する秘密鍵により署名された第１署名を提供することと、少なくとも１つの対応する前記決定性鍵に関連するデータを提供することとにより、前記第１秘密鍵の所有権を証明するステップ、を更に含む請求項４４～４６のいずれか一項に記載の方法。
48. 少なくとも１つの前記決定性秘密鍵に対応する秘密鍵は、前記対応する決定性鍵に関連する前記データに、一方向関数を適用することにより導出される、請求項４７に記載の方法。
49. ゼロ知識証明により、前記第１秘密鍵の所有権を証明するステップ、を更に含む請求項４２～４８のいずれか一項に記載の方法。
50. 準同型特性を有する暗号システムのそれぞれの秘密鍵に基づき、デジタル署名ペアを提供することにより、前記第１秘密鍵の所有権を証明するステップであって、前記それぞれの秘密鍵は、前記第１秘密鍵により互いに関連付けられる、ステップ、を更に含む請求項４２～４９のいずれか一項に記載の方法。
51. 前記第１デジタル署名は、第１ブロックチェーントランザクションに含まれる、請求項４２～５０のいずれか一項に記載の方法。
52. 前記第２デジタル署名は、第２ブロックチェーントランザクションに含まれる、請求項４２～５１のいずれか一項に記載の方法。
53. 暗号システムの少なくとも１つの秘密鍵を生成する方法であって、第１デジタル署名は、第２秘密鍵により署名され、前記第１デジタル署名は、準同型特性を有する暗号システムの第１秘密鍵及び第１公開鍵を含む第１秘密／公開鍵ペアの前記第１公開鍵に関連する第１データを含むインプットを有し、
    前記方法は、
    前記第１秘密鍵及び決定性秘密鍵に基づき、前記暗号システムの少なくとも１つの第３秘密鍵を生成するステップ、を含む方法。
54. 前記暗号システムは、楕円曲線暗号システム又はデジタル署名アルゴリズムに基づく暗号システムである、請求項５３に記載の方法。
55. 少なくとも１つの前記決定性秘密鍵は、決定論的関数をデータに適用することにより決定される、請求項５３又は５４に記載の方法。
56. 前記決定論的関数は、一方向関数である、請求項５５に記載の方法。
57. データに前記決定論的関数を繰り返し適用することにより決定される複数の前記決定性鍵を決定するステップ、を更に含む請求項５５又は５６に記載の方法。
58. 少なくとも１つの前記第３秘密鍵により署名されたデジタル署名を提供することと、少なくとも１つの対応する前記決定性秘密鍵に関連するデータを提供することとにより、前記第１秘密鍵の所有権を証明するステップ、を更に含む請求項５３～５７のいずれか一項に記載の方法。
59. ゼロ知識証明により、前記第１秘密鍵の所有権を証明するステップ、を更に含む請求項５３～５８のいずれか一項に記載の方法。
60. 準同型特性を有する暗号システムのそれぞれの秘密鍵に基づき、デジタル署名ペアを提供することにより、前記第１秘密鍵の所有権を証明するステップであって、前記それぞれの秘密鍵は、前記第１秘密鍵により互いに関連付けられる、ステップ、を更に含む請求項５３～５９のいずれか一項に記載の方法。
61. 前記第１デジタル署名は、第１ブロックチェーントランザクションに含まれる、請求項６０に記載の方法。
62. 前記第２デジタル署名は、第２ブロックチェーントランザクションに含まれる、請求項６０又は６１に記載の方法。
63. コンピュータにより実装されるシステムであって、
    プロセッサと、
    前記プロセッサによる実行の結果として、前記システムに請求項１～６２のいずれか一項に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、
    を含むシステム。
64. 実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１～６２のいずれか一項に記載の方法の実施形態を実行させる、非一時的コンピュータ可読記憶媒体。

Images