WO2021226989A1 - 通信的方法和通信装置 - Google Patents

通信的方法和通信装置 Download PDF

Info

Publication number
WO2021226989A1
WO2021226989A1 PCT/CN2020/090460 CN2020090460W WO2021226989A1 WO 2021226989 A1 WO2021226989 A1 WO 2021226989A1 CN 2020090460 W CN2020090460 W CN 2020090460W WO 2021226989 A1 WO2021226989 A1 WO 2021226989A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
identification information
encryption mode
cryptographic algorithm
algorithm suite
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2020/090460
Other languages
English (en)
French (fr)
Inventor
郭志鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP20935848.0A priority Critical patent/EP4138335A4/en
Priority to CN202080004098.1A priority patent/CN113207322B/zh
Priority to PCT/CN2020/090460 priority patent/WO2021226989A1/zh
Priority to JP2022568488A priority patent/JP7508589B2/ja
Priority to KR1020227042579A priority patent/KR102885085B1/ko
Publication of WO2021226989A1 publication Critical patent/WO2021226989A1/zh
Priority to US17/987,694 priority patent/US12413412B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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/3236—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 using cryptographic hash functions
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/3226—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 using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—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 using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication

Definitions

  • This application relates to the field of communication, and more specifically, to a communication method and communication device.
  • the automotive open system architecture (AUTOSAR) alliance defines the transport layer security (TLS) protocol and the datagram transport layer security (datagram transport) layer security, DLTS) protocol.
  • TLS transport layer security
  • DLTS datagram transport layer security
  • IP Internet Protocol
  • the present application provides a communication method, which can improve the transmission reliability and communication efficiency in the device handshake process.
  • a communication method includes: a second device receives authentication request information from a first device, where the authentication request information includes identification information of the first device; and the second device according to a first mapping The relationship determines the cryptographic algorithm suite corresponding to the identification information of the first device, and the first mapping relationship is used to indicate the corresponding relationship between the identification information of at least one device and the at least one cryptographic algorithm suite; the second device is based on the cryptographic algorithm
  • the kit generates authentication response information; the second device sends the authentication response information to the first device.
  • the second device can determine the cryptographic algorithm suite used in the communication process with the first device according to the stored first mapping relationship. Therefore, the first device and the second device do not need to transmit a list of supported cryptographic algorithm suites during the handshake process, thereby reducing the amount of data transmitted during the handshake process, and improving transmission reliability and communication efficiency.
  • the method before the second device sends the authentication response information to the first device, the method further includes: the second device determines that the pre-configured second list contains The identification information of the first device, and the second list includes the identification information of the device that needs to be authenticated.
  • the second device can determine the source legitimacy of the first device when it determines that the identification information of the first device is stored in the second list. That is, the second list can replace the cookie field allocation process in the original handshake process. Therefore, a malicious device can be prevented from forging a false source to initiate the authentication process, and the second device can directly ignore the authentication request of an illegal device according to the second list, thereby reducing the processing burden of the second device and increasing the difficulty of the attacker.
  • the authentication request information further includes the first device certificate of the first device and/or the first signature value used by the first device; and/or the authentication The response information also includes the second device certificate of the second device and/or the second signature value used by the second device.
  • the authentication request information further includes the first random number used by the first device and/or the first temporary public key used by the first device; the authentication response The information also includes a second random number used by the second device and/or a second temporary public key used by the second device.
  • the authentication request information further includes a first password; and/or the authentication response information further includes a second password, which is based on a pre-stored password by the second device The pre-shared key and the cipher algorithm suite are generated.
  • the first device and the second device can generate a password instead of the device certificate based on the determined cipher algorithm suite and the pre-stored pre-shared key. Since the length of the password is much smaller than the device certificate, the amount of interactive data in the handshake interaction process is greatly reduced, and the efficiency and reliability of the handshake are improved.
  • the device after replacing the device certificate with a password, the device no longer needs to verify the root signature in the device certificate, but instead performs a symmetric encryption and decryption operation on the password.
  • the symmetric encryption and decryption calculation speed is much higher than the verification speed, so the handshake efficiency can be improved.
  • the authentication request information further includes a first temporary public key used by the first device; the authentication response information further includes a second temporary public key used by the second device. Key and identification information of the second device.
  • each cryptographic algorithm suite in the at least one cryptographic algorithm suite meets forward security requirements.
  • the method further includes: the second device determines a message encryption mode used for communication with the first device, and the message encryption mode includes a full encryption mode and a press One of the encryption modes is required.
  • the second device determining a message encryption mode used for communication with the first device includes: the second device determines the communication with the first device according to a second mapping relationship.
  • the message encryption mode corresponding to the identification information of the device, and the second mapping relationship is used to indicate the correspondence between the identification information of the at least one device and the at least one message encryption mode.
  • the method when the message encryption mode is an on-demand encryption mode, the method further includes: the second device generates a communication message, and the communication message It includes the following fields: plain text identification, plain text data, cipher text identification, and cipher text data.
  • the plaintext data contains the stream encryption key generation seed of the ciphertext data.
  • the stream encryption algorithm cannot be used.
  • the stream encryption key generation seed of the ciphertext data can be stored in the plaintext data, so that the user datagram protocol can support the stream encryption algorithm.
  • a communication method includes: a first device determines a cryptographic algorithm suite corresponding to identification information of a second device according to a third mapping relationship, where the third mapping relationship is used to indicate the status of at least one device The corresponding relationship between the identification information and at least one cryptographic algorithm suite; the first device generates authentication request information according to the cryptographic algorithm suite, and the authentication request information includes the identification information of the first device; Send the authentication request information; the first device receives the authentication response information from the second device.
  • the first device can determine the cryptographic algorithm suite used in the communication process with the second device according to the stored third mapping relationship. Therefore, the first device and the second device do not need to transmit a list of supported cryptographic algorithm suites during the handshake process, thereby reducing the amount of data transmitted during the handshake process, and improving transmission reliability and communication efficiency.
  • the method before the first device sends the authentication request information to the second device, the method further includes: the first device determines that the first device is in the pre-configured first list The identification information of the second device is included, and the first list includes the identification information of the device that needs to be authenticated.
  • the first device can determine the source legitimacy of the second device when it determines that the identification information of the second device is stored in the second list.
  • the authentication request information further includes the device certificate of the first device and/or the first signature value used by the first device; and/or the authentication response information It also includes the second device certificate of the second device and/or the second signature value used by the second device.
  • the authentication request information further includes a first password
  • the first password is generated by the first device according to a pre-stored pre-shared key and the cryptographic algorithm suite;
  • the authentication response information further includes the second password.
  • the first device and the second device can generate a password instead of the device certificate based on the determined cipher algorithm suite and the pre-stored pre-shared key. Since the length of the password is much smaller than the device certificate, the amount of interactive data in the handshake interaction process is greatly reduced, and the efficiency and reliability of the handshake are improved.
  • the device after replacing the device certificate with a password, the device no longer needs to verify the root signature in the device certificate, but instead performs a symmetric encryption and decryption operation on the password.
  • the symmetric encryption and decryption calculation speed is much higher than the verification speed, so the handshake efficiency can be improved.
  • the authentication request information further includes the first temporary public key used by the first device; the authentication response information further includes the second temporary public key used by the second device. Key and identification information of the second device.
  • the authentication request information further includes the first random number used by the first device and/or the first temporary public key used by the first device
  • the authentication response information also includes a second random number used by the second device and/or a second temporary public key used by the second device.
  • each cryptographic algorithm suite in the at least one cryptographic algorithm suite meets forward security requirements.
  • the method further includes: the first device determines a message encryption mode used for communication with the second device, and the message encryption mode includes a full encryption mode and a press One of the encryption modes is required.
  • the first device determining a message encryption mode used for communication with the second device includes: the first device determines the communication with the second device according to a fourth mapping relationship.
  • the message encryption mode corresponding to the identification information of the device, and the fourth mapping relationship is used to indicate the correspondence between the identification information of the at least one device and the at least one message encryption mode.
  • the method further includes: the first device generates a communication message, and the communication message includes The following fields: plain text identification, plain text data, cipher text identification, cipher text data.
  • the plaintext data contains the stream encryption key generation seed of the ciphertext data.
  • the stream encryption algorithm cannot be used.
  • the stream encryption key generation seed of the ciphertext data can be stored in the plaintext data, so that the user datagram protocol can support the stream encryption algorithm.
  • a communication device in a third aspect, includes a transceiving unit and a processing unit: the transceiving unit is configured to receive authentication request information from a first device, where the authentication request information includes identification information of the first device; The unit is configured to determine a cryptographic algorithm suite corresponding to the identification information of the first device according to a first mapping relationship, where the first mapping relationship is used to indicate a correspondence between the identification information of at least one device and the at least one cryptographic algorithm suite; The processing unit is also used to generate authentication response information according to the cryptographic algorithm suite; the transceiver unit is also used to send the authentication response information to the first device.
  • the processing unit is further configured to determine that the pre-configured second list includes the identification information of the first device, and the second list includes the identification information of the device that needs to be authenticated. Identification information.
  • the authentication request information further includes the first device certificate of the first device and/or the first signature value used by the first device; and/or the authentication The response information also includes the second device certificate of the communication device and/or the second signature value used by the communication device.
  • the authentication request information further includes a first password; and/or the authentication response information further includes a second password, which is pre-stored by the processing unit according to The pre-shared key and the cryptographic algorithm suite are generated.
  • the authentication request information further includes the first random number used by the first device and/or the first temporary public key used by the first device; the authentication response The information also includes the second random number used by the communication device and/or the second temporary public key used by the communication device.
  • the authentication request information further includes the first temporary public key used by the first device; the authentication response information further includes the second temporary public key used by the communication device And the identification information of the communication device.
  • each cryptographic algorithm suite in the at least one cryptographic algorithm suite meets forward security requirements.
  • the processing unit is further configured to determine a message encryption mode used for communication with the first device, and the message encryption mode includes a full encryption mode and an on-demand encryption mode one of the.
  • the processing unit is specifically configured to determine the message encryption mode corresponding to the identification information of the first device according to the second mapping relationship, and the second mapping relationship uses For indicating the correspondence between the identification information of at least one device and the at least one message encryption mode.
  • the processing unit when the message encryption mode is an on-demand encryption mode, the processing unit is also used to generate a communication message, and the communication message includes the following fields : Plain text identification, plain text data, cipher text identification, cipher text data.
  • the plaintext data contains the stream encryption key generation seed of the ciphertext data.
  • a communication device in a fourth aspect, includes a transceiving unit and a processing unit: the processing unit is configured to determine a cryptographic algorithm suite corresponding to identification information of a second device according to a third mapping relationship, and the third mapping relationship It is used to indicate the correspondence between identification information of at least one device and at least one cryptographic algorithm suite; the processing unit is also used to generate authentication request information according to the cryptographic algorithm suite, where the authentication request information includes the identification information of the communication device; The transceiver unit is configured to send the authentication request information to the second device; the transceiver unit is also configured to receive authentication response information from the second device.
  • the processing unit is further configured to determine that the pre-configured first list includes the identification information of the second device, and the first list includes the identification information of the device that needs to be authenticated. Identification information.
  • the authentication request information further includes the device certificate of the communication device and/or the first signature value used by the communication device; and/or the authentication response information further includes The second device certificate of the second device and/or the second signature value used by the second device.
  • the authentication request information further includes a first password, which is generated by the communication device according to a pre-stored pre-shared key and the cryptographic algorithm suite; and /Or the authentication response information further includes the second password.
  • the authentication request information further includes the first random number used by the communication device and/or the first temporary public key used by the communication device; the authentication response information also It includes the second random number used by the second device and/or the second temporary public key used by the second device.
  • the authentication request information further includes the first temporary public key used by the communication device; the authentication response information further includes the second temporary public key used by the second device And the identification information of the second device.
  • each cryptographic algorithm suite in the at least one cryptographic algorithm suite meets forward security requirements.
  • the processing unit is further configured to determine a message encryption mode used for communication with the second device, and the message encryption mode includes a full encryption mode and an on-demand encryption mode one of the.
  • the processing unit is specifically configured to determine the message encryption mode corresponding to the identification information of the second device according to the fourth mapping relationship, and the fourth mapping relationship uses For indicating the correspondence between the identification information of at least one device and the at least one message encryption mode.
  • the processing unit when the message encryption mode is an on-demand encryption mode, is further configured to generate a communication message, and the communication message includes the following fields: Plain text identification, plain text data, cipher text identification, cipher text data.
  • the plaintext data contains the stream encryption key generation seed of the ciphertext data.
  • a communication device including a processor.
  • the processor is coupled with the memory, and can be used to execute instructions in the memory to implement the method in any one of the foregoing first aspect to the second aspect or the first aspect to the second aspect.
  • a processor including: an input circuit, an output circuit, and a processing circuit.
  • the processing circuit is configured to receive a signal through the input circuit and transmit the signal through the output circuit, so that the processor executes the method in any one of the foregoing first aspect to the second aspect or the first aspect to the second aspect.
  • the above-mentioned processor may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the processing circuit may be a transistor, a gate circuit, a flip-flop, and various logic circuits.
  • the input signal received by the input circuit may be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit may be, for example, but not limited to, output to the transmitter and transmitted by the transmitter, and the input circuit and output
  • the circuit can be the same circuit, which is used as an input circuit and an output circuit at different times.
  • the embodiments of the present application do not limit the specific implementation manners of the processor and various circuits.
  • a processing device including a processor. It may also include a memory, the memory is used to store instructions, the processor is used to read the instructions stored in the memory, and can receive signals through a receiver, and transmit signals through a transmitter, so as to execute the first aspect to the second aspect or the first aspect. Aspect to the method in any one of the possible implementation manners of the second aspect.
  • processors there are one or more processors, and one or more memories.
  • the memory may be integrated with the processor, or the memory and the processor may be provided separately.
  • the memory can be a non-transitory (non-transitory) memory, such as a read only memory (ROM), which can be integrated with the processor on the same chip, or can be set in different On the chip, the embodiment of the present application does not limit the type of the memory and the setting mode of the memory and the processor.
  • ROM read only memory
  • sending instruction information may be a process of outputting instruction information from the processor
  • receiving capability information may be a process of receiving input capability information by the processor.
  • the processed output data may be output to the transmitter, and the input data received by the processor may come from the receiver.
  • the transmitter and receiver can be collectively referred to as a transceiver.
  • the processing device in the seventh aspect described above may be a chip, and the processor may be implemented by hardware or software.
  • the processor When implemented by hardware, the processor may be a logic circuit, an integrated circuit, etc.; when implemented by software
  • the processor may be a general-purpose processor, which is implemented by reading software codes stored in the memory.
  • the memory may be integrated in the processor, may be located outside the processor, and exist independently.
  • a computer program product includes: a computer program (also called code, or instruction), which when the computer program is executed, causes the computer to execute the first to second aspects or The method in any one of the possible implementation manners of the first aspect to the second aspect.
  • a computer program also called code, or instruction
  • a computer-readable storage medium stores a computer program (also called code, or instruction) when it runs on a computer, so that the computer executes the first aspect to the first aspect mentioned above.
  • a computer program also called code, or instruction
  • a communication system including the communication device in the foregoing third aspect or any one of the possible implementation manners of the third aspect, and/or, any one of the foregoing fourth aspect or the fourth aspect may be implemented The communication device in the mode.
  • FIG. 1 is a schematic flow chart of the TLS protocol.
  • Fig. 2 is a schematic flowchart of a handshake process based on a pre-shared key.
  • FIGS 3 and 4 are schematic diagrams of communication systems applicable to the methods provided in the embodiments of the present application.
  • 5 to 7 are schematic flowcharts of communication methods provided by embodiments of the present application.
  • FIG. 8 is a schematic diagram of the format of a communication message in an on-demand encryption mode provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of the format of a communication message in a full encryption mode provided by an embodiment of the present application.
  • 10 to 12 are schematic flowcharts of communication methods provided by embodiments of the present application.
  • FIGS 13 and 14 are schematic block diagrams of communication devices provided by embodiments of the present application.
  • the AUTOSAR Alliance has defined the TLS protocol and the DLTS protocol for the secure communication of in-vehicle Ethernet.
  • the TLS protocol and DTLS protocol defined in AUTOSAR are the same as the TLS protocol and DTLS protocol defined in the traditional Ethernet protocol. That is, the TLS protocol and DTLS protocol defined by AUTOSAR are the transplantation of the TLS protocol and the DTLS protocol on the vehicle Ethernet.
  • FIG. 1 shows the flow of the TLS protocol.
  • the TLS protocol includes a handshake process and a communication process.
  • the root certificate, secret key (SK) #1, and device certificate #1 are preset in the car interior part #1.
  • the device certificate #1 includes the identity (ID) #1 of the car interior part #1 and the public key (public key, PK)#1 and root signature.
  • the root certificate, SK#2, and device certificate #2 are preset in the interior part #2, and the device certificate #2 includes the ID#2, PK#2, and root signature of the interior part #2.
  • the handshake process may include the following steps, for example:
  • the vehicle interior component #1 generates a random number (random) #1.
  • connection request #1 includes the random number #1 and the list of cryptographic algorithm suites supported by the in-vehicle component #1.
  • the vehicle interior component #2 generates a cookie field.
  • In-vehicle component #2 sends a verification request (HelloVerifyRequest) to in-vehicle component #1.
  • the cookie field is included in the authentication request.
  • connection request #2 sends connection request #2 to in-vehicle component #2.
  • the connection request #2 includes a random number #1, a list of cryptographic algorithm suites supported by the car interior part #1, and a cookie field.
  • the vehicle interior component #2 generates a random number #2.
  • Car interior part #2 selects a supported cryptographic algorithm suite according to the list of cryptographic algorithm suites supported by car interior part #1.
  • the vehicle interior component #2 generates a temporary public-private key pair #2 according to the selected cryptographic algorithm suite.
  • the temporary public-private key pair #2 includes a temporary private key (temporary secret key, tempSK) #2 and a temporary public key (temporary public key, tempPK) #2.
  • the vehicle interior part #2 calculates the signature (Sign) #2.
  • Sign#2 Sign(ID#2
  • In-vehicle component #2 sends a connection response (ServerHello) to in-vehicle component #1.
  • the connection response includes device certificate #2, random number #2, tempPK#2, and Sign#2.
  • the vehicle interior component #1 verifies the legitimacy of the equipment certificate #2.
  • the vehicle interior component #1 verifies the legality of Sign#2.
  • the vehicle interior component #1 generates a temporary public and private key pair #1.
  • the temporary public and private key pair #1 includes tempSK#1 and tempPK#1.
  • In-vehicle component #1 sends a ChangeCipherSpec (ChangeCipherSpec) to in-vehicle component #2.
  • the change password standard includes device certificate #1, tempPK#1 and Sign#1.
  • the in-vehicle component #1 calculates a pre-shared key (PSK) #1 according to a key derivation function (KDF).
  • PSK#1 KDF (ID#1, ID#2, tempSK#1, tempPK#2).
  • the vehicle interior component #2 verifies the legitimacy of the equipment certificate #1.
  • PSK#2 KDF (ID#1, ID#2, tempSK#2, tempPK#1).
  • SessionKey#2 KDF (PSK#2, random#1, random#2).
  • in-vehicle component #1 and in-vehicle component #2 complete the steps of identity legality authentication, cryptographic algorithm suite negotiation, and SessionKey negotiation of the two parties through a handshake process. Further, in the communication process:
  • the in-vehicle component #1 and the in-vehicle component #2 use the SessionKey to encrypt and transmit the communication message.
  • the PSK-based handshake process is shown in Figure 2.
  • the vehicle interior component #1 generates a random number (random) #1.
  • In-vehicle component #1 sends connection request #3 to in-vehicle component #2.
  • the connection request #3 includes the random number #1, the list of cryptographic algorithm suites supported by the in-vehicle component #1, and PSK_ID.
  • Car interior part #2 selects a supported cryptographic algorithm suite according to the list of cryptographic algorithm suites supported by car interior part #1, and selects PSK according to PSK_ID.
  • the in-vehicle component #2 generates a temporary public-private key pair #2 according to the selected cryptographic algorithm suite.
  • Temporary public and private key pairs include tempSK#2 and tempPK#2.
  • Car interior component #2 uses PSK to encrypt the message.
  • In-vehicle component #2 sends an encrypted connection response to in-vehicle component #1.
  • the connection response includes random numbers #2 and tempPK#2.
  • the in-vehicle component #1 decrypts the message to obtain a random number #2.
  • the vehicle interior component #1 generates a temporary public and private key pair #1.
  • the temporary public and private key pair #1 includes tempSK#1 and tempPK#1.
  • Car interior component #1 uses PSK to encrypt the message.
  • the vehicle interior component #1 sends the encrypted change password standard to the vehicle interior component #2.
  • the change password standard includes tempPK#1.
  • PSK#1 KDF (ID#1, ID#2, tempSK#1, tempPK#2).
  • In-vehicle component #1 is based on KDF SessionKey#1.
  • SessionKey#1 KDF (PSK#1, random#1, random#2).
  • PSK#2 KDF (ID#1, ID#2, tempSK#2, tempPK#1).
  • SessionKey#2 KDF (PSK#2, random#1, random#2).
  • the in-vehicle component #1 and the in-vehicle component #2 use the SessionKey to encrypt and transmit the communication message.
  • the PSK-based handshake process does not need to verify the legality of the device certificate, thus improving the efficiency of the handshake.
  • IP Internet Protocol
  • the transmission of a large amount of data between different in-car components will increase the burden of the in-car forwarding components; the existing cryptographic algorithm suite is incompatible with the hardware capabilities of the in-car components, so deployment is difficult.
  • the real-time performance is poor; based on the transmission control protocol (TCP), connections need to be established between different in-vehicle components.
  • TCP transmission control protocol
  • the DTLS protocol is obtained by modifying the TLS protocol in order to adapt to the UDP protocol. Since the UDP protocol is unreliable, packets may be lost and out of order. In order to deal with these situations, the DTLS protocol has made the following changes on the basis of the TLS protocol:
  • DTLS adds a message timeout retransmission mechanism to deal with the problem of message loss
  • DTLS removes the support of stream encryption algorithms, that is, the cipher algorithm suite supported by DTLS is a subset of the cipher algorithm suite supported by TLS.
  • the transmission of a large amount of data between different in-vehicle components will increase the burden of the in-vehicle forwarding components; the existing cryptographic algorithm suite is incompatible with the hardware capabilities of the in-vehicle components, so deployment is difficult and real-time Poor performance; in the pursuit of high real-time in-vehicle communication, the stream encryption algorithm is a commonly used and efficient encryption method, but the DTLS protocol does not support the stream encryption algorithm; and, after the secure channel between different in-vehicle components is established, all the transmitted Data must be encrypted.
  • there are many data transmissions in the car that do not need to be encrypted and only need to ensure the integrity (for example, vehicle control instructions). Therefore, encrypting all data will cause a waste of computing resources and use the session key too many times. Will increase the risk of attack.
  • the embodiments of the present application provide a communication method, in order to reduce the interaction process and the amount of communication data in the handshake process, thereby improving transmission efficiency and communication quality.
  • Fig. 3 is a schematic diagram of a communication system suitable for the communication method of an embodiment of the present application.
  • the method provided by the embodiment of the present application can be applied to a scenario in which in-vehicle components of an intelligent networked vehicle conduct secure communication through an in-vehicle Ethernet.
  • the electronic control unit (ECU)#1 and ECU#2 shown in FIG. 3 communicate through the on-board Ethernet.
  • In-vehicle components may include telematics processors that communicate with the outside world, such as telematics box (T-Box), gateway (GW), advanced driver assistance system (ADAS), and man-machine interface (human-machine interface, HMI), vehicle control unit (VCU), etc.
  • T-Box telematics box
  • GW gateway
  • ADAS advanced driver assistance system
  • HMI human-machine interface
  • VCU vehicle control unit
  • the two interior components can be directly connected. Or, the two interior components can also be transferred through other interior components.
  • ECU#1 and ECU#2 are connected through GW.
  • Fig. 5 shows a schematic flowchart of a communication method provided by an embodiment of the present application.
  • the method 500 shown in FIG. 5 may be applied to the communication system shown in FIG. 3 or FIG. 4, the first device shown in FIG. 5 may be ECU #1 in FIG. 3 or FIG. 4, and the second device may be the communication system shown in FIG. Or ECU#2 in Figure 4.
  • the method 500 may include S501 to S506, and each step is described in detail below.
  • the first device determines a cryptographic algorithm suite corresponding to the identification information of the second device according to the third mapping relationship.
  • the cryptographic algorithm suite corresponding to the identification information of the second device is a cryptographic algorithm suite used for communication between the first device and the second device.
  • the first device or the second device may be T-Box, GW, ADAS, HMI, or VCU, etc.
  • the third mapping relationship is used to indicate the corresponding relationship between the identification information of the at least one device and the at least one cryptographic algorithm suite.
  • the identification information of the at least one device may be the identification information of the device for which the first device needs to be authenticated.
  • the first device can determine the cryptographic algorithm suite used to communicate with the device that needs authentication according to the third mapping relationship. It can be understood that the identification information of the at least one device includes the identification information of the second device.
  • the first device can determine the cryptographic algorithm suite corresponding to the identification information of the second device according to the third mapping relationship, the first device can default to the second device as a device that requires authentication, and the second device can be determined Authenticity.
  • the identification information of the device may include one or more of the following: the type of the device, the identifier (ID) of the device, the Internet protocol (IP) address of the device, and the media access control (MAC) of the device address.
  • ID the identifier
  • IP Internet protocol
  • MAC media access control
  • the embodiment of the present application does not limit the correspondence between the identification information of at least one device and the at least one cryptographic algorithm suite.
  • Table 1 shows an example of one-to-one correspondence between identification information of at least one device and at least one cryptographic algorithm suite.
  • the first device can determine that the identification information of the device #A corresponds to the cryptographic algorithm suite #A, the identification information of the device #B corresponds to the cryptographic algorithm suite #B, and the identification information of the device #C corresponds to the cryptographic algorithm suite #B. It is the cryptographic algorithm suite #C, and the identification information of the device #D corresponds to the cryptographic algorithm suite #D.
  • Table 2 shows an example of a many-to-one relationship between the identification information of at least one device and the at least one cryptographic algorithm suite.
  • the first device can determine that the identification information of the device #A, the identification information of the device #B, and the identification information of the device #C correspond to the cryptographic algorithm suite #A, and the identification information of the device #D corresponds to Cipher Algorithm Suite #B.
  • the correspondence between the identification information of the at least one device and the at least one cryptographic algorithm suite indicated by the third mapping relationship may be determined according to the hardware capabilities of the first device and the at least one device. For example, if the first device and device #A both have an E-safety vehicle intrusion protection application (EVITA) full-level hardware security module (HSM), then the first device can be connected to The cryptographic algorithm suite used by the device #A for secure communication is determined to be ECDHE_ECDSA_AES_128_GCM_Whirlpool. In other words, the identification information of the device #A can be associated with ECDHE_ECDSA_AES_128_GCM_Whirlpool.
  • EVITA E-safety vehicle intrusion protection application
  • HSM full-level hardware security module
  • the temporary elliptic curve Diffie-Hellman (ephemeral elliptic curve Diffie-Hellman, ECDHE) represents the key agreement algorithm
  • the elliptic curve digital signature algorithm (elliptic curve digital signature algorithm, ECDSA) represents the digital signature algorithm
  • the advanced encryption standard (advanced encryption standard) ,AES)_128_(galois/countermode,GCM) represents the authentication encryption algorithm
  • the Whirlpool algorithm is a hash algorithm.
  • the third mapping relationship may be pre-stored in the first device.
  • the third mapping relationship may be pre-stored in the first device when the device manufacturer generates the first device; or, the third mapping relationship may be pre-stored in the first device by the user before using the first device. Or, the third mapping relationship may also be pre-stored in the first device by the software provider.
  • the first device can determine the cryptographic algorithm suite used for communication with the second device according to the saved third mapping relationship. Therefore, the first One device does not need to transmit a list of cipher algorithm suites supported by itself to the second device, thereby reducing the amount of transmitted data.
  • each cipher algorithm suite in the at least one cipher algorithm suite satisfies the forward security requirement. That is to say, when defining the cipher algorithm suite used by the first device to communicate with at least one other device, only the key agreement algorithm that meets the forward security requirements is used, for example, temporary Diffie-Hellman (ephemeral Diffie-Hellman, DHE) or ECDHE.
  • DHE temporary Diffie-Hellman
  • ECDHE ECDHE
  • S502 The first device generates authentication request information according to the determined cryptographic algorithm suite.
  • the generation of the authentication request information by the first device according to the determined cryptographic algorithm suite can be understood to mean that the first device generates the parameters included in the authentication request information according to the determined cryptographic algorithm suite.
  • the authentication request information includes the identification information of the first device (in the following, ID#1 is taken as an example for description).
  • the authentication request information may also include one or more of the following parameters: the first temporary public key used by the first device (tempPK#1 is used as an example below), and the first random number (random number) used by the first device. ) (Take random#1 as an example below), the device certificate of the first device (take device certificate #1 as an example below), the first signature value used by the first device (take Sign#1 below as an example) Take cipher#1 as an example for description), the first password (take cipher#1 as an example for description below).
  • random#1 and tempPK#1 are used to generate the session key used for communication between the first device and the second device
  • the device certificates #1, Sign#1, and cipher#1 are used to verify the legality of the first device. verify.
  • the device certificate #1 includes ID#1, the first public key used by the first device (PK#1 is used as an example for description below), and the root signature. It can be understood that since the device certificate #1 includes ID#1, the authentication request information may not include the identification information of the first device. In this case, it can be understood that the identification information of the first device is included in the device certificate# 1 in.
  • tempPK#1 is generated by the first device according to the determined cryptographic algorithm suite.
  • the first device generates a first temporary public-private key pair according to the key agreement algorithm in the cryptographic algorithm suite.
  • the first temporary public-private key pair includes tempPK#1 and the first temporary private key (tempSK#1 is taken as an example below) Two data.
  • Sign#1 is generated by the first device according to the determined cryptographic algorithm suite.
  • the first device constructs the first message (in the following, msg#1 is taken as an example for description), and the content of msg#1 is ⁇ ID#1
  • tempPK#1 ⁇ ; further, the first device uses The first private key (take SK#1 as an example below) is the key, and msg#1 is encrypted according to the digital signature algorithm specified in the cryptographic algorithm suite to get Sign#1, Sign#1 Sign(ID#1
  • cipher#1 is generated by the first device according to the pre-stored PSK and cipher algorithm suite. Among them, the pre-stored PSK corresponds to the second device.
  • the first device constructs msg#1, and the content of msg#1 is ⁇ ID#1
  • random#1 ⁇ ; further, the first device uses PSK as the key, and pairs msg#1 according to the symmetric encryption algorithm in the cryptographic algorithm suite. Encryption is performed to generate cipher#1, cipher#1 Enc PSK (ID#1
  • the pre-stored PSK may be generated by the first device during the prior identity authentication process with the second device.
  • the first device and the second device may store the same PSK.
  • the first device may determine the PSK corresponding to the second device from the one or more saved PSKs according to the identification information of the second device (in the following, ID#2 is taken as an example).
  • the pre-stored PSK may also be a PSK saved by the first device according to a pre-configured first PSK list.
  • the pre-configured first PSK list may include the PSK corresponding to the identification information of at least one device.
  • the pre-configured first PSK list may be understood as the first PSK list is pre-stored in the first device.
  • the first PSK list may be pre-stored in the first device when the device manufacturer generates the first device; or the first PSK list may be pre-stored in the first device by the user before using the first device
  • the first PSK list may also be pre-stored in the first device by the software provider.
  • the first device may determine the PSK corresponding to ID#2 according to the pre-configured first PSK list.
  • the method 500 may further include: S507.
  • the first device determines that the pre-configured first list includes the identification information of the second device.
  • the pre-configured first list can be understood as the first list is pre-stored in the first device.
  • the first list may be pre-stored in the first device when the device manufacturer generates the first device; or the first list may be pre-stored in the first device by the user before using the first device; or , The first list may also be pre-stored in the first device by the software provider.
  • S507 can also be executed before S502 or before S501. Or, S507 and S501 may be one step.
  • the first list defines the authentication process of which devices the first device needs to communicate securely with, that is, the first list includes the identification information of the devices that the first device needs to be authenticated.
  • the content of the first list may be determined according to the application scenario of the first device. For example, if the first device is ADAS, in the autonomous driving business function, ADAS needs to communicate securely with HMI, VCU, body domain controller, chassis domain controller, sensors and other devices, so it is in the first list pre-configured in ADAS The identification information of the above-mentioned equipment can be saved.
  • the first device may query whether the identification information of the second device is saved in the pre-configured first list.
  • the first list saves the identification information of the second device, it means that the first device needs to perform identity authentication on the second device, and the first device initiates an authentication process to the second device. For example, in a case where the first device determines that the identification information of the second device is included in the first list, it generates authentication request information or sends the authentication request information to the second device.
  • the identification information of the second device is not saved in the first list, it means that there is no need to perform identity authentication between the first device and the second device, and the first device will not initiate an authentication process to the second device. For example, if the first device determines that the identification information of the second device is not included in the first list, it does not generate the authentication request information or does not send the authentication request information to the second device.
  • the above-mentioned solution for the first device to determine that the identification information of the second device is included in the first list can also be implemented separately, that is, it can be used as an independent embodiment without being attached to other embodiments in this specification.
  • the first device is preset with the first list, so that the first device sends an authentication request to the second device after determining that the identification information of the second device is stored in the first list Information, so that unnecessary authentication requests can be avoided.
  • the method 500 may further include: S509, the first device determines a message encryption mode used for communication with the second device.
  • S509 may also be executed before S507, or may be executed before S502, or may be executed before S501, or S509 may also be executed after S503.
  • S509 and S507 may be one step
  • S509 and S501 may be one step.
  • the message encryption mode includes one of a full encryption mode and an on-demand encryption mode.
  • the communication message sent between the first device and the second device may include ciphertext data.
  • the ciphertext data is the data obtained by encrypting the communication data by the first device and the second device according to the cryptographic algorithm suite.
  • Figure 8 shows the communication message format in full encryption mode. As shown in Figure 8, in the full encryption mode, only the message sequence number is not encrypted, and all other data is ciphertext data.
  • the communication message sent between the first device and the second device includes: plaintext identifier, plaintext data, ciphertext identifier, ciphertext data.
  • the plaintext identifier is used to identify the length of the plaintext data, or used to indicate that the field after the plaintext identifier is plaintext data.
  • Plain text data is data that is not encrypted.
  • the stream encryption key generation seed of the ciphertext data may be included in the plaintext data.
  • Figure 9 shows the format of a communication message sent between the first device and the second device in the on-demand encryption mode. It can be seen from FIG. 9 that after the plain text identification, the data before the cipher text identification is plain text data, and the data after the cipher text identification is cipher text data.
  • the plaintext data may include: message serial numbers, stream key seeds, entertainment data, vehicle control instructions, hash values, and so on.
  • the ciphertext data may include: positioning data, map data, user privacy, and so on.
  • the embodiment of the present application does not limit the manner in which the first device determines the message encryption mode.
  • the first device may determine the message encryption mode according to the content of the data transmitted with the second device. For example, if map data, positioning data, etc. are transmitted between the first device and the second device, it is determined that the message encryption mode is the full encryption mode. If the first device and the second device not only transmit data such as map data, but also transmit entertainment data, control instructions, etc., the message encryption mode is determined to be the on-demand encryption mode, that is, the map data and other data are encrypted, and the entertainment data, Control commands, etc. are not encrypted.
  • the first device may send instruction information to the second device, indicating the message encryption mode used for communication with the second device.
  • the indication information sent by the first device may be a bool variable. If the value of the bool variable is "1", it indicates that the message encryption mode used for communication between the first device and the second device is full encryption Mode; if the value of the Boolean variable is "0", it indicates that the message encryption mode used for communication between the first device and the second device is the on-demand encryption mode.
  • the indication information may also be carried in the authentication request information.
  • the first device may determine the message encryption mode corresponding to the identification information of the second device according to the fourth mapping relationship, where the fourth mapping relationship is used to indicate the difference between the identification information of the at least one device and the at least one message encryption mode. Correspondence between.
  • the embodiment of the present application does not limit the correspondence between the identification information of at least one device and the at least one message encryption mode.
  • Table 3 shows an example of one-to-one correspondence between identification information of at least one device and at least one message encryption mode.
  • the first device can determine that the identification information of the device #A and the device #B corresponds to the full encryption mode, and the identification information of the device #C and the device #D corresponds to the on-demand encryption mode.
  • Table 4 shows an example of a many-to-one relationship between the identification information of at least one device and the at least one message encryption mode.
  • the first device can determine that the identification information corresponding to the identification information of the device #A and the identification information of the device #B are in full encryption mode, and the identification information corresponding to the identification information of the device #C and the identification information of the device #D is on-demand Encryption mode.
  • the on-demand encryption mode of the communication message in the on-demand encryption mode, data that does not need to be encrypted can be transmitted in plain text, thereby reducing the amount of data in the encrypted payload and increasing the encryption rate. Thereby improving the communication efficiency.
  • the stream encryption key generation seed of the ciphertext data can be stored in the plaintext data, so that the stream encryption algorithm can be supported on the UDP protocol to further improve the communication efficiency.
  • the information indicated by the third mapping relationship, the information indicated by the fourth mapping relationship, the content contained in the first PSK list and the content contained in the first list may be stored in the same list; or, the information indicated by the third mapping relationship, the fourth One or more of the mapping relationship indication information, the content included in the first PSK list, and the content included in the first list may be stored in the same list.
  • Table 5 shows an example in which the information indicated by the third mapping relationship, the information indicated by the fourth mapping relationship, the content contained in the first PSK list and the content contained in the first list are stored in the same list.
  • the identification information of the device #A to the device #D is the identification information of the device that the first device needs to be authenticated; and Table 5 shows the cryptographic algorithm suite #1 corresponding to the identification information of the device #A to the device #D, respectively To cipher algorithm suite #4, PSK#1 to PSK#4, message encryption mode.
  • S503 The first device sends authentication request information to the second device.
  • the second device receives the authentication request information from the first device.
  • the authentication request information may include one or more of the following parameters: ID#1, tempPK#1, random#1, device certificate #1, Sign#1, cipher#1.
  • the authentication request information may include: ID#1, tempPK#1, and random#1.
  • One-way authentication is performed between the first device and the second device, that is, the first device authenticates the legality of the second device, and the second device does not authenticate the legality of the first device.
  • the first device is a smart driving domain controller and the second device is a sensor
  • the smart driving domain controller prevents the sensors from sending forged data.
  • the sensor needs to be authenticated, and the sensor does not need to authenticate the intelligent driving domain controller.
  • the authentication request information may include: device certificates #1, Sign#1, tempPK#1, and random#1.
  • the first device and the second device perform two-way authentication, that is, the first device authenticates the legality of the second device, and the second device also authenticates the legality of the first device.
  • the authentication response information may include: ID#1, cipher#1, and tempPK#1.
  • the second device determines a cryptographic algorithm suite corresponding to the identification information of the first device according to the first mapping relationship.
  • the cryptographic algorithm suite corresponding to the identification information of the first device is the cryptographic algorithm suite used for communication between the first device and the second device.
  • the first mapping relationship is used to indicate the corresponding relationship between the identification information of the at least one device and the at least one cryptographic algorithm suite. Specifically, for the description of the first mapping relationship, reference may be made to the description of the third mapping relationship in S501, which is concise as an example, and will not be described in detail in this embodiment of the present application.
  • step S504 is the same as the cipher algorithm suite determined in step S501.
  • the first mapping relationship may be pre-stored in the second device.
  • the first mapping relationship may be pre-stored in the second device when the device manufacturer generates the second device; or the first mapping relationship may be pre-stored in the second device by the user before using the second device.
  • the first mapping relationship may also be pre-stored in the second device by the software provider.
  • the second device can default to the first device to be a device that requires authentication, so that the first device can be determined Authenticity.
  • the second device can determine the cryptographic algorithm suite used in the communication process with the first device according to the stored first mapping relationship. Therefore, the first device does not need to transmit the cipher algorithm suite supported by itself to the second device, thereby reducing the amount of data in the transmission process and improving the transmission reliability and communication efficiency.
  • each cipher algorithm suite in the at least one cipher algorithm suite satisfies the forward security requirement.
  • the authentication request information sent by the first device to the second device may include the device certificate #1 and/or Sign#1. Then, the second device may first verify the legality of the device certificate #1 before determining the cryptographic algorithm suite.
  • the second device uses the second public key used by the second device in the root certificate (PK#2 is taken as an example for description below) to verify the root signature stored in the device certificate #1. After the verification is passed, the second device determines the cryptographic algorithm suite.
  • PKI#2 is taken as an example for description below
  • the second device After determining the cryptographic algorithm suite, the second device continues to verify the legality of Sign#1.
  • the second device may construct msg#1 according to ID#1 included in the device certificate #1 and random#1 and tempPK#1 included in the authentication request information. Further, the second device may construct msg#1 according to the PK# included in the device certificate #1. 1 Verify the legality of Sign#1. After the verification is passed, the second device executes the subsequent authentication process.
  • the second device uses the pre-stored PSK corresponding to the identification information of the first device as the key, and decrypts the cipher# according to the symmetric encryption algorithm in the cipher algorithm suite. 1Get ID#1. Further, the second device determines whether ID#1 obtained by decrypting cipher#1 is consistent with ID#1 in the authentication request information. If they are inconsistent, the authentication fails, and if they are consistent, the subsequent authentication process continues. S505: The second device generates authentication response information according to the determined cryptographic algorithm suite.
  • the authentication response information can include one or more of the following parameters:
  • the identification information of the second device in the following, ID#2 is used as an example
  • the second random number used by the second device random#2 is used as an example in the following
  • the second device certificate of the second device lower In the text, device certificate #2 is used as an example for description
  • the second signature value used by the second device (Sign#1 is used as an example below)
  • the second temporary public key used by the second device hereinafter referred to as tempPK# 2 is an example for description
  • the second password in the following, cipher#2 is used as an example for description
  • the device certificate #2 includes ID#2, PK#2, and root signature. random#2 and tempPK#2 are used to generate a session key used for communication between the first device and the second device, and device certificates #2, Sign#2, and cipher#2 are used to verify the legitimacy of the second device.
  • the second device may generate the authentication response information according to the determined cryptographic algorithm suite, and it may also be understood that the second device generates the parameters included in the authentication response information.
  • the second device can generate a second temporary public-private key pair according to the determined cryptographic algorithm suite.
  • the second temporary public-private key pair includes two data, tempPK#2 and the second temporary private key (tempSK#2 is used as an example below). .
  • the second device can also construct a second message (in the following, msg#2 is taken as an example for description), and the content of msg#2 is ⁇ ID#2
  • tempPK#2 ⁇ ; further, the second device Take the second private key used (in the following, take SK#2 as an example for description) as the key, encrypt msg#2 according to the digital signature algorithm specified in the cryptographic algorithm suite to obtain Sign#2, Sign#2 Sign(ID #2
  • the second device can also generate cipher#2 according to the pre-stored PSK and cipher algorithm suite.
  • the second device constructs msg#2, and the content of msg#2 is ⁇ ID#2
  • random#2 ⁇ ; further, the second device uses PSK as the key, and pairs msg#2 according to the symmetric encryption algorithm in the cryptographic algorithm suite. Encryption is performed to generate cipher#2, cipher#2 Enc PSK (ID#2
  • " means connection, Enc PSK () means using PSK as the key and encrypting with symmetric encryption algorithm.
  • the pre-stored PSK may be generated by the first device during the prior identity authentication process with the second device.
  • the second device may determine the PSK corresponding to the first device from one or more saved PSKs according to ID#1.
  • the pre-stored PSK may also be a PSK saved by the second device according to a pre-configured second PSK list.
  • the pre-configured second PSK list may include the PSK corresponding to the identification information of at least one device.
  • the pre-configured second PSK list can be understood as the second PSK list is pre-stored in the second device.
  • the first PSK list may be pre-stored in the second device when the device manufacturer generates the second device; or the second PSK list may be pre-stored in the second device by the user before using the second device ;
  • the second PSK list may also be pre-stored in the second device by the software provider.
  • the second device may determine the PSK corresponding to ID#1 according to the pre-configured second PSK list.
  • the second device may not generate the aforementioned parameters temporarily.
  • the second device may generate a cookie field, carry the generated cookie field in the authentication response information, and send it to the first device. Further, after receiving the authentication request information carrying the cookie field sent by the first device, the second device may determine the authenticity and source legitimacy of the first device according to the cookie field in the authentication request information.
  • the method 500 may further include: S508.
  • the second device determines that the pre-configured second list contains the identification information of the first device.
  • the pre-configured second list may be understood as the second list is pre-stored in the second device.
  • the second list may be pre-stored in the second device when the device manufacturer generates the second device; or, the second list may be pre-stored in the first device by the user before using the second device; or , The second list may also be pre-stored in the second device by the software provider.
  • S508 can also be executed before S505 or before S504. Or, S508 and S504 can be one step.
  • the second list defines the authentication process of which devices the second device needs to perform secure communication with, that is, the second list includes the identification information of the devices that the second device needs to be authenticated.
  • the description of the second list reference may be made to the description of the first list in S507 above.
  • the embodiment of the present application will not elaborate.
  • the second device may query whether the identification information of the first device is stored in the second list configured in advance.
  • the second list stores the identification information of the first device, it indicates that the source of the first device is legal, and the second device responds to the authentication request of the first device. For example, when the second device determines that the identification information of the first device is included in the second list, it generates authentication response information or sends the authentication response information to the second device.
  • the identification information of the first device is not saved in the second list, it indicates that the source of the first device is illegal, and the second device does not respond to the authentication request of the first device. For example, when the second device determines that the identification information of the first device is not included in the second list, it does not generate authentication response information or does not send authentication response information to the second device.
  • the above-mentioned solution for the second device to determine that the identification information of the first device is included in the second list can also be implemented separately, that is, it can be used as an independent embodiment without being attached to other embodiments in this specification.
  • the second device is pre-configured with the second list, so that the second device can determine that the source of the first device is legal when it determines that the identification information of the first device is stored in the second list. It means that the second list can replace the cookie field allocation process in the original handshake process. Therefore, a malicious device can be prevented from forging a false source to initiate the authentication process, and the second device can directly ignore the authentication request of an illegal device according to the second list, thereby reducing the processing burden of the second device and increasing the difficulty of the attacker.
  • the method 500 may further include: S510.
  • the second device determines a message encryption mode used for communication with the first device.
  • S510 may also be executed before S508, or may be executed before S505, or may be executed before S504, or S510 may also be executed after S506.
  • S510 and S508 may be one step
  • S509 and S504 may be one step.
  • the message encryption mode includes one of a full encryption mode and an on-demand encryption mode.
  • the communication message sent between the first device and the second device may include ciphertext data.
  • the ciphertext data is the data obtained by encrypting the communication data by the first device and the second device according to the cryptographic algorithm suite.
  • Figure 8 shows the communication message format in full encryption mode. As shown in Figure 8, in the full encryption mode, only the message sequence number is not encrypted, and all other data is ciphertext data.
  • the communication message sent between the first device and the second device includes: plaintext identifier, plaintext data, ciphertext identifier, ciphertext data.
  • the plaintext identifier is used to identify the length of the plaintext data, or used to indicate that the field after the plaintext identifier is plaintext data.
  • Plain text data is data that is not encrypted.
  • the stream encryption key generation seed of the ciphertext data may be included in the plaintext data.
  • Figure 9 shows the format of the communication message in the on-demand encryption mode. It can be seen from FIG. 9 that after the plain text identification, the data before the cipher text identification is plain text data, and the data after the cipher text identification is cipher text data.
  • the plaintext data may include: message serial numbers, stream key seeds, entertainment data, vehicle control instructions, hash values, and so on.
  • the ciphertext data may include: positioning data, map data, user privacy, and so on.
  • the embodiment of the present application does not limit the manner in which the second device determines the message encryption mode.
  • the second device may determine the message encryption mode according to the instruction information from the first device, where the instruction information is used to indicate the message encryption mode used for communication between the first device and the second device.
  • the indication information received by the second device from the first device may be a bool variable. If the value of the bool variable is "1", it indicates the message used for communication between the first device and the second device The encryption mode is the full encryption mode; if the value of the Boolean variable is "0", it indicates that the message encryption mode used for communication between the first device and the second device is the on-demand encryption mode.
  • the second device may determine the message encryption mode corresponding to the identification information of the first device according to the second mapping relationship, and the second mapping relationship is used to indicate the difference between the identification information of the at least one device and the at least one message encryption mode.
  • the second mapping relationship may be made to the description of the fourth mapping relationship in S509 above.
  • the embodiment of the present application will not go into details.
  • the on-demand encryption mode of the communication message in the on-demand encryption mode, data that does not need to be encrypted can be transmitted in plain text, thereby reducing the amount of data in the encrypted payload and increasing the encryption rate. Thereby improving the communication efficiency.
  • the stream encryption key generation seed of the ciphertext data can be stored in the plaintext data, so that the stream encryption algorithm can be supported on the UDP protocol to further improve the communication efficiency.
  • the information indicated by the first mapping relationship, the information indicated by the second mapping relationship, the content contained in the second PSK list and the content contained in the second list may be stored in the same list; or, the information indicated by the first mapping relationship, the second One or more of the mapping relationship indication information, the content included in the second PSK list, and the content included in the second list may be stored in the same list.
  • Table 6 shows an example in which the information indicated by the first mapping relationship, the information indicated by the second mapping relationship, the content contained in the second PSK list and the content contained in the second list are stored in the same list.
  • the identification information of the device #E to the device #H is the identification information of the device that the second device needs to be authenticated; and Table 6 shows the cryptographic algorithm suite #1 corresponding to the identification information of the device #E to the device #H, respectively To cipher algorithm suite #4, PSK#1 to PSK#4, message encryption mode.
  • S506 The second device sends authentication response information to the first device.
  • the authentication response information may include one or more of the following parameters: random#2, device certificate #2, Sign#1, tempPK#2, cipher#2, ID#2.
  • the authentication response information may include: random#2, device certificate #2, Sign#1, tempPK#2.
  • the authentication response information may include: ID#2, tempPK#2, cipher#2.
  • the first device after receiving the authentication response information from the second device, the first device can verify the legality of the second device.
  • the first device verifies the legitimacy of the device certificate #2.
  • the first device queries the pre-configured first list according to ID#2 stored in the device certificate #2, and confirms whether the second device is a device that needs to be authenticated. If it is not, the authentication is terminated; if it is, the first device uses the PK#1 in the root certificate to verify the root signature in the device certificate #2.
  • the first device continues to verify Sign#2.
  • the first device may construct msg#2 according to ID#2 included in the device certificate #2 and random#2 and tempPK#2 included in the authentication response information. Further, the second device may construct msg#2 according to the PK# included in the device certificate #2. 2 Verify the legality of Sign#2.
  • the first device uses the prestored PSK corresponding to the second device as a key, and decrypts cipher#2 according to the symmetric encryption algorithm in the cipher algorithm suite to obtain ID#2. Further, the first device determines whether the ID#2 obtained by decrypting the cipher#2 is consistent with the ID#2 in the authentication response information, if they are inconsistent, the authentication fails, and if they are consistent, the authentication succeeds.
  • the PSK and session key used in this secure communication are calculated according to the existing process.
  • the communication process follows.
  • the first device and the second device can determine the cryptographic algorithm suite used in the communication process according to the saved mapping relationship. Therefore, the first device and the second device do not need to transmit a list of supported cryptographic algorithm suites during the handshake process, thereby reducing the amount of data transmitted during the handshake process, and improving transmission reliability and communication efficiency. In the case where the first device and the second device communicate through the forwarding component, the burden of the forwarding component can also be reduced.
  • the second device is pre-configured with the second list, so that the second device can determine that the source of the first device is legal when it determines that the identification information of the first device is stored in the second list. It means that the second list can replace the cookie field allocation process in the original handshake process. Therefore, a malicious device can be prevented from forging a false source to initiate the authentication process, and the second device can directly ignore the authentication request of an illegal device according to the second list, thereby reducing the processing burden of the second device and increasing the difficulty of the attacker.
  • an on-demand encryption mode of communication messages is defined.
  • data that does not need to be encrypted can be transmitted in plain text, thereby reducing the amount of data in the encrypted payload and increasing the encryption rate. Improved communication efficiency.
  • the stream encryption key generation seed of the ciphertext data can be stored in the plaintext data, so that the stream encryption algorithm can be supported on the UDP protocol to further improve the communication efficiency.
  • FIG. 10 is a schematic flowchart of a method 600 provided by another embodiment of the present application. As shown in FIG. 10, the method 600 may include S601 to S620, and each step is described in detail below.
  • the first device determines that a pre-configured first list contains identification information (ID#2) of the second device.
  • the first list includes identification information of devices that the first device needs to be authenticated.
  • the first device determines that ID#2 is included in the first list, the first device continues to perform the authentication process; if the first device determines that ID#2 is not included in the first list, the first device does not perform authentication with the second device process.
  • the first device determines a cipher algorithm suite and a message encryption mode corresponding to ID#2.
  • the first device may determine the cryptographic algorithm suite corresponding to ID#2 according to the third mapping relationship.
  • the first device may determine the message encryption mode corresponding to ID#2 according to the fourth mapping relationship.
  • S603 The first device generates random number #1.
  • the first device generates a first temporary public-private key pair according to the key agreement algorithm in the cryptographic algorithm suite.
  • the first temporary public-private key pair includes tempPK#1 and tempSK#1.
  • the first device generates a first signature value according to the digital signature algorithm in the cryptographic algorithm suite.
  • the first device constructs msg#1, and the content of msg#1 is ⁇ ID#1
  • S606 The first device sends authentication request information to the second device.
  • the authentication request information includes: device certificate #1, random#1, tempPK#1, and Sign#1.
  • the device certificate #1 includes: ID#1, PK#1, and root signature.
  • S607 The second device verifies the legitimacy of the device certificate #1.
  • the second device determines that ID#1 is stored in the second list configured in advance. If ID#1 is saved in the second list, the second device determines that the first device is a device that requires authentication; if ID#1 is not saved in the second list, the second device determines that the first device is a device that does not require authentication, Then terminate the authentication process.
  • the second device determines that the first device is a device that needs to be authenticated, the second device continues to use PK#2 to verify the root signature in the device certificate #1. If the verification is successful, the verification process is continued; if the verification fails, the verification process is terminated.
  • S608 The second device determines the cipher algorithm suite and the message encryption mode corresponding to ID#1.
  • the second device may determine the cryptographic algorithm suite corresponding to ID#1 according to the first mapping relationship.
  • the first device may determine the message encryption mode corresponding to ID#1 according to the second mapping relationship.
  • S609 The second device verifies the first signature value.
  • the second device may construct msg#1 according to ID#1 included in the device certificate #1 and random#1 and tempPK#1 included in the authentication request information. Further, the second device may construct msg#1 according to the PK# included in the device certificate #1. 1 Verify the legality of Sign#1. After the verification is passed, the second device executes the subsequent authentication process. If the verification fails, the verification fails.
  • S610 The second device generates a random number #2.
  • the second device generates a second temporary public-private key pair according to the key agreement algorithm in the cryptographic algorithm suite.
  • the second temporary public-private key pair includes tempPK#2 and tempSK#2.
  • the second device calculates the second signature value according to the digital signature algorithm in the cryptographic algorithm suite.
  • the second device constructs msg#2, and the content of msg#2 is ⁇ ID#2
  • S613 The second device sends authentication response information to the first device.
  • the authentication response information includes: device certificate #2, random#2, tempPK#2, Sign#2.
  • the device certificate #2 includes: ID#2, PK#2, and root signature.
  • S614 The second device calculates PSK#2.
  • KDF means calculating according to the key derivation function.
  • S615 The second device calculates the session key #2.
  • SessionKey#2 KDF (PSK#2, random#1, random#2).
  • KDF() means calculating according to the key derivation function.
  • S616 The first device verifies the legitimacy of the device certificate #2.
  • the first device determines that ID#2 is stored in the pre-configured first list according to ID#2 in device certificate #2. If ID#2 is stored in the first list, the first device determines that the second device is a device that requires authentication; if ID#2 is not stored in the first list, the first device determines that the second device is a device that does not require authentication, Then terminate the authentication process.
  • the first device determines that the second device is a device that needs to be authenticated, the first device continues to use PK#1 to verify the root signature in the device certificate #2. If the verification is successful, the verification process is continued; if the verification fails, the verification process is terminated.
  • S617 The first device verifies the second signature value.
  • the first device may construct msg#2 according to ID#2 included in the device certificate #2 and random#2 and tempPK#2 included in the authentication response information. Further, the first device may construct msg#2 according to the PK# included in the device certificate #2. 2 Verify the legality of Sign#2. After the verification is passed, the first device executes the subsequent authentication process. If the verification fails, the verification fails.
  • S618 The first device calculates PSK#1.
  • KDF() means calculating according to the key derivation function.
  • PSK#1 and PSK#2 are used in the embodiment of the present application to represent the PSK generated by the first device and the second device, respectively, this is only for distinguishing, and PSK#1 and PSK#2 should be considered equivalent.
  • S619 The first device calculates the session key #1.
  • SessionKey#1 KDF (PSK#1, random#1, random#2).
  • KDF() means calculating according to the key derivation function.
  • SessionKey#1 and SessionKey#2 are used in the embodiment of the present application to represent the SessionKey generated by the first device and the second device, respectively, this is only for distinguishing, and SessionKey#1 and SessionKey#2 should be considered equivalent.
  • the first device and the second device transmit the communication message according to the determined cipher algorithm suite and the message encryption mode.
  • the list of legal device identifications of the handshake source is recorded in the list pre-configured by the first device, which can prevent malicious devices from forging false sources to initiate denial of service attacks, and plays the role of the cookie field in the prior art.
  • the cookie field allocation process in the original TLS protocol and the DTLS protocol can be omitted, and an interactive process in the handshake process is reduced.
  • the second device can directly ignore the handshake request of the illegal device according to the pre-configured second list, so that the second device only performs the necessary handshake, which not only reduces the processing burden of the second device, but also increases the difficulty of the attacker's attack.
  • the cipher algorithm suite is corresponding to the identification information of the device, so that the first device and the second device can determine the cipher algorithm suite used in the communication process according to the saved mapping relationship, thereby eliminating the original TLS protocol Negotiation process with the cryptographic algorithm suite in the DTLS protocol, so that the first device and the second device do not need to transmit the list of cryptographic algorithm suites supported by the device during the handshake process, thereby reducing the amount of data transmitted during the handshake process and improving transmission reliability Sex and communication efficiency.
  • FIG. 11 is a schematic flowchart of a method 700 provided by another embodiment of the present application.
  • the method 700 may include S701 to S716, where S702 to S703 are the same as S603 to S604 in the method 600, and S706 Steps to S716 are the same as S610 to S620 in the method 600.
  • S701 to S716 are the same as S603 to S604 in the method 600
  • S706 Steps to S716 are the same as S610 to S620 in the method 600.
  • S701 The first device determines a cipher algorithm suite and a message encryption mode corresponding to ID#2.
  • the first device may determine the cryptographic algorithm suite corresponding to ID#2 according to the third mapping relationship.
  • the first device may determine the message encryption mode corresponding to ID#2 according to the fourth mapping relationship.
  • the first device can determine the cryptographic algorithm suite corresponding to ID#2 according to the third mapping relationship, and the first device can assume that the second device is a device that requires authentication.
  • S704 The first device sends authentication response information to the second device.
  • the authentication response information includes: ID#1, random#1, tempPK#1.
  • S705 The second device determines a cipher algorithm suite and a message encryption mode corresponding to ID#1.
  • the second device may determine the cryptographic algorithm suite corresponding to ID#1 according to the first mapping relationship.
  • the first device may determine the message encryption mode corresponding to ID#1 according to the second mapping relationship.
  • the second device can determine the cryptographic algorithm suite corresponding to ID#1 according to the first mapping relationship, and the second device can default to the first device as a device that requires authentication.
  • the second device has not authenticated the legality of the first device’s identity, the second device can determine whether the first device is a device that requires authentication during the process of determining the cryptographic algorithm suite according to the first mapping relationship, which increases the attack Compared with the current one-way authentication handshake process, the difficulty of sending malicious handshake requests is improved.
  • the cipher algorithm suite is corresponding to the identification information of the device, so that the first device and the second device can determine the cipher algorithm suite used in the communication process according to the saved mapping relationship, thereby eliminating the original TLS protocol Negotiation process with the cryptographic algorithm suite in the DTLS protocol, so that the first device and the second device do not need to transmit the list of cryptographic algorithm suites supported by the device during the handshake process, thereby reducing the amount of data transmitted during the handshake process and improving transmission reliability Sex and communication efficiency.
  • FIG. 12 is a schematic flowchart of a method 800 provided by another embodiment of the present application.
  • the method 800 may include S801 to S817, where S802 to S803 are the same as S603 to S604 in the method 600, and S808 To S809 are the same as S610 to S611 in the method 600, S812 to S813 are the same as S614 to S615 in the method 600, and S815 to S817 are the same as S618 to S620 in the method 600.
  • S801 to S817 are the same as S603 to S604 in the method 600
  • S808 To S809 are the same as S610 to S611 in the method 600
  • S812 to S813 are the same as S614 to S615 in the method 600
  • S815 to S817 are the same as S618 to S620 in the method 600.
  • the embodiments of this application will not be described in detail. The remaining steps are described in detail below.
  • the first device determines a cipher algorithm suite, a message encryption mode, and PSK corresponding to ID#2.
  • the first device may determine the cryptographic algorithm suite corresponding to ID#2 according to the third mapping relationship.
  • the first device may determine the message encryption mode corresponding to ID#2 according to the fourth mapping relationship.
  • the first device may determine the PSK corresponding to ID#2 according to the pre-configured first PSK list.
  • S804 The first device calculates the first password.
  • the first device constructs msg#1, and the content of msg#1 is ⁇ ID#1
  • random#1 ⁇ ; further, the first device uses PSK as the key, and pairs msg#1 according to the symmetric encryption algorithm in the cryptographic algorithm suite. Encryption is performed to generate cipher#1, cipher#1 Enc PSK (ID#1
  • S805 The first device sends authentication response information to the second device.
  • the authentication response information includes: ID#1, cipher#1, tempPK#1.
  • S806 The second device determines the cipher algorithm suite, message encryption mode, and PSK corresponding to ID#1.
  • the second device may determine the cryptographic algorithm suite corresponding to ID#1 according to the first mapping relationship.
  • the second device may determine the message encryption mode corresponding to ID#1 according to the second mapping relationship.
  • the second device may determine the PSK corresponding to ID#1 according to the pre-configured second PSK list.
  • S807 The second device decrypts the first password.
  • the second device determines the cipher algorithm suite
  • the determined PSK is the key
  • S810 The second device calculates a second password.
  • the second device constructs msg#2, and the content of msg#2 is ⁇ ID#2
  • random#2 ⁇ ; further, the second device uses PSK as the key, and pairs msg#2 according to the symmetric encryption algorithm in the cryptographic algorithm suite. Encryption is performed to generate cipher#2, cipher#2 Enc PSK (ID#2
  • S811 The second device sends authentication response information to the first device.
  • the authentication response information includes: ID#2, tempPK#2, cipher#2.
  • S814 The first device decrypts the second password.
  • the first device determines the PSK as the key, and decrypts cipher#2 according to the symmetric encryption algorithm in the cipher algorithm suite to obtain ID#2. Further, the second device determines whether the ID#2 obtained by decrypting the cipher#2 is consistent with the ID#2 in the authentication response information, if they are inconsistent, the authentication fails, and if they are consistent, the subsequent authentication process is continued.
  • the cipher algorithm suite is corresponding to the identification information of the device, so that the first device and the second device can determine the cipher algorithm suite used in the communication process according to the saved mapping relationship, thereby eliminating the original TLS protocol Negotiation process with the cryptographic algorithm suite in the DTLS protocol, so that the first device and the second device do not need to transmit the list of cryptographic algorithm suites supported by the device during the handshake process, thereby reducing the amount of data transmitted during the handshake process and improving transmission reliability Sex and communication efficiency.
  • a cipher can be generated based on the pre-stored PSK to replace the device certificate. Since the length of the cipher is much smaller than the device certificate, the amount of interactive data in the handshake interaction process is greatly reduced, and the efficiency and reliability of the handshake are improved.
  • the device after using cipher to replace the device certificate, the device no longer needs to verify the root signature in the device certificate, but instead performs a symmetric encryption and decryption operation on the cipher.
  • the symmetric encryption and decryption operation speed is much higher than the verification speed, so it can improve the efficiency of handshake.
  • FIG. 13 is a schematic block diagram of a communication device 1000 provided by an embodiment of the present application.
  • the communication device 1000 may include: a transceiving unit 1010 and a processing unit 1020.
  • the communication device 1000 may correspond to the first device in the above method embodiment.
  • the communication apparatus 1000 may include a method for executing the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method executed by the first device in the method 800 in FIG. Unit.
  • the units in the communication device 1000 and the above-mentioned other operations and/or functions are used to implement the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method in FIG. 12, respectively.
  • the corresponding process executed by the first device in 800 It should be understood that the specific process for each unit to execute the foregoing corresponding steps has been described in detail in the foregoing method embodiment, and is not repeated here for brevity.
  • the communication device 1000 may correspond to the second device in the above method embodiment.
  • the communication apparatus 1000 may include a method for executing the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method executed by the second device in the method 800 in FIG. unit.
  • the units in the communication device 1000 and the above-mentioned other operations and/or functions are used to implement the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method in FIG. 12, respectively.
  • the corresponding process executed by the second device in 800 It should be understood that the specific process for each unit to execute the foregoing corresponding steps has been described in detail in the foregoing method embodiment, and is not repeated here for brevity.
  • transceiving unit 1010 in the communication device 1000 may correspond to the transceiver 2010 in the communication device 2000 shown in FIG. 14, and the processing unit 1020 in the communication device 1000 may correspond to the communication device shown in FIG. Processor 2020 in 2000.
  • FIG. 14 is a schematic block diagram of a communication device 2000 provided by an embodiment of the present application.
  • the communication device 2000 may include a processor 2020, and may also include a transceiver 2010 and a memory 2030.
  • the processor 2020 is coupled with the memory 2030, and is configured to execute instructions stored in the memory to control the transceiver 2010 to send signals and/or receive signals.
  • processor 2020 and the memory 2030 may be combined into one processing device, and the processor 2020 is configured to execute the program code stored in the memory 2030 to implement the foregoing functions.
  • the memory 2030 may also be integrated in the processor 2020 or independent of the processor 2020.
  • the communication device 2000 may correspond to the first device in the above method embodiment.
  • the communication apparatus 2000 may include a method for executing the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method executed by the first device in the method 800 in FIG. Unit.
  • the units in the communication device 2000 and the other operations and/or functions described above are used to implement the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method in FIG. 12, respectively.
  • the corresponding process executed by the first device in 800 It should be understood that the specific process for each unit to execute the foregoing corresponding steps has been described in detail in the foregoing method embodiment, and is not repeated here for brevity.
  • the communication device 2000 may correspond to the second device in the above method embodiment.
  • the communication apparatus 2000 may include a method for executing the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method executed by the second device in the method 800 in FIG. Unit.
  • the units in the communication device 2000 and the other operations and/or functions described above are used to implement the method 500 in FIG. 5 to FIG. 7, the method 600 in FIG. 10, the method 700 in FIG. 11, and the method in FIG. 12, respectively.
  • the corresponding process executed by the second device in 800 It should be understood that the specific process for each unit to execute the foregoing corresponding steps has been described in detail in the foregoing method embodiment, and is not repeated here for brevity.
  • the present application also provides a computer program product, the computer program product includes: computer program code, when the computer program code runs on a computer, the computer executes FIGS. 5 to 7 and The method of any one of the embodiments shown in FIG. 10 to FIG. 12.
  • the present application also provides a computer-readable storage medium that stores program code, and when the program code runs on a computer, the computer executes FIGS. 5 to 5 7 and the method of any one of the embodiments shown in FIG. 10 to FIG. 12.
  • the present application also provides a system including the aforementioned first device and second device.
  • the above embodiments it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • software it can be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes one or more computer instructions.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.
  • computer instructions may be transmitted from a website, computer, server, or data center through a cable (such as Coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL) or wireless (such as infrared, wireless, microwave, etc.) transmission to another website site, computer, server or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center integrated with one or more available media.
  • the usable medium can be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a high-density digital video disc (digital video disc, DVD)), or a semiconductor medium (for example, a solid state disk (SSD)) )Wait.
  • a magnetic medium for example, a floppy disk, a hard disk, and a magnetic tape
  • an optical medium for example, a high-density digital video disc (digital video disc, DVD)
  • a semiconductor medium for example, a solid state disk (SSD)
  • Each network element in the foregoing device embodiments can completely correspond to each network element in the method embodiment, and the corresponding unit executes the corresponding steps.
  • the transceiver unit performs the receiving or sending steps in the method embodiment, except Steps other than sending and receiving can be executed by the processing unit (processor).
  • the processing unit processor
  • the functions of specific units refer to the corresponding method embodiments. Among them, there may be one or more processors.
  • one embodiment or “an embodiment” mentioned throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of the present application. Therefore, the appearances of "in one embodiment” or “in an embodiment” in various places throughout the specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not correspond to the embodiments of the present application. The implementation process constitutes any limitation.
  • unit used in this specification are used to denote computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution.
  • the component may be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and/or a computer running on a processor.
  • the application running on the computing device and the computing device can be components.
  • One or more components may reside in processes and/or threads of execution, and components may be located on one computer and/or distributed among two or more computers.
  • these components can be executed from various computer readable media having various data structures stored thereon.
  • the component can be based on, for example, a signal having one or more data packets (e.g. data from two components interacting with another component in a local system, a distributed system, and/or a network, such as the Internet that interacts with other systems through a signal) Communicate through local and/or remote processes.
  • a signal having one or more data packets (e.g. data from two components interacting with another component in a local system, a distributed system, and/or a network, such as the Internet that interacts with other systems through a signal) Communicate through local and/or remote processes.
  • the disclosed system, device, and method can be implemented in other ways.
  • the device embodiments described above are merely illustrative.
  • the division of the above-mentioned units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described above as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer readable storage medium.
  • the technical solution of the present application essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), magnetic disks or optical disks and other media that can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

本申请提供了一种通信的方法和通信装置。该方法包括：第二设备接收来自第一设备的认证请求信息，该认证请求信息包括该第一设备的标识信息；该第二设备根据第一映射关系确定与该第一设备的标识信息对应的密码算法套件，该第一映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；该第二设备根据该密码算法套件，生成认证响应信息；该第二设备向该第一设备发送该认证响应信息。基于本申请，可以提高两个设备的认证过程的传输可靠性和通信效率。

Description

通信的方法和通信装置 技术领域
本申请涉及通信领域，并且更具体地，涉及一种通信的方法和通信装置。
背景技术
目前，针对车载以太网(Ethernet，Eth)的安全通信，汽车开放系统架构(automotive open system architecture，AUTOSAR)联盟定义了传输层安全(transport layer security，TLS)协议和数据包传输层安全(datagram transport layer security，DLTS)协议。
不论是基于TLS协议还是基于DTLS协议，在两个设备的初始握手过程中，或者基于预共享密钥的握手过程中，其中一个设备要向另一个设备传递自身支持的密码算法套件列表。然而密码算法套件列表的数据量比较大，在握手过程中容易造成互联网协议(internet protocol，IP)包分片传输，从而影响传输的可靠性和通信效率。
发明内容
本申请提供一种通信的方法，可以提高设备握手过程中的传输可靠性和通信效率。
第一方面，提供了一种通信的方法，该方法包括：第二设备接收来自第一设备的认证请求信息，该认证请求信息包括该第一设备的标识信息；该第二设备根据第一映射关系确定与该第一设备的标识信息对应的密码算法套件，该第一映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；该第二设备根据该密码算法套件，生成认证响应信息；该第二设备向该第一设备发送该认证响应信息。
基于上述技术方案，通过将密码算法套件与设备的标识信息对应的方式，使得第二设备可以根据保存的第一映射关系确定与第一设备通信过程中使用的密码算法套件。因此，第一设备和第二设备在握手过程中，不需要传递支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。
结合第一方面，在第一方面的某些实现方式中，在该第二设备向该第一设备发送认证响应信息之前，该方法还包括：该第二设备确定预先配置的第二列表中包含该第一设备的标识信息，该第二列表中包括需要认证的设备的标识信息。
基于上述技术方案，通过在第二设备预先配置第二列表的方式，使得第二设备在确定第一设备的标识信息保存在第二列表的情况下，就可以确定第一设备的来源合法性，即第二列表可以代替原有握手过程中cookie字段分配的过程。因此，可以防止恶意设备伪造虚假来源发起认证过程，以及第二设备根据第二列表可以直接忽略不合法设备的认证请求，从而减轻第二设备的处理负担，也可以提高攻击者的攻击难度。
结合第一方面，在第一方面的某些实现方式中，该认证请求信息还包括该第一设备的第一设备证书和/或该第一设备使用的第一签名值；和/或该认证响应信息还包括该第二设备的第二设备证书和/或该第二设备使用的第二签名值。
结合第一方面，在第一方面的某些实现方式中，该认证请求信息还包括该第一设备使用的第一随机数和/或该第一设备使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二随机数和/或该第二设备使用的第二临时公钥。
结合第一方面，在第一方面的某些实现方式中，该认证请求信息还包括第一密码；和/或该认证响应信息还包括第二密码，该第二密码是该第二设备根据预存的预共享密钥和该密码算法套件生成的。
基于上述方案，第一设备和第二设备基于确定的密码算法套件和预存的预共享密钥可以生成密码来代替设备证书。由于密码的长度远小于设备证书，因此大大减小了握手交互过程中的交互数据量，提高了握手效率和可靠性。
此外，使用密码代替设备证书之后，设备不再需要对设备证书中的根签名进行验签，而是变成了对密码进行对称加密解密运算。而对称加密解密运算速度远远高于验签速度，因此可以提高握手效率。
结合第一方面，在第一方面的某些实现方式中，该认证请求信息还包括该第一设备使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二临时公钥和该第二设备的标识信息。
结合第一方面，在第一方面的某些实现方式中，该至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
结合第一方面，在第一方面的某些实现方式中，该方法还包括：该第二设备确定与该第一设备通信使用的报文加密模式，该报文加密模式包括全加密模式和按需加密模式中的一个。
基于上述技术方案，通过定义通信报文的按需加密模式，使得在按需加密模式下，对不需要加密的数据可以明文传输，从而减少了加密载荷的数据量，提高了加密速率，从而提高了通信效率。
结合第一方面，在第一方面的某些实现方式中，该第二设备确定与该第一设备通信使用的报文加密模式，包括：该第二设备根据第二映射关系确定与该第一设备的标识信息对应的该报文加密模式，该第二映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
结合第一方面，在第一方面的某些实现方式中，在该报文加密模式是按需加密模式的情况下时，该方法还包括：该第二设备生成通信报文，该通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
结合第一方面，在第一方面的某些实现方式中，该明文数据中包含该密文数据的流加密密钥生成种子。
现有的应用于用户数据报协议的握手过程中，无法使用流加密算法。而基于上述技术方案，在按需加密模式下，可以在明文数据中保存密文数据的流加密密钥生成种子，从而使得用户数据报协议可以支持流加密算法。
第二方面，提供了一种通信的方法，该方法包括：第一设备根据第三映射关系确定与第二设备的标识信息对应的密码算法套件，该第三映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；该第一设备根据该密码算法套件生成认证请求信息，该认证请求信息包括该第一设备的标识信息；该第一设备向该第二设备发送该 认证请求信息；该第一设备接收来自该第二设备的认证响应信息。
基于上述技术方案，通过将密码算法套件与设备的标识信息对应的方式，使得第一设备可以根据保存的第三映射关系确定与第二设备通信过程中使用的密码算法套件。因此，第一设备和第二设备在握手过程中，不需要传递支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。
结合第二方面，在第二方面的某些实现方式中，在该第一设备向该第二设备发送该认证请求信息之前，该方法还包括：该第一设备确定预先配置的第一列表中包含该第二设备的标识信息，该第一列表中包括需要认证的设备的标识信息。
基于上述技术方案，通过在第一设备预先配置第一列表的方式，使得第一设备在确定第二设备的标识信息保存在第二列表的情况下，就可以确定第二设备的来源合法性。
结合第二方面，在第二方面的某些实现方式中，该认证请求信息还包括该第一设备的设备证书和/或该第一设备使用的第一签名值；和/或该认证响应信息还包括该第二设备的第二设备证书和/或该第二设备使用的第二签名值。
结合第二方面，在第二方面的某些实现方式中，该认证请求信息还包括第一密码，该第一密码是该第一设备根据预存的预共享密钥和该密码算法套件生成的；和/或该认证响应信息还包括第二密码。
基于上述方案，第一设备和第二设备基于确定的密码算法套件和预存的预共享密钥可以生成密码来代替设备证书。由于密码的长度远小于设备证书，因此大大减小了握手交互过程中的交互数据量，提高了握手效率和可靠性。
此外，使用密码代替设备证书之后，设备不再需要对设备证书中的根签名进行验签，而是变成了对密码进行对称加密解密运算。而对称加密解密运算速度远远高于验签速度，因此可以提高握手效率。
结合第二方面，在第二方面的某些实现方式中，该认证请求信息还包括该第一设备使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二临时公钥和该第二设备的标识信息。
结合第二方面，在第二方面的某些实现方式中，其特征在于，该认证请求信息还包括该第一设备使用的第一随机数和/或该第一设备使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二随机数和/或该第二设备使用的第二临时公钥。
结合第二方面，在第二方面的某些实现方式中，该至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
结合第二方面，在第二方面的某些实现方式中，该方法还包括：该第一设备确定与该第二设备通信使用的报文加密模式，该报文加密模式包括全加密模式和按需加密模式中的一个。
基于上述技术方案，通过定义通信报文的按需加密模式，使得在按需加密模式下，对不需要加密的数据可以明文传输，从而减少了加密载荷的数据量，提高了加密速率，从而提高了通信效率。
结合第二方面，在第二方面的某些实现方式中，该第一设备确定与该第二设备通信使用的报文加密模式，包括：该第一设备根据第四映射关系确定与该第二设备的标识信息对应的该报文加密模式，该第四映射关系用于指示至少一个设备的标识信息与至少一个报文 加密模式之间的对应关系。
结合第二方面，在第二方面的某些实现方式中，在该报文加密模式是按需加密模式的情况下，该方法还包括：该第一设备生成通信报文，该通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
结合第二方面，在第二方面的某些实现方式中，该明文数据中包含该密文数据的流加密密钥生成种子。
现有的应用于用户数据报协议的握手过程中，无法使用流加密算法。而基于上述技术方案，在按需加密模式下，可以在明文数据中保存密文数据的流加密密钥生成种子，从而使得用户数据报协议可以支持流加密算法。
第三方面，提供一种通信装置，该通信装置包括收发单元和处理单元：该收发单元用于接收来自第一设备的认证请求信息，该认证请求信息包括该第一设备的标识信息；该处理单元用于根据第一映射关系确定与该第一设备的标识信息对应的密码算法套件，该第一映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；该处理单元还用于根据该密码算法套件，生成认证响应信息；该收发单元还用于向该第一设备发送该认证响应信息。
结合第三方面，在第三方面的某些实现方式中，该处理单元还用于确定预先配置的第二列表中包含该第一设备的标识信息，该第二列表中包括需要认证的设备的标识信息。
结合第三方面，在第三方面的某些实现方式中，该认证请求信息还包括该第一设备的第一设备证书和/或该第一设备使用的第一签名值；和/或该认证响应信息还包括该通信装置的第二设备证书和/或该通信装置使用的第二签名值。
结合第三方面，在第三方面的某些实现方式中，该认证请求信息还包括第一密码；和/或该认证响应信息还包括第二密码，该第二密码是该处理单元根据预存的预共享密钥和该密码算法套件生成的。
结合第三方面，在第三方面的某些实现方式中，该认证请求信息还包括该第一设备使用的第一随机数和/或该第一设备使用的第一临时公钥；该认证响应信息还包括该通信装置使用的第二随机数和/或该通信装置使用的第二临时公钥。
结合第三方面，在第三方面的某些实现方式中，该认证请求信息还包括该第一设备使用的第一临时公钥；该认证响应信息还包括该通信装置使用的第二临时公钥和该通信装置的标识信息。
结合第三方面，在第三方面的某些实现方式中，该至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
结合第三方面，在第三方面的某些实现方式中，该处理单元还用于确定与该第一设备通信使用的报文加密模式，该报文加密模式包括全加密模式和按需加密模式中的一个。
结合第三方面，在第三方面的某些实现方式中，该处理单元具体用于根据第二映射关系确定与该第一设备的标识信息对应的该报文加密模式，该第二映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
结合第三方面，在第三方面的某些实现方式中，在该报文加密模式是按需加密模式的情况下时，该处理单元还用于生成通信报文，该通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
结合第三方面，在第三方面的某些实现方式中，该明文数据中包含该密文数据的流加密密钥生成种子。
第四方面，提供了一种通信装置，该通信装置包括收发单元和处理单元：该处理单元用于根据第三映射关系确定与第二设备的标识信息对应的密码算法套件，该第三映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；该处理单元还用于根据该密码算法套件生成认证请求信息，该认证请求信息包括该通信装置的标识信息；该收发单元用于向该第二设备发送该认证请求信息；该收发单元还用于接收来自该第二设备的认证响应信息。
结合第四方面，在第四方面的某些实现方式中，该处理单元还用于确定预先配置的第一列表中包含该第二设备的标识信息，该第一列表中包括需要认证的设备的标识信息。
结合第四方面，在第四方面的某些实现方式中，该认证请求信息还包括该通信装置的设备证书和/或该通信装置使用的第一签名值；和/或该认证响应信息还包括该第二设备的第二设备证书和/或该第二设备使用的第二签名值。
结合第四方面，在第四方面的某些实现方式中，该认证请求信息还包括第一密码，该第一密码是该通信装置根据预存的预共享密钥和该密码算法套件生成的；和/或该认证响应信息还包括第二密码。
结合第四方面，在第四方面的某些实现方式中，该认证请求信息还包括该通信装置使用的第一随机数和/或该通信装置使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二随机数和/或该第二设备使用的第二临时公钥。
结合第四方面，在第四方面的某些实现方式中，该认证请求信息还包括该通信装置使用的第一临时公钥；该认证响应信息还包括该第二设备使用的第二临时公钥和该第二设备的标识信息。
结合第四方面，在第四方面的某些实现方式中，该至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
结合第四方面，在第四方面的某些实现方式中，该处理单元还用于确定与该第二设备通信使用的报文加密模式，该报文加密模式包括全加密模式和按需加密模式中的一个。
结合第四方面，在第四方面的某些实现方式中，该处理单元具体用于根据第四映射关系确定与该第二设备的标识信息对应的该报文加密模式，该第四映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
结合第四方面，在第四方面的某些实现方式中，在该报文加密模式是按需加密模式的情况下，该处理单元还用于生成通信报文，该通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
结合第四方面，在第四方面的某些实现方式中，该明文数据中包含该密文数据的流加密密钥生成种子。
第五方面，提供了一种通信装置，包括处理器。该处理器与存储器耦合，可用于执行存储器中的指令，以实现上述第一方面至第二方面或第一方面至第二方面中任一种可能实现方式中的方法。
第六方面，提供了一种处理器，包括：输入电路、输出电路和处理电路。处理电路用于通过输入电路接收信号，并通过输出电路发射信号，使得处理器执行上述第一方面至第 二方面或第一方面至第二方面中任一种可能实现方式中的方法。
在具体实现过程中，上述处理器可以为芯片，输入电路可以为输入管脚，输出电路可以为输出管脚，处理电路可以为晶体管、门电路、触发器和各种逻辑电路等。输入电路所接收的输入的信号可以是由例如但不限于接收器接收并输入的，输出电路所输出的信号可以是例如但不限于输出给发射器并由发射器发射的，且输入电路和输出电路可以是同一电路，该电路在不同的时刻分别用作输入电路和输出电路。本申请实施例对处理器及各种电路的具体实现方式不做限定。
第七方面，提供了一种处理装置，包括处理器。还可以包括存储器，存储器用于存储指令，该处理器用于读取存储器中存储的指令，并可通过接收器接收信号，通过发射器发射信号，以执行上述第一方面至第二方面或第一方面至第二方面中任一种可能实现方式中的方法。
可选地，处理器为一个或多个，存储器为一个或多个。
可选地，存储器可以与处理器集成在一起，或者存储器与处理器分离设置。
在具体实现过程中，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型和存储器与处理器的设置方式不做限定。
应理解，相关的数据交互过程例如发送指示信息可以为从处理器输出指示信息的过程，接收能力信息可以为处理器接收输入能力信息的过程。具体地，处理输出的数据可以输出给发射器，处理器接收的输入数据可以来自接收器。其中，发射器和接收器可以统称为收发器。
上述第七方面中的处理装置可以是一个芯片，该处理器可以通过硬件来实现也可以通过软件来实现，当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。
第八方面，提供了一种计算机程序产品，该计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当计算机程序被运行时，使得计算机执行上述第一方面至第二方面或第一方面至第二方面中任一种可能实现方式中的方法。
第九方面，提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)当其在计算机上运行时，使得计算机执行上述第一方面至第二方面或第一方面至第二方面中任一种可能实现方式中的方法。
第十方面，提供了一种通信系统，包括前述第三方面或第三方面中任一种可能实现方式中的通信装置，和/或，前述第四方面或第四方面中任一种可能实现方式中的通信装置。
附图说明
图1是TLS协议的示意性流程图。
图2是基于预共享密钥的握手过程的示意性流程图。
图3和图4是适用于本申请实施例提供的方法的通信系统的示意图。
图5至图7是本申请实施例提供的通信的方法的示意性流程图。
图8是本申请实施例提供的按需加密模式下的通信报文的格式示意图。
图9是本申请实施例提供的全加密模式下的通信报文的格式示意图。
图10至图12是本申请实施例提供的通信的方法的示意性流程图。
图13和图14是本申请实施例提供的通信装置的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
目前，针对车载以太网的安全通信，AUTOSAR联盟定义了TLS协议和DLTS协议。AUTOSAR中定义的TLS协议和DTLS协议与传统以太网协议中定义的TLS协议和DTLS协议相同，即AUTOSAR定义的TLS协议和DTLS协议是TLS协议和DTLS协议在车载以太网上的移植。
图1中示出了TLS协议的流程。如图1所示，TLS协议包含握手过程和通信过程。车内部件#1中预置根证书、私钥(secret key，SK)#1和设备证书#1，设备证书#1中包括车内部件#1的标识(identity，ID)#1、公钥(public key，PK)#1和根签名。车内部件#2中预置根证书、SK#2和设备证书#2，设备证书#2中包括车内部件#2的ID#2、PK#2和根签名。
其中握手过程例如可以包括以下步骤：
S101，车内部件#1生成随时数(random)#1。
S102，车内部件#1向车内部件#2发送连接请求(ClientHello)#1。连接请求#1中包括随机数#1和车内部件#1支持的密码算法套件列表。
S103，车内部件#2生成一个cookie字段。
S104，车内部件#2向车内部件#1发送验证请求(HelloVerifyRequest)。验证请求中包括cookie字段。
S105，车内部件#1向车内部件#2发送连接请求#2。连接请求#2中包括随机数#1、车内部件#1支持的密码算法套件列表和cookie字段。
S106，车内部件#2生成随机数#2。
S107，车内部件#2根据车内部件#1支持的密码算法套件列表选择支持的密码算法套件。
S108，车内部件#2根据选择的密码算法套件生成临时公私钥对#2。临时公私钥对#2包括临时私钥(temporary secret key，tempSK)#2和临时公钥(temporary public key，tempPK)#2。
S109，车内部件#2计算签名(Sign)#2。Sign#2＝Sign(ID#2||random#2||tempPK#2)。
S110，车内部件#2向车内部件#1发送连接响应(ServerHello)。连接响应中包括设备证书#2、随机数#2、tempPK#2和Sign#2。
S111，车内部件#1验证设备证书#2的合法性。
S112，车内部件#1验证Sign#2的合法性。
S113，车内部件#1生成临时公私钥对#1。临时公私钥对#1包括tempSK#1和tempPK#1。
S114，车内部件#1计算Sign#1。Sign#1＝Sign(ID#1||random#1||tempPK#1)
S115，车内部件#1向车内部件#2发送改变密码标准(ChangeCipherSpec)。改变密码标准中包括设备证书#1、tempPK#1和Sign#1。
S116，车内部件#1根据密钥派生函数(key derivation function，KDF)计算预共享密钥(pre-shared key，PSK)#1。PSK#1＝KDF(ID#1，ID#2，tempSK#1，tempPK#2)。
S117，车内部件#1根据KDF计算会话密钥(SessionKey)#1。SessionKey#1＝KDF(PSK#1，random#1，random#2)。
S118，车内部件#2验证设备证书#1的合法性。
S119，车内部件#2验证Sign#1的合法性。
S120，车内部件#2根据KDF计算PSK#2。PSK#2＝KDF(ID#1，ID#2，tempSK#2，tempPK#1)。
S121，车内部件#2根据KDF计算SessionKey#2。SessionKey#2＝KDF(PSK#2，random#1，random#2)。
如上所述，车内部件#1和车内部件#2通过握手过程完成双方的身份合法性认证、密码算法套件协商和SessionKey协商等步骤。进一步地，在通信过程中：
S122，车内部件#1和车内部件#2使用SessionKey对通信报文进行加密传输。
如果通信双方之前进行过握手过程，保存有相同的PSK，那么握手过程可以简化。基于PSK的握手过程如图2所示。
S201，车内部件#1生成随时数(random)#1。
S202，车内部件#1向车内部件#2发送连接请求#3。连接请求#3中包括随机数#1、车内部件#1支持的密码算法套件列表和PSK_ID。
S203，车内部件#2生成随机数#2。
S204，车内部件#2根据车内部件#1支持的密码算法套件列表选择支持的密码算法套件，根据PSK_ID选择PSK。
S205，车内部件#2根据选择的密码算法套件生成临时公私钥对#2。临时公私钥对包括tempSK#2和tempPK#2。
S206，车内部件#2使用PSK加密报文。
S207，车内部件#2向车内部件#1发送加密的连接响应。连接响应中包括随机数#2和tempPK#2。
S208，车内部件#1解密报文得到随机数#2。
S209，车内部件#1生成临时公私钥对#1。临时公私钥对#1包括tempSK#1和tempPK#1。
S210，车内部件#1使用PSK加密报文。
S211，车内部件#1向车内部件#2发送加密的改变密码标准。改变密码标准中包括tempPK#1。
S212，车内部件#1计算预共享密钥(pre-shared key，PSK)#1。PSK#1＝KDF(ID#1，ID#2，tempSK#1，tempPK#2)。
S213，车内部件#1根据KDF SessionKey#1。SessionKey#1＝KDF(PSK#1，random#1，random#2)。
S214，车内部件#2根据KDF计算PSK#2。PSK#2＝KDF(ID#1，ID#2，tempSK#2，tempPK#1)。
S215，车内部件#2根据KDF计算SessionKey#2。SessionKey#2＝KDF(PSK#2，random#1，random#2)。
S216，车内部件#1和车内部件#2使用SessionKey对通信报文进行加密传输。
如上所述，基于PSK的握手过程无需对设备证书进行合法性验证，因此提高了握手的效率。
然而不论是初始握手过程还是基于PSK的握手过程，在密码算法套件协商环节传递的密码算法套件列表的数据量比较大，以及在初始握手过程的身份合法性认证环节传递的证书数据量比较大，因此，在握手过程中容易造成互联网协议(internet protocol，IP)包分片传输，从而影响传输的可靠性和通信效率。
此外，在车内网的场景下，不同车内部件之间传输大量的数据会增加车内转发部件的负担；现有的密码算法套件与车内部件的硬件能力不兼容，因此部署难度大，实时性差；基于传输控制协议(transmission control protocol，TCP)，不同车内部件之间需要建立连接，因此在车内上电时大量车内部件建立连接容易造成总线拥堵或中心节点负载过重；TLS协议无法应用于用户数据报协议(user datagram protocol，UDP)；以及，不同车内部件之间的安全通道建立后，传输的所有数据都要加密，然而车内存在很多无需加密，只需要保证完整性的数据传输(例如，车辆控制指令)，因此，对所有数据都加密会造成运算资源浪费，同时会话密钥使用次数过多会增大攻击风险。
DTLS协议是为了适应UDP协议而对TLS协议进行改动得到的。由于UDP协议是不可靠的，报文有可能丢失和乱序。为了处理这些情况，DTLS协议在TLS协议的基础上做了如下改动：
(1)DTLS增加了报文超时重传机制，用来处理报文丢失的问题；
(2)DTLS报文中保存一个不加密的序号值，用来处理报文乱序的问题；
(3)DTLS移除了流加密算法的支持，也就是说，DTLS支持的密码算法套件是TLS支持的密码算法套件的子集。
除了上述不同之外，DTLS协议的流程与TLS协议的流程相同。
由于DTLS协议用于UDP协议，存在丢包的可能，因此，在握手过程中传输数据量较大的密码算法套件列表和设备证书，对传输可靠性和通信效率的不利影响会更大。
此外，在车内网场景下，不同车内部件之间传输大量的数据会增加车内转发部件的负担；现有的密码算法套件与车内部件的硬件能力不兼容，因此部署难度大，实时性差；在追求高实时性的车内通信中，流加密算法是常用的高效加密手段，然而DTLS协议并不支持流加密算法；以及，不同车内部件之间的安全通道建立后，传输的所有数据都要加密，然而车内存在很多无需加密，只需要保证完整性的数据传输(例如，车辆控制指令)，因此，对所有数据都加密会造成运算资源浪费，同时会话密钥使用次数过多会增大攻击风险。
基于此，本申请实施例提供一种通信的方法，以期减少握手过程中的交互过程和通信数据量，从而提高传输效率和通信质量。
图3是适用于本申请实施例的通信方法的通信系统的示意图。如图3所示，本申请实施例提供的方法可以应用于智能网联车的车内部件之间通过车载以太网进行安全通信的场景。例如，图3所示的电子控制单元(electronic control unit，ECU)#1与ECU#2之间通过车载以太网进行通信。
车内部件可以包括与外界通信的远程信息处理器如车联网终端盒子(telematics box，T-Box)、网关(gateway，GW)、高级驾驶辅助系统(advanced driver assistance system， ADAS)、人机界面(human-machine interface，HMI)、整车控制器(vehicle control unit，VCU)等。
如图3所示，两个车内部件之间可以直接连接。或者，两个车内部件之间还可以通过其它车内部件转接，如图4所示，ECU#1和ECU#2之间通过GW连接。
下面结合附图对本本申请实施例提供的方法进行说明。
图5示出了本申请实施例提供的通信的方法的示意性流程图。图5所示的方法500可以应用于图3或图4所示的通信系统中，图5所示的第一设备可以是图3或图4中的ECU#1，第二设备可以是图3或图4中的ECU#2。如图5所示，该方法500可以包括S501至S506，下面详细描述各个步骤。
S501，第一设备根据第三映射关系确定与第二设备的标识信息对应的密码算法套件。
可以理解，与第二设备的标识信息对应的密码算法套件，即第一设备与第二设备之间进行通信所使用的密码算法套件。
其中，第一设备或第二设备可以是T-Box、GW、ADAS、HMI、或VCU等。
其中，第三映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系。至少一个设备的标识信息可以是第一设备需要认证的设备的标识信息。也就是说，第一设备根据第三映射关系可以确定与需要认证的设备进行通信所使用的密码算法套件。可以理解的，至少一个设备的标识信息包括第二设备的标识信息。
可选地，若第一设备根据第三映射关系可以确定出与第二设备的标识信息对应的密码算法套件，则第一设备可以默认第二设备是需要认证的设备，即可以确定第二设备的真实性。
设备的标识信息可以包括以下一种或多种：设备的类型、设备的标识(identifier，ID)、设备的网际协议(internet protocol，IP)地址、设备的媒体访问控制(media access control，MAC)地址。
本申请实施例对至少一个设备的标识信息与至少一个密码算法套件的对应关系不做限定。
作为一个示例，至少一个设备的标识信息与至少一个密码算法套件之间可能存在一一对应的对应关系。表1示出了至少一个设备的标识信息与至少一个密码算法套件之间一一对应的示例。
表1
设备的标识信息 密码算法套件
设备#A 密码算法套件#A
设备#B 密码算法套件#B
设备#C 密码算法套件#C
设备#D 密码算法套件#D
根据表1，第一设备可以确定与设备#A的标识信息对应的是密码算法套件#A，与设备#B的标识信息对应的是密码算法套件#B，与设备#C的标识信息对应的是密码算法套件#C，与设备#D的标识信息对应的是密码算法套件#D。
作为另一示例，至少一个设备的标识信息与至少一个密码算法套件之间可能存在多对一的对应关系。表2示出了至少一个设备的标识信息与至少一个密码算法套件之间多对一 的示例。
表2
Figure PCTCN2020090460-appb-000001
根据表2，第一设备可以确定与设备#A的标识信息、设备#B的标识信息和设备#C的标识信息对应的都是密码算法套件#A，与设备#D的标识信息对应的是密码算法套件#B。
第三映射关系所指示的至少一个设备的标识信息和至少一个密码算法套件之间的对应关系，可以根据第一设备与至少一个设备的硬件能力确定。例如，如果第一设备和设备#A都具有电子安全车辆入侵防护应用(E-safety vehicle intrusion protected application，EVITA)full级的硬件安全模块(hardware security module，HSM)，则可以将第一设备与该设备#A进行安全通信使用的密码算法套件确定为ECDHE_ECDSA_AES_128_GCM_Whirlpool。也就是说，可以将设备#A的标识信息与ECDHE_ECDSA_AES_128_GCM_Whirlpool对应起来。其中，临时椭圆曲线Diffie-Hellman(ephemeral elliptic curve Diffie-Hellman，ECDHE)代表密钥协商算法，椭圆曲线数字签名算法(elliptic curve digital signature algorithm，ECDSA)代表数字签名算法，高级加密标准(advanced encryption standard，AES)_128_(galois/counter mode，GCM)代表认证加密算法，Whirlpool算法为哈希算法，这些算法都是EVITA full级的HSM中规定的算法。
第三映射关系可以是预先存储在第一设备中的。例如，第三映射关系可以是设备生产商在生成第一设备的时候预先存储在第一设备中的；或者，第三映射关系可以是用户在使用第一设备之前预先存储在第一设备中的；或者，第三映射关系还可以是软件提供商预先存储在第一设备中的。
在本申请实施例中，通过将密码算法套件与设备的标识信息对应的方式，使得第一设备够可以根据保存的第三映射关系确定与第二设备通信所使用的密码算法套件，因此，第一设备不需要向第二设备传输自身支持的密码算法套件列表，从而减小了传输的数据量。
可选地，至少一个密码算法套件中的每个密码算法套件都满足前向安全性需求。也就是说，在定义第一设备与至少一个其它设备进行通信使用的密码算法套件时，只使用满足前向安全性需求的密钥协商算法，例如，使用临时Diffie-Hellman(ephemeral Diffie-Hellman，DHE)或ECDHE。
S502，第一设备根据确定的密码算法套件生成认证请求信息。
第一设备根据确定的密码算法套件生成认证请求信息可以理解为，第一设备根据确定密码算法套件生成认证请求信息中包括的参数。
认证请求信息中包括第一设备的标识信息(下文中以ID#1为例进行说明)。认证请求信息还可以包括以下参数中的一种或多种：第一设备使用的第一临时公钥(下文中以tempPK#1为例进行说明)、第一设备使用的第一随机数(random)(下文中以random#1为例进行说明)、第一设备的设备证书(下文中以设备证书#1为例进行说明)、第一设备使用的第一签名值(下文中以Sign#1为例进行说明)、第一密码(下文中以cipher#1 为例进行说明)。其中，random#1和tempPK#1用于生成第一设备与第二设备之间通信使用的会话密钥，设备证书#1、Sign#1和cipher#1用于对第一设备的合法性进行验证。
其中，设备证书#1中包括ID#1、第一设备使用的第一公钥(下文中以PK#1为例进行说明)和根签名。可以理解，由于设备证书#1中包括ID#1，因此，认证请求信息中可以不包括第一设备的标识信息，在此情况下，可以理解为，第一设备的标识信息包含在设备证书#1中。
tempPK#1是第一设备根据确定的密码算法套件生成的。第一设备根据密码算法套件中的密钥协商算法生成第一临时公私钥对，第一临时公私钥对中包括tempPK#1和第一临时私钥(下文中以tempSK#1为例进行说明)两个数据。
Sign#1是第一设备根据确定的密码算法套件生成的。第一设备构造第一消息(下文中以msg#1为例进行说明)，msg#1的内容为{ID#1||random#1||tempPK#1}；进一步地，第一设备以使用的第一私钥(下文中以SK#1为例进行说明)为密钥，根据密码算法套件中规定的数字签名算法对msg#1加密得到Sign#1，Sign#1＝Sign(ID#1||random#1||tempPK#1)，“||”表示连接，Sign()表示用数字签名算法进行计算。
cipher#1是第一设备根据预存的PSK和密码算法套件生成的。其中，预存的PSK与第二设备对应。
第一设备构造msg#1，msg#1的内容为{ID#1||random#1}；进一步地，第一设备以PSK为密钥，根据密码算法套件中的对称加密算法对msg#1进行加密，生成cipher#1，cipher#1＝Enc PSK(ID#1||random#1)。其中，“||”表示连接，Enc PSK()表示以PSK为密钥，以对称加密算法加密。
预存的PSK可以是第一设备在与第二设备在先进行身份认证的过程中生成的。
可以理解，若第一设备与第二设备之前进行过身份认证过程，则第一设备和第二设备可以保存有相同的PSK。第一设备可以根据第二设备的标识信息(下文中以ID#2为例进行说明)从保存的一个或多个PSK中确定与第二设备对应的PSK。
预存的PSK还可以是第一设备根据预先配置的第一PSK列表中保存的PSK。预先配置的第一PSK列表中可以包括至少一个设备的标识信息对应的PSK。预先配置的第一PSK列表可以理解为第一PSK列表是预先存储在第一设备中的。例如，第一PSK列表可以是设备生产商在生成第一设备的时候预先存储在第一设备中的；或者，第一PSK列表可以是用户在使用第一设备之前预先存储在第一设备中的；或者，第一PSK列表还可以是软件提供商预先存储在第一设备中的。
在此情况下，第一设备可以根据预先配置的第一PSK列表确定与ID#2对应的PSK。
可选地，如图6所示，该方法500还可以包括：S507，第一设备确定预先配置的第一列表中包含第二设备的标识信息。预先配置的第一列表可以理解为第一列表是预先存储在第一设备中的。例如，第一列表可以是设备生产商在生成第一设备的时候预先存储在第一设备中的；或者，第一列表可以是用户在使用第一设备之前预先存储在第一设备中的；或者，第一列表还可以是软件提供商预先存储在第一设备中的。
需要说明的是，图中仅以S507在S502之后为例进行说明，不应对本申请构成限定，S507还可以在S502或者在S501之前执行。或者，S507与S501可以是一个步骤。
其中，第一列表中定义了第一设备需要和哪些设备进行安全通信的认证过程，也就是 说，第一列表中包括第一设备需要认证的设备的标识信息。
第一列表的内容可以根据第一设备的应用场景确定。例如，第一设备是ADAS，则在自动驾驶业务功能中，ADAS需要和HMI、VCU、车身域控制器、底盘域控制器、传感器等设备进行安全通信，因此ADAS中预先配置的第一列表中可以保存上述设备的标识信息。
在第一设备生成或发送认证请求信息之前，第一设备可以查询预先配置的第一列表中是否保存有第二设备的标识信息。
若第一列表保存有第二设备的标识信息，则表示第一设备需要对第二设备进行身份认证，则第一设备向第二设备发起认证过程。例如，第一设备在确定第一列表中包含第二设备的标识信息的情况下，再生成认证请求信息，或向第二设备发送认证请求信息。
若第一列表中没有保存第二设备的标识信息，则表示第一设备和第二设备之间无需进行身份认证，则第一设备不会向第二设备发起认证过程。例如，第一设备在确定第一列表中不包含第二设备的标识信息的情况下，不生成认证请求信息，或不向第二设备发送认证请求信息。
还需要说明的是，上述第一设备确定第一列表中包含第二设备的标识信息的方案也可以单独实施，即，可以作为独立的实施例，而不必依附于本说明书中的其他实施例。
在本申请实施例中，通过在第一设备预置第一列表的而方式，使得第一设备在确定第二设备的标识信息保存在第一列表的情况下，再向第二设备发送认证请求信息，从而可以避免发起不必要认证请求。
可选地，如图7所示，该方法500还可以包括：S509，第一设备确定与第二设备通信使用的报文加密模式。
需要说明的是，图中仅以S509在S507之后为例进行说明，不应对本申请构成限定。S509还可以在S507之前执行，或者可以在S502之前执行，或者可以在S501之前执行，或者S509还可以在S503之后执行。或者，S509与S507可以是一个步骤，者S509与S501可以是一个步骤。
其中，报文加密模式包括全加密模式和按需加密模式中的一个。
若第一设备与第二设备通信使用的报文加密模式是全加密模式，则第一设备与第二设备之间发送的通信报文可以包括：密文数据。
密文数据即第一设备与第二设备根据密码算法套件对通信数据进行加密得到的数据。
图8示出了全加密模式下的通信报文格式。如图8所示，在全加密模式下，只有报文序号不加密，其他所有数据均为密文数据。
若第一设备与第二设备通信使用的报文加密模式是按需加密模式，则第一设备与第二设备之间发送的通信报文包括：明文标识、明文数据、密文标识、密文数据。
其中，明文标识用于标识明文数据的长度，或者用于指示明文标识之后的字段是明文数据。明文数据即没有加密的数据。
可选地，明文数据中可以包含密文数据的流加密密钥生成种子。
图9示出了在按需加密模式下，第一设备与第二设备之间发送的通信报文的格式。从图9可以看出，明文标识之后，密文标识之前的数据是明文数据，密文标识之后的数据是密文数据。其中，明文数据可以包括：报文序号、流密钥种子、娱乐数据、车辆控制指令、 哈希值等。密文数据可以包括：定位数据、地图数据、用户隐私等。
本申请实施例对第一设备确定报文加密模式的方式不做限定。
作为一个示例，第一设备可以根据与第二设备之间传输的数据内容确定报文加密模式。例如，若第一设备与第二设备之间传输的是地图数据、定位数据等，则确定报文加密模式为全加密模式。若第一设备与第二设备之间除了传输地图数据等数据，还传输娱乐数据、控制指令等，则确定报文加密模式为按需加密模式，即对地图数据等数据加密，对娱乐数据、控制指令等不加密。
进一步地，第一设备可以向第二设备发送指示信息，指示与第二设备之间通信所使用的报文加密模式。例如，第一设备发送的指示信息可以是布尔型(bool)变量，若布尔型变量的值是“1”，则指示第一设备与第二设备之间通信使用的报文加密模式是全加密模式；若布尔型变量的值是“0”，则指示第一设备与第二设备之间通信使用的报文加密模式是按需加密模式。可选的，该指示信息还可以携带在认证请求信息中。
作为另一个示例，第一设备可以根据第四映射关系确定与第二设备的标识信息对应的报文加密模式，第四映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
本申请实施例对至少一个设备的标识信息与至少一个报文加密模式的对应关系不做限定。
例如，至少一个设备的标识信息与至少一个报文加密模式之间可能存在一一对应的对应关系。表3示出了至少一个设备的标识信息与至少一个报文加密模式之间一一对应的示例。
表3
设备的标识信息 报文加密模式
设备#A 全加密模式
设备#B 全加密模式
设备#C 按需加密模式
设备#D 按需加密模式
根据表3，第一设备可以确定与设备#A和设备#B的标识信息对应的是全加密模式，与设备#C和设备#D的标识信息对应的是按需加密模式。
又例如，至少一个设备的标识信息与至少一个报文加密模式之间可能存在多对一的对应关系。表4示出了至少一个设备的标识信息与至少一个报文加密模式之间多对一的示例。
根据表4，第一设备可以确定与设备#A的标识信息和设备#B的标识信息对应的都是全加密模式，与设备#C的标识信息和设备#D的标识信息对应的是按需加密模式。
表4
Figure PCTCN2020090460-appb-000002
还需要说明的是，上述第一设备确定与第二设备通信使用的报文加密模式的方案也可以单独实施，即，可以作为独立的实施例，而不必依附于本说明书中的其他实施例。
在本申请实施例中，通过定义通信报文的按需加密模式，使得在按需加密模式下，对不需要加密的数据可以明文传输，从而减少了加密载荷的数据量，提高了加密速率，从而提高了通信效率。在按需加密模式下，可以在明文数据中保存密文数据的流加密密钥生成种子，从而可以在UDP协议上支持流加密算法，进一步提高通信效率。
应理解，上文中以第一设备分别保存了第三映射关系、第一列表、第一PSK列表和第四映射关系为例进行说明，不应对本申请实施例构成限定。
第三映射关系指示的信息、第四映射关系指示的信息、第一PSK列表包含的内容和第一列表包含的内容可以保存在同一个列表中；或者，第三映射关系指示的信息、第四映射关系指示信息、第一PSK列表包含的内容和第一列表包含的内容中的一个或多个可以保存在同一个列表中。
表5示出了第三映射关系指示的信息、第四映射关系指示的信息、第一PSK列表包含的内容和第一列表包含的内容保存在同一个列表中的示例。
表5
设备的标识信息 密码算法套件 PSK 报文加密模式
设备#A 密码算法套件#1 PSK#1 全加密模式
设备#B 密码算法套件#2 PSK#2 全加密模式
设备#C 密码算法套件#3 PSK#3 按需加密模式
设备#D 密码算法套件#4 PSK#4 按需加密模式
其中，设备#A至设备#D的标识信息即第一设备需要认证的设备的标识信息；以及表5中示出了与设备#A至设备#D的标识信息分别对应的密码算法套件#1至密码算法套件#4、PSK#1至PSK#4、报文加密模式。
S503，第一设备向第二设备发送认证请求信息。相对应地，在S503中，第二设备接收来自第一设备的认证请求信息。
认证请求信息中可以包括以下参数中的一种或多种：ID#1、tempPK#1、random#1、设备证书#1、Sign#1、cipher#1。
例如，在第一设备与第二设备单向认证的场景下，认证请求信息中可以包括：ID#1、tempPK#1和random#1。
第一设备和第二设备之间进行单向认证，即第一设备对第二设备的合法性进行认证，第二设备不对第一设备的合法性进行认证。例如，在自动驾驶场景中，假设第一设备是智能驾驶域控制器，第二设备是传感器，则智能驾驶域控制器与域内传感器进行通信之前，智能驾驶域控制器为防止传感器发送伪造数据，需要对传感器进行认证，而传感器无需对智能驾驶域控制器进行认证。
又例如，在第一设备与第二设备进行双向认证的情况下，认证请求信息中可以包括：设备证书#1、Sign#1、tempPK#1和random#1。
第一设备与第二设备进行双向认证，即第一设备对第二设备的合法性进行认证，第二设备也对第一设备的合法性进行认证。
再例如，在第一设备预存与第二设备对应的PSK的情况下，认证响应信息可以包括： ID#1、cipher#1和tempPK#1。
S504，第二设备根据第一映射关系确定与第一设备的标识信息对应的密码算法套件。
可以理解，与第一设备的标识信息对应的密码算法套件，即第一设备与第二设备之间进行通信所使用的密码算法套件。
其中，第一映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系。具体地，关于第一映射关系的描述可以参考S501中关于第三映射关系的描述，为例简洁，本申请实施例不再详述。
可以理解的，步骤S504中确定的密码算法套件与步骤S501中确定的密码算法套件相同。
第一映射关系可以是预先存储在第二设备中的。例如，第一映射关系可以是设备生产商在生成第二设备的时候预先存储在第二设备中的；或者，第一映射关系可以是用户在使用第二设备之前预先存储在第二设备中的；或者，第一映射关系还可以是软件提供商预先存储在第二设备中的。
可选地，若第二设备根据第一映射关系可以确定出与第一设备的标识信息对应的密码算法套件，则第二设备可以默认第一设备是需要认证的设备，即可以确定第一设备的真实性。
在本申请实施例中，通过将密码算法套件与设备的标识信息对应的方式，使得第二设备可以根据保存的第一映射关系确定与第一设备通信过程中使用的密码算法套件。因此，第一设备不需要向第二设备传输自身支持的密码算法套件，从而减小了传输过程中的数据量，提高了传输可靠性和通信效率。
可选地，至少一个密码算法套件中的每个密码算法套件都满足前向安全性需求。
如前文所述，在第一设备与第二设备之间进行双向认证的情况下，第一设备向第二设备发送的认证请求信息可以包括设备证书#1和/或Sign#1。则第二设备在确定密码算法套件之前，可以先对设备证书#1的合法性进行验证。
第二设备使用根证书中的第二设备使用的第二公钥(下文中以PK#2为例进行说明)对设备证书#1中保存的根签名进行验签。验证通过之后，第二设备再确定密码算法套件。
在确定密码算法套件之后，第二设备继续对Sign#1的合法性进行验证。第二设备可以根据设备证书#1中包括的ID#1和认证请求信息中包括的random#1和tempPK#1构造msg#1，进一步地，第二设备根据设备证书#1中包括的PK#1对Sign#1的合法性进行验证。验证通过之后，第二设备执行后续的认证过程。
若认证请求信息中包括cipher#2，则第二设备确定密码算法套件之后，以预存的与第一设备的标识信息对应的PSK为密钥，以及根据密码算法套件中的对称加密算法解密cipher#1得到ID#1。进一步地，第二设备判断解密cipher#1得到的ID#1与认证请求信息中的ID#1是否一致。如果不一致，则认证失败，如果一致，则继续执行后续的认证过程。S505，第二设备根据确定的密码算法套件生成认证响应信息。
认证响应信息可以包括以下参数中的一个或多个：
第二设备的标识信息(下文中以ID#2为例进行说明)、第二设备使用的第二随机数(下文中random#2为例进行说明)、第二设备的第二设备证书(下文中以设备证书#2为例进行说明)、第二设备使用的第二签名值(下文中以Sign#1为例进行说明)、第二设 备使用的第二临时公钥(下文中以tempPK#2为例进行说明)、第二密码(下文中以cipher#2为例进行说明)。其中，设备证书#2中包括ID#2、PK#2和根签名。random#2和tempPK#2用于生成第一设备与第二设备之间通信使用的会话密钥，设备证书#2、Sign#2和cipher#2用于对第二设备的合法性进行验证。
第二设备可以根据确定的密码算法套件生成认证响应信息，也可以理解为，第二设备生成认证响应信息中包括的参数。
第二设备可以根据确定的密码算法套件生成第二临时公私钥对，第二临时公私钥对中包括tempPK#2和第二临时私钥(下文中以tempSK#2为例进行说明)两个数据。
第二设备还可以构造第二消息(下文中以msg#2为例进行说明)，msg#2的内容为{ID#2||random#2||tempPK#2}；进一步地，第二设备以使用的第二私钥(下文中以SK#2为例进行说明)为密钥，根据密码算法套件中规定的数字签名算法对msg#2加密得到Sign#2，Sign#2＝Sign(ID#2||random#2||tempPK#2)，“||”表示连接，Sign()表示用数字签名算法进行计算。
第二设备还可以根据预存的PSK和密码算法套件生成cipher#2。第二设备构造msg#2，msg#2的内容为{ID#2||random#2}；进一步地，第二设备以PSK为密钥，根据密码算法套件中的对称加密算法对msg#2进行加密，生成cipher#2，cipher#2＝Enc PSK(ID#2||random#2)。其中，“||”表示连接，Enc PSK()表示以PSK为密钥，以对称加密算法加密。
预存的PSK可以是第一设备在与第二设备在先进行身份认证的过程中生成的。
可以理解，若第一设备与第二设备之前进行过身份认证过程，则第一设备和第二设备保存有相同的PSK。第二设备可以根据ID#1从保存的一个或多个PSK中确定与第一设备对应的PSK。
预存的PSK还可以是第二设备根据预先配置的第二PSK列表中保存的PSK。预先配置的第二PSK列表中可以包括至少一个设备的标识信息对应的PSK。预先配置的第二PSK列表可以理解为第二PSK列表是预先存储在第二设备中的。例如，第一PSK列表可以是设备生产商在生成第二设备的时候预先存储在第二设备中的；或者，第二PSK列表可以是用户在使用第二设备之前预先存储在第二设备中的；或者，第二PSK列表还可以是软件提供商预先存储在第二设备中的。
在此情况下，第二设备可以根据预先配置的第二PSK列表确定与ID#1对应的PSK。
若第二设备在确定与第一设备的标识信息对应的密码算法套件之后，仍然不确定第一设备的合法性，则第二设备可以暂时不生成上述参数。
在此情况下，第二设备可以生成一个cookie字段，并将生成的cookie字段携带在认证响应信息中发送给第一设备。进一步地，第二设备可以在接收到第一设备发送的携带cookie字段的认证请求信息之后，根据认证请求信息中的cookie字段确定第一设备的真实性和来源合法性。
可选地，如图6所示，该方法500还可以包括：S508，第二设备确定预先配置的第二列表中包含第一设备的标识信息。预先配置的第二列表可以理解为第二列表是预先存储在第二设备中的。例如，第二列表可以是设备生产商在生成第二设备的时候预先存储在第二设备中的；或者，第二列表可以是用户在使用第二设备之前预先存储在第一设备中的；或者，第二列表还可以是软件提供商预先存储在第二设备中的。
需要说明的是，图中仅以S508在S505之后为例进行说明，不应对本申请构成限定，S508还可以在S505或者在S504之前执行。或者，S508与S504可以是一个步骤。
其中，第二列表中定义了第二设备需要和哪些设备进行安全通信的认证过程，也就是说，第二列表中包括第二设备需要认证的设备的标识信息。具体地，关于第二列表的描述可以参考前文S507中关于第一列表的描述，为了简洁，本申请实施例不再详述。
在第二设备生成或发送认证响应信息之前，第二设备可以查询预先配置的第二列表中是否保存有第一设备的标识信息。
若第二列表保存有第一设备的标识信息，则表示第一设备的来源合法，则第二设备响应第一设备的认证请求。例如，第二设备在确定第二列表中包含第一设备的标识信息的情况下，再生成认证响应信息，或向第二设备发送认证响应信息。
若第二列表中没有保存第一设备的标识信息，则表示第一设备的来源不合法，则第二设备不响应第一设备的认证请求。例如，第二设备在确定第二列表中不包含第一设备的标识信息的情况下，不生成认证响应信息，或不向第二设备发送认证响应信息。
还需要说明的是，上述第二设备确定第二列表中包含第一设备的标识信息的方案也可以单独实施，即，可以作为独立的实施例，而不必依附于本说明书中的其他实施例。
在本申请实施例中，通过在第二设备预先配置第二列表的方式，使得第二设备在确定第一设备的标识信息保存在第二列表的情况下，就可以确定第一设备的来源合法性，即第二列表可以代替原有握手过程中cookie字段分配的过程。因此，可以防止恶意设备伪造虚假来源发起认证过程，以及第二设备根据第二列表可以直接忽略不合法设备的认证请求，从而减轻第二设备的处理负担，也可以提高攻击者的攻击难度。
可选地，如图7所示，该方法500还可以包括：S510，第二设备确定与第一设备通信使用的报文加密模式。
需要说明的是，图中仅以S510在S508之后为例进行说明，不应对本申请构成限定。S510还可以在S508之前执行，或者可以在S505之前执行，或者可以在S504之前执行，或者S510还可以在S506之后执行。或者，S510与S508可以是一个步骤，者S509与S504可以是一个步骤。
其中，报文加密模式包括全加密模式和按需加密模式中的一个。
若第一设备与第二设备通信使用的报文加密模式是全加密模式，则第一设备与第二设备之间发送的通信报文可以包括：密文数据。
密文数据即第一设备与第二设备根据密码算法套件对通信数据进行加密得到的数据。
图8示出了全加密模式下的通信报文格式。如图8所示，在全加密模式下，只有报文序号不加密，其他所有数据均为密文数据。
若第一设备与第二设备通信使用的报文加密模式是按需加密模式，则第一设备与第二设备之间发送的通信报文包括：明文标识、明文数据、密文标识、密文数据。
其中，明文标识用于标识明文数据的长度，或者用于指示明文标识之后的字段是明文数据。明文数据即没有加密的数据。
可选地，明文数据中可以包含密文数据的流加密密钥生成种子。
图9示出了在按需加密模式下的通信报文的格式。从图9可以看出，明文标识之后，密文标识之前的数据是明文数据，密文标识之后的数据是密文数据。其中，明文数据可以 包括：报文序号、流密钥种子、娱乐数据、车辆控制指令、哈希值等。密文数据可以包括：定位数据、地图数据、用户隐私等。
本申请实施例对第二设备确定报文加密模式的方式不做限定。
作为一个示例，第二设备可以根据来自第一设备的指示信息确定报文加密模式，该指示信息用于指示第一设备与第二设备之间通信所使用的报文加密模式。例如，第二设备接收的来自第一设备的指示信息可以是布尔型(bool)变量，若布尔型变量的值是“1”，则指示第一设备与第二设备之间通信使用的报文加密模式是全加密模式；若布尔型变量的值是“0”，则指示第一设备与第二设备之间通信使用的报文加密模式是按需加密模式。
作为另一个示例，第二设备可以根据第二映射关系确定与第一设备的标识信息对应的报文加密模式，第二映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。具体地，关于第二映射关系的描述可以参考前文S509中关于第四映射关系的描述，为了简洁，本申请实施例不再详述。
还需要说明的是，上述第二设备确定与第一设备通信使用的报文加密模式的方案也可以单独实施，即，可以作为独立的实施例，而不必依附于本说明书中的其他实施例。
在本申请实施例中，通过定义通信报文的按需加密模式，使得在按需加密模式下，对不需要加密的数据可以明文传输，从而减少了加密载荷的数据量，提高了加密速率，从而提高了通信效率。在按需加密模式下，可以在明文数据中保存密文数据的流加密密钥生成种子，从而可以在UDP协议上支持流加密算法，进一步提高通信效率。
应理解，上文中以第二设备分别保存了第一映射关系、第二列表、第二PSK列表和第二映射关系为例进行说明，不应对本申请实施例构成限定。
第一映射关系指示的信息、第二映射关系指示的信息、第二PSK列表包含的内容和第二列表包含的内容可以保存在同一个列表中；或者，第一映射关系指示的信息、第二映射关系指示信息、第二PSK列表包含的内容和第二列表包含的内容中的一个或多个可以保存在同一个列表中。
表6示出了第一映射关系指示的信息、第二映射关系指示的信息、第二PSK列表包含的内容和第二列表包含的内容保存在同一个列表中的示例。
表6
设备的标识信息 密码算法套件 PSK 报文加密模式
设备#E 密码算法套件#1 PSK#1 全加密模式
设备#F 密码算法套件#2 PSK#2 全加密模式
设备#G 密码算法套件#3 PSK#3 按需加密模式
设备#H 密码算法套件#4 PSK#4 按需加密模式
其中，设备#E至设备#H的标识信息即第二设备需要认证的设备的标识信息；以及表6中示出了与设备#E至设备#H的标识信息分别对应的密码算法套件#1至密码算法套件#4、PSK#1至PSK#4、报文加密模式。
S506，第二设备向第一设备发送认证响应信息。
认证响应信息可以包括以下参数中的一个或多个：random#2、设备证书#2、Sign#1、tempPK#2、cipher#2、ID#2。
例如，在第二设备确定第一设备来源合法的情况下，认证响应信息可以包括： random#2、设备证书#2、Sign#1、tempPK#2。
又例如，第二设备预存与第一设备对应的PSK的情况下，认证响应信息可以包括：ID#2、tempPK#2、cipher#2。
相应地，在S506中，第一设备接收到来自第二设备的认证响应信息之后，可以对第二设备的合法性进行验证。
若认证响应信息中包括设备证书#2，则第一设备验证设备证书#2的合法性。第一设备根据设备证书#2中保存的ID#2查询与预先配置的第一列表，确认第二设备是否为需要认证的设备。如果不是，则终止认证；如果是，则第一设备使用根证书中的PK#1对设备证书#2中的根签名进行验签。
若认证响应信息中包括Sign#2，则第一设备继续验证Sign#2。第一设备可以根据设备证书#2中包括的ID#2和认证响应信息中包括的random#2和tempPK#2构造msg#2，进一步地，第二设备根据设备证书#2中包括的PK#2对Sign#2的合法性进行验证。
若认证响应信息中包括cipher#2，则第一设备以预存的与第二设备对应的PSK为密钥，以及根据密码算法套件中的对称加密算法解密cipher#2得到ID#2。进一步地，第一设备判断解密cipher#2得到的ID#2与认证响应信息中的ID#2是否一致，如果不一致，则认证失败，如果一致，则认证成功。
在第一设备与第二设备执行完身份认证流程以及交互了双方使用的随机数和临时公钥之后，则按照现有的流程计算本次安全通信使用的PSK和会话密钥。随后进行通信过程。
在本申请实施例中，通过将密码算法套件与设备的标识信息对应的方式，使得第一设备和第二设备可以根据保存的映射关系确定通信过程中使用的密码算法套件。因此，第一设备和第二设备在握手过程中，不需要传递支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。在第一设备与第二设备通过转发部件通信的情况下，还可以减轻转发部件的负担。
在本申请实施例中，通过在第二设备预先配置第二列表的方式，使得第二设备在确定第一设备的标识信息保存在第二列表的情况下，就可以确定第一设备的来源合法性，即第二列表可以代替原有握手过程中cookie字段分配的过程。因此，可以防止恶意设备伪造虚假来源发起认证过程，以及第二设备根据第二列表可以直接忽略不合法设备的认证请求，从而减轻第二设备的处理负担，也可以提高攻击者的攻击难度。
在本申请实施例中，定义了通信报文的按需加密模式，在按需加密模式下，对不需要加密的数据可以明文传输，从而减少了加密载荷的数据量，提高了加密速率，从而提高了通信效率。
此外，在按需加密模式下，可以在明文数据中保存密文数据的流加密密钥生成种子，从而可以在UDP协议上支持流加密算法，进一步提高通信效率。
图10是本申请另一实施例提供的方法600的示意性流程图，如图10所示，该方法600可以包括S601至S620，下面详细说明各个步骤。
S601，第一设备确定预先配置的第一列表中包含第二设备的标识信息(ID#2)。
其中，第一列表包括第一设备需要认证的设备的标识信息。
若第一设备确定第一列表中包含ID#2，则第一设备继续执行认证过程；若第一设备 确定第一列表中没有包含ID#2，则第一设备不执行与第二设备的认证过程。
S602，第一设备确定与ID#2对应的密码算法套件和报文加密模式。
第一设备可以根据第三映射关系确定与ID#2对应的密码算法套件。第一设备可以根据第四映射关系确定与ID#2对应的报文加密模式。
S603，第一设备生成随机数#1。
S604，第一设备根据密码算法套件中的密钥协商算法生成第一临时公私钥对。
第一临时公私钥对中包括tempPK#1和tempSK#1。
S605，第一设备根据密码算法套件中的数字签名算法生成第一签名值。
第一设备构造msg#1，msg#1的内容为{ID#1||random#1||tempPK#1}；进一步地，第一设备以SK#1为密钥，根据密码算法套件中规定的数字签名算法对msg#1加密得到Sign#1，Sign#1＝Sign(ID#1||random#1||tempPK#1)，“||”表示连接，Sign()表示用数字签名算法进行计算。
S606，第一设备向第二设备发送认证请求信息。
认证请求信息中包括：设备证书#1、random#1、tempPK#1和Sign#1。设备证书#1中包括：ID#1、PK#1和根签名。
S607，第二设备验证设备证书#1的合法性。
第二设备根据设备证书#1中的ID#1，确定预先配置的第二列表中保存ID#1。若第二列表中保存ID#1，则第二设备确定第一设备是需要认证的设备；若第二列表中没有保存ID#1，则第二设备确定第一设备是不需要认证的设备，进而终止认证过程。
在第二设备确定第一设备是需要认证的设备的情况下，第二设备继续使用PK#2对设备证书#1中根签名进行验证。若验证成功，则继续执行验证过程；若验证失败，则终止验证过程。
S608，第二设备确定与ID#1对应的密码算法套件和报文加密模式。
第二设备可以根据第一映射关系确定与ID#1对应的密码算法套件。第一设备可以根据第二映射关系确定与ID#1对应的报文加密模式。
S609，第二设备验证第一签名值。
第二设备可以根据设备证书#1中包括的ID#1和认证请求信息中包括的random#1和tempPK#1构造msg#1，进一步地，第二设备根据设备证书#1中包括的PK#1对Sign#1的合法性进行验证。验证通过之后，第二设备执行后续的认证过程。验证不通过，则验证失败。
S610，第二设备生成随机数#2。
S611，第二设备根据密码算法套件中的密钥协商算法生成第二临时公私钥对。
第二临时公私钥对中包括tempPK#2和tempSK#2。
S612，第二设备根据密码算法套件中的数字签名算法计算第二签名值。
第二设备构造msg#2，msg#2的内容为{ID#2||random#2||tempPK#2}；进一步地，第一设备以SK#2为密钥，根据密码算法套件中规定的数字签名算法对msg#2加密得到Sign#2，Sign#2＝Sign(ID#2||random#2||tempPK#2)，“||”表示连接，Sign()表示用数字签名算法进行计算。
S613，第二设备向第一设备发送认证响应信息。
认证响应信息中包括：设备证书#2、random#2、tempPK#2、Sign#2。设备证书#2中包括：ID#2、PK#2和根签名。
S614，第二设备计算PSK#2。
PSK#2＝KDF(ID#1，ID#2，tempSK#2，tempPK#1)。其中，KDF()表示根据密钥派生函数进行计算。
S615，第二设备计算会话密钥#2。
SessionKey#2＝KDF(PSK#2，random#1，random#2)。其中，KDF()表示根据密钥派生函数进行计算。
S616，第一设备验证设备证书#2的合法性。
第一设备根据设备证书#2中的ID#2，确定预先配置的第一列表中保存ID#2。若第一列表中保存ID#2，则第一设备确定第二设备是需要认证的设备；若第一列表中没有保存ID#2，则第一设备确定第二设备是不需要认证的设备，进而终止认证过程。
在第一设备确定第二设备是需要认证的设备的情况下，第一设备继续使用PK#1对设备证书#2中根签名进行验证。若验证成功，则继续执行验证过程；若验证失败，则终止验证过程。
S617，第一设备验证第二签名值。
第一设备可以根据设备证书#2中包括的ID#2和认证响应信息中包括的random#2和tempPK#2构造msg#2，进一步地，第一设备根据设备证书#2中包括的PK#2对Sign#2的合法性进行验证。验证通过之后，第一设备执行后续的认证过程。验证不通过，则验证失败。
S618，第一设备计算PSK#1。
PSK#1＝KDF(ID#1，ID#2，tempPK#2，tempSK#1)。其中，KDF()表示根据密钥派生函数进行计算。
可以理解，虽然本申请实施例中用PSK#1和PSK#2分别表示第一设备和第二设备生成的PSK，但这仅仅是为了区分，PSK#1和PSK#2应该认为是等同的。
S619，第一设备计算会话密钥#1。
SessionKey#1＝KDF(PSK#1，random#1，random#2)。其中，KDF()表示根据密钥派生函数进行计算。
可以理解，虽然本申请实施例中用SessionKey#1和SessionKey#2分别表示第一设备和第二设备生成的SessionKey，但这仅仅是为了区分，SessionKey#1和SessionKey#2应该认为是等同的。
S620，第一设备与第二设备根据确定的密码算法套件和报文加密模式传输通信报文。
在本申请实施例中，第一设备预先配置的列表中记录了握手来源的合法设备标识列表，可以防止恶意设备伪造虚假来源发起拒绝服务攻击，起到了现有技术中的cookie字段的作用。也就是说，可以省去原有TLS协议和DTLS协议中的cookie字段分配的过程，减少了握手过程中的一次交互过程。第二设备根据预先配置的第二列表可以直接忽略不合法设备的握手请求，使第二设备只进行必要的握手，既可以减轻第二设备的处理负担，也可以提高攻击者攻击的难度。
本申请实施例通过将密码算法套件与设备的标识信息对应的方式，使得第一设备和第 二设备可以根据保存的映射关系确定通信过程中使用的密码算法套件，从而省去了原有TLS协议和DTLS协议中密码算法套件协商过程，使得第一设备和第二设备在握手过程中，不需要传递设备支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。
此外，在会话密钥协商过程中，使用临时公私钥对，可以满足前向安全性需求。
图11是本申请另一实施例提供的方法700的示意性流程图，如图11所示，该方法700可以包括S701至S716，其中，S702至S703与方法600中的S603至S604相同，S706至S716与方法600中的S610至S620相同，为了简洁，本申请实施例不再详述。下面详细说明其余各个步骤。
S701，第一设备确定与ID#2对应的密码算法套件和报文加密模式。
第一设备可以根据第三映射关系确定与ID#2对应的密码算法套件。第一设备可以根据第四映射关系确定与ID#2对应的报文加密模式。
在本申请实施例中，第一设备根据第三映射关系可以确定出与ID#2对应的密码算法套件，则第一设备可以默认第二设备是需要认证的设备。
S704，第一设备向第二设备发送认证响应信息。
认证响应信息中包括：ID#1、random#1、tempPK#1。
S705，第二设备确定与ID#1对应的密码算法套件和报文加密模式。
第二设备可以根据第一映射关系确定与ID#1对应的密码算法套件。第一设备可以根据第二映射关系确定与ID#1对应的报文加密模式。
同样，在本申请实施例，第二设备根据第一映射关系可以确定出与ID#1对应的密码算法套件，则第二设备可以默认第一设备是需要认证的设备。
在本申请实施例中，只进行了第一设备对第二设备的单向的身份合法认证，进一步减少握手过程中的运算步骤和交互的数据量。尽管第二设备没有对第一设备的身份合法性进行认证，但是第二设备在根据第一映射关系确定密码算法套件的过程中，可以判断第一设备是否是需要认证的设备，这提高了攻击者发送恶意握手请求的难度，相比于目前的单向认证握手过程提高了安全性。
本申请实施例通过将密码算法套件与设备的标识信息对应的方式，使得第一设备和第二设备可以根据保存的映射关系确定通信过程中使用的密码算法套件，从而省去了原有TLS协议和DTLS协议中密码算法套件协商过程，使得第一设备和第二设备在握手过程中，不需要传递设备支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。
此外，在会话密钥协商过程中，使用临时公私钥对，可以满足前向安全性需求。
图12是本申请另一实施例提供的方法800的示意性流程图，如图12所示，该方法800可以包括S801至S817，其中，S802至S803与方法600中的S603至S604相同，S808至S809与方法600中的S610至S611相同，S812至S813与方法600中的S614至S615相同，S815至S817与方法600中的S618至S620相同，为了简洁，本申请实施例不再详述。下面详细说明其余各个步骤。
S801，第一设备确定与ID#2对应的密码算法套件、报文加密模式和PSK。
第一设备可以根据第三映射关系确定与ID#2对应的密码算法套件。第一设备可以根 据第四映射关系确定与ID#2对应的报文加密模式。第一设备可以根据预先配置的第一PSK列表确定与ID#2对应的PSK。
S804，第一设备计算第一密码。
第一设备构造msg#1，msg#1的内容为{ID#1||random#1}；进一步地，第一设备以PSK为密钥，根据密码算法套件中的对称加密算法对msg#1进行加密，生成cipher#1，cipher#1＝Enc PSK(ID#1||random#1)。其中，“||”表示连接，Enc PSK()表示以PSK为密钥，以对称加密算法加密。
S805，第一设备向第二设备发送认证响应信息。
认证响应信息中包括：ID#1、cipher#1、tempPK#1。
S806，第二设备确定与ID#1对应的密码算法套件、报文加密模式和PSK。
第二设备可以根据第一映射关系确定与ID#1对应的密码算法套件。第二设备可以根据第二映射关系确定与ID#1对应的报文加密模式。第二设备可以根据预先配置的第二PSK列表确定与ID#1对应的PSK。
S807，第二设备解密第一密码。
第二设备确定密码算法套件之后，以确定的PSK为密钥，以及根据密码算法套件中的对称加密算法解密cipher#1得到ID#1。进一步地，第二设备判断解密cipher#1得到的ID#1与认证请求信息中的ID#1是否一致，如果不一致，则认证失败，如果一致，则继续执行后续的认证过程。
S810，第二设备计算第二密码。
第二设备构造msg#2，msg#2的内容为{ID#2||random#2}；进一步地，第二设备以PSK为密钥，根据密码算法套件中的对称加密算法对msg#2进行加密，生成cipher#2，cipher#2＝Enc PSK(ID#2||random#2)。其中，“||”表示连接，Enc PSK()表示以PSK为密钥，以对称加密算法加密。
S811，第二设备向第一设备发送认证响应信息。
认证响应信息中包括：ID#2、tempPK#2、cipher#2。
S814，第一设备解密第二密码。
第一设备以确定的PSK为密钥，以及根据密码算法套件中的对称加密算法解密cipher#2得到ID#2。进一步地，第二设备判断解密cipher#2得到的ID#2与认证响应信息中的ID#2是否一致，如果不一致，则认证失败，如果一致，则继续执行后续的认证过程。
本申请实施例通过将密码算法套件与设备的标识信息对应的方式，使得第一设备和第二设备可以根据保存的映射关系确定通信过程中使用的密码算法套件，从而省去了原有TLS协议和DTLS协议中密码算法套件协商过程，使得第一设备和第二设备在握手过程中，不需要传递设备支持的密码算法套件列表，从而减小了握手过程中传输的数据量，提高了传输可靠性和通信效率。
以及，确定了密码算法套件之后，基于预存的PSK可以生成cipher来代替设备证书。由于cipher的长度远小于设备证书，因此大大减小了握手交互过程中的交互数据量，提高了握手效率和可靠性。
此外，使用cipher代替设备证书之后，设备不再需要对设备证书中的根签名进行验签，而是变成了对cipher进行对称加密解密运算。而对称加密解密运算速度远远高于验签速 度，因此可以提高握手效率。
此外，在会话密钥协商过程中，使用临时公私钥对，可以满足前向安全性需求。
以上，结合图5至图12详细说明了本申请实施例提供的通信的方法。以下，结合图13至图14详细说明本申请实施例提供的装置。
图13是本申请实施例提供的通信装置1000的示意性框图。如图所示，该通信装置1000可以包括：收发单元1010和处理单元1020。
在一种可能的设计中，该通信装置1000可对应于上文方法实施例中的第一设备。
应理解，该通信装置1000可以包括用于执行图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中的第一设备执行的方法的单元。并且，该通信装置1000中的各单元和上述其他操作和/或功能分别为了实现图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中的第一设备执行的相应流程。应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
在另一种可能的设计中，该通信装置1000可对应于上文方法实施例中的第二设备。
应理解，该通信装置1000可以包括用于执行图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800的第二设备执行的方法的单元。并且，该通信装置1000中的各单元和上述其他操作和/或功能分别为了实现图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中的第二设备执行的相应流程。应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
应理解，该通信装置1000中的收发单元1010可对应于图14中示出的通信装置2000中的收发器2010，该通信装置1000中的处理单元1020可对应于图14中示出的通信装置2000中的处理器2020。
图14是本申请实施例提供的通信装置2000的示意性框图。如图所示，该通信装置2000可以包括：处理器2020，还可以包括收发器2010和存储器2030。该处理器2020与存储器2030耦合，用于执行存储器中存储的指令，以控制收发器2010发送信号和/或接收信号。
应理解，上述处理器2020和存储器2030可以合成一个处理装置，处理器2020用于执行存储器2030中存储的程序代码来实现上述功能。具体实现时，该存储器2030也可以集成在处理器2020中，或者独立于处理器2020。
在一种可能的设计中，该通信装置2000可对应于上文方法实施例中的第一设备。
具体地，该通信装置2000可以包括用于执行图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中的第一设备执行的方法的单元。并且，该通信装置2000中的各单元和上述其他操作和/或功能分别为了实现图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中第一设备执行的相应流程。应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
在一种可能的设计中，该通信装置2000可对应于上文方法实施例中的第二设备。
具体地，该通信装置2000可以包括用于执行图5至图7中的方法500、图10中的方 法600、图11中的方法700以及图12中的方法800中的第二设备执行的方法的单元。并且，该通信装置2000中的各单元和上述其他操作和/或功能分别为了实现图5至图7中的方法500、图10中的方法600、图11中的方法700以及图12中的方法800中第二设备执行的相应流程。应理解，各单元执行上述相应步骤的具体过程在上述方法实施例中已经详细说明，为了简洁，在此不再赘述。
根据本申请实施例提供的方法，本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当该计算机程序代码在计算机上运行时，使得该计算机执行图5至图7以及图10至图12所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有程序代码，当该程序代码在计算机上运行时，使得该计算机执行图5至图7以及图10至图12所示实施例中任意一个实施例的方法。
根据本申请实施例提供的方法，本申请还提供一种系统，该系统包括前述的第一设备和第二设备。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
上述各个装置实施例中各网元可以和方法实施例中的各网元完全对应，由相应的单元执行相应的步骤，例如收发单元(收发器)执行方法实施例中接收或发送的步骤，除发送、接收外的其它步骤可以由处理单元(处理器)执行。具体单元的功能可以参考相应的方法实施例。其中，处理器可以为一个或多个。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
在本说明书中使用的术语“单元”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或 执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
上述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (28)

  1. 一种通信的方法，其特征在于，包括：
    第二设备接收来自第一设备的认证请求信息，所述认证请求信息包括所述第一设备的标识信息；
    所述第二设备根据第一映射关系确定与所述第一设备的标识信息对应的密码算法套件，所述第一映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；
    所述第二设备根据所述密码算法套件，生成认证响应信息；
    所述第二设备向所述第一设备发送所述认证响应信息。
  2. 根据权利要求1所述的方法，其特征在于，在所述第二设备向所述第一设备发送认证响应信息之前，所述方法还包括：
    所述第二设备确定预先配置的第二列表中包含所述第一设备的标识信息，所述第二列表中包括需要认证的设备的标识信息。
  3. 根据权利要求1或2所述的方法，其特征在于，所述认证请求信息还包括所述第一设备的第一设备证书和/或所述第一设备使用的第一签名值；和/或
    所述认证响应信息还包括所述第二设备的第二设备证书和/或所述第二设备使用的第二签名值。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，
    所述认证请求信息还包括所述第一设备使用的第一随机数和/或所述第一设备使用的第一临时公钥；
    所述认证响应信息还包括所述第二设备使用的第二随机数和/或所述第二设备使用的第二临时公钥。
  5. 根据权利要求1或2所述的方法，其特征在于，所述认证请求信息还包括第一密码；和/或
    所述认证响应信息还包括第二密码，所述第二密码是所述第二设备根据预存的预共享密钥和所述密码算法套件生成的。
  6. 根据权利要求5所述的方法，其特征在于，所述认证请求信息还包括所述第一设备使用的第一临时公钥；
    所述认证响应信息还包括所述第二设备使用的第二临时公钥和所述第二设备的标识信息。
  7. 根据权利要求1至6中任一项所述的方法，其特征在于，所述至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
  8. 根据权利要求1至7中任一项所述的方法，其特征在于，所述方法还包括：
    所述第二设备确定与所述第一设备通信使用的报文加密模式，所述报文加密模式包括全加密模式和按需加密模式中的一个。
  9. 根据权利要求8所述的方法，其特征在于，所述第二设备确定与所述第一设备通信使用的报文加密模式，包括：
    所述第二设备根据第二映射关系确定与所述第一设备的标识信息对应的所述报文加密模式，所述第二映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
  10. 根据权利要求8或9所述的方法，其特征在于，在所述报文加密模式是按需加密模式的情况下时，所述方法还包括：
    所述第二设备生成通信报文，所述通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
  11. 根据权利要求10所述的方法，其特征在于，所述明文数据中包含所述密文数据的流加密密钥生成种子。
  12. 一种通信的方法，其特征在于，包括：
    第一设备根据第三映射关系确定与第二设备的标识信息对应的密码算法套件，所述第三映射关系用于指示至少一个设备的标识信息与至少一个密码算法套件之间的对应关系；
    所述第一设备根据所述密码算法套件生成认证请求信息，所述认证请求信息包括所述第一设备的标识信息；
    所述第一设备向所述第二设备发送所述认证请求信息；
    所述第一设备接收来自所述第二设备的认证响应信息。
  13. 根据权利要求12所述的方法，其特征在于，在所述第一设备向所述第二设备发送所述认证请求信息之前，所述方法还包括：
    所述第一设备确定预先配置的第一列表中包含所述第二设备的标识信息，所述第一列表中包括需要认证的设备的标识信息。
  14. 根据权利要求12或13所述的方法，其特征在于，所述认证请求信息还包括所述第一设备的设备证书和/或所述第一设备使用的第一签名值；和/或
    所述认证响应信息还包括所述第二设备的第二设备证书和/或所述第二设备使用的第二签名值。
  15. 根据权利要求12或13所述的方法，其特征在于，所述认证请求信息还包括第一密码，所述第一密码是所述第一设备根据预存的预共享密钥和所述密码算法套件生成的；和/或
    所述认证响应信息还包括第二密码。
  16. 根据权利要求15所述的方法，其特征在于，所述认证请求信息还包括所述第一设备使用的第一临时公钥；
    所述认证响应信息还包括所述第二设备使用的第二临时公钥和所述第二设备的标识信息。
  17. 根据权利要求12至14中任一项所述的方法，其特征在于，所述认证请求信息还包括所述第一设备使用的第一随机数和/或所述第一设备使用的第一临时公钥；
    所述认证响应信息还包括所述第二设备使用的第二随机数和/或所述第二设备使用的第二临时公钥。
  18. 根据权利要求12至17中任一项所述的方法，其特征在于，所述至少一个密码算法套件中的每个密码算法套件满足前向安全性需求。
  19. 根据权利要求12至18中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一设备确定与所述第二设备通信使用的报文加密模式，所述报文加密模式包括全加密模式和按需加密模式中的一个。
  20. 根据权利要求19所述的方法，其特征在于，所述第一设备确定与所述第二设备通信使用的报文加密模式，包括：
    所述第一设备根据第四映射关系确定与所述第二设备的标识信息对应的所述报文加密模式，所述第四映射关系用于指示至少一个设备的标识信息与至少一个报文加密模式之间的对应关系。
  21. 根据权利要求19或20所述的方法，其特征在于，在所述报文加密模式是按需加密模式的情况下，所述方法还包括：
    所述第一设备生成通信报文，所述通信报文包括以下字段：明文标识、明文数据、密文标识、密文数据。
  22. 根据权利要求21所述的方法，其特征在于，所述明文数据中包含所述密文数据的流加密密钥生成种子。
  23. 一种通信装置，其特征在于，包括用于实现如权利要求1至11中任一项所述的方法的单元。
  24. 一种通信装置，其特征在于，包括用于实现如权利要求12至22中任一项所述的方法的单元。
  25. 一种通信装置，其特征在于，包括：
    处理器，用于执行存储器中存储的计算机指令，以使得所述通信装置执行：如权利要求1至11中任一项所述的方法。
  26. 一种通信装置，其特征在于，包括：
    处理器，用于执行存储器中存储的计算机指令，以使得所述通信装置执行：如权利要求12至22中任一项所述的方法。
  27. 一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被执行时，以使得如权利要求1至11中任一项所述的方法被执行。
  28. 一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被执行时，以使得如权利要求12至22中任一项所述的方法被执行。
PCT/CN2020/090460 2020-05-15 2020-05-15 通信的方法和通信装置 Ceased WO2021226989A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP20935848.0A EP4138335A4 (en) 2020-05-15 2020-05-15 COMMUNICATION METHOD AND COMMUNICATION APPARATUS
CN202080004098.1A CN113207322B (zh) 2020-05-15 2020-05-15 通信的方法和通信装置
PCT/CN2020/090460 WO2021226989A1 (zh) 2020-05-15 2020-05-15 通信的方法和通信装置
JP2022568488A JP7508589B2 (ja) 2020-05-15 2020-05-15 通信方法及び通信装置
KR1020227042579A KR102885085B1 (ko) 2020-05-15 2020-05-15 통신 방법 및 통신 장치
US17/987,694 US12413412B2 (en) 2020-05-15 2022-11-15 Communication method and communications apparatus for authentication in a handshake process

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/090460 WO2021226989A1 (zh) 2020-05-15 2020-05-15 通信的方法和通信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/987,694 Continuation US12413412B2 (en) 2020-05-15 2022-11-15 Communication method and communications apparatus for authentication in a handshake process

Publications (1)

Publication Number Publication Date
WO2021226989A1 true WO2021226989A1 (zh) 2021-11-18

Family

ID=77026375

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/090460 Ceased WO2021226989A1 (zh) 2020-05-15 2020-05-15 通信的方法和通信装置

Country Status (6)

Country Link
US (1) US12413412B2 (zh)
EP (1) EP4138335A4 (zh)
JP (1) JP7508589B2 (zh)
KR (1) KR102885085B1 (zh)
CN (1) CN113207322B (zh)
WO (1) WO2021226989A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115632863A (zh) * 2022-10-24 2023-01-20 贵州省通信产业服务有限公司 一种数据传输方法及系统
WO2024037048A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113676899A (zh) * 2021-08-09 2021-11-19 深圳市猿人创新科技有限公司 一种设备对码方法、装置及电子设备
CN115514473B (zh) * 2022-08-17 2026-01-02 阿里巴巴（中国）有限公司 数据安全通信的方法、系统、设备及存储介质
CN119232404A (zh) * 2023-06-29 2024-12-31 中兴通讯股份有限公司 信息加密传输方法、电子设备和存储介质
WO2025197548A1 (ja) * 2024-03-19 2025-09-25 ソニーセミコンダクタソリューションズ株式会社 電子機器、ホスト機器および電子機器システム
CN118300879B (zh) * 2024-04-29 2025-12-09 中国工商银行股份有限公司 通信认证方法、装置、计算机设备、存储介质和程序产品
CN119155103B (zh) * 2024-11-11 2025-02-25 北京中宏立达科技发展有限公司 一种服务隐匿的多点安全传输方法与系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010049673A1 (en) * 2008-10-27 2010-05-06 Qinetiq Limited Registered Office Quantum key distribution
EP2207302A1 (en) * 2007-11-07 2010-07-14 Nippon Telegraph and Telephone Corporation Common key setting method, relay device, and program
US20130195274A1 (en) * 2012-01-27 2013-08-01 Oki Electric Industry Co., Ltd. Commission information generator for making processes on communication performed by another computer
CN103763356A (zh) * 2014-01-08 2014-04-30 深圳大学 一种安全套接层连接的建立方法、装置及系统
CN107612899A (zh) * 2017-09-08 2018-01-19 浙江神州量子网络科技有限公司 一种基于量子密钥的OpenVPN安全通信方法和通信系统
CN108809633A (zh) * 2017-04-28 2018-11-13 广东国盾量子科技有限公司 一种身份认证的方法、装置及系统

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3253060B2 (ja) * 1997-12-25 2002-02-04 日本電信電話株式会社 相互認証方法及びその装置
JP2000349751A (ja) 1999-03-30 2000-12-15 Sony Corp 情報処理装置および方法、認証方法、並びにプログラム格納媒体
JP4696449B2 (ja) 2004-01-09 2011-06-08 ソニー株式会社 暗号化装置およびその方法
EP2217995A4 (en) * 2007-10-26 2012-11-21 Telcordia Tech Inc METHOD AND SYSTEM FOR ESTABLISHING SECURE SESSION USING IDENTITY BASED ENCRYPTION (VDTLS)
CN101616410B (zh) * 2009-06-25 2011-08-10 中兴通讯股份有限公司 一种蜂窝移动通信网络的接入方法和系统
US8943327B2 (en) * 2010-01-27 2015-01-27 Hewlett-Packard Development Company, L.P. Apparatus and method to enable operation between a main assembly and a sub-assembly that are cryptographically related
US9179303B2 (en) * 2010-11-17 2015-11-03 Qualcomm Incorporated Methods and apparatus for transmitting and receiving secure and non-secure data
US8881236B2 (en) * 2011-02-04 2014-11-04 Futurewei Technologies, Inc. Method and apparatus for a control plane to manage domain-based security and mobility in an information centric network
EP2733885A4 (en) * 2011-07-15 2015-06-17 Hitachi Ltd METHOD FOR DETERMINING AN ENCRYPTION ALGORITHM USED FOR A SIGNATURE AND VERIFICATION SERVER AND PROGRAM THEREFOR
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US8996873B1 (en) * 2014-04-08 2015-03-31 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US9184911B2 (en) * 2014-04-08 2015-11-10 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US8966267B1 (en) * 2014-04-08 2015-02-24 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US11087006B2 (en) * 2014-06-30 2021-08-10 Nicira, Inc. Method and apparatus for encrypting messages based on encryption group association
US9923923B1 (en) * 2014-09-10 2018-03-20 Amazon Technologies, Inc. Secure transport channel using multiple cipher suites
US9935769B1 (en) * 2014-12-12 2018-04-03 Amazon Technologies, Inc. Resource-based cipher suite selection
US10291589B1 (en) * 2014-12-12 2019-05-14 Amazon Technologies, Inc. Session-based access control determinations
US9787643B2 (en) * 2015-01-30 2017-10-10 Facebook, Inc. Transport layer security latency mitigation
RU2718689C2 (ru) * 2015-02-13 2020-04-13 Виза Интернэшнл Сервис Ассосиэйшн Управление конфиденциальной связью
US10116446B2 (en) * 2015-08-04 2018-10-30 Ge Aviation Systems Llc Cryptographic ignition key (CIK) embedded in removable data cartridge
CN106453269B (zh) * 2016-09-21 2021-06-25 东软集团股份有限公司 车联网安全通信方法、车载终端、服务器及系统
US10630466B1 (en) * 2016-11-03 2020-04-21 Hologram, Inc. Apparatus and method for exchanging cryptographic information with reduced overhead and latency
US10819510B2 (en) * 2018-02-06 2020-10-27 Wickr Inc. Facilitating communications using hybrid cryptography
US10841086B2 (en) * 2018-02-06 2020-11-17 Wickr, Inc. Facilitating communications using hybrid cryptography
WO2020006162A1 (en) * 2018-06-28 2020-01-02 Iot And M2M Technologies, Llc Ecdhe key exchange for mutual authentication using a key server
US11228448B2 (en) * 2018-11-20 2022-01-18 Iot And M2M Technologies, Llc Mutually authenticated ECDHE key exchange for a device and a network using multiple PKI key pairs
US12058260B2 (en) * 2019-02-24 2024-08-06 Nili Philipp System and method for securing data
US11343084B2 (en) * 2019-03-01 2022-05-24 John A. Nix Public key exchange with authenticated ECDHE and security against quantum computers
US11751049B2 (en) * 2019-05-01 2023-09-05 John A. Nix Distributed EAP-TLS authentication for wireless networks with concealed user identities
WO2021007235A1 (en) * 2019-07-08 2021-01-14 Nix John A Eap-tls authentication with concealed user identities and wireless networks
US11240270B1 (en) * 2019-08-13 2022-02-01 Wells Fargo Bank, N.A. Secure electronic transactions using transport layer security (SETUTLS)
CN110881048B (zh) * 2019-12-16 2021-11-09 苏宁云计算有限公司 基于身份认证的安全通讯方法及装置
EP3860035A1 (en) * 2020-01-29 2021-08-04 Sebastien Armleder Storing and determining a data element

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2207302A1 (en) * 2007-11-07 2010-07-14 Nippon Telegraph and Telephone Corporation Common key setting method, relay device, and program
WO2010049673A1 (en) * 2008-10-27 2010-05-06 Qinetiq Limited Registered Office Quantum key distribution
US20130195274A1 (en) * 2012-01-27 2013-08-01 Oki Electric Industry Co., Ltd. Commission information generator for making processes on communication performed by another computer
CN103763356A (zh) * 2014-01-08 2014-04-30 深圳大学 一种安全套接层连接的建立方法、装置及系统
CN108809633A (zh) * 2017-04-28 2018-11-13 广东国盾量子科技有限公司 一种身份认证的方法、装置及系统
CN107612899A (zh) * 2017-09-08 2018-01-19 浙江神州量子网络科技有限公司 一种基于量子密钥的OpenVPN安全通信方法和通信系统

Non-Patent Citations (1)

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

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024037048A1 (zh) * 2022-08-15 2024-02-22 华为技术有限公司 通信方法、装置和系统
JP2025526922A (ja) * 2022-08-15 2025-08-15 深▲ジェン▼引望智能技術有限公司 通信方法、装置、およびシステム
EP4561000A4 (en) * 2022-08-15 2025-11-19 Shenzhen Yinwang Intelligent Technology Co Ltd METHOD AND APPARATUS OF COMMUNICATION, AND SYSTEM
EP4564863A4 (en) * 2022-08-15 2025-11-26 Shenzhen Yinwang Intelligent Technology Co Ltd METHOD, APPARATUS AND COMMUNICATION SYSTEM
CN115632863A (zh) * 2022-10-24 2023-01-20 贵州省通信产业服务有限公司 一种数据传输方法及系统

Also Published As

Publication number Publication date
US20230080139A1 (en) 2023-03-16
CN113207322A (zh) 2021-08-03
EP4138335A1 (en) 2023-02-22
JP7508589B2 (ja) 2024-07-01
KR20230008167A (ko) 2023-01-13
EP4138335A4 (en) 2023-05-24
US12413412B2 (en) 2025-09-09
CN113207322B (zh) 2022-09-23
KR102885085B1 (ko) 2025-11-13
JP2023525090A (ja) 2023-06-14

Similar Documents

Publication Publication Date Title
US12047362B2 (en) Systems and methods for secure multi-party communications using a proxy
CN113207322B (zh) 通信的方法和通信装置
US11792169B2 (en) Cloud storage using encryption gateway with certificate authority identification
EP4014425B1 (en) Secure publish-subscribe communication methods and apparatus
US10009183B2 (en) Secure session capability using public-key cryptography without access to the private key
US20230421394A1 (en) Secure authentication of remote equipment
EP2561663B1 (en) Server and method for providing secured access to services
US11184177B2 (en) Method and system for securing in-vehicle ethernet links
WO2018019069A1 (zh) 一种资源操作方法及装置
CN110912685B (zh) 建立受保护通信信道
CN115766119A (zh) 通信方法、装置、通信系统及存储介质
WO2023279283A1 (zh) 建立车辆安全通信的方法、车辆、终端及系统
US12603863B2 (en) Hybrid cryptography virtual private networks
CN113950802A (zh) 用于执行站点到站点通信的网关设备和方法
CN111865956A (zh) 一种防服务劫持系统、方法、装置及存储介质
US8356175B2 (en) Methods and apparatus to perform associated security protocol extensions

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022568488

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020935848

Country of ref document: EP

Effective date: 20221118

ENP Entry into the national phase

Ref document number: 20227042579

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE