Abstract:
One embodiment of the present invention provides a system that enables a background process to access encrypted data. During operation, the system executes the background process. Next, the system obtains a set of unencrypted keys by decrypting a set of encrypted keys with a server-key. The system then makes the set of unencrypted keys available to the background process, thereby enabling the background process to encrypt and decrypt data. Finally, the system deletes the set of unencrypted keys.

Description:
BACKGROUND  
       [0001]     1. Field of the Invention  
         [0002]     The present invention relates to computer security. More specifically, the present invention relates to a method and apparatus for securely executing a background process.  
         [0003]     2. Related Art  
         [0004]     To protect confidential information from getting into the wrong hands, users often employ cryptographic techniques when storing and/or transmitting the confidential information. When a user needs access to encrypted information, the user typically executes a method to decrypt the encrypted information. Executing this method often involves first performing a verification operation to ensure that the user has permission to access the encrypted information.  
         [0005]     In many cases, background processes also need to access encrypted information. Hence, a system that uses a background process which accesses encrypted information must find a secure way to give the background process access to the encrypted information. Previous techniques for enabling a background process to access encrypted information involve hard-coding passwords or cryptographic keys into the code which the background process executes. This can be extremely time-consuming for systems that support many background processes and many cryptographic keys. Furthermore, the security of the hard-coded cryptographic keys is only as great as the security of the storage medium containing the executable code for the background process.  
         [0006]     Hence, what is needed is a method for executing a background process without the problems listed above.  
       SUMMARY  
       [0007]     One embodiment of the present invention provides a system that enables a background process to access encrypted data. During operation, the system executes the background process. Next, the system obtains a set of unencrypted keys by decrypting a set of encrypted keys with a server-key. The system then makes the set of unencrypted keys available to the background process, thereby enabling the background process to encrypt and decrypt data. Finally, the system deletes the set of unencrypted keys.  
         [0008]     In a variation on this embodiment, prior to executing the background process, the system decrypts executable code for the background process with a public key associated with a user, wherein the executable code is encrypted with a corresponding private key associated with the user. Alternatively, the code may be signed instead of entirely encrypted with the user&#39;s private key. Next, the system verifies the integrity of the executable code, and if the executable code has been tampered with, the system prevents the execution of the background process.  
         [0009]     In a variation on this embodiment, decrypting the set of encrypted keys with the server-key further involves sending the set of encrypted keys to an external security module, wherein the external security module decrypts the set of encrypted keys to obtain the set of unencrypted keys. The system then receives the set of unencrypted keys from the external security module.  
         [0010]     In a variation on this embodiment, executable code for the background process includes meta-data, which specifies restrictions on the execution of the background process.  
         [0011]     In a further variation, before the system executes the background process, the system checks the meta-data to see if the meta-data specifies a restriction on the actions of the background process. If so, the system restricts the actions of the background process as is specified in the meta-data.  
         [0012]     In a further variation, the meta-data can specify: a data-set restriction, wherein the data-set restriction specifies the data the background process can access; an access-time restriction, wherein the access-time restriction specifies when the background process can access the data; an access-count restriction, wherein the access-count restriction specifies how many times the background process can access the data; and a command-restriction, wherein the command-restriction specifies what commands the background process can execute on the data.  
         [0013]     In a variation on this embodiment, the system creates the background process, and also encrypts the set of unencrypted keys with the server-key to create the set of encrypted keys.  
         [0014]     In a further variation, after encrypting the set of unencrypted keys with the server-key, the system sends the server-key to an external security module.  
         [0015]     In a further variation, after creating the background process, the system encrypts the background process with a private key associated with a user, or a symmetric key known to the server. Alternatively, the process can signed by the private key associated with a user.  
         [0016]     In a variation on this embodiment, the unencrypted set of cryptographic keys enables the background process to encrypt/decrypt data stored on a database.  
         [0017]     In a variation on this embodiment, the server-key is stored in an external security module coupled to the database.  
         [0018]     In a variation on this embodiment, each background process in a plurality of background processes is associated with the server-key.  
         [0019]     In a variation on this embodiment, each background process in a plurality of background processes is associated with different server-keys. 
     
    
     BRIEF DESCRIPTION OF THE FIGURES  
       [0020]      FIG. 1  illustrates a computing environment in accordance with an embodiment of the present invention.  
         [0021]      FIG. 2  presents a flowchart illustrating the process of executing a background process in accordance with an embodiment of the present invention.  
         [0022]      FIG. 3  presents a flowchart illustrating the process of verifying the integrity of executable code for a background process in accordance with an embodiment of the present invention.  
         [0023]      FIG. 4  presents a flowchart illustrating the process of restricting the actions of a background process in accordance with an embodiment of the present invention.  
         [0024]      FIG. 5  presents a flowchart illustrating the process of creating a background process in accordance with an embodiment of the present invention.  
     
    
     DETAILED DESCRIPTION  
       [0025]     The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.  
         [0026]     The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital versatile discs or digital video discs).  
         [0000]     Overview  
         [0027]     One embodiment of the present invention attempts to prevent the background process from exposing keys, passwords, or any other secrets. In addition, one embodiment of the present invention secures the executable code of the background process with a digital signature. This is to prevent a Trojan horse attack (the insertion of malicious software into legitimate source code).  
         [0028]     In one embodiment of the present invention, a user who has permission to access a set of cryptographic keys authorizes a background process to perform jobs requiring access to the set of cryptographic keys. In this embodiment, the user needs to have permission and capabilities to perform any action that the user asks the background process to perform. Furthermore, in order for the background process to perform the actions requested by the user, the user must make the necessary cryptographic keys available to the background process. To do so, the user encrypts the necessary cryptographic keys under another key called a “server-key”. In this embodiment, the background process can perform any action on behalf of the user and only the server-key needs protecting.  
         [0029]     In one embodiment of the present invention, a software security module or a hardware security module protects the server-key.  
         [0030]     In one embodiment of the present invention, the server-key can be a cryptographic key associated with a user who will present the cryptographic key at the time the background process executes.  
         [0031]     In one embodiment of the present invention, the user: encrypts the executable code of the background process; uses a keyed hash; signs the code; or performs any other integrity enforcing method known to those familiar in the art.  
         [0032]     In one embodiment of the present invention, the background process can be associated with meta-data, such as an expiration period beyond which the background process cannot use the cryptographic keys, an identifier for data the background process has permission to access, or how many times the background process can execute. In this embodiment, an integrity-checking mechanism protects the meta-data.  
         [0000]     Computing Environment  
         [0033]      FIG. 1  illustrates a computing environment  100  in accordance with an embodiment of the present invention. Computing environment  100  can generally include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance. Computing environment  100  includes client  110 , network  120 , server  130 , database  140 , external security module  150 , and background process  160 .  
         [0034]     Client  110  can generally include any node on a network including computational capability and including a mechanism for communicating across the network.  
         [0035]     Network  120  can generally include any type of wired or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment of the present invention, network  120  includes the Internet.  
         [0036]     Server  130  can generally include any computational node including a mechanism for servicing requests from a client for computational and/or data storage resources.  
         [0037]     Database  140  can generally include any type of system for storing data in non-volatile storage. This includes, but is not limited to, systems based upon magnetic, optical, and magneto-optical storage devices, as well as storage devices based on flash memory and/or battery-backed up memory.  
         [0038]     External security module  150  can generally include any physical or logical device created to be highly resistant to unauthorized access. A physical external security module (ESM) is referred to as a hardware security module (HSM). In an HSM, all sensitive data is stored in a separate physical storage device with its own access control policies. The physical storage device along with its software interfaces are usually certified or tested against both physical and software-based intrusion attempts. Note that a security officer can couple external security module  150  to database  140  (as illustrated), or to server  130 .  
         [0039]     Background process  160  can generally include any process that has the same or fewer rights and privileges as the user who created the process, but is capable of running without user interaction. Note that background process  160  can execute on any system including client  110 , server  130 , and database  140  (as illustrated). Background process  160  executes on a physical device, but background process  160  itself is not a separate physical entity.  
         [0040]     In one embodiment of the present invention, user  112  includes meta-data when writing the code for background process  160 . This meta-data can include restrictions on the execution of background process  160 . For example, the meta-data can restrict how often background process  160  executes, when background process  160  executes, what data background process  160  accesses, when background process  160  accesses the data, how often background process  160  accesses the data, and what commands background process  160  executes on the data. By including meta-data with the executable code for background process  160 , user  112  reduces the harm a malicious user or a malicious piece of software can cause by corrupting background process  160 .  
         [0041]     In one embodiment of the present invention, user  112  does not include cryptographic keys when writing the executable code for background process  160 . By not including cryptographic keys with the executable code for background process  160 , user  112  reduces the probability that a malicious user or a malicious piece of software is able to harness background process  160  to perform malicious actions on data background process  160  accesses.  
         [0042]     For example, suppose in one embodiment of the present invention that, background process  160  needs to access data stored on database  140 . In this case, background process  160  executes an API (application programmer interface) call which causes database  140  to send a set of encrypted keys to external security module  150 . External security module  150  decrypts the set of encrypted keys with a server-key associated with background process  160  to obtain a set of unencrypted keys and sends the set of unencrypted keys to database  140 . Background process  160  can then access the data using the set of unencrypted keys. Note that the server-key is associated with background process  160  because the server-key is associated with user  112 , the owner of background process  160 .  
         [0043]     In one embodiment of the present invention, database  140  possesses the server-key. In this embodiment, database  140  can decrypt the set of encrypted keys.  
         [0044]     In one embodiment of the present invention, the same server-key is associated with multiple background processes.  
         [0045]     In one embodiment of the present invention, a different server-key is associated with each background process. In this embodiment, possessing the server-key serves as an authenticator for the background process.  
         [0000]     Executing a Background Process  
         [0046]      FIG. 2  presents a flowchart illustrating the process of executing a background process in accordance with an embodiment of the present invention.  
         [0047]     In this embodiment, the process begins when database  140  verifies the integrity of the executable code for background process  160  (step  202 ). Verifying the integrity of the executable code helps ensure that a malicious user has not inserted code into the executable code. This step is optional as is illustrated by the broken lines surrounding step  202 .  
         [0048]     In one embodiment of the present invention, the process begins when database  140  restricts the actions of background process  160  (step  204 ). Restricting the actions of background process  160  helps limit the effect of code which may be inserted into the executable code for background process  160  by a malicious user. This step is optional as is illustrated by the broken lines surrounding step  204 .  
         [0049]     In one embodiment of the present invention, the process begins when database  140  executes background process  160  (step  206 ). Then database  140  decrypts a set of encrypted keys (step  208 ).  
         [0050]     In one embodiment of the present invention, database  140  sends the set of encrypted keys to external security module  150  which then decrypts the set of encrypted keys with the server-key associated with background process  160  to obtain a set of unencrypted keys. External security module  150  then sends the set of unencrypted keys to database  140 .  
         [0051]     Next, database  140  makes the set of unencrypted keys available to background process  160  (step  210 ). Note that the unencrypted set of cryptographic keys enable background process  160  to encrypt/decrypt data stored on database  140 .  
         [0052]     In one embodiment of the present invention, making the set of unencrypted keys available to background process  160  can involve storing the set of unencrypted keys in a memory space accessible to background process  160 , providing the keys to background process  160  via an API call, or using the set of unencrypted keys on behalf of background process  160  in response to commands background process  160  executes.  
         [0053]     After background process  160  has finished executing, database  140  then deletes the set of unencrypted keys (step  212 ).  
         [0054]     In one embodiment of the present invention, database  140  does not wait until the background process has finished executing to delete the set of unencrypted keys. In this embodiment, database  140  deletes the set of unencrypted keys after a specified period of time, after background process  160  executes a specific command, after receiving a command from user  112 , or after user  112  halts the execution of background process  160 . This embodiment helps reduce how long the set of unencrypted keys are exposed to a potential malicious user.  
         [0000]     Verifying the Background Process Code  
         [0055]      FIG. 3  presents a flowchart illustrating the process of verifying the integrity of executable code for a background process in accordance with an embodiment of the present invention. The process begins when database  140  decrypts the executable code for background process  160  (step  300 ). Next, database  140  verifies the integrity of the executable code of background process  160  (step  302 ). Note that verifying the integrity of the executable code of background process  160  can involve verifying the signature of a user who authenticated the background process, verifying the result of a hash function, verifying a checksum, or any other method of verifying the integrity of code known to those familiar in the art.  
         [0056]     Next, database  140  determines if a malicious user has tampered with the executable code of background process  160  (step  304 ). If so, database  140  prevents execution of background process  160  (step  306 ).  
         [0000]     Restricting the Background Process  
         [0057]      FIG. 4  presents a flowchart illustrating the process of restricting the actions of a background process in accordance with an embodiment of the present invention. The process begins when database  140  examines meta-data for background process  160  (step  400 ). Database  140  then determines if the meta-data includes restrictions on the actions of background process  160  (step  402 ). If so, database  140  restricts the actions of background process  160  as specified in the meta-data (step  404 ).  
         [0000]     Creating a Background Process  
         [0058]      FIG. 5  presents a flowchart illustrating the process of creating a background process in accordance with an embodiment of the present invention. The process begins when user  112  creates background process  160  (step  502 ). Next, user  112  includes meta-data with background process  160  (step  504 ). This meta-data specifies restrictions on the execution of background process  160  and on the data background process  160  accesses. Including meta-data with background process  160  is advantageous because the meta-data reduces the harm a malicious user can cause if the malicious user was able to insert malicious code into background process  160 . This step is optional as is illustrated by the broken lines surrounding step  504 .  
         [0059]     Next, user  112  encrypts a set of unencrypted keys with a server-key (step  506 ).  
         [0060]     In one embodiment of the present invention, user  112  sends the server-key to external security module  150  (step  508 ). In this embodiment, database  140  must communicate with external security module  150  to decrypt the set of encrypted keys. This step is optional as is illustrated by the broken lines surrounding step  508 .  
         [0061]     In one embodiment of the present invention, user  112  encrypts background process  160  with a private key associated with user  112  (step  510 ). In this embodiment database  140  verifies the integrity of background process  160  before executing background process  160 . This is advantageous because encrypting background process  160  prevents a malicious user from inserting malicious code into the executable code for background process  160 . This step is optional as is illustrated by the broken lines surrounding step  510 .  
         [0062]     In one embodiment of the present invention, user  112  computes a hash value of the executable code for background process  160  to ensure the integrity of background process  160 .  
         [0063]     In one embodiment of the present invention, user  112  signs the background process to ensure the integrity of background process  160 . In this embodiment, database  160  verifies that user  112  signed the background process prior to executing background process  160 .  
         [0064]     The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.