From 0b8120b10bd59bde68fd0934c82c7c396024e412 Mon Sep 17 00:00:00 2001 From: Gymgle Date: Fri, 11 Nov 2016 14:34:39 +0800 Subject: [PATCH] Fix translation and spelling errors Change-Id: Ic974bd2f2122813605bd9887a18f7eb9f5c692b7 Signed-off-by: Gymgle --- docs/protocol-spec_zh.md | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/docs/protocol-spec_zh.md b/docs/protocol-spec_zh.md index c8be3d94c57..58b61a76617 100755 --- a/docs/protocol-spec_zh.md +++ b/docs/protocol-spec_zh.md @@ -1337,9 +1337,9 @@ consumerClient.Stop() ![figure-architecture](./images/sec-sec-arch.png) - * Peers, 它们被分为验证 peer 和非验证 peer。验证 peer（也被称为验证器）是为了规范并处理（有效性检查，执行并添加到区块链中）用户消息（交易）提交到网络上。非验证 peer（也被称为 peer）代表用户接受用户交易，并通过一些基本的有效性检查，然后把交易发送到它们附近的验证 peer。peer 维护一个最新的区块链副本，只是为了做验证，而不会执行交易(处理过程也被称为*交易验证*)。 + * Peers，它们被分为验证 peer 和非验证 peer。验证 peer（也被称为验证器）是为了规范并处理（有效性检查，执行并添加到区块链中）用户消息（交易）提交到网络上。非验证 peer（也被称为 peer）代表用户接受用户交易，并通过一些基本的有效性检查，然后把交易发送到它们附近的验证 peer。peer 维护一个最新的区块链副本，只是为了做验证，而不会执行交易(处理过程也被称为*交易验证*)。 * 注册到我们的成员服务管理系统的终端用户是在获取被系统认定的*身份*的所有权之后，并将获取到的证书安装到客户端软件后，提交交易到系统。 - * 客户端软件，为了之后能完成注册到我们成员服务和提交交易到系统所需要安装在客户端的软件 + * 客户端软件，为了之后能完成注册到我们成员服务和提交交易到系统所需要安装在客户端的软件。 * 在线钱包，用户信任的用来维护他们证书的实体，并独自根据用户的请求向网络提交交易。在线钱包配置在他们自己的客户端软件中。这个软件通常是轻量级的，它只需有对自己和自己的钱包的请求做授权。也有 peer 为一些用户扮演*在线钱包*的角色，在接下来的会话中，对在线钱包做了详细区分。 希望使用fabric的用户，通过提供之前所讨论的身份所有权，在成员管理系统中开立一个账户，新的链码被链码创建者（开发）以开发者的形式通过客户端软件部署交易的手段，公布到区块链网络中。这样的交易是第一次被 peer 或验证器接收到，并流传到整个验证器网络中，这个交易被区块链网络执行并找到自己的位置。用户同样可以通过调用交易调用一个已经部署了的链码 @@ -1347,13 +1347,14 @@ consumerClient.Stop() 下一节提供了由商业目标所驱动的安全性需求的摘要。然后我们游览一下安全组件和它们的操作，以及如何设计来满足安全需求。 ### 4.1 商业安全需求 -这一节表述的与fabric相关的商业安全需求。 +这一节表述与fabric相关的商业安全需求。 + **身份和角色管理相结合** -为了充分的支持实际业务的需求，有必要超越确保加密连续性来进行演进。一个可工作的B2B系统必须致力于证明/展示身份或其他属性来开展业务。商业交易和金融机构的消费交互需要明确的映射到账户的所有者。商务合同通常需要与特定的机构和/或拥有交易的其他特定性质的各方保证有从属关系。身份管理是此类系统的关键组成部分的两个原因是问责制和不可陷害的。 +为了充分的支持实际业务的需求，有必要超越确保加密连续性来进行演进。一个可工作的B2B系统必须致力于证明/展示身份或其他属性来开展业务。商业交易和金融机构的消费交互需要明确的映射到账户的所有者。商务合同通常需要与特定的机构和/或拥有交易的其他特定性质的各方保证有从属关系。问责制和不可陷害性是身份管理作为此类系统关键组成部分的两个原因。 -问责制意味着系统的用户，个人或公司，谁的胡作非为都可以追溯到并为自己的行为负责。在很多情况下，B2B系统需要它们的会员使用他们的身份（在某些形式）加入到系统中，以确保问责制的实行。问责制和不可陷害的。都是B2B系统的核心安全需求，并且他们非常相关。B2B系统需要保证系统的诚实用户不会因为其他用户的交易而被指控。 +问责制意味着系统的用户，个人或公司，谁的胡作非为都可以追溯到并为自己的行为负责。在很多情况下，B2B系统需要它们的会员使用他们的身份（在某些形式）加入到系统中，以确保问责制的实行。问责制和不可陷害性都是B2B系统的核心安全需求，并且他们非常相关。B2B系统需要保证系统的诚实用户不会因为其他用户的交易而被指控。 此外，一个B2B系统需要具有可再生性和灵活性，以满足参与者角色和/或从属关系的改变。 @@ -1374,7 +1375,7 @@ B2B系统对交易的隐私有着强烈的需求，如：允许系统的终端 **通过身份管理协调交易隐私.** -就像文档之后描述的那样，这里所采用的方法是使户隐私来协调身份管理，并使有竞争力的机构可以像下面一样在公共的区块链（用于内部和机构间交易）上快速的交易： +就像文档之后描述的那样，这里所采用的方法用来协调身份管理与用户隐私，并使有竞争力的机构可以像下面一样在公共的区块链（用于内部和机构间交易）上快速的交易： 1. 为交易添加证书来实现“有权限的”区块链 @@ -1386,11 +1387,13 @@ B2B系统对交易的隐私有着强烈的需求，如：允许系统的终端 3. 提供对系统中未授权会员隐藏交易内用的机制 -**审计支持.** 商业系统偶尔会受到审核。在这种情况下，将给予审计员检查某些交易，某组交易，系统中某些特定用户或系统自己的一些操作的手段。因此，任意与商业伙伴通过合同协议进行交易的系统都应该提供这样的能力。 +**审计支持.** + +商业系统偶尔会受到审核。在这种情况下，将给予审计员检查某些交易，某组交易，系统中某些特定用户或系统自己的一些操作的手段。因此，任意与商业伙伴通过合同协议进行交易的系统都应该提供这样的能力。 ### 4.2 使用成员管理的用户隐私 -成员管理服务是由网络上管理用户身份和隐私的几个基础架构来组成的。这些服务验证用户的身份，在系统中注册用户，并为他/她提供所有作为可用、兼容的参数者来创建和/或调用交易所需要的证书。公告密钥体系（Public Key Infrastructure -，PKI）是一个基于不仅对公共网络上交换的数据的加密而且能确认对方身份的公共密钥加密的。PKI管理密钥和数字证书的生成，发布和废止。数字证书是用来建立用户证书，并对消息签名的。使用证书签名的消息保证信息不被篡改。典型的PKI有一个证书颁发机构（CA），一个登记机构（RA），一个证书数据库，一个证书的存储。RA是对用户进行身份验证，校验数据的合法性，提交凭据或其他证据来支持用户请求一个或多个人反映用户身份或其他属性的可信任机构。CA根据RA的建议为特定的用户发放根CA能直接或分级的认证的数字证书。另外，RA的面向用户的通信和尽职调查的责任可以看作CA的一部分。成员服务由下图展示的实体组成。整套PKI体系的引入加强了B2B系统的强度（超过，如：比特币） +成员管理服务是由网络上管理用户身份和隐私的几个基础架构来组成的。这些服务验证用户的身份，在系统中注册用户，并为他/她提供所有作为可用、兼容的参数者来创建和/或调用交易所需要的证书。公开密钥体系（Public Key Infrastructure +，PKI）是一个基于不仅对公共网络上交换的数据的加密而且能确认对方身份的公共密钥加密的。PKI管理密钥和数字证书的生成，发布和废止。数字证书是用来建立用户证书，并对消息签名的。使用证书签名的消息保证信息不被篡改。典型的PKI有一个证书颁发机构（CA），一个登记机构（RA），一个证书数据库，一个证书的存储。RA是对用户进行身份验证，校验数据的合法性，提交凭据或其他证据来支持用户请求一个或多个人反映用户身份或其他属性的可信任机构。CA根据RA的建议为特定的用户发放根CA能直接或分级的认证的数字证书。另外，RA的面向用户的通信和尽职调查的责任可以看作CA的一部分。成员服务由下图展示的实体组成。整套PKI体系的引入加强了B2B系统的强度（如：超过比特币）。 ![Figure 1](./images/sec-memserv-components.png) @@ -1426,10 +1429,11 @@ TCerts可容纳的加密或密钥协议的公共密钥（以及数字签名的 * Hidden Enrollment ID: AES_EncryptK(enrollmentID), 其中密钥K = [HMAC(Pre-K, TCertID)]256位截断其中为每个K定义三个不同的密钥分配方案：(a)， (b) and (c)。 * Hidden Private Keys Extraction: AES_EncryptTCertOwner_EncryptKey(TCertIndex || 已知的填充/校验检查向量) 其中||表示连接，其中各个批次具有被加到计数器的唯一（每个批次）的时间戳/随机偏移量（这个实现中初始化为1）来生成TCertIndex。该计数器可以通过每次增加2来适应TCA生成公钥，并由这两种类型的私钥的TCert所有者来恢复，如签名密钥对和密钥协商密钥对。 * Sign Verification Public Key – TCert签名验证的公共密钥。 -* Key Agreement Public Key – TCert密钥协商的公钥. +* Key Agreement Public Key – TCert密钥协商的公钥。 * Validity period – 该交易证书可用于交易的外/外部签名的时间窗口。 这里至少有三种方式来配置考虑了隐藏注册ID域密钥的分配方案： + *(a)* Pre-K在注册期间发给用户，peer 和审计员，并对TCA和授权的审计员可用。它可能，例如由Kchain派生（会在这个规范的后面描述）或为了链码的保密性使用独立的key(s)。 *(b)* Pre-K对验证器，TCA和授权的审计员可用。K是在验证器成功响应用户的查询交易（通过TLS）后可用给的。查询交易可以使用与调用交易相同的格式。对应下面的例1，如果查询用户又有部署交易的ACL中的一张TCert，那么就可以得到创建这个部署交易的用户的注册ID（enrollmentID）。对应下面的例2，如果查询所使用TCert的注册ID（enrollmentID）与部署交易中访问控制域的其中一个隶属关系/角色匹配，那么就可以得到创建这个部署交易的用户的注册ID（enrollmentID）。 @@ -1538,8 +1542,7 @@ the same chaincode by the same user. Subection 5.2.2 elaborates on this.--> 最后，交易在客户端，通过它们的创建者的证书签名，并发送给验证器网络。 验证器接受私密交易，并通过下列阶段传递它们： -* *预验证*阶段，验证器根据根证书颁发机构来验证交易证书，验证交易（静态的）中包含交易证书签名，并验证交易是否为重放（参见，下面关于重放攻击的详细信息） -Validators receive the confidential transactions, and pass them through the following phases: +* *预验证*阶段，验证器根据根证书颁发机构来验证交易证书，验证交易（静态的）中包含交易证书签名，并验证交易是否为重放（参见，下面关于重放攻击的详细信息）。 * *共识*阶段， 验证器把这笔交易加入到交易的全序列表中（最终包含在总账中） * *预执行*阶段， 验证交易/注册证书是否在当前的有效期中 解密交易（如果交易是加密的），并验证交易明文的形式正确（即，符合调用访问控制，包含TCert形式正确） @@ -1632,7 +1635,7 @@ where appropriate key material is passed to the 最后给用户发放一个合同的公钥PKc，使得他们可以根据合同加密信息，从而验证器(or any in possession of SKc)可以读取它。每个合同用户的交易证书被添加到交易中，并跟随在用户信息之后。这可以使得用户可以很容易的搜索到有他们参与的交易。注意，为了信函可以在本地不保存任何状态的情况下也能通过分析总账来获取这笔交易，部署交易也会添加信息到链码创建者uc。 -整个交易由链码的创建者的证书签名，即：有信函决定使用注册还是交易证书。 +整个交易由链码的创建者的证书签名，即：由后者决定使用注册还是交易证书。 两个值得注意的要点： * 交易中的信息是以加密的方式存储的，即，code-functions， * code-hdrs在使用TCert加密整个交易之前会用想用的TCert签名，或使用不同的TCert或ECert（如果交易的部署需要带上用户的身份。一个绑定到底层交易的载体需要包含在签名信息中，即，交易的TCert的哈希是签名的，因此mix\&match攻击是不可能的。我们在4.4节中详细讨论这样的攻击，在这种情况下，攻击者不能从他看到的交易中分离出对应的密文，即，代码信息，并在另一个交易中使用它。很明显，这样会打乱整个系统的操作，链码首先有用户A创建，现在还属于恶意用户B（可能没有权限读取它） @@ -1692,7 +1695,7 @@ where appropriate key material is passed to the ### 4.4 应用的访问控制功能 -应用是抱在区块链客户端软件上的一个具有特定功能的软件。如餐桌预订。应用软件有一个版本开发商，使后者可以生成和管理一些这个应用所服务的行业所需要的链码，而且，客户端版本可以允许应用的终端用户调用这些链码。应用可以选择是否对终端用户屏蔽区块链。 +应用是运行在区块链客户端软件上的一个具有特定功能的软件。如餐桌预订。应用软件有一个开发版本，使后者可以生成和管理一些这个应用所服务的行业所需要的链码，而且，客户端版本可以允许应用的终端用户调用这些链码。应用可以选择是否对终端用户屏蔽区块链。 本节介绍应用中如何使用链码来实现自己的访问控制策略，并提供如何使用成员服务来达到相同的目的。 @@ -1923,7 +1926,7 @@ message Transaction { OBCSecCtx指向用户证书，它依赖于注册过程中的阶段。可以是用户的注册ID和密码，`` 或他的注册证书和关联的密钥(ECertu, sku), 其中 sku是用户签名和解密密钥的简化标记。 OBCSecCtx需要给在线钱包服务必要的信息来注册用户和发布需要的TCerts。 -对于后续的请求，用户u需要提供给钱包服务的请求与虾子面这个格式类似。 +对于后续的请求，用户u需要提供给钱包服务的请求与下面这个格式类似。 TransactionRequest /* account request of u \*/ { @@ -1960,8 +1963,7 @@ TLS CA需要给（非验证）peer，验证器，和单独的客户端（或具 #### 4.7.1 简化客户端 -客户端的注册和交易的创建是由非验证 peer 以在线钱包的角色全部执行的。 -集体的，终端用户利用注册证书 在非验证 peer 开立账户，并使用这些证书进一步授权 peer 建立代表用户的交易。 +客户端的注册和交易的创建是由非验证 peer 以在线钱包的角色全部执行的。特别地，终端用户利用他们的注册证书向非验证 peer 开立账户，并且使用这些证书来进一步授权 peer 建立代表用户的交易。 需要注意的是，这样的设计不会为 peer 代表用户提交的交易提供安全**授权**，如恶意 peer 可以模拟用户。 网上钱包的涉及安全问题设计规范的详细信息，可以在4.5节找到。 目前用户可以注册和执行交易的 peer 数量是一。 @@ -2104,7 +2106,7 @@ func StartOpenchainRESTServer(server *oc.ServerOpenchain, devops *oc.Devops) ## 6.2 REST API -您可以通过您所选择的任何工具与REST API的工作。例如，curl命令行实用程序或一个基于浏览器的客户端，如Firefox的REST客户端或Chrome Postman。同样，可以通过[Swagger]（http://swagger.io/）直接触发REST请求。为了获得REST API Swagger描述，点击[这里]（https://github.com/hyperledger/fabric/blob/master/core/rest/rest_api.json）。目前可用的API总结于以下部分。 +您可以通过您所选择的任何工具与REST API的工作。例如，curl命令行实用程序或一个基于浏览器的客户端，如Firefox的REST客户端或Chrome Postman。同样，可以通过 [Swagger](http://swagger.io/) 直接触发REST请求。为了获得REST API Swagger描述，点击 [这里](https://github.com/hyperledger/fabric/blob/master/core/rest/rest_api.json)。目前可用的API总结于以下部分。 ### 6.2.1 REST Endpoints