An Appropriate Design for Trusted Computing and Digital Rights Management

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

2. Outline • An operational definition of “trust”. • Requirements analysis of e-government and corporate DRM (ECM) at three levels: static, dynamic, governance. • Evaluation of IRM v1.0 against these requirements. • Suggested design improvements • DRM: Emphasise integrity and availability, not confidentiality • TC: More support for audit • Relationship Management: support for hierarchical, bridging, and peering trust with other systems and individuals • Steps toward uniform “purchase requirements” with emphasis on interoperability and appropriate security. • In progress at the Jericho Forum. • Eventually: develop an appropriate audit standard for DRM, TC, and relationship management.

3. Trust and Privilege • We must develop operational definitions for these terms, if we wish to develop trustworthy computer systems.

4. Technical and non-technical definitions of Trust • In security engineering, placing trust in a system is a last resort. • It’s better to rely on an assurance (e.g. a proof, or a recourse mechanism), than on a trusting belief that “she’ll be right”. • In non-technical circles, trust is a good thing: more trust is generally considered to be better. • Trustworthiness (an assurance) implies that trust(a risk-aware basis for a decision) is well-placed. • A completely trustworthy system (in hindsight) is one that has never violated the trust placed in it by its users. • Just because some users trust a system, we cannot conclude that the system is trustworthy. • A rational and well-informed person can estimate the trustworthiness of a system. • Irrational or poorly-informed users will make poor decisions about whether or not, and under what circumstances, to trust a system.

5. Privilege 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.

6. Trustworthiness in a Hierarchy • Information flows upwards, toward the most powerful actor. • Commands and trust flow downwards. • Peons must be trusted with some information! • If the peons are not trustworthy, then the system is not secure. King, President, Chief Justice, Pope, or … Peons, illegal immigrants, felons, excommunicants, or … • If the King does not show good leadership (by issuing appropriate commands), then the system will not work well. “Noblesse oblige”!

7. Email in a Hierarchy • 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, risk to confidentiality) • Email across: privileged & trustedrouting

8. 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?

9. Email across Hierarchies Q: How can we manage email between hierarchies? Agency X Answers: • Merge • Subsume • Bridge Company Y

10. 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.

11. 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.

12. 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, …) • In Freudian terms: ego, id, superego. • Actors can act on behalf of another actor: “agency”. • In this part of the talk, we are considering agency relationships in a hierarchy. Company X Hotmail C, acting as an employee C, acting as a hotmail client • When an agent takes on a secondary goal, or accepts a different set of constraints, they create an actor with a new “persona”.

13. Bridging Trust: B2B e-commerce • Use case: employee C of X purchasing supplies through employee V of Y. • Employee C creates a hotmail account for a “purchasing” persona. • Purchaser C doesn’t know any irrelevant information. Company X Company Y Employee V C, acting as an employee C, acting as a purchaser • Most workflow systems have rigid personae definitions (= role assignments). • Current operating systems offer very little support for bridges. Important future work!

14. Why can’t we trust our leaders? • Commands and trust flow upwards (by majority vote, or by consensus). • Information flows downwards by default (“privileged”). • Upward information flows are “trusted” (filtered, audited, etc.) • In a peerage, the leading actors are trusted, have minimal privilege, don’t know very much, and can safely act on anything they know. “Our leaders are but trusted servants…” Peers • By contrast, the King of a hierarchy has an absolute right (“root” privilege) to know everything, is not trusted, and cannot act safely.

15. Turn the picture upside down! • Information flows upwards by default (“privileged”). • Commands and trust flow downwards. • Downward information flows are “trusted” (filtered, audited, etc.) • A peerage can be modeled by Bell-La Padula, because there is a partial order on the actors’ privileges. Peers, Group members, Citizens of an ideal democracy, … Facilitator, Moderator, Democratic Leader, … • Equality of privilege is the default in a peerage, whereas inequality of privilege is the default in a hierarchy.

16. 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 -- but “we” must all agree to abide by the scheme. • “First come, first serve” (e.g. Wiki) can be an appropriate decision rule, if the cost per serving is sufficiently low. • Trustingdecisions in a hierarchy are made by its most powerful members. • Ultimately, all hierarchical trust is rooted in the King.

17. Legitimation and enforcement • Hierarchies have difficulty with legitimation. • Why should I swear fealty (give ultimate privilege) to this would-be King? • Peerages have difficulty with enforcement. • How could the least privileged actor possibly be an effective facilitator? • This isn’t Political Science 101! • I will not try to model a government. It’s hard enough to build a model that will help us develop a better computer system! • I have tried to convince you that hierarchical trust is quite different to peer trust, that bridging trust is also distinct, and that all three forms are important in our world. • My thesis: Because our applications software will help us handle all three forms of trust, therefore our trusted operating systems should support all three forms.

18. Requirements for Relationship Management • Orange-book security is hierarchical. • This is a perfect match to a military or secret-service agency. • This is a poor match to e-government and corporate applications. • A general-purpose TC must support bridging and peering relationships. • Rights-management languages must support bridges and peerages, as well as hierarchies. • We cannot design an attractive, general purpose DRM system until we have designed the infrastructure properly!

19. Vapourware • Closed-source methodology is appropriate for designing hierarchical systems. • These systems have trouble with legitimation. • Why should a user trust that the system designers (and administrators) won’t abuse their privilege? • Open-source methodology is appropriate for designing peerage systems. • These systems have trouble with enforcement. • Why should anyone trust a user not to abuse their privilege? • Real-world peerages can legitimise hierarchies, and hierarchies can enforce peerages. • Can our next-generation OS use both design patterns?!?

20. A Legitimised Hierarchy • Each assurance group may want its own Audit (different scope, objectives, Trust, … ). • The OS Administrator may refuse to accept an Auditor. • The OS Administrator makes a Trusting appointment when granting auditor-level Privilege to a nominee. • Assurance organizations may be hierarchical, e.g. if the Users are governmental agencies or corporate divisions. OS Root Administrator Auditor Users Inspector-General (an elected officer) IG1 IG2 Chair of User Assurance Group

21. Summary of Static Trust • Three types of trust: hierarchical, bridging, peering. • Information flows are either trusted or privileged. • Hierarchical trust has been explored thoroughly in the Bell-La Padula model. • A subordinate actor is trusted to act appropriately, if a superior actor delegates some privileges. • Bell-La Padula, when the hierarchy is mostly concerned about confidentiality. • Biba, when the hierarchy is mostly concerned about integrity. • A general purpose TC OS must support all concerns of a hierarchy. • Actors have multiple personae. • Bridging trust connects all an actors’ personae. • A general purpose TC OS must support personae. • Peering trust is a shared decision to trust an actor who is inferior to the peers. • Peerages have trouble with enforcement; hierarchies have trouble with legitimation. • A trusted OS must be a legitimate enforcement agent!

22. Dynamic Trust and System Trust • When we join a hierarchy, form a bridge, or join a peerage, we make a trusting choice. • We also make trusting choices when we leave a hierarchy, dismantle a bridge, or resign from a peerage. • Hierarchies and peerages make trusting choices whenever they accept or reject a member. • A trusted operating system should assist us with making, and recording, these structural operations: dynamic trust. • Reputation systems could help us to make dynamic trust decisions, but they do not help us record these decisions. • Current workflow systems have very little support for dynamic trust. • System trust could be measured by our level of confidence in predicting the future behaviour of a hierarchical or peering system.

23. My Goals • I am trying to convene a broadly-representative group of purchasers to act as “our” governance body. • Large corporations and governmental agencies have similar requirements for interoperability, auditability, static security, and multiple vendors. • A first goal: develop buyer’s requirements for TC, DRM, and relationship management. • International agreement and political “buy-in” is required if we are to have a system that is broadly acceptable. • Regulatory requirements, such as protection of individual privacy, must be addressed. • Law-enforcement and national-security requirements must also be addressed. • A second goal: develop a trustworthy auditing process. • The Jericho Forum has a congruent goal. • It is developing buyer’s requirements for information security in large multinational corporations. • However it is not a standards organisation, and it is not focussed on TC. • The Jericho Forum is defining “de-perimeterized security”.

24. Some Members of Jericho

25. Static Security for DRM • CIA: confidentiality, integrity, and availability. • The primary vulnerabilities are operational difficulties unrelated to DRM: • the link between a user and their platform (“shared” login, unattended, or stolen); • the link between the platform and the server (especially while roaming); • the links between a user and their workgroups (unstable). • Three categories of internally-authored documents. • I > A > C : internal correspondence. Author must be identified. Keys must be shared widely within the agency, to ensure high availability. Confidential within a workgroup and its line managers. Note: workgroups can cross corporate boundaries! • I = A > C : operational data, e.g. citizen (or customer) records. Accuracy is very important. Downtime is very expensive. Group-level confidentiality. • I = C > A : highly sensitive data, such as state (or corporate) secrets, requiring expensive, fine-grained DRM control. Very rare, except in secret-service or military agencies -- these are a very specialised market. • Three categories of externally-authored documents. • I > A > C : unsigned objects, e.g. downloads from the web. • I = A > C : signed objects, e.g. contracts, tax returns. • I = C > A : objects whose confidentiality is controlled by an external party, e.g. licensed software and media. Very rare. • Conclusion: we should design DRM systems to handle the I = A > C case, without increasing the operational difficulties of workplace computing.

26. Dynamic Security Requirements • The gold standard: Authentication, Authorisation, Audit. • Dynamic security is expensive. We must avoid “gold-plated” system design! Requirements: • Offline server: the user’s platform handles document-level authorisations. • Platforms only occasionally re-authenticate/re-authorise with the server: • once per week, and when the individual joins a new group. • Platforms hold a master-key with read authority for all group-level documents. • Platform credentials remain valid after a reboot or disconnect. • Almost all documents are individually-signed and group-encrypted. • The document includes a copy of the author’s signing certificate. • Audit trails must assure the completeness of key escrow (for availability) and user enrolment/disenrolment (for integrity and confidentiality). • All signing certificates, all group-master keys, and all other identity-management functions, must be handled through an open-standard interface to the DRM server. • These requirements are supportive of an I = A > C design. • Integrity is high, due to the auditable and standardized ID management; • Availability is high, even while roaming; • Confidentiality is moderate. It takes a week to revoke an authority, however most authority revocations are due to workgroup reassignments of trusted individuals.

27. Security Governance • Governance should be pro-active, not reactive. • Governors should constantly be asking questions, considering the answers, and revising plans: • 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). • The monumental failures of early DRM systems were the result of inadequate governance: • poorly-conceived specifications, • overly-ambitious implementations, and • scant attention to assurance when specifying.

28. Microsoft’s IRM v1.0 • Supported in Office 2003 for email and attachments. • All protected documents are encrypted with individual, symmetric, keys. • High confidentiality, due to fine-grained control on read authorities. • Good integrity: high content integrity, linkage of authorship to group membership (corporate position) will be difficult, and platform integrity is compromised. • Rights-management information is held in the document meta-data. • Keys are held at a server, and are released to workstations. Workstations hold recently-used keys in a cache. • Low availability, especially when roaming. • This is a C > I > A design. • It would be suitable for a secretive organisation which decides to trust the IRM server: an unlikely case. • It is not a good match to the corporate and general-government market.

29. Assessment of IRM v1.0 with TC, for Corporate DRM • Microsoft’s C = I > A design is a poor match to I = A > C. • Availability could be improved with an independent key escrow, and a rights-management protocol which conforms to an open standard. • An I = A > C design would allow platforms and users to access almost all documents after a persistent session-login with the server. • The fine-grained DRM control in IRM v1.0 is a “gold-plated” authorisation design. • Agency-level keys to encrypt most documents. • Agency-level signatures are enough to assure integrity of most documents. • Poor audit provisions of the IRM v1.0 server: • Key management is not exposed through an open-standard interface. • Identity and relationship management is not exposed through an open-standard interface. Relationship management across corporate boundaries will be problematic. • Owners must be able to audit all TC and DRM activity. • IRM v1.0 audit feature: • A record of first-time document accesses could be useful when an employee is under suspicion. • A record of document accesses could be collected on a trustworthy platform... but don’t lose the trust of the user! The platform owner must assure them, with control and audit.

30. Malware Scans in TC/DRM • An infected document may have been encrypted before its malware payload is recognisable by a scanner. • An infected document may be opened at any time in the future. • Adding a comprehensive, online, malware scan would significantly increase the multi-second latency of a first-time access in IRM v1.0. • Third-party malware scans are problematic in a security-hardened kernel. • The scanner must be highly privileged and trustworthy.

31. Summary • There are three types of operational trust: hierarchical, bridging, peering. • A hierarchical system can be legitimated by a peerage. • A peering system can be enforced by a hierarchy. • I am trying to convene a broadly-representative group of purchasers to act as “our” governance body for Trusted Computing and Digital Rights Management. • Large corporations and governmental agencies have similar requirements for interoperability, auditability, static security, and multiple vendors. • The Jericho Forum is developing buyer’s requirements for information security in large multinational corporations, but it is not a standards organisation and it is not focussed on TC and DRM. • Goals: develop an audit standard and a trustworthy auditing process.

32. Acknowledgements & Sources • Privilege and Trust, LOCKix: Richard O'Brien, Clyde Rogers, “Developing Applications on LOCK”, 1991. • Trust and Power: NiklasLuhmann, Wiley, 1979. • Personae: Jihong Li, “A Fifth Generation Messaging System”, 2002; and Shelly Mutu-Grigg, “Examining Fifth Generation Messaging Systems”, 2003. • Use case (WTC): Qiang Dong, “Workflow Simulation for International Trade”, 2002. • Use case (P2P): Benjamin Lai, “Trust in Online Trading Systems”, 2004. • Use case (ADLS): Matt Barrett, “Using NGSCB to Mitigate Existing Software Threats”, 2005. • Use case (SOEI): Jinho Lee, “A survey-based analysis of HIPAA security requirements”, 2006. • Trusted OS: Matt Barrett, “Towards an Open Trusted Computing Framework”, 2005; and Thomborson and Barrett, “Governance of Trusted Computing”, ITG 06, Auckland. • White papers and privileged communications in the Jericho Forum, www.jerichoforum.org.