Week 12 Implementation Issues Lessons Learned in Implementing

Week 12 Implementation Issues Lessons Learned in Implementing and Deploying Crypto Software Gutmann Presented by Kevin Spillane and Jon Lin

Overview ¨ Getting crypto right is hard ¨ Good crypto primitives, implemented incorrectly, leads to poor security ¨ Crypto designers can safeguard their products to make them more idiot-proof ¨ Eight problem areas addressed in the paper ¨ Sit Back. Relax. No Math Proofs! (promise)

Introduction ¨ “The determined programmer can produce snake oil using any crypto tools” ¨ Naugahyde Crypto ~ 2 nd generation snake oil

Existing Work ¨ Very little relevant research – Ross Anderson’s papers on banking security – A paper on PGP user interface problems – Bruce Schneider in Secrets and Lies “the world was full of bad security systems designed by people who read [his first book, Applied Cryptography]” – Several works on how to program securely

Crypto Software: Problems and Solutions

1. Private Keys Aren’t ¨ Security is lost when private keys are revealed to others ¨ People seem to really want to expose private keys. Why? – Certificates are expensive – Certificates are complex to obtain and setup – People don’t understand the importance of protecting keys

1. Private Keys Aren’t - Example • Vendor discovered they had – Copies of the key on their file server with the source code – In other locations with the application binaries – Developers had copied the keys to their machines while testing the application and never removed them. – Some of the developer machines had migrated to new employees with the keys still on the system – File server had hard drives upgraded; original drives with keys were sitting on the shelf – Servers were backed up regularly; tapes with keys were stored in the back seats of administrators cars (off-site storage)

1. Private Keys Aren’t It’s too easy to move private keys around. – Some CAs send certificate (with private key) in a plain text e-mail with password to customers – CAs send their root certificate (with private key) to customers so they client keys will trust the root authority

1. Private Keys Aren’t If your product allows the export of private keys in plaintext form or some other widelyreadable format, you should assume that your keys will end up in every other application on the system, and occasionally spread across other systems as well.

2. Everything is a Certificate ¨ PFX -> PKCS #12 ¨ Internet Kiosks ¨ PKCS #12 = private key + X. 509 certificate

2. Everything is a Certificate Make very clear to the user the difference between public and private keys, either in the documentation/user interface or, better, by physically separating the two.

3. Making Key Management Easy ¨ Key management is difficult ¨ Ways users have found to make key management easy – Symmetric Keys • Embedding keys in messages (EDI, XML) • Same key for everyone (WEP) – Public Key • Same key for everyone. Problem solved!

3. Making Key Management Easy Straight Diffie-Hellman requires no key management. This is always better than other no-key-management alternatives which users will create.

4. What Time is it Anyway? ¨ Assuming synchronized time among systems in a PKI is dangerous. – Many published works – Time isn’t synchronized – Time zone offsets and DST – Time isn’t security-relevant

4. What Time is it Anyway? Don’t incorporate the system clock (or other parties’ system clocks) in your security baseline. If you need synchronization, use nonces. In the presence of arbitrary end user systems, relative time measures work. Absolute time measures don’t.

End of Part 1 Any Questions?

5. RSA in CBC Mode Key RSA Data 3 DES Data RSA

5. RSA in CBC Mode ¨ Encrypt with RSA – Perform bulk data encryption • SLOW – Key exchange mechanism – Java Cryptographic Extension API • Allows weird combinations – RSA in CBC mode ¨ “ Don’t include insecure or illogical security mechanisms in your crypto tools ”

PRNG ¨ Pseudo Random Number Generator Seed PRNG Random #

6. Exercise for the User • Open. SSL 0. 9. 5 • Problems • Constant Text String • Rand() output • Dummy data file • Hash of files in current directory • /etc/passwd • /var/log/syslog • Output of Unseeded Generator

6. Exercise for the User (2) – Outcome • Easily Attacked – Fix • /dev/random

6. Exercise for the User “ If a security-related problem is difficult for a crypt developer to solve, there is no way a non-crypto user can be expected to solve it. Don’t leave hard problems as an exercise for the user ”

7. This Function NEVER FAILS Message RSA Encrypt Receive RSA Decrypt Error Sent Error Message

7. This Function NEVER FAILS ¨ Microsoft Outlook – Under load • Anti-Virus – Almost 90% mail never scanned

Microsoft Internet Information Server (IIS) Thread 1 SSL Receive Decrypt Buffer Send Thread 2 Buffer SSL Encrypt

Microsoft Internet Information Server (IIS) Thread 1 SSL Receive Decrypt Buffer Send Thread 2 Buffer SSL Encrypt

Microsoft Internet Information Server (IIS) Thread 1 SSL Receive Buffer 2 Decrypt Send Thread 2 Buffer SSL Encrypt

7. This Function Never Fails ¨ Solution – Set output data to non-value – Use Handles to State Information “ Make security-critical functions fail obviously even if the user ignores return codes ”

8. Careful with that Axe, Eugene ¨ New that we have good primitives, people use them incorrectly – ECB instead of CBC ¨ Reading Applied Cryptography makes you a cryptographer, right?

8. Careful with that Axe, Eugene “ Provide crypto functionality at the highest level possible in order to prevent users from injuring themselves and others through misuse of low-level crypto functions with properties they aren’t aware of ”

Conclusion ¨ Crypto Good – Key Management Hard ¨ Crypto Primitives Good – Using Properly Hard ¨ Library – No Holes

Questions ?