WO2022042298A1 - 车载设备的控制方法、车载设备及车辆系统 - Google Patents

车载设备的控制方法、车载设备及车辆系统 Download PDF

Info

Publication number
WO2022042298A1
WO2022042298A1 PCT/CN2021/111911 CN2021111911W WO2022042298A1 WO 2022042298 A1 WO2022042298 A1 WO 2022042298A1 CN 2021111911 W CN2021111911 W CN 2021111911W WO 2022042298 A1 WO2022042298 A1 WO 2022042298A1
Authority
WO
WIPO (PCT)
Prior art keywords
ecu
digital certificate
function
certificate
vehicle
Prior art date
Application number
PCT/CN2021/111911
Other languages
English (en)
French (fr)
Inventor
廖作鹏
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21860137.5A priority Critical patent/EP4195078A4/en
Priority to US18/043,229 priority patent/US20240028692A1/en
Publication of WO2022042298A1 publication Critical patent/WO2022042298A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the embodiments of the present application relate to the field of communication and information security, and in particular, to a control method of an in-vehicle device, an in-vehicle device, and a vehicle system.
  • ECUs electronice control units
  • the vehicle system adopts the symmetric key technology to realize the security authentication between ECUs.
  • the same symmetric key is stored between the two ECUs.
  • one ECU sends a random number to another ECU through the controller area network (CAN) bus, and the other ECU encrypts the random number with the stored symmetric key to get the return value, and returns the value. sent to the one ECU.
  • the ECU decrypts the return value using the stored symmetric key corresponding to the other ECU and compares the decrypted result with the random number. If the comparison results are consistent, the ECU determines that the other ECU is legal; otherwise, it is determined to be an illegal ECU and stops working.
  • the symmetric key is easily leaked maliciously or illegally tampered with, resulting in a low security level of the vehicle system.
  • the present application provides a control method of an in-vehicle device, an in-vehicle device and a vehicle system, which can improve the security level of the vehicle system.
  • the present application provides a method for controlling a vehicle-mounted device.
  • the method is applied to a vehicle system including a first ECU and a second ECU, where the first ECU stores a first digital certificate and a first private key, and the second ECU stores a first digital certificate and a first private key.
  • the ECU stores the second digital certificate.
  • the method may include: the first ECU sending the first digital certificate to the second ECU, where the first digital certificate includes a first public key; the first ECU sending to the second ECU the encrypted data using the first private key a first instruction, the first instruction is used to instruct the second ECU to start the first function; the second ECU decrypts the encrypted first instruction by using the first public key; the second ECU decrypts the encrypted first instruction according to the first issuing authority CA and the number of the same CAs contained in the second CA to determine the function that the second ECU allows access; the first CA is the CA that issued the first digital certificate, and the second CA is the CA that issued the second digital certificate ; the number of the first CA and the second CA are multiple; the more the same CAs contained in the first CA and the second CA, the more the number of functions that the second ECU allows to access; if If the function permitted to be accessed by the second ECU includes the first function, the second ECU activates the first function; if the function permitted to be accessed by the second ECU does not include the
  • Implementing the method of the first aspect and using the digital certificate for security authentication between ECUs can improve the security level of the vehicle system.
  • the method does not need to distinguish between the main ECU and the key ECU, which reduces the storage space requirement.
  • the security methods between ECUs have different degrees of certificate chain matching, and the functions that ECU2 can allow to access are different. This method avoids the waste of ECU resources caused by the single authentication result in the prior art, saves costs and resources, and improves user experience. .
  • the ECU can also limit some functions and continue to operate, so that the ECU can be reused reasonably, saving costs and resources, and improving user experience.
  • the first ECU may send the first digital certificate to the second ECU in response to the first message after receiving the first message from the electronic device.
  • the first message is used to instruct the second ECU to activate the first function.
  • an electronic device such as a mobile phone can send a remote control command to the server in response to a user operation, and the server forwards the remote control command to the first ECU, and the first ECU receives the remote control command.
  • the remote control message is the first message.
  • the server is used to provide remote vehicle control services.
  • the second ECU may also send the result of activation of the first function to the first ECU; the first ECU sends the electronic device A second message is sent, where the second message is used to instruct the second ECU to start the result of the first function.
  • the electronic device can output prompt information of the result, so that the user can know the result of the second ECU starting the first function.
  • the vehicle system further includes a display screen, and after the second ECU activates or refuses to activate the first function, the display screen can display prompt information, where the prompt information is used to indicate the second ECU The result of the ECU initiating this first function.
  • the second ECU may directly send the result of starting the first function to the display screen, or may send the result to the display screen through the first ECU. In this way, the user can intuitively know the start-up result of the second ECU from the display screen of the vehicle system.
  • the first CA and the second CA may also be based on the same information contained in the first CA and the second CA.
  • the number of CAs determines the functions that the first ECU is allowed to access; the more the same CAs contained in the first CA and the second CA are, the more functions the first ECU is allowed to access.
  • the function permitted to be accessed by the first ECU includes instructing the second ECU to activate the first function
  • the first ECU sends a first instruction encrypted with the first private key to the second ECU.
  • the first ECU further stores a first certificate chain
  • the second ECU further stores a second certificate chain
  • the first certificate chain includes the digital certificate of the first CA
  • the The second certificate chain includes the digital certificate of the second CA
  • the method further includes: the first ECU sending the first certificate chain to the second ECU.
  • the second ECU can determine the matching degree of the first CA and the second CA according to the certificate chains of both parties.
  • the method before the first ECU sends the first instruction encrypted with the first private key to the second ECU, the method further includes: the first ECU determines that the second digital certificate is valid , and the second ECU is the legal holder of the second digital certificate. Only when the second ECU verifies that the first digital certificate of the first ECU is legal and the second ECU is the legal holder of the first digital certificate, the second ECU will interact with the first ECU, which can improve the The level of security within the vehicle system.
  • the method before the second ECU decrypts the encrypted first instruction using the first public key, the method further includes: the second ECU determines that the first digital certificate is valid, and , the first ECU is the legal holder of the first digital certificate. Only when the first ECU verifies that the second digital certificate of the second ECU is legal and the first ECU is the legal holder of the second digital certificate, the first ECU will interact with the second ECU, which can improve the The level of security within the vehicle system.
  • the second ECU determines that the first digital certificate is valid, which specifically includes: the second ECU determines that the first digital certificate is issued by a trusted CA; or, the second ECU determines that the first digital certificate is valid.
  • the ECU determines that the first digital certificate is issued by a trusted CA and is within the validity period.
  • the first ECU when the first private key and the first public key are a key pair, the first ECU is the legal holder of the first digital certificate.
  • the first ECU may also send a first signature to the second ECU, where the first signature is obtained by processing a random number using the first private key; the second ECU uses the first public key Verify the first signature; if the verification result is the same as the random number, the first private key and the first public key are a key pair.
  • the first CA or the second CA includes one or more of the following: a root CA, a depot CA, a brand CA, a model CA, a vehicle CA, or a domain CA.
  • the first ECU is an ECU of an in-vehicle T-box
  • the second ECU is an ECU of an engine
  • the second ECU is an ECU of an in-vehicle T-box
  • the present application provides a method for controlling an in-vehicle device.
  • the method is applied to a second ECU, where the second ECU stores a second digital certificate.
  • the method may include: the second ECU receives a first digital certificate sent by the first ECU; the first ECU stores the first digital certificate and a first private key, the first digital certificate includes a first public key; the The second ECU receives the first instruction encrypted with the first private key sent by the first ECU, where the first instruction is used to instruct the second ECU to activate the first function; the second ECU uses the first public key pair The encrypted first instruction is decrypted; the second ECU determines the function that the second ECU is allowed to access according to the number of the same CA included in the first CA and the second CA; the first CA is to issue the first number
  • the CA of the certificate, the second CA is the CA that issued the second digital certificate; the number of the first CA and the second CA are multiple; the number of the same CA included in the first CA and the second CA The more, the more
  • the method further includes: the second ECU sends a result of activation of the first function to the first ECU.
  • the first ECU it is convenient for the first ECU to send the result to a display in the in-vehicle device or an electronic device such as a mobile phone, so that the user can know the result of the second ECU initiating the first function.
  • the method further includes: the second ECU sends a result of activation of the first function to a display screen in the vehicle-mounted system , so that the display screen displays prompt information, and the prompt information is used to instruct the second ECU to start the result of the first function. In this way, it is convenient for the user to know the result of the second ECU starting the first function.
  • the first ECU further stores the first certificate chain
  • the second ECU also stores the second certificate chain
  • the first certificate chain includes the digital certificate of the first CA
  • the second certificate chain includes the digital certificate of the second CA
  • the method further includes: the second ECU receives the first certificate chain sent by the first ECU, and the second ECU determines the first certificate chain according to the certificate chains of both parties. The degree of matching between the CA and the second CA.
  • the method before the second ECU decrypts the encrypted first instruction using the first public key, the method further includes: the second ECU determines that the first digital certificate is valid, and , the first ECU is the legal holder of the first digital certificate. Only when the second ECU verifies that the first digital certificate of the first ECU is legal and the second ECU is the legal holder of the first digital certificate, the second ECU will interact with the first ECU, which can improve the The level of security within the vehicle system.
  • the second ECU determining that the first digital certificate is valid specifically includes: the second ECU determining that the first digital certificate is issued by a trusted CA; or, the second ECU determining that the first digital certificate is valid A digital certificate is issued by a trusted CA and is within the validity period.
  • the first ECU when the first private key and the first public key are a key pair, the first ECU is the legal holder of the first digital certificate.
  • the second ECU may also receive a first signature sent by the first ECU, where the first signature is to use the first signature A private key is obtained after processing the random number; the second ECU uses the first public key to verify the first signature; when the verification result is the same as the random number, the first private key and the first public key are key pair.
  • the first CA or the second CA includes one or more of the following: a root CA, a depot CA, a brand CA, a model CA, a vehicle CA, or a domain CA.
  • the first ECU is an ECU of an in-vehicle T-box
  • the second ECU is an ECU of an engine
  • the second ECU is an ECU of an in-vehicle T-box.
  • the present application provides a method for controlling a vehicle-mounted device.
  • the method is applied to a first ECU, where the first ECU stores a first digital certificate and a first private key.
  • the method may include: the first ECU sending the first digital certificate to the second ECU, where the first digital certificate includes a first public key; the first ECU sending to the second ECU the encrypted data using the first private key a first instruction, where the first instruction is used to instruct the second ECU to activate the first function;
  • the first ECU may send the first digital certificate to the second ECU in response to the first message after receiving the first message from the electronic device.
  • the first message is used to instruct the second ECU to activate the first function.
  • an electronic device such as a mobile phone can send a remote control command to the server in response to a user operation, and the server forwards the remote control command to the first ECU, and the first ECU receives the remote control command.
  • the remote control message is the first message.
  • the server is used to provide remote vehicle control services.
  • the second ECU may further receive the result of activating the first function sent by the second ECU, and send a second message to the electronic device, where the second message is used to indicate the The second ECU activates the result of the first function.
  • the electronic device can output prompt information of the result, so that the user can know the result of the second ECU starting the first function.
  • the method before the first ECU sends a first instruction encrypted with the first private key to the second ECU, the method further includes: the first ECU according to the first CA and the The number of identical CAs included in the second CA determines the functions that the first ECU is allowed to access; the greater the number of identical CAs included in the first CA and the second CA, the number of functions that the first ECU is allowed to access more.
  • the function permitted to be accessed by the first ECU includes instructing the second ECU to activate the first function
  • the first ECU sends a first instruction encrypted with the first private key to the second ECU.
  • the first ECU further stores a first certificate chain
  • the second ECU further stores a second certificate chain
  • the first certificate chain includes the digital certificate of the first CA
  • the The second certificate chain includes the second CA's digital certificate.
  • the first ECU may also send the first certificate chain to the second ECU. In this way, the second ECU can determine the matching degree of the first CA and the second CA according to the certificate chains of both parties.
  • the method before the first ECU sends the first instruction encrypted by using the first private key to the second ECU, the method further includes: the first ECU determines that the second digital certificate is valid , and the second ECU is the legal holder of the second digital certificate. This increases the level of security within the vehicle system.
  • the first ECU may also send a first signature to the second ECU, where the first signature is obtained by processing a random number using the first private key. In this way, the second ECU can verify whether the first ECU is the legal holder of the first digital certificate.
  • the first ECU is an ECU of an in-vehicle T-box
  • the second ECU is an ECU of an engine
  • the second ECU is an ECU of an in-vehicle T-box.
  • the present application provides a vehicle system, the vehicle system comprising a first ECU and a second ECU, the vehicle system being configured to execute the method described in the first aspect or any one of the embodiments of the first aspect.
  • the present application provides an ECU, comprising: a security chip, one or more processors, and one or more memories; the security chip, the one or more memories, and the one or more processors wherein the security chip is used to store a second digital certificate; the one or more memories are used to store computer program code, the computer program code comprising computer instructions, when executed by the one or more processors When instructed by the computer, the ECU is caused to execute the method described in the second aspect or any one of the embodiments of the second aspect.
  • the present application provides an ECU, comprising: a security chip, one or more processors, and one or more memories; the security chip, the one or more memories, and the one or more processors wherein the security chip is used to store the first digital certificate; the one or more memories are used to store computer program code, the computer program code includes computer instructions, when the one or more processors execute The computer instructions cause the ECU to execute the method described in the third aspect or any one of the embodiments of the third aspect.
  • the present application provides an in-vehicle system, including the ECU according to the fifth aspect and a communication interface, where the communication interface is used to communicate with an Internet server.
  • the present application provides a computer storage medium, including computer instructions, which, when the computer instructions are executed on an electronic device, cause the electronic device to execute the method described in the second aspect or any one of the embodiments of the second aspect.
  • the present application provides a computer program product that, when the computer program product runs on a computer, causes the computer to execute the method described in the second aspect or any one of the embodiments of the second aspect.
  • the present application provides a computer storage medium, including computer instructions, which, when the computer instructions are executed on an electronic device, cause the electronic device to perform the method described in the third aspect or any one of the embodiments of the third aspect.
  • the present application provides a computer program product, which when the computer program product runs on a computer, causes the computer to execute the method described in the third aspect or any one of the embodiments of the third aspect.
  • Implementing the technical solution provided in this application and using digital certificates for security authentication between ECUs can improve the security level of the vehicle system.
  • the method does not need to distinguish between the main ECU and the key ECU, which reduces the storage space requirement.
  • the security methods between ECUs have different degrees of certificate chain matching, and the functions that ECU2 can allow to access are different. This method avoids the waste of ECU resources caused by the single authentication result in the prior art, saves costs and resources, and improves user experience. .
  • the ECU can also limit some functions and continue to operate, so that the ECU can be reused reasonably, saving costs and resources, and improving user experience.
  • FIG. 1 is a schematic structural diagram of a vehicle system provided by an embodiment of the present application.
  • FIG. 2 is a flow chart of issuing a digital certificate by a CA according to an embodiment of the present application
  • FIG. 3 is a structural diagram of a digital certificate issuance system provided by an embodiment of the present application.
  • FIG. 4 is a schematic flowchart of a method for controlling a vehicle-mounted device provided by an embodiment of the present application
  • 5A-5B provide a set of user interfaces implemented on an electronic device according to an embodiment of the present application
  • FIG. 6 is a flowchart for judging the matching degree of a certificate chain provided by an embodiment of the present application.
  • 8A-8C provide a set of user interfaces implemented on a vehicle system according to an embodiment of the present application.
  • first and second are only used for descriptive purposes, and should not be construed as implying or implying relative importance or implying the number of indicated technical features. Therefore, the features defined as “first” and “second” may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, unless otherwise specified, the “multiple” The meaning is two or more.
  • UI user interface
  • the term "user interface (UI)" in the description, claims and drawings of the embodiments of the present application is a medium interface for interaction and information exchange between an application program or an operating system and a user, which realizes the Conversion between internal forms and user-acceptable forms.
  • the user interface of the application is the source code written in a specific computer language such as java and extensible markup language (XML).
  • the interface source code is parsed and rendered on the terminal device, and finally presented as content that the user can recognize.
  • Controls also known as widgets, are the basic elements of the user interface. Typical controls include toolbars, menu bars, text boxes, buttons, and scroll bars. (scrollbar), pictures and text.
  • the attributes and content of controls in the interface are defined by tags or nodes.
  • XML specifies the controls contained in the interface through nodes such as ⁇ Textview>, ⁇ ImgView>, and ⁇ VideoView>.
  • a node corresponds to a control or property in the interface, and the node is rendered as user-visible content after parsing and rendering.
  • applications such as hybrid applications, often contain web pages in their interface.
  • a web page, also known as a page can be understood as a special control embedded in an application program interface.
  • a web page is source code written in a specific computer language, such as hypertext markup language (HTML), cascading styles Tables (cascading style sheets, CSS), java scripts (JavaScript, JS), etc.
  • the source code of the web page can be loaded and displayed as user-identifiable content by a browser or a web page display component similar in function to a browser.
  • the specific content contained in a web page is also defined by tags or nodes in the source code of the web page. For example, HTML defines the elements and attributes of web pages through ⁇ p>, ⁇ img>, ⁇ video>, and ⁇ canvas>.
  • GUI graphical user interface
  • GUI refers to a user interface related to computer operations that is displayed graphically. It can be an icon, window, control and other interface elements displayed on the display screen of the electronic device, wherein the control can include icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, Widgets, etc. visual interface elements.
  • each ECU in a vehicle system can be divided into a main ECU and a key ECU.
  • the number of main ECUs is one, and the number of key ECUs can be multiple.
  • the master ECU stores the symmetric key of each key ECU and verifies it through the method described in the background art. This verification method not only has a low security level, but also requires a large storage space for the main ECU to store the symmetric keys of multiple key ECUs.
  • the control strategy of the ECU is single, and the authentication results of the main ECU to the key ECU are only legal and illegal, resulting in waste of resources and poor user experience.
  • the following embodiments of the present application provide a control method of an in-vehicle device, a vehicle device, and a vehicle system.
  • the two parties before the ECU1 in the vehicle system instructs the ECU2 to start the first function, the two parties should mutually verify the validity of the other party's digital certificate, and also determine whether the other party is the legal holder of the digital certificate.
  • the ECU2 determines the functions that the ECU2 can open to the ECU1 according to the matching degree of the certificate chains of the two parties. If the first function is included in the functions that the ECU 2 is currently allowed to access, the ECU 2 activates the first function.
  • the security level of the vehicle system can be improved.
  • the method does not need to distinguish between the main ECU and the key ECU, which reduces the storage space requirement.
  • the security methods between ECUs have different degrees of certificate chain matching, and the functions that ECU2 can allow to access are different. This method avoids the waste of ECU resources caused by the single authentication result in the prior art, saves costs and resources, and improves user experience. .
  • the ECU can also limit some functions and continue to operate, so that the ECU can be reused reasonably, saving costs and resources, and improving user experience.
  • FIG. 1 is a schematic structural diagram of a vehicle system 10 according to an embodiment of the present application.
  • the vehicle system 10 may include a plurality of ECUs and a CAN bus 11 connecting the plurality of ECUs.
  • the plurality of ECUs may include, for example, an engine ECU 12, an ECU 13 of a telematics box (T-box), a transmission ECU 14, a driving recorder ECU 15, an antilock brake system (ABS) ECU 16, and the like.
  • CAN bus 11 is a broadcast type bus that can be used to transmit data between any two ECUs. Any ECU on the CAN bus 11 can monitor all the data transmitted on the CAN bus 11 .
  • the frames transmitted by the CAN bus 11 may include data frames, remote frames, error frames, and overload frames, and different frames transmit different types of data.
  • the CAN bus 11 can be used to transmit the data involved in the security authentication and control process of the ECU. For the security authentication and control process, reference may be made to the detailed description of the following embodiments.
  • ECU is also known as “trip computer”, “vehicle computer”, etc. It is the same as ordinary computer, including “ECU is the brain of the car”.
  • the ECU may also be called a vehicle-mounted device, a trip computer, a vehicle-mounted computer or other terms, which are not limited here. The following embodiments will be described by taking an ECU as an example.
  • Each ECU in the vehicle system 10 may include multiple functions, which will be described in detail below.
  • the engine ECU 12 is used to manage the engine and coordinate various functions of the engine, for example, it can be used to start the engine, stop the engine, and so on.
  • the engine is the device that powers the vehicle.
  • the engine is a machine that converts a certain type of energy into mechanical energy. Its function is to convert the chemical energy of liquid or gas combustion into thermal energy after combustion, and then convert the thermal energy into mechanical energy through expansion and output power.
  • the engine components can include two major mechanisms, the crank connecting rod mechanism and the valve mechanism, as well as five major systems such as cooling, lubrication, ignition, fuel supply, and starting system.
  • the main components are cylinder block, cylinder head, piston, piston pin, connecting rod, crankshaft, flywheel, etc.
  • the engine works by controlling fuel mixing and ignition timing based on feedback from sensors connected to the engine. That is, based on the speed and load of the engine, after calculation and processing by the ECU, action commands are sent to the fuel injector, fuel supply pump, etc., so that each cylinder has the most suitable fuel injection quantity, fuel injection rate and fuel injection time to ensure Each cylinder performs optimal combustion.
  • the T-box ECU13 is used to manage the T-box.
  • T-box is mainly used to communicate with background systems/electronic devices (such as mobile phones).
  • the display of vehicle control and vehicle information can also be realized on the electronic device side.
  • the T-box may also be called a vehicle-to-machine system, a telematics processor, a vehicle gateway, or the like, which is not limited in this embodiment of the present application.
  • the background system (such as a server) forwards the received control command to the T-box ECU13.
  • the T-box ECU 13 After the T-box ECU 13 obtains the control command, it sends the control message through the CAN bus 11 to realize the control of the vehicle. For example, start the engine, turn on the air conditioner, adjust the seat to a suitable position, open the car door/window/light/lock/horn/sunroof, etc., and finally feedback the operation result to the electronic device.
  • the T-box ECU 13 can also read the data of each ECU through the CAN bus 11, for example, obtain data such as vehicle condition report, driving report, fuel consumption statistics, violation inquiry, location trajectory, driving behavior, etc., and transmit the data to the background system through the network , which is forwarded by the background system to the electronic device for the user to view.
  • the transmission ECU 14 manages the transmission.
  • the transmission can be used to change the speed and torque of the engine. It can change the transmission ratio of the output shaft and the input shaft in a fixed or step-by-step manner.
  • the transmission components may include a speed change transmission mechanism, a control mechanism, and a power output mechanism.
  • the main function of the variable speed transmission mechanism is to change the value and direction of torque and rotational speed; the main function of the control mechanism is to control the transmission mechanism to realize the transformation of the transmission ratio, that is, to achieve gear shifting to achieve variable speed and torque.
  • the drive recorder ECU 15 manages the drive recorder.
  • the components of the driving recorder can include a host, a vehicle speed sensor, and data analysis software.
  • a driving recorder refers to an instrument that records the images and sounds of the vehicle during driving, including driving time, speed, location and other related information.
  • the vehicle speed sensor collects the rotational speed of the wheels, and sends the vehicle speed information to the driving recorder through the CAN bus.
  • the ABS ECU 16 is used to manage the ECU. ABS is to automatically control the braking force of the brakes when the vehicle is braking, so that the wheels are not locked, and are in a state of rolling and slipping (slip rate is about 20%) to ensure that the adhesion between the wheels and the ground is the maximum value. .
  • the ABS enters the anti-lock braking pressure adjustment process.
  • each ECU stores its own private key and digital certificate.
  • the ECU may also store the certificate chain. The detailed explanation of the private key, the digital certificate, and the certificate chain will be described in the subsequent embodiments, and will not be repeated here.
  • Security authentication may be performed between the ECUs in the embodiments of the present application. Specifically, before the ECU1 in the vehicle system instructs the ECU2 to start the first function, the two parties should mutually verify the validity of the other party's digital certificate, and also determine whether the other party is the digital certificate holder. When the two parties mutually confirm that the digital certificate of the other party is legal and the other party is the legal holder of the digital certificate, the ECU2 determines the functions that the ECU2 can open to the ECU1 according to the matching degree of the certificate chains of the two parties. If the ECU1 instructs the ECU2 to activate the first function included in the accessible functions, the ECU2 activates the first function.
  • the concepts related to the legality of the digital certificate, the legal holder of the digital certificate, the matching degree of the certificate chain, and the openable function of the ECU will be described in detail in the subsequent embodiments.
  • Both ECU1 and ECU2 may be any ECU in the vehicle system 10 of the embodiment of the present application.
  • the scenario where the ECU1 instructs the ECU2 to activate the first function may include, for example, the T-box ECU13 controls the engine ECU12 to start/stop the engine, and the T-box ECU13 controls the transmission ECU14 to shift gears.
  • Vehicle systems may include more or fewer components than shown, or some components may be combined, or some components may be split, or a different arrangement of components.
  • the illustrated components may be implemented in hardware, software, or a combination of software and hardware.
  • each ECU may also use a vehicle Ethernet (Ethernet) commonly used vehicle network LIN, FlexRay, and a commonly used vehicle network system MOST (media oriented systems, MOST) bus, etc., which is not limited in this embodiment of the present application.
  • vehicle Ethernet Ethernet
  • MOST media oriented systems
  • ECU can be composed of security chip, microprocessor (microcontroller unit, MCU), random access memory (random access memory, RAM), read-only memory (random-only memory, ROM), input/output interface (I/O) , analog/digital converter (A/D converter) and large-scale integrated circuits such as input, output, shaping, driving, etc.
  • microprocessor microcontroller unit, MCU
  • random access memory random access memory
  • RAM random access memory
  • read-only memory random-only memory
  • ROM read-only memory
  • I/O input/output interface
  • A/D converter analog/digital converter
  • large-scale integrated circuits such as input, output, shaping, driving, etc.
  • the security chip is used to store the digital certificate and private key of the ECU.
  • the security chip is used to store the digital certificate and private key of the ECU.
  • An A/D converter converts an analog signal into a digital signal that the MCU can process. Most of the signals sent by the sensor are analog signals.
  • the function of the A/D converter is to convert the preprocessed voltage signal of the input loop into a digital signal, and then send the converted digital signal to the MCU.
  • the MCU is the center of ECU.
  • the MCU performs arithmetic processing on the input signal with the memory program and data as required, and sends the processing result to the output loop.
  • RAM is mainly used to store variable data during calculator operation. For example, it is used to store the input and output data of the computer and the intermediate data generated by the computer process. When the power is cut off, the RAM data will disappear.
  • ROM can only read memory, used to store fixed data.
  • the manufacturer stores permanently stored programs and data such as engine fuel injection characteristic map and ignition characteristic map at one time during vehicle production. When the power is cut off, the ROM data will not disappear.
  • a digital certificate refers to an electronic certificate issued by a digital certificate authority (CA) to identify the identity information of the digital certificate holder, which provides a way to verify the identity of the communication peer.
  • CA digital certificate authority
  • CA is an authority responsible for issuing and managing digital certificates.
  • the CA is responsible for verifying the legitimacy of the public key in the public key system, including verifying the identity of the device applying for a digital certificate, managing and updating digital certificates, and maintaining a revocation list of digital certificates (digital certificates that have been revoked). certificate) etc.
  • the CA has its own private key and public key. The private key is used to sign the digital certificate of the application device, and the public key is used to verify whether the digital certificate is a digital certificate issued by the CA, that is, to verify whether the digital certificate is legal.
  • the format of the digital certificate may follow different international standards, such as X.509v3 (1997), X509v4 (1997), X.509v1 (1988), and TUTrec.x.509V3 formulated by the International Telecommunication Union, etc.
  • X.509v3 (1997), X509v4 (1997), X.509v1 (1988), and TUTrec.x.509V3 formulated by the International Telecommunication Union, etc.
  • Figure 2 shows the process of issuing a digital certificate by a CA. As shown in Figure 2, the process may include the following steps:
  • the application device generates a symmetric key, which includes a pair of public key and private key.
  • the applicant device can use an asymmetric encryption algorithm to generate a pair of public key and private key, in which the private key is kept by the applicant device itself, and the public key can be notified to many people.
  • the symmetric key can also be generated by the CA.
  • the application device applies for a digital certificate from the CA.
  • the application device sends an application document to the CA, and the application document includes information such as the public key and identification of the application device.
  • the application file is used to apply for a digital certificate from the CA.
  • the CA generates the digital certificate of the application device and issues it to the application device.
  • the CA may also confirm that the application document sent by the application device 1 is correct.
  • the CA creates a digital document according to the application document sent by the application device, and the digital document may include the public key of the application device, the identity identifier, the valid date of the digital document, the name of the digital certificate authority, and the like.
  • the CA then calculates the "digital document" using a digest algorithm to obtain a digital digest.
  • the CA uses its own private key to sign the digital digest, digital document and the digest algorithm used to calculate the digital digest to generate a digital certificate.
  • the digital certificate signing process is equivalent to "locking" the content of the digital certificate in order to prove the digital certificate. Certificates are issued by CAs.
  • the generated digital certificate is issued to the requesting device.
  • the valid date is generally 1-5 years from the issuance date of the digital certificate.
  • the digital certificate received by the application device may include information such as the serial number of the digital certificate, the validity period of the digital certificate, the identity of the digital certificate holder, the public key of the digital certificate holder, and the identity of the CA that issued the digital certificate.
  • the identification of the CA may be, for example, the name, number, and the like of the CA.
  • each digital certificate holder has a private key known only to him and uses it to decrypt and sign.
  • it has a public key and can be disclosed to the public for encryption and signature verification.
  • the sender encrypts the data with the receiver's public key, and the receiver decrypts it with its own private key. In this way, the data can reach the destination safely and without error. Even if it is intercepted by a third party, it cannot be decrypted because there is no corresponding private key.
  • the digital certificate issued by the trusted authoritative CA is a legal digital certificate, which is a legal digital certificate.
  • the digital certificate issued by a trusted authoritative CA and within the validity period is a valid digital certificate.
  • whether the digital certificate is issued by a trusted authoritative CA may be verified by means of a digital signature.
  • the verifier can use the public key corresponding to the authoritative CA carried in the digital certificate to sign and verify the digital certificate to obtain a digital digest, a digest algorithm, and a digital document.
  • the verifier uses the digest algorithm to calculate the digital document to obtain a new digital digest, and compares the digital digest with the digital digest in the digital certificate. If the comparison results are consistent, it means that the signature verification of the digital certificate is passed, and the digital certificate is a digital certificate issued by the CA, that is, the digital certificate is legal.
  • the verifier may further confirm whether the digital certificate is within the validity period. If the digital certificate is issued by an authoritative CA and within the validity period, the digital certificate is valid.
  • the application device After the application device successfully applies for a digital certificate from the CA, the application device becomes the legal holder of the digital certificate.
  • the digital certificate of the application device may be stolen, tampered with, etc. by other illegal users, and the other illegal users are not the legal holders of the digital certificate. Obviously, there is only one legal holder of a digital certificate.
  • the private key is only owned by the device that is applying for it. Therefore, the official digital holder can be confirmed through the private key. Specifically, if the other party owns the private key, the other party is the legal holder of the digital certificate.
  • the verifier can send a random number to the verified party, and the verified party encrypts the random number with its own private key to obtain a return value, and sends the return value to the verifying party. The verifier encrypts the random number with the public key disclosed by the verifier. If the encryption result is consistent with the return value, it means that the verifier has the private key corresponding to the public key carried by its digital certificate, that is, the verifier is the The legal holder of the digital certificate.
  • the digital certificate can be used to encrypt and decrypt the transmitted information to ensure that the vehicle Confidentiality and authenticity of information transmitted between ECUs in the system.
  • the process of encrypting and decrypting information by using a digital certificate reference may be made to related descriptions of subsequent method embodiments.
  • FIG. 3 is a structural diagram of a system for issuing a digital certificate to each ECU in a vehicle system provided by an embodiment of the present application.
  • the digital certificate issuing system of the embodiment of the present application adopts a multi-level hierarchical structure. This application does not limit the number of levels of the digital certificate issuing system.
  • a CA system constructed by a car manufacturer based on vehicle information may include several layers from top to bottom: root CA (Root CA), car manufacturer CA, brand CA, model CA, vehicle CA, and domain CA.
  • root CA root CA
  • car manufacturer CA brand CA
  • model CA model CA
  • vehicle CA and domain CA.
  • the specific number can be constructed according to the information of the vehicles produced by the depot. This application does not limit the number of CAs at each level of the digital certificate issuance system.
  • the root CA is the position of the top tree root in the digital certificate method system, and the root CA is the most authoritative third-party digital certificate authority in the entire CA system.
  • the root CA can issue a digital certificate (root certificate) to itself, that is, the root CA can prove its legal identity by itself.
  • Each level of CA can use its own private key to issue a digital certificate to the next level of CA, so as to issue one level down, and finally issue a digital certificate to the ECU.
  • the root CA issues a digital certificate for the car factory 1CA
  • the car factory 1CA issues a digital certificate for the brand 1CA, which means that the car factory 1CA trusts the brand 1CA, so as to transmit the trust relationship.
  • the root CA can use its own private key to issue digital certificates to the next-level car factory CAs (such as car factory 1CA and car factory 2CA).
  • the car factory CA obtains the digital certificate issued by the root CA, it means that the car factory CA is trusted.
  • a trusted OEM CA eg, OEM 1CA
  • can issue digital certificates for the next level of brand CAs eg, BRAND 1CA, BRAND 2CA, and BRAND 3CA.
  • a trusted brand CA eg, brand 1CA
  • domain 2CA issues digital certificates
  • domain CAs (such as security domain 1CA and other domain 1CAs) can issue digital certificates for ECUs under the jurisdiction of the security domain.
  • the CA hierarchical structure and arrangement shown in FIG. 3 are only examples, and may include more or less levels.
  • the security domain CA may or may not be included between the root CA and the ECU.
  • a certificate chain is an ordered list of certificates.
  • the certificate chain of the ECU includes: the digital certificate of the ECU, and the digital certificates of all CAs involved in issuing the digital certificate.
  • the existence of the certificate chain facilitates the receiver to verify whether the sender and all CAs in the sender's certificate chain are trustworthy.
  • the certificate chain consists of the following three parts: the root certificate, the intermediate certificate and the digital certificate of the ECU. in:
  • the root certificate refers to the digital certificate signed and issued by the root CA with its own private key.
  • the root certificate signature verification uses the public key of the root CA.
  • the intermediary certificate refers to the digital certificate that the root CA uses its own private key to sign and issue the intermediary CA.
  • the signature verification of the intermediary certificate uses the public key of the root CA.
  • the intermediate certificate contains the name of the root certificate.
  • the intermediary CA is the CA of other levels except the root CA in the issuance system of the digital certificate, such as the car factory CA, the brand CA, the model CA, the vehicle CA and the domain CA.
  • the ECU digital certificate refers to the digital certificate signed and issued by the private key of the upper-level intermediate CA (domain CA).
  • domain CA upper-level intermediate CA
  • the signature verification of the ECU digital certificate requires the use of the domain CA's public key.
  • the ECU can save the certificate chain, or obtain the certificate chain through query when using the certificate chain.
  • the root CA is the most authoritative and reliable digital certificate issuing center in the entire CA system, and is also the starting point of the certificate chain.
  • the issuer of the digital certificate of the root CA is itself.
  • the digital certificates of other intermediary CAs need to be issued with the private key of the intermediary CA of the upper level, and the digital certificate of the intermediary CA of the upper level shall be issued with the private key of the intermediary CA of the upper level.
  • the corresponding public key of the CA verifies the validity of the digital certificate.
  • the ECU digital certificate when verifying the legitimacy of the ECU digital certificate, it is necessary to trace the source to the root certificate step by step. Specifically, first confirm that the digital certificate is a legal digital certificate issued by an upper-level CA (such as security domain 1CA), and then confirm the legitimacy of the upper-level CA (such as security domain 1CA), ..., and so on, The legitimacy of the original issuer (ie the root CA) of the ECU digital certificate has been confirmed. If the root CA is a trusted authority CA, the ECU digital certificate is a legal digital certificate.
  • an upper-level CA such as security domain 1CA
  • the two parties before the ECU1 in the vehicle system instructs the ECU2 to start the first function, the two parties should mutually verify the legality of the other party's digital certificate, and also determine whether the other party is the holder of the digital certificate.
  • the ECU2 determines the functions that the ECU2 can open to the ECU1 according to the matching degree of the certificate chains of the two parties.
  • the ECU 2 activates the first function if it is included in the functions currently accessible to the ECU 2 .
  • ECU1 and ECU2 may be any ECU in the vehicle system 10 of the embodiment of the present application.
  • ECU1 may be T-box ECU13
  • ECU2 may be engine ECU12.
  • ECU1 and ECU2 each store their own digital certificate and private key.
  • the private key of ECU1 is called private key 1
  • the private key of ECU2 is called private key 2.
  • the digital certificate of the ECU includes: the public key of the ECU and the identifier of the CA that issued the digital certificate.
  • the digital certificate of the ECU may further include information such as the validity period of the digital certificate, the serial number or the identity of the holder.
  • FIG. 4 is a flowchart of a method for controlling an in-vehicle device provided by an embodiment of the present application.
  • the method may include the following steps:
  • the content of ECU1 and ECU2 certification includes verifying the legality of the other party's digital certificate and verifying that the other party is the legal holder of the digital certificate.
  • the digital certificate is legal and the other party is the legal holder of the digital certificate, it can be confirmed that the digital certificate is issued by a trusted authoritative CA, and the digital certificate is not counterfeited by a third party. Only when the digital certificates of both parties are legal and the other party is the legal holder of the digital certificate, can the ECUs conduct secure communication based on the digital certificate.
  • the concept of verifying the legality of the digital certificate and the legal holder of the digital certificate may refer to the detailed description above.
  • ECU1 receives a first message, where the first message is used to instruct ECU2 to activate the first function.
  • the first message may be sent to the ECU1 by other ECUs in the vehicle system 10, or may be sent to the ECU1 by an external device, which is not limited here.
  • the user can remotely control the ECU1 through an application (application, APP) installed on the electronic device or a web page on the computer.
  • the electronic device can send a remote control instruction to the server in response to the user operation, the server forwards the remote control instruction to the ECU1, and the remote control message received by the ECU1 is the first message.
  • the server is used to provide remote vehicle control services.
  • the following describes a scenario in which the ECU 1 receives the first message with reference to the user interface provided by the embodiment of the present application.
  • 5A-5B exemplarily illustrate a user interface implemented on an electronic device (eg, a cell phone).
  • an electronic device eg, a cell phone
  • FIG. 5A shows a user interface 300 displayed by an electronic device.
  • displayed in the user interface 300 are: a status bar, a tray with frequently used application icons, a page indicator, other application icons, and the like.
  • the user interface 300 shown in FIG. 5A may further include a navigation bar, a side bar, and the like.
  • the user interface 300 exemplarily shown in FIG. 5A may be a home screen.
  • other application icons may include, for example, an application (eg, “Vehicle Communication”) icon 301 for managing vehicles, and the like.
  • an application eg, “Vehicle Communication” icon 301 for managing vehicles, and the like.
  • the electronic device can detect a user operation (such as a click operation, a touch operation, etc.) acting on the icon 301, and in response to the user operation, start the application for managing the vehicle corresponding to the icon 301 (eg "Vehicle Connect") and display the user interface 400 provided by the application.
  • a user operation such as a click operation, a touch operation, etc.
  • FIG. 5B shows one implementation of user interface 400 .
  • User interface 400 is used to remotely manage the vehicle.
  • the user interface 400 displays: a search bar 410 , a control 420 , frequently used controls 431 - 433 , a control 440 , an information display bar 450 , and a menu bar 460 .
  • the search bar 410 may be used to listen for a touch operation, a click operation, etc., and in response to the operation, the electronic device may display a virtual keyboard to allow the user to input what he wants to search.
  • the control 420 is used to monitor user operations (such as click operations, touch operations, etc.), and the electronic device can display more functional controls in response to the user operations, such as controls for turning on/off the air conditioner, and controls for turning on/off lights in the car etc.
  • user operations such as click operations, touch operations, etc.
  • the electronic device can display more functional controls in response to the user operations, such as controls for turning on/off the air conditioner, and controls for turning on/off lights in the car etc.
  • the control 431 can be used to monitor user operation, and in response to the user operation, the electronic device can send a message instructing to turn on/off the engine to the T-box ECU 13 in the vehicle system through the server.
  • the control 432 may be used to monitor user operation, and in response to the user operation, the electronic device may send a message indicating opening/closing of the window to the T-box ECU 13 in the vehicle system through the server.
  • the control 433 can be used to monitor user operation, and in response to the user operation, the electronic device can send a message indicating opening/closing of the door to the T-box ECU 13 in the vehicle system through the server.
  • the control 440 is used to monitor user operations (eg, click operations, touch operations, etc.), and the electronic device may display more vehicle information, such as fuel level, today's running volume, and the like, in response to the user operations.
  • user operations eg, click operations, touch operations, etc.
  • vehicle information such as fuel level, today's running volume, and the like, in response to the user operations.
  • the information display bar 450 may include: parking place 451 , parking time 452 , distance 453 from the electronic device to the parking place, navigation information 454 and so on.
  • the menu bar allows users to switch between different pages to perform operations with different functions.
  • the first message received by the ECU1 in S100 may be, for example:
  • the electronic device detects a user operation (such as a click operation, a touch operation, etc.) on the control 431, and sends a control command for turning on/off the engine to the server in response to the operation, and the server sends the T-box ECU13 to the Control command for turning the engine on/off.
  • a user operation such as a click operation, a touch operation, etc.
  • the server sends the T-box ECU13 to the Control command for turning the engine on/off.
  • the T-box ECU13 is ECU1
  • the engine ECU12 is ECU2
  • the first function is to start or shut down the engine.
  • the electronic device detects a user operation (such as a click operation, a touch operation, etc.) on the control 432, and sends a control command for opening/closing the window to the server in response to the operation, and then the server sends the control command to the T-box ECU13.
  • the control command for opening/closing the windows is ECU1
  • the body control module (BCM) is ECU2
  • the first function is to start or close the window.
  • T-box ECU13 After the electronic device detects a user operation (such as a click operation, a touch operation, etc.) on the control 433, it sends a control command for opening/closing the door to the server in response to the operation, and the server sends the control command to the T-box ECU13.
  • T-box ECU13 is ECU1
  • BCM is ECU2
  • the first function is to open or close the door.
  • the ECU1 sends a message a to the ECU2, and the message a includes: the digital certificate 1 of the ECU1 and the random number r1.
  • the messages transmitted when the ECU1 and the ECU2 communicate are all transmitted through the CAN bus 11 .
  • the messages transmitted during the communication between the ECU1 and the ECU2 all contain the identifier of the sender and the identifier of the receiver. Since all ECUs on the CAN bus 11 can receive the message transmitted on the CAN bus 11, after receiving the message, the ECU can know the sender of the message through the sender's identifier, and the receiver's identifier can be used to know the sender of the message. Know the recipient of the message.
  • the message a may contain the identifier 1 of ECU1 and the identifier 2 of ECU2.
  • the identification 1 or the identification 2 may be a combination of a series of numbers, letters, and symbols, for example, a serial number, a serial number, a name, and the like.
  • the digital certificate 1 includes: the public key of the ECU 1 and the identity of the CA that issued the digital certificate 1 (for example, the security domain 1CA). In some embodiments, the digital certificate 1 may further include information such as the validity period of the digital certificate 1, the serial number or the identity of the holder.
  • the random number r1 may be generated by the ECU1, or may be a certain number in the digital certificate 1 or the identification 1 that has been agreed upon.
  • ECU1 After ECU1 sends the message a, all ECUs on the CAN bus can receive the message a.
  • the ECU 2 uses the public key of the CA that issued the digital certificate 1 to perform signature verification on the digital certificate 1. If the verification is passed, it means that the digital certificate 1 is legal. When ECU2 verifies digital certificate 1, it needs to trace back to the root certificate. For the specific manner in which the ECU 2 verifies the legitimacy of the digital certificate 1, reference may be made to the foregoing descriptions on the legitimacy of the digital certificate and the certificate chain.
  • the ECU 2 after confirming that the digital certificate 1 is legal, the ECU 2 returns a message b to the ECU 1 .
  • the message b includes: digital certificate 2, random number r2, and signature 2.
  • Signature 2 is the signature made by ECU2 to the random number r1 with its own private key 2.
  • the digital certificate 2 includes: the public key of the ECU 2 and the identifier of the CA that issued the digital certificate 2 (for example, the security domain 1CA).
  • the digital certificate 2 may further include information such as the validity period of the digital certificate 2, the serial number, or the ID of the holder.
  • the random number r2 may be generated by the ECU2, or may be a certain number in the digital certificate 2 or the identification 2 that has been agreed.
  • Signature 2 is the signature made by ECU2 on the random number r1 with its own private key 2, that is, the private key 2 and the random number R1 are processed through an algorithm.
  • the ECU 1 can use the public key of the CA that issued the digital certificate 2 to perform signature verification on the digital certificate 2, and if the verification is passed, it means that the digital certificate 2 is legal.
  • the ECU 1 verifies whether the ECU 2 is the legal holder of the digital certificate 2 .
  • the ECU1 uses the public key 2 carried by the digital certificate 2 to perform signature verification on the signature 2. If the signature verification result is consistent with the random number r1 in S101, it means that the public key 2 and the private key 2 carried by the digital certificate 2 are a pair The key, that is, the ECU2 is the legal holder of the digital certificate 2.
  • the ECU 1 after determining that the digital certificate 2 is legal and the ECU 2 is the legal holder of the digital certificate 2 , the ECU 1 sends a message c to the ECU 2 , and the message c includes: the signature 1 of the ECU 1 .
  • the signature 1 can be the signature made by the ECU1 to the random number r2 using its own private key 1, or it can be the signature made to the random number r1 and the random number r2 at the same time.
  • the ECU1 executes S106 , that is, the verification result of the ECU1 to the ECU2 is that the digital certificate 2 is legal and the ECU2 is the legal holder of the digital certificate 2 .
  • the ECU 2 verifies whether the ECU 1 is the legal holder of the digital certificate 1 .
  • the process of ECU2 verifying whether ECU1 is the legal holder of digital certificate 1 may refer to step S105.
  • the ECU 2 uses the public key 1 carried by the digital certificate 1 to perform signature verification on the signature 1. If the signature verification result is consistent with the random number r2 in S103, or the signature verification result is consistent with the random numbers r2 and r1, then the digital certificate
  • the public key 1 and the private key 1 carried by 1 are a pair of keys, that is, the ECU 1 is the legal holder of the digital certificate 1.
  • ECU2 sends a message d to ECU1.
  • the message d includes: the authentication result of ECU2 to ECU1.
  • the identifier 2 of the ECU2 in the message d is used to indicate that the sender of the message d is the ECU2, and the identifier 1 of the ECU1 is used to indicate that the message d is sent to the ECU1.
  • digital certificate 1 is legal and ECU1 is the legal holder of digital certificate 1
  • digital certificate 1 is legal but ECU1 is not the legal holder of digital certificate 1.
  • steps S101-S108 may be replaced by:
  • ECU1 sends digital certificate 1, random number r1, and the signature of random number r1 with private key 1 to ECU2;
  • ECU2 verifies the validity of digital certificate 1, and verifies whether ECU1 is the legal holder of digital certificate 1;
  • ECU2 After determining that digital certificate 1 is legal and ECU1 is the legal holder of digital certificate 1, ECU2 sends digital certificate 2, random number r2, and the signature of random number r2 with private key 2 to ECU1;
  • ECU1 verifies the validity of digital certificate 2, and verifies whether ECU2 is the legal holder of digital certificate 2;
  • ECU1 transmits the authentication result of ECE to ECU2.
  • digital certificate 2 is legal and ECU2 is the legal holder of digital certificate 2
  • digital certificate 2 is legal but ECU2 is not the legal holder of digital certificate 2
  • digital certificate 2 is not legal holder of digital certificate 2
  • Legal and ECU2 is not the legal holder of digital certificate 2
  • ECU2 is the legal holder of digital certificate 2 but digital certificate 2 is not legal.
  • the two-way authentication process between the ECU1 and the ECU2 can be made more concise, the interaction process between the two parties is reduced, and resources are saved.
  • the two-way authentication between ECU1 and ECU2 is successful, that is, the identity information of ECU1 and ECU2 can be guaranteed to be authentic, and further communication can be performed between ECU1 and ECU2, refer to the following steps S109-112.
  • the embodiment of the present application does not limit the execution sequence of the above S101-S108, as long as the ECU1 completes the security authentication of the ECU before instructing the ECU2 to start the first function, and the ECU2 completes the authentication before starting or rejecting the first function according to the instruction.
  • the safety certification of ECU1 is sufficient.
  • ECU1 shown in FIG. 4 triggers the two-way authentication process between ECU1 and ECU2 when receiving the first message.
  • ECU1 and ECU2 may also periodically perform the two-way authentication process. This is not limited.
  • the ECU1 instructs the ECU2 to activate the first function.
  • ECU1 sends a message e to ECU2.
  • the message e includes a first instruction encrypted with the private key 1, and the first instruction is used to instruct the ECU 2 to activate the first function.
  • the ECU 1 may first use a hash algorithm to calculate the first instruction, and then use the private key 1 to encrypt the first instruction.
  • the hash algorithm can compress the size of the first instruction and improve communication efficiency.
  • This embodiment of the present application does not limit the sequence of S109 and S100-S108.
  • the ECU 2 decrypts the message e using the public key 1 carried in the digital certificate 1 to obtain the first instruction.
  • the ECU 2 determines, according to the matching degree of the certificate chains of the two parties, the functions that the ECU 2 is currently allowed to access.
  • Each ECU may store its own certificate chain in advance, or may query its own certificate chain from the network, which is not limited in this embodiment of the present application. That is to say, ECU2 can obtain its own certificate chain locally, and can also query its own certificate chain from the network.
  • ECU2 can also obtain the certificate chain of ECU1 from ECU1, or query the certificate chain of ECU2 from the network.
  • the certificate chain of ECU1 may be carried in a message sent by any one of ECU1 to ECU2 in S101, S106, and S109, such as message a, message c, or message e.
  • ECU2 may store the certificate chain of ECU1.
  • the matching degree of the certificate chains of the two parties specifically refers to the number of the same CAs (including the root CA and the intermediate CA) contained in the certificate chains of the two parties. The greater the number of identical CAs contained in both certificate chains, the higher the degree of matching.
  • FIG. 6 exemplarily outputs the flow of the ECU 2 judging the matching degree of the certificate chains of both parties.
  • ECU2 starts from the root CA, and determines whether the CAs of the two parties are the same or not, and finally obtains the result of the matching degree.
  • the results of the degree of match may include, for example:
  • the root CAs of both parties are different. That is, digital certificate 1 and digital certificate 2 are issued by different root CAs.
  • the root CA of both parties is the same, but the CA of the depot is different. That is, the digital certificate 1 and the digital certificate 2 are issued by the same root CA but different car manufacturer CAs. That is to say, ECU1 and ECU2 belong to different carmakers.
  • the root CA and car factory CA of both parties are the same, but the brand CA is different. That is, ECU1 and ECU2 belong to different brands.
  • the root CA, car factory CA and brand CA of both parties are the same, but the model CA is different. That is, ECU1 and ECU2 belong to different models.
  • the root CA, car factory CA, brand CA and model CA of both parties are the same, but the vehicle CA is different. That is, ECU1 and ECU2 belong to different vehicles.
  • the root CA, car factory CA, brand CA, model CA, and vehicle CA of both parties are the same, but the domain CA is different. That is, ECU1 and ECU2 belong to different domains.
  • the root CA, car factory CA, brand CA, model CA, vehicle CA, and domain CA of both parties are the same. That is, ECU1 and ECU2 belong to the same domain, and ECU1 and ECU2 match exactly.
  • the higher the matching degree of the certificate chains of the two parties the greater the number of functions that the ECU 2 is allowed to access.
  • the functions that the ECU 2 is allowed to access refers to: among the functions possessed by the ECU 2 , the functions that can be opened at present or the functions that are authorized to be used.
  • Table 1 takes ECU2 as the engine ECU as an example, and exemplarily shows the functions that the engine ECU allows to access when the matching degrees of the two parties are different.
  • Table 2 takes ECU2 as a T-box ECU as an example, and exemplarily shows the functions that the T-box ECU allows access when the matching degrees of the two parties are different.
  • serial number match result ECU2 engine ECU
  • engine ECU allows access to functions 1 different root CAs without 2 different car factory without 3 different brands without 4 different models start up, shut down 5 different vehicles start up, shut down 6 different domains start up, shut down 7 same domain start up, shut down
  • the restricted functions of the ECU can be divided into two categories: functions performed by the ECU independently (such as the start function or shutdown function of the engine ECU), and the ECU and other devices. Functions that are done interactively (for example, the T-box ECU controls the functions of other ECUs according to remote commands).
  • ECU1 may also determine the function that ECU1 is allowed to access according to the matching degree of the certificate chains of the two parties, and when the item “instructing ECU2 to activate the first function” is the function that ECU1 is currently allowed to access , and then execute S109.
  • ECU2 is an engine ECU
  • the first function is to start the engine, and the certificate chains of ECU1 and ECU2 are completely matched, then ECU2 (ie, the engine ECU) starts the engine.
  • step S113 the ECU2 encrypts the message f using the private key 2, and sends the message f to the ECU1.
  • the message f includes: the execution result of the first function.
  • the execution result of the first function may be success or failure.
  • the ECU 2 can decrypt the message f through the public key 2, so as to know the result of the ECU 1 performing the first function.
  • step S114 the ECU 1 sends a second message to the electronic device, where the second message is used to indicate the execution result of the first function.
  • the ECU 1 may send a remote command to the server, where the remote command carries the execution result of the first function.
  • the server sends the remote command to the electronic device, and the remote command received by the electronic device is the second message.
  • the second message when ECU2 fails to start the first function, the second message may further carry the result of the degree of matching between the certificate chains of ECU1 and ECU2. In this way, it is convenient for subsequent users to know the reason why the ECU 2 fails to start the first function.
  • step S115 the electronic device receives the second message and outputs prompt information, where the prompt information is used to indicate the execution result of the first function by the ECU1.
  • the prompt information output by the electronic device may include, but is not limited to, visual interface elements displayed on the user interface, audio, flashing lights or vibrations, and the like.
  • the prompt information displayed in the user interface 400 by the electronic device is exemplarily shown.
  • prompt information 701 may be displayed in the user interface 400 .
  • the prompt information 701 can be, for example, text (for example, "starting the engine successfully"), icon, animation, and the like.
  • a prompt message 702 may be displayed in the user interface 400 .
  • the prompt information 702 can be, for example, text (for example, "failed to start the engine, error code 00001"), icons, animations, and the like. In this way, the user can learn the reason why the ECU 1 fails to start the first function by querying the code explanation in the vehicle manual.
  • the user interface 400 may also display a control 703, the control 703 may be used to monitor user operations, and the electronic device may display the reason for the startup failure in response to the user operation, such as displaying the ECU1 and The certificate chain of ECU2 matches the result 704 .
  • step S116 the vehicle system outputs prompt information, where the prompt information is used to indicate the execution result of the first function by the ECU 1.
  • This embodiment of the present application does not limit the sequence of S116, S114, and S115.
  • the ECU 1 may notify the relevant equipment in the vehicle system of the execution result, so that the relevant equipment outputs the prompt information.
  • the prompt information output by the vehicle system may include, but is not limited to: visual interface elements displayed on the display screen, audio output from audio equipment, light output from lamps, data output from instrument panels, and the like.
  • a user interface 500 displayed by a vehicle system on a display screen (eg, a display screen provided by a navigation device) is illustratively shown.
  • prompt information 801 may be displayed in the user interface 500 .
  • the prompt information 801 can be, for example, text (for example, "starting the engine successfully"), icon, animation, and the like.
  • a prompt message 802 may be displayed in the user interface 500 .
  • the prompt information 802 can be, for example, text (for example, "failed to start the engine, error code 00001"), icons, animations, and the like.
  • the user interface 500 may further display a control 803, the control 803 may be used to monitor user operations, and the electronic device may display the reason for the startup failure in response to the user operation, for example, displaying the ECU1 and The certificate chain of ECU2 matches the result 804 .
  • the main ECU may also perform security authentication on other key ECUs before starting its own function.
  • the degree of matching of the certificate chain between itself and other key ECUs determines whether to activate the function.
  • the main ECU may be an engine ECU
  • the key ECU may include a T-box ECU.
  • the engine ECU can initiate security authentication to the T-box.
  • the engine ECU can send a random number to the T-box ECU, and then the T-box replies with its own digital certificate and signs the random number with its own private key, so that the engine ECU can perform security on the T-box ECU Certification.
  • the engine ECU can determine whether to start the engine according to the matching degree of the certificate chains between itself and the T-box ECU.
  • ECU1 may be referred to as a first ECU
  • ECU2 may be referred to as a second ECU.
  • Digital certificate 1 may be referred to as a first digital certificate
  • digital certificate 2 may be referred to as a second digital certificate.
  • Public key 1 may be referred to as the first public key, and public key 2 may be referred to as the second public key.
  • Private key 1 may be referred to as the first private key, and private key 2 may be referred to as the second private key.
  • Each CA that issues digital certificate 1 may be referred to as a first CA, and each CA that issues digital certificate 2 may be referred to as a second CA.
  • the security level of the vehicle system can be improved.
  • the method does not need to distinguish between the main ECU and the key ECU, which reduces the storage space requirement.
  • the certificate chain matching degree in the security methods between ECUs is different, and the functions that ECU2 can access are different. This method avoids the waste of ECU resources caused by the single authentication result in the prior art, saves costs and resources, and improves user experience.
  • the ECU can also limit some functions and continue to operate, so that the ECU can be reused reasonably, saving costs and resources, and improving user experience.
  • equipment can be interchanged between vehicles of the same model, so that if a user needs to replace a certain vehicle equipment, it is not necessarily required to return to the factory for replacement or maintenance, which provides convenience for the user and the manufacturer.
  • a vehicle is scrapped, but the owner of the vehicle can replace the available on-board equipment in the scrapped vehicle with another vehicle, which saves both costs and resources.
  • the above-mentioned embodiments it may be implemented in whole or in part by software, hardware, firmware or any combination thereof.
  • software it can be implemented in whole or in part in the form of a computer program product.
  • the computer program product includes one or more computer instructions.
  • the computer program instructions when loaded and executed on a computer, result in whole or in part of the processes or functions described herein.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • the process can be completed by instructing the relevant hardware by a computer program, and the program can be stored in a computer-readable storage medium.
  • the program When the program is executed , which may include the processes of the foregoing method embodiments.
  • the aforementioned storage medium includes: ROM or random storage memory RAM, magnetic disk or optical disk and other mediums that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Bioethics (AREA)
  • Mathematical Physics (AREA)
  • Medical Informatics (AREA)
  • Lock And Its Accessories (AREA)

Abstract

车载设备的控制方法、车载设备及车辆系统。在该方法中，ECU之间利用数字证书来做ECU之间的安全认证，并根据证书链的匹配程度来确定当前允许访问的功能。利用数字证书可以提高车辆系统的安全等级。此外，该方法避免了认证结果单一性而导致的ECU资源浪费，节约成本及资源，提升用户体验。

Description

车载设备的控制方法、车载设备及车辆系统
本申请要求于2020年08月31日提交中国专利局、申请号为202010901662.1、申请名称为“车载设备的控制方法、车载设备及车辆系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及通信领域和信息安全领域，尤其涉及车载设备的控制方法、车载设备及车辆系统。
背景技术
目前，车辆系统上安装的电子控制单元(electronic control unit，ECU)的数量越来越多，极易出现ECU的非法替换、ECU程序的非法入侵和ECU关键数据的恶意篡改等问题。
为了解决上述问题，车辆系统采用对称密钥技术实现ECU之间的安全认证。在车辆系统中，两个ECU之间存储有相同的对称密钥。车辆运行时，一个ECU通过控制器局域网(controller area network，CAN)总线向另一个ECU发送随机数，另一个ECU使用存储的对称密钥对该随机数进行加密后得到返回值，并将返回值发送给该一个ECU。该ECU使用存储的与另一个ECU对应的对称密钥对该返回值进行解密，并将解密结果与随机数进行比对。若对比结果一致，则该ECU判定另一个ECU合法，否则判定为非法ECU并停止工作。
在车辆生产以及投入使用的过程中，对称密钥都极容易被恶意泄露或非法篡改，导致车辆系统的安全等级低。
发明内容
本申请提供了车载设备的控制方法、车载设备及车辆系统，可以提高车辆系统的安全等级。
第一方面，本申请提供了一种车载设备的控制方法，该方法应用于包括第一ECU和第二ECU的车辆系统，该第一ECU存储第一数字证书和第一私钥，该第二ECU存储第二数字证书。该方法可以包括：该第一ECU向该第二ECU发送该第一数字证书，该第一数字证书包括第一公钥；该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令，该第一指令用于指示该第二ECU启动第一功能；该第二ECU使用该第一公钥对加密的该第一指令进行解密；该第二ECU根据第一颁发机构CA和该第二CA中包含的相同CA的数量，确定该第二ECU允许访问的功能；该第一CA为颁发该第一数字证书的CA，该第二CA为颁发该第二数字证书的CA；该第一CA、该第二CA的数量均为多个；该第一CA和该第二CA中包含的相同CA的数量越多，该第二ECU允许访问的功能的数量越多；如果该第二ECU允许访问的功能包括该第一功能，则该第二ECU启动该第一功能；如果该第二ECU允许访问的功能不包括该第一功能，则该第二ECU拒绝启动该第一功能。
实施第一方面的方法，利用数字证书来做ECU之间的安全认证，可以提高车辆系统的安全等级。此外，该方法无需区分主ECU和关键ECU，降低了对存储空间的要求。并且，ECU之间的安全方法中证书链匹配程度不同，ECU2可允许访问的功能不同，该方法避免了现有技术中认证结果单一性而导致的ECU资源浪费，节约成本及资源，提升用户体验。此外，一个车辆系统中的ECU被替换到其他车辆系统中后，该ECU还可以限制部分功能并继续运行，这样可以合理地再利用ECU，节约成本及资源，提升用户体验。
结合第一方面，在一些实施方式中，该第一ECU可以在接收到来自电子设备的第一消息之后，响应于该第一消息向该第二ECU发送该第一数字证书。该第一消息用于指示该第二ECU启动该第一功能。
例如，当第一ECU为车载T-box的ECU时，电子设备如手机可响应于用户操作向服务器发送远程控制指令，服务器将该远程控制指令转发至第一ECU，第一ECU接收到的该远程控制消息即为第一消息。这里，该服务器用于提供远程车辆控制服务。
结合第一方面，在一些实施方式中，该第二ECU启动或拒绝启动该第一功能之后，还可以将启动该第一功能的结果发送给该第一ECU；该第一ECU向该电子设备发送第二消息，该第二消息用于指示该第二ECU启动该第一功能的结果。这样可以使得电子设备输出该结果的提示信息，便于用户获知第二ECU启动第一功能的结果。
结合第一方面，在一些实施方式中，该车辆系统还包括显示屏，该第二ECU启动或拒绝启动该第一功能之后，该显示屏可以显示提示信息，该提示信息用于指示该第二ECU启动该第一功能的结果。这里，第二ECU可以直接将启动第一功能的结果发送给显示屏，也可以通过第一ECU将该结果发送给显示屏。这样可以使得用户直观地从车辆系统的显示屏上获知第二ECU的启动结果。
结合第一方面，在一些实施方式中，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令之前，还可以根据该第一CA和该第二CA中包含的相同CA的数量，确定该第一ECU允许访问的功能；该第一CA和该第二CA中包含的相同CA的数量越多，该第一ECU允许访问的功能的数量越多。在该第一ECU允许访问的功能包括指示该第二ECU启动该第一功能的情况下，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令。
结合第一方面，在一些实施方式中，该第一ECU还存储有第一证书链，该第二ECU还存储有第二证书链；该第一证书链包括该第一CA的数字证书，该第二证书链包括该第二CA的数字证书；该方法还包括：该第一ECU向该第二ECU发送该第一证书链。这样可以使得第二ECU根据双方证书链，来确定第一CA和第二CA的匹配程度。
结合第一方面，在一些实施方式中，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令之前，该方法还包括：该第一ECU确定该第二数字证书合法，且，该第二ECU为该第二数字证书的合法持有者。在第二ECU校验第一ECU的第一数字证书合法且第二ECU为该第一数字证书的合法持有者的情况下，该第二ECU才会和第一ECU进行交互，这样可以提高车辆系统内部的安全等级。
结合第一方面，在一些实施方式中，该第二ECU使用该第一公钥对加密的该第一指令进行解密之前，该方法还包括：该第二ECU确定该第一数字证书合法，且，该第一ECU为该第一数字证书的合法持有者。在第一ECU校验第二ECU的第二数字证书合法且第一ECU为该第二数字证书的合法持有者的情况下，该第一ECU才会和第二ECU进行交互，这样可以提高车辆系统内部的安全等级。
结合第一方面，在一些实施方式中，该第二ECU确定该第一数字证书合法，具体包括：该第二ECU确定该第一数字证书是由受信任的CA颁发的；或者，该第二ECU确定该第一数字证书是由受信任的CA颁发的，且在有效期内。
在一些实施方式中，在该第一私钥和该第一公钥为密钥对时，该第一ECU为该第一数字证书的合法持有者。
在一些实施方式中，该第一ECU还可以向该第二ECU发送第一签名，该第一签名为使用该第一私钥对随机数处理后得到；该第二ECU使用该第一公钥验证该第一签名；在验证结 果和该随机数相同的情况下，该第一私钥和该第一公钥为密钥对。
结合第一方面，在一些实施方式中，该第一CA或该第二CA包括以下一项或多项：根CA、车厂CA、品牌CA、型号CA、车辆CA或域CA。
结合第一方面，在一些实施方式中，该第一ECU为车载T-box的ECU，该第二ECU为发动机的ECU；或者，该第二ECU为车载T-box的ECU。
第二方面，本申请提供了一种车载设备的控制方法，该方法应用于第二ECU，该第二ECU存储第二数字证书。该方法可以包括：该第二ECU接收到该第一ECU发送的第一数字证书；该第一ECU存储该第一数字证书和第一私钥，该第一数字证书包括第一公钥；该第二ECU接收到该第一ECU发送的使用该第一私钥加密的第一指令，该第一指令用于指示该第二ECU启动第一功能；该第二ECU使用该第一公钥对加密的该第一指令进行解密；该第二ECU根据第一CA和该第二CA中包含的相同CA的数量，确定该第二ECU允许访问的功能；该第一CA为颁发该第一数字证书的CA，该第二CA为颁发该第二数字证书的CA；该第一CA、该第二CA的数量均为多个；该第一CA和该第二CA中包含的相同CA的数量越多，该第二ECU允许访问的功能的数量越多；如果该第二ECU允许访问的功能包括该第一功能，则该第二ECU启动该第一功能；如果该第二ECU允许访问的功能不包括该第一功能，则该第二ECU拒绝启动该第一功能。
结合第二方面，在一些实施方式中，该第二ECU启动或拒绝启动该第一功能之后，该方法还包括：该第二ECU将启动该第一功能的结果发送给该第一ECU。这样可以便于第一ECU将该结果发送给车载设备中的显示器或者电子设备如手机，便于用户获知第二ECU启动第一功能的结果。
结合第二方面，在一些实施方式中，该第二ECU启动或拒绝启动该第一功能之后，该方法还包括：该第二ECU将启动该第一功能的结果发送给车载系统中的显示屏，以使得该显示屏显示提示信息，该提示信息用于指示该第二ECU启动该第一功能的结果。这样可以便于用户获知第二ECU启动第一功能的结果。
结合第二方面，在一些实施方式中，该第一ECU还存储有该第一证书链，该第二ECU还存储有该第二证书链；该第一证书链包括该第一CA的数字证书，该第二证书链包括该第二CA的数字证书；该方法还包括：该第二ECU接收到该第一ECU发送的该第一证书链，第二ECU根据双方证书链，来确定第一CA和第二CA的匹配程度。
结合第二方面，在一些实现方式中，该第二ECU使用该第一公钥对加密的该第一指令进行解密之前，该方法还包括：该第二ECU确定该第一数字证书合法，且，该第一ECU为该第一数字证书的合法持有者。在第二ECU校验第一ECU的第一数字证书合法且第二ECU为该第一数字证书的合法持有者的情况下，该第二ECU才会和第一ECU进行交互，这样可以提高车辆系统内部的安全等级。
在一些实施方式中，该第二ECU确定该第一数字证书合法，具体包括：该第二ECU确定该第一数字证书是由受信任的CA颁发的；或者，该第二ECU确定该第一数字证书是由受信任的CA颁发的，且在有效期内。
在一些实施方式中，在该第一私钥和该第一公钥为密钥对时，该第一ECU为该第一数字证书的合法持有者。
在一些实施方式中，该第二ECU确定该第一私钥和该第一公钥为密钥对之前，还可以接收到该第一ECU发送的第一签名，该第一签名为使用该第一私钥对随机数处理后得到；该第二ECU使用该第一公钥验证该第一签名；在验证结果和该随机数相同的情况下，该第一私钥 和该第一公钥为密钥对。
结合第二方面，在一些实施方式中，该第一CA或该第二CA包括以下一项或多项：根CA、车厂CA、品牌CA、型号CA、车辆CA或域CA。
结合第二方面，在一些实施方式中，该第一ECU为车载T-box的ECU，该第二ECU为发动机的ECU；或者，该第二ECU为车载T-box的ECU。
第三方面，本申请提供了一种车载设备的控制方法，该方法应用于第一ECU，该第一ECU存储第一数字证书和第一私钥。该方法可以包括：该第一ECU向该第二ECU发送该第一数字证书，该第一数字证书包括第一公钥；该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令，该第一指令用于指示该第二ECU启动第一功能；
结合第三方面，在一些实施方式中，该第一ECU可以在接收到来自电子设备的第一消息之后，响应于该第一消息向该第二ECU发送该第一数字证书。该第一消息用于指示该第二ECU启动该第一功能。
例如，当第一ECU为车载T-box的ECU时，电子设备如手机可响应于用户操作向服务器发送远程控制指令，服务器将该远程控制指令转发至第一ECU，第一ECU接收到的该远程控制消息即为第一消息。这里，该服务器用于提供远程车辆控制服务。
结合第三方面，在一些实施方式中，第二ECU还可以接收到该第二ECU发送的启动该第一功能的结果，并向该电子设备发送第二消息，该第二消息用于指示该第二ECU启动该第一功能的结果。这样可以使得电子设备输出该结果的提示信息，便于用户获知第二ECU启动第一功能的结果。
结合第三方面，在一些实施方式中，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令之前，该方法还包括：该第一ECU根据该第一CA和该第二CA中包含的相同CA的数量，确定该第一ECU允许访问的功能；该第一CA和该第二CA中包含的相同CA的数量越多，该第一ECU允许访问的功能的数量越多。在该第一ECU允许访问的功能包括指示该第二ECU启动该第一功能的情况下，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令。
结合第三方面，在一些实施方式中，该第一ECU还存储有第一证书链，该第二ECU还存储有第二证书链；该第一证书链包括该第一CA的数字证书，该第二证书链包括该第二CA的数字证书。该第一ECU还可以向该第二ECU发送该第一证书链。这样可以使得第二ECU根据双方证书链，来确定第一CA和第二CA的匹配程度。
结合第三方面，在一些实施方式中，该第一ECU向该第二ECU发送使用该第一私钥加密的第一指令之前，该方法还包括：该第一ECU确定该第二数字证书合法，且，该第二ECU为该第二数字证书的合法持有者。这样可以提高车辆系统内部的安全等级。
结合第三方面，在一些实施方式中，该第一ECU还可以向该第二ECU发送第一签名，该第一签名为使用该第一私钥对随机数处理后得到。这样可以使得第二ECU验证第一ECU是否是第一数字证书的合法持有者。
结合第三方面，在一些实施方式中，该第一ECU为车载T-box的ECU，该第二ECU为发动机的ECU；或者，该第二ECU为车载T-box的ECU。
第四方面，本申请提供了一种车辆系统，该车辆系统包括第一ECU和第二ECU，所述车辆系统用于执行如第一方面或第一方面任意一种实施方式所描述的方法。
第五方面，本申请提供了一种ECU，包括：安全芯片、一个或多个处理器和一个或多个存储器；所述安全芯片、所述一个或多个存储器与所述一个或多个处理器耦合；其中，所述 安全芯片用于存储第二数字证书；所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，使得所述ECU执行如第二方面或第二方面任意一种实施方式所描述的方法。
第六方面，本申请提供了一种ECU，包括：安全芯片、一个或多个处理器和一个或多个存储器；所述安全芯片、所述一个或多个存储器与所述一个或多个处理器耦合；其中，所述安全芯片用于存储第一数字证书；所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，使得所述ECU执行如第三方面或第三方面任意一种实施方式所描述的方法。
第七方面，本申请提供了一种车机系统，包括如第五方面的ECU和通信接口，所述通信接口用于和互联网服务器通信。
第八方面，本申请提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述第二方面或第二方面任意一种实施方式所描述的方法。
第九方面，本申请提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述第二方面或第二方面任意一种实施方式所描述的方法。
第十方面，本申请提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述第三方面或第三方面任意一种实施方式所描述的方法。
第十一方面，本申请提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述第三方面或第三方面任意一种实施方式所描述的方法。
实施本申请提供的技术方案，利用数字证书来做ECU之间的安全认证，可以提高车辆系统的安全等级。此外，该方法无需区分主ECU和关键ECU，降低了对存储空间的要求。并且，ECU之间的安全方法中证书链匹配程度不同，ECU2可允许访问的功能不同，该方法避免了现有技术中认证结果单一性而导致的ECU资源浪费，节约成本及资源，提升用户体验。此外，一个车辆系统中的ECU被替换到其他车辆系统中后，该ECU还可以限制部分功能并继续运行，这样可以合理地再利用ECU，节约成本及资源，提升用户体验。
附图说明
图1为本申请实施例提供的车辆系统的结构示意图；
图2为本申请实施例提供的CA颁发数字证书的流程图；
图3为本申请实施例提供的数字证书颁发体系的结构图；
图4为本申请实施例提供的车载设备的控制方法的流程示意图；
图5A-5B为本申请实施例提供的在电子设备上实现的一组用户界面；
图6为本申请实施例提供的判断证书链的匹配程度的流程图；
图7A-7C为本申请实施例提供在电子设备上实现的一组用户界面；
图8A-8C为本申请实施例提供的在车辆系统上实现的一组用户界面。
具体实施方式
下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。其中，在以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本申请实施例中“/”表示或的意思，“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。
以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
本申请实施例的说明书和权利要求书及附图中的术语“用户界面(user interface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。应用程序的用户界面是通过java、可扩展标记语言(extensible markup language，XML)等特定计算机语言编写的源代码，界面源代码在终端设备上经过解析，渲染，最终呈现为用户可以识别的内容，比如图片、文字、按钮等控件。控件(control)也称为部件(widget)，是用户界面的基本元素，典型的控件有工具栏(toolbar)、菜单栏(menu bar)、文本框(text box)、按钮(button)、滚动条(scrollbar)、图片和文本。界面中的控件的属性和内容是通过标签或者节点来定义的，比如XML通过<Textview>、<ImgView>、<VideoView>等节点来规定界面所包含的控件。一个节点对应界面中一个控件或属性，节点经过解析和渲染之后呈现为用户可视的内容。此外，很多应用程序，比如混合应用(hybrid application)的界面中通常还包含有网页。网页，也称为页面，可以理解为内嵌在应用程序界面中的一个特殊的控件，网页是通过特定计算机语言编写的源代码，例如超文本标记语言(hyper text markup language，HTML)，层叠样式表(cascading style sheets，CSS)，java脚本(JavaScript，JS)等，网页源代码可以由浏览器或与浏览器功能类似的网页显示组件加载和显示为用户可识别的内容。网页所包含的具体内容也是通过网页源代码中的标签或者节点来定义的，比如HTML通过<p>、<img>、<video>、<canvas>来定义网页的元素和属性。
用户界面常用的表现形式是图形用户界面(graphic user interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。
目前，车辆系统中的各个ECU可以分为主ECU和关键ECU。主ECU的数量为一个，关键ECU的数量可以为多个。主ECU存储各个关键ECU的对称密钥，并通过背景技术中描述的方法来做验证。这种验证方式不仅安全等级低，而且主ECU需要较大的存储空间来存储多个关键ECU分别的对称密钥。此外，ECU的控制策略单一，主ECU对关键ECU的认证结果只有合法和非法两种情况，造成资源浪费，用户体验感差。
本申请以下实施例提供了车载设备的控制方法、车辆设备及车辆系统。在该方法中，车辆系统中的ECU1指示ECU2启动第一功能之前，双方要相互校验对方的数字证书的合法性，同时还要判断对方是否是数字证书的合法持有者。在双方相互确认对方的数字证书合法且对方为该数字证书的合法持有者时，ECU2根据双方证书链的匹配程度来确定ECU2可开放给ECU1使用的功能。如果第一功能包含在ECU2当前允许访问的功能中，则ECU2启动该第一功能。
实施本申请实施例提供的车载设备的控制方法，利用数字证书来做ECU之间的安全认证，可以提高车辆系统的安全等级。此外，该方法无需区分主ECU和关键ECU，降低了对存储空间的要求。并且，ECU之间的安全方法中证书链匹配程度不同，ECU2可允许访问的功能不同，该方法避免了现有技术中认证结果单一性而导致的ECU资源浪费，节约成本及资源，提升用户体验。此外，一个车辆系统中的ECU被替换到其他车辆系统中后，该ECU还 可以限制部分功能并继续运行，这样可以合理地再利用ECU，节约成本及资源，提升用户体验。
本申请后续的方法实施例中将详细解释数字证书、数字证书的合法性、数字证书的合法持有者、证书链、ECU的可开放功能等概念，在此暂不赘述。
首先，介绍本申请实施例中的车辆系统。
图1为本申请实施例提供的车辆系统10的结构示意图。
如图1所示，车辆系统10可以包括多个ECU、连接多个ECU的CAN总线11。该多个ECU例如可以包括：发动机ECU12，车载盒子(telematics box，T-box)的ECU13，变速器ECU14，行车记录仪ECU15，防抱死系统(antilock brake system，ABS)ECU 16等。
CAN总线11是一个广播类型的总线，可以用于任意两个ECU之间传输数据。在CAN总线11上的任何ECU都可以监听到CAN总线11上传输的所有数据。CAN总线11传输的帧可以包含数据帧、远程帧、错误帧、过载帧，不同的帧传输不同类型的数据。在本申请实施例中，CAN总线11可用于传输ECU在安全认证以及控制过程中涉及到的数据，安全认证及控制过程可参考后文实施例的详细描述。
ECU又称“行车电脑”、“车载电脑”等，它和普通的电脑一样，包括即"ECU就是车的大脑"。在本申请以下实施例中，ECU也可以被称为车载设备、行车电脑、车载电脑或其他名词，这里不做限制。以下实施例将以ECU为例进行描述。
车辆系统10中的各个ECU都可以包括多个功能，下面详细介绍。
发动机ECU12用于管理发动机，协调发动机的各个功能，例如可用于启动发动机、关闭发动机等等。发动机是为车辆提供动力的装置。发动机是将某一种型式的能量转换为机械能的机器，其作用是将液体或气体燃烧的化学能通过燃烧后转化为热能，再把热能通过膨胀转化为机械能并对外输出动力。发动机组成部分可以包括曲柄连杆机构和配气机构两大机构，以及冷却、润滑、点火、燃料供给、启动系统等五大系统。主要部件有气缸体、气缸盖、活塞、活塞销、连杆、曲轴、飞轮等。发动机的工作原理是根据与发动机相连的传感器的反馈信号来控制燃油混合和点火正时。即以发动机的转速、负荷为基础，经过ECU计算和处理，向喷油器、供油泵等发送动作指令，使每一个汽缸都有最合适的喷油量、喷油率和喷油时间，保证每一个汽缸进行最佳的燃烧。
T-box ECU13用于管理T-box。T-box主要用于和后台系统/电子设备(例如手机)通信。在电子设备端还可以实现车辆控制与车辆信息的显示。
T-box也可以被称为车机系统、远程信息处理器、车辆网关等等，本申请实施例对此不作限制。
当用户通过电子设备端的车辆控制应用程序(application，APP)发送控制指令时，后台系统(例如服务器)将接收到的该控制指令转发到T-box ECU13。T-box ECU13在获取到控制指令后，通过CAN总线11发送控制报文，以实现对车辆的控制。例如，启动发动机、打开空调、调整座椅至合适位置、打开汽车门/窗/灯/锁/喇叭/天窗等，最后反馈操作结果给电子设备。此外，T-box ECU13还可以通过CAN总线11读取各个ECU的数据，例如获取车况报告、行车报告、油耗统计、违章查询、位置轨迹、驾驶行为等数据，并通过网络将数据传输到后台系统，由后台系统转发给电子设备，以供用户查看。
变速器ECU14用于管理变速器。变速器可以用来改变发动机的转速和转矩的机构，它能固定或分档改变输出轴和输入轴传动比。变速器组成部分可以包含变速传动机构、操纵机构以及动力输出机构等。变速传动机构的主要作用是改变转矩和转速的数值和方向；操纵机 构的主要作用是控制传动机构，实现变速器传动比的变换，即实现换档，以达到变速变矩。
行车记录仪ECU15用于管理行车记录仪。行车记录仪组成部分可以包括主机、车速传感器、数据分析软件等。行车记录仪是指记录车辆行驶途中的影像及声音包括行车时间、速度、所在位置等相关资讯的仪器。在本申请实施例中，当车辆行驶时，车速传感器采集到车轮转速，并将车速信息通过CAN总线发送给行车记录仪。
ABS ECU16用于管理ECU。ABS是在车辆制动时，自动控制制动器制动力的大小，使车轮不被抱死，处于边滚边滑(滑移率在20％左右)的状态，以保证车轮与地面的附着力为最大值。在制动过程中，电子控制装置根据车轮转速传感器输入的车轮转速信号判定有车轮趋于抱死时，ABS就进入防抱死制动压力调节过程。
在本申请实施例中，各个ECU都存储有自己的私钥和数字证书。在一些实施例中，ECU还可以存储证书链。私钥、数字证书、证书链的详细解释将在后续实施例说明，在此暂不赘述。
在本申请实施例中的ECU之间可以进行安全认证。具体的，在车辆系统中的ECU1指示ECU2启动第一功能之前，双方要相互校验对方的数字证书的合法性，同时还要判断对方是否是数字证书持有者。在双方相互确认对方的数字证书合法且对方为该数字证书的合法持有者时，ECU2根据双方证书链的匹配程度来确定ECU2可开放给ECU1使用的功能。如果ECU1指示ECU2启动的第一功能包含在可允许访问的功能中，则ECU2启动第一功能。其中有关数字证书合法性、数字证书合法持有者、证书链匹配程度、ECU的可开放功能等概念将在后续实施例中详细说明。
ECU1、ECU2均可以是本申请实施例的车辆系统10中的任意一个ECU。
ECU1指示ECU2启动第一功能的场景例如可以包括：T-box ECU13控制发动机ECU12启动/关闭发动机，T-box ECU13控制变速器ECU14变速。
可以理解的是，本申请实施例示意的结构并不构成对车辆系统的具体限定。车辆系统可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
例如，不限于CAN总线，在其他一些实施例中，车辆系统的各个ECU可以通过其他方式来连接及通信。如，各个ECU还可以通过车载以太网(Ethernet)常用车载网络LIN、FlexRay及常用车载网络系统MOST(media oriented systems，MOST)总线等等，本申请实施例对此不做限制。以下实施例将以ECU之间通过CAN总线通信进行说明。
下面介绍本申请实施例提供的ECU的结构。
ECU可以由安全芯片、微处理器((microcontroller unit，MCU)、随机存取存储器(random access memory，RAM)、只读存储器(random-only memory，ROM)、输入/输出接口(I/O)、模拟/数字转换器(A/D转换器)以及输入、输出、整形、驱动等大规模集成电路组成。其中：
安全芯片用于存储ECU的数字证书和私钥。数字证书的详细解释可参考后续实施例的描述，这里暂不赘述。
A/D转换器是将模拟信号转成MCU可以处理的数字信号。传感器送出的信号大部分是模拟信号，A/D转换器的作用就是把经过输入回路的预处理过后的电压信号转换成数字信号，然后将转换后的数字信号送入MCU。
MCU，是ECU的中心。MCU根据需要把输入信号用内存程序和数据进行运算处理，并把处理结果送往输出回路。
RAM主要用来存储计算器操作时可变数据。例如用来存储计算机的输入、输出数据和计算机过程产生的中间数据等。当电源切断时，RAM数据均会消失。
ROM只能读出存储器，用来存储固定数据。例如厂家在车辆生产时一次性存入例如发动机喷油特性脉谱、点火特性脉谱等永久性存储的程序和数据。当电源切断时，ROM数据不会消失。
下面介绍本申请实施例涉及的数字证书、数字证书的合法性、数字证书的合法持有者、证书链等概念。
(1)数字证书
数字证书是指由数字证书颁发机构(certificate authority，CA)颁发的一种用于标识数字证书持有者身份信息的电子证书，它提供了一种验证通信对端身份的方式。
其中，CA是负责签发和管理数字证书的权威机构。CA作为网络中受信任的第三方，承担公钥体系中公钥的合法性检验的责任，包括验证数字证书申请设备的身份，管理和更新数字证书，维护数字证书吊销列表(已被吊销的数字证书)等。CA有自己的私钥和公钥，其中私钥用来为申请设备的数字证书签名，公钥用以验证数字证书是否是该CA所颁发的数字证书，即验证该数字证书是否合法。
数字证书的格式可以遵循不同的国际标准，例如X.509v3(1997)、X509v4(1997)、X.509v1(1988)以及由国际电信联盟制定的TUTrec.x.509V3等，本申请实施例对此不作限制。
图2示出了CA颁发数字证书流程。如图2所示，该流程可包括如下步骤：
1，申请设备生成对称密钥，该对称密钥包括一对公钥和私钥。
申请设备可以使用非对称加密算法生成一对公钥和私钥，其中私钥由申请设备自己保管，公钥可以告知多人。在这里，对称密钥也可以由CA代为生成。
2，申请设备向CA申请数字证书。
具体的，申请设备将CA发送申请文件，申请文件包括申请设备的公钥、身份标识等信息。该申请文件用于向CA申请数字证书。
3，CA生成申请设备的数字证书，并颁发给该申请设备。
在一些实施例中，步骤3之前，CA还可以确认申请设备1的发送的申请文件无误。
CA根据申请设备发送的申请文件创建数字文档，该数字文档可以包括申请设备的公钥、身份标识、该数字文档的有效日期、数字证书颁发机构名称等。然后，CA使用摘要算法计算该“数字文档”得到数字摘要。其次，CA用自己的私钥对数字摘要、数字文档以及计算数字摘要所使用的摘要算法签名以生成数字证书，数字证书签名过程相当于为数字证书中的内容进行“上锁”，以便证明数字证书是由CA颁发的。最后，将生成数字证书颁发给申请设备。其中，有效日期一般为自数字证书颁发日起的1-5年不等。
显然地，申请设备接收到的数字证书可包括：数字证书序列号、数字证书有效期、数字证书持有者的身份标识、数字证书持有者公钥以及颁发数字证书的CA的标识等信息。CA的标识例如可以是该CA的名称、编号等等。
申请设备接收到CA颁发的数字证书后，即可在通信过程中使用该数字证书进行身份认证，为通信双方提供安全可靠的通信。具体的，每个数字证书持有者都拥有一把仅为本人所知的私钥，用它进行解密和签名。同时拥有一把公钥并可以对外公开，用于加密和签名验证。当发送数据时，发送者使用接收方的公钥对数据加密，而接收方则使用自己的私钥解密。这样，数据就可以安全无误地到达目的地了，即使被第三方截获，由于没有相应的私钥，也无 法进行解密。
(2)数字证书的合法性
在一些实施例中，由受信任的权威CA颁发的数字证书为合法的数字证书，为合法的数字证书。
在另一些实施例中，由受信任的权威CA颁发且在有效期内的数字证书为合法的数字证书。
在本申请实施例中，可通过数字签名的方式来验证数字证书是否是由受信任的权威CA颁发的。具体的，验证方接收到数字证书后，可以使用数字证书中携带的权威CA对应的公钥对数字证书签名验证后得到数字摘要、摘要算法、数字文档。之后，验证方使用摘要算法计算数字文档得到新数字摘要，将该数字摘要与数字证书中的数字摘要进行对比。如果对比结果一致，则说明该数字证书的签名验证通过，该数字证书是该CA颁发的数字证书，即该数字证书合法。在其他一些实施例中，验证方还可进一步确认该数字证书是否在有效期内，若该数字证书是权威CA颁发的且在有效期内，则该数字证书合法。
(3)数字证书的合法持有者
申请设备向CA成功申请数字证书后，该申请设备成为该数字证书的合法持有者。
在后续过程中，该申请设备的数字证书可能被其他非法用户盗取、篡改等等，该其他非法用户不是该数字证书的合法持有者。显然地，数字证书的合法持有者只有一个。
申请设备申请数字证书时的私钥只有该申请设备拥有，因此，可以通过私钥来确认数字正式的合法持有者。具体的，如果对方拥有该私钥，则对方为数字证书的合法持有者。具体实现中，验证方可以向被验证方发送一个随机数，被验证方使用自己的私钥对该随机数加密后得到返回值，并将返回值发送给验证方。验证方使用被验证方公开的公钥对该随机数进行加密，若加密结果和返回值一致，则说明被验证方拥有其数字证书携带的公钥所对应的私钥，即被验证方是该数字证书的合法持有者。
在本申请实施例中，通信的两个ECU之间确认对方的数字证书合法且对方为该数字证书的合法持有者后，可以使用该数字证书来对传输的信息进行加密和解密，确保车辆系统中ECU之间传递信息的机密性、真实性。利用数字证书对信息进行加解密的过程可参考后续方法实施例的相关描述。
(4)本申请实施例提供的数字证书颁发体系
图3是本申请实施例提供的用于给车辆系统中各ECU颁发数字证书的体系的结构图。
如图3所示，本申请实施例的数字证书颁发体系采用多层次的分级结构。本申请对数字证书颁发体系的层级数量不作限制。
示例性地，车厂基于车辆信息构建的CA系统由上至下可以包括几层：根CA(Root CA)、车厂CA、品牌CA、型号CA、车辆CA、域CA。根CA有且仅有一个，车厂CA、品牌CA、型号CA、车辆CA、域CA均可以为一个或多个。具体数目可以根据车厂生产车辆信息构建，本申请对数字证书颁发体系每一层级的CA数量不做限制。
其中根CA是处于该数字证书办法系统中最顶端树根的位置，根CA是整个CA体系中最权威的第三方数字证书颁发机构。例如，在整个数字证书体系中，根CA可以自己给自己颁发数字证书(根证书)，即根CA可以自己证明自己的合法身份。
每一层级的CA都可以使用自己的私钥向下一层的CA颁发数字证书，从而一层一层往下颁发，最终向ECU颁发数字证书。根CA为车厂1CA颁发数字证书即代表根CA信任车厂1CA，车厂1CA为品牌1CA颁发数字证书即代表车厂1CA信任品牌1CA，以此传递信任 关系。
每一个CA向下一层的CA或ECU颁发数字证书的过程可参考图2，这里不再赘述。
例如，根CA可以用自己的私钥为下一层级的车厂CA(例如车厂1CA和车厂2CA)颁发数字证书，车厂CA获取到根CA颁发的数字证书即说明该车厂CA是受信任的。类似的，受信任的车厂CA(例如车厂1CA)可以为下一层级的品牌CA(例如品牌1CA、品牌2CA和品牌3CA)颁发数字证书。以此类推，受信任的品牌CA(例如品牌1CA)可以为下一层级的型号CA颁发数字证书，…，车辆CA(例如车辆1CA)可以为该车辆系统中的ECU(例如安全域1CA和安全域2CA)颁发数字证书，域CA(例如安全域1CA和其他域1CA)可以为该安全域管辖内的ECU颁发数字证书。
图3所示的CA层级结构以及设置方式仅为示例，可以包括更多或更少的层级。例如，在根CA和ECU之间可以包括安全域CA，也可以不包括安全域CA。
(5)证书链
基于图3所示的数字证书颁发体系结构图，接下来介绍基于该数字证书颁发体系建立的证书链。
每个拥有数字证书的设备都对应一个对应的证书链。证书链是一个有序的证书列表。在本申请实施例中，ECU的证书链中包含：该ECU的数字证书，和，颁发该数字证书涉及的全部CA的数字证书。证书链的存在方便了接收方能够验证发送者和发送者的证书链中所有CA是否值得信任。证书链由以下三个部分构成：根证书、中介证书和ECU的数字证书。其中：
根证书是指根CA用自己的私钥为自己签名并颁发的数字证书。根证书签名验证要用根CA的公钥。
中介证书是指根CA用自己的私钥为中介CA签名并颁发的数字证书。中介证书的签名验证要用根CA的公钥。中介证书里面包含了根证书的名称。中介CA为数字证书的颁发系统中，除根CA以外的其他层级的CA，例如车厂CA、品牌CA、型号CA、车辆CA和域CA。
ECU数字证书是指用上一层级的中介CA(域CA)的私钥签名并颁发的数字证书。ECU数字证书的签名验证需要使用域CA的公钥。ECU可以保存证书链，也可以在使用证书链时再通过查询获取证书链。
在本申请实施例提供的证书链中，根CA是整个CA系统中最权威可靠的数字证书颁发中心，也是证书链的起点。根CA的数字证书签发者就是自己本身。在多层级的中介CA中，除最高层级的中介CA的数字证书由根CA颁发外，其他中间层级的中介CA的数字证书需要用上一层级的中介CA的私钥签发，并用上一层级中介CA相应的公钥验证数字证书的合法性。
在本申请实施例中，在验证ECU数字证书的合法性时，需要一步步溯源到根证书。具体的，首先确认该数字证书是上一层CA(例如安全域1CA)颁发的合法数字证书，然后确认该上一层CA(例如安全域1CA)的合法性，...，以此类推，一直确认到ECU数字证书的原始颁发者(即根CA)的合法性。若该根CA是受信任的权威CA，则该ECU数字证书是合法的数字证书。
基于前文图1描述的车辆系统10、图2所示的数字证书的颁发过程、图3描述的数字证书颁发体系，下面描述本申请实施例提供的车载设备控制方法。
在该方法中，车辆系统中的ECU1指示ECU2启动第一功能之前，双方要相互校验对方 的数字证书的合法性，同时还要判断对方是否是数字证书持有者。在双方相互确认对方的数字证书合法且对方为该数字证书的合法持有者时，ECU2根据双方证书链的匹配程度来确定ECU2可开放给ECU1使用的功能。如果该第一功能包含在ECU2当前可允许访问的功能中，则ECU2启动该第一功能。
其中，ECU1、ECU2均可以是本申请实施例的车辆系统10中的任意一个ECU。例如，ECU1可以为T-box ECU13，ECU2可以为发动机ECU12。
ECU1和ECU2各自存储有自己的数字证书和私钥。ECU1的私钥称为私钥1，ECU2的私钥称为私钥2。
在本申请实施例中，ECU的数字证书包括：该ECU的公钥、颁发该数字证书的CA的标识。在一些实施例中，ECU的数字证书中还可包括：数字证书的有效期、序列号或持有者的身份标识等信息。ECU获取数字证书的过程可参考前文图2、图3以及相关描述。
参考图4，图4是本申请实施例提供的车载设备控制方法的流程图。
如图4所示，该方法可包括以下步骤：
S100-S108，ECU1和ECU2之间的双向认证过程。
ECU1和ECU2认证的内容包括验证对方数字证书的合法性、验证对方是数字证书合法持有者。在数字证书合法且对方为该数字证书的合法持有人时，可以确认该数字证书是受信任的权威CA颁发的，并且该数字证书不是第三方假冒的。只有双方数字证书合法，且对方是数字证书合法持有者，ECU之间才能基于该数字证书进行安全通信。其中，验证数字证书合法性和数字证书合法持有者的概念可以参考上文的详细说明。
S100，ECU1接收到第一消息，该第一消息用于指示ECU2启动第一功能。
第一消息可以是车辆系统10内的其他ECU发送给ECU1的，也可以是由外部设备发送给ECU1的，这里不作限制。
例如，当ECU1为T-box ECU13时，用户可以通过电子设备上安装的应用程序(application，APP)或者电脑端上的网页远程控制ECU1。具体的，电子设备可响应于用户操作向服务器发送远程控制指令，服务器将该远程控制指令转发至ECU1，ECU1接收到的该远程控制消息即为第一消息。这里，该服务器用于提供远程车辆控制服务。
下面结合本申请实施例提供的用户界面，解释ECU1接收到第一消息的场景。
图5A-图5B示例性示出了电子设备(例如手机)上实现的用户界面。
图5A示出了电子设备显示的用户界面300。如图5A所示，用户界面300中显示有：状态栏、具有常用应用程序图标的托盘、页面指示符、其他应用程序图标等等。不限于此，图5A所示的用户界面300还可包括导航栏、侧边栏等等。在一些实施例中，图5A示例性所示的用户界面300可以为主界面(Home screen)。
如图5A所示，其他应用程序图标例如可包括用于管理车辆的应用程序(例如“车辆通”)图标301等等。
如图5A所示，电子设备可以检测到作用于图标301上的用户操作(例如点击操作、触摸操作等等)，并响应于该用户操作，启动该图标301对应的用于管理车辆的应用程序(例如“车辆通”)，并显示该应用程序提供的用户界面400。
图5B示出了用户界面400的一种实现形式。用户界面400用于远程管理车辆。
如图5B所示，用户界面400中显示有：搜索栏410、控件420、常用控件431-433、控件440、信息展示栏450、菜单栏460。
搜索栏410可用于监听触摸操作、点击操作等，响应于该操作，电子设备可显示虚拟键 盘，以使得用户输入想要搜索的内容。
控件420用于监听用户操作(例如点击操作、触摸操作等等)，电子设备可响应于该用户操作，显示更多的功能控件，例如开启/关闭空调的控件、开启/关闭车内灯光的控件等等。
控件431可用于监听用户操作，响应于该用户操作，电子设备可通过服务器向车辆系统中的T-box ECU13发送指示开启/关闭发动机的消息。
控件432可用于监听用户操作，响应于该用户操作，电子设备可通过服务器向车辆系统中的T-box ECU13发送指示开启/关闭窗的消息。
控件433可用于监听用户操作，响应于该用户操作，电子设备可通过服务器向车辆系统中的T-box ECU13发送指示开启/关闭车门的消息。
控件440用于监听用户操作(例如点击操作、触摸操作等等)，电子设备可响应于该用户操作，显示更多的车辆信息，例如油量、今日跑量等等。
信息展示栏450可以包括：停车地点451、停车时间452、电子设备距离停车地距离453、导航信息454等等。
菜单栏可供用户切换不同页面以进行不同功能的操作。
结合图5B所述的用户界面400，S100中ECU1接收到的第一消息例如可以是：
(1)电子设备在控件431上检测到用户操作(例如点击操作、触摸操作等)，响应该操作向服务器发送用于开启/关闭发动机的控制指令后，由该服务器向T-box ECU13发送的用于开启/关闭发动机的控制指令。这里，T-box ECU13为ECU1，发动机ECU12为ECU2，第一功能为启动或关闭发动机。
(2)电子设备在控件432上检测到用户操作(例如点击操作、触摸操作等)，响应该操作向服务器发送用于开启/关闭车窗的控制指令后，由该服务器向T-box ECU13发送的用于开启/关闭车窗的控制指令。这里，T-box ECU13为ECU1，车身控制单元(body control module，BCM)为ECU2，第一功能为启动或关闭车窗。
(3)电子设备在控件433上检测到用户操作后(例如点击操作、触摸操作等)，响应该操作向服务器发送用于开启/关闭车门的控制指令后，由该服务器向T-box ECU13发送的用于开启/关闭车门的控制指令。这里，T-box ECU13为ECU1，BCM为ECU2，第一功能为启动或关闭车门。
S101，ECU1向ECU2发送报文a，报文a包括：ECU1的数字证书1、随机数r1。
具体的，本申请实施例中ECU1和ECU2通信时传输的报文均通过CAN总线11传输。
在本申请实施例中，ECU1和ECU2之间通信时传输的报文中均包含有发送方的标识和接收方的标识。由于CAN总线11上的所有ECU均能够收到在该CAN总线11上传输的报文，因此ECU收到报文后，可以通过发送方的标识获知该报文的发送方，通过接收方的标识获知该报文的接收方。例如，报文a中可包含ECU1的标识1和ECU2的标识2。其中，标识1或标识2均可以是一串数字、字母、符号的组合，例如可以为序列号、编号、名称等等。
为了描述简洁，后续实施例将不再解释报文中携带的发送方的标识和接收方标识。
在报文a中，数字证书1的颁发过程可参考前文对图2、图3的描述。数字证书1中包括：该ECU1的公钥、颁发该数字证书1的CA(例如安全域1CA)的标识。在一些实施例中，数字证书1中还可包括：数字证书1的有效期、序列号或持有者的身份标识等信息。
随机数r1可以由ECU1生成，也可以是已经约定的数字证书1或标识1中的某一个数字。
S102，ECU2验证数字证书1的合法性。
ECU1发送报文a后，CAN总线上的全部ECU均可以接收到该报文a。
具体的，ECU2接收到报文a后，使用颁发数字证书1的CA的公钥对数字证书1进行签名验证，若验证通过则说明数字证书1是合法的。ECU2验证数字证书1时，需要追溯到根证书。ECU2验证数字证书1的合法性的具体方式可参考前文关于数字证书的合法性、证书链的相关描述。
S103，ECU2确认数字证书1合法后，向ECU1回复报文b。报文b中包括：数字证书2、随机数r2、签名2。签名2是ECU2用自己的私钥2对随机数r1做的签名。
数字证书2的颁发过程可参考前文对图2、图3的描述。数字证书2中包括：该ECU2的公钥、颁发该数字证书2的CA(例如安全域1CA)的标识。在一些实施例中，数字证书2中还可包括：数字证书2的有效期、序列号或持有者的身份标识等信息。
随机数r2可以由ECU2生成，也可以是已经约定的数字证书2或标识2中的某一个数字。
签名2是ECU2用自己的私钥2对随机数r1做的签名，即通过算法对私钥2和随机数R1做处理。
S104，ECU1验证数字证书2的合法性。
具体的，ECU1可使用颁发数字证书2的CA的公钥对数字证书2进行签名验证，若验证通过则说明数字证书2是合法的。
S105，ECU1验证ECU2是否是数字证书2的合法持有者。
具体的，ECU1使用数字证书2携带的公钥2对签名2进行签名验证，若签名验证结果和S101中的随机数r1一致，则说明数字证书2携带的公钥2与私钥2是一对密钥，即ECU2是数字证书2的合法持有者。
S106，ECU1在确定数字证书2合法且ECU2为数字证书2的合法持有者后，向ECU2发送报文c，报文c中包括：ECU1的签名1。
签名1可以是ECU1使用自己的私钥1对随机数r2做的签名，也可以是对随机数r1和随机数r2同时做的签名。
可理解的，ECU1执行S106，即ECU1对ECU2的验证结果为：数字证书2合法且ECU2为数字证书2的合法持有者。
S107，ECU2验证ECU1是否为数字证书1的合法持有者。
ECU2验证ECU1是否为数字证书1合法持有者的过程可以参考步骤S105。
具体的，ECU2使用数字证书1携带的公钥1对签名1进行签名验证，若签名验证结果和S103中的随机数r2一致，或者，签名验证结果和随机数r2及r1一致，则说明数字证书1携带的公钥1与私钥1是一对密钥，即ECU1是数字证书1的合法持有者。
S108，ECU2向ECU1发送报文d。报文d中包括：ECU2对ECU1的认证结果。
报文d中ECU2的标识2用于指示报文d的发送方为ECU2，ECU1的标识1用于指示报文d是发送给ECU1的。
这里，ECU2对ECU1的安全认证结果可以有2种：数字证书1合法且ECU1是数字证书1的合法持有者、数字证书1合法但ECU1不是数字证书1的合法持有者。
除第一种验证结果为验证通过以外，其他验证结果均属于验证不通过。
通过上述步骤S100-S108，如果ECU2对ECU1的验证结果为数字证书1合法且ECU1是数字证书1的合法持有者，则ECU1和ECU2之间完成了双向认证过程。若双向认证失败，则ECU1和ECU2后续不会再通信。
在其他一些实施例中，上述步骤S101-S108可以被替换为：
ECU1向ECU2发送数字证书1、随机数r1、使用私钥1对随机数r1做的签名；
ECU2验证数字证书1的合法性，并且，验证ECU1是否是数字证书1的合法持有者；
在确定数字证书1合法且ECU1为数字证书1的合法持有者后，ECU2向ECU1发送数字证书2、随机数r2、使用私钥2对随机数r2做的签名；
ECU1验证数字证书2的合法性，并且，验证ECU2是否是数字证书2的合法持有者；
ECU1向ECU2发送对ECE的认证结果。
这里，ECU1对ECU2的安全认证结果可以有4种：数字证书2合法且ECU2是数字证书2的合法持有者、数字证书2合法但ECU2不是数字证书2的合法持有者、数字证书2不合法且ECU2不是数字证书2的合法持有者、ECU2是数字证书2的合法持有者但数字证书2不合法。
通过上述替换步骤，可以使得ECU1和ECU2之间的双向认证过程更为简洁，减少双方的交互流程，节约资源。
在本申请实施例中，ECU1和ECU2之间双向认证成功，即ECU1和ECU2的身份信息可以保证真实性，ECU1和ECU2之间可以进行进一步的通信，参考以下步骤S109-112。
可理解的，本申请实施例不限定上述S101-S108的执行顺序，只要ECU1在指示ECU2启动第一功能前完成对ECU的安全认证，且ECU2在根据该指示启动或拒绝第一功能前完成对ECU1的安全认证即可。
可理解的，ECU1和ECU2之间可以执行一次S101-S108之后，记录对对方的安全认证结果，这样在后续的其他ECU1和ECU2的交互过程中，就可以不用再次执行S101-S108所示的双向认证过程了。
不限于图4所示的ECU1在接收到第一消息时触发ECU1和ECU2之间的双向认证过程，在其他实施例中，ECU1和ECU2还可以周期性进行该双向认证过程，本申请实施例对此不作限制。
S109-S112，ECU1指示ECU2启动第一功能。
S109，ECU1向ECU2发送报文e。报文e中包括使用私钥1加密的第一指令，第一指令用于指示ECU2启动第一功能。
在一些实施例中，ECU1可以先使用哈希(hash)算法对第一指令进行计算，然后在使用私钥1对该第一指令进行加密。hash算法可以压缩第一指令的大小，提高通信效率。
本申请实施例对S109和S100-S108的先后顺序不作限制。
S110，ECU2收到报文e后，使用数字证书1中携带的公钥1对报文e进行解密，获取第一指令。
S111，ECU2根据双方证书链的匹配程度，确定当前ECU2允许访问的功能。
各个ECU可以预先存储自己的证书链，也可以从网络中查询自己的证书链，本申请实施例不作限制。也就是说，ECU2可以从本地获取到自己的证书链，也可以从网络中查询到自己的证书链。
ECU2还可以从ECU1处获取ECU1的证书链，或者，从网络中查询到ECU2的证书链。在一些实施例中，ECU1的证书链可以携带在上述S101、S106、S109中任意一个ECU1发送给ECU2的报文中，例如报文a、报文c或报文e中。在一些实施例中，ECU2获取到ECU1的证书链后，可以存储该ECU1的证书链。
双方证书链的匹配程度具体是指，双方证书链包含的相同CA(包括根CA和中介CA)的个数。双方证书链包含的相同CA的数量越多，匹配程度越高。
参考图6，图6示例性输出了ECU2判断双方证书链匹配程度的流程。如图所示，ECU2 由根CA开始，逐层往下判断双方CA是否相同，最终得到匹配程度的结果。匹配程度的结果例如可包括：
1、双方的根CA不同。即数字证书1和数字证书2是由不同的根CA颁发的。
2、双方的根CA相同，但车厂CA不同。即，数字证书1和数字证书2是由同一根CA、不同的车厂CA颁发的。也即是说，ECU1和ECU2属于不同的车厂。
3、双方的根CA、车厂CA相同，但品牌CA不同。即，ECU1和ECU2属于不同的品牌。
4、双方的根CA、车厂CA、品牌CA相同，但型号CA不同。即，ECU1和ECU2属于不同型号。
5、双方的根CA、车厂CA、品牌CA、型号CA相同，但车辆CA不同。即，ECU1和ECU2属于不同车辆。
6、双方的根CA、车厂CA、品牌CA、型号CA、车辆CA相同，但域CA不同。即，ECU1和ECU2属于不同域。
7、双方的根CA、车厂CA、品牌CA、型号CA、车辆CA、域CA相同。即，ECU1和ECU2属于同一域，ECU1和ECU2完全匹配。
在本申请实施例中，双方证书链的匹配程度越高，ECU2允许访问的功能的数量越多。ECU2允许访问的功能是指：ECU2所具备的功能中，当前可以开放的功能或者被授权使用的功能。
参考表1和表2，表1以ECU2为发动机ECU为例，示例性示出了双方匹配程度不同时，发动机ECU允许访问的功能。表2以ECU2为T-box ECU为例，示例性示出了双方匹配程度不同时，T-box ECU允许访问的功能。
编号 匹配结果 ECU2(发动机ECU)允许访问的功能
1 不同根CA 无
2 不同车厂 无
3 不同品牌 无
4 不同型号 启动、关闭
5 不同车辆 启动、关闭
6 不同域 启动、关闭
7 相同域 启动、关闭
表1
Figure PCTCN2021111911-appb-000001
表2
在一些实施例中，在双方证书链的匹配程度不同时，ECU受到限制的功能可以分为两类：ECU独立完成的功能(例如发动机ECU的启动功能或关闭功能)，和，ECU和其他设备交互完成的功能(例如T-box ECU根据远程指令控制其他ECU的功能)。
在一些实施例中，ECU1在执行S109之前，也可以根据双方的证书链的匹配程度确定ECU1允许访问的功能，并在“指示ECU2启动第一功能”这一项为当前ECU1允许访问的功能时，才执行S109。
S112，如果当前ECU2允许访问的功能包含第一指令指示的第一功能，则ECU2启动该第一功能，如果当前ECU2允许访问的功能不包含第一指令指示的第一功能，则ECU2拒绝启动该第一功能。
例如，若ECU2为发动机ECU，第一功能为启动发动机，且ECU1和ECU2的证书链完全匹配，则ECU2(即发动机ECU)启动发动机。
可选步骤S113，ECU2使用私钥2加密报文f，并将报文f发给ECU1。报文f中包括：第一功能的执行结果。
第一功能的执行结果可以为成功或者失败。
通过S113，ECU2可以通过公钥2解密报文f，从而获知ECU1执行第一功能的结果。
可选步骤S114，ECU1向电子设备发送第二消息，第二消息用于指示第一功能的执行结果。
具体的，ECU1可向服务器发送远程指令，该远程指令携带第一功能的执行结果。之后，由服务器将该远程指令发送给电子设备，电子设备接收到的该远程指令即为第二消息。
在一些实施例中，当ECU2启动第一功能失败时，第二消息还可进一步携带ECU1和ECU2双方证书链的匹配程度结果。这样可以便于后续用户获知ECU2启动第一功能失败的原因。
可选步骤S115，电子设备接收到第二消息，输出提示信息，该提示信息用于指示ECU1对第一功能的执行结果。
电子设备输出的提示信息可以包括但不限于：在用户界面上显示的可视化界面元素、音频、闪光灯或振动等等。
参考图7A-图7C，其示例性示出了电子设备在用户界面400中显示的提示信息。
如图7A所示，当ECU1成功启动第一功能时，用户界面400中可以显示有提示信息701。该提示信息701例如可以为文本(例如“成功启动发动机”)、图标、动画等等。
如图7B所示，当ECU1启动第一功能失败时，用户界面400中可以显示有提示信息702。该提示信息702例如可以为文本(例如“启动发动机失败，错误代码00001”)、图标、动画等等。这样，用户可通过查询车辆说明书中的代码解释，获知ECU1启动第一功能失败的原因。在其他一些实施例中，用户界面400中还可显示有控件703，控件703可用于监听用户操作，电子设备可响应于该用户操作显示启动失败的原因，例如显示如图7C所示的ECU1和ECU2的证书链匹配结果704。
可选步骤S116，车辆系统输出提示信息，该提示信息用于指示ECU1对第一功能的执行结果。
本申请实施例对S116和S114、S115的先后顺序不做限定。
具体的，ECU1获知ECU2对第一功能的执行结果后，可以将该执行结果通知到车辆系统内的相关设备，以使得相关设备输出提示信息。车辆系统输出的提示信息可以包括但不限于：在显示屏上显示的可视化界面元素、音频设备输出的音频、灯具输出的灯光、仪表盘输出的数据等等。
参考图8A-图8C，其示例性示出了车辆系统在显示屏(例如导航设备提供的显示屏)上显示的用户界面500。
如图8A所示，当ECU1成功启动第一功能时，用户界面500中可以显示有提示信息801。该提示信息801例如可以为文本(例如“成功启动发动机”)、图标、动画等等。
如图8B所示，当ECU1启动第一功能失败时，用户界面500中可以显示有提示信息802。该提示信息802例如可以为文本(例如“启动发动机失败，错误代码00001”)、图标、动画等等。这样，用户可通过查询车辆说明书中的代码解释，获知ECU1启动第一功能失败的原因。在其他一些实施例中，用户界面500中还可显示有控件803，控件803可用于监听用户操作，电子设备可响应于该用户操作显示启动失败的原因，例如显示如图8C所示的ECU1和ECU2的证书链匹配结果804。
不限于本申请上述实施例提供的ECU1指示ECU2启动第一功能之前，双方进行安全认证，在其他一些实施例中，主ECU在启动自身功能之前，也可以对其他关键ECU进行安全认证，并根据自身和其他关键ECU之间的证书链的匹配程度来确定是否启动该功能。
例如，主ECU可以为发动机ECU，关键ECU可包括T-box ECU。车辆系统接收到启动发动机的操作(例如用户点火的操作)时，发动机ECU可以对T-box发起安全认证。如，发动机ECU可以向T-box ECU发送随机数，然后由T-box回复自己的数字证书和使用自己的私钥对该随机数做的签名，以使得发动机ECU可以对T-box ECU做安全认证。发动机ECU对T-box ECU的安全认证通过后，发动机ECU可以根据自己和T-box ECU双方证书链的匹配程度，确定是否启动发动机。
这样可以在主ECU工作时，查看关键ECU是否被篡改或盗窃，可以保证行车安全。
在本申请实施例中，ECU1可以被称为第一ECU，ECU2可以被称为第二ECU。
数字证书1可以被称为第一数字证书，数字证书2可以被称为第二数字证书。
公钥1可以被称为第一公钥，公钥2可以被称为第二公钥。
私钥1可以被称为第一私钥，私钥2可以被称为第二私钥。
颁发数字证书1的各个CA可以被称为第一CA，颁发数字证书2的各个CA可以被称为第二CA。
实施本申请实施例提供的车载设备的控制方法，利用数字证书实现ECU之间的安全通信，可以提高车辆系统的安全等级。此外，该方法无需区分主ECU和关键ECU，降低了对存储空间的要求。并且，ECU之间的安全方法中证书链匹配程度不同，ECU2可允许访问的功能不同，该方法避免了现有技术中认证结果单一性而导致的ECU资源浪费，节约成本及资源，提升用户体验。此外，一个车辆系统中的ECU被替换到其他车辆系统中后，该ECU还可以限制部分功能并继续运行，这样可以合理地再利用ECU，节约成本及资源，提升用户体验。
例如，同一型号车辆之间可以互换设备，这样如果用户需要跟换某车载设备时，不一定必须要求返厂更换或者维修，这为用户为厂家提供了方便。又例如，某一车辆报废，但是车主可以将报废车辆中可用的车载设备更换到其他车辆中，既节约成本也节约资源。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、 或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。
总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (27)

  1. 一种车载设备的控制方法，其特征在于，所述方法应用于包括第一电子控制单元ECU和第二ECU的车辆系统，所述第一ECU存储第一数字证书和第一私钥，所述第二ECU存储第二数字证书；所述方法包括：
    所述第一ECU向所述第二ECU发送所述第一数字证书，所述第一数字证书包括第一公钥；
    所述第一ECU向所述第二ECU发送使用所述第一私钥加密的第一指令，所述第一指令用于指示所述第二ECU启动第一功能；
    所述第二ECU使用所述第一公钥对加密的所述第一指令进行解密；
    所述第二ECU根据第一颁发机构CA和所述第二CA中包含的相同CA的数量，确定所述第二ECU允许访问的功能；所述第一CA为颁发所述第一数字证书的CA，所述第二CA为颁发所述第二数字证书的CA；所述第一CA、所述第二CA的数量均为多个；所述第一CA和所述第二CA中包含的相同CA的数量越多，所述第二ECU允许访问的功能的数量越多；
    如果所述第二ECU允许访问的功能包括所述第一功能，则所述第二ECU启动所述第一功能；如果所述第二ECU允许访问的功能不包括所述第一功能，则所述第二ECU拒绝启动所述第一功能。
  2. 根据权利要求1所述的方法，其特征在于，所述第一ECU向所述第二ECU发送所述第一数字证书之前，所述方法还包括：
    所述第一ECU接收到来自电子设备的第一消息，所述第一消息用于指示所述第二ECU启动所述第一功能。
  3. 根据权利要求1或2所述的方法，其特征在于，所述第二ECU启动或拒绝启动所述第一功能之后，所述方法还包括：
    所述第二ECU将启动所述第一功能的结果发送给所述第一ECU；
    所述第一ECU向所述电子设备发送第二消息，所述第二消息用于指示所述第二ECU启动所述第一功能的结果。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述车辆系统还包括显示屏，所述第二ECU启动或拒绝启动所述第一功能之后，所述方法还包括：
    所述显示屏显示提示信息，所述提示信息用于指示所述第二ECU启动所述第一功能的结果。
  5. 根据权利要求1-4任一项所述的方法，其特征在于，所述第一CA或所述第二CA包括以下一项或多项：根CA、车厂CA、品牌CA、型号CA、车辆CA或域CA。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，
    所述第一ECU为车载T-box的ECU，所述第二ECU为发动机的ECU；或者，
    所述第二ECU为车载T-box的ECU。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，所述第一ECU向所述第二ECU 发送使用所述第一私钥加密的第一指令之前，所述方法还包括：所述第一ECU根据所述第一CA和所述第二CA中包含的相同CA的数量，确定所述第一ECU允许访问的功能；所述第一CA和所述第二CA中包含的相同CA的数量越多，所述第一ECU允许访问的功能的数量越多；
    所述第一ECU向所述第二ECU发送使用所述第一私钥加密的第一指令，具体包括：在所述第一ECU允许访问的功能包括指示所述第二ECU启动所述第一功能的情况下，所述第一ECU向所述第二ECU发送使用所述第一私钥加密的第一指令。
  8. 根据权利要求1-7任一项所述的方法，其特征在于，所述第一ECU还存储有第一证书链，所述第二ECU还存储有第二证书链；所述第一证书链包括所述第一CA的数字证书，所述第二证书链包括所述第二CA的数字证书；
    所述第二ECU确定所述第二ECU允许访问的功能之前，所述方法还包括：
    所述第一ECU向所述第二ECU发送所述第一证书链；
    所述第二ECU根据所述第一证书链和所述第二证书链，确定第一CA和所述第二CA中包含的相同CA的数量。
  9. 根据权利要求1-8任一项所述的方法，其特征在于，所述第一ECU向所述第二ECU发送使用所述第一私钥加密的第一指令之前，所述方法还包括：
    所述第一ECU确定所述第二数字证书合法，且，所述第二ECU为所述第二数字证书的合法持有者。
  10. 根据权利要求1-9任一项所述的方法，其特征在于，所述第二ECU使用所述第一公钥对加密的所述第一指令进行解密之前，所述方法还包括：
    所述第二ECU确定所述第一数字证书合法，且，所述第一ECU为所述第一数字证书的合法持有者。
  11. 根据权利要求10所述的方法，其特征在于，所述第二ECU确定所述第一数字证书合法，具体包括：
    所述第二ECU确定所述第一数字证书是由受信任的CA颁发的；
    或者，
    所述第二ECU确定所述第一数字证书是由受信任的CA颁发的，且在有效期内。
  12. 根据权利要求10或11所述的方法，其特征在于，所述第二ECU确定所述第一ECU为所述第一数字证书的合法持有者，具体包括：
    所述第二ECU确定所述第一私钥和所述第一公钥为密钥对。
  13. 根据权利要求12所述的方法，其特征在于，所述第二ECU确定所述第一私钥和所述第一公钥为密钥对之前，所述方法还包括：
    所述第一ECU向所述第二ECU发送第一签名，所述第一签名为使用所述第一私钥对随机数处理后得到；
    所述第二ECU使用所述第一公钥验证所述第一签名；在验证结果和所述随机数相同的情 况下，所述第一私钥和所述第一公钥为密钥对。
  14. 一种车载设备的控制方法，其特征在于，所述方法应用于第二电子控制单元ECU，所述第二ECU存储第二数字证书；所述方法包括：
    所述第二ECU接收到所述第一ECU发送的第一数字证书；所述第一ECU存储所述第一数字证书和第一私钥，所述第一数字证书包括第一公钥；
    所述第二ECU接收到所述第一ECU发送的使用所述第一私钥加密的第一指令，所述第一指令用于指示所述第二ECU启动第一功能；
    所述第二ECU使用所述第一公钥对加密的所述第一指令进行解密；
    所述第二ECU根据第一颁发机构CA和所述第二CA中包含的相同CA的数量，确定所述第二ECU允许访问的功能；所述第一CA为颁发所述第一数字证书的CA，所述第二CA为颁发所述第二数字证书的CA；所述第一CA、所述第二CA的数量均为多个；所述第一CA和所述第二CA中包含的相同CA的数量越多，所述第二ECU允许访问的功能的数量越多；
    如果所述第二ECU允许访问的功能包括所述第一功能，则所述第二ECU启动所述第一功能；如果所述第二ECU允许访问的功能不包括所述第一功能，则所述第二ECU拒绝启动所述第一功能。
  15. 根据权利要求14所述的方法，其特征在于，所述第二ECU启动或拒绝启动所述第一功能之后，所述方法还包括：
    所述第二ECU将启动所述第一功能的结果发送给所述第一ECU。
  16. 根据权利要求14或15所述的方法，其特征在于，所述第二ECU启动或拒绝启动所述第一功能之后，所述方法还包括：
    所述第二ECU将启动所述第一功能的结果发送给车载系统中的显示屏，以使得所述显示屏显示提示信息，所述提示信息用于指示所述第二ECU启动所述第一功能的结果。
  17. 根据权利要求14-16任一项所述的方法，其特征在于，所述第一CA或所述第二CA包括以下一项或多项：根CA、车厂CA、品牌CA、型号CA、车辆CA或域CA。
  18. 根据权利要求14-17任一项所述的方法，其特征在于，
    所述第一ECU为车载T-box的ECU，所述第二ECU为发动机的ECU；或者，
    所述第二ECU为车载T-box的ECU。
  19. 根据权利要求14-18任一项所述的方法，其特征在于，所述第一ECU还存储有所述第一证书链，所述第二ECU还存储有所述第二证书链；所述第一证书链包括所述第一CA的数字证书，所述第二证书链包括所述第二CA的数字证书；
    所述第二ECU确定所述第二ECU允许访问的功能之前，所述方法还包括：
    所述第二ECU接收到所述第一ECU发送所述第一证书链；
    所述第二ECU根据所述第一证书链和所述第二证书链，确定第一CA和所述第二CA中包含的相同CA的数量。
  20. 根据权利要求14-19任一项所述的方法，其特征在于，所述第二ECU使用所述第一公钥对加密的所述第一指令进行解密之前，所述方法还包括：
    所述第二ECU确定所述第一数字证书合法，且，所述第一ECU为所述第一数字证书的合法持有者。
  21. 根据权利要求20所述的方法，其特征在于，所述第二ECU确定所述第一数字证书合法，具体包括：
    所述第二ECU确定所述第一数字证书是由受信任的CA颁发的；
    或者，
    所述第二ECU确定所述第一数字证书是由受信任的CA颁发的，且在有效期内。
  22. 根据权利要求20或21所述的方法，其特征在于，所述第二ECU确定所述第一ECU为所述第一数字证书的合法持有者，具体包括：
    所述第二ECU确定所述第一私钥和所述第一公钥为密钥对。
  23. 根据权利要求22所述的方法，其特征在于，所述第二ECU确定所述第一私钥和所述第一公钥为密钥对之前，所述方法还包括：
    所述第二ECU接收到所述第一ECU发送的第一签名，所述第一签名为使用所述第一私钥对随机数处理后得到；
    所述第二ECU使用所述第一公钥验证所述第一签名；在验证结果和所述随机数相同的情况下，所述第一私钥和所述第一公钥为密钥对。
  24. 一种车辆系统，其特征在于，所述车辆系统包括第一电子控制单元ECU和第二ECU，所述车辆系统用于执行如权利要求1-13任一项所述的方法。
  25. 一种电子控制单元ECU，其特征在于，包括：安全芯片、一个或多个处理器和一个或多个存储器；所述安全芯片、所述一个或多个存储器与所述一个或多个处理器耦合；其中，
    所述安全芯片用于存储第二数字证书；
    所述一个或多个存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述一个或多个处理器执行所述计算机指令时，使得所述ECU执行如权利要求14-23任一项所述的方法。
  26. 一种车机系统，其特征在于，包括如权利要求25所述的ECU和通信接口，所述通信接口用于和互联网服务器通信。
  27. 一种计算机可读存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求14-23任一项所述的方法。
PCT/CN2021/111911 2020-08-31 2021-08-10 车载设备的控制方法、车载设备及车辆系统 WO2022042298A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21860137.5A EP4195078A4 (en) 2020-08-31 2021-08-10 CONTROL METHOD FOR VEHICLE MOUNTED DEVICE, VEHICLE MOUNTED DEVICE AND VEHICLE SYSTEM
US18/043,229 US20240028692A1 (en) 2020-08-31 2021-08-10 Vehicle-Mounted Device Control Method, Vehicle-Mounted Device, and Vehicle System

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010901662.1 2020-08-31
CN202010901662.1A CN112131572B (zh) 2020-08-31 2020-08-31 车载设备的控制方法、车载设备及车辆系统

Publications (1)

Publication Number Publication Date
WO2022042298A1 true WO2022042298A1 (zh) 2022-03-03

Family

ID=73848784

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/111911 WO2022042298A1 (zh) 2020-08-31 2021-08-10 车载设备的控制方法、车载设备及车辆系统

Country Status (4)

Country Link
US (1) US20240028692A1 (zh)
EP (1) EP4195078A4 (zh)
CN (1) CN112131572B (zh)
WO (1) WO2022042298A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112131572B (zh) * 2020-08-31 2022-12-27 华为技术有限公司 车载设备的控制方法、车载设备及车辆系统
CN114978875A (zh) * 2021-02-23 2022-08-30 广州汽车集团股份有限公司 一种车载节点管理方法、装置及存储介质
CN114844627A (zh) * 2021-06-28 2022-08-02 长城汽车股份有限公司 一种车辆密钥防盗方法、系统、电子设备及车辆
US20230186692A1 (en) * 2021-12-13 2023-06-15 Gm Cruise Holdings Llc Device registration and certificate management for autonomous vehicles

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019145488A1 (en) * 2018-01-29 2019-08-01 Nagravision S.A Secure communication between in-vehicle electronic control units
CN110635893A (zh) * 2019-09-21 2019-12-31 吉林大学 一种车载以太网信息安全防护方法
CN110769393A (zh) * 2019-11-07 2020-02-07 公安部交通管理科学研究所 一种车路协同的身份认证系统及方法
CN111131313A (zh) * 2019-12-31 2020-05-08 北京邮电大学 智能网联汽车更换ecu的安全保障方法及系统
CN112131572A (zh) * 2020-08-31 2020-12-25 华为技术有限公司 车载设备的控制方法、车载设备及车辆系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6217728B2 (ja) * 2015-10-19 2017-10-25 トヨタ自動車株式会社 車両システムおよび認証方法
CN109417480A (zh) * 2016-06-17 2019-03-01 Kddi株式会社 系统、认证站、车载计算机、车辆、公开密钥证书发行方法以及程序
CN107919955B (zh) * 2017-12-28 2021-02-26 北京奇虎科技有限公司 一种车辆网络安全认证方法、系统、车辆、装置及介质
CN110891257B (zh) * 2019-11-26 2023-08-08 成都信息工程大学 一种具有防攻击双向认证的网联车远程升级系统及方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019145488A1 (en) * 2018-01-29 2019-08-01 Nagravision S.A Secure communication between in-vehicle electronic control units
CN110635893A (zh) * 2019-09-21 2019-12-31 吉林大学 一种车载以太网信息安全防护方法
CN110769393A (zh) * 2019-11-07 2020-02-07 公安部交通管理科学研究所 一种车路协同的身份认证系统及方法
CN111131313A (zh) * 2019-12-31 2020-05-08 北京邮电大学 智能网联汽车更换ecu的安全保障方法及系统
CN112131572A (zh) * 2020-08-31 2020-12-25 华为技术有限公司 车载设备的控制方法、车载设备及车辆系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4195078A4

Also Published As

Publication number Publication date
CN112131572B (zh) 2022-12-27
CN112131572A (zh) 2020-12-25
US20240028692A1 (en) 2024-01-25
EP4195078A1 (en) 2023-06-14
EP4195078A4 (en) 2024-04-10

Similar Documents

Publication Publication Date Title
WO2022042298A1 (zh) 车载设备的控制方法、车载设备及车辆系统
US11662991B2 (en) Vehicle-mounted device upgrade method and related device
US11985238B2 (en) Vehicle-mounted device upgrade method and related device
WO2021092745A1 (zh) 一种设备升级方法及相关设备
US20220094696A1 (en) Secure compliance protocols
US20180212937A1 (en) Method and Device for Communicating Securely between T-Box Device and ECU Device in Internet of Vehicles System
CN106685653B (zh) 一种基于信息安全技术的车辆远程固件更新方法及装置
WO2020211016A1 (zh) 一种设备升级方法及相关设备
WO2010019568A1 (en) System and method for using networked mobile devices in vehicles
WO2020259169A1 (zh) 认证方法、设备及系统
EP4089978A1 (en) Authentication method and apparatus for vehicle-mounted device
CN113794734A (zh) 车载can总线加密通信方法、控制装置和可读存储介质
CN113259933B (zh) 一种密钥更新的方法、网关、控制装置、电子设备及介质
WO2022151478A1 (zh) 车辆密钥管理方法、设备及其系统
CN115486107A (zh) 用于针对v2x实体的网络安全态势建立信任的方法和系统
KR102115305B1 (ko) 자동차 이력 정보 관리 컴퓨터 프로그램 및 장치
CN112087419A (zh) 一种车载终端数据传输安全防护方法和设备
Kathiresh et al. Vehicle diagnostics over internet protocol and over-the-air updates
Schweppe Security and privacy in automotive on-board networks
He et al. Application of SecOC Based on SM4 Algorithm for Communication Security of Bus in Vehicle
Wei et al. Authenticated can communications using standardized cryptographic techniques
CN116318896A (zh) 电子控制单元及其控制方法、电子设备和存储介质
Schramm et al. Secure feature activation
CN117195202A (zh) 应用验签方法、装置、车辆和存储介质
WO2022171468A1 (fr) Procédé de vérification de l&#39;authenticité d&#39;une commande d&#39;un actionneur

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18043229

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2021860137

Country of ref document: EP

Effective date: 20230308

NENP Non-entry into the national phase

Ref country code: DE