Cryptographic Foibles COEN 225 Secure Coding False Assumptions

Cryptographic Foibles COEN 225 Secure Coding

False Assumptions n 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

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

Using poor random numbers n n 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 n Time-date stamp not good enough

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

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

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

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

Poor Key Management n Using crypto is easy, storing and managing keys is difficult: ¨ Key Generation ¨ Key Transmission ¨ Key Storage ¨ Key Destruction ¨ Key Revocation

Poor Key Management n Key storage ¨ If stored in plaintext, can find keys in on-disk image n ¨ Keys that are text strings can be found by looking for all strings. n ¨ Passwords are easier, since we can store the hash of a password Try out Windows utility strings Can find keys in memory image of running processes n n Winhex will dump Windows memory n. Cipher 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 n Can investigate RAM for keys

Poor Key Management n If possible: ¨ Generate key (possibly from user input, system info, …) ¨ Write code that does not move key around n n Generates multiple copies Pass key with handle / pointer ¨ Safely n destroy key after use If possible: ¨ Do n 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

Poor Key Management n Mitigation ¨ Never store key in code, configuration files, or registry n Use the protection the OS provides ¨ n ¨ Windows Data Protection API § Not feasible in Win 95, Win 98, Win 2000, Win. CE Use removable media if it fits into operational environment If key is generated in memory: 1. 2. 3. Generate key e. g. from user password Use key Scrub the memory by overwriting key n Beware of optimizing compilers deciding that the memory area is not going to be used and does not need to be scrubbed

Poor Key Management n Mitigation ¨ Key Exchange n n n 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)

Using poor encryption n 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

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

Using poor encryption n Assume strlen(passwd) = n. ¨ XOR cipher with itself moved by n n n ¨ ¨ ¨ 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+2 n], cipher[j+3 n], … Obtained by xoring with the same symbol Have the same frequency distribution as original text

Using poor encryption n Misunderstanding stream ciphers ¨ Stream ciphers can be very secure if used correctly ¨ Stream ciphers are very fast

Using poor encryption n RC 4 first successful stream cipher:

Using poor encryption n 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

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

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

Using poor encryption n 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)

Using poor encryption n Misusing stream ciphers ¨ ¨ ¨ Using the same key twice Key streams are the same Example: n n ¨ Can sometimes guess parts of a stream n ¨ Stream 1: p 1, p 2, p 3, p 4, … Stream 2: q 1, q 2, q 3, q 4, … Encoded Stream 1: p 1 c 1, p 2 c 2, p 3 c 3, p 4 c 4, … Encoded Stream 2: q 1 c 1, q 2 c 2, q 3 c 3, q 4 c 4, … And therefore guess the corresponding parts of the other stream XOR both streams together and obtain XOR of plain texts: n n p 1 q 1, p 2 q 2, p 3 q 3, p 4 q 4, … This is very vulnerable to crypt-analysis

Using poor encryption n Example WEP (Wired Equivalent Privacy) ¨ Used the same key to encode both header and payload of package n ¨ Used integrity code but integrity code was CRC n n ¨ But header is very predictable, therefore could always guess parts of payload 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 n n Occasional vulnerable keys will eventually be used. …

Using poor encryption n 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