docker – 如何从hyperledger中的hfc-key-store中的真实fabric-

Fabric被设计为Consortium区块链系统,广泛用于企业业务场景.在Fabric业务网络中,每个组织通常包含至少一个对等体,并且可选择一个对等体.

想想这样的商业场景.有几家公司希望一起做生意.但是,他们不够相互信任.所以他们决定用Fabric来解决他们的痛点.假设该网络包含3个公司(组织),每个公司(组织)有一个同行和一个ca.

现在业务网络已经设置好了.

首先,让我解释一下入学的概念.

>每个组织的ca都有一个bootstrap用户,这来自用户名和密码,通常样本会使用admin / adminpw.在ca服务器设置期间,此引导用户正在写入CA的数据库.设置后,引导用户已注册.但没有注册.
>接下来是注册引导程序用户.在这一步中,fabric-sdk(稍后我将使用sdk)将首先生成私钥/公钥对,然后生成csr(certificate signing request),最后使用私钥签署csr并将签名的csr发送到fabric -ca服务器.
>当fabric-ca服务器收到签名的csr时.它为该用户生成证书.证书包含用户的公钥. Fabric-ca将使用其私钥对此请求进行签名,并在证书上附加其签名.
> sdk从fabric-ca服务器获取响应(来自3的证书). fabric-sdk将证书和用户的私钥放在一起(我们称之为注册)作为方法enroll()的响应.
>现在,引导用户已注册,并可使用此注册访问结构网络.

我们可以使用bootstrap用户在此组织中注册和注册新用户.这就是我们将财团区块链系统称为许可区块链系统的原因.

其次,让我解释一下sdk KVS(键值存储)的概念.

我们已经从上面的步骤获得了用户的privateKey和证书.那么我们如何坚持这些数据呢？有几种选择,将其存储在应用层数据库,一些硬件加密钱包,一些基于云的HSM等.

Fabric-sdk提供了一个KVS来做到这一点.这是一个可选选项,您可以选择是否使用它.坦率地说,我不建议在生产系统中使用它.如果你只想尝试某些东西或测试一些东西,这很好,因为它非常简单.

默认情况下,fabirc-sdk-node将使用文件系统KVS.它将凭据存储在磁盘中,这就是你提到的hfc-key-store文件夹.

那么如果KVS被盗会怎么样？

所有注册都被盗了.所有证书和私人钥匙都被盗了.攻击者可以使用这些证书和privateKeys使用这些证书中的标识访问区块链系统.这是一场灾难.

createUser()用于什么？

而不是将这些注册存储在文件系统中.将其存储在Application层数据库中的更好选择.每次我们想要访问区块链系统时,我们都可以先从db查询并获取证书和privateKey.然后使用createUser()接口创建新的User实例.此用户实例用作访问区块链系统的标识.

最后,让我解释一下Fabric中的事务流程

我们没有有效的用户证书和privateKey.我们如何向Fabric网络发送交易？ fabric-peer如何验证交易并知道我是谁？

>每个事务都包含用户的身份.如果要通过userA提交事务,则应在进一步支持调用之前调用setUserContext(userA).
>事务提议在邮件头中包含用户的证书.在将事务发送到fabric-peer之前,sdk将使用当前用户的私钥来签署此事务提议.
>在同行方面.当对等体收到endorse请求时,对等体将使用fabric-ca的根证书来验证该请求中的证书,以便对等体知道该请求来自已知CA发出的身份,现在证书是可信的.然后对等体将解析证书并获取身份的公钥,然后使用此公钥验证事务的签名(我在上面描述了tx由私钥签名,现在由公钥验证),现在交易是可信的.

从事务流程中,我们了解到必须使用用户的证书发送事务并使用用户的私钥进行签名.这就是我们在fabirc-sdk设计setUserContext()接口的原因.

加密工具

此工具用于在系统设置时生成私钥/公钥对以及相应的证书.之后,我们需要一个动态的添加/删除身份机制.而解决方案是Fabric-ca.

Note,fabric-ca is optional,you may use any other CA.