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 ~ 2nd 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 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.

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 Data

RSA 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

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

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

MessageRSA

Encrypt SentError

ReceiveRSA

DecryptMessageError

7. This Function NEVER FAILS

Microsoft Outlook– Under load

• Anti-Virus– Almost 90% mail never scanned

Microsoft Internet Information Server (IIS)

Thread 1

Thread 2

Receive BufferDecrypt

Buffer Send

SSL

SSL

Encrypt

Microsoft Internet Information Server (IIS)

Thread 1

Thread 2

Receive BufferDecrypt

Buffer Send

SSL

SSL

Encrypt

Microsoft Internet Information Server (IIS)

Thread 1

Thread 2

Receive BufferDecrypt

Send

SSL

SSL

Encrypt

Buffer 2

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

?