JP7454750B2 - 複数の実体のルート証明書データブロックチェーンの構築 - Google Patents

複数の実体のルート証明書データブロックチェーンの構築 Download PDF

Info

Publication number
JP7454750B2
JP7454750B2 JP2023522790A JP2023522790A JP7454750B2 JP 7454750 B2 JP7454750 B2 JP 7454750B2 JP 2023522790 A JP2023522790 A JP 2023522790A JP 2023522790 A JP2023522790 A JP 2023522790A JP 7454750 B2 JP7454750 B2 JP 7454750B2
Authority
JP
Japan
Prior art keywords
block
entity
action
data
genesis
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2023522790A
Other languages
English (en)
Other versions
JP2023546856A (ja
Inventor
淳 山田
Original Assignee
イサラ コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by イサラ コーポレイション filed Critical イサラ コーポレイション
Publication of JP2023546856A publication Critical patent/JP2023546856A/ja
Application granted granted Critical
Publication of JP7454750B2 publication Critical patent/JP7454750B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)

Description

関連出願の相互参照
本出願は、２０２０年１０月１５日に出願された米国特許出願第１７／０７１，４５１号に対する優先権を主張し、この米国特許出願の開示は、参照によって全体的に本明細書に包含される。
以下の説明は、暗号システムのための複数の実体のルート証明書データブロックチェーンに関連している。
暗号システムは、パブリックチャネルを経由して安全に通信するために使用される。例えば、一部の暗号システムは、メッセージを暗号化することによって機密性を実現し、一部の暗号システムは、デジタル署名によって信頼性を実現する。一部の暗号システムは、公開鍵、秘密鍵、および共有された秘密を使用して動作する。
例示的な通信システムの態様を示すブロック図である。 図１Ａのルート証明書データブロックチェーンとして使用され得る例示的なブロックチェーンの図である。 複数の実体のルート証明書データブロックチェーンのジェネシスブロックに関する例示的な署名プロセスの図である。 複数の実体のルート証明書データブロックチェーンのアクションブロックに関する例示的な署名プロセスの図である。 例示的なジェネシスブロック作成プロセスの態様を示すフロー図である。 メンバー実体から受信された例示的なデータエントリの図である。 ジェネシスブロックデータエントリに基づいて検証実体によって作成された例示的なジェネシスデータブロックの図である。 図３Ｃのジェネシスデータブロックに基づいて検証実体によって作成された例示的なジェネシスブロックの図である。 アクションブロックを作成するための例示的なプロセスの態様を示すフロー図である。 要求している実体から受信された例示的なアクションブロックデータエントリの図である。 図４Ｂのアクションブロックデータエントリに基づいて検証実体によって作成された例示的なアクションデータブロックの図である。 図４Ｃのアクションデータブロックに基づいて検証実体によって作成された例示的なアクションブロックの図である。 アクションブロックを作成するための例示的なプロセスの態様を示すフロー図である。 例示的なアクションブロックデータエントリの図である。 図５Ｂのアクションブロックデータエントリに基づいて検証実体によって作成された例示的なアクションデータブロックの図である。 図５Ｃのアクションデータブロックに基づいて検証実体によって作成された例示的なアクションブロックの図である。 例示的なコンピュータシステムのブロック図である。
本明細書で説明される内容の一部の態様では、暗号システムにおいて使用するために、分散された複数の実体のルート認証機関（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）システムが構築される。一部の例では、本明細書で説明されるシステムおよび技術の実装は、既存の技術を上回る技術的優位性または改良をもたらす。一例として、複数の実体のルートＣＡシステムを使用することによって、単一の実体のセキュリティ侵害（例えば、攻撃、技術的機能不良、または他のイベントから生じるセキュリティ侵害）からの損害が、封じ込められ得る。例えば、複数の実体のルートＣＡシステムは、ルートＣＡからのセキュリティを侵害された秘密鍵に対応する公開鍵を取り消すため、または場合によっては、問題のあるルートＣＡを完全に除去するためのプロトコルまたは別の正式なメカニズムを提供し得る。
したがって、本明細書で説明されるシステムおよび技術の態様は、通信システム（例えば、データネットワークなど）、コンピュータシステム（例えば、ネットワーク接続されたコンピュータなど）、スマートデバイス（例えば、いわゆる「モノのインターネット」（ＩｏＴ：Ｉｎｔｅｒｎｅｔ－ｏｆ－Ｔｈｉｎｇｓ）デバイスなど）、および他の種類の技術の動作を改良するために使用され得る。例えば、多種多様な最新の技術は、安全な動作のために、コンピュータによって実装された暗号システムに依存し、本明細書で説明される技術は、例えば、そのようなコンピュータによって実装された暗号システムを、より安全、より効率的にするか、または場合によっては、他の優位性を提供して、それらの暗号システムを改良することができる。
公開鍵暗号は、安全な認証、秘密鍵の共有などを実現するために、さまざまな技術において広く展開されている。公開鍵を使用して、デジタル署名を検証し、通信している関係者の識別情報の妥当性を確認すること、またはメッセージを安全に暗号化するために共有された秘密を確立することができる。公開鍵暗号によって提供されるセキュリティは、通常、信頼できる方法で、正当な識別情報に安全に結び付けられている受信された公開鍵に依存する。そのような安全な結び付けがなければ、実体は、意図された関係者に成り済ましている悪意のある関係者の識別情報を、知らないうちに信用してしまうか、またはメッセージを、実際は敵対者である間違った受信者に送信する可能性がある。公開鍵において、正当な識別情報に結び付けられているという信用を確立するために、公開鍵基盤（ＰＫＩ：Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）および信用の輪という２つの一般的な種類のシステムが使用されている。
ＰＫＩは、暗号システムにおいて信用を確立するための、現在最も広く展開されているメカニズムである。従来、ＰＫＩシステムは、ルート認証機関（ルートＣＡ）と呼ばれる信頼できる実体から生じる信用の階層木を構築する。標準的なＰＫＩシステムでは、ＣＡは、公開鍵が識別情報に属していることを確認し、これらの公開鍵および識別情報をデジタル署名に結び付け、この結び付けをデジタル証明書の形態で発行する。任意の関係者（「末端実体」）は、ＣＡの公開鍵を使用して証明書でＣＡのデジタル署名の妥当性を確認することによって、公開鍵および識別情報の結び付けを検証することができる。この妥当性確認動作はＣＡの公開鍵を使用するため、ＣＡの公開鍵も信頼されなければならない。したがって、署名された証明書を発行することによって、この公開鍵がＣＡに属していることを保証する、親ＣＡが存在しなければならない。このようにして、証明書がルートＣＡに連結され、信用を構築する。そして、このチェーンは、どこかで終わらなければならない。チェーンにおける最後の証明書は、ルート証明書と呼ばれ、ルートＣＡに属する。ルート証明書は、保証を提供するための上位の第三者ＣＡが存在しないため、自己署名される。したがって、ルート証明書は、異なる方法で信頼される。通常、ルート証明書を信用するために、公知または個人的な情報交換などの方法が使用される。
従来のＰＫＩシステムは、いくつかの技術的課題および脆弱性に直面している。ルートＣＡが単一障害点になり得るため、ＰＫＩシステムの最も重要な脆弱性のうちの１つは、ルートＣＡである。ルートＣＡがセキュリティを侵害された場合、システム全体のセキュリティの壊滅的な崩壊を引き起こす可能性がある。セキュリティを侵害されたルートＣＡの秘密鍵を持っている攻撃者は、ルート証明書によって検証可能な証明書を発行することができる。これは、攻撃者が、システム内の任意の実体に成り済ますことができ、システム全体のセキュリティおよび信用の壊滅的な崩壊を引き起こす可能性があるということを意味する。１つのルートＣＡの代わりに、複数のルートＣＡを含む信用木を構築する技術プラットフォームは、セキュリティおよび効率を改善することができ、例えば、単一の実体のセキュリティ侵害からの損害が封じ込められるか、または他の方法で軽減されることを可能にする。
一部の状況では、ルートＣＡ（従来のＰＫＩにおける潜在的な単一障害点）のリスクおよび責任は、システムをセキュリティの脆弱性の危険にさらされたままにし、ＰＫＩの展開を妨げることがある。例えば、ピア組織（および場合によっては、競合する組織）のコンソーシアムために単一のＰＫＩシステムを構築しようとする場合、セキュリティ障害に対する責任を負いたい組織が１つもなく、したがって、どのピア組織も、ルートＣＡの役割を進んで引き受けないということがあり得る。また、組織は、上位の機関が組織を管理することを望まないことがある。そのような場合、複数のピア実体のルートＣＡコンソーシアムを構築する技術プラットフォームは、セキュリティおよび効率を改善するためのＰＫＩを構築するために、より魅力的であり、好ましい。
ルート証明書を取り消す権限を与えられたルートＣＡより上位の信頼できる実体が存在しないため、従来のＰＫＩシステムは、ルートＣＡの秘密鍵のセキュリティ侵害から生じる壊滅的な障害に対する準備が十分でないことがある。ルート証明書を取り消すための正式な標準的メカニズム、またはユーザが無効になったルート証明書を識別するためのメカニズムは存在しなかった。したがって、そのような従来のＰＫＩシステムのユーザは、セキュリティを侵害されたルート証明書を識別するために、（例えば、「任意選択的な」ソフトウェアの更新を含む）公表および口伝えに頼っていた。ルート証明書を識別して取り消すための、より体系的な方法の確立を可能にする技術プラットフォームは、セキュリティおよび効率を改善する。
公開鍵暗号を使用して信用を構築するための別の従来のメカニズムは、プリティグッドプライバシー（ＰＧＰ：Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ）などのシステム内で展開される信用の輪である。このメカニズムは、管理する機関を回避するように設計されており、したがって、信用の輪システムにはＣＡが存在しない。代わりに、信用の輪システム内のセキュリティは、ピアツーピアの信用に基づく。例えば、このメカニズムは、正体不明の誰かというような種類の、信用の「友人」ネットワークとして説明されてよく、このメカニズムでは、ある人が、その人がよく知っている人（「友人」）を信用し、友人のデジタル証明書にデジタル署名することによって、友人の公開鍵および識別情報の結び付けを保証する。実体が多くの友人を持っている場合、実体は、複数の署名を証明書に含めることができる。したがって、デジタル証明書での保証の量は、証明書上の署名の数（この文脈では、直接の友人の数を示す）、およびこの証明書に達するための、署名によって接続された証明書（例えば、友人）のチェーンのホップ数という、２つの基準によって測定され得る。例えば、自分は、自分の直接の友人の証明書に署名してよい。したがって、自分は、自分の署名が証明書上にあるため、この証明書を信用する。証明書が、自分の直接の友人の証明書でない場合、この証明書から、信用している誰か（直接の友人）に到達するまで、友人のホップをたどることができてよい。従来の信用の輪の注目すべき欠点のうちの１つは、十分な数の接続された経路を含むために、信用ネットワークがかなり大きくならなければならないということであり、そうしないと、チェーンを完了できないことがあり、これは、妥当性確認が失敗するということを意味する。十分に接続されたネットワークを構築するのには、時間がかかることがある。従来の信用の輪は、ピアツーピアの大きいパブリックネットワークに対して、および他の状況において、十分正しく機能することができる。しかし、信用の輪は、階層を許可しないため、階層構造を有する企業または他の組織などの組織に、常に適しているとは限らない。さらに、従来の信用の輪システムにおける証明書の取り消しは、証明書を取り消す機関が存在しないため、困難である可能性がある。通常、取り消しは、合意によって確立される。そのような取り消しプロセスは、完了するのに長い時間がかかる可能性が高く、ユーザは、このプロセスの間、危険にさらされたままになる。
一部の実装では、複数の実体のルートＣＡシステムは、例えば、従来のＰＫＩシステムおよび従来の信用の輪システムを上回る技術的優位性をもたらすことができる。例えば、複数の実体のルートＣＡシステムは、単一のルートＣＡを含まれないが、階層構造が構築され得る、信用メカニズムを提供できる。加えて、複数の実体のルートＣＡシステムは、セキュリティを侵害されたルートＣＡ実体の公開鍵を取り消すための効率的なメカニズムを提供できる。
複数の実体のルートＣＡシステムでは、例えば、単一のルートＣＡに属している単一のルート証明書の使用の代わりに、複数の実体のルート証明書セットが使用される。複数の実体のルート証明書セットは、データセット（例えば、複数の実体の識別情報および公開鍵を含んでいるデータブロックのチェーン）であることができ、またはデータセットを使用して表され得る。複数の実体のルートＣＡシステムは、メンバー実体のコンソーシアム（例えば、委員会、組織、または実体の他の関連性）を表してよく、メンバー実体は、ルートＣＡまたは末端実体（あるいは両方）として機能してよい。複数の実体のルートＣＡシステムは複数の異なるメンバー実体を含んでいるため、単一の実体が単一障害点になることができない。複数の実体のルート証明書データブロックチェーンは、（例えば、従来のルート証明書が使用されるように）暗号システムにおいて使用するために、（例えば、従来のルート証明書が公開されるか、ブロードキャストされるか、または配布されるように）公開されるか、ブロードキャストされるか、または配布されてよい。複数の実体のルート証明書データブロックチェーンは、例えば、コンソーシアム内の新しい実体を表す新しいデータブロックをチェーンに追加することによって、ルートＣＡコンソーシアムに対する動的な変更も可能にし、このようにして柔軟性を提供し、実体の取り消しも可能にする。加えて、複数の実体のルートＣＡシステムは、例えば、メンバー実体もルートＣＡとして機能し、そのためＰＫＩの部分木を下に構築できる場合に、階層構造を可能にする。
一部の実装では、複数の実体のルートＣＡシステムは、少なくともルートＣＡレベルが除去されるか、または置き換えられるため、従来のＰＫＩ手法から、階層の少なくとも１つの層を減らす。場合によっては、複数の実体のルート証明書システムは、メンバーＣＡより下位の層に展開された場合、層の数をさらに減らし得る。さらに、複数の実体のルートＣＡシステムは、複数の暗号方式を可能にし得る。その結果、コンソーシアムのメンバーは、１つまたは複数の署名方式を使用することができる。
したがって、複数の実体のルート証明書セットは、動的であることができる。以下では、複数の実体のルートＣＡ技術プラットフォームにおいて展開され得る、安全な方法で複数の実体のルート証明書データブロックチェーンを構築して維持するための例示的なメカニズムが、さらに説明される。
例示的な実装の概要として、複数の実体のルート証明書データブロックチェーンのブロックのチェーンが、ジェネシスブロックから開始されてよい。ジェネシスブロックは、ルートＣＡコンソーシアムの創設メンバーによって確立された初期ルート証明書データブロックチェーンとして提供され得る。ジェネシスブロックは、次のように構築されてよい。例えば、創設メンバーは、最初に、ルート証明書データブロックチェーンを確立することに同意してよい。各創設メンバーは、公開鍵と秘密鍵の対を保有し、実体の公開鍵と秘密鍵の対は、暗号システムによって規定された通りに関連付けられた秘密鍵および対応する公開鍵を含む。秘密鍵は実体の秘密として保たれ、一方、公開鍵は公開され得る。創設メンバーのルートＣＡコンソーシアムが確立された後に、各創設メンバーは、識別情報および公開鍵の組み合わせにデジタル署名する。識別情報、公開鍵、およびデジタル署名を含んでいる創設メンバー実体ごとのデータのセットが、ジェネシスデータブロックを構築するために、検証実体によって収集される。次に、このジェネシスデータブロックは、完全性を保証するため、および承認の証拠を記録するために、創設メンバー実体によってデジタル署名されてよい。ジェネシスデータブロックに対するこれらの複数の署名および識別情報と公開鍵の対に対する個別の署名の組み合わせは、単一障害点を防ぐことにさらに貢献することができる。創設メンバー実体の複数の署名が追加されたこのジェネシスデータブロックは、ジェネシスブロックになる。以下では、例示的なジェネシスブロックの構築が、図３Ａ～３Ｄに関してさらに詳細に説明される。
ルートＣＡコンソーシアムに対する（例えば、ルートＣＡコンソーシアムのメンバーシップにおいて、または他の方法で）変更が発生するたびに、新しいブロックが連結され得る。そのような変更は、メンバー実体の追加または除去、既存のメンバー実体の公開鍵の更新、取り消し、置き換え、追加、またはキャンセル、あるいは別の種類の変更を含んでよい。変更の情報をデータエントリとして含んでいる新しいブロックは、暗号プロセスによって、ブロックの既存のチェーンに追加されることが可能であり、データの新しいブロックは、チェーンの内の最後かつ最新である前のブロックのハッシュを使用して連結され、この組み合わせが、コンソーシアムのメンバー実体によってデジタル署名される。一部の実装では、チェーンからのブロックの除去が許可されず、ブロックは、発生順に連結される。したがって、最新のものから順番にブロックを追跡することによって、ルートＣＡコンソーシアムのメンバーシップの現在の状態が、確定的に示されることが可能であり、識別情報に対する公開鍵の妥当性を確認できるようにする。
コンソーシアムのメンバー実体は単一障害点ではないため、そのような実体の秘密鍵のセキュリティ侵害からの損害が、封じ込められ得る。例えば、そのようなセキュリティ侵害のリスクが、セキュリティを侵害されたメンバー実体の下のサブネットワークに制限されることが可能であり、他のメンバーの下のサブネットワークは、影響を受けないままである。また、単一の実体のセキュリティ侵害が、ブロックのチェーン内のメンバーシップデータを変更するのに十分でないように、各ブロック上で複数の実体の署名が提供され得る。このメカニズムは、または安全な体系的方法で、セキュリティを侵害された秘密鍵に対応する公開鍵の素早い取り消し、または問題のあるメンバーの除去も実現し得る。
したがって、本明細書で説明されるシステムおよび技術の態様は、複数の実体のルートＣＡシステムの動作を改良するために使用され得る。一部の実装では、本明細書で説明される複数の実体のルートＣＡシステムは、単一障害点（例えば、セキュリティを侵害されたメンバー実体）を除去することによって、セキュリティリスクを軽減し得る。一部の実装では、説明される複数の実体のルートＣＡシステムは、ジェネシスブロックまたはアクションブロックの並列化されたより高速な構築を実行し得る。一部の実装では、本明細書で説明される複数の実体のルートＣＡシステムは、帯域幅の消費を減らし得る。
図１Ａは、例示的な通信システム１００の態様を示すブロック図である。図１Ａに示された例示的な通信システム１００は、４つのノード（２つの実体ノード１０２、１０４、および２つのＣＡノード１１２、１１４）を含んでいる。これらのノードは、ネットワーク１０６を経由して互いに通信する。通信システム１００は、追加の特徴または異なる特徴を含んでよく、通信システム内のコンポーネントは、図１Ａに示されているように、または別の方法で、構成されてよい。
一部の実装では、通信システム１００内のノードは、サーバ／クライアントの関係を有する。例えば、サービスネットワーク内で、実体ノード１０２はサーバであることができ、実体ノード１０４はクライアントであることができ、この逆も同様である。一部の実装では、通信システム１００内のノードは、ピアツーピアの関係を有してよい。例えば、実体ノード１０２、１０４は、サービスネットワーク、ピアツーピアネットワーク、または別の種類のネットワーク内のピアであることができる。ノードは、通信システム１００内の別の種類の関係を有してよい。
図１Ａに示された例では、例示的な実体ノード１０２、１０４およびＣＡノード１１２、１１４は、他のノードと通信するために使用される計算リソース（例えば、ハードウェア、ソフトウェア、およびファームウェア）をそれぞれ含む。例えば、図１Ａに示された通信システム１００内のノードの各々は、図６に示された例示的なコンピュータシステム６００またはそのコンポーネントとして実装されてよい。一部の実装では、通信システム１００内のノードは、例えば、ラップトップ、デスクトップ、ワークステーション、スマートフォン、タブレット、パーソナルデジタルアシスタント、サーバ、サーバクラスタ、メインフレーム、および他の種類コンピュータシステムなどの、さまざまなシステム内で実装され得る。場合によっては、単一のデバイスは、実体ノードおよび認証機関ノードの両方として動作してよい。
図１Ａに示された例では、（実体ノード１０２、１０４のうちのどちらかによって表された）末端実体または（ＣＡノード１１２、１１４のうちのどちらかによって表された）ＣＡ実体は、コンピューティングデバイス、コンピュータシステム、ＩＰアドレスまたは他のネットワークアドレス、あるいは別の種類のコンピュータ可読の識別子またはコンピュータリソースの事例に対応してよい。それに応じて、各ノードの１つまたは複数のプロセッサまたは他の要素によって、各実体の計算および他の動作が実行されてよい。同様に、実体によって送信または受信された情報は、各ノードの要素（例えば、１つまたは複数のプロセッサ、メモリ、またはインターフェイス）によって送信または受信されてよい。
例示的なネットワーク１０６は、データ通信ネットワークまたは別の種類の通信リンクのすべてまたは一部を含むことができる。例えば、ネットワーク１０６は、１つまたは複数の有線接続またはワイヤレス接続、１つまたは複数の有線ネットワークまたはワイヤレスネットワーク、あるいは他の通信チャネルを含むことができる。一部の例では、ネットワーク１０６は、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、プライベートネットワーク、仮想プライベートネットワーク（ＶＰＮ：Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、パブリックネットワーク（インターネットなど）、ピアツーピアネットワーク、セルラーネットワーク、Ｗｉ－Ｆｉネットワーク、パーソナルエリアネットワーク（ＰＡＮ：Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）（例えば、Ｂｌｕｅｔｏｏｔｈ ｌｏｗ ｅｎｅｒｇｙ（ＢＴＬＥ）ネットワーク、ＺｉｇＢｅｅネットワークなど）またはマシン間（Ｍ２Ｍ：ｍａｃｈｉｎｅ－ｔｏ－ｍａｃｈｉｎｅ）通信を含む他の短距離ネットワーク、あるいは別の種類のデータ通信ネットワークを含む。
一部の例では、図１Ａに示されたノードは、ジェネシスブロック、および場合によってはジェネシスブロックに連結された１つまたは複数のブロックのチェーンを含んでいる、複数の実体のルート証明書データブロックチェーンに基づいて、安全な方法で互いに通信する。例えば、ノードは、例示的なルート証明書データブロックチェーン１２０に基づいて信用が確立されている、暗号システムまたは別の種類のシステムを利用してよい。図１Ａに示された例示的なルート証明書データブロックチェーン１２０は、ジェネシスブロック１２２および２つのアクションブロック１２４Ａ、１２４Ｂを含んでいる。第１のアクションブロック１２４Ａは、ジェネシスブロック１２２に連結され、第２のアクションブロック１２４Ｂは、第１のアクションブロック１２４Ａに連結される。
通常、複数の実体のルート証明書データブロックチェーンは、ジェネシスブロック１２２のみを含んでよく、または任意の数のアクションブロック１２４を含んでよい。ジェネシスブロック１２２は、ルートＣＡコンソーシアムによって、またはルートＣＡコンソーシアムのために生成されるチェーン内の最初のブロックであり、アクションブロック１２４Ａ、１２４Ｂは、ルート証明書データブロックチェーン１２０またはルートＣＡコンソーシアムに関連する変更を表す。例示的なジェネシスブロックが図３Ｄに示されており、例示的なアクションブロックが図４Ｄおよび５Ｄに示されている。ルート証明書データブロックチェーン１２０は、場合によっては、追加の種類または異なる種類のブロックを含んでよい。
一部の実装では、ＣＡノード１１２、１１４は、複数の実体のルート証明書データブロックチェーン１２０に基づいてデジタル証明書を発行してよい。一例として、第１のＣＡノード１１２は、ルート証明書データブロックチェーン１２０（例えば、ジェネシスブロック１２２、またはアクションブロック１２４Ａのうちの１つ、あるいはその両方）に含まれている公開鍵を持っているルートＣＡコンソーシアムメンバーを表してよく、第１のＣＡノード１１２は、ルート証明書データブロックチェーン１２０内の公開鍵を使用して妥当性を確認され得るデジタル証明書を発行してよい。それに応じて、他の実体は、ルート証明書データブロックチェーン１２０を使用して、第１のＣＡノード１１２によって発行されデジタル証明書における信用を確立してよい。一部の実装では、第２のＣＡノード１１４は、ルート証明書データブロックチェーン１２０（例えば、ジェネシスブロック１２２、またはアクションブロック１２４Ａのうちの１つ、あるいはその両方）にやはり含まれている公開鍵を持っている別のルートＣＡコンソーシアムメンバーを表す。代替的または追加的に、第２のＣＡノード１１４は、第１のＣＡノード１１２によって発行されたデジタル証明書に基づいて他の実体によって信頼された下位のＣＡであることができる。
一部の実装では、ＣＡノード１１２、１１４によって発行されたデジタル証明書は、従来のルート証明書の代わりに、複数の実体のルート証明書データブロックチェーン１２０に対してデジタル証明書の妥当性が確認され得るということを除いて、従来のＰＫＩシステムにおけるデジタル証明書の使用に類似する方法で、末端実体によって使用されてよい。一例として、末端実体は、ＣＡノード１１２によって発行されたデジタル証明書を所有してよく、デジタル証明書は、末端実体の公開鍵およびＣＡのデジタル署名を含み、ＣＡのデジタル署名は、デジタル証明書内のＣＡのデジタル署名を検証することによって、他の末端実体がこの末端実体の公開鍵を信頼することができるように、末端実体の公開鍵を末端実体の識別情報に暗号によって結び付ける。ここで、ＣＡのデジタル署名は、ルート証明書データブロックチェーン１２０内の公開鍵を使用して検証されるため、信頼される。
一部の例では、実体ノード１０２、１０４およびＣＡノード１１２、１１４は、ルート証明書データブロックチェーン１２０に基づいて信用を確立する暗号システムを使用して、ネットワーク１０６を経由して安全に通信することができる。例えば、暗号システムは、複数の実体のルート証明書データブロックチェーン１２０に基づいて信頼されるデジタル証明書を使用する暗号プロトコルを含んでよい。
場合によっては、実体ノード１０２、１０４は、各ノードが他のノードから受信されたメッセージの信頼性の妥当性を確認することを可能にするデジタル署名方式を使用する。デジタル署名方式は、例えば、楕円曲線暗号（ＥＣＣ：ｅｌｌｉｐｔｉｃ ｃｕｒｖｅ ｃｒｙｐｔｏｇｒａｐｈｙ）に基づく署名方式、ＲＳＡに基づく署名方式、格子に基づく署名方式、ハッシュに基づく署名方式、多変量署名方式、または別の種類の暗号を使用する方式であることができる。署名者の公開鍵を使用してデジタル署名が検証される場合、検証者は、ルート証明書データブロックチェーン１２０に基づいて署名者の公開鍵における信用を確立してよい。
場合によっては、実体ノード１０２、１０４は、各ノードが機密のメッセージを他のノードに送信することを可能にする暗号化方式を使用する。暗号化方式は、例えば、楕円曲線暗号（ＥＣＣ）に基づく暗号化方式、ＲＳＡに基づく暗号化方式、格子に基づく暗号化方式、コードに基づく暗号化方式、または別の種類の暗号を使用する方式であることができる。受信者の公開鍵を使用して受信者のメッセージが暗号化される場合、送信者は、ルート証明書データブロックチェーン１２０に基づいて受信者の公開鍵における信用を確立してよい。
図１Ｂは、図１Ａのルート証明書データブロックチェーン１２０として使用され得る例示的なブロックチェーンの図である。図１Ｂに表された例示的なブロックチェーンは、例えば、コンソーシアムブロックチェーンプロトコルに従うブロック連鎖技術を使用して、次々と連結されたブロックを含んでいる。パブリックブロックチェーンプロトコル（例えば、ビットコインおよび他の形態の暗号通貨によって使用されるブロックチェーン技術）とは異なり、コンソーシアムブロックチェーンプロトコルは、新しいブロックを追加するためにマイニングに依存しない。代わりに、許可された実体によって、ブロックがチェーンに追加され、ブロックを連結するための暗号技術が、マイニングを利用するパブリックブロックチェーンプロトコルとはかなり異なることがある。
図１Ｂに示された例では、ブロックのチェーンが、チェーンの最初のブロック（「Ｂｌｏｃｋ＿＃０」）であるジェネシスブロック１２２から開始される。例示的なジェネシスブロック１２２は、データブロック（「データブロック番号０」）、およびデータブロックに対するデジタル署名を含んでいる。チェーンの各新しいブロックを形成するプロセスでは、ハッシュ関数を前のブロックに適用することによって、チェーン内の前のブロックのハッシュが計算され、このハッシュが新しいデータブロックに追加される。図１Ｂに示されているように、アクションブロック１２４Ａ（「Ｂｌｏｃｋ＿＃１」）がジェネシスブロック１２２から連結され、アクションブロック１２４Ａは、新しいデータブロック（「データブロック番号１」）および前のブロックのハッシュ（Ｈａｓｈ（Ｂｌｏｃｋ＿＃０））を含んでいる。ジェネシスブロック１２２のハッシュは、Ｈａｓｈ（Ｂｌｏｃｋ＿＃０）を計算することによって生成される。ここで、Ｈａｓｈ（・）は、暗号ハッシュ関数を入力値（例えば、「Ｂｌｏｃｋ＿＃０」）に適用することによって生成された出力ハッシュ値を表す。一部の実装では、ＳＨＡ－２ファミリー（例えば、ＳＨＡ－２５６、ＳＨＡ－５１２）またはＳＨＡ－３ファミリー内の１つまたは複数の従来のハッシュ関数が使用され得る。追加のハッシュ関数または異なるハッシュ関数が使用されてよい。
チェーンの各新しいブロックを形成するプロセスでは、前のブロックのハッシュおよび新しいデータブロックの１つまたは複数のデジタル署名が生成され、これらのデジタル署名が、新しいデータブロックおよび前のブロックのハッシュに追加される。図１Ｂに示されているように、各デジタル署名は、新しいデータブロック（「データブロック番号１」）およびハッシュ（Ｈａｓｈ（Ｂｌｏｃｋ＿＃０））の連結に基づいて生成され、このデジタル署名が追加されて、アクションブロック１２４Ａを形成する。通常、デジタル署名は、署名する実体の秘密鍵および署名されるメッセージを含んでいる入力（例えば、図１Ｂに示されているデータブロックおよびハッシュ）に対して動作するデジタル署名アルゴリズムによって生成される。デジタル署名は、任意の適切なデジタル署名アルゴリズム（例えば、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ、格子に基づくデジタル署名アルゴリズム、ハッシュに基づくデジタル署名アルゴリズム、多変量デジタル署名アルゴリズムなど）に従って生成されてよい。
チェーンのその後の各ブロックは、同様のプロセスを使用して生成されてよい。図１Ｂに示されているように、アクションブロック１２４Ｂ（「Ｂｌｏｃｋ＿＃ｎ」）が前のブロック（「Ｂｌｏｃｋ＿＃（ｎ－１）」）から連結され、アクションブロック１２４Ｂは、新しいデータブロック（「データブロック番号ｎ」）および前のブロックのハッシュを含んでいる。やはり図１Ｂに示されているように、１つまたは複数のデジタル署名が、新しいデータブロック（「データブロック番号ｎ」）およびハッシュ（「Ｈａｓｈ（Ｂｌｏｃｋ＿＃（ｎ－１））」）の連結に基づいて生成され、このデジタル署名が追加されて、アクションブロック１２４Ｂを形成する。
図１Ｂに示された例では、前のブロックのハッシュは、２つのブロック（例えば、ジェネシスブロック１２２およびアクションブロック１２４Ａ）間のリンクを明確に指定し、デジタル署名が、新しいブロックおよび前のブロックからのリンクの完全性を保証する。図２Ａ～２Ｂ、３Ａ～３Ｄ、４Ａ～４Ｄ、および５Ａ～５Ｄの例、ならびに下の関連する説明によって示されているように、ブロックのチェーンを構築するための図１Ｂに表されたデータ構造および方法の種類は、複数の実体のルート証明書データブロックチェーンを構築するための基礎として使用されてよい。
一部の実装では、（例えば、図３Ａ～３Ｄ、４Ａ～４Ｄ、および５Ａ～５Ｄの例に従って）複数の実体のルート証明書データブロックチェーンを構築することによって、通信システム内のノードによって表された実体のネットワーク内の信用を構築する。例えば、ノードの各々は、ＣＡ実体または末端実体を表してよい。ノードを接続する通信チャネルは、セキュリティが適用されず、オープンかつパブリックであると仮定されてよい。ノードによって表された実体は、ＣＡ実体および末端実体に関して何らかの階層が存在し得るコミュニティを含んでよい。ルートＣＡコンソーシアムは、（例えば、コミュニティ内の、または別の方法での）メンバー実体のグループによって形成され、複数の実体のルートＣＡシステムを確立してよい。１つの例では、ルートＣＡコンソーシアムは、政府機関によって主導されてよい。別の例では、ＣＡは、コンソーシアムを形成する同じ産業（例えば、自動車産業、銀行業界など）からのさまざまな製造業者またはサービスプロバイダ（例えば、競合するブランド）であってよい。場合によっては、コンソーシアムのメンバーは、例えば、さまざまな認証システムを有することがある異なる国での携帯電話の使用を可能にするために、さまざまな国の実体を含む。複数の実体のルートＣＡシステムを含むことによって、責任を負う単一のルートＣＡが存在しないため、これらおよび他の種類の認証の状況において解決策を提供することができる。さらに、新しい企業（または他の種類の実体）が確立されることがあり、既存の企業がビジネスをやめることがあり、これらが、コンソーシアムのメンバーシップに影響を与えることがある。このような状況も、静的ではなく、メンバーシップにおける変化と共に発達し得る複数の実体のルートＣＡシステムによって、対処される。
一部の実装では、検証実体は、秘密鍵または対称鍵などの秘密情報を必要とする、どのような動作も実行しない。したがって、機密情報または秘密情報を漏洩するリスクがない。加えて、検証実体が実行する動作は、ルートＣＡコンソーシアムの、データブロックチェーンの動作に参加できる任意のメンバー、またはデータブロックチェーンを読み取ることのみが可能な加入者が同じ動作を実行できるという意味で、透明であることができる。この透明性は、改ざんの証拠を提供し、検証実体のセキュリティ侵害を非常に難しくする。すべてのメンバーによって、ジェネシスブロックを含んでいるデータブロックチェーンのコピーが維持されるため、データブロックチェーン内の署名を検証し、ブロックチェーンのコピーを他のメンバーと比較することによって、正常に動作していないか、または成り済ましている検証実体が、容易に捕らえられ得る。
複数の実体のルートＣＡシステムのジェネシスブロックを構築する場合、図３Ｃに示されているように、データエントリ配列（すなわち、ジェネシスデータブロック）を形成するために、各創設メンバーからジェネシスブロックデータエントリが収集され得る。次に、この配列が、１つまたは複数のデジタル署名と連結される。したがって、ジェネシスブロックは、ジェネシスブロックデータエントリを含んでいるデータエントリ配列、およびコンソーシアムメンバーの複数のデジタル署名という構成要素で作られ得る。図３Ｄは、複数の実体のルート証明書データブロックチェーンの例示的なジェネシスブロック３５０の図である。場合によっては、別の種類のジェネシスブロックが使用されてよい。
複数の実体のルートＣＡシステムにおいて連結されたブロック（例えば、アクションブロック）を構築するときに、１つまたは複数のアクションブロックデータエントリが収集され得る。次に、前の／既存のブロックのハッシュが、１つまたは複数のアクションブロックデータエントリと連結される。その後、連結されたデータが、１つまたは複数のデジタル署名とさらに連結される。したがって、連結されたブロックは、データエントリまたはデータエントリの配列、前のブロックのハッシュ、およびコンソーシアムメンバーの１つまたは複数のデジタル署名という構成要素で作られ得る。図４Ｄおよび５Ｄは、複数の実体のルート証明書データブロックチェーンのブロックの例示的なチェーンの図を示している。
図２Ａは、複数の実体のルート証明書データブロックチェーンのジェネシスブロックに関する例示的な署名プロセス２００の図である。例示的な署名プロセス２００は、図２Ａに示されている検証実体２０４、および複数の創設メンバー実体（例えば、創設メンバー２０２－１、２０２－２、２０２－３、２０２－４、および２０２－ｎ）を含んでいるルートＣＡコンソーシアムによって実行される。図２Ａに示された例では、複数の実体のルート証明書データブロックチェーンを作成する時点で、創設メンバー実体がルートＣＡコンソーシアムを形成する。一部の例では、検証実体２０４は、創設メンバーとして、または独立したノードとして実装されてよい。場合によっては、伝達される内容に秘密情報が必ずしも存在しないため、創設メンバー２０２の各々と検証実体２０４の間で通信するために、オープンなパブリックチャネル２０６が使用されてよい。
一部の例では、検証実体２０４は、図３Ａ～３Ｄに示されているように、創設メンバー２０２からデータエントリを受信し、創設メンバー２０２の署名を検証し、ジェネシスデータブロックを生成して創設メンバーに送信し、創設メンバーからジェネシスデータブロックに対する署名を受信し、暗号システム内で１つまたは複数の末端実体によってルート証明書データブロックチェーンとして使用するために、ジェネシスブロックを生成する。検証実体２０４は、追加の動作または異なる動作を実行してよい。
図２Ｂは、複数の実体のルート証明書データブロックチェーンのアクションブロックに関する例示的な署名プロセス２１０の図である。例示的な署名プロセス２００は、検証実体２０４、および複数のメンバーを含んでいるルートＣＡコンソーシアムによって実行される。図２Ｂに示された例では、アクションブロックを追加する時点でのルートＣＡコンソーシアムは、メンバー２０８－１、２０８－２、２０８－３、２０８－４、および２０８－ｎを含んでいる。図２Ｂに示された例では、メンバー（２０８－１、．．．２０８－ｎ）のうちの１つまたは複数は、図２Ａからの創設メンバー（２０２－１、．．．２０２－ｎ）でもある。
一部の例では、検証実体２０４は、図４Ａ～４Ｄに示されているように、要求している実体からデータエントリを受信し、要求している実体の署名の妥当性を確認し、アクションブロックを生成する。要求している実体は、現在の有効なメンバー、または複数の実体のルートＣＡコンソーシアム２００に参加することを望んでいる新しい実体のうちの１つであってよい。例えば、検証実体２０４が、対応する秘密鍵の所有を証明するために、要求者の署名を必要とするため、（「新規」、「更新」、「置き換え」、または「追加」のアクションタイプに対応してよい）新しい公開鍵を追加するときに、要求している実体が必要とされることがある。一部の例では、図５Ａ～５Ｄに示されているように、要求している実体が存在せず、検証実体２０４がアクションブロックを生成する。
図３Ａは、例示的なジェネシスブロック作成プロセス３００の態様を示すフロー図である。一部の実装では、ジェネシスブロック作成プロセス３００は、創設メンバー３０２－１、．．．３０２－ｎ（例えば、前述のコンソーシアム内の実体）と検証実体３０４の間のデータの伝達を含む。図３Ａに示された例では、創設メンバー実体がルートＣＡコンソーシアムを形成する。場合によっては、伝達される内容に秘密情報が必ずしも存在しないため、この情報を伝達するために、オープンなパブリックチャネルが使用されてよい。一部の例では、検証実体３０４は、創設メンバーとして、または独立したノードとして実装されてよい。ジェネシスブロック作成プロセス３００は、図３Ａに示された順序で、または別の順序で、あるいは場合によっては、直列または並列に、実行されてよい。
一部の状況では、コンソーシアムの創設メンバー３０２のうちの１つが、ジェネシスブロックを作成するプロセスを実行するための検証実体３０４として識別され得る。例えば、創設メンバー３０２は、集まり、検証実体３０４としての役割を果たすジェネシスブロック作成タスクをメンバーのうちの１つに委任することに同意してよい。一部の状況では、（コンソーシアム創設メンバー３０２から独立している）独立した実体が、ジェネシスブロックを作成するプロセスを実行するための検証実体３０４として識別され得る。例えば、創設メンバー３０２は、集まり、検証実体３０４としての役割を果たすジェネシスブロック作成タスクを、独立した外部の実体に委任することに同意してよい。
図３Ａに示された例では、検証実体３０４が、コンソーシアムメンバー（創設メンバー３０２）からデータエントリを受信し、署名を検証し、ジェネシスブロックを組み立てる。さらに、検証実体３０４は、結果として得られたジェネシスブロックを、創設メンバー３０２のすべてに公開する。
３１０で、検証実体３０４が、創設メンバー３０４が、創設メンバー３０２－１、．．．３０２－ｎからデータエントリを受信する。図３Ｂは、メンバー実体から受信された例示的なデータエントリ３３０の図である。図３Ｂに示された例では、対応する創設メンバー３０２から受信されたデータエントリ３３０が、ジェネシスブロックデータエントリ３３２および対応する創設メンバーの署名（Ｓｉｇｎａｔｕｒｅ１＿ＦＭ）を含んでいる。例示的なジェネシスブロックデータエントリ３３２は、対応する創設メンバーの識別情報（ＩＤ＿ＦＭ）および公開鍵（Ｐｕｂｌｉｃ＿ｋｅｙ＿ＦＭ）を含んでいる。
一部の例では、ＩＤデータフィールド（ＩＤ＿ＦＭ）は、創設メンバー３０２に関する識別情報を含む。公開鍵データフィールド（Ｐｕｂｌｉｃ＿ｋｅｙ＿ＦＭ）は、例えば、公開鍵が属しているドメインパラメータ含む暗号システム、公開鍵、および場合によっては、有効期限の時間または時間の他の表現（例えば、持続時間）を含んでよい、有効期限などの構成要素を含んでいる、データ構造を有してよい。デジタル署名データフィールド（Ｓｉｇｎａｔｕｒｅ１＿ＦＭ）は、例えば、署名者の識別情報、署名が生成されたドメインパラメータ含む暗号システム、デジタル署名、およびタイムスタンプなどの、構成要素を含んでよい。
３１２で、検証実体３０４が、創設メンバー３０２から受信されたデータエントリ内の署名を検証する。検証実体３０４は、創設メンバー３０２によって署名されるジェネシスデータブロックを構築する前に、ジェネシスブロックデータエントリ３３２の各々に含まれる署名の妥当性を確認する。一部の例では、検証実体３０４は、署名検証アルゴリズムに基づいて署名を検証する。一部の例では、署名を生成するために使用されるデジタル署名アルゴリズムに対応する署名検証アルゴリズムは、実体の公開鍵を使用する。署名を検証できない場合（例えば、検証が失敗した場合）、形成時に、ジェネシスデータブロックエントリがジェネシスデータブロックから除外されてよい。
３１４で、検証実体３０４がジェネシスデータブロックを形成する。創設メンバー３０２のすべての署名の検証後に、検証実体３０４は、ジェネシスブロックデータエントリの配列を含み得るジェネシスデータブロックを形成する。図３Ｃは、ジェネシスブロックデータエントリに基づいて検証実体によって作成された例示的なジェネシスデータブロック３４０の図である。図３Ｃに示された例では、創設メンバーごとのジェネシスブロックデータエントリ３４２Ａ、３４２Ｂ、．．．３４２Ｃが連結されて、ジェネシスブロックデータエントリ３４２Ａ、３４２Ｂ、．．．３４２Ｃの配列を含んでいるジェネシスデータブロック３４０を形成する。
図３Ｃに示された例では、各ジェネシスブロックデータエントリ３４２Ａ、３４２Ｂ、３４２Ｃは、ジェネシスブロックデータエントリによって表された創設メンバーの公開鍵を含んでいる。例えば、ジェネシスブロックデータエントリ３４２Ａは、ＦＭ＿０を表し、ＦＭ＿０の公開鍵（「Ｐｕｂｌｉｃ＿Ｋｅｙ＿ＦＭ＿０」）を含み、ジェネシスブロックデータエントリ２４２Ｂは、ＦＭ＿１を表し、ＦＭ＿１の公開鍵（「Ｐｕｂｌｉｃ＿Ｋｅｙ＿ＦＭ＿１」）を含む、などとなる。公開鍵は、例えば、暗号システムにおいて使用するために（例えば、暗号システムによって指定された鍵生成方法に従って）生成された公開鍵と秘密鍵の対の公開鍵であることができる。
３１６で、検証実体３０４が、ジェネシスデータブロック３４０を創設メンバー３０２に配信する。動作の一部の態様では、ジェネシスデータブロック３４０が、創設メンバー３０２のサブセット（例えば、１つ、一部、またはすべて）に送信されてよい。一部の実装では、検証実体３０４からジェネシスデータブロック３４０を受信した後に、創設メンバー３０２の各々が、ジェネシスデータブロック３４０にデジタル署名する。一部の実装では、創設メンバーのサブセットは、ジェネシスデータブロック３４０にデジタル署名する。一部の例では、デジタル署名は、対応する創設メンバーの秘密鍵を使用して生成され得る。一部の実装では、デジタル署名は、署名する実体の秘密鍵および署名されるメッセージを含んでいる入力（例えば、図３Ｃに示されているようなジェネシスデータブロック３４０）に対して動作するデジタル署名アルゴリズムによって生成される。デジタル署名は、任意の適切なデジタル署名アルゴリズム（例えば、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ、格子に基づくデジタル署名アルゴリズム、ハッシュに基づくデジタル署名アルゴリズム、多変量デジタル署名アルゴリズムなど）に従って生成されてよい。
図３Ａに示された例示的なプロセス３００では、検証実体３０４が、（３１６で）ジェネシスデータブロックが配信される前に、創設メンバーがセキュリティを侵害されたということを学習した場合、検証実体３０４は、ジェネシスデータブロック３４０が署名のために他の創設メンバー３０２に送信される前に、セキュリティを侵害された創設メンバーのジェネシスブロックデータエントリ３３２をジェネシスデータブロック３４０から除去してよい。
３１８で、検証実体３０４が、創設メンバー３０２から署名を受信する。この例では、３１８で受信された署名は、創設メンバー３０２からの署名の第２のセットである。一部の例では、検証実体３０４は、任意に、創設メンバー３０２から受信された第２の署名を検証してよい。一部の例では、対応する創設メンバーの第２の署名を検証するために、対応する創設メンバーの公開鍵が使用される。一部の例では、検証実体３０４は、署名検証アルゴリズムに基づいて署名を検証する。署名検証アルゴリズムは、署名を生成するために使用されるデジタル署名アルゴリズムに対応してよく、実体の公開鍵を使用する。署名を検証できない場合（例えば、検証が失敗した場合）、プロセスが中断されてよい。一部の例では、第２の署名の署名検証プロセスが省略されてよい。
３２０で、検証実体３０４がジェネシスブロックを形成する。図３Ｄは、図３Ｃに示されたジェネシスデータブロック３４０に基づいて検証実体によって作成された例示的なジェネシスブロック３５０の図である。検証実体３０４によって、創設メンバーの署名（Ｓｉｇｎａｔｕｒｅ２＿ＦＭ＿１、Ｓｉｇｎａｔｕｒｅ２＿ＦＭ＿２など）の第２のセットが、結合されてから、ジェネシスデータブロック３４０と連結され、ジェネシスブロック３５０を形成する。
３２２で、検証実体３０４が、ジェネシスブロックを創設メンバー３０２に公開する。場合によっては、ジェネシスブロックが作成された後に、ジェネシスブロックを含んでいるデータブロックチェーンが、１つまたは複数の末端実体によって暗号システム内のルート証明書データブロックチェーンとして使用するために提供される。一部の実装では、ジェネシスブロック３５０は、創設メンバー３０２、末端実体、またはその両方によって格納されてよい。
ジェネシスブロックが作成された後も、３２２の後に、チェーン内の追加のデータブロックが構築されてよい。複数の実体のルートＣＡコンソーシアムのメンバーの有効な識別情報および公開鍵は、ジェネシスブロックから生じるブロックのチェーンによって表されることが可能であり、複数の実体のルートＣＡコンソーシアムに対する任意の変更（例えば、コンソーシアム内のメンバーの追加または削除）が、連結されたブロックによって記録される。図４Ａおよび５Ａに示された例では、単一のブロックが、チェーンの前のブロックに一度に追加され、単一のスレッドチェーンを作成する。例えば、ブロックのチェーンは、追加専用のチェーンとして展開されることが可能であり、チェーンからのブロックの除去は許可されない。これは、ブロックが発生順に連結され、最後のブロックが最新であるということを意味する。したがって、ルートＣＡコンソーシアムに属していると主張するメンバーによる署名を検証するために、最後のブロックからチェーンをたどって、このメンバーの識別情報の最初の（例えば、最新の）出現を見つけ、メンバーＣＡの妥当性を決定すること、このメンバーが有効である場合、有効な公開鍵を見つけること、およびこの公開鍵を使用して署名の妥当性を確認することができる。
図３Ａに示された例示的なプロセス３００を使用してジェネシスブロックを作成すると、この作成プロセスの速度が改善され得る。検証実体３０４と各創設メンバー３０２の間のハンドシェイク／通信は独立しており、検証実体３０４で、３１４でジェネシスデータブロック３４０が生成されるとき、および３２０でジェネシスブロック３５０が生成されるときの２回、同期が発生する。図３Ａに示された例示的なプロセス３００の他のステップは、並列に実行され得る。例えば、創設メンバー３０２のデータエントリは、検証実体３０４によって創設メンバー３０２から並列に受信されてよい。この例では、創設メンバーと検証実体の間のデータハンドシェイクごとの帯域幅の消費量は、図３Ｂに示されているように、ＩＤ、公開鍵、および署名を含んでいるデータエントリ３３０のサイズに制限され得る。したがって、帯域幅の全消費量は、創設メンバーの数と共に直線的に増加し、帯域幅の増加はスケーラブルであることができる。
図４Ａは、アクションブロックを作成するための例示的なプロセス４００の態様を示すフロー図である。一部の実装では、アクションブロックを形成するためのプロセス４００は、ルートＣＡコンソーシアムの有効なメンバー４０６－１、．．．、４０６－ｎ、検証実体４０４、および要求している実体４０２の間のデータの伝達を含む。有効なメンバー４０６－１、．．．、４０６－ｎは、創設メンバーのうちの１つまたは複数、ルート証明書データブロックチェーンが作成された後に追加された１つまたは複数の他のメンバー、またはこれらの組み合わせを含んでよい。一部の例では（例えば、アクションタイプが「更新」、「置き換え」、または「追加」である場合）、要求している実体４０２は、ルートＣＡコンソーシアムのメンバー（例えば、創設メンバーまたはルート証明書データブロックチェーンが作成された後に追加された別のメンバー）である。一部の例では（例えば、アクションタイプが「新規」である場合）、要求している実体４０２は、ルートＣＡコンソーシアムのメンバーではなく、ルートＣＡコンソーシアムに参加することを望んでいる。場合によっては、伝達される内容に秘密情報が必ずしも存在しないため、この情報を伝達するために、オープンなパブリックチャネルが使用されてよい。一部の例では、検証実体４０４は、ルートＣＡコンソーシアムのメンバーとして、または独立したノードとして実装されてよい。プロセス４００は、図４Ａに示された順序で、または別の順序で、あるいは場合によっては、直列または並列に、実行されてよい。
図４Ａに示された例では、検証実体４０４が、要求している実体４０２からデータエントリを受信し、要求している実体４０２の署名を検証し、前のブロックのハッシュを取得し、アクションブロックを生成するために使用されるアクションデータブロックを組み立て、アクションブロックを完成させる。さらに、検証実体４０２は、結果として得られたアクションブロックを、コンソーシアムのメンバー４０６および要求している実体４０２と共有する。
一部の実装では、要求している実体４０２は、例えば、公開鍵の追加または更新などの、特定のアクションを実行する必要があるコンソーシアムのメンバーのうちの１つであってよい。一部の他の実装では、要求している実体４０２は、ルートＣＡコンソーシアムに追加される新しいメンバーであってよい。
一部の実装では、新しいブロック（例えば、アクションブロック）が追加されるたびに、（例えば、ハッシュ関数を直近に追加されたブロックに適用することによって）チェーンの前のブロックのハッシュが取得され、新しいデータエントリが、関連する情報を使用してルートＣＡコンソーシアムに関する情報を更新するために必要とされるアクションを識別するように、新しいデータエントリを含んでいる新しいデータブロックが生成され、新しいデータブロックエントリおよび前のブロックのハッシュの組み合わせ（例えば、連結）にデジタル署名することによって、新しいブロックが完成する。デジタル署名は、複数のメンバーによって生成されてよい。次に、検証実体４０４によって、新しいブロックがルートＣＡコンソーシアム４０６の一部またはすべてのメンバーに公開される。
４１０で、検証実体４０４が、要求している実体４０２からデータエントリを収集する。一部の例では、要求している実体が既存のメンバーである場合、検証実体４０４に報告された要求している実体４０２からのデータエントリが、例えば、公開鍵の更新、置き換え、または追加などのアクションのためのデータを含んでよい。一部の例では、要求している実体４０２が既存のメンバーでない場合、検証実体４０４に報告された要求している実体４０２からのデータエントリが、例えば、新しいメンバーの追加などのアクションのためのデータを含んでよい。一部の例では、新しい公開鍵を持っている要求している実体４０２は、例えば、証明書署名要求規格（ＩＥＴＦ ＲＦＣ ２９８６ ＰＫＣＳ ＃１０）で説明されている方法と同様の方法で、対応する秘密鍵の所有を証明するために、デジタル署名を提示する。
図４Ｂに示された例では、要求している実体４０２（Ｄａｔａ Ｅｎｔｒｙ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）から受信された例示的なデータエントリ４３０が、アクションブロックデータエントリ４３２および要求している実体４０２のデジタル署名４３４（Ｓｉｇｎａｔｕｒｅ＿Ｒｅｑ＿ｅｎｔｉｔｙ）を含んでいる。アクションブロックデータエントリ４３２は、アクションタイプ識別子、要求している実体４０２の識別情報（ＩＤ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）、および要求している実体４０２の公開鍵（Ｐｕｂｌｉｃ＿ｋｅｙ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）を含んでいる。図４Ｂに示された例では、アクションデータブロック４３２が、新しいメンバーがルートＣＡコンソーシアムに追加されていることを示すアクションタイプ識別子（例えば、「新規」）、または別の種類のアクションブロック識別子を含んでよい。
一部の例では、ＩＤデータフィールド（ＩＤ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）は、要求している実体４０２に関する識別情報を含む。公開鍵データフィールド（Ｐｕｂｌｉｃ＿ｋｅｙ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）は、例えば、公開鍵が属しているドメインパラメータ含む暗号システム、公開鍵、および場合によっては、有効期限の時間または時間の他の表現（例えば、持続時間）を含んでよい、有効期限などの構成要素を含んでいる、データ構造を有してよい。デジタル署名データフィールド（Ｓｉｇｎａｔｕｒｅ＿Ｒｅｑ＿ｅｎｔｉｔｙ）は、例えば、署名者の識別情報、署名が生成されたドメインパラメータ含む暗号システム、デジタル署名、およびタイムスタンプなどの、構成要素を含んでよい。
４１２で、検証実体４０４が、要求している実体４０２の署名を検証する。一部の例では、署名を検証するために、要求している実体４０２の公開鍵が使用されてよい。一部の例では、検証実体４０４は、署名妥当性確認アルゴリズムに基づいて署名を検証する。一部の例では、署名を生成するために使用されるデジタル署名アルゴリズムに対応する署名検証アルゴリズムは、実体の公開鍵を使用する。
４１４で、検証実体４０４がアクションデータブロックを形成する。図４Ｃは、図４Ｂのアクションブロックデータエントリ４３０に基づいて検証実体によって作成された例示的なアクションデータブロック４４０の図である。例示的なアクションデータブロック４４０は、アクションブロックデータエントリ４３２からのデータ（アクションタイプ識別子、要求している実体４０２の識別情報（ＩＤ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）、および要求している実体４０２の公開鍵（Ｐｕｂｌｉｃ＿ｋｅｙ＿Ｒｅｑ＿Ｅｎｔｉｔｙ））を含んでいる。例示的なアクションデータブロック４４０は、ブロックチェーンからの前のブロックのハッシュも含んでいる。前のブロックのハッシュは、Ｈａｓｈ（前のブロック）を計算することによって生成される。ここで、Ｈａｓｈ（・）は、暗号ハッシュ関数を入力値（例えば、「既存のブロック」）に適用することによって生成された出力ハッシュ値を表す。一部の実装では、ＳＨＡ－２ファミリー（例えば、ＳＨＡ－２５６、ＳＨＡ－５１２）またはＳＨＡ－３ファミリー内の１つまたは複数の従来のハッシュ関数が使用され得る。別のハッシュ関数が使用されてよい。
チェーンの新しいアクションデータブロックを形成するプロセスでは、既存のブロックのハッシュおよび新しいデータブロックのデジタル署名が生成され、このデジタル署名が、新しいアクションデータブロックエントリおよび前のブロックのハッシュに追加される。４１６で、検証実体４０４が、アクションデータブロックをルートＣＡコンソーシアムのメンバー４０６に配信する。動作の一部の態様では、アクションデータブロック４４０が、ルートＣＡコンソーシアムのメンバー４０６のサブセット（すなわち、１つ、一部、またはすべて）に送信される。一部の実装では、検証実体４０４からアクションデータブロック４４０を受信した後に、メンバー４０６の各々が、アクションデータブロックにデジタル署名する。一部の例では、デジタル署名は、対応するメンバーの秘密鍵を使用して生成され得る。一部の実装では、デジタル署名は、署名する実体の秘密鍵および署名されるメッセージを含んでいる入力（例えば、図４Ｃに示されているようなアクションデータブロック４４０）に対して動作するデジタル署名アルゴリズムによって生成される。デジタル署名は、任意の適切なデジタル署名アルゴリズム（例えば、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ、格子に基づくデジタル署名アルゴリズム、ハッシュに基づくデジタル署名アルゴリズム、多変量署名アルゴリズムなど）に従って生成されてよい。
４１８で、検証実体４０４が、ルートＣＡコンソーシアムのメンバー４０６からデジタル署名を受信する。一部の例では、検証実体４０４は、任意に、メンバー４０６から受信されたデジタル署名を検証してよい。一部の例では、検証実体４０４は、署名検証アルゴリズムに基づいて署名を検証する。一部の例では、署名を生成するために使用されるデジタル署名アルゴリズムに対応する署名検証アルゴリズムは、実体の公開鍵を使用する。一部の例では、デジタル署名のこの妥当性確認プロセスが省略されてよい。
４２０で、検証実体４０４がアクションブロックを生成する。図４Ｄは、図４Ｃのアクションデータブロック４４０に基づいて検証実体によって作成された例示的なアクションブロック４５０の図である。図４Ｄに示されているように、新しいアクションブロック４５０を形成するために、検証実体が、アクションデータブロック４４０をルートＣＡコンソーシアムのメンバーのデジタル署名（Ｓｉｇｎａｔｕｒｅ＿Ｍ＿１、Ｓｉｇｎａｔｕｒｅ＿Ｍ＿２、．．．Ｓｉｇｎａｔｕｒｅ＿Ｍ＿ｎ）と結合する。
４２２で、検証実体４０４が、アクションブロックを、ルートＣＡコンソーシアムのメンバー４０６、および現在ルートＣＡコンソーシアムに属している要求している実体４０２に公開する。場合によっては、アクションブロックが作成された後に、アクションブロックを含んでいるデータブロックチェーンが、１つまたは複数の末端実体によって暗号システム内のルート証明書データブロックチェーンとして使用するために提供される。一部の実装では、アクションブロックは、メンバー、末端実体、またはその両方によって格納されてよい。
図４Ａに示された例では、検証実体４０４は、（例えば、今回の）ブロックを連結するプロセスに先行するように構成される。連結されたブロックを作成するためのこの検証実体４０４は、図３Ａに示されたようなジェネシスブロック作成プロセスにおいて使用される検証実体３０４と同じであるか、または異なってよい。また、場合によっては、異なるブロックに対して異なる検証実体が選択されてよい。これは、例えば、メンバーがルートＣＡコンソーシアムから除去される場合、または他の状況において、重要になることがある。一部の実装では、ブロックを構築するためのすべての通信が、オープンなパブリックチャネルを経由して実行されてよい。
図４Ａに示された例示的なプロセス４００を使用してブロックを連結すると、アクションブロックを追加する速度が改善され得る。検証実体４０４とルートＣＡコンソーシアムのメンバー４０６の各々の間の通信は、独立しており、並列に実行され得る。例えば、４１６でのメンバー４０６へのアクションデータブロックの配信および４１８でのメンバー４０６のデジタル署名の受信は、並列に実行されてよい。
図４Ａ～４Ｄのデータエントリ内で識別され得る可能なアクションタイプ（および関連するアクションタイプ識別子）は、メンバーを追加すること（「新規」）、公開鍵を更新すること（「更新」）、取り消し後に公開鍵を置き換えること（「置き換え」）、公開鍵を追加すること（「追加」）、および場合によっては他のアクションタイプを含む。
図５Ａは、新しいブロックを既存のブロックのチェーンに追加することによってアクションブロックを作成するための例示的なプロセス５００の態様を示すフロー図である。例示的なプロセス５００は、ルートＣＡコンソーシアムの有効なメンバー５０２－１、．．．５０２－ｎ（例えば、前述のルートＣＡコンソーシアム内の実体）および検証実体５０４によって実行される。有効なメンバー５０２－１、．．．５０２－ｎは、創設メンバーのうちの１つまたは複数、ルート証明書データブロックチェーンが作成された後に追加された１つまたは複数の他のメンバー、またはこれらの組み合わせを含んでよい。場合によっては、プロセス５００の間に、実体間で伝達される情報は、必ずしも秘密情報を含まず、この情報を伝達するために、オープンなパブリックチャネルが使用されてよい。一部の例では、検証実体５０４は、メンバーとして、または独立したノードとして実装されてよい。プロセス５００は、図５Ａに示された順序で、または別の順序で、あるいは場合によっては、直列または並列に、実行されてよい。
図５Ａに示された例では、検証実体５０４が、アクションデータブロックをメンバー５０２に配信し、既存のブロックのハッシュを取得し、アクションデータブロックに対する署名をメンバー５０２から受信し、アクションブロックを生成する。さらに、結果として得られたアクションブロックは、検証実体５０４によってメンバー５０２に公開される。
５１０で、検証実体５０４が、アクションデータブロックをルートＣＡコンソーシアムのメンバーに配信する。アクションデータブロックは、アクションブロックデータエントリに基づく。図５Ｂに示された例では、データエントリ５２０がアクションブロックデータエントリ５２２を含んでいる。アクションブロックデータエントリ５２２は、アクションタイプ識別子およびアクションタイプに関連付けられたデータを含んでいる。アクションタイプ識別子は、複数の実体のルート証明書データブロックチェーンに対する、ルートＣＡコンソーシアムによって要求されたアクションを指定する。図５Ｃは、図５Ｂのアクションブロックデータエントリ５２２に基づいて検証実体によって作成された例示的なアクションデータブロック５３０の図である。例示的なアクションデータブロック５３０は、アクションタイプ識別子に追加されたハッシュ、およびアクションブロックデータエントリ５２２からのアクションタイプに関連付けられたデータを含んでいる。
図５Ａ～５Ｄのデータエントリ内で識別され得る可能なアクションタイプ（および関連するアクションタイプ識別子）は、メンバーを除去すること（「除去」）、公開鍵を取り消すこと（「取り消し」）、古い公開鍵をキャンセルすること（「キャンセル」）、タイムスタンプ（「タイムスタンプ」）、既知のステータス（「ステータス）、フリーズ（「フリーズ」）、フリーズ解除（「フリーズ解除」）、および場合によっては他のアクションタイプを含む。
場合によっては、他の種類のアクションが定義され、利用されてよい。ここで、上に示されたアクションタイプが定義されて利用され得る方法の例が説明される。これらおよび他のアクションタイプは、別の方法で実装されてよい。
「新規」のアクションは、新しいメンバーを追加するために使用される。例えば、このアクションは、このメンバーがルートＣＡコンソーシアムに存在していなかったことを示す。したがって、新しい識別情報が、それに関連する公開鍵と共に、データエントリ内に出現する。
「除去」のアクションは、メンバーをルートＣＡコンソーシアムから除去するために使用される。このアクションは、単に秘密鍵がセキュリティを侵害されたということではなく、メンバーが行動していないということを示すため、公開鍵を取り消すアクションより強力である。この場合、公開鍵の必要性は存在せず、不正を行っているメンバーの識別情報を含むことで十分である。
「更新」のアクションは、公開鍵の期限が切れようとしているときに使用される。したがって、このアクションは、古い公開鍵の期限が切れるまで、同じセキュリティ強度を有する同じ暗号システムの２つの公開鍵が識別情報のために共存する猶予期間を可能にする。更新された公開鍵は、データエントリ内で指定され得る。
「置き換え」のアクションは、公開鍵が取り消されたときに使用される。取り消された公開鍵の所有者は、取り消された公開鍵を代替の公開鍵に置き換えることができる。代替の公開鍵は、データエントリ内で指定され得る。
「取り消し」のアクションは、公開鍵の即時の無効化を引き起こす。取り消された公開鍵は、データエントリ内で指定される。公開鍵が取り消された後に、この公開鍵の所有者は、「置き換え」アクションによって再び有効にされてよい。
「追加」のアクションは、既存の識別情報のために、第２の公開鍵を追加することを可能にし、例えば、メンバーが２つの有効な公開鍵を同時に所有する状況を引き起こす。このアクションは、第２の公開鍵が異なる暗号システムに属するか、または同じ暗号システムに属するが、異なるセキュリティ強度を有するという移行の状況において役立つことができる。第２の公開鍵は、システムの移行先の新しい暗号システム、またはセキュリティ強度、あるいはその両方のためのものである。
「追加」アクションによって開始された移行における古い公開鍵は、「キャンセル」アクションによって無効にされ得る。一部の実装では、「取り消し」は、この「キャンセル」アクションを示すために使用されてよい。
「タイムスタンプ」アクションは、チェーンが最新であり、公開された日時に正しかったことを示すために使用されてよい。コンソーシアムは、「タイムスタンプ」ブロックを公開するための適切な間隔を自由に選択できる。一部の実装では、公開されたチェーン内の最近の「タイムスタンプ」ブロックの不在は、クライアントによって、チェーンの最新のブロックが保留されたか、または公開されなかったことの指示として解釈され得る。
「ステータス」アクションは、現在有効なすべての識別情報の要約を記録するために使用されてよい。そのようなブロックは、前のブロックから計算できる情報を含むため、冗長であってよい。「ステータス」ブロックは、中間ジェネシスブロックと見なされ得る。消費者（特に、制約されたデバイス上の消費者）は、ステータスブロックの妥当性を、受信時に通常どおり確認することができる。未来のチェーンの妥当性確認は、チェーンの現在の末尾から、すでに妥当性が確認されたステータスブロックまで作業し、信用を検証するために必要とされる作業の削減を可能にする。完全な妥当性確認が望ましい場合、チェーン全体が依然として使用可能である。
「フリーズ」アクションは任意選択的である。このアクションは、特定の時間の間、新しいブロックが更新されないということ、すなわち、アクションが実行されないということを示す。したがって、このアクションブロックは、フリーズされる期間の、期間または期限切れ時間を関連付けなければならない。この時間は、メンバーがブロックのチェーンを同期させることを可能にするために使用されてよい。また、任意に、時間が指定されず、ブロックのチェーンが無期限にフリーズされるということを示してよい。これは、例えば、チェーンを終了するために使用され得る。
「フリーズ解除」アクションは任意選択的である。このアクションは、「フリーズ」アクションの偶然の使用または悪意のある使用が検出された場合にのみ使用される。このアクションは、そのような「フリーズ」アクションを取り消すことができる。
一部の実装では、メンバーおよび公開鍵を管理するために上で導入されたアクションタイプは、新しい暗号システムに移行するための機能を提供し、暗号の敏しょう性を実現する。例えば、古い公開鍵アルゴリズムから新しい公開鍵アルゴリズムへの移行が必要とされる場合、これらのアクションタイプは、移行期間を作り出す、新しい識別情報のための第２の公開鍵の高速な追加、および移行が完了したときに、古い公開鍵を後で取り消すための定義された方法を可能にする。
一部の実装では、各データエントリに対するデジタル署名に加えて、複数の実体のルート証明書データブロックチェーン内のブロック全体に対するデジタル署名が存在することが許可される。単一障害点を回避するために、複数の実体のルート証明書データブロックチェーン内の２つ以上のメンバーからのデジタル署名によって、各データエントリが保護されることが保証されてよく、そうしないと、１つのメンバーのセキュリティ侵害が、ルート証明書データを変更する可能性がある。
場合によっては、複数の実体のルート証明書データブロックチェーンは階層構造を許可し、下位レベルの構造は自由である。例えば、複数の実体のルート証明書データブロックチェーンの下のレベルは、ＰＫＩサブシステムではなく、ブロックの別のチェーンであることができ、またはこれらの混合であってよい。このシステムは、ＰＫＩサブシステムおよびブロックのチェーンの層の混合を可能にする。場合によっては、複数の実体のルート証明書データブロックチェーンは、サブシステムを含まずに展開され得る。例えば、システムは完全に平坦であってよく、その場合、ルートＣＡコンソーシアム内のメンバーは、ＣＡではなく末端実体である。
図５Ｃに示されているように、例示的なアクションデータブロック５３０は、ブロックチェーンの既存のブロックのハッシュを含んでいる。この例では、アクションタイプ識別子および関連する情報フィールドが、ブロックチェーンの前のブロックのハッシュと結合されて（例えば、連結されて）、アクションデータブロック５３０を形成する。
５１２で、検証実体５０４が、ルートＣＡコンソーシアムのメンバー５０２のデジタル署名を受信する。デジタル署名は、アクションブロックデータエントリ、アクションデータブロック全体、またはその両方に対して生成されてよい。デジタル署名は、対応するメンバーの秘密鍵を使用して生成され得る。一部の実装では、デジタル署名は、署名する実体の秘密鍵および署名されるメッセージを含んでいる入力（例えば、図５Ｃに示されているようなアクションデータブロック５３０）に対して動作するデジタル署名アルゴリズムによって生成される。デジタル署名は、任意の適切なデジタル署名アルゴリズム（例えば、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ、格子に基づくデジタル署名アルゴリズム、ハッシュに基づくデジタル署名アルゴリズム、多変量署名アルゴリズムなど）に従って生成されてよい。
５１４で、検証実体５０４がアクションブロックを生成する。メンバー（またはメンバーのサブセット）から受信されたデジタル署名は、結合され、アクションデータブロックに追加されて、アクションブロック（ブロックチェーンの新しいブロック）を形成することができる。図５Ｄは、図５Ｃのアクションデータブロック５３０に基づいて検証実体によって作成された例示的なアクションブロック５４０の図である。図５Ｄに示された例では、アクションブロック５４０は、アクションデータブロック５３０（アクションタイプ識別子、および関連する情報フィールド、ならびに前のブロックのハッシュを含んでいる）に追加された、メンバー５０２のデジタル署名（「Ｓｉｇｎａｔｕｒｅ＿Ｍ＿１」、「Ｓｉｇｎａｔｕｒｅ＿Ｍ＿２」．．．「Ｓｉｇｎａｔｕｒｅ＿Ｍ＿ｎ」）を含んでいる。場合によっては、ブロックに対する必要とされる署名の最小数は、特定のネットワークのメンバーにおける信用のレベルに依存する。
５１６で、検証実体５０４が、アクションブロックをルートＣＡコンソーシアムのメンバー５０２に公開する。場合によっては、アクションブロックが作成された後に、アクションブロックを含んでいるデータブロックチェーンが、１つまたは複数の末端実体によって暗号システム内のルート証明書データブロックチェーンとして使用するために提供される。一部の実装では、アクションブロックは、メンバー、末端実体、またはその両方によって格納されてよい。
本明細書において説明された動作の一部は、コンピュータ可読命令（例えば、コンピュータプログラム）を実行するコンピュータシステムまたはデータ処理装置によって実行される動作として実装され得る。
図６は、データ処理装置および１つまたは複数のコンピュータ可読ストレージデバイスを含むコンピュータシステム６００の例を示しているブロック図である。「データ処理装置」という用語は、例えば、プログラマブルプロセッサ、コンピュータ、システムオンチップ、またはこれらのうちの複数のもの、あるいはこれらの組み合わせを含む、データを処理するためのあらゆる種類の装置、デバイス、ノード、および機械（例えば、プロセッサ６１０）を包含する。装置は、専用論理回路、例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路）を含むことができる。装置は、ハードウェアに加えて、当該のコンピュータプログラムのための実行環境を作成するコード（例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームの実行時環境、仮想マシン、またはこれらのうちの１つまたは複数の組み合わせを構成するコード）を含むこともできる。
コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られている）（例えば、コンピュータプログラム６２４）は、コンパイラ型言語またはインタープリタ型言語、宣言型言語または手続き型言語を含む、任意の形態のプログラミング言語で記述されることが可能であり、コンピューティング環境における使用に適したスタンドアロンプログラムとして、あるいはモジュール、コンポーネント、サブルーチン、オブジェクト、または他のユニットとしての形態を含む、任意の形態で展開されることが可能である。コンピュータプログラムは、ファイルシステム内のファイルに対応してよいが、対応している必要はない。プログラムは、他のプログラムまたはデータ（例えば、マークアップ言語のドキュメントに格納された１つまたは複数のスクリプト）を保持しているファイルの一部に、プログラム専用の単一のファイルに、または複数の調整されたファイル（例えば、１つまたは複数のモジュール、サブプログラム、またはコードの一部を格納するファイル）に、格納され得る。コンピュータプログラムは、１つのサイトに位置するか、または複数のサイトにわたって分散されて通信ネットワークによって相互接続された、１つのコンピュータ上または複数のコンピュータ上で実行されるように展開され得る。
本明細書において説明されたプロセスおよび論理フローの一部は、入力データに対して動作して出力を生成することによってアクションを実行するために、１つまたは複数のコンピュータプログラムを実行する１つまたは複数のプログラマブルプロセッサ（例えば、プロセッサ６１０）によって実行され得る。プロセスおよび論理フローは、例えばＦＰＧＡ（フィールドプログラマブルゲートアレイ）またはＡＳＩＣ（特定用途向け集積回路）といった専用論理回路によって実行されることも可能であり、装置は、専用論理回路として実装されることも可能である。
コンピュータプログラムの実行に適したプロセッサの例としては、汎用マイクロプロセッサおよび専用マイクロプロセッサの両方、ならびに任意の種類のデジタルコンピュータのプロセッサが挙げられる。通常、プロセッサは、読み取り専用メモリまたはランダムアクセスメモリあるいはその両方（例えば、メモリ６２０）から命令およびデータを受信する。コンピュータの要素は、命令に従ってアクションを実行するプロセッサ、ならびに命令およびデータを格納する１つまたは複数のメモリデバイスを含むことができる。コンピュータは、データを格納するための１つまたは複数のマスストレージデバイス（例えば、磁気ディスク、光磁気ディスク、または光ディスク）を含むか、またはそのようなマスストレージデバイスとの間でデータを受信もしくは送信するように動作可能に結合されるか、あるはその両方であってもよい。しかし、コンピュータがそのようなデバイスを含む必要はない。さらに、コンピュータは、別のデバイス（例えば、電話、電子機器、携帯型オーディオまたはビデオプレーヤー、ゲーム機、全地球測位システム（ＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信器、あるいはポータブルストレージデバイス（例えば、ユニバーサルシリアルバス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）フラッシュドライブ））に埋め込まれ得る。コンピュータプログラム命令およびデータを格納するのに適したデバイスは、例えば、半導体メモリデバイス（例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリデバイスなど）、磁気ディスク（例えば、内部ハードディスク、取り外し可能なディスクなど）、光磁気ディスク、ならびにＣＤ－ＲＯＭおよびＤＶＤ－ＲＯＭディスクなどの、あらゆる形態の不揮発性メモリ、媒体、およびメモリデバイスを含む。場合によっては、プロセッサおよびメモリは、専用論理回路によって補完されるか、または専用論理回路に組み込まれ得る。
例示的な電源ユニット６４０は、電力をコンピュータシステム６００の他のコンポーネントに供給する。例えば、他のコンポーネントは、電圧バスまたは他の接続を介して電源ユニット６４０によって供給された電力に基づいて動作してよい。一部の実装では、電源ユニット６４０は、バッテリーまたはバッテリーシステム（例えば、充電式バッテリー）を含む。一部の実装では、電源ユニット６４０は、外部電力信号を（外部ソースから）受信し、外部電力信号を、コンピュータシステム６００のコンポーネント用に調整された内部電力信号に変換するアダプタ（例えば、ＡＣアダプタ）を含む。電源ユニット６４０は、他のコンポーネントを含むか、または別の方法で動作してよい。
ユーザとの対話を提供するために、動作は、情報をユーザに表示するためのディスプレイデバイス（例えば、ディスプレイ６５０）（例えば、モニタ、または別の種類のディスプレイデバイス）、ならびにユーザが入力をコンピュータに提供するために使用できるキーボードおよびポインティングデバイス（例えば、マウス、トラックボール、タブレット、タッチ感応画面、または別の種類のポインティングデバイス）を含んでいるコンピュータ上で実施され得る。ユーザとの対話を提供するために、他の種類のデバイスも使用され得る。例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック（例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバック）であることができ、ユーザからの入力が、音響入力、音声入力、または触覚入力を含む任意の形態で受信され得る。加えて、コンピュータは、ドキュメントを、ユーザによって使用されているデバイスに送信し、ユーザによって使用されているデバイスから受信することによって、ユーザと対話することができ、例えば、Ｗｅｂブラウザから受信された要求に応答して、Ｗｅｂページをユーザのクライアントデバイス上のＷｅｂブラウザに送信することによって、ユーザと対話することができる。
コンピュータシステム６００は、単一のコンピューティングデバイスまたは複数のコンピュータを含んでよく、複数のコンピュータは、近接して、または通常は互いにリモートで動作し、通常、通信ネットワークを介して（例えば、インターフェイス６３０を介して）情報をやりとりする。通信ネットワークの例としては、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）および広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、インターネットワーク（例えば、インターネット）、衛星中継を含んでいるネットワーク、ならびにピアツーピアネットワーク（例えば、アドホックピアツーピアネットワーク）が挙げられる。クライアントおよびサーバの関係は、各コンピュータ上で実行されている、互いにクライアント／サーバの関係を有しているコンピュータプログラムによって生じてよい。
例示的なインターフェイス６３０は、他のシステムまたはデバイスとの通信を提供してよい。場合によっては、インターフェイス６３０は、例えば、特に、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、近距離無線通信（ＮＦＣ：Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＧＳＭ音声通話、ＳＭＳ、ＥＭＳ、またはＭＭＳメッセージング、ワイヤレス規格（例えば、ＣＤＭＡ、ＴＤＭＡ、ＰＤＣ、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＰＲＳ）などの、さまざまなワイヤレスプロトコルに従ってワイヤレス通信を提供するワイヤレス通信インターフェイスを含む。そのような通信は、例えば、無線周波数トランシーバまたは別の種類のコンポーネントを介して発生してよい。場合によっては、インターフェイス６３０は、例えば、キーボード、ポインティングデバイス、スキャナなどの、１つまたは複数の入力デバイス／出力デバイスに接続され得る有線通信インターフェイス（例えば、ＵＳＢ、イーサネット）、あるいは、例えばネットワークアダプタを介する、スイッチまたはルータなどのネットワークデバイスを含む。
一般的な態様では、複数の実体のルート証明書データブロックチェーンは、暗号システム内の末端実体によって使用するために、生成されるか、または変更されて、提供される。
第１の態様では、ジェネシスデータブロック（例えば、図３Ｃに示された例では３４０）が、検証実体（例えば、図３Ａに示されているような検証実体３０４）によって生成される。ジェネシスデータブロックは、ルートＣＡコンソーシアムの各メンバー実体（例えば、図３Ａに示されているような創設メンバー３０２－１、．．．、３０２－ｎ）を表すジェネシスブロックデータエントリを含む。各ジェネシスブロックデータエントリは、ジェネシスブロックデータエントリによって表されたメンバー実体の識別子、ジェネシスブロックデータエントリによって表されたメンバー実体の公開鍵を含む。ジェネシスデータブロックエントリは、検証実体によって各メンバー実体から受信される。次に、（例えば、図３Ａに示されているように、３１２で）ジェネシスデータブロックデータエントリに関連付けられたデジタル署名の第１のセットが検証される。ジェネシスブロックは、ジェネシスデータブロックに基づいて、ルートＣＡコンソーシアムの検証実体によって生成される。ジェネシスブロックを生成することは、（例えば、図３Ａに示されているように、３１８で）ジェネシスデータブロックに基づいて、各メンバー実体からデジタル署名の第２のセットを受信することと、デジタル署名の第２のセットをジェネシスデータブロック（例えば、図３Ｄに示されているような３５０）に追加することとを含む。ジェネシスブロックを含んでいるブロックチェーンが、１つまたは複数の末端実体によって暗号システム内のルート証明書データブロックチェーンとして使用するために提供される。
第１の態様の実装は、次の特徴のうちの１つまたは複数を含んでよい。メンバー実体の各々は、ジェネシスブロックデータエントリ内の公開鍵に対応する秘密鍵を持っている。メンバー実体の各々の秘密鍵は、どの他のメンバーまたは検証実体によってもアクセス可能ではない。ジェネシスブロックデータエントリおよび各メンバー実体からの署名の第１のセットが、検証実体によって並列に受信される。デジタル署名の第１のセット内の各デジタル署名が、メンバー実体の識別子およびメンバー実体の秘密鍵に基づいて、メンバー実体のうちの各１つによって生成される。ジェネシスデータブロックを生成することは、メンバー実体のデジタル署名の第１のセットを検証することをさらに含んでよい。各メンバー実体からのデジタル署名の第２のセットが、検証実体によって並列に受信される。
第２の態様では、コンピューティングシステムは、１つまたは複数のプロセッサおよび命令を格納しているコンピュータ可読媒体を含み、命令は、１つまたは複数のプロセッサによって実行された場合に、第１の態様の１つまたは複数の動作を実行するように動作可能である。
第３の態様では、非一過性コンピュータ可読媒体が、データ処理装置によって実行された場合に、第１の態様の動作を実行するように動作可能である命令を格納している。
第４の態様では、アクションデータブロックが、検証実体によって取得される。アクションデータブロックが、ルートＣＡコンソーシアムのメンバー実体に配信される。アクションブロック（例えば、図４Ｄに示されているような４５０）が、アクションデータブロックおよびメンバーからの署名に基づいて、ルートＣＡコンソーシアムの検証実体によって生成される。アクションブロックを生成することは、（例えば、図４Ａに示されているように、４１８で）ジェネシスデータブロックに基づいて、各メンバー実体からデジタル署名のセットを受信することと、（例えば、図４Ｄに示されているように）デジタル署名のセットをアクションデータブロックに追加することとを含む。セット内のデジタル署名の各々は、各メンバー実体によって、アクションデータブロックに基づいて生成される（例えば、Ｓｉｇｎａｔｕｒｅ＿Ｍ＿１、Ｓｉｇｎａｔｕｒｅ＿Ｍ＿２、．．．、Ｓｉｇｎａｔｕｒｅ＿Ｍ＿ｎ）。アクションブロックを含んでいるブロックチェーンが、１つまたは複数の末端実体によって暗号システム内のルート証明書データブロックチェーンとして（例えば、更新されたルート証明書データブロックチェーンとして）使用するために提供される。
第４の態様の実装は、次の特徴のうちの１つまたは複数を含んでよい。場合によっては、アクションデータブロックエントリは、（例えば、図４Ａ～４Ｄに示された例では）要求している実体から検証実体によって受信され、アクションデータブロックエントリは、要求している実体の識別子（例えば、ＩＤ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）および要求している実体の公開鍵（例えば、Ｐｕｂｌｉｃ＿ｋｅｙ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）を含む。アクションデータブロックエントリに関連して、要求している実体のデジタル署名（例えば、Ｓｉｇｎａｔｕｒｅ＿Ｒｅｑ＿Ｅｎｔｉｔｙ）も受信され、検証実体は、要求者のデジタル署名を検証した後に、アクションデータブロックを生成する。アクションデータブロックを生成することは、ブロックチェーン内の前のブロックのハッシュを決定することと、このハッシュをアクションブロックデータエントリに追加することとを含んでよい。要求している実体は、アクションブロックデータエントリ内の公開鍵に対応する秘密鍵を持っている。要求している実体の秘密鍵は、どのメンバーまたは検証実体によってもアクセス可能ではない。アクションブロックデータエントリは、アクションタイプ識別子を含む。
第４の態様の実装は、次の特徴のうちの１つまたは複数を含んでよい。場合によっては、アクションデータブロックエントリは、（例えば、図５Ａ～５Ｄに示された例では）特定の要求している実体に関連付けられない。そのような場合、アクションデータブロックエントリは、要求している実体の識別子も要求している実体の公開鍵も含まず、要求している実体のデジタル署名が検証実体によって検証される必要はない。
第５の態様では、コンピューティングシステムは、１つまたは複数のプロセッサおよび命令を格納しているコンピュータ可読媒体を含み、命令は、１つまたは複数のプロセッサによって実行された場合に、第４の態様の１つまたは複数の動作を実行するように動作可能である。
第６の態様では、非一過性コンピュータ可読媒体が、データ処理装置によって実行された場合に、第４の態様の動作を実行するように動作可能である命令を格納している。
本明細書は、多くの詳細を含んでいるが、それらは、請求され得る内容の範囲に対する制限と理解されるべきではなく、特定の例に固有の特徴の説明と理解されるべきである。別々の実装との関連において本明細書において説明されたか、または図面に示された特定の特徴は、組み合わせられることも可能である。反対に、単一の実装との関連において説明されたか、または示された個々の特徴は、複数の実施形態において別々に、または任意の適切な部分的組み合わせで、実装されることも可能である。
同様に、図面では特定の順序で動作が示されているが、望ましい結果を達成するために、そのような動作が、示された特定の順序で、または連続的順序で実行される必要があると理解されるべきではなく、すべての示された動作が実行される必要があると理解されるべきではない。特定の環境では、マルチタスクおよび並列処理が有利であることがある。さらに、前述の実装におけるさまざまなシステムコンポーネントの分離は、すべての実装においてそのような分離を必要とすると理解されるべきではなく、説明されたプログラムコンポーネントおよびシステムが、一般に、単一の製品内で一緒に統合されるか、または複数の製品にパッケージ化され得ると理解されるべきである。
複数の実施形態が説明された。それにもかかわらず、さまざまな変更が行われ得るということが理解されるであろう。したがって、他の実施形態は、以下の特許請求の範囲内にある。

Claims (26)

  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. 前記アクションが、
    メンバーを前記ルート認証機関コンソーシアムから除去することと、
    前記ルート認証機関コンソーシアムのメンバーの公開鍵を更新することと、
    前記ルート認証機関コンソーシアムのメンバーの公開鍵を取り消すことと、
    前記ルート認証機関コンソーシアムのメンバーの公開鍵を置き換えることと、
    前記ルート認証機関コンソーシアムのメンバーの追加の公開鍵を追加することと、
    前記ルート認証機関コンソーシアムのメンバーの公開鍵をキャンセルすることと、
    前記チェーンの有効な状態をタイムスタンプ処理することと、
    現在有効なすべての識別情報の要約を記録することと、
    前記ブロックをフリーズすることと、
    前記ブロックをフリーズ解除することとのうちの少なくとも１つを含む、請求項２４に記載のコンピュータシステム。
JP2023522790A 2020-10-15 2021-01-27 複数の実体のルート証明書データブロックチェーンの構築 Active JP7454750B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/071,451 2020-10-15
US17/071,451 US10958450B1 (en) 2020-10-15 2020-10-15 Constructing a multiple-entity root certificate data block chain
PCT/CA2021/050081 WO2022077092A1 (en) 2020-10-15 2021-01-27 Constructing a multiple-entity root certificate data block chain

Publications (2)

Publication Number Publication Date
JP2023546856A JP2023546856A (ja) 2023-11-08
JP7454750B2 true JP7454750B2 (ja) 2024-03-22

Family

ID=74882874

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023522790A Active JP7454750B2 (ja) 2020-10-15 2021-01-27 複数の実体のルート証明書データブロックチェーンの構築

Country Status (4)

Country Link
US (1) US10958450B1 (ja)
EP (1) EP4229536A1 (ja)
JP (1) JP7454750B2 (ja)
WO (1) WO2022077092A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111541724B (zh) * 2020-07-08 2021-06-29 支付宝(杭州)信息技术有限公司 区块链一体机及其节点自动加入方法、装置
CN111541552B (zh) 2020-07-08 2021-06-22 支付宝(杭州)信息技术有限公司 区块链一体机及其节点自动加入方法、装置
CN113114495B (zh) * 2021-04-03 2021-12-28 湖南大学 一种基于区块链的主节点公平选举方法
CN113343213A (zh) * 2021-07-01 2021-09-03 北京邮电大学 一种分散自主网络中基于区块链的多ca跨域认证方法
CN114219487B (zh) * 2021-12-22 2024-07-09 中国电子科技网络信息安全有限公司 一种联盟链分布式证书管理方法
WO2024016084A1 (en) * 2022-07-22 2024-01-25 ISARA Corporation Certificate validation using a multiple-key-pair root certificate authority

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190238525A1 (en) 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
US20190317924A1 (en) 2018-04-12 2019-10-17 ISARA Corporation Constructing a Multiple Entity Root of Trust
JP2019532603A (ja) 2016-10-20 2019-11-07 ソニー株式会社 ブロックチェーンに基づくデジタル権利管理
WO2020019914A1 (zh) 2018-07-24 2020-01-30 腾讯科技（深圳）有限公司 数字证书校验方法、装置、计算机设备和存储介质
JP2020519039A (ja) 2017-07-26 2020-06-25 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ブロックチェーンノード通信方法および装置

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5214702A (en) 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5610982A (en) 1996-05-15 1997-03-11 Micali; Silvio Compact certification with threshold signatures
CA2275574C (en) * 1996-12-20 2003-07-29 Financial Services Technology Consortium Method and system for processing electronic documents
US6134327A (en) 1997-10-24 2000-10-17 Entrust Technologies Ltd. Method and apparatus for creating communities of trust in a secure communication system
US6553493B1 (en) 1998-04-28 2003-04-22 Verisign, Inc. Secure mapping and aliasing of private keys used in public key cryptography
TW552596B (en) * 1999-07-30 2003-09-11 Rohm Co Ltd Chip resistor and method of making the same
JP2005520364A (ja) 2001-07-09 2005-07-07 リナックスプローブ株式会社 デジタル署名された証明書を更新しかつ拡張するシステムおよび方法
US10340038B2 (en) * 2014-05-13 2019-07-02 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain, systems and methods
US9836908B2 (en) * 2014-07-25 2017-12-05 Blockchain Technologies Corporation System and method for securely receiving and counting votes in an election
CN107078908A (zh) 2014-08-22 2017-08-18 诺基亚通信公司 公开密钥基础结构中的信任锚更新
JP6704985B2 (ja) 2015-04-05 2020-06-03 デジタル・アセット・ホールディングス・エルエルシー デジタル資産仲介電子決済プラットフォーム
US10402792B2 (en) 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
KR102050129B1 (ko) * 2016-05-03 2019-11-28 안규태 블록 검증을 위한 복수의 일방향 함수를 지원하는 블록 체인
US9660978B1 (en) 2016-08-08 2017-05-23 ISARA Corporation Using a digital certificate with multiple cryptosystems
DE102016215917A1 (de) * 2016-08-24 2018-03-01 Siemens Aktiengesellschaft Gesichertes Verarbeiten einer Berechtigungsnachweisanfrage
CN106301792B (zh) 2016-08-31 2019-10-18 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及***
WO2018057520A1 (en) * 2016-09-20 2018-03-29 Nant Holdings Ip, Llc Sample tracking via sample tracking chains, systems and methods
CN107070644B (zh) 2016-12-26 2020-02-28 北京科技大学 一种基于信任网络的去中心化公钥管理方法和管理***
US10389518B2 (en) * 2017-01-27 2019-08-20 Entit Software Llc Blockchain hash value recomputation
US10484346B2 (en) * 2017-02-07 2019-11-19 Microsoft Technology Licensing, Llc Establishment of consortium blockchain network
CN106789041B (zh) 2017-02-15 2019-07-12 江苏信源久安信息科技有限公司 一种去中心化证书可信区块链方法
US10579368B2 (en) * 2017-03-10 2020-03-03 Salesforce.Com, Inc. Blockchain version control systems
US9882918B1 (en) 2017-05-15 2018-01-30 Forcepoint, LLC User behavior profile in a blockchain
US10708070B2 (en) * 2017-05-24 2020-07-07 Nxm Labs Canada Inc. System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner
US10944546B2 (en) 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
CN107592293A (zh) 2017-07-26 2018-01-16 阿里巴巴集团控股有限公司 区块链节点间通讯方法、数字证书管理方法、装置和电子设备
US11544708B2 (en) * 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain
US10785045B2 (en) * 2018-01-03 2020-09-22 International Business Machines Corporation Socially enabled consensus blockchain summarization
KR102617352B1 (ko) * 2018-06-04 2023-12-26 삼성전자주식회사 블록체인을 이용하는 사용자 장치, 이를 포함하는 블록체인 시스템 및 그것의 제품 정보 관리 방법
US11405373B2 (en) * 2018-09-07 2022-08-02 Honeywell International, Inc. Blockchain-based secured multicast communications
US10965472B2 (en) * 2018-11-02 2021-03-30 Hitachi, Ltd. Secure bootstrap for a blockchain network
US11177964B2 (en) * 2019-01-25 2021-11-16 International Business Machines Corporation Blockchain based authentication
US20200334685A1 (en) * 2019-04-18 2020-10-22 TraDove. Inc. Generating weighted indications of entity performance patterns and credibility determinations to enhance security and contextual awareness in a transaction platform

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019532603A (ja) 2016-10-20 2019-11-07 ソニー株式会社 ブロックチェーンに基づくデジタル権利管理
JP2020519039A (ja) 2017-07-26 2020-06-25 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ブロックチェーンノード通信方法および装置
US20190238525A1 (en) 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
US20190317924A1 (en) 2018-04-12 2019-10-17 ISARA Corporation Constructing a Multiple Entity Root of Trust
JP2021520167A (ja) 2018-04-12 2021-08-12 イサラ コーポレイション 複数のエンティティのルートオブトラストを構築する方法
WO2020019914A1 (zh) 2018-07-24 2020-01-30 腾讯科技（深圳）有限公司 数字证书校验方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
EP4229536A1 (en) 2023-08-23
JP2023546856A (ja) 2023-11-08
US10958450B1 (en) 2021-03-23
WO2022077092A1 (en) 2022-04-21

Similar Documents

Publication Publication Date Title
US11615060B2 (en) Constructing a multiple entity root of trust
JP7454750B2 (ja) 複数の実体のルート証明書データブロックチェーンの構築
CN111771390B (zh) 自组织网络
Seth et al. Practical security for disconnected nodes
JP2023504535A (ja) アイデンティティ（ｉｄ）ベース公開鍵生成プロトコル
Li et al. Blockchain-based secure key management for mobile edge computing
Toorani et al. A decentralized dynamic PKI based on blockchain
EP3628113A1 (en) Sybil-resistant identity generation
CN111786812A (zh) 节点管理方法、装置、计算机设备和存储介质
Ernest et al. Privacy enhancement scheme (PES) in a blockchain-edge computing environment
Zhu et al. Generating correlated digital certificates: framework and applications
Zhang et al. NDN-MPS: supporting multiparty authentication over named data networking
Chatzigiannis et al. Black-box iot: Authentication and distributed storage of iot data from constrained sensors
Raza et al. Design and implementation of a security manager for WirelessHART networks
US20240031176A1 (en) Certificate Validation Using a Multiple-Key-Pair Root Certificate Authority
Li et al. Key management in ad hoc networks using self-certified public key system
Mandal et al. Universally verifiable certificateless signcryption scheme for MANET
WO2024139741A1 (zh) 基于区块链的证书管理方法、***及相关装置
Eie Authentication in protected core networking
US20230412397A1 (en) Transitioning To and From Crypto-Agile Hybrid Public Key Infrastructures
da Silva et al. SEMAN: A novel secure middleware for mobile ad hoc networks
Cheneau et al. A Trustful Authentication and Key Exchange Scheme (TAKES) for ad hoc networks
Li et al. A Novel Security Scheme Supported by Certificateless Digital Signature and Blockchain in Named Data Networking
Lv et al. Virtual private key generator based escrow‐free certificateless public key cryptosystem for mobile ad hoc networks
Ahene et al. CLIBDA: A Deniable Authentication Scheme for Pervasive Computing Environment

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230413

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20230413

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231030

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240130

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240208

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240311

R150 Certificate of patent or registration of utility model

Ref document number: 7454750

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150