More Than 8-in-10 iOS Apps Have Poor Standards of Cryptography

For a profession which should use cryptography as a common knowledge base, the general standards applied are often poor, especially for…

More Than 8-in-10 iOS Apps Have Poor Standards of Cryptography

For a profession which should use cryptography as a common knowledge base, the general standards applied are often poor, especially for those involved in software development. And so Feichtner et al [here][1] decided to analyse Apple iOS for security mis-configurations around cryptography:

For this they used a decompilation method to analyse the code within applications found on the Apple Store, and then revealed their data flows.

Within iOS, there are common crypto libaries and which are used to implement ciphers, hashes, and key derivation functions. CommonCrypto is used for symmetric ciphers, hashs and key derivation functiosn, where as Security is used for asymmetric functions, and digital certificate operations. The calls detects are:

  • CCCryptorCreate/CCCrypt: This involves the initialisation of the cryptographic function, such as for the cipher type, the pointer to the key, and the pointer to the IV.
  • CCKeyDerivationPBKDF. This involves the conversion from pass phrases and salt to a derived key, using PBKDF2.

The basic rules applied were:

  • Rule 1: Do not use ECB mode for encryption.
  • Rule 2: Do not use a non-random IV for CBC encryption
  • Rule 3: Do not use constant encryption keys.
  • Rule 4: Do not use constant salts for PBE (Password-based encryption).
  • Rule 5: Do not use fewer than 1,000 iterations for PBE.
  • Rule 6: Do not use static seeds to seedSecureRandom.

In their analysis they found that 82% of the 417 applications analysed had at least one cryptographic flaw. Most of these related to the usage of a non-random Initalisation Vector (IV) and in the usage of constant encryption keys. The lack of an IV makes the cryptography significantly reduces the strength of the encryption, especially in the face of a dictionary attack.

The results showed that 69% of the apps did not use a non-random IV and that 64% used a constant encryption key (Table 1). What is really shocking — from a knowledge point-of-view — is that 27% of the apps used ECB. Anyone who knows anything about cryptography should know that you should NEVER use ECB, as it can be easily attacked.

Table 1

Conclusions

More than 8 in 10 iOS have a cryptographic flaws, and which is a poor result, especially when Apple has a good standard for reviewing code. Our industry must get better at designing software and which has security at its core. No other industry in the world would get away with such poor standards. Imagine if 80% of bridges created had a design flaw in them, and where the bridge could collapse? Would this be allowed?

References

[1] Feichtner, J., Missmann, D., & Spreitzer, R. (2018, June). Automated Binary Analysis on iOS: A Case Study on Cryptographic Misuse in iOS Applications. In Proceedings of the 11th ACM Conference on Security & Privacy in Wireless and Mobile Networks (pp. 236–247). ACM.