WO2025201215A1 - 一种密钥分发、解析方法及装置 - Google Patents

一种密钥分发、解析方法及装置

Info

Publication number
WO2025201215A1
WO2025201215A1 PCT/CN2025/084219 CN2025084219W WO2025201215A1 WO 2025201215 A1 WO2025201215 A1 WO 2025201215A1 CN 2025084219 W CN2025084219 W CN 2025084219W WO 2025201215 A1 WO2025201215 A1 WO 2025201215A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
key
generating
session
public key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/084219
Other languages
English (en)
French (fr)
Inventor
蒋智超
杨艳江
魏卓
张立
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Yinwang Intelligent Technology Co Ltd
Original Assignee
Shenzhen Yinwang Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Yinwang Intelligent Technology Co Ltd filed Critical Shenzhen Yinwang Intelligent Technology Co Ltd
Publication of WO2025201215A1 publication Critical patent/WO2025201215A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves

Definitions

  • the present application relates to the field of secure communications, and in particular to a key distribution and analysis method and device.
  • In-vehicle communication typically refers to communication between in-vehicle components. Because in-vehicle communication security is a crucial component of smart cars and crucial to vehicle safety, in-vehicle components typically communicate via secure channels based on business keys to ensure secure in-vehicle communication. Therefore, each in-vehicle component must have its own business key to enable communication through secure channels based on business keys.
  • keys are derived and distributed off-vehicle and then installed on the production line.
  • This involves deriving business keys for in-vehicle components through a key management system (KMS) deployed off-vehicle, and then installing them into the corresponding components on the production line.
  • KMS key management system
  • the installation process generally involves encrypting the business key using a preset key and sending the encrypted business key to the corresponding in-vehicle component. After receiving the encrypted business key, the component uses the preset key to parse the encrypted business key and obtain the business key.
  • KMS key management system
  • the present application discloses a key distribution and parsing method and device, which greatly reduces the risk of key exposure, improves the security of key distribution, and is conducive to improving the safety of vehicles.
  • the present application provides a key distribution method, which is applied to a generation component, and the method includes: obtaining a first device capability of a first component and sending a first target key to the first component; obtaining a second device capability of a second component and sending a second target key to the second component; wherein the first device capability is used to represent the security characteristics of the first component, and the second device capability is used to represent the security characteristics of the second component, the first target key is generated by encrypting the business key of the first component using a first session key, and the second target key is generated by encrypting the business key of the second component using a second session key, the first device capability corresponds to the first session key, the second device capability corresponds to the second session key, the first device capability is different from the second device capability, and the first session key is different from the second session key.
  • the generating component is a component in which the key management module in the vehicle is located, and/or the first component and the second component are respectively mounted below the generating component.
  • the generating component is, for example, a domain controller, a vehicle integrated unit (VIU), a telematics box (TBox), or an electronic control unit (ECU) in the vehicle.
  • VIP vehicle integrated unit
  • TBox telematics box
  • ECU electronice control unit
  • the domain controller includes a vehicle computing platform (vehicle computing platform) that is an integrated hardware and software platform for supporting intelligent driving, such as a mobile data center (MDC); a cockpit domain controller (CDC) that is an integrated hardware and software platform for providing in-vehicle multimedia services (such as at least one of a head-up display, an instrument panel display, and entertainment audio and video); and a vehicle domain controller (VDC) that is an integrated hardware and software platform for supporting body control and chassis control.
  • vehicle computing platform vehicle computing platform
  • vehicle computing platform that is an integrated hardware and software platform for supporting intelligent driving
  • MDC mobile data center
  • CDC cockpit domain controller
  • VDC vehicle domain controller
  • the generation of the first session key is related to the first device capability, for example, affecting the determination method of the first session key and/or the value of the first session key.
  • the first device capability is different from the second device capability, that is, the security characteristics of the first component are different from the security characteristics of the second component.
  • the generating component, the first component and the second component are disposed within a vehicle.
  • Implementing the above implementation method can improve the security of key distribution in the vehicle, which is beneficial to improving the safety of the vehicle.
  • the method before sending the first target key to the first component, the method further includes: determining a first session key based on the first device capability, the first session key being used to generate secure communication between the component and the first component; generating a business key for the first component; and encrypting the business key of the first component using the first session key to obtain a first target key.
  • the generation component performs the generation of the first session key, the first component's business key, and the first target key. Furthermore, the generation of the first session key takes into account the component's device capabilities, enabling secure distribution of business keys. Furthermore, the derivation and distribution of business keys within the vehicle improves production efficiency compared to the current method of injecting keys into vehicles on the production line.
  • the method before sending the second target key to the second component, the method also includes: determining a second session key based on the second device capability, the second session key being used for secure communication between the generating component and the second component; generating a business key for the second component; and encrypting the business key of the second component using the second session key to obtain a second target key.
  • determining the first session key includes: the first device capabilities include secure storage capabilities, receiving the first public key and identification information of the first component sent by the first component; obtaining the first session key according to the public key of the first component, the hash value of the first component, the public key of the generating component and the private key of the generating component; wherein the public key of the generating component corresponds to the private key of the generating component, the public key of the first component is obtained based on the first public key and the second public key, the second public key is generated by the generating component for the first component, and the hash value of the first component is obtained by performing a hash operation on the identification information of the first component and the public key of the first component.
  • the first device capability also includes at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the first device capability includes secure storage capability, meaning that the first component has secure storage capability.
  • HSM hardware security module
  • a hardware security module also known as a security chip or secure microcontroller, is a hardware component specifically designed to provide security functions and protection mechanisms.
  • the first public key, the second public key, the public key of the first component, and the private key of the first component are associated with parameters of elliptic curve cryptography.
  • the generation component determines the first session key using a certificateless public key protocol.
  • the generation component participates in the generation of the first component's public-private key pair (i.e., the first component's public key and the first component's private key).
  • the generation of the first component's public key utilizes the second public key provided by the generation component for the first component
  • the generation of the first component's private key utilizes the first public key provided by the generation component for the first component. This enables the subsequent local calculation of the first session key by the generation component to be consistent with the local calculation of the first session key by the first component.
  • the generation component and the first component can reach an agreement on the first session key without the need to transmit the first session key, thereby reducing the risk of key exposure.
  • the use of the first session key enables secure communication between the generation component and the first component.
  • the first session key is also associated with the identification information of the first component. Since different components have different identification information, the generation component determines a different session key for each component. This achieves a one-component-one-session key system, improving the security of service key distribution and effectively reducing the risk of key exposure.
  • the method further includes: sending a second public key, a first private key and a public key of a generating component to the first component, wherein the second public key is used to generate the public key of the first component, the first private key is used to generate the private key of the first component, and the public key of the generating component is used by the first component to parse the first target key.
  • the first private key is also associated with parameters of elliptic curve cryptography.
  • the generating component when the first component has secure storage capabilities, the generating component sends the second public key, the first private key, and the public key of the generating component to the first component, which can assist the first component in locally generating the public-private key pair of the first component and also facilitate subsequent decryption by the first component.
  • determining a second session key based on the capabilities of the second device includes: the second device capabilities include secure storage capabilities; receiving a third public key and identification information of the second component sent by the second component; and obtaining the second session key based on the public key of the second component, the hash value of the second component, the public key of the generating component, and the private key of the generating component.
  • the generating component's public key corresponds to the generating component's private key
  • the second component's public key is obtained based on the third public key and a fourth public key
  • the fourth public key is generated by the generating component for the second component
  • the hash value of the second component is obtained by hashing the identification information of the second component and the public key of the second component.
  • the method further includes: sending the fourth public key, the second private key, and the public key of the generating component to the second component, the fourth public key being used for the public key of the second component, the second private key being used to generate the private key of the second component, and the public key of the generating component being used by the second component to resolve the second target key.
  • the generating component is the component where the key management module in the vehicle is located, and determines the first session key based on the first device capability, including: the first device capability does not include secure storage capability, and the first session key is generated according to the identification information and master key of the first component, and the master key is generated by the generating component or comes from the network side device; the business key of the first component is generated, including: the business key of the first component is generated according to the identification information of the first component and the first session key; the method also includes: generating a decryption white box code based on the first session key, the decryption white box code includes the first session key, and the decryption white box code is used to restore the first target key to the business key of the first component; and sending the decryption white box code to the first component.
  • the generating component when the generating component is not the component where the key management module in the vehicle is located, such as the first component does not have a secure storage capability, the generating component generates a first session key based on the business key of the generating component and the identification information of the first component.
  • the first device capability also includes at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the first target key and/or the decryption white box code are carried in an OTA message.
  • generating the decryption white-box code based on the first session key includes: generating the decryption white-box code based on the first session key and a white-box algorithm, where the decryption white-box code is the white-box algorithm mixed with the first session key.
  • “Mixed” here can be understood to mean, for example, that the first session key itself is inserted into the white-box algorithm as a whole, or that the first session key is split into multiple parts and the multiple parts are randomly inserted into the white-box algorithm.
  • the first component when the first component does not have secure storage capabilities, the first session key and the algorithm code are mixed, and the decryption white-box code obtained after the mixing is sent to the first component.
  • the first component does not locally generate the first session key but decrypts it through the decryption white-box code.
  • secure storage of the first session key is achieved through the decryption white-box code, which increases the difficulty for attackers to obtain the first session key. Even if the first component does not have secure storage capabilities, secure storage of the key can be achieved through software.
  • the generation component can also achieve secure storage of the second session key by generating a decryption white box code.
  • this execution process please refer to the description of the execution steps of the generation component when the first device capability does not include secure storage capability. No further details will be given here.
  • determining the first session key based on the first device capability includes: the first device capability includes supporting digital certificates and supporting asymmetric hardware acceleration, and using a digital certificate-based transport layer security TLS protocol to determine the first session key.
  • the generation component includes a first generation component and a second generation component, the first component is suspended under the first generation component, and the second component is suspended under the second generation component, the first generation component is used to obtain the first device capability of the first component and send the first target key to the first component, and the first session key, the business key of the first component and the first target key are generated by the first generation component; the second generation component is used to obtain the second device capability of the second component and send the second target key to the second component, and the second session key, the business key of the second component and the second target key are generated by the second generation component.
  • the present application provides a key parsing method, which is applied to a first component.
  • the method includes: receiving a target key sent by a generating component; parsing the target key based on the device capability of the first component to obtain a business key of the first component; wherein the device capability of the first component is used to represent the security characteristics of the first component, and the target key is a key after the business key of the first component is encrypted by a session key.
  • the generating component is a component where the key management module in the vehicle is located, and/or the first component is hung below the generating component.
  • the generating component please refer to the description of the generating component in the first aspect above, which will not be repeated here.
  • the first component and the generating component are disposed within a vehicle.
  • the first component can also locally determine a session key based on the stored second public key, the first private key, and the public key of the generating component, and the second public key and the first private key are provided by the generating component. If the target key is successfully decrypted using the session key to obtain the business key of the first component, it means that the first component has achieved authenticity verification of the session key without relying on a digital certificate.
  • the method also includes: receiving the public key of the second component and the identification information of the second component sent by the second component; obtaining a negotiated key based on the public key of the second component, the hash value of the second component, the private key of the first component and the public key of the generating component, and the negotiated key is used for secure communication between the first component and the second component; wherein the device capability of the second component includes secure storage capability, the second component is attached to the generating component, and the hash value of the second component is obtained by performing a hash operation based on the public key of the second component and the identification information of the second component.
  • the first component and the second component are not the generators of each other's business keys, if there is a communication need between the first component and the second component, the first component can locally calculate a session key based on the information provided by the second component (for example, the public key of the second component and the identification information of the second component).
  • the session key is used for encryption and decryption of subsequent communications between the first component and the second component. Secure communication between the first component and the second component can be achieved through the session key.
  • the target key is parsed based on the device capability of the first component to obtain the business key of the first component, including: the device capability of the first component does not include secure storage capability, the decryption white box code is locally flashed, the decryption white box code comes from the generation component, and the decryption white box code includes the session key; the target key is parsed using the decryption white box code to obtain the business key of the first component; wherein the business key of the first component is associated with the session key and the identification information of the first component, and the session key is associated with the identification information of the first component.
  • the first component when the first component does not have the secure storage capability, secure storage of the session key is achieved by decrypting the white-box code. Therefore, the first component does not generate the session key locally, but instead decrypts the target key using the decryption white-box code pre-acquired from the generation component to obtain the business key of the first component. This increases the difficulty for an attacker to obtain the session key, and improves the security of the key even if the first component does not have the secure storage capability.
  • the present application provides a key distribution device, which is a generating component, and the device includes: an acquisition unit, used to acquire a first device capability of a first component and a device capability of a second component; a sending unit, used to send a first target key to the first component and a second target key to the second component; wherein the first device capability is used to represent the security characteristics of the first component, and the second device capability is used to represent the security characteristics of the second component, the first target key is generated by encrypting the business key of the first component using a first session key by the processing unit, and the second target key is generated by encrypting the business key of the second component by the processing unit using a second session key, the first device capability corresponds to the first session key, the second device capability corresponds to the second session key, the first device capability is different from the second device capability, and the first session key is different from the second session key.
  • the generating component, the first component and the second component are disposed within a vehicle.
  • the generating component is the component where the key management module in the vehicle is located, and/or the first component and the second component are respectively hung below the generating component.
  • the processing unit is used to: determine a first session key based on the first device capability, the first session key being used for secure communication between the generating component and the first component; generate a business key for the first component; and encrypt the business key of the first component using the first session key to obtain a first target key.
  • the processing unit is used to: determine a second session key based on the second device capability, the second session key is used to generate secure communication between the component and the second component; generate a business key for the second component; use the second session key to encrypt the business key of the second component to obtain a second target key.
  • the processing unit is specifically used to: the first device capability includes secure storage capability, receive the first public key and identification information of the first component sent by the first component; obtain the first session key according to the public key of the first component, the hash value of the first component, the public key of the generating component and the private key of the generating component; wherein the public key of the generating component corresponds to the private key of the generating component, the public key of the first component is obtained by the processing unit based on the first public key and the second public key, the second public key is generated by the generating component for the first component, and the hash value of the first component is obtained by the processing unit performing a hash operation on the identification information of the first component and the public key of the first component.
  • the first device capability includes secure storage capability, receive the first public key and identification information of the first component sent by the first component; obtain the first session key according to the public key of the first component, the hash value of the first component, the public key of the generating component and the private key of the generating component; wherein the public
  • the first public key, the second public key, the public key of the first component, and the private key of the first component are all associated with parameters of elliptic curve cryptography.
  • the sending unit is further used to: send the second public key, the first private key and the public key of the generating component to the first component, the second public key is used to generate the public key of the first component, the first private key is used to generate the private key of the first component, and the public key of the generating component is used by the first component to parse the first target key.
  • the processing unit is specifically configured to: receive the third public key and identification information of the second component sent by the second component, wherein the second device capability includes secure storage capability; obtain the second session key based on the public key of the second component, the hash value of the second component, the public key of the generating component, and the private key of the generating component; wherein the public key of the generating component corresponds to the private key of the generating component, the public key of the second component is obtained by the processing unit based on the third public key and the fourth public key, the fourth public key is generated by the generating component for the second component, and the hash value of the second component is obtained by the processing unit performing a hash operation on the identification information of the second component and the public key of the second component.
  • the method further includes: sending the fourth public key, the second private key, and the public key of the generating component to the second component, wherein the fourth public key is used for the public key of the second component, the second private key is used to generate the private key of the second component, and the public key of the generating component is used by the second component to parse the second target key.
  • the generating component is the component where the key management module in the vehicle is located, and the processing unit is specifically used to: if the first device capability does not include secure storage capability, generate a first session key based on the identification information and the master key of the first component, the master key is generated by the generating component or comes from the network side device; generate a business key of the first component based on the identification information of the first component and the first session key; generate a decryption white box code based on the first session key, the decryption white box code includes the first session key, and the decryption white box code is used to restore the first target key to the business key of the first component; the sending unit is also used to send the decryption white box code to the first component.
  • the generating component includes a first generating component and a second generating component, the first component is suspended under the first generating component, and the second component is suspended under the second generating component
  • the above-mentioned acquisition unit includes a first acquisition unit of the first generating component and a second acquisition unit of the second generating component
  • the above-mentioned sending unit includes a first sending unit of the first generating component and a second sending unit of the second generating component; the first acquisition unit is used to obtain the first device capability of the first component; the first sending unit is used to send the first target key to the first component; the second acquisition unit is used to obtain the second device capability of the second component; the second sending unit is used to send the second target key to the second component;
  • the above-mentioned processing unit includes a first processing unit of the first generating component and a second processing unit of the second generating component, wherein the first session key, the business key of the first component and the first target key are generated by the first processing unit; the second session key, the business key of
  • the present application provides a key parsing device, which is a first component and includes: a receiving unit for receiving a target key sent by a generating component, where the target key is a key obtained by encrypting the business key of the first component with a session key; a processing unit for parsing the target key based on the device capability of the first component to obtain the business key of the first component; wherein the device capability of the first component is used to represent the security characteristics of the first component.
  • the first component and the generating component are disposed within a vehicle.
  • the generating component is a component in which the key management module in the vehicle is located, and/or the first component is hung below the generating component.
  • the processing unit is specifically used to: obtain a session key based on the private key of the first component and the public key of the generating component according to the device capability of the first component including secure storage capability; and obtain a business key of the first component by parsing the target key using the session key; wherein the private key of the first component is obtained based on the first private key and the hash value of the first component, the hash value of the first component is obtained by the processing unit performing a hash operation on the identification information of the first component and the public key of the first component, the public key of the first component is obtained by the processing unit based on the first public key and the second public key, the first public key is generated by the first component, the second public key and the first private key correspond to the first component, the first private key, the second public key and the public key of the generating component come from the generating component, and the first private key is associated with the private key of the first component and the hash value of the first component.
  • the first public key, the second public key, the first private key, the public key of the first component, and the private key of the first component are all associated with parameters of elliptic curve cryptography.
  • the receiving unit is further used to receive the public key of the second component and the identification information of the second component sent by the second component;
  • the processing unit is further used to obtain a negotiated key based on the public key of the second component, the hash value of the second component, the private key of the first component and the public key of the generating component, and the negotiated key is used for secure communication between the first component and the second component; wherein the device capability of the second component includes secure storage capability, the second component is hung under the generating component, and the hash value of the second component is obtained by performing a hash operation by the processing unit based on the public key of the second component and the identification information of the second component.
  • the processing unit is specifically used to: if the device capability of the first component does not include secure storage capability, locally flash the decryption white box code, the decryption white box code comes from the generation component, and the decryption white box code includes the session key; use the decryption white box code to parse the target key to obtain the business key of the first component; wherein the business key of the first component is associated with the session key and the identification information of the first component, and the session key is associated with the identification information of the first component.
  • the present application provides a chip comprising a processor and a memory, wherein the memory is used to store program instructions; the processor calls the program instructions in the memory so that the chip executes the method in the first aspect or any possible implementation of the first aspect.
  • the present application provides an electronic control unit, which includes a processor and a memory, wherein the memory is used to store program instructions; the processor calls the program instructions in the memory so that the electronic control unit executes the method in the second aspect or any possible implementation of the second aspect.
  • the present application provides a key distribution system, which includes a first device and a second device, wherein the first device is used to implement the method in the above-mentioned first aspect or any possible implementation of the first aspect, and the second device is used to implement the method in the above-mentioned second aspect or any possible implementation of the second aspect.
  • the first device is the device of the third aspect or any possible implementation of the third aspect, or the first device is the chip described in the fifth aspect;
  • the second device is the device of the fourth aspect or any possible implementation of the fourth aspect, or the second device is the electronic control unit described in the sixth aspect.
  • the present application provides a vehicle comprising an apparatus as described in the third or fifth aspect above, or an apparatus of any possible implementation of the third or fifth aspect above, or an apparatus as described in the fourth or sixth aspect above, or an apparatus of any possible implementation of the fourth or sixth aspect above, or a key distribution system as described in the seventh aspect.
  • the present application provides a computer-readable storage medium comprising computer instructions, which, when executed by a processor, implement the method of the above-mentioned first aspect or any possible implementation of the first aspect, or implement the method of the above-mentioned second aspect or any possible implementation of the second aspect.
  • the present application provides a computer program product, which, when executed by a processor, implements the method in the above-mentioned first aspect or any possible embodiment of the first aspect, or implements the method in the above-mentioned second aspect or any possible embodiment of the second aspect.
  • the computer program product is a software installation package.
  • FIG1 is a schematic diagram of the architecture of a key management system provided in an embodiment of the present application.
  • FIG2 is a schematic structural diagram of a vehicle provided in an embodiment of the present application.
  • FIG3 is a flow chart of a key distribution method provided in an embodiment of the present application.
  • FIG4 is a flow chart of a method for deriving a service key according to an embodiment of the present application.
  • FIG5 is a flowchart of a method for generating a public and private key pair of a component provided in an embodiment of the present application
  • FIG6 is a schematic structural diagram of a key generation device provided in an embodiment of the present application.
  • FIG7 is a schematic structural diagram of a key parsing device provided in an embodiment of the present application.
  • FIG8 is a schematic structural diagram of a key processing device provided in an embodiment of the present application.
  • the described object is a "level”
  • the ordinal number before the "level” in the "first level” and the “second level” does not limit the priority between the "levels”.
  • the number of described objects is not limited by the prefix and can be one or more. Taking “first device” as an example, the number of "devices" can be one or more.
  • the objects modified by different prefixes can be the same or different. For example, if the described object is a "device,” then the "first device” and the “second device” can be the same device, the same type of device, or different types of devices.
  • the described object is "information”
  • the "first information” and the “second information” can be information of the same content or information of different contents.
  • the use of prefixes to distinguish the described objects in the embodiments of this application does not constitute a limitation on the described objects.
  • the description of the described objects please refer to the description in the context of the claims or embodiments, and the use of such prefixes should not constitute an unnecessary limitation.
  • the descriptions used in the embodiments of the present application include any one of a1, a2, ..., and an existing alone, and any combination of any multiple of a1, a2, ..., and an, each of which can exist alone.
  • the description "at least one of a, b, and c" includes a alone, b alone, c alone, a combination of a and b, a combination of a and c, a combination of b and c, or a combination of ab and c.
  • a hardware security module is a dedicated hardware device used to protect and manage sensitive data, session keys, and perform cryptographic operations.
  • EVITA E-safety vehicle intrusion protected applications
  • EVITA categorizes HSMs into three levels: EVITA full HSM, EVITA medium HSM, and EVITA light HSM (or EVITA small HSM).
  • the EVITA full HSM is used for V2X communication
  • the EVITA medium HSM is used for communication between on-board electronic control units (ECUs)
  • the EVITA light HSM is used for communication between on-board sensors and actuators.
  • Certificateless public key cryptography is a cryptographic scheme designed to address some of the certificate management issues in traditional public key infrastructure (PKI).
  • PKI public key infrastructure
  • CA trusted certificate authority
  • CL-PKC enables communicating parties to establish secure communications through negotiation, information exchange, and verification without relying on digital certificates issued by traditional certificate authorities.
  • Key derivation is the process of deriving additional keys from one or more initial keys, also known as master keys.
  • Key derivation is usually achieved by using a derivation function or key derivation function (KDF).
  • KDF key derivation function
  • Examples of key derivation functions include PBKDF2, HKDF, scrypt, Argon2, etc.
  • an embodiment of the present application provides a key management system that can determine a session key for each component in the vehicle, and use the session key corresponding to the component to ensure that the business key of the component is securely transmitted to the corresponding component.
  • the generation of the session key is related to the device capabilities of the component.
  • the device capabilities of the component are used to describe the security characteristics of the device. Different device capabilities of the component have different corresponding session keys. In this way, all components in the vehicle no longer share a single session key.
  • the business keys of different components are encrypted and transmitted using different session keys, which helps to reduce the risk of key exposure and improve the security of key transmission.
  • the key management system includes a terminal 10 and a network-side device 20, wherein the terminal 10 and the network-side device 20 communicate with each other wirelessly.
  • Terminal 10 is, for example, an intelligent terminal or IoT device with key management requirements, such as a vehicle, robot, drone, ship, or boat.
  • Vehicles are broadly defined and can include transportation vehicles (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as mowers, harvesters, etc.), and the like.
  • a robot can be an automated guided vehicle (AGV), a walking conversational robot, a service robot, or other such robot. It is understood that all terminals involved in secure communication between internal components belong to terminal 10.
  • AGV automated guided vehicle
  • the vehicle can be an autonomous vehicle or a non-autonomous vehicle.
  • autonomous driving is not limited to fully autonomous driving, highly autonomous driving, conditionally autonomous driving, or partially autonomous driving.
  • any non-fully manual driving that provides intelligent driving can be covered by this concept.
  • the embodiments of this application do not limit the vehicle's power source, such as a new energy vehicle or a traditional fuel vehicle.
  • the network-side device 20 may be a computing device or a computing device cluster, where computing devices include bare metal servers (BMSs), virtual machines, containers, or edge computing devices.
  • BMS bare metal servers
  • a BMS refers to a general-purpose physical server, such as an ARM server or an X86 server.
  • a virtual machine refers to a complete computer system with complete hardware system functionality, running in a completely isolated environment, simulated by software. Any work that can be performed on a physical computer can also be performed on a virtual machine. When creating a virtual machine on a computing device, part of the physical machine's hard disk and memory capacity is used as the virtual machine's hard disk and memory capacity.
  • Each virtual machine has an independent basic input/output system (BIOS), hard disk, and operating system, allowing it to be operated like a physical machine.
  • BIOS basic input/output system
  • a container is virtualization software that combines an application and all its dependencies into a single software package. This package is not restricted by the underlying host operating system, eliminating the need to build a complex environment and simplifying the process from application development to deployment.
  • Edge computing devices refer to devices that are closer to data sources and end users and have low latency and high bandwidth characteristics, such as smart routers and edge servers.
  • a computing device cluster may include multiple of the above-mentioned computing devices, such as a data center, but this application does not provide specific limitations.
  • the network-side device 20 can be deployed in a cloud environment or an edge environment.
  • the network-side device 20 can be an integrated device or multiple distributed devices, without specific limitation.
  • the network-side device 20 can also be a component in a computing device, such as a chip or integrated circuit.
  • a key management system is deployed on the terminal 10, and a key management system is also deployed on the network-side device 20.
  • the key management system also known as a cryptographic key management system (CKMS)
  • CKMS cryptographic key management system
  • the key management system deployed on the terminal 10 is also known as a key management module (KeyM).
  • KeyM key management module
  • the KeyM on the terminal 10 is responsible for generating and distributing relevant keys for various components within the vehicle, while the KMS on the network-side device 20 assists the KeyM on the terminal 10 in generating relevant keys.
  • Figure 1 above is only an exemplary architecture diagram of a key management system and does not limit the key management system to that shown in Figure 1.
  • the generation of the relevant keys for the various components of terminal 10 does not require the participation of network-side device 20.
  • the key management system shown in Figure 1 may also not include network-side device 20.
  • Figure 2 is a schematic diagram of the structure of a vehicle provided in an embodiment of the present application.
  • the vehicle's internal components include at least one domain controller (DC), at least one vehicle integrated unit (VIU), an electronic control unit (ECU), and a telematics box (TBox).
  • DC domain controller
  • VIU vehicle integrated unit
  • ECU electronice control unit
  • TBox telematics box
  • the TBOX communicates with the VIU and/or DC via Ethernet, for example, to transmit information or commands, including vehicle status information, key status information, and control commands.
  • the VIU manages the electronic control units (ECUs) within its area. It provides close access to the corresponding sensors, actuators, or ECUs, enabling power supply, electronic fuses, I/O port isolation, and other functions.
  • the VIU also performs some or all of the functions of a gateway, such as protocol conversion, protocol encapsulation and forwarding, and data format conversion.
  • the VIU integrates the ECU functions of certain vehicle components, it also provides electronic control capabilities to control those components.
  • At least one VIU includes VIU0, VIU1, VIU2, and VIU3.
  • the key management module KeyM is deployed only on VIU0. In some possible embodiments, there is no limit on the number of KeyMs deployed within the vehicle. KeyMs can be deployed, for example, on VIUs, DCs, or other certificate-capable devices within the vehicle. As an example, VIU0, VIU1, VIU2, and VIU3 are each deployed with a KeyM.
  • a domain controller can be understood as a general term for a system that includes domain master hardware, operating systems, algorithms, and application software.
  • at least one DC includes a vehicle computing platform (vehicle computing platform), an integrated hardware and software platform for supporting intelligent driving, such as a mobile data center (MDC); and a cockpit domain controller (CDC), an integrated hardware and software platform for providing in-vehicle multimedia services (such as at least one of a head-up display, instrument panel display, and entertainment and video).
  • MDC mobile data center
  • CDC cockpit domain controller
  • an integrated hardware and software platform for providing in-vehicle multimedia services such as at least one of a head-up display, instrument panel display, and entertainment and video.
  • at least one DC also includes an integrated hardware and software platform for supporting body and chassis control, such as a vehicle domain controller (VDC).
  • the MDC may also be referred to as an advanced driving assistance system domain controller (ADASDC) or an automatic drive domain controller (ADDC).
  • ADASDC advanced driving assistance system domain controller
  • MDC is used to provide services for vehicle components that realize autonomous driving functions.
  • Vehicle components that realize autonomous driving functions include monocular cameras, binocular cameras, millimeter-wave radars, lidars, ultrasonic radars, etc.
  • CDC is used to provide services for vehicle components within the cockpit domain, including head-up display (HUD), instrument display, radio, navigation, camera, etc.
  • HUD head-up display
  • instrument display radio
  • navigation camera
  • camera etc.
  • a digital certificate is a security tool used to verify the identities of both parties communicating on a network. It's typically based on the Public Key Infrastructure (PKI) framework, such as the SSL/TLS certificates used for authentication. Devices that support digital certificates are those equipped with the necessary functionality and security protocols to process, verify, and generate digital certificates.
  • PKI Public Key Infrastructure
  • the second category of components also includes an intelligent key module (IKM), a microcontroller unit (MCU) and a battery management system (BMS).
  • IKM intelligent key module
  • MCU microcontroller unit
  • BMS battery management system
  • the device capabilities of the third category components do not include secure storage capabilities. In some possible embodiments, the device capabilities of the third category components further satisfy at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the third category of components includes sensor components without secure storage capabilities.
  • sensor components are primarily used to collect data such as vehicle operating status and environmental information to support the vehicle's control, monitoring, and decision-making systems.
  • sensor components include global positioning systems (GPS), inertial measurement units (IMUs), vehicle speed sensors, steering angle sensors, lidars, cameras, ultrasonic sensors, atmospheric pressure sensors, temperature sensors, and other sensor components used to provide vehicle status and surrounding environment data.
  • the terminal 10 below is described using a vehicle as an example, but the embodiment of the present application does not limit the terminal 10 to being only a vehicle.
  • FIG 3 is a flowchart of a key distribution method provided in an embodiment of the present application. This method is applied to a communication system consisting of a generation component and a first component, wherein the generation component is both the generator and sender of the service key for the first component. Both the generation component and the first component are deployed on the terminal 10 in Figure 1 or the vehicle shown in Figure 2.
  • the method shown in the embodiment of FIG. 3 includes but is not limited to the following steps S301 - S305 .
  • the generating component generates a service key of the first component.
  • the first type centralized derivation
  • Centralized derivation means that a key management module (KeyM) within the vehicle is responsible for deriving the business keys for each component within the vehicle.
  • Centralized derivation generates business keys for the entire vehicle, with a single key management module responsible for generating business keys. This centralized management of business keys reduces deployment costs and facilitates maintenance.
  • KeyM key management module
  • Figure 4 is a flow chart of a business key derivation method provided in an embodiment of the present application. The method is applied to a communication system consisting of a generation component, a first component, and a network-side device, wherein the generation component is the component where the key management module KeyM is located, and the first component is any component in the vehicle that requires a business key.
  • the network-side device is, for example, the network-side device 20 in Figure 1 above, and the vehicle is an example of the terminal 10 in Figure 1.
  • the generation component and the first component are both deployed inside the vehicle, while the network-side device is deployed outside the vehicle.
  • the generation component is VIU0 in Figure 2
  • the first component can be any of the in-vehicle components shown in Figure 2 .
  • the component's service key derivation occurs inside the vehicle.
  • the embodiment shown in FIG. 4 includes but is not limited to the following steps S401 - S403 .
  • the generating component obtains the master key from the network side device.
  • the generation component obtains the master key from the network side device, including: after the vehicle is assembled and powered on, the KeyM in the generation component triggers the key derivation process, and the KeyM sends a first request to the network side device, and the first request is used to request to obtain the master key; in response to the first request, the network side device sends the master key to the generation component, so that the KeyM in the generation component obtains the master key.
  • the master key is provided by a user of the network-side device or generated by a key management system KMS deployed on the network-side device.
  • the network-side device can use encryption to securely transmit the master key to the generation component.
  • the generating component obtains identification information of the first component from the first component.
  • the identification information of the first component is used to identify the first component, and the identification information of the first component is, for example, the component serial number of the first component, the component ID of the first component, or the IP address of the first component.
  • the generating component obtains identification information of the first component from the first component, including: KeyM in the generating component sends identification request information to the first component; in response to the identification request information, the first component sends the identification information of the first component to the generating component, so that KeyM in the generating component obtains the identification information of the first component.
  • the generating component pre-stores the identification information of the first component, and the KeyM in the generating component directly obtains the identification information of the first component locally.
  • the generating component generates a service key of the first component based on the master key and the identification information of the first component.
  • a generation component generates a business key for the first component based on a master key and identification information of the first component, including: KeyM in the generation component uses the master key and the identification information of the first component as inputs to a key derivation function to obtain the business key of the first component, wherein the business key of the first component is a result output by the key derivation function based on the master key and the identification information of the first component.
  • KEY x KDF(MK, ID_ECU x
  • KEY x represents the service key of the first component, which can be any component within the vehicle.
  • KDF() represents a key derivation function
  • MK represents a master key
  • ID_ECU x represents identification information of the first component.
  • Salt_ECU x is, for example, a 256-bit number
  • Salt_ECU x increments by 1 each time the service key of the first component is updated.
  • the above formula (1) is only an example; the service key of the first component can also be generated using a modified formula based on formula (1).
  • S401 may not be executed, and the master key is locally generated by KeyM in the generating component.
  • the master key is generated by KeyM on VIU0 or comes from a network-side device.
  • This master key comes from the network-side device, allowing it to centrally manage the vehicle's master keys.
  • Each vehicle has a corresponding master key.
  • vehicle B can use vehicle A's master key to request the network-side device to verify the legitimacy of vehicle A.
  • the master key is generated locally by KeyM and never leaves the vehicle, reducing the risk of key exposure.
  • the KeyM on VIU0 generating a service key for the TBox based on the master key includes: KeyM on VIU0 generating the service key for the TBox based on the master key and the identification information of the TBox. This implementation method is described in the above-mentioned S403 and will not be repeated here.
  • Step 2 VIUx, TBox, CDC, and MDC derive service keys for their own components that are not configured with service keys.
  • MDC generates the business key of ECU001 based on the business key of MDC and the identification information of ECU001.
  • Step 1 and Step 2 above when a distributed derivation method is adopted, if the generating component is the component where KeyM is located, the generating component generates the business key of the first component based on the master key and the identification information of the first component; if the generating component is not the component where KeyM is located, the generating component generates the business key of the first component based on the business key of the generating component and the identification information of the first component.
  • each KeyM in the vehicle first generates a business key for the components on the Ethernet ring, and then the components on the Ethernet ring generate business keys for the components hanging below it. In this way, each component in the vehicle has a business key.
  • the first component is attached to the generating component.
  • the first component includes the components attached to CDC; for another example, if the generating component is VIU1, the first component includes the components attached to VIU1 (i.e., ECU11, ECU12, and ECU13); for another example, if the generating component is VIU0, the first component includes the components attached to VIU0 (including ECU11, ECU12, and ECU13).
  • the generating component and the first component may be in other forms as shown in Figure 2.
  • the device capability of the generation component must be no less than that of the first component. For example, if the generation component belongs to the first category, then the first component belongs to the first, second, or third category; if the generation component belongs to the second category, then the first component belongs to the second or third category.
  • the device capability of the first component is not distinguished.
  • the generation component when the device capability of the first component does not include secure storage capability (i.e., the first component belongs to the aforementioned third category of components), the generation component generates a business key for the first component, including: the generation component generates a root key based on the pre-key and the identification information of the first component; the generation component generates the business key for the first component based on the root key and the identification information of the first component.
  • the pre-key is the master key
  • the pre-key is the business key of the generating component.
  • the master key can be referred to the description of the corresponding content above.
  • the generating component uses a first key derivation algorithm to generate the root key, and uses a second key derivation algorithm to generate the service key of the first component.
  • the first key derivation algorithm and the second key derivation algorithm may be the same or different.
  • the business key generation is completed in the vehicle.
  • the embodiment of the present application realizes that the vehicle key does not leave the vehicle, which is conducive to reducing the risk of key exposure.
  • the generating component determines a first session key based on the device capability of the first component.
  • the device capability of the first component further satisfies at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the first public key, the second public key, the public key of the generating component, and the private key of the generating component are obtained through elliptic curve cryptography.
  • the generating component also sends the above-mentioned second public key, the first private key and the public key of the generating component to the first component, wherein the second public key is used to generate the public key of the first component, the first private key is used to generate the private key of the first component, and the public key of the generating component is used by the first component to parse and obtain the business key of the first component.
  • this example illustrates the scenario where the generating component is the component where KeyM resides and the first component is ECU i .
  • the generating component is the generator of the service key for the first component.
  • the process of determining the first session key used for secure communication between KeyM and ECU i consists of two phases: Phase 1 and Phase 2, described below.
  • Phase 1 KeyM must first assist ECU i in generating the public and private key pair of ECU i
  • the public-private key pair of ECU i includes the public key of ECU i and the private key of ECU i .
  • Figure 5 is a flowchart of a method for generating a public-private key pair for a component provided in an embodiment of the present application.
  • the method for generating the public-private key pair for ECU i shown in Figure 5 is applied to KeyM and ECU i , and includes but is not limited to the following steps S501-S505.
  • ECU i and KeyM pre-negotiate to use elliptic curve cryptography to uniformly configure system parameters locally.
  • the system parameters include Among them, ⁇ represents the elliptic curve group, n is a prime number, G is the n-order base point of the elliptic curve, and the elliptic curve
  • H() represents a hash function. H() is configured as The use of elliptic curve cryptography for system parameter configuration is conducive to lightweight implementation of public key authenticity verification and can reduce the consumption of computing power during key generation.
  • ECU i after ECU i locally executes the above system parameter configuration, ECU i generates a first public key using the following formula (2).
  • X i x i G formula (2)
  • Xi represents the first public key of ECU i
  • Xi is a random number.
  • the parameter G can be referred to in the above description and will not be described in detail here.
  • Formula (2) is only an example of how ECU i generates the first public key and does not limit the method by which ECU i generates the first public key.
  • ECU i sends the first public key and identification information of ECU i to KeyM.
  • the identification information of ECU i is used to identify ECU i .
  • the identification information of ECU i is, for example, a component serial number of ECU i , a component ID of ECU i , or an IP address of ECU i .
  • KeyM receives the first public key from ECU i and the identification information of ECU i .
  • S503 KeyM generates a second public key and a first private key for ECU i .
  • KeyM After KeyM locally executes the above system parameter configuration, KeyM first generates KeyM's private key and KeyM's public key, for example, KeyM's private key
  • KeyM after KeyM locally executes the above system parameter configuration, KeyM generates the second public key using the following formula (3).
  • P i r i G Formula (3)
  • Pi represents the second public key of ECU i
  • ri is a random number
  • the parameter G can be referred to in the above description and will not be described here in detail.
  • Formula (3) is only an example of how KeyM generates the second public key for ECU i and does not limit the method by which KeyM generates the second public key.
  • KeyM generates a first private key for ECU i , including: KeyM obtains the public key of ECU i based on the first public key of ECU i and the second public key of ECU i ; KeyM obtains a hash value of ECU i based on the public key of ECU i and identification information of ECU i ; KeyM obtains the first private key of ECU i based on the private key of KeyM and the hash value of ECU i .
  • the public key of ECU i is obtained based on the first public key of ECU i and the second public key of ECU i , which means that: the public key of ECU i is the sum of the first public key of ECU i and the second public key of ECU i, or, the public key of ECU i is obtained by concatenating the first public key of ECU i and the second public key of ECU i .
  • PKi represents the public key of ECU i
  • Xi represents the first public key of ECU i
  • Pi represents the second public key of ECU i
  • hi represents the hash value of ECU i
  • IDi represents the identification information of ECU i
  • Pi represents the first private key of ECU i
  • skKM represents the private key of KeyM
  • H(), r i , and n are described above and are not repeated here.
  • Formula (4) is only an example of how KeyM generates the first public key of ECU i for ECU i and does not limit the method by which KeyM generates the first private key.
  • KeyM sends the second public key, the first private key and the public key of KeyM to ECU i .
  • KeyM generates a public key of ECU i based on the second public key generated by itself and the first public key from ECU i , and locally stores the correspondence between the public key of ECU i and the identification information of ECU i .
  • ECU i generates a public key of ECU i according to the first public key and the second public key, and generates a private key of ECU i according to the first private key.
  • the public key of ECU i is obtained based on the first public key of ECU i and the second public key of ECU i , which means that: the public key of ECU i is the sum of the first public key of ECU i and the second public key of ECU i, or, the public key of ECU i is obtained by concatenating the first public key of ECU i and the second public key of ECU i .
  • ECU i generates a private key of ECU i based on the first private key, including: ECU i obtains a hash value of ECU i based on identification information of ECU i and a public key of ECU i ; and ECU i obtains the private key of ECU i based on the first private key and the hash value of ECU i .
  • the hash algorithm used by ECU i to obtain the hash value of ECU i is the same as the hash algorithm used by KeyM to obtain the hash value of ECU i .
  • the hash algorithm is, for example, the above-mentioned H().
  • ECU i generates the private key of ECU i through the following formula (5).
  • PKi represents the public key of ECU i
  • Xi represents the first public key of ECU i
  • Pi represents the second public key of ECU i
  • hi represents the hash value of ECU i
  • IDi represents the identification information of ECU i
  • si represents the private key of ECU i
  • Pi represents the first private key of ECU i .
  • Formula (5) is only an example of how ECU i generates the private key of ECU i and does not limit the method by which ECU i generates the private key.
  • ECU i locally stores the public and private key pair of ECU i , namely (PK i , s i ) mentioned above.
  • KeyM participates in the generation of ECU i 's public-private key pair.
  • ECU i uses the second public key provided by KeyM to generate its public key, and the first private key provided by KeyM to generate its private key.
  • KeyM's participation in the generation of ECU i 's public-private key pair enhances the security and trustworthiness of communication between the two parties.
  • Phase 2 KeyM and ECU i each determine the first session key locally
  • KeyM locally determines the first session key, including: KeyM obtains the first session key according to the private key of KeyM, the public key of KeyM, the hash value of ECU i , and the public key of ECU i .
  • the public key of ECU i is based on the first public key of ECU i and the second public key of ECU i
  • the hash value of ECU i is obtained based on the public key of ECU i and the identification information of ECU i .
  • the first public key of ECU i and the identification information of ECU i both come from ECU i
  • the second public key of ECU i is KeyM generated for ECU i .
  • KeyM determines the first session key by the following formula (6).
  • K Mi is the first session key determined by KeyM for secure communication with ECU i
  • sk KM is the private key of KeyM
  • PK KM is the public key of KeyM
  • hi is the hash value of ECU i
  • PK i is the public key of ECU i .
  • ECU i locally determines the first session key, including: ECU i obtains the first session key according to the private key of ECU i and the public key of KeyM, wherein the public key of KeyM comes from KeyM.
  • ECU i determines the first session key by the following formula (7).
  • K iM s i PK KM formula (7)
  • K iM is the first session key determined by ECU i for secure communication with KeyM
  • s i is the private key of ECU i
  • PK KM is the public key of KeyM.
  • the above formulas (6) and (7) are only used as an example for KeyM and ECU i to determine the first session key for communication between KeyM and ECU i .
  • the first session key for communication between KeyM and ECU i can also be determined by using modified formulas (6) and (7). No matter how formulas (6) and (7) are modified, K Mi calculated locally by KeyM is equal to K iM calculated locally by ECU i .
  • KeyM does not need to transmit the first session key to ECU i .
  • ECU i can generate the first session key locally based on the information obtained from KeyM (i.e. the above-mentioned second public key, the first private key and the public key of KeyM), and the first session key determined by KeyM is the same as the first session key determined locally by ECU i .
  • KeyM and ECU i have completed the negotiation on the first session key.
  • the first session key is used for encryption and decryption of subsequent communications between KeyM and ECU i , so that secure communication between KeyM and ECU i can be achieved through the first session key.
  • KeyM is the generator of both ECU_A's and ECU_B's service keys.
  • ECU_A and ECU_B are not the generators of the corresponding service keys.
  • ECU_A and ECU_B need to communicate, they must also negotiate a first session key.
  • This first session key is used for secure communication between ECU_A and ECU_B. The process for ECU_A and ECU_B to negotiate the first session key is described in steps B11-B14 below.
  • ECU_A sends ECU_A's public key and ECU_A's identification information to ECU_B.
  • the public key of ECU_A is generated by ECU_A using the method shown in the embodiment of Figure 5. Please refer to the description of the identification information of ECU i above for the identification information of ECU_A, which will not be repeated here.
  • h A is the hash value of ECU_A
  • ID A is the identification information of ECU_A
  • PK A is the public key of ECU_A
  • K BA is the first session key determined by ECU_B for secure communication with ECU_A
  • s B is the private key of ECU_B
  • PK LM is the public key of KeyM.
  • the generator of the business key of ECU_A and the generator of the business key of ECU_B may also be different.
  • the business key of ECU_A is generated by generating component 1
  • the business key of ECU_B is generated by generating component 2.
  • ECU_A and ECU_B may also locally negotiate the session key through the methods shown in B11-B14 above.
  • the device capability of the first component does not have the secure storage capability. Further, the device capability of the first component also satisfies at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the generating component determines the first session key based on the device capability of the first component, including: the generating component uses the master key as the first session key.
  • the generation component also generates a decryption white-box code based on the first session key, and the generation component sends the decryption white-box code to the first component, wherein the decryption white-box code includes the first session key, and the decryption white-box code is used by the first component to parse and obtain the business key of the first component.
  • generating the decryption white-box code based on the first session key includes: generating the decryption white-box code based on the first session key and a white-box algorithm, where the decryption white-box code is the white-box algorithm mixed with the first session key.
  • “Mixed” here can be understood to mean, for example, that the first session key itself is inserted into the white-box algorithm as a whole, or that the first session key is split into multiple parts and randomly inserted into the white-box algorithm.
  • the mixing method may be, for example, mixing the first session key and the white-box algorithm using internal obfuscation technology, or mixing the first session key and the execution process of the white-box algorithm using algebraic technology and transformation, etc., which are not specifically limited here.
  • the white-box algorithm may be, for example, a dynamic white-box algorithm or a static white-box algorithm.
  • the first session key and the algorithm code are obfuscated, and the decrypted white-box code obtained after the obfuscation is sent to the first component.
  • the first component does not generate the first session key locally but decrypts it through the decryption white-box code.
  • the decryption white-box code achieves secure storage of the first session key, thereby increasing the difficulty for an attacker to obtain the first session key. Even if the first component does not have a secure storage capability, the security of the key is improved.
  • the generating component sends the decrypted white box code to the first component via the OTA upgrade channel.
  • the decrypted white box code is carried in the OTA message.
  • S303 The generating component encrypts the service key of the first component using the first session key to obtain a first target key.
  • the first session key is used to encrypt the service key of the first component, thereby protecting the privacy and integrity of the service key.
  • the first session key helps to achieve the secure distribution of the service key of the first component, thereby improving the security of the key.
  • the first component parses the first target key based on the device capability of the first component to obtain the service key of the first component.
  • the device capabilities of the first component include support for digital certificates and support for asymmetric hardware acceleration (i.e., the first component belongs to the first category of components described above).
  • the first component parses a first target key based on the device capabilities of the first component to obtain the first component's service key, including: the first component decrypts the first target key using a local first session key to obtain the first component's service key.
  • the first session key local to the first component is, for example, the pre-master key described in "Case 1" in S402 above.
  • the device capabilities of the first component include secure storage capabilities (i.e., the first component belongs to the second category of components described above).
  • the first component based on the device capabilities of the first component, resolves the first target key to obtain the first component's service key, including: obtaining the first session key by the first component using the first component's private key and the generating component's public key; and decrypting the first target key using the first session key to obtain the first component's service key.
  • the device capabilities of the first component also satisfy at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the private key of the first component is obtained based on the first private key and the hash value of the first component.
  • the hash value of the first component is obtained by performing a hash operation on the identification information of the first component and the public key of the first component.
  • the public key of the first component is obtained based on the first public key and the second public key.
  • the first public key is generated by the first component.
  • the second public key and the first private key correspond to the first component.
  • the first private key, the second public key, and the public key of the generating component are derived from the generating component.
  • the first private key is associated with the private key of the generating component and the hash value of the first component.
  • the generation of the public-private key pair of the first component i.e., the public key of the first component and the private key of the first component
  • FIG. 5 the relevant description of the embodiment of FIG. 5 , which will not be repeated here.
  • the device capabilities of the first component do not include secure storage capabilities (i.e., the first component belongs to the third category of components described above).
  • the first component also receives decryption white-box code from the generation component.
  • the first component based on the device capabilities of the first component, parses the first target key to obtain the first component's business key, including: locally flashing the decryption white-box code; and using the decryption white-box code to parse the first target key to obtain the first component's business key.
  • the device capabilities of the first component also satisfy at least one of not supporting digital certificates and not supporting asymmetric hardware acceleration.
  • the decrypted white-box code is associated with the first session key, which is associated with the identification information of the first component.
  • the business key of the first component is associated with the first session key and the identification information of the first component.
  • the above embodiment shows the process of the generation component generating the service key of the first component and the generation component securely distributing the service key of the first component.
  • the generation component can be responsible for the generation and secure distribution of service keys of multiple components.
  • the generation component generates a business key for the second component; the generation component determines a second session key based on the device capabilities of the second component; the generation component encrypts the business key of the second component using the second session key to obtain a second target key; and the generation component sends the second target key to the second component.
  • the second component receives the second target key and parses the second target key based on the device capabilities of the second component to obtain the business key of the second component.
  • the generation process of the business key of the second component refers to the description of the generation process of the business key of the first component
  • the generation process of the second session key refers to the description of the generation process of the first session key, and will not be repeated here.
  • the generator of the component's business key can determine a session key for each component of the vehicle, and use the session key corresponding to the component to encrypt and transmit the component's business key to the corresponding component.
  • the generator determines the session key based on the component's device capabilities.
  • the component's device capabilities are used to describe the security characteristics of the device, which is beneficial to improving the security of key distribution.
  • the device capabilities of the components are different, and the session keys corresponding to the components are different. Compared with the current production line key filling process, all components in the vehicle no longer share a session key.
  • the business keys of different components are encrypted and transmitted using different session keys, which is beneficial to reducing the risk of key exposure and improving the security of key transmission.
  • the generation of the component's business key and the generation of the session key are both performed in the vehicle, so that the key does not leave the vehicle, which is also beneficial to improving the efficiency of key distribution in the vehicle.
  • the sending unit 314 is further configured to send a second target key to the second component, where the second target key is generated by encrypting the second component's service key using the second session key by the processing unit 312, and the second session key corresponds to the second device capability.
  • the first device capability is different from the second device capability
  • the first session key is different from the second session key.
  • the key generation device 30 is also used to implement the method on the generation component side described in the embodiment of Figure 4 and the method on the KeyM side described in the embodiment of Figure 5. For the sake of brevity of the description, they are not repeated here.
  • the key parsing device 40 includes a receiving unit 410 and a processing unit 412.
  • the key parsing device 40 can be implemented by hardware, software, or a combination of hardware and software.
  • the receiving unit 410 is configured to receive a target key sent by the generating component, where the target key is a key obtained by encrypting the business key of the first component with the session key; the processing unit 412 is configured to parse the target key based on the device capability of the first component to obtain the business key of the first component; wherein the device capability of the first component is used to indicate the security characteristics of the first component.
  • the key parsing device 40 is also used to implement the method on the first component side described in the embodiment of Figure 4 and the method on the ECU i side described in the embodiment of Figure 5. For the sake of brevity of the specification, they are not repeated here.
  • the process of the processor loading a configuration document to implement the hardware circuit configuration may be understood as the process of the processor loading instructions to implement the functions of some or all of the above units.
  • it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.
  • NPU neural network processing unit
  • TPU tensor processing unit
  • DPU deep learning processing unit
  • the various units in the above devices can be fully or partially integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a system-on-a-chip (SOC).
  • SOC may include at least one processor for implementing any of the above methods or implementing the functions of the various units of the device.
  • the type of the at least one processor can be different, for example, including a CPU and FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.
  • the key processing device 50 includes a processor 501, a communication interface 502, a memory 503, and a bus 504.
  • the processor 501, the memory 503, and the communication interface 502 communicate with each other via the bus 504. It should be understood that this application does not limit the number of processors and memories in the key processing device 50.
  • the key processing device 50 is a network-side device, such as a computing device, a computing device cluster, or a terminal device.
  • the network-side device can be deployed in a cloud environment or an edge environment.
  • details about the network-side device please refer to the description of the network-side device 20 in Figure 1 and will not be repeated here.
  • the key processing device 50 is a terminal or a component within a terminal.
  • the component within the vehicle may be, for example, a domain controller (DC), a vehicle integrated circuit (VIU), an electronic control unit (ECU), or a telematics processor (TBox).
  • DC domain controller
  • VIU vehicle integrated circuit
  • ECU electronice control unit
  • TBox telematics processor
  • the key processing device 50 may also be a component within the component, such as a chip or integrated circuit.
  • the terminal 10 in Figure 1 please refer to the description of terminal 10 in Figure 1 and will not be repeated here.
  • Bus 504 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, or control buses. For ease of illustration, FIG8 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 504 may include a path for transmitting information between various components of key processing device 50 (e.g., memory 503, processor 501, and communication interface 502).
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • the processor 501 can refer to the relevant description of the processor in the above embodiment, which will not be repeated here.
  • Memory 503 is used to provide storage space for storing data such as the operating system and computer programs.
  • Memory 503 can be one or a combination of random access memory (RAM), erasable programmable read-only memory (EPROM), read-only memory (ROM), or compact disc read-only memory (CD-ROM).
  • RAM random access memory
  • EPROM erasable programmable read-only memory
  • ROM read-only memory
  • CD-ROM compact disc read-only memory
  • the communication interface 502 can be used to provide information input or output for the processor 501.
  • the communication interface 502 can be used to receive data transmitted externally and/or transmit data externally. It can be a wired link interface such as an Ethernet cable, or a wireless link interface (such as Wi-Fi, Bluetooth, general wireless transmission, etc.).
  • the communication interface 502 can also include a transmitter (such as a radio frequency transmitter, antenna, etc.) or a receiver coupled to the interface.
  • the processor 501 in the key processing device 50 is used to read the computer program stored in the memory 503 to execute the aforementioned method, such as the method described in any one of FIG. 3 , FIG. 4 or FIG. 5 .
  • the key processing device 50 may be one or more modules in an execution entity (e.g., a generation component) that executes the method shown in FIG. 3 .
  • the processor 501 may be configured to read one or more computer programs stored in a memory to perform the following operations:
  • the key processing device 50 may be one or more modules in an execution entity (e.g., the first component) that executes the method shown in FIG. 3 .
  • the processor 501 may be configured to read one or more computer programs stored in a memory to perform the following operations:
  • the target key is a key obtained by encrypting the service key of the first component with the session key;
  • the target key is parsed based on the device capability of the first component to obtain the service key of the first component; wherein the device capability of the first component is used to represent the security characteristics of the first component.
  • the technical solution of the present application may essentially or contribute to the part or all or part of the technical solution in the form of a software product.
  • the computer program product is stored in a storage medium and includes a number of instructions for enabling a device (which may be a personal computer, a server, or a network device, a robot, a single-chip microcomputer, a chip, a robot, etc.) to execute all or part of the steps of the method described in each embodiment of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种密钥分发、解析方法及装置。密钥分发方法包括:生成部件获取第一部件的设备能力;生成部件基于第一部件的设备能力,确定第一会话密钥;生成部件向第一部件发送第一目标密钥,第一目标密钥为使用第一会话密钥对第一部件的业务密钥进行加密生成。也就是说,会话密钥与部件的设备能力有关,部件的设备能力不同,则该部件对应的会话密钥不同,提高了传输业务密钥的安全性,也有效降低密钥被暴露的风险。

Description

一种密钥分发、解析方法及装置
本申请要求于2024年3月28日提交中国知识产权局、申请号为202410374621.X、申请名称为“一种密钥分发、解析方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本申请涉及安全通信领域,尤其涉及一种密钥分发、解析方法及装置。
背景技术
车内通信通常是指车内部件之间的通信。因为车内通信安全是智能车的重要组成部分,关乎到车辆的安全,所以,车内部件之间一般通过基于业务密钥的安全通道的方式进行通信来确保车内通信安全。因此,每个车内部件都有自己的业务密钥,才能够实现基于业务密钥的安全通道的方式进行通信。
当前是采用车外派生、产线灌装入车的方式进行密钥的派生与分发,即通过部署在车外的密钥管理系统(key management system,KMS)为车内部件派生业务密钥,并统一在产线上依次灌装至对应的部件。灌装过程一般是:使用预置密钥对业务密钥进行加密,并将加密后的业务密钥发送至对应的车内部件,对应部件接收到加密后的业务密钥后,使用该预置密钥对加密后的业务密钥进行解析获得该业务密钥。但是,上述方案中,许多部件生产商以及整车制造商都知晓该预置密钥,增加了密钥的泄露风险,并且一旦预置密钥泄露,整车的业务密钥也存在泄露风险。
发明内容
本申请公开了一种密钥分发、解析方法及装置,大大降低了密钥的暴露风险,提高密钥分发的安全性,有利于提高车辆的安全性。
第一方面,本申请提供了一种密钥分发方法,应用于生成部件,方法包括:获取第一部件的第一设备能力并向第一部件发送第一目标密钥;获取第二部件的第二设备能力并向第二部件发送第二目标密钥;其中,第一设备能力用于表示第一部件的安全特性,第二设备能力用于表示第二部件的安全特性,第一目标密钥是使用第一会话密钥对第一部件的业务密钥进行加密生成,第二目标密钥是使用第二会话密钥对第二部件的业务密钥进行加密生成,第一设备能力对应第一会话密钥,第二设备能力对应第二会话密钥,第一设备能力不同于第二设备能力,第一会话密钥不同于第二会话密钥。
可选地,生成部件为车辆内密钥管理模块所在的部件,和/或,第一部件和第二部件分别下挂于生成部件。生成部件例如是车辆内的域控制器、整车集成单元(vehicle integrated unit,VIU)、远程信息处理器(telematics box,TBox)或电子控制单元(electronic control unit,ECU)。域控制器包括用于支撑智能驾驶的软硬件一体化平台即车载计算平台(vehicle computing platform),例如移动数据中心(mobiledata center,MDC);用于提供车载多媒体服务(例如抬头显示、仪表盘显示、娱乐影音等中的至少一项)的软硬件一体化平台,例如座舱域控制器(cockpit domain controller,CDC);以及用于支撑车身控制以及底盘控制的软硬件一体化平台,例如整车域控制器(vehicledomain controller,VDC)等中的至少一项。
以第一设备能力对应第一会话密钥为例,理解为第一会话密钥的生成与第一设备能力有关,例如影响第一会话密钥的确定方式和/或第一会话密钥的值。
第一设备能力与第二设备能力不同,即第一部件的安全特性与第二部件的安全特性不同。
上述方法中,针对不同设备能力的部件,生成部件加密传输对应部件的业务密钥时所使用的会话密钥不同,相较于使用一把会话密钥用于所有部件的业务密钥的加密传输,能提高密钥分发的安全性,有效降低了密钥暴露的风险。
可选地,生成部件、第一部件和第二部件部署在车辆内。
实施上述实现方式,能提高车内密钥分发的安全性,有利于提高车辆的安全性。
可选地,向第一部件发送第一目标密钥之前,该方法还包括:基于第一设备能力,确定第一会话密钥,第一会话密钥用于生成部件与第一部件的安全通信;生成第一部件的业务密钥;使用第一会话密钥对第一部件的业务密钥进行加密,获得第一目标密钥。
实施上述实现方式,第一会话密钥、第一部件的业务密钥以及第一目标密钥的生成由生成部件执行,且第一会话密钥的生成考量了部件的设备能力这一因素,能实现业务密钥的安全分发。另外,在车内完成业务密钥的派生和分发,相较于当前产线灌装密钥入车的方式,有利于提高车辆产线的生产效率。
同理,向第二部件发送第二目标密钥之前,该方法还包括:基于第二设备能力,确定第二会话密钥,第二会话密钥用于生成部件与第二部件的安全通信;生成第二部件的业务密钥;使用第二会话密钥对第二部件的业务密钥进行加密,获得第二目标密钥。
可选地,基于第一设备能力,确定第一会话密钥,包括:第一设备能力包括安全存储能力,接收第一部件发送的第一公钥和第一部件的标识信息;根据第一部件的公钥、第一部件的哈希值、生成部件的公钥和生成部件的私钥,获得第一会话密钥;其中,生成部件的公钥与生成部件的私钥对应,第一部件的公钥是基于第一公钥和第二公钥获得,第二公钥为生成部件为第一部件生成,第一部件的哈希值是对第一部件的标识信息和第一部件的公钥进行哈希运算获得。
进一步地,第一设备能力还包括不支持数字证书和不支持非对称硬件加速中的至少一项。
第一设备能力包括安全存储能力,即第一部件具有安全存储能力,是指第一部件具有硬件安全模块(hardware security module,HSM)或加密存储介质,能够在硬件级别上提供安全性。硬件安全模块也称为安全芯片或安全微控制器。安全芯片是专门设计用于提供安全功能和保护机制的硬件组件。
示例性地,上述第一公钥、第二公钥、第一部件的公钥以及第一部件的私钥与椭圆曲线密码学的参数关联。
实施上述实现方式,在第一部件具备安全存储能力的情况下,生成部件采用无证书公钥协议确定第一会话密钥。生成部件参与了第一部件的公私钥对(即第一部件的公钥和第一部件的私钥)的生成,即第一部件的公钥的生成利用了生成部件为第一部件提供的第二公钥,第一部件的私钥的生成利用了生成部件为第一部件提供的第一公钥,这使得后续生成部件在本地计算的第一会话密钥与第一部件在本地计算的第一会话保持一致成为可能,也就实现了生成部件与第一部件双方就第一会话密钥的协商达成一致,且无需传输第一会话密钥,降低了密钥的暴露风险,利用第一会话密钥能实现生成部件与第一部件的安全通信。另外,由上述可知,第一会话密钥还与第一部件的标识信息关联,而不同部件的标识信息不同,故生成部件为每个部件确定的会话密钥也不同,实现了一部件一会话密钥,提高了业务密钥分发的安全性,有效降低了密钥暴露的风险。
可选地,该方法还包括:向第一部件发送第二公钥、第一私钥和生成部件的公钥,第二公钥用于生成第一部件的公钥,第一私钥用于生成第一部件的私钥,生成部件的公钥用于第一部件解析第一目标密钥。
示例性地,第一私钥也与椭圆曲线密码学的参数关联。
实施上述实现方式,在第一部件具备安全存储能力的情况下,生成部件向第一部件发送第二公钥、第一私钥和生成部件的公钥,能辅助第一部件本地生成第一部件的公私钥对,也便于第一部件后续解密。
同理,基于第二设备能力,确定第二会话密钥,包括:第二设备能力包括安全存储能力,接收第二部件发送的第三公钥和第二部件的标识信息;根据第二部件的公钥、第二部件的哈希值、生成部件的公钥和生成部件的私钥,获得第二会话密钥;其中,生成部件的公钥与生成部件的私钥对应,第二部件的公钥是基于第三公钥和第四公钥获得,第四公钥为生成部件为第二部件生成,第二部件的哈希值是对第二部件的标识信息和第二部件的公钥进行哈希运算获得。进一步地,该方法还包括:向第二部件发送第四公钥,第二私钥和生成部件的公钥,第四公钥用于第二部件的公钥,第二私钥用于生成第二部件的私钥,生成部件的公钥用于第二部件解析第二目标密钥。
可选地,生成部件为车辆内密钥管理模块所在的部件,基于第一设备能力,确定第一会话密钥,包括:第一设备能力不包括安全存储能力,根据第一部件的标识信息和主密钥生成第一会话密钥,主密钥由生成部件生成或来自于网络侧设备;生成第一部件的业务密钥,包括:根据第一部件的标识信息和第一会话密钥生成第一部件的业务密钥;该方法还包括:基于第一会话密钥生成解密白盒代码,该解密白盒代码包括第一会话密钥,解密白盒代码用于将第一目标密钥还原为第一部件的业务密钥;向第一部件发送解密白盒代码。
示例性地,生成部件不为车辆内密钥管理模块所在的部件时,如第一部件不具备安全存储能力,生成部件根据生成部件的业务密钥和第一部件的标识信息生成第一会话密钥。
进一步地,第一设备能力还包括不支持数字证书和不支持非对称硬件加速中的至少一项。
示例性地,第一目标密钥和/或解密白盒代码承载于OTA消息中。
示例性地,基于第一会话密钥生成解密白盒代码,包括:基于第一会话密钥和白盒算法生成解密白盒代码,解密白盒代码为混合了第一会话密钥后的白盒算法。这里的“混合”例如理解为第一会话密钥本身作为一个整体被插入白盒算法中,或者,第一会话密钥被拆分为多个部分且这多个部分被随机地插入白盒算法中。
实施上述实现方式,在第一部件不具备安全存储能力时,通过将第一会话密钥和算法代码进行混合,将混合后获得的解密白盒代码发送给第一部件,使得第一部件本地不生成第一会话密钥而是通过解密白盒代码来解密,也就是说,通过解密白盒代码实现了第一会话密钥的安全存储,增加了攻击者获取第一会话密钥的难度,即使第一部件不具备安全存储能力,也能以软件的方式实现密钥的安全存储。
同理,如第二设备能力不包括安全存储能力时,生成部件也可以通过生成解密白盒代码的方式实现第二会话密钥的安全存储,该执行过程请参考前述第一设备能力不包括安全存储能力时生成部件的执行步骤的叙述,在此不再赘述。
示例性地,基于第一设备能力,确定第一会话密钥,包括:第一设备能力包括支持数字证书且支持非对称硬件加速,采用基于数字证书的传输层安全TLS协议确定第一会话密钥。
上述第一部件具备支持数字证书和非对称硬件加速的设备能力时,直接采用基于数字证书的安全分发协议确定用于生成部件与第一部件进行安全通信的会话密钥。
可选地,生成部件包括第一生成部件和第二生成部件,第一部件下挂于第一生成部件,第二部件下挂于第二生成部件,获取第一部件的第一设备能力以及向第一部件发送第一目标密钥均由第一生成部件执行,第一会话密钥、第一部件的业务密钥以及第一目标密钥由第一生成部件生成;获取第二部件的第二设备能力以及向第二部件发送第二目标密钥均由第二生成部件执行,第二会话密钥、第二部件的业务密钥以及第二目标密钥由第二生成部件生成。
由于同一部件的业务密钥的生成者和分发者相同,对于不同的部件来说,若部件的业务密钥的生成者不同,则部件的业务密钥的分发者也不同。多个具备密钥生成能力的部件能以并行处理的方式为各自要负责的部件生成以及分发业务密钥,有利于提高整车业务密钥的生成效率以及分发效率。
第二方面,本申请提供了一种密钥解析方式,应用于第一部件,该方法包括:接收生成部件发送的目标密钥;基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥;其中,第一部件的设备能力用于表示第一部件的安全特性,目标密钥为第一部件的业务密钥经会话密钥加密后的密钥。
可选地,生成部件为车辆内的密钥管理模块所在的部件,和/或,第一部件下挂于生成部件。生成部件请参考前述第一方面关于生成部件的叙述,在此不再赘述。
可选地,第一部件和生成部件部署在车辆内。
上述方法中,第一部件从生成部件获取目标密钥,对目标密钥进行解密以获得第一部件的业务密钥,而目标密钥的解密与第一部件的设备能力有关,不仅能增加第一部件的业务密钥的安全性,有利于降低整车密钥被泄露的风险。
可选地,基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥,包括:第一部件的设备能力包括安全存储能力,根据第一部件的私钥和生成部件的公钥,获得会话密钥;使用会话密钥解析目标密钥,获得第一部件的业务密钥;其中,第一部件的私钥是基于第一私钥和第一部件的哈希值获得,第一部件的哈希值是对第一部件的标识信息和第一部件的公钥进行哈希运算获得,第一部件的公钥是基于第一公钥和第二公钥获得,第一公钥由第一部件生成,第二公钥、第一私钥与第一部件对应,第一私钥、第二公钥和生成部件的公钥来自于生成部件,第一私钥与第一部件的私钥和第一部件的哈希值关联。
实施上述实现方式,第一部件具备安全存储能力时,第一部件本地也能基于已存储的第二公钥、第一私钥和生成部件的公钥确定一个会话密钥,且第二公钥和第一私钥由生成部件提供,如通过该会话密钥成功解密目标密钥以获得第一部件的业务密钥,说明第一部件无需依赖数字证书即实现了对会话密钥的真实性校验。
示例性地,该方法还包括:接收第二部件发送的第二部件的公钥和第二部件的标识信息;根据第二部件的公钥、第二部件的哈希值、第一部件的私钥和生成部件的公钥,获得协商密钥,协商密钥用于第一部件与第二部件的安全通信;其中,第二部件的设备能力包括安全存储能力,第二部件下挂于生成部件,第二部件的哈希值是基于第二部件的公钥和第二部件的标识信息进行哈希运算获得。
实施上述实现方式,第一部件与第二部件互不为对方的业务密钥的生成者时,如第一部件与第二部件之间有通信需求,第一部件可以基于第二部件提供的信息(例如第二部件的公钥和第二部件的标识信息)本地计算一个会话密钥,该会话密钥用于第一部件与第二部件之间后续通信的加密和解密,通过该会话密钥可以实现第一部件与第二部件的安全通信。
可选地,基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥,包括:第一部件的设备能力不包括安全存储能力,本地刷写解密白盒代码,解密白盒代码来自于生成部件,解密白盒代码包括该会话密钥;使用解密白盒代码解析目标密钥,获得第一部件的业务密钥;其中,第一部件的业务密钥与会话密钥和第一部件的标识信息关联,会话密钥与第一部件的标识信息关联。
实施上述实现方式,在第一部件不具备安全存储能力时,通过解密白盒代码实现了会话密钥的安全存储,故第一部件本地不生成会话密钥,而是通过预先从生成部件获取的该解密白盒代码来解密目标密钥以获得第一部件的业务密钥,如此增加了攻击者获取会话密钥的难度,即使第一部件不具备安全存储能力,也提高了密钥的安全性。
第三方面,本申请提供了一种密钥分发装置,该装置为生成部件,装置包括:获取单元,用于获取第一部件的第一设备能力和第二部件的设备能力;发送单元,用于向第一部件发送第一目标密钥以及向第二部件发送第二目标密钥;其中,第一设备能力用于表示第一部件的安全特性,第二设备能力用于表示第二部件的安全特性,第一目标密钥是通过处理单元使用第一会话密钥对第一部件的业务密钥进行加密生成,第二目标密钥是通过处理单元使用第二会话密钥对第二部件的业务密钥进行加密生成,第一设备能力对应第一会话密钥,第二设备能力对应第二会话密钥,第一设备能力不同于第二设备能力,第一会话密钥不同于第二会话密钥。
可选地,生成部件、第一部件和第二部件部署在车辆内。
可选地,生成部件为车辆内密钥管理模块所在的部件,和/或,第一部件和第二部件分别下挂于生成部件。
可选地,处理单元用于:基于第一设备能力,确定第一会话密钥,第一会话密钥用于生成部件与第一部件的安全通信;生成第一部件的业务密钥;使用第一会话密钥对第一部件的业务密钥进行加密,获得第一目标密钥。
同理,处理单元用于:基于第二设备能力,确定第二会话密钥,第二会话密钥用于生成部件与第二部件的安全通信;生成第二部件的业务密钥;使用第二会话密钥对第二部件的业务密钥进行加密,获得第二目标密钥。
可选地,处理单元具体用于:第一设备能力包括安全存储能力,接收第一部件发送的第一公钥和第一部件的标识信息;根据第一部件的公钥、第一部件的哈希值、生成部件的公钥和生成部件的私钥,获得第一会话密钥;其中,生成部件的公钥与生成部件的私钥对应,第一部件的公钥是处理单元基于第一公钥和第二公钥获得,第二公钥为生成部件为第一部件生成,第一部件的哈希值是处理单元对第一部件的标识信息和第一部件的公钥进行哈希运算获得。
例如,第一公钥、第二公钥、第一部件的公钥、第一部件的私钥均与椭圆曲线密码学的参数关联。
可选地,发送单元还用于:向第一部件发送第二公钥、第一私钥和生成部件的公钥,第二公钥用于生成第一部件的公钥,第一私钥用于生成第一部件的私钥,生成部件的公钥用于第一部件解析第一目标密钥。
同理,处理单元具体用于:第二设备能力包括安全存储能力,接收第二部件发送的第三公钥和第二部件的标识信息;根据第二部件的公钥、第二部件的哈希值、生成部件的公钥和生成部件的私钥,获得第二会话密钥;其中,生成部件的公钥与生成部件的私钥对应,第二部件的公钥是处理单元基于第三公钥和第四公钥获得,第四公钥为生成部件为第二部件生成,第二部件的哈希值是处理单元对第二部件的标识信息和第二部件的公钥进行哈希运算获得。进一步地,该方法还包括:向第二部件发送第四公钥,第二私钥和生成部件的公钥,第四公钥用于第二部件的公钥,第二私钥用于生成第二部件的私钥,生成部件的公钥用于第二部件解析第二目标密钥。
可选地,生成部件为车辆内密钥管理模块所在的部件,处理单元具体用于:第一设备能力不包括安全存储能力,根据第一部件的标识信息和主密钥生成第一会话密钥,主密钥由生成部件生成或来自于网络侧设备;根据第一部件的标识信息和第一会话密钥生成第一部件的业务密钥;基于第一会话密钥生成解密白盒代码,解密白盒代码包括第一会话密钥,解密白盒代码用于将第一目标密钥还原为第一部件的业务密钥;发送单元,还用于向第一部件发送解密白盒代码。
可选地,生成部件包括第一生成部件和第二生成部件,第一部件下挂于第一生成部件,第二部件下挂于第二生成部件,上述获取单元包括第一生成部件的第一获取单元和第二生成部件的第二获取单元,上述发送单元包括第一生成部件的第一发送单元和第二生成部件的第二发送单元;第一获取单元,用于获取第一部件的第一设备能力;第一发送单元,用于向第一部件发送第一目标密钥;第二获取单元,用于获取第二部件的第二设备能力;第二发送单元,用于向第二部件发送第二目标密钥;上述处理单元包括第一生成部件的第一处理单元和第二生成部件的第二处理单元,其中,第一会话密钥、第一部件的业务密钥以及第一目标密钥由第一处理单元生成;第二会话密钥、第二部件的业务密钥以及第二目标密钥由第二处理单元生成。
第四方面,本申请提供了一种密钥解析装置,该装置为第一部件,该装置包括:接收单元,用于接收生成部件发送的目标密钥,目标密钥为第一部件的业务密钥经会话密钥加密后的密钥;处理单元,用于基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥;其中,第一部件的设备能力用于表示第一部件的安全特性。
可选地,第一部件和生成部件部署在车辆内。
可选地,生成部件为车辆内的密钥管理模块所在的部件,和/或,第一部件下挂于生成部件。
可选地,处理单元具体用于:第一部件的设备能力包括安全存储能力,根据第一部件的私钥和生成部件的公钥,获得会话密钥;使用会话密钥解析目标密钥,获得第一部件的业务密钥;其中,第一部件的私钥是基于第一私钥和第一部件的哈希值获得,第一部件的哈希值是处理单元对第一部件的标识信息和第一部件的公钥进行哈希运算获得,第一部件的公钥是处理单元基于第一公钥和第二公钥获得,第一公钥由第一部件生成,第二公钥、第一私钥与第一部件对应,第一私钥、第二公钥和生成部件的公钥来自于生成部件,第一私钥与第一部件的私钥和第一部件的哈希值关联。
例如,第一公钥、第二公钥、第一私钥、第一部件的公钥、第一部件的私钥均与椭圆曲线密码学的参数关联。
示例性地,接收单元,还用于接收第二部件发送的第二部件的公钥和第二部件的标识信息;处理单元,还用于根据第二部件的公钥、第二部件的哈希值、第一部件的私钥和生成部件的公钥,获得协商密钥,协商密钥用于第一部件与第二部件的安全通信;其中,第二部件的设备能力包括安全存储能力,第二部件下挂于生成部件,第二部件的哈希值是通过处理单元基于第二部件的公钥和第二部件的标识信息进行哈希运算获得。
可选地,处理单元具体用于:第一部件的设备能力不包括安全存储能力,本地刷写解密白盒代码,解密白盒代码来自于生成部件,解密白盒代码包括该会话密钥;使用解密白盒代码解析目标密钥,获得第一部件的业务密钥;其中,第一部件的业务密钥与会话密钥和第一部件的标识信息关联,会话密钥与第一部件的标识信息关联。
第五方面,本申请提供了一种芯片,该芯片包括处理器和存储器,其中,存储器用于存储程序指令;所述处理器调用所述存储器中的程序指令,使得该芯片执行第一方面或者第一方面的任一可能的实现方式中的方法。
第六方面,本申请提供了一种电子控制单元,该电子控制单元包括处理器和存储器,其中,存储器用于存储程序指令;所述处理器调用所述存储器中的程序指令,使得该电子控制单元执行第二方面或者第二方面的任一可能的实现方式中的方法。
第七方面,本申请提供了一种密钥分发系统,该密钥分发系统包括第一装置和第二装置,其中,第一装置用于实现上述第一方面或者第一方面的任一可能的实现方式中的方法,第二装置用于实现上述第二方面或者第二方面的任一可能的实现方式中的方法。
示例性地,第一装置为上述第三方面或者第三方面任一可能的实现方式的装置,或者,第一装置为第五方面所述的芯片;第二装置为上述第四方面或者第四方面任一可能的实现方式的装置,或者,第二装置为第六方面所述的电子控制单元。
第八方面,本申请提供了一种车辆,该车辆包括如上述第三或五方面的装置,或者包括如上述第三或五方面的任一可能的实现方式的装置,或者包括如上述第四或六方面的装置,或者包括如上述第四或六方面的任一可能的实现方式的装置,或者包括如第七方面所述的密钥分发系统。
第九方面,本申请提供了一种计算机可读存储介质,包括计算机指令,当所述计算机指令在被处理器运行时,实现上述第一方面或者第一方面的任一可能的实现方式中的方法,或者实现上述第二方面或者第二方面的任一可能的实现方式中的方法。
第十方面,本申请提供了一种计算机程序产品,当该计算机程序产品被处理器执行时,实现上述第一方面或者第一方面的任一可能的实施例中的所述方法,或者实现上述第二方面或者第二方面的任一可能的实施例中的所述方法。
示例性地,该计算机程序产品为一个软件安装包。
附图说明
图1是本申请实施例提供的一种密钥管理系统的架构示意图;
图2是本申请实施例提供的一种车辆的结构示意图;
图3是本申请实施例提供的一种密钥分发方法的流程图;
图4是本申请实施例提供的一种业务密钥派生方法的流程图;
图5是本申请实施例提供的一种部件的公私钥对的生成方法的流程图;
图6是本申请实施例提供的一种密钥生成装置的结构示意图;
图7是本申请实施例提供的一种密钥解析装置的结构示意图;
图8是本申请实施例提供的一种密钥处理设备的结构示意图。
具体实施方式
需要说明的是,本申请中采用诸如“第一”、“第二”的前缀词,仅仅为了区分不同的描述对象,对被描述对象的位置、顺序、优先级、数量或内容等没有任何限定作用。例如,被描述对象为“字段”,则“第一字段”和“第二字段”中“字段”之前的序数词并不限制“字段”之间的位置或顺序,“第一”和“第二”并不限制其修饰的“字段”是否在同一个消息中,也不限制“第一字段”和“第二字段”的先后顺序。再如,被描述对象为“等级”,则“第一等级”和“第二等级”中“等级”之前的序数词并不限制“等级”之间的优先级。再如,被描述对象的数量并不受前缀词的限制,可以是一个或者多个,以“第一设备”为例,其中“设备”的数量可以是一个或者多个。此外,不同前缀词修饰的对象可以相同或不同,例如,被描述对象为“设备”,则“第一设备”和“第二设备”可以是同一个设备、相同类型的设备或者不同类型的设备;再如,被描述对象为“信息”,则“第一信息”和“第二信息”可以是相同内容的信息或者不同内容的信息。总之,本申请实施例中对用于区分描述对象的前缀词的使用不构成对所描述对象的限制,对所描述对象的陈述参见权利要求或实施例中上下文的描述,不应因为使用这种前缀词而构成多余的限制。
需要说明的是,本申请实施例中采用诸如“a1、a2、……和an中的至少一项(或至少一个)”等的描述方式,包括了a1、a2、……和an中任意一个单独存在的情况,也包括了a1、a2、……和an中任意多个的任意组合情况,每种情况可以单独存在。例如,“a、b和c中的至少一项”的描述方式,包括了单独a、单独b、单独c、a和b组合、a和c组合、b和c组合,或abc三者组合的情况。
为了便于理解,下面先对本申请实施例可能涉及的相关术语等进行介绍。
(1)硬件安全模块
硬件安全模块(hardware security module,HSM)是一种专用的硬件设备,用于保护和管理敏感数据、会话密钥和执行加密操作。(E-safety vehicle intrusion protected applications,EVITA)是一种安全标准,旨在确保车辆电子系统的安全性和防护能力。EVITA将HSM划分为三个等级:EVITA full HSM、EVITA medium HSM、EVITA light HSM(或是EVITA small HSM),其中,EVITA full HSM用于V2X通信,EVITA medium HSM用于板上电子控制单元(Electronic Control Unit,ECU)间通信,EVITA light HSM用于板子传感器和执行器的通信。
硬件安全模块在硬件级别上提供额外的安全性,使得攻击者更难以获取或篡改存储在设备中的敏感信息。
(2)无证书公钥协议
无证书公钥协议(certificateless public key cryptography,CL-PKC)是一种密码学方案,旨在解决传统公钥基础设施(public key infrastructure,PKI)中证书管理的一些问题。在传统的公钥基础设施中,需要可信的证书颁发机构(certificate authority,CA)来验证公钥的真实性,这增加了管理和维护的复杂性。
CL-PKC通过协商、交换信息和验证,实现通信的各方能在不依赖于传统证书颁发机构颁发的数字证书的情况下建立安全通信。
(3)密钥派生
密钥派生是指从一个或多个初始密钥中派生出其他密钥的过程。初始密钥也称为主密钥。
密钥派生通常依赖于派生函数或密钥派生函数(key derivation function,KDF)来实现。密钥派生函数例如是PBKDF2、HKDF、scrypt、Argon2等。
为了降低整车密钥的暴露风险,本申请实施例提供了一种密钥管理系统,该系统能够为车辆内的每个部件确定一个会话密钥,使用部件对应的会话密钥确保该部件的业务密钥安全传输至对应部件。另外,会话密钥的生成与部件的设备能力有关,部件的设备能力用于描述设备的安全特性,部件的设备能力不同,部件对应的会话密钥不同。如此,车辆内的所有部件不再共用一个会话密钥,不同部件的业务密钥通过不同的会话密钥加密传输,有利于降低密钥的暴露风险,提高密钥传输的安全性。
参见图1,图1是本申请实施例提供的一种密钥管理系统的架构示意图。如图1所示,该密钥管理系统包括终端10和网络侧设备20,其中,终端10与网络侧设备20之间以无线的方式进行通信。
终端10例如是车辆、机器人、无人机、船舶、轮船等有密钥管理需求的智能终端或物联网设备。其中,车辆为广义概念上的车辆,可以是交通工具(如商用车、乘用车、摩托车、飞行车、火车等),工业车辆(如:叉车、挂车、牵引车等),工程车辆(如挖掘机、推土车、吊车等),农用设备(如割草机、收割机等)等。再如,机器人可以为智能搬运机器人(automated guided vehicle,AGV)、可行走会话机器人、服务机器人等机器人。可以理解,涉及内部部件之间安全通信的终端都属于终端10。
示例性地,车辆可以是自动驾驶车辆,也可以是非自动驾驶车辆。这里,自动驾驶并不局限于完全自动驾驶、高度自动驾驶、有条件自动驾驶、或部分自动驾驶等,本领域技术人员可以理解,提供智能驾驶的非完全人工驾驶都可以涵盖在本概念之下。另外,本申请实施例也不限定车辆的动力来源,例如是新能源车辆或者传统燃油类车辆。
网络侧设备20可以是计算设备或者计算设备集群,其中,计算设备包括裸金属服务器(bare metal server,BMS)、虚拟机、容器或者边缘计算设备。BMS指的是通用的物理服务器,例如,ARM服务器或者X86服务器;虚拟机指的是通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。在实体计算机中能够完成的工作在虚拟机中都能够实现。在计算设备中创建虚拟机时,需要将实体机的部分硬盘和内存容量作为虚拟机的硬盘和内存容量。每个虚拟机都有独立的基础输入/输出系统(basic input/output system,BIOS)、硬盘和操作系统,可以像使用实体机一样对虚拟机进行操作;容器是一种虚拟化软件,可以将应用及其所有依赖项合并为一个软件包,该软件包不受底层主机操作系统的限制,这样无需再构建复杂的环境,简化了应用开发到部署的过程;边缘计算设备是指更加接近数据源和终端用户,具有低延迟、高带宽特点的设备,比如智能路由、边缘服务器等等。计算设备集群可包括多个上述计算设备,比如数据中心,本申请不作具体限定。网络侧设备20可以部署在云环境中,也可以部署在边缘环境中。网络侧设备20可以是集成的一个设备,也可以是分布式的多个设备,在此不作具体限定。网络侧设备20还可以是计算设备中的组件,组件可以是芯片或集成电路等。
其中,终端10上部署有密钥管理系统(key management system,KMS),网络侧设备20上也部署有密钥管理系统。密钥管理系统也称为密码学密钥管理系统(crytographic key management system,CKMS),其包含生成、分发和管理设备和应用程序的密钥的功能。为了区分网络侧设备20上部署的密钥管理系统,终端10上部署的密钥管理系统也称为密钥管理模块(key management module,KeyM),终端10上的KeyM能用于负责车辆内各部件的相关密钥的生成和分发,网络侧设备20上的KMS能辅助终端10上的KeyM执行相关密钥的生成。
上述图1只是密钥管理系统的一种示例性架构图,并不限定密钥管理系统仅为图1所示。在一些可能的实施例中,终端10各部件的相关密钥的生成无需网络侧设备20的参与,在此情况下,图1所示的密钥管理系统也可以不包括网络侧设备20。
下面将以图1中的终端10为车辆为例,对车辆包括的车内部件进行详细的介绍。参见图2,图2是本申请实施例提供的一种车辆的结构示意图。
在图2中,该车辆内的车内部件包括至少一个域控制器(domain controller,DC)、至少一个整车集成单元(vehicle integrated unit,VIU)、电子控制单元(electronic control unit,ECU)和远程信息处理器(telematics box,TBox)。其中,DC与VIU之间,以及VIU与VIU之间通过高速以太网的网络进行连接通信,使得整车网络高效率和高可靠。TBOX例如通过以太网与VIU和/或DC进行通信,例如传递信息或指令,包括车辆状态信息、钥匙状态信息、控制指令等。
VIU用于管理所在区域中的电子控制单元(electronic control unit,ECU),VIU可供相应地传感器、执行器或者ECU就近接入,实现电源供给、电子保险丝、I/O口隔离等功能。另外,VIU具有网关部分或全部的功能,例如,协议转换功能、协议封装并转发功能以及数据格式转换功能。在VIU集成了部分车辆零部件内的ECU功能时,VIU还具有电子控制功能,用于实现对相应车辆零部件的控制。
在图2中,至少一个VIU包括VIU0、VIU1、VIU2和VIU3,其中,仅VIU0上部署有上述密钥管理模块KeyM。在一些可能的实施例中,不限定车辆内部署的KeyM的数量,KeyM例如部署在VIU、DC或车辆内其他具备证书能力的装置上。作为一种示例,VIU0、VIU1、VIU2和VIU3各自均部署有KeyM。
车辆中的每个功能域可以有独立的域控制器,域控制器可以理解为包括域主控硬件、操作系统、算法和应用软件等部分的系统的统称。在图2中,至少一个DC包括用于支撑智能驾驶的软硬件一体化平台即车载计算平台(vehicle computing platform),例如移动数据中心(mobiledata center,MDC);以及包括用于提供车载多媒体服务(例如抬头显示、仪表盘显示、娱乐影音等中的至少一项)的软硬件一体化平台,例如座舱域控制器(cockpit domain controller,CDC)。在一些可能的实施例中,至少一个DC还包括用于支撑车身控制以及底盘控制的软硬件一体化平台,例如整车域控制器(vehicledomain controller,VDC)。在一些可能的实施例中,MDC也可以称作高级驾驶辅助系统域控制器(advanced driving assistance system domain controller,ADASDC)或自动驾驶域控制器(automatic drive domain controller,AD DC)。
其中,MDC用于为实现自动驾驶功能的车辆零部件提供服务,其中,实现自动驾驶功能的车辆零部件包括单目摄像头、双目摄像头、毫米波雷达、激光雷达、超声波雷达等。
CDC用于为座舱域内的车辆零部件提供服务,其中,座舱域内的车辆零部件包括抬头显示(head-up display,HUD)、仪表显示器、收音机、导航、摄像头等。
VDC用于为车身域内的车辆零部件以及底盘域内的车辆零部件提供服务,其中,车身域内的车辆零部件包括门窗升降控制器、电动后视镜、空调、中央门锁等;底盘域内的车辆零部件包括制动系统中的车辆零部件、转向系统中的车辆零部件、加速系统中的车辆零部件,比如油门等。
基于车内部件的设备能力将车辆内的部件划分为三种类型,参见下述第一类部件-第三类部件的描述:
1)第一类部件
第一类部件的设备能力包括支持数字证书且支持非对称硬件加速。
数字证书是一种用于在网络上验证通信双方身份的安全工具,通常基于公钥基础设施PKI的框架,例如用于身份验证的SSL/TLS证书。支持数字证书的设备是指具备相应功能和安全协议的设备,可以用来处理、验证和生成数字证书。
支持非对称硬件加速的设备是指该设备具备专门的硬件模块或加速器,用于执行非对称加密算法的加速运算。非对称加密算法,也称为公钥加密算法。非对称加密算法是一种使用公钥和私钥进行加密和解密的密码学算法,例如RSA、数字签名算法(digital signature algorithm,DSA)、椭圆曲线密码学(Elliptic-curve cryptography,ECC)等。
示例性地,在图2中,VIUx(其包括VIU0、VIU1、VIU2和VIU3)、TBox、CDC、MDC等连接了以太网的设备属于第一类部件。
2)第二类部件
第二类部件的设备能力包括安全存储能力。在一些可能的实施例中,第二类部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
这里,部件具备安全存储能力理解为该部件具有硬件安全模块或加密存储介质,能够在硬件级别上提供安全性。硬件安全模块也称为安全芯片或安全微控制器。安全芯片是专门设计用于提供安全功能和保护机制的硬件组件。它们通常集成了加密引擎、随机数生成器、安全存储、身份认证模块等功能,用于执行加密操作、存储密钥、验证身份等安全任务。
示例性地,在图2中,ECU01、ECU02等具有安全存储能力的设备属于第二类部件。示例性地,第二类部件挂接于控制器局域网(controller area network,CAN)总线或CAN-FD(CAN With Flexible Data-Rate)总线。
在一些可能的实施例中,第二类部件还包括智能钥匙模块(intelligent key module,IKM)、微控制单元(microcontroller unit,MCU)和电池管理系统(battery management system,BMS)。
3)第三类部件
第三类部件的设备能力不包括安全存储能力。在一些可能的实施例中,第三类部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
示例性地,第三类部件包括无安全存储能力的传感器部件,该传感器部件主要用于收集车辆运行状态、环境信息等数据,以支持车辆的控制、监测和决策系统。该传感器部件例如包括全球卫星定位系统(global positioning system,GPS)、惯性测量单元(inertial measurement unit,IMU)、车速传感器、转向角传感器、激光雷达、摄像头、超声波传感器、大气压力传感器、温度传感器等用于提供车辆状态和周围环境数据的传感器部件。
假设图2中ECU11的设备能力、ECU12的设备能力以及ECU12的设备能力满足第三类部件的设备能力的判断条件,则ECU11、ECU12、ECU12均属于第三类部件。在图2中,ECU11、ECU12、ECU12通过车内信号总线(例如CAN总线或Lin总线)与VIU1连接。
上述图2为车辆的内部结构的一种示例,但不限定图2所示系统包括的网元的数量。虽然图2未示出,但除图2所示的功能实体外,图2还可以包括其他功能实体。另外,本申请实施例提供的方法可以应用于图2所示的车辆结构。当然本申请实施例提供的方法也可以适用其他车辆结构,例如在一些实现方式中,图2中的MDC和CDC被执行逻辑功能的融合以形成一个融合后的域控制器,即MDC和CDC合二为一,当然也可能对上述VDC、MDC和CDC中的多项采用其他融合方式,在此不作具体限定。
为了叙述方便,下述终端10以车辆为例进行方案的示例性阐述,但本申请实施例并不限定终端10仅为车辆。
下面结合上述图1、图2所示的结构介绍本申请实施例提供的一种密钥分发方法。
参见图3,图3是本申请实施例提供的一种密钥分发方法的流程图。该方法应用于生成部件和第一部件组成的通信系统,其中,生成部件为第一部件的业务密钥的生成者,也是第一部件的业务密钥的发送者。生成部件和第一部件均部署在图1中的终端10上或者图2所示的车辆上。
图3实施例所示方法包括但不限于下述步骤S301-S305。
S301:生成部件生成第一部件的业务密钥。
这里,对于任一部件(例如第一部件),第一部件的业务密钥与特定的业务需求(例如诊断业务)、应用程序或服务关联。
车辆内部件的业务密钥的生成方式主要有两种,分别为集中式派生和分布式派生。
第一种:集中式派生
集中式派生是指由车辆内的一个密钥管理模块KeyM负责派生该车辆内各部件的业务密钥。采用集中式派生方式执行业务密钥的生成,由一个密钥管理模块负责整车业务密钥的生成,业务密钥集中管理,部署成本低且便于维护。
示例性地,业务密钥采用集中式派生的过程请参见图4实施例的描述。图4是本申请实施例提供的一种业务密钥派生方法的流程图。该方法应用于生成部件、第一部件以及网络侧设备组成的通信系统,其中,生成部件为密钥管理模块KeyM所在的部件,第一部件为车辆内任一对业务密钥有需求的部件。网络侧设备例如是上述图1中的网络侧设备20,车辆为图1中终端10的一种示例。
示例性地,生成部件和第一部件均部署在车辆内,网络侧设备部署在车辆外。车辆为图2所示的车辆时,生成部件为图2中的VIU0,第一部件可以是图2所示的任一车内部件。在此情况下,部件的业务密钥的派生发生在车内。
图4所示实施例包括但不限于下述步骤S401-S403。
S401:生成部件从网络侧设备获取主密钥。
作为一种示例,生成部件从网络侧设备获取主密钥,包括:车辆组装完成上电后,生成部件中的KeyM触发密钥派生流程,该KeyM向网络侧设备发送第一请求,第一请求用于请求获取主密钥;响应于第一请求,网络侧设备向生成部件发送主密钥,从而生成部件中的KeyM获取主密钥。
示例性地,主密钥为网络侧设备的用户提供或者由网络侧设备上部署的密钥管理系统KMS生成。
为了主密钥的安全性,网络侧设备可以采用加密手段向生成部件安全传输主密钥。
S402:生成部件从第一部件获取第一部件的标识信息。
其中,第一部件的标识信息用于标识第一部件。第一部件的标识信息例如是第一部件的部件序列号、第一部件的部件ID或第一部件的IP地址等。
示例性地,生成部件从第一部件获取第一部件的标识信息,包括:生成部件中的KeyM向第一部件发送标识请求信息;响应于该标识请求信息,第一部件向生成部件发送第一部件的标识信息,从而生成部件中的KeyM获取第一部件的标识信息。
另一种实现方式中,生成部件预存有第一部件的标识信息,则生成部件中的KeyM直接从本地获取第一部件的标识信息。
S403:生成部件基于主密钥和第一部件的标识信息,生成第一部件的业务密钥。
一种实现方式中,生成部件基于主密钥和第一部件的标识信息,生成第一部件的业务密钥,包括:生成部件中的KeyM将主密钥和第一部件的标识信息作为密钥派生函数的输入,获得第一部件的业务密钥,其中,第一部件的业务密钥为该密钥派生函数基于主密钥和第一部件的标识信息输出的结果。
示例性地,第一部件的业务密钥的生成满足下述公式(1):
KEYx=KDF(MK,ID_ECUx||Salt_ECUx)         公式(1)
其中,KEYx表示第一部件的业务密钥,第一部件可以是车辆内的任一部件。KDF()表示密钥派生函数,MK表示主密钥,ID_ECUx表示第一部件的标识信息。Salt_ECUx例如是256比特的数字,Salt_ECUx随着第一部件的业务密钥的每次更新而加1。上述公式(1)只是一种示例,也可以通过基于公式(1)变形后的公式生成第一部件的业务密钥。
在一些可能的实施例中,可以不执行S401,上述主密钥由生成部件中的KeyM本地生成。
第二种:分布式派生
分布式派生是指先由车辆内的密钥管理模块KeyM(设置有多个)派生处于以太网环上的部件(例如图1中的CDC、MDC、TBox、VIUx等)的业务密钥,再由以太网环上的部件为自身下挂的部件分别派生业务密钥,….,直至车辆内的各部件均有自身的业务密钥。采用分布式派生方式执行业务密钥的生成,多个具备密钥生成能力的部件能以并行处理的方式为各自要负责的部件生成业务密钥,有利于提高整车业务密钥的生成效率。
在图2所示结构中,假设VIUx(即VIU0、VIU1、VIU2和VIU3)均部署有KeyM,VIUx、TBox、CDC和MDC均处于以太网环上,采用分布式派生部件的业务密钥的过程包括下述步骤Step1和Step2。
Step1:VIU0上的KeyM基于主密钥分别为VIU0、TBox、CDC和MDC生成业务密钥,VIU1为VIU1生成业务密钥,VIU2为VIU2生成业务密钥,VIU3为VIU3生成业务密钥。
这里,主密钥由VIU0上的KeyM生成或者主密钥来自于网络侧设备。主密钥来自于网络侧设备,便于网络侧设备对车辆的主密钥进行统一管理,每辆车对应一个主密钥,当车辆A的部件替换至车辆B时,车辆B能够通过车辆A的主密钥请求网络侧设备验证车辆A身份的合法性。主密钥由KeyM本地生成,密钥不出车,降低了密钥的暴露风险。
以VIU0上的KeyM基于主密钥为TBox生成业务密钥为例,VIU0上的KeyM基于主密钥为TBox生成业务密钥,包括:VIU0上的KeyM基于主密钥和TBox的标识信息,生成TBox的业务密钥。此实施方式请参考前述S403的相关叙述,在此不再赘述。
Step2:VIUx、TBox、CDC、MDC分别为自身下挂的其它未配置业务密钥的部件派生业务密钥。
假设ECU001下挂于MDC,以MDC为自身下挂的部件ECU001派生业务密钥为例,MDC基于MDC的业务密钥和ECU001的标识信息,生成ECU001的业务密钥。
由上述Step1和Step2可知,采用分布式派生方式,生成部件为KeyM所在的部件时,则生成部件基于主密钥和第一部件的标识信息,生成第一部件的业务密钥;生成部件不为KeyM所在的部件时,则生成部件基于该生成部件的业务密钥和第一部件的标识信息,生成第一部件的业务密钥。
采用分布式派生方式,车辆内的多个部件具备密钥生成能力,车辆内的各个KeyM先为以太网环上的部件生成业务密钥,再由以太网环上的部件为自身下挂的部件生成业务密钥,如此,实现车辆内的每个部件有一个业务密钥。
采用分布式派生的情况下,第一部件下挂于生成部件。在图2中,例如生成部件为CDC则第一部件包括下挂于CDC的部件;又例如生成部件为VIU1则第一部件包括下挂于VIU1的部件(即ECU11、ECU12和ECU13);又例如生成部件为VIU0则第一部件包括下挂于VIU0的部件(包括ECU11、ECU12和ECU13),或者生成部件和第一部件还可以图2中的其他形式。
这里,第一部件下挂于生成部件,则生成部件的设备能力不低于第一部件的设备能力。例如,若生成部件属于第一类部件,则第一部件属于第一类部件、第二类部件或第三类部件;若生成部件属于第二类部件,则第一部件属于第二类部件或第三类部件。
一种实现方式中,生成部件为第一部件生成业务密钥时,不区分第一部件的设备能力。
另一种实现方式中,第一部件的设备能力不包括安全存储能力时(即第一部件属于前述第三类部件),生成部件生成第一部件的业务密钥,包括:生成部件基于预密钥和第一部件的标识信息生成根密钥;生成部件基于根密钥和第一部件的标识信息生成第一部件的业务密钥。
示例性地,生成部件为KeyM所在的部件时,上述预密钥为主密钥;生成部件不为KeyM所在的部件时,上述预密钥为该生成部件的业务密钥。其中,主密钥可参考前述相应内容的叙述。
示例性地,生成部件采用第一密钥派生算法生成上述根密钥,生成部件采用第二密钥派生算法生成第一部件的业务密钥,第一密钥派生算法和第二密钥派生算法可以相同,也可以不同。
上述生成部件和第一部件部署在车辆内时,实现了业务密钥的生成在车内完成。相较于当前产线密钥灌装流程,本申请实施例实现了车辆密钥不出车,有利于降低密钥的暴露风险。
S302:生成部件基于第一部件的设备能力,确定第一会话密钥。
这里,不限定S301和S302的执行顺序,例如二者可以同时执行或者一先以后执行。
其中,第一会话密钥用于生成部件与第一部件的安全通信。也就是说,第一会话密钥与第一部件的设备能力对应,若第一部件的设备能力发生变化,则第一会话密钥也会改变。如此,有利于提高双方通信的安全性。
示例性地,第一部件的设备能力为生成部件从第一部件获取,或者,第一部件的设备能力为用户在生成部件上设置,或者第一部件的设备能力为部件出厂时默认写入至生成部件的。
前述基于部件的设备能力将部件划分为三种类型,下面分别叙述第一部件属于不同类型的部件时,第一会话密钥的确定过程,请参见下述情况1-情况3。
情况1:第一部件属于上述第一类部件
一种实现方式中,第一部件的设备能力包括支持数字证书且支持非对称硬件加速,生成部件基于第一部件的设备能力,确定第一会话密钥,包括:生成部件采用基于数字证书的传输层安全(transport layer security,TLS)协议确定第一会话密钥。
以生成部件为KeyM,第一部件为CDC为例,说明KeyM采用TLS协议确定第一会话密钥的过程,请参考下述步骤A11-A14。
A11:KeyM与CDC预先协商好要使用的TLS版本和加密算法。
A12:KeyM向CDC发送数字证书,该数字证书包括KeyM的公钥和签名信息。
相应地,CDC使用本地存储的根证书或证书颁发机构的证书来验证KeyM发送的数字证书的有效性和真实性。数字证书的验证包括检查数字证书中的签名信息是否有效、数字证书是否在有效期内等。在该数字证书验证成功的情况下,CDC使用KeyM的公钥对预主密钥进行加密(加密过程中使用了A11中的加密算法),获得加密后的密钥,CDC向KeyM发送该加密后的密钥。
A13:KeyM从CDC接收加密后的密钥,KeyM使用KeyM的私钥对该加密后的密钥进行解密,获得预主密钥。
A14:KeyM与CDC基于该预主密钥协商确定第一会话密钥,该第一会话密钥用于加密和解密KeyM与CDC后续的通信。这里,KeyM与CDC基于该预主密钥协商确定第一会话密钥的过程可以参考现有技术有基于证书的TLS协议确定会话密钥的叙述,在此不再赘述。
上述第一部件具备支持数字证书和非对称硬件加速的设备能力时,直接采用基于数字证书的安全分发协议确定用于生成部件与第一部件进行安全通信的会话密钥。
情况2:第一部件属于上述第二类部件
一种实现方式中,第一部件的设备能力包括安全存储能力,生成部件基于第一部件的设备能力,确定第一会话密钥,包括:生成部件接收第一部件发送的第一公钥和第一部件的标识信息;根据第一部件的公钥、第一部件的哈希值、生成部件的公钥和生成部件的私钥,获得第一会话密钥;其中,生成部件的公钥与生成部件的私钥对应,第一部件的公钥是基于第一公钥和第二公钥获得,第二公钥为生成部件为第一部件生成,第一部件的哈希值是对第一部件的标识信息和第一部件的公钥进行哈希运算获得。
进一步地,第一部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
示例性地,第一公钥、第二公钥、生成部件的公钥和生成部件的私钥通过椭圆曲线密码学获得。
进一步地,生成部件在确定第一会话密钥的过程中,生成部件还向第一部件发送上述第二公钥、第一私钥和生成部件的公钥,其中,第二公钥用于生成第一部件的公钥,第一私钥用于生成第一部件的私钥,生成部件的公钥用于第一部件解析获得第一部件的业务密钥。
也就是说,第一部件属于上述第二类部件时,生成部件采用无证书公钥协议确定上述第一会话密钥,使得第一部件本地也能基于获取的第二公钥、第一私钥和生成部件的公钥确定第一会话密钥,从而第一部件无需依赖数字证书即可实现对公钥(例如第一会话密钥)的真实性校验。另外,第一部件具备安全存储能力,第一部件能够将获取的相关密钥(例如上述第二公钥、第一私钥等)进行安全存储。
为了使得情况2下第一会话密钥的获得过程的叙述更清楚,以生成部件为KeyM所在部件、第一部件为ECUi进行方案的示例性阐述,生成部件为第一部件的业务密钥的生成者。用于KeyM与ECUi安全通信的第一会话密钥的确定过程包括两个阶段,分别为下述阶段一和阶段二。
阶段一:KeyM需先辅助ECUi生成ECUi的公私钥对
ECUi的公私钥对包括ECUi的公钥和ECUi的私钥。
ECUi的公私钥对的生成过程请参考图5的流程示意图。图5是本申请实施例提供的一种部件的公私钥对的生成方法的流程图。图5所示ECUi的公私钥对的生成方法应用于KeyM与ECUi,该方法包括但不限于下述步骤S501-S505。
S501:ECUi生成第一公钥。
示例性地,ECUi与KeyM预先协商好使用椭圆曲线密码学在本地进行系统参数的统一配置。其中,系统参数包括其中,ε表示椭圆曲线组,n为素数,G为椭圆曲线的n阶基点,椭圆曲线在有限域Fq上,H()表示哈希函数。H()例如配置为采用椭圆曲线密码学进行系统参数配置,有利于轻量化的实现公钥的真实性校验,能减少密钥生成过程中算力的消耗。
示例性地,ECUi本地执行上述系统参数配置后,ECUi通过下述公式(2)生成第一公钥。
Xi=xiG             公式(2)
其中,Xi表示ECUi的第一公钥,xi为随机数,参数G可参考前述叙述,在此不再赘述。公式(2)只作为ECUi生成第一公钥的一种示例,并不应对ECUi生成第一公钥的方式构成限定。
S502:ECUi向KeyM发送第一公钥和ECUi的标识信息。
ECUi的标识信息用于标识ECUi。ECUi的标识信息例如是ECUi的部件序列号、ECUi的部件ID或ECUi的IP地址等。
相应地,KeyM接收来自于ECUi的第一公钥和ECUi的标识信息。
S503:KeyM为ECUi生成第二公钥和第一私钥。
示例性地,KeyM本地执行上述系统参数配置后,KeyM先生成KeyM的私钥和KeyM的公钥,例如,KeyM的私钥KeyM的公钥PKKM=skKMG。
示例性地,KeyM本地执行上述系统参数配置后,KeyM通过下述公式(3)生成第二公钥。
Pi=riG             公式(3)
其中,Pi表示ECUi的第二公钥,ri为随机数,参数G可参考前述叙述,在此不再赘述。公式(3)只作为KeyM为ECUi生成ECUi的第二公钥的一种示例,并不应对KeyM生成该第二公钥的方式构成限定。
一种实现方式中,KeyM为ECUi生成第一私钥,包括:KeyM基于ECUi的第一公钥和ECUi的第二公钥获得ECUi的公钥;KeyM基于ECUi的公钥和ECUi的标识信息获得ECUi的哈希值;KeyM基于KeyM的私钥和ECUi的哈希值,获得ECUi的第一私钥。
示例性地,ECUi的公钥基于ECUi的第一公钥和ECUi的第二公钥获得是指:ECUi的公钥为ECUi的第一公钥与ECUi的第二公钥之和,或者,ECUi的公钥由ECUi的第一公钥与ECUi的第二公钥二者拼接获得。
示例性地,KeyM通过下述公式(4)生成第一私钥。
其中,PKi表示ECUi的公钥,Xi表示ECUi的第一公钥,Pi表示ECUi的第二公钥,hi表示ECUi的哈希值,IDi表示ECUi的标识信息,pi表示ECUi的第一私钥,skKM表示KeyM的私钥,H()、ri、n请参考前述叙述,在此不再赘述。公式(4)只作为KeyM为ECUi生成ECUi的第一公钥的一种示例,并不应对KeyM生成该第一私钥的方式构成限定。
由公式(4)可知,哈希函数以第一部件的标识信息和第一部件的公钥二者作为输入参数,相较于哈希函数以第一部件的标识信息、第一部件的第一公钥和第一部件的第二公钥三者作为输入参数,能提高哈希函数的计算效率。
S504:KeyM向ECUi发送第二公钥、第一私钥和KeyM的公钥。
示例性地,KeyM根据自身生成的第二公钥和来自于ECUi的第一公钥生成ECUi的公钥,并在本地存储ECUi的公钥与ECUi的标识信息之间的对应关系。
S505:ECUi根据第一公钥和第二公钥生成ECUi的公钥,以及根据第一私钥生成ECUi的私钥。
示例性地,ECUi的公钥基于ECUi的第一公钥和ECUi的第二公钥获得是指:ECUi的公钥为ECUi的第一公钥与ECUi的第二公钥之和,或者,ECUi的公钥由ECUi的第一公钥与ECUi的第二公钥二者拼接获得。
一种实现方式中,ECUi根据第一私钥生成ECUi的私钥,包括:ECUi根据ECUi的标识信息和ECUi的公钥获得ECUi的哈希值;ECUi根据第一私钥和ECUi的哈希值获得ECUi的私钥。
这里,ECUi获得ECUi的哈希值时采用的哈希算法与KeyM获得ECUi的哈希值时采用的哈希算法相同,该哈希算法例如为上述H()。
示例性地,ECUi通过下述公式(5)生成ECUi的私钥。
其中,PKi表示ECUi的公钥,Xi表示ECUi的第一公钥,Pi表示ECUi的第二公钥,hi表示ECUi的哈希值,IDi表示ECUi的标识信息,si表示ECUi的私钥,pi表示ECUi的第一私钥,xi请参考公式(2)的相关叙述,在此不再赘述。公式(5)只作为ECUi生成ECUi的私钥的一种示例,并不应对ECUi生成该私钥的方式构成限定。
相应地,ECUi本地保存ECUi的公私钥对,即上述(PKi,si)。
由上述S501-S505可知,KeyM参于了ECUi的公私钥对的生成,ECUi生成ECUi的公钥时使用了KeyM提供的第二公钥,ECUi生成ECUi的私钥时使用了KeyM提供的第一私钥。KeyM参与ECUi的公私钥对的生成能增强双方通信的安全性和可信度。
阶段二:KeyM、ECUi各自本地确定第一会话密钥
KeyM本地确定第一会话密钥,包括:KeyM根据KeyM的私钥、KeyM的公钥、ECUi的哈希值和ECUi的公钥,获得第一会话密钥。
由前述可知,ECUi的公钥是基于ECUi的第一公钥和ECUi的第二公钥,ECUi的哈希值是基于ECUi的公钥和ECUi的标识信息获得,ECUi的第一公钥和ECUi的标识信息均来自于ECUi,ECUi的第二公钥为KeyM为ECUi生成。
示例性地,KeyM通过下述公式(6)确定第一会话密钥。
其中,KMi为KeyM确定的用于与ECUi安全通信的第一会话密钥,skKM为KeyM的私钥,PKKM为KeyM的公钥,hi为ECUi的哈希值,PKi为ECUi的公钥,公式(6)中的其他参数请参考前述公式中相应参数的叙述,在此不再赘述。
ECUi本地确定第一会话密钥,包括:ECUi根据ECUi的私钥和KeyM的公钥,获得第一会话密钥。其中,KeyM的公钥来自于KeyM。
示例性地,ECUi通过下述公式(7)确定第一会话密钥。
KiM=siPKKM            公式(7)
其中,KiM为ECUi确定的用于与KeyM安全通信的第一会话密钥,si为ECUi的私钥,PKKM为KeyM的公钥。
基于上述公式(6)和公式(7),由前述PKKM=skKMG、公式(2)、公式(3)、公式(4)中pi的表达式以及公式(5)中的si的表达式,对公式(6)中的KMi和公式(7)中的KiM分别进行推导,可以知晓KMi=KiM=skKMsiG。
上述公式(6)和公式(7)仅作为KeyM、ECUi各自确定用于KeyM与ECUi二者通信的第一会话密钥的一种示例,也可以采用公式(6)和公式(7)二者变形后的公式确定KeyM与ECUi二者通信的第一会话密钥,无论公式(6)和公式(7)如何变形,满足KeyM本地计算的KMi与ECUi本地计算的KiM相等。
由上述可知,KeyM无需将第一会话密钥传输给ECUi,ECUi可以基于从KeyM获取的信息(即上述第二公钥、第一私钥和KeyM的公钥)在本地生成第一会话密钥,且KeyM确定的第一会话密钥与ECUi本地确定的第一会话密钥相同,如此KeyM和ECUi双方完成了对第一会话密钥的协商,第一会话密钥用于KeyM和ECUi之间后续通信的加密和解密,从而通过第一会话密钥能实现KeyM和ECUi的安全通信。
在一些可能的实施例中,对于车辆内有通信需求的两个部件,例如ECU_A与ECU_B,其中,KeyM既是ECU_A的业务密钥的生成者,也是ECU_B的业务密钥的生成者。ECU_A和ECU_B并不是对应业务密钥的生成者。在此情况下,如ECU_A与ECU_B之间有通信需求,则ECU_A与ECU_B之间也需要协商一个第一会话密钥,该第一会话密钥用于ECU_A与ECU_B的安全通信。ECU_A与ECU_B协商第一会话密钥的过程请参考下述步骤B11-B14。
B11:ECU_A向ECU_B发送ECU_A的公钥和ECU_A的标识信息。
示例性地,ECU_A的公钥为ECU_A采用上述图5实施例所示方法生成。ECU_A的标识信息请参考前述ECUi的标识信息的叙述,在此不再赘述。
B12:ECU_B向ECU_A发送ECU_B的公钥和ECU_B的标识信息。
示例性地,ECU_B的公钥为ECU_B采用上述图5实施例所示方法生成。ECU_B的标识信息请参考前述ECUi的标识信息的叙述,在此不再赘述。
B13:ECU_A根据ECU_A的私钥、KeyM的公钥、ECU_B的哈希值和ECU_B的公钥,生成第一会话密钥。其中,ECU_B的哈希值是ECU_A基于ECU_B的公钥和ECU_B的标识信息获得。
示例性地,ECU_A通过下述公式(8)确定第一会话密钥。
其中,hB为ECU_B的哈希值,IDB为ECU_B的标识信息,PKB为ECU_B的公钥,KAB为ECU_A确定的用于与ECU_B安全通信的第一会话密钥,sA为ECU_A的私钥,PKKM为KeyM的公钥。
B14:ECU_B根据ECU_B的私钥、KeyM的公钥、ECU_A的哈希值和ECU_A的公钥,生成第一会话密钥。其中,ECU_A的哈希值是ECU_B基于ECU_A的公钥和ECU_A的标识信息获得。
示例性地,ECU_B通过下述公式(9)确定第一会话密钥。
其中,hA为ECU_A的哈希值,IDA为ECU_A的标识信息,PKA为ECU_A的公钥,KBA为ECU_B确定的用于与ECU_A安全通信的第一会话密钥,sB为ECU_B的私钥,PKLM为KeyM的公钥。
上述公式(8)中生成hB时使用的哈希算法与上述公式(9)中生成hA时使用的哈希算法相同。基于上述公式(6)中KMi相同的推导方式,对公式(8)中的KAB和公式(9)中的KBA分别进行推导,可以知晓KAB=KBA=sAsBG。
上述公式(8)和公式(9)仅作为ECU_A、ECU_B各自确定用于ECU_A与ECU_B二者通信的第一会话密钥的一种示例,也可以采用公式(8)和公式(9)二者变形后的公式确定ECU_A与ECU_B二者通信的第一会话密钥,无论公式(8)和公式(9)如何变形,满足ECU_A本地计算的KAB与ECU_B本地计算的KBA相等。
在一些可能的实施例中,对于车辆内有通信需求的两个部件(例如ECU_A与ECU_B),ECU_A的业务密钥的生成者与ECU_B的业务密钥的生成者也可能不同,例如ECU_A的业务密钥由生成部件1生成而ECU_B的业务密钥由生成部件2生成,则ECU_A与ECU_B也可通过前述B11-B14所示方法各自本地协商会话密钥,在此情况下,生成部件1辅助ECU_A生成ECU_A的公私钥对时使用的KeyM的公私钥对,与生成部件2辅助ECU_B生成ECU_B的公私钥对时使用的KeyM的公私钥对相同。
情况3:第一部件属于上述第三类部件
即第一部件的设备能力不具备安全存储能力。进一步地,第一部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
在情况3下,一种实现方式中,生成部件基于第一部件的设备能力,确定第一会话密钥,包括:基于预密钥和第一部件的标识信息生成根密钥,生成部件将根密钥作为第一会话密钥。这里,预密钥、根密钥请参考前述S301中根密钥的相关叙述,在此不再赘述。
示例性地,主密钥来源于网络侧设备,或者,主密钥由生成部件生成。
在情况3下,另一种实现方式中,生成部件基于第一部件的设备能力,确定第一会话密钥,包括:生成部件将主密钥作为第一会话密钥。
进一步地,在情况3下,生成部件还基于该第一会话密钥生成解密白盒代码,生成部件向第一部件发送解密白盒代码,其中,解密白盒代码包括第一会话密钥,解密白盒代码用于第一部件解析获得第一部件的业务密钥。
示例性地,基于第一会话密钥生成解密白盒代码,包括:基于第一会话密钥和白盒算法生成解密白盒代码,解密白盒代码为混合了第一会话密钥后的白盒算法。这里的“混合”例如理解为第一会话密钥本身作为一个整体被插入白盒算法中,或者,第一会话密钥被拆分为多个部分并随机地插入白盒算法中。
混合方式例如是采用内部混淆技术将第一会话密钥和白盒算法进行混合,或者采用代数技术和变换将第一会话密钥和白盒算法的执行过程进行混合等方式,在此不作具体限定。白盒算法例如是动态白盒算法或静态白盒算法。
在第一部件不具备安全存储能力时,通过将第一会话密钥和算法代码进行混淆,将混淆后获得的解密白盒代码发送给第一部件,第一部件本地不生成第一会话密钥而是通过解密白盒代码来解密,通过解密白盒代码实现了第一会话密钥的安全存储,如此增加了攻击者获取第一会话密钥的难度,即使第一部件不具备安全存储能力,也提高了密钥的安全性。
示例性地,生成部件通过OTA升级通道向第一部件发送解密白盒代码。也就是说,解密白盒代码承载于OTA消息中。
S303:生成部件使用第一会话密钥加密第一部件的业务密钥,获得第一目标密钥。
使用第一会话密钥对第一部件的业务密钥进行加密,保护了业务密钥的私密性和完整性。通过第一会话密钥有助于实现第一部件的业务密钥的安全分发,提高了密钥的安全性。
S304:生成部件向第一部件发送第一目标密钥。
S305:第一部件基于第一部件的设备能力解析第一目标密钥,获得第一部件的业务密钥。
一种实现方式,第一部件的设备能力包括支持数字证书且支持非对称硬件加速(即第一部件属于上述第一类部件),第一部件基于第一部件的设备能力解析第一目标密钥,获得第一部件的业务密钥,包括:第一部件使用本地的第一会话密钥解密第一目标密钥,获得第一部件的业务密钥。第一部件本地的第一会话密钥例如是前述S402中“情况1”下描述的预主密钥。
一种实现方式中,第一部件的设备能力包括具备安全存储能力(即第一部件属于上述第二类部件),第一部件基于第一部件的设备能力解析第一目标密钥,获得第一部件的业务密钥,包括:第一部件根据第一部件的私钥和生成部件的公钥,获得第一会话密钥;第一部件使用第一会话密钥解密第一目标密钥,获得第一部件的业务密钥。进一步地,该实现方式中,第一部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
其中,第一部件的私钥是基于第一私钥和第一部件的哈希值获得,第一部件的哈希值是对第一部件的标识信息和第一部件的公钥进行哈希运算获得,第一部件的公钥是基于第一公钥和第二公钥获得,第一公钥由第一部件生成,第二公钥、第一私钥与第一部件对应,第一私钥、第二公钥和生成部件的公钥来自于生成部件,第一私钥与生成部件的私钥和第一部件的哈希值关联。第一部件的公私钥对(即第一部件的公钥和第一部件的私钥)的生成例如请参考前述图5实施例的相关叙述,在此不再赘述。
一种实现方式中,第一部件的设备能力不包括安全存储能力(即第一部件属于上述第三类部件),第一部件还接收来自于生成部件的解密白盒代码,第一部件基于第一部件的设备能力解析第一目标密钥,获得第一部件的业务密钥,包括:本地刷写解密白盒代码;使用解密白盒代码解析第一目标密钥,获得第一部件的业务密钥。进一步地,该实现方式中,第一部件的设备能力还满足不支持数字证书和不支持非对称硬件加速中的至少一项。
其中,解密白盒代码与第一会话密钥关联,第一会话密钥与第一部件的标识信息关联,第一部件的业务密钥与第一会话密钥和第一部件的标识信息关联。解密白盒代码以及第一会话密钥请参考前述S402中“情况3”的相关叙述,第一部件的业务密钥的生成请参考前述S301中相应内容的叙述。
上述实施例中示出了生成部件生成第一部件的业务密钥以及生成部件安全分发第一部件的业务密钥的过程。在一些可能的实施例中,生成部件能负责多个部件的业务密钥的生成与安全分发。
作为一种示例,生成部件生成第二部件的业务密钥;生成部件基于第二部件的设备能力,确定第二会话密钥;生成部件使用第二会话密钥对第二部件的业务密钥执行加密,获得第二目标密钥;生成部件向第二部件发送第二目标密钥。相应地,第二部件接收第二目标密钥,并基于第二部件的设备能力解析第二目标密钥,获得第二部件的业务密钥。第二部件的业务密钥的生成过程请参考前述第一部件的业务密钥的生成过程的叙述,第二会话密钥的生成过程请参考前述第一会话密钥的生成过程的叙述,在此不再赘述。
其中,第一会话密钥与第一部件的设备能力对应,第二会话密钥与第二部件的设备能力对应,若第一部件的设备能力与第二部件的设备能力不同(例如第一部件所属的部件类型与第二部件所属的部件类型不同),则第一会话密钥与第二会话密钥也不同。
在一些可能的实施例中,针对属于同一部件类型的不同部件,若第一部件和第二部件均属于上述第二类部件,针对于第二类部件,会话密钥的生成不仅与部件的设备能力有关,会话密钥的生成还与部件的标识信息有关,而第一部件的标识信息与第二部件的标识信息不同,故第一会话密钥与第二会话密钥也不同。因此,不同的部件也对应有不同的会话密钥。
上述图4实施例,部件的业务密钥的生成方能够为车辆的每个部件确定一个会话密钥,并使用部件对应的会话密钥将该部件的业务密钥加密传输至对应部件。该生成方基于部件的设备能力确定用于该会话密钥,部件的设备能力用于描述设备的安全特性,有利于提高密钥分发的安全性。部件的设备能力不同,部件对应的会话密钥不同。相较于当前产线密钥灌装流程,车辆内的所有部件不再共用一个会话密钥,不同部件的业务密钥通过不同的会话密钥加密传输,有利于降低密钥的暴露风险,提高密钥传输的安全性。另外,部件的业务密钥的生成以及会话密钥的生成均在车内执行,实现了密钥不出车,也有利于提高车内密钥的分发效率。
参见图6,图6是本申请实施例提供的一种密钥生成装置的结构示意图,密钥生成装置30包括获取单元310、处理单元312和发送单元314。该密钥生成装置30可以通过硬件、软件或者软硬件结合的方式来实现。
其中,获取单元310,用于获取第一部件的第一设备能力,第一设备能力用于表示第一部件的安全特性;发送单元314,用于向第一部件发送第一目标密钥,第一目标密钥是通过处理单元312使用第一会话密钥对第一部件的业务密钥进行加密生成,第一会话密钥与第一设备能力对应。在一些可能的实施例中,获取单元310还用于获取第二部件的第二设备能力,第二设备能力用于表示第二部件的安全特性;发送单元314,还用于向第二部件发送第二目标密钥,第二目标密钥是通过处理单元312使用第二会话密钥对第二部件的业务密钥进行加密生成,第二会话密钥与第二设备能力对应。其中,第一设备能力不同于第二设备能力时,第一会话密钥不同于第二会话密钥。
该密钥生成装置30例如用于实现图3实施例所描述的生成部件侧的方法。在图3实施例中,获取单元310和处理单元312用于执行S301-S303,发送单元314可用于执行S304。
在一些可能的实施例中,该密钥生成装置30还用于实现图4实施例所描述的生成部件侧的方法以及图5实施例所描述的KeyM侧的方法,为了说明书的简洁,在此不再赘述。
参见图7,图7是本申请实施例提供的一种密钥解析装置的结构示意图,密钥解析装置40包括接收单元410和处理单元412。该密钥解析装置40可以通过硬件、软件或者软硬件结合的方式来实现。
其中,接收单元410,用于接收生成部件发送的目标密钥,该目标密钥为第一部件的业务密钥经会话密钥加密后的密钥;处理单元412,用于基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥;其中,第一部件的设备能力用于表示第一部件的安全特性。
该密钥解析装置40例如用于实现图3实施例所描述的第一部件侧的方法。在图3实施例中,接收单元410用于执行S304,处理单元412用于执行S305。
在一些可能的实施例中,该密钥解析装置40还用于实现图4实施例所描述的第一部件侧的方法以及图5实施例所描述的ECUi侧的方法,为了说明书的简洁,在此不再赘述。
应理解,以上装置(例如密钥生成装置30和密钥解析装置40)中各单元的划分仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。此外,装置中的单元可以以处理器调用软件的形式实现;例如装置包括处理器,处理器与存储器连接,存储器中存储有指令,处理器调用存储器中存储的指令,以实现以上任一种方法或实现该装置各单元的功能,其中处理器例如为通用处理器,例如中央处理单元(central processing unit,CPU)或微处理器,存储器为装置内的存储器或装置外的存储器。或者,装置中的单元可以以硬件电路的形式实现,可以通过对硬件电路的设计实现部分或全部单元的功能,该硬件电路可以理解为一个或多个处理器;例如,在一种实现中,该硬件电路为专用集成电路(application-specific integrated circuit,ASIC),通过对电路内元件逻辑关系的设计,实现以上部分或全部单元的功能;再如,在另一种实现中,该硬件电路为可以通过可编程逻辑器件(programmable logic device,PLD)实现,以现场可编程门阵列(field programmable gate array,FPGA)为例,其可以包括大量逻辑门电路,通过配置文件来配置逻辑门电路之间的连接关系,从而实现以上部分或全部单元的功能。以上装置的所有单元可以全部通过处理器调用软件的形式实现,或全部通过硬件电路的形式实现,或部分通过处理器调用软件的形式实现,剩余部分通过硬件电路的形式实现。
在本申请实施例中,处理器是一种具有信号的处理能力的电路,在一种实现中,处理器可以是具有指令读取与运行能力的电路,例如中央处理单元(central processing unit,CPU)、微处理器、图形处理器(graphics processing unit,GPU)(可以理解为一种微处理器)、或数字信号处理器(digital signal processor,DSP)等;在另一种实现中,处理器可以通过硬件电路的逻辑关系实现一定功能,该硬件电路的逻辑关系是固定的或可以重构的,例如处理器为专用集成电路(application-specific integrated circuit,ASIC)或可编程逻辑器件(programmable logic device,PLD)实现的硬件电路,例如FPGA。在可重构的硬件电路中,处理器加载配置文档,实现硬件电路配置的过程,可以理解为处理器加载指令,以实现以上部分或全部单元的功能的过程。此外,还可以是针对人工智能设计的硬件电路,其可以理解为一种ASIC,例如神经网络处理单元(neural network processing unit,NPU)张量处理单元(tensor processing unit,TPU)、深度学习处理单元(deep learning processing unit,DPU)等。
可见,以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路),例如:CPU、GPU、NPU、TPU、DPU、微处理器、DSP、ASIC、FPGA,或这些处理器形式中至少两种的组合。
此外,以上装置中的各单元可以全部或部分可以集成在一起,或者可以独立实现。在一种实现中,这些单元集成在一起,以片上系统(system-on-a-chip,SOC)的形式实现。该SOC中可以包括至少一个处理器,用于实现以上任一种方法或实现该装置各单元的功能,该至少一个处理器的种类可以不同,例如包括CPU和FPGA,CPU和人工智能处理器,CPU和GPU等。
参见图8,图8是本申请实施例提供的一种密钥处理设备的结构示意图。如图8所示,密钥处理设备50包括:处理器501、通信接口502、存储器503和总线504。处理器501、存储器503和通信接口502之间通过总线504通信。应理解,本申请不限定密钥处理设备50中的处理器、存储器的个数。
一种实现方式中,密钥处理设备50是网络侧设备,网络侧设备例如是计算设备、计算设备集群或者终端设备。网络侧设备可以部署在云环境中,也可以部署在边缘环境中。网络侧设备具体请参考图1中网络侧设备20的相关叙述,在此不再赘述。
一种实现方式中,密钥处理设备50为终端或者为终端内的部件。以终端为车辆为例,该车辆内的部件例如是域控制器DC、整车集成单元VIU、电子控制单元ECU或远程信息处理器TBox。在一些可能的实施例中,密钥处理设备50还可以是部件内的组件,该组件例如是芯片或集成电路等。终端请参考图1中终端10的相关叙述,在此不再赘述。
总线504可以是外设部件互连标准(peripheral component interconnect,PCI)总线或扩展工业标准结构(extended industry standard architecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条线表示,但并不表示仅有一根总线或一种类型的总线。总线504可包括在密钥处理设备50各个部件(例如,存储器503、处理器501、通信接口502)之间传送信息的通路。
处理器501可参考上述实施例中对处理器的相关描述,在此不再赘述。
存储器503用于提供存储空间,存储空间中可以存储操作系统和计算机程序等数据。存储器503可以是随机存取存储器(random access memory,RAM)、可擦除可编程只读存储器(erasable programmable read only memory,EPROM)、只读存储器(read-only memory,ROM),或便携式只读存储器(compact disc read memory,CD-ROM)等中的一种或者多种的组合。存储器503可以单独存在,也可以集成于处理器501内部。
通信接口502可用于为处理器501提供信息输入或输出。或者可替换的,该通信接口502可用于接收外部发送的数据和/或向外部发送数据,可以为包括诸如以太网电缆等的有线链路接口,也可以是无线链路(如Wi-Fi、蓝牙、通用无线传输等)接口。或者可替换的,通信接口502还可以包括与接口耦合的发射器(如射频发射器、天线等),或者接收器等。
该密钥处理设备50中的处理器501用于读取存储器503中存储的计算机程序,用于执行前述的方法,例如图3、图4或图5所描述的任一侧的方法。
在一种可能的设计方式中,密钥处理设备50可为执行图3所示方法的执行主体(例如生成部件)中的一个或多个模块,该处理器501可用于读取存储器中存储的一个或多个计算机程序,用于执行以下操作:
通过获取单元310获取第一部件的第一设备能力,第一设备能力用于表示第一部件的安全特性;
通过发送单元314向第一部件发送第一目标密钥,第一目标密钥是使用第一会话密钥对第一部件的业务密钥进行加密生成;
通过获取单元310获取第二部件的第二设备能力,第二设备能力用于表示第二部件的安全特性;
通过发送单元314向第二部件发送第二目标密钥,第二目标密钥是使用第二会话密钥对第二部件的业务密钥进行加密生成;
其中,第一设备能力对应第一会话密钥,第二设备能力对应第二会话密钥,第一设备能力不同于第二设备能力,第一会话密钥不同于第二会话密钥。上述第一部件的业务密钥、第一会话密钥、第二部件的业务密钥、第二会话密钥是通过处理单元312生成。
在一种可能的设计方式中,密钥处理设备50可为执行图3所示方法的执行主体(例如第一部件)中的一个或多个模块,该处理器501可用于读取存储器中存储的一个或多个计算机程序,用于执行以下操作:
通过接收单元410接收生成部件发送的目标密钥,目标密钥为第一部件的业务密钥经会话密钥加密后的密钥;
基于第一部件的设备能力解析目标密钥,获得第一部件的业务密钥;其中,第一部件的设备能力用于表示第一部件的安全特性。
在本文上述的实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详细描述的部分,可以参见其他实施例的相关描述。另外,在本申请的各个实施例中,如果没有特殊说明以及逻辑冲突,各个实施例之间的术语和/或描述具有一致性、且可以相互引用,不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。
需要说明的是,本领域普通技术人员可以看到上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质包括只读存储器(read-only memory,ROM)、随机存储器(random access memory,RAM)、可编程只读存储器(programmable read-only memory,PROM)、可擦除可编程只读存储器(erasable programmable read only memory,EPROM)、一次可编程只读存储器(one-time programmable read-only memory,OTPROM)、电子抹除式可复写只读存储(electrically-erasable programmable read-only memory,EEPROM)、只读光盘(compact disc read-only memory,CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。
本申请的技术方案本质上或者说做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机程序产品存储在一个存储介质中,包括若干指令用以使得一个设备(可以是个人计算机,服务器,或者网络设备、机器人、单片机、芯片、机器人等)执行本申请各个实施例所述方法的全部或部分步骤。

Claims (31)

  1. 一种密钥分发方法,其特征在于,应用于生成部件,所述方法包括:
    获取第一部件的第一设备能力,所述第一设备能力用于表示所述第一部件的安全特性;
    向所述第一部件发送第一目标密钥,其中,所述第一目标密钥是使用第一会话密钥对所述第一部件的业务密钥进行加密生成;
    获取第二部件的第二设备能力,所述第二设备能力用于表示所述第二部件的安全特性;
    向所述第二部件发送第二目标密钥,其中,所述第二目标密钥是使用第二会话密钥对所述第二部件的业务密钥进行加密生成;
    其中,所述第一设备能力对应所述第一会话密钥,所述第二设备能力对应所述第二会话密钥,所述第一设备能力不同于所述第二设备能力,所述第一会话密钥不同于所述第二会话密钥。
  2. 根据权利要求1所述的方法,其特征在于,所述生成部件、所述第一部件和所述第二部件部署在车辆内。
  3. 根据权利要求2所述的方法,其特征在于,所述生成部件为所述车辆内密钥管理模块所在的部件,和/或,所述第一部件和所述第二部件分别下挂于所述生成部件。
  4. 根据权利要求1-3任一项所述的方法,其特征在于,所述向所述第一部件发送第一目标密钥之前,所述方法还包括:
    基于所述第一设备能力,确定所述第一会话密钥,所述第一会话密钥用于所述生成部件与所述第一部件的安全通信;
    生成所述第一部件的业务密钥;
    使用所述第一会话密钥对所述第一部件的业务密钥进行加密,获得所述第一目标密钥。
  5. 根据权利要求4所述的方法,其特征在于,
    基于所述第一设备能力,确定所述第一会话密钥,包括:
    所述第一设备能力包括安全存储能力,接收所述第一部件发送的第一公钥和所述第一部件的标识信息;
    根据所述第一部件的公钥、所述第一部件的哈希值、所述生成部件的公钥和所述生成部件的私钥,获得所述第一会话密钥;
    其中,所述生成部件的公钥与所述生成部件的私钥对应,所述第一部件的公钥是基于所述第一公钥和第二公钥获得,所述第二公钥为所述生成部件为所述第一部件生成,所述第一部件的哈希值是对所述第一部件的标识信息和所述第一部件的公钥进行哈希运算获得。
  6. 根据权利要求5所述的方法,其特征在于,所述方法还包括:
    向所述第一部件发送所述第二公钥、第一私钥和所述生成部件的公钥,所述第二公钥用于生成所述第一部件的公钥,所述第一私钥用于生成所述第一部件的私钥,所述生成部件的公钥用于所述第一部件解析所述第一目标密钥。
  7. 根据权利要求4所述的方法,其特征在于,所述生成部件为所述车辆内密钥管理模块所在的部件,
    基于所述第一设备能力,确定所述第一会话密钥,包括:
    所述第一设备能力不包括安全存储能力,根据所述第一部件的标识信息和主密钥生成所述第一会话密钥,所述主密钥由所述生成部件生成或来自于网络侧设备;
    所述生成所述第一部件的业务密钥,包括:
    根据所述第一部件的标识信息和所述第一会话密钥生成所述第一部件的业务密钥;
    所述方法还包括:
    基于所述第一会话密钥生成解密白盒代码,所述解密白盒代码包括所述第一会话密钥,所述解密白盒代码用于将所述第一目标密钥还原为所述第一部件的业务密钥;
    向所述第一部件发送所述解密白盒代码。
  8. 根据权利要求1-7任一项所述的方法,其特征在于,所述生成部件包括第一生成部件和第二生成部件,所述第一部件下挂于所述第一生成部件,所述第二部件下挂于所述第二生成部件,
    所述获取第一部件的第一设备能力以及所述向所述第一部件发送第一目标密钥由所述第一生成部件执行,所述第一会话密钥、所述第一部件的业务密钥以及所述第一目标密钥由所述第一生成部件生成;
    所述获取第二部件的第二设备能力以及所述向所述第二部件发送第二目标密钥由所述第二生成部件执行,所述第二会话密钥、所述第二部件的业务密钥以及所述第二目标密钥由所述第二生成部件生成。
  9. 一种密钥解析方法,其特征在于,应用于第一部件,所述方法包括:
    接收生成部件发送的目标密钥,所述目标密钥为所述第一部件的业务密钥经会话密钥加密后的密钥;
    基于所述第一部件的设备能力解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的设备能力用于表示所述第一部件的安全特性。
  10. 根据权利要求9所述的方法,其特征在于,所述第一部件和所述生成部件部署在车辆内。
  11. 根据权利要求10所述的方法,其特征在于,所述生成部件为所述车辆内的密钥管理模块所在的部件,和/或,所述第一部件下挂于所述生成部件。
  12. 根据权利要求9-11任一项所述的方法,其特征在于,
    所述基于所述第一部件的设备能力解析所述目标密钥,获得所述第一部件的业务密钥,包括:
    所述第一部件的设备能力包括安全存储能力,根据所述第一部件的私钥和所述生成部件的公钥,获得所述会话密钥;
    使用所述会话密钥解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的私钥是基于第一私钥和所述第一部件的哈希值获得,所述第一部件的哈希值是对所述第一部件的标识信息和所述第一部件的公钥进行哈希运算获得,所述第一部件的公钥是基于第一公钥和第二公钥获得,所述第一公钥由所述第一部件生成,所述第二公钥、所述第一私钥与所述第一部件对应,所述第一私钥、所述第二公钥和所述生成部件的公钥来自于所述生成部件,所述第一私钥与所述第一部件的私钥和所述第一部件的哈希值关联。
  13. 根据权利要求9-11任一项所述的方法,其特征在于,
    所述基于所述第一部件的设备能力解析所述目标密钥,获得所述第一部件的业务密钥,包括:
    所述第一部件的设备能力不包括安全存储能力,本地刷写解密白盒代码,所述解密白盒代码来自于所述生成部件,所述解密白盒代码包括所述会话密钥;
    使用所述解密白盒代码解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的业务密钥与所述会话密钥和所述第一部件的标识信息关联,所述会话密钥与所述第一部件的标识信息关联。
  14. 一种密钥分发装置,其特征在于,该装置为生成部件,所述装置包括:
    获取单元,用于获取第一部件的第一设备能力,所述第一设备能力用于表示所述第一部件的安全特性;
    发送单元,用于向所述第一部件发送第一目标密钥,其中,所述第一目标密钥是通过处理单元使用第一会话密钥对所述第一部件的业务密钥进行加密生成;
    所述获取单元,还用于获取第二部件的第二设备能力,所述第二设备能力用于表示所述第二部件的安全特性;
    所述发送单元,还用于向所述第二部件发送第二目标密钥,其中,所述第二目标密钥是通过所述处理单元使用第二会话密钥对所述第二部件的业务密钥进行加密生成;
    其中,所述第一设备能力对应所述第一会话密钥,所述第二设备能力对应所述第二会话密钥,所述第一设备能力不同于所述第二设备能力,所述第一会话密钥不同于所述第二会话密钥。
  15. 根据权利要求14所述的装置,其特征在于,所述生成部件、所述第一部件和所述第二部件部署在车辆内。
  16. 根据权利要求15所述的装置,其特征在于,所述生成部件为所述车辆内密钥管理模块所在的部件,和/或,所述第一部件和所述第二部件分别下挂于所述生成部件。
  17. 根据权利要求14-16任一项所述的装置,其特征在于,所述处理单元用于:
    基于所述第一设备能力,确定所述第一会话密钥,所述第一会话密钥用于所述生成部件与所述第一部件的安全通信;
    生成所述第一部件的业务密钥;
    使用所述第一会话密钥对所述第一部件的业务密钥进行加密,获得所述第一目标密钥。
  18. 根据权利要求17所述的装置,其特征在于,所述处理单元具体用于:
    所述第一设备能力包括安全存储能力,接收所述第一部件发送的第一公钥和所述第一部件的标识信息;
    根据所述第一部件的公钥、所述第一部件的哈希值、所述生成部件的公钥和所述生成部件的私钥,获得所述第一会话密钥;
    其中,所述生成部件的公钥与所述生成部件的私钥对应,所述第一部件的公钥是基于所述第一公钥和第二公钥获得,所述第二公钥为所述生成部件为所述第一部件生成,所述第一部件的哈希值是对所述第一部件的标识信息和所述第一部件的公钥进行哈希运算获得。
  19. 根据权利要求18所述的装置,其特征在于,所述发送单元还用于:
    向所述第一部件发送所述第二公钥、第一私钥和所述生成部件的公钥,所述第二公钥用于生成所述第一部件的公钥,所述第一私钥用于生成所述第一部件的私钥,所述生成部件的公钥用于所述第一部件解析所述第一目标密钥。
  20. 根据权利要求17所述的装置,其特征在于,所述生成部件为所述车辆内密钥管理模块所在的部件,所述处理单元具体用于:
    所述第一设备能力不包括安全存储能力,根据所述第一部件的标识信息和主密钥生成所述第一会话密钥,所述主密钥由所述生成部件生成或来自于网络侧设备;
    根据所述第一部件的标识信息和所述第一会话密钥生成所述第一部件的业务密钥;
    基于所述第一会话密钥生成解密白盒代码,所述解密白盒代码包括所述第一会话密钥,所述解密白盒代码用于将所述第一目标密钥还原为所述第一部件的业务密钥;
    所述发送单元,还用于向所述第一部件发送所述解密白盒代码。
  21. 根据权利要求14-20任一项所述的装置,其特征在于,所述生成部件包括第一生成部件和第二生成部件,所述第一部件下挂于所述第一生成部件,所述第二部件下挂于所述第二生成部件,所述获取单元包括所述第一生成部件的第一获取单元和所述第二生成部件的第二获取单元,所述发送单元包括所述第一生成部件的第一发送单元和所述第二生成部件的第二发送单元;
    所述第一获取单元,用于获取所述第一部件的所述第一设备能力;
    所述第一发送单元,用于向所述第一部件发送所述第一目标密钥;
    所述第二获取单元,用于获取所述第二部件的所述第二设备能力;
    所述第二发送单元,用于向所述第二部件发送所述第二目标密钥;
    所述处理单元包括所述第一生成部件的第一处理单元和所述第二生成部件的第二处理单元,其中,
    所述第一会话密钥、所述第一部件的业务密钥以及所述第一目标密钥由所述第一处理单元生成;
    所述第二会话密钥、所述第二部件的业务密钥以及所述第二目标密钥由所述第二处理单元生成。
  22. 一种密钥解析装置,其特征在于,所述装置为第一部件,所述装置包括:
    接收单元,用于接收生成部件发送的目标密钥,所述目标密钥为所述第一部件的业务密钥经会话密钥加密后的密钥;
    处理单元,用于基于所述第一部件的设备能力解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的设备能力用于表示所述第一部件的安全特性。
  23. 根据权利要求22所述的装置,其特征在于,所述第一部件和所述生成部件部署在车辆内。
  24. 根据权利要求23所述的装置,其特征在于,所述生成部件为所述车辆内的密钥管理模块所在的部件,和/或,所述第一部件下挂于所述生成部件。
  25. 根据权利要求22-24任一项所述的装置,其特征在于,所述处理单元具体用于:
    所述第一部件的设备能力包括安全存储能力,根据所述第一部件的私钥和所述生成部件的公钥,获得所述会话密钥;
    使用所述会话密钥解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的私钥是所述处理单元基于第一私钥和所述第一部件的哈希值获得,所述第一部件的哈希值是所述处理单元对所述第一部件的标识信息和所述第一部件的公钥进行哈希运算获得,所述第一部件的公钥是所述处理单元基于第一公钥和第二公钥获得,所述第一公钥由所述第一部件生成,所述第二公钥、所述第一私钥与所述第一部件对应,所述第一私钥、所述第二公钥和所述生成部件的公钥来自于所述生成部件,所述第一私钥与所述第一部件的私钥和所述第一部件的哈希值关联。
  26. 根据权利要求22-24任一项所述的装置,其特征在于,所述处理单元具体用于:
    所述第一部件的设备能力不包括安全存储能力,本地刷写解密白盒代码,所述解密白盒代码来自于所述生成部件,所述解密白盒代码包括所述会话密钥;
    使用所述解密白盒代码解析所述目标密钥,获得所述第一部件的业务密钥;
    其中,所述第一部件的业务密钥与所述会话密钥和所述第一部件的标识信息关联,所述会话密钥与所述第一部件的标识信息关联。
  27. 一种芯片,其特征在于,所述芯片包括存储器和至少一个处理器,所述存储器存储计算机程序指令,所述至少一个处理器运行所述计算机程序指令以使所述芯片执行如权利要求1-8任一项所述的方法。
  28. 一种电子控制单元,其特征在于,所述芯片包括存储器和至少一个处理器,所述存储器存储计算机程序指令,所述至少一个处理器运行所述计算机程序指令以使所述芯片执行如权利要求9-13任一项所述的方法。
  29. 一种密钥分发系统,其特征在于,所述系统包括第一装置和第二装置,其中,所述第一装置用于实现如权利要求1-8任一项所述的方法,所述第二装置用于实现如权利要求9-13任一项所述的方法。
  30. 一种车辆,其特征在于,所述车辆包括如权利要求14-28任一项所述的装置,或者包括如权利要求29所述的系统。
  31. 一种计算机可读存储介质,其特征在于,包括计算机指令,当所述计算机指令在被处理器运行时,实现如权利要求1-8任一项所述的方法,或者,实现如权利要求9-13任一项所述的方法。
PCT/CN2025/084219 2024-03-28 2025-03-21 一种密钥分发、解析方法及装置 Pending WO2025201215A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410374621.XA CN120768535A (zh) 2024-03-28 2024-03-28 一种密钥分发、解析方法及装置
CN202410374621.X 2024-03-28

Publications (1)

Publication Number Publication Date
WO2025201215A1 true WO2025201215A1 (zh) 2025-10-02

Family

ID=97217822

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/084219 Pending WO2025201215A1 (zh) 2024-03-28 2025-03-21 一种密钥分发、解析方法及装置

Country Status (2)

Country Link
CN (1) CN120768535A (zh)
WO (1) WO2025201215A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050204139A1 (en) * 2004-03-10 2005-09-15 Helland Patrick J. Service broker security
WO2018000936A1 (zh) * 2016-07-01 2018-01-04 华为技术有限公司 密钥配置及安全策略确定方法、装置
CN109150835A (zh) * 2018-07-20 2019-01-04 国科量子通信网络有限公司 云端数据存取的方法、装置、设备及计算机可读存储介质
CN112740212A (zh) * 2020-12-24 2021-04-30 华为技术有限公司 密钥写入方法及装置
CN114244505A (zh) * 2021-12-09 2022-03-25 武汉天喻信息产业股份有限公司 一种基于安全芯片的安全通信方法
CN115866570A (zh) * 2022-11-03 2023-03-28 芜湖雄狮汽车科技有限公司 车载nfc卡片钥匙的离线绑定方法、装置、车辆及介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050204139A1 (en) * 2004-03-10 2005-09-15 Helland Patrick J. Service broker security
WO2018000936A1 (zh) * 2016-07-01 2018-01-04 华为技术有限公司 密钥配置及安全策略确定方法、装置
CN109150835A (zh) * 2018-07-20 2019-01-04 国科量子通信网络有限公司 云端数据存取的方法、装置、设备及计算机可读存储介质
CN112740212A (zh) * 2020-12-24 2021-04-30 华为技术有限公司 密钥写入方法及装置
CN114244505A (zh) * 2021-12-09 2022-03-25 武汉天喻信息产业股份有限公司 一种基于安全芯片的安全通信方法
CN115866570A (zh) * 2022-11-03 2023-03-28 芜湖雄狮汽车科技有限公司 车载nfc卡片钥匙的离线绑定方法、装置、车辆及介质

Also Published As

Publication number Publication date
CN120768535A (zh) 2025-10-10

Similar Documents

Publication Publication Date Title
JP7626911B2 (ja) 車両のアップグレードパッケージを処理するための方法および装置
CN112585905B (zh) 一种设备升级方法及相关设备
CN112913189B (zh) 一种ota升级方法及装置
US12190737B2 (en) Cryptography-based platooning mechanism for autonomous vehicle fleet management
CN112543927B (zh) 一种设备升级方法及相关设备
CN113132098B (zh) 面向大规模车内网络的可扩展can总线安全通信方法及装置
CN112689982B (zh) 数据验证方法、装置及存储介质
CN104717071B (zh) 公路列车数据认证鉴权方法及车载终端
CN111049803A (zh) 基于车载can总线通讯系统数据加密及平台安全访问的方法
CN112913209A (zh) 一种服务授权管理方法及装置
CN112655184A (zh) 一种安全保护方法、设备以及存储介质
CN112448813A (zh) 用于根据密钥推导模型产生加密密钥的方法和装置及车辆
WO2024032438A1 (zh) 车辆安全访问方法、系统及相关装置
CN116800531A (zh) 一种汽车电子电气架构及安全通信方法
KR102944254B1 (ko) 오토모티브 이더넷 기반 차량 내부 네트워크 데이터 통신 장치 및 방법
WO2025201215A1 (zh) 一种密钥分发、解析方法及装置
US20220006804A1 (en) Gateway and proxy for vehicle head unit certificate validation
JP7763947B2 (ja) 鍵伝送方法及び装置
CN115499190A (zh) 车辆密钥管理方法、安全服务设备、密钥管理系统
EP4561000A1 (en) Communication method and apparatus, and system
EP4629560A1 (en) Communication method, node, communication system, and mobile carrier
Andreica et al. Enhanced security functionalities with android devices inside vehicles
CN119584127A (zh) 一种车辆信息认证系统及方法

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: 25779419

Country of ref document: EP

Kind code of ref document: A1