views:

278

answers:

7

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?

+5  A: 

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.

Kevin
This is wrong. For asymmetric encryption, you encrypt with the recipient's public key.
Matthew Flaschen
@Matthew I didn't say otherwise. I said that he should *not* be distributing his private key.
Kevin
so in my case what should I be doing? Assuming I will be using the same public and private key for all clients.
jax
@jax use digital signatures.
Kevin
@Kevin, distributing a public key and using signatures won't work either. Then, people will just strip the signature verification from the executable.
Matthew Flaschen
@Matthew Now you're arguing a different problem. For a small software shop, few people, if any, will go that route. If they do, he has legal recourse to stop it. Licensing has other uses besides simple DRM.
Kevin
Kevin is correct, but I also note that it is exactly what the OP has been doing all along. "Encrypt with private key" == sign. And since this is a DRM scheme, there is no real security at all, which is Matthew's last point.
GregS
@GregS: "Encrypt with private key" does **not** equal "sign". In RSA, the basic operation underlying each is the same, but the method of use is completely different. Treating signing as "encrypting with the private key" is a good way to get an insecure system.
caf
@caf: No, that is *exactly* what signing is. Read the original RSA paper. Of course it is not a complete description of a secure system, but merely a short SO comment-sized explanation to aid the OP.
GregS
@GregS: "Encrypting" something is obscuring it to provide secrecy; this has nothing to do with signing. The OP is already confused between signing and encrypting, and saying that encrypting and signing are the same thing is only likely to reinforce the confusion.
caf
@caf: I agree that I should not confuse things more, not for the OP nor for others that may follow. IMO, I was clarifying.
GregS
A: 

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.

Matthew Flaschen
A: 

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).

Donnie
Signing is not encryption, period. People can read the message even without your public key. They only need that to verify the signature. And there is nothing in your "robust solution" to prevent people sharing private keys.
Matthew Flaschen
Matthew, you need the public key to verify the message.
GregS
@Matthew- I said "more robust", that's a relative assertion, not an absolute one. As you noted in your answer, any DRM is doomed to failure if someone wants to bypass it enough, the idea is to keep casual people honest, not be completely secure.
Donnie
+1  A: 

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.

Jerry Coffin
A: 

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.

Cypherpunks
A: 

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

Dominic
A: 

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.

Praveen S