Apparatus and method for disk authentication

Abstract

The present invention relates to an apparatus and method for software authentication, wherein an enclave including an operating system (OS) library is initialized in a trusted execution environment; software authentication is performed to verify the identity of the enclave; and an application is executed within the enclave using the OS library, wherein performing the software authentication includes authenticating the contents of a disk image associated with the application.

Description

Technical Field

[0001] The present invention relates to a device and method for software authentication, and in particular to disk authentication and disk sealing in a distributed computing environment. Background Art

[0002] In distributed computing environments, cloud computing is becoming increasingly important as a way to achieve more flexible, scalable, and efficient systems. However, as users of cloud computing services lose direct control over the data and applications hosted by cloud providers, the trustworthiness of cloud services has become a major issue hindering the deployment of cloud applications.

[0003] To overcome users' reservations about using cloud services, cloud / service providers offer so-called trusted services, which assure their users that the data and applications they provide to the service will remain secure and protected, and that the service will only use these assets as the users expect.

[0004] An example of a trusted service is a trusted cloud service that guarantees its customers that their applications will run in the cloud unmodified and even protected by the cloud provider, which offers the service as Infrastructure as a Service (IaaS).

[0005] Trusted services can be developed using a trusted execution environment (TEE) such as Intel Software Guard Extensions (SGX). A TEE is a secure area of ​​the processor that establishes an isolated execution environment that provides security features such as isolated execution, the integrity of applications executed using the TEE, and the confidentiality of their assets.

[0006] Trusted execution environments (TEEs), such as Intel Software Guard Extensions (SGX), ensure that applications running in them have the following properties: code immutability, meaning the logic of the protected application cannot be changed; data confidentiality, ensuring that the application cannot be accessed without authorization; and authentication, meaning the protected application has the ability to prove its identity to a third party, that it is indeed the specific program running in the TEE. Thus, using a TEE, service providers can ensure that the user's assets will be protected and that the provided services will be able to authenticate their identity to the user.

[0007] The service identity is typically a large number, such as 256 bits, that can be the result of a cryptographic hash of the service executable (i.e., the application's binary code) or the entire application deployment, including the various components and topology of the service. In the case of Intel SGX, the application's identity is a hash of the application, i.e., the hash of the initial state of the executable and memory when an isolated execution environment or protected container (commonly called an enclave) is created and begins running.

[0008] In Intel SGX, the above protections are ensured only when applications are executed in user mode. However, system calls, such as those regarding disk I / O and exception and interrupt handling, call the operating system (OS) kernel, which is generally untrusted. Furthermore, calling OS functions during application execution requires special handling and comes at a relatively high cost in terms of execution performance. Therefore, porting applications to Intel SGX requires some effort, which limits the spread of Intel SGX despite its significant security advantages.

[0009] To simplify the process of porting applications to Intel SGX, the Linux Kernel Library (LKL) was ported to Intel SGX. The LKL exposes operating system services to applications as a library. In the LKL, system calls are translated into standard function calls. SGX-LKL, i.e., Intel SGX with a ported LKL, executes the entire LKL within the SGX enclave and therefore executes any executables handled by the LKL. The main advantage of SGX-LKL is that it allows unmodified applications to run in SGX.

[0010] Despite the advantages of SGX-LKL, there are also many security issues. For example, SGX-LKL certification only covers the LKL and not the executing application. Therefore, the challenger cannot distinguish the correct application from the malicious application being executed during the certification process. In addition, the disk content is generally not authenticated through SGX-LKL certification. For applications running in interpreted languages ​​​​such as Python and Java, the behavior of the application depends not only on the executable file (i.e., the interpreter), but also mainly on the data. In addition, the application behavior is also affected by the configuration file. Finally, when using SGX-LKL, the disk content is not protected. Therefore, the data on the disk may be exposed and / or changed.

[0011] A straightforward solution to the aforementioned problem is to provide the SGX-LKL with an encrypted disk. Only the application owner knows the encryption key. At the start of execution, the SGX-LKL authenticates its identity to the owner and establishes a secure channel with them. The owner then provides an encryption key, such as a public key, that enables decryption of the disk, and program execution begins.

[0012] This solution has two major drawbacks:

[0013] First, it is vulnerable to the following attack: an attacker starts SGX-LKL execution with a disk encrypted with their own key and provides the key to the SGX-LKL enclave. The SGX-LKL enclave begins executing malware on disk, which modifies the SGX-LKL enclave's memory and changes its behavior. The SGX-LKL enclave is now corrupted, fooling the legitimate application owner into thinking it is a newly created SGX-LKL enclave instance.

[0014] Second, the solution assumes that there is an entity that can provide the disk encryption key, such as the owner of the application. Unfortunately, some applications, especially decentralized applications, do not have an owner but still need to prove their identity.

[0015] Therefore, a mechanism is needed to protect against the aforementioned attacks. In particular, the mechanism should provide authentication for overwriting not only the executable file but also the disk contents. Finally, the disk contents should be sealed to prevent tampering, especially in the case of distributed execution. Summary of the Invention

[0016] The present invention provides an apparatus and method for disk authentication and disk sealing in a distributed computing environment. In addition to an application's executable file (including the LKL), the present invention's extended authentication also includes the contents of the disk associated with the application. In other words, during authentication, in addition to the authenticity of the application's executable file, the present invention's SGX-LKL enclave will also be able to prove the authenticity of the contents of the disk being used by the application. The disk sealing provided by the present invention ensures that only disk images authenticated by extended authentication will be used and their contents will remain protected.

[0017] According to one aspect of the present invention, an apparatus for software authentication is provided, wherein the apparatus includes processing circuitry configured to: initialize an enclave within a trusted execution environment (TEE), wherein the enclave includes an operating system (OS) library; perform software authentication to verify the identity of the enclave; and execute an application within the enclave using the OS library; wherein performing software authentication includes authenticating the contents of a disk image associated with the application. In particular, the processing circuitry may include a disk authentication unit configured to authenticate the contents of the disk image associated with the application.

[0018] The content of the disk image may include at least one of the following: an executable file of the application, an interpreter of the application, execution data of the application, and a configuration file of the application.

[0019] According to another aspect, the processing circuitry, in particular the disk authentication unit, can further be configured to add a public key or a cryptographic hash of the public key to a memory of the enclave prior to initializing the enclave. The processing circuitry, in particular the disk authentication unit, can further be configured to receive another public key as input to the enclave, wherein verifying the identity of the enclave comprises verifying the received another public key or the cryptographic hash of the received another public key calculated by the processing circuitry, in particular the disk authentication unit, against the corresponding public key or the cryptographic hash of the public key added to the memory of the enclave. The processing circuitry, in particular the disk authentication unit, can further be configured to receive a cryptographic signature of the contents of the disk image as input to the enclave, wherein verifying the identity of the enclave comprises verifying the contents of the disk image using the public key and the cryptographic signature.

[0020] According to another aspect, the processing circuitry, and in particular the disk authentication unit, can be further configured to apply a cryptographic hash function to the contents of the disk image and append the resulting cryptographic hash to a memory of the enclave prior to initializing the enclave. Verifying the identity of the enclave includes verifying the contents of the disk image using the cryptographic hash.

[0021] According to yet another aspect, the processing circuitry may be further configured to halt execution of the application if verification of the enclave's identity fails. To this end, the processing circuitry may include a disk sealing unit. The processing circuitry, in particular the disk sealing unit, may be further configured to generate a random encryption key before executing the application; read the disk image; and create a copy of the disk image by encrypting the disk image using the random encryption key. The processing circuitry, in particular the disk sealing unit, may be further configured to, upon successful verification of the enclave's identity, encrypt the random encryption key using a key of the enclave, such as the enclave's sealing key, and add the encrypted random encryption key to the encrypted copy. The processing circuitry, in particular the disk sealing unit, may also be configured to redirect all disk access calls by the OS library to the encrypted copy during execution of the application.

[0022] According to one aspect of the present invention, a method for software authentication is provided, wherein the method comprises: initializing an enclave in a trusted execution environment (TEE), wherein the enclave includes an operating system (OS) library; performing software authentication to verify the identity of the enclave; and executing an application within the enclave using the OS library; wherein performing software authentication comprises authenticating the contents of a disk image associated with the application.

[0023] The content of the disk image may include at least one of the following: an executable file of the application, an interpreter of the application, execution data of the application, and a configuration file of the application.

[0024] According to a further aspect, the method may further comprise: adding a public key or a cryptographic hash of the public key to a memory of the enclave prior to initializing the enclave. The method may further comprise: receiving another public key as input to the enclave; and verifying the received another public key or the cryptographic hash of the received another public key against the corresponding public key or the cryptographic hash of the public key added to the memory of the enclave to verify the identity of the enclave.

[0025] The method may further include: receiving an encrypted signature of the contents of the disk image as input to the enclave; and verifying the contents of the disk image using the public key and the encrypted signature to verify the identity of the enclave.

[0026] According to yet another aspect, the method may further include: applying a cryptographic hash function to the contents of the disk image; and adding the resulting cryptographic hash to the memory of the enclave prior to initializing the enclave. The method may further include: verifying the contents of the disk image using the cryptographic hash to verify the identity of the enclave.

[0027] The method may further include ceasing execution of the application upon failure of the verification of the identification of the enclave.

[0028] According to another aspect, the method may further include: generating a random encryption key; reading the disk image; and, before executing the application, creating a copy of the disk image by encrypting the disk image using the random encryption key. Upon successful verification of the identity of the enclave, the random encryption key may be encrypted using a key of the enclave, such as a seal key of the enclave; and the encrypted random encryption key may be added to the encrypted copy. During execution of the application, all disk access calls by the OS library may be redirected to the encrypted copy.

[0029] In addition, a computer-readable medium storing instructions is provided, wherein when the computer-readable medium is executed on a processor, the processor is caused to perform any one of the above methods.

[0030] As described above, the device may include a dedicated disk authentication unit and / or a dedicated disk sealing unit for performing any one of the above methods. The disk authentication unit and / or the disk sealing unit may be implemented as one or more software modules or separate units of the processing circuit. The disk authentication unit and / or the disk sealing unit may be implemented as a combination of software and hardware. The processing may be performed by a chip, such as a general-purpose processor, a CPU, a GPU or a field programmable gate array (FPGA). However, the present invention is not limited to implementing the disk authentication unit and / or the disk sealing unit on programmable hardware. The unit may also be implemented on an application-specific integrated circuit (ASIC) or by a combination of the above hardware components. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Example embodiments will be described in detail below with reference to the following drawings:

[0032] Figure 1 Schematically illustrates a common client-server configuration for remote services such as remote computing;

[0033] Figure 2 Schematically illustrates a configuration for trusted computing using a secure container as known in the art;

[0034] Figure 3 The concept of runtime execution of applications in secure containers as known in the art is shown;

[0035] Figure 4 The concept of SGX-LKL enclaves as known in the art is shown;

[0036] Figure 5 The following describes an owner-based disk authentication process and a content-based disk authentication process according to an embodiment of the present invention;

[0037] Figure 6 The disk sealing process provided by the present invention is shown. DETAILED DESCRIPTION

[0038] The present invention relates to the general technical field of authentication for remote services such as cloud computing, Software as a Service (SaaS), Infrastructure as a Service (IaaS), and remote computing. The present invention extends existing mechanisms for authenticating the identity of remote applications by adding authentication and disk sealing of disk contents associated with the remote application to maintain the confidentiality and integrity of the disk contents.

[0039] Figure 1A general client-server architecture for remote services is schematically illustrated. This configuration includes one or more clients 100 communicating with one or more servers 200. As described below, the client can be implemented in a user device or a client device. The server can be implemented in a server device provided by a service provider and / or cloud provider. However, the present invention is not limited to these specific implementations and can be applied to any configuration in which a local client (device) requests a service provided by a server to the client from a remote server (device). It should be understood that the service can be provided by multiple servers or server devices, but can itself rely on a distributed system architecture. The server can include, for example, a web server, application server, and database server as a front-end. For simplicity, the remote entity providing the service, whether a single server, server device, or a distributed or microservices-based system, will be referred to as the service provider hereinafter. Furthermore, the client is not limited to a single client or client device and can itself comprise a distributed system. The client can also act as a server itself in a distributed environment, for example, as an intermediary server. The term "client" as used herein includes any of the above architectures and simply indicates that the entity 100 (e.g., a client device) receives a service from a remote entity 200 (e.g., a server device). With respect to other aspects besides provision and reception of remote services, the client 100 and the server 200 may even switch roles.

[0040] The client 100 and the service provider 200 may be operably connected to one or more corresponding client data storages and server data storages (not shown), which may be used to store information local to the corresponding client 100 and server 200, such as application code, application data, input data, output data, authentication data, etc.

[0041] The client 100 and the service provider 200 can communicate information to each other using the communication framework shown by the arrows. The information may include authentication information, such as keys and / or signatures for establishing a secure communication channel, one or more applications (e.g., code or binary files), input data and / or configuration data for executing a remote application, output data of the remote application, etc. As described below, the information may also include keys and / or signatures for software authentication. In addition, the application may be provided as interpreted code executed by an interpreter. In addition, the application may be provided as interpreted code to be executed by an interpreter.

[0042] In an IaaS architecture, a remote application may be provided by the client 100 and communicated to the service provider 200 via a communication channel before being executed by the service provider. In this case, remote servicing may include installing, for example, compiling or interpreting, the application code received from the client, executing the received application as a remote application on the service provider side, and communicating the results of the execution back to the client 100. In a SaaS architecture, the remote application is provided by the service provider itself, and remote servicing includes potentially executing the remote application on input data and / or configuration data received from the client 100, and transmitting the results to the client.

[0043] The communication framework used for communication between the client 100 and the service provider 200 can implement any well-known communication technology and protocol. The communication framework can be implemented as a packet-switched network (e.g., a public network such as the Internet, a private network such as an enterprise intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with appropriate gateways and converters). The client-server architecture can include various common communication elements, such as transmitters, receivers, transceivers, wireless devices, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. However, the embodiments are not limited to these implementations.

[0044] The communication framework can implement various network interfaces that are arranged to receive, communicate, and connect to the communication network. The network interface can be regarded as a specialized form of input / output interface. The network interface can adopt a connection protocol, including but not limited to direct connection, Ethernet (e.g., fat, thin, twisted pair 10 / 100 / 1000Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.11ax network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, etc. In addition, multiple network interfaces can be used to cooperate with various communication network types. For example, multiple network interfaces can be used to allow communication through broadcast, multicast, and unicast networks. If the processing requirements specify higher speed and capacity, a distributed network controller architecture can be similarly adopted to achieve federation, load balancing, and otherwise increase the communication bandwidth required by the client 100 and server 200. The communication network can be any wired and / or wireless network and their combinations, including but not limited to direct interconnection, secure customized connection, private network (e.g., corporate intranet), public network (e.g., Internet), Personal Area Network (PAN), Local Area Network (LAN), Metropolitan Area Network (MAN), Operating Missions as Nodes on the Internet (OMNI), Wide Area Network (WAN), wireless network, cellular network and other communication networks.

[0045] As mentioned above, client 100 and server 200 can both include equipment, and this equipment can be any electronic device that can receive, process and send information, for example, by communication component.The example of electronic equipment can include but is not limited to client device, personal digital assistant (personal digital assistant, PDA), mobile computing device, smart phone, cellular phone, e-book reader, messaging device, computer, personal computer (personal computer, PC), desktop computer, laptop computer, notebook computer, netbook, handheld computer, tablet computer, server, server array or server farm, web server, network server, internet server, workstation, network equipment, web equipment, distributed computing system, multiprocessor system, system based on processor, consumer electronic device, programmable consumer electronic device, gaming device, TV, set-top box, wireless access point, base station, user station, mobile user center, wireless network controller, router, hub, gateway, bridge, switch, machine or its combination.Embodiment is not limited in this case.

[0046] The device can perform processing operations or logic for one or more applications, such as the exemplary client application 110 and the remote application 210, for communication components, an operating system (particularly, a kernel of the operating system), and for other software elements using one or more processing components (i.e., processing circuitry). A processing component or processing circuitry can include various hardware elements, such as a device, a logic device, a component, a processor, a microprocessor, a circuit, a processor circuit, a circuit element (e.g., a transistor, a resistor, a capacitor, an inductor, etc.), an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a digital signal processor (DSP), a field programmable gate array (FPGA), a memory cell, a logic gate, a register, a semiconductor device, a chip, a microchip, a chipset, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether embodiments of the disk authentication unit and / or disk sealing unit described below are implemented using hardware elements and / or software elements can vary depending on any number of factors, such as desired computing rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints, depending on the needs of a given implementation.

[0047] The device can use one or more communication components to perform communication operations or logic for communication with other devices. The communication component can implement any known communication technology and protocol, such as a technology suitable for a packet-switched network (e.g., a public network such as the Internet, a private network such as an intranet, etc.), a circuit-switched network (e.g., a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with suitable gateways and converters). The communication component can include various types of communication elements, such as one or more communication interfaces, network interfaces, network interface cards (NICs), wireless devices, wireless transmitters / receivers (transceivers), wired and / or wireless communication media, physical connectors, etc. For example, but not limited to, communication media include wired communication media and wireless communication media. Examples of wired communication media can include wires, cables, metal conductors, printed circuit boards (PCBs), backplanes, switch fabrics, semiconductor materials, twisted pairs, coaxial cables, optical fibers, propagation signals, etc. Examples of wireless communication media can include acoustic, radio-frequency (RF) spectrum, infrared, and other wireless media.

[0048] The device can be used as Figure 1 The communication signals shown are communicated with other devices over a communication medium via one or more communication components. The other devices may be internal or external to the device, depending on the needs of a given implementation.

[0049] The device can be implemented in the form of a distributed system that can distribute portions of the above-described structure and / or operations across multiple computing entities. Examples of distributed systems can include, but are not limited to, client-server architectures, three-tier architectures, N-tier architectures, tightly coupled or clustered architectures, end-to-end architectures, master-slave architectures, shared database architectures, and other types of distributed systems. The embodiments are not limiting in this context.

[0050] The client 100 and / or the server 200 may include a computing architecture as described below. In one embodiment, the computing architecture may include or be implemented as part of an electronic device. Examples of electronic devices may include the electronic devices described above. The embodiments are not limited in this context.

[0051] As used herein, the terms "device," "component," "client," "server," "service provider," "software provider," "disk authentication unit," and "disk sealing unit" are intended to refer to any computer-related entity, including hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture described below. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a server and the server may be a component. One or more components may reside within a process and / or thread of execution, and components may be localized on a single computer or distributed across two or more computers. Furthermore, components may be communicatively coupled to one another via various types of communication media to coordinate operations. Coordination may involve a one-way or two-way exchange of information, as desired. For example, components may communicate information in the form of signals transmitted over a communication medium. Information may be implemented as signals assigned to various signal lines. In such an assignment, each message is a signal. However, alternatively, other embodiments may employ data messages. Such data messages can be sent over a variety of connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0052] The computing architecture may include various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripheral devices, interfaces, oscillators, timing devices, graphics cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, the embodiments are not limited to implementation by this computing architecture.

[0053] The computing architecture may include a processing unit, a system memory, and a system bus. The processing unit may be any of a variety of commercially available processors, including but not limited to and processor; Applications, embedded security processors; and Processor; IBM and Cell processor; Core(2) and Processor; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures can also be used as the processing unit.

[0054] The system bus provides an interface for system components, including but not limited to system memory to the processing unit. The system bus can be any of a variety of bus structures, which can be further interconnected to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters can be connected to the system bus via a slot architecture. Exemplary slot architectures can include but are not limited to Accelerated Graphics Port (AGP), Plug-in Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended), PCI(X), PCI Express, Personal Computer Memory Card International Association (PCMCIA), etc.

[0055] The computing architecture may include or implement a computer-readable storage medium to store logic. Examples of computer-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, etc. The embodiments may also be implemented at least in part as instructions contained in or on a non-transitory computer-readable medium, which can be read and executed by one or more processors to implement the operations described herein.

[0056] The system memory may include various types of computer-readable storage media in the form of one or more relatively high-speed memory cells, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), double-data-rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, austenite memory, phase change or ferroelectric memory, micron silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, device arrays such as Redundant Array of Independent Disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state disks), and memory devices. drive, SSD) and any other storage medium suitable for storing information. System memory may include non-volatile memory and / or volatile memory. Basic input / output system (BIOS) may be stored in non-volatile memory.

[0057] The computing architecture may include various types of computer-readable storage media in the form of one or more relatively slow memory units, including an internal (or external) hard disk drive (HDD), a magnetic floppy disk drive (FDD) for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk (e.g., CD-ROM, DVD, or Blu-ray). The HDD, FDD, and optical disk drive may be connected to the system bus via an HDD interface, an FDD interface, and an optical drive interface, respectively. The HDD interface for an external drive implementation may include at least one or both of a Universal Serial Bus (USB) and an IEEE 1394 interface technology.

[0058] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, and the like. For example, a plurality of program modules may be stored in the drives and memory units, including an operating system (particularly, a kernel of the operating system), one or more application programs (also referred to herein as applications, such as the exemplary client application 110 and the exemplary remote application 210), other program modules, and program data. In one embodiment, the one or more application programs, other program modules, and program data may include, for example, various applications and / or components for implementing the disclosed embodiments.

[0059] Non-volatile storage of data provided by the present invention includes storage of disk images associated with applications to be executed within an enclave. A disk image, as provided by the present invention, is a computer file containing the contents and structure of a disk volume or portion of a disk, or even an entire data storage device such as an HDD, FDD, or optical drive. A trusted execution environment can place a specific portion of the disk, or create a specific disk volume for each enclave, so that read and / or write access to that portion or volume is limited to the application executing in the TEE. The disk image may specifically include configuration data and / or interpreted code, and may generally include input and / or output data for the application.

[0060] A user can enter commands and information into a computing device through one or more wired / wireless input devices, such as a keyboard and a pointing device such as a mouse. Other input devices may include a microphone, an infrared (IR) remote control, a radio-frequency (RF) remote control, a game controller, a stylus, a card reader, a data card, a fingerprint reader, a glove, a graphics tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a trackpad, sensors, a stylus, and the like. These and other input devices are typically connected to the processing unit through an input device interface coupled to a system bus, but may be connected through other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR port, and the like.

[0061] The display may also be connected to the system bus via an interface such as a video adapter. The display may be internal or external to the computing device. In addition to the display, computing devices typically include other peripheral output devices such as speakers, printers, etc.

[0062] A computing device can operate in a network environment using logical connections to one or more remote computers, such as remote devices, via wired and / or wireless communications. A remote device can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other general network node, and typically includes many or all of the elements described with respect to a computing architecture. Logical connections can include wired / wireless connections to a local area network (LAN) and / or a larger network (e.g., a wide area network (WAN)). Such LAN and WAN network environments are common in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communications network, such as the Internet.

[0063] When used in a LAN network environment, the device is connected to the LAN via a wired and / or wireless communication network interface or adapter. The adapter can facilitate wired and / or wireless communication with the LAN, which can also include a wireless access point disposed thereon to communicate with the wireless functionality of the adapter.

[0064] When used in a WAN network environment, the device can include a modem, or be connected to a communication server on the WAN, or have other means for establishing communication on the WAN, such as through the Internet. The modem can be internal or external, can be a wired and / or wireless device, connected to the system bus via an input device interface. In a network environment, program modules or parts thereof can be stored in a remote memory / storage device. It should be understood that the network connection is exemplary, and other means can be used to establish a communication link between devices.

[0065] The client / server device is operable to communicate with wired and wireless devices or entities using the IEEE 802 series of standards, such as wireless devices operatively arranged for wireless communications (e.g., IEEE 802.11 wireless modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth. TM Wireless technologies, such as Wi-Fi, can be predefined structures like traditional networks, or simply ad hoc communications between at least two wireless devices. Wi-Fi networks use wireless technologies known as IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect devices to each other, to the internet, and to wired networks (using IEEE 802.3-related media and functions).

[0066] Such as Figure 1Remote services such as remote computing are inherently insecure and are often subject to security breaches that could compromise the user's services and / or assets, as the remote devices are owned and maintained by a typically untrusted party, the service provider. Trusted services are a relatively new concept, and therefore, the number of solutions is limited.

[0067] The HTTPS protocol allows establishing a secure channel with an authenticated server. Server authentication can be based on an X.509 certificate provided by the server, which is authenticated and signed by an a priori trusted certificate authority (in particular, a root certificate authority). Even if the server can be authenticated in this way and a secure channel providing confidentiality and communication integrity can be established, the process can still be compromised by malware on the service provider side. For example, if the corresponding software component includes malware, memory access to the remote application from a software component with a higher privilege level than the remote application, in particular, system software components including the hypervisor (also known as the Virtual Machine Monitor (VMM)) and the operating system kernel, can compromise the remote application. In this case, even the setup of the secure channel, for example via a Transport Layer Security (TLS) client, can be compromised, making it impossible to guarantee confidentiality and communication integrity.

[0068] To address the issue of higher-privilege malware, the concept of a trusted execution environment (TEE) was introduced. Application code for remote applications, such as web servers or game clients, running at the lowest privilege level, executes in an isolated execution environment (a so-called secure container or secure enclave). Even privileged system code cannot access the contents of the enclave, thus protecting the code and data within it. Instead, a limited set of trusted functions is provided that can be used to access the contents of the enclave.

[0069] An example of a trusted execution environment is Intel Software Guard Extensions (SGX), as described in detail in the review paper "Intel SGX" by Victor Costan and Srinivas Devadas, published in the IACR Cryptology ePrint Archive in 2016. SGX is a set of extensions to the Intel architecture designed to provide integrity and confidentiality guarantees for security-sensitive computations executed on computers where all privileged software (kernel, hypervisor, etc.) could be malicious. SGX-enabled processors protect the integrity and confidentiality of computations within enclaves by isolating the enclave's code and data from the external computing environment, such as the operating system and hypervisor, as well as hardware devices connected to the system bus. In SGX, an enclave (secure container) may contain only the private data of the computation and the code that operates on it. Applications are typically built using trusted and untrusted parts, with only the trusted part executing within the enclave. Enclaves can work together to support a distributed architecture. Enclave code and data run in plaintext, and enclave data written to disk is encrypted and integrity-checked.

[0070] Figure 2 Schematically illustrates a method for trusted computing using a secure container as described above. Figure 1 A modified configuration of a client-server architecture is shown. In this configuration, a service provider 300 provides a trusted execution environment 320, in which one or more secure enclaves 330 are initialized to execute remote applications 310 that ultimately provide the remote services requested by the client 100. Each remote application 310 is associated with a disk image created when the corresponding enclave is set up. For simplicity, only the trusted portion of the remote application is shown in the figure.

[0071] Figure 3The concept of a typical runtime execution of an application in a secure container, as is known in the art, is illustrated. First, a remote application 400 is constructed using a trusted portion 410 and an untrusted portion 440, respectively. This application can be provided by the service provider 300 itself, for example as SaaS, or received from the client 100 via a secure channel. When the application (untrusted portion) runs, the system creates an enclave, which is placed in the processor's trusted memory. A trusted function is called, and execution is transferred to the enclave via a call gate. The enclave has full visibility into all process data while denying external access to enclave data. The trusted function returns the enclave data, and the application continues to execute normally. During execution, the enclave prevents privileged system code 450 from accessing trusted portions, such as the operating system (OS), virtual machine monitor (VMM), BIOS, system management mode (SMM), etc. However, as described above, system calls to trusted functions, such as disk I / O or interrupts, can be executed outside the enclave to perform system calls and are therefore subject to potential security issues associated with privileged system code. As mentioned above, this problem can be partially addressed by porting the Linux Kernel Library (LKL) to Intel SGX.

[0072] In addition to security issues related to system calls, remote computing also requires a mechanism to ensure that the applications executed within the enclave are themselves trustworthy.

[0073] Like its predecessors, the Trusted Platform Model (TPM) and Trusted Execution Technology (TXT), SGX relies on software attestation to prove to the user that he / she is communicating with specific software running in a secure container hosted by trusted hardware. The attestation can be a cryptographic hash, such as SHA-1, SHA-2, SHA-256, MD4, or MD5, that verifies the contents of the secure container. Service providers can load any application into the secure container, but users / clients will refuse to load their data into a secure container whose content hash does not match the expected value. Processor- and enclave-specific sealing keys can be used to securely store and retrieve sensitive information that may need to be stored on disk, as described in more detail below.

[0074] The SGX enclave 330 can generate an SGX report containing, for example, a cryptographic hash of the enclave data of the remote application 310. The service provider can also generate a linkable quote on the SGX report, which can be signed by a Quoting Enclave (QE) (not shown). The Quoting Enclave can, in turn, generate a quote Q on the SGX report containing the report and the cryptographic hash. The QE can be provided as a separate enclave on the service provider 300 side. The SGX enclave 330 can request an attestation quote Q from a third-party attestation service (e.g., Intel's Attestation Service (IAS)), which can reside on a remote server. The attestation response from the attestation service can be signed using a public key and can include a copy of the quote. The service provider 300 can then send the quote, the IAS attestation report regarding the quote, and the data as an attestation response to the client 100, which requested attestation in the corresponding attestation request. After receiving the attestation response, the client 100 can verify the validity of the quote by checking the signature on the IAS response using the public key. The client can further verify that the cryptographic hash of the data corresponds to the hash within the quote. In this way, the data can be trusted to come directly from the sending enclave.

[0075] The cryptographic hash may be generated over any data that the remote application 310 may need to be securely processed by the secure enclave 330 of the service provider 300. For example, the data may include the binary code of the application.

[0076] If an application generates a public key for establishing a secure channel between the client 100 and the secure enclave 330, the client can verify that the public key was generated by the SGX-protected application using a cryptographic hash of the corresponding binary code, the identity of which is given by the hash. This public key can be used to generate a shared key for the secure channel between the client 100 and the secure enclave 330.

[0077] If the application is a remote application to be executed as both SaaS and IaaS services, the cryptographic hash can be used as the identification of the application. In this case, the client 100 can verify the identification of the application based on the authentication response.

[0078] By utilizing Figure 2 Trusted Execution Environment and Authentication to expand Figure 1 In a client-server architecture, the client 100 can verify the identity of a remote application 310 executing in the trusted execution environment 320 of the service provider 300.

[0079] However, determining whether an application's execution is trustworthy, particularly with respect to disk access, presents challenges. For example, if the operating system on the remote server itself contains malicious code, a security breach could occur. Often, an application's trusted functions may remain unsecured, for example by including unsafe function calls outside a secure enclave. In such cases, simply verifying the application ID will not detect a security breach.

[0080] Intel SGX attempts to address this problem by adding an LKL to the Trusted Execution Environment, which is part of the operating system. Figure 4 The concept of an SGX-LKL enclave, known in the art, is illustrated. By porting the LKL to Intel SGX, an SGX-LKL enclave 530 can be created, rather than a simple SGX enclave, to execute applications in a secure container. In addition to executing applications 510 (the trusted portion), the operating system's library LKL 560 is executed within enclave 530. Therefore, system calls to LKL 560 functions are handled within the enclave. Typical LKL functions include thread synchronization, memory management, file systems, networking, and signal handling. Furthermore, the standard C library and runtime support can be ported to Intel SGX and thus executed within the SGX-LKL enclave 530. Consequently, transitions out of the SGX-LKL enclave can be reduced to calls to the host operating system 550 and the loader / launcher, which can be executed via the hypercall interface.

[0081] Because the authentication of the SGX-LKL enclave 530 includes the library OS 560, security vulnerabilities caused by malicious system code within LKL functions can be avoided. However, as described above, the SGX-LKL enclave authentication does not include the contents of the disk image associated with the application, so that, in particular, the application's interpreted code and configuration files are not verified. Furthermore, because the contents of the disk image are unprotected, the data on the disk can be exposed and / or altered without changing the identity of the corresponding SGX-LKL enclave. Even when using SGX-LKL with an encrypted disk, freshness issues still exist, allowing attackers to cause the SGX-LKL to execute malware on the disk, thereby modifying the SGX-LKL's memory and changing its behavior.

[0082] The present invention addresses these issues by extending SGX-LKL with two additional mechanisms: a disk authentication mechanism and a disk sealing mechanism. Disk authentication and disk sealing can be added as modules in software and / or as a disk authentication unit and / or disk sealing unit to the aforementioned processing circuitry in hardware. The primary purpose of disk authentication provided according to the present invention is to verify the disk image associated with an application before executing the application within the SGX-LKL enclave. In other words, during the authentication process, in addition to the authenticity of its executable file, SGX-LKL is also able to prove the authenticity of the contents of the disk image it is processing. The disk sealing unit ensures that only disks authenticated by the disk authentication unit will be used, while ensuring that their contents remain protected. The contents of the disk image can include at least one of the following: the application's executable file, the application's interpreter, the application's execution data, and the application's configuration file.

[0083] Figure 5 The owner-based disk authentication process and the content-based disk authentication process provided by two embodiments of the present invention are shown. During the initialization process of the SGX-LKL enclave, disk authentication can be integrated as a module. The purpose of disk authentication is to ensure that the content of the disk image can be verified during the SGX-LKL software authentication process. By implementing the disk authentication provided according to the present invention, whenever the SGX-LKL enclave faces the challenge of proving its identity, it will not only authenticate the authenticity of the LKL and the application, but also the authenticity of the disk image associated with the application. Figure 5 The left and right sides of FIG. 3 describe two possible implementations of the disk authentication module / unit.

[0084] According to a first embodiment of the disk authentication unit, in the case where there is an owner of the application associated with the encryption key, an owner-based disk authentication process is implemented that is most applicable. The purpose of the owner-based disk authentication process is to verify the integrity of the disk image generated by the owner of the application.

[0085] In the first step 671 of owner-based disk attestation, the client 100 provides the public key PK associated with the owner of the application to the service provider 300. When the function to create an SGX-LKL enclave is called, for example, by the service provider 300 in response to a request to execute a specific application in the trusted execution environment 320, the disk attestation unit adds the public key PK to the memory of the SGX-LKL enclave before creating the enclave. Alternatively, a cryptographic hash of the public key PK can be added to the memory of the SGX-LKL enclave before initializing the enclave. The cryptographic hash can be SHA-1, SHA-2, SHA-256, MD4, MD5, etc.

[0086] In the next step 672, the enclave is started by creating the enclave. Since the public key PK or a cryptographic hash of the public key PK was added to the memory of the SGX-LKL enclave before initializing the enclave, the enclave identity represented by the value of MRENCLAVE in Intel SGX also reflects the public key.

[0087] In response to an authentication request from client 100, the public key PK or its cryptographic hash may be used to authenticate ownership of the enclave. To this end, the authentication request may include the public key PK associated with the owner as input to the SGX-LKL enclave. The remote server may compute a cryptographic hash for the public key PK provided with the authentication request, depending on whether the public key or its cryptographic hash has been added to the enclave's memory. Then, as part of the authentication process, verifying the enclave's identity includes comparing the received public key or its cryptographic hash with the public key or its cryptographic hash added to the enclave's memory, respectively. If the received public key and the stored public key or their corresponding cryptographic hash do not match, the SGX-LKL enclave may automatically cease execution and report the failed authentication to client 100 in the authentication response.

[0088] Alternatively or additionally, upon launch, the SGX-LKL enclave may receive a cryptographic signature of the contents of the disk image associated with the application as input to the enclave, for example, as part of the aforementioned authentication request. The cryptographic signature may be determined by the client 100 using the owner's private key corresponding to the public key added to the enclave's memory. The cryptographic signature may be calculated by computing a cryptographic hash of the contents of the disk image associated with the application and subsequently signing the cryptographic hash using the owner's private key. As part of the authentication process, in step 673, the remote server 300 may compute a corresponding cryptographic hash H of the contents of the disk image associated with the SGX-LKL enclave. The received cryptographic signature sig may then be verified against the contents of the disk image associated and used by the SGX-LKL enclave using the public key PK stored in the SGX-LKL enclave's memory or the public key PK received as input to the enclave as described above. If the cryptographic signature processed using the public key matches the cryptographic hash H computed in step 673, the process continues to step 676, where disk sealing is performed on the disk image as described below. If the two values ​​do not match, in step 675 , the SGX-LKL enclave execution stops and control flow exits the enclave.

[0089] Alternatively or additionally, according to the second embodiment, disk authentication may be implemented as Figure 5 The content-based on-disk authentication process is shown on the right. The content-based on-disk authentication process does not require the presence of the owner and is therefore particularly suitable for securely executing decentralized applications that do not have an owner but still must prove their identity.

[0090] In the first step 681 of the content-based disk attestation process, a hash, specifically a cryptographic hash H, of the contents of the disk image associated with the application is calculated on the client side if the disk image is provided by the client 100 to the service provider 300; or a hash, specifically a cryptographic hash H, of the contents of the disk image associated with the application is calculated on the server side if the application is provided as SaaS by the service provider 300. The resulting cryptographic hash H is then added to the memory of the SGX-LKL enclave in step 682 before initializing the enclave. Thus, the enclave's identity reflects the contents of the disk image before the enclave is started in SGX-LKL software attestation.

[0091] Subsequently, in step 683, the SGX-LKL enclave is started by creating an SGX-LKL enclave that includes the application, the LKL OS library, and the cryptographic hash H. In step 687, before sealing the disk and executing the application within the SGX-LKL enclave, a second cryptographic hash H' is calculated for the contents of the disk image associated with the SGX-LKL enclave to be used during the execution of the SGX-LKL enclave. This calculation may be performed in response to an explicit authentication request from the client 100. As will be described below, Figure 6 As shown in the disk sealing process described in more detail, the disk image to be used during execution of the SGX-LKL enclave can be a copy of the disk image originally associated with the SGX-LKL enclave.

[0092] In step 685, it is determined whether the cryptographic hashes H and H' are identical. If so, the process proceeds to step 687, where disk sealing is performed on the disk image as described below. However, if the two cryptographic hashes do not match, in step 686, SGX-LKL enclave execution is halted and control flow exits the enclave.

[0093] Finally, the software authentication process provided by the present invention stops application execution if verification of the enclave's identity fails, regardless of the reason for the identity verification failure. Thus, in addition to detecting malicious applications, software authentication provided by the present invention also detects changes in owner and / or disk image.

[0094] Figure 6 The disk sealing process provided by the present invention is shown. The purpose of the disk sealing process is to protect the content of the disk image during the execution of the application and to ensure that the content of the disk image matches the authentication method called by the disk authentication unit.

[0095] At the start of enclave execution, i.e. after the enclave is started in step 672 or step 683, a random encryption key K is generated on the remote server 300 in step 691. As described above, the generation of the random encryption key K may be performed as part of the disk sealing module or by a dedicated disk sealing unit of the processing circuit. Figure 5 As shown in steps 673 and 684 of the SGX-LKL enclave, the disk image associated with the SGX-LKL enclave after booting the enclave is read and a cryptographic hash of the contents of the disk image is calculated. Subsequently, a copy of the disk image, newdisk, is created in step 692 of the disk sealing process, encrypted using the random encryption key K.

[0096] Depending on whether content-based (CB) disk authentication or owner-based (OB) disk authentication is performed, in step 685, i.e., after the enclave is launched, a determination is made as to whether the cryptographic hash H' computed for the contents of the disk image associated with the SGX-LKL enclave is the same as the cryptographic hash H of the contents of the disk image associated with the application that was inserted into the enclave's memory prior to initialization. Alternatively, in step 674, the cryptographic signature sig provided as input to the SGX-LKL enclave is verified against the cryptographic hash H computed for the contents of the disk image associated with the SGX-LKL enclave using the public key PK. As described above, a failure in verification will result in an immediate halt to execution in steps 686 and 675, respectively. Since the encryption key K is randomly generated, any new execution of the SGX-LKL enclave will not be able to use the encrypted disk. Therefore, an attacker launching a new instance of the SGX-LKL enclave will not be able to access the encrypted disk.

[0097] If the hash verification succeeds, the disk seal unit encrypts the random encryption key K using the SGX-LKL enclave's encryption key, such as the sealing key, in step 693 and stores the result in the copy of the disk image in step 694. The encrypted random encryption key can be attached to the copy of the disk image as a seal. The encrypted random encryption key can be attached to the copy of the disk image using LKL functions. Storing the encrypted random encryption key in the copy of the disk image ensures that the encrypted disk image can be used with other executions or instances of the SGX-LKL enclave. Because the SGX-LKL enclave's encryption key, EK, is the same for all instances of the SGX-LKL enclave with the same identity, the encrypted disk image can be used by other instances of the SGX-LKL enclave, for example in a distributed execution environment, by decrypting the random encryption key attached to the encrypted disk image and using the random encryption key to decrypt the disk image.

[0098] Because the encrypted random encryption key is only added to the encrypted disk image if the disk authentication process described above is successful, the disk sealing mechanism provided by the present invention ensures that only disk images authenticated by the disk authentication unit will be used by the SGX-LKL enclave. The disk image is encrypted using the random encryption key, which is then encrypted using the enclave-specific encryption key EK, ensuring that only the SGX-LKL enclave with the encryption key EK and other instances of the enclave with the same identity can access and modify the disk image. Thus, the disk sealing mechanism provides confidentiality and integrity to disk images associated with applications, and further guarantees freshness within the SGX-LKL enclave due to the use of the random encryption key.

[0099] Finally, the disk sealing unit can redirect all disk accesses from the SGX-LKL enclave to the encrypted copy of the disk image. Therefore, since the compromised SGX-LKL enclave does not have access to the encrypted copy of the disk image associated with the correct SGX-LKL enclave, the above attacks that rely on executing SGX-LKL using a disk image encrypted with the attacker's key provided to the SGX-LKL enclave will not succeed.

[0100] The above extensions to SGX-LKL using disk authentication and disk sealing ensure that software authentication covers not only the executable file, but also the contents of the associated disk image. In addition, the described disk sealing makes it difficult for an attacker to modify and corrupt the disk image associated with the application executed in the secure container. The present invention provides a library OS running in SGX that can prove the authenticity of the contents of the disk images it uses and can encrypt the disk images. The disclosed method for authenticating the contents of the disk image can be based on the owner's signature and / or the contents of the disk image. In addition, a method for sealing the disk image after authenticating the authenticity of its contents is described.

Claims

1. A device for software authentication, characterized in that: comprising a processing circuit for: Initializing an enclave in a trusted execution environment (TEE), wherein the enclave includes operating system libraries; performing software authentication to verify the identity of the enclave; executing an application within the enclave using the operating system libraries; The performing of the software authentication includes authenticating the content of a disk image associated with the application.

2. The device according to claim 1, characterized in that The content of the disk image includes at least one of the following items: an executable file of the application, an interpreter of the application, execution data of the application, and a configuration file of the application.

3. The device according to claim 1, characterized in that The processing circuit is further configured to add a public key or a cryptographic hash of the public key to a memory of the enclave prior to initializing the enclave.

4. The device according to claim 3, characterized in that The processing circuit is further configured to receive another public key as input to the enclave, wherein verifying the identification of the enclave comprises verifying the received another public key or the cryptographic hash of the received another public key calculated by the processing circuitry based on the public key or the cryptographic hash of the public key added to the memory of the enclave.

5. The device according to claim 3, characterized in that The processing circuit is further configured to receive, as input to the enclave, a cryptographic signature of the contents of the disk image. wherein verifying the identity of the enclave comprises verifying the contents of the disk image using the public key and the cryptographic signature.

6. The device according to claim 1, characterized in that The processing circuitry is further configured to apply a cryptographic hash function to the contents of the disk image and add the resulting cryptographic hash to a memory of the enclave prior to initializing the enclave.

7. The device according to claim 6, characterized in that Verifying the identity of the enclave includes verifying the contents of the disk image by using the cryptographic hash.

8. The device according to claim 4, characterized in that The processing circuit is further configured to: stop executing the application when the verification of the identifier of the enclave fails.

9. The device according to any one of claims 3 to 8, characterized in that The processing circuit is further configured to: generate a random encryption key before executing the application; read the disk image; and create a copy of the disk image by encrypting the disk image using the random encryption key.

10. The device according to claim 9, characterized in that The processing circuit is further configured to, upon successful verification of the identity of the enclave, encrypt the random encryption key using a key of the enclave and add the encrypted random encryption key to the encrypted copy.

11. The device according to claim 10, characterized in that The processing circuit is further configured to redirect all disk access calls of the operating system library to the encrypted copy during execution of the application.

12. A method for software authentication, characterized in that: The method comprises: Initializing an enclave in a trusted execution environment (TEE), wherein the enclave includes operating system libraries; performing software authentication to verify the identity of the enclave; executing an application within the enclave using the operating system libraries; The performing of the software authentication includes authenticating the content of a disk image associated with the application.

13. The method according to claim 12, characterized in that Also includes: Prior to initializing the enclave, adding a public key or a cryptographic hash of the public key to the enclave's memory; receiving as input to the enclave another public key and a cryptographic signature of the contents of the disk image; verifying the received another public key or the cryptographic hash of the received another public key against the public key or the cryptographic hash of the public key added to the memory of the enclave; The contents of the disk image are verified by using the public key and the cryptographic signature.

14. The method according to claim 12, characterized in that Also includes: applying a cryptographic hash function to the contents of the disk image; Prior to initializing the enclave, adding the resulting cryptographic hash to the enclave's memory; The contents of the disk image are verified by using the cryptographic hash.

15. The method according to any one of claims 12 to 14, characterized in that Also includes: Generate a random encryption key; Reading the disk image; prior to executing the application, creating a copy of the disk image by encrypting the disk image using the random encryption key; upon successful verification of the identity of the enclave, encrypting the random encryption key using a key of the enclave, such as a sealing key of the enclave; The encrypted random encryption key is added to the encrypted copy.

Images