How to encrypt a Google Firebase Realtime Database

The problem: protecting sensitive user data in Firebase Realtime Database

For a while now I’ve been working on implementing user accounts in the PrayerMate app so that users can sync their private data to the cloud and share it between their different devices. Think of PrayerMate as being like an Evernote equivalent but specifically focussed on recording different prayer needs – some of them ones of a highly personal nature either about yourself or about close friends that you’re praying for.

Ever since Google announced their revamped version of Firebase a year ago I’ve been in love with it as a platform – the Firebase Realtime Database in particular makes authenticating users and syncing their data to the cloud as easy as pie. But there’s one big drawback: anybody with admin credentials for the Firebase project can browse all of that private user data at will. Equally, Google’s infrastructure is pretty rock solid in terms of security (I went to a presentation about it at the recent Google Cloud Next conference in London – and it is seriously cool stuff) but the consequences of a hacker getting hold of all of that user data doesn’t even bear thinking about.

That’s why I’ve been looking for a solution that allows users to still sync all of their data between their devices via Firebase, but whilst preventing me as the developer (or anybody else who somehow got hold of a data dump) from reading that data. At the same time, I wanted to do it in a way that meant a user who lost their phone wasn’t completely locked out of all of their data for all time – even people with just a single device are frequently asking me to implement sync as a backup mechanism.

Thankfully Google’s own infrastructure provides some really cool tools that made solving this surprisingly easy – and since even people within Google / Firebase themselves didn’t seem overly aware of what was on offer, I thought it was worth blogging about my experiences.

Step 1: A cross-platform encryption/decryption solution – RNCryptor

My first day of this project was spent looking for an encryption/decryption library that met the following requirements:

  • Data could be decrypted across both iOS and Android phones
  • Production ready / stable
  • Actively maintained
  • Actually secure
  • Performant (fast encryption / decryption)

Considering the year is 2017 this was a remarkably difficult exercise. Almost every library I came across had huge warnings either on the iOS version or the Android version saying “The library on the other platform uses really insecure defaults which I had to incorporate for compatibility purposes”, or it hadn’t been touched in four years, or it had a gazillion issues logged against it.

I eventually settled on RNCryptor-objc / RNCryptorNative. When I last looked at RNCryptor a few years back the only option on Android was JNCryptor which was ridiculously slow (multiple seconds per operation) and which I now notice is covered in warnings saying “Do not use on Android”.

Step 2: Securely synced encryption keys using Google Cloud KMS

With RNCryptor implemented on both platforms, that just left the little issue of how to actually sync the user’s encryption key between their devices. A naive solution would be to store that key within the Firebase database itself – that would at least prevent me from accidentally reading people’s private data (at least nothing would be stored in plain text) but would still make it trivial for anybody with access to the Firebase data to decrypt anything they wanted to.

At Google Cloud Next I came across the Google Cloud Key Management Service, and could immediately tell there was some potential here. The Google Cloud KMS lets you create encryption keys which can then be used to encrypt and decrypt data. My first assumption was that I’d generate a key for every user, but for PrayerMate’s 25,000 monthly active users that would quickly reach at least $1,500 every single month. After a chat with some of the very helpful Google Developer Advocates I quickly realised that wasn’t what I needed at all – just a single KMS key could be used to encrypt and decrypt a user’s data encryption key (DEK).

In the end what I came up with was to build a super-simple authentication service in the Google App Engine Flexible Environment. When a user first logs in to PrayerMate, the auth service generates them a new DEK which it gives to them, as well as encrypting it in KMS for storage in Firebase. When the user logs in to their second device, the auth service takes the encrypted key from Firebase and again uses KMS to decrypt it for the user to store in their device’s local keychain (where it is again stored in encrypted form).

Importantly, the KMS key belongs to a different Google account to the Firebase database, so no one user (e.g. me) has permission to both read the data AND decrypt it. A hacker would need to compromise both accounts to access the unencrypted data.

Step 3: Authentication of Firebase users via Google Cloud Endpoints

Where things get REALLY cool, however, is with the introduction of Google Cloud Endpoints in to the mix. This is basically a proxy layer that sits between your user and your backend, but which, crucially, understands the concept of Firebase authenticated users and can validate those logins and tell your backend who somebody is.

This means that each time we generate a new DEK for a user we can encrypt it along with their user ID, so that when somebody comes along later requesting to decrypt a particular DEK the backend can verify if it actually belongs to them.

On the whole, the documentation for Google Cloud Endpoints is pretty good, and if you persevere long enough you can probably figure out how to get it working. I got stuck on a couple of points: firstly, I got myself in a muddle about what to put in the endpoints_api_service section of app.yaml and how it related to the host property of openapi.yaml. There are so many different deployment combinations that the Endpoints documentation struggles to make it very clear – but if you are deploying to the flexible app engine you just use the same [PROJECT_ID].appspot.com form in both places, and your endpoints_api_service.config_id is just what you get given when you deploy your proxy configuration using gcloud service-management deploy openapi.yaml (usually something like “2017-01-01r0″).

The second place where I got really stuck for a while is how to actually enable Firebase authentication on the backend. The Endpoints documentation talked about a X-Endpoint-API-UserInfo header but for the life of me I could not get it to be injected at all. Eventually, I discovered the missing instruction from the documentation (and hopefully they’ll soon accept my request to fix that): after you have added your firebase entry to the securityDefinitions section of openapi.yaml you then ALSO need to actually use that security definition by adding a section like this:

security:
  - firebase: []

Update: I have now open-sourced the code for my backend service as firebase-keysafe. Contributions would be welcome if you spot room for improvement.

Fancy working for PrayerMate?
Android Developer Wanted

If solving interesting problems like this sounds like your cup of tea, all in the aid of helping the world to pray more, then you should know that I’m currently on the look out for a full time Android developer – ideally based in London – either on a short-term contract or more permanent. I’m looking for somebody who is fully committed to the aims of a Christian prayer app like PrayerMate and who is able to be more than just a code-monkey following a tightly defined spec but instead is able to partner in helping build the best possible prayer platform to mobilise the Christian church to pray. If that sounds like you then please get in touch!

PrayerMate’s tips for writing prayer updates

Between them, users of the PrayerMate app are now praying for over a million requests every month. Through the PrayerMate Publishing Platform you can publish prayer feeds to keep your supporters updated and engaged in praying for your ministry too – whether you’re a charity, a church or an individual. Many organisations already publish an existing prayer diary or bulletin, and the site provides tools to quickly and easily get those imported into the PrayerMate system. But what if you’re not already in a habit of writing regular prayer requests – what kinds of things make for a good prayer update?

Here are our top tips for writing prayer updates:

1. Write them prayerfully

It’s hard to expect people to be praying for your ministry if you’re not praying for it yourself. When I sit down to write my prayer updates for PrayerMate each month (yes, PrayerMate has its own feed to help you pray for PrayerMate!), I find it really helps me to begin by praying myself. It feels like the right thing to do anyway, to remind myself that this is first and foremost about inviting God to be at work – and in the process, it usually quickly becomes obvious which kinds of issues are in need of prayer, what is causing anxiety and difficulty, and what encouragements there have been to give thanks for.

2. Give thanks

That leads to our second tip: give thanks! Not all prayer updates have to be requests, it’s often helpful to have some updates which are about giving thanks for the ways in which God has been answering previous requests.

3. Think of some general ministry areas / topics

A good means of generating ideas for writing prayer updates can be to start by writing down some general ministry areas and topics for prayer. For example, if you’re a church, you might have a children’s / youth ministry, a work amongst your local community, students, mission partners who you support, and so on. Most charities will have some particular ministry areas, or perhaps regions where they operate. If you can think of five relatively broad topics then you only need to come up with six prayer points for each topic and you’ve got yourself a month’s worth of prayer points.

4. Be specific

Under each topic, you can then write some specific requests. The more vague your prayer points are, the harder you’ll find it to come up with more than one or two. So instead of saying “Pray that the kids will grow in their knowledge of Jesus”, you could single out what the teaching topic will be this week and have a few specific requests related to the various application points. This is also usually much more engaging for the people praying as well, since it helps keeps things fresh as they pray week by week.

5. Be brief

In your desire to be specific, it’s also good to keep things relatively brief. You don’t need to write a long essay for every day of the week. Just a brief line for each prayer request is fine – and will help both you and those praying.

Want to get people praying for your ministry?

Sign up to the PrayerMate Publishing Platform today to help engage your supporters in praying for your ministry.