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
endwhile

Asymmetric 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

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 buffer

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

Why 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 == 0

Leaky

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