DPKI: ブロックチェーンを使用して集中型 PKI の欠点を解消

オープン ネットワークでのデータ保護を実現するために一般的に使用される補助ツールの XNUMX つがデジタル証明書テクノロジであることは周知の事実です。 ただし、このテクノロジーの主な欠点は、デジタル証明書を発行するセンターに対する無条件の信頼であることは周知の事実です。 ENCRY のテクノロジーおよびイノベーション担当ディレクターの Andrey Chmora 氏は、組織化への新しいアプローチを提案しました。 公開鍵インフラストラクチャ (公開鍵インフラストラクチャ、 PKI）、現在の欠点を解消するのに役立ち、分散台帳（ブロックチェーン）テクノロジーを使用します。 しかし、まず最初に。

現在の公開鍵インフラストラクチャーがどのように機能するのかをよく理解しており、その主要な欠点を知っている場合は、以下で提案している変更内容に進んでください。

デジタル署名と証明書とは何ですか?インターネット上でのやり取りには、常にデータの転送が伴います。 私たちは皆、データが安全に送信されることを保証することに関心を持っています。 しかし、セキュリティとは何でしょうか? 最も求められているセキュリティ サービスは、機密性、完全性、信頼性です。 この目的のために、現在、非対称暗号化、つまり公開鍵を使用した暗号化の方法が使用されています。

これらのメソッドを使用するには、対話の対象が XNUMX つの個別のペアになったキー (公開キーと秘密キー) を持っている必要があるという事実から始めましょう。 彼らの協力により、上で述べたセキュリティ サービスが提供されます。

情報転送の機密性はどのように確保されますか? データを送信する前に、送信加入者は受信者の公開鍵を使用してオープン データを暗号化（暗号変換）し、受信者はペアの秘密鍵を使用して受信した暗号文を復号します。

送信される情報の完全性と信頼性はどのようにして達成されるのでしょうか? この問題を解決するために、別のメカニズムが作成されました。 オープンデータは暗号化されませんが、暗号化ハッシュ関数を適用した結果、つまり入力データシーケンスの「圧縮された」イメージは暗号化された形式で送信されます。 このようなハッシュの結果は「ダイジェスト」と呼ばれ、送信側加入者 (「証人」) の秘密鍵を使用して暗号化されます。 ダイジェストが暗号化された結果、デジタル署名が得られます。 これは平文とともに受信加入者 (「検証者」) に送信されます。 彼は証人の公開鍵のデジタル署名を復号し、それを暗号化ハッシュ関数を適用した結果と比較します。暗号化ハッシュ関数は、検証者が受信したオープンデータに基づいて独自に計算します。 それらが一致する場合、これは、データが送信側加入者によって本物の完全な形式で送信され、攻撃者によって変更されていないことを示します。

個人データと支払い情報を扱うほとんどのリソース (銀行、保険会社、航空会社、支払いシステム、税務署などの政府ポータル) は、非対称暗号化方式を積極的に使用しています。

デジタル証明書はそれと何の関係があるのでしょうか? それは簡単です。 最初と XNUMX 番目のプロセスには両方とも公開キーが含まれており、公開キーが中心的な役割を果たすため、キーが実際に送信者 (署名検証の場合は証人) または受信者に属しており、公開キーが実際に所有されていないことを確認することが非常に重要です。攻撃者のキーに置き換えられます。 このため、公開キーの信頼性と完全性を保証するためにデジタル証明書が存在します。

注: 公開キーの信頼性と完全性は、公開データの信頼性と完全性とまったく同じ方法、つまり電子デジタル署名 (EDS) を使用して確認されます。
デジタル証明書はどこから来たのでしょうか?信頼された認証局、つまり認証局 (CA) は、デジタル証明書の発行と維持を担当します。 申請者は CA に証明書の発行を要求し、登録センター (CR) で本人確認を受け、CA から証明書を受け取ります。 CA は、証明書の公開キーが発行対象のエンティティに正確に属していることを保証します。

公開鍵の信頼性を確認しない場合、攻撃者がこの鍵を転送/保管する際に、公開鍵を自分のものに置き換える可能性があります。 置換が行われた場合、攻撃者は送信側加入者が受信側加入者に送信するすべてのものを復号したり、オープン データを独自の裁量で変更したりできるようになります。

デジタル証明書は、非対称暗号化が利用できる場合はどこでも使用されます。 最も一般的なデジタル証明書の XNUMX つは、HTTPS プロトコルを介した安全な通信のための SSL 証明書です。 SSL 証明書の発行には、さまざまな管轄区域に登録されている何百もの企業が関与しています。 主なシェアは、IdenTrust、Comodo、GoDaddy、GlobalSign、DigiCert、CERTUM、Actalis、Secom、Trustwave の XNUMX ～ XNUMX の大規模信頼センターにかかっています。

CA と CR は PKI のコンポーネントであり、以下も含まれます。

• ディレクトリを開く – デジタル証明書の安全な保管を提供する公開データベース。
• 失効した証明書のリスト – 失効した公開鍵のデジタル証明書を安全に保管する公開データベース (ペアの秘密鍵の漏洩などにより)。 インフラストラクチャ主体は、このデータベースに個別にアクセスすることも、検証プロセスを簡素化する専用のオンライン証明書ステータス プロトコル (OCSP) を使用することもできます。
• 証明書のユーザー – CA とユーザー契約を締結し、デジタル署名を検証し、証明書の公開キーに基づいてデータを暗号化する、サービスを提供する PKI サブジェクト。
• フォロワー – 証明書の公開鍵とペアになった秘密鍵を所有しており、CA と加入者契約を結んでいる PKI サブジェクトを提供します。 加入者は同時に証明書のユーザーになることができます。

したがって、CA、CR、オープン ディレクトリなどの公開キー インフラストラクチャの信頼できるエンティティは、次の責任を負います。

1. 申請者の身元が本物であることの確認。
2. 公開鍵証明書のプロファイリング。
3. 本人確認が確実に行われた申請者に対して公開鍵証明書を発行する。
4. 公開鍵証明書のステータスを変更します。
5. 公開鍵証明書の現在のステータスに関する情報を提供します。

PKI の欠点は何ですか?PKI の根本的な欠陥は、信頼できるエンティティが存在することです。
ユーザーは CA と CR を無条件に信頼する必要があります。 しかし、実践が示すように、無条件の信頼は深刻な結果を伴います。

過去 XNUMX 年間、この分野ではインフラの脆弱性に関連した大きなスキャンダルがいくつかありました。

— 2010 年に、RealTek と JMicron から盗んだデジタル証明書を使用して署名された Stuxnet マルウェアがオンラインで拡散し始めました。

- 2017 年、Google はシマンテックが大量の偽造証明書を発行したとして非難しました。 当時、シマンテックは生産量の点で最大の CA の 70 つでした。 Google Chrome 1 ブラウザでは、この会社とその関連センターである GeoTrust および Thawte が発行した証明書のサポートが 2017 年 XNUMX 月 XNUMX 日より前に停止されました。

CA が侵害され、その結果、CA 自身だけでなく、ユーザーや加入者も含めた全員が被害を受けました。 インフラに対する信頼は損なわれている。 さらに、デジタル証明書は政治的紛争の状況でブロックされる可能性があり、これも多くのリソースの運用に影響を及ぼします。 これはまさに、ロシア大統領政権が数年前に懸念していたことであり、2016 年には、RuNet 上のサイトに SSL 証明書を発行する国家認証センターを設立する可能性について議論されました。 現在の情勢は、ロシアの国家ポータルさえも 使用する アメリカの企業 Comodo または Thawte (Symantec の子会社) によって発行されたデジタル証明書。

別の問題があります - 質問 ユーザーの一次認証（認証）。 個人的に直接連絡することなく、CA にデジタル証明書の発行要求を連絡したユーザーを特定するにはどうすればよいですか? 現在、これはインフラストラクチャの機能に応じて状況に応じて解決されます。 オープンレジスターから何かが取得されます (たとえば、証明書を要求する法人に関する情報)。申請者が個人の場合は、銀行局または郵便局が使用され、パスポートなどの身分証明書を使用して身元が確認されます。

なりすましを目的とした資格情報の偽造の問題は根本的なものです。 情報理論上の理由により、この問題に対する完全な解決策はないことに注意してください。アプリオリに信頼できる情報がなければ、特定の主題の信頼性を確認または否定することは不可能です。 原則として、申請者の本人確認を行うためには、本人確認書類の提示が必要となります。 さまざまな検証方法がありますが、どれも文書の信頼性を完全に保証するものではありません。 したがって、申請者の身元の信頼性も保証できません。

どうすればこれらの欠点を解消できるのでしょうか？現状の PKI の問題が集中化によって説明できるのであれば、分散化が特定された欠点を部分的に解消するのに役立つと想定するのは論理的です。

分散化は、信頼できるエンティティの存在を意味しません。 分散型公開鍵インフラストラクチャ (分散型公開鍵インフラストラクチャ、 DPKI) の場合、CA も CR も必要ありません。 デジタル証明書の概念を放棄し、分散レジストリを使用して公開キーに関する情報を保存してみましょう。 私たちの場合、ブロックチェーン技術を使用してリンクされた個々のレコード (ブロック) で構成される線形データベースをレジスターと呼びます。 電子証明書の代わりに「通知」という概念を導入します。

提案された DPKI では、通知の受信、検証、キャンセルのプロセスはどのようになりますか:

1. 各申請者は、登録時にフォームに記入して通知の申請を個別に送信し、その後、専用のプールに保存されるトランザクションを作成します。

2. 公開キーに関する情報は、所有者の詳細やその他のメタデータとともに、デジタル証明書ではなく分散レジストリに保存されます。集中型 PKI での発行は CA が担当します。

3. 申請者の身元の信頼性の検証は、CR ではなく、DPKI ユーザー コミュニティの共同作業によって事後に実行されます。

4. このような通知の所有者のみが公開鍵のステータスを変更できます。

5. 誰でも分散台帳にアクセスし、公開鍵の現在の状態を確認できます。

注: コミュニティによる申請者の身元確認は、一見すると信頼性が低いように思えるかもしれません。 しかし、今日ではデジタル サービスのすべてのユーザーが必然的にデジタル フットプリントを残し、このプロセスは今後も勢いを増す一方であることを忘れてはなりません。 法人のオープン電子登録簿、地図、地形画像のデジタル化、ソーシャル ネットワーク - これらはすべて公的に利用可能なツールです。 これらは、ジャーナリストと法執行機関の両方による捜査中にすでに成功裏に使用されています。 たとえば、ベリングキャットの調査や、マレーシアのボーイング社墜落事故の状況を調査している共同調査チームJITの調査を思い出すだけで十分です。

それでは、分散型公開鍵インフラストラクチャは実際にはどのように機能するのでしょうか? テクノロジー自体の説明を見てみましょう。 2018年に特許を取得 そして私たちはそれが私たちのノウハウであると正当に考えています。

多くの公開キーを所有する所有者がいて、各キーがレジストリに保存されている特定のトランザクションであると想像してください。 CA が存在しない場合、すべてのキーがこの特定の所有者に属していることをどうやって理解できるでしょうか? この問題を解決するために、所有者とそのウォレットに関する情報を含むゼロ トランザクションが作成されます (トランザクションをレジストリに登録するための手数料はそこから引き落とされます)。 null トランザクションは、公開鍵に関するデータを含む後続のトランザクションが接続される一種の「アンカー」です。 このような各トランザクションには、特殊なデータ構造、つまり通知が含まれています。

通知は、機能フィールドで構成され、所有者の公開鍵に関する情報を含む構造化されたデータのセットであり、その永続性は、分散レジストリの関連レコードの XNUMX つに配置することによって保証されます。

次の当然の疑問は、ゼロトランザクションはどのように形成されるのかということです。 null トランザクションは、後続のトランザクションと同様に、XNUMX つのデータ フィールドの集合体です。 ゼロトランザクションの形成中に、ウォレットのキーペア（公開キーとペアの秘密キー）が関係します。 このキーのペアは、ユーザーがウォレットを登録した瞬間に表示され、レジストリにゼロトランザクションを配置する手数料と、その後の通知を伴う操作の手数料がそこから引き落とされます。

図に示すように、SHA256 ハッシュ関数と RIPEMD160 ハッシュ関数を順に適用することにより、ウォレット公開キー ダイジェストが生成されます。 ここで、RIPEMD160 は、幅が 160 ビットを超えないデータのコンパクトな表現を担当します。 レジストリは安価なデータベースではないため、これは重要です。 公開キー自体は XNUMX 番目のフィールドに入力されます。 最初のフィールドには、前のトランザクションへの接続を確立するデータが含まれます。 ゼロトランザクションの場合、このフィールドには何も含まれないため、後続のトランザクションと区別されます。 XNUMX 番目のフィールドは、トランザクションの接続性を確認するためのデータです。 簡潔にするために、最初と XNUMX 番目のフィールドのデータをそれぞれ「リンク」と「チェック」と呼びます。 以下の図の XNUMX 番目と XNUMX 番目のトランザクションをリンクすることで示されているように、これらのフィールドの内容は反復ハッシュによって生成されます。

最初の XNUMX つのフィールドのデータは、ウォレットの秘密キーを使用して生成される電子署名によって証明されます。

これで、null トランザクションがプールに送信され、検証が成功した後にレジストリに入力されます。 これで、次のトランザクションをそれに「リンク」できるようになります。 ゼロ以外のトランザクションがどのように形成されるかを考えてみましょう。

おそらく最初に目を引くのは、豊富なキーペアでしょう。 すでにおなじみのウォレット キー ペアに加えて、通常のキー ペアとサービス キー ペアが使用されます。

通常の公開鍵がすべての始まりです。 このキーは、外部の世界で展開されるさまざまな手順やプロセス (銀行取引やその他の取引、文書の流れなど) に関与します。 たとえば、通常のペアの秘密鍵を使用して、支払い命令などのさまざまな文書のデジタル署名を生成できます。また、公開鍵は、その後のこれらの命令の実行でこのデジタル署名を検証するために使用できます。有効です。

サービス ペアは、登録された DPKI サブジェクトに対して発行されます。 このペアの名前はその目的に対応しています。 ゼロトランザクションを形成/チェックする場合、サービスキーは使用されないことに注意してください。

キーの目的をもう一度明確にしましょう。

1. ウォレット キーは、null トランザクションとその他の非 null トランザクションの両方を生成/検証するために使用されます。 ウォレットの秘密鍵は、ウォレットの所有者のみが知っており、ウォレットの所有者は多くの通常の公開鍵の所有者でもあります。
2. 通常の公開キーは、集中型 PKI で証明書が発行される公開キーと目的が似ています。
3. サービス キー ペアは DPKI に属します。 秘密キーは登録されたエンティティに発行され、トランザクション (ゼロ トランザクションを除く) のデジタル署名を生成するときに使用されます。 Public は、トランザクションがレジストリに登録される前に、トランザクションの電子デジタル署名を検証するために使用されます。

したがって、キーには XNUMX つのグループがあります。 XNUMX つ目にはサービス キーとウォレット キーが含まれます。これらは DPKI のコンテキストでのみ意味を持ちます。 XNUMX 番目のグループには通常のキーが含まれます。その範囲は異なる場合があり、キーが使用されるアプリケーション タスクによって決定されます。 同時に、DPKI は通常の公開キーの整合性と信頼性を保証します。

注: サービス キー ペアは、さまざまな DPKI エンティティに知られている可能性があります。 たとえば、それは誰にとっても同じかもしれません。 このため、ゼロ以外の各トランザクションの署名を生成する際には XNUMX つの秘密鍵が使用され、そのうちの XNUMX つはウォレットの鍵です。この鍵はウォレットの所有者のみが知っており、ウォレットの所有者は多くの通常のトランザクションの所有者でもあります。公開鍵。 すべてのキーには独自の意味があります。 たとえば、署名もシークレット サービス キーで生成されるため、トランザクションが登録された DPKI サブジェクトによってレジストリに入力されたことを常に証明できます。 また、所有者がトランザクションごとに料金を支払うため、DOS 攻撃などの悪用はあり得ません。

ゼロ 256 に続くすべてのトランザクションは同様の方法で形成されます。公開キー (ゼロ トランザクションの場合のようにウォレットではなく、通常のキー ペアから) は 160 つのハッシュ関数 SHAXNUMX と RIPEMDXNUMX を通じて実行されます。 このようにして、第３フィールドのデータが形成される。 XNUMX 番目のフィールドには、付随情報 (たとえば、現在のステータス、有効期限、タイムスタンプ、使用される暗号アルゴリズムの識別子などに関する情報) が含まれます。 XNUMX 番目のフィールドには、サービス キー ペアの公開キーが含まれます。 その助けを借りて、デジタル署名がチェックされ、複製されます。 このようなアプローチの必要性を正当化しましょう。

トランザクションはプールに入力され、処理されるまでそこに保管されることを思い出してください。 プールへの保存には、トランザクション データが改ざんされる可能性があるという特定のリスクが伴います。 所有者は取引データを電子デジタル署名で証明します。 このデジタル署名を検証するための公開キーは、トランザクション フィールドの XNUMX つに明示的に指定され、その後レジストリに入力されます。 トランザクション処理の特徴は、攻撃者が独自の裁量でデータを変更し、秘密鍵を使用してそれを検証し、トランザクション内のデジタル署名を検証するためのペアの公開鍵を示すことができることです。 デジタル署名のみによって真正性と完全性が保証される場合、そのような偽造は気づかれないでしょう。 ただし、デジタル署名に加えて、保存された情報のアーカイブと永続性の両方を保証する追加のメカニズムがあれば、偽造を検出できます。 これを行うには、所有者の本物の公開キーをレジストリに入力するだけで十分です。 これがどのように機能するかを説明しましょう。

攻撃者にトランザクション データを偽造させます。 キーとデジタル署名の観点からは、次のオプションが可能です。

1. 攻撃者は、所有者のデジタル署名を変更せずに、トランザクションに自分の公開キーを配置します。
2. 攻撃者は自分の秘密鍵にデジタル署名を作成しますが、所有者の公開鍵は変更しないままにします。
3. 攻撃者は秘密鍵にデジタル署名を作成し、ペアになった公開鍵をトランザクションに配置します。

明らかに、オプション 1 と 2 はデジタル署名の検証中に常に検出されるため、無意味です。 オプション 3 のみが意味を持ち、攻撃者が自分の秘密鍵にデジタル署名を形成した場合、所有者の公開鍵とは異なるペアの公開鍵をトランザクション内に保存する必要があります。 これは、攻撃者が改ざんされたデータを押し込む唯一の方法です。

所有者が固定のキーのペア (秘密鍵と公開鍵) を持っていると仮定します。 このペアの秘密鍵を使用してデータをデジタル署名によって認証すると、公開鍵がトランザクションに示されます。 また、この公開キーが以前にレジストリに入力されており、その信頼性が確実に検証されていると仮定します。 この場合、トランザクションの公開キーがレジストリの公開キーと一致しないという事実によって、偽造が示されます。

合計しましょう。 所有者の最初の取引データを処理するときは、レジストリに入力された公開キーの信頼性を検証する必要があります。 これを行うには、レジストリからキーを読み取り、セキュリティ境界 (相対的に脆弱な領域) 内の所有者の真の公開キーと比較します。 キーの信頼性が確認され、配置時にその永続性が保証されている場合、後続のトランザクションからのキーの信頼性は、レジストリからのキーと比較することで簡単に確認/反駁できます。 つまり、レジストリのキーが参照サンプルとして使用されます。 他のすべての所有者のトランザクションも同様に処理されます。

トランザクションは電子デジタル署名によって証明されます。ここで秘密キーが必要になります。サービス キーとウォレット キーの XNUMX つではなく、一度に XNUMX つ必要です。 XNUMX つの秘密キーの使用により、必要なレベルのセキュリティが確保されます。結局のところ、サービス秘密キーは他のユーザーに知られる可能性がありますが、ウォレットの秘密キーは通常のキー ペアの所有者のみに知られます。 このような XNUMX つのキーの署名を「統合」デジタル署名と呼びました。

非 null トランザクションの検証は、ウォレットとサービス キーという XNUMX つの公開キーを使用して実行されます。 検証プロセスは XNUMX つの主要な段階に分けることができます。XNUMX つ目はウォレットの公開キーのダイジェストをチェックすることで、XNUMX つ目はトランザクションの電子デジタル署名をチェックすることです。トランザクションの電子デジタル署名は、XNUMX つの秘密キーを使用して形成されたものと同じ統合されたものです (ウォレットとサービス）。 デジタル署名の有効性が確認された場合、追加の検証の後、トランザクションが登録されます。

論理的な疑問が生じるかもしれません。トランザクションがゼロ トランザクションの形式で「ルート」を持つ特定のチェーンに属しているかどうかを確認するにはどうすればよいでしょうか。 この目的のために、検証プロセスにもう XNUMX つの段階である接続チェックが追加されます。 ここでは、これまで無視してきた最初の XNUMX つのフィールドのデータが必要になります。

トランザクション No. 3 が実際にトランザクション No. 2 の後に来るかどうかを確認する必要があると想像してみましょう。 これを行うには、結合ハッシュ法を使用して、トランザクション No. 2 の 3 番目、2 番目、および 256 番目のフィールドのデータのハッシュ関数値を計算します。 次に、トランザクション No.160 の最初のフィールドのデータと、以前に取得したトランザクション No.2 の XNUMX、XNUMX、XNUMX フィールドのデータの結合ハッシュ関数値の連結が実行されます。 これらすべては、XNUMX つのハッシュ関数 SHAXNUMX と RIPEMDXNUMX によっても実行されます。 受信した値がトランザクション番号 XNUMX の XNUMX 番目のフィールドのデータと一致する場合、チェックに合格し、接続が確認されます。 これは、以下の図でより明確に示されています。

大まかに言うと、通知を生成してレジスタに入力するテクノロジーは次のようになります。 次の図は、通知チェーンを形成するプロセスを視覚的に示しています。

このテキストでは、間違いなく存在する詳細については触れず、分散型公開鍵インフラストラクチャのアイデアそのものの議論に戻ります。

したがって、申請者自身が通知の登録申請を提出し、通知は CA データベースではなくレジストリに保存されるため、DPKI の主要なアーキテクチャ コンポーネントを考慮する必要があります。

1. 有効な通知（RDN）を登録します。
2. 取り消された通知（RON）の登録。
3. 保留通知（RPN）の登録。

公開鍵に関する情報は、ハッシュ関数値の形式で RDN/RON/RPN に保存されます。 また、通常の公開鍵のステータス (失効、一時停止など) に関する情報がレジストリに入力される場合、これらは異なるレジストリ、異なるチェーン、または単一のレジストリの一部としての XNUMX つのチェーンのいずれかになる可能性があることにも注意してください。対応するコード値の形式のデータ構造の XNUMX 番目のフィールド。 DPKI のアーキテクチャ実装にはさまざまなオプションがあり、どちらを選択するかは、公開鍵を保存するための長期メモリのコストなどの最適化基準など、さまざまな要因によって決まります。

したがって、DPKI は、アーキテクチャの複雑さの点で、単純ではないにしても、少なくとも集中型ソリューションと同等であることが判明する可能性があります。

主な疑問は残っています - このテクノロジーの実装にはどのレジストリが適していますか?

レジストリの主な要件は、あらゆる種類のトランザクションを生成できることです。 台帳の最も有名な例は、ビットコイン ネットワークです。 しかし、上で説明したテクノロジを実装する場合、既存のスクリプト言語の制限、任意のデータ セットを処理するために必要なメカニズムの欠如、任意のタイプのトランザクションを生成する方法など、特定の困難が生じます。

私たち ENCRY は、上で定式化した問題を解決しようと試み、レジストリを開発しました。私たちの意見では、これには次のような多くの利点があります。

• いくつかのタイプのトランザクションをサポートします。資産を交換する (つまり、金融トランザクションを実行する) ことも、任意の構造でトランザクションを作成することもできます。
• 開発者は、さまざまな技術的問題を解決する際に必要な柔軟性を提供する独自のプログラミング言語 PrismLang にアクセスできます。
• 任意のデータセットを処理するメカニズムが提供されます。

単純化されたアプローチを採用すると、次の一連のアクションが実行されます。

1. 申請者は DPKI に登録し、デジタル ウォレットを受け取ります。 ウォレットアドレスはウォレットの公開鍵のハッシュ値です。 ウォレットの秘密鍵は申請者のみが知っています。
2. 登録されたサブジェクトには、サービス秘密キーへのアクセスが与えられます。
3. サブジェクトはゼロトランザクションを生成し、ウォレットの秘密キーを使用したデジタル署名でそれを検証します。
4. ゼロ以外のトランザクションが形成された場合、ウォレットとサービスの XNUMX つの秘密鍵を使用した電子デジタル署名によって証明されます。
5. サブジェクトはトランザクションをプールに送信します。
6. ENCRY ネットワーク ノードは、プールからトランザクションを読み取り、デジタル署名とトランザクションの接続性をチェックします。
7. デジタル署名が有効で接続が確認された場合は、トランザクションをレジスターに登録する準備が整います。

ここで、レジストリは、有効な通知、キャンセルされた通知、および一時停止された通知に関する情報を保存する分散データベースとして機能します。

もちろん、地方分権は万能薬ではありません。 プライマリ ユーザー認証の根本的な問題はどこにも消えません。現在、申請者の検証が CR によって実行されている場合、DPKI では検証をコミュニティ メンバーに委任し、経済的動機を利用して活動を刺激することが提案されています。 オープンソースの検証技術はよく知られています。 このような検証の有効性は実際に確認されています。 オンライン出版物ベリングキャットによる数多くの注目を集めた調査をもう一度思い出してみましょう。

しかし一般に、次のようなイメージが浮かび上がります。DPKI は、すべてではないにせよ、集中型 PKI の欠点の多くを修正する機会です。

Habrablog を購読してください。今後も研究開発を積極的に取り上げていきますので、フォローしてください。 ツイッターENCRY プロジェクトに関する他のニュースを見逃したくない場合は、

出所： habr.com