Crypto Boot Camp

1
Crypto Boot Camp

• Toorcon 2007

2
Introduction
3
You have to become an enterprise crypto expert

• and you only have time for a two hour seminar.

4
Administrivia

• introductions
• site info (phones, bathrooms, etc.)
• its a hacker con. turn off your wireless. now.
  regret setting your voice mail to a 4 character
  password.
• hunt down your email vendor and kill them if they
  switch on pop3/clear when youre roaming

5
Seminar Format

• Two Hours
• Four sections
• Tools Demo/Break at mid-point
• Reference section in handout
• Collect pointers, dont try to memorize the
  crypto!

6
Agenda

• Introduction/Crypto Requirements
• Crypto Technology
• Crypto Tools and Protocols
• Deployment and Defense

7
Whats Cryptography?

• Mysterious incantations from a distant Nerd
  Planet
• Mathematical algorithms to protect data
• More overhead for your systems to perform
• more overhead for your networks to transmit
• Not Known Not To Work

8
include ltbuzzwords.hgt

• RSA
• DES
• Triple DES
• PKIX
• X.509
• TLS
• SSL
• SHTTP
• IPSEC
• SSH
• Effective Key Length

• SMIME
• Digital Signature
• Entropy
• Hash
• MAC
• MD5
• SHA-1
• SHA-256
• AES
• RC-4
• ROT-13

9
Requirements for Cryptography
10
High Level Requirements

• privacy
• authenticity
• low overhead
• simplicity

11
Network/Internet Requirements

• secure TCP connections
• protect payload data
• signed data
• authenticated access

12
Cryptography Requirements

• algorithms have to be secure
• has to run at speed
• acceptable as best practice
• interoperable
• as unbreakable as possible

13
Business Requirements

• Internet commerce
• Digital Signatures
• Site identification
• User identification
• System security
• Network security
• Trust delivery

14
Translation
15
Real world requirements

• use technology thats considered mainstream
• use algorithms that are approved
• use operating parameters that are considered
  safe by contemporary standards

16
Crypto Choices

• TLS (SSL) or IPSec or PGP or SMIME
• RSA public key cryptography
• AES bulk encryption
• SHA-2 class hashes
• current 21st century key sizes and lifetimes

17
Basic Crypto Technology
18
Cryptographic Technologies

• Encryption ciphers
• single (shared) key
• dual (RSA) key
• Hash one way functions
• MAC
• HMAC
• signatures

19
Cryptographic Components

• Keys
• Entropy
• Ciphertext
• Plaintext
• Encoding Formats
• Tokens

20
Cryptographic Operations

• Key Generation
• Encryption
• Decryption
• Hashing
• Entropy Gathering
• (Big Number) Arithmetic

21
Algorithms

• Symmetric Encryption
• DES
• Triple DES
• RC-4
• AES
• Camelia
• IDEA

22
Algorithms

• Hashes
• MD-5
• SHA-1
• SHA-256, -384, -512
• RIPEMD-160
• MD-4
• HMACs

23
Algorithms

• Dual-Key Encryption
• Diffie-Hellman
• RSA
• DSA
• Elliptic Curve

24
Symmetric Encryption

• single key shared between two parties
• one side encrypts with (Ki)
• the other side decrypts with (Ki)
• Fast bulk operations
• Issues
• key distribution
• algorithm strength
• key size
• processing speed

25
Hitchhikers Guide to Symmetric Key Encryption
(mid/late 2007)

• Use AES, 128 bit minimum
• Use Triple DES if AES is not available (3-key
  only)
• Use RC-4 (128 bit) if nothing else is available
• Never use any other algorithm
• Use approved/best-practice algorithms
• Never ever build your own crypto

26
Hashing

• one way function
• given a message it gives you a number
• different (modified) message gives a different
  number
• if you sign the hash with an (RSA) private key
  its a signature in the cryptographic sense

27
Hitchhikers Guide to Cryptographic Hashing
(mid/late 2007)

• Use SHA-256 or better
• Use SHA-1 if nothing better is available
• Use MD5 if no SHA is available
• Never use any other algorithm
• Use approved/best-practice algorithms
• Never ever build your own crypto
• Prepare for arguments about hash collisions

28
Dual-Key a/k/a Public KeyAlgorithms

• two keys, at least
• one key is ok to share (public key)
• one key must be maintained secret (private key)
• proof of posession of the private key proves your
  identity
• used for signing (encrypting hashes)
• used to encrypting some data (like keys)

29
Hitchhikers Guide to Dual-Key Encryption

• Use RSA
• Dont use DSA, EC (not practical in an
  enterprise)
• Use 2048 bit or better, if at all possible
• Get worried all your equipment only does 1024
• Never ever build your own crypto

30
Demo
31
Demonstration

• uses OpenSSL
• symmetric key encryption
• hashing
• RSA key generation
• CA/Certificate Issuance
• TLS, SSL 3, and SSL 2
• OpenPGP

32
Cryptographic Protocols
33
Cryptographic Protocols

• Link Encryptors
• OpenPGP
• SMIME
• SSL and TLS
• IPSec
• DRM

34
Link Encryptors

• talk to your grandfather about the KGs they used
  in Nam
• Symmetric key
• Key distribution is manual
• No algorithm agility
• Only encrypts the one hop

35
OpenPGP

• talk to old geeks about the Cypherpunks
• IETF RFC 2440
• Based on organic crypto developed by P.
  Zimmermann
• OpenPGP standardized by IETF
• PGP, Inc. sells a version, not the only one
• message (email or document) encryption and
  signing
• GnuPG open source reference

36
SMIME

• talk to old Infosec codgers about Verisign
• IETF Standards-track messaging security
• rarely used
• universally available (in Outlook and
  Thunderbird)
• requires a PKI
• email encryption and signing
• Thunderbird - open source reference

37
SSL/TLS

• talk to a Netscape millionaire about browsers
• IETF RFC 2246 defines TLS
• SSL was a Netscape invention
• SSL 1 was broken during construction
• SSL 2 was broken a few years ago
• SSL 3 isnt perfect but is usable
• Uses PKI
• TCP connection encryption
• Used for ecommerce, tunnels
• OpenSSL - open source reference

38
Hitchhikers Guide to Certificates

• its PKIX, not X.509 (RFC 2459)
• a certificate is a public key and some naming
  stuff, digitally signed by someone you trust
• some CAs can be trusted some of the time
• just because theyre a CA doesnt mean you should
  trust them
• the critical thing the name in the cert must
  match the alleged name

39
IPSec

• the last organically developed security protocol
• recreates mid-80s military grade network
  encryption
• IP encryption and authentication
• IETF RFCs 2401, etc.
• Uses pre-shared secrets a/k/a passwords or
  certificates or more complex authentication
  schemes
• rich key management options
• universally implemented overly complex

40
DRM

• talk to a filesharer next time you visit a prison
• digital signatures can be weaponized into digital
  watermarks
• used for data use enforcement
• typically unpublished and sometimes dodgy crypto

41
Deployment
42
Hitchhikers Guide to the Crypto Marketplace

• there are charlatans out there
• dont buy homebrew crypto
• dont assume the big names do the good
  implementations
• only buy mainstream, approved, best-practice
  technology
• dont assume the vendor turns on the crypto

43
Deployment Issues

• Performance
• Set-up (PKI, configuration)
• Maintenance
• Keeping up with vulnerabilities

44
Crypto Performance

• AES and RSA are no more work than other complex
  tasks performed by modern silicon
• scaled, it can be tough (what if all of Google
  were in TLS)
• encrypt at the endpoints if you can
• dont forget infrastructure overhead

45
Crypto Set-up (1)

• if its symmetric key crypto it should be
  scheduled for replacement
• PKI
• need a certificate authority
• need certificate request/fulfillment process
• need secure storage of private key
• need certificate infrastructure
• need certificate maintenance

46
Crypto Set-up (2)

• select cryto parameters
• dont assume the vendors defaults are safe
• prepare a troubleshooting plan in case
• you need to test something with the crypto turned
  on
• you need to temporarily turn the crypto off
• you need to monitor whats inside the encrypted
  path

47
Deployment Complexities

• monitoring TLS connections is rarely completely
  legal
• Key backup of enterprise keys is normal
  business, not evil
• key recovery by use of technology is not safe and
  probably evil
• need algorithm agility in case someone breaks
  something (the vulnerability update problem)

48
Why is Crypto Hard

• the geeks are very good with intimidating
  buzzwords
• the cryptographers dont talk to the engineers
• the engineers cant control the marketeers
• the end-users keep switching it off
• different priesthood, different language,
  different value system
• implementors are rarely competent and usually
  lazy, q-a is rarely existant and often lets bad
  things through
• really about the same difficulty as an OS, a
  database, a large network, or getting your
  animated icons to work in myspace.

49
Defending Crypto
50
Crypto Defense Myths

• it was built by ltvendorgt, it must be safe
• large key sizes will save you
• nobody reads those dialog boxes anyway
• logging? we dont need no stinking logging!
• its Common Criteria Certified therefore it must
  be safe
• the military uses it, it must be secure

51
Defend your key material!
52
Crypto Attack Surface (1)

• the algorithms
• rc-4 is bad
• des is bad
• aes is good
• triple-DES is probably not bad
• SHA-256 is good
• SHA-1, MD5, RIPMED-160 are probably ok for now
  but should be avoided

53
Crypto Attack Surface (2)

• a secure algorithm implemented poorly is quite
  attackable
• dont print passwords in the clear
• defend your key material
• implementation must be sound
• and up to date (OpenSSL 0.9.8? is current?)

54
Crypto Attack Surface (3)

• vendors are lazy
• home-brew crypto
• poor password storage/selection
• poor crypto options (why is ATT running SSL2 in
  SeaTac?)
• products offer poor choices
• self-signed certificates rarely safe, as
  delivered
• nobody should be shipping DES in 2007

55
What can you do

• make sure your maintance/update program addresses
  your crypto usage
• make sure your gear is deployed in secure
  configurations
• use the telemetry you have
• dont let your users select unsafe parameters (1
  character password on salesforce.com)

56
References

• Handbook of Applied Cryptography
• Applied Cryptography (Schneier)
• Viega
• Rescorla
• P. Gutmann X.509 Style Guide http//www.cs.aucklan
  d.ac.nz/pgut001/pubs/x509guide.txt
• www.apache-ssl.org
• www.openssl.org
• www.gnupg.org

• OpenPGP RFC 2440
• TLS RFC 2246
• IPSec RFC 2401, 2411, etc.
• PKIX RFC 2459 etc. and CCITT X.509
• RFC 3766 on Public Key Strength

57
Thank you.

• Rodney Thayer
• rodney_at_thesecurityconsortium.net

58
About TSC

• The Security Consortium is a network/product
  laboratory that focuses on thorough testing of
  security products and implementations. Were
  located in San Jose California. We test
  products, do security research, offer training
  and professional services in the security
  marketplace.
• We let the smoke out so you dont have to
• The Security Consortium www.thesecurityconsortium.
  net