Method and apparatus for protected code execution on clients

In areas of technology such as Software as a Service (SaaS) and grid computing, numerous client machines may be asked to download or stream an application or applications from a server, execute code, and return data to the server for archiving and/or additional processing. However, while the majority of clients may have no malicious intent, if even a small number of clients are intentionally malicious or infected with malicious agents the impact can be detrimental to the organizations involved in the computing effort. For example, if a pharmaceutical company is using a distributed client base for a pharmaceutical simulation part of the distributed computing process may include sending sensitive material (e.g., code, data, and other information) to distributed client compute nodes. A compromised client may give undesirable parties access to this sensitive data. Additionally, a compromised client may tamper with the data and calculations thereby causing a negative impact on the pharmaceutical company's product development. Thus, sensitive materials may be compromised by malicious and/or malfunctioning applications and devices on the client computing platform.

The accompanying drawings, incorporated in and constituting a part of this specification, illustrate one or more implementations consistent with the principles of embodiments of the invention and, together with the following description of the embodiments, explain such implementations. The drawings are not necessarily to scale, the emphasis instead being placed upon illustrating the principles of embodiments of the invention. In the drawings:

FIG. 1 is a block diagram of a method according to one embodiment of the invention.

FIG. 2 is a block diagram of a method according to one embodiment of the invention.

FIG. 3 is a system block diagram according to one embodiment of the invention.

The following description refers to the accompanying drawings. Among the various drawings the same reference numbers may be used to identify the same or similar elements. While the following description provides a thorough understanding of various aspects of embodiments of the claimed invention by setting forth specific details such as particular structures, architectures, interfaces, and techniques, such details are provided for purposes of explanation and should not be viewed as limiting. Moreover, those of skill in the art will, in light of the present disclosure, appreciate that various aspects of embodiments of the invention claimed may be practiced in other examples or implementations that depart from these specific details. At certain junctures in the following disclosure, descriptions of well known devices, circuits, and methods have been omitted to avoid clouding the description of various embodiments of the invention with unnecessary detail.

FIG. 1 is a block diagram of a method 100 according to one embodiment of the invention. In block 105 , a processor (Client 1 processor), such as a central processor unit (CPU), included in a client device or environment (Client 1 ) may include a private key. Client 1 may communicate with a server (Server 1 ) or similar apparatus or system. Server 1 and Client 1 processor may use various forms of cryptography to protect sensitive information transferred or communicated between Server 1 and Client 1 processor. Server 1 and Client 1 processor may use, for example, symmetric-key systems that use a single key that both the sender and recipient have and/or public-key systems that use two or more keys, such as a public key known to multiple parties and a private key that only the recipient of messages uses. Still referring to block 105 , Client 1 processor may include a private key that is part of a public-key system. The CPU's private key may be unique to the processor and may be obtained from, for example, a device manufacturer (e.g., Intel Corporation).

In one embodiment of the invention, Client 1 processor may include a direct anonymous attestation (DAA) private key based on public-key encryption. DAA may use a single public key for many unique private keys. Thus, there is no “master” private key. As a result, the security of Server 1 /Client 1 communications and privacy of client 1 may be increased. Of course, the invention is not limited to using DAA and may instead, for example, include a single private key in a series of client CPUs that cooperate with a published public key. Specifically, a manufacturer may embed a master private key in the Client 1 CPU, while publishing the public key. This format may streamline negotiations between Client 1 and Server 1 , which may be desirable in certain situations. In other words, embodiments of the invention are not limited to any one security protocol or measure and may use any number of techniques such as DAA or various forms of public key infrastructure (PKI) schemes.

In block 110 , Server 1 may communicate to Client 1 its desire to initiate, for example, distributed computing with Client 1 by initiating a key exchange process with Client 1 processor. To do so, Server 1 may transfer materials such as a message, job, or binary large object (BLOB) to Client 1 processor. A BLOB may be many things, including a collection of binary data stored as a single entity. A BLOB may include multimedia objects, data, programs or even fragments of code. In one embodiment of the invention, Server 1 may attach a digital certificate to the BLOB. The digital certificate may verify that Server 1 is indeed Server 1 , and provide Client 1 processor with the means to encode a reply. For example, the digital certificate may be encrypted and contain Server 1 's public key as well as a variety of other identification information (e.g., name of Server 1 ). The certificate may be digitally signed by a certificate authority (CA) that issued the certificate. The certificate may be based on a certificate standard such as X.509. The above may all be done in accordance with PKI schemes or the like (e.g., web of trust).

In block 115 , Client 1 may decide whether to accept a job or the like, possibly included in or associated with the BLOB, from Server 1 . To do so, in one embodiment of the invention Client 1 is first able to determine if it trusts Server 1 to submit a workload for Client 1 to process. For example, Client 1 may use the CA's published public key to decode the digital certificate, verify the certificate as issued by the CA, and obtain Server 1 's public key and identification information held within the certificate. Based on this information, Client 1 may determine whether to accept the BLOB from Server 1 .

In some embodiments of the invention, Client 1 may determine whether to accept the job from Server 1 based on still other information. For example, such information may be included in the BLOB and may address what resources from Client 1 will be used in processing the BLOB and to what magnitude they will be used. This information may be further useful for accounting purposes wherein Client 1 may even bill Server 1 based on Server 1 's use of Client 1 resources.

In block 120 , assuming Client 1 has decided to accept the job from Server 1 , Client 1 processor may send its public key to Server 1 . For example, Client 1 processor may generate a new key (NK) using a cryptographic engine included in Client 1 processor or CPU. In other words, for any specific transaction the embedded CPU may negotiate a session key with the server. NK may be a public-private key pair based on, for example, a public-key system such as a Diffie-Hellman or Rivest, Shamir, and Adelman (RSA) public-private key pair. Client 1 processor may form a digital certificate identifying Client 1 and including the NK public key corresponding to Client 1 CPU's unique private key. The certificate may be signed with Client 1 CPU's private key, thereby allowing the external entity (e.g., Server 1 ) to validate the certificate using the NK public key. This may prevent tampering by an untrustable client.

Furthermore, in one embodiment of the invention the certificate may include information based on the DAA characteristics of Client 1 , thereby providing assurance to Server 1 of Client 1 's identity without necessarily specifically identifying Client 1 (e.g., using a trusted group signature associated with DAA). DAA may require that the CPU has a unique DAA private key and that the server obtain a corresponding DAA certificate with the associated DAA public key. The DAA protocol may protect Client 1 's privacy so that Client 1 may communicate with Server 1 multiple times without Server 1 knowing whether it has previously communicated with Client 1 .

In addition, in one embodiment of the invention Client 1 's acceptance of Server 1 's job may be a conditional acceptance. For example, Client 1 may limit processing of the job to certain Client 1 resources (e.g., Client 1 's CPU and cache but not Client 1 's system memory). As another example, Client 1 may conditionally allow execution of the job when Client 1 CPU is in HLT or Cx states (i.e., not fully engaged in productive actions for the host environment). Server 1 may then determine whether to accept Client 1 's conditional acceptance.

In block 125 , Server 1 may encrypt a private session key with Client 1 processor's public key. For example, Server 1 received, via a Client 1 application, the signed certificate containing Client 1 CPU's NK (e.g., DAA based public key). After receiving the signed certificate Server 1 may verify the NK and certificate are for an embedded CPU with cryptographic capability and that the CPU originated from a trusted manufacturer. Server 1 may accept the NK as a valid key for subsequent communication, assuming Server 1 now trusts Client 1 . Server 1 may then generate a symmetric-key system-based session key (SK), encrypt the SK with Client 1 processor's public NK, and send the encrypted SK to Client 1 CPU via the Client 1 application. The SK may allow for simpler and faster communications between Client 1 processor and Server 1 , while the SK was properly secured using the NK. The SK may be based on, for example, the Data Encryption Standard (DES) or Advanced Encryption Standard (AES).

In block 130 , Server 1 may transmit the encrypted SK through a Client 1 application. A Client 1 application may be, for example, an agent that runs on host Client 1 and facilitates communication/interfacing to the trusted Client 1 CPU. Host Client 1 may freely run this agent since a “benevolent” user may want to facilitate the distributed processing capability even though the host is shielded from seeing the data. The application may operate similarly to an internet service provider (ISP) passing data between a browser and bank server even though the ISP cannot “see” the data that is encrypted with SSL technology. As another example, host software on Client 1 may act as a conduit for a payload (e.g., Blob). Use of certain technology, such as Intel Corporation's Active Management Technology, may allow communication of the payload to the Client 1 platform independent of the Client 1 host software stack. As yet another example, a payload may be received by Client 1 processor via another out-of-band component or mechanism such as, for example, a manageability controller and firmware stack that bypasses the host. Thus, because the encryption/decryption engine is included in Client 1 CPU in one embodiment of the invention, and not elsewhere in Client 1 , communications between Server 1 and Client 1 are never “in the open” (i.e., unencrypted) on Client 1 except for within Client 1 CPU. Thus, because the Client 1 application does not include the NK private key to decrypt the transmitted SK, the SK is “passed through” the application and to Client 1 CPU where it can be decrypted in a protected environment. For example, the SK may be passed through Client 1 's host software environment or other out of band mechanism (e.g., manageability controller and firmware stack).

In block 135 , Client 1 processor decrypts Server 1 's private SK using Client 1 processor's private NK and cryptographic engine, both included Client 1 CPU. Thus, Client 1 CPU “unwraps” the SK and now a Server 1 application and Client 1 CPU have a common key SK.

In block 140 , Client 1 CPU processes the job and/or BLOB. In step 145 , Client 1 CPU encrypts the results with Server 1 's private SK and returns the results to Server 1 . A new SK may be generated for every session between Client 1 processor and Server 1 . In an embodiment of the invention, Server 1 may ensure results from Client 1 CPU have not been tampered with. For example, if the results are tampered with before arriving at Server 1 , a digital signature from Client 1 CPU may expose the tampering. At that point, Server 1 may reject the job.

Unlike conventional methods of trusted computing, in various embodiments of the invention Client 1 applications never see an “unwrapped” BLOB or related results because only Client 1 processor (e.g., CPU) includes the necessary cryptographic engine and SK private key. Conventional software-based mechanisms, such as “sandboxing”, may be insufficient in this regard. For example, sandboxing may include a set of rules used when creating an applet wherein the rules prevent certain functions when the applet is sent as part of a Web page. If the applet is allowed unlimited access to memory and operating system resources, it may do harm in the hands of someone with malicious intent. The sandbox may attempt to create an environment in which there are strict limitations on what system resources the applet can request or access. However, sandboxing and similar techniques may be limited in their ability to secure transferred code since they may be subject to software-based attacks (e.g., running virtual software to monitor other system elements or running one software application to monitor another application). Also, these methods may allow information to be stored on system memory “in the clear” (i.e., unencrypted). This may be avoided in various embodiments of the invention because Client 1 CPU includes the encryption/decryption engine and keys so unencrypted information is never stored in system memory. As a result, embodiments of the invention may protect material being executed or processed from the host it is executing on but still enable the host to determine if such execution should be permitted. The remote computing node is thus controlled to an acceptable security level while still allowing the server and node to evaluate one another as well as the perspective job.

Thus, various embodiments of the invention allow a server to encrypt code and data it may send to a client. The client's processor (e.g., CPU) may then decrypt the code/data content, execute the code, encrypt the results, and send the results back to the server. This sequence of events may occur while the execution or processing of code/data is restricted to the client CPU, which may be a trusted processing engine. Any code/data outside the client CPU (e.g., located in system memory) is always encrypted. For example, in one embodiment of the invention, when Client 1 CPU is internally executing code for secure functions, its internal logic may dictate policy that all reads/writes from RAM must be sealed and signed. In some embodiments of the invention, resources outside the CPU or processor may be utilized to process the job, but such resources would do so while only seeing encrypted data/code. Such services may ensure such data/code/information is not tampered with using, for example, digital signature or hash technology.

Also, in various embodiments of the invention some results from Client 1 CPU may exit the CPU unencrypted. Such unencrypted data may include, for example, usage statistics (e.g., what resources were used and for long were they used) that can serve accounting and billing purposes.

FIG. 2 is a block diagram of a method 200 according to one embodiment of the invention. In block 205 , after the server and client processor exchange key information as described above, for example, the server application may generate a session key (SK). In block 210 , the server may create and forward a remote execution BLOB, along with the SK, to the client processor. The BLOB may contain materials such as data, code, and other information. The BLOB may be encrypted with the SK and signed by the server application. In block 215 , the client application may verify the server signature and forward the still-encrypted BLOB to the client processor for execution. In block 230 , the client processor may decrypt and execute the BLOB and then encrypt the output data with the SK. In blocks 235 and 240 , the encrypted results may be passed through the client application and to the server application.

In light of the above, it should be evident that in various embodiments of the invention portion of the client (e.g., system memory) cannot “see” the content of the code or data that it is executing, the client cannot interfere or tamper with the job received from the server, and the results are re-sealed such that only the initiating service (e.g., Server 1 ) can see the results. Still, the client is also able to determine if it trusts a server to submit a workload for the client processor to process even though the client is unable to monitor or tamper with execution of the workload. Furthermore, the server has a high degree of assurance that portions of the client (e.g., system memory) has not seen the source code, data or results, and that the job actually executed as directed to completion. Also, there is an assurance of tamper resistance, including tampering from software based attacks and hardware-based attacks (e.g., system bus snooping). Additionally, the client platform can determine which servers/capabilities are “allowed” to submit a workload (even though the client platform has no knowledge of the actual execution and is essentially processing a “black box” or unknown job). As a result, embodiments of the invention provide assurances and support for, as an example, high performance grid computing and SaaS software development models that may be performed by distributed (and potentially un-trusted) compute nodes. For example, since SaaS allows an application to be hosted as a service provided to customers across the Internet, security is paramount for such an application.

In one embodiment of the invention, a DAA (or static) key may be set at manufacture time. For example, with DAA technology a random key may be generated in a secure facility (e.g., factory) and signed with a “master” key. The signed public key (i.e., certificate) may be loaded into the CPU and freely extracted. The private half of the key may also be stored in the CPU as, for example, a set of “fuses” (one bit literally fused/burned) or written to NVRAM or ROM (engraved in the silicon die) in the CPU package. Once the private key is stored, the private key may be removed from the manufacturing equipment.

While the functions herein may be described as being carried out by a particular structure, several components, including the memory controller, operating system, BIOS, run-time software, application software, hardware, firmware, or any combination thereof, may carry out the functions herein without detracting from the scope of the present invention. FIG. 3 is a system block diagram for use with one embodiment of the invention. Computer system 400 , which may be a client or server, includes a processor 410 , which may include a general-purpose or special-purpose processor such as a microprocessor, microcontroller, a programmable gate array (PGA), graphics processing units (GPU), embedded management controllers, and the like. Processor 410 may include a cache memory controller 412 and a cache memory 414 . Processor embodiments may include single or multiple cores and may be a multiprocessor system with multiple processors 410 . Processor 410 may be coupled over a host bus 415 to a memory hub 430 , which may be coupled to a system memory 420 (e.g., a DRAM) via a memory bus 425 . Memory hub 430 may also be coupled over an Advanced Graphics Port (AGP) bus 433 to a video controller 435 , which may be coupled to a display 437 . Memory hub 430 may also be coupled (via a hub link 438 ) to an input/output (I/O) hub 440 that is coupled to an input/output (I/O) expansion bus 442 and a Peripheral Component Interconnect (PCI) bus 444 , as defined by the PCI Local Bus Specification, Production Version, Revision 2.1 dated June 1995. I/O expansion bus 442 may be coupled to an I/O controller 446 that controls access to I/O device(s). These devices may include storage devices (e.g., disk drive 450 ) and input devices, such as a keyboard 452 and a mouse 454 . I/O hub 440 may also be coupled to, for example, a hard disk drive 458 and a compact disc (CD) drive 456 . Other storage media may be included in the system. PCI bus 444 may also be coupled to various components including, for example, a flash memory 460 . A wireless interface 462 may be coupled to PCI bus 444 , which may be used in certain embodiments to communicate wirelessly with remote devices. Wireless interface 462 may include a dipole or other antenna 463 (along with other components not shown). While such a wireless interface may vary in different embodiments, in certain embodiments the interface may be used to communicate via data packets with a wireless wide area network (WWAN), a wireless local area network (WLAN), a BLUETOOTH™, ultrawideband, a wireless personal area network (WPAN), or another wireless protocol. In various embodiments, wireless interface 462 may be coupled to system 400 , which may be a notebook or other personal computer, client, server, cellular phone, personal digital assistant (PDA) or the like, via an external add-in card or an embedded device. In other embodiments wireless interface 462 may be fully integrated into a chipset of system 400 . In one embodiment of the invention, a network controller (not shown) may be coupled to a network port (not shown) and the PCI bus 444 . Additional devices may be coupled to the I/O expansion bus 442 and the PCI bus 444 . Although the description makes reference to specific components of system 400 , it is contemplated that numerous modifications and variations of the described and illustrated embodiments may be possible. Embodiments may be implemented in code and may be stored on a storage medium having stored thereon instructions which can be used to program a system to perform the instructions. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.