Using Android Jetpack Security

Kayvan Kaseb
Software Development
5 min readSep 14, 2020
The picture is provided by Unsplash

Undoubtedly, security is a critical issue in Android application development; however, accomplishing all tasks correctly could be tricky. At Google IO/2019, Google introduced the Jetpack Security library, which aims to address some controversial issues in Android security to ease the process of making apps more secure. This essay will discuss some concepts and features in Android Jetpack Security for having more secure Android apps.

Introduction and Overview

At Google IO/2019, Google introduced the new Jetpack Security library, which aims to solve some critical issues in Android security. Jetpack Security provides an abstraction over security. In fact, it is a wrapper around primitives that are built into the platform. Therefore, it makes encrypting files and shared preferences more effectively. In addition, the Android KeyStore stores cryptographic keys in a container to make it much more difficult to extract from the device. Once keys are in the KeyStore, they could be used for cryptographic operations in the trusted execution environment, and the key material is not exportable. The Android KeyStore also provides some options like StrongBox to store and operate on keys in a secure hardware chip. Thus, the question is how does an Android developer take advantage of these platform features?

The Security library, part of Android Jetpack, provides an implementation of the security best practices related to reading and writing data at rest, as well as key creation and verification.

Basically, Jetpack Security, or JetSec for short, takes advantage of the Android KeyStore to maintain encryption keys in hardware, which makes accessing the key material would be extremely hard. Besides, JetSec supports high level of abstractions for encrypting files and shared preferences to allow Android developers to encrypt their data safely. Another significant point is that there is no need to understand algorithms and block modes. Fundamentally, JetSec is classified into two sections: Key Management and Data Encryption.

The Android KeyStore system lets you store cryptographic keys in a container to make it more difficult to extract from the device. Once keys are in the KeyStore, they can be used for cryptographic operations with the key material remaining non-exportable.

Both of these abstractions provide authenticated encryption with associated data, or AEAD for short, which provides simultaneous insurance for confidentiality and integrity of the data.

Key Management

As a matter of fact, the Jetpack Security library uses two types of key for key management concept as follows:

  1. A key-set that includes one or more keys to encrypt a file or shared preferences data. The key-sets are encrypted and stored in the shared preferences.

2. A master key that encrypts all key-sets. Only the master key is stored in the Android Key-store system to make it much more difficult to extract from the device.

Also, all data secured by JetSec is performed via the Android store. JetSec uses the concept of a master key, which is hardware-backed and optionally locked by bio-metrics such as fingerprint or face identification. This helps secure key sets, which are treated per cryptographic algorithm. In fact, AndroidX Security is using the Tink library under the hood. Tink is an open-source crypto library created by Google that supports cryptographic APIs. Out of the box, JetSec enables developers to create a master key with one line of code:

JetSec creates an industry standard AES256-bit key. This could be useful for most use cases, but for more sensitive data, there are more customization that could be accomplished. So, it is highly recommended to connect hardware-backed keys to user presence via a bio-metric credential. The Android keystore enforces bio-metrics at the hardware level, and keys will not be available for use without authorizing the device using the bio-metric prompt Jetpack Library. For utilizing JetSec, Google has recommended the time-bound key approach, which enables developers to lock and unlock keys for a limited amount of time. This is particularly useful when dealing with enterprise, financial, and other very sensitive data. To crate a custom key, you will need to indicate keystoreAlias and key purposes along with other encryption configurations. For instance:

Furthermore, we can be able to use its setUserAuthenticationRequired property to enable user authentication feature. The master key can just only be obtained for the seconds mentioned in setUserAuthenticationValidityDurationSeconds after the user authenticates himself by using bio-metric fingerprint or screen lock. For example:

setUserAuthenticationRequired(true)
setUserAuthenticationValidityDurationSeconds(6)

Eventually, we can be able to use the key for specified time once we obtain success in BiometricPrompt’s onAuthenticationSucceeded method as follows:

For time-bound master keys, Jetpack BiometricPrompt is a quick and easy way to display a backwards compatible bio-metric check on the device. You should use the Jetpack library rather than the direct platform APIs because Jetpack manages pin passwords, as well as multiple modalities, such as fingerprint and face identification.

Data encryption: how to encrypt your files and shared preferences

As you know, encrypted files have been a challenge in the past due to size limitations because the entire file would have had to have been required to be loaded into memory. EncryptedFile takes advantage of streaming AES encryption that can manage files of all sizes with just only disk space as the limiting factor. EncryptedFile could be treated similar to a normal file in Android. Once the encrypted file object has been created, you may operate on the file with the file input/output streams provided. As a result, the same encryption concepts would be applicable for EncryptedFile. For instance:

These lines of codes can create an EncryptedFile object from a normal file object. Some parameters such as FileEncryptionScheme, KeysetPrefName ,KeysetAlias are optional in implementation. In other words, they are used to name the XML file and the key inside it, which stores the encryption key value. At the moment, after obtaining the encrypted file, if you want to write some data to your encrypted file or read from it, you can use the openFileOutput() and openFileInput() methods as follows:

SharedPreferences Encryption

If you just need to persist data that can be easily model in key value pairs, encrypted shared preferences provides an implementation of shared preferences which handles encryption automatically. In general, encrypting shared preferences is similar to encrypting files. So, we store our data in SharedPreferences because it is easy to use. In the meantime, it would be an easy target for the attackers to obtain the keys from SharedPreferences. Therefore, we require to encrypt our SharedPrefernce data with utilizing EncryptedSharedPreferences feature in Security library. The important note to indicate is that the keys and values are encrypted in a different way. You can encrypt shared preferences as follows:

In conclusion

Undoubtedly, security is a critical issue in Android development, but accomplishing all tasks correctly could be tricky. This article explained some concepts and features in Android Jetpack Security based on Google resources. Although there are some prominent classes in this library for Android developers, there are some drawbacks are remained to consider such as some limitations in applying some algorithms and comparability of Android devices in working with this library (This is available for Android version 6.0 or higher).

--

--

Kayvan Kaseb
Software Development

Senior Android Developer, Technical Writer, Researcher, Artist, Founder of PURE SOFTWARE YAZILIM LİMİTED ŞİRKETİ https://www.linkedin.com/in/kayvan-kaseb