CN111935317B - 车辆信息验证方法及装置、计算机可读存储介质 - Google Patents

车辆信息验证方法及装置、计算机可读存储介质 Download PDF

Info

Publication number
CN111935317B
CN111935317B CN202011031197.7A CN202011031197A CN111935317B CN 111935317 B CN111935317 B CN 111935317B CN 202011031197 A CN202011031197 A CN 202011031197A CN 111935317 B CN111935317 B CN 111935317B
Authority
CN
China
Prior art keywords
key
ecu
vehicle
ciphertext
encrypted
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.)
Active
Application number
CN202011031197.7A
Other languages
English (en)
Other versions
CN111935317A (zh
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.)
Evergrande New Energy Automobile Investment Holding Group Co Ltd
Original Assignee
Evergrande New Energy Automobile Investment Holding Group 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 Evergrande New Energy Automobile Investment Holding Group Co Ltd filed Critical Evergrande New Energy Automobile Investment Holding Group Co Ltd
Priority to CN202011031197.7A priority Critical patent/CN111935317B/zh
Publication of CN111935317A publication Critical patent/CN111935317A/zh
Application granted granted Critical
Publication of CN111935317B publication Critical patent/CN111935317B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Lock And Its Accessories (AREA)

Abstract

本申请公开了一种车辆信息验证方法及装置、计算机可读存储介质，用以解决车辆防盗安全性低的问题。车辆信息验证方法包括：接收车辆的第二ECU发送的密钥种子；获取第三密钥，以利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥；组合第一密钥与密钥种子以确定第一被加密明码；获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同；发送第一密文至第二ECU，以使第二ECU根据预定的参考码对第一密文进行验证，预定的参考码为第二ECU根据第一密钥和第二密钥进行计算得到的。本申请实施例的方案可以提高车辆的电子防盗安全等级，降低车辆被盗的风险，并提高ECU的信息安全性能，降低受网络攻击的风险。

Description

车辆信息验证方法及装置、计算机可读存储介质
技术领域
本申请涉及车辆安全技术领域，尤其涉及一种车辆信息验证方法及装置、计算机可读存储介质。
背景技术
目前，为降低车辆的防盗安全风险，通常利用密钥生成算法来生成防盗密钥，但目前的算法复杂程度和参数灵活度低，密钥类型单一，流出风险大，算法容易被破解。且算法一旦被盗流出，则整车的安全防盗会被攻破。
如何提高车辆的防盗安全性，是本申请所要解决的技术问题。
发明内容
本申请实施例的目的是提供一种车辆信息验证方法及装置、计算机可读存储介质，用以解决车辆防盗安全性低的问题。
为了解决上述技术问题，本申请是这样实现的：
第一方面，提供了一种车辆信息验证方法，执行在车辆的第一电子控制单元ECU，该方法包括：接收车辆的第二ECU发送的密钥种子；获取第三密钥，以利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥；组合第一密钥与密钥种子以确定第一被加密明码；获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同；发送第一密文至第二ECU，以使第二ECU根据预定的参考码对第一密文进行验证，其中预定的参考码为第二ECU根据第一密钥和第二密钥进行计算得到的。
可选的，利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥，包括：确定第一ECU的名称对应的ASCII码值和第一ECU的零部件号对应的十六进制值；根据ASCII码值和十六进制值确定第二被加密明码；利用第三密钥对第二被加密明码进行加密生成第一密钥。
可选的，根据ASCII码值和十六进制值确定第二被加密明码，包括：将ASCII码值、十六进制值和预定的填充值组合得到预定字节数的第二被加密明码。
可选的，组合第一密钥与密钥种子以确定第一被加密明码，包括：将第一密钥与密钥种子组合得到预定字节数的第一被加密明码。
可选的，第二密钥为与车辆的车辆识别号码对应的随机数。
可选的，第一密钥和/或第二密钥存储在第一ECU中。
第二方面，提供了一种车辆信息验证方法，执行在诊断设备，该方法包括：向车辆的待诊断ECU发送访问请求；接收待诊断ECU响应的密钥种子；获取第三密钥，以利用第三密钥对待诊断ECU的名称和零部件号进行加密生成第一密钥；组合第一密钥与密钥种子以确定第一被加密明码；获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同；将第一密文发送至待诊断ECU进行验证，并在验证通过后访问待诊断ECU。
第三方面，提供了一种车辆信息验证装置，包括存储器和与存储器电连接的处理器，存储器存储有可在处理器运行的计算机程序，该计算机程序被该处理器执行时实现如第一方面或第二方面所述的车辆信息验证方法的步骤。
第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现如第一方面或第二方面所述的车辆信息验证方法的步骤。
本申请通过接收车辆的第二ECU发送的密钥种子；获取第三密钥，以利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥；组合第一密钥与密钥种子以确定第一被加密明码；获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同；发送第一密文至第二ECU，以使第二ECU根据预定的参考码对第一密文进行验证，其中预定的参考码为第二ECU根据第一密钥和第二密钥进行计算得到的，从而能够大大提升车辆的电子防盗安全性能。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是本申请第一实施例的车辆信息验证方法的流程示意图;
图2是本申请实施例的第一密钥生成步骤的流程示意图;
图3为本申请第一实施例的车辆信息验证方法应用场景示意图;
图4为本申请第一实施例的加密密钥示意图;
图5为本申请第二实施例的加密密钥示意图;
图6是本申请第二实施例的车辆信息验证方法的流程示意图;
图7为本申请第二实施例的车辆信息验证方法应用场景示意图;
图8为本申请第三实施例的车辆信息验证方法应用场景示意图;
图9为本申请第三实施例的加密密钥示意图;
图10是本申请第一实施例的车辆控制装置的结构示意图;
图11是本申请第二实施例的车辆控制装置的结构示意图;
图12是本申请第三实施例的车辆控制装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请中附图编号仅用于区分方案中的各个步骤，不用于限定各个步骤的执行顺序，具体执行顺序以说明书中描述为准。
为了解决现有技术中存在的问题，本申请实施例提供一种车辆信息验证方法，该方法执行在车辆的第一电子控制单元（Electronic Control Unit，ECU）。
车辆内部的ECU例如包括远程信息处理器（Telematics BOX）、无钥匙进入及启动（Passive Entry Passive Start, PEPS）系统等等与防盗相关的ECU。
为了提高车辆的电子防盗安全性，本申请提出了在车辆内部的两个ECU之间执行防盗认证的车辆信息验证方法，例如该实施例的车辆信息验证方法在上述第一ECU上执行，并与第二ECU进行交互验证。这里，第二ECU看作向第一ECU发起防盗认证的发起方，第一ECU看作响应第二ECU的防盗认证请求的响应方。
如图1所示，该实施例的车辆信息验证方法包括以下步骤：
S102，接收车辆的第二ECU发送的密钥种子。
在步骤S102中，第二ECU发送的密钥种子可以是该ECU生成的随机数，或者是预先写入并存储在第二ECU中的随机数。密钥种子为随机数，无法通过某一固定算法来计算，可增加后续由该密钥种子生成的密文被破解的难度。
第二ECU向第一ECU发送密钥种子，即表示向第一ECU发起防盗认证请求，以验证第一ECU是否通过防盗认证。
S104，获取第三密钥，以利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥。
在步骤S104中，第三密钥是对应加密算法使用的具有对应字节数的密钥，例如随机数。
第一密钥可以在接收到第二ECU发送的密钥种子后，根据第三密钥生成。也可以事先生成后预先存储在第一ECU中或外部服务器中，并在收到密钥种子后从第一ECU内部读取第一密钥，或者从外部服务器获取第一密钥。可选的，第一密钥可以是由第一ECU生成的；或者由外部服务器生成，并在整车下线时写入并存储到第一ECU内部。
在步骤S104中，生成第一密钥的第一ECU的名称和零部件号都是唯一的。根据第二ECU发送密钥种子的操作，第一ECU可以判断需要获取的第一密钥类型，以用于防盗认证场景下。
利用第三密钥对ECU唯一的名称和零部件号进行加密，生成对应第一密钥，可使得每个不同的ECU对应生成的第一密钥也是完全不同的，由此每个ECU具有不同的算法，无法移植破解不同的ECU的第一密钥，可增加利用第一密钥确定的密文的破解难度，提高ECU的信息安全性。在将上述加密得到的密文用于车辆内部的ECU之间的防盗认证时，进而可提高车辆的电子防盗安全等级，降低车辆被盗的风险，并提高ECU的信息安全性能，降低受网络攻击的风险。
S106，组合第一密钥与密钥种子以确定第一被加密明码。
可选的，组合第一密钥与密钥种子确定第一被加密明码，可以是将第一密钥与密钥种子组合得到预定字节数的第一被加密明码。第一密钥和密钥种子分别具有预定的字节数，将二者组合起来得到的第一被加密明码的字节数为二者对应的字节数之和。
第一被加密明码的字节数与后续使用的加密算法有关，例如如果使用高级加密标准（The Advanced Encryption Standard，AES）128算法，则第一被加密明码的字节数为16字节。然而，第一密钥和密钥种子的字节数可以不是固定值，例如，对应使用AES128加密算法的情况，二者分别对应的字节数之和为16字节即可。
在第一被加密明码中，密钥种子是可见的，第一密钥可以隐藏在第一被加密明码中，为不可见状态。
S108，获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同。
将可见的密钥种子进一步与隐藏的第一密钥组合得到第一被加密明码，再通过利用第二密钥，对具有第一密钥的第一被加密明码进行二次加密，并得到第一密文，可以显著提高第一密文被攻破的难度。
同样地，获取第二密钥可以为从第一ECU本地读取第二密钥，或者也可以从外部服务器获取第二密钥。
可选的，在步骤S108中，第二密钥为与车辆的车辆识别号码（VIN）对应的随机数。一个VIN对应一系列预定字节数的随机数，该随机数可以是十六进制。随机数与VIN的对应关系绑定后，可以按对长期加密存储在特定的服务器存储系统中，例如长期存储（LongTime Storage）系统中。在获取第二密钥时，可以在服务器存储系统里面通过车辆的VIN号来查询到对应绑定的密钥。
第二密钥为随机数，因此也无法通过某一固定算法来计算，如此进一步增加了所生成的第一密文的破解难度。
获取的第二密钥可以是由第一ECU生成的；或者由外部服务器生成，并在整车下线时写入并存储到第二ECU内部。
可选的，第二密钥还可以是写入并存储到防盗相关的ECU内部的参数值。
通过提前将第一密钥和/或第二密钥存储在第一ECU中，在利用第一密钥和第二密钥生成对应的密文并进行安全防盗认证时，可以提高ECU之间的安全防盗认证的速度。
每次生成的第二密钥需与之前生成的密钥进行比较，不能出现重复的密钥。此外，第二密钥不能全是0或F，其中全0表示第二密钥对应进制的最小值，全F表示第二密钥对应进制的最大值。由此，提高密钥的信息安全性。
加密算法可以为AES128算法、数据加密标准（Data Encryption Standard， DES）算法等。
S110，发送第一密文至第二ECU，以使第二ECU根据预定的参考码对第一密文进行验证，其中预定的参考码为第二ECU根据第一密钥和第二密钥进行计算得到的。
在步骤S110中，第一ECU响应第二ECU的防盗认证请求，将步骤S108确定的第一密文发送到第二ECU，从而第二ECU可以根据第一ECU返回的响应密文，验证第一ECU是否能够通过防盗认证。
第二ECU和第一ECU端均存储有相同的第一密钥和第二密钥，第二ECU在接收到第一密文之后，可以按照S106-S108的步骤，利用第二ECU端的第一密钥和第二密钥，对发送的密钥种子同步进行加密运算，得到进行验证的参考码。或者参考码为根据第一密钥和第二密钥事先计算好的预定参考码。通过将加密运算得到的预定的参考码与第一密文进行比对，对第一密文进行验证，从而可以验证第一ECU是否通过防盗认证。具体地，若预定的参考码与第一密文相同，则判定为第一ECU通过防盗认证；否则，判定为第一ECU未通过防盗认证。
可选的，根据本申请的一个实施例，生成第一密钥的步骤如图2所示，图2为本申请实施例的第一密钥生成步骤的流程示意图，包括以下步骤：
S302，确定第一ECU的名称对应的ASCII码值。
第一ECU的名称对应的ASCII码值可以是配置有固定的字节数，例如4个字节，当然本申请不局限于该具体的实施例。
S304，确定第一ECU的零部件号对应的十六进制值。
例如，PEPS的ECU的零部件号为60005588，则其对应转换的十六进制数值HEX为0393 0C D4。
在其他实施例中，根据所使用的加密算法的不同，零部件号也可以为其他进制，例如十进制，本申请不局限于该具体的实施例。
S306，根据ASCII码值和十六进制值确定第二被加密明码。
可选的，根据ASCII码值和十六进制值确定第二被加密明码包括：将ASCII码值、十六进制值和预定的填充值组合得到预定字节数的第二被加密明码。
如上文所述，第一ECU的名称对应的ASCII码值可以是配置有固定的字节数，如果少于该固定的字节数，则可以利用为随机符号的ASCII码进行填充，例如ASCII码：23(#)补全为固定的字节数。利用随机符号进行补全填充，而不利用随机数，可以避免填充的随机数与第一ECU的名称对应的ASCII码值混淆。
根据所使用的加密算法的需要，在第一ECU的名称对应的ASCII码值的字节数与零部件号对应的十六进制值的字节数之和与加密算法所需的字节数不匹配时，可以增加填充值。例如对于使用AES128加密算法的情况，在ASCII码值的字节数与十六进制值的字节数之和小于16字节时，需要增加预定字节数的填充值，以将组合后的第二被加密密钥补全为16字节。可选的，填充值默认依次从A1、B2、C3…递增，当然本申请不局限该具体实施例。
S308，利用第三密钥对第二被加密明码进行加密生成第一密钥。
在步骤S308中，第三密钥是对应加密算法使用的具有对应字节数的密钥，该字节数与第二被加密明码的字节数相同。在一个实施例中，第三密钥可以是将整个第二被加密明码按字节倒序排列确定的，当然本申请不局限于该实施例。
在步骤308中，利用第三密钥对第二被加密明码进行加密可以生成预定字节数的第二密文，其中第一密钥可以选取第二密文中的全部或部分字节，例如可以从第二密文中选择前面预定字节数作为第一密钥，或者选择后面预定字节数，或者随机选择预定字节数，本申请不局限于该具体实施例。
上述步骤确定的第一密钥可以在第一ECU内部生成，也可以在外部服务器生成后通过整车下线流程预存储在相关ECU当中。在通过外部服务器生成的情况下，ECU内部对零部件号和名称不做任何算法处理，仅直接获取外部服务器生成的第一密钥，并将之与收到的密钥种子结合成第一被加密明码，然后再使用第二密钥进行加密，得到第一密文。
下面，将结合图3至图4的具体示例对本申请上述实施例的车辆信息验证方法进行描述，其中图3为本申请实施例的车辆信息验证方法应用场景示意图，图4为本申请第一实施例的加密密钥示意图。在该实施例中，使用的加密算法例如是AES128，其中密钥字数𝑁𝑘 =4, 数据块字数 𝑁𝑏 = 4, 迭代轮数𝑁𝑟 = 10, 电码本（Electronic Codebook，ECB）模式。该加密算法对应的加密密钥字节数为16字节。
如上文所述，本申请实施例的车辆信息验证方法，在车辆内部的两个ECU之间执行防盗认证。这里， ECU发起方为第一ECU发起防盗认证的第二ECU， ECU响应方为响应第二ECU的防盗认证请求的第一ECU。
参考图3， ECU发起方向ECU响应方发送密钥种子。密钥种子12如图4所示，ECU发起方对应的8字节。
ECU响应方接收密钥种子，并获取或生成第一密钥，例如图4所示8字节的SC 14。并将8字节的SC 14与密钥种子12组合得到16字节的被加密的明码16。
对于ECU为PEPS的ECU响应方，即图4的PEPS响应方获取第二密钥，例如图4所示的16字节的ISK 18，并使用AES128加密算法利用ISK 18对明码16进行加密，得到16字节的密文，例如图4所示的16字节的密文20。
在图4实施例中，PEPS响应方可以回复8字节作为第一密文22发送给ECU发起方。其中，第一密文22的前两位0x00、0x00为预留的两字节，用于标识防盗认证相关状态，后面6个字节为对应从密文20中提取的前6个字节。
图4中，[16]表示字节数为16，明码[16]表示明码16的字节数为16位，ISK[16]表示第二密钥的ISK字节数为16位，密文[16]表示密文20的字节数为16位。下图中，[ ]出现的数字的含义与此相同解释，不再赘述。
如上文所述，第一密钥是根据第一ECU的名称和零部件号生成，下面结合图5的实施例对生成第一密钥涉及的加密密钥进行说明。
在该实施例中，以ECU为PEPS为例，其中PEPS的零部件号为60005588。
如图5所示，PEPS的名称对应的ASCII码值为16字节明码32的前4位，PEPS的零部件号对应的十六进制值为16字节明码32的中间4位，填充值为明码32的后8位。第三密钥，即图5的16字节密钥34，这里密钥34是整个明码32按字节倒序排列确定的。利用上述AES128加密算法，使用密钥34对被加密明码32进行加密，可以得到对应的第二密文，即图5所示的密文36。第一密钥，即图5所示的密钥38可以是从密文36中取前8个字节得到的。
上述实施例描述了本申请的车辆信息验证方法应用于车辆内部的两个ECU之间进行防盗认证的场景，响应方ECU通过接收发起方ECU的密钥种子，并利用响应方ECU的名称和零部件号生成的第一密钥，和密钥种子一起确定被加密的明码，然后利用第二密钥再次对前述确定的明码进行加密，并将得到的密文发送至发起方ECU进行验证。如此，通过两种类型的密钥对密钥种子进行多重加密，并进行验证，能够提高密钥流出后车辆的安全防盗被攻破的难度，进而提高车辆的电子防盗安全等级，降低车辆被盗的风险。并提高ECU的信息安全性能，降低受网络攻击的风险。
本申请通过与ECU名称及零部件号绑定，使得不同的零部件号/名称的ECU生成不同的第一密钥值。即不同零部件号/名称的ECU均具有不同的算法，因此即使流出也无法移植破解不同ECU的防盗密钥。第二密钥为预定字节数的随机数，生成后与当前车辆的VIN号进行绑定，并可以加密存储在服务器存储系统当中，在需要该密钥时通过特定授权进行查询。由于第二密钥是随机数，无法通过某一固定算法来计算，因此，大大提升车辆的电子防盗安全性能。
为了解决现有技术中存在的问题，本申请实施例提供一种车辆信息验证方法，该方法执行在诊断设备，诊断设备可以是与待诊断ECU位于同一车辆内部的ECU，也可以是外部的诊断工具，从而实现诊断设备对待诊断ECU的安全访问。
如图6所示，该实施例的车辆信息验证方法包括以下步骤：
S402，向车辆的待诊断ECU发送访问请求。
S404，接收待诊断ECU响应的密钥种子。
响应的密钥种子确定方法可以与上述图1至图5对应实施例的密钥种子相同，这里不在赘述。
S406，获取第三密钥，以利用第三密钥对待诊断ECU的名称和零部件号进行加密生成第一密钥。
这里，生成第一密钥的方式可以与上述图1至图5对应实施例的第一密钥相同，这里不在赘述。
S408，组合第一密钥与密钥种子以确定第一被加密明码。
确定第一被加密明码的方式可以与上述图1至图5对应实施例相同，这里不在赘述。
S410，获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同。
同样地，获取第二密钥的方式可以与上述图1至图5对应实施例的第二密钥相同，这里不在赘述。
S412，将第一密文发送至待诊断ECU进行验证，并在验证通过后访问待诊断ECU。
发送第一密文的确定方式可以与上述图1至图5对应实施例的第一密文相同，这里不在赘述。
在诊断设备为与待诊断ECU位于同一车辆内部的ECU时，诊断设备与待诊断ECU的交互方式如图7所示，图7为本申请第二实施例的车辆信息验证方法应用场景示意图。
如图7所示，内部诊断ECU向待诊断ECU发送访问请求，待诊断ECU响应请求，向内部诊断ECU发送密钥种子。内部诊断ECU接收密钥种子，并获取第三密钥生成第一密钥，然后与密钥种子组合得到对应的被加密明码。内部诊断ECU还获取第二密钥，并使用加密算法利用第二密钥对被加密明码进行加密，得到对应的密文。然后，内部诊断ECU将密文发送给待诊断ECU。
待诊断ECU和内部诊断ECU端可以均存储有相同的第一密钥和第二密钥，其中第一密钥可以为事先根据第三密钥生成的，待诊断ECU在接收到密文之后，利用内部存储的第一密钥和第二密钥，对其发送的密钥种子同步进行加密运算，或者通过事先已利用第一密钥和第二密钥进行加密运算，得到预定的参考码。通过将加密运算得到的预定的参考码与内部诊断ECU发送的密文进行比对，以进行验证，从而可以验证内部诊断ECU是否通过验证。具体地，预定的参考码与密文相同，则表示内部诊断ECU通过验证，可以安全访问待诊断ECU并进行诊断；否则，未通过，则无法访问待诊断ECU。
通过提前将第一密钥和/或第二密钥存储在ECU中，在利用第一密钥和第二密钥生成对应的密文并进行诊断安全访问时，可以提高诊断ECU响应待诊断ECU的安全访问的速度。
在诊断设备为外部的诊断工具时，诊断设备与待诊断ECU的交互方式如图8所示，图8为本申请第三实施例的车辆信息验证方法应用场景示意图。
该实施例如图7的区别在于，待诊断ECU与外部诊断工具直接交互，但是外部诊断工具在接收到待诊断ECU的密钥种子后，需要将密钥种子发送至服务器，由服务器从存储系统中获取对应的第一密钥和第二密钥，并结合密钥种子进行加密运算，得到对应的密文。然后将密文发送至外部诊断工具，并进一步由外部诊断工具发送至待诊断ECU进行访问验证。
可选的，在一个实施例中，外部诊断工具在收到待诊断ECU的密钥种子后，可以不将密钥种子发送至服务器，而是仅从服务器的存储系统中获取对应的第一密钥和第二密钥，结合密钥种子进行加密运算的步骤可以由外部诊断工具完成，并得到对应的密文。然后，将密文发送至待诊断ECU进行访问验证。
该实施例的车辆信息验证方法涉及的加密密钥可以参考图9，图9为本申请第三实施例的加密密钥示意图。在该实施例中，待诊断ECU例如为PEPS，诊断设备例如为图7实施例的内部诊断ECU，当然也可以是图8实施例的外部的诊断工具。使用的加密算法例如是AES128，其中密钥字数𝑁𝑘 = 4, 数据块字数 𝑁𝑏 = 4, 迭代轮数𝑁𝑟 = 10， ECB模式，该加密算法对应的加密密钥字节数为16字节。
在图9中，诊断设备发送2字节的访问请求42，待诊断ECU_PEPS响应8字节的密钥种子，例如图9所示响应请求44的后8位字节为密钥种子，其中前2位字节表示诊断服务的响应报文头。诊断设备生成或获取已生成的PEPS对应的8字节的第一密钥，即图9所示的SC_PEPS对应的密钥46，其中第一密钥可以根据图5相同的方式生成，并将密钥种子和密钥46组合得到16字节的明码48。诊断设备获取第二密钥，例如图9所示16字节的ASK 50，并利用AES128加密算法使用ASK 50对明码48进行加密运算，得到对应的16字节密文52。诊断设备可以将密文52中的前6位字节提取作为第一密文，并与前4位字节的报文信息一起组成密文54发送至待诊断ECU_PEPS，由待诊断ECU_PEPS进行验证。待诊断ECU_PEPS会根据验证结果，向诊断设备发送验证响应信息56。
上述实施例描述了本申请的车辆信息验证方法应用于对车辆内部ECU进行安全访问以进行诊断的场景，诊断设备向车辆内部的待诊断ECU发送访问请求，待诊断ECU响应请求向诊断设备发送密钥种子，诊断设备根据自身存储或生成的第一密钥，或者外部存储系统获取的第一密钥和第二密钥，将第一密钥和密钥种子一起确定被加密的明码，然后利用第二密钥再次对前述确定的明码进行加密，并将得到的密文发送至待诊断ECU进行验证。如此，通过两种类型的密钥对密钥种子进行多重加密，并进行验证，能够提高密钥流出后车辆的安全防盗被攻破的难度，进而提高车辆的电子防盗安全等级，降低车辆被盗的风险。并提高ECU的信息安全性能，降低受网络攻击的风险。
本申请通过与ECU名称及零部件号绑定，使得不同的零部件号/名称的ECU生成不同的第一密钥值。即不同零部件号/名称的ECU均具有不同的算法，因此无法移植破解不同ECU的防盗密钥。第二密钥为预定字节数的随机数，生成后与当前车辆的VIN号进行绑定，并可以加密存储在服务器存储系统当中，在需要该密钥时通过特定授权进行查询。由于第二密钥是随机数，无法通过某一固定算法来计算，因此，大大提升车辆的电子防盗安全性能。
可选的，为了解决现有技术中存在的问题，本申请实施例还提供一种车辆信息验证装置，该装置执行在车辆的第一ECU，如图10所示，该装置1000包括：
接收模块1200，用于接收车辆的第二ECU发送的密钥种子；
第一生成模块1300，用于获取第三密钥，以利用第三密钥对第一ECU的名称和零部件号进行加密生成第一密钥；
确定模块1400，用于组合第一密钥与密钥种子以确定第一被加密明码；
第二生成模块1600，用于获取第二密钥，以利用第二密钥对第一被加密明码进行加密生成第一密文，第二密钥和第一密钥不同；
发送模块1800，用于发送第一密文至第二ECU，以使第二ECU根据预定的参考码对第一密文进行验证，其中预定的参考码为第二ECU根据第一密钥和第二密钥进行计算得到的。
本申请实施例提供的车辆信息验证装置能够实现图1至图5的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
可选的，为了解决现有技术中存在的问题，本申请实施例还提供一种车辆信息验证装置，该装置执行在诊断设备，如图11所示，该装置2000包括：
第一发送模块2200，向车辆的待诊断ECU发送访问请求；
接收模块2400，用于接收待诊断ECU响应的密钥种子；
第一生成模块2500，用于获取第三密钥，以利用第三密钥对待诊断ECU的名称和零部件号进行加密生成第一密钥；
确定模块2600，用于组合第一密钥与密钥种子以确定第一被加密明码；
第二生成模块2800，用于获取第二密钥，以利用第二密钥对第一被加密明码进行加密以生成第一密文，第二密钥和第一密钥不同；
第二发送模块2900，用于将第一密文发送至待诊断ECU进行验证，并在验证通过后访问待诊断ECU。
本申请实施例提供的车辆信息验证装置能够实现图6至图9的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
可选的，本申请实施例还提供一种车辆信息验证装置，如图12所示，车辆信息验证装置3000包括存储器3200和与存储器3200电连接的处理器3400，存储器3200存储有可在处理器3400运行的计算机程序，该计算机程序被处理器3400执行时实现上述任意一种车辆信息验证方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
可选的，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述一种车辆信息验证方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器（Read-Only Memory，简称ROM）、随机存取存储器（RandomAccess Memory，简称RAM）、磁碟或者光盘等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (9)

1.一种车辆信息验证方法，其特征在于，执行在车辆的第一ECU，所述方法包括：
接收所述车辆的第二ECU发送的密钥种子；
获取第三密钥，以利用所述第三密钥对所述第一ECU的名称和零部件号进行加密生成第一密钥；
组合所述第一密钥与所述密钥种子以确定第一被加密明码，其中，在所述第一被加密明码中，所述密钥种子为可见状态，所述第一密钥为不可见状态；
获取第二密钥，以利用所述第二密钥对所述第一被加密明码进行加密生成第一密文，所述第二密钥和所述第一密钥不同；
发送所述第一密文至所述第二ECU，以使所述第二ECU根据预定的参考码对所述第一密文进行验证，其中所述预定的参考码为所述第二ECU根据所述第一密钥和所述第二密钥进行计算得到的。
2.如权利要求1所述的方法，其特征在于，利用所述第三密钥对所述第一ECU的名称和零部件号进行加密生成第一密钥，包括：
确定所述第一ECU的名称对应的ASCII码值和所述第一ECU的零部件号对应的十六进制值；
根据所述ASCII码值和所述十六进制值确定第二被加密明码；
利用所述第三密钥对所述第二被加密明码进行加密生成所述第一密钥。
3.如权利要求2所述的方法，其特征在于，根据所述ASCII码值和所述十六进制值确定第二被加密明码，包括：
将所述ASCII码值、所述十六进制值和预定的填充值组合得到预定字节数的所述第二被加密明码。
4.如权利要求1所述的方法，其特征在于，组合所述第一密钥与所述密钥种子以确定第一被加密明码，包括：
将所述第一密钥与所述密钥种子组合得到预定字节数的所述第一被加密明码。
5.如权利要求1所述的方法，其特征在于，所述第二密钥为与所述车辆的车辆识别号码对应的随机数。
6.如权利要求1所述的方法，其特征在于，
所述第一密钥和/或所述第二密钥存储在所述第一ECU中。
7.一种车辆信息验证方法，其特征在于，执行在诊断设备，所述方法包括：
向车辆的待诊断ECU发送访问请求；
接收所述待诊断ECU响应的密钥种子；
获取第三密钥，以利用所述第三密钥对所述待诊断ECU的名称和零部件号进行加密生成第一密钥；
组合所述第一密钥与所述密钥种子以确定第一被加密明码，其中，在所述第一被加密明码中，所述密钥种子为可见状态，所述第一密钥为不可见状态；
获取第二密钥，以利用所述第二密钥对所述第一被加密明码进行加密生成第一密文，所述第二密钥和所述第一密钥不同；
将所述第一密文发送至所述待诊断ECU进行验证，并在验证通过后访问所述待诊断ECU。
8.一种车辆信息验证装置，其特征在于，包括：存储器和与所述存储器电连接的处理器，所述存储器存储有可在所述处理器运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述的车辆信息验证方法的步骤。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的车辆信息验证方法的步骤。
CN202011031197.7A 2020-09-27 2020-09-27 车辆信息验证方法及装置、计算机可读存储介质 Active CN111935317B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011031197.7A CN111935317B (zh) 2020-09-27 2020-09-27 车辆信息验证方法及装置、计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011031197.7A CN111935317B (zh) 2020-09-27 2020-09-27 车辆信息验证方法及装置、计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN111935317A CN111935317A (zh) 2020-11-13
CN111935317B true CN111935317B (zh) 2021-01-01

Family

ID=73333647

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011031197.7A Active CN111935317B (zh) 2020-09-27 2020-09-27 车辆信息验证方法及装置、计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN111935317B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110138642B (zh) * 2019-04-15 2021-09-07 深圳市纽创信安科技开发有限公司 一种基于can总线的安全通信方法和系统
WO2022133945A1 (zh) * 2020-12-24 2022-06-30 华为技术有限公司 密钥写入方法及装置
CN113162928B (zh) * 2021-04-19 2023-03-31 广州小鹏汽车科技有限公司 通信方法、装置、ecu、车辆及存储介质
CN114844627A (zh) * 2021-06-28 2022-08-02 长城汽车股份有限公司 一种车辆密钥防盗方法、系统、电子设备及车辆
CN116488813B (zh) * 2023-06-26 2023-08-18 合众新能源汽车股份有限公司 车辆及其通信安全认证方法、装置、电子设备和存储介质
CN117729051B (zh) * 2024-02-04 2024-05-10 慧翰微电子股份有限公司 一种mcu软件升级的双向安全校验方法及汽车控制系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103404112A (zh) * 2011-03-04 2013-11-20 丰田自动车株式会社 车辆网络系统
CN105119900A (zh) * 2015-07-17 2015-12-02 北京奇虎科技有限公司 信息安全传输方法、联网接入方法及相应的终端
CN109286500A (zh) * 2018-09-30 2019-01-29 百度在线网络技术（北京）有限公司 车辆电子控制单元ecu认证方法、装置及设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721149B (zh) * 2016-04-25 2019-02-26 北汽福田汽车股份有限公司 一种车联网系统会话密钥生成及车载终端与ecu绑定的方法
CN108347331B (zh) * 2017-01-25 2021-08-03 北京百度网讯科技有限公司 车联网系统中T_Box设备与ECU设备进行安全通信的方法与设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103404112A (zh) * 2011-03-04 2013-11-20 丰田自动车株式会社 车辆网络系统
CN105119900A (zh) * 2015-07-17 2015-12-02 北京奇虎科技有限公司 信息安全传输方法、联网接入方法及相应的终端
CN109286500A (zh) * 2018-09-30 2019-01-29 百度在线网络技术（北京）有限公司 车辆电子控制单元ecu认证方法、装置及设备

Also Published As

Publication number Publication date
CN111935317A (zh) 2020-11-13

Similar Documents

Publication Publication Date Title
CN111935317B (zh) 车辆信息验证方法及装置、计算机可读存储介质
CN106533655B (zh) 一种车内网ecu安全通信的方法
CN102546155B (zh) 立即响应式安全密钥生成方法和系统
KR101378784B1 (ko) 동산, 특히 차량을 무단 사용으로부터 보호하는 방법
CN106572106B (zh) 一种tbox终端和tsp平台之间报文传输的方法
US9450937B2 (en) Vehicle network authentication system, and vehicle network authentication method
CN102118246A (zh) 在车辆和远程设备间进行非对称密钥交换的系统和方法
CN104583028B (zh) 单向密钥卡和交通工具配对
CN107276748B (zh) 一种汽车的无钥匙进入与启动系统的密钥导出方法
CN112487408B (zh) 用于车内ecu的安全访问方法、系统及存储介质
CN115396121B (zh) 安全芯片ota数据包的安全认证方法及安全芯片装置
CN106506149B (zh) 一种tbox终端和tsp平台之间密钥生成方法以及系统
JP2019009688A (ja) 保守システム及び保守方法
CN111565182B (zh) 一种车辆诊断方法、装置及存储介质
CN113920625B (zh) 车辆nfc钥匙认证方法
CN113781678A (zh) 无网环境下车辆蓝牙钥匙生成与鉴权方法及系统
CN113872770A (zh) 一种安全性验证方法、系统、电子设备及存储介质
CN107465649A (zh) 电子设备控制方法、终端和控制系统
CN112398894A (zh) 车用的安全验证方法及装置
CN113613214A (zh) 一种车内消息认证密钥管理方法及可读存储介质
CN111083696B (zh) 通信验证方法和系统、移动终端、车机端
CN113055181A (zh) Ota文件安全处理方法、装置及系统
CN111148275B (zh) 基于设备码的通信方法、装置及系统
CN112455386B (zh) 汽车防盗系统及方法
CN115361230B (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
GR01 Patent grant
GR01 Patent grant