We're working on an app which needs to integrate with a specific hardware component.
Now, after an update on the side of the hardware vendor, they tell us we need to sign our APK with their .keystore (which they've provided, including a password) in order to work with their hardware.
I can confirm this approach works in debug mode, the APK is signed and we have access to the hardware. However this doesn't work with Google Play signing, because Google expects the APK to be signed with our uploading certificate (and signs the APK with the key stored on their systems afterwards).
This strikes me as a very strange approach, shouldn't the .keystore and password be kept private? And are we opening ourselves up to a massive security risk if we sign the app with their keys?
Any advice is much appreciated, thank you!
It is very unusual and a potential security risk to use the signing key and password which is provided by a third party.
But: Apps that are signed with the same key as the OS on an android device can get special permissions. This might be necessary to use hardware features and system APIs on an android device which are usually not available to normal apps through Android.
Besides that, when you setup Google Play app signing, you can provide your own signing key and password. This would allow you to use the key from your hardware partner in production Play Store apps.
Related
I am using a simple TWA (a Website with PWA supported packaged into a native Android app) with bubblewrap. In order to get this TWA working properly it must have an assetlinks.json file including the sha256 fingerprint of the signing key uploaded to the webserver.
There seem to be two keys for signing: An app and an upload key.
If I release the app via playstore, the TWA want to see the app key
If I just install the local apk file it expects the upload key
Also different key tools will output different keys:
Bubblewrap seems to use the App Key: bubblewrap/bubblewrap fingerprint generateAssetLinks
Google Play seems to use the App Key as well.
The keytool seems to use the upload key: keytool -printcert -jarfile app-release-signed.apk | grep SHA256
Now I am wondering if I missunderstand something. Why does the local apk file expects a different key than the playstore release? Is it safe to upload both shasums to the assetlinks.json file in order to allow playstore releases and local testing?
So it took me some time to understand the whole process and also to find the correct documentation.
I highly recommend reading the documentation
The app key is used for Google Play releases and the upload key for local apk files.
It is safe to integrate both into the assetlinks.json file, also explained in the documentation
For local testing and google play releases at the same time it is required to have both keys listed in the file
The keys can be obtained from the 3 locations mentioned in the question
It might take some time that your device will recognize the update of that file. It is cached by google.
Also interesting to hear from a google developer:
Having both fingerprints in your asset link file is definitely more convenient, and it's something that I personally do. However, my TWAs are for testing, so I'm not too concerned about security implications.
The downside is that you increase your attack surface - if someone steals your debug key (which is probably sitting unencrypted, with some default password on your computer) they could claim to be associated with your website (and intercept links to it from their app).
I just enrolled to App Signing in Play console and everything works great.
But how should I treat my new upload keystore and its passwords now?
Can I just put this keystore under version control and put passwords into build script in plain text?
As I understand this keystore is only used to temporary sign my apk prior to upload. So I consider it to be pretty safe, since nobody except myself can actually upload new apk to Play, and there is no option to access my original release keystore by knowing upload keys.
Another thing that bothers me now is that I can't see any option to change upload keystore. Is it possible now, or at least planned to be added to Play console soon? If I'll publish my upload keystore and passwords to version control it would be nice to have an option to switch to a new private keystore, if something will go wrong.
The way you handle your keystore is pretty personal, but publishing it into your source control specially with the password is not a good idea.
You are right when you say that only you can upload the apk into your account, but your account can be compromized for various reasons, so it is always good to have a second step to upload any apk for your account.
When I worked into a team, since we had a private source control we upload the keystore with our codebase. But the password was managed through 1password.
Now that I work alone, I handle myself my keystore.
About your question to changing the keystore. This is not possible. That are two things you can't change after you uploaded your apk: the package and the keystore. This is done for security reasons.
You can have more info here: https://developer.android.com/training/articles/keystore.html
As #jonathanrz said, it's best to keep your keystore files private.
It's super easy to use a gradle.properties file to store you keystore passwords, and then just reference property values in your build.gradle file.
Just remember to guard the keystore files with your life, keep backups of them in multiple places, if you lose them, you'll have to re-upload your app.
I will answer my own question (based on Reddit discussion).
In order to change upload keystore you will need to contact Google support and request a reset. It is not the easiest option, but still good to have one.
Can't see big issues to keep upload certificate along with its password in a private repository. As long as it is not possible to automatically push production builds it sounds safe enough and also simplifies Alpha / Beta builds distribution.
Some people have reasonable concerns that by sharing release keystore with Google it may be compromised or used by Google to integrate malicious code into your app. But chances of it are pretty small so as long as you are not working on Facebook or other very popular apps it should be safe enough to rely on Google.
I'm attempting to reverse engineer an android app called HeartTrace in order to pull sensor data at a higher frequency. I decompiled, adjusted the parameters, and recompiled the APK. However, the app no longer connects to Google Fit API. Does the API require a new signature from Google before recompiling? If not, what is the issue? Thanks!
As mentioned in Sign Your App,
Android requires that all APKs be digitally signed with a certificate before they can be installed.
Therefore, you need to digitally sign the app again using these two options:
use the same key which can be found in .keystore file if the app has already been published in apps store, or
generate a new key to be used in signing in
However, if you opt to use a new key, don't forget to check Signing Considerations.
I highly recommend going through the given documentation wherein these are being discussed in complete details:
describes how to sign your APKs, including creating and storing your certificate,
signing different build configurations using different certificates, and
configuring the build process to sign your APKs automatically.
And for additional information, this tutorial on Google Fit for Android: Reading Sensor Data and solution given in this SO post - Google maps does not work after resigning an apk which is related to decompiling an Android app might also help.
A distributor is asking for an unsigned version of my app's apk. Is there some security risk I am taking if I give it to him? I'm not really sure of the purpose of the signature.
The digital signature is used to verify the installation of the app.
Android's app system is built in such a way that once an app is installed, any updates being installed must have the same digital signature attached to them. If the update has been signed by a different key, then Android will not allow its installation. This is done to prevent your app from being replaced with a malicious app posing as yours. As the malicious app will not share the same signature, it cannot replace your app.
Additionally, App stores like Google Play will not allow you to upload an apk as an update to the app if it isn't signed with the same key.
Distributing an unsigned apk shouldn't pose a threat to you per se, but if someone can get hold of your signing key, they can cause a lot of damage. I don't see a problem with giving the distributor the apk, but make sure that your signing keys stay with you, especially if you use one for multiple apps.
My company is attempting to publish its first Android app on the market, and we have gotten to the code signing step. We have keys that we use for our other products and use the windows codesign tools to sign our products. We would like to use the same key to sign the Android app, but (obviously) cannot use the windows signing tool (because it only signs .dll's and .exe's)
Does anyone know how to sign an android app using existing keys? (.spc and .pvk files)
Thanks in advance.
You can try converting the PVK into something for the Java keystore. The odds of the resulting key being something the Android Market will accept is low -- for example, the Android Market requires the key to be good for at least 25 years, that you will use the same key for the entire lifetime of your app, etc.
Since the Android key can be self-signed, you are not saving any money this way and are only wasting time and increasing risk, IMHO.