mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

数字化契约如何守护?解析盲签名的妙用

Collect
Share

作者:廖飞强 | 微众银行区块链核心开发者

来源:微众银行区块链微信公众号

数字签名在数字契约中包含不便公开的敏感信息时,如何进行有效的签名?签名时看不到信息明文,日后出现纠纷该如何追究维权?连签名者都看不到数据信息,如何支持有效的监管介入?其背后的盲签名技术和其他签名技术相比,有何过人之处?

在越来越重视隐私保护的数字化经济大背景下,对用户数据的隐私保护要求也日益提高。甚至在一些涉及敏感数据的场景中,用户向认证者提供待认证的数据, 认证者都不能观其明文

例如,关键事务决议相关的电子投票系统可能要求投票认证者在不知道每张选票意向的条件下,对每张选票进行认证,排除未授权投票者的选票。这需要保护选票意向的隐私性,又要验证选票意向明文的有效性,看起来是一项不可能的任务。

经典数字签名技术,需要获得数据明文,才能进行签名和验证,所以无法直接应用。为解决上述问题,盲签名技术应运而生。盲签名究竟如何在盲化数据明文之后,依旧保持数字签名的可验证性?盲签名可以支持哪些典型的应用场景,且看本文一一解析。

1. 盲签名的盲 化性

盲签名技术设计的核心在于 盲化待签名的数据 ,对应的机制在传统纸质签名中也有类似的存在。

最典型的示例便是 保密信封 ,其大致原理如下:

  • 第一步:将保护敏感数据的文件放进信封,在待签名区域上方放入一张复写纸,而后密封信封。这样一来,任何人不能透过信封观察信封内文件的具体内容。
  • 第二步:将密封的信封提交给签名者签名,签名过程中,信封上的签名可以透过复写纸签到文件上。
  • 第三步:使用者打开信封,取出的已签名文件,任意第三方可以认证其签名的有效性。
类似地,在使用盲签名中,用户通过技术手段对原始数据进行盲化,然后将盲化后的数据交给签名者签名,获得盲签名后再解盲,便得到了关于原始数据的有效数字签名。

盲签名技术的核心机制是 盲化 解盲 。盲化是指对原始数据添加随机性数据,隐匿原始数据明文。解盲是指移除随机性数据,将盲签名恢复为可验证的签名。

由此,盲签名在经典数字签名的基础上,新增了以下重要特性:

  • 盲化性 :签名者难以通过盲化后的待签数据,反推出原始数据的明文。
  • 不可追踪性 :签名者之前是对盲化后的待签数据签名,但使用者获取该盲签名后,会进行解盲处理,得到对应原始数据的另一个不同的签名,因此签名者无法对这一对签名进行关联和追踪。
回到之前提到的电子投票系统,上述特性可以很好地满足对应的隐私需求。具体操作时,投票者先对选票进行盲化,投票认证者仅能对盲化后的选票进行签名认证,无法知晓投票者选票的具体内容;后续投票者将盲签名解盲,投票认证者也无法追踪投票者的投票签名。据此,保护选票意向隐私性和验证选票意向明文有效性的需求得以同时满足。

值得注意的是,签名者对盲化后待签数据进行签名获得盲签名的过程,与对空白支票先进行签名,然后允许使用者任意改写支票内容的过程大不同。一般情况下, 盲签名一旦签发,其认证的原始数据是不能任意改变的 ,即解盲之后获得的签名,仅对盲化前的原始数据有效。

由此可见,盲化和解盲的构造是盲签名有效性的关键,具体如何设计这两个关键过程,常用的扩展有哪些,我们在下一节中继续展开。

2. 盲签名的构造和扩展

盲签名的构造

盲签名的构造过程可以看作是经典数字签名流程的一类通用扩展,通过引入 盲化因子 盲化算法 ,额外实现了签名的盲化和解盲步骤,其核心流程如下:
  • 盲化数据 :通过引入随机数作为盲化因子blinding_factor,将原始待签名的数据进行盲化处理。

  • 签名数据 :利用私钥将盲化的数据进行签名。

  • 解盲签名 :利用盲化数据阶段的盲化因子将盲签名解盲。

  • 验证签名 :利用公钥验证签名。

现有的大多数经典数字签名算法,都可以较为方便地构造出对应的盲签名实现,比较典型的实现有RSA盲签名、Schnorr盲签名、DSA盲签名等。

相比上一论中介绍的门限签名(参见 第17论 ), 盲签名没有复杂的密钥生成和协商问题,也不需要多方协同才能完成签名,其性能与经典数字签名相比并无太大区别

盲签名的扩展

盲签名的不可追踪性使得签名者很大程度上失去了对签名的控制权,如果出现用户滥用签名的情况,签名者很难追究维权,这在不少业务场景中是难以接受的,因此时常需要对基础的算法流程进行扩展。

在诸多扩展中,最常见的扩展之一便是 公平盲签名方案 ,其主要设计目标是允许签名者在出现纠纷时,能够通过以监管为代表的可信第三方还原出请求签名的用户身份和其他相关信息。

具体实现方式是引入一个可信第三方,通过可信第三方建立一种对签名的追踪机制。用户将待签名的原始数据和盲化后的数据首先发给可信第三方进行认证和登记,然后将盲化的数据和认证的数据发送给签名者进行验证,验证通过后进行盲签名,并保存盲化的数据。

后续如果需要进行签名追踪,签名者发送盲化的数据给可信第三方进行查询,获取用户的原始签名数据和身份。

相比直接使用会暴露待签名原始数据的经典数字签名,公平盲签名实现了一定程度上的 隐私数据访问权限隔离

  • 签名者只能看到用户身份,不能看到待签名的原始数据明文。
  • 只有当可信第三方和签名者联合之后,才可以将原始数据明文和用户身份关联起来。
除了公平盲签名之外,另一类常见的扩展是 部分盲签名 ,即分离认证数据和隐私数据,只盲化需要保护的隐私数据,其典型的应用是网络流量的欺诈检测。

总体而言,盲签名的构造支持较为通用的扩展需求。在实际业务应用中,根据具体的隐私保护需求,一般都可以自由选择数据进行定向盲化,并在必要时引入监管所需的解盲机制,控制盲签名被滥用的风险

3. 盲签名的应用赏析

在盲签名的诸多应用中,较为知名的莫过于电子现金。现实的电子现金业务会涉及复杂的流程设计,不便于体现盲签名的作用。所以,下面以一个经典的教科书示例,来展示基于盲签名的应用设计和使用注意事项。

在本例中,目标是构建一个与传统纸币功能相当的电子现金系统E-Cash,其核心需求如下:

  • 货币价值性 :电子现金是代表一定价值的数字符号,需要具备银行的授权信用,并提供相关实体现金支持。
  • 可交换性 :电子现金相比实体现金,其优势在于更方便交换、流动。电子现金与电子现金之间可以流动,电子现金与实体现金之间可以兑换。
  • 防伪与不可复制性 :每一张电子现金均需要经过银行认证,不能任意生成,而且要求不能将已有的电子现金复制出多个可用的电子现金,防止重复使用。
  • 匿名性 :电子现金不能与用户的身份进行绑定,保护用户使用电子现金的隐私性。
针对E-Cash电子现金系统的各项业务流程,可以基于盲签名技术,给出以下应用设计:
  • 用户开户 :在运行E-Cash电子现金系统的银行,用户注册一个传统的银行资金账户和一个电子现金账户,并在银行资金账户中存入一定量的资金。
  • 电子现金发行 :用户在银行的钱包客户端生成一个随机序列号,并设置申请的电子现金面额, 这里为了简化描述,假定所有任意序列号所代表的的面额相同 。而后用户将随机序列号进行盲化,再将电子现金发送给银行进行盲签名。
    银行无法知道用户电子现金的序列号,却能将签发的电子现金发到用户的电子现金账户。
  • 电子现金支付 :用户A将一张电子现金支付给用户B,用户A在支付前需要解盲电子现金,再发送给用户B。用户B收到电子现金后进行签名验证,验证成功后将电子现金的序列号发送给银行。
    银行查询该序列号,如查询到该序列号已存在,代表该电子现金已花费,用户A此次支付失败。如未查询到,则将序列号存储下来,用户A此次电子现金花费成功,银行根据之前约定的序列号代表的面额,将收到款项计入用户B的账户中。
以上设计中, 盲签名的使用让电子现金实现了与传统纸币同等的匿名性 。用户只有在经过银行认证之后才能获得电子现金,但银行后续无法将使用解盲后的电子现金的用户身份与当初发行的盲化电子现金关联起来。

我们也可以进一步用公平盲签名替换基础盲签名方案,将监管者引入电子现金系统,实现可控匿名的效果,为追究洗钱等犯罪活动提供有力的技术手段。

盲签名的使用有很强的灵活性,在使用和设计基于盲签名的应用时,分清角色进行针对性设计是用好盲签名的重要前提,务必要厘清不同角色的访问权限,想清楚盲化的数据是针对哪个角色、对哪些角色展现的数据不能盲化等问题

正是:业务涉密契约禁明示,盲化签名可签不可见!

在隐私保护要求趋严,隐私数据保护立法日益完善的商业环境下,盲签名技术提供了一种独特的隐私数据保护手段。对于关键隐私数据,盲签名既可以实现签名认证,又可以对其数据内容进行隐匿保护,还可以选择性地提供监管追溯支持,在现实业务场景中具有重要的实践价值。

至此,密码学数字签名系列分享已近尾声,对于之前介绍的数字签名技术,其验证过程大多是逐一进行的。然而,对于大数据场景中的海量隐私数据,如果需要对海量的数字签名进行一一验证,不免会带来巨大的系统负担,有时甚至会影响业务方的决策。

为了满足高性能要求,校验数据有效性的数字签名可能被迫舍弃。有没有更有效的批量签名验证技术,使得仅需一次验证计算,便可完成多个签名的效验?技术上有何挑战?欲知详情,敬请关注下文分解。

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content