I read this article about signing your Android applications. I used Eclipse to export my Android application, had to create a keystore (which succeeded) and a private key with an alias (which also succeeded). So I know that I have to sign the application with a private key.
However, the article does not make clear anything on the following questions:
What is a private key?
Should each application you make have another key or should they share the same private key?
What is an alias?
Why do the applications have a validity lifetime?
A private key is a cryptographic tool that verifies you are the owner of the app. Any build that is being updated to the Google Play store must be signed by your private key to prove it is a legitimate build.
So each different application that you want to upload to the store should have its own private key. If you ever lose this key, you will not be able to upload any new versions of your app, so make sure to store it somewhere safe and make backups!
However, you can store multiple private keys in the same keystore for convenience. (Although I do not, I find it more convenient to have a different keystore for every project as well.)
An alias is simply an easy to read name for the key. Nothing more or less.
It's worth noting, when you do an Eclipse "Run", it uses something called the debug key to run the application. This works fine because you are not trying to upload this build to the store, but this is why you need to use a separate build process to build your application for deployment.
The lifetime validity is a technical requirement. Just set it way in the future and don't worry about it.
Signing is like a certificate for your Android application (think web certificates to have some idea) - it proves that you're the owner of that application. Every app must be signed, as the link you provided clearly says.
In theory, every application from a developer should be under the same signature (after all, it's >your< signature, not the app's)
The alias is just that: an alias for your key, which you use to refer to the keystore when signing the application.
And about the lifespan, not everything lasts forever. Those signatures (or certificates if you will) can last over 25 years. Not something you have to worry about.
Related
Based on my understanding the android apk signing step is to make sure the apk a user is to install is unmodified. The apk is signed by a private key, however based on my understanding the public key is written right within the same apk file. I wonder how the user can trust the public key and use it to decrypt and verify the apk? Because I were a hacker I could simply get the original apk and modify its content and encrypt it with my own private key and insert my own public key in it so that when the user get this hacked apk he/she should still be able to pass the verification process as the apk is using a valid private and public key pair which is mine?
APK signing works for application update scenarios. You can only update an application with an APK signed with the same key as the original installed app.
Modifying an APK and signing it with another key is certainly possible and it does happen. One hurdle there is distribution: tricking users to install the modified version. Application stores have mechanisms to detect such app modifications or otherwise malicious apps, and the default platform security setting disallows sideloading i.e. installing applications from untrusted sources. These are of course not 100% effective, bad apps do get installed.
In addition to what #laalto said: the signature is also using for signature protected permissions. If you have several applications, and they use Android intents to communicate (e. g. one app is using a service in another), and the intent targets (services, receivers, content providers) are protected with private permissions, and the permissions are declared with the protection level of "signature", then Android will only grant permissions if the two applications are signed with the same key. That's where the potential hacker would be thwarted; were they to re-sign an APK with their own key, Android would notice that and deny access.
I'm writing a python script to build and sign my android project using gradlew ,
Everyone on the web is talking about how u can lose your generated key and therefor u can lose ability to update your published application. my question is are every generated keys using keytool unique?
and the signed apk using that key would easily be uploaded to google play store and every single app signed using that certain key will be considered as an update ?
thanks .
Yes, every key generated by keytool is unique.
For key management, you basically have a few options:
Generate the app signing key locally, keep it secure, and only use it when generating the release version of your app. Use a separate key for the debug versions of your app.
Generate the app signing key locally, enroll in App Signing by Play supplying your key to Google. During the enrollment, you will be prompted to created another key (called the upload key). You can use the upload key normally to sign the apps you upload to the Play Console, but make sure to keep the app signing in a safe place with strict ACLs. If you lose the upload key, you can always have it reset, so less critical.
The easiest solution (and the default in Play Console) is to enroll in App Signing by Play and let Google generate the app signing key. You are this way sure that you won't be accidentally losing or leaking it, and that it will be secure enough. Also, you'll only have one key to deal with: the upload key, which can be reset if you lose it.
I'd recommend the 3rd option (simplest, most secure), but some people prefer to keep a copy of the key with them and thus opt for the 2nd option. The 1st option is very risky as you seem to have already heard.
I want to clarify a confusion I have related to Android app certificates (used during installation).
In the web, certificates are used to map a public key with domain / identity (organization). The hash of the details is signed by CA, then verified by the browser.
An Android app ships with a public key. Based on my understanding, the developer could use his own private key, sign the hash of the app, then ship app with his public key. This information is used by installer.
My questions are:
Even if some CA was used, app would still be shipped with CA's public key - does it matter who owns the signing public key ? it could be anyone, as installer will just use it.
Is integrity checking the only thing android app certificate is used for ? App has a no public key like a website, so certificate is not being used to associate some public key with the app. Is there any other purpose for the certificate ?
does it matter who owns the signing public key ?
No. Usually, they are self-signed.
Is integrity checking the only thing android app certificate is used for ?
It is also used to answer two permission-related questions:
Is App A signed by the same signing key as App B? If yes, then those apps may be able to interoperate more closely than two arbitrary apps.
Is App A signed by the same signing key that signed the firwmare? If yes, then App A can hold certain permissions that are reserved for device manufacturers and custom ROM developers.
Also, developers can validate the signature of other apps, which can be useful for ensuring that you are talking to the proper app.
does it matter who owns the signing public key ? it could be anyone,
as installer will just use it.
Yes it will. Anyone can write an app, self-sign the certificate, and publish apps using it. The private key is still controlled by the owner, and he/she gets to control all the app's capabilities and any future updates to the app, as explained below.
Is integrity checking the only thing android app certificate is used
for ?
Nope, it serves more than that:
When installing Over-the-Air app updates, the device will confirm that the updated app's certificates match the existing one. If the developer were to sign the app with a new key, he/she should change the package name; without this, Google Play does not let the developer update the application. If the developer does want to change the signing keys, he/she will be forced to change the Application's package name, and hence this will show up as a new application altogether in the Play Store.
Two or more applications using the same public key can share data amongst each other. Permissions can be signature based for instance to allow this.
It is also possible for 2 or more applications signed using the same key to run in the same process group, and even share code and state.
More details available in the Android Developer page - https://developer.android.com/tools/publishing/app-signing.html#considerations
I understand they are used to sign and verify the authenticity of one's work, yet I still don't fully understand the roles they play. Google's dev guide just kind of says "you need these." I'm looking for an explanation, maybe in terms of something else in life I'm familiar with, so that I can understand them at a high level. I don't exactly have a computer science background.
Here's what I think they are and you can tell me if I'm right.
The keystore is like the document of authenticity for my app and my private key is like my private seal on it. Therefore, if I develop multiple apps, each will have a keystore, which I'll sign with the same private key. Right??
The keystore is basically the database of your private keys. You can have multiple keys stored in your key store. The private key is what you use to sign the app with, and because nobody else will have your private key, nobody else can make fake apps with your company, account, etc.
You can use same keystore and private key for each of your apps. There is no need to create separate keystore/privatekey for each app.
During building production apk your IDE/building system will use private key from your keystore in order to sign files inside this apk. Thanks to that only you will be able to update app to the Play Store (Google will check if certificate fingerprints are the same).
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