Apparatus and method for enhancing secure channel handshake by attestation

Abstract

An apparatus and method for incorporating remote attestation into a standardized secure channel handshake without modifying existing message structures or existing secure channel implementations. At a client side, the method comprises: generating a copy based on an exchanged secure channel message; collecting attestation measurements representing a current state of the communication device; calculating an attestation private key based on a device private key and the hash of the attestation measurement; generating an attestation signature by signing the copy using the calculated attestation private key; the attestation signature is sent over a computer network. At a server side, the method comprises the following steps: extracting a public key from a received identity certificate; generating a copy based on the exchanged secure channel message; calculating an attestation public key based on the extracted public key, a predefined reference hash, and the set of generator points; and verifying the attestation signature based on the attestation public key.

Description

Technical Field

[0001] The various aspects of the disclosed embodiments generally relate to secure network communications, and more specifically to remote authentication. Background Technology

[0002] The increasing volume of transactions conducted on the internet, many of which are commercial and financial in nature, necessitates reliable and secure network communication protocols (also known as handshakes). This need is typically addressed using secure channels, such as ubiquitous transport layer security (TLS) or other standardized secure channel protocols.

[0003] Secure channel protocols (such as TLS) use cryptography to ensure the privacy and integrity of data exchanged over computer networks and provide endpoint authentication based on digital certificates. However, these protocols do not readily provide any guarantees regarding the integrity of the software and hardware platforms on which secure channel endpoints run.

[0004] Remote attestation (RA) is a technique used to ensure the integrity of a computer platform or endpoint by sending proof of proof from one endpoint (i.e., the prover) to a second endpoint (i.e., the verifier). The verifier can then examine the proof of proof to establish a level of trust between the endpoints.

[0005] Developing new secure channel protocols or modifying existing protocols to include remote authentication can be costly and difficult to distribute to numerous endpoints and data centers requiring remote authentication. Disadvantageously, traditional methods of incorporating RA into existing secure channel protocols such as TLS require changes to message formats and / or implementation code. Therefore, adding RA to existing secure channel implementations using these traditional methods requires significant time and developer resources, creating obstacles to their adoption and use.

[0006] Therefore, there is a need for improved apparatus and methods that can enhance existing secure channel handshakes without requiring costly modifications to the implementation code. Consequently, it is desirable to provide methods and apparatus that address at least some of the aforementioned problems. Summary of the Invention

[0007] The disclosed embodiments relate to apparatus and methods for enhancing secure channel handshakes with proofs. The disclosed embodiments utilize the properties of digital signature algorithms based on the discrete logarithm problem (DLP) (referred to herein as additional subkeys) to add remote proofs to standardized secure channel handshakes in a manner that conforms to a defined message structure and avoids modification of existing secure channel implementations. Using unmodified secure channel implementations facilitates the use of existing software images, such as those available in cloud data centers and mobile communication devices. It avoids the costs of developing and distributing custom secure channel implementations.

[0008] According to the first aspect, the above and other implementations and advantages are obtained through a device including a processor communicatively coupled to a memory. The memory includes program instructions that, when executed by the processor, cause the device to send a secure channel creation request message via a computer network and receive one or more secure channel creation response messages from the computer network. The processor generates a copy based on one or more of the secure channel creation request message and the one or more secure channel creation response messages. The one or more proof measurements represent the current state of the device. The processor calculates a proof private key based on a device private key and the one or more proof measurements, generates a first proof signature by signing the copy using the proof private key, and sends a first identity certificate and the first proof signature via the computer network.

[0009] In one possible implementation, the processor executes the program instructions causing the device to generate the proof private key by: generating a measurement hash at least in part based on the proof measurement; generating a proof hash based on the measurement hash and the order of the group generator point; and calculating the proof private key by adding the proof hash to the device private key and then taking the modulo of the order of the group generator point. The device private key and proof information are then combined into the proof key, such that the proof signature can verify whether the endpoint possesses the device private key and verify the integrity of the endpoint platform.

[0010] In one possible implementation, the proof measurement includes one or more of the device's secure boot state, a hash of the device's boot image, and a hash of the device's application code. Including these measurements in the proof measurement enables the proof signature to verify the integrity of the software executed on the endpoint.

[0011] In one possible implementation, the apparatus includes a rich execution environment and a secure execution environment. The secure execution environment includes one or more of a trusted execution environment and a hardware security module (HSM). The secure execution environment is used to protect the device private key, generate the proof private key, and generate the proof signature. Including the secure execution environment provides a higher level of trust in the proof measurement and the generated signature.

[0012] In one possible implementation, the secure execution environment includes one or more software-based hardware security modules (HSMs) or trusted execution environments. Using a software-based secure execution environment can simplify deployment in a virtual environment.

[0013] In one possible implementation, the one or more secure channel creation response messages include a second identity certificate and a second proof signature. The apparatus is also used to verify the second proof signature based on a predefined reference hash. Receiving and verifying the second proof signature provides the client endpoint with a higher level of trust in the server's integrity.

[0014] In one possible implementation, the apparatus is used to verify the second proof signature by: extracting a public key from the second identity certificate; generating a transcript based on one or more of the Create Secure Channel Request message and the one or more Create Secure Channel Response messages; calculating a proof public key based on the extracted public key, the predefined reference hash, and the group generator point; and verifying the second proof signature based on the proof public key. Verifying the second proof signature based on the extracted public key and the hash of the proof evidence improves the trust level of the server.

[0015] According to the second aspect, the above and other implementations and advantages are obtained by using a method that enhances the secure channel handshake with proof. In one embodiment, the method includes: sending a secure channel creation request message over a computer network; receiving one or more secure channel creation response messages from the computer network; generating a copy based on one or more of the secure channel creation request message and the one or more secure channel creation response messages; and collecting one or more proof measurements. The one or more proof measurements represent the current state of the communication device. The method further includes: calculating a proof private key based on a device private key and the one or more proof measurements; generating a first proof signature by signing the copy using the proof private key; and sending a first identity certificate and the first proof signature over the computer network.

[0016] In one possible implementation, the generation of the proof private key includes: generating a measurement hash at least partially based on the proof measurement; generating a proof hash based on the measurement hash and the order of the group generator point; and calculating the proof private key by adding the proof hash to the device private key and then taking the modulo of the order of the group generator point. The device private key and proof information are then combined into the proof key, such that the proof signature can verify whether the endpoint possesses the device private key and verify the integrity of the endpoint platform.

[0017] In one possible implementation, the one or more Create Secure Channel response messages include a second identity certificate and a second proof signature. The method is also used to verify the second proof signature based on a predefined reference hash. Receiving and verifying the second proof signature provides the client endpoint with a higher level of trust in the server's integrity.

[0018] In one possible implementation, verifying the second proof signature includes: extracting a public key from the second identity certificate; generating a copy based on one or more of the Create Secure Channel Request message and the one or more Create Secure Channel Response messages; calculating a proof public key based on the public key and a predefined reference hash; and verifying the second proof signature based on the proof public key. Verifying the second proof signature based on the extracted public key and the hash of the proof evidence increases the server's trust level.

[0019] According to the third aspect, the above and other implementations and advantages are obtained by using a method that enhances the secure channel handshake with proof. In one embodiment, the method includes: receiving a secure channel creation request message from a computer network; sending one or more secure channel creation response messages through the computer network; receiving an identity certificate and a proof signature from the computer network; generating a copy based on one or more of the secure channel creation request message and the one or more secure channel creation response messages; extracting a public key from the identity certificate; calculating a proof public key based on the extracted public key and a predefined reference hash; and verifying the proof signature based on the proof public key and the copy. When the proof signature is valid, the secure channel is established. When the proof signature is invalid, the secure channel is rejected.

[0020] In one possible implementation, the predefined reference hash includes one or more predefined reference hashes. When the proof signature is invalid, the method further includes: selecting a next reference hash from the one or more predefined reference hashes; repeating the calculation of the proof key and verifying the proof signature step for each of the one or more predefined reference hashes until the proof signature is verified or all predefined reference hashes in the one or more predefined reference hashes have become invalid. Using multiple reference hashes to verify endpoints increases the flexibility of the proof process.

[0021] In one possible implementation, the one or more predefined reference hashes are embedded in a digital certificate received from the computer network. Embedding reference hashes in the identity document of the client endpoint provides a useful method for managing and distributing reference hashes.

[0022] According to the fourth aspect, the above and other implementations and advantages are obtained through a computer program product comprising non-transitory computer program instructions that, when executed by a processor, cause the processor to perform the method according to the disclosed embodiments. The computer program product facilitates the distribution of the above methods to various computing devices.

[0023] These and other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein in conjunction with the accompanying drawings. However, it should be understood that such description and drawings are for illustrative purposes only and should not be construed as limiting the invention; any limitation on the invention should be referenced to the appended claims. Additional aspects and advantages of the invention will be set forth in the following description, and some aspects and advantages will be apparent from the description or may be learned by practicing the invention. Furthermore, aspects and advantages of the invention may be realized and obtained by means or combinations particularly pointed out in the appended claims. Attached Figure Description

[0024] In the following detailed description of the invention, the invention will be explained in more detail with reference to exemplary embodiments shown in the accompanying drawings, wherein like references indicate like elements, and:

[0025] Figure 1 A block diagram of an exemplary computing device for enhancing a secure channel protocol with remote verification, incorporating aspects of the disclosed embodiments;

[0026] Figure 2 A flowchart illustrating an exemplary method for generating a proof signature in conjunction with various aspects of the disclosed embodiments;

[0027] Figure 3A flowchart illustrating an exemplary method for verifying a certified signature in conjunction with various aspects of the disclosed embodiments;

[0028] Figure 4 A flowchart illustrating an exemplary method for demonstrating enhanced secure channel handshakes on the client side, incorporating aspects of the disclosed embodiments;

[0029] Figure 5 A block diagram of an exemplary system for demonstrating enhanced secure channel handshakes in conjunction with various aspects of the disclosed embodiments;

[0030] Figure 6 This is a flowchart illustrating an exemplary server-side method for demonstrating enhanced secure channel handshakes, incorporating aspects of the disclosed embodiments. Detailed Implementation

[0031] Figure 1 A block diagram of an exemplary apparatus 100 for enhancing a secure channel handshake with remote proof, incorporating aspects of the disclosed embodiments, is shown. The exemplary apparatus 100 of the disclosed embodiments generally includes a computing device 100 for utilizing the properties of an additional subkey to provide remote proof in a manner conforming to standardized secure channel protocols during secure channel establishment without modifying currently available secure channel implementations. Among other benefits, the use of the novel additive subkey formula disclosed herein (referred to herein as the proof key) facilitates the inclusion of remote proof in standard secure channel protocols in a manner conforming to existing message formats, without requiring modification of currently available implementations. These improvements and advantages are partly obtained by using the proof key to generate and verify the information exchanged during the secure channel handshake.

[0032] refer to Figure 1 In one embodiment, exemplary device 100 includes a processor 102 communicatively coupled to memory 104. Memory 104 includes program instructions that, when executed by processor 102, cause device 100 to: send a secure channel creation request message 122 via computer network 170; receive one or more secure channel creation response messages 124, 126 from computer network 170; generate a copy based on one or more of the secure channel creation request message 122 and the secure channel creation response messages 124, 126; and collect one or more evidentiary measurements. One or more proof measurement and representation devices 100 demonstrate the current state of the device.

[0033] Based on device private key and one or more proof measurements Computation proves the private key The first proof signature 145 is obtained by using the proof private key. The first identity certificate 144 and the first proof signature 145, generated by signing the copy, are sent via computer network 170.

[0034] The disclosed embodiments use remote authentication to enhance the secure channel establishment protocol, also referred to herein as a secure channel handshake. Embodiments of the exemplary computing device 100 are used to provide remote authentication in a manner consistent with existing secure channel messaging protocols, supported by available secure channel software implementations without modification.

[0035] Device 100 may be any desired type of computing or communication device, including but not limited to mobile communication devices such as smartphones, wearable devices, or tablets. In some embodiments, device 100 may be a personal computing device such as a laptop or other type of personal computing device, or a server device used in cloud computing data centers, or any desired computing device including a processor, memory, and modules for communicating via a computer network.

[0036] like Figure 1 As shown in the example, processor 102 is communicatively coupled to memory 104 for reading data stored in memory 104 and performing operations thereon. In some embodiments, device 100 may also include system memory (not shown), such as a disk drive or solid-state drive, for providing high-capacity long-term storage capabilities.

[0037] Processor 102 may typically include any suitable processing device, including but not limited to: high-performance multi-core computer processing devices, such as those used in large cloud computing data centers; multi-core or single-core microprocessors, such as those used in workstations and laptops; processing devices embedded in systems, such as systems on a chip (SoC); or any suitable or dedicated processing device, such as those used in mobile communication devices; telecommunications equipment; and smart devices configured for the Internet of Things (IoT).

[0038] Memory 104 may include any desired type or combination of computer-accessible memory, such as random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile memory.

[0039] Computer network 170 is communicatively coupled to device 100 for exchanging data and messages between device 100 and other endpoints or nodes in computer network 170. Computer network 170 can be any suitable type of computer network for enabling device 100 or other computerized devices (also referred to herein as network nodes) to share information and resources. Computer network 170 may include any desired type of physical medium, such as wired, optical, or wireless media.

[0040] Wired networks include any desired type of computer network used to carry information over network links (such as links made of wires) using electrical signals. Optical networks include any type of network used to carry information over network links (such as links made of optical fiber) using optical signals. Wireless networks include any suitable type of computer network used to transmit information over the air using radio signals (such as Wi-Fi, Bluetooth, Long Term Evolution (LTE), or other wireless broadband communication mechanisms).

[0041] The system software included in the computing device 100 can provide a network communication stack when needed, such as the Internet Protocol suite, commonly known as the Transmission Control Protocol / Internet Protocol (TCP / IP) stack. The network communication stack is used to provide reliable, connection-oriented transport services.

[0042] In today's distributed computing environment, the need for network security is well understood. To meet this need, various secure channel protocols or handshakes have been developed to protect information transmitted over computer networks (e.g., computer network 170). These secure channel protocols use cryptography to provide privacy, integrity, and authenticity for information exchanged over computer networks. One such protocol is the ubiquitous transport layer security (TLS) protocol, developed and standardized by the Internet Engineering Task Force (IETF) based on various requests for comment (RFCs). The latest version is designated as TLS 1.3.

[0043] To aid understanding, certain features of the embodiments disclosed herein will be described with reference to the TLS protocol. However, those skilled in the art will readily recognize that the disclosed embodiments are not limited thereto and can be advantageously used in any suitable secure channel protocol that includes certificate verification or other types of messages, such as those containing digital signatures.

[0044] A secure channel typically has two endpoints. The endpoint that initiates the establishment of the secure channel is referred to here as the client endpoint, or simply the client. During the secure channel handshake, the client sends a request to the endpoints that need to connect to create a secure channel. The endpoint that receives the request to create a secure channel is referred to here as the server endpoint, or simply the server. Once the secure channel is successfully established, it will create a bidirectional connection between the client and the server.

[0045] In one embodiment, apparatus 100 includes a secure execution environment 108 for protecting confidential data such as cryptographic operations and key materials 110, and for providing additional trust for secure operations such as collecting proof measurements. The secure execution environment 108 can be any suitable type of secure or trusted execution environment, such as, but not limited to, a trusted execution environment (TEE), a trusted application (TA), a secure enclave, a trusted platform module (TPM), a trusted bootloader, or other suitable security components. When needed, the secure execution environment 108 may include a hardware security module (HSM) or a software-based HSM for protecting confidential key materials and cryptographic operations.

[0046] When needed, the signature generation application can be included in the secure execution environment 108. The signature generation application can be used to sign data passed to the secure execution environment 108 by application software running in the rich execution environment. The signature generation application can also be used to protect confidential information, such as the device private key or other confidential key material. Optionally, the signature generation module can be implemented as a hardware component, such as a hardware security module (HSM), or as a software component, such as a software HSM, a trusted execution environment, or other appropriately secure software cryptographic modules.

[0047] The verification module is used to generate trusted measurements of the system and application software, such as transport layer security (TLS) implementations. The secure execution environment 108 can include any desired type of secure or trusted execution environment, such as, but not limited to, a trusted execution environment (TEE), a trusted application (TA), a trusted platform module (TPM), a trusted bootstrap, or other suitable trusted modules of desired type.

[0048] The term "public-private key pair" used here typically refers to a pair of keys used with asymmetric encryption algorithms, where data encrypted using one key in the public-private key pair can be decrypted using only the corresponding other key in the same public-private key pair. For example, data encrypted using the private key can only be decrypted using the corresponding public key in the same public-private key pair.

[0049] The security of various asymmetric cryptography-based digital signature algorithms, such as the widely used elliptic-curve digital signature algorithm (ECDSA) and Edwards-curve digital signature algorithm (EdDSA), assumes that the discrete logarithm problem (DLP) is exponentially difficult with respect to group size. To aid understanding, exemplary embodiments of the enhanced secure channel protocol disclosed herein are described with reference to the elliptic-curve digital signature algorithm (ECDSA). However, those skilled in the art will readily recognize that other DLP-based digital signatures can be similarly extended to support embodiments of the subkeying process disclosed herein without departing from the spirit and scope of the invention.

[0050] As used in this article, the phrase "signing a data block using a key" or "creating a signature on a data block using a key" refers to the process of generating a digital signature for a data block using a specific encryption key. This involves using a key... generated data blocks The digital signature on the device is represented here using the following symbols: ,in, It is a data block. This is the signature key. For example, the encryption key could be the private key in a public-private key pair. A common method for generating a digital signature is to create a digest of the data block by calculating its cryptographic hash. The digest is then encrypted with the encryption key, resulting in the ciphertext, which becomes the digital signature. Verification of a digital signature can be accomplished by decrypting it using the public key and then comparing the decrypted value with a newly created hash of the data block.

[0051] It should be understood that some advantages of the disclosed embodiments are achieved by utilizing certain characteristics of DLP-based cryptographic algorithms. The primary property of interest herein is referred to as the additional subkey. As a non-limiting example, the following discussion provides an overview of the construction and use of the additional subkey as illustrated using ECDSA. As stated above, the additional subkey mechanism disclosed herein can be advantageously used with other DLP-based cryptographic systems without departing from the spirit and scope of the disclosed embodiments.

[0052] The construction of the additional subkey begins with the selection of the base private key. Sum generator points In the following discussion, the private key... Sum generator points Based on ECDSA, elliptic curve scalar multiplication is used to group generator points. Multiply by the basic private key Obtain the corresponding basic public key .

[0053] As is known in the art, elliptic curve scalar multiplication, also known as elliptic curve point multiplication, is an operation that uses elliptic curve point addition to add points along an elliptic curve to itself in sequence, where the scalar value defines the number of times the addition is performed.

[0054] The cryptographic operations described in this article use two types of addition: basic integer or scalar addition and block operations. When adding two scalar values, for example, when adding the basic private key... and random integers At that time, standard integer addition is used to create sums. When adding a point from a finite group, the corresponding group operation is applied. For example, in the case of ECDSA, when adding a basic public key... and child public key At that time, elliptic curve point addition is used to generate sums. Both of these operations are represented here by the plus sign "+". Those skilled in the art will easily distinguish between these two types of addition based on the context.

[0055] It can be seen that for 0 and integer values any random integer between ,in, For group generator points The order of the ordered pairs To form a valid public-private key pair, where, For the basic private key, h is the child private key. For the corresponding public key. Ordered pairs Form a valid additive subkey pair. The subpublic key is used for reasons that will be discussed further below. This can be referred to as proving the public key and the sub-private key. This can be referred to as proving the private key.

[0056] Sub-key The generation can be achieved by first using the basic private key. With random numbers Add them together to get the sub-private key To complete. Sub-public key Then you can use the group generator point Multiply by child private key To generate. Or, a sub-public key. You can use the group generator point Multiply by a random number Generate intermediate key To generate it. Then you can use the basic public key. Add to intermediate key To calculate the sub-public key intermediate key It can be expressed in equation form as follows: .

[0057] The exemplary computing device 100 uses the aforementioned properties of the additional subkey to extend the existing secure channel protocol with remote authentication in a manner consistent with and supported by existing secure channel implementations. Using existing secure channel implementations without modification can facilitate the use of the embodiments disclosed herein with standard software images, such as those available in cloud computing data centers and mobile communication devices, thereby eliminating deployment barriers and reducing implementation costs.

[0058] When a secure channel is required, device 100 sends a Create Secure Channel Request message 122 to the desired server endpoint (not shown) via computer network 170. The server endpoint can be any desired service, such as a banking application, online store, or other site requiring network security. When using TLS, the Create Secure Channel message takes the form of a ClientHello message 130.

[0059] In the illustrated embodiment, device 100 receives one or more Create Secure Channel Response messages 124, 126 from computer network 170. Continuing with the TLS example, the one or more Create Secure Channel Response messages 124, 126 may include a ServerHello message 132, an EncryptedExtensions message 134, a CertificateRequest message 136, a Certificate message 138 containing an identity certificate representing the server's identity and public key, a CertificateVerify message 140, and a Finished message 142. As will be discussed further below, the CertificateVerify message 140 includes a digital signature 141 on a known dataset. In conventional secure channel protocols, this signature can be used to verify whether the server endpoint possesses the private key corresponding to the server certificate 138.

[0060] A transcript is generated, wherein the transcript includes data known to both endpoints of the secure channel, i.e., data known to both device 100 and the server endpoint. In some embodiments, the transcript may be generated based on one or more of a Create Secure Channel Request message 122 and one or more Create Secure Channel Response messages 124, 126. Non-limiting examples of suitable transcripts are defined by the TLS protocol and include the running hash of messages exchanged during the handshake.

[0061] Generate proof measurement Among them, the proof of measurement These measurements indicate the state of the computing device. They help verifiers ensure that the integrity of device 100 and the software image currently running on device 100 has not been compromised. Suitable proof measurements include secure boot state, boot image hash, kernel hash, hash of the binary code of the TLS endpoint application, and other similar security-related metrics. In one embodiment, proof measurements... It can be created by the trusted coprocessor 108 or the trusted platform module (TPM) based on the boot process or measurement of the application code. In device 100, the secure execution environment 108 can be used to reliably generate application measurements or other information to ensure endpoint integrity.

[0062] In traditional secure channel protocols (such as TLS), the device's private key is used. Sign the copy to ensure that the endpoint has the correct private key. The proof. In the embodiments disclosed herein, the device private key In the secure channel handshake, it is replaced by the proof private key. Among them, proving the private key Based on device private key and proof measurement Both include an additional sub-private key. Therefore, verification uses the proof private key. The created signature can verify whether the endpoint possesses the device's private key. And to prove whether the evidence is correct. By using the proof private key. The copy is signed to generate a proof signature 145. This proof signature 145 is then transmitted along with the device's identity certificate 106 to a server endpoint, where it can be used to establish trust within the device 100.

[0063] Continuing with the TLS example, the device's identity certificate 106 and proof signature 145 can be transmitted during the TLS handshake using a Certificate message 144, followed by a CertificateVerify message 146, and finally a Finished message 148. The proof signature 145, which includes remote proof information, can be included in the CertificateVerify message 146 without any modification to the standard TLS CertificateVerify message.

[0064] Figure 2 This is a flowchart illustrating an exemplary method 200 for generating a proof signature in conjunction with various aspects of the disclosed embodiments. The exemplary method 200 is suitable for calculating a proof private key. And generate the above reference. Figure 1 The proof signature described is 145.

[0065] Exemplary method 200 begins by generating a 202 copy based on data available to both endpoints during a secure channel handshake. For example, the copy could be a running hash of messages exchanged during the handshake, such as a copy defined by a TLS handshake.

[0066] Then 204 proof measurements were collected. Advantageously, the collected proof measurements... The integrity of the proof device 100 and the software executed thereon is not compromised. (Based on proof measurement) Generate 206 measurement hash By measuring hash Mapping (e.g., using modulo operation) to an interval To generate a 208 proof hash ,in, It is a group generator point The order of.

[0067] This can be achieved by using the device's private key (e.g., the private key associated with device 100). ) and proof hash Add and then apply to the group generator point To calculate the private key, take the modulo of the order of the 2^10. Prove the private key It can be expressed in equation form as: , where n is the order of the generator point P. Then, by using the proof private key... Sign the copy to generate a 212 proof signature.

[0068] Figure 3 This is a flowchart illustrating an exemplary method 300 for verifying a certified signature in conjunction with various aspects of the disclosed embodiments. The exemplary method 300 of the disclosed embodiments is suitable for use in the aforementioned apparatus 100, or in any suitable node on a computer network, where it is desirable to ensure the identity and integrity of the endpoints while establishing a secure communication channel.

[0069] Exemplary method 300 begins by receiving a 304 certificate and a certificate signature during a secure channel handshake. The received certificate can be any suitable digital certificate, such as a traditional identity certificate generated by a trusted certificate authority. In some embodiments, the received certificate can be an identity certificate signed by a trusted certificate authority, wherein the identity certificate binds the public key associated with the identified entity to the identity of the certificate holder. Optionally, additional information can be embedded in the received certificate.

[0070] For example, additional information may include one or more reference hashes used to assist in remote proof. The received proof signature may be a proof signature, such as the proof signature described above, wherein the proof signature is generated based on the proof key and one or more proof measurements.

[0071] The term "embedding information in a certificate" as used here refers to including information in the certificate body and incorporating that information into the certificate's signature. Therefore, by embedding information into the certificate, the certificate's signature ensures the integrity of the embedded information.

[0072] Extract the public key associated with the endpoint of the secure channel from the received certificate (306). When needed, the received certificate can be verified based on the digital signature it contains, for example by obtaining a public key from a trusted certificate authority and verifying the signature based on that public key.

[0073] A 308 copy is generated based on a method agreed upon by the two endpoints during a secure channel handshake. An example of a suitable copy is the message copy defined in the TLS protocol. Alternatively, the copy can be any expected data value that can be independently reproduced by the two endpoints during the secure channel handshake.

[0074] Next, based on the extracted public key Predefined reference hash Sum generator points To calculate the 310 proof public key A predefined reference hash represents the hash of a known good proof measure. When the proof hash generated by the client endpoint matches the known good reference hash, the integrity of the client endpoint can be trusted. (Predefined reference hash) It can be stored locally, such as in a database or other suitable data store. Alternatively, a predefined reference hash can be used. It can be obtained from trusted sources, such as trusted institutions accessible through computer networks.

[0075] Prove the public key This is the sub-public key corresponding to the additional sub-key pair described above. Recall that the extracted public key equals the device private key multiplied by the group generator point. By multiplying the group generator by the reference hash... and the result is compared with the extracted public key. Add and then apply to the group generator point order To compute proof of public key The public key can be expressed in equation form as: .

[0076] It can be based on the proof public key The generated copy is verified (312) to prove the signature. If the signature verification (314) is valid, the endpoint continues (316) to establish a secure channel. If the signature verification (314) fails, the handshake terminates, and the secure channel is not established (320).

[0077] In some embodiments, it may be advantageous to maintain multiple reference hashes for a single endpoint. When multiple reference hashes are available, method 300 checks an additional reference hash 318 before the secure channel handshake fails 320. If the additional reference hash is available, method 300 repeats 322 to compute the public key 310 and verify 312 to prove the signature until the signature is successfully verified or all available reference hashes have been tried.

[0078] Figure 4 This is a flowchart illustrating an exemplary method 400 for enhancing a secure channel handshake with proofs, incorporating aspects of the disclosed embodiments. The exemplary method 400 is suitable for including remote proofs in a secure channel handshake and facilitates the addition of remote proofs to standard secure channel protocols, such as TLS, without altering the message structure or modifying existing implementations. The disclosed embodiments facilitate the easy addition of remote proofs to off-the-shelf software implementations, such as those available in standard images, images provided by cloud data centers, or images available on mobile communication devices.

[0079] Exemplary method 400 (also known as a secure channel handshake) begins with sending a 402 request to create a secure channel. A secure channel creation request can be sent, for example, from a client endpoint to a server endpoint, such as an endpoint listening for connection requests on a computer network. A suitable example of a secure channel creation request is the ClientHello message defined in the TLS protocol.

[0080] The server responds by sending one or more Create Secure Channel response messages, to which the client endpoint receives a 404 response. These one or more Create Secure Channel response messages can include messages such as ServerHello, Encrypted Extensions, CertificateRequest, Certificate, CertificateVerify, and Finished, as described above and defined by the TLS protocol.

[0081] A 406 copy is generated based on information known to both the client and server endpoints of the established secure channel. A non-limiting example of a suitable copy is defined by the TLS protocol, which is based on the running hash of the messages exchanged during the handshake.

[0082] One or more proof measurements (408) are collected, wherein the one or more proof measurements represent the current state of the communication device. As used herein, the term "communication device" refers to any computerized device capable of communicating via a wired or wireless network. These measurements represent the current state of the computing device on which the endpoint's application code is executing, and may include any appropriate measurements useful for establishing the integrity of the endpoint. Proof measurements include information such as secure boot state, boot image hash, kernel hash, hash of the binary code of the TLS endpoint application, and other similar security-related metrics. Optionally, proof measurements (408) may be collected in a secure execution environment or by a trusted application executing in a trusted execution environment.

[0083] The computation 410 of the proof private key combines the device private key with the proof information to form an additional private key. Incorporating the proof measurement into the proof private key helps ensure the integrity of the client endpoint platform through the signature created using the proof private key. Any suitable private key can be advantageously used as the device private key, such as a private key associated with the endpoint's platform, a private key associated with the endpoint's application code, a key associated with the hardware on which the endpoint's application code is executing, or other suitable private keys as needed. The device private key can be any type of private key, such as an ECDSA private key or a private key derived from any suitable DLP-based cryptosystem that supports the creation of additional subkeys.

[0084] Suitable proof information may include collected proof measurements or hashes of collected proof measurements. The proof private key is an appended private key, which can be formed by adding the hash of the proof measurement to the device private key and then taking the modulo of the order of the group generator point. The corresponding proof public key is calculated by multiplying the group generator point by the proof private key.

[0085] A 412 proof signature is generated by signing the copy using the proof private key. As mentioned above, verifying the proof signature ensures that the endpoint possesses the device private key and that the endpoint's integrity has not been compromised.

[0086] Then, as part of the secure channel handshake, the endpoint's identity certificate and proof signature are sent to the server endpoint via I41. The identity certificate can be any suitable form of digital certificate that uses a digital signature to bind the endpoint's identity to the endpoint's public key. For example, the public key could be the device's public key corresponding to the device's private key on which the calculation of the proof private key is based. The identity certificate is favorablely signed by a trusted certificate authority, thus facilitating the verification of the identity certificate based on any suitable trusted private key infrastructure (PKI).

[0087] Optionally, the identity certificate may also include one or more reference hashes to provide proof information about the client endpoint. The server endpoint can use the included one or more reference hashes when verifying the proof signature.

[0088] Figure 5 This is a block diagram of an exemplary system 500 for enhancing a secure channel handshake with proof, incorporating aspects of the disclosed embodiments. In the exemplary embodiment shown by system 500, a client endpoint (also referred to as a prover 510) initiates a secure channel handshake with a server endpoint (also referred to as a verifier 512). As used herein, the term "provider" refers to an entity that provides proof evidence in a remote proof scheme, and the term "verifier" refers to an entity that examines the provided proof evidence in a remote proof scheme to verify the integrity of the prover.

[0089] In some embodiments, the prover may include a trusted module 514 for providing a secure execution environment in which cryptographic operations and the collection of proof measurements can be performed in a trusted manner. The trusted module, also referred to herein as a secure execution environment, can be any suitable form of secure execution environment, including but not limited to a trusted execution environment (TEE), a trusted application (TA), a secure enclave, a trusted platform module (TPM), a trusted bootstrap, or other suitable security components. When needed, the trusted module 514 may include a hardware security module (HSM) or a software-based HSM for protecting confidential key material and cryptographic operations.

[0090] When needed, the verifier may include a signature verification component 516 for protecting confidential key material and cryptographic operations. The signature verification module 516 may be any suitable type of security component, such as, but not limited to, a trusted execution environment (TEE), a trusted application (TA), a secure enclave, a trusted platform module (TPM), a trusted bootstrap, or other suitable security components. When needed, the signature verification component 516 may include a hardware security module (HSM) or a software-based HSM for protecting confidential key material and cryptographic operations.

[0091] Database 518 or other suitable data storage may be included in server endpoint 512 to store reference hashes. Optionally, database 518 may include multiple reference hashes for a single endpoint, or, if needed, may include reference hashes corresponding to multiple endpoints.

[0092] Remote proofs can be added to the secure channel handshake by collecting 501 proof measurements from the endpoint. Proof measurements can include any expected values ​​useful for ensuring the integrity of the endpoint device platform, such as secure boot state, boot image hash, kernel hash, hash of the TLS endpoint application's binary code, and other suitable security-related metrics.

[0093] The certifier 510 requests a signature 502 on the copy or other suitable data value based on the device private key d. The trusted module 514 calculates 503 the certifying private key based on the device private key d measured in the certifying module. Then, a 504 certifying signature is generated by signing the copy or other suitable data value with the calculated certifying private key. An example of a suitable data value is a copy as defined in the TLS protocol.

[0094] Once the certificate signature has been generated (504), it is transmitted (505) to the server endpoint (512). The transmission of the certificate signature (505) can be accomplished by including the certificate signature in a handshake message such as the CertificateVerify message defined by the TLS protocol.

[0095] Upon receiving the proof signature at step 505, verifier 512 sends the proof signature along with the client endpoint's public key at step 506 to signature verification module 516, where it can be verified based on the endpoint's public key and a predetermined reference hash. The predetermined reference hash corresponds to a set of known and sound proof measures of the client endpoint 510 and can be stored in database 518 or other suitable data storage within the verifier. Optionally, verifier 512 can retrieve the predetermined reference hash from a trusted authority when needed.

[0096] The signature verification module 516 computes the proof public key by adding the endpoint's public key to a predetermined reference hash and then taking the modulo of the order of the group generator point. The proof public key is then used to verify the proof signature. In embodiments where multiple predetermined reference hashes are available at endpoint 510, the signature verification module 516 can be used to attempt to verify the proof signature based on each predetermined reference hash. When any predetermined reference hash results in a proof key that leads to successful signature verification, the integrity of the endpoint is not compromised, and the handshake can continue.

[0097] Figure 6 This is a flowchart of an exemplary server-side method 600 for enhancing a secure channel handshake with proof, incorporating aspects of the disclosed embodiments. The exemplary method 600 of the disclosed embodiments facilitates the incorporation of remote proof information into a standardized secure channel protocol without modifying predefined message formats or standard secure channel implementations.

[0098] The server endpoint does not initiate the creation of a secure connection; instead, it listens for incoming connection requests. A secure channel handshake begins when the server endpoint receives a 602 Create Secure Channel Request message. The request to create a secure channel may have been sent by any appropriate client endpoint over the computer network. The client endpoint making the request is verified through the secure channel handshake before a secure channel is established. The Create Secure Channel message can be any expected type of secure channel request message, such as the ClientHello message used in a TLS handshake.

[0099] In response to receiving a 602 Create Secure Channel Request message, the server sends one or more 604 Create Secure Channel Response messages. In one embodiment, the sent 602 response messages include ServerHello messages, EncryptedExtensions messages, CertificateRequest messages, Certificate messages, CertificateVerify messages, and Finished messages, such as those defined by the TLS handshake protocol. Alternatively, any suitable secure channel handshake message may be sent as needed.

[0100] The identity certificate and proof signature are received by the server endpoint via 606. The identity certificate can be any suitable digital certificate used to bind the client endpoint's identity to its public key. The identity certificate can be signed by a trusted certificate authority, thus providing a guarantee that the client endpoint and its corresponding public key can be trusted by the server endpoint. When needed, the identity certificate may include additional information, such as one or more reference hashes corresponding to a known good proof measure associated with the client endpoint.

[0101] The received proof signature is generated by the client and represents a digital signature on the data value known to both endpoints of the secure channel handshake. For example, a suitable data value could be a copy, such as the copy defined in the TLS protocol. The proof signature is obtained by using the above reference... Figure 1 The description of the proof private key, etc., is generated by signing the data value with the proof private key.

[0102] Generate a 608 copy, wherein the copy is based on one or more of the Create Secure Channel Request message and one or more Create Secure Channel Response messages. Any suitable data value known to both endpoints of the secure channel handshake can be advantageously used as the copy, such as the copy defined by the TLS protocol.

[0103] Extract the public key corresponding to the client endpoint private key from the received identity certificate (610).

[0104] As described above and referenced Figure 3 The 612 proof public key is calculated based on the extracted public key and a predefined reference hash. The predefined reference hash corresponds to a known good proof associated with the client endpoint and can be stored locally within the server endpoint or obtained from a trusted authority when needed to provide an appropriate reference hash.

[0105] Then, the proof signature (614) is verified based on the proof public key. Verification of 614 is accomplished by decrypting the received proof signature using the computed proof public key and comparing the decrypted data with the reference hash. If verification is successful, the secure channel handshake continues and a secure channel (618) is established. If verification fails, a secure channel is not established, and the process continues to 620.

[0106] In some embodiments, multiple reference hashes are maintained for a given client endpoint, and when verification of the proven signature fails, exemplary method 600 checks 622 to see if additional reference hashes are available. When no other references are available, the secure channel handshake fails 624 and the secure channel is not established.

[0107] When an additional reference hash becomes available, the next reference hash is selected (626), and the calculation of the corresponding proof public key (612) and the verification of the proof signature (614) are repeated for each available reference hash. When the reference hash leads to successful proof signature verification (628), the secure channel handshake continues (618).

[0108] With software upgrades and changes in hardware platforms, reference hashes may need to be updated to reflect changes in proof measurements. Maintaining and distributing reliable reference hashes is crucial for ensuring the integrity of numerous endpoints exposed on the internet. To facilitate the availability of reference hashes, a verification authority can be established to provide a reliable source for them. Endpoints can access this verification authority periodically or as needed to maintain a local storage of their predefined reference hashes. Optionally, reference hashes can be incorporated into an identity book generated by a trusted certificate authority. This facilitates the distribution of trusted reference hashes and their corresponding identity certificates by endpoints.

[0109] Therefore, although the essential novel features of the invention applicable to exemplary embodiments thereof have been shown, described, and pointed out herein, it should be understood that those skilled in the art can make various omissions, substitutions, and changes to the form and details of the illustrated apparatus and methods, as well as the operation of the setup, without departing from the spirit and scope of the invention. Furthermore, all combinations of those elements that are explicitly desired to perform substantially the same function in substantially the same manner to achieve the same result are within the scope of the invention. Moreover, it should be recognized that structures and / or elements shown and / or described in conjunction with any form or embodiment of the disclosed invention can be incorporated as general design choices into any other form or embodiment disclosed, described, or suggested. Therefore, its intent is limited only as indicated by the scope of the appended claims.

Claims

1. An apparatus (100), characterized in that, Includes a processor (102) communicatively coupled to a memory (104), wherein the memory (104) includes program instructions that, when executed by the processor (102), cause the device (100) to perform the following operations: Send a request message to create a secure channel (122) via computer network (170); Receive one or more Secure Channel Creation Response Messages (124, 126) from the computer network (170). A copy is generated based on one or more of the Create Secure Channel Request message (122) and the one or more Create Secure Channel Response messages (124, 126); Collect one or more proof measurements ( ), wherein the one or more proof measurements represent the current state of the device (100); Based on device private key ( ) and the one or more proof measurements ( ) compute proof of private key ( ); By using the proof private key ( The manuscript is signed to generate a first proof signature (145); The first identity certificate (144) and the first proof signature (145) are sent through the computer network (170).

2. The apparatus (100) according to claim 1, characterized in that, The processor (102) executes the program instructions to cause the device (100) to generate the proof private key in the following manner: ): At least in part, the measurement hash is generated based on the proof measurement. ); Based on the measurement hash ( ) and group generator points ( The order of the generation proof hash () ); By the proof hash ( ) and the device private key ( Add them together and then apply the group generator points ( The proof private key is calculated by taking the modulo of the order of the given number. ).

3. The apparatus (100) according to any one of the preceding claims, characterized in that, The proof measurement includes one or more of the following: the secure boot state of the device (100), the hash of the boot image of the device (100), and the hash of the application code of the device (100).

4. The apparatus (100) according to any one of the preceding claims, characterized in that, The device (100) includes a rich execution environment and a secure execution environment (108), wherein the secure execution environment includes one or more of a trusted execution environment and an HSM. The secure execution environment (108) is used to protect the device private key ( ), generate the proof private key ( ) and generate the proof signature (145).

5. The apparatus (100) according to any one of the preceding claims, characterized in that, The secure execution environment (108) includes one or more software-based HSMs or trusted execution environments.

6. The apparatus (100) according to any one of the preceding claims, characterized in that, The one or more secure channel creation response messages (124, 126) include a second identity certificate (138) and a second proof signature (141), and the device (100) is also used to base its response on a predefined reference hash ( Verify the second proof signature (145).

7. The apparatus (100) according to claim 6, characterized in that, The device (100) is used to verify the second proof signature (145) in the following manner: Extract the public key from the second identity certificate. ); A copy is generated based on one or more of the Create Secure Channel Request message (122) and the one or more Create Secure Channel Response messages (124, 126); Based on the extracted public key ( The predefined reference hash ( ) and the group generator point ( ) Compute proof public key ( ); Based on the aforementioned public key ( Verify the second proof signature.

8. A method (400) for enhancing a secure channel handshake with proof, characterized in that, The method (400) includes: Send a (402) Secure Channel Request message over a computer network; Receive one or more (404) Create Secure Channel Response messages from the computer network; Generate a (406) copy based on one or more of the Create Secure Channel Request message and the one or more Create Secure Channel Response messages; Collect (408) one or more proof measurements, wherein the one or more proof measurements represent the current state of the communication device; Based on the device private key and the one or more proof measurement calculations (410) of the proof private key; (412) First proof signature is generated by signing the copy using the proof private key; (414) The first identity certificate and the first proof signature are sent through the computer network.

9. The method (400) according to claim 8, characterized in that, The generation of the proof private key (410) includes: At least in part, the proof measurement generates (206) a measurement hash ( ); Generate (208) proof hash based on the order of the measured hash and group generator points; The proof private key is calculated (210) by adding the proof hash to the device private key and then taking the modulo of the order of the group generator point.

10. The method (400) according to claim 8 or 9, characterized in that, The one or more secure channel creation response messages include a second identity certificate and a second proof signature, and the method (400) is also used to verify the second proof signature based on a predefined reference hash.

11. The method (400) according to any one of claims 8 to 10, characterized in that, Verification of the second proof signature includes: Extract the (306) public key from the second identity certificate; Generate (308) copy based on one or more of the Create Secure Channel Request message and the one or more Create Secure Channel Response messages; The public key is proved by calculating (310) based on the public key and the predefined reference hash; The second proof signature is verified based on the proof public key (312).

12. A method (600) for enhancing secure channel handshakes with proof, characterized in that, The method (600) includes: Receive (602) Create Secure Channel Request message from the computer network; Send one or more Create Secure Channel response messages (604) through the computer network; Receive (606) identity certificate and proof signature from the computer network; Generate a (608) copy based on one or more of the Create Secure Channel Request message and the one or more Create Secure Channel Response messages; Extract the (610) public key from the identity certificate; The public key is proved by calculating (612) based on the extracted public key and the predefined reference hash; Based on the proof public key and the copy verification (614), the proof signature is verified; When the proof signature is valid, establish the secure channel (618); When the proof signature is invalid, reject the secure channel (622).

13. The method (600) according to claim 12, characterized in that, The predefined reference hash includes one or more predefined reference hashes, and the method further includes the following when the proof signature is invalid (620): Select (626) the next reference hash from the one or more predefined reference hashes; repeat (628) the calculation of the proof key (612) and verify the proof signature (614) step for each of the one or more predefined reference hashes until the proof signature (618) is verified or all of the one or more predefined reference hashes have expired.

14. The method (600) according to claim 12 or 13, characterized in that, The one or more predefined reference hashes are embedded in the digital certificate, and the digital certificate is received from the computer network.

15. A computer program product, characterized in that, The computer program product includes non-transitory computer program instructions that, when executed by the processor (102), cause the processor (102) to perform the method according to any one of claims 8 to 14.

Images