Confused about encryption with public and private keys (which to use for encryption)

Question

I am making a licensing system when clients ask my server for a license and I send them a license if they are permitted to have one.

On my current system I encrypt the license using a single private key and have the public key embedded into the client application that they use to decrypt the license. It works!

Others have told me that I should be encrypting with the public key on the server and distributing the private key to clients. I have searched the web and can see that sometimes they use the private key to encrypt and other times they use the public key to encrypt.

In this case what am I supposed to do?

Answer 1

Others have told me that I should be encrypting with the public key on the server and distributing the private key to clients.

Those people are wrong. The name private key implies that it is private meaning that only you should have access to it.

In this case what am I supposed to do?

Use digital signatures. Sign the license file with your private key and use your public key in your application to verify that the signature on the license came from you.

Answer 2

If you are using public-private (asymmetric) encryption, you always encrypt with the recipient's public key, who decrypts with their private key. For digital signatures, you sign with your private key and the recipient verifies the signature with their public key.

The question then arises, how do you make a secure DRM system? If you use encryption, and give the recipients a private key, they can distribute either the key or the decrypted content. If you use signatures, they can simply strip out the signature verification part of your program.

The answer is that it's impossible. The concept of DRM is fundamentally flawed.

Answer 3

If you are encrypting something that is only to be read by a single recipient, then you encrypt with that recipients public key and they use their private key to read it.

If you are encrypting for multiple recipients, then you can encrypt with your private key and distribute your public key to those which you want to be able to read it. This is usually called "signing" as anyone who has access to your public key can read it, so it's not really a form of private communication.

An overall more robust solution for you would be for your app to generate a key pair per installation, send the public key that it generated back to the server, which you would then use to encrypt so that only that single install could use the license that you created (by decrypting it with its private key).

Answer 4

At least in a typical public key encryption algorithm (e.g., RSA) there's not really a major difference between the public and the private key. When you generate keys, you get two keys. You keep one private and publish the other -- but it doesn't matter much which one you publish and which one you keep private.

Anything you encrypt with one key can be decrypted with the other key. For normal purposes, you publish one key, which lets anybody encrypt something that only you can decrypt. From a technical viewpoint, the reverse works fine though: if you encrypt something with your private key, anybody with the public key can decrypt it. This is typically used for things like signature verification (i.e., anybody with the public key can verify that the signature had to have been created with the private key). You usually want to use separate key pairs for encryption and signing though.

For your case, it's open to some question what you're really going to accomplish. You can certainly encrypt some data necessary to use the program, so the user needs the key to decrypt it and use the program -- but if the user is willing to give a copy of the code to an unauthorized person, they probably won't hesitate at giving a copy of the key to them as well. As such, even though the encryption/decryption will do it's job, it's unlikely to provide any real protection.

A more typical licensing scheme is tied to something like a specific IP address, so you do something like encrypting the IP address, then use the result as a key to decrypt data necessary to use the program. If the IP address is wrong, the data isn't decrypted correctly, and the program doesn't work. As long as the user has a static IP address this can work well -- but will cause problems in conjunction with DHCP.

My immediate advice would to just not do this at all. If you insist on doing it anyway, don't do it yourself -- get something like FlexNet to handle it for you. You're better off without it, but at least this way you'll get something that sort of works, and you won't waste time and effort on it that could be put to better purposes like improving your software.

Answer 5

Congratulations, you just invented the RSA signature. (Which is what you should be using, anyway.) To communicate with a public key system, you need to use the private key once and the public key once, but RSA supports two different orders: 1) Encrypt with the public key, decrypt with the private: The recipient doesn't know anything about the source of the message, but the sender knows that only the recipient (the holder of the private key) can read it. This is classical "encryption". 2) "Encrypt" with the private key, then "decrypt" with the public. This is a digital signature, and provides authentication. Anyone can read the message, but only the private key holder could have sent it.

Assuming your license is customized to the client (which could be as simple as including a copy of a client-generated random number), then it's useless to anyone else, but the client can be sure that the server sent it.

The symmetry isn't quite that neat in practice; the different modes of operation have different weaknesses and gotchas, so the implementation is typically significantly different, but that's the general idea.

One of the first and most important lessons in cryptology is understanding authentication and when to use it. It's needed at least as often as encryption, and not knowing when to use it leaves you in a Midvale School for the Gifted situation.

Answer 6

I'm with Jerry. People have already figured this all out, and developed, tested and documented a solution. Another option for you is Agilis.

Dominic

Answer 7

Hope this link from wikipedia helps. PKI is based on mutual trust. However the private key has to be protected by the owner. Public as the name implies is open to all. The entire architecture is made inorder to help the scenario as defined above in your question.