System and method for controlling and enforcing access rights to encrypted media

A system for providing rights controlled access to digital media comprises a server data processor and a client data processor connected by a communications network. The user data processor provides access to a data object in accordance with rules associated with the data object by the server data processor. The client data processor comprises a machine key device and a user key device. The machine key device is preferably an installed component of the client data processor that provides encryption, decryption, and authentication functionality for the client data processor. The user key device is preferably a removable, portable device that connects to the client data processor and provides encryption, decryption, and authentication functionality for the user. A method restricts the use of a data object to a particular user and a particular data processor through the use of additional layers of encryption. The method preferably comprises encrypting a data object such that the it can be decrypted by the machine key device, and further encrypting the data object such that it can be decrypted by the user key device. A method restricts the use of a data object to a particular user and a particular data processor through the use of rules that require authentication of the machine key device and the user key device.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to controlling and enforcing access rights to data objects and, more particularly, the invention relates to restricting the use of a data object to particular data processors and/or users.

2. Description of the Related Art

Digital representations of media include text files, digital audio, digital video, digital images, and digital multimedia files, among others. The benefits of these media representations and their associated technologies are manifold. These digital representations of media have enabled significant advances in the reproduction, distribution, and use/presentation of the media. There are, however, drawbacks associated with these representations. Digital media is easily copied and/or reproduced, making unauthorized copying or use difficult to control. Ease of transmission also makes unauthorized distribution difficult to control.

Systems have been developed to address the problem of controlling and securely maintaining one's ownership rights in digital media, while still permitting use of the digital media by others. One system is described in U.S. Pat. No. 5,845,281, METHOD AND SYSTEM FOR MANAGING A DATA OBJECT SO AS TO COMPLY WITH PREDETERMINED CONDITIONS FOR USAGE, which issued Dec. 1, 1998 to Benson et al., and is assigned to the assignee of the present application. Another system is described in U.S. Pat. No. 5,892,900, SYSTEMS AND METHODS FOR SECURE TRANSACTION MANAGEMENT AND ELECTRONIC RIGHTS PROTECTION, which issued Apr. 6, 1999 to Ginter et al.

Existing systems generally comprise a client program (user program) executing on a user computer and a server program (data packaging program) executing on a server computer. The computers are generally connected through a computer network. The server program packages a digital media representation (data object) along with a set of rules that govern the use of the data object, in a secure package. The secure package is encrypted such that only the client program can decrypt and use it. The secure package is then transmitted to the client program, which allows use of the data object in accordance with the prescribed rules of use. The data object may, for example, be a digital video file in MPEG format. In this case, the server program would package the video file and a set of rules governing the use of the file in a secure package. The server would then transmit the secure package to the client program. The client program would then likely display the video sequence in accordance with the rules associated with the file.

The limitations of the rules of use are generally delimited by the capabilities of the client program. In other words, a rule is typically an instruction to the client program to allow or not allow some action, or alternatively an instruction to perform an action. Accordingly, the client program needs to be able to understand and implement the actions prescribed by the rules. Typical client programs allow rules that specify such things as: a) how many times a data object can be used or presented, b) whether the data object can be copied, c) whether a hardcopy or printout of the data object can be made, if applicable. Other rules can be created, as long as the client program is capable of performing the associated actions on the device upon which the client program is running.

SUMMARY OF THE INVENTION

The present invention provides a system and associated methods for extending the capabilities of rights controlled access media systems. The system and methods provide for designation and authentication of the identity of the data processor upon/through which a data object is to be used. The system further provides for encryption of a data object and its associated rules such that only a designated data processor can decrypt and use the data object. The system and methods further provide for designation and authentication of the identity of a user by whom the data object is to be used. The system also provides for encryption of a data object and its associated rules such that only a designated user can decrypt and use the data object.

In one embodiment, the system comprises a data object provider data processor and a user data processor connected by a communications network. The user data processor preferably comprises a machine key device and a user key device. The machine key device is preferably an installed component of the user data processor that provides encryption, decryption, and authentication functionality for the user data processor. The user key device is preferably a removable, portable device that connects to the user data processor and provides encryption, decryption, and authentication functionality for the user.

In one embodiment, a method restricts the use of a data object to a particular user and a particular data processor through the use of additional layers of encryption. The method preferably comprises encrypting a data object such that it can be decrypted by the machine key device, and further encrypting the data object such that it can be decrypted by the user key device. This embodiment can also be applied outside the context of rights controlled access media systems to limit or restrict the use of a data object to a particular data processor or user. In this case, the rules typically associated with a data object need not be included and the encryption for the user and machine key devices serve as the limitations on the use of the data object.

In another embodiment, a method restricts the use of a data object to a particular user and a particular data processor through the use of rules that require authentication of the machine key device and the user key device. The method preferably comprises including a machine digital certificate within a set of rules and creating a rule that requires the authentication of a machine key device based upon the included machine digital certificate. The method preferably further comprises including a user digital certificate within a set of rules and creating a rule that requires the authentication of a user key device based upon the included user digital certificate.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the description that follows, a first and several alternative embodiments of the invention will be described in detail. As will be understood by one skilled in the art, features described with reference to alternative embodiments may also be applicable in the context of the first embodiment as well as other alternative embodiments.

I. General Overview

FIG. 1Ais a flow diagram showing the general data flow according to a first embodiment of the invention. The flow diagram is divided into a data object provider part102and a user part104. In the first embodiment, the data object provider part102is generally performed through a data object provider data processor200(FIG. 2) and the user part104is generally performed through a user data processor300(FIG. 3).

In the data object provider part102, a data object106is created by an author. The author also determines the conditions108for the usage of the data object106by a user. The data object106and the usage conditions108are input to a data packaging program110, which creates a secure data package112of the data object106and of control data116which are based on the input usage conditions108. Once packaged in this way, the data object106can only be accessed by a user program114.

The data object106is packaged together with a set of control data116. The control data116may be a general set of control data, which is the same for all users of the data object106. This may be the case when the data object106is sent to a retailer or a bulletin board, wherefrom a user may obtain it. The data object106may also be packaged as a consequence of a request from a user for usage of the data object106. In that case, the package may include control data116, which is specifically adapted to that user. This control data116is called a user set of control data. It may for example comprise the number of usages purchased by the user. Typically, the user set of control data will be created on the basis of the general set of control data and include at least a subset thereof. A user set of control data116need not always be adapted for a specific user. All sets of control data116that are created on the basis of a general set of control data will be called a user set of control data. Thus, a set of control data116can be a general set in one phase and a user set in another phase.

The above-mentioned data packaging can be carried out by the author himself by means of the data packaging program110. As an alternative, the author may send his data object106to a broker, who inputs the data object106and the usage conditions determined by the author to the data packaging program110in order to create a secure package112. The author may also sell his data object106to the broker. In that case, the broker may apply its own usage conditions to the data packaging program110. The author may also provide the data object106in a secure package to the broker, which repackages the data object106and adds further control data, which is relevant to its business activities. Various combinations of the above alternatives are also conceivable.

In the user part104of the flow diagram, a user program114receives the secure package112. The user program114preferably interacts with a machine key device118and a user key device120in order to authenticate the identity of the user and/or user data processor and unpackage the secure package112. Upon successful unpackaging, the user program114presents the data object106in a final form122for usage. After usage, the data object106is preferably repackaged into the secure package112.

The control data116preferably comprises control elements that control all operations relating to the usage of the object106. The number of control elements is preferably unlimited. The data provider may define any number of control elements to represent his predetermined conditions of usage of the data object106. A restriction, however, is that the data packaging program110and the user program114must have compatible program code to handle all the control elements. Control elements can contain data, script or program code that is executed by the user program114to control usage of the related data object106. Script and program code can contain conditional statements or other statements, which are processed with the relevant object and system parameters on the user data processor300in order to control use of the data object106.

FIG. 1Billustrates a flow diagram showing the general data flow according to an alternative embodiment of the invention. In the alternative embodiment, the packaging program110creates a separate secure package112A-B for each of the data object106and the usage conditions108. The separate secure packages112A-B can be transmitted separately to the user program114.

In the case of some media formats, the secure package112need not contain the complete data object106. In one embodiment, only a portion of the data object106without which the data object106would be practically useless is included in the secure package112. The portion can include up to the whole of the data object106. In the case of digital video such as MPEG, for example, only some or all of the key frames of a video segment need to be securely packaged in order to protect the complete video segment.

II. System and Data Security

The present invention makes use of encryption technology to implement various security features. At least two types of encryption may be used in accordance with various aspects of the invention: symmetric key encryption and asymmetric key encryption.

Symmetric key encryption employs a single key for both encryption and decryption. The two parties that wish to communicate securely must both hold the symmetric key. A secure message is passed by encrypting the message with the symmetric key, transferring the message, and then decrypting the message with the same symmetric key. Symmetric key encryption can also be used to authenticate a party by sending the party a message encrypted with a symmetric key that is held by the party. If the party can decrypt the message, its identity can be verified by examining the decrypted message. One well-known system for symmetric key encryption is the Data Encryption Standard (DES), a Federal Information Processing Standard (FIPS) that describes the Data Encryption Algorithm (DEA).

Asymmetric key encryption employs a key pair, which comprises a pair of related keys typically called a public key and a private key. One of the keys is used for encryption and the other for decryption. The public key is typically published, while the private key is held secret by one party. Asymmetric key encryption allows one party to send a secure message to another party without the transfer between the parties of a “secret” key. A party that wishes to communicate with another typically encrypts a message with the other party's public key. The encrypted message is then transferred to the other party. The other party then decrypts the message with their corresponding private key. Asymmetric key encryption can also be used to authenticate a party. The party to be authenticated encrypts an identified set of data with its private key. If the encrypted data can be decrypted with the corresponding public key, then the encrypting party must have been in possession of the corresponding private key. Accordingly, the party can be authenticated assuming that the private key has not become compromised. One well-known system for asymmetric key encryption is RSA, devised at the Massachusetts Institute of Technology in 1978 by Rivest, Shamir, and Adelman.

Asymmetric key encryption technology can also be used to verify the authenticity of a message in a process known as signing a message. In this case, a one-way hash of a message is encrypted with the private key of the sender. This encrypted one-way hash is also known as a signature. The signature is sent along with the message itself. The recipient, upon receiving the message and the signature, decrypts the signature (encrypted hash) using the public key of the sender. The recipient also reproduces a hash of the received message using the same one-way hash function used by the sender. If the decrypted hash and the reproduced hash match, the message must be the same, unaltered message that was sent by the sender. In order to assure the authenticity of the public key used to verify the signature, digital certificates have been developed. A digital certificate is a public key that has been signed by a trusted authority that can vouch for the authenticity of the public key. Digital certificates can be easily disseminated and authenticated to facilitate secure communications and authentications. Symmetric key encryption technology could also be used to verify the authenticity of a message by using a symmetric key rather than an asymmetric key to encrypt the hash.

The aforementioned and additional information regarding encryption will be well known to one skilled in the art and is provided solely to facilitate the understanding of the invention by the layman. An excellent introduction to cryptography for the layman is provided by Phil Zimmermann in a document titled, “Introduction to Cryptography,” which can be downloaded at www.pgpi.org/doc/guide/6.5/en/intro/in a PDF file format. A search of the World Wide Web for PKI (public key infrastructure) will also provide several excellent resources on encryption technology.

III. System Components

A. Data Object Provider Data Processor

FIG. 2is a system block diagram of a data object provider data processor200in accordance with the first embodiment. As mentioned above, the data object provider may be an author of a data object, an owner of a data object, a broker of a data object or anyone else who wants to distribute a data object, while retaining the control of its usage. The data processor200is preferably a general or special purpose processor. The data processor200preferably comprises a CPU202, a memory204and a communication device206, which are interconnected by a bus208. The communication device206preferably enables the data object provider data processor300to communicate with one or more user data processors300in order to transfer securely packaged data objects112. The communication device206may be, for example, a media access controller (MAC), used to connect to an Ethernet or the Internet. As shown inFIG. 2, other conventional components, such as a display210, a keyboard212, a printer214, a bulk storage device216, and a ROM218, may also be connected to the bus208. The memory204preferably stores network and telecommunications programs220, and an operating system (OS)222. All the above-mentioned elements are well-known and commercially available. The memory11also stores a data packaging program110and, preferably, a database224for storage of data objects106and/or control data116. Depending upon the current operation, one or more data objects106can be stored in the memory204as shown or in the bulk storage216. The data provider's data processor200is preferably located in a secure environment.

B. User Data Processor

The user data processor300, which is shown inFIG. 3A, is a general or special purpose processor. The user data processor300preferably comprises a CPU302, a memory304, and a communication device306, which are interconnected by a bus308. The communication device306preferably enables the user data processor300to communicate with a data object provider data processor200in order to receive securely packaged data objects112. The communication device306may be, for example, a media access controller (MAC), used to connect to an Ethernet or the Internet. The data object provider data processor200and the user data processor300are preferably connected by a communications network (not shown). As shown inFIG. 3A, other conventional means, such as a display310, a keyboard312, a printer314, a sound system326, a ROM318, and a bulk storage device316, may also be connected to the bus308. The memory304preferably stores network and telecommunications programs320, and an operating system (OS)322. All the above-mentioned elements are well-known and commercially available. For the purpose of the present invention, the memory304also stores a user program114and, optionally, a database324for storage of data objects106and/or control data116. Depending upon the current operation, a data package112can be stored in the memory304, as shown, or in the bulk storage316. The user program114preferably holds a user program key115with which the user program114performs secure operations.

In an alternative embodiment, the user data processor300could be a peripheral device or a plug-in card that may be used in conjunction with a general-purpose computer. In this case, the data processor300preferably comprises a user program114, which may be implemented in hardware or software. In still another embodiment, the user data processor300may be a device having the capability to decode a data object106and produce an output signal for a presentation device. The presentation device could be, for example, a television, a stereo, or a printer. The user data processor300can be a “set-top” box to be used in conjunction with televisions.

C. Key Devices

In accordance with the first embodiment of the present invention, the user data processor300also comprises the machine key device118and a user key device120, which are connected, directly or indirectly, to the bus308. Each key device is preferably a secure device that contains encryption and/or decryption logic and an encryption and/or decryption key or key set. In the first embodiment, the machine key device118contains a machine key119, and the user key device120contains a user key121. In the first embodiment, the key devices118,120use asymmetric encryption/authentication in which case the machine key119and user key121are preferably the private keys of an asymmetric key pair. Alternatively, the key devices118,120may use symmetric encryption in which case the machine key119and user key121would be symmetric keys. In still another embodiment, the machine key119and the user key121may be identification codes instead of encryption keys.

The machine key device118is generally an installed component of the user data processor300that is configured to be not easily portable. The machine key device118may be permanently attached to the user data processor300. For example, the machine key device118could be integrated into the motherboard of a user data processor300(computer). Alternatively, the machine key device118could be a card that is connected through an expansion card slot of a computer such that the housing of the computer must be removed to remove the card. The user key device120is generally a portable or removable component of the user data processor300that can easily be removed and reconnected to alternative user data processors. The user key device120may be a smart card that can be connected to a receptacle on the user data processor300. In the first embodiment, the machine key device118is associated with a user data processor300, while the user key device120is associated with a user of a data object106.

In the first embodiment, the machine key device118and the user key device120are configured to perform encryption and decryption functions. Using the encryption and decryption capabilities of the key devices118,120, the user program114can also perform the functions of message and party authentication. In the case the key devices118,120use asymmetric key technology, the devices preferably are also configured to create key pairs and store private keys. The public keys-can be exported from the key devices118,120and digital certificates can be created from the exported keys. In the case that the key devices118,120use symmetric key technology, the devices preferably store a number of symmetric keys, each of which has a time period during which the key is valid.

The functionality that is provided by the machine key device118can be incorporated into a secure hardware encryption/decryption device in accordance with known techniques. The functionality that is provided by the user key device120can be incorporated in a “smart card” or a credit card sized device having active components in accordance with known techniques.

In an alternative embodiment, the key devices118,120may not include encryption functionality. In this case, the key devices118,120may simply provide a symmetric or an asymmetric key; the functionality of encrypting and decrypting can be incorporated into software running on the user data processor300, such as the user program114. In still another embodiment, the key devices118,120may simply provide a machine key119or user key121in the form of identification codes that can be read by the user program114without encryption to verify the identity of the user data processor or the user. For example, the machine key device118could be a media access controller (MAC) for the user data processor300, from which a unique MAC address can be read. The MAC address can be used as a machine key119to identify the MAC, and accordingly, the user data processor300in which it is installed. The user key device120could, for example, be the keyboard312attached to the user data processor300, provided that the user is prompted to input through the keyboard312a user key121in the form of an identification code that can be used to authenticate the user.

D. Security Modules

In accordance with the first embodiment, as illustrated inFIG. 3B, the user program114includes a number of security modules352,354, and356. The security modules352,354, and356may interface with the key devices118,120and may also implement security functionality such as encryption and decryption. The security modules352,354, and356are preferably software or code sections, or program classes included in the user program code. The security modules352,354, and356may, however, be separate software modules from the user program114. The functionality of the security modules352,354, and356may also be incorporated in one or more hardware modules.

The first security module (or the user program security module)352implements, for the user program114, some or all of the encryption, decryption, message (signature) authentication, and party authentication functionality discussed above with reference to the key devices. The first security module352allows the user program114to receive a basic secure package112from the data object provider data processor200. The first security module352uses a first key (the user program key)115for some or all of its security functions. The variations discussed above with reference to the key devices118,120also apply to the first security module352. For example, the user program key115may be a symmetric key or an asymmetric key pair.

Although the first security module352is included in the first embodiment, its incorporation is not essential to the functioning of the invention. The first security module352, however, allows functionality of the second and third security modules354,356to be disabled while still maintaining the ability to communicate secure packages. This feature allows a data object106to be used in conjunction with the system even when the data object provider does not want to restrict the use of the data object106to a particular user or data processor300.

The second security module354interfaces with the user key device120. In the first embodiment, the second security module354has minimal functionality, with most of the security functionality such as encryption, decryption, party authentication, and signature verification being handled by the user key device120. The second security module354may, in this case, still include functionality sufficient to authenticate the user key device120, in conjunction with the user key device security functionality, as described above. For example, the second security module354may send data to the user key device120which the device120encrypts using its private key. The second security module then authenticates the user key device120by decrypting the encrypted data using the corresponding public key as contained in a digital certificate. In this first embodiment, the second key355need not be included in the second security module354.

In an alternative embodiment, much or all of the security functionality could be incorporated into the second security module354, rather than the user key device120. In this case, the user key device120could simply supply a user key121, which could be the second key355that the second security module uses to implement the security functionality that would otherwise be incorporated into the user key device120. In still another alternative embodiment, the user key device120could be minimally functional, such as supporting no more than the input of a user key121by a user in the form of a password or passcode through the keyboard312. In this case, the second key355, used by the second security module354for security functions would be maintained by the second security module354itself. The second security module354in this case is preferably configured to authenticate the user based upon the code supplied by the user key device120. Further, the second security module354, in this case, is also preferably configured to perform the required security functionality, such as decryption, upon authenticating the user. The variations discussed above with reference to the key devices118,120also apply to the second security module354. For example, the second key115may be a symmetric key or an asymmetric key pair.

The functional requirements of the third security module356are preferably similar to those of the second security module354, but with an interface to the machine key device118instead. The third key357of the third security module356, likewise, may not be necessary, may be the machine key117supplied by the machine key device118, or may be a separate key held by the third security module356, depending upon the embodiment chosen.

In one embodiment, the first, second, and third security modules352,354, and356can be combined into one or two modules. The modules need not be separate identifiable units within the user program114and may be fully integrated to the user program114. In one embodiment, the invention need not incorporate the second security module354or the user key device120, in which case user authentication and user encryption need not be performed. In another embodiment, the invention need not incorporate the third security module356or the machine key device118, in which case machine authentication and machine encryption need not be performed.

IV. User and Machine Encryption of the Secure Package

A. General Embodiment of the Secure Package

In a general embodiment, a data object106is encapsulated in a secure package112by successively encrypting the data object106for decryption by the first, second, and third security modules352,354, and356.FIG. 4Aillustrates three layers of encryption that secure the data object106within the secure package112in accordance with this embodiment. The data object106is encrypted in a first layer402using the first security module key115. The data object106is also encrypted in a second layer404using the second security module key355. The data object106is also encrypted in a third layer406using the third security module key357. Inclusion of all three layers is not essential to the functioning of the invention, however, at least either the second layer404or the third layer406is preferably present.

As illustrated inFIG. 4A, control data116need not necessarily be included in the secure package112. In this case, the encryption for the second and third security modules354and356may be used in lieu of the control data116in order to restrict the use of the data object106to a particular user or data processor300. On the other hand, the control data116can be included to enable access control other than restriction of the use of the data object106to a particular user or data processor300. The control data116may be included in the same secure package112as the data object106or in a separate secure package (e.g.112B inFIG. 1B). The separate secure package112B is preferably signed by the data object provider data processor200and may use single layer encryption, successive encryption similar to that used for the data object secure package112A, or no encryption.

B. The Packaging Process

In the first embodiment, the secure package112is encrypted based upon a program key115as well as a machine key119and a user key121.FIG. 4Billustrates, in accordance with the first embodiment, the layers of encryption used to secure the data object106and, if present, the control data116.FIG. 4Bwill now be discussed in conjunction withFIG. 5A, which illustrates a process500by which the data packaging program110produces the secure package112in accordance with the first embodiment.

At a step502the data packaging program110generates a symmetric session key412and encrypts the data object106and the control data116with the key412. The data object106and the control data116can be encrypted separately or together. As illustrated inFIG. 4B, the data object106and the control data116are encrypted in a layer414. The symmetric session key412is generated and used for a single communication or communication session since information is more efficiently encrypted with symmetric than with asymmetric keys. In general, data to be securely communicated can be encrypted with the symmetric session key, and the session key in turn can be encrypted with an asymmetric key pair. This process is known as “key wrapping.”

At a step504, the data packaging program110encrypts the symmetric session key412with a public program key (wrapping the symmetric session key412). In the first embodiment, the program key115is an asymmetric key pair comprising the public program key and a private program key. The asymmetric key pair is generated in advance by the user program114and the public key is published (preferably as a digital certificate) or transmitted to the data packaging program114. This encryption of the symmetric session key412is in effect a further encryption, using the program key115, of the data encrypted with the symmetric session key412itself. As illustrated inFIG. 4B, the symmetric session key412is encrypted in a layer416. In the first embodiment, the layers414and416together correspond to the first layer402in the general embodiment described above.

In an alternative embodiment, the program key115may be a symmetric program key known to both the packaging program110and the user program114. In this case, the symmetric session key412is preferably encrypted with the symmetric program key. In still another alternative embodiment, the steps502and504can be combined such that the data object106and the control data116are directly encrypted with the program key115. In this case the session key412need not be used.

At a step506the data packaging program110determines whether the use of the data object106is to be restricted to a particular user, and if so, passes control to a step508. If not, the data packaging program110skips step508and passes control on to a step510. The data packaging program110may make this determination based upon usage conditions108specified by the author or data object provider. A control element included in the usage conditions will preferably specify that the data object106is to be restricted to a particular user.

At the step508, the data packaging program110further encrypts the symmetric session key412with a public user key. In the first embodiment, the user key121is an asymmetric key pair comprising the public user key and a private user key. The asymmetric key pair is preferably generated in advance by the user key device120and the public key is published (preferably as a digital certificate) or transmitted to the data packaging program114. This encryption of the symmetric session key412is in effect a further encryption, using the user key121, of the data encrypted with the symmetric session key412itself. As illustrated inFIG. 4B, the step508results in an encryption layer418, which corresponds to the second layer404in the general embodiment described above. In an alternative embodiment, the user key121may be a symmetric user key known to both the packaging program110and the user program114. In this case, the symmetric session key412is preferably further encrypted with the symmetric user key.

At a step510, which is similar to the step506, the data packaging program110determines whether the use of the data object106is to be restricted to a particular data processor, and if so, passes control to a step512. If not, the data packaging program110skips step512and passes control on to a step514.

At the step512, the data packaging program110further encrypts the symmetric session key412with a public machine key. In the first embodiment, the machine key119is an asymmetric key pair comprising the public machine key and a private machine key. The asymmetric key pair is preferably generated in advance by the machine key device118and the public key is published (preferably as a digital certificate) or transmitted to the data packaging program114. This encryption of the symmetric session key412is in effect a further encryption, using the machine key119, of the data encrypted with the symmetric session key412itself. As illustrated inFIG. 4B, the step512results in an encryption layer420, which corresponds to the third layer406in the general embodiment described above. In an alternative embodiment, the machine key119may be a symmetric machine key known to both the packaging program110and the machine key device118. In this case, the symmetric session key412is preferably further encrypted with the symmetric machine key.

At a step514, the data packaging program110completes the packaging of the data object106and control data116and transmits the secure package112over a communications network to the user data processor300. In the first embodiment, the encrypted data object106and control data116as well as the encrypted symmetric session key412are concatenated and header information422is prepended indicating which levels of encryption have been used in the packaging. The data is then packetized for transmission. In an alternative embodiment, the encrypted data object106and control data116may be transmitted separately from the encrypted symmetric session key412. In still another embodiment, the data object106and the control data116can be encrypted separately with different symmetric session keys412. Each of the different symmetric session keys412could then be encrypted separately in accordance with the steps504–512. The data object106, the control data116and the encrypted symmetric session keys could be then sent separately or together. In still another embodiment, the encrypted data object106, the control data116, and the session key412could each be sent separately.

C. The Unpackaging Process

FIG. 5Billustrates a process520by which the user program114unpackages the secure package112in accordance with the first embodiment. At a step522, the user data processor300receives the secure package112from the data packaging program110. The secure package112preferably contains the data object106and the control data116encrypted by the symmetric session key412, as well as the multiple encrypted version of the symmetric session key412.

At a step524, the user program114determines whether the symmetric session key412has been encrypted with the public machine key. If so, the user program114proceeds on to a step526, if not, the user program skips step526and proceeds on to a step528. The user program preferably makes the step524determination by examining the header information422prepended to the secure package in step514of the process500. The header information422preferably indicates which levels of encryption have been applied.

At the step526, the third security module356(FIG. 3B) of the user program114at least partially decrypts the symmetric session key412using the machine key device118. In the first embodiment, the machine key119is an asymmetric key pair comprising a public machine key and a private machine key. The machine key device118preferably comprises the private machine key and logic sufficient to decrypt, using the private machine key, data encrypted with the public machine key. Accordingly, the third security module356preferably provides the encrypted symmetric session key412to the machine key device118and is returned an at least partially decrypted symmetric session key412. This decryption results in removal of the encryption layer420(FIG. 4B).

In an alternative embodiment, the machine key119may be a symmetric machine key known to both the packaging program110and the machine key device118. The machine key device118, in this case, performs the decryption using the symmetric machine key. In an additional alternative embodiment, the decryption functionality could be handled by the third security module356(FIG. 3B) of the user program114. In this case, the machine key device118may simply supply the machine key119with which the third security module356decrypts the symmetric session key412.

At the step528, the user program114determines whether the symmetric session key412has been encrypted with the public user key. If so, the user program114proceeds on to a step530, if not, the user program skips step530and proceeds on to a step532.

At the step530the second security module354(FIG. 3B) of the user program114at least partially decrypts the symmetric session key412using the user key device120. In the first embodiment, the user key121is an asymmetric key pair comprising a public user key and a private user key. The user key device120preferably comprises the private user key and logic sufficient to decrypt, using the private user key, data encrypted with the public user key. Accordingly, the second security module354preferably provides the encrypted symmetric session key412to the user key device120and is returned an at least partially decrypted symmetric session key412. This decryption results in removal of the encryption layer418(FIG. 4B).

In an alternative embodiment, the user key119may be a symmetric user key known to both the packaging program110and the user key device118. The user key device120, in this case, performs the decryption using the symmetric user key. In an additional alternative embodiment, the decryption functionality could be handled by the second security module354(FIG. 3B) of the user program114. In this case, the user key device120may simply supply the user key121with which the second security module354decrypts the symmetric session key412.

At the step532, the first security module352of the user program114decrypts the symmetric key412using the private program key. In the first embodiment, the program key115is an asymmetric key pair comprising a public program key and the private program key. The first security module352preferably comprises logic for decrypting, using the private program key, data encrypted with the public program key. This decryption results in removal of the encryption layer416and accordingly provides the symmetric session key412.

At a step534, the user program114uses the decrypted symmetric session key412to decrypt the data object106and the control data116. This decryption results in removal of the encryption layer414. The functionality necessary to remove the encryption layer414may be incorporated into the first security module352or it may be incorporated into the user program114itself. Once the data object106and the control data116are exposed, the user program114can present to the user the data object106in accordance with the rules or control elements specified in the control data116.

V. User and Machine Authentication

A. General Embodiment

FIG. 6Aillustrates a general embodiment of a set of control data600that restricts use of a data object106(FIG. 1) to a particular user and a particular data processor300. The set of control data600comprises a number of control elements602. A first control element604contains rules or instructions that restrict use of the data object106to a particular user by authenticating the user. A second control element606contains rules or instructions that restrict use of the data object106to a particular data processor by authenticating the data processor300.

The set of control data600can be used in conjunction with the process500to further protect the data object106against unauthorized use. In the case that a illegitimate entity “breaks” the encryption provided through the process500, the illegitimate entity will then have to break the security features provided by the control data600in conjunction with the user program114in order to gain access to the data object106. Furthermore, the security features provided by the control data600can be used independently of the process500in order to restrict the use of a data object106to a particular data processor300or user.

B. Generating the Control Elements

FIG. 6Billustrates a set of control data610in accordance with the first embodiment. The first control element604restricts the use of the data object106to a particular user through the use of the public user key605(discussed in section IV above). The second control element606restricts the use of the data object106to a particular data processor through the use of the public machine key607(discussed in section IV above).FIG. 6Bwill now be discussed in conjunction withFIG. 7A, which illustrates a process700by which the data packaging program110produces the set of control data610in accordance with the first embodiment.

At a step702, the data packaging program110determines whether the use of the data object106is to be restricted to a user, and if so, passes control to a step704. If not, the data packaging program110skips step704and a subsequent step706and passes control on to a step708. The determination of step702is preferably identical to the determination made in step506of the process500.

At step704, the data packaging program110includes the public user key605in the control data610. In the first embodiment, the user key121is an asymmetric key pair comprising the public user key and a private user key. At step706the data packaging program creates the first control element604. The public user key605may be contained within the first control element604or may be included separately within the control data610. The first control element604preferably comprises data, script, or program code sufficient to instruct the user program114to authenticate the user based upon the public user key605. In an alternative embodiment, a user ID or password could be used in place of the public user key605.

At a step708, the data packaging program110determines whether the use of the data object106is to be restricted to a particular data processor300, and if so, passes control to a step710. If not, the data packaging program110skips step710and a subsequent step712and passes control on to a step714. The determination of step708is preferably identical to the determination made in step510of the process500.

At step710, the data packaging program110includes the public machine key607in the control data610. In the first embodiment, the machine key119is an asymmetric key pair comprising the public machine key and a private machine key. At step712the data packaging program creates the second control element606. The public machine key607may be contained within the second control element606or may be included separately within the control data610. The second control element606preferably comprises data, script, or program code sufficient to instruct the user program114to authenticate the data processor300based upon the public machine key607. In an alternative embodiment, a machine identifier, such as a MAC address (described in section III-C above) could be used in place of the public machine key607.

At the step714, the data packaging program110creates the remaining control elements602that govern the use of the data object106. The remaining control elements can specify, for example, the number of allowed uses of the data object106, the kinds of uses, such as printing as opposed to just viewing, and the duration of use.

At a step716, the data packaging program110securely packages and sends the data object106and the control data116to the user data processor300. In the first embodiment, the step716preferably comprises the process500ofFIG. 5A. In alternative embodiments other secure packaging and/or communication processes may be used in accordance with known techniques.

C. Application of the Control Elements

FIG. 7Billustrates a process720by which the user program114applies the control elements602to restrict the use of the data object106to a particular user and/or a particular data processor300in accordance with the first embodiment. At a step722the user data processor300receives the packaged data object106and control data116from the data packaging program110. At a step724the user program114unpackages the data object106and the control data116. In the first embodiment, the step724preferably comprises the process520ofFIG. 5B.

At a step726, the user program114determines whether the use of the data object106is restricted to a particular data processor. If so, the user program114proceeds on to a step728, if not, the user program skips step728and proceeds on to a step730. The user program preferably makes the step726determination by examining the control elements602. The presence of the second control element606, restricting use of the data object106to a particular data processor300, causes the user program114to make a positive determination in step726. The absence of such a control element causes a negative determination.

At the step728, the third security module356of the user program114authenticates the identity of the user data processor300using the machine key device118in conjunction with the public machine key607. In the first embodiment, the third security module356sends a random data element to the machine key device118. The machine key device118, in turn, encrypts the random data element with the private machine key, held by the machine key device118. The machine key device118, in turn, sends the encrypted random data element back to the third security module356. The third security module356then decrypts the encrypted random data element with the public machine key contained in the control data112. If the decrypted random data element matches the original random data element, the public machine key607contained in the control data116must match the private machine key held by the machine key device118; in this case the data processor300has been authenticated. If the third security module356is not able to authenticate the data processor300, the user program114preferably displays an error message to the user and discontinues processing of the data object106.

In alternative embodiments, other methods of authenticating the data processor300can be used. For example, a MAC (media access controller) address could be used in lieu of the public machine key607. The machine key device118in this case is preferably the MAC, which may not contain encryption functionality. Accordingly, the third security module356may simply verify that the machine key device118has supplied a correct MAC address.

At the step730, the user program114determines whether the use of the data object106is restricted to a particular user. If so, the user program114proceeds on to a step732, if not, the user program skips step732and proceeds on to a step734. The user program preferably makes the step730determination by examining the control elements602. The presence of the first control element604, restricting use of the data object106to a particular user, causes the user program114to make a positive determination in step730. The absence of such a control element causes a negative determination.

At the step732, the second security module354of the user program114authenticates the identity of the user using the user key device120in conjunction with the public user key605. The second security module354performs the step732in a manner similar to that of the step726. If the third security module356is not able to authenticate the user, the user program114preferably displays an error message to the user and discontinues processing of the data object106.

In alternative embodiments, other methods of authenticating the user can be used. For example, a user ID or password could be used in lieu of the public user key605. The user key device120in this case could be the keyboard312through which the user may input a user ID or password. Accordingly, the second security module354may simply verify that the user has supplied the correct user ID or password.

At a step734the user program114continues to process the remaining control elements602in accordance with which the user is granted access to the data object106.

It will be apparent to one skilled in the art that various encryption techniques can be used in conjunction with the packaging and authentication aspects of the present invention. Some of these techniques have been described in sections II, III-C, and III-D above.

Although the invention has been described in terms of certain embodiments, other embodiments that are apparent to those of ordinary skill in the art, including embodiments which do not provide all of the features and advantages set forth herein, are also within the scope of this invention. Accordingly, the scope of the invention is defined by the claims that follow. In the claims, a portion shall include greater than none and up to the whole of a thing; encryption of a thing shall include encryption of a portion of the thing. In the method claims, reference characters are used for convenience of description only, and do not indicate a particular order for performing the method.