A Third Party Service for Providing Trust on the Internet Work done in 2001 at HP Labs by Michael VanHilst and Ski Ilnicki

The Problem Vendor reputation –this vendor meets high standards Site authenticity – this is the vendor’s web cite Page integrity –this is the vendor’s web page Non-repudiation

PKI The originator has a private key The receiver has the originator’s public key and uses it to verify data sent from the originator The receiver verifies the originator’s public key with the stored public key of a well known certification authority

PKI Verification The user can verify that: The public key was issued by the certificate authority (or an agent thereof) The public key was bound to the name (and URL domain) of the originator The public key was bound to a period of validity (that includes today)

Current Practice Vendor purchases a certificate The CA (i.e. Verisign) checks vendor bone fides –Purchaser has valid business license –Purchaser owns domain name –Issues vendor a Digital ID Vendor attaches Digital ID to pages –ID includes rooted chain of signed keys

Current Weaknesses Business could display Verisign-like seal but not use their certificates* Business could register with misleading name or URL (visual inspection only!) –amazon.tv or a common mistyping User could be tricked into accepting untrusted certification authority key No assurance for unknown businesses

Other Threats Hacked pages on vendor site Domain name spoofing by poisoning DNS caches with bad IP address (DNS and DHCP don’t use authentication) A CA gives CA authority to a non- trustworthy individual Non-trustworthy employee of a CA

Naïve Users? Even for obvious spoofs: Navigate menus for certificate info –under file->properties in IE –under view->page_info in Netscape) Displayed info has limited value –Go to the myFAU login page and try to find something that positively identifies them.

The Threat If a web page asks you for a password or account information, how do you know you can trust it? How do you know who they are? Even if you know who they are, how do you know you can trust them? How does your mother know?

Our Proposal Use a trusted third party to perform all verifications and provide assurances Overcomes most weaknesses in the current practice Does not require modification to web, browsers, or CA standards

3 rd Party Vendor Registration 1.Vendor registers with 3 rd party (e.g., BBB) 2.3 rd party tracks vendor reputation 3.Vendor gets PKI ID key pair and 2nd key for private exchange with 3 rd Party 4.Vendor makes modifications to web site to support verification

3 rd Party User Registration 1.User contacts third party (e.g. BBB) (i.e., long before contacting vendors) 2.User establishes validity of 3 rd party in the usual way 3.User gives Trusted 3 rd Party (T3P) a secret string (e.g., “my dog has fleas”) User’s T3P secret cannot be found by trial and error attack – only user verifies it

Web Site Verification 1.User visits web page of a vendor 2.Vendor page displays seal of T3P Seal has hyperlink with encrypted page URL 3.User clicks seal, goes to T3P over SSL 4.T3P verifies vendor & URL 5.User sees 2 nd page with info & secret 6.User clicks (or redirected) to verified URL, in case seal copied to other URL

Site Assurance 3 rd PartyUserVendor fetch page fetch assurance refetch page page assurance + URL

Site & Content Verification 1.User visits web page of a vendor 2.Vendor page displays seal of T3P Seal has hyperlink, encrypted URL+session* 3.User clicks seal, goes to T3P over SSL 4.T3P verifies vendor & URL 5.T3P fetches page & verifies signature 6.User sees 2 nd page with T3P secret 7.User clicks (or redirected) to verified URL

(Session Info) Page could be dynamically generated with session and/or user cookie info Session and user specific info not available from T3P must be included (encrypted) as parameters to T3P URL Vendor must support two modes of page generation to allow request from vendor to match that from user

Content Assurance 3 rd PartyUserVendor fetch page fetch assurance fetch page page assurance + URL refetch page page

Proxy Auto Verification 1.User visits web page of a vendor 2.Vendor page displays seal of T3P Seal has hyperlink, encrypted URL/session info 3.User clicks seal, goes to T3P over SSL 4.T3P verifies vendor & URL 5.T3P fetches & verifies page signature 6.User sees frame with T3P secret 7.User gets verified page from T3P

Non-repudiation 1.User visits web page of a vendor 2.Vendor page displays seal of T3P Seal has hyperlink, encrypted URL/session info 3.User clicks seal, goes to T3P over SSL 4.T3P verifies vendor & URL 5.T3P fetches & verifies page signature 6.User sees frame with T3P secret 7.User gets verified page signed by T3P

Proxy & Non-repudiation 3 rd PartyUserVendor fetch page fetch assurance fetch page page assurance + page

T3P Session Proxy Extension to proxy or non-repudiated Send all subsequent user requests from page directly through T3P All hyperlinks on page have T3P’s URL –Links can be recrafted by T3P –or by vendor (but checked by T3P) Both parties can get T3P signed pages

(Cookies) During the proxied session, the vendor’s cookie on the user’s client does not come into play. At the end of the session, a final step must transfer the session info back to the vendor directly from the user to update the cookie

Session Proxy 3 rd PartyUserVendor fetch page start session fetch page page assurance + page next request fetch page page assurance + page finish cookie

(Included Images) If vendor includes content from other sites Vendor must provide signed versions of all content Providers of included content must have their own vendor relationship with T3P T3P marks parts of page, displayed to user, that are not verifiable