Objectbox-java: Support for secure private data storage

[pakoito]

Allow configuring the proprietary serialization format to include a layer of security.

Suggestions:

• Full document encryption
• Obfuscate fields via @annotation

[greenrobot]

Didn't get the "Obfuscate fields via @ annotation" part - can you give an example? Thanks.

[pakoito]

This is just a guess because there's no open specification of the format the data is stored on, but could the data stored possibly be read using any binary editor?

If so I'd suggest the possibility of mangling, obfuscating, or doing some kind of reversible operation before storing some fields that could be sensitive, like emails or addresses, so at least they're not plainly searchable with a tool.

[greenrobot]

Ah, you want to encrypt only partially, interesting idea. Not sure how indexing should handle those however. For example you could have a "greater than X" query. Here, an index is only useful if it stores plain values because the order changes once you encrypt.

[pakoito]

I'd solve that with documentation, if you use partial encryption it'd be understandable such fields could not used as indexes.

[bigntallmike]

As to encrypting individual fields:
@EncryptedField
String CCNumber;
results in CCNumber's data being stored encrypted in the back-end and not being searchable.

Now as far as that goes, it can be implemented with getters and setters and storing the encrypted data in something like a Byte array variable instead.

[adoubleu]

Are there any plans for encryption support? Could you provide a schedule for the feature? We have sensible data on our product. Encryption is a MUST have feature, so we might switch to a SQLCipher compatible db if the objectbox encryption-support is far from being released.

Thank you. Best regards from Berlin,

Adrian

[adoubleu]

Do you have any plans to support DB encryption? Would you please provide a timeframe?

Thank you.

[greenrobot]

Wanted to start off some discussion about implementation:
libsodium probably would be a good starting point. My last time doing encryption was a combo of ECC, AES with IV and HMAC. libsodium rather recommends ChaCha20-Poly1305 (see also RFC 7905), which is also significantly faster (in software).

Any thoughts on that?

In principle, I am thinking to encrypt only object data, not the entire DB structure (b-trees and such). This is not only much simpler to implement but also the more better performing solution. On the down side, it would allow an attacker to snoop into the b-tree structure and see plain IDs and object counts. Also indexed properties would be revealed, which could somewhat be mitigated by using hash indexes (since 2.0). My hope is that it seldom makes sense to index secure information like passwords and the likes.

Any objections/thougths/confirmations here?

Links:
https://gist.github.com/atoponce/07d8d4c833873be2f68c34f9afc5a78a
https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html

[worldsnas]

I have asked around a little and it seems like ECC, AES and Argon2(instead of HMAC) is the good options.
I can do more searching in a few days and post if anything changes.

ps:eagerly waiting for this feature

[davidhowe]

So in lieu of no official database encryption support, we've gone the route of field encryption using the property converters. We've implemented AES-256 encryption on String fields. Thus far performance tests show the following:
No encryption, 1000 objects (13 fields / object) write ~ 2740ms
Encrypted, 1000 objects (13 fields, 6 encrypted) write ~ 6434ms
No encryption, 1000 objects (13 fields / object) read ~ 58ms
Encrypted, 1000 objects (13 fields, 6 encrypted) read ~ 70ms

Checkout this handy AES lib: https://github.com/scottyab/AESCrypt-Android

An example of the property converter class

class EncryptionConverter : PropertyConverter<String, String> {

    override fun convertToDatabaseValue(entityProperty: String): String {
        return AESUtil.encrypt("YOUR_SUPER_SECURE_KEY" , entityProperty)
    }

    override fun convertToEntityProperty(databaseValue: String?): String {
        return AESUtil.decrypt("YOUR_SUPER_SECURE_KEY" , databaseValue)
    }
}

Your field in entity class would look something like this

@Convert(converter = EncryptionConverter::class, dbType = String::class)
    var username : String = ""

Also remember, with field encryption you're giving up partial field lookup capability

[greenrobot]

@davidhowe Thanks for sharing this.
Quick side question: how are you writing objects? Do you e.g. use put(objectList) passing all objects in at once?

[davidhowe]

@greenrobot Good question. I was running it in a loop adding one at a time. (Inefficient!)
Did another test writing same 1000 entries as above comparing loop vs put(objectList)
Results as follows:
Encryption
Loop - 7667ms
put(objectList) - 789ms

No encryption
Loop - 5950ms
put(objectList) - 101ms

[umeshNova]

Can't we encrypt the db file with file encryption in jetPack? No doubt this will solve specific to android. Please refer https://blog.mindorks.com/how-to-encrypt-data-safely-on-device-and-use-the-androidkeystore.