数据处理方法、装置、存储介质及电子设备

技术领域

本申请涉及信息安全技术领域，具体涉及一种数据处理方法、装置、存储介质及电子设备。

背景技术

车辆出行是当代人们比较受欢迎的出行方式，对于车辆产生的资产监控数据的可信上链需求也异常强烈。在上链前，通常需要对资产监控数据进行签名，以保证源头可信，而多级签名会使得签名数据的大小翻倍，进而使得验签的时间翻倍以及上链的数据增多。

发明内容

为了解决上述技术问题，提出了本申请。本申请实施例提供了一种数据处理方法、装置、存储介质及电子设备。

第一方面，本申请一实施例提供了一种数据处理方法，应用于车辆端，车辆端与用户端配对连接，该方法包括：获取车辆端中与用户端匹配的资产监控数据；基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值；获取车辆端的私钥；基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据；将第一签名数据和资产监控数据发送至用户端，以便用户端对资产监控数据进行签名，得到第二签名数据，并生成第一签名数据和第二签名数据的聚合结果。

结合第一方面，在第一方面的某些实现方式中，资产监控数据包括碳汇资产监控数据，碳汇资产监控数据包括行驶里程数据、行驶位置数据和电池电量数据中的至少一种数据。

结合第一方面，在第一方面的某些实现方式中，基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据，包括：利用BLS签名算法，基于车辆端的私钥，对第一哈希值进行签名，生成第一签名数据。

结合第一方面，在第一方面的某些实现方式中，数据处理方法还包括：基于车辆端的私钥，生成第一公钥；将第一公钥发送至用户端，以便用户端基于第一公钥和第二公钥，生成第三公钥，其中，第二公钥是基于用户端的私钥生成的。

第二方面，本申请一实施例提供了一种数据处理方法，应用于用户端，用户端与车辆端配对连接，该方法包括：获取车辆端发送的资产监控数据和第一签名数据，第一签名数据是基于车辆端的私钥对资产监控数据进行签名生成的；基于第二哈希函数对资产监控数据进行哈希运算，得到第二哈希值；获取用户端的私钥；基于用户端的私钥对第二哈希值进行签名，生成第二签名数据；将第一签名数据和第二签名数据进行聚合，得到第三签名数据。

结合第二方面，在第二方面的某些实现方式中，数据处理方法还包括：将第三签名数据和资产监控数据发送至物联网平台，以便物联网平台基于第三签名数据，对资产监控数据验真。

结合第二方面，在第二方面的某些实现方式中，数据处理方法还包括：基于用户端的私钥，生成第二公钥；获取基于车辆端的私钥生成的第一公钥；基于第一公钥和第二公钥，生成第三公钥；将第三公钥发送至物联网平台，以便物联网平台基于第三公钥，对第三签名数据验签。

第三方面，本申请一实施例提供了一种数据处理方法，应用于物联网平台，该方法包括：获取用户端发送的资产监控数据和第三签名数据，第三签名数据为第一签名数据和第二签名数据的聚合结果，第一签名数据为车辆端对资产监控数据进行签名生成的，第二签名数据为用户端对资产监控数据进行签名生成的；获取用户端发送的第三公钥，第三公钥是第一公钥和第二公钥的聚合结果，第一公钥是基于车辆端的私钥生成的，第二公钥是基于用户端的私钥生成的；基于第三签名数据和第三公钥对资产监控数据进行验真。

结合第三方面，在第三方面的某些实现方式中，数据处理方法还包括：在验真通过的情况下，将第三签名数据和资产监控数据上传至区块链。

第四方面，本申请一实施例提供了一种数据处理装置，应用于车辆端，车辆端与用户端配对连接，该装置包括：第一获取模块，用于获取车辆端中与用户端匹配的资产监控数据；确定模块，用于基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值；第二获取模块，用于获取车辆端的私钥；生成模块，用于基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据；发送模块，用于将第一签名数据和资产监控数据发送至用户端，以便用户端对资产监控数据进行签名，得到第二签名数据，并生成第一签名数据和第二签名数据的聚合结果。

第五方面，本申请一实施例提供了一种数据处理装置，应用于用户端，用户端与车辆端配对连接，该装置包括：第一获取模块，用于获取车辆端发送的资产监控数据和第一签名数据，第一签名数据是基于车辆端的私钥对资产监控数据进行签名生成的；第一确定模块，用于基于第二哈希函数对资产监控数据进行哈希运算，得到第二哈希值；第二获取模块，用于获取用户端的私钥；生成模块，用于基于用户端的私钥对第二哈希值进行签名，生成第二签名数据；第二确定模块，用于将第一签名数据和第二签名数据进行聚合，得到第三签名数据。

第六方面，本申请一实施例提供了一种数据处理装置，应用于物联网平台，该装置包括：第一获取模块，用于获取用户端发送的资产监控数据和第三签名数据，第三签名数据为第一签名数据和第二签名数据的聚合结果，第一签名数据为车辆端对资产监控数据进行签名生成的，第二签名数据为用户端对资产监控数据进行签名生成的；第二获取模块，用于获取用户端发送的第三公钥，第三公钥是第一公钥和第二公钥的聚合结果，第一公钥是基于车辆端的私钥生成的，第二公钥是基于用户端的私钥生成的；验真模块，用于基于第三签名数据和第三公钥对资产监控数据进行验真。

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

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

本申请实施例提供的数据处理方法具有如下有益效果：

首先，利用车辆端的私钥对资产监控数据对应的第一哈希值进行签名，得到第一签名数据，减少了第一签名数据的长度，并且能够提高第一签名数据的生成效率、降低第一签名数据的数据量。其次，将第一签名数据和资产监控数据同时发送给用户端，方便用户端对资产监控数据进行签名，得到第二签名数据，并将第一签名数据和第二签名数据聚合，聚合后的签名数据的数据量相比于第一签名数据和第二签名数据有所降低，进而缩短对聚合后的签名数据的验签时间。

附图说明

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

图1所示为本申请实施例所适用的一场景示意图。

图2所示为本申请一示例性实施例提供的数据处理方法的流程示意图。

图3所示为本申请一示例性实施例提供的BLS签名算法的原理示意图。

图4所示为本申请另一示例性实施例提供的数据处理方法的流程示意图。

图5所示为本申请又一示例性实施例提供的数据处理方法的流程示意图。

图6所示为本申请一示例性实施例提供的数据处理装置的结构示意图。

图7所示为本申请另一示例性实施例提供的数据处理装置的结构示意图。

图8所示为本申请又一示例性实施例提供的数据处理装置的结构示意图。

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

具体实施方式

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

申请概述

如今车辆出行是人们比较受欢迎的出行方式，车辆在行驶过程中产生的数据往往可以作为碳汇资产换算的基础数据并打包上传，同时车辆也作为设备资产，对上述资产监控数据的可信上链的需求异常强烈。

虽然车辆智能化趋势明显，但是往往只具备简单的蓝牙芯片来和手机应用程序(Application，APP)或手机小程序连接通信，例如，电动二轮车。车辆的行驶里程、位置和电池充放电等传感器采集的数据需要通过蓝牙芯片发送到配对的用户端的手机蓝牙小程序或手机APP，然后通过用户端的手机进行中转上链。

当前的数据上链方案通常利用车辆端的蓝牙芯片对车辆端产生的资产监控数据进行签名，以确定数据源头可信，然后将签名后的数据发送至用户端的手机侧蓝牙小程序。手机侧蓝牙小程序再对数据进行签名，以确保是合法授权的手机侧蓝牙小程序在处理数据，最后手机侧把二级签名后的数据发送至物联网平台(例如，可信服务器)进行验真，在验真通过的情况下，将签名后的数据进行上链。然而，两级(可能会有更多级)签名使得签名数据大小翻倍(电动二轮车的签名和手机小程序的签名)，使得验签时间翻倍以及上链的数据相应增多。

有鉴于此，本申请提出一种数据处理方法，应用于车辆端，车辆端与用户端配对连接，该方法包括：获取车辆端中与用户端匹配的资产监控数据；基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值；获取车辆端的私钥；基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据；将第一签名数据和资产监控数据发送至用户端，以便用户端对资产监控数据进行签名，得到第二签名数据，并生成第一签名数据和第二签名数据的聚合结果。在本申请中，利用车辆端的私钥对资产监控数据对应的第一哈希值进行签名，得到第一签名数据，减少了第一签名数据的长度，并且能够提高第一签名数据的生成效率、降低第一签名数据的数据量。其次，将第一签名数据和资产监控数据同时发送给用户端，方便用户端对资产监控数据进行签名，得到第二签名数据，并将第一签名数据和第二签名数据聚合，聚合后的签名数据的数据量相比于第一签名数据和第二签名数据有所降低，进而缩短对聚合后的签名数据的验签时间。

示例性场景

图1所示为本申请实施例所适用的一场景示意图。在图1的示例中，涉及目标车辆、用户A、用户B、用户C、物联网平台(例如，服务器)以及区块链。例如，用户A、用户B和用户C均对目标车辆有用车需求，并且，物联网平台具有区块链的上链身份，可以连接到区块链网络，借助区块链，实现授权、使用、数据上传等全过程的记录和追踪。通常情况下，用户A、用户B、用户C在使用目标车辆前，利用自持的手机终端中的小程序与目标车辆进行注册和匹配，匹配成功之后，用户A、用户B、用户C就获得了授权，可以使用目标车辆。

对于未经授权，也即未与目标车辆进行注册和匹配的用户，则不能使用目标车辆。因此，在用户使用目标车辆前，首先对用户身份进行验证，验证通过的情况下，目标车辆方能响应用户的使用请求。

例如，在用户B使用目标车辆阶段，目标车辆在收到用户B的使用请求后，目标车辆会记录用户B在使用阶段车辆的行驶里程、行驶位置等数据。若目标车辆为电车，同时也会记录在整个行驶阶段的电池电量。行驶结束后，目标车辆基于车身装载的蓝牙芯片对行驶过程中记录的相关数据进行数据签名，并将签名后的数据及未签名的原始数据发送至用户B的手机终端。用户B的手机终端基于手机侧装载的蓝牙芯片对原始数据进行签名，并将手机侧签名后的数据以及目标车辆签名后的数据进行聚合，得到签名聚合数据，并再次将签名聚合数据和原始数据发送至物联网平台。物联网平台利用注册和匹配阶段获取的聚合公钥对签名聚合数据进行验签，若验签后得到的数据与原始数据一致，则将原始数据和签名聚合数据发送至区块链。

相应地，用户A和用户C对目标车辆的使用过程参照前述对用户B的描述。此外，目标车辆可以是任意类型的车辆，例如，目标车辆为二轮电动车、四轮轿车、皮卡车、共享单车等等。

示例性方法

图2所示为本申请一示例性实施例提供的数据处理方法的流程示意图。如图2所示，针对车辆端，本申请实施例提供的数据处理方法包括如下步骤。

步骤S210，获取车辆端中与用户端匹配的资产监控数据。

资产监控数据表示车辆端在行驶过程中产生的目标数据以及车辆端的设备资产数据。例如，目标数据包括行驶起点、行驶终点、行驶时间等等；设备资产数据包括车辆端对应的设备价值。

在一实施例中，目标数据可用作碳汇资产换算的基础数据，即目标数据包括碳汇资产监控数据。碳汇资产监控数据包括行驶里程数据、行驶位置数据(例如，行驶起点和行驶终点)，针对用电的车辆端，碳汇资产监控数据还包括电池电量等。

车辆在使用前，需要与用户端进行匹配。例如，用户端可以借助手机小程序与车辆端进行匹配。车辆端可以对应一个匹配的用户端，也可以对应多个匹配的用户端，未与车辆端匹配的用户则不可以使用该车辆。

步骤S220，基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值。

获取第一哈希函数，利用第一哈希函数对资产监控数据进行单向映射，即将资产监控数据映射成为一个较短的定长哈希值。从得到的第一哈希值不能反向推导出资产监控数据。

步骤S230，获取车辆端的私钥。

在密码学中，私钥是指某个用来完成加密、解密、完整性验证等密码学应用的秘密信息。车辆端的私钥可以通过车辆端自身装载的密钥生成芯片产生，也可以从外部获取，本申请实施例不限制车辆端私钥的获取方式。

步骤S240，基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据。

步骤S250，将第一签名数据和资产监控数据发送至用户端。

步骤S250的目的在于使用户端对资产监控数据进行签名，得到第二签名数据，并生成第一签名数据和第二签名数据的聚合结果。

在本申请实施例中，利用车辆端的私钥对资产监控数据对应的第一哈希值进行签名，得到第一签名数据，减少了第一签名数据的长度，并且能够提高第一签名数据的生成效率、降低第一签名数据的数据量。其次，将第一签名数据和资产监控数据同时发送给用户端，方便用户端对资产监控数据进行签名，得到第二签名数据，并将第一签名数据和第二签名数据聚合，聚合后的签名数据的数据量相比于第一签名数据和第二签名数据有所降低，进而缩短对聚合后的签名数据的验签时间。

在一种实施方式中，车辆端利用BLS签名算法，基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值。

具体地，图3所示为本申请一示例性实施例提供的BLS签名算法的原理示意图。车辆端利用BLS算法，将资产监控数据哈希到椭圆曲线。具体可以将资产监控数据进行哈希处理，并将得到的第一哈希值作为椭圆曲线上的两个点的x坐标，这两个点的y坐标不同，再进行曲线配对，即在一条曲线上取点P和点Q，并将这两个点通过公式e(P，Q)→n映射为一个数字，且该曲线不管用P和Q中的哪个点乘以一个数字x，都能得到相同的结果，即满足e(x×P，Q)＝e(P，x×Q)。

车辆端的蓝牙芯片和用户端的手机终端中的蓝牙芯片往往是算力和设计比较简单的芯片，只能提供有限的随机数，而随机数相同或者相关往往会造成私钥泄露，通过本申请中的BLS签名算法，计算得到第一哈希值，能够避免使用随机数。

在一种实施方式中，利用BLS签名算法，基于车辆端的私钥，对第一哈希值进行签名，生成第一签名数据。

具体地，在匹配到满足上述条件的椭圆曲线之后，计算关于资产监控数据对应的第一签名数据。首先，可以将资产监控数据哈希到曲线H(m1)，得到第一哈希值，并将车辆端的私钥X1乘以第一哈希值H(m1)，得到第一签名数据S1＝H(m1)×X1。

图4所示为本申请另一示例性实施例提供的数据处理方法的流程示意图。在图2所示实施例的基础上延伸出图4所示实施例，如图4所示，针对车辆端，数据处理方法还包括如下步骤。

步骤S410，基于车辆端的私钥，生成第一公钥。

示例性地，利用车辆端装载的蓝牙芯片生成车辆端的私钥X1，并基于私钥X1生成第一公钥PK1，具体地，PK1＝X1×G(G为预先设定的椭圆曲线有限域参数)。

步骤S420，将第一公钥发送至用户端。

步骤S420的目的在于用户端能够基于第一公钥和第二公钥，生成第三公钥，其中，第二公钥是基于用户端的私钥生成的。

在一种实施方式中，车辆端获取车辆端的身份标识信息和/或蓝牙芯片的地址信息，蓝牙芯片用于生成车辆端的私钥；将车辆端的身份标识信息和/或蓝牙芯片的地址信息发送至用户端，以便用户端基于身份标识信息和/或蓝牙芯片的地址信息建立用户端与车辆端的关联关系，并通过二者之间的关联关系，确定与车辆端匹配的用户终端。

在本申请实施例中，用户端使用车辆之前，需要与车辆端进行匹配。具体地，用户端可以通过手机终端与车辆端进行匹配。在匹配的过程中，车辆端会产生私钥，并根据私钥生成车辆端的公钥，最终将公钥发送至用户端，方便用户端在车辆端的第一公钥的基础上，结合用户端自身的第二公钥，进行聚合，得到聚合后的公钥。

如图2所示，针对用户端，本申请实施例提供的数据处理方法包括如下步骤。

步骤S260，获取车辆端发送的资产监控数据和第一签名数据。

第一签名数据是基于车辆端的私钥对资产监控数据进行签名生成的。

步骤S270，基于第二哈希函数对资产监控数据进行哈希运算，得到第二哈希值。

与前述相对应，获取第二哈希函数，并利用第二哈希函数对资产监控数据进行单向映射，即将资产监控数据映射为一个较短的定长哈希值，从得到的第二哈希值中不能单向推导出资产监控数据。第二哈希函数和第一哈希函数可以相同，也可以不同。

步骤S280，获取用户端的私钥。

用户端的私钥可以通过车辆端自身装载的密钥生成芯片(例如，蓝牙芯片)产生，也可以从外部获取，本申请实施例不限制用户端私钥的获取方式。

步骤S290，基于用户端的私钥对第二哈希值进行签名，生成第二签名数据。

步骤S2100，将第一签名数据和第二签名数据进行聚合，得到第三签名数据。

示例性地，对第一签名数据S1和第二签名数据S2进行聚合处理，可以将第一签名数据S1和第二签名数据S2进行相加操作，即通过公式S＝S1+S2，对第一签名数据和第二签名数据进行相加操作，得到第三签名数据S。

在本申请实施例中，通过对第二哈希值进行签名，减少了第二签名数据的长度，提高了第二签名数据的生成效率，降低了第二签名数据的数据量。并且，将第一签名数据和第二签名数据进行聚合，聚合后的签名数据的数据量相比于第一签名数据和第二签名数据降低，缩短了对第三签名数据的验签时间。

在一种实施方式中，利用BLS签名算法，生成用户端的私钥。

在一种实施方式中，利用BLS签名算法，基于第二哈希函数对资产监控数据进行哈希运算，得到第二哈希值。

继续参照图3，用户端利用BLS算法，将资产监控数据哈希到椭圆曲线，即将资产监控数据进行哈希处理，并将得到的第二哈希值作为椭圆曲线上的两个点的x坐标。

在一种实施方式中，利用BLS签名算法，基于用户端的私钥，对第二哈希值进行签名，生成第二签名数据。

具体地，可以将资产监控数据哈希到曲线H(m2)，得到第二哈希值，并将车辆端的私钥X2乘以第一哈希值H(m2)，得到第一签名数据S2＝H(m2)×X2。

同样地，利用BLS签名算法，在对资产监控数据进行签名时，能够避免使用随机数，减轻了车辆端的蓝牙芯片和用户端的手机终端中的蓝牙芯片的计算压力，保证了车辆端产生的资产监控数据的安全性。

在本申请一实施例中，将第三签名数据和资产监控数据发送至物联网平台，以便物联网平台基于第三签名数据，对资产监控数据进行验真，从而节省了计算资源和耗费的时间，提高了验证效率，进一步保证了第三签数据和资产监控数据在上链前的数据可信度。

图5所示为本申请又一示例性实施例提供的数据处理方法的流程示意图。在图2所示实施例的基础上延伸出图5所示实施例，如图5所示，在本申请实施例中，数据处理方法还包括如下步骤。

步骤S510，基于用户端的私钥，生成第二公钥。

示例性地，利用用户端的手机终端中装载的蓝牙芯片生成用户端的第二私钥X2，并基于第二私钥X2生成第二公钥PK2，具体地，PK2＝X2×G(G为预先设定的椭圆曲线有限域参数)。

步骤S520，获取基于车辆端的私钥生成的第一公钥。

步骤S530，基于第一公钥和第二公钥，生成第三公钥。

具体地，对第一公钥和第二公钥进行聚合处理，可以将第一公钥PK1和第二公钥PK2进行相加操作，签名聚合结果为P＝PK1+PK2，即第三公钥P＝PK1+PK2。

步骤S540，将第三公钥发送至物联网平台。

在一种实施方式中，用户端获取车辆端的身份标识信息和/或蓝牙芯片的地址信息；获取用户端的身份标识信息和/蓝牙芯片的地址信息，并将车辆端的身份标识信息和/蓝牙芯片的地址信息、用户端的身份标识信息和/蓝牙芯片的地址信息发送至物联网平台，以便物联网平台确定用户端和车辆端的关联关系，并根据用户端和车辆端的关联关系，获取与用户端和车辆端同时匹配的第三公钥。

在本申请实施例中，通过将车辆端的第一公钥和用户端的第二公钥聚合生成第三公钥，并将第三公钥发送至物联网平台，有便于物联网平台根据第三公钥对第三签名数据进行验签。

如图2所示，针对物联网平台，本申请实施例提供的数据处理方法包括如下步骤。

步骤S2110，获取用户端发送的资产监控数据和第三签名数据。

第三签名数据为第一签名数据和第二签名数据的聚合结果，第一签名数据为车辆端对资产监控数据进行签名生成的，第二签名数据为用户端对资产监控数据进行签名生成的。

步骤S2120，获取用户端发送的第三公钥。

第三公钥是第一公钥和第二公钥的聚合结果，第一公钥是基于车辆端的私钥生成的，第二公钥是基于用户端的私钥生成的。

步骤S2130，基于第三签名数据和第三公钥对资产监控数据进行验真。

具体地，获取车辆端的身份标识信息和/蓝牙芯片的地址信息、用户端的身份标识信息和/蓝牙芯片的地址信息，根据车辆端和用户端的上述信息，获取车辆端和用户端共同作用的第三签名。若没有正确对应的第三签名，说明用户端上传的第三签名数据和资产监控数据可能被攻击，或者用户端的第三签名数据和资产监控数据上传错误。

在获取正确对应的第三签名的情况下，利用BLS签名算法，可通过公式e(G，S)＝e(PK1，H(m1))·e(PK2，H(m2))来验证。具体可以将e(G，S1+S2)拆分为e(G，S1)·e(G，S2)；再将e(G，S1)·e(G，S2)拆分为e(G，X1×H(m1))·e(G，X2×H(m2))，以及e(G，X1×H(m1))·e(G，X2×H(m2))＝e(X1×G，H(m1))·e(X2×G，H(m2))；最后确定公式e(X1×G，H(m1))·e(X2×G，H(m2))＝e(PK1，H(m1))·e(PK2，H(m2))是否成立。

在本申请一示例性实施例中，在验真通过的情况下，将第三签名数据和资产监控数据上传至区块链。

在本申请实施例中，物联网平台基于第三公钥对第三签名数据进行验签，确定与第三签名数据对应的资产监控数据，保证数据上链前的真实可信。此外，通过第三公钥对第三签名数据进行验签，只需要一次验签就能得到第三签名数据中与资产监控数据对应的待验证数据，减少了验签次数。

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

图6所示为本申请一示例性实施例提供的数据处理装置的结构示意图。如图6所示，本申请实施例提供的数据处理装置60应用于车辆端，该装置包括：

第一获取模块610，用于获取车辆端中与用户端匹配的资产监控数据；

确定模块620，用于基于第一哈希函数对资产监控数据进行哈希运算，得到第一哈希值；

第二获取模块630，用于获取车辆端的私钥；

生成模块640，用于基于车辆端的私钥对第一哈希值进行签名，生成第一签名数据；

发送模块650，用于将第一签名数据和资产监控数据发送至用户端，以便用户端对资产监控数据进行签名，得到第二签名数据，并生成第一签名数据和第二签名数据的聚合结果。

在本申请一实施例中，资产监控数据包括碳汇资产监控数据，碳汇资产监控数据包括行驶里程数据、行驶位置数据和电池电量数据中的至少一种数据。

在本申请一实施例中，生成模块640还用于，利用BLS签名算法，基于车辆端的私钥，对第一哈希值进行签名，生成第一签名数据。

在本申请一实施例中，发送模块650还用于，基于车辆端的私钥，生成第一公钥；将第一公钥发送至所述用户端，以便用户端基于第一公钥和第二公钥，生成第三公钥，其中，第二公钥是基于用户端的私钥生成的。

图7所示为本申请一示例性实施例提供的数据处理装置的结构示意图。如图7所示，本申请实施例提供的数据处理装置70应用于用户端，该装置包括：

第一获取模块710，用于获取车辆端发送的资产监控数据和第一签名数据，第一签名数据是基于车辆端的私钥对资产监控数据进行签名生成的；

第一确定模块720，用于基于第二哈希函数对资产监控数据进行哈希运算，得到第二哈希值；

第二获取模块730，用于获取用户端的私钥；

生成模块740，用于基于用户端的私钥对第二哈希值进行签名，生成第二签名数据；

第二确定模块750，用于将第一签名数据和第二签名数据进行聚合，得到第三签名数据。

在本申请一实施例中，第二确定模块750还用于，将第三签名数据和资产监控数据发送至物联网平台，以便物联网平台基于第三签名数据，对资产监控数据验真。

在本申请一实施例中，第二确定模块750还用于，基于用户端的私钥，生成第二公钥；获取基于车辆端的私钥生成的第一公钥；基于第一公钥和第二公钥，生成第三公钥；将第三公钥发送至物联网平台，以便物联网平台基于第三公钥，对第三签名数据验签。

图8所示为本申请一示例性实施例提供的数据处理装置的流程示意图。如图8所示，本申请实施例提供的数据处理装置80应用于物联网终端，该装置包括：

第一获取模块810，用于获取用户端发送的资产监控数据和第三签名数据，第三签名数据为第一签名数据和第二签名数据的聚合结果，第一签名数据为车辆端对资产监控数据进行签名生成的，第二签名数据为用户端对资产监控数据进行签名生成的；

第二获取模块820，用于获取用户端发送的第三公钥，第三公钥是第一公钥和第二公钥的聚合结果，第一公钥是基于车辆端的私钥生成的，第二公钥是基于用户端的私钥生成的；

验真模块830，用于基于第三签名数据和第三公钥对资产监控数据进行验真。

在本申请一实施例中，验真模块830还用于，在验真通过的情况下，将第三签名数据和资产监控数据上传至区块链。

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

如图9所示，电子设备90包括一个或多个处理器901和存储器902。

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

存储器902可以包括一个或多个计算机程序产品，所述计算机程序产品可以包括各种形式的计算机可读存储介质，例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。在所述计算机可读存储介质上可以存储一个或多个计算机程序指令，处理器901可以运行所述程序指令，以实现上文所述的本申请的各个实施例的方法以及/或者其他期望的功能。在所述计算机可读存储介质中还可以存储诸如包括资产监控数据、第一哈希值、第二哈希值、第一签名数据、第二签名数据、第三签名数据、第一公钥、第二公钥和第三公钥等各种内容。

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

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

该输出装置904可以向外部输出各种信息，包括资产监控数据、第一哈希值、第二哈希值、第一签名数据、第二签名数据、第三签名数据、第一公钥、第二公钥和第三公钥。该输出装置904可以包括例如显示器、扬声器、打印机、以及通信网络及其所连接的远程输出设备等等。

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

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

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

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

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

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

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

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

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

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