To use all the neat features from the microG project, which allows you to use all features of your Android smartphone without those shitty, proprietary battery-consuming Google blobs, your system is required to support signature spoofing. Currently only very few custom ROMs have built-in support for this feature, luckily you can use Xposed or a patching tool to add the feature to the systems that don’t have it.

But: What is all this about? Is signature spoofing a problem when not using microG? Will it influence my security?

About signature spoofing

On Android, all applications are signed (usually using SHA1 with RSA). The certificate/key-combinations used to sign apps are self-signed. This means there is no PKI / certificate authority to verify a key to be owned by a person/company/entity. Thus everyone can come up with a key that has a equally valid Google certificate as keys used by Google to publish their apps.

However, on Android signatures are not designed to serve the purpose of verifying ownership/source of a package. Signatures are used to verify integrity and to ensure same package author when updating apps. The second one is important, to verify that only one the author has access to the private storage of an app. A different author is not able to sign an app using the same key, because he does not have access to it, and thus can not provide an update to an application that will be granted access to the app private storage. For example, the Signal app provided by OpenWhisperSystems is signed by a key not available to third-parties and thus Signal can store chat history in the private app storage and don’t need to fear that a rogue update can access this data. This means that signatures are important to ensure the secrecy of the private app storage and thus is an essential part of the Android package managements security system.

Signature spoofing allows applications to behave like being signed by a third party. This means that whenever one application asks the operating system for the certificate used to sign an installed package and that package uses signature spoofing, instead of the certificate attached to the app, a spoofed certificate is returned. This certificate has to be announced in the AndroidManifest.xml and the app is required to request the android.permission.FAKE_SIGNATURE permission. This means that it is not only easy to detect that an application uses signature spoofing, the user also has to give its consent – before Android 6, this was done during installation time, since then the consent is even more explicit in a dedicated pop-up, and the user can decide not to grant the permission.

Of course only very few developers ever ask for the certificate used to sign an application. There are numerous reasons for that:

• In most cases you only want to verify, that an app is signed with the same key as yours (e.g. the apps are from the same author). For this case, the package manager has a method checkSignatures which compares the certificates of two packages. Thus the app author is not required to mess with byte arrays returned when requesting the certificate – and verifying the author name of a certificate is completely useless as described above.
• If you want to use any kind of security model, you are much more likely to introduce a custom permission. On Android every app can declare a new permission and decide which apps will be granted this permission. One option here is to restrict by signature, or you can also require explicit user consent. This again is a lot easier than working with certificates, even more flexible and can be used to allow third-parties to integrate with your app (on users decision). Nice!
• Directly working with certificates is not considered a security feature and is not listed on the security tips article in the documentation, whereas the proper use of permissions is.
• When using the package managers GET_SIGNATURES feature to directly access the certificate, the android lint tool (which is usually used during the compilation process) will print a high priority warning, as improper use of this feature can be a security risk and the proper use is rather complicated. So complicated, that Google themselves did it wrong once, resulting in a major Android security vulnerability (sometimes referred to as the Fake ID vulnerability).

So why does microG require signature spoofing?

Now that we know, that only very few use direct access to certificate, you might wonder why microG needs it for certain features. Well the fact is that although most developers don’t even now about it, their apps actually do direct certificate access. This is due to how Google Play Services works:

Applications that use Google Play Services use the Play Services client library. This library is directly embedded into the application, is delivered as part of it and finally runs in the security context of that app. And this library actually uses direct certificate access to ensure that the Play Services app installed on the device is singed by a specific private key. It also verifies that the Play Store is installed (and signed using the same key), although it is not required for Play Services to run. This is the reason for the development of the microG FakeStore app.

There is one other popular use case I’d like to stress: DRM. Some developers use direct certificate access to verify that the application itself is signed by them. The reason for this is simple: If you modify an application you need to sign it (the previous signature is broken, if your system is not vulnerable to the “Android Master Key” vulnerability). As you don’t have the private key of the original developer you will not be able to create a valid signature that has the same certificate. This means you can’t modify the application without the original developer knowing about it. (Well, you could modify the checking code itself, …). With signature spoofing you can easily bypass these restrictions – as long as the app does not contain code to detect signature spoofing.

Security implications: Facts and myths

If you want to have a short answer to the question “Does it influence my security?”, here it is: Yes. Details?

• It should be noted that there might be “real” use-cases of certificate access. For these use-cases, consider that signature spoofing is protected by a permission that requires explicit consent (and is optional on Android 6). The patch included in OmniROM 5.1 additionally requires to activate the feature in the developer settings, decreasing the risk of unintentional bad use. As your very private data on your phone (messages, call logs, contact details) is at the same protection level, this is nothing really to fear about, but still worth to mention.
• The whole source code of the Android Open Source Project (the core operating system including package manager, contact storage, etc.) does not contain any relevant use of GET_SIGNATURES and as such is not influenced at all.
• When imitating Play Services (as done by microG), an application might get access to some app details that are not intended to be sent to other apps. A rogue app that imitates Play Services thus can access this data. Most of this data however is already accessible through other means, for example notifications for Android Wear devices might be send to that app, but are also available using the system notification API. Additionally note, that that’s exactly the data sent to Google if you were using Google Play Service. If you have the Google Play Services or microG installed, it is no longer possible to imitate Play Services, so this risk is mitigated.
• You don’t really care about accidentally breaking DRM systems, do you?

I’d also like to point out a myths I heard regarding signature spoofing. Some people assume, that signature spoofing allows to break the Android signature security model and thus rogue applications can access private app storage. But in fact signature spoofing is only applied after installation if the permission was granted, it has no influence on the package manager security model.

The CyanogenMod story

You might have heard that the CyanogenMod core development team did not accept the request to add signature spoofing to CyanogenMod (CM). This was the case for all three versions of the feature patch:

1. Permission granted at installation time: Link
2. Permission and checkbox in developer settings: Link
3. Runtime permission (active user consent, CM13 only): Link

What you might find interesting about this is:

• CyanogenMod comes pre-rooted. Root has to be enabled through a checkbox in developer settings and with root access you can do everything you could also do with signature spoofing and A LOT more
• Most CM developers that argued that this is a huge security issue, were not able to say why or give a concrete attack scenario and if they were, it was the myth explained above.
• One CM developer confronted me with the third point mentioned above: Apps imitating Play Services can receive data intended for Google. I already pointed out how problematic that is above. However, Android currently does not properly verify signature on system apps, (as these cannot be installed or uninstalled by user, there is no reason to assume that it is rogue) and thus an app imitating Play Services can already do so, as Play Services must be installed as system app and the user will accept it, if he assumes it to be a legit Play Services (if it’s not he is unlikely to install it and grant the spoofing permission).
• It was suggested that for this feature to be secure it has to be restricted to apps installed on the system permission and being signed with the platform key (which only CM core team possesses). This means that this would make the patch not only useless, but enforcing “higher security” when using the signature spoofing feature introduced than using the “spoofing” integrated into Android, basically rendering the whole patch useless.

I have no idea why exactly CM team does not like to include the spoofing feature, but it seems it is not possible to argue with them. Although they mention security as the reason, they fail to prove that there is a relevant security risk exposed by the patch. Funnily enough, they publicly tried to get a statement from Google’s Android Security Engineer Nick Kralevich for the first version of the patch, but he never responded (at least not publicly).

As long as this functionality relies on the the spoofing aspect, no – official CM repos will not carry this patch. […] If this means we see us forked or users migrate to Xposed, so be it.
~ Abhisek Devkota, CyanogenMod “Community Manager”

This really sounds like a request to fork CM, doesn’t it? With CM being the most popular custom ROM with widest device support, it is crucial that people using this system can run without Google software. And when we are about, we could also remove the proprietary Google bits included in CM. Good idea? Let me know!