bad practices in Apple’s sample code for the doCipher:key:context:padding method

Question

According to this article http://blog.gdssecurity.com/labs/2013/3/5/retrieving-crypto-keys-via-ios-runtime-hooking.html

There is "bad practices in Apple’s sample code for the doCipher:key:context:padding method http://developer.apple.com/library/ios/#samplecode/CryptoExercise/Listings/Classes_SecKeyWrapper_m.html. The following code snippet shows that it will use a static IV of 16 bytes of 0x0’s.

 // Initialization vector; dummy in this case 0’s.

uint8_t iv[kChosenCipherBlockSize];

memset((void *) iv, 0x0, (size_t) sizeof(iv));

Why is it really bad in layman's term and how to fix it ?

What I only understand is that it is possible to hook that code to intercept the symetric key. But I don't understand why and how to prevent this.

Answer 1

The code outlined in that post is insecure because it does not follow the rule about Initialization Vectors being random values. Notice that the engineer who wrote it commented:

//... dummy in this case 0’s.

True initialization vectors of a fixed size (or IVs, as the blog calls them) would never allocate a buffer to be passed to a crypto function with the same value over and over, they would instead randomize the data contained by the buffer each time so that its location could not be inferred by looking at the sample code provided -as the author did. Just cut out the call to memset(), and that block of memory will be filled with "junk" by the runtime. If you want to get technical, write your own version of memset() that generates pseudo-random data to overwrite the memory of that local.

Answer 2

In Classes_SecKeyWrapper.m we see that the initialization vector (IV) is used in a call to CCCryptorCreate, which defaults to use cipher-block chaining (CBC) mode (as documented in CommonCryptor.h).

CBC mode XORs each block with the next before encrypting and ensures that two identical blocks don't produce the same result. Because the first block has no previous block to be XORed with, you are required to made up a block called “initialization vector”. This randomizes the output of the first block and lowers the chance of a replay attack or a chosen-ciphertext attack.

In CBC mode, the initialization vector should be random and unique for each call to CCCryptorCreate, and should be used by the encryptor and the decryptor code (so you have to send it along the message to whoever wants to decrypt the result).

The Apple sample code is commented with dummy in this case 0's. A dummy is a substitute for the real thing, so I believe the original writer was aware of the issue and simply chose to write a simplified example on purpose.