What exactly is the importance of signing an apk before releasing to the market?
From the Android Documentation for Signing Applications:
The 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.
The important points to understand about signing Android applications
are:
All applications must be signed. The system will not install an application on an emulator or a device if it is not signed.
To test and debug your application, the build tools sign your application with a special debug key that is created by the Android
SDK build tools.
When you are ready to release your application for end-users, you must sign it with a suitable private key. You cannot publish an
application that is signed with the debug key generated by the SDK
tools.
You can use self-signed certificates to sign your applications. No certificate authority is needed.
The system tests a signer certificate's expiration date only at install time. If an application's signer certificate expires after the
application is installed, the application will continue to function
normally.
You can use standard tools — Keytool and Jarsigner — to generate keys and sign your application .apk files.
After you sign your application for release, we recommend that you use the zipalign tool to optimize the final APK package.
The Android system will not install or run an application that is not
signed appropriately. This applies wherever the Android system is run,
whether on an actual device or on the emulator. For this reason, you
must set up signing for your application before you can run it or
debug it on an emulator or device
Why means:
Some aspects of application signing may affect how you approach the
development of your application, especially if you are planning to
release multiple applications.
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:
Application upgrade – As you release updates to your application, you must continue to sign the updates with the same
certificate or set of certificates, if you want users to be able to
upgrade seamlessly to the new version. When the system is installing
an update to an application, it compares the certificate(s) in the new
version with those in the existing version. If the certificates match
exactly, including both the certificate data and order, then the
system allows the update. If you sign the new version without using
matching certificates, you must also assign a different package name
to the application — in this case, the user installs the new version
as a completely new application.
Application modularity – The Android system allows applications that are signed by the same certificate to run in the same process, if
the applications so requests, so that the system treats them as a
single application. In this way you can deploy your application in
modules, and users can update each of the modules independently if
needed.
Code/data sharing through permissions – The Android system provides signature-based permissions enforcement, so that an
application can expose functionality to another application that is
signed with a specified certificate. By signing multiple applications
with the same certificate and using signature-based permissions
checks, your applications can share code and data in a secure manner.
Another important consideration in determining your signing strategy
is how to set the validity period of the key that you will use to sign
your applications.
If you plan to support upgrades for a single application, you should ensure that your key has a validity period that exceeds the expected
lifespan of that application. A validity period of 25 years or more is
recommended. When your key's validity period expires, users will no
longer be able to seamlessly upgrade to new versions of your
application.
If you will sign multiple distinct applications with the same key, you should ensure that your key's validity period exceeds the expected
lifespan of all versions of all of the applications, including
dependent applications that may be added to the suite in the future.
If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period ending
after 22 October 2033. Google Play enforces this requirement to ensure
that users can seamlessly upgrade applications when new versions are
available.
Why?
Developers can prevent someone from tampering with their app.
Sign to protect your app!
This works in the public key cryptography. You are the only one who has the private key. You are the only one who can sign your apps. The user can trust the app being directly from you. It is mathematically proven to be unfeasible to tamper with the app if the private key is not available.
You know, in public key cryptography there are two keys like the sides of a coin. The private and the public key. You keep the private key secret. You lock it away and keep it secure. On the other hand you publish your public key.
These keys are like the sides of a coin because what you encrypt with one key you decrypt with the other key.
And how is this applied for app signing?
Signing is encrypting with the private key.
Because you publish the public key the app store and the users have your public key. They can decrypt your app and therefore know for sure that the app is really your own. Android and the app store does this for them.
The app store verifies the signature by decrypting with the public key.
That's all, folks.
Sign Apk:
Generating a signed apk means to encrypt your apk with a password or a key that is known only to you and you have to remember this apk forever as if for any further upgradation done on your app you have to access it with your app then.
Related
I have the following scenario:
We have a critical app that's distributed through apk download from our own servers (not Play store). The app updates itself, and another app, by downloading and installing the apk (with android intent). Both these apk's are signed by our company's code signing key.
The problem:
The signing key will expire in 5 days, and we couldn't renew it, as it's 2048 bit RSA. According to some CA/Browser forum document:
Baseline requirements for code signing
But if we change the private key to 3072bit RSA, android will reject to install (this I understand):
Package com.whatever.myapp signatures do not match previously installed version; ignoring!
Is there any way of making it less painful for the users than uninstalling and reinstalling the app? (It's distributed nationwide, to more than 1000 clients, who aren't able to do this).
Changing the package name would mean a clean db for the clients, so it's not a feasible solution. Is this true, that I cannot get a valid signature for the 2048bit RSA private key? Are there any solutions?
Thanks in advance!
Keys don't expire, but certificates do (or at least they have a NotValidAfter field). That being said, Android does not verify the validity of the certificate, it only enforces that the certificate remains the same byte-for-byte, so technically, having an "outdated" certificate will have no impact on your users.
If you still want to change the key, you'd have to use key rotation (https://source.android.com/security/apksigning/v3) which is a feature that was introduced in Android 9, so only users on Android 9+ would be able to verify the signature with the new key while users on older devices would keep verifying the signature from the old key.
I knew it's only for managing application in google play store.
But are there also other reasons to protect code from the decompiler?
I wonder what is the right answer for this question in the interview.
Anyone, who let me know the reasons why we should sign the application?
if you're asking why would we sign an apk, well a digital signature is a method of demonstrating the authenticity of a digital file, such as a document, message or in this case an apk, which is really just a collection of files.
so by signing an apk, we are effectively creating a way of ensuring that whoever makes use of the apk gets a verifiable copy of the file they were expecting to receive. This has obvious advantages in terms of security, as others can't make changes to this file whilst maintaining the same signature.
From the docs :
There are several reasons why you should do so:
App upgrade: When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the
existing version. The system allows the update if the certificates
match. If you sign the new version with a different certificate, you
must assign a different package name to the app—in this case, the user
installs the new version as a completely new app.
App modularity: Android allows APKs signed by the same certificate to run in the same process, if the apps so request, so that the system
treats them as a single app. In this way you can deploy your app in
modules, and users can update each of the modules independently.
Code/data sharing through permissions: Android provides signature-based permissions enforcement, so that an app can expose
functionality to another app that is signed with a specified
certificate. By signing multiple APKs with the same certificate and
using signature-based permissions checks, your apps can share code and
data in a secure manner.
If you plan to support upgrades for an app, ensure that your app
signing key has a validity period that exceeds the expected lifespan
of that app. A validity period of 25 years or more is recommended.
When your key's validity period expires, users will no longer be able
to seamlessly upgrade to new versions of your app.
If you plan to publish your apps on Google Play, the key you use to
sign your app must have a validity period ending after 22 October
2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade apps when new versions are available.
My Google developer account holds now 5 different apps in it, 4 of them were created before the new Google App Signing was released, and they all 4 share the same certificate. When I created the last app I followed the steps to create a new key and now that one works "separatedly" from the rest of apps, with its own release key.
I'm wondering if I could use the same recently created release-key.jks that I'm using to sign the last app for the rest of applications.
Also in case I could, which of the three options that the App Signing page of the Google Play Console offers me should I choose to upload it?
"You've exported your app signing key"
"You haven't exported your app signing key"
"You don't store your app signing key in a Java Keystore"
I'm a bit lost here and I don't want to mess things up by not being able to release more updates in a future.
Thanks beforehand!
You should use the same key you signed it with for the first time
According to https://developer.android.com/studio/publish/app-signing#considerations
You should sign all of your APKs with the same certificate throughout
the expected lifespan of your apps. There are several reasons why you
should do so:
App upgrade: When the system is installing an update to an app, it
compares the certificate(s) in the new version with those in the
existing version. The system allows the update if the certificates
match. If you sign the new version with a different certificate, you
must assign a different package name to the app—in this case, the user
installs the new version as a completely new app. App modularity:
Android allows APKs signed by the same certificate to run in the same
process, if the apps so request, so that the system treats them as a
single app. In this way you can deploy your app in modules, and users
can update each of the modules independently. Code/data sharing
through permissions: Android provides signature-based permissions
enforcement, so that an app can expose functionality to another app
that is signed with a specified certificate. By signing multiple APKs
with the same certificate and using signature-based permissions
checks, your apps can share code and data in a secure manner. If you
plan to support upgrades for an app, ensure that your app signing key
has a validity period that exceeds the expected lifespan of that app.
A validity period of 25 years or more is recommended. When your key's
validity period expires, users will no longer be able to seamlessly
upgrade to new versions of your app.
If you plan to publish your apps on Google Play, the key you use to
sign those APKs must have a validity period ending after 22 October
2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade apps when new versions are available. If you use
Google Play App Signing, Google ensures your apps are correctly signed
and able to receive updates throughout their lifespans.
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 have made two versions of my application, a "large" version, and a "mini"/"lite" version.
Should I be signing both of these with the same key? Or should I sign with a unique key for each of them?
What are the repercussions of signing multiple applications with the same key?
Please sign your apps with the same certificate only in case you need to share data, or other resources. Some disadvantages of signing with the same certificate:
If your app certificate is compromised, all your apps are in danger. Certificate holder can create fake updates for your apps to steal users data etc.
If you wanna sell one of your apps, you have to compromise your certificate to the buyer.
If you lose your certificate, you will be unable to make updates for all your apps. You will be forced to create new packages (new apps) for all of them.
If one of your apps has signature level permission, or allows user id sharing, all your apps can take advantage of this!
Happy signing!
Signing is used mainly to identify an application's developer. If anything, you're suppose to sign all applications you make with the same key.
The 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.
Read everything here:
http://developer.android.com/guide/publishing/app-signing.html
Signing the applications with the same key allows them access to each other's data.