[android-security-discuss] Re: System packages signatures and permissions

[guillaume leterrier (Teleca Germany)]

Yes, I agree that this is not how Android security scheme is designed
(meaning there is no central certificate authority in the scheme).

But, I think it would not be necessary to go for a full centralized
certificate authority scheme (“a certificate that most applications
must be signed with in addition to their own to be able to get most
existing application permissions“)  to extend the current scheme.

I guess, having the multiple signature scheme supported and a new
protection level supported could be sufficient.

Indeed, for example, most of the Android protected APIs (declared in
\frameworks\base\core\res\AndroidManifest.xml) are currently protected
as Dangerous protection level.

It would be interesting to create a new protection level
(DangerousOrSignature) and apply it to all current permissions
protected as Dangerous.

If the developer application (requesting a protected API) has been
also signed with the same key of the protected APIs package, the end-
user would not have to grant manually the requested permissions.

If the application is only signed by the developer, then the user
would be requested to grant or not the permissions (i.e installing or
not the application).


To avoid any unforeseen security side-effects and complexity, it may
be preferable to make a strict distinction between the primary key
used to sign the application, and the subsequent multiple signing keys
(secondary keys).
The secondary keys shall only be used to request signature protected
permissions (permissions declared by other applications signed by
primary keys matching one of the requesting application secondary
keys).
However, the secondary keys shall not be used to grant a permission
(declared by the application itself) requested by other applications.
Only the primary (as in the current scheme) shall be used for this
purpose.
To sum-up, the secondary keys shall only be used to request signed
permissions declared by other applications (based on their primary
keys).


Enabling such multiple signature scheme enables to support
applications that would request signed permissions provided by
different applications signed by different signatures, without forcing
the end-user to decide to grant or not those permissions. This will
also avoid, for achieving the same result, to resign all applications
with a common signature, but only the one requesting the signed
permissions of other applications.

Basically, the DangerousOrSignature protection level may end up simply
replacing the Dangerous protection level in the Android security
scheme.
If the signature check is failing, then the end-user can still be
requested to grant or not.
The only advantage of the current Dangerous protection scheme is to
always request the end-user granting decision whatever the application
signature.

Guillaume


On Apr 1, 7:02 pm, Dianne Hackborn <hack...@android.com> wrote:
> I am not sure what exactly you are looking for, but from your original
> message it sounds like you want to have a certificate that most applications
> must be signed with in addition to their own to be able to get most existing
> application permissions.
>
> If so, we simply do not do that.  Android is an open platform, and we do not
> require that applications be signed by some authority to use standard
> features of the platform.
>
> I could certainly imagine one extending the system to add a new permission
> type where you specify the certificates that can have it, but we won't use
> this in the base platform, because that is not how we do security.
>
> On Wed, Apr 1, 2009 at 7:06 AM, guillaume leterrier (Teleca Germany) <
>
>
>
>
>
> guillaume.leterr...@teleca.com> wrote:
>
> > Well, I do not agree. Indeed, as it was mentioned in an other thread
> > (copied below), the multiple signature scheme is not supported.
> > In my opinion, this is a huge limitation for the platform.
>
> > Basically, this means that an application can declare a permission
> > ( protected by the signature scheme ), but this permission can only be
> > used by an other application with the same signature. So, one can not
> > create a permission ( protected by the signature scheme ) and have 2
> > different applications (signed with 2 different signatures, coming
> > from 2 different developers ) using this permission. Only a dangerous
> > or normal protection allows to do that !
>
> > > 1)I know jar signer support multiple signatures in one jar file. If an
> > > APK file has two valid signatures, does that mean this APK can access
> > > signature level permission provided by both signers?
>
> > In theory, something is done with multiple signatures, but nobody has
> > ever
> > used this so it probably doesn't work.  This also has the side-effect
> > (if it
> > does work) of aliasing the two signatures to the same thing since
> > they
> > presumably come from the same owner, which is likely not what you
> > want.
>
> > So basically, please don't do this. :)
>
> > On Mar 27, 11:14 pm, "ejx...@email.mot.com" <ejx...@gmail.com> wrote:
> > > Android permissions guard activities between applications. From
> > > Security perspective, android frame work is as same as an application.
> > > To use signature level or permission defined by framework, your
> > > application has to be signed using same key.
>
> > > You can define signature level permission in your application as well.
> > > And you can use multiple signing keys to sign your application. Other
> > > app would need to be signed using one of signing keys you used so they
> > > can use permission enforced by your application.
>
> > > Do you agree with me?
>
> > > For T-Mobile G1, HTC generated 4 keys to sign different groups of
> > > APKs. These 4 keys are corresponding to 4 keys in open source:
> > > testkey, media, platform and shared. You can search .bks files under
> > > build directory.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.- Hide quoted text -
>
> - Show quoted text -