TF5 & IOS Encryption Question

oh, and it doesn’t matter what order you do things in.

Make a backup of your .tapforms document before you encrypt just for safe keeping.

You are correct. I asked a similar question and the encryption you key set in TF5 is just for local encryption only.

The data is transmitted to Cloudant in an encrypted format of course using standard SSL (https) encrypted data connections. What happens to it after then is up to IBM. Remember, IBM is a huge company. They’ve been around as long as Apple and I’m sure that data security is of utmost importance to them.

I did contact Cloudant and asked them the question and this is what I was told:

Greg H @cloudant.com
Apr 25
Hey Brendan,

Data on the multi tenant service is also encrypted.

But then I got a response from a general support query that said:

Cloudant Support support@cloudant.com
Apr 25
Hi Brendan,
On our Multi-tenant clusters data is not encrypted at rest. Encryption at rest is available on Dedicated clusters.

Regards,
Josh Stonefield – Cloudant Support

So I don’t really know what is true and what is not true.

What is sent in clear text and what is not (through SSL, but that is only for the transfer)? Ie, if the form names and field names are sent in cleartext, but the record data is sent encrypted (after all, the database is encrypted locally) then that should be fine. The real issue (for me) if the record data was not sent in encrypted format. (I must admit it would be difficult for me to see why that would be the case.)

I tried to have a look at the Cloudant dashboard where one can “look” into the databases but, well…, it is really not clear what one has to look at. It is using, afaik, MongoDB, i.e., the database is a bunch of JSON objects. I looked at some top level records, most of the values were clearly encoded/encrypted data, although I did find the names of my forms within the database in clear text form. But I could not find a way to reveal any real record data.

It would really be important to find information about the exact state of encryption on the Cloudant server. Again, if the records themselves are there in clear text, even if behind the Cloudant firewall, that is way too dangerous. If this is indeed the case, it is reason for me not to use TP at all and get my money back. (I could never get the nearby sync working, although the Cloudant sync works like charm). But if the records themselves are sent to IBM encrypted, then I do not see any danger.

Tony, no need to shout :)

Tap Forms transmits the data using SSL, which is an encrypted communication channel. The data however, as was observed in a response above from Cloudant appears to not be encrypted on the actual Cloudant server. I don’t honestly know why this is the case since it’s not beyond their technology to encrypt the database.

It’s not a MongoDB database by the way, it’s a CouchDB database. Yes, all the documents are stored in JSON format.

With Nearby sync, the data is encrypted during transit also using an SSL connection and then of course since you can individually encrypt the local database, then your data will be most secured that way.

I’ll contact Cloudant to see if there’s any reason why they’re not encrypting their data at rest. As I mentioned before, I got 2 conflicting responses from them.

Remember you can also have multiple database documents in Tap Forms 5. Some that sync over Nearby and some that sync via Cloudant.

You can also easily move your private data to a new document by using the Export and Import Tap Forms Archive commands.

Thanks Brendan for clarifying this with IBM. It is obviously an important issue.

I must say I would be very surprised if IBM did not encrypt the data, or if the user would not have such an option somewhere. As you said in an earlier reply, IBM is an older company than, eg, Apple; one of the statements of Apple is that, afaik, the data is encrypted in such a way, that data on iCloud cannot be decrypted by them even if they wanted to. This day and age IBM should provide a similar option… Anyway.

If the response of IBM is negative, is it a major change in TF to encrypt the record content before sent to Cloudant? Ie, that only encrypted data would be stored on their servers? Or at least offer that as an option for a TF Form? After all, it is perfectly possible for a specific form that one would want to encrypt only 1-2 fields, not the whole thing (a bit like Bento does).

(I did not get the nearby sync working at all, although I followed, with a brand new database, what is in the description. I got, at first setup, a reply on some system error on both my iPhone and my iPad, and none of the sync works. Cloudant is my only option.)

I just sent this email off to the Canadian sales rep I had been communicating with over the past few months:

I’ve been getting questions from my customers about how secure their data is on IBM’s Cloudant servers.

Can you clarify or help me to understand what security precautions IBM has for all the customer data that’s stored on your servers?

I once asked Greg H about it and he told me the data was encrypted, but asking the same question of support@cloudant.com tells me that the data is NOT encrypted at rest. What is IBM doing to prevent anyone from getting access to all that data?

My customers have also sent messages to Cloudant Support and they’re being told that the multi-tenant servers do not encrypt their data.

In this day and age of needing high security on any cloud service, how can this be? I didn’t think that was possible for a big company like IBM to provide a cloud service that didn’t provide a secure place for their customer’s data to reside. Am I being misinformed here?

Is there a way for the user to enable encryption of their databases in their Cloudant dashboard?

The reply I’ve received so far was just a forward to another rep asking to confirm things.

Tap Forms already provides encryption on the local device storage. I’m going to ask Couchbase to see if there’s a way I can hook into the replication engine to see if I can pre-encrypt certain data before it’s sent to Cloudant and then unencrypted it on the other side. You would have to setup a sync password that’s identical on all devices in order for that to work of course. I don’t want to have to encrypt the data twice on the local device though.

FYI, I’ve managed to write an encryption routine which will encrypt the values stored in a record during the upload to Cloudant and decrypt them when downloading to the devices. So I’m making progress. I may not be able to encrypt the attachments though because the amount of memory required to do that might be too large for this specific technique, especially on the iOS devices.

So here’s another concern I have about this.

What password do I use to encrypt the data? Right now for my testing I’m just using the “Sync Password” available on the Nearby Sync settings screen. I was thinking that I could put that button also on the Cloud Sync settings screen. It could be the same password used for Nearby sync. The Nearby sync password is used just for authentication of the connection between devices.

I was also thinking that I could just simply use the user’s Cloudant login password as the key for encrypting the data stored on the server. OR I could use the local encryption key used when encrypting the database.

The problem is with any of these approaches, if you were to change the key on the local device, you would have no choice but to delete the database on Cloudant and start over the sync again so that the data in Cloudant could be encrypted using the new key. But now I have to tell people somewhere that this is what has to happen. If they don’t do this, sync will not function anymore and I’ll get support requests asking why. It just complicates things.

But I did just receive a response from someone at Cloudant who said this:

We wont offer encryption for any of the old Multi-tenant clusters. However, in a couple of weeks we will be offering a couple of new multi-tenant plans that will include encryption at rest as a default.

I don’t have any of the details, but they said they’d let me know when they could. It would be great if I didn’t have to worry about this because it opens up a whole new avenue for hurt and confusion. But I want to do what’s best for the customer of course, so that’s why I’ve been working on this.