1. An Appropriate Design for Trusted Computing and Digital Rights Management Prof. Clark Thomborson 7 th April 2007

2. TC/DRM 7 Apr 07 2 Outline An operational theory of trust. Hierarchies, bridges, and peerages. Problems of legitimation and enforcement. Desirable and feasible technical systems Enterprise Content Management (ECM): Emphasis should be on integrity and availability. Trusted Computing (TC): Emphasis should be on audit and assurance. Relationship Management: support for hierarchical, bridging, and peering trust with diverse systems and individuals. Why Digital Rights Managment (DRM) is a difficult security problem for its governors.

3. TC/DRM 7 Apr 07 3 Trust, Trustworthiness, and Privilege When someone chooses to use a non-assured system, they are accepting risk – and therefore they are trusting the system. Trustworthiness (an assurance) implies that trust (a risk-aware basis for a decision) is well-placed. Increasing our trust is our only way to cope with the increasing complexity of modern life. [Luhmann, Trust & Power, Wiley 1979] In security engineering, a trusted flow of information is one that might violate the security goals of the system (if a user or administrator makes an error). A privileged flow of information will not violate the security goals. In this respect, “privilege” is the opposite of “trust”. [O'Brien & Rogers, “Developing Applications on LOCK”, 1991]. Secure systems, if they are to do anything useful, must have trusted flows.

4. TC/DRM 7 Apr 07 4 Privilege and Trust in a Hierarchy Information flows upwards, toward the most powerful actor (at the root). Commands and trust flow downwards. The King is the most privileged. The peons are the most trusted. King, President, Chief Justice, Pope, or … Peons, illegal immigrants, felons, excommunicants, or … Information flowing up is “privileged”. Information flowing down is “trusted”. Orange book TCSEC, e.g. LOCKix.

5. TC/DRM 7 Apr 07 5 Email in a Hierarchy that has a Goal of Confidentiality Information flows upwards, toward the leading actor.  Actors can send email to their superiors. Non-upwards email traffic is trusted: not allowed by default; should be filtered, audited, … King, President, Chief Justice, Pope, or … Peons, illegal immigrants, felons, excommunicants, or … Email up: “privileged” (allowed by default) Email down: “trusted” (disallowed by default, risking a loss of confidentiality) Email across: privileged & trusted routing

6. TC/DRM 7 Apr 07 6 Email across Hierarchies Q: How should we handle email between hierarchies? Company XAgency Y Answers:  Merge  Subsume  Bridge Merged X+Y Not often desirable or even feasible. Cryptography doesn’t protect X from Y, because the CEO/King of the merged company has the right to know all keys. Can an appropriate King(X+Y) be found?

7. TC/DRM 7 Apr 07 7 Email across Hierarchies Q: How can we manage email between hierarchies? Agency X Company Y Answers:  Merge  Subsume  Bridge

8. TC/DRM 7 Apr 07 8 Email across Hierarchies Q: How can we manage email between hierarchies? Company X Agency Y Answers:  Merge  Subsume  Bridge! Bridging connection: trusted in both directions.

9. TC/DRM 7 Apr 07 9 Bridging Trust We use “bridges” every time we send personal email from our work computer. We build a bridge by constructing a “bridging persona”. Even Kings can form bridges. However Kings are most likely to use an actual person, e.g. their personal secretary, rather than a bridging persona. Agency X Hotmail Bridging connection: bidirectional trusted. Used for all communication among an actor’s personae. C should encrypt all hotmail to avoid revelations. C, acting as a governmental agent C, acting as a hotmail client

10. TC/DRM 7 Apr 07 10 Personae, Actors, and Agents I use “actor” to refer to an agent (a human, or a computer program), pursuing a goal (risk vs. reward), subject to some constraints (social, technical, ethical, …) Actors can act on behalf of another actor: “agency”. In this part of the talk, we are considering agency relationships in a hierarchy. When an agent takes on a secondary goal, or accepts a secondary set of constraints, they create an actor with a new “persona”. Company X Hotmail C, acting as an employee C, acting as a hotmail client

11. TC/DRM 7 Apr 07 11 Peerages Information flows upwards by default (“privileged”). Commands and trust flow downwards. Downward information flows are “trusted” (filtered, audited, etc.) Facilitator, Moderator, Democratic Leader, … Peers, Group members, Citizens of an ideal democracy, …

12. TC/DRM 7 Apr 07 12 Peer trust vs. Hierarchical trust Trusting decisions in a peerage are made by peers, according to some fixed decision rule. There is no single root of peer trust. There are many possible decision rules, but simple majority and consensus are the most common. Weighted sums in a reputation scheme (e.g. eBay for goods, Poblano for documents) are a calculus of peer trust. “First come, first serve” (e.g. Wikipedia) is an appropriate decision rule, if the cost per serving is sufficiently low. The constitution of a peerage specifies its decision rule and its membership rules. Trusting decisions in a hierarchy are made by its most powerful members. Ultimately, all hierarchical trust is rooted in the King. A hierarchy does not need a constitution.

13. TC/DRM 7 Apr 07 13 Legitimation and enforcement Hierarchies have difficulty with legitimation. What happens if more than one person claims to be King? What happens if the King rules poorly? Peerages have difficulty with enforcement. What happens if a peer ignores the decisions of the peerage? What happens if a peer does not abide by the constitution? Can we use a peerage to legitimate a hierarchy, and a hierarchy to enforce a peerage? I am trying to specify a general-purpose trusted operating system with a well-defined assurance mechanism. There are other possible designs, because peerages are not the only means of legitimation. Legitimation will occur with the passage of time, if trust is not abused. So peers and hierarchs will gain trust in any computer system to which they grant privileges. In most communication and computation technologies we have a set of “de facto” standards, with a monopoly controlling their implementation and assurance. Is this appropriate for the world’s trusted computing?

14. TC/DRM 7 Apr 07 14 A Legitimised Hierarchy with an Empowered Peerage Auditor IG2IG1 TC Root Administrator TC Users Chair of User Assurance Group Inspector-General (an elected officer) Each user assurance group must develop its own Audit objectives (to assure their agreed security requirements). The OS Administrator may refuse to accept an Auditor, in which case the users should move to a different OS. The OS Administrator makes a Trusting appointment when granting auditor-level Privilege to one of the inspector-generals. The Auditor is the most privileged actor.

15. TC/DRM 7 Apr 07 15 Security Governance Responsibilities of the governors: Specification, or Policy (answering the question of what the system is supposed to do), Implementation (answering the question of how to make the system do what it is supposed to do), and Assurance (answering the question of whether the system is meeting its specifications). We’re still in the early stages of corporate ECM and TC. The monumental failures of early DRM systems (from InterTrust and MediaSnap) in ECM markets were the result of poor specifications and overly-ambitious implementations. Will the TC features of Vista or Red Hat Enterprise Linux 5 be useful in corporations? In e-government? Will it be easy to build trustworthy bridges between Vista and Linux? Technology is not the only option for implementation.

16. TC/DRM 7 Apr 07 16 Implementation Methods [adapted from Lessig’s theory] EasyDifficult Inexpensive Expensive Our technological architectures make things easy or difficult. LegalIllegal Our laws make things legal or illegal. Our economies make things inexpensive or expensive. Moral Immoral Our cultures make things moral or immoral.

17. TC/DRM 7 Apr 07 17 Secure Bridges, Diverse Systems Security is well-defined for hierarchical systems. The hierarch controls specification, implementation and assurance. Security is problematic for peerages, and in communications between hierarchies and peerages. Every peer, and every hierarch, has different security goals. If an organisation wants to communicate effectively with others, it must formalise its security goals in its own computer systems, it must reveal these security goals to communication partners when forming bridges, and it must trust these partners to respect these goals. If organisations restrict bridge formation excessively, they will not be able to communicate effectively. Some trust is necessary, otherwise no action is possible. If organisations do not impose any limits on bridge formation and use, they will be highly vulnerable to misplaced trust.

18. TC/DRM 7 Apr 07 18 An Appeal for Cooperation The New Zealand has specified four requirements on TC/DRM technology in e-government. See http://www.e.govt.nz/policy/tc-and-drm/principles- policies-06/tc-drm-0906.pdf.http://www.e.govt.nz/policy/tc-and-drm/principles- policies-06/tc-drm-0906.pdf These requirements can be met by a TC/ECM system, in which imported documents are in technical control of the recipient. In TC/DRM systems, the licensor has some control over the licensee’s computer. This is unacceptable to the NZ government, and it is worrisome for corporations and individuals. Other governments, and large corporations, have similar security requirements on TC and ECM. A broadly-constituted peer-assurance group would promote appropriate technologies, and it would allow us to build trustworthy bridges to other members of our group. I am trying to form a peer-assurance group. Will you help?