[Android Apps and Games] FFU5y:
I just wanted to add a little to this:

The way it presently works, the PDroid core is effectively already protected by cryptograpic signatures (with caveats; see points 1-3 below). This is achieved by PDroid defining its own custom Android permission, which is required to write settings to the Privacy service a.k.a. PDroid core, and protecting this custom Android permission.

The custom Android permission is added to the list of Android permissions via the AndroidManifest.xml of the app which is installed. In both PDroid Manager, and the PDroid 2.0 App, this permisison is specified as being "signature" protected. This means that only other apps digitally signed using the same cryptographic key as the app which initially defined the permission can have the permission. It is possible for an app to add the permission as a 'normal' permission, rather than one which is signature protected but only if it is the first app to define that permission.

So, in terms of use cases:

1. If you have installed PDroid 2.0 App or PDroid Manager, and no other app had previously defined the new permission used to write to PDroid, only another app signed with the same digital signature as the PDroid 2.0 App or PDroid Manager (whichever you installed) would be able to write settings to the PDroid core.

2. If you (as a user) want multiple apps to be able to write settings to the PDroid core, you need to re-sign both those apps with the same signature. This can be done, and indeed this is what CollegeDev did originally when you had to have both PDroid and PDroidAddon apps installed. This a bit annoying for non-devs, but is possible.

3. If another app (not PDroid 2.0 App or PDroid Manager) was installed prior to both of those apps, it could potentially define the permission required to write to the PDroid core as a 'normal' permission, and thus any other app would be able to request that permission. This would be a bad thing, but only matters if this other app is installed before PDroid 2.0 App or PDroid Manager.

Indeed, it would probably be wise for both these apps to check, on startup, whether they have the relevant permission and whether it is a signature-protected permission. If the app doesn't have the permission (some other app has signature-protected it), or worse - the permission is not signature protected (i.e. some other app has defined it in a very unsafe way) the user should be warned.

Anyway, my point is essentially that the PDroid core is protected from rogue applications making changes, so long as PDroid Manager or PDroid 2.0 App is installed before any other app that defines the relevant permission. Right now, the weakness comes from neither app checking if the permission is already defined or defined in an insecure way. (Actually, PDroid 2.0 App may do the former: PDroid Manager will simply not successfully write settings to the PDroid core if it doesn't have the correct permissions).

Nominating trusted apps

Coming back to wbedard's original comment regarding 'nominating' apps which can change the permissions: one way to handle this would be to create a setting in PDroid called 'administer PDroid', and then use that setting to determine which apps can configure PDroid. The main thing is that you have to have one trusted app - installed as a system app ideally - which you can be certain is not being replaced or faked - which allows you to determine which other apps are trusted to configure PDroid core.

Edit: I need to make clear that I am a huge fan of this idea of having an app that can nominate what other apps are allowed to configure the PDroid core. It would allow users to have multiple PDroid management apps installed at the same time. (Of course, then there is the risk of the apps conflicting with each other, though - e.g. when a new app is installed, getting two notifications; when an app does something getting two pop-up messages).

Also, keep in mind that once an app has root, all bets are off. An app that has root access can modify permissions, it can modify your PDroid core settings database, it can potentially re-sign the PDroid 2.0 App or PDroid Manager app, etc.

(If I've gotten anything wrong here, let me know, but I'm pretty sure I haven't. For details about android permission declaration and 'signature' protection see the android docs for permissions.)

Additional comments on digital signatures

It occurred to me that some people are probably not familiar with the concept of digital signatures, and so the above information may make no sense. From Wikipedia:

So CollegeDev has a cryptographic key, as do I (and anyone else releasing signed APK files). When we package up the APK file for release, we generate a digital signature for that package using the cryptographic key. So if someone receives an APK which is identified as being signed by me, and if this signature is valid (which is determined mathematically by Android), the user can be sure that:

I signed the package (because my cryptographic key will not change, and its identity is included in the signature)

The contents of the package have not changed (because the signature contains a means of verifying the contents of the package).

A digital signature is only as safe as the cryptographic key of the person who signed it (e.g. if I posted my key to XDA, you could never trust that key again, because anyone could use it to sign anything). However, to do that would be stupid.

So, when an Android permission is defined with signature protection by an app, that means that only other apps signed with the same cryptographic key - i.e. from the same APK creator - can have that permission.

How do I know if it is really the right developer's signature?

Good question, and a difficult one. If you already have the app installed (i.e. you installed PDroid 2.0 App and are now installing a later version), then Android will warn you if the signature is not from the same person. Otherwise, you need to decompress the APK file and check the fingerprint from the /META-INF/CERT.RSA - which you have to extract using 'keytool' (see top rated answer) against the known fingerprint of the signer.

You need to check the fingerprints, because anyone can create a certificate with any 'details' - name, address, etc. The fingerprint can't be modified. How do you know the 'correct' fingerprint for someone? Hopefully they have included it in their sig footer, or you have another copy of a package which you are absolutely certain was signed by them so you can compare the fingerprints.

Sorry for the mega-post, but this information is critically important to understanding the security around PDroid Core and the interactions with it.