From: Charles Watt <watt@sware.com>
Date: Wed, 17 Apr 1996 02:35:44 +0800
To: cypherpunks@toad.com
Subject: Re: Bank transactions on Internet
Message-ID: <9604161346.AA06924@mordred.sware.com>
MIME-Version: 1.0
Content-Type: text


-----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,
 ApDNkoCKfI0iz1XP4rYpl2XlbqF9/llmB3tLaunuqLWlnD5+VcGwYDNR/HJQa+AV
 7s41qt0zFhiYbhidj7zh4e8=

> From: Eric Young <eay@mincom.oz.au>
> On Mon, 8 Apr 1996, JR Weaver wrote:
> > with SFNB to purchase my own copy of 128-bit Netscape Navigator. You can make
> > transactions over the net and SFNB does not limit you to 128-bit. Is it really
> > that easy to break 40-bit? Don't you need access to a "fair amount of cpu
> > power" to brute force crack 40bit? As far as I know client authentication is
> Put put it in a word, 'yes'.
> 
> > strictly username & password. What other authentication system exists??
> This would be a very good system to attack.
> 
> ... (details on Eric's break-SSL saga)
> 
> Please remember that I'm not talking about theory.  Besides the person 
> working next to me, no-one at work knew I was participating in the brute 
> force beaking attempt.  Well this is not totally true, the owner of the SGI 
> with 6 R4400 CPU's noticed that I was using a few of the CPU's but they 
> did not know what the programs were doing :-).
> 
> I would say that RC4 40 should not be used if possible, especially to do 
> with anything to do with banking.
> 
> eric (just putting in his own 2 certs worth).

As Chief Scientist for SecureWare and one of the designers of SFNB's
security architecture, I would like to make a couple of points regarding
this thread:

	1. SFNB customers are at absolutely NO RISK from Internet attacks
	2. It's a whole lot harder to break into SFNB than just cracking
	   a 40-bit RC4 key.
	3. 40-bit SSL, when used within a properly designed security
	   framework, is more than adequate for personal banking 
	   transactions.

Along the way I'll outline my understanding of SFNB's plans for future 
security enhancements (as only an advisor to SFNB I cannot speak for them
directly) with the hope of getting some useful feedback from the experts 
on this list.  I'll apologize in advance for the length of this post, but 
while I enjoy this list for its occasional emphasis on crypto, sometimes 
the participents get a little too focused and forget that encryption does 
not equate to security.

First, the U.S. banking system is very nice to account holders.  The banks,
rather than the customers, assume all risk associated with security problems
in telephone banking, ATMs, etc...  Internet banking is no different, which
explains why so few banks have jumped onto the net with real transactions.
If an SFNB customer should lose any funds due to a security problem, SFNB
pays, not the customer.

Second, in order to break the SSL-protected password of an SFNB account
holder, you need access to the encrypted data.  This is not easy to obtain
over the Internet, and would generally require illegal activity in order 
to gain control of a host within the Internet infrastructure or collusion 
with the account holder.  Should an attacker crack the key and obtain 
the account number and password of an SFNB account holder, they are clearly 
warned upon login that they are engaging in illegal activity.  Once they 
have logged in, there is no way to transfer money out of the account 
without leaving a target address and phone number for the recipient.  
Furthermore, any payment to an individual or unknown entity would be 
made in the form of a physical check that would have to be cashed at
a physical bank.  The whole process is heavily audited with real-time 
audit filtering and pattern matching capabilities -- SFNB is, afterall, 
running on a military grade secure operating system (see SWP at 
www.secureware.com).  Any security system that is deployed should be
compared against the value you are trying to protect.  It seems like a 
pretty big risk to an attacker -- and I assure you SFNB will prosecute.

Finally, I whole-heartedly agree that 40-bit encryption is far too weak 
for many applications, and that the current export limitations are absurd.  
I have my own copy of the Xilinx development tool set at home and am
quite capable of using it to design a 40-bit key cracking engine.  I assume 
that others on this list might be able to as well.  However, it is important 
to note that strong encryption does NOT equate to strong security.  
Encryption is merely one of many tools that are available in building 
secure systems.  For example, a Web-based application running over 128-bit 
SSL would still be vulnerable to:

	- attacks against the server host
	- server spoof attacks
	- client side attacks, e.g. a Trojan Horse

In my estimation, all of these are more likely (and more dangerous if 
successful) than an attacker cracking the 40-bit key used for a bank 
transaction.  Any security sensitive application, such as Internet banking, 
that does not protect against all of these attacks is asking for trouble
in the long run.  Note that in the long run the Trojan Horse problem is the 
most severe for a banking application, for the bank cannot control end 
user PCs.  And no matter how good the tools they are provided for their 
protection (see Troy at www.secureware.com), ultimately the bank cannot 
protect users from their own foolish actions.

Also, despite the noise currently being made in Washington about relaxing 
export regulations, the current limitations are reality.  Thus, it has been
SFNB's goal from the start to design a personal banking solution that 
protects against all of these attacks and is secure running over 40-bits.  
At this time, as SFNB does not have this solution fully deployed, SNFB 
offers the 128-bit version of the Netscape browswer FREE to any SFNB 
customer that wants it.  Just call their customer support line.

The trick to secure personal banking at 40-bits is to remember that
encryption can be used for many functions.  For personal checking, it is
the authenticity and integrity of a transaction that must be strongly
protected, not the confidentiality.  For the latter, 40-bits is sufficient,
i.e., while confidentiality of account holder transactions is certainly
important, the value of discovering this information does not justify the
cost of an attack against the encryption.  Thus, if the 40-bit encrypted 
traffic between the browser and server does not contain any repeatable 
authentication information, 40-bits is sufficient.  For commercial accounts
this is not the case and SFNB does is planning to use security beyond SSL.

In the long term SFNB plans to disassociate the authentication of a 
transaction from its encryption through the use of SmartCard-based 
client-side private keys and bank-issued certificates.  This has the
advantage of permitting signatures to obtain non-repudiable transactions, 
making the bank "electronic commerce enabled".  However, this feature 
has not been available in commercial browsers within the originally 
estimated time frame.  We considered running the browsers transparently 
over SecureWare's Hannah product (www.secureware.com) to get client-side 
keying and a stronger protocol than SSL, but SFNB decided it was a better 
business decision to wait for client-side support in the browsers -- i.e, 
the cost to SFNB of distributing and supporting special client-side software 
>> cost of projected loss due to successful attacks on the bank during the 
estimated interval before browser support becomes available.  It is, after 
all, SFNB's decision to make.  They, not the customer, will pay any costs 
associated with a successful attack, whether financial or PR.

But as the availability of client-side certificates has been pushed out, 
we have prepared two interim solutions, both of which solve the list of 
problems above.  SFNB is currently debating whether to deploy one (or both):

1.  Distribute a browser plug-in or locally resident Java applet to 
    calculate an MD5/SHA hash computed over:
	- the user's password
	- a secret key created and distributed by SFNB that is unique to 
	  the account holder
	- a login challenge (random number) issued by the server

    This hash, rather than the password, would be sent over the SSL 
    protected connection to authenticate the user.
	
2.  Distribute SecureID or some other token-based authentication device to
    account holders.  (Remember when banks used to give away toasters?).

With either approach server-spoof attacks are prevented, for the server 
cannot access the local key material or token.  Attacks against 40-bit keys 
are effectively negated, for any such attack would have to be mounted:

	- in real-time before the account holder logs out of the bank and
	  invalidates the session key.  SFNB imposes an inactivity log out.

	- from a gateway through which the account holder's SSL session is 
	  routed in order to grab control of the account holder's session
	  due to the complex cookie mechanism being used.

Note that even our final solution using hardware-based crypto is not 
perfect.  But then there is no such thing as perfect security.  SFNB does
have, even with its current implementation, a system that is more difficult
to defeat than current financial instruments such as paper checks, credit 
cards, ATM cards, etc...

Charles Watt
SecureWare, Inc.

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