How (cryptographically, technically) sound is this software activation/license validation scheme?

Question

I heard someone give a marketing pitch today regarding a framework that they are selling to prevent application piracy (which I know, you cannot). Here's the high-level overview:

Registration Process:

• Phone encrypts using the server's public key: the mobile phone's IMEI number and the installed application's unique ID (assigned by the app developer) to the server i.e.,

  Reg_request = Encrypt(Server_PublicKey, (IMEI||AppID))

• Service decrypts Reg_request using a decryption function and its own private key to extract IMEI and AppID

• Service then asks the user for payment. Upon payment, the Service generates an activation serial number based on IMEI||AppID
• Service then encrypts the generated serial number with the smartphone's public key and then sends this to the user.
• Upon receiving this, the application decrypts it using a decryption function and the private key stored on the smartphone to obtain the serial number.
• For activation, the application passes IMEI||AppID to its own hash function to get a temporary validation serial number.
• If this number matches the serial number received from the server, the activation is successful.

I have little knowledge of crypto but this looks like traditional Public-key cryptography to me. How sound is this approach or rather how difficult will it make it for the attacker to break this? And, do conventional desktop-based software use more sophisticated approaches?

Answer 1

Asymmetric crypto has at least one advantage when it comes to license key generation. The private key can be used to encrypt license data and generate the license key while the public key is used to validate the license data. The private key will be kept private and is only used by the license generator or the license activation service. Using this method, it won't be easy to create "key generators" for anyone who is trying to tamper with your app.

In the end though, one should understand that it is extremely difficult (if not impossible) to create a scheme that can completely prevent piracy. You can only discourage end users from performing a "Casual Piracy."

Answer 2

The scheme you described represents nothing special, and in fact the semantics wouldn't change at all if you replaced all the public key cryptography with something like HTTPS.

My guess is that this is an instance of the classic case where managers instruct developers to add cryptography to the product to make it more secure or simply because it sounds cool, but neither of them are actually familiar with cryptography.