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

Weaving a Web of Trust

IRUS Bay Area Roundtable Rohit KhareOctober 9, 1998 (Adam Rifkin)

October 9, 1998 Weaving a Web of Trust 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


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 it’s 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


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 securityCommon certificate formats and repositoriesCommon user interface hooks

How can [online banks] convey trustworthiness without marble?


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

applet’s advice: third party ratings, endorsements, &c

Controlling the privileges of that applet: to read portfolios, even execute trades, but not leak info


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 beholdersIntersection of school, parents, and political policy

Need to integrate several mechanismsBlack- and White- listsEntrusting publishers vs contents


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


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 doesn’t preclude implementation

holes


Principle: Be Specific

In real life, holistic judgments are vague: “I trust my spouse” — for what? “I trust my Bank” — that’s 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 fileNot easy to identify the actual user

Web client interfaces don’t understand either‘Do you want to submit this data unencrypted’ - swat!

Underlying OS security can thwart limitsSandboxing mobile code, redistribution limits


Principle: Trust Yourself

Assertion Chains should lead back to self “My credit card number is xxxx”

CreditCorp’s certificate Issuing Bank own records “United.com is the airline” (it isn’t)

Local DNS Root Servers ICANN Jon Postel (oops!)

“Jon’s public key is yyyy” (X.509)

Signed by USC Signed by state of CA Signed by Feds “Jon’s public key is zzzz” (PGP)

Signed by Jon Signed by Fred Signed by self “Public key nnnn is Jon”(SDSI/SPKI)

“Self’s DNS’s Jon is nnnn” — root your own naming tree


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 AltaVista’s 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


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/D&B

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


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. Verisign’s 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


Principal: Computers

The Web’s 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)


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 standardsAnytime 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


Policies When

Principal-Centric Who you areObject-Centric What you haveAction-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 ManagerCreate, Read/Write Create, Read/WriteDeposit, Withdraw

Teller Read Read/Write Deposit

Guard None None Withdraw


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


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


Policies: Action-Centric

Placing trust in demonstrated abilitiesTypically test and compile into an

authorization certificate Driver’s 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


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: what’s easiest to check? Licenses

Watch for conflicting policy styles Hotel erred in using payment-ability as identity


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 PKILabeling Resources Web MetadataCodifying Policies Policy LanguagesAutomating the Web of Trust TM

Engines


Pragmatics: Identifying Principals

Digital Certificates alone aren’t 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


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


Pragmatics: Codifying Policies

Web’s ‘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


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


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 relationshipsThe Social Security PEBES Case (“mail vs. e-mail”):

speed, anonymity of electronic queries changes the risk profile


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


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


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?


For Further Information... This Talk http://www.ics.uci.edu/~rohit/web-of-trust

Our Paper http://www.cs.caltech.edu/~adam/papers/www

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 [email protected], [email protected]

Documents

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