docker - 证书是如何从 super 账本中 hfc-key-store 中真实的 fabric-ca-server 证书派生出来的？

Question

我想先解释一下我理解的正确，如果我是对的，请告诉我真相，如果我错了，请告诉我我错了。我的解释是关于 super 账本网络和节点 sdk 如何协同工作以及节点 sdk 如何连接到 super 账本网络。

开始吧。当我启动 super 账本网络时，它所做的是在端口 7054 上创建fabric-ca-server docker 镜像和容器。在该端口上，它注册了一个用户“admin，密码为:”adminpwd。这意味着也已经制作了证书对于这个用户。现在假设我想从节点 sdk 创建一个新用户。我想我需要做的是拥有 Admin 的证书，以便我可以签署我的请求，并且网络知道我是管理员并且是网络。代码的作用是首先写入 getUserContext("admin")，如果找不到，则尝试使用用户名和密码(admin 和 adminpwd)进行注册。我的理解是 getUserContext 转到 hfc-key -store 文件夹并尝试为 admin 查找证书。如果没有找到，则会发生注册，然后发生 createUser 函数，它将从fabric-ca-server docker 镜像派生的证书放入 hfc-key-store，以便当管理员再次尝试注册时，它不必转到fabric-ca-server docker 图片。到目前为止我是对的吗？我现在问我的问题。

问题:

我知道在尝试注册时，它不会从 fabric-ca-server docker 镜像中获取管理员的原始证书，因为如果它被盗，整个网络就会被搞砸。所以它所做的是从原始证书中获得某种公共(public)/私有(private)和证书，我可以进行其他操作。问题是:如果有人偷了我的 hfc-key-store 文件夹，里面有管理员证书怎么办。他可以在不注册的情况下进行操作，因为 getUserContext("admin") 将返回 true 并让它做任何事情。如果有人偷了那个文件夹怎么办？不是很危险吗？

我根本不明白 getUserContext() 和 setUserContext() 以及 createUser() 函数是什么意思。如果你能做到，请用一种非常容易理解的语言来描述它们，因为我已经很长时间没有试图解决这个问题了，但没有运气。为什么我们需要这些功能，它们对我们有什么帮助等等。

为什么cryptogen 工具不在生产中使用，而fabric-ca-server 可以在生产中使用？

Answer 1

那里似乎有很多问题。让我一步一步地解释它。如果有什么不妥或不清楚的地方，请发表您的意见。

Fabric 设计为 Consortium Blockchain System广泛应用于企业业务场景。在 Fabric 业务网络中，每个组织通常至少包含一个对等方，以及可选的一个 ca。

想想这样的业务场景。几家公司想一起做生意。然而，他们还不够信任对方。所以他们决定使用 Fabric 来解决他们的痛点。假设这个网络包含 3 个公司(orgs)，每个公司(org)有一个 peer 和一个 ca。

现在业务网络已经建立。

首先，让我解释一下注册的概念。

每个组织的 ca 都有一个引导用户，这来自用户名和密码，通常示例将使用 admin/adminpw。在 ca 服务器设置期间，此引导用户已写入 CA 的数据库。设置完成后，引导用户被注册。但没有被录取。

接下来是enroll the bootstrap user .在这一步中，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(key-value-store)的概念。

我们已经通过上面的步骤获得了用户的私钥和证书。那么我们如何持久化这些数据呢？有几种选择，将其存储在应用层数据库、一些硬件加密钱包、一些基于云的 HSM 等中。

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

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

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

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

createUser() 有什么用？

而不是将这些注册存储在文件系统中。将其存储在应用程序层数据库中的更好选择。每次我们要访问区块链系统时，我们可以先从db中查询并获取证书和privateKey。然后使用 createUser()接口(interface)来创建一个新的 User 实例。此 User 实例用作访问区块链系统的身份。

最后解释一下fabric中的交易流程

我们没有有效的用户证书和私钥。我们如何将交易发送到结构网络？ fabric-peer 如何验证交易并知道我是谁？

每笔交易都包含用户的身份。如果您想通过userA提交交易，那么你应该拨打 setUserContext(userA)在进一步背书调用之前。

交易提议在消息头包含用户的证书。并且在交易发送到fabric-peer之前，sdk会使用当前用户的私钥来签署这个交易提案。

在对等端。当peer收到背书请求时，peer会使用fabric-ca的根证书来验证这个请求中的证书，这样peer就知道这个请求是来自一个已知CA颁发的身份，现在这个证书是可信的。然后peer会解析证书并得到身份的公钥，然后用这个公钥验证交易的签名(我上面描述的tx是用私钥签名的，现在用公钥验证)，现在交易是可信的。

从交易流程中我们了解到，一笔交易必须带有用户的证书并由用户的私钥签名。这就是我们设计 setUserContext() 的原因fabirc-sdk 的接口(interface)。

加密工具

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

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