Support for secure objects in a computer system

The present invention generally relates to protecting data and software in a computer system from various forms of attack, including protection against attacks from other software in the computer system. More specifically, in one exemplary embodiment, two new machine instructions control encryption / decryption, and the sensitive software and data in the "safety object" are used by these sensitive software and data inside the CPU. It provides a mechanism to ensure that it is always encrypted except during the period it is.

The Internet is a powerful tool that has changed the world. As Lu Garsner, former chairman and CEO of IBM (a registered trademark of IBM), said, "The Internet is the only one we have ever experienced to drive business, economic and social change. It's the strongest tool. "

But like many tools, this tool can be both good and bad. Every week, we hear of Internet-based attacks where systems are compromised and sensitive information is stolen.

Some of the recent news is: UK MI5: Top Company Targeted by China's Cyber Attack, The Times (London), December 3, 2007, Massive data leakage by illegal software: A malicious computer program secretly installed on the server of Hanaford Brothers Supermarket leaked 4.2 million debit and credit card information, AP 2008 March 28, 2014 Russian misconduct group hijacks PC with large-scale scheme, New York Times, August 6, 2008, 8 million people are at risk of ID fraud due to the theft of credit card statements by hotel chain hackers, (UK) Daily Mail, August 25, 2008, New York Mellon Bank data breach now affects 12.5 million, Reuters, August 28, 2008, and U.S. authorities accused 11 people in five countries of stealing tens of millions of credit and debit card numbers from several retailers, including TJX Companies, Reuters, August 28, 2008. (Quoted from the New York Bank article above).

There are many other similar cases.

<p num="0006"> In this way, software that helps prevent information theft from a computer system by an internet-based attack and allows an attacker to capture sensitive data and software in the computer system into the target computer system. There is a need for systems and methods that can be protected from other software, including.</p>

<p num="0007"> Typical features of the present invention, in view of the above and other typical problems, drawbacks, and disadvantages of conventional systems, protect the computer system from other software in the computer system by cryptography. It is to provide a processor that includes a mechanism for supporting safety objects, including code and data.</p><p num="0008"> Another typical feature of the present invention is a structure for maintaining at least one of the data and code as a cryptographically protected portion of the secure object, except when the secure object is actually being processed in the CPU. And to provide a method.</p><p num="0009"> Another typical feature of the present invention is the cryptographic engine and the machine instructions to load the key into the cryptographic engine for decrypting the secure object as it enters the CPU for processing the secure object. It is to provide a mechanism to include.</p><p num="0010"> Accordingly, in the first exemplary embodiment of the specification, a processor in a computer system incorporating a mechanism that supports secure objects containing code and data protected from other software in the computer system by cryptography. Will be described.</p><p num="0011"> Also included in the second exemplary embodiment of the present specification is a cryptographic engine for providing access to the secure object and an instruction to load the key into the cryptographic engine while the code for the secure object is running on the processor. The mechanism to do this will be explained.</p><p num="0012"> Further, in the third embodiment of the present specification, a method of protecting private information and a storage medium for storing a machine-readable instruction for executing the method will be described.</p><p num="0013"> In addition, a fourth exemplary embodiment of the specification describes a data structure tangibly embodied in a machine-readable storage medium that is cryptographically protected from other software in a computer system.</p><p num="0014"> Further, in a fifth exemplary embodiment of the specification, machine instructions are described that provide a mechanism to support secure objects containing code and data protected from other software in a computer system by cryptography.</p><p num="0015"> Therefore, the present invention is always cryptographically protected, except while the private data of the data structure is being processed in the CPU in the computer system, thereby, against the private data, the computer system. It provides new machine instructions and data structures that provide protection from other software inside.</p><p num="0016"> The aforementioned and other objectives, embodiments and advantages will be better understood below by elaborating on an exemplary embodiment of the invention with reference to the drawings.</p>

<figref num="1">Shown is a high-level language description of a secure object 100 that contains code and data that is cryptographically protected from other software.</figref><figref num="2">An example of a low-level implementation 200 (eg, compiled version) of a safety object.</figref><figref num="3">FIG. 300 shows an exemplary block diagram 300 of a microprocessor that provides support for safety objects.</figref><figref num="4">The esm instruction format 400 used to implement a safety object is shown.</figref><figref num="5">The handle of the esm instruction is decrypted in order to illustrate the concept 500 of the second exemplary embodiment and find the encryption / decryption key.</figref><figref num="6">A process 600 for constructing an executable file containing a safety object is shown for the first exemplary embodiment.</figref><figref num="7">A second exemplary embodiment shows another process 700 of constructing an executable file containing safety objects that can be used.</figref><figref num="8">Indicates how a safety object calls or sends a message to another object.</figref><figref num="9">An exemplary hardware / information processing system 900 for incorporating the present invention is shown.</figref><figref num="10">A signal-carrying storage medium 1000 (eg, storage medium) for storing the steps of the program of the method according to the invention is shown.</figref>

Hereinafter, exemplary embodiments of the method and structure according to the invention will be described with reference to the drawings.

The present invention provides a mechanism for implementing a novel construct "safety object" that provides strong defense against software attacks. This safe object, like objects in other object-oriented programming languages, contains data and code that manipulates the data and provides access to it. Security objects exist in existing programming languages such as Java in that the security object's private code and data are cryptographically protected so that no other software can access the security object's private information. Different from the object to do.

FIG. 1 presents an example of what the safety object 100 might look like in a high-level programming language. The safety object includes private data 101 and private methods 102, as well as methods that allow access to the safety object via its public interfaces 103, 105 . Other software can use safety objects (ie, other software can "call" or "send messages" to safety objects), while other software has a public interface. Safe objects can only be accessed via 103, 105.

In secure object-based systems, private information is almost always encrypted. It is encrypted both in the paging system and in the file system while in memory and on disk.

FIG. 2 shows what a compiled version 200 of a safe object can look like in memory.

The private information of a secure object is "unencrypted" only when: When accessed from inside the safety object Only while the information is inside the microprocessor.

Other code does not have access to the secure object's private information, so a software attack that enters the system through a vulnerability in another software module can encrypt the secure object's private information. Has no means of access to versions that are not. As shown in FIG. 2, the encrypted private information can include a private code and private data, which correspond to the private code 102 and the private data 101 of FIG. ..

In an exemplary embodiment used to illustrate the concepts of the invention, the novel design is used to enter and exit public methods of safety objects, "entering safety methods" and It includes two new instructions, "esm" and "lsm", respectively, corresponding to "leave secure methods".

The esm instruction loads some cryptographic key information into a special register used to decrypt the private code and data of the secure object as it moves from memory into the microprocessor. Other data passed to this method, such as arguments, and the return address saved when the safe object is called are accessed without this encryption.

FIG. 3 is a block diagram 300 of microprocessor 301 that provides support for safety objects. This microprocessor executes code in much the same way as a commonly used microprocessor today, but (1) decrypts sensitive information as it is moved from external memory 303 into the L1 cache 304. (2) Includes a cryptographic engine 302 for encrypting confidential information when it is moved from the L1 cache 304 to the external memory 303. This encryption is used to ensure that other software, including viruses, worms, and other "attack software," cannot obtain an unencrypted version of sensitive information.

FIG. 3 also shows a block 305 in the cryptographic engine labeled as a "key" that holds the keys used in the encryption and decryption process. This key block could contain a set of cryptographic registers specially specified to hold these keys. The cryptographic engine 302 may be a coprocessor associated with the processor 307, or the cryptographic engine may be a function executed by the CPU processor itself.

The lsm instruction can consist only of the opcode, which restores the previous state of the special cryptographic register 305, so that when returned to the secure method, the normal insecure code is executed without this encryption and decryption. it can.

In this secure object system, the key 305 used to decrypt the secure object's private information is available for the secure object, but no other code can use these keys.

As illustrated in FIG. 4, the esm instruction 400 puts a key in an opcode field 401 and a special cryptographic key register in key block 305 to provide access to the object's private data. It has an operand field 402, called the "handle" of the opcode field 401, which is used to load. However, the key used to decrypt the private information of the "object" must not be available to any other code, so the handle provides an indirect reference to the cryptographic key information that cannot be used by other software. This process will be described in more detail later.

Inside the secure object, the private information is decrypted on the path from memory 303 to CPU 307 and encrypted on the path from CPU 307 to memory 303. This cryptography includes the integrity of the private code and data of secure objects and the cryptographic integrity value to protect their confidentiality. Thus, when hostile software, or a software bug, or a software attack from another software module "tampers" an object's private code or data, the object then accesses that code or data. When doing so, the cryptographic hardware will generate a cryptographic integrity exception.

In contrast, when a secure object updates its private data 101, the "object" key is used to update its cryptographic integrity value, and when the "object" later accesses this data, the integrity. No exception is raised. Cryptographic and decryption processes, including cryptographic integrity protection, could be performed as described in the concurrent pending applications identified above.

This integrity protection is also essential to protect the keys that provide access to the object's private information. When hostile software attempts to use the safe object's handle (which can be used in the safe object's esm instruction) with some other code, the use of this "other" code generates a cryptographic complete exception. , The execution will be terminated. Since the key is not available to the hostile software, the hostile software cannot generate code that passes the cryptographic integrity check when the key is used. And since the hostile software has no way to get or use the key other than through the handle, the hostile software has no way to gain access to the key or private information of the safety object.

In one exemplary implementation, cryptographic key information and handle-to-key mappings are stored in protected area 306, which is inaccessible to software. In this implementation, when the CPU executes an esm instruction, the CPU gets a handle from the esm instruction, maps that handle to cryptographic key information, and then puts this cryptographic key information in a special cryptographic register in key block 305. Load.

In the second exemplary implementation 500 shown in FIG. 5, the handle is designed in such a way as to eliminate the need to store the encryption key information of the object. In this design, the handle is an encrypted form of the key information of the secure object, which is encrypted under a special "system key" that is not available to the software. In this design, in executing the esm instruction, the CPU decrypts the handle using the system key to obtain the key information of the object, and then loads the key information of the object into the encryption register to make the object private. Provide access to information. This system key must be further protected, but this design is more extensible because it does not need to store a large number of object keys and handle-to-object key mappings. Is high.

Details on one method of implementing this encryption, decryption, and integrity checking are given in the co-pending application identified above.

6 and 7 illustrate the process of constructing an executable file with safety objects for the two implementations described above.

FIG. 6 shows process 600 building an executable file for the first exemplary implementation. In addition to the normal compiler processing 601 in step 602, the compiler will generate esm and lsm instructions at the entry point and the return point of the safety object to the public method. Subsequent additional processing, as shown in FIG. Associate the esm instruction for a given object with a handle (step 603), Link the handle of the object to cryptographic key information to protect confidentiality and integrity (step 604). Encrypt the private code and data of each object using the key information of that object (step 605), and The key information and the handle-to-key mapping are stored in a "protected area" that is not accessible to most software but is used in the execution of the esm instruction (step 606). It will be.

FIG. 7 shows process 700 building an executable file for the second exemplary implementation. As in the previous case, normal compiler processing is done in step 701, and in step 702 the compiler generates esm and lsm instructions at the entry and return points of the safety object to the public method. It will be. However, the additional processing in this case is Generate encryption key information for each secure object (step 703), Encrypt the private code and data of each object using the encryption key information of that object (step 704). Encrypt the encryption key information of each object using a special "system key" (step 705), and The encryption form of the key information of each object is used as a handle in the esm command of the object (step 705). It will be.

This additional processing will be done in a small, carefully scrutinized and reliable program.

In the second implementation, this additional processing does not need to be performed on the system on which the executable file is operated. The additional processing may be performed on another creation machine, and then sent to the desired destination machine for execution.

When this process is complete, the safe object in the executable is "safe". They are protected from bugs in other software modules, including bugs in privileged software such as device drivers, operating systems, and hypervisors, or attacks from them. In the second implementation above, these objects are protected while they are "in transit" from the creating machine to the desired destination machine.

This design makes it possible to know that the content of a given safe object is indeed secure, without having to prove the accuracy of millions of lines of OS, middleware, and application code. This design only needs to prove the accuracy of the safety object mechanism described above and the design accuracy of a particular safety object.

[Use of safety objects] Safety objects could be used to avoid the types of security breaches described in the "Background Technology" section above. Had the confidential information been stored in a secure object, for example, the theft of 4.2 million credit and debit cards could have been avoided. No software other than the safety object itself will have a complete list available, careful design, keeping the "object" code as small as possible, and carefully scrutinizing the "object" code for software vulnerabilities. By doing so, the problem of software attacks on the code of safety objects could be minimized or avoided. As mentioned earlier, you don't have to prove the accuracy of millions of lines of application and system code, you just need to prove the accuracy of safety objects.

In addition to protecting the "objects" themselves, they also protect the routes of entry and exit to safe objects, where software attacks "eaves" these routes and collect large amounts of sensitive information over time. You also need to make it impossible.

These routes can be protected by standard communication security mechanisms. In a "good" design, sensitive information is never vulnerable. Sensitive information sent to a secure object will be protected by a communication security mechanism until it is safely inside the secure object. Similarly, sensitive information sent by a secure object will be protected by a communication security mechanism before it leaves the secure object.

With this type of design, attack software would not be able to obtain any sensitive information from the system. Attack software will not be able to obtain sensitive information that resides within the secure object, and will not be able to steal sensitive information when it is sent to or will be received by the secure object.

[Object that calls another object] Safe objects can call (or send messages to) other objects. That is, the safe object can use both a safe object and an unsafe object. An example of this is illustrated in Process 800, which is exemplified in FIG.

In this example, the ProcessCardRequest 801 is a secure object that contains sensitive credit card information. The ProcessCardRequest 801 calls another secure object, EncryptAndDecrypt (encryption and decryption) 802, to encrypt sensitive information transmitted to the remote system. The ProcessCardRequest 801 then calls the ordinary unsafe object SendandReceiveMsg (message transmission / reception) 803 to send an already encrypted message for transmission to a remote system.

It should be noted that the object that encrypts and decrypts the confidential information must be a secure object because it needs to access the confidential information in the "unencrypted state". On the other hand, an object that sends a message to a remote system is a normal insecure object if the data it receives for transmission is already encrypted for protection during "in transit" between systems. can do. Also note that if a secure object calls another object, the cryptographic key information must be set up properly for the called object.

This example shows another aspect of the safety object. As mentioned earlier, the private information in the secure object is almost always encrypted. On the other hand, the public information in the secure object is not encrypted, that is, it is not encrypted under the secure object cryptography. If the ProcessCardRequest class has a public field for storing encrypted messages that will be passed to a remote system, that field can be passed to an unsecured SendandReceiveMsg object, which is described by the secure object's cryptography. Since it is not "disturbed", the SendandReceiveMsg object will see the same message that the ProcessCardRequest sees.

Confidential information is not vulnerable in this design. It is always protected by either secure object cryptography or communication cryptography.

Additional details Interrupts and process dispatching When an interrupt is made to a secure object, the state of the special cryptographic hardware that provides access to the secure object's private information must be preserved. Then, when the safety object resumes execution later, its state must be restored. Access to the "object" key by device drivers, or process dispatching code or other operating system level code, is not desirable as it can jeopardize the security of the "object". , Interrupt handlers and OS-level code will save and restore handles rather than keys, and loading handles into handle registers will load the appropriate key information into the cryptographic hardware. .. The current state of the crypto handle is only another element of the "process context" that must be saved and restored when a process is suspended and resumed.

Swapping, paging, and executable files in the file system When a process is in memory, the private information in its secure object is encrypted as described above, and the rest of the code and data is in an unencrypted state. When swapped or paged out to disk, the process image has the same shape, i.e. the secure object is encrypted and there is no residual code and data. Therefore, safe objects are also safe when swapped or paged without any special action in the swapping or paging system.

As mentioned above, encryption, decryption, and integrity protection could be performed as described in the co-pending application identified above. However, in this case, the addresses used in encryption, decryption, and integrity checks can change because the physical addresses of the code and data can change when the process or part of the process is swapped or paged to disk. It is based on virtual addresses rather than physical addresses.

The executable in the file system has the same protection as when it is in memory, the private information in the secure object is encrypted, and the rest of the executable is not. If the file is brought into memory to spawn a new process, no special action is required.

Passing arguments and return values When one object calls another, the arguments and return values usually have to be "understandable" for both objects, and in some cases cryptographic conversion of these values may be required. is there. There are several cases to consider. 1. 1. An ordinary unsafe object calls another ordinary unsafe object. The arguments and return values are "unencrypted" on both the calling and called objects. No conversion required. 2. A safe object calls an unsafe object. In this case, the fields in the safe object used to pass arguments to or receive a return value from that unsafe object should be public. (If the information is exposed in an unsecured object, there is no point in making it private in the secure object.) These fields will be in "unencrypted state" and therefore conversion is required. Absent. 3. 3. An unsafe object calls a safe object. In this case, the fields in the safety object used for the passed arguments and the return value should be public. These fields will be in "unencrypted state" and therefore no conversion is required. 4. A safety object calls another safety object. In this case, the private information passed in this call must be decrypted using the key of the calling object and re-encrypted using the key of the called object. This can be done in the esm instruction. Similarly, when a return value is passed to a private field in the calling object, that information must be decrypted using the called object's key and re-encrypted using the calling object's key. This can be done in the lsm instruction.

File system I / O The secure object should also have the ability to store and retrieve private information in the file system. And this private information must remain private while in the file system. This can be done by calling a safety object from the file system to perform a safe read and a safe write to it. In addition to the file descriptor, buffer, and buffer arguments, the file system has private information that is written to the file, for example, by receiving an argument or set of arguments for cryptographic key information by the SecureWrite method. In the meantime, it will be protected by cryptography and its confidentiality and completeness will be protected. Similarly, the SecureRead method can take an argument or set of arguments to the cryptographic key information and read it this way to validate the integrity of the private information read from the file system. Yeah. (This cryptographic key information could be stored in a private field or group of fields in a secure object that calls the SecureWrite and SecureRead methods.) The SecureRead and SecureWrite are "standard" for the actual file system I / O. Read and write system calls could be used to perform all required cryptographic encryption, decryption, and integrity checks. (The "address" used for encryption and decryption in the file system I / O could be a few bytes at the beginning of the file.)

cache Also, the private information of the secure object needs to be protected if it appears to be "unencrypted" in the L1, L2, and L3 caches. In one implementation, as shown in FIG. 3, encryption and decryption are performed between the L1 cache and the L2 cache. In this design, the private information in the L2 or L3 cache is cryptographically protected as if it were in external memory. In this design, the private information is unencrypted in the L1 cache, so it is necessary to ensure that this plaintext private information is not available to any other software.

If the safety object is interrupted, or if the safety object makes a call to code outside the safety object, one possible way is to execute the lsm instruction only in the L1 cache (or an entry that contains private information in the L1 cache). ) Is cleared. In one multi-core design, the L1 cache (or cache group) for a given CPU core is not available to other CPU cores.

In another design, encryption and decryption is done between the CPU core and the L1 cache. In this case, the private information in L1 is encrypted and protected as if it were in external memory, but encrypted / decrypted whenever the private information is loaded from or stored in the L1 cache. Will have to be done.

Another design could include an additional "L0.5" cache between the L1 cache and the CPU. In this design, the L1, L2, and L3 caches all contain encrypted forms of private information, and L0.5 is used for the unencrypted form of private information in the execution of secure objects. Will provide an additional level of cache that will be used for. The contents of this L0.5 cache will be cleared when returning to the safe method, when an interrupt occurs, and when the safe method calls code outside the safe object.

Safety process As mentioned above, safety objects can be used at the process level to protect all of the process's private information for its entire lifetime, including private information that the safety object stores in or retrieves from the file system. it can. The esm instruction will set up cryptographic protection at the beginning of execution, which will be used for the life of the process. As mentioned earlier, when a process makes a call to external code, such as an operating system call, the external code is executed without accessing the key of the safe object.

[wrap up] We have described new approaches to providing strong defenses against software-based attacks. This approach is based on a new construct, a safety object, which ensures that private information is private. The private information of a safe object is protected throughout its life cycle, whether it is in memory, paged out to disk, or written to the file system. Private information is protected by cryptography from device drivers, operating systems, and other software, including privileged software such as hypervisors. This cryptography prevents other software from retrieving private information or modifying it undetected.

The ability of secure objects allows us to prove that sensitive information is indeed secure without having to prove the accuracy of millions of lines of operating system, middleware, and application code. It is only necessary to prove the accuracy of the mechanism for the implementation of the safety object and the accuracy of the design of a given safety object.

Safety object functionality can be added to the processor in a "backward compatible" way. All existing code can be continuously executed without modification and without any performance disadvantages. Nevertheless, writing new code that leverages the security object feature can provide much stronger security for sensitive information.

[Typical hardware implementation] As mentioned above, the microprocessor shown in FIG. 3 has been improved by incorporating two new instructions, esm and lsm, and a cryptographic register and a cryptographic engine that includes the ability to clear these registers under the circumstances described above. Also behaves much like a traditional microprocessor.

FIG. 9 shows a typical hardware configuration of an information processing / computer system according to the present invention, which is preferably at least one processor or central processing unit implemented to execute esm and lsm instructions, respectively. It has a device (CPU: central processing unit) 910.

The CPU 910 may include a random access memory (RAM: random access memory) 914, a read-only memory (ROM: read-only memory) 916, (disk unit 921 and tape drive 940, etc.) via the system bus 912. Input / output (I / O: input / output) adapters 918 (for connecting peripheral devices to bus 912), keyboards 924, mice 926, speakers 928, microphones 932, or other user interface devices or theirs. User interface adapter 922 for connecting combinations to bus 912, communication adapter for connecting information processing systems to data processing networks, the Internet, intranets, personal area networks (PANs), etc. The 934 and the bus 912 are interconnected to a display adapter 936 for connecting to a display device 938 and / or a printer 939 (such as a digital printer).

In addition to the hardware / software environment described above, another aspect of the invention includes a computer-implemented method for performing the above method. As an example, this method can be implemented in the specific environment described above.

Such a method can be carried out, for example, by operating a computer and embodying it with a digital data processing device to execute a sequence of machine-readable instructions. These instructions can be contained in various types of signal-carrying storage media.

Thus, this aspect of the invention tangibly embodies a machine-readable instruction program that can be executed by the digital data processing apparatus incorporating the CPU 910 and hardware to carry out the method of the invention. It is aimed at program products including storage media.

The signal-supporting storage medium may include a RAM built into the CPU 910, for example, as represented by a high-speed access storage device. Alternatively, these instructions can be included in another signal-carrying storage medium, such as the magnetic data storage diskette 1000 (FIG. 10), which the CPU 910 can directly or indirectly access.

Whether contained in a diskette 1000, in a computer / CPU 910, or in another medium, these instructions (eg, conventional "hard drive" or DASD storage devices (such as RAID arrays), magnetic tapes, electronic read-only memories (eg, ROM, EPROM, or EEPROM), optical storage devices (eg, CD-ROM, WORM, DVD, digital optical tape, etc.), Used in paper punch cards or transmission media such as communication links or radios that incorporate storage devices for storing instructions in various formats, such as digital or analog, that may be used to transmit computer instructions. It can be stored on a variety of machine-readable data storage media, such as other suitable signal-carrying storage media, including devices and memory. In certain exemplary embodiments of the invention, machine-readable instructions can include software object code.

Although the present invention has been described in the context of an exemplary embodiment, those skilled in the art will recognize that it is possible to practice the present invention using modifications within the spirit and scope of the appended claims. ..

Furthermore, it should be noted that Applicant's intent is to cover the equivalent of all claim elements, even if modified during subsequent procedural processing.