PSA: Think About Stronger App Signing Keys

Back in the beginning of Android development, we were told to use keytool to generate our production signing key for our APKs. The only real requirement was that the key have a long enough validity period (25 years at the time, IIRC).

Now, the documentation for app signing contains a small side note about the -keysize parameter to keytool:

The size of each generated key (bits). If not supplied, Keytool uses a default key size of 1024 bits. In general, we recommend using a key size of 2048 bits or higher.

The reason for the 2,048-bit key size recommendation is that 1,024-bit RSA (the keytool default) has been considered at risk for a few years.

The recent revelations about state-sponsored decryption research should be hammering this home. Even if today, forging a 1,024-bit digital signature is still impractical for all but the largest security agencies, it is well within reason that this will fall within the reach of large botnets in the not-too-distant future. As with the “master key” security issue from earlier in 2013, apps will be able to be replaced with hacked editions, without tripping up the signature check, or signature-level permission checks might start passing due to forged signatures.

Switching to a larger keysize is not that hard… for new apps. Just specify -keysize 4096 when creating your production signing key, and you should be good for a long time, barring a major decryption breakthrough for RSA signatures.

For existing apps with existing signing keys, though, you cannot change the key without breaking your ability to update the app — the very security measure we are trying to ensure works will stop us.

Unfortunately, one survey has found that ~75% of Android apps use 1,024-bit signing keys. That includes me, as I had created a production signing key before the documentation update and had missed the update itself, since the security point was not trumpted by Google.

Hence, I’m doing my own bit of trumpeting. Fortunately, without a trumpet, as I don’t play the trumpet, and it is a bit early in the morning for my neighbors to have to put up with amateur trumpet-playing…

Create a new, stronger production signing key, as a separate key from whatever you are using for production. Make note to use that new signing key for any new apps you create. And, if you have other reasons why you are migrating an existing user base to a new app (e.g., free app for which you are now offering a paid-app option), consider using the new signing key.

If you are a consultant, and you create unique signing keys per project, just cut over to using a stronger key for new clients and projects.

And if you are creating apps for which security is paramount, you might consider whether it is worthwhile to move your user base to a new version of the app with a new signing key at some point.

A tip o’ the hat to The Guardian Project, whose mailing list posts pointed out this issue.

Interested in Jetpack Compose? has a weekly newsletter of the latest articles, samples, and other details of Compose development!