Thoughts on shared-key authentication

[Charles Watt <watt@xxxxxxxxx>]

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
 A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
 dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
 MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
 Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
 DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
 AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
 A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
 aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
 BwP+eZsNFRAvH/278pFEFxJYn4qugayrKLxU0mEYckY5DDWVTbDex6Dpjq8jAncW
 1ydDgePOn0MDaLcb6Er+czg=

There are many applications that have a much stronger requirement for
data authenticity than for confidentiality.  As an example, retail
banking over the Internet.  (Please hold any comments on the specific
example.  If you do not like it, think for a while and you will be able 
to find an example that your prefer that meets these criteria).  40-bit 
keys for encryption are adequate for things like viewing your check 
register -- there are MUCH easier ways for an attacker to gain access to 
your transaction data than breaking a 40-bit key (e.g., if in the US the
odds are pretty good that your bank supports telephone banking where all 
I need is your account number from your check and your SSN, which I can 
look up on the Web).  However, the authorization of bill payments requires 
a full 128-bits of authenticity -- definitely not cool if an attacker can 
pay your bills for you.

When servicing a customer base of > 1 million account holders, it is:

	1) an onerous administrative task
	2) a horrendous performance hit on the server

to use client-side certificates -- particularly in light of the fact 
that most banks have already distributed via manual methods sufficient 
information to authenticate customers (e.g., ATM cards and PINs) that 
could be used in an automated fashion by an on-line bank server.

It is quite possible to build into TLS a shared-secret authentication
mechanism that is exportable and whose strength is independent of the
strength of the encryption.  We run an example of such a mechanism in 
our lab:

	a) modify a public-domain implementation of MD5 or SHA to add
 	   procedures for saving and restoring the internal state
	   registers -- an easy task.

	b) on the server, create a one-way hash of the customer password
	   by running your modified hash function over the password.
	   Save the internal state registers of the hash function and throw 
	   away the password.

	c) when the customer logs in, have the server send a one-time nonce
	   to the browser.

	d) have the client prompt the customer for the customer's password.
	   The client calculates the one way hash of password + nonce.

	e) send the resulting hash value to the server.  Note that a standard
	   version of the hash function is all you need on the client.

	f) server verifies customer password by restoring the hash function
	   registers and performing the final hash cycle over just the
	   nonce.

Charles Watt
Security First Network Bank
www.sfnb.com

P.S:
Even though we built this in the lab with the intent of providing it for
our international banks, we were never able to deploy it due to a security
flaw in all SSL-capable Web servers that were available at the time -- no one 
provided an interface by which the application running on the server could 
access the SSL session ID.  Without access to the session ID to link 
successive connections into a login session, the 128-bit keyed hash provided 
by SSL is worthless to the application.  Instead the app must fall back on 
the cookie mechanism as a way to link a login session.  But cookies are
protected using 40-bit encryption, reducing the assurance with which you can 
link successive connections from 128 --> 40 bits.  

In the end it was easier to find an off-shore solution to the crypto problem 
than to get the big name server vendors to support secure applications.

-----END PRIVACY-ENHANCED MESSAGE-----