in Android Security, Android Studio, Best Practices

Best Practices for Using AES Encryption in Android

One of the most popular encryption methods used today is the AES Encryption (Advanced Encryption Standard). Its development was overseen by the National Institute of Standards and Technology of the U.S. Government, which in the 1990s invited proposals for a strong encryption algorithm to replace the aging Data Encryption Standard (DES). DES was retired because of the use of a smaller-length secret key, which made is very vulnerable to brute-force attacks.

The AES Encryption is a symmetric encryption algorithm. This means that the same secret key is used to both encrypt and decrypt the data. This is unlike asymmetric encryption, where two keys (public and private) are generated. In practice, this introduces a challenge in the use of AES: getting the secret key to the receiver safely. Despite this, however, the AES algorithm is found to be reliable in real-world use and is trusted by the likes of the U.S. government for protecting documents.

How safe is AES Encryption?

AES has been found to be very reliable for real-world use and is the basis of encryption in a number of domains, including government, end-user software, etc. Since AES is only a standard, the algorithm’s weakness lies in the implementation. Also important are the software libraries used in the implementation and how secure those are.

As far as pure encryption strength is concerned, AES offers three key lengths: 128-bit, 192-bit, and 256-bit. Key lengths of above 192 bits produce a level of encryption strong enough to protect highly classified government documents.

Operating modes for AES encryption

Operating modes refer to the various ways in which the AES encryption algorithm can be used. These modes have evolved through the course of the history of the algorithm’s usage, and not all of them are recommended in  modern security practices. Still, they provide a complete picture of the AES algorithm.

The Electronic Codebook (ECB) mode for AES

This mode is the simplest of all, and as a result, not so secure. The basic idea is simple: divide the input plain text into same-sized blocks and apply the same key to produce the ciphertext. A singular advantage of this mode is the ability to add parallelization: once the input message has been broken into blocks, the encryption itself is trivial and is simply a matter of concatenating the output of all the encryption blocks in order. If there are 100 parallel processes working on encryption, the output will appear 100 times faster than in the case of sequential modes.

However, the ECB suffers from a serious drawback. Since the key used is the same, this mode makes it easy for the attacker to brute-force his way into ascertaining the key. This works because, in the ECB mode, same blocks of plaintext will result in identical ciphertexts; this makes it very easy to discern patterns within the ciphertext, which opens a huge back-door for brute force attacks to determine the key used.

The Cipher Block Chaining (CBC) mode for AES

In this mode, the encryption of a block depends on the output of the previous block. Conceptually, what’s done is that the ciphertext output of a block encryption is XORed with the next plaintext block to be encrypted. Once this XORing is done, the key is applied to produce the ciphertext, which becomes the input for the next block, and so on.

So where does the input for the first block come from? This is where this mode introduces the idea of an initialization vector (IV). The IV is a randomized string that serves as the starting point for the encryption. That is, the IV gets XORed with the plaintext of the first block, which then gets encrypted and becomes the XOR input for the second block, and so on.

While much stronger than the ECB mode, the CBC mode introduces a massive performance penalty – the encryption is sequential, and so doesn’t allow any parallelization. Hence, this mode tends to be very slow.

Propagating Cipher Block Chaining Mode (PCBC)

This mode improves on the CBC mode by making the ciphertext less predictable. Essentially, at each stage, the input is XORed with the plaintext and ciphertext from the previous stage, changing the ciphertext at each step. Like the CBC mode, though, this mode depends on synchronous execution and can’t take advantage of parallelization.

Output Feedback (OFB) Mode

This mode is used to convert the AES algorithm from a block cipher to a stream cipher of synchronous type. It generates a stream of the secret key, which is then XORed with the plaintext to get the ciphertext. Because the encryption in this mode happens on a per-bit basis, it is more efficient to transmit information as error-detecting codes can be applied easily. The ciphertext of each state is fed into the stream generator of the next stage to produce the next stream of secret keys.

While the generation of streams is synchronous, this mode can optimize the generation of final ciphertext. This is because the final ciphertext generation at each stage depends only on the XORing of plaintext and  ciphertext, and can be computed via parallel processes once the stream generation is done for each stage.

There are much more modes of AES encryption, but they are variants of these and tend to add small improvements.

Guidelines for using the various modes of AES

Different AES modes have different strengths and weaknesses, and these should be kept in mind when choosing a mode.

  • The ECB mode is pretty weak and is best avoided. The only exception is when encrypting a single block of plain text because in those there will be nothing to compare against and determine patterns in the ciphertext.
  • CBC and OFB are quite close in their operation and can be used interchangeably.
  • The counter (CTR) mode, another variation of the OFB mode, is used when you need parallel processing of encryption to speed things up.
  • Finally, for encrypting data that is accessed randomly (say, hard disks), you should use specialized modes like the XTS mode.

AES safeguards specific to Android

As concerns the encryption on Android, certain key points are worth keeping in mind:

  • It’s better to be paranoid: When it comes to information access on Android, it’s recommended to remember that access rules are loose and often don’t exist. An average smartphone is exposed to several hands, gets connected to multiple computers, and is under threat from apps with aggressive permissions. This means that all information stored on the phone is open to snooping. More specifically, this calls for not storing the secret key directly on the device. Even the Android root file system can’t be relied upon, as it is accessible on rooted phones (a practice that is quite common).
  • Don’t use the String class: The strings created by the standard String class in Java are immutable. This means that if the secret key is stored in a string, it is visible in the RAM during its lifetime, and there’s no way to way to change it. Instead, the byte array is recommended for storing sensitive keys.
  • Randomize the Initialization Vector (IV): Since the IV also gets transmitted to the receiver along with the ciphertext, using the same IV for each message is not recommended. IV for each message should be randomized by using a strong algorithm.
  • Avoid the EditText field: The problem with String class extends to the EditText field in Android, as it returns a standard String. The workaround is more tedious but safer: construct a new view that listens to key tap events and collects them into a byte array.
  • Avoid adventurous implementations: It can be tempting to use that shiny new implementation of AES and feel good, but it’s a practice best avoided. There’s no telling what loopholes exist in which implementation, so it’s better to stick to the standard ones.

In conclusion, the AES encryption is one of the most popular and recommended algorithms for encryption, but getting it right is not as straightforward as may seem as first sight. Several precautions and best practices go into making an application use it securely, especially when it comes to Android.