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
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.
So if I already have an Android app in the hands of many customers, and I sign the app myself with an APK, but want to start using Play App Signing and let Google generate the app signing key, won't my current customers be unable to update the app thereafter? My understanding is that updates will only be accepted on the mobile device if the app signing cert is the same for the update as for the already-installed app. If I start using Play App Signing and let Google generate the (new) app signing key, obviously the cert will change. Have I got this right? How best to handle this situation?
So what happens is you sign the app with key A. Google can recognize its you from that key. Google will generate key B, save it, and resign your app with B. Then it will put that version available for download.
When you later update the app, it will see key A, verify the app, and resign it with key B, the same key it generated last time. So it will have the same signature and will be accepted by the mobile devices as an update.
So updates work. You are allowing Google to purposely man in the middle you and you have the risk that Google will decide to alter your app before release. But most people find that an acceptable risk (they have no real reason to do it and a lot of reasons not to).
You can provide Google with the key you wish them to sign the APKs with. You don't have to let Google generate a new key. Make sure to open the advanced options when enrolling and not use the default option for this feature, then follow the instructions.
Before being able to publish an Android App on Google Play it needs to be signed with a release key. Its said to be for security. When generating the key one has to enter a password.
What is all the fuss about, here?
Let me ask, what would happen if my release key got stolen/copied. Assume somebody could even manage to use that key to sign apps of him/herself. What bad would that mean?
I would argue, little to none, correct? (considering that my developer account/console credentials were not stolen too)
Maybe the biggest/ only risk would arrise if somebody elses app signed with the stolen release key would become able to more directly access data of my app (on the users devices).
They can grab your APK (publicly readable on all Android devices), modify it (e.g., add malware), sign it, and distribute it. Assuming that they bump the versionCode, anyone who tries installing their hacked version of your app will succeed, as from Android's standpoint, it is a valid upgrade. If the hacker can obtain your credentials for your distribution channel (e.g., compromise your Google account for the Play Store), they can ship their update to all of your users.
Or, they can create their own separate APK and sign it with your signing key. Now, your app and theirs are signed by the same key. That opens up other attack avenues:
If you used android:sharedUserId, they can get at all of your app's files on internal storage, which are normally protected from other apps (outside of rooted devices)
If you used permissions with a signature protectionLevel, their app can hold those same permissions and perhaps interact with your app in ways that you were only expecting your own suite of apps to use
There's a developer interested in purchasing one of my apps (the only one that actually have users), meaning I would need to send him the original source code, the keystore and request Google for a transfer following this link: https://support.google.com/googleplay/android-developer/answer/6230247?hl=en
The issue is: all my apps use the same certificate from the same keystore.
So my question is: Would it be possible for the new developer to hijack any of my other apps?
I believe that the answer is "No. A device would allow another apk signed with the same certificate and with the same package name to update on the device, but Google Play wouldn't allow the developer to upload another app with the same package name as any of my other apps".
But I'm not sure on that and I would like further tech details on it.
As I said, the other apps I have are not important and I could just as well unpublish them. But I rather not, and even if I do, the question is still valid.
ps.: yeah, now I've learned that I should have 1-certificate per app.
The package name of your application is unique in the Play Store. It is how devices (and the Play Store) identify your application, and thus must be unique and cannot be changed. Android will not allow your users to install two applications with the same package name.
However, giving your keystore to another developer is still risky. The Play Store employs two gates when updating an application:
First, you must have access to the account that owns the application.
Second, you must have an APK signed with the correct keystore
By giving someone access to your keystore, you remove one of the two security checks. If the new owner of the application where to gain access to your developer account, they could re-publish the other applications as well. There's also the risk of this new owner selling the keystore and application to someone else in the future who might do the same thing.
Theoretically if your account is secure, then your other applications are also safe from hijacking.
Whether this risk is acceptable is up to you.
They could sign an APK and encourage your existing users to sideload it. When sideloading, the app isn't going to be able to know if it came from you or them. But the Play store itself won't let them upload an app that you haven't transferred to them.
Normally, part of the agreement when the buyer buys and app that using a key used by other apps would include a small snippet that the buyer must protect the key. This agreement would be bilateral anyways, since you could in theory hijack their users by sideloading a signed APK.
Would it be possible for the new developer to hijack any of my other
apps?
No way in the world its possible for him to do anything to any other of your apps unless you give him your keystore.
Your keystore is the key to all your applications and you should never share it with anyone. Having an app signed with your keystore in my developer account would never ever let me do anything to your own apps.
Anybody can have apps publish in plays store with different keystores.
I have ready one application in Android that I am planning to sell to different clients. Each client will send me their own information to customize the layout of the application and maybe some functionality. The clients can decide if they want to give the application for free in the market or if it will be paid.
I know that it is not possible to upload the two applications with the same package name, so I will refactor the package name for each client.
According the Android documentation:
Android requires that all apps be digitally signed with a certificate
before they can be installed. Android uses this certificate to
identify the author of an app, and the certificate does not need to be
signed by a certificate authority. Android apps often use self-signed
certificates. The app developer holds the certificate's private key.
I would like to know what is the best way to handle the publishing and signing of my application:
Should I publish the customized version of my application for each client using my own google account or I should request/create one google account for each client?
Regarding the signing procedure, Should I use the same key for each customized version of my application or I should create multiple keys in one Keystore?
Thanks in advance
1- It is best that the client create their own Google play console and send you an invitation as admin, so that you can manage it for them (create new app, listing, publishing etc).
2- Sure you can use same key for all of them (i will recommend you that) as long as it is still valid (should be valid for at least 25 years)