Weaving a Web of Trust
advertisement
Weaving a Web of Trust IRUS Bay Area Roundtable October 9, 1998 Rohit Khare (Adam Rifkin) 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? October 9, 1998 Introduction Principles Principals Policies Pragmatics Applications Limits of Trust Implications Weaving a Web of Trust Why What When How 2 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 October 9, 1998 Weaving a Web of Trust 3 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? October 9, 1998 Weaving a Web of Trust 4 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 October 9, 1998 Weaving a Web of Trust 5 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 October 9, 1998 Weaving a Web of Trust 6 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 October 9, 1998 Weaving a Web of Trust 7 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 October 9, 1998 Weaving a Web of Trust 8 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 file Not 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 limits Sandboxing mobile code, redistribution limits October 9, 1998 Weaving a Web of Trust 9 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 “Jon’s public key is yyyy” (oops!) (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 October 9, 1998 Weaving a Web of Trust 10 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 October 9, 1998 Weaving a Web of Trust 11 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 Names People An identity which persists across transactions; liable Addresses Computers Limited lifetime; can only prove correct execution Credentials Organizations Persistent lifetime; can link People & Computers October 9, 1998 Weaving a Web of Trust 12 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 October 9, 1998 Weaving a Web of Trust 13 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) October 9, 1998 Weaving a Web of Trust 14 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 October 9, 1998 Weaving a Web of Trust 15 Policies When Who you are What you have What you can do Principal-Centric Object-Centric Action-Centric 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 Branch Manager October 9, 1998 Savings Account Create, Read/Write Create, Read/Write Vault Deposit, Withdraw Teller Read Read/Write Deposit Guard None None Withdraw Weaving a Web of Trust 16 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 October 9, 1998 Weaving a Web of Trust 17 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 October 9, 1998 Weaving a Web of Trust 18 Policies: Action-Centric Placing trust in demonstrated abilities Typically 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 October 9, 1998 Weaving a Web of Trust 19 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 October 9, 1998 Weaving a Web of Trust 20 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 October 9, 1998 Weaving a Web of Trust 21 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 October 9, 1998 Weaving a Web of Trust 22 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 October 9, 1998 Weaving a Web of Trust 23 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 October 9, 1998 Weaving a Web of Trust 24 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 October 9, 1998 Weaving a Web of Trust 25 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 October 9, 1998 Weaving a Web of Trust 26 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 October 9, 1998 Weaving a Web of Trust 27 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 Weaving a Web of Trust October 9, 1998 28 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? October 9, 1998 Weaving a Web of Trust 29 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 October 9, 1998 rohit@ics.uci.edu, adam@cs.caltech.edu Weaving a Web of Trust 30
