[guardian-dev] Sharing encrypted content with other apps

[Natanael]

Den 29 jan 2014 01:03 skrev "Mark Murphy" <mmurphy at commonsware.com>:
>
> On Tue, Jan 28, 2014, at 15:54, Michael Rogers wrote:
> > I've been pondering whether it's possible for an Android app to share
> > encrypted content - for example, an image stored in a SQLCipher
> > database - with another app, without first creating an unencrypted
> > copy of the content on disk.
>
> Create a ContentProvider that implements openFile(), using
> ParcelFileDescriptor and createPipe() to stream your content from heap
> space, based upon your SQLCipher query. So long as the other party needs
> a forward-only stream (i.e., no rewinding), a content:// Uri pointing at
> your provider should work fine. Note that media playback, in particular,
> tends to want rewinding, as I think was discussed on this list last
> year.
>
> Here's a sample:
>
> https://github.com/commonsguy/cw-omnibus/tree/master/ContentProvider/Pipe
>
> In my case, I am reading the data from a file, to keep the sample
> simple, but you could get your data from anything you wanted, including
> an encrypted source.
>
> The catch is that you need to be in position to do the decryption, which
> means that you have the passphrase. If the trigger for wanting to share
> the content is the user doing something in your UI, you can make sure
> that you have the passphrase before calling startActivity() to request
> the other app to do something with your content://, so you will be able
> to decrypt it. This will not work nearly so well if the content can be
> requested at arbitrary points in time, as your process may be gone and
> you may not be in position to get the passphrase. That's the stumbling
> block that I ran into when pondering wrapping IOCipher in my
> StreamProvider (an extension of Google's FileProvider for serving
> content from more sources), and I haven't gotten back around to try to
> deal with this.

Couldn't you share a file specific decryption key via the Intent with the
app that needs to open it? But then it needs to be aware of that the file
is encrypted and use a specific API, unless you put the key in the filename
it's supposed to make a request for when opening it (I don't think that's a
good idea).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140129/ff0c0ead/attachment.html>