An Appropriate Design for Trusted Computing and Digital Rights Management

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

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 peeringtrust with diverse systems and individuals. • Why Digital Rights Managment (DRM) is a difficult security problem for its governors. 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. 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 trustflow 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. TC/DRM 7 Apr 07

5. Email in a Hierarchythat 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 & trustedrouting TC/DRM 7 Apr 07

6. Merged X+Y Email across Hierarchies Q: How should we handle email between hierarchies? Company X Agency Y Answers: • Merge • Subsume • Bridge • 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? TC/DRM 7 Apr 07

7. Email across Hierarchies Q: How can we manage email between hierarchies? Agency X Answers: • Merge • Subsume • Bridge Company Y 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. 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 C, acting as a governmental agent C, acting as a hotmail client • Bridging connection: bidirectional trusted. • Used for all communication among an actor’s personae. • C should encrypt all hotmail to avoid revelations. 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 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.) Peers, Group members, Citizens of an ideal democracy, … Facilitator, Moderator, Democratic Leader, … TC/DRM 7 Apr 07

12. Peer trust vs. Hierarchical trust • Trustingdecisions 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. • Trustingdecisions 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. 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? TC/DRM 7 Apr 07

14. A Legitimised Hierarchy with an Empowered Peerage • 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. TC Root Administrator Auditor TC Users Inspector-General (an elected officer) IG1 IG2 Chair of User Assurance Group 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. TC/DRM 7 Apr 07

16. Our laws make things legal or illegal. Legal Illegal Moral Inexpensive Expensive Immoral Our cultures make things moral or immoral. Easy Difficult Implementation Methods[adapted from Lessig’s theory] Our economies make things inexpensive or expensive. Our technological architectures make things easy or difficult. 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. 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. • 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? TC/DRM 7 Apr 07