Secure Persistent Principal

[afandria]

We need to look into how we can secure the persistent principal or how much it needs to be secured. Is isolating it from other apps enough? Is keeping the app data encrypted at rest enough?

Do we need to use a private keystore? (This one will take some work.)

@ultrasaurus @azinman

[joeblew99]

@afraidria

The security at rest is an important use case. I did not know it was know it's a feature request but it's great afaik :)

You can see what SQL cipher does as this does security at rest for sqlite, but with them the key must be in the key store basically.

[ultrasaurus]

@joeblew99 this is specifically about how we store the "principal" (our keys) -- separate from how data is stored in syncbase (which is maybe what you are saying in your reference to SQL cipher). Certainly before a mobile app is released in production, we would want to store keys securely, it's just something that hadn't been implemented yet. We're still at our 0.1.x release so there are a number of open issues.

@afraidria @azinman We'll probably want to look at the Android KeyStore and maybe iOS Keychain services, which I think these are the standard way to tie data to the authenticated user.

This issue is open to remind us to look at this when the high-level API stabilizes, but fixing crashes or bugs which cause the apps not to sync are the focus right now. The core Go code is pretty stable, but the whole mobile layer in iOS and Android, the "High Level API" (HLAPI) is pretty new.

[joeblew99]

@ultrasaurus

I knwo you said your no where near implementing this yet, but for roadmapping, for my project, i need the business data encrypted at rest, NOT just the keys. sql-cipher encrypts the actual business data. Its a mess to work with i might add :), hence why i am playing with syncbase.

the keys normally go into the Cert store as you suggest to @afandria.