1. Government Policy on Trusted Computing and Digital Rights Management a view from New Zealand Prof. Clark Thomborson 7 th April 2007

2. TC/DRM Policy 7 Apr 07 2 Outline An operational theory of trust. Hierarchies, bridges, and peerages. Problems of legitimation and enforcement. Governmental and corporate Digital Rights Management (DRM). Distinguishing Enterprise Content Management (ECM) from DRM. New Zealand’s policy: Four principles for Trusted Computing (TC) and DRM in e-government Revision of copyright law for digital works Desirable and feasible technical systems ECM: Emphasis should be on integrity and availability, not on license enforcement for copyright content (DRM). Trusted Computing: Emphasis should be on audit and assurance. Relationship Management: support for hierarchical, bridging, and peering trust with diverse systems and individuals. A broad consortium should define purchase requirements for digital security, with emphasis on interoperability via open standards. Progress at the Jericho Forum. My goal: an audit standard for ECM/TC, perhaps through ISO.

3. TC/DRM Policy 7 Apr 07 3 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.

4. TC/DRM Policy 7 Apr 07 4 Privilege 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 Policy 7 Apr 07 5 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”!

6. TC/DRM Policy 7 Apr 07 6 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 & trusted routing

7. TC/DRM Policy 7 Apr 07 7 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?

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

9. TC/DRM Policy 7 Apr 07 9 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.

10. TC/DRM Policy 7 Apr 07 10 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

11. TC/DRM Policy 7 Apr 07 11 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 When an agent takes on a secondary goal, or accepts a different set of constraints, they create an actor with a new “persona”. C, acting as an employee C, acting as a hotmail client

12. TC/DRM Policy 7 Apr 07 12 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 Most workflow systems have rigid personae definitions (= role assignments). Current operating systems offer very little support for bridges. Important future work! C, acting as an employee C, acting as a purchaser Employee V

13. TC/DRM Policy 7 Apr 07 13 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.

14. TC/DRM Policy 7 Apr 07 14 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. Equality of privilege is the default in a peerage, whereas inequality of privilege is the default in a hierarchy. Facilitator, Moderator, Democratic Leader, … Peers, Group members, Citizens of an ideal democracy, …

15. TC/DRM Policy 7 Apr 07 15 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 -- 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. Trusting decisions in a hierarchy are made by its most powerful members. Ultimately, all hierarchical trust is rooted in the King.

16. TC/DRM Policy 7 Apr 07 16 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.

17. TC/DRM Policy 7 Apr 07 17 Secure Bridges, Diverse Systems Orange-book security is well-defined for hierarchical systems. The hierarch governs the hierarchy: specification, implementation and assurance are under a single locus of control. A single military or secret-service agency is a strict hierarchy. We need trusted bridges between systems with disparate security goals if we want to build a trustworthy international communication system. A general-purpose TC OS will help us manage our hierarchical, bridging, and peering relationships. We must reveal our relationships to our OS! Trust is required... A general-purpose relationship management system will support a trustworthy ECM system. The donor trusts the recipient to manage “their” documents. Contractual agreements are required for ECM relationships. A legitimated TC might support a DRM system. The licensees must accept the control regime required by the licensors.

18. TC/DRM Policy 7 Apr 07 18 A Legitimised Hierarchy Auditor IG2IG1 OS Root Administrator Users Chair of User Assurance Group Inspector-General (an elected officer) 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.

19. TC/DRM Policy 7 Apr 07 19 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!

20. TC/DRM Policy 7 Apr 07 20 A Grand Project 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, ECM, 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 is already developing buyer’s requirements for information security in large multinational corporations. Jericho is not a standards organisation, and it’s not focussed on TC. One possibility: convene another forum in the Open Group. This would make it easy to cooperate with the Jericho Forum and other relevant fora.

21. TC/DRM Policy 7 Apr 07 21 Some Members of Jericho

22. TC/DRM Policy 7 Apr 07 22 Static Security for Corporate/Gov’t ECM: a first-draft proposal Static security: confidentiality, integrity, and availability. (CIA) Internally-authored documents fall in three categories:  Integrity first: internal correspondence. Agency (or corporate division)- confidential by default, but keys are shared widely within the agency to ensure ready availability.  Integrity and availability first: operational data, e.g. citizen (or customer) records. Agency-confidential except in cases where privacy laws or expectations require finer-grain protection. Provisions for ‘bridging trust’ allow efficient data sharing between agencies, where appropriate.  Rarely: highly sensitive data, such as state (or corporate) secrets, requiring narrowly controlled access within the agency. Three categories of externally-authored documents:  Integrity first: unsigned objects, e.g. downloads from the web.  Integrity and availability first: signed objects, e.g. contracts, tax returns.  Rarely: objects whose confidentiality is controlled by an external party, e.g. licensed software and media. We should design ECM systems to handle the I = A > C case. We must handle the usual cases efficiently. Copyright license enforcement (DRM) is not a primary task of ECM.

23. TC/DRM Policy 7 Apr 07 23 Dynamic Security The system processes of dynamic security support the system properties of static security. I think my distinction between the static, dynamic, governance layers of security is a novel taxonomic structure. Please let me know if you find it useful, or if you find some defect or improvement. Please let me know if you find relevant prior art. A competent security engineer will... Seal the most important security perimeters with an Authenticating gold veneer, Sprinkle Auditing gold-dust uniformly but very sparingly over the most important security areas, and Place an Authorising golden seal on the most important accesses. Gold is expensive – use it sparingly!! Authenticating people is very expensive. ECM, when based on delegated authority over documents, will be much less expensive than DRM based on license enforcement.

24. TC/DRM Policy 7 Apr 07 24 Security Governance Governors should constantly be asking questions, considering the answers, and revising plans. Good governance is pro-active, not reactive. 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 DRM systems in ECM applications were the result of poorly-conceived specifications, overly-ambitious implementations, and scant attention to assurance. 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?

25. TC/DRM Policy 7 Apr 07 25 New Zealand’s Principles for DRM and TC in e-Government Last year, the New Zealand Parliament adopted a set of principles and policies for the use of trusted computing and DRM in its operations. http://www.e.govt.nz/policy/tc-and-drm/principles-policies-06/tc-drm-0906.pdf  “For as long as it has any business or statutory requirements to do so, government must be able to: use the information it owns/holds; provide access to its information to others, when they are entitled to access it.” I think other sovereign governments will require a similar assurance. All governmental documents must have high availability and integrity: ECM. Some governmental documents are highly confidential, requiring special- purpose DRM systems under single-agency control. Key control is a primary vulnerability in ECM (and in DRM). To mitigate this vulnerability, I would advise governmental agencies to separate their key-management systems from their ECM systems. System interfaces should conform to an open standard, so that there can be secondary vendors and a feasible transition plan to a secondary vendor.

26. TC/DRM Policy 7 Apr 07 26 NZ e-Government Principle #2  “Government use of trusted computing and digital rights management technologies must not compromise the privacy rights accorded to individuals who use government systems, or about whom the government holds information.” This principle may be technically infeasible. Can a standardised TC/DRM technology support our diverse privacy requirements? Can a privacy-preserving TC/DRM satisfy our diverse requirements for law enforcement and national security? I have heard that telecommunication switches in the USA must support three independent wiretaps. I would model this as a 4-wide peerage in control of the telco’s switch. Should our TC/DRMs have 3 trapdoors? Privacy goal of a secure TC/DRM system: all trapdoor use is legitimate. Legitimation is a more general goal than privacy. The users of an unlegitimated trusted system will be distressed, and may avoid or even subvert the system.

27. TC/DRM Policy 7 Apr 07 27 NZ e-Government Principle #3  “The use of trusted computing and digital rights management technologies must not endanger the integrity of government-held information, or the privacy of personal information, by permitting information to enter or leave government systems, or be amended while within them, without prior government awareness and explicit consent.” All sovereign governments, and all corporations, have similar requirements for high integrity, confidentiality at the perimeter, and legitimation. Technical analysis: These requirements cannot be achieved with a closed-source DRM system on an unauditable TC platform. This is ECM: documents entering a governmental (or corporate) security boundary must be “owned” by the receiving agency, so they can be fully managed by a local rights server. This is not DRM, indeed I think strong controls (e.g. a manager’s explicit consent) should be placed on any individual’s importation of non-owned documents and objects. Each importation is a threat to system confidentiality, and imported documents may be subject to amendment.

28. TC/DRM Policy 7 Apr 07 28 NZ e-Government Principle #4  “The security of government systems and information must not be undermined by use of trusted computing and digital rights management technologies.” Each principle is supported by policies. In this case: “Agencies will reject the use of TC/DRM mechanisms, and information encumbered with externally imposed digital restrictions, unless they are able to satisfy themselves that the communications and information are free of harmful content, such as worms and viruses.” Is this the “killer app” for the NZ principles? This requirement is surprisingly difficult to achieve, in current TC/DRM technology. It much easier in TC/ECM. I believe the e-Government unit has rendered an important service to the international community by identifying and publicising this security issue with DRM. I think other governments will give similar advice to their agencies. Why not incorporate this into an ISO standard?

29. TC/DRM Policy 7 Apr 07 29 Why Malware Scans are Problematic in TC/DRM An infected document may have been encrypted at a time when its malware payload is not detectable. An infected document may be opened at any time in the future. Non-owned documents can only be scanned on computers that are trusted by the licensor. DRM: Document access is controlled by the licensor, even when the licensee possesses a digital copy. A difficult requirement: malware scanners need efficient and unrestricted access to the DRM keystores. This will be expensive, and may not be allowed by the license contract. License contracts might contain suitable assurances against malware, to mitigate the risk of accessing an unscanned document. I would advise corporations against signing DRM license agreements which indemnify licensors against loss due to malware in the licensed object.

30. TC/DRM Policy 7 Apr 07 30 Malware Scans are Easier in ECM Owned documents can be scanned for malware, on any computer platform that is owned (and trusted) by the recipient. In ECM systems, all documents are controlled by the recipient. Recipient computers can have full administrative rights over the document. The donor trusts the recipient to observe the terms of their ECM contractual agreement. The recipient may be under an obligation to maintain a tamper- evident audit of accesses. There can be no requirement on the recipient to obtain donor permission to open a document. This would be DRM. The donor’s trust allows the recipient to run efficient, offline, and effective malware scans. The trustworthy recipient will not abuse this trust.

31. TC/DRM Policy 7 Apr 07 31 The DRM/Copyright Puzzle DRM is a much harder problem than ECM. ECM, as sketched in this presentation, is based on documents being fully in the control of the possessor. The donor must relinquish technical control. The donor retains legal control, primarily through contract law, but also through copyright and government regulation (e.g. NZ’s Privacy Act). The donor retains social and economic control. Primary role of government: regulator of commerce. DRM, as sketched in this presentation, is based on documents remaining in the control of the licensor. The licensor of a digitized document must trust the recipient’s computer. The licensor retains technical control over their documents essentially by controlling the licensee’s computer, thereby rendering this computer less trustworthy from the licensee’s perspective. The licensed content may be stored on a computer that is owned (and controlled) by someone other than the licensor: a security risk. Roles of government: rewriting, reinterpreting, and enforcing copyright law; regulating commerce in copyright licenses; mediating disputes over the control and use of a trusted computer (licensor v licensee v owner).

32. TC/DRM Policy 7 Apr 07 32 Acknowledgements & Sources Privilege and Trust, LOCKix: Richard O'Brien, Clyde Rogers, “Developing Applications on LOCK”, 1991. Trust and Power: Niklas Luhmann, 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. www.jerichoforum.org

33. TC/DRM Policy 7 Apr 07 33 Three Questions Will you help me work toward a series of ISO (or other) standards, specifying TC, ECM, and relationship management systems which would be trustworthy and useful for diverse organisations and people from a very wide range of cultures, and which are feasibly and economically implementable? Do you agree that the NZ principles provide an excellent starting point for these standards? I am also working from the “Jericho Commandments”, its other whitepapers, and its privileged communications. Will you help me form a broadly-representative and trustworthy user’s group, who will elect auditors to assure the compliance of trusted (semi-secret) systems? Governance is specification, implementation, and assurance. Governors cannot outsource all their responsibilities, but they can safely delegate their responsibilities to trustworthy entities. TC/ECM systems are extremely expensive. We must collaborate if we want them to be affordable, interoperable, and trustworthy.