JP2022552420A - 証明書認証用の分散台帳に基づく方法およびシステム - Google Patents
証明書認証用の分散台帳に基づく方法およびシステム Download PDFInfo
- Publication number
- JP2022552420A JP2022552420A JP2022523229A JP2022523229A JP2022552420A JP 2022552420 A JP2022552420 A JP 2022552420A JP 2022523229 A JP2022523229 A JP 2022523229A JP 2022523229 A JP2022523229 A JP 2022523229A JP 2022552420 A JP2022552420 A JP 2022552420A
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- issuer
- distributed ledger
- server
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/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/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)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
分散台帳との間で役割および証明書を追加および除去ための取引、および2つの接続されたサーバの証明書を認証するための取引を公表するための方法およびシステムを開示する。役割は、役割を有するどのサーバが、証明書および役割に関するどのタイプの取引を公表できるかを指定する。役割が要求されたとき、役割および発行者証明書を追加するための2つの取引が分散台帳に公表される。どんな役割も有しないサーバの証明書が要求されたとき、証明書を追加するための取引だけは、分散台帳に公表される。すべての取引は、証明書要求サーバと、証明書発行サーバと、分散台帳を維持している分散台帳ネットワークとの間の動作を通して公表される。2つの接続されたサーバは、それらの相手側の識別の真正性を、分散台帳から受信した、分散台帳技術の証明書不変性および可用性の利益を有する証明書を用いて検証できる。【選択図】図2
Description
本発明は、認証された接続を確立するための方法およびシステムに関し、より詳細には分散台帳技術を採用して、認証された接続を確立する方法およびシステムに関する。
安全なネットワークを保証するために、相互認証は、実際の接続が行われる前に実体が互いに認証するセキュリティ処理である。この相互認証は、ネットワーク環境では、クライアントとサーバの両方がデジタル証明書を提供してクライアントおよびサーバの識別を証明しなければならないことを要求する。相互認証処理のために、クライアントおよびサーバが互いの証明書を交換し、検証し、信頼する場合だけ接続を行うことができる。TLS(Transport Layer Security、トランスポート層セキュリティ)プロトコルおよびその前にあったSSL(Secure Socket Layer)プロトコルは、そのような証明書の交換および検証に取り組むために開発されてきた。SSL/TLSプロトコルは、X.509規格によりフォーマットが規定される公開鍵証明書であるX.509証明書の最も一般的なタイプの1つを採用する。X.509証明書はウェブサイト、個人、または組織などの識別と暗号鍵対を安全に関連づける。
しかしながら、X.509証明書は証明書不変性、証明書可用性、および証明書履歴に関する限り、決して完全ではない。証明書不変性に対する影響は、ハッカーの攻撃がX.509証明書に不正な変更を加えることにある。ルート証明書、または認証局(certificate authority、CA)のいずれかが危険にさらされると、システムセキュリティは、危険にさらされる。証明書可用性の他の欠点は、あらゆるサーバが自身の証明書データベースを維持しなければならないことであり、その結果、証明書データベースの間に不整合が発生する。証明書履歴のマイナス面に関しては、追加および取消しを含むすべての記録は、前述の2つの問題のためにX.509証明書のデータベースに存在するわけではない。
本発明の目的は、発行者資格および発行者証明書を公表するため、分散台帳にサーバ証明書を公表するため、および証明書認証のための方法およびシステムを提供することであり、これにより、分散台帳ネットワークにより維持された分散台帳でサーバの証明書を追加および除去して、分散台帳で証明書を検証することになったときに証明書不変性および証明書可用性を改善する。
前述の目的を達成するために、互いに通信状態にある証明書発行ノード(certificate-issuing node、CI)および証明書要求サーバ(certificate-requesting server、CR)を通して、CIを含む分散台帳ネットワークにより維持された分散台帳に発行者資格および発行者証明書を公表するための方法は、(a)CIは、CRから資格関連情報を受信するステップと、(b)CIは、発行者資格取引に署名して、分散台帳に発行者資格取引を提出するステップと、(c)CRおよびCIの一方は、CRに関する発行者証明書を作成し、発行者証明書に署名し、発行者証明書の署名者がCRではないときにCRに発行者証明書を送信するステップと、(d)分散台帳で発行者資格取引が作成された後、発行者証明書を有するCRおよびCIの任意の一方は、発行者証明書取引に署名して、分散台帳に発行者証明書取引を提出するステップと、を含む。
前述の目的を達成するために、互いに通信状態にある証明書発行サーバ(CI)および証明書要求サーバ(CR)を通して、CIを含む分散台帳ネットワークにより維持された分散台帳にサーバ証明書を公表するための方法は、(a)CIは、CRから証明書関連情報を受信するステップと、(b)CIは、CRに関するサーバ証明書を作成し、サーバ証明書に署名し、CRにサーバ証明書を送信するステップと、(c)CIは、サーバ証明書取引に署名して、分散台帳にサーバ証明書取引を提出するステップと、 を含む。
前述の目的を達成するために、分散台帳を維持している分散台帳ネットワークに互いに通信可能に接続された接続サーバ(connecting server、CS)および受信サーバ(receiving server、RS)の証明書を認証するための方法は、(a)RSは、CSと識別を交換するステップと、(b)RSは、CS識別に基づき分散台帳からCSの証明書およびCS証明書発行者の公開鍵を取り出すステップと、(c)RSは、CS証明書発行者の公開鍵を用いてCSの証明書が真正であるかどうかを検証するステップと、(d)CSの証明書が真正であることが検証された後、RSは、CSがRSから秘密情報を受信するように認証されていると判断するステップと、を含む。
前述の目的を達成するために、発行者資格および発行者証明書を公表するための分散台帳に基づくシステムは、証明書要求サーバ(CR)および分散台帳ネットワークを含む。
分散台帳を維持している分散台帳ネットワークは、CRに通信可能に接続され、証明書発行ノード(CI)を含む。CIは、CRから資格関連情報を受信し、発行者資格取引に署名し、分散台帳に発行者資格取引を提出する。CRおよびCIの一方は、CRに関する発行者証明書をさらに作成し、発行者証明書の署名者がCRではないときにCRに発行者証明書を送信する。分散台帳で発行者資格取引が作成された後、発行者証明書を有するCRおよびCIの一方は、発行者証明書取引に署名し、分散台帳に発行者証明書取引を提出する。
前述の目的を達成するために、分散台帳にサーバ証明書を公表するための分散台帳に基づくシステムは、証明書要求サーバ(CR)および分散台帳ネットワークを含む。
分散台帳ネットワークは、分散台帳を維持し、CRに通信可能に接続され、証明書発行サーバ(CI)を含む。CIは、CRから証明書関連情報を受信し、CRに関するサーバ証明書を作成し、サーバ証明書に署名し、CRにサーバ証明書を送信し、サーバ証明書取引に署名して分散台帳にサーバ証明書取引を提出する。
前述の目的を達成するために、証明書認証用の分散台帳に基づくシステムは、分散台帳ネットワーク、接続サーバ(CS)、および受信サーバ(RS)を含む。
分散台帳ネットワークは、分散台帳を維持する。
CSは、分散台帳ネットワークに通信可能に接続される。
RSは、分散台帳ネットワークに通信可能に接続され、CSと識別を交換し、CS識別に基づき分散台帳からCSの証明書およびCS証明書発行者の公開鍵を取り出してCSの証明書が真正であるかどうかを検証し、CSの証明書が真正であることを検証したとき、CSがRSから秘密情報を受信するように認証されていると判断する。
前記によれば、役割を有する、または役割をまったく有しないすべてのサーバは、分散台帳との間で権限を与えられたサーバにより追加または除去される、サーバ自体の証明書を有する。分散台帳での役割は、役割を有するどのサーバがどのタイプの役割および証明書を追加する権限を与えられているかを規制する権限を指定し、その結果、権限のない実体が証明書、および分散台帳での役割を破壊するのを防止する。
分散台帳は本来、分散させられる。これにより、悪意のある活動によって標的にする、集中化した実体がまったく存在しないので、セキュリティの層が追加される。複製された形態で分散台帳を大域に広げることが可能であるので、単一の点故障を回避できる。その結果、分散台帳に公表された役割および証明書はまた、分散台帳の不変性により利益を得ることが可能である。分散台帳での証明書および役割は、合意機構に基づき絶えずかつ迅速に更新できるので、分散台帳での証明書および役割に関する不整合は、問題にならないように思われる。その結果、本発明の方法およびシステムにより分散台帳に追加された証明書は、サーバが証明書認証のために信頼を互いに確認することを要求することを提供でき、これは、サーバ間の安全な通信できわめて重要である。
さらに、透明性もまた、分散台帳技術の利点と考えることが可能である。分散台帳は、記憶された情報すべてに容易にかつ自由にアクセスできるようにし、これにより、サーバに接続したときに証明書認証に非常に大きな所望の透明性を追加できる。
分散台帳は本来、分散させられる。これにより、悪意のある活動によって標的にする、集中化した実体がまったく存在しないので、セキュリティの層が追加される。複製された形態で分散台帳を大域に広げることが可能であるので、単一の点故障を回避できる。その結果、分散台帳に公表された役割および証明書はまた、分散台帳の不変性により利益を得ることが可能である。分散台帳での証明書および役割は、合意機構に基づき絶えずかつ迅速に更新できるので、分散台帳での証明書および役割に関する不整合は、問題にならないように思われる。その結果、本発明の方法およびシステムにより分散台帳に追加された証明書は、サーバが証明書認証のために信頼を互いに確認することを要求することを提供でき、これは、サーバ間の安全な通信できわめて重要である。
さらに、透明性もまた、分散台帳技術の利点と考えることが可能である。分散台帳は、記憶された情報すべてに容易にかつ自由にアクセスできるようにし、これにより、サーバに接続したときに証明書認証に非常に大きな所望の透明性を追加できる。
本発明の他の目的、利点、および新規な特徴は、添付の図面と併せて解釈されたときに以下の詳細な説明からより明らかになるであろう。
以下で提示する記述で使用する専門用語は、技術のある種の特有の実施形態についての詳細な記述に関連して使用されるとしても、その用語の最も広い合理的な手法で解釈されることが意図される。ある種の用語は、以下で強調される場合さえあるが、しかしながら、任意の制限された手法で解釈されることを意図されるどんな専門用語も、この「発明を実施するための形態」の節でそのようなものとして具体的に規定される。
以下で紹介する実施形態は、ソフトウェアおよび/もしくはファームウェアによりプログラムされ、または構成されたプログラム可能回路により、または完全に専用回路により、またはそのような形態の組合せで実装できる。そのような専用回路は(もしあれば)、たとえば1つまたは複数の特定用途向け集積回路(application-specific integrated circuit、ASIC)、プログラム可能論理デバイス(programmable logic device、PLD)、フィールド・プログラマブル・ゲート・アレイ(field programmable gate array、FPGA)などの形態をとることができる。
本発明での各サーバは、分散台帳ネットワークにより維持された分散台帳に記憶された自身の識別として証明書を所有する。第1のサーバに関する証明書は、証明書の真正性を検証するために、自身に関連する第2のサーバに提出される。証明書が検証された後、第2のサーバは、第1のサーバを信頼し、第1のサーバに秘密情報を自発的に送信する。同様に、そのようなシナリオは、第2のサーバが検証のために第1のサーバに自身の証明書を提供するときに逆に適用できる。
分散台帳との間で証明書を追加または除去するために、発行者の資格を有するサーバだけがそうすることができるようになる。そのためには、発行者の資格はまた、分散台帳との間で追加または除去されて、どのサーバがどの種類の発行者の資格および証明書を追加および除去できるかを常に把握すべきである。サーバの発行者の資格のタイプ、および他のサーバの発行者の資格および証明書を追加および除去する、または取り消す、対応する取引を指定する分散台帳規則が存在する。
分散台帳との間で証明書を追加または除去するために、発行者の資格を有するサーバだけがそうすることができるようになる。そのためには、発行者の資格はまた、分散台帳との間で追加または除去されて、どのサーバがどの種類の発行者の資格および証明書を追加および除去できるかを常に把握すべきである。サーバの発行者の資格のタイプ、および他のサーバの発行者の資格および証明書を追加および除去する、または取り消す、対応する取引を指定する分散台帳規則が存在する。
簡潔に述べると、記述する実施形態は、分散台帳で発行者の資格および証明書を公表するための、証明書認証用の1つまたは複数の方法およびシステムに関する。任意の2つのサーバが接続するときに証明書認証を確実にするために、サーバの識別および交換されたサーバ証明書に基づき分散台帳から取り出された証明書は、取り出された証明書が利用可能であるかどうか、または取り出された証明書が、認証された情報転送をサーバ間で開始する基礎として採用できる交換された証明書と調和するかどうかを確かめるために検証できる。
分散台帳に基づく解決策は、証明書の信頼および不変性で改善が予見されるので採用される。解決手段は、分散台帳で多数の発行者の資格および証明書を中に記憶する証明書ストアにある。その名前が反映するように、発行者の資格は、分散台帳との間で他のサーバの発行者の資格および証明書を追加および除去できる発行権限を有するサーバにより所有される。発行者の資格または発行者の役割を有するサーバはまた、分散台帳に自身の証明書を有することができ、一方、どの発行者の資格も有しないサーバは、分散台帳に自身の証明書だけを有することが可能である。
発行者の役割を有するサーバを追加するために、サーバの証明書を追加する取引およびサーバの発行者の役割を追加する取引は、分散台帳と、分散台帳ネットワークの多数のサーバの中の2つである証明書要求サーバ(CR)および証明書発行ノード(CI)との間の対話を通して分散台帳に公表される。どんな発行者の役割も有しないサーバを追加するために、サーバの証明書を追加する取引は、分散台帳に公表される。取引を公表する他に、ここでの動作はまた、取引に署名し取引を検証するための台帳鍵対の使用、および証明書に署名し証明書を検証するための証明書鍵対の使用を伴う。発行者の役割または証明書が分散台帳から除去され、または取り消されたとき、発行者の役割を除去する、または証明書を取り消す取引は、分散台帳に公表される。方法およびシステムに関する詳細について、以下でさらに詳しく述べる。
分散台帳に基づく解決策は、証明書の信頼および不変性で改善が予見されるので採用される。解決手段は、分散台帳で多数の発行者の資格および証明書を中に記憶する証明書ストアにある。その名前が反映するように、発行者の資格は、分散台帳との間で他のサーバの発行者の資格および証明書を追加および除去できる発行権限を有するサーバにより所有される。発行者の資格または発行者の役割を有するサーバはまた、分散台帳に自身の証明書を有することができ、一方、どの発行者の資格も有しないサーバは、分散台帳に自身の証明書だけを有することが可能である。
発行者の役割を有するサーバを追加するために、サーバの証明書を追加する取引およびサーバの発行者の役割を追加する取引は、分散台帳と、分散台帳ネットワークの多数のサーバの中の2つである証明書要求サーバ(CR)および証明書発行ノード(CI)との間の対話を通して分散台帳に公表される。どんな発行者の役割も有しないサーバを追加するために、サーバの証明書を追加する取引は、分散台帳に公表される。取引を公表する他に、ここでの動作はまた、取引に署名し取引を検証するための台帳鍵対の使用、および証明書に署名し証明書を検証するための証明書鍵対の使用を伴う。発行者の役割または証明書が分散台帳から除去され、または取り消されたとき、発行者の役割を除去する、または証明書を取り消す取引は、分散台帳に公表される。方法およびシステムに関する詳細について、以下でさらに詳しく述べる。
本発明の目標は、発行者だけが証明書に署名し、証明書を公表できることを重要視する。目標を達成するために、受託者および運用者である2つのタイプの発行者の役割、ならびにルート証明書、管理者証明書、およびサーバ証明書である3つのタイプの証明書について述べる。すべての証明書は、分散台帳に公表されなければならないが、認可された分散台帳ネットワークでは、あらゆるサーバではなく発行者の役割を有するサーバは、他のサーバに関する証明書および発行者の役割を公表できる。受託者および運用者という発行者の役割はそれぞれ、信頼の起源、ならびにサイトですべてのサーバを運用して証明書および発行者の役割を公表する権限を与えられている各サイトの管理者を表す。簡潔にするために、用語「役割」は、本明細書で以後「発行者の役割」に取って代わる。
受託者の役割を有するサーバ、運用者の役割を有するサーバ、および役割なしのサーバはそれぞれルート証明書、管理者証明書、およびサーバ証明書を所有する。名前の違いにもかかわらず、3つのタイプの証明書は、検証のために証明書の公開鍵を使用する方法以外は、証明書の共通のデータフィールドに関する限り基本的に同じである。ルート証明書および管理者証明書は、公開鍵を使用して発行者の証明書の発行者により署名された証明書を検証できる発行者の証明書に関係し、一方、サーバ証明書を有するサーバがどんな証明書も発行する権限を与えられておらず、かつサーバ証明書を用いてサーバにより署名された証明書が存在しないというだけの理由で、サーバ証明書での公開鍵を使用して他の証明書を検証できない。
受託者の役割を有するサーバ、運用者の役割を有するサーバ、および役割なしのサーバはそれぞれルート証明書、管理者証明書、およびサーバ証明書を所有する。名前の違いにもかかわらず、3つのタイプの証明書は、検証のために証明書の公開鍵を使用する方法以外は、証明書の共通のデータフィールドに関する限り基本的に同じである。ルート証明書および管理者証明書は、公開鍵を使用して発行者の証明書の発行者により署名された証明書を検証できる発行者の証明書に関係し、一方、サーバ証明書を有するサーバがどんな証明書も発行する権限を与えられておらず、かつサーバ証明書を用いてサーバにより署名された証明書が存在しないというだけの理由で、サーバ証明書での公開鍵を使用して他の証明書を検証できない。
あらゆる証明書とその署名者の証明書の間の署名関係を考慮すると、その関係を言い換える簡略化された方法は、発行者の証明書は、証明書に署名し、発行者により署名された証明書を検証するということである。検証用に任意の証明書を与えられると、証明書に署名している発行者の証明書を分散台帳から再帰的に識別して証明書を検証でき、そのような検証処理は、ルート証明書である最上位の証明書まで遡ることが可能である。
証明書タイプ、および発行者の役割を有する実体の例を示す図1を参照する。左側のブロックは、分散台帳ネットワークで発行者の役割を有するサーバを示し、右側のブロックは、権限を与えられたサーバにより分散台帳に公表される3つのタイプの証明書を示す。図1に示すように、運用者の役割を有するサーバは、発行者の役割をまったく有することなく自身の管理者証明書および他のサーバのサーバ証明書を分散台帳に追加する取引を公表する資格を与えられ、受託者の役割を有するサーバは、分散台帳に自身のルート証明書を追加する取引を公表する資格を与えられる。
図1の右側には、分散台帳での3つのタイプの証明書を示す。各管理者証明書を使用して、管理者証明書により署名されたサーバ証明書を検証でき、ルート証明書を使用して、ルート証明書を公表しているサーバにより署名された管理者証明書を検証できる。証明書の検証処理は、サーバ証明書または管理者証明書が配置されたどこからでも開始してよく、利用可能である場合には、サーバ証明書または管理者証明書とルート証明書の間にある、順次検証される他の中間的な管理者証明書を伴うルート証明書で終了してよい。その間、検証処理は、ルート証明書まで進む必要はなく、条件が満たされた、または満たされないときに終了できる。条件は、事前に承認されたリストの中に検証中の証明書があるか、または検証が開始した証明書で検証が終了するかどうかを含むがそれに限定されない。それにもかかわらず、受託者および運用者の役割を有するサーバの数、ルート証明書、管理者証明書、およびサーバ証明書の数、ならびに証明書の階層構造は、図1に示すものに限定されない。
証明書タイプ、および発行者の役割を有する実体の例を示す図1を参照する。左側のブロックは、分散台帳ネットワークで発行者の役割を有するサーバを示し、右側のブロックは、権限を与えられたサーバにより分散台帳に公表される3つのタイプの証明書を示す。図1に示すように、運用者の役割を有するサーバは、発行者の役割をまったく有することなく自身の管理者証明書および他のサーバのサーバ証明書を分散台帳に追加する取引を公表する資格を与えられ、受託者の役割を有するサーバは、分散台帳に自身のルート証明書を追加する取引を公表する資格を与えられる。
図1の右側には、分散台帳での3つのタイプの証明書を示す。各管理者証明書を使用して、管理者証明書により署名されたサーバ証明書を検証でき、ルート証明書を使用して、ルート証明書を公表しているサーバにより署名された管理者証明書を検証できる。証明書の検証処理は、サーバ証明書または管理者証明書が配置されたどこからでも開始してよく、利用可能である場合には、サーバ証明書または管理者証明書とルート証明書の間にある、順次検証される他の中間的な管理者証明書を伴うルート証明書で終了してよい。その間、検証処理は、ルート証明書まで進む必要はなく、条件が満たされた、または満たされないときに終了できる。条件は、事前に承認されたリストの中に検証中の証明書があるか、または検証が開始した証明書で検証が終了するかどうかを含むがそれに限定されない。それにもかかわらず、受託者および運用者の役割を有するサーバの数、ルート証明書、管理者証明書、およびサーバ証明書の数、ならびに証明書の階層構造は、図1に示すものに限定されない。
どの役割がどのタイプの取引を分散台帳に公表できるかに関する分散台帳規則を示す以下の表は、役割と証明書の間の関係をより深く掘り下げている。
表によれば、受託者の役割を有するサーバは、運用者の役割、ルート証明書、および他のサーバに関連する管理者証明書を追加および削除する取引を分散台帳に公表する資格を有する。受託者の役割を有するサーバは、別のサーバのサーバ証明書を追加または取り消す資格がないことに留意する。受託者の役割を有するサーバは、分散台帳で受託者の役割を有する唯一のサーバではない限り、単体で他のサーバの受託者の役割を追加および除去する取引を公表する資格がない。その代わり、受託者の役割を有する、分散台帳で少なくとも1つのサーバの圧倒的多数のための集合的役割となるように規定された、受託者定足数の役割を有するサーバは、受託者の役割を有するサーバを追加および除去する取引を公表する資格がある。
受託者の役割とは対照的に、運用者の役割を有するサーバは、運用者の役割、管理者証明書、および他のサーバのサーバ証明書を追加および除去、または取り消す取引を分散台帳に公表する資格がある。受託者の役割を有するサーバおよび運用者の役割を有するサーバは、いずれも運用者の役割およびサーバの管理者証明書を追加、除去、および取り消す取引を公表できることに留意する。役割をなにも有しないサーバについては、サーバは、どんな取引も公表する資格がない。
受託者の役割とは対照的に、運用者の役割を有するサーバは、運用者の役割、管理者証明書、および他のサーバのサーバ証明書を追加および除去、または取り消す取引を分散台帳に公表する資格がある。受託者の役割を有するサーバおよび運用者の役割を有するサーバは、いずれも運用者の役割およびサーバの管理者証明書を追加、除去、および取り消す取引を公表できることに留意する。役割をなにも有しないサーバについては、サーバは、どんな取引も公表する資格がない。
発行者の役割および証明書を包含する分散台帳での証明書ストアは、互いに関連する2つのサーバの証明書認証にとって基本であるので、役割および証明書を追加および除去するための取引を公開する方法は、最初に導入される。証明書ストアは、最初に構築されたとき、自身に公表された開始取引から開始して、受託者の役割を有する一番初めのサーバを作成する。開始取引は、受託者の分散型識別子(decentralized identifier、DID)、受託者により公表される任意の取引の分散台帳署名を検証するための公開鍵、および受託者の役割を含む。
図2を参照する。本発明による、分散台帳に発行者資格および発行者証明書を公表する方法の実施形態が提供される。本実施形態での方法は、いずれも分散台帳ネットワークの一部である証明書要求サーバ(CR)および証明書発行ノード(CI)を伴う。CIは、1つまたは複数のサーバを含んでよい。方法は、CIが分散台帳で受託者定足数および受託者の役割を有するノードであるときに適用され、CRは、CIにより分散台帳に受託者または運用者の役割で追加されるように要求する。この方法では、役割およびサーバ証明書を有しないサーバは、方法の議論から除外される。分散に公表される取引は、役割および証明書を追加または除去することを意図することがあるので、役割および証明書を追加するためのステップS210~S240から以下のステップを含む。
ステップS200:CIは、公表される取引のタイプを決定する。取引のタイプは、役割および証明書を追加すること、役割を除去すること、証明書を取り消すことを含む。
ステップS210:役割および証明書を追加するという取引タイプを決定したとき、CIは、CRから資格関連情報を受信する。資格関連情報は、分散台帳に順次に追加される取引でCRの発行者資格または役割を追加するために必要とされ、CRのDID、台帳公開鍵、および役割を含む。基本的に、証明書ストアで役割を有する各サーバは、いずれも非対称鍵対に関係する台帳鍵対および証明書鍵対を有する。台帳対は、台帳公開鍵および台帳秘密鍵を有し、証明書対は、証明書公開鍵および証明書秘密鍵を有する。
サーバに関連する台帳秘密鍵は、サーバで記憶され、証明書ストアに公表される任意の取引に署名するサーバにより使用される。サーバに関連する台帳公開鍵は、CRを追加するための現在のステップで言及する取引など、サーバを追加するための取引のために分散台帳に送信される。その結果、分散台帳は、サーバの台帳公開鍵を用いてサーバにより署名されるその後の任意の取引を検証できる。一方では、サーバによりサーバの証明書秘密鍵を使用して、管理者証明書およびサーバ証明書の一方であってよい別のサーバの証明書に署名する。サーバの証明書公開鍵は、サーバにより署名された他のサーバの証明書を検証するためにサーバの証明書に含まれる。
サーバに関連する台帳秘密鍵は、サーバで記憶され、証明書ストアに公表される任意の取引に署名するサーバにより使用される。サーバに関連する台帳公開鍵は、CRを追加するための現在のステップで言及する取引など、サーバを追加するための取引のために分散台帳に送信される。その結果、分散台帳は、サーバの台帳公開鍵を用いてサーバにより署名されるその後の任意の取引を検証できる。一方では、サーバによりサーバの証明書秘密鍵を使用して、管理者証明書およびサーバ証明書の一方であってよい別のサーバの証明書に署名する。サーバの証明書公開鍵は、サーバにより署名された他のサーバの証明書を検証するためにサーバの証明書に含まれる。
ステップS220:CIは、発行者資格取引に署名して、分散台帳に発行者資格取引を提出する。発行者資格取引は、分散台帳にCRを搭載するのに役立ち、CRのDIDおよび台帳公開鍵、CIのDID、ならびに分散台帳に追加されるCRの役割を含み、CIの台帳秘密鍵により署名される。分散台帳規則からなる前述の表から、CRは、受託者または運用者の役割で追加されるように要求してよく、一方、CIは、受託者定足数または受託者の役割を担ってよい。CRが受託者の役割を要求するとき、CIは、受託者定足数の役割を担うべきであり、少なくとも1つのサーバを含む。CRが運用者の役割を要求するとき、CIは、受託者または運用者の役割を担ってよく、個々のサーバである。
ステップS230:CRおよびCIの一方は、CRに関する発行者証明書を作成し、発行者証明書に署名し、発行者証明書の署名者がCRではないときにCRに発行者証明書を送信する。CRが受託者の役割を要求するとき、発行者証明書を作成し、発行者証明書に署名するのはCRであり、発行者証明書は、ルート証明書である。CRが運用者の役割を要求するとき、発行者証明書を作成し、発行者証明書に署名するのはCIであり、発行者証明書は、管理者証明書である。
発行者証明書は、CRにより要求される役割に応じて、発行者証明書を作成するCRおよびCIの一方の証明書秘密鍵により署名される。発行者証明書の作成者がCIである場合、CIは、発行者証明書を記憶して後で検証するために、CRに発行者証明書を送信しなければならない。
発行者証明書は、CRにより要求される役割に応じて、発行者証明書を作成するCRおよびCIの一方の証明書秘密鍵により署名される。発行者証明書の作成者がCIである場合、CIは、発行者証明書を記憶して後で検証するために、CRに発行者証明書を送信しなければならない。
ステップS240:分散台帳で発行者資格取引が作成された後、発行者証明書を有するCRおよびCIの任意の一方は、発行者証明書取引に署名して、分散台帳に発行者証明書取引を提出する。発行者資格取引は、分散台帳で作成された後に初めて署名され、分散台帳に提出されるべきである。CRは、受託者の役割を要求するとき、自分自身のルート証明書を作成し、ルート証明書を有する唯一のCRであり、その結果、図3に示すように、発行者証明書取引に署名し、分散台帳に発行者証明書取引を提出するのはCRである。CRが運用者の役割を要求するとき、CIは、CRに関する管理者証明書を作成し、管理者証明書に署名し、CRに管理者証明書をさらに送信するので、CIもCRも管理者証明書を有し、したがって、CIおよびCRのいずれか一方は、図4および図5に示すように、発行者証明書取引に署名して分散台帳に発行者証明書取引を提出できる。
発行者証明書取引については、発行者証明書取引は、提出者のDID、証明書ID、発行者証明書、および提出者の署名を含む。提出者は、発行者証明書を有するCRおよびCIの任意の一方であってよい。証明書IDは、発行者証明書のハッシュ値である。発行者証明書は、CRの識別および証明書公開鍵、CRの任意選択の役割、および発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含む。CRの識別は、ウェブアドレス、たとえばwww.tbcasoft.comであってよいサブジェクト代替名(subject alternative name、SAN)である。CRの役割は、発行者証明書を所有するサーバに関連する発行者証明書の役割を検証および利用することを必要とするアプリケーションに提供されてよいので、任意選択である。発行者証明書取引を公表する前に、発行者証明書取引の提出者は、自身の台帳秘密鍵を用いて発行者証明書取引に署名する。
発行者証明書取引については、発行者証明書取引は、提出者のDID、証明書ID、発行者証明書、および提出者の署名を含む。提出者は、発行者証明書を有するCRおよびCIの任意の一方であってよい。証明書IDは、発行者証明書のハッシュ値である。発行者証明書は、CRの識別および証明書公開鍵、CRの任意選択の役割、および発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含む。CRの識別は、ウェブアドレス、たとえばwww.tbcasoft.comであってよいサブジェクト代替名(subject alternative name、SAN)である。CRの役割は、発行者証明書を所有するサーバに関連する発行者証明書の役割を検証および利用することを必要とするアプリケーションに提供されてよいので、任意選択である。発行者証明書取引を公表する前に、発行者証明書取引の提出者は、自身の台帳秘密鍵を用いて発行者証明書取引に署名する。
証明書要求サーバの役割に応じて、ステップS230は、CRの役割によって変わる異なるステップを含んでよい。CRの役割が受託者であるとき、図3は、CRが受託者の役割を要求するためのシーケンス図を示し、図4および図5は、CRが運用者の役割を要求するためのシーケンス図を示す。図6を参照する。CRが要求する役割に適合させるために、ステップS230は、以下のステップを含む。
ステップS231:CRにより要求された役割が受託者であるとき、CRは、ルート証明書を作成する。受託者の役割を有するサーバだけがルート証明書を追加できることを指定する分散台帳規則により、ルート証明書を作成するのはCRである。
CRの役割が運用者であるとき、ステップS230は、以下のステップを含む。
ステップS232:CRにより要求された役割が運用者であるとき、CRは、管理者証明書署名リクエスト(certificate signing request、CSR)をCIに送信する。管理者CSRは、運用者情報、およびCRの証明書公開鍵を含む。運用者情報は、CRのSAN、商号、部署名、市、州、国、および連絡先電子メールからなるフィールドを含む。
ステップS233:CIは、管理者CSRを用いて管理者証明書を作成し、CIの証明書公開鍵を用いて管理者証明書に署名し、管理者証明書を作成し、CRに管理者証明書を送信する。受託者および運用者の役割を有するサーバが管理者証明書を追加できることを指定する分散台帳規則のために、管理者証明書を作成するのはCIである。
図4と図5の違いは、発行者証明書取引を公表するサーバである。発行者証明取引を公表するための役割をサーバが有する限り、CRまたはCIが発行者証明書取引を公表するかどうかは問題とすべきではない。公表される役割は運用者であるので、図4で受託者または運用者の役割を有するCIおよび図5で運用者の役割を有するCRのいずれか一方は、発行者証明書取引を公表できる。
証明書ストアで任意のサーバを除去、または任意の証明書を取り消すことを意図するとき、サーバを除去するための取引、または証明書を取り消すための取引は、分散台帳に公表できる。それに応じて、前述の方法は、分散台帳で役割を有するサーバを除去するため、および証明書を取り消すための以下のステップをさらに含む。図2を参照する。前述の方法は、役割および証明書を除去、および取り消すための以下のステップをさらに含む。
ステップS250:役割を除去、および受託者の役割を有するサーバを除去するタイプを決定するとき、受託者の役割を有する少なくとも1つのサーバの圧倒的多数は、受託者除去取引を生成してサーバを除去し、受託者除去取引に署名し、分散台帳に受託者除去取引を提出する。現在のステップは、受託者の役割を有するサーバを除去するための動作を伴う。受託者除去取引は、サーバのDID、および少なくとも1つのサーバの圧倒的多数に対応する少なくとも1つのDIDを含み、少なくとも1つのサーバの圧倒的多数の少なくとも1つの台帳秘密鍵により署名される。
ステップS260:役割を除去し、運用者の役割を有する第1のサーバを除去するタイプを決定するとき、受託者または運用者の役割を有し、分散台帳に第1のサーバを追加する第2のサーバは、運用者除去取引を生成して分散台帳から第1のサーバを除去し、運用者除去取引に署名し、分散台帳に運用者除去取引を提出する。現在のステップは、運用者の役割を有するサーバを除去するための動作を伴う。運用者除去取引は、第2のサーバのDIDおよび第1のサーバのDIDを含み、第2のサーバの台帳秘密鍵により署名される。
ステップS270:分散台帳で証明書を取り消し、受託者または運用者の役割を有する第1のサーバの発行者証明書を取り消すタイプを決定するとき、受託者または運用者の役割を有し、発行者証明書を追加する第2のサーバは、証明書取消取引を生成して分散台帳で発行者証明書を取り消し、証明書取消取引に署名し、分散台帳に証明書取消取引を提出する。
第1のサーバが受託者の役割を担うとき、第2のサーバは、同様に受託者の役割を担うべきであり、第1のサーバが運用者の役割を担うとき、第2のサーバは、受託者または運用者の役割を担ってよいことに留意する。現在のステップは、第1のサーバが受託者の役割を担い、かつ第2のサーバが受託者の役割を担うときに発行者証明書、多くの場合、ルート証明書、または第1のサーバが運用者の役割を担い、かつ第2の役割が受託者または運用者の役割の一方を担うときに管理者証明書を除去するための動作を伴う。運用者取消取引は、発行者証明書の証明書IDおよび第2のサーバのDIDを含み、第2のサーバの台帳秘密鍵により署名される。
第1のサーバが受託者の役割を担うとき、第2のサーバは、同様に受託者の役割を担うべきであり、第1のサーバが運用者の役割を担うとき、第2のサーバは、受託者または運用者の役割を担ってよいことに留意する。現在のステップは、第1のサーバが受託者の役割を担い、かつ第2のサーバが受託者の役割を担うときに発行者証明書、多くの場合、ルート証明書、または第1のサーバが運用者の役割を担い、かつ第2の役割が受託者または運用者の役割の一方を担うときに管理者証明書を除去するための動作を伴う。運用者取消取引は、発行者証明書の証明書IDおよび第2のサーバのDIDを含み、第2のサーバの台帳秘密鍵により署名される。
分散台帳にサーバ証明書を追加するための取引が1つだけ存在するので、分散台帳にサーバ証明書を公表するための方法は、発行者資格取引がない状態で発行者の資格および証明書を公表するための前述の方法と異なる。
シーケンス図である図7は、本発明による、分散台帳にサーバ証明書を公開するための方法が以下のステップを含むことを示す。分散台帳は、分散台帳ネットワークにより維持される。分散台帳ネットワークは、多数のサーバを含み、多数のサーバのうち2つは、証明書発行ノード(CI)および証明書要求サーバ(CR)である。
シーケンス図である図7は、本発明による、分散台帳にサーバ証明書を公開するための方法が以下のステップを含むことを示す。分散台帳は、分散台帳ネットワークにより維持される。分散台帳ネットワークは、多数のサーバを含み、多数のサーバのうち2つは、証明書発行ノード(CI)および証明書要求サーバ(CR)である。
ステップS610:CIは、CRから証明書関連情報を受信する。サーバ証明書だけが作成される必要があるので、証明書関連情報は、CIがCRから必要とするすべてである。証明書関連情報は、サーバ情報および認証公開鍵を含む。サーバ情報は、CRのインターネット・プロトコル(internet protocol、IP)・アドレスおよびホスト名を含む。
ステップS620:CIは、CRに関するサーバ証明書を作成し、サーバ証明書に署名し、CRにサーバ証明書を送信する。サーバ証明書は、CRのSANおよび認証公開鍵を含み、CIの秘密鍵により署名される。
ステップS630:CIは、サーバ証明書取引に署名して、分散台帳にサーバ証明書取引を提出する。サーバ証明書取引は、サーバ証明書の証明書ID、サーバ証明書、およびCIのDIDを含み、CIの台帳秘密鍵により署名される。証明書ISは、サーバ証明書のハッシュ値である。
分散台帳に追加されたサーバ証明書を取り消すために、分散台帳にサーバ証明書を公表するための方法は、以下のステップをさらに含む。
運用者の役割を有し、サーバ証明書を追加するサーバは、証明書取消取引を生成して分散台帳でサーバ証明書を取り消し、証明書取消取引に署名し、分散台帳に証明書取消取引を提出する。証明書取消取引は、サーバ証明書の証明書ID、およびサーバ証明書を追加するサーバのDIDを含み、発行者証明書を追加するサーバの台帳秘密鍵により署名される。
分散台帳に役割および証明書を追加および除去する方法を実装後、関心のある次の主題は、互いに関連するサーバに関する証明書を使用して互いのサーバ証明書の真正性を検証して、相互認証された情報交換を確立する方法である。図8を参照する。本発明による、分散台帳を維持している分散台帳ネットワークで接続サーバ(CS)および受信サーバ(RS)の証明書を認証するための方法は、RSの側から以下のステップを含む。
ステップS710:RSおよびCSは、自身の識別を交換する。RSの識別は、RSのSANであり、CSの識別は、CSのSANである。RSおよびCSは、互いに自身のSANを交換する。識別に加えて、一実施形態では、RSおよびCSは、図9に示すように自身の証明書をさらに交換できる。
ステップS720:RSは、CS識別に基づき分散台帳からCSの証明書およびCS証明書発行者の公開鍵を取り出す。CS識別を使用して、分散台帳からCSの証明書、およびCS証明書発行者の公開鍵を有するCS証明書発行者の証明書を取り出すことが可能である。CS証明書発行者の公開鍵は、CS証明書発行者の証明書を有する、CS証明書発行者により署名されたCSの証明書を検証するのに役立つ。RSの識別を用いて分散台帳から証明書をまったく取り出すことができない場合、分散台帳は、RSの証明書が、時間のかからない簡単な方法で真正ではないことを信号で伝えることが可能である。
ステップS730:RSは、CS証明書発行者の公開鍵を用いてCSの証明書が真正であるかどうかを検証する。CSの証明書、およびCS証明書発行者の公開鍵は、RSに利用可能になると、CSの証明書が真正であることを直接に検証するために使用できる。選択肢として他の検証取り組み方法が利用できる。交換された証明書を使用する一検証取り組み方法では、RSは、交換されたCSの証明書と取り出されたCSの証明書の両方がCS証明書発行者の公開鍵と調和するかどうかをさらに検証する。別の検証取り組み方法では、RSは、CSの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて現在の証明書に署名する次の証明書を取り出して、次の証明書での公開鍵を用いて現在の証明書を検証して、現在の証明書が妥当であるか、または検証条件が満たされたときにCSの証明書が真正であると検証されたと判断し、そうではない場合、現在の証明書を次の証明書に更新する。たとえば、検証条件は、検証される証明書が事前に承認されたリストにあるかどうかであってよい。
CSの証明書が真正であると検証された後、そのことは、RSの側での片側だけの証明書認証がうまく検証され、CSが、情報交換するのに信頼できるサーバであり、RSがCSとの間で秘密情報を自発的に送受信することを意味する。
方法は、以下のようにRSの証明書を認証するための類似ステップをさらに含む。
ステップS740:CSは、RS識別に基づき分散台帳からRSの証明書およびRS証明書発行者の公開鍵を取り出す。
ステップS750:CSは、RS証明書発行者の公開鍵を用いてRSの証明書が真正であるかどうかを検証する。
同様に、RSの証明書が真正であると検証された後、そのことは、CSの側での片側だけの証明書認証がうまく検証され、RSが、情報を交換するのに信頼できるサーバであり、CSがRSとの間で秘密情報を自発的に送受信することを意味する。
RSの証明書の認証とCSの証明書の認証との間には重複があるため、ステップS740およびS750に関する詳細な説明を繰り返さない。
前述の方法について詳しく述べたので、前述の方法を遂行するためのシステムが、次に論じる主題である。分散台帳に発行者資格および発行者証明書を公表するための方法、分散台帳にサーバ証明書を公表するための方法、および分散台帳ネットワークで2つのサーバの証明書を認証するための方法という3つの方法が存在するので、3つのシステムは、それぞれの方法に対応、すなわち分散台帳に発行者資格および発行者証明書を公表するための分散台帳に基づくシステム、分散台帳にサーバ証明書を公表するための分散台帳に基づくシステム、および証明書認証用の分散台帳に基づくシステムとすることが可能である。
発行者資格および発行者証明書を公表するための分散台帳に基づくシステムに関与するのは、CR、CI、および分散台帳ネットワークである。CRおよびCIは、それぞれサーバおよびノードである。ノードであるので、CIは、受託者定足数の役割を有するときには少なくとも1つのサーバを含んでよく、受託者または運用者の役割を有するときには1つのサーバに過ぎなくてよい。CRおよびCIは、両方とも分散台帳に取引を公表する必要があるかどうかに応じて分散台帳ネットワークの一部であっても、そうではなくてもよい。CR10が受託者の役割を要求し、かつCI20が受託者定足数の役割を担うとき、CR10およびCI20はすべて、CR10もCI20もルート証明書、および受託者の役割を有するCR10を分散台帳に追加するための取引を公表するので、図10に示すように分散台帳ネットワーク30の中に留まらなければならない。
CR10が運用者の役割を要求し、かつCI20が受託者の役割を担うとき、CI20は、分散台帳ネットワーク30の中に常に留まっていなければならず、一方、CR10は、発行者証明書取引がCR10またはCI20により公表されてよいので分散台帳ネットワーク30の中に留まっても、留まらなくともよい。発行者証明書取引がCR10により公表されたとき、CR10はまた、図10に示すように分散台帳ネットワーク30の中に留まらなければならない。発行者証明書取引がCIにより公表されたとき、CRは、図11に示すように分散台帳ネットワーク30の外に留まってよいが、分散台帳ネットワーク30に接続する必要がある。
図11に示すように、サーバ証明書を公表するための分散台帳に基づくシステムはまた、それぞれサーバであるCR10およびCI20を含む。分散台帳にサーバ証明書を公開できる役割を有する唯一のサーバであるので、システムのCI20は、分散台帳ネットワーク30の中に留まるべきである。CI20と異なり、CR10は、どんな取引も公表する役割がないので、分散台帳ネットワーク30の中にそのように留まる必要はない。しかしながら、CR10は、分散台帳ネットワークに接続されるべきである。
図12に示す、証明書認証用の分散台帳に基づくシステムについて、システムに伴う接続サーバ(CS)40および受信サーバ(RS)50は、分散台帳ネットワーク30に接続されたままでいる必要がある。証明書認証は、任意の取引を公表することに関係しない主題であるが、接続サーバ(CS)40も受信サーバ(RS)も、検証処理中に分散台帳から読み出さなければならない。それに加えて、接続サーバ(CS)40および受信サーバ(RS)は、互いに接続状態にあると考えられる。
CR10が運用者の役割を要求し、かつCI20が受託者の役割を担うとき、CI20は、分散台帳ネットワーク30の中に常に留まっていなければならず、一方、CR10は、発行者証明書取引がCR10またはCI20により公表されてよいので分散台帳ネットワーク30の中に留まっても、留まらなくともよい。発行者証明書取引がCR10により公表されたとき、CR10はまた、図10に示すように分散台帳ネットワーク30の中に留まらなければならない。発行者証明書取引がCIにより公表されたとき、CRは、図11に示すように分散台帳ネットワーク30の外に留まってよいが、分散台帳ネットワーク30に接続する必要がある。
図11に示すように、サーバ証明書を公表するための分散台帳に基づくシステムはまた、それぞれサーバであるCR10およびCI20を含む。分散台帳にサーバ証明書を公開できる役割を有する唯一のサーバであるので、システムのCI20は、分散台帳ネットワーク30の中に留まるべきである。CI20と異なり、CR10は、どんな取引も公表する役割がないので、分散台帳ネットワーク30の中にそのように留まる必要はない。しかしながら、CR10は、分散台帳ネットワークに接続されるべきである。
図12に示す、証明書認証用の分散台帳に基づくシステムについて、システムに伴う接続サーバ(CS)40および受信サーバ(RS)50は、分散台帳ネットワーク30に接続されたままでいる必要がある。証明書認証は、任意の取引を公表することに関係しない主題であるが、接続サーバ(CS)40も受信サーバ(RS)も、検証処理中に分散台帳から読み出さなければならない。それに加えて、接続サーバ(CS)40および受信サーバ(RS)は、互いに接続状態にあると考えられる。
本発明での方法およびシステムは第一に、分散台帳が不変であり、かつ単一の集中化した権限の制御を受けることなく共用されるという事実から生じる証明書不変性を提供するという点で有利であり、分散台帳解決策は、証明書認証に非常によく調和するようになる。第二に、証明書の発行および取消しの履歴もまた、分散台帳に記録される。証明書可用性について、分散台帳ネットワークでの分散台帳は、分散台帳ネットワークでのすべての分散台帳全体にわたって整合性を保証するために合意機構により絶えず維持されるので、分散台帳ネットワークでのサーバは、分散台帳ネットワークで分散台帳を管理する必要がない。
本発明の数多くの特徴および利点が、本発明の構造および機能の詳細と共に前述の説明で示されたとしても、本開示は例示でしかない。添付の特許請求の範囲が表現する用語の広い一般的な意味により示される最大限の範囲まで、本発明の原理の範囲内で特に部分の形状、サイズ、および配置に関して詳細に変更を行ってよい。
Claims (32)
- 分散台帳を維持している分散台帳ネットワークに通信可能に互いに接続された接続サーバ(connecting server、CS)および受信サーバ(receiving server、RS)の証明書を認証するための方法であって、
(a)前記RSは、前記CSと識別を交換するステップと、
(b)前記RSは、CS識別に基づき前記分散台帳からCSの証明書およびCS証明書発行者の公開鍵を取り出すステップと、
(c)前記RSは、前記CS証明書発行者の公開鍵を用いて前記CSの証明書が真正であるかどうかを検証するステップと、
(d)前記CSの証明書が真正であることが検証された後、前記RSは、前記CSが前記RSから秘密情報を受信するように認証されていると判断するステップと、を備える、
方法。 - (1)前記CSは、RS識別に基づき前記分散台帳からRSの証明書およびRS証明書発行者の公開鍵を取り出し、(2)前記CSは、前記RS証明書発行者の公開鍵を用いて前記RSの証明書が真正であるかどうかを検証し、(3)前記RSの証明書が検証された後、前記CSは、前記RSが前記CSから秘密情報を受信するように認証されていると判断することを特徴とする、請求項1に記載の方法。
- 前記ステップ(a)で、前記RSは、前記CSと証明書をさらに交換することを特徴とする、請求項2に記載の方法。
- 前記ステップ(c)および前記ステップ(2)で、前記RSは、交換された前記CSの証明書と取り出された前記CSの証明書の両方が前記CS証明書発行者の公開鍵と調和するかどうかをさらに検証し、前記CSは、交換された前記RSの証明書と取り出された前記RSの証明書の両方が前記RS証明書発行者の公開鍵と調和するかどうかをさらに検証することを特徴とする、請求項3に記載の方法。
- 前記CS識別は、前記CSのサブジェクト代替名であり、前記RS識別は、前記RSのサブジェクト代替名であることを特徴とする、請求項1に記載の方法。
- 前記ステップ(c)で、前記RSは、前記CSの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて前記現在の証明書に署名する前記次の証明書を取り出して、前記次の証明書での公開鍵を用いて前記現在の証明書を検証して、前記現在の証明書が検証された、または検証条件が満たされたときに前記CSの証明書が真正であると検証されたと判断し、そうではない場合、前記現在の証明書を前記次の証明書に更新し、前記ステップ(2)で、前記CSは、前記RSの証明書を現在の証明書として初期化し、ループして、次の証明書の証明書発行者の秘密鍵を用いて前記現在の証明書に署名する前記次の証明書を取り出して、前記次の証明書での公開鍵を用いて前記現在の証明書を検証して、前記現在の証明書が検証された、または前記検証条件が満たされたときに前記RSの証明書が真正であると検証されたと判断し、そうではない場合、前記現在の証明書を前記次の証明書に更新することを特徴とする、請求項1に記載の方法。
- 互いに通信状態にある証明書発行ノード(certificate-issuing node、CI)および証明書要求サーバ(certificate-requesting server、CR)を通して、前記CIを含む分散台帳ネットワークにより維持された分散台帳に発行者資格および発行者証明書を公表するための方法であって、
(a)前記CIは、前記CRから資格関連情報を受信するステップと、
(b)前記CIは、発行者資格取引に署名して、前記分散台帳に前記発行者資格取引を提出するステップと、
(c)前記CRおよび前記CIの一方は、前記CRに関する発行者証明書を作成し、前記発行者証明書に署名し、前記発行者証明書の署名者が前記CRではないときに前記CRに前記発行者証明書を送信するステップと、
(d)前記分散台帳で前記発行者資格取引が作成された後、前記発行者証明書を有する前記CRおよび前記CIの任意の一方は、発行者証明書取引に署名して、前記分散台帳に前記発行者証明書取引を提出するステップと、を備える、
方法。 - 前記資格関連情報は、前記CRの分散型識別子(decentralized identifier、DID)、台帳公開鍵、および役割を含むことを特徴とする、請求項7に記載の方法。
- 前記発行者資格取引は、前記CRのDIDおよび台帳公開鍵、前記CIのDID、ならびに前記分散台帳に追加されるCRの役割を含むことを特徴とする、請求項7に記載の方法。
- 前記CIは、CIの台帳秘密鍵を用いて前記発行者資格取引に署名することを特徴とする、請求項7に記載の方法。
- 前記発行者証明書取引は、提出者のDID、証明書ID、前記発行者証明書、および前記提出者の署名を含み、前記証明書IDは、前記発行者証明書のハッシュ値であり、前記発行者証明書は、前記CRの識別および証明書公開鍵、前記CRの任意選択の役割、ならびに前記発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含むことを特徴とする、請求項9に記載の方法。
- 前記CRの識別は、サブジェクト代替名であることを特徴とする、請求項11に記載の方法。
- 発行者証明書取引提出者は、自身の台帳秘密鍵を用いて前記発行者証明書取引に署名し、前記発行者証明書取引が前記CRにより提出されたとき、前記分散台帳ネットワークは、前記CRを含み、前記発行者証明書取引が前記CIにより提出されたとき、前記分散台帳ネットワークは、前記CRを含まないことを特徴とする、請求項7に記載の方法。
- 前記分散台帳に追加される前記CRの役割は、受託者であり、前記分散台帳での前記CIの役割は、受託者定足数であり、前記受託者定足数は、前記分散台帳内の少なくとも1つのサーバの圧倒的多数が前記受託者の役割を有する発行役割であると規定され、前記CIは、前記少なくとも1つのサーバの前記圧倒的多数を含むことを特徴とする、請求項9に記載の方法。
- 前記分散台帳に追加される前記CRの役割は、運用者であり、前記分散台帳での前記CIの役割は、前記受託者または前記運用者であることを特徴とする、請求項14に記載の方法。
- 前記ステップ(c)で、前記CRは、前記発行者証明書を作成し、前記CRの前記証明書公開鍵と対をなす前記CRの証明書秘密鍵を用いて前記発行者証明書に署名することを特徴とする、請求項14に記載の方法。
- 前記ステップ(c)で、前記CIは、前記CRから発行者証明書署名リクエスト(certificate signing request、CSR)を受信し、前記発行者CSRを用いて前記発行者証明書に署名し、前記CIの前記証明書公開鍵と対をなす前記CIの証明書秘密鍵を用いて前記発行者証明書に署名し、前記発行者CSRは、運用者情報、および前記CRの証明書公開鍵を含むことを特徴とする、請求項15に記載の方法。
- 前記運用者情報は、前記CRのサブジェクト代替名、商号、部署名、市、州、国、および連絡先電子メールからなるフィールドを含むことを特徴とする、請求項17に記載の方法。
- 互いに通信状態にある証明書発行サーバ(CI)および証明書要求サーバ(CR)を通して、前記CIを含む分散台帳ネットワークにより維持された分散台帳にサーバ証明書を公表するための方法であって、
(a)前記CIは、前記CRから証明書関連情報を受信するステップと、
(b)前記CIは、前記CRに関するサーバ証明書を作成し、前記サーバ証明書に署名し、前記CRに前記サーバ証明書を送信するステップと、
(c)前記CIは、サーバ証明書取引に署名して、前記分散台帳に前記サーバ証明書取引を提出するステップと、を備える、
方法。 - 前記証明書関連情報は、サーバ情報および認証公開鍵を含み、前記サーバ情報は、前記CRのインターネット・プロトコル(internet protocol、IP)・アドレスおよびホスト名を含むことを特徴とする、請求項19に記載の方法。
- 前記サーバ証明書取引は、前記サーバ証明書の証明書ID、前記サーバ証明書、および前記CIのDIDを含み、前記CIの台帳秘密鍵により署名され、前記サーバ証明書は、前記CRのサブジェクト代替名、および前記認証公開鍵を含み、前記CIの証明書秘密鍵により署名され、前記証明書IDは、前記サーバ証明書のハッシュ値であることを特徴とする、請求項20に記載の方法。
- 前記分散台帳でサーバ証明書を取り消すとき、前記運用者の役割を有し前記サーバ証明書を追加するサーバは、証明書取消取引を生成して前記分散台帳で前記サーバ証明書を取り消し、前記証明書取消取引に署名し、前記分散台帳に前記証明書取消取引を提出し、前記証明書取消取引は、前記サーバ証明書の前記証明書ID、および前記サーバ証明書を追加する前記サーバのDIDを含み、前記発行者証明書を追加する前記サーバの台帳秘密鍵により署名されることを特徴とする、請求項19に記載の方法。
- 証明書認証用の分散台帳に基づくシステムであって、
分散台帳を維持する分散台帳ネットワークと、
前記分散台帳ネットワークに通信可能に接続された接続サーバ(CS)と、
前記分散台帳ネットワークに通信可能に接続された受信サーバ(RS)であって、前記CSと識別を交換し、CS識別に基づき前記分散台帳からCSの証明書およびCS証明書発行者の公開鍵を取り出して前記CSの証明書が真正であるかどうかを検証し、前記CSの証明書が真正であることを検証したときに前記CSが前記RSから秘密情報を受信するように認証されていると判断するRSと、を備える、
システム。 - 前記CSは、RS識別に基づき前記分散台帳からRSの証明書およびRS証明書発行者の公開鍵を取り出して前記RSの証明書が真正であるかどうかを検証し、前記RSの証明書が真正であることを検証したときに前記RSが前記CSから秘密情報を受信するように認証されていると判断することを特徴とする、請求項23に記載のシステム。
- 前記RSは、前記CSと証明書をさらに交換することを特徴とする、請求項24に記載のシステム。
- 前記RSは、交換された前記CSの証明書と取り出された前記CSの証明書の両方が前記CS証明書発行者の公開鍵と調和するかどうかを検証し、前記CSは、交換された前記RSの証明書と取り出された前記RSの証明書の両方が前記RS証明書発行者の公開鍵と調和するかどうかを検証することを特徴とする、請求項25に記載のシステム。
- 発行者資格および発行者証明書を公表するための分散台帳に基づくシステムであって、
証明書要求サーバ(CR)と、
分散台帳を維持し、前記CRに通信可能に接続され、証明書発行ノード(CI)を含む分散台帳ネットワークと、を備え、
前記CIは、前記CRから資格関連情報を受信し、発行者資格取引に署名し、分散台帳に前記発行者資格取引を提出し、
前記CRおよび前記CIの一方は、前記CRに関する発行者証明書をさらに作成し、前記発行者証明書の署名者が前記CRではないときに前記CRに前記発行者証明書を送信し、
前記分散台帳で前記発行者資格取引が作成された後、前記発行者証明書を有する前記CRおよび前記CIの一方は、発行者証明書取引に署名して、前記分散台帳に前記発行者証明書取引を提出する、ことを特徴とする、
システム。 - 前記資格関連情報は、前記CRの分散型識別子(DID)、台帳公開鍵、および役割を含むことを特徴とする、請求項27に記載のシステム。
- 前記発行者資格取引は、前記CRのDIDおよび台帳公開鍵、CIのDID、ならびに前記分散台帳に追加されるCRの役割を含むことを特徴とする、請求項27に記載のシステム。
- 前記CIは、CIの台帳秘密鍵を用いて前記発行者資格取引に署名することを特徴とする、請求項27に記載のシステム。
- 前記発行者証明書取引は、提出者のDID、証明書ID、前記発行者証明書、および前記提出者の署名を含み、前記証明書IDは、前記発行者証明書のハッシュ値であり、前記発行者証明書は、前記CRの識別および証明書公開鍵、前記CRの任意選択の役割、ならびに前記発行者証明書の証明書署名者の証明書秘密鍵により署名された署名を含むことを特徴とする、請求項30に記載のシステム。
- 発行者証明書取引提出者は、自身の台帳秘密鍵を用いて前記発行者証明書取引に署名し、前記発行者証明書取引が前記CRにより提出されたとき、前記分散台帳ネットワークは、前記CRを含み、前記発行者証明書取引が前記CIにより提出されたとき、前記分散台帳ネットワークは、前記CRを含まないことを特徴とする、請求項27に記載のシステム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962923472P | 2019-10-18 | 2019-10-18 | |
US62/923,472 | 2019-10-18 | ||
PCT/US2020/056393 WO2021077120A1 (en) | 2019-10-18 | 2020-10-19 | Distributed ledger-based methods and systems for certificate authentication |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2022552420A true JP2022552420A (ja) | 2022-12-15 |
Family
ID=75538778
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022523229A Pending JP2022552420A (ja) | 2019-10-18 | 2020-10-19 | 証明書認証用の分散台帳に基づく方法およびシステム |
Country Status (6)
Country | Link |
---|---|
US (1) | US20220294647A1 (ja) |
EP (1) | EP4046330A4 (ja) |
JP (1) | JP2022552420A (ja) |
CN (1) | CN114930770A (ja) |
TW (1) | TWI818209B (ja) |
WO (1) | WO2021077120A1 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210314293A1 (en) * | 2020-04-02 | 2021-10-07 | Hewlett Packard Enterprise Development Lp | Method and system for using tunnel extensible authentication protocol (teap) for self-sovereign identity based authentication |
US20220393883A1 (en) * | 2021-06-03 | 2022-12-08 | Unisys Corporation | Machine-to machine authentication through trusted chain of ownership |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9876775B2 (en) * | 2012-11-09 | 2018-01-23 | Ent Technologies, Inc. | Generalized entity network translation (GENT) |
US10333705B2 (en) * | 2016-04-30 | 2019-06-25 | Civic Technologies, Inc. | Methods and apparatus for providing attestation of information using a centralized or distributed ledger |
US20170346639A1 (en) * | 2016-05-24 | 2017-11-30 | Business Information Exchange System Corp. | Public Key Infrastructure based on the Public Certificates Ledger |
WO2018057510A1 (en) * | 2016-09-20 | 2018-03-29 | United States Postal Service | Methods and systems for a digital trust architecture |
US11055802B2 (en) * | 2017-09-22 | 2021-07-06 | Sensormatic Electronics, LLC | Methods and apparatus for implementing identity and asset sharing management |
US10454878B2 (en) * | 2017-10-04 | 2019-10-22 | The Dun & Bradstreet Corporation | System and method for identity resolution across disparate distributed immutable ledger networks |
US11641278B2 (en) * | 2018-03-27 | 2023-05-02 | Workday, Inc. | Digital credential authentication |
GB201815396D0 (en) * | 2018-09-21 | 2018-11-07 | Nchain Holdings Ltd | Computer implemented system and method |
-
2020
- 2020-10-19 WO PCT/US2020/056393 patent/WO2021077120A1/en unknown
- 2020-10-19 JP JP2022523229A patent/JP2022552420A/ja active Pending
- 2020-10-19 US US17/769,759 patent/US20220294647A1/en active Pending
- 2020-10-19 CN CN202080072879.4A patent/CN114930770A/zh active Pending
- 2020-10-19 EP EP20877681.5A patent/EP4046330A4/en active Pending
- 2020-11-26 TW TW109141617A patent/TWI818209B/zh active
Also Published As
Publication number | Publication date |
---|---|
CN114930770A (zh) | 2022-08-19 |
EP4046330A1 (en) | 2022-08-24 |
TWI818209B (zh) | 2023-10-11 |
EP4046330A4 (en) | 2024-02-14 |
WO2021077120A1 (en) | 2021-04-22 |
US20220294647A1 (en) | 2022-09-15 |
TW202217701A (zh) | 2022-05-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10764067B2 (en) | Operation of a certificate authority on a distributed ledger | |
US11706038B1 (en) | System and method for distributed PKI root | |
AU2022204148B2 (en) | Methods and apparatus for providing blockchain participant identity binding | |
US10848325B1 (en) | Systems and methods for notary agent for public key infrastructure names | |
US20210273779A1 (en) | Hash-based digital signatures for hierarchical internet public key infrastructure | |
US10284379B1 (en) | Public key infrastructure based on the public certificates ledger | |
JP5215289B2 (ja) | 分散式の委任および検証のための方法、装置、およびシステム | |
JP2022504420A (ja) | デジタル証明書の発行方法、デジタル証明書発行センター、記憶媒体およびコンピュータプログラム | |
CN109104396B (zh) | 一种基于代理签名的区块链代理授权方法、介质 | |
WO2018184446A1 (zh) | 实现ca互信的方法、装置、系统和电子设备 | |
CN113824563B (zh) | 一种基于区块链证书的跨域身份认证方法 | |
WO2014035748A1 (en) | Method and device for dynamically updating and maintaining certificate path data across remote trust domains | |
US20030079125A1 (en) | System and method for electronic certificate revocation | |
CN110855445B (zh) | 一种基于区块链的证书管理方法、装置及存储设备 | |
JP2023503607A (ja) | 自動デジタル証明書検証のための方法およびデバイス | |
EP1668815B1 (en) | Delegated certificate authority | |
KR20220006097A (ko) | 블록체인을 이용한 공개 키 관리를 위한 방법 및 디바이스 | |
JP2022552420A (ja) | 証明書認証用の分散台帳に基づく方法およびシステム | |
WO2022116734A1 (zh) | 数字证书签发的方法、装置、终端实体和系统 | |
Osmov et al. | On the blockchain-based general-purpose public key infrastructure | |
WO2022222722A1 (zh) | Id-pkc信息处理方法、装置、节点及存储介质 | |
CN113672959A (zh) | 一种可溯源的基于区块链的无纸化办公痕迹保留方法 | |
WO2023287435A1 (en) | Blockchain for digital certificate transactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20231011 |