SWE 681 / ISA 681
Secure Software Design &
Programming:
Lecture 7: Cryptography
Dr. David A. Wheeler
2014-06-29
Outline
•
•
•
•
Introduction
Basic crypto algorithms
Storing passwords (salted hashes)
Basic protocols
2
Cryptography & Cryptanalysis
• Cryptography = the science (or art) of
transforming intelligible data to an unintelligible
form, and its inverse transformation
– Means “Secret writing”
• Cryptanalysis = the science (or art) of undoing the
cryptographic transformation without (exact)
knowledge of how that transformation was
initially executed
• We’ll focus on cryptography (defense),
emphasizing how to counter cryptanalysis
(attack)
3
What cryptography is… and is not
• Cryptography is a set of tools that can help
develop secure software
– Important component in some cases
• Cryptography won’t solve most security issues
– Cryptography is not the same as developing
secure software
– “If you think cryptography is the answer to your
problem, then you don’t know what your problem
is” – Peter Neumann
4
Danger, Will Robinson
• Never, never, never, never, never, never, never
create your cryptographic algorithm or protocol
– Specialist training: PhD in math + 10+ years
experience to create new approaches
– Even then, the odds are good you’ll get it wrong
– Reuse what’s been done
• Be very cautious; tiny implementation errors of
crypto algorithms, or in how they are invoked,
often become massive vulnerabilities
– Reuse good implementations where practical
8 April 2015
5
Enigma
• Nazi Germany used the
“Enigma” machine widely
• Ally cryptanalysis broke it
& got extremely valuable
intelligence (“Ultra”)
• Value debated, but
Winston Churchill told
King George VI, “It was
thanks to Ultra that we
won the war”
Source: NSA (via Wikipedia)
6
Some common basic types of
cryptographic algorithms
• Symmetric (secret/shared key) encryption/decryption
– Algorithm examples: DES*, 3DES, AES
• Key exchange
– Algorithm examples: Diffie-Hellman, Curve25519
• Asymmetric (public key) encryption/decryption
– Algorithm examples: RSA, elliptic curve family
• Cryptographic (one-way) hash (aka “digital fingerprint”)
– Algorithm examples: MD5*, SHA-1*, SHA-512, SHA-3
• Cryptographic pseudo-random number generator (PRNG)
* These are examples; do not use these algorithms in future systems
7
Symmetric (secret/shared key)
encryption/decryption
• Symmetric encryption/decryption algorithms
use the same value (“key”) to encrypt and
later decrypt
Secret key
Plaintext
Encrypt
Ciphertext
(encrypted text)
Decrypt
Plaintext
8
Data Encryption Standard (DES)
•
•
•
•
•
•
1973: NIST solicited for a DES
1974: NIST second solicitation, IBM responded
1975: Algorithm published
1976: NIST Workshop, adequate “10-15 years”
1977: DES standardized (FIPS)
Has held up relatively well over time
– Do need to avoid weak/semi-weak keys
• Slow in software
• Big problem: Key only 56 variable bits
– 64 bit key, but every 8th bit is odd parity (beware: may use known key
if don’t give correct parity!)
– Easily broken with modern computers/hardware
– Do not use DES for security today
9
Triple DES
• Uses DES 3 times, with 3 keys K1…K3:
– ciphertext = E(K3, D(K2, E(K1, plaintext)))
– plaintext = D(K1, E(K2, D(K3, ciphertext)))
• Each DES key 56 bits, full key length 3x56=168 bits
– Effective key length strength is 112 bits due to a “man in the
middle” attack
– Just like DES, keys must have correct parity & avoid weak keys
• Relatively secure, but slow
• Defined, as Triple Data Encryption Algorithm, in:
– NIST Special Publication 800-67 Revision 1
– ISO/IEC 18033-3:2005 Information technology — Security
techniques — Encryption algorithms — Part 3: Block ciphers
10
Advanced Encryption Standard
(AES)
• Replaced DES
– DES key too short, 3DES too slow
• Developed through open international
competition run by NIST
– Required algorithms & sample implementation
– Forbid patents (so anyone can use)
– Competition was a fantastic success
• 15 candidates; Rijdael won & became AES
– U.S. FIPS PUB 197
• A simple-to-understand detailed description is at:
http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html
11
AES (2)
• Rijndael algorithm allows block and key sizes
of any multiple of 32 bits, 128…256 bits
• AES is a limited variant of Rijndael with block
size=128, key sizes = 128, 192, or 256 bits
– Algorithm internally repeats; as key lengthens,
number of iterations increases
– 128bit key=> 10 cycles, 192bit => 12, 256bit => 14
• Much faster than 3DES, longer keys
12
Key exchange
• Communicate partial information so communicating
parties establish shared secret without exposure
(parties might not authenticate!)
Alice
Shared & unrevealed key
Communication
Bob
Shared & unrevealed key
13
Diffie-Hellman key exchange
• Aka “Diffie–Hellman–Merkle” key exchange
• First published in 1976
• Allows two parties, without prior knowledge, to jointly establish a
shared secret key over an insecure communications channel
– Key can then be used to encrypt subsequent communications using a
symmetric key cipher
– Does not authenticate (vulnerable to man-in-the-middle) by itself, but
other mechanisms can be used to address this
• Used in Transport Layer Security (TLS) ephemeral modes (EDH or
DHE) to provide perfect forward secrecy
– Perfect forward secrecy = each session generates random public keys
without using a deterministic algorithm. Thus, if a session key is
compromised, newer & older session keys are not
14
Diffie-Hellman illustrated
• Alice and Bob exchange
their secret colors
(representing numbers)
via public transport only
as a mix
• Original version of D-H
uses multiplicative group
of integers modulo p
Credit: https://en.wikipedia.org/
wiki/Diffie%E2%80%93Hellman_key_exchan
ge as of 2014-04-16
15
Curve25519
• Developed by D. J. Bernstein
• Intended to be “a state-of-the-art Diffie-Hellman function”
– “Given a user's 32-byte secret key, Curve25519 computes the
user's 32-byte public key.”
– “Given user's 32-byte secret key and another user's 32-byte
public key, Curve25519 computes a 32-byte secret shared by the
two users. This secret can then be used to authenticate and
encrypt messages between the two users.”
• Based on elliptic-curve cryptography
• Ed25519 is a related public-key elliptic-curve signature
system
• More info: “Curve25519: new Diffie-Hellman speed
records” by Daniel J. Bernstein, http://cr.yp.to/ecdh.html
16
Asymmetric (public key)
encryption/decryption
• Asymmetric encryption/decryption algorithms
use two different values (“keys”) to encrypt
and later decrypt
Decryption key
Encryption key
Plaintext
Encrypt
Ciphertext
(encrypted text)
Decrypt
Plaintext
17
RSA
• Named after Rivest, Shamir, & Adleman
• Public key crypto based on difficulty of factoring
into prime numbers
– Public key & private key
– Encryption & decryption raise “message” by large
exponent
• Patent released/expired in 2000
• Don’t use RSA keys < 1024 bits; 2048+ better
– On August 14, 2012, Microsoft issued update to
Windows XP & later to block RSA keys <1024 bits
18
Elliptic curve cryptography (ECC)
• Algorithms based on elliptic curves presume it’s infeasible
to find the discrete logarithm of a random elliptic curve
element, w.r.t. a publicly known base point
– This is “elliptic curve discrete logarithm problem” (ECDLP)
– Smaller key size for equivalent protection, e.g., 256 ECC key ~
3072 bit RSA key
– Developed in 1985 by Neal Koblitz and Victor Miller
– Very general approach, many algorithms based on ECC
– Intro: http://arstechnica.com/security/2013/10/a-relativelyeasy-to-understand-primer-on-elliptic-curve-cryptography/
• Several ECC algorithms included in NSA’s suite B (a suite of
encryption algorithms)
19
Issue: Elliptic Curve Cryptography
(ECC) & patents
• Patent concerns are primary inhibitor of ECC use
– ECC application may in some cases be inhibited in US by patents (Certicom)
– Often unclear what’s covered (typical software patent problem)
– RSA claims: “ECC… have no general patents, though some newer elliptic curve
algorithms and certain efficient implementation techniques may be covered
by patents… it is the implementation technique that is patented, not the
prime or representation, and there are alternative, compatible
implementation techniques that are not covered by the patents…”
• http://web.archive.org/web/20130524001754/http://www.rsa.com/rsalabs/node.asp?id=2325
– IETF RFC 6090 (released 2011) describes the fundamental ECC algorithms as
defined seminal references from 1994 and earlier, with the goal of allowing
patent-free implementation… but patent holders can always sue anyway
• US government has a license for national security uses
– That doesn’t help the rest of us!
– All parties have to agree before they can use a crypto algorithm
– http://www.nsa.gov/business/programs/elliptic_curve.shtml
• Yet another example of how software patents put computer users &
software developers at risk & inhibit innovation
20
Asymmetric often used with
symmetric algorithms
• Asymmetric algorithms tend to be slow
• When used to encrypt, often used with
symmetric algorithm
– Sender creates single-use “shared” key using
cryptographically secure pseudo-random number
generator
– Shared key encrypted using asymmetric algorithm
– Receiver receives & decrypts shared key
– Rest of data is encrypted with (faster) symmetric
algorithm using this single-use key
21
Cryptographic (one-way) hash
function
• Cryptographic (one-way) hash function takes
arbitrary-length data & generates fixed-length
hash (“fingerprint”) so infeasible to:
– Create another message with a given hash value
(“preimage resistance”)
– Create another (modified?) message with same hash
as first message (“second preimage resistance”)
– Create any two messages with same hash (“collision
resistance”)
Message
Hash
Cryptographic hash
(fingerprint, digest) – fixed width
22
Cryptographic Hash
• Overall goal: Adversary can’t replace or modify
data without changing fingerprint
• Some uses:
– Verifying integrity – just store fingerprint, verify by
recomputing to ensure unchanged/expected
– Digital signing – Use private key to “encrypt”
fingerprint; anyone can use public key to verify
– File id – e.g., CM systems
– Creating “random” values
– Password storage (“salted hashes”)
23
Cryptographic hash algorithms:
MD5, SHA-1, SHA-2
• MD5: Was widely used, but now broken
• SHA-1: Many moved to it, still widely used
– Cryptanalysis work in 2004 found important
weaknesses
– Recommendation: gradually move from it
• SHA-2
– Family: SHA-224, SHA-256, SHA-384, SHA-512
– Technical similarities with SHA-1 raised concerns
24
Cryptographic hash algorithms:
SHA-3
• NIST announced on November 2, 2007 a
public competition to develop a new
cryptographic hash algorithm, SHA-3
• NIST received sixty-four entries from
cryptographers around the world by October
31, 2008
• NIST announced Keccak as the winner of the
SHA-3 competition on October 2, 2012
25
Lifecycles of popular crytographic
hashes (Valerie Aurora)
1
9
9
0
Function
1
9
9
1
1
9
9
2
1
9
9
3
1
9
9
4
1
9
9
5
1
9
9
6
1
9
9
7
1
9
9
8
1
9
9
9
2
0
0
0
2
0
0
1
Snefru
MD4
MD5
MD2
2
0
0
2
2
0
0
3
2
0
0
4
2
0
0
5
2
0
0
6
2
0
0
7
2
0
0
8
2
0
0
9
2
0
1
0
2
0
1
1
2
0
1
2
In 2004 Xiaoyun
Wang et al.
published
“Collisions for Hash
Functions MD4,
MD5, HAVAL-128
and RIPEMD.”
RIPEMD-128 is
only 128-bit,
“irresponsible
based on sheer
digest length”
because at best it’s
2^64 complexity to
break
RIPEMD
HAVAL-128
SHA-0
SHA-1
RIPEMD-128
RIPEMD-160
SHA-2 family
SHA-3 (Keccak)
Key: Unbroken
Weakened
Broken
Deprecated
Source: “Lifecycles of popular crytographic hashes”,
Valerie Aurora,
http://valerieaurora.org/hash.html
26
Reactions to stages in the life cycle
of cryptographic hash functions
Stage
Expert reaction
Programmer reaction
Non-expert ("slashdotter") reaction
Initial proposal
Skepticism, don't recommend use
in practice
Wait to hear from the experts before
adding to OpenSSL
SHA-what?
Peer reviewal
Moderate effort to find holes and
garner an easy publication
Used by a particularly adventurous
developers for specific purposes
Name-drop the hash at cocktail parties to
impress other geeks
General acceptance
Top-level researchers begin serious
work on finding a weakness (and
international fame)
Even Microsoft is using the hash function
now
Flame anyone who suggests the function
may be broken in our lifetime
Minor weakness
discovered
Massive downloads of turgid preprints from arXiv, calls for new hash
functions
Start reviewing other hash functions for
replacement
Long semi-mathematical posts comparing
the complexity of the attack to the number
of protons in the universe
Serious weakness
discovered
Tension-filled CRYPTO rump
sessions! A full break is considered
inevitable
Migrate to new hash functions
immediately, where necessary
Point out that no actual collisions have been
found
First collision found
Uncork the champagne! Interest in
the details of the construction, but
no surprise
Gather around a co-worker's computer,
comparing the colliding inputs and
running the hash function on them
Explain why a simple collision attack is still
useless, it's really the second pre-image
attack that counts
Meaningful collisions
generated on home
computer
How adorable! I'm busy trying to
break this new hash function,
though
Send each other colliding X.509
certificates as pranks
Tell people at parties that you always knew
it would be broken
Collisions generated by
hand
Memorize as fun party trick for
next faculty mixer
Boggle
Try to remember how to do long division by
hand
Assumed to be weak but
no one bothers to break
No one is getting a publication out
of breaking this
What's this crypto library function for?
Update Pokemon Wikipedia pages
Source: “Lifecycles of popular crytographic hashes”, Valerie Aurora, http://valerieaurora.org/hash.html
27
Cryptographic algorithms are often
(eventually) broken
• Cryptanalysis is an active field
– Sometimes advances lead to weakening/break in
algorithms… even ones considered secure before
– Lifecycles of cryptographic hashes good illustration
• Make sure you can change algorithms!
– Designs should not assume that crypto algorithms
never change
• Best to have at least two algorithms implemented
– So you can switch away from “broken” one
28
RSA & DH: Some concerns
• Concerns about RSA & Diffie-Hellman (DH) raised at Black Hat 2013
– RSA and DH underpinned by difficulty of “discrete logarithm problem”
– French academic Antoine Joux published two papers suggesting an algorithm
to break it could be found before long
– “Our conclusion is there is a small but definite chance that RSA and classic
Diffie-Hellman will not be usable for encryption purposes in four to five years”
- Alex Stamos, chief technology officer, Artemis
– “The RSA protocol that is the foundation of security on the Internet is likely to
be broken in the very near future,” Philippe Courtot, CEO of Qualys
– http://www.technologyreview.com/news/517781/math-advances-raise-theprospect-of-an-internet-security-crisis/).
• Elliptic Curve Cryptography (ECC) techniques available
– May be inhibited in US by Certicom patents (patents vs. security), as noted
earlier
• No evidence NIST will start a new public key crypto competition – why?!?
29
Use what you check
(Android “Master Key”)
• CVE-2013-4787 / Android bug 8219321
– Reported to Google by Jeff Forristal (Rain Forest
Puppy)
– Packages are really “zip” archive files
– Special zip files can be created where >1 file can exist
in a directory with same name
– One is checked for its fingerprint… but a different one
is actually installed
• App stores can check for such malformed zip files
30
Cryptographic pseudo-random
number generator (PRNG)
• Many algorithms depend on secret keys or
“nonce” that won’t be reused
• A great way to get these is to generate a random
number (if enough bits)
• Software fundamentally deterministic
– Where can, use hardware for truly random value
helpful
– But can’t always use them, or just them, or trust them
• Pseudo-random number generators create
“random” data
– So attackers cannot determine past/future values
31
Use cryptographic PRNG for crypto
• Many “random” functions are easily predicted by an attacker
– Often implemented as linear congruential generator (LCG)
– E.G., Java Random()
• Must use cryptographically secure PRNG (CSPRNG) for crypto and
security-related tasks - not ones easily predicted
– Java: SecureRandom()
– Linux/Unix: read from /dev/random
• Read /dev/urandom if you just can’t wait, but urandom will return data even if
it has poor randomness
• Many algorithms exist to implement CSPRNGs. Examples:
– Yarrow, Fortuna, ANSI X9.17 (which can use any block cipher, e.g., AES)
– NIST SP 800-90A’s Hash_DRBG, HMAC_DRBG, and CTR_DRBG (do not
use the removed algorithm Dual_EC_DRBG)
• Be careful seeding them; ensure seed can’t be guessed
– Time-of-day (current or boot) is easy to guess
32
Dual_EC_DRBG Controversy
•
Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG)
–
–
–
–
•
•
Was part of NIST SP 800-90A (1 of 4 algorithms)
Three orders of magnitude slower than other 3
Brown raised concerns in 2006
Dan Shumow and Niels Ferguson re-raised concerns in 2007
Edward Snowden’s leaks excerpted by The New York Times led to strong suspicions
that this algorithm was subverted (kleptographic attack/backdoor)
RSA used Dual_EC_DRBG as default algorithm in its BSAFE and Data Protection
Manager products
– Surprising choice given its poor performance & the re-raised concerns in 2007
– Reuters reported on 2013-12-20 a $10 million deal between RSA and NSA to set
Dual_EC_DRBG as the default CSPRNG in BSAFE
•
http://www.reuters.com/article/2013/12/20/us-usa-security-rsa-idUSBRE9BJ1C220131220
– RSA Security categorically denies that it entered into a secret contract with NSA to incorporate
a known flawed random number generator into its BSAFE encryption libraries; much debate
•
•
https://blogs.rsa.com/news-media/rsa-response/ and http://arstechnica.com/security/2013/12/rsaissues-non-denying-denial-of-nsa-deal-to-favor-flawed-crypto-code/
“NIST strongly recommends that, pending the resolution of the security concerns
and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January
2012 version of SP 800-90A, no longer be used…. Effective immediately, NIST
Special Publication 800-90A is being re-issued as a draft for public comment..”
33
PRNG failure example:
iOS 7 early_random()
• Many Apple iOS vulnerability countermeasures depend on randomness
that cannot be predicted by attacker
– Many randomness-gathering mechanisms not available early in boot process
– Apple provides early_random() PRNG (pseudo-random number generator)
• iOS 7 update changed algorithm… to a horrifically-bad linear congruential
generator (LCG) algorithm!
– Trivial to brute-force, and then determine previous/later values. It can only
produce 2^19 unique outputs, with a maximum period of 2^17, far below
2^64 output space
– “An unprivileged attacker, even when confined by the most restrictive
sandbox, can recover arbitrary outputs from the generator and consequently
bypass all the exploit mitigations that rely on the early random PRNG”
• More info:
– “Revisiting iOS Kernel (In)Security: Attacking the early random() PRNG” by
Tarjei Mandt, Azimuth Security http://mista.nu/research/early_randompaper.pdf - presented at CanSecWest 2014
– http://www.theregister.co.uk/2014/03/16/ios_7_has_weak_random_number
_generator/
34
Crypto algorithm: Simple, stream,
and block-level
• “Simple” algorithms work symbol-at-a-time
– Read a byte, determine what to translate that to
• Block-level algorithms
– Group symbols together into blocks
– Replace sequence of blocks
• Later byte in same block changes encoding of this byte
– Many modern algorithms work this way
• Stream algorithms
– Work bit-at-a-time
35
Notes about block algorithms
• Block encryption algorithms can be used in a number
of different modes, including:
– Electronic code book (ECB)
• Same block of data returns the same result
– Cipher block chaining (CBC)
• Same block of data returns different result, depending on past
blocks in the same stream
• Never use ECB mode; CBC is far better than ECB
– Returning same block each time often reveals too much
• Many modes require an “initialization vector” (IV)
– Need not be secret, but must be unpredictable
– Create new IV each session; don’t reuse IVs
36
Storing passwords: Things to avoid
• Never store passwords as clear text (see Sony)
– Attackers can masquerade as any user on your
system & many others (password reuse)
• Storing as hashes helps, but not much
– Attackers can precalculate hashes of likely
passwords, then compare
– Attackers can easily see who has same passwords
37
Storing passwords:
Basics of salted hashes
• Store salted hashes of passwords
–
–
–
–
Hash(user “salt” + user password) for that user
Since different users have different salts, precompute fails
Attacker can’t easily see if two users use same passwords
Salts need to have enough random bits (NIST SP 800-132
requires 128+ bits)
• Use cryptographically secure pseudo-random number generator
– Use secure hash functions (SHA-512, not SHA-1 or MD5)
• On user log in, just repeat process
– See if the result is the same as stored salted hash
• Prevents social engineering “can you tell me my
password?” – because you can’t easily do it
• Can make even stronger with key derivation functions…
38
Key Derivation Functions
• “Key derivation functions” computes a derived key
– Repeatedly uses cryptographic hash, cipher, or HMAC + original data +
salt to generate derived key
– Doing it repeatedly makes it intentionally slow, thus making password
cracking more difficult (“key stretching”)
• PBKDF2 (Password-Based Key Derivation Function 2) common
– RSA Laboratories' Public-Key Cryptography Standards (PKCS) #5 v2.0
– Also RFC 2898
– “Recommendation for Password-Based Key Derivation” NIST Special
Publication 800-132
• Alternative function: bcrypt (counters hardware/GPU)
• Can use “HMAC” instead of cryptographic hash directly – use
special key known just to server as part of hash
– Hide this key, even from attackers who “own” system
– Counters offline attack.. but only if you can prevent getting that key
39
Beware of client hashing password
• Usual approach: Client sends
normal password over encrypted
channel
• Usually wrong for only client to
create & send salted hash
– If attacker modifies/replaces client,
modified client can just repeat the
hashed value on server & get in
Client
Server stores
hash(salt+Sent)
Client
• Okay to hash on both sides
– Hashing on client end means that
attacker-controlled server can’t see
client’s original password (bonus!)
– Hashing on server end means that
attacker-controlled client can’t use
stored hash to log in to this or other
servers (usual purpose for hashed
passwords)
Sent=password
Sent=hash(salt+
password)
Server stores
Sent
Client
Sent=hash(salt+
password)
Server stores
hash(salt+Sent)
40
What should you use?
• Crypto algorithms often broken over time; support switching algorithms*
• Shared-secret encryption – do not use DES (key is too short)
– For now, use (at least) AES
– Support at least 3DES as alternate (slow, but secure due to decades of attack)
• Hashing (“fingerprinting”) – do not use MD5
– Move smartly away from weakening SHA-1
– SHA-2’s SHA-256 or SHA-512 are useful & widely available, but some concerns
– Consider (also) using SHA-3; at least make it easy to switch to SHA-3
• Public key
– Usually RSA (patents expired); again, make it easy to switch
– Elliptic key cryptography has smaller key sizes, but patent issues lurk
• Randomness - do not use most “random” functions (easily guessed by attacker)
– Use cryptographic PRNGs, e.g., Linux /dev/random, Java SecureRandom()
8 April 2015
* Have I said this before? 
41
Keeping secrets
• Often need passwords/keys for program
– E.G., for database system, external sites
•
•
•
•
Don’t build into source… store separately
Minimize what processes have secret
Minimize time keeping secrets
Erase securely ASAP
– This is harder than you’d think!
– Lock into memory with mlock() / VirtualLock()
– Ensure that garbage collector won’t make extra copies, and will really
get rid of it
• SecureString in .NET
• Haven’t found good way in Java; String worst, char[] arrays better
– Overwrite… and make sure compiler doesn’t “optimize away” the
overwrite!
42
Digital certificates
• Electronic document (file) that binds a public
key with an identity (person/organization)
• Typically has other information
• Usual format: X.509
• Can be signed by others; often in a chain,
leading back to some root certificate(s)
• Some root certificates built into web
browsers, providing a place to start
43
Cryptographic protocols
• Build on crypto algorithms to create
confidentiality & integrity
– Secure Socket Layer (SSL) / Transport Layer
Security (TLS) – “https:”; officially TLS is new name
– Internet Protocol Security (IPSec) – often used for
Virtual Private Networks
– SSH: Secures remote terminals
– Kerberos: Single-sign-on/authentication over
network (Windows uses proprietary variant)
44
SSL/TLS cert validation often
implemented incorrectly
• Common errors:
– Failure to verify chain-of-trust
– Failure verify hostname (certs only valid for given hostname or pattern!)
– Failure to deal with certification revocation & X.509 extensions (key usage
limits, name constraints, etc.)
• Cause: Confusing APIs in SSL/TLS & data transport libraries
– OpenSSL SSL_connect: Return value signals some errors, but if “OK” must then
check “verify result” flags
– Java SSLSocketFactory doesn’t always verify hostname
– cURL: if CURLOPT_SSL_VERIFYHOST=true, hostname check disabled
•
•
•
•
Always test code with abnormal certs (unknown, wrong host, etc.)
In test environment add self-signed certs/CAs to keystore; don’t disable
Read API docs carefully, explicitly set options, carefully check results
Read “The most dangerous code in the world: Validating SSL certificates in
non-browser software” by Goergiev et al, 2012
45
Public Key Infrastructure (PKI) /
Certificate Authority (CA) Issues (1)
• Most protocols authenticate the server (destination) by checking
certificates
– How can you be sure that the certificate belongs to that server?
– Accepting a wrong one leads to man-in-the-middle attack
– “PKI” provides certificates, e.g., from 1+ certificate authorities (CAs)
• Unfortunately, many CAs untrustworthy
– Summary: “Defcon 19: Moxie Marlinspike - SSL And The Future Of
Authenticity” http://www.youtube.com/watch?v=xIiklPyS8MU
– Throw away “bad” CAs = can’t access most of the Internet
– Some organizations even self-subvert!
• TLS/SSL still helpful, but greatly weakened because of this
– Originally designed vs. passive attacks, authenticity was “a bit of a hand wave”
• No easy solution, and not enough people working to solve it
– In some scenarios “certificate pinning” & DNSSEC can help
46
Public Key Infrastructure (PKI) /
Certificate Authority (CA) Issues (2)
• Need to revoke compromised certificates, but…
• Currently-available revocation mechanisms broken
– Certificate Revocation List (CRL)(: Client downloads revocation
list. Slow, attacker can prevent, hasn’t scaled with Internet
– Online Certificate Status Protocol (OCSP): Client online query.
Slow, attacker can prevent
– OCSP Stapling: Server online query & provides to client.
Attacker can prevent (by filtering out)
– CRLSets: Blacklist of known bad certs. Attacker can prevent
CRLSet download, only revokes a few (popular) certificates
– Must-staple HTTP header.: Attacker can prevent
– Short-lived certificates: Doesn’t scale, interferes with pinning
– X.509 OCSP must-staple: No spec, not widely implemented
47
Public Key Infrastructure (PKI) /
Certificate Authority (CA) Issues (3)
• Interview with Kipp Hickman, designer of original SSL protocol:
– “So, certificate authorities was the deal… Oh, that whole authenticity
thing…”
– “We were designing SSL to prevent passive attacks for the most part,
you know.”
– “We heard about this thing – the man-in-the-middle attack – and so
we just threw that in at the end”
– “Really, that whole thing with certificates, it was a bit of a hand wave.
We didn’t think it was gonna work, we didn’t know”.
Source: http://privacy-pc.com/articles/ssl-and-the-future-of-authenticity2-certificate-authorities.html
• Rather disturbing comments for such a key protocol!
• Later versions improved, but CAs & revocation still a big problem
• Be prepared to change if solutions become available
48
Timing attacks: The problem
• Many algorithms take a variable amount of time
– E.G., array “is equal to?” usually stops on first unequal value
• Attackers can get confidential info (like private keys) through this
– Attackers perform act multiple times…
– Use statistics to eliminate jitter; a shocking amount is removable!
– E.G., for “is equal to” attacker can determine if he guessed first one
correctly, then second one, then third one, …
• Yes, it really works
– 15-100μs accuracy across the Internet and 100ns over a local network
[Crosby2009]
– One example (finding 20 byte HMAC result): Keyczar used standard
equality test, allowing attacker to find session value in < week with 10
req/s… “and all of a sudden I’m logged in as you” [Hale2009]
– If attacker on same system or has shared resources (such as mobile
apps or virtualized cloud), timing attack problems are even worse
49
Timing attacks: Solutions
• Use timing-independent (sometimes called “constant-time”) algorithms
– Not the same as O(1) algorithms!!
• E.G., “is equal to” in Java [Lawson2010] [Hale2009]:
public static boolean isEqual(byte[] a, byte[] b) {
if (a.length != b.length) { return false; } // Omitting this is a bad bug
int result = 0;
for (int i = 0; i < a.length; i++) { // Note that we always examine everything
result |= a[i] ^ b[i];
}
return result == 0;
}
• Crypto library implementations have to worry about this broadly
• Consider if you need timing-independent, especially when using crypto
– In particular, use them when comparing hashed or encrypted values, or when
doing anything with private keys
– Timing attacks apply broadly, but “is equal to” is especially common issue
– MessageDigest.equal() was fixed in Java SE 6 Update 17
50
Some introductory books on
cryptography
• Applied Cryptography by Bruce Schneier (1994
& 1996) – highly influential, incredibly
researched, somewhat dated
• Handbook of Applied Cryptography by Alfred J.
Menezes, Paul C. van Oorschot and Scott A.
Vanstone (2001) - newer, contents freely
available at http://cacr.uwaterloo.ca/hac/
• Practical Cryptography by Niels Ferguson and
Bruce Schneier (2003) – updated, shorter
51
Conclusions
• Do not create your own crypto
algorithm/protocol
• Where possible, reuse existing implementations
– At least reuse existing algorithms (after you make sure
they’re okay via public sources!)
• Support multiple algorithms, allow switch via
configuration
– Crypto algorithms are often broken
– Making them configurable makes switch easy
52
Released under CC BY-SA 3.0
• This presentation is released under the Creative Commons AttributionShareAlike 3.0 Unported (CC BY-SA 3.0) license
• You are free:
– to Share — to copy, distribute and transmit the work
– to Remix — to adapt the work
– to make commercial use of the work
• Under the following conditions:
– Attribution — You must attribute the work in the manner specified by the
author or licensor (but not in any way that suggests that they endorse you or
your use of the work)
– Share Alike — If you alter, transform, or build upon this work, you may
distribute the resulting work only under the same or similar license to this one
• These conditions can be waived by permission from the copyright holder
– dwheeler at dwheeler dot com
• Details at: http://creativecommons.org/licenses/by-sa/3.0/
• Attribute me as “David A. Wheeler”
53