i'm trying to publish my app on Play Store, and i receive an error during the progress. Im using a gradle plugin which is "Chaquopy" in this project and found out a warning from Play Store that related to this plugin.
Security Alert: Your app contains embedded private keys or keystore files This app contains one or more private keys or keystore files embedded in its published APK as listed at the end of this message. These embedded items can be accessed by third parties, which can raise a variety of different security concerns depending on what the key is used for. For example, if the private key is the signing key for your application, a third party could sign and distribute apps that replace your authentic apps or corrupt them. Such a party could also sign and distribute apps under your identity. As a general security practice, we strongly recommend against embedding private keys and keystore files in apps, even if the keys are password protected or obfuscated. The most effective way to protect your private key and keystore files are not to circulate them. Please remove your private keys and keystore files from your app at your earliest convenience. For more information about keeping your keys secure, please see https://developer.android.com/tools/publishing/app-signing.html. You have a responsibility as a developer to secure your private key properly, at all times. Please note: Applications with vulnerabilities that expose users to risk of compromise may be considered in violation of our 'Malicious Behaviour' policy and section 4.4 of the Developer Distribution Agreement. assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/badcert.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/badkey.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/keycert.passwd.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/keycert.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/keycert2.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/ssl_key.passwd.pem assets/chaquopy/requirements-common.imy.UNPACKED_ARCHIVE/future/backports/test/ssl_key.pem
I tried upgrade the latest version of Chaquopy plugin but it still not resolve my error here. Please help me with this.
This is some test data included with the future package. Chaquopy itself does not use this package, so you must have added it directly or indirectly with one of your pip requirements. However, it is not a security risk, so the message can be safely ignored.
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.
Starting with Android I have seen that it is necessary to sign the apk. But thinking about what a digital signature is and for what it serves (guaranteeing authenticity and integrity of information) I've read that Android really does not make you sign the app to verify authenticity and integration, but because "Android uses that signature to identify the app that is making any type of request either to the system or to other applications".
Is that so?
I read that it is recommended that a developer sign their apps with the same signature The concept of digital signature is unique for each document, so how is it possible that different apps of a developer have the same signature?
I think I read that by signing the apk, me and nobody else can modify this app. Is that so? How is this?
Thank you
Both are correct. Signatures are indeed used to detect that the app you're installing has not been modified, but they can also be used to restrict access from other apps on your device. Say a company builds 2 apps, and they want to share data between them. They can use a signature-protected permission to ensure that your data can only be accessed by that company's apps.
It's not the signature that's the same, but the private key used to generate that signature. The signature is unique for every build of your app, as you would expect. See https://developer.android.com/studio/publish/app-signing.html for more info.
It's not that you cannot modify the app; it's that Android will not allow you to upgrade an app from version A to version B if the signatures of A and B were generated from different keys. If someone tampers with the app, the signature will be invalidated so they have to resign it with their own key. You should never give your key to untrusted people, since that would allow them to modify and resign your apps without changing the key.
Of course, signatures don't protect you from malicious modified APKs unless you already have an authentic version of the app installed that Android can compare the new version with. This is why you should refrain from installing APK files from unknown sources.
Can anyone please elaborate what is app signing in android and why it is necessary to upload an app to android market? Also tell me what changes it make to the application package/apk file.
Thanks in Advance
You sign your application with your private key so that ownership and the integrity of the APK can be verified.
https://en.wikipedia.org/wiki/Public-key_cryptography
https://developer.android.com/tools/publishing/app-signing.html
You might've noticed that in some cases a download has an associated md5 hash, that's a similar sort of thing although intended exclusively for verifying the integrity of the download.
In the old days, you checksummed your downloads against the provided hash just because your connection was lossy and crappy and files could get corrupted.
These days it's that and security.
One among many security concerns would be a nefarious actor taking over your Android Market account and uploading a hacked/virus-infected APK. Signing with a private key ideally reduces the odds this could happen successfully unless they've made off with your keys as well. By identifying you, via the keys, they're also protecting your users from the aforementioned scenario.
App signing is required to identify the author.
Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.
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.
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