CN113055340A

CN113055340A - Authentication method and device

Info

Publication number: CN113055340A
Application number: CN201911368436.5A
Authority: CN
Inventors: 唐甜; 乔立忠; 张梦楠; 曹斌
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-12-26
Filing date: 2019-12-26
Publication date: 2021-06-29
Anticipated expiration: 2039-12-26
Also published as: WO2021128989A1; CN113055340B

Abstract

The embodiment of the application discloses an authentication method and equipment.A first information encrypted by a first private key is sent to a first device to be authenticated by an authentication tool (namely, a second device), and the first device can decrypt according to a first public key to obtain the first information, wherein the first public key corresponds to the first private key; then, the first device can perform matching verification on the first information and the second information stored locally to obtain a verification result, and determine the usage right of the first device according to the verification result. Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the authentication equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed and the like at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

Description

Authentication method and device

Technical Field

The present application relates to the field of secure communication technologies, and in particular, to an authentication method and device, where the method may be used for authenticating a device or an interface on the device when there is a need to open a usage right of the device or the interface on the device.

Background

There is a lot of information stored on the device, some of which is very important for the manufacturer or user of the device. At present, devices are usually authenticated by means of a codebook to ensure the security of the devices and the information thereon. Specifically, a plurality of passwords are stored in a password book, one or more passwords are preset on the equipment, when the requirement for opening the use permission of the equipment exists, designated personnel (such as debugging personnel, operation and maintenance personnel, production personnel and the like) input the passwords in the password book into the equipment and match the passwords with the preset passwords in the equipment, when the matching is successful, the equipment is regarded as passing the authentication, and the use permission corresponding to the successfully matched passwords in the equipment is opened, so that the corresponding important information can be accessed through the opened use permission in the equipment.

However, since the storage, transmission and matching of the codebook are all plain texts, and the passwords in the codebook are very easy to leak due to manual management of the codebook, the device is authenticated by adopting the codebook, and the security is low. Therefore, an authentication mode with higher security level is urgently needed to be provided, the open use authority of the equipment under the secure condition is ensured, and the security of the information on the equipment is ensured.

Disclosure of Invention

Based on this, the embodiment of the application provides an authentication method and device, which implement safer authentication of a device to be authenticated by encrypting information sent by the device to be authenticated through an authentication tool and decrypting the information by the device to be authenticated.

In a first aspect, an authentication method is provided, which is applied in a scenario including a first device and a second device, and takes the first device as an execution subject, and the authentication method may include: after receiving first information which is sent by second equipment and encrypted by a first private key, the first equipment decrypts the first information according to a first public key to obtain the first information, wherein the first public key corresponds to the first private key; then, the first device can perform matching verification on the first information and the second information stored locally to obtain a verification result, and determine the usage right of the first device according to the verification result. Specifically, when the verification result indicates that the verification passes, the first device opens the corresponding usage right, and when the verification result indicates that the verification fails, the first device does not open the corresponding usage right. Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the second equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

Wherein the first device may be any device to be authenticated, for example: may refer to a network device or a board, for example: but also to a debug interface or a service interface on the device. The second device may refer to an authentication tool having an authentication function. When the first device is a debugging interface, the authentication tool issues the first information encrypted by the first private key to the device where the debugging interface is located and decrypts the first information by the first public key, and after the first information passes verification, the device where the debugging interface is located opens the use permission of the debugging interface for accessing and using the debugging interface.

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

For higher safety, the embodiment of the present application may further include: the first equipment receives a first public key which is sent by the second equipment and encrypted by a second private key of the authentication server; and the first equipment decrypts the encrypted first public key by using the locally stored second public key of the authentication server to obtain the first public key. Therefore, the first public key is encrypted by the authentication server which is a server with higher security level, and the first public key is safer and more reliable than the first public key which is directly stored on the first device.

Optionally, the second information includes a first random number, and before the receiving the first information encrypted by using the first private key and sent by the second device, the embodiment of the present application may further include: the method comprises the steps that a first device sends a challenge request message to a second device, wherein the challenge request message carries a first random number; then, the first device receives the first information encrypted by the first private key sent by the second device, and includes: the first device receives a response message sent by the second device, wherein the response message carries the first information, and the first information comprises a second random number; at this time, the matching verification of the first information and the locally stored second information by the first device includes: and performing matching verification on the first random number and the second random number. The first random number can uniquely identify the first authentication of the first device, and the random number is used for authentication, so that each authentication can be performed based on the random number generated at this time, the information of the first device can be effectively prevented from being copied, and replay attack is prevented.

Optionally, the second information may further include first device identification information, where the first information includes the second device identification information, where the first device identification information is used to uniquely identify the first device, and then the first device performs matching verification on the first information and the locally stored second information, which may further include: and performing matching verification on the first equipment identification information and the second equipment identification information. As an example, if 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 performs matching verification on the first information and second information stored locally, which may further include: and performing matching verification on the first device ID and the second device ID. As another example, for security, if the first device identification information is a hash value of a first device ID and the second device identification information is a hash value of a second device ID, then the first device performs matching verification on the first information and the locally stored second information, which may further include: and 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 the security of authentication, the device ID in this embodiment of the application is an unpublished ID capable of uniquely identifying the device, for example: the first device ID is a Hardware Unique Key (HUK) defined when the first device leaves the factory, for example: the first Device ID is obtained by processing according to a wafer identifier (die ID) and a Unique Device Identifier (UDI) of the first Device. Therefore, the second device identification information such as the second device ID or the hash value of the second device ID obtained after decryption is verified through the first device identification information such as the first device ID locally stored by the first device or the hash value of the first device ID, so as to guide the first device to manage the use authority of the first device, and realize reliable and safe authentication of the first device.

Optionally, the second information may further include target valid information, where the first information includes actual usage information, and the actual usage information is used to characterize a case that the first device currently uses the second device for authentication. Then, the first device performs matching verification on the first information and the locally stored second information, and may further include: and the first equipment verifies the actual use information according to the target valid information so as to determine whether the second equipment can be continuously used for authenticating the first equipment. When the first device determines that the actual use information does not reach the target valid information, the second device is determined to be valid for the first device, and the second device can be continuously used for authenticating the first device; otherwise, when the first device determines that the actual usage information has reached the target valid information, it determines that the second device has failed for the first device, and cannot continue to use the second device to authenticate the first device. The target valid information is the maximum number of times (for example, 5 times) that the authentication is allowed to be performed by using the second device; alternatively, the target valid information is the maximum time allowed for authentication using the second device (e.g., 20 hours). Therefore, the actual use information carried in the first information is verified through the target effective information locally stored by the first equipment, the first equipment is guided to manage the use authority of the first equipment, and the first equipment is authenticated reliably and safely.

Optionally, the first information may further include indication information, where the indication information is used to indicate at least one of the following information: time for opening the usage right, interface for opening the usage right, or operation for opening the usage right. The indication information may be sent by the first device to the second device in the challenge request message, or may be corresponding indication information specified by the second device according to the authentication range of the second device; the first device may also send the challenge request message to the second device, and the second device determines the corresponding indication information according to its own authentication range. Therefore, the first device is guided to manage the specific use authority through the indication information obtained after the first device receives and decrypts the indication information, and reliable and safe authentication of the first device is achieved.

In a second aspect, an embodiment of the present application further provides a method for authenticating a usage right of a first device, where the method is applied in a scenario including the first device and a second device, and the second device is used as an execution subject, and the authentication method may include: the second equipment encrypts the first information by adopting a locally stored first private key and sends the first information encrypted by the first private key to the first equipment so as to authenticate the use authority of the first equipment. Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the second equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

Wherein, the second device may refer to an authentication tool having an authentication function. The first device may be any device to be authenticated, for example: may refer to a network device or a board, for example: but also to a debug interface or a service interface on the device. When the first device is a debugging interface, the authentication tool issues the first information encrypted by the first private key to the device where the debugging interface is located and decrypts the first information by the first public key, and after the first information passes verification, the device where the debugging interface is located opens the use permission of the debugging interface for accessing and using the debugging interface.

Optionally, the embodiment of the present application may further include: the method comprises the steps that a second device receives a second public key of an authentication server, a first public key encrypted by a second private key and a first private key encrypted by the second private key, wherein the second public key corresponds to the second public key; then, the second device decrypts the first private key encrypted by the second private key by using the second public key 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 second public key stored locally to obtain the first public key.

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

Optionally, the first information may include first device identification information, which is used by the first device for authentication. The first device identification information is the first device identification ID or a 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: and the second equipment performs matching verification on the first equipment ID and a second equipment ID which is locally stored and corresponds to the first equipment. As another example, the first information may further include a hash value of the first device ID, and then, this embodiment of the present application may further include: and matching and verifying the hash value of the first device ID and a locally stored hash value of a second device ID corresponding to the first device. The first device ID is a hardware unique key HUK defined when the first device leaves a factory, or the first device ID is obtained by processing according to a wafer identifier die ID and a unique device identifier UDI of the first device.

Optionally, the first information further includes target valid information, where the target valid information is used by the first device to determine whether the second device can be used for authentication, and then, this embodiment of the present application may further include: the second device updates the actual use information, and the actual use information is used for representing the condition of currently using the second device for authentication on the first device; and then, the second equipment verifies the updated actual use information according to the target valid information so as to determine whether the second equipment can be continuously used for authenticating the first equipment. If the target valid information is the maximum number of times of authentication allowed by using the second device, the actual use information is the actual use number of times of authentication performed by the first device by using the second device at present; or, the target valid information is the longest time allowed to use the second device for authentication, and the actual usage information is the actual usage time from the starting time of the timing of the target valid information to the current time.

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

For various possible implementation manners and achieved technical effects of the method provided by the second aspect, reference may be made to the description of the method provided by the first aspect, and details are not described herein again.

In a third aspect, the present application further provides a first device, including a transceiver unit and a processing unit. Wherein, the transceiver unit is configured to perform transceiving operation in the method provided by the first aspect; the processing unit is configured to perform other operations than the transceiving operation in the first aspect. For example: when the first device executes the method of the first aspect, the transceiver unit is configured to receive first information encrypted with a first private key and sent by a second device; the processing unit is used for decrypting according to the first public key to obtain the first information, the processing unit is also used for performing matching verification on the first information and the locally stored second information to obtain a verification result, and the processing unit is also used for determining the use permission of the first equipment according to the verification result.

In a fourth aspect, an embodiment of the present application further provides a second device, where the second device includes a transceiver unit and a processing unit. Wherein, the transceiver unit is used for executing the transceiving operation in the method provided by the second aspect; the processing unit is configured to perform other operations than the transceiving operation in the second aspect described above. For example: when the second device executes the method of 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 is used for encrypting the first information by adopting a first private key stored locally.

In a fifth aspect, an embodiment of the present application further provides a first device, which includes a communication interface and a processor. Wherein, the communication interface is used for executing the transceiving operation in the method provided by the first aspect; a processor configured to perform the operations of the method provided by the first aspect, except the transceiving operation.

In a sixth aspect, an embodiment of the present application further provides a second device, which includes a communication interface and a processor. Wherein, the communication interface is used for executing the transceiving operation in the method provided by the second aspect; a processor configured to perform other operations than the transceiving operation in the method provided by the foregoing second aspect.

In a seventh aspect, an embodiment of the present application further provides a first device, where the first device includes a memory and a processor. Wherein the memory is used for storing program codes; the processor is configured to execute the instructions in the program code to cause the first device to perform the method provided in the first aspect above.

In an eighth aspect, an embodiment of the present application further provides a second device, where the second device includes a memory and a processor. Wherein the memory is used for storing program codes; the processor is configured to execute the instructions in the program code, so that the first device performs the method provided by the second aspect above.

In a ninth aspect, embodiments of the present application further provide a computer-readable storage medium, which stores instructions that, when executed on a computer, cause the computer to perform the authentication method provided in the above first aspect or second aspect.

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

In an eleventh aspect, the present application further provides a communication system, where the communication system includes the first device provided in the third aspect, the fifth aspect, or the seventh aspect, and the second device provided in the fourth aspect, the sixth aspect, or the eighth aspect.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.

Fig. 1 is a schematic diagram of a network system framework involved in an application scenario in an embodiment of the present application;

fig. 2 is a schematic flowchart illustrating authentication of device 12 in the scenario of fig. 1 according to an embodiment of the present application;

fig. 3 is a schematic flowchart of an authentication method 100 according to an embodiment of the present application;

fig. 4 is a flowchart illustrating an authentication method 200 in the scenario of fig. 1 according to an embodiment of the present application;

fig. 5 is a flowchart illustrating an authentication method 300 according to an embodiment of the present application;

fig. 6 is a flowchart illustrating a method 400 for authenticating the usage right of the first device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a first apparatus 700 according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a second apparatus 800 according to an embodiment of the present disclosure;

fig. 9 is a schematic structural diagram of a first apparatus 900 according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a second apparatus 1000 according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of a first device 1100 according to an embodiment of the present disclosure;

fig. 12 is a schematic structural diagram of a second apparatus 1200 according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a communication system 1300 according to an embodiment of the present application.

Detailed Description

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

At present, a device is generally authenticated by adopting a password book mode, one or more passwords are preset on the device, a plurality of passwords are stored in the password book, when the use right of the device needs to be opened, appointed personnel such as debugging personnel, operation and maintenance personnel, production personnel and the like input the passwords in the password book into the device, the device matches the input passwords with the preset passwords, when the matching is successful, the authentication of the device is regarded as passed, the device opens the use right corresponding to the successfully matched passwords, and therefore corresponding important information can be accessed through the opened use right. Although the codebook is mastered by a small number of appointed personnel, the safety of important information stored in the equipment can be ensured to a certain extent, the storage, transmission and matching of the codebook are all plain texts, the appointed personnel with the authority of the codebook are complicated, the manual management of the codebook is very easy to reveal the passwords in the codebook, and the mode of authenticating the equipment by adopting the codebook is low in safety.

In addition, since accessing important information on the device is usually implemented through a critical interface (e.g., a debug interface or a service interface) on the device, many device manufacturers remove connectors of the critical interface (i.e., a pad corresponding to the critical interface is exposed) when the device leaves a factory, so as to ensure the security of the important information on the device. However, an attacker can identify the bonding pads corresponding to the key interfaces through observation and instruments such as a multimeter and the like, and access the key interfaces to the analyzer through jumper wires, so that the key information can be directly acquired, and the method is very unsafe. For example: the hardware data of microsoft notebook usually adopts two-stage Key for Encryption protection, that is, Full Volume Encryption Key (FVEK for short) is used for Encryption, and Volume Master Key (VMK for short) is used for Encryption of FVEK; the VMK is stored in a Trusted Platform Module (TPM for short). When Microsoft produces the notebook computer, an LPC (English: Low Pin Count) interface of the TPM is added to test the performance of the notebook computer, but when the Microsoft delivers goods, the interface is exposed from a bonding pad corresponding to a connector, so an attacker can easily identify the exposed LPC interface of the TPM, and the interface is accessed to a logic analyzer through a jumper wire to directly obtain the VMK, so that the FVEK encrypted by the VMK is cracked, the hard disk data encrypted by the FVEK is cracked, and the safety of the notebook computer is seriously endangered.

Therefore, the security of the device and the security of important information on the device cannot be well ensured by the protection mode of the password book or the mode of removing the connector of the key interface of the device when the device leaves a factory.

Based on this, the embodiment of the present application provides an authentication method, where when a user needs to access a first device, the first device needs to perform authentication, and a corresponding usage right on the first device may be opened only after the authentication is passed, so that the user can safely access or use the first device within an opened usage right range. The first device to be authenticated locally stores the second information and the first public key, and the authentication process may specifically include: sending second information to a second device with an authentication function, such as an authentication tool, by a first device to be authenticated; for a second device, receiving first information (the first information may be the same as or different from second information) sent by a first device, encrypting the received first information based on a first private key, and sending the first information encrypted by the first private key to the first device; the first device decrypts according to the first public key to obtain first information, performs matching verification on the first information and second information stored locally to obtain a verification result, and determines the use permission of the first device according to the verification result. Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the second equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

For example, one of the scenarios in the embodiment of the present application may be applied to a network as shown in fig. 1. Referring to fig. 1, the network includes: an authentication tool 11 and a device 12. The authentication tool 11 may be a physical entity designed by the manufacturer of the device 12 and used for authenticating the device 12 shipped from the factory, and the authentication tool 11 locally stores a private key a and has a function of encrypting information by using the private key a. The device 12 may be any device that requires authentication, such as: the device 12 may be a network device such as a router and a switch, a terminal device such as a mobile phone and a notebook computer, a mobile storage device such as a usb disk, a debugging interface, a service interface, or a single board. The scenario shown in fig. 1 may further include a Certificate Authority (CA) server 13, configured to allocate a public key and a private key to an authentication tool, so as to improve the security level of the authentication scenario.

In specific implementation, the authentication tool 11 stores a private key a in the local secure storage area, and the device 12 stores a public key a in the local secure storage area, where the private key a corresponds to the public key a. When access to the device 12 is required, the authentication process for the device 12, see fig. 2, may include: s11, device 12 generates a random number of 1; s12, the device 12 sends the challenge request message carrying the random number 1 to the authentication tool 11; s13, the authentication tool 11 encrypts the received random number 2 (which may be the same as the random number 1 or not) with the private key a to obtain X; s14, the authentication tool 11 carries X in the response message, and sends it to the device 12; s15, the device 12 decrypts X by using the public key a to obtain the random number 2; s16, the device 12 compares the random number 1 with the random number 2, and if the two are the same, it indicates that the authentication of the device 12 passes, otherwise, it indicates that the authentication of the device 12 fails. In this way, a more secure protection of the device 12 to be authenticated is achieved.

It should be noted that the public key a and the private key a may be generated by the authentication tool 11 itself, or may be distributed by the CA server 13 for the authentication tool 11, and may be determined specifically according to the security requirement of the device 12, which is not specifically limited in this embodiment of the application. The CA server 13 may be an off-line server with respect to the authentication tool 11 and the device 12, and requires a user (e.g., a manager of the device 12) to configure the authentication tool 11 and the device 12 via a secure production environment device; alternatively, the CA server 13 may be an online server with respect to the authentication tool 11 and the device 12, and may interact directly through 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 without being relayed by the user.

It should be noted that, in the embodiment of the present application, the local secure storage area of the device refers to a storage area that cannot be easily accessed and tampered in the local storage area of the device. For example: the secure storage area may be a One-Time Programmable (OTP) memory of the device, for example: the secure storage area may also be an electrical FUSE (eFUSE) of the device, and since the contents stored in the secure storage area, such as OTP or eFUSE, are not changeable, the secure storage area local to the device may reliably and securely store important information, such as: the secure storage area local to the authentication tool 11 may securely and securely hold the private key a and the secure storage area local to the device 12 may securely and securely hold the public key a.

It is to be understood that the above scenario is only one example of a scenario provided in the embodiment of the present application, and the embodiment of the present application is not limited to this scenario.

The following describes in detail a specific implementation manner of the authentication method in the embodiment of the present application by way of embodiments with reference to the accompanying drawings.

Fig. 3 is a flowchart illustrating an authentication method 100 according to an embodiment of the present application. Referring to fig. 3, the method 100 is applied to a network including a device 1 and a device 2, wherein the device 1 holds a public key 1 in advance. The method 100 may be performed to authenticate the device 1 when access to the device 1 is required. For example: the method 100 may be applied in the network shown in fig. 1, where the device 1 may be the device 12 and the device 2 may be the authentication tool 11. The method 100 may include, for example, the following S101 to S106:

s101, the device 2 receives the information 1 sent by the device 1.

The device 2 is a physical entity, also called an authentication tool, for authenticating the device 1 to be authenticated, and determining whether to open the usage right of the device to be authenticated. The device 2 may include an authentication interface for establishing a connection with the device 1 to be authenticated, which may be a wired interface, for example: a Universal Serial Bus (USB) interface or a Joint Test Action Group (JTAG) interface; alternatively, the authentication interface may also be a wireless interface, such as: bluetooth.

The device 1 refers to a device to be authenticated, and in this embodiment of the present application, the device to be authenticated may be a network device, for example: switches, routers, and also end devices, for example: mobile phones, notebook computers, and also mobile storage devices, such as: the U disk can also be an interface, for example: the debugging interface and the service interface can also be single boards.

The information 1 may include: the random number 2 received by the device 2. When the device 1 needs to authenticate, it can generate the random number 1 corresponding to the authentication, and store the random number 2 in the local secure storage area of the device 1. The random number 1 can uniquely identify one-time authentication of the equipment 1, and the random number is used for authentication, so that each-time authentication can be carried out based on the random number generated at this time, the information of the equipment 1 can be effectively prevented from being copied, and replay attack is prevented.

In specific implementation, before S101, the device 1 may send a challenge request message to the device 2, where the challenge request message carries the random number 1; then, S102 may specifically be: the device 2 receives the challenge request message and obtains the random number 2 from it, it being understood that if the challenge request message is transmitted without error, the random number 2 and the random number 1 are identical, otherwise, the random number 2 may not be identical to the random number 1.

Further, the information 1 may further include: the device identification information 2 received by the device 2 and corresponding to the device 1 may be used to uniquely identify the device 1. Specifically, the device Identification information 2 may be a hash value of device Identification (ID) 2 or device ID 2. The device 1 stores a hash value of the device ID1 or the device ID1 of the device 1, the device ID1 may be an identifier capable of uniquely identifying the device 1, and the hash value of the device ID1 is a hash value obtained by hashing the device ID 1. For added security, the device ID1 may be a non-public identification of the device 1. For example: the device ID1 may be a Hardware Unique Key (HUK) defined when the device 1 leaves the factory; another example is: the Device ID1 may also be an identifier obtained from a Unique Device Identification (UDI) of the Device 1 and a wafer Identification (die ID) in the Device 1. It can be seen that, by using the hash value of the device ID1 or the device ID1 to authenticate, the authentication authority of the device 2 can be effectively controlled, that is, after an attacker or a user obtains the public key, the attacker or the user can only attack or use the device 1, and cannot authenticate another device and develop a corresponding use authority by using the public key, so that the security risk is minimized, and the security protection of the device is improved.

Furthermore, the information 1 may also include target valid information which is used by the device 1 to determine whether the device 2 can be used for authentication. The target valid information may specifically be the maximum number of times (for example, 5 times) that the device 2 is allowed to be used for authentication, or the maximum time (for example, 1 day) that the device 2 is allowed to be used for authentication, so as to limit the number of times or duration of valid use of the device 2 with reference to the target valid information, so as to control the device 2 to be used within a safe range.

If the device 1 needs to configure the authentication range by itself, the information 1 may further include indication information, where the indication information is used to indicate at least one of the following information: the time of opening the use permission (for example, the time of opening the use permission can be accessed within 2 hours), the interface of opening the use permission (for example, 3 debugging interfaces on the open device 1, or the debugging interface 1 and the debugging interface 2 on the open device 1) or the operation of opening the use permission (for example, the read operation is allowed on the device 1, or the write operation is allowed on the device 1). It should be noted that, according to the authentication requirement, the device 1 may also not specify the authentication range, that is, the device 2 configures the authentication range without including the indication information in the information 1, or none of the devices is configured, and the usage right of the device 1 is opened following the set default authentication range after one authentication is passed.

Before the device 2 is used 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 the authentication interface.

In specific implementation, when the device 1 has an access requirement and needs to authenticate the device 1, the device 1 may send a challenge request message to the device 2, where the challenge request message received by the device 2 carries the information 1.

As an example, the challenge request message may include only the content of the challenge request message itself, such as: the challenge request message includes: challenge type, key number, and challenge field length, then information 1 only includes: challenge type, key number, and challenge field length. Wherein the challenge type is predefined by the device 1 and the device 2 for indicating that the challenge request message is active, for example: when the value of the challenge type field is 0x5AAA555A, it indicates that the challenge request message is used to indicate authentication of device 1. The key classification is used to indicate the type of key pair currently used, for example: when the value of the key classification field is 0x07, it indicates that the authentication key pair is currently used, again for example: when the key classification field has a value of 0x09, it indicates that the remote attestation key pair is currently in use. The key number is used to indicate the specific key pair currently used, i.e. to indicate the key pair corresponding to the locally stored public key 1, for example: the authentication key pair may include 16 key pairs, which are respectively allocated to different products or different interfaces for use, so as to prevent one key pair from being leaked, and allow another key pair to be used without too large influence. The length of the challenge field can be used for signal verification, and the problems that the transmission information of the challenge request message is lost in the transmission process and the like are prevented.

As another example, in order to increase the security level of the authentication of the device 1, a field may be further added to the challenge request message for carrying at least one of the hash values of the random number 1, the device ID1 and the device ID1, and then, the information 1 includes not only the content of the challenge request message itself, but also: at least one of hash values of random number 2, device ID2, and device ID 2. If no error occurs during the process of sending the challenge request message to the device 2 by the device 1 and receiving the challenge request message by the device 2, the random number 2 is consistent with the random number 1, the device ID2 is consistent with the device ID1, and the hash value of the device ID2 is consistent with the hash value of the device ID 1.

As another example, according to the authentication requirement of the device 1, another field may be added in the challenge request message to carry indication information or target valid information, and then, the information 1 includes not only the content of the challenge request message itself but also the indication information or the target valid information; or, on this basis, the information 1 may further include: at least one of hash values of random number 2, device ID2, and device ID 2.

In this way, device 1 instructs device 2 to authenticate device 1 by sending a challenge request message to device 2. After receiving the challenge request message, the device 2 obtains the information 1 by analyzing the challenge request message, and provides a data basis for authentication of the device 1.

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

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

In some possible implementations, device 2 may authenticate device 1 with a self-generated public and private key, and then private key 1 may be generated by device 2 based on an internal algorithm and stored locally. In this example, the device 2 needs to send the public key 1 corresponding to the private key 1 to the device 1 before executing S105 described below, so that the device 1 stores the public key 1 in the local secure storage space.

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

In other possible implementations, to increase the security level, the device 2 may also apply a public-private key pair from the device 3 for authenticating the device 1, and then the private key 1 may be the private key assigned by the device 3 to the device 2. The device 3 may be, for example, an authentication server with a high security level, such as a CA server.

Whether the public key 1 and the private key 1 are generated by the device 2 itself or distributed by the device 3, the encrypted private key 2 on the device 3 can be used for sending the encrypted private key to the device 2, so that the security is improved. In specific implementation, the process of sending, by the device 3, the public and private key pair to the device 2 may include, for example: s21, device 2 sends request message to device 3, to request device 3 to send public and private key pair for authenticating device 1; s22, the device 3 determines the private key 1 and the corresponding public key 1 to be sent to the device 2 in response to the request message, and in order to further improve the security, the device 3 encrypts the private key 1 and the public key 1 by using its own private key 2; s23, the device 2 receives the public key 2 corresponding to the private key 2 sent by the device 3; s24, the device 2 receives the private key 1 encrypted by the private key 2 and the public key 1 encrypted by the private key 2 sent by the device 3; s25, the device 2 decrypts the private key 1 encrypted by the private key 2 by using the public key 2, obtains the private key 1, and stores 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 when performing subsequent authentication, the device 2 sends the public key 1 encrypted by the private key 2 to the device 1, and the device 1 decrypts the public key 1 encrypted by the private key 2 by using the locally stored public key 2, and locally stores the public key 1 obtained after decryption, thereby providing a data base for authentication.

It should be noted that the manner in which the device 3 issues the public key 2 to the device 1, and the manners in which the device 3 in S23 and S24 can 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 can both be determined according to whether the device 3 is an offline server or an online server. When the device 3 is in an offline state with respect to the device 1, the user may copy the public key 2 from the device 3 through the secure production environment device and configure the public key 2 on the device 1 through the secure production environment device; when device 3 is online with respect to device 1, device 3 may send public key 2 directly to device 1 over the connection established between the two. Similarly, when the device 3 is in an offline state relative to the device 2, the request message may be submitted on the device 3 by the user, and after the user copies 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 from the device 3 through the secure production environment device, the user configures 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 onto the device 2 through the secure production environment device; when device 3 is online with respect to device 2, device 3 may send public key 2, private key 1 encrypted by private key 2, and public key 1 encrypted by private key 2 to device 2 directly over the connection established between the two.

For S23 and S24, as an example, device 3 may carry public key 2, private key 1 encrypted by private key 2, and public key 1 encrypted by private key 2 in a message, which is fed back to device 2. As another example, for greater security, the device 3 may carry the public key 2 in one message, and 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, which are fed back to the device 2 respectively.

For S102, if the information 1 includes the device identification information 2, the device 2 may locally store a device identification information list of the device 2, where the device is responsible for authentication, and all devices identified in the list may be used as objects for authentication of the device 2. After receiving the information 1, the device 2 may first perform matching verification on the device identification information 2 and a locally stored device identification information list, if matching, execute S102, otherwise, determine that the device 1 is not the object of authentication of the device 2, and terminate the authentication.

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

For S102, if the information 1 includes the target valid information, the device 2 may locally store actual valid information, where the actual valid information is used to represent a current situation where the device 2 is used to authenticate the device 1. After receiving the information 1, the device 2 may update the actual usage information, and then perform matching verification on the target valid information and the updated actual usage information, if matching (that is, the actual usage information of the device 2 does not reach the target valid 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 actual valid information of the device 2 may be reset by the manufacturer of the device 1 to restore the authentication function of the device 2 to the device 1.

As an example, when the target valid information is the maximum number of times (for example, 5 times) that the device 2 is allowed to be used for authentication, the actual use information is the actual use number (for example, 3 times) that the device 1 is authenticated by the currently used device 2, when the device 2 receives the information 1 again, the actual use number may be incremented by one, and whether the new actual use number is less than or equal to the target valid information is determined, if yes, S102 is executed, otherwise, the authentication of the device 1 by using the device 2 is stopped, and the device 2 is prompted to fail.

As another example, when the target valid information is the maximum time (e.g., 24 hours) for allowing the device 2 to be used for authentication, the actual usage information is the actual usage time (e.g., 10 hours) from the starting time of the counting of the target valid information to the current time, when the device 2 receives the information 1 again, the updated actual usage time may be the time (e.g., 12 hours) elapsed from the starting time of the counting of the target valid information to the current time, and whether the new actual usage time reaches the target valid information is determined, if not, S102 is executed, if yes, the authentication of the device 1 by the device 2 is stopped, and the device 2 is prompted to fail.

It should be noted that, when the information 1 includes the target valid information, S102 may encrypt the information 1 including the target valid information and send the encrypted information to the device 1; or, S102 may also eliminate the target valid information in the information 1, encrypt the remaining information 1, and send the encrypted information to the device 1, that is, the information 1 does not include the target valid information encrypted by the public key 1. Or, the information 1 may also carry the updated actual usage information in the information 1, and send the information to the device 1, so that the device 1 reconfirms whether the device 2 is valid based on the actual usage information and the locally stored target valid information.

For S102, if the information 1 includes the indication information, the device 2 may encrypt the information 1 including the indication information and send the encrypted information to the device 1; or, if the information 1 includes the indication information, the device 2 may locally store an authentication range of the device 2, which is responsible for authenticating the device 1, and then, after receiving the information 1, the device 2 may first perform matching verification on the indication information and the locally stored authentication range of the device 1, and encrypt the indication information corresponding to the matched authentication range based on the private key 1 and then send the encrypted indication information as a part of the information 1 to the device 1; or, if the information 1 does not include the indication information, but the device 2 locally stores the authentication range of the device 2 responsible for authenticating the device 1, after receiving the information 1, the device 2 may encrypt the indication information corresponding to the locally stored authentication range based on the private key 1 and then send the encrypted indication information to the device 1 as a part of the information 1; or, if the information 1 does not include the indication information and the device 2 does not locally store the authentication range for authenticating the device 1, S102 may be directly executed, the information 1 does not include the indication information, and the device 1 may open the usage right of the device 1 according to the default setting thereon.

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

And S104, the device 1 receives the information 1 which is sent by the device 2 and encrypted by the private key 1.

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

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

As another example, for better security, the device 2 may also separately send the public key 1 encrypted by the private key 2 to the device 1, and send the information 1 to the device 1 in a response message. 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 of private key 1 encryption, device ID2 of private key 1 encryption, the key type of private key 1 encryption, the key number of private key 1 encryption, and the challenge field length of private key 1 encryption. And 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, the information 1 encrypted by the private key 1 in the response message may specifically include: the challenge type encrypted by private key 1, the key number encrypted by private key 1, and the challenge field length encrypted by private key 1.

If the information 1 includes the content of the challenge request message itself and the random number 2, 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 2 encrypted by the private key 1, the key type encrypted by the private key 1, the key number encrypted by the private key 1, and the challenge field length encrypted by the private key 1.

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

If the information 1 includes the content of the challenge request message and the indication information, 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 indication information encrypted by the private key 1, the key type encrypted by the private key 1, the key number encrypted by the private key 1 and the challenge field length encrypted by the private key 1.

It should be noted that the information 1 may include one or more of the random number 2, the device identification information 2, and the indication information, in addition to the content of the challenge request message itself. For example: when the information 1 includes the content of the challenge request message itself, the indication information, the random number 2, and the device identification information 2, 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 2 encrypted by the private key 1, the device identification information 2 encrypted by the private key 1, the indication information encrypted by the private key 1, the key type encrypted by the private key 1, the key number encrypted by the private key 1 and the challenge field length encrypted by the private key 1.

In this way, the device 2 sends a response message to the device 1, and after receiving the response message, the device 1 analyzes the response message to obtain the information 1 encrypted by the device 2 by using the private key 1, thereby providing a data base for the authentication of the device 1.

S105, the device 1 decrypts according to the public key 1 to obtain the 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 authority of the device 1 according to the verification result.

As an example, if only the content of the request message itself is challenged in the information 1, the device 1 may include, for the decrypted information 1: challenge type, key number, and challenge field length. In this example, for S106, specifically, it may be: if the device 1 locally stores the content of the challenge request message, the decrypted content of the challenge request message and the locally stored content of the challenge request message may be compared, if the content of the challenge request message is consistent with the locally stored content of the challenge request message, the usage right of the open device 1 is determined, otherwise, the authentication failure of the device 1 is determined; or, if the device 1 does not locally store the content of the challenge request message, S105 to S106 may specifically be: as long as the public key 1 is used for decryption to obtain the information 1, the authentication of the device 1 can be determined to pass, the use authority of the device 1 is opened, otherwise, the authentication of the device 1 is determined to fail.

As another example, if the information 1 includes the content of the challenge request message itself and the random number 2, the information 1 decrypted by the device 1 may include: challenge type, random number 2, key type, key number, and challenge field length. In this example, for S106, specifically, it may be: the device 1 judges whether the random number 1 stored locally is consistent with the random number 2 in the information 1, if so, the use authority of the device 1 is determined to be opened, otherwise, the authentication of the device 1 is determined to be failed.

As yet another example, if the information 1 includes the content of the challenge request message itself and the device identification information 2, the information 1 decrypted by the device 1 may include: challenge type, device identification information 2, key type, key number, and challenge field length. In this example, for S106, specifically, it may be: the device 1 judges whether the locally stored device identification information 1 is consistent with the device identification information 2 in the information 1, if so, the use authority of the device 1 is opened, otherwise, the authentication of the device 1 is determined to be failed.

As yet another example, if the information 1 includes the content of the challenge request message itself and the indication information, 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, specifically, it may be: if the device 1 locally stores the indication information, the indication information obtained after decryption can be compared with the locally stored indication information, if the indication information is consistent with the locally stored indication information, the use authority of the device 1 is opened according to the indication information, otherwise, the authentication failure of the device 1 is determined; or, if the device 1 does not locally store the indication information, the indication information may be regarded as an authentication range configured by the device 2 for the device 1, and then S105 to S106 may specifically be: the authentication of the device 1 can be determined to pass as long as the public key 1 is used for decryption to obtain the information 1, the use authority of the device 1 is opened according to the indication information, and otherwise, the authentication of the device 1 is determined to fail.

It should be noted that the information 1 may include one or more of the random number 2, the device identification information 2, and the indication information, in addition to the content of the challenge request message itself. For example: when the information 1 includes the content of the challenge request message itself, the indication information, the random number 2, and the device identification information 2, for S106, it may specifically be: the device 1 judges whether the random number 1 stored locally is consistent with the random number 2 in the information 1, if not, the authentication of the device 1 is determined to be failed; if yes, continuously judging whether the locally stored equipment identification information 1 is consistent with the identification information 2 in the information 1, and if not, determining that the authentication of the equipment 1 fails; if yes, taking the indication information carried by the challenged request message stored locally in the device 1 as an example, continuously comparing whether the indication information obtained after decryption is consistent with the locally stored indication information, and if not, determining that the authentication of the device 1 fails; if the information is consistent with the instruction information, the use authority of the device 1 is opened according to the instruction information and the device identification information 1.

The device 1 may be a network device or a board, taking the device 1 as a network device as an example, when the results of the comparison processes in S106 are all consistent, the network device opens the usage rights of all interfaces thereon; alternatively, when there is an inconsistency between the results of the comparison processes in S106, the network device does not open the usage right of any interface thereon. As another example, the information 1 also carries indication information, such as: the interface ID is debugged, and then, when the results of each comparison process in S106 are consistent, the network device may open the corresponding usage right according to the indication information, for example: opening the use permission of a debugging interface corresponding to the debugging interface ID; alternatively, when there is an inconsistency between the results of the comparison processes in S106, the network device does not open the usage right of any interface thereon.

When the device 1 may also refer to a debug interface or a service interface on a certain device, when the results of each comparison process in S106 are consistent, the device may open the usage right of the corresponding debug interface or service interface thereon. When the results of the comparison processes in S106 are inconsistent, the device may not open the usage right of the debug interface or the service interface.

In this way, through the interaction of the device 1 and the device 2, secure and reliable authentication of the device 1 is achieved, thereby ensuring that access to the device 1 is secure.

In some specific implementation manners, for a scenario where the device 3 configures a public-private key pair for the device 2, the device 3 is an absolutely secure device, and has a capability of updating a public-private key of the device 3 and revoking the public-private key allocated to the device 2, so that the authentication performed on the device 1 by using the authentication tool of the device 2 is more flexible and controllable.

As an example, when the device 3 determines that its own public key 2 and private key 2 are not secure enough, and there may be a certain security risk, it determines that the public key 2 and private key 2 are invalid, which may further include: s31, the device 3 enables the private key 4 and the corresponding public key 4; s32, the device 3 adopts the private key 4 to encrypt the public key 1 and the private key 1 respectively; s33, the device 3 configures the public key 4, the public key 1 respectively by adopting the private key 4 and the private key 1 respectively by adopting the private key 4 to the device 2; s34, the device 2 decrypts the private keys 1 respectively by the private keys 4 by the public keys 4 to obtain the private keys 1 and stores the private keys 1 in the local safe storage space of the device 2; s35, device 1 sends challenge request message to device 2; s36, the device 2 sends a response message 1 to the device 1, where the response message 1 at least includes: challenge type, public key 4, key type, key number, and challenge field length, and the value of the challenge type field in the response message 1 is used to instruct the device 1 to update the corresponding public key of the device 3 stored thereon, for example: the value of the challenge type field is 0x55AA 555A; s37, device 1 deletes public key 2 or sets public key 2 as the prohibited public key, and stores public key 4 accordingly. In this way, the device 3 enables updating 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 determines that the public key 1 and the private key 1 are invalid, and this embodiment of the present application may further include: s41, device 3 reassigns private key 3 and corresponding public key 3 to device 2; s42, the device 3 respectively encrypts the public key 3 and the private key 3 by using the private key 2; s43, the device 3 configures the public key 2, the public key 3 respectively by using the private key 2 and the private key 3 respectively by using the private key 2 to the device 2; and S44, the device 2 decrypts the private keys 3 respectively by using the private key 2 through the public key 2 to obtain the private keys 3, and stores the private keys 3 in the local secure storage space of the device 2. In this way, the device 3 realizes revoking and updating 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 safely and reliably.

As another example, when the device 3 determines that the public key 2 and the private key 2 of the device are not sufficiently secure, and the public key 1 and the private key 1 allocated to the device 2 by the device 3 are also not sufficiently secure, and there may be a certain potential safety hazard, it is determined that the public key 2, the private key 2, the public key 1, and the private key 1 all fail, and the embodiment of the present application may further include: s51, enabling the user private key 4 and the corresponding public key 4 by the device 3, and reallocating the private key 3 and the corresponding public key 3 to the device 2; s52, the device 3 encrypts the public key 3 and the private key 3 with the private key 4, respectively; s53, the device 3 configures the public key 4, the public key 3 respectively by using the private key 4 and the private key 3 respectively by using the private key 4 to the device 2; s54, the device 2 decrypts the private keys 3 respectively by the private keys 4 by the public keys 4 to obtain the private keys 3 and stores the private keys 3 in the local safe storage space of the device 2; s55, device 1 sends challenge request message to device 2; s56, the device 2 sends a response message 2 to the device 1, where the response message 2 at least includes: the challenge type, the public key 4, the key type, the key number and the challenge field length, and the value of the challenge type field in the response message 2 is used for instructing the device 1 to update the corresponding public key of the device 3 stored thereon; s57, device 1 deletes public key 2 or sets public key 2 as the prohibited public key, and stores public key 4 accordingly. In this way, the device 3 realizes the update of the public key stored in the device 1 and the revoke and update of the public key and the private key used for authentication in the device 2, so that the device 2 can authenticate the device 1 more safely and reliably.

It can be seen that, by the authentication method provided by the embodiment of the application, the device 1 to be authenticated sends information 2 to the device 2 with the authentication function, such as an authentication tool; the device 2 encrypts the received information 1 based on the private key 1 and sends the information 1 encrypted by the private key 1 to the device 1; the device 1 decrypts according to the public key 1 to obtain the information 1, and determines the use authority of the device 1 by comparing the information 1 with the locally stored information 2. Therefore, the authentication of the equipment 1 to be authenticated by the equipment 2 is realized through the encryption and decryption technology and the special equipment 2 for authenticating the equipment 1, the potential safety hazard existing when the equipment 1 is protected to be safe in the modes of exposing the corresponding bonding pad of the password book or the interface and the like at present is overcome, and the equipment 1 to be authenticated is ensured to be more safe and reliable in protection.

For a more clear and detailed description of the embodiment of the present application, in the following scenario shown in fig. 1, assuming that the device 12 is the debug interface 12 of the switch, the CA server 13 and the switch 12 cannot directly communicate, and the CA server 13 and the authentication tool 11 cannot directly communicate, as an example, the authentication process in the embodiment of the present application is specifically described with reference to fig. 4.

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

s201, the user 14 submits a request message on the CA server 13, where the request message is used to request the CA server 13 to distribute the public and private keys to the authentication tool 11.

In this embodiment, the user 14 may also be a safe production line automation device, and all operations performed by the user 14 are automatically performed.

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 encrypts the private key B and the public key B respectively with its own private key d.

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 the 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 decrypts the private key b encrypted by the private key D by using the public key D, and obtains and stores the private key b.

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

S209, the authentication tool 11 encrypts the information in the challenge request message 1 by using the locally stored private key b, and generates a response message 1 including X2 encrypted by the private key b, where X2 is a 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 exchanger decrypts the public key B encrypted by the private key D by using the locally stored public key D, and obtains and stores the public key B.

S213, the exchanger decrypts the information in the response message 1 by using the public key B to obtain X2, wherein X2 is obtained by decrypting the X2 encrypted by using the private key B by using the public key B.

S214, the switch compares whether the X2 is consistent with the random number X1 stored locally, if so, S215 is executed, otherwise, S216 is executed.

S215, the switch opens the usage right of the debug interface 12.

S216, the exchanger determines to stop the authentication process and reports the authentication error to the CA server 13.

Thus, in this embodiment, through the encryption and decryption technology, the CA server 13, which is a server with a higher security level, and the interaction between the authentication tool 11 specially used for authenticating the switch and the switch, the management of the use permission of the debug interface 12 on the switch by the authentication tool 11 is realized, and the safer protection of the key interface on the switch is realized.

Fig. 5 shows a flowchart of an authentication method 300 in an embodiment of the present application, where the method 300 is applied in a scenario including a first device and a second device, and the first device is used as an execution subject, and the authentication method 300 may include:

s301, receiving first information which is sent by second equipment and encrypted by a first private key;

s302, decrypting according to the first public key to obtain the first information, wherein the first public key corresponds to the first private key;

s303, performing matching verification on the first information and the locally stored second information to obtain a verification result;

s304, determining the use authority of the first device according to the verification result.

The first device may be device 1 in method 100, and then the second device is device 2 in method 100, the first private key is private key 1 in method 100, the first public key is public key 1 in method 100, the first information is information 1 in method 100, and the second information is information 2 in method 100. Or, the first device may also be the debug 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, the first public key is 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 passes, the first device opens the corresponding usage right, and when the verification result indicates that the verification fails, the first device does not open the corresponding usage right. Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the second equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

In some possible implementations, the first private key and the first public key may be generated by the second device; alternatively, the first private key and the first public key may be configured for the second device by the authentication server.

For greater security, the method 300 may further include: the first equipment receives a first public key which is sent by the second equipment and encrypted by a second private key of the authentication server; and the first equipment decrypts the encrypted first public key by using the locally stored second public key of the authentication server to obtain the first public key. Therefore, the first public key is encrypted by the authentication server which is a server with higher security level, and the first public key is safer and more reliable than the first public key which is directly stored on the first device.

As an example, the second information may include a first random number, and before performing S301, the method 300 may further include: sending a challenge request message to the second device, wherein the challenge request message carries a first random number; then, S301 may specifically include: the first device receives a response message sent by the second device, wherein the response message carries the first information, and the first information comprises a second random number; at this time, S303 may specifically include: and performing matching verification on the first random number and the second random number. The first random number can uniquely identify the first authentication of the first device, and the random number is used for authentication, so that each authentication can be performed based on the random number generated at this time, the information of the first device can be effectively prevented from being copied, and replay attack is prevented.

As another example, the second information may further include first device identification information, where the first information includes second device identification information, and the first device identification information is used to uniquely identify the first device, then S303 may further specifically include: and performing matching verification on the first equipment identification information and the second equipment 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 further include: and performing matching verification on the first device ID and the second device ID. As another example, if the first device identification information is a hash value of a first device ID, and the second device identification information is a hash value of a second device ID, then S303 may specifically include: and performing matching verification on the hash value of the first device ID and the hash value of the second device ID. For the security of authentication, the device ID in this embodiment of the application is an unpublished ID capable of uniquely identifying the device, for example: the first device ID is a hardware unique key HUK defined when the first device is shipped, for example: the first device ID is processed from the wafer identification die ID and the unique device identification UDI of the first device. Therefore, the decrypted hash value of the second device ID or the second device ID is verified through the first device ID or the hash value of the first device ID locally stored by the first device, and the reliable and safe authentication of the first device is realized.

As another example, the second information may further include target valid information, and the first information includes actual usage information, where the actual usage information is used to characterize a case where the first device is currently authenticated using the second device. Then, S303 may specifically further include: and the first equipment verifies the actual use information according to the target valid information so as to determine whether the second equipment can be continuously used for authenticating the first equipment. When the first device determines that the actual use information does not reach the target valid information, the second device is determined to be valid for the first device, and the second device can be continuously used for authenticating the first device; otherwise, when the first device determines that the actual usage information has reached the target valid information, it determines that the second device has failed for the first device, and cannot continue to use the second device to authenticate the first device. The target valid information is the maximum number of times (for example, 5 times) that the authentication is allowed to be performed by using the second device; alternatively, the target valid information is the maximum time allowed for authentication using the second device (e.g., 20 hours). Therefore, the actual use information carried in the first information is verified through the target effective information locally stored in the first equipment, and the reliable and safe authentication of the first equipment is realized.

As still another example, the first information may further include indication information indicating at least one of the following information: time for opening the usage right, interface for opening the usage right, or operation for opening the usage right. The indication information may be sent by the first device to the second device in the challenge request message, or may be corresponding indication information specified by the second device according to the authentication range of the second device; the first device may also send the challenge request message to the second device, and the second device determines the corresponding indication information according to its own authentication range. Therefore, the reliable and safe authentication of the first equipment is realized through the indication information obtained after the first equipment receives and decrypts the indication information.

It should be noted that, for the method 300 in the embodiment of the present application, specific implementation and achieved effects can be referred to the related descriptions in the embodiments shown in fig. 3 and fig. 4.

Fig. 6 shows a flowchart of a method 400 for authenticating a usage right of a first device in an embodiment of the present application, where the method 400 is applied in a scenario including the first device and a second device, and the second device is used as an execution subject, and the method 400 may include:

s401, encrypting the first information by using a locally stored first private key;

s402, sending the first information encrypted by the first private key to a first device to authenticate the use authority of the first device.

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

Therefore, the authentication of the first equipment to be authenticated is realized through the encryption and decryption technology and the second equipment with the authentication function, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a bonding pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be protected more safely and reliably.

In some specific implementations, the first private key and the first public key may be generated by the second device; alternatively, the first private key and the first public key may be configured for the second device by the authentication server.

As an example, the method 400 may further include: the method comprises the steps that a second device receives a second public key of an authentication server, a first public key encrypted by a second private key and a first private key encrypted by the second private key, wherein the second public key corresponds to the second public key; then, the second device decrypts the first private key encrypted by the second private key by using the second public key 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 second public key stored locally to obtain the first public key.

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

As yet another example, the second information may further include the first information further includes first device identification information used by the first device for authentication, such as: may be the first device ID or a hash of the first device ID. The method 400 may further include: the second device performs matching verification on the first device ID and a second device ID which is locally stored and corresponds to the first device; or the second device performs matching verification on the hash value of the first device ID and a locally stored hash value of a second device ID corresponding to the first device. The first device ID is a hardware unique key HUK defined when the first device leaves a factory, or the first device ID is obtained by processing according to a wafer identifier die ID and a unique device identifier UDI of the first device.

As yet another example, the first information may further include target valid information used by the first device to determine whether authentication using the second device can continue. Then, the method 400 may further include: the second device updates the actual use information, and the actual use information is used for representing the condition of currently using the second device for authentication on the first device; and then, the second equipment verifies the updated actual use information according to the target valid information so as to determine whether the second equipment can be continuously used for authenticating the first equipment. If the target valid information is the maximum number of times of authentication allowed by using the second device, the actual use information is the actual use number of times of authentication performed by the first device by using the second device at present; or, the target valid information is the longest time allowed to use the second device for authentication, and the actual usage information is the actual usage time from the starting time of the timing of the target valid information to the current time.

As still another example, the first information may further include indication information indicating at least one of the following information: time for opening the usage right, interface for opening the usage right, or operation for opening the usage right.

It should be noted that, for the method 400 in the embodiment of the present application, specific implementation and achieved effects can be referred to in the embodiments shown in fig. 3, fig. 4 and fig. 5 described above.

In addition, the present application also provides a first device 700, see fig. 7. The first device 700 comprises a transceiving unit 701 and a processing unit 702. The transceiver 701 is configured to perform a transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or a transceiving operation performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or a transceiving operation performed by the first device in the method embodiment shown in fig. 5; the processing unit 702 is configured to perform other operations besides the transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or other operations besides the transceiving operation performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or other operations besides the transceiving operation performed by the first device in the method embodiment shown in fig. 5. For example: the first device 700 is the device 1 in the method 100, and then the transceiving unit 701 is configured to receive the information 1 encrypted by the private key 1 and sent by the device 2; the processing unit 702 is configured to perform decryption according to the public key 1 to obtain the information 1, and the processing unit 702 is further configured to compare the information 1 with the locally stored information 2 to determine the usage right of the device 1.

In addition, a second apparatus 800 is also provided in the embodiments of the present application, see fig. 8. The second device 800 comprises a transceiving unit 801 and a processing unit 802. Wherein, the transceiver 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 transceiving operation performed by the second device in the method embodiment shown in fig. 6; the processing unit 802 is configured to perform other operations besides the transceiving operation performed by the device 2 in the embodiment shown in fig. 3, or other operations besides the transceiving operation performed by the authentication tool 11 in the embodiment shown in fig. 4, or other operations besides the transceiving operation performed by the second device in the embodiment of the method shown in fig. 6. For example: the first device 800 is the device 2 in the method 100, then the transceiving unit 801 is configured to send the information 1 encrypted by the private key 1 to the device 1; the processing unit 802 is configured to encrypt the information 1 according to a locally stored private key 1.

In addition, the embodiment of the present application further provides a first device 900, which is shown in fig. 9. The first device 900 comprises a communication interface 901 and a processor 902 connected to the communication interface 901. The communication interface 901 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 debug interface 12 of the switch in the embodiment shown in fig. 4, or the transceiving operation performed by the first device in the method embodiment shown in fig. 5; the processor 902 is configured to perform the operations, other than the transceiving operations, performed by the device 1 in the embodiment shown in fig. 3, or the operations, other than the transceiving operations, performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or the operations, other than the transceiving operations, performed by the first device in the embodiment of the method shown in fig. 5. For example: the first device 900 is the device 1 in the method 100, and then the communication interface 901 is configured to receive the information 1 encrypted by using the private key 1 and sent by the device 2; the processor 902 is configured to perform decryption according to the public key 1 to obtain information 1; the processor 902 is also arranged to compare the information 1 with the locally stored information 2 to determine the usage rights of the device 1.

In addition, the embodiment of the present application also provides a second apparatus 1000, which is shown in fig. 10. The second device 1000 comprises a communication interface 1001 and a processor 1002 connected to the communication interface 1001. The communication interface 1001 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 transceiving operation performed by the second device in the embodiment of the method shown in fig. 6; the processor 1002 is configured to perform the operations, other than the transceiving operations, performed by the device 2 in the embodiment shown in fig. 3, or the operations, other than the transceiving operations, performed by the authentication tool 11 in the embodiment shown in fig. 4, or the operations, other than the transceiving operations, performed by the second device in the embodiment of the method shown in fig. 6. For example: the second device 1000 is device 2 in the method 100, then the communication interface 1001 is configured to send information 1 encrypted by the private key 1 to the device 1; the processor 1002 is configured to encrypt the information 1 according to a locally stored private key 1.

In addition, the embodiment of the present application further provides a first device 1100, which is shown in fig. 11. The first device 1100 includes a memory 1101 and a processor 1102. Wherein the memory 1101 is used for storing program codes; the processor 1102 is configured to execute the instructions in the program code, so that the first device 1100 performs the method performed by the device 1 in the embodiment shown in fig. 3, or the method performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or the method performed by the first device in the embodiment of the method shown in fig. 5.

In addition, the embodiment of the present application further provides a second apparatus 1200, which is shown in fig. 12. The second device 1200 comprises a memory 1201 and a processor 1202. Wherein the memory 1201 is used for storing program codes; the processor 1202 is configured to execute the instructions in the program code, so that the second device 1200 performs the method performed by the device 2 in the embodiment shown in fig. 3, or the method performed by the authentication tool 11 in the embodiment shown in fig. 4, or the method performed by the second device in the embodiment of the method shown in fig. 6.

It is understood that in the above embodiments, the processor may be a Central Processing Unit (CPU), a Network Processor (NP), or a combination of CPU and NP. The processor may also be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof. The processor may refer to one processor or may include a plurality of processors. The memory may include a volatile memory (RAM), such as a random-access memory (RAM); the memory may also include a non-volatile memory (ROM), such as a read-only memory (ROM), a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); the memory may also comprise a combination of memories of the kind described above. The memory may refer to one memory, or may include a plurality of memories. In one embodiment, the memory has stored therein computer-readable instructions comprising a plurality of software modules, such as a sending module, a processing module, and a receiving module. After the processor executes each software module, the processor can perform corresponding operation according to the instruction of each software module. In the present embodiment, the operation performed by one software module actually refers to an operation performed by the processor according to the instruction of the software module. After the processor executes the computer-readable instructions in the memory, all operations that the first device or the second device may perform may be performed as directed by the computer-readable instructions.

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

In addition, an embodiment of the present application further provides a communication system 1300, which is shown in fig. 13. The communication system 1300 includes a first device 1301 and a second device 1302, where the first device 1301 may specifically be the first device 700, the first device 900, or the first device 1100, and the second device 1402 may specifically be the second device 800, the second device 1000, or the second device 1200.

In addition, an embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored, and when the instructions are executed on a computer, the computer is caused to execute the authentication method in the embodiments shown in fig. 3 to fig. 6.

In addition, the embodiment of the present application also provides a computer program product, which when running on a computer, causes the computer to execute the authentication method in the foregoing embodiments shown in fig. 3 to fig. 6.

In the names of "first information", "first private key", and the like, the "first" in the embodiments of the present application is used only for name identification, and does not represent the first in sequence. The same applies to "second" etc.

As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by software plus a general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product, which may be stored in a storage medium, such as a read-only memory (ROM)/RAM, a magnetic disk, an optical disk, or the like, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, system embodiments and device embodiments are substantially similar to method embodiments and are therefore described in a relatively simple manner, where relevant reference may be made to some descriptions of method embodiments. The above-described embodiments of the apparatus and system are merely illustrative, wherein modules described as separate parts may or may not be physically separate, and parts shown as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only a preferred embodiment of the present application and is not intended to limit the scope of the present application. It should be noted that, for a person skilled in the art, several improvements and modifications can be made without departing from the scope of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. An authentication method, implemented by a first device, comprising:

receiving first information which is sent by second equipment and encrypted by a first private key;

decrypting according to a first public key to obtain the first information, wherein the first public key corresponds to the first private key;

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

and determining the use authority of the first equipment according to the verification result.

2. The method of claim 1,

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

alternatively, the first and second electrodes may be,

the first private key and the first public key are configured for the second device by the authentication server.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

receiving a first public key which is sent by the second equipment and encrypted by a second private key of the authentication server;

and decrypting the encrypted first public key by using a locally stored second public key of the authentication server to obtain the first public key.

4. The method according to any of claims 1-3, wherein the second information comprises a first random number, and wherein before the receiving the first information encrypted with a first private key sent by the second device, the method further comprises:

sending a challenge request message to the second device, wherein the challenge request message carries the first random number;

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

receiving a response message sent by the second device, wherein the response message carries the first information, and the first information comprises a second random number;

the matching verification of the first information and the locally stored second information includes:

and performing matching verification on the first random number and the second random number.

5. 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, the first device identification information is used for uniquely identifying the first device, and the matching verification of the first information and the locally stored second information further includes:

and performing matching verification on the first equipment identification information and the second equipment identification information.

6. The method of claim 5,

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 a first device ID, and the second device identification information is a hash value of a second device ID.

7. The method according to claim 6, wherein the first device ID is a Hardware Unique Key (HUK) defined at the time of shipment of the first device, or the first device ID is processed according to a wafer identification die ID and a Unique Device Identification (UDI) of the first device.

8. The method according to any one of claims 1 to 7, wherein the second information further includes target valid information, the first information includes actual usage information, the actual usage information is used for characterizing a condition of authentication of the second device currently used on the first device, and the matching verification of the first information and the locally stored second information further includes:

and verifying the actual use information according to the target valid information to determine whether the second equipment can be continuously used for authenticating the first equipment.

9. The method of claim 8,

the target valid information is the maximum number of times of authentication allowed by using the second equipment;

alternatively, the first and second electrodes may be,

the target valid information is the maximum time allowed for authentication using the second device.

10. The method according to any one of claims 1 to 9, wherein the first information further comprises indication information indicating at least one of the following information: time for opening the usage right, interface for opening the usage right, or operation for opening the usage right.

11. The method of any of claims 1-10, wherein the first device is a debug interface.

12. A method of authenticating usage rights of a first device, implemented by a second device, comprising:

encrypting the first information by adopting a locally stored first private key;

and sending the first information encrypted by the first private key to the first equipment so as to authenticate the use authority of the first equipment.

13. The method of claim 12, further comprising:

receiving a second public key of an authentication server, the first public key encrypted by a second private key and the first private key encrypted by the second private key, which are sent by the authentication server, wherein the second private key corresponds to the second public key;

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

and sending the first public key encrypted by the second private key to the first device.

14. The method of claim 12 or 13, wherein the first information comprises a first random number, and wherein prior to encrypting the first information, the method further comprises:

receiving a challenge request message sent by the first device, wherein 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:

and sending a response message to the first device, wherein the response message carries the first random number encrypted by the first private key.

15. The method according to any one of claims 12 to 14,

the first information includes first device identification information used by the first device for authentication.

16. The method of claim 15, wherein the first device identification information is a first device Identification (ID) or a hash value of the first device ID.

17. The method according to claim 16, wherein the first device ID is a hardware unique key HUK defined at the time of shipment of the first device, or wherein the first device ID is processed from a wafer identification die ID and a unique device identification UDI of the first device.

18. The method of any of claims 12-17, wherein the first information further comprises target valid information, the target valid information being used by the first device to determine whether authentication using the second device can continue.

19. The method of claim 18,

alternatively, the first and second electrodes may be,

20. The method according to any of claims 12-19, wherein the first information further comprises indication information indicating at least one of the following information: time for opening the usage right, interface for opening the usage right, or operation for opening the usage right.

21. The method of any of claims 1-20, wherein the first device is a debug interface.

22. A first device, comprising:

a communication interface; and

a processor coupled to the communication interface;

the communication interface and the processor, the first device being configured to perform the method of any of the preceding claims 1-11.

23. A second apparatus, comprising:

a communication interface; and

a processor coupled to the communication interface;

the second device is configured to perform the method of any of the preceding claims 12-21 according to the communication interface and the processor.

24. A first device, wherein the first device comprises a memory and a processor;

the memory for storing program code;

the processor, configured to execute instructions in the program code to cause the first device to perform the method of any of claims 1-11 above.

25. A second device, wherein the second device comprises a memory and a processor;

the memory for storing program code;

the processor, configured to execute instructions in the program code to cause the second device to perform the method of any of the preceding claims 12-21.

26. A computer-readable storage medium having stored therein instructions which, when run on a computer, cause the computer to perform the method of any of claims 1-11 or claims 12-21 above.

27. A communication system comprising a first device according to claim 22 or 24 and a second device according to claim 23 or 25.