14

如何多人守护一份数字契约?解析多方门限签名的妙用

 4 years ago
source link: https://www.jinse.com/blockchain/759489.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

数字签名是否只能由单一主体签署?在涉及多方授权的场景中,如何实现多方联合签名?多方联合签名是否支持决策权重分配?其背后的门限签名技术除了支持多方授权功能之外,还有哪些神奇之处?

在倡导价值流通、价值融合的数字化经济中,多方合作无处不在。此过程中签订的数字契约,难免遇到需要在多个参与方之间 分配独立决策权重 的场景,然后对于一个拟定的决策目标,只有满足一定数量协作方同时授权才能生效。

一个典型的示例是基金会区块链资金账户管理。

该账户的资金由多个参与方共有,因此其账户私钥一般不应由单一主体保管,以避免权利过于集中,出现肆意操作资金的风险。另一方面,如果出现唯一的私钥丢失,则资金可能永久性丢失,潜在风险巨大。

如何以一种公平有效的方式,让多个参与方共同掌控账户资金,是一个十分现实的需求。

经典数字签名技术,由于只能由 单一主体来掌控私钥 ,所以无法直接用以解决上述问题。为此,我们需要引入门限签名技术。门限签名究竟是如何实现公平有效的多方授权机制?可以支持哪些具体的应用场景?本文将进行专题解析。

门限签名的协作性

在协作中实现有效多方授权的关键在于『分权机制』,对应的机制在中国古已有之。

“虎符”就是一个典型的见证。作为调兵遣将用的兵符,虎符是一种伏虎形状的令牌,一般由青铜或者黄金制成,制成后,劈为两半,分别交由将帅和皇帝保管。只有集齐对应的两个虎符,无缝合并成完整的伏虎形态,持符者才有权调兵遣将。

QZvmiub.jpg!web

虎符生效所需的最小数量其实就对应到了密码学中的术语—— 门限值 ,只有达到了门限值的授权数量,授权才生效。

门限签名是门限密码学(参见第13论)中的一个重要分支,从构造上来看,门限签名可以看作数字签名和秘密分享的结合体。

对于一个 (t, n)门限签名 算法,其典型的使用过程如下:

在一个由n个参与方组成的群体中,群体中各参与方通过一定方法获得相应的 签名私钥分片 ,群体中至少有t方使用各自的签名私钥分片对同一份数据进行签名,产生 签名分片 ,然后将各方签名分片合并,才能产生最终有效的签名。其中,t为门限值,当签名方的个数小于t时,无法产生有效的签名。

门限签名在诸多分布式协作场景中均有应用,以下从两个典型场景来展示其效果。

  • 基金会区块链资金账户管理

针对其账户资金权需要由多方共同授权才能动用的需求,可以使用门限签名来解决其中的业务痛点:

  1. 管理资金账户的n个参与方可以各自拥有一个私钥分片,可以进行独立的决策过程。

  2. 动用资金账户必须获得由至少t个参与方进行签名授权,才能生成有效的门限签名。

  3. 少于t个参与方签名授权,无法动用资金账户。

  4. 除此之外,门限签名还提供了以下额外特性:

  5. 身份隐匿:第三方无法从聚合的门限签名中恢复出授权签名的参与方的个体身份。

  6. 容灾恢复:最多允许n-t方私钥丢失,不影响资金账户的使用。

rieMZjA.jpg!web

  • 跨机构投票决议

针对其多数独立决策方同意才能通过决议的需求,利用门限签名可以容易地实现这种规则效果。

假定投票决议通过的条件是获得多于50%同意,则可以设置门限值为t > n/2。由此,只有当某个决议项收集了至少t个决策方的签名时,才能针对该决议项生成有效的签名,进而通过该项决议。

同时,正如基金会区块链资金账户所有展示的身份隐匿特性,所有决策方的身份都受到匿名保护,可以安心独立地完成做出符合自身意愿的决策。

对于不同决策方拥有不同权重的投票决议过程,门限签名也可以轻易支持。

简单设计是按权重分配不同数量的私钥给对应决策方,这样各个决策方能产生不同个数的签名分片,体现其分布式协作中的权重分配。高阶设计可以采用带权重的门限签名方案,即参与方均是一个私钥,但产生的签名自带权重。

由此可见,对于多方协作中所涉及的联合决策、权重分配、身份保护、容灾恢复等核心需求,门限签名都能提供很好的支持。

门限签名的使用注意事项

门限签名的构造和使用相对比较直白,但也有其特别的注意事项。

  • 基本算法选型

门限签名的构造方式很多,算法变种也不少,选型时可能会带来一定的困惑。

首先,我们需要区分一类与门限签名功能类似的签名技术,即 多重签名技术 。其实现机制是让多个参与方进行多次签名操作,最终生成多个签名,但不能对这些签名进行合并,验证时需要按各个参与方的签名公钥依次验证。

多重签名与门限签名的具体区别如下图所示:

EVbYnum.jpg!web

多重签名在公私钥对的初始化便捷度指标上占优,但综合各项指标,门限签名通常是更优的选择。

目前比较常见的门限签名算法有,基于RSA的Shoup门限签名方案、基于Elgamal 的Harn 门限签名方案、基于ECDSA的门限签名方案,以及基于BLS的门限签名方案。

从综合性能方面考量,比较推荐使用 基于ECDSA的门限签名方案和基于BLS的门限签名方案 ,目前其签名效率均可以达到毫秒级。

  • 是否 引入可信第三方

回到公私钥对的初始化指标,门限签名需要一个协商过程才能完成初始化。如何安全地进行初始化,让各个参与方获得自身的私钥分片,是保障门限签名有效性的关键。

根据这一初始化过程中,是否需要引入可信第三方,门限签名可以分成以下两个大类:

  1. 中心化门限签名:由可信第三方生成所有签名方的私钥分片,然后进行私钥分片分发,最后各签名方使用私钥分片进行签名。签名方之间不需要进行私钥分片生成过程中的数据交互。

  2. 分布式门限签名:不需要引入可信第三方,签名方可以通过交互进行相关参数的协商,完成各自私钥分片的生成过程。获得私钥分片后,签名方使用其进行签名。

INjMBfr.jpg!web

上述两类门限签名方式的不同之处在于,中心化门限签名的签名方之间,数据交互少,甚至没有交互,极大程度降低通信开销,但所有签名方均需信任一个第三方。分布式门限签名不需要可信第三方,但是签名方之间需要进行数据交互,增加了通信开销。

具体业务场景中,如果存在一个可以担任可信第三方的角色,采用中心化门限签名方案是较好的选择,可以提高系统效率。如果不存在此类角色,则可以选择分布式门限签名。

门限签名的应用赏析

随着经济数字化改革的深入,在以区块链为代表的分布式协作技术的驱动下,以往难以实现的分布式商业场景,如今成为了可能,其中门限签名更是大有用武之地。

基于门限签名的典型应用场景有:分布式资产托管、可共识区块链预言机、分布式公钥证书服务等。如果我们用threshold signature作为关键词搜索,可以查到很多和不同类别签名技术结合的融合方案。

限于篇幅,这里以公钥证书服务PKI(Public Key Infrastructure)的分布式版本DPKI(Decentralized Public Key Infrastructure)为例,进行应用赏析。

正如第15论所提到的,PKI作为鉴别数字签名有效性的三大必备共性技术之一,其解决的核心问题是:公钥密码算法中,公钥有效性的认证问题。

PKI一般由一个权威机构运营,提供对实体身份和公钥的认证服务,认证通过后签发一个对应的数字证书。通过数字证书可以证明身份的真实性,以及身份与公钥的关联性。

传统PKI面临的不足之处主要体现在,传统PKI证书签发机构在签发和管理证书的过程中,可能存在 单点脆弱性 ,即出现单一证书签发机构的证书签发私钥泄露或被窃取,从而导致重大声誉和财务损失。

例如,黑客从中心化的证书签发机构获得签名证书并窃取私钥,然后对恶意软件进行签名,生成看似安全的签名认证软件,但这实际是一个恶意软件,非常容易导致网络安全事故。

保障数字证书的有效性是PKI 系统的信任基础,影响到整个系统的可靠性。为了提高系统可靠性,可以基于门限签名来构造分布式公钥证书服务DPKI。

在证书签发过程中,使用门限签名算法,使得一个有效的数字证书必须获得来自不少于门限个数的签名分片才能生效。同时,证书的验证过程只需要使用单个合并公钥,所以也不会影响原有的证书验证过程。

DPKI实现了一种分布式公钥证书管理体系,要求多方授权才能签发数字证书,不再依赖单一实体对签名私钥的保护能力。当黑客获取的签名私钥个数少于门限值,就无法自行签发有效的数字证书,无法进行网络破坏和攻击行为。

门限签名使得传统PKI的单一信任点变为了分布式PKI的信任网,可以有效提高PKI的稳健性,使其签发的数字证书更安全、更可信。

uUJrUbE.jpg!web

正是:平等分权契约须联名,门限签名不合则不达!

在多方协同、互利互惠的分布式商业大环境中,如何有效地支持各个参与方之间权利分配、独立决策是至关重要的业务需求。门限签名则是满足这些协作性需求的一类关键技术,控制权利过分集中导致的系统性风险,鼓励更多实体参与合作,并建立公平、对等的伙伴关系,在数字契约的框架下,切实保障各个参与方的合法权益。

门限签名对参与方的身份也提供了一定的匿名保护,但是对于待签数据本身没有提供直接的保护。签名方依旧可以看到待签数据的明文,在某些特定的业务场景中,这是不可接受的。为什么这些业务场景会有这样的隐私保护需求?技术上如何满足这一需求?欲知详情,敬请关注下文分解。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK