Document Security

by Paul E. Sevinç

For over five years, researchers from around the world have worked on controlling access to XML documents. Typically, the focus has been on server-side mechanisms for record-like documents and the system architecture has assumed a centralized policy administration point. In contrast, we study client-side mechanisms for narrative-like documents with sticky policies.

The objective of this research project is to develop practical and comprehensive technical measures for document security. It commenced in September 2003, and is being conducted by the Zurich Information Security Center (ZISC) – in particular its members Prof. Dr. David Basin (Swiss Federal Institute of Technology Zurich), Dr. Günter Karjoth (IBM Zurich Research Laboratory), Beat Perjés (Credit Suisse), Dr. Gritta Wolf (Credit Suisse) and Paul E. Sevinç (Swiss Federal Institute of Technology Zurich).

Document Security is motivated by the fact that enterprises must secure many of the documents they process for reasons that include protecting a customer's privacy in accordance with the law, and gaining an advantage over competitors by not sharing trade secrets. Currently, these enterprises must resort to organizational measures, since technical ones are impractical, insufficiently comprehensive, or completely lacking.

The (long-term) vision of Document Security is to ensure that information in documents can be protected by mechanisms that enforce a security and privacy policy, and that the mechanisms are not limited to a particular platform or even document processor. The threat model is that a company's stakeholders (employees, consultants, shareholders etc.) who access sensitive documents are not trusted, because:

• they may be careless in their use and distribution of data
• their software might be untrustworthy (eg compromised by a Trojan horse) even when the users are trustworthy or
• some may actually be dishonest.

This lack of trust means strong client-side control is required, which propels Document Security into the realm of rights management and trusted computing.

From the vision and the threat model, we derived the project scope of Document Security: the primary goals are content confidentiality (eg to protect trade secrets) and policy integrity (in order to keep attackers from simply assigning themselves arbitrary permissions). Microsoft coined the term 'enterprise rights management', since the first goal differs from the goal of digital rights management (DRM), which typically involves payment for access to non-confidential data (eg a movie). Privacy is outside the scope of our project.

It is worth mentioning that we derived our requirements not from what we as computer scientists consider challenging or interesting, but from actual business use cases of a major Swiss bank. For instance, users must be able to define different rules (policy) for different parts (content) within one and the same document so that they do not have to create several differently censored versions of a document. Another example is that it must be possible to specify that certain users have the permission to delegate permissions to other users so that they can also delegate certain document-processing tasks.

The documents we consider are a superset of XML documents. We have developed a formal (ie mathematically precise) model of this superset. Finally, we have formally defined the semantics of a policy language that implies the sticky-policy paradigm. That is, the policy sticks with the information and remains enforced when the information is transferred between documents (eg via cut and paste). The subjects are basically sets of properties (ie name-value pairs) that could be used for modelling roles for (hierarchical) role-based access control. The granularity of the objects is that of single attributes and nodes. The set of actions not only includes actions on the content (in particular 'read'), but also on the policy ('add rule', 'delegate permissions'). Furthermore, and in addition to conditions, we also support provisions and thus allow for access decisions to be made dependent on them (eg signing a non-disclosure agreement [NDA] or logging access).

Our next step will be to consider containers other than documents (eg a database). When the information originates from another type of container, the document will take the other container's policy into account, in accordance with the policy-combination or policy-mapping semantics (eg intersection of restrictions).

As for a prototype, we have designed a client system (perceived by the user, for instance, as a word processor) that will be implemented by students under our supervision. Content and policy are the components of a document tuple (see Figure). As the user (red) is not part of the trusted base (green), the integrity of the client system - particularly the confidentiality of secret keys - must be ensured by either operating-system mechanisms (if the computer is administrated by trusted employees of the enterprise) or by hardware-based mechanisms. While the Provisions Service (blue) is part of the trusted base, too, it is merely a local stub. Otherwise, dishonest users could simply trash their computer to destroy access logs or NDAs.

Document Security has resulted in a few spin-off projects such as a Trusted Platform Module (TPM) emulator for Linux and an evaluation of XML-diff algorithms. It also raises interesting questions in the domain of usability and security.

Link:
http://www.zisc.ethz.ch/research/docsec

Please contact:
Paul E. Sevinç, Information Security GroupD-INFK and ZISC, Swiss Federal Institute of Technology, Zurich, Switzerland
Tel: +41 44 632 7250
E-mail: paul.sevincinf.ethz.ch