基于区块链的可验证凭证的共享和选择性披露---论文分享

步入研究生生活，也算是走上了科研的道路。前几天在组会上做了汇报，顺便将此整理一下作为自己的第一篇博客，也算是个小小的记录和开始。

目前关注的方向是基于区块链的数据选择性披露，这次汇报的文章作为入门了解选择性披露还是一篇非常不错的文章，废话少说，直接进入正题。

跳过概述和引言部分，直接介绍实际应用场景帮助理解选择性披露。

激励场景和准备工作

引入场景

Jane是X大学的一名学生，最近刚完成了本科学位。她正在申请一个海外研究所Y大学的研究生职位。最近几个月，Y大学的招生协调员Bob收到了一些外国申请者的假成绩单，所以他希望核实Jane的身份和X大学的成绩单。Jane愿意共享凭证，但她也对自己的隐私很谨慎，并且希望仅共享使Bob满意的基本信息。

通过这样的场景我们很自然的引入了选择性披露这个概念，其中大学X作为凭证（此处为成绩单）的颁发者我们称为发行者，Jane为接收者，而Bob作为凭证的验证者，上图很好的展示了选择性披露的应用场景。Jane收到来自大学X的凭证之后可以对凭证进行编辑操作以对不同的验证者共享凭证中不同的属性集合，如对Bob共享学院（UNSW）和专业（CSE），对Tom共享专业（CSE）和绩点（3.75），从而实现了数据的选择性披露。

基于SSI的共享凭证

要实现上述场景所需的功能，往往需要对系统中用户的身份进行管理。因此这篇论文是基于SSI实现的凭证共享。SSI（Self-Sovereign Identity，自我主权身份），大致思想就是使用户完全控制自己的身份。系统包含以下部分：

发行者.这是一个实体，例如，X大学，负责颁发证书。在最一般的意义上，发行者可以是在系统中注册的任何人，但在我们的系统中，发行者是具有SSI平台的预注册实体。

接收者.这是一个实体，例如，Jane，其请求并接收来自发行者（因此也称为凭证的持有者）的凭证。接收者可以与验证者共享凭证。接收者的身份在SSI平台注册。

验证者.这是一个实体，例如，Bob，他从接收者接收凭证并使用系统验证凭证。这可以是具有要验证的凭据的任何人。

凭证.可验证凭证（或简称凭证）是由实体（即，发行者）创造的关于另一实体（即，接收者）的防篡改语句集，其可以被密码验证（即，验证者）。凭证上的个人信息片段，例如地址或出生日期，称为“凭证属性”（或简称属性）。可验证的凭证用于生成声明。

声明.是关于接收者的宣称，并且通常由凭证的属性的子集构成。在我们的场景中，如果Jane选择凭证属性的一个子集与Bob共享，那么Jane将根据颁发的凭证创建声明。

可见发行者和接收者都要通过SSI进行一个身份的注册，以及声明是接收者对验证者所共享的属性的集合，因此为凭证的子集。

一开始，我也想过，可不可以让发行者对凭证中的每个属性进行签名，然后接收者对属性进行选择性的共享，验证者再对接收到的属性一个一个进行验证。这种想法其实很自然，被称为原子证书，但是也当然有很多问题，这种方法对发行者和验证者增加了成本（即，生成、管理和验证n个签名），以及随着每个凭证的有效载荷的大小增加（高达签名长度的N倍）而产生更高的通信开销。在这篇论文中，提出了一种可编辑签名，凭证仅被签名一次，并且可以生成多个声明，而无需发行者的重新签名或任何第三方交互。另外，发行方和接收方之间的交互的减少的数量可以防止发行方关联接收方的凭证共享活动。接下来我们一起来看看。

可编辑的选择性披露

该部分我认为是全文的重点，设计了一个可验证的数据结构来实现凭证的编辑及验证。分为可编辑签名的生成、编辑和验证功能三部分。

签名生成

（阶段1 -扩展）在每个节点处使用GGM (Goldreich-Goldwasser-Micali)从随机种子L生成伪随机值，向下工作树。

（阶段2 -散列）Merkle树构建使用Merkle树散列向上工作树。叶节点值与来自阶段1的随机值一起被散列。左（L）和右（R）子节点的散列值被连接并散列以生成中间节点。

（阶段3-签名）向上散列树，散列根R被签名以产生σ = Sign 0（R）。  最后，证书C上的扩展签名Sign（C）生成为（L，σ）。

这里的GGM当时看了两天没看明白，屏蔽实现原理，我们可以通俗的理解成一个生成伪随机数的算法，可以组织成一个树状结构向下扩展，其中叶子节点与每个属性值对应，右边为Merkle Hash Tree（MHT），需要注意的就是叶子节点是属性和左边生成的伪随机数的组合哈希。这里要加入伪随机数进行哈希的原理是一般凭证中属性的字段比较简单，破坏者有可能进行反向哈希碰撞对属性值进行破解，加入了伪随机数可以降低碰撞的概率，然而却又出现了新的问题，这里留个悬念，文章结尾处进行讨论。MHT向上哈希后得到Merkle Root，发行者对其进行签名得到σ，然后对σ进行扩展即加入随机种子L得到扩展后的签名（L，σ）。

凭证编辑

我们的设计从两个角度考虑编辑，这取决于哪个实体应该具有更大的灵活性：接收方或发行方。在第一种情况下，接收者可以编辑来自凭证的属性的任何子集。在第二种情况下，发行者可以通过将某些属性设置为“不可编辑”来限制编辑的范围。在发行方需要在其凭证中定义强制性披露组件的情况下，这可能是必要的。

接收方的灵活性

Setup:Setup(1k) → (params,PK, SK)

其中params是公共参数，PK，SK是基于安全参数k的公钥-私钥对。我们假设参数是所有其他算法的隐式输入。这里其实就是一个生成密钥对的函数。

Sign:Sign(SKissuer,C) → (C,S)

该函数将发行者私钥SKissuer和凭证C作为输入。它输出一个凭证签名对（C，S）。S是扩展的可编辑签名并且由（σ，aux）组成，其中σ是签名并且aux是关于编辑的辅助信息（例如，GGM树构建的种子L）。生成过程就是签名的签名生成，不再赘述。。

注意，在对凭证进行签名之后，发行方将为了保密性，将被散列的凭证存储在区块链上作为凭证发行的记录。

Redact:Redact(PKissuer,C,σ,aux, rm) →(C‘,σ,aux’)

此函数接受发行方公钥PKissuer，C、C的签名σ、辅助编辑信息aux、要被移除的凭证属性rm，并且如下进行：

1)对于所有凭证属性a[i] ∈ rm（i = l..n），do：

（a）从C中移除a[i]以生成C‘（⊆C）

（B）生成a[i]的散列值，hai = H（a[i]），然后

（c）通过包括hai以及a[i]的索引来将aux更新为aux‘。

2)通过包含不属于rm的属性来生成最终的aux‘。

最后，它返回声明C‘和更新的扩展可编辑签名S’，该签名由签名σ和更新的aux‘组成.其中要注意的就是这个aux，aux为auxiliary的缩写即辅助信息，这里就是用于存储辅助信息的集合，比如一开始会存入随机种子L，在这里的编辑函数又加入了ai的哈希以及索引以便后续验证操作。

Verify:Verify(C‘,σ,aux’) → b

此函数接受编辑的凭证C‘，签名σ和aux’作为输入，并且：

1）对于每个公开的属性a[i]计算H（a[i]）。对于每个编辑过的属性a[j]，从aux‘中获取其散列值，其中（i，j = l.n，i = j）。

2)使用上一步的哈希值重建Merkle树。

3)检查σ是否是Merkle树的根上相对于发行者公钥的有效签名。

它返回一个布尔位b ∈（0，1），说明C‘是否被接受。这里的验证其实就是对于共享的属性计算其哈希值，对于不共享的属性即编辑过的属性直接从aux‘中获取其哈希值，然后从aux’中的随机种子L生成对应随机数以重新构建MHT获得Merkle Root，与输入σ进行一个验证即可判断接收者所共享的属性有没有进行一个篡改操作。

发行方的灵活性

Sign. Sign(SKissuer,C,rdt) → (C,S).

此函数接受SKissuer、C和可编辑属性rdt，其中rdt ⊆ C。它输出凭证-签名对（C，S）。重要的是，该函数还将所有强制属性的列表（即，a[i] ∉ rdt）写入在凭证头部。

与之前的方法类似，在对凭证进行签名之后，发行方将散列的凭证存储在区块链上。这样做允许验证者访问凭证的头部以检索凭证的强制属性列表。

Redact. Redact(PKissuer,C,σ,aux, rdt,rm) →(C‘  ,σ,aux’).

此函数接受具有签名S的PKissuer，C、可编辑属性rdt和要删除的属性rm。首先，如果rm∉rdt，则该函数中止。它输出具有更新的扩展可编辑签名S‘ =（σ，aux’）和声明C‘。

Verify. Verify(C‘,σ,aux’) → b.

该函数采用C‘、σ和aux’作为输入，并且经由在先前方法中描述的相同过程来验证凭证。可选地，验证者可以选择通过查找存储在区块链中的凭证的头部来进一步验证接收者是否已经公开了所有强制属性。

这里的函数实现和前面类似，不过多赘述，就是多了强制属性列表，接收者必须对其进行共享。

credchain架构

基于以上，这篇文章提出了credchain架构，下面大致对其进行介绍。

凭证共享服务

        该架构，如图所示，由两部分组成：SSI平台和去中心化应用层，其为用户提供使用客户端钱包应用与区块链网络交互的手段。每个注册发行方管理身份和事实数据存储库(Identity and Fact Data Repository)以存储接收方的身份数据和事实（例如，Jane’s课程注册数据存储在University X）和一个名为Verifiable Credential的云存储器中存储和共享生成的证书。SSI平台包括两层：数据层和服务层。数据层包括链上数据（注册表智能合约）。服务层包括账户服务（用于区块链账户管理）、DID服务（用于管理DID）、发行方服务（用于管理发行方签署凭证的资格）和凭证服务（用于管理凭证）。请注意，该架构的核心是服务层，该服务层抽象并公开了所有必要的功能，以在基于区块链的SSI平台中管理身份。

凭据管理的工作流

标识符注册。在SSI平台中创建账户会生成区块链账户、密钥对，并为用户注册新的DID。密钥对主要用于对凭据进行签名。在成功注册时，DID注册智能合约被启动以存储DID和相关联的DDO。我们假设发行方已经在系统中注册，并且在获得平台所有者的批准后，他们的信息存储在另一个智能合约发行方注册表中。其中DID为Decentralized IDentity即去中心化标识符。

凭证发放。对于凭证发放，分为身份确认和凭证发放两部分。首先，参与者使用具有在区块链上注册的凭证的身份来彼此标识自己，并且经由DApp服务器通信，如图所示。过程开始于接收者（1）向DApp服务器发送访问请求和他的DID以及与发行方相关的信息（例如，在我们的场景中，Jane可以发送大学X的学生ID）。DApp服务器（2）收集发行方标识细节，并且（3）将访问请求转发给该发行方。发行方对照来自身份和事实数据储存库的课程注册数据验证接收方的信息，并且从提供的DID获得接收方的服务端点，然后（4）经由DApp服务器向接收方（5）发送接受通知。

        在已经建立身份之后，如图所示。接收方（1）向DApp服务器发送对凭证的请求。服务器（2）对照DID注册表验证身份，并且（3）将请求沿着接收者的DID一起转发到发行者。在接收到凭证请求时，发行方从其身份和事实数据存储库获取相关数据并创建凭证C。然后，颁发者从SDA调用函数Sign（）以对生成的凭证进行签名。接下来，发行方（4）创建区块链交易以将签名凭证的散列存储在凭证注册表中作为发行的记录。之后，发行方将凭证上传到其私有云存储Verifiable Credential并生成可共享链接，然后（5）通过DApp服务器将其发送给接收方，然后（6）通知接收方。接收者继而可以查看凭证并且（7）将其下载到他们的电子邮件设备.链接使用收件人的公钥加密，以确保凭证仅可由正确的收件人访问。

选择性披露和验证。接收者可以通过从SDA调用函数Redact（）来编辑凭证中的一些属性。经编辑的凭证（声明）被存储在接收者的私有云存储上，并且为验证者生成可共享链接，与声明一起。平台基于接收者定义的可访问时间限制（例如，可访问时间限制）声明生成JSON Web令牌（JWT），如接下来的七天。这个JWT允许接收者指定验证者对共享数据的访问时间。向验证者发送具有指定访问周期的声明的链接及其相关联的JWT。最后，验证者获取JWT和声明，以从凭证服务调用Verification模块。该模块首先解码JWT并检查访问周期是否有效，然后调用Verify（）来验证声明的真实性和完整性。此处文章中没有给出相应的解释图。

再后面就是实现、测试等部分，此处不过多介绍，想要进一步了解的此处给出链接：

https://ieeexplore.ieee.org/document/9343074

总结

        本文提出了一种基于区块链的SSI凭证共享架构，称为CredChain，重点关注隐私。我们提出了一个选择性的公开方案，利用可编辑签名的上下文创建和验证证书的效率和灵活性。我们通过在CredChain用于共享学术证书的实例，分析了该架构的隐私和安全方面，并在吞吐量和延迟方面给出了核心组件的性能测量。

潜在问题

        前面留下了一个疑问，就是在签名生成过程中，本文实现方案是将随机种子L暴露给验证者的，这里详细探讨以下。之所以加入伪随机数进行哈希是因为属性字段过于简单，防止攻击者反向哈希碰撞，然而暴露随机种子的做法使得攻击者也可以获得相应伪随机数，那么原本的目的是不是并未达到，攻击者仍有一定概率可以实现反向哈希碰撞，这里是一个潜在的问题。

个人总结及感想

        通过阅读师姐的论文以及本文，对如何实现数据的选择性披露以及有了一个初步的想法，其中关键就是设计一个可验证的数据结构（ADS），确定按何粒度对数据进行划分，划分好后接收者如何对数据进行一个选择性的共享披露，然后验证者如何对编辑后的数据进行一个验证，本文设计的是GGM和MHT的结合，虽然有潜在问题，但能大致满足功能。然后就是对系统中的用户进行身份的验证，本文使用了SSI平台进行实现。再其他就是一些应用场景的实现。因此后续就是着重于如何设计一个高效安全的可验证的数据结构来实现选择性披露。以上就是个人的一些总结。

第一次编写，有不足之处还请多多谅解。对于选择性披露方向有高明见解还请多多指教~