Cryptographic Foibles

COEN 225 Secure Coding

False Assumptions

Fresh from the press:RAM retains memory after shutdownRetention 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 Keyshttp://citp.princeton.edu.nyud.net/pub/coldboot.pdf

Using poor random numbers

Most cryptographical algorithms relay on random numbers

Random numbers can be predictableC-run time function rand will generate exactly

the same sequence of random numbersNeed to set seed

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

Using poor random numbers

Using simple random number generation techniquesLinear congruence random number generator:

Allows to predict next value

int __cdecl rand(void) { return((holdrand = holdrand * 214013L+2351011L)>>16)&0x7ffff;}

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

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 …

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

Poor Key Management

Using crypto is easy, storing and managing keys is difficult:Key GenerationKey TransmissionKey StorageKey DestructionKey Revocation

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

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

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:1. Generate key e.g. from user password2. Use key3. 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

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)

Using poor encryption

Do not invent your own encryption algorithmUnless you know what you are doingSubject the result to public scrutinyAre 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

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');}

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

Using poor encryption

Misunderstanding stream ciphersStream ciphers can be very secure if used

correctlyStream ciphers are very fast

Using poor encryption

RC4 first successful stream cipher:

Using poor encryption

Stream ciphers are vulnerable to bit flippingAttacker needs to guess contents of parts of

encrypted streamAttacker can then change contents to any

desired value

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

Using poor encryption

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

Using poor encryption

Mitigation against bit flipping: Use an integrity check at the end of the dataReceiver can confirm integrity of message by

recalculating the hash

Message hash(Message)

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: p1c1, p2 c2, p3 c3, p4 c4, … Encoded Stream 2: q1c1, 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: p1q1, p2 q2, p3 q3, p4 q4, … This is very vulnerable to crypt-analysis

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. …

Using poor encryption

Mitigation:Only use approved cryptographic methodsOnly use them in an approved mannerDo not trust a single security mechanism

since it might be based on a false assumption