Actually signatures is the certificate as a binary blob.  This is what the
platform uses to compare .apk certs; you can compare the binary data against
your own values if you want.

On Thu, Sep 23, 2010 at 11:19 AM, Chris Palmer <[email protected]>wrote:

> On Thu, Sep 23, 2010 at 1:40 AM, jelford <[email protected]> wrote:
>
> > Is there a way to check incoming service connections (AIDL/
> > ContentProvider) for the key that signed them (presumably at runtime
> > using a function like android.os.getSigningKey())? Specifically, I
> > would like to check them against a list of "trusted" keys.
>
> I think the closest thing to that is
>
>
> http://developer.android.com/reference/android/content/pm/PackageInfo.html#signatures
>
> but that is wrong --- it's a representation of the signature, not of
> the certificate itself. I don't see a way you get get the certificate
> using public APIs, actually. Maybe I haven't looked hard enough. If I
> have not, someone will correct me.
>
> There is also
>
>
> http://developer.android.com/reference/android/content/pm/PackageManager.html#checkSignatures(java.lang.String
> ,
> java.lang.String)
>
> You could use this to test that the client who sent the incoming
> request was signed by the same signer as another package you trust,
> but I hesitate to recommend it in your situation for two reasons:
>
> 1. Tautology. If you check com.foo.blorg against com.foo.blorg, it'll
> be true but meaningless. Including if the user has installed an
> impostor com.foo.blorg.
>
> 2. You might have no reason to trust that your canonical test package,
> say com.you.whatever, is the true com.you.whatever. If I write a
> package called that, and the user installs mine instead of yours, my
> other apps could then connect to your service.
>
> Maybe you should create a permission, make it not be signature-level
> protected, and just let any app ask for it and then let users decide
> if they want to allow app Foo to have it?
>
> Alternately, you could have all your in-house developers sign their
> apps with the same cert. Certificates are supposed to identify the
> entity that created the code. Perhaps your company is the singular
> entity that creates all your apps? Beware of false granularity.
>
> Of course, beware of false coarseness, too...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Android Security Discussions" group.
> To post to this group, send email to
> [email protected].
> To unsubscribe from this group, send email to
> [email protected]<android-security-discuss%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/android-security-discuss?hl=en.
>
>


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

-- 
You received this message because you are subscribed to the Google Groups 
"Android Security Discussions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/android-security-discuss?hl=en.

Reply via email to