一种汽车OTA车云交互方法及系统与流程

一种汽车ota车云交互方法及系统
技术领域
1.本技术涉及汽车移动通讯技术领域，具体涉及一种汽车ota车云交互方法及系统。


背景技术：

2.随着汽车智能化、网联化、电动化、共享化的普及，汽车内部软件应用越来越多，在为车主提供良好的产品体验的同时，软件问题导致的故障也将日益增加。在此背景下，汽车空间下载技术(over-the-air technology，简称ota)的使用愈发重要，车辆出现软件故障或汽车在进行功能迭代时，车主无需将汽车开到维修店，仅在车内进行简单的操作即可完成升级。不仅节省了汽车厂商的费用，同时也极大的提升了用户体验。
3.然而，在现有技术中ota技术车云交互协议采用定制化开发，各品牌车型采用的车云交互协议仅该品牌车型可以使用。导致车云交互协议通用性较差，而通用性较高的车云交互协议则存在安全性较低的问题。
4.因此，在现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。


技术实现要素：

5.本技术实施例要达到的技术目的是提供一种汽车ota车云交互方法及系统，用于解决现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。
6.为解决上述技术问题，本技术实施例提供了一种汽车ota车云交互方法，所述方法包括：
7.获得第一待处理数据，并对所述第一待处理数据进行第一预设格式的封装处理，获得第一封装处理结果；
8.构建第一签名规则，基于所述第一签名规则进行所述第一封装处理结果进行算法签名，获得第一签名结果；
9.将所述第一签名结果封装至所述第一封装处理结果，获得第二封装处理结果；
10.根据所述第一待处理数据的接口类型匹配第一密钥，并基于所述第一密钥通过预设加密算法将所述第二封装处理结果进行加密，将加密结果转为第二预设格式的第一字符串；
11.将所述第一字符串发送至汽车ota平台，获得所述汽车ota平台的第一响应结果，其中，所述第一响应结果包括验证签名；
12.通过所述第一密钥进行所述第一响应结果解密，获得第一解密数据；
13.将所述第一解密数据基于所述第一签名规则进行签名，获得第二签名结果；
14.当所述第二签名结果与所述验证签名数据一致，则验签成功，完成所述第一待处理数据的ota车云交互。
15.优选地，如上所述的方法，所述构建第一签名规则，还包括：
16.构建排序规则，其中，所述排序规则为参数名美国信息交换标准代码ascii码从小到大排序规则，且所述参数名作大小写区分；
17.构建参数值检验规则，其中，所述参数值检验规则为进行参数值校验的规则，当参数值为空或者空字符串则不参与签名；
18.构建格式校验规则，其中，所述格式校验规则包括进行文件和字段的校验规则，当识别为文件或字段时不参与签名；
19.构建新增字段规则，当接口请求报文不为注册接口时，请求报文签名增加设备标识符字段；
20.根据所述排序规则、所述参数值检验规则、所述格式校验规则和所述新增字段规则构建所述第一签名规则。
21.具体地，如上所述的方法，所述根据所述第一待处理数据的接口类型匹配第一密钥，还包括：
22.判断所述接口类型是否为第一类型接口；
23.当所述接口类型为所述第一类型接口时，则不进行加密处理，直接将所述第二封装处理结果发送至汽车ota平台。
24.进一步的，如上所述的方法，所述方法还包括：
25.当所述接口类型不是所述第一类型接口时，判断所述接口类型是否为注册接口；
26.当所述接口类型为所述注册接口时，获得第一约定值；
27.将所述第一约定值作为所述第一密钥；
28.当所述接口类型不为所述注册接口时，获得车辆secret值，将所述车辆secret值作为所述第一密钥。
29.具体地，如上所述的方法，所述方法还包括：
30.当所述接口类型不为所述注册接口时，判断所述汽车ota平台是否成功接收作为secret值的所述第一密钥；
31.当所述汽车ota平台未成功接收作为secret值的所述第一密钥时，提示异常，并将所述第一密钥调整为所述第一约定值。
32.优选地，如上所述的方法，所述方法还包括：
33.判断所述第一待处理数据是否为下载请求；
34.当所述第一待处理数据为下载请求时，进行所述汽车ota平台的文件下载，获得第一下载结果；
35.判断所述第一下载结果是否成功，当下载成功时，对所述第一下载结果的哈希值进行计算，将计算结果与所述第一下载结果中的预设哈希值比对，根据比对结果进行所述第一下载结果的有效性校验。
36.具体地，如上所述的方法，所述获得第一签名结果，还包括：
37.根据所述第一签名规则，使用统一资源定位符url键值对应的格式拼接成第二字符串；
38.对所述第二字符串使用第二密钥进行算法签名，获得所述第一签名结果。
39.本技术的另一实施例还提供了一种汽车ota车云交互系统，所述系统包括：
40.第一获得单元，用于获得第一待处理数据，并对所述第一待处理数据进行第一预
设格式的封装处理，获得第一封装处理结果；
41.第一构建单元，用于构建第一签名规则，基于所述第一签名规则进行所述第一封装处理结果进行算法签名，获得第一签名结果；
42.第二获得单元，用于将所述第一签名结果封装至所述第一封装处理结果，获得第二封装处理结果；
43.第一处理单元，用于根据所述第一待处理数据的接口类型匹配第一密钥，并基于所述第一密钥通过预设加密算法将所述第二封装处理结果进行加密，将加密结果转为第二预设格式的第一字符串；
44.第三获得单元，用于将所述第一字符串发送至汽车ota平台，获得所述汽车ota平台的第一响应结果，其中，所述第一响应结果包括验证签名；
45.第四获得单元，用于通过所述第一密钥进行所述第一响应结果解密，获得第一解密数据；
46.第五获得单元，用于将所述第一解密数据基于所述第一签名规则进行签名，获得第二签名结果；
47.第二处理单元，用于当所述第二签名结果与所述验证签名数据一致，则验签成功，完成所述第一待处理数据的ota车云交互。
48.进一步地，所述系统还包括：
49.第一构建单元，用于构建排序规则，其中，所述排序规则为参数名ascii码从小到大排序规则，且所述参数名作大小写区分；
50.第二构建单元，用于构建参数值检验规则，其中，所述参数值检验规则为进行参数值校验的规则，当参数值为空或者空字符串则不参与签名；
51.第三构建单元，用于构建格式校验规则，其中，所述格式校验规则包括进行文件和字段的校验规则，当识别为文件或字段时不参与签名；
52.第四构建单元，用于构建新增字段规则，当接口请求报文不为注册接口时，请求报文签名增加设备标识符字段；
53.第五构建单元，用于根据所述排序规则、所述参数值检验规则、所述格式校验规则和所述新增字段规则构建所述第一签名规则。
54.进一步地，所述系统还包括：
55.第一判断单元，用于判断所述接口类型是否为第一类型接口；
56.第一发送单元，用于当所述接口类型为所述第一类型接口时，则不进行加密处理，直接将所述第二封装处理结果发送至汽车ota平台。
57.进一步地，所述系统还包括：
58.第二判断单元，用于当所述接口类型不是所述第一类型接口时，判断所述接口类型是否为注册接口；
59.第六获得单元，用于当所述接口类型为所述注册接口时，获得第一约定值；
60.第三处理单元，用于将所述第一约定值作为所述第一密钥；
61.第四处理单元，用于当所述接口类型不为所述注册接口时，获得车辆secret值，将所述车辆secret值作为所述第一密钥。
62.进一步地，所述系统还包括：
63.第五处理单元，用于当所述接口类型不为所述注册接口时，判断所述汽车ota平台是否成功接收作为secret值的所述第一密钥；
64.第六处理单元，用于当所述汽车ota平台未成功接收作为secret值的所述第一密钥时，提示异常，并将所述第一密钥调整为所述第一约定值。
65.进一步地，所述系统还包括：
66.第三判断单元，用于判断所述第一待处理数据是否为下载请求；
67.第七获得单元，用于当所述第一待处理数据为下载请求时，进行所述汽车ota平台的文件下载，获得第一下载结果；
68.第七处理单元，用于判断所述第一下载结果是否成功，当下载成功时，对所述第一下载结果的哈希值进行计算，将计算结果与所述第一下载结果中的预设哈希值比对，根据比对结果进行所述第一下载结果的有效性校验。
69.进一步地，所述系统还包括：
70.第八处理单元，用于根据所述第一签名规则，使用url键值对应的格式拼接成第二字符串；
71.第八获得单元，用于对所述第二字符串使用第二密钥进行算法签名，获得所述第一签名结果。
72.本技术的再一实施例还提供了一种电子设备，包括：处理器和存储器，所述处理器与存储器耦合；所述存储器用于存储程序，所述处理器，用于通过调用，执行如上所述方法的步骤。
73.本技术的又一实施例还提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述方法的步骤。
74.与现有技术相比，本技术实施例提供的一种汽车ota车云交互方法及系统，至少具有以下有益效果：
75.本技术实施例提供的方法通过获取待处理数据，对待处理数据进行格式封装处理，获取封装处理结果。通过第一签名规则进行第一封装处理结果算法签名，获取签名结果。将签名结果封装至封装处理结果，获取第二封装处理结果。根据待处理数据的接口类型匹配密钥，并基于密钥通过加密算法将第二封装处理结果进行加密，将加密结果转字符串。将所述字符串发送至汽车ota平台，并对ota平台返回的数据进行验证，验证完成后完成待处理数据的ota车云交互。通过各种车云交互需求，实现了车云协议的标准化、平台化的软件模块，进一步提高了车云协议的通用性和安全性的技术效果。解决了现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。
附图说明
76.图1为本技术提供的一种汽车ota车云交互方法流程示意图；
77.图2为本技术提供的一种汽车ota车云交互方法中获得第一签名规则的流程示意图；
78.图3为本技术提供的一种汽车ota车云交互方法中对第一下载结果的有效性校验的流程示意图；
79.图4为本技术提供了一种汽车ota车云交互系统结构示意图；
80.图5为本技术示例性电子设备的结构示意图。
具体实施方式
81.为使本技术要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。在下面的描述中，提供诸如具体的配置和组件的特定细节仅仅是为了帮助全面理解本技术的实施例。因此，本领域技术人员应该清楚，可以对这里描述的实施例进行各种改变和修改而不脱离本技术的范围和精神。另外，为了清楚和简洁，省略了对已知功能和构造的描述。
82.应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本技术的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。
83.在本技术的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
84.应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
85.在本技术所提供的实施例中，应理解，“与a相应的b”表示b与a相关联，根据a可以确定b。但还应理解，根据a确定b并不意味着仅仅根据a确定b，还可以根据a和/或其它信息确定b。
86.本技术提供一种汽车ota车云交互方法及系统，用于针对解决现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。
87.针对上述技术问题，本技术提供的技术方案总体思路如下：
88.本技术实施例提供的方法通过获取待处理数据，对待处理数据进行格式封装处理，获取封装处理结果。通过第一签名规则进行第一封装处理结果算法签名，获取签名结果。将签名结果封装至封装处理结果，获取第二封装处理结果。根据待处理数据的接口类型匹配密钥，并基于密钥通过加密算法将第二封装处理结果进行加密，将加密结果转字符串。通过各种车云交互需求，实现了车云协议的标准化、平台化的软件模块，进一步提高了车云协议的通用性和安全性的技术效果。解决了现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。
89.在介绍了本技术基本原理后，下面，将参考附图对本技术中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本技术的一部分实施例，而不是本技术的全部实施例，应理解，本技术不受这里描述的示例实施例的限制。基于本技术的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部。
90.实施例一
91.如图1所示，本技术提供了一种汽车ota车云交互方法，所述方法包括：
92.s100：获得第一待处理数据，并对所述第一待处理数据进行第一预设格式的封装
处理，获得第一封装处理结果；
93.s200：构建第一签名规则，基于所述第一签名规则进行所述第一封装处理结果进行算法签名，获得第一签名结果；
94.具体的，ota车云交互模块用于和ota平台进行通信，该ota车云交互模块由upc模块、安全套接字协议(secure sockets layer，简称ssl)模块以及不同的协议连接libcurl模块构成，用于与ota平台进行数据交互，实现服务器注册功能，上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能。其中upc模块用于获取第一待处理数据以及对第一待处理数据进行处理，其中第一待处理数据包括实现车辆注册功能，获取服务器配置信息功能，上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能需要处理的参数数据。对处理第一封装处理结果的第一预设格式的封装进行签名，第一预设格式的封装是一种数据交换格式，此处优选为js对象简谱(javascript object notation，简称json)格式，将该数据处理方式作为明文通过第一签名规则进行签名处理，其中当第一待处理数据为实现文件下载功能时不进行签名处理。第一签名规则用于对明文进行签名，upc会将相关数据封装成第一预设格式的数据，ssl模块再将该json格式的数据按照签名规则，对数据进行签名得到第一签名结果。其中，签名规则包括排序规则、参数值检验规则、格式校验规则和新增字段规则构建所述第一签名规则，第一签名规则用于对明文进行签名。
95.s300：将所述第一签名结果封装至所述第一封装处理结果，获得第二封装处理结果；
96.具体的，将签名后的第一签名结果，封装至第一封装处理结果，获取第二封装处理结果，此时第二封装处理结果中包含了第一封装处理结果的数据形式以及通过该数据形式处理后的第一待处理数据。通过获取第二封装处理结果，由于此时该处理结果并不能获知其用于实现何种功能，且不同功能的实现需要采用不同的处理方式，因此需要在获取第二封装处理结果前对第一封装处理结果进行判断，获取第一封装处理结果中的接口数据。通过对第二封装处理结果实现了数据处理算法的封装，保证了数据的安全性。
97.s400：根据所述第一待处理数据的接口类型匹配第一密钥，并基于所述第一密钥通过预设加密算法将所述第二封装处理结果进行加密，将加密结果转为第二预设格式的第一字符串；
98.具体的，由于第一待处理数据用于实现不同功能，不同功能的实现需要采取不同的处理方式，例如当第一待处理数据的接口类型为升级日志文件上传和诊断日志文件上传接口请求时，此时第一待处理数据实际为实现文件上传功能，在实现文件上传功能时无需对文件进行加密，因此不需要获取密钥。当第一待处理数据为实现除文件上传功能和文件下载功能以外的其他功能时，第一待处理数据均需要进行加密，根据第一待处理数据的接口类型判断其所需要实现的功能，并获取对应的密钥数据即第一密钥，其中注册接口加密所使用的第一密钥为约定值，上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能接口加密数据时所使用的密钥为车辆secret值该secret值为注册成功后服务端下发的。根据第一密钥数据通过预设加密算法(优选为aes-256算法)将第二封装处理结果进行加密，将加密结果转为第二预设格式(优选为base64格式)的第一字符串，上传至汽车ota平台。
99.s500：将所述第一字符串发送至汽车ota平台，获得所述汽车ota平台的第一响应结果，其中，所述第一响应结果包括验证签名；
100.s600：通过所述第一密钥进行所述第一响应结果解密，获得第一解密数据；
101.具体的，将加密结果转为第二预设格式的第一字符串后，通过libcurl模块发送至汽车ota平台，ota平台在接收到libcurl模块发送的数据后会返回对应的数据，ota平台发送的返回数据即第一响应结果。该第一响应结果中包含验证签名数据，该验证签名数据为ota平台业务签名。因为ota平台所有接口的返回数据均使用加密，所以要对返回进行数据解密，其中注册接口加密所使用的第一密钥为约定值，上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能接口加密数据所使用的第一密钥为车辆secret值。ota平台服务端可能存在尚未获取到车辆secret之前，就返回数据给车端的情况如ota平台服务端获取secret失败，此时ota平台服务端返回的数据加密所使用的第一密钥为约定值。通过第一密钥对第一响应结果进行解密，其中第一密钥为根据第一待处理数据的接口类型匹配的密钥。通过第一密钥对第一响应结果进行解密，获取解密后的数据。
102.s700：将所述第一解密数据基于所述第一签名规则进行签名，获得第二签名结果；
103.s800：当所述第二签名结果与所述验证签名数据一致，则验签成功，完成所述第一待处理数据的ota车云交互。
104.具体的，获取解密后的数据中明文的json数据，由于不能确定此json数据是否正确，因此要进行验签操作，通过第一签名规则进行对明文的json数据进行再次签名，获得签名结果即第二签名结果。通过对第二签名结果和ota平台服务端返回的验证签名数据进行验证，当第二签名结果和ota平台服务端返回的验证签名数据一致时则验证成功，完成第一待处理数据的ota车云交互。通过各种车云交互需求，实现了车云协议的标准化、平台化的软件模块，进一步提高了车云协议的通用性和安全性的技术效果。
105.如图2所示，本技术实施例提供的方法步骤s200包括：
106.s210：构建排序规则，其中，所述排序规则为参数名ascii码从小到大排序规则，且所述参数名作大小写区分；
107.s220：构建参数值检验规则，其中，所述参数值检验规则为进行参数值校验的规则，当参数值为空或者空字符串则不参与签名；
108.s230：构建格式校验规则，其中，所述格式校验规则包括进行文件和字段的校验规则，当识别为文件或字段时不参与签名；
109.s240：构建新增字段规则，当接口请求报文不为注册接口时，请求报文签名增加设备标识符字段；
110.s250：根据所述排序规则、所述参数值检验规则、所述格式校验规则和所述新增字段规则构建所述第一签名规则。
111.具体的，签名规则包括，排序规则，其中排序规则将参数名ascii码从小到大进行排列，并且区分参数名大小写。参数值检验规则，通过参数值检验规则对参数的合法性进行校验，例如校验参数值是否为空或是否为空字符串，当参数值为空或为空字符串时则不参与签名。格式校验规则，其中格式校验规则用于对文件和字段进行校验，当识别为文件或字段时不参与签名。新增字段规则，其中新增字段规则用于当接口请求报文不为注册接口时，
此时请求报文签名增加设备标识符字段，其中设备标识符字段表示设备id。通过上述排序规则、参数值检验规则、格式校验规则和新增字段规则构建所述第一签名规则，第一签名规则用于对明文进行签名。将签名后的数据以第二预设格式传输给upc处理模块。通过获取签名规则对明文进行签名处理，进一步提高了数据的安全性。
112.本技术实施例提供的方法步骤s300包括：
113.s310：判断所述接口类型是否为第一类型接口；
114.s320：当所述接口类型为所述第一类型接口时，则不进行加密处理，直接将所述第二封装处理结果基于libcurl模块发送至汽车ota平台。
115.具体的，在获取第二封装处理结果之前还包括对第一待处理数据的接口类型进行判断，获取第一待处理数据的接口类型，当第一待处理数据的接口类型为升级日志文件上传和诊断日志文件上传接口请求时，对第二封装处理结果不进行加密处理。此时直接将第二封装处理结果通过libcurl模块将数据，上传至ota平台。然后基于libcurl中函数curl_easy_perform判断是否成功。其中，libcurl用于不同的协议连接和沟通不同服务器。
116.本技术实施例提供的方法步骤s310包括：
117.s311：当所述接口类型不是所述第一类型接口时，判断所述接口类型是否为注册接口；
118.s312：当所述接口类型为所述注册接口时，获得第一约定值；
119.s313：将所述第一约定值作为所述第一密钥；
120.s314：当所述接口类型不为所述注册接口时，获得车辆secret值，将所述车辆secret值作为所述第一密钥。
121.具体的，第一待处理数据的接口类型不是升级日志文件上传和诊断日志文件上传接口请求时，此时对第二封装处理结果需要进行加密处理。由于注册接口加密所使用的第一密钥为约定值，上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能接口加密数据时所使用的密钥为车辆secret值该secret值为注册成功后服务端下发的。因此，需要对接口类型进行判断，判断结果当接口类型为注册接口时，此时采用的加密密钥为约定的第一约定值。将第一约定值作为第一密钥，对数据进行加密。当接口类型不为注册接口时，此时接口加密数据时所使用的密钥为车辆secret值该secret值为注册成功后服务端下发的，将车辆secret值作为所述第一密钥对数据进行加密处理。
122.本技术实施例提供的方法步骤s311包括：
123.s311-1：当所述接口类型不为所述注册接口时，判断所述汽车ota平台是否成功接收作为secret值的所述第一密钥；
124.s311-2：当所述汽车ota平台未成功接收作为secret值的所述第一密钥时，提示异常，并将所述第一密钥调整为所述第一约定值。
125.具体的，第一待处理数据的接口类型不为所述注册接口时，正常情况下接口加密数据时所使用的密钥为车辆secret值，该secret值为注册成功后ota平台服务端下发的，将车辆secret值作为所述第一密钥对数据进行加密处理。由于ota平台服务端可能存在尚未获取到车辆secret，而车端依然需要对汽车ota平台进行数据传输，如ota平台服务端获取车辆secret失败，此时车端数据加密所使用的第一密钥为注册接口时约定的加密密钥，即
第一约定值。
126.如图3所示，本技术实施例提供的方法步骤s400包括：
127.s410：判断所述第一待处理数据是否为下载请求；
128.s420：当所述第一待处理数据为下载请求时，进行所述汽车ota平台的文件下载，获得第一下载结果；
129.s430：判断所述第一下载结果是否成功，当下载成功时，对所述第一下载结果的哈希值进行计算，将计算结果与所述第一下载结果中的预设哈希值比对，根据比对结果进行所述第一下载结果的有效性校验。
130.具体的，判断第一待处理数据是否为下载请求，即判断第一待处理数据是否为实现文件下载功能数据，当第一待处理数据为实现文件下载功能数据即下载请求时。通过libcurl模块进行所述汽车ota平台的文件下载，获得第一下载结果，第一下载结果为通过libcurl模块下载的文件数据。然后通过libcurl函数curl_easy_perform判断是否成功，下载完成后但尚不能确定下载的文件是否有效，通过计算下载文件的哈希值(hash)，并与下载文件中包含的文件哈希值即预设哈希值比对，当计算下载文件的哈希值与下载文件中包含的文件哈希值相同时，则判断该文件为有效文件。其中哈希值根据文件大小、时间、类型、创作着、机器等计算出来，判断下载文件的有效性。通过对下载文件的有效性进行判断，进一步提高了车云协议的安全性。
131.本技术实施例提供的方法步骤s200包括：
132.s260：根据所述第一签名规则，使用url键值对应的格式拼接成第二字符串；
133.s270：对所述第二字符串使用第二密钥进行算法签名，获得所述第一签名结果。
134.具体的，根据签名规则使用url键值对的格式(即key1＝value1&key2＝value2
…
)拼接成第二字符串。第二字符串就是签名内容，再对签名内容使用第二密钥进行加密，得到所述第一签名结果。其中，在注册接口加密所使用的第二密钥为约定值；上报车辆配置信息功能，检测新版本功能，文件下载功能，上报升级结果功能，上传文件功能等功能接口加密数据所使用的第二密钥为车辆secret值。通过对签名内容进行密钥加密进一步提高了数据的安全性。
135.综上所述，本技术实施例提供的方法通过获取待处理数据，对待处理数据进行格式封装处理，获取封装处理结果。通过第一签名规则进行第一封装处理结果算法签名，获取签名结果。将签名结果封装至封装处理结果，获取第二封装处理结果。根据待处理数据的接口类型匹配密钥，并基于密钥通过加密算法将第二封装处理结果进行加密，将加密结果转字符串。将所述字符串发送至汽车车云交互平台，并对车云交互平台返回的数据进行验证，验证完成后完成待处理数据的车车云交互，保证了车云交互数据的安全性。通过各种车云交互需求，实现了车云协议的标准化、平台化的软件模块，进一步提高了车云协议的通用性和安全性的技术效果。解决了现有技术中存在车云交互协议采用定制化开发，导致车云交互系统存在使用通用性差安全性低的技术问题。
136.实施例二
137.基于与前述实施例中一种汽车ota车云交互方法相同的发明构思，如图4所示，本技术提供了一种汽车ota车云交互系统，所述系统包括：
138.第一获得单元11，用于获得第一待处理数据，并对所述第一待处理数据进行第一
预设格式的封装处理，获得第一封装处理结果；
139.第一构建单元12，用于构建第一签名规则，基于所述第一签名规则进行所述第一封装处理结果进行算法签名，获得第一签名结果；
140.第二获得单元13，用于将所述第一签名结果封装至所述第一封装处理结果，获得第二封装处理结果；
141.第一处理单元14，用于根据所述第一待处理数据的接口类型匹配第一密钥，并基于所述第一密钥通过预设加密算法将所述第二封装处理结果进行加密，将加密结果转为第二预设格式的第一字符串；
142.第三获得单元15，用于将所述第一字符串发送至汽车ota平台，获得所述汽车ota平台的第一响应结果，其中，所述第一响应结果包括验证签名；
143.第四获得单元16，用于通过所述第一密钥进行所述第一响应结果解密，获得第一解密数据；
144.第五获得单元17，用于将所述第一解密数据基于所述第一签名规则进行签名，获得第二签名结果；
145.第二处理单元18，用于当所述第二签名结果与所述验证签名数据一致，则验签成功，完成所述第一待处理数据的ota车云交互。
146.进一步地，所述系统还包括：
147.第一构建单元，用于构建排序规则，其中，所述排序规则为参数名ascii码从小到大排序规则，且所述参数名作大小写区分；
148.第二构建单元，用于构建参数值检验规则，其中，所述参数值检验规则为进行参数值校验的规则，当参数值为空或者空字符串则不参与签名；
149.第三构建单元，用于构建格式校验规则，其中，所述格式校验规则包括进行文件和字段的校验规则，当识别为文件或字段时不参与签名；
150.第四构建单元，用于构建新增字段规则，当接口请求报文不为注册接口时，请求报文签名增加设备标识符字段；
151.第五构建单元，用于根据所述排序规则、所述参数值检验规则、所述格式校验规则和所述新增字段规则构建所述第一签名规则。
152.进一步地，所述系统还包括：
153.第一判断单元，用于判断所述接口类型是否为第一类型接口；
154.第一发送单元，用于当所述接口类型为所述第一类型接口时，则不进行加密处理，直接将所述第二封装处理结果发送至汽车ota平台。
155.进一步地，所述系统还包括：
156.第二判断单元，用于当所述接口类型不是所述第一类型接口时，判断所述接口类型是否为注册接口；
157.第六获得单元，用于当所述接口类型为所述注册接口时，获得第一约定值；
158.第三处理单元，用于将所述第一约定值作为所述第一密钥；
159.第四处理单元，用于当所述接口类型不为所述注册接口时，获得车辆secret值，将所述车辆secret值作为所述第一密钥。
160.进一步地，所述系统还包括：
discread only memory，cd rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线架构304与处理器相连接。存储器也可以和处理器集成在一起。
179.其中，存储器301用于存储执行本技术方案的计算机执行指令，并由处理器302来控制执行。处理器302用于执行存储器301中存储的计算机执行指令，从而实现本技术上述实施例提供的一种汽车ota车云交互方法。
180.本领域普通技术人员可以理解：本技术中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本技术的范围，也不表示先后顺序。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“至少一个”是指一个或者多个。至少两个是指两个或者多个。“至少一个”、“任意一个”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个、种)，可以表示：a，b，c，ab，ac，bc，或abc，其中a，b，c可以是单个，也可以是多个。
181.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程系统。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
182.本技术中所描述的各种说明性的逻辑单元和电路可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列(fpga)或其它可编程逻辑系统，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算系统的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。
183.本技术中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件单元、或者这两者的结合。软件单元可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以
向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于asic中，asic可以设置于终端中。可选地，处理器和存储媒介也可以设置于终端中的不同的部件中。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
184.此外，本技术可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。
185.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含。
186.以上所述是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。