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

Government Policy on Trusted Computing and Digital Rights Management

a view from New Zealand

Prof. Clark Thomborson

7th April 2007

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.


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.


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.


Trustworthiness in a Hierarchy

Information flows upwards, toward the most powerful actor.


Peons must be trusted with some information!

If the peons are not trustworthy, then the system is not secure.



If the King does not show good leadership (by issuing appropriate commands), then the system will not work well. “Noblesse oblige”!


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, …



Email up: “privileged” (allowed by default) Email down: “trusted” (disallowed by

default, risk to confidentiality) Email across: privileged & trusted routing


Email across Hierarchies

Q: How should we handle email between hierarchies?

Company X Agency Y

Answers:

1. Merge2. Subsume

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



Q: How can we manage email between hierarchies?

Agency X

Company YAnswers:

1. Merge

2. Subsume3. Bridge



Q: How can we manage email between hierarchies?

Company X Agency Y

Answers:

1. Merge

2. Subsume

3. Bridge! • Bridging connection: trusted in both directions.


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


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


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


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.


Turn the picture upside down!

Information flows upwards by default (“privileged”).


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, …


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.


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.


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.


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.


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!


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.


Some Members of Jericho


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.


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.


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?


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.


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.



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.



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?


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.


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.


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


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.


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.

Documents

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