There have been several Google security projects but this is the first Android-specific security library that’s part of AndroidX. It’s been a long time coming but I for one am happy to see it. AndroidX security is under alpha and so the feature set may yet change, but currently its primary focus is keeping data secure at rest and its use is recommended in the Android Security best practices. Files and data within your applications’ private data directory are protected by system Linux style user permissions. This prevents access from other applications or would be attackers on  non-rooted devices. However it’s still good security practice to encryption your sensitive app data.

To help developers secure their app’s data at rest it offers two utilities:

  • EncryptedSharedPreferences – automatically encrypts keys and values and adheres to the SharedPreference Interface. It’s easy to replace existing SharedPreference usages with this implementation instead. The rest of the article focuses on EncryptedSharedPreferences but many of the points are valid for EncryptedFile.
  • EncryptedFile – allows you to read/write encrypted files by providing custom implementations of FileInputStream and FileOutputStream.

Having used powerful encryption libraries such as javax.security and BouncyCastle – both of which offer the ability to perform secure cryptographic operations but the learning curve and number of customisation options are high. This either puts people off altogether or leads to accidental but critical security mistakes. For example, I accidently used the default Initiation Vector which turned out to be a static 0 byte array – this is bad from a security point of view.  I like the fact AndroidX has a very simple API and defaults to a recommended* AES GCM 256bit based encryption algorithm.

* A note on my recommendations: this is based on my understanding at the time of publishing but please do your own research to confirm this library and encryption algorithm are indeed safe and secure.

How to include in your project?

As with any of the AndroidX packages just include this dependency in your build.gradle file.

implementation "androidx.security:security-crypto:1.0.0-alpha02"

Note: This is only available within the AndroidX library suite and as such, there is no backports that are compatible with the old Android Support libraries.

Example using `EncryptedSharedPreferences`

Let’s dig into the EncryptedSharedPreferences part of library and storing arbitrary data on or about users is a common task for many applications.

 

MasterKeys is a helper class that generates your encryption keys and stores them in the Android Keystore.

val keyGenParameterSpec = MasterKeys.AES256_GCM_SPEC

val masterKeyAlias = MasterKeys.getOrCreate(keyGenParameterSpec)

Note: if you require the strongest security using a hardware-backed Keystore you can use your own KeyGenParameterSpec and alter the options via the KeyGenParameterSpec.Builder.

 

Create EncryptedSharedPreferences like this:

val sharedPrefs = EncryptedSharedPreferences

.create(

FILENAME,

masterKeyAlias,

context,

EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,

EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM)

You can interact with SharedPreferences as normal – the encryption and decryption happens transparently to you. The masterKeyAlias was created in the previous step and is a String used to identify the key in the Android Keystore.

 

Under the hood

Here’s what a EncryptedSharedPreferences file looks like. This was extracted from one of my sample apps using Facebook’s Stetho library, although you could just as easily use ADB or Device File Explorer within Android Studio to pull the SharedPreferences XML file from your app’s private data directory.

As noted in the key management section of the security best practises, AndroidX Security uses a 2-part system for key management.

A keyset that contains one or more keys to encrypt a file or shared preferences data. The keyset itself is stored in SharedPreferences.

A master key that encrypts all keysets. This key is stored using the Android Keystore system.

EncryptedSharedPreferences uses two different encryption schemes. The one for the keys is deterministic, by that I mean any key (i.e “access_token”) will render to the same ciphertext every time whereas values are encrypted with a non-deterministic schema. Non-deterministic uses random data with the encryption algorithm for the same text it will generate a different ciphertext. This improved security wouldn’t work for the SharedPreference keys as they need to be consistent in order to look up the values in the HashMap.

Considerations

The library is relatively new and is in Alpha02. It seems robust in my testing, as have other alpha AndroidX libraries. But it’s certainly a risk worth considering before implementing in production.

To use this library you’ll need to set your minSkdVersion to 23 (Android 6.0). This is mainly due to dependency on the Google encryption library Tink which requires SDK23 for Android Keystore operations. If this security library alone isn’t enough to increase your applications minSDK then you could opt to support AndroidX Security library for SDK 23+ and default to the regular File or SharedPreferences for users on older devices. Why reduce security of all of your users just to support old devices?

You won’t be able to use Preference Activity/Fragment with XML to link directly to the SharedPreference data so before jumping in and encrypting all the things, consider that you’re unlikely to need to encrypt all your app’s shared preferences. I’d recommend splitting out just sensitive data such as OAuth access and refresh tokens, email or any other personally identifiable data.

It’s also worth thinking about the recovery strategy in case the decrypt fails. The use case I’ve often used this type of encryption for is caching server-side data for offline access. If the key fails to be retrieved or for whatever reason, the decrypt fails. The worst case is asking the user to re-authenticate and re-download the data when they next have connectivity. Of course, this recovery strategy of starting again relies on the data being on the server and although it’s not a great user experience, I don’t see it as the end of the world (i.e 1-star rating 😉 ). However, that’s not the case for an offline-only password manager where there would be no recovery option. So remember to catch the SecurityException and handle according to your specific app/use case.

Should you use it?

“It depends” – it’s very much down to your application’s use-cases and the type of data you’re storing. For me, it’s a yes. It’s better than using nothing and from a developer point of view, it’s easy to implement and helps keep the app and user data safer. While it doesn’t offer 100% security (spoiler alert: nothing does) it will be more laborious and increase the required skill level for an attacker to successfully extract data.

If you’re already using one of the many open-source encrypted Shared Preferences libraries then I think its would be a good switch. Certainly, if you’re using SecurePreferences, a library I developed several years back, I’d urge you to migrate to AndroidX Security at this point. As mentioned earlier, the API is simpler, uses AES GCM 256 and is supported by Google rather than being neglected by me ;).

Special thanks to Niall Scott, Mat Rollings and Mez Pahlan for help editing and typo fixing.

If you’re using AndroidX security in development or production I’m keen to hear you’ve experiences.

Moving apps

TL;DR This article fills in some of the gaps in the official docs and add rationale to why you should consider moving your app to a non-human Google account.

Google offers the ability to move/transfer one of many apps from one Google account to another. But before you transfer highly recommend reading the official docs on how to transfer apps to a different developer account here.

Why transfer?

Are you using your personal Google account for apps?

If your app(s) are associated with your personal Google account you run the risk of having your access to Gmail, Google Photos, Drive blocked if Google Play account is suspended due to a breach of Play content policy. The thought of losing access to my emails, family photos is a very frightening prospect. You might think you’ll never be in breach and maybe you’re right? but remember the Play content policy is frequently updated and you have to ask yourself how closely you read the updates. I ran into policy breaches a few times and none of the apps I’ve released are particularly risky. The first app that I wrote to get my first Android job was a wallpaper changer based geotagged Flickr photos and user’s location. It was pulled due to copyright infringement (I mistakenly used Flickr’s logo and name). So certainly worth considering moving them to seperate Google account.

 

What if the account owner leaves your organisation?

Recently at work the first Android developer left for greener pastures. I mention first because he was only one in the Android team and registered his work Google account as the Google Play Developer owner which I’m sure happens a lot. When he left the company a few weeks ago his Google account was deactivated as you’d expect. However, because that account was the owner on Google Play we *lost* all access to Google Play console 😱😱😱. Thankfully we were able to restore their Google account which restored our access. But keeping an ex-employee’s account active just for this would be less than ideal.

Continue reading

Slides and links(below) from my “What’s NNNNNNNNew in Android Security” talk at Droidcon London. The video via SkillsMatter is here.

Resources:

Training and Developer Docs

Would you like me to speak at your conference or meetup? If so please get in contact.

Any questions, please drop me an email or tweet.

 

Scott MCEI had a great time at MCE conference in Warsaw, Poland in April. I’d recommend MCE as a mobile conference I attended both Android and iOS talks and there were all high quality. Also all the people I met were very friendly and spoke great english. I was introduced to Polish vodka and some tasty polish food. Thanks to the organisers for inviting me and I hope to attend again.

In this presentation I share a story of a recent Android app I developed where app security wasn’t prioritised and how I still provided a minimal level of security to protect the app’s users and developer reputation.

For those wondering why my t-shirt has a mantis shrimp on it? check out this awesome oatmeal comic.

Last week I attended the first Blackhat mobile security summit in London. It was a great chance for us to learn from security specialists.

I co-wrote this article (deadlink)  to highlights some of our favourite and key takeaways.

  • New Android Security Rewards Program
  • State of malware on Android/mobile
  • Samsung / SwiftKey Zip Traversal Hack
  • SSL validation (or lack of) still one of most common app vulns
  • “erase everything” = not everything?
  • Windows phone 8 exploits and security faux pas

I have released a new open source library to wrap a Google Play services API called SafetyNet, which has been completely eclipsed by the recent Google IO and WWDC coverage 😉 safetynet_framed

Here’s a blog post that explains a bit about what is it and why and here’s the code on github.

I’ve also released the Sample app on the Google Play store so you can run the Safety Net test on your own device.

 

Another blog on the Intohand blog, this time “How to publish your open source library to Maven central”

Have you created a great (or at least useful) Java/Android open source project that you want to enable other developers usmavene in their projects easily? have you wondered how to publish your library to Maven central? then this is the article for you!

http://intohand.com/blog/post/how-to-publish-your-open-source-library-to-maven-central

This is an extract for a blog post I wrote for intohand. Read the full article here.

Whilst emulators provide a function, nothing beats testing on real hardware. As a developer however unless you’re near a test wall of phones, have a very large bag or lots of colleagues/friends who are all running different software versions it can be a pain. It would be ideal if you could have a single phone that acted as a Swiss Army knife.

At the end of this article using a tool called MultiRom you’ll have a Nexus 4 with the option of booting into various versions of Android.

mulitboot-image09

After last nights SWUX meetup I figured I’d share some more links on Google’s Material design that I’ve found since the last meetup I attended.

Articles:googledesign

  • An exploration in Material Design by Arthur Bodolec @ Feed.ly  – good information about the Z order and a nicely polished example.
  • We Are Living In A Material World And I Am A Material Girl – Trello – Great article that shows before and after material, and most interesting thing for me was how Trello got rid of the navigation drawer.
  • Instagram with Material Design concept by Miroslaw Stanek – some great code samples.

Examples of Material apps – there are several of these kind of sights two of the best are:

  • pttrns.com – has a new beta section showing material/lollipop Android apps. What’s great is you can filter by the type of screen you’re looking for.
  • materialup – showcases material apps and websites but also material concepts and animations

Tools

  • Material Palette, pick two of the material colours and this site will generate palette of 8 colours ready to drop in to your app/project
  • Keyline Pushing – Android  app – when running draws an keyline grid on top of apps, useful for designer/developers to validate an app is ahearence to material’s metrics and keyline spec