Rethinking rsa encryption of license keys

[Igor de Oliveira Couto]

Dr. Hawkins, I apologise for coming in late to this discussion, but let me see if I can be of some assistance.

SYMMETRICAL encryption has 1 main purpose, which is to 'hide' data in an encrypted format.

ASYMMETRICAL encryption, on the other hand, has 2 purposes: hide data, and *sign* the data - which is really its main purpose. 'Signing' data serves 2 purposes: proving where the data came from, and that it has not been modified since it left the source. Now, *that* is useful.

In asymmetrical encryption, the private key is used to *sign data*, and the public key is used to *verify the signature* - that is, that the data really came from that source, and that it has not been modified during transit. If a single bit is changed in the data, then the public key will not verify it. The private key can sign data that is encrypted, or data that is not. It does not matter, so 'signing' is a function totally separate from 'encryption'.

The way this is used in registration systems is like this:

1) Company 'A' produces software, and the software has the company's PUBLIC KEY built into it.

2) The client downloads the software, tries it, and buys it. 

3) Company 'A' produces a license file, which is *signed* with the company's PRIVATE KEY.

4) Client puts the license file in with the software, When the software starts, it checks that the license file exists, and uses the PUBLIC KEY to make sure that it was Company 'A' who issued it.

The only problem with this kind of system, is that your client might then share their license file with all their friends, or put it on a torrent server. So, in order to try and avoid that, Company 'A' will usually put some personal client information in their license file - like client name, the MAC address of their computer, etc.

Then, in step 4 above, when the software launches, it will:

* use the PUBLIC Key to check that the data really came from Company 'A' (so if someone tries to change the username or the data in the license, it will not pass the check)
* then check that the information on the file matches the user/computer information in the current system.

Note that the license file does not have to be encrypted: it only has to be *signed*, and it is up to the developer to choose whether they want to make the license file human-readable or not.

Asymmetrical encryption has a variety of applications that go beyond software registration - ie., it is how 'secure' communications work on the internet (SSL certificates use public/private key pairs to verify the source of the data, and that it hasn't been tainted during transmission). The famous GPG software uses private/public key pairs to sign (and optionally, encrypt) your email and computer files: you keep your private key, and distribute your public key to your friends and contacts. 

Implementing these systems does add another layer of complexity to your software, so it is always a good idea to establish quite precisely what your needs are, and what problem you think this encryption layer will solve. It may be that there is a simpler, alternative - like simple server authentication - that may be more recommendable. It all depends on your specific use-case.

I hope this information helps.

Kind regards,

--
Igor Couto
Sydney, Australia