Fragile encryption for Android app security

Programmers want to use encryption to improve the security of the program, but lack of professional cryptographic background knowledge, so that the application of data protection is very weak. This article will describe some of the fragile encryption methods that may appear in Android apps, as well as the corresponding attack methods.

the main cause of fragile encryption

There are many reasons for weak encryption in Android apps, and the OWASP Mobile Top 10 gives several reasons:　　

Robust cryptographic algorithms are used with fragile cryptographic algorithms, but cryptographic implementations are vulnerable.

using weak cipher algorithm to implement encryption and decryption

Let's take a look at what happens if an app uses a weak encryption algorithm.

For example, using MD5 as the hash algorithm, MD5 has been considered unsafe. If the application uses a fragile algorithm such as MD5, and the attacker can read the hash, the attacker will have a considerable opportunity to decipher the encryption. Suppose the application uses MD5 to generate such a hash:

8f6b983ad06881847a180f1398910891

An attacker could use tools such as John or an online rainbow table hack service:

For example, the hash was successfully cracked.

In addition, some developers use coding to protect sensitive information. Encoding is not encrypted, and it is easy to decode and restore the plaintext. For example, after we decompile an application, we find the following BASE64 encoded characters:

Sgvsbg8gv29ybgqu

Find a website that provides online base64 decoding to restore clear text:

insecure implementation of strong cipher algorithm

Another is the use of strong encryption, but the use of the method is not secure, for example, using a symmetric encryption algorithm such as AES, although the algorithm is strong enough, but when its implementation is not as vulnerable as the attack.

1.AES Encryption using Javax.crypto.Cipher initialization when using the ECB mode, will make the same plaintext at different times will produce the same ciphertext, vulnerable to dictionary attacks , security is not high enough.

  Public voidInitaes () {Try {             This. Cipher = Javax.crypto.Cipher.getInstance ("aes/ecb/pkcs5padding"); Exception V0_3=NewJavax.crypto.spec.SecretKeySpec ( This. Keybytes, "AES");  This. Cipher.init (1, V0_3);  This. Decipher = javax.crypto.Cipher.getInstance ("aes/ecb/pkcs5padding");  This. Decipher.init (2, V0_3); COM.EASEMOB.UTIL.EMLOG.D ("Encrypt", "Initital for AES"); } Catch(Exception v0_5) {v0_5.printstacktrace (); }        return; }

2. Using securerandom When using the Setseed setting seed will result in random numbers being generated .

It is common for us to realize that the SecureRandom class should be used to generate a key to encrypt local sensitive information, which in practice is inappropriate.

In this approach, instead of storing the key as a string directly in the APK file, the key is generated by another string-a bit similar to generating an encryption key from a user's password. This necessary obfuscation can make it difficult for an attacker to hack encrypted information, but for an experienced attacker, this strategy is easily bypassed, so we do not recommend this approach.

In fact, the existing security mechanisms of Android have provided good protection for this data, sensitive data should be tagged on mode_private, and then stored in internal storage, please note that must not be stored in the SD card, because access control can not force on the external storage function.

Combined with device encryption measures, this approach can eliminate most attacks.

Beyond that, there is another problem with using the SecureRandom class as we described above. Starting with Android4.2, the default implementation of SecureRandom is OpenSSL, where developers cannot overwrite securerandom internal state information, such as the following code:

New securerandom (); byte New byte []{(byte) 1};securerandom.setseed (b); // on Android4.2, the following line of code always returns the same number. System.out.println (Securerandom.nextint ());

(the "Translator note" code can see that the program overrides the seed in the random object, resulting in the same sequence of random numbers generated each time)

In previous versions of Android, SecureRandom was implemented based on bouncy castle, which allowed operations like the above code to be obtained from/dev/urandom when each instance of the SecureRandom class produced a pseudo-random number. ("Translator note"/dev/urandom is a Unix-like system based on the current computer chaotic state, such as memory usage, CPU utilization and other information calculated random numbers, readers can try to cat/dev/urandom under Linux, it will continue to output garbled, the general use of "entropy" This jargon describes the chaotic state of computers. Those who try to generate random numbers are usually created by replacing the existing seed to produce a sequence of random numbers (refer to the relevant implementation document), and if the seed is fixed, then the resulting random sequence is predictable, which is unsafe. This is now done through OpenSSL, making this wrong behavior no longer possible.

Unfortunately, applications that rely on the old SecureRandom class will find that the random numbers generated each time the program starts are different (in fact, this should be the expected behavior of the random number generator). It is not OK to confuse the encryption key in this way.

("Translator note" The original author means that some applications to encrypt sensitive information, encrypted words require a key, but if the key is directly stored up feel very uncomfortable, so by generating a random number of ways to confuse the key, then every time the program starts with the same key to decrypt the data, so through a fixed information, such as a password, or remember a random number, usually many people use the current time, and then through the fixed information as a seed to generate random numbers, using this random number to do the key, the equivalent of a fixed information to do a confusing operation. In fact, this method is still unsafe, security has become how to ensure the safety of this seed, the temporary cure. The following part of the author's idea is that the key should be stored directly on the mode_private tag, and the security of the key is ensured through the system's access control mechanism. ）

the right way

A more reasonable solution is simply to generate a random AES algorithm key when the application first starts:

 Public StaticSecretkey GenerateKey ()throwsnosuchalgorithmexception {//generate a 256-bit key    Final intOutputkeylength = 256; SecureRandom SecureRandom=NewSecureRandom (); //Do *not* seed securerandom!    Automatically seeded from system entropy. //don't give securerandom a fixed seed! Generate random seeds by system entropy valueKeygenerator keygenerator = keygenerator.getinstance ("AES");    Keygenerator.init (Outputkeylength, securerandom); Secretkey Key=Keygenerator.generatekey (); returnKey

Note that the security of this method relies on how the security of the key is ensured, which can depend on the security of the internal storage of the Android system. Store the key directly in the file, marked as Mode_private with internal memory. ("Translator note" Many of our Android phones are rooted, many applications will also get root privileges, root user can do anything ...) What about this? ）

a safer Approach

If your app requires additional encryption, a recommended way is to enter a password or pin every time you enter your app. Then pass this password to PBKDF2 (PBKDF2, password-based key export function version 2, is the RSA Security company proposed key export algorithm, usually used to obtain the key according to the password, through a kind of professional technology called key stretching), Android provides an implementation called PBKDF2WITHHMACSHA1 in the Secretkeyfactory class:

 Public StaticSecretkey GenerateKey (Char[] Passphraseorpin,byte[] salt)throwsnosuchalgorithmexception, invalidkeyspecexception {//The PBKDF2 algorithm executes the number of rounds, the larger the number, the longer the computation time, you should let this number//large enough that the algorithm takes more than 100 milliseconds to secure    Final intiterations = 1000; //generate a 256-bit key    Final intOutputkeylength = 256; Secretkeyfactory secretkeyfactory= Secretkeyfactory.getinstance ("PBKDF2WITHHMACSHA1"); KeySpec KeySpec=Newpbekeyspec (Passphraseorpin, salt, iterations, outputkeylength); Secretkey Secretkey=Secretkeyfactory.generatesecret (KEYSPEC); returnSecretkey;}

The encryption salt should be a random string produced by SecureRandom, and encrypted with ciphertext stored in the internal memory. It is important to use crypto salts, which can effectively prevent dictionary attacks.

("Translator note" See PBKDF2WITHHMACSHA1 this name can also know that the algorithm is based on the SHA1 algorithm, often attack this unidirectional function method is a dictionary attack, pre-calculated a large number of plaintext corresponding ciphertext, like a clear text corresponding to the dictionary, and then a comparison, If the plaintext string is connected to a random string before it is encrypted, then those pre-computed dictionaries are useless. ）

Check that your app is using securerandom correctly

As described in this article, as well as the new security features of the jelly Bean, Android4.2 's securerandom default implementation has changed, and using it to generate a fixed key is no longer feasible.

If you also use this error method, we recommend that you update your app now to prevent some inexplicable errors when users upgrade to Android4.2 or later.

Reference Links:

Http://bobao.360.cn/learning/detail/174.html

Http://www.cnblogs.com/maverick-fu/p/4341808.html

Http://www.importnew.com/3456.html

Fragile encryption for Android app security