Selective data encryption using style sheet processing for decryption by a client proxy

Abstract

A method, system, and computer program product for selectively encrypting one or more elements of a document using style sheet processing. Disclosed is a policy-driven augmented style sheet processor (e.g. an Extensible Stylesheet Language, or "XSL", processor) that creates a selectively-encrypted document (e.g. an Extensible Markup Language, or "XML", document) carrying key-distribution material, such that by using an augmented document processor (e.g. an augmented XML processing engine), an agent can recover only the information elements for which it is authorized. The Document Type Definition (DTD) or schema associated with a document is modified, such that the DTD or schema specifies a reference to stored security policy to be applied to document elements. Each document element may specify a different security policy, such that the different elements of a single document can be encrypted differently (and, some elements may remain unencrypted). The key distribution material enables a document to be encrypted for decryption by an audience that is unknown at the time of document creation, and enables access to the distinct elements of a single encrypted document to be controlled for multiple users and/or groups of users. In this manner, group collaboration is improved by giving more people easier access to information for which they are authorized, while protecting sensitive data from unauthorized agents. A key recovery technique is also defined, whereby the entire document can be decrypted by an authorized agent regardless of how the different elements were originally encrypted and the access protections which were applied to those elements.

Claims

1. A computer program product embodied on computer readable media readable by a computing system in a computing environment, for enforcing security policy using style sheet processing, comprising:

computer-readable program code that is configured to obtain an input document;

computer-readable program code that is configured to obtain a Document Type Definition (DTD) that defines elements of said input document, wherein: (1) an attribute of at least one element defined in said DTD references one of a plurality of stored policy enforcement objects; (2) more than one of said references may reference a single stored policy enforcement object; and (3) each of said stored policy enforcement objects specifies a visibility policy for said referencing element or elements, said visibility policy identifying an encryption requirement for all elements having that visibility policy and a community whose members are authorized to view those elements;

computer-readable program code that is configured to apply one or more style sheets to said input document, thereby adding markup notation to each element of said input document for which said element definition in said DTD references one of said stored policy enforcement objects specifying a visibility policy with a non-null encryption requirement, resulting in creation of an interim transient document that indicates elements of said input document which are to be encrypted; and

computer-readable program code that is configured to create an output document in which each element of said interim transient document for which markup notation has been added is encrypted in a manner that enables a client proxy associated with a group that is a community member authorized to view that element to use key distribution material associated with the output document when decrypting the encrypted element.

2. The computer program product according to claim 1, further comprising computer-readable program code that is configured to render said output document on a client device.

3. The computer program product according to claim 1, wherein said markup notation in said interim transient document comprises tags of a markup language.

4. The computer program product according to claim 1, wherein said input document is specified in an Extensible Markup Language (XML) notation.

5. The computer program product according to claim 4, wherein said output document is specified in said XML notation.

6. The computer program product according to claim 1, wherein said stored policy enforcement objects further comprise computer-readable program code that is configured to override a method for evaluating said elements of said input document, and wherein said computer-readable program code that is configured to apply said one or more style sheets further comprises computer-readable program code that is configured to invoke said computer-readable program code that is configured to override, thereby causing said markup notation to be added.

7. The computer program product according to claim 6, wherein said style sheets are specified in an Extensible Stylesheet Language (XSL) notation.

8. The computer program product according to claim 7, wherein said method is a value-of method of said XSL notation, and wherein said computer-readable program code that is configured to override said value-of method is by subclassing said value-of method.

9. The computer program product according to claim 6, wherein:

said overriding method comprises:

computer-readable program code that is configured to generate said markup notation as encryption tags; and

computer-readable program code that is configured to insert said generated encryption tags into said interim transient document to surround elements of said interim transient document for which said visibility policy of said elements in said input document have said non-null encryption requirement; and

said computer-readable program code that is configured to create said output document further comprises computer-readable program code that is configured to encrypt those elements surrounded by said inserted encryption tags.

10. The computer program product according to claim 1, wherein said encryption requirement further comprises specification of an encryption algorithm to be used when encrypting elements having that visibility policy.

11. The computer program product according to claim 1, wherein said encryption requirement further comprises specification of an encryption algorithm strength value to be used when encrypting elements having that visibility policy.

12. The computer program product according to claim 1, wherein said computer-readable program code that is configured to create said output document further comprises:

computer-readable program code that is configured to generate a distinct symmetric key for each unique one of said communities identified by said visibility policy in said stored policy objects for each of said elements of said input document; and

computer-readable program code that is configured to encrypt each of said distinct symmetric keys to create member-specific versions thereof, further comprising:

computer-readable program code that is configured to determine whether each of said members of said community for which said distinct symmetric key was generated is an individual or a group; and

computer-readable program code that is configured to encrypt a separate version of said distinct symmetric key for each determined individual and for a clerk process associated with each determined group.

13. The computer program product according to claim 12, wherein said computer-readable program code that is configured to encrypt a separate version of said distinct symmetric key creates one of said member-specific versions using, as input, a public key of one of said determined individuals or a public key of said clerk process.

14. The computer program product according to claim 1, wherein said encrypted elements in said created output document are encrypted using a cipher block chaining mode encryption process.

15. The computer program product according to claim 12, further comprising:

computer-readable program code that is configured to create a key class for each of said unique communities, wherein said key class is associated with each of said encrypted elements of said output document for which members of this unique community are authorized viewers, and wherein said key class comprises: (1) an encryption algorithm identifier and key length used when encrypting said associated encrypted elements; (2) an identifier of each of said members of said unique community; and (3) one of said member-specific versions of said encrypted symmetric key for each of said identified community members.

16. The computer program product according to claim 12, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

computer-readable program code that is configured to establish a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy; and

computer-readable program code that is configured to decrypt, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

computer-readable program code that is configured to expand said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

computer-readable program code that is configured to identify zero or more of said expanded groups of which said individual user or process is one of said group members;

computer-readable program code that is configured to decrypt, by said clerk process for each of said identified groups upon request by said client proxy, said member-specific version of said symmetric key, thereby creating a decrypted key for each of said identified groups; and

computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

17. The computer program product according to claim 16, wherein:

said computer-readable program code that is configured to encrypt a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said computer-readable program code that is configured to decrypt said member-specific version of said symmetric key further comprises:

computer-readable that is configured to locate a clerk process for said identified group;

computer-readable program code that is configured to establish a second session between said client proxy and said clerk process;

computer-readable program code that is configured to digitally sign said member-specific version, a certificate of said client proxy, and an identifier of said individual user or process by said client proxy, thereby creating a first digital signature;

computer-readable program code that is configured to send said first digital signature, said member-specific version, said certificate, and said identifier from said client proxy to said clerk process on said second session;

computer-readable program code that is configured to receive said sent first digital signature, said member-specific version, said certificate of said proxy, and said identifier by said clerk process;

computer-readable program code that is configured to verify said first digital signature by said clerk process;

computer-readable program code that is configured to verify, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

computer-readable program code that is configured to decrypt said member-specific version using a private key of said clerk process, wherein said private key is associated with said public key of said clerk process;

computer-readable program code that is configured to re-encrypt said decrypted member-specific version using a public key of said client proxy, thereby creating a re-encrypted key;

computer-readable program code that is configured to digitally sign said re-encrypted key by said clerk process, thereby creating a second digital signature;

computer-readable program code that is configured to return said second digital signature and said re-encrypted key from said clerk process to said client proxy on said second session;

computer-readable program code that is configured to receive said second digital signature and said re-encrypted key by said client proxy;

computer-readable program code that is configured to verify said second digital signature by said client proxy; and

computer-readable program code that is configured to decrypt, in said client proxy, said received re-encrypted key using a private key of said client proxy, creating said decrypted key; and

said computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document is executed by said client proxy using said decrypted key.

18. The computer program product according to claim 12, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

computer-readable program code that is configured to establish a first mutually-authenticated secure session between device used by said individual user or process and said client proxy; and

computer-readable program code that is configured to decrypt, for said individual user or process upon determining that said individual user or process is a member of one of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

computer-readable program code that is configured to expand said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

computer-readable program code that is configured to identify zero or more of said expanded groups of which said individual user or process is one of said group members; and

computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document, by said client proxy, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

19. The computer program product according to claim 18, wherein:

said computer-readable program code that is configured to encrypt a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process; and

said computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document further comprises:

computer-readable program code that is configured to locate a clerk process for said identified group;

computer-readable program code that is configured to establish a second mutually-authenticated secure session between said client proxy and said clerk process;

computer-readable program code that is configured to locate said member-specific version of said symmetric key which was encrypted using said public key of said clerk process, wherein said clerk process is associated with a group of which said individual user or process is a group member;

computer-readable program code that is configured to send said located member-specific version from said client proxy to said clerk process, along with a certificate of said client proxy, an identifier of said individual user or process, and an element encrypted with said member-specific version, on said second secure session;

computer-readable program code that is configured to receive said sent member-specific version, said certificate of said proxy, said identifier, and said element by said clerk process;

computer-readable program code that is configured to verify, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

computer-readable program code that is configured to decrypt said member-specific version using a private key of said clerk process;

computer-readable program code that is configured to decrypt said element using said decrypted member-specific version; and

computer-readable program code that is configured to return said decrypted element from said clerk process to said client proxy on said second secure session.

20. The computer program product according to claim 15, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

computer-readable program code that is configured to establish a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy device; and

computer-readable program code that is configured to decrypt, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

computer-readable program code that is configured to expand said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

computer-readable program code that is configured to identify zero or more of said key classes which identify said individual user or process as one of said group members;

computer-readable program code that is configured to decrypt, by said clerk process for each of said determined key classes, said member-specific version of said symmetric key in said key class which was encrypted using said public key of said clerk process, wherein said computer-readable program code that is configured to decrypt uses a private key of said clerk process, thereby creating a decrypted key; and

computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for said key class.

21. The computer program product according to claim 16, wherein:

said computer-readable program code that is configured to encrypt a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said computer-readable program code that is configured to decrypt said member-specific version of said symmetric key further comprises:

computer-readable program code that is configured to locate a clerk process for said identified group; and

computer-readable program code that is configured to establish a second mutually-authenticated secure session between said client proxy and said clerk process;

computer-readable program code that is configured to send said member-specific version from said client proxy to said clerk process, along with a certificate of said client proxy and an identifier of said user or process, on said second secure session;

computer-readable program code that is configured to receive said sent member-specific version, said certificate of said proxy, and said identifier by said clerk process;

computer-readable program code that is configured to verify, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

computer-readable program code that is configured to decrypt said member-specific version using a private key of said clerk process;

computer-readable program code that is configured to return said decrypted member-specific version from said clerk process to said client proxy on said second secure session; and

computer-readable program code that is configured to receive said decrypted member-specific version by said client proxy; and

said computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document is executed by said client proxy using said received decrypted member-specific version.

22. The computer program product according to claim 21, further comprising computer-readable program code that is configured to substitute a predetermined text message for any encrypted elements in said output document which cannot be decrypted for said individual user or process.

23. The computer program product according to claim 18, wherein:

said computer-readable program code that is configured to encrypt a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process; and

said computer-readable program code that is configured to decrypt selected ones of said encrypted elements in said output document further comprises:

computer-readable program code that is configured to locate a clerk process for said identified group;

computer-readable program code that is configured to establish a second session between said client proxy and said clerk process;

computer-readable program code that is configured to locate said member-specific version of said symmetric key which was encrypted using said public key of said clerk process, wherein said clerk process is associated with a group of which said individual user or process is a group member;

computer-readable program code that is configured to digitally sign said located member-specific version, a certificate of said client proxy, an identifier of said individual user or process, and an element encrypted with said member-specific version, thereby creating a first digital signature;

computer-readable program code that is configured to send said first digital signature, said located member-specific version, said certificate, said identifier, and said element from said client proxy to said clerk process on said second session;

computer-readable program code that is configured to receive said sent first digital signature, said member-specific version, said certificate, said identifier, and said element by said clerk process;

computer-readable program code that is configured to verify said first digital signature by said clerk process;

computer-readable program code that is configured to verify, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

computer-readable program code that is configured to decrypt said member-specific version using a private key of said clerk process;

computer-readable program code that is configured to decrypt said element using said decrypted member-specific version;

computer-readable program code that is configured to re-encrypt said decrypted element using a public key of said client proxy, thereby creating a re-encrypted element;

computer-readable program code that is configured to digitally sign said re-encrypted element by said clerk process, thereby creating a second digital signature;

computer-readable program code that is configured to return said second digital signature and said re-encrypted element from said clerk process to said client proxy on said second session;

computer-readable program code that is configured to receive said second digital signature and said re-encrypted element by said client proxy; and

computer-readable program code that is configured to verify said second digital signature by said client proxy.

24. The computer program product according to claim 1, wherein said DTD is replaced by a schema.

25. The computer program product according to claim 1, wherein said encryption requirement further comprises specification of an encryption key length.

26. The computer program product according to claim 9, wherein said inserted encryption tags may surround either values of said elements or values and tags of said elements.

27. A system for enforcing security policy using style sheet processing in a computing environment, comprising:

means for obtaining an input document;

means for obtaining a Document Type Definition (DTD) that defines elements of said input document, wherein: (1) an attribute of at least one element defined in said DTD references one of a plurality of stored policy enforcement objects; (2) more than one of said references may reference a single stored policy enforcement object; and (3) each of said stored policy enforcement objects specifies a visibility policy for said referencing element or elements, said visibility policy identifying an encryption requirement for all elements having that visibility policy and a community whose members are authorized to view those elements;

means for applying one or more style sheets to said input document, thereby adding markup notation to each element of said input document for which said element definition in said DTD references one of said stored policy enforcement objects specifying a visibility policy with a non-null encryption requirement, resulting in creation of an interim transient document that indicates elements of said input document which are to be encrypted; and

means for creating an output document in which each element of said interim transient document for which markup notation has been added is encrypted in a manner that enables a client proxy acting on behalf of an individual user or process to decrypt the encrypted element using key distribution material associated with the output document when the individual user or process is one of the community members authorized to view that element.

28. The system according to claim 27, further comprising means for rendering said output document on a client device.

29. The system according to claim 27, wherein said markup notation in said interim transient document comprises tags of a markup language.

30. The system according to claim 27, wherein said input document is specified in an Extensible Markup Language (XML) notation.

31. The system according to claim 30, wherein said output document is specified in said XML notation.

32. The system according to claim 27, wherein said stored policy enforcement objects further comprise means for overriding a method for evaluating said elements of said input document, and wherein said means for applying one or more style sheets further comprises means for invoking said means for overriding, thereby causing said markup notation to be added.

33. The system according to claim 32, wherein said style sheets are specified in an Extensible Stylesheet Language (XSL) notation.

34. The system according to claim 33, wherein said method is a value-of method of said XSL notation, and wherein said means for overriding said value-of method is by subclassing said value-of method.

35. The system according to claim 32, wherein: said overriding method comprises:

means for generating said markup notation as encryption tags; and

means for inserting said generated encryption tags into said interim transient document to surround elements of said interim transient document for which said visibility policy of said elements in said input document have said non-null encryption requirement; and

said means for creating said output document further comprises means for encrypting those elements surrounded by said inserted encryption tags.

36. The system according to claim 27, wherein said encryption requirement further comprises specification of an encryption algorithm to be used when encrypting elements having that visibility policy.

37. The system according to claim 27, wherein said encryption requirement further comprises specification of an encryption algorithm strength value to be used when encrypting elements having that visibility policy.

38. The system according to claim 27, wherein said means for creating said output document further comprises:

means for generating a distinct symmetric key for each unique one of said communities identified by said visibility policy in said stored policy objects for each of said elements of said input document; and

means for encrypting each of said distinct symmetric keys to create member-specific versions thereof, further comprising:

means for determining whether each of said members of said community for which said distinct symmetric key was generated is an individual or a group; and

means for encrypting a separate version of said distinct symmetric key for each determined individual and for a clerk process associated with each determined group.

39. The system according to claim 38, wherein said means for encrypting a separate version of said distinct symmetric key creates one of said member-specific versions using, as input, a public key of one of said determined individuals or a public key of said clerk process.

40. The system according to claim 27, wherein said encrypted elements in said created output document are encrypted using a cipher block chaining mode encryption process.

41. The system according to claim 38, further comprising:

means for creating a key class for each of said unique communities, wherein said key class is associated with each of said encrypted elements of said output document for which members of this unique community are authorized viewers, and wherein said key class comprises: (1) an encryption algorithm identifier and key length used when encrypting said associated encrypted elements; (2) an identifier of each member of said unique community; and (3) one of said member-specific versions of said encrypted symmetric key for each of said identified community members.

42. The system according to claim 38, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

means for establishing a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy; and

means for decrypting, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

means for expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

means for identifying zero or more of said expanded groups of which said individual user or process is one of said group members;

means for decrypting, by said clerk process for each of said identified groups upon request by said client proxy, said member-specific version of said symmetric key, thereby creating a decrypted key for each of said identified groups; and

means for decrypting selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

43. The system according to claim 42, wherein:

said means for encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said means for decrypting said member-specific version of said symmetric key further comprises:

means for programmatically locating a clerk process for said identified group;

means for establishing a second session between said client proxy and said clerk process;

means for digitally signing said member-specific version, a certificate of said client proxy, and an identifier of said individual user or process by said client proxy, thereby creating a first digital signature;

means for sending said first digital signature, said member-specific version, said certificate, and said identifier from said client proxy to said clerk process on said second session;

means for receiving said sent first digital signature, said member-specific version, said certificate of said proxy, and said identifier by said clerk process;

means for verifying said first digital signature by said clerk process;

means for verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

means for decrypting said member-specific version using a private key of said clerk process, wherein said private key is associated with said public key of said clerk process;

means for re-encrypting said decrypted member-specific version using a public key of said client proxy, thereby creating a re-encrypted key;

means for digitally signing said re-encrypted key by said clerk process, thereby creating a second digital signature;

means for returning said second digital signature and said re-encrypted key from said clerk process to said client proxy on said second session;

means for receiving said second digital signature and said re-encrypted key by said client proxy;

means for verifying said second digital signature by said client proxy; and

means, operable in said client proxy, for decrypting said received re-encrypted key using a private key of said client proxy, creating said decrypted key; and

said means for decrypting selected ones of said encrypted elements in said output document is executed by said client proxy using said decrypted key.

44. The system according to claim 38, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

means for establishing a first mutually-authenticated secure session between device used by said individual user or process and said client proxy; and

means for decrypting, for said individual user or process upon determining that said individual user or process is a member of one of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

means for expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

means for identifying zero or more of said expanded groups of which said individual user or process is one of said group members; and

means for decrypting selected ones of said encrypted elements in said output document, by said client proxy, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

45. The system according to claim 44, wherein:

said means for encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process; and

said means for decrypting selected ones of said encrypted elements in said output document further comprises:

means for programmatically locating a clerk process for said identified group;

means for establishing a second mutually-authenticated secure session between said client proxy and said clerk process;

means for locating said member-specific version of said symmetric key which was encrypted using said public key of said clerk process, wherein said clerk process is associated with a group of which said individual user or process is a group member;

means for sending said located member-specific version from said client proxy to said clerk process, along with a certificate of said client proxy, an identifier of said individual user or process, and an element encrypted with said member-specific version, on said second secure session;

means for receiving said sent member-specific version, said certificate of said proxy, said identifier, and said element by said clerk process;

means for verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

means for decrypting said member-specific version using a private key of said clerk process;

means for decrypting said element using said decrypted member-specific version; and

means for returning said decrypted element from said clerk process to said client proxy on said second secure session.

46. The system according to claim 41, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

means for establishing a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy device; and

means for decrypting, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

means for expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

means for identifying zero or more of said key classes which identify said individual user or process as one of said group members;

means for decrypting, by said clerk process for each of said determined key classes, said member-specific version of said symmetric key in said key class which was encrypted using said public key of said clerk process, wherein said means for decrypting uses a private key of said clerk process, thereby creating a decrypted key; and

means for decrypting selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for said key class.

47. The system according to claim 42, wherein:

said means for encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said means for decrypting said member-specific version of said symmetric key further comprises:

means for programmatically locating a clerk process for said identified group; and

means for establishing a second mutually-authenticated secure session between said client proxy and said clerk process;

means for sending said member-specific version from said client proxy to said clerk process, along with a certificate of said client proxy and an identifier of said user or process, on said second secure session;

means for receiving said sent member-specific version, said certificate of said proxy, and said identifier by said clerk process;

means for verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

means for decrypting said member-specific version using a private key of said clerk process;

means for returning said decrypted member-specific version from said clerk process to said client proxy on said second secure session; and

means for receiving said decrypted member-specific version by said client proxy; and

said means for decrypting selected ones of said encrypted elements in said output document is executed by said client proxy using said received decrypted member-specific version.

48. The system according to claim 47, further comprising means for substituting a predetermined text message for any encrypted elements in said output document which cannot be decrypted for said individual user or process.

49. The system according to claim 44, wherein:

said means for encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process; and

said means for decrypting selected ones of said encrypted elements in said output document further comprises:

means for programmatically locating a clerk process for said identified group;

means for establishing a second session between said client proxy and said clerk process;

means for locating said member-specific version of said r symmetric key which was encrypted using said public key of said clerk process, wherein said clerk process is associated with a group of which said individual user or process is a group member; means for digitally signing said located member-specific version, a certificate of said client proxy, an identifier of said individual user or process, and an element encrypted with said member-specific version, thereby creating a first digital signature;

means for sending said first digital signature, said located member-specific version, said certificate, said identifier, and said element from said client proxy to said clerk process on said second session;

means for receiving said sent first digital signature, said member-specific version, said certificate, said identifier, and said element by said clerk process;

means for verifying said first digital signature by said clerk process;

means for verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

means for decrypting said member-specific version using a private key of said clerk process;

means for decrypting said element using said decrypted member-specific version;

means for re-encrypting said decrypted element using a public key of said client proxy, thereby creating a re-encrypted element;

means for digitally signing said re-encrypted element by said clerk process, thereby creating a second digital signature;

means for returning said second digital signature and said re-encrypted element from said clerk process to said client proxy on said second session;

means for receiving said second digital signature and said re-encrypted element by said client proxy; and

means for verifying said second digital signature by said client proxy.

50. The system according to claim 27, wherein said DTD is replaced by a schema.

51. The system according to claim 27, wherein said encryption requirement further comprises specification of an encryption key length.

52. The system according to claim 35, wherein said inserted encryption tags may surround either values of said elements or values and tags of said elements.

53. A method for enforcing security policy using style sheet processing, comprising:

providing an input document;

providing a Document Type Definition (DTD) that defines elements of said input document, wherein: (1) an attribute of at least one element defined in said DTD references one of a plurality of stored policy enforcement objects; (2) more than one of said references may reference a single stored policy enforcement object; and (3) each of said stored policy enforcement objects specifies a visibility policy for said referencing element or elements, said visibility policy identifying an encryption requirement for all elements having that visibility policy and a community whose members are authorized to view those elements;

applying one or more style sheets to said input document, thereby adding markup notation to each element of said input document for which said element definition in said DTD references one of said stored policy enforcement objects specifying a visibility policy with a non-null encryption requirement, resulting in creation of an interim transient document that indicates elements of said input document which are to be encrypted; and

creating an output document in which each element of said interim transient document for which markup notation has been added is encrypted in a manner that enables a client proxy acting on behalf of an individual user or process to decrypt the encrypted element using key distribution material associated with the output document when the individual user or process is one of the community members authorized to view that element.

54. The method according to claim 53, further comprising rendering said output document on a client device.

55. The method according to claim 53, wherein said markup notation in said interim transient document comprises tags of a markup language.

56. The method according to claim 53, wherein said input document is specified in an Extensible Markup Language (XML) notation.

57. The method according to claim 56, wherein said output document is specified in said XML notation.

58. The method according to claim 53, wherein said stored policy enforcement objects further comprise executable code for overriding a method for evaluating said elements of said input document, and wherein said of applying one or more style sheets further comprises invoking said executable code, thereby causing said markup notation to be added.

59. The method according to claim 58, wherein said style sheets are specified in an Extensible Stylesheet Language (XSL) notation.

60. The method according to claim 59, wherein said method is a value-of method of said XSL notation, and wherein said overriding said value-of method is by subclassing said value-of method.

61. The method according to claim 58, wherein:

said invoking further comprises:

generating said markup notation as encryption tags; and

inserting said generated encryption tags into said interim transient document to surround elements of said interim transient document for which said visibility policy of said elements in said input document have said non-null encryption requirement; and

said creating said output document further comprises of encrypting those elements surrounded by said inserted encryption tags.

62. The method according to claim 53, wherein said encryption requirement further comprises specification of an encryption algorithm to be used when encrypting elements having that visibility policy.

63. The method according to claim 53, wherein said encryption requirement further comprises specification of an encryption algorithm strength value to be used when encrypting elements having that visibility policy.

64. The method according to claim 53, wherein said said output document further comprises:

generating a distinct symmetric key for each unique one of said communities identified by said visibility policy in said stored policy objects for each of said elements of said input document; and

encrypting each of said distinct symmetric keys to create member-specific versions thereof, further comprising:

determining whether each of said members of said community for which said distinct symmetric key was generated is an individual or a group; and

encrypting a separate version of said distinct symmetric key for each determined individual and for a clerk process associated with each determined group.

65. The method according to claim 64, wherein said encrypting a separate version of said distinct symmetric key creates one of said member-specific versions using, as input, a public key of one of said determined individuals or a public key of said clerk process.

66. The method according to claim 53, wherein said encrypted elements in said created output document are encrypted using a cipher block chaining mode encryption process.

67. The method according to claim 64, further comprising:

creating a key class for each of said unique communities, wherein said key class is associated with each of said encrypted elements of said output document for which members of this unique community are authorized viewers, and wherein said key class comprises: (1) an encryption algorithm identifier and key length used when encrypting said associated encrypted elements; (2) an identifier of each member of said unique community; and (3) one of said member-specific versions of said encrypted symmetric key for each of said identified community members.

68. The method according to claim 64, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

establishing a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy; and

decrypting, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

identifying zero or more of said expanded groups of which said individual user or process is one of said group members;

decrypting, by said clerk process for each of said identified groups upon request by said client proxy, said member-specific version of said symmetric key, thereby creating a decrypted key for each of said identified groups; and

decrypting selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

69. The method according to claim 68, wherein:

said encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said decrypting said member-specific version of said symmetric key further comprises:

programmatically locating a clerk process for said identified group;

establishing a second session between said client proxy and said clerk process;

digitally signing said member-specific version, a certificate of said client proxy, and an identifier of said individual user or process by said client proxy, thereby creating a first digital signature;

sending said first digital signature, said member-specific version, said certificate, and said identifier from said client proxy to said clerk process on said second session;

receiving said sent first digital signature, said member-specific version, said certificate of said proxy, and said identifier by said clerk process;

verifying said first digital signature by said clerk process;

verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

decrypting said member-specific version using a private key of said clerk process, wherein said private key is associated with said public key of said clerk process;

re-encrypting said decrypted member-specific version using a public key of said client proxy, thereby creating a re-encrypted key;

digitally signing said re-encrypted key by said clerk process, thereby creating a second digital signature;

returning said second digital signature and said re-encrypted key from said clerk process to said client proxy on said second session;

receiving said second digital signature and said re-encrypted key by said client proxy;

verifying said second digital signature by said client proxy; and

decrypting, in said client proxy, said received re-encrypted key using a private key of said client proxy, creating said decrypted key; and said decrypting selected ones of said encrypted elements in said output document is executed by said client proxy using said decrypted key.

70. The method according to claim 64, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

establishing a first mutually-authenticated secure session between device used by said individual user or process and said client proxy; and

decrypting, for said individual user or process upon determining that said individual user or process is a member of one of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

identifying zero or more of said expanded groups of which said individual user or process is one of said group members; and

decrypting selected ones of said encrypted elements in said output document, by said client proxy, wherein said selected ones of said encrypted elements are those which were encrypted for one of said identified groups.

71. The method according to claim 67, wherein said identification of said communities further comprises identification of at least one of: (1) one or more individual users or processes which are community members; and (2) one or more groups which are community members, wherein each of said groups comprises one or more individual users or processes; and further comprising:

establishing a first mutually-authenticated secure session between a client device used by said individual user or process and said client proxy device; and

decrypting, for said individual user or process upon determining that said individual user or process is a member of one or more of said determined groups, only those encrypted elements in said output document for which any of said one or more of said determined groups is one of said authorized community members, further comprising:

expanding said determined groups to determine said individual users or processes that are group members in each of said expanded groups;

identifying zero or more of said key classes which identify said individual user or process as one of said group members;

decrypting, by said clerk process for each of said determined key classes, said member-specific version of said symmetric key in said key class which was encrypted using said public key of said clerk process, wherein said decrypting uses a private key of said clerk process, thereby creating a decrypted key; and

decrypting selected ones of said encrypted elements in said output document, by said client proxy using said decrypted keys, wherein said selected ones of said encrypted elements are those which were encrypted for said key class.

72. The method according to claim 68, wherein:

said encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process;

said decrypting said member-specific version of said symmetric key further comprises:

programmatically locating a clerk process for said identified group; and

establishing a second mutually-authenticated secure session between said client proxy and said clerk process;

sending said member-specific version from said client proxy to said clerk process, along with a certificate of said client proxy and an identifier of said user or process, on said second secure session;

receiving said sent member-specific version, said certificate of said proxy, and said identifier by said clerk process;

verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

decrypting said member-specific version using a private key of said clerk process;

returning said decrypted member-specific version from said clerk process to said client proxy on said second secure session; and

receiving said decrypted member-specific version by said client proxy; and

said decrypting selected ones of said encrypted elements in said output document is executed by said client proxy using said received decrypted member-specific version.

73. The method according to claim 72, further comprising substituting a predetermined text message for any encrypted elements in said output document which cannot be decrypted for said individual user or process.

74. The method according to claim 70, wherein:

said encrypting a separate version uses a public key of said clerk process as input when creating said member-specific version for said clerk process; and

said decrypting selected ones of said encrypted elements in said output document further comprises:

programmatically locating a clerk process for said identified group;

establishing a second session between said client proxy and said clerk process;

locating said member-specific version of said symmetric key which was encrypted using said public key of said clerk process, wherein said clerk process is associated with a group of which said individual user or process is a group member;

digitally signing said located member-specific version, a certificate of said client proxy, an identifier of said individual user or process, and an element encrypted with said member-specific version, thereby creating a first digital signature;

sending said first digital signature, said located member-specific version, said certificate, said identifier, and said element from said client proxy to said clerk process on said second session;

receiving said sent first digital signature, said member-specific version, said certificate, said identifier, and said element by said clerk process;

verifying said first digital signature by said clerk process;

verifying, by said clerk process, that said individual user or process and said client proxy are members of said identified group associated with said member-specific version;

decrypting said member-specific version using a private key of said clerk process;

decrypting said element using said decrypted member-specific version;

re-encrypting said decrypted element using a public key of said client proxy, thereby creating a re-encrypted element;

digitally signing said re-encrypted element by said clerk process, thereby creating a second digital signature;

returning said second digital signature and said re-encrypted element from said clerk process to said client proxy on said second session;

receiving said second digital signature and said re-encrypted element by said client proxy; and

verifying said second digital signature by said client proxy.

75. The method according to claim 53, wherein said DTD is replaced by a schema.

76. The method according to claim 53, wherein said encryption requirement further comprises specification of an encryption key length.

77. The method according to claim 61, wherein said inserted encryption tags may surround either values of said elements or values and tags of said elements.

Description

BACKGROUND OF THE INVENTION

Related Inventions

This application is related to the application having Ser. No. 09/422,430 entitled "Selective Data Encryption Using Style Sheet Processing", 09/422,537 entitled "Selective Data Encryption Using Style Sheet Processing for Decryption by a Group Clerk", and 09/422,431 entitled "Selective Data Encryption Using Style Sheet Processing for Decryption by a Key Recovery Agent", all assigned to the same assignee and filed concurrently herewith on Oct. 21, 1999.

1. Field of the Invention

The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for selectively encrypting one or more document elements using style sheet processing. The document may be an Extensible Markup Language (XML) document, and the style sheet processor may be an Extensible Stylesheet Language (XSL) processor.

2. Description of the Related Art

Cryptography is a security mechanism for protecting information from unintended disclosure by transforming the information into a form that is unreadable to humans, and unreadable to machines that are not specially adapted to reversing the transformation back to the original information content. The cryptographic transformation can be performed on data that is to be transmitted electronically, such as an electronic mail message or an electronic document requested by a user of the Internet, and is equally useful for data that is to be securely stored, such as the account records for customers of a bank or credit company.

The transformation process performed on the original data is referred to as "encryption". The process of reversing the transformation, to restore the original data, is referred to as "decryption". The terms "encipher" and "decipher" are also used to describe these processes, respectively. A mechanism that can both encipher and decipher is referred to as a "cipher".

Use of a "key" during the encryption and decryption processes helps make the cipher more difficult to break. A key is a randomly-generated number factored into operation of the encryption to make the result dependent on the key. The value used for the key in effect "personalizes" the algorithm, so that the same algorithm used on the same input data produces a different output for each different key value. When the value of this key is unknown to unauthorized persons, they will not be able to duplicate or to reverse the encryption.

One of the oldest and most common security systems today is what is known as a "private key" or "symmetric" security system. Private key systems involve two users, both of whom have a shared secret (or private) key for encrypting and decrypting information passed between them over a network. Before communications can occur, the two users must communicate in some secure manner to agree on this private key to ensure the key is known only to the two users. An example of a cipher used for private key security is the Data Encryption Algorithm ("DEA"). This algorithm was developed by scientists of the International Business Machines Corporation ("IBM"), and formed the basis of a United States federal standard known as the Data Encryption Standard ("DES"). Private key systems have a number of drawbacks in an open network environment such as the Internet, however, where users will conduct all communications over the open network environment and do not need or want the added overhead and expense of a separate secure means of exchanging key information before secure network communications occur. To address the limitations of private key systems, security systems known as "public key", or "asymmetric", systems evolved. In a public key system, a user has a key pair that consists of a private key and a public key, both keys being used to encrypt and decrypt messages. The private key is never to be divulged or used by anyone but the owner. The public key, on the other hand, is available to anyone who needs to use it. As an example of using the key pair for encrypting a message, the originator of a message encrypts the message using the receiver's public key. The receiver then decrypts the message with his private key. The algorithm and the public key used to encrypt a message can be exposed without comprising the security of the encrypted message, as only the holder of the associated private key will be able to successfully decrypt the message. A key pair can also be used to authenticate, or establish the identity of, a message originator. To use a key pair for authentication, the message originator digitally signs the message (or a digest thereof) using his own private key. The receiver decrypts the digital signature using the sender's public key. A common means of publishing a public key to be used for a particular receiver is in an X.509 certificate, also known as a "digital identity".

Public key encryption is generally computationally expensive, having numerous exponentiation operations. It also requires much longer key material than a symmetric key algorithm to provide equivalent security. Hence it is used sparingly, preferably only for cryptographic operations that need its unique properties. Symmetric key encryption is more widely used for bulk data encryption/decryption, because it demands less of the CPU, using primarily repeated shift, rotate, exclusive OR, and table lookup operations.

Public and symmetric key encryption methods are often combined. One example of their combination is the Secure Sockets Layer (SSL), and its follow-on replacement known as Transport Layer Security (TLS). Another example is the Internet Key Exchange (IKE) protocol of the IP Security Protocol, as defined in the Internet Engineering Task Force (IETF) document RFC 2411, "IP Security Document Roadmap".

In general, both the SSL and IKE protocols perform similar steps. First the parties are mutually authenticated using public key encryption, during which process X.509 certificates are exchanged and encryption algorithms negotiated. Then the first party creates a symmetric key and encrypts it using the second party's public key. The encrypted symmetric key is transferred to the second party, which then decrypts it using its private key. This process of negotiation and key transfer is called a "key agreement". A key agreement may have a predetermined expiration time, and the protocol may include means for subsequent key agreements. After completing a key agreement, the symmetric key can be used to perform efficient bulk data encryption between the parties.

The majority of current encryption techniques deal with encrypting an entire document for transmission to a known audience. Little attention has been given to the business-to-business security requirements of today's complex networking environments, where a document must flow asynchronously through a number of intermediate agents such as transcoders, gateways, and firewalls (where each agent may have a unique need to know different aspects of the transmitted information) and where the audience cannot be precisely determined beforehand.

Furthermore, key distribution in a complex, multi-business networking environment is a critical issue. If two parties repeatedly exchange encrypted data using the same key over and over again for successive documents (such as might occur when two businesses need to exchange transactional information in an on-going manner), then it makes it easier for a third party to crack the encryption and discover the document content of all the repeated transmissions. Thus, there must be a secure method for periodically distributing new keys between communicating parties. Likewise, if keys are changed and the subsequent keys are varied by an easily computed function of the base shared key, then the repeated transmissions would be easier to crack than if a random key were selected for each new transmission. It is therefore preferable to use a randomly-generated key value for each subsequent key. It is also preferable to use a new key for each document, to increase the security of the document. If a random key is used for each document, then a secure technique must exist to distribute this key to the receiver with a minimum of system overhead.

A document may be securely stored in an encrypted file system, or an encrypted file may be stored on a server where it can be accessed only by those possessing the decryption key. For the same reasons discussed above, each document should be encrypted with a different random key and a means must exist of distributing this key to all those who need to read the document.

A plaintext document can be protected during transmission by encrypting the transport-layer connection using SSL or TLS, or by creating an encrypted data-link-layer tunnel using the IP Security Protocol (IPSec) or the Layer 2 Tunneling protocol (L2TP). However, such methods of protection only apply to connection-oriented systems where an end-to-end session exists between the sender and receiver at the time of transmission. Both offer techniques whereby the encryption key hiding the data is changed at regular intervals over the life of the session.

These approaches (encrypting the file, the file system, or the session) are not useful in some situations, however. In situations where several agents (such as a series of intermediaries including gateways, transcoders, and/or firewalls) must handle the document in succession, it may be necessary for each intermediary to have access to some of the encrypted data elements within a file or document. This implies that the intermediaries need the key for decrypting the file, making protection of the key a logistical nightmare. When encryption is performed at the level of the entire document, then an intermediary that receives the key will have access to the entire document rather than just those elements that may be needed for this intermediary's particular function, thus increasing the potential for unauthorized agents to gain access to the security-sensitive information.

Another problem situation for existing techniques (such as relying on an encrypted session) is transmitting documents through store-and-forward systems such as message queuing (MQ), where the sender and receiver connect to a store-and-forward server at different times and never establish end-to-end connections to one another. In an MQ system, even if the connection between the sender and the MQ server is encrypted, and the connection between the MQ server and the receiver is encrypted, nevertheless the document is stored as plaintext on the MQ server for some period of time. This obviously creates a security exposure unless access to the MQ server is strictly controlled. It is unreasonable for the creator of security-sensitive information to rely on the MQ server (possibly including multiple such servers in a network path) to provide sufficient protection for preventing access to his plaintext document.

The existing approaches which have been described above (encrypting the session, encrypting the file system, or encrypting the file) are also not useful in the situation where the target client device has such limited CPU processing power that it cannot perform the necessary encryption/decryption operations, or performs them so slowly as to make the system unusable.

Electronic commerce is becoming increasingly important in today's global economy. Electronic commerce, also known as "e-commerce" or "e-business", involves the secure transfer of business-critical data to selected recipients over non-secure public networks such as the Internet. Consider the overall life cycle of an e-business document. In the general case, the document passes through various hands or agents, which differ greatly in terms of their "need to know" specific data elements within the document. Consider an employee record or document generated by an Enterprise Resource Planning (ERP) software application. This employee document is an example of a single document that may contain elements needing different types of access protection. The document may contain public information such as the employee's name, employee serial number, and date of hire. This information may need to be in plaintext form so the document is searchable in a database. The employee document may also contain salary information that only managers may see. It may also contain payroll information that only the payroll department should view. Finally it may contain medical data that only medical personnel should see. In addition, the employee should be able to view the entire contents of his own employee document. Besides transit over a network, the document may pass through agents that store and forward the data, such as a company repository which records and time stamps transmitted and received documents for legal purposes, an e-mail system, an e-mail archive, an e-mail screening program on a firewall, and so forth. It is unreasonable to fully trust all the intermediaries in such an electronic commerce system. Furthermore, at the time of document construction, it is virtually impossible to foresee who all the ultimate consumers (i.e. requesting users or application programs) of the data may be, or which intermediary agents may handle the data, and yet the data must be protected. It is also unreasonable to create a customized document for each potential consumer, or to create a customized document upon each request by a different consumer, where the customized document would contain only those elements for which the consumer is authorized.

Commonly-assigned U.S. patent application Ser. No. 09/240,387, filed Jan. 29, 1999, titled "Method, System, and Apparatus for Selecting Encryption Levels Based on Policy Profiling" suggest tagging data elements in Extensible Markup Language ("XML") documents with field-level or record-level security information. By inspecting this security-level information and consulting directory entries concerning an individual's access privileges, a server responding to a document request suppresses any document elements for which the requester is unauthorized, determines the encryption algorithm and key length required by the most restrictive remaining element (i.e. the remaining element having the highest-level security requirements), and encrypts the entire resulting filtered document accordingly. This invention does not solve the problem of encrypted documents with multiple authorized receivers and agents, each with a different need-to-know (i.e. it does not restrict the ability to read certain fields of a document to certain individuals or groups). Nor does it address the problem of client devices with insufficient processing power to decrypt received documents.

Several solutions for distributing encrypted key material along with the encrypted document to which the key applies are known in the art. The SMIME industry standard defined by the IETF is used in secure e-mail transmission, providing an encapsulation of digitally signed and encrypted objects. (See SMIME charter information that is available from the IETF for more information.) The Lotus Notes® software uses a proprietary implementation for key distribution. (See "Lotus Notes" is a registered trademark of Lotus Development Corporation and/or IBM, and more information about Lotus Notes is available by contacting IBM.) However, neither of these existing approaches suggest that individual document fields be encrypted (and other fields not encrypted). Nor do they suggest having different authorized viewing communities, or using multiple and/or different encryption algorithms and/or keys, for different fields in a document that need different levels of security (nor is a capability for distributing multiple keys per document available).

Accordingly, what is needed is a technique with which security policy can be efficiently enforced in a complex distributed network computing environment, incorporating many complex factors such as those described above.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a technique for enforcing security policy efficiently in a complex distributed networking environment.

Another object of the present invention is to provide this technique in a manner that enables data to be protected throughout the business process, and throughout transmission between agents in a network path from a document server to a document receiver, making security-sensitive information in the document visible only to those agents having a need to know the information while protecting the information from disclosure to other parties.

Yet another object of the present invention is to provide this technique whereby each of the different elements within a single document may use a different security policy, including the ability to use different security algorithms, keys, and key lengths from one element to another.

Still another object of the present invention is to provide this technique by applying style sheets to documents encoded in tag languages such as the Extensible Markup Language.

Yet another object of the present invention is to provide this technique whereby a client proxy assists in decrypting a selectively encrypted document on behalf of a requesting user or process.

A further object of the present invention is to provide a key distribution technique which enables a different key to be used for each encrypted document or document element, where each key used can be distributed to all document receivers without creating a security exposure.

Another object of the present invention is to provide this key distribution technique in a manner that enables an encryption key to be recovered whether the encrypted document resides in a file system or is in a queue en route to its target audience.

A further object of the present invention is to provide a selective data encryption technique that reduces the amount of data that must be encrypted to provide a given level of security, thereby improving the performance of security processing for client devices with limited capabilities.

Still another object of the present invention is to provide a technique for recovering the key(s) used to encrypt elements of a document.

Another object of the present invention is to provide these techniques in a backward-compatible manner, such that existing style sheets continue to function properly.

Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.

To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for enforcing security policy using style sheet processing. In one embodiment, this technique comprises: providing an input document; providing one or more stored policy enforcement objects, wherein each of the stored policy enforcement objects specifies a security policy to be associated with zero or more elements of the input document; providing a Document Type Definition (DTD) corresponding to the input document, wherein the DTD has been augmented with one or more references to selected ones of the stored policy enforcement objects; executing an augmented style sheet processor; requesting, from a user or process on a client device, an encrypted output document; receiving the request at a client proxy device; executing an augmented document processor by a client proxy on the client proxy device; and transmitting a result document to the requesting client device. Executing the augmented style sheet processor preferably further comprises: loading the DTD; resolving each of the one or more references in the loaded DTD; instantiating the policy enforcement objects associated with the resolved references; executing selected ones of the instantiated policy enforcement objects during application of one or more style sheets to the input document, wherein a result of executing the selected ones is an interim transient document reflecting the execution; generating one or more random encryption keys; encrypting selected elements of the interim transient document, wherein a particular one of the generated random encryption keys may be used to encrypt one or more of the selected elements, while leaving zero or more other elements of the interim transient document unencrypted; encrypting each of the one or more random encryption keys; and creating an encrypted output document comprising the zero or more other unencrypted elements, said selected encrypted elements, and said encrypted encryption keys. Executing the augmented document processor preferably further comprises assisting in decrypting the requested output document on behalf of the requesting user or process, thereby creating a result document.

Alternatively, the DTD may be replaced by a schema.

This technique may also comprise rendering the result document on the requesting client device.

The interim transient document may comprise one or more encryption tags identifying elements needing encryption. The input document may be specified in an Extensible Markup Language (XML) notation, and the result document may also specified in this XML notation. The style sheets may be specified in an Extensible Stylesheet Language (XSL) notation.

The stored policy enforcement objects may further comprise executable code for overriding a method for evaluating the elements of the input document, and wherein executing selected ones further comprises overriding this method for evaluating. This method may be a value-of method of the XSL notation, and overriding the value-of method may be by subclassing this value-of method. This overriding may further comprise generating encryption tags, and inserting the generated encryption tags into the interim transient document to surround elements of the interim transient document which are determined to require encryption. Encrypting selected elements may further comprise encrypting those elements surrounded by the inserted encryption tags.

Each of the instantiated policy enforcement objects may further comprise: a specification of a community that is authorized to view the elements associated with the security policy; and an encryption requirement for the elements associated with the security policy. This encryption requirement may further comprise specification of an encryption algorithm. Or, this encryption requirement may further comprise specification of an encryption algorithm strength value, and/or specification of an encryption key length. The encryption requirement may have a null value to indicate that the specified security policy does not require encryption.

Encrypting the encryption keys may further comprise encrypting a different version of each of the random encryption keys for each of one or more members of each of zero or more of the communities which uses the encryption key, and wherein each of the different versions is encrypted using a public key of the community member for which the different version was encrypted.

Encrypting the selected elements may use a cipher block chaining mode encryption process.

This technique may further comprise: creating a key class for each unique community, wherein the key class is associated with each of the encrypted elements for which this unique community is an authorized viewer, and wherein the key class comprises: (1) a strongest encryption requirement of the associated encrypted elements; (2) an identifier of each member of the unique community; and (3) one of the different versions of the encrypted encryption key for each of the identified community members. Generating the one or more random encryption keys may generate a particular one of the random encryption keys for each of the key classes, wherein each of the different versions in a particular key class is encrypted from the generated encryption key generated for the key class. Encryption of the selected elements may use that one of the particular random encryption keys which was generated for the key class with which the selected element is associated. This technique may further comprise: establishing a first mutually-authenticated secure session between the client device and the client proxy device. The specification of the communities may further comprise specification of at least one of: (1) one or more individual users or processes which are community members, and (2) one or more groups which are community members, wherein each of the groups comprises one or more individual users or processes. Decrypting the requested output document may further comprise: expanding the one or more groups of the communities to determine the individual users or processes in each of the expanded groups; determining zero or more of the key classes which identify the requesting user or process as one of the expanded group members; decrypting, for each of the determined key classes, the different version of the random encryption key in the key class which was encrypted using the public key of the one member, wherein the decrypting uses a private key of the one member which is associated with the public key which was used for encryption, thereby creating a decrypted key; and decrypting selected ones of the encrypted elements in the requested output document using the decrypted keys, wherein the selected ones of the encrypted elements are those which were encrypted for the key class. Rendering the result document may further comprise rendering the decrypted selected ones and the other unencrypted elements.

In one aspect, the technique may further comprise: establishing a first mutually-authenticated secure session between the client device and the client proxy device. The specification of the communities may further comprise specification of at least one of: (1) one or more individual users or processes which are community members, and (2) one or more groups which are community members, wherein each of the groups comprises one or more individual users or processes. Decrypting the requested output document may further comprise: expanding the one or more groups of the communities to determine the individual users or processes in each of the expanded groups; determining zero or more of the expanded communities of which the requesting user or process is one of the expanded group members; decrypting, for each of the determined communities, the different version of the random encryption key which was encrypted using the public key of the one member, wherein the one member is the expanded group of which the requesting user or process is one of the expanded group members, thereby creating a decrypted key for each of the determined communities; and decrypting selected ones of the encrypted elements in the requested output document using the decrypted keys, wherein the selected ones of the encrypted elements are those which were encrypted for one of the determined communities. Rendering the result document may further comprise rendering the decrypted selected ones and the other unencrypted elements.

Decrypting the different version for each of the determined communities may further comprise: locating a group clerk for the determined community; establishing a second session between the client proxy and the group clerk; digitally signing the different version, a certificate of the client proxy, and an identifier of the requesting user or process, thereby creating a first digital signature; sending the first digital signature, the different version, the certificate, and the identifier from the client proxy to the group clerk on the second session; receiving the sent first digital signature, the different version, the certificate of said proxy, and the identifier by the group clerk; verifying the first digital signature by the group clerk; verifying, by the group clerk, that the requesting user or process and the client proxy are authorized members of the determined community associated with the different version; decrypting the different version using a private key of the one member which is associated with the public key which was used for encryption; re-encrypting the decrypted different version using a public key of the client proxy, thereby creating a re-encrypted key; digitally signing the re-encrypted key by the group clerk, thereby creating a second digital signature; returning the second digital signature and the re-encrypted key from the group clerk to the client proxy on the second session; receiving the second digital signature and the re-encrypted key by the client proxy; verifying the second digital signature by the client proxy; and decrypting, in the client proxy, the received re-encrypted key using a private key of the client proxy, creating the decrypted key. Decrypting the selected ones of the encrypted elements in the requested output document may be executed by the client proxy.

Or, decrypting decrypting the different version for each of the determined communities may further comprise: locating a group clerk for the determined community; establishing a second mutually-authenticated secure session between the client proxy and the group clerk; sending the different version from the client proxy to the group clerk, along with a certificate of the client proxy and an identifier of the requesting user or process, on the second secure session; receiving the sent different version, the certificate of the proxy, and the identifier by the group clerk; verifying, by the group clerk, that the requesting user or process and the client proxy are authorized members of the determined community associated with the different version; decrypting the different version using a private key of the one member which is associated with the public key which was used for encryption; returning the decrypted different version from the group clerk to the client proxy on the second secure session; and receiving the decrypted different version by the client proxy. Decrypting the selected ones of the encrypted elements in the requested output document may be executed by the client proxy using the received decrypted different version.

In another aspect, the technique may further comprise establishing a first mutually-authenticated secure session between the client device and the client proxy device. The specification of the communities may further comprise specification of at least one of: (1) one or more individual users or processes which are community members, and (2) one or more groups which are community members, wherein each of the groups comprises one or more individual users or processes. Decrypting the requested output document may further comprise: expanding the one or more groups of the communities to determine the individual users or processes in each of the expanded groups; determining zero or more of the expanded communities of which the requesting user or process is one of the expanded group members; and decrypting selected ones of the encrypted elements in the requested output document, wherein the selected ones of the encrypted elements are those which were encrypted for one of the determined communities. Rendering the result document may further comprise rendering the returned decrypted elements and the other unencrypted elements.

In this aspect, decrypting the selected ones of said encrypted elements in the requested output document may further comprise: locating a group clerk for the determined community; establishing a second mutually-authenticated secure session between the client proxy and the group clerk; locating the different version of the random encryption key which was encrypted using the public key of the one member, wherein the one member is the expanded group of which the requesting user or process is one of the expanded group members; sending the located different version from the client proxy to the group clerk, along with a certificate of the client proxy, an identifier of the requesting user or process, and an element encrypted with the different version on the second secure session; receiving the sent different version, the certificate of the proxy, the identifier, and the element by the group clerk; verifying, by the group clerk, that the requesting user or process and the client proxy are authorized members of the determined community associated with the different version; decrypting the different version using a private key of the one member which is associated with the public key which was used for encryption; decrypting the element using the decrypted different version; and returning the decrypted element from the group clerk to the client proxy on the second secure session.

Or, decrypting the selected ones of the encrypted elements in the requested output document may further comprise: locating a group clerk for the determined community; establishing a second session between the client proxy and the group clerk; locating the different version of the random encryption key which was encrypted using the public key of the one member, wherein the one member is the expanded group of which the requesting user or process is one of the expanded group members; digitally signing the located different version, a certificate of the client proxy, an identifier of the requesting user or process, and an element encrypted with the different version, thereby creating a first digital signature; sending the first digital signature, the located different version, the certificate, the identifier, and the element from the client proxy to the group clerk on the second session; receiving the sent first digital signature, the different version, the certificate, the identifier, and the element by the group clerk; verifying the first digital signature by the group clerk; verifying, by the group clerk, that the requesting user or process and the client proxy are authorized members of the determined community associated with the different version; decrypting the different version using a private key of the one member which is associated with the public key which was used for encryption; decrypting the element using the decrypted different version; re-encrypting the decrypted element using a public key of the client proxy, thereby creating a re-encrypted element; digitally signing the re-encrypted element by the group clerk, thereby creating a second digital signature; returning the second digital signature and the re-encrypted element from the group clerk to the client proxy on the second session; receiving the second digital signature and the re-encrypted element by the client proxy; and verifying the second digital signature by the client proxy.

Rendering the result document may further comprise rendering a substitute text message for any of the selected encrypted elements in the requested output document which cannot be decrypted by decrypting the requested output document.

The inserted encryption tags may surround either values of the elements or values and tags of the elements.

The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer workstation environment in which the present invention may be practiced;

FIG. 2 is a diagram of a networked computing environment in which the present invention may be practiced;

FIG. 3 depicts a Document Type Definition (DID) that has been augmented with security policy information, according to the preferred embodiments of the present invention;

FIGS. 4A-4C illustrate an example of an employee document on which the present invention may operate; an interim representation of the employee document after being augmented with security information; and the same document after encryption has been performed;

FIGS. 5A-5C depict examples of record or object formats that may be used with the preferred embodiments of the present invention;

FIG. 6 provides an overview of the components involved in the preferred embodiments of the present invention, and the general data flows between them; and

FIGS. 7 through 12 illustrate flow charts depicting the logic with which the preferred embodiments of the present invention may be implemented.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a representative workstation hardware environment in which the present invention may be practiced. The environment of FIG. 1 comprises a representative single user computer workstation 10, such as a personal computer, including related peripheral devices. The workstation 10 includes a microprocessor 12 and a bus 14 employed to connect and enable communication between the microprocessor 12 and the components of the workstation 10 in accordance with known techniques. The workstation 10 typically includes a user interface adapter 16, which connects the microprocessor 12 via the bus 14 to one or more interface devices, such as a keyboard 18, mouse 20, and/or other interface devices 22, which can be any user interface device, such as a touch sensitive screen, digitized entry pad, etc. The bus 14 also connects a display device 24, such as an LCD screen or monitor, to the microprocessor 12 via a display adapter 26. The bus 14 also connects the microprocessor 12 to memory 28 and long-term storage 30 which can include a hard drive, diskette drive, tape drive, etc.

The workstation 10 may communicate with other computers or networks of computers, for example via a communications channel or modem 32. Alternatively, the workstation 10 may communicate using a wireless interface at 32, such as a CDPD (cellular digital packet data) card. The workstation 10 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or the workstation 10 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.

FIG. 2 illustrates a data processing network 40 in which the present invention may be practiced. The data processing network 40 may include a plurality of individual networks, such as wireless network 42 and network 44, each of which may include a plurality of individual workstations 10. Additionally, as those skilled in the art will appreciate, one or more LANs may be included (not shown), where a LAN may comprise a plurality of intelligent workstations coupled to a host processor.

Still referring to FIG. 2, the networks 42 and 44 may also include mainframe computers or servers, such as a gateway computer 46 or application server 47 (which may access a data repository 48). A gateway computer 46 serves as a point of entry into each network 44. The gateway 46 may be preferably coupled to another network 42 by means of a communications link 50a. The gateway 46 may also be directly coupled to one or more workstations 10 using a communications link 50b, 50c. The gateway computer 46 may be implemented utilizing an Enterprise Systems Architecture/370 available from IBM, an Enterprise Systems Architecture/390 computer, etc. Depending on the application, a midrange computer, such as an Application System/400 (also known as an AS/400) may be employed. ("Enterprise Systems Architecture/370" is a trademark of IBM; "Enterprise Systems Architecture/390", "Application System/400", and "AS/400" are registered trademarks of IBM.)

The gateway computer 46 may also be coupled 49 to a storage device (such as data repository 48). Further, the gateway 46 may be directly or indirectly coupled to one or more workstations 10.

Those skilled in the art will appreciate that the gateway computer 46 may be located a great geographic distance from the network 42, and similarly, the workstations 10 may be located a substantial distance from the networks 42 and 44. For example, the network 42 may be located in California, while the gateway 46 may be located in Texas, and one or more of the workstations 10 may be located in New York. The workstations 10 may connect to the wireless network 42 using a networking protocol such as the Transmission Control Protocol/Internet Protocol ("TCP/IP") over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. The wireless network 42 preferably connects to the gateway 46 using a network connection 50a such as TCP or UDP (User Datagram Protocol) over IP, X.25, Frame Relay, ISDN (Integrated Services Digital Network), PSTN (Public Switched Telephone Network), etc. The workstations 10 may alternatively connect directly to the gateway 46 using dial connections 50b or 50c. Further, the wireless network 42 and network 44 may connect to one or more other networks (not shown), in an analogous manner to that depicted in FIG. 2.

Software programming code which embodies the present invention is typically accessed by the microprocessor 12 of server 47 or an intermediary such as gateway 46 (hereinafter referred to simply as an intermediary)—and by workstation 10 in several embodiments of the present invention—from long-term storage media 30 of some type, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed to users from the memory or storage of one computer system over a network of some type to other computer systems for use by users of such other systems. Alternatively, the programming code may be embodied in the memory 28, and accessed by the microprocessor 12 using the bus 14. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.

A user of the present invention may connect his computer to a server using a wireline connection, or a wireless connection. Wireline connections are those that use physical media such as cables and telephone lines, whereas wireless connections use media such as satellite links, radio frequency waves, and infrared waves. Many connection techniques can be used with these various media, such as: using the computer's modem to establish a connection over a telephone line; using a LAN card such as Token Ring or Ethernet; using a cellular modem to establish a wireless connection; etc. The user's computer may be any type of computer processor, including laptop, handheld or mobile computers; vehicle-mounted devices; desktop computers; mainframe computers; etc., having processing (and optionally communication) capabilities. The remote server and the intermediary, similarly, can be one of any number of different types of computer which have processing and communication capabilities. These techniques are well known in the art, and the hardware devices and software which enable their use are readily available. Hereinafter, the user's computer will be referred to equivalently as a "workstation", "device", or "computer", and use of any of these terms or the term "server" refers to any of the types of computing devices described above.

In the preferred embodiments, the present invention is implemented as one or more computer software programs. The software may operate on a server, on a user workstation, and/or on an intermediary in a network, as one or more modules (also referred to as code subroutines, or "objects" in object-oriented programming) which are invoked upon request. The server or intermediary may be providing services in an Internet environment, in a corporate intranet or extranet, or in any other network environment.

The present invention defines a novel technique for selectively enforcing security policy in a distributed network computing environment using style sheet processing. A policy-driven augmented style sheet processor is used to create a selectively-encrypted document carrying key-distribution material, such that by using an augmented document processor an agent can recover a Document Object Model ("DOM") containing only the information elements for which the agent is authorized. In the preferred embodiments, the augmented style sheet processor is an augmented Extensible Stylesheet Language ("XSL") processor, the document is an XML document, and the augmented document processor is an augmented XML processing engine. Documents encoded in this fashion support improved group collaboration models, giving more people easier access to information for which they are authorized, while protecting sensitive data from unauthorized agents. The present invention also provides a novel, efficient way to recover encrypted data from documents encoded according to the inventive techniques disclosed herein.

A number of terms to be used in the description of the preferred embodiments will now be defined.

"Community" refers to the collection of viewers to which a given authorization policy applies, in regard to a specific class of information. In the employee record example previously discussed, "all managers" or "employee plus all medical personnel" are examples of potential communities. In the preferred embodiments, a community is represented by the distinguished names (DNs) of one or more individuals and/or groups comprising that community. For each DN there is a corresponding X.509 certificate. In the preferred embodiments of the present invention, whenever a group can be represented by a single certificate, that group certificate is preferred in place of all the individual certificates for all the group's members (as will be described in more detail with reference to FIG. 7A).
"Element visibility" is a policy that defines to whom (where this may be people and/or application programs or processes) an element defined by a DTD (or alternatively, by a schema) should be made visible, and under what conditions. According to the preferred embodiments, a visibility policy defines (1) the minimum encryption strength required for the element, and (2) the community that is authorized to see the element's value. "Minimum encryption strength" can be resolved to a specific encryption algorithm and key length (e.g. by consulting a directory or lookup table, etc.). Encryption that is stronger than required can satisfy an element visibility policy, but weaker-than-required encryption is never satisfactory. (Note that while the preferred embodiments discuss dynamically determining an algorithm and key length to provide the minimum encryption strength which has been specified in a policy object, in an alternative approach the algorithm identifier and key length may be specified directly in the policy object without deviating from the scope of the present invention. In this case, a determination as to which of multiple algorithms and associated key lengths provides a stronger encryption may be made by using a look-up table in which the pertinent values are arranged in a particular order of strength, by coding the relative strength values directly into an implementation, etc. It will be obvious to one of ordinary skill in the art how the descriptions of the preferred embodiments are to be modified when using this alternative approach.)
"Group" refers to a collection of one or more individuals or processes (i.e. application entities) who are authorized members of a community. Preferably, a group is represented by a named object in an LDAP directory. (Alternatively, other storage repositories may be used.) The information stored for a particular group comprises: (1) the group's X.509 certificate; (2) a pointer (or other identifier) identifying a group clerk or clerks; and (3) pointers to each group member. (The X.509 certificates for each group member are then contained in, or pointed to from, the group member's stored information.) If a proxy or agent is authorized to act on behalf of a group or group member, the proxy is also identified as a group member.
"Group clerk" refers to a process that maintains the private key for a group, rather than having each group member store the private key. The clerk is contacted during the decryption of secure document content being served to a group member, and provides information for use in the decryption process. Each group has at least one clerk. Multiple clerks may be identified for a single group for purposes of hot backup and/or load distribution, where each such clerk has equivalent processing privileges on behalf of a particular group.

Commonly-assigned U.S. Pat. No. 6,585,778 (Ser. No. 09/385,899, filed Aug. 30, 1999), titled "Enforcing Data Policy Using Style Sheet Processing", discloses a technique for controlling the content of a document using stored policy information. This invention, referred to hereinafter as the "referenced invention", is incorporated herein by reference. The present invention defines an extension to the stored policy objects defined in this referenced invention, whereby the stored policy objects further comprise attributes specifying the element visibility information described above. These extensions will be described in more detail with reference to FIGS. 7A through 7C.

The employee record example previously discussed will be used to illustrate the benefits as well as the implementation of the present invention. Suppose a company maintains a database (or other repository) of information about its employees, and further suppose that the stored record for each employee comprises the employee's name, employee serial number, data of hire, current salary, and any pertinent medical conditions. FIG. 3 depicts an example of a DTD 300 that may be used to describe the data in the record for an employee of this company. As is well known in the art, a DTD is a definition of the structure of an XML document, and is encoded in a file which is intended to be processed, along with the file containing a particular XML document, by an XML parser. The DTD tells the parser how to interpret the document which was created according to that DTD. (Note that while the present invention is described with reference to information specified in a DTD, the information may be specified in other semantically equivalent forms. In particular, the schemas which are currently being standardized by the World Wide Web Consortium or "W3C" may be used instead of DTDs. Refer to "XML Schema Part 1: Structures", which is available from the W3C, for more information. References herein to a DTD are to be interpreted as applying equally to a schema.) This DTD 300 includes entries for the employee name ("empl_name") 350, the employee serial number ("ser_nbr") 360, "date_of_hire" 370, current salary ("curr_") 380, and "medical _condition" 390.

This DTD 300 has been augmented with data policy information which, according to the present invention, includes element visibility information that can be used to selectively encrypt the associated document elements, thereby restricting access to the values of the document elements. As defined by the referenced invention, data policy (as extended by the present invention to include element visibility) can be associated with a document's data structures by modifying the DTD for the document to specify the URI (Uniform Resource Indicator) of each applicable policy. Three different data policies, each with different element visibility, will be used to illustrate the employee record example. Each policy will now be discussed, along with the element visibility information specified in the stored policy objects.

The policy used for the employee name, serial number, and date of hire is to allow unrestricted access to these data items. Data policy information to enforce this unrestricted access policy (as well as any policies used with the present invention) is preferably stored in a directory database, such as an LDAP database. The stored policy can then be retrieved by sending a message to the database engine, specifying the URI of the desired information, as will be discussed in more detail below. An example URI that may be used to retrieve the "unrestricted" policy information for this example is shown at element 332. Note that XML parameter entity substitution has been used in this example DTD 300, whereby the relatively long URIs 312, 322, 332 are specified as the value associated with shorter entity names 311, 321, 331. These shorter names are then used within the attribute list declarations, such as "%unrestricted" 355 in the empl_name declaration 350. This approach has the advantage of reducing the number of characters within the DTD when a URI is used repeatedly, and also makes the attribute list declarations more intuitive and easier to read. (As will be obvious, the URIs may alternatively be replicated throughout the DTD without deviating from the scope of the present invention.) Note that the URIs 312, 322, 332 have been depicted as relative distinguished names (RDNs) for the stored data policy information. These RDNs are simply a unique identifier for storing the object in a directory. Alternative storage techniques (and identifications thereof) may be used without deviating from the scope of the present invention.

Because access to the employee name, serial number, and date of hire is to be unrestricted, the values of these document elements will not be encrypted in the document to be returned to a document requester. Thus, the minimum security strength and community attributes of the policy object stored at location 332 are preferably set to null values (to indicate that encryption is not required).

Another policy used with the employee record example is to limit access to an employee's current salary to the employee himself, any managers of the company, and any employees within the company's human resources (HR) department. The URI for this policy has been given the entity name "empl_mgr_hr" 311, and is specified 385 in the attribute list declaration for curr_salary 380. The stored policy object located at URI 312 will specify the encryption strength deemed to be appropriate for protecting this employee salary information from unauthorized access. The community attribute in the policy object will preferably comprise three distinguished name values—one for the individual employee, one for the group comprising all managers, and one for the group comprising all employees in the HR department. (Alternatively, a separate DN entry could be specified for each member of the managers group and/or each member of the HR department, but as previously stated, it is preferable to represent all members of a group by a group DN when the group DN is available.)

The third policy of this example is used with the medical conditions information. Suppose that access to this information is to be restricted to the employee to which it pertains, and any employee working in the medical department. Information for enforcing this policy (including its element visibility restrictions), which has been given the entity name "empl_medical" 321, is stored at URI 322. The policy is associated with the medical_condition 390 element by specifying 395 the URI 322 through its entity name 321. The stored policy object located at URI 322 will specify the encryption strength appropriate for protecting the employee's medical condition information, and the community attribute in the policy object will preferably comprise two distinguished name values—one for the individual employee and one for the group comprising all employees in the medical department. (As described above, a separate DN entry could alternatively be specified for each member of the medical group, without deviating from the scope of the present invention.)

The solution used in the preferred embodiments—of specifying a data policy URI within a data element's attribute fist declaration—allows one to encode the most complex arrangement possible, that being a different policy and different element visibility for each data element (even though this situation is likely never to occur in actual use). As can be seen from the example DTD in FIG. 3, the preferred embodiments use standard DTD markups with a special convention. In this manner, processes unaware of the policy convention will still see totally valid XML syntax which passes all standard validation tests when the respective document contains policy markups. A beneficial side effect of this is that if the document generated by a data source uses a URI DTD reference (such as element 405 of document 400 in FIG. 4A, which refers to the storage location of the example DTD 300 of FIG. 3), then an enterprise data policy administrator can cause data policy and element visibility restrictions to be applied to such generated documents simply by modifying the referenced DTD (to add policy definitions and element visibility, or perhaps change the policy definitions and element visibility which have already been added). No change to the code which generates the XML source documents at the data source needs to be made to cause the appropriate encryption and access restrictions to be applied.

By convention, the DTD policy markup of the preferred embodiments uses a fixed attribute (see, e.g., 354 of FIG. 3) from a policy namespace (see 352 of FIG. 3) to indicate the URI of the policy which is to be applied to an XML element. As is known in the art, using a namespace prefix enables differentiation among tags that might otherwise be considered duplicates. Setting a fixed value guarantees that the value of this attribute (such as the value 355 of attribute 353) will be available to the XSL processor whenever it processes the element (such as the emp_name element 351).

FIG. 4A illustrates a simple source document 400 resulting from retrieval of the employee record information for a particular employee (identified by name at 402 and by serial number at 404), before the processing of the present invention has occurred. This source document 400 contains plaintext information for all document elements of the employee record, including the security-sensitive elements "curr_salary" 408 and "medical_condition" 410 (which are to be encrypted using the stored policy objects specified at 385 and 395 of FIG. 3, respectively). The example DTD of FIG. 3 would then be used by an augmented XSL processor, as described below, to apply the desired data policy and element visibility rules to produce a selectively-encrypted version of this document 400 before publishing the encrypted document or sending the encrypted document to the requesting client. Note that there is no policy markup nor any reference to policy in the document 400, and hence, as stated above, there was no need to modify the XML emitter of the document-generating application at the data source.

Skipping for now the discussion of FIG. 4B (comprising FIGS. 4B1 and 4B2) and proceeding to FIG. 4C (comprising FIGS. 4C1 and 4C2), a representative example of a selectively-encrypted document containing the information from source document 400 is shown at 450. Using the policy and element visibility examples discussed with reference to FIG. 3, if the requesting user is the employee 402, this user will be able to recover (i.e. decrypt) the protected values of both curr_salary 408 and medical_condition 410 from the encrypted fields 452, 454 (where these fields 452, 454 contain values used for illustrative purposes only) of document 450 which is transmitted in response to his request. In addition, because selectively-encrypted documents are not customized for a particular requesting user according to the present invention, but rather carry sufficient key distribution material to enable access by any authorized user, employee 402 will be able to recover the protected values 453, 455 from fields 452, 454 even if he was not the original requester of the encrypted document. Similarly, a user who is a manager in this company or who works in the HR department will be able to recover the value 453 of encrypted field 452 if he receives document 450, because these users are within the authorized community for corresponding document element 408, and a user in the medical department will be able to recover the value 455 of encrypted field 454. If a user who is not a manager, is not the individual employee, and does not work in either the HR or medical department receives encrypted document 450, this user will only be able to view the values of unrestricted document elements 402, 404, and 406, even though the values of the curr_salary and medical_condition elements are contained within this user's copy of the document 450. The manner in which an augmented style sheet processor applies the data policy and visibility rules to yield these results according to the present invention will be discussed below. (Style sheet processing may perform additional changes to source document 400 in the process of generating an encrypted document, such as formatting the employee record information into a predetermined layout or performing target-specific transformation unrelated to data policy and element visibility, using techniques which are known in the art and do not form part of the present invention.)

According to the preferred embodiments of the present invention, the process of selectively encrypting a document is implemented as two logical phases. The first phase is referred to herein as the "preprocessing" phase. The augmented DTD 300 described with reference to FIG. 3, a source document such as document 400 of FIG. 4A, and the stored policy objects and their visibility rules (not shown) are used as input to the preprocessing phase. The second phase is referred to herein as the "post processing" phase. Encrypted document 450, including its embedded key distribution material 460, is generated as a result of the post processing phase.

FIGS. 5A-5C show preferred embodiments of the format of records or objects (referred to hereinafter as "objects" for ease of reference) that are created and used during the processing of the present invention to perform the selective encryption technique disclosed herein, and which are also used during the corresponding decryption processes. The content and format of each of these objects will now be described. (The manner in which these objects are created and used during the processing of the preferred embodiments will be described in more detail below with reference to the logic in FIGS. 7-12.)

FIG. 5A depicts the layout of an object referred to herein as a "key object". According to the preferred embodiments, one version 500 of this key object is used internally by the encryption processing of the present invention, and a second version 510 is transmitted along with the encrypted object with which it was used. Both versions 500, 510 include one distinguished name (DN) 501. Version 500 of the key object includes an X.509 certificate 502a corresponding to this DN, while version 510 replaces the certificate with a "keyIdentifier" 502b (see RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile") which can be used to locate the certificate 502a in conjunction with the DN via a directory or other repository. Finally, both versions 500 and 510 include an encrypted