Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to prevent usage of leaked keystore and password?

Tags:

Problem

The keystore and its password are used to sign the app that is then used by Android to identify the developer. If leaked, someone could update the concerned app on our behalf. Even if the person doesn't have access to our playstore account, they still could publish it somewhere else.

We see everywhere, "never lose it", "never leak it", etc. But what if I did? I cannot find the required steps to follow when they both, the keystore and its password, leak so I can protect our users and our app.

Question

Even if I publish the same app with an other appid, how can I protect my users that are still on the old one? Is there some best practice here?

like image 687
oldergod Avatar asked Sep 23 '16 08:09

oldergod


People also ask

Why should you password protect Keystores?

The JKS keystores are binary stores and its contents are encrypted using the password as a key. No one can access the contents without the password. The password is for protecting the contents of the store from illegitimate accesses and manipulation.

Can keystore be hacked?

Since the keystore file is secured with a password, we have used the brute-force and the dictionary attack to crack the password of the keystore file in Ethereum wallets. Our results showed that the dictionary attack is more efficient to hack the keystore file than the brute-force attack.

Where should I keep my keystore?

Keystore file is stored and secured in Google play. Your APKs will be signed by Google Play with app signing key and published to users. Even if you lost your upload key you can contact with Google and you can update your application after validating your account.

Can I use same keystore for multiple apps?

A keystore is just a means to securely store the public/private key pair which is used to sign your Android apks. So yes, you can use the same keystore to sign multiple apks, without a problem. You can also use the same alias (each alias is a certificate) to sign multiple apks, and it will work.


2 Answers

Unfortunately there doesn't seem to be a great way to migrate an existing application to a new signing key. This is probably for the best, since the best practice remains to a) have a strong key and b) keep your private release key as private as possible. I found this article outlining a feasible (but rather user un-friendly way) to migrate from a 1024 bit to a 4096 bit key, which seems to fit your use case. Since you still have a valid signing key for the compromised app, you can attempt to migrate them away from it via update.

  1. generate the new signing key, RSA 4096
  2. Update the first app, App1, with a mechanism for exporting private data, using TrustedIntents with a signature pin of the new key, RSA 4096, which Checkey will generate for you
  3. Create a new version of the app with a different package name, App2
  4. sign App2 with new key, RSA 4096
  5. Add method to App2 for receiving user data from App1, including a signature pin of the old signing key, RSA 1024, for use with TrustedIntents
  6. Publish App2 to the app stores
  7. From App1, prompt user to install App2
  8. runs and imports data from App1
  9. App2 prompts user to uninstall App1
like image 173
sarwar Avatar answered Nov 01 '22 12:11

sarwar


Unfortunately, there is no easy answer to this problem. As mentioned above, the most general solution is to create a new app, tell users to switch, and migrate the data over.

However, on Lollipop+, there is another possible solution. You can use upgrade keys to change the signing key of an app in place, which saves you the trouble of creating a second app or doing the data migration. Unfortunately, Play currently has no support for this, so it's only really an option for off-market apps, and users on Kitkat are out of luck.

like image 35
Antimony Avatar answered Nov 01 '22 12:11

Antimony