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 peering trust with
  diverse systems and individuals.
• Why Digital Rights Managment (DRM) is a difficult
  security problem for its governors.

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.

4
Privilege and Trust 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
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 trusted routing

6
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 doesnt protect X from Y, because
  the CEO/King of the merged company has the right
  to know all keys.
• Can an appropriate King(XY) be found?

7
Email across Hierarchies

• Q How can we manage email between hierarchies?

Agency X

• Answers
• Merge
• Subsume
• Bridge

Company Y
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.

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 actors
  personae.
• C should encrypt all hotmail to avoid revelations.

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
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,
12
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.
• 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.
• Trusting decisions 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.

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 worlds trusted computing?

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.

Auditor
TC Root Administrator
TC Users
IG2
IG1
Inspector-General (an elected officer)
Chair of User Assurance Group
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).
• Were 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.

16
Implementation Methodsadapted from Lessigs
theory
Our economies make things inexpensive or
expensive.
Our technological architectures make things easy
or difficult.
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.

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/princip
  les-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 licensees 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?