Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
  • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
  • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/12—Applying verification of the received information
  • H04L63/126—Applying verification of the received information the source of the received data
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
  • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

• the present disclosure in some embodiments thereof, relates to cyber security and, more specifically, but not exclusively, to systems and methods for attestation.
• Remote communication between two computing devices over a network is prone to malicious attack, for example, an application running on a server which is being accessed by a remote client terminal may be compromised by a malicious entity.
• Effort is being made to develop systems and methods that enable the remote client terminal to validate that the application running on the server has not been maliciously compromised.
• a device for attestation comprises: a computing circuitry having a processor being configured to: acquire a sealing key from the processor, decrypt a private key from an encrypted private key based on the sealing key, and sign a report from a challenger based on the private key.
• An advantage of the device according to the first aspect is that a sealing key is acquired from a processor of the device, where the sealing key is used for decrypting an encrypted private key to obtain the private key for encrypting a report from a challenger. Comparing with the prior art, this embodiment does not need to use the key stored in the processor for signing the report, and enables any entity to provide an alternative attestation service which can be used by organizations that trust the entity, and flexibility of the attestation service is thus improved.
• the processor further configured to execute an enclave security-related module for: acquiring the sealing key from the processor, generating the private key and a public key, wherein the public key is used to attest an authenticity of the report, encrypting the private key using the sealing key to obtain an encrypted private key, and storing the encrypted private key and the public key at a database accessible to one or more attestation services.
• An advantage of this implementation form is that a pair of keys comprising a private key and a public key are generated, where the private key is used to sign the report from the challenger, and the public key may be accessed by any entities and used to attest authenticity of the report. Comparing with the prior art, there is no need to use the key stored in the processor for signing the report, which enables any entity to provide an alternative attestation service which may be used by organizations that trust the entity, and flexibility of the attestation service is thus improved.
• the enclave security-related module may be installed on selected processors, enabling alternative attestation services on the selected processors.
• the enclave security-related module is unable to access the hardware coded keys stored in the processor. Instead, the enclave security-related module creates its own pair of keys.
• the public key is published and used to verify signed report by the attestation service (e.g., server).
• the private key is used to sign reports that have been locally attested.
• Encrypting the private key hides the private key from any process that is not the enclave security -related module. Optionally, only the enclave security-related module is able to access the encrypted private key.
• the private key and the public key are part of a randomly generated pair of signing keys.
• the encrypted private key is acquired from the database.
• the public key is also stored in the database.
• the device is a server.
• the device further comprises: a trusted Basic Input/Output System, BIOS and/or a trusted minimalistic operating system, OS.
• BIOS Basic Input/Output System
• OS a trusted minimalistic operating system
• Any enclave running in the already trusted BIOS and/or OS does not have to prove its authenticity.
• the enclave security-related module does not have to be attested in order to be trusted, since it is executed in the trusted BIOS and/or OS.
• the execution of the trusted BIOS and/or trusted minimalistic OS which are assumed to be non-compromised, avoid the need to authenticate the enclave.
• a method for attestation comprises: acquiring a sealing key from a processor of a device executing the method, decrypting a private key from an encrypted private key based on the sealing key, and signing a report from a challenger based on the private key.
• the attestation is not based on predefined data stored on hardware, for example, hardware encoded cryptographic keys, which are known only to a remote server that is able to validate authenticity of a report generated by a process using the hardware encoded cryptographic keys.
• Any third party entity is able to provide an alternative attestation service.
• the alternative attestation service does not depend on knowledge of the hardware encoded keys. Other organizations that trust the third party entity may use the attestation service provided by the third party entity.
• the alternative attestation service may be used as an alternative to, and/or combined with the single attestation service based on the hardcoded keys.
• the method further comprises: executing an enclave security-related module for: acquiring the sealing key from the processor of the device executing the method, generating the private key and a public key, wherein the public key is used to attest an authenticity of the report, encrypting the private key using the sealing key, and storing the encrypted private key and the public key at a database accessible to one or more attestation services.
• the method further comprising: randomly generating a pair of keys comprising the private key and the public key.
• the public key may be published, that is, the public key may be accessed by any entities and used to attest authenticity of the report.
• the method further comprising: retrieving the encrypted private key from the database.
• the method further comprising: installing a trusted Basic Input/Output System, BIOS.
• the method further comprising: installing a trusted minimalistic operating system, OS.
• an attestation service operator device comprises: a database, and a computing circuitry for executing an attestation process, wherein the computing circuitry is configured to store a plurality of public keys each generated using a processor of a different computing circuitry of a plurality of computing circuitries, wherein the computing circuitry is further configured to acquire a report and a public key from a challenger and attest an authenticity of the report based on the public key among the plurality of public keys.
• the attestation service is independent of, and does not access and/or use any special data encoded in the hardware of the respective different computing circuitry, for example, keys encoded in the hardware.
• the computing circuitry is configured to verify the authenticity of the report with the stored public key.
• a method of an attestation service comprises: storing a plurality of public keys, each generated using a processor of a different computing circuitry of a plurality of computing circuitries, acquiring a report and a public key from a challenger and attesting an authenticity the report based on the public key among the plurality of public keys.
• the method further comprising: verifying the authenticity of the report with the stored public key after acquiring the report.
• a computer program product comprising computer readable code instructions which, when run in a computer will cause the computer to perform the method according to any one of the second aspect and further implementations of the second aspect or any one of the fourth aspect and further implementations of the fourth aspect of the invention.
• a computer readable storage medium comprising computer program code instructions, being executable by a computer, for performing a method according to any one of the second aspect and further implementations of the second aspect or any one of the fourth aspect and further implementations of the fourth aspect of the invention when the computer program code instructions runs on a computer.
• an apparatus for encoding a video stream includes a processor and a memory.
• the memory is storing instructions that cause the processor to perform the method according to any one of the second aspect and further implementations of the second aspect or any one of the fourth aspect and further implementations of the fourth aspect of the invention.
• the invention also relates to a computer program, characterized in program code, which, when run by at least one processor causes said at least one processor to execute any method according to embodiments of the invention.
• the invention also relates to a computer program product comprising a computer readable medium and said mentioned computer program, wherein said computer program is included in the computer readable medium, and comprises of one or more from the group: ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), Flash memory, EEPROM (Electrically EPROM) and hard disk drive.
• FIG. 1 is a block diagram of components of a system for attestation, in accordance with some embodiments of the present invention
• FIG. 2 is a flowchart of a process for attestation, in accordance with some embodiments of the present invention
• FIG. 3 is a flowchart of a process for performing the pre-installation phase of the attestation process, in accordance with some embodiments of the present invention
• FIG. 4 is a dataflow diagram of a process for performing the pre-installation phase of the attestation process, in accordance with some embodiments of the present invention.
• FIG. 5 is dataflow diagrams of a process for booting, report generation, and report verification, as part of the attestation process, in accordance with some embodiments of the present invention
• FIG. 6 is a dataflow diagram of the boot process, in accordance with some embodiments of the present invention.
• FIG. 7 is a dataflow diagram of the report generation process, in accordance with some embodiments of the present invention.
• FIG. 8 is a dataflow diagram of the report verification process, in accordance with some embodiments of the present invention.
• the present invention in some embodiments thereof, relates to cyber security and, more specifically, but not exclusively, to systems and methods for attestation.
• An aspect of some embodiments of the present invention relates to systems, methods, an apparatus, and/or code instructions for attestation of a report generated by a target process, for example, an application executed by a processor (e.g., server) which is being accessed remotely by a client terminal.
• the attestation is not based on predefined data stored on hardware, for example, hardware encoded cryptographic keys, which are known only to a remote server that is able to validate authenticity of a report generated by a process using the hardware encoded cryptographic keys.
• the attestation process includes a first pre-installation phase for setting up the ability to perform attestation for processes, and a production phase for performing the attestation for processes.
• the installation phase may be performed by each respective processor of multiple processors executing a respective enclave security -related module.
• the enclave security- related module is a software module, and may be installed on selected processors, enabling alternative attestation services on the selected processors.
• a private key and a public key are generated.
• the public key is used to attest an authenticity of a report generated by a target process, as described herein.
• a sealing key is acquired from the processor.
• the private key is encrypted using the sealing key to obtain an encrypted private key.
• the encrypted private key and the public key are stored at a database accessible to one or more attestation services.
• the encrypted private key may be decrypted using the sealing key acquired from the processor to sign the report from the challenger during the production phase.
• the challenger may be a remote device that seeks to authenticate a target process running on the device (e.g., server), for example, a client terminal that is requesting to authenticate a process used for establishing a remote connection to the server, or a client terminal that is requesting to authenticate data and/or an application on the server to which the client terminal is connected, or data that the client terminal is obtaining.
• a target process running on the device (e.g., server)
• the device e.g., server
• a client terminal that is requesting to authenticate a process used for establishing a remote connection to the server
• a client terminal that is requesting to authenticate data and/or an application on the server to which the client terminal is connected, or data that the client terminal is obtaining.
• the challenger may use the attestation service (e.g., server) to perform the validation of the target process, optionally to authenticate a report that the challenger receives from the server hosting the target process indicating authenticity of the target process.
• the attestation service may provide attestation services to multiple challengers.
• the enclave security-related module is unable to access the hardware coded keys stored in the processor. Instead, the enclave security-related module creates its own pair of keys.
• the public key is published and used to verify signed report by the attestation service (e.g., server).
• the private key is used to sign reports that have been locally attested.
• Signing as used herein may be implemented using a standard cryptographic process. For example, signing a report is done by hashing the report with a cryptographic hash and then encrypting the result with the private key. Verifying the signature is done by decrypting the result with the public key and comparing the result with the hash of the report.
• the installation phase is performed when the processor executes a trusted Basic Input / Output System, BIOS and/or a trusted minimalistic operating system, OS when the private key and a public key are generated.
• BIOS and/or a trusted minimalistic operating system OS when the private key and a public key are generated.
• BIOS and/or a trusted minimalistic operating system OS when the private key and a public key are generated.
• BIOS and/or a trusted minimalistic operating system OS when the private key and a public key are generated.
• BIOS and/or a trusted minimalistic operating system OS when the private key and a public key are generated.
• the attestation is performed by acquiring the sealing key from the processor.
• the encrypted private key is obtained from the database.
• a private key is decrypted from the encrypted private key using the sealing key.
• a report from a challenger is signed using the private key.
• the attestation may be performed by the enclave security-related module, which may be used to attest the authenticity of other processes (e.g., enclaves).
• An aspect of some embodiments of the present invention relates to systems, methods, an apparatus, and/or code instructions for providing an attestation service operation, for attesting authenticity of a report.
• the attestation service includes a dataset that stores multiple public keys, each generated using a processor of a different computing circuitry.
• Each public key may be generated during the pre-installation phase of the respective processor.
• the attestation service acquires a report and a public key from a challenger, and attests an authenticity of the report based on the public key among the stored multiple public keys.
• the attestation service is independent of, and does not access and/or use any special data encoded in the hardware of the respective different computing circuitry, for example, keys encoded in the hardware.
• At least some implementations of the systems, apparatus, methods, and/or code instructions described herein address the technical problem of relying on a single attestation service for attesting the authenticity of a report provided by a certain processor.
• the single attestation service attests the authenticity of the report based on knowledge of data that is hard coded into the certain processor during manufacturing, for example, cryptographic keys.
• the single attestation service is based on each processor executing a special secure process that is able to locally access the cryptographic keys stored on the respective processor. The keys are used by the special secure process to attest the authenticity of the values generated by other secure processes on the processor.
• the single attestation service Since the knowledge of which processor has which cryptographic keys inserted into the processor at manufacture time is a secret by the single attestation service, and access of the cryptographic keys may only be performed by the special secure process, only the single attestation service is able to attest to authenticity of reports provided by the processors having keys hardcoded thereon. In other words, only the single attestation service is able to securely keep track of the special keys and only the single attestation service is capable of verifying any digital signature done by any special secure process running on any processor. Reliance on the single attestation service is problematic, for example, if the single attestation service becomes unavailable no attestation is available at all, and if the single attestation service becomes compromised then attestation service becomes compromised.
• At least some implementations of the systems, apparatus, methods, and/or code instructions described herein provide a technical solution to the technical problem by providing an alternative attestation service that does not depend on knowledge of, and/or access to the data (e.g., cryptographic keys) inserted into processors at manufacture time.
• data e.g., cryptographic keys
• processors include a set of instructions that enable the creation of enclaves.
• An enclave is a program which is protected by a processor in a way that no high privileged entity, including operating system and/or hypervisor is capable of accessing the protected program data or change the protected program logic.
• a crucial part of the security provided by enclaves is an attestation process.
• the attestation process allows an enclave to prove its identity to a third party.
• the identity of an enclave is, for example, a cryptographic hash of the executable and data protected.
• the main purpose of the attestation process is to prove that some value, sometimes termed herein a report, was generated by an enclave having a defined identity.
• the attested value, VA may be utilized by third parties to establish trusted communication with the enclave: the enclave creates a pair of asymmetric keys, attest the validity of the public key and share the attested public key with third party.
• the standard attestation process is executed in two phases. The first phase is executed internally inside the processor. Any enclave denoted E may invoke the processor with a special instruction to attest for some other enclave E2 that some value was generated by El.
• the second phase depends on a web based attestation service which as explained herein is a single attestation service that can only be provided by the manufacturer of the processors since attestation is based on knowledge of keys that are hard coded into the processors.
• the certain processors include functions that allow any enclave to attest the authenticity of its report to any other enclave running on the same processor, including a special quoting enclave designed to access the special keys encoded on the respective processor.
• a REPORT instruction enables a certain enclave to instruct the processor to attest for another enclave that a certain report was generated by the certain enclave.
• the quoting enclave is a special enclave on processors that is designed to perform the task of handling remote attestation, receiving REPORTS from other enclaves, verifies the REPORTS, and signs the REPORTS with the asymmetric key before returning the result to the application.
• E requests the processor to attest the report for the special quoting enclave running on the processor.
• the processor attests the report for the quoting enclave.
• the quoting enclave verifies the report authenticity.
• the quoting enclave signs the report with its signing key and returns the signed report to E.
• the single attestation service Since only the single attestation service stores the hard coded processor signing keys, only the single attestation service has the ability to attest that the signed report was legitimately signed by a quoting enclave in one of the processors. The single attestation service gets signed reports from third parties and attests the authenticity of the signature. The single attestation service cannot shared the hardcoded signing keys with third parties as it will break processor security.
• the main disadvantage of this above standard process is that service providers are required to trust the single attestation service. Service providers have to trust that the single attestation service will never attest fake signatures or refuse to attest legitimate ones.
• the availability of secure processor services relies on the continuous accessibility of the single attestation service.
• Any third party entity is able to provide an alternative attestation service.
• the alternative attestation service does not depend on knowledge of the hardware encoded keys. Other organizations that trust the third party entity may use the attestation service provided by the third party entity.
• the alternative attestation service may be used as an alternative to, and/or combined with the single attestation service based on the hardcoded keys.
• the embodiments of the present invention may be a system, a method, and/or a computer program product.
• the computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
• the computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device.
• the computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.
• Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.
• a network for example, the Internet, a local area network, a wide area network and/or a wireless network.
• the computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
• the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
• LAN local area network
• WAN wide area network
• Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
• electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
• FPGA field-programmable gate arrays
• PLA programmable logic arrays
• each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s).
• the functions noted in the block may occur out of the order noted in the figures.
• two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
• FIG. 1 is a block diagram of components of a system 100 for attestation, in accordance with some embodiments of the present invention.
• FIG. 2 is a flowchart of a process for attestation, in accordance with some embodiments of the present invention.
• System 100 includes a computing device for attestation 102, a challenger device 104 and a computing device 106 providing an attestation service.
• Each one of devices 102, 104, and 106 may be implemented as, for example one or more and/or combination of: a group of connected devices, a client terminal, a server, a virtual server, a computing cloud, a virtual machine, a smart television, a desktop computer, a thin client, a network node, a network server, and/or a mobile device (e.g., a Smartphone, a Tablet computer, a laptop computer, a wearable computer, glasses computer, and a watch computer, etc.).
• a mobile device e.g., a Smartphone, a Tablet computer, a laptop computer, a wearable computer, glasses computer, and a watch computer, etc.
• Devices 102 and 106 may act as servers, and challenger device 104 may act as a client.
• Devices 102, 104, and 106 may communicate over a network 108.
• Network 108 may be implemented as, for example, the internet, a local area network, a virtual network, a wireless network, a cellular network, a local bus, a point to point link (e.g., wired), and/or combinations of the aforementioned.
• Communication between devices 102, 104, and 106 over network 108 may be implemented, for example, via an application programming interface (API), software development kit (SDK), functions and/or libraries and/or add-ons added to existing applications, an application for download and local execution, function and/or interface calls to code executed by a certain device.
• API application programming interface
• SDK software development kit
• Each device 102, 104, 106 includes a respective computing circuitry having at least one respective processor 110, 112, 114 for executing code 116A, 118A, 120A stored on a respective memory 116, 118, 120.
• Code 116A, 118A, 120A stores instructions for implementation of the methods described herein. It is noted that at least some code instructions and/or processor functions may be implemented as computing circuitry and/or other hardware.
• Hardware processor(s) 112, 114, 116 may be implemented, for example, as a central processing unit(s) (CPU), a graphics processing unit(s) (GPU), field programmable gate array(s) (FPGA), digital signal processor(s) (DSP), and application specific integrated circuit(s) (ASIC).
• processors 112, 114, 116 may include a single processor, or multiple processors (homogenous or heterogeneous) arranged for parallel processing, as clusters and/or as one or more multi core processing devices.
• Processor 112 may be associated with the sealing key 112A.
• Memory 116, 118, 120 may be implemented as, for example, a random access memory (RAM), read-only memory (ROM), and/or a storage device, for example, non volatile memory, magnetic media, semiconductor memory devices, hard drive, removable storage, and optical media (e.g., DVD, CD-ROM).
• RAM random access memory
• ROM read-only memory
• storage device for example, non volatile memory, magnetic media, semiconductor memory devices, hard drive, removable storage, and optical media (e.g., DVD, CD-ROM).
• Memory 116 of device 102 may store a target process 116B for attestation thereof.
• Memory 116 may store an enclave security related module 116C that includes code stored in a memory that when executed by processor(s) 112 causes processor(s) 112 to acquire sealing key (112A), generate private key (122A) and public key (122B), encrypt private key (122A) using sealing key (112A) to obtain encrypted private key (122C), and store encrypted private key (122C) and public key (122B) at database (126A) accessible to one or more attestation services (106), as described herein.
• Each device 102, 104, 106 may include a respective data storage device 122, 124, 126 for storing data.
• Data storage device(s) 122, 124, 126 may be implemented as, for example, a memory, a local hard-drive, virtual storage, a removable storage unit, an optical disk, a storage device, and/or as a remote server and/or computing cloud (e.g., accessed using a network connection). It is noted that data stored in memory and/or data storage device may be interchanged (e.g., loaded from the data storage device to memory for execution) and/or stored in both, and/or stored in any one of the memory and/or the data storage device.
• Data storage device 122 may store one or more of: a generated private key 122 A, a generated public key 122B, an encrypted private key 122C created by encrypting private key 122A using sealing key 112A, and a trusted Basic Input / Output System, BIOS and/or a trusted minimalistic operating system, OS 122D.
• BIOS Basic Input / Output System
• OS 122D a trusted minimalistic operating system
• Data storage device 124 may store a report 124A.
• Data storage device 126 may store a database 126A of encrypted private keys 126B and public keys 126C generated by different devices 102.
• dataset 126A stores both encrypted private keys 126B and public keys 126C.
• one dataset stores encrypted private keys, and another dataset stores public keys 126C.
• Each device 102, 104, 106 may include a respective network interface (omitted from the figure for clarity) for connecting to one or more network 108, for example, one or more of, a network interface card, an antenna, a wireless interface to connect to a wireless network, a physical interface for connecting to a cable for network connectivity, a virtual interface implemented in software, network communication software providing higher layers of network connectivity, and/or other implementations.
• a network interface card for example, one or more of, a network interface card, an antenna, a wireless interface to connect to a wireless network, a physical interface for connecting to a cable for network connectivity, a virtual interface implemented in software, network communication software providing higher layers of network connectivity, and/or other implementations.
• Devices 102, 104, and/or 106 may include and/or are in communication with one or more respective user interfaces 128, 130, 132 that include a mechanism for user interaction, for example, to enter data (e.g., request a remote connection to target process 116B) and/or view data (e.g., view data obtained remotely from target process 116B).
• data e.g., request a remote connection to target process 116B
• view data e.g., view data obtained remotely from target process 116B
• Exemplary physical user interface 128, 130, 132 include, for example, one or more of, a touchscreen, a display, gesture activation devices, a keyboard, a mouse, and voice activated software using speakers and microphone.
• the method includes a pre-installation phase implemented as described with reference to 202-210, a production phase implemented as described with reference to 212-216, and an attestation phase implemented as described with reference to 218-220.
• the pre-installation phase is performed at each device (102), for example, for each server storing an application and/or other data (e.g., target process 116B) for remote access by a client terminal (e.g., challenger device 104).
• the pre installation phase may be performed by the enclave security related module (116C).
• the production phase is implemented by each device (102) in response to a message from the challenger (104), for example, an attempt to remotely access the target process on the device (116B) over a network (108).
• the attestation phase is implemented by an attestation service (e.g., device 106) in response to receiving a report (124A) from challenger (104) for attestation thereof.
• a trusted Basic Input / Output System BIOS and/or a trusted minimalistic operating system, OS (122D) is loaded to the device, for execution by the processor of the computing circuitry.
• the trusted BIOS and/or trusted OS sets up a non-compromised environment for generated trusted keys that are assumed to be uncompromised. Any enclave running in the already trusted BIOS and/or OS does not have to prove its authenticity. The enclave security related module does not have to be attested in order to be trusted, since it is executed in the trusted BIOS and/or OS.
• the enclave security related module (116C) is installed after, and/or as part of the loading of the trusted BIOS and/or trusted OS.
• the sealing key (112A) is acquired from the processor of the device.
• the sealing key may be acquired, for example, instructions by the enclave security related module as part of the installation process.
• the sealing key is a unique key associated with each enclave.
• Each enclave may request its sealing key from the processor.
• the sealing key may be used by the respective enclave to encrypt data between activations of the enclave.
• a private key (122A) and a public key (122B) are generated, optionally by the enclave security related module.
• the public key is used to attest an authenticity of the report, as described herein.
• the private key and the public key are part of a randomly generated pair of signing keys.
• the private key and the public key may be generated, for example, using a standard cryptographic process, for example, as defined by the Digital Signature Algorithm (DSA).
• DSA Digital Signature Algorithm
• the origin of the private key and public key is known (e.g., enclave security related module) and the private key and public are trusted, and assumed to be uncompromised.
• the private key is encrypted using the sealing key to obtain an encrypted private key (122C), optionally by the enclave security related module. Encrypting the private key hides the private key from any process that is not the enclave security related module. Optionally, only the enclave security related module is able to access the encrypted private key.
• the encrypted private key and the public key are stored at a database (126A) accessible to one or more attestation services (106).
• the public key is used by the attestation service to verify signatures of enclave security related modules.
• Each public key is generated using a processor of a different computing circuitry of multiple computing circuitries.
• Each of the multiple computing circuitries is executing a respective enclave security related module.
• the sealing key is acquired from the processor, for example, upon boot-up and/or in response to a trigger by the challenger device attempting to attest the integrity of the target process.
• the sealing key may be acquired by the enclave security related module.
• the private key is obtained by decrypting the encrypted private key based on the sealing key.
• the encrypted private key may be acquired (e.g., by the enclave security related module) from the database (126A).
• the private key was generated during the pre installation phase, in 206.
• a report from the challenger is signed based on the private key obtained in 214.
• the report may be verified by the enclave security related module before being signed by the private key.
• the signed report may be provided to the challenger.
• the local attestation mechanism may be used for attestation between two processes running on the same processor.
• the local attestation mechanism may be based on a standard process.
• the signed report is acquired from the challenger, optionally by the attestation service server.
• a public key may be obtained from the challenger, where the public key is obtained by the challenger from the enclave security related module and/or from the database storing public keys. Alternatively, the public key is obtained by the attestation service from the database storing public keys. The public key obtained from the challenger is used to find a matching public key stored in the dataset.
• an authenticity of the report is attested, optionally by the attestation service server.
• the authenticity of the report is attested by the challenger which accesses the public keys.
• the authenticity of the report is verified with the matched stored public key after acquiring the report from the challenger.
• the authenticity of the report is attested based on the public key among the multiple public keys.
• An indication of the authenticity the report is provided, optionally by the attestation service server to the challenger device.
• FIG. 3 is a flowchart 302 of a process for performing the pre-installation phase of the attestation process, in accordance with some embodiments of the present invention.
• At least some features of the method described with reference to FIG. 3 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to FIG. 2.
• At least some features of the method described with reference to FIG. 3 may be implemented by components of system 100 described with reference to FIG. 1.
• an alternative quoting (AQ) enclave also referred to herein as the enclave security related module, is launched in a pre-installation model.
• the AQ generates a random public and private key pair.
• the processor provides the AQ with a sealing key.
• the AQ publishes the public key and an encryption of the private key encrypted with the sealing key.
• the attestation service provider stores the public key in a highly protected list of recognized quoting enclave’s keys, for example, in the database.
• FIG. 4 is a dataflow diagram 402 of a process for performing the pre-installation phase of the attestation process, in accordance with some embodiments of the present invention.
• At least some features of the method described with reference to FIG. 4 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to FIG. 3 and/or FIG. 2.
• At least some features of the method described with reference to FIG. 4 may be implemented by components of system 100 described with reference to FIG. 1.
• Dataflow diagram 402 describes dataflow between an attestation operator 404 (e.g., attestation service server), enclave security related module 406 (also referred to herein as AQ), and processor (i.e., CPU) 408.
• attestation operator 404 e.g., attestation service server
• enclave security related module 406 also referred to herein as AQ
• processor i.e., CPU
• attestation operator 404 sends a request to AQ 406 to obtain signing keys.
• AQ 406 creates a public and private key pair.
• AQ sends a request to CPU 407 to get the AQ sealing key.
• CPU 408 returns the sealing key to AQ 406.
• AQ 406 creates a sealed key by encrypting the private key with the seal.
• the public key and sealed key are provided to attestation operator 404.
• the public key and sealed key are stored by attestation operator 404, for example, in the database.
• FIG. 5 includes dataflow diagrams of a process for booting 502, report generation 504, and report verification 506, as part of the attestation process, in accordance with some embodiments of the present invention.
• At least some features of the method described with reference to FIG. 5 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to FIG. 2.
• At least some features of the method described with reference to FIG. 5 may be implemented by components of system 100 described with reference to FIG. 1.
• the server (on which the enclave security related module has been installed in the pre-installation phase) boots with a regular OS.
• the enclave security related module is launched.
• the enclave security related module obtains the encrypted private key generated during the pre-installation process, for example, from the attestation service server.
• the enclave security related module obtains a sealing key from the process, and decrypts the encrypted private key with the sealing key to obtain the decrypted private key.
• an attesting enclave e.g., the target process
• creates a report for the AQ using a local attestation procedure for example, based on standard local attestation processes.
• the AQ verifies the validity of the report using the local attestation procedure.
• the AQ signs the report with the private key (obtained in 502C) and provides the signed report to the third party (also referred to herein as the challenger, and/or challenger device).
• the third party also referred to herein as the challenger, and/or challenger device.
• the third party sends the signed report to the attestation service provider.
• the attestation service provider verifies that the signature of the signed report corresponds to one of the recognized enclaves, optionally one of the enclave security related modules.
• the attestation service provider provides an indication of successful attestation of the report to the third party.
• FIG. 6 is a dataflow diagram 602 of the boot process, in accordance with some embodiments of the present invention. At least some features of the method described with reference to FIG. 6 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to 502 of FIG. 5 and/or FIG. 2. At least some features of the method described with reference to FIG. 6 may be implemented by components of system 100 described with reference to FIG. 1.
• the enclave security related module 406 retrieves the signing key from attestation operator 404.
• attestation operator 404 retrieves the public key and encrypted private key encrypted with the sealing key corresponding to the requesting enclave security related module 406.
• attestation operator 404 provides the public key and encrypted private key to enclave security related module 406.
• enclave security related module 406 requests the sealing key from processor 408.
• processor 408 provides the sealing key to enclave security related module 406.
• enclave security related module 406 decrypts the encrypted key with the sealing key to obtain the private key.
• FIG. 7 is a dataflow diagram 702 of the report generation process, in accordance with some embodiments of the present invention. At least some features of the method described with reference to FIG. 7 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to 504 of FIG. 5 and/or FIG. 2. At least some features of the method described with reference to FIG. 7 may be implemented by components of system 100 described with reference to FIG. 1.
• a third party 706 (also referred to herein as a challenger and/or challenging device) sends a challenge to attesting enclave 704 (e.g., target process). For example, the third party is attempting to verify integrity of the target process before attempting a remote connection to the target process.
• a report is created from the challenge, by attesting enclave 704.
• a request for attesting the report for the enclave security related module (i.e., AQ 406) is sent from attesting enclave 704 to processor 408.
• processor 408 provides the attested report, denoted ATT_R, to attesting enclave 704.
• At 716 attesting enclave sends ATT_R to AQ 406.
• AQ 406 verifies ATT R.
• AQ 406 signs ATT_R with the signing key, creating a signed report.
• the signed report and the associated public key are provided by AQ 406 to attesting enclave 704.
• FIG. 8 is a dataflow diagram 802 of the report verification process, in accordance with some embodiments of the present invention. At least some features of the method described with reference to FIG. 8 may correspond to, and/or be replaced with, and/or may include features of the method described with reference to 506 of FIG. 5 and/or FIG. 2. At least some features of the method described with reference to FIG. 8 may be implemented by components of the system 100 described with reference to FIG. 1.
• third party 706 provides the signed report and the public key to attestation operator 404.
• At 806 attempts to match the public key to one of the public keys in the database. If the signed report is verified using the public key, a response is generated by signing the signed report with a signing key of the attestation operator. At 808, the response is provided by attestation operator 404 to third party 706.
• 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.
• a compound or “at least one compound” may include a plurality of compounds, including mixtures thereof.
• 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 and/or to exclude the incorporation of features from other embodiments.
• range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the invention. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges 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 subranges 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. This applies regardless of the breadth of the range.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• General Physics & Mathematics (AREA)
• Signal Processing (AREA)
• Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computing Systems (AREA)
• Health & Medical Sciences (AREA)
• Bioethics (AREA)
• General Health & Medical Sciences (AREA)
• Mobile Radio Communication Systems (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=68104661

Family Applications (1)

Country Status (3)

Family Cites Families (2)

• 2019
  • 2019-09-30 EP EP19779894.5A patent/EP3973428A1/en active Pending
  • 2019-09-30 WO PCT/EP2019/076479 patent/WO2021063484A1/en unknown
  • 2019-09-30 CN CN201980100957.4A patent/CN114556342A/zh active Pending

Also Published As

Similar Documents

Legal Events