Cryptography
Last few weeks I spent on Cryptography and Internet security courser. I finished Cryptography course on Coursera and Internet security on my college. I learned very useful things that will be relevant for making reimplementation of CryptoLint. In this post I will explain six rules that are, according to the paper "An Empirical Study of Cryptographic Misuse in Android Applicatios", reviewed with CryptoLint. However, I will explain few more mistakes that are potentially important to examine. I will not explain how encryption algorithm works and similar things, but I will put links for those who are not familiar with cryptographic concepts.
First rule prohibits the use of Electronic Codebook mode (ECB) for encrypting more than one block of data with the same key, because identical messages (blocks) will encrypt to identical ciphertexts. Such a leak of information is dangerous.
Second rule recommends not to use Cipher Block Chaining mode (CBC) with non-random initialization vector (IV), because attacker will know the IV in advance and he can perform the attack. For example, lets say he wants to verify that the previous message was "attack at dusk". For that message, IV1 was used, and he knows that for the next message IV2 will be used. Then, what he does is trick the victim to encrypt a message M which is specially constructed as M=IV1?"attack at dusk"? IV2, and when he receives ciphertext, compares it to the one that contains unknown message he tries to guess. If they match, then he successfully guessed plaintext.
Third rule is trivial, but very important. It says not to use symmetric key hard-coded in software that is distributed to more than one party. A hard-coded key in publicly available software is not a secret key, thus the resulting encryption does not provide secrecy.
Fourth and fifth rules are about password based encryption (PBE). It is strongly recommended not to use constant salts, because static salt allows an attacker to pre-compute a dictionary based on the known salt, negating much of the benefit of using a salt at all. Furthermore, according to PKCS#5 standard it is recommended to use at least 1000 iterations for PBE. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.
Sixth rule tells not to seed SecureRandom() functions with static value. Androids SecureRandom function is a pseudo-random number generator (PRG) that needs to be properly seeded by some random value. A PRG seeded with a constant seed will produce a constant, known output across all implementations and all runs. Since PRGs are often used to create keying material, the resulting keys are not random, and thus not secure. PRG (Pseudo Random Generator) must be unpredictable, which means there is no efficient algorithm that could predict the output.
There are some rules that could be checked, but CryptoLint didnt check them. I will enumerate and explain them now and I will try to add them to my implementation. OTP (One time pad) must use a single key only once, because if it uses the same key twice there is a simple attack on it: M1 ? M2 = C1 ? C2. More about attack.
Furthermore, confidentiality must always go with integrity, which means, for perfect secrecy, we have to use algorithms that provide confidentiality and integrity. If we use only algorithms that provide confidentiality there is a simple attack in that case. Lets say Alice is sending HTTP request to server which is on port 80. Attacker is listening on port 30, so he will easily change port number from 80 to 30, and when server gets the request he will decrypt the message and send it to attacker as plaintext. However, it is very important how are MAC and encryption combined. It is recommended not to implement those algorithms by yourself, and especially not to use encryption and hash combination (sometimes hash then encrypt) because it can be very vulnerable. Best way is to use standards like: GCM (CTR mode encryption then CW-MAC ), CCM (CBC MAC then CTR mode encryption), EAX (CTR mode encryption then CMAC).
When decryption fails it is very important not to explain why it failed, more precisely, it should not be told to attacker was it MAC error or a pad error, because attacker can change cipher and by looking at the types of errors he can obtain plain text. Furthermore, even if the same error message is used for MAC error and pad error, it is important that reply time doesnt depend on MAC error and pad error. More about padding oracle attack and timing attack.
At the end of the post, when we talk about cryptography, the most important thing is to use standards that are secure and implemented by experienced professionals.
download file now