Securing Information by Controlling Access to Data in Documents

Research Collection

Doctoral Thesis

Securing information by controlling access to data in documents

Author(s): Sevinç, Paul Ersin

Publication Date: 2007

Permanent Link: https://doi.org/10.3929/ethz-a-005414562

Rights / License: In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use.

ETH Library ETH Dissertation 17161

Securing Information by Controlling Access to Data in Documents

Paul E. Sevinc¸, Dipl. El.-Ing. ETH Department of Computer Science

2007

DISS. ETH NR. 17161

SECURING INFORMATION BY CONTROLLING ACCESSTO DATA IN DOCUMENTS

Abhandlung zur Erlangung des Titels Doktor der Wissenschaften der EIDGENOSSISCHEN¨ TECHNISCHEN HOCHSCHULE ZURICH¨

vorgelegt von PAUL E.SEVINC¸ Dipl. El.-Ing. ETH, ETH Zurich¨ geboren am 15. Marz¨ 1975 Burger¨ von Wittenbach SG

angenommen auf Antrag von Prof. Dr. David Basin, Referent Dr. Gunter¨ Karjoth, Korreferent

2007

DISS. ETH NO. 17161

SECURING INFORMATION BY CONTROLLING ACCESSTO DATA IN DOCUMENTS

A dissertation submitted to the SWISS FEDERAL INSTITUTEOF TECHNOLOGY ZURICH for the degree of Doctor of Sciences

presented by PAUL E.SEVINC¸ Dipl. El.-Ing. ETH, ETH Zurich born on March 15th, 1975 citizen of Wittenbach SG

accepted on the recommendation of Prof. Dr. David Basin, examiner Dr. Gunter¨ Karjoth, co-examiner

2007

Kurzfassung

Obwohl sich Papier als Medium ungebrochener Beliebtheit erfreut, sind elektronische Dokumente und deren Verarbeitung, Speicherung und Ubertragung¨ im Alltag nicht mehr wegzudenken. Die Einfachheit, mit welcher befugte Personen dadurch an Infor- mationen gelangen, kann aber mit sich bringen, dass auch unbefugte Personen einfach an dieselben Informationen gelangen. Um letzterem vorzubeugen, d.h. um insbeson- dere die Vertraulichkeit von Informationen zu gewahrleisten,¨ mussen¨ Dokumente gesichert werden. Dies, die Dokumenten-Sicherheit, ist das Thema dieser Abhandlung. Unser Ansatz zur Sicherung von Dokumenten ist, Zugriffe auf Dokumente zu kontrollieren. Dabei soll ein Benutzer nicht zwingend entweder vollen oder gar keinen Zugriff auf ein Dokument haben, sondern durchaus in der Lage sein, auf gewisse Aus- schnitte eines Dokuments zugreifen zu konnen¨ und auf andere nicht. Solch eine feingranulare Zugriffskontrolle setzt voraus, dass die Struktur von Do- kumenten – besser gesagt von deren Inhalt – bekannt ist. Deshalb befassen wir uns zunachst¨ mit Dokumenten an sich, vor allem mit Lese- und Schreiboperationen dar- auf, da die Operationen die eigentlichen Zugriffe darstellen. Wir entwerfen ein Doku- menteninhaltsmodell, welches sich von bisherigen nicht nur durch seine prazise¨ Spe- ziﬁkation abhebt, sondern auch dadurch, dass es allgemeinerer Natur ist als zur Zeit verbreitete Dokumentenformate. Nach dem Dokumenteninhaltsmodell entwerfen wir ein Zugriffskontrollmodell, welches auf ersterem basiert. Systeme, welche das Zugriffskontrollmodell umsetzen, konnen¨ damit Sicherheitsanforderungen aus dem Geschaftsalltag¨ von Finanzdienst- leistern erfullen.¨ Nebst der Feingranularitat¨ ist es charakterisiert durch Rollenbasiert- heit, durch die Moglichkeit,¨ Zugriffe von getroffenen Vorkehrungen und von der Zu- griffszeit abhangig¨ zu machen und durch die Eigenschaft, dass Ausschnitte, die inner- halb eines Dokumentes oder zwischen Dokumenten verschoben oder dupliziert werden, nach wie vor gesichert sind. Daruberhinaus¨ macht es Anforderungen erfullbar,¨ welche essentiell sind fur¨ Dokumenten-Sicherheit, aber mit bisherigen Zugriffskon- trollmodellen nicht erfullt¨ werden konnen,¨ da diesen ein klassisches Client/Server- Modell zu Grunde liegt. Insgesamt stellt unser Zugriffskontrollmodell einen grossen Schritt in Richtung Benutzungskontrollmodell dar. Systeme, welche den Zugriff auf Dokumente kontrollieren, mussen¨ selbst auch ge-

vii viii schutzt¨ werden, damit sie nicht umgangen werden konnen.¨ Die Systemgrenzen umfas- sen nicht nur Hardware- und Software-Komponenten, sondern auch ein Dateiformat fur¨ Dokumente. Die Dokumente werden dabei mittels kryptographischer Verfahren gesichert. Auch diesem Themenkomplex, der sich im Wesentlichen um die Verwal- tung kryptographischer Schlussel¨ dreht, nehmen wir uns an. Zu diesem Zweck haben wir ein Schlusselaustauschprotokoll¨ auf der Basis des sogenannten Trusted Computing entwickelt. Zusammengefasst geben wir in dieser Abhandlung sowohl theoretische als auch praktische Antworten auf Fragen, welche sich im Kontext von Dokumenten-Sicherheit stellen. Dabei bedienen wir uns auch formaler Methoden. Abstract

Despite paper’s unabated popularity as a medium, everyday life without electronic documents, including their processing, storage, and transmission, has become un- thinkable. The ease with which authorized persons can thereby obtain information, however, can bring with it that unauthorized persons also easily obtain that same information. To prevent such unauthorized information obtainment, especially to ensure the confidentiality of information, documents must be secured. This, document security, is the topic of this dissertation. Our approach to securing documents is to control access to documents. However, users should not be limited to all-or-nothing access to a given document, but should rather be able to access certain parts of a document while being unable to access others. Such fine-grained access control requires that the structure of documents—more precisely of their contents—be well-defined. We therefore first consider documents per se, especially read and write operations thereon, since the operations constitute the actual accesses. We design a document-content model that improves on the state of the art not only in the precision of its specification, but also by virtue of being more general than current popular document formats. We subsequently design an access-control model that is based on our document- content model. Systems implementing the access-control model are able to fulfill security requirements encountered in the day-to-day operations of financial institutions. In addition to its fine granularity, our access-control model is characterized by being role-based, by the possibility of making accesses depend on provisions having been made and on the time of access, and by the property that parts which are moved or duplicated within or between documents are still secured. Furthermore, it supports the fulfillment of requirements that are essential for document security, but that cannot be fulfilled with previous access-control models as these are based on a classical client/server model. Overall, our access-control model marks a huge step in direction of a usage-control model. Systems that control access to documents must themselves be protected so as to avoid their circumvention. The boundaries of such systems comprise not only hardware and software components, but also a file format for documents. The documents are secured using cryptography. We also consider this topic; in essence the topic of

ix x managing cryptographic keys. To this end, we have developed a key-exchange protocol based on so-called Trusted Computing. In summary, in this dissertation we give both theoretical and practical answers to questions that arise in the context of document security. For this, we also employ formal methods. Contents

1 Introduction 1 1.1 Access Control as a Means to Document Security ...... 1 1.2 The Big Picture ...... 2 1.3 Security Requirements ...... 2 1.4 Contributions ...... 4 1.5 Languages ...... 5 1.6 Organization ...... 6

2 Background 7 2.1 Access Control ...... 7 2.1.1 Subjects and Objects ...... 8 2.1.2 Policy Points and Policies ...... 8 2.1.3 Actions and Operations ...... 9 2.1.4 Provisions and Obligations ...... 9 2.1.5 Permissions ...... 10 2.1.6 Rights Management and Usage Control ...... 11 2.1.7 Access-Control Models ...... 12 2.2 Extensible Markup Language ...... 13 2.2.1 Characterizing XML Documents ...... 15 2.3 Object-Z ...... 17 2.4 Trusted Computing ...... 21 2.4.1 Root of Trust for Measurement ...... 22 2.4.2 Root of Trust for Reporting ...... 22 2.4.3 Root of Trust for Storage ...... 23 2.5 ZIP, JAR, and ODF Files ...... 24

3 System Model 25 3.1 Interaction ...... 25 3.2 Documents ...... 26 3.3 Document Processors ...... 28

xi xii CONTENTS

4 Content Model 31 4.1 Motivation and Informal Description ...... 31 4.2 Formal Speciﬁcation ...... 33 4.2.1 Building Blocks ...... 33 4.2.2 Clipboard ...... 35 4.2.3 Content ...... 36 4.2.4 Document ...... 39 4.2.5 Document Processor ...... 40 4.3 Proofs of Concept ...... 42 4.3.1 Reports ...... 42 4.3.2 XML Documents ...... 49 4.3.3 Example: File System ...... 57 4.4 Semi-Structured Data ...... 59

5 Access-Control Model 61 5.1 Informal Description ...... 61 5.1.1 Title Deed ...... 62 5.1.2 Access Policy ...... 62 5.2 Formal Speciﬁcation ...... 66 5.2.1 Subjects ...... 67 5.2.2 Time and Time Service ...... 68 5.2.3 Provisions and Provisions Service ...... 68 5.2.4 Title Deeds ...... 69 5.2.5 Access Policies ...... 70 5.2.6 Policy Decision Point ...... 73 5.2.7 Policed Document ...... 75 5.2.8 Policy Enforcing Document Processor ...... 75 5.3 Proof of Concept: Reports ...... 80 5.4 From Databases to Documents ...... 80

6 Key Distribution & Storage 83 6.1 Requirements ...... 84 6.2 Protocol ...... 85 6.2.1 TPM Commands ...... 86 6.2.2 Notation ...... 88 6.2.3 Initial Possessions of Parties ...... 88 6.2.4 Protocol Run ...... 89 6.3 Security Analysis ...... 90 6.3.1 Security against Man-in-the-Middle Attacks ...... 90 CONTENTS xiii

6.3.2 Ideal Trusted Platform: Security against Dishonest Users . . . . . 91

7 Encoding Documents 93 7.1 Encoding Content ...... 93 7.2 Encoding Policies ...... 94 7.3 Encoding Document Tuples ...... 95 7.4 Levels of Trust ...... 97 7.5 Software Security ...... 101

8 Related Work 103 8.1 XML Access Control ...... 104 8.1.1 General Characteristics ...... 104 8.1.2 Proposal-Speciﬁc Characteristics ...... 105

9 Conclusion 107 9.1 Summary ...... 107 9.2 Future Work ...... 108 9.3 Lessons Learned ...... 112

A Example Report 115 A.1 Content ...... 115 A.2 Title Deed ...... 118 A.3 Access Policy ...... 120

B Policy Schemas 125 B.1 Title Deeds ...... 126 B.2 Access Policies ...... 128

C Implementation Notes 133

References 143

CURRICULUM VITAE 153 xiv CONTENTS List of Figures

2.1 Controlling Access to a Night Club ...... 8 2.2 Controlling Access to Objects (simpliﬁed) ...... 8 2.3 Controlling Access to Objects (extended) ...... 11 2.4 Sticky Policies ...... 13 2.5 XML Nodes ...... 15 2.6 Tree[T] ...... 18 2.7 BoundedTree extending Tree[T] ...... 19 2.8 BoundedTree ...... 20

3.1 Coarse System Model ...... 25 3.2 Page Layout View ...... 26 3.3 Outline View ...... 26 3.4 Plain Documents ...... 27 3.5 Policed Documents ...... 27 3.6 Secured Documents ...... 28 3.7 Document Views ...... 28 3.8 Detailed System Model ...... 29 3.9 Key Distribution ...... 29

4.1 Slide Show ...... 32 4.2 Slide Show Structure ...... 32 4.3 Content Model Class Diagram ...... 33 4.4 Report Nodes ...... 42

5.1 Document Model ...... 62 5.2 Policies Model ...... 63

6.1 Setting ...... 85 6.2 Attackers ...... 85 6.3 Trusted Third Parties (TTPs) as a Model for Ideal Roots of Trust . . . . . 86

7.1 Document Model (unsecured) ...... 96

xv xvi LISTOF FIGURES

7.2 Document Model (secured) ...... 96

9.1 Two Views Depicting the Same Model ...... 109

A.1 Report Schema ...... 117 A.2 Example Report Tree ...... 118

B.1 Title Deed Schema ...... 127 List of Tables

5.1 Operations permitted by Change Action ...... 65 5.2 Operations permitted by Add, Delete, and Update Actions (other models) 65

6.1 Key Distribution Protocol ...... 89

7.1 Overview of Cases 1 and 2 ...... 98 7.2 Key Distribution for Case 1 ...... 99 7.3 Key Distribution for Case 2 ...... 101

xvii xviii LISTOF TABLES Acknowledgments

My position as a doctoral student and assistant at the ETH Zurich was mostly funded by the Zurich Information Security Center (ZISC). I appreciate the ZISC’s support and having been entrusted with assisting in getting it up and running.

First and foremost, I would like to thank Prof. Dr. David Basin, Dr. Gunter¨ Karjoth (IBM Zurich Research Laboratory), Beat Perjes´ (Credit Suisse), and Dr. Gritta Wolf (Credit Suisse) for their supervision of my project as well as Prof. Dr. Ernst-Rudiger¨ Olderog (Universitat¨ Oldenburg) for his help with formalizing my model specifications and Mario Strasser (ETH Zurich)¨ for his invaluable assistance with all things trusted computing. Prof. Basin also acted as dissertation examiner and Dr. Karjoth as dissertation co-examiner. Diana von Bidder regaled our group with self-made pastry on many occasions. Achim Brucker (who, as our group’s IT-infrastructure czar, constantly worried about our hardware and software so that we did not have to) and Dr. Burkhart Wolff initi- ated my transition from Z newbie to wizard of OZ. Paul Hankes Drielsma fixed my English.0 My security mind-set was sharpened in the course of many fruitful discussions with Manuel Hilty, Michael Naf¨ (who is a great person to share an office with), and Dr. Alexander Pretschner. Boris Kopf¨ concisely explained mathematical matters when I needed to recall them. All the persons mentioned above as well as Michael Wahler diligently reviewed texts leading to this dissertation and provided valuable feedback. I explicitly mentioned some but owe thanks to all current and former members of ETH Zurich’s Information Security Group. They have created and maintain a pleasant work environment on the basis of the generous conditions afforded to us by the ETH Zurich in general and by Prof. Basin in particular.

For all of that and for much more, thanks y’all!

0Prof. Dr. Luca Vigano` (now at the Universita` degli Studi di Verona) ﬁxed what little Italian I managed to learn in the course of my dissertation, I might add.

xix

Chapter 1

Introduction

The paperless ofﬁce has not materialized; instead, more paper is consumed than ever [112]. Nevertheless, processing documents electronically has grown in importance as witnessed by the recent emergence of a new discipline within computer science: document engineering1. Document engineering is concerned with gathering both functional and non-functional requirements for document processors and with how to meet these requirements. Functional requirements include basic requirements such as allowing for opening documents, reading or viewing their content, editing, tracking changes, etc. Non-functional requirements include usability and security requirements. This dissertation is about security requirements and how they can be met to achieve document security. Exercising truth in advertisement, we remark that we largely consider document security in isolation and not in the context of a document life cycle or work- ﬂow.

1.1 Access Control as a Means to Document Security

We achieve document security by performing access control. Sensitive data is often secured by controlling access to its container, containers being application-specific data stores. Two well-known examples of containers other than documents are databases and file systems. Typically, databases are based on the relational model, whereas file systems are modeled as trees whose inner nodes are directories (also called folders) and whose leaves are files. For both examples, there exist access-control models and systems (e.g., [13, 27, 51, 115]) that take the inner structure of the respective container into account and thus allow for fine-grained access control. This means that access is not granted or denied to a database or a file system as a whole, but rather to individual tables or views of the database and to individual directories or files of the file system. In our context, fine-grained access control is also required for documents.

1http://www.documentengineering.org/

1 2 1.2. THE BIG PICTURE

1.2 The Big Picture

Without limiting the generality of this dissertation, our context is a ﬁnancial institu- tion such as a bank and its stakeholders (i.e., shareholders, employees, customers, etc.). Other business organizations, government organizations such as the military, etc. would have served as examples just as well. The notion of stakeholder is a business notion; technically, stakeholders correspond to users acting in one or more roles. Users create, exchange, read, and edit documents that contain sensitive data which must be secured for reasons that include protecting customer privacy2 in accordance with the law and gaining a competitive advantage over competitors by not sharing trade secrets. In general, a bank cannot fully trust all users—not even all its employees— because they may not understand the bank’s security requirements, they may be careless in their use of data, or they may actually be dishonest. Put differently, the problem is how to control access to a document such that the data contained in the document can only be accessed by users and in ways sanctioned by the data’s owners. In our context, data owners are employees of a bank acting on behalf of the bank. Legally this may make the bank the data owner, but technically a given piece of data is owned by an employee. Our solution is twofold: First, we tackle the issue of controlling access to a document’s content given its policies. Second, we tackle the issue of ensuring that only document processors that enforce a document’s policies are able to open the document (i.e., that users cannot circumvent the access-control mechanisms). The second part of our solution implies that the secure storage or transfer of documents is a nonissue. In particular, we need not worry about users accidentally or intentionally providing other users with copies of documents. We outline the problem in more detail in the next section and naturally devote most of this dissertation to its solution.

1.3 Security Requirements

The security requirements that systems need to be able to meet when they are based on our access-control model have been distilled in discussions with a partner bank’s information security architects. The information security architects in turn had previously interviewed other bank employees to gather security requirements from a business point of view. The main security goal is confidentiality. Given the examples from Section 1.2, the requirement for confidentiality is evident. For the time being, confidentiality is not

2Note that we do not directly support privacy goals in this dissertation. If desired, they must be met via security (e.g., anonymity via confidentiality). 1.3. SECURITY REQUIREMENTS 3 only the main security goal but the only security goal. (In Chapter 5, we explain why integrity may become a security goal in the future and how it can be assured, too.) The reason is quite simple: when users send a document to other users or receive a document from other users, they do not send or receive “the” document but a (perfect) copy—possibly a copy of a copy. Therefore, they can freely add content to, or delete content from, the copy (and even delete the copy as a whole) as long as nobody gets unauthorized access to confidential content. (If it is important to a document holder that her copy of the document remains integer, she merely has to secure the file system in which her copy of the document resides.) Note that as far as document security is concerned, non-repudiation is not a security goal. Certain documents (e.g., electronic contracts) must certainly be digitally signed. However, a digital signature is just another piece of data. There is no need to specifically protect digital signatures or what they sign; if either one is changed, the other no longer matches. It must be possible to control access to documents in a fine-grained manner.3 To us, this was the most surprising requirement. We thought that from a usability point of view, giving users full access to a document or no access at all would be preferable. However, our partners made it abundantly clear that they would like to be able to define different rules (policy) for different parts (content) within one and the same document so that they need not create multiple, differently censored versions. It must be possible to delegate permissions. This requirement stems from the fact that team leaders may need (or simply want) to delegate certain document-processing tasks to members of their team. However, in order to have some control over permission delegation, users must be explicitly permitted to delegate their permissions. Access-control decisions may be time-dependent. This requirement is motivated by the law. For example, to mitigate the risk of insider trading, public access to the company’s annual report must not be granted before a given date. Luckily, support for elaborate time expressions is not required. That is, it suffices that permissions are only valid after and/or before a certain point of time. (As we shall see, our access-control model would support any kind of time conditions, but our concrete policy language does not.) Permissions that expire are also very useful for temporarily delegating permissions. Access-control decisions may depend on provisions having been made. Support for two kinds of provision is required in the context of banking: accept and sign.4 When

3As already mentioned at the beginning of this chapter, in fine-grained access control, the objects protected are not the data containers (in our case documents) as a whole, but rather their constituent parts. 4In earlier work [113, 114], we also considered log provisions with the understanding that when a permission depends on a log provision, the system controlling access must have logged (or rather: logs 4 1.4. CONTRIBUTIONS a permission depends on an accept permission, the user requesting access must have accepted the agreement specified in the provision before access can be granted. When a permission depends on a sign provision, the user requesting access must have signed the agreement specified in the provision before access can be granted. The difference between accepting and signing is that signing may legally be more binding than agree- ing, even though both require a willful act. Examples for agreements are end-user license agreements and non-disclosure agreements as well as company guidelines. In addition to the business-driven requirements, we require that the document- content model (and in extension the access-control model) encompasses—but is not limited to—XML documents and that the access-control model is role-based. According to our interviews, the access-control models of the majority of enterprise IT systems are not role-based yet, but the trend is clearly in the direction of role-based access control.

1.4 Contributions

We compare with related work in Chapter 8. Briefly summarized, the three major contributions of this dissertation are an access-control model, a protocol for remotely at- testing to a software-stack integrity measurement and for securely exchanging secrets (in our case decryption keys), and a document file format. Furthermore, the specifications of the models are formal and we provide a prototypical implementation of an access-controlling document processor. Our model specifications can also serve as large case studies of the formalism we have chosen (cf. §1.5). Our access-control model improves on the state of the art by a novel treatment of editing operations (new state, more natural actions), by including a policy-combination semantics that allows for securely combining strings of text, and by introducing the sticky-policies paradigm [74, 69] into the realm of document security. Several publications on trusted computing address how to properly measure the software stack of a computer when the computer is booted [83, 82, 108] and how to perform usage control on a computer once it has been deemed trustworthy [107, 111]. Surprisingly, these publications leave open how to remotely attest to a measurement and on how to securely distribute and handle secrets.5 This is also the case with the integrity-reporting protocol sketched in the TCG architecture overview [126, p. 9] and with the two choices for enhancing the protection of data on remote computers given on the fly) the message specified in the provision before access can be granted. However, because log provisions blurred the concept of provisions (cf. §2.1.4), we no longer consider them. If required, logging must be embedded in a system in a different manner. 5This is not to say that others have never addressed these questions before. But their protocols have been published in the form of programming language-dependent and TPM library-dependent source code without any security analysis at best. 1.5. LANGUAGES 5 by Pearson et al. [98, pp. 47-48]. We fill this gap with a detailed protocol (at the level of Trusted Platform Module commands) and a security analysis thereof. The protocol is general in the sense that it is independent of a specific usage-control application. We apply it to manage keys. Our document file format improves on the state of the art by providing a means for usage control and by being open for taking the relative strength of platforms into account.

1.5 Languages

We employ four technical languages: Java, Object-Z, the Uniﬁed Modeling Language (UML), and the Extensible Markup Language (XML).

• Java [20, 4] denotes both an imperative, object-oriented programming language and a platform. Our prototype is implemented in the Java programming language and runs on the Java platform.

• Object-Z [116, 36, 34] is an object-oriented extension of the formal speciﬁcation language Z [72, 118, 18, 73, 79, 140]. Both our document-content model and our access-control model are formally speciﬁed in Object-Z.

• The UML [95, 43] is a graphical modeling language. We use it in what Martin Fowler and Steve Mellor call the sketch mode [43, p. 2]. That is, we use it for informative illustrations only; the normative models are formally speciﬁed in Object-Z.

• The XML [133, 59, 88] is a markup language. We use it as the basis for the concrete syntax of our policy language, whose schemas are formally speciﬁed in XML Schema [136, 59, 88].

Object-Z and the XML are briefly introduced in Chapter 2. As we use Java only for the implementation (cf. Appendix C) and the UML only informally, they are not prerequisites. In earlier work [114, 6], we have also employed CSP-OZ [42], a specification language combining Communicating Sequential Processes (CSP) [61] and Object-Z (OZ). The advantage of CSP-OZ over Object-Z is that the order in which access requests are evaluated can be made explicit. The disadvantage is that in addition to mastering Object-Z, one must also master CSP as well as their combination. As the request- evaluation order is fairly simple in our access-control model, we can do without CSP without risking any underspecification. 6 1.6. ORGANIZATION

1.6 Organization

In addition to this chapter, this dissertation features eight chapters and three appen- dices. In Chapter 2, we provide background information by introducing access control, the XML, Object-Z, trusted computing, and archive formats (i.e., the formats of ZIP, JAR, and ODF ﬁles). In Chapter 3, we give an informal overview of our system model before delving into formal details in the following chapters. In Chapter 4, we specify our abstract document-content model as well as two concrete ones as specializations of the abstract one. In Chapter 5, we specify our access- control model by specifying the abstract syntax of policies and their semantics (i.e., their interpretation by policy points). In Chapter 6, we explain how cryptographic keys can be securely distributed and stored. This is a prerequisite for Chapter 7, in which we concretize the syntax of policies (whose schemas are given in full in Appendix B) and apply cryptography to secure documents as a whole. In Chapter 8, we compare with related work before we conclude this dissertation with a summary and suggestions for future work in Chapter 9. Chapter 2

Background

This chapter provides background information that is of relevance to this dissertation. We brieﬂy introduce the Extensible Markup Language (XML) in Section 2.2, Object- Z in Section 2.3, trusted computing in Section 2.4, and archive formats in Section 2.5. These sections are independent of each other and can be safely skipped by readers with a working knowledge of the XML, Object-Z, trusted computing, and archive formats, respectively. In Section 2.1, we present some access-control terminology in order to establish a common language. Therefore, it should not be skipped even by readers familiar with access control.

2.1 Access Control

Security is about protecting entities from entities and access control is a means to achieve security by keeping entities who are not trusted to act properly at a safe dis- tance from the entities to protect. Consider the scene depicted in Figure 2.1: A couple (subject) would like to enter a night club (object). However, not everyone is welcome to the club—maybe really for security reasons and maybe for other reasons. In any case, there is a bouncer (policy enforcement point) who checks with the manager (policy decision point) whether certain persons are to be let in and who enforces the manager’s decisions. The manager makes its decisions based on the club owner’s guest list (policy).

An abstract view of a canonical access-control system is depicted in Figure 2.2. It is simpliﬁed in that two services that are required in our context are omitted, but we will extend it later in this section.

7 8 2.1. ACCESS CONTROL

Couple: Subject Bouncer: PEP Club: Object Manager: PDP Guest List: Policy (Girl: Principal, Boy: Principal)

Figure 2.1: Controlling Access to a Night Club

1. request access to object i Subject PEP Objects 4. grant or deny access 1 .. n t s 2 e . u e q v e a r

l u y a n te e

d r r e o q

t u n e a s r t .g 3

PDP Policy

Figure 2.2: Controlling Access to Objects (simpliﬁed)

2.1.1 Subjects and Objects

The entities that access other entities are called subjects. Subjects are modeled as tuples consisting of principals. In our context, subjects represent natural persons (i.e., humans) and are pairs consisting of a user principal and a role principal. In other contexts, subjects might represent legal persons, software processes, etc. In the night-club example above, subjects represent couples. The entities that are accessed by other entities are called objects (also called re- sources). As we shall see, in our context, objects are the nodes and attributes of our document-content model. In the night-club example above, the night club is the only object there is.

2.1.2 Policy Points and Policies

The two entities which control access are called policy points. Together, they constitute a reference monitor. The policy decision point (PDP) makes access decisions by evaluating requests under consideration of the policy while the policy enforcement point (PEP) enforces them by mediating access to objects by subjects. (Synonyms of PDP and PEP are access decision function (ADF) and access enforcement function (AEF) [71], respectively.) Policies formalize security requirements. In the night-club example above, the guest 2.1. ACCESS CONTROL 9 list is the policy, the manager is the PDP, and the bouncer is the PEP.

2.1.3 Actions and Operations

Similar to Gabillon et al. [48], we differentiate between actions and operations. Each operation is a speciﬁc access. Each action is a kind of access. For example, deleting a single paragraph from a chapter and deleting an entire section from a chapter are two different operations. But for both operations, the chapter is change-accessed. In the night-club example above, the set of operations happens to be singleton (consisting of “enter”) and consequently, there is only one action (whose name might be “enter” as well). When the PEP asks the PDP to evaluate an access request, the PDP maps operations to actions. Within policies, there is no notion of operations, only of actions.

2.1.4 Provisions and Obligations

In the context of access control and based on their natural-language deﬁnitions, provisions must have been made before access can be granted and obligations must be met after access has been granted. For example, if users are required to sign a non-disclosure agreement (NDA) before they are granted access to certain data, signing the NDA is a provision; if they are required to delete the data within a month of having been granted access to it, deleting the data within a month is an obligation. The difference between provisions and obligations is a subtle one that depends on the abstraction level of the policy language [60, 101]. Returning to the example from just before, users may be obliged not to ever disclose data that they have been granted access to. Since this obligation is difﬁcult to enforce technically, it is mapped to a provision (signing an NDA) so that—at least—legal steps can be taken when the users are caught not meeting the original obligation. Unsurprisingly, the terms provision and obligation are used differently in the access- control literature:

• Bettini et al. [14, 15] define provisions as actions that must be performed before access can be granted and obligations as actions that must be performed after access has been granted. Their definitions are certainly closest to ours, but they emphasize the action whereas we emphasize the result (cf. next paragraph). Fur- thermore, they allow for provisions being made while an access request is evaluated whereas we leave such on-the-fly provision making to higher layers for the sake of keeping the access-control layer as simple as possible. As far as the user is concerned, it does not matter whether an access request is suspended or automatically submitted a second time if it was denied because of certain provisions 10 2.1. ACCESS CONTROL

not having been made the ﬁrst time around.

• Hilty et al. [60] and Pretschner et al. [101] deﬁne provisions as any and all conditions that must be met before access can be granted, including but not limited to the request subject, object, and action matching the policy subject, object, and action. Consequently, they deﬁne obligations as any and all conditions that must be met after access has been granted.

• The eXtensible Access Control Markup Language (XACML) specification [93, p. 16] defines obligations by referring to the provisional actions1 from the XML Ac- cess Control Language (XACL) [67, 77] as actions that must be performed instead of or in addition to actions that may be performed. (As a consequence, the “obligations” service is connected to the PEP in the XACML data-flow model whereas the provisions service is connected to the PDP in our model [cf. Figure 2.3].)

We deﬁne provisions abstractly by two key characteristics with respect to a given user: making a provision is stateful and idempotent. Provision making being stateful means that the provisions service—which is the subsystem that manages which user has made which provisions—changes its state when it is presented with proof for a user having made a provision for the ﬁrst time. Provision making being idempotent means that the provisions service does not change state when the same user makes the same provision again. For example, once a user has signed a given NDA, there is a record that ties the user, the NDA, and the user’s signature to each other. If the same user were to sign the same NDA with the same signing key, no further record would be created. We do not support obligations in this dissertation. Or worded positively: we assume that obligations have been mapped to provisions.

2.1.5 Permissions

As mentioned above, policies formalize security requirements. In our context, policies relate subjects, objects, actions, points in time, and provisions to each other. More speciﬁcally, they relate roles to permissions (also called privileges) which in turn relate users, objects, actions, points in time, and provisions to each other. When an access request is evaluated, the subject (i.e., the role and the user), the object, and the action are derived from the request while the current time and the made provisions are provided by the time service and the provisions service, respectively (cf. Figure 2.3). As their name implies, permissions are positive in the sense that they grant requests. In this dissertation, we do not consider prohibitions which are negative in the sense that

1Unfortunately, “provisional action” is a misnomer. The intention was clearly to designate actions that are related to provisions. However, the deﬁnition of the adjective “provisional” is—according to the Merriam-Webster online dictionary—“serving for the time being” (i.e., synonymous with “temporary”). 2.1. ACCESS CONTROL 11 they deny requests. Prohibitions are not considered because they would have made the users’ lives more complicated since the users would have had to understand a permissions and prohibitions combination semantics (that we would have had to come up with ﬁrst). Instead, users can rely on one basic rule: any access that is not explicitly permitted is denied.

1. request access to object i Objects Subject PEP 6. grant or deny access 1 .. n t s 2 e . u e q v e a r lu y a t en e re d r o qu nt e a st r .g 5

PDP Policy

3. get time 4. filter out made provisions

Time Service Provisions Service

Figure 2.3: Controlling Access to Objects (extended)

2.1.6 Rights Management and Usage Control

The terms rights management and usage control are more recent than the term access control. Nevertheless, all three denote the same basic concept, namely authorization. Ignoring that policies may be called licenses, that subjects may be called consumers, that reading may be called playing back, etc., the difference between the three terms lies in what is typically implied. Rights management [128, 142] typically implies that access to rights-managed data is always controlled. (Contrast this with the following example: a user who has read access to a file in a Unix-like file system can easily copy the file and share the copy with users who do not have read access to the original file.) Furthermore, digital rights management (DRM) typically implies that licenses need to be enforced in a potentially hostile environment (i.e., on playback devices that are owned by the consumer) and that the content is audio or visual in nature. The main goal of DRM is payment for access to non-confidential data (e.g., your favorite band’s latest song) whereas the main goal of enterprise rights management is confidentiality.2 In other words, in DRM se-

2In the academic literature, enterprise rights management may be better known as secure information sharing. 12 2.1. ACCESS CONTROL curity is a means to an end whereas in enterprise rights management security is the end. Usage control [97, 143] subsumes rights management as well as what might be called “traditional access control” and typically implies support for (future) obligations. Even though we provide a foundation for controlling usage of documents, we use neither the term usage control nor the term rights management and simply stick to the term access control in the remainder of this dissertation.

2.1.7 Access-Control Models

Access-control models abound (e.g., [16, 33, 37, 41]). Some have been around for decades, others are brand-new; some are application-specific, others are application- agnostic; some support confidentiality, others integrity; and so on and so forth. Need- less to say, quite a few are merely old wine in new skins. We do not claim that our access-control model is revolutionary, but it does combine and adapt existing concepts in novel ways for the application at hand in order to meet the latter’s security requirements (cf. §1.3). The most influential concepts have been discretionary access control, role-based access control, and the sticky-policies paradigm.

Discretionary Access Control

In discretionary access control (DAC) [16, 41], every object has an owner (represented by a user). The owner grants or revokes access to the object(s) that she owns at her discretion. A user who has read access to an object can copy the object and becomes the owner of the copy. For our access-control model, we have adopted the concept of ownership of objects by users from DAC. However, when a user copies an object, the copy is still owned by the owner of the original object. To some, this may be the key characteristic of originator-controlled access control [16]; in any case, in our context the access policy is not centralized but sticky (see below).

Role-Based Access Control

In role-based access control (RBAC) [92, 41], users are related to roles and roles are related to permissions. The idea is to ease the update of a user’s permissions by decoupling users from permissions; when the user changes her role within an organization, she only needs to be assigned a new role. Conversely, when a permission is assigned to or revoked from a role, it need not be assigned to or revoked from every user in that role. (In practice, the roles themselves may change often at times, a process that is not well supported by RBAC.) Roles can also be related to roles, allowing for hierarchical 2.2. EXTENSIBLE MARKUP LANGUAGE 13 role-based access control whereby a role A that is related to a role B implicitly has all the permissions that role B has, too. For our access-control model, we have adopted hierarchical role-based access control. Furthermore, we have (re)introduced a direct relation between users and permissions, which allows us to limit permissions to a subset of users in a certain role.

Sticky Policies

In our context, owners need assurance that the policies governing access to their documents’ content are respected, even when other users incorporate parts of these documents in their own documents. To achieve this, we associate parts of each document with the respective parts of its policy and maintain this association. This amounts to a ﬁne-grained variant of the sticky-policies paradigm [74, 69]: when content is copied (or cut) from a document to the clipboard and pasted into a document, then so is the respective part of the policy (cf. Figure 2.4).

Document A Clipboard Document B

t n

o copy

c paste

o p

Figure 2.4: Sticky Policies

2.2 Extensible Markup Language

The XML [133, 59, 88] is a markup language. XML documents are tree-based data structures that are typically encoded in text. (We do not consider binary encodings of XML documents.) An example XML document—an XHTML [132] document to be more speciﬁc—is given in Listing 2.1. The text encoding may start with a so-called XML declaration (e.g., the ﬁrst line of the example) that is not part of the XML document but meta-information for XML parsers.

unfamiliar with the target should ignore it. −−> 2007−03−15 < t i t l e>Document Security Document Security

e t a l .

ZISC

Model
Documents are ...
Formal Model
...
Listing 2.1: Example XML Document
There are five types of XML nodes (cf. Figure 2.5): document, element, text, comment, and processing instruction. (These are five types of XML nodes that are also found in the Document Object Model (DOM) [131, 59, 88] and the XPath data model [135, 59, 88].) The root of every XML document is of type document. The document root is implicit and thus not visible in the text encoding. The main building block of an XML document is the node of type element. Elements are delimited by their start tag, e.g., in the example, and their end tag, e.g., . They can have content (i.e., child nodes) or be empty. In the latter case, the start and end tags can be merged, e.g.,
instead of

. Not all strings are valid element tags; those that are are in the set of qualified names. Elements, even empty elements such as , can have attributes, e.g., property="author", as well as namespace declarations (which are also meta-information for XML parsers and not shown in the example). Attributes are name-value pairs whose names are also qualified names and unique within an element’s set of attributes. The content of elements can consist of further (properly nested) elements as well as nodes of type text, nodes of type comment, and nodes of 2.2. EXTENSIBLEcd: XML MARKUP LANGUAGE 15
XmlNode
Comment ProcessingInstruction Text
* *
* * *
Document Element
+ root element
+ document root 0..1
*
Erstellt mit Poseidon forFigure UML Community 2.5: XMLEdition. Nicht Nodes zur kommerziellen Nutzung. type processing instruction, all three of which are leaf nodes. Text nodes are simply encoded as strings of character data and implicitly delimited by the other nodes. Comment nodes are delimited by , every- thing in between being the comment. Processing-instruction nodes are delimited by ; the first white-space character separates the processing instruction’s target, e.g., docsec-editor, from the processing instruction’s value (also called data), e.g., expand tree on open. Every XML document has at most one root element (also called document element), e.g., ... , that should not be confused with the document root. The root element is the document root’s only child node of type element. As shown in the example, comments and processing instructions may appear before the root element, in which case their nodes are children of the document root and siblings of the root element. XML documents must be well-formed and can be valid. They are well-formed when all elements are properly nested and only comments or processing instructions are found outside of the root element. They are valid according to a schema when they are instances of a set of XML documents defined by the schema.
2.2.1 Characterizing XML Documents
XML documents can be characterized as being record-like/data-oriented or narrative- like/document-oriented [59]/[88]. (We make use of these terms in our discussion of related work in Chapter 8.) This characterization depends heavily on how an XML document is used and is by no means strict, but the XML document’s structure is a strong indicator. 16 2.2. EXTENSIBLE MARKUP LANGUAGE
Record-like/data-oriented XML documents are basically databases that are organized hierarchically, as a tree instead of as relations. Consider the address-book example in Listing 2.2. The address elements (i.e., the subtrees rooted at them) are obviously the database records. Note that the white space between element nodes and between element and text nodes does not matter; more precisely, there is no mixed content (i.e., no text node has an element-node sibling or vice versa), which is why XML parsers can deduce that such white space is ignorable. Note further that the tree need not be balanced, but that its branches (the records) exhibit the same or at least a similar structure.
Beat [email protected] 0−800−ZISC−27

David [email protected] 0−800−ZISC−32

G r i t t a gritta@zisc .ethz.ch 0−800−ZISC−49

Gü nter [email protected] 0−800−ZISC−45

Paul [email protected] 0−800−ZISC−77
Listing 2.2: Address Book
If we were to secure a record-like/data-oriented XML document, we would likely refer to objects by type (as defined in the XML document’s schema), not by address (as resulting from the XML-document instance). For the address-book example, the access policy may formalize that all e-mail addresses are public while all phone numbers are confidential. Narrative-like/document-oriented XML documents are also organized in trees, of 2.3. OBJECT-Z 17 course. However, their structure is likely to be less regular than that of record-like/data- oriented XML documents. Consider the XHTML example from before where sections can be nested arbitrarily deep and can consist of any number of paragraphs. Further- more, there may be mixed content, e.g., both li elements in the example, and then white space does matter. When we secure narrative-like/document-oriented XML documents in later chapters, we always refer to objects by address, never by type. For the XHTML example, the access policy may formalize that some paragraphs are public while other paragraphs are confidential. All that said, XML documents may also exhibit characteristics of both classes. For example, a record-like/data-oriented XML document may have a field that is basically a narrative-like/document-oriented XML document. This is akin to having BLOBs and CLOBs in relational databases.
2.3 Object-Z
Object-Z [116, 36, 34] is an object-oriented extension of the formal specification language Z [72, 118, 18, 73, 79, 140]. A system specification in Object-Z decomposes the system into objects. Each object is an instance of a class that is defined in a class schema. Class schemas have the following form:
ClassName[GenericParameters]
VisibilityList InheritedClasses LocalDefinitions StateSchema InitialStateSchema OperationSchemas
Consider the two example class schemas in Figure 2.6 on page 18 and in Figure 2.7 on page 19: The class names are Tree and BoundedTree. The first class schema defines a family of classes as its class name is followed by an optional list of generic parameters (delimited by [ and ]). When the class is used as a type (e.g., in BoundedTree), the generic parameters must be substituted by actual types (e.g., Tree[Z]). The optional visibility list (delimited by ( and )) makes those features (i.e., constants, variables, initial state schema, and operations) which it lists visible from outside of the class. If the visibility list is omitted, all features are visible. Tree makes the secondary variable domain, the initial state schema, and the operations GetValue, 18 2.3. OBJECT-Z
Tree[T ] (domain, Init, GetValue, SetValue, GetChild, AddChild, DeleteChild)
value : T
children : seq ↓Tree[T ] C ∆
domain : P1 seq N1
domain = {h i} ∪ {i : dom children; p : seq N1 | p ∈ children(i).domain • hii a p}
Init children = h i
GetValue SetValue value!: T ∆(value) value?: T value! = value value0 = value?
GetChild index?: N1 child!: ↓Tree[T ] index? ≤ #children child! = children(index?)
AddChild ∆(children) index?: N1 child?: ↓Tree[T ] index? ≤ #children + 1 #children0 = #children + 1 0 ∀ i : N1 | i < index? • children (i) = children(i) children0(index?) = child? 0 ∀ i : N1 | index? < i ∧ i ≤ #children + 1 • children (i) = children(i − 1) 0 0 DeleteChild =b AddChild[children , children/children, children ] \ (child?) AddEmptyChild =b [child!: ↓Tree[T ] | child!.Init] k AddChild
Figure 2.6: Tree[T] 2.3. OBJECT-Z 19
BoundedTree (bounds, domain, Init, GetValue, SetValue, GetChild, AddChild, DeleteChild) Tree[Z] bounds : Z × Z first(bounds) ≤ second(bounds)
first(bounds) ≤ value ∧ value ≤ second(bounds) ∀ i : N1 | i ≤ #children • children(i) ∈ BoundedTree
Init value = first(bounds)
Figure 2.7: BoundedTree extending Tree[T]
SetValue, GetChild, AddChild, and DeleteChild visible. Note that the primary variables value and children as well as the operation AddEmptyChild are nevertheless visible to subclasses such as BoundedTree. When a class inherits other classes (which is optional as well), the only thing it does not inherit are their visibility lists. State schemas, initial state schemas, and operations with the same name are combined by merging their declaration parts and conjoining their predicate parts. Therefore, except for losing the inheritance relationship between Tree and BoundedTree, BoundedTree could have been equivalently defined as shown in Figure 2.8 on page 20. The only local definitions of interest to us are the definitions of constants. Note that the value of a constant need not be the same for two different instances of the same class.3 For example, two BoundedTree instances can have different bounds, but these potentially different bounds never change. The state schema defines primary variables and secondary variables (separated by ∆) as well as the class invariant. The value of a secondary variable is derived from the values of primary variables and cannot be directly changed by operations. BoundedTree features both value types (i.e., Z) and reference types (i.e., BoundedTree). So children is not a sequence of BoundedTree objects, but a sequence of references to BoundedTree objects. In the case of Tree, T could be either a value type or a reference type. However, children is a sequence of references to Tree objects or to objects whose type inherits (↓)
Tree. Finally, the references in children are defined to be contained ( C). That is, no two Tree instances can reference the same Tree instance, thereby greatly reducing where
3This is similar to having final non-static fields in Java. 20 2.3. OBJECT-Z
BoundedTree (bounds, domain, Init, GetValue, SetValue, GetChild, AddChild, DeleteChild) bounds : Z × Z first(bounds) ≤ second(bounds)
value : Z
children : seq BoundedTree C ∆
domain : P1 seq N1
domain = {h i} ∪ {i : dom children; p : seq N1 | p ∈ children(i).domain • hii a p} first(bounds) ≤ value ∧ value ≤ second(bounds)
Init children = h i value = first(bounds)
GetValue SetValue value!: Z ∆(value) value?: value! = value Z value0 = value?
GetChild index?: N1 child!: BoundedTree index? ≤ #children child! = children(index?)
AddChild ∆(children) index?: N1 child?: BoundedTree index? ≤ #children + 1 #children0 = #children + 1 0 ∀ i : N1 | i < index? • children (i) = children(i) children0(index?) = child? 0 ∀ i : N1 | index? < i ∧ i ≤ #children + 1 • children (i) = children(i − 1) 0 0 DeleteChild =b AddChild[children , children/children, children ] \ (child?) AddEmptyChild =b [child!: BoundedTree | child!.Init] k AddChild
Figure 2.8: BoundedTree 2.4. TRUSTED COMPUTING 21 object aliasing might occur. The initial state schema defines a predicate that evaluates to true for an object when the object is in its initial state. The initial state schema does not define an operation, so it cannot be invoked to put an object into its initial state. However, the object can be in its initial state (again) after having had operations invoked on it. Operations can have input (variable name with suffix ?) and output (variable name with suffix !). An operation has to declare all primary variables that it changes in its delta list (delimited by ∆( and )). Operations can be defined (=b ) by promoting other operations and by combining other operations through conjunction, parallel composition, nondeterministic choice, sequential composition, scope enrichment, and hiding. Types cannot only be defined as class types. In addition to the built-in type Z (inte- gers), types can also be defined globally as abbreviations, basic types (also called given types), and free types. Abbreviations are useful to give a type built from other types through the application of Cartesian products (×), powersets (P), sequences (seq), etc. a simple name: SimpleName == ComplexType Basic types are new types introduced simply by putting their names in brackets: [BasicType, GivenType]. Free types define a specific set of values: FreeType ::= Value | ConstructorhhSomeTypeii. Free types are particularly handy to define recursive types, e.g.: BinaryTree ::= EmptyLeaf | ValueNodehhZ × BinaryTree × BinaryTreeii. Constants can also be defined globally and they can also be generic. For example, the following generic constant defines a function that pairs the function argument with itself:
[T ] pair : T → (T × T ) ∀ t : T • pair(t) = (t, t)
2.4 Trusted Computing
Trusted computing is about embedding a trusted computing base (TCB) [16] in a computing platform that allows a third party to determine the trustworthiness of the computing platform, i.e., whether or not the computing platform is a trusted platform from the point of view of the third party. The Trusted Computing Group (TCG), an industry standards organization, has specified a TCB for trusted computing in the form of three so-called roots of trust [126]: the root of trust for storage (RTS), the root of trust for reporting (RTR), and the root of trust for measurement (RTM). In particular, the TCG has 22 2.4. TRUSTED COMPUTING specified a Trusted Platform Module (TPM) [127] that can act as both a RTS and a RTR.4 These specifications are clearly gaining momentum as witnessed by large-scale R&D projects such as EMSCB and OpenTC5, open-source projects such as TPM Emulator [122] and TrouSerS6, the inclusion of TPM services in Windows Vista [86], and the increasing number of personal computers with a TPM and a basic input/output system (BIOS) that can act as the RTM [76]. In the remainder of this section, we summarize the TCG’s definitions for RTM, RTR, and RTS. For a comprehensive description, the reader is referred to the TCG architecture overview [126] and to textbooks on trusted computing [98, 58, 87].
2.4.1 Root of Trust for Measurement
When a computer is booted, control passes between different subsystems. First the BIOS is given control of the computer, followed by the boot loader, the operating system loader, and finally the operating system. In an authenticated boot, the BIOS measures (i.e., cryptographically hashes) the boot loader prior to handing over control, the boot loader measures the operating system loader, and the operating system loader measures the operating system. These measurements reflect what software stack is in control of the computer at the end of the boot sequence; in other words, they reflect the platform configuration. Hence the name platform configuration register (PCR) for the TPM registers where such measurements are stored and which are initialized at startup and extended at every step of the boot sequence. An attacker who wants to change the platform configuration without being de- tected has to corrupt the root of trust for measurement (BIOS), which we assume to be infeasible without physical access to the computer. Ideally, a tamper-proof piece of hardware will eventually act as the root of trust for measurement and measure the BIOS at the beginning of the boot sequence.
2.4.2 Root of Trust for Reporting
Each TPM has an endorsement key (EK) which is a signing key whose public key is certified by a trusted third party (e.g., the TPM manufacturer). For privacy reasons, the EK is only used to obtain a key certificate from a certificate authority (CA) for an attestation identity key (AIK), which the TPM generates itself. In order to alleviate even the strongest privacy concerns, direct anonymous attestation (DAA) [22, 26] is the protocol of choice for certifying AIKs. AIKs are signing keys whose private key is
4There seems to be consensus in the information-security community that TCBs for trusted computing must be hardware-based, but tamper-proof hardware remains an open challenge [3, 117]. 5http://www.emscb.de/ and http://www.opentc.net/ 6http://tpm-emulator.berlios.de/ and http://trousers.sourceforge.net/ 2.4. TRUSTED COMPUTING 23 only used for signing data that has originated in the TPM. For example, a remote party interested in learning what software stack is in control of the computer can query the TPM for PCR values. The query contains the set of PCRs to look up and a nonce (in order for the remote party to check for replay attacks). The TPM answers with the respective PCR values and the signature generated by signing the values as well as the nonce with one of its AIKs. Put differently, the TPM attests to, or reports on, the platform configuration.
2.4.3 Root of Trust for Storage
The protected storage feature of a TPM allows for the secure storage of sensitive objects such as TPM keys and confidential data. However, storage and cost constraints require that only the necessary (i.e., currently used) objects can reside inside a TPM; the remaining objects must be stored outside in unprotected memory and are revealed to the user or loaded into the TPM on demand. To this end, externally stored objects are encrypted with an (asymmetric) storage key, which is referred to as the parent key of the object. A parent key can again be stored outside the TPM and (possibly along with other keys) protected by another storage key. The thereby induced storage tree is rooted at the so called storage root key (SRK), which is created upon initialization of the the TPM and cannot be unloaded. Consequently, a parent key has to be loaded into the TPM before the data it protects can be revealed or a key unwrapped and loaded into the TPM. Note that protected keys are only used inside the TPM and thus (in contrast to arbitrary data) are never disclosed to the user. Furthermore, each key is either marked as being migrateable or non-migrateable. In the former case, the key might be replicated and moved to other platforms whereas in the latter case the key is bound to an individual TPM and is never duplicated. Regarding the actual protection of objects, one differentiates between binding and sealing.
Binding is the operation of encrypting an object with the public key of a binding key. Binding keys are encryption keys. If the binding key is non-migratable, only the TPM that created the key can use its private key; hence, the encrypted object is effectively bound to a particular TPM.
Sealing takes binding one step further: the object is not only bound to a particular TPM, but in addition can only be decrypted if the current platform configuration matches the values associated with the protected object at the time of encryption.
It must be assumed that an attacker with physical access to the computer can get access to the private keys stored in the TPM. Current TPMs are designed to protect against software attacks, but not against hardware attacks (they are tamper-resistant at best) [58, 87]. 24 2.5. ZIP, JAR, AND ODFFILES
2.5 ZIP, JAR, and ODF Files
ZIP files are single files (from the point of view of an operating system’s file system) that encode an archive (i.e., a set) of files [99]. The files within a ZIP file can individually be compressed and encrypted when they are archived as well as decrypted and decompressed when they are extracted; the ZIP file format specification defines various compression and encryption methods. Nevertheless, a file could already be compressed and/or encrypted when it is added to an archive. When (non-empty) directories are archived, the directories are (recursively) flattened, but—if necessary— recreated again when a file is extracted that was implicitly added to the archive via its directory. JAR (short for Java Archive) files are first and foremost ZIP files [124]. In addition to the files explicitly added to an archive, JAR files contain a text file called manifest.mf (and with relative path META-INF/) featuring sections (i.e., lists) of name-value pairs. For example, JAR files that are meant to be executed designate (in the value of the attribute named Main-Class) whose class’ main method is to be invoked by the Java interpreter. More importantly, the JAR file specification defines a standard for signing JAR files, thereby tying the integrity/authenticity of an archive to the confidentiality of a signing key. ODF (short for OpenDocument Format) files are ZIP files as well [94, 96, 38]. This allows for convenient management and exchange of documents that consist of several files (text, image, etc.). Like JAR files, ODF files contain a manifest file (with relative path META-INF/), but it is called manifest.xml. As its suffix implies, the manifest file is XML-based. It provides an inventory of and meta-information (full path, size, media type) on the other files in the same archive as well as optional encryption data. Chapter 3
System Model
In this chapter, we provide an informal overview of things to come before we delve into the gory details of document security in the core chapters of this dissertation. We briefly touch on how subjects interact with document processors, on how documents are viewed by document processors, and finally on documents processors themselves. Taken together, these three aspects already provide a coarse model of a document- security system as depicted in Figure 3.1. To access documents, subjects interact with document processors, which in turn read from and write to documents. Why documents are depicted as folders will become clear shortly.
Document Subject interacts with reads/writes Document Processor
Figure 3.1: Coarse System Model
3.1 Interaction
Subjects interact with document processors the way that they interact with file browsers and not the way that they interact with database management systems. Consider Fig- ures 3.2 and 3.3. Both figures depict the same example report, once in page layout view and once in outline view1. When subjects scroll down in the page layout view, they implicitly request access to nodes in pre-order. The outline view makes access requests more explicit: Before they can access any other node, subjects need to have access (in a general, not only security- related sense) to the root node. Once they have access to (i.e., expanded) a node, the document processor determines the node’s number of child nodes and the child-node types. Only then can a child node be accessed correctly (i.e., in line with its type).
1This is Microsoft Word terminology.
25 26 3.2. DOCUMENTS
Figure 3.2: Page Layout View
Figure 3.3: Outline View
The conclusion we draw for our access-control model is that it need not be hierarchical, meaning that when a subject requests access to a node, there is no need to first check whether the subject is permitted to access the node’s ancestors. If he was not, he would not have been able to request access to the node in the first place. In contrast, when subjects request access to an object in a hierarchical database, they provide the object’s address or path, which may be absolute, and access to all objects on the path may need to be checked, too.
3.2 Documents
The reason why we depict documents as folders is that documents are tuples. State-of- the-art document formats—a recent example is OpenDocument [94, 38]—are complex and consist of several components: the actual content, of course, as well as components such as style sheets, change logs, etc. A document’s content component is the raison d’être for all its other components—and therefore for the document itself—and is where the data that represents the sensitive information is stored. First, in Chapter 4, we model documents as one-tuples consisting of a content component only (cf. Figure 3.4). Our document-content model is formal (i.e., mathematically precise) and comprehensive (i.e., modeling not only document state but also document operations to access the document state). 3.2. DOCUMENTS 27
Content
Document (1-tuple)
Figure 3.4: Plain Documents
Then, in Chapter 5, we model documents as triples consisting of a content component, a title-deed component, and an access-policy component (cf. Figure 3.5). The latter two components are part of our access-control model—which is formal and comprehensive, too—and govern access to the document (in particular to the content component). Title deeds express which user owns which part of the content, while access policies formalize the owner’s security requirements. Title deeds are motivated in Sec- tion 5.1.1.
Content
Document Title Deed (triple)
Access Policy
Figure 3.5: Policed Documents
Finally, in Chapter 7, we model documents as five-tuples consisting of an encrypted content component, a title-deed component, an access-policy component, an encrypted decryption key, and a digital signature (cf. Figure 3.6). The latter two components are part of our document encoding which must ensure that subjects cannot circumvent access-controlling document processors (cf. the next section). The document model actually depends on the view taken. Our view is that of document processors since document processors are going to control access to documents eventually. As depicted in Figure 3.7, a file system might view a document not as consisting of several components, but simply as a stream of bits whose interpretation is left to the programs that open the respective file. Of course, a decent file browser will display the document file with a meaningful icon to subjects, but this merely means that the file browser can associate file names (or other meta-information) with icons that represent types of files. The document processor, in contrast, can weave a document’s components into one rich user interface, making the technical nature of documents 28 3.3. DOCUMENT PROCESSORS
encrypted Decryption Key
encrypted Content
Document Title Deed (5-tuple)
Access Policy
Signature
Figure 3.6: Secured Documents transparent to subjects.
file system
...
document processor
Figure 3.7: Document Views
3.3 Document Processors
Document processors consist of several subsystems. These subsystems include, but are not limited to, a policy enforcement point (PEP) and a policy decision point (PDP) (cf. Figure 3.8) as well as a provisions service and a time service, all of which are part of our access-control model, too. Whether a given permission has been made by a given user can be checked with the provisions service, while the time service can be queried for the current time. Document processors also manage a set of master keys that must not be disclosed. In order to decode documents, document processors need to know the master decryption key which allows to decrypt the encrypted document decryption key (which in turn allows to decrypt the encrypted content). In order to encode documents, document processors need to know two keys:
1. the master encryption key which allows to encrypt the (to be generated) document decryption key and 3.3. DOCUMENT PROCESSORS 29
interacts with Document reads/writes Processor
PEP
PDP reads
Figure 3.8: Detailed System Model
2. the signature key which allows to sign documents such that subjects cannot replace title deeds or access policies with more permissible ones.
Being entrusted with the above-mentioned secret keys implies that document processors are in the trusted computing base. Ensuring the document processors’ trustworthiness and sharing the secret keys with them can be done statically, based on standard operating-system security, or dynamically, based on trusted computing. The latter approach, detailed in Chapter 6, involves three basic steps as depicted in Figure 3.9:
1. A server that is already in the trusted computing base checks whether the trusted stack is in control of the subject’s computer.
2. It binds the secret keys to the subject’s TPM.
3. The trusted stack seals the secret keys in the subject’s TPM.
Document Processor
PEP 1. authenticate TPM & stack 2. bind secret keys to TPM o se s t u
ey k
ine PDP -l ecret s
l OS Hardware sea . stack for off 3 TPM
Figure 3.9: Key Distribution 30 3.3. DOCUMENT PROCESSORS Chapter 4
Content Model
In this chapter, we present a model for document content. Since we intend to control access to documents in a fine-grained manner, our document-content model is one with fine granularity. It is concrete enough to reflect a tree structure and abstract enough to encompass more than just XML documents; as a matter of fact, it even encompasses other kinds of hierarchical containers such as a directory information base or a file system. We motivate and informally describe our document-content model in Section 4.1. In Section 4.2, we formally specify it and—as proofs of concept of its generality— specialize it to two concrete document formats in Section 4.3. With Section 4.4, we conclude this chapter by citing two different definitions for semi-structured data and by explaining where our document-content model fits in.
4.1 Motivation and Informal Description
What are appropriate models for the inner structure of document content? One possibility is to define the inner structure of document content as an array of (independent) characters [62] with the result that access to every single character has to be controlled. Another possibility is to group characters and to define the inner structure of document content as an array of strings (separated by white space, for instance). In both cases, the structure is linear. However, many documents exhibit a tree structure (e.g., chapters, sections, paragraphs, etc.) that we would like to reflect in the document-content model. Consider the slides of a presentation such as the one in Figure 4.1, for instance. The presentation has four children, a title slide and three “regular” slides. The title slide has two children, a title (with value “DocSec”) and a subtitle (“PES”). The other three slides have two children each, the first child being a heading (“Agenda”, “Terms”, and “Conclu- sions”, respectively) and the second child being a list or a paragraph. The tree on the
31 32 4.1. MOTIVATION AND INFORMAL DESCRIPTION left of Figure 4.2 fully represents the presentation.
Agenda Terms Conclusions DocSec Document ● yada, yada, yada yada this and that ● yada Security PES ● yada that and this
Figure 4.1: Slide Show
Presentation <> -> TitleSlide <1> -> Title(DocSec) <1,1> -> Subtitle(PES) <1,2> -> Slide <2> -> Heading(Agenda) <2,1> -> UnnumberedList <2,2> -> ListItem() <2,2,1> -> Paragraph(yada) <2,2,1,1> -> ListItem() <2,2,2> -> Paragraph(yada) <2,2,2,1> -> ListItem() <2,2,3> -> Paragraph(yada) <2,2,3,1> -> Slide <3> -> Heading(Terms) <3,1> -> DefinitionList <3,2> -> ListItem(Document) <3,2,1> -> Paragraph(this and that) <3,2,1,1> -> ListItem(Security) <3,2,2> -> Paragraph(that and this) <3,2,2,1> -> Slide <4> -> Heading(Conclusions) <4,1> -> Paragraph(yada, yada, yada} <4,2> Figure 4.2: Slide Show Structure
Therefore, we propose a generic model for the inner structure of document content: rooted trees consisting of attributed nodes. For the example above, there would be a type attribute (with possible values “Presentation”, “TitleSlide”, etc.) and a text attribute (with arbitrary, potentially empty strings as values). To address the nodes, we employ a straightforward numbering scheme. By denot- ing the root with the empty sequence and by starting the branch numbers connecting a node with its children with 1, the paths on the right of Figure 4.2 are all valid paths for the example on its left. We do not limit our document-content model to state, but also include operations. These define the possible accesses to content. In particular, attribute values can be 4.2. FORMAL SPECIFICATION 33 read and changed, attributes can be added and deleted, and nodes can be added and deleted. Furthermore, attribute values, attributes, and nodes can be copied to and pasted from a clipboard. Note that explicitly modeling a clipboard and clipboard- related operations is not a luxury, but a necessity in order to support sticky policies.
4.2 Formal Specification
In this section, we formally specify document processors, documents, and content from the bottom up. The resulting class hierarchy is depicted in Figure 4.3. DocumentProcessor cd: Content Model models the user interfaces, Document the containers, and Content the attributed nodes.
Clipboard[V] Node[V] −node −attribute:Name x V #attributes:Name x V −attributeValue:V * −nodes
−clipboard
DocumentProcessor Document * Content −documents −content
*
Figure 4.3: Content Model Class Diagram
4.2.1 Building Blocks
We introduce two basic types, an abbreviation, a generic constant, and a generic class as building blocks. Name and Character are the two basic types and Value the abbreviation. Name represents the set of attribute names and Character the set of attribute-value characters. That is, Values are sequences (strings) of Characters. As we shall see, security-sensitive data is stored as attribute values. [Name, Character] Value == seq Character
The generic constant typeOf defines a family of functions. Given an object, the respective typeOf function returns the object’s type. [T ] typeOf : T → P T ∀ t : T • typeOf (t) = T
The generic class Node is a recursive type where each node has attributes and a sequence of child nodes. The primary variable attributes is a finite set of name-value 34 4.2. FORMAL SPECIFICATION pairs in which a name (of type Name) maps to at most one value (of generic type V ), i.e., attributes is a function mapping finitely many names to values. Note that the child nodes are contained. Node not only features primary variables, but also a secondary variable: equals is the set of all trees that are equal to the tree of which the node is the root. Furthermore, Node features seven operations: ReadNode returns a reference (node!) to the subtree at index index?. AddNode adds a reference to the tree referenced by node? at index index?. DeleteNode deletes the reference at index index?. ReadAttribute returns the name (name!)1 and the value (value!) of the attribute named name?. AddAttribute adds attribute (name?, value?) to the node. DeleteAttribute deletes the attribute named name? from the node. Finally, ReadAttributeValue returns the value (value!) of the attribute named name?. We reuse Node for content in this chapter and for title deeds and access policies in the next.
Node[V ] (equals)
attributes : Name 7 7→ V
nodes : seq ↓Node[V ] C ∆ equals : P ↓Node[V ] equals = {t : typeOf (self) | attributes = t.attributes ∧ #nodes = #t.nodes ∧ (∀ i : N1 | i ≤ #nodes • nodes(i) ∈ t.nodes(i).equals)}
Init Note that attributes need not be equal nodes = h i to the empty set.
ReadNode index?: N1 node!: ↓Node[V ] index? ≤ #nodes node! = node(index?)
1Returning the name aids in specifying the clipboard-related operations later on. 4.2. FORMAL SPECIFICATION 35
AddNode ∆(nodes) index?: N1 node?: ↓Node[V ] index? ≤ #nodes + 1 #nodes0 = #nodes + 1 0 ∀ i : N1 | i < index? • nodes (i) = nodes(i) nodes0(index?) = node? 0 ∀ i : N1 | index? < i ∧ i ≤ #nodes + 1 • nodes (i) = nodes(i − 1) 0 0 DeleteNode =b AddNode[node!, nodes , nodes/node?, nodes, nodes ] ReadAttribute name?: Name name!: Name value!: V name! = name? name! 7→ value! ∈ attributes
AddAttribute ∆(attributes) name?: Name value?: V name? 6∈ dom attributes attributes0 = attributes ∪ {name? 7→ value?}
DeleteAttribute =b AddAttribute[attributes0, attribute/attribute, attributes0] \ (value?)
ReadAttributeValue =b ReadAttribute \ (name!)
4.2.2 Clipboard
Clipboard is a generic class type. Objects of type Clipboard can cache a node, an attribute, and an attribute value. Note that the cached node is contained. Clipboard features six visible operations: a getter and a setter operation each for the node, the attribute, and the attribute value.
Clipboard[V ] (Init, getNode, setNode, getAttribute, setAttribute, getAttributeValue, setAttributeValue) 36 4.2. FORMAL SPECIFICATION
Init
node : P ↓Node[V ] C node = ∅ attribute : P(Name × V ) attribute = ∅ attributeValue : P V attributeValue = ∅ #node ≤ 1 #attribute ≤ 1 #attributeValue ≤ 1
getNode setNode node!: ↓Node[V ] ∆(node) node?: ↓Node[V ] ∃ n : ↓Node[V ] • node = {n} ∧ node! ∈ n.equals ∧ node! 6= n ∃ n : ↓Node[V ] • node0 = {n} ∧ node? ∈ n.equals ∧ node? 6= n
getAttribute setAttribute name!: Name ∆(attribute) value!: V name?: Name value?: V attribute = {(name!, value!)} attribute0 = {(name?, value?)}
getAttributeValue setAttributeValue attributeValue!: V ∆(attributeValue) attributeValue?: V attributeValue = {attributeValue!} attributeValue0 = {attributeValue?}
4.2.3 Content
Content is the single most important type of our document-content model and features seventeen visible operations. These operations determine how content can be accessed. Thus, controlling access to content means controlling who can invoke these operations under which conditions. But first things first.
Content (equals, Init, GetNumberOfNodes, GetNodeType, GetDomainOfAttributes, ReadNode, AddNode, DeleteNode, CopyNode, PasteNode, AddAttribute, DeleteAttribute, CopyAttribute, PasteAttribute, ReadAttributeValue, AddAttributeValue, DeleteAttributeValue, CopyAttributeValue, PasteAttributeValue) Node[Value][AddNodeV /AddNode] clipboard : Clipboard[Value] ∀ c : ↓Content • c.clipboard = clipboard 4.2. FORMAL SPECIFICATION 37
nodes : seq ↓Content C
GetNumberOfNodes filter?: P ↓Content numberOfNodes!: N numberOfNodes! = #(nodes filter?)
GetNodeType index?: N1 nodeType!: P ↓Content index? ≤ #nodes nodeType! = typeOf (nodes(index?))
AddNode =b [node!: Content | node!.Init ∧ node!.attributes = ∅] k AddNodeV CopyNode =b ReadNode k clipboard.setNode PasteNode =b clipboard.getNode k AddNodeV GetDomainOfAttributes filter?: P Name domainOfAttributes!: P Name domainOfAttributes! = {name : dom attributes | name ∈ filter?}
CopyAttribute =b ReadAttribute k clipboard.setAttribute PasteAttribute =b clipboard.getAttribute k AddAttribute AddAttributeValue ∆(attributes) name?: Name value?: Value to?: N1 value : Value name? ∈ dom attributes #value? > 0 to? ≤ #value + 1 value = attributes(name?) attributes0 = attributes⊕ {name? 7→ (1 .. to? − 1) value a value? a (to? .. #value) value} 38 4.2. FORMAL SPECIFICATION
DeleteAttributeValue ∆(attributes) name?: Name fromInclusive?: N1 toExclusive?: N1 value : Value name? ∈ dom attributes toExclusive? − fromInclusive? > 0 value = attributes(name?) toExclusive? ≤ #value + 1 0 attributes = attributes ⊕ {name? 7→ (1 .. fromInclusive? − 1) valuea (toExclusive? .. #value) value}
SubValue value?: Value fromInclusive?: N1 toExclusive?: N1 value!: Value fromInclusive? ≤ #value? toExclusive? ≤ #value? + 1 fromInclusive? < toExclusive? value! = (fromInclusive? .. toExclusive? − 1) value?
CopyAttributeValue =b (ReadAttributeValue k SubValue) k clipboard.setAttributeValue PasteAttributeValue =b clipboard.getAttributeValue k AddAttributeValue
Content is a subclass of Node. More specifically, it is a subclass of Node with the type Value substituted for the generic type V . All content nodes share a reference to the same clipboard so that nodes, attributes, and attribute values can be copied and pasted between them. The seventeen visible operations are:
• GetNumberOfNodes, GetNodeType, and GetDomainOfAttributes allow for discov- ering the content structure. Access to these three operations will not be controlled.
• ReadNode allows for reading a node. This is akin to expanding the node in a graphical user interface. When access to this operation is controlled, subjects will need read access to the node to be read/expanded.
• AddNode, DeleteNode, and PasteNode as well as AddAttribute, DeleteAttribute, and PasteAttribute allow for changing the content structure. When access is controlled, subjects will need change access to the node being changed, they will not need any access to the node or attribute being added, deleted, or pasted. Since 4.2. FORMAL SPECIFICATION 39
subjects may not have access to the node or attribute being pasted, the pasted node or attribute will be collapsed in a graphical user interface.
• CopyNode, CopyAttribute, and CopyAttributeValue allow for copying content (data). Access to these three operations will not be controlled, either.
• ReadAttributeValue allows for reading content data. When access to this operation is controlled, subjects will need read access to the attribute being read/ expanded.
• AddAttributeValue, DeleteAttributeValue, and PasteAttributeValue allow for changing content data. When access is controlled, subjects will need change access to the attribute being changed, they will not need change access to the attribute’s node. Since subjects may not have access to the attribute value being pasted, but collapsing (in a graphical user interface) the attribute whose value is to be changed is undesirable from a usability point of view, access to the attribute value cached in the clipboard must be controlled instead.
4.2.4 Document
To emphasize the fact that documents are containers, we introduce the empty class Container, which class Document and other container classes inherit.2
Container (Init) Init
Document is a wrapper class around a document’s root node. An empty document (i.e., a document in its initial state) has a root node with no child nodes (as specified in Content’s Init predicate) and with no attributes.
Document (content, Init) Container Init
content : Content C content.Init content.attributes = ∅
2Container is akin to a marker interface (also called tagging interface) in Java. 40 4.2. FORMAL SPECIFICATION
4.2.5 Document Processor
The DocumentProcessor class defines two (primary) variables: document is the set of open documents and nodeToDoc maps nodes that have been read/expanded to their document, which must be open. New documents can be created (NewDocument operation), existing documents can be opened (OpenDocument operation), and open documents can be closed (CloseDocument operation). The ReadRoot operation allows to read/expand a document’s root node. Most other visible operations are promotions of the respective Content operation. The object (referenced by) d? models the selection of the document that is currently active (i.e., whose window is in front if the user interface is graphical) and n? models the selection of the active document’s node to operate on. Only nodes that have previously been read/expanded can be operated on. The cut operations simply combine the respective copy and delete operations.
DocumentProcessor (Init, NewDocument, OpenDocument, CloseDocument, ReadRoot, GetNumberOfNodes, GetNodeType, GetDomainOfAttributes, ReadNode, AddNode, DeleteNode, CopyNode, CutNode, PasteNode, AddAttribute, DeleteAttribute, CopyAttribute, CutAttribute, PasteAttribute, ReadAttributeValue, AddAttributeValue, DeleteAttributeValue, CopyAttributeValue, CutAttributeValue, PasteAttributeValue)
documents : P Document nodeToDoc : Content 7→ Document ran nodeToDoc ⊆ documents
Init documents = ∅ nodeToDoc = ∅
OpenDocument ∆(documents) d?: Document d? 6∈ documents documents0 = documents ∪ {d?}
NewDocument =b [d!: Document | d!.Init] k OpenDocument CloseDocument ∆(documents, nodeToDoc) d?: Document d? ∈ documents documents0 = documents \{d?} 0 0 nodeToDoc = documents B nodeToDoc 4.2. FORMAL SPECIFICATION 41
ReadRoot ∆(nodeToDoc) d?: Document d? ∈ documents nodeToDoc0 = nodeToDoc ∪ {d?.content 7→ d?}
ContentNode d?: documents n?: Content d? = nodeToDoc(n?)
GetNumberOfNodes =b [ContentNode] • n?.GetNumberOfNodes GetNodeType =b [ContentNode] • n?.GetNodeType GetDomainOfAttributes =b [ContentNode] • n?.GetDomainOfAttributes ExpandContentNode ∆(nodeToDoc) d?: documents node?: Content nodeToDoc0 = nodeToDoc ∪ {node? 7→ d?}
ReadNode =b [ContentNode] • n?.ReadNode k ExpandContentNode AddNode =b [ContentNode] • n?.AddNode DropContentNode ∆(nodeToDoc) d?: documents node?: Content nodeToDoc0 = nodeToDoc \{node? 7→ d?}
DeleteNode =b [ContentNode] • n?.DeleteNode k DropContentNode CopyNode =b [ContentNode] • n?.CopyNode CutNode =b CopyNode ∧ DeleteNode PasteNode =b [ContentNode] • n?.PasteNode AddAttribute =b [ContentNode] • n?.AddAttribute DeleteAttribute =b [ContentNode] • n?.DeleteAttribute CopyAttribute =b [ContentNode] • n?.CopyAttribute CutAttribute =b CopyAttribute ∧ DeleteAttribute PasteAttribute =b [ContentNode] • n?.PasteAttribute ReadAttributeValue =b [ContentNode] • n?.ReadAttributeValue AddAttributeValue =b [ContentNode] • n?.AddAttributeValue DeleteAttributeValue =b [ContentNode] • n?.DeleteAttributeValue CopyAttributeValue =b [ContentNode] • n?.CopyAttributeValue CutAttributeValue =b CopyAttributeValue ∧ DeleteAttributeValue PasteAttributeValue =b [ContentNode] • n?.PasteAttributeValue 42 4.3. PROOFSOF CONCEPT
4.3 Proofs of Concept
We specialize the document-content model by subclassing Content. The subclasses impose additional constraints on nodes. The Content subclasses do not have the same interface as Content. However, each visible operation is mapped to a visible Content operation, which will save us from specializing the policy as well. This is not only convenient, but potentially also more secure as a mature PDP implementation can be reused in any application whose document format is a specialization of our document- content model. Furthermore, the sticky-policies paradigm even holds when data is copied from one specialization to another, e.g., from reports (cf. §4.3.1) to XML documents (cf. §4.3.2).
4.3.1 Reports
In this section, we specialize the abstract document-content model to a model for reports. Reports are very simple text documents that have a title and zero or more paragraphs followed by zero or more chapters. Chapters have a title and zero or more paragraphs followed by zero or more sections. And sections have a title and zero or cd: Report more paragraphs. The types of report nodes are depicted in Figure 4.4.
TextAttributeNode
Paragraph ParagraphParent *
Section Chapter Report * *
Erstellt mit Poseidon forFigure UML Community 4.4: Report Edition. Nicht Nodes zur kommerziellen Nutzung.
Content
All report nodes have in common that they have exactly one attribute whose name is equal to the constant text. Its value is the paragraph text for paragraph nodes and the title for report, chapter, and section nodes.
text : Name 4.3. PROOFSOF CONCEPT 43
As the superclass of all report nodes, TextAttributeNode defines the relationship to Content and establishes the above-mentioned fact that all report nodes have exactly one attribute.
TextAttributeNode (equals, Init) Content Init
nodes : seq ↓TextAttributeNode C attributes = {text 7→ h i} dom attributes = {text} ∀ n : nodes • n 6∈ TextAttributeNode
ReadTextValue =b [name!: Name | name! = text] k ReadAttributeValue AddTextValue =b [name!: Name | name! = text] k AddAttributeValue DeleteTextValue =b [name!: Name | name! = text] k DeleteAttributeValue CopyTextValue =b [name!: Name | name! = text] k CopyAttributeValue PasteTextValue =b [name!: Name | name! = text] k PasteAttributeValue
Nodes of type Paragraph have no child nodes. That is, they are leaves.
Paragraph (equals, Init, ReadParagraphValue, AddParagraphValue, DeleteParagraphValue, CopyParagraphValue, PasteParagraphValue) TextAttributeNode[ReadParagraphValue/ReadTextValue, AddParagraphValue/AddTextValue, DeleteParagraphValue/DeleteTextValue, CopyParagraphValue/CopyTextValue, PasteParagraphValue/PasteTextValue]
nodes = h i
Report, chapter, and section nodes have in common that they may have child nodes of type Paragraph and—when they do so—that those child nodes come first.
ParagraphParent (equals, Init) TextAttributeNode[ReadTitleValue/ReadTextValue, AddTitleValue/AddTextValue, DeleteTitleValue/DeleteTextValue, CopyTitleValue/CopyTextValue, PasteTitleValue/PasteTextValue] 44 4.3. PROOFSOF CONCEPT
nodes : seq(Paragraph ∪ ↓ParagraphParent) C ∆ nrOfParagraphs : N ∀ n : nodes • n 6∈ ParagraphParent nrOfParagraphs ≤ #nodes ∧ (1 .. nrOfParagraphs) nodes ∈ seq Paragraph ∧ (nrOfParagraphs + 1 .. #nodes) nodes ∈ seq ↓ParagraphParent
GetNumberOfParagraphs =b [filter!: P ↓Paragraph | filter! = ↓Paragraph] k GetNumberOfNodes[numberOfParagraphs!/numberOfNodes!]) GetNumberOfPPs =b [filter!: P ParagraphParent | filter! = ParagraphParent] k GetNumberOfNodes[numberOfPPs!/numberOfNodes!])
ReadParagraph =b [index?, index!: N1 | index? ≤ nrOfParagraphs ∧ index! = index?] k ReadNode AddParagraph =b [node!: Paragraph | node!.Init] k AddNodeV DeleteParagraph =b [index?: N1 | index? ≤ nrOfParagraphs] ∧ DeleteNode CopyParagraph =b [index?: N1 | index? ≤ nrOfParagraphs] ∧ CopyNode PasteParagraph =b (clipboard.getNode k [node?: Paragraph]) ∧ PasteNode ReadPP =b [index?, index!: N1 | index? ≤ nrOfParagraphsParents ∧ index! = index? + nrOfParagraphs] k ReadNode DeletePP =b [index?, index!: N1 | index? ≤ nrOfParagraphParents ∧ index! = index? + nrOfParagraphs] k DeleteNode CopyPP =b [index?, index!: N1 | index? ≤ nrOfParagraphParents ∧ index! = index? + nrOfParagraphs] k CopyNode
Nodes of type Section have child nodes of type Paragraph only.
Section (equals, Init, GetNumberOfParagraphs, ReadParagraph, AddParagraph, DeleteParagraph, CopyParagraph, PasteParagraph, ReadTitleValue, AddTitleValue, DeleteTitleValue, CopyTitleValue, PasteTitleValue) ParagraphParent
nodes : seq Paragraph C
Nodes of type Chapter have zero or more child nodes of type Paragraph followed by zero or more child nodes of type Section.
Chapter (equals, Init, GetNumberOfParagraphs, ReadParagraph, AddParagraph, DeleteParagraph, CopyParagraph, PasteParagraph, GetNumberOfSections, ReadSection, AddSection, DeleteSection, CopySection, PasteSection, ReadTitleValue, AddTitleValue, DeleteTitleValue, CopyTitleValue, PasteTitleValue) 4.3. PROOFSOF CONCEPT 45
ParagraphParent[GetNumberOfSections/GetNumberOfPPs, ReadSection/ReadPP, DeleteSection/DeletePP, CopySection/CopyPP]
nodes : seq(Paragraph ∪ Section) C
AddSection =b [index?, index!: N1; node!: Section | index? ≤ nrOfParagraphParents + 1 ∧ index! = index? + nrOfParagraphs ∧ node!.Init] k AddNodeV PasteSection =b (clipboard.getNode k [node?: Section])∧ [index?, index!: N1 | index? ≤ nrOfParagraphParents ∧ index! = index? + nrOfParagraphs] k PasteNode
Report is the type of report content root nodes. Nodes of type Report have zero or more child nodes of type Paragraph followed by zero or more nodes of type Chapter. Report (equals, Init, GetNumberOfParagraphs, ReadParagraph, AddParagraph, DeleteParagraph, CopyParagraph, PasteParagraph, GetNumberOfChapters, ReadChapter, AddChapter, DeleteChapter, CopyChapter, PasteChapter, ReadTitleValue, AddTitleValue, DeleteTitleValue, CopyTitleValue, PasteTitleValue) ParagraphParent[GetNumberOfChapters/GetNumberOfPPs, ReadChapter/ReadPP, DeleteChapter/DeletePP, CopyChapter/CopyPP]
nodes : seq(Paragraph ∪ Chapter) C
AddChapter =b [index?, index!: N1; node!: Chapter | index? ≤ nrOfParagraphParents + 1 ∧ index! = index? + nrOfParagraphs ∧ node!.Init] k AddNodeV PasteChapter =b (clipboard.getNode k [node?: Chapter])∧ [index?, index!: N1 | index? ≤ nrOfParagraphParents ∧ index! = index? + nrOfParagraphs] k PasteNode
The beauty of Report, Chapter, Section, and Paragraph being Content subclasses whose visible operations are specializations of visible Content operations is that when access is controlled, neither the PDP nor the title deeds and access policies need to be specialized in any way. For example, instead of checking with the PDP whether a ReadParagraph operation should be granted, the PEP can ask the PDP to decide on a ReadNode operation.
Container
ReportDocument is a wrapper class around a report’s root node. An empty report (i.e., a report in its initial state) has a root node with no child nodes and with an empty title attribute. 46 4.3. PROOFSOF CONCEPT
ReportDocument (content, Init) Container Init
content : Report C content.Init
Document Processor
The ReportProcessor class is to Report, Chapter, Section, and Paragraph nodes what the DocumentProcessor is to plain Content nodes. Consequently, most visible operations are promotions of the respective Report, Chapter, Section, and Paragraph operations. But the design principles (e.g., the cut operations being simple combinations of the respective copy and delete operations) remain the same.
ReportProcessor (Init, NewDocument, OpenDocument, CloseDocument, ReadRoot, ReadParagraphValue, AddParagraphValue, DeleteParagraphValue, CopyParagraphValue, PasteParagraphValue, GetNumberOfParagraphs, ReadParagraph, AddParagraph, DeleteParagraph, CopyParagraph, PasteParagraph, GetNumberOfSections, ReadSection, AddSection, DeleteSection, CopySection, PasteSection, GetNumberOfChapters, ReadChapter, AddChapter, DeleteChapter, CopyChapter, PasteChapter, ReadTitleValue, AddTitleValue, DeleteTitleValue, CopyTitleValue, PasteTitleValue)
documents : P ReportDocument nodeToDoc : ↓TextAttributeNode 7→ ReportDocument ran nodeToDoc ⊆ documents
Init documents = ∅
OpenDocument ∆(documents) d?: ReportDocument d? 6∈ documents documents0 = documents ∪ {d?}
NewDocument =b [d!: ReportDocument | d!.Init] k OpenDocument 4.3. PROOFSOF CONCEPT 47
CloseDocument ∆(documents, nodeToDoc) d?: ReportDocument d? ∈ documents documents0 = documents \{d?} 0 0 nodeToDoc = documents B nodeToDoc
ReadRoot ∆(nodeToDoc) d?: Documents d?: documents nodeToDoc0 = nodeToDoc ∪ {d?.content 7→ d?}
ParagraphNode d?: documents n?: Paragraph d? = nodeToDoc(n?)
ParagraphParentNode d?: documents n?: ↓ParagraphParent d? = nodeToDoc(n?)
SectionNode d?: documents n?: Section d? = nodeToDoc(n?)
ChapterNode d?: documents n?: Chapter d? = nodeToDoc(n?)
ReportNode d?: documents n?: Report d? = nodeToDoc(n?)
GetNumberOfParagraphs =b [ParagraphParentNode] • n?.GetNumberOfParagraphs GetNumberOfSections =b [ChapterNode] • n?.GetNumberOfSections GetNumberOfChapters =b [ReportNode] • n?.GetNumberOfChapters 48 4.3. PROOFSOF CONCEPT
ExpandTextAttributeNode ∆(nodeToDoc) d?: documents node?: ↓TextAttributeNode nodeToDoc0 = nodeToDoc ∪ {node? 7→ d?}
DropTextAttributeNode ∆(nodeToDoc) d?: documents node?: ↓TextAttributeNode nodeToDoc0 = nodeToDoc \{node? 7→ d?}
ReadParagraph =b [ParagraphParentNode] • n?.ReadParagraph k ExpandTextAttributeNode AddParagraph =b [ParagraphParentNode] • n?.AddParagraph DeleteParagraph =b [ParagraphParentNode] • n?.DeleteParagraph k DropTextAttributeNode CopyParagraph =b [ParagraphParentNode] • n?.CopyParagraph CutParagraph =b CopyParagraph ∧ DeleteParagraph PasteParagraph =b [ParagraphParentNode] • n?.PasteParagraph ReadSection =b [ChapterNode] • n?.ReadSection k AddTextAttributeNode AddSection =b [ChapterNode] • n?.AddSection DeleteSection =b [ChapterNode] • n?.DeleteSection k DeleteTextAttributeNode CopySection =b [ChapterNode] • n?.CopySection CutSection =b CopySection ∧ DeleteSection PasteSection =b [ChapterNode] • n?.PasteSection ReadChapter =b [ReportNode] • n?.ReadChapter k AddTextAttributeNode AddChapter =b [ReportNode] • n?.AddChapter DeleteChapter =b [ReportNode] • n?.DeleteChapter k DeleteTextAttributeNode CopyChapter =b [ReportNode] • n?.CopyChapter CutChapter =b CopyChapter ∧ DeleteChapter PasteChapter =b [ReportNode] • n?.PasteChapter ReadParagraphValue =b [ParagraphNode] • n?.ReadParagraphValue AddParagraphValue =b [ParagraphNode] • n?.AddParagraphValue DeleteParagraphValue =b [ParagraphNode] • n?.DeleteParagraphValue CopyParagraphValue =b [ParagraphNode] • n?.CopyParagraphValue CutParagraphValue =b CopyParagraphValue ∧ DeleteParagraphValue PasteParagraphValue =b [ParagraphNode] • n?.PasteParagraphValue ReadTitleValue =b [ParagraphParentNode] • n?.ReadTitleValue AddTitleValue =b [ParagraphParentNode] • n?.AddTitleValue DeleteTitleValue =b [ParagraphParentNode] • n?.DeleteTitleValue CopyTitleValue =b [ParagraphParentNode] • n?.CopyTitleValue CutTitleValue =b CopyTitleValue ∧ DeleteTitleValue PasteTitleValue =b [ParagraphParentNode] • n?.PasteTitleValue 4.3. PROOFSOF CONCEPT 49
4.3.2 XML Documents
In this section, we specialize the abstract document-content model to a model for XML documents. We have chosen XML documents for one of our proofs of concept not only because this allows us to compare our work to a large body of research (cf. §8.1), but also because XML applications have been, and are being, defined for all kinds of data, from highly structured to totally unstructured [75]. Therefore, our access- control model (as well as system) is of potential interest for present and future XML applications and especially document types typically associated with office documents (e.g., texts, spreadsheets, or presentations). OpenDocument [94, 38], for instance, is XML-based and even Word and Excel from the Microsoft Office 2003 suite allow for saving documents in an XML-based format [85, 78].
Content
Before we define the XML nodes depicted in Figure 2.5 on page 15, we have to introduce a few constants. PITarget is the set of attribute values that constitute a legal processing-instruction target and QNameV is the set of attribute values that constitute a legal element tag, namely qualified names.
PITarget, QNameV : P Value h i ∈ PITarget h i ∈ QNameV
QNameN is the set of attribute names that constitute legal XML-attribute names, namely qualified names as well. Note that in a standard XML encoding, the sets QNameV and QNameN coincide, but there is no need to express that in our model. As a matter of fact, our model emphasizes that element tags can be secured but XML-attribute names cannot. Finally, comment, target, data, text, and tag are the names of (non-XML) attributes appearing in the definitions of XML nodes below.
QNameN : P Name QNameN ⊂ Name
comment, target, data, text, tag : Name tag 6∈ QNameN
As the superclass of all XML nodes, XmlNode defines the relationship to Content and establishes the fact that all child nodes of XML nodes are XML nodes as well.
XmlNode (equals, Init) 50 4.3. PROOFSOF CONCEPT
Content
nodes : seq ↓XmlNode C ∀ n : nodes • n 6∈ XmlNode
Comments are nodes that have one attribute, the value of which is the actual comment, and no children. Comment (equals, Init, ReadCommentValue, AddCommentValue, DeleteCommentValue, CopyCommentValue, PasteCommentValue) XmlNode Init attributes = {(comment 7→ h i)} dom attributes = {comment} nodes = h i
ReadCommentValue =b [name!: Name | name! = comment] k ReadAttributeValue AddCommentValue =b [name!: Name | name! = comment] k AddAttributeValue DeleteCommentValue =b [name!: Name | name! = comment] k DeleteAttributeValue CopyCommentValue =b [name!: Name | name! = comment] k CopyAttributeValue PasteCommentValue =b [name!: Name | name! = comment] k PasteAttributeValue
Processing instructions are nodes that have two attributes, the values of which are the target and the data, and no children. ProcessingInstruction (equals, Init, ReadTargetValue, AddTargetValue, DeleteTargetValue, CopyTargetValue, PasteTargetValue, ReadDataValue, AddDataValue, DeleteDataValue, CopyDataValue, PasteDataValue) XmlNode Init attributes = {target 7→ h i, dom attributes = {target, data} data 7→ h i} ∃ v : PITarget • v = attributes(target) nodes = h i
ReadTargetValue =b [name!: Name | name! = target] k ReadAttributeValue AddTargetValue =b [name!: Name | name! = target] k AddAttributeValue DeleteTargetValue =b [name!: Name | name! = target] k DeleteAttributeValue CopyTargetValue =b [name!: Name | name! = target] k CopyAttributeValue PasteTargetValue =b [name!: Name | name! = target] k PasteAttributeValue Note that AddTargetValue, DeleteTargetValue, and PasteTargetValue only occur when the resulting value is in PITarget. 4.3. PROOFSOF CONCEPT 51
ReadDataValue =b [name!: Name | name! = data] k ReadAttributeValue AddDataValue =b [name!: Name | name! = data] k AddAttributeValue DeleteDataValue =b [name!: Name | name! = data] k DeleteAttributeValue CopyDataValue =b [name!: Name | name! = data] k CopyAttributeValue PasteDataValue =b [name!: Name | name! = data] k PasteAttributeValue
Texts are nodes that have one attribute, the value of which is the actual text, and no children. Text (equals, Init, ReadTextValue, AddTextValue, DeleteTextValue, CopyTextValue, PasteTextValue) XmlNode Init attributes = {(text 7→ h i)} dom attributes = {text} nodes = h i
ReadTextValue =b [name!: Name | name! = text] k ReadAttributeValue AddTextValue =b [name!: Name | name! = text] k AddAttributeValue DeleteTextValue =b [name!: Name | name! = text] k DeleteAttributeValue CopyTextValue =b [name!: Name | name! = text] k CopyAttributeValue PasteTextValue =b [name!: Name | name! = text] k PasteAttributeValue
Elements are nodes that have one or more attributes and zero or more children. One attribute is the attribute whose name is equal to tag and whose value is the element’s tag and the other attributes are the actual XML attributes. Text child nodes are never adjacent.3 Element (equals, Init, GetTypeOfNode, GetNumberOfXmlNodes, ReadXmlNode, AddComment, AddElement, AddProcessingInstruction, AddText, DeleteXmlNode, CopyXmlNode, PasteXmlNode, ReadTagValue, AddTagValue, DeleteTagValue, CopyTagValue, PasteTagValue, GetDomainOfXmlAttributes, AddXmlAttribute, DeleteXmlAttribute, CopyXmlAttribute, PasteXmlAttribute, ReadXmlAttributeValue, AddXmlAttributeValue, DeleteXmlAttributeValue, CopyXmlAttributeValue, PasteXmlAttributeValue)
3According to the DOM specification [131], “[w]hen a document is first made available via the DOM, there is only one Text node for each block of text. Users may create adjacent Text nodes that represent the contents of a given element without any intervening markup, but should be aware that there is no way to represent the separations between these nodes in XML [...], so they will not (in general) persist between DOM editing sessions. The Node.normalize() method merges any such adjacent Text objects into a single node for each block of text.” As we anticipate title deeds and access policies and do not want to worry about what it would mean to normalize them, we go further than the DOM in that in our model subjects cannot create adjacent text nodes in the first place. 52 4.3. PROOFSOF CONCEPT
XmlNode
nodes : seq(Comment ∪ Element ∪ ProcessingInstruction ∪ Text) C tag ∈ dom attributes ∃ v : QNameV • v = attributes(tag) dom attributes \{tag} ∈ P QNameN ∀ i, j : dom nodes | i = j − 1 • nodes(i) 6∈ Text ∨ nodes(j ) 6∈ Text
Init attributes = {(tag 7→ h i)}
GetNumberOfXmlNodes =b [filter!: P ↓XmlNode | filter! = ↓XmlNode] k GetNumberOfNodes[numberOfXmlNodes!/numberOfNodes!]
ReadXmlNode =b ReadNode AddComment =b [node!: Comment | node!.Init] k AddNodeV AddElement =b [node!: Element | node!.Init] k AddNodeV AddProcessingInstruction =b [node!: ProcessingInstruction | node!.Init] k AddNodeV AddText =b [node!: Text | node!.Init] k AddNodeV DeleteXmlNode =b DeleteNode CopyXmlNode =b CopyNode PasteXmlNode =b PasteNode Note that AddText and PasteXmlNode only occur when two Text nodes do not end up as immediate siblings.
ReadTagValue =b [name!: Name | name! = tag] k ReadAttributeValue AddTagValue =b [name!: Name | name! = tag] k AddAttributeValue DeleteTagValue =b [name!: Name | name! = tag] k DeleteAttributeValue CopyTagValue =b [name!: Name | name! = tag] k CopyAttributeValue PasteTagValue =b [name!: Name | name! = tag] k PasteAttributeValue Note that AddTag, DeleteTag, and PasteTag only occur when the resulting value is in QNameV .
GetDomainOfXmlAttributes =b [filter?: P QNameN | filter? = QNameN ] k GetDomainOfAttributes[domainOfXmlAttributes!/domainOfAttributes!] AddXmlAttribute =b AddAttribute DeleteXmlAttribute =b DeleteAttribute CopyXmlAttribute =b [name?: QNameN ] ∧ CopyAttribute PasteXmlAttribute =b PasteAttribute Note that AddXmlAttribute and PasteXmlAttribute only occur when the element does not end up having two XML attributes with the same name. Note further that AddXmlAttribute, DeleteXmlAttribute, and PasteXmlAttribute only occur when the name given is in QNameN . 4.3. PROOFSOF CONCEPT 53
ReadXmlAttributeValue =b [name?: QNameN ] ∧ ReadAttributeValue AddXmlAttributeValue =b [name?: QNameN ] ∧ AddAttributeValue DeleteXmlAttributeValue =b [name?: QNameN ] ∧ DeleteAttributeValue CopyXmlAttributeValue =b [name?: QNameN ] ∧ CopyAttributeValue PasteXmlAttributeValue =b [name?: QNameN ] ∧ PasteAttributeValue
Documents are nodes that have no attribute and zero or more children. At most one child is an element node and no child node is a text node.
Document (equals, Init, GetTypeOfNode, GetNumberOfXmlNodes, ReadXmlNode, AddComment, AddElement, AddProcessingInstruction, DeleteXmlNode, CopyXmlNode, PasteXmlNode) XmlNode
nodes : seq(Comment ∪ Element ∪ ProcessingInstruction) C
attributes = ∅ ∀ n1, n2 : nodes • n1 6∈ Element ∨ n2 6∈ Element
GetNumberOfXmlNodes =b [filter!: P ↓XmlNode | filter! = ↓XmlNode] k GetNumberOfNodes[numberOfXmlNodes!/numberOfNodes!]
ReadXmlNode =b ReadNode AddComment =b [node!: Comment | node!.Init] k AddNodeV AddElement =b [node!: Element | node!.Init] k AddNodeV AddProcessingInstruction =b [node!: ProcessingInstruction | node!.Init] k AddNodeV DeleteXmlNode =b DeleteNode CopyXmlNode =b CopyNode PasteXmlNode =b PasteNode Note that AddElement and PasteXmlNode only occur when the document does not end up having two root elements.
The beauty of Comment, ProcessingInstruction, Text, Element, and Document being Content subclasses whose visible operations are specializations of visible Content operations is that when access is controlled, neither the PDP nor the title deeds and access policies need to be specialized in any way. For example, instead of checking with the PDP whether a ReadXmlNode operation should be granted, the PEP can ask the PDP to decide on a ReadNode operation.
Container
XMLDocument is a wrapper class around an XML document’s root node. An empty XML document (i.e., an XML document in its initial state) has a root node with no child nodes. 54 4.3. PROOFSOF CONCEPT
XmlDocument (content, Init) Container Init
content : Document C content.Init
Document Processor
The XmlProcessor class is to Comment, ProcessingInstruction, Text, Element, and Docu- ment nodes what the DocumentProcessor is to plain Content nodes. Consequently, most visible operations are promotions of the respective Comment, ProcessingInstruction, Text, Element, and Document operations. But the design principles (e.g., the cut operations being simple combinations of the respective copy and delete operations) remain the same.
XmlProcessor (Init, NewDocument, OpenDocument, CloseDocument, ReadRoot, ReadCommentValue, AddCommentValue, DeleteCommentValue, CopyCommentValue, CutCommentValue, PasteCommentValue, ReadTargetValue, AddTargetValue, DeleteTargetValue, CopyTargetValue, CutTargetValue, PasteTargetValue, ReadDataValue, AddDataValue, DeleteDataValue, CopyDataValue, CutDataValue, PasteDataValue, ReadTextValue, AddTextValue, DeleteTextValue, CopyTextValue, CutTextValue, PasteTextValue, GetTypeOfNode, GetNumberOfXmlNodes, ReadXmlNode, AddComment, AddElement, AddProcessingInstruction, AddText, DeleteXmlNode, CopyXmlNode, CutXmlNode, PasteXmlNode, ReadTagValue, AddTagValue, DeleteTagValue, CopyTagValue, CutTagValue, PasteTagValue, GetDomainOfXmlAttributes, AddXmlAttribute, DeleteXmlAttribute, CopyXmlAttribute, CutXmlAttribute, PasteXmlAttribute, ReadXmlAttributeValue, AddXmlAttributeValue, DeleteXmlAttributeValue, CopyXmlAttributeValue, CutXmlAttributeValue, PasteXmlAttributeValue)
documents : P XmlDocument nodeToDoc : ↓XmlNode 7→ XmlDocument ran nodeToDoc ⊆ documents
Init documents = ∅ 4.3. PROOFSOF CONCEPT 55
OpenDocument ∆(documents) d?: XmlDocument d? 6∈ documents documents0 = documents ∪ {d?}
NewDocument =b [d!: XmlDocument | d!.Init] k OpenDocument CloseDocument ∆(documents, nodeToDoc) d?: XmlDocument d? ∈ documents documents0 = documents \{d?} 0 0 nodeToDoc = documents B nodeToDoc
ReadRoot ∆(nodeToDoc) d?: Documents d?: documents nodeToDoc0 = nodeToDoc ∪ {d?.content 7→ d?}
CommentNode d?: documents n?: Comment d? = nodeToDoc(n?)
ProcessingInstructionNode d?: documents n?: ProcessingInstruction d? = nodeToDoc(n?)
TextNode d?: documents n?: Text d? = nodeToDoc(n?)
ElementNode d?: documents n?: Element d? = nodeToDoc(n?) 56 4.3. PROOFSOF CONCEPT
DocumentNode d?: documents n?: Document d? = nodeToDoc(n?)
ReadCommentValue =b [CommentNode] k n?.ReadCommentValue AddCommentValue =b [CommentNode] k n?.AddCommentValue DeleteCommentValue =b [CommentNode] k n?.DeleteCommentValue CopyCommentValue =b [CommentNode] k n?.CopyCommentValue CutCommentValue =b CopyCommentValue ∧ DeleteCommentValue PasteCommentValue =b [CommentNode] k n?.PasteCommentValue ReadTargetValue =b [ProcessingInstructionNode] k n?.ReadTargetValue AddTargetValue =b [ProcessingInstructionNode] k n?.AddTargetValue DeleteTargetValue =b [ProcessingInstructionNode] k n?.DeleteTargetValue CopyTargetValue =b [ProcessingInstructionNode] k n?.CopyTargetValue CutTargetValue =b CopyTargetValue ∧ DeleteTargetValue PasteTargetValue =b [ProcessingInstructionNode] k n?.PasteTargetValue ReadDataValue =b [ProcessingInstructionNode] k n?.ReadDataValue AddDataValue =b [ProcessingInstructionNode] k n?.AddDataValue DeleteDataValue =b [ProcessingInstructionNode] k n?.DeleteDataValue CopyDataValue =b [ProcessingInstructionNode] k n?.CopyDataValue CutDataValue =b CopyDataValue ∧ DeleteDataValue PasteDataValue =b [ProcessingInstructionNode] k n?.PasteDataValue ReadTextValue =b [TextNode] k n?.ReadTextValue AddTextValue =b [TextNode] k n?.AddTextValue DeleteTextValue =b [TextNode] k n?.DeleteTextValue CopyTextValue =b [TextNode] k n?.CopyTextValue CutTextValue =b CopyTextValue ∧ DeleteTextValue PasteTextValue =b [TextNode] k n?.PasteTextValue ExpandXmlNode ∆(nodeToDoc) d?: documents node?: ↓XmlNode nodeToDoc0 = nodeToDoc ∪ {node? 7→ d?}
DropXmlNode ∆(nodeToDoc) d?: documents node?: ↓XmlNode nodeToDoc0 = nodeToDoc \{node? 7→ d?}
GetTypeOfNode =b ([ElementNode] ∨ [DocumentNode]) k n?.GetTypeOfNode GetNumberOfXmlNodes([ElementNode] ∨ [DocumentNode]) k n?.GetNumberOfXmlNodes 4.3. PROOFSOF CONCEPT 57
ReadXmlNode =b ([ElementNode] ∨ [DocumentNode]) k n?.ReadXmlNode k ExpandXmlNode AddComment =b ([ElementNode] ∨ [DocumentNode]) k n?.AddComment AddElement =b ([ElementNode] ∨ [DocumentNode]) k n?.AddElement AddProcessingInstruction =b ([ElementNode] ∨ [DocumentNode]) k n?.AddProcessingInstruction AddText =b [ElementNode] k n?.AddText DeleteXmlNode =b ([ElementNode] ∨ [DocumentNode]) k n?.DeleteXmlNode k DropXmlNode CopyXmlNode =b ([ElementNode] ∨ [DocumentNode]) k n?.CopyXmlNode CutXmlNode =b CopyXmlNode ∧ PasteXmlNode PasteXmlNode =b ([ElementNode] ∨ [DocumentNode]) k n?.PasteXmlNode ReadTagValue =b [ElementNode] k n?.ReadTagValue AddTagValue =b [ElementNode] k n?.AddTagValue DeleteTagValue =b [ElementNode] k n?.DeleteTagValue CopyTagValue =b [ElementNode] k n?.CopyTagValue CutTagValue =b CopyTagValue ∧ DeleteTagValue PasteTagValue =b [ElementNode] k n?.PasteTagValue GetDomainOfXmlAttributes =b [ElementNode] k n?.GetDomainOfXmlAttributes AddXmlAttribute =b [ElementNode] k n?.AddXmlAttribute DeleteXmlAttribute =b [ElementNode] k n?.DeleteXmlAttribute CopyXmlAttribute =b [ElementNode] k n?.CopyXmlAttribute CutXmlAttribute =b CopyXmlAttribute ∧ DeleteXmlAttribute PasteXmlAttribute =b [ElementNode] k n?.PasteXmlAttribute ReadXmlAttributeValue =b [ElementNode] k n?.ReadXmlAttributeValue AddXmlAttributeValue =b [ElementNode] k n?.AddXmlAttributeValue DeleteXmlAttributeValue =b [ElementNode] k n?.DeleteXmlAttributeValue CopyXmlAttributeValue =b [ElementNode] k n?.CopyXmlAttributeValue CutXmlAttributeValue =b CopyXmlAttributeValue ∧ DeleteXmlAttributeValue PasteXmlAttributeValue =b [ElementNode] k n?.PasteXmlAttributeValue
4.3.3 Example: File System
At the beginning of this chapter on page 31, we claimed that our document-content model encompasses containers other than documents. In this section, we support this claim by sketching a specialization to a generic file system. In other words, unlike the proof-of-concept specializations to reports and to XML documents, we provide this specialization for illustrative purposes only and therefore refrain from specializing the operations as well. Directories are nodes that have a name attribute (whose value is the name of the directory) as well as further attributes (e.g., the time of creation) and child nodes: Directory (Init,...) 58 4.3. PROOFSOF CONCEPT
Content nameName : Name Init nodes : seq(Directory ∪ File) nameName 7→ h i ∈ attributes ... nameName ∈ dom attributes ...
...
Files are leaves that have a name attribute (whose value is the name of the file), a value attribute (whose value is the content of the file), and further attributes (e.g., the content type):
File (Init,...) Content nameName, valueName : Name nameName 6= valueName Init nameName 7→ h i ∈ attributes nodes = h i valueName 7→ h i ∈ attributes nameName ∈ dom attributes ... valueName ∈ dom attributes ...
...
Finally, a file system is a container that has a root directory:
FileSystem (Init,...) Container Init root : Directory root.Init ......
...
All the operations we defined for document content make sense for file systems, even copy, cut, and paste (either to duplicate a directory or file within the same file 4.4. SEMI-STRUCTURED DATA 59 system or to check it out into another). For obvious reasons, the document-content model lacks an execute operation; however, if the file system represents a revision control system such as Subversion4 or CVS5, none is needed.
4.4 Semi-Structured Data
Especially in the context of XML, the term “semi-structured data” is often used. When XML is viewed as a notation for semi-structured data, it means that “we can use markup to impose structure on some parts of the data while leaving other parts as unstructured text.” [88, p. 34] However, Garcia-Molina et al. [50, p. 174] define semi-structured data as follows:
A database of semistructured data is a collection of nodes. Each node is either a leaf or interior. Leaf nodes have associated data; the type of this data can be any atomic type, such as numbers and strings. Interior nodes have one or more arcs out. Each arc has a label, which indicates how the node at the head of the arcs relates to the node at the tail. One interior node, called the root, has no arcs entering and represents the entire database. Every node must be reachable from the root, although the graph structure is not necessarily a tree.
With respect to the second definition, neither our document-content model nor XML documents are examples of semi-structured data. But semi-structured data can be encoded by way of attributes that denote a unique identifier within a tree (in the case of XML documents, ID is typically the type of identifier attributes) or that reference one or more identifiers (IDREF/IDREFS). All this said, we refrain from using the term “semi-structured data” for our document- content model in order to avoid confusion. Nevertheless, our document-content model indeed encompasses semi-structured data with respect to the first definition.
4http://subversion.tigris.org/ 5http://www.nongnu.org/cvs/ 60 4.4. SEMI-STRUCTURED DATA Chapter 5
Access-Control Model
In this chapter, we present an access-control model that is based on the document- content model from the last chapter and that allows for achieving document confidentiality and integrity. As explained in Section 1.3 on page 2, confidentiality is currently the only security goal that needs to be met. Nevertheless, by considering integrity as well, we are prepared in case collaborative document processors1 have a breakthrough in security-sensitive contexts and users thus access the same copy of a document. Note that Chapter 6 and Chapter 7 remain valid independent of whether the breakthrough materializes or not. While a secure file format may no longer be necessary (files reside on a trusted server, so there are no files to be exchanged in general), policies still need to be encoded and the client-side processes must still be trustworthy—but more on that later. We informally describe our access-control model from the top down in Section 5.1 and formally specify it from the bottom up in Section 5.2. In Section 5.3, we explain how easily a specialization of our document-content model can be access-controlled with neither changing the policy language nor the PDP. In Section 5.4, we outline how the realm of sticky policies could be extended to relational databases from where document content may originate.
5.1 Informal Description
In this chapter, we model documents as triples consisting of a content component, a title-deed component, and an access-policy component. This is depicted in Figure 5.1 (which is the same as Figure 3.5 on pages 27). The content component was specified in the last chapter. The other two components are specified in this chapter.
1e.g., SubEthaEdit (http://www.codingmonkeys.de/subethaedit/index.html)
61 62 5.1. INFORMAL DESCRIPTION
Content
Document Title Deed (triple)
Access Policy
Figure 5.1: Document Model
5.1.1 Title Deed
Whatever the access-policy syntax and semantics may be, the need for access policies in access-control models and systems is obvious. In settings where sensitive data is found in centralized containers such as a database, most users never have to act as policy makers (or rather as policy formalizers). The users who administer a centralized container also administer its access policy. In our setting where there may be many distributed containers (i.e., documents), any and all users potentially have to act as policy makers. (This is an important difference between document security and database security.) However, users must not be able to arbitrarily edit access policies; otherwise, untrustworthy users will simply give themselves any permissions they would like. This is where title deeds come in. A document’s title deed maps objects (i.e., the nodes and attributes of the document’s content) to users (cf. lower part of Figure 5.2). Each object is owned by exactly one user. When a user adds a new object to the content, the user becomes the owner of the object. In the spirit of the sticky-policies paradigm (cf. §2.1.7), when an object is copied (or cut) to the clipboard or pasted from the clipboard so is the respective owner. Object ownership can change in one way only: when attribute values are merged (i.e., one value is pasted into another) and the two values are owned by different users, a generic super user (think of root in a Unix-like file system) becomes the owner of the combined value. Users can arbitrarily change the access policy with respect to objects they own. That is, a title deed acts as the access policy of its document’s access policy.
5.1.2 Access Policy
Access to a document’s content is directly governed by the document’s access policy. The access-policy language defines what (semantics) and how (syntax) security requirements can be formalized, allowing a PDP to decide under which conditions a given subject can be granted access to an object. At the highest level, the access policy 5.1. INFORMAL DESCRIPTION 63
AccessPolicy
* Role * * Permission * * * * * *
1..* 1..* * User Object Action Time Provision *
TitleDeed
Figure 5.2: Policies Model relates roles to permissions (cf. upper part of Figure 5.2). Permissions are five-tuples: the first component is a non-empty set of users, the second component is an object reference, the third component is an action, the fourth component is a non-empty set of points in time, and the fifth component is a set of provisions. With the structure of an access policy out of the way, we can now turn to its meaning. Subjects request access to objects by trying to perform operations. When a subject requests access to an object, the request is granted when a permission matches the request. A permission matches a request if the following conditions hold:
1. The permission is related to the subject’s role or it is related to a role that the subject’s role is a descendant of.
2. The subject’s user is in the permission’s set of users.
3. The subject has requested access to the object referenced by the permission.
4. The kind of requested access corresponds to the permission’s action.
5. The time of request is in the permission’s set of points in time.
6. The subject’s user has made all provisions in the permission’s set of provisions.
The permission is related to the subject’s role or it is related to a role that the subject’s role is a descendant of.
Roles can be related to each other through inheritance; in particular, all roles are (directly or indirectly) related to a common base role. Recall that in Section 3.1, we noted that our access-control model is not hierarchical. However, we were not referring to a hierarchy of roles, but to a hierarchy of objects. Our PDP is aware of the former, but not of the latter. 64 5.1. INFORMAL DESCRIPTION
The subject’s user is in the permission’s set of users.
This serves two main purposes: First, when a user adds a new object to the content, the user can be given arbitrary access to the object without having to give access to any other user. Second, when subjects delegate some of their permissions to other subjects (delegation is possible but also access-controlled as we shall see shortly), they can limit the delegated permissions to a subset of users. For example, if a manager wants to delegate some of her permissions to her secretary (but not to all employees whose role is secretary) she can make the delegated permissions depend on the secretary’s user ID. Furthermore, when data is imported into a document from a source (container) whose access-control model is not role-based but discretionary (an example in the context of relational databases is given in Section 5.4), the imported permissions can be related to the common base role without having to give access to users outside of the original groups of authorized users. All that said, many permissions will simply match all users in a (sub)role as is typical in role-based access control.
The subject has requested access to the object referenced by the permission.
As just mentioned in Section 5.1.1, a document’s objects are its content nodes and attributes.
The kind of requested access corresponds to the permission’s action.
There are three actions: read, change, and delegate. A permission with a read action permits a read operation (i.e., ReadNode if the respective object is a node and ReadAttributeValue if the respective object is an attribute). What operations a permission with a change action permits is summarized in Ta- ble 5.1: With respect to an attribute, a change permission allows for adding to the attribute’s value (AddAttributeValue and PasteAttributeValue) and for deleting from the attribute’s value (DeleteAttributeValue); it does not allow for deleting the attribute or for adding an attribute. With respect to a node, a change permission allows for adding an attribute to the node (AddAttribute and PasteAttribute), for adding a child node (i.e., a subtree rooted at that node) to the node (AddNode and PasteNode), for deleting an attribute from the node (DeleteAttribute), and for deleting a child node (i.e., a subtree rooted at that node) from the node (DeleteNode). This is in contrast to other models (cf. §8), which typically have add, delete, and update actions (cf. Table 5.2). Such models not only lack symmetry, we also claim that giving add, delete, and update permissions individually is unsatisfactory, in particular in the context of document editing which requires the ability to undo operations. (This is another important difference between document security and database secu- 5.1. INFORMAL DESCRIPTION 65
Object attribute node Action change change the attribute value add an attribute to the node add a subtree to the node delete an attribute from the node delete a subtree from the node
Table 5.1: Operations permitted by Change Action rity.) Suppose, for example, that a subject has the permission to add an object to a node. Undoing adding an attribute or a node could be supported by giving the subject the permission to delete the attribute or the node. However, the permissions required to undo pasting an attribute or a node (i.e., a subtree) are less clear. Similarly, does deleting a node require the permission to delete all descendants of the node? And does deleting an object require the permission to read the object? Now suppose that a subject has the permission to delete an object but not the permission to add an object to the object’s parent node. Can deleting the object be undone without giving the subject “new” (add) permissions on “old” nodes? We avoid these questions with our approach and instead provide users with a simple semantics of an editing action whose consequences are easy to understand: to add or delete a child node or an attribute, a subject must be allowed to change the parent.
Object attribute node Action add not applicable add attribute to node add child node to node delete delete attribute delete subtree rooted at node update change attribute value not applicable
Table 5.2: Operations permitted by Add, Delete, and Update Actions (other models)
In addition to the content-related operations and to the operations depending on object ownership, there is also an operation corresponding to the delegate action. The operation allows subjects to delegate some or all of their permissions to other subjects. In other words, an access policy not only serves as the access policy of its document’s content, it also serves as its own access policy (in addition to the title deed). In its result, delegating a permission to a role does not differ from assigning a permission to a role. These two operations differ in when they are authorized: As seen in Section 5.1.1, a user is allowed to assign any permission to any role when she is the owner of the respective object. A permission with a delegate action permits a subject to delegate a 66 5.2. FORMAL SPECIFICATION permission to any role provided that the subject has a permission that is at least as permissive as the permission being delegated.
The time of request is in the permission’s set of points in time. / The subject’s user has made all provisions in the permission’s set of provisions.
The last two conditions stem from our requirements for access-control decisions depending on time and provisions having been made, respectively (cf. §1.3). Because of our support for provisions, we also need to consider what happens when more than one permission matches a request—or to avoid this from happen- ing in the first place—up to but excluding the sixth criterium. The are several reasons: First, which set of provisions is to be checked by the PDP if there are several sets? Sec- ond, about which set of provisions is the user to be told when no set of provisions has been fully made?2 And third, should the policy maker be made aware of overlapping permissions (with respect to the first four components) or not? Our solution is threefold: First, no two permissions that are related to the same role can overlap (with respect to the first four components). That is, the permissions have no users in common, they reference different objects, they have different actions, or they have no point in time in common. Second, two permission that are related to two different, but related roles can overlap (with respect to the first four conditions), but the set of provisions in the permission related to the subrole must be a subset of the set of provisions of the permission related to the superrole. After all, it would be strange to expect that a user in a role has made more provisions than the same user in a less powerful role. Third, the user must have made all the provisions in the intersection of the sets of provisions of all the permissions that match a request (up to but excluding the sixth criterium).
5.2 Formal Specification
In this section, we formally specify the abstract syntax of title deeds and access policies. To define their semantics, we formally specify the PDP as well as the time service and provisions service that the PDP relies on. Finally, we specify the PEP, which brings together the different parts from the last chapter and this chapter. As a specification aid, we extend the generic class type Node and add a value variable to its state, resulting in the generic class type ValueNode. This class reflects what
2We are aware of the possibility that the need may arise to formalize requirements that state that either one set of permissions has to be made or another. In that case, changing the last permission component’s syntax and semantics to include mandatory, optional, alternative, etc. provisions seems clearer to us, however. 5.2. FORMAL SPECIFICATION 67 title deeds and access policies have in common and we consequently extend it for both. ValueNode features an operation (ReadObjectValue) that expects an input of type Object: Object ::= Node | AttributehhNameii
ValueNode[V ] (equals) Node[V ] clipboard : Clipboard[V ] ∀ vn : ValueNode[V ] • vn.clipboard = clipboard
value : V ∀ vn : equals • value = vn.value
CopyNode =b ReadNode k clipboard.setNode PasteNode =b clipboard.getNode k AddNodeV CopyAttribute =b ReadAttribute k clipboard.setAttribute PasteAttribute =b clipboard.getAttribute k AddAttribute ReadNodeValue value!: V value! = value
ReadObjectValue =b ([object?: Object | object? = Node] ∧ ReadNodeValue) [] ([object?: Object; name!: Name | object? = Attribute(name!)] k ReadAttributeValue)
5.2.1 Subjects
The set of users and the set of roles are application-specific, which is why we specify them as a basic set. The generic super user that we postulate is not application-specific, however. [User, Role]
superUser : User
Roles can be related to each other through inheritance. In particular, all roles directly or indirectly inherit the base role anyRole. anyRole : Role inherits : Role ↔ Role ∀ r : Role • ¬ (anyRole inherits r) ∀ r : Role • ¬ (r inherits r) ∀ r : Role \{anyRole}• r inherits+ anyRole ∗ ∗ ∀ r1, r2 : Role • r1 inherits r2 ∧ r2 inherits r1 ⇒ r1 = r2 68 5.2. FORMAL SPECIFICATION
The set of subjects is specified as the Cartesian product of the set of users and the set of roles.
Subject == User × Role
5.2.2 Time and Time Service
We model time as discrete points:
Time ::= PointhhNii AnyTime == {t : N • Point(t)}
The dimension of points in time is application-specific. Technically, defining Point(0) to be the epoch (i.e., January 1st, 1970, 00:00:00 GMT) and each point in time corresponding to one millisecond is an obvious choice. The time service is specified in the class TimeService. Note that the only visible feature is the GetTime operation. This is to emphasize that no entity within our model can reset or advance the time.
TimeService (GetTime) Init time : Time time = Point(0)
GetTime Tick time!: Time ∆(time) time! = time time0 = Point(Point ∼ time + 1)
Whether the time service is a local service (i.e., runs on the same client as the PDP) or a remote service (i.e., runs on a server) depends on whether the local system clock is trusted or not.
5.2.3 Provisions and Provisions Service
We support two kinds of provisions: accept and sign.
[Agreement] Provision ::= AccepthhAgreementii | SignhhAgreementii
These two provisions are essential given our requirements, but others could be added simply by extending Provision. The provisions service is specified in the class ProvisionsService. Note that the only visible feature is the FilterOutMadeProvisions operation. Obviously, there must be a 5.2. FORMAL SPECIFICATION 69 means for users to make provisions and to have the provisions service update its state accordingly. However, overseeing this is a task for entities outside our model.
ProvisionsService (FilterOutMadeProvisions) Init made : User ↔ Provision made = {}
AddMadeProvision FilterOutMadeProvisions ∆(made) user?: User user?: User ps?: P Provision ps?: Provision ps!: P Provision made0 = made ∪ {(user?, ps?)} ps! = {p : ps? | (user?, p) 6∈ made}
The provisions service may be a local service. However, the evidence that a user has made a provision must be kept on secure (remote) servers. Otherwise, the user could destroy the evidence simply by physically destroying the local computer.
5.2.4 Title Deeds
We take advantage of the fact that document content is tree-based by specifying title deeds (and access policies) as trees as well. For all documents, each content node has a corresponding title-deed node (as well as a corresponding access policy node) and vice versa. The owner of a content node is given in the value of the corresponding titledeed node. The owner of a content attribute is given in the value of the corresponding title-deed attribute. Getting the node type, the number of nodes, or the domain of attributes and reading an attribute value neither change a document’s content nor the clipboard in any way. Therefore, those operations have no counterpart in TitleDeed. And while adding to an attribute value and deleting from an attribute value change a document’s content, the attribute concerned is still owned by the same user. Therefore, those two operations have no counterpart in TitleDeed, either. Adding a new content node results in the user adding the node becoming the owner of the (childless) node and of all the node’s attributes. Deleting/copying/pasting a content node results in the corresponding title-deed node being deleted/copied/pasted as well. Adding a new content attribute results in the user adding the attribute becoming the owner of the attribute. Deleting/copying/pasting a content attribute results in the corresponding title-deed attribute being deleted/copied/pasted as well. 70 5.2. FORMAL SPECIFICATION
TitleDeed (equals, Init, ReadNodeValue, ReadNode, AddNode, DeleteNode, CopyNode, PasteNode, AddAttribute, DeleteAttribute, CopyAttribute, PasteAttribute, CopyAttributeValue, PasteAttributeValue, ReadObjectValue) ValueNode[User][AddAttributeV /AddAttribute] mergeOwners :(User × User) → User
∀ o1, o2 : User • mergeOwners(o1, o2) = if o1 = o2 then o1 else superUser
nodes : seq TitleDeed C
AddNode =b [owner?: User; domainOfAttributes?: P Name; node!: TitleDeed | node!.Init ∧ node!.value = owner? ∧ dom node!.attributes = domainOfAttributes? ∧ ∀ a : node!.attributes • second(a) = owner?] k AddNodeV
AddAttribute =b [owner?: User; value!: User | value! = owner?] k AddAttributeV
CopyAttributeValue =b ReadAttributeValue k clipboard.setAttributeValue MergeAttributeOwners ∆(attributes) name?: Name value?: Value attributeValue?: Value attributes0 = attributes ⊕ {(name?, mergeOwners(value?, attributeValue?))}
PasteAttributeValue =b (ReadAttribute ∧ clipboard.getAttributeValue) k MergeAttributeOwners
Combining documents is straightforward when nodes and attributes are copied and pasted. However, when an attribute value is pasted into another, owners need to be combined. Since we do not want to grant any subject more access merely because two attribute values are merged, we combine owners as follows (cf. §5.1.1): When the two attribute values are owned by the same user, the user also owns the combined attribute (value). When the two attribute values are owned by different users, the generic super user owns the combined attribute (value). This is formalized in mergeOwners.
5.2.5 Access Policies
While title deeds map (implicit) objects to users, access policies map (implicit) objects to role-permission relations. This is why permissions have no object component in the formal specification.
Action ::= read | change | delegate
Permission == P1 User × Action × P1 Time × P Provision 5.2. FORMAL SPECIFICATION 71
For better readability, we specify four helper functions to select the respective permission components:
users : Permission → P1 User action : Permission → Action
times : Permission → P1 Time provisions : Permission → P Provision ∀ p : Permission • users(p) = p.1 ∀ p : Permission • action(p) = p.2 ∀ p : Permission • times(p) = p.3 ∀ p : Permission • provisions(p) = p.4
Not taking provisions into account, a role-permission relation for an implicit object tentatively grants a request for the same implicit object when a permission is related to the request subject’s role or the permission is related to a role that the request subject’s role is a descendant of, when the request subject’s user is in the permission’s set of users, when the request action is the same as the permission’s action, and when the request time is in the permission’s set of points in time:
tentativelyGrants :(Role ↔ Permission) ↔ (Subject × Action × Time) ∀ rps : Role ↔ Permission; s : Subject; a : Action; t : Time • rps tentativelyGrants (s, a, t) ⇔ (∃ r : Role; p : Permission | r 7→ p ∈ rps • first(s) inherits∗ r ∧ second(s) ∈ users(p) ∧ a = action(p) ∧ t ∈ times(p))
The provisions that must have been made are those in the intersection of all sets of provisions that otherwise match the request:
getProvisions :(Role ↔ Permission) × (Subject × Action × Time) 7→ P Provision ∀ rps : Role ↔ Permission; s : Subject; a : Action; t : Time | rps tentativelyGrants (s, a, t) • getProvisions(rps, (s, a, t)) = ∩{p : Permission | (∃ r : Role • r 7→ p ∈ rps ∧ first(s) inherits∗ r ∧ second(s) ∈ users(p) ∧ a = action(p) ∧ t ∈ times(p)) • provisions(p)}
Just like owners need to be merged for title deeds when an attribute value is pasted into another, role-permission relations need to be merged for access policies. The strat- egy is straightforward. If an access request would be tentatively granted for both attribute values, it must also be granted for the combined attribute value and vice versa. If a provision would have to have been made for either attribute value, it must also have been made for the combined attribute value: 72 5.2. FORMAL SPECIFICATION
mergeRolePermissions : ((Role ↔ Permission) × (Role ↔ Permission)) → (Role ↔ Permission)
∀ rps1, rps2 : Role ↔ Permission; req : Subject × Action × Time • rps1 tentativelyGrants req ∧ rps2 tentativelyGrants req ⇔ mergeRolePermissions(rps1, rps2) tentativelyGrants req ∀ rps1, rps2 : Role ↔ Permission; req : Subject × Action × Time • mergeRolePermissions(rps1, rps2) tentativelyGrants req ⇒ getProvisions(rps1, req) ∪ getProvisions(rps2, req) = getProvisions(mergeRolePermissions(rps1, rps2), req)
Getting the number of nodes, the node type, or the domain of attributes and reading an attribute value neither change a document’s content nor the clipboard in any way. Therefore, those operations have no counterpart in AccessPolicy. And while adding an attribute value and deleting an attribute value change a document’s content, the user who makes the changes does not gain any further permissions. Therefore, those two operations have no counterpart in AccessPolicy, either. Adding a new content node results in the user adding the node having all permissions on the (childless) node and on all the node’s attributes. Deleting/copying/pasting a content node results in the corresponding access-policy node being deleted/copied/pasted as well. Adding a new content attribute results in the user adding the attribute having all permissions on the attribute. Deleting/copying/pasting a content attribute results in the corresponding access-policy attribute being deleted/copied/pasted as well.
AccessPolicy (equals, Init, ReadNodeValue, ReadNode, AddNode, DeleteNode, CopyNode, PasteNode, AddAttribute, DeleteAttribute, CopyAttribute, PasteAttribute, CopyAttributeValue, PasteAttributeValue, ReadObjectValue, AssignPermissionToRole, RevokePermissionFromRole, DelegatePermissionToRole) ValueNode[Role ↔ Permission][AddAttributeV /AddAttribute]
nodes : seq AccessPolicy C ∗ ∀ r1, r2 : Role; p1, p2 : Permission | r1 inherits r2 ∧ p1 6= p2 ∧ r1 7→ p1 ∈ value ∧ r2 7→ p2 ∈ value • users(p1) ∩ users(p2) = ∅ ∨ action(p1) 6= action(p2) ∨ times(p1) ∩ times(p2) = ∅ ∨ r1 6= r2 ∧ permissions(p1) ⊆ permissions(p2)
ownerDefaultPermissions : User → (Role ↔ Permission) ∀ owner : User • ownerDefaultPermissions(u) = {a : Action • anyRole 7→ ({u}, a, AnyTime, {})} 5.2. FORMAL SPECIFICATION 73
AddNode =b [owner?: User; domainOfAttributes?: P Name; node!: AccessPolicy | node!.Init ∧ node!.value = ownerDefaultPermissions(owner?) ∧ dom node!.attributes = domainOfAttributes? ∧ ∀ a : node!.attributes • second(a) = ownerDefaultPermissions(owner?)] k AddNodeV
AddAttribute =b [owner?: User; value!: Role ↔ Permission | value! = ownerDefaultPermissions(owner?)] k AddAttributeV
CopyAttributeValue =b ReadAttributeValue k clipboard.setAttributeValue MergeAttributeRolePermissions ∆(attributes) name?: Name value?: Value attributeValue?: Value attributes0 = attributes ⊕ {(name?, mergeRolePermissions(value?, attributeValue?))}
PasteAttributeValue =b (ReadAttribute ∧ clipboard.getAttributeValue) k MergeAttributeRolePermissions AssignPermissionToRole role?: Role permission?: Permission value0 = value ∪ {role? 7→ permission?}
RevokePermissionFromRole role?: Role permission?: Permission value0 = value \{role? 7→ permission?}
DelegatePermissionToRole =b AssignPermissionToRole
Furthermore, AccessPolicy features three access policy-specific operations: assigning a permission to a role, revoking a permission from a role, and delegating a permission to (another) role. All three result in changes to the access policy. However, as far as changing the access policy goes, delegating a permission to a role is equivalent to adding a new role-permission mapping. As we shall see below, these two operations differ in when they are granted.
5.2.6 Policy Decision Point
PDPs are specified in class PolicyDecisionPoint. PolicyDecisionPoint features five visible operations. ReadRequest, ChangeRequest, and DelegateRequest expect a role-permission relation as well as a subject as input. DelegateRequest additionally requires the permission to be delegated as input to ensure that the subject who wants to delegate the permission has a permission that is at least as permissible as the permission to be del- 74 5.2. FORMAL SPECIFICATION egated. AssignPermissionToRoleRequest and RevokePermissionFromRoleRequest expect a user and a subject as input. Note that no return value is specified. In an implementation, a PDP has to return a value (or throw an exception) that states whether a request was granted or denied. In Object-Z, the operation access to which is controlled simply does not occur because not all preconditions have been met.
PolicyDecisionPoint (ReadRequest, ChangeRequest, DelegateRequest, AssignPermissionToRoleRequest, RevokePermissionFromRoleRequest) timeService : TimeService provisionsService : ProvisionsService
PolicyDecisionPoint is stateless.
CheckProvisions ps?: P Provisions ps? = ∅
CheckSubjectActionTime value?: Role ↔ Permission subject?: Subject action?: Action time?: Time ps!: P Provision value? tentativelyGrants (subject?, read, time?) ps! = getProvisions(value?, (subject?, read, time?))
AccessRequest =b ((timeService.GetTime k CheckSubjectActionTime) k provisionsService.FilerOutMadeProvisions) k CheckProvisions ReadRequest =b [action!: Action | action! = read] k AccessRequest ChangeRequest =b [action!: Action | action! = change] k AccessRequest CheckPermission value?: Role ↔ Permission subject?: Subject permission?: Permission ∃ r : Role; p : Permission • r 7→ p ∈ value? ∧ first(subject?) inherits∗ r ∧ users(permission?) ⊆ users(p) ∧ action(permission?) = action(p) ∧ times(permission?) ⊆ times(p) ∧ provisions(permission?) ⊇ provisions(p)
DelegateRequest =b ([action!: Action | action! = delegate] k (AccessRequest∧ CheckPermission) 5.2. FORMAL SPECIFICATION 75
CheckOwnership value?: User subject?: Subject value = first(subject?)
AssignPermissionToRoleRequest =b CheckOwnership RevokePermissionFromRoleRequest =b CheckOwnership
5.2.7 Policed Document
PolicedDocument is a wrapper class around a document’s root nodes. An empty document (i.e., a document in its initial state) has root nodes with no child nodes (as specified in Content’s, TitleDeed’s, and AccessPolicy’s Init predicate) and with no attributes.
PolicedDocument (content, titleDeed, accessPolicy, Init) Document Init
titleDeed : TitleDeed C titleDeed.Init
accessPolicy : AccessPolicy C titleDeed.attributes = ∅ accessPolicy.Init accessPolicy.attributes = ∅
5.2.8 Policy Enforcing Document Processor
A document processor that acts as a PEP is specified in class PolicyEnforcingDocument- Processor. (At first sight, the specification may be intimidating, but this is just because it is quite verbose.) First we point out the reference to a PDP. As explained before, the PDP is consulted when nodes are read/expanded, when attribute values are read, when nodes are added/pasted or deleted, when attributes are added/pasted or deleted, and when attribute values are edited. Because subjects should not have to request access for every character they add to or delete from an attribute value, the document processor maintains which attributes have been granted change access to in nodesToEditables. And for Content operations that have counterparts in TitleDeed and AccessPolicy, the respective PolicyEnforcingDocumentProcessor operations are not only promotions of the Content operations but transactions operating simultaneously on all three document components. 76 5.2. FORMAL SPECIFICATION
PolicyEnforcingDocumentProcessor (Init, NewDocument, OpenDocument, CloseDocument, ReadRoot, GetNumberOfNodes, GetNodeType, GetDomainOfAttributes, ReadNode, AddNode, DeleteNode, CopyNode, CutNode, PasteNode, AddAttribute, DeleteAttribute, CopyAttribute, CutAttribute, PasteAttribute, ReadAttributeValue, AddAttributeValue, DeleteAttributeValue, CopyAttributeValue, CutAttributeValue, PasteAttributeValue, AssignPermissionToRole, RevokePermissionFromRole, DelegatePermissionToRole) pdp : PolicyDecisionPoint
subject : P Subject
documents : P PolicedDocument C nodesToDoc :(Content × TitleDeed × AccessPolicy) 7→ PolicedDocument nodesToEditables :(Content × TitleDeed × AccessPolicy) 7→ P Name #subject ≤ 1 ran nodesToDoc ⊆ documents dom nodesToEditables = dom nodesToDoc
Init subject = ∅ documents = ∅ nodesToDoc = ∅ nodesToEditables = ∅
LogIn LogOut ∆(subject) ∆(subject, documents, nodesToDoc, subject?: Subject nodesToEditables)
subject = ∅ subject 6= ∅ 0 0 subject = {subject?} subject = ∅ 0 documents = ∅ 0 nodesToDoc = ∅ 0 nodesToEditables = ∅
OpenDocument ∆(documents) d?: PolicedDocument
subject 6= ∅ d? 6∈ documents documents0 = documents ∪ {d?}
NewDocument =b [d!: PolicedDocument | d!.Init] k OpenDocument 5.2. FORMAL SPECIFICATION 77
CloseDocument ∆(documents, nodesToDoc, nodesToEditables) d?: PolicedDocument d? ∈ documents documents0 = documents \{d?} nodesToDoc0 = documents0 £ nodesToDoc 0 0 nodesToEditables = dom nodesToDoc C nodesToEditables
ExpandDocNodes ∆(nodesToDoc, nodesToEditables) d?: documents content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy nodesToDoc0 = nodesToDoc ∪ {(content?, titleDeed?, accessPolicy?) 7→ d?} nodesToEditables0 = nodesToEditables∪ {(content?, titleDeed?, accessPolicy?) 7→ ∅}
ReadRoot =b [d?, d!: documents; content!: Content; titleDeed!: TitleDeed; accessPolicy!: AccessPolicy | d! = d? ∧ content! = d?.content ∧ titleDeed! = d?.titleDeed ∧ accessPolicy! = d?.accessPolicy] k (((accessPolicy.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ReadRequest) ∧ ExpandDocNodes) DocNodes d?: documents content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy d? = nodesToDoc((content?, titleDeed?, accessPolicy?))
GetNumberOfNodes =b [DocNodes] • content?.GetNumberOfNodes GetNodeType =b [DocNodes] • content?.GetNodeType GetDomainOfAttributes =b [DocNodes] • content?.GetDomainOfAttributes ReadNode =b [DocNodes] • ((((accessPolicy?.ReadNode k ([node?: AccessPolicy] • node?.ReadNodeValue)) ∧ [subject!: Subject | subject! = subject]) k pdp.ReadRequest) ∧ content?.ReadNode[content!/node!]∧ titleDeed?.ReadNode[titleDeed!/node!]∧ accessPolicy?.ReadNode[accessPolicy!/node!]) k ExpandDocNodes
AddNode =b [DocNodes] • ((accessPolicy?.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest) ∧ content?.AddNode∧ titleDeed?.AddNode ∧ accessPolicy?.AddNode 78 5.2. FORMAL SPECIFICATION
DropDocNodes ∆(nodesToDoc, nodesToEditables) d?: documents content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy nodesToDoc0 = nodesToDoc \{(content?, titleDeed?, accessPolicy?) 7→ d?} 0 0 nodesToEditables = dom nodesToDoc C nodesToEditables
DeleteNode =b [DocNodes] • (((accessPolicy?.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest)∧ content?.DeleteNode[content!/node!] ∧ titleDeed?.DeleteNode[titleDeed!/node!]∧ accessPolicy?.DeleteNode[accessPolicy!/node!]) k DropDocNodes
CopyNode =b [DocNodes] • content?.CopyNode ∧ titleDeed?.CopyNode∧ accessPolicy?.CopyNode
CutNode =b CopyNode ∧ DeleteNode PasteNode =b [DocNodes] • ((accessPolicy?.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest) ∧ content?.PasteNode∧ titleDeed?.PasteNode ∧ accessPolicy?.PasteNode
AddAttribute =b [DocNodes] • ((accessPolicy.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest) ∧ content.AddAttribute∧ titleDeed.AddAttribute ∧ accessPolicy.AddAttribute UpdateEditable ∆(nodesToEditables) content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy name?: Name nodesToEditables0 = nodesToEditables ⊕ ((content?, titleDeed?, accessPolicy?) 7→ nodesToEditables((content?, titleDeed?, accessPolicy?)) \{name?})
DeleteAttribute =b [DocNodes] • ((accessPolicy?.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest) ∧ UpdateEditable∧ content?.DeleteAttribute ∧ titleDeed?.DeleteAttribute∧ accessPolicy?.DeleteAttribute
CopyAttribute =b [DocNodes] • content?.CopyAttribute∧ titleDeed?.CopyAttribute ∧ accessPolicy?.CopyAttribute
CutAttribute =b CopyAttribute ∧ DeleteAttribute PasteAttribute =b [DocNodes] • ((accessPolicy?.ReadNodeValue ∧ [subject!: Subject| subject! = subject]) k pdp.ChangeRequest) ∧ content?.PasteAttribute∧ titleDeed?.PasteAttribute ∧ accessPolicy?.PasteAttribute 5.2. FORMAL SPECIFICATION 79
ReadAttributeValue =b [DocNodes] • ((accessPolicy?.ReadAttributeValue∧ [subject!: Subject | subject! = subject]) k pdp.ReadRequest)∧ content?.ReadAttributeValue MakeAttributeEditable ∆(nodesToEditables) content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy name?: Name name? 6∈ nodesToEditables((content?, titleDeed?, accessPolicy?)) nodesToEditables0 = nodesToEditables ⊕ ((content?, titleDeed?, accessPolicy?) 7→ nodesToEditables((content?, titleDeed?, accessPolicy?)) ∪ {name?})
AttributeIsEditable content?: Content titleDeed?: TitleDeed accessPolicy?: AccessPolicy name?: Name name? ∈ nodesToEditables((content?, titleDeed?, accessPolicy?))
ChangeAttributeValue =b [DocNodes] • (((accessPolicy?.ReadAttributeValue∧ [subject!: Subject | subject! = subject]) k pdp.ChangeRequest)∧ MakeAttributeEditable) [] AttributeIsEditable
AddAttributeValue =b ChangeAttributeValue ∧ ([DocNodes] • content.AddAttributeValue)
DeleteAttributeValue =b ChangeAttributeValue ∧ ([DocNodes] • content.DeleteAttributeValue)
CopyAttributeValue =b content?.CopyAttributeValue∧ titleDeed?.CopyAttributeValue ∧ accessPolicy?.CopyAttributeValue
CutAttributeValue =b CopyAttributeValue ∧ DeleteAttributeValue PasteAttributeValue =b ChangeAttributeValue ∧ ([DocNodes] • content?.PasteAttributeValue ∧ titleDeed?.PasteAttributeValue∧ accessPolicy?.PasteAttributeValue)
DelegatePermissionToRole =b [DocNodes] • ((accessPolicy?.ReadObjectValue∧ [subject!: Subject | subject! = subject]) k pdp.DelegateRequest)∧ accessPolicy?.DelegatePermissionToRole
AssignPermissionToRole =b [DocNodes] • ((titleDeed?.ReadObjectValue∧ [subject!: Subject | subject! = subject]) k pdp.AssignPermissionToRoleRequest)∧ accessPolicy?.AssignPermissionToRole 80 5.3. PROOFOF CONCEPT:REPORTS
RevokePermissionFromRole =b [DocNodes] • ((titleDeed?.ReadObjectValue∧ [subject!: Subject | subject! = subject]) k pdp.RevokePermissionFromRoleRequest)∧ accessPolicy?.RevokePermissionFromRole
5.3 Proof of Concept: Reports
In the last chapter, we have seen that the report-content model and the XML-document model are specializations of the document-content model. In this chapter, we have added two more components to documents. Adding the same two components to reports is trivial:
PolicedReportDocument (content, titleDeed, accessPolicy, Init) ReportDocument Init
titleDeed : TitleDeed C titleDeed.Init
accessPolicy : AccessPolicy C accessPolicy.Init
The interesting and important result is that given a concrete syntax for, as well as a runtime representation of, title deeds and access policies and given a PDP, we can reuse them without modification when controlling access to documents whose content model is a specialization of our document-content model. That is, specifying a report processor that acts as a PEP may be tedious, but straightforward. For every report- related operation, one determines the content-related operation the report-related operation is mapped to by consulting the Content subclasses, one then determines what has been added to the respective PolicyEnforcingDocumentProcessor operation compared with the respective DocumentProcessor operations, and one then makes the same additions to the respective ReportProcessor operation. However, instead of boring the reader with yet another five pages of Object-Z, we refer to our prototypical implementation (cf. Appendix C) that shows the result of this process in Java.
5.4 From Databases to Documents
Before a user can read-access a secured database (with customer data for instance), she has to authenticate herself and be authorized for the read-access. However, once read- access to the database is granted, any and all data readable by her can simply be copied 5.4. FROM DATABASES TO DOCUMENTS 81 from the database and pasted into a document without the access policy being copied (not to mention later enforced) as well. Given that both the source container (database) and the target container (document) are access controlled in our context, the question naturally arises whether the target access policy can be a function of the source access policy. The answer depends on the source and target access-control models; for textbook SQL security [50, 53] and our document security, the answer is yes. In SQL security, an access policy is a set of grants. Grants formalize which privileges a set of users has on a database element. Database elements are relations (i.e., tables or views). Users are identified by their authorization ID. The special authorization ID PUBLIC includes any user. (In our formalization, we do not model PUBLIC as an authorization ID with a special semantics but simply as the set of all authorization IDs.) A privilege is a kind of access and thus corresponds to an action and not to a permission in the access-control terminology established in Section 2.1. Privileges can be parameterized with a set of columns3 in order to limit grants to part of a database element. (In our formalization, we do not model parameterless privileges; instead, some privileges may be parameterized with the set of all columns, the respective grants thereby effectively spanning the whole database element.) Of all the privileges, only the SELECT privilege is of interest to us here. Finally, grants can include the option to be granted to other users. Formally, we can summarize the above as follows:
[AuthorizationID, Column, DatabaseElement] Public == AuthorizationID
Privilege ::= SelecthhP1 Columnii GrantOption ::= with | without
Grant == P1 Privilege × DatabaseElement × P1 AuthorizationID × GrantOption Policy == P Grant
Now, when a piece of data is copied from a database field and pasted to a document- content attribute, the generic super user can be made the owner of the attribute and each grant whose set of objects covers the field can be mapped to two (grant option not included) or three (grant option included) permissions
• that are related to the common base role,
• whose sets of users are basically the grant’s set of authorization IDs,
• whose objects are the attribute,
3We refer to database attributes as columns in order to avoid confusion with document-content attributes. 82 5.4. FROM DATABASES TO DOCUMENTS
• whose actions are read and change (as well as delegate if the grant includes the grant option), respectively,
• whose sets of points in time include all points in time, and
• whose sets of provisions are empty.
Mapping access policies from databases whose database management systems are based on access-control models that are more complex than that of textbook SQL to documents may be more involved. However, the mere fact that we are able to outline a mapping in about one page shows that such mappings are feasible and worth pursuing in future work. It also shows that our access-control model is quite powerful. Chapter 6
Key Distribution & Storage
As we have briefly seen in Chapter 2 and as we shall see in detail in the next chapter, we have to address the problem of protecting cryptographic keys—or more generally secret pieces of data—from subjects such that certain processes that the subjects can launch nonetheless have access to the cryptographic keys. In our context, the processes that need access to the cryptographic keys are trusted document processors, and the cryptographic keys are a decryption key (which may be the same as the corresponding encryption key) and a signing key. Two problem cases can be considered:
1. The owner of the cryptographic keys (in our context a bank) is also the owner of and administrates the computer on which the cryptographic keys are stored. Subjects have no administrative rights.
2. The subject is the owner of and administrates the computer on which the cryptographic keys are stored. For example, members of the enterprise’s board of directors may be more inclined to read documents on a computer they already have, such as their home computer, than to be issued a computer from every enterprise on whose board of directors they sit.1
Case 1 is fairly easy to solve with security mechanisms provided by the operating system. Nowadays, we do not even have to recur to setuid or similar mechanisms (e.g., [57]). State-of-the-art operating systems provide security mechanisms without setuid’s pitfalls (e.g., Mac OS X’s Keychain). We do not consider case 1 any further.
1Recall the case of former CIA Director John Deutch who accessed classified material on his unsecured home computer. The problem was not that he was not trusted (as the CIA director, he certainly was), but his software might have been untrustworthy. Had the classified material been encrypted with a key known not even to him, he could have been forced to boot his home computer into a trusted state, and the story would never have made the news.
83 84 6.1. REQUIREMENTS
Case 2 is much more difficult to solve. Software-based techniques such as code obfuscation [30, 129] and white-box cryptography [29, 28] may alleviate the problem, but unfortunately, “[s]oftware cannot protect itself.” [65, p. 172]. Hardware-based mechanisms, however, can level the playing field. Security hardware takes many forms and serves many purposes [3, 117]. To solve case 2, we present a protocol based on Trusted Platform Modules (TPMs, cf. §2.4) that can be applied in situations where access to secrets of an enterprise must be controlled on computers that are not owned and administrated by the enterprise.2
In the remainder of this chapter, we therefore understand “trusted computing” to mean trusted computing as specified by the TCG and focus on personal computers without limiting the protocol’s generality. In Section 6.1, we abstractly describe the problem that we solve with our protocol. We define the protocol and analyze its security in Sections 6.2 and 6.3, respectively.
6.1 Requirements
Consider the setting depicted in Figure 6.1: A server has secret data ds that it is willing to share with certain clients over an open channel (i.e., one that is not encrypted in any way) upon request, but not with the clients’ users. The owner of the secret ds does not trust the users because they may not understand or respect the owner’s security requirements or because they may have an untrustworthy platform, such as one com- promised by a Trojan horse. In any case, the server is willing to share the secret ds with clients who are known to meet the owner’s security requirements. Because the main security goal of our protocol is confidentiality of the secret ds , this entails that the client uses the secret ds without disclosing it to the user or to any other entity. Furthermore, the client must either hinder the user from launching another process or at least force a change in the PCRs. Otherwise, the other (potentially malicious) process could simply request the TPM to disclose the secret ds . It is in the server’s interest to ensure that this security goal is met. Thus, the protocol needs to be resilient against man-in-the-middle attacks, and given an ideal (tamper-proof) trusted platform against dishonest users as well (cf. Figure 6.2).
2In our specification, we treat a TPM as a trusted third party that can serve as an oracle with respect to making platform measurements; this not only results in a clear specification, but this analogy for ideal roots of trust could also serve as the basis for a formal model of trusted computing in the future (cf. §9). 6.2. PROTOCOL 85
client G user G open
server S owner S
open user B client B
Figure 6.1: Setting
dishonest user open man in the middle open
Figure 6.2: Attackers
6.2 Protocol
In this section, we present a protocol that ensures that the server only distributes given secret data ds to trusted clients (i.e., clients that meet the data owner’s security requirements as explained in the last section). The protocol involves three parties: the server, a client, and the client’s TPM. Considering the TPM to be a participant in its own right may come as a surprise, but the following model should clarify this point. Ideal roots of trust can be modeled as trusted third parties (cf. Figure 6.3) with certain oracle properties related to measurement. That is, for each client there is a third party whom both the server and the client trust. Furthermore, the channel between the client and the trusted third party is secure (i.e., confidential and authentic). Not even the user can intercept or insert messages on this channel. There is no (direct) channel between the server and the trusted third party, though. Nevertheless, the server can encrypt data with the trusted third party’s public encryption key along with information about a platform configuration. The trusted third party has the ability to determine the platform configuration of the client and decrypts data for the client only if the client’s platform configuration is the one given when the data was encrypted. In this model, our protocol basically proceeds as follows:
1. The client requests the secret ds from the server.
2. The server encrypts ds with the trusted third party’s public key along with information about the platform configuration it trusts and sends the encrypted data to the client. 86 6.2. PROTOCOL
TTP G user G
authentic confidential open client G client B authentic open confidential
TTP B user B
Figure 6.3: Trusted Third Parties (TTPs) as a Model for Ideal Roots of Trust
3. The client sends the encrypted data to the trusted third party and requests the trusted third party to decrypt the data for it.
4. The trusted third party determines the client’s current platform configuration and reveals the decrypted data to the client only if the client’s platform configuration is the one given when the data was encrypted.
Note that the first two steps only have to be taken once whereas the last two steps may be taken repeatedly. The real protocol is more complex. In particular, it involves the generation of a platform configuration-dependent binding key and the use of an AIK. Even though privacy is not an issue for the application we have in mind, employing an AIK has the pleasant side effect of extending our protocol’s usefulness to settings where privacy matters. For example, the secret data ds could be the license key for a media player that manages digital rights. By using different AIKs when requesting license keys, the requests cannot be linked to the same client.
6.2.1 TPM Commands
We briefly introduce the TPM commands required in our protocol. For the sake of simplicity, we omit input values such as command-authorization data and key parameters as well as output values such as error codes. For a comprehensive description of the commands, the reader is referred to the TPM main specification [127] and to Pearson et al. [98].
TPM CreateWrapKey generates an asymmetric key and returns the public key in plain text and the private key encrypted with the key pair’s parent key. The input values of interest to us are a key handle that points to the generated key’s parent key, the flag which declares the key as a binding or signing key, the flag which declares the key as migratable or non-migratable, and the (potentially empty) set of PCRs 6.2. PROTOCOL 87
to whose values the key is sealed. Note that for the key to be non-migratable, the parent key must be non-migratable as well.
In our protocol, we use this command on the client to generate a non-migratable binding key that is sealed to a (non-empty) set of PCRs.
TPM LoadKey2 loads an asymmetric key onto the TPM and returns the key handle which points to the loaded key, thus making the key available for use in subse- quent TPM commands. The input values of interest to us are the public key, the encrypted private key, and a key handle that points to the loaded key’s parent key. A non-migratable key will only be loaded onto the TPM if it was generated by the TPM.
In our protocol, we use this command on the client to load the binding key generated with TPM CreateWrapKey onto the client TPM.
TPM CertifyKey returns a key certificate. The input values of interest to us are a key handle that points to the key to certify and a key handle that points to the certifying signing key.
In our protocol, we use this command on the client to certify with an AIK that the binding key generated with TPM CreateWrapKey and loaded with TPM - LoadKey2 is a non-migratable binding key that is sealed to a set of PCRs.
TSS Bind encrypts data and returns it in cipher text. The input values of interest to us are the data to encrypt and the public key used for encryption. Note that it is the responsibility of the caller to ensure that the encryption key is a non-migratable binding key. Note further that the TSS Bind command is not a TPM command, but fully implemented in software.
In our protocol, we use this command on the server to encrypt a secret with the public key of the binding key generated with TPM CreateWrapKey and certified with TPM CertifyKey.
TPM UnBind decrypts data and returns it in plain text. The input values of interest to us are the data to decrypt and a key handle that points to the binding key (whose private key is used for decryption). A sealed binding key will only be used by the TPM if the values in the PCRs match those specified during sealing.
In our protocol, we use this command on the client to decrypt the secret encrypted with TSS Bind with the private key of the binding key generated with TPM CreateWrapKey and loaded with TPM LoadKey2. 88 6.2. PROTOCOL
6.2.2 Notation
We employ so-called “Alice & Bob” notation, which leaves implicit many of the checks carried out by principals when executing the protocol and the associated control flow when these checks fail, e.g., aborting when the verification of a digital signature fails [25]. Nevertheless, we have annotated our protocol specification, making explicit the checks of TPM-specific key properties and platform configuration information, using an assert statement. The semantics of assert is standard: it aborts the protocol execution when the asserted predicate does not hold. Furthermore, we employ the following notation:
• REQ is a constant, requesting the secret data ds .
• PCR INFO is a set of PCR indices and their respective values.
−1 •KX is a key pair with public key KX and private key KX .
• HX is the handle to the key KX .
• aik, binding, and non-migratable are flags that denote properties of a key, namely that the key is an AIK, a binding key, and non-migratable, respectively.
−1 −1 • EncP (binding, non-migratable, PCR INFO, KC ) is the private key KC of the non-
migratable binding key KC sealed to PCR INFO, encrypted with the (non-migratable)
parent key KP .
• SigAIK (binding, non-migratable, PCR INFO, N , KC ) is the certificate of the public
key KC of the non-migratable binding key KC sealed to PCR INFO, signed with −1 the private key KAIK of the signing key KAIK .
• SigCA(aik, KAIK ) is the certificate of the public key KAIK of the attestation identity −1 key KAIK , signed with the private key KCA of the signing key KCA
6.2.3 Initial Possessions of Parties
The server knows
• the secret data ds ,
• the public key KCA of the certificate authority’s signing key, and
• the PCRs and their values for the trusted stack.
The client knows
• the handle HP to (and authorization data for) a non-migratable storage key KP , 6.2. PROTOCOL 89
Table 6.1: Key Distribution Protocol 1 C −→ S REQ 2 C ←− S PCR INFO, N
3 TPM ←− C TPM CreateWrapKey(HP , binding, non-migratable, PCR INFO)
4 TPM assert KP is non-migratable −1 generate non-migratable binding key (KC , KC ) −1 5 TPM −→ C KC , EncP (binding, non-migratable, PCR INFO, KC )
6 TPM ←− C TPM LoadKey2(KC , EncP (binding, non-migratable, −1 PCR INFO, KC ), HP )
7 TPM −→ C HC
8 TPM ←− C TPM CertifyKey(HC , HAIK , N )
9 TPM −→ C SigAIK (binding, non-migratable, PCR INFO, N , KC )
10 C −→ S SigAIK (binding, non-migratable, PCR INFO, N , KC ),
SigCA(aik, KAIK )
11 S assert KAIK is aik
assert KC is binding
assert KC is sealed to PCR INFO
12 C ←− S EncC (ds )
13 TPM ←− C TPM UnBind(EncC (ds ), HC ) 14 TPM assert C is in state PCR INFO
15 TPM −→ C ds
• the handle HAI to (and authorization data for) an AIK, and
• the certificate SigCA(aik, KAIK ) for verification of the AIK by a third party, in our case the server.
In a protocol run, the AIK allows the client to prove to the server that the latter is indirectly interacting with a TPM. The TPM knows (i.e., has loaded)
−1 • the private key KP of the non-migratable storage key KP and
−1 • the private key KAI of the AIK.
6.2.4 Protocol Run
The protocol is specified in Table 6.1. The client initiates a protocol run by requesting the secret data ds from the server (1). The server replies with the set of PCRs that 90 6.3. SECURITY ANALYSIS have to be used to represent the (trusted) state of the client and a nonce N which iden- tifies the protocol run (2). Note that the nonce does not provide additional security since replay attacks are not an issue.3 The client invokes the TPM CreateWrapKey command (3) to have the TPM create a non-migratable asymmetric encryption key −1 KC := (KC , KC ) (4) that is sealed to the PCRs specified in step 2 (5). The client loads the key into the TPM by invoking TPM LoadKey2 (6), receives the key handle from the TPM (7), and has the TPM certify the loaded key with the AIK (8). The TPM returns the certificate (9), which the client forwards to the server together with the certificate of the
AIK (10). The server checks that the certificates are valid (11), in particular that KC is a non-migratable binding key sealed to the required PCRs. If the key KC has the required properties, the secret ds is bound to it and the resulting protected object returned to the client (12). Upon receipt of the protected object, the client invokes TPM UnBind to have the TPM decrypt the secret ds (13). The TPM checks that the client is in the trusted state
(14) before using KC and returning the secret ds (14). Note that there is no need for (and no additional security in) explicitly sealing the −1 secret ds since the private key KC of the binding key KC is sealed to the required PCRs itself. From now on, whenever the client is in the trusted state (i.e., the PCR values match the required ones) it can have the TPM unbind the secret ds for its intended use.
6.3 Security Analysis
6.3.1 Security against Man-in-the-Middle Attacks
Since the communication channel between the client and the server is open, a man in the middle sees the following four messages exchanged in steps 1, 2, 10, and 12:
1. REQ,
2. PCR INFO, N ,
3. SigAIK (binding, non-migratable, PCR INFO, N , KC ),
SigCA(aik, KAIK ), and
4. EncC (ds )
Obviously, the first three messages are independent of the secret data ds , and hence they provide no information about it (even in a strict information-theoretic sense). The fourth message is encrypted with the public key KC , where the corresponding private
3The reason is that it is not important when the binding key has been generated and certified, but what its properties are. Because the binding key is non-migratable, these properties (in particular, which TPM it is associated with) never change. 6.3. SECURITY ANALYSIS 91
−1 key KC is unknown to the man in the middle. Hence, the man in the middle can only decrypt the fourth message by breaking the cryptographic system, which we assume −1 to be infeasible, or by deriving the private key KC from the first three messages. How- ever, the first two messages are also completely independent of the encryption key KC and deriving a private key from the corresponding public key in the third message amounts to breaking the cryptographic system. Thus, the protocol is secure against a passive man-in-the-middle attack. An active man in the middle could try to replace the third message he sees by
SigMS [enc, nm, PCR INFO, N ](KME ), SigCA[sig](KMS )—KMS is his signing key and
KME is his encryption key—in order to fool the server into binding the secret ds to KME
(EncME (ds )). However, this requires forging the CA’s signature, which again amounts to breaking the cryptographic system. Thus, the protocol is secure against an active man-in-the-middle attack.
6.3.2 Ideal Trusted Platform: Security against Dishonest Users
Because the server verifies the two certificates exchanged in a protocol run, in particular that KC is non-migratable and sealed to the PCRs specified by PCR INFO, and because it binds the secret data ds to KC , the client must execute step 13 of the protocol as the honest client (i.e., using a trusted software stack). Afterwards, a dishonest user could put the client into a dishonest state (by launching another process if at all permitted or rebooting another stack) which results in different PCR values and in the TPM not unbinding the secret ds . Alternatively, a dishonest user could mount a hardware attack in order to read the secret ds out of the TPM, which we assume to be infeasible given an ideal (tamper-proof) trusted platform. Thus, an ideal (tamper-proof) trusted platform not only provides security against man-in-the-middle attacks but also against attacks by dishonest clients. 92 6.3. SECURITY ANALYSIS Chapter 7
Encoding Documents
Our approach requires document encodings at two levels. At the lower level, encodings for document components—in particular content, title deed, and access policy— are required. In other words, content, title deed, and access policy require a concrete syntax. At the higher level, an encoding for document tuples is required. On the one hand, the higher-level encoding has to tie a document’s components to each other for the sake of usability. Subjects should not have to manage the document components individually. That is, documents need to be encoded such that they appear as an indi- visible unit on storage (i.e., in a file system) or in transit (e.g., as an e-mail attachment). On the other hand, through the application of cryptography, the higher-level encoding has to tie the document components to each other for the sake of security. Attackers must neither be able to circumvent the PEP by directly accessing the content nor be able to fool the PDP by changing the title deed or the access policy without authorization. Section 7.1 and Section 7.2 are about document-component encodings while Sec- tion 7.3 is about document-tuple encodings.
7.1 Encoding Content
Content encodings are highly application-dependent. Many content encodings are likely to be and remain XML-based in the foreseeable future, but the beauty of our approach is not only that the content encodings are fully independent of the policy encodings, but also that the content encodings and the respective tools (e.g., the best of the many XML APIs for the application at hand) can be chosen without having to artificially and inefficiently map them to a generic content encoding or tool. An example content encoding (for report content as modeled in Section 4.3.1) is given in Appendix A.1.
93 94 7.2. ENCODING POLICIES
7.2 Encoding Policies
Originally, we intended to express access policies in the eXtensible Access Control Markup Language (XACML) [93]. The XACML is a very powerful, but also very complex XML- based policy, request, and response language. Even though several implementations of the XACML are readily available, in particular an open-source one from Sun Microsys- tems Laboratories1, we have decided against basing our access-policy language on the XACML (i.e., against defining an XACML profile). After careful consideration, we feel that the benefits do not justify the costs; we do not require the XACML’s power but would still have had to manage its complexity (e.g., the fact that one set of security requirements can be formalized in many ways in the XACML). Instead, we have defined one straightforward XML-based format each for title deeds and access policies. Based on the semantics and abstract syntax from Chapter 5, a concrete syntax of both title deeds and access policies is specified in the XML Schema language [136] in Appendix B. An example title deed and an example access policy that ease access (no pun intended) to the schemas are given in Appendix A.2 and A.3, respectively. With respect to our encoding of access policies, recall that the central abstraction in role-based access control is the role-permission relation.2 Mathematically, a role- permission relation (Role ↔ Permission) is a subset of the Cartesian product set of the set of roles and the set of permissions (Role × Permission); in other words, a role- permission relation is a set of ordered role-permission pairs and hence an element in P(Role × Permission). When a role-permission pair is added to the set, no other pair is affected. When a role-permission pair is deleted from the set, no other pair is affected either. Unlike with actual encodings of role-permission relations, there can thus be no undesired side effects. In practice, access policies are not encoded as sets of role-permission pairs but in a form that is reminiscent of normalized relational databases [50, 141]. Depending on how exactly the role-permission relation is “normalized”, there are consequences that policy makers need to be aware of but that—to the best of our knowledge—have not been explicitly addressed in the literature yet. We give two simple examples3 in order to sensitize the reader to such consequences:
• In Ferraiolo et al.’s policy language [41], roles are defined and given an ID, permissions are defined and given an ID, and the role-permission relation is defined
1http://sunxacml.sourceforge.net/ 2Admittedly, the user-role relation is just as important for the overall system. But unlike the role- permission relation, which is in the realm of the authorization subsystem and thus inside the scope of this dissertation, the user-role relation is in the realm of the authentication subsystem and thus outside the scope of this dissertation. 3Further examples can be found in related work (cf. §8), in the Enterprise JavaBeans policy language [23, 105], and in many other models and systems. 7.3. ENCODING DOCUMENT TUPLES 95
by defining mappings between one role ID and a set of permission IDs:
[RoleID, PermissionID] Role == RoleID × ... Permission == PermissionID × ... RPsMapping == RoleID × P PermissionID Policy == P Role × P Permission × P RPsMapping
Problems such as referencing a non-existent role (ID) or permission (ID) can be easily avoided with automated tool support. But care has to be taken when permissions are changed as all roles that are related to those permissions are affected. It may be prudent to consider permissions to be immutable (i.e., they can be added and deleted but not changed); in that case, there is no reason for the “same” permission to be defined under two different IDs, so tools can also check for duplicates.
• In Steele et al.’s policy language [120], a role is basically defined as a set of permissions:
[RoleID, Permission] Role == RoleID × P Permission Policy == P Role
Now the “same” permission has to be duplicated n times when it is supposed to be related to n roles. Consequently, it also has to be changed or deleted n times. In other words, the pitfalls in this kind of encoding are dual to those of the last one.
What seems important to us is that users do not have to “normalize” role-permission relations manually as this would nullify the advantages of role-based access control. In other words, merely featuring a concept called “role” does not turn an access-control model into a role-based one. Our solution is to shield users from the actual encoding by providing a software layer that gives them a relational view of access policies.
7.3 Encoding Document Tuples
As already mentioned in Chapter 3 and as explicitly modeled in Chapter 5, documents are tuples. Until now, they have been 3-tuples consisting of a content component, a title-deed component, and an access-policy component (cf. Figure 7.1). Grouping these files is based on a simple, yet powerful idea that we first became aware of in the form of OpenDocument Format (ODF) files: documents are encoded as ZIP files whereby document components are mapped to ZIP-file entries. As a free side effect of this encoding, document components are even compressed. 96 7.3. ENCODING DOCUMENT TUPLES
Content
Document Title Deed (triple)
Access Policy
Figure 7.1: Document Model (unsecured)
Obviously, nothing in that encoding keeps attackers from circumventing the policy points, which is why we actually encode document tuples as depicted in Figure 7.2. That is, hereafter documents are 5-tuples, consisting of an encrypted content component, a title-deed component, an access-policy component, an encrypted decryption key, and a (digital) signature.
encrypted Decryption Key
encrypted Content
Document Title Deed (5-tuple)
Access Policy
Signature
Figure 7.2: Document Model (secured)
In order to analyze the security of the document encoding, we need to start with what only a document processor knows and we need to understand (the security of) the steps taken by the document processor to arrive at encoded document d given a content component c, a title-deed component td, and an access-policy component ac and vice versa:
• Possessions of the document processor:
– master encryption/decryption key pair (kencryption , kdecryption )
– signing/verification key pair (ksigning , kverification ) – content component c
• From components to tuple: 7.4. LEVELSOF TRUST 97
1. Generate a session key ksession . For performance reasons, the session key is symmetric.
2. Encrypt content c with session key ksession to yield encrypted content ec.
3. Encrypt session key ksession with master encryption key kencryption to yield
encrypted session key eksession , discarding session key ksession . 4. Sign encrypted content ec, title deed td, and access policy ap with signing
key ksigning to yield signature sig.
5. Group encrypted session key eksession , encrypted content ec, title deed td, access policy ap, and signature sig to yield document d.
• From tuple to components:
1. Ungroup document d to yield encrypted session key eksession , encrypted content ec, title deed td, access policy ap, and signature sig. 2. Verify signature sig over encrypted content ec, title deed td, and access pol-
icy ap with verification key kverification . Abort if the verification fails!
3. Decrypt encrypted session key eksession with master decryption key kdecryption
to yield session key ksession .
4. Decrypt encrypted content ec with session key ksession to yield content c, dis-
carding session key ksession .
Given the document d, an attacker could attempt to replace title deed td or access policy ap to dupe the document processor. To thwart this attack, the signing key ksigning must be secret and the verification key kverification must be authentic so that the signature sig cannot be replaced. Given the encrypted content ec, the attacker could also attempt to decrypt it himself. To thwart this attack, both the session key ksession and the master decryption key kdecryption must be secret. How to secure these keys is the topic of Chapter 6.
7.4 Levels of Trust
In our discussions so far, trust has been a binary property of platforms: either the platform is trusted or the platform is not trusted. However, more interesting and chal- lenging than the situation with a (fully) trusted platform only are situations in which documents need to be accessible on platforms with different levels of trust. Admit- tedly, having to deal with such situations is currently more realistic in the context of multimedia applications [100] than in our context of banking. But as this may change in the future, we provide some food for thought in this section. 98 7.4. LEVELSOF TRUST
We consider two different platforms: a fully trusted one (e.g., based on TPMs) and a partially trusted one (e.g., based on white-box cryptography). The assumption is that the partially trusted one is easier to break than the fully trusted one. Furthermore, we consider two client applications, a reader and an editor. A reader can open and display documents while an editor can open and display documents as well as create, change, and save documents. In line with the number of platforms, we also consider two content-sensitivity levels: confidential and secret. Confidential content can potentially be granted access to on both fully trusted platforms and partially trusted platforms. Secret content must never be accessible on partially trusted platforms. Whether a piece of data within a document’s content is confidential or secret is expressed in a new document component, the sensitivity policy (what Popescu et al. [100] call data- flow policy). A document’s sensitivity policy could be derived from the document’s access policy. There are two meaningful cases to discuss (cf. Table 7.1):
1. The editor is available on the fully trusted platform only and the reader is available on the partially trusted platform (as well as on the fully trusted platform).
2. The editor is available on both the fully trusted platform and the partially trusted platform (and the reader is available on both platforms as well).
In both cases, our goal is to ensure that no subject gains unauthorized access to secret data (unless the fully trusted platform is broken) even if the partially trusted platform is broken. In what follows, when we state that document data is encrypted with a key e, we actually mean that a (symmetric) session key is generated, the data encrypted with the session key, the session key encrypted with the key e, and the encrypted session key stored as a further component of the document. Conversely, when we state that document data is decrypted with a key d, we actually mean that the session key corresponding to the data is decrypted with the key d and the data decrypted with the session key.
Case 1 Case 2 editor reader editor reader
fully trusted platform √ √ √ √ (secret content)
partially trusted platform √ √ √ — (confidential content) Table 7.1: Overview of Cases 1 and 2 7.4. LEVELSOF TRUST 99
Case 1
Let’s assume that documents are still signed tuples with encrypted content component as described in Section 7.3. The editor (on the fully trusted platform) knows key pairs (e, d) and (s, v) where e is an encryption key, d a decryption key, s a signing key, and v a verification key. The reader (on the partially trusted platform) must know keys v and d in order to verify a document’s integrity and decrypt its content, respectively. If an attacker were to learn d, he could circumvent the reader, decrypt a document’s content component and would thus have gained access not only to confidential but also to secret data. Alternatively, if the attacker were to replace v by his verification key va , he could replace a document’s access policy with one that grants him arbitrary access, sign the document tuple with his signing key sa , and have the reader decrypt the document’s content for him. To thwart these attacks, we introduce a third key pair (cf. Table 7.2). The editor now knows key pairs (es , ds ), (ec, dc), and (s, v). The reader must know keys dc and v.A document’s content is no longer encrypted as a whole; instead, secret data is encrypted with es and confidential data with ec. If an attacker were to learn dc, he would “only” have gained access to confidential but not to secret data. Similarly, if the attacker were to replace v by his verification key va , he could have the reader decrypt confidential data for him but no secret data since the reader does not know ds .
editor on fully reader on fully editor on partially reader on partially trusted platform trusted platform trusted platform trusted platform
(es , ds ) ds —
(ec, dc) dc — dc (s, v) v — v
Table 7.2: Key Distribution for Case 1
Case 2
This case builds on the previous one. Let’s still assume that the editor on the fully trusted platform knows key pairs (es , ds ), (ec, dc), and (s, v). The editor on the partially trusted platform must know key pairs (ec, dc) (in order to encrypt data) and (s, v) (in order to vouch for a document’s integrity). Obviously, all data created or changed with the editor on the partially trusted platform is always confidential and never secret. Even though an attacker can still not gain access to secret data on the partially trusted platform, he could mount an attack reminiscent of a privilege-escalation attack: if he were to learn s, he could replace a document’s access policy with one that grants him arbitrary access, sign the document tuple, and have the editor (or reader) on the fully 100 7.4. LEVELSOF TRUST trusted platform decrypt the document’s content for him. (Note that tampering with the sensitivity policy would be of no use to the attacker; on the contrary, it would allow the editor to detect a mismatch between sensitivity level and encryption key.) To thwart this attack, we introduce a fourth key pair. The editor on the fully trusted platform now knows key pairs (es , ds ), (ec, dc), (ss , vs ), and (sc, vc). The editor on the partially trusted platform knows key pairs (ec, dc) and (sc, vc) as well as key vs .A document is no longer signed as a whole; instead, those parts of the access policy referring to secret data are signed with ss and those parts of the access policy referring to confidential data are signed with sc. If the attacker were to learn sc and use it to also sign those parts of an access policy that refer to secret data, the editor on the fully trusted platform would detect a mismatch between the sensitivity levels of the signing key and the encryption key. If the attacker replaced the sensitivity policy as well in order to avoid mismatch detection, the editor would simply use the wrong decryption key. However, he could replace the access policy with one from a document whose content happens to have the same structure as the content he is trying to access, but whose access policy permits him more access. Despite having failed to thwart the latest attack yet, we are on the right track. In the previous document encodings, signing a document as a whole cryptographically tied its components to each other. What remains to be done to secure the current document encoding is reintroducing cryptographic ties by signing more than just access-policy parts. Document content has structure and pieces of content (the granules or access objects) have an address. Let ci denote a document’s piece of content at address i, sli ci ’s sensitivity level, and apsi those parts of the access policy referring to ci . A new document component, the signature collection, is a collection of signatures whereby the ith signature has been generated by signing a cryptographic hash of the triple (ci , sli , apsi ) (or at least pair (ci , apsi )) with ss if ci is secret and with sc if ci is confidential (as expressed in sli ). One minor issue remains to be looked into: Is it necessary for the editor on the fully trusted platform to know signing key sc? With respect to our goal, the answer is no.
The editor on the trusted platform could sign all triples with ss , even those previously signed with sc. However, this could lead subjects (whether human or not) to let down their guard and trust in the signatures more than they maybe should. Therefore, we propose to never replace sc-based signatures with ss -based ones as implied in Table 7.3. In this section, we have considered two platforms (fully trusted and partially trusted) and two applications (editor and reader). Provided that the need exists in practice, one could consider three or more platforms (totally or only partially ordered with respect to the level of trust vested in them) and/or three or more applications (with different sets of possible features). 7.5. SOFTWARE SECURITY 101
editor on fully reader on fully editor on partially reader on partially trusted platform trusted platform trusted platform trusted platform
(es , ds ) ds
(ec, dc) dc (ec, dc) dc
(ss , vs ) vs vs vs
(sc, vc) vc (sc, vc) vc
Table 7.3: Key Distribution for Case 2
7.5 Software Security
Devising cryptographic primitives is a demanding undertaking; lucky for us, there are quite a few good ones to choose from so that we do not have to devise our own [84, 121, 40, 119]. However, the security of our document-tuple encoding not only depends on applying the right cryptographic primitives (which we can assume to be perfect) at the right step. It also depends on the document processor not disclosing its possessions accidentally. Ensuring the latter (e.g., by not dumping core before any secrets in memory have been overwritten) is the topic of software security. There are a great many excellent books on software security available these days (e.g., [57, 63, 64, 65, 129, 130]). So while properly using cryptographic primitives as building blocks requires care, it can reason- ably be expected from software engineers. In practice, when it comes to cryptography, the most difficult problem is arguably the management of cryptographic keys. 102 7.5. SOFTWARE SECURITY Chapter 8
Related Work
With respect to access-control models, XML access control is most closely related to our work. We devote most of this section to it. With respect to key management, there is no open related work worth mentioning. Obviously, industry has come up with solutions, but does not seem willing to disclose implementation details.1 For example, the most detailed description of Apple’s FairPlay (used in Apple’s iPod, iTunes, and QuickTime products) we have found is a Wikipedia entry [139]. Project DReaM is an initiative by Sun Microsystems to develop open specifications for and an open reference implementation of a DRM solution [123]. However, several important aspects have not been addressed yet, in particular “[c]lient security—the implementation of a robust client that will be required for a viable solution.” [125, p. 4] Also related to our work are certain (commercial) document-security systems. Such systems, the one from Adobe for documents in the Portable Document Format (PDF) [1] being a good example2, are based on fairly simple access-control models that are not fine-grained at all (i.e., a document as a whole is the object to which access is controlled). While access to copy operations can be denied, what can be copied is no longer controlled access to (i.e., there is no support for sticky policies). On the plus side, a simple access-control model makes for better usability. Furthermore, such systems typically feature document life cycle and work-flow functionality. Note that document security not always means controlling access to a document independently of other documents. For example, Atallah and Bykova [5] and Bykova and Atallah [24], tackle the general problem of how to best encode access to a subset of n documents in an m-bit string when m < n. One criterium for the quality of such an encoding is the number of false positives, which the authors define as access to a document that should not be accessible. Note further that document security not even al-
1One can speculate whether acting against Kerkhoff’s principle (or Shannon’s maxim if you prefer) is to gain a competitive advantage over competitors or because there is no viable alternative to security by obscurity yet. 2http://www.adobe.com/products/server/securityserver/
103 104 8.1. XML ACCESS CONTROL ways means controlling access. For example, the Document Security Language (DSL) by Hwang and Chang [66] is an XML-based language that allows to express how an XML document is transformed into another XML document by encrypting and/or signing parts of it. A DSL instance consists of sections that define keys and algorithms, of sections that assign keys to algorithms, of sections that describe the encryption steps based on the XSL Transformations (XSLT) [138, 59] part of the Extensible Stylesheet Language (XSL), and of sections that describe the signing steps. (While attribute-level encryption is supported, the result of a DSL transformation neither respects the XML Encryp- tion [134] nor the XML Signature [137] standard.) Such document-security works are obviously not related to ours.
8.1 XML Access Control
We first discuss the general characteristics of XML access control and then proposal- specific ones.
8.1.1 General Characteristics
As its name implies, XML access control is about controlling access to XML documents. (It is not about encoding policies or requests and responses in the XML, albeit doing so in the context of XML access control is typical.) For the most part, the focus of XML access control is on record-like/data-oriented XML documents and on server- side mechanisms enforcing centrally administrated access policies. This focus seems to stem from the attempt to port access-control models and systems from the world of relational databases to the world of XML databases. XML access control is based on fine-grained XML document models, although the different models differ in the granularity and the types of their constituent parts. More- over, they differ in the operations offered and their semantics. Some systems only provide a read operation with no arguments and thus expect subjects to request entire XML documents (typically, there is only one instance, namely the XML-encoded database), in which case the systems respond with a censored copy called the view (Gabillon [45] compares several view-generation strategies). Policy languages for XML access control differ considerably, both in their features in general and in their syntactic sugar in particular. Quite a few features are intended to ease a policy writer’s life, but they are also a double-edged sword: they not only make the policy language more complex, they may also necessitate conflict-resolution strategies [32, 67, 77]. The (XML) documents that we secure are narrative-like/document-oriented, and we do so with client-side mechanisms. As we have seen, our document-content model 8.1. XML ACCESS CONTROL 105 is more general than the model of XML documents. Furthermore, its specialization to XML documents is more comprehensive (covering not only element and text nodes but also comment and processing-instruction nodes) and of finer granularity. With respect to access policies, we have focused on a simple, yet expressive, core language with a clean, formal semantics that avoids conflicts by design. Finally, thanks to our support for sticky policies, data is never left at the user’s discretion, not even when it is copied.
8.1.2 Proposal-Specific Characteristics
The XML Access Control Language (XACL) [67, 77] (for which Murata et al. [90] as well as Qi and Kudo [102, 103] suggest efficiency improvements) is the only proposal for XML access control with support for provisions (in Bettini et al.’s sense, cf. §2.1.4). What is peculiar is that provisions may even need to be made (by the system) when access is denied. More importantly, XACL policies may be ambiguous in terms of which provisions must have been made for a given request. In our access-control model, there is no such ambiguity. Author-χ (an access-control system) and χ-Sec (its credentials and policy language) [10, 11, 7, 9, 12] go beyond XML access control in that they actually allow to control access to semi-structured data (in Garcia-Molina et al.’s sense, cf. §4.4) encoded in the XML. Arcs (i.e., references or hyperlinks) can be given navigate access to; navigate privilege “authorizes a subject to see the existence of a specific link or of all the links in a given element and to navigate through them” [10, p. 61]. χ-Sec features a rich language based on periodic time expressions [91] for expressing temporal conditions. In our access- control model, arcs can be encoded as attributes (as is done in the XML), whereby read access can be interpreted as navigate access. As periodic time expressions are not necessary in our context, they are not supported in the concrete syntax of our access-policy language in order to keep it simple. Subjects in the Fine-Grained Access Control System for XML Documents by Dami- ani et al. [32] are 3-tuples consisting of a user-ID component, an IP-address component, and a symbolic-address component. That is, it may not only matter who (user ID) requests access but also from where (IP address and symbolic address). As in other proposals for XML access control, access policies (which consist of rules) can be writ- ten for a type of XML documents (as defined by their schema) or for a single instance. By default, more specific rules take precedence over more general ones in case of conflict. However, schema-level rules can be declared as hard, meaning they cannot be overwritten, and instance-level rules can be declared as soft, meaning they only apply when no other rules apply. This makes this proposal the only one that explicitly addresses the relation between schema-level and instance-level access policies. Based on earlier work of theirs [47], Gabillon et al. [48, 45] go beyond XML access 106 8.1. XML ACCESS CONTROL control in that their proposal is based on tree-structured data in general. However, nodes in their trees have no properties other than child nodes. This has the unfortu- nate consequence that the access-policy language must be adapted to every specialization. In contrast, we can specialize our document-content model without changing our access-policy language. On the plus side, object ownership and access-policy editing are not foreign concepts, and permission delegation is supported as well. (Using Prolog [21], Gabillon [46] has also formalized certain aspects.) Given a subject and an access policy, Xplorer [120] generates a GUI that allows the subject to access XML documents in accordance with the access policy (whose role- permission encoding we already mentioned in Section 7.2). Objects are not directly referred to in permissions. Instead, objects are given a sensitivity level and permissions are defined to apply to objects of certain sensitivity levels. While our access-control model is more general, sensitivity levels are very attractive from a usability point of view as object owners could limit themselves to assigning their objects a sensitivity level instead of a role-permission relation. The task of assigning role-permission relations to sensitivity levels could then be left to expert policy makers. Further proposals for XML access control with no distinctive characteristic of interest to us include [17, 35, 39, 55, 56, 70, 144]. Bertino et al. [8], Fundulaki and Marx [44], Luo et al. [81], and Rihak [104] compare smaller sets of proposals for XML access control but, with the exception of Bertino et al., in more depth than we do.3
3Anderson’s comparison between the Enterprise Privacy Authorization Language (EPAL) [68] and the eXtensible Access Control Markup Language (XACML) [93] may also be of interest [2]. Chapter 9
Conclusion
In the course of this dissertation, we have designed a model and implemented a system in order to achieve document security, the primary security goal being confidentiality and the secondary security goal being integrity. We are interested in document security in particular because we are interested in information security in general, because information is represented by data [53], and because documents represent an important class of data container.
9.1 Summary
We have presented our document model whereby documents are tuples consisting of a content component, a title-deed component, an access-policy component, a decryption- key component, and a signature component. The (encrypted) content component is where the data that represents the sensitive information is stored. Its model is that of a (rooted) tree consisting of attributed nodes. The title-deed component features object- ownership information, the objects being the nodes and the attributes. Its model is that of a function from objects to users. The access-policy component formalizes document- specific security requirements. Its model is that of a relation between roles and permissions. The decryption-key component is a (itself encrypted) key for decrypting the content component. The signature component cryptographically ties the content component, the title-deed component, and the access-policy component to each other. Our document model reflects that access to documents needs to be controlled at two levels. By ensuring that only select processes know the decryption key necessary to decrypt a document’s decryption key, we ensure that only those processes have full access to the document. By further ensuring that those processes can and do verify the authenticity of the document’s signature and that they grant access (or not) to the document’s content in accordance with the document’s access policy (and to the document’s access policy in accordance with the document’s title deed), we ensure that
107 108 9.2. FUTURE WORK subjects have limited access to the document. Our access-control model is fine-grained and role-based. Furthermore, access-control decisions can depend on provisions having been made as well as the time of access. We have also incorporated the sticky-policies paradigm into our model and system in order to allow for copy (or cut) and paste operations that do not result in unsecured information. We have even outlined how the realm of sticky policies can be extended beyond documents to include databases. As for key management, we have designed a protocol that allows servers to securely distribute secrets to trusted platforms. The protocol is based on trusted-computing technology and is specified at the level of TPM commands. The protocol maintains the confidentiality of secrets in the face of eavesdroppers and careless users. Given an ideal (tamper-proof) trusted platform, the protocol maintains the confidentiality of secrets even in the face of dishonest users.
9.2 Future Work
Even though we have come a long way, there is still important and interesting work left to do in document security. The following is a non-exhaustive list of suggestions in addition to the one we made at the end of Section 5.4. Copy by Reference Users cannot be expected to keep track of sensitive content that has been duplicated and to consistently maintain the access policy or policies. This issue is obvious when content from one type of container (e.g., a relational database) is copied into another (e.g., a presentation) (cf. §5.4) or when content is copied from one document into another and is still obvious when content is explicitly copied within a document. Content may also be copied implicitly within a document, in which case the user may not be aware of it. As a case in point, consider the spreadsheet table and its corresponding chart depicted in Figure 9.1. In OpenOffice.org, such a document results in two content.xml files, excerpts of which are given below.
20 30 40 9.2. FUTURE WORK 109
22 33 44
Figure 9.1: Two Views Depicting the Same Model
Row 1 110 9.2. FUTURE WORK
20 30 40 Row 2 22 33 44
As can be seen in the excerpts above, a potentially sensitive piece of data such as the value 22 appears four times, namely once as an attribute value and once as a text node in both content.xml files. In software-engineering terms (as coined by the Model-View-Controller pattern [49, 89]), the model is redundant1, but—as a simple test shows—changes in one view (the table) are reflected in the other (the chart), so the views are consistent. This suggests two possible avenues for keeping the access policy consistent: employ the same mechanisms that keep the views consistent or normalize the model. Execution Policy In Section 4.3.3, we sketch a specialization of our document- content model to a generic file system. At the end of that section, we point out that if the file system represents a revision control system, no execute operation is required. Nevertheless, it may be worthwhile to investigate whether our access-control model can be put to good use in containers such as file systems and how to support process execution. Location-based Access Control Permissions match a request when several condi-
1Strictly speaking, a “redundant model” is an oxymoron. 9.2. FUTURE WORK 111 tions hold. In order to account for differing data-protection legislation, one could additionally demand that a request originates from a location in a permission’s set of locations. Extending our model to support location-based access control is straightforward. The difficulty lies in measuring the location of a computer system in a trustworthy manner. Office Suite Compared to document formats of office suites such as Microsoft Of- fice [85, 78] and OpenOffice.org [94, 96, 38], reports as we have defined them and plain XML documents are merely toy examples. To be of practical use, our access-control model thus has to be incorporated into a state-of-the-art office suite. Printing For many reasons, printing documents is a necessity. This effectively strips the (previously sticky) policy away. In order to force users to carefully handle hard copies of sensitive documents, performing Lightweight Digital Rights Management (LWDRM)2 by incorporating watermarks that clearly state which user has printed out a given document may go a long way. Obviously, users must not be able to print out more than they can read electronically. How to prune documents is application-dependent, however. (In the case of XML documents, for example, the resulting XML document may no longer be valid even though it may still be well-formed.) Furthermore, printing may require that users have made additional provisions—which could be as mundane as having paid a license fee. Usability Usability and security do not always go hand in hand, but they do not necessarily stand in each other’s way, either [52, 31]. In this dissertation, we have not paid much attention to usability with the notable exception of the edit state that we have identified as being crucial for document processors to be usable at all. Obviously, our prototype’s user interface (UI) leaves a lot to be desired. Nodes and attributes have to be explicitly expanded, which is tedious even for small documents. Maybe the UI could implicitly (try to) expand them when they become visible. Furthermore, the content-tree structure has to be managed manually whereas this happens automatically in document processors that allow for declaring a stretch of text as a heading, a paragraph, a list item, etc. with the single click of a button. The fine granularity of our access-control model brings with it that object owners have to assign permissions to roles for every single object they own. This, too, is tedious even for small documents. Working with sensitivity levels as discussed in Chap- ter 8 would alleviate this problem; this would also change the access-control model, however. Alternatively, the UI could provide for assigning permissions to roles for several objects at once. Note that we do not suggest to extend our access-control model
2http://www.idmt.fraunhofer.de/de/projekte_themen/lwdrm.htm and http://www. lwdrm.com/ 112 9.3. LESSONS LEARNED with an inheritance scheme for role-permission relations. Such schemes are popular in XML access control but bring with them a whole new set of issues. Formal Trusted Computing We have provided an informal security analysis of the protocol presented in Chapter 6. A formal analysis of our protocol and other TPM- based protocols would require developing formal models for TPM-specific concepts such as binding and sealing, which could be based on groundwork laid by Lin [80]. Speaking of formalization. According to Bowen and Hinchey [19], there are three formalization levels: formal specification (level 0), formal development/verification (level 1), and machine-checked proofs (level 2). As they explain, even limiting oneself to level 0 formality can accrue many benefits, which has been confirmed by our experience. Our formal models turned out to be a solid foundation for the implementation of our prototype even without applying refinement calculus (employing both an object- oriented formal notation and an object-oriented programming language was certainly of great value, too). Problematic designs have been caught early and cheaper to fix than they would have been without a formal model. Furthermore, the formal model shows clearly where there is high potential for reuse across different document formats. Fi- nally, defining the semantics and (abstract) syntax of policy languages can hardly be done with more precision in natural language than in the language of mathematics.
9.3 Lessons Learned
When the ZISC project that resulted in this dissertation was launched about three and a half years ago, a deceptively modest goal was set, namely to figure out whether document-security solutions that meet a bank’s requirements are feasible at all. Ex- pected was not a solution that can be put into practice in the short term; expected was a basis for deciding whether a salesman claiming to have a document-security solution should be heard out—or kicked out. The good news is that practical document-security solutions are feasible in our—in the meantime expert—opinion. The bad news is that a potential solution still needs careful evaluation as it certainly had to trade functionality, security, and usability off against each other. With respect to security, there are four aspects to evaluate. The first aspect to evaluate is authentication. The strongest authorization system cannot compensate for a weak authentication system; the overall access-control system would thus be weak, too. However, since banks already have strong authentication systems in place (not only for their employees, but also for their customers [online banking]), document-security solutions should allow for plugging the banks’ authentication systems in instead of providing their own (cf. Appendix C for how we have done so). 9.3. LESSONS LEARNED 113
The second aspect to evaluate is the document-content model. That the document- content model is hierarchical is not as important as we originally thought, even though (implicitly) limiting access to a subtree by limiting access to the subtree’s root node is very convenient. What is important is that many application-level objects (e.g., head- ings, lists, paragraphs, tables, etc.) can be mapped to a few abstract objects (e.g., nodes and attributes). What security requirements can be formalized should not depend on whether a sensitive piece of data is in a heading, a list, or any other application-level object. On the contrary, it should be possible to have the same piece of data in different application-level objects during a document’s lifetime without the security requirements having to change. (There are examples in XML access control where, for instance, an element tag cannot be turned into a text node without having to manually adapt the policy.) The third aspect to evaluate is the access-control model. There is no reason why fine-grained access control and sticky policies cannot be supported and there is no reason why access-control decision cannot depend on time and on provisions having been made. The access-control model being role-based is not a problem, either. How- ever, how can access-control systems cope with changing role hierarchies, especially if there is not one centralized container to which access is controlled (e.g., a database) but many distributed containers (e.g., documents)? Collaborative document processors may alleviate the problem (i.e., there are still many containers, but they are centralized and not distributed anymore). But this issue of changing roles needs to be looked into independent of document security if role-based access control is to live up to its expectations. Luckily, our access-control model would not need a complete overhaul if role-based access control was deemed unsuitable for document security. By assigning all permissions to the base role (anyRole) (and by not including all users in a permission’s set of users), role-based access control can pretty much be disabled. The fourth, and most difficult, aspect to evaluate is key management. The jury is still out on whether trusted computing as championed by the Trusted Computing Group becomes ubiquitous. In the meantime, many vendors (not only in document security) rely on other means to secure keys. But many DRM schemes have been, and are being, broken because keys cannot be secured well enough to withstand attacks long enough to not make it worth the attackers’ while.—Whoever comes up with a work- able solution to the key-management problem will have a huge impact on information security in practice. Who knows, our TPM-based protocol may just be it. 114 9.3. LESSONS LEARNED Appendix A
Example Report
In this chapter, we present a concrete title deed in Section A.2 and a concrete access policy in Section A.3. The document that they govern access to is a report document whose content is presented in Section A.1.
A.1 Content
The report-content schema is shown in Listing A.1 and in Figure A.1 on page 117. Re- call that sensitive data is in attribute values and note that in the report-content schema, title data is in XML-attribute values while paragraph data is in text nodes. This high- lights an important point: there is no obligation to map model attributes to XML attributes. In any case, the report-content format is fairly straightforward.

115 116 A.1. CONTENT
Listing A.1: Report Schema
For example, the report tree depicted in Figure A.2 on page 118 corresponds to the XML document in Listing A.2. The report has one paragraph and two chapters. The first chapter has two paragraphs and the second chapter has one section. The section has one paragraph. As we know from Section 4.3.1, each node in the report has exactly one (model) attribute.
... ... ...
... Listing A.2: Example Report A.1. CONTENT 117 1 of SectionType ChapterType type: SectionType type: ChapterType ∞ ∞ 0.. 0.. section chapter ParagraphParentType ParagraphParentType ParagraphParentType base: ParagraphParentType base: ParagraphParentType base: ParagraphParentType string type: string from: XMLSchema.xsd string ∞ 0.. type: string from: XMLSchema.xsd paragraph extends: dsr:ParagraphParentType extends: dsr:ParagraphParentType extends: dsr:ParagraphParentType @ title ReportType type: ReportType ParagraphParentType ReportType ChapterType SectionType report ec/Java/Schemas/Report.xsd schema / file:/E:/synchronized/DocS
Figure A.1: Report Schema 118 A.2. TITLE DEED
Report title = “…”
Paragraph Chapter Chapter text = “…” title = “…” title = “…”
Paragraph Paragraph Section text = “…” text = “…” title = “…”
Paragraph text = “…”
Figure A.2: Example Report Tree
A.2 Title Deed
The title deed is shown in Listing A.3. Taking advantage of the fact that the XML model is also tree-based, nodes are addressed implicitly. Except for the second chapter node and all its descendants, the report node and all its descendants are owned by user David. The second chapter node and all its descendants are owned by user Paul. Note that the root element, TitleDeed, declares http://www.zisc.ethz. ch/research/docsec/titledeed as the default namespace. A.2. TITLE DEED 119

Listing A.3: Example Title Deed 120 A.3. ACCESS POLICY
A.3 Access Policy
The access policy is shown in Listing A.4. Again, taking advantage of the fact that the XML model is also tree-based, nodes are addressed implicitly (i.e., Permission elements neither have an object-related XML attribute nor an object-related child element). Except for the second chapter node and all its descendants, subjects in role
Student have permissions p2 and p3 on the report node and all its descendants and subjects in role Professor have permissions p0, p1, and p4. That is, user Paul in role Student is allowed to make changes until noon on February 28, 2007 CET (p2) and any user in role Student is allowed to read at any time provided that the user has signed agreement NDA (p3). Users in role Professor are allowed to read (p4), make changes (p1), and even delegate their permissions (p0) without any further constraints. No subject has any permissions on the second chapter node or any of its descendants. Note that the root element, AccessPolicy, declares http://www.zisc.ethz.ch/research/ docsec/accesspolicy as the default namespace.
delegate change Paul change A.3. ACCESS POLICY 121
read read 122 A.3. ACCESS POLICY
A.3. ACCESS POLICY 123
124 A.3. ACCESS POLICY
Listing A.4: Example Access Policy Appendix B
Policy Schemas
The schema for title deeds (cf. Listing B.2 and Figure B.1 on page 127) and the schema for access policies (cf. Listing B.3) have two types in common (cf. Listing B.1)1. One, AttributeType, is the base type of attribute references, which require a name. The other, UserIDType, is the type of user IDs. Both are in the same namespace, http: //www.zisc.ethz.ch/research/docsec.

This work was partially supported by the Zurich Information Security Center. It represents the views of the authors.

1We omit graphical representations of the policy schema and the access-policy schema because they are too simple and too complex, respectively.
125 126 B.1. TITLE DEEDS
Listing B.1: Policy Schema
B.1 Title Deeds
The root element of title deeds is TitleDeed and has one child element, Node, which refers to the root node of a document’s content component. Node elements have one XML attribute and two child elements. The name of the XML attribute is owner and its value denotes the ID of the user who owns the content node. The first child element, Attributes, has zero or more child elements, all Attributes, and the second child element, Nodes, has also zero or more child elements, all Nodes. Attribute elements have two XML attributes. The name of one of the two XML attributes is name and its value denotes the name of the content attribute to which it refers. The name of the other of the two XML attributes is owner and its value denotes the ID of the user who owns the content attribute. Title deeds have no text nodes, so white space between tags can be ignored.

This work was partially supported by the Zurich Information Security Center. It represents the views of the authors.
B.1. TITLE DEEDS 127 1 of AttributeType type: AttributeType NodeType UserIDType type: NodeType type: UserIDType from: PolicySchema.xsd ∞ 0.. Attribute ∞ AttributeType 0.. Node base: AttributeType from: PolicySchema.xsd @owner NodeType type: NodeType UserIDType extends: ds:AttributeType type: UserIDType from: PolicySchema.xsd Node Attributes Nodes PolicyType @owner type: PolicyType import: PolicySchema.xsd PolicyType NodeType AttributeType TitleDeed ava/Schemas/TitleDeedSchema.xsd schema / file:/E:/synchronized/DocSec/J
Figure B.1: Title Deed Schema 128 B.2. ACCESS POLICIES

Listing B.2: Title Deed Schema
B.2 Access Policies
The root element of access policies is AccessPolicy and has two child elements, Permissions, which encloses a set of permissions, and Node, which refers to the root node of a document’s content component. A permission is encoded in a Permission element. Permission elements have one XML attribute and four child elements. The B.2. ACCESS POLICIES 129 name of the XML attribute is id and its value is unique among an access policy’s permission IDs. Permission’s first child element, Users, has either one child element, AnyUser, or one or more child elements, all Users. AnyUser is an empty element whose meaning is “any and every user”.2 User elements have one child text node whose value denotes a user ID. Permission’s second child element, Action, has one child text node whose value can be read, change, or delegate. Permission’s third child element, Time, is an empty element with two optional XML attributes. It basically represents the set of all points in time, but the XML attribute since reduces the set to those points in time since its value while the XML attribute until reduces the set to those points in time until its value. Permission’s fourth child element, Provisions, has zero or more child elements, all Agrees and Signs. Both Agree and Sign elements are empty elements with one XML attribute. The name of the XML attribute is agreement and its value denotes the ID of the agreement that must have been agreed to and signed, respectively. Node elements have three child elements. The first child element, RolePermissions, has zero or more child elements, all RolePermissions, the second child element, Attributes, has also zero or more child elements, all Attributes, and the third child element, Nodes, has zero or more child elements as well, all Nodes. RolePermission elements are empty and have two XML attributes. The name of one of the two XML attributes is role and its value is the name of a role. The name of the other of the two XML attributes is permissionIDs and its value is a white-space seperated list of permissions IDs defined in the same access policy. Attribute elements have one XML attribute and one child element, RolePermissions. The name of the XML attribute is name and its value denotes the name of the content attribute to which it refers.

2We have considered doing without the AnyUser element and interpreting an empty Users element as the set of all users (recall that in the model, the set of users is never empty). However, this may not only have been confusing and error-prone because an empty set would have encoded the contrary but also because it would have amounted to a default-grant semantics whereas the overall semantics is default-deny. 130 B.2. ACCESS POLICIES
This work was partially supported by the Zurich Information Security Center. It represents the views of the authors.

B.2. ACCESS POLICIES 131

132 B.2. ACCESS POLICIES

Listing B.3: Access Policy Schema Appendix C
Implementation Notes
We have implemented in the Java programming language a prototypical document processor that runs on the Java platform. Furthermore, we have implemented a provisions service as a Web service [106] and a key-management subsystem based on trusted computing technology [145]. The prototype—including the full source code—is available at http://www.zisc. ethz.ch/research/docsec. Running the prototype requires the Java Platform, Standard Edition version 6 or later with no additional libraries or version 5 with
• the Java Architecture for XML Binding (JAXB) and
• the Streaming API for XML (StAX).
Note that the Java Platform, Enterprise Edition version 5 includes these libraries. Sun Microsystems’ implementation of the Java Platform, Standard Edition is available at http://java.sun.com/javase/. The reference implementation of the Java API for XML Binding (i.e., jaxb-api.jar and jaxb-impl.jar) is available at https: //jaxb.dev.java.net/ and includes the Streaming API for XML. The reference implementation of the Streaming API for XML (i.e., jsr173 1.0 api.jar) is available at http://dev2dev.bea.com/xml/stax.html. Sun Microsystems’ implementation of the Java Platform, Enterprise Edition is available at http://java.sun.com/ javaee/. In the remainder of this chapter, we say a few words about authentication. Authen- tication is based on the authentication part of the Java Authentication and Authoriza- tion Service (JAAS) [54]. The Java authentication service is an implementation of the Pluggable Authentication Module (PAM) framework [109, 110, 130]. We require one or more authentication modules that populate a subject with a role principal (cf. List- ing C.1 on page 134) and a user principal (cf. Listing C.2 on page 135). Since authentication mechanisms are outside the scope of this dissertation, we provide an authentication module that lets users freely choose their role name and their
133 134 user name and that is thus aptly named RidiculouslyInsecureLoginModule (cf. Listing C.3 on page 137). Without having to recompile the report editor, it can easily be replaced by a secure authentication module either by changing the configuration file at ConfigFiles/LoginModule.txt or by pointing to another configuration file in the virtual-machine argument java.security.auth.login.config1. Note that the callback handler (cf. Listing C.4 on page 139) is securely implemented and can be reused in other Swing-based applications. // $Id: Role.java 35399 2007−02−19 16:49:30Z psevinc $ package ch.ethz. zisc .docsec.authentication; import java.security . ∗ ;
/ ∗ ∗ ∗ R o l e s a r e immutable . This allows dependent classes to share references without having to worry about aliasing issues. ∗
∗ Copyright 2007 Paul E. Sevinc , Zurich Information Security Center ∗ ∗ @author Paul E. Sevinç ∗ @version $Rev : 35399 $ , $Date : 2007−02−19 17:49:30 +0100 (Mo, 19 Feb 2007) $ ∗ / public final class Role implements P r i n c i p a l { public final static Role ANY ROLE = new Role ( ) ;
private final String name;
/ / any−role constructor private Role ( ) { name = ”” ; }
public Role( String name ) { i f ( name == null | | name.length() == 0 ) { throw new IllegalArgumentException () ; }
1Recall that virtual-machine arguments are prefixed by -D (e.g., -Djava.security.auth.login.config=ConfigFiles/LoginModule.txt). 135
t h i s . name = name ; // since String is immutable }
public String getName() { return name ; // since String is immutable }
@Override public String toString() { return ”Role(” + name + ”)”; }
@Override public i n t hashCode ( ) { return name.hashCode() ; }
@Override public boolean equals( Object obj ) { return obj instanceof Role && ((Role)obj).name.equals( name ); // since Role is final } } Listing C.1: Role.java
// $Id: User.java 35416 2007−02−20 13:04:16Z psevinc $ package ch.ethz. zisc .docsec.authentication; import java . io . ∗ ; import java.security . ∗ ;
/ ∗ ∗ ∗ Users are not only serializable , but also immutable . This allows dependent classes to share references without having to worry about aliasing issues. ∗
∗ Copyright 2007 Paul E. Sevinc , Zurich Information Security Center ∗ ∗ @author Paul E. Sevinç ∗ @version $Rev : 35416 $ , $Date : 2007−02−20 14:04:16 +0100 (Di, 20 Feb 2007) $ ∗ / 136 public final class User implements Cloneable, Principal , Serializable { public final static User SUPER USER = new User ( ) ;
private final String name;
/ / super −user constructor private User ( ) { name = ”” ; }
public User( String name ) { i f ( name == null | | name.length() == 0 ) { throw new IllegalArgumentException () ; }
t h i s . name = name ; // since String is immutable }
public String getName() { return name ; // since String is immutable }
@Override public String toString() { return ”User(” + name + ”)”; }
@Override public i n t hashCode ( ) { return name.hashCode() ; }
@Override public boolean equals( Object obj ) { return obj instanceof User && ((User)obj).name.equals( name ); // since User is final } 137
} Listing C.2: User.java
// $Id: RidiculouslyInsecureLoginModule.java 35399 2007−02−19 16:49:30Z p s e v i n c $ package ch.ethz. zisc .docsec.authentication; import java . io . ∗ ; import java . u t i l . ∗ ; import java.security . ∗ ; import javax.security.auth. ∗ ; import javax.security.auth.callback . ∗ ; import javax.security.auth.login. ∗ ; import javax.security.auth.spi. ∗ ;
/ ∗ ∗ ∗ Copyright 2007 Paul E. Sevinc , Zurich Information Security Center ∗ ∗ @author Paul E. Sevinç ∗ @version $Rev : 35399 $ , $Date : 2007−02−19 17:49:30 +0100 (Mo, 19 Feb 2007) $ ∗ / public class RidiculouslyInsecureLoginModule implements LoginModule { private CallbackHandler callbackHandler = null ; private Principal role = null ; private Principal user = null ; private Subject subject = null ;
public void initialize( Subject subject , CallbackHandler callbackHandler , Map ignored , Map ignoredToo ) { assert subject != null ;
t h i s .subject = subject; t h i s .callbackHandler = callbackHandler; }
public boolean login ( ) throws LoginException { i f ( callbackHandler == null ) { throw new LoginException( ”RidiculouslyInsecureLoginModule r e q u i r e s a c a l l b a c k handler.” ); 138
}
t r y { Callback[] callbacks = new Callback[ 3 ]; callbacks[ 0 ] = new TextOutputCallback( TextOutputCallback .WARNING, ”This login module i s ridiculously insecure!” ); callbacks[ 1 ] = new NameCallback( ”Please enter a r o l e name ( r o l e ID).”); callbacks[ 2 ] = new NameCallback( ”Please enter a user name ( user ID).”); callbackHandler.handle( callbacks ); String roleID = ((NameCallback)callbacks[ 1 ]) .getName() ; String userID = ((NameCallback)callbacks[ 2 ]) .getName() ; i f ( roleID == null | | userID == null ) { throw new FailedLoginException( ”Logging In Has Failed ” ) ; } r o l e = new Role( roleID ); user = new User( userID ); return true ; } catch ( IOException ioe ) { throw new LoginException( ioe.getMessage() ); } catch ( UnsupportedCallbackException uce ) { throw new LoginException( uce.getMessage() ); } }
public boolean commit ( ) throws LoginException { i f ( r o l e == null | | user == null ) { return false ; }
Set principals = subject.getPrincipals(); principals.add( role ); principals.add( user ); return true ; }
public boolean abort ( ) throws LoginException { i f ( r o l e == null | | user == null ) { return false ; } 139
r o l e = null ; user = null ; return true ; }
public boolean logout ( ) throws LoginException { i f ( r o l e == null | | user == null ) { throw new LoginException( ”Logging In Had Failed ” ) ; }
/ ∗ ∗ According to http :// java .sun.com/javase /6/docs/guide/ security / jaas /JAASLMDevGuide.html we would only have to worry about the subject being read −only if we had added credentials to it. ∗ /
Set principals = subject.getPrincipals(); principals.remove( role ); principals.remove( user ); r o l e = null ; user = null ; return true ; } } Listing C.3: RidiculouslyInsecureLoginModule.java
// $Id: SwingCallbackHandler.java 35399 2007−02−19 16:49:30Z psevinc $ package ch.ethz. zisc .docsec.authentication; import java . awt . ∗ ; import java . io . ∗ ; import javax.security.auth.callback . ∗ ; import javax .swing. ∗ ;
/ ∗ ∗ ∗ Copyright 2007 Paul E. Sevinc , Zurich Information Security Center ∗ ∗ @author Paul E. Sevinç ∗ @version $Rev : 35399 $ , $Date : 2007−02−19 17:49:30 +0100 (Mo, 19 Feb 2007) $ ∗ / public class SwingCallbackHandler 140
implements CallbackHandler { private final JFrame parentFrame;
public SwingCallbackHandler( JFrame parentFrame ) { t h i s .parentFrame = parentFrame; }
public void handle( Callback[] callbacks ) throws IOException , UnsupportedCallbackException { for ( i n t i = 0 ; i < callbacks.length; ++i ) { i f ( callbacks[ i ] instanceof TextOutputCallback ) { TextOutputCallback toc = (TextOutputCallback)callbacks[ i ]; switch ( toc.getMessageType() ) { case TextOutputCallback .ERROR: JOptionPane .showMessageDialog( parentFrame , toc.getMessage() , ””, JOptionPane.ERROR MESSAGE ); break ; case TextOutputCallback .INFORMATION: JOptionPane .showMessageDialog( parentFrame , toc.getMessage() , ””, JOptionPane .INFORMATION MESSAGE ) ; break ; case TextOutputCallback .WARNING: JOptionPane .showMessageDialog( parentFrame , toc.getMessage() , ””, JOptionPane .WARNING MESSAGE ) ; break ; default : throw new IOException( ”Unsupported message type : ” + toc.getMessageType() ); } } else i f ( callbacks[ i ] instanceof NameCallback ) { NameCallback nc = (NameCallback)callbacks[ i ]; nc.setName( JOptionPane.showInputDialog( parentFrame , nc.getPrompt() , ”” , JOptionPane.QUESTION MESSAGE ) ) ; } else i f ( callbacks[ i ] instanceof PasswordCallback ) { PasswordCallback pc = (PasswordCallback)callbacks[ i ]; JPasswordField passwordField = new JPasswordField( 16 ); i f ( pc.isEchoOn() ) { passwordField.setEchoChar( ( char ) 0 ) ; 141
} JPanel passwordPane = new JPanel ( new GridLayout( 2, 1 ) ); passwordPane .add( new JLabel( pc.getPrompt() ) ); passwordPane.add( passwordField ) ; i f ( JOptionPane.showOptionDialog( parentFrame , passwordPane, ””, JOptionPane.OK CANCEL OPTION, JOptionPane . QUESTION MESSAGE, null , null , null ) == JOptionPane .OK OPTION ) { pc.setPassword( passwordField.getPassword() ) ; } else { pc.setPassword( null ); } char [] password = passwordField.getPassword() ; i f ( password != null ) { for ( i n t j = 0 ; j < password.length; ++j ) { password[ j ] = ( char ) 0 ; } } } else { throw new UnsupportedCallbackException( callbacks[ i ], ”Unsupported callback” ); } } } } Listing C.4: SwingCallbackHandler.java 142 References
[1] Adobe Systems. “PDF Reference: Version 1.6.” Published on the WWW. URL http://partners.adobe.com/public/developer/pdf/index_reference.html
[2] A. Anderson. “A Comparison of Two Privacy Policy Languages: EPAL and XACML.” Tech. Rep. TR-2005-147, Sun Microsystems Laboratories, September 2005.
[3] R. Anderson, M. Bond, J. Clulow, and S. Skorobogatov. “Cryptographic Processors – a survey.” Tech. Rep. 641, University of Cambridge, August 2005.
[4] K. Arnold, J. Gosling, and D. Holmes. The Java Programming Language. The Java Series. Addison Wesley Professional, 4th ed., 2006. ISBN 0321349806.
[5] M. Atallah and M. Bykova. “Portable and Flexible Document Access Control Mechanisms.” In P. Samarati, P. Ryan, D. Gollmann, and R. Molva (eds.), Proceedings of the 9th European Symposium on Research in Computer Security (ESORICS 2004), vol. 3193 of Lecture Notes in Computer Science, pp. 193–208. Springer-Verlag, September 2004.
[6] D. Basin, E.-R. Olderog, and P. E. Sevinç. “Specifying and Analyzing Security Automata using CSP-OZ.” In Proceedings of the 2007 ACM Conference on Computer and Communications Security (ASIACCS 2007). ACM Press, 2007.
[7] E. Bertino, B. Carminati, and E. Ferrari. “A Temporal author Management Scheme for Secure Broadcasting of XML Documents.” In V. Atluri (ed.), Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS 2002), pp. 31–40. November 2002.
[8] E. Bertino, B. Carminati, and E. Ferrari. “Access Control for XML documents and data.” In Information Security Technical Report, vol. 9, no. 3, pp. 19–34, July-September 2004.
[9] E. Bertino, B. Carminati, E. Ferrari, and G. Mella. “Author-χ – A System for Secure Dissemination and Update of XML Documents.” In N. Bianchi-Berthouze (ed.), Proceedings of the 3rd International Workshop on Databases in Networked Information Systems (DNIS 2003), vol. 2822 of Lecture Notes in Computer Science, pp. 66–85. Springer-Verlag, September 2003.
[10] E. Bertino, S. Castano, and E. Ferrari. “On Specifying Security Policies for Web Documents with an XML-based Language.” In Proceedings of the 6th ACM Symposium on Access Control Models and Technologies (SACMAT 2001), pp. 57–65. May 2001.
[11] E. Bertino, S. Castano, and E. Ferrari. “Securing XML Documents with Author-X.” In IEEE Internet Computing, vol. 5, no. 3, pp. 21–31, May/June 2001.
[12] E. Bertino, E. Ferrari, and L. Parasiliti Provenza. “Signature and Access Control Policies for XML Documents.” In E. Snekkenes and D. Gollmann (eds.), Proceedings of the 8th European Symposium on Research in Computer Security (ESORICS 2003), vol. 2808 of Lecture Notes in Computer Science, pp. 1–22. Springer-Verlag, October 2003.
143 144 REFERENCES
[13] E. Bertino and R. Sandhu. “Database Security—Concepts, Approaches, and Challenges.” In IEEE Transactions on Dependable and Secure Computing, vol. 2, no. 1, pp. 2–19, January-March 2005.
[14] C. Bettini, S. Jajodia, X. S. Wang, and D. Wijesekera. “Provisions and Obligations in Policy Rule Management.” In Journal of Network and Systems Management, vol. 11, no. 3, pp. 351–372, Septem- ber 2003.
[15] C. Bettini, S. Jajodia, X. S. Wang, and D. Wijesekera. “Reasoning with advanced policy rules and its application to access control.” In International Journal on Digital Libraries, vol. 4, no. 3, pp. 156–170, November 2004.
[16] M. Bishop. Computer Security: Art and Science. Addison Wesley Professional, 2003. ISBN 0201440997.
[17] L. Bouganim, F. Dang Ngoc, and P. Pucheral. “Client-based Access Control Management for XML Documents.” In W. Jonker and M. Petkovic´ (eds.), Proceedings of the Workshop on Secure Data Management in a Connected World (SDM 2004), vol. 3178 of Lecture Notes in Computer Science, pp. 84–95. Springer-Verlag, August 2004.
[18] J. Bowen. “Formal Specification and Documentation using Z: A Case Study Approach.” Published on the WWW. URL http://www.zuser.org/zbook/
[19] J. P. Bowen and M. G. Hinchey. “Ten Commandments of Formal Methods ... Ten Years Later.” In Computer, vol. 39, no. 1, pp. 40 – 48, January 2006.
[20] G. Bracha, J. Gosling, B. Joy, and G. Steele. The Java Language Specification. The Java Series. Addison Wesley Professional, 3rd ed., 2005. ISBN 0321246780.
[21] M. Bramer. Logic Programming with Prolog. Springer-Verlag, 2005. ISBN 1852339381.
[22] E. Brickell, J. Camenisch, and L. Chen. “Direct Anonymous Attestation.” In B. Pfitzmann and P. Liu (eds.), Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS 2004), pp. 132–145. ACM Press, 2004.
[23] B. Burke and R. Monson-Haefel. Enterprise JavaBeans 3.0. O’Reilly, 5th ed., 2006. ISBN 059600978X.
[24] M. Bykova and M. Atallah. “Succinct Specifications of Portable Document Access Policies.” In Proceedings of the 9th ACM Symposium on Access Control Models and Technologies (SACMAT 2004), pp. 41–50. June 2004.
[25] C. Caleiro, L. Vigano,` and D. Basin. “Deconstructing Alice and Bob.” In Proceedings of the Workshop on Automated Reasoning for Security Protocol Analysis (ARSPA 2005), vol. 135 of Electronic Notes in Theoretical Computer Science, pp. 3–22. July 2005.
[26] J. Camenisch. “Better Privacy for Trusted Computing Platforms.” In P. Samarati, P. Ryan, D. Goll- mann, and R. Molva (eds.), Proceedings of the 9th European Symposium on Research in Computer Se- curity (ESORICS 2004), vol. 3193 of Lecture Notes in Computer Science, pp. 73–88. Springer-Verlag, September 2004.
[27] S. Castano, M. Fugini, G. Martella, and P. Samarati. Database Security. ACM Press, 1995. ISBN 0201593750.
[28] S. Chow, P. Eisen, H. Johnson, and P. C. Van Oorschot. “White-Box Cryptography and an AES Implementation.” In K. Nyberg and H. Heys (eds.), Selected Areas in Cryptography: 9th Annual International Workshop (SAC 2002), vol. 2595 of Lecture Notes in Computer Science, pp. 250–270. Springer-Verlag, August 2003. REFERENCES 145
[29] S. Chow, P. Eisen, H. Johnson, and P. C. Van Oorschot. “A White-Box DES Implementation for DRM Applications.” In J. Feigenbaum (ed.), Digital Rights Management: ACM CCS-9 Workshop (DRM 2002), vol. 2696 of Lecture Notes in Computer Science, pp. 1–15. Springer-Verlag, November 2003.
[30] C. S. Collberg and C. Thomborson. “Watermarking, Tamper-Proofing, and Obfuscation-Tools for Software Protection.” In IEEE Transactions on Software Engineering, vol. 28, no. 8, pp. 735–746, August 2002.
[31] L. F. Cranor and S. Garfinkel (eds.). Security and Usability: Designing Secure Systems that People Can Use. O’Reilly, 2005. ISBN 0596008279.
[32] E. Damiani, S. De Capitani di Vimercati, S. Paraboschi, and P. Samarati. “A Fine-Grained Access Control System for XML Documents.” In ACM Transactions on Information and System Security, vol. 5, no. 2, pp. 169–202, May 2002.
[33] S. De Capitani di Vimercati, S. Paraboschi, and P. Samarati. “Access control: principles and solutions.” In Software: Practice and Experience, vol. 3, no. 5, pp. 397–421, April 2003.
[34] J. Derrick and E. Boiten. Refinement in Z and Object-Z. FACIT. Springer-Verlag, 2001. ISBN 185233245X.
[35] P. Devanbu, M. Gertz, A. Kwong, C. Martel, G. Nuckolls, and S. Stubblebine. “Flexible Authenti- cation of XML Documents.” In P. Samarati (ed.), Proceedings of the 8th ACM Conference on Computer and Communications Security (CCS 2001), pp. 136–145. November 2001.
[36] R. Duke and G. Rose. Formal Object-Oriented Specification Using Object-Z. Cornerstones of Com- puting. Macmillan Press, 2000. ISBN 0333801237.
[37] C. Eckert. IT-Sicherheit: Konzepte - Verfahren - Protokolle. Oldenbourg, 3rd ed., 2004. ISBN 3486200003.
[38] J. D. Eisenberg. OASIS OpenDocument Essentials. O’Reilly, 2006. To be published. URL http://books.evc-cit.info/
[39] W. Fan, C.-Y. Chan, and M. Garofalakis. “Secure XML Querying with Security Views.” In Proceed- ings of the 2004 ACM SIGMOD international conference on Management of data. 2004.
[40] N. Ferguson and B. Schneier. Practical Cryptography. Wiley Publishing, Inc., 2003. ISBN 0471223573.
[41] D. F. Ferraiolo, D. R. Kuhn, and R. Chandramouli. Role-Based Access Control. Artech House, 2003. ISBN 1580533701.
[42] C. Fischer. “CSP-OZ: a combination of Object-Z and CSP.” In Proc. 2nd IFIP Workshop on Formal Methods for Open Object-Based Distributed Systems (FMOODS), pp. 423–438. 1997.
[43] M. Fowler. UML Distilled. Addison Wesley Professional, 3rd ed., 2003. ISBN 0321193687.
[44] I. Fundulaki and M. Marx. “Specifying Access Control Policies for XML Documents with XPath.” In Proceedings of the 9th ACM Symposium on Access Control Models and Technologies (SACMAT 2004), pp. 61–69. June 2004.
[45] A. Gabillon. “An Authorization Model for XML DataBases.” In Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS 2004). 2004. 146 REFERENCES
[46] A. Gabillon. “A Formal Access Control Model for XML Databases.” In W. Jonker and M. Petkovic´ (eds.), Proceedings of the Workshop on Secure Data Management in a Connected World (SDM 2005), vol. 3674 of Lecture Notes in Computer Science, pp. 86–103. Springer-Verlag, September 2005.
[47] A. Gabillon and E. Bruno. “Regulating Access to XML Documents.” In Proceedings of the fifteenth annual working conference on Database and application security, pp. 299–314. 2001.
[48] A. Gabillon, M. Munier, J.-J. Bascou, L. Gallon, and E. Bruno. “An Access Control Model for Tree Data Structures.” In Proceedings of the 5th International Conference on Information Security, pp. 117–135. 2002.
[49] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object- Oriented Software. Addison Wesley Professional, 1995. ISBN 0201633612.
[50] H. Garcia-Molina, J. D. Ullman, and J. D. Widom. Database Systems: The Complete Book. Prentice Hall, 2002. ISBN 0130319953.
[51] S. Garfinkel, G. Spafford, and A. Schwartz. Practical UNIX and Internet Security. O’Reilly, 3rd ed., 2003. ISBN 0596003234.
[52] S. L. Garfinkel. Design Principles and Patterns for Computer Systems that are Simultaneously Secure and Usable. Ph.D. thesis, Massachusetts Institute of Technology, May 2005.
[53] D. Gollmann. Computer Security. Wiley, 2nd ed., 2006. ISBN 0470862939.
[54] L. Gong, G. Ellison, and M. Dageforde. Inside Java 2 Platform Security: Architecture, API Design, and Implementation. Java Series. Addison Wesley Professional, 2nd ed., 2003. ISBN 0201787911.
[55] V. Gowadia and C. Farkas. “RDF Metadata for XML Access Control.” In ACM Workshop on XML Security, pp. 31–48. 2003.
[56] V. Gowadia and C. Farkas. “Tree Automate for Schema-level Filtering of XML Associations.” In yada, yada, yada, pp. 136–145. 2005.
[57] M. G. Graff and K. R. van Wyk. Secure Coding: Principles & Practice. O’Reilly, 2003. ISBN 0596002424.
[58] D. Grawrock. The Intel Safer Computing Initiative. Intel Press, 2006. ISBN 0976483262.
[59] E. R. Harold and W. S. Means. XML in a Nutshell. O’Reilly, 3rd ed., 2004. ISBN 0596007647.
[60] M. Hilty, D. Basin, and A. Pretschner. “On Obligations.” In S. de Capitani di Vimercati, P. Syver- son, and D. Gollmann (eds.), Proceedings of the 10th European Symposium on Research in Computer Se- curity (ESORICS 2005), vol. 3679 of Lecture Notes in Computer Science, pp. 98–117. Springer-Verlag, September 2005.
[61] C. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. ISBN 0131532715.
[62] T. B. Hodel-Widmer and K. R. Dittrich. “Concept and prototype of a collaborative business process environment for document processing.” In Data & Knowledge Engineering, vol. 52, no. 1, pp. 61– 120, January 2005.
[63] G. Hoglund and G. McGraw. Exploiting Software: How to Break Code. Addison Wesley Professional, 2004. ISBN 0201786958.
[64] M. Howard and D. LeBlanc. Writing Secure Code. Microsoft Press, 2nd ed., 2003. ISBN 0735617228.
[65] M. Howard, D. LeBlanc, and J. Viega. 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. McGraw-Hill/Osborne, 2005. ISBN 0072260858. REFERENCES 147
[66] G.-H. Hwang and T.-K. Chang. “Document Security Language (DSL) V2.0.” URL http://www.xml-dsl.com/
[67] IBM Tokyo Research Laboratory. “XML Access Control Language (XACL).” Published on the WWW. URL http://www.trl.ibm.com/projects/xml/xacl/
[68] IBM Zurich Research Laboratory. “Enterprise Privacy Authorization Language (EPAL).” Pub- lished on the WWW. URL http://www.zurich.ibm.com/security/enterprise-privacy/epal/
[69] IBM Zurich Research Laboratory. “Enterprise Privacy Technologies.” Published on the WWW. URL http://www.zurich.ibm.com/security/enterprise-privacy/
[70] C. Ilioudis, G. Pangalos, and A. Vakali. “Security Model for XML data.” In Proceedings of the International Conference on Internet Computing, pp. 400–406. Las Vegas, June 2001.
[71] International Organization for Standardization. Information technology – Open Systems Interconnec- tion – Security frameworks for open systems: Access control framework, 1996. URL http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail? CSNUMBER=18199
[72] International Organization for Standardization. Information technology – Z formal specification notation – Syntax, type system and semantics, July 2002. URL http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail? CSNUMBER=21573
[73] J. Jacky. The Way of Z: Practical Programming with Formal Methods. Cambridge University Press, 1997. ISBN 0521550416.
[74] G. Karjoth, M. Schunter, and M. Waidner. “Platform for Enterprise Privacy Practices: Privacy- Enabled Management of Customer Data.” In R. Dingledine and P. Syverson (eds.), Privacy En- hancing Technologies, vol. 2482 of Lecture Notes in Computer Science, pp. 69–84. Springer-Verlag, 2003.
[75] M. H. Kay. “XML Five Years On: A Review of the Achievements So Far and the Challenges Ahead.” In Proceedings of the 2003 ACM symposium on Document engineering, pp. 29–31. Grenoble, November 2003.
[76] R. L. Kay. “This Ain’t Your Father’s Internet: How Hardware Security Will Become Nearly Ubiq- uitous as a Rock Solid Solution to Safeguarding Connected Computing.” Published on the WWW. URL http://www.ndpta.com/TPMForecast.html
[77] M. Kudo and S. Hada. “XML Document Security based on Provisional Authorization.” In Pro- ceedings of the 7th ACM Conference on Computer and Communications Security (CCS 2000), pp. 87–96. Athens, November 2000.
[78] E. Lenz, M. McRae, and S. St.Laurent. Office 2003 XML. O’Reilly, 2004. ISBN 0596005385.
[79] D. Lightfoot. Formal Specification Using Z. Grassroot Series. Palgrave, 2nd ed., 2001. ISBN 0333763270.
[80] A. H. Lin. Automated Analysis of Security APIs. Master’s thesis, Massachusetts Institute of Tech- nology, May 2005. URL http://theory.lcs.mit.edu/˜cis/cis-theses.html 148 REFERENCES
[81] B. Luo, D. Lee, W.-C. Lee, and P. Liu. “A Flexible Framework for Architecting XML Access Control Enforcement Mechanisms.” In W. Jonker and M. Petkovic´ (eds.), Proceedings of the Workshop on Secure Data Management in a Connected World (SDM 2004), vol. 3178 of Lecture Notes in Computer Science, pp. 133–147. Springer-Verlag, August 2004.
[82] J. Marchesini, S. W. Smith, O. Wild, A. Barsamian, and J. Stabiner. “Open-Source Applications of TCPA Hardware.” In Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC 2004), pp. 294–303. IEEE Computer Society, December 2004.
[83] J. Marchesini, S. W. Smith, O. Wild, and R. MacDonald. “Experimenting with TCPA/TCG Hard- ware, Or: How I Learned to Stop Worrying and Love The Bear.” Tech. Rep. Dartmouth TR2003- 476, Dartmouth College, December 2003.
[84] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone. Handbook of Applied Cryptography. CRC Press, 1996. ISBN 0849385237.
[85] Microsoft. “Office 2003 XML Reference Schemas.” Published on the WWW. URL http://www.microsoft.com/office/xml/default.mspx
[86] Microsoft. “Windows Vista Beta 2 Trusted Platform Module Services Step by Step Guide.” Published on the WWW. URL http://www.microsoft.com/technet/windowsvista/library/ 29201194-5e2b-46d0-9c77-d17c25c56af3.mspx
[87] C. Mitchell (ed.). Trusted Computing, vol. 6 of IEE Professional Applications of Computing. The Insti- tution of Electrical Engineers, 2005. ISBN 0863415253.
[88] A. Møller and M. Schwartzbach. An Introduction to XML and Web Technologies. Addison Wesley Professional, 2006. ISBN 0321269667.
[89] H. Mossenb¨ ock.¨ Objektorientierte Programmierung in Oberon-2. Springer-Verlag, 1998. ISBN 3540646493.
[90] M. Murata, A. Tozawa, and M. Kudo. “XML Access Control Using Static Analysis.” In Proceed- ings of the 10th ACM Conference on Computer and Communications Security (CCS 2003), pp. 73–84. Washington D.C., October 2003.
[91] M. Niezette´ and J.-M. Stevenne.´ “An Efficient Symbolic Representation of Periodic Time.” In Proceedings of the ISMM International Conference on Information and Knowledge Management (CIKM- 92), pp. 161–168. 1992.
[92] NIST CSRC. “Role Based Access Control.” Published on the WWW. URL http://csrc.nist.gov/rbac/
[93] OASIS. “eXtensible Access Control Markup Language (XACML).” Specification. URL http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
[94] OASIS. “Open Document Format for Office Applications (OpenDocument).” Specification. URL http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
[95] Object Management Group. “Unified Modeling Language Version 2.0.” OMG Specification. URL http://www.uml.org/
[96] OpenOffice.org. “OpenOffice.org XML File Format.” Published on the WWW. URL http://xml.openoffice.org/ REFERENCES 149
[97] J. Park and R. Sandhu. “The UCONABC Usage Control Model.” In ACM Transactions on Informa- tion and System Security, vol. 7, no. 1, pp. 128–174, February 2004.
[98] S. Pearson (ed.). Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall, 2003. ISBN 0130092207.
[99] PKWARE, Inc. “.ZIP File Format Specification.” Application Note. URL http://www.pkware.com/business_and_developers/developer/appnote/
[100] B. C. Popescu, B. Crispo, and A. S. Tanenbaum. “Support for Multi-Level Security Policies in DRM Architectures.” In Proceedings of the 2004 workshop on New security paradigms (NSPW 2004), pp. 3–9. ACM Press, New York, NY, USA, 2005.
[101] A. Pretschner, M. Hilty, and D. Basin. “Distributed Usage Control.” In Communications of the ACM, vol. 49, no. 9, pp. 39–44, September 2006.
[102] N. Qi and M. Kudo. “Access-Condition-Table-Driven Access Control for XML Databases.” In P. Samarati, P. Ryan, D. Gollmann, and R. Molva (eds.), Proceedings of the 9th European Symposium on Research in Computer Security (ESORICS 2004), vol. 3193 of Lecture Notes in Computer Science, pp. 17–32. Springer-Verlag, September 2004.
[103] N. Qi and M. Kudo. “XML Access Control with Policy Matching Tree.” In Proceedings of the 10th European Symposium on Research in Computer Security (ESORICS 2005). 2005.
[104] J. Rihak. “Access Control Markup Languages for XML Documents.”, 2004. Semesterarbeit, ETH Zurich. URL http://www.infsec.ethz.ch/education/projects/archive/#XMLACMLs
[105] E. Roman, R. Patel Sriganesh, and G. Brose. Mastering Enterprise JavaBeans. Wiley, 3rd ed., 2004. ISBN 0764576828.
[106] J. Ruesch.¨ “A Web Services Implemntation of a Provisions Service.”, 2007. Semesterarbeit, ETH Zurich. URL http://www.infsec.ethz.ch/education/projects/archive/#WSPS
[107] R. Sailer, T. Jaeger, X. Zhang, and L. van Doorn. “Attestation-based Policy Enforcement for Remote Access.” In Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS 2004), pp. 308–307. October 2004.
[108] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. “Design and Implementation of a TCG-based Integrity Measurement Architecture.” In Proceedings of the 13th Usenix Security Symposium, pp. 223–238. August 2004.
[109] V. Samar. “Unified Login with Pluggable Authentication Modules (PAM).” In Proceedings of the 3rd ACM Conference on Computer and Communications Security (CCS 1996), pp. 1–10. ACM Press, New York, NY, USA, 1996.
[110] V. Samar and C. Lai. “Making Login Services Independent of Authentication Technologies.” Pub- lished on the WWW. URL http://www.sun.com/software/solaris/pam/pam.external.pdf
[111] R. Sandhu and X. Zhang. “Peer-to-Peer Access Control Architecture Using Trusted Computing Technology.” In Proceedings of the 10th ACM Symposium on Access Control Models and Technologies (SACMAT 2005), pp. 147–158. June 2005. 150 REFERENCES
[112] A. J. Seilen and R. H. R. Harper. The Myth of the Paperless Office. The MIT Press, 2001. ISBN 0262194643.
[113] P. E. Sevinçand D. Basin. “Controlling Access to Documents: A Formal Access Control Model.” Tech. Rep. 517, ETH Zurich, May 2006.
[114] P. E. Sevinç, D. Basin, and E.-R. Olderog. “Controlling Access to Documents: A Formal Access Control Model.” In G. Muller¨ (ed.), Proceedings of the 1st International Conference on Emerging Trends in Information and Communication Security (ETRICS 2006), vol. 3995 of Lecture Notes in Computer Science, pp. 352–367. Springer-Verlag, June 2006.
[115] B. Smith and B. Komar. Microsoft Windows Security Resource Kit. Microsoft Press, 2nd ed., 2005. ISBN 0735621748.
[116] G. Smith. The Object-Z Specification Language. Advances in Formal Methods. Kluwer Academic Publishers, 2000. ISBN 0792386841.
[117] S. W. Smith. Trusted Computing Platforms: Design and Applications. Springer-Verlag, 2005. ISBN 0387239162.
[118] J. Spivey. “The Z Notation: A Reference Manual.” Published on the WWW. URL http://spivey.oriel.ox.ac.uk/mike/zrm/index.html
[119] W. Stallings. Cryptography and Network Security. Prentice Hall, 4th ed., 2005. ISBN 0131873164.
[120] R. Steele, W. Gardner, T. S. Dillon, and A. Erradi. “XML-Based Declerative Access Control.” In SOFSEM 2005: Theory and Practice of Computer Science: 31st Conference on Current Trends in The- ory and Practice of Computer Science, vol. 3381 of Lecture Notes in Computer Science, pp. 310–319. Springer-Verlag, January 2005.
[121] D. R. Stinson. Cryptography: Theory and Practice. CRC Press, 3rd ed., 2005. ISBN 1584885084.
[122] M. Strasser. “A Software-based TPM Emulator for Linux.” Semesterarbeit, ETH Zurich, 2004. URL http://www.infsec.ethz.ch/education/projects/archive/#TPMEmulator
[123] Sun Microsystems. “DReaM.” URL https://dream.dev.java.net/
[124] Sun Microsystems. “JAR File Specification.” Application Note. URL http://java.sun.com/javase/6/docs/guide/jar/jar.html
[125] Sun Microsystems. “DReaM-CAS Client Specification.” Technical Specification, March 2006. Ver- sion 0.9c. URL https://dream.dev.java.net/
[126] Trusted Computing Group. “TCG Architecture Overview.” TCG Specification. URL https://www.trustedcomputinggroup.org/groups/TCG_1_0_Architecture_ Overview.pdf
[127] Trusted Computing Group. “TCG TPM Specification Version 1.2.” TCG Specification. URL https://www.trustedcomputinggroup.org/specs/TPM
[128] J. Van Tassel. Digital Rights Management: Protecting and Monetizing Content. NAB Executive Tech- nology Briefings. Focal Press, 2006. ISBN 0240807227.
[129] J. Viega and G. McGraw. Building Secure Software. Addison Wesley Professional, 2002. ISBN 020172152X. REFERENCES 151
[130] J. Viega and M. Messier. Secure Programming Cookbook. O’Reilly, 2003. ISBN 0596003943.
[131] W3C (World Wide Web Consortium). “Document Object Model (DOM) Level 3 Core Specifica- tion.” W3C Recommendation. URL http://www.w3.org/TR/DOM-Level-3-Core/
[132] W3C (World Wide Web Consortium). “Extensible HyperText Markup Language (XHTML).” W3C Recommendation. URL http://www.w3.org/MarkUp/
[133] W3C (World Wide Web Consortium). “Extensible Markup Language (XML).” W3C Recommen- dation. URL http://www.w3c.org/XML/
[134] W3C (World Wide Web Consortium). “XML Encryption.” W3C Recommendation. URL http://www.w3.org/Encryption/2001/
[135] W3C (World Wide Web Consortium). “XML Path Language (XPath).” W3C Recommendation. URL http://www.w3.org/TR/xpath
[136] W3C (World Wide Web Consortium). “XML Schema.” W3C Recommendation. URL http://www.w3.org/XML/Schema
[137] W3C (World Wide Web Consortium). “XML Signature.” W3C Recommendation. URL http://www.w3.org/Signature/
[138] W3C (World Wide Web Consortium). “XSL Transformations (XSLT).” W3C Recommendation. URL http://www.w3.org/TR/xslt
[139] Wikipedia. “FairPlay.” Wikipedia Article. URL http://en.wikipedia.org/wiki/FairPlay
[140] J. Woodcock and J. Davies. “Using Z: Specification, Refinement, and Proof.” Published on the WWW. URL http://www.usingz.com/
[141] C. A. Zehnder. Informationssysteme und Datenbanken. vdf Hochschulverlag, 6th ed., 1998. ISBN 3728120197.
[142] W. Zeng, H. Yu, and C.-Y. Lin (eds.). Multimedia Security Technologies for Digital Rights Management. Academic Press, 2006. ISBN 0123694760.
[143] X. Zhang, F. Parisi-Presicce, R. Sandhu, and J. Park. “Formal Model and Policy Specification of Usage Control.” In ACM Transactions on Information and System Security, vol. 8, no. 4, pp. 351–387, November 2005.
[144] X. Zhang, J. Park, and R. Sandhu. “Schema Based XML Security: RBAC Approach.” In Proceedings of the 17th Annual IFIP WG 11.3 Working Conference on Data and Applications Security. August 2003.
[145] T. Zweifel. Trusted Knoppix. Master’s thesis, ETH Zurich, March 2006. URL http://www.infsec.ethz.ch/education/projects/archive/ #TrustedKnoppix 152 REFERENCES CURRICULUM VITAE
Member of the ACM and the IEEE Computer Society
EDUCATION • ETH Zurich: Dr. sc. ETH January 2003 - March 2007 Doctoral thesis, Information Security Group: Securing Information by Controlling Access to Data in Documents • ETH Zurich: Dipl. El.-Ing. ETH October 1995 - March 2000 Master’s thesis, EPFL: Design Patterns for the Management of IP Networks Semester project, Institute of Theoretical Computer Science: Encryption of Data: an interactive teaching module for the WWW Semester project, Computer Engineering and Networks Laboratory: A Framework for Multiobjective Optimization with Genetic Algorithms Exchange student at the EPFL Winter Semester 1999/2000 • Kantonsschule am Burggraben St. Gallen (KSBG): Matura August 1990 - January 1995 Exchange student at College` Voltaire, Geneva February - July 1993
PRACTICAL EXPERIENCE • Assistant in computer science, ETH Zurich January 2003 - March 2007 • Software engineer, ELCA Informatique SA July 2001 - December 2002 • Software engineer, Trilogy Software, Inc. January - June 2001 • Software engineer, Teamup AG July - December 2000 • Regular contributor to MacTech Magazine 1999 - 2001 • Intern, Ubilab (former IT research lab of UBS AG) Summer of 1998 • Medic, Swiss Army 1995 - 2005 • Swimming coach, Schwimm-Club Wittenbach 1991 - 2001
PROGRAMMING SKILLS • Declarative (functional and logic) and imperative (procedural and object-oriented) programming • Java Platform and Mac OS X • Web technologies and XML
LANGUAGES • (Swiss) German and Syriac/Aramaic (my mother-tongues) • French and English (both fluent) • Italian