WO2023221591A1 - 一种数据传输的方法、相关装置、设备以及存储介质 - Google Patents

一种数据传输的方法、相关装置、设备以及存储介质 Download PDF

Info

Publication number
WO2023221591A1
WO2023221591A1 PCT/CN2023/078315 CN2023078315W WO2023221591A1 WO 2023221591 A1 WO2023221591 A1 WO 2023221591A1 CN 2023078315 W CN2023078315 W CN 2023078315W WO 2023221591 A1 WO2023221591 A1 WO 2023221591A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
public key
data
key
identification
Prior art date
Application number
PCT/CN2023/078315
Other languages
English (en)
French (fr)
Inventor
张鹏
宋伟
张巨广
农臻豪
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2023221591A1 publication Critical patent/WO2023221591A1/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
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy

Definitions

  • This application relates to the field of security technology and the field of Internet of Vehicles technology, especially data transmission technology.
  • the driving recorder is one of the devices installed in the car. Its function has gradually developed from pure positioning recording to the recording of multi-dimensional information, thereby enabling remote collection of pictures and videos, analysis of driver driving behavior, real-time remote live broadcast, and location positioning. Trajectory and other functions.
  • cloud transfer or cloud storage can be used to store the driving data collected by the driving recorder on the cloud device, and the keys and certificates are saved on a third-party server.
  • the car owner wants to access the driving data collected by the driving recorder, he directly initiates an access request to the cloud device, and the cloud device feeds back the driving data to the user.
  • Driving data is highly private, and storing keys and certificates on third-party servers still poses certain security risks. That is, driving data is easily stolen or tampered with during the data transmission process, and the security and reliability of data transmission are low.
  • Embodiments of the present application provide a data transmission method, related devices, equipment, and storage media. It can improve the security, privacy and reliability of data transmission.
  • this application provides a data transmission method, which is executed by the second device, including:
  • the first public key and the first device identifier are determined according to the first certificate, where the first public key and the first private key are key pairs generated by the first device,
  • the first device identifier is the identifier corresponding to the first device;
  • both the first device identification and the second device identification are registered identifications, receive a data access request sent by the first device, where the data access request is encrypted by the first device using the second public key or the first private key,
  • the second public key is obtained by the first device based on the second certificate, the second public key and the second private key are a key pair generated by the second device, and the second device identifier is the corresponding identifier of the second device;
  • target data is sent to the first device, where the target data is encrypted by the second device using the first public key or the second private key.
  • Another aspect of this application provides a data transmission method, which is executed by the first device, including:
  • the second public key and the second device identification are determined based on the second certificate, where the second public key and the second private key are key pairs generated by the second device,
  • the second device identifier is the identifier corresponding to the second device
  • a data access request is sent to the second device, where the data access request is encrypted by the first device using the second public key or the first private key.
  • a public key and a first private key are a key pair generated by the first device, and the first device identifier is a corresponding identifier of the first device;
  • a data transmission device including:
  • a transceiver module configured to receive the first certificate sent by the first device, and send the second certificate to the first device;
  • Determining module configured to determine the first public key and the first device identification according to the first certificate if the first certificate and the second certificate are both valid certificates, wherein the first public key and the first private key are generated for the first device
  • the key pair, the first device identification is the identification corresponding to the first device
  • the transceiver module is also configured to receive a data access request sent by the first device if the first device identifier and the second device identifier are both registered identifiers, wherein the data access request is that the first device adopts the second public key or the first
  • the private key is encrypted, the second public key is obtained by the first device based on the second certificate, the second public key and the second private key are a key pair generated by the second device, and the second device is identified as corresponding to the second device logo;
  • the transceiver module is also configured to respond to the data access request sent by the first device and send target data to the first device, where the target data is encrypted by the second device using the first public key or the second private key.
  • a data transmission device including:
  • a transceiver module configured to send the first certificate to the second device and receive the second certificate sent by the second device;
  • Determining module configured to determine the second public key and the second device identification according to the second certificate if the first certificate and the second certificate are both valid certificates, wherein the second public key and the second private key are generated for the second device
  • the key pair, the second device identification is the identification corresponding to the second device
  • a transceiver module configured to send a data access request to the second device if both the first device identifier and the second device identifier are registered identifiers, where the data access request is that the first device uses the second public key or the first private key. Obtained through encryption, the first public key and the first private key are the key pairs generated by the first device, and the first device identifier is the corresponding identifier of the first device;
  • the transceiver module is configured to receive target data sent by the second device, where the target data is encrypted by the second device using the first public key or the second private key.
  • the data transmission system includes vehicle-mounted terminals and mobile devices, including:
  • the vehicle-mounted terminal receives the first certificate sent by the mobile terminal
  • the mobile terminal receives the second certificate sent by the vehicle-mounted terminal
  • the vehicle-mounted terminal determines the first public key and the first device identification based on the first certificate, and the mobile terminal determines the second public key and the second device identification based on the second certificate, wherein, the first public key and the first private key are a key pair generated by the mobile terminal, the second public key and the second private key are a key pair generated by the vehicle-mounted terminal, the first device identifier is the identifier corresponding to the mobile terminal, and the The second device identification is the identification corresponding to the vehicle-mounted terminal;
  • the mobile terminal sends a data access request to the vehicle-mounted terminal, where the data access request is encrypted by the mobile terminal using the second public key or the first private key;
  • the vehicle-mounted terminal responds to the data access request sent by the mobile terminal and sends target driving data to the mobile terminal, where the target driving data is encrypted by the vehicle-mounted terminal using the first public key or the second private key.
  • Another aspect of the present application provides a computer device, including a memory and a processor.
  • the memory stores a computer program.
  • the processor executes the computer program, the methods of the above aspects are implemented.
  • Another aspect of the present application provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed by a processor, the methods of the above aspects are implemented.
  • Another aspect of the present application provides a computer program product, including a computer program, which implements the methods of the above aspects when executed by a processor.
  • the embodiment of the present application provides a data transmission method.
  • the second device receives the first certificate sent by the first device and sends the second certificate to the first device.
  • the second device determines the first public key and the first device identification based on the first certificate. Based on this, if the first device identification and the second device identification are both registered identifications, the second device receives the data access request sent by the first device, and responds to the data access request to send the target data to the first device.
  • the first public key and the first private key are the key pairs generated by the first device
  • the first device identification is the identification corresponding to the first device
  • the second public key and the second private key are the keys generated by the second device.
  • the second device identifier is the identifier corresponding to the second device.
  • the data access request is encrypted by the first device using the second public key or the first private key
  • the target data is encrypted by the second device using the first public key or the second private key.
  • P2P peer to Peer
  • the key and certificate system is extended to the decentralized peer-to-peer network (Peer to Peer, P2P), so that terminals in the P2P network (for example, vehicle-mounted terminals and mobile terminals) can use each other's information stored in Local keys and certificates implement identity authentication, which helps improve the security, privacy and reliability of data transmission between terminals.
  • Figure 1 is an architectural schematic diagram of a data transmission system in an embodiment of the present application
  • Figure 2 is an environmental schematic diagram of the Internet of Vehicles system in the embodiment of the present application.
  • Figure 3 is a schematic flow chart of the data transmission method in the embodiment of the present application.
  • Figure 4 is a schematic diagram of the work flow of a vehicle-mounted terminal based on the Internet of Vehicles system in the embodiment of the present application;
  • Figure 5 is a schematic diagram of an interface for releasing a terminal identity binding relationship in an embodiment of the present application
  • Figure 6 is a schematic diagram of an interface for adding a terminal identification binding relationship in an embodiment of the present application.
  • Figure 7 is a communication schematic diagram of an intelligent connected car in an embodiment of the present application.
  • Figure 8 is a schematic diagram of terminal communication based on QR codes in an embodiment of the present application.
  • Figure 9 is a schematic diagram of terminal communication based on manual input of information in an embodiment of the present application.
  • Figure 10 is another schematic flow chart of the data transmission method in the embodiment of the present application.
  • Figure 11 is a schematic diagram of the work flow of a mobile terminal based on the Internet of Vehicles system in the embodiment of the present application;
  • Figure 12 is a schematic diagram of an interaction process based on the Internet of Vehicles system in the embodiment of the present application.
  • Figure 13 is a schematic diagram of a data transmission device in an embodiment of the present application.
  • Figure 14 is another schematic diagram of the data transmission device in the embodiment of the present application.
  • Figure 15 is a schematic structural diagram of a terminal in an embodiment of the present application.
  • this application provides a secure data transmission solution based on peer-to-peer (Peer to Peer, P2P).
  • P2P has some advantages that the server-client (Client-Server, C/S) model does not have, which are mainly reflected in the expansion of information volume and the free and open nature of anonymous services.
  • C/S server-client
  • the biggest advantage of P2P is that it can support reliable and convenient information query.
  • peer nodes share some of the resources they own. These shared resources provide services and content through the network and can be directly accessed by other peer nodes without going through intermediate entities. It can be seen that peer nodes are both resource providers (ie, servers) and resource acquirers (ie, clients) in the P2P network.
  • the data transmission system includes several node devices.
  • the node device may be a server or a terminal.
  • This application uses the node device as a terminal as an example for introduction.
  • the client is deployed on the terminal.
  • the client can run on the terminal in the form of a browser, or it can run on the terminal in the form of an independent application (application, APP).
  • application application, APP
  • the server involved in this application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers.
  • the terminal can be a mobile phone, computer, intelligent voice interaction device, smart home appliance, vehicle terminal, aircraft, etc., but is not limited to this.
  • Embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.
  • FIG 2 is an environmental schematic diagram of the Internet of Vehicles system in the embodiment of the present application. As shown in the figure, vehicles and vehicles, vehicles and equipment, vehicles and roads, and vehicles and vehicles are realized through information and communication technology. Information sharing between clouds. In the process of Internet of Vehicles communication, an identity authentication system is established to give vehicles, roadside units (Road Side Units, RSUs) and information service platforms and other infrastructure infrastructure trusted digital identities to resist security attacks such as information forgery and tampering.
  • RSUs Roadside units
  • information service platforms and other infrastructure infrastructure trusted digital identities to resist security attacks such as information forgery and tampering.
  • the Internet of Vehicles is the application of the Internet of Things (IOT) in the automotive industry.
  • the Internet of Things refers to the real-time Collect any objects or processes that need to be connected and interacted, collect their sound, light, heat, electricity, mechanics, chemistry, biology, location and other required information, and realize the connection between things and things through various possible network accesses. Ubiquitous connection with people enables intelligent perception, identification and management of items and processes.
  • the Internet of Things is an information carrier based on the Internet, traditional telecommunications networks, etc., allowing all ordinary physical objects that can be independently addressed to form an interconnected network.
  • the Cloud IOT aims to connect the information sensed and the instructions received by the sensing devices in the traditional Internet of Things to the Internet to truly realize networking and realize the storage and calculation of massive data through cloud computing technology. Due to the The characteristic of the Internet is that things are connected to each other, and the current operating status of each "object" is perceived in real time. Therefore, a large amount of data information will be generated in this process. How to summarize this information, and how to filter out useful information from the massive information. Decision support for subsequent development has become a key issue affecting the development of the Internet of Things, and cloud IoT based on cloud computing and cloud storage technology has therefore become a strong support for the application of Internet of Things technology.
  • Car Generally refers to smart cars or intelligent connected cars.
  • Vehicle-mounted terminal It can be equipped with a vehicle-mounted system (i.e., the system used by the car), usually using the Android system.
  • vehicle-mounted terminal integrates multiple functions such as positioning, communication, and driving recorder, and has business scheduling functions and data processing capabilities. In this application, it is assumed that the vehicle system has high security and cannot be cracked. Therefore, the private key cannot be obtained.
  • Car owner that is, the owner of the car.
  • This application generally refers to the car owner’s mobile terminal, including but not limited to computers and mobile phones.
  • the account system of the mobile terminal has high security and will not allow other users to obtain the data of the car owner's terminal and the private key therein.
  • Public key and private key Asymmetric encryption key pair, in which the private key is kept by itself.
  • Equipment identification The unique identification (identity, ID) of the device. Usually, vehicle-mounted terminals and mobile terminals have their own TID.
  • Mobile terminal identification (mobile ID, MID): Indicates the ID of the vehicle terminal. This part can also be provided by the car owner's account.
  • Car terminal identification (car ID, CID): Indicates the TID of the car terminal.
  • Car owner account The login account of the car company APP.
  • Certificate Indicates that a certain public key is a certificate file belonging to a certain TID.
  • the certificate is signed by an authority and can therefore be verified.
  • Root certificate the public key file of an authoritative organization, a self-signed certificate.
  • Authoritative organization that is, the certificate issuing authority (Certification Authority, CA) is the core of the Public Key Infrastructure (PKI). It is mainly used to save private keys, provide root certificates, and is responsible for issuing certificates and authentication. Certificates, manage issued certificates, etc. Generally, traffic scheduling, session maintenance, and load balancing are completed in authoritative institutions.
  • CA Certificate issuing authority
  • PKI Public Key Infrastructure
  • the data transmission method in this embodiment of the application can be performed by a terminal.
  • the terminal can be a vehicle-mounted terminal, including:
  • the second device receives the first certificate sent by the first device, and sends the second certificate to the first device;
  • the first device after the first device establishes a communication connection with the second device, the first device sends a first certificate to the second device, and the second device sends a second certificate to the first device.
  • the first device may be a mobile terminal (for example, a mobile phone, a tablet or a computer, etc.), and the second device may be a vehicle-mounted terminal.
  • the mobile terminal After the mobile terminal establishes a communication connection with the vehicle-mounted terminal, the mobile terminal sends the first certificate to the vehicle-mounted terminal, whereby the vehicle-mounted terminal receives the first certificate. Similarly, the vehicle-mounted terminal sends the second certificate to the mobile terminal, whereby the mobile terminal receives the second certificate.
  • the second device determines the first public key and the first device identification based on the first certificate, where the first public key and the first private key are generated by the first device.
  • the key pair, the first device identification is the identification corresponding to the first device;
  • the second device verifies the validity of the first certificate, and the first device verifies the validity of the second certificate. If both the first certificate and the second certificate are valid certificates, the second device may determine the public key in the first certificate as the first public key, and determine the device identification in the first certificate as the first device identification. Similarly, the first device may determine the public key in the second certificate as the second public key, and determine the device identification in the second certificate as the second device identification.
  • the first public key and the first private key are a key pair generated by the first device, and the first device identifier is a corresponding identifier of the first device.
  • the second public key and the second private key are a key pair generated by the second device, and the second device identifier is a corresponding identifier of the second device.
  • the vehicle-mounted terminal obtains the first public key and the first device identification based on the first certificate, where the first public key and the first private key are key pairs generated by the mobile terminal, that is, the first public key may be the mobile terminal
  • the public key and the first private key may be the mobile terminal private key.
  • the first device identifier is the TID of the mobile terminal, That is MID.
  • the mobile terminal obtains the second public key and the second device identification based on the second certificate, where the second public key and the second private key are key pairs generated by the vehicle-mounted terminal, that is, the second public key may be the vehicle-mounted terminal.
  • the public key and the second private key may be the vehicle terminal private key.
  • the second device identifier is the TID of the vehicle-mounted terminal, that is, CID.
  • the second device receives the data access request sent by the first device, wherein the data access request is that the first device uses the second public key or the first private key.
  • the second public key is obtained by the first device according to the second certificate, the second public key and the second private key are the key pairs generated by the second device, and the second device identification is the key pair corresponding to the second device. logo;
  • the second device detects the registration status of the first device identity, and the first device detects the registration status of the second device identity. If the first device identity and the second device identity are both registered identities, the first device can encrypt the data access request using the second public key or the first private key. Based on this, the first device sends a data access request to the second device.
  • the mobile terminal uses the vehicle-mounted terminal public key or the mobile terminal private key to encrypt the data access request. Based on this, the mobile terminal sends the data access request to the vehicle-mounted terminal.
  • the second device responds to the data access request sent by the first device and sends target data to the first device, where the target data is encrypted by the second device using the first public key or the second private key.
  • the second device uses the first public key or the second private key to encrypt the original data based on the data access request sent by the first device, thereby obtaining the target data. Then, the second device sends the target data to the first device.
  • the vehicle-mounted terminal in response to the data access request, encrypts the original data using the mobile terminal public key or the vehicle-mounted terminal private key to obtain the target data. Then, the vehicle-mounted terminal sends the target data to the mobile terminal.
  • the original data can be driving data collected by a driving recorder, including but not limited to voice, photos, video records, etc. collected during driving.
  • the embodiment of the present application provides a data transmission method.
  • the key and certificate system is extended to the decentralized P2P network, so that terminals in the P2P network (for example, vehicle-mounted terminals and mobile terminals) can use locally stored keys and certificates to achieve identity. Authentication, thus helping to improve the security, privacy and reliability of data transmission between terminals.
  • the second device before the second device sends the second certificate to the first device, it may also include:
  • the second device obtains the second public key and the second private key
  • the second device stores the second private key
  • the second device sends the second public key and the second device identification to the authentication server, so that the authentication server uses the target private key to sign the second public key and the second device identification to obtain the second certificate;
  • the second device receives the second certificate sent by the authentication server.
  • a method for a second device to apply for a certificate from an authority is introduced. It can be seen from the foregoing embodiments that before the second device sends the second certificate to the first device, it needs to first Apply for a second certificate from the authority. First, the second device generates a key pair, namely a second public key and a second private key. On the one hand, the second device needs to store the second private key locally. On the other hand, the second device needs to send the second public key and the second device identification to the authentication server of the authority, and the authentication server uses its own target private key to sign the second public key and the second device identification to obtain the second Two certificates. Finally, the authentication server feeds back the second certificate to the second device.
  • Figure 4 is a schematic diagram of the work flow of a vehicle-mounted terminal based on the Internet of Vehicles system in the embodiment of the present application, as shown in the figure, specifically:
  • step A1 the vehicle-mounted terminal is pre-installed with the root certificate of the authority before leaving the factory.
  • the vehicle-mounted terminal During the initialization process after leaving the factory, the vehicle-mounted terminal generates a key pair (ie, the vehicle-mounted terminal public key and the vehicle-mounted terminal private key).
  • the private key of the vehicle-mounted terminal is saved by the vehicle-mounted terminal itself and will not be leaked. It can be seen that no device other than the vehicle terminal can learn the private key of the vehicle terminal.
  • an algorithm can be used to generate a key pair, or an encryption chip can be used to generate a key pair, which is not limited here.
  • step A2 the vehicle-mounted terminal obtains its own CID and binds the vehicle-mounted terminal public key. Based on this, the vehicle-mounted terminal initiates a Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS) request or a Transport Layer Security (TLS) request to the authentication server of the authoritative organization to apply for the issuance of a certificate.
  • HTTPS Hyper Text Transfer Protocol over Secure Socket Layer
  • TLS Transport Layer Security
  • step A3 after receiving the request sent by the vehicle-mounted terminal, the authentication server of the authority can use the target private key (i.e., the root certificate private key) to digitally sign the CID and the vehicle-mounted terminal public key to form a certificate (i.e., the second Certificate).
  • the target private key i.e., the root certificate private key
  • step A4 the authentication server of the authoritative organization feeds back the certificate (ie, the second certificate) to the vehicle-mounted terminal through the HTTPS channel or TLS channel, thereby minimizing the risk that the vehicle-mounted terminal will be hijacked and obtain the wrong certificate. Based on this, the certificate (ie, the second certificate) is saved by the vehicle-mounted terminal.
  • step A5 after the vehicle-mounted terminal receives the certificate (i.e., the second certificate), it verifies whether the signature of the certificate (i.e., the second certificate) is correct through the root certificate pre-installed in step A1 to ensure that the certificate is legal. sex.
  • the vehicle-mounted terminal has a key pair bound to its own CID (that is, the vehicle-mounted terminal public key and the vehicle-mounted terminal private key) and the certificate system, and other visitors can communicate with it securely.
  • CID that is, the vehicle-mounted terminal public key and the vehicle-mounted terminal private key
  • the embodiment of this application provides a way for the second device to apply for a certificate from an authority.
  • the node device has the corresponding certificate.
  • the certificate is authenticated and can confirm the identity of the information sender. Therefore, in conjunction with the method of exchanging certificates between node devices, communication between devices can be made secure and trustworthy.
  • the second device after the second device receives the second certificate sent by the authentication server, it may also include:
  • the second device uses the target public key to decrypt the second certificate to obtain the second target signature, where the target public key and the target private key are key pairs generated by the authentication server;
  • the second device performs hash calculation on the second public key and the second device identification to obtain the second target digest
  • the second device stores the second certificate.
  • a way for the second device to verify the second certificate is introduced.
  • the second device is pre-installed with the root certificate of the authoritative organization before leaving the factory.
  • the root certificate includes the target public key, and the target public key and the target private key are keys generated by the authoritative organization (i.e., the authentication server). right.
  • the second certificate can be decrypted using the target public key to obtain the second target signature.
  • the second device needs to perform hash calculation on the plaintext second public key and the second device identification to obtain the second target digest. If the second target signature is consistent with the second target digest, it means that the second certificate received by the second device is a valid certificate, and therefore, the second device stores the second certificate locally.
  • the target public key is used to decrypt the second certificate to obtain the second target signature, that is:
  • signature_2 publickey_CA(DC_2)
  • signature_2 represents the second target signature.
  • publickey_CA represents the target public key generated by the authority.
  • DC_2 represents the second certificate.
  • Hash calculation is performed on the second public key and the second device identification to obtain the second target digest, which is:
  • digest_2 hash(publickey_2+CID);
  • digest_2 represents the second target digest.
  • hash() represents hash calculation.
  • publickey_2 represents the second public key.
  • CID represents the second device identification.
  • the second target signature ie signature_2
  • the second target digest ie digest_2
  • the embodiment of the present application provides a method for the second device to verify the second certificate.
  • the second device can verify the legitimacy of the second certificate. In this way, you can ensure the legitimacy of your local certificate and improve the security and reliability of communication.
  • the second device after the second device receives the first certificate sent by the first device, it may also include:
  • the second device uses the target public key to decrypt the first certificate and obtain the first digital signature, where the target public key is the public key generated by the authentication server;
  • the second device obtains the first public key to be verified and the first identification to be verified from the first certificate
  • the second device performs hash calculation on the first public key to be verified and the first identification to be verified to obtain the first message digest
  • the second device determines that the first certificate is valid. Certificate
  • the second device determines the first public key and the first device identification based on the first certificate, which may include:
  • the second device uses the first public key to be verified in the first certificate as the first public key, and uses the first identification to be verified in the first certificate as the first device identification.
  • a way for the second device to verify the first certificate is introduced.
  • the second device is pre-installed with the root certificate of the authority before leaving the factory, where the root certificate includes the target public key. Based on this, the second device can use the target public key to decrypt the first certificate to obtain the first digital signature.
  • the second device can obtain the first public key to be verified and the first identification to be verified in plain text from the first certificate, and then perform hash calculation on the first public key to be verified and the first identification to be verified to obtain the first message Summary. If the first message digest is consistent with the first digital signature, it means that the first certificate received by the second device is a valid certificate. Therefore, the second device can use the first public key to be verified in the first certificate as the first public key, and the first identification to be verified in the first certificate as the first device identification.
  • the target public key is used to decrypt the first certificate to obtain the first digital signature, that is:
  • signature_A publickey_CA(DC_A);
  • signature_A represents the first digital signature.
  • publickey_CA represents the target public key generated by the authority.
  • DC_A represents the first certificate.
  • Hash calculation is performed on the first public key to be verified and the first identification to be verified to obtain the first message digest, that is:
  • digest_A hash(publickey_A+MID_A);
  • digest_A represents the first message digest.
  • hash() represents hash calculation.
  • publickey_A represents the first public key to be verified.
  • MID_A represents the first identification to be verified.
  • the second device will not transmit data to the first device.
  • the embodiment of this application provides a method for the second device to verify the first certificate.
  • the second device can also verify the validity of the first certificate to prevent other devices from using counterfeit certificates to request data, thereby improving the security and reliability of communication.
  • the second device responds to the data access request sent by the first device and sends the target to the first device.
  • Data specifically may include:
  • the second device uses the second private key to decrypt the data access request to obtain the request data;
  • the second device obtains the original data according to the requested data
  • the second device uses the second private key to encrypt the original data to obtain the target data
  • the second device sends the target data to the first device so that the first device uses the second public key to pair the target Decrypt the data to obtain the original data;
  • the second device uses the second private key to decrypt the data access request to obtain the request data;
  • the second device obtains the original data according to the requested data
  • the second device uses the first public key to encrypt the original data and obtain the target data;
  • the second device sends the target data to the first device, so that the first device uses the first private key to decrypt the target data and obtain the original data;
  • the second device uses the first public key to decrypt the data access request to obtain the request data;
  • the second device obtains the original data according to the requested data
  • the second device uses the second private key to encrypt the original data to obtain the target data
  • the second device sends the target data to the first device, so that the first device uses the second public key to decrypt the target data and obtain the original data;
  • the second device uses the first public key to decrypt the data access request to obtain the request data;
  • the second device obtains the original data according to the requested data
  • the second device uses the first public key to encrypt the original data and obtain the target data;
  • the second device sends the target data to the first device, so that the first device uses the first private key to decrypt the target data and obtain the original data.
  • the second device locally stores the second private key, and the second device can obtain the first public key.
  • the first device locally stores the first private key, and the first device can obtain the second public key.
  • the first device is a mobile terminal and the second device is a vehicle-mounted terminal.
  • the first public key is the public key of the mobile terminal
  • the first private key is the private key of the mobile terminal
  • the second public key is the public key of the vehicle-mounted terminal
  • the second private key is the private key of the vehicle-mounted terminal.
  • the mobile terminal can encrypt the request data using the public key of the vehicle-mounted terminal to obtain the data access request. Therefore, the mobile terminal sends a data access request to the vehicle-mounted terminal, and the vehicle-mounted terminal can decrypt the data access request using the vehicle-mounted terminal's private key to obtain the requested data.
  • the vehicle-mounted terminal calls the corresponding driving data as original data according to the requested data. Then the vehicle-mounted terminal uses the vehicle-mounted terminal private key to encrypt the original data to obtain the target data.
  • the vehicle-mounted terminal sends target data to the mobile terminal, and the mobile terminal can use the vehicle-mounted terminal public key to decrypt the target data to obtain the original data.
  • the mobile terminal can encrypt the request data using the public key of the vehicle-mounted terminal to obtain the data access request. Therefore, the mobile terminal sends a data access request to the vehicle-mounted terminal, and the vehicle-mounted terminal can decrypt the data access request using the vehicle-mounted terminal's private key to obtain the requested data.
  • the vehicle-mounted terminal calls the corresponding driving data as original data according to the requested data. Then the vehicle-mounted terminal uses the mobile terminal public key to encrypt the original data to obtain the target data.
  • the vehicle-mounted terminal sends the target data to the mobile terminal, and the mobile terminal can decrypt the target data using the mobile terminal's private key to obtain the original data.
  • the mobile terminal can encrypt the request data using the mobile terminal private key to obtain the data access request. Therefore, the mobile terminal sends a data access request to the vehicle-mounted terminal, and the vehicle-mounted terminal can use the mobile terminal's public key to decrypt the data access request to obtain the requested data.
  • the vehicle-mounted terminal calls the corresponding driving data as original data according to the requested data. Then the vehicle-mounted terminal uses the vehicle-mounted terminal private key to encrypt the original data to obtain the target data.
  • the vehicle-mounted terminal sends target data to the mobile terminal, and the mobile terminal can use the vehicle-mounted terminal public key to decrypt the target data to obtain the original data.
  • the mobile terminal can encrypt the request data using the mobile terminal private key to obtain the data access request. Therefore, the mobile terminal sends a data access request to the vehicle-mounted terminal, and the vehicle-mounted terminal can use the mobile terminal's public key to decrypt the data access request to obtain the requested data.
  • the vehicle-mounted terminal calls the corresponding driving data as original data according to the requested data. Then the vehicle-mounted terminal uses the mobile terminal public key to encrypt the original data to obtain the target data.
  • the vehicle-mounted terminal sends the target data to the mobile terminal, and the mobile terminal can decrypt the target data using the mobile terminal's private key to obtain the original data.
  • the embodiments of this application provide multiple methods for secure communication based on different keys.
  • the second device can select the corresponding key for encryption or decryption according to the actual situation, thereby increasing the feasibility and flexibility of the solution.
  • the second device determines the first public key and the first device identification based on the first certificate, May also include:
  • the second device obtains the first device identification set stored in the second device, where the first device identification set includes M first registered device identifications that have been registered for the second device, where M is an integer greater than or equal to 1;
  • the second device determines that the first device identification is a registered identification.
  • a method of determining whether the first device identity belongs to a registered identity is introduced.
  • the first device can register the first device identification into the second device through the Bluetooth protocol or other secure channels. Based on this, the second device needs to match the received first device identification. If the matching is successful, , it means that the first device is a device that has been registered before, that is, it is determined that the first device identifier is a registered identifier.
  • the first device is a mobile terminal and the second device is a vehicle-mounted terminal.
  • the user can bind M MIDs to the vehicle-mounted terminal, that is, M mobile terminals are allowed to communicate with one vehicle-mounted terminal.
  • M mobile terminals are allowed to communicate with one vehicle-mounted terminal.
  • Table 1 is an illustration of M MIDs that have been registered to the vehicle-mounted terminal.
  • the same vehicle-mounted terminal ie, the same CID
  • the vehicle-mounted terminal with CID "CID_0001" has three registered first registration device identifiers, where the three first registration device identifiers are MID_0235659, MID_0254981 and MID_0264154 respectively.
  • the embodiment of the present application provides a way to determine whether the first device identity belongs to a registered identity.
  • the first device can register its first device identification into the second device, and the second device can store it.
  • verifying the device identity it can be determined whether it is the same as the previously registered identity, thereby improving the security and reliability of device communication.
  • another optional embodiment provided by the embodiment of this application may also include:
  • the second device displays the first device identification set
  • the second device responds to the deletion operation of the K first registered device identities in the first device identity set, removes the K first registered device identities from the first device identity set, and obtains an updated first device identity set, where , K is an integer greater than or equal to 1 and less than or equal to M;
  • the second device displays the logo to add controls
  • the second device responds to the selection operation of the logo adding control and displays the logo adding area
  • the second device In response to the input operation in the identification adding area, the second device adds T first registered device identifications to the first device identification set to obtain an updated first device identification set, where T is an integer greater than or equal to 1.
  • methods of binding and unbinding device identities are introduced. It can be known from the foregoing embodiments that the second device also supports the function of displaying the first device identification set. Based on this, the CID and the MID can be bound or unbound. The following will take the second device as a vehicle-mounted terminal as an example to introduce the process of binding and unbinding the identifier with the help of illustrations.
  • Figure 5 is a schematic interface diagram for unbinding a terminal identity in an embodiment of the present application.
  • B1 is used to indicate that the binding relationship with "CID_0001 "Bound MID list, among which there are currently 2 MIDs bound to "CID_0001”.
  • B2 is used to indicate the selected MID. Since only one MID is selected here, K is equal to 1. It is understandable that the method of selecting MID includes but is not limited to long press, double click, click on the control, etc., which are not limited here.
  • B3 is used to indicate removal of the control. After the user selects K MIDs, click the delete control indicated by B3 to display the interface shown in (B) in Figure 5. At this time, the selected "MID_0235659" has been unbound from "CID_0001" relation.
  • Figure 6 is a schematic interface diagram for adding a terminal identity binding relationship in an embodiment of the present application.
  • C1 is used to indicate that it has been linked to "CID_0001 "Bound MID list, among which there are currently 2 MIDs bound to "CID_0001”.
  • C2 is used to indicate the added control.
  • the logo adding control indicated by C2 the logo adding area indicated by C3 can be displayed. Based on this, the user can enter the corresponding MID in the identification adding area, for example, "MID_0264154". Since only one MID is added here, T equals 1.
  • the interface shown in Figure 6 (B) will be displayed. At this time, the selected "MID_0264154" has been successfully bound to "CID_0001".
  • the embodiment of the present application provides a method of binding and binding device identities.
  • the previously bound MID can be deleted in the vehicle-mounted terminal to avoid being used by criminals.
  • the results are visualized on the vehicle-mounted terminal, so that even malicious intrusions can be detected in time and malicious access parties can be eliminated.
  • the second device receives the first certificate sent by the first device and sends the first certificate to the first device.
  • the second device When the second device and the first device activate the Bluetooth function, the second device establishes a Bluetooth connection with the first device, so that a communication connection is established between the second device and the first device;
  • the second device When the second device and the first device are connected to the same wireless hotspot, the second device establishes a communication connection with the first device;
  • the second device displays a QR code, where the QR code includes the second device identification
  • the second device When the first device scans the QR code, the second device establishes a communication connection with the first device;
  • the second device displays an information input area
  • the second device responds to the first device identifier input for the information input area and establishes a communication connection with the first device.
  • various ways of establishing a communication connection are described. It can be known from the foregoing embodiments that data transmission can be performed after the first device and the second device establish a communication connection. Therefore, the following takes the first device as a mobile terminal and the second device as a vehicle-mounted terminal as an example to illustrate the method of establishing a communication connection. .
  • FIG. 7 is a communication schematic diagram of an intelligent network-connected car in an embodiment of the present application.
  • an intelligent network-connected car usually It has mobile hotspot (Wireless Fidelity, Wi-Fi) function, Bluetooth function, camera function, Global Positioning System (Global Positioning System, GPS) function, radar function, communication function, etc.
  • Wi-Fi Wireless Fidelity
  • GPS Global Positioning System
  • the vehicle-mounted terminal can have built-in Wi-Fi function, Bluetooth function, GPS function, communication function, etc.
  • the vehicle-mounted terminal and the mobile terminal can establish a connection using near field communication.
  • both the vehicle-mounted terminal and the mobile terminal enable the Bluetooth function and establish a communication connection based on the Bluetooth protocol.
  • the vehicle-mounted terminal activates the hotspot function, and the mobile terminal accesses the hotspot corresponding to the vehicle-mounted terminal.
  • the vehicle-mounted terminal and the mobile terminal access the same wireless hotspot, that is, they establish a communication connection through the same Wi-Fi network.
  • the vehicle-mounted terminal displays a QR code that can be scanned by a mobile terminal.
  • Figure 8 is a schematic diagram of terminal communication based on a QR code in an embodiment of the present application.
  • a QR code indicated by D1 is displayed on the vehicle terminal, where the two
  • the QR code contains the CID of the vehicle terminal, which can be obtained by scanning the code on the mobile terminal through the vehicle owner's APP. Based on this, the mobile terminal can scan the QR code. After the scan is successful, a communication connection between the two devices is established.
  • the vehicle-mounted terminal displays an information input area for users to manually enter the MID (for example, car owner account number, system-assigned identification number or mobile phone number, etc.).
  • MID for example, car owner account number, system-assigned identification number or mobile phone number, etc.
  • Figure 9 is a schematic diagram of terminal communication based on manual input of information in an embodiment of the present application.
  • E1 is used to indicate the information input area, and the user can enter the information indicated by E1.
  • E1 Enter the MID (ie, the first device identification) in the area.
  • click the confirmation control indicated by E2 to establish a communication connection between the two devices.
  • embodiments of the present application provide multiple ways to establish communication connections.
  • using near field communication to add the trusted counterparty as the designated access party can avoid tampering and intrusion in the case of public network communication.
  • asymmetric encryption and certificate systems provide a great guarantee for the security and credibility of data communication, and this application can also adopt a more lightweight approach. That is, the agreed key can be simply exchanged during the near field communication process. After that, the key is directly used for encrypted communication between the mobile terminal and the vehicle-mounted terminal, and the key is no longer transmitted in the communication link, which also has many advantages. Good safety effect.
  • the randomness and complexity of the key can also be checked, and the car owner can be reminded to change it regularly.
  • the data transmission method in this embodiment of the application can be performed by a terminal.
  • the terminal can be a mobile terminal, including:
  • the first device sends the first certificate to the second device, and receives the second certificate sent by the second device;
  • the first device after the first device establishes a communication connection with the second device, the first device sends a first certificate to the second device, and the second device sends a second certificate to the first device.
  • the first device may be a mobile terminal (for example, a mobile phone, a tablet or a computer, etc.), and the second device may be a vehicle-mounted terminal.
  • step 210 and step 110 are similar and will not be described again here.
  • the first device determines the second public key and the second device identification based on the second certificate, where the second public key and the second private key are generated by the second device.
  • the key pair, the second device identification is the identification corresponding to the second device;
  • the second device verifies the validity of the first certificate, and the first device verifies the validity of the second certificate. If both the first certificate and the second certificate are valid certificates, the second device may determine the public key in the first certificate as the first public key, and determine the device identification in the first certificate as the first device identification. Similarly, the first device may determine the public key in the second certificate as the second public key, and determine the device identification in the second certificate as the second device identification.
  • the first public key and the first private key are a key pair generated by the first device, and the first device identifier is a corresponding identifier of the first device.
  • the second public key and the second private key are a key pair generated by the second device, and the second device identifier is a corresponding identifier of the second device.
  • step 220 and step 120 are similar and will not be described again here.
  • the first device sends a data access request to the second device, where the data access request is that the first device uses the second public key or the first private key. Obtained through encryption, the first public key and the first private key are the key pairs generated by the first device, and the first device identifier is the corresponding identifier of the first device;
  • the second device detects the registration status of the first device identity, and the first device detects the registration status of the second device identity. If the first device identity and the second device identity are both registered identities, the first device can encrypt the data access request using the second public key or the first private key. Based on this, the first device sends a data access request to the second device.
  • step 230 and step 130 are similar and will not be described again here.
  • the first device receives the target data sent by the second device, where the target data is encrypted by the second device using the first public key or the second private key.
  • the second device responds to the data access request sent by the first device and uses the first public key or the second private key to encrypt the original data, thereby obtaining the target data. Then, the second device sends the target data to the first device.
  • step 240 and step 140 are similar and will not be described again here.
  • the embodiment of the present application provides a data transmission method.
  • the key and certificate system is extended to the decentralized P2P network, so that terminals in the P2P network (for example, vehicle-mounted terminals and mobile terminals) can use locally stored keys and certificates to achieve identity. certification, This will help improve the security, privacy and reliability of data transmission between terminals.
  • the first device before the first device sends the first certificate to the second device, it may also include:
  • the first device obtains the first public key and the first private key
  • the first device stores the first private key
  • the first device sends the first public key and the first device identification to the authentication server, so that the authentication server uses the target private key to sign the first public key and the first device identification to obtain the first certificate;
  • the first device receives the first certificate sent by the authentication server.
  • a method for a first device to apply for a certificate from an authority is introduced.
  • the first device before the first device sends the first certificate to the second device, it needs to apply for the first certificate from the authority.
  • the first device generates a key pair, namely a first public key and a first private key.
  • the first device needs to store the first private key locally.
  • the first device needs to send the first public key and the first device identification to the authentication server of the authority, and the authentication server uses its own target private key to sign the first public key and the first device identification, and obtains the third One certificate.
  • the authentication server feeds back the first certificate to the first device.
  • Figure 11 is a schematic workflow diagram of a mobile terminal based on the Internet of Vehicles system in an embodiment of the present application, as shown in the figure, specifically:
  • step F1 the user downloads the APP to the mobile terminal, and the root certificate of the authoritative organization is built into the APP.
  • This process can be provided by the APP's Software Development Kit (SDK).
  • SDK Software Development Kit
  • the corresponding key pair ie, mobile terminal public key and mobile terminal private key
  • MIDs for example, car owner account, system assigned identification number or mobile phone number, etc.
  • the mobile terminal private key is kept by the mobile terminal itself and will not be leaked. It can be seen that except for the mobile terminal, no one can know the private key of the mobile terminal.
  • step F2 the mobile terminal binds the MID to the mobile terminal public key. Based on this, the mobile terminal initiates an HTTPS request or TLS request to the authentication server of the authority to apply for the issuance of a certificate.
  • step F3 after receiving the request sent by the mobile terminal, the authentication server of the authority can use the target private key (i.e., the root certificate private key) to digitally sign the MID and the mobile terminal public key to form a certificate (i.e., the first certificate ).
  • the target private key i.e., the root certificate private key
  • the mobile terminal public key i.e., the first certificate
  • step F4 the authentication server of the authority feeds back the certificate (ie, the first certificate) to the mobile terminal through the HTTPS channel or TLS channel, thereby minimizing the risk that the mobile terminal will be hijacked and obtain the wrong certificate. Based on this, the certificate (ie, the first certificate) is saved by the mobile terminal.
  • step F5 after the mobile terminal receives the certificate (i.e., the first certificate), it verifies whether the signature of the certificate (i.e., the first certificate) is correct through the root certificate pre-installed in step F1 to ensure that the certificate is legal. sex.
  • the mobile terminal has a key pair (i.e., mobile terminal public key and mobile terminal private key) bound to its own MID and a certificate system, and other visitors can communicate with it securely.
  • a key pair i.e., mobile terminal public key and mobile terminal private key
  • the mobile terminal APP may clear data. Therefore, when logging in again, you need to re-verify whether the key pair (that is, the mobile terminal public key and the mobile terminal private key) and the certificate exist and are legal. If it does not exist or is illegal, it needs to be regenerated.
  • the security of the APP is mainly ensured by the APP, that is, it mainly ensures that its private key cannot be obtained, and the encryption chip that comes with the APP system is used as much as possible.
  • the embodiment of this application provides a way for the first device to apply for a certificate from an authority.
  • the node device has the corresponding certificate, which is authenticated and can confirm the identity of the information sender. Therefore, in conjunction with the method of exchanging certificates between node devices, communication between devices can be made secure and trustworthy.
  • the first device after the first device receives the first certificate sent by the authentication server, it may also include:
  • the first device uses the target public key to decrypt the first certificate to obtain the first target signature, where the target public key and the target private key are key pairs generated by the authentication server;
  • the first device performs hash calculation on the first public key and the first device identification to obtain the first target digest
  • the first device stores the first certificate.
  • a method for a first device to verify a first certificate is introduced.
  • the first device has a root certificate of an authoritative organization built into the downloaded APP.
  • the root certificate includes the target public key, and the target public key and the target private key are keys generated by the authoritative organization (i.e., the authentication server). Key pair.
  • the first certificate can be decrypted using the target public key to obtain the first target signature.
  • the first device needs to perform hash calculation on the first public key in plain text and the first device identification to obtain the first target digest. If the first target signature is consistent with the first target digest, it means that the first certificate received by the first device is a valid certificate, and therefore, the first device stores the first certificate locally.
  • the first certificate is decrypted using the target public key to obtain the first target signature, that is:
  • signature_1 publickey_CA(DC_1);
  • signature_1 represents the first target signature.
  • publickey_CA represents the target public key generated by the authority.
  • DC_1 represents the first certificate.
  • Hash calculation is performed on the first public key and the first device identification to obtain the first target digest, which is:
  • digest_1 hash(publickey_1+MID);
  • digest_1 represents the first target digest.
  • hash() represents hash calculation.
  • publickey_1 represents the first public key.
  • MID represents the first device identification.
  • the first target signature ie signature_1
  • the first target digest ie digest_1
  • the embodiment of the present application provides a method for the first device to verify the first certificate.
  • the first device can also verify the legitimacy of the first certificate. In this way, you can ensure the legitimacy of your local certificate, thus improving the security and reliability of communication.
  • the first device after the first device receives the second certificate sent by the second device, it may also include:
  • the first device uses the target public key to decrypt the second certificate to obtain the second digital signature, where the target public key is the public key generated by the authentication server;
  • the first device obtains the second public key to be verified and the second identification to be verified from the second certificate;
  • the first device performs hash calculation on the second public key to be verified and the second identification to be verified to obtain the second message digest;
  • the first device determines that the second certificate is a valid certificate
  • the first device determines the second public key and the second device identification based on the second certificate, which may include:
  • the first device uses the second public key to be verified in the second certificate as the second public key, and uses the second identification to be verified in the second certificate as the second device identification.
  • a method for a first device to verify a second certificate is introduced.
  • the first device has a root certificate of an authoritative organization built into the downloaded APP, where the root certificate includes the target public key. Based on this, the target public key can be used to decrypt the second certificate to obtain the second digital signature.
  • the first device can obtain the second public key to be verified and the second identification to be verified in plain text from the second certificate, and then perform hash calculation on the second public key to be verified and the second identification to be verified to obtain the second message. Summary. If the second message digest is consistent with the second digital signature, it means that the second certificate received by the first device is a valid certificate. Therefore, the first device can use the second public key to be verified in the second certificate as the first public key, and the second identification to be verified in the second certificate as the second device identification.
  • the target public key is used to decrypt the second certificate to obtain the second digital signature, that is:
  • signature_B publickey_CA(DC_B);
  • signature_B represents the second digital signature.
  • publickey_CA represents the target public key generated by the authority.
  • DC_B represents the second certificate.
  • Hash calculation is performed on the second public key to be verified and the second identification to be verified to obtain the second message digest, that is:
  • digest_B hash(publickey_B+CID_B);
  • digest_B represents the second message digest.
  • hash() represents hash calculation.
  • publickey_B represents the second public key to be verified.
  • CID_B represents the second identification to be verified.
  • the second digital signature ie, signature_B
  • the second message digest ie, digest_B
  • the embodiment of this application provides a method for the first device to verify the second certificate.
  • the first device After the first device obtains the second certificate, it can also verify the validity of the second certificate to prevent other devices from using counterfeit certificates to request data, thereby improving the security and reliability of communication.
  • the first device before the first device sends the data access request to the second device, it may also include:
  • the first device uses the second public key to encrypt the request data and obtains the data access request;
  • the first device After the first device sends a data access request to the second device, it may also include:
  • the first device sends a data access request to the second device, so that the second device uses the second private key to decrypt the data access request and obtain the requested data;
  • the first device Before sending the data access request to the second device, the first device may also include:
  • the first device uses the first private key to encrypt the request data to obtain the data access request;
  • the first device After the first device sends a data access request to the second device, it may also include:
  • the first device sends a data access request to the second device, so that the second device uses the first public key to decrypt the data access request and obtain the requested data;
  • the first device After the first device receives the target data sent by the second device, it may also include:
  • the first device uses the second public key to decrypt the target data and obtain the original data
  • the first device After the first device receives the target data sent by the second device, it may also include:
  • the first device uses the first private key to decrypt the target data to obtain the original data.
  • multiple ways of secure communication based on different keys are introduced. It can be known from the foregoing embodiments that the first device locally stores the first private key, and the first device can obtain the second public key. The second device locally stores the second private key, and the second device can obtain the first public key.
  • the embodiments of this application provide multiple methods for secure communication based on different keys.
  • the first device can select a corresponding key for encryption or decryption according to the actual situation, thereby increasing the feasibility and flexibility of the solution.
  • the first device obtains a second device identification set stored by the first device, where the second device identification set includes N second registered device identifications that have been registered for the first device, and N is an integer greater than or equal to 1;
  • the first device determines that the second device identification is a registered identification.
  • a method of determining whether a device identity belongs to a registered identity is introduced.
  • the second device can register the second device identification into the first device through the Bluetooth protocol or other secure channels. Based on this, the first device needs to match the received second device identification. If the matching is successful, , it means that the second device is a device that has been registered before, that is, it is determined that the second device identification is a registered identification.
  • the first device is a mobile terminal and the second device is a vehicle-mounted terminal.
  • the user can bind N CIDs to the mobile terminal, that is, N vehicle-mounted terminals are allowed to communicate with one mobile terminal.
  • N vehicle-mounted terminals are allowed to communicate with one mobile terminal.
  • Table 2 is an illustration of N CIDs that have been registered to the mobile terminal.
  • the same mobile terminal ie, the same MID
  • the mobile terminal with the MID "MID_0235659" has two registered second registration device identities, where the two second registration device identities are CID_0001 and CID_0006 respectively.
  • the embodiment of the present application provides a way to determine whether a device identity belongs to a registered identity.
  • the second device can register its own second device identification into the first device, and the APP in the first device can save it.
  • the APP in the first device can save it.
  • verifying the device identity it can be determined whether it is the same as the previously registered identity, thus improving the security and reliability of device communication.
  • the first device sends the first certificate to the second device, and receives the first certificate sent by the second device.
  • the first device When the second device and the first device activate the Bluetooth function, the first device establishes a Bluetooth connection with the second device, so that a communication connection is established between the second device and the first device;
  • the first device When the second device and the first device are connected to the same wireless hotspot, the first device establishes a communication connection with the second device;
  • the first device scans the QR code displayed on the second device to establish a communication connection with the first device, where the QR code includes the second device identification.
  • data transmission can be performed after the first device and the second device establish a communication connection.
  • data transmission can be performed after the first device and the second device establish a communication connection.
  • embodiments of the present application provide multiple ways to establish communication connections.
  • using near field communication to add the trusted counterparty as the designated access party can avoid tampering and intrusion in the case of public network communication.
  • asymmetric encryption and certificate systems provide a great guarantee for the security and credibility of data communication, and this application can also adopt a more lightweight approach. That is, the agreed key can be simply exchanged during the near field communication process. After that, the mobile terminal and the vehicle-mounted terminal directly use the key to encrypt the communication, and the key is no longer transmitted in the communication link, which also has good performance. Safety effect.
  • the randomness and complexity of the key can also be checked, and the car owner can be reminded to change it regularly.
  • Figure 12 is a schematic diagram of an interaction process based on the Internet of Vehicles system in the embodiment of the present application. As shown in the figure, specifically:
  • step G1 the vehicle-mounted terminal is pre-installed with the root certificate of the authority before leaving the factory.
  • the vehicle-mounted terminal public key and the vehicle-mounted terminal private key are generated. Among them, the private key of the vehicle-mounted terminal is saved by the vehicle-mounted terminal itself and will not be leaked.
  • step G2 the vehicle-mounted terminal obtains its own CID and binds the vehicle-mounted terminal public key. Based on this, the vehicle-mounted terminal initiates an HTTPS request or TLS request to the authentication server of the authoritative organization to apply for the issuance of a certificate.
  • step G3 after receiving the request sent by the vehicle-mounted terminal, the authentication server of the authority can use the target private key (ie, the root certificate private key) to digitally sign the CID and the vehicle-mounted terminal public key to form a second certificate.
  • the target private key ie, the root certificate private key
  • step G4 the authentication server of the authoritative organization feeds back the second certificate to the vehicle-mounted terminal through the HTTPS channel or TLS channel, and the vehicle-mounted terminal saves the second certificate.
  • step G5 after receiving the second certificate, the vehicle-mounted terminal verifies whether the signature of the second certificate is correct through the root certificate pre-installed in step G1, thereby ensuring the legitimacy of the second certificate.
  • step G6 the user downloads the APP to the mobile terminal, and the root certificate of the authoritative organization is built into the APP.
  • This process can be provided by the APP's SDK.
  • the corresponding mobile terminal public key and mobile terminal private key are generated based on different MIDs (for example, car owner account or mobile phone number, etc.).
  • the mobile terminal private key is kept by the mobile terminal itself and will not be leaked.
  • step G7 the mobile terminal binds the MID with the mobile terminal public key. Based on this, the mobile terminal initiates an HTTPS request or TLS request to the authentication server of the authority to apply for the issuance of a certificate.
  • the authentication server of the authority may use the target private key (ie, the root certificate private key) to digitally sign the MID and the mobile terminal public key to form a first certificate.
  • the target private key ie, the root certificate private key
  • step G9 the authentication server of the authority feeds back the first certificate to the mobile terminal through the HTTPS channel or TLS channel, and the mobile terminal saves the first certificate.
  • step G10 after receiving the first certificate, the mobile terminal verifies whether the signature of the first certificate is correct through the root certificate pre-installed in step G6, thereby ensuring the legitimacy of the first certificate.
  • the relationship between the vehicle-mounted terminal and the mobile terminal i.e., the car owner APP
  • This step is usually performed offline by the car owner after purchasing and picking up the car for the first time. Data is transmitted through Bluetooth protocols, etc., so the security risk is relatively small.
  • step G11 the vehicle-mounted terminal exchanges the CID to the car owner APP of the mobile terminal through the Bluetooth protocol or other secure channels, and the car owner APP saves it.
  • step G12 the car owner APP of the mobile terminal exchanges the MID to the vehicle-mounted terminal through the Bluetooth protocol or other secure channels, and the vehicle-mounted terminal saves it.
  • the mobile terminal and the vehicle-mounted terminal exchange certificates with each other when communicating. Both parties verify the identity of the other party and determine whether it is the same as the previously registered identity. The identity is verified by the root certificate and cannot be forged. After both parties have verified their identities, that is, exchanged keys with each other, they can communicate securely.
  • This application solves the security and trust requirements for direct connection between car owners and cars through the P2P network in the Internet of Vehicles.
  • the key and certificate system is expanded, so that both vehicle-mounted terminals and mobile terminals are equivalent to the security and trust level of servers deployed in the computer room.
  • car owners usually do not take the initiative to damage their cars.
  • the communication spaces between car owners and car owners are isolated from each other and will not invade each other. Based on this, the secure communication needs of vehicle-mounted terminals and mobile terminals are ensured, and the high privacy protection standards required by regulatory requirements are met.
  • Figure 13 is a schematic diagram of a data transmission device in the embodiment of the present application.
  • the data transmission device 30 includes:
  • the transceiver module 310 is configured to receive the first certificate sent by the first device, and send the second certificate to the first device;
  • the determination module 320 is configured to determine the first public key and the first device identification according to the first certificate if the first certificate and the second certificate are both valid certificates, wherein the first public key and the first private key are the first device identifiers.
  • the first device identifier is the identifier corresponding to the first device;
  • the transceiver module 310 is also configured to receive a data access request sent by the first device if both the first device identification and the second device identification are registered identifications, wherein the data access request is that the first device adopts the second public key or the third public key.
  • a private key is encrypted, the second public key is obtained by the first device based on the second certificate, the second public key and the second private key are a key pair generated by the second device, and the second device is identified as the second device corresponding identification;
  • the transceiver module 310 is also configured to respond to the data access request sent by the first device and send target data to the first device, where the target data is encrypted by the second device using the first public key or the second private key.
  • the data transmission device 30 further includes an acquisition module 330 and a storage module 340;
  • Obtain module 330 configured to obtain the second public key before sending the second certificate to the first device and second private key;
  • Storage module 340 used to store the second private key
  • the transceiver module 310 is also used to send the second public key and the second device identification to the authentication server, so that the authentication server uses the target private key to sign the second public key and the second device identification to obtain the second certificate;
  • the transceiver module 310 is also used to receive the second certificate sent by the authentication server.
  • the data transmission device 30 further includes a decryption module 350 and a generation module 360;
  • the decryption module 350 is configured to decrypt the second certificate using the target public key after receiving the second certificate sent by the authentication server, and obtain the second target signature, where the target public key and the target private key are key pairs generated by the authentication server. ;
  • the generation module 360 is used to perform hash calculation on the second public key and the second device identification to obtain the second target digest
  • the storage module 340 is also configured to store the second certificate if the second target signature is consistent with the second target digest.
  • the decryption module 350 is also configured to decrypt the first certificate using the target public key after receiving the first certificate sent by the first device, and obtain the first digital signature, where the target public key is the public key generated by the authentication server;
  • the acquisition module 330 is also used to acquire the first public key to be verified and the first identification to be verified from the first certificate;
  • the generation module 360 is also used to perform hash calculation on the first public key to be verified and the first identification to be verified to obtain the first message digest;
  • the determination module 320 is also configured to determine that the first certificate is a valid certificate if the first message digest is consistent with the first digital signature;
  • the determination module 320 is specifically configured to use the first public key to be verified in the first certificate as the first public key, and the first identification to be verified in the first certificate as the first device identification.
  • the transceiver module 310 is specifically configured to use the second private key to decrypt the data access request to obtain the requested data if the data access request is encrypted by the first device using the second public key; if the data access request is the The first device uses the first private key to encrypt the data, and then uses the first public key to decrypt the data access request to obtain the request data;
  • a public key encrypts the original data to obtain the target data
  • the acquisition module 330 is also configured to obtain the first device identity set stored by the second device after determining the first public key and the first device identity according to the first certificate, where the first device identity set includes the first device identity set that has been registered for the second device.
  • M first registered device identifiers, M is an integer greater than or equal to 1;
  • the determination module 320 is also configured to determine that the first device identity is a registered identity if the first device identity successfully matches a first registered device identity in the first device identity set.
  • the data transmission device 30 further includes a display module 370 and a processing module 380;
  • the display module 370 is used to display the first device identification set
  • the processing module 380 is configured to respond to the deletion operation of the K first registered device identities in the first device identity set, remove the K first registered device identities from the first device identity set, and obtain the updated first device identity.
  • K is an integer greater than or equal to 1 and less than or equal to M;
  • the display module 370 is also used to display the logo adding control
  • the display module 370 is also used to display the logo adding area in response to the selection operation of the logo adding control;
  • the processing module 380 is also configured to respond to the input operation for the identity adding area, add T first registered device identities to the first device identity set, and obtain an updated first device identity set, where T is greater than or equal to 1. integer.
  • the data transmission device 20 further includes a communication module 390;
  • the communication module 390 is configured to receive the first certificate sent by the first device and establish a Bluetooth connection with the first device when the second device and the first device activate the Bluetooth function before sending the second certificate to the first device. Establish a communication connection between the second device and the first device;
  • the communication module 390 is also used to receive the first certificate sent by the first device and establish a communication connection with the first device when the second device and the first device are connected to the same wireless hotspot before sending the second certificate to the first device. ;
  • the display module 370 is also used to receive the first certificate sent by the first device, and send the first certificate to the first device. Before sending the second certificate, display the QR code, where the QR code includes the second device identification;
  • the communication module 390 is also used to establish a communication connection with the first device when the first device scans the QR code;
  • the display module 370 is also configured to receive the first certificate sent by the first device and display the information input area before sending the second certificate to the first device;
  • the communication module 390 is also configured to respond to the first device identification input for the information input area and establish a communication connection with the first device.
  • Figure 14 is a schematic diagram of another embodiment of the data transmission device in the embodiment of the present application.
  • the data transmission device 40 includes:
  • the transceiver module 410 is used to send the first certificate to the second device and receive the second certificate sent by the second device;
  • the determination module 420 is configured to determine the second public key and the second device identification according to the second certificate if the first certificate and the second certificate are both valid certificates, wherein the second public key and the second private key are the second device identifiers.
  • the second device identifier is the identifier corresponding to the second device;
  • the transceiver module 410 is configured to send a data access request to the second device if the first device identifier and the second device identifier are both registered identifiers, where the data access request is that the first device uses the second public key or the first private key. Obtained by key encryption, the first public key and the first private key are key pairs generated by the first device, and the first device identifier is the corresponding identifier of the first device;
  • the transceiver module 410 is configured to receive target data sent by the second device, where the target data is encrypted by the second device using the first public key or the second private key.
  • the data transmission device 40 further includes an acquisition module 430 and a storage module 440;
  • the acquisition module 430 is used to acquire the first public key and the first private key before sending the first certificate to the second device;
  • Storage module 440 used to store the first private key
  • the transceiver module 410 is also used to send the first public key and the first device identification to the authentication server, so that the authentication server uses the target private key to sign the first public key and the first device identification to obtain the first certificate;
  • the transceiver module 410 is also used to receive the first certificate sent by the authentication server.
  • the data transmission device 40 further includes a decryption module 450 and a generation module 460;
  • the decryption module 450 is configured to decrypt the first certificate using the target public key after receiving the first certificate sent by the authentication server, and obtain the first target signature, where the target public key and the target private key are key pairs generated by the authentication server. ;
  • the generation module 460 is used to perform hash calculation on the first public key and the first device identification to obtain the first target digest;
  • the storage module 440 is also configured to store the first certificate if the first target signature is consistent with the first target digest.
  • the decryption module 450 is also configured to decrypt the second certificate using the target public key after receiving the second certificate sent by the second device, and obtain the second digital signature, where the target public key is the public key generated by the authentication server;
  • the acquisition module 430 is also used to acquire the second public key to be verified and the second identity to be verified from the second certificate;
  • the generation module 460 is also used to perform hash calculation on the second public key to be verified and the second identification to be verified to obtain the second message digest;
  • the determination module 420 is also configured to determine that the second certificate is a valid certificate if the second message digest is consistent with the second digital signature;
  • the determination module 420 is specifically configured to use the second public key to be verified in the second certificate as the second public key, and the second identification to be verified in the second certificate as the second device identification.
  • the data transmission device 40 further includes an encryption module 470;
  • the encryption module 470 is used to encrypt the request data using the second public key to obtain the data access request before sending the data access request to the second device; or, use the first private key to encrypt the request data to obtain the data access request.
  • the transceiver module 410 is also configured to send a data access request to the second device after sending the data access request to the second device, so that the second device decrypts the data access request to obtain the requested data. If the data access request uses the If the data access request is encrypted with the second public key, then the second device uses the second private key to decrypt the data access request. If the data access request is encrypted with the first private key, then The second device uses the first public key to decrypt the data access request;
  • the decryption module 450 is also used to receive the target data sent by the second device. If the target data is obtained by the second device using the second private key to encrypt the original data, use the second public key to decrypt the target data to obtain Original data; if the target data is obtained by the second device using the first public key to encrypt the original data, then the first private key is used to decrypt the target data to obtain the original data.
  • the acquisition module 430 is also configured to determine the second public key and the second device identification according to the second certificate. Then, obtain the second device identification set stored by the first device, where the second device identification set includes N second registered device identifications that have been registered for the first device, and N is an integer greater than or equal to 1;
  • the determination module 420 is also configured to determine that the second device identity is a registered identity if the second device identity successfully matches a second registered device identity in the second device identity set.
  • the data transmission device 40 further includes a communication module 480;
  • the communication module 480 is configured to send the first certificate to the second device and before receiving the second certificate sent by the second device, when the second device starts the Bluetooth function with the first device, establish a Bluetooth connection with the second device so that Establish a communication connection between the second device and the first device;
  • the communication module 480 is also used to send the first certificate to the second device and establish a communication connection with the second device when the second device and the first device are connected to the same wireless hotspot before receiving the second certificate sent by the second device. ;
  • the communication module 480 is also configured to send the first certificate to the second device, and before receiving the second certificate sent by the second device, scan the QR code displayed on the second device to establish a communication connection with the first device, wherein, The QR code includes a second device identification.
  • Embodiments of the present application also provide a data transmission device that can be deployed on a terminal, as shown in Figure 15.
  • a data transmission device that can be deployed on a terminal, as shown in Figure 15.
  • the terminal is a mobile phone as an example for explanation:
  • FIG. 15 shows a block diagram of a partial structure of a mobile phone related to the terminal provided by the embodiment of the present application.
  • the mobile phone includes: radio frequency (RF) circuit 510, memory 520, input unit 530 (including touch panel 531 and other input devices 532), display unit 540 (including display panel 541), sensor 550, audio Circuit 560 (connecting speaker 561 and microphone 562), wireless fidelity (WiFi) module 570, processor 580, power supply 590 and other components.
  • RF radio frequency
  • the memory 520 can be used to store software programs and modules.
  • the processor 580 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 520 .
  • the memory 520 may mainly include a storage program area and a storage data area, wherein the storage program area may store the operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the storage data area may store the program based on Data created by the use of mobile phones (such as audio data, phone books, etc.), etc.
  • memory 520 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other Volatile solid-state memory devices.
  • the processor 580 is the control center of the mobile phone, using various interfaces and lines to connect various parts of the entire mobile phone, and executing software programs and/or modules stored in the memory 520 by running or executing them, and calling data stored in the memory 520.
  • the processor 580 may include one or more processing units; optionally, the processor 580 may integrate an application processor and a modem processor, where the application processor mainly processes the operating system, user interface and application programs. etc., the modem processor mainly handles wireless communications. It can be understood that the above modem processor may not be integrated into the processor 580 .
  • the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.
  • the steps performed by the terminal in the above embodiment may be based on the terminal structure shown in FIG. 15 .
  • An embodiment of the present application also provides a computer device, including a memory and a processor.
  • the memory stores a computer program.
  • the processor executes the computer program, it implements the steps of the methods described in the foregoing embodiments.
  • Embodiments of the present application also provide a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed by a processor, the steps of the method described in each of the foregoing embodiments are implemented.
  • the embodiments of the present application also provide a computer program product, which includes a computer program.
  • a computer program product which includes a computer program.
  • the steps of the method described in each of the foregoing embodiments are implemented.

Abstract

本申请公开了一种数据传输的方法,可应用领域包括但不限于地图领域、交通领域、自动驾驶领域、车载场景等，应用场景至少包括各类终端，如：手机、电脑、车载终端等。本申请包括接收第一设备发送的第一证书，并向第一设备发送第二证书；若第一证书和第二证书均为有效证书，则根据第一证书确定第一公钥和第一设备标识；若第一设备标识和第二设备标识均为已注册标识，则接收第一设备发送的数据访问请求；响应第一设备发送的数据访问请求，向第一设备发送目标数据。本申请还提供了装置、设备和存储介质。本申请将密钥和证书体系扩展到P2P网络中，使得终端之间能够利用存储在本地的密钥和证书实现身份认证，从而提升数据传输的安全性。

Description

一种数据传输的方法、相关装置、设备以及存储介质
本申请要求于2022年05月16日提交中国专利局、申请号为2022105309073、申请名称为“一种数据传输的方法、相关装置、设备以及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及安全技术领域以及车联网技术领域，尤其涉及数据传输技术。
背景技术
近年来，随着物联网和移动网络的普及，行车记录仪发展迅速。行车记录仪是安装于车内的设备之一，其功能从纯粹的定位记录逐渐发展为多维度信息的记录，以此实现远程采集图片和视频、分析驾驶员驾驶行为、实时远程直播、定位位置轨迹等功能。
目前，可采用云中转或云存储的方式，将行车记录仪采集的行车数据保存在云端设备上，密钥和证书都在第三方服务器上保存。当车主想要访问行车记录仪采集的行车数据时，直接向云端设备发起访问请求，云端设备将行车数据反馈给用户。
然而，现有方案至少存在如下问题，行车数据具有较强的私密性，将密钥和证书都放在第三方服务器保存，仍然存在一定的安全隐患。即，行车数据容易在数据传输过程中被盗取或者篡改，数据传输的安全性和可靠性较低。
发明内容
本申请实施例提供了一种数据传输的方法、相关装置、设备以及存储介质。能够提升数据传输的安全性、私密性和可靠性。
有鉴于此，本申请一方面提供一种数据传输的方法，由第二设备执行，包括：
接收第一设备发送的第一证书，并向第一设备发送第二证书；
若第一证书以及第二证书均为有效证书，则根据第一证书确定第一公钥以及第一设备标识，其中，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
若第一设备标识以及第二设备标识均为已注册标识，则接收第一设备发送的数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第二公钥为第一设备根据第二证书获取到的，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
响应第一设备发送的数据访问请求，向第一设备发送目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
本申请另一方面提供一种数据传输的方法，由第一设备执行，包括：
向第二设备发送第一证书，并接收第二设备发送的第二证书；
若第一证书以及第二证书均为有效证书，则根据第二证书确定第二公钥以及第二设备标识，其中，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
若第一设备标识以及第二设备标识均为已注册标识，则向第二设备发送数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
接收第二设备发送的目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
本申请另一方面提供一种数据传输装置，包括：
收发模块，用于接收第一设备发送的第一证书，并向第一设备发送第二证书；
确定模块，用于若第一证书以及第二证书均为有效证书，则根据第一证书确定第一公钥以及第一设备标识，其中，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
收发模块，还用于若第一设备标识以及第二设备标识均为已注册标识，则接收第一设备发送的数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第二公钥为第一设备根据第二证书获取到的，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
收发模块，还用于响应第一设备发送的数据访问请求，向第一设备发送目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
本申请另一方面提供一种数据传输装置，包括：
收发模块，用于向第二设备发送第一证书，并接收第二设备发送的第二证书；
确定模块，用于若第一证书以及第二证书均为有效证书，则根据第二证书确定第二公钥以及第二设备标识，其中，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
收发模块，用于若第一设备标识以及第二设备标识均为已注册标识，则向第二设备发送数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
收发模块，用于若接收第二设备发送的目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
本申请另一方面提供一种数据传输的方法，应用于数据传输系统，数据传输系统包括车载终端以及移动设备，包括：
车载终端接收移动终端发送的第一证书；
移动终端接收车载终端发送的第二证书；
若第一证书以及第二证书均为有效证书，则车载终端根据第一证书确定第一公钥以及第一设备标识，且，移动终端根据第二证书确定第二公钥以及第二设备标识，其中，第一公钥以及第一私钥为移动终端生成的密钥对，第二公钥以及第二私钥为车载终端生成的密钥对，第一设备标识为移动终端对应的标识，第二设备标识为车载终端对应的标识；
若第一设备标识以及第二设备标识均为已注册标识，则移动终端向车载终端发送数据访问请求，其中，数据访问请求为移动终端采用第二公钥或第一私钥加密得到的；
车载终端响应移动终端发送的数据访问请求，并向移动终端发送目标行车数据，其中，目标行车数据为车载终端采用第一公钥或第二私钥加密得到的。
本申请另一方面提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述各方面的方法。
本申请的另一方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方面的方法。
本申请的另一个方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方面的方法。
从以上技术方案可以看出，本申请实施例具有以下优点：
本申请实施例提供了一种数据传输的方法，首先，第二设备接收第一设备发送的第一证书，并向第一设备发送第二证书。此时，如果第一证书以及第二证书均为有效证书，那么第二设备根据第一证书确定第一公钥以及第一设备标识。基于此，如果第一设备标识以及第二设备标识均为已注册标识，则第二设备接收第一设备发送的数据访问请求，并响应该数据访问请求，向第一设备发送目标数据。其中，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识。数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，而目标数据为第二设备采用第一公钥或第二私钥加密得到的。通过上述方式，将密钥和证书体系扩展到去中心化的对等网络(Peer to Peer，P2P)中，使得P2P网络中的终端(例如，车载终端和移动终端)彼此之间能够利用存储在本地的密钥和证书实现身份认证，从而有利于提升终端之间数据传输的安全性、私密性和可靠性。
附图说明
图1为本申请实施例中数据传输系统的一个架构示意图；
图2为本申请实施例中车联网系统的一个环境示意图；
图3为本申请实施例中数据传输方法的一个流程示意图；
图4为本申请实施例中基于车联网系统的一个车载终端工作流程示意图；
图5为本申请实施例中解除终端标识绑定关系的一个界面示意图；
图6为本申请实施例中添加终端标识绑定关系的一个界面示意图；
图7为本申请实施例中智能网联汽车的一个通信示意图；
图8为本申请实施例中基于二维码实现终端通信的一个示意图；
图9为本申请实施例中基于手动输入信息实现终端通信的一个示意图；
图10为本申请实施例中数据传输方法的另一个流程示意图；
图11为本申请实施例中基于车联网系统的一个移动终端工作流程示意图；
图12为本申请实施例中基于车联网系统的一个交互流程示意图；
图13为本申请实施例中数据传输装置的一个示意图；
图14为本申请实施例中数据传输装置的另一个示意图；
图15为本申请实施例中终端的一个结构示意图。
具体实施方式
现如今，按照规定，除了车主能访问行车记录仪采集的内容外，任何其他第三方均无权访问，包括第三方服务提供方。这就要求即使是车企自身以及解决方案的提供商，也不能存储客户的密钥。同时又要求车主和车之间无法欺骗，不被拦截破解其中的传输内容，基于此，本申请提供一种基于对等网络(Peer to Peer，P2P)实现的数据安全传输方案。
作为一种新型的网络应用方式，P2P具有一些服务器-客户机(Client-Server，C/S)模式所不具备的优势，主要表现在信息量的扩大以及匿名服务的自由开放性等。P2P最大的优势在于能够支持可靠且便捷的信息查询。在P2P网络中，对等节点共享它们所拥有的一部分资源，这些共享资源通过网络提供服务和内容，能够被其他对等节点直接访问，且无需经过中间实体。可见，对等节点在P2P网络中既是资源提供者(即，服务器)，又是资源获得者(即，客户端)。
为了在P2P网络中提升数据传输的安全性、私密性和可靠性。本申请提供了一种数据传输的方法，该方法应用于如图1所示的数据传输系统，如图所示，数据传输系统包括若干个节点设备，本申请对节点设备的数量不做限制。节点设备可以是服务器或终端，本申请以节点设备为终端作为示例进行介绍。客户端部署于终端上，其中，客户端可以通过浏览器的形式运行于终端上，也可以通过独立的应用程序(application，APP)的形式运行于终端上等，对于客户端的具体展现形式，此处不做限定。本申请涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的 云服务器。终端可以是手机、电脑、智能语音交互设备、智能家电、车载终端和飞行器等，但并不局限于此。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。
P2P促进了车联网产业的发展，随着汽车技术的迅猛发展，未来汽车将向网联化和智能化发展，各种智能系统和通信技术的搭载给未来的交通带来更多的可能性。为了便于理解，请参阅图2，图2为本申请实施例中车联网系统的一个环境示意图，如图所示，通过信息通信技术实现车与车、车与设备、车与路、以及车与云之间的信息分享。在车联网通信过程中，建立身份认证体系，赋予车辆、路侧单元(Road Side Unit，RSU)和信息服务平台等基础设施可信的数字身份，抵御信息伪造和篡改等安全攻击。
车联网是物联网(The Internet of Things，IOT)在汽车行业的应用，物联网是指通过信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要连接、互动的物体或过程，采集其声、光、热、电、力学、化学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。物联网是一个基于互联网、传统电信网等的信息承载体，让所有能够被独立寻址的普通物理对象形成互联互通的网络。
而云物联(Cloud IOT)旨在将传统物联网中传感设备感知的信息和接受的指令连入互联网中，真正实现网络化，并通过云计算技术实现海量数据的存储和运算，由于物联网的特性是物与物相连接，实时感知各个“物体”当前的运行状态，因此，在这个过程中会产生大量的数据信息，如何将这些信息汇总,如何在海量信息中筛取有用信息为后续发展做决策支持,成为影响物联网发展的关键问题，而基于云计算和云存储技术的云物联也因此成为物联网技术应用的有力支持。
鉴于本申请涉及到一些与专业领域相关的术语，为了便于理解，下面将对相关术语进行解释。
(1)车：泛指智能汽车或智能网联汽车。
(2)车载终端：可搭载车载系统(即，汽车所使用的系统)，通常采用安卓系统。车载终端集成定位、通信、行驶记录仪等多项功能，具有业务调度功能和数据处理能力。在本申请中，假设车载系统具有较高的安全性，且不可被破解，因此，无法获取其中的私钥。
(3)车主：即车的主人，本申请泛指车主的移动终端，包括但不仅限于电脑和手机。在本申请中，假设移动终端的账号系统具有较高的安全性，不会被其他用户获取到车主终端的数据以及其中的私钥。
(4)公钥和私钥：即非对称加密的密钥对，其中，私钥自己保存。
(5)设备标识(ting identity，TID)：设备唯一的标识(identity，ID)，通常，车载终端和移动终端都拥有一个自己的TID。
(6)移动终端标识(mobile ID，MID)：表示车载终端的ID，这一部分也可以由车主账号提供。
(7)车载终端标识(car ID，CID)：表示车载终端的TID。
(8)车主账号：车企APP的登陆账号。
(9)证书：表示某个公钥是属于某个TID的证书文件，该证书由权威机构签名，因此可被验证。
(10)根证书：即权威机构的公钥文件，自签证书。
(11)权威机构：即，证书的签发机构(Certification Authority，CA)，是公钥基础设施(Public Key Infrastructure，PKI)的核心，主要用于保存私钥、提供根证书、负责签发证书、认证证书、管理已颁发证书等。一般流量调度、会话保持、负载均衡在权威机构完成。
结合上述介绍，下面将对本申请中数据传输的方法进行介绍，请参阅图3，本申请实施例中数据传输的方法可以由终端执行，示例性地，该终端可以是车载终端，包括：
110、第二设备接收第一设备发送的第一证书，并向第一设备发送第二证书；
在一个或多个实施例中，第一设备与第二设备建立通信连接之后，第一设备向第二设备发送第一证书，且，第二设备向第一设备发送第二证书。其中，第一设备可以为移动终端(例如，手机、平板电脑或电脑等)，第二设备可以是车载终端。
具体地，移动终端与车载终端建立通信连接之后，移动终端向车载终端发送第一证书，由此，车载终端接收到第一证书。类似地，车载终端向移动终端发送第二证书，由此，移动终端接收到第二证书。
120、若第一证书以及第二证书均为有效证书，则第二设备根据第一证书确定第一公钥以及第一设备标识，其中，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
在一个或多个实施例中，第二设备验证第一证书的有效性，且，第一设备验证第二证书的有效性。如果第一证书和第二证书均为有效证书，则第二设备可将第一证书中的公钥确定为第一公钥，并将第一证书中的设备标识确定为第一设备标识。类似地，第一设备可将第二证书中的公钥确定为第二公钥，并将第二证书中的设备标识确定为第二设备标识。第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识。第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识。
具体地，车载终端基于第一证书得到第一公钥和第一设备标识，其中，第一公钥和第一私钥是移动终端生成的密钥对，即，第一公钥可以是移动终端公钥，第一私钥可以是移动终端私钥。第一设备标识为移动终端的TID， 即MID。类似地，移动终端基于第二证书得到第二公钥和第二设备标识，其中，第二公钥和第二私钥是车载终端生成的密钥对，即，第二公钥可以是车载终端公钥，第二私钥可以是车载终端私钥。第二设备标识为车载终端的TID，即CID。
130、若第一设备标识以及第二设备标识均为已注册标识，则第二设备接收第一设备发送的数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第二公钥为第一设备根据第二证书获取到的，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
在一个或多个实施例中，第二设备检测第一设备标识的注册情况，且，第一设备检测第二设备标识的注册情况。如果第一设备标识以及第二设备标识均为已注册标识，则第一设备可以采用第二公钥或第一私钥加密得到数据访问请求。基于此，第一设备向第二设备发送数据访问请求。
具体地，移动终端采用车载终端公钥或移动终端私钥加密得到数据访问请求，基于此，移动终端向车载终端发送数据访问请求。
140、第二设备响应第一设备发送的数据访问请求，向第一设备发送目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
在一个或多个实施例中，第二设备基于第一设备发送的数据访问请求，采用第一公钥或第二私钥对原始数据进行加密，由此得到目标数据。于是，第二设备向第一设备发送目标数据。
具体地，车载终端响应于数据访问请求，采用移动终端公钥或者车载终端私钥对原始数据进行加密，得到目标数据。然后，车载终端向移动终端发送目标数据。其中，原始数据可以是行车记录仪采集到的行车数据，包含但不仅限于行车过程中采集到的语音、照片、视频记录等。
本申请实施例提供了一种数据传输的方法。通过上述方式，将密钥和证书体系扩展到去中心化的P2P网络中，使得P2P网络中的终端(例如，车载终端和移动终端)彼此之间能够利用存储在本地的密钥和证书实现身份认证，从而有利于提升终端之间数据传输的安全性、私密性和可靠性。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备向第一设备发送第二证书之前，还可以包括：
第二设备获取第二公钥以及第二私钥；
第二设备存储第二私钥；
第二设备将第二公钥以及第二设备标识发送至认证服务器，以使认证服务器采用目标私钥对第二公钥以及第二设备标识进行签名，得到第二证书；
第二设备接收认证服务器发送的第二证书。
在一个或多个实施例中，介绍了一种第二设备向权威机构申请证书的方式。由前述实施例可知，在第二设备向第一设备发送第二证书之前，需要先 向权威机构申请第二证书。首先，第二设备生成密钥对，即第二公钥和第二私钥。一方面，第二设备需要将第二私钥存储在本地。另一方面，第二设备需要将第二公钥以及第二设备标识发送至权威机构的认证服务器，由认证服务器采用自己的目标私钥对第二公钥以及第二设备标识进行签名，得到第二证书。最后，认证服务器向第二设备反馈第二证书。
以第二设备为车载终端为例，为了便于理解，请参阅图4，图4为本申请实施例中基于车联网系统的一个车载终端工作流程示意图，如图所示，具体地：
在步骤A1中，车载终端在出厂前预先安装权威机构的根证书。车载终端在出厂后的初始化过程中，生成密钥对(即，车载终端公钥以及车载终端私钥)。其中，车载终端私钥由车载终端自身保存，且不外泄。可见，除了车载终端之外，任何设备都无法获知车载终端私钥。
需要说明的是，可采用算法生成密钥对，或者，采用加密芯片生成密钥对，此处不做限定。
在步骤A2中，车载终端获取自身的CID，并且绑定车载终端公钥。基于此，车载终端向权威机构的认证服务器发起超文本传输安全协议(Hyper Text Transfer Protocol over Secure Socket Layer，HTTPS)请求或安全传输层协议(Transport Layer Security，TLS)请求，以申请签发证书。
在步骤A3中，权威机构的认证服务器收到车载终端发送的请求之后，可使用目标私钥(即，根证书私钥)对CID和车载终端公钥进行数字签名，形成证书(即，第二证书)。
在步骤A4中，权威机构的认证服务器通过HTTPS通道或TLS通道，向车载终端反馈证书(即，第二证书)，由此，最大程度地避免车载终端被劫持拿到错误的证书。基于此，由车载终端保存该证书(即，第二证书)。
在步骤A5中，车载终端收到证书(即，第二证书)后，要通过步骤A1中预先安装的根证书校验证书(即，第二证书)的签名是否正确，以此确保证书的合法性。
基于上述流程，车载终端有了与自身CID绑定的密钥对(即，车载终端公钥以及车载终端私钥)以及证书体系，其他访问者可以安全地与其进行通信。
其次，本申请实施例提供了一种第二设备向权威机构申请证书的方式。通过上述方式，让节点设备拥有相应的证书，证书具有认证性，能够确认信息发送者的身份。因此，配合节点设备之间交换证书的方式，能够使设备之间的通信变得安全且可信赖。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备接收认证服务器发送的第二证书之后，还可以包括：
第二设备采用目标公钥对第二证书进行解密，得到第二目标签名，其中，目标公钥以及目标私钥为认证服务器生成的密钥对；
第二设备对第二公钥以及第二设备标识进行哈希计算，得到第二目标摘要；
若第二目标签名与第二目标摘要一致，则第二设备存储第二证书。
在一个或多个实施例中，介绍了一种第二设备验证第二证书的方式。由前述实施例可知，第二设备在出厂前预先安装权威机构的根证书，其中，根证书里包括目标公钥，目标公钥以及目标私钥为权威机构(即，认证服务器)生成的密钥对。基于此，可采用目标公钥对第二证书进行解密，得到第二目标签名。此外，第二设备需要对明文的第二公钥以及第二设备标识进行哈希计算，得到第二目标摘要。如果第二目标签名与第二目标摘要一致，则表示第二设备收到的第二证书是有效证书，因此，第二设备将第二证书存储在本地。
具体地，以第二设备为车载终端为例，采用目标公钥对第二证书进行解密，得到第二目标签名，即：
signature_2＝publickey_CA(DC_2)；
其中，signature_2表示第二目标签名。publickey_CA表示权威机构生成的目标公钥。DC_2表示第二证书。
对第二公钥以及第二设备标识进行哈希计算，得到第二目标摘要，即：
digest_2＝hash(publickey_2+CID)；
其中，digest_2表示第二目标摘要。hash()表示哈希计算。publickey_2表示第二公钥。CID表示第二设备标识。
基于此，如果第二目标签名(即signature_2)与第二目标摘要(即digest_2)一致，则表示第二证书是有效证书。反之，如果不一致，则第二设备可以重新向权威机构申请颁发证书。
再次，本申请实施例提供了一种第二设备验证第二证书的方式。通过上述方式，第二设备在获取到第二证书之后，可以验证第二证书的合法性。以此，保证自己本地证书的合法性，提升通信的安全性和可靠性。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备接收第一设备发送的第一证书之后，还可以包括：
第二设备采用目标公钥对第一证书进行解密，得到第一数字签名，其中，目标公钥为认证服务器生成的公钥；
第二设备从第一证书中获取第一待验证公钥以及第一待验证标识；
第二设备对第一待验证公钥以及第一待验证标识进行哈希计算，得到第一消息摘要；
若第一消息摘要与第一数字签名一致，则第二设备确定第一证书为有效 证书；
第二设备根据第一证书确定第一公钥以及第一设备标识，具体可以包括：
第二设备将第一证书中的第一待验证公钥作为第一公钥，并将第一证书中的第一待验证标识作为第一设备标识。
在一个或多个实施例中，介绍了一种第二设备验证第一证书的方式。由前述实施例可知，第二设备在出厂前预先安装权威机构的根证书，其中，根证书里包括目标公钥。基于此，第二设备可采用目标公钥对第一证书进行解密，得到第一数字签名。此外，第二设备可以从第一证书中获取明文的第一待验证公钥以及第一待验证标识，然后对第一待验证公钥以及第一待验证标识进行哈希计算，得到第一消息摘要。如果第一消息摘要与第一数字签名一致，则表示第二设备收到的第一证书是有效证书。因此，第二设备即可将第一证书中的第一待验证公钥作为第一公钥，并将第一证书中的第一待验证标识作为第一设备标识。
具体地，以第二设备为车载终端为例，采用目标公钥对第一证书进行解密，得到第一数字签名，即：
signature_A＝publickey_CA(DC_A)；
其中，signature_A表示第一数字签名。publickey_CA表示权威机构生成的目标公钥。DC_A表示第一证书。
对第一待验证公钥以及第一待验证标识进行哈希计算，得到第一消息摘要，即：
digest_A＝hash(publickey_A+MID_A)；
其中，digest_A表示第一消息摘要。hash()表示哈希计算。publickey_A表示第一待验证公钥。MID_A表示第一待验证标识。
基于此，如果第一数字签名(即signature_A)与第一消息摘要(即digest_A)一致，则表示第一证书是有效证书。反之，如果不一致，则第二设备不会向第一设备传输数据。
其次，本申请实施例提供了一种第二设备验证第一证书的方式。通过上述方式，第二设备在获取到第一证书之后，还可以验证第一证书的有效性，避免其他设备使用仿造的证书请求数据，以此提升通信的安全性和可靠性。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备响应第一设备发送的数据访问请求，向第一设备发送目标数据，具体可以包括：
若数据访问请求为第一设备采用第二公钥加密得到的，则第二设备采用第二私钥对数据访问请求进行解密，得到请求数据；
第二设备根据请求数据获取原始数据；
第二设备采用第二私钥对原始数据进行加密，得到目标数据；
第二设备向第一设备发送目标数据，以使第一设备采用第二公钥对目标 数据进行解密，得到原始数据；
或，
若数据访问请求为第一设备采用第二公钥加密得到的，则第二设备采用第二私钥对数据访问请求进行解密，得到请求数据；
第二设备根据请求数据获取原始数据；
第二设备采用第一公钥对原始数据进行加密，得到目标数据；
第二设备向第一设备发送目标数据，以使第一设备采用第一私钥对目标数据进行解密，得到原始数据；
或，
若数据访问请求为第一设备采用第一私钥加密得到的，则第二设备采用第一公钥对数据访问请求进行解密，得到请求数据；
第二设备根据请求数据获取原始数据；
第二设备采用第二私钥对原始数据进行加密，得到目标数据；
第二设备向第一设备发送目标数据，以使第一设备采用第二公钥对目标数据进行解密，得到原始数据；
或，
若数据访问请求为第一设备采用第一私钥加密得到的，则第二设备采用第一公钥对数据访问请求进行解密，得到请求数据；
第二设备根据请求数据获取原始数据；
第二设备采用第一公钥对原始数据进行加密，得到目标数据；
第二设备向第一设备发送目标数据，以使第一设备采用第一私钥对目标数据进行解密，得到原始数据。
在一个或多个实施例中，介绍了基于不同密钥进行安全通信的多种方式。由前述实施例可知，第二设备本地存储第二私钥，且，第二设备能够获取到第一公钥。而第一设备本地存储第一私钥，且，第一设备能够获取到第二公钥。
下面将以第一设备为移动终端，第二设备为车载终端为例进行介绍。其中，第一公钥为移动终端公钥，第一私钥为移动终端私钥，第二公钥为车载终端公钥，第二私钥为车载终端私钥。假设用户通过移动终端选择查看2022年5月3日15点至17点的行车数据，由此，得到用户的请求数据。
方式一；
移动终端可采用车载终端公钥对请求数据进行加密，得到数据访问请求。于是，移动终端向车载终端发送数据访问请求，车载终端可采用车载终端私钥对数据访问请求进行解密，即可得到请求数据。车载终端根据请求数据，调用相应的行车数据作为原始数据。然后车载终端使用车载终端私钥对原始数据进行加密，得到目标数据。车载终端向移动终端发送目标数据，移动终端可采用车载终端公钥对目标数据进行解密，即可得到原始数据。
方式二；
移动终端可采用车载终端公钥对请求数据进行加密，得到数据访问请求。于是，移动终端向车载终端发送数据访问请求，车载终端可采用车载终端私钥对数据访问请求进行解密，即可得到请求数据。车载终端根据请求数据，调用相应的行车数据作为原始数据。然后车载终端使用移动终端公钥对原始数据进行加密，得到目标数据。车载终端向移动终端发送目标数据，移动终端可采用移动终端私钥对目标数据进行解密，即可得到原始数据。
方式三；
移动终端可采用移动终端私钥对请求数据进行加密，得到数据访问请求。于是，移动终端向车载终端发送数据访问请求，车载终端可采用移动终端公钥对数据访问请求进行解密，即可得到请求数据。车载终端根据请求数据，调用相应的行车数据作为原始数据。然后车载终端使用车载终端私钥对原始数据进行加密，得到目标数据。车载终端向移动终端发送目标数据，移动终端可采用车载终端公钥对目标数据进行解密，即可得到原始数据。
方式四；
移动终端可采用移动终端私钥对请求数据进行加密，得到数据访问请求。于是，移动终端向车载终端发送数据访问请求，车载终端可采用移动终端公钥对数据访问请求进行解密，即可得到请求数据。车载终端根据请求数据，调用相应的行车数据作为原始数据。然后车载终端使用移动终端公钥对原始数据进行加密，得到目标数据。车载终端向移动终端发送目标数据，移动终端可采用移动终端私钥对目标数据进行解密，即可得到原始数据。
其次，本申请实施例提供了基于不同密钥进行安全通信的多种方式。通过上述方式，第二设备可根据实际情况选择相应的密钥进行加密或解密，从而增加方案的可行性和灵活性。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备根据第一证书确定第一公钥以及第一设备标识之后，还可以包括：
第二设备获取第二设备存储的第一设备标识集合，其中，第一设备标识集合包括已针对第二设备注册的M个第一注册设备标识，M为大于或等于1的整数；
若第一设备标识与第一设备标识集合中的一个第一注册设备标识匹配成功，则第二设备确定第一设备标识为已注册标识。
在一个或多个实施例中，介绍了一种判定第一设备标识是否属于已注册标识的方式。由前述实施例可知，第一设备可通过蓝牙协议或其他安全通道，将第一设备标识注册到第二设备中，基于此，第二设备需要对接收到第一设备标识进行匹配，如果匹配成功，则表示该第一设备为曾经注册过的设备，即，确定第一设备标识为已注册标识。
具体地，下面将以第一设备为移动终端，第二设备为车载终端为例进行介绍。用户可以将M个MID绑定到车载终端，即，允许有M个移动终端与一个车载终端进行通信。为了便于理解，请参阅表1，表1为已注册到车载终端的M个MID的一个示意。
表1
可见，同一个车载终端(即，同一个CID)可绑定至少一个MID。以表1为例，CID为“CID_0001”的车载终端具有已注册的3个第一注册设备标识，其中，这3个第一注册设备标识分别为MID_0235659，MID_0254981和MID_0264154。
其次，本申请实施例提供了一种判定第一设备标识是否属于已注册标识的方式。通过上述方式，第一设备可将自身的第一设备标识注册到第二设备中，由第二设备进行存储。通过验证设备标识即可判定是否与曾经注册的身份相同，由此，提升设备通信的安全性和可靠性。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：
第二设备显示第一设备标识集合；
第二设备响应针对第一设备标识集合中K个第一注册设备标识的删除操作，从第一设备标识集合中移除K个第一注册设备标识，得到更新后的第一设备标识集合，其中，K为大于或等于1，且小于或等于M的整数；
还可以包括：
第二设备显示标识添加控件；
第二设备响应针对标识添加控件的选择操作，显示标识添加区域；
第二设备响应针对标识添加区域的输入操作，在第一设备标识集合中添加T个第一注册设备标识，得到更新后的第一设备标识集合，其中，T为大于或等于1整数。
在一个或多个实施例中，介绍了绑定和解绑设备标识的方式。由前述实施例可知，第二设备还支持显示第一设备标识集合的功能，基于此，可对CID和MID进行绑定或解绑。下面将以第二设备为车载终端为例，结合图示介绍标识绑定和解绑的过程。
一、解除终端标识绑定关系；
具体地，为了便于理解，请参阅图5，图5为本申请实施例中解除终端标识绑定关系的一个界面示意图，如图5中(A)图所示，B1用于指示已与“CID_0001”绑定的MID列表，其中，当前有2个MID与“CID_0001”绑定。 B2用于指示选中的MID，由于这里只选择了一个MID，因此，K等于1。可以理解的是，选中MID的方式包含但不仅限于长按，双击，点击控件等，此处不做限定。B3用于指示删除控件。用户在选定K个MID之后，点击B3所指示的删除控件，即可显示如图5中(B)图所示的界面，此时，选中的“MID_0235659”已解除与“CID_0001”的绑定关系。
二、添加终端标识绑定关系；
具体地，为了便于理解，请参阅图6，图6为本申请实施例中添加终端标识绑定关系的一个界面示意图，如图6中(A)图所示，C1用于指示已与“CID_0001”绑定的MID列表，其中，当前有2个MID与“CID_0001”绑定。C2用于指示标识添加控件。用户点击C2所指示的标识添加控件之后，即可显示C3所指示的标识添加区域。基于此，用户可在标识添加区域内输入相应的MID，例如，“MID_0264154”。由于这里只添加了一个MID，因此，T等于1。输入完毕后，即可显示如图6中(B)图所示的界面，此时，选中的“MID_0264154”已与“CID_0001”绑定成功。
再次，本申请实施例提供了绑定和解绑设备标识的方式。通过上述方式，如果用户的移动终端不再使用，则可以在车载终端中将之前绑定的MID删除，从而避免被不法分子利用。与此同时，在车载终端上实现结果可视化，即使恶意入侵也能及时发现，并清除恶意访问方。
可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第二设备接收第一设备发送的第一证书，并向第一设备发送第二证书之前，还可以包括：
当第二设备与第一设备启动蓝牙功能时，第二设备与第一设备建立蓝牙连接，以使第二设备与第一设备之间建立通信连接；
或，
当第二设备与第一设备连入同一无线热点时，第二设备与第一设备建立通信连接；
或，
第二设备显示二维码，其中，二维码包括第二设备标识；
当第一设备扫描二维码时，第二设备与第一设备建立通信连接；
或，
第二设备显示信息输入区域；
第二设备响应针对信息输入区域输入的第一设备标识，与第一设备建立通信连接。
在一个或多个实施例中，介绍了建立通信连接的多种方式。由前述实施例可知，第一设备与第二设备建立通信连接后即可进行数据传输，因此，下面将以第一设备为移动终端，第二设备为车载终端为例，说明建立通信连接的方式。
可以理解的是，车载终端部署于智能网联汽车，为了便于理解，请参阅图7，图7为本申请实施例中智能网联汽车的一个通信示意图，如图所示，智能网联汽车通常具有行动热点(Wireless Fidelity，Wi-Fi)功能、蓝牙功能、摄像头功能、全球定位系统(Global Positioning System，GPS)功能、雷达功能、通信功能等。基于此，车载终端可内置Wi-Fi功能、蓝牙功能、GPS功能和通信功能等。
关联方式一；
车载终端与移动终端可采用近场通信的方式建立连接。例如，车载终端与移动终端均开启蓝牙功能，基于蓝牙协议建立通信连接。
关联方式二；
车载终端启动热点功能，移动终端接入该车载终端对应的热点。由此，车载终端与移动终端接入了同一个无线热点，即，两者通过同一Wi-Fi下的网络建立通信连接。
关联方式三；
车载终端显示二维码，可供移动终端扫描。为了便于理解，请参阅图8，图8为本申请实施例中基于二维码实现终端通信的一个示意图，如图所示，车载终端上显示有D1所指示的二维码，其中，该二维码包含车载终端的CID，以供移动终端通过车主APP扫码获取。基于此，移动终端可扫描该二维码，扫描成功后，即建立两个设备之间的通信连接。
关联方式四；
车载终端显示信息输入区域，可供用户手动输入MID(例如，车主账号，系统分配标识号或手机号等)。为了便于理解，请参阅图9，图9为本申请实施例中基于手动输入信息实现终端通信的一个示意图，如图所示，E1用于指示信息输入区域，用户可在E1所指示的信息输入区域内输入MID(即，第一设备标识)。输入完毕后，点击E2所指示的确认控件，即建立两个设备之间的通信连接。
其次，本申请实施例提供了建立通信连接的多种方式。通过上述方式，利用近场通信将信赖的对方加为指定访问方，能够避免在公网通信的情况下被篡改侵入。此外，非对称加密和证书体系对数据通信的安全可信性提供了很大保障，本申请还可以采用更轻量的方式。即，近场通信过程中可简单地交换约定的密钥，此后，移动终端和车载终端之间就直接用该密钥进行加密通信，并且在通信链路中不再传输密钥，同样具有很好的安全效果。为了进一步加强密钥的安全性，还可以检查密钥的随机性和复杂性，并且提醒车主定时更换。
结合上述介绍，下面将对本申请中数据传输的方法进行介绍，请参阅图10，本申请实施例中数据传输的方法可以由终端执行，示例性地，该终端可以是移动终端，包括：
210、第一设备向第二设备发送第一证书，并接收第二设备发送的第二证书；
在一个或多个实施例中，第一设备与第二设备建立通信连接之后，第一设备向第二设备发送第一证书，且，第二设备向第一设备发送第二证书。其中，第一设备可以为移动终端(例如，手机、平板电脑或电脑等)，第二设备可以是车载终端。
需要说明的是，步骤210与步骤110的执行过程类似，此处不做赘述。
220、若第一证书以及第二证书均为有效证书，则第一设备根据第二证书确定第二公钥以及第二设备标识，其中，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
在一个或多个实施例中，第二设备验证第一证书的有效性，且，第一设备验证第二证书的有效性。如果第一证书和第二证书均为有效证书，则第二设备可将第一证书中的公钥确定为第一公钥，并将第一证书中的设备标识确定为第一设备标识。类似地，第一设备可将第二证书中的公钥确定为第二公钥，并将第二证书中的设备标识确定为第二设备标识。第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识。第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识。
需要说明的是，步骤220与步骤120的执行过程类似，此处不做赘述。
230、若第一设备标识以及第二设备标识均为已注册标识，则第一设备向第二设备发送数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
在一个或多个实施例中，第二设备检测第一设备标识的注册情况，且，第一设备检测第二设备标识的注册情况。如果第一设备标识以及第二设备标识均为已注册标识，则第一设备可以采用第二公钥或第一私钥加密得到数据访问请求。基于此，第一设备向第二设备发送数据访问请求。
需要说明的是，步骤230与步骤130的执行过程类似，此处不做赘述。
240、第一设备接收第二设备发送的目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
在一个或多个实施例中，第二设备响应第一设备发送的数据访问请求，采用第一公钥或第二私钥对原始数据进行加密，由此得到目标数据。于是，第二设备向第一设备发送目标数据。
需要说明的是，步骤240与步骤140的执行过程类似，此处不做赘述。
本申请实施例提供了一种数据传输的方法。通过上述方式，将密钥和证书体系扩展到去中心化的P2P网络中，使得P2P网络中的终端(例如，车载终端和移动终端)彼此之间能够利用存储在本地的密钥和证书实现身份认证， 从而有利于提升终端之间数据传输的安全性、私密性和可靠性。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备向第二设备发送第一证书之前，还可以包括：
第一设备获取第一公钥以及第一私钥；
第一设备存储第一私钥；
第一设备将第一公钥以及第一设备标识发送至认证服务器，以使认证服务器采用目标私钥对第一公钥以及第一设备标识进行签名，得到第一证书；
第一设备接收认证服务器发送的第一证书。
在一个或多个实施例中，介绍了一种第一设备向权威机构申请证书的方式。由前述实施例可知，在第一设备向第二设备发送第一证书之前，需要先向权威机构申请第一证书。首先，第一设备生成密钥对，即第一公钥和第一私钥。一方面，第一设备需要将第一私钥存储在本地。另一方面，第一设备需要将第一公钥以及第一设备标识发送至权威机构的认证服务器，由认证服务器采用自己的目标私钥对第一公钥以及第一设备标识进行签名，得到第一证书。最后，认证服务器向第一设备反馈第一证书。
以第一设备为移动终端为例，为了便于理解，请参阅图11，图11为本申请实施例中基于车联网系统的一个移动终端工作流程示意图，如图所示，具体地：
在步骤F1中，用户下载APP到移动终端，APP中内置权威机构的根证书，其中，这个过程可以由APP的软件开发工具包(Software Development Kit，SDK)提供。用户登录APP之后，根据不同的MID(例如，车主账号，系统分配标识号或手机号码等)生成相应的密钥对(即，移动终端公钥以及移动终端私钥)。移动终端私钥由移动终端自身保存，且不外泄。可见，除了移动终端之外，都无法获知移动终端私钥。
在步骤F2中，移动终端将MID与移动终端公钥绑定。基于此，移动终端向权威机构的认证服务器发起HTTPS请求或TLS、请求，以申请签发证书。
在步骤F3中，权威机构的认证服务器收到移动终端发送请求之后，可使用目标私钥(即，根证书私钥)对MID和移动终端公钥进行数字签名，形成证书(即，第一证书)。
在步骤F4中，权威机构的认证服务器通过HTTPS通道或TLS通道，向移动终端反馈证书(即，第一证书)，由此，最大程度避免移动终端被劫持拿到错误的证书。基于此，由移动终端保存该证书(即，第一证书)。
在步骤F5中，移动终端收到证书(即，第一证书)后，要通过步骤F1中预先安装的根证书校验证书(即，第一证书)的签名是否正确，以此确保证书的合法性。
基于上述流程，移动终端有了与自身MID绑定的密钥对(即移动终端公钥以及移动终端私钥)以及证书体系，其他访问者可以安全地与其进行通信。
需要说明的是，移动终端的APP可能会清除数据，因此，再次登录的时候需要重新验证密钥对(即，移动终端公钥以及移动终端私钥)以及证书是否存在且合法。如果不存在或不合法，则需要重新生成。APP的安全性主要由APP保证，即，主要是保证其私钥不可被获取，尽可能地使用APP系统自带的加密芯片。
其次，本申请实施例提供了一种第一设备向权威机构申请证书的方式。通过上述方式，使得节点设备拥有相应的证书，证书具有认证性，能够确认信息发送者的身份。因此，配合节点设备之间交换证书的方式，能够使设备之间的通信变得安全且可信赖。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备接收认证服务器发送的第一证书之后，还可以包括：
第一设备采用目标公钥对第一证书进行解密，得到第一目标签名，其中，目标公钥以及目标私钥为认证服务器生成的密钥对；
第一设备对第一公钥以及第一设备标识进行哈希计算，得到第一目标摘要；
若第一目标签名与第一目标摘要一致，则第一设备存储第一证书。
在一个或多个实施例中，介绍了一种第一设备验证第一证书的方式。由前述实施例可知，第一设备在下载的APP中内置有权威机构的根证书，其中，根证书里包括目标公钥，目标公钥以及目标私钥为权威机构(即认证服务器)生成的密钥对。基于此，可采用目标公钥对第一证书进行解密，得到第一目标签名。此外，第一设备需要对明文的第一公钥以及第一设备标识进行哈希计算，得到第一目标摘要。如果第一目标签名与第一目标摘要一致，则表示第一设备收到的第一证书是有效证书，因此，第一设备将第一证书存储在本地。
具体地，以第一设备为移动终端为例，采用目标公钥对第一证书进行解密，得到第一目标签名，即：
signature_1＝publickey_CA(DC_1)；
其中，signature_1表示第一目标签名。publickey_CA表示权威机构生成的目标公钥。DC_1表示第一证书。
对第一公钥以及第一设备标识进行哈希计算，得到第一目标摘要，即：
digest_1＝hash(publickey_1+MID)；
其中，digest_1表示第一目标摘要。hash()表示哈希计算。publickey_1表示第一公钥。MID表示第一设备标识。
基于此，如果第一目标签名(即signature_1)与第一目标摘要(即digest_1)一致，则表示第一证书是有效证书。反之，如果不一致，则第一设备可以重新向权威机构申请颁发证书。
再次，本申请实施例提供了一种第一设备验证第一证书的方式。通过上述方式，第一设备在获取到第一证书之后，还可以验证第一证书的合法性。以此，保证自己本地证书的合法性，由此提升通信的安全性和可靠性。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备接收第二设备发送的第二证书之后，还可以包括：
第一设备采用目标公钥对第二证书进行解密，得到第二数字签名，其中，目标公钥为认证服务器生成的公钥；
第一设备从第二证书中获取第二待验证公钥以及第二待验证标识；
第一设备对第二待验证公钥以及第二待验证标识进行哈希计算，得到第二消息摘要；
若第二消息摘要与第二数字签名一致，则第一设备确定第二证书为有效证书；
第一设备根据第二证书确定第二公钥以及第二设备标识，具体可以包括：
第一设备将第二证书中的第二待验证公钥作为第二公钥，并将第二证书中的第二待验证标识作为第二设备标识。
在一个或多个实施例中，介绍了一种第一设备验证第二证书的方式。由前述实施例可知，第一设备在下载的APP中内置有权威机构的根证书，其中，根证书里包括目标公钥。基于此，可采用目标公钥对第二证书进行解密，得到第二数字签名。此外，第一设备可以从第二证书中获取明文的第二待验证公钥以及第二待验证标识，然后对第二待验证公钥以及第二待验证标识进行哈希计算，得到第二消息摘要。如果第二消息摘要与第二数字签名一致，则表示第一设备收到的第二证书是有效证书。因此，第一设备即可将第二证书中的第二待验证公钥作为第一公钥，并将第二证书中的第二待验证标识作为第二设备标识。
具体地，以第一设备为移动终端为例，采用目标公钥对第二证书进行解密，得到第二数字签名，即：
signature_B＝publickey_CA(DC_B)；
其中，signature_B表示第二数字签名。publickey_CA表示权威机构生成的目标公钥。DC_B表示第二证书。
对第二待验证公钥以及第二待验证标识进行哈希计算，得到第二消息摘要，即：
digest_B＝hash(publickey_B+CID_B)；
其中，digest_B表示第二消息摘要。hash()表示哈希计算。publickey_B表示第二待验证公钥。CID_B表示第二待验证标识。
基于此，如果第二数字签名(即，signature_B)与第二消息摘要(即，digest_B)一致，则表示第二证书是有效证书。反之，如果不一致，则第一设 备不会向第二设备发送请求。
其次，本申请实施例提供了一种第一设备验证第二证书的方式。通过上述方式，第一设备在获取到第二证书之后，还可以验证第二证书的有效性，避免其他设备使用仿造的证书请求数据，以此提升通信的安全性和可靠性。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备向第二设备发送数据访问请求之前，还可以包括：
第一设备采用第二公钥对请求数据进行加密，得到数据访问请求；
第一设备向第二设备发送数据访问请求之后，还可以包括：
第一设备向第二设备发送数据访问请求，以使第二设备采用第二私钥对数据访问请求进行解密，得到请求数据；
或，
第一设备向第二设备发送数据访问请求之前，还可以包括：
第一设备采用第一私钥对请求数据进行加密，得到数据访问请求；
第一设备向第二设备发送数据访问请求之后，还可以包括：
第一设备向第二设备发送数据访问请求，以使第二设备采用第一公钥对数据访问请求进行解密，得到请求数据；
或，
第一设备接收第二设备发送的目标数据之后，还可以包括：
若目标数据为第二设备采用第二私钥对原始数据进行加密得到的，则第一设备采用第二公钥对目标数据进行解密，得到原始数据；
或，
第一设备接收第二设备发送的目标数据之后，还可以包括：
若目标数据为第二设备采用第一公钥对原始数据进行加密得到的，则第一设备采用第一私钥对目标数据进行解密，得到原始数据。
在一个或多个实施例中，介绍了基于不同密钥进行安全通信的多种方式。由前述实施例可知，第一设备本地存储第一私钥，且，第一设备能够获取到第二公钥。而第二设备本地存储第二私钥，且，第二设备能够获取到第一公钥。
需要说明的是，本实施例所描述的内容，可参阅前述实施例中方式一，方式二，方式三和方式四，此处不做赘述。
其次，本申请实施例提供了基于不同密钥进行安全通信的多种方式。通过上述方式，第一设备可根据实际情况选择相应的密钥进行加密或解密，从而增加方案的可行性和灵活性。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备根据第二证书确定第二公钥以及第二设备标识之后，还可以包括：
第一设备获取第一设备存储的第二设备标识集合，其中，第二设备标识集合包括已针对第一设备注册的N个第二注册设备标识，N为大于或等于1的整数；
若第二设备标识与第二设备标识集合中的一个第二注册设备标识匹配成功，则第一设备确定第二设备标识为已注册标识。
在一个或多个实施例中，介绍了一种判定设备标识是否属于已注册标识的方式。由前述实施例可知，第二设备可通过蓝牙协议或其他安全通道，将第二设备标识注册到第一设备中，基于此，第一设备需要对接收到第二设备标识进行匹配，如果匹配成功，则表示该第二设备为曾经注册过的设备，即，确定第二设备标识为已注册标识。
具体地，下面将以第一设备为移动终端，第二设备为车载终端为例进行介绍。用户可以将N个CID绑定到移动终端，即，允许有N个车载终端与一个移动终端进行通信。为了便于理解，请参阅表2，表2为已注册到移动终端的N个CID的一个示意。
表2
可见，同一个移动终端(即，同一个MID)可绑定至少一个CID。以表2为例，MID为“MID_0235659”的移动终端具有已注册的2个第二注册设备标识，其中，这2个第二注册设备标识分别为CID_0001和CID_0006。
其次，本申请实施例提供了一种判定设备标识是否属于已注册标识的方式。通过上述方式，第二设备可将自身的第二设备标识注册到第一设备中，由第一设备内的APP进行保存。通过验证设备标识即可判定是否与曾经注册的身份相同，由此，提升设备通信的安全性和可靠性。
可选地，在上述图10对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一设备向第二设备发送第一证书，并接收第二设备发送的第二证书之前，还可以包括：
当第二设备与第一设备启动蓝牙功能时，第一设备与第二设备建立蓝牙连接，以使第二设备与第一设备之间建立通信连接；
或，
当第二设备与第一设备连入同一无线热点时，第一设备与第二设备建立通信连接；
或，
第一设备扫描显示于第二设备上的二维码，与第一设备建立通信连接，其中，二维码包括第二设备标识。
在一个或多个实施例中，介绍了建立通信连接的多种方式。由前述实施 例可知，第一设备与第二设备建立通信连接后即可进行数据传输。需要说明的是，本实施例所描述的内容，可参阅前述实施例中关联方式一、关联方式二和关联方式三，此处不做赘述。
其次，本申请实施例提供了建立通信连接的多种方式。通过上述方式，利用近场通信将信赖的对方加为指定访问方，能够避免在公网通信的情况下被篡改侵入。此外，非对称加密和证书体系对数据通信的安全可信性提供了很大保障，本申请还可以采用更轻量的方式。即，近场通信过程中可简单地交换约定的密钥，此后，移动终端和车载终端通信就直接用该密钥加密通信，并且在通信链路中不再传输密钥，同样具有很好的安全效果。为了进一步加强密钥的安全性，还可以检查密钥的随机性和复杂性，并且提醒车主定时更换。
结合上述介绍，为了便于理解，请参阅图12，图12为本申请实施例中基于车联网系统的一个交互流程示意图，如图所示，具体地：
在步骤G1中，车载终端在出厂前预先安装权威机构的根证书。车载终端在出厂后的初始化过程中，生成车载终端公钥以及车载终端私钥。其中，车载终端私钥由车载终端自身保存，且不外泄。
在步骤G2中，车载终端获取自身的CID，并且绑定车载终端公钥。基于此，车载终端向权威机构的认证服务器发起HTTPS请求或TLS请求，以申请签发证书。
在步骤G3中，权威机构的认证服务器收到车载终端发送的请求之后，可使用目标私钥(即，根证书私钥)为CID和车载终端公钥进行数字签名，形成第二证书。
在步骤G4中，权威机构的认证服务器通过HTTPS通道或TLS通道，向车载终端反馈第二证书，由车载终端保存该第二证书。
在步骤G5中，车载终端收到第二证书后，要通过步骤G1中预先安装的根证书校验第二证书的签名是否正确，以此确保第二证书的合法性。
在步骤G6中，用户下载APP到移动终端，APP中内置权威机构的根证书，其中，这个过程可以由APP的SDK提供。用户登录APP之后，根据不同的MID(例如，车主账号或手机号等)生成相应的移动终端公钥以及移动终端私钥。移动终端私钥由移动终端自身保存，且不外泄。
在步骤G7中，移动终端将MID与移动终端公钥绑定。基于此，移动终端向权威机构的认证服务器发起HTTPS请求或TLS、请求，以申请签发证书。
在步骤G8中，权威机构的认证服务器收到移动终端发送的请求之后，可使用目标私钥(即，根证书私钥)为MID和移动终端公钥进行数字签名，形成第一证书。
在步骤G9中，权威机构的认证服务器通过HTTPS通道或TLS通道，向移动终端反馈第一证书，由移动终端保存该第一证书。
在步骤G10中，移动终端收到第一证书后，要通过步骤G6中预先安装的根证书校验第一证书的签名是否正确，以此确保第一证书的合法性。
在车载终端和移动终端都有可信且对等的安全环境后，需绑定车载终端和移动终端(即，车主APP)的关系。这一步通常由车主在第一次购车提车后线下操作，通过蓝牙协议等传输数据，相对而言安全风险较小。
在步骤G11中，车载终端将CID通过蓝牙协议或其他安全通道交换到移动终端的车主APP中，由车主APP进行保存。
在步骤G12中，移动终端的车主APP将MID通过蓝牙协议或其他安全通道交换到车载终端中，由车载终端进行保存。
移动终端与车载终端通信时彼此交换证书，双方各自验证对方身份，判定是否与曾经注册的身份相同，其中，身份是由根证书进行校验的，无法伪造。双方验证完身份后，即，彼此交换密钥，可安全通信。
本申请解决了车联网中车主与车通过P2P网络直连的安全信任需求。一方面扩展了密钥和证书体系，让车载终端和移动终端都等同于部署在机房内服务器的安全可信级别。另一方面，利用了车主和车载终端相互信赖的关系，车主通常不会主动破坏自己的车。最后，车主和车主之间的通信空间彼此隔离，不会相互侵犯。基于此，保证了车载终端和移动终端的安全通信需求，达到了监管要求的高隐私保护标准。
下面对本申请中的数据传输装置进行详细描述，请参阅图13，图13为本申请实施例中数据传输装置的一个实施例示意图，数据传输装置30包括：
收发模块310，用于接收第一设备发送的第一证书，并向第一设备发送第二证书；
确定模块320，用于若第一证书以及第二证书均为有效证书，则根据第一证书确定第一公钥以及第一设备标识，其中，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
收发模块310，还用于若第一设备标识以及第二设备标识均为已注册标识，则接收第一设备发送的数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第二公钥为第一设备根据第二证书获取到的，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
收发模块310，还用于响应第一设备发送的数据访问请求，向第一设备发送目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，数据传输装置30还包括获取模块330以及存储模块340；
获取模块330，用于向第一设备发送第二证书之前，获取第二公钥以及 第二私钥；
存储模块340，用于存储第二私钥；
收发模块310，还用于将第二公钥以及第二设备标识发送至认证服务器，以使认证服务器采用目标私钥对第二公钥以及第二设备标识进行签名，得到第二证书；
收发模块310，还用于接收认证服务器发送的第二证书。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，数据传输装置30还包括解密模块350以及生成模块360；
解密模块350，用于接收认证服务器发送的第二证书之后，采用目标公钥对第二证书进行解密，得到第二目标签名，其中，目标公钥以及目标私钥为认证服务器生成的密钥对；
生成模块360，用于对第二公钥以及第二设备标识进行哈希计算，得到第二目标摘要；
存储模块340，还用于若第二目标签名与第二目标摘要一致，则存储第二证书。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，
解密模块350，还用于接收第一设备发送的第一证书之后，采用目标公钥对第一证书进行解密，得到第一数字签名，其中，目标公钥为认证服务器生成的公钥；
获取模块330，还用于从第一证书中获取第一待验证公钥以及第一待验证标识；
生成模块360，还用于对第一待验证公钥以及第一待验证标识进行哈希计算，得到第一消息摘要；
确定模块320，还用于若第一消息摘要与第一数字签名一致，则确定第一证书为有效证书；
确定模块320，具体用于将第一证书中的第一待验证公钥作为第一公钥，并将第一证书中的第一待验证标识作为第一设备标识。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，
收发模块310，具体用于若数据访问请求为第一设备采用第二公钥加密得到的，则采用第二私钥对数据访问请求进行解密，得到请求数据；若所述数据访问请求为所述第一设备采用所述第一私钥加密得到的，则采用所述第一公钥对所述数据访问请求进行解密，得到请求数据；
根据请求数据获取原始数据；
采用第二私钥对原始数据进行加密，得到目标数据；或者，采用所述第 一公钥对所述原始数据进行加密，得到所述目标数据；
向第一设备发送目标数据，以使第一设备对目标数据进行解密得到原始数据，若所述目标数据是采用所述第二私钥加密得到的，则所述第一设备采用所述第二公钥对所述目标数据解密，若所述目标数据是采用所述第一公钥加密得到的，则所述第一设备采用所述第一私钥对所述目标数据解密。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，
获取模块330，还用于根据第一证书确定第一公钥以及第一设备标识之后，获取第二设备存储的第一设备标识集合，其中，第一设备标识集合包括已针对第二设备注册的M个第一注册设备标识，M为大于或等于1的整数；
确定模块320，还用于若第一设备标识与第一设备标识集合中的一个第一注册设备标识匹配成功，则确定第一设备标识为已注册标识。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，数据传输装置30还包括显示模块370以及处理模块380；
显示模块370，用于显示第一设备标识集合；
处理模块380，用于响应针对第一设备标识集合中K个第一注册设备标识的删除操作，从第一设备标识集合中移除K个第一注册设备标识，得到更新后的第一设备标识集合，其中，K为大于或等于1，且小于或等于M的整数；
显示模块370，还用于显示标识添加控件；
显示模块370，还用于响应针对标识添加控件的选择操作，显示标识添加区域；
处理模块380，还用于响应针对标识添加区域的输入操作，在第一设备标识集合中添加T个第一注册设备标识，得到更新后的第一设备标识集合，其中，T为大于或等于1整数。
可选地，在上述图13所对应的实施例的基础上，本申请实施例提供的数据传输装置30的另一实施例中，数据传输装置20还包括通信模块390；
通信模块390，用于接收第一设备发送的第一证书，并向第一设备发送第二证书之前，当第二设备与第一设备启动蓝牙功能时，与第一设备建立蓝牙连接，以使第二设备与第一设备之间建立通信连接；
或，
通信模块390，还用于接收第一设备发送的第一证书，并向第一设备发送第二证书之前，当第二设备与第一设备连入同一无线热点时，与第一设备建立通信连接；
或，
显示模块370，还用于接收第一设备发送的第一证书，并向第一设备发 送第二证书之前，显示二维码，其中，二维码包括第二设备标识；
通信模块390，还用于当第一设备扫描二维码时，与第一设备建立通信连接；
或，
显示模块370，还用于接收第一设备发送的第一证书，并向第一设备发送第二证书之前，显示信息输入区域；
通信模块390，还用于响应针对信息输入区域输入的第一设备标识，与第一设备建立通信连接。
下面对本申请中的数据传输装置进行详细描述，请参阅图14，图14为本申请实施例中数据传输装置的另一个实施例示意图，数据传输装置40包括：
收发模块410，用于向第二设备发送第一证书，并接收第二设备发送的第二证书；
确定模块420，用于若第一证书以及第二证书均为有效证书，则根据第二证书确定第二公钥以及第二设备标识，其中，第二公钥以及第二私钥为第二设备生成的密钥对，第二设备标识为第二设备对应的标识；
收发模块410，用于若第一设备标识以及第二设备标识均为已注册标识，则向第二设备发送数据访问请求，其中，数据访问请求为第一设备采用第二公钥或第一私钥加密得到的，第一公钥以及第一私钥为第一设备生成的密钥对，第一设备标识为第一设备对应的标识；
收发模块410，用于若接收第二设备发送的目标数据，其中，目标数据为第二设备采用第一公钥或第二私钥加密得到的。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，数据传输装置40还包括获取模块430以及存储模块440；
获取模块430，用于向第二设备发送第一证书之前，获取第一公钥以及第一私钥；
存储模块440，用于存储第一私钥；
收发模块410，还用于将第一公钥以及第一设备标识发送至认证服务器，以使认证服务器采用目标私钥对第一公钥以及第一设备标识进行签名，得到第一证书；
收发模块410，还用于接收认证服务器发送的第一证书。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，数据传输装置40还包括解密模块450以及生成模块460；
解密模块450，用于接收认证服务器发送的第一证书之后，采用目标公钥对第一证书进行解密，得到第一目标签名，其中，目标公钥以及目标私钥为认证服务器生成的密钥对；
生成模块460，用于对第一公钥以及第一设备标识进行哈希计算，得到第一目标摘要；
存储模块440，还用于若第一目标签名与第一目标摘要一致，则存储第一证书。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，
解密模块450，还用于接收第二设备发送的第二证书之后，采用目标公钥对第二证书进行解密，得到第二数字签名，其中，目标公钥为认证服务器生成的公钥；
获取模块430，还用于从第二证书中获取第二待验证公钥以及第二待验证标识；
生成模块460，还用于对第二待验证公钥以及第二待验证标识进行哈希计算，得到第二消息摘要；
确定模块420，还用于若第二消息摘要与第二数字签名一致，则确定第二证书为有效证书；
确定模块420，具体用于将第二证书中的第二待验证公钥作为第二公钥，并将第二证书中的第二待验证标识作为第二设备标识。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，数据传输装置40还包括加密模块470；
加密模块470，用于向第二设备发送数据访问请求之前，采用第二公钥对请求数据进行加密，得到数据访问请求；或者，采用所述第一私钥对请求数据进行加密，得到所述数据访问请求；
收发模块410，还用于向第二设备发送数据访问请求之后，向第二设备发送数据访问请求，以使第二设备对数据访问请求进行解密得到请求数据，若所述数据访问请求是采用所述第二公钥加密得到的，则所述第二设备采用所述第二私钥对所述数据访问请求进行解密，若所述数据访问请求是采用所述第一私钥加密得到的，则所述第二设备采用所述第一公钥对所述数据访问请求进行解密；
或，
解密模块450，还用于接收第二设备发送的目标数据之后，若目标数据为第二设备采用第二私钥对原始数据进行加密得到的，则采用第二公钥对目标数据进行解密，得到原始数据；若目标数据为第二设备采用第一公钥对原始数据进行加密得到的，则采用第一私钥对目标数据进行解密，得到原始数据。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，
获取模块430，还用于根据第二证书确定第二公钥以及第二设备标识之 后，获取第一设备存储的第二设备标识集合，其中，第二设备标识集合包括已针对第一设备注册的N个第二注册设备标识，N为大于或等于1的整数；
确定模块420，还用于若第二设备标识与第二设备标识集合中的一个第二注册设备标识匹配成功，则确定第二设备标识为已注册标识。
可选地，在上述图14所对应的实施例的基础上，本申请实施例提供的数据传输装置40的另一实施例中，数据传输装置40还包括通信模块480；
通信模块480，用于向第二设备发送第一证书，并接收第二设备发送的第二证书之前，当第二设备与第一设备启动蓝牙功能时，与第二设备建立蓝牙连接，以使第二设备与第一设备之间建立通信连接；
或，
通信模块480，还用于向第二设备发送第一证书，并接收第二设备发送的第二证书之前，当第二设备与第一设备连入同一无线热点时，与第二设备建立通信连接；
或，
通信模块480，还用于向第二设备发送第一证书，并接收第二设备发送的第二证书之前，扫描显示于第二设备上的二维码，与第一设备建立通信连接，其中，二维码包括第二设备标识。
本申请实施例还提供了一种数据传输装置，可部署于终端上，如图15所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。在本申请实施例中，以终端为手机为例进行说明：
图15示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图15，手机包括：射频(radio frequency，RF)电路510、存储器520、输入单元530(包括触控面板531以及其他输入设备532)、显示单元540(包括显示面板541)、传感器550、音频电路560(连接扬声器561和传声器562)、无线保真(wireless fidelity，WiFi)模块570、处理器580、以及电源590等部件。本领域技术人员可以理解，图15中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
下面结合图15对手机的构成部件进行介绍：
存储器520可用于存储软件程序以及模块，处理器580通过运行存储在存储器520的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他 易失性固态存储器件。
处理器580是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器520内的软件程序和/或模块，以及调用存储在存储器520内的数据，执行手机的各种功能和处理数据。可选的，处理器580可包括一个或多个处理单元；可选的，处理器580可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器580中。
手尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。
上述实施例中由终端所执行的步骤可以基于该图15所示的终端结构。
本申请实施例中还提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，该处理器执行计算机程序时，实现前述各个实施例描述方法的步骤。
本申请实施例中还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现前述各个实施例描述方法的步骤。
本申请实施例中还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时，实现前述各个实施例描述方法的步骤。
可以理解的是，在本申请的具体实施方式中，涉及到用户信息，车载信息，行车数据等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (20)

  1. 一种数据传输的方法，由第二设备执行，包括：
    接收第一设备发送的第一证书，并向所述第一设备发送第二证书；
    若所述第一证书以及所述第二证书均为有效证书，则根据所述第一证书确定第一公钥以及第一设备标识，其中，所述第一公钥以及第一私钥为所述第一设备生成的密钥对，所述第一设备标识为所述第一设备对应的标识；
    若所述第一设备标识以及第二设备标识均为已注册标识，则接收所述第一设备发送的数据访问请求，其中，所述数据访问请求为所述第一设备采用第二公钥或所述第一私钥加密得到的，所述第二公钥为所述第一设备根据所述第二证书获取到的，所述第二公钥以及第二私钥为所述第二设备生成的密钥对，所述第二设备标识为所述第二设备对应的标识；
    响应所述第一设备发送的数据访问请求，向所述第一设备发送目标数据，其中，所述目标数据为所述第二设备采用所述第一公钥或所述第二私钥加密得到的。
  2. 根据权利要求1所述的方法，所述向所述第一设备发送第二证书之前，所述方法还包括：
    获取所述第二公钥以及所述第二私钥；
    存储所述第二私钥；
    将所述第二公钥以及所述第二设备标识发送至认证服务器，以使所述认证服务器采用目标私钥对所述第二公钥以及所述第二设备标识进行签名，得到所述第二证书；
    接收所述认证服务器发送的所述第二证书。
  3. 根据权利要求2所述的方法，所述接收所述认证服务器发送的所述第二证书之后，所述方法还包括：
    采用目标公钥对所述第二证书进行解密，得到第二目标签名，其中，所述目标公钥以及所述目标私钥为所述认证服务器生成的密钥对；
    对所述第二公钥以及所述第二设备标识进行哈希计算，得到第二目标摘要；
    若所述第二目标签名与所述第二目标摘要一致，则存储所述第二证书。
  4. 根据权利要求1所述的方法，所述接收第一设备发送的第一证书之后，所述方法还包括：
    采用目标公钥对所述第一证书进行解密，得到第一数字签名，其中，所述目标公钥为认证服务器生成的公钥；
    从所述第一证书中获取第一待验证公钥以及第一待验证标识；
    对所述第一待验证公钥以及所述第一待验证标识进行哈希计算，得到第一消息摘要；
    若所述第一消息摘要与所述第一数字签名一致，则确定所述第一证书为 有效证书；
    所述根据所述第一证书确定第一公钥以及第一设备标识，包括：
    将所述第一证书中的所述第一待验证公钥作为所述第一公钥，并将所述第一证书中的所述第一待验证标识作为所述第一设备标识。
  5. 根据权利要求1所述的方法，所述响应所述第一设备发送的数据访问请求，向所述第一设备发送目标数据，包括：
    若所述数据访问请求为所述第一设备采用所述第二公钥加密得到的，则采用所述第二私钥对所述数据访问请求进行解密，得到请求数据；若所述数据访问请求为所述第一设备采用所述第一私钥加密得到的，则采用所述第一公钥对所述数据访问请求进行解密，得到请求数据；
    根据所述请求数据获取原始数据；
    采用所述第二私钥对所述原始数据进行加密，得到所述目标数据；或者，采用所述第一公钥对所述原始数据进行加密，得到所述目标数据；
    向所述第一设备发送所述目标数据，以使所述第一设备对所述目标数据进行解密得到所述原始数据，若所述目标数据是采用所述第二私钥加密得到的，则所述第一设备采用所述第二公钥对所述目标数据解密，若所述目标数据是采用所述第一公钥加密得到的，则所述第一设备采用所述第一私钥对所述目标数据解密。
  6. 根据权利要求1所述的方法，所述根据所述第一证书确定第一公钥以及第一设备标识之后，所述方法还包括：
    获取所述第二设备存储的第一设备标识集合，其中，所述第一设备标识集合包括已针对所述第二设备注册的M个第一注册设备标识，所述M为大于或等于1的整数；
    若所述第一设备标识与所述第一设备标识集合中的一个第一注册设备标识匹配成功，则确定所述第一设备标识为已注册标识。
  7. 根据权利要求6所述的方法，所述方法还包括：
    显示所述第一设备标识集合；
    响应针对所述第一设备标识集合中K个第一注册设备标识的删除操作，从所述第一设备标识集合中移除所述K个第一注册设备标识，得到更新后的第一设备标识集合，其中，所述K为大于或等于1，且小于或等于所述M的整数；
    所述方法还包括：
    显示标识添加控件；
    响应针对所述标识添加控件的选择操作，显示标识添加区域；
    响应针对所述标识添加区域的输入操作，在所述第一设备标识集合中添加T个第一注册设备标识，得到更新后的第一设备标识集合，其中，所述T为大于或等于1整数。
  8. 根据权利要求1至7中任一项所述的方法，所述接收所述第一设备发送的第一证书，并向所述第一设备发送第二证书之前，所述方法还包括：
    当所述第二设备与所述第一设备启动蓝牙功能时，与所述第一设备建立蓝牙连接，以使所述第二设备与所述第一设备之间建立通信连接；
    或，
    当所述第二设备与所述第一设备连入同一无线热点时，与所述第一设备建立通信连接；
    或，
    显示二维码，其中，所述二维码包括所述第二设备标识；
    当所述第一设备扫描所述二维码时，与所述第一设备建立通信连接；
    或，
    显示信息输入区域；
    响应针对所述信息输入区域输入的所述第一设备标识，与所述第一设备建立通信连接。
  9. 一种数据传输的方法，由第一设备执行，包括：
    向第二设备发送第一证书，并接收所述第二设备发送的第二证书；
    若所述第一证书以及所述第二证书均为有效证书，则根据所述第二证书确定第二公钥以及第二设备标识，其中，所述第二公钥以及第二私钥为所述第二设备生成的密钥对，所述第二设备标识为所述第二设备对应的标识；
    若第一设备标识以及所述第二设备标识均为已注册标识，则向所述第二设备发送数据访问请求，其中，所述数据访问请求为所述第一设备采用所述第二公钥或第一私钥加密得到的，第一公钥以及所述第一私钥为所述第一设备生成的密钥对，所述第一设备标识为所述第一设备对应的标识；
    接收所述第二设备发送的目标数据，其中，所述目标数据为所述第二设备采用所述第一公钥或所述第二私钥加密得到的。
  10. 根据权利要求9所述的方法，所述向第二设备发送第一证书之前，所述方法还包括：
    获取所述第一公钥以及所述第一私钥；
    存储所述第一私钥；
    将所述第一公钥以及所述第一设备标识发送至认证服务器，以使所述认证服务器采用目标私钥对所述第一公钥以及所述第一设备标识进行签名，得到所述第一证书；
    接收所述认证服务器发送的所述第一证书。
  11. 根据权利要求10所述的方法，所述接收所述认证服务器发送的所述第一证书之后，所述方法还包括：
    采用目标公钥对所述第一证书进行解密，得到第一目标签名，其中，所述目标公钥以及所述目标私钥为所述认证服务器生成的密钥对；
    对所述第一公钥以及所述第一设备标识进行哈希计算，得到第一目标摘要；
    若所述第一目标签名与所述第一目标摘要一致，则存储所述第一证书。
  12. 根据权利要求9所述的方法，所述接收所述第二设备发送的第二证书之后，所述方法还包括：
    采用目标公钥对所述第二证书进行解密，得到第二数字签名，其中，所述目标公钥为认证服务器生成的公钥；
    从所述第二证书中获取第二待验证公钥以及第二待验证标识；
    对所述第二待验证公钥以及所述第二待验证标识进行哈希计算，得到第二消息摘要；
    若所述第二消息摘要与所述第二数字签名一致，则确定所述第二证书为有效证书；
    所述根据所述第二证书确定第二公钥以及第二设备标识，包括：
    将所述第二证书中的所述第二待验证公钥作为所述第二公钥，并将所述第二证书中的所述第二待验证标识作为所述第二设备标识。
  13. 根据权利要求9所述的方法，所述向所述第二设备发送数据访问请求之前，所述方法还包括：
    采用所述第二公钥对请求数据进行加密，得到所述数据访问请求；或者，采用所述第一私钥对请求数据进行加密，得到所述数据访问请求；
    所述向所述第二设备发送数据访问请求之后，所述方法还包括：
    向所述第二设备发送数据访问请求，以使所述第二设备对数据访问请求进行解密得到所述请求数据，若所述数据访问请求是采用所述第二公钥加密得到的，则所述第二设备采用所述第二私钥对所述数据访问请求进行解密，若所述数据访问请求是采用所述第一私钥加密得到的，则所述第二设备采用所述第一公钥对所述数据访问请求进行解密；
    所述接收所述第二设备发送的目标数据之后，所述方法还包括：
    若所述目标数据为所述第二设备采用所述第二私钥对原始数据进行加密得到的，则采用所述第二公钥对所述目标数据进行解密，得到所述原始数据；
    若所述目标数据为所述第二设备采用所述第一公钥对原始数据进行加密得到的，则采用所述第一私钥对所述目标数据进行解密，得到所述原始数据。
  14. 根据权利要求9所述的方法，所述根据所述第二证书确定第二公钥以及第二设备标识之后，所述方法还包括：
    获取所述第一设备存储的第二设备标识集合，其中，所述第二设备标识集合包括已针对所述第一设备注册的N个第二注册设备标识，所述N为大于或等于1的整数；
    若所述第二设备标识与所述第二设备标识集合中的一个第二注册设备标识匹配成功，则确定所述第二设备标识为已注册标识。
  15. 根据权利要求9至14中任一项所述的方法，所述向第二设备发送第一证书，并接收所述第二设备发送的第二证书之前，所述方法还包括：
    当所述第二设备与所述第一设备启动蓝牙功能时，与所述第二设备建立蓝牙连接，以使所述第二设备与所述第一设备之间建立通信连接；
    或，
    当所述第二设备与所述第一设备连入同一无线热点时，与所述第二设备建立通信连接；
    或，
    扫描显示于所述第二设备上的二维码，与所述第一设备建立通信连接，其中，所述二维码包括所述第二设备标识。
  16. 一种数据传输装置，包括：
    收发模块，用于接收第一设备发送的第一证书，并向所述第一设备发送第二证书；
    确定模块，用于若所述第一证书以及所述第二证书均为有效证书，则根据所述第一证书确定第一公钥以及第一设备标识，其中，所述第一公钥以及第一私钥为所述第一设备生成的密钥对，所述第一设备标识为所述第一设备对应的标识；
    所述收发模块，还用于若所述第一设备标识以及第二设备标识均为已注册标识，则接收所述第一设备发送的数据访问请求，其中，所述数据访问请求为所述第一设备采用第二公钥或所述第一私钥加密得到的，所述第二公钥为所述第一设备根据所述第二证书获取到的，所述第二公钥以及第二私钥为第二设备生成的密钥对，所述第二设备标识为所述第二设备对应的标识；
    所述收发模块，还用于响应所述第一设备发送的数据访问请求，向所述第一设备发送目标数据，其中，所述目标数据为所述第二设备采用所述第一公钥或所述第二私钥加密得到的。
  17. 一种数据传输装置，包括：
    收发模块，用于向第二设备发送第一证书，并接收所述第二设备发送的第二证书；
    确定模块，用于若所述第一证书以及所述第二证书均为有效证书，则根据所述第二证书确定第二公钥以及第二设备标识，其中，所述第二公钥以及第二私钥为所述第二设备生成的密钥对，所述第二设备标识为所述第二设备对应的标识；
    所述收发模块，还用于若第一设备标识以及所述第二设备标识均为已注册标识，则向所述第二设备发送数据访问请求，其中，所述数据访问请求为第一设备采用所述第二公钥或第一私钥加密得到的，第一公钥以及所述第一私钥为所述第一设备生成的密钥对，所述第一设备标识为所述第一设备对应的标识；
    所述收发模块，还用于若接收所述第二设备发送的目标数据，其中，所述目标数据为所述第二设备采用所述第一公钥或所述第二私钥加密得到的。
  18. 一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至8中任一项所述的方法的步骤，或，权利要求9至15中任一项所述的方法的步骤。
  19. 一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法的步骤，或，权利要求9至15中任一项所述的方法的步骤。
  20. 一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现权利要求1至8中任一项所述的方法的步骤，或，权利要求9至15中任一项所述的方法的步骤。
PCT/CN2023/078315 2022-05-16 2023-02-27 一种数据传输的方法、相关装置、设备以及存储介质 WO2023221591A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210530907.3 2022-05-16
CN202210530907.3A CN115150091A (zh) 2022-05-16 2022-05-16 一种数据传输的方法、相关装置、设备以及存储介质

Publications (1)

Publication Number Publication Date
WO2023221591A1 true WO2023221591A1 (zh) 2023-11-23

Family

ID=83405844

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/078315 WO2023221591A1 (zh) 2022-05-16 2023-02-27 一种数据传输的方法、相关装置、设备以及存储介质

Country Status (2)

Country Link
CN (1) CN115150091A (zh)
WO (1) WO2023221591A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150091A (zh) * 2022-05-16 2022-10-04 腾讯科技（深圳）有限公司 一种数据传输的方法、相关装置、设备以及存储介质
CN115795428B (zh) * 2023-02-01 2023-05-09 中汽研软件测评(天津)有限公司 一种自动驾驶数据的安全读取认证方法、系统和电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110113238A1 (en) * 2009-11-09 2011-05-12 Cisco Technology, Inc. Certificate enrollment with purchase to limit sybil attacks in peer-to-peer network
CN109639427A (zh) * 2017-10-09 2019-04-16 华为技术有限公司 一种数据发送的方法及设备
CN112491933A (zh) * 2020-12-25 2021-03-12 四川虹微技术有限公司 一种局域网加密通信方法和存储介质
CN114168924A (zh) * 2022-02-10 2022-03-11 亿次网联(杭州)科技有限公司 一种基于数字证书的群成员相互认证的方法和系统
CN115150091A (zh) * 2022-05-16 2022-10-04 腾讯科技（深圳）有限公司 一种数据传输的方法、相关装置、设备以及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110113238A1 (en) * 2009-11-09 2011-05-12 Cisco Technology, Inc. Certificate enrollment with purchase to limit sybil attacks in peer-to-peer network
CN109639427A (zh) * 2017-10-09 2019-04-16 华为技术有限公司 一种数据发送的方法及设备
CN112491933A (zh) * 2020-12-25 2021-03-12 四川虹微技术有限公司 一种局域网加密通信方法和存储介质
CN114168924A (zh) * 2022-02-10 2022-03-11 亿次网联(杭州)科技有限公司 一种基于数字证书的群成员相互认证的方法和系统
CN115150091A (zh) * 2022-05-16 2022-10-04 腾讯科技（深圳）有限公司 一种数据传输的方法、相关装置、设备以及存储介质

Also Published As

Publication number Publication date
CN115150091A (zh) 2022-10-04

Similar Documents

Publication Publication Date Title
WO2022262078A1 (zh) 基于零信任安全的访问控制方法、设备及存储介质
WO2023221591A1 (zh) 一种数据传输的方法、相关装置、设备以及存储介质
US20190207762A1 (en) Communication method, apparatus and system, electronic device, and computer readable storage medium
CN111742531B (zh) 简档信息共享
US20060143295A1 (en) System, method, mobile station and gateway for communicating with a universal plug and play network
WO2016201811A1 (zh) 身份认证方法、装置及系统
WO2019178942A1 (zh) 一种进行ssl握手的方法和系统
KR20180095873A (ko) 무선 네트워크 접속 방법 및 장치, 및 저장 매체
JP2003500923A (ja) セキュア通信をイニシャライズし、装置を排他的にペアリングする方法、コンピュータ・プログラムおよび装置
KR20090067155A (ko) 보안 연결 확립 방법, 보안 핸드쉐이크 서비스 확립 방법 및 컴퓨터 판독가능 매체
US20080137859A1 (en) Public key passing
KR20160127167A (ko) 다중 팩터 인증 기관
KR20160025531A (ko) Scep 및 각각의 관리 애플리케이션을 이용하여 디바이스에 대한 인증서를 등록하는 방법
KR101974062B1 (ko) 클라우드 하드웨어 모듈 기반 전자 서명 방법
CN112311537A (zh) 基于区块链的设备接入认证系统及方法
US20220311625A1 (en) Certificate Application Method And Device
JP2017525236A (ja) 増強メディア・プラットフォームによる通信の安全確保
WO2023071751A1 (zh) 一种认证方法和通信装置
WO2022001225A1 (zh) 身份凭据的申请方法、身份认证的方法、设备及装置
Jian et al. Internet of things (IOT) cybersecurity based on the hybrid cryptosystem
CN112235331A (zh) 一种数据传输处理方法及设备
KR101256114B1 (ko) 다수의 ｍａｃ검증서버에 의한 메시지인증코드 검증 방법 및 시스템
KR102263053B1 (ko) 근거리 영역 네트워크(lan) 환경에서 기기 간 데이터 동기화가 가능한 데이터베이스 구조 및 이를 이용한 데이터 동기화 방법
CN115146320A (zh) 一种证书查询方法及装置
WO2023240587A1 (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: 23806552

Country of ref document: EP

Kind code of ref document: A1