Secure transmission based registration

Abstract

An apparatus includes a Secure Transport Registration (EST) client configured to: store a trust anchor, initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with an EST server, receive a TLS / DTLS EST server certificate from the EST server, verify the TLS / DTLS EST server certificate using the trust anchor, and, if verification fails, complete a TLS / DTLS handshake to establish an untrusted TLS / DTLS session with the EST server.

Description

Technical Field

[0001] This invention relates to an improved Enrollment over SecureTransport (EST) process. Background Technology

[0002] The Internet Engineering Task Force (IETF) defines "Secure Transport Registration" (EST) in RFC 7030, which describes how to leverage Transport Layer Security (TLS) and Hypertext Transfer Protocol (HTTP) to provide an authenticated and authorized channel for requests and responses to Simple Public Key Infrastructure (PKI). Architecturally, the EST service sits between the Certification Authority (CA) and the client.

[0003] IETF RFC 9148 defines a new EST transport protocol based on Restricted Application Protocol (CoAP) because restricted devices and networks in Internet of Things (IoT) use cases use CoAP (UDP) and CoAPs (DTLS) instead of HTTP (TCP) and HTTPS (TLS). Datagram Transport Layer Security (DTLS) is used to secure CoAP messages. Summary of the Invention

[0004] According to a first aspect, an apparatus is provided that includes a "Secure Transmission Registration" (EST) client, the EST client being configured to: Store trust anchors; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; Verify TLS / DTLS EST server certificates using trusted anchors; and If authentication fails, complete the TLS / DTLS handshake to establish an untrusted TLS / DTLS session with the EST server.

[0005] The EST client can also be further configured as follows: Using the untrusted TLS / DTLS session, a Certificate Authority (CA) certificate retrieval request is sent to the EST server; and Receive one or more CA certificates from the EST server.

[0006] The EST client can also be further configured to store one or more CA certificates in temporary or volatile storage.

[0007] The EST client can also be further configured to send a verification request to the EST server to verify the one or more CA certificates, wherein the verification request includes a vendor identifier corresponding to the vendor CA associated with the trust anchor. Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; and Verify one or more CA certificates.

[0008] The EST client can also be configured to move one or more CA certificates to the Trust Anchor Store after verifying them. For example, the EST client can use a CA certificate to update an explicit TA store / database.

[0009] The EST client can be configured as follows: Send a CA certificate retrieval request to the EST server using an untrusted TLS / DTLS session, wherein the CA certificate retrieval request contains a vendor identifier associated with the vendor CA associated with the trusted anchor; and Receive a CA certificate response from the EST server, wherein the CA certificate response is signed by the EST server and contains an EST-signed certificate signed by the vendor CA; and Verify one or more CA certificates.

[0010] Typically, CA certificate responses use the Cryptographic Message Syntax (CMS) format.

[0011] The EST client can be configured to: verify the EST signing certificate using a trust anchor, extract the EST server's public key from the EST signing certificate, and use the public key to verify the signature of the CA certificate response.

[0012] In one embodiment, the EST client is configured as follows: Send a trust establishment request to the EST server, wherein the trust establishment request contains a vendor identifier associated with the vendor CA associated with the trust anchor. Receive a response from the EST server, which includes a TLS / DTLS EST server certificate signed by the EST server and an EST server signing certificate signed by the vendor CA; Verify the EST server signing certificate using a trust anchor; Extract the public key from the EST signing certificate; and Use this public key to verify the signed TLS / DTLS EST server certificate.

[0013] The EST client can also be further configured to terminate untrusted TLS / DTLS sessions and initiate a new TLS / DTLS handshake with the EST server to establish a trusted TLS / DTLS session. For example, after verifying the CA certificate response or the TLS / DTLS EST server certificate. Alternatively, the EST client can be further configured to verify untrusted TLS / DTLS sessions to establish a trusted TLS / DTLS session.

[0014] According to the second aspect, a method is provided for execution on a device containing a "Secure Transmission Registration" (EST) client, the method comprising: Store trust anchors; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; Verify TLS / DTLS EST server certificates using trusted anchors; and If authentication fails, complete the TLS / DTLS handshake to establish an untrusted TLS / DTLS session with the EST server.

[0015] The method may also include: Send a Certificate Authority (CA) certificate request to the EST server using an untrusted TLS / DTLS session; and Receive one or more CA certificates from the EST server.

[0016] The method may also include storing one or more CA certificates in temporary or volatile memory.

[0017] The method may also include: Send a verification request to the EST server to verify one or more CA certificates, wherein the verification request contains a vendor identifier associated with the vendor CA associated with the trust anchor. Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; and Verify one or more CA certificates.

[0018] The method may also include: after verifying one or more CA certificates, moving the one or more CA certificates to a trust anchor store. For example, moving one or more CA certificates to an explicit TA store / database.

[0019] The method may also include: Send a CA certificate retrieval request to the EST server using an untrusted TLS / DTLS session, wherein the CA certificate retrieval request contains a vendor identifier associated with the vendor CA associated with the trusted anchor; and Receive a CA certificate response from the EST server, wherein the CA certificate response is signed by the EST server and contains an EST-signed certificate signed by the vendor CA; and Verify one or more CA certificates.

[0020] CA certificate responses can be in the Cryptographic Message Syntax (CMS) format.

[0021] The method may also include: verifying the EST signing certificate using a trust anchor, extracting the public key of the EST server from the EST signing certificate, and using the public key to verify the signature of the CA certificate response.

[0022] The method may also include: Send a trust establishment request to the EST server, wherein the trust establishment request contains a vendor identifier associated with the vendor CA associated with the trust anchor. Receive a response from the EST server, which includes a TLS / DTLS EST server certificate signed by the EST server and an EST server signing certificate signed by the vendor CA; Verify the EST server signing certificate using a trust anchor; Extract the public key from the EST signing certificate; and Use the public key to verify the signed TLS / DTLS EST server certificate. The method may further include: terminating the untrusted TLS / DTLS session and initiating a new TLS / DTLS handshake with the EST server to establish a trusted TLS / DTLS session. Alternatively, the method may further include verifying the untrusted TLS / DTLS session to establish a trusted TLS / DTLS session.

[0023] According to the third aspect, a system is provided, comprising: The EST server is configured as follows: Generate asymmetric key pairs; Send a Certificate Signing Request (CSR) to the supplier CA. Receive the EST signing certificate from the supplier CA and associate the certificate with the supplier identifier associated with that supplier CA; Use the private key of the asymmetric key pair to sign one or more Certificate Authority (CA) certificates; The EST client is configured as follows: Store the trust anchor associated with the vendor's CA; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) (TLS / DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; Verify TLS / DTLS EST server certificates using trusted anchors; and If authentication fails, complete the TLS / DTLS handshake to establish an untrusted TLS / DTLS session with the EST server.

[0024] The EST client can also be further configured as follows: Use the untrusted TLS / DTLS session to send a Certificate Authority (CA) certificate retrieval request to the EST server; Receive one or more CA certificates from the EST server; Send a verification request to the EST server to verify one or more CA certificates, wherein the verification request contains a vendor identifier associated with the vendor CA; Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; and Verify one or more CA certificates.

[0025] According to the fourth aspect, a method is provided for establishing a Trusted Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) session between an EST client and an EST server, the method comprising: The EST client stores a trust anchor, which is associated with the vendor CA. Initiate a TLS / DTLS handshake between the EST client and the EST server; Send the TLS / DTLS EST server certificate from the EST server to the EST client; Verify TLS / DTLS certificates using trust anchors; and If authentication fails, a TLS / DTLS handshake is completed, establishing an untrusted TLS / DTLS session between the EST client and the EST server. Attached Figure Description

[0026] Figure 1 The signal flow diagram of the EST process is shown; Figure 2 A signal flow diagram of another EST procedure is shown; Figure 3A signal flow diagram of another EST procedure is shown; Figure 4 A signal flow diagram of another EST procedure is shown; and Figure 5 A schematic diagram of an apparatus according to one embodiment is shown. Detailed Implementation

[0027] Figure 1 A signal flow diagram 100 for an EST process is shown. In step 101, the EST client is loaded with an implicit trust anchor (TA). For example, the EST client may consist of a smart meter, modem, or other device, and the implicit TA may be pre-provided by the manufacturer at the factory. Subsequently, the implicit TA can be used on the client or server during the EST TLS / DTLS authentication process.

[0028] In step 102, TA is loaded into the EST server during installation.

[0029] In step 103, the EST client performs a TLS handshake with the EST server to establish a TLS session 104. The EST client uses an implicit TA to authenticate with the EST server.

[0030] In step 105, within the TLS session, the EST client sends a CA certificate request to the EST server. For example, the EST client can use the " / cacerts" function to request the CA's EST CA TA database information (provided in certificate form). Both the EST client and the EST server support the / cacerts function (or its CoAP equivalent).

[0031] In step 106, the EST server sends a certificate response (e.g., in PKCS7 format). For example, "application / pkcs7-mime" can be used as the HTTP content type. A simple PKI response is sent. The EST server includes the current root CA certificate in the response. The EST server may also include any other certificates required by the client to build a certificate chain from the certificate issued by the EST CA to the current ESTCA TA. For example, if the EST CA is a subordinate CA, the response may include all necessary subordinate CA certificates to build a certificate chain leading to the root EST CA.

[0032] After out-of-band verification is completed, other certificates can be verified through regular certificate path verification (using the latest CA certificate as the TA) before being used in the certificate verification process to build the certificate path.

[0033] The EST client can store the extracted EST CA certificate as an explicit TA for subsequent EST server authentication. The EST client can then disable the implicit TA for the EST server.

[0034] In step 107, the EST client sends a client certificate request to the EST server. The EST client can request a certificate from the EST server using the " / simpleenroll" function. The EST client can obtain a certificate for itself by submitting a registration request to the EST server. The client typically includes a simple PKI request (such as a PKCS#10 certificate request as defined by the IETF in RFC2986).

[0035] A Certificate Signing Request (CSR) can be used to provide the EST server with proof of ownership of the client's private key. The EST client then uses the private key to generate a CSR signature.

[0036] When using an existing certificate for TLS client authentication, an EST client may request an additional certificate. For example, when requesting a certificate that cannot be used for TLS client authentication, the client can use the existing certificate for TLS client authentication.

[0037] In step 108, the EST server sends a client certificate request to the operating CA.

[0038] In step 109, the EST server receives the requested certificate from the operating CA.

[0039] In step 110, the EST server sends a client certificate response to the EST client. This response may be a "CMC Simple PKI Response with Certificate Only" (as defined by the IETF in RFC 5272), containing only the certificate issued by the operating CA. The registration process is now complete.

[0040] EST-CoAPs client (hereinafter referred to as "EST client") authenticates with EST-CoAPs server (hereinafter referred to as "EST server") based on certificate authentication during the DTLS handshake. The EST-CoAPs client is pre-configured with a TA database containing trusted anchors for the EST server, which allows the client to update its trusted anchor (operational-grade TA) for that user after the initial authentication with the EST-CoAPs server. The above is based on... Figure 1 The described EST procedure can also be used for EST-CoAP, but DTLS must be used instead of TLS.

[0041] If the trust anchor of the EST server is known during device manufacturing and can be injected into the device, the architecture (and signaling flow) will function correctly. However, if the trust anchor of the EST server is unknown during device manufacturing, additional steps may be required after manufacturing to configure the correct trust anchor for the device based on the customer's situation. These additional steps can introduce issues related to misconfiguration risks, scalability problems, and inventory shipment rerouting. Furthermore, the problem becomes even more complex when devices from multiple manufacturers need to be deployed in a single deployment (common in IoT technologies).

[0042] Another potential problem is the compromise of the operating Certificate Authority (CA) or the rotation of operating CA certificates. If an operating CA is compromised and services are transferred to a new operating CA, devices will be unable to verify the new operating CA when attempting to obtain a new operating certificate from it. The method proposed in this invention helps to verify the new operating CA.

[0043] The embodiments provided herein address these problems, at least in part, by offering an improved EST process.

[0044] Figure 2 Signal flow diagram 200 for the EST process is shown. This process also applies to EST-CoAP. Each vendor is associated with and publishes an identifier, such as an IEEE OUI assigned to a manufacturer. A vendor may also be a device manufacturer.

[0045] In step 201, the device is infused with a TA (Task Authority) known and trusted by the supplier during the manufacturing process. For example, an EST client may consist of a smart meter or other device, and the TA can be obtained by the manufacturer from a trusted CA (Certificate Authority) during the factory phase.

[0046] In step 202, the server TA is loaded into the EST server (e.g., during installation). This TA is associated with the TLS certificate of the EST client and allows the EST server to verify the EST client.

[0047] In step 203, the EST server generates a new asymmetric key pair for signing. This asymmetric key pair is different from the EST server's TLS / DTLS server asymmetric key pair to achieve separation of responsibilities.

[0048] In step 204, the EST server generates a Certificate Signing Request (CSR) for the new key pair and sends the CSR to the vendor CA. Secure out-of-band technology is typically used to send the CSR. Generally, the EST server can send the CSR to each of multiple vendors. Each vendor can then sign the corresponding certificate using its trusted CA (i.e., the vendor CA). This vendor CA corresponds to the TA, which is injected into the device along with the EST client during manufacturing.

[0049] In step 205, the vendor CA sends a (vendor-signed) certificate for the new key pair to the EST server. This certificate, which may be called an EST-signed certificate, has been signed by the vendor CA.

[0050] In step 206, the EST server configures each certificate according to the vendor identifier associated with the vendor (and its vendor CA).

[0051] Steps 204 to 206 can be performed whenever it is necessary to deploy equipment from different manufacturers.

[0052] In step 207, the EST client initiates a TLS / DTLS handshake with the EST server 208.

[0053] In step 208, the EST server exchanges its TLS / DTLS EST server certificate, which is signed using a client-specific PKI (different from the asymmetric key pair generated in step 203). This TLS / DTLS EST server certificate is different from the certificate received from the vendor CA during the EST server configuration process.

[0054] In step 209, the EST client performs certificate verification. Because the EST client's implicit TA is not configured to trust the PKI certificate chain of the TLS / DTLS EST server certificate, the EST client's certificate verification fails. In a normal EST process, this would result in the termination of session establishment.

[0055] In step 210, the EST client does not terminate the TLS / DTLS session, but continues the (untrusted) TLS / DTLS session. This step completes the TLS / DTLS handshake.

[0056] In step 211, the EST client sends a CA certificate retrieval request to the EST server. This request is related to the above... Figure 1 The CA certificate request in step 105 described is similar or equivalent. For example, for a TLS session, an EST client can use HTTP and take the path "est / cacerts".

[0057] In step 212, the EST server sends one or more CA certificates to the EST client.

[0058] In step 213, because the client does not trust the TLS / DTLS session, the EST client stores the returned CA certificate in volatile or temporary memory. This is consistent with... Figure 1 The process described in the previous section differs from the one described elsewhere, in which the EST client stores the CA certificate in an explicit TA store / database.

[0059] In step 214, the EST client sends a CA certificate verification request to the EST server. This request includes a vendor identifier (e.g., using the new path "est / valcacerts / {vendor_identifier}" or the equivalent of CoAP).

[0060] In step 215, the EST server identifies the vendor identifier and processes the CA certificate verification request. The EST server signs the CA certificate response using the asymmetric private key generated according to the EST server configuration (i.e., the new private key generated in step 203). The CA certificate response may contain validity information.

[0061] In step 216, the EST server generates a CA certificate response signed using the private key. This response is typically in CMS (Cryptographic Message Syntax) format (defined by IETF RFC 5652).

[0062] In step 217, the EST server sends a CA certificate response to the EST client, along with an EST server-signed certificate associated with the asymmetric key pair (generated in step 203) and signed by the vendor CA. The EST client receives this response.

[0063] In step 218, the EST client uses the TA to verify the EST server signing certificate contained in the response, extracts the EST server's signing public key from the certificate upon successful verification, and uses this public key to verify the CA certificate associated with the signed CA certificate response. Once the CA certificate passes the above verification, it is moved from volatile or temporary memory to the explicit TA repository / database.

[0064] In one embodiment, to avoid an excessively large response message, the CA certificate may not be included in the CA certificate response because the EST client has already obtained a local copy through steps 212 and 213. Therefore, the EST client can verify the received signature against the local copy.

[0065] In step 219, the EST client terminates the (untrusted) EST session with the EST server.

[0066] In step 220, the EST client initiates a TLS / DTLS handshake with the EST server to establish a new (trusted) TLS / DTLS session. The EST client can use an explicit TA to authenticate the EST server. After the trusted TLS / DTLS session is established, the EST procedure for registering the EST client follows the steps outlined above. Figure 1 The steps described.

[0067] Figure 3 This is a signaling flowchart illustrating an alternative to the EST procedure. Steps 301 to 310 are consistent with the above. Figure 2 Steps 201 to 210 are described identically. Therefore, the EST client establishes an untrusted TLS / DTLS session with the EST server.

[0068] In step 311, instead of sending a regular CA certificate retrieval request (e.g., / est / cacerts) to the EST server, the EST client sends a CA certificate retrieval request containing the vendor identifier (e.g., using the new path est / cacerts / {manufacturer_identifier}).

[0069] In step 312, the EST server identifies the vendor identifier and processes the CA certificate retrieval request. The EST server signs the CA certificate response using an asymmetric private key generated according to the EST server configuration.

[0070] In step 313, the EST server generates a CA certificate response. This response contains the EST server signing certificate associated with the asymmetric key pair (generated in step 203). The response is typically in CMS (Crypto-Message Syntax) format (defined by IETF RFC 5652).

[0071] In step 314, the EST server sends a CA certificate response with the EST server's signing certificate to the EST client.

[0072] In step 315, the EST client verifies the EST server's signing certificate. Upon successful verification, the client extracts the EST server's signing public key from the certificate and uses this key to verify the CA certificate. Once the CA certificate is verified in this way, it is moved to the explicit TA repository / database. Implicit TAs can be removed.

[0073] After updating the TA storage, Figure 3 Two different options, A and B, are shown to continue the EST process.

[0074] Solution A includes steps 316 and 317, which are consistent with the above-mentioned steps. Figure 2 Steps 219 and 220 are identical, as described, whereby the EST client terminates the TLS / DTLS session and initiates a new handshake. This process is easy to implement and requires almost no modification to the existing EST protocol.

[0075] Option B provides a better solution that requires only a single step 318, but may require further updates to the existing EST protocol: instead of terminating the untrusted TLS / DTLS session, the EST client verifies the session and marks it as a trusted TLS / DTLS session.

[0076] Therefore, in step 318, the EST client verifies the certificate of the TLS / DTLS EST server and marks the TLS / DTLS session as valid.

[0077] Figure 4 A signal flow diagram of an EST procedure according to another embodiment is shown. This embodiment is similar to the one described above. Figure 3 The described embodiments are similar. Steps 401 to 410 are the same as those described above. Figure 3 The steps 301 to 310 described are the same.

[0078] In step 411, after establishing an untrusted TLS / DTLS session, the EST client sends an "Establish Trust" request to the EST server containing the vendor identifier (e.g., using the new path est / establishtrust / {manufacturer_identifier}). In this step, the EST client does not request a CA certificate (as per the previous text). Figure 3 (This differs from step 311 described). Instead, the EST client first attempts to establish trust with the EST server. Once trust is established, a trusted TLS / DTLS session can be established between the EST client and the EST server, through which the EST client can request and receive CA certificates.

[0079] In step 412, the EST server identifies the vendor identifier and processes the "Establish Trust" request. The EST server signs the TLS / DTLS EST server certificate chain using the asymmetric private key generated according to the EST server configuration (created in step 403).

[0080] In step 413, the EST server generates a response (e.g., in CMS format) containing a chain of signed TLS / DTLS EST server certificates.

[0081] In step 414, the EST server sends a signed response containing the EST server's signing certificate (signed by the vendor CA), and the EST client receives the response and the certificate.

[0082] In step 415, the EST client verifies the EST server signing certificate contained in the response, extracts the EST server public key from the certificate after successful verification, and uses the public key to verify the signed TLS / DTLS EST server certificate chain.

[0083] Steps 416 to 418 are consistent with the above. Figure 3 Steps 316 to 318 are described identically. After completing step 418, the EST client can continue executing the regular EST process (e.g., as described above). Figure 1 and Figure 2 As described, send the / est / cacerts message to the EST server, followed by the equivalent of est / simpleenrollment or CoAP.

[0084] Figure 5 An apparatus 500 is shown for implementing the EST client described herein via software and hardware. The apparatus includes a transmitter 501 and a receiver 502 for transmitting / sending and receiving messages (e.g., CoAP messages using DTLS), respectively. The apparatus 500 also includes a processor 503 for processing messages and causing the EST client to execute... Figures 1 to 4 The EST client steps are shown in any of the diagrams. The device 500 also includes a memory 504 for storing certificates. The memory 503 may further include volatile or temporary memory for storing CA certificates received from the EST server before verifying the EST server.

[0085] While specific embodiments of the invention have been described above, those skilled in the art will understand that the invention can also be implemented in other ways. The above description is intended to illustrate, not limit, the invention. It will be apparent to those skilled in the art that modifications can be made to the invention without departing from the scope of the claims set forth below.

[0086] Every feature disclosed or described in this specification may be incorporated into the invention, whether used alone or in combination with any other feature disclosed or described in this specification in any suitable manner.

Claims

1. An apparatus including a Secure Transmission Registration (EST) client, the EST client being configured to: Store trust anchors; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; The TLS / DTLS EST server certificate is verified using a trust anchor; as well as If authentication fails, the TLS / DTLS handshake is completed to establish an untrusted TLS / DTLS session with the EST server.

2. The apparatus of claim 1, wherein the EST client is further configured to: Send a Certificate Authority (CA) certificate retrieval request to the EST server using the untrusted TLS / DTLS session; and Receive one or more CA certificates from the EST server.

3. The apparatus according to claim 2, wherein, The EST client is also configured to store the one or more CA certificates in temporary or volatile memory.

4. The apparatus according to claim 2 or 3, wherein, The EST client is also configured to send a verification request to the EST server to verify one or more certificates of the CA; the verification request includes a vendor identifier associated with the vendor CA associated with the trust anchor. Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; as well as Verify the one or more CA certificates.

5. The apparatus of claim 4, wherein the EST client is further configured to: after verifying the one or more CA certificates, move the one or more CA certificates to a trust anchor storage.

6. The apparatus of claim 1, wherein the EST client is configured to: The untrusted TLS / DTLS session is used to send a CA certificate retrieval request to the EST server, wherein the CA certificate retrieval request contains a vendor identifier associated with the vendor CA associated with the trust anchor. as well as Receive a CA certificate response from the EST server, wherein the CA certificate response is signed by the EST server and contains an EST signing certificate signed by the vendor CA; as well as Verify the one or more CA certificates.

7. The apparatus according to claim 4, 5 or 6, wherein the CA certificate response is in the format of Cryptographic Message Syntax (CMS).

8. The apparatus according to any one of claims 4 to 7, wherein the EST client is configured to: verify the EST signing certificate using the trust anchor, extract the public key of the EST server from the EST signing certificate, and verify the signature of the CA certificate response using the public key.

9. The apparatus of claim 1, wherein the EST client is configured to: Send a trust establishment request to the EST server, wherein the trust establishment request contains a vendor identifier associated with the vendor CA associated with the trust anchor; Receive a response from the EST server, the response containing a TLS / DTLS EST server certificate signed by the EST server and an EST server signing certificate signed by the vendor CA; Use the trust anchor to verify the EST server signing certificate; Extract the public key from the EST server signing certificate; as well as Use this public key to verify the signed TLS / DTLS EST server certificate.

10. The apparatus according to any one of claims 4 to 9, wherein, The EST client is also configured to terminate the untrusted TLS / DTLS session and initiate a new TLS / DTLS handshake with the EST server to establish a trusted TLS / DTLS session.

11. The apparatus according to any one of claims 4 to 9, wherein, The EST client is also configured to verify the untrusted TLS / DTLS session in order to establish a trusted TLS / DTLS session.

12. A method performed on an apparatus including a "Secure Transmission Registration" (EST) client, the method comprising: Store trust anchors; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; The TLS / DTLS EST server certificate is verified using the trust anchor. as well as If authentication fails, the TLS / DTLS handshake is completed to establish an untrusted TLS / DTLS session with the EST server.

13. The method of claim 12, further comprising: Send a Certificate Authority (CA) certificate request to the EST server using the untrusted TLS / DTLS session; as well as Receive one or more CA certificates from the EST server.

14. The method of claim 13, further comprising storing the one or more CA certificates in temporary or volatile memory.

15. The method according to claim 13 or 14, further comprising: Send a verification request to the EST server to verify the one or more CA certificates, wherein the verification request includes a vendor identifier associated with the vendor CA associated with the trust anchor; Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; as well as Verify the one or more CA certificates.

16. The method of claim 15, wherein after verifying the one or more CA certificates, the one or more CA certificates are moved to the trust anchor storage.

17. The method of claim 12, further comprising: The untrusted TLS / DTLS session is used to send a CA certificate retrieval request to the EST server, wherein the CA certificate retrieval request contains a vendor identifier associated with the vendor CA associated with the trust anchor. as well as Receive a CA certificate response from the EST server, wherein the CA certificate response is signed by the EST server and contains an EST signing certificate signed by the vendor CA; as well as Verify the one or more CA certificates.

18. The method of claim 15, 16 or 17, wherein the CA certificate response is in the Cryptographic Message Syntax (CMS) format.

19. The method according to any one of claims 15 to 18, further comprising: Verify the EST signing certificate using the trust anchor; Extract the public key of the EST server from the EST signing certificate; The public key is then used to verify the signature of the CA certificate response.

20. The method of claim 12, further comprising: Send a trust establishment request to the EST server, wherein the trust establishment request includes a vendor identifier associated with the vendor CA associated with the trust anchor. Receive a response from the EST server, the response including a TLS / DTLS EST server certificate signed by the EST server and an EST server signing certificate signed by the vendor CA; Use the trust anchor to verify the EST server signing certificate; Extract the public key from the EST signing certificate; as well as Use this public key to verify the signed TLS / DTLS EST server certificate.

21. The method according to any one of claims 15 to 20, further comprising terminating the untrusted TLS / DTLS session and initiating a new TLS / DTLS handshake with the EST server to establish a trusted TLS / DTLS session.

22. The method according to any one of claims 15 to 20, further comprising verifying the untrusted TLS / DTLS session to establish a trusted TLS / DTLS session.

23. A system comprising: The EST server is configured as follows: Generate asymmetric key pairs; Send a Certificate Signing Request (CSR) to the supplier CA. Receive the EST signing certificate from the supplier CA and associate the certificate with the supplier identifier associated with the supplier CA; Use the private key of the asymmetric key pair to sign one or more Certificate Authority (CA) certificates; The EST client is configured as follows: Store the trust anchor associated with the vendor CA; Initiate a Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) handshake with the EST server; Receive the TLS / DTLS EST server certificate from the EST server; The TLS / DTLS EST server certificate is verified using the trust anchor. as well as If authentication fails, the TLS / DTLS handshake is completed to establish an untrusted TLS / DTLS session with the EST server.

24. The system of claim 23, wherein the EST client is further configured to: Send a Certificate Authority (CA) certificate retrieval request to the EST server using the untrusted TLS / DTLS session; Receive one or more CA certificates from the EST server; Send a verification request to the EST server to verify the one or more CA certificates, wherein the verification request contains a vendor identifier associated with the vendor CA; Receive a verification response from the EST server, wherein the verification response includes a CA certificate response signed by the EST server and an EST signing certificate signed by the vendor CA; as well as Verify the one or more CA certificates.

25. A method for establishing a Trusted Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) session between an EST client and an EST server, the method comprising: The EST client stores a trust anchor, which is associated with a vendor CA. Initiate a TLS / DTLS handshake between the EST client and the EST server; Send the TLS / DTLS EST server certificate from the EST server to the EST client; Use the aforementioned trust anchor to verify the TLS / DTLS certificate; as well as If authentication fails, the TLS / DTLS handshake is completed to establish an untrusted TLS / DTLS session between the EST client and the EST server.

Images