A Third Party Service for Providing Trust on the Internet

1
A Third Party Service for Providing Trust on the
Internet

• Work done in 2001 at HP Labs by Michael VanHilst
  and Ski Ilnicki

2
The Problem

• Vendor reputation
• this vendor meets high standards
• Site authenticity
• this is the vendors web cite
• Page integrity
• this is the vendors web page
• Non-repudiation

3
PKI

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

4
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)

5
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

6
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

7
Other Threats

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

8
Naïve Users?

• Even for obvious spoofs
• Navigate menus for certificate info
• under file-gtproperties in IE
• under view-gtpage_info in Netscape)
• Displayed info has limited value
• Go to the myFAU login page and try to find
  something that positively identifies them.

9
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?

10
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

11
3rd Party Vendor Registration

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

12
3rd Party User Registration

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

13
Web Site Verification

• User visits web page of a vendor
• Vendor page displays seal of T3P
• Seal has hyperlink with encrypted page URL
• User clicks seal, goes to T3P over SSL
• T3P verifies vendor URL
• User sees 2nd page with info secret
• User clicks (or redirected) to verified URL, in
  case seal copied to other URL

14
Site Assurance
3rd Party
User
Vendor
fetch page
page
fetch assurance
assurance URL
refetch page
page
15
Site Content Verification

• User visits web page of a vendor
• Vendor page displays seal of T3P
• Seal has hyperlink, encrypted URLsession
• User clicks seal, goes to T3P over SSL
• T3P verifies vendor URL
• T3P fetches page verifies signature
• User sees 2nd page with T3P secret
• User clicks (or redirected) to verified URL

16
(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

17
Content Assurance
3rd Party
User
Vendor
fetch page
page
fetch assurance
fetch page
page
assurance URL
refetch page
page
18
Proxy Auto Verification

• User visits web page of a vendor
• Vendor page displays seal of T3P
• Seal has hyperlink, encrypted URL/session info
• User clicks seal, goes to T3P over SSL
• T3P verifies vendor URL
• T3P fetches verifies page signature
• User sees frame with T3P secret
• User gets verified page from T3P

19
Non-repudiation

• User visits web page of a vendor
• Vendor page displays seal of T3P
• Seal has hyperlink, encrypted URL/session info
• User clicks seal, goes to T3P over SSL
• T3P verifies vendor URL
• T3P fetches verifies page signature
• User sees frame with T3P secret
• User gets verified page signed by T3P

20
Proxy Non-repudiation
3rd Party
User
Vendor
fetch page
page
fetch assurance
fetch page
page
assurance page
21
T3P Session Proxy

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

22
(Cookies)

• During the proxied session, the vendors cookie
  on the users 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

23
Session Proxy
3rd Party
User
Vendor
fetch page
page
start session
fetch page
page
assurance page
next request
fetch page
page
assurance page
finish
cookie
24
(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