1

Possible Duplicate:
Generating a unique machine id

I'm trying to build a licensing mechanism for a software we're building. We have a whitelist of machines that can use the software.

What parts of a machine are unique to be used as part of the fingerprint?

Community
  • 1
  • 1
Only Bolivian Here
  • 35,719
  • 63
  • 161
  • 257
  • 2
    Strictly speaking: **none**. If you want those that tend to work: MAC address of the NIC, BIOS serial number, disk serial number, various CPU properties ... and if you feel so inclined you can even combine them. Alternatively, give a definition of "a computer" ;) – 0xC0000022L Nov 26 '11 at 00:17
  • You mentioned those that I needed. I'm going to fetch each of those properties, combine them, hash them and save that hash as a valid authorized machine. – Only Bolivian Here Nov 26 '11 at 00:18
  • @STATUS_ACCESS_DENIED: You say, "strictly speaking", you mean two hard drives can have the same serial number? – Only Bolivian Here Nov 26 '11 at 00:21
  • no, I mean that one could clone (or restore from a backup) the system, exchange the hard drive and thus have a different hard drive serial number and suddenly your product wouldn't work anymore. Also, the serial numbers you often get to see from the OS is written into the partition table, so it can be manipulated. Too many unknowns. There is no absolute safety, so you should define the constraints of your question better ... – 0xC0000022L Nov 26 '11 at 00:27
  • @STATUS_ACCESS_DENIED: That's exactly the result I'm looking for. If a user changes any hardware aspect, the software should no longer work and they need to call us and ask for activation. Since this software handles sensitive data, this kind of scrutiny is expected. – Only Bolivian Here Nov 26 '11 at 00:34
  • well, then you have your answer. Still, "cloning" could be something as simple as restoring a backup after a drive crash. If that should mean that an activation is needed, fair enough. But that's a business decision, not a technical question ... – 0xC0000022L Nov 26 '11 at 00:39

1 Answers1

0

Your problem (access controls for the purpose of enforcing a software license) is similar to that of security/encryption in general. But the number one rule is: never roll your own crypto. I think that definitely applies here.

Consider how easy it is to defeat all of the identity mechanisms you might find. Then consider how easy it is to patch the binary to not execute the comparison that would drive it to execute the "your software is unlicensed" code. Now consider how easy it is to download a patch which does that for everyone in the world.

Now try to balance your desire to thwart the users who can't figure that out against the impact on your legitimate users who will find your software to be "broken" when they replace their failing hard disk (built with flood zone parts, e.g. :). How will your software react when you're on a platform with no NIC or disks (totally feasible, your software may last ages longer than any hardware API you use). Will it fail safe/paranoid, or fail compliant/trusting? Are you sure you really want to go ahead with this scheme?

If you indeed need a license mechanism, consider an algorithm to produce license identification strings instead.

Brian Cain
  • 14,403
  • 3
  • 50
  • 88
  • That's exactly the result I'm looking for. If a user changes any hardware aspect, the software should no longer work and they need to call us and ask for activation. Since this software handles sensitive data, this kind of scrutiny is expected. – Only Bolivian Here Nov 26 '11 at 00:35
  • @Brian: I disagree. The problem with those that are sold is that they tend to be already cracked. – 0xC0000022L Nov 26 '11 at 00:38
  • *shrug* famous last words (@SergioTapia). How about using an off-the-shelf node-locked licensing scheme (e.g. [flexlm](http://www.flexerasoftware.com/products/flexnet-publisher.htm) )? – Brian Cain Nov 26 '11 at 00:38
  • @STATUS_ACCESS_DENIED -- it sounds as if you're recommending [security through obscurity](http://en.wikipedia.org/wiki/Security_through_obscurity). – Brian Cain Nov 26 '11 at 00:40
  • 1
    @Brian: far from it. But I am a reverse code engineer and I know what's possible and how feasible it is. None, I repeat, **none** of the solutions entirely implemented in code are secure. And it doesn't matter which crypto-algo you propose, because they all fail on one end: if you don't trust the user, you must never give him the tools to access whatever you want to protect. So let's say you encrypt something and need to decrypt it on the user's machine, the (private) key must be somewhere on the machine. It seems you need to do some web searches to check what's cracked and what's not ... – 0xC0000022L Nov 26 '11 at 00:48
  • I don't see how getting the data from the hardware and creating a unique hash is security through obscurity. Can you elaborate? Mind you, this is just the initial authorization phase, the rest of the interaction between client and web service is handled through other means. – Only Bolivian Here Nov 26 '11 at 00:49
  • @STATUS_ACCESS_DENIED, of course everything you're saying is true -- it just makes my point. Why try? I only disagree with your conclusion that a new roll-your-own algorithm will somehow be inherently more secure than an off the shelf one. – Brian Cain Nov 26 '11 at 01:30