Securing executable content using a trusted computing platform

A software development system (SDS) (228) digitally signs software (230) developed on the system. The SDS (228) executes on a computer system (112) having a trusted computing platform. The platform includes protected areas (220, 226) that store data and cannot be accessed by unauthorized modules. A code signing module (232) executing in a protected area (226) obtains a private/public key pair and a corresponding digital certificate. The SDS (228) is configured to automatically and transparently utilize the code signing module (232) to sign software (230) produced by the system. End-user systems (114) receive the certificate with the software and can use it to verify the signature. This verification will fail if a parasitic virus or other malicious code has altered the software (230). Accordingly, the SDS (228) greatly reduces the risk of malicious code executing on the end-user computer system (114).

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains in general to computer security and in particular to preventing malicious and/or unauthorized code from executing on a computer system.

2. Background Art

A parasitic computer virus typically infects a computer system by inserting viral code into other executable programs stored on the computer system. This code can infect other files and/or computer systems, destroy data on the computer system, or perform other malicious actions. Other types of malicious code, including Trojan horses, worms, keystroke grabbers, etc. can also damage computer systems. Thus, there is a strong desire to prevent viruses and other malicious code from infecting and/or executing on a computer system.

One technique for preventing virus infections and other attacks is to install anti-virus software on the computer system in order to detect the presence of viruses and other malicious code. Anti-virus software utilizes various tools, such as string scanning and emulation, to detect malicious code and prevent it from damaging the computer system. However, certain types of malicious code, such as polymorphic, metamorphic, and obfuscated entry point threats, are difficult for anti-virus software to detect.

Another technique for preventing attacks is to establish mechanisms for detecting whether software has been altered by a virus or other malicious code. Code signing is one technique for detecting alterations. Digitally signed code includes values in computer programs that the computer system can use to detect whether the code has been altered. Code signing thus prevents tampering with executable content.

However, existing digital signing schemes are cumbersome. A software developer must obtain a digital certificate from a certificate authority (CA) in order to sign code and this is often a costly and tedious process. Moreover, the developer must securely manage the digital certificate to keep it from being compromised. Since most software developers will not go to the trouble of obtaining such a certificate, most software is not signed. Therefore, most computer systems are configured to execute both signed and unsigned code, meaning that the systems are susceptible to parasitic viruses.

Accordingly, there is a need in the art for a mechanism that allows software developers to easily obtain certificates and digitally sign computer programs. Such a mechanism will significantly reduce the threat of parasitic virus infection and other attacks by making it easier for end-users to detect malicious code.

DISCLOSURE OF INVENTION

The above need is met by a code signing module (232) that executes in the protected area (226) of a developer computer system (112) having a trusted computing platform and automatically signs (316) software developed on the system. A typical computing environment contains a certificate authority (CA) (110), a developer computer system (112), and an end-user computer system (114) in communication via a network (116). The CA (110) is an entity that issues and manages security credentials, keys, and/or other data in order to support authentication, verification, and encryption.

The developer computer system (112) includes a trusted computing platform having a protected area (222) in storage (208) and a protected area (226) in memory (206). Only authorized modules can access these areas. A software development system (SDS) (228) executes on the developer computer system (112). A developer uses the SDS (228) to develop software (230).

A code signing module (232) executes in the protected area (226) of memory (226) on the developer computer system (112) and communicates with the CA (110) to obtain a private/public key pair and a certificate based on the public key. In one embodiment, the certificate also includes a machine ID (203) that uniquely identifies the developer computer system (112). The code signing module (232) stores the private key (234) in a protected area (222).

When the SDS (228) builds a software module (230), it passes the software to a protected area. The code signing module (232) uses the private key (234) to digitally sign (316) the software. As part of the signing process, the code signing module (232) incorporates the certificate into the file containing the software (230). The signed software (230) is passed back into an unprotected area of the developer computer system (112).

The signed software is distributed to an end-user who executes the software (230) on the end-user system (114). The end-user system (114) uses the certificate to verify (320) the signature of the software (230). If the signature does not verify, then there is a high probability that the software has been tampered with by a parasitic virus or other malicious entity. In one embodiment, the end-user system (114) is configured to execute only signed software and to verify each piece of software's signature before executing it. This embodiment prevents the computer system (114) from executing software that has been altered, thereby significantly decreasing the risk that a parasitic virus or other malicious code will harm the computer system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a high-level block diagram of a computing environment100according to one embodiment of the present invention.FIG. 1illustrates a certificate authority (CA)110, a developer computer system112, and an end-user computer system114connected by a network116.

The CA110is an entity that issues and manages security credentials, keys, and/or other data in order to support authentication, verification, and encryption. The CA110issues “certificates” containing encrypted information that can be decrypted using the CA's widely-known public key. A third party, such as the end-user computer system114, can use the CA's public key to decrypt the certificate and verify that the information contained therein has not been altered. Therefore, the functionality provided by the CA110allows information to be communicated from the developer computer system112to the end-user computer system114without tampering (i.e., the end-user computer system is able to detect any tampering). VeriSign, Inc. is an example of a commercial CA112.

In one embodiment, the developer system112contains a trusted computing platform and is utilized by a developer to develop computer programs (sometimes referred to as “software” or “code”) for execution on the end-user system114. In one embodiment, the developer system112communicates with the CA110to obtain certificates and uses the certificates to “sign” software developed on the system. The signing happens in a secure area of the trusted computing platform in order to prevent malicious code from compromising the signature. Although only a single developer system112is shown inFIG. 1, it will be understood that embodiments of the present invention can have thousands or millions of developer systems.

The trusted computing platform utilized by the developer system112implements technologies and protocols that allow third parties to “trust” the platform for certain purposes. The platform can “prove” to the third parties that the platform is trustworthy and has not been altered in a way that would betray the trust. In one embodiment, the trusted computing platform is similar to a conventional computer system, except that the trusted platform has a secure storage that can store data in a location that is tamper-proof and inaccessible to non-trusted software and has a secure execution environment that executes tamper-proof software. Examples of trusted computing platforms that can be utilized with the present invention include the platform advocated by the Trusted Computing Platform Alliance (TCPA) of Hillsboro, Oreg., and the “Palladium” platform advocated by Microsoft Corp. of Redmond, Wash., for the Windows family of operating systems.

In one embodiment, the end-user computer system114is a conventional computer system executing, for example, a Microsoft Windows-compatible operating system (OS), Apple OS X, and/or a Linux-compatible OS. The end-user computer system114is adapted to execute software developed on the developer computer system112. Although only one end-user computer system114is shown inFIG. 1, embodiments of the present invention can have thousands or millions of such systems. Moreover, an end-user computer system114can be a developer computer system112and vice versa depending upon the context. For example, a developer might execute certain end-user software on the developer computer system112.

The end-user computer system114includes functionality for verifying a signature in the software received from the developer system112. If the code has been tampered with by, for example, a parasitic virus, the signature verification will fail and the end-user computer system114will detect the tampering. In one embodiment, the end-user computer system114is configured to execute only signed code. This embodiment substantially reduces the risk of infection by a parasitic virus since the computer system114will quickly detect the presence of a virus.

The network116represents the communication pathways between the CA110, developer system112, and end-user system114. In one embodiment, the network116is the Internet. As such, the CA110and computer systems112,114can use conventional communications technologies such as the secure sockets layer (SSL), Secure HTTP (S-HTTP), and/or virtual private networks (VPNs) to engage in secure communications over network links. The network116can also utilize dedicated or private communications links that are not necessarily part of the Internet. In one embodiment, all or part of the network116includes non-electronic links. For example, the developer may communicate with the CA110via U.S. mail, voice telephone, etc. All of these means of communication are supported and can be included within certain embodiments of the network116ofFIG. 1.

FIG. 2is a high-level block diagram illustrating the developer computer system112according to one embodiment of the present invention. In addition, the end-user system114is also similar to the system illustrated inFIG. 2, although the end-user system might not include a trusted computing platform or software development functionality. As is known in the art, the computer system112is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic for providing the specified functionality. A module can be implemented in hardware, firmware, and/or software.

FIG. 2illustrates at least one processor202coupled to a bus204. Also coupled to the bus204are a memory206, a storage device208, a keyboard210, a graphics adapter212, a pointing device214, and a network adapter216. A display218is coupled to the graphics adapter212. In one embodiment, the processor202includes special-purpose functionality for supporting the trusted computing platform, such as instructions allowing creation of and interfacing with protected storage areas and instructions for executing programs in a “trusted” mode that cannot be interrupted or compromised. In one embodiment, the processor is also compatible with general-purpose processors, such as INTEL x86, SUN MICROSYSTEMS SPARC, and/or POWERPC processors. In one embodiment, the processor202holds an identification value203(referred to as the “machine ID”). The machine ID203uniquely identifies the processor202, the computer system112, and/or the trusted computing platform. In another embodiment, the machine ID203is stored elsewhere in the computer system200.

The storage device208illustrated inFIG. 2is representative of one or more storage devices that are associated with the computer system. The storage devices may include, for example, one or more hard disk drives, a smart card, a memory stick, nonvolatile random access memory (NVRAM), a compact disk (CD) or DVD drive, etc. The storage device208includes an unprotected area220and a protected area222. The unprotected area220holds information that is accessible to all of the components and modules in the computer system112. The protected area222, in contrast, holds information that is accessible only to itself and/or to a set of other trusted components and modules in the computer system112. For example, in one embodiment the unprotected area220is a conventional hard disk drive holding unencrypted data while the protected area is a smart card or other storage device that is accessible to only components and modules having certain permissions and cryptographic keys.

The memory206holds instructions and data utilized by the processor202. In one embodiment the memory206is a random access memory (RAM). Depending upon the embodiment, the memory106may also include firmware, read-only memory (ROM), and/or NVRAM. As with the storage device, the memory is divided into unprotected224and protected226areas. In one embodiment, both the unprotected224and protected226areas are held in RAM, but the pages of memory forming the protected area226are walled-off and bidden by the trusted computing platform so that only certain components and modules can view or modify the data held therein. Modules stored in the storage device208are typically loaded into the memory206in order to be utilized by the processor202. A secure pathway (not shown) over the bus204allows instructions and data to be securely transmitted between the protected area222of the storage device208and the protected area226of the memory206. In addition, the program modules executing in protected memory are typically signed. For these reasons, program modules executing in protected memory226and data held in the protected storage222are “trusted” by other modules in the system112and by third party systems.

The pointing device214may be a mouse, track ball, or other type of pointing device, and is used in combination with the keyboard210to input data into the computer system200. The graphics adapter212displays images and other information on the display218. The network adapter216couples the computer system112to the network116.

In one embodiment, the developer computer system112includes a software development system module (referred to as the “SDS”)228that the developer uses to develop software230adapted for execution on end-user computer systems114. In one embodiment, the SDS228includes functionality allowing the developer to write, compile, link, and debug executable code. For example, Visual Studio available from Microsoft Corp. can be utilized as the SDS228. In one embodiment, at least a portion of the SDS228executes in the unprotected area224of memory206.

The SDS228includes a code signing module232for signing the software230developed with the SDS. In one embodiment, the code signing module232is integrated into SDS228. In another embodiment, the code signing module232is a discrete module that is called by the SDS228or the developer once the software230is produced. In one embodiment, the code signing module232is implemented as an automated process that automatically and transparently (i.e., without developer intervention) signs all software developed with the SDS228. This automated embodiment greatly reduces the burden on the part of the developer to produce signed code.

In one embodiment, the code signing module232executes in the protected area226of memory206and is itself signed. The SDS228uses an application programming interface (API) of the code signing module232and/or trusted computing platform to authenticate itself to the code signing module and pass the developed software230from the unprotected area224to the protected area226of memory206. The SDS228authenticates itself in order to prevent malicious code from impersonating the SDS228and improperly accessing the functionality of the code signing module232. Then, the code signing module232electronically signs the software230and passes the signed software back to the unprotected area224. At this point, the developer can distribute the signed software to the end-user computer systems114.

In another embodiment, the code signing module232executes in a different computer system than the one in which the SDS228executes. In this embodiment, the code signing computer system is connected to the developer computer system112via a secure network connection and/or has another secure pathway for accepting in a trusted manner the software230developed with the SDS228. For example, a corporation or other enterprise that has multiple developers developing the software230can have a dedicated code signing computer system that signs software developed by the enterprise. The software230can be entered into the code signing computer system via a secure network connection or by physically loading media containing the software into a suitable input device in the system.

FIG. 3is a flow chart illustrating steps for developing, distributing, and executing signed code according to one embodiment of the present invention. It should be understood that these steps are illustrative only, and that other embodiments of the present invention may perform different and/or additional steps than those described herein in order to perform different and/or additional tasks. Furthermore, the steps can be performed in different orders than the steps described herein.

The code signing module232or another module executing in the protected area226of memory206obtains310one or more private/public key pairs that can be used to sign software using public-key-based techniques. In one embodiment, the code signing module232obtains the key pairs from the CA110or another entity via a secure network116link. In another embodiment, the code signing module232or another module executing in the protected area226of memory206generates the keys itself. In another embodiment, the trusted computing platform itself has a unique private/public key pair that modules executing on the platform can utilize for digital signatures and other purposes.

As is known in the art, a key is a mathematical value, such as a long integer, that is usually generated according to a random or pseudo-random technique. Public-key encryption utilizes a private key/public key pair. The keys are related such that a message encrypted with the private key can be decrypted with the public key and vice versa, but the public key and message cannot be used (at least in a reasonable amount of time) to calculate the private key. The entity generating the keys can use conventional techniques to generate the key pairs, including, for example, techniques utilizing the Diffie-Hellman, Knapsack, DSA, and/or RSA key-generation schemes. The private keys234are stored in the protected area222of the storage device208and loaded into the protected area226of memory206when utilized by the processor202.

Digital signatures rely upon public-key cryptography techniques to “prove” that an unaltered message was received from a known party. A message encrypted with a private key can be decrypted by only the corresponding public key. Moreover, the decryption will fail if the message and/or public key has been altered. Thus, if the end-user computer system114“knows” the true public key of the CA110and uses that key to decrypt a message received from the CA, the end-user system114can be “sure” that the message was sent by the CA and was not modified.

The code signing module232obtains312a certificate for the key pair. In an embodiment where the code signing module232obtains the certificate from the CA110, the module232communicates with the CA110and “proves” to the CA that it is executing on a trusted computing platform and neither the module nor the platform have been compromised. If the code signing module232generated the keys itself, the module232sends the public key to the CA110in order to obtain312the certificate. In one embodiment, the code signing module232also sends identifying information to the CA110, such as the machine ID203, the name of the developer or enterprise to which the developer belongs, etc.

In response, the CA110creates a certificate specifying the public key and, optionally, the machine ID of the developer system112and/or other identifying information. The CA110signs (i.e., encrypts) the certificate with the CA's private key and sends the certificate to the developer system112. In one embodiment, the CA110retains the machine ID and/or other identifying information in order to allow the developer to be explicitly identified from the certificate even if there is no identifying information in the certificate itself (e.g., the certificate can have a serial number which the CA cross-references with the identifying information). In another embodiment, the CA110discards the machine ID and/or other identifying information in order to render the developer anonymous if there is no identifying information in the certificate.

In one embodiment, the code signing module232generates the keys itself (and/or utilizes keys associated with the trusted computing platform) and also generates the certificate itself. This certificate can be trusted by third parties because the trusted computing platform on the developer computer system112itself is trustworthy.

The developer uses the SDS228to develop314the software230. At some point, the SDS228will build a version of the software230and activate the code signing module232to sign the software. In one embodiment, the SDS228is adapted to use the code signing module232to sign the software every time the SDS compiles and links the code forming the software. This embodiment ensures that all software produced by the SDS228is signed. In another embodiment, the SDS228can be configured to sign only certain software.

The code signing module232uses a hash function to compute a hash of the software. As is known in the art, a “hash function” is a function, mathematical or otherwise, that takes an input string and converts it to a fixed-size output string. In one embodiment, the code signing module232uses the software230as the input to the hash function and obtains a much smaller output string (the “hash”). The hash function is selected so that any change to the software230will produce a change in the hash. Therefore, the hash acts as a sort of fingerprint of the software230. Examples of hash functions that can be used by embodiments of the present invention include MD5 and SHA.

In one embodiment, the code signing module232uses the private key234to encrypt the hash. In another embodiment, the private key234is utilized by the hash function itself to produce the hash, thereby eliminating the need to perform a discrete encryption of the hash. In one embodiment, the code signing module232also uses the machine ID203during this process. For example, the machine ID203can be included in the hashed software, used to influence the hash function, etc. The module232stores the encrypted hash and the certificate containing the public key corresponding to the private key used to encrypt the hash in the software, which effectively signs316the software. In one embodiment, the code signing module232signs all software developed using the SDS228with the same key pair and certificate. In another embodiment, different software developed using the SDS228is signed with different key pairs and certificates.

The code signing module232passes the signed software230out to the unprotected memory area224. At this point, the code signing module232has no further use for the private key. Accordingly, the key can be destroyed or, if there is a desire to save the key, held in the protected area222of the storage device208or held in escrow.

The developer distributes318the signed software230to end-users via standard distribution channels, such as by selling boxed software at retail stores and/or making the software available for download from the Internet. At some point, an end-user attempts to execute the signed software230on an end-user system114.

In one embodiment, the OS or other program modules on the end-user system114verify320the software's signature before executing it. In one embodiment, the end-user system114uses the hashing function to recalculate the hash for the software. Then, the end-user system114decrypts the certificate using the CA's public key and uses the developer's public key contained therein to decrypt the encrypted hash distributed with the software. If the hash of the software generated by the end-user system114matches the decrypted hash distributed with the software, the software230has not been altered and is presumably safe to execute320on the end-user system.

In one embodiment, the end-user system114verifies320the software's signature each time it executes the code. If a parasitic virus, Trojan horse, worm, keystroke grabber, or other malicious code infects the end-user system114and modifies the file containing the software230, the modification will cause the verification to fail. As discussed above, in one embodiment the end-user system114is configured to execute only signed software. In another embodiment, the end-user system114executes only signed software, but does not necessarily verify that the signatures are valid. Rather, the system114treats the signature itself as a guarantee that the software was created by a trusted computing platform and, therefore, is not malicious (this is especially true if the signature explicitly identifies the developer). In another embodiment, the end-user system114does not verify that the signatures are valid yet the greater prevalence of signed software due to the present invention results in a generally safer computing environment than in the past.

In one embodiment, the end-user system114maintains a list of hashes or other data in signatures that identify software known to be malicious. For example, the end-user system114can obtain this list from a provider of anti-virus software via the network116. The end-user system114compares the signatures of new software installed on the system against the data in the list in order to detected signed software that is malicious.

Thus, the SDS228according to the present invention allows a software developer to easily develop signed software. The code signing module232handles the key management, certificate management, and code signing aspects of the process in a manner transparent to the developer. Accordingly, the present invention facilitates an increase in the use of signed code and correspondingly lessens the impact of malicious code on end-user computer systems114. In certain embodiments, the present invention also allows the developer computer system112to be explicitly identified.