基于TrustZone的以太坊密钥保护方法

A TrustZone-Based Key Protection Scheme for Ethereum Blockchain

摘要

在以太坊中，用户数字资产的安全性与其私钥紧密相关，一旦私钥泄漏，用户将面临无法挽回的数字资产损失。加密货币钱包常被用于管理和保护区块链系统的密钥。但是，现有的加密货币钱包安全性不高。为了更好地保护以太坊用户的数字资产，在不影响以太坊系统正常功能的情况下，提出了一种基于TrustZone的以太坊密钥保护方法，以在用户通过支持TrustZone的移动终端接入和使用以太坊系统时，提高用户密钥在生成、存储和使用过程中的安全性。在该方法中，与私钥相关的操作都是在TrustZone的安全世界中进行的。私钥未被使用时，将以安全文件的形式被保存在本地文件系统中。当有交易需要被签名时，将存有对应私钥的安全文件加载到安全世界中，并恢复出私钥以对交易签名，从而使得私钥可以安全而持续地被使用。在模拟环境下实现了该方法的原型系统，并对系统的功能和性能进行了验证和测试。实验结果表明，本文的原型系统在以太坊系统中能够正常运行，性能开销在合理范围内，具有可行性。

Abstract

The security of Ethereum digital assets mainly depends on users’ private keys. If a user’s private key is leaked, thier digital assets are irretrievably lost. Cryptocurrency wallets typically provide key management and protection for blockchain systems. However, the security of most existing cryptocurrency wallets is poor. To provide better protection for users’ digital assets, we propose a TrustZone-based key protection scheme for the Ethereum blockchain, which can significantly enhance the security of the generation, storage, and usage of Ethereum keys without disrupting the standard functionalities of Ethereum when users access and use the Ethereum system through mobile terminals that support TrustZone. Mainly, operations related to private keys are enforced in the secure world of the TrustZone. Private keys that are not in service are stored in the local filesystem as secure files. The corresponding secure file is loaded into the secure world to recover the private key only when a transaction needs to be signed, ensuring that private keys can be used securely and continuously. We implemented the prototype system in a simulation environment and verified its functionality and performance. The experimental results show that the developed prototype system can work normally in Ethereum with a reasonable performance overhead, validating the feasibility of the proposed scheme.

Graphical abstract

0　 引 言

作为一种典型的区块链系统，以太坊也具有比特币系统的不可篡改、去中心化等特点^[1]。由于采用了新的共识算法，并支持能够应用于多个领域的智能合约^[2-4]，以太坊在交易速度上比比特币系统要高很多，应用场景也更多样化。

此外，不同于比特币的未花费交易(Unspent Transaction Output, UTXO)模型，以太坊是通过账户来实现交易操作的。在以太坊中，有两种账户类型，即外部账户和合约账户。外部账户是普通用户通过私钥管理的账户，用户可以通过外部账户转账，或者创建、部署智能合约。合约账户其实就是智能合约中的地址，但合约账户没有私钥，合约账户只能在外部账户调用智能合约时被激活。账户的状态就是以太坊的状态，以太坊状态的改变都是由外部账户发起的交易所引起的，用户密钥则是外部账户的基础。

因此，密钥的管理与保护（包括密钥生成、存储和使用）在以太坊的运行过程中起着关键作用，被认为是包括以太坊在内的分布式账本应用的十大障碍之一^[5]。如果攻击者能够通过某种方式（如注入攻击、重放攻击等^[6]）获得用户的私钥，攻击者就能够对用户的以太坊资产进行任意操作，给用户造成不可逆转的经济损失^[7]。例如，Base生态项目RocketSwap的服务器遭到攻击，存放在服务器上的私钥被盗取，使得合约中的资产被转移至攻击者的账户中，最终导致了86.8万美元的损失^[8]。因此，必须安全妥善地保护以太坊中的用户私钥。

在包括以太坊在内的数字货币系统中，人们一般通过加密货币钱包来管理和保护其密钥。现有的加密货币钱包大体上可以分成两类，即软件钱包^[9-10]和硬件钱包^[11-12]。软件钱包可被认为是区块链系统上的一种应用，用户可以通过软件钱包提供的接口与底层的区块链系统进行交互以实现对其数字资产的管理。软件钱包因操作方便，成为使用得较多的数字货币钱包，但其在使用过程中，用户私钥通常是由用户口令来保护的，而且用口令加密/解密私钥、用私钥对交易签名等操作通常是在普通执行环境（Rich Execution Environment, REE）中进行的，容易受到不可信的操作系统及其他恶意软件的攻击，安全性较差。硬件钱包通常通过一个额外的专用加密设备（如一个USB设备或蓝牙设备）生成和存储密钥，并在该设备中用私钥对交易签名。硬件钱包的操作过程对用户是透明的，无须用户的介入。总体上来讲，硬件钱包的安全性比软件钱包高，但硬件钱包也面临着一些安全威胁，如在使用时容易受到中间人攻击^[13]，导致用户的数字资产被转移到欺诈地址上。而且，硬件钱包相对于用户的设备来说是额外添加的，用户必须妥善保管它，避免因遗失而造成资产损失。此外，受体积或容量的限制，硬件钱包的处理能力往往是有限的，无法很好地扩展和兼容更多的平台。因此，现有的以太坊密钥保护方案在安全性、平台适用性、可扩展性等方面仍有待提升。

基于此，本文提出了一种基于TrustZone的以太坊密钥保护方法，以在用户通过支持TrustZone的移动终端接入和使用以太坊系统时，在不影响以太坊系统正常功能的情况下，提高用户密钥在生成、存储和使用过程中的安全性。本文对以太坊的交易流程进行了分解，将与用户私钥相关的操作放在TrustZone的安全世界(Secure World, SW)中进行，并根据TrustZone的编程规范重新实现了这些操作。首先在SW中生成用户的公私钥。当私钥未被使用时，先在SW中将其写入到安全文件中，再将安全文件存储在本地文件系统中，从而使得私钥可以被安全存储和持续使用。当有交易要被签名时，先将交易信息和存有对应私钥的安全文件加载到SW中，再在SW中恢复出私钥，并用私钥对交易签名。签名后的交易信息将被提交至以太坊交易池中等待验证。本文的贡献如下：

1） 利用TrustZone的安全特性实现了对以太坊密钥的保护。将与用户私钥相关的操作，如用户公私钥生成、将私钥写入安全文件、从安全文件读取私钥、用私钥对以太坊交易签名等，都放在SW中进行，既能保证私钥的安全存储，也能为私钥的使用提供运行时保护。

2） 在模拟环境中实现了本文方法的原型系统，并对原型系统的功能进行了验证。结果表明，本文方法是可行的，能够正常完成以太坊交易，即基于该方法签名的交易能被以太坊验证和接受。

1　 预备知识

1.1　TrustZone与OP-TEE

TrustZone^[14-16]技术是由ARM公司设计的一种硬件体系结构，被广泛应用于移动终端上。TrustZone包含两个域，即安全世界SW和普通世界（Normal World, NW）。SW也被称为可信执行环境（Trusted Execution Environment, TEE），可为敏感任务的执行提供安全的环境。NW也被称为REE，普通的操作都是在NW中进行的。SW与NW是物理隔离的，各自独立拥有寄存器、物理内存及外设等资源。在某一时刻，只有一个世界被允许运行，运行的世界将独占处理器资源。SW与NW之间的切换由名为“安全监视器”（Secure Monitor）的组件控制。运行在SW和NW中的应用程序分别被称为可信应用（Trust Application, TA）和客户端程序（Client Application, CA）。SW/TA能够访问NW中的资源，但是，SW/TA中的代码和资源受到访问控制策略的严格保护，不能被NW任意访问。这样的设计使得敏感操作和数据在SW中被执行和处理时，不会受到来自NW中的软件攻击，为代码和数据提供了高安全性保障。

OP-TEE(Open Portable TEE)^[17]是一款基于TrustZone技术的操作系统，符合Global Platform（GP）规范发布的TEE标准，支持QEMU平台，提供了完整的开发工具包编译TA与CA。基于OP-TEE的开发环境，用户可以构建和开发自定义的TA。其中，TA的唯一标识符（Universal Unique Identifier, UUID）是CA与TA连接的关键信息，特定的UUID对应着特定的TA^[18]。

在OP-TEE中运行CA与TA时，其操作流程为：CA先向SW发送请求连接信息，SW验证连接信息的合法性后，接受该请求，CA即与SW建立起连接。之后，CA将想要调用的TA的UUID与会话信息发至SW，就可以与被调用的TA建立起会话，并可以向TA发送操作命令及需要处理的数据。TA收到命令后，即可执行预定义的操作，对CA传入的数据进行处理，并将执行结果返回给CA。CA继续执行程序以完成后续的操作。

1.2　安全存储与安全文件

OP-TEE提供了安全存储功能，使得敏感数据以安全文件（Secure File, SF）的形式保存在本地文件系统中。安全文件是由TA创建的，被保存在NW的文件系统中^[19-20]。但是，对于NW而言，安全文件是加密文件，即在NW中打开一个安全文件时，看到的内容都是密文。将数据写入安全文件以及从安全文件读取数据的操作只能由TA来执行，并且每个安全文件都有一个唯一的文件标识符，TA通过文件标识符来操作对应的安全文件。

在TA中用安全文件保护数据的流程为：首先，TA用对称加密算法加密数据，所用的密钥是一个随机选取的对称密钥，被称为文件加密密钥(File Encryption Key, FEK)。加密后的数据被TA写入安全文件中。之后，FEK被可信应用存储密钥(Trusted Applicant Storage Key, TSK)加密，加密后的FEK被写入头部文件中。TSK是由基于物理设备的且唯一的安全存储密钥(Secure Storage Key, SSK)与该TA的UUID实时计算的，不会存储在本地，以为FEK和安全文件中的数据提供保护。本文利用安全文件存储以太坊用户私钥，以实现用户私钥的安全存储和可持续使用。

1.3　Web3.js

Web3.js是一个提供了以太坊操作接口的JavaScript库，由以太坊基金会开发和维护。Web3.js允许用户使用HTTP、IPC或WebSocket与本地或远程的以太坊节点交互，从而实现以太币的转账、创建智能合约、从智能合约中读写数据等操作。

本文通过Web3.js提供的函数接口，创建初始化的以太坊交易，将初始化的以太坊交易发送给TrustZone，并将TrustZone返回的签名后的交易信息广播到以太坊网络中，从而实现了基于TrustZone的以太坊交易流程。

1.4　MbedTLS

MbedTLS库是由ARM公司用C语言实现的开源SSL/TLS算法库，以方便软件开发人员在移动终端等环境中使用SSL/TLS功能及各种加密算法。

本文将MbedTLS库集成到了TrustZone开发环境中，通过MbedTLS库提供的接口实现了本文所需的与用户密钥相关的操作，包括密钥生成算法和以太坊交易签名算法。

2　 方案设计

本文将以太坊交易流程分解为密钥生成、交易签名、交易提交三个子流程，在此基础上，利用TrustZone的安全特性实现了以太坊密钥的安全存储和运行时保护，其系统架构如图1所示。

本文方案的设计原则是将与私钥相关的操作都放在SW的TA中进行，与本地文件系统和网络的交互等操作则被放在NW中进行。与私钥相关的操作包括生成公私钥、创建安全文件并将私钥写入安全文件、从安全文件中恢复出私钥、用私钥对以太坊交易信息签名。NW中的应用又分为两个部分：CA和Web端程序（Web App, WA）。CA接受用户的输入，与TA建立会话，向TA传送操作命令及数据，接收TA返回的执行结果，与本地文件系统交互。WA负责计算用户的账户地址、将用户输入的部分交易信息初始化到交易信息结构体中、计算待签名信息的哈希值及地址恢复标识符V、处理交易信息以及与以太坊网络的交互等。

需要指出的是，一般情况下，TA只能与CA交互，不能直接与本地文件系统及WA交互，即TA只接收CA输入的命令和数据，并将结果返回给CA。但是，当操作安全文件时，TA可以直接与本地文件系统交互，即TA可以直接将安全文件存入本地文件系统或从本地文件系统中读取安全文件。CA与WA虽然都是NW中的应用，但是它们之间不直接交互，而是通过本地文件系统间接交互，例如，CA将用户公钥写入到本地文件系统中，WA再从本地文件系统读取公钥，用公钥计算用户的账户地址，再将账户地址写入到本地文件系统中。对于交易信息也是如此，WA将待签名的交易信息写入到本地文件系统中，CA从本地文件系统中读取交易信息，再将其传给TA。TA将签名后的交易信息返回给CA，CA将其写入到本地文件系统中，WA再从本地文件系统中获取签名后的交易信息，并对其进行后续的处理。为了使描述简洁，在后文中，TA、CA及WA之间将被描述得可以直接交互，以省略它们之间的交互细节，例如，“TA将执行结果返回给CA，CA将结果写入本地文系统件，WA再从本地文件系统读取结果”将被简化为“TA将执行结果返回给WA”。

2.1　密钥生成

密钥生成子流程首先根据以太坊的规定，在TA中生成用户的公私钥，并将私钥写入安全文件后存储在本地文件系统中，以便后续流程能够安全、持续地使用私钥。根据公钥计算账户地址也是在此阶段进行的，但由于用户公钥不是敏感数据，所以本文将生成账户地址的操作放在WA中进行。

根据以太坊黄皮书^[21]的描述，以太坊是用可恢复的椭圆曲线数字签名算法(Elliptic Curve Digital Signature Algorithm, ECDSA)^[22]对交易进行签名的，其具体使用的椭圆曲线参数为secp256k1^[23]。采用secp256k1的椭圆曲线可以表示为y²=x³+7(mod p)，其中，p是一个素数。将该椭圆曲线上的一个特定基点表示为G，其横坐标、纵坐标和阶数分别用G_x，G_y 和n来表示，p和n都是接近2²⁵⁶的大整数。上述各参数的具体值见表1。

在基于ECDSA-secp256k1的以太坊交易签名算法^[24]中，私钥sk是一个大小为32字节且不大于n的正整数，公钥pk是由私钥与基点G进行点乘而得到的，账户地址Address被定义为公钥在keccak256算法^[25]下的哈希值的后20字节。keccak256是以太坊中所特有的哈希函数，由于具有特殊的海绵结构，keccak256在提供一般哈希特性的同时，还能够抵抗侧信道攻击。

基于上述分析，本文根据TrustZone的编程规范，在CA和TA中分别定义了密钥生成方法CA_KeyGen_ETH()和TA_KeyGen_ETH()，以在TA中为用户生成符合以太坊规范的公私钥。其中，CA_KeyGen_ETH()方法首先在CA与TA之间建立连接，然后将生成密钥命令与一个文件标识符发送给TA，并接收TA_KeyGen_ETH()方法返回的公钥pk，再将pk保存在本地文件系统中。由于CA_KeyGen_ETH()属于常规操作，在此不再描述其详细定义。TA_KeyGen_ETH()的详细定义如方法1所示。

基于上述TA_KeyGen_ETH()方法，本文在TrustZone中生成以太坊密钥的过程如图2所示，其具体过程如下：

1) CA以UUID为参数通过CA_KeyGen_ETH()方法连接对应的TA。

2) CA_KeyGen_ETH()方法将生成密钥命令及一个文件标识符object_id发送给TA，以调用TA中的TA_KeyGen_ETH()方法。

3) TA执行TA_KeyGen_ETH()方法，将执行结果pk返回给CA_KeyGen_ETH()方法，并将SF_sk存储在本地文件系统中。

4) CA将pk传给WA。

5) WA通过pk计算Address，其具体过程为：计算pk在keccak256算法下的哈希值，在该哈希值的后20个字节前加上前缀“0x”，得到一个长度为21字节的字符串，该字符串即为Address。

6) WA将pk和Address保存在本地文件系统中。

2.2　交易签名

交易签名子流程主要完成以太坊交易信息的初始化以及用私钥对初始化后的交易签名。其中，交易信息初始化是指将交易的参数信息以及用户输入的交易信息填充到以太坊规定的数据结构体中。用私钥对交易信息签名包括了两个阶段^[26]：对账户地址Address的签名和对交易信息的签名，即首先用私钥sk对Address签名，并将该签名结果更新到初始化后的交易信息中；接着再用sk对更新后的交易信息进行第二次签名，得到最终的签名结果。在上述签名过程中，先对账户地址签名是为了确保当前待签名的交易确实是由该地址的合法拥有者发起的，也即确保只有该地址的私钥持有者才能够发起基于该地址的交易，从而防止地址伪造或未经授权的交易。

2.2.1　交易信息的初始化

根据以太坊黄皮书的规定，以太坊交易信息的数据结构体如图3所示，主要包括以下信息：当前交易编号Nonce、用户愿意为每单位的Gas支付的单价gasPrice、用户指定的该交易可以消耗的最大Gas数量gasLimit、交易金额value、用户发起交易时附带的想要传输的数据data、目的地址to、交易签名结果的前32字节R、交易签名结果的后32字节S、地址恢复标识符V、链参数chainId。

在初始化上述以太坊交易数据结构体时，gasPrice、gasLimit、value、data、to是由用户输入的，R、S、V则被初始化为空。因此，在初始化以太坊交易时，只需要填充正确的Nonce和chainId即可。为此，本文调用了Web3.js中的web3.eth.getTransactionCount()方法获取Nonce的值，该方法能够通过给定的地址返回该地址已经发出的交易数量。需要注意的是，在读取Nonce值时要确保以太坊交易池中的交易都已经被以太坊确认。同样地，本文调用了Web3.js中的web3.eth.net.getId()方法获取chainId的值，该方法能够返回连接网络的链ID。对上述数据结构体的各项值进行初始化填充后，就生成了初始化的以太坊交易信息InitTx。

2.2.2　交易签名

根据以太坊黄皮书的规定，ECDSA-secp256k1算法在生成签名时是将待签名消息的keccak256哈希值作为输入，生成长度为65字节的签名结果。该签名结果可被表示为3个部分，即前32字节为R，随后的32字节为S，最后一个字节为recid（recover id），在以太坊中用V表示，其值只能是0或1。但是，从EIP-155标准^[27]开始，V的值改由（1）式来计算。将chainId引入到V的计算中，是为了防止跨链重放攻击。

V=\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{d}+\mathrm{c}\mathrm{h}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{I}\mathrm{d}\times \mathrm{2}+\mathrm{35}（1）

本文所使用的MbedTLS库中的mbedtls_ecdsa_sign()方法在用私钥对交易信息签名时，只能计算得到R和S，不能计算出V。因此，需要特别指出的是，本文中的所有签名结果均是指R和S，没有包含V。而且，在生成签名时，S有时会出现在椭圆曲线的另一侧，不是所需的值。为此，在生成签名后还需要对签名结果进行判断，以确保所生成的S值满足以太坊所规定的条件，即S<n/2，n的值见表1。

从（1）式可知，V的计算不涉及到私钥，所以本文将其放在了WA中计算。而且，recid可以取两个值，这就导致可以算出两个V。为了得到所需要的V，本文先将recid置为0，并计算出此时的V，再根据R、S和V恢复出一个临时公钥，将该临时公钥与本地存储的公钥相比较，若它们相同，则该V即是所需要的；若它们不相同，本文就将recid置为1，并计算出此时的V，该情况下的V即是所需要的。

基于上述分析，本文根据TrustZone的编程规范，在CA和TA中分别定义了CA_Sign_ETH()方法和TA_Sign_ETH()方法，以在TA中对以太坊交易信息签名。其中，CA_Sign_ETH()方法首先在CA与TA之间建立连接，然后向TA发送签名命令、待签名的信息和安全文件的文件标识符，并接收TA_Sign_ETH()方法返回的签名结果，最后将签名结果保存在本地文件系统中。由于CA_Sign_ETH()属于常规操作，在此不再描述其详细定义。TA_Sign_ETH()的详细定义如方法2所示。

基于上述TA_Sign_ETH()方法，本文在TrustZone中对以太坊交易信息签名的过程如图4所示，其具体过程如下：

1) WA生成初始化的交易信息InitTx，从文件系统中获取账户地址Address，计算Address在keccak256算法下的哈希值hash(Address)，将hash(Address)传给CA。

2) CA以UUID为参数通过CA_Sign_ETH()方法连接对应的TA。

3) CA_Sign_ETH()方法将交易签名命令、hash(Address)和安全文件的标识符object_id发送给TA，以调用TA中的TA_Sign_ETH()方法。

4) TA执行TA_Sign_ETH()方法，将执行结果Sig(Address)=(R₁,S₁)返回给CA_Sign_ETH()方法。

5) CA将Sig(Address)传给WA。

6) WA将recid₁置为0，并根据（1）式计算V₁，然后以hash(Address)、Sig(Address)和V₁为输入，调用Web3.js库的util.ecrecover()方法，生成一个临时公钥pk'，并比较pk'与本地存储的pk是否相同。若它们相同，则保留该V₁；若pk'与pk不相同，WA就将recid₁置为1，并根据（1）式计算V₁，保留此时的V₁。之后，WA将(R₁,S₁,V₁)更新到InitTx中，计算InitTx在keccak256算法下的哈希值hash(InitTx)，将hash(InitTx)传递给CA。

7) CA以UUID为参数通过CA_Sign_ETH()方法连接对应的TA。

8) CA_Sign_ETH()方法将交易签名命令、hash(InitTx)和安全文件的标识符object_id发送给TA，以调用TA中的TA_Sign_ETH()方法。

9) TA执行TA_Sign_ETH()方法，将执行结果Sig(InitTx)=(R₂, S₂)返回给CA_Sign_ETH()方法。

10) CA将Sig(InitTx)传给WA。

11) WA计算出V₂值。(R₂, S₂, V₂)即为最终的签名结果。

2.3　交易提交

在交易提交子流程中，WA将TA返回的签名结果填充到以太坊交易数据结构体中，并对交易数据结构体进行序列化，最后将序列化后的交易提交到以太坊交易池中，其具体过程为：

1) WA将交易签名结果(R₂,S₂,V₂)填充到如图3所示的交易数据结构体中。

2) WA调用Web3.js库的Tx.serialize()方法序列化填充后的交易数据结构体，得到序列化后的交易信息serializedTx。Tx.serialize()方法实现了以太坊所要求的递归长度前缀编码(Recursive Length Prefix, RLP)，以将结构体数据编码成二进制字节数组，并能通过反序列化操作恢复出原来的数据。

3) WA以serializedTx为输入，调用Web3.js库的web3.eth.sendSignedTransaction()方法将交易信息广播到以太坊网络，等待以太坊的确认。

3　 原型系统实现及评估

3.1　软硬件环境

本文在QEMU模拟环境下实现了方案的原型系统，其软硬件环境为：Intel Core i7-11700 CPU @ 2.50 GHz处理器，8 GB内存，语言和JavaScript作为编程语言。WA操作系统为Linux Ubuntu 20.04LTS，CA和TA的操作系统是3.19版本的OP-TEE，QEMU的版本为7.0.0，MbedTLS库的版本为2.0，geth平台版本为1.10.15-stable。

OP-TEE提供了安全存储功能接口，但并不包含本文方案需要的secp256k1域参数以及keccak256算法。MbedTLS库提供了本文所需相关算法的接口并能适用于OP-TEE中，本文使用MbedTLS库提供的接口来实现与secp256k1相关的操作，包括生成用户公私钥和用私钥对交易信息签名。通过geth平台搭建以太坊网络，利用geth提供的指令配置以太坊私有链，并将其用于原型系统的功能验证和性能测试。采用Web3.js库提供的接口以实现与以太坊交易相关的操作，包括初始化交易信息、根据签名结果恢复出公钥、序列化以太坊交易数据结构体、向以太坊交易池提交交易。

3.2　功能测试

图5从开发者的角度展示了本文原型系统的部分核心功能，包括TA的第一次签名、第二次签名，以及WA将序列化的交易信息提交至以太坊交易池并被以太坊所确认。为了安全性，TA一般只运行相关操作，不直接将运行结果显示给用户，用户可以在CA的界面中查看运行结果。因此，本文将执行结果都显示在CA端的界面上。

1) 在第一次签名中，TA对WA/CA传来的账户地址的keccak256哈希值(见图5(a)中的标号②)签名，将签名结果(见图5(b)中的标号①)传回给CA/WA。WA先计算一个V和一个临时公钥，并与本地存储的公钥进行比对，根据比较结果确定V的值(见图5(a)中的标号③)。

2) 在第二次签名中，WA先将第一次签名的结果填充到交易数据结构体中，再计算交易信息的keccak256哈希值(见图5(a)中的标号④)，并将该哈希值传给CA/TA。TA对交易信息的keccak256哈希值签名，将签名结果(见图5(b)中的标号②)传回给CA/WA。WA先计算一个V和另一个临时公钥，并与本地存储的公钥进行比对，根据比较结果确定V的值(见图5(a)中的标号⑤)。

3) WA先将第二次签名的结果填充到交易数据结构体中，再序列化该交易数据结构体，最后将序列化的结果广播到以太坊网络。图5(c)中的标号①显示了交易在成功提交到以太坊交易池后，geth平台显示的界面。其中，hash是本次交易的哈希值，from是发起方的地址(可以看到是与图5(a)中的标号①是一致的)，Nonce是本次交易的编号，recipient是接收方的地址，value是本次交易的以太币数量。

从图5可以看到，基于本文方法的以太坊交易是可以成功提交到以太坊交易池的。这说明将以太坊交易过程中与私钥相关的操作放在TrustZone的SW中进行是可行的，能够在不影响以太坊正常交易功能的同时，利用TrustZone的安全特性提高以太坊用户密钥在生成、存储和使用过程中的安全性。

3.3　性能评估与分析

在上述原型系统的基础上，对本文方案的时间开销进行了测试，主要包括公私钥生成、交易签名以及交易提交的时间，并与原始以太坊系统和文献[26]的性能进行了对比。所有测试结果都是2 000轮重复操作的平均值。为了方便描述，将原始以太坊、文献[26]的方案、本文方案分别简称为ETH、HSM-ETH、TZ-ETH。

表2展示了不同方案在各个阶段的时间开销。由于ETH没有提供生成用户密钥的接口，而是直接生成用户账户的，因此，没有测试其密钥生成时间。此外，由于ETH将交易签名和交易提交封装为一个接口，故而没有单独测试其交易签名和交易提交的时间，而是直接测试其交易签名和交易提交的总时间。

从表2可以看出，与ETH和HSM-ETH相比，本文方案的时间开销较大，原因有两点：1） 本文的原型系统是在软件模拟环境下实现的，没有直接在硬件设备上测试其性能。一般而言，基于软件的应用在性能开销上比基于硬件的应用要大。因此，若将本文方案应用于在硬件上支持TrustZone的移动设备中时，其性能将有较大的提升空间。2） 为了保证私钥的安全存储和可持续使用，以及给私钥安全性更高的运行时保护，本文方案将与私钥相关的操作都放在SW的TA中执行，而TA又只能与CA进行交互，这就导致本文方案在实现流程上，比ETH和HSM-ETH都要复杂一些。具体而言，就是TA在生成密钥及对交易签名时，需要与NW中的CA和文件系统交互以获得输入和传出结果，CA与WA之间也是通过文件系统来传递中间结果。这些操作都会增加方案的性能开销。但是，从数量级上看，本文方案的性能开销在20 ms级别，在可接受的范围内。

为更详细地分析方案的性能开销，本文还测试了将私钥（256 bits）写入安全文件和从安全文件读取私钥的时间，以及公钥(512 bits)与签名结果(256 bits×2)在NW与SW之间交互的时间，其结果如表3所示。

从表3可以看出，在密钥生成过程中，将大小为512 bits的公钥传给CA和将大小为256 bits的私钥写入安全文件所用的时间在密钥生成过程中的占比为50.9%。当对交易签名时，从安全文件读取私钥和将大小分别为256 bits的R与S传给CA所用的时间在签名过程中的占比为27.6%。从实验结果可以看到，本文方案的性能开销有较大部分都是由各操作之间的交互导致的，这与本文前面的理论分析是一致的。这些操作之间的交互是由TrustZone本身决定的，是必不可少的，是实现本文方案所必需的开销。

4　 相关工作

TEE在区块链中的应用。TEE常被用于保护区块链系统及其应用的安全与隐私，如文献[28]为了保护存储在区块链上的智能合约，在基于TrustZone的TEE中构建智能合约，以为智能合约提供安全的运行环境。针对链外支付通道需要各方在短时间内访问区块链、而恶意节点又故意延迟访问以窃取资金的问题，文献[29]引入了受TEE保护的资金库，在各方之间建立离线交易通道，实现了高效、可靠的链外交易。Ekiden^[30]利用区块链和TEE两者互补的特性将智能合约的执行过程和共识过程分隔开，既能提高系统的性能，也能保护合约的隐私，还具有较高的扩展性。针对Ekiden只适用于小型智能合约的问题，文献[31]提出了CONFIDE，以为更复杂、更庞大的金融级别的智能合约提供保护，其数据加密协议和基于TEE的合约引擎保证了数据在整个生命周期内的机密性，基于TEE的虚拟机则为智能合约的高效执行提供了保障，使得系统的吞吐量较高。

区块链的密钥管理与保护。用户在区块链上的数字资产的安全性与其密钥紧密相关。为了抵御可能存在的攻击，研究人员提出了各种区块链上的密钥管理与保护方案，包括用第三方托管密钥^[9]、口令派生密钥^[32]、离线存储密钥^[33，34]、分层确定性钱包^[35]等。本文从保护对象、密钥生成保护、签名保护、密钥安全存储、运行环境和整体安全性等方面，将本文方案和几种具有代表性的区块链密钥保护方案进行了对比分析，如表4所示。

文献[26]基于硬件安全模块(Hardware Security Module, HSM)构建了以太坊钱包，其中，HSM负责生成密钥、存储密钥以及对交易签名，这些操作都是在受保护的内存进行中，能够在一定程度上保证密钥的安全，使其免受外部恶意程序的攻击。

文献[33]和文献[34]都利用了TrustZone技术来形成比特币冷钱包。它们都是在SW中执行与密钥相关的操作，以为密钥提供运行时保护，从而提高比特币钱包的安全性。但它们保护的对象都是比特币的密钥，其方案无法直接应用于以太坊密钥的保护。

文献[11]使用了智能卡构建硬件钱包，该方案基于Diffie-Hellman密钥交换协议的密钥加密方案，实现了私钥的安全备份和恢复。该方案的重点是保护密钥在生成过程的安全性，密钥在使用过程的安全性没有被考虑。文献[12]为解决当前硬件钱包缺少软硬件检查措施而存在钱包信息被修改或泄露的问题，在原始钱包中加入了基于协作密钥的交互式身份验证，从而确保钱包在使用时的完整性。但该方案没有考虑密钥在使用过程中的安全性。文献[36]提出了一种区块链密钥协议，该协议以会话密钥取代常规的存储在钱包中的密钥，能够防止钱包信息被盗。由于涉及多方交互，方案的通信成本较高。文献[11-12，36]均是在普通执行环境REE下实现的，其安全性均有待提高；而且，它们保护的对象也都是比特币的密钥，其方案无法直接应用于以太坊密钥的保护。

本文方案利用TrustZone技术来保护应用场景更为广泛的以太坊系统的密钥，并且同时考虑了以太坊密钥的安全存储和运行时保护。具体而言，本文将公私钥的生成、用私钥对交易签名等与私钥相关的操作都放在TrustZone的SW中进行。而且，当未被使用时，私钥是以安全文件的形式被保存在本地文件系统中的；当需要使用私钥时，本文再将安全文件加载到SW中，以确保私钥能够被持续使用。总体而言，针对用户通过支持TrustZone的移动终端接入和使用以太坊系统的场景，本文方案能够在密钥生成、存储和使用过程中，为密钥提供更强的安全保护。

5　 结 语

为了更好地保护以太坊用户的数字资产，本文提出了一种基于TrustZone的以太坊密钥保护方法。本文在详细分析了以太坊交易流程的基础上，对以太坊的交易流程进行了分解，将密钥生成、用私钥对交易签名放在TrustZone的SW中进行，将未被使用的私钥以安全文件的形式存储在本地文件系统中。当需要使用私钥时，该方法再将安全文件加载到SW中并恢复出私钥，从而使得私钥可被安全、持续地使用。本文在模拟环境下实现了该方法的原型系统，对原型系统的功能和性能进行了验证和测试，并与现有方案进行了综合对比。结果表明，本文方法实现了预期目标，即基于本文方法生成的交易仍能被以太坊系统验证和接受，且性能开销在合理范围内，具有可行性。

参考文献

[1] GUPTA N K， JAIN A， SHARMA P C， et al. State of the art and challenges in blockchain applications［C］//Proceedings of Smart Systems： Innovations in Computing. Singapore： Springer， 2022： 311-320.DOI： 10.1007/978-981-16-2877-1_28 .

[2] PACHECO M， OLIVA G A， RAJBAHADUR G K， et al. What makes Ethereum blockchain transactions be processed fast or slow？ An empirical study［J］. Empirical Software Engineering， 2023， 28（2）： 39. DOI： 10.1007/s10664-022-10283-7 .

[3] YANG Q， WANG H. Privacy-preserving transactive energy management for IoT-aided smart homes via blockchain［J］. IEEE Internet of Things Journal， 2021， 8（14）： 11463-11475. DOI： 10.1109/JIOT.2021.3051323 .

[4] ZHANG L， LEE B， YE Y H， et al. Evaluation of ethereum end-to-end transaction latency［C］//Proceedings of 2021 11th IFIP International Conference on New Technologies， Mobility and Security （NTMS）. Paris： IEEE Press， 2021： 1-5. DOI： 10.1109/NTMS49979.2021.9432676 .

[5] MEIKLEJOHN S. Top ten obstacles along distributed ledgers path to adoption［J］. IEEE Security & Privacy， 2018， 16（4）： 13-19. DOI： 10.1109/MSP.2018.3111235 .

[6] 刘汉卿， 阮娜. 区块链中攻击方式的研究［J］. 计算机学报， 2021， 44（4）： 786-805. DOI： 10.11897/SP.J.1016.2021.00786 .

[7] LIU H Q， RUAN N. A survey on attacking strategies in blockchain［J］. Chinese Journal of Computers， 2021， 44（4）： 786-805. DOI： 10.11897/SP.J.1016.2021.00786（Ch ）.

[8] 魏松杰， 吕伟龙， 李莎莎. 区块链公链应用的典型安全问题综述［J］. 软件学报， 2022， 33（1）： 324-355. DOI： 10.13328/j.cnki.jos.006280 .

[9] WEI S J， LÜ W L， LI S S. Overview on typical security problems in public blockchain applications［J］. Journal of Software， 2022， 33（1）： 324-355. DOI： 10.13328/j.cnki.jos.006280（Ch ）.

[10] GROUP S. ETH DApp attacks［EB/OL］. ［2023-08-17］.

[11] ARMSTRONG B. Coinbase［EB/OL］. ［2023-11-17］.

[12] SWANEPOE M. Luno［EB/OL］. ［2023-11-17］.

[13] REZAEIGHALEH H， ZOU C C. New secure approach to backup cryptocurrency wallets［C］//Proceedings of 2019 IEEE Global Communications Conference （GLOBECOM）. New York： IEEE Press， 2020： 1-6. DOI： 10.1109/GLOBECOM38437.2019.9014007 .

[14] DABROWSKI A， PFEFFER K， REICHEL M， et al. Better keep cash in your boots-hardware wallets are the new single point of failure［C］//Proceedings of the 2021 ACM CCS Workshop on Decentralized Finance and Security. New York： ACM， 2021： 1-8. DOI： 10.1145/3464967.3488588 .

[15] GURI M. BeatCoin： Leaking private keys from air-gapped cryptocurrency wallets［C］//Proceedings of 2018 IEEE International Conference on Internet of Things （iThings） and IEEE Green Computing and Communications （GreenCom） and IEEE Cyber， Physical and Social Computing （CPSCom） and IEEE Smart Data （SmartData）. New York： IEEE Press， 2019： 1308-1316. DOI： 10.1109/Cybermatics_2018.2018.00227 .

[16] ARM. Arm security technology building a secure system using TrustZone technology［EB/OL］. ［2021-12-10］.

[17] 王丽娜，赵敬昌，余荣威，等. 针对 ARM 安全监视器的模糊测试方法研究［J］.武汉大学学报（理学版），2024，70（04）：453-462.DOI：10.14188/j.1671-8836.2023.0009 .

[18] WANG L N， ZHAO J C， YU R W， et al. Research on fuzz testing method for ARM secure monitor［J］. J Wuhan Univ（Nat Sci Ed），2024，70（04）：453-462.DOI：10.14188/j.1671-8836.2023.0009（Ch ）.

[19] 任正伟， 李雪婷， 王丽娜， 等. 云存储中外包数据确定性删除研究综述［J］. 电子学报， 2022， 50（10）： 2542-2560. DOI： 10.12263/DZXB.20220204 .

[20] REN Z W， LI X T， WANG L N， et al. A survey on assured deletion of outsourced data in cloud storage［J］. Acta Electonica Sinica， 2022，50（10）： 2542-2560. DOI： 10.12263/DZXB.20220204（Ch ）.

[21] MILL H. OP-TEE［EB/OL］. ［2023-11-07］.

[22] YANG H， LEE M. Demystifying ARM TrustZone TEE client API using OP-TEE［C］//Proceedings of SMA 2020： The 9th International Conference on Smart Media and Applications. New York： ACM， 2020： 325-328. DOI： 10.1145/3426020.3426113 .

[23] GITFINEON. Secure storage in OP-TEE［EB/OL］. ［2023-10-11］.

[24] REN Z W， LI X， XU S W， et al. Restricting the number of times that data can be accessed in cloud storage using TrustZone［C］// Proceedings of the 22nd IEEE/ACM International Symposium on Cluster， Cloud and Internet Computing （CCGrid）. New York： IEEE Press， 2022： 289-296. DOI：10.1109/CCGrid54584.2022.00038 .

[25] WOOD G. Ethereum： A secure decentralised generalised transaction ledger［EB/OL］. ［2023-01-18］.

[26] JOHNSON D， MENEZES A， VANSTONE S. The elliptic curve digital signature algorithm （ECDSA）［J］. International Journal of Information Security， 2001， 1（1）： 36-63. DOI： 10.1007/s102070100002 .

[27] DI-SCALA A J， GANGEMI A， ROMEO G， et al. Special subsets of addresses for blockchains using the secp256k1 curve［J］. Mathematics， 2022， 10（15）： 2746. DOI： 10.3390/math10152746 .

[28] ULLA M M， PREETHI， KHAN M S， et al. Implementation of elliptic curve cryptosystem with bitcoin curves on SECP256k1， NIST256p， NIST521p， and LLL［J］. Journal of ICT Standardization， 2023， 11（4）： 329-353. DOI： 10.13052/jicts2245-800X.1141 .

[29] BERTONI G， DAEMEN J， HOFFERT S， et al. Keccak［EB/OL］. ［2023-11-06］. DOI: 10.1007/978-3-642-38348-9_19 .

[30] SHBAIR W M， GAVRILOV E， STATE R. HSM-based key management solution for ethereum blockchain［C］//Proceedings of 2021 IEEE International Conference on Blockchain and Cryptocurrency （ICBC）. New York： IEEE Press， 2021： 1-3. DOI： 10.1109/ICBC51069.2021.9461136 .

[31] ETHEREUM GROUP. EIP-155 ［EB/OL］. ［2016-10-14］.

[32] JIAN Z L， LU Y， QIAO Y Y， et al. TSC-VEE： A TrustZone-based smart contract virtual execution environment［J］. IEEE Transactions on Parallel and Distributed Systems， 2023， 34（6）： 1773-1788. DOI： 10.1109/TPDS.2023.3263882 .

[33] LIND J， NAOR O， EYAL I， et al. Teechain： A secure payment network with asynchronous blockchain access［C］//Proceedings of the 27th ACM Symposium on Operating Systems Principles. New York： ACM， 2019： 63-79. DOI： 10.1145/3341301.3359627 .

[34] ZHANG F， HE W， CHENG R， et al. The ekiden platform for confidentiality-preserving， trustworthy， and performant smart contracts［J］. IEEE Security & Privacy， 2020， 18（3）： 17-27. DOI： 10.1109/MSEC.2020.2976984 .

[35] YAN Y， WEI C Z， GUO X P， et al. Confidentiality support over financial grade consortium blockchain［C］//Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. New York： ACM， 2020： 2227-2240. DOI： 10.1145/3318464.3386127 .

[36] JIANG J W， WANG D， ZHANG G Y， et al. Quantum-resistant password-based threshold single-sign-on authentication with updatable server private key［C］//Proceedings of the European Symposium on Research in Computer Security（ESORICS）. Cham： Springer， 2022： 295-316. DOI： 10.1007/978-3-031-17146-8_15 .

[37] GENTILAL M， MARTINS P， SOUSA L. TrustZone-backed Bitcoin wallet［C］//Proceedings of the Fourth Workshop on Cryptography and Security in Computing Systems. New York： ACM， 2017： 25-28. DOI： 10.1145/3031836.3031841 .

[38] DAI W Q， DENG J， WANG Q Y， et al. SBLWT： A secure blockchain lightweight wallet based on trustzone［J］. IEEE Access， 2018， 6： 40638-40648. DOI： 10.1109/ACCESS.2018.2856864 .

[39] FAN C I， TSENG Y F， SU H P， et al. Secure hierarchical bitcoin wallet scheme against privilege escalation attacks［J］. International Journal of Information Security， 2020， 19（3）： 245-255. DOI： 10.1007/s10207-019-00476-5 .

[40] SUNG S. A new key protocol design for cryptocurrency wallet［J］. ICT Express， 2021， 7（3）： 316-321. DOI： 10.1016/j.icte.2021.08.002 .