After reading the documentation on shared UIDs and APK signing, I
concluded that using multiple signatures for an application I am
writing would be a good solution.  First, I'll explain the problem I'm
attempting to solve, and next I'll explain how I imagined multiply
signed APKs would solve it.

I'm writing an application that will allow users/developers to freely
contribute content to.  The contributable content is functionality;
not simply images, sounds, data, or other resources.  Let's say for
example, the content is an implementation of an interface that
contains a controller for an interactive character in a video game.
The users/developers should be able to package this content and
distribute, for money if they wish, on the Android Market, in the same
manner that the application itself was.

By having the application and the content packages use the same
sharedUserId, the Java classes contained in the content packages are
available to be directly used by the application.  However, in order
to be able to install two APKs wishing to use the same sharedUserId,
they must have common signatures.  This could be achieved by sharing
the applications signing key with the contributors, but this has
serious implications, and should not be done.  The logical thing to do
would be to sign the application with a truly private key, in addition
to a key that is publicly available to the contributors of the
application.  The contributors would sign their packages with their
own private key, and the previously mentioned shared key.

This solution, however, does not work in the current implementation.
Or at least I haven't managed to make it work.  From my testing, and
likely soon to be confirmed by code inspection, the APKs can only
share a UID if and only if the sets of signatures are identical across
APKs.  I'm curious, is this truly the case?  If so, is the use case
above not enough to warrant the functionality sought?  Finally, if the
solution presented will not work, may you suggest an alternative that
will?

As an aside, an alternative I was brainstorming involved:
 1) getting the list of all installed packages
 2) checking for the existence of a class (or perhaps meta-data from
the manifest) (or some other suitable convention)
 3) creating a DexClassLoader for the packages that match

I'm not sure of the security of this method; perhaps it's not possible
to use the DexClassLoader for packages for which you don't share
signatures.  Perhaps no security exists at all, in which case I could
perform the signature check myself if I deemed it necessary.

I appreciate any advice.  Thanks in advance!

--
Nate

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