I want to preface this question with two things so I can narrow down where my actual question is:
a) I've done software dev before, though never for android
b) I'm familiar with PKI and encryptions and hashing and digital signatures and blah blah blah
That being said I'm having trouble tracking down more information about where and how Android verifies app creators. I've heard a lot of different information so I'm trying to synthesize to get a better idea of the workflow.
I know that every app developer gets their own private/public key pair and they sign their apps by hashing the APK (with SHA-1 most of the time if I'm not mistaken) and there you go. You upload it and (I believe) the public key goes in META INF inside the APK. This much I understand.
My question is how this relates to when a user downloads the app itself. I know the phone checks to make sure that the app is validly signed, and that the signature also has information about author and etc included. But I've also read that apps are self signed and that Google Play (or whatever they're calling the Market now) doesn't implement a CA, and that there's no identity authentication? But my question is what, then, stops people from uploading an app under another developers name (crowdsourcing aside)?
If the phone only checks for valid signatures does that imply that the only means of authentication is done when the app is uploaded? And if that's the case how does the app market check it? Is it the usual - use the private key on file and verify the signature? Or does the developer have to provide the market with their private key to authenticate?
In short, Android and Google Play essentially don't care about what's in actual certificate. Google Play will validate it indeed, and check if it is valid for 30 years or more, but they don't really use (at least currently, AFAIK) the actual info in the cert. You could use your own name/company name in the CN, but no one will validate this, and users won't see this info at all. What Android does is:
check the signature to make sure the APK hasn't been tampered with
then compare the singing certificate as a binary blob to the one of the currently installed version of the app to make sure that the two versions have been signed with the same key/certificate (e.g., by the same person/company)
it does the same thing to enforce permission if you are using using sharedUid or signature permissions with two or more apps.
So, to answer your question, someone can easily create a certificate with your name on it, but Android and Google Play don't really care. As long as they don't have your private key, they won't be able produce an app signature that is the same as yours and thus they wouldn't be able to overwrite/update your app with theirs, or get any special permissions.
Regarding apps updates without using APK signing key rotation - the publisher's whole certificate must be exactly the same for the old and the new version. It was discussed here.
Related
Good day,
I have a question that might seen kindergarten in nature, but please go easy on me.
I have developed an app that works fine, and use a keystore, with a key value of "key0" and accompanying password. I have since developed a second app and I am using the same keystore, "key0" and password for uploads.
I thought that Google Play would complain citing security concerns if it didn't like using "key0" for app2 when uploading? Common sense would dictate using different keys for different apps, but if so, Google are happy to allow my app updates and issue them on the store!
I must admit that I am a novice when understanding certificates and keys - and this confusion has just been compounded by Google telling me that you cannot use the same key for different apps. I am confused by this, because on the App Signing page of the play console, although the upload certificates are the same for both apps, the app signing certificates. I am lost as to what all this means. Could someone please help?
From my understanding, Google wants the developers to use different keys for their app signing so that the key is confidential and anyone with that key can actually submit an update for your application if they are having the same package name that your application has.
Hence about the other question that you have, I think sometimes it is necessary to publish two or more applications using the same sign in key so that they can actually share the data between them. For example, Facebook and the Messenger app actually share the data between them and from my understanding, I think they use the same key to sign in their apps so that they can enable this data sharing.
I think this is a good read.
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.
What are all the conditions satisfied by the APK to upload in play store?
like debug release,signed apk,keystore generation.and please explain them how to do?
A release build. So you should ensure you are not polluting the logcat with your debugging statements. Usually this will automatically be flagged off for you but you may (as I often did) use different forms of debug logging (eg with the NDK) which will need explicit deactivation.
You will need to sign your APK also. You can generate a key and keystore offline with your development tools (i.e. Android Studio, can't remember about Eclipse but (How do I generate a "Keystore" for Google Play?) should work in that instance).
When you register an account on the playstore you need to upload your public key. You can associate about 20 (IIRC) keys with an app's GMS profile, although that is not strictly required to upload an app in general it is one of the great benefits of a Play Store account. See https://developers.google.com/android/guides/setup for more on that.
Then if you are seeking financial reward, either via advertisemnet or direct sales you will need to provide your address.
For this service and also, I suspect, for the purposes of identity verification, Google require a one off registration fee of a princely $25.
I just sold one of my Android apps via Apptopia. The selling process requires that I send the buyer my Android certificate key, used to sign the app.
I have several other apps which I'm not selling, that are signed using this same certificate.
Is is safe to send the key to the buyer? Is there any way they could mess with my other apps?
Thanks
I would not say it is safe, but. Given that they are getting access to your key, technically it makes them possible to generate packages that can be 'uploaded' in place of your other applications, but they still do not have acces to your developer console (I am assuming you are transferring your app out of your account), so that gives you a certain degree of safety.
I know it is late, but a good practice could be to sign your apps with separate certificates in the future (which has its own drawbacks too, in certain cases). See this.
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