CN117591195A - 目标应用的启动方法、装置和存储介质 - Google Patents

目标应用的启动方法、装置和存储介质 Download PDF

Info

Publication number
CN117591195A
CN117591195A CN202311534877.4A CN202311534877A CN117591195A CN 117591195 A CN117591195 A CN 117591195A CN 202311534877 A CN202311534877 A CN 202311534877A CN 117591195 A CN117591195 A CN 117591195A
Authority
CN
China
Prior art keywords
hash value
target application
signature information
file
boot loader
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311534877.4A
Other languages
English (en)
Inventor
王鹏鹏
白杨
裴丰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Foss Hangzhou Intelligent Technology Co Ltd
Original Assignee
Foss Hangzhou Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Foss Hangzhou Intelligent Technology Co Ltd filed Critical Foss Hangzhou Intelligent Technology Co Ltd
Priority to CN202311534877.4A priority Critical patent/CN117591195A/zh
Publication of CN117591195A publication Critical patent/CN117591195A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)

Abstract

本申请公开了一种目标应用的启动方法、装置和存储介质。其中，该方法包括：在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序；利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。本申请解决了车载应用的安全启动过程中出现的效率较低的技术问题。

Description

目标应用的启动方法、装置和存储介质
技术领域
本申请涉及车载控制器软件开发领域，具体而言，涉及一种目标应用的启动方法、装置和存储介质。
背景技术
随着软件定义汽车(Software Defined Vehicles,SDV)的概念的提出，汽车软件发展迅速，其功能越来越多，也变得越来越智能，汽车在为人们更好服务的同时，许多安全问题也随之出现，例如，攻击者恶意篡改汽车ECU的软件(例如，车载应用)、在可编程片上系统(System on a Chip，SOC)启动过程中，恶意软件有可能会修改SOC中的引导加载程序等固件等。
相关技术中，为了确保车载应用的安全启动，通常会在操作系统启动后、车载应用加载运行前经过多个模块的数字签名的验证，并且只有当前阶段对后续待启动的模块进行验证通过后，才会加载和执行后续的模块。
然而，在采用传统的校验方法中仅依赖软件进行校验计算的情况下，由于待验证的签名信息是存储在应用模块的CPU中，车载应用的加载是在SOC的CPU中进行的，这样在校验过程中会从Flash中读取一次应用程序数据，校验完成后还需要再次从Flash中读取一次数据，才能加载车载应用。
由于应用程序的数据量很大，重复从Flash中读取应用程序数据，耗时较长，在此情况下，如果还要经过依次通过各个模块的校验才能启动车载应用，将进一步增加车载应用的启动时间，从而导致了车载应用的安全启动过程中出现的效率较低的技术问题。
针对上述的问题，目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种目标应用的启动、装置和存储介质，以至少解决车载应用的安全启动过程中出现的效率较低的技术问题。
根据本申请实施例的一个方面，提供了一种目标应用的启动方法，包括：在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
可选地，上述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用的程序文件的第一预测哈希值，包括：在解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，其中，引导加载程序文件包括引导加载程序数据，第二预测哈希值是对引导加载程序数据进行哈希运算得到的值；利用解密密钥对第一签名信息进行解密，得到第二解密哈希值，其中，第一签名信息是预先从目标闪存中读取到的信息；在第二预测哈希值与第二解密哈希值相同的情况下，确定第一签名信息验证通过，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值。
可选地，在加载目标应用之前，上述方法还包括：在车载系统启动的过程中，从目标闪存中读取解密密钥和解密密钥的哈希值；对解密密钥执行哈希运算，得到第三预测哈希值；在解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，包括：在第三预测哈希值与解密密钥的哈希值相同的情况下，确定解密密钥校验通过，并根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值。
可选地，上述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用的程序文件的第一预测哈希值之前，方法还包括：获取非对称密钥对，其中，非对称密钥对包括解密密钥和加密密钥；将引导加载程序文件和目标应用的程序文件存储至目标闪存中，其中，引导加载程序文件携带有第一签名信息，目标应用程序文件携带有第二签名信息。
可选地，在将引导加载程序文件和目标应用的程序文件存储至目标闪存中之前，上述方法还包括：获取第一签名信息和第二签名信息；对第一签名信息与引导加载程序的第一源文件进行拼接处理，得到引导加载程序文件；对第二签名信息与目标应用的第二源文件进行拼接处理，得到目标应用程序文件。
可选地，上述获取第一签名信息和第二签名信息，包括：对第一源文件中的引导加载程序数据执行哈希运算，得到第一哈希值；利用加密密钥，对第一哈希值进行加密处理，得到第一签名信息；对第二源文件中的应用程序数据执行哈希运算，得到第二哈希值；利用加密密钥，对第二哈希值进行加密处理，得到第二签名信息。
可选地，上述获取非对称密钥对，包括：响应于目标客户端中的上位机系统发送的例程控制请求指令，生成解密密钥和加密密钥；将解密密钥和加密密钥确定为非对称密钥对。
可选地，上述利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值，包括：在加载目标应用的过程中，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；在车载系统中启动目标应用之前，上述方法还包括：在加载目标应用的过程中，判断第一预测哈希值是否与第一解密哈希值相同。
根据本申请实施例的又一方面，还提供了一种目标应用的启动装置，包括：第一处理单元，用于在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；解密单元，用于利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；第一启动单元，用于在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
根据本申请实施例的又一个方面，还提供了一种计算机可读的存储介质，其中，计算机可读的存储介质包括存储的程序，使得该计算机设备执行如以上目标应用的启动方法。
通过本申请提供的上述实施例，在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，然后将计算出来的第一预测哈希值与利用非对称密钥对中的解密密钥解密出来的第一解密哈希值进行比对，并在第一预测哈希值与第一解密哈希值相同的情况下，才启动目标应用。换句话说，本申请技术方案是边加载应用程序边进行校验计算，在加载完成后根据校验结果选择是否启动应用程序，从而在确保车载应用能够安全启动的前提下，又能减少车载应用的加载时长，解决了车载应用的安全启动过程出现的效率较低的技术问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请实施例的一种可选的目标应用的启动方法的应用环境的示意图；
图2是根据本申请实施例的一种可选的目标应用的启动方法的流程图；
图3是相关技术与本申请实施例中公钥哈希值的存储方式的对比图；
图4是相关技术与本申请实施例中校验计算和加载应用程序的对比图；
图5是根据本申请实施例的一种可选的目标应用的启动方法的整体流程图；
图6是根据本申请实施例的一种可选的目标应用的启动方法的子流程图；
图7是根据本申请实施例的另一种可选的目标应用的启动方法的子流程图；
图8是根据本申请实施例的一种可选的获取非对称密钥对的过程示意图；
图9是根据本申请实施例的一种可选的生成带有第一签名信息的引导加载程序文件和带有第二签名信息的目标应用程序文件的示意图；
图10是根据本申请实施例的一种可选的将公钥及公钥哈希值存储到目标闪存的示意图；
图11是根据本申请实施例的一种可选的公钥校验的示意图；
图12是根据本申请实施例的一种可选的对第一签名信息进行校验的示意图；
图13是根据本申请实施例的一种可选的边加载应用程序边对第二签名信息进行校验的过程示意图；
图14是根据本申请实施例的一种可选的启动目标应用的过程示意图；
图15是根据本申请实施例的一种可选的常用哈希运算的算法示意图；
图16是根据本申请实施例的一种可选的常用加密算法的示意图；
图17是根据本申请实施例的一种可选的目标应用的启动装置的示意图；
图18是根据本申请实施例的一种可选的电子设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先，对下文中出现的技术名词进行说明：
ECU：电子控制单元(Electronic Control Unit)；
Bootrom：操作系统集成的启动代码；
Bootloader：是在操作系统内核运行之前运行的一段小程序。
根据本申请实施例的一个方面，提供了一种目标应用的启动方法，可选地，作为一种可选的实施方式，上述目标应用的启动方法可以但不限于应用于如图1所示的环境中。其中，可以但不限于包括车载终端102以及服务器104，该车载终端102上可以但不限于包括显示器、处理器及存储器，该服务器104包括数据库以及处理引擎。
具体过程可如下步骤：
步骤S102，服务器104通过网络110向车载终端102发送第一签名信息验证通过指令；
步骤S104-S108，车载终端102在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
除图1示出的示例之外，上述步骤可以由车载终端或服务器独立完成，或由车载终端和服务器共同协作完成，如由车载终端102直接获取第一签名信息验证通过指令，从而减轻服务器104的处理压力。本申请并不限制车载终端102的具体实现方式。服务器104可以是单个的服务器或者是多个服务器组成的服务器集群，也可以是云服务器。
可选地，作为一种可选的实施方式，如图2所示，目标应用的启动方法可以由电子设备执行，如图1所示的用户设备或服务器，具体步骤包括：
S202，在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；
S204，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
S206，在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
为了便于理解上述目标应用的启动方法，下面先结合图3所示的关于验签过程中公钥HASH的摘要值(又可以被理解为公钥的哈希值)的存储方式进行描述。
如图3中(a)所示，相关技术中存储公钥的哈希值的方式是通过efuse或者HSM、SHE硬件模块中类似OTP的存储空间进行存储；而在如图3中(b)所示的本申请技术方案中则使用系统已有的Flash中自带的OTP用户可锁定位的专用安全区域进行公钥的哈希值的安全存储。
采用图3中(a)所示的存储方式，需要额外的硬件模块支持安全存储，无疑是增加了系统成本；因此，本申请技术方案是在系统不依赖外部硬件资源的情况下，实现公钥哈希值的安全存储的目的，降低了系统成本。
再例如，如图4中(a)所示，在相关技术中使用HSM硬件对需要加载的应用程序从Flash中读取出来进行解密校验计算通过后，SOC再从Flash加载启动应用程序。而在SOC从Flash加载到RAM的过程中可能会存在加载数据不完整的情况，如果加载的应用程序数据不完整而启动了应用程序，将会造成应用程序无法正常工作，造成不可预期的后果。
而采用如图4中(b)所示的本申请技术方案，在不使用HSM硬件的情况下，采用边加载应用程序，边进行校验计算的方式，在加载完成后根据校验结果选择是否启动应用程序方法，可以充分保证加载的应用程序的完整性。
为了更加清晰的理解上述目标应用的启动方法，下面结合如图5所示的整体流程图进一步进行描述。具体步骤如下：
S502，获取非对称加密算法RSA2048密钥对；
需要说明的是，上述非对称加密算法RSA2048仅为一种示例，并不对其进行限定，例如，还可以是如图16所示的RSA-1024、RSA-4096、AES、ECC等算法。
S504，生成带有签名信息的文件，并将带有签名信息的文件烧录到Flash中；
其中，带有签名信息的文件包括但不限于带有第一签名信息的Bootloader文件(引导加载程序文件)和带有第二签名信息的目标应用程序文件。
需要说明的是，在SOC系统上电后，首先运行的是BootRAM，这是SOC厂商出厂配置的启动文件，BootRAM从Flash中加载启动Bootloader，最后Bootloader从Flash中加载启动目标应用(APP)。
由于应用程序的数据量一般都会很大，出于对成本的考虑，都是将应用程序存储在Flash闪存中。
S506，上位机给ECU发送UDS诊断SID31触发公钥写入到Flash的Block，同时公钥HASH摘要写入Flash的OTP区域，完成公钥和公钥HASH摘要的写入后重启ECU；
步骤S506是为了将公钥以及公钥哈希值注入到Flash，下面会结合具体实施例对注入到Flash的过程进行详细描述。
S508，对公钥的有效性进行校验；
如图11所示，当ECU上电启动，首先是BootROM加载运行Bootloader程序。在Bootloader中，从Flash中的分别把公钥和公钥HASH摘要值都读取出来，然后计算公钥的HASH摘要值，计算出来的HASH摘要值与读取出来的公钥HASH摘要进行对比，如果一致，则表示公钥是可信的，可以用于签名信息的验签。如果不一致，则表示当前Flash中的公钥是不可信的，不能用于签名信息的验签，公钥校验失败，停留在Bootloader中。如果没有上述注入公钥和公钥HASH摘要操作，那么读取出来的公钥以及公钥摘要也无法校验通过。公钥校验充分保证公钥的完整性和可信度，进而保证后续的验签流程的完整性和可信度。一旦公钥存在问题，那么后续的验签流程将终止。
具体步骤可以参考图6中(b)所示，包括：
S508-1，对公钥的有效性进行校验，从Flash中读取公钥，并对读取到的公钥执行哈希运算，然后与Flash的OTP区域中的公钥哈希值进行对比；
S508-2，如果二者不一致，则一直停留在Bootloader中；
S508-3，如果二者一致，则对当前运行的Bootloader文件的第一签名信息进行校验。
对第一签名信息的校验过程可以参考上述实施例中的描述，此处不再赘述。
S510，对Bootloader文件(引导加载程序文件)的第一签名信息进行校验；
校验的具体实现方式，下面会结合具体实施例进行详细描述。
S512，对目标应用(APP)文件的第二签名信息进行校验和应用程序的加载；
对第二签名信息进行校验的过程如图7中(b)所示，包括如下步骤：
S512-1，使用RSA2048的公钥对APP文件的签名信息解密，解密出来的第一解密哈希值；
对加载到RAM中的应用程序进行哈希运算，计算得到第一预测哈希值，将第一解密哈希值与第一预测哈希值进行对比，在对比结果为二者一致的情况下，执行步骤S512-2；否则执行步骤S512-3。
需要说明的是，采用上述方式的验签过程，是从Flash中边加载APP(目标应用)应用程序到RAM，同时计算加载的数据的HASH摘要。当目标应用的程序数据加载完成后，对应的第一预测哈希值计算也将完成，然后将APP程序的签名信息读取出来，进行预测哈希值与解密出来的真实哈希值之间的对比。
S512-2，如果一致，启动运行应用程序；
如果一致，则表示当前运行的Bootloader是完整的、可信的，可以对APP进行签名信息的验签和加载启动。
S512-3，如果不一致，APP验签失败次数加1，保存至Flash，然后ECU重启复位。
如果不一致，则表示当前Bootloader是不完整的、不可信的，不能对APP进行签名信息的验签和加载启动，停留在Bootloader中，Bootloader验签过程可参考图12所示，下面会结合具体实施例对其进行详细描述。
又例如，APP程序加载和第二签名信息的验证过程可以参考图13，具体实现过程如上述步骤S512-1～S512-3，此处不再赘述。
需要说明的是，只有在上述步骤S508～S512的校验都通过的情况下，才会执行启动APP的操作，具体是通过切换PC指针指向的APP起始地址，启动APP，启动APP的步骤可以参考图14。
从图14可以看出，在车载系统中，通过目标终端发送的校验启动指令，对Bootloader文件的第一签名信息进行校验，在校验通过的情况下，启动APP程序文件的第二签名信息的校验过程，并根据校验结果，确定是否启动APP。
S514，根据APP文件的签名信息校验的校验结果(为失败的情况)，执行APP验签失败处理流程。
为了避免因验签检验计算出现错误，误判原本完整可信的应用程序文件为异常程序文件，导致验签失败无法启动。同时也为了避免如果因为APP应用程序本身是存在问题，反复进行安全启动的情况。本申请技术方案在APP应用程序验签失败后记录失败次数，保存Flash，然后ECU复位重启，再次尝试进行安全启动，如果尝试次数超过预先设定值，则直接停留在Bootloader中，不去执行安全启动过程。
具体步骤可以参考图7中(c)所示，包括：
S514-1，检查APP验签失败次数是否超过3次；
如果未超过3次，则执行步骤S514-3；否则执行步骤S514-2。
S514-2，如果尝试次数超过3次，则一直停留在Bootloader区域；
S514-3，如果尝试次数未超过3次，则跳转至对公钥的有效性进行校验的实现步骤，如跳转至步骤S508。
显然，上述3次仅为一种示例，并不对其进行限定，例如，还可以是4次、5次等。
在本申请实施例中，是采用边加载边进行校验计算的方式，相比与专利中先进行CRC(循环冗余校验)计算，待全部检验通过后再加载并启动应用程序的方式节省从了一次从Flash中读取应用程序数据的时间，缩短整个安全启动时间。
本申请实施例中，采取边加载边进行校验计算的方式，只有校验通过才会去启动应用程序，相比与专利中先校验后加载的方式，在确保加载运行的应用程序是完整的情况下，还可以提升目标应用的启动效率。
通过本申请的上述实施方式，在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，然后将计算出来的第一预测哈希值与利用非对称密钥对中的解密密钥解密出来的第一解密哈希值进行比对，并在第一预测哈希值与第一解密哈希值相同的情况下，才启动目标应用。换句话说，本申请技术方案是边加载应用程序边进行校验计算，在加载完成后根据校验结果选择是否启动应用程序，从而在确保车载应用能够安全启动的前提下，又能减少车载应用的加载时长，解决了车载应用的安全启动过程出现的效率较低的技术问题。
作为一种可选的实施方式，上述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用的程序文件的第一预测哈希值，包括：
在解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，其中，引导加载程序文件包括引导加载程序数据，第二预测哈希值是对引导加载程序数据进行哈希运算得到的值；
利用解密密钥对第一签名信息进行解密，得到第二解密哈希值，其中，第一签名信息是预先从目标闪存中读取到的信息；
在第二预测哈希值与第二解密哈希值相同的情况下，确定第一签名信息验证通过，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值。
如图12所示，只有在上述步骤S508中完成公钥检验并通过的情况下，才会进行对加载运行的Bootloader文件签名验签。该验签过程是将Flash中的Bootloader程序数据读取出来，并根据读取出来的Bootloader程序数据，计算第二预测哈希值。
然后把第一签名信息读取出来，使用RSA2048的公钥进行解密计算，得到第二解密哈希值。将第二解密哈希值与第二预测哈希值进行对比。
如果二者一致，则表示当前运行的Bootloader是完整的、可信的，可以对APP进行签名信息的验签和加载启动；如果不一致，则表示当前Bootloader是不完整的、不可信的，不能对APP进行签名信息的验签和加载启动，停留在Bootloader中。
具体步骤可以参考图7中(a)所示，包括：
S510-1，使用公钥对Bootloader文件的签名信息进行解密，解密出来的HASH摘要值与Bootloader文件计算出来的HASH摘要值进行对比；
S510-2，若计算出来的第二预测哈希值与解密出来的第二解密哈希值不一致，则一直停留在如图14所示的Bootloader运行区域。
S510-3，若计算出来的第二预测哈希值与解密出来的第二解密哈希值一致，对需要加载运行的APP文件进行验签。
采用上述方式，在ECU上电启动后，对BootROM加载运行的Bootloader程序文件进行校验，确保了出厂配置的启动文件的完整性和可靠性，为目标应用程序文件的验签过程奠定基础。
作为一种可选的示例，在加载目标应用之前，上述方法还包括：在车载系统启动的过程中，从目标闪存中读取解密密钥和解密密钥的哈希值；对解密密钥执行哈希运算，得到第三预测哈希值；
上述在解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，包括：在第三预测哈希值与解密密钥的哈希值相同的情况下，确定解密密钥校验通过，并根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值。
如图11所示，当ECU上电启动，首先是BootROM加载运行Bootloader程序。在Bootloader中，从Flash中的分别把公钥和公钥HASH摘要值都读取出来，然后计算公钥的HASH摘要值，计算出来的HASH摘要值与读取出来的公钥HASH摘要进行对比，如果一致，则表示公钥是可信的，可以用于签名信息的验签。如果不一致，则表示当前Flash中的公钥是不可信的，不能用于签名信息的验签，公钥校验失败，停留在Bootloader中。如果上述注入公钥和公钥HASH摘要操作，那么读取出来的公钥以及公钥摘要也无法校验通过。
公钥校验充分保证公钥的完整性和可信度，进而保证后续的验签流程的完整性和可信度。一旦公钥存在问题，那么后续的验签流程将终止。
采用上述方式，对整个校验过程的解密过程所使用到的解密密钥(公钥)进行校验，确保了解密密钥的有效性。
作为一种可选的实现方式，上述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用的程序文件的第一预测哈希值之前，上述方法还包括：
获取非对称密钥对，其中，非对称密钥对包括解密密钥和加密密钥；
将引导加载程序文件和目标应用的程序文件存储至目标闪存中，其中，引导加载程序文件携带有第一签名信息，目标应用程序文件携带有第二签名信息。
如图8所示，使用OpenSSL软件库包通过输入对应的指令，即可生成需要的非对称密钥对中的私钥(加密密钥)和公钥(解密密钥)。
作为一种可选的示例，上述获取获取非对称密钥对，包括：
响应于目标客户端中的上位机系统发送的例程控制请求指令，生成解密密钥和加密密钥；
将解密密钥和加密密钥确定为非对称密钥对。
使用图8所示的“oppenssl genra-out..”的例程控制请求指令，生成RSA2048密钥对，也即，生成上述非对称对密钥对中的加密密钥和解密密钥。
本申请实施例中使用的是非对称加密算法RSA，比对称加密算法AES更加安全，因为对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥，一个用来加密，一个用来解密，而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。因此，非对称加密安全性更好；
另外，本申请实施例中的使用的加密算法RSA-2048算法仅为一种示例，并不对其进行限定，例如，还可以将RSA-2048算法替换成RSA-1024、RSA-4096、AES、ECC等也可以实现本发明专利技术方案，加密算法的替换可以参考图16。
作为一种可选的实现方式，在将将引导加载程序文件和目标应用的程序文件存储至目标闪存中之前，方法还包括：
获取第一签名信息和第二签名信息；
对第一签名信息与引导加载程序的第一源文件进行拼接处理，得到引导加载程序文件；
对第二签名信息与目标应用的第二源文件进行拼接处理，得到目标应用程序文件。
对于上述步骤S504，为生成带有签名信息文件以及烧录到Flash中的过程，具体实现过程可参考图9和图6中(a)所示，包括：
S504-1，使用OpenSSL对Bootloader和APP文件进行SHA-256的HASH摘要计算，得到第一哈希值和第二哈希值；
S504-2，使用上述实施例中生成RSA2048密钥对中的私钥，对步骤S504-1中计算出来的Bootloader和APP文件的第一哈希值和第二哈希值进行加密计算，而加密计算得到的结果，即为第一源文件的第一签名信息和第二源文件的第二签名信息，其中，签名信息的长度可以但不限于是固定的256个字节；
其中，图10所示的SHA-256摘要算法(又可以被理解为哈希算法)仅为一种示例，并不对其进行限定，例如，还可以将SHA-256摘要算法替换成SHA-1、SHA-512、CRC16、CRC32、MD5等也可以实现本发明专利技术方案，具体可参考图15。
S504-3，将两个签名信息与两个源文件对应进行拼接处理，得到拼接后的引导加载程序文件和目标应用程序文件。
其中，拼接前后的文件格式保存不变，本方案使用的是BIN文件格式，即二进制格式。
作为一种可选的示例，上述根据获取第一签名信息和第二签名信息的具体步骤包括：
对第一源文件中的引导加载程序数据执行哈希运算，得到第一哈希值；利用加密密钥，对第一哈希值进行加密处理，得到第一签名信息；
对第二源文件中的应用程序数据执行哈希运算，得到第二哈希值；利用加密密钥，对第二哈希值进行加密处理，得到第二签名信息。
需要说明的是，Bootloader和APP文件的签名信息的拼接是不同的，因为ECU出厂后Bootloader程序是不会更新的，而APP程序是可以通过OTA升级更新的。所以在本申请实施中，Bootloader的签名信息拼接在原始Bootloader文件的固定位置，这个固定位置信息是写在Bootloader程序中的，这样做的目的是安全启动在验签Bootloader文件时可以准确的读取到Bootloader文件的签名信息，同时也避免了文件的签名信息数据的存储信息传播。
对于APP的签名信息则无法按照Bootloader文件将签名信息固定在某个指定。因为APP文件会升级更新，而文件的大小是不固定，无法准确的确定签名信息存储的位置。所有本方案是将APP文件的签名信息拼接在原文件的末尾，签名信息存储的位置可以动态跟随APP文件大小变化而变化。虽然签名信息存储的位置是变化的，在安全启动验签APP文件时是能够准确计算出该签名信息的存储位置。
具体做法就是在更新刷写APP文件时，如图10所示的上位机发送的UDS诊断刷写请求服务中是有当前刷写的APP文件起始位置信息和长度信息，起始位置信息就是存储到Flash中位置，将起始位置信息和长度信息保存到Flash中。又因为签名信息的长度是固定的256个字节大小，所以在安全启动验签APP文件读取签名信息时就可以通过APP的起始位置、长度信息和签名信息的长度计算出签名信息的存储在Flash中的位置。计算公式为：
签名信息地址＝App的起始地址+App的长度–签名信息长度
其中，图10所示的Routine Request即为目标客户端中的上位机系统发送的例程控制请求指令。
S504-4，将生成带有签名信息的Bootloader文件烧录到Flash中，通过上位机UDS诊断刷写的方式把APP文件更新到Flash中。
需要说明的是，如图10所示，本申请实施例中使用的是Flash中自带的OTP用户可锁定位的专用安全区域存储非对称加密算法RSA2048的公钥HASH摘要值，在安全存储公钥HASH的摘要值中不需要额外硬件资源，使用系统已有的Flash中自带的OTP用户可锁定位的专用安全区域进行公钥HASH的摘要值的安全存储。本发明在系统不依赖额外硬件资源的情况下，同样是达到了公钥HASH的摘要值安全存储，降低了系统成本。
作为一种可选的示例，上述利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值，包括：在加载目标应用的过程中，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
在车载系统中启动目标应用之前，上述方法还包括：在加载目标应用的过程中，判断第一预测哈希值是否与第一解密哈希值相同。
其中，在加载目标应用的过程中，判断第一预测哈希值是否与第一解密哈希值相同，其目的在于边加载应用程序边进行校验计算，在加载完成后根据校验结果选择是否启动应用程序，从而在确保车载应用能够安全启动的前提下，又能减少车载应用的加载时长，解决了车载应用的安全启动过程出现的效率较低的技术问题。
结合上述各实施例的描述可知，本申请技术方案通过把验签需要的公钥HASH摘要保存在Flash的OTP中，减少额外硬件资源来存储该公钥HASH摘要；通过先对原Bootloader和App文件数据计算HASH摘要，再使用RSA2048对其加密得到签名信息，减少验签的计算量同时可以在加载App的同时进行验签计算，极大程度上节省了安全启动的时间。
与相关技术相比，本申请技术方案至少存在以下有效效果：
(1)本申请实施例中使用的是Flash中自带的OTP用户可锁定位的专用安全区域存储非对称加密算法RSA2048的公钥HASH摘要值，不需要使用HSE硬件，可以降低系统成本；
(2)本申请使用的是非对称加密算法RSA，比对称加密算法AES更加安全，因为对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥，一个用来加密，一个用来解密，而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。因此非对称加密安全性更好；
(3)本申请实施例是采用边加载边进行校验计算的方式，相比与专利中先进行CRC计算，待全部检验通过后再加载并启动应用程序的方式节省从了一次从Flash中读取应用程序数据的时间，缩短整个安全启动时间；
(4)本申请实施例中，采取边加载边进行校验计算的方式，只有校验通过才会去启动应用程序，相比与专利中先校验后加载的方式，保证了加载运行的应用程序是完整的。
可以理解的是，在本申请的具体实施方式中，涉及到用户信息等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
根据本申请实施例的另一个方面，还提供了一种用于实施上述目标应用的启动方法的目标应用的启动装置。如图17所示，该装置包括：
第一处理单元1702，用于在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；
解密单元1704，用于利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
第一启动单元1706，用于在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
可选地，上述第一处理单元1702，包括：
第一处理模块，用于在解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，其中，引导加载程序文件包括引导加载程序数据，第二预测哈希值是对引导加载程序数据进行哈希运算得到的值；
第二处理模块，用于利用解密密钥对第一签名信息进行解密，得到第二解密哈希值，其中，第一签名信息是预先从目标闪存中读取到的信息；
第三处理模块，用于在第二预测哈希值与第二解密哈希值相同的情况下，确定第一签名信息验证通过，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值。可选地，上述转换单元1706，包括：
可选地，上述装置还包括：
第四处理模块，用于在加载目标应用之前，在车载系统启动的过程中，从目标闪存中读取解密密钥和解密密钥的哈希值；对解密密钥执行哈希运算，得到第三预测哈希值；
上述第一处理模块，包括：
第一处理子模块，用于在第三预测哈希值与解密密钥的哈希值相同的情况下，确定解密密钥校验通过，并根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值。
可选地，上述第一处理单元1702，还包括：
获取模块，用于获取非对称密钥对，其中，非对称密钥对包括解密密钥和加密密钥；
存储模块，用于将引导加载程序文件和目标应用的程序文件存储至目标闪存中，其中，引导加载程序文件携带有第一签名信息，目标应用程序文件携带有第二签名信息。
可选地，上述存储模块，包括：
第一获取子模块，用于获取第一签名信息和第二签名信息；
第一拼接子模块，用于对第一签名信息与引导加载程序的第一源文件进行拼接处理，得到引导加载程序文件；
第二拼接子模块，用于对第二签名信息与目标应用的第二源文件进行拼接处理，得到目标应用程序文件。
可选地，上述存储模块，还包括：
第二处理子模块，用于对第一源文件中的引导加载程序数据执行哈希运算，得到第一哈希值；利用加密密钥，对第一哈希值进行加密处理，得到第一签名信息；
第三处理子模块，用于对第二源文件中的应用程序数据执行哈希运算，得到第二哈希值；利用加密密钥，对第二哈希值进行加密处理，得到第二签名信息。
可选地，上述获取模块，包括：
第四处理子模块，用于响应于目标客户端中的上位机系统发送的例程控制请求指令，生成解密密钥和加密密钥；
第五处理子模块，用于将解密密钥和加密密钥确定为非对称密钥对。
可选地，上述解密单元1704，包括：
解密模块，用于在加载目标应用的过程中，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
上述方法还包括：第二处理单元，用于在车载系统中启动目标应用之前，在加载目标应用的过程中，判断第一预测哈希值是否与第一解密哈希值相同。
具体实施例可以参考上述目标应用的启动方法中所示示例，本示例中在此不再赘述。
根据本申请实施例的又一个方面，还提供了一种用于实施上述目标应用的启动方法的电子设备，该电子设备可以但不限于为图1中所示的车载终端102或服务器104，本实施例以电子设备为车载终端102为例说明，进一步如图18所示，该电子设备包括存储器1802和处理器1804，该存储器1802中存储有计算机程序，该处理器1804被设置为通过计算机程序执行上述任一项方法实施例中的步骤。
可选地，在本实施例中，上述电子设备可以位于计算机网络的多个网络设备中的至少一个网络设备。
可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：
S1，在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；
S2，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
S3，在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
可选地，本领域普通技术人员可以理解，图18所示的结构仅为示意，图18其并不对上述电子设备的结构造成限定。例如，电子设备还可包括比图18中所示更多或者更少的组件(如网络接口等)，或者具有与图18所示不同的配置。
其中，存储器1802可用于存储软件程序以及模块，如本申请实施例中的目标应用的启动方法和装置对应的程序指令/模块，处理器1804通过运行存储在存储器1802内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的目标应用的启动方法。存储器1802可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1802可进一步包括相对于处理器1804远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。其中，存储器1802具体可以但不限于用于存储第一签名信息、第一预测哈希值和第一解密哈希值。作为一种示例，如图18所示，上述存储器1802中可以但不限于包括上述目标应用的启动装置中的第一处理单元1702、解密单元1704及第一启动单元1706。此外，还可以包括但不限于上述目标应用的启动装置中的其他模块单元，本示例中不再赘述。
可选地，上述的传输装置1806用于经由一个网络接收或者发送数据。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置1806包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置1806为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。
此外，上述电子设备还包括：显示器1808，用于显示上述任务时序信息、第一子任务数据、以及第二子任务数据等信息；和连接总线1810，用于连接上述电子设备中的各个模块部件。
在其他实施例中，上述用户设备或者服务器可以是一个分布式系统中的一个节点，其中，该分布式系统可以为区块链系统，该区块链系统可以是由该多个节点通过网络通信的形式连接形成的分布式系统。其中，节点之间可以组成点对点(Peer To Peer，简称P2P)网络，任意形式的计算设备，比如服务器、用户设备等电子设备都可以通过加入该点对点网络而成为该区块链系统中的一个节点。
根据本申请的一个方面，提供了一种计算机程序产品，该计算机程序产品包括计算机程序/指令，该计算机程序/指令包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理器执行时，执行本申请实施例提供的各种功能。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
需要说明的是，电子设备的计算机系统仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
计算机系统包括中央处理器(Central Processing Unit，CPU)，其可以根据存储在只读存储器(Read-Only Memory，ROM)中的程序或者从存储部分加载到随机访问存储器(Random Access Memory，RAM)中的程序而执行各种适当的动作和处理。在随机访问存储器中，还存储有系统操作所需的各种程序和数据。中央处理器、在只读存储器以及随机访问存储器通过总线彼此相连。输入/输出接口(Input/Output接口，即I/O接口)也连接至总线。
以下部件连接至输入/输出接口：包括键盘、鼠标等的输入部分；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分；包括硬盘等的存储部分；以及包括诸如局域网卡、调制解调器等的网络接口卡的通信部分。通信部分经由诸如因特网的网络执行通信处理。驱动器也根据需要连接至输入/输出接口。可拆卸介质，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器上，以便于从其上读出的计算机程序根据需要被安装入存储部分。
特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理器执行时，执行本申请的系统中限定的各种功能。
根据本申请的一个方面，提供了一种计算机可读存储介质，计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的方法。
可选地，在本实施例中，上述计算机可读的存储介质可以被设置为存储用于执行以下步骤的计算机程序：
S1，在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，引导加载程序文件包括引导加载程序的第一源文件和第一签名信息，引导加载程序是车载系统启动之前运行的初始化程序，第一签名信息是利用非对称密钥对中的加密密钥对第一源文件的哈希值进行加密得到的信息，目标应用程序文件包含目标应用的第二源文件和第二签名信息，第二签名信息是利用加密密钥对第二源文件的哈希值进行加密得到的信息；
S2，利用非对称密钥对中的解密密钥，对第二签名信息进行解密，得到第一解密哈希值；
S3，在第一预测哈希值与第一解密哈希值相同的情况下，在车载系统中启动目标应用。
可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令电子设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。
在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的用户设备，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种目标应用的启动方法，其特征在于，包括：
在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载所述目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，所述引导加载程序文件包括引导加载程序的第一源文件和所述第一签名信息，所述引导加载程序是车载系统启动之前运行的初始化程序，所述第一签名信息是利用非对称密钥对中的加密密钥对所述第一源文件的哈希值进行加密得到的信息，所述目标应用程序文件包含所述目标应用的第二源文件和第二签名信息，所述第二签名信息是利用所述加密密钥对所述第二源文件的哈希值进行加密得到的信息；
利用所述非对称密钥对中的解密密钥，对所述第二签名信息进行解密，得到第一解密哈希值；
在所述第一预测哈希值与所述第一解密哈希值相同的情况下，在所述车载系统中启动所述目标应用。
2.根据权利要求1所述的方法，其特征在于，所述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载所述目标应用的过程中确定所述目标应用的程序文件的第一预测哈希值，包括：
在所述解密密钥校验通过的情况下，根据从目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，其中，所述引导加载程序文件包括所述引导加载程序数据，所述第二预测哈希值是对所述引导加载程序数据进行哈希运算得到的值；
利用所述解密密钥对所述第一签名信息进行解密，得到第二解密哈希值，其中，所述第一签名信息是预先从所述目标闪存中读取到的信息；
在所述第二预测哈希值与所述第二解密哈希值相同的情况下，确定所述第一签名信息验证通过，加载所述目标应用，并在加载所述目标应用的过程中确定所述目标应用程序文件的所述第一预测哈希值。
3.根据权利要求2所述的方法，其特征在于，
在加载目标应用之前，所述方法还包括：在所述车载系统启动的过程中，从所述目标闪存中读取所述解密密钥和所述解密密钥的哈希值；对所述解密密钥执行哈希运算，得到第三预测哈希值；
所述在所述解密密钥校验通过的情况下，根据从所述目标闪存中读取到的引导加载程序数据，确定第二预测哈希值，包括：在所述第三预测哈希值与所述解密密钥的哈希值相同的情况下，确定所述解密密钥校验通过，并根据从所述目标闪存中读取到的所述引导加载程序数据，确定所述第二预测哈希值。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述在引导加载程序文件的第一签名信息验证通过的情况下，加载目标应用，并在加载所述目标应用的过程中确定所述目标应用的程序文件的第一预测哈希值之前，所述方法还包括：
获取所述非对称密钥对，其中，所述非对称密钥对包括所述解密密钥和所述加密密钥；
将所述引导加载程序文件和所述目标应用的程序文件存储至所述目标闪存中，其中，所述引导加载程序文件携带有所述第一签名信息，所述目标应用程序文件携带有所述第二签名信息。
5.根据权利要求4所述的方法，其特征在于，在将所述引导加载程序文件和所述目标应用的程序文件存储至所述目标闪存中之前，所述方法还包括：
获取所述第一签名信息和所述第二签名信息；
对所述第一签名信息与所述引导加载程序的所述第一源文件进行拼接处理，得到所述引导加载程序文件；
对所述第二签名信息与所述目标应用的所述第二源文件进行拼接处理，得到所述目标应用程序文件。
6.根据权利要求5所述的方法，其特征在于，所述获取所述第一签名信息和所述第二签名信息，包括：
对所述第一源文件中的引导加载程序数据执行哈希运算，得到第一哈希值；利用所述加密密钥，对所述第一哈希值进行加密处理，得到所述第一签名信息；
对所述第二源文件中的应用程序数据执行哈希运算，得到第二哈希值；利用所述加密密钥，对所述第二哈希值进行加密处理，得到所述第二签名信息。
7.根据权利要求4所述的方法，其特征在于，所述获取所述非对称密钥对，包括：
响应于目标客户端中的上位机系统发送的例程控制请求指令，生成所述解密密钥和所述加密密钥；
将所述解密密钥和所述加密密钥确定为所述非对称密钥对。
8.根据权利要求1至3中任一项所述的方法，其特征在于，
所述利用所述非对称密钥对中的解密密钥，对所述第二签名信息进行解密，得到第一解密哈希值，包括：在加载所述目标应用的过程中，利用所述非对称密钥对中的解密密钥，对所述第二签名信息进行解密，得到第一解密哈希值；
在所述车载系统中启动所述目标应用之前，所述方法还包括：在加载所述目标应用的过程中，判断所述第一预测哈希值是否与所述第一解密哈希值相同。
9.一种目标应用的启动装置，其特征在于，包括：
第一处理单元，用于在引导加载程序文件中包括的第一签名信息验证通过的情况下，加载目标应用，并在加载所述目标应用的过程中确定目标应用程序文件的第一预测哈希值，其中，所述引导加载程序文件包括引导加载程序的第一源文件和所述第一签名信息，所述引导加载程序是车载系统启动之前运行的初始化程序，所述第一签名信息是利用非对称密钥对中的加密密钥对所述第一源文件的哈希值进行加密得到的信息，所述目标应用程序文件包含所述目标应用的第二源文件和第二签名信息，所述第二签名信息是利用所述加密密钥对所述第二源文件的哈希值进行加密得到的信息；
解密单元，用于利用所述非对称密钥对中的解密密钥，对所述第二签名信息进行解密，得到第一解密哈希值；
第一启动单元，用于在所述第一预测哈希值与所述第一解密哈希值相同的情况下，在所述车载系统中启动所述目标应用。
10.一种计算机可读的存储介质，其特征在于，所述计算机可读的存储介质包括存储的程序，其中，所述程序被电子设备运行时执行所述权利要求1至8任一项中所述的方法。
CN202311534877.4A 2023-11-16 2023-11-16 目标应用的启动方法、装置和存储介质 Pending CN117591195A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311534877.4A CN117591195A (zh) 2023-11-16 2023-11-16 目标应用的启动方法、装置和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311534877.4A CN117591195A (zh) 2023-11-16 2023-11-16 目标应用的启动方法、装置和存储介质

Publications (1)

Publication Number Publication Date
CN117591195A true CN117591195A (zh) 2024-02-23

Family

ID=89909242

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311534877.4A Pending CN117591195A (zh) 2023-11-16 2023-11-16 目标应用的启动方法、装置和存储介质

Country Status (1)

Country Link
CN (1) CN117591195A (zh)

Similar Documents

Publication Publication Date Title
US10372914B2 (en) Validating firmware on a computing device
CN102830992B (zh) 插件加载方法及系统
JP4501349B2 (ja) システムモジュール実行装置
CN112507328B (zh) 一种文件签名方法、计算设备及存储介质
KR20210151926A (ko) 블록체인을 사용한 버전 이력 관리
US10853472B2 (en) System, apparatus and method for independently recovering a credential
WO2021073375A1 (zh) 一种组合式设备远程证明模式的协商方法及相关设备
Mbakoyiannis et al. Secure over-the-air firmware updating for automotive electronic control units
CN113221166A (zh) 一种获取区块链数据的方法、装置、电子设备及存储介质
US8646070B1 (en) Verifying authenticity in data storage management systems
CN111125725A (zh) 一种镜像校验的加解密方法、设备及介质
US20220224546A1 (en) Software integrity protection method and apparatus, and software integrity verification method and apparatus
KR20170089352A (ko) 가상화 시스템에서 수행하는 무결성 검증 방법
CN111177709A (zh) 一种终端可信组件的执行方法、装置及计算机设备
US11307790B2 (en) Method, device, and computer program product for managing data placement
CN112597485A (zh) 基于区块链的信息校验方法、装置和设备及存储介质
CN112632573A (zh) 智能合约执行方法、装置、系统、存储介质及电子设备
CN112148314A (zh) 一种嵌入式系统的镜像验证方法、装置、设备及存储介质
CN112637307B (zh) 文件更新方法、系统、计算机设备及存储介质
CN115242413A (zh) 物联网设备固件安全升级方法、装置、电子设备及介质
CN111400771A (zh) 目标分区的校验方法及装置、存储介质、计算机设备
CN113056739A (zh) 到瞬态、非持久性存储电路中的文件系统的验证和安装
CN117591195A (zh) 目标应用的启动方法、装置和存储介质
CN113360914A (zh) 一种bios更新的方法、系统、设备及介质
CN112866195A (zh) 敏捷数据传输方法、装置、计算机设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination