System and method for secure remote computing with enhanced isolation and access control

Abstract

A system and method for providing a remote user with verifiable proofs of a secure computing environment. The system comprises a secure execution environment, an attestation manager, and an attestation reporting interface. The attestation manager generates verifiable proofs regarding the integrity of the execution environment, the software running within the environment, and the effectiveness of access 5 control measures. These proofs are provided to the remote user via the attestation reporting interface, enabling them to independently verify the security of the environment. The method involves establishing a secure execution environment, monitoring system integrity, implementing access controls, and generating attestation reports. By combining trusted execution environments, integrity measurement architectures, and access control mechanisms, the invention provides a robust solution for securing remote computing, enabling 10 users to confidently entrust sensitive data and applications to remote infrastructure.

Description

[0001] SYSTEM AND METHOD FOR SECURE REMOTE COMPUTING WITH ENHANCED ISOLATION AND ACCESS CONTROL

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of priority from U.S. Provisional Patent Application No. 63 / 674,350, filed July 23, 2024 the contents of which are incorporated by reference in their entirety.

[0004] FIELD OF THE DISCLOSURE

[0005] The disclosure herein relates to systems and methods for remote use of secure computing environments. More specifically, the disclosure pertains to systems and methods for providing verifiable proofs to a remote user that a computing environment is secure.

[0006] BACKGROUND

[0007] The increasing reliance on cloud computing and remote infrastructure has created significant challenges in ensuring the security and trustworthiness of computing environments. Remote users often entrust their sensitive data and applications to third-party cloud providers, relinquishing direct control over the underlying infrastructure. This raises concerns about the potential for unauthorized access, data breaches, and malicious activities by the cloud provider or other unauthorized parties.

[0008] Traditional security measures, such as firewalls, intrusion detection systems, and access control lists, may not be sufficient to address these threats. These measures are often implemented at the software level and can be bypassed or compromised by sophisticated attacks targeting the hardware or firmware. Furthermore, the complexity of modern cloud environments, with their vast array of software components and interconnected systems, increases the attack surface and makes it difficult to maintain a strong security posture.

[0009] To address these challenges, Trusted Execution Environments (TEEs) have emerged as a promising solution. TEEs, such as Intel Software Guard Extensions (SGX) and ARM Trustzone, provide a secure, isolated environment for executing code and protecting sensitive data. TEEs offer confidential execution of user-level applications, ensuring that the code and data within the enclave are protected from unauthorized access, even from privileged software or hardware.

[0010] However, simply deploying applications within a TEE is not sufficient to guarantee security. Remote users need a way to verify that the TEE is properly configured, that the software running within the TEE is trusted, and that the system is protected from unauthorized access. Without such verification mechanisms, remote users must rely on the cloud provider's assertions about the security of the environment, which may not be trustworthy.

[0011] Therefore, there is a need for a system and method that provides remote users with verifiable proofs of a secure computing environment, enabling them to confidently entrust their sensitive data and applications to remote infrastructure. Such a system should provide assurances about the integrity of the execution environment, the trustworthiness of the software running within the environment, and the effectiveness of access control measures, thereby mitigating the risks associated with remote computing.

[0012] SUMMARY OF THE EMBODIMENTS

[0013] The present disclosure addresses the need for a secure computing environment that provides remote users with verifiable assurances regarding its integrity and security. To this end, a system and method are introduced that leverage a combination of trusted execution environments, integrity measurement architectures, and access control mechanisms to provide verifiable proofs to remote users, enabling them to confidently entrust their sensitive data and applications to remote infrastructure.

[0014] In accordance with one aspect of the disclosed subject matter, a system is provided for providing a remote user with verifiable proofs of a secure computing environment. The system comprises a secure execution environment configured to execute an operating platform. The secure execution environment may be either a virtual machine, through the use of a trusted execution environment (TEE), or a bare-metal machine, thereby providing flexibility in deployment options.

[0015] The system further comprises an attestation manager, which is the central component for generating and managing the verifiable proofs. The attestation manager comprises a platform verification module configured to generate a first attestation report attesting to the integrity of the secure execution environment. If the secure execution environment is a virtual machine, the first attestation report comprises a remote verifiable quote attesting to a virtualized environment. If the secure execution environment is a bare-metal machine, the first attestation report comprises a TEE quote, for example of a Trusted Platform Module (TPM) or of the Central Processing Unit (CPU) quote signed by a manufacturer's private key attesting to execution on a bare-metal machine.

[0016] The attestation manager also includes a runtime verification module comprising an integrity measurement architecture (IMA) module configured to log filesystem accesses during runtime, generate a second attestation report comprising a measurement of the system's runtime integrity, and verify the integrity of the boot process by measuring predefined measurement registers such as Platform Configuration Registers (PCRs) and the like and comparing them to known good values. The verification of the boot process and runtime environment ensures that the software running on the machine is as expected.

[0017] The attestation manager further includes an accessibility verification module configured to disable network access, serial access, and terminal access to the system, and to generate a third attestation report verifying the restricted access state of the system. Network blocking is implemented using at least one of the group consisting of iptables, SELinux, and AppArmor. Serial and terminal blocking is implemented by at least one of the group consisting of randomizing the login password, changing the default user's shell, and disabling TTY devices. The proof of exclusive access further comprises certificate binding, wherein a new private key and certificate are generated upon system reboot, and the hash of the certificate is included in a nonce signed by a Trusted Platform Module (TPM).

[0018] The attestation manager further comprises an attestation reporting interface configured to provide the remote user with access to the first, second, and third attestation reports, enabling the remote user to independently verify the execution environment, software integrity, and exclusive access of the computing environment.

[0019] In accordance with another aspect of the disclosed subject matter, a method is provided for providing a remote user with verifiable proofs of a secure computing environment. The method comprises the steps of: establishing a secure execution environment comprising an operating platform, verifying the secure execution environment, monitoring access to the secure execution environment during operation, verifying software integrity, disabling access to the secure execution environment, and verifying inaccessibility to the secure environment. The method further comprises providing the remote user with access to a first attestation report enabling the remote user to verify the secure execution environment, a second attestation report enabling the remote user to verify the software integrity, and a third attestation report enabling the remote user to verify exclusive access of the computing environment.

[0020] The step of establishing a secure execution environment comprises either configuring a trusted execution environment (TEE) to execute a virtual machine, or configuring a trusted execution environment (TEE) to operate on a bare-metal machine. The step of verifying the secure execution environment comprises generating a first attestation report cryptographically attesting that the operating platform is secure. The step of monitoring access to the secure execution environment during operation comprises logging filesystem accesses during runtime, and may further comprise using an integrity measurement architecture (IMA) module to log filesystem accesses during runtime. The step of verifying software integrity comprises generating a second attestation report comprising a measurement of the system's runtime integrity, and may further comprise using an integrity measurement architecture (IMA) module to generate a second attestation report comprising a measurement of the system's runtime integrity. The step of disabling access to the secure execution environment comprises disabling at least one of network access, serial access, and terminal access to the system. The step of verifying inaccessibility to the secure environment comprises generating a third attestation report verifying the restricted access state of the system.

[0021] The method may further comprise generating a proof of software integrity that the software running on the machine is as expected. Verifying boot process integrity using the TPM and IMA comprises measuring predefined measurement registers such as Platform Configuration Registers (PCRs) and the like and comparing them to known good values. Verifying runtime environment integrity using an IMA module comprises logging filesystem accesses, generating a log of accessed files and their respective hashes, and measuring the log entries in a dedicated PCR or the like. The method may also further comprises generating a proof of exclusive access. The method may also further comprise the step of proving network blocking is implemented using iptables, SELinux, or AppArmor, and proving serial and terminal blocking is implemented by randomizing the login password, changing the default user's shell, or disabling TTY devices. The method may also further comprise the step of certificate binding, by generating a new private key and certificate upon system reboot, and including the hash of the certificate in a nonce signed by the TPM.

[0022] Through these systems and methods, the present disclosure provides a robust and verifiable solution for securing remote computing environments, enabling remote users to confidently entrust their sensitive data and applications to remote infrastructure.

[0023] BRIEF DESCRIPTION OF THE FIGURES

[0024] For a better understanding of the embodiments and to show how it may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings.

[0025] With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of selected embodiments only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects. In this regard, no attempt is made to show structural details in more detail than is necessary for a fundamental understanding; the description taken with the drawings making apparent to those skilled in the art howthe various selected embodiments may be put into practice. In the accompanying drawings:

[0026] Fig. 1 is a block diagram illustrating a system for providing a remote user with verifiable proofs of a secure computing environment.

[0027] Fig. 2 is a flowchart illustrating a method for providing a remote user with verifiable proofs of a secure computing environment.

[0028] Fig. 3 is a flowchart illustrating a method for transitioning the system from an unlocked state to a locked state. Fig. 4 is a flowchart illustrating a method for transitioning the system from a locked state to an unlocked state.

[0029] DETAILED DESCRIPTION

[0030] Aspects of the present disclosure relate to systems and methods for secure remote computing. More specifically, the disclosure pertains to methods and platforms which use trusted execution environments, integrity measurement architectures, and access control mechanisms to provide verifiable proofs of a secure computing environment to remote users, enabling them to confidently entrust their sensitive data and applications to remote infrastructure.

[0031] The system and method described herein address the established need for remote users to have confidence in the security and integrity of remote computing environments. By combining trusted execution environments (TEEs) to create isolated and protected environments, integrity measurement architectures (IMAs) to continuously monitor the system's runtime state, and comprehensive access control mechanisms to prevent unauthorized access, the present invention provides a comprehensive solution for securing remote computing. The verifiable proofs provided to the remote user enable them to independently assess the security posture of the environment, thereby mitigating the risks associated with entrusting sensitive data and applications to remote infrastructure.

[0032] In various embodiments of the disclosure, one or more tasks as described herein may be performed by a data processor, such as a computing platform or distributed computing system for executing a plurality of instructions. Optionally, the data processor includes or accesses a volatile memory for storing instructions, data or the like. Additionally, or alternatively, the data processor may access a non-volatile storage, for example, a magnetic hard-disk, flash-drive, removable media or the like, for storing instructions and / or data.

[0033] It is particularly noted that the systems and methods of the disclosure herein may not be limited in its application to the details of construction and the arrangement of the components or methods set forth in the description or illustrated in the drawings and examples. The systems and methods of the disclosure may be capable of other embodiments, or of being practiced and carried out in various ways and technologies.

[0034] Alternative methods and materials similar or equivalent to those described herein may be used in the practice or testing of embodiments of the disclosure. Nevertheless, particular methods and materials are described herein for illustrative purposes only. The materials, methods, and examples are not intended to be necessarily limiting.

[0035] Reference is now made to the block diagram of Fig. 1 illustrating a system 100 for providing a remote user 40 with verifiable proofs of a secure computing environment. The system 100 generally comprises a secure environment 10, an operating platform 12, a network 30, and a remote user 40.

[0036] The remote user 40 represents an entity, such as an individual or an organization, that requires secure access to a computing environment. The remote user 40 connects to the system 100 via the network 30 and relies on verifiable proofs provided by the system 100 to ensure the security and integrity of the computing environment. The remote user 40 may be a customer in a cloud computing scenario, a researcher accessing sensitive data, or any other entity requiring a trusted and secure computing platform.

[0037] The network 30 facilitates communication between the remote user 40 and the secure environment 10. The network 30 may be the Internet, a local area network (LAN), a wide area network (WAN), or any other suitable communication network. The network 30 enables the remote user 40 to send requests to the secure environment 10 and receive attestation reports verifying the security and integrity of the computing environment. The secure environment 10 is the core of the system 100, providing a protected and isolated space for executing applications and processing sensitive data. The secure environment 10 comprises an operating platform 12, a platform verification module 11 , a runtime verification module 13, and an accessibility verification module 15.

[0038] The operating platform 12 provides the foundation for the secure environment 11 . It may be a virtual machine or a bare-metal machine and provides the necessary resources for executing applications and processing data. The operating platform 12 is configured to leverage hardware-based security features, such as Intel Trust Domain Extensions (TDX) or AMD Secure Encrypted Virtualization (SEV), to ensure the confidentiality and integrity of the computing environment.

[0039] The platform verification module 11 generates a first attestation report 21 attesting to the integrity of the trusted execution environment. The platform verification module 11 verifies that the operating platform 12 is running in a trusted state and has not been tampered with. The platform verification module 11 may use a TEE quote, for example of a Trusted Platform Module (TPM) or of the Central Processing Unit (CPU) which uses the Trusted Platform Module (TPM) or other hardware- based security mechanisms to provide cryptographic algorithms and secure storage of cryptographic keys and measurement results, ensuring the integrity of the attestation process and to generate the first attestation report.

[0040] The runtime verification module 13 monitors and logs filesystem accesses during runtime. The runtime verification module 13 may employ an Integrity Measurement Architecture (IMA) or other softwarebased security mechanisms to extend TPM reports, or their counterparts provided by Intel TDX, with runtime information by logging accessed files and updating PCRs, or their counterparts, allowing for continuous monitoring of the system's integrity. Accordingly, the runtime verification module 13 generates a second attestation report 23 comprising a measurement of the system's runtime integrity.

[0041] The accessibility verification module 15 disables network access, serial access, and terminal access to the system. The accessibility verification module 15 may use iptables, SELinux, AppArmor, or other access control mechanisms to block network access, randomizing login passwords, changing default user shells, and disabling TTY devices to restrict serial and terminal access. The accessibility verification module 15 generates a third attestation report 25 verifying the restricted access state of the system.

[0042] The attestation reporting interface 14 provides the remote user 40 with access to the first attestation report 21 , the second attestation report 23, and the third attestation report 25. The attestation reporting interface 14 enables the remote user 40 to verify the execution environment, software integrity, and exclusive access of the computing environment.

[0043] The remote user 40 connects to the secure environment 10 via the network 30. The platform verification module 11 , runtime verification module 13, and accessibility verification module 15 generate attestation reports 21, 23, and 25, respectively. The attestation reporting interface 14 provides the remote user 40 with access to the attestation reports. The remote user 40 verifies the attestation reports to ensure the security and integrity of the computing environment. A secure communication channel 42 may be established between the remote user 40 and the operating platform 12, allowing for encrypted data transfer and secure interaction once the attestation reports have been successfully verified. The remote user 40 may then securely access the computing environment via the network 30.

[0044] Where appropriate, to ensure the authenticity of the attestation reports, a new private key and certificate are generated upon system reboot, and the hash of the certificate is included in a nonce signed by the TPM or its counterpart, thereby binding the certificate to the proofs generated by the system. The system 100 can operate in two modes: a locked state, in which it is inaccessible and secured, and an unlocked state, in which it can be managed and updated by an authorized entity. Transitioning between these states ensures both security and manageability of the system.

[0045] Referring now to the flowchart of Fig. 2 illustrating a method for providing a remote user with verifiable proofs of a secure computing environment. The method begins at the "START" step and proceeds as follows:

[0046] First, a secure execution environment is established 212. This environment may be either a virtual machine or a bare-metal machine, and the choice between these two options affects subsequent steps in the method. If a virtual machine is selected, virtualization technologies such as Intel TDX or AMD SEV are utilized to create an isolated and secure environment. If a bare-metal machine is selected, a Trusted Platform Module (TPM) is employed to ensure the integrity and security of the underlying hardware and firmware.

[0047] Next, the secure execution environment is verified 214 to ensure that it meets the required security standards. This verification process involves checking the integrity of the operating system, firmware, and other critical components.

[0048] A decision is then made 216 as to whether the platform is secure. If the platform is not secure, the method returns to the "Establish Secure Execution Environment" step 212 to re-establish the environment and address any security vulnerabilities.

[0049] If the platform is secure, a first attestation report is sent to the remote user 218. This report provides verifiable proof that the execution environment is trusted and has not been compromised.

[0050] Following the verification of the execution environment, the method proceeds to monitor filesystem access during runtime 222. This monitoring is performed using an Integrity Measurement Architecture (IMA) or similar technology, which logs all filesystem accesses and calculates cryptographic hashes of the accessed files.

[0051] The software integrity is then verified 224 by comparing the logged filesystem accesses and their corresponding hashes against a known-good baseline.

[0052] A decision is made 226 as to whether the software is safe. If the software is not safe, indicating a potential security breach or tampering, the method returns to the "Monitor Filesystem Access During Runtime'1step 222 to continue monitoring and detecting any further unauthorized changes.

[0053] If the software is safe, a second attestation report is sent to the remote user 228. This report provides verifiable proof that the software running in the secure execution environment is trusted and has not been tampered with during runtime.

[0054] After verifying the software integrity, the method proceeds to disable access to the system 232. This involves implementing various access control measures to restrict network, serial, and terminal access to the system, preventing unauthorized access and data exfiltration. These measures may include using iptables, SELinux, AppArmor, or other access control mechanisms.

[0055] The inaccessibility of the system is then verified 234 to ensure that the access control measures are effective and that the system is indeed inaccessible to unauthorized parties.

[0056] A decision is made 235 as to whether the system is inaccessible. If the system is not inaccessible, indicating a failure in the access control measures, the method returns to the "Disable Access to the System" step 232 to re-implement the access control measures and ensure that the system is properly secured.

[0057] If the system is inaccessible, the system proceeds to generate new cryptographic keys and certificates 236, creating a new private key and public key certificate for secure communication. The certificate is then bound to the proofs 237, cryptographically linking the certificate to the verified state of the system, after which a third attestation report is sent to the remote user 238. This report provides verifiable proof that the system is protected from unauthorized access. Finally, the method reaches the "END" step, indicating the successful completion of the process and the provision of a secure and verifiable computing environment to the remote user."

[0058] A new cryptographic key pair may be thus generated, comprising a private key and a public key certificate. The hash of the public key certificate may be included in a nonce (a one-time arbitrary number used in to prevent the interception and reuse of a valid message) that is signed by the TPM or its counterpart, thereby cryptographically binding the certificate to the verified state of the system.

[0059] To facilitate both security and manageability, the system may be configured to operate in two distinct modes: a "locked" state and an "unlocked" state. In the "locked" state, the system is configured to provide maximum security and inaccessibility to unauthorized parties, including the platform owner. This state ensures that the remote user's data and applications are protected from tampering or unauthorized access. Conversely, in the "unlocked" state, the system is configured to allow authorized entities, such as the platform owner, to perform maintenance, updates, and reconfigurations.

[0060] Fig. 3 illustrates a flowchart (300) depicting the method for transitioning the system from an unlocked state to a locked state. The process begins at the "START" step (301) in the unlocked state, where the system is configurable and manageable by authorized entities. Upon receiving a "RECEIVE LOCK REQUEST" (302), the system initiates the locking procedure. To minimize the attack surface, the system proceeds to "STOP ALL SERVICES" (303), halting all non-essential services. Next, the system implements "IMPLEMENT ACCESS CONTROL MEASURES" (304) to restrict network, serial, and terminal access, preventing unauthorized access and data exfiltration. The system then generates "GENERATE NEW CRYPTOGRAPHIC KEYS AND CERTIFICATES" (305), creating a new private key and public key certificate for secure communication after the system is locked. To ensure the authenticity of the system's state, "BIND CERTIFICATE TO PROOFS" (306), the certificate is cryptographically bound to the verified state of the system. The system proceeds to "GENERATE ATTESTATION REPORTS" (307), creating reports that provide verifiable proof of the system's security posture. The system then performs the "REBOOT SYSTEM" step (308) to ensure all security measures take effect, and transitions to "ENTER LOCKED STATE" (309), providing a secure environment for the remote user. The process concludes at the "END" step (310) in the locked state.

[0061] During the transition from the "unlocked" state to the "locked" state, the system undergoes a series of security hardening procedures, including disabling network access, serial access, and terminal access, as well as generating new cryptographic keys and certificates. These procedures ensure that the system is secured before being made available to the remote user in the "locked" state. The ability to transition between these two states provides a balance between security and manageability, allowing for secure remote computing while still enabling necessary system maintenance and updates.

[0062] Upon transitioning the system to the locked state, a cryptographic key pair, comprising a private key and a corresponding public key certificate, is generated possibly using a cryptographically secure random number generator. The key pair generation process leverages the capabilities of the Trusted Platform Module (TPM), if present, to ensure the security and integrity of the generated keys. If a TPM is not present, alternative agents such as Intel TDX, AMD SEV or the like may be used to protect the keys generated inside the CPU. Specifically, the TPM's key generation functionality is utilized to create a non-exportable private key, meaning that the private key is stored securely within the TPM and cannot be extracted. The corresponding public key certificate is then generated, containing information about the public key, the identity of the system, and a digital signature from a trusted certificate authority or a self-signed signature. To further enhance security, the hash of the public key certificate is included in a nonce that is signed by the TPM, thereby cryptographically binding the certificate to the verified state of the system as measured by the TPM's measurement registers such as Platform Configuration Registers (PCRs) and the like. This binding ensures that the certificate is only valid if the system remains in the same verified state, providing a strong link between the certificate and the security posture of the system. The generated certificate is then made available to the remote user through the attestation reporting interface, enabling secure communication with the system after the remote user has successfully verified the attestation reports.

[0063] Fig. 4 illustrates a flowchart (400) depicting the method for transitioning the system from a locked state to an unlocked state. The process begins at the "START" step (401) in the locked state, where the system provides verifiable security to the remote user. Upon receiving a "RECEIVE UNLOCK REQUEST" (402), the system initiates the unlocking procedure. To prevent unauthorized access, the system first "VERIFY UNLOCK REQUEST" (403), ensuring the request is legitimate and comes from an authorized source. The system then "ERASE ALL CRYPTOGRAPHIC KEYS AND CERTIFICATES" (404), removing the existing keys and certificates used for secure communication. The system proceeds to "RESTORE ACCESS" (405), removing access control measures to allow for system configuration and management. Next, the system "START MANAGEMENT SERVICES" (406), enabling system updates and reconfigurations. The system then "REBOOT SYSTEM" (407) to ensure all changes take effect, and transitions to "ENTER UNLOCKED STATE" (408), providing a manageable state for system maintenance. The process concludes at the "END" step (409) in the unlocked state.

[0064] Technical and scientific terms used herein should have the same meaning as commonly understood by one of ordinary skill in the art to which the disclosure pertains. Nevertheless, it is expected that during the life of a patent maturing from this application many relevant systems and methods will be developed. Accordingly, the scope of the terms such as computing unit, network, display, memory, server and the like are intended to include all such new technologies a priori.

[0065] As used herein the term ‘‘about’’ refers to at least ± 10 %.

[0066] The terms "comprises", "comprising", "includes", "including", "having” and their conjugates mean "including but not limited to" and indicate that the components listed are included, but not generally to the exclusion of other components. Such terms encompass the terms "consisting of' and "consisting essentially of'.

[0067] The phrase "consisting essentially of' means that the composition or method may include additional ingredients and / or steps, but only if the additional ingredients and / or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

[0068] As used herein, the singular form "a", "an" and "the" may include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

[0069] The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or to exclude the incorporation of features from other embodiments.

[0070] The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the disclosure may include a plurality of “optional” features unless such features conflict.

[0071] Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging / ranges between” a first indicate number and a second indicate number and “ranging / ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween. It should be understood, therefore, that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the disclosure. Accordingly, the description of a range should be considered to have specifically disclosed all the possible sub-ranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed sub-ranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6 as well as non-integral intermediate values. This applies regardless of the breadth of the range.

[0072] It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination or as suitable in any other described embodiment of the disclosure. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments unless the embodiment is inoperative without those elements.

[0073] Although the disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

[0074] All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present disclosure. To the extent that section headings are used, they should not be construed as necessarily limiting.

[0075] The scope of the disclosed subject matter is defined by the appended claims and includes both combinations and sub combinations of the various features described hereinabove as well as variations and modifications thereof, which would occur to persons skilled in the art upon reading the foregoing description.

Claims

CLAIMS1 . A system for providing a remote user with verifiable proofs of a secure computing environment, comprising: a secure execution environment configured to execute an operating platform; and an attestation manager comprising at least a platform verification module, a runtime verification module, an accessibility verification module and an attestation reporting interface.

2. The system of claim 1, wherein the secure execution environment comprises a trusted execution environment (TEE) configured to execute a virtual machine.

3. The system of claim 1, wherein the secure execution environment comprises a bare-metal machine.

4. The system of claim 1, wherein the runtime verification module comprises an integrity measurement architecture (IMA) module.

5. The system of claim 1 , wherein at least one verifiable proof comprises a proof of execution environment.

6. The system of claim 5, wherein the proof of execution environment comprises a proof that the user's workload operates in a virtual machine.

7. The system of claim 6, wherein the proof that the user's workload operates in a virtual machine comprises a remote verifiable quote generated by the platform verification module attesting to a virtualized environment.

8. The system of claim 5, wherein the proof of execution environment comprises a proof that the user's workload operates on a bare-metal machine.

9. The system of claim 8, wherein the proof that the user's workload operates on a bare-metal machine comprises a Trusted Platform Module (TPM) quote signed by a manufacturer's private key attesting to execution on a bare-metal machine.

10. The system of claim 1 , wherein at least one verifiable proof comprises a proof of software integrity.11 . The system of claim 10, wherein the proof of software integrity comprises proof that the software running on the machine is as expected.

12. The system of claim 10, wherein the proof of software integrity comprises demonstrating that the software is running on the machine as expected by using a Trusted Platform Module (TPM) and an integrity measurement architecture (IMA) to verify the integrity of the boot process.

13. The system of claim 12, wherein the Trusted Platform Module (TPM) and the integrity measurement architecture (IMA) verify the integrity of the boot process by measuring predefined measurement registers and comparing them to known good values.

14. The system of claim 10, wherein the proof of software integrity comprises demonstrating that the software is running on the machine as expected by using a Trusted Platform Module (TPM) and an integrity measurement architecture (IMA) to verify the integrity of the runtime environment.

15. The system of claim 14, wherein the integrity measurement architecture (IMA) module logs filesystem accesses, generates a log of accessed files and their respective hashes, and measures the log entries in a dedicated measurement register, thereby allowing verification of the runtime environment.

16. The system of claim 1 , wherein at least one verifiable proof comprises a proof of exclusive access.

17. The system of claim 16, wherein the proof of exclusive access comprises proof of network blocking.

18. The system of claim 17, wherein the network blocking is implemented using at least one of the group consisting of iptables, SELinux, and AppArmor.

19. The system of claim 16, wherein the proof of exclusive access comprises proof of serial blocking.

20. The system of claim 16, wherein the proof of exclusive access comprises proof of terminal blocking.21 . The system of claim 19, wherein the serial and terminal blocking is implemented by at least one of the group consisting of randomizing the login password, changing the default user's shell, and disabling TTY devices.

22. The system of claim 20, wherein the serial and terminal blocking is implemented by at least one of the group consisting of randomizing the login password, changing the default user's shell, and disabling TTY devices.

23. The system of claim 16, wherein the proof of exclusive access comprises certificate binding.

24. The system of claim 23, wherein the certificate binding comprises generating a new private key and certificate upon system reboot, and including the hash of the certificate in a nonce signed by a Trusted Platform Module (TPM).

25. A system for providing a remote user with verifiable proofs of a secure computing environment, comprising: a secure execution environment configured to execute an operating platform, wherein the secure execution environment is selected from at least one of: a trusted execution environment (TEE) configured to execute a virtual machine, and a bare-metal machine; an attestation manager comprising: a platform verification module configured to generate a first attestation report attesting to the integrity of the secure execution environment, wherein the first attestation report comprises a remote verifiable quote attesting to a virtualized environment if the secure execution environment is a virtual machine, and a TEE quote signed by a manufacturer's private key attesting to execution on a bare-metal machine if the secure execution environment is a bare-metal machine; a runtime verification module comprising an integrity measurement architecture (IMA) module configured to: log filesystem accesses during runtime, generate a second attestation report comprising a measurement of the system's runtime integrity, and verify the integrity of the boot process by measuring a predefined measurement registerand comparing them to known good values; an accessibility verification module configured to: disable network access, serial access, and terminal access to the system, generate a third attestation report verifying the restricted access state of the system, andimplement network blocking using at least one of the group consisting of iptables, SELinux, and AppArmor, and implement serial and terminal blocking by at least one of the group consisting of randomizing the login password, changing the default user's shell, and disabling TTY devices; and an attestation reporting interface configured to provide the remote user with access to the first attestation report, the second attestation report, and the third attestation report, and wherein the proof of exclusive access comprises certificate binding by generating a new private key and certificate upon system reboot, and including the hash of the certificate in a nonce signed by the trusted execution environment.

26. A method for providing a remote user with verifiable proofs of a secure computing environment, comprising: establishing a secure execution environment comprising an operating platform; verifying the secure execution environment; monitoring access to the secure execution environment during operation; verifying software integrity; disabling access to the secure execution environment; and verifying inaccessibility to the secure environment.

27. The method of claim 26 further providing the remote user with access to at least: a first attestation report enabling the remote user to verify the secure execution environment, a second attestation report enabling the remote user to verify the software integrity, and a third attestation report enabling the remote user to verify exclusive access of the computing environment.

28. The method of claim 26 wherein the step of establishing a secure execution environment comprises configuring a trusted execution environment (TEE) to execute a virtual machine.

29. The method of claim 26 wherein the step of establishing a secure execution environment comprises configuring a trusted execution environment (TEE) to or operate on a bare-metal machine.

30. The method of claim 26 wherein the step of verifying the secure execution environment comprises generating a first attestation report cryptographically attesting that the operating platform is secure.31 . The method of claim 26 wherein the step of monitoring access to the secure execution environment during operation comprises logging filesystem accesses during runtime.

32. The method of claim 26 wherein the step of monitoring access to the secure execution environment during operation comprises using an integrity measurement architecture (IMA) module to log filesystem accesses during runtime.

33. The method of claim 26 wherein the step of verifying software integrity comprises generating a second attestation report comprising a measurement of the system's runtime integrity.

34. The method of claim 26 wherein the step of verifying software integrity comprises using an integrity measurement architecture (IMA) module to generate a second attestation report comprising a measurement of the system's runtime integrity.

35. The method of claim 26 wherein the step of disabling access to the secure execution environment comprises disabling a least one of network access, serial access, and terminal access to the system.

36. The method of claim 26 wherein the step of verifying inaccessibility to the secure environment comprises generating a third attestation report verifying the restricted access state of the system.

37. The method of claim 26, wherein generating at least one verifiable proof comprises generating a proof of execution environment.

38. The method of claim 37, wherein generating the proof of execution environment comprises providing a proof that the user's workload operates in a virtual machine.

39. The method of claim 38, wherein providing the proof that the user's workload operates in a virtual machine comprises generating a remote verifiable quote attesting to a virtualized environment.

40. The method of claim 37, wherein generating the proof of execution environment comprises providing a proof that the user's workload operates on a bare-metal machine.41 . The method of claim 40, wherein providing the proof that the user's workload operates on a bare-metal machine comprises providing a TEE quote signed by a manufacturer's private key attesting to execution on a bare-metal machine.

42. The method of claim 26 further generating a proof of software integrity that the software running on the machine is as expected.

43. The method of claim 42, wherein generating the proof of software integrity comprises demonstrating that the software is running on the operating platform as expected by using TEE and IMA to verify boot process integrity.

44. The method of claim 43, wherein verifying boot process integrity using the TEE and IMA comprises measuring predefined measurement registers and comparing them to known good values.

45. The method of claim 42, wherein generating the proof of software integrity comprises demonstrating that the software is running on the machine as expected by using TEE and IMA to verify runtime environment integrity.

46. The method of claim 45, wherein verifying runtime environment integrity using an IMA module comprises logging filesystem accesses, generating a log of accessed files and their respective hashes, and measuring the log entries in a dedicated measurement register.

47. The method of claim 26, further generating a proof of exclusive access.

48. The method of claim 47, wherein generating the proof of exclusive access comprises providing proof of network blocking.

49. The method of claim 48, wherein the network blocking is implemented using iptables, SELinux, or AppArmor.

50. The method of claim 47, wherein generating the proof of exclusive access comprises providing proof of serial blocking.

51. The method of claim 47, wherein generating the proof of exclusive access comprises providing proof of terminal blocking.

52. The method of claim 50 or claim 51 , wherein the serial and terminal blocking is implemented by randomizing the login password, changing the default user's shell, or disabling TTY devices.

53. The method of claim 47, wherein generating the proof of exclusive access comprises providing certificate binding.

54. The method of claim 53, wherein the certificate binding comprises generating a new private key and certificate upon system reboot, and including the hash of the certificate in a nonce signed by the TEE.

55. A method for providing a remote user with verifiable proofs of a secure computing environment, comprising: establishing a secure execution environment comprising an operating platform; wherein establishing a secure execution environment involves one of: configuring a trusted execution environment (TEE) to execute a virtual machine, or configuring a trusted execution environment (TEE) to operate on a bare-metal machine; verifying the secure execution environment by generating a first attestation report cryptographically attesting that the operating platform is secure; monitoring access to the secure execution environment during operation by logging filesystem accesses during runtime; verifying software integrity by: generating a second attestation report comprising a measurement of the system's runtime integrity, and demonstrating that the software is running on the operating platform as expected; disabling access to the secure execution environment; and verifying inaccessibility to the secure environment by generating a third attestation report verifying the restricted access state of the system; and further providing the remote user with access to at least: a first attestation report enabling the remote user to verify the secure execution environment, a second attestation report enabling the remote user to verify the software integrity, and a third attestation report enabling the remote user to verify exclusive access of the computing environment, wherein generating the proof of software integrity comprises demonstrating that the software is running on the operating platform as expected by using the TEE and IMA to verify boot process integrity by measuring predefined measurement regiters and comparing them to known good values, and verifying runtime environment integrity using an IMA module by logging filesystem accesses, generating a log of accessed files and their respective hashes, and measuring the log entries in a dedicated measurement register, and wherein generating the proof of exclusive access comprises providing proof of network blocking implemented using at least one of the group consisting of iptables, SELinux, and AppArmor, and providing proof of serial and terminal blocking implemented by at least one of the group consisting of randomizing the login password, changing the default user's shell, and disabling TTY devices, and wherein generating the proof of exclusive access comprises providing certificate binding by generating a new private key and certificate upon system reboot, and including the hash of the certificate in a nonce signed by the TEE.

Images