Does the signing key for an APK change?

[mendhak]

From this thread I understand that for each application in F-Droid, a new signing key is generated. Does this signing key change, or can we expect it to stay the same?

Example, for conscrypt provider APK I ran:

~/Android/Sdk/build-tools/33.0.0/apksigner verify --print-certs -v ~/Downloads/com.mendhak.conscryptprovider_3.apk

And got the output

Signer #1 certificate SHA-256 digest: 3396e1fe3ebefe1e344d747722a21a70902a73c6eac31fbe1c5cb0843c384d4b
Signer #1 certificate SHA-1 digest: 9de14dda20f05a5801be23cc533414114876b75e
Signer #1 certificate MD5 digest: 438a8da444ca3189a23a6e3d57e082f7

Can I expect this to stay the same in the future… barring any major catastrophes? Or are there policies that rotate the signing key, something like that?

[Licaon_Kter]

What’s your use case? That well-known site hash thing for an app?

[mendhak]

I’ll try to explain it, its purpose is for a bit of risk reduction. Basically this APK can be used by other applications. It can provide TLS 1.3 capabilities to older Android devices.

Just for safety, it would be good if the calling application can ensure that this APK has an expected signature, to minimize risk of spoofing.

Since F-Droid does the packaging and deploying, it is also signing the APK. In the case of conscrypt provider, I did a check, the key is 9de14dda20f05a5801be23cc533414114876b75e. So, a calling application could use that when detecting the APK to ensure it’s from an “expected” source.

So my question became, is that key that F-Droid uses, for an application, meant to be long lasting? I’m actually fine if it breaks in the future and changes to something else.

[adrianmalacoda]

I can be wrong but I’m fairly sure it can’t change. Android prevents updating to a newer version if the signature does not match.

[mendhak]

Aaah of course how did I forget that! Yes you’re right. So it would only be a major catastrophe that would cause the signing keys to change.

Thanks both!

[Licaon_Kter]

@mendhak

Just for safety, it would be good if the calling application can ensure that this APK has an expected signature, to minimize risk of spoofing.

How does an application “call” exactly? It downloads the APK and verifies?

[mendhak]

Sorry for late reply. I can show the repo itself, have a look: GitHub - mendhak/Conscrypt-Provider: Conscrypt Provider app, which can be included from other applications (WIP)

The APK would need to already be installed on the user’s device. Then, the calling application would need to use Reflection to invoke a method inside the APK I’ve made here.

    Context targetContext = context.createPackageContext("com.mendhak.conscryptprovider",
            Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY);
    ClassLoader classLoader = targetContext.getClassLoader();
    Class installClass = classLoader.loadClass("com.mendhak.conscryptprovider.ConscryptProvider");
    Method installMethod = installClass.getMethod("install", new Class[]{});
    installMethod.invoke(null);
    installed = true;
    Log.i("Conscrypt Provider installed");

Before this the calling application would need to ensure the package is installed, and ideally that the signature matches an expected one.

This particular APK you’ll see is dead simple, it’s literally a one-liner that actually calls a Java library. The reason for putting it into an APK is because it’s a large library, and not needed by everyone. So this mechanism (‘call’ an APK) allows me to optionally provide this to users from my app.