开发者

Implementing node-locked license: public fields with signature versus complete encryption

Background

I need to implement a simple node-locked licensing mechanism (i.e. the license needs to be valid only for a specific physical computer).

I intend to use an asymmetric cryptographic algorithm such as RSA.

Here is how I intend to organize the basic licensing "workflow":

  • The application that needs to be licensed reads a piece of data that uniquely identifies the computer (it is currently running on). Let's call this data "computed ID".
  • User requests the license by sending the computer ID.
  • Based on the computer ID, the license is generated and protected (either by full encryption or by signing) and sent back to the user.
  • The application can then compare the license with the actual computer ID and refuse to run if they do not match.

Note that computer ID will not be particularly sensitive (probably just a MAC address and possibly HD serial) and does not represent a secret on its own.

Question

The dilemma I have is whether to:

  1. encrypt the computer ID (both in the license request and in the license itself),
  2. or to include it as a plain text (in both request and license) and just add a signature (in license).

(1) If I choose full encryption, then I'll need two pairs of public/private keys - one for each direction (one for encrypting the request and decrypting it before generating license; and one for encrypting the license and decrypting it by the application).

(2) If I choose to use signatur开发者_开发知识库e, I just need one key par - private key for signing the license and public key for verifying the signature when application runs (so it knows the plain text computer ID in license did not change).

The approach (2) looks simpler to me, but is it as "strong" as (1)?

I'm implementing this in C#, but I'd like a general "high level" advice on pros and cons of each approach, regardless of the implementation details.


Since this is my area of expertise, let me jump in... It seems you are trying to create your own activation system starting from scratch. May I ask why you are doing so, rather than just using a commercial system?

In the early days of using activation to protect software licenses a number of companies took the approach of developing their own systems without having deep expertise, and their ignorance of what it took to make a secure, user-friendly activation system gave activation a bad name. So, in the interests of helping you not have to painfully re-learn these lessons and irritate your customers, here are some of the things you need to think about:

  • How will users activate their license if they don't have a network connection to the server, or their connection is blocked by a firewall?
  • You said you are node-locking your application to some parameters of the user's system. How will you deal with someone who makes a minor upgrade to their system, causing a node-locking parameter to change? Note the MAC address is not a good choice for this, even though it is commonly used, as the ease with which the MAC address can be configured on some systems means MAC-address node-locking is insecure.
  • A user's system crashes - how can they get their license running on another system? (and how can you know they are telling the truth about their system crash?)
  • What if a user wants to move their license to another machine after a while, say from their desktop to their laptop. Can your system allow them to do this without it being a security hole or an annoying manual process requiring your support?
  • How will you secure your licenses against key tampering, spoofing or tampering with the licensing code etc?
  • From your post it seems you just want to enable the whole application for now. What if in future you want to activate time-limited trial or subscription licenses, configure product features or enable certain modules etc. Will your activation system support this or will you have to re-build it?
  • Some companies don't want any clear-text information about their systems going over the Internet, so you may want to encrypt the uploaded system details from the get-go.

Just some things to think about.


As your computed id works only on the machine where the computed id can be reproduced it is actually not really a problem if you transport the computed id as plaintext. even if somebody steals it, he wont be able to use it. If somebody manipulates it through the transport you will recognize it too (as it is signed)

But: it depends what kind of computed id you generate. If you dont use a appropriate algorithm someone could get some information about the system on where the computed id got generated (which wouldnt be appreciated by your licencees) For that you should use a "save" hash function with no (or non predictable) collisions.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜