一种诊断刷写过程数据合法性验证方法及其系统
技术领域
本发明涉及车辆应用技术中的诊断刷写数据安全领域，尤其涉及一种诊断刷写过程数据合法性验证方法及其系统。
背景技术
目前，针对ECU控制器通过总线诊断刷写方式进行应用程序数据更新时，或通过OTA方式进行数据更新时，由于刷写文件保存和转移的影响，无法保证待刷写文件是可靠的、是来自合法有效来源的。如果使用了这类的刷写文件，ECU即使诊断刷写成功，但却会出现功能异常，甚至无法作动等现象。
发明内容
本发明的目的在于提供一种诊断刷写过程数据合法性验证方法及其系统。
本发明采用的技术方案是：
一种诊断刷写过程数据合法性验证方法，其包括以下步骤：
步骤1，在后端服务器平台上，将待刷写的文件结合随机给定的随机数，利用加密算法得到个固定长度的哈希值；
步骤2，将固定长度的哈希值同分配的私钥结合，使用公开密钥算法计算得到签名；
步骤3，当执行软件升级更新时，ECU控制器接收待刷写的数据文件以及对应的签名；
步骤4， ECU控制器内部将收到的签名和已存储在非易失性存储器的公钥通过验证系统的反函数计算得出哈希值和随机数；
步骤5， ECU控制器完整收到数据文件利用反算得出的随机数利用加密算法得到第二哈希值；
步骤6，比对哈希值和第二哈希值的值是否一致；当一致时，则判定当前待刷写的数据文件是正确合法的；反之，则该数据文件不属于ECU控制器的应用程序数据。
进一步地，步骤1中在后端服务器平台上，将待刷写的文件Flash File中的数据Flash Data，叠加平台随机给定的随机数Salt (32 bytes)，通过SHA256算法计算得出一个固定长度的哈希值Hash Value1(32 bytes)；
进一步地，步骤2中固定长度的哈希值Hash Value1(32 bytes)同分配的私钥PrivateKey(256 bytes)结合，使用RSA算法计算得到签名Signature (32 bytes)；
进一步地，步骤4中通过验证系统RSA-1的反函数计算得出哈希值Hash Value1(32bytes)和随机数Salt (32 bytes)。
一种诊断刷写过程数据合法性验证系统，采用了权利要求1至4任一所述的一种诊断刷写过程数据合法性验证方法，其特征在于：系统包括后端服务器平台和ECU控制器，
后端服务器平台包括以下模块：
随机数生成模块，用于随机给定的随机数用于加密算法；
公钥生成模块，用于提供公钥数据；
私钥生成模块，用于提供私钥数据；
签名模块，用于获取随机数并计算哈希值，结合私钥数据利用公开密钥算法得到签名；
数据文件存储模块，用于存储数据文件；
ECU控制器，获得公钥并集成至ECU的芯片内部；获取数据文件及其签名，并结合公钥通过验证系统的反算得出哈希值和随机数；同时将接收的数据文件利用反算得出的随机数利用加密算法得到第二哈希值，并比对哈希值和第二哈希值的值是否一致。
本发明采用以上技术方案，在源头处先对待刷写文件进行签名处理。接着，在进行诊断刷写时，ECU控制器接收刷写文件和正确刷写文件对应的签名，并在内部对文件数据反算得出校验值，同接收的签名进行对比。若一致，则说明刷写文件是合法有效无误的；否则，刷写文件是错误的。本发明是对诊断刷写在数据安全上的补充，通过签名验证，保证了ECU软件升级的可靠合法，也是OTA平台系统文件数据安全的扩展。
附图说明
以下结合附图和具体实施方式对本发明做进一步详细说明；
图1为本发明一种诊断刷写过程数据合法性验证方法的流程示意图；
图2为本发明一种诊断刷写过程数据合法性验证系统的架构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图对本申请实施例中的技术方案进行清楚、完整地描述。
如图1或图2所示，本发明公开了一种诊断刷写过程数据合法性验证方法，其包括以下步骤：
步骤1，在后端服务器平台上，将待刷写的文件结合随机给定的随机数，利用加密算法得到个固定长度的哈希值；
步骤2，将固定长度的哈希值同分配的私钥结合，使用公开密钥算法计算得到签名；
步骤3，当执行软件升级更新时，ECU控制器接收待刷写的数据文件以及对应的签名；
步骤4， ECU控制器内部将收到的签名和已存储在非易失性存储器的公钥通过验证系统的反函数计算得出哈希值和随机数；
步骤5， ECU控制器完整收到数据文件利用反算得出的随机数利用加密算法得到第二哈希值；
步骤6，比对哈希值和第二哈希值的值是否一致；当一致时，则判定当前待刷写的数据文件是正确合法的；反之，则该数据文件不属于ECU控制器的应用程序数据。
具体地，如图1所示，①表示在后端服务器平台上，将待刷写的文件Flash File中的数据Flash Data，叠加平台随机给定的随机盐Salt (32 bytes)，通过SHA256算法计算得出一个固定长度的哈希值Hash Value1(32 bytes)；
②表示固定长度的哈希值Hash Value1(32 bytes)同分配的私钥Private Key(256bytes)结合，使用RSA算法计算得到签名Signature (32 bytes)；
③表示后端服务器平台发送签名至ECU控制器；
④表示待刷写的文件Flash File发送至ECU控制器；
⑤表示当开始执行软件升级更新时，ECU控制器接收来自③的签名Signature和④待刷写的数据文件Flash File；
⑥ 表示ECU控制器内部将收到的签名Signature (32 bytes)和已存储在非易失性存储器的公钥Public Key(256 bytes)通过验证系统RSA-1反函数计算得出哈希值HashValue1(32 bytes)和随机盐Salt (32 bytes)；
⑦表示另一方面，ECU控制器完整收到Flash File中的File Data，以及⑥中反算得出的随机盐Salt (32 bytes)，也经过SHA256算法得到Hash Value2 (32 bytes)。
⑧表示比对Hash Value1和Hash Value2的值是否一致。若一致，则说明此次待刷写的数据文件是正确合法的；反之，则该文件不属于ECU控制器的应用程序数据。
如图2所示，一种诊断刷写过程数据合法性验证系统，包括后端服务器平台和ECU控制器，
后端服务器平台包括以下模块：
随机数生成模块，用于随机给定的随机数用于加密算法；
公钥生成模块，用于提供公钥数据；
私钥生成模块，用于提供私钥数据；
签名模块，用于获取随机数并计算哈希值，结合私钥数据利用公开密钥算法得到签名；
数据文件存储模块，用于存储数据文件；
ECU控制器，获得公钥并集成至ECU的芯片内部；获取数据文件及其签名，并结合公钥通过验证系统的反算得出哈希值和随机数；同时将接收的数据文件利用反算得出的随机数利用加密算法得到第二哈希值，并比对哈希值和第二哈希值的值是否一致。
具体地，后端服务器平台系统功能：随机数Salt自动生成、密钥对（公钥PublicKey和私钥Private Key）建立分管、签名Signature生成、待刷写文件Flash File管理存储。ECU供应商从平台获得公钥Public Key，并集成至ECU的芯片内部，以供计算时掉用。
本发明采用以上技术方案，在源头处先对待刷写文件进行签名处理。接着，在进行诊断刷写时，ECU控制器接收刷写文件和正确刷写文件对应的签名，并在内部对文件数据反算得出校验值，同接收的签名进行对比。若一致，则说明刷写文件是合法有效无误的；否则，刷写文件是错误的。本发明是对诊断刷写在数据安全上的补充，通过签名验证，保证了ECU软件升级的可靠合法，也是OTA平台系统文件数据安全的扩展。
显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
