Mon Jan 9 00:16:33 CET 2012

The Apple Idioten Vektor (IV)

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

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

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.

At least they fail consistently.

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
:-)

Wait! There is more!

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"