CN113055340B

CN113055340B - Authentication method and equipment

Info

Publication number: CN113055340B
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: 2023-09-26
Anticipated expiration: 2039-12-26
Also published as: WO2021128989A1; CN113055340A

Abstract

The embodiment of the application discloses an authentication method and equipment, wherein an authentication tool (namely, second equipment) sends first information encrypted by a first private key to first equipment to be authenticated, and the first equipment 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 locally stored second information to obtain a verification result, and the use authority of the first device is determined according to the verification result. Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

Description

Authentication method and equipment

Technical Field

The application relates to the technical field of secure communication, in particular to an authentication method and equipment, which can be used for authenticating equipment or an interface on the equipment when the use authority for opening the equipment or the interface on the equipment is required.

Background

Many pieces of information are stored on the device, and some of the information is very important to the manufacturer or user of the device. Currently, devices are authenticated, typically by means of a codebook, to ensure the security of the device and the information thereon. Specifically, a plurality of passwords are stored in a codebook, one or more passwords are preset on the equipment, when the requirement of opening the use authority of the equipment is met, appointed personnel (such as debugging personnel, operation and maintenance personnel, production personnel and the like) input the passwords in the codebook into the equipment, match with the passwords preset in the equipment, and when the match is successful, the equipment passes the authentication, the use authority corresponding to the successfully matched passwords on the equipment is opened, so that the corresponding important information can be accessed through the opened use authority on the equipment.

However, since the codebook is used for storing, transmitting and matching in plaintext, and the password in the codebook is easy to leak by artificially managing the codebook, the security is low by adopting the codebook to authenticate the device. Based on the above, it is needed to provide an authentication method with higher security level, so as to ensure that the device is opened with the use permission under the condition of security, thereby ensuring the security of the information thereon.

Disclosure of Invention

Based on the above, the embodiment of the application provides an authentication method and equipment, which realize safer authentication of equipment to be authenticated by encrypting information sent by the equipment to be authenticated through an authentication tool and decrypting the information by the equipment 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 uses the first device as an execution body, where the authentication method may include, for example: after receiving first information encrypted by a first private key and sent by a second device, the first device 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 locally stored second information to obtain a verification result, and the use authority of the first device is determined according to the verification result. Specifically, when the verification result indicates that the verification is passed, the first device opens the corresponding use right, and when the verification result indicates that the verification is not passed, the first device does not open the corresponding use right. Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

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

Alternatively, 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 by the authentication server for the second device.

For better security, the embodiment of the application can further comprise: the first device receives a first public key which is sent by the second device and is encrypted by a second private key of the authentication server; the first device decrypts the encrypted first public key using a locally stored second public key of the authentication server to obtain the first public key. In this way, the first public key is encrypted by the authentication server, which is a higher security level server, which is safer and more reliable than directly storing the first public key on the first device.

Optionally, before the second information includes the first random number and the first information encrypted with the first private key sent by the second device is received, the embodiment of the present application may further include: the first equipment sends a challenge request message to the second equipment, wherein the challenge request message carries a first random number; then, the first device receives first information encrypted by the first private key sent by the second device, including: the first equipment receives a response message sent by the second equipment, wherein the response message carries the first information, and the first information comprises a second random number; at this time, the first device performs matching verification on the first information and the locally stored second information, including: and carrying out matching verification on the first random number and the second random number. The first random number can uniquely identify one-time authentication of the first equipment, and the random number is used for authentication, so that each authentication can be performed based on the random number generated at the time, information of the first equipment 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 second device identification information, where the first device identification information is used to uniquely identify the first device, and the first device performs matching verification on the first information and the locally stored second information, and may further include: and carrying out 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, and then the first device performs matching verification on the first information and the locally stored second information, and may further include: and carrying out matching verification on the first equipment ID and the second equipment ID. As another example, for better security, 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, and may further include: and carrying out matching verification on the hash value of the first equipment ID and the hash value of the second equipment ID. Wherein the first device ID is used to uniquely identify the first device. For the security of authentication, in the embodiment of the present application, the device ID is a non-public ID capable of uniquely identifying the device, for example: the first device ID is a hardware unique key (english: hardware Unique Key, abbreviated as "HUK") defined when the first device leaves the factory, and for example: the first device ID is obtained by processing according to a wafer identifier (english: die Identification, abbreviated as die ID) and a unique device identifier (english: unique Device Identification, abbreviated as UDI) of the first device. In this way, the first equipment ID or the first equipment ID hash value and other first equipment identification information are locally stored in the first equipment, the second equipment ID or the second equipment ID hash value and other second equipment identification information obtained after decryption is verified, the first equipment is guided to manage the use authority, and the first equipment is reliably and safely authenticated.

Optionally, 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 current authentication situation of the first device using the second device. Then, the first device performs matching verification on the first information and the locally stored second information, and may further include: and the first device verifies the actual use information according to the target effective information to determine whether the second device can be continuously used for authenticating the first device. 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 used for authenticating the first device; otherwise, when the first device determines that the actual usage information has reached the target valid information, it is determined that the second device has failed for the first device, and the second device cannot be used for authenticating the first device. Wherein the target validity information is the maximum number of times (e.g., 5 times) authentication is allowed using the second device; alternatively, the target validity information is the maximum time (e.g., 20 hours) that the second device is allowed to authenticate. In this way, the target effective information locally stored by the first device is used for verifying the actual use information carried in the first information, so as to guide the first device to manage the use authority of the first device, and realize the reliable and safe authentication of the first device.

Optionally, the first information 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 right, the interface of opening the use right or the operation of opening the use right. The indication information can be corresponding indication information which is sent to the second device by the first device in the challenge request message or specified by the second device according to the authentication range of the second device; the first device may also send corresponding indication information to the second device in the challenge request message, where the indication information is determined by the second device according to the authentication range of the second device. In this way, the indication information obtained after the first device receives and decrypts the indication information guides the first device to manage the specific use authority, so that the first device is reliably and safely authenticated.

In a second aspect, an embodiment of the present application further provides a method for authenticating a use right of a first device, where the method is applied in a scenario including the first device and a second device, and uses the second device as an execution body, where the authentication method may include, for example: the second device 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 device so as to authenticate the use authority of the first device. Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

The second device may be referred to as 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: and may also refer to a debug interface or a business interface on the device. When the first device refers to the debug interface, the authentication tool issues the first information encrypted by the first private key to the device where the debug interface is located, and the first public key decrypts the first information, and after the first information passes through verification, the device where the debug interface is located opens the use authority of the debug interface for accessing and using the debug interface.

Optionally, the embodiment of the application further comprises: the second device receives 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; 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 locally stored second public key to obtain the first public key.

Optionally, the first information includes a first random number, and before encrypting the first information, an 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 second device transmitting the first information encrypted by the first private key to the first device may include: and the second device sends a response message to the first device, wherein the response message carries the first random number encrypted by the first private key.

Alternatively, the first information may include first device identification information, which is used by the first device for authentication. The first equipment identification information is the first equipment identification ID or a hash value of the first equipment ID. As an example, when the first information includes the first device ID, an embodiment of the present application may further include: and the second equipment performs matching verification on the first equipment ID and the locally stored second equipment ID corresponding to the first equipment. As another example, the first information may further include a hash value of the first device ID, and then an embodiment of the present application may further include: and carrying out matching verification on the hash value of the first equipment ID and the hash value of the second equipment ID which is stored locally and corresponds to the first equipment. The first equipment ID is a hardware unique key HUK defined when the first equipment leaves a factory, or is obtained by processing according to a wafer identification die ID and a unique equipment identification UDI of the first equipment.

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

Optionally, the first information 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 right, the interface of opening the use right or the operation of opening the use right.

Various possible implementation manners and achieved technical effects of the method provided in the second aspect may refer to the description of the method provided in the first aspect, which is not repeated herein.

In a third aspect, the present application further provides a first device, including a transceiver unit and a processing unit. The transceiver unit is configured to perform a transceiver operation in the method provided in the first aspect; the processing unit is configured to perform operations other than the transceiving operation in the first aspect described above. For example: when the first device executes the method of the first aspect, the transceiver unit is configured to receive first information sent by a second device and encrypted with a first private key; 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 carrying out 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 authority of the first device according to the verification result.

In a fourth aspect, the embodiment of the 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 transceiver operation in the method provided by the second aspect; the processing unit is configured to perform operations other than the transceiving operation in the above second aspect. For example: the transceiver unit is configured to send the first information encrypted by the first private key to a first device when the second device performs the method of the second aspect; the processing unit is used for encrypting the first information by adopting a locally stored first private key.

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

In a sixth aspect, an embodiment of the present application further provides a second device, including a communication interface and a processor. Wherein the communication interface is configured to perform the transceiving operation in the method provided by the second aspect; and a processor, configured to perform operations other than the transceiving operation in the method provided in the 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 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 instructions in the program code to cause the first device to perform the method provided in the second aspect above.

In a ninth aspect, embodiments of the present application also provide a computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the authentication method provided in the first or second aspect above.

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

In an eleventh aspect, the embodiment of 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 of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings for those of ordinary skill in the art.

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 flow chart of authentication of the device 12 in the scenario of FIG. 1 in an embodiment of the present application;

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

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

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

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

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

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

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

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

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

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 diagram of a communication system 1300 according to an embodiment of the present application.

Detailed Description

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

At present, a device is generally authenticated by adopting a mode of a codebook, one or more passwords are preset on the device, a plurality of passwords are stored on the codebook, when the use permission of the device needs to be opened, the passwords in the codebook are input into the device by appointed personnel such as debugging personnel, operation and maintenance personnel and production personnel, the device matches the input passwords with the preset passwords, when the matching is successful, the device is regarded as the authentication of the device to pass, and the device opens the use permission corresponding to the successfully matched passwords, so that the corresponding important information can be accessed through the opened use permission. Although the code book is mastered by a few appointed persons, the safety of important information stored on the equipment can be ensured to a certain extent, the storage, transmission and matching of the code book are all realized by adopting plaintext, moreover, the appointed persons with the code book authority are relatively miscellaneous, the password in the code book is easy to leak by artificially managing the code book, and the mode of authenticating the equipment by adopting the code book is low in safety.

In addition, because access to important information on the device is usually achieved through key interfaces (such as debug interfaces or business interfaces) on the device, many manufacturers of the device remove connectors of the key interfaces (i.e. pads corresponding to the key interfaces are exposed) when the device leaves the factory, so as to ensure the safety of the important information on the device. However, an attacker can identify the bonding pads corresponding to the key interfaces through instruments such as an observation instrument, a universal meter and the like, and access the key interfaces to the analyzer through jumper wires, so that the important information is directly acquired, and the method is quite unsafe. For example: hardware data of microsoft notebooks are usually encrypted and protected by adopting two-level keys, namely, the hardware data is encrypted by a full volume encryption key (English: full Volume Encryption Key, abbreviated as FVEK), and the hardware data is encrypted by a volume master key (English: volume Master Key, abbreviated as VMK) (also called an original key); the VMK is stored in a trusted platform module (English: trusted Platform Module; TPM for short). When the notebook computer is produced by Microsoft, an LPC (Low Pin Count) interface of a TPM is added to test the performance of the notebook computer, but when the notebook computer is shipped, the interface is exposed from a bonding pad corresponding to a connector, so that an attacker can easily identify the LPC interface of the exposed TPM, and the interface is connected with a logic analyzer through a jumper wire to directly obtain the VMK, thereby breaking the FVEK encrypted by the VMK, further breaking hard disk data encrypted by the FVEK, and seriously endangering the safety of the notebook computer.

Therefore, the security of the device and the security of important information on the device cannot be well ensured in both the protection mode of the codebook and the mode of removing the connector of the key interface of the device when leaving the factory.

Based on this, the embodiment of the application provides an authentication method, when a user needs to access a first device, the first device needs to perform authentication, and after the authentication passes, the corresponding use authority on the first device can be opened, so that the user can safely access or use the first device within the opened use authority range. The first device to be authenticated locally stores the second information and the first public key, and the authentication process may specifically include: transmitting second information to second equipment with authentication function such as an authentication tool by first equipment to be authenticated; for the second device, receiving first information (which may be the same as or different from second information) sent by the first device, encrypting the received first information based on the 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 the locally stored second information to obtain a verification result, and then determines the use authority of the first device according to the verification result. Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

For example, one of the scenarios of the embodiments 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 a 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 or a switch, a terminal device such as a mobile phone or a notebook computer, a mobile storage device such as a usb disk, or a debug interface, a service interface, or a board. The scenario shown in fig. 1 may further include a certificate authority (english: certificate Authority, abbreviated as CA) server 13, configured to assign a public-private key to the authentication tool, so as to improve the security level of the authentication scenario.

In particular, the authentication tool 11 stores a private key a in a 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 procedure for the device 12, see fig. 2, may include: s11, the device 12 generates a random number 1; s12, the device 12 carries the random number 1 in a challenge request message and sends the challenge request message to the authentication tool 11; s13, the authentication tool 11 encrypts the received random number 2 (which can be consistent with the random number 1 or not consistent with the random number 1) by using the private key a to obtain X; s14, the authentication tool 11 carries X in a response message and sends the response message to the device 12; s15, the device 12 decrypts the 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, if the random number 1 and the random number 2 are the same, the authentication of the device 12 passes, otherwise, 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, or may be distributed by the CA server 13 to the authentication tool 11, and may be specifically determined according to the security requirement of the device 12, which is not specifically limited in the embodiment of the present application. The CA server 13 may be an offline 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 through a secure production environment device as a medium; alternatively, the CA server 13 may be an online server with respect to the authentication tool 11 and the device 12, and the interaction may be performed 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 transferred 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 with in the local storage area of the device. For example: the secure storage area may be a One-time programmable memory (English: one-Time Programmable, abbreviated: OTP) of the device, again for example: the secure storage area may also be an electrical FUSE (e.g., eFUSE) of the device, and since the contents stored in the secure storage area such as OTP or eFUSE may not be changed, the secure storage area local to the device may reliably and safely store important information, for example: the secure storage area local to the authentication tool 11 may reliably and securely hold the private key a and the secure storage area local to the device 12 may reliably and securely hold the public key a.

It will be appreciated that the above scenario is merely an example of one scenario provided by embodiments of the present application, and embodiments of the present application are not limited to this scenario.

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

Fig. 3 is a flowchart of an authentication method 100 according to an embodiment of the present application. Referring to fig. 3, the method 100 is applied in a network comprising a device 1 and a device 2, wherein the device 1 has a public key 1 stored in advance. The method 100 may be performed first 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, 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 transmitted by the device 1.

The device 2 refers to a physical entity for authenticating the device 1 to be authenticated, which is also called an authentication tool, and is used for authenticating the device to be authenticated to determine whether to open the use authority of the device to be authenticated. The device 2 may comprise 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 (English: universal Serial Bus, abbreviated as USB) interface or a joint test work group (English: joint Test Action Group, abbreviated as JTAG) interface; alternatively, the authentication interface may be a wireless interface, such as: bluetooth.

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

Information 1 may include: the device 2 receives the random number 2. When the device 1 needs to authenticate, the device 1 can generate a random number 1 corresponding to the authentication, and store the random number 2 in a 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 authentication can be performed based on the random number generated at this time, and the information of the equipment 1 can be effectively prevented from being copied and replay attack can be prevented.

In particular, 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 therefrom, and it will be appreciated that if the challenge request message is transmitted without errors, 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.

In addition, the information 1 may further include: the device 2 receives the device identification information 2 corresponding to the device 1, and the device identification information 2 may be used to uniquely identify the device 1. Specifically, the device Identification information 2 may be a device Identification (in english: identification, abbreviated as ID) 2 or a hash value of the device ID 2. The device 1 stores a device ID1 of the device 1 or a hash value of the device ID1, where 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 performing hash calculation on the device ID 1. For greater security, the device ID1 may be an identification of the device 1 that is not public to the outside. For example: the device ID1 may be a hardware unique key (english: hardware Unique Key, abbreviated: HUK) defined when the device 1 leaves the factory; also for example: the device ID1 may also be an identification obtained from a unique device identification (english: unique Device Identification, abbreviated: UDI) of the device 1 and a wafer identification (english: dieid) in the device 1. It can be seen that the authentication is performed by using the device ID1 or the hash value of the device ID1, so that the authentication authority of the device 2 can be effectively managed and controlled, that is, after an attacker or a user obtains the public key, only the device 1 can be attacked or used, the public key cannot be used for authenticating other devices and developing corresponding use authorities, so that the security risk is reduced to the minimum, and the security protection of the device is improved.

Furthermore, the information 1 may also comprise target validity information, which is used by the device 1 to determine whether the authentication can continue using the device 2. The target valid information may be, in particular, the maximum number of times (e.g., 5 times) that the device 2 is allowed to authenticate, or the maximum time (e.g., 1 day) that the device 2 is allowed to authenticate, so that the number of valid uses or the duration of the device 2 is limited with reference to the target valid information so that the device 2 is controlled to be used within a safe range.

If the device 1 needs to configure the authentication range, 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 right (e.g., access is available within 2 hours from the time of opening the use right), the interface of opening the use right (e.g., 3 debug interfaces on the device 1 are opened, or the debug interfaces 1 and 2 on the device 1 are opened), or the operation of opening the use right (e.g., allowing a read operation on the device 1 or allowing a write operation on the device 1). It should be noted that, according to the authentication requirement, the device 1 may not specify the authentication range, that is, the information 1 does not include the indication information, and the device 2 configures the authentication range, or neither configures the authentication range, and the usage rights of the device 1 are opened following the default authentication range set after one authentication pass.

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

In particular, when there is an access requirement for the device 1, and authentication needs to be performed on 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, for example: 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 represent the type of key pair that is currently used, for example: when the value of the key classification field is 0x07, it indicates that an authentication key pair is currently used, and for example: when the value of the key classification field is 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 in use, i.e. to indicate the key pair corresponding to the locally stored public key 1, for example: the authentication key pair can comprise 16 key pairs which are respectively distributed to different products or different interfaces for use, so that when one key pair is prevented from being leaked, the other key pair can be allowed to be used, and the generated influence range is not too large. The length of the challenge field can be used for signal verification to prevent the problems of information loss and the like of the challenge request message in the transmission process.

As another example, to increase the security level of authentication of the device 1, a field may be further added to the challenge request message for carrying at least one of a random number 1, a device ID1 and a hash value of 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 the random number 2, the device ID2, and the hash value of the device ID 2. If no error occurs in 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 yet another example, depending on the authentication needs of the device 1, other fields may be added in the challenge request message for carrying 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 target valid information; alternatively, on the basis, the information 1 may further include: at least one of the random number 2, the device ID2, and the hash value of the device ID 2.

Thus, 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 parsing 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, the device 2 may authenticate the device 1 with its own generated public-private key, and then the private key 1 may be generated and stored locally by the device 2 based on an internal algorithm. In this example, the device 2 also needs to transmit the public key 1 corresponding to the private key 1 to the device 1 before performing S105 described below, so that the device 1 saves the public key 1 in a 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 of private key 1 encryption, the random number 2 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.

In other possible implementations, to increase the security level, the device 2 may also apply for a public-private key pair from the device 3 for authentication of the device 1, and then the private key 1 may be the private key allocated by the device 3 to the device 2. The device 3 may be 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 or distributed to the device 3, the public key 1 and the private key 1 can be encrypted by the private key 2 on the device 3 and then sent to the device 2, so that the security is improved. In particular implementation, the process of sending the public-private key pair to the device 2 by the device 3 may include, for example: s21, the device 2 sends a request message to the device 3, and the request message is used for requesting the device 3 to send a public-private key pair for authenticating the device 1; s22, the device 3 determines the private key 1 and the corresponding public key 1 to be transmitted to the device 2 in response to the request message, and, in order to further improve security, the device 3 encrypts the private key 1 and the public key 1 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 to obtain the private key 1, and stores the private key 1 in a local safe storage space. In this example, the device 1 locally stores in advance the public key 2 corresponding to the private key 2 on the device 3, so that when the subsequent authentication is performed, the device 2 sends the public key 1 encrypted by the private key 2 to the device 1, 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, so as to provide a data base for the authentication.

It should be noted that, the manner in which the device 3 issues the public key 2 to the device 1, and the manner in which the device 3 may 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 in S23 and S24 may be determined according to whether the device 3 is an offline server or an online server. When device 3 is offline with respect to device 1, public key 2 may be copied from device 3 by the user via the secure production environment device and public key 2 may be configured onto device 1 via 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 via the connection established between the two. Similarly, when the device 3 is offline with respect to the device 2, the request message may be submitted on the device 3 by a user, who 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, and then 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 to 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 2 encrypted private key 1, and private key 2 encrypted public key 1 directly to device 2 over the connection established by both.

For S23 and S24, as an example, the device 3 may carry the public key 2, the private key 1 encrypted by the private key 2, and the public key 1 encrypted by the private key 2 in one message, and feed back to the device 2. As another example, for greater security, the device 3 may carry the public key 2 in one message, and 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 list of device identification information responsible for authentication, where the devices identified in the list may be the subject of 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 so, S102 is executed, otherwise, it is determined that the device 1 is not an object of authentication of the device 2, and the authentication is aborted.

It should be noted that, when the device identification information 2 included in the information 1 is the device ID2 or the hash value of the device ID2, in order to distinguish different devices 1 that all use the device 2 to perform authentication, S102 may encrypt the information 1 including the device ID2 or the hash value of the device ID2 and then send the encrypted information to the device 1, so that the different devices 1 determine whether to perform authentication on themselves based on the received encrypted device ID or the hash value of the device ID in the information 1; alternatively, S102 may also encrypt the remaining information 1 after eliminating the device ID2 or the hash value of the device ID2 in the information 1, and then send the encrypted information 1 to the device 1, that is, the information 1 does not include the device ID2 or the hash value of 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 the actual valid information, where the actual valid information is used to characterize the current situation of using the device 2 to authenticate the device 1. After receiving the information 1, the device 2 may update the actual usage information first, and then perform matching verification on the target valid information and the updated actual usage information, if matching (i.e., 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 fails, 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 perform authentication, the actual usage information is the actual number of times (for example: 3 times) that the device 1 stops currently using the device 2 to perform authentication, and when the device 2 receives the information 1 again, the actual number of times may be increased by one, and it is determined whether the new actual number of times is equal to or less than the target valid information, if yes, S102 is performed, otherwise, the authentication of the device 2 to the device 1 is stopped, and the device 2 is prompted to fail.

As another example, when the target effective information is the longest time (for example, 24 hours) for which authentication is allowed by the use device 2, the actual use information is the actual use time (for example, 10 hours) from the timing start time of the target effective information to the current time, when the device 2 receives the information 1 again, the update actual use time may be the time (for example, 12 hours) elapsed from the timing start time of the target effective information to the current time, and it may be determined whether the new actual use time reaches the target effective information, if not, S102 is executed, if yes, authentication of the use device 2 to the device 1 is stopped, and the device 2 is prompted to fail.

When the information 1 includes the target effective information, S102 may encrypt the information 1 including the target effective information and then send the encrypted information 1 to the device 1; alternatively, S102 may reject the target valid information in the information 1, encrypt the remaining information 1, and send the encrypted target valid information to the device 1, that is, the information 1 does not include the target valid information encrypted by the public key 1. Alternatively, the information 1 may also carry the updated actual usage information in the information 1, and send the updated actual usage 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 instruction information, the device 2 may encrypt the information 1 including the instruction information and send the encrypted information to the device 1; or if the information 1 includes the indication information, the device 2 can locally store the authentication range responsible for authenticating the device 1, after receiving the information 1, the device 2 can firstly perform matching verification on the indication information and the locally stored authentication range of the device 1, 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 an authentication range 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 as a part of the information 1 to the device 1; or, if the information 1 does not include the indication information and the device 2 does not locally store the authentication range responsible 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 use right of the device 1 according to the default setting thereon.

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

S104, the device 1 receives the information 1 encrypted with the private key 1 transmitted by the device 2.

In particular, 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: private key 2 encrypted public key 1, private key 1 encrypted challenge type, private key 1 encrypted random number 2, private key 1 encrypted key type, private key 1 encrypted key number, and private key 1 encrypted challenge field length.

As another example, for greater security, device 2 may also send device 1 separately from public key 1 encrypted by private key 2, with information 1 being sent to 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, the 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. Whereas the device 2 sends the public key 1 encrypted by the private key 2 to the device 1 by means of other messages than the message conveying the information 1.

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

If the information 1 includes the content of the challenge request message and the random number 2, the information 1 encrypted by the private key 1 in the response message may specifically include: the challenge type of private key 1 encryption, the random number 2 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.

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

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

It should be noted that, in addition to the content of the challenge request message itself, the information 1 may further include one or more of a random number 2, device identification information 2, and indication information. 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 method comprises the steps of encrypting a challenge type by a private key 1, encrypting a random number 2 by the private key 1, encrypting equipment identification information 2 by the private key 1, encrypting indication information by the private key 1, encrypting a key type by the private key 1, encrypting a key number by the private key 1 and encrypting a challenge field length by the private key 1.

Thus, the device 2 obtains the information 1 encrypted by the device 2 by using its private key 1 by sending a response message to the device 1, after the device 1 receives the response message, and by parsing the response message, a data basis is provided for 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: 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 content of the challenge request message obtained after decryption and the content of the locally stored challenge request message can be compared, if the content of the challenge request message is consistent with the content of the locally stored challenge request message, the use authority of the open device 1 is determined, otherwise, the authentication failure of the device 1 is determined; alternatively, if the device 1 does not store the content of the challenge request message itself locally, S105 to S106 may specifically be: the authentication passing of the device 1 can be determined as long as the public key 1 is adopted for decryption to obtain the information 1, and the use authority of the device 1 is opened, otherwise, the authentication failure of the device 1 is determined.

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 locally stored random number 1 is consistent with the random number 2 in the information 1, if so, the use authority of the open device 1 is determined, otherwise, the authentication failure of the device 1 is determined.

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 equipment 1 judges whether the locally stored equipment identification information 1 is consistent with the equipment identification information 2 in the information 1, if so, the use authority of the equipment 1 is opened, otherwise, the authentication failure of the equipment 1 is determined.

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

It should be noted that, in addition to the content of the challenge request message itself, the information 1 may further include one or more of a random number 2, device identification information 2, and indication information. For example: when the information 1 includes the content of the challenge request message itself, the instruction information, the random number 2, and the set identification information 2, for S106, it may be specifically: the equipment 1 judges whether the locally stored random number 1 is consistent with the random number 2 in the information 1, if not, the authentication of the equipment 1 is determined to be failed; if the device identification information 1 is consistent with the set identification information 2 in the locally stored device identification information 1, continuing to judge whether the device identification information 1 is consistent with the set identification information 2 in the locally stored device identification information 1, and if the device identification information is inconsistent with the set identification information 2, determining that the authentication of the device 1 fails; if so, taking the indication information carried by the challenge request message stored locally in the equipment 1 as an example, continuously comparing whether the indication information obtained after decryption is consistent with the indication information stored locally, and if not, determining that the authentication of the equipment 1 fails; if the information is consistent, 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 consistent, the network device opens the use rights of all the interfaces thereon; or, when there is an inconsistency in the result of each comparison process in S106, the network device does not open the use authority of any one of the interfaces thereon. As another example, the information 1 further carries indication information, for example: if the results of the comparison processes in S106 are identical, the network device may open the corresponding usage rights according to the indication information, for example: opening the use authority of the debug interface corresponding to the debug interface ID; or, when there is an inconsistency in the result of each comparison process in S106, the network device does not open the use authority of any one of the interfaces thereon.

The device 1 may also refer to a debug interface or a service interface on a certain device, where when the results of the comparison processes in S106 are consistent, the device may open the usage rights of the corresponding debug interface or service interface on the device. When there is an inconsistency in the result of each comparison process in S106, the device may not open the use authority of the debug interface or the service interface.

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

In some specific implementations, for the scenario that the device 3 configures the public-private key for the device 2 to have a higher security level, the device 3 is used as an absolute security device, and has the capability of updating the public-private key of the device 3 itself and canceling the public-private key allocated for the device 2, so that the authentication of the device 1 using the authentication tool of the device 2 is more flexible and controllable.

As an example, when the device 3 determines that the public key 2 and the private key 2 are not secure enough, and a certain potential safety hazard may exist, it determines that the public key 2 and the private key 2 are invalid, and the embodiment of the present application may further include: s31, enabling the private key 4 and the corresponding public key 4 by the device 3; 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 private 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 adopts the public key 4 to decrypt the private key 1 by adopting the private key 4 respectively, and the private key 1 is obtained and stored in a local safe storage space of the device 2; s35, the device 1 transmits a challenge request message to the device 2; s36, the device 2 sends a response message 1 to the device 1, where the response message 1 includes at least: the value of the challenge type field in the response message 1 is used to instruct the device 1 to update the public key corresponding to the device 3 stored thereon, for example: the value of challenge type field = 0x55AA555A; s37, the device 1 deletes the public key 2 or sets the public key 2 as the forbidden public key, and correspondingly saves the public key 4. In this way, the device 3 enables an update of the public key stored on the device 1, making it possible to control the authentication of the device 1 more secure and reliable.

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 a certain potential safety hazard may exist, it determines that the public key 1 and the private key 1 are invalid, and the embodiment of the present application may further include: s41, the device 3 redistributes the private key 3 and the corresponding public key 3 to the device 2; s42, the device 3 adopts the private key 2 to encrypt the public key 3 and the private key 3 respectively; s43, the device 3 configures the public key 2, the public key 3 respectively by adopting the private key 2 and the private key 3 respectively by adopting the private key 2 to the device 2; s44, the device 2 adopts the public key 2 to decrypt the private key 3 by adopting the private key 2, and the private key 3 is obtained and stored in a local safe storage space of the device 2. In this way, the device 3 enables the revocation and updating of the public and private keys used for authentication on the device 2, so that the device 2 can authenticate the device 1 more securely and reliably.

As yet another example, when the device 3 determines that the public key 2 and the private key 2 thereof are not secure enough, and the public key 1 and the private key 1 allocated by the device 3 to the device 2 are not secure enough, and a certain potential safety hazard may exist, it is determined that the public key 2, the private key 2, the public key 1 and the private key 1 are invalid, and the embodiment of the present application may further include: s51, the device 3 starts the user private key 4 and the corresponding public key 4, and redistributes the private key 3 and the corresponding public key 3 to the device 2; s52, the device 3 adopts the private key 4 to encrypt the public key 3 and the private key 3 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 adopts the public key 4 to decrypt the private key 3 by adopting the private key 4 respectively, and the private key 3 is obtained and stored in a local safe storage space of the device 2; s55, the device 1 transmits a challenge request message to the device 2; s56, the device 2 sends a response message 2 to the device 1, where the response message 2 includes at least: the value of the challenge type field in the response message 2 is used to instruct the device 1 to update the public key corresponding to the device 3 stored thereon; s57, the device 1 deletes the public key 2 or sets the public key 2 as the forbidden public key, and correspondingly saves the public key 4. In this way, the device 3 implements an update to the public key stored on the device 1, and a revocation and update to the public and private keys used for authentication on 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 present application, the device 1 to be authenticated sends the information 2 to the device 2 with the authentication function, such as the authentication tool; the device 2 encrypts the received information 1 based on the private key 1 and transmits the information 1 encrypted by the private key 1 to the device 1; the device 1 decrypts the public key 1 to obtain the information 1 and determines the usage rights of the device 1 by comparing the information 1 with the locally stored information 2. Thus, through encryption and decryption technology and equipment 2 special for authenticating equipment 1, the authentication of equipment 1 to be authenticated by equipment 2 is realized, the potential safety hazard existing when equipment 1 is protected in the current mode of exposing corresponding bonding pads through a codebook or an interface and the like is overcome, and the protection of equipment 1 to be authenticated is ensured to be safer and more reliable.

For the sake of more clarity and details of the embodiment of the present application, in the following, in the scenario shown in fig. 1, the authentication procedure in the embodiment of the present application will be specifically described with reference to fig. 4, 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.

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

S201, the user 14 submits a request message on the CA server 13, which requests the CA server 13 to assign a public-private key to the authentication tool 11.

In this embodiment, the user 14 may be a safe 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 with its own private key d, respectively.

S204, the CA server 13 configures the public key D corresponding to the private key D to the exchange 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 with 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 exchange.

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 adopts the public key B to decrypt the information in the response message 1 to obtain X2, wherein the X2 is obtained by decrypting the X2 encrypted by the private key B by the public key B.

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

S215, the switch opens the use authority of the debug interface 12.

S216, the switch determines to suspend the authentication flow and reports the authentication error to the CA server 13.

In this way, in this embodiment, through the encryption and decryption technology, the higher security level server, namely the CA server 13, and the interaction between the authentication tool 11 and the switch, which is specially used for authenticating the switch, the management of the authentication tool 11 on the use authority of the debug interface 12 on the switch 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 according to 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 authentication method 300 includes, for example:

S301, receiving first information encrypted by a first private key and sent by second equipment;

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

s303, carrying out 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, 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. Alternatively, the first device may 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 is passed, the first device opens the corresponding use right, and when the verification result indicates that the verification is not passed, the first device does not open the corresponding use right. Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

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 by the authentication server for the second device.

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

As one 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 equipment receives a response message sent by the second equipment, 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 carrying out matching verification on the first random number and the second random number. The first random number can uniquely identify one-time authentication of the first equipment, and the random number is used for authentication, so that each authentication can be performed based on the random number generated at the time, information of the first equipment 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, and then S303 may specifically further include: and carrying out 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, and S303 may specifically further include: and carrying out matching verification on the first equipment ID and the second equipment ID. As another example, 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, and S303 may specifically include: and carrying out matching verification on the hash value of the first equipment ID and the hash value of the second equipment ID. For the security of authentication, in the embodiment of the present application, the device ID is a non-public 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, and for example: the first device ID is processed according to a wafer identification die ID and a unique device identification UDI of the first device. In this way, the first device is reliably and safely authenticated by verifying the second device ID or the hash value of the second device ID obtained after decryption through the first device ID or the hash value of the first device ID locally stored by the first device.

As yet 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 current authentication on the first device using the second device. Then S303 may specifically further include: and the first device verifies the actual use information according to the target effective information to determine whether the second device can be continuously used for authenticating the first device. 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 used for authenticating the first device; otherwise, when the first device determines that the actual usage information has reached the target valid information, it is determined that the second device has failed for the first device, and the second device cannot be used for authenticating the first device. Wherein the target validity information is the maximum number of times (e.g., 5 times) authentication is allowed using the second device; alternatively, the target validity information is the maximum time (e.g., 20 hours) that the second device is allowed to authenticate. In this way, the actual use information carried in the first information is verified through the target effective information locally stored in the first device, so that the first device is reliably and safely authenticated.

As still another example, the first information may further include indication information for indicating at least one of the following information: the time of opening the use right, the interface of opening the use right or the operation of opening the use right. The indication information can be corresponding indication information which is sent to the second device by the first device in the challenge request message or specified by the second device according to the authentication range of the second device; the first device may also send corresponding indication information to the second device in the challenge request message, where the indication information is determined by the second device according to the authentication range of the second device. In this way, the indication information obtained after the first device receives and decrypts the indication information can realize reliable and safe authentication of the first device.

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

Fig. 6 is a flowchart of a method 400 for authenticating a usage right of a first device according to 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 taken as an execution body, and the method 400 may include:

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

and S402, the first information encrypted by the first private key is sent to the first device so as 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. Alternatively, the second device may be the authentication tool 11 in the method 200, and 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.

Thus, 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 by the mode of exposing the corresponding bonding pad of the codebook or the interface and the like at present is overcome, and the safer and more reliable protection of the first equipment to be authenticated is ensured.

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 by the authentication server for the second device.

As one example, the method 400 may further include: the second device receives 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; 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 locally stored second public key to obtain the first public key.

As another example, the first information includes a first random number, and then, prior to S401, the method 400 may specifically 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 device sends a response message to the first device, 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 first information and further include first device identification information, the first device identification information being used by the first device for authentication, for example: may be the first device ID or a hash value of the first device ID. The method 400 may further include: the second device performs matching verification on the first device ID and a locally stored second device ID corresponding to the first device; or the second device performs matching verification on the hash value of the first device ID and the hash value of the second device ID which is stored locally and corresponds to the first device. The first equipment ID is a hardware unique key HUK defined when the first equipment leaves a factory, or is obtained by processing according to a wafer identification die ID and a unique equipment identification UDI of the first equipment.

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

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

It should be noted that, the specific implementation manner and the achieved effect of the method 400 in the embodiment of the present application may be referred to the above description of the embodiments shown in fig. 3, fig. 4, and fig. 5.

The application further provides a first device 700, see fig. 7. The first device 700 comprises a transceiver unit 701 and a processing unit 702. The transceiver unit 701 is configured to perform the transceiver operation performed by the device 1 in the embodiment shown in fig. 3, or the transceiver operation performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or the transceiver operation performed by the first device in the method embodiment shown in fig. 5; the processing unit 702 is configured to perform operations other than the transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or operations other than the transceiving operation performed by the debug interface 12 of the switch in the embodiment shown in fig. 4, or operations other than the transceiving operation performed by the first device in the method embodiment shown in fig. 5. For example: the first device 700 is device 1 in the method 100, and then the transceiver unit 701 is configured to receive the information 1 encrypted with the private key 1 sent by the device 2; the processing unit 702 is configured to decrypt 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 and determine the usage rights of the device 1.

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

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

In addition, the embodiment of the application also provides a second device 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 operations other than the transceiving operation performed by the device 2 in the embodiment shown in fig. 3, or operations other than the transceiving operation performed by the authentication tool 11 in the embodiment shown in fig. 4, or operations other than the transceiving operation performed by the second device in the method embodiment 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 the 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 application also 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 to cause the first device 1100 to perform 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 method embodiment shown in fig. 5.

In addition, the embodiment of the application also provides a second device 1200, which is shown in fig. 12. The second device 1200 includes a memory 1201 and a processor 1202. Wherein the memory 1201 is used for storing program codes; the processor 1202 is configured to execute instructions in the program code to cause the second device 1200 to perform 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 will be appreciated that in the above embodiments, the processor may be a central processor (English: central processing unit, abbreviated: CPU), a network processor (English: network processor, abbreviated: 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 (English: programmable logic device). The PLD may be a complex programmable logic device (English: complex programmable logic device, abbreviated: CPLD), a field programmable gate array (English: field-programmable gate array, abbreviated: FPGA), a general-purpose array logic (English: generic array logic, abbreviated: GAL), or any combination thereof. A processor may refer to one processor or may include multiple processors. The memory may include volatile memory (english) such as random-access memory (RAM); the memory may also include a nonvolatile memory (english: non-volatile memory), such as a read-only memory (ROM), a flash memory (english: flash memory), a hard disk (HDD) or a Solid State Disk (SSD); the memory may also comprise a combination of the above types of memories. The memory may be one memory or may include a plurality of memories. In one embodiment, the memory stores computer readable instructions comprising a plurality of software modules, such as a transmit module, a process module, and a receive module. After executing each software module, the processor can perform corresponding operation according to the instruction of each software module. In this embodiment, the operation performed by one software module actually refers to an operation performed by a processor according to an instruction of the software module. After executing the computer readable instructions in the memory, the processor may perform all operations that the first device or the second device may perform as indicated by the computer readable instructions.

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

In addition, the embodiment of the 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, the embodiment of the present application further provides a computer readable storage medium, where instructions are stored, when the computer readable storage medium runs on a computer, to cause the computer to perform the authentication method in the embodiments shown in fig. 3 to 6.

Furthermore, embodiments of the present application provide a computer program product which, when run on a computer, causes the computer to perform the authentication method described in the embodiments shown in the foregoing fig. 3-6.

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

From the above description of embodiments, it will be apparent to those skilled in the art that all or part of the steps of the above described example methods may be implemented in software plus general hardware platforms. 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, etc., and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network communication device such as a router) to perform the method according to the embodiments or some parts of the embodiments of the present application.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments and apparatus embodiments, since they are substantially similar to method embodiments, the description is relatively simple, with reference to the description of method embodiments in part. The above-described apparatus and system embodiments are merely illustrative, in which the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed across multiple network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present application without undue burden.

The foregoing is merely a preferred embodiment of the present application and is not intended to limit the scope of the present application. It should be noted that modifications and adaptations to the present application may occur to one skilled in the art without departing from its scope.

Claims

1. An authentication method, characterized in that it is implemented by a first device, which is a device to be authenticated, comprising:

transmitting second information to second equipment, wherein the second equipment is an authentication tool with an authentication function, the second information comprises indication information, and the indication information is used for indicating at least one of the following information: the time of opening the use permission or the interface of opening the use permission or the operation of opening the use permission;

receiving first information which is sent by the second equipment and is encrypted by adopting a first private key, wherein the first information corresponds to the second information, and the first information comprises the indication information;

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

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

If the verification result represents that verification is passed, opening the corresponding use permission of the first equipment based on the indication information;

and if the verification result characterizes that the verification is not passed, the use authority of the first device is not opened.

2. The method of claim 1, wherein the step of determining the position of the substrate comprises,

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

or alternatively, the process may be performed,

the first private key and the first public key are configured for the second device for an 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 transmitted by the second equipment and is encrypted by a second private key of the authentication server;

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 of claim 1 or 2, wherein the second information comprises a first random number, and wherein prior to the receiving the first information transmitted by the second device encrypted with the first private key, 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 the first information encrypted by the first private key and 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 comprises:

and carrying out matching verification on the first random number and the second random number.

5. The method according to claim 1 or 2, 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 between the first information and the locally stored second information further includes:

and carrying out matching verification on the first equipment identification information and the second equipment identification information.

6. The method of claim 5, wherein the step of determining the position of the probe is performed,

the first equipment identification information is a first equipment identification ID, and the second equipment identification information is a second equipment ID; or alternatively

The first equipment identification information is a hash value of a first equipment ID, and the second equipment identification information is a hash value of a second equipment ID.

7. The method of claim 6, wherein the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or wherein 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 claim 1 or 2, 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 the first device that the second device is currently used for authentication, 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 effective information to determine whether the second equipment can be continuously used for authenticating the first equipment.

9. The method of claim 8, wherein the step of determining the position of the first electrode is performed,

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

or alternatively, the process may be performed,

the target validity information is the longest time allowed for authentication using the second device.

10. The method of claim 1 or 2, wherein the first device is a debug interface.

11. A method of authenticating a right to use a first device, implemented by a second device, the second device being an authentication tool having an authentication function, comprising:

receiving first information from the first device, wherein the first device is a device to be authenticated, and the first information comprises indication information, and the indication information is used for indicating at least one of the following information: the time of opening the use permission or the interface of opening the use permission or the operation of opening the use permission;

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

the first information encrypted by the first private key is sent to the first device so as to authenticate the use right of the first device, the first device locally stores second information and a first public key, the first public key corresponds to the first private key, the second information is used for carrying out matching verification on the first information obtained by decrypting the first public key, the first device is instructed to open the corresponding use right based on the instruction information when the matching verification is passed, and the first device is instructed not to open the use right when the matching verification is not passed.

12. The method of claim 11, wherein the method further comprises:

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;

the first public key encrypted by the second private key is sent to the first device.

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

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.

14. The method according to claim 11 or 12, wherein,

the first information includes first device identification information, which is used by the first device for authentication.

15. The method of claim 14, wherein the first device identification information is a first device identification ID or a hash value of the first device ID.

16. The method of claim 15, wherein the first device ID is a hardware unique key HUK defined when the first device leaves the factory, or wherein the first device ID is processed according to a wafer identification die ID and a unique device identification UDI of the first device.

17. The method of claim 11 or 12, wherein the first information further comprises target validity information, the target validity information being used by the first device to determine whether authentication with the second device can continue.

18. The method of claim 17, wherein the step of determining the position of the probe is performed,

or alternatively, the process may be performed,

19. The method of claim 11 or 12, wherein the first device is a debug interface.

20. A first device, comprising:

a communication interface; and

a processor connected 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-10 or 19.

21. A second device, comprising:

a communication interface; and

a processor connected to the communication interface;

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

22. A first device comprising a memory and a processor;

the memory is used for storing program codes;

the processor for executing instructions in the program code to cause the first device to perform the method of any of the preceding claims 1-10 or 19.

23. A second device comprising a memory and a processor;

the memory is used for storing program codes;

the processor being operative to execute instructions in the program code to cause the second device to perform the method of any one of the preceding claims 11-19.

24. A computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of any of the preceding claims 1-19.

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