LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 币圈百科 > 数字托管平台为何需要签名机?了解 RenrenBit 推出的可信签名机

数字托管平台为何需要签名机?了解 RenrenBit 推出的可信签名机

2020-05-15 RenrenBit 来源:链闻

签名机服务是数字托管平台重要的基础设施,RenrenBit 探索基于 Intel SGX 框架的可信签名机服务以提高平台安全等级。

原文标题:《RenrenBit 实现基于 Intel SGX 框架的可信签名机服务》
撰文:RRLab 研究院

根据 CoinMarketCap 显示,数字货币市值已达 2200 亿美元,持有数字货币用户规模达到千万级,数字资产正在成为一个越来越流行和重要性也越来越高的一项资产。与此同时,调查显示大部分用户选择将资产交由各种数字资产托管平台代为管理。相对于传统的金融托管平台,数字资产托管服务才刚刚起步,基础设施并不成熟,未来有很大的发展空间。签名机服务,就是其中最重要的基础设施之一,可以说得上是数字托管平台的安全核心。RenrenBit 旗下科研实验室 RRLab 发布最新科研成果,成功实现基于 Intel SGX 框架的可信签名机服务,大大提高了平台的资金安全等级。

传统数字托管平台现状

数字托管平台介绍

图 1-1 冷温热钱包架构示意图

数字资产托管平台为用户提供高效、易用和安全的资产托管服务,主要包括充值和提币服务。为了支持这些服务,其内部至少要有三种钱包,即冷钱包、温钱包、热钱包,如图 1-1 所示。平台为每个用户分配一个温钱包地址,用户充值时需要向温钱包地址充值,为了便于用户资产集中调度,用户温钱包的资产被归集到一个热钱包中,同时热钱包也用于用户提币。目前几乎所有平台架构中都是按照冷热分离的原则构建,当热钱包资产达到一定程度时转移部分到冷钱包,因为冷钱包比温钱包和热钱包更加安全,大部分资产会放置在冷钱包里,一般不会动用。小部分资产会放在温钱包和热钱包中,为用户提供高效的充值和提币服务。除了冷钱包是离线管理,其中温钱包和热钱包都必须在线工作,我们将其合称为云钱包服务。

平台架构 / 签名服务

图 1-2 一种传统的云钱包架构

一种传统的云钱包架构如图 1-2 所示,由于云钱包需要对接多条主流公链,为了便于快速开发,常见的云钱包架构往往负责与多个区块链主网进行交互,并且同时维护私钥的存储以及私钥签名功能。私钥管理服务未作单独拆分,云钱包需要实现私钥的存储和管理、用户充值提币服务以及内部资产归集服务。

私钥存储:为每个用户分配温钱包时,平台会生成对应的私钥,以及平台管理热钱包时也有对应的私钥。对于所有的温钱包和热钱包中的所涉及的私钥,对其进行统一管理,将其存储在数据库中。

充值服务:当用户充值时,资产托管平台为用户生成一个温钱包地址,并将其私钥存储在数据库中,用户需要向温钱包地址进行转账,平台检测温钱包地址收到转账时判定为用户充值。用户充值到账后,需要将资产归集到热钱包,使用温钱包对应的私钥签名一笔归集交易完成归集动作。

归集服务:将分散在各温钱包中的资产归集到同一个热钱包中,方便集中管理,在检查到用户充值后,使用温钱包发起交易,从数据库中读取温钱包对应的私钥,然后对交易完成签名,最后将交易发送到链上,将资产转账到热钱包,完成归集操作。

提币服务:根据用户提币的地址,使用热钱包发起一笔转账目标地址为用户指定的提币地址的提币交易,从数据库中读取热钱包对应的私钥对该交易进行签名,然后发送到链上,完成用户提币操作。

威胁模型分析

历年来,全世界的数字资产托管平台已经被黑客收割了快 30 亿美元了,各种资金安全事故层出不穷,令人不寒而栗。黑客攻击的手法多种多样,既有来自内部的、也有来自外部的,既有纯技术上的,也有通过人员实施的,特工间谍之类。

本节基于传统数字托管平台架构,我们开展系统威胁模型分析,在图 1-1 中标注了威胁模型。主要针对私钥在生命周期里各个阶段的安全性进行分析,假定攻击者的目标是「窃取明文私钥」。传统数字资产托管面临的威胁者有:

外部人员:泛指所有非法入侵者,包括黑客和作恶的云服务厂商等。内部人员:一般研发人员、运维人员和特权人员等,他们或能修改平台代码,或能登录服务器,或能访问数据库,或者掌握平台中的部分特殊秘密。

针对外部人员,面临的威胁有:

在图 1-1 中(a)处攻击者获取云服务器权限后,可以修改资产托管平台代码,从而导出明文私钥。在图 1-1 中(b)处攻击者不修改代码时,可以运行恶意程序,嗅探内存,在服务执行签名操作时,读取私钥;在图 1-1 中(c)处攻击者可以窃听通信的数据,监听私钥;在图 1-1 中(d)处攻击者和云服务厂商可以读取数据库内容,偷取私钥。

评估:以上只有(2)中在(b)处的威胁是可以通过 SSL 加密通信解决的,其它威胁均无法解决。不管是黑客还是对云服务厂商,只要他们进入服务器,托管平台就会陷入极端危险的境地。

针对内部人员,面临的威胁有:

研发人员增加恶意代码,输出私钥;运维人员访问数据库,读取私钥;运维人员登录服务器,篡改代码;运维人员登录服务器,执行恶意程序嗅探内存。特权人员登录服务器,重新部署服务,增加恶意模块,读取私钥。

评估:通常我们会采用一些开发和运维管理措施,比如严格代码 Review、管理分权等。这样可以稍微降低内部威胁,但是仍然离实现完美的资产托管安全远的很。

在 RenrenBit 内部流传一句话:我们并非不相信人,只是人都会犯错。在当前架构中无法很好的解决来自内部和外部的各种威胁,私钥的存储和使用始终存在一定的风险。接下来,本文会介绍可信计算技术,并说明 RenrenBit 是如何设计实现更加安全的资产托管平台系统架构,重点介绍可信签名服务。

可信计算技术

为了解决传统云钱包资产托管平台中存在的威胁,在 RRLab 科研团队的主导下,我们引入了可信计算框架 Intel SGX 技术保证私钥安全,为用户资产安全保驾护航。

Intel SGX 可信计算技术

Intel 于 2013 年在 HASP 会议连发三篇论文,提出了 SGX (Intel? Software Guard Extensions)框架,SGX 框架对机密信息提供硬件级防护,重点保护应用代码和数据的安全。SGX 作为一组处理器指令集的扩展,它允许应用程序实例化一个被硬件保护的安全区域 enclave。如图 2-1 所示,基于 SGX 的应用程序可以被划分为可信区域部分和不可信区域部分。可信区域 enclave 是应用程序地址空间中的一块被保护的区域,这块被保护的区域即使在特权恶意软件的存在下仍然能提供完整性和机密性。可信应用中不可信部分通过特定的接口访问可信区域 enclave 中对应的接口,不可信部分以及外部应用程序无法访问 enclave 的内存区域,即使是虚拟机监视器、BIOS 或者操作系统级的特权程序等都无法访问 enclave 的内存区域。

Intel SGX 框架有以下特点:

enclave 内存无法从可信区域外读写,无论进行读写的程序具有什么级别的权限 ;部署在硬件环境中的 enclave 无法通过软硬件调试器进行调试 ;enclave 环境不能通过传统函数调用或堆栈操作进入。要调用 enclave 中的函数,必须要通过 SGX 平台和指令进行验证 ;enclave 中内存采用具有回放保护功能的行业标准加密算法进行加密 ;内存加密密钥存储在 CPU 硬件中中且不可访问,并随着电源周期(例如系统启动或者从休眠状态恢复时)随机更改 ;enclave 中的隔离数据只能通过可信区域进行访问 ;Intel SGX 提供了远程认证能力,可以验证运行的可信程序代码是否被篡改。

图 2-1 基于 SGX 的可信应用程序示意图

Nuclear 可信计算开发架构

Intel SGX 只提供给开发者基础类库,为了实现云钱包资产托管私钥管理服务,RRLab 在 Intel SGX 可信环境的基础上开发了 Nuclear 可信安全框架,如图 2-2 所示。我们在 Intel SGX 的基础上构建了一系列开发类库,主要分为基础密码算法库和基础通用软件库。在基础密码算法库中,开发了 BIP32、BIP39 和 BIP44 协议的基础类库,同时也开发了 SECP256K1 与 ED25519 常用签名算法类库等,用于支持私钥的生成和签名;在基础通用软件库中,开发了 KMS SDK,序列化工具,存储工具,RPC 框架,网络工具等类库,实现了常用的基础软件库,构建了完整的区块链领域的可信计算开发生态。

图 2-2 Nuclear 可信计算开发框架示意图

RenrenBit 的可信签名服务

RenrenBit 云钱包基于 Intel SGX 的资产托管系统架构,架构中将资产托管系统和签名系统拆分,构建了基于 Intel SGX 的私钥管理服务,在可信区域 enclave 中生成和使用私钥,明文私钥始终保持在可信安全区 enclave 范围内,依托 SGX 内存保护机制保护私钥的安全。

在 Nuclear 的基础上,我们构建了可信签名服务,整体的云钱包资产托管系统架构简化示意图如图 2-3 所示,可信签名服务核心功能在可信区域 enclave 中完成。

图 2-3 RenrenBit 资产托管系统架构简化示意图

防代码篡改:资产托管系统与可信签名服务隔离部署,二者交互交互时,首先通过远程认证来验证可信签名服务代码是否被篡改。

抗内存嗅探:由于可信签名服务运行在 Intel SGX 可信区域之中,目前并无有效的方法对其实施内存嗅探攻击。

通信加密:从资产托管服务到可信签名服务 Enclave,这段通信链路经过 AES+RSA 双重加密,从密码学上保证每次签名参数信息不会发生泄露。

二次加密:生成钱包私钥时,首先在可信区域内使用预设定的密码(私钥)加密,然后使用硬件 KMS 进行二次加密,最后由托管系统存储在数据库中。

无状态服务:可信签名服务是无状态服务,本身不存储任何数据,利于横向扩展服务集群。资产托管业务系统需要使用私钥签名时,会提供待签名 Hash 及数据库中查询到的加密私钥。

定制管理策略:通过制定相对简单的安全策略,就能依托 Intel SGX 框架提升资产托管平台的安全性。

系统的具体运行流程

创建温钱包时生成私钥,温钱包的创建流程如图 2-4 所示:

托管系统向可信签名服务发起初始化请求;可信签名服务在 enclave 中生成私钥,并进行第一次加密;可信签名服务在 enclave 中,使用硬件 KMS 对加密私钥进行二次加密;硬件 KMS 返回加密后结果;可信签名服务通过安全信道返回温钱包公钥和加密私钥至托管系统;托管系统存储公钥和加密私钥至数据库。

图 2-4 创建温钱包流程

提币与归集时使用私钥签名的流程如图 2-5 所示:

托管系统向数据库查询查询温钱包公钥和二次加密私钥;数据库返回公钥和二次加密私钥;托管系统使用待签名 Hash 和二次加密私钥请求可信签名服务签名;可信签名服务 enclave 中调用 KMS 解密加密私钥;硬件 KMS 服务返回解密后私钥;可信签名服务 enclave 中二次解密 KMS 服务返回的解密私钥;可信签名服务 enclave 中使用私钥对待签名 Hash 进行签名;可信签名服务通过安全信道返回签名结果;托管系统把交易数据和签名打包上链。

图 2-5 使用加密私钥签名流程

安全性分析

在图 2-3 中同时也标注了威胁模型,假设攻击者的目的是窃取明文私钥。获取明文私钥首先需要获取二次加密的密文私钥,然后通过硬件 KMS 解密,然后通过可信签名服务中私钥再次解密。图 2-3 中标注了 5 处攻击方式,接下来进行分析。

防御外部攻击

(1)在(a)处,攻击者入侵了可信签名服务器,由于可信环境为二进制部署,攻击者无法直接修改代码改变服务逻辑窃取私钥;如果攻击者部署一个含恶意程序的可信签名服务,用来替代原有的可信签名,然而托管系统在调用签名服务时,通过远程认证发现可信签名服务被篡改,停止下一步调用交互,防止加密私钥泄露;由于私钥始终保持在 enclave 中,攻击者无法通过内存嗅探的方式窃取 enclave 内存中私钥。

(2)在(b)处,由于调用内容经过 AES+RSA 双重加密,攻击者无法从信道中获取加密私钥。

(3)在(c)处,攻击者(云服务厂商)即使获取了 KMS 解密后私钥,但该私钥仍然经过加密,无法获取明文私钥。

(4)在(d)处,攻击者即使获取数据库中二次加密私钥,仍然无法经过二次解密获取明文私钥。
通过分析可知,攻击者始终无法获取明文私钥。即使获取加密私钥以及 KMS 解密权限,仍然无法进行二次解密。可信签名服务可以实现保护明文私钥的目的。

防御内部攻击

(1) SGX 软件必须签署发版,签署的权利在特权人员手中。每次发布新版本时,可信签名服务代码不仅需要技术团队 Review,还需要安全团队审计后编译成二进制程序后,最后必须由特权人员签署,并由安全负责人部署和运维。

(2)抗代码篡改。由于 Intel SGX 的特性,一旦部署完成后,无法篡改代码,因为篡改代码会导致软件 ID 变更,通过远程认证会迅速发现攻击行为。因此,不管是开发人员还是运维人员都无法篡改软件。

(3)私钥加密存储。不管是运维人员还是开发人员,从数据库只能获取加密私钥,无法作恶。

(4)特权人员除了签署 SGX 软件,不参与其它管理流程,也就无法作恶。
总之,在引入了 Intel SGX 技术之后,数字资产才彻底摆脱了单点安全问题的困扰,同时也提升了破解平台中多点安全的难度。

总结

随着加密货币的价值增长,黑客事件层出不穷,保障用户的资产安全成为数字资产托管平台的行业痛点。RRLab 引入的可信计算框架 Intel SGX 技术,实现了可信签名机服务,大大提高了数字资产托管平台的安全性。

可信签名服务只是 RRLab 的第一步,后续我们将拓展可信计算架构应用,让可信在托管平台架构中承担更多也更重要的角色。同时,我们也正在构建 MPC 计算服务。我们始终坚持安全高于一切,所有的努力保障 RenrenBit 的用户资产安全。

参考

[1] Intel SGX Explained

[2] Intel? 64 and IA-32 Architectures Software Developer’s Manual Volume 3D: System Programming Guide, Part 4

[3] Intel? Software Guard Extensions SDK for Linux* OS

[4] Intel? Software Guard Extensions Programming Reference

[5] Intel? Software Guard Extensions: EPID Provisioning and Attestation Services

—-

编译者/作者:RenrenBit

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...