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

3rd Party Vendor Registration

1. Vendor registers with 3rd party (e.g., BBB)

2. 3rd party tracks vendor reputation

3. Vendor gets PKI ID key pair and 2nd key for private exchange with 3rd Party

4. Vendor makes modifications to web site to support verification

3rd Party User Registration

1. User contacts third party (e.g. BBB) (i.e., long before contacting vendors)

2. User establishes validity of 3rd party in the usual way

3. User gives Trusted 3rd 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 vendor2. Vendor page displays seal of T3P

Seal has hyperlink with encrypted page URL

3. User clicks seal, goes to T3P over SSL4. T3P verifies vendor & URL5. User sees 2nd page with info & secret6. User clicks (or redirected) to verified

URL, in case seal copied to other URL

Site Assurance

3rd Party User Vendor

fetch page

fetch assurance

refetch page

page

page

assurance + URL

Site & Content Verification

1. User visits web page of a vendor2. Vendor page displays seal of T3P

Seal has hyperlink, encrypted URL+session*

3. User clicks seal, goes to T3P over SSL4. T3P verifies vendor & URL5. T3P fetches page & verifies signature6. User sees 2nd page with T3P secret7. 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

3rd Party User Vendor

fetch page

fetch assurance

fetch page

page

page

assurance + URL refetch page

page

Proxy Auto Verification

1. User visits web page of a vendor2. Vendor page displays seal of T3P

Seal has hyperlink, encrypted URL/session info

3. User clicks seal, goes to T3P over SSL4. T3P verifies vendor & URL5. T3P fetches & verifies page signature6. User sees frame with T3P secret 7. User gets verified page from T3P

Non-repudiation

1. User visits web page of a vendor2. Vendor page displays seal of T3P

Seal has hyperlink, encrypted URL/session info

3. User clicks seal, goes to T3P over SSL4. T3P verifies vendor & URL5. T3P fetches & verifies page signature6. User sees frame with T3P secret 7. User gets verified page signed by T3P

Proxy & Non-repudiation

3rd Party User Vendor

fetch page

fetch assurance

fetch page

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

3rd Party User Vendorfetch page

start sessionfetch page

page

pageassurance + page

next requestfetch page

pageassurance + 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