Will,
You are correct. If the signature check fails, the user approval will
still be requested. That is exactly the concept behind
"DangerousOrSignature". It could be better called
"SignatureFirstOrDangerous"
If one wants to declare a permission protection based on signature
only (no end-user approval request ever), then it shall only use the
"signature" protection level.
To answer your question, the "SignatureFirstOrDangerous" protection
level provides more flexibity and ease in the permission approval
process. It has the have major advantage of automatically approving
the required permission, if there is a trust relationship between the
permission requester and provider (based on signature). It could make
a more friendly end-user experience, because the end-user would not be
asked for approval. At the same time, it still provides the
possibility for the end-user to approve or not, if this trust
relationship doesn't exist.
This could be quite powerful in the case of common SW libraries (as
for example ,the Android protected APIs) that are used a lot by many
various applications.
The applications could be pre-approved (meaning signed with the same
signature of the requested permission) or would be simply not pre-
approved.
In the future, I m convinced that some application will emerge as
standard applications for the android platform (to be installed by the
end-user, and not pre-installed in the system image) provided by very
well known software application supplier. These standard applications
could be pre-approved for these multiple common SW libraries (multiple
signature scheme), and so make the approval process seamless, removing
a potential complex permission approval hurdle from the end-user.
The OEM could then decide to get pre-signed or not these common SW
libraries by the pre-approved application SW suppliers. As the common
SW libraries could be part of the system image, then could still be
upgraded by a secure FOTA scheme at further stages of the product life
cyle.
In case of an application that is not pre-approved, it could still
request the use of these common SW libraries
("SignatureFirstOrDangerous"), but the end-user will assess the
security risk (being sufficiently informed) and decide or not to grant
the permission request.
Basically, the "SignatureFirstOrDangerous" protection level may end up
simply replacing the "Dangerous" protection level in the Android
security scheme. Indeed, it is in a way backward compatible. if the
signature check is failing, then the end-user can still be requested
to grant or not.
Of course, such extra flexibility of the permission approval process
(signature based) is improved or is definitely more valid if the
multiple signature level is also supported (as described in the
previous post) by the Android platform.
Guillaume
On Apr 3, 8:40 pm, William Enck <[email protected]> wrote:
> Guillaume,
>
> Since users that currently accept all dangerous permissions are going
> to accept all failed DangerousOrSignature permissions as well, does
> the new protection level really buy us anything?
>
> Thanks,
>
> -Will
>
> On Apr 2, 2009, at 10:22 AM, guillaume leterrier (Teleca Germany) wrote:
>
>
>
>
>
>
>
> > 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 <[email protected]> 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) <
>
> >> [email protected]> 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, "[email protected]" <[email protected]>
> >>> 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
> >> [email protected]
>
> >> 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 -
>
> --
> William Enck
> PhD Candidate
> Department of Computer Science and Engineering
> The Pennsylvania State University
> [email protected] Hide quoted text -
>
> - Show quoted text -
