Secure data in Android — Encryption in Android (Part 1)

Yakiv Mospan
ProAndroidDev
Published in
6 min readOct 26, 2017

--

This article is a part of “Secure data in Android” series:

  1. Encryption
  2. Encryption in Android (Part 1)
  3. Encryption in Android (Part 2)
  4. Encrypting Large Data
  5. Initialization Vector
  6. Key Invalidation
  7. Fingerprint
  8. Confirm Credentials

Those describes the “Secure data in Android” workshop topics. Sample application with full code snippets is available on GitHub.

In previous “Encryption” article we spoke about basics of Cryptography: algorithm types (symmetric, asymmetric), cipher types (stream, block), modes, paddings and key types. This article will show you how encryption works in Android.

Table of Contents

  • Java Cryptography Architecture
  • Android Key Store
  • Sample Project
  • Whats Next
  • Security Tips

Java Cryptography Architecture

Android builds on the Java Cryptography Architecture (JCA), that provides API for digital signatures, certificates, encryption, keys generation and management.

KeyGenerator — provides the public API for generating symmetric cryptographic keys.

KeyPairGenerator — an engine class which is capable of generating a private key and its related public key utilizing the algorithm it was initialized with.

SecretKey — a secret (symmetric) key. The purpose of this interface is to group (and provide type safety for) all secret key interfaces (e.g., SecretKeySpec).

PrivateKey — a private (asymmetric) key. The purpose of this interface is to group (and provide type safety for) all private key interfaces(e.g., RSAPrivateKey).

PublicKey — a public key. This interface contains no methods or constants. It merely serves to group (and provide type safety for) all public key interfaces(e.g., RSAPublicKey).

KeyPair — this class is a simple holder for a key pair (a public key and a private key). It does not enforce any security, and, when initialized, should be treated like a PrivateKey.

SecureRandom — generates cryptographically secure pseudo-random numbers. We will not use it directly in this series, but it is widely used inside of KeyGenerator, KeyPairGenerator components and Keys implementations.

KeyStore — database with a well secured mechanism of data protection, that is used to save, get and remove keys. Requires entrance password and passwords for each of the keys. In other words it is protected file that you need to create, read and update (with provided API).

Certificate — certificate used to validate and save asymmetric keys.

Cipher — provides access to implementations of cryptographic ciphers for encryption, decryption, wrapping, unwrapping and signing.

Provider — defines a set of extensible implementations, independent API’s. Providers are the groups of different Algorithms or their customizations. There are 3d party providers, such as Bouncy Castle and Spongy Castle (android version of Bouncy Castle), as well as providers available out of box, such as cut-down version of Bouncy Castle (we will take a bit deeper look on them, later on, during this article series).

Android Key Store

And in 18 version of Android, AndroidKeyStore was introduced:

The Android Key Store system lets you store cryptographic keys in a container to make it more difficult to extract from the device.

Once keys are in the key store, they can be used for cryptographic operations with the key material remaining non-exportable.

Moreover, it offers facilities to restrict when and how keys can be used, such as requiring user authentication for key use or restricting keys to be used only in certain cryptographic modes.

AndroidKeyStore is a JCA Provider implementation, where:

  • No KeyStore passwords is required (really, at all)
  • Key material never enters the application process
  • Key material may be bound to the secure hardware (Trust Zone)
  • Asymmetric keys are available from 18 +
  • Symmetric keys are available from 23 +

With out it, before Android 18, you would need to create a file somewhere in your local or external device storage, where all of your keys would be kept (as you can understand, it is easy to extract that file). But with AndroidKeyStore you do not need to create anything, system will manage everything for you:

  • If device manufacture supports Trusted Execution Environment(TEE), your keys will be saved there (the most secure option);
  • If device manufacture doesn’t support TEE, keys will be stored in emulated software environment, provided by the system.

In both cases, your keys will be automatically removed from the system after deleting the application. Also keys material is never exposed, even to you (we will see this later on). We will just work with key references, that is passed to KeyStore System Service, where, under the cover, all dirty work with key materials is done .

Sounds cool, right? But as always happens, it is full of surprises.

Sample Project

The best way to demonstrate those API’s in action is to develop sample application, with real cases you can face during your own application development.

Secrets Keeper, Home Screen

Main goal of our sample application is to save user Secrets, locally, and keep them protected using Encryption, Fingerprint and Confirm Credentials API’s.

To use application, user need to create a master password (during sign up process). This password will be used to protect Secrets: to add new, view, edit and delete already created Secrets, user needs to enter master password.

What is Secret ? Anything you want to kept protected: gmail password, credit card pin code, your secret notes that no one should see.

The application itself is already developed and located on GitHub. During this article series we will focus on it’s specific security features implementation (not on it’s user interface). And to get better understanding of what we are doing, lets look on requirements that this app has:

  • Support Android 18 + devices (we want to focus on best available API, but don’t worry, compatibility of lower API versions will be also covered in this article series);
  • Allow user to access application only if Lock Screen is set (the first and very important step of protection, if you want to secure your data — protect your device);
  • Protect user master password with Encryption (we don’t want someone to get users data by just fetching shared preferences file and reading password);
  • Protect user Secrets with Encryption (namely, the same thing as with password);
  • Allow user to access Secrets with Fingerprint (there will be a separate article dedicated to Fingerprint);
  • Add additional Confirm Credentials protection (there will be a separate article dedicated to Confirm Credentials).

Whats Next

In next “Encryption in Android (Part 2)” article from “Secure data in Android” series we will learn:

How to work with key guard, how to create and manage cryptographic keys and how to encrypt and decrypt data in Android.

Security Tips

Set your smartphone to lock after a short idle time, and set it to require authentication for unlocking. If at all possible, use something stronger than a simple-minded four-digit PIN.

Mobile devices are an open gate to our privacy, secrets, and money (mobile banking). Be very careful what apps you choose to install and pay special attention to what permissions each app is requesting. For instance, it doesn’t quite make sense for a weather app to demand access to your photos, does it?

Create very strong and complex passwords and change them often, and never, ever reuse a password on another site or account.

--

--

Android Developer at Temy. Author. Contributor. Love what I do, working hard to become better and, of course, not forgetting to make some fun.