CN114556342A

CN114556342A - System and method for attestation

Info

Publication number: CN114556342A
Application number: CN201980100957.4A
Authority: CN
Inventors: 巴伦·阿亚尔; 王烽; 丹.图伊图
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2019-09-30
Filing date: 2019-09-30
Publication date: 2022-05-27
Also published as: WO2021063484A1; EP3973428A1

Abstract

Apparatus and methods for attestation are disclosed. An apparatus for attestation, comprising: a computational circuit having a processor, the computational circuit to: obtaining a sealing key from the processor; decrypting the encrypted private key into a private key based on the sealed key; the report from the authenticator is signed based on the private key. This approach does not require the use of the key stored in the processor to sign the report and enables any entity to provide an alternative attestation service available to organizations that trust the entity, thus increasing the flexibility of the attestation service.

Description

System and method for attestation

Technical Field

Some embodiments of the invention relate to network security and more particularly, but not exclusively, to a system and method for attestation.

Background

Remote communication between two computing devices over a network is vulnerable to malicious attacks, for example, an application running on a server that a remote client is accessing may be attacked by a malicious entity. Efforts are underway to develop systems and methods that enable a remote client to verify that an application running on a server is not being attacked by malicious attacks.

Disclosure of Invention

It is an object of the present invention to provide an apparatus, method, apparatus, system and/or code instructions for attestation and/or for providing attestation services.

The above and other objects are achieved by the features of the independent claims. Further implementations are apparent in the dependent claims, the detailed description and the drawings.

According to a first aspect, an apparatus for attestation, comprising: a computational circuit having a processor, the computational circuit to: obtaining a sealing key from the processor; decrypting the encrypted private key into a private key based on the sealed key; a report from an authenticator (challenge) is signed based on the private key.

The apparatus according to the first aspect is advantageous in that the sealing key is obtained from a processor of the apparatus, wherein the sealing key is used to decrypt an encrypted private key to obtain a private key used to encrypt a report from an authenticator. This embodiment does not require the use of the key stored in the processor to sign the report, and enables any entity to provide an alternative attestation service available to organizations that trust the entity, thus increasing the flexibility of the attestation service, compared to the prior art.

In another implementation manner of the first aspect, the processor is further configured to execute a secure area (enclave) security-related module, configured to: obtaining the sealing key from the processor; generating the private key and a public key, wherein the public key is used to prove authenticity of the report; encrypting the private key using the sealed key to obtain an encrypted private key; storing the encrypted private key and the public key in a database accessible to one or more attestation services.

This implementation has the advantage of generating a key pair comprising a private key for signing the report from the authenticator and a public key accessible by any entity for proving the authenticity of the report. In contrast to the prior art, the report need not be signed using the key stored in the processor, which enables any entity to provide an alternative attestation service available to organizations that trust the entity, thus increasing the flexibility of the attestation service.

A security zone security-related module may be installed on the selected processor to enable the alternate attestation service on the selected processor.

The secure zone security-related module does not have access to a hard-coded key stored in the processor. Instead, the security zone security-related module creates its own key pair. The public key is issued and used to verify the report signed by the attestation service (e.g., a server). The private key is used to sign a locally certified report.

Encrypting the private key hides the private key from any processes that do not belong to the secure zone security-related module. Optionally, only the secure area security-related module has access to the encrypted private key.

In another implementation of the first aspect, the private key and the public key are part of a randomly generated signature key pair.

In another implementation form of the first aspect, the encrypted private key is obtained from the database. Optionally, the public key is also stored in the database.

In another implementation form of the first aspect, the device is a server.

In another implementation manner of the first aspect, the apparatus further includes: a trusted Basic Input/Output System (BIOS) and/or a trusted minimal Operating System (OS).

Any secure area running in the trusted BIOS and/or operating system does not necessarily prove its authenticity. Since the secure zone security-related module is executed in the trusted BIOS and/or OS, the module may be trusted without certification. Execution of the trusted BIOS and/or trusted minimalist OS (assumed to be not attacked) avoids the need for authentication of the secure zone.

According to a second aspect, a method for attestation, comprising: obtaining a sealing key from a processor of a device executing the method; decrypting the encrypted private key into a private key based on the sealed key; the report from the authenticator is signed based on the private key.

The proof is not based on predefined data stored on the hardware, such as a hard-coded encryption key, which is known only to the remote server, which is able to verify the authenticity of the report generated by the process using the hard-coded encryption key.

Any third party entity can provide the alternate attestation service. The alternate attestation service does not rely on the hard-coded key information. Other organizations that trust third party entities may use the attestation services provided by the third party entities. The alternate attestation service may be used as an alternative to and/or in combination with a single attestation service based on the hard-coded key.

In another implementation manner of the second aspect, the method further includes: executing a secure zone security-related module to: obtaining 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 prove authenticity of the report; encrypting the private key using the sealed key; storing the encrypted private key and the public key in a database accessible to one or more attestation services.

In another implementation manner of the second aspect, the method further includes: a key pair comprising the private key and the public key is randomly generated.

In this implementation, the public key may be issued, i.e., the public key may be accessed by any entity and used to prove the authenticity of the report.

In another implementation manner of the second aspect, the method further includes: retrieving the encrypted private key from the database.

In another implementation manner of the second aspect, the method further includes: a trusted Basic Input/Output System (BIOS) is installed.

In another implementation form of the second aspect, the method further comprises: install a trusted minimal Operating System (OS).

According to a third aspect, an attestation service operator device (operator device) comprises: a database; a computing circuit for performing an attestation process; wherein the computing circuitry is to store a plurality of public keys, each public key generated using a processor of a different computing circuitry of the plurality of computing circuitry; the computing circuitry is further to obtain a report and a public key from an authenticator and to certify authenticity of the report based on the public key of 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, e.g., a key encoded in the hardware.

In another implementation form of the third aspect, the computing circuitry is configured to verify authenticity of the report by the stored public key.

According to a fourth aspect, a method of certifying a service, comprising: storing a plurality of public keys, each public key generated using a processor of a different one of the plurality of computing circuits; obtaining a report and a public key from an authenticator and certifying authenticity of the report based on the public key of the plurality of public keys.

In another implementation form of the fourth aspect, the method further comprises: verifying authenticity of the report by the stored public key after the report is acquired.

According to a fifth aspect, a computer program product comprising computer readable code instructions which, when run in a computer, will cause the computer to perform a method according to any one of the second and other implementations of the second aspect of the present invention or any one of the fourth and other implementations of the fourth aspect of the present invention.

According to a sixth aspect, a computer readable storage medium comprises computer program code instructions executable by a computer for performing a method according to any of the second and other implementations of the second aspect of the invention or any of the fourth and other implementations of the fourth aspect of the invention when the computer program code instructions are run on a computer.

According to a seventh aspect, an apparatus for encoding a video stream comprises a processor and a memory. The memory stores instructions that cause the processor to perform a method according to any one of the second and further implementations of the second aspect of the invention or any one of the fourth and further implementations of the fourth aspect of the invention.

The invention also relates to a computer program, characterized by program code which, when run by at least one processor, causes the at least one processor to perform any of the methods according to embodiments of the invention. Furthermore, the invention relates to a computer program product comprising a computer readable medium and the computer program, wherein the computer program is contained in the computer readable medium and comprises one or more of the following groups: Read-Only Memory (ROM), Programmable ROM (PROM), Erasable PROM (EPROM), flash Memory, Electrically EPROM (EEPROM), and hard disk drives.

Unless defined otherwise, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, some exemplary methods and/or materials are described below. In case of conflict, the present patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not necessarily limiting.

Drawings

Some embodiments of the invention are described herein, by way of example only, with reference to the accompanying drawings. With specific reference to the figures, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the embodiments of the present invention. Thus, it will be apparent to one skilled in the art from the description of the figures how embodiments of the invention may be practiced.

Wherein:

FIG. 1 is a block diagram of components of a system for attestation provided by some embodiments of the invention;

FIG. 2 is a flow diagram of an attestation process provided by some embodiments of the invention;

FIG. 3 is a flow diagram of a process for performing a pre-installation phase of an attestation process provided by some embodiments of the invention;

FIG. 4 is a data flow diagram of a process for performing a pre-install phase of an attestation process provided by some embodiments of the invention;

FIG. 5 is a data flow diagram of a process of startup, report generation, and report validation (as part of an attestation process) provided by some embodiments of the invention;

FIG. 6 is a data flow diagram of a boot process (boot process) provided by some embodiments of the invention;

FIG. 7 is a data flow diagram of a report generation process provided by some embodiments of the present invention;

fig. 8 is a data flow diagram of a report validation process provided by some embodiments of the present invention.

Detailed Description

An aspect of some embodiments of the invention relates to systems, methods, apparatus, and/or code instructions for certifying reports generated by a target process (e.g., an application executed by a processor (e.g., a server) remotely accessed by a client). The proof is not based on predefined data stored on the hardware, such as a hard-coded encryption key, which is known only to the remote server, which is able to verify the authenticity of the report generated by the process using the hard-coded encryption key. Optionally, the attestation process comprises: a first pre-installation stage for setting the function of the execution process certification; a production phase for performing process certification.

The installation phase may be performed by each respective processor of a plurality of processors executing respective security zone security-related modules. The security zone security-related module is a software module that may be installed on a selected processor to enable the alternate attestation service on the selected processor. A private key and a public key are generated. The public key is used to prove the authenticity of the report generated by the target process, as described herein. A sealing key is obtained from the processor. Encrypting the private key using the sealed key to obtain an encrypted private key. The encrypted private key and the public key are stored in a database accessible to one or more attestation services. During a production phase, the encrypted private key may be decrypted using the sealing key obtained from the processor to sign a report from the authenticator.

The authenticator may be a remote device attempting to authenticate a target process running on the device (e.g., a server), such as a client requesting authentication of a process for establishing a remote connection with the server, or a client requesting authentication of data and/or applications on a server to which the client is connected or data that the client is acquiring.

The authenticator may perform verification of the target process using the attestation service (e.g., a server), optionally to authenticate a report received by the authenticator from a server hosting the target process, the report indicating authenticity of the target process. The attestation service may provide attestation service to multiple authenticators.

It should be noted that the secure zone security-related module does not have access to the hard-coded key stored in the processor. Instead, the security zone security-related module creates its own key pair. The public key is issued and used to verify the report signed by the attestation service (e.g., a server). The private key is used to sign a locally certified report.

The signature used herein may be implemented using standard cryptographic procedures. For example, the report may be signed by hashing the report using a cryptographic hash and then encrypting the result using a private key. Verifying a signature by decrypting the result using the public key and comparing the result to the reported hash value.

Optionally, in generating the private key and the public key, the installation phase is performed when the processor executes a trusted Basic Input/Output System (BIOS) and/or a trusted minimal Operating System (OS). After the private key and the public key are generated, a higher level and/or fully operational BIOS and/or OS may be executed at the production stage. Execution of the trusted BIOS and/or the trusted minimalist OS (assumed to be not attacked) avoids the need for authentication of the secure zone(s).

At the production stage, performing attestation by obtaining the sealing key from the processor. Obtaining the encrypted private key from the database. Decrypting the encrypted private key into a private key using the sealing key. The report from the authenticator is signed using the private key. The attestation may be performed by the secure zone security correlation module, which may be used to attest to the authenticity of other processes (e.g., secure zones).

An aspect of some embodiments of the invention relates to systems, methods, apparatuses, and/or code instructions for providing an attestation service operation to attest to the authenticity of a report. The attestation service includes a data set storing a plurality of public keys, each public key generated using a processor of a different computing circuit. Each public key may be generated during a pre-installation phase of the respective processor. The attestation service obtains a report and a public key from an authenticator and attests to authenticity of the report based on the public key of the stored 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 circuits, e.g. a key 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 to prove the authenticity of a report provided by a certain processor. The single attestation service attests to the authenticity of a report based on data (e.g., encryption key) information that is hard-coded into some processor during production. Furthermore, the single attestation service performs a special security procedure on a per processor basis that enables local access to the encryption keys stored on the respective processors. The special security process uses the key to prove authenticity of values generated by other security processes on the processor. Since the information about which processor has which encryption key inserted into the processor at the time of production is a secret of the single attestation service and the access of the encryption key can only be performed by the special security procedure, only the single attestation service can prove the authenticity of the report provided by the processor having the hard-coded key thereon. In other words, only the single attestation service is able to securely track the special keys, and only the single attestation service is able to verify any digital signatures done by any special security processes running on any processor. Relying on the single attestation service can be problematic, for example, if the single attestation service becomes unavailable, no attestation is available at all, and if the single attestation service is attacked, the attestation service can be affected. At least some implementations of the systems, apparatus, methods, and/or code instructions described herein provide solutions to this technical problem by providing alternative attestation services that do not rely on information about and/or access to data (e.g., encryption keys) inserted into the processor at the time of production.

Further details will now be described to assist the reader in understanding the technical problem and solution.

Some processors include a set of instructions that enable the creation of a safe zone. A secure area is a program that is protected by a processor in such a way that no highly privileged entity (including the operating system and/or hypervisor) can access the protected program data or change the protected program logic. One of the key parts of the security provided by the security zone is the attestation process. The attestation process allows the secure area to prove its identity to a third party. For example, the identity of the security zone is a cryptographic hash of the executable file and the protected data. The primary purpose of the attestation process is to attest that certain values (sometimes referred to herein as reports) were generated by a secure area with a defined identity. A third party may establish trusted communication with the secure zone using the certified value VA: the secure zone creates a pair of asymmetric keys, certifies the validity of the public key and shares the certified public key with a third party. The standard proof process is performed in two phases. The first phase is performed inside the processor. Any security zone denoted E may call the processor through a special instruction to prove to other security zones E2 that a certain value was generated by E1. Traditionally, the second phase relies on a Web-based attestation service, which, as explained herein, is a single attestation service that can only be provided by the processor manufacturer, since the attestation is based on key information hard-coded into the processor.

Some processors include functionality that allows any secure area to prove its reported authenticity to any other secure area running on the same processor, including a special referencing secure area (quoting enclosure) designed to access special keys encoded on the respective processor. The reporting instructions enable a security zone to instruct the processor to prove to another security zone that a report was generated by the security zone. The reference security zone is a special security zone on the processor intended to perform the following tasks: processing remote attestation, receiving reports from other secure zones, verifying the reports, and signing the reports using asymmetric keys before returning the results to the application.

A standard attestation process based on hard-coded keys known only to the single attestation service is now provided to help the reader understand the technical advantages over the standard process described herein, which does not use hard-coded keys and is capable of creating multiple attestation services. E denotes a security zone in which the authenticity of certain reports is to be proven to a third party. The standard procedure is as follows:

e requests the processor to certify reporting of special reference safe zones running on the processor.

2. The processor attests to the report referencing the secure enclave.

E sharing the signed report with the reference safe zone.

4. The cited security zone verifies the authenticity of the report.

5. The cited secure zone signs the report using its signing key and returns the signed report to E.

Sharing the signed report with a third party.

Since only the single attestation service stores the hardcoded processor signing key, only the single attestation service can attest that the signed report was legitimately signed by a citation security zone in one of the processors. The single attestation service obtains the signed report from a third party and attests to the authenticity of the signature. The single attestation service cannot share the hard coded signing key with third parties because it would breach the security of the processor.

7. A third party shares the signed report with the single attestation service and obtains a response from the single attestation service as to whether the signature of the report is authentic.

Because only the single attestation service knows the cited secure zone signing key, only the single attestation service can prove the authenticity of the signed report. The main drawback of the above standard procedure is the requirement that the service provider trust the single proof service. The service provider must trust that the single attestation service never attests to false signatures or refuses to attest to legitimate signatures. The availability of the secure processor service depends on the continuous accessibility of the single attestation service.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or examples. The invention is capable of other embodiments or of being practiced or carried out in various ways.

Embodiments of the present invention may be systems, methods and/or computer program products. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied therein for causing a processor to perform various aspects of the present invention.

The computer readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing/processing device, or to an external computer or external storage device via a network, such as 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. In the latter scenario, 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), and the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, electronic circuitry including programmable logic circuits, Field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), etc., can execute computer-readable program instructions to perform aspects of the present invention by personalizing the electronic circuitry with state information for the computer-readable program instructions.

Aspects of the present invention are described herein in connection with flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products provided by embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, 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). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, 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. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Reference is now made to fig. 1, which is a block diagram of components of a system for attestation 100 provided by some embodiments of the invention. Reference is additionally made to fig. 2, which is a flow chart of an attestation process provided by some embodiments of the invention.

The system 100 includes a computing device 102 for attestation, an authenticator device 104, and a computing device 106 that provides attestation services.

Each of the devices 102, 104, and 106 may be implemented as one or more and/or combinations of the following, such as: a set of connected devices, clients, servers, virtual servers, computing clouds, virtual machines, smart televisions, desktop computers, thin clients, network nodes, network servers, and/or mobile devices (e.g., smartphones, tablets, laptops, wearable computers, glasses computers, watch computers, etc.).

The devices 102 and 106 may act as servers and the authenticator device 104 may act as a client.

It should be understood that a single implementation of 102, 104, and 106 is depicted for clarity, but multiple instances of 102, 104, and 106 may be implemented.

Devices 102, 104, and 106 may communicate over network 108.

The network 108 may be implemented, for example, as 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., a wired link), and/or combinations thereof.

For example, communication between devices 102, 104, and 106 over network 108 may be implemented through Application Programming Interfaces (APIs), Software Development Kits (SDKs), functions and/or libraries and/or attachments to existing applications, applications for downloading and executing locally, functions and/or interface calls to code executed by a device.

Each device 102, 104, 106 includes a respective computing circuit having at least one respective processor 110, 112, 114 for executing

code

116A, 118A, 120A stored on a

respective memory

116, 118, 120. The

code

116A, 118A, 120A stores instructions for implementing the methods described herein. It should be noted that at least some of the code instructions and/or processor functions may be implemented as computing circuitry and/or other hardware.

The

hardware processors

112, 114, 116 may be implemented as, for example, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), and an Application Specific Integrated Circuit (ASIC). The

processors

112, 114, 116 may include a single processor or multiple processors (homogeneous or heterogeneous) arranged for parallel processing as a cluster and/or as one or more multi-core processing devices.

The processor 112 may be associated with a sealing key 112A.

The

memories

116, 118, 120 may be implemented, for example, as Random Access Memories (RAMs), read-only memories (ROMs), and/or storage devices such as non-volatile memories, magnetic media, semiconductor storage devices, hard disk drives, removable storage devices, and optical media (e.g., DVDs and compact discs).

The memory 116 of the device 102 may store the target process 116B for attestation. The memory 116 may store a security zone security-related module 116C, the security zone security-related module 116C comprising code stored in the memory that, when executed by the processor 112, causes the processor 112 to: obtaining a sealing key (112A); generating a private key (122A) and a public key (122B); encrypting the private key (122A) using the sealing key (112A) to obtain an encrypted private key (122C); the encrypted private key (122C) and public key (122B) are stored in a 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. The data storage devices 122, 124, 126 may be implemented, for example, as memory, local hard drives, virtual storage devices, removable storage units, optical disks, storage devices, and/or remote servers and/or computing clouds (e.g., accessed using a network connection). It should be noted that data stored in memory and/or data storage devices may be interchanged (e.g., loaded from the data storage device into the memory for execution) and/or stored in both, and/or stored in either of the memory and/or the data storage devices.

The data storage device 122 may store one or more of the following: generated private key 122A, generated public key 122B, encrypted private key 122C created by encrypting private key 122A using sealing key 112A, and trusted Basic Input/Output System (BIOS) and/or trusted extremely simple Operating System (OS) 122D.

The data storage device 124 may store a report 124A.

The data storage device 126 may store a database 126A of encrypted private keys 126B and public keys 126C generated by different devices 102. In one implementation, data set 126A stores encrypted private key 126B and public key 126C. In another implementation, one data set stores the encrypted private key and the other data set stores the public key 126C.

Each device 102, 104, 106 may include a respective network interface (omitted from the figures for clarity) for connecting to one or more networks 108, such as one or more of: a network interface card, an antenna and a wireless interface for connecting to a wireless network; a physical interface for connecting to a cable for network connection; a virtual interface implemented by software; network communication software and/or other implementations that provide higher layer network connectivity.

The devices 102, 104, and/or 106 may include and/or communicate with one or more

respective user interfaces

128, 130, 132 that include user interaction mechanisms, e.g., for entering data (e.g., requesting a remote connection to the target process 116B) and/or viewing data (e.g., viewing data remotely obtained from the target process 116B).

Exemplary

physical user interfaces

128, 130, 132 include one or more of a touch screen, a display, a gesture activation device, a keyboard, a mouse, and voice activated software using a speaker and microphone, for example.

Referring now again to fig. 2, the method includes a pre-installation phase of the implementation described with reference to 202 to 210, a production phase of the implementation described with reference to 212 to 216, and a certification phase of the implementation described with reference to 218 to 220. For example, the pre-installation phase is performed at each device (102) for each server that stores applications and/or other data (e.g., target process 116B) for remote access by clients (e.g., authenticator device 104). The pre-installation phase may be performed by a safe zone security-related module (116C). The production phase is implemented by each device (102) in response to a message from the authenticator (104), for example, to attempt to remotely access a target process on the device (116B) over the network (108). The attestation phase is implemented by an attestation service (e.g., device 106) in response to receiving a report (124A) from an authenticator (104) to attest.

At 202, a trusted Basic Input/Output System (BIOS) and/or a trusted minimal Operating System (OS) (122D) is loaded to the device for execution by the processor of the computing circuit. The trusted BIOS and/or trusted OS sets a non-hacked context for the generated trusted key (assumed to be non-hacked). Any secure area running in the trusted BIOS and/or operating system does not necessarily prove its authenticity. Since the secure zone security-related module is executed in the trusted BIOS and/or OS, the module may be trusted without certification.

Optionally, the secure zone security-related module (116C) is installed after loading the trusted BIOS and/or the trusted OS and/or is installed as part of the loading.

At 204, a sealing key is obtained from the processor of the device (112A). For example, the sealing key may be obtained by the secure zone security-related module via instructions as part of the installation process.

The sealing key is a unique key associated with each secure zone. Each secure zone may request its sealing key from the processor. The respective secure zone may encrypt data between activations of the secure zone using the sealing key.

At 206, optionally, a private key (122A) and a public key (122B) are generated by the secure area security-related module. As described herein, the public key is used to prove the authenticity of the report.

Optionally, the private key and the public key are part of a randomly generated signature key pair. For example, the private key and the public key may be generated using a standard cryptographic process such as that defined by Digital Signature Algorithm (DSA).

Because the private key and the public key are generated in a trusted BIOS and/or OS environment, the sources of the private key and the public key are known (e.g., a secure zone security-related module) and the private key and the public key are trusted and assumed to be not attacked.

At 208, the private key is optionally encrypted by the secure area security-related module using the sealing key to obtain an encrypted private key (122C).

At 210, the encrypted private key and the public key are stored in a database (126A) accessible to one or more attestation services (106).

The attestation service uses the public key to verify a signature of the secure zone security-related module.

A plurality of public keys are stored in the database. Each public key is generated using a processor of a different one of the plurality of computing circuits. Each of the plurality of computing circuits is executing a respective security zone security-related module.

At 212, the sealing key is obtained from the processor, e.g., at start-up and/or in response to a trigger by the authenticator device to attempt to prove authenticity of a target process. The sealing key may be obtained by the secure zone security-related module.

At 214, the private key is obtained by decrypting the encrypted private key based on the sealing key. The encrypted private key may be obtained from a database (126A) (e.g., by the secure enclave security related module). The private key is generated at a pre-installation stage in 206.

At 216, the report from the authenticator is signed based on the private key obtained in 214. The report may be verified by the secure zone security-related module and then signed by the private key. The signed report may be provided to the authenticator.

Any security zone that wants to prove its identity creates a report through the security zone security correlation module and uses the local attestation mechanism. 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 standard procedures.

At 218, the signed report is optionally obtained by the attestation service server from the authenticator.

The public key may be obtained from the authenticator, wherein the public key is obtained by the authenticator from the secure zone security-related module and/or from the database storing the public key. Alternatively, the public key is obtained by the attestation service from the database storing the public key.

The public key obtained from the authenticator is used to find a matching public key stored in the dataset.

At 220, optionally, the authenticity of the report is certified by the certification service server. Alternatively, the authenticity of the report is certified by the authenticator accessing the public key.

After the report is obtained from the authenticator, the authenticity of the report is verified using the matching stored public key.

The authenticity of the report is certified based on the public key of the plurality of public keys.

Optionally, providing, by the attestation service server, an indication of authenticity of the report to the authenticator device.

Reference is now made to fig. 3, which is a flow diagram 302 of a process for performing a pre-install phase of an attestation process provided by some embodiments of the invention. At least some features of the method described with reference to fig. 3 may correspond to and/or be replaced by, 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 the system 100 described with reference to fig. 1.

At 304, an Alternate Quoting (AQ) security zone, also referred to herein as a security zone security-related module, is launched in the pre-installation model.

At 306, the AQ generates a random public and private key pair.

At 308, the processor provides a sealing key to the AQ.

At 310, the AQ issues an encryption of the public key and the private key encrypted using the sealing key.

At 312, the attestation service provider stores the public key in a highly protected list of identified keys that reference the secure zone, e.g., in a database.

Reference is now made to fig. 4, which is a data flow diagram 402 of a process for performing a pre-install phase of an attestation process as provided by some embodiments of the invention. At least some features of the method described with reference to fig. 4 may correspond to and/or be replaced by, 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 the system 100 described with reference to fig. 1.

A data flow diagram 402 depicts a data flow between an attestation operator 404 (e.g., an attestation service server), a security zone security related module 406 (also referred to herein as AQ), and a processor (i.e., CPU) 408.

At 410, attestation operator 404 sends a request to AQ 406 to obtain a signing key.

At 412, AQ 406 creates a public key and private key pair.

At 414, the AQ sends a request to CPU 407 to obtain the AQ sealing key.

At 416, CPU 408 returns the sealing key to AQ 406.

At 418, AQ 406 creates the sealed key by encrypting the private key using sealing.

At 420, the public key and the sealing key are provided to attestation operator 404.

At 422, the public key and the sealing key are stored by attestation operator 404, such as in a database.

Reference is now made to fig. 5, which includes a data flow diagram of the processes of initiation (502), report generation (504), and report validation (506) provided by some embodiments of the present invention as part of an attestation process. At least some features of the method described with reference to fig. 5 may correspond to and/or be replaced by, 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 the system 100 described with reference to fig. 1.

At 502A, the server (on which the secure zone security-related module has been installed during a pre-installation phase) is booted using a conventional OS. The security zone security-related module is started.

At 502B, for example, the secure enclave security correlation module obtains the encrypted private key generated during the pre-installation process from the attestation service server.

At 502C, the security zone security association module obtains a sealing key from the process and decrypts the encrypted private key using the sealing key to obtain a decrypted private key.

At 504A, a certifying security zone (e.g., a target process) creates a report for the AQ using a local certification process (e.g., based on a standard local certification process).

At 504B, the AQ verifies the validity of the report using the local attestation process.

At 504C, the AQ signs the report using the private key (obtained in 502C) and provides the signed report to a third party (also referred to herein as an authenticator and/or authenticator device).

At 506A, the third party sends the signed report to the attestation service provider.

At 506B, the attestation service provider verifies that the signature of the signed report corresponds to one of the identified security zones, optionally one of the security-zone security-related modules.

At 506C, the attestation service provider provides an indication of successful attestation of the report to a third party.

Reference is now made to fig. 6, which is a data flow diagram 602 of a boot process provided by some embodiments of the invention. At least some features of the method described with reference to fig. 6 may correspond to and/or be replaced by, and/or may include, features of the method described with reference to 502 in 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 the system 100 described with reference to fig. 1.

At 604, the secure zone security correlation module 406 retrieves the signing key from the attestation operator 404.

At 606, attestation operator 404 retrieves the public key encrypted using the sealing key and the encrypted private key corresponding to the requesting secure area security correlation module 406.

At 608, attestation operator 404 provides the public key and the encrypted private key to secure area security correlation module 406.

At 610, the security zone security correlation module 406 requests the sealing key from the processor 408.

At 612, the processor 408 provides the sealing key to the secure zone security correlation module 406.

At 614, the secure area security correlation module 406 decrypts the encrypted key using the sealed key to obtain the private key.

Reference is now made to fig. 7, which is a data flow diagram 702 of a report generation process provided by 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 2. At least some features of the method described with reference to fig. 7 may be implemented by components of the system 100 described with reference to fig. 1.

At 708, the third party 706 (also referred to herein as an authenticator and/or authentication device) sends an authentication to the attestation security zone 704 (e.g., target process). For example, a third party attempts to verify the authenticity of the target process before attempting to remotely connect to the target process.

At 710, a report is created by the attestation security zone 704 based on the authentication.

At 712, a request to certify a report of the security zone security-related module (i.e., AQ 406) is sent from certifying security zone 704 to processor 408.

At 714, processor 408 provides the certified report (denoted ATT _ R) to the certification security zone 704.

At 716, the certifying security zone sends an ATT _ R to AQ 406.

At 718, AQ 406 validates ATT _ R.

At 720, AQ 406 signs the ATT _ R using the signing key, creating a signed report.

At 722, AQ 406 provides the signed report and the associated public key to attestation security zone 704.

At 724, the attestation security region 704 provides the signed report and the public key to the third party 706.

Reference is now made to fig. 8, which is a data flow diagram 802 of a report validation process provided by 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 by, and/or may include, features of the method described with reference to 506 in 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.

At 804, third party 706 provides the signed report and the public key to attestation operator 404.

At 806, an attempt is made to match the public key to one of the public keys in the database. Generating a response by signing the signed report using a signing key of the certifying operator if the signed report is verified using the public key.

At 808, attestation operator 404 provides the response to third party 706.

Other systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.

The description of the various embodiments of the present invention has been presented for purposes of illustration and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application, or technical improvements over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is anticipated that during the life of a patent maturing from this application many relevant keys will be developed and the scope of the term "key" is intended to include all such new technologies a priori.

The term "about" as used herein means ± 10%.

The terms "including", "having" and variations thereof mean "including but not limited to". The term includes the terms "consisting of … …" and "consisting essentially of … …".

The phrase "consisting essentially of … …" means that the composition or method may include additional components and/or steps, provided that the additional components and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a complex" or "at least one complex" may include a plurality of complexes, 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 presence of other combinations of features of other embodiments.

The word "optionally" is used herein to mean "provided in some embodiments and not provided in other embodiments. Any particular embodiment of the invention may include a plurality of "optional" features unless such features conflict.

In the present application, various embodiments of the present invention may be presented in a range format. It is to be understood that the description of the range format is merely for convenience and brevity and should not be construed as a fixed limitation on the scope of the present invention. Thus, 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, a description of a range such as from 1 to 6 should be considered to have specifically disclosed sub-ranges 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 such as 1, 2, 3, 4, 5, and 6. This applies regardless of the wide range.

When a range of numbers is indicated herein, the expression includes any number (fractional or integer) recited within the indicated range. The phrases "a range between a first indicated number and a second indicated number" and "a range from a first indicated number to a second indicated number" are used interchangeably herein to mean to include the first indicated number and the second indicated number and all fractions and integers in between.

It is appreciated that certain features of the invention, 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 invention which are, for brevity, described in the context of a single embodiment, may also be provided separately, in any suitable subcombination, or in any other described embodiment as suitable for the invention. Certain features described in the context of various embodiments should not be considered essential features of those embodiments, unless the embodiments are inoperable without these elements.

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 invention. For section headings, they should not be construed as necessarily limiting. In addition, the entire contents of any one or more priority documents of the present application are incorporated by reference into the present application.

Claims

1. An apparatus (102) for attestation, comprising:

computing circuitry having a processor (112), the computing circuitry to:

obtaining a sealing key (112A) from the processor (112);

decrypting the encrypted private key (122C) to a private key (122A) based on the sealing key (112A);

the report (124A) from the authenticator (104) is signed based on the private key (122A).

2. The device (102) of claim 1, wherein the processor (112) is further configured to execute a safe zone security correlation module (116C) configured to:

obtaining the sealing key (112A) from the processor (112);

generating the private key (122A) and a public key (122B), wherein the public key (122B) is used to prove authenticity of the report;

encrypting the private key (122A) using the sealing key (112A) to obtain the encrypted private key (122C);

storing the encrypted private key (122C) and the public key (122B) in a database (126A) accessible to one or more attestation services (106).

3. The device (102) of claim 1 or 2, wherein the private key (122A) and the public key (122B) are part of a randomly generated signature key pair.

4. The device (102) of claim 2 or 3, wherein the encrypted private key (122C) and the public key are obtained from the database (126A).

5. The device (102) of any of the preceding claims, wherein the device (102) is a server.

6. The device (102) of any of the preceding claims, wherein the device (102) further comprises:

a trusted Basic Input/Output System (BIOS) and/or a trusted Operating System (OS) (122D).

7. A method for attestation, the method comprising:

obtaining a sealing key (212) from a processor of a device executing the method;

decrypting the encrypted private key into a private key based on the sealed key (214);

the report from the authenticator is signed (216) based on the private key.

8. The method of claim 7, further comprising:

executing a secure zone security-related module to:

obtaining the sealing key from the processor of the device executing the method (204);

generating the private key and a public key (206), wherein the public key is used to prove authenticity of the report;

encrypting (208) the private key using the sealing key;

storing the encrypted private key and the public key in one or more databases accessible to an attestation service (210).

9. The method according to any one of claims 7 and 8, further comprising:

a key pair (206) comprising the private key and the public key is randomly generated.

10. The method according to any one of claims 7 to 9, further comprising:

retrieving the encrypted private key from the database.

11. The method according to any one of claims 7 to 10, further comprising:

a trusted Basic Input/Output System (BIOS) is installed (202).

12. The method according to any one of claims 7 to 11, further comprising:

an Operating System (OS) is installed (202).

13. An attestation service operator device (106), comprising:

a database (126A);

a computing circuit (116) for performing an attestation process;

wherein the computing circuit (116) is configured to store a plurality of public keys (126C), each public key generated using a processor (112) of a different computing circuit (102) of the plurality of computing circuits (102);

the computing circuit (116) is further configured to obtain the signed report (124A) and the public key from the authenticator (104) and to certify the authenticity of the report (124A) based on a public key of the plurality of public keys (126C).

14. The attestation service operator device (106) of claim 13, wherein the computing circuit (116) is configured to verify the authenticity of the report (124A) with the stored public key.

15. An attestation service method, comprising:

storing a plurality of public keys, each public key generated (210) using a processor of a different one of the plurality of computing circuits;

obtaining a signed report and a public key from an authenticator (281) and certifying authenticity of the signed report based on the public key of the plurality of public keys (220).

16. The method of claim 15, further comprising:

verifying the authenticity of the signed report by the stored public key after the signed report is acquired (220).

17. A computer program product, characterized by program code means for performing the method according to any one of claims 7 to 12 or any one of claims 15 and 16 when said computer program is run on a computer.

18. A computer readable storage medium comprising computer program code instructions executable by a computer to perform the method of any one of claims 7 to 12 or any one of claims 15 and 16 when the computer program code instructions are run on a computer.