I am wondering which is the more popular option, Having 1 keystore to sign all the apps you publish, and duplicating that keystore into the cloud and locally to keep it safe, or generating a new keystore for every new app submitted, and keeping copies of all of them?
It seems easier to have 1 keystore for everything, but despite duplicating it, im afraid of it getting corrupted and loosing access to all of the apps.
Whats the best approach for this situation?
If you use the same keystore, it will be easier to make your apps work together. By having them signed with the same key, you can use a shared UID (not really recommended), or use signature based permissions. That would make it possible to export certain data or functionality and restrict access to your own apps only (using a ContentProvider or a remote service). The downside is, that if you loose the key, you'll have to republish all apps.
If you use separate keystores, it's easier to transfer an app to someone else (give them keystore and password). Additionally, you need to re-publish only one app if you lose/corrupt the keystore.
Take you pick, but I'd say: use the same keystore and make lots of backups. I would also use physical media (CD, etc) in separate locations, rather then the 'cloud', but that's your choice too.
Related
I need to upload my own new second Android application in playstore. I know it is possible to use same keystore file. But I don't have idea to use same alias or different alias need to generate for second application for playstore.
Keystore is just container holding your keys (like jar for cookies), so from technical point of view is completely irrelevant if you keep all your keys in single keystore or you have them splited among many (you can even have separated keystore file for each key - nothing prevents that).
Alias is also irrelevant - it's just "human friendly name" for your key, just for your convenience. It also makes no difference technically, however you cannot have more than one keys using the same alias in given keystore:
KeyStore Aliases
All keystore entries (key and trusted certificate
entries) are accessed via unique aliases.
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html
However you can use the same alias in different keystores w/o any problems.
NOTE: You can technically sign all your apps with the same key but this is strongly discouraged. You should create separate key for each released app - that will make your life much easier when i.e. you will decide to sell your project for instance.
Yes You can use same keystore to upload different apps, if all the apps belongs to you or your firm.
I bought an app from another developer , we transfer the app to my account following this process https://support.google.com/googleplay/android-developer/checklist/3294213?hl=en .
then I've asked the developer to send me the keystore which contain the private key (alias key).
according to http://developer.android.com/tools/publishing/app-signing.html it's not possible to update a new app with different alias key (private key).
and also it's mentioned How much important to keep the private key in secure place !
now there is some one else who has the private key (key alias) , and my app is not secured enough , what should I do ?
The appId com.example.appname along with the keystore signature can identify an app uniquely. Moreover apps of the same signature can share data between them (see doc android:sharedUserId).
Without your private key you cannot update your application anymore!
This does not actually force you not to bring up the "same" app with a different appId and a different signature!
For the users this means that
they will stop getting updates on the old app (as it is published as a different app)
will lose any local progress is saved by the app
will have to manually install the new app
But it could be a way to avoid any unauthorized publications / modifications of your app!
The only thing that could protect you in terms of the previous owner of your app should be the contract that you may have signed during your co-operation or at the end of it. So lawyers will take action in case of any malicious usage of them!
If I were you I will try to measure out the 3 drawbacks for the users (see dots above) and how harmful will be for me and my app to be hacked. In case you feel that you are not comfortable to continue with the existing app then you may think to create a "boarding update" to the existing app so the user will move to the new one as smooth as possible :D
I have a signed APK. What I want to do is, access the private key and sign (encrypt) some message using it.
Is it possible to access this private key through my code in run time?
Any sample code to do the same?
Never, ever place you Keyring for signing playstore apks in your app.
Because everyone can extract the keyring from your app and use it.
Best practice is to create a new keypair inside of your app on first start. So every installation of your app has its own keypair. Otherwise your users could encrypt data from other installations, too.
More secure is it, to ask the user for password. Which you can then use to secure the keystore for the newly generated keypair. This way also a stolen keystore of your app is harder to crack, because it has a password which only your user knows.
Very complex scenarios uses a key exchange system, where your user keys are generated and managed by a server application. Transport can be done with AES encryption etc.
Here is good presentation about basic cryptography on android from a good fried al sutton ;) http://de.slideshare.net/AlSutton/2014-droidcon-nlandroidcryptography?ref=https://www.linkedin.com/in/alsutton
I'm currently looking at the possibilities of storing/using secrets keys in an Android application. I've found Nikolay Elenkov's blog very helpful regarding this topic and I've learnt a lot of things about the Android keystore and some hardware-based implementations.
Still I've got some questions about security and user experience aspects.
Software keystore
For what I understood, in this configuration a masterkey is derived (using PBKDF2) from a user password (plus a salt to prevent rainbow tables attacks) and used to encrypt secrets. As far as I know, the password is the one used for the lock screen.
On a non-rooted phone, only the user 'keystore' is able to read/write the encrypted files and whenever an application want to access a file, it has to call the keystore daemon which checks if its UID is authorized to access this file (the authorizations are stored in a sqlite database).
But there are still some details I couldn't figure out :
Does using the keystore enforce the use of a password-protected lock screen ?
Does the user have to input his/her password every time an access to the encrypted keys is required ?
Given it's a software-only mechanism, I think a secret key will always end up decrypted in RAM whenever it's used for cryptographic operations, right ?
Hardware-based keystore
As for the hardware-based implementation, it seems that SoC manufacturers provide solutions compliant to [Global Platform TEE][2] (Trusted Execution Environment) with embedded Trusted Applications and APIs that enable Google to provide an hardware-backed implementation of its keystore. It's thus possible to store secret keys in the TEE, ask for RSA key pair creation inside the TEE and sign or check data using secret keys stored inside the TEE. This way, one can use secret keys for basic cryptographic operations without them ever leaving the TEE.
If I got it right, access control to those keys is provided by the Google keystore daemon using the same mechanism as in the software implementation. The only difference is that references to the keys stored in the TEE are used instead of the encrypted keys themselves.
If everything stated before is correct, I guess it would be possible on a rooted phone to modify the permissions database so that an application with an arbitrary UID can have data signed with any key stored in the TEE. Am I right ?
Thanks for your time!
Does using the keystore enforce the use of a password-protected lock
screen ?
Yes, user is forced to use lock screen, protected with password, pin, or pattern.
Does the user have to input his/her password every time an access to
the encrypted keys is required ?
No, once the device is unloked, KeyStore becomes unlocked as well and there's no need to enter additional passwords. However, application should check if the KeyStore is unlocked, because user could disable the lock screen protection in Settings. Once key locked is disabled, KeyStore becomes uninitialized and must be unlocked again.Several times I faced a strange behavior, when the KeyStore was locked, but I didn't have lock screen protection set up. I was prompted to enter a password or pin code to enter the KeyStore. However, it was not possible, since I didn't have any passwords. I assume some system apps were locking the KeyStore. I had to reset it to re-initialize.
Given it's a software-only mechanism, I think a secret key will
always end up decrypted in RAM whenever it's used for cryptographic
operations, right ?
Yes, all keys retrieved from the KeyStore will reside in RAM until garbage-collected or deinitialized. But you can obtain the key each time you need it, not keeping it in some long-living variable.
Unfortunately, I'm not familiar with HW-backed KeyStore. Cannot say anything about it.
Your analysis of the TEE-based hardware-backed scenario is correct. The private key bits generated in the TEE (which isn't necessarily compliant with the Global Platform specs) never leave the TEE and private key operations are performed inside it.
You're also correct that the handles to the TEE-based keys are stored in Keystore, so it's possible for root to access and use any of them, or to move them around so any app can use them.
Can I somehow get details from android key alias? like validity, organisation and so on...
I lost my key and keystore files, but I remember all passwords, is there any way how can I get this information from existing apk file?
All I need to do is just export new version of my application and I want it to replace previous after installation.
THX
Sorry, there is no way to replace a lost keystore. Once it is lost you cannot get it back, do your best to find it, but failing this the best you can do is publish a new app(with a new keystore), and tell your users to install the new app for updates.
Make sure you backup your new key store, send it to yourself via email, put it in a cloud, and put it on a different computer so that doesn't happen again.
Even if you knew the details that you put in your old keystore you could not recreate it - keystores are designed to be impossible to recreate.
Just in case you want another source:
https://groups.google.com/forum/?fromgroups=#!topic/android-developers/tcmT2uHOmGY