Not applicable.
Not applicable.
The present invention relates to data rights management and more particularly to a secured system and methodology and production system and methodology related thereto and to apparatus and methodology for production side systems and are consumer side systems for securely utilizing protected electronic data files of content (protected content), and further relates to controlled distribution, and regulating usage of the respective content on a recipient device (computing system) to be limited strictly to defined permitted uses, in accordance with usage rights (associated with the respective content to control usage of that respective content), on specifically restricted to a specific one particular recipient device (for a plurality of specific particular recipient devices), or usage on some or any authorized recipient device without restriction to any one in specific, to control use of the respective content as an application software program, exporting, modifying, executing as an application program, viewing, and/or printing of electronic data files. These electronic data files can be any type of content, such as for word processing, or image files (such as for audio, visual and audiovisual components), for movies, or still photo visual image files, or audio only files, or any type of stored data content, or content which when authorized is an executable application software program, etc. The present invention applies and works equally well with any of these forms of digital electronic data files.
There is a need to have controlled distribution of digital files in order to protect the proprietary ownership rights as well as non-copyrighted works and other rights including trade secret and business proprietary.
Heretofore, the provision of secured communication (or other distribution) of data files to be protected, has been provided utilizing a variety of techniques, all of which are complex and confusing to the users of the product. Furthermore, the so-called electronic data files, lack in actual security offered, and often fail in being utilized in the areas where it is needed.
In the case of distribution of data files of content comprising text, images, and electronic sheet music, a number of formats have been derived to securely transmit and restrict and selectively provide for either viewing and/or printing of electronic data files. Proprietary systems are available from the music composition software companies of Sibelius (providing a “Scorch” product), and a Finale/Make Music, Inc., which provides its own tools. Additionally, numerous encryption schemes have been derived for transfer of audio music files. These include those provided at the iTunes' website by Apple Computer, Inc., and analogous schemes from others. Additionally, the company PGP, Inc. (Pretty Good Privacy, Inc.), provides both free and purchasable commercial grade products implementing data encryption techniques to permit RSA encryption implementation on files representing data content or application files. Furthermore, many Adobe Acrobat, “PDF” data files are in use, but with minimal or no protection. Additionally, Windows XP, by Microsoft, Inc., offers options for encryption of files.
Secure distribution usually involves encryption or proprietary conversion of some kind. There are many well-known options for this. Encryption, hash functions, other one-way functions, and symmetric and asymmetric encryption are well known to those skilled in the art. (To generally educate oneself, see Applied Cryptography, by Bruce Schneier, Chapter 2, Protocol Building Blocks; also see Section 2.3 on One-Way Functions). The present invention is not restricted to any specific type of encryption, and is compatible with any that otherwise fits specific design needs of an embodiment.
Usage of specific terminology defined within this patent specification shall have the specific meaning ascribed it therein.
The notion of a one-way function is central to public-key cryptography. While not protocols in themselves, one-way functions are a fundamental building block.
One-way functions are relatively easy to compute, but significantly harder to reverse. That is, given x it is easy to compute f(x), but given f(x) it is hard to compute x.
A trap-door one-way function is a special type of one-way function, one with a secret trapdoor. It is easy to compute in one direction and hard to compute in the other direction. But, if one knows the secret, one can easily compute the function in the other direction. That is, it is easy to compute f(x) given x, and hard to compute x given f(x). However, there is some secret information, y, such that given f(x) and y it is easy to compute x.
A one-way hash function can be implemented in many ways and has many names such as compression function, contraction function, message digest, fingerprint, cryptographic checksum, message integrity check (MIC), and manipulation detection code (MDC). One-way hash functions are central to modern cryptography, and are another building block for many protocols.
Hash functions have been used in computer science for a long time. A hash function is a function, mathematical or otherwise, that takes a variable-length input string (called a pre-image) and converts it to a fixed-length (generally smaller) output string (called a hash value).
The point here is to produce a value that indicates whether a candidate pre-image is likely to be the same as the real pre-image. Because hash functions are typically many-to-one, you cannot use them to determine with certainty that the two strings are equal, but you can use them to get a reasonable assurance of accuracy.
A one-way hash function is a hash function that works in one direction: It is easy to compute a hash value from pre-image, but it is hard to generate a pre-image that hashes to a particular value. A good one-way hash function is also collision-free: It is hard to generate two pre-images with the same hash value.
The hash function can be public; there's no need for secrecy to the process. The security of a one-way hash function is its one-wayness. The output is not dependent on the input in any discernible way. A single bit change in the pre-image changes, on the average, half of the bits in the hash value. Given a hash value, it is computationally unfeasible to find a pre-image that hashes to that value.
A hash function can be thought of as a way of fingerprinting files. Thus, to verify that someone has a particular file (that you also have), then ask him for the hash value. If he sends you the correct hash value, then it is almost certain that he has that file. Normally, a one-way hash function is used without a key, so that anyone can verify the hash. If one wants only the recipient to be able to verify the hash, then one can use Message Authentication Codes.
A Message Authentication Code (MAC), also known as a data authentication code (DAC), is a one-way hash function with the addition of a secret key. The hash value is a function of both the pre-image and the key. The theory is exactly the same as hash functions, except only someone with the key can verify the hash value. A MAC can be created out of a hash function or a block encryption algorithm; there are also dedicated MACs.
Public-key cryptography, as described in 1976 by Whitefield Diffie and Martin Hellman, uses two different keys—one public and the other private. It is computationally hard to deduce the private key from the public key. Anyone with the public key can encrypt a message but only the person with the private key can decrypt the message.
Mathematically, the process is based on the trap-door one-way functions. Encryption is the easy direction. Instructions for encryption are the public key; anyone can encrypt a message. Decryption is the hard direction. In the best case, it is made hard enough that people with super computers and years couldn't decrypt the message without the secret. The secret, or trap-door, is the private key. With that secret, decryption is as easy as encryption.
To send a message using public-key cryptography:
(1) Both parties agree on a public-key cryptosystem.
(2) Party 1 sends Party 2 a public key.
(3) Party 2 encrypts a message using Party 1 's public key and sends it to party 1 .
(4) Party 1 decrypts Party 2 's message using Party 1 's private key.
Commonly, a network of users agrees on a public-key cryptosystem. Every user has his or her own public key and private key, and the public keys are all published in a database somewhere.
With asymmetric key encryption, one key is public (e.g., to encrypt or to decrypt), and the other key is private (e.g., to decrypt or to encrypt, respectively).
In the real world, public-key algorithms are not a substitute for symmetric algorithms. They are not used to encrypt messages; they are used to encrypt keys. The reasons for this are that public-key algorithms are slow and that public-key cryptosystems are vulnerable to chosen-plaintext attacks.
In most practical implementations public-key cryptography is used to secure and distribute session keys; those session keys are used with symmetric algorithms to secure message traffic. This is sometimes called a hybrid cryptosystem.
Using public-key cryptography for key distribution solves a very important key-management problem. With symmetric cryptography, the data encryption key sits around until it is used. If anyone ever gets their hands on it, they can decrypt messages encrypted with it. With the hybrid cryptosystem, the session key is created when it is needed to encrypt communications and destroyed when it is no longer needed. This drastically reduces the risk of compromising the session key. Of course, the private key is vulnerable to compromise, but it is at less risk because it is only used once per communication to encrypt a session key.
Public-key Cryptography or Public Key Cryptography refers to a form of cryptography in which each user has a public key and a private key. Messages are sent encrypted with the receiver's public key; the receiver decrypts them using the private key. Using this method, the private key never has to be revealed to anyone other than the user.
Private Key Encryption refers to a form of cryptography in which sender and receiver have the same key or similar keys.
Private Key Cryptography refers to a form of cryptography in which the encryptor and decryptor use the same key, which must be kept secret. This methodology is usually only used by a small group.
Secret Key Encryption refers to a form of cryptography in which sender and receiver share a secret key.
As discussed above, hash functions are one-way functions.
Encryption is different than Hashing.
With Hashing,
Most encrypted content today is encrypted with an encryption key and then a decryption key is used to decrypt the data. The encryption/decryption key pair are sometimes identical (the same) or a matched pair (but different). Either way, the decryption key must be supplied to decrypt the content. If a new decryption key is desired, the content must be re-encrypted. Further, as long as one has the decryption key and the encrypted content, it can be decrypted anywhere and once decrypted, the data can be copied as desired.
A need, therefore, exists for encrypted content to be encrypted only once and yet can be distributed widely. A need exists for the distributed encrypted content to only be available for use on certain specific authorized computers, for usage in accordance with defined usage rights (that can be fixed or have varying rights. A need exists to minimize the computational power required to distribute content to a plurality of users (e.g., up to thousands or even to millions of customers) and a need exists to allow such content to be distributed on media such as mass produced CD-ROMs.
Server-based authentication, while possible, is limited in utility by requiring connection to a server for authentication in order for an appliance to use a file.
It is, therefore, an object of the present invention to provide a methodology and system to provide for the selectively controllable distribution of data files (content) to be protected, and selectively controllable computer appliance specific based usage options such as viewing and printing of electronic data files (or exporting of files, or running of an application software program). It is a further object to make the use of the methodology and system easy and straight forward for the provider of encryption services and for the consumer of decryption services.
In accordance with those and other objectives, the present invention provides in one embodiment, a system and methodology for uniquely encrypting the content for a specific remote appliance's specific usage so that content may be encrypted utilizing an Appliance Identification generated internally within the remote appliance and may also be selectively permitted to view and/or export and/or print and/or execute as an application, the electronic data file. This Appliance Identification is utilized both in the encryption by the provider and is utilized in the recipient device as a part of decrypting in the recipient device (at the consumer level) so as to provide for appliance specific control of utilization of the encrypted content, wherein the control is provided responsive to generation of an appliance identification of a recipient device, such as provided by a query to hardware or installed software in the respective recipient device.
In accordance with one aspect of the present invention, a system and methodology are set forth, providing a structure system architecture for production systems and for recipient systems. Usually, the production systems are run by-or-for the owners (e.g., publishers or copyright owners) or distributors of content to be protected and distributed for restricted regulated controlled usage only on authorized recipient systems. In a preferred embodiment, the usage can further be made specific to a particular recipient device system (e.g., the user's appliance). Overall, the trusted provider's production system provides the production subsystem that works with the recipient subsystem comprised of the recipient system (e.g., recipient device).
In accordance with another aspect of the present invention, protected content is made to be appliance specific. Consumers are supplied only a partial decryption key, wherein a respective utilized production key is encrypted utilizing the generated Appliance ID to provide an encrypted production key. This partial encryption key is useless until the Appliance ID is internally generated and provided by the recipient device appliance, to allow the decryption and generation at the recipient device of a production key copy, which is the key necessary to decrypt the protected content locally at the recipient device of the consumer. The consumer never is allowed to see the production key copy and cannot alter the Appliance ID because it is generated from fixed computer identification parameters.
The distribution of documents, whether they take the form of musical scores, pictures, movies or audio or executable software application programs, remained relatively secure when the distribution medium was a physical paper, tape, film or CD-ROM, respectively. The cost of duplication was typically much more than the cost of the legitimate item. However, with the advent of digital content this distribution cost drops significantly and is a concern for the owners of content (such as documents). For example, this problem exists in the distribution of electronic music.
In accordance with a further aspect of the present invention, Data Rights Management (DRM) is implemented by applying a single encryption to selected files of content for a specific distribution.
In accordance with still another embodiment, to further encrypt for a specific recipient device (such as a particular computer running respective application software), an Appliance ID provided by that specific recipient device (running the application software) is used by the trusted provider (production system) to encrypt the respective associated production key that was utilized for encrypting of respective associated selected files of original content (and associated ticket, where present) as used to generate the respective encrypted content (and where present, the respective associated encrypted ticket). This allows distribution of protected content via Internet download, email, or CD-ROM, etc.
Note, the distributor (trusted provider) can also choose to encrypt the same original file of selected content multiple times, each time differently for different distributions. In this case, the user recipient device is given a key (password) to unlock and deliver usage rights and selectively control and allow access to the content. This key is valid only for the respective content and is valid only on a particular computer. As discussed herein, each computer also has its own identifier, which is generated by respective application software on the recipient device as an Appliance ID. The Appliance ID is generated from specific data within the recipient device, and it is not editable by the user of the recipient device.
In one preferred embodiment, there are tickets (or associated control data) [defining rights], associated with, or included with, or integrated within the original (and encrypted) content. The tickets specify the usage rights for respective associated content that a particular computer recipient device is granted. Once the particular computer has the key(s), the respective associated ticket(s) and the respective associated encrypted content, the particular recipient device provides for selective access to the protected (encrypted) content that is available locally at that particular recipient device computer (without requiring any access or connection to a central server).
At the production subsystem where the content is encrypted initially, the original (selected) content is encrypted responsive to an associated production key to generate respective associated encrypted content. The encrypted content is made selectively available and only utilizable on the recipient device utilizing the respective application software program running on the respective particular computer. In this case, the encrypted content is selectively usable only by the specific particular computer that generated the Appliance ID that was provided to the production subsystem, and that was utilized by the production subsystem to encrypt the respective production key, to provide as an encrypted production key, which is thereafter provided to the particular computer recipient device which utilizes the Appliance ID to decrypt the encrypted production key to generate a decrypted production key which is used to decrypt the encrypted content, and where appropriate, to decrypt the associated encrypted ticket to define usage rights for the associated encrypted content. The production key is encrypted responsive to an Appliance ID (such as generated at the specific computer), to generate an encrypted production key that is provided to and can only be decrypted by the specific particular computer that provided the respective Appliance ID. The integrity of the distribution and controlled usage process is thus maintained.
In accordance with the production aspects of the present invention, encryption tools are used to convert original content into an encrypted form of encrypted content and to create production keys (used by the production subsystem). These tools can be implemented in multiple, alternative forms, such as stand-alone programs, ActiveX servers, etc. The encrypted content can only be used with particular associated (and preferably authorized and validated) application software running on a computer system. The associated authorized application software can be a stand-alone product, a plug-in, or can be included within another specific respective application software. In any case, the associated application software provides for one or more of regulated selective viewing, annotating, collaborative networking, selective printing, selective exporting, and selective active execution of content representing executable application software. Optionally, for another level of appliance specific protection, in addition to the above, a user must obtain an appliance specific key (e.g., a password, a hardware component or otherwise) for use in their particular computer in order to access the protected content. The production key is combined in a secure way with or generated from the Appliance ID to generate an appliance specific key only usable for a particular specific computer recipient device. Tickets defining usage rights can be generated and included with, or separately associated with, or integrated into, the respective associated content (as encrypted) for granting rights to the respective encrypted content on the user's particular specific recipient device computer running the respective associated application software. Authorization can be implemented, controlled and distributed, via a host web site(s) production subsystem, with delivery of the encrypted production key, and optionally the encrypted ticket and/or encrypted content provided to a user by direct download, email, regular postal mail, other electronic delivery or raw text, etc.
A particular specific computer (recipient device) running the respective application software or integrating in the associated application software into other software (also referred to as a client application), provides for control of the access to and usage of the encrypted content on the recipient device, and can also provide other functions. Additionally, other client application software (having the associated application software integrated therein) can be created to provide data rights management (DRM) functionality for other uses. These client applications can even be embedded into specific appliances, into specific other applications, or into computer operating systems. Alternatively, various sub-programs that can be integrated into an associated application software's functionality, can provide either or both of stand-alone or integrated modules into other software, to provide therefor, respective DRM compatible application software.
These and other aspects of the present invention will become clearer by reference to the accompanying drawings and detailed description of the drawings, wherein:
FIG. 1 is a block diagram at a system level showing the provider and consumer sides, and a data rights management overview, illustrating provider level encryption services and consumer decryption services;
FIG. 2 is a block diagram illustrating an alternative embodiment of FIG. 1, where the provider side of the provider and consumer data rights management system provides a combined output of both the encrypted content and the encrypted production key as a single communication to the consumer side recipient device, illustrating both the state flow and system architecture associated therewith;
FIG. 3 is a block diagram and state flow diagram illustrating the provider encryption services and consumer decryption services with appliance specific based data rights management system, with associated rights ticket, further expounding on FIG. 1;
FIG. 4 is a block diagram and state flow diagram, illustrating the combined system of FIG. 3 with the provision of combined content with associated rights ticket;
FIGS. 5-8 illustrate more detailed block diagrams of the provider encryption services block 104 of FIGS. 1-4; wherein
FIG. 5 illustrates a block diagram and state flow diagram for generation of an encrypted content output and an encrypted production key output;
FIG. 6 illustrates a detailed block diagram of the production key block 140 , illustrating the generation of the encrypted production key from the production key and an Appliance ID (preferably a jumbled Appliance ID, and securely communicated) coming from either the appliance (e.g., recipient device) or a storage means (e.g., history file for customer on a host server) storing the Appliance ID from the appliance.
FIG. 7 illustrates a detailed block of the content encryption block 102 , utilizing the production key and original encrypted content to generate the encrypted (original) content output;
FIG. 8 illustrates a more detailed diagram of the production key generation subsystem 101 , which provides for generation of a production key from either a saved key or by generation of a new key;
FIGS. 9-12 provide further details of the consumer decryption services subsystem 204 of FIGS. 1-4 (such as on one or more recipient systems running associated application software); wherein
FIG. 9 illustrates the block diagram and data flow related to the utilization of the communicated encrypted content, jumbled encrypted production key, and utilizing an internally generated Appliance ID to decrypt the production key to generate a production key copy, and for utilizing the production key copy to decrypt the encrypted content copy to provide (preferably-temporary) unencrypted content out;
FIG. 10 illustrates the subsystem 204 for generating the Appliance ID (and jumbled Appliance ID where utilized), for provision respectively within the consumer decryption services subsystem 204 and to the producer subsystem 104 ;
FIG. 11 illustrates the production key decryption subsystem providing for decryption of the encrypted production key utilizing the internally generated Appliance ID to generate an appliance key utilized to decrypt the encrypted production to provide a production key copy output to the consumer decryption subsystem 204 ;
FIG. 12 is a more detailed block diagram and state flow drawing of the decryption of content subsystem 202 of the consumer decryption subsystem 204 providing for decryption of the encrypted content copy utilizing the production key copy to generate the unencrypted content (preferably only temporarily storing the unencrypted content during its usage), for use by the consumer decryption subsystem 204 ;
FIGS. 13-15 illustrate various aspects of usage rights ticket generation, encryption, decoding, and utilization of a rights ticket of FIGS. 3-4; wherein
FIG. 13 illustrates the encrypted ticket generator 401 of FIGS. 3-4 for providing an encrypted ticket output providing for associated defined rights, allowed usages, and Ticket IDs, wherein the encrypted ticket output is associated with production key and encrypted content;
FIG. 14 illustrates ticket decoding at the consumer decryption subsystem 204 and more specifically the utilization in the subsystem 430 of the encrypted ticket output of the encrypted ticket generator 401 wherein the encrypted ticket copy and production key copy are utilized by a decryption engine to generate a ticket copy which is utilized via ticket decode logic to determine rights and allowed usages and Ticket ID verification;
FIG. 15 illustrates the overall system operation for the encrypted ticket generator 401 and the resulting ticket decoding 430 , providing an overall production and consumer system block diagram and state and data flow diagram;
FIG. 16A is a detailed electrical computing system block diagram showing both electronic computing system hardware components, data components, and state flow and data flow for the complete distribution system including the production subsystem and consumer subsystem, with FIG. 16A illustrating the provision of independent non-combined separate outputs of an encrypted production key and associated encrypted content, and where applicable, also an associated encrypted ticket, wherein FIG. 16A provides a detailed system block diagram including data and state flow indications, for FIGS. 1, 3 , and 5 - 15 , as well as FIGS. 18-28 and 30 - 33 ;
FIG. 16B is a detailed overall system block diagram and state and data flow diagram providing for a complete system illustration of the system as illustrated in FIGS. 2, 9 , 10 , 11 and 12 , and FIG. 16B illustrates the system of 16 A where the encrypted content (and where applicable, the associated encrypted ticket) and the associated encrypted production key are combined into a single file output which is thereafter provided to the consumer subsystem (e.g., the recipient device), wherein FIG. 16B is analogous to FIG. 16A, except for the addition of combining logic and separating logic as present in FIG. 16B and not in FIG. 16A, wherein FIG. 16B relates to FIGS. 2, 4 , 5 - 15 , and 16 - 33 ;
FIG. 17A illustrates the data storage structure and components therein, for the encrypted secure format (ESF) and associated encrypted production key (ESZ) as illustrated and discussed herein.
FIG. 18 illustrates a flow chart and state flow diagram for production system encryption of selected content for a specific recipient device;
FIG. 19 illustrates a flow chart and state flow diagram illustrating the decryption of the encrypted content and utilizing the encrypted production provided by the production subsystem (as illustrated in FIG. 18) to provide for a decrypted output, and further illustrates an aspect of the invention providing a flow chart and state flow for only temporarily storing decrypted content in a recipient device during actual usage and authorized utilization thereof;
FIG. 20 is a flow chart and state flow diagram illustrating the selection of authorized utilization, for selectively providing for one of printing, exporting, or viewing, or executing as an application program, of at least a portion of the decrypted content, either in accordance with predetermined default usage rights, or in accordance with a permission usage rights ticket as discussed herein;
FIG. 21 illustrates the reception and storing of the encrypted content and encrypted production output from the production system of FIG. 18 for storage at the recipient device and optionally, at a remotely coupled server;
FIG. 22 is a flow chart and state flow diagram, illustrating the production system ticket generation subsystem, providing a source of usage rights, selected original content, and an associated production encryption key used to generate an output of encrypted content with an associated encrypted ticket, either embedded or separate, regulating usage rights for the respective encrypted content. The production system further provides for encryption of the production encryption key. In a preferred embodiment, this encryption is responsive to an Appliance ID generated at a specific recipient device, in order to provide an encrypted production key which can only be utilized only at the specific recipient device that is associated with (and can regenerate) the generated Appliance ID.
FIG. 23 is a detailed system block diagram combined with a flow chart and state flow diagram, illustrating the utilization at the recipient device 204 of encrypted content with an associated ticket and of an associated encrypted production key, to provide for generation of decrypted content and a decrypted ticket, utilizing a decrypted production key generated internally within the recipient device. The encrypted production encryption key is decrypted utilizing the associated Appliance ID also generated within the respective recipient device. The recipient device provides for recipient device storage of data usage rights within a local memory. Usage rights regulate the number of copies allowed to be used (e.g., printed) and track and store a number of copies already used (e.g., printed)=actual usage, etc., and provides for storage of usage rights data (within the recipient device storage) in an encrypted format. It provides for only temporary storage (of decrypted protected content and/or usage rights tickets) during utilization of the respective decrypted content and the respective decrypted key storage, providing an output controlling permitted usages of the respective content on the recipient device;
FIG. 24 is a flow chart and state flow diagram illustrating the control of selective usage within the recipient device of decrypted content responsive to a decrypted ticket as provided from within the recipient device, (see, for example, FIG. 23), to selectively provide for one of regulated usage of exporting, printing, executing of a file as an application program, or of viewing of a video presentation, for at least a portion of (or all of) the decrypted content and optionally for a defined number of usages, responsive to the usage rights permitted by the decrypted ticket, and also illustrates the process of storing control data with the encrypted ticket in the recipient device, for setting a defined number of usages permitted (e.g., to be printed or copied or exported or an application program executed);
FIG. 25 shows an alternate embodiment, showing a flow chart, state flow, and data flow diagrams, illustrating processing in the recipient device of decrypted original content which original content is itself representative of a ticket defining usage rights for an associated data file, where the recipient device is responsive to a usage request for use of the respective associated data file, and regulates the usage on the recipient device of the associated data file as restricted to the defined usage rights for permitted usage as is granted by the permissions of the ticket of the original content, to provide for regulated permitted usage of the associated data file by the recipient device, such as printing, viewing, exporting, saving, or execution of an application program, represented by the associated data file;
FIG. 26 illustrates a flow chart and state flow diagram corresponding to the combined output systems of FIGS. 2 and 4, herein, wherein encrypted content and an encrypted production key are combined to provide a combined encrypted output which is provided as a combined output to a recipient device, wherein the recipient device receives the combined encrypted output, and separates the combined content into separate files, an encrypted content copy file and an encrypted production key copy file, which are then separately decrypted in the recipient device to provide a decrypted encrypted production key which is utilized to decrypt the encrypted content to provide an output of decrypted content (the unencrypted content).
FIG. 27 illustrates a flow chart and state flow diagram for a production system providing (1) for the encryption of selected original content with a production encryption key; (2) for the encryption of encryption of the respective production encryption key with the same production key; and (3) encryption of the production encryption key to make the distributed protected content appliance specific, by encrypting the production key responsive to an Appliance ID generated at a recipient device to create the encrypted production key, and further provides for encryption, utilizing the same production encryption key, of a usage rights permission ticket output (generated by a ticket logic subsystem to provide a ticket output with defined rights for the associated encrypted content, and encrypts the generated ticket using the same production key as was utilize to encrypt the respective associated selected original content, so as to provide an encrypted ticket output which defines the usage rights, ticket ID, etc., for a ticket specifically associated with the respective encrypted content and encrypted production key, which made appliance specific via the encrypted production key, and are ultimately to be provided to a specific recipient device;
FIG. 28 illustrates a flow chart and state flow diagram for implementing additional security within the recipient device, by storing the decrypted ticket at least in part, in a plurality of locations within storage of the recipient device, to provide for multi-level security verification capability and to increase the level of security;
FIG. 29 illustrates a flow chart and state flow diagram illustrating, within the recipient device, the altering of the multiple stored values for usage rights of decrypted content in the respective multiple locations of the storage device storage of the recipient device 1400 analogous to the storage and locations of FIG. 28;
FIG. 30 illustrates a flow chart and state flow diagram illustrating the operation, within the recipient device, to process and utilize an encrypted ticket, to provide for decrypting of the encrypting content on an appliance specific basis (in a preferred embodiment), to provide decryption of the ticket and ticket ID and other data for usage rights, and provides for validation of usage rights ticket (such as based on actual usage or verifying multiple stored tickets to validate usage rights) providing a validated usage rights signal to regulation logic which regulates the usage of decrypted content as output from FIG. 19, for example, to provide for selectively regulated usage such as viewing, saving, exporting, running as an application program or printing.
The ease of transmitting electronic data from one medium to another has necessitated advances in encryption to secure distribution to protect copyright and trade secrets. The security system and methodology of the present invention provided herein provide for secure distribution and regulated control of usage for protected content provided to recipient device-based products. This mitigates concerns of publishers and editors who want to ensure their works are protected while preserving the ability for others to legally use a copy of the original content unencumbered. Protected works of original content are encrypted for security prior to transmission.
In accordance with the present invention, original content (e.g., information) that is selected to be protected is encrypted and is stored in a proprietary, encrypted format by a trusted provider production system that only valid recipient device appliance software can read or use. Therefore, protected works stay protected no matter where they are, whether on one or more computers, CDs, or via the Internet. In accordance with the present invention, only designated specific recipient devices and authorized trusted providers are able to decrypt this protected data. An encrypted content file, in accordance with one aspect of the present invention, is completely unreadable and unusable on any system except the intended specific authorized recipient device (or devices). The protected content is not usable or readable on any other recipient device, or any other computer that is not authorized, or on any other system, or on CD-ROMS, on a PC, on the Internet, or anywhere else. Each recipient device appliance has a unique identifier associated with it, that is used, in a preferred embodiment, during the encryption process to ensure that protected content is appliance specific and can only be viewed and/or otherwise usable on the recipient device (or devices) that is was intended for. In one preferred embodiment, where copyright or trade secret protection is applicable, all protected content is also protected by affixing or displaying an appropriate copyright notice (or trade secret or other notice) that is not removable.
In another preferred embodiment, a production system generates a specific particular production (encryption) key as associated with the respective selected content. The particular production key is used in encrypting said selected content. A ticket (or other associated data) is generated to define permitted usage rights for the respective selected content, (either based on default criteria (e.g., no use, some uses, and full use) or based upon specific defined usage permission criteria. The production system preferably uses RSA to encrypt its data. RSA is an industry standard encryption used by thousands of companies around the world, including Citibank, Microsoft, Oracle, and Wells Fargo. It has resisted attempts to crack it for over four decades, and is a very powerful encryption solution more than suitable for protecting original content. However, any other encryption technology can also be utilized with the present invention. The choice is one of design consideration.
In a preferred embodiment, several functions that the recipient device would otherwise be able to perform can be selectively disabled (or enhanced) for respective particular encrypted content responsive to respective associated usage rights permissions. In one embodiment, default usage rights permit each authorized recipient device to be allowed to always be able to view encrypted original content that was intended for it.
Examples of functions that be selectively enabled (or disabled) include:
The system and methodology of the present invention, provide for a production system and methodology for the production of protected content, production encryption keys, (and where applicable, associated usage rights) and for secure distribution by a trusted provider's production subsystem, to a consumer subsystem with a recipient device appliance running valid authorized respective associated application software. The system and methodology of the present invention provides for secure distribution, transmission and storage for protected content at all times, thereby protecting the rights of the original content holders and owners and, therefore, ensuring that their original content works stay protected. The present invention also provides for simplified user (consumer) interaction, and in an easy to use manner allows people to legitimately use protected content in permitted ways.
In accordance with one aspect of the present invention, a system and methodology for secure distribution and protection of usage of protected content provides an infrastructure supporting one (or more recipient devices) user appliances—each recipient device comprised of a computer subsystem (processor, memory, display, etc.) running an (authorized, validated) executable application software program (herein also referred to as one of a specific (or particular) device (or appliance or recipient device), providing for one or more defined permitted uses of protected content, and optionally, additionally or alternatively, restricting any usage of the respective content to be only usable on a specific particular appliance. In other words, the protected content is made appliance specific (only usable on a specific defined appliance).
This system and methodology also allows users of the recipient device to efficiently interact with and use the protected content information. The protected content can be of their own creation, or licensed from one or more multiple third parties of original content.
This system and methodology of the present invention also provides controls to be utilized by and for the benefit of owners, producers, distributors, and publishers, to utilize to limit the use of their protected content to (1) any authorized recipient device appliance (a computing system running an authorized copy of the associated application software (that is compatible with the methodology and structure and outputs used by the respective production subsystem to generate the protected (encrypted) content, etc.). (2) Additionally, control of usage can be further restricted to limit usage to only a specific appliance (or specific appliances) that are licensed, by making the protected content only usable on a specific particular designated one (or more) of the specific appliance recipient devices.
In a preferred alternate embodiment, the trusted provider's production system selects the level of security to be associated with protected content. The options for security levels are completely flexible and variable, and can be set to be any of a plurality of levels over a range from limiting to only certain usage of the protected content on specific particular ones of recipient device/appliances, and ranging to permitting all uses of the protected content on any authorized recipient device (appliance), any usages desired to be regulated, including all permitations and combinations of the above. For maximum enhanced security, usage is controlled to only be usable only on a specific designated one or ones of the recipient device(s).
In accordance with another aspect of the present invention, the system and methodology provide for associated identification data of related information (such as the origination, date of creation, alternate titles, etc.) of the protected content information. The association of the associated identification can be either physically associated with or logically mapped or indexed to the respective associated data file(s) (content, key, and ticket). This related associated identification information can be either stored within (as a part of) the protected encrypted content, or provided as additional data stored separately from (but associated with) the respective protected encrypted content.
A data file of selected content is first converted and encrypted (and stored) in a proprietary file format by a trusted provider (with a production system) to provide for protection of the protected content information. The proprietary encrypted security format (referred to alternatively as ESF format or protected content format or encrypted content) provides a file protection methodology, infrastructure and architecture. This file structure can contain one or multiple named objects that each may mutually exclusively be encrypted (or not).
In a preferred embodiment, only a licensed user or a recipient device, one using a computing system running authorized licensed application software, can utilize the protected content in the proprietary file format. In one embodiment, usage of the respective content on the recipient device can be even further restricted in accordance with associated usage rights or permissions associated with each respective file of encrypted content [that is, either embedded or as a separate rights data file component of the respective encrypted content or as a separate associated data file (e.g., a ticket)], when that security level is enabled during production.
During the production of the protected content in the proprietary file format, the production system (also referred to as production subsystem) sets the permission (usage rights) level for each file that is selected (the selected file), the selected file is encrypted, to create a file of protected (encrypted) content. Alternatively, multiple files can be encrypted as a group, at a selected set level of permission usage rights. Protected content can be converted (and stored) at multiple usage levels.
Examples of levels of usage rights permission that can be set for a protected file (or group of files) include:
There are many in-between, and additional other, usage levels, providing for setting of a level for one of various combinations of permitted usages, including types of encryption, etc., that can be defined and implemented, in accordance with use requirements and design choices.
In one embodiment, the only level of usage restriction that the user of the recipient device can set is for content of the user of the recipient device, and only at the Basic Level. Alternatively, either Basic and Standard level encryptions can be performed for content of the recipient device. The provider/producer of protected content can set any level of usage restrictions and encryption. After distribution, the user of a recipient device cannot alter usage restrictions unless permitted by the usage rights permissions, and then, preferably, only more restrictively than the original (to maintain security).
Enhanced usage level encryption of content can only be encrypted by a trusted provider of the content that has production encryption application software to provide for content encryption, and setting of usage right permissions (restrictions), etc. The Enhanced usage restriction level in addition to content usage restrictions, as described above, provide for restricted access to the decrypted information, solely restricted to a particular specific one (or more) authorized remote device appliance(s). This is distinguished from the illustrated Basic and Standard Levels, where any licensed recipient device appliance can decrypt the Basic or Standard level encrypted content.
In accordance with a preferred embodiment of the present invention, usage rights permissions are associated with a specific encrypted content file by the provider/producer [such as by an indexed mapping using an ID for mapping the usage rights to the respective file (or files)], and are further utilized by the associated authorized application software on one or more authorized recipient devices, for controlling usage on a respective recipient device for respective associated protected encrypted content.
The various security levels of encryption can be applied to any type of content and/or object, and multiple encryption levels can be used within a given file or files or set of information.
Additionally, all encryption levels can optionally provide for notices (such as copyright notices), warning of the restricting of the use of the protected content as only for authorized licensed users.
An Enhanced Level Encryption option is preferable for maximum protection of content.
With the Enhanced level of encryption level security, the data to be protected is encrypted using a private key (an encryption key) (such as of a RSA public/private data key pair). This private key is provided by (generated or recalled from storage or otherwise provided) and kept by the trusted provider (or providers) only. Trusted providers should, preferably, be a very limited group of entities, trustworthy to maintain confidentiality as to the keys, the process and all related aspects.
The encryption of the selected content by the private data key allows the selected content data to (1) be verified as legitimate data and, (2) not be altered by another third party, other than the intended recipient device, since none of them have, or can generate this key. This encrypted protected data is unintelligible on any computer, CD-ROM or across any public network, without the public data key. The public data key (also referred to as encryption key, or production key, or production encryption key, or authorization key) is never shared beyond the trusted provider without the public data key itself first being encrypted. Only a recipient device computing system capable of decrypting the public data key is able to use the information.
The public data key is encrypted (such as by using a RSA symmetric authorization key, or other means) responsive to a unique identification. Preferably, the unique identification is at least in part generated responsive to unique identifying information generated from within a specific recipient device. Alternatively, the public data key can be provided by a particular recipient device (specific appliance).
For example, the unique ID can also be provided by generation of a unique ID via software in the recipient device (either via a pool of pre-assigned numbers, via a random number type generator combined with other data (such as time of day, date, etc.) The authorization key is confidential, and is maintained as a trade secret combination of a unique ID (also alternatively referred to as Appliance ID) generated by a particular recipient device appliance (such as generated based upon the unique network card MAC address, and/or other information). The recipient device software application obfuscates the process (such as in the binary code) and uses the unique identification (ID) to decrypt the respective public data key that was encrypted at the trusted provider for the respective content. For optimum security, the recipient device application software never reveals authorization keys to any user, and never stores (as decrypted) authorization keys in a file (except in an encrypted form), and minimizes the presence of any decrypted authorization key in RAM to a temporary transient presence. This provides security at multiple levels, (1) since the protected (encrypted) content cannot generally be used by just any computer to utilize protected content, (2) since knowledge is needed of the specifics and the methodology, (3) since the computing system must be running the proper application software and (4) since the computing system must be comprised of components to enable the application software generates the unique ID and other information utilized by the application software to generate and Appliance ID that is used to decrypt the encrypted public data key (that cannot otherwise be determined and thus, the protected (encrypted) data cannot be used).
In accordance with one aspect of the present invention, a system and methodology is provided for generating, or otherwise providing production encryption keys, and storing, and selectively re-utilizing the keys. In a preferred embodiment, a new encrypted production key public data key is created for every recipient device appliance (each with its own unique ID) within which the protected content data is to be selectively authorized for usage.
This allows great versatility, such as permitting mass production and distribution of selected protected content, such as by placing the encrypted (protected content) data to be placed on a CD-ROM or via Internet. Thereafter, the production key can be encrypted using a respective unique ID from a particular recipient device, and then, the relatively small encrypted public data keys (encrypted production keys) can be sent to the selected ones of the recipient devices. The encrypted production keys can only be used by the respective particular recipient device (specific recipient device that generated the respective unique ID utilized to encrypt the production encryption key), to authorize and be decrypted by the specific particular recipient device in providing for the permitted use of respective protected (encrypted) content on a selective basis.
In one embodiment, a selected file (or files) of content data is encrypted only once with a single production encryption (public data) key. This allows one encrypted public data key to always be utilized to generate a respective encrypted production key (such as utilizing a particular unique ID to generate an appliance key) for that respective composition. This simplifies the process, and is useful in many applications, such as providing server-based on-line distribution of protected content.
For maximum security, encrypted data is not stored in an unencrypted form on any hard disk file on any recipient device appliance. However, if desired (for a special situation, for example), special usage permissions can be set by an authorized trusted provider to permit this operation.
In a preferred embodiment, with regulated usage rights, there are two (2) inter-related portions of selected content data that are encrypted for each file, portion of file, or group of files. First, there is a first portion that is the actual original content data information (such as text, graphics, performance notation such as sheet music, data representative of a still or motion video or an audio image, an executable program file, or other data file) that is encrypted. The second portion of selected content data is associated with a respective first portion. The second portion defines permissions for the use of the respective associated first portion (the original content), (such as a permissions for viewing or printing viewable information). The first portion (original content) and the associated second portion (usage rights such as a ticket) can each be separately encrypted as two separate files, or encrypted together as one file. In either case, the encryption is done using the same production key. Then, at the recipient device appliance, both the first portion and the second portion must be decrypted using the same public data key (encrypted production key), (which is decrypted by the respective recipient device).
Only a trusted provider, (e.g., distributor/publisher) of the content can determine and set the usage rights permissions for associated encrypted (protected) content. Usage rights can be set according to multiple options. There can be a preset minimum usage (e.g., a default level of none to little rights, hanging up to an unrestricted level of all rights), selectively set based upon criteria or related to a specific transaction [such as transaction data (e.g., a credit card related transaction to purchase usage rights).
User level authorization of appliances (such as hierarchical-based levels), (e.g., multiple levels, ranging from maximum usage rights to minimum (or more restricted (relatively)) usage rights can be set to be based upon relative rank or importance of respective appliances (and their respective users). For example, a conductor is least restricted (having the most permissions), with each subsequent user group at a lesser usage rights level vis-à-vis the previous (higher) user. After conductor, the next level for a symphony would be concertmaster; then, principals for each instrument, and the next level would be lateral players (e.g., all violins, all cellos, etc.). This hierarchical rights levels also apply to other types of user groups (e.g., a school, class).
Permissions for usage rights can be (1) regulated either by type of usage for any authorized recipient device appliance, or (2) regulated so as to only work on a particular specific appliance (or multiple particular specific appliances), and then further regulated to selectively control type of usage on a respective specific recipient device. There are many alternative options for usage permissions.
Examples include:
Permissions can also include other associated data, such as creator of the permissions, password, and modification of the permissions rights.
Permissions can also be set to limit usage to a defined number of times. Many options exist. For example, in one embodiment, during production of the encrypted content and associated usage rights permission, usage rights are set in the most restrictive state, in the absence of any explicit permissions. Many other options also can be selected, based upon design criteria and requirements of the trusted provider.
In a preferred embodiment, permissions data in the Enhanced level encryption model are encrypted twice, first, with the private data key, and then with the authorization key. Only the trusted provider/producer of the encrypted content is capable of performing the encryption of the production key (only it has the private data key). By encrypting the production key utilizing a unique Appliance ID generated at a particular specific recipient device appliance, only that particular specific recipient device appliance can decrypt or use the encrypted content, or encrypted permission associated with and related to the protected content. The Enhanced security level permissions cannot be changed by the user.
Permissions can be provided to the user in one complete package (integrated or otherwise combined as a single file or group of files) or in multiple packages (that is, the encrypted content file is separate from the associated encrypted usage rights file, and the encrypted content file is provided separately from the encrypted permission). Where encrypted content and associated encrypted usage rights permissions are provided as separate files, there are multiple options that can be selected. The encrypted content can be (1) unusable on a recipient device without the associated separate encrypted permission file, or (2) usable in a recipient device in a minimal manner of usage without the associated usage rights file, or (3) usable to a predefined level of usage (from minimal to all options enable) on a recipient device without (unless it is present) the associated encrypted permission file, or (4) usable at whatever level of usage the respective associated encrypted usage rights permission file (or ticket) provides for, but only as per that level. (Many other options can be chosen. Again, the choice is again one of design options.) The various individual permissions can be established and set by a trusted provider, at any time concurrent with or subsequent to the encryption of the respective protected (encrypted) content. However, preferably, only a trusted provider can generate related associated additional files (or tickets or packages) of permissions granting a broadening of usage rights for a previously encrypted content.
In accordance with a defined process/methodology for secure distribution, the recipient device user provides the provider subsystem with the recipient device's unique ID (and optionally other information) such as by providing appliance data (or other methods such as when unique ID changes have been made in the field). The trusted provider then generates the encrypted public data keys (e.g., encrypted production key) and encrypted permission packages (e.g., encrypted ticket) for a user. These can be sent to the recipient device with increased security, since a third party's use of this encrypted information requires a licensed application software program executing on a recipient device, and must be compatible with the trusted provider technology. And in the “specific appliance only” embodiment, the decryption process further requires specific hardware (e.g. a particular specific recipient device) to generate the particular recipient device's unique ID.
The encrypted public data key is intended solely for a respective particular specific recipient device appliance, and is not usable on any other appliance. This provides for flexibility with security. For example, the encrypted public key may be stored on (but is unusable on) a separate appliance for backup or an intermediate device used in the transmission of the key to the intended particular specific appliance. When a single file (or files) of encrypted content is authorized for separate permitted usage on multiple recipient device appliances, each appliance's key (for all of the multiple recipient devices) is stored together as one file of all the keys, as associated with the respective encrypted content file. Even though only one of those keys is valid for usage on each of the respective ones of the particular specific recipient device appliance, without compromising the security of the keys for the other appliances. Thus, only one of those specific multiple recipient devices (that can decrypt one of the keys) can utilize that one respective encrypted content file, but not any other recipient device. Further, each recipient device can only utilize the encrypted production keys explicitly created specifically for it.
Key refers to a symbol or sequence of symbols or a data file, (or electrical or mathematical or mechanical or numerical correlates of symbols) (or mathematical data processing of data files) such as utilized by an encryption engine or other keyed conversion logic [and the corresponding decryption engine] in order to encrypt or decrypt any other data files (such as text).
Appliance is a term used as an alternative term for a computer system running application software that comprises a recipient device.
Recipient Device refers to any computer system executing (or running) application software (or otherwise), for getting appliance data from within the computer system for generating an Appliance ID for the recipient device, which is provided and used for encrypting a production key that was utilized for encrypting respective encrypted content, to provide an encrypted production key. Only the recipient device generating the Appliance ID can thereafter, decrypt the encrypted production key to utilize the respective decrypted content locally at a recipient device. In accordance with one aspect of the present invention, multiple encrypted production keys can be associated with encrypted content to permit usage of that content by a plurality of authorized recipient devices. Alternatively, a fixed encrypted production key can be used to permit all recipient devices running the correct application software, to use the encrypted content in a preferred embodiment usage is as per defined usage rights (whether Read-Only, Read/Annotate, Network, or other) for regulating use of encrypted content.
Master Production Key refers to a master key that allows a document to be encrypted (or decrypted) regardless of what appliance is trying to open the document. This is useful for a production system to test, modify or re-authorize rights for encrypted content. Only a few production utilities are provided that can open a document with this key. The master production keys are never distributed to a consumer.
Document Production (Encryption) Key (or Appliance Key) is a key that is utilized to provide for encryption (and decryption) by a specific recipient device appliance, and provides control for regulating usage of respective associated content [such as to open a particular (or group of) documents]. A group of documents can share the same document production key when designated for the same recipient device (or devices).
Appliance Authorization refers to a set of information utilized to provide for a unique identification and authorization, such as an appliance key such as generated from fixed data identifying the appliance (and preferably with an added password level of protection for use of the application software), and/or a program level for the respective application software program (feature set levels (e.g., Reader Only; Read-Annotate; Print; Export), and preferably also serial number (user identification) that authorizes the program to run at no more than a specified feature set (and preferably only on a specified appliance). Alternatively, some are provided as a non-variable stand-alone product and is not capable of running all the features authorized. For example, a reduced feature reader product, such as Acrobat Reader from Adobe Inc., or the eSReader from e-Stand, Inc., has very limited capabilities and doesn't include the fullest feature set but will only run with the limited feature set as fixed to be allowed.
Original content refers to any one or more of:
Key Production, usage, and retention strategy can be varied. For example keys can be time-stamped or otherwise designated with a limited life. Alternatively, all keys can be generally valid indefinitely (forever); however, in this case, the Appliance Authorization can be limited to a specific date as specified by the computer's system clock.
Appliance ID refers to a unique identifier associated with, and preferably generated by, a specific appliance. This unique identifier is preferably calculated on-the-fly [in the specific appliance (recipient device) executing respective authorized application software thereupon], based on unique features of the specific appliance.
A Ticket ID refers to a unique identifier associated with a specific ticket. This identifier is created when the ticket is generated, and is utilized in identifying and locating the respective specific ticket (e.g., for indexing, mapping, cataloging, and/or providing linking ID to associate the respective ticket with other components or content or files).
In a preferred embodiment, Document Keys are generated from the Production Keys and Appliance ID. For example, the respective production (encryption) key utilized for respective encrypted content is encrypted utilizing the Appliance ID as a key input to the encryption logic, (needed for both the encryption and the subsequent associated decryption) to generate a Document Key [comprised of the production key encrypted using the specific Appliance ID as an input]. For example, document keys are generated upon the sale of a document to a customer, who either supplies their Appliance ID or which is a previously stored Appliance ID (historically by customer ID on file), such as a result of a previous authorization or previous document (of selected encrypted content) purchase. The Document Key is required to unlock [using the respective application software within the recipient device to generate a generated Appliance ID (such as by access to the recipient device computing hardware and software)]. The application software applies the decrypted production key which is utilized thereafter in decrypting the encrypted content within the specific respective recipient device appliance and for controlled regulated use of the encrypted content in a decrypted (unencrypted content) form, by the specific respective recipient device.
As illustrated in FIG. 1, data rights management system ( 10 ) is comprised of a provider encryption services subsystem ( 104 ) providing outputs of encrypted content ( 120 ), and encrypted production key ( 158 ). The recipient device has control decryption logic (executed in the application software) generates an Appliance ID, and preferably jumbles the Appliance ID (such as utilizing a defined hash) to output a jumbled Appliance ID ( 157 ) production subsystem 104 .
The production system utilizes the Appliance ID (if necessary after first un-jumbling the jumbled Appliance ID) and encrypts the production encryption key responsive to the Appliance ID to generate an encrypted production encryption key (also called an encrypted production key).
Jumbling refers to processing of content to be communicated in a secure method. Jumbling can be accomplished in numerous alternative ways, such as use of secure socket layer (SSL), or hashing, encryption, etc. (For additional background, also see Applied Cryptography by Bruce Schneier; or other texts).
A jumble operation refers to a form of encryption used to transmit data between systems. This may be an encryption method using a predefined key on original transmitted data and outputs to encrypted transmitted data. It could also be an encryption method using a negotiated temporary key between the jumble and unjumble operations.
An unjumble operation is a decryption method that inputs encrypted transmitted data and outputs a copy of original transmitted data. The decryption method and key is selected to be complimentary to the encryption method used in the jumble operation.
For additional security, the outputs are each jumbled and are unjumbled by an authorized recipient device. The jumbling (and respective un-jumbling) is optional, and while adding another level of security, is not a requirement of (or necessary to use of) the present invention. As illustrated in FIG. 1, the encrypted content and encrypted production encryption key are jumbled to provide jumbled outputs of a jumbled encrypted content ( 120 J) and a jumbled encrypted production key ( 158 T). These jumbled outputs ( 120 J and 158 T) are coupled to a recipient device. The jumbled outputs are coupled to respective inputs 220 and 188 of the consumer decryption services subsystem 204 [such as a user's computer appliance (recipient device). The provider subsystem 104 provides a host computing subsystem comprising a processor, storage, and running respective production application software to provide for operation of the provider subsystem 104 . In a preferred embodiment, the provider subsystem 104 and consumer subsystem 204 are each further comprised of a communications interface for coupling communications therebetween. The consumer decryption services subsystem 204 (e.g., a recipient device) provides a computing subsystem running compatible application software to provide for selective viewing, annotating, networking, exporting, running as an executable application program, and saving, in accordance with respective associated defined usage rights. The consumer subsystem 204 provides an output of the Appliance ID ( 187 ) [e.g., preferably in one embodiment jumbled such as by utilizing an encryption to jumble the internally generated Appliance ID]. The consumer can call (phone), FAX, email, or directly couple via computer, to provide an output of the Appliance ID ( 187 ) to the input ( 157 ) of the provider encryption services subsystem ( 104 ). The provider encryption services subsystem ( 104 ) utilizes the Appliance ID input ( 157 ) to encrypt the production encryption key which was utilized to encrypt respective associated content (if appropriate, first un-jumbling the jumbled Appliance ID), and the encrypted production key is coupled for output from the provider subsystem 104 (preferably jumbled for transmission) [illustrated as coupled to input 188 of the consumer services subsystem 204 ]. The encrypted content output ( 120 ) is jumbled and provided as jumbled encrypted content output ( 120 J), and is provided from the provider subsystem ( 104 ) and is coupled to an input ( 220 ) of the consumer decryption services subsystem ( 204 ). The consumer decryption services subsystem ( 204 ) utilizes a jumble decryption to un-jumble the jumbled encrypted production key and to generate an encrypted production key copy, and then utilizes its internally generated Appliance ID to decrypt the encrypted production key copy, and then utilizes the decrypted production key to decrypt the associated respective encrypted content, to generate an output ( 200 ) of unencrypted content that is stored in the recipient device in its unencrypted form for usage by the application software of the recipient device in accordance with the respective associated defined usage rights. Preferably, storage of the unencrypted content in the memory of the recipient device of the consumer subsystem is only temporarily stored as unencrypted, responsive to the application software, so as to maximize security.
Referring to FIG. 2, an alternative embodiment to that of FIG. 1 is illustrated, showing the encrypted content and the encrypted production key being combined by the production system ( 104 ) as a single combined output, prior to communications to an external system, or otherwise coupled to a respective consumer subsystem ( 204 ) (recipient device). As illustrated in FIG. 2, all communications between the provider subsystem ( 104 ) and consumer subsystem ( 204 ) is jumbled, to add an extra level of security. This is optional; it is a design option [to add jumbling (or not)]. As illustrated in FIG. 2, the provider encryption services subsystem ( 104 ) receives the (jumbled) Appliance ID ( 187 ) from the recipient device ( 204 ), coupled to production subsystem ( 104 ) as an input ( 157 ) and the jumbled Appliance ID is dejumbled in the recipient device and is utilized to generate an Appliance ID (also referred to as an Appliance ID copy). The production system ( 104 ) utilizes the Appliance ID copy to encrypt the respective associated production key that was utilized to encrypt the selected original content to create the respective encrypted content, responsive to the Appliance ID copy. The provider encryption services subsystem ( 104 ) then provides an output of the encrypted production key ( 158 ) which is combined with the encrypted content output ( 120 ) utilizing combining logic 311 to provide a combined output ( 310 ) of the encrypted content 120 with the encrypted production key ( 158 ). This combined output ( 310 ) is preferably jumbled prior to output from the production subsystem ( 104 ) to any external system. The combined output ( 310 ) is then coupled as an input to separation logic ( 312 ) of the consumer decryption services subsystem (recipient device) ( 204 ).
The subsystem ( 204 ) provides a computing subsystem with a processor, memory, and display, and runs (executes) respective application software, to provide a recipient device appliance for a consumer to use to permit allowed usage of encrypted content. The consumer subsystem ( 204 ) provides separation logic ( 312 ) for separating the encrypted content and the encrypted production key from the combined output ( 311 ). (If necessary, the jumbled combined input is first unjumbled.) The consumer decryption services subsystem ( 204 ) then utilizes the internally generated Appliance ID to decrypt the (unjumbled) encrypted production key to generate a decrypted production key that is utilized to decrypt the encrypted content to provide an output of unencrypted content ( 200 ). The unencrypted content ( 200 ) is stored locally in the recipient device (preferably, temporarily) only during and as needed for authorized usage (e.g., viewing, annotating, networking, saving, exporting) of the decrypted content in accordance with associated usage rights (if any) for the respective selected content.
In one embodiment, for greater security, communications between the production subsystem ( 104 ) and consumer subsystem ( 204 ) are jumbled, (and then unjumbled by the respective other one of the consumer subsystem ( 204 ) and production subsystem ( 104 ), respectively), (such as Appliance ID, encrypted production key, etc.). In an alternative embodiment, where circumstances are correct, no jumbling may be needed, so it is not provided, and the present invention works equally well. The jumbling (and unjumbling) adds another layer of security and its use is one of design choice.
Furthermore, encrypted content and Document IDs can be hosted on a host system (or saved as “groupings” or “sets” on CD ROMs) to be provided to one or more consumer subsystems ( 204 ). In both these scenarios, a consumer can simply provide the Appliance ID and Document IDs for the desired selected encrypted content, and the host system can locate the selected content, and the associated respective production key used to encrypt the respective content as per the Document IDs, and encrypts the respective production key responsive to the provided Appliance ID and Document IDs received from the consumer, to generate and provide a document key that is provided to the consumer subsystem ( 204 ). The consumer system ( 204 ) then generates an Appliance ID locally and uses it to decrypt the document key to get to the decrypted production key needed to decrypt the selected content (and, if appropriate, the respective associated encrypted ticket.).
The discussion of the illustrated embodiments discussed so far herein have been directed to communications of single files and single keys.
In accordance with another illustrated embodiment of the present invention, in addition to communication and usage of single files and single keys, or multiple files encrypted with a same single key, alternatively, multiple ones of unencrypted initial content files can each be encrypted with a different production key. The encrypted production keys and encrypted content can be sent separately and individually, or combined and together.
The same production key can be used for all of the multiple unencrypted initial content files, or there can be multiple production keys used for encryption, and with some of the keys used on more than one unencrypted initial content file.
In accordance with another aspect of the present invention, a production ID is associated with every production key. This production ID should be relatively unique and the only relationship to production key is that there is a one-to-one relationship. The production ID can be, for example, a random number, current time, random sequence of characters or a sequentially generated number that increases every time a new production key is generated, or other items, or a combination of these. The production ID can be used as an index to find a production key for a respective file of associated encrypted content. In this case, the production ID is transmitted along with the encrypted initial content to the recipient device (and also subsequently with the encrypted production key). Thereafter, the recipient device can be sent a respective production ID to a host [e.g., production subsystem ( 104 )], and the production subsystem ( 104 ) locates the associated respective production key for the respective production ID, and encrypts the respective production key and sends the encrypted production key to the respective recipient device (e.g., such as encrypted to be appliance specific responsive to the respective Appliance ID).
In accordance with one embodiment, the production ID associated with encrypted initial content is verified prior to use, and is compared to the respective production ID associated with an encrypted production key. If the production ID's match, then the respective encrypted production key can be used with the respective encrypted initial content to obtain the unencrypted initial content on the client machine (recipient device).
Additionally, or alternatively, to the production ID, the Appliance ID may also be associated with the encrypted production key. This allows the client (e.g., the recipient device or system) to effectively ignore encrypted production keys that are not meant for that client recipient device, by comparing the client's Appliance ID with the respective Appliance ID associated with each of the respective ones of encrypted production keys.
In one embodiment, the encrypted production keys are transmitted separately from the encrypted content. In an alternate embodiment, the production key and encrypted initial content are transmitted together from server production subsystem ( 104 ) to client [recipient device (consumer subsystem ( 204 )]. In either case, there is a chance that the production ID or Appliance ID is not associated with the encrypted production key or the production ID is not associated with the encrypted initial content. The client recipient device ( 204 ) does not always know which encrypted production key goes with which encrypted initial content on which client. In this case, the client system ( 204 ) can still create the unencrypted initial content but the process will take longer.
There are many alternative ways to find the correct production key. For example, the client system ( 204 ) can try using every encrypted production key that it has available to decrypt the encrypted initial content. When the client determines the encrypted initial content is correct, it stops looking.
Alternatively, there may be times when the client recipient device system ( 204 ) does not keep track of which document key is to be used for a particular document on a particular appliance. In this case, the client system ( 204 ) needs to check all the keys on the recipient device ( 204 ) for location of the correct particular document key. In this case, the client recipient device ( 204 ) finds the correct document key by decrypting the respective encrypted content with each respective production key, to attempt to generate the correct decrypted content for a selection, and then check the respective unencrypted initial content for correctness.
The recipient device ( 204 ) (client's) check for correctness of the respective unencrypted initial content requires that the client ( 204 ) has some knowledge of some aspect of the correct decrypted content. This could be a number of things. For example, the first part of the decrypted content can have a fixed set of initial characters (or a checksum on the content) or that the decrypted content f