Self-protecting documents

ES 2 248 952 T3

DESCRIPTION

Self-protected documents.

The invention relates to document rights management, and more specifically, to a self-protective document scheme that allows the protection of electronic documents without the need for additional software or hardware support for protection.

One of the most important problems preventing the wide distribution of digital documents through electronic commerce is the current lack of protection of the intellectual property rights of content owners during the distribution and use of digital documents. Efforts to solve this problem have been called “Intellectual Property Rights Management” (“IPRM”), “Digital Property Rights Management” (“DPRM”), “Intellectual Property Management” (“IPM”), “ Rights Management ”(“ AM ”), and“ Electronic Copyright Management ”(“ ECM ”).

A document, as the term is used herein, is any unit of information subject to distribution or transfer, including, but not limited to, correspondence, books, magazines, newspapers, newspapers, other documents, software, photographs and other images. , audio and video clips, and other multimedia presentations. A document can be made in paper form, as digital data on a storage medium, or in any other known manner on various media.

In the world of printed documents, the work created by an author is generally sent to an editor, who formats and prints numerous copies of the work. The items are subsequently shipped by a distributor to bookstores or other retail stores, where end users can purchase the items.

Although the low quality of copies and the high cost of distributing printed material have served as deterrents to illegal copying of most printed documents, unprotected electronic documents are much easier to copy, modify and redistribute. Therefore, some method of protecting electronic documents is needed to make it more difficult to copy them illegally. This will serve as a deterrent to copying, although it is still possible, for example, to make paper copies of printed documents and duplicate them in the old style.

With paper documents, there is an additional step of digitizing the document before it can be redistributed electronically; this serves as a deterrent. Unfortunately, it has been widely recognized that there is no viable way to prevent people from making unauthorized distributions of electronic documents within current general-purpose computing and communications systems such as personal computers, workstations, and other connected devices. local area networks (LANs), intranets, and the Internet. Many attempts to provide hardware-based solutions to prevent unauthorized copying have been shown to be unsuccessful.

Two basic schemes have been used to try to solve the document protection problem: secure containers and trusted systems.

A "secure container" (or simply an encrypted document) offers a way to keep the document's content encrypted until a number of authorization conditions are met and some copyright terms are met (eg pay-as-you-go). After verifying the various conditions and terms with the document provider, the document is delivered to the user in unencrypted form. Commercial products such as IBM's Cryptolopes and InterTrust's Digiboxes fall into this category. Clearly, the secure container approach provides a solution to protect the document during distribution through insecure channels, but it does not provide any mechanism to prevent legitimate users from obtaining the unencrypted document and then using and redistributing it in violation of the user's intellectual property. content owner.

Cryptographic mechanisms are typically used to encrypt (or "encrypt") documents that are then publicly distributed and stored, and ultimately decrypted privately by authorized users. This provides a basic form of protection during distribution of the document from a document dispenser to a desired user over a public network, as well as during storage of the document on an insecure medium.

In the "trust system" approach, the entire system is responsible for preventing unauthorized use and distribution of the document. Creating a trusted system generally involves introducing new hardware such as a secure processor, secure storage, and secure rendering devices. This also requires that all software applications running on trusted systems are certified to be trusted. Although building tamper-proof trusted systems is still a real challenge for today's technologies, current market trends suggest that open and trusted systems, such as PCs and workstations, will be the dominant systems used to access copyrighted documents. In this sense, current computing environments, such as PCs and workstations, equipped with popular operating systems (for example, Windows and UNIX) and rendering applications (for example, Microsoft Word) are not trusted systems and cannot be done. trustworthy without significantly altering your architectures.

Therefore, although some trusted components can be deployed, you must continue to trust

ES 2 248 952 T3 in various unknown and untrusted elements and systems. In such systems, although they are expected to be secure, unanticipated errors and weaknesses are frequently found and exploited.

There are numerous issues in Rights Management: authentication, authorization, accounting, payment and financial compensation, specification of rights, verification of rights, enforcement of rights, and document protection. Document protection is a particularly important issue. After a user has paid the content owner's fees and has been allowed to perform a particular operation with a document (for example, printing, screen viewing, music playback, or software running), the document is presumably in language not encrypted or not encrypted. Stated in simple terms, the problem with document protection is preventing the content owner's rights from being compromised when the document is in its most vulnerable state: stored, in an unencrypted state, on a machine within the user's control. Even when documents are sent securely (typically in encrypted form) from a dispenser to the user, they must be rendered to a presentation data form before the user can view or otherwise manipulate the document. Therefore, to achieve the highest level of protection, it is important to protect the content of the document as much as possible, while revealing it to the user at a later stage and in a form that is difficult to usefully retrieve.

In known approaches to electronic document distribution that employ encryption, an encrypted document is made in several separate steps. First: the encrypted document is received by the user. Second: the user uses his private key (in a public key cryptosystem) to decrypt the data and derive the unencrypted content of the document. Finally, the unencrypted content is then passed to a rendering application, which translates the computer-readable document into the finished document, for viewing on the user's computer screen or for printing a paper copy. Unencrypted content requires rendering because, in most cases, the rendering application is a third-party product (such as Microsoft Word or Adobe Acrobat Reader) that requires the input document to be in a specific form. It should then be appreciated that between the second and third steps the previously protected document is vulnerable. It has been decrypted, but is still stored in unencrypted electronic form on the user's computer. If the user is careless or otherwise motivated to minimize fees, the document can be easily redistributed without acquiring the necessary permissions from the content owner.

Accordingly, it would be beneficial to provide an electronic document distribution scheme that minimizes the disadvantages of known systems.

WO 98/11690 describes a system and method of self-decrypting digital information including a digital information structure that includes an encrypted data file (54), an unwrapping procedure (50) for identifying positions of other stored portions of the digital information, and for extract a program that will communicate with the operating system, and a driver application (52), so a function of the driver application (52) is to catch all calls from the operating system for file access.

The object of the present invention is to provide a scheme that is capable of preventing users from obtaining a useful form of an electronically distributed document during the decryption and / or rendering processes.

This object is achieved by the subject matter of independent claims 1, 9 and 11.

Preferred embodiments are defined in the dependent claims.

The present self-protective document ("SPD") is not subject to the above-noted disadvantages of the prior art. By combining an encrypted document with a series of permissions and an executable code segment that includes most of the software required to extract and use the encrypted document, the self-protecting document performs document content protection without the need for additional hardware and software. .

The SPD system is broken down between a content creator (analogous to the author and publisher of the traditional model) and a content distributor. The author / publisher creates the original document, and decides what rights are authorized. The distributor subsequently personalizes the document for use by multiple users, ensuring through personalization that users do not exceed the permissions they have acquired.

On the user system, the self-protective document is decrypted at the last possible moment. In one embodiment of the invention, various rendering facilities are also provided within the SPD, so that the use of the SPD does not have to be based on an external application that might not be trusted (and that could invite unauthorized use). In an alternative embodiment, interfaces and protocols are specified for a third-party rendering application to interact with the SPD to perform trusted rendering.

In one embodiment of the invention, the encrypted document is decrypted by the user system by simultaneously "polarizing" it with a key that depends, at least in part, on the state of the user system. Polarization may be cryptographically less secure than encryption used for distribution, but it serves to deter occasional copying. In this embodiment, depolarization is carried out during or after the rendering process, to render any intermediate form of the document essentially unusable.

ES 2 248 952 T3

Figure 1 is a high-level block diagram representing a model for the commercial creation and distribution of electronic documents in secure or insecure environments.

Figure 2 is a flow chart illustrating decryption of protected electronic documents in accordance with the art.

Figure 3 is a flow chart illustrating decryption of protected electronic documents according to a simple embodiment of the invention.

Figure 4 is a flow chart illustrating decryption of protected electronic documents in accordance with a preferred embodiment of the invention.

Figure 5 is a functional block diagram illustrating data structures present in a self-protective document according to one embodiment of the invention.

Figure 6 is a flow chart illustrating the creation and personalization of a self-protective document in accordance with one embodiment of the invention.

Figure 7 is a flow chart, from the perspective of the user, illustrating the actions taken when handling and using a self-protective document according to the invention.

Figure 8 is a graph illustrating various possible pathways between an encrypted and unrepresented document and decrypted and rendered presentation data.

Figure 9 is a flow chart illustrating a polarization process according to the invention in which the document format information remains in the unencrypted state for rendering.

Figure 1 represents a high-level functional model for a system for the electronic distribution of documents, which as defined above, can include correspondence, books, magazines, newspapers, newspapers, other documents, software, audio and video clips, and other multimedia presentations.

An author (or publisher) 110 creates original document content 112 and passes it to a distributor 114 for distribution. Although it is contemplated that the author can also distribute documents directly, without the participation of another party as a distributor, the division of tasks outlined in figure 1 is more efficient, because it allows the author / editor 110 to concentrate on the creation of the content, and not on the the mechanical and mundane functions assumed by the distributor 114. Furthermore, such a division would allow distributor 114 to realize economies of scale by association with a number of authors and publishers (including the illustrated author / publisher 110).

Distributor 114 then passes the modified content 116 to a user 118. In a typical electronic distribution model, the modified content 116 represents an encrypted version of the original content 112; distributor 114 encrypts original content 112 with user 118's public key, and modified content 116 is personalized only for single user 118. User 118 is then able to use his private key to decrypt modified content 116 and view original content 112.

User 118 passes to distributor 114 a payment 120 for content 112 via clearinghouse 122. Clearinghouse 122 collects requests from user 118 and other users who wish to view a particular document. The clearinghouse 122 also collects payment information, such as debit transactions, credit card transactions, or other known electronic payment schemes, and sends the collected user payments as a payment batch 124 to the distributor 114. Naturally, Clearinghouse 122 is expected to withhold a portion of payment from user 120. In turn, distributor 114 holds a portion of payment batch 124 and sends a payment 126 (including copyright) to author and publisher 110. In one embodiment of this scheme, distributor 114 waits for a group of user requests for a single document before sending anything. When this is done, a single document with modified content 116 can be generated for decryption by all requesting users. This technique is known in the art.

Meanwhile, each time user 118 requests (or uses) a document, an accounting message 128 is sent to an audit server 130. The audit server 130 ensures that each request made by user 118 matches a document sent by the distributor 114; accounting information 131 is received by audit server 130 directly from dispatcher 114. Inconsistencies are transmitted through a report 132 to the clearing house 122, which can then adjust the payment batches 124 made to the distributor 114. This accounting scheme is present to reduce the possibility of fraud in this electronic document distribution model, as well. how to handle time-dependent use permits that may result in charges varying, depending on the duration or extent of use.

The previous model for electronic commerce of documents, depicted in Figure 1, is in common use today. As will be shown in detail below, it is equally applicable to the system and method discussed here for the distribution of self-protective documents.

ES 2 248 952 T3

Turning now to FIG. 2, the steps performed by user 118 (FIG. 1) in a prior art system for electronic document distribution are depicted. As explained above, cryptographic mechanisms are typically used to encrypt documents. The encrypted documents are later distributed and stored publicly and decrypted privately by authorized users. This provides a basic form of protection during document distribution from a document dispenser to a desired user over a public network, as well as during document storage on an insecure medium.

Initially, an encrypted document 210 is received by user 118 and passed to a decryption step 212. As is known in the art, decryption step 212 receives the user's private key 118, which is stored locally on the user's computer. user or is entered by the user when necessary. Document 210 is decrypted, leading to decryption of content 216 similar or identical to original content 112 (Figure 1).

The unencrypted content 216 is passed to a rendering application 218, which constructs presentation data 220, or a usable version of the original document content 112. In typical systems of this type, presentation data 220 is data immediately suitable for display. on a video screen, for printing as a hard copy, or for other use depending on the type of document.

As explained above, the document is vulnerable on systems like this one. The unencrypted content 216 may be copied, stored, or passed on to other users without the knowledge or consent of the distributor 114 or the author / publisher 110. Even a legitimate user may be tempted to minimize license fees by capturing the document in the non-state. encryption to redistribute it and use it at will, without paying the intellectual property of the content owners. As explained above, the present invention addresses a scheme to prevent such a user from obtaining a useful form of the document during the rendering process on the user system.

Accordingly, the system and method of the present invention set forth an alternative scheme for handling encrypted documents on user system 118. A simple embodiment of this scheme is illustrated in Figure 3.

Figure 3 is similar to Figure 2, in that an encrypted document 310 is passed to a decryption step 312 (using a private key 314) and a rendering application 316, resulting in presentation data 318. However, a protective wrap 320 offers an additional layer of protection. Protective envelope 320 allows document 310 to be decrypted and rendered without leaving unencrypted content (as in unencrypted content 216 of Figure 2) available for interception. This is accomplished by including decryption and rendering elements within document 310, as will be described below with reference to FIG. 5. The included decryption and rendering elements are adapted to limit user interaction with the SPD, prohibiting some operations (such as saving the document or performing cut and paste operations) depending on the user's permissions.

Figure 4 is a more sophisticated version. The scheme of Figure 4 includes an intermediate "polarization" step adapted to fix the document after it has been decrypted but before rendering. First, the content of the encrypted document 410 is passed to a polarizer 412. The polarizer 412 receives the user's private key 414 and, via a decryption step 416, decrypts the content of the document 410. Simultaneously, the polarizer 412 receives a polarization key 418 from the user system.

This polarization key 418 is used by the polarizer 412 to transform the document into a version that has polarized content 420. All these operations can take place in the open, without any kind of protective mechanism, provided that the polarizer 412 does not store a unencrypted version of the document between decryption and polarization.

In one embodiment of the invention, bias key 418 represents a combination of data items taken from the internal state of the user's system, such as the date and time of day, the time elapsed since the last keystroke, speed, and processor serial number, and any other information that can be derived repeatably from the user system. It is useful to include some time-derived information in the polarization key 418 so that interception and capture of the polarized content 420 is not useful. Further rendering of the polarized document would not be possible as the system time would have changed too much.

Then, back inside a protective envelope 422, the polarized content 420 is passed to a rendering application 424. As explained above, typical rendering applications are third party applications such as Microsoft Word or Adobe Acrobat Reader. However, it is likely that such external rendering applications will not be able to process the polarized content 420, since the content, format codes, and other keys used by the renderer will have been muddled in the polarization process.

Therefore, the rendering application 424 must be commutative (or at least fault tolerant), or it must receive polarized content 420 that is largely complete and actionable by the application. This last possibility will be explained below, in connection with figure 9.

ES 2 248 952 T3

The output of the rendering application is polarized presentation data 426, which has been formatted by the rendering application 424, but is still polarized, and therefore not readable by the user. The polarized presentation data 426 is passed to a depolarizer 428, which receives the polarization key 418 and restores the original shape of the document as presentation data 430. In one embodiment of the invention, the depolarization function is combined with the rendering or display function. In this case, the polarized display data 426 is received directly by a display device, which may be separate from the user system and receive data over a communication channel.

The creation of the polarization key 418, the rendering application 418, and the depolarization step 428 are all elements of the protective envelope 422; These are tamper resistant program items. It is contemplated that all of the computational steps that take place within the protective shell 422 use local data only, and do not store temporary data on any globally accessible storage medium or memory area; only explicit results will be exported from protective envelope 422. This approach will prevent users from easily modifying operating system entry points or fraud with system resources to intercept and use intermediate data.

It should be noted that the display data 430 of FIG. 4, in alternative embodiments of the invention, may be device independent or device dependent. In the case of device independence, additional processing by a device driver (such as a display driver or a printer driver) is typically required to complete the rendering process. In the currently preferred device-dependent case, device-specific modifications have already been made to the presentation data (in the rendering application 424 or the depolarization step 428), and the presentation data 430 can be sent directly to the device. desired output.

The decryption schemes described above with reference to Figures 3 and 4 are enabled by a single document structure, which is represented in detail in Figure 5. As explained above, some operations performed by the system and method of the invention require trusted components. One way to ensure that some unmodified code is being used to effect trust aspects of the invention is to provide the code along with the documents. The various components of a self-protective document according to the invention are illustrated in Figure 5.

The invention approaches the document protection problem without any assumptions in the presence of trusted hardware units or software modules in the user system. This is done by enhancing a document so that it is an active meta-document object. The owners of the content (that is, authors or publishers) attach to a document rights that specify the types of uses, necessary authorizations and associated rights, and a software module that executes the permissions granted to the user. This combination of the document, the associated rights, and the attached software modules that enforce the rights are the self-protective document ("SPD") of the invention. A self-protective document prevents unauthorized and uncontrolled use and distribution of the document, thereby protecting the rights of content owners.

Self-protecting document 510 includes three main functional segments: an executable code segment 512 contains some portions of executable code necessary to allow the user to use the encrypted document; a rights and permissions segment 514 contains data structures representative of the various levels of access to be allowed to various users; and a content segment 516 includes the encrypted content 116 (FIG. 1) that the user wishes to view.

In a preferred embodiment of the invention, the content segment 516 of the SPD 510 includes three subsections: document meta information 518 (including, but not limited to, the title, format, and revision date of the document), rights information 520 (such as as a copyright notice attached to the text, as well as information on rights and permissions), and the protected content 520 (the encrypted document itself).

In one embodiment of the invention, rights and permissions segment 514 includes information about the specific rights of each authorized user. A list of terms and conditions can be attached to each right of use. For example, user John Doe may have the right to view a particular document and print it twice, at a cost of $ 10. In this case, rights and permissions segment 514 identifies John Doe, associates two rights with him (the viewing right and the printing right), and specifies the terms and conditions including price ($ 10) and a limitation on printing. (twice). Rights and permissions segment 514 may also include information about other users.

In an alternative embodiment, rights and permissions segment 514 includes only a link to external information specifying information about rights. In this case, the actual rights and permissions are stored elsewhere, for example on a network permission server, which must be queried each time the document is to be used. This approach provides the advantage that rights and permissions can be dynamically updated by content owners. For example, the price per view can be increased, or user rights can be terminated if unauthorized use has been detected.

In any scenario, the rights and permissions segment 514 is cryptographically signed (by methods

ES 2 248 952 T3 known in the art) to avoid manipulation with the specified rights and permissions; it can also be encrypted to prevent the user from directly viewing their own rights and permissions and those of others.

The executable code segment 512, also called the "Control SPD", also contains several subsections, each of which includes a software module at least partially within the executable code segment. In one embodiment of the invention, the Java programming language is used for SPD Control; however, it is contemplated that any platform-dependent or platform-specific, interpreted or compiled language may be used in an implementation of this invention.

A rights enforcer 524 is present to verify the identity of the user, to compare an action requested by the user with the actions listed in the rights and permissions segment 514, and to allow or deny the requested action depending on the specified rights. The operation of the rights enforcer 524 will be explained in more detail below, in connection with FIG. 7.

Also present is a fixed bias engine 526 within executable code segment 512; it is used to read and polarize the data according to the state of the system (or another polarization key) as explained above. In a preferred embodiment of the invention, the bias engine 526 acts on the document before it is stored or decrypted, so that the document is never stored in the unencrypted state on the user system. The bias engine 526 is secured, that is, it is cryptographically signed and encrypted, to prevent tampering, reverse engineering, and disassembly.

A counterpart depolarization engine 528 is also included to allow generation of presentation data in the unencrypted state of the polarized content (see FIG. 4). The depolarization engine includes a set of safe window objects, which provides a relatively tamper-proof interface to the rendering API (application program interface) of the user system. Secure window objects are resistant to being intercepted, thereby reducing the possibility that the document, in its unencrypted form, can be reconstructed by intercepting and receiving data destined for the operating system.

A counterpart depolarization engine 528 is also included to allow generation of unencrypted presentation data of the polarized content (see FIG. 4). The depolarization engine 528 provides a relatively tamper-proof interface to the logical or physical output device (eg, the user display device). The input to the depolarization engine 528 is polarized display data. Therefore, if such data is intercepted, it will not reveal any of the unencrypted content without further depolarization depending, for example, on the state of the user system.

A secure viewer 530 is optionally included in executable code segment 512. Secure viewer 530 is used to allow only the access levels that are allowed under the rights and permissions segment 514. For example, if the user has only acquired sufficient rights to view a document (and not to save or print it), the viewer will not allow the user to save, print, or perform the standard cut and paste operations possible in most modern operating systems. .

Finally, a rendering engine 532 is included or referenced within the executable code segment 512. The rendering engine 532 does not have to be secure. Consequently, the code for the rendering engine 532 can be included within the SPD applet, or alternatively retrieved (via a secure link) from some other location. In either case, rendering engine 532 is adapted to receive polarized document content and produce polarized presentation data therefrom (see FIG. 4).

The above aspects and elements of self-protective document 510 will be explained in more detail below, in conjunction with the operation of the system.

Figure 6 shows the steps taken when creating and distributing a self-protecting document 510. A generic SPD 610 includes non-user-specific rights information and is not encrypted for any particular user. The generic SPD 610 is created from three items: the content of the original document 612, in unencrypted (unencrypted) form; a high-level rights specification 614; and an optional 616 watermark.

The content 612 is preprocessed (step 618) to configure the document as desired by the author or publisher. For example, you can select a preferred page size, font, and page layout. The content 612 is essentially "pre-rendered" in the step of pre-processing the content so that it is in a format that is compatible with the user's systems and the SPD. For example, content 612 can be converted from Microsoft Word (".DOC") or Adobe Acrobat (".PDF") format to a different format specially adapted to be read by the rendering engine 532 (Figure 5). In one embodiment of the invention, multiple versions of the content 612 are generated by the content preprocessing step and stored in the generic SPD 610; the different versions can later be purchased separately by the user according to his needs.

The high-level rights specification 614 exposes what combinations of access rights are permissible. Such a specification of rights is tailored to a particular document, and is capable of describing different groups of rights for different classes of downstream users. For example, a publisher may receive the right to distribute up to 100,000 copies of a document at a royalty of $ 1.00 per copy, originating the additional copies.

ES 2 248 952 T3 a right of $ 2.00. Similarly, users can be given the option to purchase a version of the document that "expires" after a month, a year, or never. Several possible limitations are described with reference to a detailed example, which follows. Digital Property Rights Language (DPRL) is a language that can be used to specify rights for digital works. Provides a mechanism in which different terms and conditions can be specified and enforced for rights. Rights specifications are represented as sentences in DPRL. For details, see, for example, United States Patent No. 5,715,403 to Stefik, entitled "System for controlling the distribution and use of digital works that carry rights of use attached where the rights of use are defined by a grammar of Rights Of Use". The execution of the rights and the verification of conditions associated with the rights are carried out using SPD technology.

Different rights can be specified for different parts of a digital work using a "work" specification. Within a work specification different sets of rights applicable to this work are specified. Rights can be grouped into groups called “rights groups”. Each right within a group of rights is associated with a series of conditions. The conditions can be of different types: rights to turn off, time of use, type of access, type of watermark, type of device on which the operation can be performed, etc. DPRL allows different categories of rights: transfer, rendering rights, derivative work rights, file management rights, and configuration rights. Transportation rights govern the movement of a work from one warehouse to another. Rendering rights govern the printing and viewing of a work, or more generally, the transmission of a work by means of a transducer to an external medium (this includes the "export" right, which can be used to make a copy in non-English language. encryption). Derivative work rights govern the reuse of a work when creating new works. File management rights govern the creation and restoration of backups. Finally, the configuration rights refer to the installation of software in repositories. {XE “rights: categories of”}

An exemplary work specification in DPRL is set out below:

(Construction site:

(Rights-Language-Version: 1.02) (Work ID: “ISDN-1-55860-166-X; AAP-2348957tut”) (Description: “Title:“ Zuke-Zack, the Moby Dog Story ”

Author: "John Beagle"

Copyright 1994 Jones Publishing ”) (Owner: (Certificate:

(Authority: “Library of Congress”) (ID: “Murphy Publishers”))) (Parts: “Photo-Celebshots-Dogs-23487gfj” “Dog-Breeds-Chart-AKC”) (Comment: “Rights edited by Pete Jones , June 1996 ”) (Content: (From: 1) (To: 16636)) (Rights group:“ Ordinary ”(Comment:“ This rights group is used for standard retail editions ”) (Set:

(Time: (Until: 01/01/1998 0:01)) (Rights: (To: “Jones-PBLSH-18546789”) (Camera: “Visa”))) (Reproduction:

(Rights: (Per use: 10.00 USD)) (By: 1: 0: 0) (To: 0: 0: 1))))

ES 2 248 952 T3 (Print:

(Rights: (Measured: (Fee: 1.00 USD) (Printer:

(Certificate:

(Authority: “DPI” (Type: “TrustedPrinter-6”))) (Watermark:

(Watermark-Str. "Title:" Zeke Zack - the Moby Dog "

Copyright 1994 by Zeke Jones.

All rights reserved ”) (Watermark-symbols: user-id institution-position render-name render-time)))) (Transfer) (Copy: (Rights: (By use: 10.00 USD))) ( Copy: (Access:

(User: (Certificate:

(Authority: “Murphy Publishers”) (Type: “Distributor))))) (Deleted :) (Backup :) (Restore: (Rights: (By use: 5.00 USD)))))

This work specification has a group of rights called “Ordinary”, which specifies rights for standard retail editions of a book titled “Zuke-Zack, the Moby Dog Story”. The work specification expresses the conditions for various rights: reproduction, printing, transfer, copying, deletion, backup and restoration. The sample work includes two other parts, a photograph and a breed chart incorporated from other sources. A "set" specification groups together a set of common conditions that apply to all rights in the group. This specification indicates that all group rights are valid until January 1, 1998 and that the right must be paid into the account “Jones-PBLSH-18546789”. The clearinghouse for this transaction must be Visa. The following contract applies: the work can be reproduced by paying $ 1.00 each hour, where the rate increases per second; work can be printed on “DPT” certified TrustedPrinter-6 at a fee of $ 10.00 per print; the printout should have a watermark thread (as illustrated) and a list of symbols signifying that the currently known “fingerprint” information is being printed; This work can be copied by paying $ 10.00 or by purchasing a dealer certificate from Murphy Publisher; and the unrestricted transfer, deletion or backup of this work is allowed (restoration costs $ 5.00).

The high-level rights specification 614 is also subjected to a preprocessing step (step 620), in which the high-level specification (i.e., human-readable) is compiled to a more efficient representation of data structure for use. by invention.

The generic SPD 610 is then created (step 622) by combining the preprocessed content 612, the preprocessed rights specification 614, and the watermark 616. A watermark can be added by any means known in the art; it can be visible or hidden within the SPD. Generic SPD 610 may also optionally be encrypted by author / publisher 110 for transmission to dispatcher 114 (FIG. 1).

Generic SPD 610 is then received by distributor 114, and stored for later customization. When dispatcher 114 receives a request from user 624 (directly or through clearinghouse 122 or other intermediary), dispatcher 114 creates a group of user permissions (step 626) that is consistent with

ES 2 248 952 T3 the user request 624 and the rights specification 614. If there is no such consistent set of permissions, no further action is taken on behalf of that user (other than an optional notification message for the user ).

The user permissions and user public key 628 are then used to generate (step 630) a custom SPD 632 adapted for use by the user. The user permissions from step 626 are stored in the rights and permissions segment 514 of the SPD 632, and the user public key 628 is used to encrypt the content in the content segment 516 of the SPD 632. A public key encryption mechanism can be used to transform the SPD from generic form to custom SPD 632. Such a mechanism is useful if the SPD has to be transferred confidentially between different parties, for example, author to publisher to retailer to consumer, with protection of rights at each stage. It should also be noted that multiple user requests can be formed and hosted within a single SPD 632; There are techniques known in the art that are capable of using multiple public keys to encrypt a document in such a way that any of the user's private keys can be used for decryption.

The resulting custom SPD 632 is then transmitted to user 118 by any available means, such as over a computer network, or stored on a physical medium (such as a magnetic or optical disk).

The operations performed when a user receives an SPD are illustrated in the flow chart of Figure 7. The SPD is first received and stored in the user system (step 710); in many cases, you don't have to use the SPD. When it is desired to use it, the user is authenticated first (step 712), typically with a username and password or key. The system then determines what action the user wants (step 714). When an action is chosen, the invention rights enforcement step (step 716) checks the conditions associated with the desired action (such as rate, time, access level, watermark, or other conditions); this can be done locally using the SPD 512 applet (figure 5) or by accessing a rights enforcement server.

If the entitlement enforcement step (step 716) fails, an update procedure is started (step 718). The user can choose to update their permissions, for example by authorizing additional rights. After the successful verification of the conditions, a pre-audit procedure is carried out (step 718), in which the SPD system records the verification status to a monitoring service (for example, the audit server 130 of Fig. 1). The content is then safely rendered on the screen (step 722) as explained above. When the user has finished, a post-audit procedure is carried out (step 724) in which the usage amount is updated with the tracking service. The SPD system then waits for further action.

The protection produced by the SPD stems from the inability of the user to capture a useful form of the document at any intermediate stage during the rendering process. This is done by decrypting the content of the document to an unencrypted form at the latest possible stage, ideally in the last step.

The SPD decryption model is illustrated in Figure 8. E denotes the encryption function performed by the publisher; D denotes the decryption performed on the user system, and R denotes the render transformation. Many prior art systems use a first sequence of 810 transformations, D (E (x)) followed by R (D (E (x))). As previously stated, the first decryption leaves the document in a vulnerable state. Ideally, the transformations are performed in the reverse order 812, R '(E (x)) followed by D (R' (E (x))). This postpones decryption to the last possible time.

The existence of R ', a rendering operation that can be performed before decryption, is determined by the following equality:

D (R '(E (x))) = R (D (E (x)))

In case the encryption and decryption functions are commutative, that is, E (D (x)) = D (E (x)) for any x, the existence of R 'is ensured:

R '(y) = E (R (D (y))) for y = E (x)

In practice, the encryption and decryption functions in popular public key cryptographic systems such as the RSA system and the ElGamal discrete logarithm system meet the switching requirement. This means that the transformation R 'exists if these cryptographic systems are used for encryption and decryption.

The x '= D (R' (E (x))) path represents an ideal SPD solution to protecting documents against unauthorized use and distribution of documents. A document distribution and use scenario can be described as follows. When a user purchases the document, the document is encrypted using public user information and transmitted over an insecure network channel such as the Internet. The encrypted document has the rights information attached and a protection applet 512 that executes the rights and permissions granted to the user by the content owner. At the user's request to use the document, the applet verifies the rights and permissions and generates from the encrypted document the presentation format of the original document. Like any shape

ES 2 248 952 T3 intermediate document before the final presentation data is encrypted with the user's private information, the document protection model SPD ensures that any intermediate form of the document is not useful to other systems when intercepted.

Clearly, this ideal model is based on whether the R 'transformation corresponding to the R rendering transformation can be efficiently computed or not, and in particular whether an invocation of the decryption function D is needed during an implementation of R'. A trivial case where R 'can be efficiently implemented is where R is commutative with the encryption function E. When this happens,

R '(y) = E (R (D (y))) = R (E (D (y))) = R (y) for y = E (x). In this case, R '= R.

Consideration of Figure 8 reveals that many intermediate solutions (for example, intermediate solutions 814, 816, and 818) to the document protection problem may exist in the user system between the two extremes x '= R (D ( E (x))), which has no protection at x = D (E (x)), and x '= D (R' (E (x))), which has ideal protection (under the assumptions discussed above). As illustrated in Figure 8, different paths can be considered from the encrypted document E (x) to the presentation data x 'corresponding to different combinations of partial render transforms and partial decrypt transforms. Again, it should be recognized that delaying D decryption on any path increases the level of document protection.

As explained above, an alternative method of delaying decryption to the last possible moment employs a polarization technique that encrypts only the content of the document, not the format or the entire document as a whole. This possibility is represented in figure 9. Starting with the unencrypted content of document 910 (which, it should be noted, does not exist in a single identifiable position during user processing, but rather is a transient state that occurs within step 412 of Figure 4), the The document is divided (step 912) into a data portion 914 and a format portion 916. The data portion 914 is polarized (step 918) using the polarization key 920 and merged (step 922) with the unencrypted format portion 916. This results in the polarized content 924 being able to be rendered to polarized presentation data without first decrypting the content. It should be noted that this form of polarization is probably less secure than full encryption with the polarization key, since a batch of information can potentially be derived from the layout of a document, word lengths, line lengths, etc; however, this scheme will present a useful deterrent to accidental copyright infringement.

Although some exemplary embodiments of the invention have been described in detail above, it should be recognized that other forms, alternatives, modifications, versions, and variations of the invention are equally operative and will be apparent to those skilled in the art. For example, the portions of the above-described invention that are described as software components could be implemented as hardware. Furthermore, although some functional blocks are described herein as separate and independent from each other, these functional blocks can be consolidated and performed on a single general-purpose computer, or further decomposed into sub-functions as is accepted in the art.

According to a preferred embodiment of the method for creating a self-protective document, the modification step further includes the step of pre-processing the unencrypted document. Furthermore, it advantageously further includes the step of personalizing the generic self-protective document.

The personalization step preferably includes the sub-steps of receiving a user's document request, receiving the user's public key, creating a rights and permissions segment consistent with the user's document request and rights specification, encrypting the segment. of original content to produce an encrypted content segment and combine the code segment, the rights and permissions segment and the encrypted content segment to produce a custom self-protective document.

According to a preferred embodiment of the method for using a self-protective document having an encrypted content segment in a user system, the step of modifying the encrypted content segment includes the secondary step of transforming the encrypted content segment by an encryption algorithm and using the polarization key. In addition, the re-encryption step includes the secondary steps of identifying data information and format information within the encrypted content segment, separating the data information and format information from the encrypted content segment, encrypting the data information with the encryption key. polarization, and combine the encrypted data information with the format information to produce the polarized content.

According to an advantageous embodiment, the polarization key includes a combination of status information derived from the user system.