Cryptographic Foibles

1. Cryptographic Foibles COEN 225 Secure Coding

2. False Assumptions • Fresh from the press: • RAM retains memory after shutdown • Retention boosted by cold air • Allows access to encryption keys after system shutdown J. Alex Haldermany, Seth D. Schoenz, Nadia Heningery, William Clarksony, William Paulx, Joseph A. Calandrinoy, Ariel J. Feldmany, Jacob Appelbaum, and Edward W. Felteny: Lest We Remember: Cold Boot Attacks on Encryption Keys http://citp.princeton.edu.nyud.net/pub/coldboot.pdf

3. Using poor random numbers • Most cryptographical algorithms relay on random numbers • Random numbers can be predictable • C-run time function rand will generate exactly the same sequence of random numbers • Need to set seed

4. Using poor random numbers • Most cryptographical algorithms relay on random numbers • Random numbers can be predictable • C-run time function rand will generate exactly the same sequence of random numbers • Need to set seed • Derive seed from something that cannot be guessed or controlled • Time-date stamp not good enough

5. Using poor random numbers • Using simple random number generation techniques • Linear congruence random number generator: • Allows to predict next value • int __cdecl rand(void) { • return((holdrand = holdrand * 214013L+2351011L)>>16)&0x7ffff; • }

6. Using poor random numbers • Linear congruence random number generator • ASF Software’s Texas Hold ‘Em Poker • Allowed to predict the complete deck after knowing five cards from the deck • http://www.cigital.com/news/index.php?pg=art&artid=20 • Code Red Worm IP address generation • “Random” IP addresses were not random • Worm tried to infect same targets from all infected computers • Netscape Navigator (Early versions) • SSL keys were highly predictable

7. Using poor random numbers • Mitigation • Use better random number generators • FIPS 186-2 approved • CryptGenRandom() API in Windows • Uses system entropy for a seed: • Current time • Performance counters • User environment block • Low level system information • System exception information • …

8. Poor Key Management • Password derived keys • Subject to guessing attacks • Subject to dictionary attacks • Pronouncable or memorizable passwords contain entropy: • Minimum password length for 56b / 128b key is • Numeric PIN: 17 40 • Case insensitive alpha: 12 28 • Case sensitive alpha: 10 23 • Alpha-numeric 10 22 • Alpha-numeric + punct. 9 20

9. Poor Key Management • Using crypto is easy, storing and managing keys is difficult: • Key Generation • Key Transmission • Key Storage • Key Destruction • Key Revocation

10. Poor Key Management • Key storage • If stored in plaintext, can find keys in on-disk image • Passwords are easier, since we can store the hash of a password • Keys that are text strings can be found by looking for all strings. • Try out Windows utility strings • Can find keys in memory image of running processes • Winhex will dump Windows memory • nCipher offers utility that attaches itself to running process and scans process memory for areas of high entropy • These are possible keys • RAM does not loose contents immediately after power-down • Can investigate RAM for keys

11. Poor Key Management • If possible: • Generate key (possibly from user input, system info, …) • Write code that does not move key around • Generates multiple copies • Pass key with handle / pointer • Safely destroy key after use • If possible: • Do not use the same buffer for plain text and cipher • IIS 4 did that and under certain load conditions would send out plain text in SSL

12. Poor Key Management • Mitigation • Never store key in code, configuration files, or registry • Use the protection the OS provides • Windows Data Protection API • Not feasible in Win95, Win98, Win2000, WinCE • Use removable media if it fits into operational environment • If key is generated in memory: • Generate key e.g. from user password • Use key • Scrub the memory by overwriting key • Beware of optimizing compilers deciding that the memory area is not going to be used and does not need to be scrubbed

13. Poor Key Management • Mitigation • Key Exchange • Avoid key exchange if possible • Consider sneaker net • Use cryptographic protocols that • create a secure channel • authenticate both partners • are secure against man-in-the-middle attacks • are certified • Never, never invent your own crypto-protocol • (Unless you know what you are doing and have it subjected to public scrutiny)

14. Using poor encryption • Do not invent your own encryption algorithm • Unless you know what you are doing • Subject the result to public scrutiny • Are willing to face product liability suits if your product is unsafe

15. Using poor encryption • Do not create a cipher text by xor-ing a natural language text with another text • Do not create a cipher text by xor-ing with a password void encrypt( char * plain, char * cipher, char * passwd) { while(*plain != '\0') { *(cipher++) = *(plain++) ^ *pwd; if(*pwd == '\0') pwd = passwd; *plain = '\0'); }

16. Using poor encryption • Assume strlen(passwd) = n. • XOR cipher with itself moved by n • cipher[i]  cipher[i+n] • This equals plain[i]  plain[i+n] • Calculate frequency of symbols • Has a spike for 0 (xoring space with space, e with e, …) • This allows you to guess n • After you guessed n, do a simple frequency analysis of the streams • cipher[j], cipher[j+n], cipher[j+2n], cipher[j+3n], … • Obtained by xoring with the same symbol • Have the same frequency distribution as original text

17. Using poor encryption • Misunderstanding stream ciphers • Stream ciphers can be very secure if used correctly • Stream ciphers are very fast

18. Using poor encryption • RC4 first successful stream cipher:

19. Using poor encryption • Stream ciphers are vulnerable to bit flipping • Attacker needs to guess contents of parts of encrypted stream • Attacker can then change contents to any desired value

20. Using poor encryption • Bit flipping example • Email uses cookies to store account name. • Attackers account is 00401 = 0x 30 30 34 30 31 • Key stream is 0x f1 34 95 20 01 10 • Encrypted account is 0x c1 04 a1 31 21 • Attacker want to access account 00402 = 0x 30 30 34 30 32 • Can reconstruct key stream from plain text and cipher • Or: XOR Old encrypted stream, old account number, new account number • Result: • Target account is encrypted as 0x c1 04 a1 31 23

21. Using poor encryption • Warning: Some block streams in certain modes are also vulnerable to bit flipping or to block exchanges

22. Using poor encryption • Mitigation against bit flipping: • Use an integrity check at the end of the data • Receiver can confirm integrity of message by recalculating the hash Message hash(Message)

23. Using poor encryption • Misusing stream ciphers • Using the same key twice • Key streams are the same • Example: • Stream 1: p1, p2, p3, p4, … • Stream 2: q1, q2, q3, q4, … • Encoded Stream 1: p1c1, p2 c2, p3 c3, p4 c4, … • Encoded Stream 2: q1c1, q2 c2, q3 c3, q4 c4, … • Can sometimes guess parts of a stream • And therefore guess the corresponding parts of the other stream • XOR both streams together and obtain XOR of plain texts: • p1q1, p2 q2, p3 q3, p4 q4, … • This is very vulnerable to crypt-analysis

24. Using poor encryption • Example WEP (Wired Equivalent Privacy) • Used the same key to encode both header and payload of package • But header is very predictable, therefore could always guess parts of payload • Used integrity code but integrity code was CRC • Can calculate the value that CRC takes if parts of the message are changed • Therefore, CRC does not protect against bit-flipping • Used poor key-generation and poor random number generation • Occasional vulnerable keys will eventually be used. • …

25. Using poor encryption • Mitigation: • Only use approved cryptographic methods • Only use them in an approved manner • Do not trust a single security mechanism since it might be based on a false assumption