WO2021128989A1

WO2021128989A1 - Authentication method and device

Info

Publication number: WO2021128989A1
Application number: PCT/CN2020/116536
Authority: WO
Inventors: 唐甜; 乔立忠; 张梦楠; 曹斌
Original assignee: 华为技术有限公司
Priority date: 2019-12-26
Filing date: 2020-09-21
Publication date: 2021-07-01
Also published as: CN113055340B; CN113055340A

Abstract

Disclosed are an authentication method and device. An authentication tool (i.e. a second device) sends first information encrypted by means of a first private key to a first device to be authenticated, and the first device can perform decryption according to a first public key to obtain the first information, wherein the first public key corresponds to the first private key. Therefore, the first device can perform matching verification on the first information and locally stored second information to obtain a verification result, and determine a use permission of the first device according to the verification result. In this way, by means of encryption and decryption techniques and an authentication device with an authentication function, authentication of a first device to be authenticated is realized, security risks when the first device is currently secured by means of, for example, a codebook or an interface being exposed from a pad, are avoided; and safer and more reliable protection of the first device to be authenticated is ensured.

Description

Authentication method and equipment

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office of China, the application number is 201911368436.5, and the application name is "Authentication Method and Equipment" on December 26, 2019. The entire content is incorporated into this application by reference. .

Technical field

This application relates to the field of secure communication technology, and in particular to an authentication method and device. The method can be used to authenticate the device or the interface on the device when there is a need to open the device or the interface on the device.

Background technique

A lot of information is stored on the device, and some information is very important to the manufacturer or user of the device. At present, the device is usually authenticated by a codebook to ensure the security of the device and the information on it. Specifically, multiple passwords are stored in the codebook, and one or more passwords are preset on the device. When there is a need to open the use rights of the device, designated personnel (such as debuggers, operation and maintenance personnel, production Personnel, etc.) input the password in the password book into the device and match it with the password preset in the device. When the matching is successful, the device is deemed to have passed the authentication, and the access rights corresponding to the successfully matched password on the device are opened, thus The corresponding important information can be accessed through the use permission that has been opened on the device.

However, since the storage, transmission, and matching of the cipher book are all in plain text, and the manual management of the cipher book is very easy to reveal the password in the cipher book, it can be seen that using the cipher book to authenticate the device has low security. Based on this, it is urgent to provide an authentication method with a higher security level to ensure that the device is open to use permissions under safe conditions, so as to ensure the security of the information on it.

Summary of the invention

Based on this, the embodiments of the present application provide an authentication method and device. The information sent by the device to be authenticated is encrypted by the authentication tool and decrypted by the device to be authenticated, so that the device to be authenticated is more Secure authentication.

In the first aspect, an authentication method is provided, which is applied in a scenario that includes a first device and a second device, with the first device as the execution subject, the authentication method may include, for example, the first device receives a transmission from the second device After using the first private key to encrypt the first information, decrypt it according to the first public key to obtain the first information, where the first public key corresponds to the first private key; then, the first device can The information and the locally stored second information are matched and verified to obtain a verification result, and the use authority of the first device is determined according to the verification result. Specifically, when the verification result indicates that the verification is passed, the first device opens the corresponding use right, and when the verification result indicates that the verification fails, the first device does not open the corresponding use right. In this way, through the encryption and decryption technology and the second device with authentication function, the authentication of the first device to be authenticated is realized, which overcomes the current situation of protecting the security of the first device by means of codebooks or exposed pads corresponding to the interface. The potential safety hazards ensure the safer and more reliable protection of the first device to be authenticated.

Wherein, the first device may be any device to be authenticated, for example, it may refer to a network device or a single board, or for another example, it may also refer to a debugging interface or a service interface on the device. The second device may refer to an authentication tool with an authentication function. When the first device refers to the debugging interface, the authentication tool sends the first information encrypted by the first private key to the device where the debugging interface is located and decrypted by the first public key. After the verification is passed, the device where the debugging interface is located will open the The permission to use the debugging interface is for accessing and using the debugging interface.

Optionally, the first private key and the first public key may be generated by the second device; or, the first private key and the first public key may also be configured by the authentication server for the second device.

For more security, the embodiments of the present application may further include: the first device receives the first public key encrypted by the second private key of the authentication server sent by the second device; the first device uses the locally stored first public key of the authentication server The second public key is used to decrypt the encrypted first public key to obtain the first public key. In this way, encrypting the first public key by a server with a higher security level, which is the authentication server, is more secure and reliable than storing the first public key directly on the first device.

Optionally, the second information includes the first random number, and before the first information encrypted by the first private key sent by the second device is received, the embodiment of the present application may further include: the first device sends to the second device A challenge request message, the challenge request message carries the first random number; then, the first device receiving the first information encrypted by the first private key sent by the second device includes: the first device receiving the first information sent by the second device A response message, which carries the first information, and the first information includes a second random number; at this time, the first device performs matching verification on the first information and the locally stored second information, including: Perform matching verification on the first random number and the second random number. Among them, the first random number can uniquely identify an authentication to the first device, and the random number is used for authentication to ensure that each authentication can be performed based on the random number generated this time, which can effectively prevent the information of the first device Is copied to prevent replay attacks.

Optionally, the second information may also include first device identification information, and the first information includes second device identification information, where the first device identification information is used to uniquely identify the first device, then the first device Performing matching verification on the first information and the locally stored second information may also include: performing matching verification on the first device identification information and the second device identification information. As an example, the first device identification information is a first device ID, and the second device identification information is a second device ID. Then, the first device has a response to the first information and the locally stored second information Performing matching verification may also include: performing matching verification on the first device ID and the second device ID. As another example, for more security, the first device identification information is the hash value of the first device ID, and the second device identification information is the hash value of the second device ID. Performing matching verification on the first information and the locally stored second information may also include: performing matching verification on the hash value of the first device ID and the hash value of the second device ID. Wherein, the first device ID is used to uniquely identify the first device. For safe authentication, the device ID in this embodiment of the application is a non-public ID that can uniquely identify the device. For example, the first device ID is a hardware unique key (English: Hardware Unique Key, which is defined when the first device leaves the factory). Abbreviation: HUK), another example: the first device ID is obtained by processing the chip identification (English: die Identification, abbreviation: die ID) of the first device and the unique device identification (English: Unique Device Identification, abbreviation: UDI). In this way, through the first device identification information such as the first device ID or the hash value of the first device ID stored locally by the first device, the decrypted second device ID or the hash value of the second device ID and other second device identification information The device identification information is verified, and the first device is guided to manage its use authority, so as to realize reliable and safe authentication of the first device.

Optionally, the second information may also include target effective information, and the first information includes actual usage information, where the actual usage information is used to characterize the authentication of the second device on the first device. Happening. Then, the first device to perform matching verification on the first information and the locally stored second information may also include: the first device verifies the actual usage information according to the target valid information to determine the first information Whether the second device can continue to be used to authenticate the first device. When the first device determines that the actual usage information has not reached the target effective information, it determines that the second device is valid for the first device and can continue to use the second device to authenticate the first device; otherwise, when the first device determines If the actual use information has reached the target effective information, it is determined that the second device is invalid for the first device, and the second device cannot be used to authenticate the first device. Wherein, the target effective information is the maximum number of times allowed to use the second device for authentication (for example: 5 times); or, the target effective information is the maximum time allowed to use the second device for authentication (for example: 20 hour). In this way, the actual use information carried in the first information is verified through the target effective information stored locally by the first device, guiding the first device to manage its use rights, and realizing reliable and safe authentication of the first device.

Optionally, the first information may further include indication information, the indication information being used to indicate at least one of the following information: the time when the usage right is opened, the interface for opening the usage right, or the usage right is opened Operation. Wherein, the indication information may be sent by the first device to the second device in the challenge request message, or it may be corresponding indication information specified by the second device according to its own authentication range; it may also be the first device in the challenge request message. The corresponding indication information sent to the second device in the message and determined by the second device according to its own authentication range. In this way, the instruction information obtained after being received and decrypted by the first device guides the first device to manage the specific usage rights on it, thereby realizing reliable and safe authentication of the first device.

In the second aspect, the embodiments of the present application also provide a method for authenticating the use right of a first device. This method is applied in a scenario that includes the first device and the second device, and the second device is the execution subject. The right method may include, for example, the second device encrypts the first information by using a first private key stored locally, and sends the first information encrypted by the first private key to the first device, so as to The use authority of the first device is authenticated. In this way, through the encryption and decryption technology and the second device with authentication function, the authentication of the first device to be authenticated is realized, which overcomes the current situation of protecting the security of the first device by means of codebooks or exposed pads corresponding to the interface. The potential safety hazards ensure the safer and more reliable protection of the first device to be authenticated.

Among them, the second device may refer to an authentication tool with an authentication function. The first device may be any device to be authenticated, for example: it may refer to a network device or a single board, or for example: it may also refer to a debugging interface or a service interface on the device. When the first device refers to the debugging interface, the authentication tool sends the first information encrypted by the first private key to the device where the debugging interface is located and decrypted by the first public key. After the verification is passed, the device where the debugging interface is located will open the The permission to use the debugging interface is for accessing and using the debugging interface.

Optionally, the embodiment of the present application may further include: the second device receives the second public key of the authentication server sent by the authentication server, the first public key encrypted by the second private key, and the second public key encrypted by the second private key. The first private key encrypted by the private key, the second private key corresponds to the second public key; then, the second device uses the second public key to encrypt the second private key The first private key is decrypted to obtain the first private key; the second device may also send the first public key encrypted by the second private key to the first device, so that The first device decrypts the first public key encrypted by the second private key based on the locally stored second public key to obtain the first public key.

Optionally, the first information includes a first random number. Then, before encrypting the first information, the embodiment of the present application may further include: the second device receives the challenge request message sent by the first device, The challenge request message carries the first random number; then, the second device sending the first information encrypted by the first private key to the first device may include: The first device sends a response message, and the response message carries the first random number encrypted by the first private key.

Optionally, the first information may include first device identification information, and the first device identification information is used for identity verification by the first device. Wherein, the first device identification information is the first device identification ID or the hash value of the first device ID. As an example, when the first information includes the first device ID, the embodiment of the present application may further include: the second device matches the first device ID with a locally stored second device ID corresponding to the first device verification. As another example, the first information may also include the hash value of the first device ID. Then, the embodiment of the present application may further include: the hash value of the first device ID and the locally stored hash value of the first device ID. The hash value of the second device ID corresponding to a device is matched and verified. Wherein, the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or the first device ID is processed according to the chip ID die ID of the first device and the unique device ID UDI owned.

Optionally, the first information further includes target valid information, and the target valid information is used by the first device to determine whether the second device can continue to be used for authentication. Then, the embodiment of the present application may further include: The second device updates the actual usage information, and the actual usage information is used to characterize the current use of the second device authentication on the first device; then, the second device updates the information according to the target valid information. The subsequent actual use information is verified to determine whether the second device can continue to be used to authenticate the first device. Wherein, the target effective information is the maximum number of times that the second device is allowed to perform authentication, then the actual usage information is the actual number of times the first device uses the second device for authentication until the current time; Alternatively, the target valid information is the maximum time allowed to use the second device for authentication, then the actual usage information is the actual usage time from the timing start time of the target valid information to the current moment.

Optionally, the first information may further include indication information, the indication information being used to indicate at least one of the following information: the time when the usage right is opened, the interface for opening the usage right, or the usage right is opened Operation.

For the various possible implementation manners and technical effects achieved by the method provided in the second aspect, reference may be made to the introduction of the method provided in the first aspect, which will not be repeated here.

In the third aspect, this application also provides a first device, including a transceiver unit and a processing unit. Wherein, the transceiving unit is used to perform the transceiving operations in the method provided in the above first aspect; the processing unit is used to perform other operations in addition to the transceiving operations in the above first aspect. For example: when the first device executes the method described in the first aspect, the transceiving unit is used to receive the first information encrypted by the first private key sent by the second device; the processing unit is used to The first public key is decrypted to obtain the first information. The processing unit is also used to perform matching verification on the first information and the locally stored second information to obtain a verification result, and the processing unit is further used to obtain the verification result according to the verification result. , To determine the use permission of the first device.

In a fourth aspect, an embodiment of the present application also provides a second device, and the second device includes a transceiver unit and a processing unit. Wherein, the transceiving unit is used to perform the transceiving operation in the method provided in the above second aspect; the processing unit is used to perform other operations in addition to the transceiving operation in the above second aspect. For example: when the second device executes the method described in the second aspect, the transceiving unit is configured to send the first information encrypted by the first private key to the first device; the processing unit It is used to encrypt the first information by using the first private key stored locally.

In a fifth aspect, an embodiment of the present application also provides a first device, including a communication interface and a processor. Wherein, the communication interface is used to perform the transceiving operation in the method provided in the foregoing first aspect; the processor is used to perform other operations except the transceiving operation in the method provided in the foregoing first aspect.

In a sixth aspect, an embodiment of the present application also provides a second device, including a communication interface and a processor. Wherein, the communication interface is used to perform the transceiving operation in the method provided in the foregoing second aspect; the processor is used to perform other operations in the method provided in the foregoing second aspect except for the transceiving operation.

In a seventh aspect, an embodiment of the present application further provides a first device, and the first device includes a memory and a processor. Wherein, the memory is used to store program code; the processor is used to run instructions in the program code, so that the first device executes the method provided in the first aspect above.

In an eighth aspect, an embodiment of the present application also provides a second device, the second device including a memory and a processor. Wherein, the memory is used to store program code; the processor is used to run instructions in the program code, so that the first device executes the method provided in the second aspect above.

In a ninth aspect, the embodiments of the present application also provide a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer, causes the computer to execute the first aspect or the second aspect above. The authentication method provided by the aspect.

In a tenth aspect, the embodiments of the present application also provide a computer program product, which when running on a computer, causes the computer to execute the authentication method provided in the first or second aspect.

In an eleventh aspect, an embodiment of the present application also provides a communication system, which includes the first device provided in the third, fifth, or seventh aspect and the fourth, sixth, or first device provided in the third, fifth, or seventh aspect. The second device provided by the eighth aspect.

Description of the drawings

FIG. 1 is a schematic diagram of a network system framework involved in an application scenario in an embodiment of this application;

FIG. 2 is a schematic diagram of the authentication process of the device 12 in the scenario of FIG. 1 in an embodiment of the application;

FIG. 3 is a schematic flowchart of an authentication method 100 in an embodiment of this application;

FIG. 4 is a schematic flowchart of an authentication method 200 in the scenario of FIG. 1 in an embodiment of this application;

FIG. 5 is a schematic flowchart of an authentication method 300 in an embodiment of this application;

FIG. 6 is a schematic flowchart of a method 400 for authenticating the use right of a first device in an embodiment of this application;

FIG. 7 is a schematic structural diagram of a first device 700 in an embodiment of this application;

FIG. 8 is a schematic structural diagram of a second device 800 in an embodiment of this application;

FIG. 9 is a schematic structural diagram of a first device 900 in an embodiment of this application;

FIG. 10 is a schematic structural diagram of a second device 1000 in an embodiment of this application;

FIG. 11 is a schematic structural diagram of a first device 1100 in an embodiment of this application;

FIG. 12 is a schematic structural diagram of a second device 1200 in an embodiment of this application;

FIG. 13 is a schematic structural diagram of a communication system 1300 in an embodiment of this application.

Detailed ways

Some important information (for example: hard disk data of the device) is generally stored on the device. This important information is critical to the safety of the device, and certain protective measures need to be taken to ensure the safety of this important information.

At present, the device is usually authenticated by a codebook. One or more passwords are preset on the device, and multiple passwords are stored in the codebook. When the permission to use the device needs to be opened, the debugging personnel, operation and maintenance Designated personnel, such as personnel, production personnel, enter the password in the codebook into the device, and the device will match the entered password with the preset password. When the match is successful, it will be regarded as the authentication of the device passed, and the device will be opened. The use authority corresponding to the successfully matched password, so that the corresponding important information can be accessed through the open use authority. Although the cipher book is controlled by a small number of designated personnel, which can ensure the security of important information stored on the device to a certain extent, the storage, transmission and matching of the cipher book are all in plain text, and the designated personnel with the authority of the cipher book It is more complicated, and it is very easy to leak the password in the codebook by manual management. The method of using the codebook to authenticate the device has low security.

In addition, because access to important information on the device is usually achieved through key interfaces on the device (such as a debugging interface or a business interface), many equipment manufacturers remove the connectors of these key interfaces when the device leaves the factory (that is, the key The corresponding pads of the interface are exposed) to ensure the safety of important information on the device. However, an attacker can identify the pads corresponding to these key interfaces through observations and instruments such as multimeters, and connect the key interfaces to the analyzer through jumpers to directly obtain these important information, which is very insecure. For example, the hardware data of a Microsoft notebook is usually encrypted and protected by a two-level key, that is, encrypted by a full volume encryption key (English: Full Volume Encryption Key, abbreviated as: FVEK), and encrypted by a volume master key (English: Volume Master Key). , Referred to as VMK) (also referred to as the original key) encrypts FVEK; the VMK is stored in a trusted platform module (English: Trusted Platform Module, referred to as TPM). When Microsoft produced the laptop, it added the LPC (English: Low Pin Count) interface of the TPM to test the performance of the laptop. However, when the laptop was shipped, the interface was exposed from the corresponding pad of the connector. Then, the attacker It is easy to identify the LPC interface of the exposed TPM, and connect the interface to the logic analyzer through a jumper to directly obtain the VMK, thereby cracking the FVEK encrypted by the VMK, and then cracking the hard disk encrypted by the FVEK Data seriously endangers the safety of the laptop.

It can be seen that neither the cipher key protection method nor the above-mentioned method of removing the connector of the key interface of the device at the factory can not well ensure the security of the device and the security of important information on the device.

Based on this, the embodiment of the present application provides an authentication method. When the user needs to access the first device, the first device needs to be authenticated. After the authentication is passed, the corresponding usage rights on the first device can be opened for the user to access the first device. Safely access or use the first device within the scope of the open use authority. The first device to be authenticated locally stores the second information and the first public key. The authentication process may specifically include: the first device to be authenticated sends the first device to a second device with authentication function such as an authentication tool. Second information; for the second device, the first information sent by the first device is received (the first information may be the same as the second information, or may be different from the second information), based on the first private key pair received The information is encrypted, and the first information encrypted by the first private key is sent to the first device; the first device decrypts according to the first public key to obtain the first information, and the first information and the locally stored first information The second information is matched and verified to obtain a verification result, and then the use authority of the first device is determined according to the verification result. In this way, through the encryption and decryption technology and the second device with authentication function, the authentication of the first device to be authenticated is realized, which overcomes the current situation of protecting the security of the first device by means of codebooks or exposed pads corresponding to the interface. The potential safety hazards ensure the safer and more reliable protection of the first device to be authenticated.

For example, one of the scenarios of the embodiment of the present application may be applied to the network as shown in FIG. 1. Referring to Figure 1, the network includes: an authentication tool 11 and a device 12. Wherein, the authentication tool 11 may be a physical entity designed by the manufacturer of the device 12 to authenticate the device 12 that it leaves the factory. The authentication tool 11 stores the private key a locally, and uses the private key a as information. Encryption function. The device 12 can be any device that needs to be authenticated. For example, the device 12 can be a network device such as a router or a switch, a terminal device such as a mobile phone, a laptop, etc., a mobile storage device such as a USB flash drive, or a debugging device. Interface, service interface or single board. The scenario shown in FIG. 1 may also include a certificate authority (English: Certificate Authority, abbreviated as: CA) server 13 for allocating public and private keys to authentication tools to improve the security level of the authentication scenario.

In specific implementation, the authentication tool 11 stores the private key a in the local secure storage area, and the device 12 stores the public key A in the local secure storage area, and the private key a corresponds to the public key A. When the device 12 needs to be accessed, the authentication process for the device 12 is shown in Fig. 2, which may include: S11, the device 12 generates a random number 1; S12, the device 12 carries the random number 1 in the challenge request message and sends it to the authentication tool 11. S13, the authentication tool 11 uses the private key a to encrypt the received random number 2 (which can be consistent with the random number 1, or inconsistent with the random number 1) to obtain X; S14, the authentication tool 11 carries X in The response message is sent to the device 12; S15, the device 12 uses the public key A to decrypt X to obtain the random number 2; S16, the device 12 compares the random number 1 and the random number 2. If the two are the same, it means that the device 12’s The authentication passed this time, otherwise, it means that the authentication of the device 12 failed this time. In this way, more secure protection of the authentication device 12 is realized.

It should be noted that the above-mentioned public key A and private key a can be generated by the authentication tool 11 itself, or distributed by the CA server 13 for the authentication tool 11, which can be specifically determined according to the security requirements of the device 12. In this application There is no specific limitation in the embodiment. Wherein, the CA server 13 may be an offline server relative to the authentication tool 11 and the device 12, requiring a user (for example, a manager of the device 12) to configure the authentication tool 11 and the device 12 through a secure production environment device as a medium; Alternatively, compared to the authentication tool 11 and the device 12, the CA server 13 may also be an online server, which can directly pass the connection established between the CA server 13 and the authentication tool 11 and the connection established between the CA server 13 and the device 12 Connect to interact, no need to be transferred by the user.

It should be noted that the local secure storage area of the device in the embodiment of the present application refers to a storage area in the local storage area of the device that cannot be easily accessed or tampered with. For example, the secure storage area can be the one-time programmable memory of the device (English: One-Time Programmable, abbreviated as OTP), and for example: the secure storage area can also be the electrical fuse of the device (English: electrical FUSE, abbreviated as: eFUSE) ), because the content stored in the secure storage area such as OTP or eFUSE cannot be changed, the local secure storage area of the device can store important information reliably and securely. For example, the local secure storage area of the authentication tool 11 can be reliable and secure. To save the private key a, the local secure storage area of the device 12 can save the public key A reliably and securely.

It is understandable that the foregoing scenario is only an example of a scenario provided in an embodiment of the present application, and the embodiment of the present application is not limited to this scenario.

The specific implementation of the authentication method in the embodiment of the present application will be described in detail below with reference to the accompanying drawings and embodiments.

FIG. 3 is a schematic flowchart of an authentication method 100 in an embodiment of this application. Referring to Fig. 3, the method 100 is applied to a network including a device 1 and a device 2, where the device 1 has a public key 1 stored in advance. When the device 1 needs to be accessed, the method 100 can be executed first to authenticate the device 1. For example, the method 100 can be applied to the network shown in FIG. 1, the device 1 can be the device 12, and the device 2 can be the authentication tool 11. The method 100 may include the following S101 to S106, for example:

S101: Device 2 receives information 1 sent by device 1.

Among them, device 2 refers to the physical entity used to authenticate the device 1 to be authenticated, also known as an authentication tool, used to authenticate the device to be authenticated, and determine whether to open the right to use the device to be authenticated . The device 2 may include an authentication interface, which is used to establish a connection with the device 1 to be authenticated. The authentication interface may be a wired interface, such as a universal serial bus (English: Universal Serial Bus, abbreviated as: USB) interface or Joint Test Action Group (English: Joint Test Action Group, JTAG for short) interface; or, the authentication interface may also be a wireless interface, such as Bluetooth.

Device 1 refers to the device to be authenticated. In the embodiment of the application, the device to be authenticated can be a network device, such as a switch, a router, or a terminal device, such as a mobile phone, a laptop, or a mobile storage device. A device, such as a USB flash drive, can also be an interface, such as a debugging interface, a service interface, or a single board.

Information 1 may include: random number 2 received by device 2. When the device 1 needs to perform authentication, it can generate the random number 1 corresponding to the second authentication, and save the random number 2 in the local secure storage area of the device 1. The random number 1 can uniquely identify an authentication to device 1, and use random numbers for authentication to ensure that each authentication can be performed based on the random number generated this time, which can effectively prevent the information of device 1 from being copied. Replay attack.

In specific implementation, before S101, device 1 may send a challenge request message to device 2, and the challenge request message carries the random number 1. Then, S102 may specifically be: device 2 receives the challenge request message and obtains a random number from it. Number 2, it is understandable that if the challenge request message is correct in the transmission process, random number 2 and random number 1 are consistent, otherwise, random number 2 may also be inconsistent with random number 1.

In addition, the information 1 may also include: the device identification information 2 corresponding to the device 1 received by the device 2, and the device identification information 2 may be used to uniquely identify the device 1. Specifically, the device identification information 2 may be a device identification (English: Identification, abbreviation: ID) 2 or a hash value of the device ID2. The device 1 stores the device ID1 or the hash value of the device ID1 of the device 1. The device ID1 can be an identifier that can uniquely identify the device 1. The hash value of the device ID1 is the hash obtained by the hash calculation of the device ID1 value. For more security, the device ID1 may be a non-public identification of the device 1 to the outside. For example: the device ID1 can be the hardware unique key (English: Hardware Unique Key, abbreviated as HUK) defined when the device 1 leaves the factory; for another example: the device ID1 can also be a unique device identification based on the device 1 (English: Unique Device) Identification (abbreviation: UDI) and the identification obtained by the chip identification (English: die Identification, abbreviation: die ID) in the device 1. It can be seen that the use of device ID1 or the hash value of device ID1 for authentication can effectively control the authentication authority of device 2. That is, after an attacker or user obtains the public key, they can only attack or use device 1, but cannot use this The public key authenticates other devices and develops corresponding usage rights, minimizing security risks and improving the security protection of devices.

In addition, the information 1 may also include target valid information, which is used by the device 1 to determine whether the device 2 can continue to be used for authentication. The target validity information may specifically be the maximum number of times allowed to use device 2 for authentication (for example: 5 times), or the maximum time allowed to use device 2 for authentication (for example: 1 day), so as to refer to the validity of the target The information limits the effective use times or duration of the device 2 so that the device 2 is controlled to be used within a safe range.

If the device 1 needs to configure its own authentication range, then the information 1 may also include indication information, which is used to indicate at least one of the following information: the time when the use authority is opened (for example: the time when the use authority is opened It can be accessed within 2 hours), interfaces with open access rights (for example: open 3 debugging interfaces on device 1, or open debug interface 1 and debugging interface 2 on device 1) or open access operations (for example : Allow read operation on device 1, or allow write operation on device 1). It should be noted that, according to the authentication requirements, device 1 may not specify the authentication scope, that is, the indication information is not included in information 1, and the authentication scope is configured by device 2, or no configuration is performed. After the authentication is passed, the use authority of the device 1 is opened according to the set default authentication scope.

Before using the device 2 to authenticate the device 1, at least the private key 1 is pre-stored in the local secure storage space of the device 2, and the device 2 establishes a connection with the device 1 through its authentication interface.

In specific implementation, when there is an access requirement for device 1 and device 1 needs to be authenticated, device 1 may send a challenge request message to device 2, and the challenge request message received by device 2 carries information 1.

As an example, the challenge request message may only include the content of the challenge request message itself. For example, the challenge request message includes: challenge type, key type, key number, and challenge field length, then information 1 only includes: challenge type , Key type, key number, and challenge field length. Among them, the challenge type is predefined by device 1 and device 2 and used to indicate the role of the challenge request message. For example, when the value of the challenge type field is 0x5AAA555A, it means that the challenge request message is used to indicate the authentication of device 1 . The key classification is used to indicate the type of the key pair currently used. For example, when the value of the key classification field is 0x07, it means that the authentication key pair is currently used. For example, when the value of the key classification field is 0x09, which means that the remote attestation key pair is currently being used. The key number is used to indicate the specific key pair currently in use, that is, the key pair corresponding to the public key 1 stored locally. For example, the authentication key pair can include 16 key pairs, which are allocated to different products. Or when different interfaces are used to prevent a certain key pair from being leaked, another key pair can be allowed to be used, and the impact range will not be too large. The length of the challenge field can be used for signal verification to prevent problems such as loss of information sent during the transmission of the challenge request message.

As another example, in order to increase the security level for device 1 authentication, the challenge request message can also add a field to carry at least one of the random number 1, the device ID1, and the hash value of the device ID1. Then, the Information 1 not only includes the content of the challenge request message itself, but also includes at least one of the random number 2, the device ID2, and the hash value of the device ID2. Among them, if device 1 sends the challenge request message to device 2 and device 2 receives the challenge request message, no error occurs, then random number 2 is consistent with random number 1, device ID2 is consistent with device ID1, and device ID2 The hash value of is the same as the hash value of device ID1.

As another example, according to the authentication needs of the device 1, other fields can be added to the challenge request message to carry indication information or target validity information. Then, the information 1 not only includes the content of the challenge request message itself, It also includes indication information or target valid information; or, on this basis, information 1 may also include: at least one of a random number 2, a device ID2, and a hash value of the device ID2.

In this way, device 1 sends a challenge request message to device 2 to instruct device 2 to perform authentication for device 1. After receiving the challenge request message, device 2 obtains information 1 by parsing the challenge request message, which provides a data basis for device 1 authentication.

S102, the device 2 encrypts the information 1 according to the private key 1.

The private key 1 is a private key stored in the local secure storage space of the device 2 and is used to encrypt the information 1 received by the device 2 when the device 1 is authenticated.

In some possible implementation manners, the device 2 can use the public and private key generated by itself to authenticate the device 1. Then, the private key 1 can be generated by the device 2 based on an internal algorithm and stored locally. In this example, the device 2 also needs to send the public key 1 corresponding to the private key 1 to the device 1 before performing the following S105, so that the device 1 saves the public key 1 in the local secure storage space.

For example: when information 1 includes the content of the challenge request message itself and random number 2, information 1 may specifically include: the challenge type encrypted by the private key 1, the random number encrypted by the private key 1, the key type encrypted by the private key 1, The key number encrypted by private key 1 and the length of the challenge field encrypted by private key 1.

In other possible implementations, in order to improve the security level, device 2 can also apply for a public-private key pair from device 3 to authenticate device 1. Then, the private key 1 can be assigned by device 3 to device 2. Private key. Among them, the device 3 may be, for example, an authentication server with a high security level such as a CA server.

Regardless of whether the public key 1 and the private key 1 are generated by the device 2 itself or assigned by the device 3, they can be encrypted by the private key 2 on the device 3 and sent to the device 2 to improve security. In specific implementation, the process of sending a public-private key pair from device 3 to device 2 may include, for example: S21, device 2 sends a request message to device 3 for requesting device 3 to send a public-private key pair for authenticating device 1; S22: In response to the request message, device 3 determines the private key 1 and corresponding public key 1 to be sent to device 2, and, in order to further improve security, device 3 uses its own private key 2 to combine private key 1 and public key 1 is encrypted; S23, device 2 receives the private key 2 sent by device 3, and the corresponding public key 2; S24, device 2 receives the private key 2 sent by device 3, encrypted private key 1 and private key 2 encrypted public key 1; S25 , The device 2 uses the public key 2 to decrypt the private key 1 encrypted by the private key 2 to obtain the private key 1, and save the private key 1 in the local secure storage space. In this example, the device 1 locally pre-stores the public key 2 corresponding to the private key 2 on the device 3, so that during subsequent authentication, the device 2 sends the public key 1 encrypted by the private key 2 to the device 1, and the device 1 uses the locally stored public key 2 The public key 2 decrypts the public key 1 encrypted by the private key 2, and saves the public key 1 obtained after decryption locally to provide a data basis for authentication.

It should be noted that the way in which device 3 sends public key 2 to device 1, and in S23 and S24, device 3 can send public key 2, private key 1 encrypted by private key 2, and public key 1 encrypted by private key 2 to The mode of the device 2 can be determined according to whether the device 3 is an offline server or an online server. When device 3 is offline relative to device 1, the user can copy public key 2 from device 3 through a secure production environment device, and configure public key 2 to device 1 through the secure production environment device; 3 When the device 1 is online, the device 3 can directly send the public key 2 to the device 1 through the connection established between the two. Similarly, when the device 3 is offline relative to the device 2, the user can submit the above request message on the device 3. The user copies the public key 2 and the private key encrypted by the private key 2 from the device 3 through a secure production environment device After public key 1 encrypted by 1 and private key 2, configure public key 2, private key 1 encrypted by private key 2 and public key 1 encrypted by private key 2 to device 2 through a secure production environment device; when device 3 is opposite When the device 2 is online, the device 3 can directly send the public key 2, the private key 1 encrypted by the private key 2 and the public key 1 encrypted by the private key 2 to the device 2 through the connection established between the two.

For S23 and S24, as an example, the device 3 can carry the public key 2, the private key 1 encrypted by the private key 2, and the public key 1 encrypted by the private key 2, in a message, and feed it back to the device 2. As another example, for more security, the device 3 can carry the public key 2 in one message, carry the private key 1 encrypted by the private key 2 and the public key 1 encrypted by the private key 2 in another message, and feed them back to Equipment 2.

For S102, if the information 1 includes the device identification information 2, the device 2 can also store locally a list of device identification information responsible for authentication, and all the devices identified in the list can be the objects of the device 2 authentication. After device 2 receives information 1, it can first perform matching verification on the device identification information 2 with the locally saved device identification information list, if it matches, execute S102, otherwise, it is determined that device 1 is not the target of device 2 authentication , Suspend this authentication.

It should be noted that when the device identification information 2 included in the information 1 is the device ID2 or the hash value of the device ID2, in order to distinguish different devices 1 that all use the device 2 for authentication, S102 may include the device ID2 or the device ID2. The information 1 with the hash value of is encrypted and sent to the device 1, so that different devices 1 can determine whether to authenticate themselves based on the device ID or the hash value of the device ID in the received encrypted information 1; or , S102 can also remove the device ID2 or the hash value of the device ID2 in the information 1, and then encrypt the remaining information 1 and send it to the device 1. That is, the information 1 does not include the device ID 2 or the device encrypted by the private key 1 The hash value of ID2.

For S102, if the information 1 includes target effective information, the device 2 can also store actual effective information locally, and the actual effective information is used to characterize the current use of the device 2 to authenticate the device 1. After device 2 receives information 1, it can update the actual use information first, and then perform matching verification on the target effective information and the updated actual use information. If they match (that is, the actual use information of device 2 does not reach the target effective information), S102 is executed, otherwise, it is determined that the device 2 is invalid and the device 1 cannot be authenticated. After the device 2 fails, the manufacturer of the device 1 can reset the actual valid information of the device 2 to restore the authentication function of the device 2 to the device 1.

As an example, when the target effective information is the maximum number of times that device 2 is allowed to perform authentication (for example: 5 times), then the actual use information is the actual number of times that device 1 has used device 2 to perform authentication (for example: 3). Times), when device 2 receives information 1 again, it can add one to the actual number of uses, and determine whether the new actual number of uses is less than or equal to the target effective information, if so, execute S102, otherwise, stop using device 2 Device 1 authenticates and prompts that device 2 is invalid.

As another example, when the target valid information is the longest time allowed to use the device 2 for authentication (for example: 24 hours), then the actual usage information is from the timing start time of the target valid information to the current time The actual use time (for example: 10 hours), when the device 2 receives information 1, it can update the actual use time to the time elapsed from the timing start time of the target effective information to the current time (for example, : 12 hours), and judge whether the new actual use time reaches the target effective information, if not, execute S102, if yes, stop using the device 2 to authenticate the device 1 and prompt the device 2 to be invalid.

It should be noted that when the target valid information is included in the message 1, S102 may encrypt the message 1 including the target valid information and send it to the device 1; or, in S102, after removing the target valid information in the message 1, the The remaining information 1 is encrypted and sent to the device 1, that is, the information 1 does not include the target effective information encrypted by the public key 1. Alternatively, the information 1 can also carry the updated actual usage information in the information 1 and send it to the device 1, so that the device 1 can reconfirm whether the device 2 is valid based on the actual usage information and the target valid information stored locally.

For S102, if information 1 includes instruction information, device 2 can encrypt information 1 including instruction information and send it to device 1; or, if information 1 includes instruction information, device 2 can also store its responsible counterpart locally. Device 1 performs the authentication range of authentication. Then, after device 2 receives information 1, it can first match and verify the indication information with the authentication range of device 1 stored locally, and then correspond to the matched authentication range The instruction information is encrypted based on the private key 1 and then sent to the device 1 as part of the information 1. Or, if the instruction information is not included in the information 1, but the device 2 locally stores the authentication scope that it is responsible for authenticating the device 1, Then, after device 2 receives information 1, it can encrypt the indication information corresponding to the authentication scope stored locally based on private key 1 and then send it to device 1 as a part of information 1; or, if information 1 does not include indication information , And device 2 does not store the authentication scope responsible for authenticating device 1 locally, then S102 can be executed directly, and the instruction information is not included in message 1, and device 1 can open device 1’s default settings according to its default settings. Use permissions.

S103: The device 2 sends the information 1 encrypted by the private key 1 to the device 1.

S104: The device 1 receives the information 1 encrypted by the private key 1 sent by the device 2.

In specific implementation, as a response to the challenge request message sent by device 1 to device 2, device 2 may carry information 1 in a response message corresponding to the challenge request message and send it to device 1.

As an example, the device 2 may use the public key 1 encrypted by the private key 2 and the encrypted content of the information 1 as the information 1 at the same time, and send it to the device 1 in a response message. For example: when information 1 includes the content of the challenge request message itself and random number 2, information 1 encrypted by private key 1 may specifically include: public key encrypted by private key 2, challenge type encrypted by private key 1, and encryption by private key 1. The random number 2, the key type encrypted by private key 1, the key number encrypted by private key 1, and the length of the challenge field encrypted by private key 1.

As another example, in order to be more secure, the device 2 may also separately send the public key 1 encrypted by the private key 2 to the device 1, and carry the information 1 in the response message and send it to the device 1. For example: when the information 2 includes the content of the challenge request message itself and the device ID2, the information 1 encrypted by the private key 1 may specifically include: the challenge type encrypted by the private key 1, the device ID encrypted by the private key 1, and the secret encrypted by the private key 1. The key type, the key number encrypted by the private key 1, and the length of the challenge field encrypted by the private key 1. The device 2 sends the public key 1 encrypted by the private key 2 to the device 1 through a message other than the message of the transmission information 1.

If the information 1 only includes the content of the challenge request message itself, the information 1 encrypted by the private key 1 in the response message may specifically include: the challenge type encrypted by the private key 1, the key type encrypted by the private key 1, and the private key 1 encrypted The length of the challenge field encrypted by the key number and private key 1.

If the information 1 includes the content of the challenge request message itself and the random number 2, then the information 1 encrypted by the private key 1 in the response message may specifically include: the challenge type encrypted by the private key 1, the random number encrypted by the private key 1, 2, the private key 1Encrypted key type, private key 1 encrypted key number, and private key 1 encrypted challenge field length.

If information 1 includes the content of the challenge request message itself and device identification information 2 (for example: device ID2 or the hash value of device ID2), then the information 1 encrypted by private key 1 in the response message may specifically include: encrypted by private key 1 Challenge type, identification information 2 encrypted by private key 1 (for example: device ID 2 encrypted by private key 1 or hash value of device ID 2 encrypted by private key 1), key type encrypted by private key 1, and secret encrypted by private key 1. The length of the challenge field encrypted by the key number and private key 1.

If the information 1 includes the content and instruction information of the challenge request message itself, the information 1 encrypted by the private key 1 in the response message may specifically include: the challenge type encrypted by the private key 1, the instruction information encrypted by the private key 1, and the private key 1 encryption The key type, the key number encrypted by private key 1, and the length of the challenge field encrypted by private key 1.

It should be noted that, in addition to the content of the challenge request message itself, information 1 may also include one or more of random number 2, device identification information 2, and indication information. For example: when information 1 includes the content of the challenge request message itself, indication information, random number 2 and device identification information 2, the information 1 encrypted by private key 1 in the response message may specifically include: challenge type encrypted by private key 1, private key 1 encrypted random number 2, private key 1 encrypted device identification information 2, private key 1 encrypted instruction information, private key 1 encrypted key type, private key 1 encrypted key number, and private key 1 encrypted challenge field length.

In this way, device 2 sends a response message to device 1. After receiving the response message, device 1 parses the response message to obtain information 1 encrypted by device 2 with its private key 1, which provides data for authenticating device 1 basis.

S105: Device 1 performs decryption according to public key 1 to obtain information 1.

S106: The device 1 compares the information 1 with the locally stored information 2 to obtain a verification result, and determines the use right of the device 1 according to the verification result.

As an example, if only the content of the challenge request message itself is contained in the information 1, the decrypted information 1 by the device 1 may include: challenge type, key type, key number, and challenge field length. In this example, S106 may specifically be: if the device 1 locally stores the content of the challenge request message itself, then the decrypted content of the challenge request message itself can be compared with the content of the challenge request message itself stored locally. If they are consistent, it is determined that the use authority of device 1 is opened; otherwise, it is determined that the authentication of device 1 has failed; or, if the content of the challenge request message itself is not saved locally, S105 to S106 may specifically be: as long as the public key 1 is used By decrypting to obtain information 1, it can be determined that the authentication of the device 1 is passed and the use right of the device 1 is opened; otherwise, it is determined that the authentication of the device 1 has failed.

As another example, if information 1 includes the content of the challenge request message itself and random number 2, then the information 1 decrypted by device 1 may include: challenge type, random number 2, key type, key number, and challenge field length . In this example, for S106, it can be specifically: Device 1 judges whether the random number 1 stored locally and the random number 2 in the information 1 are consistent, if they are consistent, it determines that the use authority of device 1 is opened; otherwise, it determines that device 1 authenticates. Right to fail.

As another example, if information 1 includes the content of the challenge request message itself and device identification information 2, then the information 1 decrypted by device 1 may include: challenge type, device identification information 2, key type, key number, and challenge The length of the field. In this example, for S106, it can specifically be: Device 1 determines whether the locally stored device identification information 1 and the device identification information 2 in the information 1 are consistent, if they are consistent, then the use authority of the device 1 is opened, otherwise, the device is determined 1Authentication failed.

As another example, if the information 1 includes the content and indication information of the challenge request message itself, the information 1 decrypted by the device 1 may include: challenge type, indication information, key type, key number, and challenge field length. In this example, for S106, it may specifically be: if the device 1 stores the instruction information locally, the instruction information obtained after decryption can be compared with the instruction information stored locally, and if they are consistent, the device 1’s information is opened according to the instruction information. Use permission, otherwise, it is determined that the authentication of device 1 has failed; or, if device 1 does not store the indication information locally, the indication information can be regarded as the authentication range configured by device 2 for device 1. Then, S105 to S106 may specifically be: As long as the public key 1 is used to decrypt the information 1, it can be determined that the authentication of the device 1 is passed, and the use authority of the device 1 is opened according to the instruction information; otherwise, it is determined that the authentication of the device 1 has failed.

It should be noted that, in addition to the content of the challenge request message itself, the information 1 may also include one or more of the random number 2, the device identification information 2, and the indication information. For example: when the information 1 includes the content of the challenge request message itself, the instruction information, the random number 2 and the identification information 2, for S106, it can be specifically: the device 1 judges the random number 1 stored locally and the random number in the information 1 2 Whether they are consistent, if they are inconsistent, it is determined that the authentication of device 1 has failed; if they are consistent, continue to determine whether the locally stored device identification information 1 and the device identification information 2 in the information 1 are consistent, if they are inconsistent, determine the device 1 Authentication failed; if they are consistent, take the indication information carried in the challenged request message stored locally in device 1 as an example, continue to compare whether the indication information obtained after decryption is consistent with the indication information stored locally, if they are inconsistent, determine the device 1 The authentication fails; if they are consistent, the use authority of the device 1 is opened according to the instruction information and the device identification information 1.

Device 1 can be a network device or a single board. Taking Device 1 as a network device as an example, as an example, when the results of the comparison processes in S106 are consistent, the network device opens the use rights of all interfaces on it; or, when When the results of the comparison processes in S106 are inconsistent, the network device does not open the use right of any interface on it. As another example, the information 1 also carries indication information, such as a debugging interface ID. Then, when the results of the comparison processes in S106 are consistent, the network device can open the corresponding usage rights according to the indication information, for example: Open the use right of the debugging interface corresponding to the debugging interface ID; or, when the results of the comparison processes in S106 are inconsistent, the network device does not open the use right of any interface on it.

Device 1 can also refer to a debugging interface or service interface on a certain device. When the results of the comparison processes in S106 are consistent, the device can open the corresponding debugging interface or service interface on it. When the results of the comparison processes in S106 are inconsistent, the device may not open the use right of the debugging interface or the service interface.

In this way, through the interaction between the device 1 and the device 2, a safe and reliable authentication of the device 1 is realized, thereby ensuring that all accesses to the device 1 are safe.

In some specific implementations, for the scenario where device 3 configures a public-private key pair for device 2 with a higher security level, device 3, as an absolutely secure device, also has the ability to update device 3’s own public and private keys and revoke the allocation for device 2 The ability of public and private keys makes it more flexible and controllable to use device 2 as an authentication tool to authenticate device 1.

As an example, when the device 3 determines that its public key 2 and private key 2 are not sufficiently secure, and there may be a certain security risk, it is determined that the public key 2 and the private key 2 are invalid. The embodiment of the present application may further include: S31, the device 3 Enable private key 4 and corresponding public key 4; S32, device 3 uses private key 4 to encrypt public key 1 and private key 1 respectively; S33, device 3 uses public key 4 and private key 4 to respectively encrypt public key 1 And using private key 4 to configure private key 1 to device 2; S34, device 2 uses public key 4 to decrypt private key 1 using private key 4 to obtain private key 1 and save it in the local secure storage space of device 2 In; S35, device 1 sends a challenge request message to device 2; S36, device 2 sends a response message 1 to device 1, the response message 1 at least includes: challenge type, public key 4, key type, key number and challenge The field length. The value of the challenge type field in the response message 1 is used to instruct device 1 to update the public key corresponding to device 3 stored on it, for example: the value of the challenge type field = 0x55AA555A; S37, device 1 deletes public key 2 Or set public key 2 as a prohibited public key, and save public key 4 accordingly. In this way, the device 3 realizes the update of the public key stored on the device 1, making it possible to control the authentication of the device 1 more securely and reliably.

As another example, when the device 3 determines that the public key 1 and the private key 1 allocated to the device 2 are not secure enough and there may be a certain security risk, it is determined that the public key 1 and the private key 1 are invalid. The embodiment of the application may also Including: S41, device 3 redistributes private key 3 and corresponding public key 3 for device 2; S42, device 3 uses private key 2 to encrypt public key 3 and private key 3 respectively; S43, device 3 encrypts public key 2, Use private key 2 to separately configure public key 3 and private key 2 to private key 3 to device 2; S44, device 2 uses public key 2 to decrypt private key 3 using private key 2 to obtain private key 3 and Save it in the local secure storage space of device 2. In this way, the device 3 realizes the revocation and update of the public key and the private key used for authentication on the device 2, so that the device 2 can authenticate the device 1 more securely and reliably.

As another example, when device 3 determines that its public key 2 and private key 2 are not secure enough, and the public key 1 and private key 1 allocated by device 3 to device 2 are also not secure enough, there may be a certain security risk, determine the The public key 2, the private key 2, the public key 1, and the private key 1 are all invalid. The embodiment of this application may also include: S51, the device 3 activates the user private key 4 and the corresponding public key 4, and redistributes the private key for the device 2 3 and the corresponding public key 3; S52, device 3 uses private key 4 to encrypt public key 3 and private key 3 respectively; S53, device 3 uses public key 4 and private key 4 to public key 3 and private key respectively 4 Configure the private key 3 to the device 2 respectively; S54, the device 2 uses the public key 4 to decrypt the private key 3 with the private key 4 to obtain the private key 3 and save it in the local secure storage space of the device 2; S55, Device 1 sends a challenge request message to device 2; S56, device 2 sends a response message 2 to device 1, and the response message 2 includes at least: challenge type, public key 4, key type, key number, and challenge field length. The value of the challenge type field in response message 2 is used to instruct device 1 to update the public key corresponding to device 3 saved on it; S57, device 1 deletes public key 2 or sets public key 2 as a prohibited public key, and Corresponding to save the public key 4. In this way, device 3 can update the public key saved on device 1, and revoke and update the public and private keys used for authentication on device 2, so that device 2 can perform more secure and reliable operations on device 1. Authentication.

It can be seen that, through the authentication method provided by the embodiment of this application, the device 1 to be authenticated sends information 2 to the device 2 with authentication function such as an authentication tool; the device 2 performs the authentication on the received information 1 based on the private key 1. Encrypt and send the information 1 encrypted with the private key 1 to the device 1. The device 1 decrypts the information according to the public key 1 to obtain the information 1. By comparing the information 1 and the locally stored information 2, the use authority of the device 1 is determined. In this way, through the encryption and decryption technology and the device 2 dedicated to authenticating the device 1, the device 2 can authenticate the device 1 to be authenticated, which overcomes the current protection of the device through the codebook or the exposed pad of the interface. 1 The hidden safety hazards that exist during security ensure that the protection of the device 1 to be authenticated is safer and more reliable.

In order to introduce the embodiments of this application more clearly and in detail, in the scenario shown in Figure 1 below, it is assumed that the device 12 is the debugging interface 12 of the switch, the CA server 13 and the switch 12 cannot communicate directly, and the CA server 13 and the authentication tool 11 are also Taking the example of not being able to communicate directly, the authentication process in the embodiment of the present application will be described in detail with reference to FIG. 4.

Referring to FIG. 4, the authentication process of the method 200 in this embodiment may include, for example:

S201: The user 14 submits a request message on the CA server 13, and the request message is used to request the CA server 13 to allocate a public and private key to the authentication tool 11.

Among them, in this embodiment, the user 14 may also be a safe production line automation equipment that automatically performs all operations performed by the user 14.

S202: The CA server 13 generates a private key b and a corresponding public key B for the authentication tool 11.

S203: The CA server 13 uses its own private key d to encrypt the private key b and the public key B respectively.

S204, the CA server 13 configures the public key D corresponding to the private key d to the switch through the user 14.

S205: The switch saves the public key D in a local secure storage space.

S206, the CA server 13 configures the public key D, the private key b encrypted by the private key d, and the public key B encrypted by the private key d to the authentication tool 11 through the user 14.

S207: The authentication tool 11 uses the public key D to decrypt the private key b encrypted by the private key d, and obtains and saves the private key b.

S208: The switch sends a challenge request message 1 to the authentication tool 11. The challenge request message 1 carries a random number X1.

S209. The authentication tool 11 uses the locally stored private key b to encrypt the information in the challenge request message 1, and generates a response message 1 including X2 encrypted by the private key b, where X2 is the random number received by the authentication tool 11 .

S210: The authentication tool 11 sends the response message 1 to the switch.

S211: The authentication tool 11 sends the public key B encrypted with the private key d to the switch.

S212: The switch uses the public key D stored locally to decrypt the public key B encrypted with the private key d, and obtains and saves the public key B.

S213: The switch uses the public key B to decrypt the information in the response message 1 to obtain X2, which is obtained by the public key B decrypting X2 encrypted with the private key b.

S214: The switch compares whether X2 and the locally stored random number X1 are consistent, if they are consistent, execute S215, otherwise, execute S216.

S215: The switch opens the use right of the debugging interface 12.

S216: The switch determines to suspend the authentication process, and reports an authentication error to the CA server 13.

In this way, in this embodiment, the authentication tool is implemented through the interaction between the encryption and decryption technology, the CA server 13, a server with a higher security level, and the authentication tool 11 that is specifically used to authenticate the switch, and the switch. 11 The management of the use authority of the debugging interface 12 on the switch realizes more secure protection of the key interface on the switch.

FIG. 5 shows a schematic flowchart of an authentication method 300 in an embodiment of the present application. The method 300 is applied in a scenario that includes a first device and a second device, and the first device is the execution subject. The authentication method 300 For example, it can include:

S301: Receive the first information encrypted by the first private key and sent by the second device.

S302: Decrypt according to the first public key to obtain the first information, where the first public key corresponds to the first private key;

S303: Perform matching verification on the first information and the locally stored second information to obtain a verification result;

S304: Determine the use right of the first device according to the verification result.

The first device can be device 1 in method 100, then the second device is device 2 in method 100, the first private key is private key 1 in method 100, and the first public key is public key in method 100. Key 1, the first information is information 1 in method 100, and the second information is information 2 in method 100. Alternatively, the first device may also be the debugging interface 12 of the switch in the method 200, then the second device is the authentication tool 11 in the method 200, the first private key is the private key b in the method 200, and the first public key For the public key B in the method 200, the first information includes the random number X2 encrypted by the private key b in the method 100, and the second information includes the random number X1 in the method 100.

Specifically, when the verification result indicates that the verification is passed, the first device opens the corresponding use right, and when the verification result indicates that the verification fails, the first device does not open the corresponding use right. In this way, through the encryption and decryption technology and the second device with authentication function, the authentication of the first device to be authenticated is realized, which overcomes the current situation of protecting the security of the first device by means of codebooks or exposed pads corresponding to the interface. The potential safety hazards ensure the safer and more reliable protection of the first device to be authenticated.

In some possible implementation manners, the first private key and the first public key may be generated by the second device; or, the first private key and the first public key may also be configured by the authentication server for the second device.

For more security, the method 300 may further include: the first device receives the first public key encrypted by the second private key of the authentication server sent by the second device; and the first device uses the second public key of the authentication server stored locally. Key to decrypt the encrypted first public key to obtain the first public key. In this way, encrypting the first public key by a server with a higher security level, which is the authentication server, is more secure and reliable than storing the first public key directly on the first device.

As an example, the second information may include the first random number. Before S301 is performed, the method 300 may further include: sending a challenge request message to the second device, where the challenge request message carries the first random number; then, S301 may specifically Including: the first device receives a response message sent by the second device, the response message carries the first information, and the first information includes a second random number; in this case, S303 may specifically include: A random number and the second random number are matched and verified. Among them, the first random number can uniquely identify an authentication to the first device, and the random number is used for authentication to ensure that each authentication can be performed based on the random number generated this time, which can effectively prevent the information of the first device Is copied to prevent replay attacks.

As another example, the second information may further include first device identification information, the first information includes second device identification information, and the first device identification information is used to uniquely identify the first device, then, S303 Specifically, it may further include: performing matching verification on the first device identification information and the second device identification information. As an example, the first device identification information is a first device ID, and the second device identification information is a second device ID. Then, S303 may specifically include: comparing the first device ID and the second device ID Perform matching verification. As another example, the first device identification information is the hash value of the first device ID, and the second device identification information is the hash value of the second device ID. Then, S303 may specifically include: The hash value of one device ID and the hash value of the second device ID are matched and verified. For the security of authentication, the device ID in this embodiment of the application is a non-public ID that can uniquely identify the device, for example: the first device ID is the hardware unique key HUK defined when the first device leaves the factory, another example is: The device ID is obtained by processing the die ID of the first device and the unique device identifier UDI. In this way, the first device ID or the hash value of the first device ID stored locally by the first device is used to verify the second device ID or the hash value of the second device ID obtained after decryption, so as to realize the reliability of the first device And secure authentication.

As another example, the second information may also include target valid information, and the first information includes actual usage information, where the actual usage information is used to characterize that the second device authentication is currently used on the first device. Case. Then, S303 may specifically include: the first device verifies the actual usage information according to the target valid information to determine whether the second device can continue to be used to authenticate the first device. When the first device determines that the actual usage information has not reached the target effective information, it determines that the second device is valid for the first device and can continue to use the second device to authenticate the first device; otherwise, when the first device determines If the actual use information has reached the target effective information, it is determined that the second device is invalid for the first device, and the second device cannot be used to authenticate the first device. Wherein, the target effective information is the maximum number of times allowed to use the second device for authentication (for example: 5 times); or, the target effective information is the maximum time allowed to use the second device for authentication (for example: 20 hour). In this way, the actual use information carried in the first information is verified through the target effective information stored locally in the first device, so that reliable and safe authentication of the first device is realized.

As yet another example, the first information may further include indication information, the indication information being used to indicate at least one of the following information: the time when the use permission is opened, the interface for opening the use permission, or the use Permission operation. Wherein, the indication information may be sent by the first device to the second device in the challenge request message, or it may be corresponding indication information specified by the second device according to its own authentication range; it may also be the first device in the challenge request message. The corresponding indication information sent to the second device in the message and determined by the second device according to its own authentication range. In this way, through the instruction information obtained after the first device receives and decrypts, reliable and safe authentication of the first device is realized.

It should be noted that, for the method 300 in the embodiment of the present application, the specific implementation manner and the achieved effect can be referred to the related description in the embodiment shown in FIG. 3 and FIG. 4.

6 shows a schematic flowchart of a method 400 for authenticating the use right of a first device in an embodiment of the present application. The method 400 is applied in a scenario that includes a first device and a second device. For the execution subject, the method 400 may include, for example:

S401: Encrypt the first information by using a first private key stored locally;

S402: Send the first information encrypted by the first private key to a first device, so as to authenticate the use right of the first device.

The second device can be device 2 in method 100, then the first device is device 1 in method 100, the first private key is private key 1 in method 100, and the first public key is public key in method 100. Key 1, the first information is information 1 in method 100. Alternatively, the second device may be the authentication tool 11 in the method 200. Then, the first device is the debugging interface 12 of the switch in the method 200, the first private key is the private key b in the method 200, and the first public key is In the public key B in the method 200, the first information includes the random number X2 encrypted by the private key b in the method 100.

In this way, through the encryption and decryption technology and the second device with authentication function, the authentication of the first device to be authenticated is realized, which overcomes the current situation of protecting the security of the first device by means of codebooks or exposed pads corresponding to the interface. The potential safety hazards ensure the safer and more reliable protection of the first device to be authenticated.

In some specific implementation manners, the first private key and the first public key may be generated by the second device; or, the first private key and the first public key may also be configured by the authentication server for the second device.

As an example, the method 400 may further include: the second device receiving the second public key of the authentication server sent by the authentication server, the first public key encrypted by the second private key, and the second private key The encrypted first private key, the second private key corresponds to the second public key; then, the second device uses the second public key to encrypt the second private key The first private key is decrypted to obtain the first private key; the second device may also send the first public key encrypted by the second private key to the first device, so that the second device A device decrypts the first public key encrypted by the second private key based on the locally stored second public key to obtain the first public key.

As another example, the first information includes the first random number. Then, before S401, the method 400 may specifically further include: the second device receives a challenge request message sent by the first device, where the challenge request message Carrying the first random number; S402 may specifically include: the second device sends a response message to the first device, where the response message carries the first random number encrypted by the first private key.

As another example, the second information may also include the first information and first device identification information. The first device identification information is used by the first device for identity verification. For example, it may be the first device ID or the first device ID. A hash value of the device ID. The method 400 may further include: the second device performs matching verification on the first device ID and a locally stored second device ID corresponding to the first device; or, the second device performs a matching verification on the first device ID. The Greek value is matched and verified with the locally stored hash value of the second device ID corresponding to the first device. Wherein, the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or the first device ID is processed according to the chip ID die ID of the first device and the unique device ID UDI owned.

As another example, the first information may also include target valid information, which is used by the first device to determine whether the second device can continue to be used for authentication. Then, the method 400 may further include: the second device updates the actual usage information, the actual usage information is used to characterize the current use of the second device authentication on the first device; then, the second device according to The target effective information verifies the updated actual usage information to determine whether the second device can continue to be used to authenticate the first device. Wherein, the target effective information is the maximum number of times that the second device is allowed to perform authentication, then the actual usage information is the actual number of times the first device uses the second device for authentication until the current time; Alternatively, the target valid information is the maximum time allowed to use the second device for authentication, then the actual usage information is the actual usage time from the timing start time of the target valid information to the current moment.

As yet another example, the first information may further include indication information, the indication information being used to indicate at least one of the following information: the time when the use permission is opened, the interface for opening the use permission, or the use Permission operation.

It should be noted that, for the method 400 in the embodiment of the present application, the specific implementation manner and the achieved effect can be referred to the related description in the embodiment shown in FIG. 3, FIG. 4, and FIG. 5.

In addition, this application also provides a first device 700, as shown in FIG. 7. The first device 700 includes a transceiver unit 701 and a processing unit 702. The transceiving unit 701 is configured to perform the transceiving operation performed by the device 1 in the embodiment shown in FIG. 3, or the transceiving operation performed by the debugging interface 12 of the switch in the embodiment shown in FIG. 4, or the method embodiment shown in FIG. Transceiving operations performed by the first device; the processing unit 702 is configured to perform operations other than the transceiving operations performed by the device 1 in the embodiment shown in FIG. 3, or other operations performed by the debugging interface 12 of the switch in the embodiment shown in FIG. 4 Operations other than the transceiving operation, or operations performed by the first device in the method embodiment shown in FIG. 5 other than the transceiving operation. For example: the first device 700 is the device 1 in the method 100, then the transceiving unit 701 is used to receive the information 1 encrypted with the private key 1 sent by the device 2; the processing unit 702 is used to decrypt according to the public key 1 to obtain Information 1, the processing unit 702 is also used to compare the information 1 and the locally stored information 2 to determine the use right of the device 1.

In addition, an embodiment of the present application also provides a second device 800, as shown in FIG. 8. The second device 800 includes a transceiver unit 801 and a processing unit 802. Among them, the transceiving unit 801 is configured to perform the transceiving operation performed by the device 2 in the embodiment shown in FIG. 3, or the transceiving operation performed by the authentication tool 11 in the embodiment shown in FIG. 4, or the method embodiment shown in FIG. Transceiving operations performed by the second device in the second device; the processing unit 802 is configured to perform operations other than the transceiving operations performed by the device 2 in the embodiment shown in FIG. 3, or other operations performed by the authentication tool 11 in the embodiment shown in FIG. 4 Operations other than the transceiving operation, or operations performed by the second device in the method embodiment shown in FIG. 6 other than the transceiving operation. For example: the first device 800 is the device 2 in the method 100, then the transceiver unit 801 is used to send the information 1 encrypted by the private key 1 to the device 1; the processing unit 802 is used to pair the private key 1 according to the locally stored private key. Information 1 is encrypted.

In addition, an embodiment of the present application also provides a first device 900, as shown in FIG. 9. The first device 900 includes a communication interface 901 and a processor 902 connected to the communication interface 901. Among them, the communication interface 901 is used to perform the transceiving operation performed by the device 1 in the embodiment shown in FIG. 3, or the transceiving operation performed by the debugging interface 12 of the switch in the embodiment shown in FIG. 4, or the method shown in FIG. 5 is implemented The transceiving operation performed by the first device in the example; the processor 902 is configured to perform other operations other than the transceiving operation performed by the device 1 in the embodiment shown in FIG. 3, or the debugging interface 12 of the switch in the embodiment shown in FIG. 4 executes Other operations other than the transceiving operation, or other operations performed by the first device in the method embodiment shown in FIG. 5 other than the transceiving operation. For example: the first device 900 is the device 1 in the method 100, then the communication interface 901 is used to receive the information 1 encrypted with the private key 1 sent by the device 2; the processor 902 is used to decrypt according to the public key 1 to obtain Information 1; The processor 902 is also used to compare the information 1 and the locally stored information 2 to determine the use authority of the device 1.

In addition, an embodiment of the present application also provides a second device 1000, as shown in FIG. 10. The second device 1000 includes a communication interface 1001 and a processor 1002 connected to the communication interface 1001. Wherein, the communication interface 1001 is used to perform the transceiving operation performed by the device 2 in the embodiment shown in FIG. 3, or the transceiving operation performed by the authentication tool 11 in the embodiment shown in FIG. 4, or the first method in the method embodiment shown in FIG. 2. Transceiving operations performed by the device; the processor 1002 is configured to perform other operations other than the transceiving operations performed by the device 2 in the embodiment shown in FIG. 3, or the authentication tool 11 in the embodiment shown in FIG. 4 other than transceiving operations Operations other than those performed by the second device in the method embodiment shown in FIG. 6 other than the transceiving operations. For example: the second device 1000 is the device 2 in the method 100, then the communication interface 1001 is used to send the information 1 encrypted by the private key 1 to the device 1; the processor 1002 is used to pair the private key 1 according to the locally stored private key. Information 1 is encrypted.

In addition, an embodiment of the present application also provides a first device 1100, as shown in FIG. 11. The first device 1100 includes a memory 1101 and a processor 1102. The memory 1101 is used to store program code; the processor 1102 is used to run instructions in the program code, so that the first device 1100 executes the method executed by the device 1 in the embodiment shown in FIG. 3, or as shown in FIG. 4 The method executed by the debugging interface 12 of the switch in the embodiment, or the method executed by the first device in the method embodiment shown in FIG. 5.

In addition, an embodiment of the present application also provides a second device 1200, as shown in FIG. 12. The second device 1200 includes a memory 1201 and a processor 1202. The memory 1201 is used to store program code; the processor 1202 is used to run instructions in the program code, so that the second device 1200 executes the method performed by the device 2 in the embodiment shown in FIG. 3, or as shown in FIG. 4 The method executed by the authentication tool 11 in the embodiment, or the method executed by the second device in the method embodiment shown in FIG. 6.

It can be understood that, in the foregoing embodiment, the processor may be a central processing unit (English: central processing unit, abbreviation: CPU), a network processor (English: network processor, abbreviation: NP), or a combination of CPU and NP. The processor may also be an application-specific integrated circuit (English: application-specific integrated circuit, abbreviation: ASIC), a programmable logic device (English: programmable logic device, abbreviation: PLD) or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (English: complex programmable logic device, abbreviation: CPLD), field programmable logic gate array (English: field-programmable gate array, abbreviation: FPGA), general array logic (English: generic array) logic, abbreviation: GAL) or any combination thereof. The processor may refer to one processor or may include multiple processors. The memory may include volatile memory (English: volatile memory), such as random access memory (English: random-access memory, abbreviation: RAM); the memory may also include non-volatile memory (English: non-volatile memory), For example, read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) or solid state drive (English: solid-state drive, Abbreviation: SSD); the memory can also include a combination of the above-mentioned types of memory. The memory may refer to one memory, or may include multiple memories. In a specific embodiment, computer-readable instructions are stored in the memory, and the computer-readable instructions include multiple software modules, such as a sending module, a processing module, and a receiving module. After executing each software module, the processor can perform corresponding operations according to the instructions of each software module. In this embodiment, an operation performed by a software module actually refers to an operation performed by the processor according to an instruction of the software module. After the processor executes the computer-readable instructions in the memory, it can execute all operations that can be executed by the first device or the second device according to the instructions of the computer-readable instructions.

It can be understood that, in the foregoing embodiment, the communication interface 901 of the first device 900 can be specifically used as the transceiver unit 701 in the first device 700 to implement data communication between the first device and the second device. Similarly, the communication interface 1001 of the second device 1000 can be specifically used as the transceiver unit 801 in the second device 800 to implement data communication between the first device and the second device.

In addition, an embodiment of the present application also provides a communication system 1300, as shown in FIG. 13. The communication system 1300 includes a first device 1301 and a second device 1302. The first device 1301 may specifically be the above-mentioned first device 700, the first device 900 or the first device 1100, and the second device 1402 may specifically be the above-mentioned second device. The device 800, the second device 1000, or the second device 1200.

In addition, the embodiments of the present application also provide a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer, causes the computer to execute the implementation shown in Figures 3 to 6 above. The authentication method in the example.

In addition, the embodiment of the present application also provides a computer program product, which when it runs on a computer, causes the computer to execute the authentication method in the aforementioned embodiment shown in FIG. 3 to FIG. 6.

The “first” in the names of “first information”, “first private key” and the like mentioned in the embodiments of the present application is only used for name identification, and does not represent the first in order. This rule also applies to "second" and so on.

From the description of the foregoing implementation manners, it can be understood that those skilled in the art can clearly understand that all or part of the steps in the foregoing embodiment methods can be implemented by means of software and a general hardware platform. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, and the computer software product can be stored in a storage medium, such as read-only memory (English: read-only memory, ROM)/RAM, magnetic disk, An optical disc, etc., includes a number of instructions to enable a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in the various embodiments or some parts of the embodiments of the present application.

The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the system embodiment and the device embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. The above-described device and system embodiments are only illustrative. The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work.

The above descriptions are only the preferred embodiments of the present application, and are not used to limit the protection scope of the present application. It should be pointed out that for those of ordinary skill in the art, without departing from this application, several improvements and modifications can be made, and these improvements and modifications should also be regarded as the scope of protection of this application.

Claims

An authentication method, characterized in that it is implemented by a first device, and includes:

Receiving the first information encrypted by the first private key sent by the second device;

Decrypt according to the first public key to obtain the first information, and the first public key corresponds to the first private key;

Performing matching verification on the first information and the locally stored second information to obtain a verification result;

According to the verification result, the use right of the first device is determined.
The method of claim 1, wherein:

The first private key and the first public key are generated by the second device;

or,

The first private key and the first public key are configured by the authentication server for the second device.
The method according to claim 1 or 2, wherein the method further comprises:

Receiving the first public key encrypted by the second private key of the authentication server sent by the second device;

Use the locally stored second public key of the authentication server to decrypt the encrypted first public key to obtain the first public key.
The method according to any one of claims 1 to 3, wherein the second information comprises a first random number, and before the first information encrypted by the first private key sent by the second device is received, The method also includes:

Sending a challenge request message to the second device, where the challenge request message carries the first random number;

The receiving the first information encrypted by the first private key sent by the second device includes:

Receiving a response message sent by the second device, where the response message carries the first information, and the first information includes a second random number;

The performing matching verification on the first information and the locally stored second information includes:

Perform matching verification on the first random number and the second random number.
The method according to any one of claims 1 to 4, wherein the second information further includes first device identification information, the first information includes second device identification information, and the first device identification The information is used to uniquely identify the first device, and the matching verification of the first information and the locally stored second information further includes:

Perform matching verification on the first device identification information and the second device identification information.
The method of claim 5, wherein:

The first device identification information is a first device identification ID, and the second device identification information is a second device ID; or

The first device identification information is a hash value of the first device ID, and the second device identification information is a hash value of the second device ID.
The method according to claim 6, wherein the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or the first device ID is based on the first device ID. The chip identification die ID and the unique device identification UDI are processed.
The method according to any one of claims 1-7, wherein the second information further includes target effective information, the first information includes actual usage information, and the actual usage information is used to characterize the When the second device authentication is currently used on the first device, the matching verification of the first information and the locally stored second information further includes:

According to the target effective information, the actual usage information is verified to determine whether the second device can continue to be used to authenticate the first device.
The method of claim 8, wherein:

The target effective information is the maximum number of times that the second device is allowed to be used for authentication;

or,

The target effective information is the longest time allowed to use the second device for authentication.
The method according to any one of claims 1-9, wherein the first information further comprises indication information, and the indication information is used to indicate at least one of the following information: the time when the usage authority is released , Opening the interface of the use authority or the operation of opening the use authority.
The method according to any one of claims 1-10, wherein the first device is a debugging interface.
A method for authenticating the use right of a first device, characterized in that it is implemented by a second device, and includes:

Encrypt the first information by using the first private key stored locally;

Sending the first information encrypted by the first private key to the first device to authenticate the use right of the first device.
The method according to claim 12, wherein the method further comprises:

Receiving the second public key of the authentication server, the first public key encrypted by the second private key, and the first private key encrypted by the second private key, the second private key The key corresponds to the second public key;

Decrypt the first private key encrypted by the second private key by using the second public key to obtain the first private key;

Sending the first public key encrypted by the second private key to the first device.
The method according to claim 12 or 13, wherein the first information comprises a first random number, and before encrypting the first information, the method further comprises:

Receiving a challenge request message sent by the first device, where the challenge request message carries the first random number;

The sending the first information encrypted by the first private key to the first device includes:

Send a response message to the first device, where the response message carries the first random number encrypted by the first private key.
The method according to any one of claims 12-14, characterized in that,

The first information includes first device identification information, and the first device identification information is used for identity verification by the first device.
The method according to claim 15, wherein the first device identification information is a first device identification ID or a hash value of the first device ID.
The method according to claim 16, wherein the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or the first device ID is based on the first device ID. The chip identification die ID and the unique device identification UDI are processed.
The method according to any one of claims 12-17, wherein the first information further comprises target valid information, and the target valid information is used by the first device to determine whether the first device can continue to use the Second, the device performs authentication.
The method of claim 18, wherein:

The target effective information is the maximum number of times that the second device is allowed to be used for authentication;

or,

The target effective information is the longest time allowed to use the second device for authentication.
The method according to any one of claims 12-19, wherein the first information further comprises indication information, and the indication information is used to indicate at least one of the following information: the time when the usage authority is released , Opening the interface of the usage authority or the operation of opening the usage authority.
The method according to any one of claims 1-20, wherein the first device is a debugging interface.
A first device, characterized in that it comprises:

Communication interface; and

A processor connected to the communication interface;

According to the communication interface and the processor, the first device is configured to execute the method according to any one of the preceding claims 1-11.
A second device, characterized in that it comprises:

Communication interface; and

A processor connected to the communication interface;

According to the communication interface and the processor, the second device is used to execute the method of any one of the preceding claims 12-21.
A first device, characterized in that the first device includes a memory and a processor;

The memory is used to store program code;

The processor is configured to run instructions in the program code, so that the first device executes the method according to any one of claims 1-11.
A second device, characterized in that, the second device includes a memory and a processor;

The memory is used to store program code;

The processor is configured to run instructions in the program code, so that the second device executes the method according to any one of claims 12-21.
A computer-readable storage medium, characterized in that instructions are stored in the computer-readable storage medium, which when run on a computer, cause the computer to execute any of the above claims 1-11 or claims 12-21. The method described in one item.
A communication system, characterized by comprising the first device according to claim 22 or 24 and the second device according to claim 23 or 25.