System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party Number:7,415,620 from the United States Patent and Trademark Office (PTO) owispatent In accordance with certain aspects, a chain of trust is established between a subscriber unit and a content provider. A request is submitted from the subscriber unit to the content provider. A challenge nonce is generated at the content provider and returned to the subscriber unit. At the subscriber unit, an operating system (OS) certificate containing an identity of the operating system from the software identity register, information describing the operating system, the challenge nonce, and a CPU public key is formed, and the OS certificate is signed using a CPU private key. The OS certificate and a CPU manufacturer certificate supplied by a manufacturer of the CPU are passed from the subscriber unit to the content provider, and are evaluated at the content provider to determine whether to reject or fulfill the request.<H authenticating, processing, System, and, meth, 7415620.html, Patent, pto, 7415620

Title: System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party

Abstract: In accordance with certain aspects, a chain of trust is established between a subscriber unit and a content provider. A request is submitted from the subscriber unit to the content provider. A challenge nonce is generated at the content provider and returned to the subscriber unit. At the subscriber unit, an operating system (OS) certificate containing an identity of the operating system from the software identity register, information describing the operating system, the challenge nonce, and a CPU public key is formed, and the OS certificate is signed using a CPU private key. The OS certificate and a CPU manufacturer certificate supplied by a manufacturer of the CPU are passed from the subscriber unit to the content provider, and are evaluated at the content provider to determine whether to reject or fulfill the request.

Patent Number: 7,415,620 Issued on 08/19/2008 to England, et al.

Inventors: England; Paul (Bellevue, WA), DeTreville; John D. (Seattle, WA), Lampson; Butler W. (Cambridge, MA)
Assignee: Microsoft Corporation (Redmond, WA)

Appl. No.: 11/615,361

Filed: December 22, 2006

Related U.S. Patent Documents


Application Number	Filing Date	Patent Number	Issue Date
09266207	Mar., 1999	7174457
60105891	Oct., 1998

Current U.S. Class: 713/193 ; 713/164; 713/165; 713/166; 713/167; 713/168; 713/189; 726/10; 726/18; 726/2; 726/26; 726/27

Current International Class: G06F 11/30 (20060101)

Field of Search: 713/164-168,173,189,193 726/2,10,18,26,27

References Cited [Referenced By]

U.S. Patent Documents


4817140	March 1989	Chandra et al.
4827508	May 1989	Shear
4908861	March 1990	Brachtl et al.
4969189	November 1990	Ohta et al.
4977594	December 1990	Shear
5007082	April 1991	Cummins
5023907	June 1991	Johnson et al.
5050213	September 1991	Shear
5140634	August 1992	Guillou et al.
5276311	January 1994	Hennige
5283830	February 1994	Hinsley et al.
5335334	August 1994	Takahashi et al.
5349643	September 1994	Cox et al.
5365589	November 1994	Gutowitz
5410598	April 1995	Shear
5421006	May 1995	Jablon et al.
5448716	September 1995	Hardell et al.
5473690	December 1995	Grimonprez et al.
5473692	December 1995	Davis
5483649	January 1996	Kuznetsov et al.
5491827	February 1996	Holtey
5544246	August 1996	Mandelbaum et al.
5557518	September 1996	Rosen
5557765	September 1996	Lipner et al.
5559957	September 1996	Balk
5615263	March 1997	Takahashi
5623637	April 1997	Jones et al.
5638446	June 1997	Rubin
5654746	August 1997	McMullan, Jr. et al.
5664016	September 1997	Preneel et al.
5671280	September 1997	Rosen
5721781	February 1998	Deo et al.
5724425	March 1998	Chang et al.
5724527	March 1998	Karnik et al.
5745886	April 1998	Rosen
5757919	May 1998	Herbert et al.
5778069	July 1998	Thomlinson et al.
5796824	August 1998	Hasebe et al.
5802592	September 1998	Chess et al.
5812662	September 1998	Hsu et al.
5812980	September 1998	Asai
5841869	November 1998	Merkling et al.
5844986	December 1998	Davis
5860099	January 1999	Milios et al.
5870467	February 1999	Imai et al.
5872847	February 1999	Boyle et al.
5892900	April 1999	Ginter et al.
5892902	April 1999	Clark
5892904	April 1999	Atkinson et al.
5910987	June 1999	Ginter et al.
5915019	June 1999	Ginter et al.
5917912	June 1999	Ginter et al.
5919257	July 1999	Trostle
5920861	July 1999	Hall et al.
5933498	August 1999	Schneck et al.
5937063	August 1999	Davis
5940504	August 1999	Griswold
5943422	August 1999	Van Wie et al.
5944821	August 1999	Angelo
5949876	September 1999	Ginter et al.
5953502	September 1999	Helbig, Sr.
5958050	September 1999	Griffin et al.
5963980	October 1999	Coulier et al.
5974546	October 1999	Anderson
6026166	February 2000	LeBourgeois
6028933	February 2000	Heer et al.
6092189	July 2000	Fisher et al.
6105137	August 2000	Graunke
6148083	November 2000	Fieres
6185678	February 2001	Arbaugh
6189100	February 2001	Barr et al.
6189103	February 2001	Nevarez et al.
6230285	May 2001	Sadowsky et al.
6237786	May 2001	Ginter et al.
6263431	July 2001	Lovelace et al.
6327660	December 2001	Patel
6401208	June 2002	Davis et al.
6453334	September 2002	Vinson et al.
6557104	April 2003	Vu et al.
6735696	May 2004	Hannah
7017188	March 2006	Schmeidler et al.
7047414	May 2006	Wheeler et al.
7103771	September 2006	Grawrock
7188240	March 2007	Berstis et al.
7194092	March 2007	England et al.
7302709	November 2007	England
2002/0007452	January 2002	Traw et al.
2002/0069365	June 2002	Howard et al.
2002/0107803	August 2002	Lisanke et al.
2002/0120936	August 2002	Del Beccaro et al.
2002/0152173	October 2002	Rudd
2003/0056112	March 2003	Vinson et al.
2003/0126454	July 2003	Glew et al.
2003/0163711	August 2003	Grawrock
2003/0188179	October 2003	Challener et al.
2004/0003273	January 2004	Grawrock et al.
2007/0067624	March 2007	England
2007/0086588	April 2007	England
2007/0088946	April 2007	England
2007/0088949	April 2007	England
2007/0104329	May 2007	England

Foreign Patent Documents


0695985	Feb., 1996	EP
2260629	Apr., 1993	GB
1040172	Feb., 1998	JP
WO9938070	Jul., 1999	WO

Other References

Coffey et al, Non-repudiation with mandatory proof of reciept, 1996, ACM, vol. 26, pp. 6-17. cited by examiner .
Arbaugh, William et al., "Automated Recovery in a Secure Bootstrap Process", Network and Distributed System Security Symposium, Internet Society, (Mar. 1998),155-167. cited by other .
Abadi, et al., "Authentication and Delegation with Smart-cards", Jul. 30, 1992 30 pages. cited by other .
Arbaugh, "A Secure and Reliable Bootstrap Architecture", 1996 pp. 1-7. cited by other .
Clark, et al., "BITS: A Smartcard Protected Operating System" Communications on the ACM Nov. 1994 vol. 37 No. 11, pp. 66-94. cited by other .
Feiertag, et al., "The Foundations of a provably secure operating system( PSOS)", California Proceedings of the National Computer Conference AFIPS Press, 1979, pp. 329-334. cited by other .
Internet Security: SanDisk and New Microsoft Technology Provide Copy Protected Music for Internet Music Player Market. (Product Annoucement) Edge: Work Group Computing Report Apr. 19, 1999 2 pages. cited by other .
Kuhn, "The TrustNo1 Cryptoprocessor Concept" Apr. 30, 1997. cited by other .
Lampson, et al., "Authentication in Distributed Systems: Theory and Practice" Digital Equipment Corporation ACM Transactions on Computer Systems vol. 10 No. 4 Nov. 1992 pp. 265-310. cited by other .
McKenkie, "Seybold Report on Internet Publishing", v1 n4 p. 6(9) Dec. 1996. cited by other .
Murphy, et al., "Preventing Piracy: Authorization Software May Ease Hollywood's Fear of the Net" Internet World Magazine Apr. 1, 2000 3 pages. cited by other .
"Phoenix Technologies Partners with Secure Computing in Enterprise Security Marketplace" Jul. 2, 2001 Business Wife Courtesy of Dialog Text Search pp. 1-2. cited by other .
Schneier, "Applied Cryptography" Applied Cryptography Protocols Alogrith and Source Code in C. 1996 pp. 574-577. cited by other .
Stallings(2), "Cryptography and Network Security", 1992, 2nd Edition, pp. 186-187. cited by other .
Stallings, "Cryptography and Network Security", 1999, Prentice Hall, 2nd Edition, pp. 143-147. cited by other .
Yee, "Using Secure Coprocessors" School of Computer Science Carnegie Mellon University 1994 pp. i-vi 1-94. cited by other .
Young, "Facing An Internet Security Minefield Microsoft Hardens NT Server's Defenses" Windows Watcher Sep. 12, 1997 Issue 9 8 pages. cited by other .
Housley, R "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", 1-3. cited by other .
Muller-Schloer, Christian " A Microprocessor-based Cryptoprocessor", vol. 3 Issue 5, (Oct. 31, 1983),5-15. cited by other .
""Non-Final Office Action", U.S. Appl. No. 10/431,011, (Jun. 1, 2007),", U.S. Appl. No. 10/431,011, (Jun. 1, 2007),1-6. cited by other.

Primary Examiner: Vu; Kimyen
Assistant Examiner: Dada; Beemnet W

Parent Case Text

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 09/266,207, filed Mar. 10, 1999, which is hereby incorporated by reference herein. U.S. patent application Ser. No. 09/266,207 is a non-provisional application claiming priority to U.S. provisional patent application Ser. No. 60/105,891 filed on Oct. 26, 1998, which is herein incorporated by reference, and is related to co-pending applications titled "Loading And Identifying A Digital Rights Management Operating System," U.S. patent application Ser. No. 09/227,611, now U.S. Pat. No. 6,327,652, "Key-based Secure Storage," U.S. patent application Ser. No. 09/227,568, "Digital Rights Management," U.S. patent application Ser. No. 09/227,559, now U.S. Pat. No. 6,820,063, and "Digital Rights Management Operating System," U.S. patent application Ser. No. 09/227,561, now U.S. Pat. No. 6,330,670, all filed on Jan. 8, 1999 and assigned to the same assignee as the present application.

Claims

What is claimed is:

1. A method implemented in a subscriber unit for establishing a chain of trust between the subscriber unit and a content provider, the subscriber unit having a central processing unit (CPU) and an operating system (OS), the CPU having a pair of private and public keys, a manufacturer certificate supplied by a manufacturer of the CPU, and a software identity register that holds an identity of the operating system, the method comprising: submitting a request to the content provider, the request specifying a particular content; receiving, from the content provider, a challenge nonce generated at the content provider; forming an OS certificate containing the identity from the software identity register, information describing the operating system, the challenge nonce, and the CPU public key and signing the OS certificate using the CPU private key, wherein the forming comprises forming the OS certificate with one or more items from a boot log containing identities of software components that are executing on the CPU; passing the OS certificate and the CPU manufacturer certificate to the content provider for the content provider to evaluate the OS certificate and the CPU manufacturer to determine whether to reject or fulfill the request.

2. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by determining whether to trust the identity in the OS certificate.

3. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by determining whether the challenge nonce returned in the OS certificate is the challenge nonce generated by the content provider.

4. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by verifying the signature on the OS certificate using the CPU public key contained in the OS certificate.

5. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by determining whether the OS certificate and the manufacturer certificate contain an identical CPU public key.

6. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by verifying a manufacturer signature on the manufacturer certificate.

7. The method as recited in claim 1, wherein the content provider evaluates the OS certificate by determining whether to trust the manufacturer of the CPU.

8. The method as recited in claim 1, further comprising downloading the content specified in the request in an event that the content provider elects to fulfill the request.

9. The method as recited in claim 8, the content provider having encrypted the content using a storage key derived in part from the identity of the operating system.

10. A method implemented in a content provider for establishing a chain of trust between the content provider and a subscriber unit, in which the subscriber unit has a central processing unit (CPU) and an operating system (OS) and the CPU further includes a pair of private and public keys, a manufacturer certificate supplied by a manufacturer of the CPU, and a software identity register that holds an identity of the operating system, the method comprising: receiving a request from the subscriber unit, the request specifying a particular content; generating a challenge nonce; returning the challenge nonce to the subscriber unit; receiving, from the subscriber unit, the CPU manufacturer certificate and an OS certificate containing the identity from the software identity register, information describing the operating system, the challenge nonce, and the CPU public key, the OS certificate having been signed using the CPU private key, wherein the identity from the software identity register comprises one or more items from a boot log containing identities of software components executing on the CPU; and evaluating the OS certificate and the CPU manufacturer certificate at the content provider to determine whether to reject or fulfill the request.

11. A method implemented by a third party for associating a level of trust with a user computer, the user computer having a central processing unit (CPU) and an operating system (OS), the CPU having a pair of private and public keys, a manufacturer certificate supplied by a manufacturer of the CPU, and a software identity register that holds an identity of an operating system executing on the CPU, the method comprising: establishing a secure connection between the user computer and the third party; generating a challenge nonce; transmitting the challenge nonce to the user computer over the secure connection; receiving, from the user computer, an OS certificate and the challenge nonce, wherein the OS certificate comprises one or more items from a boot log containing identities of software components executing on the CPU, and wherein the OS certificate and the challenge nonce are signed by the user computer using the CPU private key; associating the level of trust for the user computer using the signed OS certificate.

12. The method as recited in claim 11, wherein the identities of the software components executing on the CPU are held in the software identity register.

13. The method as recited in claim 11, wherein the level of trust is based on the operating system identified by the software identity register.

14. The method as recited in claim 11, wherein the OS certificate comprises a boot log.

15. The method as recited in claim 11, wherein the OS certificate comprises a value of a register containing a value associated with a boot log.

16. The method as recited in claim 11, wherein the level of trust is based on the identities of the software components executing on the CPU.

17. The method as recited in claim 11, wherein the software components include device drivers executing on the CPU.

18. The method as recited in claim 17, wherein the level of trust is based on the identities of the device drivers executing on the CPU.

19. The method as recited in claim 11, further comprising: receiving, from the user computer, a request for access to specific content; evaluating whether to permit access based on the level of trust associated with the user computer.

20. The method as recited in claim 19, wherein the access comprises: transmitting the specific content to the user computer through the secure connection.

21. The method as recited in claim 19, wherein the access comprises: transmitting a storage key for the specific content to the user computer through the secure connection, wherein the specific content was previously stored on the user computer.

22. The method as recited in claim 21, wherein the specific content was obtained outside the secure connection.

Description

FIELD OF THE INVENTION

This invention relates to computer-implemented authentication systems and methods for authenticating an operating system (OS) to a processor during its boot sequence in order to establish a chain of trust rooted in the combination of the OS and the processor on which it is running. The invention can be used in conjunction with digital rights management systems to establish trust with a content provider. This invention further relates to techniques for securely maintaining the digital content in persistent local memory (such as on disk) while preventing rogue operating systems and applications from illicitly accessing the content.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright .COPYRGT.1998, Microsoft Corporation, All Rights Reserved.

BACKGROUND

More and more content is being delivered in digital form, and more and more digital content is being delivered online over private and public networks, such as Intranets and the Internet. For a client, digital form allows more sophisticated content, while online delivery improves timeliness and convenience. For a publisher, digital content also reduces delivery costs. Unfortunately, these worthwhile attributes are often outweighed in the minds of publishers by the corresponding disadvantage that online information delivery makes it relatively easy to obtain pristine digital content and to pirate the content at the expense and harm of the publisher.

Piracy of digital content, especially online digital content, is not yet a great problem. Most premium content that is available on the Web is of low value, and therefore casual and organized pirates do not yet see an attractive business stealing and reselling content. Increasingly, though, higher-value content is becoming available. Books and audio recordings are available now, and as bandwidths increase, video content will start to appear. With the increase in value of online digital content, the attractiveness of organized and casual theft increases.

The unusual property of digital content is that the publisher (or reseller) gives or sells the content to a client, but continues to restrict rights to use the content even after the content is under the sole physical control of the client. For instance, a publisher will typically retain copyright to a work so that the client cannot reproduce or publish the work without permission. A publisher could also adjust pricing according to whether the client is allowed to make a persistent copy, or is just allowed to view the content online as it is delivered. These scenarios reveal a peculiar arrangement. The user that possesses the digital bits often does not have full rights to their use; instead, the provider retains at least some of the rights.

"Digital rights management" is therefore fast becoming a central requirement if online commerce is to continue its rapid growth. Content providers and the computer industry must quickly address technologies and protocol for ensuring that digital content is properly handled in accordance with the rights granted by the publisher. If measures are not taken, traditional content providers may be put out of business by widespread theft, or, more likely, will refuse altogether to deliver content online.

Traditional security systems ill serve this problem. There are highly secure schemes for encrypting data on networks, authenticating users, revoking certificates, and storing data securely. Unfortunately, none of these systems address the assurance of content security after it has been delivered to a client's machine. Traditional uses of smart cards offer little help. Smart cards merely provide authentication, storage, and encryption capabilities. Ultimately, useful content must be assembled within the host machine for display, and again, at this point the bits are subject to theft. Cryptographic coprocessors provide higher-performance cryptographic operations, and are usually programmable but again, fundamentally, any operating system or sufficiently privileged application, trusted or not, can use the services of the cryptographic processor.

There appear to be three solutions to this problem. One solution is to do away with general-purpose computing devices and use special-purpose tamper-resistant boxes for delivery, storage, and display of secure content. This is the approach adopted by the cable industry and their set-top boxes, and looks set to be the model for DVD-video presentation. The second solution is to use secret, proprietary data formats and applications software, or to use tamper-resistant software containers, in the hope that the resulting complexity will substantially impede piracy. The third solution is to modify the general-purpose computer to support a general model of client-side content security and digital rights management.

A fundamental building block for client-side content security is a secure operating system. If a computer can be booted only into an operating system that itself honors content rights, and allows only compliant applications to access rights-restricted data, then data integrity within the machine can be assured. This stepping-stone to a secure operating system is sometimes called "Secure Boot." If secure boot cannot be assured, then whatever rights management system the secure OS provides, the computer can always be booted into an insecure operating system as a step to compromise it.

Secure boot of an operating system is usually a multi-stage process. A securely booted computer runs a trusted program at startup. The trusted program loads an initial layer of the operating system and checks its integrity (by using a code signature or by other means) before allowing it to run. This layer will in turn load and check the succeeding layers. This proceeds all the way to loading trusted (signed) device drivers, and finally the trusted application(s).

An article by B. Lampson, M. Abadi, and M. Burrows, entitled "Authentication in Distributed Systems: Theory and Practice," ACM Transactions on Computer Systems v10, 265, 1992, describes in general terms the requirements for securely booting an operating system. The only hardware assist is a register that holds a machine secret. When boot begins this register becomes readable, and there's a hardware operation to make this secret unreadable. Once it's unreadable, it stays unreadable until the next boot. The boot code mints a public-key pair and a certificate that the operating system can use to authenticate itself to other parties in order to establish trust.

Clark and Hoffman's BITS system is designed to support secure boot from a smart card. P. C. Clark and L. J. Hoffman, "BITS: A Smartcard Operating System," Comm. ACM. 37, 66, 1994. In their design, the smart card holds the boot sector, and PCs are designed to boot from the smart card. The smart card continues to be involved in the boot process (for example, the smart card holds the signatures or keys of other parts of the OS).

Bennet Yee describes a scheme in which a secure processor first gets control of the booting machine. B. Yee, "Using Secure Coprocessors", Ph.D. Thesis, Carnegie Mellon University, 1994. The secure processor can check code integrity before loading other systems. One of the nice features of this scheme is that there is a tamper-resistant device that can later be queried for the details of the running operating system.

Another secure boot model, known as AEGIS.RTM., is disclosed by W. Arbaugh, D. G. Farber, and J. M Smith in a paper entitled "A Secure and Reliable Bootstrap Architecture", Univ. of Penn. Dept. of CIS Technical Report, IEEE Symposium on Security and Privacy, page 65, 1997. This AEGIS.RTM. model requires a tamper-resistant BIOS that has hard-wired into it the signature of the following stage. This scheme has the very considerable advantage that it works well with current microprocessors and the current PC architecture, but has three drawbacks. First, the set of trusted operating systems or trusted publishers must be wired into the BIOS. Second, if the content is valuable enough (for instance, e-cash or Hollywood videos), users will find a way of replacing the BIOS with one that permits an insecure boot. Third, when obtaining data from a network server, the client has no way of proving to the remote server that it is indeed running a trusted system.

On the more general subject of client-side rights management, several systems exist or have been proposed to encapsulate data and rights in a tamper-resistant software package. An early example is IBM.RTM.'s Cryptolope.RTM.. Another existent commercial implementation of a rights management system has been developed by Intertrust. In the audio domain, AT&T Research have proposed their "A2b.RTM." audio rights management system based on the PolicyMaker rights management system.

SUMMARY

This invention concerns a system and method for distributing digital data to a client and handling the digital data at the client in accordance with the rights granted by the publisher. Generally, the system involves a general-purpose microprocessor that enables a new mechanism that facilitates an authenticated boot sequence in which the operating system can prove its identity to the microprocessor. The boot sequence provides the building blocks for client-side rights management when the system is online, and provides for continued protection of persistent data even when the user goes offline.

In one implementation, the client or subscriber-side computer system has a central processing unit (CPU) and an operating system (OS). The CPU is manufactured with a public-key pair, a manufacturer certificate testifying that the manufacturer built the CPU according to a known specification, and a software identity register. The operating system includes a block of code, referred to as the "boot block". The boot block uniquely describes the operating system in that it will boot that operating system and no other. An OS identity can be established from the boot block by examining a digital signature stored with the boot block or by computing a hash digest of the boot block.

During booting, the CPU executes the boot block as an atomic operation to store the identity of the operating system into the software identity register. Execution of the boot block is such that the software identity register, which can be read but not modified, is set to either the OS identity (i.e., boot block digest or OS public key) if the operation is successful, or zero if some event or circumstance subverts operation.

Rooted in this self-authentication, the OS can then continue to load and validate other blocks of code (including device drivers to be executed). An identity of each block of code that is successfully validated is appended to a boot log.

Following this authenticated boot sequence, the subscriber unit is prepared to establish a chain of trust to prove its hardware and software to a content provider. The CPU in the subscriber unit begins by submitting a request for content maintained at the content provider.

In response to the request, the content provider generates a challenge nonce and returns the challenge nonce to the subscriber unit. The subscriber unit forms an OS certificate that contains the OS identity (held in its software identity register), the boot log, the challenge nonce, and the CPU public key. The CPU signs this newly minted OS certificate using the CPU private key. The subscriber unit returns this OS certificate, along with the CPU manufacturer certificate, to the content provider. The content provider then has sufficient information to identify the OS and other software components identified in the log, and the processor, and to determine whether to trust this combination of software and hardware. If trust is established, the content provider can choose to download the content to the subscriber unit, along with a list of terms under which the content may be used. This list may be in the form of a license or an Access Control List (ACL), specifying by which processor, by which OS, by which application(s), and under which additional terms the content may be used.

The subscriber unit stores the content in encrypted form using a storage key that is generated as a function of CPU-specific and OS-specific data. More particularly, the CPU forms a generator seed from a CPU-specific secret, a user-supplied seed, and OS-specific data from the OS identity register. The generator seed, the CPU-specific key, and the OS digest are input to a hash function to generate a unique storage key. The storage key is then used to encrypt the content. In this manner, only the same CPU and OS that have proven themselves to the content provider are able subsequently to access the data previously encrypted.

Alternatively, the processor may contain a fixed per-processor symmetric key K.sub.S which can be used to encrypt a data structure containing content along with a statement of the conditions under which it may be decrypted; key K.sub.S is also used to decrypt the data structure, test the conditions, and either return the content or fail. Key K.sub.S is to be used only for this pair of operations, which are referred to as "Seal" and "Unseal".

In both of these scenarios for providing secure storage, a key pair K.sub.CPU and K.sub.CPU.sup.-1 unique to the CPU need be capable only of signing, not for encryption. Alternatively, if the key pair K.sub.CPU and K.sub.CPU.sup.-1 is capable of encryption and decryption as well, ordinary user-level software can implement the "Seal" operation, even on another processor, and K.sub.CPU.sup.-1 can be used to implement the "Unseal" operation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic illustration of a system having a subscriber unit and a content provider.

FIG. 2 is a block diagram of the subscriber unit.

FIG. 3 illustrates a signed boot block.

FIG. 4 is a flow diagram showing a method for performing an authenticated boot operation on the operating system.

FIG. 5 illustrates a boot log created during booting of an operating system on the subscriber unit.

FIGS. 6a and 6b are a flow diagram showing a method for proving a CPU and operating system resident at the subscriber unit to the content provider.

FIG. 7 is a flow diagram showing a method for securely storing digital content.

The same numbers are used throughout the drawings to reference like components or features.

DETAILED DESCRIPTION

The following discussion assumes that the reader is familiar with cryptography. For a basic introduction of cryptography, the reader is directed to a text written by Bruce Schneier and entitled "Applied Cryptography: Protocols, Algorithms, and Source Code in C," published by John Wiley & Sons with copyright 1994 (or second edition with copyright 1996), which is hereby incorporated by reference.

This invention concerns a system and method for distributing digital data to a client and handling the digital data at the client in accordance with the rights granted by the publisher. In the most basic scenario, a content provider agrees to deliver digital content to a subscriber unit, provided that the subscriber unit promises not to violate the associated terms for using the digital data and that the content provider can trust the subscriber unit's promise. For instance, the content provider delivers content to the subscriber unit with the understanding that the subscriber unit will not redistribute the content, reproduce the content, or utilize the content in violation of a predefined use agreement between the content provider and the subscriber unit.

The content may be essentially any type of content that can be expressed as digital data, including video, still pictures, audio, graphical images, and textual data or executable content (computer programs). Examples of possible content include feature-length movies, TV shows, games, software programs, news, stock information, weather reports, art, photographs, and so on.

To place this in a particular context for discussion purposes, suppose the content provider 22 is a producer of feature films. Assume that the content provider f22 offers its animated movies at two different prices a low price for the right to view the movie one time as it is delivered online (i.e., akin to pay-per-view) and a higher price for the right to view the movie as often as the subscriber likes (i.e., akin to video purchase). In each case, the agreement specifically prohibits reproduction of the movie or redistribution of the movie to another subscriber unit. In the first case, it also prohibits the client device from making a persistent copy to disk. For the content provider 22 to download a requested movie, it must trust that the subscriber unit will abide by the agreement and not permit illicit use of the digital movie data. This trust involves trust of the hardware components, trust of the operating system, and trust of the applications, as well as trust of the manufacturer of the hardware and software.

FIG. 1 shows a system 20 having a content provider 22 that is capable of delivering digital content to a subscriber unit 24 over a network 26. The content provider 22 has a content database 30 that stores the content and a media server 32 that serves the content to the subscriber unit 24. The media server may be configured to download the entire content as a file, or to stream the content continuously over the network. As an example, the content provider may implement a server computer system comprising one or clustered server computers that handle requests from subscribers, manage the digital files locally, and facilitate delivery of requested digital files over the network 26 to the subscriber unit 24.

The subscriber unit 24 is coupled to receive the digital content from the network 26. The subscriber unit 24 is illustrated as a general-purpose computer that is linked to the network 26 via a network connection, a digital cable interface, a modem, or other interface. The subscriber computer has memory to buffer or to store the digital content received from the content provider, a monitor to display any visual content (video, pictures, images, text, etc.), and a sound system (not shown) to play audio content. The subscriber unit may be implemented, however, as other devices that are capable of receiving and presenting digital content. For instance, the subscriber unit 24 might be a television, or a television/set-top box system, or a portable-computing device (e.g., laptop, palmtop, portable information device, Web-enabled phone, etc.).

The network 26 is representative of many diverse types of networks, including wire-based networks, such as an enterprise network (e.g., a local area network, wide area network) or a public network (e.g., the Internet), and wireless networks (e.g., satellite network, RF network, microwave). The network 26 can also be implemented as a telephone network, or an interactive television network, or any other form for linking the subscriber unit 24 to the content provider 22.

Exemplary Subscriber Unit

FIG. 2 shows general components in the subscriber unit 26. They include a central processing unit (CPU) 40, nonvolatile memory 42 (e.g., ROM, disk drive, CD ROM, etc.), volatile memory 44 (e.g., RAM), and a network interface 46 (e.g., modem, network port, wireless transceiver, etc.). The subscriber unit 26 may also include a sound system 48 and/or a display 50. These components are interconnected via conventional busing architectures, including parallel and serial schemes (not shown).

The CPU 40 has a processor 60 and may have a cryptographic accelerator 62. The CPU 40 is capable of performing cryptographic functions, such as signing, encrypting, decrypting, and authenticating, with or without the accelerator 62 assisting in intensive mathematical computations commonly involved in cryptographic functions.

The CPU manufacturer equips the CPU 40 with a pair of public and private keys 64 that is unique to the CPU. For discussion purpose, the CPU's public key is referred to as "K.sub.CPU" and the corresponding private key is referred to as "K.sub.CPU.sup.-1". Other physical implementations may include storing the key on an external device to which the main CPU has privileged access (where the stored secrets are inaccessible to arbitrary application or operating systems code). The private key is never revealed and is used only for the specific purpose of signing stylized statements, such as when responding to challenges from the content provider, as is discussed below in more detail. The CPU manufacturer may further embed a second secret key K.sub.2 in the CPU 40 or other secure hardware. The second key is distinct from the first key pair, and is used to generate a secure storage key, as is described blow under the heading "Secure Storage". Alternatively, as described below, a symmetric key K.sub.S may be used with "Seal" and "Unseal" operations to encrypt a data structure along with a statement of the conditions under which the data structure may be decrypted.

The manufacturer also issues a signed certificate 66 testifying that it produced the CPU according to a known specification. Generally, the certificate testifies that the manufacturer created the key pair 64, placed the key pair onto the CPU 40, and then destroyed its own knowledge of the private key "K.sub.CPU.sup.-1". In this way, nobody but the CPU knows the CPU private key K.sub.CPU.sup.-1; the same key is not issued to other CPUs. The certificate can in principle be stored on a separate physical device but still logically belongs to the processor with the corresponding key.

The manufacturer has a pair of public and private signing keys, K.sub.MFR and K.sub.MFR.sup.-1. The private key K.sub.MFR.sup.-1 is known only to the manufacturer, while the public key K.sub.MFR is made available to the public. The manufacturer certificate 66 contains the manufacturer's public key K.sub.MFR, the CPU's public key K.sub.CPU, and the above testimony. The manufacture signs the certificate using its private signing key, K.sub.MFR.sup.-1, as follows: Mfr. Certificate=(K.sub.MFR, Certifies-for-Boot, K.sub.CPU), signed by K.sub.MFR.sup.-1

The predicate "certifies-for-boot" is a pledge by the manufacturer that it created the CPU and the CPU key pair according to a known specification. The pledge further states that the CPU can correctly perform authenticated boot procedures, as are described below in more detail. The manufacturer certificate 66 is publicly accessible, yet it cannot be forged without knowledge of the manufacturer's private key K.sub.MFR.sup