WO2023151582A1 - 针对车辆的安全通信方法、相关装置及通信系统 - Google Patents

针对车辆的安全通信方法、相关装置及通信系统 Download PDF

Info

Publication number
WO2023151582A1
WO2023151582A1 PCT/CN2023/074973 CN2023074973W WO2023151582A1 WO 2023151582 A1 WO2023151582 A1 WO 2023151582A1 CN 2023074973 W CN2023074973 W CN 2023074973W WO 2023151582 A1 WO2023151582 A1 WO 2023151582A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
control device
vehicle control
key
data
Prior art date
Application number
PCT/CN2023/074973
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
Priority claimed from CN202210751865.6A external-priority patent/CN116633531A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2023151582A1 publication Critical patent/WO2023151582A1/zh

Links

Classifications

    • 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

Definitions

  • the present application relates to the technical field of communication, and in particular to a safety communication method for vehicles, a related device and a communication system.
  • This application provides a safe communication method, related devices and communication system for vehicles, which can ensure that only the two parties can obtain the data interacted between the vehicle control equipment and the vehicle, and prevent the interactive data from being obtained, tampered with or forged by a third party, and can protect the vehicle and the vehicle.
  • the information security of both sides of the vehicle control equipment improves the safety of the vehicle.
  • a safety communication method for a vehicle is provided, which is applied to a communication system including a vehicle control device and a vehicle.
  • the method includes: the vehicle control device generates first data to be sent, and encrypts the first data by using a first key; the vehicle control device sends the encrypted first data to the vehicle; the vehicle receives the encrypted data sent by the vehicle control device the encrypted first data; the vehicle uses the first key to decrypt the encrypted first data to obtain the first data; the vehicle performs corresponding operations according to the first data.
  • the vehicle control device and the vehicle communicate based on the key, which is equivalent to establishing a point-to-point security channel between the vehicle control device and the vehicle, which can ensure that the data exchanged between the two parties is only the vehicle control device and the vehicle It can be obtained to prevent the interaction data of both parties from being obtained, tampered with or forged by a third party.
  • the information security of both the vehicle and the vehicle control equipment can be guaranteed, thereby avoiding the leakage of the private data of the user in the vehicle, the control of the vehicle by a third party, the loss of the vehicle, and the control of multiple vehicles in batches by a third party, etc., and improving the safety of the vehicle.
  • the third party here refers to the vehicle control equipment, other equipment or institutions other than the vehicle.
  • the first data includes remote control instructions, which are used to instruct the vehicle to perform corresponding operations; or, the first data includes remote monitoring instructions, which are used to inquire about the status of the vehicle .
  • the second data may include data characterizing the state of the vehicle, and/or, operating data of the vehicle.
  • the vehicle control device and the vehicle can obtain the first key in the following manner:
  • Mode 2 After the vehicle control device determines the first key, it sends the first key to the vehicle;
  • the vehicle control device and the vehicle negotiate the first key through short-distance communication technology.
  • Both the vehicle control device and the vehicle generate a shared key according to the binding factor
  • the ECDH algorithm can ensure that the vehicle control device and the vehicle can safely know the public key of the peer device, and combined with the private key that only the local device knows, the vehicle control device and the vehicle can obtain a secure key known only to both parties. the first key of .
  • the near-field communication technology enables the vehicle control device and the vehicle to obtain the first key through negotiation conveniently and quickly.
  • the vehicle control device disconnects from the server, and the vehicle may also disconnect from the server, and the server is used to manage the vehicle. Since the connection between the vehicle control device and the vehicle and the server is cut off, even if there is a security hole in the server, it can also ensure that the first key negotiated by both parties is not obtained by the server, thereby ensuring the security of the subsequent communication process based on the first key.
  • the vehicle control device and the vehicle negotiate the first key through long-distance communication technology.
  • the vehicle control device and the vehicle negotiate to obtain the first key through the elliptic curve Diffie-Hellman key exchange ECDH algorithm, and the vehicle control device and the vehicle communicate through the server during the negotiation process, and the server is used to manage the vehicle.
  • the ECDH algorithm can ensure that the vehicle control device and the vehicle can safely know the public key of the peer device, and combined with the private key that only the local device knows, the vehicle control device and the vehicle can obtain a secure key known only to both parties. the first key of .
  • the method further includes Including: the vehicle control device and the vehicle are associated with storing the vehicle's identification, and the first key.
  • the vehicle control device can find the first key corresponding to the vehicle according to the associated stored information, and use the first key to process (including encrypt or decrypt) the data communicated with the vehicle.
  • the vehicle can find the first key corresponding to the vehicle control device according to the associated stored information, and use the first key to process (including encrypt or decrypt) the data communicated with the vehicle control device.
  • the vehicle control device and the vehicle use the same account to log in to the server, and the server is used to manage the vehicle.
  • This is equivalent to establishing a point-to-point secure channel between the vehicle control device logged in with a specific account and the vehicle logged in with a specific account, which can avoid The communication data between them is obtained, tampered with or forged by a third party.
  • the vehicle control device may display a first user interface, and the first user interface includes one or more control options; the vehicle control device receives A user operation acting on the control option, the user operation is used to trigger the vehicle control device to generate the first data to be sent.
  • the communication data between the vehicle control device and the vehicle may be forwarded through the server.
  • the encryption algorithm used may be selected according to actual requirements. For example, if there is a requirement for the integrity of the transmitted data, an algorithm that ensures the integrity of the data can be used to encrypt the data; if there is a requirement for the confidentiality of the transmitted data, an algorithm that can ensure the confidentiality of the data can be used to encrypt data.
  • a secure communication method for vehicles is provided, which is applied to a vehicle control device.
  • the method includes: the vehicle control device generates first data to be sent, and uses a first key to encrypt the first data; the vehicle control device The device sends the encrypted first data to the vehicle.
  • the method further includes: the vehicle control device receives the encrypted second data sent by the vehicle; the vehicle control device uses the first key to decrypt the encrypted second data to obtain the second data; the vehicle control device executes corresponding operations according to the second data.
  • a secure communication method for vehicles is provided, which is applied to a vehicle control device.
  • the method includes: the vehicle receives encrypted first data sent by the vehicle control device; the vehicle uses the first key to decrypt the encrypted first data The first data, the first data is obtained; the vehicle performs corresponding operations according to the first data.
  • the operation performed by the vehicle can refer to the first aspect or any one of the first aspect The operations performed by the vehicle in the implementation manner will not be repeated here.
  • a vehicle control device including: memory, one or more processors; the memory is coupled to one or more processors, the memory is used to store computer program codes, and the computer program codes include computer instructions, one or more Multiple processors call computer instructions to make the vehicle control device execute the method according to the second aspect or any implementation manner of the second aspect.
  • a vehicle including: a memory, one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program codes, the computer program codes include computer instructions, and one or more The processor invokes computer instructions to make the vehicle execute the method according to the third aspect or any one implementation manner of the third aspect.
  • a communication system including a vehicle control device and a vehicle, the vehicle control device is used to execute the method according to any one of the second aspect or the second aspect, and the vehicle is used to execute the method according to the third aspect or the third aspect The method of any one embodiment.
  • a computer-readable storage medium including instructions, and when the instructions are run on the electronic device, the electronic device is made to execute the method according to the second aspect or any one of the implementation manners of the second aspect.
  • a computer program product is provided.
  • the computer program product is run on a computer, the computer is made to execute the method of the second aspect or any one implementation manner of the second aspect.
  • a computer-readable storage medium including instructions, and when the instructions are run on the electronic device, the electronic device is made to execute the method according to the second aspect or any one of the implementation manners of the second aspect.
  • a computer program product is provided.
  • the computer program product runs on a computer, the computer executes the method of the third aspect or any one implementation manner of the third aspect.
  • a chip system in an eleventh aspect, includes at least one processor, configured to implement the above-mentioned second aspect or any implementation manner of the second aspect, or the third aspect or any one of the third aspect method of implementation.
  • the vehicle control device and the vehicle use a key known only to both parties to encrypt the data that needs to be sent to the peer device, and send the encrypted data to the peer device, and the peer device receives the encrypted data. After accessing the data, use the key to decrypt the data.
  • the implementation of this technical solution is equivalent to establishing a point-to-point safe channel between the vehicle control device and the vehicle, which can ensure that only the vehicle control device and the vehicle can obtain the interactive data between the two parties, and prevent the interactive data of both parties from being obtained by a third party. Tampering or counterfeiting can ensure the information security of both the vehicle and the vehicle control equipment, and improve the safety of the vehicle.
  • FIG. 1 is an architecture diagram of a communication system provided by an embodiment of the present application
  • FIG. 2A is a block diagram of the hardware structure of the vehicle control device provided by the embodiment of the present application.
  • FIG. 2B and FIG. 2C are the software architecture of the vehicle control device provided by the embodiment of the present application.
  • FIG. 3A is a block diagram of the hardware structure of the vehicle provided by the embodiment of the present application.
  • Fig. 3B is the software architecture of the vehicle provided by the embodiment of the present application.
  • Fig. 4A-Fig. 4Z are a group of user interfaces realized on the vehicle provided by the embodiment of the present application.
  • Figure 4-1 is the user interface implemented on the vehicle provided by the embodiment of the present application.
  • Figures 5A-5N are a set of user interfaces implemented on a watch-type car control device provided by the embodiment of the present application.
  • Fig. 6A-Fig. 6J are a group of user interfaces implemented on the mobile phone type car control device provided by the embodiment of the present application;
  • Fig. 7 shows a flow chart of establishing a secure binding relationship between a vehicle control device and a vehicle through short-distance communication technology
  • Fig. 8 shows a flow chart of establishing a secure binding relationship between a vehicle control device and a vehicle through long-distance communication technology
  • Fig. 9 shows a flow chart of a vehicle control device sending data to a vehicle
  • first and second are used for descriptive purposes only, and cannot be understood as implying or implying relative importance or implicitly specifying the quantity of indicated technical features. Therefore, the features defined as “first” and “second” may explicitly or implicitly include one or more of these 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 following embodiments of this application is a medium interface for interaction and information exchange between an application program or an operating system and a user, and it realizes the difference between the internal form of information and the form acceptable to the user. conversion between.
  • the user interface is the source code written in a specific computer language such as java and extensible markup language (XML).
  • the source code of the interface is parsed and rendered on the electronic device, and finally presented as content that can be recognized by the user.
  • the commonly used form of user interface is the graphical user interface (graphic user interface, GUI), which refers to the user interface related to computer operation displayed in a graphical way. It may be text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, Widgets, and other visible interface elements displayed on the display screen of the electronic device.
  • the following embodiments of the present application provide a safety communication method, a related device and a communication system for vehicles.
  • the vehicle control device and the vehicle respectively store a key (key).
  • the vehicle control device and the vehicle use the key to encrypt the data that needs to be sent to the peer device, and then encrypt the encrypted
  • the data is sent to the peer device.
  • the peer device can use the pre-stored key to decrypt the data.
  • the communication is based on the key stored in the vehicle control device and the vehicle, which is equivalent to establishing a point-to-point secure channel between the vehicle control device and the vehicle, which can ensure the data exchanged between the two parties Only the vehicle control device and the vehicle can be obtained, preventing the interaction data between the two parties from being obtained, tampered with or forged by a third party.
  • the information security of both the vehicle and the vehicle control equipment can be guaranteed, thereby avoiding the leakage of the private data of the user in the vehicle, the control of the vehicle by a third party, the loss of the vehicle, and the control of multiple vehicles in batches by a third party, etc., and improving the safety of the vehicle.
  • the third party here refers to the vehicle control equipment, other equipment or institutions other than the vehicle.
  • the communication process between the vehicle control device and the vehicle can be performed through a public network and a server.
  • the server cannot obtain, tamper or forge the communication data between the vehicle control device and the vehicle, and even if there is a security loophole in the public network or server, it will not affect the security of the vehicle and the vehicle control device. Influence.
  • the vehicle control device and the vehicle may also communicate directly through the short-distance communication technology without relaying through the server.
  • the key used for communication between the vehicle control device and the vehicle is equivalent to being bound to the vehicle control device and the vehicle at the same time, so the key can also be called a binding key (bindkey).
  • the key is only used for communication between the bound vehicle control device and the vehicle.
  • the vehicle control device and the key stored in the vehicle can be obtained through negotiation between the two parties, or one party can notify the opposite device after determining it.
  • the above-mentioned process of negotiating or notifying the key can be performed between the vehicle control device and the vehicle through short-distance communication technology.
  • both the vehicle control device and the vehicle may first disconnect from the server, and then perform the above process of negotiating or notifying the key through short-distance communication technology.
  • the connection between the vehicle control device and the vehicle and the server is cut off, even if the server has a security hole, it can also ensure that the key communicated between the two parties will not be obtained by the server, thereby ensuring the security of the communication process based on the key.
  • the connection between the vehicle control device and the vehicle can also be The above-mentioned process of negotiating or notifying the key is performed by the server.
  • the vehicle control device and the vehicle may respectively store accounts used to log in to the server, and the vehicle control device and the vehicle may respectively store keys known only to both parties, which may be simultaneously associated with the account of the vehicle control device and the vehicle's Account binding.
  • the account number of the vehicle control device and the account number of the vehicle may be the same or different.
  • the vehicle control device and the vehicle can each store a key known only to both parties. During the communication process, one party uses the key to encrypt data and then sends it to the other party, and the other party also uses the key to decrypt it.
  • the vehicle control device and the vehicle may store a pair of keys together, one side stores a public key (public key), and the other side stores a private key (private key) corresponding to the public key.
  • one party encrypts the data with its own stored public key or private key and sends it to the other party, and the other party uses the stored private key or public key to decrypt it.
  • the vehicle control device and the vehicle can jointly store two pairs of keys, one of which stores the public key 1 and the private key 2, and the other stores the private key 1 and the public key 2.
  • one party encrypts the data with its own stored private key and sends it to the other party, and the other party decrypts it with the stored public key.
  • the vehicle control device or the vehicle can use different keys when encrypting and decrypting.
  • FIG. 1 is a schematic structural diagram of a communication system 10 provided by an embodiment of the present application.
  • the communication system 10 includes: a vehicle control device 100 , a vehicle 200 , a server 300 , and so on.
  • the vehicle control device 100 may include various types of devices, and the embodiment of the present application does not limit the specific type of the vehicle control device 100 .
  • the vehicle control device 100 may include a mobile phone, a vehicle fault diagnosis terminal, and may also include a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, a large-screen TV, a smart screen, a wearable device (such as Smart watches, smart bracelets), augmented reality (augmented reality, AR) devices, virtual reality (virtual reality, VR) devices, artificial intelligence (artificial intelligence, AI) devices, smart headphones, game consoles and other portable terminal devices, etc.
  • augmented reality augmented reality, AR
  • VR virtual reality
  • AI artificial intelligence
  • the embodiment of the present application does not limit the software operating system (operating system, OS) configured on the vehicle control device 100, for example, it may include but not limited to etc.
  • Vehicle 200 may include motor vehicles such as large automobiles, small automobiles, electric vehicles, motorcycles, and tractors.
  • the OS configured on the vehicle 200 may include but not limited to wait.
  • the vehicle 200 can establish a connection and communicate with other devices in the communication system 10 through a vehicle to everything (V2X) communication technology (cellular V2X, C-V2X) based on a cellular network.
  • V2X vehicle to everything
  • the vehicle 200 may be connected to a network device, and use the network device as an intermediate device to communicate with other devices such as the vehicle control device 100 and the server 300 .
  • C-V2X may include V2X (LTE-V2X) based on long term evolution (LTE-V2X), 5G-V2X wait.
  • LTE-V2X long term evolution
  • 5G-V2X 5G-V2X wait.
  • the vehicle 200 can also communicate with other devices in the communication system 10 based on other wireless communication technologies such as short-range/near-range communication (short range communication) technologies.
  • the vehicle 200 can communicate via wireless-fidelity (wireless-fidelity, Wi-Fi), Bluetooth (Bluetooth, BT), near field communication (near field communication, NFC), infrared (infrared, IR), ultra-wideband (ultra-wideband , UWB) and other technologies communicate with the vehicle control device 100 and the like.
  • the bluetooth can be classic bluetooth or bluetooth low energy (bluetooth low energy, BLE).
  • Vehicle management applications can be installed in both the vehicle control device 100 and the vehicle 200 .
  • the forms and capabilities of the vehicle-related applications installed in the vehicle control device 100 and the vehicle 200 may be different.
  • the vehicle management application in the vehicle control device 100 provides various services for the vehicle control device 100, such as vehicle information query, remote control of the vehicle, remote fault diagnosis of the vehicle, and the like.
  • the vehicle management application in the vehicle 200 provides various services for the vehicle 200, such as navigation, entertainment and so on.
  • the vehicle control device 100 or the vehicle 200 can log in to the server 300 through a vehicle management application and a user account to use various services provided by the server 300 .
  • the user account may be, for example, a name, a Huawei identity (identity, ID), a mobile phone number, and other identifiers.
  • the vehicle control device 100 or the vehicle 200 can use part or all of the services provided by the vehicle management application in the form of a guest.
  • the server 300 may be provided by a vehicle manufacturer or a third party.
  • the server 300 is used to manage vehicles and provide various services for vehicle management applications, such as navigation, entertainment, vehicle information query, remote control of vehicles, remote fault diagnosis of vehicles, and the like.
  • the server 300 may be a cloud server or a local server.
  • the server 300 may also be called a car cloud server.
  • the number of servers 300 may be one or more.
  • the vehicle control device 100 and the vehicle 200 can be used to access the server 300 .
  • Communication between the server 300 and each vehicle control device 100 and vehicle 200 may be through cellular mobile communication technologies such as 3G, LTE, and 5G, or wide area network (WAN) technology, or local area network (LAN) technology.
  • cellular mobile communication technologies such as 3G, LTE, and 5G, or wide area network (WAN) technology, or local area network (LAN) technology.
  • the vehicle control device 100 and the vehicle 200 may establish a security binding relationship based on a key.
  • the vehicle control device 100 and the vehicle 200 establish a security binding relationship based on a key, which means that the vehicle control device 100 and the vehicle 200 are first bound, and then both parties negotiate a key or one party notifies the other after determining the key, and the vehicle control device 100
  • the identity of the peer device and the key are stored in association with the vehicle 200 .
  • the vehicle control device 100 and the vehicle 200 can communicate based on the key.
  • the vehicle control device 100 and the vehicle 200 use the key to encrypt data to be sent to the peer device, and then send the encrypted data to the peer device.
  • the peer device can use the pre-stored key to decrypt the data.
  • a vehicle control device can establish a key-based binding relationship with one or more vehicles, and a vehicle can also establish a key-based security binding relationship with one or more vehicle control devices.
  • Table 1 exemplarily shows the key-based security binding relationship stored in the vehicle control device 100 .
  • Table 2 exemplarily shows the key-based security binding relationship stored in the vehicle 200 .
  • key-based secure binding relationships are established between the vehicle 200 and the vehicle control device 100 , the vehicle control device 600 and the vehicle control device 700 .
  • the vehicle 200 and the vehicle control device 100 communicate based on key 1
  • the vehicle 200 and the vehicle control device 600 communicate based on key 4
  • the vehicle 200 and the vehicle control device 700 communicate based on key 5.
  • the vehicle control device 100 and the vehicle 200 may establish a secure binding relationship based on an account and a key.
  • the vehicle control device 100 and the vehicle 200 establish a secure binding relationship based on accounts and keys, which means that after the vehicle control device 100 and the vehicle 200 log in to the server 300 using accounts, the two devices are first bound to each other, and then the two parties negotiate a key Alternatively, one party notifies the other party after determining the key, and the vehicle control device 100 and the vehicle 200 store the identification of the peer device, the accounts used by both parties to log in to the server 300 and the key.
  • the two parties can communicate based on the key. Specifically, during the communication process between the two, the vehicle control device 100 and the vehicle 200 use the key to encrypt data to be sent to the peer device, and then send the encrypted data to the peer device. After receiving the encrypted data, the peer device can use the pre-stored key to decrypt the data.
  • the two can establish a binding relationship based on the account and the key.
  • a car control device can establish a secure binding relationship based on accounts and keys with one or more vehicles, and a vehicle can also establish a secure binding relationship based on accounts and keys with one or more car control devices.
  • Table 3 exemplarily shows the security binding relationship based on accounts and keys stored in the vehicle control device 100 .
  • the application package may include application programs such as vehicle management application, camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and short message.
  • vehicle management application is used to provide various services for the vehicle control device 100, such as vehicle information query, remote control of the vehicle, remote fault diagnosis of the vehicle, and the like.
  • the vehicle 200 includes: a controller area network (controller area network, CAN) bus 11, a plurality of electronic control units (electronic control unit, ECU), engine 13, vehicle-mounted box (telematics box, T-box) 14. Transmission 15, driving recorder 16, antilock brake system (ABS) 17, sensor system 18, camera system 19, microphone 20, and so on.
  • a controller area network controller area network, CAN
  • ECU electronic control unit
  • T-box vehicle-mounted box
  • Transmission driving recorder
  • ABS antilock brake system
  • sensor system camera system 19 microphone 20, and so on.
  • the CAN bus 11 is a serial communication network supporting distributed control or real-time control for connecting various components of the vehicle 200 . Any component on the CAN bus 11 can monitor all 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 safety communication method for the vehicle of each component.
  • the CAN bus 11 can be used to transmit the data involved in the safety communication method for the vehicle of each component.
  • the method embodiment please refer to the detailed description of the method embodiment below.
  • the ECU is equivalent to the processor or the brain of the vehicle 200 , and is used to instruct the corresponding components to perform corresponding actions according to the instructions obtained from the CAN bus 11 or according to the operations input by the user.
  • 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 input, output, shaping, driving and other large-scale integrated circuits.
  • ECUs There are many kinds of ECUs, and different kinds of ECUs can be used to realize different functions.
  • the data read by T-box 14 through CAN bus 11 can be transmitted to the TSP background system through the network, and the TSP The background system forwards it to the vehicle control device 100 on the user side for viewing by the user.
  • T-box 14 may specifically include a communication module and a display screen.
  • the communication module can be used to provide wireless communication function, support the vehicle 200 through wireless local area networks (wireless local area networks, WLAN) (such as wireless fidelity (wireless fidelity, Wi-Fi) network), bluetooth (bluetooth, BT), global navigation Satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field communication technology (near field communication, NFC), infrared technology (infrared, IR), ultra-wideband (ultra-wideband, UWB), etc.
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN wireless local area networks
  • WLAN such as wireless fidelity (wireless fidelity, Wi-Fi) network
  • bluetooth blue, BT
  • global navigation Satellite system global navigation satellite system, GNSS
  • frequency modulation frequency modulation, FM
  • near field communication technology near field communication
  • NFC
  • the communication module is also used to perform key-based communication with the vehicle control device 100 .
  • the communication module can be used to send data encrypted using a key to the vehicle control device 100 , and can also receive data encrypted using a key sent by the vehicle control device 100 .
  • the communication process between the communication module and the vehicle control device 100 reference may be made to the detailed description of subsequent method embodiments.
  • the T-box 14 may also be called a vehicle-machine system, a telematics processor, a vehicle gateway, etc., which is not limited in this embodiment of the present application.
  • Speed changer 15 can be used to change the mechanism of the rotating speed and torque of engine, and it can change output shaft and input shaft gear ratio fixedly or in steps.
  • the components of the transmission 15 may include a speed change transmission mechanism, an operating mechanism, a power output mechanism, and the like.
  • the main function of the speed change transmission mechanism is to change the value and direction of torque and speed; the main function of the control mechanism is to control the transmission mechanism to realize the transformation of the transmission ratio of the transmission, that is, to realize shifting, so as to achieve variable speed and torque.
  • the driving recorder ECU 124 is used to manage the driving recorder 16 .
  • ABS17 is to automatically control the braking force of the brake when the vehicle is braking, so that the wheel is not locked and is in a state of rolling and sliding, so as to ensure the maximum adhesion between the wheel and the ground.
  • the ABS enters the anti-lock brake pressure adjustment process.
  • the sensor system 18 may include: an acceleration sensor, a vehicle speed sensor, a shock sensor, a gyroscope sensor, a radar sensor, a signal transmitter, a signal receiver, and the like.
  • the acceleration sensor and the vehicle speed sensor are used to detect the speed of the vehicle 200 .
  • the shock sensor can be installed under the seat, on the seat belt, on the seat back, on the operation panel, on the airbag or in other positions, and is used to detect whether the vehicle 200 has been bumped and where the user is.
  • Gyroscopic sensors may be used to determine the motion attitude of the vehicle 200 .
  • Radar sensors may include lidar, ultrasonic radar, millimeter wave radar, and the like. Radar sensors, signal transmitters and signal receivers can be used to detect the user's location.
  • Camera system 19 may include multiple cameras for capturing still images or video.
  • the camera in the camera system 19 can be arranged at positions such as the front of the car, the rear of the car, the side, and in the car, so as to facilitate the realization of functions such as assisted driving, driving record, panoramic view, and in-car monitoring.
  • the sensor system 18 and the camera system 19 can be used to detect the surrounding environment, so that the vehicle 200 can make corresponding decisions to deal with environmental changes, for example, it can be used to complete the task of paying attention to the surrounding environment during the automatic driving stage.
  • the vehicle 200 may also include multiple interfaces, such as a USB interface, an RS-232 interface, an RS485 interface, etc., which can be connected to an external camera, microphone, earphone, and the vehicle control device 100 on the user side.
  • multiple interfaces such as a USB interface, an RS-232 interface, an RS485 interface, etc., which can be connected to an external camera, microphone, earphone, and the vehicle control device 100 on the user side.
  • Vehicle 200 may include more or fewer components than shown, or some components may be combined or separated, or a different arrangement of components may be made.
  • the illustrated components can be realized in hardware, software or a combination of software and hardware.
  • the vehicle 200 may also include a separate memory, battery, lights, wipers, instrument panel, audio, transmission control unit (TCU), auxiliary control unit (auxiliary control unit, ACU), smart entry and start system ( passive entry passive start, PEPS), on board unit (OBU), body control module (body control module, BCM), charging interface, etc.
  • the memory is used to associate and store the key-based binding relationship between the vehicle 200 and other vehicle control devices, for example, the respective keys of the vehicle control device 100 and the vehicle 200 can be stored in association. identity, and the bound key.
  • the memory is used to associate and store the binding relationship between the vehicle 200 and other vehicle control devices based on accounts and keys. account, and the bound key.
  • FIG. 3B shows the software structure of the vehicle 200 provided by the embodiment of the present application.
  • the vehicle 200 may include: a binding function module, a near-end interaction module, an external network interaction module, a cryptographic algorithm module, and a vehicle control data processing module. in:
  • the binding function module is used to provide a series of user interfaces involved in the vehicle 200 when the vehicle 200 establishes a binding relationship with the vehicle control device 100 .
  • For the user interface reference may be made to the detailed description of the subsequent embodiments.
  • the near-end interaction module is configured to perform short-distance communication with the vehicle control device 100 .
  • the near-end interaction module can support the vehicle 200 to communicate with other devices through Bluetooth, Wi-Fi, NFC and other technologies.
  • the external network interaction module is used for performing remote communication with the vehicle control device 100 and also for communicating with the server 300 .
  • the near-end interaction module can support the vehicle 200 to communicate with other devices through cellular network, WAN, LAN and other technologies.
  • the cryptographic algorithm module is used to calculate a series of mathematical factors involved in the key negotiation process between the vehicle 200 and the vehicle control device 100 .
  • the vehicle control data processing module is used for encrypting the data to be sent by the vehicle 200 to the vehicle control device 100 using the key, and for decrypting the encrypted data sent by the vehicle control device 100 using the key.
  • the software structure of the vehicle 200 shown in FIG. 3B is only an example, and does not constitute a specific limitation to the vehicle 200 .
  • the vehicle 200 may include more or less units than shown in the figure, or combine some units, or separate some units, or arrange different units.
  • the software architecture of the vehicle 200 may also include a vehicle management application, which supports the vehicle 200 to log in to the server 300 to obtain various services provided by the server 300 and so on.
  • FIG. 4A exemplarily shows a user interface 41 displayed after the vehicle 200 logs in to the server 300 .
  • User interface 41 may be provided by a vehicle management application in vehicle 200 .
  • the user interface 41 may be displayed after the vehicle 200 receives a user operation acting on the vehicle management application icon in the main interface, or receives a user operation acting on the user avatar in the main interface, or receives other user operations. .
  • top status bar 401 displayed in the user interface 41 are: top status bar 401, login avatar 402, login account 403, used to switch accounts Control 404 for logging out, control 405 for logging out, control 406 for starting face recognition, control 407 for setting the vehicle control device safely bound to the vehicle 200, user local data management information 408, and the bottom task bar 409.
  • the top status bar 401 may include: one or more of the avatar corresponding to the account used by the vehicle 200 to log in to the server 300 currently, a message notifier, a weather indicator, a time indicator, a battery status indicator, a Bluetooth indicator, and a Wi-Fi signal.
  • signal strength indicators one or more signal strength indicators for mobile communication signals (also referred to as cellular signals), and the like.
  • the login avatar 402 is the avatar corresponding to the account currently used by the vehicle 200 to log in to the server 300 .
  • the login avatar 402 in FIG. 4A also displays prompt information, indicating that the current login account is the vehicle owner account.
  • the user local data management information 408 is used to display the local user data of the vehicle 200, such as historically logged-in account information, etc., and can also be used to provide an entry for the user to delete part or all of the local user data.
  • the bottom task bar 409 may include: controls for entering the main interface, multi-tasking keys, seat adjustment controls, air conditioner temperature adjustment controls, volume adjustment controls, and the like.
  • the control 407 is used to monitor user operations (such as touch operations, click operations, etc.), and the vehicle 200 may respond to the user operations to display the user interface 42 for displaying information of the vehicle control device currently safely bound to the vehicle 200 .
  • user operations such as touch operations, click operations, etc.
  • the vehicle 200 may respond to the user operations to display the user interface 42 for displaying information of the vehicle control device currently safely bound to the vehicle 200 .
  • the vehicle 200 displays the user interface 41 shown in FIG. 4A , it may also display the number of vehicle control devices currently bound to the vehicle 200 under the control 407 .
  • 4B-4D show several implementations of the user interface 42 displaying the information of the vehicle control device that the vehicle 200 is currently securely bound to.
  • the vehicle 200 may display FIG. 4B in response to the user operation on the control 407 in FIG. 4A .
  • the upper limit value of the vehicle control device that can be safely bound to the vehicle 200 can be preset, for example, it can be set in the vehicle 200 by default before the vehicle leaves the factory.
  • 4B shows a window 410, which is used to display a list of vehicle control devices that have been safely bound to the vehicle 200, specifically including: prompt information 410a, prompt information 410b, multiple currently securely bound vehicle control device information 410c, and corresponding Unbind control 410d.
  • the user can input a sliding operation from bottom to top in the window 410 to view more vehicle control device information.
  • the prompt information 410a is used to remind the user of the operations that can be performed by the vehicle control device that is securely bound to the vehicle 200 , for example, functions such as remote control of car locks, car windows, and trunk can be performed.
  • the prompt information 410b is used to remind the user that the number of vehicle control devices safely bound to the current vehicle 200 has reached the upper limit.
  • the vehicle control device information 410c may be the identification of the vehicle control device safely bound to the vehicle 200, such as "Xiaobin's Mate40Pro", “LiBin's Mate40Pro", “LiBin's P50" and so on in the figure.
  • the unbinding control 410d can be used to trigger the unbinding of the corresponding vehicle control device and the vehicle 200 . Unbinding refers to releasing the security binding relationship between the corresponding vehicle control device and the vehicle 200 .
  • the vehicle 200 may display FIG. 4C in response to the user operation on the control 407 in FIG. 4A .
  • FIG. 4C and FIG. 4B The difference between FIG. 4C and FIG. 4B is that, since the number of vehicle control devices safely bound to the current vehicle 200 has not reached the upper limit, the vehicle 200 can display a control 410e and a control 410f for safely binding more vehicle control devices.
  • the control 410e and the control 410f can be used to trigger the vehicle 200 to safely bind different types of vehicle control devices in different ways, for example, the control 410e can be used to trigger the vehicle 200 to safely bind the mobile phone, and the control 410f can be used to trigger the vehicle to safely bind the watch.
  • the vehicle 200 can also use the same method to securely bind various vehicle control devices, so that the vehicle 200 only needs to display a control for securely binding the vehicle control device, or the vehicle can also display more Many controls are used to securely bind different types of vehicle control devices in different ways.
  • the vehicle 200 may display FIG. 4D .
  • FIG. 4D The difference between FIG. 4D and FIG. 4B and FIG. 4C is that the vehicle 200 does not display the information of the vehicle control device safely bound to the vehicle because the current vehicle 200 has not been safely bound to the vehicle control device.
  • the vehicle 200 can detect a user operation (such as touch operation, click operation, etc.) acting on the control 410e or control 410f in FIG. 4C or FIG. fixed car control If the preparation of the equipment has not started Bluetooth, the user interface 43 shown in Figure 4E will be displayed to prompt the user; The displayed user interface 44 is used to load the information required for securely binding the vehicle control device.
  • the vehicle 200 after the vehicle 200 detects the user operation acting on the control 410e or control 410f in FIG. 4C or 4D, it can first perform the operation of verifying the user's identity information, and then display the User Interface.
  • Methods of verifying user identity may include, for example, face authentication, code scanning authentication, digital password authentication, fingerprint authentication, etc.
  • the purpose of authentication is to confirm that the current user is consistent with the user corresponding to the current login account.
  • FIG. 4E exemplarily shows a manner in which the vehicle 200 prompts the user to make preparations before securely binding the vehicle control device.
  • a window 411 is displayed in the user interface 43 shown in FIG. 4E, and the window 411 includes: a control 411a for starting Bluetooth, prompt information 411b, and prompt information 411c.
  • the control 411a is used to monitor user operations, and the vehicle 200 can activate Bluetooth in response to the user operations.
  • the prompt information 411b can be used to prompt the user to turn on the Bluetooth of the vehicle 200 before proceeding with the subsequent operation of securely binding the vehicle control device.
  • the prompt information 411c is used to remind the user what preparations the vehicle control device should make when the vehicle 200 is securely bound to the vehicle control device, for example, the vehicle control device should turn on Bluetooth and log in with the same account as the current vehicle 200 .
  • the vehicle 200 After the vehicle 200 detects the operation on the control 411a in FIG. 4E , it can start Bluetooth and display the user interface 44 as shown in FIG. 4F .
  • a window 412 is displayed in the user interface 44, and the window 412 includes: a title 412a, a prompt message 412b, a loading prompt 412c, and a control 412d.
  • the title 412a indicates that the current window 412 is used to display the content required for key negotiation between the vehicle 200 and the vehicle control device, for example, the text "Security Key”.
  • the prompt information 412b is used to remind the user how to operate on the vehicle control device to complete the security binding. If different types of vehicle control devices correspond to different operations, the prompt information 412b may also have different implementation forms.
  • the prompt information 412b in FIG. 4F is used to prompt the user to open the vehicle management application (such as the AITO application in the figure) on the vehicle control device to scan the code, and keep the Bluetooth of the vehicle control device turned on.
  • the loading prompt 412c is used to indicate that the vehicle 200 is currently loading the information required for the safe binding between the vehicle 200 and the vehicle control device, and the information can be implemented as a two-dimensional code, a bar code, a digital password, or other forms, for example.
  • the control 412d can be used to monitor the user's operation, and the vehicle 200 can stop displaying the window 412 in response to the user's operation, and interrupt the operation of safely binding the vehicle control device.
  • the vehicle 200 may not display the user interface shown in FIG. 4F , but may directly display the loaded content in the window 412, As shown in the subsequent user interface of FIG. 4G or FIG. 4H .
  • the vehicle 200 After the vehicle 200 has loaded the information required for safe binding with the vehicle control device, it can display the user interface 44 shown in FIG. 4G , or the user interface 44 shown in FIG. 4I .
  • FIG. 4G exemplarily shows the information required for the secure binding of the vehicle 200 and the mobile phone type vehicle control device.
  • the user interface shown in FIG. 4G may be the interface displayed after the vehicle detects that the control 410e in FIG. 4C or FIG. 4D is applied. Since mobile phone-type car control devices are usually equipped with a camera, the vehicle 200 can display the QR code 413 in FIG. Further, a key is negotiated with the vehicle 200 .
  • FIG. 4I exemplarily shows the information required for secure binding of the vehicle 200 and the watch-type vehicle control device.
  • the user interface shown in FIG. 4I may be the interface displayed after the vehicle detects that the control 410f in FIG. 4C or FIG. 4D is applied.
  • the vehicle 200 can display the digital password 414 in FIG. 4I , so that the watch-type car control device can obtain the information required for the above-mentioned secure binding by inputting the digital password, and then negotiate a key with the vehicle 200 .
  • the two-dimensional code 413 shown in FIG. 4G or the digital password 414 shown in FIG. 4I can have a certain timeliness, and become invalid after the display exceeds a preset duration.
  • the vehicle 200 can actively refresh the two-dimensional code or digital password and display the refreshed information on the display screen, or the vehicle 200 can also prompt the user that the current two-dimensional code or digital password is invalid and prompt the user to refresh the two-dimensional code or digital password.
  • Password such as shown in Figure 4H or Figure 4J.
  • vehicle 200 shown in FIG. 4G and FIG. 4I displaying different types of information (such as two-dimensional codes and digital passwords) to securely bind different types of vehicle control devices.
  • information such as two-dimensional codes and digital passwords
  • the same type of information can be displayed, for example, digital passwords can be displayed, or the type of information displayed by the vehicle 200 can also be switched with the user's operation.
  • the information required for safe binding with the vehicle control device shown in Figure 4G or Figure 4I is displayed on the vehicle 200, and the vehicle control device performs corresponding operations according to the corresponding instructions, for example, the vehicle control device scans a QR code or receives an input number After the password, some information can be exchanged between the vehicle 200 and the vehicle control device, for example, the device identification and the account currently used to log in to the server 300 can be sent to the peer device.
  • the vehicle 200 After the vehicle 200 receives the account number of the vehicle control device, it can compare it with the account it currently uses to log in to the server 300. If the two are different, it can input prompt information to remind the user that the vehicle 200 can only be safely bound with its login account. Vehicle control devices with the same account. If the two are the same, it is only necessary to execute the subsequent security binding process, and a prompt message 415 shown in FIG. 4K may be displayed to remind the user that the current vehicle 200 is performing security binding operation of the corresponding vehicle control device.
  • a prompt message 415 shown in FIG. 4K may be displayed to remind the user that the current vehicle 200 is performing security binding operation of the corresponding vehicle control device.
  • FIG. 4M and 4N are user interfaces displayed by the vehicle 200 after the security binding between the vehicle 200 and the vehicle control device expires.
  • Fig. 4M is the user interface displayed after the vehicle 200 executes the operation of safely binding the vehicle control device in the background and the security binding times out.
  • the user interface can be the main interface of the vehicle 200. Timeout prompt message.
  • FIG. 4N is a user interface displayed after the vehicle 200 executes the operation of securely binding the vehicle control device in the foreground after the security binding times out. 200 and the control 417 that is safely bound again to the vehicle control device. After the vehicle 200 detects the user operation acting on the control 417 , it can perform subsequent security binding operations with the corresponding vehicle control device based on the information exchanged.
  • FIG. 4S is a user interface 42 displayed after the vehicle 200 executes securely binding a watch-type car control device operation in the foreground and successfully binds.
  • the newly added vehicle control device information 410c corresponding to the vehicle control device and the corresponding unbinding control 410d will be displayed in the window 410 .
  • the text on the newly added vehicle control device information 410c in FIG. 4S indicates that the identifier of the vehicle control device newly bound to the vehicle 200 is "LiBin's Watch 7".
  • the vehicle control device information 410c there may also be displayed prompt information indicating that the vehicle control device is a new security binding device, such as the text "new".
  • the newly added vehicle control device information 410c and the corresponding unbinding control 410d can be arranged in front of the corresponding controls that have been safely bound to the vehicle control device.
  • the vehicle 200 can detect the user operation on the unbinding control 410d corresponding to the vehicle control device identified as "Xiaobin's Mate40 Pro" in the window 410 shown in FIG. 4B, FIG. 4C, FIG. 4R or FIG. 4S, and then display the Window 419 shown at 4T.
  • Window 419 includes prompt information 419a, control 419b, and control 419c.
  • the prompt information 419a is used to prompt the user that the corresponding vehicle control device will not be able to remotely control the vehicle 200 after unbinding.
  • the control 419b is used to monitor user operations, and the vehicle 200 will no longer execute the unbinding process in response to the user operations.
  • the control 419c is used to monitor user operations, and the vehicle 200 will execute the unbinding process in response to the user operations.
  • Fig. 4U shows that the vehicle 200 triggers the face verification flow
  • Fig. 4V shows the user interface when the vehicle 200 triggers the code scanning verification process. If the current time is within a preset period of time (for example, 5 minutes) from the last verified user identity, the user interface shown in FIG. unbind operation of the control device.
  • the vehicle 200 can only perform the operation of unbinding with the vehicle control device while the user interface shown in FIG. 4W is kept displayed. If the vehicle 200 exits and displays the user interface shown in FIG. 4W, it will be interrupted. The process of unbinding the car control device.
  • FIG. 4X shows a pop-up window displayed after the vehicle 200 receives a user operation to exit the user interface shown in FIG. 4W.
  • the vehicle 200 may display the Pop-ups.
  • the pop-up window is used to remind the user that the unbinding process of the vehicle 200 and the vehicle control device can only be performed while displaying the user interface shown in FIG. 4W . If the user interface is exited, the unbinding process will be interrupted.
  • the vehicle 200 may not keep displaying the user interface shown in FIG. 4W , but the vehicle 200 may display other user interfaces or run other applications, as long as the operation of unbinding with the vehicle device is performed in the background.
  • FIG. 4-1 exemplarily show the unbinding results displayed by the vehicle 200 after the vehicle 200 and the vehicle control device perform the unbinding operation.
  • Fig. 4Y is the user interface displayed after the vehicle 200 performs the operation of unbinding the vehicle control device in the foreground, and after the unbinding timeout, the user interface displays a prompt message for prompting the user to untie the timeout, and is used to trigger the vehicle 200 and the vehicle Control device re-unbind controls.
  • Unbinding timeout may mean that the vehicle 200 and the corresponding vehicle control device fail to complete the unbinding process within a preset period of time.
  • the preset duration may be, for example, 2 seconds, 5 seconds, 10 seconds, and so on.
  • Fig. 4Z is the user interface displayed after the vehicle 200 performs the operation of unbinding the vehicle control device at the foreground and the unbinding fails. Control device re-unbind controls.
  • Unbinding failure may refer to that the vehicle 200 and the corresponding vehicle control device fail to execute the unbinding process successfully.
  • Reasons for unbinding failure may include, but are not limited to: abnormality of the connection path between the vehicle 200 and the vehicle control device, abnormality of the vehicle control device (such as low power shutdown, refusal of safe binding, etc.), vehicle abnormality, etc.
  • FIG. 4-1 shows the user interface displayed by the vehicle 200 after the vehicle 200 performs an operation of unbinding with the vehicle control device in the foreground, and after the vehicle 200 is successfully unbound with the vehicle control device.
  • the car control device identified as "Xiaobin's Mate40 Pro" is unbound from the vehicle 200, and other Device IDs are no longer displayed in the user interface.
  • FIGS. 5A-5N are a set of user interfaces implemented on the watch-type car control device 100 provided by the embodiment of the present application.
  • FIGS. 5A-5N show a way for the vehicle control device 100 and the vehicle 200 to be securely bound through short-distance communication technology.
  • FIG. 5A exemplarily shows a user interface 51 displayed after the vehicle control device 100 logs in to the server 300 .
  • the user interface 51 may be provided by a vehicle management application in the vehicle control device 100, and is used to display vehicle information of a certain vehicle. As shown in FIG. 5A , the user interface 51 displays the information of the vehicle bound to the vehicle control device 100 , such as driving mileage, battery power, fuel quantity, current status and so on.
  • the vehicle control device 100 is only bound to the vehicle, but not securely bound to the vehicle. Therefore, the vehicle control device 100 can only view the information of the vehicle, but cannot control the vehicle.
  • the vehicle control device 100 may detect a user operation (such as an upward sliding operation, a downward sliding operation, etc.) acting on the user interface 51 for displaying the vehicle control interface.
  • a user operation such as an upward sliding operation, a downward sliding operation, etc.
  • the vehicle control device 100 may first prompt the user to perform a security binding process with the corresponding vehicle.
  • FIG. 5B shows the user interface 52 displayed after the vehicle control device 100 detects a user operation acting on the user interface 51 .
  • the user interface 52 shows a manner in which the vehicle control device 100 prompts the user to make preparations before safely binding the corresponding vehicle.
  • Windows are displayed in the user interface 52: prompt information 501a, control 501b and control 501c.
  • the prompt information 501a is used to remind the user what kind of preparations each device should make when the car control device 100 is safely bound to the vehicle.
  • the management device such as a mobile phone
  • the management device sets the vehicle as a default vehicle. After the default vehicle is set, the vehicle control operations received by the vehicle control device 100 are all executed for the default vehicle.
  • the control 501b is used to monitor user operations. If the current vehicle control device 100 is ready for security binding (for example, Bluetooth is turned on), the vehicle control device 100 can respond to the user operation on the control 501b and receive other nearby devices. (For example, a vehicle) sends a Bluetooth broadcast to search for nearby Bluetooth devices that can be bound.
  • the vehicle control device 100 finds a vehicle corresponding to the information displayed on the user interface 51 , it can directly execute a secure binding process with the vehicle.
  • the car control device 100 If the car control device 100 only finds a bindable Bluetooth device, it can directly execute the secure binding process with the device, and display the connection prompt 504 in FIG. 5D, which can be used to prompt the user to The control device 100 is establishing a Bluetooth connection with the searched Bluetooth device.
  • the vehicle control device 100 After the vehicle control device 100 starts to execute the security binding process with a certain vehicle, the following items can be confirmed first: the vehicle control device 100 and the vehicle have successfully established a Bluetooth connection, the vehicle control device 100 has discovered the vehicle, and the vehicle has not interrupted security. In the binding process, the vehicle control device 100 and the vehicle log in with the same account, and the management device (such as a mobile phone) of the vehicle control device 100 sets the vehicle as a default vehicle. If the current situation does not meet the above items, the vehicle control device 100 may interrupt the security binding process, and may display one of the user interfaces shown in FIG. 5F according to the actual situation, to remind the user of the reason for currently interrupting the security binding process. If the current situation meets the above items, the vehicle control device 100 may execute a subsequent security binding process, for example, may display the user interface shown in FIG. 5G .
  • FIG. 5G shows an interface provided by the vehicle control device 100 for obtaining information required for safe binding with the vehicle.
  • the user interface shown in FIG. 5G may display prompt information and number keys, and the prompt information is used to prompt the user to input a digital password.
  • the vehicle control device 100 may receive the digital password input by the user. If the digital password entered by the user is inconsistent with the digital password displayed on the vehicle side or has expired, the vehicle control device 100 will not be able to obtain the information carried by the digital password, and will not be able to continue the subsequent security binding process. In this case, the vehicle control device 100 may display the user interface shown in FIG. 5I to prompt the user to re-enter the digital password.
  • 5K to 5N exemplarily show the security binding results displayed by the vehicle control device 100 after the vehicle control device 100 and the vehicle perform a security binding operation.
  • FIG. 5L is a user interface displayed by the vehicle control device 100 after the security binding between the vehicle control device 100 and the vehicle fails due to excessive binding attempts.
  • the user interface shown in FIG. 5N may also be referred to as a first user interface.
  • the unbinding process can also be triggered on the car control device 100 of the watch category.
  • the car control device 100 can set a control for unbinding in the user interface shown in FIG. 5A for the user to click and trigger the unbinding process.
  • 6A-6J are a set of user interfaces implemented on the mobile phone type car control device 100 provided by the embodiment of the present application. 6A-6J show a way for the vehicle control device 100 and the vehicle 200 to be securely bound through the remote communication technology.
  • FIG. 6A exemplarily shows a user interface 61 displayed after the vehicle control device 100 logs in to the server 300 .
  • the user interface 61 may be provided by a vehicle management application in the vehicle control device 100 , and is used to display a list of vehicles safely bound to the vehicle control device 100 . As shown in FIG. 6A , the user interface 61 displays: vehicle information of the vehicle securely bound by the vehicle control device 100 , such as vehicle icon, model, license plate number, VIN and so on. Also displayed in the user interface 61 is a control 601 for securely binding the new vehicle. The control 601 can be used to monitor user operations (such as touch operations, click operations, etc.), and the vehicle control device 100 can execute a mobile phone number authentication process in response to the user operations.
  • the vehicle control device 100 may first verify the user's mobile phone number, and check whether there is a registered car purchase record under the mobile phone number.
  • the server 300 can store the purchase records of each vehicle, including the information of each vehicle (such as vehicle identification, vehicle picture, model, vehicle frame number, license plate number, etc.) and the corresponding purchase mobile phone number.
  • 6B-6E show a series of user interfaces for the car control device 100 to verify whether the mobile phone number has a car purchase record.
  • the vehicle control device 100 can display multiple mobile phone number options 602 , a control 603 for adding a mobile phone number, and a control 604 .
  • the mobile phone number option 602 may correspond to the mobile phone numbers added by the vehicle control device 100 in history.
  • the vehicle control device 100 can send a portable message to the server 300.
  • the mobile phone number option 602 corresponds to the verification request of the mobile phone number.
  • the vehicle control device 100 may display the user interface shown in FIG. 6C for the user to input a new mobile phone number. Afterwards, the vehicle control device 100 can monitor the user operation of clicking the next step control by the user, and send a verification request carrying the new mobile phone number added by the user to the server 300 .
  • the server 300 may send a verification code to the device (for example, the vehicle control device 100 ) where the mobile phone number is located. This step is to verify that the device where the mobile phone number is located is currently located near the user, and the device is safe and credible.
  • a user interface as shown in FIG. 6D is displayed.
  • the vehicle control device 100 may receive the verification code input by the user, and send a message carrying the verification code to the server 300 .
  • the server 300 After receiving the verification code sent by the vehicle control device 100, the server 300 compares it with the verification code previously sent to the vehicle control device 100. If they are consistent, it confirms that the device with the mobile phone number is currently located near the user, and the device is safe. and believable. Afterwards, the server 300 can query whether there is a car purchase record under the mobile phone number, and send the query result to the vehicle control device 100 .
  • the vehicle control device 100 may display the user interface shown in FIG. 6F to remind the user that there is no car purchase record under the current mobile phone number.
  • the server 300 inquires that there is a car purchase record under the mobile phone number, it can send the vehicle information purchased under the mobile phone number to the vehicle control device 100 .
  • the vehicle control device 100 After the vehicle control device 100 receives the vehicle information, it can display the options of each vehicle purchased under the mobile phone number. As shown in Figure 6G, the car control device 100 displays vehicle options 605 and 606, as well as controls 607 and 608.
  • the vehicle option 605 indicates that a car with the model "Car X1 Huawei Smart Selection" purchased under the mobile phone number, followed by the VIN For a vehicle whose six digits are "018233", the vehicle option 606 indicates that the mobile phone number has purchased a vehicle with the model "Car X1 Free Launch Edition" and the last six digits of the VIN are "028233".
  • the vehicle control device 100 may detect the user operation on the control 608 after detecting the user operation on one or more vehicle options, and then execute the security binding process on the vehicle corresponding to the vehicle option.
  • the vehicle control device 100 and the corresponding vehicle execute the security binding process
  • the user interface shown in FIG. 6H may also be displayed to prompt the user that the vehicle is currently being securely bound.
  • FIG. 6I exemplarily shows the user interface displayed after the vehicle control device 100 is successfully and securely bound to the vehicle. As shown in FIG. 6I , after the vehicle control device 100 securely binds the vehicle, the vehicle information of the newly securely bound vehicle can be displayed in the vehicle list of the user interface 61 .
  • the vehicle control device 100 can use the negotiated key to communicate with the vehicle to realize functions such as remote control of the vehicle, remote query of vehicle status, and remote diagnosis of vehicle faults.
  • the secure binding here means that after the vehicle control device 100 successfully binds the vehicle safely, in response to the detected user operation on the vehicle information shown in FIG. 6I , the information for remote control of the vehicle shown in FIG. 6J can be displayed.
  • the user interface of the vehicle As shown in FIG. 6J , multiple control options 609-612 are displayed in the user interface, which are respectively used to control the car lock, control the car window, find the car, and control the air conditioner.
  • the vehicle control device 100 can monitor user operations on any of the control options 609-612, and execute corresponding steps in response to the user operations, such as sending instructions to the vehicle to control the car locks, sending instructions to control the windows, Send commands to query the location of the vehicle, send commands to control the air conditioner, etc.
  • the user interface shown in FIG. 6J may also be referred to as a first user interface.
  • the unbinding process can also be triggered on the vehicle control device 100 of the mobile phone category.
  • the vehicle control device 100 can set a control for unbinding in the user interface shown in FIG. 6A, FIG. 6I or FIG. Trigger the unbinding process.
  • the vehicle control device can query the vehicle status and Displays vehicle status, but cannot control the vehicle.
  • the vehicle control device can control the vehicle only after a secure binding relationship has been established between the vehicle control device and the vehicle, which ensures that the vehicle control device controls the vehicle through the key to prevent third parties from tampering or forging the vehicle control device to send Control instructions to the vehicle to ensure the safety of the vehicle.
  • the vehicle control device when the vehicle control device is only bound to the vehicle but not securely bound, the vehicle control device can also control the vehicle. In this case, the vehicle control device can prompt the user that the security of the control method is average.
  • the vehicle control device can perform operations such as querying vehicle status, controlling the vehicle, remotely diagnosing vehicle faults, etc., and communicating with the vehicle only after establishing a secure binding relationship with the vehicle.
  • KeyLai communicates with the vehicle to ensure that the data exchanged between the two parties can only be obtained by the vehicle control device and the vehicle, avoiding data leakage and ensuring the information security of both devices.
  • the vehicle 200 after receiving the message sent by the vehicle control device 100, the vehicle 200 generates a binding factor in response to the user operation.
  • the vehicle 200 can send a Bluetooth broadcast carrying its own identity. After the nearby vehicle control device 100 receives the Bluetooth broadcast, it can display the vehicle options corresponding to the vehicle 200 on the display screen. If the user operates the vehicle option, the vehicle control device 100 can establish a Bluetooth connection with the vehicle 200, and then send a Bluetooth message to the vehicle 200 to trigger the vehicle 200 to generate a binding factor. Exemplarily, as shown in FIG. 5E , the vehicle control device 100 displays a plurality of vehicle options, including the vehicle options of the vehicle 200. The vehicle 200 sends the Bluetooth message. In some other implementations, if the only Bluetooth device searched by the vehicle control device 100 is the vehicle 200 , the vehicle control device 100 may directly send a Bluetooth message to the vehicle 200 without user input.
  • the binding factor may be one or a group of random numbers.
  • the vehicle 200 may use a preset random number generation algorithm to generate the binding factor.
  • S101 may be executed by a binding function module in the vehicle 200 .
  • the vehicle control device 100 acquires the binding factor generated by the vehicle 200.
  • Mode 1 After the vehicle 200 generates the binding factor, it converts the binding factor into a two-dimensional code, a digital password (such as a personal identification code (Personal Identification Number, PIN)), a barcode, etc., and displays the converted content on the display Afterwards, the vehicle control device 100 acquires the binding factor by scanning a two-dimensional code, a barcode or receiving an input digital password.
  • Fig. 4G shows the two-dimensional code carrying the binding factor displayed by the vehicle 200
  • Fig. 4I shows the digital password carrying the binding factor displayed by the vehicle 200
  • Fig. 5G and Fig. 5H show the vehicle control device 100 A user interface for receiving an input digital password.
  • the vehicle control device 100 and the vehicle 200 each generate a shared key (prekey) according to the binding factor.
  • the vehicle control device 100 and the vehicle 200 are preset with the same algorithm and parameters, and the vehicle control device 100 and the vehicle 200 use the same algorithm and parameters to generate the same shared key prekey.
  • the embodiment of this application does not limit the algorithm.
  • the shared secret prekey can be a random number or a set of random numbers.
  • the length and complexity of the shared key prekey may be higher than the length and complexity of the binding factor.
  • S103 may be executed by the cryptographic algorithm modules in the vehicle control device 100 and the vehicle 200 .
  • S104 may specifically include the following steps:
  • a binding key bindkey of sufficient length and complexity that is known only to the vehicle control device 100 and the vehicle 200 can be obtained. In this way, the communication security between the subsequent vehicle control device 100 and the vehicle 200 can be guaranteed.
  • the purpose of the above S101-S104 is to allow the vehicle control device 100 and the vehicle 200 to negotiate a key known only to both parties.
  • other technical means may also be used to achieve this purpose.
  • the technical means used in the above S101-S102 can be slightly modified to obtain the following solutions:
  • the binding factor generated by the vehicle 200 is directly used as the binding key bindkey, so that the above S103-S104 does not need to be performed, which can reduce the operations of both parties.
  • the vehicle 200 may receive the binding key bindkey directly input by the user, and then the vehicle control device 100 obtains the binding key bindkey from the vehicle 200 through a similar method in S102 above.
  • the vehicle control device 100 and the vehicle 200 can use short-range communication technology (such as Bluetooth, NFC, Wi-Fi communication technology) to exchange device information.
  • S105 may be executed by cooperation of the near-end interaction modules of the vehicle control device 100 and the vehicle 200 .
  • the vehicle control device 100 and the vehicle 200 if the vehicle control device 100 and the vehicle 200 have established a communication connection (such as a Bluetooth communication connection, a Wi-Fi communication connection) during the aforementioned S101-S104 process, then the vehicle control device 100 and the vehicle 200 will The DT has already been exchanged in , and there is no need to repeat the DT exchange at this time.
  • a communication connection such as a Bluetooth communication connection, a Wi-Fi communication connection
  • the device information exchanged by the two parties may also include the account currently used to log in to the server 300 .
  • the step of exchanging accounts can be performed before S104, and can also be performed after S104.
  • step S106 the security binding relationship is established successfully; if not, the user can be prompted that the two accounts are different, such as the prompt in the upper right corner of Figure 5F, and the security binding relationship cannot be established.
  • the vehicle control device 100 associates and stores the identification of the vehicle 200 and the binding key bindkey, as shown in Table 1 for example; the vehicle 200 associates and stores The identification and binding key bindkey of the vehicle control device 100 are shown in Table 2, for example.
  • the vehicle control device 100 and the vehicle 200 establish a secure binding relationship based on an account number and a key
  • the vehicle control device 100 stores the identification of the vehicle 200, the account number of the vehicle control device 100, the account number of the vehicle 200, and the binding
  • the key bindkey is, for example, shown in Table 3; the vehicle 200 associates and stores the identifier of the vehicle control device 100 , the account of the vehicle control device 100 , the account of the vehicle 200 , and the binding key bindkey, as shown in Table 4 for example.
  • the vehicle control device 100 or the vehicle 200 can store the security binding relationship in the security unit, which can ensure that the security binding relationship is not leaked, and ensure that only the corresponding vehicle control device 100 and the vehicle control device 200 have binding keys. The vehicle 200 is informed, thereby ensuring the communication security between the two.
  • the vehicle control device 100 and the vehicle 200 can obtain a binding key bind key known only to both parties through short-distance communication technology.
  • both the vehicle control device 100 and the vehicle 200 may disconnect from the server 300 first, and then perform the above-mentioned process shown in FIG. 7 through short-distance communication technology.
  • the vehicle control device 100 and Before the vehicle 200 establishes the secure binding relationship the user may also be prompted to disconnect from the server 300 .
  • the ways for the car control device 100 or the vehicle 200 to disconnect from the server 300 may include but not limited to: turn off the Wi-Fi function, turn off the cellular network, and so on.
  • the connection between the vehicle control device 100 and the vehicle 200 and the server 300 is cut off, even if the server 300 has a security hole, it can also ensure that the key communicated by the two parties will not be obtained by the server 300, thereby ensuring subsequent binding based on the binding key.
  • the security of the key communication process If the vehicle control device 100 and the vehicle 200 disconnect from the server 300 , the account exchanged between the vehicle control device 100 and the vehicle 200 in S105 may be the account used to log in to the server 300 last time.
  • the vehicle control device 100 and the vehicle 200 can negotiate a key through the long-distance communication technology.
  • the distance between the vehicle control device 100 on the user side and the vehicle 200 is usually relatively long. binding relationship.
  • the process of establishing a secure binding relationship through long-distance communication technology may include the following steps:
  • 6A-6G exemplarily show the user interface displayed by the vehicle control device 100 in scene 1, and reference may be made to related descriptions.
  • Scenario 2 when the vehicle control device 100 has been bound to the vehicle 200 but is not securely bound, the information of the vehicle 200 can be displayed. If a user operation for entering the vehicle control interface is received, or a user operation for controlling The vehicle control device 100 can be triggered to be safely bound to the vehicle 200 by the user operation of the vehicle; and the vehicle control device 100 can also send a binding request to the vehicle 200 through the server 300, so that the vehicle 200 is triggered and the vehicle control device 100% secure binding.
  • FIG. 5A exemplarily shows the vehicle information displayed when the vehicle control device 100 is not securely bound to the vehicle 200. After the vehicle control device 100 detects a user operation acting on the user interface 51, it can be triggered and correspondingly The vehicle 200 is securely bound.
  • Scenario 3 The user on the vehicle control device 100 selects the vehicle 200 on the vehicle control device 100, and triggers the security binding between the vehicle control device 100 and the vehicle 200; the user on the vehicle 200 side selects the vehicle control device 100 on the vehicle 200, and triggers the The vehicle 200 and the vehicle control device 100 are securely bound.
  • the embodiment of the present application does not limit the manner in which the user selects the vehicle control device or the vehicle, and the manner in which the security binding between the vehicle control device or the vehicle and the peer device is triggered.
  • the user may input the identification of the vehicle 200 into the vehicle control device 100 to trigger the secure binding of the vehicle control device 100 and the vehicle 200 .
  • the vehicle control device 100 and the vehicle 200 may perform a subsequent security binding process.
  • the vehicle control device 100 and the vehicle 200 negotiate a key bindkey through the server 300 .
  • the vehicle control device 100 logs in to the server 300
  • the vehicle 200 logs in to the server 300 .
  • the embodiment of the present application does not limit the execution sequence of S203, S203 only needs to be executed before S204, and its sequence with S201-S202 is not limited.
  • the vehicle control device 100 may use the first account to log in to the server 300 through the vehicle management application. Similarly, the vehicle 200 can log in to the server 300 using the first account through the vehicle management application.
  • the first account and the second account may be the same account or different accounts.
  • S204 can refer to S1042 in FIG. 7, the difference is that, when exchanging the public key at S204, there is no need to encrypt with the shared key pre key.
  • the vehicle control device 100 and the vehicle 200 respectively use the public key of the opposite end and its own private key to calculate the binding key bind key.
  • S205 may refer to S1043 in FIG. 7, the difference is that in S205, the vehicle control device 100 and the vehicle 200 can obtain the public key of the peer device without decrypting with the shared key pre key.
  • the purpose of the above S202, S204-S205 is to enable the vehicle control device 100 and the vehicle 200 to negotiate a key known only to both parties.
  • other technical means may also be used to achieve this purpose.
  • the vehicle control device 100 or the vehicle 200 may receive the binding key bindkey directly input by the user, and then send the binding key bindkey to the peer device through the server 300 .
  • the vehicle control device 100 and the vehicle 200 may prompt the user to connect to server 300.
  • the way in which the vehicle control device 100 or the vehicle 200 is connected to the server 300 may include but not limited to: enabling the Wi-Fi function, enabling the cellular network, and so on.
  • the vehicle control device 100 communicates with the vehicle 200 based on a secure binding relationship.
  • FIG. 9 shows a process in which the vehicle control device 100 sends data to the vehicle 200 .
  • FIG. 9 takes the communication process between the vehicle control device 100 and the vehicle 200 based on the server 300 as an example.
  • the process may include the following steps:
  • the vehicle control device 100 generates data to be sent to the vehicle 200 .
  • An instruction to remotely control the vehicle 200 is used to remotely control the vehicle 200 to perform corresponding operations, such as remote lock/unlock command, remote window open/close window command, remote start command, remote door open command, remote start/close air conditioner command, and remote call vehicle command , remote lighting instructions and so on.
  • the command is used to remotely obtain the status and other information of the vehicle 200 .
  • the command is used to remotely obtain the status and other information of the vehicle 200 .
  • instructions for remotely viewing the camera monitoring inside the vehicle instructions for downloading vehicle monitoring data, instructions for downloading vehicle operation logs, instructions for viewing the location of the vehicle, instructions for viewing vehicle driving records, and so on.
  • the vehicle control device 100 may generate data to be sent to the vehicle 200 after receiving a user operation. For example, referring to FIG. 5N, when the vehicle control device 100 detects a user operation on any one of the control options 506-509, it will generate a corresponding instruction for controlling the car lock, send an instruction for controlling the window, and send an instruction for querying the vehicle. Position command, send command to control air conditioner.
  • the vehicle control device 100 uses the stored binding key bindkey to encrypt the data to be sent.
  • the vehicle control device 100 may search for the binding key bind key corresponding to the vehicle 200 in the stored security binding relationship. If the vehicle control device 100 stores a key-based security binding relationship, the corresponding binding key bind key can be found according to the identification of the vehicle 200 . If the vehicle control device 100 stores a security binding relationship based on an account number and a key, the corresponding binding key can be found according to the identification of the vehicle 200 and the account used by the current vehicle control device 100 and/or vehicle 200 to log in to the server 300. key bind key.
  • the vehicle control device 100 may select a data encryption algorithm according to actual needs.
  • the vehicle control device 100 may use an algorithm to ensure data integrity to encrypt data.
  • integrity algorithms can be used for some non-privacy-related non-sensitive data such as instructions to start the air conditioner and turn on the lights. Integrity refers to ensuring that information or data is not tampered with by unauthorized parties or can be quickly discovered after being tampered with during the process of transmitting and storing information or data. Algorithms to ensure data integrity may include, but are not limited to: hash-based message authentication code (hash-based message authentication code, HMAC) and other encryption algorithms.
  • HMAC hash-based message authentication code
  • the vehicle control device 100 may use an algorithm that ensures data confidentiality to encrypt data.
  • confidentiality algorithms can be used for some sensitive data related to privacy, such as instructions to check vehicle location, unlock instructions, etc. Confidentiality refers to ensuring that information or data cannot be obtained by unauthorized parties during the process of transmitting and storing information or data. Algorithms to ensure data confidentiality may include, but are not limited to: the advanced encryption standard (AES) of cipher block chaining (cipher block chaining, CBC), that is, AES-CBC.
  • AES advanced encryption standard
  • CBC cipher block chaining
  • the vehicle control device 100 may use an algorithm that simultaneously ensures data confidentiality and integrity to encrypt data.
  • Algorithms that simultaneously ensure data confidentiality and integrity may include, but are not limited to: Advanced Encryption Standard (AES) in calculator mode (galois/counter mode, GSM), that is, AES-GSM.
  • AES Advanced Encryption Standard
  • GSM Galois/counter mode
  • the vehicle control device 100 sends the encrypted data to the vehicle 200 through the server 300 .
  • vehicle control device 100 while the vehicle control device 100 is sending the encrypted data, it may also log the current vehicle control device 100 into the first account used by the server 300, and/or, the device identification of the vehicle control device 100 is passed through the server 300 at the same time. 300 is sent to vehicle 200 .
  • the vehicle 200 uses the stored binding key bindkey to decrypt the received data to obtain the original data.
  • the vehicle 200 can also search the stored security binding relationship to check whether the received device identification is included in the device identification of each device bound to it, if If yes, execute S304, if not, do not execute S304. In this way, an unbound vehicle control device or a third party can be prevented from sending data and causing the vehicle 200 to perform meaningless decryption operations.
  • the vehicle 200 can also look up the stored security binding relationship to check whether the received account is included in the accounts of each device bound to it, and if so, , execute S304, and if not, do not execute S304. In this way, the vehicle 200 can be prevented from performing meaningless decryption operations by sending data from an unbound account.
  • the vehicle 200 may search for the binding key bind key corresponding to the vehicle control device 100 in the stored security binding relationship. If the vehicle 200 stores a key-based security binding relationship, the corresponding binding key bind key can be found according to the identification of the vehicle 200 . If the vehicle 200 has stored the security binding relationship based on the account number and the key, the corresponding binding key bind can be found according to the identification of the vehicle 200 and the account used by the current vehicle control device 100 and/or the vehicle 200 to log in to the server 300 key.
  • the vehicle 200 decrypts the received data using the same algorithm used by the vehicle control device 100 to encrypt in S302.
  • the algorithm may be used by the vehicle control device 100 and the vehicle 200 through negotiation, or may be an algorithm that is preset for use.
  • the vehicle 200 performs corresponding operations according to the data.
  • the vehicle 200 performs corresponding operations according to the instruction. For example, the vehicle 200 can unlock, open the window, inquire about the location and return the location to the vehicle control device 100 , send monitoring images to the vehicle control device 100 , send the driving recorder to the vehicle control device 100 and so on according to the instruction.
  • the vehicle control device 100 and the vehicle 200 respectively store a key known only to both parties.
  • the vehicle control device 100 uses the key to encrypt data and then sends it to the vehicle 200.
  • the vehicle 200 uses the same key.
  • FIG. 10 shows a process in which the vehicle 200 sends data to the vehicle control device 100 .
  • FIG. 10 takes the communication process between the vehicle control device 100 and the vehicle 200 based on the server 300 as an example.
  • the vehicle 200 acquires data to be sent to the vehicle control device 100 .
  • the data sent by the vehicle 200 to the vehicle control device 100 may include but not limited to the following categories: (1) Data representing vehicle status, such as window status, transmitter status, door status, air conditioner status, vehicle location, and so on. (2) Data stored in the vehicle itself, such as monitoring data, running logs, driving records, etc.
  • the vehicle 200 may acquire data to be sent to the vehicle control device 100 after receiving the instruction sent by the vehicle 200 .
  • the vehicle 200 may acquire data to be sent to the vehicle control device 100, such as the status of the car lock, the status of the window, the position of the vehicle, the status of the air conditioner and so on.
  • the vehicle control device 100 uses the stored binding key bindkey to decrypt the received data to obtain the original data.
  • the vehicle control device 100 after decryption is data representing the state of the vehicle sent by the vehicle 200, data stored in the vehicle itself, etc.
  • the vehicle control device can store these data, and can also display these data on the display screen for future use. user view.
  • the communication process between the vehicle control device 100 and the vehicle 200 is not limited to the server 300 shown in FIG. 9 and FIG. bindkey communication.
  • the communication process between the vehicle control device 100 and the vehicle 200 using short-distance communication technology is similar to the process described in FIG. 9 and FIG. 10 , except that the communication technology is different.
  • the binding key bindkey used for communication between the vehicle control device and the vehicle may also be referred to as a first key.
  • the data sent during the communication between the vehicle control device and the vehicle in FIGS. 9-10 may be referred to as first data.
  • the vehicle control device and the vehicle establish a security binding relationship, and communicate based on the security binding relationship, which can ensure that the data exchanged between the two parties is only the vehicle control device with the security binding relationship and the vehicle can be obtained to prevent the interaction data between the two parties from being obtained, tampered with or forged by a third party.
  • the information security of both the vehicle and the vehicle control equipment can be guaranteed, thereby avoiding the leakage of the private data of the user in the vehicle, the control of the vehicle by a third party, the loss of the vehicle, and the control of multiple vehicles in batches by a third party, etc., and improving the safety of the vehicle.
  • the third party here refers to the vehicle control equipment, other equipment or institutions other than the vehicle.
  • FIGS. 7-10 only show a scheme in which the vehicle control device and the vehicle negotiate a key and communicate using the symmetric key algorithm and the key.
  • the vehicle control device and the vehicle may also negotiate a pair of keys or two pairs of keys, and communicate using the pair of keys or the two pairs of keys.
  • the embodiment of the present application does not limit the manner in which the vehicle control device and the vehicle negotiate one or two pairs of keys.
  • the communication data between the vehicle control device and the server can pass through the hypertext transfer protocol (hyper text transfer protocol over secure socket layer, HTTPS) encryption, the communication data between the vehicle and the server can also be encrypted through the TLS-based message queuing telemetry transport protocol (message queuing telemetry transport, MQTT) protocol, so as to further ensure that the vehicle control equipment and the vehicle Security of the communication channel when communicating through the server.
  • HTTPS hypertext transfer protocol over secure socket layer
  • MQTT message queuing telemetry transport
  • each step in the foregoing method embodiments may be implemented by an integrated logic circuit of hardware in a processor or instructions in the form of software.
  • the method steps disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.
  • the system-on-a-chip may consist of chips, or may include chips and other discrete devices.
  • processors in the chip system there may be one or more processors in the chip system.
  • the processor can be realized by hardware or by software.
  • the processor may be a logic circuit, an integrated circuit, or the like.
  • the processor may be a general-purpose processor implemented by reading software codes stored in a memory.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website, computer, server or data center Transmission to another website site, computer, server, or data center by wired (eg, coaxial cable, optical fiber, DSL) or wireless (eg, infrared, wireless, microwave, etc.) means.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrated with one or more available media.
  • the available medium may be a magnetic medium (such as a floppy disk, a hard disk, or a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (solid state disk, SSD)), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了针对车辆的安全通信方法、相关装置及通信系统。车控设备和车辆使用只有双方知晓的密钥对需要发送给对端设备的数据进行加密，将加密后的数据发送给对端设备，对端设备接收到加密后的数据后，使用该密钥解密数据。实施该技术方案，相当于在车控设备和车辆之间建立了点对点的安全通道，能够保证双方交互的数据只有该车控设备和该车辆能够获取到，避免双方的交互数据被第三方获取、篡改或伪造，可以保障车辆及车控设备双方的信息安全，提高车辆的安全性。

Description

针对车辆的安全通信方法、相关装置及通信系统
本申请要求于2022年02月14日提交中国专利局、申请号为202210134460.8、申请名称为“一种车控设备绑定方法”的中国专利申请、于2022年06月29日提交中国专利局、申请号为202210751865.6、申请名称为“针对车辆的安全通信方法、相关装置及通信系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及针对车辆的安全通信方法、相关装置及通信系统。
背景技术
随着车辆功能及网络通信功能的增强，车控设备如手机、智能手表、车辆故障诊断终端等可以通过网络和车辆远程通信，如远程控制车辆、远程查询车辆状态、远程诊断车辆故障等。这种远程交互的方式，给用户带来了极大的便利。
但是，和车辆的远程交互依赖于公共网络及服务器，如果公共网络或者服务器出现安全漏洞，则可能出现第三方篡改或者伪造与车辆交互的数据，造成车辆的隐私数据泄露、车辆丢失、甚至多车辆批量被控制等后果。例如，被攻击的服务器可能在车主不知情的情况下，伪造车控设备的控制指令，以查看、修改车辆数据，这会威胁到车辆安全。
如何保障通信过程中车辆的安全，是当前研究的方向。
发明内容
本申请提供了针对车辆的安全通信方法、相关装置及通信系统，可以保证车控设备和车辆交互的数据只有双方能够获取到，避免该交互数据被第三方获取、篡改或伪造，可以保障车辆及车控设备双方的信息安全，提高车辆的安全性。
第一方面，提供了一种针对车辆的安全通信方法，应用于包括车控设备和车辆的通信系统。该方法包括：车控设备生成待发送的第一数据，使用第一密钥对第一数据进行加密；车控设备将加密后的第一数据发送给车辆；车辆接收到车控设备发送的加密后的第一数据；车辆使用第一密钥解密加密后的第一数据，得到第一数据；车辆根据第一数据执行对应的操作。
实施第一方面提供的方法，车控设备和车辆基于密钥来通信，相当于在车控设备和车辆之间建立了点对点的安全通道，能够保证双方交互的数据只有该车控设备和该车辆能够获取到，避免双方的交互数据被第三方获取、篡改或伪造。这样可以保障车辆及车控设备双方的信息安全，进而避免了车辆中用户的隐私数据泄露、车辆被第三方控制、车辆丢失、多车辆批量被第三方控制等情况，提高了车辆的安全性。这里的第三方指车控设备、车辆以外的其他设备或机构。
结合第一方面，在一些实施方式中，第一数据包括远程控制指令，远程控制指令用于指示车辆执行对应的操作；或者，第一数据包括远程监控指令，远程监控指令用于查询车辆的状态。
结合第一方面，在一些实施方式中，该方法还可以包括：车辆获取待发送的第二数据，使用第一密钥对第二数据进行加密；车辆将加密后的第二数据发送给车控设备；车控设备接 收到车辆发送的加密后的第二数据；车控设备使用第一密钥解密加密后的第二数据，得到第二数据；车控设备根据第二数据执行对应的操作。
在一些实施方式中，第二数据可以包括表征车辆的状态的数据，和/或，车辆的运行数据。
结合第一方面，在一些实施方式中，车控设备和车辆可以通过以下方式获取第一密钥：
方式1，车控设备和车辆协商得到第一密钥；
方式2，车控设备确定第一密钥后，将第一密钥发送给车辆；
方式3，车控设备接收到车辆发送的第一密钥，并且第一密钥由车辆确定。
进一步地使用方式1时，车控设备和车辆可以有以下两种方案来协商第一密钥：
方案1，车控设备和车辆通过近距离通信技术来协商第一密钥。
具体的，车辆显示二维码或条形码或数字密码，车控设备扫描车辆显示的二维码或条形码，或者，接收到输入的和车辆显示的数字密码相同的数字密码，二维码、条形码、数字密码均携带有车辆生成的绑定因子；或者，车辆通过近场通信NFC将绑定因子发送给车控设备；
车控设备、车辆都根据绑定因子生成共享密钥；
车辆和车控设备，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到第一密钥，并且车辆在协商过程中使用共享密钥加密发送给车控设备的公钥，车辆和车控设备在协商过程中通过近距离通信技术通信。
通过方案1，ECDH算法能够保证车控设备和车辆可以安全地获知对端设备的公钥，再结合只有本端设备获知的私钥，该车控设备和车辆就能够得到只有双方知晓的、安全的第一密钥。此外，近距离通信技术能够让车控设备和车辆可以方便、快捷地协商得到第一密钥。
在方案1中，通过ECDH算法协商第一密钥的过程可包括：车控设备和车辆都使用相同的椭圆曲线参数生成不同的椭圆曲线密钥对，使用共享密钥加密各自的公钥后发送给对端设备，然后各自使用对端的公钥和自己的私钥，计算得到第一密钥。
在一些实施方式中，车控设备和车辆通过方案1来协商第一密钥的过程中，车控设备断开和服务器的连接，车辆也可以断开和服务器的连接，服务器用于管理车辆。由于切断了车控设备、车辆分别与服务器的连接，即使服务器存在安全漏洞，也可以保证双方协商的第一密钥不被服务器获取，进而保障后续基于该第一密钥的通信过程的安全。
方案2，车控设备和车辆通过远距离通信技术来协商第一密钥。
具体的，车控设备和车辆，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到第一密钥，并且车控设备和车辆在协商过程中通过服务器通信，服务器用于管理车辆。
通过方案2，ECDH算法能够保证车控设备和车辆可以安全地获知对端设备的公钥，再结合只有本端设备获知的私钥，该车控设备和车辆就能够得到只有双方知晓的、安全的第一密钥。
在方案2中，通过ECDH算法协商第一密钥的过程可包括：车控设备和车辆都使用相同的椭圆曲线参数生成不同的椭圆曲线密钥对，将各自的公钥后发送给对端设备，然后各自使用对端的公钥和自己的私钥，计算得到第一密钥。
在一些实施方式中，在通过方案2协商得到第一密钥之前，车控设备可以接收到输入的手机号码；车控设备显示一个或多个车辆选项，一个或多个车辆选项对应手机号码下购买的车辆；车控设备接收到作用于车辆选项的用户操作，向车辆发送绑定请求；和车控设备协商第一密钥的车辆为，接收到用户操作的车辆选项对应的车辆。在一些实施方式中，车控设备可以根据手机号码从服务器中查询得到其下购买的车辆的信息。
结合第一方面，在一些实施方式中，车控设备和车辆协商得到第一密钥之后，方法还包 括：车控设备和车辆均关联存储车辆的标识，和，第一密钥。这样，车控设备可以根据关联存储的信息，找到和车辆对应的第一密钥，并使用该第一密钥对和该车辆通信的数据进行处理(包括加密或解密)。并且，车辆可以根据关联存储的信息，找到和车控设备对应的第一密钥，并使用该第一密钥对和该车控设备通信的数据进行处理(包括加密或解密)。
结合第一方面，在一些实施方式中，车控设备和车辆使用相同账号登录到服务器，服务器用于管理车辆。这样相当于在登录了特定账号的车控设备，和，登录了特定账号的车辆之间建立了点对点的安全通道，可以避免登录了特定账号的车控设备，和，登录了特定账号的车辆之间的通信数据被第三方获取、篡改或伪造。
结合第一方面，在一些实施方式中，车控设备生成待发送的第一数据之前，车控设备可以显示第一用户界面，第一用户界面包括一个或多个控制选项；车控设备接收到作用于控制选项上的用户操作，用户操作用于触发车控设备生成待发送的第一数据。
结合第一方面，在一些实施方式中，车控设备和车辆之间的通信数据，可以通过服务器转发。
结合第一方面，在一些实施方式中，车控设备和车辆通信时，可以根据实际需求选择所使用的加密算法。例如，在对传输的数据有完整性要求的情况下，可以使用保证数据完整性的算法来对数据进行加密，在对传输的数据有机密性要求的情况下，可以使用保证数据机密性的算法来对数据进行加密。
第二方面，提供了一种针对车辆的安全通信方法，应用于车控设备，该方法包括：车控设备生成待发送的第一数据，使用第一密钥对第一数据进行加密；车控设备将加密后的第一数据发送给车辆。
结合第二方面，在一些实施方式中，该方法还包括：车控设备接收到车辆发送的加密后的第二数据；车控设备使用第一密钥解密加密后的第二数据，得到第二数据；车控设备根据第二数据执行对应的操作。
实施第二方面提供的方法，车控设备使用第一密钥来处理和车辆之间的通信数据，能够保证该通信数据只有该车控设备和该车辆能够获取到，避免该通信数据被第三方获取、篡改或伪造。这样可以保障车辆及车控设备双方的信息安全，进而避免了车辆中用户的隐私数据泄露、车辆被第三方控制、车辆丢失、多车辆批量被第三方控制等情况，提高了车辆的安全性。这里的第三方指车控设备、车辆以外的其他设备或机构。
在第二方面提供的方法中，车控设备所执行的操作，可参考第一方面或第一方面的任意一种实施方式中车控设备所执行的操作，这里不再赘述。
第三方面，提供了一种针对车辆的安全通信方法，应用于车控设备，该方法包括：车辆接收到车控设备发送的加密后的第一数据；车辆使用第一密钥解密加密后的第一数据，得到第一数据；车辆根据第一数据执行对应的操作。
结合第三方面，在一些实施方式中，该方法还包括：车辆获取待发送的第二数据，使用第一密钥对第二数据进行加密；车辆将加密后的第二数据发送给车控设备。
实施第三方面提供的方法，车辆使用第一密钥来处理和车控设备之间的通信数据，能够保证该通信数据只有该车控设备和该车辆能够获取到，避免该通信数据被第三方获取、篡改或伪造。这样可以保障车辆及车控设备双方的信息安全，进而避免了车辆中用户的隐私数据泄露、车辆被第三方控制、车辆丢失、多车辆批量被第三方控制等情况，提高了车辆的安全性。这里的第三方指车控设备、车辆以外的其他设备或机构。
在第三方面提供的方法中，车辆所执行的操作，可参考第一方面或第一方面的任意一种 实施方式中车辆所执行的操作，这里不再赘述。
第四方面，提供了一种车控设备，包括：存储器、一个或多个处理器；存储器与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，一个或多个处理器调用计算机指令以使得车控设备执行如第二方面或第二方面任意一种实施方式的方法。
第五方面，提供了一种车辆，包括：存储器、一个或多个处理器；存储器与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，一个或多个处理器调用计算机指令以使得车辆执行如第三方面或第三方面任意一种实施方式的方法。
第六方面，提供了通信系统，包括车控设备和车辆，车控设备用于执行如第二方面或第二方面任意一种实施方式的方法，车辆用于执行如第三方面或第三方面任意一种实施方式的方法。
第七方面，提供了一种计算机可读存储介质，包括指令，当指令在电子设备上运行时，使得电子设备执行如第二方面或第二方面任意一种实施方式的方法。
第八方面，提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第二方面或第二方面任意一种实施方式的方法。
第九方面，提供了一种计算机可读存储介质，包括指令，当指令在电子设备上运行时，使得电子设备执行如第二方面或第二方面任意一种实施方式的方法。
第十方面，提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行第三方面或第三方面任意一种实施方式的方法。
第十一方面，提供了一种芯片系统，所述芯片系统包括至少一个处理器，用于实现上述第二方面或第二方面任意一种实施方式，或第三方面或第三方面任意一种实施方式的方法。
实施本申请提供的技术方案，车控设备和车辆使用只有双方知晓的密钥对需要发送给对端设备的数据进行加密，将加密后的数据发送给对端设备，对端设备接收到加密后的数据后，使用该密钥解密数据。实施该技术方案，相当于在车控设备和车辆之间建立了点对点的安全通道，能够保证双方交互的数据只有该车控设备和该车辆能够获取到，避免双方的交互数据被第三方获取、篡改或伪造，可以保障车辆及车控设备双方的信息安全，提高车辆的安全性。
附图说明
图1为本申请实施例提供的通信系统的架构图；
图2A为本申请实施例提供的车控设备的硬件结构框图；
图2B、图2C为本申请实施例提供的车控设备的软件架构；
图3A为本申请实施例提供的车辆的硬件结构框图；
图3B为本申请实施例提供的车辆的软件架构；
图4A-图4Z，为本申请实施例提供的在车辆上实现的一组用户界面；
图4-1为本申请实施例提供的在车辆上实现的用户界面；
图5A-图5N，为本申请实施例提供的在手表类型的车控设备上实现的一组用户界面；
图6A-图6J，为本申请实施例提供的在手机类型的车控设备上实现的一组用户界面；
图7示出了一种车控设备和车辆通过近距离通信技术建立安全绑定关系的流程图；
图8示出了一种车控设备和车辆通过远距离通信技术建立安全绑定关系的流程图；
图9示出了一种车控设备向车辆发送数据的流程图；
图10示出了一种车辆向车控设备发送数据的流程图。
具体实施方式
下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。
以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
本申请以下实施例中的术语“用户界面(user interface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面是通过java、可扩展标记语言(extensible markup language，XML)等特定计算机语言编写的源代码，界面源代码在电子设备上经过解析，渲染，最终呈现为用户可以识别的内容。用户界面常用的表现形式是图形用户界面(graphic user interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的文本、图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。
本申请以下实施例提供了针对车辆的安全通信方法、相关装置及通信系统。在该方法中，车控设备和车辆分别存储有密钥(key)，在通信过程中，车控设备和车辆使用该密钥对需要发送给对端设备的数据进行加密，然后将加密后的数据发送给对端设备。对端设备接收到加密后的数据后，可以使用预先存储的密钥解密该数据。
通过本申请实施例提供的针对车辆的安全通信方法，基于车控设备和车辆存储的密钥来通信，相当于在车控设备和车辆之间建立了点对点的安全通道，能够保证双方交互的数据只有该车控设备和该车辆能够获取到，避免双方的交互数据被第三方获取、篡改或伪造。这样可以保障车辆及车控设备双方的信息安全，进而避免了车辆中用户的隐私数据泄露、车辆被第三方控制、车辆丢失、多车辆批量被第三方控制等情况，提高了车辆的安全性。这里的第三方指车控设备、车辆以外的其他设备或机构。
在一些实施方式中，车控设备和车辆之间的通信过程可以通过公共网络以及服务器进行。实施本申请实施例提供的方法，服务器不能够获取、篡改或者伪造车控设备和车辆之间的通信数据，即使公共网络或服务器存在安全漏洞，也不会对车辆及车控设备的安全性造成影响。在其他一些实施方式中，车控设备和车辆也可以通过近距离通信技术直接通信，无需通过服务器中转。
用于车控设备和车辆通信的密钥相当于同时和该车控设备及车辆绑定，因此该密钥也可以被称为绑定密钥(bindkey)。该密钥仅用于绑定的该车控设备和该车辆之间的通信。
车控设备和车辆存储的密钥可以由双方协商得到，也可以由一方确定后通知对端设备。车控设备和车辆之间可以通过近距离通信技术执行上述协商或通知密钥的过程。在一些实施方式中，车控设备和车辆都可以先断开与服务器之间的连接，然后再通过近距离通信技术执行上述协商或通知密钥的过程。这样，由于切断了车控设备、车辆分别与服务器的连接，即使服务器存在安全漏洞，也可以保证双方沟通的密钥不被服务器获取，进而保障基于该密钥的通信过程的安全。当然，在服务器的安全性有保障的情况下，车控设备和车辆之间也可以 通过服务器来执行上述协商或通知密钥的过程。
在一些实施方式中，车控设备和车辆可以分别存储有用于登录到服务器的账号，车控设备和车辆各自存储的只有双方知晓的密钥，可以同时和该车控设备的账号、该车辆的账号绑定。车控设备的账号和车辆的账号，可以相同，也可以不同。车控设备和车辆各自都使用自己的账号登录到服务器后，双方才能够基于该密钥通信，否则车控设备和车辆之间无法通信。即，如果车控设备或车辆登录到服务器的账号发生变化，则该车控设备和该车辆就不能通信。这样相当于在登录了特定账号的车控设备，和，登录了特定账号的车辆之间建立了点对点的安全通道，可以避免登录了特定账号的车控设备，和，登录了特定账号的车辆之间的通信数据被第三方获取、篡改或伪造。
车控设备和车辆可以各自存储一个只有双方知晓的密钥。在通信过程中，一方使用该密钥对数据进行加密后发送给另一方，另一方同样使用该密钥解密。
或者，车控设备和车辆可以共同存储一对密钥，一方存储公钥(publickey)，另一方存储该公钥对应的私钥(privatekey)。在通信过程中，一方使用自己存储的公钥或私钥对数据进行加密后发送给另一方，另一方使用存储的私钥或公钥解密。
或者，车控设备和车辆可以共同存储两对密钥，一方存储公钥1和私钥2，另一方存储私钥1和公钥2。在通信过程中，一方使用自己存储的私钥对数据进行加密后发送给另一方，另一方使用存储的公钥解密。这样，车控设备或车辆在加密及解密时可以使用不同的密钥。
在车控设备和车辆的通信过程中，车控设备或车辆可以根据实际需求选择数据的加密算法。例如，在有完整性要求的情况下，该车控设备或车辆可以使用保证数据完整性的算法来对数据进行加密。完整性是指在传输、存储信息或数据的过程中，确保信息或数据不被非授权方篡改或在被篡改后能够被迅速发现。又例如，在有机密性要求的情况下，该车控设备或车辆可以使用保证数据机密性的算法来对数据进行加密。机密性是指在传输、存储信息或数据的过程中，确保信息或数据不能够被非授权方获取。
下面首先介绍本申请实施例提供的通信系统。
参考图1，图1为本申请实施例提供的通信系统10的结构示意图。
如图1所示，本申请实施例提供的通信系统10包括：车控设备100、车辆200、服务器300，等等。
车控设备100可以包括各种类型的设备，本申请实施例对该车控设备100的具体类型不作限制。例如，该车控设备100可以包括手机，车辆故障诊断终端，还可以包括平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、大屏电视、智慧屏、可穿戴式设备(如智能手表、智能手环)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence，AI)设备、智能耳机，游戏机等便携式终端设备等等。
本申请实施例对车控设备100配置的软件操作系统(operating system，OS)不做限定，例如可包括但不限于等等。
车辆200可以包括大型汽车、小型汽车、电动车、摩托车、拖拉机等机动车。车辆200配置的OS可包括但不限于等。
车辆200可以通过基于蜂窝网络的车辆与万物(vehicle to everything，V2X)通信技术(cellular V2X，C-V2X)和通信系统10中的其他设备建立连接并通信。例如，车辆200可以连接到网络设备，以网络设备作为中间设备，和其他设备如车控设备100、服务器300等通信。C-V2X例如可包括基于长期演进(long term evolution，LTE)的V2X(LTE-V2X)、5G-V2X 等。不限于蜂窝网络，车辆200还可以基于其他无线通信技术例如短距离/近距离通信(short range communication)技术，和通信系统10中的其他设备通信。例如，车辆200可以通过无线保真(wireless-fidelity，Wi-Fi)、蓝牙(Bluetooth，BT)、近场通信(near field communication，NFC)，红外(infrared，IR)、超宽带(ultra-wideband，UWB)等技术和车控设备100等通信。蓝牙可以是经典蓝牙，也可以是低功耗蓝牙(bluetooth low energy，BLE)。
车控设备100和车辆200中均可以安装有车辆管理应用。车控设备100和车辆200中安装的车辆关系应用的形态及能力可以有所不同。车控设备100中的车辆管理应用为车控设备100提供各项服务，如车辆信息查询、车辆的远程控制、车辆的远程故障诊断等。车辆200中的车辆管理应用为车辆200提供各项服务，如导航、娱乐等。车控设备100或车辆200可以通过车辆管理应用及用户账号登录到服务器300，以使用该服务器300提供的各项服务。用户账号例如可以是名字、华为标识(identity，ID)、手机号码等身份标识。在一些实施方式中，用户在输入账号后，还要输入相应的密码、人脸图像、声纹、指纹、验证码等身份验证信息才能够通过车控设备100或车辆200中的车辆管理应用登录到服务器300。在其他一些方式中，即使用户没有输入账号，车控设备100或车辆200也可以访客形式使用该车辆管理应用提供的部分或全部服务。
服务器300可以由车辆厂商或第三方提供。服务器300用于管理车辆，为车辆管理应用提供各项服务，如导航、娱乐、车辆信息查询、车辆的远程控制、车辆的远程故障诊断等。服务器300可以是云服务器，也可以是本地服务器。服务器300也可以被称为车云服务器。服务器300的数量可以为一个或多个。
车控设备100、车辆200可以用于访问服务器300。服务器300和各个车控设备100、车辆200之间可通过3G、LTE、5G等蜂窝移动通信技术或广域网(wide area network，WAN)技术、局域网(LAN)技术通信。
在本申请一些实施方式中，车控设备100和车辆200可以建立基于密钥的安全绑定关系。车控设备100和车辆200建立基于密钥的安全绑定关系是指，车控设备100和车辆200首先绑定，然后双方协商密钥或由一方确定密钥后通知另一方，车控设备100和车辆200各自关联存储对端设备的标识和该密钥。车控设备100和车辆200协商或通知密钥的具体过程，密钥的具体形态，可参考后续方法实施例中的详细介绍。建立基于密钥的安全绑定关系后，车控设备100和车辆200可以基于该密钥通信。具体的，在两者的通信过程中，车控设备100和车辆200使用该密钥对需要发送给对端设备的数据进行加密，然后将加密后的数据发送给对端设备。对端设备接收到加密后的数据后，可以使用预先存储的密钥解密该数据。
一个车控设备可以和一个或多个车辆建立基于密钥的绑定关系，一个车辆也可以和一个或多个车控设备建立基于密钥的安全绑定关系。
参考表1，表1示例性示出了车控设备100中存储的基于密钥的安全绑定关系。
表1
如表1所示，车控设备100和车辆200、车辆400及车辆500之间均建立了基于密钥的安全绑定关系。车控设备100和车辆200基于key 1通信，车控设备100和车辆400基于key 2通信，车控设备100和车辆500基于key 3通信。
参考表2，表2示例性示出了车辆200中存储的基于密钥的安全绑定关系。
表2
如表2所示，车辆200和车控设备100、车控设备600及车控设备700之间均建立了基于密钥的安全绑定关系。车辆200和车控设备100基于key 1通信，车辆200和车控设备600基于key 4通信，车辆200和车控设备700基于key 5通信。
在本申请其他一些实施方式中，车控设备100和车辆200可以建立基于账号和密钥的安全绑定关系。车控设备100和车辆200建立基于账号和密钥的安全绑定关系是指，车控设备100和车辆200各自使用账号登录到服务器300后，首先两个设备相互绑定，然后双方协商密钥或由一方确定密钥后通知另一方，车控设备100和车辆200各自关联存储对端设备的标识、双方登录服务器300所使用的账号和该密钥。建立基于账号和密钥的安全绑定关系后，车控设备100和车辆200各自使用对应账号登录到服务器的情况下，双方可以基于该密钥通信。具体的，在两者的通信过程中，车控设备100和车辆200使用该密钥对需要发送给对端设备的数据进行加密，然后将加密后的数据发送给对端设备。对端设备接收到加密后的数据后，可以使用预先存储的密钥解密该数据。
在一些实施方式中，只有车控设备100和车辆200登录到服务器300所使用的账号相同，两者之间才能够建立基于账号和密钥的安全绑定关系。在一些实施方式中，即使车控设备100和车辆200登录的账号不同，两者也可以建立基于账号和密钥的绑定关系。
一个车控设备可以和一个或多个车辆建立基于账号和密钥的安全绑定关系，一个车辆也可以和一个或多个车控设备建立基于账号和密钥的安全绑定关系。
一个车控设备或一个车辆均可以通过一个或多个账号登录到服务器300。
参考表3，表3示例性示出了车控设备100中存储的基于账号和密钥的安全绑定关系。
表3
如表3所示，车控设备100和车辆200、车辆400及车辆500之间均建立了基于账号和密钥的安全绑定关系。车控设备100和车辆200均使用账号1登录到服务器300后，可以基于key6通信；车控设备100和车辆400均使用账号2登录到服务器300后，可以基于key 7通信；车控设备100和车辆500均使用账号3登录到服务器300后，可以基于key8通信。
参考表4，表4示例性示出了车辆200中存储的基于账号和密钥的安全绑定关系。

表4
如表4所示，车辆200和车控设备100、车控设备600及车控设备700之间均建立了基于账号和密钥的安全绑定关系。车辆200和车控设备100均使用账号1登录到服务器300后，可以基于key6通信；车辆200和车控设备600均使用账号4登录到服务器300后，可以基于key 9通信；车辆200和车控设备700均使用账号5登录到服务器300后，可以基于key 10通信。
在一些实施方式中，上述提及的车控设备的标识可以是设备序列号、媒体访问控制(media access control，MAC)地址、互联网协议(internet protocol，IP)地址等可以指示唯一设备的标识，车辆的标识可以是车架号、车牌号等可以指示唯一车辆的标识。
在一些实施方式中，上述车控设备100或车辆200中关联存储的安全绑定关系，可以存储于安全单元/安全芯片(secureelement，SE)，这样可以保证该安全绑定关系不被泄露，确保绑定密钥只有对应的车控设备100及车辆200获知，从而保证两者之间的通信安全。
图1所示的结构并不构成对通信系统10的具体限定。在本申请另一些实施例中，通信系统10可以包括比图示更多或更少的设备。例如，不限于图1所示的几个设备，通信系统10还可以包括提供通信服务运营商提供的网络设备，如基站(NodeB)、演进型基站(evolved Node B，eNB)，或者中继站等接入网设备，以提供公共网络，从而支撑车控设备100和车辆200之间的通信。
通信系统10也可以被称作车联网系统、V2X系统等其他名词，这里不做限定。
图2A示出了车控设备100的结构示意图。
车控设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本申请实施例示意的结构并不构成对车控设备100的具体限定。在本申请另一些实施例中，车控设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit， NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在本申请实施例中，处理器110用于使用密钥加密车控设备100将要发送给车辆200的数据，还用于使用密钥解密车辆200发送过来的加密的数据。
充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过车控设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。
车控设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。车控设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在车控设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。
调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。
无线通信模块160可以提供应用在车控设备100上的包括无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导 航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号解调以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，车控设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得车控设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。
在本申请实施例中，移动通信模块150或无线通信模块160可用于和车辆200之间协商密钥，或者，将车控设备100确定的密钥通知给车辆200，或者，接收到车辆200确定的密钥。移动通信模块150或无线通信模块160与车辆200之间的密钥协商过程，可参考后续方法实施例的详细描述。
在本申请实施例中，移动通信模块150或无线通信模块160还用于执行和车辆200之间基于密钥的通信。具体的，移动通信模块150或无线通信模块160可用于将使用密钥加密的数据发送给车辆200，也可以接收到车辆200发送的使用密钥加密的数据。移动通信模块150或无线通信模块160与车辆200之间的通信过程，可参考后续方法实施例的详细描述。
车控设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)。显示面板还可以采用有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，miniled，microled，micro-oled，量子点发光二极管(quantum dot light emitting diodes，QLED)等制造。在一些实施例中，车控设备可以包括1个或N个显示屏194，N为大于1的正整数。显示屏194可用于显示后续实施例介绍的一系列在车控设备100上实现的用户界面。
车控设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，车控设备100可以包括1个或N个摄像头193，N为大于1的正整数。
数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当车控设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。
视频编解码器用于对数字视频压缩或解压缩。车控设备100可以支持一种或多种视频编解码器。这样，车控设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。
NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现车控设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。
内部存储器121可以包括一个或多个随机存取存储器(random access memory，RAM)和一个或多个非易失性存储器(non-volatile memory，NVM)。
随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如机器指令)，还可以用于存储用户及应用程序的数据等。
非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。
外部存储器接口120可以用于连接外部的非易失性存储器，实现扩展车控设备100的存储能力。外部的非易失性存储器通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部的非易失性存储器中。
在本申请一些实施方式中，内部存储器121用于关联存储车控设备100和其他车辆基于密钥的绑定关系，例如可关联存储车控设备100、车辆200各自的标识，以及绑定的密钥。在本申请另一些实施方式中，内部存储器121用于关联存储车控设备100和其他车辆基于账号和密钥的绑定关系，例如可关联存储车控设备100、车辆200各自的标识，各自绑定的账号，以及绑定的密钥。
车控设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器180A，电极之间的电容改变。车控设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏194，车控设备100根据压力传感器180A检测所述触摸操作强度。车控设备100也可以根据压力传感器180A的检测信号计 算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。
触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于车控设备100的表面，与显示屏194所处的位置不同。
按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。车控设备100可以接收按键输入，产生与车控设备100的用户设置以及功能控制有关的键信号输入。
马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用(例如拍照，音频播放等)的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景(例如：时间提醒，接收信息，闹钟，游戏等)也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。
指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。
车控设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明车控设备100的软件结构。
图2B是本申请实施例的车控设备100的软件结构框图。
分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。
应用程序层可以包括一系列应用程序包。
如图2B所示，应用程序包可以包括车辆管理应用、相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。其中，车辆管理应用用于为车控设备100提供各项服务，如车辆信息查询、车辆的远程控制、车辆的远程故障诊断等。
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图2B所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。
视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面， 可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供车控设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。
资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，振动，指示灯闪烁等。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。
三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。
下面结合捕获拍照场景，示例性说明车控设备100软件以及硬件的工作流程。
当触摸传感器180K接收到触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，该单击操作所对应的控件为相机应用图标的控件为例，相机应用调用应用框架层的接口，启动相机应用，进而通过调用内核层启动摄像头驱动，通过摄像头193捕获静态图像或视频。
图2C是本申请实施例提供的另一种车控设备100的软件结构框图。
如图2C所示，车控设备100可包括：绑定功能模块、近端交互模块、对外网络交互模块、密码算法模块、车控数据处理模块。其中：
绑定功能模块，用于提供车控设备100和车辆200建立绑定关系时，该车控设备100所涉及的一系列用户界面。该用户界面可参考后续实施例的详细描述。
近端交互模块，用于和车辆200执行近距离通信。具体的，近端交互模块可支持车控设备100通过蓝牙、Wi-Fi、NFC等技术和其他设备通信。
对外网络交互模块，用于和车辆200执行远程通信，还可用于和服务器300进行通信。具体的，近端交互模块可支持车控设备100通过蜂窝网络、WAN、LAN等技术和其他设备通 信。
密码算法模块，用于计算车控设备100和车辆200协商密钥过程中所涉及到的一系列数学因子。
车控数据处理模块，用于使用密钥加密车控设备100将要发送给车辆200的数据，还用于使用密钥解密车辆200发送过来的加密的数据。
上述图2C示出的车控设备100的软件结构仅为示例，并不构成对车控设备100的具体限定。在本申请另一些实施例中，该车控设备100可以包括比图示更多或更少的单元，或者组合某些单元，或者拆分某些单元，或者不同的单元布置。例如，车控设备100的软件架构中还可以包括车辆管理应用，该车辆管理应用支持车控设备100登录到服务器300以获取服务器300提供的各项服务等等。
参考图3A，图3A为本申请实施例提供的车辆200的结构示意图。
如图3A所示，车辆200包括：控制器局域网络(controller area network，CAN)总线11、多个电子控制单元(electronic control unit，ECU)、发动机13、车载盒子(telematics box，T-box)14、变速器15、行车记录仪16、防抱死系统(antilock brake system，ABS)17、传感器系统18、摄像系统19，麦克风20，等等。
CAN总线11是支持分布式控制或实时控制的串行通信网络，用于连接车辆200的各个部件。在CAN总线11上的任何部件都可以监听到CAN总线11上传输的所有数据。CAN总线11传输的帧可以包含数据帧、远程帧、错误帧、过载帧，不同的帧传输不同类型的数据。在本申请实施例中，CAN总线11可用于传输各个部件在针对车辆的安全通信方法中涉及到的数据，该方法的具体实现可参考后文方法实施例的详细描述。
不限于CAN总线11，在其他一些实施例中，车辆200的各个部件还可以通过其他方式来连接及通信。如，各个部件还可以通过车载以太网(ethernet)局域互联网络(local interconnect network，LIN)总线、FlexRay及常用车载网络系统(media oriented systems，MOST)总线等等通信，本申请实施例对此不做限制。以下实施例以各个部件通过CAN总线11通信进行说明。
ECU相当于车辆200的处理器或大脑，用于根据从CAN总线11上获取的指令或者根据用户输入的操作，指示对应的部件执行相应的动作。ECU可以由安全芯片、微处理器((microcontroller unit，MCU)、随机存取存储器(random access memory，RAM)、只读存储器(random-only memory，ROM)、输入/输出接口(I/O)、模拟/数字转换器(A/D转换器)以及输入、输出、整形、驱动等大规模集成电路组成。
ECU的种类繁多，不同种类的ECU可以用于实现不同的功能。
车辆200中的多个ECU例如可包括：发动机ECU121，车载盒子(telematics box，T-box)的ECU122，变速器ECU123，行车记录仪ECU124，防抱死系统(antilock brake system，ABS)ECU 125等。
发动机ECU121用于管理发动机，协调发动机的各个功能，例如可用于启动发动机、关闭发动机等等。发动机是为车辆200提供动力的装置。发动机是将某一种形式的能量转换为机械能的机器。车辆200可用于将液体或气体燃烧的化学能，或者将电能转化为机械能并对外输出动力。发动机组成部分可以包括曲柄连杆机构和配气机构两大机构，以及冷却、润滑、点火、能量供给、启动系统等五大系统。发动机的主要部件有气缸体、气缸盖、活塞、活塞销、连杆、曲轴、飞轮等。
T-box ECU122用于管理T-box14。
T-box14主要负责和互联网通信，为车辆200提供远程通讯接口，提供包括导航、娱乐、行车数据采集、行驶轨迹记录、车辆故障监控、车辆远程查询和控制(如开闭锁、空调控制、车窗控制、发动机扭矩限制、发动机启停、调整座椅，查询电池电量、油量、车门状态等)、驾驶行为分析、无线热点分享、道路救援、异常提醒等服务。
T-box14可用于和汽车远程服务提供商(telematics service provider，TSP)以及用户(如驾驶员)侧电子设备(如车控设备100)通信，实现车控设备100上的车辆状态显示与控制。当用户通过车控设备100上的车辆管理应用发送控制命令后，TSP会发出请求指令到T-box14，T-box14在获取到控制命令后，通过CAN总线发送控制报文并实现对车辆200的控制，最后反馈操作结果到用户侧车控设备100上的车辆管理应用上。也就是说，T-box14通过CAN总线11读取到的数据，例如车况报告、行车报告、油耗统计、违章查询、位置轨迹、驾驶行为等数据，可以通过网络将传输到TSP后台系统，由TSP后台系统转发给用户侧的车控设备100，以供用户查看。
T-box14具体可包括通信模块和显示屏。
其中，通信模块可用于提供无线通信功能，支持车辆200通过无线局域网(wireless local area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)、超宽带(ultra-wideband，UWB)等无线通信技术和其他设备通信。通信模块还可用于提供移动通信功能，支持车辆200通过全球移动通讯系统(global system for mobile communications，GSM)、通用移动通信系统(universal Mobile telecommunications system，UMTS)、宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，5G以及未来出现的6G等通信技术和其他设备通信。
通信模块可以通过基于蜂窝网络的车辆与万物(vehicle to everything，V2X)通信技术(cellular V2X，C-V2X)和其他设备如服务器、用户侧电子设备等建立连接并通信。C-V2X例如可包括基于长期演进(long term evolution，LTE)的V2X(LTE-V2X)、5G-V2X等。
在本申请实施例中，通信模块可用于和车控设备100之间协商密钥，或者，将车辆200确定的密钥通知给车控设备100，或者，接收到车控设备100确定的密钥。通信模块与车控设备100之间的密钥协商过程，可参考后续方法实施例的详细描述。
在本申请实施例中，通信模块还用于执行和车控设备100之间基于密钥的通信。具体的，通信模块可用于将使用密钥加密的数据发送给车控设备100，也可以接收到车控设备100发送的使用密钥加密的数据。通信模块与车控设备100之间的通信过程，可参考后续方法实施例的详细描述。
显示屏用于为驾驶员提供可视化的界面。车辆200中可包括一个或多个显示屏，例如可包括设置于驾驶座前方的车载显示屏，设置于座椅上方的用于显示周边情况的显示屏，还可包括将信息投射到风窗玻璃上的抬头数字显示仪(head up display，HUD)等等。后续实施例提供的车辆200中用于显示用户界面的显示屏，可以是设置于座椅旁的车载显示屏，也可以是设置于座椅上方的显示屏，也可以是HUD等等，这里不做限定。车辆200中显示屏上显示的用户界面，具体可参考后续实施例的详细描述，在此暂不赘述。
T-box14也可以被称为车机系统、远程信息处理器、车辆网关等等，本申请实施例对此不作限制。
变速器ECU123用于管理变速器。
变速器15可以用来改变发动机的转速和转矩的机构，它能固定或分档改变输出轴和输入轴传动比。变速器15组成部分可以包含变速传动机构、操纵机构以及动力输出机构等。变速传动机构的主要作用是改变转矩和转速的数值和方向；操纵机构的主要作用是控制传动机构，实现变速器传动比的变换，即实现换档，以达到变速变矩。
行车记录仪ECU124用于管理行车记录仪16。
行车记录仪16组成部分可以包括主机、车速传感器、数据分析软件等。行车记录仪16是指记录车辆行驶途中的影像及声音包括行车时间、速度、所在位置等相关资讯的仪器。在本申请实施例中，当车辆行驶时，车速传感器采集到车轮转速，并将车速信息通过CAN总线发送给行车记录仪16。
ABS ECU125用于管理ABS17。
ABS17是在车辆制动时，自动控制制动器制动力的大小，使车轮不被抱死，处于边滚边滑的状态，以保证车轮与地面的附着力为最大值。在制动过程中，电子控制装置根据车轮转速传感器输入的车轮转速信号判定有车轮趋于抱死时，ABS就进入防抱死制动压力调节过程。
传感器系统18可包括：加速度传感器、车速传感器、震动传感器、陀螺仪传感器、雷达传感器，信号发射器，信号接收器等等。加速度传感器及车速传感器用于检测车辆200的速度。震动传感器可以设置在座位下方、安全带、椅背、操作面板、气囊或其他位置，用于检测车辆200是否被碰撞以及用户所在位置。陀螺仪传感器可以用于确定车辆200的运动姿态。雷达传感器可包括激光雷达、超声波雷达、毫米波雷达等。雷达传感器、信号发射器和信号接收器可用于检测用户所在位置。
摄像系统19可包括多个摄像头，摄像头用于捕获静态图像或视频。摄像系统19中的摄像头可以设置在车前、车后、侧边、车内等位置，便于实现辅助驾驶、行车记录、全景环视、车内监控等功能。
传感器系统18、摄像系统19可用于检测周边环境，便于车辆200做出相应的决策来应对环境变化，例如可用于自动驾驶阶段完成对周边环境进行关注的任务。
麦克风20，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或输出语音指令时，用户可以通过人嘴靠近麦克风20发声，将声音信号输入到麦克风20。车辆200可以设置至少一个麦克风20。在另一些实施例中，车辆200可以设置两个麦克风20，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，车辆200还可以设置三个，四个或更多麦克风20，形成麦克风阵列，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。
此外，车辆200还可以包括多个接口，例如USB接口，RS-232接口、RS485接口等等，可外接摄像头、麦克风、耳机以及用户侧的车控设备100。
可以理解的是，本申请实施例示意的结构并不构成对车辆系统的具体限定。车辆200可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
例如，车辆200还可包括单独的存储器、电池、车灯、雨刷、仪表盘、音响、车载终端(transmission control unit，TCU)、辅助控制单元(auxiliary control unit，ACU)、智能进入及启动系统(passive entry passive start，PEPS)、车载单元(on board unit，OBU)、车身控制模块(body control module，BCM)、充电接口等等。在一些实施例中，存储器用于关联存储车辆200和其他车控设备基于密钥的绑定关系，例如可关联存储车控设备100、车辆200各自的标 识，以及绑定的密钥。在本申请另一些实施方式中，存储器用于关联存储车辆200和其他车控设备基于账号和密钥的绑定关系，例如可关联存储车控设备100、车辆200各自的标识，各自绑定的账号，以及绑定的密钥。
车辆200各个部件的具体作用也可参考后续方法实施例的介绍，这里不赘述。
车辆200配置的软件操作系统(operating system，OS)可包括但不限于 Windows嵌入式紧凑型(Windows Embedded Compact，WinCE)操作系统等。
参考图3B，图3B为本申请实施例提供的车辆200的软件结构。
如图3B所示，车辆200可包括：绑定功能模块、近端交互模块、对外网络交互模块、密码算法模块、车控数据处理模块。其中：
绑定功能模块，用于提供车辆200和车控设备100建立绑定关系时，该车辆200所涉及的一系列用户界面。该用户界面可参考后续实施例的详细描述。
近端交互模块，用于和车控设备100执行近距离通信。具体的，近端交互模块可支持车辆200通过蓝牙、Wi-Fi、NFC等技术和其他设备通信。
对外网络交互模块，用于和车控设备100执行远程通信，还可用于和服务器300进行通信。具体的，近端交互模块可支持车辆200通过蜂窝网络、WAN、LAN等技术和其他设备通信。
密码算法模块，用于计算车辆200和车控设备100协商密钥过程中所涉及到的一系列数学因子。
车控数据处理模块，用于使用密钥加密车辆200将要发送给车控设备100的数据，还用于使用密钥解密车控设备100发送过来的加密的数据。
上述图3B示出的车辆200的软件结构仅为示例，并不构成对车辆200的具体限定。在本申请另一些实施例中，该车辆200可以包括比图示更多或更少的单元，或者组合某些单元，或者拆分某些单元，或者不同的单元布置。例如，车辆200的软件架构中还可以包括车辆管理应用，该车辆管理应用支持车辆200登录到服务器300以获取服务器300提供的各项服务等等。
基于上述图1所示的通信系统10、图2A-图2C所示的车控设备100、图3A-图3B所示的车辆200，下面介绍本申请实施例提供的一系列用户界面。
这些用户界面的应用前提是：车控设备100和车辆200登录相同账号后通过蓝牙协商密钥，即，车控设备100和车辆200通过蓝牙建立基于账号和密钥的安全绑定关系。在介绍下面的一系列用户界面过程中，提及的安全绑定车控设备和车辆是指，建立车控设备和车辆之间基于账号和密钥的安全绑定关系，也是指在登录了相同账号的车控设备和车辆之间建立点对点的安全通道。
图4A-图4Z以及图4-1，为本申请实施例提供的在车辆200上实现的一组用户界面。
图4A示例性示出了车辆200登录到服务器300后显示的一个用户界面41。
用户界面41可以由车辆200中的车辆管理应用提供。用户界面41可以由车辆200接收到作用于主界面中的车辆管理应用图标上的用户操作，或者，接收到作用于主界面中用户头像上的用户操作，或者接收到其他用户操作后，而显示。
用户界面41中显示有：顶部状态栏401、登录头像402、登录账号403、用于切换账号 的控件404、用于退出登录的控件405、用于启动人脸识别的控件406、用于设置车辆200安全绑定的车控设备的控件407、用户本地数据管理信息408，以及，底部任务栏409。
顶部状态栏401可包括：车辆200当前登录到服务器300所使用账号对应的头像、消息通知符、天气指示符、时间指示符、电池状态指示符、蓝牙指示符、Wi-Fi信号的一个或多个信号强度指示符、移动通信信号(又可称为蜂窝信号)的一个或多个信号强度指示符等等。
登录头像402为车辆200当前登录到服务器300所使用账号对应的头像。图4A中的登录头像402上还显示有提示信息，表明当前登录账号为车主账号。
用户本地数据管理信息408，用于展示车辆200的本地用户数据，例如历史登录过的账号信息等，还可以用于提供入口以供用户删除部分或全部的本地用户数据。
底部任务栏409可包括：用于进入主界面的控件、多任务键、座椅调节控件、空调温度调节控件、音量调节控件等等。
控件407用于监听用户操作(如触摸操作、点击操作等)，车辆200可响应于该用户操作，显示用于展示车辆200当前所安全绑定的车控设备的信息的用户界面42。在一些实施方式中，车辆200在显示图4A所示的用户界面41时，还可以在控件407下方显示当前车辆200已经安全绑定的车控设备的数量。
图4B-图4D示出了展示车辆200当前所安全绑定的车控设备的信息的用户界面42的几种实现方式。
如果车辆200当前安全绑定的车控设备数量已经达到上限，则响应作用于图4A中控件407上的用户操作，车辆200可以显示图4B。车辆200可以安全绑定的车控设备上限值可以预先设置，例如可以在车辆出厂前默认置于车辆200中。图4B显示有窗口410，窗口410用于显示车辆200已安全绑定的车控设备列表，具体包括：提示信息410a、提示信息410b、多个当前安全绑定的车控设备信息410c以及对应的解绑控件410d。用户可以在窗口410内输入从下往上的滑动操作，以查看更多的车控设备信息。提示信息410a用于提示用户和车辆200安全绑定的车控设备所能够执行的操作，例如能够执行远程控制车锁、车窗、后备箱等功能。提示信息410b用于提示用户当前车辆200安全绑定的车控设备数量已经达到上限。车控设备信息410c可以是车辆200安全绑定的车控设备的标识，如图中的“小斌的Mate40Pro”“LiBin的Mate40Pro”“LiBin的P50”等。解绑控件410d可用于触发对应的车控设备和车辆200解绑。解绑是指解除对应车控设备和车辆200之间的安全绑定关系。
如果车辆200当前安全绑定的车控设备数量未达到上限，则响应作用于图4A中控件407上的用户操作，车辆200可以显示图4C。图4C和图4B的不同之处是，由于当前车辆200安全绑定的车控设备数量还未达到上限，车辆200可以显示用于安全绑定更多车控设备的控件410e和控件410f。其中，控件410e和控件410f可用于触发车辆200通过不同的方式来安全绑定不同类型的车控设备，例如控件410e可用于触发车辆200安全绑定手机，控件410f可用于触发车辆安全绑定手表。在其他一些实施方式中，车辆200也可以使用相同的方式安全绑定各类车控设备，这样车辆200仅显示一个用于安全绑定车控设备的控件即可，或者，车辆也可以显示更多的用于通过不同方式安全绑定不同类型车控设备的控件。
如果车辆200当前还未安全绑定车控设备，则响应作用于图4A中控件407上的用户操作，车辆200可以显示图4D。图4D和图4B、图4C的不同之处是，由于当前车辆200还未安全绑定车控设备，车辆200并未显示车辆安全绑定的车控设备的信息。
之后，车辆200可以检测到作用于图4C或图4D中的控件410e或控件410f的用户操作(如触摸操作、点击操作等)，响应于该用户操作，如果当前车辆200还未做好安全绑定车控 设备的准备工作如还未启动蓝牙，则显示图4E所示的用户界面43以提示用户；如果当前车辆200已做好安全绑定车控设备的准备工作如已经启动蓝牙，则显示图4F所示的用户界面44以加载安全绑定车控设备所需的信息。在一些实施方式中，车辆200检测到作用于图4C或图4D中的控件410e或控件410f的用户操作后，可以先执行验证用户身份信息的操作，然后再显示图4E或图4F所示的用户界面。验证用户身份的方式例如可包括人脸认证、扫码认证、数字密码认证、指纹认证等等，验证的目的是为了确定当前用户和当前登录账号对应的用户一致。
图4E示例性示出了车辆200提示用户做好安全绑定车控设备之前的准备工作的一种方式。图4E所示的用户界面43中显示有窗口411，窗口411包括：用于启动蓝牙的控件411a、提示信息411b、提示信息411c。其中，控件411a用于监听用户操作，车辆200可响应于该用户操作而启动蓝牙。提示信息411b可用于提示用户需要先开启车辆200的蓝牙，才能继续后续安全绑定车控设备的操作。提示信息411c用于提示用户车辆200在安全绑定车控设备时，该车控设备应该做好何种准备，例如该车控设备应该开启蓝牙，并且与当前车辆200登录相同的账号。
车辆200检测到作用于图4E中控件411a的操作后，可以启动蓝牙，并且显示如图4F所示的用户界面44。用户界面44中显示有窗口412，窗口412包括：标题412a，提示信息412b，加载提示412c、控件412d。标题412a指示当前窗口412用于显示车辆200和车控设备协商密钥所需的内容，例如可以为文本“安全密钥”。提示信息412b用于提示用户在车控设备上应该如何操作才能完成安全绑定，如果不同类别的车控设备对应有不同的操作，则提示信息412b也可以有不同的实现形式。图4F中的提示信息412b用于提示用户需要在车控设备上打开车辆管理应用(例如图中的AITO应用)扫码，并且保持车控设备的蓝牙开启。加载提示412c用于指示车辆200当前正在加载车辆200和车控设备安全绑定所需的信息，该信息例如可以实现为二维码、条形码、数字密码、或其他形式。车辆200和车控设备安全绑定所需的信息的具体内容，可参考后续方法实施例的详细描述。控件412d可用于监听用户操作，车辆200可响应于该用户操作，停止显示窗口412，中断安全绑定车控设备的操作。
在一些实施方式中，如果车辆200加载和车控设备协商密钥所需信息的速度很快，则车辆200可以不用显示图4F所示的用户界面，可以直接在窗口412中显示已加载内容，如后续图4G或图4H的用户界面所示。
车辆200加载好和车控设备安全绑定所需的信息之后，可以显示图4G所示的用户界面44，或，图4I所示的用户界面44。
图4G示例性示出了用于车辆200和手机类型的车控设备安全绑定所需的信息。图4G所示的用户界面可以是车辆检测到作用于图4C或图4D中的控件410e后所显示的界面。由于手机类型的车控设备通常配置有摄像头，因此车辆200可以显示图4G中的二维码413，以方便手机类型的车控设备通过扫码的方式来获取上述安全绑定所需的信息，进而和车辆200协商密钥。
图4I示例性示出了用于车辆200和手表类型的车控设备安全绑定所需的信息。图4I所示的用户界面可以是车辆检测到作用于图4C或图4D中的控件410f后所显示的界面。车辆200可以显示图4I中的数字密码414，以方便手表类型的车控设备通过输入数字密码的方式来获取上述安全绑定所需的信息，进而和车辆200协商密钥。
在一些实施方式中，为了保证密钥协商过程的安全性，图4G示出的二维码413或图4I示出的数字密码414都可以有一定的时效性，在显示超过预设时长后失效。在失效后，车辆 200可以主动刷新该二维码或数字密码并将刷新后的信息显示在显示屏上，或者，车辆200也可以提示用户当前二维码或数字密码已失效并提示用户刷新唉二维码或数字密码，例如图4H或图4J所示。
不限于图4G、图4I示出的车辆200显示不同类别的信息(如二维码和数字密码)以安全绑定不同类别的车控设备，在其他一些实施方式中，车辆200也可以在安全绑定不同类别的车控设备时，都显示相同类别的信息，如可以都显示数字密码等，或者，车辆200显示的信息类别也可以随用户操作切换。
在车辆200显示图4G或图4I所示的和车控设备安全绑定所需的信息，并且车控设备按照相应的指示执行对应操作，例如车控设备扫描二维码或接收到输入的数字密码后，车辆200和该车控设备之间可以交互一些信息，例如可以将自身的设备标识、当前登录到服务器300所使用的账号发送给对端设备。
车辆200接收到车控设备的账号后，可以和当前自身登录到服务器300所使用的账号进行比对，如果两者不同，则可以输入提示信息以提示用户车辆200只能安全绑定和其登录相同账号的车控设备。如果两者相同，则仅需执行后续的安全绑定流程，并可以显示图4K所示的提示信息415，以提示用户当前车辆200正在执行安全绑定对应车控设备的操作。安全绑定流程的具体实现可参考后续方法实施例的详细描述。
在一些实施方式中，车辆200只能在保持显示图4K所示的用户界面的过程中，执行和车控设备安全绑定的操作，如果车辆200退出显示图4K所示的用户界面，则会中断安全绑定车控设备的流程。
示例性地，图4L示出了车辆200接收到退出显示图4K所示用户界面的用户操作后所显示的弹窗416。例如，如果车辆200在图4K所示的用户界面上，接收到作用于底部任务栏中用于进入主界面的控件上的用户操作，或者接收到系统返回手势等，则可以显示弹窗416。弹窗416用于提示用户车辆200和车控设备的安全绑定流程只能在显示图4K所示的用户界面同时进行，如果退出显示该用户界面，则会中断安全绑定流程。
在另一些实施方式中，车辆200可以不用保持显示图4K所示的用户界面，车辆200可以显示其他用户界面，也可以运行其他应用，只要在后台执行和车辆设备安全绑定的操作即可。
图4M-图4S，示例性示出了车辆200和车控设备执行安全绑定操作后，车辆200所显示的安全绑定结果。
图4M和图4N为车辆200和车控设备安全绑定超时后，车辆200所显示的用户界面。图4M为车辆200在后台执行安全绑定车控设备操作，并且在安全绑定超时后所显示的用户界面，该用户界面可以为车辆200的主界面，该用户界面显示有用于提示用户安全绑定超时的提示信息。图4N为车辆200在前台执行安全绑定车控设备操作，并且在安全绑定超时后所显示的用户界面，该用户界面显示有用于提示用户安全绑定超时的提示信息，以及用于触发车辆200和车控设备重新安全绑定的控件417。车辆200监听到作用于控件417上的用户操作后，可以和对应的车控设备基于以交互的信息再次执行后续的安全绑定操作。
安全绑定超时可以是指车辆200和对应车控设备通过上述扫码或数字密码等方式交换信息后，在预设时长内未能执行完安全绑定流程。该预设时长例如可以是2秒、5秒、10秒等。
图4O和图4P为车辆200和车控设备安全绑定失败后，车辆200所显示的用户界面。图4O为车辆200在后台执行安全绑定车控设备操作，并且在安全绑定失败后所显示的用户界面，该用户界面可以为车辆200的主界面，该用户界面显示有用于提示用户安全绑定失败的提示 信息。图4P为车辆200在前台执行安全绑定车控设备操作，并且在安全绑定失败后所显示的用户界面，该用户界面显示有用于提示用户安全绑定失败的提示信息，以及用于触发车辆200和车控设备重新安全绑定的控件418。车辆200监听到作用于控件418上的用户操作后，可以和对应的车控设备基于以交互的信息再次执行后续的安全绑定操作。
安全绑定失败可以是指车辆200和对应车控设备通过上述扫码或数字密码等方式交换信息后，未能成功执行安全绑定流程。安全绑定失败的原因例如可包括但不限于：车辆200和车控设备之间的连接通路异常、车控设备异常(如低电关机、拒绝安全绑定等)、车辆异常等。
图4Q-图4S为车辆200和车控设备成功安全绑定后，车辆200所显示的用户界面。
图4Q为车辆200在后台执行安全绑定车控设备操作，并且在成功安全绑定后所显示的用户界面，该用户界面可以为车辆200的主界面，该用户界面显示有用于提示用户成功安全绑定的提示信息。
图4R为车辆200在前台执行安全绑定手机类型的车控设备操作，并且在成功安全绑定后所显示的用户界面42。如图4R所示，车辆200成功安全绑定手机类型的车控设备后，将在窗口410中显示新增加的该车控设备对应的车控设备信息410c以及对应的解绑控件410d。例如，图4R中新增的车控设备信息410c上的文本指示了车辆200新安全绑定的车控设备的标识为“LiBin的P50”。车控设备信息410c旁边还可以显示有指示该车控设备为新安全绑定设备的提示信息，例如文本“new”。新增的车控设备信息410c以及对应的解绑控件410d可以排列在之前已安全绑定车控设备对应控件的前面。
图4S为车辆200在前台执行安全绑定手表类型的车控设备操作，并且在成功安全绑定后所显示的用户界面42。如图4S所示，车辆200成功安全绑定手表类型的车控设备后，将在窗口410中显示新增加的该车控设备对应的车控设备信息410c以及对应的解绑控件410d。例如，图4S中新增的车控设备信息410c上的文本指示了车辆200新安全绑定的车控设备的标识为“LiBin的Watch 7”。车控设备信息410c旁边还可以显示有指示该车控设备为新安全绑定设备的提示信息，例如文本“new”。新增的车控设备信息410c以及对应的解绑控件410d可以排列在之前已安全绑定车控设备对应控件的前面。
成功安全绑定可以是指车辆200和对应车控设备通过上述扫码或数字密码等方式交换信息后，在预设时长内成功执行安全绑定流程。该安全绑定流程具体可参考后续方法实施例的描述。车辆200和车控设备协商好密钥后即成功安全绑定，之后双方各自将该密钥、当前双方登录的相同账号，以及对端设备的设备标识关联存储，后续双方就可以使用该密钥来通信。
在一些实施方式中，用户还可以根据实际需求触发车辆200和部分车控设备解绑。解绑是指车辆200和车控设备均删除关联存储的密钥、当前双方登录的相同账号，以及对端设备的设备标识，解绑后双方不能够使用该密钥通信。
车辆200可以检测到作用于图4B、图4C、图4R或图4S所显示窗口410中标识为“小斌的Mate40 Pro”的车控设备对应的解绑控件410d上的用户操作，然后显示图4T所示的窗口419。窗口419包括提示信息419a、控件419b和控件419c。提示信息419a用于提示用户解绑后对应的车控设备将无法远程控制车辆200。控件419b用于监听用户操作，车辆200将响应于该用户操作不再执行解绑流程。控件419c用于监听用户操作，车辆200将响应于该用户操作执行解绑流程。
车辆200检测到作用于图4T的窗口419中控件419c上的用户操作后，如果当前时间距离上一次验证用户身份超过预设时长(例如5分钟)，则可以再次触发验证用户身份的流程。车辆200验证用户身份的方式可以随用户操作切换。图4U示出了车辆200触发人脸验证流 程时显示的用户界面，图4V示出了车辆200触发扫码验证流程时的用户界面。如果当前时间距离上一次验证用户身份在预设时长(例如5分钟)内，则可以无需再次验证用户身份，可以直接显示图4W所示的用户界面，以提示用户当前正在执行车辆200和对应车控设备的解绑操作。
在一些实施方式中，车辆200只能在保持显示图4W所示的用户界面的过程中，执行和车控设备解绑的操作，如果车辆200退出显示图4W所示的用户界面，则会中断解绑车控设备的流程。
示例性地，图4X示出了车辆200接收到退出显示图4W所示用户界面的用户操作后所显示的弹窗。例如，如果车辆200在图4W所示的用户界面上，接收到作用于底部任务栏中用于进入主界面的控件上的用户操作，或者接收到系统返回手势等，则可以显示图4X中的弹窗。该弹窗用于提示用户车辆200和车控设备的解绑流程只能在显示图4W所示的用户界面同时进行，如果退出显示该用户界面，则会中断解绑流程。
在另一些实施方式中，车辆200可以不用保持显示图4W所示的用户界面，车辆200可以显示其他用户界面，也可以运行其他应用，只要在后台执行和车辆设备解绑的操作即可。
图4Y—图4Z，以及图4-1示例性示出了车辆200和车控设备执行解绑操作后，车辆200所显示的解绑结果。
图4Y为车辆200在前台执行解绑车控设备操作，并且在解绑超时后所显示的用户界面，该用户界面显示有用于提示用户解绑超时的提示信息，以及用于触发车辆200和车控设备重新解绑的控件。
解绑超时可以是指车辆200和对应车控设备在预设时长内未能执行完解绑流程。该预设时长例如可以是2秒、5秒、10秒等。
图4Z为车辆200在前台执行解绑车控设备操作，并且在解绑失败后所显示的用户界面，该用户界面显示有用于提示用户解绑失败的提示信息，以及用于触发车辆200和车控设备重新解绑的控件。
解绑失败可以是指车辆200和对应车控设备未能成功执行解绑流程。解绑失败的原因例如可包括但不限于：车辆200和车控设备之间的连接通路异常、车控设备异常(如低电关机、拒绝安全绑定等)、车辆异常等。
图4-1为车辆200在前台执行和车控设备解绑的操作，并且和车控设备成功解绑后，车辆200所显示的用户界面。相比于图4B、图4C、图4R或图4S，如图4-1所示，在成功解绑设备之后，标识为“小斌的Mate40 Pro”的车控设备和车辆200解绑，其设备标识不再显示在用户界面中。
图5A-图5N，为本申请实施例提供的在手表类型的车控设备100上实现的一组用户界面。图5A-图5N示出了车控设备100和车辆200通过近距离通信技术安全绑定的一种方式。
图5A示例性示出了车控设备100登录到服务器300后显示的一个用户界面51。
用户界面51可以由车控设备100中的车辆管理应用提供，用于展示某个车辆的车辆信息。如图5A所示，用户界面51中显示有车控设备100绑定的车辆的信息，如行驶里程、电量、油量、当前状态等等。这里车控设备100仅仅绑定了车辆，但是并未和该车辆做安全绑定，因此车控设备100仅能查看车辆的信息，但是不能控制该车辆。
之后，车控设备100可以检测到作用于用户界面51的、用于显示车辆控制界面的用户操作(例如向上滑动操作、下下滑动操作等)，由于当前车控设备100并未和对应的车辆做安全 绑定，为了保障信息安全，车控设备100可以先提示用户执行和对应车辆的安全绑定流程。
图5B示出了车控设备100检测到作用于用户界面51的用户操作后所显示的用户界面52。用户界面52示出了车控设备100提示用户做好安全绑定对应车辆之前的准备工作的一种方式。用户界面52中显示有窗口：提示信息501a、控件501b和控件501c。
其中，提示信息501a用于提示用户车控设备100在安全绑定车辆时，各设备应该做好何种准备，例如该车控设备100和对应车辆都应该开启蓝牙并且登录相同账号，手表类型的车控设备100的管理设备(例如手机)将该车辆设置为默认车辆。设置默认车辆后，车控设备100接收到的车控操作均是针对该默认车辆来执行。控件501b用于监听用户操作，如果当前车控设备100已做好安全绑定的准备工作(例如已打开蓝牙)，则车控设备100可以响应于在控件501b上的用户操作，接收附近其他设备(例如车辆)发送的蓝牙广播，搜索附近是否有可绑定的蓝牙设备。如果当前车控设备100未做好安全绑定的准备工作(例如未打开蓝牙)，车控设备100可响应于在控件501b上的用户操作，显示图5C所示的提示信息502及控件503。提示信息502用于提示用户开启蓝牙，控件503用于接收用户操作，车控设备100可响应于该用户操作而启动蓝牙。
如果车控设备100搜索到用户界面51所示信息对应的车辆，则可以直接执行和该车辆之间的安全绑定流程。
如果车控设备100仅搜索到一个可绑定的蓝牙设备，则可以直接执行和该设备之间的安全绑定流程，并且显示图5D中的连接提示504，连接提示504可用于提示用户当前车控设备100正在和搜索到的蓝牙设备建立蓝牙连接。
如果车控设备100搜索到多个可绑定的蓝牙设备，车控设备100可以显示搜索到的设备列表，如图5E所示。图5E所示的用户界面中显示有车控设备100搜索到的一个或多个设备的设备标识505，例如图5E说明当前车控设备搜索到了标识为“问界F1”的车辆和标识为“问界M5”的车辆。之后，车控设备100可以检测到作用于搜索到的设备标识505上的用户操作，然后和该设备标识505对应的设备执行安全绑定流程。该安全绑定流程的具体实现可参考后续方法实施例的详细描述。
车控设备100开始执行和某个车辆的安全绑定流程后，可以先确认以下几项：车控设备100和该车辆成功建立蓝牙连接、车控设备100发现该车辆、该车辆侧未中断安全绑定流程、车控设备100和该车辆登录了相同账号、车控设备100的管理设备(例如手机)将该车辆设置为默认车辆。如果当前情况不符合上述几项，则车控设备100可以中断安全绑定流程，并可以根据实际情况显示图5F所示的其中一个用户界面，用于提示用户当前中断安全绑定流程的原因。如果当前情况符合上述几项，则车控设备100可以执行后续的安全绑定流程，例如可以显示图5G所示的用户界面。
图5G示出了车控设备100提供的用于获取和车辆安全绑定所需信息的一个界面。图5G所示的用户界面中可显示有提示信息以及数字按键，该提示信息用于提示用户输入数字密码。之后，如图5H所示，车控设备100可以接收到用户输入的数字密码。如果用户输入的数字密码和车辆侧显示的数字密码不一致或已过期，则车控设备100将无法获取该数字密码携带的信息，也就无法继续执行后续的安全绑定流程。在这种情况下，车控设备100可以显示图5I所示的用户界面，以提示用户重新输入数字密码。如果用户输入的数字密码和车辆侧显示的数字密码一致或在有效期内，例如用户输入图4I中的数字密码414，则车控设备100可以利用该数字密码携带的信息和车辆执行后续的安全绑定流程，并可以显示图5J所示的提示信息，以提示用户当前车控设备100正在执行安全绑定对应车辆的操作。
图5K-图5N，示例性示出了车控设备100和车辆执行安全绑定操作后，车控设备100所显示的安全绑定结果。
图5K为车控设备100和车辆安全绑定失败后，车控设备100所显示的用户界面。
图5L为车控设备100和车辆由于尝试绑定的次数过多而导致安全绑定失败后，车控设备100所显示的用户界面。
图5M为车控设备100和车辆由于双方之间的蓝牙连接断开而导致安全绑定失败后，车控设备100所显示的用户界面。
图5N为车控设备100和车辆成功安全绑定后，车控设备100所显示的用户界面。图5N所示的用户界面为车辆控制界面。如图5N所示，该用户界面显示有：多个控制选项506-509，分别用于控制车锁、控制车窗、寻车、控制空调。车控设备100可以监听到作用于控制选项506-509中任一项上的用户操作，并响应该用户操作执行对应的步骤，例如向车辆发送控制车锁的指令、发送控制车窗的指令、发送用于查询车辆位置的指令、发送控制空调的指令等等。
图5N所示的用户界面也可以被称为第一用户界面。
在手表类别的车控设备100上也可以触发解绑流程，例如车控设备100可以在图5A所示的用户界面中设置用于解绑的控件，以供用户点击并触发解绑流程。
图6A-图6J，为本申请实施例提供的在手机类型的车控设备100上实现的一组用户界面。图6A-图6J示出了车控设备100和车辆200通过远距离通信技术安全绑定的一种方式。
图6A示例性示出了车控设备100登录到服务器300后显示的一个用户界面61。
用户界面61可以由车控设备100中的车辆管理应用提供，用于展示该车控设备100安全绑定的车辆列表。如图6A所示，用户界面61中显示有：车控设备100所安全绑定的车辆的车辆信息，如车辆图标、型号、车牌号、车架号等等。用户界面61中还显示有用于安全绑定新车辆的控件601。控件601可用于监听用户操作(如触摸操作、点击操作等)，车控设备100可响应于该用户操作，执行手机号码的认证流程。在一些实施方式中，车控设备100可以先验证用户的手机号码，查验该手机号码下是否有登记的购车记录。服务器300中可以存储有各个车辆的购买记录，包括各个车辆的信息(如车辆标识、车辆图片、型号、车架号、车牌号等)及对应的购买手机号码。
图6B-图6E示出了车控设备100验证手机号码是否有购车记录的一系列用户界面。
如图6B所示，车控设备100检测到作用于图6A中控件601上的用户操作后，可以显示多个手机号码选项602，用于添加手机号码的控件603，以及控件604。手机号码选项602可以对应于车控设备100历史添加过的手机号码。
如果用户选择了某个手机号码选项602，即车控设备100监听到作用于手机号码选项602的用户操作后检测到作用于控件604的用户操作后，该车控设备100可以向服务器300发送携带该手机号码选项602对应手机号码的验证请求。
如果用户选择添加新的手机号码，即车控设备100监听到作用于控件603的用户操作后，该车控设备100可以显示图6C所示的用户界面，以供用户输入新的手机号码。之后，车控设备100可以监听到用户点击下一步控件的用户操作，向服务器300发送携带用户添加的该新的手机号码的验证请求。
服务器300接收到携带手机号码的验证请求后，可以向该手机号码所在的设备(例如可以是车控设备100)发送验证码。这一步骤是为了校验该手机号码所在的设备当前位于用户附近，该设备是安全及可信的。
车控设备100向服务器300发送验证请求之后，显示如图6D所示的用户界面。之后，如图6E所示，车控设备100可以接收到用户输入的验证码，并向服务器300发送携带该验证码的消息。
服务器300接收到车控设备100发送的验证码后，和之前发送给该车控设备100的验证码进行比对，若一致，则确认该手机号码所在的设备当前位于用户附近，该设备是安全及可信的。之后，服务器300可以查询该手机号码下是否有购车记录，并将查询结果发送给车控设备100。
如果服务器300查询到该手机号码下并无购车记录，车控设备100可以显示图6F所示的用户界面，以提示用户当前手机号码下并无购车记录。
如果服务器300查询到该手机号码下存在购车记录，则可以将该手机号码下购买的车辆信息发送给车控设备100。车控设备100接收到该车辆信息后，可以显示该手机号码下购买的各个车辆的选项。如图6G所示，车控设备100显示有车辆选项605和606，以及控件607、控件608，车辆选项605表示该手机号码下购买有一辆型号为“Car X1华为智选”，车架号后六位为“018233”的车辆，车辆选项606表示该手机号码下购买有一辆型号为“Car X1自由元征版”，车架号后六位为“028233”的车辆。
之后，车控设备100可以检测到作用于一个或多个车辆选项上的用户操作后，作用到控件608上的用户操作，然后和该车辆选项对应的车辆执行安全绑定流程。该安全绑定流程的具体实现可参考后续方法实施例的详细描述。车控设备100和对应车辆执行安全绑定流程的过程中，还可以显示图6H所示的用户界面，以提示用户当前正在安全绑定车辆。
图6I示例性示出了车控设备100成功安全绑定车辆后所显示的用户界面。如图6I所示，车控设备100安全绑定车辆后，可以在用户界面61的车辆列表中该新安全绑定车辆的车辆信息。
车控设备100成功安全绑定车辆后，该车控设备100就可以使用协商的密钥和该车辆通信，以实现对该车辆的远程控制、车辆状态的远程查询、车辆故障远程诊断等功能。这里的安全绑定是指车控设备100成功安全绑定车辆后，响应于检测到的在图6I所示的车辆信息上的用户操作，可以显示图6J所示的用于远程控制该车辆信息对应车辆的用户界面。如图6J所示，该用户界面中显示有多个控制选项609-612，分别用于控制车锁、控制车窗、寻车、控制空调。车控设备100可以监听到作用于控制选项609-612中任一项上的用户操作，并响应该用户操作执行对应的步骤，例如向车辆发送控制车锁的指令、发送控制车窗的指令、发送用于查询车辆位置的指令、发送控制空调的指令等等。
图6J所示的用户界面也可以被称为第一用户界面。
在手机类别的车控设备100上也可以触发解绑流程，例如车控设备100可以在图6A、图6I或图6J所示的用户界面中设置用于解绑的控件，以供用户点击并触发解绑流程。
从上述图5A-图5N，图6A-图6J示出的示例可知，在一些实施方式中，车控设备仅绑定了车辆但并未做安全绑定之前，车控设备可以查询车辆状态并显示车辆状态，但是不能控制车辆。只有在车控设备和车辆之间建立了安全绑定关系后，车控设备才可以控制车辆，这样可以保证车控设备通过密钥来控制车辆，以避免第三方篡改或伪造该车控设备发送给车辆的控制指令，从而保证车辆的安全。
在其他一些实施方式中，车控设备仅绑定了车辆但并未做安全绑定时，车控设备也可以控制车辆，此种情况下车控设备可以提示用户该控制方式的安全性一般。
在其他一些实施方式中，车控设备只有在和车辆建立安全绑定关系之后，才可以执行查询车辆状态、控制车辆、远程诊断车辆故障等和车辆通信的操作，这样可以保证车控设备通过密钥来和车辆通信，保证双方交互的数据只有车控设备和车辆能够获取到，避免数据泄露，从而双方设备的信息安全。
基于上述图1所示的通信系统10、图2A-图2C所示的车控设备100、图3A-图3B所示的车辆200，以及上述UI实施例，下面介绍本申请实施例提供的针对车辆的安全通信方法的实现流程。下面的该方法以车控设备100和车辆200之间的通信过程为例，该车控设备100可以为上述各实施例中提及的车控设备100，该车辆200可以为上述各实施例中提及的车辆200。
该针对车辆的安全通信方法可包括如下几个阶段：
阶段一，车控设备100和车辆200建立安全绑定关系。
本申请实施例中的安全绑定关系可包括两种，一种是基于密钥的安全绑定关系，另一种是基于账号和密钥的安全绑定关系。
建立基于密钥的安全绑定关系是指，车控设备和车辆协商密钥或者由一方确定密钥后通知另一方，然后车控设备和车辆各自关联存储对端设备的标识和该密钥。基于密钥的安全绑定关系的实现，可参考前文表1、表2及相关内容。该密钥仅用于该车控设备和该车辆之间的通信。建立该基于密钥的安全绑定关系，相当于在该车控设备和该车辆之间建立了点对点的安全通道，能够保证该车控设备和该车辆之间的通信安全。一个车控设备可以和多个车辆分别建立基于密钥的安全绑定关系，一个车辆也可以和多个车控设备分别建立基于密钥的安全绑定关系。
建立基于账号和密钥的安全绑定关系是指，车控设备和车辆各自使用账号登录到服务器300后，协商密钥或者由一方确定密钥后通知另一方，然后车控设备和车辆各自关联存储对端设备的标识、双方登录所使用的账号和该密钥。基于账号和密钥的安全绑定关系的实现，可参考前文表3、表4及相关内容。该密钥仅用于登录了对应账号的车控设备和登录了对应账号的车辆之间的通信。建立该基于账号和密钥的安全绑定关系，相当于在该登录了特定账号的车控设备和该登录了特定账号的车辆之间建立了点对点的安全通道，能够保证该登录了特定账号的车控设备和该登录了特定账号的车辆之间的通信安全。一个车控设备可以和一个或多个车辆建立基于账号和密钥的安全绑定关系，一个车辆也可以和一个或多个车控设备建立基于账号和密钥的安全绑定关系。一个车控设备或一个车辆，在不同时间点可以登录不同的账号。
在一些实施方式中，只有车控设备和车辆登录到服务器300所使用的账号相同，两者之间才能够建立基于账号和密钥的安全绑定关系。即，只有登录相同账号的车控设备和车辆之间才能安全绑定。
在另一些实施方式中，即使车控设备和车辆登录的账号不同，两者也可以建立基于账号和密钥的绑定关系。即，登录不同账号的车控设备和车辆之间也能安全绑定。例如，车控设备登录的账号和车辆登录的账号之间可以分别为主账号和子账号，或者相反。子账号可以是指被主账号授权的账号，例如主账号可以是车主的账号，子账号可以包括车主的家庭成员的账号，又例如主账号可以是租车公司的账号，子账号可以包括租车人的账号。主账号授权给子账号的形式可以包括多种，可以参考现有技术中的权限授予方案，这里不再展开说明。
车控设备100和车辆200建立安全绑定关系的方式有多种，下面列举几种可能的实现方 式。
图7示出了一种车控设备100和车辆200通过近距离通信技术协商密钥，以建立安全绑定关系的过程。本申请实施例提及的近距离通信技术可包括但不限于：蓝牙、NFC、Wi-Fi P2P、Wi-Fi热点等。
参考图7，车控设备100和车辆200通过近距离通信技术协商密钥的过程可包括如下步骤：
S101，车辆200生成绑定因子。
以下介绍几种车辆200生成绑定因子的场景：
场景1，车辆200接收到用户操作，响应于该用户操作生成绑定因子。
例如，车辆200接收到作用于图4C或图4D中的控件410e或控件410f上的用户操作，或者，车辆200接收到作用于图4E中的控件411a上的用户操作后，可以响应于该用户操作，生成绑定因子。
场景2，车辆200接收到车控设备100发送的消息后，响应于该用户操作生成绑定因子。
例如，车辆200可以发送携带自身标识的蓝牙广播，附近的车控设备100接收到该蓝牙广播后，可以在显示屏上显示该车辆200对应的车辆选项，若车控设备100接收到作用于该车辆选项的用户操作，则车控设备100可以和该车辆200建立蓝牙连接，然后向该车辆200发送蓝牙消息，以触发车辆200生成绑定因子。示例性地，如图5E所示，车控设备100显示有多个车辆选项，其中包括车辆200的车辆选项，在接收到作用于车辆200的车辆选项对应的用户操作后，车控设备100向车辆200发送蓝牙消息。在其他一些实施方式中，如果车控设备100搜索到的蓝牙设备仅有车辆200，则可以无需用户输入用户操作，车控设备100可以直接向该车辆200发送蓝牙消息。
在本申请实施例中，绑定因子可以是一个或一组随机数。车辆200可以使用预置的随机数生成算法生成该绑定因子。
S101可以由车辆200中的绑定功能模块执行。
S102，车控设备100获取车辆200生成的绑定因子。
以下介绍几种车控设备100获取绑定因子的方式：
方式1，车辆200生成绑定因子后，将绑定因子转换为二维码、数字密码(如个人识别码(Personal Identification Number，PIN))、条形码等形式，并将转换后的内容显示在显示屏上，之后，车控设备100通过扫描二维码、条形码或者接收输入的数字密码的方式获取该绑定因子。示例性地，图4G示出了车辆200显示的携带绑定因子的二维码，图4I示出了车辆200显示的携带绑定因子的数字密码，图5G及图5H示出了车控设备100接收输入的数字密码的用户界面。
方式2，车辆200生成绑定因子后，通过蓝牙、NFC、Wi-Fi等近距离通信技术将该绑定因子发送给车辆200。
S102可以由车控设备100和车辆200中的近端交互模块配合执行。
S103，车控设备100和车辆200各自根据绑定因子生成共享密钥(prekey)。
车控设备100和车辆200中预置有相同的算法和参数，车控设备100和车辆200使用该相同的算法和参数生成相同的共享密钥prekey。本申请实施例对该算法不做限制。共享密钥prekey可以是一个随机数或一组随机数。共享密钥prekey的长度、复杂度可以高于绑定因子的长度、复杂度。
S103可以由车控设备100和车辆200中的密码算法模块执行。
S104，车控设备100和车辆200通过近距离通信技术，使用共享密钥prekey协商绑定密钥bindkey。
车控设备100和车辆200可以使用近距离通信技术(例如蓝牙、NFC、Wi-Fi通信技术)，以及椭圆曲线迪菲-赫尔曼秘钥交换(elliptic curve diffie–hellman key exchange，ECDH)算法来协商绑定密钥bind key。
S104具体可以包括以下几个步骤：
S1041，车控设备100和车辆200各自生成椭圆曲线密钥对。
车控设备100和车辆200可以预置有相同的椭圆曲线参数，各自使用该椭圆曲线参数生成不同的椭圆曲线密钥对。椭圆曲线密钥对中包括一个公钥和一个私钥。车控设备100生成的椭圆曲线密钥对可以包括：私钥a，公钥a*G。车辆200生成的椭圆曲线密钥对可以包括：私钥b，公钥b*G。
S1042，车控设备100和车辆200使用共享密钥pre key加密各自的公钥后发送给对端设备。
车控设备100使用共享密钥pre key对自己计算得到的公钥进行加密，将加密后的数据通过蓝牙、NFC、Wi-Fi等近距离通信技术发送给车辆200。同时，车辆200也使用共享密钥pre key对自己计算得到的公钥进行加密，将加密后的数据通过蓝牙、NFC、Wi-Fi等近距离通信技术发送给车控设备100。
由于共享密钥pre key只有车控设备100和车辆200双方知晓，通过S1042可以保证双方设备交换的公钥不被泄露，让双方设备安全地获知对端设备的公钥。
S1043，车控设备100和车辆200各自使用对端的公钥和自己的私钥，计算得到绑定密钥bind key。
车控设备100使用共享密钥pre key解密获得车辆200的公钥b*G，然后使用ECDH算法，结合自己的私钥a，计算得到绑定密钥bindkey。例如，车控设备100计算得到的绑定密钥bindkey为a*b*G。
同样的，车辆200使用共享密钥pre key解密获得车控设备100的公钥a*G，然后使用ECDH算法，结合自己的私钥b，计算得到绑定密钥bindkey。例如，车辆200计算得到的绑定密钥bindkey为b*a*G。可见，车辆200和车控设备100计算出的绑定密钥bindkey的值一致。
通过S1042可以让车控设备100和车辆200安全地获知对端设备的公钥，再结合只有本端设备获知的私钥，该车控设备100和车辆200就能够得到只有双方知晓的、安全的绑定密钥bindkey。该绑定密钥可以在后续车控设备100和车辆200的通信过程中作为对称密钥使用。
通过S1041-S1043示出的通过ECDH算法来协商绑定密钥bindkey，可以获得长度、复杂度足够大的，且只有车控设备100和车辆200知晓的绑定密钥bindkey。这样可以保障后续车控设备100和车辆200的通信安全。
S104可以由车控设备100和车辆200的密码算法模块配合执行。
上述S101-S104的目的是为了让车控设备100和车辆200能够协商出只有双方知晓的密钥，在本申请一些实施方式中，还可以使用其他技术手段来实现该目的。例如，可以针对上述S101-S102所使用的技术手段稍微变形，得到以下几种方案：
方案1，车控设备100和车辆200获取到绑定因子后，直接将该绑定因子当作共享密钥pre key使用，这样就无需执行上述S1042，可以减少双方的操作。
方案2，车控设备100和车辆200直接执行S104，并且在S1042中直接交互公钥，无需 使用共享密钥pre key来加密公钥后再交互。这样即使交互的公钥可能被第三方获取，但通过S1043的算法计算得到的绑定密钥bindkey也只有车控设备100和车辆200能够知晓，保证了绑定密钥bindkey的安全性。
方案3，车辆200生成的绑定因子直接作为绑定密钥bindkey使用，这样就无需执行上述S103-S104，可以减少双方操作。
方案4，车辆200可以接收用户直接输入的绑定密钥bindkey，然后车控设备100通过上述S102中类似的方法从车辆200处获取该绑定密钥bindkey。
方案5，上述S101-S104所示的方案，上述方案1-方案4，车控设备100和车辆200的角色以及执行的操作可以交换。
S105，车控设备100和车辆200通过近距离通信技术交换设备信息。
车控设备100和车辆200可以使用近距离通信技术(例如蓝牙、NFC、Wi-Fi通信技术)来交换设备信息。S105可以由车控设备100和车辆200的近端交互模块配合执行。
设备信息可包括设备标识。车控设备100的设备标识可以是设备序列号、MAC地址、IP地址等。车辆200的设备标识可以是车架号、车牌号等。车控设备100可以将自身的设备标识发送给车辆200，同样的，车辆200也可以将自身的设备标识发送给车控设备100。
在一些实施方式中，如果前述的S101-S104过程中，车控设备100和车辆200建立了通信连接(例如蓝牙通信连接、Wi-Fi通信连接)，则车控设备100和车辆200在前述过程中就已经交换过设备标识，此时不必再重复交换设备标识。当然，在其他一些实施方式中，即使车控设备100和车辆200在前述过程中就已经交换过设备标识，双方也可以在协商绑定密钥bindkey后再次交换设备标识。
如果车控设备100和车辆200之间建立的是基于账号和密钥的安全绑定关系，则双方交换的设备信息还可包括当前登录到服务器300所使用的账号。交换账号的步骤可以在S104之前执行，也可以在S104之后执行。如果要求建立安全绑定关系的车控设备和车辆必须登录相同的账号，则车控设备100和车辆200交换账号信息后，还可以确认对端账号和自身账号是否相同，如果相同，则执行后续步骤S106，成功建立安全绑定关系；如果不相同，则可以提示用户双方账号不同，例如图5F右上角的提示方式，并且无法建立安全绑定关系。
S106，车控设备100和车辆200各自存储安全绑定关系。
如果车控设备100和车辆200之间建立的是基于密钥的安全绑定关系，那么车控设备100关联存储车辆200的标识、绑定密钥bindkey，例如表1所示；车辆200关联存储车控设备100的标识、绑定密钥bindkey，例如表2所示。
如果车控设备100和车辆200之间建立的是基于账号和密钥的安全绑定关系，那么车控设备100关联存储车辆200的标识、车控设备100的账号、车辆200的账号、绑定密钥bindkey，例如表3所示；车辆200关联存储车控设备100的标识、车控设备100的账号、车辆200的账号、绑定密钥bindkey，例如表4所示。
在一些实施方式中，车控设备100或车辆200可以将安全绑定关系存储于安全单元中，这样可以保证该安全绑定关系不被泄露，确保绑定密钥只有对应的车控设备100及车辆200获知，从而保证两者之间的通信安全。
通过图7所示的建立安全绑定关系的过程，车控设备100和车辆200可以通过近距离通信技术获得只有双方知晓的绑定密钥bind key。
在一些实施方式中，车控设备100和车辆200都可以先断开与服务器300之间的连接，然后再通过近距离通信技术执行上述图7所示的过程。在一些实施方式中，车控设备100和 车辆200建立安全绑定关系之前，也可以提示用户断开和服务器300之间的连接。车控设备100或车辆200断开和服务器300之间连接的方式可包括但不限于：关闭Wi-Fi功能、关闭蜂窝网络等等。这样，由于切断了车控设备100、车辆200分别与服务器300的连接，即使服务器300存在安全漏洞，也可以保证双方沟通的密钥不被服务器300获取，进而保障后续基于该绑定密钥bind key的通信过程的安全。如果车控设备100和车辆200断开了与服务器300之间的连接，则S105中车控设备100和车辆200交换的账号可以为最近一次登录到服务器300所使用的账号。
图8示出了一种车控设备100和车辆200通过远距离通信技术协商密钥，以建立安全绑定关系的过程。
在车控设备100和车辆200之间的距离较远，无法使用近距离通信技术的情况下，车控设备100和车辆200可以通过远距离通信技术来协商密钥。例如，在租车场景、共享车辆场景下，通常用户侧的车控设备100和车辆200之间的距离较远，此时可以通过远距离通信技术来建立车控设备100和车辆200之间的安全绑定关系。
本申请实施例提及的远距离通信技术是指车控设备100和车辆200通过服务器300通信，依赖于服务器300以及各类公共网络。
如图8所示，通过远距离通信技术建立安全绑定关系的过程可包括如下步骤：
S201，车控设备100被触发和车辆200安全绑定，车辆200被触发和车控设备100安全绑定。
以下介绍几种车控设备100和车辆200被触发绑定对端设备的场景：
场景1，车控设备100接收到用户输入的手机号码后，可以根据该手机号码从服务器300处查询该手机号码下的购车记录，显示该手机号码下购买过的车辆的车辆选项；之后，车控设备100可以接收到作用于某个车辆选项的用户操作，被触发和该车辆选项对应的车辆200安全绑定；响应于该用户操作，车控设备100通过服务器300向车辆200发送绑定请求，以使得车辆200被触发和该车控设备100安全绑定。
图6A-图6G示例性示出了场景1中车控设备100所显示的用户界面，可参考相关描述。
场景2，车控设备100已经和车辆200绑定，但并未安全绑定的情况下，可以显示车辆200的信息，如果接收到用于进入车辆控制界面的用户操作，或者接收到用于控制车辆的用户操作，则车控设备100可以被触发和车辆200安全绑定；并且，车控设备100还可以通过服务器300向车辆200发送绑定请求，以使得车辆200被触发和该车控设备100安全绑定。
图5A示例性示出了车控设备100未和车辆200安全绑定的情况下显示的车辆信息，车控设备100在检测到作用于用户界面51上的用户操作后，可以被触发和对应的车辆200安全绑定。
场景3，车控设备100侧的用户在车控设备100上选中车辆200，并且触发车控设备100和车辆200安全绑定；车辆200侧的用户在车辆200上选中车控设备100，并且触发车辆200和车控设备100安全绑定。
本申请实施例对用户选择车控设备或车辆的方式，以及，触发车控设备或车辆和对端设备安全绑定的方式不做限定。例如，用户可以在车控设备100中输入车辆200的标识，以触发车控设备100和车辆200安全绑定。
S101之后，车控设备100和车辆200可以执行后续的安全绑定流程。
S202-S205，车控设备100和车辆200通过服务器300协商密钥bindkey。
S202，车控设备100和车辆200各自生成椭圆曲线密钥对。
S202和图7中的S1041相同，可参考前文相关描述。
S203，车控设备100登录到服务器300，车辆200登录到服务器300。
本申请实施例对S203的执行顺序不做限定，S203仅需要在S204之前执行即可，其和S201-S202的先后顺序不受限制。
车控设备100可以通过车辆管理应用，使用第一账号登录到服务器300。同样的，车辆200可以通过车辆管理应用，使用第一账号登录到服务器300。第一账号，第二账号可以为相同的账号，也可以为不同的账号。
车控设备100和车辆200各自登录到服务器300后，两设备就可以通过服务器300进行远距离通信。
S204，车控设备100和车辆200通过服务器300交换各自的公钥。
S204的实现可参考图7中的S1042，不同之处在于，在S204交换公钥时无需通过共享密钥pre key加密。
S205，车控设备100和车辆200各自使用对端的公钥和自己的私钥，计算得到绑定密钥bind key。
S205可参考图7中的S1043，不同之处在于，S205中车控设备100和车辆200无需使用共享密钥pre key解密即可获得对端设备的公钥。
上述S202，S204-S205的目的是为了让车控设备100和车辆200能够协商出只有双方知晓的密钥，在本申请一些实施方式中，还可以使用其他技术手段来实现该目的。例如，车控设备100或车辆200可以接收用户直接输入的绑定密钥bindkey，然后将该绑定密钥bindkey，通过服务器300发送给对端设备。
S206，车控设备100和车辆200通过远距离通信技术交换设备信息。
S206可参考图7中的S105，不同之处在于，S206中车控设备100和车辆200交换设备信息使用的是远距离通信技术。
S207，车控设备100和车辆200各自存储安全绑定关系。
S207可参考图7中的S106。
在车控设备100和车辆200成功建立安全绑定关系之后，车控设备100和车辆200可以执行阶段二的步骤，即基于该安全绑定关系进行通信。
在一些实施方式中，如果车控设备100和车辆200建立安全绑定关系之前，均断开了和服务器300的连接，则在执行完阶段一后，车控设备100和车辆200可以提示用户连接到服务器300。车控设备100或车辆200连接到服务器300的方式可包括但不限于：开启Wi-Fi功能、开启蜂窝网络等等。
阶段二，车控设备100和车辆200基于安全绑定关系通信。
车控设备100和车辆200的通信过程包括两方面，一方面是车控设备100向车辆200发送数据的过程，另一方面是车辆200向车控设备100发送数据的过程。车控设备100和车辆200的通信过程可以基于服务器300进行，也可以使用近距离通信技术进行。
图9示出了一种车控设备100向车辆200发送数据的过程。图9以车控设备100和车辆200的通信过程基于服务器300进行为例。
如图9所示，该过程可包括如下步骤：
S301，车控设备100生成待发送给车辆200的数据。
车控设备100发送给车辆200的数据可包括但不限于以下几种类别：
(1)远程控制车辆200的指令。该指令用于远程控制车辆200执行对应的操作，例如远程锁车/解锁指令、远程开窗/关窗指令、远程启动指令、远程开门指令、远程启动/关闭空调的指令、远程召唤车辆的指令、远程打灯的指令等等。
(2)远程监控车辆200的指令。该指令用于远程获取车辆200的状态及其他信息。例如远程查看车辆内部摄像头监控的指令、下载车辆监控数据的指令、下载车辆运行日志的指令、查看车辆位置的指令、查看车辆行车记录的指令等等。
(3)远程诊断车辆200的故障的指令。该指令用于远程获取车辆200的各类状态信息以及运行数据，用于诊断车辆故障。
在一些实施方式中，车控设备100可以在接收到用户操作后，生成待发送给车辆200的数据。例如，参考图5N，车控设备100检测到作用于控制选项506-509中任意一个上的用户操作时，将生成对应的控制车锁的指令、发送控制车窗的指令、发送用于查询车辆位置的指令、发送控制空调的指令。
S302，车控设备100使用存储的绑定密钥bindkey对待发送的数据进行加密。
车控设备100在确定要向车辆200发送数据后，可以在存储的安全绑定关系中，查找和该车辆200对应的绑定密钥bind key。如果车控设备100存储了基于密钥的安全绑定关系，则可以根据车辆200的标识找到对应的绑定密钥bind key。如果车控设备100存储了基于账号和密钥的安全绑定关系，则可以根据车辆200的标识、当前车控设备100和/或车辆200登录到服务器300所使用的账号找到对应的绑定密钥bind key。
车控设备100可以根据实际需求选择数据的加密算法。
在有完整性要求的情况下，该车控设备100可以使用保证数据完整性的算法来对数据进行加密。例如，针对一些不涉及隐私的非敏感数据如启动空调的指令、打灯指令等，可以使用完整性算法。完整性是指在传输、存储信息或数据的过程中，确保信息或数据不被非授权方篡改或在被篡改后能够被迅速发现。保证数据完整性的算法可包括但不限于：哈希消息认证码算法(hash-based message suthentication code，HMAC)等加密算法。
在有机密性要求的情况下，该车控设备100可以使用保证数据机密性的算法来对数据进行加密。例如，针对一些涉及隐私的敏感数据如查看车辆位置的指令、解锁指令等，可以使用机密性算法。机密性是指在传输、存储信息或数据的过程中，确保信息或数据不能够被非授权方获取。保证数据机密性的算法可包括但不限于：密码分组链接模式(cipher block chaining，CBC)的高级加密标准(advanced encrptionstandard，AES)，即AES-CBC。
在同时有完整性和机密性要求的情况下，该车控设备100可以使用同时保证数据机密性和完整性的算法来对数据进行加密。同时保证数据机密性和完整性的算法可包括但不限于：计算器模式(galois/counter mode，GSM)的高级加密标准(advanced encrptionstandard，AES)，即AES-GSM。
S303，车控设备100将加密后的数据，通过服务器300发送给车辆200。
在一些实施方式中，车控设备100在发送加密后数据的同时，还可以将当前车控设备100登录到服务器300使用的第一账号，和/或，车控设备100的设备标识同时通过服务器300发送给车辆200。
S304，车辆200使用存储的绑定密钥bindkey解密接收到的数据，以获得原始数据。
在一些实施方式中，如果车辆200还接收到了设备标识，则车辆200还可以查找存储的安全绑定关系，查看自己绑定的各个设备的设备标识中是否包括接收到的该设备标识，如果 有，则执行S304，如果没有则不执行S304。这样可以避免未绑定的车控设备或第三方发送数据而使得车辆200执行无意义的解密操作。
在一些实施方式中，如果车辆200还接收到了发送方的账号，则车辆200还可以查找存储的安全绑定关系，查看自己绑定的各个设备的账号中是否包括接收到的该账号，如果有，则执行S304，如果没有则不执行S304。这样可以避免未绑定的账号发送数据而使得车辆200执行无意义的解密操作。
具体执行S304时，车辆200可以在存储的安全绑定关系中，查找和该车控设备100对应的绑定密钥bind key。如果车辆200存储了基于密钥的安全绑定关系，则可以根据车辆200的标识找到对应的绑定密钥bind key。如果车辆200存储了基于账号和密钥的安全绑定关系，则可以根据车辆200的标识、当前车控设备100和/或车辆200登录到服务器300所使用的账号找到对应的绑定密钥bind key。
车辆200使用S302中车控设备100加密时相同的算法来解密接收到的数据。该算法可以是车控设备100和车辆200协商一致使用的，或者是预先设置好使用的算法。
S305，车辆200根据该数据执行对应的操作。
如果车辆200解密后获取到的数据是远程控制车辆200的指令、远程监控车辆200的指令或远程诊断车辆200的故障的指令，则车辆200根据该指令执行相应的操作。例如，车辆200可以根据该指令解锁、开窗、查询位置并返回位置给车控设备100、发送监控画面给车控设备100、发送行车记录仪给车控设备100等等。
通过图9所示的方法，车控设备100和车辆200分别存储有只有双方知晓的密钥，车控设备100使用该密钥将数据加密后发送给车辆200，车辆200使用相同的密钥。
图10示出了一种车辆200向车控设备100发送数据的过程。图10以车控设备100和车辆200的通信过程基于服务器300进行为例。
如图10所示，该过程可包括如下步骤：
S401，车辆200获取待发送给车控设备100的数据。
车辆200发送给车控设备100的数据可包括但不限于以下几种类别：(1)表征车辆状态的数据，例如车窗状态、发送机状态、车门状态、空调状态、车辆位置，等等。(2)车辆本身存储的数据，如监控数据、运行日志、行车记录等。
在一些实施方式中，车辆200可以在接收到车辆200发送的指令后，获取待发送给车控设备100的数据。例如，车辆200接收到车控设备100在S304中发送的指令后，可以获取待发送给车控设备100的数据，例如车锁状态、车窗状态、车辆位置、空调状态等等。
S402，车辆200使用存储的绑定密钥bindkey对待发送的数据进行加密。
S403，车辆200将加密后的数据，通过服务器300发送给车控设备100。
S404，车控设备100使用存储的绑定密钥bindkey解密接收到的数据，以获得原始数据。
S402-S404可参考前文S302-S304的实现，不同之处在于两者的执行主体互换了。
S405，车控设备100根据该数据执行对应的操作。
如果车控设备100解密后获取到的数据是车辆200发送的表征车辆状态的数据、车辆本身存储的数据等，车控设备可以存储这些数据，也可以将这些数据显示在显示屏中，以供用户查看。
车控设备100和车辆200的通信过程不限于图9、图10示出的通过服务器300进行，在一些实施方式中，车控设备100和车辆200也可以使用近距离通信技术和绑定密钥bindkey 通信。车控设备100和车辆200使用近距离通信技术通信的过程，和图9、图10描述的过程类似，不同之处是通信技术的不同。
在上述图7-图10所示的方法中，车控设备和车辆之间通信所用的绑定密钥bindkey，也可以被称为第一密钥。图9-图10中车控设备和车辆通信过程中发送的数据，可以被称为第一数据。
通过图7-图10所示的方法，车控设备和车辆建立安全绑定关系，并基于该安全绑定关系来通信，能够保证双方交互的数据只有具备该安全绑定关系的该车控设备和该车辆能够获取到，避免双方的交互数据被第三方获取、篡改或伪造。这样可以保障车辆及车控设备双方的信息安全，进而避免了车辆中用户的隐私数据泄露、车辆被第三方控制、车辆丢失、多车辆批量被第三方控制等情况，提高了车辆的安全性。这里的第三方指车控设备、车辆以外的其他设备或机构。
上述图7-图10所示的方法，仅示出了车控设备和车辆协商一个密钥，并使用该对称密钥算法和该密钥来通信的方案。在其他一些实施方式中，车控设备和车辆还可以协商一对密钥或两对密钥，并使用该一对密钥或两对密钥来通信。本申请实施例对车控设备和车辆协商一对或两对密钥的方式不做限定。
在上述图7-图10所示的方法中，车控设备和服务器之间的通信数据可以通过基于传输层安全协议(transport layer security protocol，TLS)的以安全为目标的超文本传输协议(hyper text transfer protocol over secure socket layer，HTTPS)加密，车辆和服务器之间的通信数据也可以通过基于TLS的消息队列遥测传输协议(message queuing telemetry transport，MQTT)协议加密，从而进一步保证车控设备和车辆通过服务器通信时的通信通道的安全性。
应理解，上述方法实施例中的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
本申请还提供一种车控设备，该车控设备可以包括：存储器和处理器。其中，存储器可用于存储计算机程序；处理器可用于调用所述存储器中的计算机程序，以使得该车辆执行上述任意一个实施例中车控设备100侧执行的方法。
本申请还提供一种车辆，该车辆可以包括：存储器和处理器。其中，存储器可用于存储计算机程序；处理器可用于调用所述存储器中的计算机程序，以使得该车辆执行上述任意一个实施例中车辆200侧执行的方法。
本申请还提供了一种芯片系统，所述芯片系统包括至少一个处理器，用于实现上述任一个实施例中车控设备100或车辆200侧所涉及的功能。
在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。
该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
可选地，该芯片系统中的处理器可以为一个或多个。该处理器可以通过硬件实现也可以通过软件实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等。当通过软件实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现。
可选地，该芯片系统中的存储器也可以为一个或多个。该存储器可以与处理器集成在一起，也可以和处理器分离设置，本申请实施例并不限定。示例性地，存储器可以是非瞬时性 处理器，例如只读存储器ROM，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型，以及存储器与处理器的设置方式不作具体限定。
示例性地，该芯片系统可以是现场可编程门阵列(field programmable gate array，FPGA)，可以是专用集成芯片(application specific integrated circuit，ASIC)，还可以是系统芯片(system on chip，SoC)，还可以是中央处理器(central processor unit，CPU)，还可以是网络处理器(network processor，NP)，还可以是数字信号处理电路(digital signal processor，DSP)，还可以是微控制器(micro controller unit，MCU)，还可以是可编程控制器(programmable logic device，PLD)或其他集成芯片。
本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行上述任一个实施例中车控设备100或车辆200侧所执行的方法。
本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行上述任一个实施例中车控设备100或车辆200侧所执行的方法。
本申请的各实施方式可以任意进行组合，以实现不同的技术效果。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。
总之，以上所述仅为本申请技术方案的实施例而已，并非用于限定本申请的保护范围。凡根据本申请的揭露，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (27)

  1. 一种针对车辆的安全通信方法，其特征在于，所述方法应用于车控设备，所述方法包括：
    所述车控设备生成待发送的第一数据，使用第一密钥对所述第一数据进行加密；
    所述车控设备将加密后的所述第一数据发送给车辆。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    所述车控设备接收到所述车辆发送的加密后的第二数据；
    所述车控设备使用所述第一密钥解密加密后的所述第二数据，得到所述第二数据；
    所述车控设备根据所述第二数据执行对应的操作。
  3. 根据权利要求1或2所述的方法，其特征在于，所述车控设备使用第一密钥对所述第一数据进行加密之前，所述方法还包括：
    所述车控设备和所述车辆协商得到所述第一密钥；
    或者，所述车控设备确定所述第一密钥后，将所述第一密钥发送给所述车辆；
    或者，所述车控设备接收到所述车辆发送的所述第一密钥，并且所述第一密钥由所述车辆确定。
  4. 根据权利要求3所述的方法，其特征在于，所述车控设备和所述车辆协商得到所述第一密钥，具体包括：
    所述车控设备扫描所述车辆显示的二维码或条形码，或者，接收到输入的和所述车辆显示的数字密码相同的数字密码，所述二维码、所述条形码、所述数字密码均携带有所述车辆生成的绑定因子；或者，所述车控设备通过近场通信NFC接收到所述车辆发送的所述绑定因子；
    所述车控设备根据所述绑定因子生成共享密钥；
    所述车控设备和所述车辆，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到所述第一密钥，并且所述车控设备在协商过程中使用所述共享密钥加密发送给所述车辆的公钥，所述车控设备和所述车辆在协商过程中通过近距离通信技术通信。
  5. 根据权利要求3或4所述的方法，其特征在于，所述方法还包括：
    在所述车控设备和所述车辆协商得到所述第一密钥的过程中，所述车控设备断开和服务器的连接，所述服务器用于管理所述车辆。
  6. 根据权利要求3所述的方法，其特征在于，所述车控设备和所述车辆协商得到所述第一密钥，具体包括：
    所述车控设备和所述车辆，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到所述第一密钥，并且所述车控设备和所述车辆在协商过程中通过服务器通信，所述服务器用于管理所述车辆。
  7. 根据权利要求6所述的方法，其特征在于，所述车控设备和所述车辆协商得到所述第 一密钥之前，所述方法还包括：
    所述车控设备接收到输入的手机号码；
    所述车控设备显示一个或多个车辆选项，所述一个或多个车辆选项对应所述手机号码下购买的车辆；
    所述车控设备接收到作用于所述车辆选项的用户操作；和所述车控设备协商所述第一密钥的所述车辆为，接收到所述用户操作的车辆选项对应的车辆。
  8. 根据权利要求3-7任一项所述的方法，其特征在于，所述车控设备和所述车辆协商得到所述第一密钥之后，所述方法还包括：
    所述车控设备关联存储所述车辆的标识，和，所述第一密钥。
  9. 根据权利要求1-8任一项所述的方法，其特征在于，所述车控设备和所述车辆使用相同账号登录到服务器，所述服务器用于管理所述车辆。
  10. 根据权利要求1-9任一项所述的方法，其特征在于，
    所述第一数据包括远程控制指令，所述远程控制指令用于指示所述车辆执行对应的操作；
    或者，
    所述第一数据包括远程监控指令，所述远程监控指令用于查询所述车辆的状态。
  11. 根据权利要求2所述的方法，其特征在于，所述第二数据包括表征所述车辆的状态的数据，和/或，所述车辆的运行数据。
  12. 一种针对车辆的安全通信方法，其特征在于，所述方法应用于车辆，所述方法包括：
    所述车辆接收到车控设备发送的加密后的第一数据；
    所述车辆使用所述第一密钥解密加密后的所述第一数据，得到所述第一数据；
    所述车辆根据所述第一数据执行对应的操作。
  13. 根据权利要求12所述的方法，其特征在于，所述方法还包括：
    所述车辆获取待发送的第二数据，使用所述第一密钥对所述第二数据进行加密；
    所述车辆将加密后的所述第二数据发送给所述车控设备。
  14. 根据权利要求12或13所述的方法，其特征在于，所述车辆接收到车控设备发送的加密后的第一数据之前，所述方法还包括：
    所述车辆和所述车控设备协商得到所述第一密钥；
    或者，所述车辆确定所述第一密钥后，将所述第一密钥发送给所述车控设备；
    或者，所述车辆接收到所述车控设备发送的所述第一密钥，并且所述第一密钥由所述车控设备确定。
  15. 根据权利要求14所述的方法，其特征在于，所述车辆和所述车控设备协商得到所述第一密钥，具体包括：
    所述车辆显示二维码或条形码或数字密码，所述二维码、所述条形码、所述数字密码均 携带有所述车辆生成的绑定因子；或者，所述车辆通过近场通信NFC将所述绑定因子发送给所述车控设备；
    所述车辆根据所述绑定因子生成共享密钥；
    所述车辆和所述车控设备，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到所述第一密钥，并且所述车辆在协商过程中使用所述共享密钥加密发送给所述车控设备的公钥，所述车辆和所述车控设备在协商过程中通过近距离通信技术通信。
  16. 根据权利要求14或15所述的方法，其特征在于，所述方法还包括：
    在所述车辆和所述车控设备协商得到所述第一密钥的过程中，所述车辆断开和服务器的连接，所述服务器用于管理所述车辆。
  17. 根据权利要求14所述的方法，其特征在于，所述车辆和所述车控设备协商得到所述第一密钥，具体包括：
    所述车辆和所述车控设备，通过椭圆曲线迪菲-赫尔曼秘钥交换ECDH算法协商得到所述第一密钥，并且所述车辆和所述车控设备在协商过程中通过服务器通信，所述服务器用于管理所述车辆。
  18. 根据权利要求17所述的方法，其特征在于，所述车辆和所述车控设备协商得到所述第一密钥之前，所述方法还包括：
    所述车辆接收到所述车控设备发送的绑定请求。
  19. 根据权利要求14-18任一项所述的方法，其特征在于，所述车辆和所述车控设备协商得到所述第一密钥之后，所述方法还包括：
    所述车辆关联存储所述车控设备的标识，和，所述第一密钥。
  20. 根据权利要求12-19任一项所述的方法，其特征在于，所述车辆和所述车控设备使用相同账号登录到服务器，所述服务器用于管理所述车辆。
  21. 根据权利要求12-20任一项所述的方法，其特征在于，
    所述第一数据包括远程控制指令，所述远程控制指令用于指示所述车辆执行对应的操作；
    或者，
    所述第一数据包括远程监控指令，所述远程监控指令用于查询所述车辆的状态。
  22. 根据权利要求13所述的方法，其特征在于，所述第二数据包括表征所述车辆的状态的数据，和/或，所述车辆的运行数据。
  23. 一种通信系统，其特征在于，所述通信系统包括车控设备和车辆，所述车控设备用于执行如权利要求1-11任一项所述的方法，所述车辆用于执行如权利要求12-22任一项所述的方法。
  24. 一种车控设备，其特征在于，包括：存储器、一个或多个处理器；所述存储器与所 述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述车控设备执行如权利要求1-11中任一项所述的方法。
  25. 一种车辆，其特征在于，包括：存储器、一个或多个处理器；所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述车辆执行如权利要求12-22中任一项所述的方法。
  26. 一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行，使得所述电子设备执行如权利要求1-11中任一项或如权利要求12-22中任一项所述的方法。
  27. 一种计算机程序产品，其特征在于，所述计算机程序产品包含计算机指令，当所述计算机指令在电子设备上运行，使得所述电子设备执行如权利要求1-11中任一项或如权利要求12-22中任一项所述的方法。
PCT/CN2023/074973 2022-02-14 2023-02-08 针对车辆的安全通信方法、相关装置及通信系统 WO2023151582A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202210134460 2022-02-14
CN202210134460.8 2022-02-14
CN202210751865.6A CN116633531A (zh) 2022-02-14 2022-06-29 针对车辆的安全通信方法、相关装置及通信系统
CN202210751865.6 2022-06-29

Publications (1)

Publication Number Publication Date
WO2023151582A1 true WO2023151582A1 (zh) 2023-08-17

Family

ID=87563650

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/074973 WO2023151582A1 (zh) 2022-02-14 2023-02-08 针对车辆的安全通信方法、相关装置及通信系统

Country Status (1)

Country Link
WO (1) WO2023151582A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140270158A1 (en) * 2013-03-14 2014-09-18 General Motors Llc Connection key distribution
US20170236343A1 (en) * 2016-02-16 2017-08-17 GM Global Technology Operations LLC Regulating vehicle access using cryptographic methods
CN111200496A (zh) * 2019-11-05 2020-05-26 储长青 一种基于车辆的数字钥匙实现方法
CN112600668A (zh) * 2020-12-15 2021-04-02 上海银基信息安全技术股份有限公司 密钥协商方法、装置、电子设备和存储介质
CN113589722A (zh) * 2021-07-21 2021-11-02 上汽通用五菱汽车股份有限公司 车控加密方法、系统、装置及计算机可读存储介质
CN113613250A (zh) * 2021-07-22 2021-11-05 上汽通用五菱汽车股份有限公司 蓝牙车控方法、系统及计算机可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140270158A1 (en) * 2013-03-14 2014-09-18 General Motors Llc Connection key distribution
US20170236343A1 (en) * 2016-02-16 2017-08-17 GM Global Technology Operations LLC Regulating vehicle access using cryptographic methods
CN111200496A (zh) * 2019-11-05 2020-05-26 储长青 一种基于车辆的数字钥匙实现方法
CN112600668A (zh) * 2020-12-15 2021-04-02 上海银基信息安全技术股份有限公司 密钥协商方法、装置、电子设备和存储介质
CN113589722A (zh) * 2021-07-21 2021-11-02 上汽通用五菱汽车股份有限公司 车控加密方法、系统、装置及计算机可读存储介质
CN113613250A (zh) * 2021-07-22 2021-11-05 上汽通用五菱汽车股份有限公司 蓝牙车控方法、系统及计算机可读存储介质

Similar Documents

Publication Publication Date Title
CN115580854B (zh) 蓝牙扫描方法和电子设备
CN109690607B (zh) 基于视频的数据收集、图像捕获以及分析配置
US10202100B1 (en) Accessing a vehicle using portable devices
CN111404802A (zh) 通知处理系统、方法以及电子设备
WO2020233538A1 (zh) 一种接入无线局域网的方法和终端
WO2021197139A1 (zh) 一种推荐服务的方法、电子设备和系统
US20220188095A1 (en) Method for storing and transmitting data by using vehicle key and apparatus
EP4030680A1 (en) Application processing method and related product
CN115019418B (zh) 蓝牙车钥匙控车方法、装置和存储介质
US20240095408A1 (en) Data protection method and system, medium, and electronic device
CN113965789B (zh) 一种投屏方法、终端和通信系统
CN116633531A (zh) 针对车辆的安全通信方法、相关装置及通信系统
WO2023198104A1 (zh) 异步授权方法、系统、电子设备及计算机可读存储介质
WO2023151582A1 (zh) 针对车辆的安全通信方法、相关装置及通信系统
WO2023169545A1 (zh) 离线设备控制方法及相关装置
WO2023029990A1 (zh) 蓝牙连接方法及电子设备
WO2023024887A1 (zh) 跨设备认证方法和装置
CN115001667B (zh) 密钥协商方法、系统、电子设备和计算机可读存储介质
WO2024078315A1 (zh) 一种应用控制方法、电子设备和系统
CN118102295A (zh) 一种通信方法以及电子设备
CN116033592B (zh) 蜂窝通信功能的使用方法和装置
WO2024103411A1 (zh) 分享数字车钥匙的方法及装置、存储介质
CN117951662A (zh) 一种处理数据的方法及电子设备
CN116996611A (zh) 一种通知消息处理系统、方法和装置
CN116782186A (zh) 离线设备控制方法及相关装置

Legal Events

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

Ref document number: 23752362

Country of ref document: EP

Kind code of ref document: A1