Cryptography
for
Cybersecurity Professionals
April, 2019
Motivation
"cryptography is a solved problem ... the remaining problems ... are primarily political"
- Cryptography textbooks
" cryptography is in fact the strongest link in the chain"
- Security researchers
"Secure your router in two easy steps: enable secret and service password-encryption"
- Every CCNA curriculum ever
Motivation Cont.
Cryptographic Systems
A security system that utilizes cryptography to enable or augment functionality
Cross-disciplinary
- Cryptography
- Mathematics
- Hardware / Software Engineering
- User Interfaces / APIs
- etc.
Many distinct ways to get cryptographic systems wrong
Where Cryptographic Systems Break
1. Theory
2. Primitives
3. Protocols
4. Implementation
5. Usage
Theory
Are our cryptographic systems constructed on the basis of valid assumptions?
- Open question...
Compromise assumed as hard as underlying problem
- RSA and integer factorization
- Diffie-Hellman and discrete logarithm
Hard problems assumed to be hard
One-way functions assumed to be feasible
- P != NP ?
Primitives
The building blocks of cryptographic systems
In general, a primitive is an algorithm
- Ciphers, MACs, Signatures, Hash Functions, etc.
How do primitives break?
- The primitive itself is flawed
- The right primitive becomes the wrong primitive
History is littered with broken primitives...
Data Encryption Standard (DES) - 1975
Symmetric block cipher
- Block size: 64 bits
- Key size: 64 bits*
What's the issue?
- Key size is too small
Chronology
- 1998 EFF's Deep Crack breaks in 56 hours
- 1999 EFF's Deep Crack breaks in 22 hours
- 2006 COPACOBANA cracks in 9 days, for $10,000
- 2016 hashcat + GPU cracks in 15 days
GSM Encryption (1987)
Added to GSM standard to encrypt mobile traffic between device and cell tower
Stream cipher, comes in multiple flavors
- A5/0: no encryption
- A5/1: based on LFSRs
- A5/2: weaker version of A5/1
- A5/3 (KASUMI)
What's the issue?
- Deliberately weak algorithms (laptop-crackable)
- Vulnerable to downgrade attacks
MD5 (1992) & SHA-1 (1995)
Cryptographic hash functions
- MD5 digest width = 128 bits
- SHA-1 digest width = 160 bits
What's the problem?
- Digest width is too small
Chronology
- 2005 first full MD5 collision
- 2017 CWI Amsterdam and Google SHA-1 collision
RC4 (1994*)
History's most (in)famous stream cipher
What's the issue?
- Keystream bias(es)
Practical applications
- Cracking WEP communications
- Cracking SSL/TLS sessions (RFC 7465, 2015)
i := 0
j := 0
while GeneratingOutput:
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap values of S[i] and S[j]
K := S[(S[i] + S[j]) mod 256]
output K
endwhileAsymmetric Algorithms (now)
Primitives with security guarantees based on the computational difficulty of hard problems
A few problems we are entirely reliant upon
- Integer factorization (RSA)
- Discrete logarithm in finite fields (DSA)
- Discrete logarithm on elliptic curves (ECDSA)
Quantum computation may change the game...
Open question: will this be another case where the right primitives become the wrong primitives?
Post-Quantum Cryptography
Cryptographic schemes for which quantum computation does not provide an exponential speedup
The search for post-quantum algorithms: NIST
- February 2016: Initial call for submissions
- December 2017: Round 1 candidates announced (69)
- January 2019: Round 2 candidates announced (17)
A note on practicality
- Key size (MBs, GBs??)
- Bandwidth (DoS made easy)
- Encrypt / decrypt / sign / validate times
Protocols
A set of rules and conventions by which we perform cryptographic operations
Cryptographic protocols are everywhere
- Mobile phones
- Wireless access points (WEP, WPA*)
- Automobiles (vehicle immobilizers)
- Internet traffic (SSL/TLS)
When we design cryptographic protocols, we introduce complexity and thereby enlarge our attack surface
Diffie-Hellman Key Agreement
Introduced* the idea of asymmetric cryptography - New Directions in Cryptography (1976)
Establishment of shared secret between two parties over an insecure channel
"Textbook" (or "anonymous") DH protocol insecure against active adversary: man in the middle attacks
Diffie-Hellman Key Agreement
The protocol
Alice
Bob
Public
g, p
Choose a in {1,...,p-1}
Compute A = g^a mod p
Choose b in {1,...,p-1}
Compute B = g^b mod p
Compute S = B^a
= (g^b)^a
= g^ab
Compute S = A^b
= (g^a)^b
= g^ab
Send A
Send B
Diffie-Hellman Key Agreement
Fixing the protocol: DH-MQV
Alice
Bob
Public
g, p
Send A
Send B
(x, Y = g^y)
(y, X = g^x)
Pick random a
Compute A = g^a
Pick random b
Compute B = g^b
Compute (B x Y^B)^(a+xA)
Compute (A x X^A)^(b+yB)
(B * Y^B)^{a + xA} = (g^b * (g^y)^B)^{a + xA} = (g^{b+yB})^{a+xA} = g^{(b+yB)(a+xA)}
(A * X^A)^{b+yB} = (g^a * (g^x)^A)^{b+yB} = (g^{a+xA})^{b+yB} = g^{(b+yB)(a+xA)}
Alice computes
Bob computes
SSL/TLS and Ciphersuite Negotiation
The single most important cryptographic protocol in use today
Long history of attacks on SSL/TLS
- BEAST, CRIME, DROWN, TERROR, etc...
Vulnerable to ciphersuite downgrade attacks
Client
Server
Client Hello
Server Hello
I support algorithms X, Y, and Z
Let's use algorithm Y
SSL/TLS and RSA PKCS #1 v1.5
RSA PKCS #1 v1.5 - a padding scheme for messages encrypted with RSA
When PKCS #1 v1.5 used within the SSL/TLS protocol, it is vulnerable to padding oracle attacks
SSL/TLS and RSA PKCS #1 v1.5
RSA PKCS #1 v1.5 Padding scheme
0x00
0x02
0x00
Random, Nonzero Bytes
Original Message
SSL/TLS Protocol
Client
Server
Client Hello
Server Hello
Client Key Exchange
...
Stuff
Stuff
PMS
Bleichenbacher's Attack (1998)
Active attack on the SSL/TLS (<1.3) protocol, using SSL/TLS server as a padding oracle
Relies on homomorphism of RSA encryption
Fixing the protocol
- Do not inform client of bad padding
Fixing the padding scheme
- Weakness of PKCS #1 v1.5 = low redundancy
- More advanced padding schemes e.g. OAEP
Implementation
How do we actually realize cryptographic systems in the real world?
- Hardware
- Software
Why does this matter?
- Cryptographic systems vulnerable to the same flaws as all hardware / software systems
Cryptography Implementations
When we perform some cryptographic operation, we are faced with two choices
1. Roll it ourselves
2. Use a library
Many arguments against "rolling your own crypto"
Vast majority of people / organizations meet cryptography needs via software libraries
- Many exist
- But OpenSSL dominates
Cryptographic Supply Chain
Academic Cryptographers,
Mathematicians,
Complexity Theorists
Crypto Implementors
Application Software Developers
End Users (e.g. you, me)
Coding to Standard
RSA-Encrypted Premaster Secret Message
...
1. Generate a string R of 46 random bytes
2. Decrypt the message to recover the plaintext M
3. If the PKCS#1 padding is not correct,
or the length of message M is not exactly 48 bytes:
pre_master_secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0,
and version number check is explicitly disabled:
pre_master_secret = M
else:
pre_master_secret = ClientHello.client_version || M[2..47]
RFC 5246: TLS version 1.2
(3)
(2)
(1)
Coding to Standard
i=RSA_private_decrypt((int)n,p,p,rsa,RSA_PKCS1_PADDING);
al = -1;
...
if (al != -1)
{
/* Some decryption failure -- use random value instead as countermeasure
* against Bleichenbacher's attack on PKCS1 v1.5 RSA padding
* (see RFC 2246, section 7.4.7.1). */
ERR_clear_error();
i = SSL_MAX_MASTER_KEY_LENGTH;
p[0] = s->client_version >> 8;
p[1] = s->client_version & 0xff;
if (RAND_pseudo_bytes(p+2, i-2) <= 0)
goto err;
}
s->session->master_key_length=
s->method->ssl3_enc->generate_master_secret(s,
s->session->master_key,
p,i);OpenSSL 1.0.1c
(3)
(2)
(1)
Space Shuttles & Elevators
// set up the context
EVP_CIPHER_CTX *ctx;
if (!(ctx = EVP_CIPHER_CTX_new()))
handle_errors();
// openssl wants unsigned character buffers
unsigned char *key_buf = ...
unsigned char *ct_buf = ...
unsigned char *pt_buf = ...
// initialize the encryption operation
if (EVP_EncryptInit_ex(ctx, EVP_aes_128_ecb(), NULL, key_buf, NULL) != 1)
handle_errors();
// provide plaintext bytes to be encrypted
int len;
if (EVP_EncryptUpdate(ctx, ct_buf, &len, pt_buf, pt_len) != 1)
handle_errors();
ct_len += len;
// finalize encryption operation
if (EVP_EncryptFinal_ex(ctx, ct_buf+len, &len) != 1)
handle_errors();
ct_len += len;
// cleanup
EVP_CIPHER_CTX_free(ctx);AES encryption: OpenSSL
Space Shuttles & Elevators
// initialize some buffers
unsigned char *key = ...
unsigned char *pt = ...
unsigned char *ct = ...
// aes encryption: so easy a caveman could do it
aes_128_encrypt(ct, pt, key);
// do stuff with your encrypted bufferWhy is this better?
- Simpler, more intuitive API
- Fewer opportunities to make mistakes
Why is it dangerous?
- Gives user too much latitude to do something bad
AES encryption: proprietary*
Space Shuttles & Elevators
#include "crypto_secretbox.h"
unsigned char key = ...
unsigned char nonce = ...
unsigned long long plen;
unsigned char pt = ...
unsigned long long clen;
unsigned char ct = ...
// do everything
crypto_secretbox(ct, pt, plen, nonce, key);
// do stuff with your encrypted buffer
// AND rest assured that message is authenticatedWhy is this better?
- Equally simple / intuitive API
- Hides lower level details from users
AES encryption: NaCL
Do APIs Really Matter?
Survey of security-critical applications and libraries (2012)
Broken certificate verification in
- Amazon's EC2 library and cloud clients
- Paypal merchant SDKs
- Mobile banking applications
- Web server middlewares e.g. Apache Axis, Pusher
"The root causes of these vulnerabilities are badly designed APIs of SSL implementations ..."
Side Channel Attacks
During operation, cryptographic system leaks information regarding some secret value
Many attack vectors
- Timing
- Audio
- Power Usage (SPA, DPA)
- Electromagnetic Radiation
Timing Attacks
The time taken to perform some cryptographic operation leaks information about internal, secret value
// typical comparison operation
for (int i = 0; i < len; i++)
if (x[i] != y[i]) return false;
return true;
// constant time comparison
int diff = 0
for (int i = 0; i < len; i++)
diff |= x[i] ^ y[i];
return diff == 0Leaky
Less so
Usage
Can cryptographic systems break despite careful design and correct implementation?
- Yes. Catastrophically.
Where do users screw up?
- Poor key management
- Misapplication of cryptographic tools
- Misuse of cryptographic tools
Key Management
/*
* super_important_program.c
*
* A program that performs SUPER IMPORTANT computations,
* with the help of some crypto.
*/
static const char *SECRET_KEY = "YELLOWSUBMARINE";
// encrypt and decrypt all the things!How do users / organizations store, distribute, update, and revoke encryption keys?
Hardcoded values
Sharing of asymmetric key parameters
- Common RSA modulus N
Misapplication of Cryptographic Tools
Most users don't know better; leads to using the wrong tool for the job
Non-cryptographic PRNGs in "secure" applications
- rand() in C, random in Python
Non-authenticated encryption where we should require authentication
- "Vanilla" AES
Mistaking algorithms for encryption schemes
- "Textbook" RSA
Misuse of Cryptographic Tools
Despite choosing the correct tool, many users still neglect to read the manual
Common example: nonce reuse
- The name is literally the manual here
Use of a unique nonce is fundamental to the security guarantees of many symmetric algorithms
- Block ciphers in CTR mode
Exploiting nonce reuse
- KRACK attack on WPA2
Misuse Resistance
How can we design cryptographic systems that remain secure despite misuse?
Active area of research e.g. RFC 8452
Takeaways
Cryptography is hard; designing and implementing secure cryptographic systems is really hard
Many distinct ways in which cryptographic systems break
- Theory, Primitives, Protocols, Implementation, Usage
What can we do?
- Panic
- Recognize limitations
- ???
References
- Practical Cryptographic Systems by Matthew Green
- Should We Deploy TLS? by Matthew Green
- Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS#1 by Daniel Bleichenbacher
- 20 Years of Attacks on the RSA Cryptosystem by Dan Boneh
- The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by Georgiev et al.
- Post-Quantum Cryptography by Daniel J. Bernstein
- Serious Cryptography by Jean-Philipoe Aumasson
- Cryptography Engineering by Ferguson, Schneier, Kohno
References Cont.
- RFC 2313 PKCS #1: RSA Encyption, Version 1.5
- RFC 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
- RFC 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
- RFC 5246 The Transport Layer Security (TLS) Protocol, Version 1.2
Crypto for Cyber Pros
By turingcompl33t
Crypto for Cyber Pros
What Diffie and Hellman never told you.