CN111147259A

CN111147259A - Authentication method and device

Info

Publication number: CN111147259A
Application number: CN201911370614.8A
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: 2020-05-12
Anticipated expiration: 2039-12-26
Also published as: WO2021128988A1; CN111147259B

Abstract

The embodiment of the application discloses an authentication method and equipment, wherein a first certificate is generated for a first device to be authenticated by second devices with a certificate issuing function, such as a CA server and the like, and is digitally signed based on a first private key, after the first device obtains the digitally signed first certificate, the digitally signed certificate is verified to obtain a first verification result, and the use permission of the first device is authenticated based on the first verification result. Therefore, the authentication of the first equipment to be authenticated is realized through the second equipment with the certificate issuing function and the digital signature function and the higher security level through the digitally signed first certificate, the potential safety hazard existing when the first equipment is protected to be safe through a password book and other modes at present is overcome, and the access and the use of the first equipment are ensured to be safer and more reliable.

Description

Authentication method and device

Technical Field

The present application relates to the field of secure communication technologies, and in particular, to an authentication method and device for authenticating a device or an interface on the device when the device or the interface on the device has a requirement for opening a use permission.

Background

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

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

Disclosure of Invention

Based on this, the embodiment of the present application provides an authentication method and apparatus, and a method and apparatus for authenticating a usage right of a first device, where a mode that an apparatus such as a Certificate Authority (CA) server with a higher security level digitally signs a certificate and the apparatus to be authenticated verifies the integrity of the signed certificate is used to implement safer authentication of the apparatus to be authenticated.

In a first aspect, an authentication method is provided, which is applied in a scenario including a first device and a second device, and takes the first device as an execution subject, and the authentication method may include: the first device obtains the first certificate digitally signed by the first private key from the second device, i.e. the first certificate can be verified to obtain a first verification result, and then the first device can determine the use permission of the first device according to the first verification result. Specifically, when the first verification result indicates that the verification passes, the first device opens the corresponding usage right, and when the first verification result indicates that the verification fails, the first device does not open the corresponding usage right. Therefore, the first certificate is digitally signed by the second equipment with a certificate issuing function and a digital signature function and higher security level, the first certificate after the digital signature is verified by the first equipment to be authenticated, the authentication of the first equipment to be authenticated is realized, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be safer and more reliable through the certificate issued by the second equipment with high security level and the digital signature technology.

Wherein the first device may be any device to be authenticated, for example: may refer to a network device or a board, for example: but also to a debug interface or a service interface on the device. The second device may refer to an authentication server with a higher security level and having a certificate issuing function and a digital signature function, for example: a Certificate Authority (CA) server. When the first device is a debugging interface and the second device is a CA server, the CA server issues a certificate which is digitally signed and then is issued to the device where the debugging interface is located, and after the certificate passes verification, the device where the debugging interface is located opens the use permission of the debugging interface for accessing and using the debugging interface.

Optionally, the verifying the first certificate by the first device may specifically include: and the first equipment verifies the first certificate according to a locally stored first public key corresponding to the first private key. The method specifically comprises two parts of integrity verification and validity verification of a first certificate, wherein a first device receives the first certificate and a signature of the first certificate, the first device can decrypt the received signature through a first public key to obtain a first abstract, the first device can also calculate a hash value of the received first certificate and record the hash value as a second abstract of the first certificate, the first device determines a first verification result of the first certificate through matching verification of the first abstract and the second abstract, and when the first abstract and the second abstract are matched, the first verification result represents that the first certificate is verified to pass; when the first digest and the second digest do not match, the first verification result indicates that the verification of the first certificate is not passed. Therefore, the certificate is verified through the public key locally stored in the first equipment, the first equipment is guided to manage the use authority of the first equipment, and the reliable and safe authentication of the first equipment is realized.

Optionally, the first certificate may include a certificate type, and the first device verifies the first certificate, which may further include: the certificate type is verified. If a field for indicating the certificate type of the first certificate is expanded in the expanded domain of the first certificate, the first device may read the field, and when it is determined that the field indicates that the first certificate is an authentication certificate, the first verification result may represent that the first certificate passes verification; otherwise, when it is determined that the field indicates that the first certificate is not an authentication certificate, the first verification result may indicate that the verification of the first certificate is not passed. In this way, the first device may also guide the first device to manage its usage right through verification of the certificate type of the received first certificate, thereby implementing reliable and secure authentication of the first device.

Optionally, the first certificate may further include first device identification information, and then verifying the first certificate may further include: and matching and verifying the first equipment identification information carried by the first certificate based on locally stored second equipment identification information of the first equipment, wherein the second equipment identification information is used for uniquely identifying the first equipment. As an example, the first device Identification information may be a first device Identification (ID), and the first device verifies the first certificate, and may further include: and the first equipment carries out matching verification on the first equipment ID carried by the first certificate based on a second equipment ID of the first equipment, which is locally stored, wherein the second equipment ID is used for uniquely identifying the first equipment. As another example, for security, the first device identification information may also be a hash value of the first device ID, and then the first device verifies the first certificate, which may further include: and the first device performs matching verification on the hash value of the first device ID carried by the first certificate based on the locally stored hash value of a second device ID of the first device, wherein the second device ID is used for uniquely identifying the first device. Wherein the first certificate may extend in its extension field a field for carrying the first device ID or a hash value of the first device ID. It should be noted that, in order to perform security authentication, in the embodiment of the present application, the device ID is an ID that is not public and can uniquely identify the device, for example: the second device ID is a Hardware Unique Key (HUK) defined when the first device leaves the factory, for example: the second Device ID is obtained by processing according to a wafer ID (die ID) and a Unique Device ID (UDI) of the first Device. Therefore, the first device ID or the hash value of the first device ID carried in the first certificate is verified through the second device ID or the hash value of the second device ID locally stored by the first device, so as to guide the first device to manage the use authority of the first device, and realize reliable and safe authentication of the first device.

Optionally, the first certificate may further include a first certificate identification ID, and the first device verifies the first certificate, which may further include: and the first equipment carries out matching verification on the first certificate ID according to the second certificate ID stored locally. Wherein the first certificate may extend a field in its extension field for carrying the first certificate ID. In one case, when the first device does not use the first certificate for authentication, the first device does not locally store the certificate ID of the first certificate, and in this case, when the first device determines that the first certificate ID is not locally stored, that is, the matching verification of the first certificate ID is considered to be passed, the first certificate may be used for authentication. In another case, when the first device has used the first certificate for authentication, the first device locally stores the second certificate ID of the first certificate, and in this case, when the first device determines that the locally stored second certificate ID matches the first certificate ID in the first certificate, that is, the matching verification of the first certificate ID is considered to be passed, the first certificate may be used for authentication. In another case, when the first device has used the first certificate for authentication, the first device locally stores the second certificate ID of the first certificate, but since the number of times the first certificate is used exceeds the upper limit or the time of use of the first certificate exceeds the upper limit, the second certificate ID is marked as a failed state, in this case, when the first device determines that the locally stored second certificate ID matches the first certificate ID in the first certificate, but the state of the second certificate ID is failed, it is considered that the matching verification of the first certificate ID is not passed, and the first certificate cannot be reused for authentication of the first device. Therefore, the first certificate ID carried in the first certificate is verified through the second certificate ID locally stored by the first equipment, so that the first equipment is guided to manage the use authority of the first equipment, and the reliable and safe authentication of the first equipment is realized.

Optionally, the first certificate may also include target validity information, which is used by the device 1 to determine whether authentication using certificate 1 can be continued. Then, the first device verifying the first certificate may further include: the first device verifies the target valid information according to actual use information, wherein the actual use information is used for representing the condition that the first certificate is currently used on the first device. If the target valid information is the maximum number of times (for example, 5 times) that the first certificate is allowed to be used for authentication, the actual use information is the actual use number of times that the first device is authenticated by using the first certificate at present; or the target valid information is the longest time (for example, 20 hours) allowed for authentication using the first certificate, the actual usage information is the actual usage time from the starting time of the timer of the target valid information to the current time. Wherein the first certificate may extend a field for carrying the target valid information in its extension field. As an example, when the first device determines that the locally stored actual usage information reaches the target valid information of the first certificate, the first device may revoke the first certificate, such as: and marking the second certificate ID corresponding to the first certificate stored locally in the first equipment as invalid. Therefore, the target effective information carried in the first certificate is verified through the actual use information locally stored in the first equipment, the first equipment is guided to manage the use authority of the first equipment, and the first equipment is authenticated reliably and safely.

Optionally, the first certificate may further include a second public key, and the first device verifies the first certificate, which may further include: and the first equipment verifies the second public key according to the locally stored first public key. If the first device determines that the first public key and the second public key are inconsistent, the first device regards as the second device that the first public key and the first private key that are not secure enough need to be updated, and then, the embodiment of the present application may further include: the first device replaces the locally stored first public key with the second public key. Thus, the second public key carried in the first certificate is verified through the first public key locally stored by the first equipment, and when the public keys are consistent, the first equipment is guided to manage the use authority of the first equipment, so that the reliable and safe authentication of the first equipment is realized; and when the public keys are inconsistent, the first equipment is guided to update the locally stored public key, and the update of the authentication public key and the authentication private key by the second equipment is completed, so that the subsequent authentication on the first equipment is safer.

In a second aspect, an embodiment of the present application further provides a method for authenticating a usage right of a first device, which is implemented by a second device, and for example, the method may include: the second equipment carries out digital signature on the first certificate by adopting a first private key, wherein the first private key and the first certificate are generated by the second equipment for authenticating the first equipment; and the second device sends the first certificate digitally signed by the first private key to the first device to authenticate the use authority of the first device. Therefore, the first certificate is digitally signed by the second equipment with a certificate issuing function and a digital signature function and higher security level, and the digitally signed first certificate is sent to the first equipment to be authenticated, so that the first equipment verifies the digitally signed first certificate, the authentication of the first equipment to be authenticated is realized, the potential safety hazard existing when the first equipment is protected to be safe in the mode that a password book or an interface corresponding to a pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be more safe and reliable in protection through the certificate issued by the second equipment with high security level and the digital signature technology.

Wherein the first device may be any device to be authenticated, for example: the second device may be an authentication server.

Optionally, in this embodiment of the application, the first certificate may further include first device identification information, where the first device identification information is used by the first device for identity authentication. For example: the first device identification information may be the first device ID or a hash value of the first device ID. Then, the embodiment of the present application may further include: the second equipment receives a certificate request message, wherein the certificate request message comprises a first equipment identification ID; and the second equipment carries out matching verification on the first equipment ID according to the second equipment ID stored locally. Or the second device receives a certificate request message, wherein the certificate request message comprises a hash value of the first device identification ID; and the second equipment carries out matching verification on the hash value of the first equipment ID according to the locally stored hash value of the second equipment ID. After the matching verification is passed, the second device may also carry the first device ID or the hash value of the first device ID in the first certificate, and send the first certificate to the first device. In the embodiment of the present application, the device ID is an ID that is not public and can uniquely identify the device, for example: the first device ID is a hardware unique key HUK defined when the first device is shipped, for example: the first device ID is processed from the wafer identification die ID and the unique device identification UDI of the first device. In this way, the second device verifies the first device ID or the hash value of the first device ID carried in the certificate request message through the locally stored second device ID or the hash value of the second device ID, and instructs the second device whether to issue the first certificate to the first device, so that the authentication of the first device is more reliable and safer.

In this embodiment of the present application, the first certificate may further include target valid information, where the target valid information is used by the first device to determine whether to continue to use the first certificate for authentication. For example: the target valid information may specifically be the maximum number of times that the authentication is allowed using the first certificate, or the target valid information may also be the maximum time that the authentication is allowed using the first certificate. Then, the embodiment of the present application may further include: the second device receives the certificate request message, which may also include target valid information.

Optionally, the first certificate may further carry at least one of a certificate type, first device identification information, and a first certificate ID. For the content specifically carried in the first certificate and the way of verifying the first certificate by the corresponding first device, refer to the relevant description of the first aspect.

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

In a third aspect, the present application further provides a first device, including a transceiver unit and a processing unit. Wherein, the transceiver unit is configured to perform transceiving operation in the method provided by the first aspect; the processing unit is configured to perform other operations than the transceiving operation in the first aspect. For example: when the first device executes the method of the first aspect, the transceiving unit is configured to obtain a first certificate digitally signed with a first private key; the processing unit is used for verifying the first certificate to obtain a first verification result; the processing unit is further used for determining the use authority of the first device according to the first verification result.

In a fourth aspect, an embodiment of the present application further provides a second device, where the second device includes a transceiver unit and a processing unit. Wherein, the transceiver unit is used for executing the transceiving operation in the method provided by the second aspect; the processing unit is configured to perform other operations than the transceiving operation in the second aspect described above. For example: when the second device executes the method of the second aspect, the transceiving unit is configured to send a first certificate digitally signed by a first private key to the first device; the processing unit is configured to digitally sign the first certificate using a first private key.

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

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

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

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

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

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

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

Drawings

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

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

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

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

FIG. 4a is a diagram illustrating a certificate in an embodiment of the present application;

FIG. 4b is a diagram illustrating a digitally signed certificate from the certificate of FIG. 4a in an embodiment of the present application;

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

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

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

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

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

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

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

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

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

fig. 14 is a schematic structural diagram of a communication system 1400 in the embodiment of the present application.

Detailed Description

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

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

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

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

Based on this, the embodiment of the present application provides an authentication method, when a user needs to access a first device, the first device needs to perform authentication, and after the authentication is passed, a corresponding usage right on the first device may be opened, so that the user can safely access the first device within an opened usage right range. The authentication process may specifically include: a second device with a Certificate issuing function, such as a Certificate Authority (CA) server, generates a first Certificate for a first device to be authenticated, and digitally signs the first Certificate based on a first private key, so that when the first device obtains the digitally signed first Certificate, the digitally signed Certificate can be verified to obtain a first verification result, and the usage right of the first device is authenticated based on the first verification result. And when the first verification result shows that the verification is passed, the first device opens the corresponding use authority, and when the first verification result shows that the verification is not passed, the first device does not open the corresponding use authority. Therefore, the first certificate is digitally signed by the second equipment with a certificate issuing function and a digital signature function and higher security level, the first certificate after the digital signature is verified by the first equipment to be authenticated, the authentication of the first equipment to be authenticated is realized, the potential safety hazard existing when the first equipment is protected in the mode that a password book or an interface corresponding to a pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be safer and more reliable through the certificate issued by the second equipment with high security level and the digital signature technology.

The digital signature technology can be regarded as the combination of a digital digest technology and a public-private key technology, can verify whether the certificate is tampered or not through the digital digest technology, can verify whether the digital digest is legal or not through the public-private key technology, and is a technology capable of providing rapid and comprehensive integrity protection and verification for the certificate. A digital signature typically includes a pair of keys, one key for signing a digital digest of a certificate, message, etc., and the other key for verifying the signature of the certificate, message, etc. As an example, assume that the digital signature process for certificate X may include the following two processes: the first process, signing the digital digest of the certificate X, that is, before the certificate X goes down from the CA server to the device Y, the CA server may first obtain the digest X1 of the digital digest of X through the hash algorithm, and then obtain the digestEncode X1 by digitally signing the digest X1 with the private key a; including X and digestEncode X1 sent to device Y when the certificate X is dropped onto device Y; the second process, verifying certificate X, specifically includes: the device Y verifies the digestEncode X1 with the public key a to obtain a digestDecode X3, then calculates the digital digest of X by using the same hash algorithm as that used for digital signature, and generates a digital digest X2, and if the digestDecode X3 is the digest X2, it can be determined that the certificate X is complete (i.e., the certificate X is not tampered with) and legal (i.e., the certificate X is issued by a legal manufacturer), thereby ensuring that the access to the device Y is safe and reliable. The private key a and the public key a are a pair of keys provided by a CA server corresponding to the manufacturer of the device Y, the public key a is publicly visible, and the private key a is secret and only visible to the CA server. Therefore, the security level of the CA server is high, so that the certificate issued by the CA server and the digital signature technology are adopted for digitally signing the certificate in the embodiment of the application, and the device to be authenticated is a high-security-level security protection measure.

For example, one of the scenarios in the embodiment of the present application may be applied to a network as shown in fig. 1. Referring to fig. 1, the network includes: CA server 11, device 12 and user 13. The CA server 11 may be a secure, authoritative, and sufficiently trusted server corresponding to the manufacturer of the device 12, the CA server 11 may generate, distribute, and manage certificates corresponding to the devices of the manufacturer, and the CA server 11 may also be used as a signing system for the devices of the manufacturer to digitally sign certificates that are going to be sent to the devices. The device 12 may be any device that requires authentication, such as: the device 12 may be a network device such as a router and a switch, a terminal device such as a mobile phone and a notebook computer, a mobile storage device such as a usb disk, a debugging interface, a service interface, or a single board. The user 13 may specifically be a manager of the device 12, or the user 13 may also be an automation tool of the device 12 in a safety production line, and is configured to automatically execute all operations that can be performed by the user 13.

In specific implementation, the CA server 11 pre-generates a public and private key pair of the device 12: private key a and public key a, which device 12 obtains and stores in a local secure storage area. When access to the device 12 is required, the authentication process for the device 12, see fig. 2, may include: s11, the user 13 submits a certificate request message corresponding to the device 12 on the CA server 11; s12, the CA server 11 responds to the certificate request message to generate a certificate X, and digitally signs the certificate X based on the private key a to obtain the signature 1 of the certificate X; s13, user 13 obtains certificate X and signature 1; s14, the user 13 configures the certificate X and signature 1 onto the device 12; s15, device 12 verifies certificate X with public key a, the verification passing indicates that the authentication of device 12 passes, otherwise, the verification failing indicates that the authentication of device 12 fails. In this way, a more secure protection of the device 12 to be authenticated is achieved.

It should be noted that, in the implementation shown in fig. 2, the CA server 11 is an offline server, then S13 may specifically be that the user 13 copies the certificate X ' on the CA server 11 through a secure production environment device, and S14 may specifically be that the user 13 configures the certificate X ' on the device 12 through the secure production environment device storing the certificate X '; alternatively, S13 and S14 may not be performed by user 13, but rather may be performed automatically by a secure line automation tool. In other possible implementations, the CA server 11 may also be an online server, and the CA server 11 and the device 12 may be in communication without the user 13 having to transit the certificate X 'through another secure production environment device, and the CA server 11 may send the certificate X' directly to the device 12.

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

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

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

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

s101, the device 2 generates a certificate 1, a private key 1 and a public key 1, wherein the public key 1 corresponds to the private key 1.

The device 2 is a device having a function of generating a certificate and a function of digitally signing the certificate, and includes: the device 2 may be a CA server corresponding to the manufacturer of the device 1. The device 2 is a secure trusted device for the device 1 to be authenticated and for the entire network.

In some specific implementations, when there is an access requirement for the device 1 and the device 1 needs to be authenticated, before S101, the device 2 may receive a certificate request message, where the certificate request message is used to apply for the corresponding certificate 1 of the device 1 from the device 2, and the device 2 executes S101 in response to the certificate request message. As an example, the certificate request message received by the device 2 may be initiated by the user or a secure production line automation tool to the device 2, i.e. for triggering the certificate request message on the device 2; as another example, if the device 2 is an online device, i.e. the device 2 can communicate with the device 1, then the certificate request message may also be sent by the device 1 to the device 2.

The certificate request message received by the device 2 may carry the device identification information 1 of the device 1, and the device identification information 1 may be used to uniquely identify the device 1.

As an example, the device Identification information 1 may be device Identification (ID) 1. If the device 2 locally stores a device ID list consisting of device IDs of all devices to be authenticated that are authorized to issue a certificate, then, when the device ID1 is carried in the certificate request message received by the device 2, the device 2 may perform matching verification on the device ID1 according to the locally stored device ID list, and when it is determined that the device ID1 belongs to the device ID list, and the characterizing device ID1 matches with a specific device ID in the device ID list, then the device 2 performs S101 to generate a certificate 1 for the device 1; otherwise, when it is determined that the device ID1 does not belong to the device ID list, and the characterizing device ID1 and all device IDs in the device ID list are not matched, it indicates that the device 2 is not responsible for generating a corresponding certificate for the authentication of the device 1, and then the device 2 does not execute S101, and terminates the authentication of the device 1 by the device 2 this time.

As another example, the device identification information 1 may also be a hash value of the device ID 1. If the device 2 has the right to issue the certificate in the local storage device 2 for authentication, and the hash value list of the device ID is composed of the hash values of the device IDs of all the devices to be authenticated, then, when the certificate request message received by the device 2 carries the hash value of the device ID1, the device 2 may perform matching verification on the hash value of the device ID1 according to the locally stored hash value list of the device ID, and when it is determined that the hash value of the device ID1 belongs to the hash value list of the device ID, and the hash value representing the device ID1 matches with the hash value of a specific device ID in the hash value list of the device ID, the device 2 performs S101 to generate the certificate 1 for the device 1; on the contrary, when it is determined that the hash value of the device ID1 does not belong to the hash value list of the device ID, and the hash values of the device IDs in the hash value list representing the device ID1 and all the device IDs in the hash value list of the device ID are not matched, it indicates that the device 2 is not responsible for generating a corresponding certificate for the authentication of the device 1, and then the device 2 does not execute S101, and terminates the authentication of the device 1 by the device 2 this time.

The device ID1 may be an identifier capable of uniquely identifying the device 1, and the device ID1 may be an identifier that the device 1 is not open to the outside for further security. For example: the device ID1 may be a Hardware Unique Key (HUK) defined when the device 1 leaves the factory; another example is: the Device ID1 may also be an identifier obtained from a Unique Device Identification (UDI) of the Device 1 and a wafer Identification (die ID) in the Device 1.

In addition, according to the requirement of authentication, the certificate request message received by the device 2 may also carry target valid information, and the target valid information is used by the device 1 to determine whether to continue to use the certificate 1 for authentication. The target valid information may specifically be the maximum number of times (for example, 5 times) that the authentication is allowed using the certificate 1, or the maximum time (for example, 1 day) that the authentication is allowed using the certificate 1, so that the device 2 determines the valid number of times or duration of the use of the certificate 1 to be generated with reference to the target valid information.

In specific implementation, the device 2 generates its corresponding certificate 1 for the device 1 in response to the received certificate request message, and further generates a private key 1 and a corresponding public key 1 in order to implement authentication of the device 1 by means of digital signature. As an example, as shown in fig. 4a, the certificate 1 may include: the certificate comprises a version number, a serial number, a signature algorithm identifier, issuer information, a validity period, user information, public key information and an extension domain, wherein the version number is the version number of the certificate 1; the serial number is a number allocated to the certificate 1 by the device 2, and can uniquely identify the certificate 1; the signature algorithm identifier refers to the algorithm and related parameters for securing the certificate 1, such as: the signature algorithm identifier may include: message digest algorithm (abbreviated as MD5), RSA encryption algorithm and related parameters, such as: when not secured, the signature algorithm identifier may be null; the issuer information refers to the relevant information of the device 2, and may specifically include the country, state, province, organization unit department, name, and email to which the device 2 belongs; the validity period may include a start time and an end time; the user information is related information of a user to which the device 1 belongs corresponding to the certificate 1, and specifically may include a country, a state, a province, an organization unit, a department of the organization unit, a name, and an email to which the device 1 belongs; the public key information refers to information related to the public key 1 that securely protects the certificate 1, and may include, for example: public key 1, the public key encryption algorithm used and the corresponding parameters; an extension field, which may include one or more data items to be extended, may extend at least one of the following information: at least one of certificate type, device ID1, hash value of device ID1, and certificate ID1, for example: area 1 may be extended in an extended field of this certificate 1, the value of the field in this area 1 being used to indicate the certificate type of certificate 1, again for example: it is also possible to extend area 2 in the extended field of this certificate 1 for storing the hash value of device ID1 or device ID1, again for example: it is also possible to extend the area 3 in the extension field of the certificate 1 for storing target validity information, again for example: an area 4 may also be extended in the extended field of the certificate 1 for storing a certificate ID1 capable of uniquely identifying the certificate 1.

It can be seen that, through S101, the device 2 generates the certificate 1, the public key 1, and the private key 1 for the device 1 to be authenticated, and provides a reliable data base for subsequent digital signature on the certificate 1 and authentication on the device 1.

S102, the device 2 adopts the private key 1 to digitally sign the certificate 1, and obtains the signature 1 of the certificate 1.

In a specific implementation, the process of digitally signing the certificate 1 by the device 2 may specifically include: s21, the device 2 adopts the Hash algorithm 1 to perform Hash calculation on the certificate 1, and records the Hash value obtained by Hash calculation as the digital abstract 1 of the certificate 1; s22, the device 2 encrypts the digital digest 1 with the private key 1, and records the encrypted value as the signature 1 of the certificate 1.

S103, the device 2 sends the certificate 1 and the signature 1 to the device 1.

S104, the device 1 obtains the certificate 1 digitally signed with the private key 1.

As an example, if device 2 is online with respect to device 1 and a communication connection has been established between device 2 and device 1, then device 2 may send certificate 1 and signature 1 to device 1 based on the already established communication connection.

As another example, in some scenarios with higher security requirements, the device 2 is offline with respect to the device 1, i.e. there is no communication connection between the device 2 and the device 1, then the device 2 sends the certificate 1 and the signature 1 to the device 1, which may also be: the user or a secure line automation tool copies the certificate 1 and signature 1 from the device 2 and then configures the certificate 1 and signature 1 onto the device 1.

For example: assuming that the certificate shown in fig. 4a is certificate 1 in S101 to S103, then, referring to fig. 4b, certificate 1 and signature 1 in S103 can be sent to device 1 in the above-described manner in combination. Note that the certificate 1 and the signature 1 shown in fig. 4b may be regarded as "the certificate 1 digitally signed with the private key 1" in S104.

Note that "certificate 1 digitally signed with private key 1" in S104 and "certificate 1 and private key 1" in S103 both represent the same content, for example: both represent what is shown in figure 4 b.

Therefore, the device 1 acquires the certificate 1 digitally signed by the private key 1, so that subsequent authentication of the device 1 becomes possible.

S105, the device 1 verifies the certificate 1 to obtain a verification result 1.

Before S105, device 1 stores public key 1 locally in advance, and if device 2 is online with respect to device 1, device 2 may directly send public key 1 to device 1, and device 1 stores received public key 1 in a local secure storage space. Or, if the device 2 is offline with respect to the device 1, the user first obtains the public key 1 from the device 2, and then configures the public key 1 into the local secure storage space of the device 1.

In a specific implementation, after the device 1 obtains the certificate 1 and the signature 1, S105 may specifically include: device 1 verifies certificate 1 against locally stored public key 1. Specifically, the process of verifying the certificate 1 by the device 1 according to the locally stored public key 1 may specifically include: s31, the device 1 decrypts the signature 1 by using the public key 1, and records the decrypted value as a digital abstract 2; s32, the device 1 performs hash calculation on the certificate 1 by using the hash algorithm 1, and records the hash value obtained by the hash calculation as the digital digest 3 of the certificate 1; s33, the device 1 compares the digital abstract 2 with the digital abstract 3 to obtain a comparison result. As an example, when the device 1 verifies the certificate 1 only through the public key 1, the comparison result is the verification result 1, and if the comparison result indicates that the digital digest 2 is the same as the digital digest 3, it is determined that the certificate 1 is legal and complete, and then the verification result 1 represents that the device 1 passes the verification of the certificate 1; otherwise, if the comparison result indicates that the digital digest 2 and the digital digest 3 are not the same, it is determined that the certificate 1 is illegal and/or incomplete, and the verification result 1 indicates that the device 1 fails to verify the certificate 1.

In some possible implementations, the certificate type may be included in the certificate 1, and specifically, in an extension field of the certificate 1, a field for storing the certificate type is extended, and a value of the field is used to indicate the certificate type of the certificate 1. Then, S105 may further include: the certificate type in certificate 1 is verified. During specific implementation, whether the certificate type is an authentication certificate is judged, a judgment result is obtained, if the judgment result 1 indicates that the certificate type of the certificate 1 is the authentication certificate, it can be determined that the certificate 1 can be used for authentication of the device 1, otherwise, if the judgment result indicates that the certificate type of the certificate 1 is not the authentication certificate, it can be determined that the certificate 1 cannot be used for authentication of the device 1. As an example, S105 may specifically include: s41, obtaining the comparison result according to the S31-S33; s42, judging whether the certificate type is an authentication certificate, and obtaining a judgment result; s43, determining a verification result 1 according to the comparison result and the judgment result, wherein if the comparison result shows that the digital abstract 2 and the digital abstract 3 are the same and the judgment result shows that the certificate type of the certificate 1 is an authentication certificate, the verification result 1 represents that the device 1 passes the verification of the certificate 1; otherwise, the verification result 1 represents that the device 1 fails to verify the certificate 1.

In other possible implementations, the certificate 1 may further include device identification information 1 of the device 1 to which the certificate 1 is applicable, and taking the hash value of the device ID1 or the device ID1 as the device identification information 1 as an example, specifically, a field for storing the hash value of the device ID1 or the device ID1 may be extended in an extension field of the certificate 1. As an example, if the device ID1 is included in certificate 1, S105 may further include: matching verification is performed on the device ID1 carried by the certificate 1 based on the locally stored device ID2 of the device 1, and a matching result 1 is obtained, wherein the device ID2 is used for uniquely identifying the device 1. If the matching result 1 indicates that the device ID1 and the device ID2 are the same, it may be determined that the certificate 1 was issued for authentication of the device 1, otherwise, it may be determined that the certificate 1 was issued for authentication of the device 1. As another example, if the hash value of the device ID1 is included in the certificate 1, S105 may further include: and performing matching verification on the hash value of the device ID1 carried by the certificate 1 based on the locally stored hash value of the device ID2 of the device 1 to obtain a matching result 2. If the matching result 2 indicates that the hash value of the device ID1 and the hash value of the device ID2 are the same, it can be determined that the certificate 1 was issued for authentication of the device 1, otherwise, it can be determined that the certificate 1 was issued for authentication of the device 1. As still another example, if the hash value of the device ID1 and the device ID1 is included in the certificate 1, S105 may further include: matching verification is carried out on the equipment ID1 carried by the certificate 1 based on the locally stored equipment ID2 of the equipment 1, and a matching result 3 is obtained; and performing matching verification on the hash value of the device ID1 carried by the certificate 1 based on the locally stored hash value of the device ID2 of the device 1 to obtain a matching result 4. If the match result 3 indicates that the device ID1 and the device ID2 are the same and the match result 4 indicates that the hash value of the device ID1 and the hash value of the device ID2 are the same, then it may be determined that the certificate 1 was issued for authentication of the device 1, otherwise it may be determined that the certificate 1 was issued for authentication of the device 1. The device ID2 is a hardware unique key HUK defined when the device 1 is shipped from the factory, or the device ID2 is obtained by processing the wafer ID die ID and the unique device ID UDI of the device 1.

In this implementation, in one case, if only the device ID1 (the hash value of the device ID 1) is extended in the certificate 1, S105 may specifically include: s51, obtaining the comparison result according to the S31-S33; s52, the device 1 performs matching verification on the device ID1 (or the hash value of the device ID 1) carried by the certificate 1 based on the locally stored device ID2 (or the hash value of the device ID 2), and obtains a matching result; s53, determining a verification result 1 according to the comparison result and the matching result, wherein if the comparison result indicates that the digital digest 2 is the same as the digital digest 3, and the matching result indicates that the device ID1 is the same as the device ID2 (or the hash value of the device ID1 is the same as the hash value of the device ID 2), the verification result 1 indicates that the device 1 passes the verification of the certificate 1; otherwise, the verification result 1 represents that the device 1 fails to verify the certificate 1. In another case, if the certificate 1 extends the device ID1 (the hash value of the device ID 1) and the certificate type, S105 may specifically include: s51, obtaining the comparison result according to the S31-S33; s52, the device 1 performs matching verification on the device ID1 (or the hash value of the device ID 1) carried by the certificate 1 based on the locally stored device ID2 (or the hash value of the device ID 2), and obtains a matching result; s53, judging whether the certificate type is an authentication certificate, and obtaining a judgment result; s54, determining a verification result 1 according to the comparison result, the matching result and the judgment result, wherein if the comparison result indicates that the digital digest 2 is the same as the digital digest 3, the matching result represents that the equipment ID1 is the same as the equipment ID2 (or the hash value of the equipment ID1 is the same as the hash value of the equipment ID 2), and the judgment result represents that the certificate 1 is an authentication certificate, the verification result 1 represents that the equipment 1 passes the verification of the certificate 1; otherwise, the verification result 1 represents that the device 1 fails to verify the certificate 1.

In some further possible implementations, the certificate ID1 of the certificate 1 may also be included in the certificate 1, and specifically, the field for storing the certificate ID1 may be extended in an extended field of the certificate 1. Then, S105 may further include: the certificate ID1 is match verified against the locally stored certificate ID 2.

As an example, if the certificate 1 is a one-time certificate, i.e. the certificate 1 can only complete one authentication of the device 1, in order to ensure that each certificate that is down on the device 1 can only be used effectively 1 time, then the certificate IDs of all certificates 1 that it has used can be saved on the device 1. Then, after receiving the certificate 1, the device 1 may determine whether the certificate ID1 corresponding to the certificate 1 matches the locally stored certificate ID2, and if so, it indicates that the certificate 1 has been used on the device 1, that is, the certificate 1 has failed, and the device 1 cannot be authenticated by using the certificate 1 any more; otherwise, if the certificate 1 is not matched, it means that the certificate 1 is first put down on the device 1, and the device 1 can be authenticated by using the certificate 1.

As another example, if the certificate 1 is not a one-time certificate, it may be determined whether the certificate 1 may continue to authenticate the device 1 in combination with the target validity information extended in the certificate 1, and the specific implementation may be referred to the following description about the target validity information.

In still other possible implementations, the certificate 1 may further include target valid information, where the target valid information is a maximum number of times that the certificate 1 is allowed to be used for authentication, or a maximum time that the first certificate is allowed to be used for authentication. Specifically, in the extended field of the certificate 1, a field for storing the target valid information is extended, and a value of the field is used to indicate the target valid information of the certificate 1. Then, S105 may further include: and verifying the target effective information according to the actual use information. The actual use information is used for representing the current condition of using the certificate 1 on the device 1, and when the target valid information is the maximum number of times of authentication allowed by using the certificate 1, the actual use information is the actual use number of times of authentication performed by stopping using the certificate 1 by the device 1; or, when the target valid information is the longest time allowed to authenticate by using the certificate 1, the actual usage information is the actual usage time from the starting time of the timing of the target valid information to the current time.

As an example, assuming that the certificate 1 includes the certificate ID1 and the target valid information, when the device 1 acquires the certificate 1 for the first time, the device 1 checks that the certificate ID1 corresponding to the certificate 1 is not stored on the device 1, the device 1 stores the certificate ID1 to the local of the device 1, and triggers to start recording the actual valid information, that is, records the number of times of use of the certificate 1 corresponding to the certificate ID1 as 1 or triggers to start recording the actual use time. When the device 1 does not obtain and use the certificate 1 for the first time, the S105 may include: s61, the device 1 checks whether the certificate ID1 stored locally is consistent with the certificate ID1 carried in the certificate 1, if so, executes S62, otherwise, executes S64; s62, determining whether the actual usage number of the certificate 1 corresponding to the certificate ID1 reaches the target valid information (i.e., the maximum allowable number of times), or determining whether the actual usage duration of the certificate 1 corresponding to the certificate ID1 reaches the target valid information (i.e., the maximum allowable time), if not, executing S63, otherwise, executing S64; s63, determining that the certificate 1 is still valid, and continuing to authenticate the device 1 by using the certificate 1, and if the target valid information is the number of times, updating the actual number of times of use (i.e. adding one to the actual number of times of use); s64, determining that the certificate 1 is invalid, and not authenticating the device 1 based on the certificate 1. After the condition executed in S63 is satisfied, if the certificate 1 further includes at least one of the hash values of the device ID1 and the device ID1, and the certificate type, the verification result 1 may also be obtained through corresponding verification, for example: determine whether device ID2 and device ID1 stored locally by device 1 are consistent, for example: determine whether the hash value of the device ID2 locally stored by the device 1 matches the hash value of the device ID1, for example: it is verified whether the certificate type of the certificate 1 is an authentication certificate.

It will be appreciated that certificates may degrade in security as they are used. Then, the target valid information of the certificate is set, so that the valid use time or times of the certificate can be limited, and the certificate can be revoked when the certificate is used to a safety insufficient, so that the condition that the certificate is used to a safety insufficient, the condition that the use time or the use time of the certificate is too long, the equipment can still be authenticated after the safety is reduced, the authentication effect is reduced, and the effect of protecting the safety of the equipment 1 is greatly reduced.

In some further possible implementation manners, the certificate 1 further includes a public key 2, and then S105 may further specifically include: the public key 2 in the certificate 1 is verified against the locally stored public key 1. In one case, the public key 2 is the public key 1 that digitally signs the certificate 1, then the device 1 can determine that the public key 2 is consistent with the locally stored public key 1, and then the device 1 can be authenticated based on the certificate 1. In another case, when it is found that the public key 1 and the private key 1 are no longer secure, in order to continuously ensure the security of the authentication method, the device 2 may further generate a new private key 2 and a public key 2 corresponding to the private key 2, carry the public key 2 in the certificate 1, and send the certificate 1 to the device 1, at this time, the device 1 determines, through comparison, that the locally stored public key 1 is not consistent with the public key 2 carried in the certificate 1, and in order not to affect the subsequent authentication on the device 1, replace the locally stored public key 1 with the public key 2. It should be noted that, subsequently, the certificate 1 may use the private key 2 to perform digital signature to obtain the signature 2, and send the signature 2 and the certificate 1 to the device 1, and the device 1 may use the locally stored public key 2 to verify the certificate 1 to obtain the verification result 1.

S106, the device 1 determines the use authority of the device 1 according to the verification result 1.

It is understood that the verification result 1 can be obtained through S105, in one case, the verification result 1 can represent that the device 1 passes the verification of the certificate 1, and then the device 1 can open the usage right of the device 1 based on the verification result 1. Alternatively, the verification result 1 may represent that the device 1 fails to verify the certificate 1, and then the device 1 may determine not to open the usage right of the device 1 based on the verification result 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 verification result 1 represents that the network device passes the verification of the certificate 1, the network device opens the usage rights of all interfaces thereon; or when the verification result 1 indicates that the network device does not pass the verification of the certificate 1, the network device does not open the use right of any interface thereon. As another example, the certificate 1 may also carry an authentication scope in its extended domain, such as: authenticating the interface ID, then, when the verification result 1 represents that the network device passes the verification of the certificate 1, the network device may open the corresponding usage right according to the authentication scope, for example: opening the use authority of the authentication interface corresponding to the authentication interface ID; or when the verification result 1 indicates that the network device does not pass the verification of the certificate 1, the network device does not open the use right of any interface thereon.

When the device 1 may also refer to a debug interface or a service interface on a certain device, if the verification result 1 indicates that the debug interface or the service interface passes the verification of the certificate 1, the device may open the usage right of the corresponding debug interface or the service interface thereon. When the verification result 1 indicates that the certificate 1 is not verified by the debugging interface or the service interface, the device may not open the usage right of the debugging interface or the service interface.

It can be seen that, according to the method provided by the embodiment of the application, the device 2 with the certificate issuing function and the digital signature function and the higher security level performs the digital signature on the certificate 1, and the device 1 to be authenticated verifies the digitally signed certificate 1, so that the authentication of the device 1 to be authenticated is realized, the potential safety hazard existing when the device 1 is protected in a manner that a password book or an interface corresponding to a pad is exposed at present is overcome, and the device 1 to be authenticated is ensured to be more safely and reliably protected through the certificate 1 issued by the device 1 with the high security level and the digital signature technology.

For a more clear and detailed description of the embodiment of the present application, in the scenario shown in fig. 1, taking the certificate shown in fig. 4a and 4b as the certificate 1, the CA server 11 and the device 12 cannot directly communicate, and the authentication process in the embodiment of the present application is specifically described with reference to fig. 5.

The device 12 is a switch 12, and the public key 3 and the HUK 12 of the switch are stored on the switch 12. The CA server 11 stores a list of device ID hash values composed of hash values of device IDs of all devices to be authenticated, which are responsible for issuing certificates for authentication.

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

s201, the user 13 submits a certificate request message on the CA server, where the certificate request message carries the hash value, the maximum authentication number, and the authentication range of the HUK 12.

Wherein the authentication scope is used to indicate the debug interface 1 and the debug interface 2 on the switch 12.

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

S202, the CA server 11 determines whether the hash value of the HUK 12 is in the list of hash values of device IDs stored locally, and if not, executes S203, otherwise, executes S204 to S215 described below.

S203, the CA server 11 displays a prompt message to the user 13, the prompt message being used to inform the user 13 that the CA server 11 is not responsible for authenticating the switch 12.

S204, the CA server 11 generates the certificate 12, and digitally signs the certificate 12 using the private key 3, to obtain the signature 12.

Wherein the certificate 12 is shown in fig. 4a, and the certificate 12 and its corresponding signature 12 are shown in fig. 4 b. Wherein, the public key information in the certificate 12 includes a public key 3', and the extension domain includes: hash value of HUK 12, certificate ID12, maximum number of authentications-5, interface ID1 of authentication interface 1, and interface ID2 of authentication interface 2.

The user 13 obtains the certificate 12 and the signature 12 from the CA server 11 via the storage device S205.

S206, the user 13 configures the certificate 12 and the signature 12 on the switch 12 through the storage device.

S207, the switch 12 verifies that the locally stored public key 3 verifies the signature 12, if the verification passes, S208 is executed, otherwise, S216 is executed.

S208, the switch 12 verifies whether the certificate type in the certificate 12 is an authentication certificate, if so, S209 is executed, otherwise, S216 is executed.

S209, the switch 12 verifies whether the locally stored public key 3 is consistent with the public key 3' stored in the certificate 12, if so, S210 is executed, otherwise, S216 is executed.

S210, the switch 12 verifies whether the version number, serial number, signature algorithm identifier, issuer information, validity period, user information, etc. in the certificate 12 are valid, if so, S211 is executed, otherwise, S216 is executed.

S211, the switch 12 determines whether the certificate ID12 is stored locally in the switch 12, and if not, executes S212, and if so, executes S213.

S212, the switch 12 locally records the certificate ID12, and records the number of actual uses as 0.

S213, the switch 12 determines whether the hash value of the HUK 12 locally stored by the switch 12 is consistent with the hash value of the HUK 12 carried in the certificate 12, if so, executes S214, otherwise, executes S216.

S214, the switch 12 determines whether the actual number of times reaches 5, if not, executes S215, otherwise, executes S216.

S215, the switch 12 opens the debug interface 1 and the debug interface 2, and adds 1 to the number of actual uses.

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

It should be noted that, in the authentication process of the switch 12, the sequence of verification and judgment may be adjusted, and is not specifically limited in the embodiment of the present application.

Thus, in this embodiment, the CA server 11, which is a device with a higher security level, manages the usage right of the switch 12 based on the certificate 12 issued by the CA server and the signature 12 obtained by digitally signing the certificate 12, and opens the usage right of the debug interface that is more critical to the switch 12 through the authentication result indication, thereby implementing a safer protection for the switch 12.

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

s301, acquiring a first certificate digitally signed by a first private key;

s302, verifying the first certificate to obtain a first verification result;

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

The first device may be device 1 in method 100, and then the second device is device 2 in method 100, the first private key is private key 1 in method 100, the first public key is public key 1 in method 100, the first certificate is certificate 1 in method 100, and the first verification result is verification result 1 in method 100. Or, the first device may also be the switch 12 in the method 200, and then, the second device is the CA server 11 in the method 200, the first private key is the private key 3 in the method 200, the first public key is the public key 3 in the method 200, and the first certificate is the certificate 12 in the method 200.

Wherein the first device may be any device to be authenticated, for example: may refer to a network device or a board, for example: but also to a debug interface or a service interface on the device. The second device may refer to an authentication server with a higher security level and having a certificate issuing function and a digital signature function, for example: and a CA server. When the first device is a debugging interface and the second device is a CA server, the CA server issues a certificate which is digitally signed and then is issued to the device where the debugging interface is located, and after the certificate passes verification, the device where the debugging interface is located opens the use permission of the debugging interface for accessing and using the debugging interface.

As an example, the verifying the first certificate by the first device may specifically include: and the first equipment verifies the first certificate according to a locally stored first public key corresponding to the first private key. Therefore, the certificate is verified through the public key locally stored in the first equipment, and the reliable and safe authentication of the first equipment is realized.

As another example, the first certificate may include a certificate type therein, and S302 may further include: the certificate type is verified. If a field for indicating the certificate type of the first certificate is extended in the extended domain of the first certificate, the first device may read the field, and when it is determined that the field indicates that the first certificate is an authentication certificate, the first verification result may indicate that the first certificate passes verification. In this way, the first device may also enable a reliable and secure authentication of the first device by verification of the certificate type of the received first certificate.

As still another example, the first certificate may further include first device identification information, and then S302 may further include: and matching and verifying the first equipment identification information carried by the first certificate based on locally stored second equipment identification information of the first equipment, wherein the second equipment identification information is used for uniquely identifying the first equipment. As an example, the first device identification information may be a first device identification, and then S302 may further include: and the first equipment carries out matching verification on the first equipment ID carried by the first certificate based on a second equipment ID of the first equipment, which is locally stored, wherein the second equipment ID is used for uniquely identifying the first equipment. As another example, for security, the first device identification information may also be a hash value of the first device ID, and then S302 may further include: and the first device performs matching verification on the hash value of the first device ID carried by the first certificate based on the locally stored hash value of a second device ID of the first device, wherein the second device ID is used for uniquely identifying the first device. Wherein the first certificate may extend in its extension field a field for carrying the first device ID or a hash value of the first device ID. Therefore, the first device ID or the hash value of the first device ID carried in the first certificate is verified through the second device ID or the hash value of the second device ID locally stored by the first device, and the reliable and safe authentication of the first device is realized. For example: the

It should be noted that, in order to perform security authentication, in the embodiment of the present application, the device ID is an ID that is not public and can uniquely identify the device, for example: the second device ID is a hardware unique key HUK defined when the first device leaves the factory, for example: the second device ID is processed from the wafer identification die ID and the unique device identification UDI of the first device.

As yet another example, the first certificate may further include a first certificate identification ID, and S302 may further include: and the first equipment carries out matching verification on the first certificate ID according to the second certificate ID stored locally. Wherein the first certificate may extend a field in its extension field for carrying the first certificate ID. Therefore, the first certificate ID carried in the first certificate is verified through the second certificate ID locally stored in the first equipment, and the reliable and safe authentication of the first equipment is realized.

In one case, when the first device does not use the first certificate for authentication, the first device does not locally store the certificate ID of the first certificate, and in this case, when the first device determines that the first certificate ID is not locally stored, that is, the matching verification of the first certificate ID is considered to be passed, the first certificate may be used for authentication.

In another case, when the first device has used the first certificate for authentication, the first device locally stores the second certificate ID of the first certificate, and in this case, when the first device determines that the locally stored second certificate ID matches the first certificate ID in the first certificate, that is, the matching verification of the first certificate ID is considered to be passed, the first certificate may be used for authentication.

In another case, when the first device has used the first certificate for authentication, the first device locally stores the second certificate ID of the first certificate, but since the number of times the first certificate is used exceeds the upper limit or the time of use of the first certificate exceeds the upper limit, the second certificate ID is marked as a failed state, in this case, when the first device determines that the locally stored second certificate ID matches the first certificate ID in the first certificate, but the state of the second certificate ID is failed, it is considered that the matching verification of the first certificate ID is not passed, and the first certificate cannot be reused for authentication of the first device.

As another example, the first certificate may also include target validity information that is used by the device 1 to determine whether authentication using certificate 1 can continue. S302 may further include: the first device verifies the target valid information according to actual use information, wherein the actual use information is used for representing the condition that the first certificate is currently used on the first device. If the target valid information is the maximum number of times (for example, 5 times) that the first certificate is allowed to be used for authentication, the actual use information is the actual use number of times that the first device is authenticated by using the first certificate at present; or the target valid information is the longest time (for example, 20 hours) allowed for authentication using the first certificate, the actual usage information is the actual usage time from the starting time of the timer of the target valid information to the current time. Wherein the first certificate may extend a field for carrying the target valid information in its extension field. It is understood that when the first device determines that the locally stored actual usage information reaches the target valid information of the first certificate, the first device may revoke the first certificate, such as: and marking the second certificate ID corresponding to the first certificate stored locally in the first equipment as invalid. Therefore, the target valid information carried in the first certificate is verified through the actual use information locally stored in the first equipment, and the reliable and safe authentication of the first equipment is realized.

As yet another example, the first certificate may further include a second public key, and S302 may further include: and the first equipment verifies the second public key according to the locally stored first public key. If the first device determines that the first public key and the second public key are inconsistent, the first device regards as the second device that the first public key and the first private key that are not secure enough need to be updated, and then, the embodiment of the present application may further include: the first device replaces the locally stored first public key with the second public key. Thus, the second public key carried in the first certificate is verified through the first public key locally stored by the first equipment, and when the public keys are consistent, the first equipment is guided to manage the use authority of the first equipment, so that the reliable and safe authentication of the first equipment is realized; and when the public keys are inconsistent, the first equipment is guided to update the locally stored public key, and the update of the authentication public key and the authentication private key by the second equipment is completed, so that the subsequent authentication on the first equipment is safer.

Wherein the second public key may be public key 2 in method 100.

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

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

s401, performing digital signature on the first certificate by adopting a first private key;

s402, sending a first certificate which is digitally signed by a first private key to the first device, so that the first device determines the use authority of the first device based on the first certificate.

Where the second device may be device 2 in method 100, then the first device is device 1 in method 100, the first private key is private key 1 in method 100, the first public key is public key 1 in method 100, and the first certificate is certificate 1 in method 100. Alternatively, the second device may also be the CA server 11 in the method 200, and then the first device is the switch 12 in the method 200, the first private key is the private key 3 in the method 200, and the first public key is the public key 3 in the method 200.

Therefore, the first certificate is digitally signed by the second equipment with a certificate issuing function and a digital signature function and higher security level, and the digitally signed first certificate is sent to the first equipment to be authenticated, so that the first equipment verifies the digitally signed first certificate, the authentication of the first equipment to be authenticated is realized, the potential safety hazard existing when the first equipment is protected to be safe in the mode that a password book or an interface corresponding to a pad is exposed at present is overcome, and the first equipment to be authenticated is ensured to be more safe and reliable in protection through the certificate issued by the second equipment with high security level and the digital signature technology.

As an example, in the method 400, the first certificate may further include first device identification information, and the first device identification information is used by the first device for authentication. For example: the first device identification information may be the first device ID or a hash value of the first device ID. As an example, the method 400 may further include: the second equipment receives a certificate request message, wherein the certificate request message comprises a first equipment identification ID; and the second equipment carries out matching verification on the first equipment ID according to the second equipment ID stored locally. As another example, the method 400 may further include: the second equipment receives a certificate request message, wherein the certificate request message comprises a hash value of the ID of the first equipment; and the second equipment carries out matching verification on the hash value of the first equipment ID according to the locally stored hash value of the second equipment ID. After the matching verification is passed, the second device may also carry the first device ID or the hash value of the first device ID in the first certificate, and send the first certificate to the first device. In this way, the second device verifies the first device ID or the hash value of the first device ID carried in the certificate request message through the locally stored second device ID or the hash value of the second device ID, and instructs the second device whether to issue the first certificate to the first device, so that the authentication of the first device is more reliable and safer.

In this embodiment of the present application, the device ID is an unpublished ID capable of uniquely identifying the device, for example: the first device ID is a hardware unique key HUK defined when the first device is shipped, for example: the first device ID is processed from the wafer identification die ID and the unique device identification UDI of the first device.

As yet another example, in the method 400, the first certificate may further include target valid information, which is used by the first device to determine whether authentication using the first certificate can be continued. For example: the target valid information may specifically be the maximum number of times that the authentication is allowed using the first certificate, or the target valid information may also be the maximum time that the authentication is allowed using the first certificate. Then, the embodiment of the present application may further include: the second device receives the certificate request message, which may also include target valid information.

As yet another example, the first certificate may further carry at least one of a certificate type, first device identification information, and a first certificate ID. For the content specifically carried in the first certificate and the corresponding way of verifying the first certificate by the first device, refer to the related description of the method 300.

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

In addition, the embodiment of the present application further provides a first apparatus 800, which is shown in fig. 8. The first device 800 comprises a transceiving unit 801 and a processing unit 802. The transceiving unit 801 is configured to perform transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or transceiving operation performed by the switch 12 in the embodiment shown in fig. 5, or transceiving operation performed by the first device in the method embodiment shown in fig. 6; the processing unit 802 is configured to perform other operations besides the transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or other operations besides the transceiving operation performed by the switch 12 in the embodiment shown in fig. 5, or other operations besides the transceiving operation performed by the first device in the method embodiment shown in fig. 6. For example: the first device 800 is the device 1 in the method 100, then the transceiving unit 801 is configured to perform obtaining the certificate 1 and the signature 1; the processing unit 802 is configured to perform authentication on the certificate 1 to obtain an authentication result 1; the processing unit 802 is further configured to determine the usage right of the device 1 according to the verification result 1.

In addition, a second apparatus 900 is also provided in the embodiment of the present application, and is shown in fig. 9. The second device 900 comprises a transceiving unit 901 and a processing unit 902. The transceiving unit 901 is configured to perform transceiving operation performed by the device 2 in the embodiment shown in fig. 3, or transceiving operation performed by the CA server 11 in the embodiment shown in fig. 5, or transceiving operation performed by the second device in the method embodiment shown in fig. 7; the processing unit 902 is configured to perform other operations besides the transceiving operation performed by the device 2 in the embodiment shown in fig. 3, or other operations besides the transceiving operation performed by the CA server 11 in the embodiment shown in fig. 5, or other operations besides the transceiving operation performed by the second device in the method embodiment shown in fig. 7. For example: the second device 900 is the device 2 in the method 100, then the transceiving unit 901 is configured to send the certificate 1 digitally signed by the private key 1 to the device 1; the processing unit 902 is configured to digitally sign the certificate 1 with the private key 1.

In addition, the embodiment of the present application further provides a first apparatus 1000, which is shown in fig. 10. The first device 1000 includes a communication interface 1001 and a processor 1002 coupled to the communication interface 1001. Among them, the communication interface 1001 is used to execute the transceiving operation executed by the device 1 in the embodiment shown in fig. 3, or the transceiving operation executed by the switch 12 in the embodiment shown in fig. 5, or the transceiving operation executed by the first device in the method embodiment shown in fig. 6; the processor 1002 is configured to perform other operations besides the transceiving operation performed by the device 1 in the embodiment shown in fig. 3, or other operations besides the transceiving operation performed by the switch 12 in the embodiment shown in fig. 5, or other operations besides the transceiving operation performed by the first device in the method embodiment shown in fig. 6. For example: the first device 1000 is device 1 in the method 100, then the communication interface 1001 is used to obtain the certificate 1 and the signature 1; the processor 1002 is configured to perform authentication on the certificate 1, and obtain an authentication result 1; the processor 1002 is further configured to determine the usage right of the device 1 according to the verification result 1.

In addition, the embodiment of the present application further provides a second device 1100, which is shown in fig. 11. The second device 1100 comprises a communication interface 1101 and a processor 1102 connected to the communication interface 1101. The communication interface 1101 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 CA server 11 in the embodiment shown in fig. 5, or the transceiving operation performed by the second device in the method embodiment shown in fig. 7; the processor 1102 is configured to perform the operations other than the transceiving operations performed by the device 2 in the embodiment shown in fig. 3, or the operations other than the transceiving operations performed by the CA server 11 in the embodiment shown in fig. 5, or the operations other than the transceiving operations performed by the second device in the embodiment of the method shown in fig. 7. For example: the second device 1100 is device 2 in the method 100, then the communication interface 1101 is configured to send to the device 1 a certificate 1 digitally signed with a private key 1; the processor 1102 is configured to digitally sign the certificate 1 with the private key 1.

In addition, the embodiment of the present application further provides a first apparatus 1200, which is shown in fig. 12. The first device 1200 comprises a memory 1201 and a processor 1202. Wherein the memory 1201 is used for storing program codes; the processor 1202 is configured to execute the instructions in the program code, so that the first device 1200 executes the method executed by the device 1 in the embodiment shown in fig. 3, or the method executed by the switch 12 in the embodiment shown in fig. 5, or the method executed by the first device in the embodiment shown in fig. 6.

In addition, the embodiment of the present application further provides a second apparatus 1300, which is shown in fig. 13. The second device 1300 includes a memory 1301 and a processor 1302. Wherein, the memory 1301 is used for storing program codes; the processor 1302 is configured to execute the instructions in the program code, so that the second device 1300 performs the method performed by the device 2 in the embodiment shown in fig. 3, or the method performed by the CA server 11 in the embodiment shown in fig. 5, or the method performed by the second device in the embodiment of the method shown in fig. 7.

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

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

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

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

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

In the names of "first certificate", "first private key", etc., mentioned in the embodiments of the present application, "first" is used merely as a name identification, and does not represent first in sequence. The same applies to "second" etc.

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

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

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

Claims

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

acquiring a first certificate digitally signed by a first private key;

verifying the first certificate to obtain a first verification result;

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

2. The method of claim 1, wherein the verifying the first certificate comprises:

and verifying the first certificate according to a locally stored first public key corresponding to the first private key.

3. The method according to claim 1 or 2, wherein the first certificate includes a certificate type, and wherein the verifying the first certificate further comprises:

the certificate type is verified.

4. The method according to any of claims 1-3, wherein the first certificate further includes first device identification information, and wherein the verifying the first certificate further comprises:

and matching and verifying the first equipment identification information carried by the first certificate based on locally stored second equipment identification information of the first equipment, wherein the second equipment identification information is used for uniquely identifying the first equipment.

5. The method of claim 4,

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

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

6. The method according to claim 4 or 5, wherein the second device ID is a Hardware Unique Key (HUK) defined when the first device is shipped from a factory, or the second device ID is obtained by processing according to a wafer identifier (dieID) and a Unique Device Identifier (UDI) of the first device.

7. The method of any of claims 1-6, wherein the first certificate further comprises a first certificate Identification (ID), wherein the verifying the first certificate further comprises:

and performing matching verification on the first certificate ID according to the second certificate ID stored locally.

8. The method of any of claims 1-7, wherein the first certificate further comprises target validity information, and wherein the verifying the first certificate further comprises:

and verifying the target valid information according to actual use information, wherein the actual use information is used for representing the condition that the first certificate is currently used on the first equipment.

9. The method of claim 8,

the target valid information is the maximum number of times of authentication allowed by using the first certificate;

alternatively, the first and second electrodes may be,

the target valid information is the maximum time allowed for authentication using the first certificate.

10. The method of any of claims 1-9, wherein the first certificate further comprises a second public key, and wherein the verifying the first certificate further comprises:

and verifying the second public key according to the locally stored first public key.

11. The method of claim 10, further comprising:

and if the second public key is not consistent with the first public key, replacing the locally stored first public key with the second public key.

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

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

digitally signing the first certificate with a first private key;

and sending the first certificate digitally signed by the first private key to the first device so as to authenticate the use authority of the first device.

14. The method of claim 13, wherein the first certificate further comprises first device identification information, and wherein the first device identification information is used by the first device for authentication.

15. The method of claim 14,

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 at the time of shipment of the first device, or wherein the first device ID is processed according to a wafer identifier dieID and a unique device identifier UDI of the first device.

17. The method of any of claims 13-16, wherein the first certificate further comprises target valid information, the target valid information being used by the first device to determine whether authentication using the first certificate can be continued, the target valid information being a maximum number of times that authentication using the first certificate is allowed, or the target valid information being a maximum time that authentication using the first certificate is allowed.

18. The method according to any of claims 13-17, wherein the first certificate further carries at least one of a certificate type, first device identification information, and a first certificate ID.

19. The method of any of claims 13-18, wherein the second device is an authentication server.

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

21. A first device, comprising:

a communication interface; and

a processor coupled to the communication interface;

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

22. A second apparatus, comprising:

a communication interface; and

a processor coupled to the communication interface;

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

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

the memory for storing program code;

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

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

the memory for storing program code;

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

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

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