草酸亚铁
BlockChain技术系列（四）-fabric安全介绍
这⼀节将讨论下⾯的图所展⽰的设置描述。特别的，系统是由下⾯这些实体构成的：成员管理基础架构，如从⼀个实体集合中区分出不同⽤户⾝份的职责（使⽤系统中任意形式的标识，如：信⽤卡，⾝份证），为这个⽤户注册开户，并⽣成必要的证书以便通过fabric成功的创建交易，部署或调⽤链码。 城市信报
Peers, 它们被分为验证 peer 和⾮验证 peer。验证 peer（也被称为验证器）是为了规范并处理（有效性检查，执⾏并添加到区块链中）⽤户消息（交易）提交到⽹络上。⾮验证 peer（也被称为 peer）代表⽤户接受⽤户交易，并通过⼀些基本的有效性检查，然后把交易发送到它们附近的验证 peer。peer 维护⼀个最新的区块链副本，只是为了做验证，⽽不会执⾏交易(处理过程也被称为交易验证)。注册到我们的成员服务管理系统的终端⽤户是在获取被系统认定的⾝份的所有权之后，并将获取到的证书安装到客户端软件后，提交交易到系统。
客户端软件，为了之后能完成注册到我们成员服务和提交交易到系统所需要安装在客户端的软件
在线钱包，⽤户信任的⽤来维护他们证书的实体，并独⾃根据⽤户的请求向⽹络提交交易。在线钱包配置在他们⾃⼰的客户端软件中。这个软件通常是轻量级的，它只需有对⾃⼰和⾃⼰的钱包的请求做授权。也有 peer 为⼀些⽤户扮演在线钱包的⾓⾊，在接下来的会话中，对在线钱包做了详细区分。
希望使⽤fabric的⽤户，通过提供之前所讨论的⾝份所有权，在成员管理系统中开⽴⼀个账户，新的链码被链码创建者（开发）以开发者的形式通过客户端软件部署交易的⼿段，公布到区块链⽹络中。这样的交易是第⼀次被 peer 或验证器接收到，并流传到整个验证器⽹络中，这个交易被区块链⽹络执⾏并到⾃⼰的位置。⽤户同样可以通过调⽤交易调⽤⼀个已经部署了的链码
下⼀节提供了由商业⽬标所驱动的安全性需求的摘要。然后我们游览⼀下安全组件和它们的操作，以及如何设计来满⾜安全需求。
4.1 商业安全需求
⾝份和⾓⾊管理相结合
这⼀节表述的与fabric相关的商业安全需求。 ⾝份和⾓⾊管理相结合
为了充分的⽀持实际业务的需求，有必要超越确保加密连续性来进⾏演进。⼀个可⼯作的B2B系统必须致⼒于证明/展⽰⾝份或其他属性来开展业务。商业交易和⾦融机构的消费交互需要明确的映射到账户的所有者。商务合同通常需要与特定的机构和/或拥有交易的其他特定性质的各⽅保证有从属关系。⾝份管理是此类系统的关键组成部分的两个原因是问责制和不可陷害的。
问责制意味着系统的⽤户，个⼈或公司，谁的胡作⾮为都可以追溯到并为⾃⼰的⾏为负责。在很多情
况下，B2B系统需要它们的会员使⽤他们的⾝份（在某些形式）加⼊到系统中，以确保问责制的实⾏。问责制和不可陷害的。都是B2B系统的核⼼安全需求，并且他们⾮常相关。B2B系统需要保证系统的诚实⽤户不会因为其他⽤户的交易⽽被指控。
此外，⼀个B2B系统需要具有可再⽣性和灵活性，以满⾜参与者⾓⾊和/或从属关系的改变。
交易隐私.
B2B系统对交易的隐私有着强烈的需求，如：允许系统的终端⽤户控制他与环境交互和共享的信息。例如：⼀家企业在交易型B2B系统上开展业务，要求它的交易得其他企业不可见，⽽他的⾏业合作伙伴⽆权分享机密信息。
在fabric中交易隐私是通过下⾯⾮授权⽤户的两个属性来实现的:
交易匿名，交易的所有者隐藏在⼀个被称为匿名集的组建中，在fabric中，它是⽤户的⼀个集合。
交易不可关联，同⼀⽤户的两个或多个交易不能被关联起来。
根据上下⽂，⾮授权⽤户可以是系统以外的任何⼈，或⽤户的⼦集。
交易隐私与B2B系统的两个或多个成员之间的保密协议的内容强烈相关。任何授权机制的匿名性和不可关联性需要在交易时考虑。
通过⾝份管理协调交易隐私.
就像⽂档之后描述的那样，这⾥所采⽤的⽅法是使户隐私来协调⾝份管理，并使有竞争⼒的机构可以像下⾯⼀样在公共的区块链（⽤于内部和机构间交易）上快速的交易：
1. 为交易添加证书来实现“有权限的”区块链
华大博雅
2. 使⽤两层系统：
1. 向登记的证颁发机构（CA）注册来获得(相对的) 静态登记证书 (ECerts)
2. 通过交易CA获取能如实但伪匿名的代表登记⽤户的交易证书(TCerts).
3. 提供对系统中未授权会员隐藏交易内⽤的机制
审计⽀持.
审计⽀持. 商业系统偶尔会受到审核。在这种情况下，将给予审计员检查某些交易，某组交易，系统
中某些特定⽤户或系统⾃⼰的⼀些操作的⼿段。因此，任意与商业伙伴通过合同协议进⾏交易的系统都应该提供这样的能⼒。
4.2 使⽤成员管理的⽤户隐私
成员管理服务是由⽹络上管理⽤户⾝份和隐私的⼏个基础架构来组成的。这些服务验证⽤户的⾝份，在系统中注册⽤户，并为他/她提供所有作为可⽤、兼容的参数者来创建和/或调⽤交易所需要的证书。公告密钥体系（Public Key Infrastructure ，PKI）是⼀个基于不仅对公共⽹络上交换的数据的加密⽽且能确认对⽅⾝份的公共密钥加密的。PKI管理密钥和数字证书的⽣成，发布和废⽌。数字证书是⽤来建⽴⽤户证书，并对消息签名的。使⽤证书签名的消息保证信息不被篡改。典型的PKI有⼀个证书颁发机构（CA），⼀个登记机构（RA），⼀个证书数据库，⼀个证书的存储。RA是对⽤户进⾏⾝份验证，校验数据的合法性，提交凭据或其他证据来⽀持⽤户请求⼀个或多个⼈反映⽤户⾝份或其他属性的可信任机构。CA根据RA的建议为特定的⽤户发放根CA能直接或分级的认证的数字证书。另外，RA的⾯向⽤户的通信和尽职调查的责任可以看作CA的⼀部分。成员服务由下图展⽰的实体组成。整套PKI体系的引⼊加强了B2B系统的强度（超过，如：⽐特币）
根证书颁发机构(根CA): 它代表PKI体系中的信任锚。数字证书的验证遵循信任链。根CA是PKI层次结构中最上层的CA。
登记机构(RA): 它是⼀个可以确定想要加⼊到带权限区块链的⽤户的有效性和⾝份的可信实体。它是负责与⽤户外的带外通信来验证他/她的⾝份和作⽤。它是负责与⽤户进⾏频外通信来验证他/她的⾝份和⾓⾊。它创建登记时所需要的注册证书和根信任上的信息。
注册证书颁发机构(ECA): 负责给通过提供的注册凭证验证的⽤户颁发注册证书(ECerts)
交易认证中⼼(TCA): 负责给提供了有效注册证书的⽤户颁发交易证书(TCerts)
TLS证书颁发机构(TLS-CA): 负责签发允许⽤户访问其⽹络的TLS证书和凭证。它验证⽤户提供的包含该⽤户的特定信息的，⽤来签发TLS 证书的，证书或证据。
注册证书(ECerts) ECerts是长期证书。它们是颁发给所有⾓⾊的，如⽤户，⾮验证 peer，验证 peer。在给⽤户颁发的情况下，谁向区块链提交候选⼈申请谁就拥有TCerts（在下⾯讨论），ECerts有两种可能的结构和使⽤模式：
dsjModel A: ECerts 包含所有者的⾝份/注册ID，并可以在交易中为TCert请求提供只⽤来对名义实体⾝份做验证。它们包含两个密钥对的公共部分：签名密钥对和加密/密钥协商密钥对。 ECerts是每个⼈都可以访问。
Model B: ECerts 包含所有者的⾝份/注册ID，并只为TCert请求提供名义实体的⾝份验证。它们包含⼀
个签名密钥对的公共部
分，即，签名验证公钥的公共部分。作为依赖⽅，ECerts最好只由TCA和审计⼈员访问。他们对交易是不可见的，因此（不像
TCerts）签名密钥对不在这⼀层级发挥不可抵赖的作⽤。
交易证书(TCerts) TCerts是每个交易的短期证书。它们是由TCA根据授权的⽤户请求颁发的。它们安全的给⼀个交易授权，并可以被配置为隐藏谁参与了交易或选择性地暴露这样⾝份注册ID这样的信息。他们包含签名密钥对的公共部分，并可以被配置为包含⼀个密钥协议的密钥对的公共部分。他们仅颁发给⽤户。它们唯⼀的关联到所有者，它们可以被配置为这个关联只有TCA知道知道（和授权审核员）。TCert 可以配置成不携带⽤户的⾝份信息。它们使得⽤户不仅以匿名⽅式参与到系统中，⽽且阻⽌了交易之间的关联性。
然⽽，审计能⼒和问责制的要求TCA能够获取给定⾝份的TCert，或者获取指定TCert的所有者。有关TCerts如何在部署和调⽤交易中使⽤的详细信息参见4.3节，交易安全是在基础设施层⾯提供的。
TCerts可容纳的加密或密钥协议的公共密钥（以及数字签名的验证公钥）。 如果配备好TCert，那么就需要注册证书不能包含加密或密钥协议的公钥。
这样的密钥协议的公钥，Key_Agreement_TCertPub_Key，可以由交易认证机构（TCA）使⽤与⽣成
Signature_Verification_TCertPub_Key同样的⽅法，使⽤TCertIndex + 1 ⽽不是TCertIndex来作为索引个值来⽣成，其中TCertIndex 是由TCA为了恢复⽽隐藏在TCert中的。交易证书（TCert）的结构如下所述：TCertID – 交易证书ID（为了避免通过隐藏的注册ID发⽣的意外可关联性，最好由TCA随机⽣成）.
Hidden Enrollment ID: AES_Encrypt (enrollmentID), 其中密钥K = [HMAC(Pre-K, TCertID)]其中为每个K定义三个不同的密钥分配⽅案：(a)， (b) and (c)。
Hidden Private Keys Extraction: AES_Encrypt (TCertIndex || 已知的填充/校验检查向量) 其中||表⽰连K 256位截断TCertOwner_EncryptKey
接，其中各个批次具有被加到计数器的唯⼀（每个批次）的时间戳/随机偏移量（这个实现中初始化为1）来⽣成TCertIndex。该计数器可以通过每次增加2来适应TCA⽣成公钥，并由这两种类型的私钥的TCert所有者来恢复，如签名密钥对和密钥协商密钥对。Sign Verification Public Key – TCert签名验证的公共密钥。Key Agreement Public Key – TCert密钥协商的公钥.
Validity period – 该交易证书可⽤于交易的外/外部签名的时间窗⼝。
这⾥⾄少有三种⽅式来配置考虑了隐藏注册ID域密钥的分配⽅案： (a) Pre-K在注册期间发给⽤户，peer 和审计员，并对TCA和授权的审计员可⽤。它可能，例如由K 派⽣（会在这个规范的后⾯描述）或为了链码的保密性使⽤独⽴的key(s)。
(b) Pre-K对验证器，TCA和授权的审计员可⽤。K是在验证器成功响应⽤户的查询交易（通过TLS）后可⽤给的。查询交易可以使⽤与调⽤交易相同的格式。对应下⾯的例1，如果查询⽤户⼜有部署交易的ACL中的⼀张TCert，那么就可以得到创建这个部署交易的⽤户的注册ID（enrollmentID）。对应下⾯的例2，如果查询所使⽤TCert的注册ID（enrollmentID）与部署交易中访问控制域的其中⼀个⾪属关系/⾓⾊匹配，那么就可以得到创建这个部署交易的⽤户的注册ID（enrollmentID）。
Example 1:
Example 2:
(c) Pre-K对TCA和授权的审计员可⽤。对于批量中的所有TCert，TCert特有的K可以和TCert⼀起分发给TCert的所有者（通过TLS）。这样就通过K的TCert所有者启⽤⽬标释放（TCert所有者的注册ID的可信通知）。这样的⽬标释放可以使⽤预定收件⼈的密钥协商公钥和/或PK 其中SK 就像规范的后⾯描述的那样对验证器可⽤。这样⽬标释放给其它合同的参与者也可以被纳⼊到这个交易或在频外完成。如果TCert与上述的ECert模型A的结合使⽤，那么使⽤K不发送给TCert的所有者的⽅案（c）就⾜够了。
如果TCert与上述的ECert模型A 的结合使⽤，那么TCert中的密钥协商的公钥域可能就不需要了。
交易认证中⼼(TCA)以批量的⽅式返回TCert，每个批量包含不是每个TCert都有的，但是和TCert的批量⼀起传递到客户端的
KeyDF_Key(Key-Derivation-Function Key) （通⽤TLS）。KeyDF_Key允许TCert的拥有者派⽣出真正⽤于从
AES_Encrypt （TCertIndex || 已知的填充/校验检查向量）的TCertIndex恢复的TCertOwner_EncryptKey。
TLS证书(TLS-Certs) TLS-Certs 是⽤于系统/组件到系统/组件间通讯所使⽤的证书。他们包含所有者的⾝份信息，使⽤是为了保证⽹络基本的安全。
成员管理的这个实现提供下⾯描述的基础功能：ECerts是没有到期/废⽌的；TCert的过期是由验证周期的时间窗⼝提供的。TCerts是没有废⽌的。ECA，TCA和TLS CA证书是⾃签名的，其中TLS CA提供信任锚点。
4.2.1 ⽤户/客户端注册过程
下⾯这个图⾼度概括了⽤户注册过程，它具有离线和在线阶段。
离线处理: 在第⼀步中，每个⽤户/⾮验证 peer /验证 peer 有权在线下将较强的识别凭证（⾝份证明）到导⼊到注册机构（RA）。这需要在频外给RA提供为⽤户创建（存储）账号的证据凭证。第⼆步，RA返回对应的⽤户名/密码和信任锚点（这个实现中是TLS-CA Cert）给⽤户。如果⽤户访问了本地客户端，那么这是客户端可以以TLS-CA证书作为信任锚点来提供安全保障的⼀种⽅法。
在线阶段: 第三步，⽤户连接客户端来请求注册到系统中。⽤户发送它的⽤户名和密码给客户端。客户端代表⽤户发送请求给PKI框架。第四步，接受包，第五步，包含其中⼀些对应于由客户端私有/秘密密钥的若⼲证书。⼀旦客户端验证包中所有加密材料是正确/有效的，他就把证书存储在本地并通知⽤户。这时候⽤户注册就完成了。
图4展⽰了注册的详细过程。PKI框架具有RA， ECA， TCA和TLS-CA这些实体。第⼀步只收，RA调⽤“AddEntry”函数为它的数据库输⼊（⽤户名/密码）。这时候⽤户已正式注册到系统数据库中。客户端需要TLS-CA证书（当作信任锚点）来验证与服务器之间的TLS握⼿是正确的。第四步，客户端发送包含注册公钥和像⽤户名，密码这样的附加⾝份信息的注册请求到ECA（通过TLS备案层协议）。ECA验证这个⽤户是否真实存在于数据库。⼀旦它确认⽤户有权限提交他/她的注册公钥，那么ECA就会验证它。这个注册信息是⼀次性的。ECA会更新它的数据库来标识这条注册信息（⽤户名，密码）不能再被使⽤。ECA构造，签名并送回⼀张包含⽤户注册公钥的（步骤5）注册证书（ECert）。它同样会发送将来会⽤到（客户端需要向TCA证明他/她的ECert使⽤争取的ECA创建的）的ECA证书（EC
A-Cert)）。（尽管ECA-Cert在最初的实现中是⾃签名的，TCA，TLS-CA和ECA是共址）第六步，客户端验证ECert中的公钥是最初由客户端提交的（即ECA没有作弊）。它同样验证ECert中的所有期望的信息存在且形式正确。
chain chain chain TCertOwner_EncryptKey
同样的，在第七步，客户端发送包含它的公钥和⾝份的注册信息到TLS-CA。TLS-CA验证该⽤户在数据库中真实存在。TLS-CA⽣成，签名包含⽤户TLS公钥的⼀张TLS-Cert（步骤8）。TLS-CA发送TLS-Cert和它的证书（TLS-CA Cert）。第九步类似于第六步，客户端验证TLS Cert中的公钥是最初由客户端提交的，TLS Cert中的信息是完整且形式正确。在第⼗步，客户端在本地存储中保存这两张证书的所有证书。这时候⽤户就注册完成了。
在这个版本的实现中验证器的注册过程和 peer 的是⼀样的。尽管，不同的实现可能使得验证器直接通过在线过程来注册。
客户端: 请求TCert批量需要包含（另外计数），ECert和使⽤ECert私钥签名的请求（其中ECert的私钥使⽤本地存储获取的）
TCA为批量⽣成TCerts: ⽣成密钥派⽣函数的密钥，KeyDF_Key, 当作HMAC(TCA_KDF_Key, EnrollP
ub_Key). 为每张TCert⽣成公钥(使⽤TCertPub_Key = EnrollPub_Key + ExpansionValue G, 其中384位的ExpansionValue = HMAC(Expansion_Key, TCertIndex)和384位的Expansion_Key = HMAC(KeyDF_Key, “2”)). ⽣成每个AES_Encrypt (TCertIndex || 已知的填充/校验检查向量)， 其中|| 表⽰连接，且TCertOwner_EncryptKey被当作[HMAC(KeyDF_Key, “1”)]派⽣.
客户端: 为部署，调⽤和查询，根据TCert来⽣成TCert的私钥：KeyDF_Key和ECert的私钥需要从本地存储中获取。KeyDF_Key是⽤来派⽣被当作[HMAC(KeyDF_Key, “1”)]的TCertOwner_EncryptKey；TCertOwner_EncryptKey是⽤来对TCert中的
AES_Encrypt (TCertIndex || 已知的填充/校验检查向量)域解密的；TCertIndex是⽤来派⽣TCert的私钥的：TCertPriv_Key = (EnrollPriv_Key + ExpansionValue)模n，其中384位的ExpansionValue = HMAC(Expansion_Key,
TCertIndex)，384位的Expansion_Key = HMAC(KeyDF_Key, “2”)。
4.2.2 过期和废⽌证书
实际是⽀持交易证书过期的。⼀张交易证书能使⽤的时间窗是由‘validity period’标识的。实现过期⽀持的挑战在于系统的分布式特性。也就是说，所有验证实体必须共享相同的信息；即，与交易相关的
有效期验证需要保证⼀致性。为了保证有效期的验证在所有的验证器间保持⼀致，有效期标识这⼀概念被引⼊。这个标识扮演着逻辑时钟，使得系统可以唯⼀识别有效期。在创世纪时，链的“当前有效期”由TCA 初始化。⾄关重要的是，此有效期标识符给出随时间单调增加的值，这使得它规定了有效期间总次序。
对于指定类型的交易，系统交易有效周期标识是⽤来⼀起向区块链公布有效期满的。系统交易涉及已经在创世纪块被定义和作为基础设施的⼀部分的合同。有效周期标识是由TCA周期性的调⽤链码来更新的。注意，只有TCA允许更新有效期。TCA通过给定义了有效期区间的‘not-before’和‘not-after’这两个域设置合适的整数值来为每个交易证书设置有效期。
TCert过期: 在处理TCert时，验证器从状态表中读取与总账中的‘current validity period’相关的值来验证与交易相关的外部证书⽬前是否有效。状态表中的当前值需要落在TCert的‘not-before’和‘not-after’这两个⼦域所定义的区间中。如果满⾜，那么验证器就继续处理交易。如果当前值没有在这个区间中，那么TCert已经过期或还没⽣效，那么验证器就停⽌处理交易。
ECert过期: 注册证书与交易证书具有不同的有效期长度。
废⽌是由证书废⽌列表（CRLs）来⽀持的，CRLs鉴定废⽌的证书。CRLs的改变，增量的差异通过区块链来公布
4.3 基础设施层⾯提供的交易安全
fabric中的交易是通过提交⽤户-消息来引⼊到总账中的。就像之前章节讨论的那样，这些信息具有指定的结构，且允许⽤户部署新的链码，调⽤已经存在的链码，或查询已经存在的链码的状态。因此交易的⽅式被规范，公布和处理在整个系统提供的隐私和安全中起着重要的作⽤。
⼀⽅⾯我们的成员服务通过检查交易是由系统的有效⽤户创建的来提供验证交易的⼿段，为了把⽤户⾝份和交易撇清，但是在特定条件下⼜需要追踪特定个体的交易（执法，审计）。也就是说，成员服务提供结合⽤户隐私与问责制和不可抵赖性来提供交易认证机制。
另⼀⽅⾯，fabric的成员服务不能单独提供完整的⽤户活动隐私。⾸先fabric提供完整的隐私保护条款，隐私保护认证机制需要通过交易保密协同。很明显，如果认为链码的内容可能会泄漏创建者的信息，那么这就打破了链码创建者的隐私要求。第⼀⼩节讨论交易的保密性。为链码的调⽤强制访问控制是⼀个重要的安全要求。fabric暴露给应⽤程序（例如，链码创建者）这意味着当应⽤利⽤fabric的成员服务是，需要应⽤⾃⼰调⽤访问控制。4.4节详细阐述了这⼀点。
重放攻击是链码安全的另⼀个重要⽅⾯，作为恶意⽤户可能复制⼀个之前的，已经加⼊到区块链中的交易，并向⽹络重放它来篡改它的操作。这是第4.3.3节的话题。
本节的其余部分介绍了基础设施中的安全机制是如何纳⼊到交易的⽣命周期中，并分别详细介绍每⼀个安全机制。
TCertOwner_EncryptKey 256位截断256位截断TCertOwner_EncryptKey
4.3.1 交易安全的⽣命周期
交易在客户端创建。客户端可以是普通的客户端，或更专⽤的应⽤，即，通过区块链处理（服务器）或调⽤（客户端）具体链码的软件部分。这样的应⽤是建⽴在平台（客户端）上的，并在4.4节中详细介绍。新链码的开发者可以通过这些fabric的基础设施来新部署交易：希望交易符合保密/安全的版本和类型
希望访问部分链码的⽤户有适当的（读）访问权限<!-- (read-access code/state/activity, invocation-access) -->链码规范代码元数据，包含的信息需要在链码执⾏时传递给它（即，配置参数），和
附加在交易结构上的并只在应⽤部署链码时使⽤的交易元数据
具有保密限制的链码的调⽤和查询交易都是⽤类似的⽅式创建。交易者提供需要执⾏的链码的标识，要调⽤的函数的名称及其参数。可选的，调⽤者可以传递在链码执⾏的时候所需要提供的代码调⽤元数据给交易创建函数。交易元数据是调⽤者的应⽤程序或调⽤者本⾝为了它⾃⼰的⽬的所使⽤的另外
⼀个域。最后，交易在客户端，通过它们的创建者的证书签名，并发送给验证器⽹络。 验证器接受私密交易，并通过下列阶段传递它们：
预验证阶段，验证器根据根证书颁发机构来验证交易证书，验证交易（静态的）中包含交易证书签名，并验证交易是否为重放（参见，下⾯关于重放攻击的详细信息） Validators receive the confidential transactions, and pass them through the following phases：共识阶段， 验证器把这笔交易加⼊到交易的全序列表中（最终包含在总账中）
预执⾏阶段， 验证交易/注册证书是否在当前的有效期中 解密交易（如果交易是加密的），并验证交易明⽂的形式正确（即，符合调⽤访问控制，包含TCert形式正确） 在当前处理块的事务中，也执⾏了简单的重放攻击检查。执⾏阶段， (解密的) 链码和相关的代码元数据被传递给容器，并执⾏。
提交 阶段， (解密的)更新的链码的状态和交易本⾝被提交到总账中。
4.3.2 交易保密性威廉加拉
在开发⼈员的要求下，交易机密性要求链码的原⽂，即代码，描述，是不能被未授权的实体（即，未被开发⼈员授权的⽤户或 peer）访问或推导（assuming a computational attacker）出来。对于后者，部署和调⽤交易的内容始终被隐藏对链码的保密需求是⾄关重要的。本着同样的精神，未授权⽅，不应该能联系链码（调⽤交易）与链码本⾝（部署交易）之间的调⽤关系或他们之间的调⽤。
任何候选的解决⽅案的附加要求是，满⾜并⽀持底层的成员服务的隐私和安全规定。此外，在fabric中他不应该阻⽌任何链码函数的调⽤访问控制，或在应⽤上实现强制的访问控制机制(参看4.4⼩结)。
下⾯提供了以⽤户的粒度来设置的交易机密性机制的规范。最后⼩结提供了⼀些如何在验证器的层次来扩展这个功能的⽅针。当前版本所⽀持的特性和他的安全条款可以在4.7节中到。
⽬标是达到允许任意的⼦集实体被允许或限制访问链码的下⾯所展⽰的部分： 1. 链码函数头，即，包含在链码中函数的原型
1. 链码[调⽤&] 状态，即， 当⼀个或多个函数被调⽤时，连续更新的特定链码的状态。
2. 所有上⾯所说的
注意，这样的设计为应⽤提供利⽤fabric的成员管理基础设施和公钥基础设施来建⽴⾃⼰的访问控制策略和执法机制的能⼒。
4.3.2.1 针对⽤户的保密
为了⽀持细粒度的保密控制，即，为链码创建者定义的⽤户的⼦集，限制链码的明⽂读权限，⼀条绑定到单个长周期的加密密钥对的链（PK , SK ）。
尽管这个密钥对的初始化是通过每条链的PKI来存储和维护的，在之后的版本中，这个限制将会去除。链（和相关的密钥对）可以由任意带有特定（管理）权限的⽤户通过区块链来触发（参看4.3.2.2⼩节）
以吏为师搭建搭建. 在注册阶段， ⽤户获取（像之前⼀样）⼀张注册证书，为⽤户u 标记为Cert ，其中每个验证器v 获取的注册证书标记为Cert 。注册会给⽤户或验证器发放下⾯这些证书：
1. ⽤户：
a. 声明并授予⾃⼰签名密钥对(spk , ssk )chain chain i u i j v j u u
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议