本文作者：李世敬、吴琛、胡麦芳![]()
近日，央行发布《金融分布式账本技术安全规范》，在业内被视为区块链在金融行业内应用的重要标准。该标准规定了金融分布式账本技术的安全体系架构，在基础硬件、基础软件、密码算法、节点通信、账本数据、共识协议、智能合约、身份管理、隐私保护、监管支撑、运维要求、治理机制等多方面的规范，对区块链技术在金融行业的应用提出了更高的要求。
趣链科技始终坚持自主、可控的区块链技术研发，并于2016年推出了全自研趣链区块链平台，经过持续的迭代升级，在性能优化、功能升级、隐私保护、监管支持等方面不断完善和加强，取得了丰富的效果。平台在工信部、银联、票交所等多家权威机构评测中均名列第一，也是目前行业内落地金融相关场景最多的区块链平台。
随着《安全规范》的发布，我们以自研区块链平台产品作为参照，在第一时间进行了深度分析，趣链区块链平台在重点领域均满足相关规范与要求，企业客户使用趣链区块链平台开展金融类业务，无需做大幅度的改造。
与此同时，以Hyperledger Fabric为代表的其他区块链平台，其在硬件加密、节点容错、身份管理、隐私保护、监管审计等层面尚未完全符合规范要求，在实际落地金融业务过程中存在底层平台重新改造的风险。
本文就趣链区块链平台和Hyperledger Fabric v2.0（下称Fabric）在《安全规范》中的符合情况与程度进行分析和对比，并提出需要重点关注的条例和要求。
符合国密的硬件级别高安全防护
在基础硬件层面，标准强调：“加密机设备应符合国家密码管理部门颁布的GM/T 0045-2016的要求。使用的个人硬件密码设备，应符合行业主管部门和国家密码管理部门相关要求。”
针对用户密钥和链上信息的安全性需求，趣链区块链平台构建软硬件相结合的安全基础设施，适配符合国密GM/T 0045-2016以及商用密码检测中心标准的硬件密码卡（PCIE密码卡，型号SJK1862-G）和智能密码钥匙（型号SJK1905）等加密机设备，同时支持密钥备份和导出等一系列服务，有效保证了密钥不可篡改，为用户敏感信息保驾护航。
Fabric原生架构中没有进行安全硬件适配，暂不符合商用密码中心标准，如需符合标准则需要相关金融机构自行投入人力、硬件成本以满足要求。
看得见的审计记录
在账本数据层面，标准要求：“账本数据应具有一致性和保密性，对其访问和使用应具有安全审计功能，审计记录包括访问日期、时间、用户标识、数据内容等审计相关信息，数据变更（包括失败的变更）、节点一致性校验失败也应提供审计记录。”
趣链区块链平台通过账本容错机制和账本加密功能保证了账本数据的一致性和保密性。而标准中账本数据可审计的规定给分布式账本系统提出了更高的要求。平台提供日志结构化、合约数据可视化功能，结合趣链飞洛BaaS平台，提供账户信息可视化、日志数据可视化、账本数据可视化等服务，可以很好地满足账本审计相关需求。
Fabric提供了类似SQL查询账本的功能，可进行有效审计，网络参与者见证的交易都可以被授权的监管机构和审计人员检测和跟踪。然而针对标准中关于审计记录的可验可查，Fabric并不能满足，基于Fabric的区块链金融项目，需要投入一定的二次开发成本才能满足相关账本审计的需求。
健壮的共识算法
在共识协议层面，标准强调：“协议应具备抗DDoS攻击、处理恶意报文、识别恶意节点的能力,且应采取不转发、拒绝连接、黑名单等措施缩小影响。单次共识过程和系统运行的整个共识历史都应可审计、可监管, 该历史应不可被纂改。”
趣链区块链平台针对共识协议节点恶意攻击的问题，采用RBFT高鲁棒性拜占庭容错共识算法，并自研Recovery机制，能够保证动态数据的失效恢复。同时通过多层级的日志系统进行共识过程的记录，做到对故障/欺诈节点的感知、确认、处理、记录等全流程管控。
而Fabric在v1.0以后采用Kafka进行交易的定序，在v1.4.1后支持RAFT共识算法，这两种实现方式可以容忍半数节点失效，但不支持拜占庭容错，即不能容忍节点作恶，需适配拜占庭容错共识算法才能满足规范要求。
支持全国密的密码安全模块
在密码算法层面，标准强调：“在存储敏感的业务数据、身份鉴别数据和密钥数据之前，应使用符合国家标准的加密算法、消息鉴别码算法、数字签名等技术提供通信中数据的完整性保护和校验。使用随机数应按照国家密码管理部门相关要求生成随机序列，并符合GB/T 32915-2016要求。使用数字签名等技术保证实体行为的不可否认性，其应用场景包括实体行为的确认、背书方对实体行为进行的背书。”
针对敏感业务数据、身份鉴别数据和密钥数据的存储问题，趣链区块链平台早在2016年就已支持国密标准，使用SM2、SM3、SM4、SM9等国密算法对以上数据进行安全加密，全方位地保证数据在存储、传输、使用过程中的安全性。与此同时，平台对接了第三方证书机构CFCA，可提供真实可信的证书服务。
原生Fabric暂不支持国密标准，主要通过密码套件接口BCCSP支持国际标准的各类加密哈希算法，并应用于相关签名、验签、数据加密等处理流程中，处理过程中存在着大量不可控因素，同时通过自身的安全成员服务MSP而不是第三方可信证书机构提供证书服务。基于Fabric架构的金融项目需要适配新的密码模块，以符合标准要求。
智能合约管理新机制
在智能合约层面，标准强调：“应在部署或升级操作时定义版本号，交易信息中应明确调用的智能合约版本。具有前向兼容能力，旧版本合约应及时停用并存档，新版本合约能调用历史数据。支持智能合约之间相互访问的条件下，限制错误智能合约的感染。控制智能合约对外部环境的访问。系统有代码漏洞审核机制，智能合约发布应引入相关方联合审核机制，审核流程高效、严谨。满足智能合约从部署到废止的生命周期相关要求。”
趣链区块链平台针对智能合约版本、访问、审计、生命周期管理等一系列问题，采用“纵横”管理策略，纵向支持合约版本无缝升级、向前兼容、调用历史数据等兼容性能力；横向提供完备的合约生命周期管理，包括合约的创建部署、调用销毁、冻结存档等。趣链区块链平台作为首个支持Java语言编写智能合约的底层区块链平台，提供完备的合约部署、升级、冻结、解冻、销毁、存档全流程管理机制。另外平台针对智能合约相关标准还支持以下特性：
- 针对外部数据访问，平台实现Oracle预言机机制保证合约能够安全可控的访问外部可信数据。
- 针对合约安全审计，平台提供了合约安全审计服务MeshSec，为开发者提供完善的合约漏洞分析、形式验证以及合约安全评级等安全检测服务。
- 针对合约的联合审核，平台通过联盟自治机制CAF（Consortium Autonomous Framework），不仅可以支持合约版本控制，还可提供成员管理、系统升级层面的联合审核治理机制，对合约及系统进行高效管理，以避免中心化审核的集权问题。
Fabric在v2.0采用了新的链码（chaincode）生命周期管理，包含链码名称和版本号管理，同时，新引入了分布式的智能合约治理方式，对链码升级、背书策略更新等方面进行了优化和支持。但其在链码生命周期管理过程中暂不支持合约冻结/解冻，该功能在实际业务场景中是必要的，另外Fabric当前还不支持访问可信外部数据源，这限制了合约的部分可扩展性。
告别匿名性，拥抱“真实”的身份管理
在身份管理层面，标准要求：“相应主体应实现有效的用户身份管理，主要功能包括身份注册、身份核实、安全审计、账户管理凭证生命周期管理、身份鉴别、节点标识管理、身份更新和撤销、身份信息安全性管理等，并对身份进行监管审计。支持还原匿名标识中的用户真实身份以及相关交易信息，配合交易审查，加强KYC管理。”
在标准的细则中，可以发现当前身份管理主要矛盾在于当前大多数区块链没有将用户真实身份与区块链账户核实对应，随之引发用户身份注册、用户凭证生命周期管理、账户管理、身份鉴别等信息无法管理审计的问题，这源于区块链的特性之一：匿名性。
趣链区块链平台采用了一站式身份管理解决方案，配合飞洛BaaS平台采用用户身份先识别后上链的联合管理机制，可以很好地解决身份信息记录、管理、审计以及还原匿名标识中用户真实身份等问题，使链上身份可查可证，满足KYC要求。另外，平台内置的国密SM9算法，也能有效地满足“前端匿名，后端可控”的身份管理需求。
同样由于匿名性，Fabric对于身份管理信息如数字身份证明、用户职业居住地工作等无法获取，所以暂不支持部分身份管理规范标准，需要进行业务层面的二次改造。
混合式多层级隐私保护机制
在隐私保护层面，标准强调：“业务相关方应将隐私数据按照敏感度进行分级，并根据具体场景制定相关的隐私保护策略，以使系统的信息保密性和隐私保护程度与执行效率达到平衡，并在隐私数据的采集、存储、使用、流转过程中满足隐私保护技术要求，方便隐私数据的监管和审计。”
趣链区块链平台根据不同场景下业务相关方隐私保护问题，提出基于命名空间（namespace）的分区共识机制、可验证隐私交易的隐私保护机制、基于TEE的账本加密等特性。
- 分区共识机制通过分区策略和规则将不同的业务交易划分为不同分区粒度的子网络，实现了节点协同过程的优化和物理级的安全隔离。
- 隐私保护机制针对不同级别的敏感隐私数据需求，基于零知识证明、同态加密和环签名等技术，通过交易相关方动态指定策略实现了交易粒度层面的用户隐私权限控制。
- 基于TEE账本加密解决数据存储安全问题，用户可通过密码学算法如哈希校验等进行有效性和正确性验证，方便监管和审计。
在隐私保护层面，Fabric通过通道策略达到了访问隔离的目的，如果想在调用链码前对数据进行加密操作，需要自己提供密钥获取方式，这种形式虽然可以达到数据加密的要求，但相比之下，趣链区块链平台提供的一站式安全解决方案更为高效便捷。另外，关于隐私交易，Fabric在2.0版本中更新了原有的隐私保护策略，成员组织可选择与其直接网络的特定成员私下共享数据。除此之外，关于隐私交易的数据审计问题如细则中隐私数据的采集、流转、使用的相关审查策略，Fabric不能很好的满足，需要相应改造链码以及业务系统等。
“一键上报”式监管
在监管支撑层面，标准要求：“支持监管机构的接入，以满足信息审计和披露的要求，应支持监管机构访问最底层数据，实现穿透式监管。当系统或交易出现问题时，应能主动报警，采取适当纠正措施，并向监管机构、管理机构报送事件信息。
趣链区块链平台支持监管节点的接入，并支持消息订阅异常推送功能，在系统交易出现问题时主动上报并采取适当安全措施。另外针对监管主动干预交易等问题，平台提供了不同层级的权限管理体系，可以对系统级、节点级、合约交易级多层级进行不同粒度的干预权限和限制。
而在监管支撑方面，原生Fabric在系统和交易出现问题时，可以对问题进行定位和处理。但没有一套完善的上报纠错机制来满足监管需求。需要对原生的架构进行二次开发，存在一定的改造成本。
分布式、高安全的运维手段
在运维要求层面，标准要求：“节点的版本升级应支持向下兼容，应记录升级过程中相关操作日志，做到可审计、可追溯。应制定版本升级失败的应急预案，在升级失败的情况下启动应急预案进行回滚，在规定时间内恢复节点的可用性。
趣链区块链平台针对于节点升级问题，采用基于CAF联盟自治的系统升级方案，通过多中心化投票的方式对整个升级过程进行记录，以便于审计追溯。对于升级失败情况采用事前预防、事中处理、事后记录的预案策略，以应对一些升级失败等突发状况。针对系统的可用性，平台新增热备节点CVP（Candidate VP），实现动态替换失效的VP节点。
Fabric v1.X版本与v0.X版本不能够很好的兼容，不满足规范中对兼容性的要求。同时由于引入了Docker、Kafka、Zookeeper等第三方软件，对需要版本升级的业务系统提出了更高的运维需求。另外，Fabric在系统异常情况下进行数据恢复回滚操作时，节点必须是离线的，在回滚成功之后重启才可恢复正常，这大大降低了系统可用性。
写在最后
趣链区块链平台长期坚持合规、监管友好、支持企业级服务的良好理念，通过在金融领域的深耕积累，已经符合了相关规范要求，具备了金融分布式账本安全服务能力。而Hyperledger Fabric目前在硬件加密、身份管理、监管审计等功能上存在一定的缺失，导致其在金融行业的应用存在一定的局限性，如需在金融场景中使用，需要相应技术改造和适配以满足相关的标准规范，进而带来相关成本与研发周期的增加。
趣链区块链平台将继续结合新标准和实际应用场景，在业内发挥重要领跑力量，助力实现更好的分布协作，打造更好的金融形态、更好的信任社会。
参考文献：
[1] 中国人民银行.金融分布式账本技术安全规范.
http://www.cfstc.org/bzgk/gk/view/yulan.jsp?i_id=1855
|
|
转播
