Most Common Cryptography Mistakes 3/8/2016 You fell vic+m to one - PowerPoint PPT Presentation

Most Common Cryptography Mistakes 3/8/2016

You fell vic+m to one of the classic blunders!

#8: Key Re-use • Don’t use same key for both direcEons. – Risk: replay aHacks • Don’t re-use same key for both encrypEon and authenEcaEon.

#7: Careful with ConcatenaEon • Common mistake: Hash(S||T) – “builEn” || “securely” = “built” || “insecurely”

Amazon Web Services hHp://amazon.com/set?u=daw&n=David&t=U&m=… MAC(K,”udawnDavidtU”)

Amazon Web Services hHp://amazon.com/set?u=daw&n=DavidtAq&t=U&m=… MAC(K,”udawnDavidtAqtU”) hHp://amazon.com/set?u=daw&n=David&t=A&qt=U&m=…

#7: Careful with ConcatenaEon • Common mistake: Hash(S||T) – “builEn” || “securely” = “built” || “insecurely” • Fix: Hash(len(S) || S || T) • Make sure inputs to hash/MAC are uniquely decodable

#5: Don’t Encrypt without Auth • Common mistake: encrypt, but no authenEcaEon – A checksum does not provide authenEcaEon • If you’re encrypEng, you probably want authenEcated encrypEon – Encrypt-then-authenEcate: E k1 ( M ), F k2 ( E k1 ( M )) – Or, use a dedicated AE mode: GCM, EAX, …

Encrypt without Auth Hall of Shame • ASP.NET (x2) • XML encrypEon • Amazon EC2 • JavaServer Faces • Ruby on Rails • OWASP ESAPI • IPSEC • WEP • SSH2

#4: Be Careful with Randomness • Common mistake: use predictable random number generator (e.g., to generate keys) • SoluEon: Use a crypto-quality PRNG. – /dev/urandom, CryptGenRandom, …

Netscape Navigator char chall[16], k[16]; srand(getpid() + time(NULL) + getppid()); for (int i=0; i<16; i++) chal[i] = rand(); for (int i=0; i<16; i++) chal[i] = rand();

Netscape Navigator 1.1 cert S Client Server R, {K} K S , {M} K , … where (R, K) = hash(microseconds, x) x = seconds + pid + (ppid << 12)

Netscape Navigator 1.1 cert S Client Server R, {K} K S , {M} K , … where (R, K) = hash(microseconds, x) x = seconds + pid + (ppid << 12) A7ack: Eavesdropper can guess x ( ≈ 10 bits) and microseconds (20 bits), and use R to check guess.

Bad PRNGs = broken crypto • Netscape server’s private keys ( ≈ 32 bits) • Kerberos v4’s session keys ( ≈ 20 bits) • X11 MIT-MAGIC-COOKIE1 (8 bits) • Linux vtun ( ≈ 1 bit) • PlanetPoker site ( ≈ 18 bits) • Debian OpenSSL (15 bits) • CryptoAG – NSA spiked their PRNG • Dual_EC_DRBG – backdoor that only NSA can use

#3: Passphrases Make Poor Keys • Common mistake: Generate crypto key as Hash(passphrase) • Problem: ≈ 20 bits of entropy; even with a slow hash, this is not nearly enough. Human- generated secrets just don’t have enough entropy. • Example: Bitcoin brainwallets • SoluEon: Crypto keys should be random.

#2: Be Secure By Default • Common mistake: Security is opEonal, or configurable, or negoEable • Fix: There is one mode of operaEon, and it is secure. No human configuraEon needed. – e.g., Skype

#2: Beware Rollback AHacks • Common mistake: Security is negoEable, and aHacker can persuade you to fall back to insecure crypto

A CASE STUDY

MS Point-to-Point EncrypEon (MPPE) If both endpoints support 128-bit crypto: I support 128-bit crypto So do I. Here’s a nonce: R Client Server M ⊕ RC4(K) where K = hash(password || R)

MS Point-to-Point EncrypEon (MPPE) If both endpoints support 128-bit crypto: I support 128-bit crypto So do I. Here’s a nonce: R Client Server M ⊕ RC4(K) where K = hash(password || R) A7ack 1: Eavesdropper can try dic+onary search on password, given some known plaintext.

MS Point-to-Point EncrypEon (MPPE) If both endpoints support 128-bit crypto: I support 128-bit crypto So do I. Here’s a nonce: R Client Server M ⊕ RC4(K) where K = hash(password || R) A7ack 2: Ac+ve a7acker can tamper with packets by flipping bits, since there is no MAC.

I support 128-bit crypto So do I. Here’s a nonce: R Client Server M ⊕ RC4(K) where K = hash(password || R) I support 128-bit crypto So do I. Here’s a nonce: R Bad Guy Client M ⊕ RC4(K) A7ack 3: Bad guy can replay a prior session, since client doesn’t contribute a nonce.

I support 128-bit crypto So do I. Here’s a nonce: R Client Server M ⊕ RC4(K) where K = hash(password || R) I support 128-bit crypto So do I. Here’s a nonce: R Bad Guy Client M ⊕ RC4(K) A7ack 4: Bad guy can replay and reverse message direc+on, since same key used in both direc+ons.

MS Point-to-Point EncrypEon (MPPE) If one endpoint doesn’t support 128-bit crypto: I support 128-bit crypto I don’t. Use 40-bit crypto Client Server M ⊕ RC4(K) where K = hash(uppercase(password))

MS Point-to-Point EncrypEon (MPPE) If one endpoint doesn’t support 128-bit crypto: I support 128-bit crypto I don’t. Use 40-bit crypto Client Server M ⊕ RC4(K) where K = hash(uppercase(password)) A7ack 1: Eavesdropper can try dic+onary search on password, given some known plaintext.

MS Point-to-Point EncrypEon (MPPE) If one endpoint doesn’t support 128-bit crypto: I support 128-bit crypto I don’t. Use 40-bit crypto Client Server M ⊕ RC4(K) where K = hash(uppercase(password)) A7ack 2: Dic+onary search can be sped up with precomputed table (given known plaintext).

MS Point-to-Point EncrypEon (MPPE) I support 128-bit crypto I don’t. Use 40-bit crypto Client Bad Guy M ⊕ RC4(K) where K = hash(uppercase(password)) A7ack 3: Imposter server can downgrade client to 40-bit crypto, then crack password.

MS Point-to-Point EncrypEon (MPPE) I support 128-bit I support 128-bit So do I. Nonce: R Bad Client Server I don’t. Use 40-bit Guy M ⊕ RC4(K) M’ ⊕ RC4(K’) where K = hash(uppercase(password)), K’ = hash(password || R) A7ack 4: Man-in-the-middle can downgrade crypto strength even if both client + server support 128-bit crypto, then crack password.

#1: Don’t Roll Your Own • Don’t design your own crypto algorithm • Use a Eme-honored, well-tested system – For data in transit: TLS, SSH, IPSEC – For data at rest: GnuPG

#0: Crypto Ain’t Magic “If you think cryptography is the soluEon to your problem, then you don’t understand cryptography and you don’t understand your problem.” – Roger Needham

Meta-Lessons • Cryptography is hard. • Hire an expert, or use an exisEng system (e.g., SSL, SSH, GnuPG). • But: Most vulnerabiliEes are in applicaEons and sovware, not in crypto algorithms.

BONUS MATERIAL

#8: Traffic Analysis is SEll Possible • EncrypEon doesn’t hide sender, recipient, length, or Eme of message. (“meta-data”)

SSH (handshake; key exchange) Client Server {l} K {l} K’ {s} K {s} K’ {\n} K {\nfoo bar \n$} K’

SSH {\n} K {\nPassword: } K’ {q} K Client Server {p} K {l} K {e} K {4} K {\n} K {\nLast login: …\n $\n} K’

SSH {\n} K {\nPassword: } K’ {q} K Client Server {p} K Reveals Reveals +me length of between password. {l} K keystrokes. This leaks {e} K par+al informa+on about the {4} K password! {\n} K {\nLast login: …\n $\n} K’

Lessons Summarized • Don’t design your own crypto algorithm. • Use authenEcated encrypEon (don’t encrypt without authenEcaEng). • Use crypto-quality random numbers. • Don’t derive crypto keys from passphrases. • Be secure by default. • Be careful with concatenaEon. • Don’t re-use nonces/IVs. Don’t re-use keys for mulEple purposes. • EncrypEon doesn’t prevent traffic analysis (“metadata”).

#7: Don’t re-use nonces/IVs • Re-using a nonce or IV leads to catastrophic security failure.

Credit card numbers in a database

Aver Base64 decoding

Encrypted credit card numbers

Encrypted credit card numbers ASCII: …, ‘3’ = 0x 33 , ‘4’ = 0x34 , ‘5’ = 0x 35 , …

Encrypted credit card numbers ASCII: ‘0’ = 0x 30 , …, ‘7’ = 0x37 , ‘8’ = 0x 38 , ‘9’ = 0x39

#7: Don’t re-use nonces/IVs • Re-using a nonce or IV leads to catastrophic security failure.

WEP (encrypted traffic) • Early method for encrypEng Wifi: WEP (Wired Equivalent Privacy) – Share a single cryptographic key among all devices – Encrypt all packets sent over the air, using the shared key – Use a checksum to prevent injecEon of spoofed packets

WEP - A LiHle More Detail IV, P ⊕ RC4(K, IV) • WEP uses the RC4 stream cipher to encrypt a TCP/IP packet (P) by xor-ing it with keystream (RC4(K, IV))

A Risk of Keystream Reuse IV, P ⊕ RC4(K, IV) IV, P’ ⊕ RC4(K, IV) • In some implementaEons, IVs repeat. – If we send two ciphertexts (C, C’) using the same IV, then the xor of plaintexts leaks (P ⊕ P’ = C ⊕ C’), which might reveal both plaintexts † Lesson: Don’t re-use nonces/IVs

WEP -- Even More Detail IV original unencrypted packet checksum RC4 key IV encrypted packet

AHack #2: Spoofed Packets IV, (P, CRC(P)) ⊕ Z • AHackers can inject forged 802.11 traffic – Learn Z = RC4(K, IV) using previous aHack – Since the CRC checksum is unkeyed, you can then create valid ciphertexts that will be accepted by the receiver