> 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 to http://developer.android.com/intl/zh-TW/reference/javax/crypto/spec/p...
> ) 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? - Try http://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 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.

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