Method and apparatus for authenticating IoT devices

Abstract

A system and method for authenticating a device are disclosed. In one embodiment, the method includes generating a tamper-proof secret (ATS) associated with customer-specific information (CSI), providing the ATS for secure storage by the device, and receiving a message from the device, wherein the certificate signing request includes a certificate signing request, the CSI, and an authentication tag derived at least partially according to the ATS and the CSI, and authenticating the received message by comparing the received authentication tag with another authentication tag generated at least partially based on the received CSI.

Description

Technical Field

[0001] Cross-Reference to Related Applications This disclosure claims priority to U.S. Provisional Patent Application No. 63 / 521,533, filed on June 16, 2023, the content of which is hereby incorporated by reference in its entirety.

[0002] This disclosure relates to systems and methods for providing security to remote devices, and particularly to systems and methods for remotely authenticating.

Background Art

[0003] With the spread of Internet of Things (IoT) devices, there has been an ongoing industry-wide effort towards interoperable smart home protocols that enable seamless connection and secure communication between smart devices. BMS (Connectivity Standards Alliance) Matter is an innovative standard in such efforts, and each Matter IoT device requires its own public key infrastructure (PKI) key pair. Currently, IoT manufacturers are facing significant challenges in securely generating, installing, and preventing unauthorized copies of such Matter PKI keys, especially in high-volume production environments. Meanwhile, the entry of PKI companies into the IoT market also presents business opportunities. By leveraging extensive experience, PKI companies can offer both certificate authority (CA) services and certificate provisioning services to IoT manufacturers.

[0004] Regarding the certificate provisioning service, a PKI company can choose to distribute the client source code to potential IoT manufacturers / customers. This makes it easier for manufacturers to integrate the code into their own code and test the code on customer IoT devices. By executing the integrated code, the IoT device can utilize the provisioning services of the PKI company, such as requesting a digital certificate from the PKI server. [Overview of the project] [Problems that the invention aims to solve]

[0005] Adapting existing provisioning protocols to the IoT space presents two main challenges. First, many IoT devices lack the certificates (e.g., digital certificates) necessary to verify the manufacturer's identity or the device's identity itself. This lack of credentials makes authenticating messages from devices difficult, which is a critical step in existing protocol flows. Second, manufacturing errors frequently occur during the device manufacturing process, which can lead to misuse of provisioning services. [Means for solving the problem]

[0006] To address the requirements described above, this document discloses a system and a method for authenticating a device. In one embodiment, the method includes generating a tamper-proof secret (ATS) associated with customer-specific information (CSI), providing the ATS for secure storage by the device, and receiving a message from the device, wherein the message from the device includes a certificate signing request, the CSI, and an authentication tag derived at least in accordance with the ATS and the CSI, and authenticating the received message by comparing the received authentication tag with another authentication tag generated at least in part based on the received CSI.

[0007] Another embodiment is demonstrated by a device having a processor and a communicably coupled memory for storing processor instructions for performing the operations described above.

[0008] The configurations, functions, and advantages discussed can be achieved independently in various embodiments of the present invention, or in combination in yet other embodiments, and further details can be understood by referring to the following description and drawings.

[0009] Here, refer to the drawings, and similar reference numbers throughout represent the corresponding parts. [Brief explanation of the drawing]

[0010] [Figure 1A] Figure 1A shows a typical system for authenticating remote devices. [Figure 1B] Figure 1B shows a typical system for authenticating remote devices. [Figure 2] Figure 2 shows an exemplary operation that can be used to authenticate a remote device. [Figure 3] Figure 3 shows one embodiment of how an authentication server calculates an authentication tag. [Figure 4] Figure 4 shows one embodiment of deriving AuthTag' from ATS. [Figure 5] Figure 5 illustrates an exemplary computer system that may be used to implement the processing elements of a geolocation system. [Modes for carrying out the invention]

[0011] The following description refers to the accompanying drawings, which form part of this description and illustrate several embodiments. It will be understood that other embodiments may be used and structural modifications may be made without departing from the scope of this disclosure.

[0012] Overview Figures 1A and 1B illustrate a generalized system 100 for authenticating an IoT device 104. Figure 1A shows an embodiment in which the message exchange between the IoT device 104 and the authentication server 102 / CA 106 is a Certificate Signing Request (CSR) and a digital certificate. Figure 1B shows a more general embodiment in which the message exchange is some kind of "authentication request and response" and the communication channel 120 may be further encrypted. The encryption mechanism depends on the specific application scenario. For example, this may be a TLS channel between the author server and a programming station directly connected to the device. Alternatively, the encryption mechanism and encryption key may be established in advance from the bandwidth before communication. In both cases, the system 100 comprises an authentication server 102, such as a PKI server. The authentication server is communicably coupled to the IoT device manufacturer 108 via a secure communication channel 116. This communication channel is used to share secrets in time before the execution of the authentication protocol. For example, once an ATS is generated, it may be encrypted with the PGP (Pretty Good Privacy) key of the IoT manufacturer 108 and signed by the PGP of the authentication server 102.

[0013] The IoT device may be configured with a secure chip 118 that makes it sufficiently difficult for an attacker to copy sensitive information, such as ATS, from a legitimate IoT device 104 to another IoT device 104. In such an implementation, the delivery of ATS and other sensitive information to the chip manufacturer 110 may also be done via a secure communication channel 114. Thus, the secure chip 118 that stores ATS 120 is mounted on the IoT device 108. Other means may be used to protect ATS and other personal information stored on the IoT device 104, including, for example, implementing a trusted execution environment (TEE) on the IoT device 104.

[0014] When a deployed IoT device 104 establishes communication with an entity, that entity needs to verify that IoT device 104 is indeed the IoT device 104 it claims to be, and not a cloned IoT device. In a PKI class system, this can be achieved by generating a digital certificate signing request (CSR) to a Certificate Authority (CA) 106. The CSR contains the public key of a public / private key pair unique to device 104. CA 106 uses the public key to authenticate the device, and if the device is authenticated, provides the CA with a digital certificate signed for the device. Device 104 can then be authenticated using the signed digital certificate. Computational and communication costs may not make the use of X.509 digital certificates very advantageous.

[0015] To address the aforementioned problems, a novel protocol tailored to the IoT device 104 and the system is described herein. In this protocol, the IoT device 104 is authenticated instead by communication with an authentication server 102, as further described below. Such communication may be carried out using lighter weight calculation and communication requirements. Furthermore, the entity providing the authentication server 102 may allow manufacturers to integrate their own software code with code designed for authentication operations, thereby increasing security and enabling testing of the integrated code on the IoT device 104.

[0016] This protocol achieves two main objectives. First, the protocol establishes a mechanism for authenticating all message requests from legitimate IoT devices 104. The mechanism specifies specific steps for "securely delivering" the necessary authentication information to device 104. Once these credentials are in place, the mechanism can detect and reject unauthenticated device messages, thereby preventing misuse of the provisioning service. Second, the protocol establishes a mechanism for associating specific customers with the provisioning service and privileges. This mechanism helps detect manufacturing errors during production. This is achieved by using "Anti-Tamper Secrets" (ATS), which are unique to each customer and are described in this disclosure. The ATS acts as a security check during protocol execution, thereby preventing misuse of the provisioning service.

[0017] The protocol described also serves additional purposes. This protocol is It supports the use of a single package for client source code for all types of IoT devices, regardless of whether they have access to the hardware security module. This protocol also helps customers integrate client source code with minimal changes. Finally, the protocol reduces the computational and communication costs of devices. This may include configurations that involve small request and response buffer sizes, as well as the aforementioned reliance on X.509 certificate-based message signing.

[0018] Device Message Authentication By implementing an authentication algorithm on a device, device messages can be authenticated. Such algorithms may be signature algorithms (e.g., Rivest-Shamir-Adleman or RSA algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA)), or message authentication code (MAC) algorithms such as hash-based message authentication code (HMAC).

[0019] However, practical implementations of such authentication are difficult because all of these techniques require the establishment of cryptographic keys prior to such authentication. Depending on the algorithm, this cryptographic key may be in a configuration that includes either a signature key or a MAC key. For ease of reference, when a distinction between different algorithms is not necessary, this disclosure uses the term authentication key to refer to both such keys.

[0020] The entity providing the authentication key may need to distribute the authentication key to each device via the device manufacturer or chip manufacturer (when security operations are at least partially implemented in a secure chip). Depending on the implementation constraints of the IoT device or chip manufacturer and the relationship with the PKI company, it may be configured to distribute such authentication keys using either a secure channel (e.g., PGP) or white-box cryptography.

[0021] Anti-Tampering Secret (ATS) As described below, the authentication key provisioning service generates a unique secret value for each customer, hereinafter referred to as anti-tampering secret (ATS). The ATS encapsulates in secret the relevant customers, defined collectively as customer-specific information (CSI), and information specific to the services and / or privileges granted to the customer. The ATS is essentially a shared secret between the provisioning server and the customer. The ATS can be generated in various ways, and the characteristics of the ATS depend on the application. However, the ATS must have several characteristics. First, when a (IoT or other) device communicates with another entity, the device must be able to prove that it implicitly or explicitly knows the value of the ATS. Second, the information contained in the CSI used to derive the ATS needs to be flexible enough to avoid a combinatorial explosion in the number of ATS values within the system. Finally, the CSI and ATS pair needs to be securely stored from or derivable from the information within the server database.

[0022] The ATS, CSI pair can be generated in various ways. First, the ATS can be generated from the CSI. For example, the ATS may be an encrypted version of the CSI (e.g., ATS = E[CSI]). In another embodiment, the ATS is a cryptographic hash of the CSI. Second, the ATI may be configured as a unique random (or pseudo-random) number simply mapped to the CSI. For example, the authentication server 102 may simply generate a plurality of random numbers, assign the CSI to one of such random numbers, and then store them associated for later use.

[0023] Note that for all definitions of the ATS, CSI pair, it should be noted that the ATS appears as a pseudo-random number that does not reveal useful information about the CSI to an entity without privacy in its generation and / or storage.

[0024] Figure 2 shows an exemplary operation that may be used to authenticate a remote device such as an IoT device 104. In block 202, an ATS associated with the CSI is generated, for example, by the authentication server 102. The CSI includes customer-specific information such as the PKI type, customer identifier (ID), and product ID. The CSI may also be configured to include information describing the customer's rights and privileges, or other information.

[0025] In one embodiment, the ATS is a pseudo-random or random number that is independently generated and stored on the authentication server 102 associated with (or mapped to) the CSI. In another embodiment, the ATS is an encrypted version of the CSI. In yet another embodiment, the ATS is a cryptographic hash of the CSI. For example, the ATS may be configured to be defined as a random number with FR = fixed padding = sufficient bits, and a cryptographic hash of two fields of the CSI.

[0026] Next, the pair (CSI, ATS) is encrypted with the authentication server key, and the encrypted version (E[CSI, ATS]) is stored on the server for later retrieval and use. In one embodiment, rather than storing the ATS in association with the CSI, the CSI is stored by the authentication server 102, and the ATS is recalculated for use in the authentication process as needed. If the FR is used to generate the ATS, the FR should also be stored securely.

[0027] In block 204, the ATS is then provided to the IoT device manufacturer 108 or chip manufacturer 110 via secure channels (securing channels 114 and 116, respectively). In one embodiment, the ATS is provided to the IoT device 104 by the IoT manufacturer 108 for secure storage, protected, for example, by enforcing TEE or by storage within the secure chip 118. In other embodiments, the authentication server 102 integrates the ATS into the IoT device source code via white-box cryptography. After the manufacturing of the IoT devices 104 is complete, they are delivered to the customer for use.

[0028] If a customer desires a service that requires authentication of the IoT device 104, a message containing the request (e.g., a certificate signing request message containing a certificate signing request) is sent from the IoT device 104 to the authentication server 102. The message may include an authentication tag, at least partially derived according to the CSR, CSI, and ATS and CSI, and may also include a nonce.

[0029] In one embodiment, the authentication tag is calculated by deriving the authentication key from the ATS and then calculating the authentication tag on the CSR. The authentication key may be an HMAC key generated as follows:

[0030]

number

[0031] In the formula, HK represents the HMAC key, KDF represents the key derivation function, nonce is an arbitrary random nonce of sufficient size to introduce randomness into key generation, and the “+” operator represents concatenation. The KDF may be any preferred function for securely deriving the cryptographic key from a seed with sufficient entropy known to both the IoT device 104 and the authentication server 102. For example, a standardized KDF such as the one described in NIST Special Publication NIST SP 800-108r1, “Recommendation for Key Derivation Using Pseudorandom Functions”, August 2022 (incorporated herein by reference) may be used. The authentication tag can then be computed on the CSR request as follows:

[0032]

number

[0033] In the formula, HMAC is a secret key-based message authentication algorithm as defined in RFC2104, which is incorporated herein by reference.

[0034] The IoT device 104 then generates the aforementioned message, which includes the CSR, CSI, and calculated authentication tag, and an optional nonce, and sends the message to the authentication server 102. Communication between the authentication server 102 and the IoT device 104 is preferably carried out over the Internet. In some implementations, a manufacturer programming station may be present between the IoT device 104 and the authentication server 102 to facilitate communication without affecting the authentication protocol described herein.

[0035] In block 206, the authentication server 102 receives a CSR message from device 104. The authentication server 102 then authenticates the CSR message by comparing the received authentication tag with another authentication tag, which is generated at least partially according to the CSI received in the CSR request message, as shown in block 208.

[0036] Figure 3 shows one embodiment of how the authentication server 102 calculates the authentication tag. In block 302, the authentication server determines the ATS from the CSR message. This can be achieved by extracting the CSI from the CSR message and retrieving the ATS associated with the CSI from the secure storage of the authentication server 102. In an alternative configuration, the CSI of the CSR message may be used to regenerate the ATS using the same technique used to generate the ATS originally provisioned on device 104.

[0037] Once the ATS is determined, it is used to generate another authentication tag (hereinafter referred to alternatively as 'AuthTag'), as shown in block 304.

[0038] Figure 4 shows one embodiment of the derivation of AuthTag' from ATS. Actions are performed to reflect the actions performed by IoT device 104 when calculating the authorization tag contained in the CSR message (hereinafter alternatively referred to as AuthTag). In block 402, the authentication key is re-derived according to the ATS. This can be achieved, for example, by re-deriving the authentication key described in Equation 1 using the ATS determined in block 302 and any nonce contained in the CSR request message. In block 404, another authentication tag (AuthTag') is derived according to the re-derived authentication key. Again, this is achieved using actions that reflect the actions performed by IoT device 104 when generating the authentication tag sent as part of the CSR message, as described below.

[0039]

number

[0040] If AuthTag = AuthTag', the authentication server 102 authenticates the request sent by the IoT device 104 and sends a response to the IoT device 104. If AuthTag ≠ AuthTag', the authentication server 102 takes an appropriate action, such as not responding to the CSR message or responding with an error. Furthermore, the authentication server 102 may be configured to report and / or log failed requests.

[0041] Note that if there is an error in the CSI included in the CSR message, the authentication server 102 will not be able to find the corresponding ATS in the authentication server database, and the authentication server 102 will also not be able to regenerate the ATS from the CSI. In this case, the corresponding ATS cannot be determined, and authentication will fail. This implicitly detects an error or mistake in the CSI.

[0042] In the above description, the IoT device 104 may be configured to communicate the CSR message directly with the authentication server 102. As shown in Figure 1, in another embodiment, the IoT device 104 may communicate the CSR message to the CA 106, and the CA 106 may be configured to forward the CSR message to the authentication server 102 for authentication before responding to the request.

[0043] Hardware environment Figure 5 shows an exemplary computer system 500 that may be used to implement the processing elements of the above disclosure, including an authentication server 102, an IoT device 104, and a certification authority 106. Computer 502 comprises a processor 504 and memory such as random access memory (RAM) 506. Computer 502 is operably coupled to a display 522 that presents images to the user, such as windows on a graphical user interface 518B. Computer 502 may be coupled to other devices such as a keyboard 514, a mouse device 516, and a printer 528. Naturally, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripheral devices, and other devices, may be used with computer 502.

[0044] Generally, computer 502 operates under the control of an operating system 508 stored in memory 506, receives inputs and commands, and interfaces with the user to present results through a graphical user interface (GUI) module 518A. Although the GUI module 518B is illustrated as a separate module, the instructions that perform the GUI functions may reside or be distributed within the operating system 508, computer programs 510, or implemented in dedicated memory and processor. Computer 502 also implements a compiler 512 that enables application programs 510 written in programming languages ​​such as COBOL, C++, FORTRAN, or other languages ​​to be translated into processor 504-readable code. After completion, the application 510 uses the relationships and logic generated using the compiler 512 to access and manipulate data stored in the computer 502's memory 506. Computer 502 also optionally includes external communication devices such as a modem, satellite link, Ethernet card, or other devices for communicating with other computers.

[0045] In one embodiment, the instructions implementing the operating system 508, the computer program 510, and the compiler 512 are tangibly embodied in a data storage device 520, which may be configured to include one or more fixed or removable data storage devices, such as a zip drive, a floppy disk drive 524, a hard drive, a CD-ROM drive, or a tape drive, on a computer-readable medium. Furthermore, the operating system 508 and the computer program 510 consist of instructions that, when read and executed by a computer 502, cause the computer 502 to perform the operations described in this disclosure. The computer program 510 and / or operation instructions may also be tangibly embodied in a memory 506 and / or a data communication device 530, thereby creating a computer program product or manufactured article. Accordingly, as used herein, the terms “manufactured article,” “program storage device,” and “computer program product” are intended to encompass computer programs accessible from any computer-readable device or medium.

[0046] A person skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope of this disclosure. For example, a person skilled in the art will recognize that any combination of the above components, or any number of different components, peripheral devices, and other devices, can be used.

[0047] conclusion Herein, we conclude the description of preferred embodiments of the present disclosure.

[0048] One or more computer systems can be configured to perform specific operations or actions by having software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform actions when it is running. One or more computer programs can be configured to perform specific operations or actions by including instructions that cause the device to perform actions when executed by a data processing device. One common embodiment includes a method for authenticating a device. The method also includes generating a tamper-proof secret (ATS) associated with customer-specific information (CSI), providing the ATS for secure storage by the device, and receiving a message from the device, wherein the message comprises a certificate signing request (CSR), the CSI, and an authentication tag derived at least in accordance with the CSR, the ATS, and the CSI. The method also includes authenticating a received message by comparing the received authentication tag with another authentication tag generated at least in accordance with the received CSI. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0049] The implementation may include one or more of the following configurations:

[0050] The above method, in which ATS is calculated at least partially from random numbers and CSI.

[0051] A method of any of the above, wherein the authentication tag is at least partially calculated according to the authentication key, CSI, and certificate signing request, and the authentication key is at least partially calculated according to the ATS.

[0052] A method of any of the above, wherein the authentication tag is at least partially computed as an encryption function according to the authentication key, the CSI, and the certificate signing request. A method of any of the above, wherein authenticating the certificate signing request according to a comparison of the received authentication tag and another authentication tag generated at least partially based on the received CSI, may include determining the ATS and deriving another authentication tag according to the ATS.

[0053] Any of the above methods may include a configuration in which determining the ATS involves obtaining the generated ATS associated with the received CSI and regenerating the ATS at least partially according to the received CSI.

[0054] A method of any of the above, comprising: deriving another authentication tag in accordance with the ATS; re-deriving an authentication key in accordance with the ATS; re-deriving the authentication key; the CSI; and deriving another authentication tag at least partially as a cryptographic function in accordance with the certificate signing request.

[0055] A method comprising any of the above, wherein an authentication key is derived according to the ATS, a generated random nonce, and a key derivation function, and the authentication tag is computed at least in part as an encryption function according to the authentication key, the CSI, the certificate signing request, and the generated random nonce, and the message may further include a generated random nonce, the de-derived authentication key is further derived according to the received generated random nonce, and another authentication tag is further derived according to the received nonce. Examples of implementations of the described technology include hardware, methods or processes, or computer software for computer-accessible media.

[0056] One general embodiment includes a device for authenticating a device. The device also includes a processor and memory communicably coupled to the processor, wherein the memory stores processor instructions including processor instructions for receiving a message, the message including a CSR, the CSI, the CSR, the ATS, and an authentication tag derived at least in accordance with the CSI. The device also includes authenticating a received message by comparing the received authentication tag with another authentication tag generated at least in accordance with the received CSI. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the Method.

[0057] The implementation may include one or more of the following configurations:

[0058] The above-mentioned device, in which the ATS is calculated at least partially from random numbers and CSI.

[0059] Any of the above-mentioned devices, wherein the authentication tag is calculated at least in part according to the authentication key, CSI, and certificate signing request, and the authentication key is calculated at least in part according to the ATS.

[0060] A device, any of the above, wherein the authentication tag is at least partially computed as an encryption function according to the authentication key, the CSI, and the certificate signing request.

[0061] Any of the above-described devices, wherein the processor instructions for authenticating a certificate signing request according to a comparison of a received authentication tag with another authentication tag generated at least in part based on a received CSI may include processor instructions for determining an ATS and deriving another authentication tag according to the ATS.

[0062] Any of the above-described devices, wherein the processor instructions for determining the ATS may include processor instructions for obtaining a generated ATS associated with a received CSI and for regenerating the ATS at least partially according to the received CSI.

[0063] Any of the above-described devices, wherein the processor instructions for deriving another authentication tag in accordance with the ATS may include processor instructions for re-deriving an authentication key in accordance with the ATS, and at least partially re-deriving the authentication key CSI, and for deriving another authentication tag as an encryption function in accordance with the certificate signing request.

[0064] A device, any of the above, wherein an authentication key is derived according to the ATS, a generated random nonce, and a key derivation function; the authentication tag is at least partially computed as an encryption function according to the authentication key, the CSI, the certificate signing request, and the generated random nonce; the message further includes the generated random nonce; the re-derived authentication key is further derived according to the received generated random nonce; and another authentication tag is further derived according to the received nonce. Examples of implementations of the described technology include hardware, methods or processes, or computer software for computer-accessible media.

[0065] The above description of preferred embodiments is presented for illustrative and illustrative purposes only. It is not intended to be exhaustive or to limit the disclosure to the exact form disclosed. Many modifications and variations are possible in light of the above teachings. For example, using the principles described above, one could design an ATS-based authentication protocol having different authentication algorithms, or authentication keys generated using different algorithms and data, or delivered to the IoT manufacturer 108 and / or IoT device 104. The ATS may also be defined differently from those described herein, may be stored by the authentication server 102, or may be delivered to the IoT device manufacturer 108 or IoT device 104 in a different manner. Finally, different message exchanges may be defined.

[0066] The scope of rights is intended to be limited not by this detailed description, but rather by the claims attached herein.

Claims

1. A method for authenticating a device, To generate tamper-proof secrets (ATS) associated with customer-specific information (CSI), To provide the ATS for secure storage by the aforementioned device, Receiving a message from the aforementioned device, wherein the message is Certificate Signing Request (CSR) and, The aforementioned CSI and, Receiving includes, the CSR, the ATS, and an authentication tag derived at least in part according to the CSI, A method comprising authenticating a received message by comparing the received authentication tag with another authentication tag generated at least partially based on the received CSI.

2. The method according to claim 1, wherein the ATS is calculated at least partially from random numbers and the CSI.

3. The method according to claim 2, The authentication tag is calculated at least in part according to the authentication key, the CSI, and the certificate signing request. A method by which the authentication key is calculated at least in part according to the ATS.

4. The method according to claim 3, The aforementioned authentication tag The aforementioned authentication key, The aforementioned CSI and... A method that is at least partially computed as an encryption function in accordance with the aforementioned certificate signing request.

5. The method according to claim 4, Authenticating the certificate signing request, at least partially, according to the comparison between the received authentication tag and another authentication tag, which was generated according to the received CSI, Determining the aforementioned ATS, A method comprising deriving the other authentication tag in accordance with the ATS.

6. The method according to claim 5, Determining the aforementioned ATS To obtain the generated ATS associated with the received CSI. A method comprising either regenerating the ATS based at least partially on the received CSI.

7. A method according to claim 6, wherein the other authentication tag is derived according to the ATS, Re-deriving the authentication key according to the ATS, The aforementioned other authentication tag, at least partially, The aforementioned re-derived authentication key, The aforementioned CSI and... A method comprising deriving an encryption function in accordance with the aforementioned certificate signing request.

8. The method according to claim 7, The authentication key is derived according to the ATS, the generated random nonce, and the key derivation function. The authentication tag is at least partially, The aforementioned authentication key, The aforementioned CSI and, The aforementioned certificate signing request, The encryption function is calculated according to the generated random nonce, The message further includes the generated random nonce, The re-derived authentication key is further derived according to the received generated random nonce. A method in which the aforementioned other authentication tag is further derived according to the received nonce.

9. A device for authenticating devices, Processor and A memory that is communicably coupled to the processor, wherein the memory is To generate tamper-proof secrets (ATS) associated with customer-specific information (CSI), To provide the ATS for secure storage by the aforementioned device, Receiving a message from the aforementioned device, wherein the message is Certificate Signing Request (CSR) and, The aforementioned CSI and, Receiving includes, the CSR, the ATS, and an authentication tag derived at least in part according to the CSI, A device comprising: a memory storing processor instructions, including a processor instruction for authenticating a received message by comparing the received authentication tag with another authentication tag generated at least partially based on the received CSI; and

10. The apparatus according to claim 9, wherein the ATS is calculated at least partially from random numbers and the CSI.

11. The apparatus according to claim 10, The authentication tag is calculated at least in part according to the authentication key, the CSI, and the certificate signing request. An apparatus in which the authentication key is calculated at least in part according to the ATS.

12. The apparatus according to claim 11, The authentication tag is at least partially The aforementioned authentication key, The aforementioned CSI and... The device, calculated according to the aforementioned certificate signing request.

13. The apparatus according to claim 12, The processor instruction for authenticating the certificate signing request according to the comparison between the received authentication tag and another authentication tag at least partially generated according to the received CSI, Determining the aforementioned ATS, A device including a processor instruction for deriving the other authentication tag in accordance with the ATS.

14. The method according to claim 13, The processor instruction for determining the ATS is, A processor instruction for obtaining the generated ATS associated with the received CSI, A device comprising either a processor instruction for regenerating the ATS in at least partly according to the received CSI.

15. The apparatus according to claim 14, wherein the processor instruction for deriving the other authentication tag in accordance with the ATS is Re-deriving the authentication key according to the ATS, The aforementioned other authentication tag, at least partially, The aforementioned re-derived authentication key, The aforementioned CSI and... A device including a processor instruction to derive as an encryption function in accordance with the aforementioned certificate signing request.

16. The apparatus according to claim 15, The authentication key is derived according to the ATS, the generated random nonce, and the key derivation function. The authentication tag is at least partially The aforementioned authentication key, The aforementioned CSI and, The aforementioned certificate signing request, The encryption function is calculated according to the generated random nonce, The certificate signing request further includes the generated random nonce, The re-derived authentication key is further derived according to the received generated random nonce. The device, wherein the aforementioned other authentication tag is further derived according to the received nonce.

17. A device for authenticating a device, To generate tamper-proof secrets (ATS) associated with customer-specific information (CSI), To provide the ATS for secure storage by the aforementioned device, Receiving a message from the aforementioned device, wherein the message is Certificate Signing Request (CSR), The CSI, Receiving includes, the CSR, the ATS, and an authentication tag derived at least in part according to the CSI, A method comprising authenticating a received message by comparing the received authentication tag with another authentication tag generated at least partially based on the received CSI.

18. The method according to claim 17, wherein the ATS is calculated at least partially from random numbers and the CSI.

19. The method according to claim 18, The authentication tag is calculated at least in part according to the authentication key, the CSI, and the certificate signing request. A method by which the authentication key is calculated at least in part according to the ATS.

20. The method according to claim 19, The authentication tag is at least partially The aforementioned authentication key, The aforementioned CSI and... A method calculated as an encryption function in accordance with the aforementioned certificate signing request.

Images