US 20050008163 A1
In a network of intermittently-connected computers, a method and apparatus for maintaining and managing control over data objects authored, accessed, and altered by users in dynamic, distributed, and collaborative contexts. The invention method and apparatus attach to each data object an identification of a respective control policy. Each control policy comprises at least an indication of a subset of the users who may access the data object, an indication of the privileges granted to each subset of users able to access the data object, and an indication of a subset of users who may define or edit the control policy. The invention method and apparatus separate the management of the control policies of data objects from the creation and use of the data objects. The invention method and apparatus automate common policy changes, distribution of policy changes to the enforcement agents, and propagation of control policies to derivative works.
1. A computer method of protecting data objects, said method comprising the steps of:
encrypting a data object with a content encryption key; and
encrypting the content encryption key with a key encryption key of a control policy associated with the data object.
2. The method of protecting data objects of
recording a control policy tag corresponding to the data object.
3. The method of protecting data objects of
storing the encrypted content encryption key in the control policy tag.
4. The method of protecting data objects of
decrypting the content encryption key stored in the control policy tag with a cached key encryption key; and
decrypting the data object with the decrypted content encryption key.
5. The method of protecting data objects of
6. The method of protecting data objects of
7. The method of protecting data objects of
8. The method of protecting data objects of
9. The method of protecting data objects of
10. The method of protecting data objects of
automatically replacing an expired key encryption key of a control policy.
11. The method of protecting data objects of
selecting a proper key from a set of decryption keys comprising at least one of: a next future key, a current key, a recently expired key, and an old key received from a control policy server.
12. The method of protecting data objects of
storing a second copy of the content key encrypted with a second encryption key in the control policy tag.
13. The method of protecting data objects
14. The method of protecting data objects of
providing access to a data object with an expired key encryption key of the control policy using the control policy server key encryption key.
15. The method of protecting data objects of
protecting integrity of the control policy tag against tampering.
16. The method of protecting data objects of
17. The method of protecting data objects of
checking a control policy server for modifications to the control policy associated with the data object.
18. The method of protecting data objects of
19. The method of protecting data objects of
revoking a user's access to the data object upon detection of the changes to the control policy that prevent that user from further access to the data object.
20. The method of protecting data objects of
storing the key encryption key of the control policy on a control policy server.
21. The method of protecting data objects of
retrieving a decryption key for the key encryption key of the control policy and the indication of privileges for a user by the user if the user is indicated in the control policy to be in a set of users who may access the data object.
22. The method of protecting data objects of
23. The method of protecting data objects of
storing an indication of a duration of time for which the user may access the data object; and
revoking a user's access to the data object upon expiration of the duration of time.
24. The method of protecting data objects of
decrypting the data object; and
allowing the user to access the data object.
25. The method of protecting data objects of
destroying the key encryption key of the control policy upon expiration of the duration of time.
26. The method of protecting data objects of
changing the content encryption key whenever the data object is modified.
27. The method of protecting data objects of
automatically replacing an expired control policy tag.
28. The method of protecting data objects of
29. The method of protecting data objects of
sending the control policy tag to a control policy server if a control policy version does not match a current version.
This application claims the benefit of U.S. Provisional Application No. 60/475,109, filed on Jun. 2, 2003, the entire teachings of which are incorporated herein by reference.
The present invention relates to the field of usage rights enforcement and management for digitally encoded documents and data.
The encoding and distributing of audio, video, graphical, and written work in digital formats has become a fundamental part of modern business. However, the ease with which copies may be made that are identical to the original and the speed of distribution enabled by the Internet have caused the owners of such works to adopt technologies that associate and enforce usage rights with digitally encoded data. Examples of those interested in such technologies include: providers of music, movies, or other entertainment content; publishers of electronic newspapers, magazines, or books; and corporations with confidential, proprietary, or otherwise sensitive information. Without loss of generality and for ease of exposition, we will refer to all of these kinds of digitally encoded works as data objects.
Many approaches exist to associate and enforce usage rights with data objects. One common approach is based on technologies that attempt to prevent the unauthorized copying of data objects from the physical media carrying the objects. U.S. Pat. No. 5,513,260 is an example of one such copy protection scheme.
Though copy-protection techniques are appropriate for some domains, the types of usage rights that they can enforce are too coarse grained to be a general solution. For example, the owner of a proprietary and confidential document may wish to have one group of individuals be able to only read a protected document and a different group be allowed to read and write it. Copy-prevention technologies are not powerful enough to describe such usage policies.
More general-purpose approaches exist that protect the data objects so that only authorized users can access and use the objects according to a set of rules specified for each class or group of authorized user. This approach typically relies on encryption technology to guarantee that only authorized users have access to the actual data object. In particular, authorized users are given access to the secret key needed to decrypt the protected object and produce the actual data object. The usage rights typically specify who is authorized to access the secret key and what an authorized user can do with the decrypted data object. This basic approach includes the large body of work in digital rights management (DRM) and related rights management technologies. Though this approach does not prevent copying of the encrypted bits, it achieves the same end result as copy protection since unauthorized users cannot access the protected data objects without the secret key.
To be effective, a rights management system must tightly couple the usage rights to the encrypted data objects so that the usage rights always appear with the associated object. This coupling should make it very difficult and ideally impossible for someone, who is not the owner of the object or otherwise authorized, to separate the data object from its usage rights.
We can group attacks that attempt to separate a data object from its usage rights into two categories. The first category comprises attacks on the combination of the usage rights and encrypted data object. Replacing the usage rights of one file with the usage rights of another is an example of an attack in this category. The second category comprises attacks undertaken while the data object is decrypted and being used by an authorized user. The goal here is to obtain an unprotected copy of the decrypted data object by directly circumventing the usage rights. To be effective, a rights management system must contain mechanisms that protect against both categories of attack.
The second category of attacks highlights the fact that the encrypted data object must eventually be decrypted in order to be accessed by an authorized user. A rights management system may either allow the user to decrypt the data object directly, or it may require the deployment and use of rights-management-aware applications. In many commercial situations, the owner of the protected data object may not want to bother the end user with an explicit encryption and decryption step or may not trust the end user to abide by the usage rights. Thus, the preferred method is to employ rights-management-aware applications that transparently decrypt the data objects for authorized users and enforce the usage rules attached to the objects. Rights-management-aware applications act as trusted agents for the rights management system, enforcing the rules specified by the owners of the protected data objects. Media players that can play music files in encrypted formats are examples of rights-management-aware applications.
The closeness of the coupling and the reliance on trusted application agents constitute the fundamental differences between rights management systems and technologies like encrypting file systems. In an encrypting file system (e.g., Microsoft's EFS, U.S. Pat. No. 6,249,866), usage rights are associated only with the computer structure holding the data object (e.g., a file) and not with the data object itself. Since applications are not aware of the usage rights enforced by an encrypting file system, it is fairly simple for a user, who is authorized to access the object but not to change its usage rights, to save the data object in a manner that does not propagate the rights. In particular, an authorized user of a protected file in an encrypting file system needs only to save the file to a directory outside the encrypting file system to create an unencumbered copy of the protected file.
The use of rights-management-aware applications allows a rights management system to enforce a tight coupling between an encrypted data object and its associated usage rights. Some designers have chosen to implement this tight coupling by storing the usage rights together with the encrypted data object, producing a new data object that is often referred to as a secure container (e.g., see U.S. Pat. No. 6,427,140). In this approach, usage rights are explicitly tied to a particular copy of the protected data object. This approach works well, for example, in commercial markets like online music where the owner of the data object publishes read-only content and simply wants to maintain control over the usage and distribution of the content. We refer to such rights management systems as supporting publish-only distribution models.
A key characteristic of the publish-only distribution model is that the usage rights in the secure container are not expected to change over time. Or if they do change, they change slowly, and the change affects only one end user at a time. To change the usage rights in the publish-only distribution model, the owner must have access to the secure container holding the usage rights. Access to the secure container would enable the rights management system to modify the usage rights stored in the container. If the secure container was not available, the owner can remove the end user's authorization to access the original secure container (e.g., by destroying the decryption key for this container) and re-issue a new secure container to the end user with the same protected data object but new usage rights. This latter approach requires the rights management system to notify the end user of the new secure container, and it requires that the rights management system has a copy of the data object to put into the new secure container.
Though these requirements are not an imposition in a domain like online music, they are a serious impediment to dynamic environments, i.e., ones where the usage rights protecting data objects may change frequently and in possibly significant ways. These requirements are also a serious impediment to distributed environments, where multiple users may have individual copies of a protected data object on diverse computer devices and storage media, some of which may not be online or otherwise accessible to the owner of the protected object. Clearly, it is not possible in such environments for the rights management system to have access to all of the copies of the protected object when the owner wishes to make a change to the usage rights of that protected object. It is also not desirable to re-issue a new protected data object to a group of users, since the change in usage rights may affect only a few users and should be unnoticed (transparent) to the rest. Furthermore, it may not even be possible to re-issue the protected data object in a distributed environment where the owner controls the usage rights but does not have a copy of the latest version of the object.
In a truly collaborative environment, it's often difficult and sometimes impossible to identify a single “publisher” of collaborative material. For corporate data, it is possible however to identify the “owner” of collaborative material produced for the purposes of a corporation's business. The owner is the company that employs the author or authors of the collaborative works. For collaborative environments then, there is a clear need to distinguish between those who produce sensitive material and those that determine the usage rights of the same material.
Authentica has patented a partial solution to the enforcement and management of usage rights for digital data objects in dynamic and distributed environments (U.S. Pat. No. 6,449,721). This approach allows the owner of a digital data object to maintain control over the usage rights even after the protected objects have been distributed to end users. In particular, the approach stores the usage rights of protected objects in a single, central location so that an owner of a protected data object can change the usage rights of that object without requiring simultaneous access to any of the (possibly numerous) copies of the data object. Ideally, this approach allows multiple, distributed copies of the data object to exist while maintaining only a single, authoritative copy of the object's usage rights. Having a single, authoritative copy of the object's usage rights simplifies management of the usage rights.
Authentica's approach creates a unique identifier for each segment of protected information. The Authentica key server maintains an association between unique segment identifiers, the usage rights for those segments, and the encryption keys used to protect and access each segment. To access a protected segment, an end user must authenticate to the server and provide the identifier of the protected segment he or she wishes to access. Assuming that the user is authorized to access the protected segment, the server responds with a decryption key for that segment and the usage rights for that segment and user combination. A rights-management-aware application on the end-user's machine uses the server's response to provide the end user with the owner-designated level of access to the protected segment.
Though an approach like Authentica's allows the owners of protected data objects to control usage of distributed information and dynamically change that usage information without the need to collect or redistribute the protected data objects, it is not a complete solution to the problems associated with the enforcement and management of usage rights in collaborative environments. In particular, a solution for collaborative environments needs to focus on protecting the products of collaboration in a manner that fits naturally into existing collaborative models. For example, in commercial enterprises, collaboration often produces multiple documents all protected by the same usage rights, and thus a truly collaborative solution should allow for the easy grouping of multiple documents under a single set of usage rights. In addition, it is also often expected that derivative works created during collaboration would also be protected by the usage rights of the collaboration and that changes to these rights would coincide with existing processes for moving a work into a new collaborative setting. Finally, all of the current rights management systems, especially those focused on publish-only distribution models, too tightly control the creation, modification, and distribution of protected documents to be appropriate for protecting the data objects comprising collaborative interactions. An appropriate solution should clearly distinguish between the rights held by “authors” and those held by “owners.”
Various technologies and inventions in this field, including models of discretionary, mandatory, or role-based access control, and DRM (Digital Rights Management) related technologies have addressed one or another of the requirements mentioned above. The embodiments of the present invention, however, offer a unique approach that addresses all of the necessary features for a rights management system targeting dynamic, distributed, collaborative contexts.
Aspects of the invention include a method and a system for maintaining and managing control over data objects authored, accessed, and altered by users in dynamic, distributed, and collaborative contexts.
A data object is any audio, graphical, video, or written work encoded in digital form and encapsulated in a computer structure, such as a file, message, or shared memory object, that a software program can access and manipulate.
A distributed and collaborative context is one in which groups of one or more users work individually or collaboratively on collections of one or more data objects on a network of computers with at least intermittent connectivity to achieve some common purpose. In the present invention, we refer to this common purpose as a business process.
Within a business process, there can be classes of users with different sets of rights and responsibilities. In the present invention, we refer to these classes as roles.
The present invention considers a context to be dynamic if properties of the system can change during the lifetime of a business process. For example, the system might allow the set of users belonging to a role to change during a business process, or it might allow the type of control imposed on a data object to change. The invention separates the publication and modification of protected data objects from the ownership and manipulation of the policies controlling the usage of those data objects.
Control over a data object is specified by a set of rules describing how software programs run by a computer user in a particular role may access and manipulate the object. In the present invention, we refer to these rules as usage rights.
Control policies are signed assertions that describe the conditions under which usage rights are authorized. A control policy comprises at least a list of users who may access the data object, the privileges of those users with access, and an additional list of users who may define or edit the control policy. Policies in the present invention may also define supplemental properties that apply to the objects under its control, to assure authenticity, integrity, and confidentiality of those objects.
As stated in the previous paragraph, the term ‘control’ as used in the present invention typically implies protection against access by unauthorized users and their applications.
A further objective of the present invention is to provide a system and method for obtaining visibility into a business process. Such visibility may be achieved without committing to the risks of securing data objects by encrypting or otherwise changing the actual digital representation of their data objects. When control does not include protection, we obviously cannot ensure that we maintain control against malicious adversaries, i.e. ones that manipulate the protected data objects outside of our protected environment. However, this level of control is still desirable in business situations where an enterprise might want visibility into a business process while their data objects remain in plain text.
A further objective of the present invention is to provide a method and system for storing control policies on one or more central servers.
A further objective of the present invention is to provide a method and system for editing control policies, based on an indication of the users that may edit the control policies and the types of changes that those users can perform. Changes to a control policy would be enacted on the server storing that control policy.
A further objective of the present invention is to provide a method and system for temporarily changing one or more control policies and then reverting back automatically to the original settings at some point in the future.
A further objective of the present invention is to provide a method and system for having one or more preset temporary changes that can be enacted by the click of one button and then rolled back on the click of another button.
A further objective of the present invention is to provide a method and system for attaching to each data object an identification of one (i.e., a respective) control policy. In the present invention, we refer to the control policy whose identification is attached to a data object as the control policy protecting that data object. We also refer to such a data object as a protected data object.
A further objective of the present invention is to allow multiple data objects to reference the same control policy.
A further objective of the present invention is to provide a method and system wherein the identification of a control policy specifies the server in whose name space the actual control policy identifier is defined. In the preferred embodiment, the policy reference attached to a data object comprises a server URL and a numerical value known to that server.
A further objective of the present invention is to provide a method and system for checking by a client connected possibly intermittently to a policy server that a user attempting to create, access, or alter a data object protected by a control policy has the right to perform that action on that data object. If the user has the right, the client allows the requested action to proceed. If the user does not have the right, the client responds with an appropriate error message. In other words, the protection provided by the business process approach does not just protect proprietary, confidential, or otherwise sensitive data objects while they're stored on disk or transmitted over a communication link, but it also protects them while they are operated on by the software applications of authorized users and during inter-application communication (e.g., clipboard operations in the Microsoft Windows operating system).
A further objective of the present invention is to provide a method and system with control policies that may contain conditions that specify device, location, time-of-access, or network connectivity constraints.
A further objective of the present invention is to provide a method and system wherein users authorized to edit a control policy can change that policy without physical or electronic access to all data objects protected by the policy.
A further objective of the present invention is to provide a method and system allowing the only authoritative copy (or copies) of a protected data object to be located on computing machines or media of users without the rights to change the control policy protecting the data object.
In one embodiment of the invention, there is no notion of registering a protected data object with the policy server before distributing it to other users. This is a key aspect of the system required to support collaborative work that involves creation and modification of data objects on machines of authorized users that may be off-line.
A further objective of the present invention is to provide a method and system for allowing authorized users to create new protected data objects even when the client that they are working on has lost connectivity with the server of the specified control policy. Authorized users in this circumstance are those users that have the right to create data objects under the control policy. In the preferred embodiment, the user must have had some recent access to the policy server, where “recent” means within the cache timeout period as specified for that policy.
A further objective of the present invention is to provide a method and system for two or more authorized users to view protected data objects and work collaboratively on new and existing protected data objects even when one or more of these users' clients may have lost connectivity with the server (or servers) of the control policies protecting the collaborative data objects. The protected data objects may never have been viewed while connected to the server (or servers). The shared data objects may be new, that is, created while the users did not have connectivity with the server.
A further objective of the present invention is to provide a method and system in which the storage of the policy server scales in proportion to the number of control policies defined. The storage should not scale in proportion to the number of unique protected data objects nor with the number of copies of these protected data objects.
A further objective of the present invention is to provide a method and system for grouping control policies into business processes.
A further objective of the present invention is to provide a method and system for constructing a control policy by identifying one or more roles involved in that control policy. Each role comprises a respective set of usage rights and a list of users.
A further objective of the present invention is to provide a method and system for aggregating the usage rights of a user appearing in multiple roles contained in a single control policy.
A further objective of the present invention is to provide a method and system for differentiating between users with the privilege to administer (create, edit, and delete) business processes and their encompassing control policies from those users with the privilege to modify only the list of users in one or more roles of a control policy.
A further objective of the present invention is to provide a method and system in which the identification of a control policy on a data object can change. This change might cause the data object to be no longer managed by the system.
A further objective of the present invention is to provide a method and system allowing users with appropriate usage rights to change the control policy identifications on data objects. A user may be granted the right to unprotect data objects by changing the objects control policy identifier to “unmanaged” or equivalent status.
A further objective of the present invention is to provide a method and system with control policies that further define a list of users who may transfer data objects out of the control policy and a separate list of users who may assign the policy to data objects. Both of these actions involve changing the control policy identifier attached to a data object. There may be times when these lists contain no users.
A further objective of the present invention is to provide a method and system for automating the transfer of data objects between control policies for those users with the privilege to do the transfer and assign manually. The preferred embodiment of this aspect involves integrating a tool into the software component of an existing electronic business process.
A further objective of the present invention is to provide a method and system for allowing the administrators of business processes to determine the events that cause the automatic transfer of data objects between control policies.
A further objective of the present invention is to provide a method and system for organizing business processes in a hierarchical manner. Such a hierarchy may be used to limit the scope of transfers of data objects between control policies. It may also be used to define control policies or other properties that are common to several business processes in a single location.
A further objective of the present invention is to provide a method and system (e.g., graphical user interface) for displaying and changing the control policy of a protected data object. In one embodiment this is implemented as a drop-down window located in the title bar of the window displaying the data object. This drop-down window is referred to as the droplet control. When a user clicks on the droplet control, a window may open up with several policies and options for selection by the user.
A further objective of the present invention is to provide a method and system for displaying the list of possible control policies that a user can transfer the current data object to when the user activates the droplet control.
A further objective of the present invention is to provide a method and system for changing a data object's control policy when a user selects a new control policy in the activated droplet control window of the data object.
A further objective of the present invention is to provide a method and system for illustrating the hierarchy of control policies within business processes within an activated droplet control window.
A further objective of the present invention is to provide a method and system for encrypting data objects with a content encryption key (CEK), which is then encrypted with a key encryption key (KEK) of the control policy associated with the data object.
A further objective of the present invention is to provide a method and system for indicating whether the data objects protected by a control policy should be treated as ephemeral or permanent objects. An ephemeral data object is accessible until some designated future time; after that time, the object becomes inaccessible and unrecoverable. A permanent data object is always accessible or recoverable when presented to the rights management system or its agents.
A further objective of the present invention is to provide a method and system for forcing all data objects protected by a control policy to become inaccessible and unrecoverable before the designated future time. The business process's administrator can permanently revoke access earlier than planned.
A further objective of the present invention is to provide a method and system for recording the control policy identifier in a data structure stored with the (possibly encrypted) bits of the protected data object. In the preferred embodiment, we refer to this data structure as the Control Policy Tag (CPT).
A further objective of the present invention is to provide a method and system for attaching the CPT to the beginning or end of the protected data object.
A further objective of the present invention is to provide a method and system for constructing the CPT of a protected data object on either a client or a server machine.
A further objective of the present invention is to provide a method and system for storing the CEK safely in the CPT. The client can access protected data objects off-line with only cached policy and key (KEK) information because the CPT contains the CEK.
A further objective of the present invention is to provide a method and system for automatically replacing an expired CPT on a protected data object. Expiration of a CPT may occur because the CPT format has changed or the control policy KEK for the CPT has expired (i.e., gone beyond its validity period).
A further objective of the present invention is to provide a method and system where the trustworthy clients of the rights management system do not need code to interpret old CPT formats.
A further objective of the present invention is to provide a method and system for indicating that a control policy protects data objects that are read-only or stored on read-only computer media.
A further objective of the present invention is to provide a method and system for informing an unauthorized user of the system protecting the data object accessed. The preferred embodiment includes a text message in the CPT.
A further objective of the present invention is to provide a method and system for protecting the integrity of the CPT against tampering. The preferred embodiment uses a secure hash over the CPT fields.
A further objective of the present invention is to provide a method and system for protecting the confidentiality of a data object's CEK while stored in the CPT. The preferred embodiment encrypts the CEK with the control policy's KEK. The encrypted CEK is protected against known plaintext attacks (i.e. attacks based on the knowledge of identical pieces of two similar documents) by using random seed values and changing the CEK whenever the data object is changed.
A further objective of the present invention is to provide a method and system for protecting the server and client communication against network-based attacks. The preferred embodiment uses a Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) connection for communications between the client and server.
A further objective of the present invention is to provide a method and system for enabling an audit or forensic analysis of a business process based on activities granted and denied within one or more of the control policies of that business process.
A further objective of the present invention is to provide a method and system for identifying the data objects in an activity log based on unique document identifiers maintained in the CPT.
A further objective of the present invention is to provide a method and system for allowing the client to access the server at user login time to obtain and cache the control policies in which the user is mentioned. This feature addresses issues arising in collaborative and distributed environments, including intermittent connectivity, off-line usage of protected data objects, and off-line collaboration with others mentioned in the control policy.
A further objective of the present invention is to provide a method and system for varying the polling frequency at which clients verify cached policies with the server. The frequency may be set so that the client must always verify the cache policy before permitting access.
A further objective of the present invention is to provide a method and system for having clients verify and refresh cached policies when network access is restored.
A further objective of the present invention is to provide a method and system for the server to prompt clients to refresh their cached policies.
A further objective of the present invention is to provide a method and system for specifying the expiration time of a cached control policy.
A further objective of the present invention is to provide a method and system for specifying the validity period of the KEK of a control policy.
A further objective of the present invention is to provide a method and system for allowing the server to supply a client with a limited history of KEKs for a control policy. The use of an expired policy KEK in a protected data object does not force the client to have to contact the server before accessing the object. Even though a user never accesses a protected data object while online, as long as his or her off-line access occurs within the cache timeout period of the control policy of the data object, the user will not be denied access due to an out-of-date KEK.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
A description of preferred embodiments of the invention follows.
The present invention starts with centralized management of usage rights organized in a structure that mirrors the important processes of the business.
Using the organizing structure 10 in
The preferred embodiments will illustrate how the present invention supports the transparent use of protected data objects in a dynamic, distributed, and collaborative environment, where multiple users are modifying individual copies of protected data objects on diverse computer devices and storage media, some of which may not be online or otherwise accessible to the owner of the protected data objects. The discussion will clearly show that the invention supports the distinction between an information author and owner. It will also illustrate that the invention includes protections against adversaries that would try to attack the association between policies and data objects.
As an example of a dynamic, distributed, collaborative environment where we need to protect data objects while simultaneously providing the ability to create, modify, and distribute these protected data objects within the constrains of a policy model, consider a company that wishes to control and protect data objects in compliance with NASD 2711, a regulation that requires a clear and auditable separation of information between the bankers and research analysts in investment banks.
The “NASD 2711” business process 150 comprises three control policies 14: “Background Research” 152 (
The example illustrated in
The block diagram in
The reference monitor 24 in the client agent 26 intercepts operation requests on the data of the protected data object 32 by the rights-management-aware application 21. This monitor uses the tag 23 on the protected data object 32 to obtain the usage rights in the policy protecting this data object 22 for the user 20. The client agent 26 may have to communicate with the policy manager 27 on the policy server 29 to obtain the details of the control policy identified by the tag 23. Assuming the user 20 has the right to perform the requested operation, the crypto engine 25 in the client agent 26 will perform the appropriate encryption operation for the requested operation on the data object 22. The encryption key required to perform this operation was originally obtained from the key manager 28 on the policy server 29 as part of control policy request and reply actions.
The control policies stored on the policy server 29 may be created and edited by an appropriately authorized user 30 using a policy administration application 31, which interacts with the policy manager 27 on the policy server 29.
A particular embodiment may use multiple policy servers. Multiple servers may be used for the purpose of improved reliability or load balancing.
In a particular embodiment, the client agent 26 may have only intermittent connectivity with the policy server 29. Though the invention supports the propagation of modified usage rights to the copies of the effected data objects in a timely manner, the definition of “timely” is set by the users 30 authorized to manage policies. For example, in some commercial situations, timely might mean that all accesses to a data object after modification of its usage rights would be governed by the new rights. In other situations where the commercial environment calls for limited “off-line” access to protected data objects, timely might mean that the usage rights are updated once the local agent for the rights management system comes back online.
The client application 21 in
In general, client-centric processing based on reference monitoring, as illustrated in
Policies and Policy Administration
In the embodiment explained below, a control policy 14 comprises at least a list of the users authorized to access the data objects protected by that policy, a digest of the privileges granted to each user in the authorization list, a current Key Encryption Key (KEK), and a unique identifier (i.e., the Policy ID used in tags 23). Control policies 14 may also contain conditions on those privileges; these conditions may specify additional device, location, time-of-access, or network-connectivity constraints.
The present invention differentiates between the set of users 20 authorized to access data objects protected by a policy (mentioned above) and the set of users 30 to administer (i.e. create, edit, and delete) control policies and the encompassing business processes. Notice that a user might be a member of both sets of users 20, 30.
To better address business process needs of enterprises, the preferred embodiment supports three explicit types of administrative users: information technology (IT) administrators; business process owners; and business role administrators. IT administrators are those users that have administrative access to the policy server 29 in
To facilitate further categorization of an enterprise's business processes and directly reflect the hierarchical nature of business process management, one preferred embodiment supports the organizing of defined business processes in a hierarchical manner. For example, consider a collection of business processes that are organized as a tree. The business process at the root of the tree represents the topmost context, and the business processes at the leaves of the tree are the individual components of the business process at the root. Additional interior tree nodes may be used to represent major categories within the overall business process.
Such a hierarchy organized as a tree may be used to indicate the user or users that are able to administer all of the business processes within a subtree of the hierarchy. Similarly, the indicated users might be able to administer only the roles within that subtree.
An authorized user may choose to create or edit a business process, control policy 14, or role list, as illustrated in step 44. All changes performed by the user are logged and committed in step 46. The changes are then displayed to the user in Step 43.
By logging the changes, the system may allow authorized users to undo an earlier change to the database on the policy server 29. In particular, Step 43 also allows the user to rollback a set of committed changes, as illustrated in step 45. This action is also logged and committed in step 46. Steps 43 through 46 are repeated until the user exits the policy administration application 31. All of these steps can occur without any access to or knowledge of the exact data objects protected by the changed business processes and policies on the policy server 29.
One preferred embodiment of the invention uses the rollback feature mentioned above to implement a one-click security setting that can be enabled or disabled in a dynamic manner. We colloquially call the one-click security setting the security knob.
In the simplest case, consider a business process with two security alert states: normal and lock-down. “Normal” is the default security state; the enterprise proceeds without any special considerations beyond the policies enforced in the normal day-to-day workflow of this business process. The security officers and business process owners have together also defined a set of changes to this business process that should go into effect whenever the business process is “under attack” or otherwise vulnerable (e.g., vulnerable to an identified and determined adversary, or vulnerable to potential violations of a governmental regulation during some critical time period). When applied to the appropriate pieces of the business process, these set of changes comprise the “lock-down” security state.
A key aspect of this feature is that an enterprise or business process owner may want to enter this “lock-down” security state quickly and only for a temporary time period. Once the threat or vulnerability has passed, the system should revert to the policy characteristics defined for the “normal” security state. It would be too slow, error-prone, and tedious to edit each of the pieces of a business process every time the enterprise or business process owner wanted to enter or exit the “lock-down” security state.
To implement this capability, one embodiment would create a set of log events that would automatically be applied when the security knob was set to a pre-defined setting. The log events for the “lock-down” security state described above could be captured by simply having the authorized administrator perform the changes to the current business process (i.e. “normal” security state), having the system log and store those changes under the appropriate security setting identifier (i.e., “lock-down”), and not having those changes actually applied to the database at the time of definition. The log events for the transition from “lock-down” to “normal” are simply those used to revert from the “lock-down” change.
To keep the security setting coherent, the system would ask the user if he or she also wanted to change, for example, the “lock-down” security state while the authorized user was making changes to the business process under the “normal” security state.
Those of ordinary skill in the art should recognize the methods of extending this two-setting security knob example and implementation to one that implements an n-setting security knob, for any specific n greater than 2.
Since the system does not have access to all of the data objects 32 protected by a control policy 14 when that policy is modified, we must be careful when “deleting” a control policy. First, we cannot reuse a control policy identifier from a “deleted” control policy for a new policy, since any data object 32 protected by the “deleted” policy would then appear to be part of the new control policy. We might also want some privileged user to be able to recover data objects from “deleted” control policies.
In the preferred embodiment, we use a globally unique identifier (GUID) as the identifier on a control policy 14, ensuring that no two control policies 14 ever get the same identifier. When an authorized administrative user deletes a control policy, the system removes the control policy from the system (possibly logging the action and the deleted information) so that data objects protected by the “deleted” control policy will appear as data objects that users are not authorized to access. Recovering a protected data object is handled through the “disaster recovery” mechanism described later.
Encryption and the Control Policy Tag (CPT)
To ensure continuous protection of and control over a data object 22, a preferred embodiment of the current invention encrypts the data object 22 when it is not being accessed by rights-management-aware application. To each encrypted data object 22, the system attaches a Control Policy Tag (CPT).
For each data object 22, the rights management system generates a pseudo-random number that it uses as a symmetric key for encrypting and decrypting the data object 22. This process effectively produces a unique CEK for each data object. The control policy tag 23 in
The version field 51 identifies the version of the CPT structure being used. This field allows the system designers to change the format or contents of the CPT in the future and yet still be able to access content protected by old as well as new CPT structures (see
The version field 51 may begin with a “magic number” that content filtering applications can use to identify the data object 32 as one encrypted and protected under the current invention. This “magic number” could, for example, be used by anti-virus scanning applications to know that the protected data object 32 is encrypted (and presumably free of viruses due to a scan before encryption).
The length field 52 specifies the size of the CPT in bytes.
The text message field 53 is an optional field that explains to an unauthorized user (or users executing programs not under control of the rights management system) that the attached data object 32 is protected and where to go to get more information. This field is optional; some deployments may choose greater secrecy (no information provided to unauthorized users) over ease-of-use concerns (informing users how they can become part of the rights management system).
The control policy id field 54 identifies the control policy 14 that protects the attached data object. This field contains a globally unique identifier (GUID). The control policy id field 54 may also specify (e.g., via a URL) the policy server 29 in whose name space the GUID is known.
The object id field 55 is another optional field; it specifies a unique identifier for each data object 22.
Each protected data object 32 is encrypted with a secret key, called the Content Encryption Key (CEK), and this key is stored in at least two places in the CPT structure 23, labeled Encrypted CEK 56 and 57. One of these two fields 56, 57 contains the CEK encrypted with the policy server's KEK. The other field contains the CEK encrypted with the Key Encryption Key (KEK) of the policy identified in the control policy id field 54. The KEKs may be either symmetric or asymmetric keys. For the rest of the description of the preferred embodiment, we will assume that a KEK comprises a public/private key pair.
Another embodiment may include additional KEK fields that support role-based KEKs. In this manner, an administrator could specify unique key properties (e.g., shorter off-line access) for certain roles.
Since an embodiment of the present invention may use one or more different content encryption algorithms, the encryption algorithm id field 58 identifies the actual algorithm and other definable properties (e.g., key length) used to encrypt the data object with the CEK.
The final field, the integrity check field 59, is used to ensure that no one has tampered with the fields in the CPT 23. It may contain, for example, a secure hash of the entire CPT.
If the data object is tagged but not encrypted, the two encrypted CEK fields 56 and 57 and the encryption algorithm id field 58 are zeroed.
Control policies 14 are considered an integral part of a protected data object 32, accompanying the data object even as it moves among computers and their internal structures (e.g., file systems and memory buffers). The CPT, which references the governing control policy through the control policy id field 54 and contains the CEK secured by the control policy's KEK, is propagated with the encrypted data object 22 until explicitly removed by an authorized user through an embodiment of the rights management system of the present invention.
An explicit decision of the present invention is to allow multiple data objects 32 to refer to and be protected by a single control policy 14. The CPT structure described above clearly supports this decision. The embodiment also emphasizes the fact that the value in the control policy id field 54 of the CPT does not uniquely identify a document (as a unique document identifier would do).
The policy server 29 of
The preferred embodiment of the present invention has the CPT 23 located in front of the data object 32 (i.e. the CPT is encountered before the data object when scanning a protected data object 32 starting with the first byte of the protected data object). A different embodiment could place the CPT at the end or at any other explicit location within the protected data object 32.
The preferred embodiment allows both the policy server 29 and the client agent 26 of
If the monitor 24 can interpret the CPT 23, the monitor in step 65 proceeds to check the integrity of the CPT via field 59 (
If the user appears in multiple roles under the corresponding (associated) control policy 14, the preferred embodiment aggregates the usage rights for each of the roles containing the user. This aggregation yields a set of usage rights that contains all of the positive rights of that user's individual roles. Clearly, another embodiment might use a different aggregation method.
If the operation is authorized, the monitor 24 in step 70 uses the KEK of the control policy 14 identified in the CPT to decrypt the CEK used to encrypt and decrypt the contents of the subject protected data object 32. The sections on CPT update and disaster recovery below describe some exceptional conditions that may occur during the processing of step 70 in some embodiments.
Finally, given a decrypted CEK, the monitor 24 in step 72 uses the CEK to either decrypt the encrypted contents on a read operation or encrypt new contents on a write operation.
Architecture of Client Agent 26
The client handler process 82 acts as a local proxy for the policy server 29 of
Under this embodiment, the reference monitor 83 requests the policy KEK from the key service and cache 87 in the client handler process 82 in order to extract the CEK for a protected document from its CPT (step 70 of
The client handler process 82 also includes a logging service 88 for collecting log information from each integration bundle 84 and eventually passing that log information back to the policy server 29 of
Some control policies 14 state how long they can be cached and used off-line. When such policies timeout, the handler process 82 in step 93 will re-fetch expired policies 14 from the policy server 29. The control policy KEK can also expire; the embodiment's handling of this time out condition is described below in the section labeled “Expired KEKs and CPT Update.”
The preferred embodiment currently implements a three-way toggle (labeled Basic, Standard, and High) for setting control policy KEK expiry periods and cache timeout values. The policy KEK validity period and length of time before cached policy timeout are longer in the “Low” setting than the “Medium” setting, providing more potential exposure if a KEK is compromised or a control policy changed. The “High” setting provides the highest level of security and thus lowest level of exposure; however, it also implies that users can work off-line for shorter periods of time. Each deployment of the embodiment of the present invention will select control policy KEK expiry periods and cache timeout values according to their level of risk tolerance and need for off-line use of protected data objects 32.
Finally, the policy server 29 can prompt the handler processes 82 of online clients to flush and refresh their cached policies, as stated in step 94. Off-line clients will synchronize their cached policy stores with the policy server 29 when again connected.
For steps 91-94, the client handler process 82 in step 95 will check to make sure that the necessary network communication occurred. If everything was successful, the handler process 82 in step 96 will cache the received control policies 14 in secure storage. If the client had no network connectivity with the policy server 29, the handler process 82 in step 97 will record the missed event for replay later in steps 98 and 99, after network connectivity is restored.
Expired KEKs and CPT Update
The CPT 23 of a protected data object 32 is the only structure in the present invention that contains the CEK used to encrypt the data object 32. As explained earlier, the CEK is encrypted with the KEK of the control policy 14 identified in the control policy id field 54 of
The policy server 29 of
The preferred embodiment of the present invention assigns a unique identifier to each KEK within a control policy 14. Using key manager 28, the policy server 29 stores the current KEK and maintains a history of KEKs for each active control policy 14. This history may contain all KEKs ever generated for a control policy 14, or it may contain only a limited number of the most recent expired KEKs for that policy.
To let the client agent 26 of
We will consider two cases associated with an attempt to access a protected data object 32 with a CEK encrypted with an expired control policy KEK; we consider further cases in the later section entitled “Disaster Recovery and CPT Version Control.” Both of the current cases assume that the policy server 29 maintains a complete history of expired KEKs and distributes only a limited number of the most recently expired keys to the client agent 26. We assume that it is not practical for the policy server 29 to distribute a complete history of expired KEKs to every client agent 26.
In the first case, if the expired control policy KEK is one of the ones sent by the server 29 in the distributed history, the client agent 26 is able to decrypt the CEK, use this CEK to access the protected data object 32, and create a new CPT for the protected data object 32 that uses the control policy's current KEK. All of this occurs without any involvement of the user or further communication with the policy server 29, i.e. it could occur even while the client was off-line.
The second case solves the problem that the expired KEK is not part of the history distributed to the client agent 26. To recover from this situation, the client agent 26 must be online and able to communicate with the policy server 29, since the policy server maintains a complete history expired KEKs for the control policy 14 of the protected data objects 32. The preferred embodiment simply has the client agent 26 request the particular expired KEK of the control policy 14 of interest. When the policy server 29 responds with the appropriate archived KEK, the client proceeds as above (as if it found the expired KEK in the distributed history).
Persistence Models for Protected Data Objects
The present invention supports two explicit persistence models for protected data objects 32. In general, the protected data objects 32 of a control policy 14 are either considered permanent or ephemeral assets.
In the “permanent” model, protected data objects 32 within a control policy 14 are considered permanent assets that should be protected and never lost. The preferred embodiment implements this model by encrypting the CEK of each protected data object 32 with the public master KEK of the policy server 29. This encrypted value is stored in the one of the encrypted CEK fields (e.g., field 56 of
The next section, entitled “Disaster Recovery and CPT Version Control”, describes how the preferred embodiment uses the private master KEK to be always able to recover the CEK of a protected data object 32. For now, we simply state that the master KEK of the policy server 29 also has a validity period, except that the validity period of the master KEK is typically longer than those assigned to control policy KEKs. The validity period can be longer because, as explained in the next section, the private portion of the master KEK is never distributed to the client agents 26 (i.e., it is used only on the policy server 29). Since the master KEK has a validity period, the preferred embodiment also associates a unique identifier with each generated master KEK of the policy server 29, and this identifier is stored with the encrypted CEK in field 56 of
In the “ephemeral” model, protected data objects 32 within a control policy 14 are considered ephemeral assets that should be protected for some pre-determined period of time and then destroyed. By “destroyed” we mean that it is theoretically impossible to recover the plaintext of the protected data object 32.
The preferred embodiment implements the “ephemeral” model by encrypting the CEK in the CPT 23 not with the policy server's master KEK but with a “policy master” KEK (field 56 of
When the owner of an ephemeral policy decides that it is time to permanently destroy all data objects associated with that policy 14, he or she simply requests that all archived copies of the policy master KEKs for that policy be deleted on the policy server 29.
Disaster Recovery and CPT Version Control
There are many types of disasters that an embodiment of the present invention must protect against and recover from (e.g., loss of the policy store and restoration of that store from backups). In this section, we focus on two unique aspects of the present invention's disaster recovery mechanisms. The first concerns embodiments that maintain only a limited history of control policy KEKs (or have through some catastrophic event lost all of the archived KEKs for one or more control policies 14). The second describes support within the present invention for forward and backward compatibility of CPT formats. This feature is again necessary to address the dynamic nature of the enterprise security space and to ensure that the system is always able to recover the CEK stored in the CPT 23 of a protected data object 32 that may not have been referenced for years.
As described above, the KEK for the control policy can expire; the embodiment identifies such an occurrence by noticing that none of the unique identifiers of the stored KEKs match the unique identifier of the KEK used to encrypt the CEK. To recover, in step 111, the monitor 24 extracts the CPT 23 and sends it to the policy server 29 with a request for the server to encrypt the CEK with the current policy KEK. The server 29 in step 112 recovers the CEK by using the appropriate master KEK (server or policy), as indicated by the unique identifier stored with the encrypted CEK. The server 29 in step 113 returns the updated CPT to client agent 26. The client agent 26 in step 114 retrieves the CEK from the received CPT, generates a new CEK, wraps it into an updated CPT, and replaces the original CPT 23 if the protected data object 32 is not marked read-only or stored on read-only media, and proceeds to step 115 using the updated CPT. The client may cache the received CPT in the case where the data object 32 is marked read-only.
The preferred embodiment treats the versioning of CPT formats as a disaster recovery problem. This approach allows the embodiment to distribute client agents 26 with code that only knows how to interpret the current CPT format and how to recover from disasters.
Read-Only Protected Data Objects
So far, the description has generally assumed a collaborative environment involving the creation and modification of protected data objects 32. The preferred embodiment also supports a publish-only model of document generation and distribution. In particular, the preferred embodiment allows the business process administrator to indicate that the KEK for a control policy 14 should always remain valid. This option is desirable when the administrator knows that the data objects protected by the control policy 14 are read-only or are stored on read-only computer media. Even though the system cannot update the CPT 23 of a read-only data object 32, it may still want to expire the policies 14 associated with read-only documents in the client's policy cache 86 to restrict the length of time allowed for off-line viewing of read-only data objects.
Policy Identification and Data Object Transfer
In one embodiment, an ActiveX Window supports droplet control 120. Contents and hierarchy of same are obtained from policy server 29 via cache 86, tag 23 and/or client handler 82 as further explained below.
An authorized user in step 130 opens a document in a rights-management-aware application 21. This might be a new document 22 (data object), in which case the client agent 26 in step 132 displays the default “Unmanaged” control policy in droplet control 120. Alternatively, this might be an existing protected document, in which case the agent 26 in step 132 displays the name of the control policy protecting the document 22 in the droplet control 120. The user in step 134 edits and further manipulates open document within the usage rights specified by the control policy 14 for that user. The logic flow from step 134 back to itself represents the fact that such editing may continue for some unspecified and extended period of time.
At some point, the user in step 136 may decide to activate the droplet control 120 and select a new control policy 14 to which he would like to transfer the protected document. After selection, the agent 26 in step 138 creates a new CPT 23 with the selected control policy identifier in it and tags the document 22 with it. If specified in the control policy 14, an authorized user may in step 136 select the “Unmanaged” control policy, in which case the agent 26 in step 138 does not create a new CPT, deletes the existing CPT, and decrypts the document 22. After step 138, the user can continue to edit the document 22 under the constraints of the new control policy 14.
Each control policy 14 in the system records a list of users with the authority to transfer data objects 22 out of the protection provided by that control policy. The control policy 14 also contains a list of users with the authority to assign new data objects 22 to the control policy. In order for a user to transfer a data object 22 from its current control policy 14 to a new control policy, the user must be a member of the “transfer-out” list of the current control policy 14 and a member of the “assign-to” list of the new control policy 14.
“Transfer” rights are not necessary, i.e. the “transfer-out” and “assign-to” lists of a control policy 14 can be empty. However, in the preferred embodiment of the present invention, at least one of the roles in a control policy 14 will allow users to assign data objects 22 to the policy 14. If none of the roles has assign privileges, the policy 14 would not have any meaning (i.e., it would never have objects associated with it). The “assign-to” list may become empty because the privilege was needed only initially to assign data objects to the control policy 14. For instance, a member may have “assign-to” privileges during the initial creation of the policy and assignment of data objects to the policy. After this initialization, the “assign-to” privilege is removed and the policy 14 controls a fixed set of objects.
In general, the preferred embodiment supports three kinds of “transfers” within the hierarchy of business processes 12 (
The types of transfers described above can be explicitly initiated by an authorized user through the droplet control 120 described earlier, or transfers can be implicitly initiated as a byproduct of some other electronic action undertaken by the authorized user. We refer to this latter category as “automatic transfers.”
The policy 14 associated with a data object 22 may be changed automatically via merge operations (e.g., cut/paste operations). The preferred embodiment of the present invention implements the following kinds of automatic transfers on merge operations: If a protected data object 32 is pasted into an unmanaged data object, the targeted data object assumes the policy 14 of the pasted object. If the protected data object is pasted into a protected data object with a different policy 14, the target object maintains its policy and the paste is allowed to complete only if the source data object's policy allows transfer and the target data object's policy allows assign.
The preferred embodiment of the present invention implements “automatic transfers” by integrating a standalone transfer tool into a software component of an existing electronic business process. For example, a report generator for a large database system might be modified to use the standalone transfer tool to produce reports as protected data objects 32 under a pre-configured control policy 14. As another example, an email server might be configured to use the standalone transfer tool as a type of filter (i.e. exploiting those interfaces used by anti-virus filters) to transfer automatically data objects from one control policy 14 to another based on the people or groups in the “to” and “from” fields of an email message. An automatic transfer would take place only if the sender of the email message had the appropriate transfer rights. Such an embodiment would also want to employ digital signatures to ensure that the email message actually came from the person specified in the “from” field.
Collaboration in a dynamic and distributed environment implies that the only authoritative copy of a protected data object 32 may reside in the field, away from the policy server 29, and in locations not accessible by the business process owner. A system in support of dynamic, distributed, and collaborate environments must make it easy for two (or more) authorized users to generate and share protected data objects 32 both on and off-line. The preferred embodiment of the present invention supports such a goal with the only criterion that the authorized users must have had some recent access to the policy server 29, where “recent” means within the cache timeout for the control policy 14 under which they wish to collaborate. In other words, collaboration is driven by pre-defined business processes 12 and not by pre-registered data objects 32.
While off-line, user A in step 144 creates a sensitive data object D (in the example, a document) and protects it with control policy P. This action takes place while user A is disconnected from the policy server 29. Since control policy P is cached on user A's laptop, he or she is able to create and protect document D. User A in step 145 gives a copy of document D to user B. User B in step 146 is able to edit protected document D on his or her laptop while also disconnected from the policy server 29. The collaboration of users A and B around document D (or any other document protected by control policy P) continues in step 147, as long as no expiry periods occur.
Audits, Forensics, and Compliance
The preferred embodiment of the present invention supports logging of the activities (granted and denied) monitored and controlled by the client agent 26 of
Auditing the activities associated with the data objects 32 of a business process 12 does not necessarily require encryption of the identified data objects 32. In one embodiment of the invention, the identified data objects 32 may be simply “managed” and not “protected.” In other words, auditing requires only that an identified data object 32 have a CPT 23; it does not require that the contents 22 of that data object 32 be encrypted.
The object id field 55 in the CPT 23 (
This example emphasizes the fact that the preferred embodiment of the present invention uses object identifiers only for audits, forensics, and compliance purposes. The embodiment does not use the object identifier 55 of a protected data object 32 for determining the control policy 14 or associated usage rules.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.