CN108833115B - 一种基于区块链的多方公平pdf合同签署方法 - Google Patents

一种基于区块链的多方公平pdf合同签署方法 Download PDF

Info

Publication number
CN108833115B
CN108833115B CN201810634852.4A CN201810634852A CN108833115B CN 108833115 B CN108833115 B CN 108833115B CN 201810634852 A CN201810634852 A CN 201810634852A CN 108833115 B CN108833115 B CN 108833115B
Authority
CN
China
Prior art keywords
ves
contract
block chain
hash
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810634852.4A
Other languages
English (en)
Other versions
CN108833115A (zh
Inventor
田海博
何杰杰
刘佳南
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Xinruiji Technology Beijing Co ltd
Original Assignee
Sun Yat Sen University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Yat Sen University filed Critical Sun Yat Sen University
Priority to CN201810634852.4A priority Critical patent/CN108833115B/zh
Publication of CN108833115A publication Critical patent/CN108833115A/zh
Application granted granted Critical
Publication of CN108833115B publication Critical patent/CN108833115B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Power Engineering (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

本发明涉及一种基于区块链的多方公平PDF合同签署方法，参与者包括多名合同签署方P1，…，Pn，一个可信第三方TTP及区块链节点。首先P1生成合同的可验证加密签名VES1，计算合同内容的哈希上下文CTX1，生成群组密钥协商协议GKA的元素GE1，把VES1、CTX1和GE1封装为区块链交易，发送给区块链节点；然后Pi验证Pi‑1的VESi‑1，1<i≤n，验证通过后Pi生成新的VESi、CTXi和GEi并通过交易发给区块链节点；Pn完成操作后，Pj计算群组加密密钥GK，1≤j≤n，加密PDF文档的数字签名形成密文Cj，把Cj封装为交易发给区块链节点；Pj查询区块链数据，并用GK解密后合成完整的PDF合同；Pj如果超时后未能获得区块链数据，与TTP通信处理异常。本发明对TTP的依赖较弱，效率更高。

Description

一种基于区块链的多方公平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的数字签名
Figure BDA0001697851240000011
可验证加密签名VES1，计算合同内容的哈希上下文CTX1，生成群组密钥协商协议GKA的元素GE1，把VES1、CTX1和GE1封装为区块链交易，发送给任意区块链节点；
S2)由P2开始，i按照由2至n升序，Pi验证Pi-1(1<i≤n)的VESi-1签名，若验证失败退出协议，若验证成功则Pi生成数字签名
Figure BDA0001697851240000021
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的签名公私钥对
Figure BDA0001697851240000022
S12)所述合同签署方P1使用
Figure BDA0001697851240000023
作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(Gen，Sign，Verify)中的数字签名算法Sign签署PDF合同m0，得到
Figure BDA0001697851240000024
其中mP1和
Figure BDA0001697851240000025
是所述合同签署方P1根据PDF数字签名规范所生成的附属信息，mP1为空或不为空，符号“||”是二进制比特串的串接操作；
S13)所述合同签署方P1计算
Figure BDA0001697851240000026
其中pkTTP是TTP兼容VES方案的公钥，设置
Figure BDA0001697851240000027
S14)所述合同签署方P1合成含有其数字签名
Figure BDA0001697851240000028
的PDF合同
Figure BDA0001697851240000029
采用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算
Figure BDA00016978512400000210
计算完成后设置此时的哈希缓存为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算法生成签名公私钥对
Figure BDA0001697851240000031
S22)所述Pi采用VES.Verify算法验证VES签名，如果该算法返回假，则停止执行协议，否则继续；
S23)所述Pi使用Pi-1，…，P1所分别提供的VESi-1，…，VES1之中的附属信息
Figure BDA0001697851240000032
Figure BDA0001697851240000033
合成准文档
Figure BDA0001697851240000034
其中
Figure BDA0001697851240000035
是长度分别为
Figure BDA0001697851240000036
的全0比特串，然后按照PDF数字签名规范生成附属信息
Figure BDA0001697851240000037
和
Figure BDA0001697851240000038
之后定义
Figure BDA0001697851240000039
Pi使用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算后用Pi-1提供的CTXi-1替换此时形成的哈希缓存，之后计算
Figure BDA00016978512400000310
计算Hash.final得到
Figure BDA00016978512400000311
的哈希值，之后Pi使用
Figure BDA00016978512400000312
作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(Gen，Sign，Verify)中的数字签名算法Sign签署内容
Figure BDA00016978512400000313
得到
Figure BDA00016978512400000314
其中Sign算法是先求哈希后计算签名的构造方法，实际计算签名时直接对
Figure BDA00016978512400000315
的哈希值签名；
S24)所述Pi计算
Figure BDA00016978512400000316
其中pkTTP是TTP兼容VES方案的公钥，设置
Figure BDA00016978512400000317
S25)所述Pi采用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算后用CTXi-1替换此时形成的哈希缓存，之后计算
Figure BDA00016978512400000318
计算完成后设置此时的哈希缓存为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，并采用对称密钥加密算法加密
Figure BDA0001697851240000041
形成密文Cj；
S34)所述Pj把所述Cj封装为区块链交易的数据，把交易发送给任意区块链节点。
上述步骤4)包括：
S41)所述Pj向区块链查询VESg，密文Cg，1≤g≤n，如果超过了合同签署最大时长，则执行异常处理流程，退出协议；
S42)所述Pj采用群组密钥GK，使用对称密钥解密算法解密Cg获得明文
Figure BDA0001697851240000042
1≤g≤n；
S43)所述Pj使用PDF合同m0，
Figure BDA0001697851240000043
1≤g≤n合成各方顺序签署的PDF合同。
上述步骤5)包括：
S51)所述Pj向区块链查询VESg，密文Cg,1≤l≤n，如果超过了合同签署最大时长，则向TTP发送仲裁请求，指明要求仲裁的合同签署方，群组密钥GK，描述要求仲裁的原因；例如缺少Cg，或者解密后无法验证
Figure BDA0001697851240000044
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的私钥
Figure BDA0001697851240000061
表示为：
S:8b9519e7f1dd9fa5d47ebf205bfd7dd800c404a0b7aa1991dae344118f7713aa；
公钥
Figure BDA0001697851240000062
相应的表示为：
X:2da31c6cd1cd7dd0f43299bf01676731b1ab40217b659c13ac2a5726a3f9ab1
Y:390a7665a6dc1505af34261bc9309fc56d0417984c10c7102f37355d02119cb9；
各个合同签署方使用协商一致的GKA算法，其密钥生成算法GKA.Gen与ECDSA的密钥生成算法相同。GKA.KA的算法描述如下：设P1，…，Pn按照其在以太坊中注册的顺序排序，首尾相连，那么P1计算与其两个邻居的ECDH共享密钥
Figure BDA0001697851240000063
和
Figure BDA0001697851240000064
计算
Figure BDA0001697851240000065
例如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年在《Ad Hoc Networks》期刊中的DASGKA实例。
可验证加密签名VES方案可以采用Ateniese在2004年发表在《ACM Transactionson Information and System Security》期刊中的RSA-VES方案，这样各合同签署方都具有RSA签名算法的公钥和私钥。PDF签名采用Adobe公司在PDF 1.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生成合同的数字签名
Figure BDA0001697851240000071
可验证加密签名VES1，计算合同内容的哈希上下文CTX1，生成群组密钥协商协议(GKA)的元素GE1，把VES1、CTX1和GE1封装为区块链交易，发送给区块链节点，具体包括：
11)P1所签署的PDF合同是P1、P2、P3、P4协商一致的，称为m0，P1采用RSA-VES方案，P1通过RSA-VES的密钥生成算法生成P1的签名公私钥对
Figure BDA0001697851240000072
12)P1使用
Figure BDA0001697851240000073
作为RSA签名密钥，按照PDF规范采用itextpdf库文件通过扩展的钱包客户端完成PDF合同的签署，生成的数字签名是
Figure BDA0001697851240000074
通过对比签过名的PDF文档和原始未签名的PDF文档的比特序列，获得包含签名字段的比特序列，之后减去签名的比特序列，获得mP1和
Figure BDA0001697851240000075
13)P1通过扩展的钱包客户端通过RSA-VES算法获得可验证加密签名，签署内容为
Figure BDA0001697851240000076
TTP的公钥也由RSA-VES算法提供，设签署的VES签名表示为
Figure BDA0001697851240000077
设置
Figure BDA0001697851240000078
14)P1采用SHA256方案，首先对其初始化，然后执行更新操作，更新输入的比特序列是含有P1签名的完整PDF文档，更新之后，读取缓存的比特序列，形成CTX1；
15)P1采用前述的GKA方案，生成与左右邻居的ECDH共享秘密SK14和SK12，计算
Figure BDA0001697851240000081
Figure BDA0001697851240000082
16)P1把VES1、CTX1和GE1封装为以太坊交易的数据，调用智能合约的Store接口，把交易发送给以太坊区块链节点，交易发送时遵照以太坊客户端的规范，用ECDSA数字签名算法签名。
2)P2验证P1的VES签名，验证失败退出协议，否则P2生成新的数字签名
Figure BDA0001697851240000083
VES2、CTX2、GE2并通过交易发给区块链节点，具体实施时，
21)P1的VES签名是采用RSA-VES方案中的签名算法生成的，P2通过该方案的密钥生成算法生成RSA签名的公私钥对
Figure BDA0001697851240000084
22)P2采用P1的RSA公钥，TTP的RSA公钥，并用PDF合同m0和VES1中的mP1和
Figure BDA0001697851240000085
合成VES签署的比特序列，采用RSA-VES方案的签名验证算法验证P1的VES签名，如果该算法返回假，表明P1没有提交有效的数字签名，则停止执行协议，否则继续；
23)P2获取P1的附属信息mP1和
Figure BDA0001697851240000086
按照PDF规范把mP1和
Figure BDA0001697851240000087
与m0合成一个PDF文档，并采用0填充P1的数字签名的字段，形成与P1签完名之后完全相同长度的准文档
Figure BDA0001697851240000088
之后采用itextpdf库文件通过扩展的钱包客户端按照PDF规范继续完成PDF合同的签署，形成
Figure BDA0001697851240000089
和
Figure BDA00016978512400000810
得到
Figure BDA00016978512400000811
之后P2初始化SHA256算法，然后依赖P1提供的CTX1替换SHA256的缓存内容，之后更新输入
Figure BDA00016978512400000812
填充后得到最终的哈希值，之后P2使用
Figure BDA00016978512400000813
作为签名密钥，使用RSA数字签名算法直接签署PDF合同
Figure BDA00016978512400000814
的哈希值，得到
Figure BDA00016978512400000815
24)P2根据重新计算
Figure BDA00016978512400000816
的哈希值，按照RSA-VES的VES签名方案计算P2的VES签名
Figure BDA00016978512400000817
设置
Figure BDA00016978512400000818
25)P2初始化SHA256方案，用CTX1的比特序列替换初始化之后的比特序列，并更新输入
Figure BDA00016978512400000819
的比特序列，把此时SHA256的缓存内容设置为CTX2；
27)P2采用前述的GKA方案，生成与左右邻居的ECDH共享秘密SK21和SK23，计算
Figure BDA00016978512400000820
Figure BDA0001697851240000091
28)P2把VES2、CTX2和GE2封装为以太坊交易的数据，调用智能合约的Store接口，把交易发送给以太坊区块链节点，交易发送时遵照以太坊客户端的规范，用ECDSA数字签名算法签名。
3)P3验证P2的VES签名，验证失败退出协议，否则P3生成新的数字签名
Figure BDA0001697851240000092
VES3、CTX3、GE3并通过交易发给区块链节点，具体实施过程与P2的实施过程类似，其中
Figure BDA0001697851240000093
4)P4验证P3的VES签名，验证失败退出协议，否则P4生成新的数字签名
Figure BDA0001697851240000094
VES4、CTX4、GE4并通过交易发给区块链节点，具体实施过程与P2的实施过程类似，其中
Figure BDA0001697851240000095
5)P1验证P2、P3、P4的VES签名，需要计算
Figure BDA0001697851240000096
比特序列的哈希值，其中
Figure BDA0001697851240000097
的比特序列P1可以直接从VES2的内容构造出来，
Figure BDA0001697851240000098
的比特序列无法恢复，需要使用步骤23)类似的方法，采用CTX2与VES3的内容计算其哈希值，
Figure BDA0001697851240000099
哈希值的计算方法与
Figure BDA00016978512400000910
类似；此时，采用RSA-VES的验证算法，P1可以验证P2、P3、P4的VES签名，如果任何一个签名验证失败，退出协议；否则计算群组加密密钥GK，计算方法是计算
Figure BDA00016978512400000911
GK＝SHA256(SHA256(SK12)||SHA256(SK23)||SHA256(SK34)||SHA256(SK14))，然后采用AES256-CTR加密
Figure BDA00016978512400000912
形成C1，把C1封装为交易，调用Store接口，采用P1的以太坊私钥，采用ECDSA数字签名签署，之后发给以太坊节点；
6)P2验证P3、P4的VES签名，计算
Figure BDA00016978512400000913
比特序列的哈希值，计算过程与步骤5)类似，如果任何一个签名验证失败，退出协议；否则计算群组加密密钥GK，计算方法是计算
Figure BDA00016978512400000914
GK＝SHA256(SHA256(SK21)||SHA256(SK23)||SHA256(SK34)||SHA256(SK41)),然后采用AES256-CTR加密
Figure BDA00016978512400000915
形成C2，把C2封装为交易，调用Store接口，采用P2的以太坊私钥，采用ECDSA数字签名签署，之后发给以太坊节点；
7)P3验证P1，P4的VES签名，计算
Figure BDA00016978512400000916
比特序列的哈希值，计算过程与步骤5)类似，如果签名验证失败，退出协议；否则计算群组加密密钥GK，计算方法是计算
Figure BDA0001697851240000101
GK＝SHA256(SHA256(SK12)||SHA256(SK32)||SHA256(SK34)||SHA256(SK41)),然后采用AES256-CTR加密
Figure BDA0001697851240000102
形成C3，把C3封装为交易，调用Store接口，采用P3的以太坊私钥，采用ECDSA数字签名签署，之后发给以太坊节点；
8)P4验证P1，P2的VES签名，计算
Figure BDA0001697851240000103
比特序列的哈希值，计算过程与步骤5)类似，如果签名验证失败，退出协议；否则计算群组加密密钥GK，计算方法是计算
Figure BDA0001697851240000104
GK＝SHA256(SHA256(SK12)||SHA256(SK23)||SHA256(SK43)||SHA256(SK41)),然后采用AES256-CTR加密
Figure BDA0001697851240000105
形成C4，把C4封装为交易，调用Store接口，采用P4的以太坊私钥，采用ECDSA数字签名签署，之后发给以太坊节点；
9)P1用GK解密Cg，2≤g≤4，得到
Figure BDA0001697851240000106
然后用PDF合同m0，VESg,1≤g≤4中的
Figure BDA0001697851240000107
和
Figure BDA0001697851240000108
首先验证解密的数字签名是否正确，验证不通过，认为出现了异常，执行异常处理流程，否则依照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合同的数字签名。

Claims (2)

1.一种基于区块链的多方公平PDF合同签署方法，包括多名合同签署方P1，…，Pn，n为大于1的整数，一个可信第三方TTP及区块链节点，所述各个合同签署方协商一致的PDF合同m0，包括以下步骤：
S1)所述合同签署方P1生成所述PDF合同m0的数字签名
Figure FDA0002769489260000011
及附属信息mP1和
Figure FDA0002769489260000012
可验证加密签名VES1，计算合同内容的哈希上下文CTX1，生成群组密钥协商协议GKA的元素GE1，把VES1、CTX1和GE1封装为区块链交易，发送给任意区块链节点；
S2)由合同签署方P2开始，i按照由2至n升序，Pi验证Pi-1，1<i≤n，的VESi-1签名；若验证失败退出协议；若验证成功则Pi生成数字签名
Figure FDA0002769489260000013
及其附属信息
Figure FDA0002769489260000014
和
Figure FDA0002769489260000015
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通信，完成异常处理流程；
所述的步骤S1)包括：
S11)所述合同签署方P1所采用的是各个所述合同签署方协商一致的VES方案(VES.Gen，VES.Sign，VES.Verify)，所述合同签署方P1通过VES.Gen算法生成所述合同签署方P1的签名公私钥对
Figure FDA0002769489260000016
S12)所述合同签署方P1使用
Figure FDA0002769489260000017
作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(Gen，Sign，Verify)中的数字签名算法Sign签署PDF合同m0，得到
Figure FDA0002769489260000018
其中mP1和
Figure FDA0002769489260000019
是所述合同签署方P1根据PDF数字签名规范所生成的附属信息，mP1为空或不为空，符号“||”是二进制比特串的串接操作；
S13)所述合同签署方P1计算
Figure FDA00027694892600000110
其中pkTTP是TTP兼容VES方案的公钥，设置
Figure FDA00027694892600000111
S14)所述合同签署方P1合成含有其数字签名
Figure FDA00027694892600000112
的PDF合同
Figure FDA00027694892600000113
采用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算
Figure FDA0002769489260000021
计算完成后设置此时的哈希缓存为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封装为区块链交易的数据，把交易发送给区块链节点；
所述的步骤S2)包括：
S21)所述Pi-1的VES签名是采用各个所述合同签署方协商一致的VES方案(VES.Gen，VES.Sign，VES.Verify)中的VES.Sign算法生成的，Pi通过VES.Gen算法生成签名公私钥对
Figure FDA0002769489260000022
S22)所述Pi采用VES.Verify算法验证VES签名，如果该算法返回假，则停止执行协议，否则继续；
S23)所述Pi使用Pi-1，…，P1所分别提供的VESi-1，…，VES1之中的附属信息
Figure FDA0002769489260000023
Figure FDA0002769489260000024
合成准文档
Figure FDA0002769489260000025
其中
Figure FDA0002769489260000026
是长度分别为
Figure FDA0002769489260000027
的全0比特串，然后按照PDF数字签名规范生成附属信息
Figure FDA0002769489260000028
和
Figure FDA0002769489260000029
之后定义
Figure FDA00027694892600000210
Pi使用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算后用Pi-1提供的CTXi-1替换此时形成的哈希缓存，之后计算
Figure FDA00027694892600000211
计算Hash.final得到
Figure FDA00027694892600000212
的哈希值，之后Pi使用
Figure FDA00027694892600000213
作为签名密钥，使用各个所述合同签署方协商一致的兼容数字签名方案(Gen，Sign，Verify)中的数字签名算法Sign签署内容
Figure FDA00027694892600000214
得到
Figure FDA00027694892600000215
其中Sign算法是先求哈希后计算签名的构造方法，实际计算签名时直接对
Figure FDA00027694892600000216
的哈希值签名；
S24)所述Pi计算
Figure FDA00027694892600000217
其中pkTTP是TTP兼容VES方案的公钥，设置
Figure FDA00027694892600000218
S25)所述Pi采用各个所述合同签署方协商一致的哈希方案(Hash.init，Hash.update，Hash.final)，计算Hash.init，计算后用CTXi-1替换此时形成的哈希缓存，之后计算
Figure FDA0002769489260000031
计算完成后设置此时的哈希缓存为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封装为区块链交易的数据，把交易发送给任意区块链节点；
所述的步骤S3)包括：
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，并采用对称密钥加密算法加密
Figure FDA0002769489260000032
形成密文Cj；
S34)所述Pj把所述Cj封装为区块链交易的数据，把交易发送给任意区块链节点；
所述的步骤S4)包括：
S41)所述Pj向区块链查询VESg，密文Cg，1≤g≤n，如果超过了合同签署最大时长，则执行异常处理流程；
S42)所述Pj采用群组密钥GK，使用对称密钥解密算法解密Cg获得明文
Figure FDA0002769489260000033
S43)所述Pj使用PDF合同m0，
Figure FDA0002769489260000034
合成各方顺序签署的PDF合同；
所述的步骤S5)包括：
S51)所述Pj向区块链查询VESg，密文Cg,1≤l≤n，如果超过了合同签署最大时长，则执行异常处理流程，向TTP发送仲裁请求，指明要求仲裁的合同签署方，群组密钥GK，描述要求仲裁的原因；
S52)所述TTP查询区块链数据，确认Pj是遵从协议的，确认要求仲裁的对象尚没有被仲裁过，那么TTP使用自己的私钥，将Pj所要求仲裁的合同签署方的VES签名恢复为普通签名，并再次确认被仲裁的原因，把恢复的普通签名加密后形成密文，向区块链中记录此次仲裁事件；
S53)Pj用GK解密TTP加密的普通签名，按照步骤43)合成有签名的PDF合同。
2.根据权利要求1所述的一种基于区块链的多方公平PDF合同签署方法，其特征在于，所述的合同签署方把交易发送给区块链节点的过程如下：
S61)区块链节点运行多方合同签署的智能合约，包含注册、存储接口；
S62)智能合约通过注册接口确认合同的所有签署人、认可的TTP、签署人的顺序、此次合同签署的唯一编号等信息，并为各个签署人分配存储区；
S63)智能合约通过存储接口存储合同签署方或者TTP的交易数据，并把不同合同签署人生成的不同交易数据存储在为其分配的存储区中，交易数据中应当包含此次合同签署的唯一编号。
CN201810634852.4A 2018-06-15 2018-06-15 一种基于区块链的多方公平pdf合同签署方法 Active CN108833115B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810634852.4A CN108833115B (zh) 2018-06-15 2018-06-15 一种基于区块链的多方公平pdf合同签署方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810634852.4A CN108833115B (zh) 2018-06-15 2018-06-15 一种基于区块链的多方公平pdf合同签署方法

Publications (2)

Publication Number Publication Date
CN108833115A CN108833115A (zh) 2018-11-16
CN108833115B true CN108833115B (zh) 2021-01-26

Family

ID=64142615

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810634852.4A Active CN108833115B (zh) 2018-06-15 2018-06-15 一种基于区块链的多方公平pdf合同签署方法

Country Status (1)

Country Link
CN (1) CN108833115B (zh)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109361504B (zh) * 2018-12-04 2021-10-08 桂林电子科技大学 一种基于区块链的多用户通信密钥协商方法
CN109743171B (zh) * 2018-12-06 2022-04-12 广州博士信息技术研究院有限公司 一种解决多方数字签名、时间戳及加密的密钥串联方法
CN110048846B (zh) * 2018-12-12 2020-04-14 阿里巴巴集团控股有限公司 一种基于区块链智能合约的签名验证方法及系统
CN109784917B (zh) * 2018-12-13 2020-11-17 如般量子科技有限公司 基于对称密钥池的抗量子计算区块链保密交易系统和方法
CN109377198B (zh) * 2018-12-24 2022-03-11 上海金融期货信息技术有限公司 一种基于联盟链多方共识的签约系统
CN109919610A (zh) * 2019-01-14 2019-06-21 如般量子科技有限公司 基于p2p公钥池的抗量子计算区块链保密交易方法和系统
CN109919609A (zh) * 2019-01-14 2019-06-21 如般量子科技有限公司 基于公钥池的抗量子计算区块链保密交易方法和系统
CN109617699A (zh) * 2019-01-16 2019-04-12 北京沃东天骏信息技术有限公司 一种密钥生成方法、区块链网络服务平台及存储介质
CN109615378B (zh) * 2019-01-24 2021-06-15 上海点融信息科技有限责任公司 基于区块链的安全多方计算方法、装置及可读存储介质
CN109687979A (zh) * 2019-03-06 2019-04-26 郑州师范学院 一种环签名方法、装置、设备及介质
CN110008754A (zh) * 2019-03-18 2019-07-12 阿里巴巴集团控股有限公司 一种对沟通记录进行区块链存证方法及系统
CN110033269A (zh) * 2019-03-18 2019-07-19 阿里巴巴集团控股有限公司 基于区块链的合同磋商方法及装置、电子设备、存储介质
CN109756349B (zh) * 2019-03-19 2020-12-01 全链通有限公司 基于域名区块链的群组通信方法、区块链节点及介质
TWI704794B (zh) * 2019-03-29 2020-09-11 區塊科技股份有限公司 基於區塊鏈的合約簽核與驗證系統及其實施方法
CN110011795B (zh) * 2019-04-12 2021-07-30 郑州轻工业学院 基于区块链的对称群组密钥协商方法
CN110113157A (zh) * 2019-05-05 2019-08-09 江苏全链通信息科技有限公司 基于区块链的合同处理方法、设备、网络及存储介质
CN109995509B (zh) * 2019-05-08 2021-07-06 西安电子科技大学 基于消息恢复签名的认证密钥交换方法
CN112039821B (zh) * 2019-06-03 2022-09-27 本无链科技(深圳)有限公司 一种基于区块链的群组内私密消息交换方法及系统
CN112084526A (zh) * 2019-06-12 2020-12-15 阿里巴巴集团控股有限公司 基于区块链多重签名的原产地数字证书实现方法及设备
CN110298661B (zh) * 2019-07-01 2023-06-23 贵州大学 基于智能合约的大数据安全公平交换方法
CN110647553B (zh) * 2019-08-02 2022-05-24 广州供电局有限公司 一种基于区块链的电力交易合同管理方法及系统
US11088851B2 (en) 2019-09-04 2021-08-10 Gk8 Ltd Systems and methods for signing of a message
CN111062833A (zh) * 2019-11-26 2020-04-24 青岛大学 一种合同数据的签名认证方法及相关装置
CN111355592B (zh) * 2020-03-03 2022-06-10 泰华智慧产业集团股份有限公司 一种基于区块链的以太坊智能合约电子签章系统及方法
CN111539000B (zh) * 2020-04-17 2022-06-28 福建福昕软件开发股份有限公司 一种基于pdf文档的简化电子签名流程的方法、系统及装置
CN112187767A (zh) * 2020-09-23 2021-01-05 上海万向区块链股份公司 基于区块链的多方合同共识系统、方法及介质
CN113411188B (zh) * 2021-05-19 2022-08-02 广州炒米信息科技有限公司 电子合同签署方法、装置、存储介质及计算机设备
CN113378196B (zh) * 2021-06-21 2022-04-15 中山大学 基于区块链的多方合同签署方法
CN113761582B (zh) * 2021-09-29 2023-06-16 山东省计算中心（国家超级计算济南中心） 基于群签名的可监管区块链交易隐私保护方法及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160283920A1 (en) * 2015-03-28 2016-09-29 Justin Fisher Authentication and verification of digital data utilizing blockchain technology
WO2017079652A1 (en) * 2015-11-05 2017-05-11 Pulsifer Allen Cryptographic transactions system
CN106504008B (zh) * 2016-10-24 2017-12-29 中山大学 一种基于区块链的公平合同签署方法
CN106960165B (zh) * 2017-03-13 2020-12-22 广东网金控股股份有限公司 一种基于区块链智能合约实现电子合同多方会签的方法
CN107040383B (zh) * 2017-04-24 2018-01-30 中山大学 一种基于区块链的盲可验证加密签名方法
CN107171794B (zh) * 2017-06-27 2019-10-22 葛峰 一种基于区块链和智能合约的电子文书签署方法

Also Published As

Publication number Publication date
CN108833115A (zh) 2018-11-16

Similar Documents

Publication Publication Date Title
CN108833115B (zh) 一种基于区块链的多方公平pdf合同签署方法
CN108111301B (zh) 基于后量子密钥交换实现ssh协议的方法及其系统
CN110247757B (zh) 基于国密算法的区块链处理方法、装置及系统
JP4944886B2 (ja) 展性攻撃に対して改良された安全性を有する技術（これに限定されない）を含む非ワンタイムパッド暗号で暗号化した署名鍵を用いた、暗号認証、及び／又は共有暗号鍵の設定
US8464060B2 (en) Method and structure for self-sealed joint proof-of-knowledge and diffie-hellman key-exchange protocols
JP4837729B2 (ja) 暗号認証方法、コンピュータシステム及びデータキャリア
CN107248909B (zh) 一种基于sm2算法的无证书安全签名方法
CN107659395B (zh) 一种多服务器环境下基于身份的分布式认证方法及系统
US12047519B2 (en) Physical unclonable function based mutual authentication and key exchange
CN111682938A (zh) 面向中心化移动定位系统的三方可认证密钥协商方法
CN111953479B (zh) 数据处理的方法及装置
KR100989185B1 (ko) Ｒｓａ기반 패스워드 인증을 통한 세션키 분배방법
CN106789087B (zh) 确定消息的数据摘要、基于多方的数字签名的方法及系统
CN112771832A (zh) 用于共享公共秘密的计算机实现的系统和方法
CN110719172B (zh) 区块链系统中的签名方法、签名系统以及相关设备
CN110519219B (zh) 一种基于格的口令认证密钥交换方法及系统
CN111130758A (zh) 一种适用于资源受限设备的轻量级匿名认证方法
CN108768634B (zh) 可验证加密签名生成方法和系统
CN108964906B (zh) 协同ecc的数字签名方法
CN114070549B (zh) 一种密钥生成方法、装置、设备和存储介质
WO2022116175A1 (zh) 数字签名的生成方法、装置和服务器
CN116346336A (zh) 一种基于多层密钥生成中心的密钥分发方法及相关系统
CN114070550B (zh) 一种信息处理方法、装置、设备和存储介质
CN113094721B (zh) 一种基于模上错误学习的后量子口令认证密钥交换方法
CN110572788A (zh) 基于非对称密钥池和隐式证书的无线传感器通信方法和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210420

Address after: 066, 2nd floor, building 15, Chuangke Town, Wenquan Town, Haidian District, Beijing

Patentee after: Beijing Hengdao Fuying Technology Development Co.,Ltd.

Address before: 510275 Xingang West Road, Guangdong, Guangzhou, No. 135, No.

Patentee before: SUN YAT-SEN University

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210518

Address after: 095, 2nd floor, building 15, Chuangke town community commercial building, Wenquan Town, Haidian District, Beijing

Patentee after: Xinruiji Technology (Beijing) Co.,Ltd.

Address before: 066, 2nd floor, building 15, Chuangke Town, Wenquan Town, Haidian District, Beijing

Patentee before: Beijing Hengdao Fuying Technology Development Co.,Ltd.