mod%log

We all agree that crypto is important and therefore should be left to the experts. Well, kind of. This "expert" thing is probably the most extensively construed thing in the world of IT security. We all know, that we have a vast amount of "experts" out there.

Apple still ignores the fact that Objective-C and Cocoa is the new PHP. Most iOS programmers ain't reflect anything that has been told to them - functionality matters, what else. You'll become a super-hero in your company if you have proven to be able adding security to your Apps! Fortunately, Apple provides a crypto library that isn't that complicated, so even your 17 years old iOS expert student is able to generate new buzzwords for your portfolio & keynote slides, hence more $$$.

So... let's call this thing that Apple must take care of:

Responsibility regarding how secure and safe their software is, how unambiguous their application programming interfaces should look like, and how it is published and documented.
Apple provides documentation to their APIs in their online iOS and OSX Developer Library. They also have some crypto stuff available here, let's have a look at the CryptoExercise - sounds promising to get a brief understanding about their high level crypto API:

This sample demonstrates the use of the two main Cryptographic API sets on the iPhone OS SDK. Asymmetric Key Encryption and random nonce generation is handled through the Security framework API set, whereas, Symmetric Key Encryption and Digest generation is handled by the CommonCrypto API set. The CryptoExercise sample brings both of these APIs together through a network service, discoverable via Bonjour, that performs a "dummy" cryptographic protocol between devices found on the same subnet. Link: Apple Crypto Exercise

The CryptoExercise is the official "Related Sample Code" when it comes to "Secure Coding" and e.g. to the "Certificate, Key, and Trust Services Reference".

They also provide a man-page for their "Common Crypto Interface" CCCryptor(3cc):

  CCCryptorCreate, CCryptorCreateFromData, CCCryptorRelease,
  CCCryptorUpdate, CCCryptorFinal, CCCryptorGetOutputLength,
  CCCryptorReset, CCCrypt -- Common Cryptographic Algorithm Interfaces

Using the CCCryptor, one can use common sounding functions such as CCCryptorCreate, CCCryptorUpdate, CCCryptorFinal (or simply CCCrypt() one-shot function) to perform symmetric encryption using different algorithms like AES, 3DES and hardcore security ciphers like RC4, DES, etc.

Apple supports ECB and CBC mode for their ciphers, and fortunately a developer really needs to explicitly prove stupidity by using ECB since APIs default to CBC, the Cipher Block Chaining mode. What could possibly go wrong? Right, there is some minor thing that is called the "IV". Apple supposedly translated the acronym IV to "Ignorance Vector" when writing their Common Crypto API man-pages, but we should read "Initialization Vector" - used to initialize the very first block of cipher text.

You can easily learn (even on Wikipedia), that IVs must be unique for any message encrypted with a given key. And also, that an IV must be unpredictable to avoid several types of cryptographic attacks. That's pretty well known, and there is exactly no single use case for an IV initialized entirely with zeros.

And this is how they describe their API and especially the usage of the IV:

Another option for block ciphers is Cipher Block Chaining, known as CBC mode. When using CBC mode, an Initialization Vector (IV) is provided along with the key when starting an encrypt or decrypt operation. If CBC mode is selected and no IV is provided, an IV of all zeroes will be used.

Instead of simply returning ENOBRAIN, they initialize the IV with zeros without any warning. This is so damn unique and unpredictable, you can't make this up.

In their header files they call the Initialization Vector "optional":

@param  iv      Initialization vector, optional. Used by 
                block ciphers when Cipher Block Chaining (CBC) 
                mode is enabled. If present, must be the same
                length as the selected algorithm's block size. 
                If CBC mode is selected (by the absence of the 
                kCCOptionECBMode bit in the options flags) and no 
                IV is present, a NULL (all zeroes) IV will be used. 
                This parameter is ignored if ECB mode is used or
                if a stream cipher algorithm is selected.
...
CCCryptorStatus CCCryptorCreate(
        CCOperation op,             /* kCCEncrypt, etc. */
        CCAlgorithm alg,            /* kCCAlgorithmDES, etc. */
        CCOptions options,          /* kCCOptionPKCS7Padding, etc. */
        const void *key,            /* raw key material */
        size_t keyLength,       
        const void *iv,             /* optional initialization vector */
        CCCryptorRef *cryptorRef);  /* RETURNED */
...

and the sample code looks like that:

...
uint8_t iv[kChosenCipherBlockSize];
memset((void *) iv, 0x0, (size_t) sizeof(iv));
...
// Create and Initialize the crypto reference.
ccStatus = CCCryptorCreate( encryptOrDecrypt, 
                            kCCAlgorithmAES128, 
                            *pkcs7, 
                            (const void *)[symmetricKey bytes], 
                            kChosenCipherKeySize, 
                            (const void *)iv, 
                            &thisEncipher
                        );
...

Well done, Apple. Now imagine those guys that i have mentioned above, super special experts on iOS and OSX application security and crypto. They will use your documentation, your notes & hints and they will also use your official sample code. And nobody will ever question, what you have told them. Now, go ahead and watch github projects forking like hell, using your broken code! This simple mistake might increase for a decent period of time due to code copy & paste mentality in iOS/OSX open source projects. Maybe even your recently featured, closed source OSX AppStore application that safely stores passwords, follow your guidelines :-)

There are people out there, who are abusing dead trees to spread the word. Using Google Books, i found two books, covering OSX/iOS application security and also crypto. 50 % of those books simply made it wrong as you did, Apple, fifty per cent. "Professional Cocoa Application Security By Graham J. Lee" did it right, this book is on "Amazon Best Sellers Rank: #527,874". The following book did it wrong: "Pro Core Data for IOS: Data Access and Persistence Engine for iPhone, iPad, and iPod touch" [sic!] By Michael Privat, Robert Warner - Chapter "Using Core Data in Advanced Applications - Creating an Application for Note and Password Storage and Encryption" - and guess what: "Amazon Best Sellers Rank: #289,601"