最初に私が正しく理解していることを説明したいと思います。私が正しい場合は、真実を教えてください。間違っている場合は、間違っていることも教えてください。私の説明は、ハイパーレジャーネットワークとノードSDKがどのように連携するか、およびノードSDKがハイパーレジャーネットワークに接続する方法についてです。
はじめましょう。ハイパーレジャーネットワークを起動すると、ポート7054でファブリックCAサーバーのDockerイメージとコンテナーが作成されます。そのポートで、ユーザー「admin」とパスワード「adminpwd」を登録しました。つまり、証明書も作成されていますこのユーザーの場合です。ここで、ノードSDKから新しいユーザーを作成したいとします。管理者の証明書を取得して、要求に署名し、ネットワークが管理者であり、ネットワークのコードは、最初にgetUserContext( "admin")を書き込み、見つからない場合は、ユーザー名とパスワード(adminおよびadminpwd)で登録を試みます。私の理解では、getUserContextはhfc-keyに移動します。 -storeフォルダーを使用して、adminの証明書を見つけようとします。見つからない場合は、登録が行われ、createUser関数が実行されます。これにより、fabric-ca-server Dockerイメージから派生した証明書がhfc-key-storeに配置され、管理者が再度登録しようとしたときに、fabric-ca-server Dockerに移動する必要はありません画像。私は今のところ正しいですか?今から質問します。
質問:
登録しようとしたときに、ファブリックCAサーバーのDockerイメージから管理者の元の証明書が取得されないことを理解しています。盗まれた場合、ネットワーク全体が台無しになるためです。それでそれがすることは、私が他の操作を行うことができるもので、元のものからある種のパブリック/プライベートと証明書を導き出すことです。質問:管理者の証明書があるhfc-key-storeフォルダーを誰かが盗んだ場合getUserContext( "admin")はtrueを返し、何でもできるため、登録せずに操作を実行できます。誰かがそのフォルダを盗んだ場合はどうなりますか?危ないですか?
GetUserContext()とsetUserContext()の意味、およびcreateUser()関数の意味がまったくわかりません。できれば喜んでください。非常に理解しやすい言語で説明してください。私がこれに頭を回そうとしていましたが、運が悪かったので久しぶりです。なぜこれらの関数が必要なのか、それらが私たちに役立つものなどです。
Cryptogenツールが本番環境では使用されないが、ファブリックcaサーバーが本番環境で使用できるのはなぜですか?
そこには多くの質問があるようです。ステップごとに説明しましょう。何かがおかしい、またははっきりしない場合は、コメントをお寄せください。
ファブリックは_Consortium Blockchain System
_として設計されており、企業のビジネスシナリオで広く使用されています。ファブリックビジネスネットワークでは、通常、各組織には少なくとも1つのピアと、オプションで1つのCAが含まれます。
このようなビジネスシナリオを考えてみてください。複数の企業が一緒にビジネスをしたいと考えています。しかし、彼らはお互いを十分に信頼していません。そこで、彼らはファブリックを使用して問題点を解決することにしました。このネットワークに3つの企業(組織)が含まれ、各企業(組織)に1つのピアと1つのCAがあるとします。
これで、ビジネスネットワークは既にセットアップされています。
enroll the bootstrap user
_です。このステップでは、fabric-sdk(後でsdkを使用します)が最初に秘密鍵と公開鍵のペアを生成し、次にcsr( 証明書署名要求 )を生成し、最後に秘密鍵を使用して署名しますcsrを使用して、署名されたcsrをfabric-caサーバーに送信します。enroll()
の応答として、証明書とユーザーの秘密鍵を一緒に(登録と呼びます)まとめます。bootstrapユーザーを使用して、この組織に新しいユーザーを登録および登録できます。これが、コンソーシアムのブロックチェーンシステムを許可されたブロックチェーンシステムと呼ぶ理由です。
上記の手順でユーザーのプライベートキーと証明書を取得しています。では、これらのデータをどのように永続化するのでしょうか。いくつかの選択肢があり、それをアプリケーションレイヤーデータベース、ハードウェアで暗号化されたウォレット、クラウドベースのHSMなどに保存します。
Fabric-sdkはこれを行うためのKVSを提供します。これはオプションの選択であり、使用するかどうかを選択できます。率直に言って、これを運用システムで使用することはお勧めしません。何かを試してみたい、または何かをテストしたいだけの場合は、非常に簡単なので、これは良いことです。
デフォルトでは、fabirc-sdk-nodeはファイルシステムKVSを使用します。資格情報をディスクに保存します。これは、hfc-key-storeフォルダーについて述べたものです。
登録はすべて盗まれます。すべての証明書とprivateKeysが盗まれます。攻撃者はこれらの証明書とprivateKeysを使用して、これらの証明書のIDを持つブロックチェーンシステムにアクセスできます。これは災害だ。
これらの登録をファイルシステムに保存する代わりに。アプリケーションレイヤーデータベースに保存することをお勧めします。ブロックチェーンシステムにアクセスするたびに、まずデータベースからクエリを実行し、証明書とprivateKeyを取得できます。次に、createUser()
インターフェイスを使用して、新しいUserインスタンスを作成します。このユーザーインスタンスは、ブロックチェーンシステムにアクセスするためのIDとして使用されます。
有効なユーザー証明書とprivateKeyがありません。トランザクションをファブリックネットワークに送信するにはどうすればよいですか?ファブリックピアはどのようにトランザクションを確認し、私が誰であるかを知るのですか?
userA
でトランザクションを送信する場合は、setUserContext(userA)
を呼び出してから、さらに推奨呼び出しを行う必要があります。トランザクションフローから、トランザクションはユーザーの証明書で送信され、ユーザーの秘密キーで署名される必要があることがわかりました。これがsetUserContext()
インターフェイスをfabirc-sdkで設計した理由です。
このツールは、システムのセットアップ時に秘密鍵と公開鍵のペアと対応する証明書を生成するために使用されます。その後、動的なIDの追加/削除メカニズムが必要です。そして、解決策はFabric-caです。
なお、fabric-caはオプションであり、他のCAを使用することもできます。
あなたの質問にはいくつかの部分があります。上から始めてみます。
ファブリックCAは、ファブリックピアまたはオーダーノードを実行/操作するために必要ではありません。デフォルトのセキュリティメカニズムは、楕円曲線を使用する標準のX509 PKIに基づいています(p256がデフォルトです)。必要な方法で発行されたX509証明書を使用できます。ファブリックCAは、そのような実装の1つとして提供されています。
ファブリックCAには複数のAPIがありますが、主な2つのAPIは登録と登録です。登録は、X509証明書を発行するプロセスです。ユーザー/ノードを登録する前に、まずユーザー/ノードを登録する必要があります。ファブリックCAを初めて起動するときは、「ブートストラップ」管理ユーザーを作成する必要があります。このユーザーは起動時に自動的に登録されますが、まだ登録されていません。秘密キーと証明書署名リクエストを生成してファブリックCAに登録し、登録IDとシークレットを使用してこれを送信します。これが成功すると、Fabric CAによって署名されたX509証明書を受け取ります。
便宜上、Fabric Node SDKは、Fabric CAにユーザーを登録および登録するためのラッパーAPIを提供するfabric-ca-clientパッケージを提供します。これにより、Fabric CAから資格情報を取得して使用できます
ただし、ファブリッククライアントパッケージでは、ファブリックCAから資格情報を取得する必要はありません。独自の秘密鍵と、他の機関によって発行された(または、cryptogenによって生成された)X509証明書がある場合があります。
ファブリッククライアントは、資格情報を格納するための「プラグ可能な」キーストアを提供します。デフォルトはファイルベースのキーストアです。
内部的に、ファブリッククライアントは実際に User クラスを使用して現在のユーザーを表します。この構造を設定するにはいくつかの方法があるため、これは重要です。
createUser()
-この関数を使用すると、既存の秘密/公開(X509)鍵ペアからユーザーを作成できますUser.setEnrollment()
-これにより、必要な情報を構造に直接追加できます...これは一般的に からの応答で使用されますCertificateAuthority.enroll()
User
オブジェクトを取得したら、それを使用するようにファブリッククライアントに指示する必要があります。これは、 Client.setUserContext()
を使用する場所です。 User
オブジェクトを渡すと、デフォルトでこれが永続化されます。Client.getUserContext()
を使用できます。これにより、構成済みのキーストアからユーザー情報が読み込まれます-クライアントアプリケーションを起動するときの将来のリクエストに使用できます。cryptogen
に関する質問については、生成された暗号化マテリアルを本番環境で使用できない理由はありません。単に、開発とテストを支援するように設計されたツールであることだけですbootstrapネットワーク。これはPKIインフラストラクチャではなく、証明書の失効などは含まれていません。
お役に立てれば。
私はあなたのすべての質問が大好きで、最近Node SDK for HLFに取り組んだときに同じ質問に出くわしました。
私の知る限り最善を尽くしてお答えします。
APIドキュメントでは、ここですべての技術を説明しています: getUserContextsetUserContextcreateUser
これらすべてのメソッドは、NodeSDKの「クライアント」クラスで使用できます。これらの方法により、「ユーザー」管理が可能になります。 Hyperledger Fabricの世界のユーザーと言うと、デフォルトで公開鍵と秘密鍵の参照が付属しています。所属、アイデンティティ、役割など、他のすべてのフィールドもあります。続きを読む: ユーザー
createUser上記のプロパティのすべてまたはいずれかが指定されたserクラスのインスタンスを作成します。このインスタンスは、関連するすべての操作を実行するために使用されます。ユーザーが「admin」アクセス権を持っている場合、他のロールに対して、Hyperledger Fabricワールドなどで「admin」レベルの機能を実行できます。
getUserContextおよびsetUserContextclientインスタンスのコンテキストを取得/設定します。適切なユーザーコンテキストを設定することで、クライアントを認証し、クライアントインスタンスはこのコンテキストを使用してリクエストに署名できます。
これに加えて、これらのメソッドは両方とも、構成されている場合、いくつかの永続ストアに対して読み取り/書き込みを行います。 Node SDKの場合、それはhfc-key-storeです。このフォルダーの内容を調べると、ここに保存されているすべてのユーザーIDが見つかります。必要なファイルがこのフォルダー(または暗号スイート用に構成されているフォルダー)の下に見つからない場合、getUserContextは失敗し、ファイルシステムから証明書を手動で読み取り、これらの証明書からユーザーを作成する必要がありますsetUserContextに使用します。
cryptogenツールは本質的に静的です。ファブリックCAサーバーはREST APIを介した通信をサポートしますが、Fabric CAクライアントまたはファブリックSDKを使用します。これは、外出先で新しいID(読み取り証明書)を生成する必要がある実稼働環境で非常に役立ちます。 cryptogenツールはここでは扱いにくくなる可能性があります。