CIS 4615 meeting -*- Outline -*- * Using the Wrong Cryptography Based on chapter 21 of the book "24 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega (McGraw Hill, 2010) and chapter 11 of the book "Building Secure Software" by John Viega and Gary McGraw (Addison Wesley 2002). ** background ------------------------------------------ BACKGROUND Who cares about good cryptography? Are there extra defensive measures for fixing bad crypto? ------------------------------------------ ... - the military, intelligence services - banks and financial institutions - people who value their privacy - people who need to sign digitally ... no, you are sending information out of the system ** problems *** using home-grown cryptography ------------------------------------------ USING HOME-GROWN CRYPTOGRAPHY Do NOT create your own ------------------------------------------ ... encryption algorithm Q: Why not create your own algorithm? It's not likely to be any good. Even experts have trouble making up new algorithms that are good. When NIST asked for replacements for the DES, 15 algorithms were proposed, and 3 were broken before the first conference to examine them Q: But won't a new algorithm fool attackers? No, not if they understand cryptography... Q: What to do? Use tried-and-true implementations of respected algorithms. *** using a weak cryptographic primitive ------------------------------------------ USING A WEAK PRIMITIVE Algorithms well known to be weak: - DES (key is too small, only 56 bits) - 3DES - any symmetric algorithm that allows a key of less than 128 bits, e.g., 40 bit RC4 - MD4 and MD5 - 1024-bit RSA and DH may be at risk use 2048 bit keys ------------------------------------------ RC4 can be brute forced in less than 1 hour MD4 is "busted and worthless", MD5 is "not far behind" Q: How to fix software when the currently good algorithms are broken? Make your software configurable *** creating your own protocol ------------------------------------------ CREATING YOUR OWN PROTOCOL Do NOT create your own security protocol from low-level primitives ------------------------------------------ Q: Why not create your own protocol? It's very difficult; experts have made mistakes... You may not understand the properties of your protocol fully Q: What to do? Use a high-level, tested security protocol, such as: - SSL 3 and TLS - IPSec - XMLDSig for signatures - XXMLEnc for encryption *** Using a cryptographic primitive incorrectly ------------------------------------------ USING CRYPTO PRIMITIVES INCORRECTLY: STREAM CYPHERS def: A *stream cypher* works byte-by-byte Best to avoid them if you can! When using a stream cypher: - don't reuse the encryption key - realize that there is no data integrity ------------------------------------------ Q: Why not reuse the encryption key in RC4? both plaintexts are encrypted by xor against the key stream; so xoring the encrypted streams leaves the key stream visible! (a xor k) xor (b xor k) = k ? ------------------------------------------ USING CRYPTO PRIMITIVES INCORRECTLY: def: a *hash* is a digest, used for integrity checks (signatures) Do NOT hash concatenated data! "do not " and "go" vs. "do " and "not go" ------------------------------------------ Q: Can an integrity checker tell the difference? No, when put together they look the same! Q: What to do instead? record all the individual hashes, or hash the hashes ------------------------------------------ LENGTH EXTENSION ATTACKS for code that looks like: Hash = H(secret + username) 1. Attacker gives a username of "M", Hash = (Secret + "M") 2. Now attacker can calculate Hashes for Mike, Molly, etc. ------------------------------------------ Instead use HMAC i.e., instead of Hash = H(secret + username) do Hash - HMAC(secret, username) ------------------------------------------ OTHER FAULTS Do NOT use ECB mode for block cyphers - attacker can tell if 2 blocks have the same cyphertext Do NOT encrypt known plaintext - helps attackers discover the key ------------------------------------------ just don't do these thing *** validating a hash incorrectly ------------------------------------------ VALIDATING A HASH INCORRECTLY Do NOT just check the length Instead ------------------------------------------ ... - calculate the hash - check the lengths - check that all bits match (as bits) *** using the wrong primitive ------------------------------------------ USING THE WRONG PRIMITIVE Can encryption stop tampering with data? ------------------------------------------ ... no, encryption provides secrecy, not tamper-prevention *** using the wrong protocol ------------------------------------------ USING THE WRONG PROTOCOL Do NOT use SSL 2 it is broken ------------------------------------------ *** failure to use salt ------------------------------------------ FAILURE TO USE SALT def: a *salt* is a non-secret random number Used to make precomputation attacks more costly (use more space) Needed in: - key derivation function - deriving an encryption key from a key derivation function ------------------------------------------ Q: What to do? Use a strong RNG to generate the salt. *** failing to use a random initialization vector ------------------------------------------ FAILURE TO USE A RANDOM IV For block cyphers using chaining modes, need an initialization vector (IV) Must be cryptographically random E.g., in C#: AesManaged aes = new AesManaged(); RNGCryptoServiceProvier rng = new RNGCryptoServiceProvider(); rng.GetBytes(aes.IV); ------------------------------------------ *** using a weak key derivation function ------------------------------------------ USING A WEAK KEY DERIVATION FUNCTION def: a *key derivation function* (or KDF) creates a key from something nonrandom (like a password) problem: how to make a KDF with terrible efficiency ------------------------------------------ Q: Why do we want terrible performance in a KDF? That makes it harder to use brute-force attacks *** failure to provide an integrity check ------------------------------------------ FAILURE TO PROVIDE AN INTEGRITY CHECK For stream cyphers: - really need integrity check For block cyphers: - want to know if data may be corrupted ------------------------------------------ RC4 is "hideously open" to bit flipping attacks *** failure to use agile encryption ------------------------------------------ FAILURE TO USE AGILE ENCRYPTION Which algorithms are broken changes quickly So need way ------------------------------------------ ... to change algorithms easily and to change parameters (e.g., number of iterations of KDF)