Same keystore, but different keys for different apps? - android

Ok so I understand I can use the same keystore for multiple apps, but what about the same KEY or ALIAS? Should I use the same keystore AND same alias or key for all of my apps?

You dont have to use the same alias for your apps. But for the same app when publishing updates my understanding is that you have to use the same keystore/alias. Now, which approach is better? Depends, however signing apps with the same key establishes the trust among your applications in sharing data. From android developer's website:
The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications.

Related

Android Release Keystore

I just started wondering if I MUST create a Keystore for each Android app I develop considering that our company develops custom made apps for clients. Should I create one Keystore for each app or just one for all of them?
EDIT: Also how many alias for each keystore and if more than one, why?
If you are developing apps for clients, you shouldn't really hold the signing keys. Since it's their app, they should own the signing keys and publish it. Ideally, you would send them unsigned APKs which they will sign and publish. If they can't/don't want to do that, you should have separate keys for each company. First, because at some point they may require you hand it over, and second to limit the damage if the keystore is lost or damaged.
Also, your question doesn't explicitly say this, but regardless of how manage keystore files, do use different keys for each client. Otherwise Client A may get access to Client B's data if the two apps happen to be installed on the same device and use signature-level permissions.

What does the term 'application signing' mean in Android?

Can anyone please elaborate what is app signing in android and why it is necessary to upload an app to android market? Also tell me what changes it make to the application package/apk file.
Thanks in Advance
You sign your application with your private key so that ownership and the integrity of the APK can be verified.
https://en.wikipedia.org/wiki/Public-key_cryptography
https://developer.android.com/tools/publishing/app-signing.html
You might've noticed that in some cases a download has an associated md5 hash, that's a similar sort of thing although intended exclusively for verifying the integrity of the download.
In the old days, you checksummed your downloads against the provided hash just because your connection was lossy and crappy and files could get corrupted.
These days it's that and security.
One among many security concerns would be a nefarious actor taking over your Android Market account and uploading a hacked/virus-infected APK. Signing with a private key ideally reduces the odds this could happen successfully unless they've made off with your keys as well. By identifying you, via the keys, they're also protecting your users from the aforementioned scenario.
App signing is required to identify the author.
Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.

Is there any advantage to using a certificate authority when creating certificates for android code signing?

With regards to the certificate used for code signing for Android Marketplace,
I realize that using a trusted third party to sign such a certificate is ... unlikely, for reasons that have been discussed.
However an organization could create their own certificate authority, and sign the certificate that way.
My question is, would there be any advantage whatsoever to doing it this way?
I get the impression that really the only thing that matters is the private key used to sign the code (and perhaps the expiration date) and that any other certificate information, such as chain of authority or CRL location is not utilized by the system in any way.
Thanks.
Not that I can see. Since it's a public-private key pair, the only thing that matters is that you hold the private key. Signing with Google vs. a trusted third party doesn't matter.

Can I use the same keystore file to sign two different applications?

I have to upload a new application, It's just the design that's a little different. Yesterday I generated the keystore file to sign application. Can I use the same?
You can use that keystore for any number of applications.
No need to generate a new keystore.
I'll make a counter argument to the consensus answer so far.
I agree that for most app authors most of the time, sharing the same keystore/certificate/password between your apps will work fine. The critical thing is to use "the same certificate throughout the expected lifespan of your applications" so the app can upgrade itself.
But I can think of one very good reason to have separate keystores for separate apps or families of apps. If you think you might ever want to sell an app to someone else for them to publish as an upgrade to the original, you'll have to share your one-and-only keystore and password with them to do so. Probably not a huge issue but a bit of worry to you and, perhaps, a due diligence issue to a big-enough buyer.
Also, I really don't read the same line in the documentation the same way as #ol_v_er does. I think the current line:
You should sign all of your apps with the same certificate throughout the expected lifespan of your applications.
(note the lack of a comma in the current version) is simply emphasizing that the 'lifetime' recommendation applies to all apps, not actually directing you to use the same certificate for all of your apps.
The official documentation tells us:
In general, the recommended strategy for all developers is to sign all of your applications with the same certificate, throughout the expected lifespan of your applications. There are several reasons why you should do so ...
https://developer.android.com/studio/publish/app-signing.html#considerations
So yes, try to sign all of your applications with the same certificate.
I want to add some clarification here, because this question and the answers provided lead to confusion for me. It is crucial to understand what a keystore actually is.
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. It has security implications, however. If your single alias is compromised, then all of your apps will have been compromised.
However, if you intend to sell the rights to your apps one day, then using the same alias for all of your apps may not be a good idea. However, using the same keystore, provided you use a different alias for each apk, may not necessarily be a bad option. I'm sure there is a way that you can move a certificate from one keystore to another, so that you can securely give the necessary keys for only that certificate to your buyer.
To make it very clear, a keystore is just that, a storage medium for keys. It plays no actual part in the process of signing an apk, but only serves to store the keys which are actually used to sign the apk.
References:
Understanding keystore, certificates and alias
https://www.digitalocean.com/community/tutorials/java-keytool-essentials-working-with-java-keystores
Of course! You can use the same keystore file as many times you want. It's always better to use the same keystore file for all the applications you develop. That will help if you want to update or modify the application. At that time you need to sign your application with the same key.
Recent Update
If you want to enrol in App signing by google you have to use new different key to sign your apk or bundle otherwise after uploading google console will give you error message saying
You uploaded an APK or Android App Bundle that is signed with a key
that is also used to sign APKs that are delivered to users. Because
you are enrolled in App Signing by Google Play, you should sign your
APK or Android App Bundle with a new key before you upload it
I do sign all my apps using the same certificate (keystore). This gives an advantage if i change my mind and want my apps to share their data.
As you might know Android identifies each app with an UID. If all your apps are signed by the same certificate you can request android to assign same user id more than one app and inturn make them run in a single process and share the data.
From android doc android:sharedUserId
android:sharedUserId
The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if this attribute is set to the same value for two or more applications, they will all share the same ID — provided that they are also signed by the same certificate. Application with the same user ID can access each other's data and, if desired, run in the same process

Is it okay to sign two different applications with the same key?

I have made two versions of my application, a "large" version, and a "mini"/"lite" version.
Should I be signing both of these with the same key? Or should I sign with a unique key for each of them?
What are the repercussions of signing multiple applications with the same key?
Please sign your apps with the same certificate only in case you need to share data, or other resources. Some disadvantages of signing with the same certificate:
If your app certificate is compromised, all your apps are in danger. Certificate holder can create fake updates for your apps to steal users data etc.
If you wanna sell one of your apps, you have to compromise your certificate to the buyer.
If you lose your certificate, you will be unable to make updates for all your apps. You will be forced to create new packages (new apps) for all of them.
If one of your apps has signature level permission, or allows user id sharing, all your apps can take advantage of this!
Happy signing!
Signing is used mainly to identify an application's developer. If anything, you're suppose to sign all applications you make with the same key.
The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.
Read everything here:
http://developer.android.com/guide/publishing/app-signing.html
Signing the applications with the same key allows them access to each other's data.

Categories

Resources