Add end-to-end encryption/zero-access encryption

[raph]

What is the general goal of the feature?
To provide enhanced security and privacy to projects handling sensitive data

What are the most likely user stories for how and when this would be used by someone on your team?
Organizations who work on sensitive data (gender-based violence, human rights violations, criminal proceedings, etc) would have access to a data-collection system where even the system administrators cannot access any of the data. Only authorized users (project admins) can create and view forms, read the data collected, see and manage users. The current encryption scheme in KoBo falls short for several reasons:

1. It is complex and inaccessible to the average user

2. Only the data is encrypted—forms and users, which can in themselves be very sensitive, remain in the clear

3. It renders the data analysis and reporting features of KoBo useless

Can you sketch out graphically how you think this should look/work in practice?
There would be no visual difference to the way the data collection process works

What can you contribute to making this feature a reality?
Feedback, testing

[tinok]

@raph My understanding of your suggestion is that this approach should fulfill three requirements:

1. Users should be able to use the tools on kf.kobotoolbox.org/kobo.humanitarianresponse.info (map, table, report, export) even if the data was encrypted at the moment of data collection. An authorized user should be able to decrypt data.
2. The choice to encrypt data should be an easy setting for users to enable (rather than generating private/public keys and adding the public key to the XLSForm settings sheet).
3. The form and other settings on the mobile device should be encrypted as well.

#1:

• The current method would work if the user somehow uploaded their private key to the serve to decrypt data (or if it is done client-side somehow, not sure this is possible yet - @magicznyleszek?). Advantage: Server-side decryption would give you full availability of features. Downside: If the server is compromised, so would be your private key–and your decrypted data in the decrypted state.
• A keyphrase-based decryption is another option. Advantage: he server never sees decrypted data nor has access to the decryption key. Downside: Not as secure. This would require significant (?) changes to how Collect and Enketo encrypt at the moment.

#2: If we stick with public/private keys we could work on making the key generation and integration with KoBo easier (e.g. a UI field to specify your public key once for all of the user’s forms; an API request to generate a new key pair, etc.). If we go with the passphrase route, Enketo and Collect this could have a setting (for all forms? form specific?) to enable/disable encryption.

#3 is a separate issue. Encrypting the entire mobile device is already default for iOS and most Android systems, so technically this is done as long as the user’s device password is secure. Users forced to give up their device password would equally likely give up their Collect password (if there was one), so I’m not sure if this is useful. The advantage with current public/private key encryption is decryption is impossible even under duress.

[raph]

Thanks for the follow up @tinok!

@tinok

My understanding of your suggestion is that this approach should fulfill three requirements:

1. Users should be able to use the tools on kf.kobotoolbox.org/kobo.humanitarianresponse.info (map, table, report, export) even if the data was encrypted at the moment of data collection. An authorized user should be able to decrypt data.
2. The choice to encrypt data should be an easy setting for users to enable (rather than generating private/public keys and adding the public key to the XLSForm settings sheet).

Yes that is accurate.

@tinok

3. The form and other settings on the mobile device should be encrypted as well.

No that is not necessary. I believe the number of users who need on-device encryption (on top of Android system encryption) is small compared to those who need more general data privacy safeguards (and end-to-end encryption) and our ODK-compliant client Tella already has this feature for those users who need it.

@tinok

#1:

• The current method would work if the user somehow uploaded their private key to the serve to decrypt data (or if it is done client-side somehow, not sure this is possible yet - @magicznyleszek?). Advantage: Server-side decryption would give you full availability of features. Downside: If the server is compromised, so would be your private key–and your decrypted data in the decrypted state.

I believe the security downside is too great and wouldn’t advise for this solution.

@tinok

• A keyphrase-based decryption is another option. Advantage: he server never sees decrypted data nor has access to the decryption key. Downside: Not as secure. This would require significant (?) changes to how Collect and Enketo encrypt at the moment.

This seems like the most sensible solution. As you mentioned, this is not as secure but the usability gains would be enormous. Ideally, KoBo would provide three options to admins managing the server:

• unencrypted forms and data repository (the current default set up)
• unencrypted forms and encrypted data, which can only be decrypted once downloaded, with the admin’s private key never leaving their local computer storage
• encrypted forms and encrypted data, both of which are decrypted in the browser using a passphrase or other methods (mnemonics, etc).