WO2022133945A1 - 密钥写入方法及装置 - Google Patents

密钥写入方法及装置 Download PDF

Info

Publication number
WO2022133945A1
WO2022133945A1 PCT/CN2020/139146 CN2020139146W WO2022133945A1 WO 2022133945 A1 WO2022133945 A1 WO 2022133945A1 CN 2020139146 W CN2020139146 W CN 2020139146W WO 2022133945 A1 WO2022133945 A1 WO 2022133945A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
ecu
kms
encrypted
function
Prior art date
Application number
PCT/CN2020/139146
Other languages
English (en)
French (fr)
Inventor
钟胤
魏卓
姜锡忎
杨艳江
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN202080004588.1A priority Critical patent/CN112740212B/zh
Priority to PCT/CN2020/139146 priority patent/WO2022133945A1/zh
Publication of WO2022133945A1 publication Critical patent/WO2022133945A1/zh

Links

Images

Classifications

    • 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

Definitions

  • the present application relates to the field of security, and more particularly, to a method and device for writing a key.
  • Information security is a prerequisite for autonomous driving.
  • the information security of the vehicle can be protected by a variety of keys in the vehicle computer system.
  • the security of the in-vehicle communication network can be protected through a security onboard communication (SecOC) key (SecOC key), and the authenticity of the device can also be guaranteed through a device key (device key).
  • SecOC key security onboard communication
  • device key device key
  • keys are applied in various functions (or, in other words, various services) of the entire vehicle, and may be referred to as function keys (or may also be referred to as service keys). Ensuring the security of the function key is the core of the information security of the vehicle computer system.
  • the function keys currently used in the vehicle computer system are mainly preset keys.
  • the function key is preset in the electronic control unit (ECU) of the vehicle.
  • ECU electronice control unit
  • These function keys may be visible to the entire vehicle production line, ECU supplier production lines, etc., so the protection of the keys is not comprehensive enough, and there is a risk of key leakage.
  • the present application provides a key writing method and device, in order to provide a key writing process for a vehicle, avoid the risk of key leakage existing in the preset key, and strengthen the security protection of the key.
  • the present application provides a method for writing a key, comprising: a key management device obtaining an encrypted function key from a key management server (key management server, KMS), and the encrypted function key is based on obtained by encrypting the first key, the first key is the agreed key between the KMS and the ECU, and the first key is invisible to a third party; the key management device reports to the ECU Send the encrypted function key.
  • KMS key management server
  • the function key is a key that can be used to encrypt ECUs of various functions in the vehicle, so as to ensure the security of the computer system of the vehicle.
  • the first key can be understood as an intermediate key, which on the one hand can be used to encrypt the function key, and on the other hand is invisible to third parties.
  • the intermediate key introduced in the embodiments of the present application can be encrypted based on another key (such as a temporary key or another intermediate key) and then distributed to the ECU, which reduces the risk of leakage; It is used to encrypt the function key, so that the risk of leakage of the function key in the process of being issued to the ECU is also reduced.
  • the key writing to the vehicle computer system is realized without relying on the preset key, the protection of the function key is greatly enhanced, and the risk of key leakage is greatly reduced.
  • the key management device before the key management device obtains the encrypted function key from the KMS, the key management device receives the first key identifier from the ECU, The first key identifier is identification information generated based on the calculation of the first key; the key management device sends the first key identifier to the KMS, and the first key identifier is used for all The KMS determines the first key.
  • the first key identifier can be used by the KMS to search for the corresponding first key locally. Since the first key identification is used in the transmission process from the ECU to the KMS instead of directly transmitting the first key, the leakage of the function key caused by the leakage of the first key is largely avoided. .
  • the first key identifier may be obtained by the ECU performing a hash operation on the first key. After hash operation, the obtained first key identifier can not only be used to identify the first key, which is convenient for KMS to find the first key, but also makes the first key invisible to the third party, thus protecting the first key .
  • the key management apparatus obtains an encrypted first key from the KMS, where the encrypted first key is pre-stored in the ECU based on The second key is obtained by encrypting the first key; the key management device sends the encrypted first key to the ECU.
  • the risk of leakage of the first key can be reduced.
  • the first key can be used to replace the second key in the ECU, that is, the key is refreshed, the timeliness of the intermediate key is improved, the risk of key leakage is reduced, and the risk of key leakage is reduced to a greater extent. Increased key security.
  • the second key is a temporary key preset in the ECU by the ECU supplier.
  • one possible form of the second key is an ephemeral key.
  • the intermediate key can be encrypted with an ephemeral key distributed by the vendor's production line.
  • the temporary key can be preset in the ECU when the ECU device is produced.
  • the intermediate key can be sent to the ECU after encryption based on the temporary key. Since the intermediate key is forwarded from the KMS to the ECU in the form of ciphertext, the intermediate key is also invisible to other network elements during the transmission process, thus protecting the security of the intermediate key and indirectly protecting the Security of function keys encrypted by intermediate keys.
  • the second key is a key received by the ECU from the key management device before acquiring the first key.
  • another possible form of the second key is another intermediate key.
  • the first key in this embodiment can be used in place of the second key. That is, by flashing the intermediate key, the timeliness of the intermediate key is improved, thereby reducing the risk of key leakage and increasing the security of the key to a greater extent.
  • the key management device before the key management device obtains the encrypted first key from the KMS, the key management device receives a second encryption key from the ECU key identification, the second key identification is the identification information generated based on the calculation of the second key; the key management sends the second key identification to the KMS, and the second key identification uses The second key is determined at the KMS.
  • the second key identifier can be used by the KMS to search for the corresponding second key locally. Since the second key identification is used in the transmission process from the ECU to the KMS instead of directly transmitting the second key, the leakage of the first key caused by the leakage of the second key is greatly reduced , thereby reducing the risk of leakage of function keys.
  • the second key identifier may be obtained by the ECU performing a hash operation on the second key. After hash operation, the obtained second key identifier can be used to identify the second key, which is convenient for the KMS to find the second key, and makes the second key invisible to three parties, thereby protecting the second key.
  • the key management apparatus receives a status code from the ECU, where the status code is used to indicate whether the key received by the ECU has been successfully written wherein, the key includes the first key and/or the function key. It should be understood that if the key writing is successful, the writing success status code can be returned, which is convenient for the key management device to clarify the progress of the key writing; if the key writing is not successful, an error status code will be returned to facilitate understanding of the key writing. The status of the input and the reason why the key was not written successfully, so as to quickly locate the problem and debug it. In this way, each key corresponds to its own status code, which makes the management of key status more intuitive and convenient.
  • the key management device locally maintains a key list, and the key list is used to record the encryption key requested by the key management device for the ECU.
  • the state of the key which includes one or more of the following: application required, successful acquisition, successful writing, and writing failure.
  • the state of the key is the state of need to apply, successful acquisition, successful writing, and writing failure.
  • the error status code may also be set with different codes for the problems of the absence of the key and the incorrect key identification, which are not limited in this embodiment of the present application.
  • the key management device can update the state of the key applied and issued in real time, so that when an error occurs in the key writing process, it can quickly locate the problem and debug it in time.
  • the key management device since the key management device maintains the key list locally, it can perform offline verification on the key issued to the ECU, and does not depend on the network, which can reduce both signaling overhead and time overhead.
  • the present application provides a method for writing a key, comprising: an ECU receiving an encrypted function key from a key management device, where the encrypted function key is obtained by encryption based on a first key, and the The first key is an agreed key between the KMS and the ECU, and the first key is invisible to a third party; the ECU decrypts the encrypted function key based on the first key, and Write the obtained function key locally.
  • function key is a key that can be used to encrypt various functional ECUs in the vehicle, so as to ensure the security of the vehicle computer system.
  • the first key can be understood as an intermediate key, which on the one hand can be used to encrypt the function key, and on the other hand is invisible to the three parties.
  • the intermediate key introduced in the embodiments of the present application can be encrypted based on another key (such as a temporary key or another intermediate key) and then distributed to the ECU, which reduces the risk of leakage; It is used to encrypt the function key, so that the risk of leakage of the function key in the process of being issued to the ECU is also reduced.
  • the key writing to the vehicle computer system is realized without relying on the preset key, the protection of the function key is greatly enhanced, and the risk of key leakage is greatly reduced.
  • the ECU before the ECU receives the encrypted function key from the key management device, the ECU sends the first key identifier to the key management device,
  • the first key identification is identification information generated based on the calculation of the first key, and the first key identification is used for the KMS to determine the first key.
  • the first key identifier can be used by the KMS to search for the corresponding first key locally. Since the first key identification is used in the transmission process from the ECU to the KMS instead of directly transmitting the first key, the leakage of the function key caused by the leakage of the first key is greatly reduced risks of.
  • the first key identifier may be obtained by the ECU performing a hash operation on the first key. After hash operation, the obtained first key identifier can not only be used to identify the first key, which is convenient for KMS to find the first key, but also makes the first key invisible to the third party, thus protecting the first key .
  • the method before the ECU receives the encrypted function key from the key management device, the method further includes: the ECU receiving the encrypted function key from the key management device The encrypted first key, the first key is obtained by encrypting the first key based on the second key; the ECU decrypts the encrypted first key based on the first key, to write the obtained first key locally.
  • the risk of leakage of the first key can be reduced.
  • the first key can be used to replace the second key in the ECU, that is, the key is refreshed, the timeliness of the intermediate key is improved, the risk of key leakage is reduced, and the risk of key leakage is reduced to a greater extent. Increased key security.
  • the second key is a temporary key preset in the ECU by the ECU supplier.
  • one possible form of the second key is an ephemeral key.
  • the intermediate key can be encrypted with an ephemeral key distributed by the vendor's production line.
  • the temporary key can be preset in the ECU when the ECU device is produced.
  • the intermediate key can be sent to the ECU after encryption based on the temporary key. Since the intermediate key is forwarded from the KMS to the ECU in the form of ciphertext, the intermediate key is also invisible to other network elements during the transmission process, thus protecting the security of the intermediate key and indirectly protecting the Security of function keys encrypted by intermediate keys.
  • the second key is a key obtained by the ECU from the key management device.
  • another possible form of the second key is another intermediate key.
  • the first key in this embodiment can be used in place of the second key. That is, by flashing the intermediate key, the timeliness of the intermediate key is improved, thereby reducing the risk of key leakage and increasing the security of the key to a greater extent.
  • the ECU before the ECU receives the encrypted first key from the key management device, the ECU sends the second key identifier to the key management device , the second key identifier is identification information calculated and generated based on the second key, and is used by the KMS to determine the second key.
  • the second key identifier can be used by the KMS to search for the corresponding second key locally. Since the second key identification is used in the transmission process from the ECU to the KMS instead of directly transmitting the second key, the leakage of the first key caused by the leakage of the second key is greatly reduced , thereby reducing the risk of leakage of function keys.
  • the second key identifier may be obtained by the ECU performing a hash operation on the second key. After hash operation, the obtained second key identifier can not only be used to identify the second key, which is convenient for KMS to find the second key, but also makes the second key invisible to the third party, thus protecting the second key .
  • the ECU sends a status code to the key management apparatus, where the status code is used to indicate whether the key received by the ECU has been successfully written ; wherein the key includes the first key and/or the function key.
  • the writing success status code can be returned, which is convenient for the key management device to clarify the progress of the key writing; if the key writing is not successful, an error status code will be returned to facilitate understanding of the key writing.
  • the present application provides a method for writing a key, including: the KMS determines a first key for encrypting a function key based on a first key identifier obtained from an ECU; the first key The identifier is calculated and generated by the ECU based on the first key, the first key is an agreed key between the KMS and the ECU, and the first key is invisible to a third party; The KMS encrypts the function key based on the first key to obtain the encrypted function key; the KMS sends the encrypted function key to the key management device.
  • function key is a key that can be used to encrypt various functional ECUs in the vehicle, so as to ensure the security of the vehicle computer system.
  • the first key can be understood as an intermediate key, which on the one hand can be used to encrypt the function key, and on the other hand is invisible to third parties.
  • the first key identifier can be used by the KMS to search for the corresponding first key locally.
  • the intermediate key introduced in the embodiments of the present application can be encrypted based on another key (such as a temporary key or another intermediate key) and then distributed to the ECU, which reduces the risk of leakage; It is used to encrypt the function key, so that the risk of leakage of the function key in the process of being issued to the ECU is also reduced.
  • the key writing to the vehicle computer system is realized without relying on the preset key, the protection of the function key is greatly enhanced, and the risk of key leakage is greatly reduced.
  • the first key identifier is used in the transmission process from the ECU to the KMS, instead of directly transmitting the first key, the function key caused by the leakage of the first key is largely avoided. of leakage.
  • the KMS before the KMS determines the first key for encrypting the function key based on the first key identifier obtained from the ECU, the KMS passes the The key management device sends the encrypted first key to the ECU, where the encrypted first key is obtained by encrypting the first key based on the second key.
  • the risk of leakage of the first key can be reduced.
  • the first key can be used to replace the second key in the ECU, that is, the key is refreshed, the timeliness of the intermediate key is improved, the risk of key leakage is reduced, and the risk of key leakage is reduced to a greater extent. Increased key security.
  • the method before the KMS sends the encrypted first key to the key management apparatus, the method further includes: the KMS obtains from the ECU A second key identifier, the second key identifier is calculated and generated by the ECU based on the second key; the KMS determines, based on the second key identifier information, to encrypt the first key of the second key.
  • the second key identifier can be used by the KMS to search for the corresponding second key locally. Since the second key identification is used in the transmission process from the ECU to the KMS instead of directly transmitting the second key, the leakage of the first key caused by the leakage of the second key is greatly reduced , thereby reducing the risk of leakage of function keys.
  • the KMS determines the second key based on the second key identifier, encrypts the second key based on the second key first key to obtain the encrypted first key.
  • the KMS sends an error to the key management apparatus when the second key cannot be determined based on the second key identifier hint.
  • the KMS may search the locally recorded key identifier for the same second key identifier, and then determine the second key. For the case where the second key cannot be found, there is a corresponding error status code, which is convenient for quickly locating errors and debugging.
  • the second key is a temporary key preset in the ECU by the ECU supplier.
  • one possible form of the second key is an ephemeral key.
  • the intermediate key can be encrypted with an ephemeral key distributed by the vendor's production line.
  • the temporary key can be preset in the ECU when the ECU device is produced.
  • the intermediate key can be sent to the ECU after encryption based on the temporary key. Since the intermediate key is forwarded from the KMS to the ECU in the form of ciphertext, the intermediate key is also invisible to other network elements during the transmission process, thus protecting the security of the intermediate key and indirectly protecting the Security of function keys encrypted by intermediate keys.
  • the second key is a key obtained by the ECU from the key management device.
  • another possible form of the second key is another intermediate key.
  • the first key in this embodiment can be used in place of the second key. That is, by flashing the intermediate key, the timeliness of the intermediate key is improved, thereby reducing the risk of key leakage and increasing the security of the key to a greater extent.
  • the key management device is an original equipment manufacturer (original equipment manufacturer, OEM) key flashing device, or a dealer (dealer) tester (tester tool).
  • a key writing device which includes a unit or a module for implementing the methods of the first aspect to the third aspect and any possible implementation manner of the first aspect to the third aspect. It should be understood that each module or unit can implement corresponding functions by executing a computer program.
  • a key writing device comprising: a memory and a processor.
  • the memory can be used to store a computer program; the processor can be used to call the computer program in the memory, so that the key writing device executes the first aspect to the third aspect and any one of the first aspect to the third aspect method in one possible implementation.
  • the key writing device further includes a communication interface, which is coupled with the processor, and is used for inputting and/or outputting information, such as a function key to be written.
  • processors there are one or more processors and one or more memories.
  • the memory may be integrated with the processor, or the memory may be provided separately from the processor.
  • a computer program product comprising: a computer program (also referred to as code, or instructions), which, when the computer program is executed, causes the computer to execute the above-mentioned first to sixth aspects.
  • a computer program also referred to as code, or instructions
  • a computer-readable storage medium stores a computer program (also referred to as code, or instructions).
  • the computer program When executed, it causes the computer to execute the methods in the first aspect to the third aspect and any one of the possible implementation manners of the first aspect to the third aspect.
  • 1 is a network architecture suitable for the key writing method provided by the embodiment of the present application.
  • FIG. 2 is a schematic flowchart of a method for obtaining a key provided by an embodiment of the present application
  • FIG. 3 is a schematic flowchart of a method for writing a key to an ECU according to an embodiment of the present application
  • FIG. 4 is a schematic block diagram of an apparatus for writing a key provided by an embodiment of the present application.
  • FIG. 5 is another schematic block diagram of an apparatus for writing a key provided by an embodiment of the present application.
  • the method provided in this application can be applied to various computer system software, such as: Unix operating system, Unix-like operating system, Microsoft Windows operating system (microsoft windows operating system), media access control operating system (MacOS) , Linux operating system, and operating system patches and hardware drivers.
  • Unix operating system Unix-like operating system
  • Microsoft Windows operating system Microsoft windows operating system
  • MacOS media access control operating system
  • Linux operating system Linux operating system
  • patches and hardware drivers such as: Unix operating system, Unix-like operating system, Microsoft Windows operating system (microsoft windows operating system), media access control operating system (MacOS) , Linux operating system, and operating system patches and hardware drivers.
  • the method provided in this application can also be applied to various application software, such as office software, Internet software, multimedia software, analysis software, collaboration software, business software, and the like.
  • Vehicles in the embodiments of the present application may include, but are not limited to, cars, trucks, motorcycles, buses, boats, airplanes, helicopters, lawn mowers, recreational vehicles, playground vehicles, construction equipment, trams, golf
  • the embodiments of the present application are not particularly limited to a golf cart, a train, a trolley, and the like.
  • the network architecture 100 may include a KMS 102 , an OEM server 104 , an OEM key flashing device (also referred to as an OEM tool) 106 , a vehicle 108 , and a vehicle 110 , ECU 1081-108n and ECU 1101-110m.
  • Communication between the KMS 102 and the OEM server 104, between the OEM server 104 and the OEM key flashing device 106, and between the OEM key flashing device 106 and the ECUs 1081-108n, 1101-110m can all be communicated through local connections, Communication may also be performed through a secure connection (eg, transport layer security (TLS) protocol, virtual private network (VPN), etc.) to ensure communication security.
  • TLS transport layer security
  • VPN virtual private network
  • n and m are both natural numbers.
  • OEM original equipment manufacturer
  • FIG. 1 is only for ease of understanding, and shows a key writing process used in a vehicle production line, but this should not constitute any limitation to the present application.
  • the key writing method provided in this application can also be applied to after-sales service, such as a key update process for after-sales service.
  • the OEM key flashing device 106 in FIG. 1 can be replaced by a dealer diagnostic instrument (also called a dealer diagnostic tool (tester tool)), and the OEM server 104 can be replaced by a dealer server (dealer server).
  • Communication between the above-mentioned KMS and the dealer server, between the dealer server and the dealer diagnosis instrument, and between the dealer diagnosis instrument and the ECU can also be performed through a local connection or a secure connection.
  • the hardware structures of the OEM server and the dealer server may be similar.
  • the functions of the OEM key flashing device and the dealer diagnostic instrument are similar, and the application scenarios are different. Therefore, the hardware structure of the OEM key flashing device and the dealer diagnostic instrument can also be similar.
  • the KMS further includes a KMS front-end server and a KMS back-end server.
  • the KMS front-end server is mainly responsible for communication with the outside world, which can be understood as the interface between the KMS back-end server and the outside world.
  • the KMS background server is mainly responsible for key generation, key search, etc.
  • the KMS front-end server and the KMS back-end server can be two physically independent devices, or can be integrated into the same physical device. This embodiment of the present application does not limit this.
  • FIG. 1 two vehicles are shown in FIG. 1 along with one or more ECUs deployed on each vehicle.
  • This application does not limit the number of complete vehicles and the number of deployed ECUs in the network architecture.
  • ECU It can also be called an on-board controller, which can be used to control various functions in the use of the vehicle.
  • the ECU may include, but is not limited to, an ECU with an engine control function, an ECU with a handle control function, an ECU with a brake control function, and the like.
  • Function key It can also be called a business key. It can be used to encrypt the keys of ECUs of various functions in the vehicle to ensure the security of the computer system of the vehicle.
  • the function key may include, but is not limited to, a security onboard communication (SecOC) key (SecOC key) used to protect vehicle network communication security; a device key used for device authentication.
  • SecOC security onboard communication
  • device key used for device authentication.
  • the function key may be allocated based on one vehicle and one service.
  • one or more ECUs used for the same service can share the same function key.
  • the ECUs of the same business are different.
  • the multiple ECUs can share the same function key, and the multiple ECUs can perform encrypted communication with each other based on the function key.
  • messages can be encrypted and decrypted based on the same functional key to achieve encryption and integrity protection of messages; the freshness of messages can also be determined based on counters, so as to prevent playback effect.
  • the multiple ECUs may also share the same function key. Any one of the plurality of ECUs authenticates other ECUs of the service based on the function key.
  • function key used for on-board encrypted communication and the function key used for device authentication are keys for different services, and therefore are different keys.
  • function key can also be allocated on a smaller granularity basis.
  • function keys can be allocated based on a vehicle, a service, and a pair of ECUs. For example, if multiple ECUs are used for the same service, every two ECUs in the multiple ECUs may form a pair of ECUs. Each pair of ECUs can share a function key.
  • the plurality of ECUs include ECU-1, ECU-2 and ECU-3.
  • the same function key can be shared between ECU-1 and ECU-2, such as function key 1; another function key can be shared between ECU-2 and ECU-3, such as function key 2;
  • a function key can be shared between ECU-1 and ECU-3, such as function key 3.
  • the key to be actually transmitted may be encrypted by the intermediate key.
  • the function key can be encrypted by an intermediate key.
  • the function key is sent to the ECU after encryption based on the intermediate key. Since the function key is forwarded from the KMS to the ECU in the form of ciphertext, the function key is invisible to other network elements during the transmission process.
  • the intermediate key may be a key obtained in advance by the ECU, and may be used to decrypt the subsequently received encrypted function key, so as to realize the writing of the function key. Therefore, the intermediate key can be understood as the key obtained before the ECU obtains the function key, which can be called the ECU key (ECU key). In a possible implementation, the intermediate key can be obtained from the KMS.
  • the function key can be distributed based on a whole vehicle and a business, or it may be distributed based on a whole vehicle, a business, and a pair of ECUs.
  • the distribution granularity corresponds, and the intermediate key can also be distributed based on a complete vehicle, a business, or based on a complete vehicle, a business, and a pair of ECUs.
  • Temp key In this embodiment of the present application, in order to protect the intermediate key, a temporary key distributed by the supplier's production line may be used to encrypt the intermediate key.
  • the temporary key can be preset in the ECU when the ECU device is produced.
  • the intermediate key can be sent to the ECU after encryption based on the temporary key. Since the intermediate key is forwarded from the KMS to the ECU in the form of ciphertext, the intermediate key is also invisible to other network elements during the transmission process.
  • Key state In this embodiment of the present application, different numerical values can be used to represent the state of the key in the entire process from obtaining the key to writing the key. For the convenience of description, the numerical value used to represent the state of the key is referred to as a state code hereinafter.
  • Table 1 A possible definition method is shown in Table 1.
  • the state codes shown in Table 1 are hexadecimal numbers, and each code number can correspond to a state.
  • the code 0x00 can be the default value, or also called the default value.
  • the default value can represent a state in which it has not yet been determined whether the corresponding key needs to be refreshed. It should be understood that the state of the key can be reset to the default value each time the key writing process is initiated for a function key in an entire vehicle. After that, you can further set the key that needs to be applied for, and update the status of the key in real time with the steps of applying, obtaining, writing, etc. .
  • the code 0x01 can indicate that an application is required. For example, in the initial key writing process, it is necessary to apply for a key from the KMS and write the applied key to the ECU. For another example, in the key update process, it is necessary to apply for a key from the KMS, and the newly applied key can be used to replace the key originally stored in the ECU, that is, a key refresh is realized. Therefore, in the key update process, 0x01 can also indicate that flashing is required.
  • error status code may also be set with different codes for the problems of the absence of the key and the incorrect key identification, which are not limited in this embodiment of the present application.
  • Table 1 is only for the convenience of understanding, and the corresponding relationship between the numerical value and the key state is shown in the form of a table, but this should not constitute any limitation to the present application. It should also be understood that the different codes shown in Table 1 and their corresponding meanings are only examples, and the key state may include but not be limited to the several listed in Table 1, and the key state may also pass numerical values in other systems. or other means. This embodiment of the present application does not make any limitation on this.
  • Hash operation a cryptographic operation, which can be understood as the process of solving a hash function.
  • the identification information of the key can be obtained by performing a hash operation on the key.
  • the identification information of the key can be used as the identification information of the key.
  • the identification information of the key is simply referred to as a key identifier (key identifier, key ID).
  • key ID may correspond to a key ID, and each key ID may be used to identify a key.
  • the second key which can be an ECU key or a temporary key
  • Key0-ID identification information of the second key, hereinafter referred to as the second key identification
  • Key1 the first key, which can be the ECU key
  • Key1-ID identification information of the first key, hereinafter referred to as the first key identification
  • MAC1 MAC of the first key
  • CT1 encrypted first key
  • Key2 function key, for example, it can be a SecOC key
  • Key2-ID the identification information of the function key Key2
  • MAC2 MAC of the function key Key2
  • CT2 encrypted function key Key2
  • Key3 function key, such as another SecOC key
  • Key3-ID the identification information of the function key Key3
  • Key4 function key, for example, it can be a device key
  • Key4-ID the identification information of the function key Key4.
  • the keys are invisible to third parties.
  • the key is invisible to the third party, which can specifically refer to, except for the ECU (such as ECU-1 in the following embodiment) and KMS, other devices (such as OEM key flashing device, OEM server, dealer diagnostic instrument, dealer server, etc.) cannot obtain the plaintext of the key.
  • the KMS can transmit the key through other devices, the ciphertext generated by the key is transmitted between the ECU and the KMS, which makes the key invisible to third parties other than the ECU and the KMS.
  • the key writing process may specifically include the process of obtaining the key from the KMS and the process of writing the key to the ECU.
  • the method 200 described below in conjunction with FIG. 2 describes in detail the process of acquiring the key from the KMS
  • the method 300 described in conjunction with FIG. 3 describes in detail the process of writing the key to the ECU. It can be understood that the process of obtaining the key from the KMS provided by the method 200 and the process of writing the key to the ECU provided by the method 300 may be used alone or in combination. This embodiment of the present application does not limit this.
  • obtaining the key described in the method 200 mainly includes obtaining the intermediate key and obtaining the function key.
  • Writing the key to the ECU described in the method 300 mainly includes writing the intermediate key to the ECU and writing the function key to the ECU.
  • obtaining the key may include obtaining the first key and obtaining the function key; writing the key may include writing the first key and writing the function key.
  • the key (including the function key and the first key) in this embodiment of the present application may be allocated with the granularity of one complete vehicle and one service, or may be distributed at the granularity of one complete vehicle and one service , a pair of ECUs are allocated for granularity.
  • one or more ECUs used for the same service in the vehicle can request to obtain the key based on the method provided in the following method 200 , and the key can be written to the ECU based on the method provided in the following method 300 .
  • a pair of ECUs used for the same service in a vehicle can also request to obtain the encryption key based on the method provided in the following method 200.
  • the key can be written to the ECU based on the method provided in the method 300 described below.
  • each ECU in the multiple ECUs can request to obtain keys based on the method provided in the following method 200, and can obtain keys based on the following
  • the method provided in the method 300 is used to write the key to the ECU.
  • the following embodiments take the key writing process on the vehicle production line as an example to describe in detail the method for obtaining the key and the method for writing the key provided by the embodiment of the present application.
  • the OEM key flashing device in this paper is an example of a key management device in this scenario.
  • this method can also be used for the key update process in after-sales service.
  • the OEM key flashing device in the following embodiment can be replaced by a dealer diagnostic instrument (ie, another example of the key management device), and the OEM server can be replaced by a dealer server.
  • the method can also be applied to the key writing process of other computer systems or other application software. This embodiment of the present application does not limit this.
  • each network element exemplified below in conjunction with the accompanying drawings can also be replaced by other devices having the same or similar functions.
  • each network element can be divided into multiple modules based on different functions, and can also be integrated in the same physical device. This is also not limited in the embodiments of the present application. As long as the program in which the code of the method provided by the embodiment of the present application is recorded can be executed, the key writing can be implemented according to the method provided by the embodiment of the present application.
  • FIG. 2 is a schematic flowchart of a method 200 for obtaining a key provided by an embodiment of the present application.
  • obtaining the key in the method 200 mainly includes obtaining the intermediate key (ie, the first key described below) and obtaining the function key.
  • the intermediate key can be encrypted based on another key (ie, the second key described below), and the function key can be encrypted based on the intermediate key, so as to ensure that the key is not visible to a third party during the key transmission process.
  • the method 200 may include steps 210 to 270 . Each step in the method 200 will be described in detail below.
  • the OEM key flashing device can first obtain the identification information of the second key (hereinafter referred to as the second key) from the ECU (such as the ECU-1 described below). key ID). It should be understood that ECU-1 can be any ECU that requests a key through the OEM key flashing device.
  • step 210 the OEM key flashing device obtains the second key identifier from the ECU-1.
  • the second key may refer to the key written to the ECU-1 last time, or in other words, the key pre-stored in the ECU-1 before the request for the intermediate key from the KMS this time.
  • the method 200 for obtaining a key shown in FIG. 2 can be used in the scenario of writing the function key to the ECU-1 for the first time, and can also be used in the scenario of updating the function key in the ECU-1.
  • the second key can be, for example, a temporary key preset in the ECU-1 by the ECU supplier in the scenario where the key is written to the ECU-1 for the first time; it can also be the last time the key was written
  • the intermediate key eg ECU key obtained from KMS and written to ECU-1 in the process. This embodiment of the present application does not limit this.
  • ECU-1 can send the second key identifier (ie, Key0-ID) to the KMS through the OEM key flashing device, so that the KMS can obtain the second key and then encrypt the subsequently issued first key .
  • the second key identifier ie, Key0-ID
  • the first key is the intermediate key to be written into the ECU-1 obtained through step 250 in this embodiment. It can be understood that the first key is a key obtained after the second key, and can be used to replace the second key to encrypt the subsequently transmitted key. Therefore the first key is the key obtained from the KMS (eg ECU key), not the temporary key preset in ECU-1.
  • KMS eg ECU key
  • the second key identifier can be obtained by ECU-1 performing a hash operation on the second key. After hash operation, the obtained second key identifier can not only be used to identify the second key, which is convenient for KMS to find the second key, but also makes the second key invisible to the third party, avoiding the risk of key leakage .
  • step 220 the OEM key flashing device sends a key request to the KMS to request the KMS to allocate a new function key.
  • the OEM key flashing device can know which function keys have been obtained by each ECU in the vehicle, it can also determine which function keys each ECU needs to obtain. In other words, the OEM key flashing device can determine which function keys need to be applied for for ECU-1, or in other words, the OEM key flashing device can determine the type and quantity of keys applied for ECU-1. Based on this, the OEM key flashing device can generate a key request to apply for a function key from the KMS. The OEM key flash device can send the key request to the KMS through the OEM server.
  • the key request may carry the second key identifier obtained by the OEM key flashing device from ECU-1. After the KMS receives the key request, it can read the second key identifier.
  • step 230 the KMS looks up the second key based on the received second key identification.
  • the second key may be used to protect the first key
  • the first key may be used to protect the function key
  • KMS Key Management System
  • the KMS can maintain a database locally, and the database can store various types of keys, such as the above-mentioned temporary keys, intermediate keys, and function keys.
  • the KMS may search the local database for the corresponding key identifier.
  • step 240 may be executed, and the KMS prompts an error to the OEM key flashing device.
  • the KMS can terminate the key writing process.
  • the KMS can send a corresponding error status code to the OEM key flashing device for this error, so that the OEM key flashing device can quickly locate the problem and debug it.
  • step 250 the KMS encrypts the first key based on the second key to obtain the encrypted first key.
  • the first key can be an ECU key, which can be used to replace the second key in ECU-1.
  • the second key may be a temporary key preset by the ECU supplier, or may be an intermediate key obtained from the KMS by the OEM key flashing device. Based on the difference of the second key, the first key can be used to replace the temporary key preset in the ECU-1, and can also be used to update the intermediate key obtained by the ECU-1 last time. This embodiment of the present application does not limit this.
  • the first key may be a key that is pre-generated by the KMS and stored in a locally maintained database and selected, or may be a randomly generated key. This embodiment of the present application does not limit this.
  • the KMS may encrypt the first key based on the second key to obtain an encrypted first key.
  • the KMS can derive two derived keys K1 and K2 corresponding to the second key based on the second key, parameters Key_update_ENC_C and Key_update_MAC_C through a key derivation function (key derivation function, KDF).
  • KDF key derivation function
  • the specific values of the parameters Key_update_ENC_C and Key_update_MAC_C may be predefined, for example, predefined in relevant technical specifications.
  • the technical specification can be, for example, a secure hardware extension (SHE) published by the automotive open system architecture (AUTOSAR) organization.
  • SHE secure hardware extension
  • K1 and K2 can be expressed as follows:
  • K1 KDF(Key0, Key_update_ENC_C);
  • K2 KDF(Key0, Key_update_MAC_C).
  • the KMS can obtain the encrypted first key based on the above K1 by using the advanced encryption standard (Advanced Encryption Standard, AES), for example, denoted as CT1.
  • AES Advanced Encryption Standard
  • CT1 AES(K1, Key1
  • CNT1 is the count value output by the KMS local counter (count, CNT), which can be used for counting. It can be incremented by 1 before each encryption. By verifying the size relationship between the received CNT and the local CNT, anti-replay can be achieved. purpose of the attack.
  • the KMS can further use a message authentication code (cypher-based message authentication code, CMAC) based on block encryption, and obtain a message authentication code (message authentication code, MAC) based on the above-mentioned parameter K2 and the encrypted first key CT1.
  • CMAC message authentication code
  • MAC message authentication code
  • step 260 the KMS encrypts the function key based on the first key to obtain the encrypted function key.
  • the function key may be a key pre-generated by the KMS and selected from a database maintained locally, or a randomly generated key. This embodiment of the present application does not limit this.
  • the process by which the KMS encrypts the function key based on the first key may be similar to the process by which the KMS encrypts the first key based on the second key.
  • the KMS may derive two parameters K3 and K4 corresponding to the first key based on the first key, Key_update_ENC_C, and Key_update_MAC_C through the KDF.
  • K3 and K4 can be expressed as follows:
  • K3 KDF(Key1, Key_update_ENC_C);
  • K4 KDF(Key1, Key_update_MAC_C).
  • the KMS can use AES to obtain an encrypted function key based on the above K3, for example, denoted as CT2.
  • CT2 AES(K3, Key2
  • CNT2 can be used for counting, and it can be incremented by 1 before each encryption.
  • the KMS may further use CMAC to obtain the verification code MAC2 of the function key based on the above K4 and the above encrypted function key CT2.
  • ECU-1 since ECU-1 may be used for one or more services, it may apply for one or more function keys. If ECU-1 applies for multiple function keys, the KMS can encrypt the multiple function keys respectively based on the first key, and can further generate a corresponding MAC. The KMS may, for example, implement encryption of multiple function keys and generation of multiple MACs based on the implementation provided in step 260 . In other words, in the formula for generating the encrypted function key listed above, Key2 can also be replaced with other function keys such as Key3 and Key4. For the sake of brevity, no examples are provided here.
  • the algorithms for generating the encryption key and generating the MAC listed in the above steps 250 and 260 are only examples, and should not constitute any limitation to the embodiments of the present application.
  • the encryption algorithm can also include, for example, a data encryption standard (data encryption standard, DES), etc.
  • the MAC algorithm for example, can also include an encrypted message authentication code HMAC (hash-based message authentication code based on hash operation, HMAC), etc., the embodiments of the present application are not limited herein.
  • the corresponding count value (as shown in CNT1 and CNT2 above) can be automatically incremented by one, and the count value can be used as a parameter for encrypting the key, so as to prevent replay effect of the attack.
  • replay attack is that the attacker sends a packet that the destination host has received to deceive the system. It is mainly used in the identity authentication process and destroys the correctness of the authentication.
  • counters may be provided in both KMS and ECU-1. If the count value of the counter in KMS is greater than the count value of the counter in ECU-1, it indicates that there may be packet loss in ECU-1; if the count value of the KMS counter is consistent with the count value of the counter in ECU-1, it indicates that the ECU There may be no packet loss in -1; if the count value of the counter in KMS is less than the count value of the counter in ECU-1, it indicates that the message may be a replay message.
  • step 270 the KMS sends key information to the OEM key flashing device, where the key information includes the encrypted first key and the encrypted function key.
  • the KMS can forward the key information to the OEM key flashing device through the OEM server. Since the encrypted first key (that is, the above CT1) and the encrypted function key (that is, the above CT2) in the key information have undergone encryption processing, the OEM server and the OEM key flashing device have not obtained the information for When the keys of the first key and the function key are encrypted, the first key and the function key cannot be obtained. Therefore, it can be ensured that the first key and the function key are not leaked during the process of sending from the KMS to the OEM key flashing device.
  • the key information further includes the MAC of the first key (ie, the aforementioned MAC1) and the MAC of the function key (ie, the aforementioned MAC2).
  • the OEM key flashing device can also determine whether the key information from the KMS is fully received, and further determine the functions required by the ECU-1 according to the predetermined ECU-1 requirements for the type and quantity of the function keys Whether the keys have been fully obtained from the KMS.
  • the key information further includes an indication of the number of keys, so that the OEM key flashing device can detect whether the encrypted key (or the key) from the KMS is fully received based on this.
  • the KMS can send the encrypted key to the OEM key flashing device after each time it generates an encrypted key, that is, step 270 can be implemented through multiple sending steps; After all the encryption keys are completely encrypted, they are sent to the OEM key flashing device together, that is, step 270 can be implemented through a sending step.
  • This embodiment of the present application does not limit this.
  • the figure is just an example, showing a process of sending the encrypted first key and the encrypted function key to the OEM key flashing device through one step.
  • the OEM key refresh device in the embodiment of the present application may also locally record the type and quantity of the keys requested from the KMS.
  • the OEM key flashing device may record the correspondence between the above-mentioned ECU-1 and the type and quantity of the requested key.
  • the type of the key can be represented by the key code.
  • Each key designation can represent a type of key.
  • various types of keys can be defined as shown in Table 2 below:
  • Table 2 is only for ease of understanding, and exemplarily provides the correspondence between several types of key types and key codes. In fact, the key types are not limited to those listed in Table 2. It should also be understood that this application does not limit the correspondence between the key code and the key type, as well as the specific expression method and value of the key code.
  • Table 3 shows the correspondence between ECU-1 locally recorded by the OEM key flashing device and the type and quantity of keys requested by the ECU-1.
  • ECU key type quantity ECU-1 1000 1 ECU-1 2000 2 ECU-1 2001 1
  • Table 3 is only for the convenience of understanding, and shows an example of the correspondence between the ECU-1 locally recorded by the OEM key flashing device and the type and quantity of the requested keys.
  • the correspondence may be represented in a list form or in other forms.
  • the type and quantity of keys applied for by the same ECU can be written in a set according to preset rules.
  • the correspondence shown in Table 3 can be transformed into ⁇ ECU-1: 1000, 1; 2000, 2; 2001, 1 ⁇ . This application includes, but is not limited to.
  • the number may not be included in the list, but the types of the keys requested by ECU-1 are recorded separately, as shown in Table 4 below. It can be understood that each row in Table 4 corresponds to a key. Although the key types in the second row and the third row are the same, they represent different keys.
  • ECU key type ECU-1 1000 ECU-1 2000 ECU-1 2000 ECU-1 2001
  • the above-mentioned list for recording the correspondence between the types and quantities of keys requested by the ECU-1 and the ECU-1 is referred to as a key list. It should be understood that Tables 3 and 4 listed above are only two examples of the key list. More examples of key lists are shown below in conjunction with other tables.
  • the above key information further includes a key code.
  • the OEM key flashing device can determine whether the correct type of key has been received based on the received key code and the type of key required by the ECU-1 recorded in the key list.
  • the key list further includes identification information of each key.
  • the identification information of each key may include: identification information of the first key (for example, it may be referred to as a first key identification for short), and identification information of one or more function keys (for example, it may be referred to as a function key for short) identification).
  • the identification information of the key may be the hash value of the key.
  • the OEM key flashing device can locally record the identification information of the received key.
  • the key list may be obtained by adding the identification information of the key to the corresponding relationship listed above as shown in Table 4. Table 5 shows yet another example of the key list.
  • ECU key ID key type ECU-1 Key1-ID 1000 ECU-1 Key2-ID 2000 ECU-1 Key3-ID 2000 ECU-1 Key4-ID 2001
  • the OEM key flashing device can subsequently send the key received from the KMS to the ECU, so that the ECU can write the newly applied key locally.
  • the OEM key flashing device can perform verification according to the identification information of the key obtained from the ECU and the identification information recorded locally. Since the OEM key flashing device locally records the identification information of the key obtained from the KMS, the OEM key flashing device can complete the verification without interacting with the KMS, so this verification can be called offline verification. test.
  • the OEM key flashing device can also maintain the key status locally.
  • the key status may specifically refer to the status of each key, for example, the application needs to be applied, the acquisition is successful, the writing is successful, the writing fails, and the default value.
  • the key state can be represented by different state codes. Each status code can represent a meaning.
  • Each status code can represent a meaning.
  • the OEM key flashing device may update the key status each time a key write request from the ECU is received and/or each time a key is obtained from the KMS or an error indication is received, so that the The key state reflects the state of each key in the ECU in real time.
  • the status of each key shown in Table 6 is as follows: the first key (ie Key1) key has been successfully obtained, the function key (including Key2, Key3 and Key4) need to be written; it can also be determined that the status of each key shown in Table 7 is as follows: the first key (ie Key1) and the function key (including Key2, Key3 and Key4) are all Obtained successfully.
  • the key state information can also be maintained locally on the OEM key flashing device as an item in the key list.
  • Table 8 shows yet another example of the key list.
  • ECU key ID key type quantity state ECU-1 Key1-ID 1000 1 0x02
  • ECU-1 Key4-ID 2001 1 0x02
  • the OEM key flashing device can apply for keys for multiple vehicles and multiple ECUs.
  • the ECU-1 in the above step 210 may be any one of a plurality of ECUs.
  • each of the plurality of ECUs may send the second key identification to the OEM key flashing device by performing step 210 .
  • different second keys may be pre-stored in different ECUs, and corresponding second key identifiers are also different.
  • the ECUs in each vehicle can send the ECU's device identification code, ECU device type and vehicle identification number (VIN) to the OEM key flashing device.
  • the ECU's Device ID and ECU Device Type can be used to identify an ECU.
  • the vehicle identification code can be used to identify a complete vehicle.
  • the device identification code of the ECU may be, for example, a part number (part number, PART#).
  • ECU devices may include, but are not limited to, engine management system (EMS), automatic transmission control unit (TCU), body control module (BCM), electronic stability control system ( electronic stability program, ESP), battery management system (battery management system, BMS), vehicle controller (vehicle control unit, VCU), etc.
  • EMS engine management system
  • TCU automatic transmission control unit
  • BCM body control module
  • ESP electronic stability control system
  • BMS battery management system
  • VCU vehicle controller
  • the device identification code of an ECU contains information indicating the device type of the ECU.
  • the ECU can be directly identified by the device identification code.
  • the ECU's device identification code and vehicle identification code can be used to indicate one ECU of a complete vehicle.
  • each ECU sending the device identification code of the ECU, the device type of the ECU, and the vehicle identification code to the OEM key flashing device may be combined with the above step 210 to be performed in the same step, or may be performed separately. This embodiment of the present application does not limit this.
  • the above key information includes the device identification code of ECU-1, the device type and VIN of ECU-1.
  • the OEM key flashing device can be based on the device ID of ECU-1, the device type and VIN of ECU-1 received from ECU-1, and the device ID of ECU-1, the device ID of ECU-1 received from KMS, Device type and VIN, check the device identification code of ECU-1, the device type and VIN of ECU-1.
  • the key list further includes one or more of the device identification code of each ECU, the ECU device type, and the vehicle identification number (VIN).
  • Table 9 lists an example of the key list maintained locally by the OEM key flash device.
  • Table 9 only exemplifies the keys maintained locally by the OEM key flashing device when multiple ECUs (including ECU-1 to ECU-4) perform key writing to several types of keys An example of a list. In fact, the number of ECUs, key types and key states are not limited to those listed in Table 9.
  • Table 9 exemplarily shows an example in which the status is the write error status code "other".
  • the status code of the function key (specifically, the SecOC key) of the ECU-3 is 0x13, which can indicate that the writing of the SecOC key of the ECU-3 fails, and the flashing is terminated.
  • the type of error that causes the failure to write the SecOC key of the ECU-3 may be, for example, passing the MAC verification, or failing to pass the CNT verification, etc., which is not limited in this embodiment of the present application.
  • the OEM key flashing device can obtain the keys requested to be written by each ECU from the KMS according to the methods described in steps 210 to 270 above.
  • the flow of writing the key to the ECU will be described in detail below with reference to FIG. 3 . It can be understood that the process of writing the key to the ECU is a process executed after the above-mentioned process of obtaining the key from the KMS. In order to better understand the relationship between the process of writing the key to the ECU and the above process of obtaining the key from the KMS, the above-mentioned ECU-1 is still used as an example for description below.
  • the key applied by the OEM key flashing device for the ECU-1 includes a first key (ie Key1) and a function key (it is assumed to include Key2, Key3 and Key4 listed above).
  • FIG. 3 is a schematic flowchart of a method 300 for writing a key to an ECU according to an embodiment of the present application. It should be understood that the OEM key flashing device has obtained the ciphertext of the intermediate key (such as the first key described above) and the ciphertext of the function key from the KMS for writing the ECU-1. The following procedure is used to issue a key to ECU-1.
  • the OEM key flashing device has obtained the ciphertext of the intermediate key (such as the first key described above) and the ciphertext of the function key from the KMS for writing the ECU-1. The following procedure is used to issue a key to ECU-1.
  • the method 300 may include steps 301 to 324 . Each step in the method 300 will be described in detail below.
  • step 301 the OEM key flashing device sends the encrypted first key to ECU-1. Accordingly, the ECU-1 receives the encrypted first key from the OEM key flashing device.
  • the encrypted first key is the encrypted first key (eg, CT1 listed above) received by the OEM key flashing device and sent by the KMS in step 270 .
  • step 302 ECU-1 decrypts the encrypted first key to obtain and write the first key.
  • the first key is obtained by encrypting the second key
  • the second key is obtained by the KMS performing a local search based on the second key identifier obtained from the ECU-1 in the above method 200 Since the second key is pre-stored in ECU-1, ECU-1 can decrypt the received encrypted first key according to the second key, and then obtain the first key.
  • the method may include: the OEM key flashing device sends the MAC of the first key (eg, the MAC1 listed above) to the ECU-1. Accordingly, the ECU-1 receives the MAC of the first key from the OEM key flashing device.
  • the OEM key flashing device sends the MAC of the first key (eg, the MAC1 listed above) to the ECU-1. Accordingly, the ECU-1 receives the MAC of the first key from the OEM key flashing device.
  • ECU-1 may first perform MAC verification based on the received MAC of the first key, so as to complete the authentication and integrity check of the encrypted first key. ECU-1 can decrypt the encrypted first key under the condition of successful verification, and then obtain the first key.
  • the method may further include: the OEM key flashing device sends the CNT of the first key (eg, the CNT1 listed above) to the ECU-1. Accordingly, the ECU-1 receives the CNT of the first key from the OEM key flashing device.
  • the OEM key flashing device sends the CNT of the first key (eg, the CNT1 listed above) to the ECU-1. Accordingly, the ECU-1 receives the CNT of the first key from the OEM key flashing device.
  • ECU-1 after decrypting to obtain the first key, ECU-1 can perform CNT verification based on the received CNT to prevent replay attacks. ECU-1 can write the first key locally when the verification is successful.
  • the ECU-1 can receive the encrypted first key and the MAC and CNT corresponding to the first key from the OEM key flashing device.
  • ECU-1 can perform MAC verification first, decrypt to obtain the first key after successful verification, and perform CNT verification after successful decryption.
  • the OEM key flashing device can carry the encrypted first key, the MAC and/or CNT corresponding to the first key in the same signaling and send it to ECU-1, or can use different signaling separately It is sent to ECU-1, which is not limited in this embodiment of the present application.
  • the ECU-1 may store the decrypted first key locally.
  • the ECU-1 may use the decrypted first key in place of the pre-stored second key.
  • ECU-1 can delete the second key originally stored locally and write the first key.
  • a flashing process of the intermediate key is realized.
  • the ECU-1 may also store the CNT of the first key locally, so as to verify the subsequently received CNT.
  • the ECU may store the keys (including the above-mentioned second key, first key and function key) in a local designated storage area. Once the key is written, it can no longer be read from the storage area, but can only read the corresponding identification information, that is, the key identification. Therefore, in the embodiment of the present application, once ECU-1 writes the first key, other devices cannot read the first key; once ECU-1 writes the function key, other devices cannot read it either. Get the function key. Therefore, the first key and the function key are always invisible to the third party during the process of delivering the first key and the function key from the KMS to the ECU-1, thereby avoiding key leakage and having high security.
  • step 303 the ECU-1 sends a status code to the OEM key flashing device. Accordingly, the OEM key flashing device receives the status code from the ECU-1.
  • the ECU-1 may send a status code to the OEM key flashing device based on whether the MAC verification is successful, whether the first key is successfully obtained, and whether the CNT verification is successful.
  • ECU-1 may send an error status code to the OEM key flashing device to indicate that the writing fails: MAC verification based on the received MAC1 fails, the encrypted first key is not verified. A key decryption fails and the CNT verification based on the received CNT1 fails.
  • the failure status code can be, for example, 0x13 as listed above.
  • the ECU-1 may also send a message to the OEM key flashing device when the MAC verification based on the received MAC1 is successful, the decryption of the encrypted first key is successful, and the CNT verification based on the received CNT1 is successful.
  • Success status code to indicate that the write was successful and the key write process can continue.
  • the success status code can be, for example, 0xFF as listed above.
  • step 304 the OEM key flashing device determines whether the first key has been successfully written into the ECU-1 according to the received status code.
  • the flashing can be terminated.
  • the OEM key flashing device may also perform step 305 to update the status code of the first key to an error status code. For example, the OEM key flashing device may update the locally maintained key list according to the received error status code 0x13, and update the state of the first key to 0x13.
  • the list of keys in the OEM key flash device can be as shown in Table 10:
  • key type key ID ECU-1 1000 Key1-ID 0x13 2000 Key2-ID 0x01 2000 Key3-ID 0x01 2001 Key4-ID 0x01
  • the OEM key flashing device records the failure to write the first key (ie, Key1) in the key list, and terminates the key writing process; the function keys (including Key2, Key3, Key4) need to be written enter.
  • step 306 and subsequent related steps may continue to be executed.
  • the OEM key flashing device can implement step 304 by performing the following operations: the OEM key flashing device can determine whether the received status code is 0xFF (ie, the writing is successful). If so, the received status code is a write success status code; if not, the received status code is an error status code.
  • step 306 the OEM key flashing device sends a request for obtaining the first key identifier to the ECU-1.
  • step 307 the ECU-1 generates a first key identification.
  • the ECU-1 may perform a hash operation on the first key obtained by decryption based on the request from the OEM key flashing device received in step 306 to obtain the first key identifier.
  • step 308 the ECU-1 sends the first key identifier to the OEM key flashing device.
  • step 309 the OEM key flashing device performs offline verification to determine whether the ECU-1 successfully writes the first key.
  • the OEM key flashing device can compare the first key identifier obtained from the ECU-1 with the first key identifier recorded locally (for example, recorded in the key list), and then determine whether the first key is successful Write to ECU-1.
  • the offline verification performed by the OEM key flashing device in step 309 is the offline verification of the first key identifier. If the first key has been written into ECU-1, the first key identifier obtained by the OEM key flashing device is consistent with the locally recorded first key identifier; if the first key is not If it is successfully written into ECU-1, the first key identifier obtained by the OEM key flashing device is different from the first key identifier recorded locally. Thus, the OEM key flashing device can determine whether the first key has been successfully written into the ECU-1.
  • the OEM key flashing device can determine whether the first key has been successfully written into the ECU by comparing the first key identifier pre-recorded locally with the first key identifier obtained from ECU-1 -1, and it is no longer necessary to obtain the first key identifier from the KMS again, that is, it does not need to rely on the network, so it is called offline verification.
  • the time overhead caused by the signaling interaction can also be reduced.
  • the problem of key leakage can also be avoided.
  • step 310 the OEM key flashing device updates the key state of the first key according to the offline verification result.
  • the OEM key flashing device may perform step 310a to update the status code of the first key to an error status code. The OEM key flashing device can thus terminate the key writing process and no longer send the encrypted function key to ECU-1.
  • step 310a by the OEM key flashing device is similar to the specific process of the above-mentioned step 305, and details are not repeated here.
  • the OEM key flashing device can record the corresponding status code for the error type, so that the error type can be quickly found according to the status code in the future, which is convenient for quickly locating the problem and subsequent debugging and solving.
  • the first key identifier obtained by the OEM key flashing device from the ECU-1 is consistent with the first key identifier locally recorded in the OEM key flashing device, it is determined that the writing of the first key is successful.
  • the OEM key flash device can determine that the function key was successfully written.
  • Step 310b is executed to update the status code of the first key to a status code of successful writing.
  • the list status in the OEM key flash device can be as shown in Table 11:
  • key type key ID ECU-1 1000 Key1-ID 0xFF 2000 Key2-ID 0x01 2000 Key3-ID 0x01 2001 Key4-ID 0x01
  • the OEM key flashing device can continue to perform the subsequent steps 311 to 320 .
  • step 311 the OEM key flashing device sends the encrypted function key to ECU-1.
  • the encrypted function key may be the encrypted function key (eg, CT2 listed above) received by the OEM key flash device from the KMS in step 270 of the above method 200 .
  • step 312 the ECU-1 decrypts the encrypted function key to obtain and write the function key.
  • the function key is obtained by encrypting the first key, and the first key can be obtained based on the steps in step 301 and step 302 above, so ECU-1 can use the first key to obtain Decrypt the received encrypted function key to obtain the function key.
  • the OEM key flashing device may send encrypted function keys to ECU-1.
  • ECU-1 For each encrypted function key, ECU-1 can decrypt based on the first key.
  • the method may include: the OEM key flashing device sends the MAC of the function key (eg, the MAC2 listed above) to the ECU-1. Accordingly, the ECU-1 receives the MAC of the function key from the OEM key flashing device.
  • the OEM key flashing device sends the MAC of the function key (eg, the MAC2 listed above) to the ECU-1. Accordingly, the ECU-1 receives the MAC of the function key from the OEM key flashing device.
  • ECU-1 may first perform MAC verification based on the received MAC of the function key, so as to complete the authentication and integrity check of the encrypted function key. ECU-1 can decrypt the encrypted function key when the verification is successful, and then obtain the function key.
  • the method may further include: the OEM key flashing device sends the CNT of the function key (eg, the CNT2 listed above) to the ECU-1. Accordingly, the ECU-1 receives the CNT of the function key from the OEM key flashing device.
  • the OEM key flashing device sends the CNT of the function key (eg, the CNT2 listed above) to the ECU-1. Accordingly, the ECU-1 receives the CNT of the function key from the OEM key flashing device.
  • the ECU-1 after the ECU-1 decrypts and obtains the function key, it can perform CNT verification based on the CNT of the received function key, so as to determine whether the decrypted function key is actually derived from the KMS. ECU-1 can write the function key locally when the verification is successful.
  • each function key may correspond to a MAC or a CNT.
  • ECU-1 can separately perform MAC verification on the MAC of each function key, and then decrypt the function key corresponding to the MAC if the verification is successful; after decrypting the function key, it can further decrypt the function key. CNT for verification.
  • the OEM key flashing device can carry the encrypted function key, the MAC and/or CNT corresponding to the function key in the same signaling and send it to ECU-1, or send it to ECU-1 through different signaling.
  • ECU-1 which is not limited in this embodiment of the present application.
  • ECU-1 can store the decrypted function key locally.
  • the ECU-1 may store the decrypted function key in a designated storage area, thereby realizing the writing of the function key.
  • the ECU-1 may also store the CNT of the function key locally, so as to verify the subsequently received CNT.
  • ECU-1 can perform MAC verification and/or CNT verification based on each function key, and when the MAC verification is successful And/or after the CNT verification is passed, the corresponding function key is stored locally.
  • the process of the OEM key flashing device sending the encrypted function key to ECU-1 is also the process of the OEM key flashing device issuing the function key to ECU-1, but the function key is in ciphertext. issued in the form of .
  • the OEM key flashing device can determine whether the function key issued by it has been successfully written into the ECU-1 through the offline verification described below. It should be understood that the OEM key flashing device can separately perform offline verification on the function key identifiers corresponding to the issued one or more function keys to determine whether each function key has been successfully written into the ECU-1.
  • steps 313 to 320 still take a function key as an example to describe the offline verification process.
  • step 313 the ECU-1 sends a status code to the OEM key flashing device. Accordingly, the OEM key flashing device receives the status code from the ECU-1.
  • step 313 is similar to the specific process of step 303 above. The difference is that the status code sent by ECU-1 in step 313 indicates whether the function key has been successfully written, and the status code in step 303 indicates whether the first key has been successfully written. status code.
  • the status code sent by ECU-1 in step 313 indicates whether the function key has been successfully written
  • the status code in step 303 indicates whether the first key has been successfully written. status code.
  • step 314 the OEM key flashing device determines whether the function key has been successfully written according to the received status code.
  • step 315 can be executed to update the status code of the function key to an error status code.
  • the OEM key flashing device can update the locally maintained key list according to the received error status code 0x13, and update the status of the function key to 0x13.
  • the key list in the OEM key flashing device can be as shown in Table 12:
  • the OEM key flashing device records in the key list that the first key (ie, Key1) was successfully written; the function key (ie, Key2) failed to be written.
  • the OEM key flashing device can pass offline verification to confirm again whether the function key has been successfully written to ECU-1.
  • step 316 the OEM key flashing device sends a request to ECU-1 to obtain the function key identifier.
  • the OEM key flashing device can send the request to ECU-1 based on the received write success status code to request to obtain the function key identifier.
  • step 317 the ECU-1 generates a function key identification.
  • ECU-1 may perform a hash operation on the function key decrypted in step 312 based on the request from the OEM key flashing device received in step 317 to obtain the function key identifier.
  • step 318 the ECU-1 sends the function key identification to the OEM key flashing device.
  • step 319 the OEM key flashing device performs offline verification to determine whether the function key has been successfully written to ECU-1.
  • the OEM key flashing device can compare the function key identification obtained from ECU-1 with the function key identification recorded locally (for example, recorded in the key list), and then determine whether the function key has been successfully written. into ECU-1.
  • the offline verification performed by the OEM key flashing device in step 319 is the offline verification of the functional key identifier. If the function key has been successfully written into ECU-1, the function key ID obtained by the OEM key flashing device is consistent with the locally recorded function key ID; if the function key has not been successfully written into ECU-1, the function key identifier obtained by the OEM key flashing device is different from the function key identifier recorded locally. Thus, the OEM key flashing device can determine whether the function key has been successfully written into the ECU-1.
  • the verification of the functional key identification by the OEM key flashing device does not need to depend on the network, so it can also be called offline verification.
  • offline verification the time overhead caused by signaling interaction can be reduced, and the problem of function key leakage can also be avoided.
  • step 320 the OEM key flashing device updates the key state of the function key according to the offline verification result.
  • the OEM key flashing device may execute step 320a to update the status code of the function key to an error status code. It should be understood that the specific process of performing step 320a by the OEM key flashing device is similar to the specific process of the above-mentioned step 305, and will not be repeated here.
  • step 320b is executed to update the status code of the function key to write Success status code.
  • key type key ID ECU-1 1000 Key1-ID 0xFF 2000 Key2-ID 0xFF 2000 Key3-ID 0xFF 2001 Key4-ID 0xFF
  • Table 14 only shows the key state of the key issued by ECU-1.
  • the OEM key flashing device can apply and issue keys for more ECUs. Based on such a design, the table 14 can also be transformed into a list recording keys issued for multiple ECUs. For brevity, descriptions are not listed here.
  • the OEM key flashing device can confirm whether the ECU-1 has written the key, so as to avoid the OEM key flashing device from writing the same key Repeat multiple times.
  • the OEM key flashing device may first confirm whether the ECU-1 has successfully written the first key; before executing step 311, the OEM key flashing device may First confirm whether the ECU-1 has successfully written the function key.
  • the method further includes:
  • Step 321 the OEM key flashing device obtains a pre-stored third key identifier from ECU-1;
  • Step 322 the OEM key flashing device determines whether the third key identification obtained from ECU-1 is the first key identification.
  • the third key identifier obtained by the OEM key flashing device from ECU-1 is the first key identifier; if ECU-1 1. If the first key is not written before step 301, then in step 321, the third key identifier obtained by the OEM key flashing device from ECU-1 is not the first key identifier, but may be the one in method 200 above. The second key identifier may also be other. This embodiment of the present application does not limit this.
  • the OEM key flashing device can compare the third key identification obtained from ECU-1 with the first key identification recorded locally to determine whether the third key identification obtained from ECU-1 is the first key identification Key ID. If the two are consistent, it means that the first key has been successfully written in the ECU-1, and the above step 310b and subsequent steps can be directly executed, while steps 301 to 309 and step 310a are omitted; if the two are inconsistent , it means that the first key has not been successfully written in the ECU-1, and the above steps 301 to 320 can be executed.
  • the method further includes:
  • Step 323 the OEM key flashing device obtains the pre-stored fourth key identifier from ECU-1;
  • Step 324 the OEM key flashing device determines whether the fourth key identifier obtained from the ECU-1 is a function key identifier.
  • step 323 and step 324 are similar to the specific process of step 321 and step 322 above, the difference is that step 321 and step 322 are used to determine whether ECU-1 has successfully written the first key. Step 324 is for determining whether ECU-1 has successfully written the function key.
  • the third key identifier and the fourth key identifier may be stored in different storage areas.
  • the OEM key flashing device obtains the third key identifier and the fourth key identifier from the ECU-1, it can specify to read different key identifiers in different storage areas.
  • An intermediate key is introduced in the embodiment of this application. On the one hand, it is sent to the ECU based on another key (such as a temporary key or another intermediate key), which reduces the risk of leakage; on the other hand, it is used to encrypt the function key. , so that the risk of leakage of the function key in the process of being issued to the ECU is also reduced. As a result, the key writing to the vehicle computer system is realized without relying on the preset key, the protection of the function key is greatly enhanced, and the risk of key leakage is greatly reduced.
  • another key such as a temporary key or another intermediate key
  • the OEM key flashing device can update the status of the key applied and issued in real time, so that when an error occurs in the key writing process, the problem can be quickly located, so that it can be timely debugging.
  • the OEM key flashing device since the OEM key flashing device maintains the key list locally, it can perform offline verification of the key issued to the ECU without relying on the network, which can reduce both signaling overhead and time overhead.
  • an embodiment of the present application further provides a key writing device 400 , and the device may include: a processing module 410 and a communication module 420 .
  • the key writing device may correspond to the key management device in the above method embodiment.
  • the key management device in the above method embodiment.
  • it could be an OEM key flash device or a dealer diagnostic.
  • the processing module 410 may be configured to obtain an encrypted function key from the KMS, where the encrypted function key is obtained by encrypting a first key, and the first key is an agreed key between the KMS and the ECU and the first key is invisible to third parties; the communication module 420 can be used to send the encrypted function key to the ECU.
  • the communication module 420 is further configured to receive a first key identification from the ECU, where the first key identification is identification information calculated and generated based on the first key;
  • the KMS sends the first key identifier, where the first key identifier is used by the KMS to determine the first key.
  • the processing module 410 is further configured to obtain an encrypted first key from the KMS, where the encrypted first key is based on a second key pre-stored in the ECU for the first key. obtained by encrypting the key; the key management device sends the encrypted first key to the ECU.
  • the second key is a temporary key preset in the ECU by an ECU supplier.
  • the second key is a key obtained by the ECU from the key management device.
  • the communication module 420 is further configured to receive a second key identification from the ECU, where the second key identification is identification information calculated and generated based on the second key;
  • the KMS sends the second key identifier, where the second key identifier is used by the KMS to determine the second key.
  • the communication module 420 is further configured to receive a status code from the ECU, where the status code is used to indicate whether the key received by the ECU has been successfully written; wherein the key includes the the first key and/or the function key.
  • the processing module 410 is further configured to locally maintain a key list, where the key list is used to record the state of the key requested by the key management device for the ECU, and the state includes one of the following or Multiple: requires application, successful acquisition, successful write, and write failure.
  • the key writing device 400 may correspond to the ECU in the above method embodiment, such as ECU-1.
  • the communication module 420 may be configured to receive an encrypted function key from the key management device, where the encrypted function key is obtained by encrypting a first key, and the first key is between the KMS and the ECU and the first key is invisible to the third party; the processing module 410 can be used to decrypt the encrypted function key based on the first key, so as to write the obtained function key into local.
  • the communication module 420 is further configured to send a first key identification to the key management apparatus, where the first key identification is identification information generated based on the calculation of the first key, and the first key identification is A key identifier is used by the KMS to determine the first key.
  • the communication module 420 is further configured to receive an encrypted first key from the key management device, where the first key is obtained by encrypting the first key based on the second key; the The processing module 410 is further configured to decrypt the encrypted first key based on the first key, so as to write the obtained first key locally.
  • the second key is a temporary key preset in the ECU by an ECU supplier.
  • the second key is a key obtained by the ECU from the key management device.
  • the communication module 420 is further configured to send a second key identification to the key management device, where the second key identification is identification information generated based on the second key calculation, and is used for KMS determination. the second key.
  • the communication module 420 is further configured to send a status code to the key management apparatus, where the status code is used to indicate whether the key received by the ECU has been successfully written; wherein the key includes the first key and/or the function key.
  • the key management device is an OEM key flashing device, or a dealer diagnostic instrument.
  • the key writing device may correspond to the key management server in the above method embodiment.
  • the processing module 410 may be configured to determine a first key for encrypting the function key based on the first key identifier obtained from the ECU; the first key identifier is determined by the ECU based on the first key Calculated and generated, the first key is an agreed key between the KMS and the ECU, and the first key is invisible to a third party; the KMS encrypts the Function key, get the encrypted function key.
  • the communication module 420 can be used to send the encrypted function key to the key management device.
  • the communication module 420 is further configured to send an encrypted first key to the ECU through the key management device, where the encrypted first key is based on the second key to encrypt the first key. get.
  • the processing module 410 is further configured to obtain a second key identifier from the ECU, where the second key identifier is the identification information calculated and generated by the ECU based on the second key; the KMS is based on The second key identification information determines the second key used to encrypt the first key.
  • the processing module 410 is further configured to encrypt the first key based on the second key when the second key is determined based on the second key identifier to obtain encrypted 's first key.
  • the communication module 420 is further configured to send an error prompt to the key management apparatus when the second key cannot be determined based on the second key identifier.
  • the second key is a temporary key preset in the ECU by an ECU supplier.
  • the second key is a key obtained by the ECU from the key management device.
  • the key management device is an OEM key flashing device, or a dealer diagnostic instrument.
  • the key writing device may include, but is not limited to, multiple modules or units listed above.
  • the modules or units shown above in conjunction with FIG. 4 are only shown for ease of understanding, and should not constitute any limitation to the embodiments of the present application.
  • FIG. 5 is a schematic block diagram of a key writing apparatus 500 provided by an embodiment of the present application.
  • the computing device 500 may include: a processor 510 , a communication interface 520 and a memory 530 .
  • the processor 510, the communication interface 520 and the memory 530 communicate with each other through an internal connection path, the memory 530 is used for storing instructions, and the processor 510 is used for executing the instructions stored in the memory 530 to control the communication interface 520 to send signals and / or receive signals.
  • key writing apparatus 500 may be used to execute various steps and/or processes in the above method embodiments.
  • the memory 530 may include read only memory and random access memory and provide instructions and data to the processor. A portion of the memory may also include non-volatile random access memory.
  • the memory 530 may be a separate device or may be integrated in the processor 510 .
  • the processor 510 may be configured to execute the instructions stored in the memory 530, and when the processor 510 executes the instructions stored in the memory, the processor 510 is configured to execute various steps and/or processes of the above method embodiments.
  • the communication interface 520 may also be an input/output interface, a circuit, or the like.
  • the communication interface 520, the processor 510 and the memory 530 may be integrated in the same chip, or may be integrated in different chips. This application does not limit this.
  • the present application also provides a system, which includes the aforementioned ECU, a key management device, and a key management server.
  • the present application also provides a computer program product, the computer program product includes: a computer program (also referred to as code, or an instruction), when the computer program is run, the electronic device is made to execute the program shown in FIG. 2 or FIG. 3 .
  • a computer program also referred to as code, or an instruction
  • the electronic device is made to execute the program shown in FIG. 2 or FIG. 3 .
  • the present application also provides a computer-readable storage medium storing a computer program (also referred to as code, or instructions).
  • a computer program also referred to as code, or instructions.
  • the electronic device is caused to execute the method of any one of the embodiments shown in FIG. 2 or FIG. 3 .
  • the processor in this embodiment of the present application may be an integrated circuit chip, which has a signal processing capability.
  • each step of the above method embodiment may be completed by a hardware integrated logic circuit in a processor or an instruction in the form of software.
  • the above-mentioned processor may be a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or any other available processor.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • Programming logic devices, discrete gate or transistor logic devices, discrete hardware components The methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed.
  • a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the steps of the methods disclosed in conjunction with the embodiments of the present application may be directly embodied as executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art.
  • the storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in combination with its hardware.
  • the memory in the embodiments of the present application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.
  • the non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically programmable Erase programmable read-only memory (electrically EPROM, EEPROM) or flash memory.
  • Volatile memory may be random access memory (RAM), which acts as an external cache.
  • RAM random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous DRAM
  • SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous link dynamic random access memory
  • direct rambus RAM direct rambus RAM
  • unit may be used to refer to a computer-related entity, hardware, firmware, a combination of hardware and software, software, or software in execution.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • each functional unit may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software When implemented in software, it can be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be downloaded from a website site, computer, server, or data center Transmission to another website site, computer, server, or data center is by wire (eg, coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes an integration of one or more available media.
  • the usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state disks (SSDs)), and the like.
  • the functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium.
  • the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution, and the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other media that can store program codes .

Landscapes

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

Abstract

本申请提供一种密钥写入方法及装置。该方法包括：密钥管理装置从密钥管理服务器获取加密的功能密钥，并向电子控制单元发送该加密的功能密钥。该加密的功能密钥是基于第一密钥加密得到的，该第一密钥是密钥管理服务器与电子控制单元之间的约定密钥，且该第一密钥对第三方不可见。由于密钥一旦被写入电子控制单元，就无法从电子控制单元读取。因此第一密钥和功能密钥对第三方不可见，从而减小了泄漏风险。另外，通过第一密钥加密功能密钥，使得功能密钥在被下发给电子控制单元的过程中，泄漏风险也得以减小。由此，实现了对整车计算机系统的密钥写入，不依赖于预置密钥，对功能密钥的保护大大增强，密钥泄漏的风险大大减小。

Description

密钥写入方法及装置 技术领域
本申请涉及安全领域，更为具体地，涉及一种密钥写入方法及装置。
背景技术
信息安全是自动驾驶的前提。目前，整车计算机系统中可以通过多种密钥来保护整车的信息安全。例如，可通过板端加密通讯(security onboard communication，SecOC)密钥(SecOC key)来保护车载通信网络的安全，也可通过设备认证密钥(device key)来保证设备的真实性等。这些密钥在整车的多种功能(或者说，多种业务)中应用，可以称为功能密钥(或者也可以称为，业务密钥(service key))。保证功能密钥的安全是整车计算机系统信息安全的核心。
然而，目前应用于整车计算机系统的功能密钥以预置密钥为主。例如，整车出厂前，先将功能密钥预置在整车的电子控制单元(electric control unit，ECU)中。这些功能密钥对于整车生产线、ECU的供应商产线等可能都是可见的，因此对密钥的保护不够全面，存在密钥泄露的风险。
发明内容
本申请提供了一种密钥写入方法及装置，以期提供一种用于整车的密钥写入流程，避免预置密钥存在的密钥泄漏风险，加强对密钥的安全保护。
第一方面，本申请提供了一种密钥写入方法，包括：密钥管理装置从密钥管理服务器(key management server，KMS)获取加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为所述KMS与ECU之间的约定密钥，且所述第一密钥对第三方不可见；所述密钥管理装置向所述ECU发送所述加密的功能密钥。
应理解，功能密钥为可用于加密整车中各类功能的ECU的密钥，从而保障整车计算机系统的安全。
还应理解，第一密钥可理解为是中间密钥，它一方面可用于加密功能密钥，另一方面也对第三方不可见。
因此，本申请实施例中引入的中间密钥，一方面可基于另一密钥(比如临时密钥或另一中间密钥)加密后下发给ECU，减小了泄漏风险；另一方面用于加密功能密钥，使得功能密钥在被下发给ECU的过程中的泄漏风险也得以减小。由此，实现了对整车计算机系统的密钥写入，不依赖于预置密钥，对功能密钥的保护大大增强，密钥泄漏的风险大大减小。
结合第一方面，在第一方面的某些实现方式中，在所述密钥管理装置从KMS获取加密的功能密钥之前，所述密钥管理装置从所述ECU接收第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息；所述密钥管理装置向所述KMS发送所述第 一密钥标识，所述第一密钥标识用于所述KMS确定所述第一密钥。
该第一密钥标识可用于KMS从本地查找与之对应的第一密钥。由于在由ECU至KMS的传输过程中使用了第一密钥标识，而非直接传输第一密钥，从而在很大程度上避免了由于第一密钥的泄漏而造成的功能密钥的泄漏。
一种可能的实现方式是，该第一密钥标识可以由ECU对该第一密钥进行哈希运算得到。经过哈希运算，使得所得到的第一密钥标识既可用于标识第一密钥，便于KMS查找第一密钥，又使得第一密钥对第三方不可见，从而保护了第一密钥。
结合第一方面，在第一方面的某些实现方式中，所述密钥管理装置从所述KMS获取加密的第一密钥，所述加密的第一密钥是基于预存在所述ECU中的第二密钥对所述第一密钥加密得到的；所述密钥管理装置将所述加密的第一密钥发送给所述ECU。
通过用预存在ECU中的第二密钥对第一密钥进行加密得到加密的第一密钥，可以减小第一密钥的泄漏风险。另外，该第一密钥可用于替代ECU中的第二密钥，也即实现了密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
一种可能的情况是，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
换言之，该第二密钥的一种可能的形式是临时密钥。为了保护中间密钥，可以使用供应商产线分配的临时密钥来对中间密钥进行加密。该临时密钥可以在ECU设备生产时，预置在ECU中。在从KMS获取中间密钥的过程中，中间密钥可基于临时密钥的加密后被发送至ECU。由于中间密钥是以密文的形式从KMS被转发至ECU的，使得在传输过程中，该中间密钥对于其他网元也是不可见的，从而保护了中间密钥的安全，间接也保护了中间密钥加密的功能密钥的安全。
另一种可能的情况是，所述第二密钥是所述ECU在获取到所述第一密钥之前从所述密钥管理装置接收到的密钥。
换言之，该第二密钥的另一种可能的形式是另一中间密钥。本实施例中的第一密钥可用于替代第二密钥。也即通过对中间密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
结合第一方面，在第一方面的某些实现方式中，在所述密钥管理装置从所述KMS获取加密的第一密钥之前，所述密钥管理装置从所述ECU接收第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息；所述密钥管理向所述KMS发送所述第二密钥标识，所述第二密钥标识用于所述KMS确定所述第二密钥。
该第二密钥标识可用于KMS从本地查找与之对应的第二密钥。由于在由ECU至KMS的传输过程中使用了第二密钥标识，而非直接传输第二密钥，从而在很大程度上减小了由于第二密钥的泄漏而造成的第一密钥的泄漏，进而减小了功能密钥的泄漏风险。一种可能的实现方式是，该第二密钥标识可以由ECU对该第二密钥进行哈希运算得到。经过哈希运算，使得所得到的第二密钥标识既可用于标识第二密钥，便于KMS查找第二密钥，又使得第二密钥对三方不可见，从而保护了第二密钥。
结合第一方面，在第一方面的某些实现方式中，所述密钥管理装置接收来自所述ECU的状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。应理解，若密钥写入成功，则可返回写入成功状 态码，方便密钥管理装置明确密钥写入的进展；若密钥未写入成功会返回错误状态码，便于了解密钥写入的状态和查找密钥未写入成功的原因，从而快速定位问题和进行调试。如此一来，每个密钥对应其各自的状态码，使得密钥状态的管理更为直观和简便。
结合第一方面，在第一方面的某些实现方式中，所述密钥管理装置本地维护有密钥列表，所述密钥列表用于记录所述密钥管理装置为所述ECU请求的密钥的状态，所述状态包括以下一项或多项：需要申请、成功获取、写入成功和写入失败。
应理解，密钥的状态为需要申请、成功获取、写入成功和写入失败等状态。此外，错误状态码还可以针对密钥不存在和密钥标识错误的问题设置不同的代号，本申请实施例对此不作限定。
通过引入了密钥列表，密钥管理装置可以对其申请及下发的密钥的状态进行实时更新，从而可以在密钥写入流程出现错误时，快速定位问题，从而可以及时调试。此外，由于密钥管理装置本地维护该密钥列表，可以对其下发给ECU的密钥进行离线验证，不依赖于网络，既可以减少信令开销，也可以减少时间开销。
第二方面，本申请提供了一种密钥写入方法，包括：ECU从密钥管理装置接收加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为KMS与所述ECU之间的约定密钥，且所述第一密钥对第三方不可见；所述ECU基于所述第一密钥解密所述加密的功能密钥，并将获得的所述功能密钥写入本地。
应理解，功能密钥为可用于加密整车中各类功能ECU的密钥，从而保障整车计算机系统的安全。
还应理解，第一密钥可理解为是中间密钥，它一方面可用于加密功能密钥，另一方面也对三方不可见。
因此，本申请实施例中引入的中间密钥，一方面可基于另一密钥(比如临时密钥或另一中间密钥)加密后下发给ECU，减小了泄漏风险；另一方面用于加密功能密钥，使得功能密钥在被下发给ECU的过程中的泄漏风险也得以减小。由此，实现了对整车计算机系统的密钥写入，不依赖于预置密钥，对功能密钥的保护大大增强，密钥泄漏的风险大大减小。
结合第二方面，在第二方面的某些实现方式中，在所述ECU从密钥管理装置接收加密的功能密钥之前，所述ECU向所述密钥管理装置发送第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息，且所述第一密钥标识用于KMS确定所述第一密钥。
该第一密钥标识可用于KMS从本地查找与之对应的第一密钥。由于在由ECU至KMS的传输过程中使用了第一密钥标识，而非直接传输第一密钥，从而在很大程度上降低了由于第一密钥的泄漏而造成的功能密钥的泄漏的风险。
一种可能的实现方式是，该第一密钥标识可以由ECU对该第一密钥进行哈希运算得到。经过哈希运算，使得所得到的第一密钥标识既可用于标识第一密钥，便于KMS查找第一密钥，又使得第一密钥对第三方不可见，从而保护了第一密钥。
结合第二方面，在第二方面的某些实现方式中，在所述ECU从密钥管理装置接收加密的功能密钥之前，所述方法还包括：所述ECU从所述密钥管理装置接收加密的第一密钥，所述第一密钥是基于第二密钥对所述第一密钥加密得到的；所述ECU基于所述第一 密钥解密所述加密的第一密钥，以将获得的所述第一密钥写入本地。
通过用预存在ECU中的第二密钥对第一密钥进行加密得到加密的第一密钥，可以减小第一密钥的泄漏风险。另外，该第一密钥可用于替代ECU中的第二密钥，也即实现了密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
一种可能的情况是，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
换言之，该第二密钥的一种可能的形式是临时密钥。为了保护中间密钥，可以使用供应商产线分配的临时密钥来对中间密钥进行加密。该临时密钥可以在ECU设备生产时，预置在ECU中。在从KMS获取中间密钥的过程中，中间密钥可基于临时密钥的加密后被发送至ECU。由于中间密钥是以密文的形式从KMS被转发至ECU的，使得在传输过程中，该中间密钥对于其他网元也是不可见的，从而保护了中间密钥的安全，间接也保护了中间密钥加密的功能密钥的安全。
另一种可能的情况是，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
换言之，该第二密钥的另一种可能的形式是另一中间密钥。本实施例中的第一密钥可用于替代第二密钥。也即通过对中间密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
结合第二方面，在第二方面的一种实现方式中，在所述ECU从密钥管理装置接收加密的第一密钥之前，所述ECU向所述密钥管理装置发送第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息，用于KMS确定所述第二密钥。
该第二密钥标识可用于KMS从本地查找与之对应的第二密钥。由于在由ECU至KMS的传输过程中使用了第二密钥标识，而非直接传输第二密钥，从而在很大程度上减小了由于第二密钥的泄漏而造成的第一密钥的泄漏，进而减小了功能密钥的泄漏风险。一种可能的实现方式是，该第二密钥标识可以由ECU对该第二密钥进行哈希运算得到。经过哈希运算，使得所得到的第二密钥标识既可用于标识第二密钥，便于KMS查找第二密钥，又使得第二密钥对第三方不可见，从而保护了第二密钥。
结合第二方面，在第二方面的一种实现方式中，所述ECU向所述密钥管理装置发送状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。
应理解，若密钥写入成功，则可返回写入成功状态码，方便密钥管理装置明确密钥写入的进展；若密钥未写入成功会返回错误状态码，便于了解密钥写入的状态和查找密钥未写入成功的原因，从而快速定位问题和进行调试。如此一来，每个密钥对应其各自的状态码，使得密钥状态的管理更为直观和简便。
第三方面，本申请提供了一种密钥写入方法，包括：KMS基于从ECU获取到的第一密钥标识，确定用于加密功能密钥的第一密钥；所述第一密钥标识由所述ECU基于所述第一密钥计算生成，所述第一密钥是所述KMS与所述ECU之间的约定密钥，且所述第一密钥对第三方不可见；所述KMS基于所述第一密钥加密所述功能密钥，得到加密的功能密钥；所述KMS向密钥管理装置发送加密的功能密钥。
应理解，功能密钥为可用于加密整车中各类功能ECU的密钥，从而保障整车计算机系统的安全。
还应理解，第一密钥可理解为是中间密钥，它一方面可用于加密功能密钥，另一方面也对第三方不可见。第一密钥标识可用于KMS从本地查找与之对应的第一密钥。
因此，本申请实施例中引入的中间密钥，一方面可基于另一密钥(比如临时密钥或另一中间密钥)加密后下发给ECU，减小了泄漏风险；另一方面用于加密功能密钥，使得功能密钥在被下发给ECU的过程中的泄漏风险也得以减小。由此，实现了对整车计算机系统的密钥写入，不依赖于预置密钥，对功能密钥的保护大大增强，密钥泄漏的风险大大减小。另外，由于在由ECU至KMS的传输过程中使用了第一密钥标识，而非直接传输第一密钥，从而在很大程度上避免了由于第一密钥的泄漏而造成的功能密钥的泄漏。
结合第三方面，在第三方面的一种实现方式中，在所述KMS基于从ECU获取到的第一密钥标识，确定用于加密功能密钥的第一密钥之前，所述KMS通过所述密钥管理装置向所述ECU发送加密的第一密钥，所述加密的第一密钥是基于第二密钥对第一密钥加密得到。
通过用预存在ECU中的第二密钥对第一密钥进行加密得到加密的第一密钥，可以减小第一密钥的泄漏风险。另外，该第一密钥可用于替代ECU中的第二密钥，也即实现了密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
结合第三方面，在第三方面的一种实现方式中，在所述KMS向所述密钥管理装置发送加密的第一密钥之前，所述方法还包括：所述KMS从所述ECU获取第二密钥标识，所述第二密钥标识由所述ECU基于所述第二密钥计算生成；所述KMS基于所述第二密钥标识信息，确定用于加密所述第一密钥的所述第二密钥。
该第二密钥标识可用于KMS从本地查找与之对应的第二密钥。由于在由ECU至KMS的传输过程中使用了第二密钥标识，而非直接传输第二密钥，从而在很大程度上减小了由于第二密钥的泄漏而造成的第一密钥的泄漏，进而减小了功能密钥的泄漏风险。
结合第三方面，在第三方面的一种实现方式中，所述KMS在基于所述第二密钥标识确定出所述第二密钥的情况下，基于所述第二密钥加密所述第一密钥，以获得加密的第一密钥。
结合第三方面，在第三方面的一种实现方式中，所述KMS在基于所述第二密钥标识无法确定出所述第二密钥的情况下，向所述密钥管理装置发送错误提示。
KMS可以基于接收到的第二密钥标识，在本地记录的密钥标识中查找与之相同的第二密钥标识，进而确定该第二密钥。针对查找不到第二密钥的情况，有对应的错误状态码，从而方便快速定位错误和进行调试。
一种可能的情况是，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
换言之，该第二密钥的一种可能的形式是临时密钥。为了保护中间密钥，可以使用供应商产线分配的临时密钥来对中间密钥进行加密。该临时密钥可以在ECU设备生产时，预置在ECU中。在从KMS获取中间密钥的过程中，中间密钥可基于临时密钥的加密后被发送至ECU。由于中间密钥是以密文的形式从KMS被转发至ECU的，使得在传输过程中，该中间密钥对于其他网元也是不可见的，从而保护了中间密钥的安全，间接也保护了中间密钥加密的功能密钥的安全。
另一种可能的情况是，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
换言之，该第二密钥的另一种可能的形式是另一中间密钥。本实施例中的第一密钥可用于替代第二密钥。也即通过对中间密钥的刷写，提高了中间密钥的时效性，从而降低了密钥泄漏的风险，更大程度地增加了密钥的安全性。
结合上述各方面，所述密钥管理装置为原始设备制造商(original equipment manufacturer，OEM)密钥刷写装置，或，经销商(dealer)诊断仪(tester tool)。
第四方面，提供了一种密钥写入装置，该装置包括用于实现上述第一方面至第三方面以及第一方面至第三方面任意一种可能实现方式中的方法的单元或模块。应理解，各个模块或单元可通过执行计算机程序来实现相应的功能。
第五方面，提供了一种密钥写入装置，该装置包括：存储器和处理器。该存储器可用于存储计算机程序；该处理器可用于调用所述存储器中的计算机程序，以使得所述密钥写入装置执行上述第一方面至第三方面以及第一方面至第三方面任意一种可能实现方式中的方法。可选地，该密钥写入装置还包括通信接口，该通信接口与处理器耦合，该通信接口用于输入和/或输出信息，所述信息比如包括要写入的功能密钥。
可选地，所述处理器为一个或多个，所述存储器为一个或多个。
可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。
第六方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述第一方面至第三方面以及第一方面至第三方面任意一种可能实现方式中的方法。
第七方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行上述第一方面至第三方面以及第一方面至第三方面任意一种可能实现方式中的方法。
附图说明
图1为适用于本申请实施例提供的密钥写入方法的网络架构；
图2为本申请实施例提供的获取密钥的方法的示意性流程图；
图3为本申请实施例提供的一种向ECU写入密钥的方法的示意性流程图；
图4为本申请实施例提供的一种密钥写入装置的示意性框图；
图5为本申请实施例提供的一种密钥写入装置的另一示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
本申请提供的方法可以应用于各种计算机系统软件，例如：Unix操作系统、类Unix操作系统、微软视窗操作系统(microsoft windows operating system)、介质访问控制操作系统(media access control operating system，MacOS)、Linux操作系统、以及操作系统的补丁程序和硬件驱动程序等。
本申请提供的方法还可以应用于各种应用软件，例如：办公软件、互联网软件、多媒体软件、分析软件、协作软件、商务软件等。
本申请实施例中的整车可以包括但不限于，轿车、卡车、摩托车、公共汽车、船、飞 机、直升飞机、割草机、娱乐车、游乐场整车、施工设备、电车、高尔夫球车、火车、及手推车等，本申请实施例不做特别的限定。
为便于理解本申请实施例，首先结合图1详细说明适用于本申请提供的密钥的写入方法的网络架构。如图1所示，该网络架构100可以包括KMS 102，OEM服务器(OEM server)104，OEM密钥刷写装置(也可以称为OEM工具(OEM tool))106、整车108、整车110、ECU 1081-108n及ECU 1101-110m。KMS 102和OEM服务器104之间，OEM服务器104和OEM密钥刷写装置106之间，OEM密钥刷写装置106和ECU 1081-108n、1101-110m之间，均可以通过本地连接来通信，也可通过安全连接(比如，安全传输层(transport layer security，TLS)协议、虚拟专用网络(virtual private network，VPN)等)来通信，以保证通信安全。其中，n、m均为自然数。
可以理解，对于整车生产而言，上述原始设备制造商(OEM)具体可以是指整车制造商。
应理解，图1仅为便于理解，示出了用于整车生产线中密钥写入流程，但这不应对本申请构成任何限定。本申请提供的密钥写入方法也可应用于售后服务中，比如用于售后服务的密钥更新流程。在应用于售后服务时，图1中的OEM密钥刷写装置106可以替换为经销商诊断仪(也可以称为经销商诊断工具(tester tool))，同时OEM服务器104可以替换为经销商服务器(dealer server)。上述KMS与经销商服务器之间，经销商服务器与经销商诊断仪之间，经销商诊断仪与ECU之间也可通过本地连接或安全连接来通信。
可以理解，由于OEM服务器与经销商服务器的功能相似，应用场景不同，故，OEM服务器与经销商服务器的硬件结构可以是相似的。OEM密钥刷写装置与经销商诊断仪的功能相似，应用场景里不同，故，OEM密钥刷写装置与经销商诊断仪的硬件结构也可以是相似的。
可选地，KMS还进一步包括KMS前置服务器和KMS后台服务器。KMS前置服务器主要负责与外部的通信，可理解为是KMS后台服务器与外部通信的接口。KMS后台服务器主要负责密钥生成、密钥查找等。KMS前置服务器与KMS后台服务器可以是物理上独立的两个设备，也可以集成在同一个物理设备中。本申请实施例对此不作限定。
还应理解，图1中示出了两辆车以及部署在每辆车上的一个或多个ECU。本申请对于该网络架构中的整车数量以及所部署的ECU的数量均不作限定。在介绍本申请实施例之前，首先对本申请中涉及到的术语作简单说明。
1、ECU：也可以称为车载控制器，可用于控制整车使用中的各种功能。ECU例如可以包括但不限于，具有发动机控制功能的ECU、具有手柄控制功能的ECU、具有制动器控制功能的ECU等。
2、功能密钥：也可以称为业务密钥。可用于加密整车中各类功能的ECU的密钥，从而保障整车计算机系统的安全。功能密钥例如可以包括但不限于，用于保护车载网络通信安全的板端加密通讯(security onboard communication，SecOC)的密钥(SecOC key)；用于设备认证的设备密钥。
在本申请实施例中，功能密钥可以是基于一台整车、一个业务来分配的。对于一台整车而言，用于同一业务的一个或多个ECU可以共用同一个功能密钥。而对于不同的整车而言，同一业务的ECU是不同的。
比如，若同一整车中的多个ECU用于板端加密通讯，该多个ECU可共用同一个功能密钥，该多个ECU相互之间均可基于该功能密钥来进行加密通信。例如，相互通信的ECU之间，可以基于相同的功能密钥来对消息进行加密和解密，以达到对消息的加密和完整性保护；还可基于计数器来确定消息的新鲜性，从而可以达到防重放的效果。
又比如，若同一整车中的多个ECU用于设备认证，该多个ECU也可共用同一个功能密钥。该多个ECU中的任意一个ECU基于该功能密钥来对该业务的其他ECU进行认证。
可以理解，用于板端加密通讯的功能密钥和用于设备认证的功能密钥是不同业务的密钥，因此是不同的密钥。
当然，该功能密钥也可以基于更小的粒度来分配。例如，功能密钥可以是基于一台整车、一个业务、一对ECU来分配的。比如，若多个ECU用于同一业务，该多个ECU中的每两个ECU可以组成一对ECU。每对ECU可以共用一个功能密钥。
比如，该多个ECU包括ECU-1、ECU-2和ECU-3。ECU-1和ECU-2之间可共用同一个功能密钥，比如记为功能密钥1；ECU-2和ECU-3之间可共用另一个功能密钥，比如记为功能密钥2；ECU-1和ECU-3之间可共用功能密钥，比如记为功能密钥3。
3、中间密钥：在本申请实施例中，为了避免密钥在传输过程中被泄漏，可通过中间密钥对实际要传输的密钥进行加密。例如，可通过中间密钥来加密功能密钥。在从KMS获取功能密钥的过程中，功能密钥基于中间密钥的加密后被发送至ECU。由于功能密钥是以密文的形式从KMS被转发至ECU的，在传输过程中，该功能密钥对于其他网元是不可见的。
该中间密钥可以是ECU预先获取到的密钥，可用于对解密后续接收到的加密的功能密钥，以实现功能密钥的写入。因此，该中间密钥可以理解为是在ECU在获取功能密钥之前获取的密钥，可以称为ECU密钥(ECU key)。在一种可能的实现方式中，该中间密钥可以从KMS获取。
由于中间密钥可用于加密功能密钥，而功能密钥可能是基于一个整车、一个业务而分配，也可能是基于一台整车、一个业务、一对ECU而分配，与功能密钥的分配粒度相对应，中间密钥也可以基于一台整车、一个业务而分配，也可以是基于一台整车、一个业务、一对ECU而分配。
4、临时密钥(temp key)：在本申请实施例中，为了保护中间密钥，可以使用供应商产线分配的临时密钥来对中间密钥进行加密。该临时密钥可以在ECU设备生产时，预置在ECU中。在从KMS获取中间密钥的过程中，中间密钥可基于临时密钥的加密后被发送至ECU。由于中间密钥是以密文的形式从KMS被转发至ECU的，在传输过程中，该中间密钥对于其他网元也是不可见的。
5、密钥状态：在本申请实施例中，可通过不同数值来表示从获取密钥到写入密钥整个过程中密钥的状态。为便于说明，下文中将用于表示密钥状态的数值称为状态代号。
一种可能的定义方法如表1所示。表1中所示的状态代号为十六进制数，每个代号可对应一种状态。
表1
状态 含义
0x00 默认值
0x01 需要申请
0x02 成功获取密钥
0xFF 写入成功
其他 写入错误状态码，表示写入失败
其中，代号0x00可以默认值，或者也叫缺省值。默认值可表示还未决定所对应的密钥是否需要刷写的一种状态。应理解，每次开始对一台整车中的功能密钥执行密钥写入流程时，密钥状态都可重置到默认值。此后，可以进一步设置需要申请的密钥，并随着密钥的申请、获取、写入等步骤，实时地更新该密钥的状态为需要申请、成功获取、写入成功或写入失败等状态。
代号0x01可表示需要申请。比如，在初次写入密钥流程中，需要从KMS申请密钥，并将申请到的密钥写入ECU。又比如，在密钥更新流程中，需要从KMS申请密钥，新申请到的密钥可用于替代原先存储在ECU中的密钥，也即实现了一次密钥刷写。因此在密钥更新流程中，0x01也可表示需要刷写。
此外，错误状态码还可以针对密钥不存在和密钥标识错误的问题设置不同的代号，本申请实施例对此不作限定。
应理解，表1仅为便于理解，将数值与密钥状态的对应关系以表格的形式示出，但这不应对本申请构成任何限定。还应理解，表1所示的不同代号及其对应的含义仅为示例，密钥状态可以包括但不限于表1中所列举的几种，且，密钥状态也可以通过其他进制的数值或其他方式来表示。本申请实施例对此不作任何限定。
下文中为方便理解和说明，在涉及对密钥状态的描述时，以表1中所示的数值与密钥状态的对应关系为例来描述。但应理解，这样的描述仅为示例，不应对本申请实施例构成任何限定。
6、哈希(Hash)运算：一种密码学运算，可理解为求解哈希函数的过程。
哈希运算的一种可能的执行过程如下：将数据元素的关键字作为自变量，通过选择某种哈希函数，计算出的值可以作为该元素的身份识别信息，表示如下：ID＝H(Key)。
在本申请实施例中，可通过对密钥进行哈希运算，得到该密钥的身份识别信息。该密钥的身份识别信息可作为该密钥的标识信息。下文中为方便说明，将密钥的标识信息简称为密钥标识(key identifier，key ID)。每个密钥ID可对应一个密钥ID，每个密钥ID可用于标识一个密钥。
此外，为方便区分和说明，对文中涉及到的主要参数说明如下：
Key0：第二密钥，可以是ECU密钥，也可以是临时密钥；
Key0-ID：第二密钥的标识信息，下文简称第二密钥标识；
Key1：第一密钥，可以是ECU密钥；
Key1-ID：第一密钥的标识信息，下文简称第一密钥标识；
MAC1：第一密钥的MAC；
CT1：加密的第一密钥；
Key2：功能密钥，例如可以是SecOC密钥；
Key2-ID：功能密钥Key2的标识信息；
MAC2：功能密钥Key2的MAC；
CT2：加密的功能密钥Key2；
Key3：功能密钥，例如可以是另一SecOC密钥；
Key3-ID：功能密钥Key3的标识信息；
Key4：功能密钥，例如可以是设备密钥；
Key4-ID：功能密钥Key4的标识信息。
另外，本申请实施例中多次提及密钥(如下文实施例中的第一密钥、功能密钥)对第三方不可见。密钥对第三方不可见，具体可以是指，除了ECU(如下文实施例中的ECU-1)和KMS，其他设备(如OEM密钥刷写装置、OEM服务器、经销商诊断仪、经销商服务器等)均无法获取到密钥的明文。即便KMS可以通过其他设备来传输密钥，但在ECU与KMS之间传输的是由密钥生成的密文，这就使得密钥对除了ECU和KMS之外的第三方不可见。
下面将结合附图对本申请实施例提供的密钥写入方法做详细说明。
为便于理解和说明，下文实施例首先描述针对一个ECU的密钥写入流程，然后描述针对多个ECU的密钥写入流程。密钥写入流程具体可以包括从KMS获取密钥的流程和向ECU写入密钥的流程。下文中结合图2描述的方法200详细说明了从KMS获取密钥的流程，结合图3描述的方法300详细说明了向ECU写入密钥的流程。可以理解，方法200所提供的从KMS获取密钥的流程和方法300所提供的向ECU写入密钥的流程可以单独使用，也可以结合使用。本申请实施例对此不作限定。
应理解，方法200中所述的获取密钥主要包括获取中间密钥和获取功能密钥。方法300中所述的向ECU写入密钥主要包括向ECU写入中间密钥和向ECU写入功能密钥。下文中为了简洁，获取密钥可以包括获取第一密钥和获取功能密钥；写入密钥可以包括写入第一密钥和写入功能密钥。
如前所述，本申请实施例中的密钥(包括功能密钥和第一密钥)可以是以一台整车、一个业务为粒度来分配，也可以是以一台整车、一个业务、一对ECU为粒度来分配。在以一台整车、一个业务为粒度来分配密钥的情况下，一台整车中用于同一业务的一个或多个ECU均可以基于下述方法200中提供的方法来请求获取密钥，并可基于下述方法300中提供的方法来向ECU写入密钥。在以一个整车、一个业务、一对ECU为粒度来分配密钥的情况下，一台整车中用于同一业务的一对ECU也可以基于下述方法200中提供的方法来请求获取密钥，并可基于下述方法300中提供的方法来向ECU写入密钥。
应理解，上文列举的分配粒度仅为示例，不应对本申请构成任何限定。当多个ECU可以共享密钥(包括中间密钥和功能密钥)时，该多个ECU中的每个ECU均可以基于下述方法200中提供的方法来请求获取密钥，并可基于下述方法300中提供的方法来向ECU写入密钥。
另外，需要说明的是，下文实施例以整车生产线上密钥写入流程为例，详细说明本申请实施例所提供的获取密钥的方法和写入密钥的方法。文中的OEM密钥刷写装置是此场景下的密钥管理装置的一例。但这不应对该方法所适用的场景构成任何限定。如前所述，该方法也可用于售后服务中的密钥更新流程。此情况下，下述实施例中的OEM密钥刷写装置可以替换为经销商诊断仪(即，密钥管理装置的另一例)，OEM服务器可替换为经销商服务器。又例如，该方法还可应用于其他计算机系统或其他应用软件的密钥写入流程。 本申请实施例对此不作限定。
还需要说明的是，下文结合附图所示例的各网元也可以替换为其他具有相同或相似功能的设备。另外，各网元可以基于不同的功能划分为多个模块，也可以集成在同一个物理设备中。本申请实施例对此也不作限定。只要能够通过运行记录有本申请实施例的提供的方法的代码的程序，以根据本申请实施例提供的方法实现密钥写入即可。
图2是本申请实施例提供的获取密钥的方法200的示意性流程图。如前所述，方法200中所述的获取密钥主要包括获取中间密钥(即，下文所述的第一密钥)和获取功能密钥。其中，中间密钥可以基于另一密钥(即，下文所述的第二密钥)来加密，功能密钥可以基于中间密钥来加密，从而保证密钥传输过程中对第三方不可见。
如图2所示，该方法200可以包括步骤210至步骤270。下面对方法200中的各个步骤做详细说明。
为了便于KMS选择合适的密钥来加密第一密钥，OEM密钥刷写装置可以先从ECU(如下文所述的ECU-1)中获取第二密钥的标识信息(下文简称第二密钥标识)。应理解，ECU-1可以是任意一个通过OEM密钥刷写装置请求密钥的ECU。
在步骤210中，OEM密钥刷写装置从ECU-1获取第二密钥标识。
在本申请实施例中，第二密钥可以是指上一次写入ECU-1的密钥，或者说，是在此次从KMS请求中间密钥之前，预存在该ECU-1中的密钥。可以理解，图2所示的获取密钥的方法200可以用于首次向ECU-1写入功能密钥的场景，也可用于对ECU-1中的功能密钥进行更新的场景。与之对应，该第二密钥例如可以是首次向ECU-1写入密钥的场景中，由ECU供应商预置在该ECU-1中的临时密钥；也可以上一次密钥写入流程中从KMS获取到并写入ECU-1的中间密钥(例如ECU密钥)。本申请实施例对此不作限定。
ECU-1可以将该第二密钥标识(即，Key0-ID)通过OEM密钥刷写装置发送给KMS，以便于KMS获取第二密钥，进而对后续下发的第一密钥进行加密。
这里，第一密钥是本实施例中通过步骤250获取到的要写入ECU-1的中间密钥。可以理解，第一密钥是在第二密钥之后获取到的密钥，可用于替代第二密钥，对后续传输的密钥进行加密。因此第一密钥是从KMS获取到的密钥(例如ECU密钥)，而非预置在ECU-1中的临时密钥。
如前所述，该第二密钥标识可以由ECU-1对该第二密钥进行哈希运算得到。经过哈希运算，使得所得到的第二密钥标识既可用于标识第二密钥，便于KMS查找第二密钥，又使得第二密钥对第三方不可见，避免了密钥泄漏的风险。
在步骤220中，OEM密钥刷写装置向KMS发送密钥请求，以请求KMS分配新的功能密钥。
由于OEM密钥刷写装置可以了解到整车中各ECU已经获取到了哪些功能密钥，也可以确定各ECU还需要获取哪些功能密钥。换言之，OEM密钥刷写装置可以确定需要为ECU-1申请哪些功能密钥，或者说，OEM密钥刷写装置可以确定为ECU-1申请的密钥的类型和数量。OEM密钥刷写装置可基于此，生成密钥请求，以向KMS申请功能密钥。OEM密钥刷写装置可以通过OEM服务器将该密钥请求发送至KMS。
该密钥请求中可以携带OEM密钥刷写装置从ECU-1获取到的第二密钥标识。KMS在接收到密钥请求后，便可以读取到该第二密钥标识。
在步骤230中，KMS基于接收到的第二密钥标识查找该第二密钥。
在本申请实施例中，该第二密钥可用于保护第一密钥，该第一密钥可用于保护功能密钥。
各类密钥均可存储在KMS中。比如，KMS可在本地维护一个数据库，数据库中可保存有各类密钥，如上述临时密钥、中间密钥、功能密钥等。KMS可以基于接收到的第二密钥标识，在本地的数据库中查找与之对应的密钥标识。
若数据库中不存在与该第二密钥标识对应的密钥标识，则可执行步骤240，KMS向OEM密钥刷写装置提示错误。KMS可以终止该密钥写入流程。在一种可能的设计中，KMS可以针对此错误向OEM密钥刷写装置发送相应的错误状态码，从而方便OEM密钥刷写装置快速地定位问题和进行调试。
若数据库中存在与该第二密钥标识对应的密钥标识，则可执行下述步骤250至步骤270。
在步骤250中，KMS基于第二密钥加密第一密钥，得到加密的第一密钥。
第一密钥可以是ECU key，该ECU key可用于替换ECU-1中的第二密钥。如前所述，该第二密钥可以是由ECU供应商预置的临时密钥，也可以是由OEM密钥刷写装置从KMS获取到的中间密钥。基于第二密钥的不同，该第一密钥可用于替换预置在ECU-1中的临时密钥，也可用于更新该ECU-1上一次获取到的中间密钥。本申请实施例对此不作限定。
示例性地，第一密钥可以是KMS预先生成并保存在本地维护的数据库中选择出的密钥，也可以是随机生成的密钥。本申请实施例对此不作限定。KMS可以基于第二密钥加密该第一密钥，以得到加密的第一密钥。
在一种实现方式中，KMS可以通过密钥导出函数(key derivation function，KDF)，基于第二密钥、参数Key_update_ENC_C和Key_update_MAC_C，派生出与第二密钥对应的K1、K2两个派生密钥。其中，参数Key_update_ENC_C和Key_update_MAC_C的具体取值可以是预定义的，比如在相关的技术规范中预定义。所述技术规范例如可以是在汽车开放系统架构(automotive open system architecture，AUTOSAR)组织发布的安全硬件扩展(secure hardware extension，SHE)。
K1、K2的生成例如可通过公式表示如下：
K1＝KDF(Key0，Key_update_ENC_C)；
K2＝KDF(Key0，Key_update_MAC_C)。
此后，KMS可以使用高级加密标准(advanced encryption standard，AES)基于上述K1得到加密的第一密钥，例如记为CT1。
CT1的生成例如可通过公式表示为：CT1＝AES(K1，Key1|CNT1)。
其中，CNT1是由KMS本地的计数器(count，CNT)输出的计数值，可用于计数，每次加密前可自加1，通过验证接收到的CNT与本地CNT的大小关系，可达到防重放攻击的目的。
KMS可进一步使用基于分组加密的消息认证码(cypher-based message authentication code，CMAC)，基于上述参数K2和加密的第一密钥CT1得到消息认证码(message authentication code，MAC)。为便于区分，这里将基于加密的第一密钥CT1生成的MAC记为MAC1。
消息认证码MAC1的生成例如可通过公式表示为：MAC1＝CMAC(K2，CT1)。
在步骤260中，KMS基于第一密钥加密功能密钥，得到加密的功能密钥。
示例性地，功能密钥可以是KMS预先生成并保存在本地维护的数据库中选择出的密钥，也可以是随机生成的密钥。本申请实施例对此不作限定。
应理解，KMS基于第一密钥加密功能密钥，与KMS基于第二密钥加密第一密钥的过程可以是相似的。
在一种实现方式中，KMS可以通过KDF，基于第一密钥、Key_update_ENC_C、Key_update_MAC_C，派生出与第一密钥对应的K3、K4两个参数。
K3、K4的生成例如可通过公式表示如下：
K3＝KDF(Key1，Key_update_ENC_C)；
K4＝KDF(Key1，Key_update_MAC_C)。
此后，KMS可以使用AES，基于上述K3得到加密的功能密钥，例如记为CT2。
CT2的生成例如可通过公式表示为：CT2＝AES(K3，Key2|CNT2)。
其中，CNT2可用于计数，每次加密前可自加1。
KMS可进一步使用CMAC，基于上述K4和上述加密的功能密钥CT2，得到功能密钥的验证码MAC2。
验证码MAC2的生成例如可通过公式表示为：MAC2＝CMAC(K4，CT2)。
应理解，由于ECU-1可能用于一个或多个业务，因此可能申请一个或多个功能密钥。若ECU-1申请多个功能密钥，则KMS可基于第一密钥对多个功能密钥分别进行加密，并可进一步生成对应的MAC。KMS例如可以基于步骤260所提供的实现方式来实现多个功能密钥的加密和多个MAC的生成。换言之，上文所列举的用于生成加密的功能密钥的公式中，Key2也可以替换为Key3、Key4等其他功能密钥。为了简洁，这里不再一一举例说明。
还应理解，上文步骤250和步骤260中列举的用于生成加密密钥和生成MAC的算法仅为示例，不应对本申请实施例构成任何限定。本领域的技术人员可知，加密算法例如还可以包括数据加密标准(data encrytion standard，DES)等，MAC算法例如还可以包括基于哈希运算得到加密的消息验证码HMAC(hash-based message authentication code，HMAC)等，本申请实施例在此不做限定。
还应理解，KMS每一次对密钥加密，其对应的计数值(如上文中的CNT1和CNT2所示)可自动加一，该计数值可作为用于加密密钥的参数，从而达到防重放攻击的效果。所谓重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程，破坏认证的正确性。
例如，KMS和ECU-1中都可以设置有计数器。若KMS中计数器的计数值大于ECU-1中计数器的计数值，则表明ECU-1中可能存在数据包丢失的情况；若KMS计数器的计数值与ECU-1中计数器的计数值一致，表明ECU-1中可能不存在数据包丢失的情况；若KMS中计数器的计数值小于ECU-1中计数器的计数值，则表明该消息可能为重放消息。
在步骤270中，KMS向OEM密钥刷写装置发送密钥信息，该密钥信息包括加密的第一密钥和加密的功能密钥。
KMS可通过OEM服务器向OEM密钥刷写装置转发该密钥信息。由于该密钥信息中加密的第一密钥(即，上述CT1)和加密的功能密钥(即，上述CT2)经过了加密处理， OEM服务器和OEM密钥刷写装置在未获取到用于加密第一密钥和功能密钥的密钥的情况下，是无法获取到第一密钥和功能密钥的。从而可以保证该第一密钥和功能密钥在从KMS发送至OEM密钥刷写装置的过程中不被泄漏。
可选地，该密钥信息还包括第一密钥的MAC(即，上述MAC1)和功能密钥的MAC(即，上述MAC2)。
该OEM密钥刷写装置还可以根据预先确定的ECU-1对功能密钥的类型及其数量的需求，确定对来自KMS的密钥信息是否接收完全，并进一步确定ECU-1所需的功能密钥是否已从KMS全部获取到。
举例而言，若ECU-1需要的密钥数量为3，OEM密钥刷写装置从KMS接收到的加密密钥的数量也为3，则可确定该OEM密钥刷写装置对来自KMS的密钥信息已接收完全。若ECU-1请求的密钥数量为3，OEM密钥刷写装置从KMS接收到的加密密钥的数量为2，则可确定该OEM密钥刷写装置可能对来自KMS的加密密钥接收不完全，或者，可能存在没有成功获取的密钥。可选地，该密钥信息还包括密钥数量的指示，以便于OEM密钥刷写装置基于此来检测是否对来自KMS的加密的密钥(或者说密钥)接收完全。
应理解，KMS可以在每一次生成加密的密钥后，发送给OEM密钥刷写装置，即，步骤270可通过多个发送的步骤来实现；也可以在对下发给ECU-1的加密的密钥全部加密完成后，一起发送给OEM密钥刷写装置，即，步骤270可以通过一个发送的步骤来实现。本申请实施例对此不作限定。图中仅为示例，示出了通过一个步骤向OEM密钥刷写装置发送加密的第一密钥和加密的功能密钥的过程。为了更好地管理密钥和维护密钥状态，本申请实施例中的OEM密钥刷写装置还可本地记录向KMS请求的密钥的类型和数量。例如，OEM密钥刷写装置可记录上述ECU-1与请求的密钥的类型、数量的对应关系。其中，密钥的类型可通过密钥代号来表示。每个密钥代号可表示一种类型的密钥。比如可根据下文表2所示来定义各种类型的密钥：
表2
密钥代号 密钥类型
1000 ECU密钥
2000 SecOC密钥
2001 设备密钥
应理解，表2仅为便于理解，示例性地给出了几种类型的密钥类型与密钥代号的对应关系。事实上，密钥类型并不限于表2中所列举。还应理解，本申请对于密钥代号与密钥类型的对应关系，以及密钥代号的具体表示方法和取值均不作限定。
表3示出了OEM密钥刷写装置本地记录的ECU-1与该ECU-1请求的密钥的类型和数量的对应关系。
表3
ECU 密钥类型 数量
ECU-1 1000 1
ECU-1 2000 2
ECU-1 2001 1
应理解，表3仅为便于理解，示出了OEM密钥刷写装置本地记录的ECU-1与请求的 密钥的类型和数量的对应关系的一例。该对应关系可以以列表形式来表征，也可以以其他形式来表征。例如，可以按照预设的规则，将同一个ECU申请的密钥的类型和数量写在一个集合中。比如，表3中所示的对应关系可以变形为{ECU-1：1000，1；2000，2；2001，1}。本申请包括但不限于此。
例如，该列表中可以不包括数量，而将ECU-1请求的密钥所属的类型分别记录，如下文表4所示。可以理解，表4中的每一行对应一个密钥，虽然第二行和第三行的密钥类型相同，但表示的是不同的密钥。
表4
ECU 密钥类型
ECU-1 1000
ECU-1 2000
ECU-1 2000
ECU-1 2001
应理解，上述对应关系还可通过其他可能的形式来表征，本申请实施例对此不作限定。
在本申请实施例中，将上述用于记录ECU-1与ECU-1请求的密钥的类型和数量的对应关系的列表称为密钥列表。应理解，上文列举的表3和表4仅为密钥列表的两例。下文中会结合其他表格示出更多关于密钥列表的示例。
可选地，上述密钥信息中还包括密钥代号。
OEM密钥刷写装置可以基于接收到的密钥代号，以及密钥列表中记录的ECU-1需要的密钥类型，以确定是否接收到正确类型的密钥。
可选地，该密钥列表还包括各密钥的标识信息。
具体地，各密钥的标识信息可以包括：第一密钥的标识信息(例如可简称为第一密钥标识)、以及一个或多个功能密钥的标识信息(例如可简称为功能密钥标识)。
前已述及，密钥的标识信息(例如可简称为密钥标识)可以是该密钥的哈希值。OEM密钥刷写装置可以在本地记录接收到的密钥的标识信息。例如，该密钥列表可以是在上文列举的如表4所示的对应关系中增加密钥的标识信息而得到。表5示出了密钥列表的又一例。
表5
ECU 密钥标识 密钥类型
ECU-1 Key1-ID 1000
ECU-1 Key2-ID 2000
ECU-1 Key3-ID 2000
ECU-1 Key4-ID 2001
由于OEM密钥刷写装置后续可以将从KMS接收到的密钥发送至ECU，以便于ECU将新申请到的密钥写入本地。OEM密钥刷写装置为了确定ECU是否写入成功，可以根据从ECU获取到的密钥的标识信息和本地记录的标识信息进行校验。由于OEM密钥刷写装置本地记录了从KMS获取到的密钥的标识信息，OEM密钥刷写装置不必再与KMS交互，便可完成校验，故可将此次校验称为离线校验。
由于后文中将会在方法300描述的密钥写入流程中详细说明离线校验的过程，这里暂 且省略对离线校验的具体描述。
为了更全面地了解到ECU申请的各个密钥的状态，OEM密钥刷写装置还可以在本地维护密钥状态。密钥状态具体可以是指每个密钥的状态，比如，需要申请、成功获取、写入成功、写入失败以及默认值等。
密钥状态可以通过不同的状态代号来表示。每个状态代号可表示一种含义。密钥状态及其对应的状态代号可参看上文结合表1的示例。为了简洁，这里不再赘述。
OEM密钥刷写装置可以在每一次接收到来自ECU的密钥写入请求和/或每一次从KMS获取到密钥或接收到错误指示的时候，对该密钥状态进行更新，以使该密钥状态实时地反映ECU中各密钥的状态。
下文的表6和表7示例性地给出了密钥状态的两例。
表6
密钥标识 状态
Key1-ID 0x02
Key2-ID 0x01
Key3-ID 0x01
Key4-ID 0x01
表7
密钥标识 状态
Key1-ID 0x02
Key2-ID 0x02
Key3-ID 0x02
Key4-ID 0x02
根据上文表1中所列举的状态代号与含义的对应关系，可确定表6中所示的各密钥的状态如下：第一密钥(也即Key1)密钥已成功获取，功能密钥(包括Key2、Key3和Key4)需要写入；还可确定表7中所示的各密钥的状态如下：第一密钥(也即Key1)和功能密钥(包括Key2、Key3和Key4)均已成功获取。该密钥状态信息也可以作为密钥列表中的一项，在OEM密钥刷写装置本地维护。表8示出了密钥列表的再一例。
表8
ECU 密钥标识 密钥类型 数量 状态
ECU-1 Key1-ID 1000 1 0x02
ECU-1 Key2-ID 2000 1 0x02
ECU-1 Key3-ID 2000 1 0x02
ECU-1 Key4-ID 2001 1 0x02
应理解，上文结合表3至表8所示的密钥列表仅为示例，在上文所示例的基础上，本领域的技术人员可以做出等价的变换得出其他形式的密钥列表，或其他可用于表示各密钥的类型、标识信息、状态之间对应关系的形式。这些变换都应落入本申请的保护范围内。
可以理解，在实际应用中，OEM密钥刷写装置可以为多台整车、多个ECU申请密钥。上文的步骤210中的ECU-1可以是多个ECU中的任意一个。换言之，多个ECU中的每个ECU可以通过执行步骤210向OEM密钥刷写装置发送第二密钥标识。可以理解，不同的 ECU中可能预先存储了不同的第二密钥，对应的第二密钥标识也不同。
此外，为了区分不同的整车和ECU，各整车中的ECU均可以向OEM密钥刷写装置发送ECU的设备识别码、ECU设备类型和整车识别码(vehicle identification number，VIN)。ECU的设备识别码和ECU设备类型可用于标识一个ECU。整车识别码可用于标识一台整车。
其中，ECU的设备识别码例如可以是零件编号(part number，PART#)。
ECU设备类型例如可以包括但不限于，发动机管理系统(engine management system，EMS)、自动变速箱控制单元(transmission control unit，TCU)、车身控制模块(body control module，BCM)、电子稳定控制系统(electronic stability program，ESP)、电池管理系统(battery management system，BMS)、整车控制器(vehicle control unit，VCU)等。
在有些情况下，ECU的设备识别码中包含了该ECU的设备类型的指示信息。此情况下，ECU可直接由设备识别码来标识。
基于上文对ECU的设备识别码、ECU设备类型以及VIN的说明ECU的设备识别码和整车识别码可用于指示一台整车的一个ECU。
各ECU向OEM密钥刷写装置发送ECU的设备识别码、ECU设备类型以及整车识别码的操作例如可以与上文步骤210合并为同一个步骤来执行，也可以分别执行。本申请实施例对此不作限定。
可选地，上述密钥信息中包括ECU-1的设备识别码、ECU-1的设备类型和VIN。
OEM密钥刷写装置可以基于从ECU-1接收到的ECU-1的设备识别码、ECU-1的设备类型和VIN，以及从KMS接收到的ECU-1的设备识别码、ECU-1的设备类型和VIN，检查ECU-1的设备识别码、ECU-1的设备类型和VIN。
可选地，该密钥列表还包括各ECU的设备识别码、ECU设备类型、整车识别码(vehicle identification number，VIN)中的一项或多项。
表9列举了OEM密钥刷写装置本地维护的密钥列表的一例。
表9
密钥类型 密钥ID ECU-1 ECU-2 ECU-3 ECU-4
1000 Key1-ID 0xFF 0xFF 0xFF 0x01
2000 Key2-ID 0xFF 0x00 0x13 0x01
2000 Key3-ID 0xFF 0x00 0x13 0x01
2001 Key4-ID 0x00 0xFF 0x02 0x00
应理解，表9只是示例性地给出了多个ECU(包括ECU-1至ECU-4)对几种类型的密钥进行密钥写入时，OEM密钥刷写装置本地维护的密钥列表的一例。事实上，ECU个数、密钥类型以及密钥状态并不限于表9中所列举。
除了上文表1中所列举的状态代号，表9还示例性地示出了状态为写入错误状态码“其他”的一例。如表9中所示，ECU-3的功能密钥(具体为SecOC密钥)的状态代号为0x13，可表示该ECU-3的SecOC密钥写入失败，终止刷写。导致ECU-3的SecOC密钥写入失败的错误类型，例如可能是通过MAC验证、或没有通过CNT校验等，本申请实施例对此不作限定。
应理解，OEM密钥刷写装置可以根据密钥列表，按照上文步骤210至步骤270所述的 方法，分别从KMS获取每个ECU请求写入的密钥。
下面将结合图3详细说明向ECU写入密钥的流程。可以理解，向ECU写入密钥的流程是在上文所述的从KMS获取密钥的流程之后执行的流程。为了更好地理解向ECU写入密钥的流程与上文从KMS获取密钥的流程之间的关系，下文仍以上述ECU-1为例来说明。OEM密钥刷写装置为该ECU-1申请到的密钥包括第一密钥(即Key1)和功能密钥(假设包括上文列举的Key2、Key3和Key4)。
图3是本申请实施例提供的一种向ECU写入密钥的方法300的示意性流程图。应理解，OEM密钥刷写装置已经从KMS获取到了用于写入ECU-1的中间密钥(如上文所述的第一密钥)的密文和功能密钥的密文，故可通过下述流程来为ECU-1下发密钥。
如图3所示，该方法300可以包括步骤301至步骤324。下面对方法300中的各个步骤做详细说明。
在步骤301中，OEM密钥刷写装置向ECU-1发送加密的第一密钥。相应地，ECU-1从OEM密钥刷写装置接收加密的第一密钥。
应理解，所述加密的第一密钥，即为步骤270中，OEM密钥刷写装置接收到的由KMS发送的加密的第一密钥(如，上文列举的CT1)。
在步骤302中，ECU-1解密该加密的第一密钥，以获得并写入该第一密钥。
如前所述，该第一密钥由第二密钥加密而得到，而该第二密钥是上文方法200中KMS基于从ECU-1获取到的第二密钥标识进行本地查找而获得的密钥，由于ECU-1中预存有该第二密钥，故ECU-1可以根据该第二密钥来解密接收到的加密的第一密钥，进而获得该第一密钥。
可选地，该方法可以包括：OEM密钥刷写装置向ECU-1发送第一密钥的MAC(如，上文列举的MAC1)。相应地，ECU-1从OEM密钥刷写装置接收第一密钥的MAC。
此情况下，ECU-1可以先基于接收到的第一密钥的MAC进行MAC验证，以完成对加密的第一密钥的认证和完整性校验。ECU-1可以在验证成功的情况下解密加密的第一密钥，进而得到第一密钥。
可选地，该方法还可以包括：OEM密钥刷写装置向ECU-1发送第一密钥的CNT(如，上文列举的CNT1)。相应地，ECU-1从OEM密钥刷写装置接收第一密钥的CNT。
此情况下，ECU-1在解密得到第一密钥之后，可以基于接收到的CNT进行CNT校验，以防重放攻击。ECU-1可以在校验成功的情况下将该第一密钥写入本地。
基于上文所述，ECU-1可以从OEM密钥刷写装置接收到加密的第一密钥以及与第一密钥对应的MAC和CNT。ECU-1可以先进行MAC验证，在验证成功后解密获得第一密钥，并在解密成功后进行CNT校验。
应理解，OEM密钥刷写装置可以将加密的第一密钥、第一密钥对应的MAC和/或CNT携带在同一条信令中发送给ECU-1，也可以通过不同的信令分别发送给ECU-1，本申请实施例对此不作限定。ECU-1可以将解密获得的第一密钥存储在本地。
示例性地，ECU-1可以将该解密的第一密钥用来替代预存的第二密钥。例如，ECU-1可以将原本存储在本地的第二密钥删除，并写入第一密钥。由此实现了一次中间密钥的刷写过程。
可选地，ECU-1在CNT校验成功的情况下，还可将该第一密钥的CNT也存储在本地， 以便于对后续接收到的CNT进行校验。
需要说明的是，ECU可以将密钥(包括上述第二密钥、第一密钥以及功能密钥)存储在本地某一指定的存储区域。密钥一旦被写入，就不能再从该存储区域中读取，而只能读取到与之对应的标识信息，也即密钥标识。因此，在本申请实施例中，ECU-1一旦将第一密钥写入，其他设备便无法读取到该第一密钥；ECU-1一旦将功能密钥写入，其他设备也无法读取到功能密钥。因此，第一密钥和功能密钥在从KMS下发至ECU-1的过程中，一直都对第三方不可见，从而可以避免密钥泄漏，具有较高的安全性。
在步骤303中，ECU-1向OEM密钥刷写装置发送状态码。相应地，OEM密钥刷写装置从ECU-1接收状态码。
ECU-1可以基于MAC验证是否成功、第一密钥是否成功获得以及CNT校验是否成功，向OEM密钥刷写装置发送状态码。
示例性地，ECU-1在出现如下至少一种情况时，可以向OEM密钥刷写装置发送错误状态码，以指示写入失败：基于接收到的MAC1进行的MAC验证失败、对加密的第一密钥解密失败以及基于接收到的CNT1进行的CNT校验失败。该失败状态码例如可以是上文所列举的0x13。
ECU-1也可以在基于接收到的MAC1进行的MAC验证成功、对加密的第一密钥解密成功以及基于接收到的CNT1进行的CNT校验成功的情况下，向OEM密钥刷写装置发送成功状态码，以指示写入成功，可继续该密钥写入流程。该成功状态码例如可以是上文所列举的0xFF。
在步骤304中，OEM密钥刷写装置根据接收到的状态码，确定该第一密钥是否被成功写入ECU-1。
若OEM密钥刷写装置接收到的状态码为错误状态码，则可终止刷写。OEM密钥刷写装置还可执行步骤305，将该第一密钥的状态码更新为错误状态码。例如，OEM密钥刷写装置可根据接收到的错误状态码0x13，更新本地维护的密钥列表，将第一密钥的状态更新为0x13。
OEM密钥刷写装置中的密钥列表可以如表10中所示：
表10
密钥类型 密钥ID ECU-1
1000 Key1-ID 0x13
2000 Key2-ID 0x01
2000 Key3-ID 0x01
2001 Key4-ID 0x01
可以看到，OEM密钥刷写装置在密钥列表中记录了第一密钥(即，Key1)写入失败，终止密钥写入流程；功能密钥(包括Key2、Key3、Key4)需要写入。
若OEM密钥刷写装置接收到的状态码为写入成功状态码，则可继续执行步骤306及其后续相关步骤。
OEM密钥刷写装置可通过执行如下操作来实现步骤304：OEM密钥刷写装置可判断接收到的状态码是否为0xFF(即，写入成功)。若是，则接收到的状态码为写入成功状态码；若否，则接收到的状态码为错误状态码。
在步骤306中，OEM密钥刷写装置向ECU-1发送获取第一密钥标识的请求。
在步骤307中，ECU-1生成第一密钥标识。
ECU-1可以基于在步骤306中接收到的来自OEM密钥刷写装置的请求，对解密获得的第一密钥进行哈希运算，得到第一密钥标识。
在步骤308中，ECU-1向OEM密钥刷写装置发送该第一密钥标识。
在步骤309中，OEM密钥刷写装置进行离线验证，以确定ECU-1是否成功写入第一密钥。
OEM密钥刷写装置可以将从ECU-1获取的第一密钥标识与本地记录(比如在密钥列表中记录)的第一密钥标识进行比对，进而确定第一密钥是否被成功写入ECU-1。换言之，步骤309中OEM密钥刷写装置进行的离线验证，是对第一密钥标识的离线验证。如果该第一密钥已经被写入ECU-1，则该OEM密钥刷写装置获取到的第一密钥标识与本地记录的第一密钥标识是一致的；如果该第一密钥未被成功写入ECU-1，则该OEM密钥刷写装置获取到的第一密钥标识与本地记录的第一密钥标识是不同的。由此，OEM密钥刷写装置可以判断该第一密钥是否被成功写入ECU-1。
应理解，OEM密钥刷写装置可以通过将预先在本地记录的第一密钥标识与从ECU-1获取的第一密钥标识进行比对，来确定第一密钥是否被成功写入ECU-1，而不再需要从KMS再次获取第一密钥标识，也即不需要依赖于网络，因此称之为离线验证。此外，因OEM不需要从KMS再次获取第一密钥标识，也可以减少信令交互带来的时间开销。再者，通过对第一密钥标识进行比对，而非对第一密钥进行比对，还可以避免密钥泄露的问题。
在步骤310中，OEM密钥刷写装置根据离线验证的结果，更新第一密钥的密钥状态。
若OEM密钥刷写装置从ECU-1获取的第一密钥标识与OEM密钥刷写装置中本地记录的第一密钥标识不一致，则可确定该第一密钥未被成功写入。OEM密钥刷写装置可以执行步骤310a，将该第一密钥的状态码更新为错误状态码。OEM密钥刷写装置由此可终止该密钥写入流程，不再将加密的功能密钥发送给ECU-1。
应理解，OEM密钥刷写装置执行步骤310a的具体过程与上述步骤305的具体过程相似，这里不再赘述。
还应理解，OEM密钥刷写装置可以针对该错误类型，记录对应的状态代号，以便于后续根据该状态代号可以快速找到错误类型，方便对问题快速定位和后续的调试解决。
若OEM密钥刷写装置从ECU-1获取的第一密钥标识与OEM密钥刷写装置中本地记录的第一密钥标识一致，确定该第一密钥的写入成功。
在此情况下，OEM密钥刷写装置可确定该功能密钥被成功写入。执行步骤310b，将该第一密钥的状态码更新为成功写入状态码。OEM密钥刷写装置中列表状态可以如表11所示：
表11
密钥类型 密钥ID ECU-1
1000 Key1-ID 0xFF
2000 Key2-ID 0x01
2000 Key3-ID 0x01
2001 Key4-ID 0x01
OEM密钥刷写装置可继续执行后续步骤311至步骤320。
应理解，为便于理解和说明，下文的步骤311至312中以一个功能密钥(如Key2)为例来描述在ECU-1中写入功能密钥的过程，但这不应对本申请构成任何限定。本申请实施例对于为每个ECU下发的功能密钥的数量和类型均不作限定。
在步骤311中，OEM密钥刷写装置向ECU-1发送加密的功能密钥。
这里，加密的功能密钥可以是上文方法200的步骤270中OEM密钥刷写装置从KMS接收到的加密的功能密钥(如，上文列举的CT2)。
在步骤312中，ECU-1解密该加密的功能密钥，以获得并写入功能密钥。
如前所述，该功能密钥由第一密钥加密而得到，而该第一密钥可基于上文步骤301和步骤302中的步骤获得，故ECU-1可以根据该第一密钥来解密接收到的加密的功能密钥，进而获得该功能密钥。
应理解，OEM密钥刷写装置可能向ECU-1发送加密的功能密钥。对于每个加密的功能密钥，ECU-1都可以基于第一密钥来解密。
可选地，该方法可以包括：OEM密钥刷写装置向ECU-1发送功能密钥的MAC(如，上文列举的MAC2)。相应地，ECU-1从OEM密钥刷写装置接收功能密钥的MAC。
此情况下，ECU-1可以先基于接收到的功能密钥的MAC进行MAC验证，以完成对加密的功能密钥的认证和完整性校验。ECU-1可以在验证成功的情况下解密加密的功能密钥，进而得到功能密钥。
可选地，该方法还可以包括：OEM密钥刷写装置向ECU-1发送功能密钥的CNT(如，上文列举的CNT2)。相应地，ECU-1从OEM密钥刷写装置接收功能密钥的CNT。
此情况下，ECU-1在解密得到功能密钥之后，可以基于接收到的功能密钥的CNT，进行CNT校验，以确定解密所得的功能密钥是否真实地来源于KMS。ECU-1可以在校验成功的情况下将该功能密钥写入本地。
可以理解，每个功能密钥可对应于一个MAC，也可对应一个CNT。ECU-1可以分别对每个功能密钥的MAC进行MAC验证，进而在验证成功的情况下，解密该MAC对应的功能密钥；在解密得到功能密钥后，可进一步对该功能密钥的CNT进行校验。
应理解，OEM密钥刷写装置可以将加密的功能密钥、功能密钥对应的MAC和/或CNT携带在同一条信令中发送给ECU-1，也可以通过不同的信令分别发送给ECU-1，本申请实施例对此不作限定。
ECU-1可以将解密获得的功能密钥存储在本地。
示例性地，ECU-1可以将该解密的功能密钥存储在指定的存储区域，由此实现了该功能密钥的写入。
可选地，ECU-1在CNT校验成功的情况下，还可以将功能密钥的CNT也存储在本地，以便于对后续接收到的CNT进行校验。
可以理解，当OEM密钥刷写装置向ECU-1发送了多个加密的功能密钥时，ECU-1可以基于每一个功能密钥进行MAC验证和/或CNT校验，并在MAC验证成功和/或CNT校验合格后，将相应的功能密钥存储在本地。
应理解，OEM密钥刷写装置向ECU-1发送加密的功能密钥的过程也就是OEM密钥刷写装置为ECU-1下发功能密钥的过程，只是该功能密钥是以密文的形式下发的。
此后，OEM密钥刷写装置可通过下文所述的离线验证来确定其下发的功能密钥是否被成功写入ECU-1。应理解，OEM密钥刷写装置可以对下发的一个或多个功能密钥对应的功能密钥标识分别进行离线验证，以确定每个功能密钥是否被成功写入ECU-1。
为便于理解和说明，下文的步骤313至步骤320仍以一个功能密钥为例来描述离线验证的过程。
在步骤313中，ECU-1向OEM密钥刷写装置发送状态码。相应地，OEM密钥刷写装置从ECU-1接收状态码。
应理解，步骤313的具体过程与上文步骤303的具体过程相似。所不同的是，步骤313中ECU-1发送的状态码所指示的是功能密钥是否被成功写入的状态码，步骤303中的状态码所指示的是第一密钥是否被成功写入的状态码。步骤313的具体过程可参看上文步骤303的相关描述，这里不做赘述。
在步骤314中，OEM密钥刷写装置根据接收到的状态码，确定该功能密钥是否被成功写入。
若OEM密钥刷写装置接收到的状态码为错误状态码，则可执行步骤315，将该功能密钥的状态码更新为错误状态码。例如，OEM密钥刷写装置可根据接收到的错误状态码0x13，更新本地维护的密钥列表，将该功能密钥的状态更新为0x13。
以SecOC密钥(即，功能密钥的一例，其对应的密钥类型的代号为2000)为例，OEM密钥刷写装置中的密钥列表可以如表12中所示：
表12
密钥类型 密钥ID ECU-1
1000 Key1-ID 0xFF
2000 Key2-ID 0x13
可以看到，OEM密钥刷写装置在密钥列表中记录了第一密钥(即，Key1)写入成功；功能密钥(即，Key2)写入失败。
若OEM密钥刷写装置接收到的状态码为写入成功状态码，OEM密钥刷写装置可通过离线验证，再次确认该功能密钥是否被成功写入ECU-1。
在步骤316中，OEM密钥刷写装置向ECU-1发送获取功能密钥标识的请求。
OEM密钥刷写装置可以基于接到的写入成功状态码，向ECU-1发送该请求，以请求获得该功能密钥标识。
在步骤317中，ECU-1生成功能密钥标识。
ECU-1可以基于在步骤317中接收到的来自OEM密钥刷写装置的请求，对在步骤312中解密获得的功能密钥进行哈希运算，得到功能密钥标识。
在步骤318中，ECU-1向OEM密钥刷写装置发送该功能密钥标识。
在步骤319中，OEM密钥刷写装置进行离线验证，以确定该功能密钥是否被成功写入ECU-1。
OEM密钥刷写装置可以根据将从ECU-1获取的功能密钥标识与本地记录(比如在密钥列表中记录)的功能密钥标识进行比对，进而确定该功能密钥是否被成功写入ECU-1。换言之，步骤319中OEM密钥刷写装置进行的离线验证，是对功能密钥标识的离线验证。如果该功能密钥已经被成功写入ECU-1，则该OEM密钥刷写装置获取到的功能密钥标识 与本地记录的功能密钥标识是一致的；如果该功能密钥未被成功写入ECU-1，则该OEM密钥刷写装置获取到的功能密钥标识与本地记录的功能密钥标识是不同的。由此，OEM密钥刷写装置可以判断该功能密钥是否被成功写入ECU-1。
应理解，与对第一密钥标识的离线验证相似，OEM密钥刷写装置对功能密钥标识的验证也不需要依赖于网络，因此也可以称之为离线验证。通过离线验证，可以减少信令交互带来的时间开销，也可避免功能密钥泄漏的问题。
在步骤320中，OEM密钥刷写装置根据离线验证的结果，更新功能密钥的密钥状态。
若OEM密钥刷写装置从ECU-1获取的功能密钥标识与OEM密钥刷写装置本地记录的功能密钥标识不一致，则可确定该功能密钥未被成功写入。OEM密钥刷写装置可以执行步骤320a，将该功能密钥的状态码更新为错误状态码。应理解，OEM密钥刷写装置执行步骤320a的具体过程与上述步骤305的具体过程相似，这里不再赘述。
若OEM密钥刷写装置从ECU-1获取的功能密钥标识与OEM密钥刷写装置本地记录的功能密钥标识一致，则执行步骤320b，将该功能密钥的状态码更新为写入成功状态码。
仍以SecOC密钥为例，OEM密钥刷写装置中列表状态可以如表13所示：
表13
密钥类型 密钥ID ECU-1
1000 Key1-ID 0xFF
2000 Key2-ID 0xFF
由此，该功能密钥被成功写入至ECU-1中。
通过执行上述步骤311至步骤320，可以实现对多个功能密钥的写入。若OEM密钥刷写装置对其下发的多个功能密钥的状态都为写入成功，则可得到更新后的密钥列表如表14所示：
表14
密钥类型 密钥ID ECU-1
1000 Key1-ID 0xFF
2000 Key2-ID 0xFF
2000 Key3-ID 0xFF
2001 Key4-ID 0xFF
应理解，表14仅示出了对ECU-1下发的密钥的密钥状态。OEM密钥刷写装置可以为更多的ECU申请和下发密钥。基于这样的设计，表14还可以变形为记录有为多个ECU下发的密钥的列表。为了简洁，这里不再列举说明。
另一方面，OEM密钥刷写装置在为ECU-1下发密钥之前，可以先确认该ECU-1是否已经写入了该密钥，从而可以避免OEM密钥刷写装置对同一密钥重复多次下发。
例如，在本实施例中，OEM密钥刷写装置在执行步骤301之前，可以先确认该ECU-1是否已经成功写入第一密钥；OEM密钥刷写装置在执行步骤311之前，可以先确认该ECU-1是否已经成功写入功能密钥。
可选地，在步骤301之前，该方法还包括：
步骤321，OEM密钥刷写装置从ECU-1获取预存的第三密钥标识；
步骤322，OEM密钥刷写装置确定从ECU-1获取的第三密钥标识是否为第一密钥标 识。
如果ECU-1在步骤301之前就已写入第一密钥，则在步骤321中OEM密钥刷写装置从ECU-1获取的第三密钥标识即为第一密钥标识；如果ECU-1在步骤301之前未写入第一密钥，则在步骤321中OEM密钥刷写装置从ECU-1获取的第三密钥标识不是第一密钥标识，有可能是上文方法200中所述的第二密钥标识，也有可能是其他。本申请实施例对此不作限定。
OEM密钥刷写装置可以将从ECU-1获取到的第三密钥标识和本地记录的第一密钥标识进行比对，以确定从ECU-1获取的第三密钥标识是否为第一密钥标识。若二者一致，则表示该ECU-1中已经成功写入了第一密钥，可直接执行上文的步骤310b及后续步骤，而将步骤301至步骤309以及步骤310a省略；若二者不一致，则表示该ECU-1中未成功写入该第一密钥，可执行上文的步骤301至步骤320。
可选地，在步骤311之前，该方法还包括：
步骤323，OEM密钥刷写装置从ECU-1获取预存的第四密钥标识；
步骤324，OEM密钥刷写装置确定从ECU-1获取的第四密钥标识是否为功能密钥标识。
步骤323和步骤324的具体过程与上文步骤321和步骤322的具体过程相似，所不同的是，步骤321和步骤322用于确定ECU-1是否已经成功写入第一密钥，步骤323和步骤324用于确定ECU-1是否已经成功写入功能密钥。
需要说明的是，第三密钥标识和第四密钥标识可能被存储在不同的存储区域。OEM密钥刷写装置从ECU-1获取第三密钥标识和第四密钥标识时，可以指定在不同的存储区域读取不同的密钥标识。
本申请实施例中引入中间密钥，一方面基于另一密钥(比如临时密钥或另一中间密钥)后下发给ECU，减小了泄漏风险；另一方面用于加密功能密钥，使得功能密钥在被下发给ECU的过程中的泄漏风险也得以减小。由此，实现了对整车计算机系统的密钥写入，不依赖于预置密钥，对功能密钥的保护大大增强，密钥泄漏的风险大大减小。
此外，由于引入了密钥列表，OEM密钥刷写装置可以对其申请及下发的密钥的状态进行实时更新，从而可以在密钥写入流程出现错误时，快速定位问题，从而可以及时调试。
再者，由于OEM密钥刷写装置本地维护该密钥列表，可以对其下发给ECU的密钥进行离线验证，不依赖于网络，既可以减少信令开销，也可以减少时间开销。
基于与上述方法相同的构思，本申请实施例还提供了一种密钥写入装置400，该装置可以包括：处理模块410和通信模块420。
在一种可能的设计中，该密钥写入装置可对应于上文方法实施例中的密钥管理装置。例如可以是OEM密钥刷写装置或经销商诊断仪。
其中，处理模块410可用于从KMS获取加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为所述KMS与ECU之间的约定密钥，且所述第一密钥对第三方不可见；通信模块420可用于向所述ECU发送所述加密的功能密钥。
可选地，该通信模块420还用于从所述ECU接收第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息；所述密钥管理装置向所述KMS发送所述第一密钥标识，所述第一密钥标识用于所述KMS确定所述第一密钥。
可选地，该处理模块410还用于从所述KMS获取加密的第一密钥，所述加密的第一密钥是基于预存在所述ECU中的第二密钥对所述第一密钥加密得到的；所述密钥管理装置将所述加密的第一密钥发送给所述ECU。
可选地，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
可选地，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
可选地，该通信模块420还用于从所述ECU接收第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息；所述密钥管理装置向所述KMS发送所述第二密钥标识，所述第二密钥标识用于所述KMS确定所述第二密钥。
可选地，该通信模块420还用于接收来自所述ECU的状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。
可选地，该处理模块410还用于本地维护密钥列表，所述密钥列表用于记录所述密钥管理装置为所述ECU请求的密钥的状态，所述状态包括以下一项或多项：需要申请、成功获取、写入成功和写入失败。
在另一种可能的设计中，该密钥写入装置400可对应于上文方法实施例中的ECU，如ECU-1。
其中，通信模块420可用于从密钥管理装置接收加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为KMS与所述ECU之间的约定密钥，且所述第一密钥对第三方不可见；处理模块410可用于基于所述第一密钥解密所述加密的功能密钥，以将获得的所述功能密钥写入本地。
可选地，该通信模块420还用于向所述密钥管理装置发送第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息，且所述第一密钥标识用于所述KMS确定所述第一密钥。
可选地，该通信模块420还用于从所述密钥管理装置接收加密的第一密钥，所述第一密钥是基于第二密钥对所述第一密钥加密得到的；该处理模块410还用于基于所述第一密钥解密所述加密的第一密钥，以将获得的所述第一密钥写入本地。
可选地，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
可选地，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。可选地，该通信模块420还用于向所述密钥管理装置发送第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息，用于KMS确定所述第二密钥。
可选地，该通信模块420还用于向所述密钥管理装置发送状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。
可选地，所述密钥管理装置为原始设备制造商密钥刷写装置，或，经销商诊断仪。
在又一种可能的设计中，该密钥写入装置可对应于上文方法实施例中的密钥管理服务器。
其中，处理模块410可用于基于从ECU获取到的第一密钥标识，确定用于加密功能密钥的第一密钥；所述第一密钥标识由所述ECU基于所述第一密钥计算生成，所述第一密钥是所述KMS与所述ECU之间的约定密钥，且所述第一密钥对第三方不可见； 所述KMS基于所述第一密钥加密所述功能密钥，得到加密的功能密钥。
通信模块420可用于向密钥管理装置发送加密的功能密钥。
可选地，该通信模块420还用于通过所述密钥管理装置向所述ECU发送加密的第一密钥，所述加密的第一密钥是基于第二密钥对第一密钥加密得到。
可选地，该处理模块410还用于从所述ECU获取第二密钥标识，所述第二密钥标识由所述ECU基于所述第二密钥计算生成的标识信息；所述KMS基于所述第二密钥标识信息，确定用于加密所述第一密钥的所述第二密钥。
可选地，该处理模块410还用于在基于所述第二密钥标识确定出所述第二密钥的情况下，基于所述第二密钥加密所述第一密钥，以获得加密的第一密钥。
可选地，该通信模块420还用于在基于所述第二密钥标识无法确定出所述第二密钥的情况下，向所述密钥管理装置发送错误提示。
可选地，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
可选地，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
可选地，所述密钥管理装置为原始设备制造商密钥刷写装置，或，经销商诊断仪。
应理解，密钥写入装置可以包括但不限于上文所列举的多个模块或单元。上文结合图4示出的各模块或单元仅为便于理解而示出，不应对本申请实施例构成任何限定。
图5是本申请实施例提供的一种密钥写入装置500的示意性框图。如图5所示，该计算设备500可以包括：处理器510、通信接口520和存储器530。其中，处理器510、通信接口520和存储器530通过内部连接通路互相通信，该存储器530用于存储指令，该处理器510用于执行该存储器530存储的指令，以控制该通信接口520发送信号和/或接收信号。
应理解，该密钥写入装置500可以用于执行上述方法实施例中各个步骤和/或流程。
可选地，该存储器530可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。存储器530可以是一个单独的器件，也可以集成在处理器510中。该处理器510可以用于执行存储器530中存储的指令，并且当该处理器510执行存储器中存储的指令时，该处理器510用于执行上述方法实施例的各个步骤和/或流程。
可选地，通信接口520也可以是输入/输出接口、电路等。该通信接口520与处理器510和存储器530都可以集成在同一个芯片中，也可以集成在不同的芯片中。本申请对此不作限定。
本申请还提供一种系统，所述系统包括前文所述的ECU、密钥管理装置和密钥管理服务器。
本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得电子设备执行图2或图3所示实施例中任意一个实施例的方法。
本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得电子设备执行图2或图3所示实施例中任意一个实施例的方法。
应理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电 路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
还应理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本说明书中使用的术语“单元”、“模块”等，可用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。在本申请所提供的几个实施例中，应该理解到，所揭露的装置、设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例 方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，各功能单元的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令(程序)。在计算机上加载和执行所述计算机程序指令(程序)时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请示例性的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (28)

  1. 一种密钥写入方法，其特征在于，包括：
    密钥管理装置从密钥管理服务器KMS获取加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为所述KMS与电子控制单元ECU之间的约定密钥，且所述第一密钥对第三方不可见；
    所述密钥管理装置向所述ECU发送所述加密的功能密钥。
  2. 如权利要求1所述的方法，其特征在于，在所述密钥管理装置从KMS获取加密的功能密钥之前，所述方法还包括：
    所述密钥管理装置从所述ECU接收第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息；
    所述密钥管理装置向所述KMS发送所述第一密钥标识，所述第一密钥标识用于所述KMS确定所述第一密钥。
  3. 如权利要求1或2所述的方法，其特征在于，在所述密钥管理装置从KMS获取加密的功能密钥之前，所述方法还包括：
    所述密钥管理装置从所述KMS获取加密的第一密钥，所述加密的第一密钥是基于预存在所述ECU中的第二密钥对所述第一密钥加密得到的；
    所述密钥管理装置将所述加密的第一密钥发送给所述ECU。
  4. 如权利要求3所述的方法，其特征在于，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
  5. 如权利要求3所述的方法，其特征在于，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
  6. 如权利要求3至5中任一项所述的方法，其特征在于，在所述密钥管理装置从所述KMS获取加密的第一密钥之前，所述方法还包括：
    所述密钥管理装置从所述ECU接收第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息；
    所述密钥管理装置向所述KMS发送所述第二密钥标识，所述第二密钥标识用于所述KMS确定所述第二密钥。
  7. 如权利要求2至6中任一项所述的方法，其特征在于，所述方法还包括：
    所述密钥管理装置接收来自所述ECU的状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。
  8. 如权利要求7所述的方法，其特征在于，所述密钥管理装置本地维护有密钥列表，所述密钥列表用于记录所述密钥管理装置为所述ECU请求的密钥的状态，所述状态包括以下一项或多项：需要申请、成功获取、写入成功和写入失败。
  9. 如权利要求1至8中任一项所述的方法，其特征在于，所述密钥管理装置为原始设备制造商密钥刷写装置，或，经销商诊断仪。
  10. 一种密钥写入方法，其特征在于，包括：
    电子控制单元ECU从密钥管理装置接收加密的功能密钥，所述加密的功能密钥是基于第一密钥加密得到的，所述第一密钥为密钥管理服务器KMS与所述ECU之间的 约定密钥，且所述第一密钥对第三方不可见；
    所述ECU基于所述第一密钥解密所述加密的功能密钥，以将获得的所述功能密钥写入本地。
  11. 如权利要求10所述的方法，其特征在于，在所述ECU从密钥管理装置接收加密的功能密钥之前，所述方法还包括：
    所述ECU向所述密钥管理装置发送第一密钥标识，所述第一密钥标识是基于所述第一密钥计算生成的标识信息，且所述第一密钥标识用于所述KMS确定所述第一密钥。
  12. 如权利要求10或11所述的方法，其特征在于，在所述ECU从密钥管理装置接收加密的功能密钥之前，所述方法还包括：
    所述ECU从所述密钥管理装置接收加密的第一密钥，所述第一密钥是基于第二密钥对所述第一密钥加密得到的；
    所述ECU基于所述第一密钥解密所述加密的第一密钥，以将获得的所述第一密钥写入本地。
  13. 如权利要求12所述的方法，其特征在于，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
  14. 如权利要求12所述的方法，其特征在于，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
  15. 如权利要求12至14中任一项所述的方法，其特征在于，在所述ECU从所述密钥管理装置接收加密的第一密钥之前，所述方法还包括：
    所述ECU向所述密钥管理装置发送第二密钥标识，所述第二密钥标识是基于所述第二密钥计算生成的标识信息，用于KMS确定所述第二密钥。
  16. 如权利要求11至12中任一项所述的方法，其特征在于，所述方法还包括：
    所述ECU向所述密钥管理装置发送状态码，所述状态码用于指示所述ECU接收到的密钥是否被成功写入；其中，所述密钥包括所述第一密钥和/或所述功能密钥。
  17. 如权利要求10至16中任一项所述的方法，其特征在于，所述密钥管理装置为原始设备制造商密钥刷写装置，或，经销商诊断仪。
  18. 一种密钥写入方法，其特征在于，包括：
    密钥管理服务器KMS基于从电子控制单元ECU获取到的第一密钥标识，确定用于加密功能密钥的第一密钥；所述第一密钥标识由所述ECU基于所述第一密钥计算生成，所述第一密钥是所述KMS与所述ECU之间的约定密钥，且所述第一密钥对第三方不可见；
    所述KMS基于所述第一密钥加密所述功能密钥，得到加密的功能密钥；
    所述KMS向密钥管理装置发送加密的功能密钥。
  19. 如权利要求18所述的方法，其特征在于，在所述KMS基于从ECU获取到的第一密钥标识，确定用于加密功能密钥的第一密钥之前，所述方法还包括：
    所述KMS通过所述密钥管理装置向所述ECU发送加密的第一密钥，所述加密的第一密钥是基于第二密钥对第一密钥加密得到。
  20. 如权利要求19所述的方法，其特征在于，在所述KMS向所述密钥管理装置 发送加密的第一密钥之前，所述方法还包括：
    所述KMS从所述ECU获取第二密钥标识，所述第二密钥标识由所述ECU基于所述第二密钥计算生成的标识信息；
    所述KMS基于所述第二密钥标识信息，确定用于加密所述第一密钥的所述第二密钥。
  21. 如权利要求20所述的方法，其特征在于，所述方法还包括：
    所述KMS在基于所述第二密钥标识确定出所述第二密钥的情况下，基于所述第二密钥加密所述第一密钥，以获得加密的第一密钥。
  22. 如权利要求20所述的方法，其特征在于，所述方法还包括：
    所述KMS在基于所述第二密钥标识无法确定出所述第二密钥的情况下，向所述密钥管理装置发送错误提示。
  23. 如权利要求20至22中任一项所述的方法，其特征在于，所述第二密钥是ECU供应商预置在所述ECU中的临时密钥。
  24. 如权利要求20至23中任一项所述的方法，其特征在于，所述第二密钥是所述ECU从所述密钥管理装置获取到的密钥。
  25. 如权利要求18至24中任一项所述的方法，其特征在于，所述密钥管理装置为原始设备制造商密钥刷写装置，或，经销商诊断仪。
  26. 一种密钥写入装置，其特征在于，用于实现如权利要求1至25中任一项所述的方法。
  27. 一种密钥写入装置，其特征在于，包括：
    存储器，用于存储计算机程序；
    处理器，用于调用所述存储器中的计算机程序，以使得所述装置执行权利要求1至25中任一项所述的方法。
  28. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被处理器执行时，使得计算机执行如权利要求1至25中任一项所述的方法。
PCT/CN2020/139146 2020-12-24 2020-12-24 密钥写入方法及装置 WO2022133945A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080004588.1A CN112740212B (zh) 2020-12-24 2020-12-24 密钥写入方法及装置
PCT/CN2020/139146 WO2022133945A1 (zh) 2020-12-24 2020-12-24 密钥写入方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/139146 WO2022133945A1 (zh) 2020-12-24 2020-12-24 密钥写入方法及装置

Publications (1)

Publication Number Publication Date
WO2022133945A1 true WO2022133945A1 (zh) 2022-06-30

Family

ID=75609504

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/139146 WO2022133945A1 (zh) 2020-12-24 2020-12-24 密钥写入方法及装置

Country Status (2)

Country Link
CN (1) CN112740212B (zh)
WO (1) WO2022133945A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113259933B (zh) * 2021-06-15 2023-08-29 北京天融信网络安全技术有限公司 一种密钥更新的方法、网关、控制装置、电子设备及介质
CN117597688A (zh) * 2021-07-23 2024-02-23 华为技术有限公司 一种密钥验证方法及相关装置
CN116628701B (zh) * 2023-05-25 2023-11-24 合芯科技有限公司 Tpcm在位检测方法、装置、服务器启动方法及服务器

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150263856A1 (en) * 2014-03-11 2015-09-17 GM Global Technology Operations LLC Password encryption for controlling access to electronic control units
CN105794146A (zh) * 2014-11-13 2016-07-20 松下电器（美国）知识产权公司 密钥管理方法、车载网络系统以及密钥管理装置
CN108989024A (zh) * 2018-06-29 2018-12-11 百度在线网络技术（北京）有限公司 控制在车辆中电子控制单元间通信的方法、装置、设备、存储介质以及相应车辆

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106658493B (zh) * 2016-10-17 2019-12-06 东软集团股份有限公司 密钥管理方法、装置和系统
CN109728902A (zh) * 2018-06-01 2019-05-07 平安科技（深圳）有限公司 密钥管理方法、设备、存储介质及装置
CN109922084B (zh) * 2019-04-10 2021-08-03 北京阿尔山区块链联盟科技有限公司 密钥管理方法、装置以及电子设备
CN111935317B (zh) * 2020-09-27 2021-01-01 恒大新能源汽车投资控股集团有限公司 车辆信息验证方法及装置、计算机可读存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150263856A1 (en) * 2014-03-11 2015-09-17 GM Global Technology Operations LLC Password encryption for controlling access to electronic control units
CN105794146A (zh) * 2014-11-13 2016-07-20 松下电器（美国）知识产权公司 密钥管理方法、车载网络系统以及密钥管理装置
CN108989024A (zh) * 2018-06-29 2018-12-11 百度在线网络技术（北京）有限公司 控制在车辆中电子控制单元间通信的方法、装置、设备、存储介质以及相应车辆

Also Published As

Publication number Publication date
CN112740212B (zh) 2022-08-09
CN112740212A (zh) 2021-04-30

Similar Documents

Publication Publication Date Title
WO2022133945A1 (zh) 密钥写入方法及装置
JP6197000B2 (ja) システム、車両及びソフトウェア配布処理方法
US10855460B2 (en) In-vehicle computer system, vehicle, key generation device, management method, key generation method, and computer program
CN109257374B (zh) 安全控制方法、装置和计算机设备
CN106572106B (zh) 一种tbox终端和tsp平台之间报文传输的方法
WO2017022821A1 (ja) 管理装置、管理システム、鍵生成装置、鍵生成システム、鍵管理システム、車両、管理方法、鍵生成方法、及びコンピュータプログラム
JP6178390B2 (ja) 管理装置、管理システム、車両、管理方法、及びコンピュータプログラム
EP3276876B1 (en) Management device, vehicle, management method, and computer program
JP6190443B2 (ja) 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
US20170070488A1 (en) Method, apparatus and system for dynamically controlling secure vehicle communication based on ignition
WO2018029905A1 (ja) データ提供システム、データ保安装置、データ提供方法、及びコンピュータプログラム
JP6625293B2 (ja) 鍵管理装置および通信機器
WO2018029893A1 (ja) データ提供システム、データ保安装置、データ提供方法、及びコンピュータプログラム
WO2022151478A1 (zh) 车辆密钥管理方法、设备及其系统
JP6260068B1 (ja) 保守装置、保守方法、及びコンピュータプログラム
JP6440334B2 (ja) システム、車両及びソフトウェア配布処理方法
JP6203798B2 (ja) 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム
WO2023000313A1 (zh) 一种密钥验证方法及相关装置
JP2018050255A (ja) 車両情報収集システム、データ保安装置、車両情報収集方法、及びコンピュータプログラム
JP2018006782A (ja) データ提供システム、データ提供装置、車載コンピュータ、データ提供方法、及びコンピュータプログラム
WO2022227057A1 (zh) 一种密钥更新方法及其相关设备
JP6464466B2 (ja) 保守装置、保守方法、及びコンピュータプログラム
JP6554704B2 (ja) データ提供システム及びデータ提供方法
JP2018057044A (ja) 車両情報収集システム、データ保安装置、車両情報収集装置、車両情報収集方法、及びコンピュータプログラム
WO2017216874A1 (ja) 鍵管理装置、鍵管理プログラムおよび鍵共有方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20966517

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20966517

Country of ref document: EP

Kind code of ref document: A1