6

The documentation for application licensing describes LICENSED_OLD_KEY as meaning:

The application is licensed to the user, but there is an updated application version available that is signed with a different key.

On the other hand, the documentation for signing strategies says:

If you sign the new version without using matching certificates, you will also need to assign a different package name to the application — in this case, the user installs the new version as a completely new application.

Since applications are identified by their package names, this seems to say that you can't change the signing key for a published application. (Rather, you can change the key and package, but then it will be treated by the market as a new application.)

I can't think of a scenario where it is possible to receive a LICENSED_OLD_KEY response. Am I missing something?

dolphin
  • 1,192
  • 10
  • 27
Ted Hopp
  • 232,168
  • 48
  • 399
  • 521

1 Answers1

3

The documentation states that LICENSED_OLD_KEY

...can indicate that the key pair used by the installed application version is invalid or compromised.

Looks like this code was added for cases where a private key is leaked or can otherwise be no longer trusted. Since the current IPC mechanism doesn't even know which public key is used on the client side, I would guess that the whole package name gets tainted. The idea is that in this case an app should ask a user to upgrade to the new version which isn't tainted and should presumably already exist. Since this upgrade would require switching to a whole new different package, how this is supposed to be done is unclear. My guess is that this mechanism isn't really used at all at this point, so the chances of getting this code are very close to zero. In the current version of the official LVL library this code is treated the same way the normal LICENSED response is.

p.s. Also please note that you confuse the keypair used for signing your apps and the keypair used for the LVL service. Those two are completely different and unrelated. Interestingly, with the latter keypair you don't even get to know the private key at all. You get your own pre-generated public key (one per developer) from your publisher console, and that's all you get.

dragonroot
  • 5,653
  • 3
  • 38
  • 63
  • I see what you're saying. But if you're right, then the documentation is (to be generous) misleading. I'm not the one confusing the keypair used for signing apps with the keypair used for the LVL service: the docs seem to clearly say that LICENSED_OLD_KEY has to do with how the application is signed, not how the LVL transaction is encrypted. (If the LVL keys were compromised, presumably a new version of the app using a new LVL key pair could be published without changing how the app is signed.) – Ted Hopp Dec 18 '11 at 03:57
  • Ted, could you post a link to the part of docs which says that? I highly doubt that the Market component even looks at the cert of the app when it performs LVL - at least I can perform the check with both the standard debug cert and the real cert used on the Market. – dragonroot Dec 19 '11 at 03:07
  • FWIW, yes, the docs are misleading - this topic wouldn't have existed otherwise. – dragonroot Dec 19 '11 at 03:08
  • I thought that the first text cited in my post was saying that: _"there is an updated application version available that is signed with a different key."_. – Ted Hopp Dec 19 '11 at 03:24