Is there any thought to potentially moving the ODK Collect local store to
something like SQL CIPHER? We've used it in one app and it seems pretty
great. I think the benefits of providing stock DB encryption on the phone
would probably be welcomed by a lot of groups.
As one of the devs on SQLCipher, we have enouraged this before. ODK
however also stores its data in a filesystem, which makes for easy
syncing with a desktop. These could be moved to a SQLCipher blob, but
that might cause problems with some workflow.
Based on SQLCipher, we have created a new IOCipher encrypted file
system, that works in Java, as well as being mountable via fuse
filesystem on Linux, and via webdav over https. It is still early, but
we hope it can solve the file side of the ODK Setup.
Still for now, even moving the SQLite/android.database.* code over to
SQLCipher would be a great step. Our SQLCipher codebase is very stable
and works from Android 2.x to 4.x.
+n
···
On 06/11/2012 09:02 PM, Matt Berg wrote: > Is there any thought to potentially moving the ODK Collect local store > to something like SQL CIPHER? We've used it in one app and it seems > pretty great. I think the benefits of providing stock DB encryption on > the phone would probably be welcomed by a lot of groups.ODK Collect 1.x stores all instance data as XML files, and only stores
directory and status information in the SQL databases (grab a SQLite tool
and open forms.db and instances.db to see the type of info stored in them
-- it is nothing particularly useful - no survey responses, for example).
So there is little value in encrypting those databases.
Encrypted forms ( http://opendatakit.org/help/encrypted-forms/ ) are one
solution for encrypting data (once the form is finalized) that we've
decided to release in ODK Collect 1.2.
It is also possible to implement cipher streams around the XML File I/O ( I
did a prototype of this + encrypted forms on this clone:
http://code.google.com/r/mitchellsundt-experimental/source/detail?r=c55e0d34011b1bf79c10824826551156c3e9c514).
The problem is with encryption of media attachments to a form. ODK Collect
uses external apps to do image capture, audio recording, etc. These store
thumbnails of images and audio files in their own data representations for
quick access; ODK Collect then makes and saves a copy for its own use.
Fully protecting all of these media attachments is something we cannot
ensure, because we don't control these 3rd party apps.
And there is also the technical issue of how SD Cards store and reclaim
storage internally. So we decided to not give anyone a false sense of
security about the data stored on the phone. We can guarantee that the
data sent off the phone is encrypted and cannot be reasonably decoded (via
Encrypted Forms). But users requiring secure data capture should expect
that some or all captured data is not secured and should implement
wipe-and-reinstall procedures to periodically clear the SD Card of all data
files, thumbnails and other scraps of data, re-image the phone operating
system, and re-install ODK Collect.
Mitch
···
On Mon, Jun 11, 2012 at 10:11 PM, Nathan of Guardian < nathan@guardianproject.info> wrote:On 06/11/2012 09:02 PM, Matt Berg wrote:
Is there any thought to potentially moving the ODK Collect local store
to something like SQL CIPHER? We've used it in one app and it seems
pretty great. I think the benefits of providing stock DB encryption on
the phone would probably be welcomed by a lot of groups.As one of the devs on SQLCipher, we have enouraged this before. ODK
however also stores its data in a filesystem, which makes for easy
syncing with a desktop. These could be moved to a SQLCipher blob, but
that might cause problems with some workflow.Based on SQLCipher, we have created a new IOCipher encrypted file
system, that works in Java, as well as being mountable via fuse
filesystem on Linux, and via webdav over https. It is still early, but
we hope it can solve the file side of the ODK Setup.https://github.com/guardianproject/iocipher
Still for now, even moving the SQLite/android.database.* code over to
SQLCipher would be a great step. Our SQLCipher codebase is very stable
and works from Android 2.x to 4.x.+n
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com