标签: hyperledger-fabric-ca

我想首先正确解释我的理解,如果我是对的,请告诉我真相,如果我弄错了,请告诉我,我错了.我的解释是关于hyperledger网络和节点sdk如何协同工作以及节点sdk如何连接到超级网络.

开始吧.当我启动hyperledger网络时,它所做的是在端口7054上创建fabric-ca-server docker镜像和容器.在该端口上,它注册了一个用户"admin with the password:"adminpwd".这意味着还有证书制作对于这个用户.现在假设我想从节点sdk创建一个新用户.我想我需要做的是为管理员提供证书,以便我可以签署我的请求,网络知道我是管理员和部分网络.代码的作用是第一次写入getUserContext("admin"),如果找不到,那么它会尝试使用用户名和密码(admin和adminpwd)注册.我的理解是getUserContext转到hfc-key -store文件夹并尝试查找admin的证书.如果找不到它,会发生注册然后发生createUser函数,它将从fabric-ca-server docker映像派生的证书放入hfc-key-store,这样当管理员再次尝试注册时,它不必转到fabric-ca-server docker 图片.我到目前为止对吗？我现在就问我的问题.

问题:

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

2. 我不明白getUserContext()和setUserContext()以及createUser()函数的含义.如果你能做到,只要用一种非常易于理解的语言来描述它们,因为我已经很长一段时间试图绕过这个但没有运气.为什么我们需要这些功能,它们对我们的帮助等等.

3. 为什么cryptogen工具不用于生产,而fabric-ca-server可用于生产？

我阅读了Hyperledger Fabric会员服务提供商(MSP)上的文档,但并非所有内容都非常清楚.

关于MSP文档部分的链接是这样的:https: //hyperledger-fabric.readthedocs.io/en/release-1.2/membership/membership.html

1. 从文档引用:

这是成员服务提供商(MSP)发挥作用的地方 - 它通过列出其成员的身份或通过识别来识别信任哪些根CA和中间CA以定义信任域(例如组织)的成员.哪些CA被授权为其成员发布有效身份,或者 - 通常情况下 - 通过两者的组合.

我对这一段的理解是这样的:OrgX的MSP要么有一个OrgX成员列表(因此可以简单地根据列表检查网络上的参与者),或者MSP定义允许哪个证书颁发机构发布身份OrgX的成员.这种理解是否正确？

2. 如果OrgX的MSP定义了允许向OrgX成员发放身份的证书颁发机构,那么这如何保护网络免受不必要的参与者的侵害？假设OrgX的MSP使用"Symantec"作为其CA. 因此,拥有赛门铁克证书的每个人都被视为OrgX的成员,并且可以参与该网络.但是,如果我(谁不是OrgX的成员)获得"赛门铁克"的证书怎么办？我现在自动被认为是OrgX的余烬,可以加入网络吗？

3. 有渠道MSP和本地MSP.根据文档,通道MSP和本地MSP都定义哪些标识属于某个组织(例如,OrgX).但是,如果信道MSP包含与本地MSP相同的信息(即基本上是身份列表),那么将信道MSP实例化到节点的重点是什么？

在 Hyperledger Fabric CA 中注册和注册证书之间究竟有什么区别。我是密码学的新手，我对 Fabric CA 的工作感到非常困惑。此外，通过 cryptogen 生成的证书与通过 Fabric CA 生成的证书有何不同。

我遵循的步骤:

1)用1-ca(即root ca),1-orderer,1-peer和1-couchdb启动织物

2)我将shell连接到ca,它是root并触发2个命令来注册中间ca.

  fabric-ca-client enroll -u http://admin:adminpw@localhost:7054
  fabric-ca-client register --id.name ica --id.attrs '"hf.Registrar.Roles=user,peer",hf.Revoker=true,hf.IntermediateCA=true' --id.secret icapw

3)我按如下方式启动了ca1容​​器:

services:
  ca1.example.com:
    image: hyperledger/fabric-ca:x86_64-1.1.0
    environment:
      - FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
      - FABRIC_CA_SERVER_PORT=8054
      - FABRIC_CA_SERVER_CA_NAME=ca1.example.com
    ports:
      - "8054:8054"
    command: sh -c 'fabric-ca-server start -b admin:adminpw -u http://ica:icapw@ca.example.com:7054'
    container_name: ca1.example.com
    networks:
      - basic

但它总是创建默认证书,所以我从容器中删除所有,然后再次启动命令,当我尝试使用该中间ca注册管理员时,它会给我以下错误:

signed certificate with serial number 619423114660023963149266564884451731119475746692
ca1.example.com    | 2018/09/20 06:38:53 [INFO] 127.0.0.1:47144 POST /enroll 500 0 "Certificate signing failure: Failed to insert record intodatabase: attempt to write a readonly database"

我不确定我遵循的流程.所以建议我遵循的确切步骤,如果步骤正确,那么这个错误的原因.

我已按照文档:https: …

我是 Hyperledger Fabric 开发的新手，我正在尝试进行用户友好的注册。
例如：
+ 使用来自谷歌帐户的 Oauth。
+ 或使用传统的电子邮件密码注册。

我已经阅读了 hyperledger fabric 文档并尝试了其中的一些示例。我只知道新的身份创建过程是这样的：
1.通过fabric-ca客户端或SDK从fabric-ca服务器获取管理员身份。
2. 使用该管理员身份注册新身份。
3.然后fabric-ca服务器将发回新身份的ID和密码（所谓的密码）。
4. 用户将使用该 ID 和密码来注册新用户，以及创建交易等。

所以，我的问题是：

1. 我应该做哪些额外的工作来使注册/登录过程看起来像传统的 Oauth 或用户/电子邮件注册。
   
2. 我应该在哪里存储用户的附加信息，如电子邮件、密码、生日等
   （我之前读过这个问题：用户注册和登录 Hyperledger fabric，所以我认为有办法做到这一点，但没有弄清楚然而）。

我hyperledger在集群中部署了一个结构网络 v2.2.0，其中有 2 个对等组织和一个排序组织kubernetes。每个组织都有自己的 CA 服务器。CA pod 有时会不断重新启动。为了知道CA服务器的服务是否可达，我尝试使用healthz端口9443上的API。

livenessProbe我在 CA 部署中使用了这样的条件：

    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /healthz
        port: 9443
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1

配置此活性探针后，Pod 会随着事件继续重新启动Liveness probe failed: HTTP probe failed with status code: 400。为什么会发生这种情况？

让我们以 3 个公平组织的场景为例，即每个组织都运行对等体，并且应该平等地参与订购过程。
对我来说，将这 3 个组织配置为每个组织都有一个排序者节点和一些对等点是很自然的。然而，强烈建议不要采用这种设置。引用常见问题解答：

问题：我可以让一个组织同时扮演订购角色和应用角色吗？
回答：虽然这是可能的，但这是一种非常不鼓励的配置。默认情况下，/Channel/Orderer/BlockValidation 策略允许订购组织的任何有效证书对区块进行签名。如果组织同时扮演订购和应用程序角色，则应更新此策略以将块签名者限制为授权订购的证书子集。

在另一个 SO 问题中，一个答案提供了有关此主题的更多详细信息：

首先，很容易错误配置策略并显着降低系统的安全性。订购服务和应用程序根据权力分离的原则运作。重要的是，排序节点不能制造验证交易，同样重要的是应用程序交易者不能制造区块。

并继续：

其次，由于 MSP 定义必须出现在通道配置的两个部分中，因此您最终会得到两个相同的 MSP 定义副本，它们必须保持完全同步。由于两个 MSP 具有相同的 ID，如果内容不完全相同，则会在评估身份时产生歧义。

我整个晚上都在绞尽脑汁地思考，如果此设置配置不正确，哪些攻击媒介和参与者可能会给我的组织或整个网络带来潜在的安全风险。

不幸的是，我只能想到一种情况：如果排序者二进制文件中存在漏洞，则另一个组织的排序者可以利用此漏洞以我组织的身份创建交易。

问题：如果您在单个组织中拥有对等点和订购者并且配置不正确，可能会暴露哪些攻击媒介？演员会是谁？客户、管理员、网络的其他组织、完全的局外人？

额外问题：在给定场景中建议的替代方案是什么？每个参与组织是否应该分成单独的对等组织和订购者组织？喜欢Company1PeerOrg、Company1OrdererOrg、Company2PeerOrg，...？

我有一个带有一个Fabric CA的单组织设置。CA Server与MySQL一起运行。我正在使用NodeSDK来连接事务并将其发布到Chaincode。

我能够为同行和订购者设置国家，州，地区，组织和组织单位属性。但是，当我在Fabric中注册并注册“用户”时，并不是所有属性都已设置。从证书文件中可以看到，仅设置了“公用名”和“组织单位”属性。

以下是我用于注册和注册用户的代码段：

await gateway.connect(connectionProfile, { wallet, identity: 'admin', discovery: { enabled: false } });

ca = await gateway.getClient().getCertificateAuthority();
adminIdentity = gateway.getCurrentIdentity();

const secret = await ca.register({
                affiliation: user.$affiliation,
                enrollmentID: user.$name,
                role: user.$role,
               }, adminIdentity);

const enrollment = await ca.enroll({
                    enrollmentID: user.$name,
                    enrollmentSecret: secret,
                 });
const userIdentity = await X509WalletMixin.createIdentity(process.env.ACTIVE_MSP, enrollment.certificate, enrollment.key.toBytes());

在这里，“用户”是我在应用程序中使用的参与者的模型。公用名（CN）设置为“ enrollmentID”，组织单位设置为“ role” +“ affiliation”，并且为用户生成的证书具有以下信息：

Owner: CN=jondoe, OU=client + OU=admin.forwarder.com
Issuer: CN=ca.allparticipants.logistics.com, 
O=allparticipants.logistics.com, L=Bengaluru, ST=Karnataka, C=IN
Serial number: ea385863390c07c320fd6717de7878fd9f81dc3e
Valid from: Mon Apr 15 14:11:00 IST …

我正在尝试在configtx.yaml文件内的策略定义中添加自定义节点 OU 。策略定义位于 configtx.yaml 文件的应用程序部分，如下所示：

Application: &ApplicationDefaults

# Organizations is the list of orgs which are defined as participants on
# the application side of the network
ACLs: &ACLsDefault
    peer/Propose: /Channel/Application/Checkous

Organizations:

# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
#   /Channel/Application/<PolicyName>
Policies:
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    Checkous:
        Type: Signature
        Rule: …

阅读fabric-ca 文档尚不清楚什么fabric-ca-client register时候fabric-ca-client enroll可以用来完成领域中的所有任务fabric-ca-client register。实际上，仅在fabric-ca-client enroll运行时才颁发证书。此外，对于引导程序标识fabric-ca-client register，文档中没有任何步骤。

有人可以提供出它是什么，一个例子register做哪些enroll不能做？