Government Policy on Trusted Computing and Digital Rights Management a view from New Zealand Prof. Clark Thomborson 7th April 2007 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. TC/DRM Policy 7 Apr 07 2 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. TC/DRM Policy 7 Apr 07 3 Privilege in a Hierarchy Information flows King, President, Chief upwards, toward the Justice, Pope, or … most powerful actor (at the root). Commands and trust flow downwards. The King is the most Peons, illegal immigrants, felons, privileged. excommunicants, or … The peons are the Information flowing up is most trusted. “privileged”. Information flowing down is “trusted”. Orange book TCSEC, e.g. LOCKix. TC/DRM Policy 7 Apr 07 4 Trustworthiness in a Hierarchy Information flows King, President, Chief upwards, toward the Justice, Pope, or … most powerful actor. Commands and trust flow downwards. Peons must be trusted with some information! Peons, illegal immigrants, felons, excommunicants, or … If the peons are not trustworthy, then the If the King does not show good system is not secure. leadership (by issuing appropriate commands), then the system will not work well. “Noblesse oblige”! TC/DRM Policy 7 Apr 07 5 Email in a Hierarchy Information flows King, President, Chief upwards, toward Justice, Pope, or … the leading actor. Actors can send email to their superiors. Non-upwards email Peons, illegal immigrants, felons, excommunicants, or … traffic is trusted: not allowed by default; Email up: “privileged” (allowed by default) should be filtered, Email down: “trusted” (disallowed by audited, … default, risk to confidentiality) Email across: privileged & trusted routing TC/DRM Policy 7 Apr 07 6 Email across Hierarchies Q: How should we handle email Merged X+Y between hierarchies? Company X Agency Y Answers: 1. Merge 2. Subsume • Not often desirable or even feasible. 3. Bridge • 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 Policy 7 Apr 07 7 Email across Hierarchies Q: How can we manage email Agency X between hierarchies? Answers: Company Y 1. Merge 2. Subsume 3. Bridge TC/DRM Policy 7 Apr 07 8 Email across Hierarchies Q: How can we manage email Company X Agency Y between hierarchies? Answers: 1. Merge 2. Subsume • Bridging connection: trusted 3. Bridge! in both directions. TC/DRM Policy 7 Apr 07 9 Bridging Trust We use “bridges” every time we send personal Agency X Hotmail email from our work computer. We build a bridge by constructing a “bridging persona”. Even Kings can form bridges. C, acting as a C, acting as However Kings are governmental a hotmail most likely to use an agent client actual person, e.g. • Bridging connection: bidirectional trusted. their personal secretary, rather than a • Used for all communication among an bridging persona. actor’s personae. • C should encrypt all hotmail to avoid revelations. TC/DRM Policy 7 Apr 07 10 Personae, Actors, and Agents I use “actor” to refer to an agent (a human, or Company X Hotmail a computer program), pursuing a goal (risk vs. reward), subject to some constraints (social, technical, ethical, …) C, acting as an In Freudian terms: ego, C, acting as employee id, superego. a hotmail Actors can act on behalf client of another actor: “agency”. • When an agent takes on a secondary goal, In this part of the talk, we or accepts a different set of constraints, are considering agency they create an actor with a new “persona”. relationships in a hierarchy. TC/DRM Policy 7 Apr 07 11 Bridging Trust: B2B e-commerce Use case: employee C of X purchasing Company X Company Y supplies through employee V of Y. Employee C creates a hotmail Employee V C, acting account for a as an “purchasing” employee C, acting as persona. a purchaser Purchaser C • Most workflow systems have rigid doesn‟t know any personae definitions (= role assignments). irrelevant • Current operating systems offer very little information. support for bridges. Important future work! TC/DRM Policy 7 Apr 07 12 Why can‟t we trust our leaders? Commands and trust “Our leaders are but flow upwards (by trusted servants…” majority vote, or by consensus). Information flows downwards by default (“privileged”). Upward information flows are “trusted” (filtered, audited, etc.) Peers In a peerage, the leading actors are trusted, have By contrast, the King of a hierarchy minimal privilege, don‟t has an absolute right (“root” privilege) know very much, and to know everything, is not trusted, can safely act on and cannot act safely. anything they know. TC/DRM Policy 7 Apr 07 13 Turn the picture upside down! Information flows Peers, Group members, Citizens upwards by default of an ideal democracy, … (“privileged”). Commands and trust flow downwards. Downward information flows are “trusted” (filtered, Facilitator, Moderator, audited, etc.) Democratic Leader, … A peerage can be modeled by Bell-La Equality of privilege is the Padula, because there is a partial default in a peerage, whereas order on the actors‟ inequality of privilege is the privileges. default in a hierarchy. TC/DRM Policy 7 Apr 07 14 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. TC/DRM Policy 7 Apr 07 15 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. TC/DRM Policy 7 Apr 07 16 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. TC/DRM Policy 7 Apr 07 17 A Legitimised Hierarchy OS Root Administrator Auditor • Each assurance group may want its own Audit (different scope, objectives, Trust, … ). • The OS Administrator may refuse to accept an Auditor. • The OS Administrator Users makes a Trusting appointment when granting auditor-level Privilege to a nominee. • Assurance IG1 IG2 Inspector-General organizations may be (an elected officer) hierarchical, e.g. if the Users are governmental Chair of User Assurance agencies or corporate Group TC/DRM Policy 7 Apr 07 divisions. 18 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! TC/DRM Policy 7 Apr 07 19 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. TC/DRM Policy 7 Apr 07 20 Some Members of Jericho TC/DRM Policy 7 Apr 07 21 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: 1. Integrity first: internal correspondence. Agency (or corporate division)- confidential by default, but keys are shared widely within the agency to ensure ready availability. 2. 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. 3. Rarely: highly sensitive data, such as state (or corporate) secrets, requiring narrowly controlled access within the agency. Three categories of externally-authored documents: 1. Integrity first: unsigned objects, e.g. downloads from the web. 2. Integrity and availability first: signed objects, e.g. contracts, tax returns. 3. 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. TC/DRM Policy 7 Apr 07 22 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. TC/DRM Policy 7 Apr 07 23 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? TC/DRM Policy 7 Apr 07 24 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 1. “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. TC/DRM Policy 7 Apr 07 25 NZ e-Government Principle #2 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. TC/DRM Policy 7 Apr 07 26 NZ e-Government Principle #3 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. TC/DRM Policy 7 Apr 07 27 NZ e-Government Principle #4 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? TC/DRM Policy 7 Apr 07 28 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. TC/DRM Policy 7 Apr 07 29 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. TC/DRM Policy 7 Apr 07 30 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). TC/DRM Policy 7 Apr 07 31 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. TC/DRM Policy 7 Apr 07 32 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. TC/DRM Policy 7 Apr 07 33
"Government Policy on Trusted Computing and Digital Rights Management"