一种基于区块链的多方公平PDF合同签署方法与流程

本发明涉及信息安全领域，特别是涉及一种区块链应用技术，用于完成多方公平pdf合同签署。

背景技术

公平的合同签署是指参与合同签署的双方或者多方要么同时都能得到有各方签名的合同，要么都得不到有效合同的签名。该问题研究的很早，在密码应用技术领域一直是受到关注的，从早期的纯粹双方的公平合同签署，到后来的基于第三方的公平合同签署协议，人们给出了多种有趣有效的解决方案。

然而，理论的研究成果在应用到pdf合同签署时，却出现了障碍。pdf合同签署设计上是一个各方顺序签名的技术，即后序合同签署方的签名包含前序合同签署方的签名，另外pdf规范按照自己定义的数字签名方法，每次签名时都会增加一些辅助的数据。这样的特性，使得传统的对于同一个文档进行的交换数字签名的技术失去了效用。

田海博等人提出了一种满足便携文档格式的公平多方合同签署协议，2018年发表在期刊《西电学报》第45卷第1期。该方法采用了可验证加密签名(ves)方案，提出了分布式哈希的计算方法，给出了多方公平签署合同的过程。然而，该方法后序合同签署方需要传递前序合同签署方的数字签名，且ttp需要在线参与到多方合同签署的过程中，协助完成检查，对ttp的要求较高，容易造成瓶颈。

技术实现要素：

针对当前方法对ttp依赖较强，效率较低，存在的通信和性能瓶颈的问题，本发明引入区块链技术，把各方的ves和分布式哈希所涉及的状态量存储到区块链中，并融合进一个群组密钥协商协议gka，用于向区块链中存储加密的数字签名，确保合同签署各方关于合同内容和合同签名的隐私性，最终实现了一个基于区块链的多方公平合同签署方法。

本发明的目的在于设计一种基于区块链的公平多方pdf合同签署方法，本发明利用区块链可信存储、可信计算等特点，使得ttp完全成为离线第三方，提高协议整体执行的效率。

为实现上述目的，本发明给出如下方法：

一种基于区块链的多方公平pdf合同签署方法，包括多名合同签署方p1，…，pn，n为大于1的整数，一个可信第三方ttp及区块链节点，所述各个合同签署方协商一致的pdf合同m0，包括以下步骤：

s1)p1生成所述pdf合同m0的数字签名可验证加密签名ves1，计算合同内容的哈希上下文ctx1，生成群组密钥协商协议gka的元素ge1，把ves1、ctx1和ge1封装为区块链交易，发送给任意区块链节点；

s2)由p2开始，i按照由2至n升序，pi验证pi-1(1<i≤n)的vesi-1签名，若验证失败退出协议，若验证成功则pi生成数字签名vesi、ctxi、gei并通过区块链交易发送给任意区块链节点；

s3)在pn完成操作后，以pj(1≤j≤n)代表所述合同签署方p1，…，pn，pj验证其它未验证的ves签名，如果验证失败，退出协议，否则计算群组加密密钥gk，加密pdf文档的数字签名形成密文cj，把cj封装为交易发送给任意区块链节点；

s4)pj查询区块链数据，用gk解密其它合同签署方的密文，1≤j≤n，合成各方顺序签署的pdf合同；

s5)pj在合成pdf合同过程中出现异常时与ttp通信，完成异常处理流程。

上述步骤1)包括：

s11)所述合同签署方p1所采用的是各个所述合同签署方协商一致的ves方案(ves.gen，ves.sign，ves.verify)，所述合同签署方p1通过ves.gen算法生成所述合同签署方p1的签名公私钥对

s12)所述合同签署方p1使用作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(gen，sign，verify)中的数字签名算法sign签署pdf合同m0，得到其中mp1和是所述合同签署方p1根据pdf数字签名规范所生成的附属信息，mp1为空或不为空，符号“||”是二进制比特串的串接操作；

s13)所述合同签署方p1计算其中pkttp是ttp兼容ves方案的公钥，设置

s14)所述合同签署方p1合成含有其数字签名的pdf合同采用各个所述合同签署方协商一致的哈希方案(hash.init，hash.update，hash.final)，计算hash.init，计算计算完成后设置此时的哈希缓存为ctx1；

s15)所述合同签署方p1采用各个所述合同签署方协商一致的gka方案(gka.gen，gka.ka)，其中gka.gen与区块链节点所采用数字签名方案(bc.gen,bc.sign,bc.verify)中的bc.gen算法兼容，之后按照gka.ka算法计算ge1；其中(bc.gen,bc.sign,bc.verify)表示在本发明技术方案中区块链节点适用的任意一种数字签名方案；

s16)所述合同签署方p1把ves1、ctx1和ge1封装为区块链交易的数据，把交易发送给区块链节点。

上述步骤2)包括：

s21)所述pi-1的ves签名是采用各个所述合同签署方协商一致的ves方案(ves.gen，ves.sign，ves.verify)中的ves.sign算法生成的，pi通过ves.gen算法生成签名公私钥对

s22)所述pi采用ves.verify算法验证ves签名，如果该算法返回假，则停止执行协议，否则继续；

s23)所述pi使用pi-1，…，p1所分别提供的vesi-1，…，ves1之中的附属信息合成准文档其中是长度分别为的全0比特串，然后按照pdf数字签名规范生成附属信息和之后定义pi使用各个所述合同签署方协商一致的哈希方案(hash.init，hash.update，hash.final)，计算hash.init，计算后用pi-1提供的ctxi-1替换此时形成的哈希缓存，之后计算计算hash.final得到的哈希值，之后pi使用作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(gen，sign，verify)中的数字签名算法sign签署内容得到其中sign算法是先求哈希后计算签名的构造方法，实际计算签名时直接对的哈希值签名；

s24)所述pi计算其中pkttp是ttp兼容ves方案的公钥，设置

s25)所述pi采用各个所述合同签署方协商一致的哈希方案(hash.init，hash.update，hash.final)，计算hash.init，计算后用ctxi-1替换此时形成的哈希缓存，之后计算计算完成后设置此时的哈希缓存为ctxi；

s26)所述pi采用各个所述合同签署方协商一致的gka方案(gka.gen，gka.ka)，其中gka.gen与区块链节点所采用数字签名方案(bc.gen,bc.sign,bc.verify)中的bc.gen算法兼容，之后按照gka.ka算法计算gei；

s27)所述pi把vesi、ctxi和gei封装为区块链交易的数据，把交易发送给任意区块链节点。

上述步骤3)包括：

s31)所述pj，1≤j≤n，查询区块链节点，确认pn是否完成了操作，如果没有完成，继续等待，否则继续执行；

s32)所述pj查询vesl,，使用各个所述合同签署方协商一致的ves方案(ves.gen，ves.sign，ves.verify)中的ves.verify算法验证vesl，在1<l时，采用ctxl-1辅助完成验证，如果任何一个ves签名验证失败，退出协议，否则继续执行；

其中所述vesl表示当l≠j,j-1,且1≤l≤n时所指代的合同签署方pl的可验证加密签名；

所述ctxl-1表示当l≠j,j-1,且1≤l≤n时所指代的合同签署方pl-1的哈希上下文；

s33)所述pj采用各个所述合同签署方协商一致的的gka方案以各方提交的ge元素为输入，计算群组密钥gk，并采用对称密钥加密算法加密形成密文cj；

s34)所述pj把所述cj封装为区块链交易的数据，把交易发送给任意区块链节点。

上述步骤4)包括：

s41)所述pj向区块链查询vesg，密文cg，1≤g≤n，如果超过了合同签署最大时长，则执行异常处理流程，退出协议；

s42)所述pj采用群组密钥gk，使用对称密钥解密算法解密cg获得明文1≤g≤n；

s43)所述pj使用pdf合同m0，1≤g≤n合成各方顺序签署的pdf合同。

上述步骤5)包括：

s51)所述pj向区块链查询vesg，密文cg,1≤l≤n，如果超过了合同签署最大时长，则向ttp发送仲裁请求，指明要求仲裁的合同签署方，群组密钥gk，描述要求仲裁的原因；例如缺少cg，或者解密后无法验证

s52)所述ttp查询区块链数据，确认pj是遵从协议的，确认要求仲裁的对象尚没有被仲裁过，那么ttp使用自己的私钥，将pj所要求仲裁的合同签署方的ves签名恢复为普通签名，并再次确认被仲裁的原因，把恢复的普通签名加密后形成密文，向区块链中记录此次仲裁事件。

s53)pj用gk解密加密的普通签名，按照步骤43)合成有签名的pdf合同。

上述合同签署方把交易发送给区块链节点的过程如下：

s61)区块链节点运行多方合同签署的智能合约，包含注册，存储等接口；

s62)智能合约通过注册接口确认合同的所有签署人、认可的ttp、签署人的顺序、此次合同签署的唯一编号等信息，并为各个签署人分配存储区；

s63)智能合约通过存储接口存储合同签署方或者ttp的交易数据，并把不同合同签署人生成的不同交易数据存储在为其分配的存储区中，交易数据中应当包含此次合同签署的唯一编号。

本发明技术方案中中为了便于在不同步骤中进行描述和区分，每个数据参数所采用的下标符号i、j、g在各自的取值范围下，均对应于所述的各个相应的合同签署方p1，…，pn。例如，当i＝j＝g＝3时，pi、pj、pg均代表合同签署方p3，其他参数符号如c、ves等，当下标取值相同时也表示同一含义。

本发明具有以下优点：

首先，矿工或者其它第三方通过合同签署方存储到区块链中的数据和运行的智能合约，只能判断有些公钥持有人准备签署一份合同，并不能知晓合同的内容或者各方对合同给出的数字签名，具有隐私保护的属性；其次，合同签署各方如果都诚实的执行协议，各方都可以本地恢复完整的pdf合同，整个过程只需要向区块链存储两次数据即可完成；最后，合同签署各方如果有任何一方不诚实的执行协议，要么各方都没有存储第二轮加密的签名数据，从而都没有获得完整的pdf合同签名或者任何其它合同签署方的有效数字签名，要么各方可以通过可信第三方恢复不诚实合同签署方的数字签名，各方都获得完整的pdf合同签名，协议是公平的。

本发明所提供的一种基于区块链的多方公平pdf合同签署方法，可以作为基于以太坊的分布式应用或者其它支持智能合约或者脚本技术区块链的一个应用，并且可以进一步增加代币或者令牌机制，激励合同签署方和ttp按照协议执行，形成更为完善的公平多方pdf合同签署应用，广泛用于电子商务、电子政务、金融科技等领域需要签署电子合同的场景中。

附图说明：

图1是基于区块链的公平多方pdf合同签署，实线表示正常的协议执行流程，图中以p1为例展示了各个合同签署方向区块链节点发送的交易情况，双箭头实线表明各个合同签署方都会与区块链节点交互；虚线表示异常处理的流程，各个合同参与方都可能与ttp通信以处理异常，ttp需要与区块链节点通信验证交易，记录处理流程。

具体实施方式：

实施例1：

设多名合同签署方p1，…，pn、一个可信第三方ttp及以太坊区块链节点。每个合同签署方具有以太坊数字签名的公私钥。以太坊采用了ecdsa数字签名方案，椭圆曲线是secp-256k1。每个合同签署方的数字签名方案(bc.gen,bc.sign,bc.verify)就代表ecdsa中相应的密钥生成算法，签名算法和签名验证算法。每个合同签署方的区块链公钥和私钥都使用ecdsa的密钥生成算法得到。例如，p1的私钥表示为：

s:8b9519e7f1dd9fa5d47ebf205bfd7dd800c404a0b7aa1991dae344118f7713aa；

公钥相应的表示为：

x:2da31c6cd1cd7dd0f43299bf01676731b1ab40217b659c13ac2a5726a3f9ab1

y:390a7665a6dc1505af34261bc9309fc56d0417984c10c7102f37355d02119cb9；

各个合同签署方使用协商一致的gka算法，其密钥生成算法gka.gen与ecdsa的密钥生成算法相同。gka.ka的算法描述如下：设p1，…，pn按照其在以太坊中注册的顺序排序，首尾相连，那么p1计算与其两个邻居的ecdh共享密钥和计算例如n＝4，h采用sha-256哈希算法，那么p4的公钥为：

x:4e5e993fedca03957105c1d44a92aea51a4c99eb271697ff84eac558ed9d7662

y:720900b851ac216de89961cf5c04fdee087dda91f53ef7dd6645a9795d27b5a8

p2的公钥为：

x:990c9521257d44e193d9ad561c05c63e8942f053a2d520d0aa226d34034d8d60

y:c0f994ef2befa8ba9add5871ca958d6d01d045726ffaaa1419f3d5bd9bc3141a

sk12的十六进制表达是

a889d164a8b780903e7b53baaeb37ee3b173411ffb9b30eef53de56e2ce1810d

sk14的十六进制表达是

7830037e35981a16f1c4e242cb862e1576bd4e6a906c2b7cdea49abcb3e78037

ge1的十六进制表达是

6a96557bcb3e9165fa760a8d5c9cf4322bab6393f8284d72c6f243c359245981

这样，当各合同签署方都提交了各自的ge元素后，每一个合同签署方可以用自己与邻居的ecdh(椭圆曲线diffie-hellman)秘密值计算所有其它合同签署方哈希之后的秘密值，进而，可以得知每个合同签署方的加密密钥。gka.ka算法的正式描述见zhao等人2011年在《adhocnetworks》期刊中的dasgka实例。

可验证加密签名ves方案可以采用ateniese在2004年发表在《acmtransactionsoninformationandsystemsecurity》期刊中的rsa-ves方案，这样各合同签署方都具有rsa签名算法的公钥和私钥。pdf签名采用adobe公司在pdf1.7中给出的签名规范，同样选择rsa签名算法。满足ves方案(ves.gen，ves.sign，ves.verify)和数字签名方案(gen，sign，verify)兼容的需求。

采用以太坊智能合约，意味着各合同签署方和ttp拥有以太坊钱包客户端，可以生成和发送交易，可以查询以太坊区块链数据；同时意味着存在一个以太坊智能合约，使得各合同签署方可以通过智能合约完成注册和数据存储。在本实施例中，我们采用扩展的钱包客户端，采用solidity语言开发智能合约，提供注册register和存储store两个接口。合同签署各方通过注册接口确认合同签署的意向，得到合同签署的唯一编号，确认各方认可的ttp、确认各签署人的签名顺序、并为各个签署人分配存储区。合同签署方或者ttp通过存储接口store存储交易中的数据字段，并把不同合同签署人生成的不同交易数据存储在为其分配的存储区中，交易数据中应当包含此次合同签署的唯一编号。

ttp除拥有扩展的以太坊钱包之外，还需要打开服务程序，接受合同签署方的仲裁请求，提供仲裁服务。

哈希方案(hash.init，hash.update，hash.final)在本具体实施例1采用sha256哈希方案。

下面描述n＝4时各方签署合同的实施过程：

各合同签署方通过以太坊智能合约的注册接口确认各方顺序等信息，设定合同签署方顺序为p1、p2、p3、p4，可信第三方为ttp，区块链节点是钱包客户端连接的任意以太坊节点，之后，

1)p1生成合同的数字签名可验证加密签名ves1，计算合同内容的哈希上下文ctx1，生成群组密钥协商协议(gka)的元素ge1，把ves1、ctx1和ge1封装为区块链交易，发送给区块链节点，具体包括：

11)p1所签署的pdf合同是p1、p2、p3、p4协商一致的，称为m0，p1采用rsa-ves方案，p1通过rsa-ves的密钥生成算法生成p1的签名公私钥对

12)p1使用作为rsa签名密钥，按照pdf规范采用itextpdf库文件通过扩展的钱包客户端完成pdf合同的签署，生成的数字签名是通过对比签过名的pdf文档和原始未签名的pdf文档的比特序列，获得包含签名字段的比特序列，之后减去签名的比特序列，获得mp1和

13)p1通过扩展的钱包客户端通过rsa-ves算法获得可验证加密签名，签署内容为ttp的公钥也由rsa-ves算法提供，设签署的ves签名表示为设置

14)p1采用sha256方案，首先对其初始化，然后执行更新操作，更新输入的比特序列是含有p1签名的完整pdf文档，更新之后，读取缓存的比特序列，形成ctx1；

15)p1采用前述的gka方案，生成与左右邻居的ecdh共享秘密sk14和sk12，计算

16)p1把ves1、ctx1和ge1封装为以太坊交易的数据，调用智能合约的store接口，把交易发送给以太坊区块链节点，交易发送时遵照以太坊客户端的规范，用ecdsa数字签名算法签名。

2)p2验证p1的ves签名，验证失败退出协议，否则p2生成新的数字签名ves2、ctx2、ge2并通过交易发给区块链节点，具体实施时，

21)p1的ves签名是采用rsa-ves方案中的签名算法生成的，p2通过该方案的密钥生成算法生成rsa签名的公私钥对

22)p2采用p1的rsa公钥，ttp的rsa公钥，并用pdf合同m0和ves1中的mp1和合成ves签署的比特序列，采用rsa-ves方案的签名验证算法验证p1的ves签名，如果该算法返回假，表明p1没有提交有效的数字签名，则停止执行协议，否则继续；

23)p2获取p1的附属信息mp1和按照pdf规范把mp1和与m0合成一个pdf文档，并采用0填充p1的数字签名的字段，形成与p1签完名之后完全相同长度的准文档之后采用itextpdf库文件通过扩展的钱包客户端按照pdf规范继续完成pdf合同的签署，形成和得到之后p2初始化sha256算法，然后依赖p1提供的ctx1替换sha256的缓存内容，之后更新输入填充后得到最终的哈希值，之后p2使用作为签名密钥，使用rsa数字签名算法直接签署pdf合同的哈希值，得到

24)p2根据重新计算的哈希值，按照rsa-ves的ves签名方案计算p2的ves签名设置

25)p2初始化sha256方案，用ctx1的比特序列替换初始化之后的比特序列，并更新输入的比特序列，把此时sha256的缓存内容设置为ctx2；

27)p2采用前述的gka方案，生成与左右邻居的ecdh共享秘密sk21和sk23，计算

28)p2把ves2、ctx2和ge2封装为以太坊交易的数据，调用智能合约的store接口，把交易发送给以太坊区块链节点，交易发送时遵照以太坊客户端的规范，用ecdsa数字签名算法签名。

3)p3验证p2的ves签名，验证失败退出协议，否则p3生成新的数字签名ves3、ctx3、ge3并通过交易发给区块链节点，具体实施过程与p2的实施过程类似，其中

4)p4验证p3的ves签名，验证失败退出协议，否则p4生成新的数字签名ves4、ctx4、ge4并通过交易发给区块链节点，具体实施过程与p2的实施过程类似，其中

5)p1验证p2、p3、p4的ves签名，需要计算比特序列的哈希值，其中的比特序列p1可以直接从ves2的内容构造出来，的比特序列无法恢复，需要使用步骤23)类似的方法，采用ctx2与ves3的内容计算其哈希值，哈希值的计算方法与类似；此时，采用rsa-ves的验证算法，p1可以验证p2、p3、p4的ves签名，如果任何一个签名验证失败，退出协议；否则计算群组加密密钥gk，计算方法是计算gk＝sha256(sha256(sk12)||sha256(sk23)||sha256(sk34)||sha256(sk14))，然后采用aes256-ctr加密形成c1，把c1封装为交易，调用store接口，采用p1的以太坊私钥，采用ecdsa数字签名签署，之后发给以太坊节点；

6)p2验证p3、p4的ves签名，计算比特序列的哈希值，计算过程与步骤5)类似，如果任何一个签名验证失败，退出协议；否则计算群组加密密钥gk，计算方法是计算gk＝sha256(sha256(sk21)||sha256(sk23)||sha256(sk34)||sha256(sk41)),然后采用aes256-ctr加密形成c2，把c2封装为交易，调用store接口，采用p2的以太坊私钥，采用ecdsa数字签名签署，之后发给以太坊节点；

7)p3验证p1，p4的ves签名，计算比特序列的哈希值，计算过程与步骤5)类似，如果签名验证失败，退出协议；否则计算群组加密密钥gk，计算方法是计算gk＝sha256(sha256(sk12)||sha256(sk32)||sha256(sk34)||sha256(sk41)),然后采用aes256-ctr加密形成c3，把c3封装为交易，调用store接口，采用p3的以太坊私钥，采用ecdsa数字签名签署，之后发给以太坊节点；

8)p4验证p1，p2的ves签名，计算比特序列的哈希值，计算过程与步骤5)类似，如果签名验证失败，退出协议；否则计算群组加密密钥gk，计算方法是计算gk＝sha256(sha256(sk12)||sha256(sk23)||sha256(sk43)||sha256(sk41)),然后采用aes256-ctr加密形成c4，把c4封装为交易，调用store接口，采用p4的以太坊私钥，采用ecdsa数字签名签署，之后发给以太坊节点；

9)p1用gk解密cg，2≤g≤4，得到然后用pdf合同m0，vesg,1≤g≤4中的和首先验证解密的数字签名是否正确，验证不通过，认为出现了异常，执行异常处理流程，否则依照pdf合同的规范合成新的pdf文档，获得具有各合同签署方签名的pdf合同；

10)p2、p3、p4获得有签字的pdf合同的过程类似步骤9)。

11)如果在步骤9或者步骤10中，pj，1≤j≤4，发送含有加密数字签名的交易之后开始计时，如果超时后依旧未能获取、或者获取后验证不通过某个或某些合同签署方加密后的数字签名，例如未能获得pi的数字签名，1≤i≠j≤4，那么认为合同签署出现了异常，需要完成异常处理流程；pj向ttp发送仲裁请求，指明pi的以太坊地址，描述原因为超时，同时给出智能合约的地址和pj计算的群组加密密钥gk；

ttp查询智能合约存储的内容，确认pi确实没有发送加密的数字签名，而同时pj是遵守协议的，即发送了加密的数字签名，且解密后与vesj中的ves签名恢复后的数字签名相同，且pi的ves签名从来没有恢复过，此时ttp受理仲裁，恢复vesi中的ves签名为普通签名，如果仲裁的描述原因是数字签名不正确，需要对比恢复的数字签名和描述的数字签名是否一致，一致则不再处理，否则使用gk加密后形成ci，并把仲裁事件和ci一起形成交易，调用智能合约的store接口，发送给区块链节点；

此后，pj获取ci，解密后类似步骤9)合成pdf文档。

实施例2：

实施例2与实施例1基本相同，不同之处在于实施例2运行在qtum、fabric等智能合约平台中。

实施例3：

实施例3与实施例1基本相同，不同之处在于实施例3采用了dsa数字签名、dsa-ves可验证签名、sha-3-256哈希方案等具体方案。

实施例4：

实施例4与实施例1基本相同，不同之处在于实施例4的合同签署人数不是4人，而是3人或者5到100中的任意人数。

实施例5：

实施例5与实施例1基本相同，不同之处在于实施例5采用了aes-cbc，aes-ecb，aes-cfb，aes-ofb或者其他包括但不限于idea，3des等加密算法加密了pdf合同的数字签名。