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