Hello, I'm taking a security class and required to implement a licensing server that send licenses that are non -transferable. I have no idea how to do that, could you please give me some of your ideas. Regards,
+3
A:
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.
Ukko
2010-04-29 19:21:54
I agree but the mac address can be changed :(http://www.topbits.com/how-to-change-a-mac-address.html
2010-04-29 19:48:45
I used "scare quotes", a parenthetical aside, and a bunch of modifiers to point out that fact. But pedagogically it is a great example (c.f. http://en.wikipedia.org/wiki/Lie-to-children).If you need to have a nit proof solution then the answer is easy, no such solution exists.
Ukko
2010-04-29 20:00:52
I guess, you don't know the solution. there must be always a solution
2010-04-29 20:06:14
There does not have to be, think about the steps that you are doing. You always have to authenticate something to establish identity, and that authentication can be spoofed. You can change the MAC address and thwart MAC based identification-so what? You have asserted that an unspoofable mechanism exists, that is a tall order, one that has never held to date.As for not knowing the solution I gave you one in my original answer. You step now is to recognize it and see hoe to apply it to your homework. There may well be better answers but it is an answer nonetheless.
Ukko
2010-04-29 20:27:40
Every protection can be cracked, every DRM hacked, every MAC changed and every safeguard 'rearranged'. There's nothing guaranteed, nothing airtight, have another read - Ukko's absolutely right.
Allon Guralnek
2010-04-29 20:28:32
ok thanks a lot for the solution
2010-04-29 20:52:39
+1
A:
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?
bgiles
2010-04-29 21:43:14