Cryptography Fundamentals James Walden Northern Kentucky University Topics

Cryptography Fundamentals James Walden Northern Kentucky University

Topics 1. 2. 3. 4. 5. Cryptography Concepts Public Key Cryptography Man-in-the-Middle Attacks Hash Functions Random Number Generation CSC 666: Secure Software Engineering

Cryptography Concepts Communication channel Sender encrypt Recipient decrypt ciphertext plaintext shared secret key Alice shared secret key Eve (eavesdropper) CSC 666: Secure Software Engineering Bob

Cryptanalysis Threat Models Ciphertext only: adversary has only ciphertext; goal is to find plaintext, possibly key. Known plaintext: adversary has ciphertext, corresponding plaintext; goal is to find key. Chosen plaintext: adversary may supply plaintexts and obtain corresponding ciphertext; goal is to find key.

Kerckhoff’s Principle Cryptosystem security should only depend on 1. Quality of shared encryption algorithm E 2. Secrecy of key K The best attack against such a system is Exhaustive key search (a/k/a Brute Force) Note that this assumes that all keys are equally likely to be chosen, i. e. are randomly generated.

Brute Force Attack Exhaustive search of keyspace by decrypting ciphertext C with all possible keys K. Must determine if DK(C) is a likely plaintext Requires some knowledge of format (language, doc type) For N possible keys, Worst case is N decryptions. Mean case is N/2 decryptions. Example: DES has 56 -bit keys Average time to find key is 255 decryptions.

Is 128 bits enough? 128 -bit keyspace permits 2128 keys 340, 282, 366, 920, 938, 463, 374, 607, 431, 768, 211, 456 or 3. 4 x 1038 keys Cracking 1 trillion (1012) keys per second requires 3. 4 x 1026 seconds or 1. 08 x 1019 years Cracking 1 trillion keys per second on 1 billion CPUs requires 1. 08 x 1010 years = 10. 8 billion years

Stream Ciphers Features Use encryption algorithm to generate a pseudorandom stream of bits called keystream. XOR keystream with plaintext bit stream to generate ciphertext bit stream. Stream Cipher 1 1 0 0 1 0 Plaintext stream 1 0 Ciphertext stream = 0 1 CSC 666: Secure Software Engineering

Block Ciphers Features Divide message into fixed size blocks. Pad plaintext if it doesn’t fit into blocks. Encrypt each plaintext block with algorithm. PKCS#7 Padding value = number of bytes appended. Padding verified and removed after decryption. 7 7 7 7 4 4 CSC 666: Secure Software Engineering

Electronic Code Book Mode Encrypt each block independently. E(block) = Cblock each time block appears Therefore attacker can build dictionary of blocks. ECB encryption of bitmap hides colors but image is still discernible.

Cipher Block Chaining Mode XOR each block with previous ciphertext block. Random initialization vector (IV) used for 1 st block. CBC encryption of bitmap looks random.

Advanced Encryption Standard AES was winner of open NIST competition (1997 -2000) Rijndael, designed by Joan Daemen and Vincent Rijmen. Published as FIPS 197 in November 2001. 128 -bit block cipher Variable key length: 128 -, 192 -, or 256 -bit keys. Replacement for DES vulnerable to brute force attacks due to 56 -bit keys. Triple DES is very slow.

Symmetric Key Distribution Requires each pair of communicating parties to share a (separate) secret key. shared secret shared secret n (n-1)/2 keys

Public-Key Cryptography Separate keys for encryption and decryption. Communication channel Sender encrypt plaintext Recipient decrypt plaintext ciphertext plaintext Bob’s public key Alice Bob’s private key Eve (eavesdropper) Bob

Public Key Distribution Only one key is needed for each recipient private public n key pairs private

Requirements 1. It must be computationally easy to encipher or decipher a message given the appropriate key. 2. It must be computationally infeasible to derive the private key from the public key. 3. It must be computationally infeasible to determine the private key from a chosen plaintext attack.

One-Way Trapdoor Functions Trapdoor one-way Function: One-way function whose inverse is easy to calculate only if given a special piece of information. Example: Prime factoring Easy to calculate product. Difficult to calculate prime factors from product. Easy to calculate one prime factor, given others. Note: Better attacks than brute force exist. While prime factoring is hard, it’s not as hard as a brute force search of all keys. 128 -bit keys are not sufficient for public keys! Key size required depends on which trapdoor fn used.

Diffie-Hellman Key Exchange Compute shared key w/o trusted 3 rd party. Based on discrete logarithm problem Given integers n and g and prime number p, compute k such that n = gk mod p. Solutions known for small p. Computationally infeasible for large p. Shared Constants prime modulus p, integer base g ≠ {0, 1, p– 1}

Diffie-Hellman Algorithm 1. 2. 3. 4. 5. Alice chooses a random private key k Computes public key A = gk mod p and sends to Bob chooses a random private key k’ Computes public key B = gk’ mod p and sends to Alice computes secret key 1. K 1 = Bk mod p 6. Bob computes secret key 1. K 2 = Ak’ mod p 7. Encrypt messages w/ symmetric cipher using K 1=K 2 as the shared secret key.

Diffie-Hellman Example Assume p = 53 and g = 17 Alice chooses k. Alice = 5 Then KAlice = 175 mod 53 = 40 Bob chooses k. Bob = 7 Then KBob = 177 mod 53 = 6 Shared key: Alice computation: KBobk. Alice mod p = 65 mod 53 = 38 Bob computation: KAlicek. Bob mod p = 407 mod 53 = 38

Diffie-Hellman Activity Assume p = 51 and g = 19. Find a student to pair with. Each student picks a random private key. Compute public key with irb(main): 001: 0> (19**7). modulo(51) => 43 Share your public key with your partner. Compute shared, secret key using irb. Compare shared key with partner. If they match, congratulations! If they don’t, find out what went wrong.

RSA Algorithm Choose two large prime numbers p, q Let the modular base n = pq. Choose e < n so e is relatively prime to (n). Compute inverse of e, d, as private key. Public key: (e, n) Private key: d Encipher: c = me mod n Decipher: m = cd mod n

Man-in-the-Middle Attacks MITM is an active network attack in which attacker routes packets through his machine, modifying them in the process. Attacker needs to start with one of these attacks: ARP spoofing DHCP spoofing DNS hijacking or cache poisoning Route hijacking DNS cache poisoning Then he can modify packets as desired. CSC 666: Secure Software Engineering

ARP Spoofing LAN: 192. 168. 1. x CLIENT Regular traffic SERVER switch Alice. 10 Bob. 100 Using arp poisoning MAC: 00: 0 A: E 4: 3 B: 47: 7 E MAC: 00: 0 A: E 4: 2 E: 9 B: 11 gratuitous arp reply Bob’s IP→ Cracker’s MAC arpspoof 192. 168. 1. 100 victim ip gateway ip MAC: 00: 22: 64: 34: 60: 88 gratuitous arp reply Alice’s IP→ Cracker’s MAC arpspoof 192. 168. 1. 100 192. 168. 1. 10 victim ip gateway ip Cracker. 1

Hash Functions Hash Function h: M MD Input M: variable length message M Output MD: fixed length “Message Digest” of input Many inputs produce same output (called a collision) Limited number of outputs; infinite number of inputs Avalanche effect: small input change -> big output change Example (insecure) hash function Sum 32 -bit words of message mod 232 M h MD=h(M)

MACs for Data Integrity Given a message M and shared secret key K, Alice computes H(K||M) and sends M and this hash to Bob. Communication channel h MAC message M Alice 6 B 34339 shared secret key (attack detected) 87 F 9024 =? 4 C 66809 MAC received MAC Mallory (modifying) h computed MAC message M’ shared secret key Bob

Secure Hash Function A function h = hash(m) must have 3 properties to be secure: 1. Pre-image resistance: Given a hash h it should be difficult to find any message m such that h = hash(m). Functions that lack this property are vulnerable to preimage attacks. 2. Second pre-image resistance: Given an input m 1 it should be difficult to find another input m 2 such that m 1 ≠ m 2 and hash(m 1) = hash(m 2). Functions that lack this property are vulnerable to second-preimage attacks. 3. Collision resistance: It should be difficult to find two different messages m 1 and m 2 such that hash(m 1) = hash(m 2). Such a pair is called a cryptographic hash collision. This property is sometimes referred to as strong collision resistance. It requires a hash value at least twice as long as that required for preimage -resistance; otherwise collisions may be found by a birthday attack.

Digital Signatures

Message-Digest Algorithm 5 (MD 5) Developed by Ron Rivest in 1991 Uses 128 -bit hash values Merkle–Damgård construction Still widely used in legacy applications even though collision vulnerabilities allow forgery of digital signatures and SSL certificates.

MD 5 Collision Attack History 1. Initial attacks (2004) could only find collisions in files that differed only in last few bytes. 2. Early attacks (2008) used cluster of 200 PS 3 s for a couple of days. 3. Current attacks can find a collision in seconds on single PC. Lesson: Cryptanalytic attacks always improve. Change algorithms before they do.

Secure Hash Algorithm (SHA-1) Developed by NSA; approved federal std by NIST SHA-0 (1993) and SHA-1 (1995) 160 -bit hash values Merkle–Damgård construction SHA-1 developed to correct insecurity of SHA-0 SHA-1 still found in legacy applications Vulnerabilities less severe than those of MD 5 Can find SHA-1 collision in 269 operations. Can find SHA-0 collision in 239 operations.

SHA-2 Developed by NSA; approved federal std by NIST SHA-2 (2001) 224, 256, 384, or 512 -bit hash values Merkle–Damgård construction Current recommended hash function for security applications like digital signatures or SSL certificates. Cryptanalysts making progress but no breaks Can only find collisions if modify hash algorithm by reducing number of rounds from 80 (SHA-512) to 46 or 64 (SHA-256) to 41.

SHA-3 Winner of open NIST competition (2007 -2012) Draft standard published in 2014. Keccak (2012) 224, 256, 384, or 512 -bit hash values. Concerns about NIST changes to 128 - and 256 -bit values only. An alternative to SHA-2 Not a replacement as SHA-2 is not broken. Built on sponge-function instead of Merkle–Damgård construction like MD 5, SHA-1, SHA-2 so that the same cryptanalytic techniques will not work against SHA-3.

Random Number Generation PRNGs are Statistically random, but Predictable. Given same seed, generate same sequence. CSPRNGs are Statistically random and not predictable. Seed themselves at times with random bits from hardware (time between keystrokes, hard drive movements, etc. ) CSC 666: Secure Software Engineering

Ivy Bridge RNG Added with Ivy Bridge Core i. N CPUs in 2012. One RNG per die, not per core. Entropy source is thermal noise.

Random Number APIs Windows rand() – insecure PRNG, uses LCG Crypt. Gen. Random() – CSRNG Crypt. Gen. Key() – to securely generate keys Java java. util. Random – insecure PRNG java. security. Secure. Random – CSRNG Relies on OS, so Secure. Random can fall back to insecure Random if OS does not provide /dev/random or similar CSC

Key Size and Security Protection Symmetric Public Diffie. Key Hellman Elliptic Curve Hash Short term against small organizations 64 816 128 Very short term against agencies 80 1248 160 Short term against agencies (10 years) 96 1776 192 Medium term against agencies (20 years) 112 2432 224 Long term protection (30 years) 128 3248 256 Long term protection with increased defense against quantum computers. 256 15424 512 ECRYPT 2 recommendations from www. keylength. com

Key Points Symmetric cryptography Alice/Bob send confidential data with shared key. 128 -bit keys long enough for brute force attacks. Stream (RC 4) vs. Block (AES) ciphers. Public key (asymmetric) cryptography Alice encrypts with Bob’s public key Bob decrypts with Bob’s private key Secure hash functions Resistance to pre-image, 2 nd pre-image, collision Digital signature = Hash + Encrypt w/ Private Keys must be generated with CSPRNGs

References 1. 2. 3. 4. 5. 6. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. David Gourley et. Al. , HTTP: The Definitive Guide, O’Reilly, 2002. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, 2 nd Edition, Wiley, 2011. Ivan Ristic, Bulletproof SSL and TLS, Feisty Duck, 2014. Sanctum, “HTTP Response Splitting Whitepaper, ” http: //www. packetstormsecurity. org/papers/general/whi tepaper_httpresponse. pdf, 2004. Michael Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2011. CSC 666: Secure Software Engineering