Cryptography in iOS - How to protect your precious data?
Our current project (PDF Subscription service) is in need some urgent tasks relating to protecting data far away from hackers. There are many ways to put data into pocket with multi-levels, especially in iOS. As one of my tasks in the project, I would like to learn more about cryptography and apply into our end-to-end encryption with PDF data, image data and a part of video data. As my normal habit, I noted what I read about.
This section is for someone who is not familiar with cryptography. Some basic terms will be unleashed here.
Symmetric and Asymmetric cipher
Key and Salt
Key is not a password! If we have a password, we must convert it into a key. This key is for encrypting and decrypting document. Needless to say, the key is not public as the password. For making a key, we need a salt described as follows.
Salt is usually a large, random number for generating a key from a password. Because password is usually short and easy to remember, we should make a key which is long and hard to read which prevents brute-force attack. To do this task, a salt is needed. It will be combined with password, the result is a key.
In fact, salt is public, not need to be secret.
HMAC (Hash-based Message Authentication Code)
Initialization Vector (IV)
Cipher-block is must be multiple of block size. Sometimes the last block may be smaller than block size. Therefore, we must add pseudo-data to the end of plaintext. This block size problem is dealt with by padding.
Padding is the practice of expanding plaintext to the correct length prior to encryption. It needs to be done in a way that the padding can be unambiguously removed after decryption. There are several ways to achieve this, but the only way supported by iOS is called PKCS #7 padding.
Implementation in iOS
Fortunately, Rob Napier opens his work at RNCryptor. That helps us save a lots time but it is better if we know a litte bit about these techniques.
Do not try to encrypt a file in separate parts
Firstly, do not try to encrypt a file in separate parts. Normally, an encrypt algorithm will save a header in cipher text, included key (gen from password), HMAC, salt and so on. Therefor, decrypt algorithm will read the header first to get these information before decrypting. If you encrypt a file by chunking this file and encrypting each part separately, cipher text will contains many headers. That will make decrypt algorithm goes fail because it cannot know where is header and where is cipher text.
OpenSSL is deprecated from OSX 10.7 and not included in iOS
In addition to these APIs, a number of open source tools use OpenSSL for secure networking. If you use OpenSSL in your publicly shipping apps, you must provide your own copy of the OpenSSL libraries, preferably as part of your app bundle; the OpenSSL libraries that OS X provides are deprecated. Refer link.
The reason Apple raised for that is: OS X includes a low-level command-line interface to the OpenSSL open-source cryptography toolkit; this interface is not available on iOS.
Further, although OpenSSL is commonly used in the open source community, **it does not provide a stable API from version to version**. For this reason, the programmatic interface to OpenSSL is deprecated in OS X and is not provided in iOS. Use of the Apple-provided OpenSSL libraries by apps is strongly discouraged.
One of Apple Engineers said in details at here.
Open source - Library
- RNCryptor by author of the above book
- NAChloride. An Objective-C wrapper of libsodium which a package of NaCl. “NaCl (pronounced “salt”) is a new easy-to-use high-speed software library for network communication, encryption, decryption, signatures, etc. NaCl’s goal is to provide all of the core operations needed to build higher-level cryptographic tools.”.
- Original Security Libray by Apple.
- Aerogear Crypto iOS.
blog comments powered by Disqus