Government Policy on Trusted Computing and Digital Rights Management by n.rajbharath


									Government Policy on
Trusted Computing and
Digital Rights Management

       a view from New Zealand

          Prof. Clark Thomborson

              7th April 2007
   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
       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.
                         Information flowing down is
                         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
 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

 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
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
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
   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
                                   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
    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
                                      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
    Information flows
     downwards by default
    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, …
    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
   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

                                  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
                                                        • 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
        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
        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
        Peerages have trouble with enforcement; hierarchies have trouble with
        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
        Law-enforcement and national-security requirements must also be
   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
       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.
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
   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
       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
       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
   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

                                     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
       In ECM systems, all documents are controlled by the recipient.
       Recipient computers can have full administrative rights over the
   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”,
   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,
                                 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

To top