Signing Keys¶
Android requires that all APKs be digitally signed with a certificate before they are installed on a device or updated. To achieve this, developers maintain one or more keystores – plus the credentials to access them. A keystore holds one or more of those digital certificates, identifying their owner by a DN (Distinctive Name) – and providing hashes, which allow verifying the certificate.
When you install an app for the first time, you establish a trust (TOFU: trust on first use) – basically stating „I trust the developer who built and signed this app, to provide me with this app and future updates for it.“ If the app is otherwise OK (supporting your device's architecture, Android version, etc), Android accepts your choice – and makes sure to respect it. Which means: updates for this app are only accepted, if they are signed with the very same certificate.
Now, IzzyOnDroid always ships the APKs built and signed by their respective developers – so we need to check they are properly signed. For this,
- we check the certificates on app inclusion
- we do not accept APKs signed with „debug certificates“. These are automatically generated by the building tools for easy testing, and considered rather weak. Also, the developer has not much control over them.
- we do not accept APKs signed with „public certificates“ – e.g. test keys intended for educational purposes etc.
- we check against a list of „leaked certificates“ – i.e. certificates to be considered compromised, as at some point keystore and credentials became „public knowledge“. Such certificates are often shared and used by malware groups.
- with the initial APK accepted into our repository, we „pin“ its certificate, by recording its hash with the app's metadata. The keyword for that is
AllowedAPKSigningKeys. So should the signing key for some reason change with an update, such update would be rejected by our repo right away: it could have been compromised (e.g. by a malicious actor who gained access to the app's repository). While those having the app already installed, would be protected against such update already (see „TOFU“ above), this is to protect those wanting to install it for the first time. - should an APK signed with a different key arrive here, we take proper measures to ensure it is justified (for details, see e.g. How to keep your key safe and what measures to take for the event of loss?) – or if that's not possible, the update stays rejected, and future updates disabled until the situation could be solved – or the app even be removed.