Week 13 – Implementation Issues

bubblesradiographerΔιακομιστές

4 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

106 εμφανίσεις

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

Message

RSA

Encrypt

Sent

Error

Receive

RSA

Decrypt

Message

Error

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

Buffer

Decrypt

Buffer

Send

SSL

SSL

Encrypt

Microsoft Internet Information
Server (IIS)

Thread 1

Thread 2

Receive

Buffer

Decrypt

Buffer

Send

SSL

SSL

Encrypt

Microsoft Internet Information
Server (IIS)

Thread 1

Thread 2

Receive

Buffer

Decrypt

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

?