I understand that Android application security strategy is different from other OS security scheme and one does not want to violate the “all apps are created equal“ tenant.
However, it may end up being difficult for all end-users to always take the proper security decisions regarding permission to grant or not. Some end-user may even not want to be involved in such decision, when they want to get a new service or application. Not all end-user will be or would like to become security aware. To some extend, some end-user may simply give-up caring about the security requests and end-up always grant permissions whatever they install, if they are overflowed with security info/request. If all applications are equal and none of them have inherent trust against a specific platform/OEM, then it would be more difficult for the end-user to identify and sort malicious from proper applications („approved“ or „considered safe“ by OEM or operator) at installation time. The application signature is not a guarantee against a fake malicious application if there is no counterpart signature in the platform to be checked. This counterpart signature could be the framework signature (as previously described for the "dangerous" permission), or the Android application installer component itself checking the application signature against an authorized OEM signature list, and automatically handling the permission approvals instead of the end-user when a trust relationship exits. This Android application installer could become a kind of anti-virus check at installation time. Indeed, many malicious fake application (considered as safe in their original signed distributed version) could be maliciously "recreated" with a different signature and distributed. This could become a big open door to spread virus or application with malicious behavior, if the end-user is not careful of the application source. Has a Android platform a way to log which application has actually performed the „COST money operation“ by logging the application signature? So, afterwards, one could analyse the log to assess liabilities. In case of malicious use, the malicious application could then be tracked, even after being uninstalled. On Apr 7, 12:05 am, Dianne Hackborn <[email protected]> wrote: > We won't be changing the framework permissions to use a new > "dangerousOrSignature" permission. There are two major problems with this: > > (1) The signature is supplied by the device manufacturer, meaning that you > need to have a relationship with every manufacturer (or carrier) who you > want to use this facility with, potentially requiring that an app be signed > with a very large number of certificates. > > (2) It seriously violates our "all apps are created equal" tenant. > > On Mon, Apr 6, 2009 at 1:36 AM, guillaume leterrier (Teleca Germany) < > > > > [email protected]> wrote: > > > 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. > > ... > > read more »- Hide quoted text - > > - Show quoted text -
