Week 12 Implementation Issues

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 2nd generation snake oil

4
Existing Work

• Very little relevant research
• Ross Andersons 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 Arent

• 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 dont understand the importance of
  protecting keys

7
1. Private Keys Arent - 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 Arent

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

9
1. Private Keys Arent

• 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 -gt 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 isnt synchronized
• Time zone offsets and DST
• Time isnt security-relevant

15
4. What Time is it Anyway?

• Dont 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 dont.

16
End of Part 1

Any Questions?
17
5. RSA in CBC Mode
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
• Dont include insecure or illogical security
  mechanisms in your crypto tools

19
PRNG

• Pseudo Random Number Generator

PRNG
Random
Seed
20
6. Exercise for the User

• OpenSSL 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
• 0123456789ABCDEF0
• 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.
  Dont leave hard problems as an exercise for the
  user

23
7. This Function NEVER FAILS
RSA Encrypt
Error
Message
Sent
RSA Decrypt
Error
Receive
Message
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
SSL
Receive
Buffer
Decrypt
Encrypt
SSL
Buffer
Send
Thread 2
26
Microsoft Internet Information Server (IIS)
Thread 1
SSL
Receive
Buffer
Decrypt
Encrypt
SSL
Buffer
Send
Thread 2
27
Microsoft Internet Information Server (IIS)
Thread 1
SSL
Receive
Buffer
Decrypt
Encrypt
SSL
Send
Buffer 2
Thread 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
  arent aware of

31
Conclusion

• Crypto Good
• Key Management Hard
• Crypto Primitives Good
• Using Properly Hard
• Library
• No Holes

32
Questions
?