> And yes, copying the key off of /data will be somewhat trivial for anybody
> who is motivated enough to get an app working on multiple devices when it
> shouldn't unless that key is protected somehow.

> Pat

> -----Original Message-----
> From: android-platform@googlegroups.com

> [mailto:android-platform@googlegroups.com] On Behalf Of Al Sutton
> Sent: October-26-09 3:03 PM
> To: android-platform@googlegroups.com
> Subject: Re: More Applications on SDCARD

> So what would stop someone with root extracting the key and passing it  
> over to someone else, thus making the SD card & key a pair?

> It might be worth encrypting the key with PKCS#5 (password based  
> encryption, which is already present in the build according tohttp://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> escr.html
> ) using the device ID in the OS so that any key copied around won't  
> decrypt on another device without a fair chunk of work.

> 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 26 Oct 2009, at 18:45, Jean-Baptiste Queru wrote:

> > The plan is to store the (randomly-generated) key on /data, with no
> > user intervention - it doesn't need to be stored any more securely
> > than anything that's already on /data, since it protects data that's
> > not any more sensitive than the one on /data.

> > JBQ

> > On Mon, Oct 26, 2009 at 11:40 AM, Patrick Ethier <patr...@secureops.com
> > > wrote:

> >> 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

> ...

> read more »