Protection of application secrets

FIELD OF THE INVENTION

[0001] The invention relates generally to computer systems. More specifically, the invention relates to protecting information critical to an application's functionality by encrypting data based on machine-specific entropy and application-specific evidence, and securely communicating the protected information from one code component to another.

BACKGROUND OF THE INVENTION

[0002] The rapid emergence of Internet applications based on multi-tier architectures with componentized code has created a need for heightened computer security. That is, software applications are no longer stored in and executed from a single monolithic file. Instead, applications are created from multiple components, potentially running on multiple machines, and delivered and executed across multiple networks. As computer systems increasingly rely on these distributed system and network architectures, computer software must increasingly protect secrets critical to the application's functionality, including cryptographic keying material, passwords, and message digests (or hashes) used to verify the integrity and authenticity of one piece of computer software to another.

[0003] For example, with reference to FIG. 3, a server <b>301</b> running internet web server software (e.g., Internet Information Server) communicates with local client machines <b>303</b>-<b>309</b>, each running a web browser (e.g., Microsoft Internet Explorer®). In many cases the client needs to know it is talking with the right web server before providing payment information for an electronic purchase. Typically, this is handled by creating a secure SSL communications channel with server authentication. This creates a problem for the developer of the Internet web server software. SSL authentication requires storage of a private cryptographic key for this purpose, along with a public server X509 certificate. This private key needs to be kept hidden and only made available for use in Internet web service authentication. If a hostile entity can compromise this key, they can impersonate the service and potentially cause significant harm to the clients and to the service owner's business. However, current operating systems and virtual machine environments do not support hiding such secrets such that only a single application can use them. The result is that each application developer must come up with his or her own approach to hiding such secrets or accept a potentially serious risk that must be mitigated using deployment and administrative procedures.

[0004] Known solutions to protecting application secrets have focused on protection of persistent data on a per-machine or per-account basis, and isolating runtime information and code at the process level. These solutions typically encrypt an application's secrets using a unique machine key protected by the operating system, or a user-specific key derived from the authentication credentials of each user. In the first case, any application code running on the machine can access the secrets; in the latter any application code running on behalf of the user can access the secrets. If an application has secrets that it truly needs to protect from other application code, it is necessary to implement some private method of hiding such secrets. Approaches that have been used include use of a password derived cryptographic key to encrypt the secrets, scatter-gather algorithms to try and hide such secrets in the application, and use of algorithmic approaches to materializing the secret value when needed. The first method is often impractical as it requires an authorized user be present to enter the password when the secrets are needed. The last approach often results in weak protection as such algorithms are difficult to design and implement in ways that are not trivially attacked.

[0005] The difficulty of attacking a secret hiding algorithm is generally determined by the difficulty level of reverse engineering the algorithm used. Design of these algorithms, such that they are not easily reverse engineered, is difficult as the hacker has complete access to the application code. If a hacker can determine how such an algorithm works, then the secrets can be easily retrieved by hostile code. Such code also impacts the application developer in that it requires additional development and debugging time impacting the overall cost in creating the application.

[0006] Previous solutions also do not provide a mechanism by which trusted code components can securely share information when they are running inside the same process space with less trusted code components.

[0007] Because of the aforementioned difficulties, typically only large developers of high-end services such as Web servers (e.g., IIS), mail servers (e.g., Exchange), or authentication servers (e.g., Kerberos KDC) have been able to expend the resources to develop proprietary solutions based on careful design considerations, after substantial development time, and having undergone rigorous testing to avoid unintentional security breaches. Such solutions are often cost prohibitive for software developers with more modest budgets, causing smaller developers to use less secure methods for protecting application secrets. However, software developers of all sizes require the protection of application secrets to meet their customers' needs.

[0008] There are many known examples of solutions used by smaller developers including: storing application secrets (e.g., login/password pairs) as encrypted strings in data files, typically offering minimal security; storing application secrets as clear-text strings in resource or configuration data, which provides virtually no security; and simplistic algorithms that simply write the secret into the application code's data areas at some reserved offset. These known solutions do not provide a general solution that developers can use to manage application secrets with robust security.

[0009] Thus, it would be an advancement in the art to be able to more effectively protect critical application secrets in a form that prevents disclosure to potentially hostile code on the same machine, while allowing easy retrieval by the owning application. It would also be an advancement in the art to make such a solution available for arbitrary applications to use through a well-known application program interface (API). It would be a further advancement in the art to be able to protect an application secret when sending the secret to another trusted application, without allowing untrusted applications or malicious code to also access the secret.

BRIEF SUMMARY OF THE INVENTION

[0010] Aspects of the invention overcome the problems of the prior art discussed above by using a novel combination of encrypted stores, hidden keys, trusted application evidence, and machine-specific entropy to protect application secrets. A runtime environment may use verifiable runtime information as evidence to authenticate code components, and also use the evidence in combination with the machine specific entropy to derive application specific cryptographic keys used to encrypt and decrypt data. Using application-specific encryption, the invention ensures that only the owning application can retrieve its own stored secrets.

[0011] Some aspects of the invention generate a cryptographic key based on machine-specific entropy in combination with trusted evidence associated with a requesting application and, using the generated key, encrypt data received from the requesting application.

[0012] Some aspects of the invention generate a cryptographic key based on machine-specific entropy in combination with evidence associated with a requesting application and, using the generated key, attempt to decrypt previously encrypted.

[0013] Some aspects of the invention enable communication of application secrets from one code component to another. A secret manager module creates an object that stores evidence associated with an application secret owner that desires to send an application secret to another code component, data encrypted using a key based on machine-specific entropy and trusted evidence associated with the sending application, and evidence associated with an intended recipient code component. The secret manager module returns to the sending application a reference to the newly created object, which the sending application can send to the recipient code component. The recipient code then requests the secret from the secret manager module, passing it a reference to the object. When the requesting code component's evidence matches the intended recipient's evidence, the secret manager module decrypts the data and sends the decrypted data to the receiving code component.

[0014] Some aspects of the invention provide a data structure for storing an object used to send an application secret from one code component to another code component. The data structure has a first portion for storing data encrypted using a symmetric cipher algorithm, based on a key generated from machine-specific entropy and trusted evidence associated with the application secret's owner. The data structure has a second portion for storing the trusted evidence associated with the application secret's owner. The data structure has a third portion for storing trusted evidence associated with an intended recipient of the application secret.

[0015] Some aspects of the invention provide a computer system that stores and manages application secrets. The computer has in memory one or more code components that execute in a runtime environment, and hidden machine-specific entropy. The computer has a secret store component (SSC) that receives from one of the code components a request to securely store its data, retrieves from an evidence provider trusted evidence associated with the requesting code component, and encrypts the received data based on the evidence and the entropy.

[0016] Some aspects of the invention provide an application program interface (API) through which applications can interact with a secret store component (SSC) to securely store and manage application secrets. The API has a first function call for storing application secrets. The first function accepts application data, and encrypts and stores the application data. The encryption is based on machine-specific entropy and evidence corresponding to a code component calling the first function. The API has a second function call for retrieving previously stored application secrets. The second function accepts a reference to previously stored encrypted data, and decrypts previously stored encrypted data corresponding to the reference. The decryption is based on the machine-specific entropy and evidence associated with the requesting code component. The API has a third function call for communicating an application secret from one code component to another code component. The third function accepts a reference to previously stored encrypted data and evidence corresponding to an intended recipient code component. The third function creates a data transfer object including the encrypted secret, the secret owner's evidence, and the intended recipient's evidence, and returns to the requesting code component a reference to the object.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0017[0017] The foregoing summary, as well as the following detailed description, may be better understood when read in conjunction with the accompanying drawings, in which like reference numerals identify like elements, and which are included by way of example, and not by way of limitation with regard to the claimed invention.

P-0018[0018]FIG. 1 illustrates a schematic diagram of an exemplary general-purpose digital computing environment that may be used to implement various aspects of the present invention.

P-0019[0019]FIG. 2 illustrates a block diagram of a computer readable medium according to one or more aspects of the invention.

P-0020[0020]FIG. 3 illustrates a client-server architecture that benefits from the present invention.

P-0021[0021]FIG. 4 illustrates a data flow diagram for one or more aspects of the invention.

P-0022[0022]FIG. 5 illustrates a method for protecting application secrets according to one or more aspects of the invention.

P-0023[0023]FIG. 6 illustrates a method for retrieving protected application secrets according to one or more aspects of the invention.

P-0024[0024]FIG. 7 illustrates a method and data flow for transferring a protected secret from one code component to another according to one or more aspects of the invention.

DETAILED DESCRIPTION OF THE INVENTION

P-0025[0025] Aspects of the present invention use a combination of machine-specific entropy and application-specific evidence to securely manage and communicate critical application information stored in an encrypted data store. One or more aspects of the invention are applicable to any general purpose computing platform capable of running a variety of operating systems, virtual machines; and applications, including PCs running WINDOWS®, LINUX®, MacOS®, or SOLARIS® brand operating systems and the like, as well as PDA devices, Tablet PCs, pen-based computers, and other data processing systems. FIG. 1 illustrates a schematic diagram of an exemplary conventional general-purpose digital computing environment that may be used to implement various aspects of the present invention. In FIG. 1, a computer <b>100</b> includes a processing unit <b>110</b>, a system memory <b>120</b>, and a system bus <b>130</b> that couples various system components including the system memory to the processing unit <b>110</b>. The system bus <b>130</b> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory <b>120</b> includes read only memory (ROM) <b>140</b> and random access memory (RAM) <b>150</b>.

P-0026[0026] A basic input/output system <b>160</b> (BIOS), containing the basic routines that help to transfer information between elements within the computer <b>100</b>, such as during start-up, is stored in the ROM <b>140</b>. The computer <b>100</b> also includes a hard disk drive <b>170</b> for reading from and writing to a hard disk (not shown), a magnetic disk drive <b>180</b> for reading from or writing to a removable magnetic disk <b>190</b>, and an optical disk drive <b>191</b> for reading from or writing to a removable optical disk <b>192</b>, such as a CD ROM or other optical media. The hard disk drive <b>170</b>, magnetic disk drive <b>180</b>, and optical disk drive <b>191</b> are connected to the system bus <b>130</b> by a hard disk drive interface <b>192</b>, a magnetic disk drive interface <b>193</b>, and an optical disk drive interface <b>194</b>, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules, and other data for the personal computer <b>100</b>. It will be appreciated by those skilled in the art that other types of computer readable media that may store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the example operating environment.

P-0027[0027] A number of program modules may be stored on the hard disk drive <b>170</b>, magnetic disk <b>190</b>, optical disk <b>192</b>, ROM <b>140</b>, or RAM <b>150</b>, including an operating system <b>195</b>, one or more application programs <b>196</b>, other program modules <b>197</b>, and program data <b>198</b>. A user may enter commands and information into the computer <b>100</b> through input devices, such as a keyboard <b>101</b> and a pointing device <b>102</b>. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices often are connected to the processing unit <b>110</b> through a serial port interface <b>106</b> that is coupled to the system bus <b>130</b>, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB). Further still, these devices may be coupled directly to the system bus <b>130</b> via an appropriate interface (not shown). A monitor <b>107</b> or other type of display device is also connected to the system bus <b>130</b> via an interface, such as a video adapter <b>108</b>. In addition to the monitor <b>107</b>, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. As one example, a pen digitizer <b>165</b> and accompanying pen or user input device <b>166</b> are provided in order to digitally capture freehand input. The pen digitizer <b>165</b> may be coupled to the processing unit <b>110</b> via the serial port interface <b>106</b> and the system bus <b>130</b>, as shown in FIG. 1, or through any other suitable connection. Furthermore, although the digitizer <b>165</b> is shown apart from the monitor <b>107</b>, the usable input area of the digitizer <b>165</b> may be co-extensive with the display area of the monitor <b>107</b>. Further still, the digitizer <b>165</b> may be integrated in the monitor <b>107</b>, or may exist as a separate device overlaying or otherwise appended to the monitor <b>107</b>.

P-0028[0028] The computer <b>100</b> may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer <b>109</b>. The remote computer <b>109</b> may be a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer <b>100</b>, although only a memory storage device <b>111</b> with related applications programs <b>196</b> have been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) <b>112</b> and a wide area network (WAN) <b>113</b>. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

P-0029[0029] When used in a LAN networking environment, the computer <b>100</b> is connected to the local network <b>112</b> through a network interface or adapter <b>114</b>. When used in a WAN networking environment, the personal computer <b>100</b> typically includes a modem <b>115</b> or other means for establishing a communications link over the wide area network <b>113</b>, e.g., to the Internet. The modem <b>115</b>, which may be internal or external, is connected to the system bus <b>130</b> via the serial port interface <b>106</b>. In a networked environment, program modules depicted relative to the personal computer <b>100</b>, or portions thereof, may be stored in a remote memory storage device.

P-0030[0030] It will be appreciated that the network connections shown are exemplary and other techniques for establishing a communications link between the computers may be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like is presumed, and the system may be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Any of various conventional web browsers may be used to display and manipulate data on web pages.

P-0031[0031] With reference to FIG. 2, the inventive methods may be embodied as computer readable instructions stored on a computer readable medium such as a floppy disk, CD-ROM, removable storage device, hard disk, system memory, or other data storage medium. FIG. 2 illustrates a block diagram of a computer readable medium <b>201</b> that may be used in accordance with one or more aspects of the invention, further described below. The computer readable medium <b>201</b> may store one or more software modules, such as code components <b>411</b>, SSC module <b>403</b>, entropy <b>405</b>, and encrypted data store <b>409</b>. Evidence provider <b>407</b> may also optionally be stored on computer readable medium <b>201</b>. More or fewer software modules may alternatively be used. For example, entropy <b>405</b> may be stored internally in SSC module <b>403</b>. When one or more computer processors execute one or more of the software modules, the software modules interact to perform according to aspects of the present invention. While the software modules may be stored on the same computer readable medium or on various computer readable mediums used by a common system, the computer system may execute one or more of the software modules in separate process spaces to maintain security, as is known in the art.

P-0032[0032]FIG. 4 illustrates a data flow diagram according to one or more aspects of the invention. Within a runtime environment <b>401</b>, there is a secret store component (SSC) <b>403</b>, entropy <b>405</b>, an evidence provider <b>407</b>, and an encrypted store <b>409</b>. One or more code components <b>411</b> execute on top of the runtime environment. The terms “code component” and “application” are used interchangeably herein.

P-0033[0033] Secret store component (SSC) <b>403</b> manages application secrets as described herein, and may publish public functions available for code components to call in order to perform one or more services in accordance with various aspects of the invention. For example, SSC <b>403</b> may publish a first function StoreSecret ( ) that code components may call in order store one of the code component's secrets, a second function RetrieveSecret ( ) that code components may call in order to retrieve a previously stored secret, and a third function CreateSecretObject ( ) that code components can call in order to create an instance of an object that may be used to securely transfer a secret from one code component to another. Alternatively, SSC <b>403</b> may publish more or fewer functions depending on system design criteria and the like. Developers may then use these functions in their development of secure Internet-scale, componentized, distributed applications.

P-0034[0034] In addition to publishing functions for code components to use, SSC <b>403</b> may retrieve trusted code evidence associate with code components requesting SSC services, securely store SSC (or machine-specific) internal entropy data, compute encryption keys unique for each code component by combining trusted code evidence with SSC internal entropy data, encrypt and decrypt secret data using predefined cryptographic algorithms, and provide persistent storage of encrypted secrets.

P-0035[0035] Entropy <b>405</b> may be any data that cannot easily be determined by an attacker and that is specific to an instance of SSC <b>403</b>. Preferable, entropy <b>405</b> includes random binary data specific to the SSC in a given computer environment in order to prevent application secrets stored on one computer from being moved to another computer and decrypted. Entropy may be computed using any high quality random number generator. Reliable random number generators may use a hardware source of randomness if available, or it may use a software random number generator that uses multiple sources of unpredictable events such as a hard disk head position, time between keyboard entries, and so forth. In addition, the entropy is preferably (but not required) larger than the required encryption key size (discussed below).

P-0036[0036] Each SSC may hide the entropy data so that malicious code cannot locate and exploit the machine-specific entropy. This may be done using any of a variety of approaches discussed previously such as scatter-gather algorithms or embedded algorithmic approaches that materialize the entropy when needed. These can be combined with various code obfuscation techniques such as self-modifying code, partially encrypted code segments, and so forth. The specific technique used to hide the entropy data is not critical, so long as the specific technique used affords a reasonable degree of protection and prevents easy attack by hackers and malicious code.

P-0037[0037] In one aspect of the invention, the entropy data includes a random number generated using the WINDOWS® CryptoAPI random number generator when the SSC is installed on a machine. By providing machine specific entropy, and hiding the entropy so that it is not available to malicious code, hackers cannot steal the encrypted store, reinstall it on another machine on which a second SSC is installed, and decrypt the stored secrets using the second machine's SSC.

P-0038[0038] Code components <b>411</b> and SSC <b>403</b> exchange storage and retrieval requests for secrets stored in encrypted store <b>409</b>. Code components <b>411</b> and evidence provider <b>407</b> independently communicate to establish each code component's evidence. Multiple code components using a single shared SSC, evidence provider, and encrypted store increases efficiency and reduces the amount of system resources required to provide a robust security system. However, multiple SSCs, evidence providers, and/or encrypted stores may alternatively be used. Each code component may communicate with the SSC via a published API.

P-0039[0039] A code component (or application) refers to any compilation of source code, object code, or other code that causes computation to occur. For example, a code component may include an executable program, a dynamic link library, a script file, or any source code file that is executed by the runtime environment. The runtime environment may be an operating system such as WINDOWS®, LINUX®, MacOS® and SOLARIS® brand operating systems, or it may be a virtual machine, such as JAVA® VM and Microsoft Corporation's Common Language Runtime (CLR). Other virtual machines and operating systems may alternatively be used.

P-0040[0040] Evidence provider <b>407</b> provides verifiable evidence for use by SSC <b>403</b> and/or code component <b>411</b>, as further discussed below. Evidence generically refers to any trustworthy information regarding a code component (e.g., file name, file size, digital signature, etc.). Evidence provider <b>407</b> is trustworthy code that the SSC relies upon to supply unique information about an application that is requesting its services. Evidence provider is preferably capable of inspecting the in-memory runtime image of such applications and identifying them. In one aspect of the invention, the evidence provider <b>407</b> verifies a digital signature over the application code image. The evidence provider examines the currently executing application code memory image, including an embedded digital signature, and verifies the signature. The result is that if the calling code component is malicious code, the trusted evidence will be evidence associated with the malicious code, and not evidence associated with a non-malicious application (e.g., outlook.exe) the malicious code is attempting to impersonate.

P-0041[0041] In one aspect of the invention, the evidence provider uses Common Language Runtime (CLR) StrongName digital signatures as evidence. StrongNames provide a unique, unspoofable, name for a given CLR code component that also insures that the code has not been modified. The fact that the StrongName is cryptographically bound to the code component using digital signature technology makes the binding particularly strong and verifiable at any given time. Using StrongName-based evidence also provides controlled sharing. For example, one could use only the StrongName public key value as the evidence, resulting in all application code signed with the corresponding private key being treated as the same application by the SSC. Alternatively, by using the full CLR Assembly name including the StrongName public key, user supplied name, version, and locale, very fine grained differentiation between applications is achieved.

P-0042[0042] In other aspects of the invention, evidence provider <b>407</b> may alternatively provide any of various types of evidence, including Authenticode certificates associated with a digital signature over the application, a message digest value over the application code image, or even application name strings provided these are guaranteed to be unique and unspoofable. The specific type of evidence used is secondary to the evidence's level of trustworthiness

P-0043[0043] With further reference to FIG. 5, one or more aspects of the invention provide a method for protecting a code component secret by encrypting the secret using a key based on the code component's evidence, as well as on machine-specific entropy. In step <b>501</b>, SSC <b>403</b> receives a request from code component <b>411</b> to store a secret S. The request may optionally include a code component defined reference value, which may be used when a code component stores multiple secrets. The code component may later use the reference value to indicate to the SCC which of the multiple secrets to retrieve, as further described below.

P-0044[0044] After receiving the request to store secret S, SSC <b>403</b> retrieves, in step <b>503</b>, the trusted evidence for the requesting code component from evidence provider <b>407</b>. After receiving the evidence, SSC <b>403</b> may convert the evidence into a byte array representation. That is, when the evidence is in the form of a character string, the SSC may convert the character string representation into a byte array representation of the data. In step <b>505</b>, SSC <b>407</b> retrieves the machine-specific entropy byte array. These may be retrieved by running an algorithm within the SSC, or could be materialized on a byte-by-byte basis as required for computation of the key.

P-0045[0045] In step <b>507</b>, SSC <b>403</b> calculates the cryptographic key K that will be used to encrypt the secret S by combining the evidence with the entropy. In one aspect of the invention, key K may be defined as the first n bits of HASH(Entropy,Evidence), where n is the required key size for the encryption algorithm (step <b>511</b>, below). Preferably, a non-reversible algorithm such as SHA-1 or MD-5 is used. Knowledge of an application's evidence should not provide useful information as to the key used to protect that application's secrets. If the specific hash function used fails to provide a sufficient number of bits for the desired symmetric encryption key, the SSC may compute additional bits by hashing the results with a known constant, and concatenating the result to the first hash value. Such techniques are well known within the cryptographic community.

P-0046[0046] Alternatively, non-hash-based approaches may be used. It is only important that an attacker cannot easily determine the encryption key if he or she knows the evidence value. One could, for example, use the entropy value to derive a symmetric encryption key, encrypt the evidence value using this key, and then use n bits of the encrypted value as the secret encryption key. The specific algorithm used is secondary to the use of both the evidence and the entropy in generating the key, so long as the algorithm provides sufficient security against hackers reverse-engineering it.

P-0047[0047] In step <b>509</b>, SSC <b>403</b> calculates a random initialization vector (IV) when required by the encryption (cipher) algorithm, e.g., when using a block cipher in cipher block chaining (CBC) mode. If the specific encryption algorithm does not use an initialization vector, this step may be skipped.

P-0048[0048] In step <b>511</b>, the SSC encrypts S using key K (and the initialization vector, when required). In one aspect of the invention, regular, double, or triple DES encryption may be used as the encryption algorithm. In other aspects of the invention, advanced encryption standard (AES) or RC<b>4</b> may be used. However, any encryption algorithm may be used that provides a strong symmetric cipher. Finally, in step <b>513</b>, SCC <b>403</b> stores the encrypted secret in persistent data store <b>409</b> (e.g., a database or file), along with the initialization vector (when used). When, in step <b>501</b>, the code component provides a reference value, the reference value may also be stored with the encrypted secret and the initialization vector. The encrypted store may be indexed or sorted using known database and data storage techniques, including using the reference value as an index value.

P-0049[0049] Using the above method, malicious code cannot circumvent the SSC because the stored secrets are always encrypted, and the malicious code cannot compute the required decryption keys without knowledge of both the per-machine entropy and application-specific evidence values. Even if a piece of malicious code were able to duplicate a piece of evidence, the malicious code would not have all the information necessary to decrypt any secrets, because the malicious code would still need the machine-specific entropy. If the malicious code were able to duplicate the machine specific entropy, the malicious code would only gain access to the secrets stored on that one machine (assuming the attacker could also duplicate the trusted evidence for each code component).

P-0050[0050] With further reference to FIG. 6, the SSC may use a complementary method to retrieve a stored secret from encrypted data store <b>409</b> by creating a symmetric decryption key. Unless the caller is the secret owner, the correct key will not be generated and the retrieval will fail.

P-0051[0051] Beginning in step <b>601</b>, the SSC receives a request from a calling code component for a stored secret S. The request may include a reference value when the code component has more than one secret in storage. If the code component only stores one secret at a time, then default data associated with the code component (e.g., filename) may be used as a reference value. Upon receiving the request, the SSC retrieves, in step <b>603</b>, the data stored in the encrypted data store <b>409</b> at the location identified by the reference value.

P-0052[0052] SSC <b>403</b>, in step <b>605</b>, generates a key K based on data associated with the calling code component <b>411</b>. That is, SSC <b>403</b> retrieves the entropy stored in secure memory, retrieves from evidence provider <b>407</b> the evidence for the calling code component, and uses the first n bits of HASH(Entropy,Evidence), as it did when creating the original key used to store the secret (step <b>507</b>, above). Once the key has been generated, the SSC decrypts S using K in step <b>607</b>.

P-0053[0053] In step <b>609</b>, SSC <b>403</b> may determine whether the decryption was a success and, if so, return the decrypted secret to the calling code component in step <b>611</b>. If the decryption was not a success, the SSC may halt the process and return nothing to the calling code component. The SSC might not always be able to determine if the decryption succeeded or not. Determination of decryption success is only possible when the SSC knows something about the structure of the data that was encrypted. The SSC may add a header structure onto each encrypted secret for this purpose, though this is not required. Alternatively (not shown), the SSC may return the decrypted value to the calling code component regardless of whether the decryption was a success or not. By returning the decrypted value regardless of the decryption's success, the calling code component does not learn whether the decryption was a success or not, and thus cannot gain any beneficial information that could speed up brute force attacks.

P-0054[0054] In another aspect of the invention, with reference to FIG. 7, similar principles may be used to securely pass secrets from one code component to another known, trusted code component. For example, consider an application that makes use of a secure Web service to retrieve stock quotes. Further, the Web service owner only wants to send the stock quotes to its own client application code, which is designed such that the quote data cannot be stored and easily made available to others. To enforce this, an SSL client authentication credential (e.g., an X509 Certificate and corresponding private key) unique to the client application code is generated when the client first registers for the stock quote service. The client application then needs to store this so it is not accessible by other applications. In use (i.e., to receive stock quotes), the client application needs to supply the authentication credential to the SSL protocol handler provided by the operating system. This preferably is done in such a manner that only the SSL protocol handler has access to the credential information, and not other code that may be running in the same process space as the client application.

P-0055[0055]FIG. 7 illustrates a method performed by SSC <b>403</b>, with associated data flow, for sending a protected secret from a sending code component <b>751</b> to a recipient code component <b>759</b> within a runtime environment (e.g., an OS process or a virtual machine environment). In FIG. 7, solid lines indicate control flow (i.e., steps), and dashed lines indicate data flow. The dotted rectangle indicates steps performed by SSC <b>403</b>.

P-0056[0056] In step <b>701</b>, the SSC receives a request from the sending code component <b>751</b> to create an object O that securely stores the secret S, and that sending code component <b>751</b> can use to communicate the secret to recipient code component <b>759</b>. The request may include a reference value (REF) <b>753</b> that identifies the secret in the encrypted store <b>409</b>, and should include a copy of recipient evidence (REV) <b>755</b> that is associated with the intended recipient code component <b>759</b>.

P-0057[0057] In step <b>703</b>, the SSC retrieves the encrypted secret (ES) from encrypted data store <b>409</b> using the reference value, and in step <b>705</b> constructs transport object instance (O) <b>757</b>. SSC inserts into object instance <b>757</b> various object properties, including the encrypted secret (ES), the secret owner's evidence (EV) (i.e., the sending code component's evidence), and the intended recipient's evidence (REV). When the encryption/decryption algorithm requires an initialization vector (IV), the initialization vector may also be inserted as an object property. Optionally, the reference value (REF) may also be included in O (not shown). One or more of the object properties may be private object properties, such as the object properties storing evidence. O preferably has a lifespan of one. That is, once O is referred back to and the secret returned to the intended recipient the SSC will delete O. However, one of skill in the art will appreciate a variation of the invention in which O may have a lifespan greater than one.

P-0058[0058] After creating the object O, SSC passes, in step <b>707</b>, to sending code component <b>751</b> a reference to O <b>761</b> (e.g., a pointer, an instance name, etc.). Subsequently, in step <b>709</b>, sending code component <b>751</b> sends to receiving code component <b>759</b> the reference to O. The reference to O may be transmitted using any convenient in- or inter-process communication mechanism such as a shared memory buffer, named pipe, message queue, and the like. Because the information in O is encrypted, and because only a reference to O is being transmitted, there is no requirement that the reference to O be kept secret.

P-0059[0059] Upon receiving reference to O <b>761</b>, receiving code component sends to the SSC, in step <b>711</b>, a request for secret S based on reference to O <b>761</b>. In step <b>713</b>, SSC reads the object properties stored in O <b>757</b>, and compares the intended recipient evidence (REV) <b>755</b> to the trusted caller's evidence <b>763</b>, which is the trusted evidence associated with the code component that called the SSC with the reference to O (i.e., receiving code component <b>759</b>). If the two pieces of evidence do not match, SSC may halt such that the calling code component, now identified as other than the intended recipient, cannot receive the decrypted secret.

P-0060[0060] If, however, the trusted caller evidence <b>763</b> matches recipient evidence <b>755</b>, the SSC is assured that the receiving code component <b>759</b> is the intended recipient, and the SSC generates the decryption key in step <b>715</b>. The decryption key may be generated using the internally stored owner evidence (EV) based on the principles discussed above. After generating the decryption key, the SSC decrypts secret S in step <b>717</b>, and returns the decrypted secret <b>765</b> to the receiving code component <b>759</b> in step <b>719</b>.

P-0061[0061] Using the above described principles, software developers of all sizes with any budget can provide Internet-scale, componentized, and/or distributed applications that safely store critical application (code component) secrets. A non-exhaustive list of types of applications that can benefit from secure storage of secrets includes middle tier Web services components that access a database backend, interacting service components communicating across a network, applications that require code components to authenticate in addition to authenticating a user, and Web cookie management applications. It should be appreciated by one of skill in the art that other types of applications may also benefit from services provided by the invention as discussed herein.

P-0062[0062] While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims.