Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Week 12 Implementation Issues Lessons Learned in Implementing and Deploying Crypto Software Gutmann Presented by Kevin Spillane and Jon Lin."— Presentation transcript:

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

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

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

4 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

5 Crypto Software: Problems and Solutions

6 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

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

8 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 with password to customers –CAs send their root certificate (with private key) to customers so they client keys will trust the root authority

9 1. Private Keys Aren’t If your product allows the export of private keys in plaintext form or some other widely- readable 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.

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

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

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

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

14 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

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

16 End of Part 1 Any Questions?

17 5. RSA in CBC Mode KeyData RSA 3 DES Data RSA

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

19 PRNG  Pseudo Random Number Generator Seed PRNG Random #

20 6. Exercise for the User OpenSSL Problems Constant Text String Rand() output Dummy data file Hash of files in current directory /etc/passwd /var/log/syslog Output of Unseeded Generator “ ABCDEF0” Empty (requires change to library)

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

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

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

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

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

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

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

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

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

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

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

32 Questions ?


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

Similar presentations


Ads by Google