Implementing a program that generates non-transferable licences

I'm taking a security开发者_StackOverflow中文版 class and am required to implement a licensing server that sends licenses that are non-transferable. I have no idea how to do that. Could you please give me some of your ideas?

You need to find something to tie the license to that is unique and immutable for sufficiently realistic values of unique and immutable. The canonical example is the network adaptor's MAC address. This address is usually set at the factory, "cannot" be changed, and is globally unique. (Did I hedge that enough to keep the nit-picker at bay...?)

Once you have this identifying info making a non-transferable license is pretty easy, you basically have a trusted authority sign the address and use that as the license. If you want to check that a machine is the one you are licensed to run on you just check to see if the signature is OK using the public part of the key.

If you can assume web access you can require the user to log in to a central server. It sends back a token referencing the user id as described in the other answer, plus a time range when it's valid. The idea is that you don't want to require continuous web access, just access once an hour or day or whatever your risk tolerance is.

Ideally this is done behind the scenes, e.g., using an initial token obtained from the server when the user first registered their product. Your app uses this token to log into the central server for an operational token, nothing is ever done in cleartext with user names and passwords.

The benefits: this is not tied to the physical hardware like a MAC address (network card). It REALLY pisses off users when they're told that they'll lose everything because they replaced their hardware.

The drawback: a knowledgeable attacker could copy the token to additional systems. However there are three ways of dealing with this:

• personalize the application. "Chris" is probably not going to be happy if the application keeps referring to him as "Bob".
• only allow one active instance at the server. Be careful though - this might lead to 'denial of service' attacks on your users. Or just frustration if they can't access the app at home because they forgot to log out at work.
• live with it. What's the cost of lost sales vs. the cost of implementing something stronger and/or pissing off honest users?