An appropriate design for trusted computing and digital rights management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

An Appropriate Design for Trusted Computing and Digital Rights Management PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on
  • Presentation posted in: General

An Appropriate Design for Trusted Computing and Digital Rights Management. Prof. Clark Thomborson 4 th April 2007. Outline. An operational definition of “trust”. Requirements analysis of e-government and corporate DRM (ECM) at three levels: s tatic, dynamic, governance.

Download Presentation

An Appropriate Design for Trusted Computing and Digital Rights Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


An appropriate design for trusted computing and digital rights management

An Appropriate Design for Trusted Computing and Digital Rights Management

Prof. Clark Thomborson

4th April 2007


Outline

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.


Trust and privilege

Trust and Privilege

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


Technical and non technical definitions of trust

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

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.


Trustworthiness in a hierarchy

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”!


Email in a hierarchy

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


Email across hierarchies

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?


Email across hierarchies1

Email across Hierarchies

Q: How can we manage email between hierarchies?

Agency X

Answers:

  • Merge

  • Subsume

  • Bridge

Company Y


Email across hierarchies2

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.


Bridging trust

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.


Personae actors and agents

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


Bridging trust b2b e commerce

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!


Why can t we trust our leaders

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

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.


Peer trust vs hierarchical trust

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.


Legitimation and enforcement

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.


Requirements for relationship management

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!


Vapourware

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?!?


A legitimised hierarchy

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


Summary of static trust

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!


Dynamic trust and system trust

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.


My goals

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


Some members of jericho

Some Members of Jericho


Static security for drm

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.


Dynamic security requirements

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.


Security governance

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.


Microsoft s irm v1 0

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.


Assessment of irm v1 0 with tc for corporate drm

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.


Malware scans in tc drm

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.


Summary

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.


Acknowledgements sources

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.


  • Login