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).
Related
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
So working on pushing our first build of our app to the various app stores.
Apple provides its own set of challenges and irritations.
Google, however, instead of allowing you to somehow authenticate with your google account (which would make sense to me), wants you to create a keystore with a private key & public cert (which it embeds in your apk). Then every update must have that same cert in order to be pushed to Google Play (if I understand the docs correctly).
So the keystore has a password, the private key has a password, and the keystore resides on your filesystem somewhere. This is all well and fine if you're a solo developer, however I am on a development team and any one of us may want to push an update to the app.
How do you deal with distributing the keystore and passwords in a secure way to your team & onboard new teammates when they arrive?
The answer is, you don't. There should only be one person that controls the keystore and passwords because that's who controls who submits it to the Play store. You certainly don't want new onboard teammates just submitting a new apk whenever they feel the need to.
If you're the head of this team, you should be the only one with it and control when new updates are pushed to the Play store.
If you really need to or have reason to allow multiple team member access to the Keystore.. you can subversion them. In my experience, they don't seem to be tied to a specific computer. So even if you have to replace your computer, you should still be able to use the Keystore.
Actually that is a smart thing to do anyway. We have several Keystores that got corrupted or who only knows what, but they stopped working. Which means whatever is tied to that Keystore is hosed.
I have been developing an Android application for another person that is to be published to the Google Play Store. They have a developer account, and have given me a key. I have made a build release of the application and now have an unsigned apk. All I have is their key. Is there a way to release this app into the Play store without this keystore I have heard about, just using they key they have provided? All the tutorials and docs I am looking at keep mentioning the keystore, and since this person has their own account with their own key and will be maintaining the app on their own moving forward, it doesn't make sense for me to use my own account.
Alternatively, maybe it is just a situation where I need to give them the unsigned apk key and they are responsible for the remainder of the publishing process. This is less than ideal, because we would like to be able to possibly make some changes to the app after the initial release. Any guidance would be appreciated.
They can create the keystore and send it to you, the keystore should be password protected, then you will have an alias/password pair inside the keystore to access the key you want. When exporting your apk you can select this keystore and sign the package with their key. To make changes in the future you will need to sign it/export it again with the same key and upload it to the Google Play store. If you lose the key you will not be able to upload a new version. You can find more detail at this SO question.
My advice is to generate a keystore the proper way, either the other person needs to or you should and then share the information.
I have an open source app that Ive recently added in-app billing to. Is it safe to keep it open source, since the code now has the RSA key in it?
The key Im referring to is the Base64-encoded RSA public key provided by the Google Play Developer Console.
How the name says it's a public key. This means it can be shared publicly with others. Even if you don't want to share it, any developer with enough skills can very likely extract it from your application, if it's there. So that's not a big issues, if you revealed it.
What you really have to keep secret is the way you store and access your public key inside your app. It is important because your app uses your public key for validating payment server response. Response considered to be valid if it was signed by your private key. Thus, having a public key you can always say whether a server has used your private key (which is known only by you) to sign the content or not. What a hacker can do is, he/she can replace your public key inside your app with their public key and then send hacked response signed with their private key. Your logic will successfully validate such responses and your app will behave as a paid app. So be aware and kept the way you store your public key private.
Regarding your case, I would suggest to remove in-app payment related code from your open-source project completely. This will increase security and make hackers life more difficult. You don't need to worry that you revealed your public key, but you may better remove it too, together with the implementation mentioned above.
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.