Weaving a Web of Trust

1
Weaving a Web of Trust
IRUS Bay Area Roundtable Rohit Khare October 9,
1998 (Adam Rifkin)
2
Weaving a Web of Trust

• Mission
• How can users decide what to trust on the Web?
• Mechanism
• Does X have permission to do Y with resource Z?

• Introduction
• Principles Why
• Principals What
• Policies When
• Pragmatics How
• Applications
• Limits of Trust
• Implications

3
Introduction

• Clara Customer fires up her favorite Web browser
  one morning and connects to her Bank to pay her
  rent. The Bank's computer duly opens up an
  encrypted session, and Clara fills out the
  payment form from her landlord
• A Welter of Decisions...
• Can the Bank really believe its Clara? Vice
  versa?
• What kind of receipt can Clara rely on?
• Has the rent bill been delegated accurately?
• Cryptography answers how, not why
• Tamper-proofing is not the same as entrusting

4
New Conflicts in Open Systems

• The Bank no longer controls both ends
• Assumptions about trusted hardware, ATM card
  scanners, private communications links
  invalidated
• Furthermore, Web applications tend towards
  interoperable infrastructure technology
• Common cryptographic channel security
• Common certificate formats and repositories
• Common user interface hooks
• How can online banks convey trustworthiness
  without marble?

5
Scenario Entrusting an Applet

• Sara Surfer hears about a whiz-bang new financial
  applet from Jesse Jester. She hops over to
  FlyByNight.Com and downloads their latest and
  greatest auto-stock-picker
• Automated support for trust decisions
• Helping Sara decide whether to trust the applets
  advice third party ratings, endorsements, c
• Controlling the privileges of that applet to
  read portfolios, even execute trades, but not
  leak info

6
Scenario Content Filtering

• Many transactions can be rolled-back
• Often some recourse if trust is violated files
  recovered, money refunded, boarding denied
• Social effects cannot
• Should Johnny view page P? is another trust
  issue
• Indecency and inappropriateness is in the eye of
  several beholders
• Intersection of school, parents, and political
  policy
• Need to integrate several mechanisms
• Black- and White- lists
• Entrusting publishers vs contents

7
Trust Management

• Traditional, closed security falls short
• Access Control Lists and user databases operate
  over a known, finite universe of principals
  resources
• PolicyMaker introduced a new approach
• Blaze, Feigenbaum, et al. at IEEE Oakland 1996
• A TM engine strings together assertions into
  proofs
• ...Where assertions can come from many sources
• ...And the crytpography falls out as just one way
  to entrust the binding of an assertion to a
  speaker
• We need to ask why rather than how

8
Principles Why

• Digital TM engines can be more exacting in
  establishing authority, so
• Be Specific
• Broader assertions are less reliable
• Trust Yourself
• All trust decisions must loop back to own axioms
• Be Careful
• Logical design doesnt preclude implementation
  holes

9
Principle Be Specific

• In real life, holistic judgments are vague
• I trust my spouse for what?
• I trust my Bank thats not how they see it
• General-purpose Web tools frustrate
• Web servers deal in bags of bits between machines
• Not easy to distinguish a medical record file
• Not easy to identify the actual user
• Web client interfaces dont understand either
• Do you want to submit this data unencrypted -
  swat!
• Underlying OS security can thwart limits
• Sandboxing mobile code, redistribution limits

10
Principle Trust Yourself

• Assertion Chains should lead back to self
• My credit card number is xxxx
• CreditCorps certificate ? Issuing Bank ? own
  records
• United.com is the airline (it isnt)
• Local DNS ? Root Servers ? ICANN ? Jon
  Postel (oops!)
• Jons public key is yyyy (X.509)
• Signed by USC ? Signed by state of CA ? Signed by
  Feds
• Jons public key is zzzz (PGP)
• Signed by Jon ? Signed by Fred ? Signed by self
• Public key nnnn is Jon (SDSI/SPKI)
• Selfs DNSs Jon is nnnn root your own naming
  tree

11
Principle Be Careful

• Identify ( Justify) every trust decision
• Can be buried in operational logic
• Example Is Scooter a Member?
• W3C has Public, Member, and Team web access
• Originally, Member IP address masks were used
• Verbal contracts trusted employees to protect
  info
• AltaVistas web crawler was seen as a Member
• ... And information leaked out to the index!
• Required coordination of password database,
  filesystem permissions, and Robot Exclusion file

12
Principals What

• Microsoft Authenticode entrusts ActiveX controls
  based on encrypted communication between
  machines signed identity of the author(s) and a
  safe applet pledge certificate from MS and a
  commercial sw publisher certificate from
  Verisign/DB
• People Names
• An identity which persists across transactions
  liable
• Computers Addresses
• Limited lifetime can only prove correct
  execution
• Organizations Credentials
• Persistent lifetime can link People Computers

13
Principal People

• Trust behavioral consistency
• Legal and social precedent holds individuals
  liable
• Ultimately, people back computers and
  organizations
• Human identity should be established outside of
  any particular application
• E.g. Verisigns multiple levels, from email to
  notary to credit check to personal investigation
• Identity alone is not trustworthy
• Bank trusts Clara Customer, not Clara Beekham
• Once the organization establishes a role linking
  the two

14
Principal Computers

• The Webs Trusted Computing Base?
• Client PCs have many points of failure
• Even https relies on routing and domain naming
• Entrusting Devices as Devices
• To execute cryptographic operations correctly
• To modify internal state or trigger peripherals
• Checksums, clock freshness, channel security, etc
  can only prove a consistent address
• Example Cellphone cloning fraud conflates device
  authentication (ser ) with user authorization
  (bill)

15
Principal Organizations

• Organizations are much like people
• Literally and legally, as incorporation
  suggests
• Scale has a quality all its own
• Easier to trust a group of people over time with
  internal checks and balances and standards
• Anytime trust has to be shared with a different
  principal
• Credentials bind people to devices
• It is more efficient to intermediate
  relationships
• Reflects the same transaction costs as optimal
  firm-size theory does in real world economics

16
Policies When

• Principal-Centric Who you are
• Object-Centric What you have
• Action-Centric What you can do
• TM Engines take a proposition (principal, action,
  object), assertions, and a policy evaluator as
  input to generate an authorization matrix
• Policies can be composable on behalf of several
  stakeholders

Credit Line Savings Account Vault Branch
Manager Create, Read/Write Create,
Read/Write Deposit, Withdraw Teller Read Read/Wri
te Deposit Guard None None Withdraw
17
Policies Principal-Centric

• Placing trust in principals (or roles)
• Typically, classify individuals into groups
• Denning 76 proved information flow w/lattices
• Principle of least privilege encourages
  specificity
• ... and label each object or action with a
  minimum or maximum authorization level
• Bell and LaPadula compartmentalization of
  processes read downwards, write upwards,
  sanitization
• Useful when there are fewer users than objects or
  actions

18
Policies Object-Centric

• Placing trust in objects (or keys)
• Typically, protect resources with keys
• Hand out the combination to a vault
• Secret-sharing can require multiple cooperating
  keyholders (e.g. a safe-deposit box)
• Optionally compartmentalize access
• Different interfaces have different keys
• Deposit and Withdraw handles in MS COM-speak
• Possession of the right pointer limits the
  visible functions
• Useful when there are fewer objects than users or
  actions

19
Policies Action-Centric

• Placing trust in demonstrated abilities
• Typically test and compile into an authorization
  certificate
• Drivers License or swimming test
• Manage classes of capabilities
• Bank might be factored into Account Creation,
  Bookkeeping, and Vault Access
• ... Then map onto personnel and objects as needed
• Example Drinking age laws are intrinsic, not
  from a registry of drinkers or access controls on
  bottles

20
Policies Implementation

• Trusting someone to drive a car
• By identity a list of authorized drivers
• By object a set of keys to be handed out
• By capability rent a car with license
  insurance
• Choice of primary axis depends on
• Simplicity which is the smallest set? bank
  employees
• Dynamism avoid enumerating the volatile.
  drivers
• Efficiency whats easiest to check? Licenses
• Watch for conflicting policy styles
• Hotel erred in using payment-ability as identity

21
Pragmatics How

• The topological shift from a single secure node
  to a net of separately administered domains is
  driving the development of a new generation of
  Web TM tools
• Identifying Principals Decentralized PKI
• Labeling Resources Web Metadata
• Codifying Policies Policy Languages
• Automating the Web of Trust TM Engines

22
Pragmatics Identifying Principals

• Digital Certificates alone arent trustworthy
• Kohnfelder78 introduced Certification
  Authorities
• CA Utility is proportional to its reach
• Clearinghouse simplifies group-membership
• ... But its power is inversely related
• The further up the pyramid, the greater the
  liability
• Unprincipled compared to PGP/SPKI/SDSI
• Identity certificates are not specific about
  authorization
• Hierarchy ends in God, not self
• Logistical difficulties of updating global
  revocation lists

23
Pragmatics Labeling Resources

• Traditional fixed set of security attributes
• UNIX file permissions, AFS ACLs, process handles
• Separable security labels as metadata
• PICS labels, Resource Description Framwork (RDF)
• Deliverable in, with, or from third parties
• Self-description of schemas
• Loadable rating scales or attribute vocabularies
• Difficulty of binding to variable Web pages
• Languages, obsolescence, bundling together pages

24
Pragmatics Codifying Policies

• Webs trust problems are too varied to compile
  in
• PICS filtering, applet authorization soon
  payment method selection and privacy policy
  negotiation
• Externalized policy evaluators
• More flexible to put in a general-purpose TM
  Engine
• Possible to compose policies written in several
  languages and styles
• Example REFEREE can load in policy interpreters
  as well as policies, rather than PICSRulz alone

25
Applications

• Collaborative Authoring Publication
• Extending trust to push networks, readers
• Content Filtering
• Acceptable content rights management privacy
• Highlights composable policy, diverse label
  stores
• Electronic Commerce
• Negotiating by assertion rather than policy JEPI
• Downloadable Code
• Trusted applet trusted runtime/OS

26
Limits of Trust

• Limits of Web Security
• Security services below, at, and above HTTP layer
• Trust as a Social Contract
• Game-theoretic model of rational
  opponents Axelrod
• Trust is a learning process how can tools help?
• Trust in the Mirror
• Moving the world into the box magnifies latent
  flaws in existing relationships
• The Social Security PEBES Case (mail vs.
  e-mail) speed, anonymity of electronic queries
  changes the risk profile

27
Limits Web Servers

• Unprincipled
• Not able to specifically identify resources at
  risk within a server (medical records)
• Not responsible for own security varies by OS
• Not careful in logging anomalies or for rollback
• Principal identification scattered
• E.g. SSL client-auth info cannot pass up to HTTP
• Lower-layer IP source or DNS lookup spoofable
• Inflexible policies
• Typically limited to user-and-password
  configurations

28
Limits Web Clients

• Unprincipled
• Does not adapt behavior to specific site IE4
  Zones
• Requires trusting monolithic sw vendor instead of
  self
• Not carefully integrated with OS cache leaks,
  cookies
• Principal identification scattered
• Desktop PCs Macs have a weak concept of User
• User interface hides computer address spoofable
• Organizational identification relies on images,
  DNS
• Inflexible Policies
• Content-filtering, applet, and privacy checks
  built-in

29
Implications

• Web Developers
• Commit to developing standardized TM
  infrastructure
• Web Users
• Awareness of the flood of trust decisions of
  mere surfing motivates developers to do their
  part
• Application Stakeholders
• Identify and justify your systems trust
  decisions
• Citizens
• What are the social consequences of fragmenting
  our trust communities into self-contained
  world-views?

30
For Further Information...

• This Talk http//www.ics.uci.edu/rohit/web-of-tru
  st
• Our Paper http//www.cs.caltech.edu/adam/papers/w
  ww
• The Book http//www.w3j.com/7/
• Digital Signature Labels http//www.w3.org/DSig/
• Simple PKI http//www.ietf.org/html.charters/spki-
  charter.html
• REFEREE http//www.research.att.com/jf/pubs/www6-
  97.html
• PolicyMaker ftp//dimacs.rutgers.edu/pub/dimacs/
  TechnicalReports/TechReports/1996/96-17.ps.gz
• Contact Us rohit_at_ics.uci.edu, adam_at_cs.caltech.edu