System packages signatures and permission

by guillaume leterrier (Teleca Germany) » Mon, 23 Mar 2009 18:47:06 GMT


Sponsored Links
 Hi,

Running the emulator from sdk version: android-sdk-windows-1.1_r1,

I have extracted using ADB all packages located under

system/app/*.apk

and

system/framework/framework-res.apk

Then using,

jarsigner -verify -verbose -certs *.apk

One can view the certificates used to sign these various packages.

They are all signed with the same certificate parameters.

 X.509, emailaddress=andr...@android.com, CN=Android, OU=Android,
O=Android, L=Mountain View, ST=California, C=US


Does it mean, they are really signed with the same key?  How could I
verify that?

They appear to be signed by Android (Google). I guess that if I
rebuild the Android image for the emulation, it will be always the
same private key used? if yes, this means that this private key should
only be used for development purpose.

For a commercial product, I guess, the OEM shall sign these packages
with its secret private key?


Then, I have extracted the permissions of each packages using

aapt d permissions *.apk

I compared them to the declared permissions provided by "Frameworks
\base\core\res\AndroidManifest.xml"
corresponding to the framework-res.apk ( the android protected API).

None of the framework permissions protected by "signature" or
"signatureOrSystem" are used by any of these application packages.

Why? All the used ones by application packages are basically either
Normal or Dangerous.
All these system applications are already installed by the OEM. So,
the OEM will already authorize these permissions on behalf of the end-
user.

 However, for any new application installed by the end-user, it seems
that a lot of security responsability is handed on the end-user
shoulders?

Isn't it due to the central design choice of not having a CA to
control capability approval of the applications?
 I mean not having a CA and application/capability approval process,
but letting every application developer signing its application
without any approval.

Indeed, if most of the declared framework APIs were protected by
signature, it would force every application
developpers to get their applications signed with the same key (used
to sign the framework packages). In this case, it will be the OEM key
or a common google secret private key. So, we would end-up with a kind
of CA ( OEM or google ). correct?


Guillaume



System packages signatures and permission

by ejx...@email.mot.com » Fri, 27 Mar 2009 21:22:59 GMT


 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.


Sponsored Links


System packages signatures and permission

by guillaume leterrier (Teleca Germany) » Wed, 01 Apr 2009 16:49:24 GMT


 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 !





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






> build directory.



System packages signatures and permission

by guillaume leterrier (Teleca Germany) » Thu, 02 Apr 2009 22:32:47 GMT


 es, 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 ( 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:02pm, Dianne Hackborn <hack...@android.com> wrote:
> - Show quoted text -



System packages signatures and permission

by guillaume leterrier (Teleca Germany) » Mon, 06 Apr 2009 20:37:31 GMT


 ill,

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:40pm, William Enck <e...@cse.psu.edu> wrote:
> - Show quoted text -



System packages signatures and permission

by guillaume leterrier (Teleca Germany) » Wed, 08 Apr 2009 13:46:50 GMT


  understand that Android application security strategy is different
from other OS security scheme and one does not want to violate the
ll apps are created equaltenant.

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
(pprovedor onsidered safeby 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 OST money operationby 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:05am, Dianne Hackborn <hack...@android.com> wrote:
> - Show quoted text -



System packages signatures and permission

by jfr » Mon, 04 May 2009 15:36:57 GMT


 ello Dianne,

Thanks for the active participation in the discussion -- it's always
good to have the knowledgeble parties engaged.


I do understand the philosophy behind not wanting to put everything
behind a closed padlock that no one can get to -- that has hampered
growth in lots of application spaces. However, the various scenarios
that have been laid out that could very easily be exploited for
malicious intent due to this inadequate "trust me, I'm a good guy"
security model should raise serious questions.

There must be some way in which a middle position can be reached. I
don't imagine that it's the intent of OHA or Google to create a
platform rife with the same kind of exploitable scenarios that wreaks
havoc on corporate networks running exploitable desktop operating
systems that don't already have a clear way of establishing and
revoking trust. Other non-locked mobile platforms (BlackBerry, Windows
Mobile) have come up with workable trust systems that make it easy for
developers to build and commercialize apps while protecting both users
on their devices and the networks on which their devices operate. I'm
sure the massive brains behind Android can conceptualize a model that
works for all parties.

The possible impacts of misbehaving applications on customer privacy
and network operations in this scenario are very significant. I know
that security/privacy has often been used as a bugaboo by carriers to
prevent evolution of applications in the mobile space for years, but
there is a correlation between that and the low number of trojans and
viruses on mobile devices on wireless data networks to date.

Android, unlike Linux on PDAs 10 years ago, is not meant to be a
hacker-only platform. It's meant for consumers, the vast majority of
which do not WANT to have to grasp complexities such as shared UIDs,
self-signed certs and what those mean, etc.

-jfr

On Apr 1, 1:02pm, Dianne Hackborn <hack...@android.com> wrote:
> answer them.



Other Threads

1. How to make second DDMS work on the PC which already running a DDMS?

Basically you cannot do that.

DDMS connects to the emulator through adb. adb connects to all running
emulators, and will make them available to the first DDMS.

upon launching DDMS A, it will connect to all available emulators,
making it impossible for a 2nd DDMS/Eclipse to connect to them.

Xav






-- 
Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.

--~--~---------~--~----~------------~-------~--~----~

2. Understanding build.xml in SDK version 1.5 - where are the targets?

<taskdel name="setup" .../> defines a custom Ant task that does the following:

- From the content of 'default.properties' (value is 'target'),
resolve the project Build Target (ie which platform or add-on your
project is compiling against).
- From this resolution, find the path to the target folder (for
example $SDK/platforms/android-1.5/).
- Import the files containing the target and all the build logic (for
example $SDK/platforms/android-1.5/templates/android_rules.xml)
- Setup properties that define paths to things inside the resolved
target folder (android.jar, aapt, dx, etc...)

Xav


---------- Forwarded message ----------
From: brian.schim...@googlemail.com <brian.schim...@googlemail.com>
Date: Mon, May 18, 2009 at 5:41 AM
Subject: [android-developers] Understanding build.xml in SDK version
1.5 - where are the targets?
To: Android Developers <android-developers@googlegroups.com>



Hi there,
I just tried to figure out the build.xml from the SDK 1.5. I used
"android update project" an an existing project and got a very short
build.xml. When I strip out all the comments, this is what's left:

<?xml version="1.0" encoding="UTF-8"?>
<project name="com.webxells.ourproduct" >
  <property file="local.properties"/>
  <property file="build.properties"/>
  <property file="default.properties"/>
  <path id="android.antlibs">
   <pathelement path="${sdk-location}/tools/lib/anttasks.jar" />
   <pathelement path="${sdk-location}/tools/lib/sdklib.jar" />
   <pathelement path="${sdk-location}/tools/lib/
androidprefs.jar" />
   <pathelement path="${sdk-location}/tools/lib/apkbuilder.jar" /
   <pathelement path="${sdk-location}/tools/lib/jarutils.jar" />
 </path>
 <taskdef name="setup" classname="com.android.ant.SetupTask"
classpathref="android.antlibs"/>
 <setup />
</project>

The documentation tells me to call "ant debug" or "ant release". As
far as I know, "debug" and "release" must be the names of targets in
this build.xml, but the build.xml does not contain any target at all.
I would expect to get a message like "Target "debug" does not exist in
the project", but to my big surprise, it works and does something.

Anyway, compilation fails for several reasons. If I knew where the
<javac> task is called, I knew which parameters to add to fix it, but
I can't find it anywhere in this small build.xml. There are many other
things I'd like to customize, but I just don't get where to find them.

thanks for your answers,
Brian




-- 
Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.

--~--~---------~--~----~------------~-------~--~----~

3. Modifying kernel headers in bionic

4. Is there some plan to support USAT (USIM Application Toolkit)

5. Is there some plan to support USAT for 3G

6. Notepad tutorial and the case of the missing setListAdapter() method

7. AChartEngine - a charting library for the Android platform