> Would someone care to elaborate how the keys to perform all this encryption
> are going to be managed?

> I've been poking around the source code looking at the JCE stuff (mainly
> bouncy castle) and my assumption here is that in order for this to work
> properly we'd need to have a definitive key store. Although seems trivial to
> generate a Java keystore it becomes less apparent how to integrate the
> securing and management of the key store from an end-user perspective.

> I'd assume that the private key on each device would have to be protected and
> integrated with the phone security mechanisms (Unlock Pattern/SIM PIN) in
> order to make any sense or be usable for the end-user. We'd need probably
> need a way to "tie" the key and the keystore to the actual device so it
> cannot simply be copied off the device and replicated (moving  from a
> hardware device to an emulator for example). Ideally using some hardware
> link, maybe leveraging some of the SIM's crypto capabilities (The intent is
> to avoid making this a GSM specific feature but I don`t see how else to
> manage right now).

> Once you generate this secured key, you can then start doing things like
> encrypting packages onto a card and doing signed meta-data manifests.

> I'm struggling with a similar problem right now looking at how to get a
> device specific PGP (or GPG) key installed on a device in order to enable
> secured communications.

> If the above is something that the AOSP team would be interested in as a
> feature I`d definitely be open to attempt taking it on as a project.

> Regards,
> Pat

> -----Original Message-----
> From: android-platform@googlegroups.com
> [mailto:android-platform@googlegroups.com] On Behalf Of Jean-Baptiste Queru
> Sent: October-26-09 1:29 PM
> To: android-platform@googlegroups.com
> Subject: Re: More Applications on SDCARD

> The notion of encrypting per-device auth stuff is pretty interesting,
> though it obviously adds quite an extra level of complexity.

> Keeping the filesystem unencrypted, though, opens quite some cans of
> security worms that might be worth avoiding as a starting point.

> JBQ

> On Mon, Oct 26, 2009 at 9:41 AM, lbcoder <lbco...@gmail.com> wrote:

>> I think I touched on this in the thread starter.

>> i.e., keep any number of per-device configurations within the same
>> sdcard for the possibility of sharing to other devices. If the per-
>> device configuration is encrypted, then upon sdcard insertion, only
>> those apps permitted by that device are runnable. And we can either
>> key-check those apps on insertion, OR run a simple SHA hash of the
>> file. If the hash doesn't match what is stored in the per-device
>> configuration, request authorization refresh. If the per-device
>> configuration doesn't exist, create it and go through the full
>> authorization requests. The user can put a checkmark beside each app
>> they want to authorize.

>> i.e., the sdcard has a "master" packages.xml, and for each device, it
>> has a "deviceid-packages.xml" which is a subset of the master
>> packages.xml for that card.

>> Regarding users not understanding why some apps can't be shared
>> between devices... I think that it is important that they be warned of
>> this. You can give them a LIST of *ALL* of the apps that are installed
>> on the card, and do something along the lines of greying out the
>> "protected" apps. If a user tries to authorize a protected app, give
>> them a warning that says "This app is not authorized. The app
>> developer requires that this app be restricted to the device it was
>> initially installed on". That should make it pretty clear. And since
>> the apk is encrypted using the same key as the deviceid-packages.xml
>> file for the device it was initially installed on, it will be
>> gibberish to any other device, so even if they hacked the
>> authorization dialog, it would still be impossible to run it.

>> On Oct 23, 8:28 am, Jean-Baptiste Queru <j...@android.com> wrote:
>>> Well, as soon as we allow something like that, we can't allow
>>> forward-locked apps on the SD card, and those are likely to be the
>>> largest ones, i.e. the ones that'd benefit most from being installed
>>> there. Maybe that could be worked around by keeping the "protected"
>>> parts of the app on internal storage, and putting the rest on the SD
>>> card. I'm not sure that users would understand why only some of their
>>> apps can be shared between devices.

>>> This opens a lot of other cans of worms: e.g. this'll create
>>> situations where the same app is installed on the internal storage and
>>> on the SD card. This doesn't directly allow to guarantee overall
>>> uniqueness of UIDs on a given device. This creates some nasty issues
>>> of compatibility if developers start to fine-tune individual versions
>>> of their app for individual devices and an SD card is shared between
>>> non-identical devices. This would also require to re-validate all the
>>> permissions of all the SD-card apps whenever that SD-card is mounted
>>> on a device (including at each boot). In general, this would create a
>>> truckload of security issues, since no device can't trust the content
>>> of the SD card.

>>> Like I said, this is something that we should really really really not
>>> try to do in a first version - it'd doom the feature to being so hard
>>> to implement and to have so many subtle issues that I guarantee it'd
>>> delay it much further. Enough users have been vocal enough about this
>>> that I strongly feel that we should aim for something simple that's
>>> more likely to be feasible (because "simple" is already going to be
>>> hard enough).

>>> JBQ

>>> On Thu, Oct 22, 2009 at 11:56 PM, Al Sutton <a...@funkyandroid.com> wrote:

>>> > I've never been a fan of assuming how a user uses their device and not
>>> > including functionality on that basis.

>>> > Personally I can see people temporarily swapping SD cards so they can
>>> > try out other peoples apps on their phone, so I can see the need to
>>> > handle it properly.

>>> > Al.
>>> > --

>>> > * Looking for Android Apps? - Tryhttp://andappstore.com/*

>>> > ======
>>> > Funky Android Limited is registered in England & Wales with the
>>> > company number  6741909.

>>> > The views expressed in this email are those of the author and not
>>> > necessarily those of Funky Android Limited, it's associates, or it's
>>> > subsidiaries.

>>> > On 23 Oct 2009, at 01:05, Eric F wrote:

>>> >>  you buy a Mac Mini you get to
>>> >> choose how big of a disk drive you want. I can't really imagine a
>>> >> situation where I'd want to have different apps on different SD cards
>>> >> and switch between them. Sure in a perfect world it should still work.
>>> >> But if it degrades from the system being able to work smoothly in
>>> >> other areas, I don't think this is a bad thing to give up. Especially
>>> >> if it's possible to A) take the file that represents the encrypted
>>> >> file system and copy it to the computer, and then copy it to a second
>>> >> card. So let's say we bought an 8GB card thinking that would be
>>> >> sufficient. Later we realize we wanted a 16 GB card, we move the file
>>> >> between cards using a computer and then use Android to resize the
>>> >> filesystem to our new choice, preserving our installed apps.

>>> >> I can't see normal users "swapping cards", so that leaves us with
>>> >> power users. I think most power users are hungry for the largest/
>>> >> fastest SD card they can get their hands on. Which means 16 (soon 32)
>>> >> GB cards, how many of those is a user going to need? Many phones are

>>> --
>>> Jean-Baptiste M. "JBQ" Queru
>>> Software Engineer, Android Open-Source Project, Google.

>>> Questions sent directly to me that have no reason for being private
>>> will likely get ignored or forwarded to a public forum with no further
>>> warning.

> --
> Jean-Baptiste M. "JBQ" Queru
> Software Engineer, Android Open-Source Project, Google.

> Questions sent directly to me that have no reason for being private
> will likely get ignored or forwarded to a public forum with no further
> warning.