19

When exporting a signed Android application using Eclipse, is there a purpose to using multiple aliases?

According to the official guide about signing, it's recommended that you sign all applications with the same certificate to allow your applications to share data, code and be updated in modular fashion.

Assuming that "alias", "key" and "certificate" are essentially interchangeable in this context, is there a reason why someone would want to use different aliases for all their applications? The only reason I can think of is that it adds more security to your applications, in the sense that a compromised key/password doesn't compromise everything. Are there other reasons?

Also, is the generated key dependent on the name of the alias? In other words, if you change the name of the alias but not the password, would the generated certificate be different?

Sufian
  • 6,405
  • 16
  • 66
  • 120
Steve Haley
  • 55,374
  • 17
  • 77
  • 85
  • I recently ran into this question and for those who are looking, I believe that the accepted answer is incorrect. Please see my answer below for clarification. – Tony Chan Oct 12 '11 at 09:37

3 Answers3

16

Correct me if I'm wrong but if you'll see this answer to a similar question you see that the certificate does indeed depend on the particular "alias" (within your keystore) that you choose to sign with.

Read the answer carefully and you see that the "keystore" contains "alias"s (which are actually private+public key pairs). When you sign your apk it is the "public key" that is the actual certificate being embedded.

Therefore when updating your app you should always use the same "alias", not just the same "keystore". As for why devs would have multiple "alias"s in their keystore, I'm uncertain of the benefit other than what you and others have stated.

And the only way you can sign with a different alias would be to clone the previous one as the answer also suggests.

I have also confirmed that signing an APK with different alias's (from the same Keystore) will generate different APK signing signatures which should be proof that different "alias"s = different certificate. How to get your signing sig (<- note: I don't know what the Trace.i method they refer to is, I used Log.i instead)

Community
  • 1
  • 1
Tony Chan
  • 8,017
  • 4
  • 50
  • 49
  • I have to agree that the accepted answer can be misunderstood. After further research I understand that an "alias" is just a "name" to a key entry in the keystore. Creating a key with alias 'key1' and another key in the same store with alias 'key2', does not make them interchangeable. Although you can change the alias (name) or password on either and not affect their signature they are ultimately two separate keys. They are NOT aliases to the keystore itself. – JRomero Apr 24 '13 at 19:59
  • 1
    I confirm that signing with single keystore but different aliases creates different signing signatures. Even Android marketplace doesn't allow you to add multiple APK's signed with different aliases. – Grigori A. Jun 05 '13 at 08:33
  • @Turbo I made an amendment to the the accepted answer that I think makes things more clear. – Bruno Bronosky Mar 18 '15 at 16:15
  • When I came to this thread years ago I agreed with you. Now that I have more experience, I find problems with your answer. You are (in fairness, just as the OP stated) assuming that the *alias* is the key pair. However, the answer you reference states that the alias is just an identifier for the "keystore entry" (aka: key). I'd like to see your answer modified to s/alias/key/g and include a single definition for alias. **Alias** - An arbitrary and changeable identifier for a key or key pair and its content. (Note: You can add a solo public key and use it strictly for verifying signatures.) – Bruno Bronosky Mar 18 '15 at 16:35
9

Do be aware that by signing the apps with different keys you are sacrificing "signature-based permissions" interoperability between your apps.

Excerpt from Android - Signing Your Applications - Signing Strategies

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.

Bruno Bronosky
  • 66,273
  • 12
  • 162
  • 149
  • I just got 2 down votes and no comments. Thanks! The SO community appreciates your contributions. – Bruno Bronosky Jan 12 '16 at 16:07
  • But do they really need interoperability. Like we can understand for Gmail and Inbox. They need to talk to each other. But do Calculator and say Whatsapp need interoperability? For the 2 different types of apps which may never want to communicate to each other, what is the benefit of signing them with the same key? – kirtan403 Nov 29 '16 at 09:38
  • "But do they really need interoperability?" That's for you to decide. I just want you to have the information so you can make an informed decision. I worked for a media company that had dozens of TV and Radio stations. Each had multiple apps (live streaming, weather, traffic, alarm clock, etc.) because they were developed by different teams or vendors. They needed to interoperate. You DO NOT WANT to release apps then later realize interoperation is impossible without getting users to install a differently signed app (aka: not an upgrade, link the user to a new install) – Bruno Bronosky Nov 29 '16 at 17:08
  • 1
    Really useful bit of information - and although somewhat tangential to the actual question, quite relevant to the topic. Just to let you know that at least one member of the SO community appreciates your contribution! – Thailandian Feb 21 '17 at 15:09
3

I was doing some testing, and although it seems to matter which key you use in the keystore, changing the alias on the key and the name of the keystore file doesn't really seem to matter to the handset. If you're curious, I changed the alias with keytool-iui that I got from here: http://code.google.com/p/keytool-iui/

To answer the OP, I would say that it is useful if you work in a large company with multiple divisions writing their own apps. So Wilson's Widgets could have a keystore of wilsonwidgets.keystore, and there could be an internal department with a "widgetmakers" key, and a department with a "widgetdelivery" key, and another department with an "hrdepartment" key. Each department could prevent the other department from updating their app, but the company itself has all of the keys stored in one keystore that can be backed up to one location.

Personally, I sign each app with a different key store them all in the same keystore. I do that so if Google decides to buy one of my apps from me I can break off that one key and give it to them without having to sell them the whole lot or regenerate keys for the other apps. Realistically... I'm just wasting time and effort... sigh

Bryan
  • 63
  • 6
  • 1
    Do be aware that by signing the apps with different keys you are sacrificing "signature-based permissions" interoperability between your apps. I couldn't fit my comment in here so I posted it as an answer. I'm up voting you anyway – Bruno Bronosky Mar 12 '13 at 18:47