CN116975936B - 金融资质证明方法、金融资质验证方法 - Google Patents

Abstract

本申请提供了一种金融资质证明方法、金融资质验证方法，涉及信息安全技术领域。该金融资质证明方法包括：向多个金融机构端发送目标用户的金融资质证明请求；接收多个金融机构端各自发送的同态承诺；对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺；基于目标同态承诺，利用范围证明，生成证明文件，证明文件用于证明目标用户在多个金融机构端中存储的金融数据满足目标条件；将证明文件发送至第三方机构端，以便第三方机构端对证明文件进行验证。本申请在实现多个金融机构端联合证明目标用户的金融数据的金融属性的同时，保护了目标用户的数据隐私安全。

Description

金融资质证明方法、金融资质验证方法

技术领域

本申请涉及信息安全技术领域，具体涉及一种金融资质证明方法、金融资质验证方法。

背景技术

相关金融资质证明方法中，大多是单方证明。然而，随着信息多样化的发展，存在一些金融资质证明需要联合多方参与。多方参与的过程中，各自的信息可能存在泄密风险，同时，如何在保密状态下，对多方的证明结果进行汇总，也是亟须解决的问题。

发明内容

有鉴于此，本申请实施例提供了一种金融资质证明方法、金融资质验证方法。

第一方面，本申请一实施例提供了一种金融资质证明方法，应用于用户端，用户端分别与多个金融机构端和第三方机构端连接。该金融资质证明方法包括：向多个金融机构端发送目标用户的金融资质证明请求，以便每个金融机构端响应于金融资质证明请求，基于金融机构端中存储的目标用户的金融数据，生成同态承诺；接收多个金融机构端各自发送的同态承诺；对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺；基于目标同态承诺，利用范围证明，生成证明文件，证明文件用于证明目标用户在多个金融机构端中存储的金融数据满足目标条件；将证明文件发送至第三方机构端，以便第三方机构端对证明文件进行验证。

结合第一方面，在第一方面的某些实现方式中，该金融资质证明方法还包括：在向多个金融机构端发送目标用户的金融资质证明请求之前，获取第三方机构端发送的验证数据，验证数据包括目标用户的身份标识和随机数；将验证数据发送至多个金融机构端，以便每个金融机构端在生成同态承诺后，将同态承诺和验证数据发送至用户端；在生成证明文件之后，将证明文件和验证数据发送至第三方机构，以便第三方机构通过验证数据判断证明文件是否为针对金融资质证明请求生成的。

结合第一方面，在第一方面的某些实现方式中，对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺，包括：接收多个金融机构端各自发送的电子签名；对多个金融机构端各自发送的同态承诺和电子签名进行验证；若多个金融机构端均通过验证，则对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺。

结合第一方面，在第一方面的某些实现方式中，金融机构的电子签名基于金融机构端的私钥、金融机构端生成的同态承诺和验证数据得到，验证数据是由第三方机构端生成，并经用户端发送至每个金融机构端的。

结合第一方面，在第一方面的某些实现方式中，在将证明文件发送至第三方机构端之后，金融资质证明方法还包括：获取多个金融机构端各自对应的电子签名；将多个金融机构端各自对应的电子签名和同态承诺发送至第三方机构端，以便第三方机构端基于多个金融机构端各自对应的电子签名和同态承诺，对证明文件进行验证。

第二方面，本申请一实施例提供了一种金融资质验证方法，应用于第三方机构端，第三方机构端与用户端连接，用户端与多个金融机构端连接。该金融资质验证方法包括：接收用户端发送的证明文件，证明文件是基于目标同态承诺生成的，目标同态承诺是通过对多个金融机构端各自对应的同态承诺进行同态关系运算得到的，金融机构端对应的同态承诺是基于目标用户的金融资质证明请求和金融机构端中存储的目标用户的金融数据生成的；对证明文件进行验证，以便验证目标用户在多个金融机构端中存储的金融数据是否满足目标条件。

结合第二方面，在第二方面的某些实现方式中，对证明文件进行验证，包括：获取多个金融机构端各自对应的电子签名和同态承诺；对多个金融机构端各自对应的电子签名进行验证；在多个金融机构端各自对应的电子签名均通过验证的情况下，基于多个金融机构端各自对应的同态承诺，对证明文件进行验证。

结合第二方面，在第二方面的某些实现方式中，基于多个金融机构端各自对应的同态承诺，对证明文件进行验证，包括：对多个金融机构端各自对应的同态承诺进行同态关系运算，生成待验证同态承诺；在证明文件内，对待验证同态承诺和证明文件包含的目标同态承诺进行一致性认证；在一致性认证通过的情况下，验证目标同态承诺是否在证明文件包含的目标范围内。

第三方面，本申请一实施例提供了一种金融资质证明装置，应用于用户端，用户端分别与多个金融机构端和第三方机构端连接。该金融资质证明装置包括：第一发送模块，用于向多个金融机构端发送目标用户的金融资质证明请求，以便每个金融机构端响应于金融资质证明请求，基于金融机构端中存储的目标用户的金融数据，生成同态承诺；接收模块，用于接收多个金融机构端各自发送的同态承诺；运算模块，用于对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺；生成模块，用于基于目标同态承诺，利用范围证明，生成证明文件，证明文件用于证明目标用户在多个金融机构端中存储的金融数据满足目标条；第二发送模块，用于将证明文件发送至第三方机构端，以便第三方机构端对证明文件进行验证。

第四方面，本申请一实施例提供了一种金融资质验证装置，应用于第三方机构端，第三方机构端与用户端连接，用户端与多个金融机构端连接。该金融资质验证装置包括：接收模块，用于接收用户端发送的证明文件，证明文件是基于目标同态承诺生成的，目标同态承诺是通过对多个金融机构端各自对应的同态承诺进行同态关系运算得到的，金融机构端对应的同态承诺是基于目标用户的金融资质证明请求和金融机构端中存储的目标用户的金融数据生成的；验证模块，用于对证明文件进行验证，以便验证目标用户在多个金融机构端中存储的金融数据是否满足目标条件。

第五方面，本申请一实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序用于执行第一方面和第二方面所述的方法。

第六方面，本申请一实施例提供了一种电子设备，该电子设备包括：处理器；用于存储处理器可执行指令的存储器；该处理器用于执行第一方面和第二方面所述的方法。

在本申请实施例中，金融机构端生成的是同态承诺，实现了多个金融机构联合证明目标用户的金融数据所具有的金融属性。同时，本申请实施例采用范围证明解决了如何证明被承诺绑定的金融数据确实满足目标条件，并且不泄露金融数据的问题，保证了目标用户的数据隐私安全。具体而言，目标用户获取的是各个金融机构对目标用户的金融数据的承诺，并且公布的只有一个零知识的范围证明，因此，一个金融机构并不知晓其他金融机构中存储的目标用户的金融数据，同时，第三方机构并不知道目标用户在多个金融机构中存储的金融数据的具体值，仅仅知道这个值满足目标条件。

附图说明

通过结合附图对本申请实施例进行更详细地描述，本申请的上述以及其他目的、特征和优势将变得更加明显。附图用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1所示为本申请一示例性实施例提供的应用场景图。

图2所示为本申请一示例性实施例提供的金融资质证明方法的流程示意图。

图3所示为本申请一示例性实施例提供的生成目标同态承诺的流程示意图。

图4所示为本申请一实施例提供的金融资质证明装置的结构示意图。

图5所示为本申请一实施例提供的金融资质验证装置的结构示意图。

图6所示为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

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

图1所示为本申请一示例性实施例提供的应用场景图。示例性地，在该应用场景中，第三方机构端为交易机构。如图1所示，本申请实施例提及的应用场景包括金融机构10（即金融机构端）、交易机构20（即交易机构端）和用户端30，其中，金融机构20和交易机构20分别与用户端30连接。

用户端30可以是智能手机、平板电脑、台式计算机等。金融机构10和交易机构20可以是独立的物理服务器，或者由多个服务器组成的服务器集群，或者能进行云计算的云服务器。金融机构10和交易机构20可以是实体机，也可以是虚拟机，数量可以是一个或多个，本申请实施例对服务器的类型和数量不作限定。

示例性地，用户甲想在交易机构20中对拍卖物品进行竞价，然而，交易机构设立了关于竞价的规则，即需要用户甲证明自己在各个金融机构中的存款总数超过100万。基于上述场景，用户甲通过用户端30向多家金融机构发送金融资质证明请求，每个金融机构10基于金融机构端中存储的目标用户的存款，生成金融机构10各自对应的同态承诺。例如，针对金融机构，用户甲在其中存储了25万，金融机构/>的同态承诺是：用户甲存储有25万。之后，每个金融机构10分别将同态承诺发送至用户端30，用户端30对每个金融机构10各自发送的同态承诺进行同态关系运算，生成目标同态承诺，继而生成目标同态承诺的证明文件，并将证明文件发送至交易机构20。交易机构20对证明文件进行验证，以验证用户甲在各家金融机构10中的存款总数是否真的超过100万。

图2所示为本申请一示例性实施例提供的金融资质证明方法的流程示意图。示例性地，该金融资质证明方法涉及金融机构端、用户端和第三方机构端。

如图2所示，本申请实施例提供的金融资质证明方法包括如下步骤。

步骤S210，发送目标用户的金融资质证明请求。具体地，用户端向金融机构端发送目标用户的金融资质证明请求。

示例性地，金融资质证明请求具有用户属性和时间属性，此外，还具有事件属性。具体来说，金融资质证明请求中包含生成该请求的用户信息和时间信息，以及该请求对应的具体事件。例如，金融资质证明请求用于请求金融机构端证明目标用户存储的金融数据的具体值。举例来说，金融机构端包括银行，金融数据为存款额度。

步骤S220，基于金融机构中存储的目标用户的金融数据，生成同态承诺。具体地，金融机构端基于其存储的目标用户的金融数据，生成同态承诺。

承诺是一个算法。例如，用户A希望向用户B承诺一个值m，并约定好一个星期后用户A再公布m的值，则承诺的生成过程如下：

步骤一：用户A任选一个随机数r，生成承诺，并将c发送给用户B；步骤二：一个星期后，用户A打开承诺，即用户A将m和r都公开发送给用户B；步骤三：用户B检查是否有/>，如果是，那么用户A在步骤二中公布的值确实是用户A一周前承诺的值。如果不是，那么认为用户A在步骤二中公布的值是不正确的。

根据承诺的隐藏性，用户A将承诺c发送给用户B之后，在用户A打开承诺之前，用户B无法得到m。根据承诺的绑定性，用户A将c发送给用户B之后，用户A无法在步骤二中用其他的消息来骗过用户B。

相比于前面陈述的承诺，同态承诺是一种满足某种同态关系的承诺，例如，若同态承诺为加法同态承诺，则除了满足上面承诺的隐藏性和绑定性之外，它还满足：。也就是说，可以使用/>和/>的同态承诺，可以得到关于/>的承诺，其中，/>）表示/>（）。

需要说明的是，在本实施例中，对于同态承诺而言，可以采用任意类型的同态承诺，只要确保该同态承诺能够满足加法同态。因此，本实施例中的同态承诺可以为加法同态承诺，或者全同态承诺，本说明书并不对此进行限制。对于同态承诺算法而言，当采用相关技术中的Pedersen承诺机制时，可以为未加密数据确定一随机数，并基于该随机数与未加密数据进行计算得到相应的承诺数值。

将多个金融机构可以分别表示为，……，/>，在一个示例中，金融机构端生成的同态承诺可以表示为/>，/>表示金融机构端中存储的目标用户的金融数据，/>表示金融机构端产生的随机数，/>表示金融机构端根据目标用户的金融数据和随机数生成的同态承诺。在另一个示例中，用户端向金融机构端发送/>，然后金融机构端检查用户端发送的/>是否和自己记录的值相同，并承诺/>是否生成正确，即是否有/>=Comm(/>)。也就是说，金融机构端可以根据目标用户的金融资质证明请求，直接生成同态承诺，也可以用户端生成对金融机构端/>所存储的金融数据的承诺，并将其发送给金融机构端/>，金融机构端/>对用户端发送的承诺进行验证，将验证结果写成同态承诺。

示例性地，在本实施例中，针对每个金融机构端，还可以采用包含PedersenCommitment的同态加密技术对金融数据加密：公共参数为椭圆曲线的两个生成元，基于上述椭圆曲线，金融机构端有一对公私钥/>，其中/>。金融机构端针对目标用户的金融数据的承诺密文为/>，其中/>是Pedersen承诺，r为上述同态加密中所使用的随机数，/>是金融数据的密文。在金融机构端对金融数据进行查验时，使用私钥Sk解密时可以消除含有随机数r部分，所以无需对r做记录。解密/>＝时，先用密钥sk从/>得到/>，从而可消除含有随机数的部分得到/>。另外，为了解密金融数据的密文/>，有如下设定，即金融数据x有一个有效区间，比如[0，232]。有多种方法可以解密金融数据的密文/>，比如Pollard的Kangaroo方法，或者事先计算并保存这个区间相应的密文集，最后根据/>的值查表可确定x的值，当然本说明书并不对此进行限制。

步骤S230，发送同态承诺。具体地，金融机构端向用户端发送同态承诺。

步骤S240，对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺。具体地，用户端对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺。

示例性地，用户端对多个金融机构端发送的同态承诺进行加法同态运算。根据前述实施例，多个金融机构端记为，……，/>，目标用户在/>，……，/>中存储的金融数据记为/>，每个金融机构端生成的同态承诺记为/>。对多个同态承诺进行加法同态运算，得到的目标同态承诺可表示为/>。

步骤S250，基于目标同态承诺，利用范围证明，生成证明文件。具体地，用户端基于目标同态承诺，利用范围证明，生成证明文件。

范围证明技术是密码学领域的一种安全的证明协议，可用于证明一个数字在某一合理区间并且不泄露该数字的具体数值等信息。例如，Borromean环签名方案、Bulletproof方案、zkSNARK等零知识证明技术均可用于范围证明。具体地，首先确定一个最大范围，证明者拥有一个金额x及其对应的密文或者承诺c，其生成范围证明/>后，验证者通过验证/>以及c，就可以确定c对应的明文x是属于/>的，同时不泄漏x的任何信息。如此，有助于在隐私数据的情况下，针对数据密文进行必要的验证。更具体地，针对一个承诺c和一个范围Range，可声明如下：“我知道一个值x和一个随机数r，使得Comm/>=c，且x在范围Range之中”。其中，范围证明包含了两个函数：

Generate Proof，其中，输入x和r满足x in Range以及，则输出一个证明文件π，这个证明文件π会包含c和Range的信息。

，其中输入一个承诺c、一个范围Range和一个证明文件π，Verify输出1代表范围证明验证通过，输出0代表范围证明验证不通过。

如果用户A真的知道一个值x和一个随机数r，使得，且x在范围Range之中，那么用户A可以使Generate Proof生成一个证明π，且π一定可以通过Verify函数的验证。反过来，如果用户A并不知道这样的x和r，那么用户A无论通过什么办法都不能成功生成一个通过Verify函数的证明文件。

在本申请实施例中，利用范围证明生成的证明文件用于证明目标用户在多个金融机构端中存储的金融数据满足目标条件。目标条件可以根据目标用户向第三方机构端请求的具体业务确定，例如，目标用户想在第三方机构端中进行竞价，则目标条件根据目标用户想要竞价的具体订单确定，在一个示例中，目标条件为大于500万。

步骤S260，发送证明文件。具体地，用户端向第三方机构端发送证明文件。

步骤S270，对证明文件进行验证。具体地，第三方机构端对证明文件进行验证。

若证明文件通过第三方机构端的验证，则认为目标用户的金融数据确实满足目标条件，第三方机构端可接受目标用户的事件请求，否则，可拒绝目标用户的事件请求。

在本申请实施例中，金融机构端生成的是同态承诺，实现了多个金融机构联合证明目标用户的金融数据所具有的金融属性。同时，本申请实施例采用范围证明解决了如何证明被承诺绑定的金融数据确实满足目标条件，并且不泄露金融数据信息的问题，保护了目标用户的数据隐私安全。具体而言，目标用户获取的是各个金融机构对目标用户的金融数据的承诺，并且公布的只有一个零知识的范围证明，因此，一个金融机构并不知晓其他金融机构中存储的目标用户的金融数据，同时，第三方机构端并不知道目标用户在多个金融机构中存储的金融数据的具体值，仅仅知道这个值满足目标条件。

图3所示为本申请一示例性实施例提供的生成目标同态承诺的流程示意图。在图2所示的用户端对应的实施例的基础上，延伸出图3所示实施例，下面着重叙述图3所示实施例与图2所示实施例的不同之处，相同之处不再赘述。

如图3所示，在本申请实施例中，对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺，包括如下步骤。

步骤S310，接收多个金融机构端各自发送的电子签名。

示例性地，假设用户A拥有一对公私钥，其中PK是公钥，SK是私钥。签名算法记为/>，其中，m是任何一条消息。可以看出，签名算法需要SK作为输入，因此，只有用户A能够使用签名算法。验证算法记为/>，其中Sig是一个签名，该签名可以是由上面的签名算法生成的，也可以是恶意伪造的其他数据。若Ver算法的输出结果是1，则代表验证通过，若输出结果是0，则代表验证不通过。而当且仅当收到的签名确实是由签名算法产生的情况下，Ver算法的输出结果为1。

电子签名可证明自己确实拥有公钥PK对应的私钥SK。具体来说，如果用户B希望用户A证明自己拥有PK对应的SK，那么，用户B先向用户A随机发送一条消息m，然后用户A调用签名算法产生一个，并发送给用户B。用户B收到Sig后，调用验证算法检查用户A发送的Sig是否能通过检验。如果用户A确实拥有SK，那么用户A可以使用签名算法计算出Sig，使得用户B可以检查通过；如果用户A没有SK，那么用户A无法使用签名算法，因此用户A无法返回一个能通过验证算法的Sig。

具体来说，可利用非对称加密技术提供电子签名，这使得第三方机构端能够确认此次金融资质证明的有效性。例如，金融机构端可以对其生成的同态承诺进行电子签名，而第三方机构端可以根据金融机构端的电子签名来确认同态承诺是由金融机构端发送的。同时，电子签名也可以用于确保同态承诺在传输过程中不被篡改。例如，金融机构端将向用户端发送消息。金融机构端生成消息的哈希值，然后使用其私钥加密该哈希值以提供为加密哈希值的电子签名。金融机构端将该电子签名附加到该消息上，并将该具有电子签名的消息发送给用户端。用户端使用金融机构端的公钥解密该电子签名，并提取哈希值。用户端对消息进行哈希处理并比较哈希值。如果哈希值相同，用户端可以确认该消息确实来自金融机构端，且未被篡改。

在一个示例性中，每个金融机构端都拥有一对公私钥/>，金融机构端/>通过其拥有的私钥/>生成该金融机构的电子签名。

在另一个示例中，每个金融机构端根据其生成的同态承诺和私钥，生成电子签名，示例性地，金融机构端/>的电子签名可以表示为/>。将同态承诺作为生成电子签名的随机消息，避免了再次生成随机消息造成的计算资源消耗。

在又一示例性中，金融机构端生成电子签名前，用户端获取第三方机构端发送的验证数据，该验证数据包括用户的身份标识和随机数。用户端将验证数据发送至金融机构端。金融机构端生成同态承诺后，金融机构端根据验证数据、金融机构端的私钥和生成的同态承诺，生成电子签名。

在这种示例性场景下，用户端在向金融机构端发送金融资质证明请求时，可以将验证数据写入金融资质证明请求一并发送至金融机构端。

在本实施例中，每个金融机构端对应的电子签名可以表示为。其中，随机数s可以是不重复的数，例如，1、2、3，……，随机数也可以是当天的日期等等，只要保证不重复就行。

通过验证数据，可以保证目标用户不能重复使用金融机构端的电子签名以及不能使用其他用户的电子签名，便于第三方机构端对证明文件进行验证，以保证金融机构端生成的同态承诺确实是第三方机构端想让其证明的目标用户当前的金融数据的承诺。此外，将同态承诺和验证数据进行绑定，并结合金融机构端的私钥生成电子签名，同样减少了计算资源的消耗。

步骤S320，对多个金融机构端各自发送的同态承诺和电子签名进行验证。

首先，针对电子签名的验证：若电子签名仅仅是基于金融机构端的私钥生成的，那么，用户端可以根据金融机构端提供的公钥对电子签名进行验证。若电子签名是基于金融机构端的同态承诺、验证数据和私钥生成的，则通过金融机构端的公钥验证是否有，若等于1，则表示电子签名的验证通过，反之，电子签名未通过验证。

其次，针对金融机构端的同态承诺的验证：检查是否有，若二者相等，则表示金融机构端发送的同态承诺是真实的，否则，说明金融机构端不诚实或者同态承诺出错，本次协议结束。

步骤S330，若多个金融机构端均通过验证，则对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺。

在本申请实施例中，对多个金融机构端的同态承诺进行同态关系运算之前，首先对金融机构端发送的同态承诺和电子签名进行验证，对电子签名进行验证保证了金融机构端生成的同态承诺是经过该金融机构端签名认可的，对同态承诺进行验证保证了该承诺的真实性，也即保证了同态承诺中的金融数据的真实性。

结合图3和图2所示实施例，在接收到多个金融机构端各自发送的电子签名后，用户端将多个金融机构端对应的电子签名和同态承诺随证明文件一并发送给第三方机构端。便于第三方机构端对用户端发送的证明文件的真实性进行验证。

下面对第三方机构端对证明文件的验证过程进行详细阐述。

对多个金融机构端各自对应的电子签名进行验证；在多个金融机构端各自对应的电子签名均通过验证的情况下，基于多个金融机构端各自对应的同态承诺，对证明文件进行验证。

更具体地，对多个金融机构端各自对应的同态承诺进行同态关系运算，生成待验证同态承诺；在证明文件内，对待验证同态承诺和证明文件包含的目标同态承诺进行一致性认证；在一致性认证通过的情况下，验证目标同态承诺是否在证明文件包含的目标范围内。

也就是说，第三方机构端需要检查每个金融机构端的电子签名，这就保证了如果目标用户使用金融机构给其他用户的电子签名，或者重复使用之前从金融机构端处获得的电子签名，都会导致电子签名的验证不通过。若电子签名是基于金融机构端产生的同态承诺、私钥和验证数据确定的，则检查电子签名，即检查是否。

在电子签名验证通过的情况下，第三方机构端检查证明文件中包含的c是否等于待验证承诺。验证证明文件，即检查是/>=1。如果都验证通过，第三方机构端则接受用户的金融证明，不通过则拒绝。

在本实施例中，电子签名的验证保证了以下两点：第一，金融机构端各自对应的同态承诺都是经过金融机构端签名认可的；第二，金融机构端的电子签名里面用的验证数据确实是第三方机构端发出的，由于验证数据包含了目标用户的用户名和一个只用一次的随机数，这保证了这些金融机构端的电子签名都是签发给目标用户的，而且确实是为了这次金融资质证明新产生的电子签名，而不是使用之前的电子签名，这就保证了认证的金融数据是最新的，而不是之前的历史数据。此外，对待验证同态承诺和证明文件包含的目标同态承诺进行一致性认证，保证了证明文件中的目标同态承诺确实是经过了n个金融机构端联合认证得到的。

上文结合图2和图3，详细描述了本申请的方法实施例，下面结合图4和图5，详细描述本申请的装置实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图4所示为本申请一示例性实施例提供的资质证明装置的结构示意图。示例性地，该装置应用于用户端，用户端分别与多个金融机构端和第三方机构端连接。如图4所示，本申请实施例提供的资质证明装置40包括：

第一发送模块410，用于向多个金融机构端发送目标用户的金融资质证明请求，以便每个金融机构端响应于金融资质证明请求，基于金融机构端中存储的目标用户的金融数据，生成的同态承诺；

接收模块420，用于接收多个金融机构端各自发送的同态承诺；

运算模块430，用于对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺；

生成模块440，用于基于目标同态承诺，利用范围证明，生成证明文件，证明文件用于证明目标用户在多个金融机构端中存储的金融数据满足目标条件；

第二发送模块450，用于将证明文件发送至第三方机构端，以便第三方机构端对证明文件进行验证。

在本申请一实施例中，还包括接收模块，用于在向多个金融机构端发送目标用户的金融资质证明请求之前，获取第三方机构端发送的验证数据，验证数据包括目标用户的身份标识和随机数；将验证数据发送至多个金融机构端，以便每个金融机构端在生成同态承诺后，将同态承诺和验证数据发送至用户端；在生成证明文件之后，将证明文件和验证数据发送至第三方机构，以便第三方机构通过验证数据判断证明文件是否为针对金融资质证明请求生成的。

在本申请一实施例中，生成模块440还用于，接收多个金融机构端各自发送的电子签名；对多个金融机构端各自发送的同态承诺和电子签名进行验证；若多个金融机构端均通过验证，则对多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺。

在本申请一实施例中，金融机构端的电子签名基于金融机构端的私钥、金融机构端生成的同态承诺和验证数据得到，验证数据是由第三方机构端生成，并经用户端发送至每个金融机构端的。

在本申请一实施例中，第二发送模块450还用于，获取多个金融机构端各自对应的电子签名；将多个金融机构端各自对应的电子签名和同态承诺发送至第三方机构端，以便第三方机构端基于多个金融机构端各自对应的电子签名和同态承诺，对证明文件进行验证。

图5所示为本申请一示例性实施例提供的资质验证装置的结构示意图。示例性地，该装置应用于第三方机构端，第三方机构端与用户端连接，用户端与多个金融机构端连接。如图5所示，本申请实施例提供的资质验证装置50包括：

接收模块510，用于接收用户端发送的证明文件，证明文件是基于目标同态承诺生成的，目标同态承诺是通过对多个金融机构端各自对应的同态承诺进行同态关系运算得到的，金融机构端对应的同态承诺是基于目标用户的金融资质证明请求和金融机构端中存储的目标用户的金融数据生成的；

验证模块520，用于对证明文件进行验证，以便验证目标用户在多个金融机构端中存储的金融数据是否满足目标条件。

在本申请一实施例中，验证模块520还用于，获取多个金融机构端各自对应的电子签名和同态承诺；对多个金融机构端各自对应的电子签名进行验证；在多个金融机构端各自对应的电子签名均通过验证的情况下，基于多个金融机构端各自对应的同态承诺，对证明文件进行验证。

在本申请一实施例中，验证模块520还用于，对多个金融机构端各自对应的同态承诺进行同态关系运算，生成待验证同态承诺；在证明文件内，对待验证同态承诺和证明文件包含的目标同态承诺进行一致性认证；在一致性认证通过的情况下，验证目标同态承诺是否在证明文件包含的目标范围内。

下面，参考图6来描述根据本申请实施例的电子设备。图6所示为本申请一示例性实施例提供的电子设备的结构示意图。

如图6所示，电子设备60包括一个或多个处理器601和存储器602。

处理器601可以是中央处理单元（CPU）或者具有数据处理能力和/或指令执行能力的其他形式的处理单元，并且可以控制电子设备60中的其他组件以执行期望的功能。

存储器602可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器（RAM）和/或高速缓冲存储器（cache）等。所述非易失性存储器例如可以包括只读存储器（ROM）、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器601可以运行所述程序指令，以实现上文所述的本申请的各个实施例的方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如包括金融资质证明请求、证明文件、同态承诺、目标条件等各种内容。

在一个示例中，电子设备60还可以包括：输入装置603和输出装置604，这些组件通过总线系统和/或其他形式的连接机构（未示出）互连。

该输入装置603可以包括例如键盘、鼠标等等。

该输出装置604可以向外部输出各种信息，包括金融资质证明请求、证明文件、同态承诺、目标条件等。该输出装置604可以包括例如显示器、扬声器、打印机，以及通信网络及其所连接的远程输出设备等等。

当然，为了简化，图6中仅示出了该电子设备60中与本申请有关的组件中的一些，省略了诸如总线、输入/输出接口等等的组件。除此之外，根据具体应用情况，电子设备60还可以包括任何其他适当的组件。

除了上述方法和设备以外，本申请的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述描述的根据本申请各种实施例的方法中的步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。

此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述描述的根据本申请各种实施例的方法中的步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。

以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

本申请中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

还需要指出的是，在本申请的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。

Claims (7)

1.一种金融资质证明方法，其特征在于，应用于用户端，所述用户端分别与多个金融机构端和第三方机构端连接，所述方法包括：

向所述多个金融机构端发送目标用户的金融资质证明请求，以便每个所述金融机构端响应于所述金融资质证明请求，基于所述金融机构端中存储的所述目标用户的金融数据，生成同态承诺；

接收所述多个金融机构端各自发送的同态承诺；

对所述多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺；

基于所述目标同态承诺，利用范围证明，生成证明文件，所述证明文件用于证明所述目标用户在所述多个金融机构端中存储的金融数据满足目标条件；

将所述证明文件发送至所述第三方机构端，以便所述第三方机构端对所述证明文件进行验证；

所述对所述多个金融机构端各自发送的同态承诺进行同态关系运算，生成目标同态承诺，包括：

接收所述多个金融机构端各自发送的电子签名；

对所述多个金融机构端各自发送的同态承诺和电子签名进行验证；

若所述多个金融机构端均通过验证，则对所述多个金融机构端各自发送的同态承诺进行同态关系运算，生成所述目标同态承诺。

2.根据权利要求1所述的金融资质证明方法，其特征在于，还包括：

在向所述多个金融机构端发送所述目标用户的金融资质证明请求之前，获取所述第三方机构端发送的验证数据，所述验证数据包括所述目标用户的身份标识和随机数；

将所述验证数据发送至所述多个金融机构端，以便每个所述金融机构端在生成所述同态承诺后，将所述同态承诺和所述验证数据发送至所述用户端；

在生成所述证明文件之后，将所述证明文件和所述验证数据发送至所述第三方机构，以便所述第三方机构通过所述验证数据判断所述证明文件是否为针对所述金融资质证明请求生成的。

3.根据权利要求1所述的金融资质证明方法，其特征在于，所述金融机构端的电子签名是基于所述金融机构端的私钥、所述金融机构端生成的同态承诺和验证数据得到，所述验证数据是由所述第三方机构端生成，并经所述用户端发送至每个所述金融机构端的。

4.根据权利要求1所述的金融资质证明方法，其特征在于，在所述将所述证明文件发送至第三方机构端之后，所述方法还包括：

获取所述多个金融机构端各自对应的电子签名；

将所述多个金融机构端各自对应的电子签名和同态承诺发送至所述第三方机构端，以便所述第三方机构端基于所述多个金融机构端各自对应的电子签名和同态承诺，对所述证明文件进行验证。

5.一种金融资质验证方法，其特征在于，应用于第三方机构端，所述第三方机构端与用户端连接，所述用户端还与多个金融机构端连接，所述方法包括：

接收所述用户端发送的证明文件，所述证明文件是基于目标同态承诺生成的，所述目标同态承诺是通过对所述多个金融机构端各自对应的同态承诺进行同态关系运算得到的，所述金融机构端对应的同态承诺是基于目标用户的金融资质证明请求和所述金融机构端中存储的所述目标用户的金融数据生成的；

对所述证明文件进行验证，以便验证所述目标用户在所述多个金融机构端中存储的金融数据是否满足目标条件；

所述对所述证明文件进行验证，包括：

获取所述多个金融机构端各自对应的电子签名和同态承诺；

对所述多个金融机构端各自对应的电子签名进行验证；

在所述多个金融机构端各自对应的电子签名均通过验证的情况下，基于所述多个金融机构端各自对应的同态承诺，对所述证明文件进行验证；

所述基于所述多个金融机构端各自对应的同态承诺，对所述证明文件进行验证，包括：

对所述多个金融机构端各自对应的同态承诺进行同态关系运算，生成待验证同态承诺；

在所述证明文件内，对所述待验证同态承诺和所述证明文件包含的目标同态承诺进行一致性认证；

在所述一致性认证通过的情况下，验证所述目标同态承诺是否在所述证明文件包含的目标范围内。

6.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序用于执行上述权利要求1至5任一项所述的方法。

7.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于执行上述权利要求1至5任一项所述的方法。