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