刘 鑫，柳 毅

（广东工业大学计算机学院，广东 广州 510006）

0 引 言

随着区块链和智能合约的普及，各种加密货币不断涌现，它们带来诸多便利的同时也引起了资金被盗和隐私泄露等问题。例如，针对DAO 合约的攻击导致超过360 万个Ether 的损失［1］。黑客攻击了美链（BEC）的Token合约，通过一个整数溢出安全漏洞，将大量Token 砸向交易所，导致BEC 的价格几乎归零。这些案例中许多都是由智能合约代码漏洞引起的，例如重入和循环调用等。正是由于智能合约一经部署就无法修改合约代码的这一特性，不同于其他的中心化应用软件，在资金被盗时没有应急措施，而且在私钥被盗或遗忘的情况下，资金便无法使用，区块链也缺乏相应的恢复机制。许多加密货币引入了自己独有的加密代币，用私钥进行身份认证成功后即可交易。这些私钥往往都是冗长且毫无规律性的字符串，由钱包软件管理，并且此类软件还为用户提供了与加密货币交互的界面［2-3］。这类钱包管理软件采用传统的账号密码登录方式，大多数用户使用的密码都是比较便于记忆的弱密码，恶意软件可能会引入键盘捕捉器截获账户密码从而盗取用户私钥［4］。PPSS 是Bagherzandi等人［5］引入的一个中心原语，它允许用户在n个服务器之间存储秘密，之后用户可以通过与t+1（t＜n）个服务器进行交互，在拥有单个密码的情况下重建秘密。与此同时，攻击者侵入这些服务器中的t台，并控制所有通信信道，也无法截获秘密。该方案的优点是在重建秘密阶段不依赖安全信道或公钥基础设施，但是在与服务器进行多轮交互过程中可能会受到在线字典攻击，一旦攻击者破坏了t+1 台服务器就能立刻获得秘密。如果密钥完全由服务器存储，则称为服务器端钱包。这类钱包的弊端是密钥的安全性完全取决于服务器的诚实性，然而服务器总是好奇的，无法保证其安全性。由于这种服务器端钱包存在安全隐患，仅提供与区块链交互界面（或仅存储用户加密私钥）的托管钱包开始激增。在这种钱包中，包括私钥存储在内的功能已转移到客户端，称为客户端钱包。客户端钱包的一个例子是区块链钱包［6］，它是一种基于密码的钱包，它基于密码知识对服务器进行单因素身份验证，并通过由Google 身份认证器、电子邮件等组成的选项之一对服务器启用双因素认证（2FA）。在创建事务时，可以通过输入第二密码来验证身份［7］。另外，还有许多学者应用阈值加密、多重签名、硬件存储等方法存储用户私钥。Zhou等人［8］提出了一种基于无可信中心门限椭圆曲线数字签名的方案。在该方案中，参与者合作生成公钥和私钥，并在不需要可信中心参与的情况下共享私钥。超过阈值数的参与者可以通过恒定轮数对交易进行签名，有效抵御单点攻击。多重签名协议［9］最早由Itakura 和Nakamura 引入，允许一组签名者（每个人都拥有自己的公私钥对）在消息m上生成单个签名。在给定消息和所有签名者的公钥集的情况下，可以公开验证签名的有效性。将标准签名方案转换为多重签名方案的一种简单方法是让每个签名者使用其私钥为m生成独立签名，并将所有单个签名串联起来。然而，在这种情况下，多重签名的大小随着签名者的数量线性增长。Maxwell 等人［9］提出了一种新的基于Schnorr 的多重签名方案（即允许一组签名者在公共消息上产生短的联合签名的协议），该方案满足普通公钥模型安全性，这意味着签名者只需要拥有公钥，但不必在使用协议之前向某个认证机构或其他签名者证明知道与其公钥相对应的私钥。

然而上述的方案都无法实现私钥丢失后的资金托管和账户恢复的功能。Moser 等人［10］设计的加密货币通过延迟接受交易来抑制密钥盗窃，一旦非法交易发布在区块链上，合法用户有足够的时间使用适当的恢复密钥来阻止交易。这种机制的目的是减少攻击者窃取密钥的动机。但是，它没有解决在无意中丢失密钥的情况下恢复对帐户访问的问题。Homoliak等人［7］设计了一个智能合约钱包框架，该框架由4 个组件组成（即认证器、客户端、硬件钱包和智能合约），并提供在与区块链交互的2 个阶段执行的双因素认证2FA。该方案的优势是自主设定安全认证规则，将智能合约和身份认证绑定，一旦满足某种条件时就会触发双因素身份认证，但是硬件钱包不方便携带，一旦钱包丢失就会有安全风险。Breuer 等人［11］提出了一种系统，将安全规则写进智能合约并部署，在检测到有安全问题时智能合约可以暂时锁定账户并托管账户资金，同时调用双因素身份验证2FA程序。初始化时，帐户的所有者在用户委员会中秘密共享一些安全问题的答案。当2FA机制被触发时，用户可以向智能合约提供预设问题的答案来实现身份认证，认证成功后才能解锁账户。该方案可以在检测到账户异常时实施额外的保护，对于正常的交易也不会增加额外的验证时间，但是初始化之后若要再添加新的委员会成员，过程比较繁琐。

1 预备知识

1.1 双因素身份认证2FA

双因素身份验证2FA 是通过要求用户提供额外的身份验证因素（例如，由安全令牌生成的代码）来增强基于密码的身份验证的弹性［12］。2FA 在许多领域都有应用，最常见的是异地登录应用程序时，通常需要用户在输入密码后再输入手机动态验证码。这种方法可以有效阻止恶意用户盗取密码。如果将这一想法引入到去中心化环境中，首先出现的问题是在没有可信权威的情况下，无法产生验证码。显然，智能合约无法存储保密信息，智能合约本身不提供任何形式的隐私。

1.2 非交互零知识证明（NIZK）

非交互式零知识证明系统只包含一条由证明者（Prover, P）发送给验证者（Validator, V）的消息。由于其良好的保密性、认证性和较低的交互复杂度，它被广泛用于构建各种类型的密码协议和密码算法。Goldwasser 等人［13］对交互式证明系统进行了研究，并分析了知识复杂度为零的交互式证明系统，这开创了密码学和计算复杂度理论的一个重要分支——零知识证明。Blum 等人［14-15］最早提出了非交互零知识NIZK 证明系统，并引入了目前普遍应用的公共参考串（CRS）模型。非交互式零知识证明系统［16］只包含由证明者发送给验证者的消息，这可以更好地用于构建密码协议。随后，关于NIZK 证明系统的理论和应用的研究层出不穷［17］，包括NP 问题的NIZK 证据和非交互式统计（完美）零知识，以及NIZK 证明在CCA安全加密方案、匿名认证、群签名和环签名构造中的应用。

在一个非交互零知识证明系统中，（P，V）是一对概率图灵机，P是指概率多项式时间（充当承诺者），V是指决策多项式时间（充当验证者），R是指非交互随机数预言机［18］，（P，V）则称为语言L的非交互零知识证明系统。该系统遵循以下3个原则：

1）完整性（Completeness）。若P知道一个定理的证明方法，则P使V以绝对优势的概率相信它能证明。在多项式时间内，对于任何公共输入x⊂L，都可以计算：

2）公正性（Soundness）。若P不知道一个定理的证明方法，则P使V相信它会证明定理的概率很低。在多项式时间内，对于任何公共输入x⊄L，任何交互图灵机P'，都可以计算：

3）零知识性（Zero-knowledge）。对于任何公共输入x⊂L，存在一个概率多项式时间算法满足：

其中，R∈{0，1}c(|x|)代表在公共参数x区间内产生随机数，cM（x）x⊂L表示一个概率多项式时间算法［19］。

遵循Schnorr 协议的NIZK 方案的实现依赖于证明者P 和验证者V。设（g，h）和（g'，h'）是p阶素数群Zp的2 对元素，要证明存在元素ω∈Zp，使得gω=g'、hω=h'同时成立，证明者P需要发送一条证明消息来说服验证者V，具体如下：

1）证明者P 从Zp中均匀采样r并计算出承诺（commitment，com）com=（gr，hr），生成随机挑战c=Hash（com，M），M表示一串数据，再计算z=ωc+r并生成证明π=(gr，hr，z)。

2）如果验证者V 计算得到g'c·gr=gz和h'c·hr=hz，则验证通过。

遵循Schnorr协议的NIZK方案包含以下算法：

1）Setup（1λ）：在输入安全参数1λ时，算法返回公共参考字符串crs。

2）Prove（crs，stmt，wit）：在输入公共引用字符串crs、语句stmt和见证wit时，算法返回证明π。

3）Verify（crs，stmt，π）：在输入公共引用字符串crs、语句stmt 和证明π时，算法返回一个比特位{0，1}。0表示验证失败，1表示验证成功。

1.3 基于离散对数困难问题的ElGamal算法

在密码学中，ElGamal 加密算法是一个基于Diffie-Hellman 密钥交换的非对称加密算法，它在1985 年由塔希尔·盖莫尔提出。ElGamal 公开密钥密码体制是基于有限域中离散对数问题的难解性的。它所根据的原理是：求解离散对数是困难的，而其逆运算可以应用平方乘的方法有效地计算出来。在相应的群G中，指数函数是单向函数，即在有限的算力之下无法逆向求解。

2 方案设计

2.1 整体架构

本文提出的方案主要结合了非交互零知识证明、Shamir 密钥分割、ElGamal 算法、默克尔树等多种方法，在智能合约的辅助下对区块链交易实现实时监控［20］保护，在发生异常情况时及时启动双因素认证，防止恶意交易的发生。本文方案由以下3个部分组成：

1）支持双因素认证的区块链用户（User，U）：通过初始化，用户可以自定义需要保护的交易类型并提交自己的安全验证密码（该密码可以是低熵的），在启动双因素认证时提交密码验证交易。

2）辅助验证组（Verification Group，VG）：任何加入区块链节点贡献算力的矿工都可以加入验证组，在初始化阶段，提交公钥并获得唯一的组内ID，在双因素认证阶段为用户的身份认证提供算力［21］。

3）智能合约：监测用户的交易地址变化、交易金额以及特定时间段内的交易频次，用户自行设计具体的合约并部署。

本文的方案设定了3种强制调用2FA的异常情况：

Q1：交易地址不属于预设的日常交易地址集合；

Q2：单次交易的金额超过阈值；

Q3：一定时间内的交易次数超过阈值［22］。

一旦智能合约监测到上述的3 种异常情况，立即触发双因素认证。方案的实现步骤可分为初始化、调用双因素认证、智能合约判定，其中双因素认证分为默克尔树认证和非交互零知识证明。具体内容下文将进行详细描述。

2.2 初始化

设(G1，G2，GT，p，g1，g2)是p阶素数非对称双线性映射群系统，e:G1×G2→GT表示一个有效可计算的双线性配对，g1、g2分别表示群G1、G2的生成元，gT=（g1，g2）表示GT的生成元。H：{0，1}*→{0，1}λ是抗冲突的哈希函数。初始化算法的具体实现如下：

输入安全参数1λ，α=（α1，…，αlog(p)）表示低熵秘密的二进制表示，t表示验证组的秘密重构阈值，n表示验证组大小，用户运行Setup 算法输出唯一的全局标识符IDi，并将哈希数据块集合MH={H(α1)，…，H(αlog(p))｝在验证组内广播，用MH 构建默克尔树并在本地［23］存储默克尔根R。之后Setup算法从Z*p均匀采样一组元素（x，r，s，ρ），其中x作为用户私钥，公钥设置为：

其中crs由NIZK.Setup（1λ）生成，c0、c1、u1、u2是用ElGamal算法加密的低熵秘密，参数具体表示如下所示：

验证组成员运行Setup算法输出组内索引Yi和共享密钥ski=xi，利用Shamir 秘密分割算法生成验证组的共享密钥集：

其中任意t个共享密钥可以重建秘密。每个组内成员在本地创建一个搜索表，如表1所示。

表1 验证组成员搜索表

2.3 调用双因素认证

智能合约监测用户的账户资金动向［24］，一旦有预设的异常情况出现，智能合约就会暂停用户当前交易并启动双因素认证。第一因素的认证过程如图1所示。

图1 第一因素认证过程

首先暂停用户交易，启动第一因素认证，用户需要向智能合约提交全局标识符IDi、随机数e、默克尔根R和随机数e产生的H（R/e）。然后智能合约向验证组发布IDi的查询交易任务，查询完成后，验证组成员提交IDi和哈希数据块集合MH（用于生成默克尔树），具体表示如下：

最后由智能合约判定最终结果，判定过程将在智能合约判定阶段详细说明。若验证通过，则继续进行第二因素认证，否则拒绝交易并锁定24 h。

第二因素认证由NIZK 和ElGamal 算法共同实现，用户本地运行计算出低熵秘密的密文块和对应的密文块证明，提交给验证组进行分布式验证，并由验证组向智能合约集中反馈验证结果，最终由智能合约判定验证是否通过。具体步骤分为用户提交验证申请和验证组反馈验证结果：

1）用户提交验证申请：用户执行申请算法，输入公钥pk、用于验证的低熵秘密γ（验证γ是否与初始化的α相等）：

在群G1中均匀采样ri计算密文块（c0，i，c1，i），并产生密文块对应的证明πi，具体计算步骤如下所示：

最后申请算法会返回一个验证列表L：

2）验证组反馈验证结果：验证组成员执行反馈算法，输入公钥pk、共享私钥ski、验证列表L，验证组成员在本地计算：

对于L中的所有密文块对应的证明πi都满足上述等式，等式成立，则继续验证，若不满足则立即拒绝交易，且24 h 内不可再发起双因素认证。下一步，生成用于双线性配对的参数k←H(pk，L)，并进行以下计算：

其中b0、b1反馈给智能合约进行对比验证［25］，每个验证组成员随机生成一个群元素δ和拉格朗日系数λi，生成0、进行双线性配对验证：

最后，每个验证组成员向智能合约发送一个验证反馈Ri：

Ri=(c(i)0，λi，b1，k(i)，k)

2.4 智能合约函数的设计与判定过程

本文方案部署的智能合约包括createVerification-Group（）、firstVerification（）、secondVerification（）、first-Broadcast（）、secondBroadcast（）等几个合约函数，它们的具体功能如下：

1）createVerificationGroup（）：矿工提交合约地址，用户提交低熵秘密的二进制表示α以及哈希数据块集合MH，每个矿工会得到一个密钥份额ski、组内索引Yi和单个哈希数据块H（αi），该函数用于生成验证组的初始化。

2）firstVerification（）：用户提交全局标识符IDi、随机数e、默克尔根R和随机数e产生的H(R|e)，验证组成员提交对应的H（αi），最终由智能合约判定验证结果，该函数用于执行第一因素认证。

3）firstBroadcast（）：该函数用于广播第一因素认证结果。

4）secondVerification（）：用户在本地计算出低熵秘密的密文块和对应的密文块证明并向智能合约发起查询，验证组进行组内验证，并由验证组向智能合约集中反馈验证结果，最终由智能合约判定验证结果。该函数用于执行第二因素认证。

5）secondBroadcast（）：该函数用于广播第二因素认证结果。

对于第一因素的认证，智能合约主要的任务是收集验证组提交IDi和哈希数据块集合MH，用MH 生成默克尔根R～，接着计算H(R～|e)，判定等式：

是否成立，若成立，则验证通过，进入第二因素认证，否则验证失败。

智能合约收集验证组成员的反馈Ri，并查验以下等式是否成立：

若对于收集到的Ri都满足上述等式，则验证通过，否则验证不通过。

3 性能对比分析

3.1 安全性分析

本文提出的双因素认证包括默克尔树认证和非交互零知识证明。默克尔树认证的安全性主要依赖于哈希函数的抗碰撞性和不可逆性，本文采用的哈希函数是SHA-256，由于其不可逆的性质，只要SHA-256 不被破解，恶意用户就不能截获用户的低熵秘密，并且在验证阶段，用户传递的是H(R|e)，而非默克尔根R，并且每次随机产生随机数e，这整个过程都不会泄露默克尔根R。在非交互零知识证明阶段，验证组成员向智能合约反馈的信息是零散的密文块［26］以及对应密文块的证明。假设恶意用户截获了所有信息，也无法获得真正的低熵秘密，可以抵御验证组成员的合谋攻击。在双因素认证的过程中，只要遇到验证失败，智能合约就会拒绝交易，在24 h之后才能再次发起双因素认证，这里可以抵御恶意用户的猜测攻击。

3.2 方案对比分析

本文方案引入智能合约监测用户的交易状态和账户资金，以便于及时拦截异常交易，强制用户调用2FA 进行身份认证，只有在通过验证之后交易才能通过。本文方案与文献［7］、文献［11］、文献［17］相比有许多优势，具体如表2所示。

表2 方案性能对比

文献［17］在身份认证过程中需要多个服务器提供计算量，而且服务器和用户之间还需要多轮交互才能完成验证，这既增加了服务器租用费也可能泄露用户的密码。而文献［7］需要通过多轮交互，并且生成一次性密码都需要可信第三方，这也会增加认证过程中许多额外开销。相比之下，文献［11］无需服务器辅助验证，也减少了交互次数，但是与本文方案相比，鉴别恶意用户的时间更长，计算开销也更大，具体在实验验证部分详细描述。

4 实验验证

本文实验硬件环境为Intel Core i7-6700 CPU 3.40 GHz，8 GB RAM 和Intel Core i5-1240p CPU 4.40 GHz，16 GB RAM；操作系统为Ubuntu 20.04；编译器为IntelliJ IDEA 和Remix，通过web3.js 实现与区块链的交互。本文方案的基础实验平台是以太坊，在以太坊虚拟机上部署智能合约，每项操作都有计算量和Gas 值的限制，所以主要的计算任务都分配给了验证组成员。

与文献［7］和文献［11］相比，由于无需与服务器交互，本文方案的初始化时间更短。但与文献［11］相比，本文方案在初始化开销方面会略高一些，由于初始化阶段，用户需要生成低熵秘密的默克尔树并保存默克尔根，验证组成员需要保存低熵秘密的哈希数据块，但这在验证阶段将会提高验证速率。具体对比如图2所示。

图2 初始化时间对比

在双因素认证阶段，文献［7］和文献［17］都需要借助第三方服务器生成随机的一次性密码OTP，所以验证时间会比认证过程完全依赖智能合约的方案花费更多。本文方案和文献［11］的方案验证时间有所优化。具体的对比如图3所示。

图3 验证时间对比

经过实验认证，本文方案面对在恶意用户企图非法转移账户资金时，第一因素默克尔认证可以成功识别并拦截73%的恶意用户，拦截后恶意用户便无法接触到后续的非交互零知识证明，在用户恢复［27］账户使用权后也只需要支付默克尔认证的费用，这也可以减少恶意用户攻击的频率。具体对比如图4所示。

图4 恶意用户的双因素认证开销对比

5 结束语

本文提出的双因素认证方案结合了非交互零知识证明、默克尔树、ElGamal 算法等方法，并将认证过程写进智能合约中。当智能合约捕捉到了异常交易，强制用户进行双因素认证以恢复交易，若是认证失败，异常交易将会被锁定24 小时。从实验验证的结果来看，面对恶意用户的攻击，本文方案的认证开销更小，并且合法用户有较长的时间来恢复账户，可避免许多的经济损失。