Trusted code groups

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to the field of software security, and more particularly to software security verification and validation.

2. Description of the Related Art

Software applications today are typically composed of several different executable modules that work together to provide a common “application function.” For instance, a developer of a new application may write source code that implements the “core business logic” of the application, while resorting to third party or other code libraries for more routine functionality, such as common dialog boxes or communication functions. At runtime, the application is launched and instructs the operating system to load an instance of the other libraries which are dynamically linked to the executing application code. Then the application and the libraries typically work together as a single unit in memory while the application is executing.

However, managing trust between the executing application code and the libraries is difficult. While an application is executing, any libraries that it loads are mapped into the application's memory space or process boundary and execute as if it was part of the application. Once loaded there are no boundaries between the application and the library, and the application is placing complete trust in the library when it calls into the library. The library could modify, delete, or redistribute any or all data the application has access to. As applications become more complex, and libraries are more commonly loaded on a computing device from various, possibly un-trusted locations, it is becoming more important to focus on the security and integrity (i.e., the “trustworthiness”) of code libraries that may be called or loaded by an application.

An adequate mechanism to evaluate and/or ensure the trustworthiness of a code library has eluded those skilled in the art, until now.

SUMMARY OF THE INVENTION

The invention is directed to techniques and mechanisms for ensuring or enforcing trust between an application and a library. In one aspect, the invention envisions a method for ensuring trust between code modules. The method includes receiving an application that uses a class of functionality, the application including a list of Trusted Code Groups (“TCGs”) trusted by the application to implement the class. The method also includes receiving a library that implements the class of functionality, the library being signed using a signing key, the signature associating the library with a TCG, the TCG being an endorsement of trustworthiness. When a call is initiated to cause the library to be loaded, the method includes, prior to loading the library, causing the signature on the library to be verified to determine if the library is a member of one of the listed TCGs.

In another aspect, the invention envisions a method and a computer-readable medium for verifying a trustworthiness of a library. The method includes receiving an instruction from an application to load the library, the application having an associated list of authorized TCG IDs, each TCG ID being associated with a TCG that represents a level of trust associated with a group of libraries. The method further includes examining the library to detect a digital signature that associates a TCG ID with the library, comparing the TCG ID of the library to the list of authorized TCG IDs associated with the application to determine if the library is authorized to execute with the application, and if the library is authorized, loading the library.

In yet another aspect, the invention envisions an apparatus for verifying a trustworthiness of a library. The apparatus includes a storage medium on which is stored an application and a library, a processor, and a memory coupled to the processor and the storage medium, and in which resides computer-executable components. The components are operative to cause the processor to receive an instruction from an application to load the library, the application having an associated list of authorized TCG IDs, each TCG ID being associated with a TCG that represents a level of trust associated with a group of libraries, to examine the library to detect a digital signature that associates a TCG ID with the library, to compare the TCG ID of the library to the list of authorized TCG IDs associated with the application to determine if the library is authorized to execute with the application, and if the library is authorized, to load the library.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout.

<figref idrefs="DRAWINGS">FIG. 1</figref> shows a system memory in which are executing an application and an instance of a library, in accordance with one implementation of the invention.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a conceptual illustration of a hierarchy of Trusted Entities (“TEs”) that each have one or more associated Trusted Code Groups (“TCGs”).

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a sample development environment in which a code developer interacts with a TE to get a library approved for a particular TCG under control of the TE.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a computing device, such as a handheld computing device, on which executes an application that uses a library, in accordance with an implementation of the invention.

<figref idrefs="DRAWINGS">FIG. 5</figref> is an operational flow diagram generally illustrating a method for ensuring trust between an application and a library loaded by that application.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a functional block diagram generally illustrating the core components of a sample computing device in which implementations of the invention are particularly applicable.

DETAILED DESCRIPTION

What follows is a detailed description of various embodiments of the invention that enable an application developer to control the trustworthiness of libraries that the application may cause to be loaded at runtime. Briefly stated, the invention envisions allowing library developers to have their shared libraries evaluated for inclusion in one or more “trusted code groups.” An application developer then includes a listing that identifies those trusted code groups that the application should trust at runtime. When an installed application is launched and attempts to load a library, a trust manager verifies that the library is within a trusted code group recognized by the application. If so, the trust manager allows the library to be loaded, and if not, the trust manager fails the load.

To begin the discussion, <figref idrefs="DRAWINGS">FIG. 1</figref> shows a system memory <b>101</b> in which are executing an application <b>111</b> and an instance of a library <b>131</b>, in accordance with one implementation of the invention. Other code may also be executing in the system memory <b>101</b>, such as other applications <b>145</b> and/or operating system code <b>147</b>. Before proceeding, it is helpful to provide some definitions of terms that will be used throughout this document.

The term “trustor” means any executable code (e.g., an application) that loads a trustee. The trustor has a memory or process protection boundary around it and makes policy for what comes and goes across that boundary. A simple user application is only one example of a trustor. Other examples include, without limitation, scripts, web page content (e.g., “Flash” or “Shockwave” components), user interfaces (e.g., a user interface specification in a high level UI description language), and the like.

The term “trustee” means any executable code (e.g., a library) or configuration data that gets loaded by the trustor at runtime. The term “trustee” includes, without limitation, shared and public libraries, dynamically and statically linked libraries, “extensions”, scripts, configurations, content, user interfaces, or any other resource (e.g., image or multimedia data) as those terms are used in the art.

The terms “application” and “trustor” may be used interchangeably throughout this document. Likewise, the terms “library” and “trustee” may be used interchangeably throughout this document. Accordingly, no specific meaning should be attached to the terms “application” or “library” different than the meanings just ascribed to those terms.

As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, when an application <b>111</b> is loaded in memory <b>101</b>, a process is created in which the application executes, and that process has a process boundary <b>113</b>. Code that is executing within the process boundary <b>113</b> generally has free access to any memory locations within that boundary, but does not have access, at least not directly, outside the process boundary <b>113</b>. Although illustrated here as contiguous memory space, it will be appreciated that a process may have discontiguous memory locations as well.

In this example, the application <b>111</b> is executing within the process boundary <b>113</b> and has allocated for itself memory space for data <b>115</b>. Although shown here as a single contiguous data space <b>115</b>, it will be appreciated that the application <b>111</b> may have several different data locations for different types of data.

At any point during execution, the application <b>111</b> may cause to be loaded one or more libraries, such as library <b>131</b>. In this example, the library <b>131</b> could be any supplemental code used by the application <b>111</b> but which is not integral to the application <b>111</b>. In one example, the library <b>131</b> could be a third-party library that implements some core or special functionality.

The library <b>131</b> generally has no process or protection boundaries of its own, but rather executes within the application's process boundary <b>113</b>. Accordingly, the library <b>131</b> has access to everything the application <b>111</b> does, such as the application's data <b>115</b> and even portions of the application executable code. Moreover, the library <b>131</b> may have its own data <b>117</b> to which the application <b>111</b> may have access. It is this free access to the application's code <b>111</b> and data <b>115</b> that creates the need for a strong trust relationship between the application <b>111</b> and the library <b>131</b>.

As is described more fully in the remainder of this patent document, the application <b>111</b> declares certain information that defines a trust relationship to which the library <b>131</b> must belong. When loaded, the library <b>131</b> indicates those trust relationships to which is does belong. When the library <b>131</b> begins loading, if it does not belong to a trust relationship recognized by the application <b>111</b>, the load is failed.

<figref idrefs="DRAWINGS">FIG. 2</figref> is a conceptual illustration of a hierarchy <b>200</b> of Trusted Entities (“TEs”) that each have one or more associated Trusted Code Groups (“TCGs”). In accordance with the invention, a Trusted Code Group (“TCG”) is essentially a group of code modules that are equally trusted. A Trusted Entity (TE) is an organization, or possibly an individual, that approves or certifies code modules into one or more TCGs. It is envisioned that a particular TE will take ownership of a particular TCG and evaluate or test code modules proposed for membership in the TCG.

In one specific implementation, each TCG has an associated TCG Identifier (TCG ID). The TCG ID is a 32-bit integer that identifies the TCG and uniquely distinguishes each TCG from other TCGs. In this specific implementation, the full range of TCG IDs may extend from 0x00000000 to 0xFFFFFFFF. Referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, a highest level TE (i.e., TE <b>201</b>) has ownership of the entire range of TCG IDs. This highest level TE <b>201</b> may be an organization responsible for the operating system on mobile devices, or the like.

The highest level TE <b>201</b> delegates ranges within the entire TCG ID range to subordinate TEs that correspond to some area of expertise or particular domain of trust. In one example, a subordinate TE (security TE <b>211</b>) may have the obligation to verify and endorse code libraries that are related to any type of security feature. Thus, a range of TCG IDs for security features is delegated to the security TE <b>211</b>. The security TE <b>211</b> may further delegate a sub-range of its TCG IDs to a next level TE. For example, the security TE <b>211</b> may delegate a sub-range of TCG IDs to an encryption TE <b>221</b> or an authentication TE <b>222</b>.

The highest level TE <b>201</b> may delegate a different range of TCG IDs for user interface components to a user interface TE <b>212</b> that is responsible for user interface libraries. The user interface TE <b>212</b> then further delegates a sub-range of its TCG IDs to a common dialogs TE <b>223</b> that is responsible for common dialogs. This hierarchical system allows for a flexible distribution of ranges of TCG IDs that can accommodate additional TCGs in the future. It will be appreciated that certain sub-ranges of the entire range could be excluded from use as a TCG ID for some reason, such as to be reserved for another use.

To illustrate this concept with a concrete example, assume that the highest level TE <b>201</b> delegated the range 0x000F0000 through 0x000FFFFF to the security TE <b>211</b>, and the range 0x00100000 through 0x1A0000 to the user interface TE <b>212</b>. The security TE <b>211</b> may in turn delegate the sub-range 0x000F000F through 0x000F00FF to the encryption TE <b>221</b>, and delegate the sub-range 0x000F0100 through 0x000F0FFF to the authentication TE <b>222</b>. The user interface TE <b>212</b> could delegate the sub-range 0x0010F000 through 0x0010FFFF to the common dialogs TE <b>223</b>. Of course, these specific ranges and sub-ranges are merely examples to illustrate the concept and are not necessary to the invention in any way.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a sample development environment in which a code developer <b>301</b> interacts with a TE <b>331</b> to get a shared library <b>311</b> signed into a particular TCG under control of the TE <b>331</b>. In this example, the code developer <b>301</b> may have developed a library <b>311</b> that can be used in a digital rights management (“DRM”) application to decode secured media content. The TE <b>331</b> has been delegated a range of TCG IDs <b>332</b> with the authority to approve libraries into a particular TCG for DRM libraries. The TE <b>331</b> receives the authority to endorse libraries from a root TE authority or a “CA” <b>333</b> in this example.

The developer <b>301</b> presents the unsigned library <b>311</b> to the TE <b>331</b> for approval, which may include any manner of investigation such as bug checking, virus checking, performance evaluations, or perhaps simply the verification of the identity of the developer <b>301</b> to ensure that the developer <b>301</b> is trustworthy. If the unsigned library <b>311</b> and/or the developer <b>301</b> satisfy the TE's criteria, then the TE <b>331</b> “signs” the unsigned library <b>311</b>. Signing the unsigned library <b>311</b> may include generating a hash value of the unsigned library <b>311</b> and encoding that hash value using a private key <b>320</b>. That encoded hash value is referred to as a digital signature <b>325</b> of the unsigned library <b>311</b>.

In one implementation, the TCG ID <b>312</b> of the group into which the library is being signed is added to the unsigned library <b>311</b> when the digital signature <b>325</b> is generated. This allows a direct identification of the TCG from information added to the library during the signing process. Alternatively, the TCG ID may be associated with the signing authority (e.g., the TE <b>331</b> or the CA <b>333</b>) and embedded in its root certificate, allowing the TCG to be determined indirectly from the certificate chain when the digital signature <b>325</b> is verified at runtime. A common digital certificate standard that is applicable to implementations of the invention is the ITU-T X.509 standard.

It will be appreciated that the digital signature <b>325</b> effectively binds the signed library <b>321</b> to the TCG either explicitly, in the case where the TCG ID <b>312</b> is included with the package, or implicitly, in the case where the certificate <b>335</b> is associated with the TCG through the certificate chain.

The TE <b>331</b> then returns the signed library <b>321</b>, the digital signature <b>325</b>, and possibly the TCG ID <b>312</b> of the group into which the library has been signed. The TE <b>331</b> also returns the TE's certificate <b>335</b>, which includes the TE's public key for use in verifying the authenticity of the digital signature <b>325</b>.

The TE certificate <b>335</b> could in fact be a certificate chain that includes intermediate certificates leading to a trusted root certificate, such as a certificate for the CA <b>333</b>. The developer <b>301</b> is now ready to distribute the signed library <b>321</b>.

It should be noted that although described here as a single entity that performs both the library approval and the certificate issuance, those two tasks could be performed by separate entities. For example, in some cases the TE <b>331</b> may appeal to the CA <b>335</b> to issue the certificate <b>335</b>, or perhaps to a completely separate entity.

<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a computing device <b>401</b>, a handheld computing device in this example, on which executes an application <b>411</b>. One example computing device that may be used in implementations of the invention is illustrated in <figref idrefs="DRAWINGS">FIG. 6</figref> and described below. The computing device <b>401</b> includes an operating system <b>420</b> and one or more installed applications (e.g., application <b>411</b>). There are also one or more code libraries <b>415</b>, which may be “certified” as described above (e.g., certified library <b>417</b>) or un-certified (e.g., library <b>419</b>). In this example, the certified library <b>417</b> has been approved for inclusion in a TCG, and has been signed by an appropriate TE as described above.

The application <b>411</b> has meta-data that includes an authorized TCG list <b>412</b>, which may be a list of the authorized TCG IDs that the application <b>411</b> declares it recognizes. This means that any libraries <b>415</b> loaded with the application <b>411</b> must be in one of the TCGs in the authorized TCG list <b>412</b>. It will be appreciated that the authorized TCG list <b>412</b> may include a range or ranges of trusted TCG IDs, rather than simply a list of individual TCG IDs.

The application <b>411</b> may also include a list of trusted certificates <b>413</b>, which includes root certificates for any TEs that the application <b>411</b> trusts.

The root certificates are used to determine whether a certified library has been altered since it was signed by using the TE's public key (embedded in the root certificate) to validate the digital signature of the certified library <b>517</b>. The trusted certificates <b>413</b> may be pre-installed on the computing device <b>401</b>, or may be installed with the application <b>411</b> or at any other time. The operating system <b>420</b> may also maintain a store of trusted certificates <b>422</b> in addition to or in lieu of the trusted certificates <b>413</b> maintained by the application <b>411</b>.

When the application <b>411</b> is executing, it may try to launch (e.g., perhaps using a “CreateInstance” call, or the like) the certified library <b>417</b>. The application <b>411</b> declares that any library it calls must be a member of one of the trusted TCGs in the authorized TCG list <b>412</b>. This could either be done at initialization as part of the application's startup procedure, or the application <b>411</b> could pass in the authorized TCG list <b>412</b> (or the relevant part of it) with the call (e.g., CreateInstance) to load the library.

In response to the request by the application <b>411</b>, the operating system <b>420</b> locates the certified library <b>417</b> and determines if it is approved for execution with the application <b>411</b>. The approval determination may be performed by a trust manager <b>424</b> module of the operating system <b>420</b> that extracts a digital signature from the certified library <b>417</b> and determines if a corresponding root certificate exists in the application trusted certificates <b>413</b>, or perhaps in the global trusted certificates <b>422</b>. If so, the trust manager <b>424</b> verifies the authenticity of the library's digital signature to ensure that the library has not been altered since it was signed. This verification may include checking with a remote Trust Entity or Certificating Authority <b>460</b> to ensure that the appropriate root certificate is not revoked.

If all that validates, the operating system <b>420</b> loads the certified library <b>417</b> (or a portion of it) and links it to the application <b>411</b> in the application's memory space. If any test along the way fails, then the operating system <b>420</b> doesn't load the certified library <b>417</b> and returns an error.

In some cases, the application <b>411</b> may request a particular class of functionality without necessarily specifying which particular library to invoke. There may be multiple libraries that provide the requested functionality, some certified libraries <b>417</b> and some un-certified libraries <b>419</b>. In those cases, the operating system <b>420</b> may only make available to the application <b>411</b> those libraries that meet the application's TCG requirements (i.e., a certified library <b>417</b>). For example, the application <b>411</b> may render audio content, such as “MP3” content, that is subject to DRM control. In that case, the application <b>411</b> will likely require that any MP3 decoders (libraries) be trusted not to pirate the content. This trust may come in the form of membership in a particular DRM TCG. Thus, when the application <b>411</b> requests an MP3 decoder library, the operating system <b>420</b> only makes MP3 decoder libraries available that are members of the particular DRM TCG.

<figref idrefs="DRAWINGS">FIG. 5</figref> is an operational flow diagram generally illustrating a method <b>500</b> for ensuring trust between an application and a library loaded by that application. The method <b>500</b> generally describes steps performed by various mechanisms in a system for establishing and verifying trust between the application the library.

At block <b>502</b>, a library is created by a code developer. The library may be any module or component of code that is intended or able to execute in a supporting role by sharing a process with another module of executing code, such as an application.

At block <b>504</b>, the library is signed to represent that the library is authorized for inclusion in a TCG. Inclusion in the TCG implies that the library is endorsed by some trusted entity (e.g., a TE) and has been verified to be compliant with any requirements or criteria for inclusion in the TCG. In one implementation, a TCG ID that identifies the particular group in which the library has been signed is explicitly added to the library when it is signed. In an alternative embodiment, a TCG certificate is included with the signed library that represents the particular TCG in which the library has been signed. The TCG certificate is either issued by a TE, or derives its authority from a TE responsible for the TCG. In this way, the signature binds the library to the TCG, either implicitly or explicitly.

At block <b>506</b>, an application is created and configured to use a library such as the library created at block <b>502</b>. The application may be any executable code that performs some primary functionality, and relies on another module of code (i.e., a library) to support that functionality or to provide some supplemental functionality.

At block <b>508</b>, a list of authorized TCGs is added to the application, such as in meta-information for the application. The list of authorized TCGs identifies those TCGs to which any library that is loaded to support the application must belong in order to execute in the process or memory boundary of the application. Alternatively or in addition, the application may include trusted root certificates that represent TEs that the application developer trusts to sign libraries into a TCG.

At block <b>510</b>, the application from block <b>508</b> and the library from block <b>504</b> are installed on a computing device, such as a handheld computing device or intelligent cellular phone. It will be appreciated that the application and the library need not be installed at the same time, and likely will not be, but that both components ultimately get installed on the same device.

At block <b>512</b>, the application is started and begins execution. When the application is launched, a code signature for the application optionally may be verified to ensure that the code was actually provided by the code developer, but that verification is significantly different in character and purpose from the TCG verification described in the bulk of this document.

At block <b>514</b>, the application issues a CreateInstance call to load a class that is implemented by the library. It will be appreciated that in some cases, an application may be written to make calls to a class of library rather than to a particular library. Multiple libraries could be installed to implement that class of library and as such, the application does not have specific control over which implementing class gets instantiated. However, the call by the application to create an instance of that class of library initiates, in this example, the loading of the library from block <b>510</b>.

At block <b>516</b>, before the library is loaded, the signature on the library is checked to be sure it is valid and chains up to root certificates that are identified as trusted by the application. In one implementation, a valid signature indicates that the library has not been altered since it was signed. Accordingly, a TCG ID included with or embedded in the library directly identifies to which TCG the library belongs. Alternatively, the TCG membership may be determined from the certificate chain used to sign the library. For example, trusted root certificates associated with the application may contain confirming (e.g., root) certificates for trusted entities with signing authority for a particular TCG. The TCG certificate associated with the library is evaluated against the local trusted root certificates. It should be noted that an application could identify multiple TCG IDs that are authorized to execute with the application. Those multiple TCG IDs could be identified either as simply a list of TCG IDs, a range of TCG IDs, or perhaps a Boolean expression that defines which one or more TCGs a library must belong to in order to execute with the application. These and other alternatives will be apparent to those skilled in the art.

If the signature on the library confirms its trustworthiness, then at block <b>518</b> the library is loaded. If however the signature on the library fails the confirmation in any way, then at block <b>520</b> it is not loaded. If multiple libraries are loaded on the computing device, an alternative library may be selected and evaluated in the same manner as the initial library. Alternatively, a security prompt may be issued to allow a trust decision to be made by a user or another security confirming authority. Yet another alternative is to simply fail the load of the library and issue an error code to that effect.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a functional block diagram generally illustrating the core components of a sample computing device <b>601</b> in which implementations of the invention are particularly applicable. The computing device <b>601</b> could be any mobile computing device, such as a cellular telephone, a personal digital assistant, a handheld “palmtop” device, a laptop computer, a portable music player, a global positioning satellite (GPS) device, or the like. Similarly, the computing device <b>601</b> could be any fixed computing device, such as a desk-top computer or server.

In this example, the computing device <b>601</b> includes a processor unit <b>604</b>, a memory <b>606</b>, a storage medium <b>613</b>, and an audio unit <b>631</b>. The processor unit <b>604</b> advantageously includes a microprocessor or a special-purpose processor such as a digital signal processor (DSP), but may in the alternative be any conventional form of processor, controller, microcontroller, or state machine.

The processor unit <b>604</b> is coupled to the memory <b>606</b>, which is advantageously implemented as RAM memory holding software instructions that are executed by the processor unit <b>604</b>. In this embodiment, the software instructions stored in the memory <b>606</b> include an operating system <b>610</b>, one or more applications <b>612</b>, and one or more code libraries <b>614</b>. The memory <b>606</b> may be on-board RAM, or the processor unit <b>604</b> and the memory <b>606</b> could collectively reside in an ASIC. In an alternate embodiment, the memory <b>606</b> could be composed of firmware or flash memory.

The processor unit <b>604</b> is coupled to the storage medium <b>613</b>, which may be implemented as any nonvolatile memory, such as ROM memory, flash memory, or a magnetic disk drive, just to name a few. The storage medium <b>613</b> could also be implemented as any combination of those or other technologies, such as a magnetic disk drive with cache (RAM) memory, or the like. In this particular embodiment, the storage medium <b>613</b> is used to store data during periods when the computing device <b>601</b> is powered off or without power.

The computing device <b>601</b> also includes a communications module <b>621</b> that enables bidirectional communication between the computing device <b>601</b> and one or more other computing devices. The communications module <b>621</b> may include components to enable RF or other wireless communications, such as a cellular telephone network, Bluetooth connection, wireless local area network, or perhaps a wireless wide area network. Alternatively, the communications module <b>621</b> may include components to enable land-line or hard-wired network communications, such as an Ethernet connection, RJ-11 connection, universal serial bus connection, IEEE 6394 (Firewire) connection, or the like. These are intended as non-exhaustive lists and many other alternatives are possible.

The audio unit <b>631</b> is a component of the computing device <b>601</b> that is configured to convert signals between analog and digital format. The audio unit <b>631</b> is used by the computing device <b>601</b> to output sound using a speaker <b>632</b> and to receive input signals from a microphone <b>633</b>.

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates only certain components that are generally found in most conventional computing devices. Very many other components are also routinely found in particular implementations, and in certain rare cases, some components shown in <figref idrefs="DRAWINGS">FIG. 6</figref> may be omitted. However, the computing device <b>601</b> shown in <figref idrefs="DRAWINGS">FIG. 6</figref> is typical of the devices commonly found today.

While the present invention has been described with reference to particular embodiments and implementations, it should be understood that these are illustrative only, and that the scope of the invention is not limited to these embodiments. Many variations, modifications, additions and improvements to the embodiments described above are possible. It is contemplated that these variations, modifications, additions and improvements fall within the scope of the invention as detailed within the following claims.