Enketo now has full support for encryption-enabled forms! This long-requested feature is compatible with other tools in the Open Data Kit ecosystem and of course in particular with ODK Briefcase, the primary tool for decryption.
Why use this
Enketo has always facilitated encryption of data during transport from the browser to the data server (e.g. to Aggregate, Ona, KoBoToolbox) just like any website that uses an “https” web address (note that both Enketo and the data server need to be using https). However, some projects also require sensitive data to be securely encrypted while it is still stored on the device and while it is stored on the data server. This new feature responds to that requirement.
How it works
Encryption takes place as soon as the record is finalized and saved.
A random single-use encryption key is generated by Enketo, and this is used to symmetrically encrypt all data including file uploads such as photos. The form definition includes a public RSA key that is used by Enketo to asymmetrically encrypt the single-use encryption key. The resulting asymmetrically-encrypted symmetric encryption key is passed along with the submission. For those of you interested in the full technical details on the encryption algorithms see this specification.
Once the submission has been received on the data server, it can be decrypted in ODK Briefcase. This can be done by pulling the submissions and using the private RSA key to decrypt the symmetric encryption key that was used to encrypt the data.
The only person that should have access to the private key is the person that is entrusted with decrypting the data.
Auto-saving and saving as draft
For encryption-enabled forms, Enketo will automatically de-activate 2 features that normally exist in offline-enabled webform views: the auto-save feature and the ability to save a record as draft. This is done to avoid storing sensitive data without encryption, because even Enketo will not be able to decrypt the data once it is encrypted.
How to use
To use this feature the XLSForm needs to include a public_key in the settings sheet (and keep the matching private key secret). See the XLSForm specification and ODK documentation for more details. Note that some older tutorials mention an additional need for a submission_url. This can be ignored, as that is actually an independent feature that does not relate to encryption.
XML wizards may be interested in looking at the XForms Specification.
The only known limitation is that encrypting photos, videos, audio and other uploaded files puts a heavy burden on a low-spec device. If the survey includes file uploads, it is therefore required to always test your survey on actual devices that will be used during collection. In addition, you may want to ensure that the uploaded file size is limited. In the future, a feature will be added to facilitate this by automatically transforming the image to a pixel size that can be set in the XLSForm.
Internet Explorer does not support encryption and will just show a helpful warning during load. To work around that lack of support, the best approach is to simply make sure to never use that awful browser for any reason.
During the course of development, a possible bug was discovered in KoBoToolbox that seems to affect some encrypted submissions with multiple uploads per record. Make sure to track this bug and test your form if it sounds like this may apply to your encryption-enabled survey.
At some point it may become worthwhile to start a discussion within the ODK group on a new modern encryption specification that is simpler and faster, provides even better security, and offers an easier out-of-the-box implementation across platforms. There is a straightforward path towards adding a new encryption algorithm without affecting users or compatibility of Briefcase with older encrypted data.
This feature was sponsored by the London School of Hygiene & Tropical Medicine as part of their program to provide LSHTM Open Research Kits to support global health research. Many thanks to LSHTM ORK for funding this important feature!
Also many thanks to the amazing ODK developers Guillermo Gutérrez (ggalmazor) and Hélène Martin (lognaturel) for helping out!