CN114650136A - 一种基于混合云的电子签名方法及装置 - Google Patents

Abstract

本申请公开了一种基于混合云的电子签名方法，涉及电子签名技术领域，包括：分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；将携带有第一签名分量的第一请求发送给发送方云，以便发送方云生成第一数字签名，并将携带有第一数字签名的第二请求发送给接收方云；在接收方云生成最终签名，并将携带有最终签名的第三请求发送给接收方以便接收方对最终签名进行验证后，接收接收方发送的对最终签名的验证结果，验证通过则数字签名完成。本方法将私钥及对应的数字签名流程分散在两个云(即混合云)中，使得用户终端无需增加额外的专用密码设备，也消除了用户密钥由单个云保管的安全风险，安全性高。

Description

一种基于混合云的电子签名方法及装置

技术领域

本申请涉及电子签名技术领域，尤其涉及一种基于混合云的电子签名方法、装置。

背景技术

随着我国对信息安全越来越重视，越来越多的信息系统采用数字证书和密码技术来确保信息的安全性。一般来说，数字证书和密码技术采用密码硬件设备来实现，如加密机、加密卡或智能密码钥匙，采用这些密码硬件设备来存储用户数字证书、私钥并进行密码运算，具有较高的安全等级，可确保数据的安全性。但是，随着移动互联网的发展，越来越多的信息系统、互联网业务已转移到移动终端上进行操作，而传统的密码硬件设备难以直接在移动终端设备上方便地使用，这就需要增加额外的密码设备，从而增加了用户成本、提高了操作难度、兼容性差。因此当前的很多移动互联网应用中，密钥在移动终端上直接存储和使用，得不到专用硬件的保护，造成了移动终端上业务安全无法实现或保护等级降低的情况。

另一方面，近年来随着微信、支付宝等移动APP推出了小程序功能，很多数字签名应用以小程序作为入口，将用户证书及私钥托管在某个为用户提供数字签名服务的云服务中，可称为云证书数字签名。该方案虽然方便了用户的使用，避开了移动终端的密钥存储安全问题，但是由于拥有用户私钥的云服务存在非法使用用户私钥的可能，存在很大的安全隐患。另外，该方式在云服务进行数字签名前需要进行基于用户口令的对称密码身份认证，该身份认证中用户口令对应的对称密码也在云服务进行存储和认证函数计算，一方面存在对称密码泄露的可能性，另一方面该认证流程独立于数字签名流程，整个签名流程因包含2个独立的流程而略显复杂。

发明内容

本申请提供的一种基于混合云的电子签名方法，旨在解决现有技术中云服务端用户密钥存在安全风险以及身份认证流程与数字签名流程相互独立的问题。

为实现上述目的，本申请采用以下技术方案：

本申请的一种基于混合云的电子签名方法，包括以下步骤：

分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

作为优选，所述消息还包含时间戳，所述时间戳用于判断收到所述消息的时间是否应为当前时刻，若否则中止签名。

作为优选，所述获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

根据用户口令分别计算在所述发送方云和所述接收方云的私钥的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

作为优选，所述获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

根据用户口令计算在所述发送方云的第一私钥分量，并从所述发送方云处获取在所述接收方云的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

作为优选，所述获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

从所述接收方云处获取在所述发送方云的第一私钥分量，并从所述发送方云处获取在所述接收方云的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

作为优选，还包括根据公钥合并函数将在所述发送方云和所述接收方云的公钥合并成总体公钥，根据所述总体公钥和自身真实身份向CA机构申请并接收其返回的数字证书。

作为优选，所述将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云，包括：

利用在所述发送方云和所述接收方云的第一私钥分量分别对消息进行签名得到第一签名分量和第三签名分量，并将携带有所述消息、所述第一签名分量、所述第三签名分量和所述数字证书的第一请求发送给所述发送方云，以便所述发送方云利用在所述发送方云的第二私钥分量生成第二签名分量并将其与所述第一签名分量合并成第一数字签名，根据所述数字证书验证所述第一数字签名，验证通过则将携带有所述消息、所述第一数字签名、所述第三签名分量和所述数字证书的第二请求发送给所述接收方云。

作为优选，所述在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成，包括：

在所述接收方云验证时间通过时，将所述第三签名分量和其利用在所述接收方云的第二私钥分量生成的第四签名分量合并成第二数字签名，并将所述第一数字签名和所述第二数字签名合并为最终签名，将所述消息、所述最终签名和所述数字证书发送给接收方以便接收方根据所述数字证书对所述最终签名进行验证后，接收所述接收方的验证结果，验证通过，数字签名完成。

一种基于混合云的电子签名装置，包括：

获取模块，用于分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

发送模块，用于将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

完成模块，用于在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述中任一项所述的一种基于混合云的电子签名方法。

本发明具有如下有益效果：

本方案令发送方和接收方分别接入发送方云与接收方云，根据发送方云与接收方云不会互通隐私的特性，将私钥及对应的数字签名流程分散在两个云(即混合云)中，使得用户终端无需增加额外的专用密码设备，也消除了用户密钥由单个云保管的安全风险，可达到较高安全要求；而且由于每个云的私钥分量均被分拆，即使将两个云中分拆后的私钥分量凑齐也无法恢复用于签名的全部私钥，私钥安全性大大提高；而且在云服务进行数字签名前不需要进行基于用户口令的对称密码身份认证，同时身份认证中用户口令对应的对称密码也不需要在云服务进行存储和认证计算，而是转化为了分拆后的私钥分量，这样一方面避免了在云服务对对称密码进行存储和计算而导致密码泄露的可能，另一方面身份认证流程与数字签名流程统一，整个签名流程得到较大精简。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实现一种基于混合云的电子签名方法的流程图；

图2是本申请实施例1中成员关系及密钥分布图；

图3是本申请实施例2中成员关系及密钥分布图；

图4是本申请实施例3中成员关系及密钥分布图；

图5是本申请实施例4实现一种基于混合云的电子签名装置示意图。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的权利要求书和说明书的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序，应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式，此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他单元。

实施例1

如图1所示，一种基于混合云的电子签名方法，包括以下步骤：

S110、分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

S120、将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

S130、在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

根据实施例1可知，混合云融合了公有云和私有云，是近年来云计算的主要模式和发展方向，尤其私企主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多地采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的，本方案中的混合云则是指发送方云与接收方云的混合，其中发送方云与接收方云既可以是公有云也可以是私有云，但它们不属于同一组织，因此不会互通隐私，而发送方和接收方均为终端，且可能位于内网，无法或者难以直接连接。

数字签名，又称公钥数字签名，是只有信息的发送者才能产生的别人无法伪造的数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明，是一种类似写在纸上的物理签名，但使用了公钥加密领域的技术来实现的、用于鉴别数字信息的方法，属于电子签名，电子签名是指任何数据电文中以电子形式所含、所附用于识别签名人身份并标明签名人认可其中内容的数据。

本实施例提供两种实施方式，其中密钥分布如图2所示，发送方A的随机存取存储器如内存中短暂存在过KA、KB，其长期存储器如硬盘或ROM中则没有存储任何密钥，发送方云SA的长期存储器中存储EA、DA_，接收方云SB的长期存储器中则存储EB、DB_，接收方B的随机存取存储器如内存及长期存储器如硬盘或ROM中都未存任何密钥。

第一种实施方式，发送方A先到发送方云SA和接收方云SB注册为用户并分配密钥，具体地为：

发送方A与发送方云SA进行TLS通信，SA会对A进行真实身份认证，其中，身份认证方法包括人脸识别、指纹、短信、身份证等，一般认证流程是先连接到公安局、通信运营商或银行等权威机构，再由权威机构执行身份认证，并将认证结果返回到请求方，真实身份认证通过后，发送方云SA认可发送方A的合法性，并建立发送方身份ID 即IDA对应的数据条目。真实身份认证仅在注册时使用，后续A与SA可不再进行真实身份认证。此时，发送方A会根据公私钥算法生成其在该发送方云的公私钥对EA/DA，设置口令为PWDA，根据PWDA可以使用单向函数计算得到私钥DA的第一私钥分量KA，例如KA=HASH(IDA||IDSA||PWDA)，其中，HASH(*)为摘要函数，||为字符拼接标识，IDSA为发送方云SA的身份ID,再根据私钥拆分函数DA=FD(DA_,KA)计算私钥DA的第二私钥分量DA_，其中，DA=FD(DA_,KA)表示私钥DA可以分拆为第一私钥分量KA和第二私钥分量DA_，优选为，当密码体系为RSA时，DA=DA_+KA mod φ(NA)，NA为RSA算法的模数，φ(*)为欧拉函数，第一、第二只是为了将两个私钥分量区分开，无特殊含义，然后将公钥EA和第二私钥分量DA_发送给发送方云SA。

接着，发送方A与接收方云SB 进行TLS通信，SB对A的真实身份认证通过后，认可发送方A的合法性，其中，该身份认证方法与接收方云相同，并建立IDA对应的数据条目。真实身份认证仅在注册时使用，后续A与SB可不再进行真实身份认证。然后，发送方A会根据公私钥算法生成其在该接收方云的公私钥对EB/DB，设置口令为PWDB，并根据PWDB计算得到私钥DB的第一私钥分量KB，例如KB=HASH(IDA||IDSB||PWDB)，IDSB为接收方云SB的身份ID，再根据私钥拆分函数DB=FD(DB_,KB)计算得到私钥DB的第二私钥分量DB_，并将EB/DB_发送给SB。

最后，发送方A将在发送方云的公钥EA和在接收方云的公钥EB根据公钥合并函数进行合并得到合并公钥即总体公钥PKA=FPK(EA,EB)，并根据发送方A的真实身份向CA机构申请得到数字证书CERTA，其中包含PKA，在申请到CERTA后发送方会A销毁EA、DA、EB和DB。其中，PKA=FPK(EA,EB)表示公钥PKA可以由公钥EA和公钥EB合并而成。优选为，当密码体系为RSA时，可参考文献《Damgard I , Mikkelsen G L , Skeltved T . On the security ofdistributed multiprime RSA.[C]// International Conference on InformationSecurity and Cryptology. 2014》中的“Four-prime Distributed RSA”部分，设EA=(NA,e)、EB=(NB,e)，则PKA=(NA*NB,e)。

发送方云SA和接收方云SB不存储用户口令相关密钥，而是分别存储分拆后的私钥分量DA_、DB_，避免了云服务对对称密码进行存储和计算而导致密码泄露的可能性，且私钥DA、DB均被分拆，在缺少KA、KB的情况下，即使将分拆后的私钥分量DA_、DB_凑齐也无法恢复用于签名的全部私钥，私钥安全性大大提高。

接下来，进入认证及签名阶段，具体地为：

首先，发送方A与发送方云SA进行认证及签名：发送方A发送给接收方B的消息为M，M中包含时间戳TM和消息主体，其中，消息主体可以是实际消息或实际消息的摘要值；当消息主体是实际消息的摘要值时，实际消息可通过邮件、短信等方式发送给接收方B，发送方A根据用户输入的PWDA和PWDB计算得到KA和KB，因为发送方是不存储任何密钥的，故此处需要重新计算在发送方云的第一私钥分量KA和在接收方云的第一私钥分量KB，将第一请求MSA=M||SIG(M,KA)||SIG(M,KB)||CERTA发送给发送方云，其中，SIG(M,KA)为第一签名分量，表示用在发送方云SA的私钥DA的第一私钥分量KA对消息M进行签名，同理，SIG(M,KB)为第三签名分量，表示用在接收方云SB的私钥DB的第一私钥分量KB对消息M进行签名，当发送方云SA接收到第一请求MSA后，首先根据时间戳TM判断收到消息的时间是否应为当前时刻，若否则拒收消息并中止流程，若是则根据CERTA中的IDA找到其在发送方云的EA/DA_，并计算第二签名分量SIG(M,DA_)，其表示用在发送方云SA的私钥DA的第二私钥分量DA_对消息M进行签名，并根据签名分量合并函数将其与SIG(M,KA)合并得到第一数字签名SIGA=FS(SIG(M,KA), SIG(M,DA_))，用EA验证SIGA，验证通过即认可A的身份及消息M，其中，SIGA=FS(SIG(M,KA), SIG(M,DA_))表示将签名分量SIG(M,KA)、SIG(M,DA_)合并为签名SIGA。优选为，当密码体系为RSA且DA=DA_+KA mod φ(NA)时，合并的签名SIGA=SIG(M,DA_)*SIG(M,KA) mod NA。

其次，发送方A与接收方云SB进行认证及签名：发送方云SA将第二请求MSB=M||SIGA||SIG(M,KB)||CERTA发送给接收方云SB，SB收到MSB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收该请求，并根据CERTA中的IDA找到发送方在接收方云的EB/DB_，然后计算第四签名分量SIG(M,DB_)，其表示用在接收方云的私钥DB的第二私钥分量DB_对消息M进行签名，同样根据签名分量合并函数将其与SIG(M,KB)合并得到第二数字签名SIGB=FS(SIG(M,KB), SIG(M,DB_))，再用EB验证SIGB，验证通过即认可A的身份及消息M。

最后，发送方A与接收方B进行认证及签名:接收方云SB根据签名合并函数将第一数字签名SIGA与第二数字签名SIGB进行合并得到最终签名SIGM=FS2(SIGA,SIGB)，然后将第三请求MB=M||SIGM||CERTA发送给接收方B，B收到MB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收消息，并验证CERTA的合法性，CERTA验证通过后根据CERTA找到发送方的总体公钥PKA，并用PKA验证SIGM，验证通过即认可A的身份及消息M，签名完成。其中，SIGM=FS2(SIGA,SIGB)表示将签名SIGA、SIGB合并为签名SIGM。优选为，当密码体系为RSA时，可参考文献《Damgard I , Mikkelsen G L , Skeltved T .On the security of distributed multiprime RSA.[C]// International Conferenceon Information Security and Cryptology. 2014》中的“Four-prime Distributed RSA”部分，根据中国剩余定理将SIGA和SIGB合并为SIGM。

本实施方式令发送方和接收方分别接入发送方云与接收方云，根据发送方云与接收方云不会互通隐私的特性，将私钥及对应的数字签名流程分散在两个云(即混合云)中，对用户终端如固定终端或移动终端来说无需增加额外的专用密码设备，也消除了用户密钥由单个云保管的安全风险，可达到较高安全要求，同时将用户口令的认证流程与数字签名流程进行了统一，简化了签名流程。

在另一实施方式中，发送方A在发送方云SA和接收方云SB的公私钥对的生成方不同，其数字证书的申请方也不同，具体地为：

发送方A到发送方云SA注册为用户并分配密钥：发送方A与发送方云SA进行TLS通信， SA对A的真实身份认证通过后， SA认可A的合法性，并建立发送方IDA对应的数据条目，此时，SA会根据公私钥算法生成发送方在其的公私钥对EA/DA，同时A设置口令为PWDA，根据PWDA可以使用单向函数计算得到其在发送方云SA的私钥DA的第一私钥分量KA，例如KA=HASH(IDA||IDSA||PWDA)，A将KA发送给SA，SA再根据私钥拆分函数DA=FD(DA_,KA)计算私钥DA的第二私钥分量DA_。

接着，发送方A与接收方云SB 进行TLS通信，SB对A的真实身份认证通过后，认可A的合法性，并建立IDA对应的数据条目，然后，SB会根据公私钥算法生成发送方在其的公私钥对EB/DB，A则设置口令为PWDB，并根据PWDB计算得到私钥DB的第一私钥分量KB，例如KB=HASH(IDA||IDSB||PWDB)，并将KB发送给SB，SB根据私钥拆分函数DB=FD(DB_,KB)计算DB的第二私钥分量DB_。

最后，发送方云SA向接收方云SB请求得到EB，得到EB后会根据公钥合并函数将EA和EB进行合并得到合并公钥即总体公钥PKA=FPK(EA,EB)，并根据发送方A的真实身份向CA机构申请得到数字证书CERTA，其中包含PKA，在申请到CERTA后SA销毁DA、KA，SB销毁KB和DB，SA将CERTA发送给A。

认证及签名阶段的方法则与上一实施方式相同，而且本实施方式中的不同只是为了满足不同用户终端的要求，若用户终端（此处指发送方）倾向于在云端处理大部分密码计算工作则可以选择该实施方式，若倾向于己方设备处理，则选择上一实施方式，但上述两种实施方式的成员关系及密钥分布相同。

实施例2

本实施例提供另外两种实施方式，其中密钥分布如图3所示，发送方A的随机存取存储器如内存中存在过KA，长期存储器如硬盘或ROM中不存储任何密钥，发送方云SA的长期存储器中存储KB、EA、DA_，接收方云SB的长期存储器中则存储EB、DB_，接收方B的随机存取存储器如内存及长期存储器如硬盘或ROM中都未存任何密钥，可看出其与实施例1最大的区别在于DB的第一私钥分量KB的存储地方不同。

在第一种实施方式中，发送方A到发送方云SA注册为用户并分配密钥的方法与实施例1中的第一种实施方式无任何不同，不同在于接收方云SB 在对发送方A的真实身份认证通过且A生成了在SB的公私钥对之后，DB的第一私钥分量KB不是通过函数计算出来的，更不用设置在接收方云的用户口令，而是A与SA进行真实身份认证后，从SA获取到的真随机数，且SA存储KB，是为了将同一私钥的两个私钥分量分开存储，其后的私钥分拆方法与数字证书申请方法都与实施例1中的第一种实施方式相同。

接下来的认证及签名阶段也不同，具体地为：

首先，发送方A与发送方云SA进行认证及签名：发送方A发送给接收方B的消息为M，M中包含时间戳TM和消息主体，发送方A根据用户输入的PWDA计算得到KA后，将第一请求MSA=M||SIG(M,KA)|| CERTA发送给发送方云，发送方云首先根据时间戳TM判断收到消息的时间是否应为当前时刻，若是则根据CERTA中的IDA找到发送方在发送方云的EA/DA_，并计算SIG(M,DA_)，并将其与SIG(M,KA)合并得到第一数字签名SIGA=FS(SIG(M,KA), SIG(M,DA_))，用EA验证SIGA，验证通过即认可A的身份及消息M。

其次，发送方A与接收方云SB进行认证及签名：发送方云SA根据CERTA中的IDA找到发送方在接收方云的KB，并计算SIG(M,KB)，然后将第二请求MSB=M||SIGA||SIG(M,KB)||CERTA发送给接收方云SB，SB收到MSB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收该请求，并根据CERTA中的IDA找到发送方在接收方云SB的EB/DB_，然后计算SIG(M,DB_)，同样将其与SIG(M,KB)合并得到第二数字签名SIGB=FS(SIG(M,KB), SIG(M,DB_))，再用EB验证SIGB，验证通过即认可A的身份及消息M。

最后，发送方A与接收方B进行认证及签名:接收方云SB将第一数字签名SIGA与第二数字签名SIGB进行合并得到最终签名SIGM=FS2(SIGA,SIGB)，然后将第三请求MB=M||SIGM||CERTA发送给接收方B，B收到MB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收消息，并验证CERTA的合法性，CERTA验证通过后根据CERTA找到发送方的总体公钥PKA，并用PKA验证SIGM，验证通过即认可A的身份及消息M，签名完成。

在第二种实施方式中，将本实施例第一种实施方式中的公私钥对生成方和数字证书申请方替换为实施例1中第二种实施方式中的主体即可，但在分拆在接收方云的私钥前，需由发送方A将KB发送给SB,其他流程则与本实施例第一种实施方式相同，在此不再赘述。

本实施例与实施例1的区别就是在实施例1中KB在发送方A的随机存取存储器如内存中停留过，在本实施例中则存在发送方云SA的长期存储器中。

在每个云的私钥分量均被分拆，即使将两个云的分拆后的私钥分量凑齐也无法恢复用于签名的全部私钥，私钥安全性大大提高。

实施例3

本实施例也提供两种实施方式，其中密钥分布如图4所示，发送方A的随机存取存储器如内存和长期存储器如硬盘或ROM中都没有存过任何密钥，发送方云SA的长期存储器中存储KB、EA、DA_，接收方云SB的长期存储器中则存储KA、EB、DB_，接收方B的随机存取存储器如内存及长期存储器如硬盘或ROM中同样未存任何密钥，其与实施例2最大的区别在于DA的第一私钥分量KA的存储地方不同。

在第一种实施方式中，发送方A在发送方云SA的私钥DA的第一私钥分量KA不是通过函数计算得到的，而是发送方A与接收方云SB真实身份认证通过后，从SB处获取的真随机数，且由SB存储KA，同样地，其在接收方云SB的私钥DB的第一私钥分量KB则是发送方A与发送方云SA真实身份认证通过后从SA处获取的真随机数，且由SA存储KB,数字证书申请方式则与实施例1、实施例2的第一种实施方式相同。

接下来的认证及签名阶段也不同，具体地为：

首先，发送方A与发送方云SA进行认证及签名：发送方A发送给接收方B的消息为M，M中包含时间戳TM和消息主体，A与SB进行真实身份认证后，将M发送给SB，SB根据IDA找到发送方在发送方云SA的私钥DA的第一私钥分量KA，并用KA计算得到SIG(M,KA)，然后将其发送给A，A将第一请求MSA=M||SIG(M,KA)|| CERTA发送给发送方云SA，发送方云SA首先根据时间戳TM判断收到消息的时间是否应为当前时刻，若是则根据CERTA中的IDA找到发送方在发送方云的EA/DA_，并计算SIG(M,DA_)，并将其与SIG(M,KA)合并得到第一数字签名SIGA=FS(SIG(M,KA), SIG(M,DA_))，用EA验证SIGA，验证通过即认可A的身份及消息M。

其次，发送方A与接收方云SB进行认证及签名：发送方云SA根据CERTA中的IDA找到发送方在接收方云的KB，并计算SIG(M,KB)，然后将第二请求MSB=M||SIGA||SIG(M,KB)||CERTA发送给接收方云SB，SB收到MSB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收该请求，并根据CERTA中的IDA找到发送方在接收方云的EB/DB_，然后计算SIG(M,DB_)，同样将其与SIG(M,KB)合并得到第二数字签名SIGB=FS(SIG(M,KB), SIG(M,DB_))，再用EB验证SIGB，验证通过即认可A的身份及消息M。

最后，发送方A与接收方B进行认证及签名:接收方云SB将第一数字签名SIGA与第二数字签名SIGB进行合并得到最终签名SIGM=FS2(SIGA,SIGB)，然后将第三请求MB=M||SIGM||CERTA发送给接收方B，B收到MB后同样先根据TM判断收到消息的时间是否应为当前时刻，若否则中止签名，若是则接收消息，并验证CERTA的合法性，CERTA验证通过后根据CERTA找到发送方的总体公钥PKA，并用PKA验证SIGM，验证通过即认可A的身份及消息M，签名完成。

在第二种实施方式中，将本实施例第一种实施方式中的公私钥对生成方和数字证书申请方替换为实施例1与实施例2中第二种实施方式中的主体即可，但在分拆在发送方云的私钥和在接收方云的私钥前，需先由发送方A将KA发送给SA、将KB分别SB,其他流程则与本实施例第一种实施方式相同，在此不再赘述。

本实施例与实施例1、实施例2的区别则是本实施例发送方云SA的长期存储器中存储了KB、EA和DA_，接收方云SB的长期存储器中存储了KA、EB、DB_，将KB存储在SA、KA存储在SB是为了将同一私钥的两个私钥分量分开保存以提高私钥安全性。

将私钥及对应的数字签名流程分散在两个云(即混合云)中，对用户终端来说无需增加额外的专用密码设备，也消除了用户密钥由单个云保管的安全风险，可达到较高安全要求。

实施例4

如图5所示，一种基于混合云的电子签名装置，包括：

获取模块10，用于分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

发送模块20，用于将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

完成模块30，用于在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

上述装置的一种实施方式可为：获取模块10分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和在所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量，发送模块20将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云，完成模块30在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。 一种存储有计算机程序的计算机可读存储介质，所述计算机程序使计算机执行时实现如上述的一种基于混合云的电子签名方法。 示例性地，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器中，并由处理器执行，并由输入接口和输出接口完成数据的I/O接口传输，以完成本发明,一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机设备中的执行过程。 计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。计算机设备可包括，但不仅限于，存储器、处理器,本领域技术人员可以理解，本实施例仅仅是计算机设备的示例，并不构成对计算机设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件，例如计算机设备还可以包括输入器、网络接入设备、总线等。 处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以是计算机设备的内部存储单元，例如计算机设备的硬盘或内存。存储器也可以是计算机设备的外部存储设备，例如计算机设备上配备的插接式硬盘，智能存储卡（Smart Media Card,SMC），安全数字（Secure Digital,SD）卡，闪存卡（Flash Card）等,进一步地，存储器还可以既包括计算机设备的内部存储单元也包括外部存储设备,存储器用于存储计算机程序以及计算机设备所需的其他程序和数据,存储器还可以用于暂时地存储在输出器，而前述的存储介质包括U盘、移动硬盘、只读存储器ROM、随机存储器RAM、碟盘或光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何在本发明揭露的技术范围内的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种基于混合云的电子签名方法，其特征在于，包括以下步骤：

分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

2.根据权利要求1所述的一种基于混合云的电子签名方法，其特征在于，所述消息还包含时间戳，所述时间戳用于判断收到所述消息的时间是否应为当前时刻，若否则中止签名。

3.根据权利要求1所述的一种基于混合云的电子签名方法，其特征在于，所述获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

根据用户口令分别计算在所述发送方云和所述接收方云的私钥的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

4.根据权利要求1所述的一种基于混合云的电子签名方法，其特征在于，所述获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

根据用户口令计算在所述发送方云的私钥的第一私钥分量，并从所述发送方云处获取在所述接收方云的私钥的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

5.根据权利要求1所述的一种基于混合云的电子签名方法，其特征在于，所述获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，包括：

根据公私钥算法分别生成在所述发送方云和所述接收方云的公私钥对；

从所述接收方云处获取在所述发送方云的私钥的第一私钥分量，并从所述发送方云处获取在所述接收方云的私钥的第一私钥分量；

将每个私钥及其第一私钥分量输入私钥分拆函数中，计算得到其第二私钥分量。

6.根据权利要求3-5任意一项所述的一种基于混合云的电子签名方法，其特征在于，还包括根据公钥合并函数将在所述发送方云和所述接收方云的公钥合并成总体公钥，根据所述总体公钥和自身真实身份向CA机构申请并接收其返回的数字证书。

7.根据权利要求6所述的一种基于混合云的电子签名方法，其特征在于，所述将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云，包括：

利用在所述发送方云和所述接收方云的第一私钥分量分别对消息进行签名得到第一签名分量和第三签名分量，将携带有所述消息、所述第一签名分量、所述第三签名分量和所述数字证书的第一请求发送给所述发送方云，以便所述发送方云利用在发送方云的第二私钥分量生成第二签名分量并将其与所述第一签名分量合并成第一数字签名，根据所述数字证书验证所述第一数字签名，验证通过则将携带有所述消息、所述第一数字签名、所述第三签名分量和所述数字证书的第二请求发送给所述接收方云。

8.根据权利要求7所述的一种基于混合云的电子签名方法，其特征在于，所述在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成，包括：

在所述接收方云验证时间通过时，将所述第三签名分量和其利用在所述接收方云的第二私钥分量生成的第四签名分量合并成第二数字签名，并将所述第一数字签名和所述第二数字签名合并为最终签名，将所述消息、所述最终签名和所述数字证书发送给接收方以便接收方根据所述数字证书对所述最终签名进行验证后，接收所述接收方的验证结果，验证通过，数字签名完成。

9.一种基于混合云的电子签名装置，其特征在于，包括：

获取模块，用于分别与发送方云和接收方云建立通信连接，并获取其在所述发送方云和所述接收方云的第一私钥分量和第二私钥分量，每一私钥分量用于生成对应的签名分量；

发送模块，用于将携带有消息和第一签名分量的第一请求发送给所述发送方云，以便所述发送方云根据所述第一签名分量生成第一数字签名，并将携带有所述第一数字签名和第三签名分量的第二请求发送给所述接收方云；

完成模块，用于在所述接收方云根据所述第三签名分量生成第二数字签名并将其与所述第一数字签名合并得到最终签名，将携带有所述最终签名的第三请求发送给接收方以便所述接收方对所述最终签名进行验证后，接收所述接收方发送的对所述最终签名的验证结果，验证通过则数字签名完成。

10.一种存储有计算机程序的计算机可读存储介质，其特征在于，所述计算机程序使计算机执行时实现如权利要求1～8中任一项所述的一种基于混合云的电子签名方法。

Images