#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2007
    Location
    US
    Posts
    105
    Rep Power
    54

    Product Key Algorithms


    Hello,

    I've been considering different algorithms to apply in product key generation and licensing for commercial software and have a question. I have found some articles and examples on partial serial number verification where a seed is sent somewhere in the product key to be used with the function that is partially compiled in the software.

    Before researching the topic I thought a good solution might be to use asymmetric encryption. Use some plaintext as the seed and combine with the private key to create the cipher which would be stored on the user's computer. The software would be shipped with the public key and algorithm but with a minor addition that would convert the cipher to hex or hash it. This hash would match the key the user enters in after first verifying the cipher is valid with the public key.

    While I understand that the psnv protects against mass generation of fraudulent keys, I really don't see how it protects a single product that well. So I guess the question is, would it be harder to reverse engineer a partial serial number verification system or forge a cipher that could be verified with a public key. Let's take a well written psnv algo and rsa for example.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2007
    Location
    US
    Posts
    105
    Rep Power
    54
    I guess I should include that the product key would be checked over the network once to ensure that it hasn't been used before. Obviously, (not so much for me the first time thinking it through) if the program found a cipher stored it would try and match that which would allow the same cipher to be accepted, since the network check would be bypassed by the presence of a cipher.

    So would it be of any use to use the hashed cipher for the seed or shifted byte string?
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2009
    Posts
    191
    Rep Power
    50
    I won't pretend that I understand with any clarity the concept you have in mind -- for me, it is much easier to read a little formal notation, such as

    E(k, H(x))

    or what have you.

    However, I have given a lot of thought to this class of problems, and even fielded a design of my own. In essence, software license enforcement schemes are a form of DRM (Digital Rights Management), and like all DRM schemes implemented on general-purpose computers, are extremely vulnerable to hacking. I don't believe that any such system can be made secure.

    Still, one can hope to choose an "optimal" scheme with relatively high effort to break.

    The incorporation of a network check -- that is, a verification performed by a computer that is (hopefully) not under a potential adversary's control -- is an advantage. In such a case, if a unique number is assigned to each license, the "license key" can be the digital signature of that unique number. If the signature scheme is secure, then keys cannot be forged, and the network verification can ensure that they are not re-used (though this in itself can get tricky).

    But the network verification can easily be bypassed by suitable patching of the executable(s). So such a scheme may be useful for an application that requires installation-specific interaction with a network service under control of the software vendor. If the app doesn't fundamentally rely on some data from the network server in order to do its job, it can be patched to skip the network check-in. If the data from the network server is vital, but not installation-specific, it is only necessary for an adversary with access to a single paid license to make a record of the interaction, which can become the basis of a published crack. It doesn't help much to encrypt the data sent from the network server with a license-specific key, because the application must be able to decrypt it, and any hacker who knows how to use debugging tools will be able to extract the plaintext.

    So, in this old programmer's opinion, unless the nature of the software application is such that it requires customer-specific data from the vendor, any license key enforcement mechanism can be broken.


    PS I hope my above-mentioned design is secure, because the highly specialized product is a communication device whose function requires constant interaction with a computer that is beyond the adversary's reach. Most situations aren't so tightly constrained, so my "trick" lacks general applicability.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2007
    Location
    US
    Posts
    105
    Rep Power
    54
    Thanks for the reply,

    I know it helps to see the technical pieces instead of just hearing the theory. For starters this is one of the several articles I've breezed over.
    Implementing PKVS
    That's just a start. I've also digged into other commercial examples.
    I see two areas of attack. The software and the values stored outside of the software. I've only skimmed the surface of cryptography but I still fail to see how the above example protects from somebody copying the program and values saved to get it running on a different computer. I do credit it as a huge step towards limiting the damage to a single cracked copy and its copies. As far as the network check goes, I don't see how it could become immune to the same attacks as the software. Obfuscators can help to an extent but most free solutions only remove comments, encrypt the variable and function names, but somewhere in the program there is probably going to be display messages for the end users.
    unless the nature of the software application is such that it requires customer-specific data from the vendor
    Each program would be a specialized compilation per purchase? Or maybe the user's details are used for a match over the network to unlock the program? by assigning a value to store outside of the program? Say the network check provides vital parts and is installation specific, would it be recompiling the program, adding another compiled program to interact with the current one, or once again stroing values to allow it to run?
    I see the only way to keep a program to a single machine is to rely on the hardware ids. A digital signature seems to just be an additional feature in the DRM. If my assumptions are correct, then DRM truly relies on the integrity and relationship of both the provided hardware id and provided encryption/decryption function. So what is the best way to give a computer all required resources to decrypt the product key to match the hardware id (of course the hardware id is still welcomed to be encrypted towards a match) without giving the user the ability to encrypt a hardware id into a product key?

    I've read an assymmetric algorithm that allows 2 public keys to be used for both encryption and verification. Only the private key may decrypt.

    Generalized Example:
    2 magic primary #s are used: N and E so that N > E.
    the plaintext is taken to the power of E then mod N.
    This produces the cipher.
    The cipher is then decrypted with another primary P
    by taking the cipher to the power of P then mod N which
    results in the plaintext.

    I wonder if it would be possible to store P and N on the user's computer knowing E is required for the key generation. Then the next challenge is how to limit to a number of digits to make it user friendly.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2009
    Posts
    191
    Rep Power
    50
    To clarify my proviso about the requirement for customer-specific data: I mean something that is inherent in the nature of the application.

    For example, I know a software package with an extremely expensive license that has a vendor-database search feature. The database is very specific and technical, and for that reason is not practical to re-create. It is enormous, and constantly updated (this up-to-dateness is essential to its value), so a cracker can't simply "fetch a copy."

    Using this feature requires the application to connect to the vendor's server. I don't know that the vendor uses this connection as an opportunity to validate the user's license -- but they certainly could.

    But this server dependence is a natural feature of the application, not something you can just artificially plaster on to an app for security purposes. If an app gets part of its standard code or data from a server, a cracker only needs to spy on this transfer once, and can make a cracked version independent of the server. It doesn't matter if the stuff from the server is encrypted, even with a license-unique or session-unique key, because some part of the app must decrypt it before use, and a cracker can get this decrypted form.

    I took a glance at the linked article -- I wonder what is the author's security background. It's easy to construct a license key system in which the forging of licenses is impossible -- that's what public key signatures are for. But a cracker needs only one good key, in order to distribute thousands of unlicensed copies.

    Some more expensive packages use a hardware key (dongle), which (if done really carefully) may be impractical to duplicate. But a cracker can patch the application to skip the license checks.

    There are fancy (and costly) license schemes out there that imbed license checks in thousands of places within your application, encrypt blocks of application code, etc. etc. But a patient cracker using debugging tools can get past all of it.

    These techniques can increase the cost of cracking, but they cannot prevent it. The cracker will always get through.

    Maybe someday there will be welded-shut computing platforms that use tamper-proof hardware IDs and operating systems that will only execute signed executables. If this is accompanied by a draconian system of enforcement to prevent release of a parallel operating system that can run the executables without the signature check, then I suppose licenses will become inviolate. Until then, license schemes are like luggage locks -- they keep your friends out, but are transparent to real thieves.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2007
    Location
    US
    Posts
    105
    Rep Power
    54
    Thanks again for the reply and explanation,

    If half the program is secured on a server where it remains, then I can understand how an application of DRM would carry other concerns. Since every piece is not in the user's possession at once I'd say you have the advantage. In your case, hardware ids can help, but you would obviously have to rely on monitoring usage by first authentication (username, passwords, ips, hardware ids, biometrics or what have you) traffic encryption, setting effective policies, and monitoring network and application usage so that the value of your service, the data, is not stolen.

    If a cracker finds a way to patch the network functionality out of the client side to your program then I'd say you better get some good tech support because you have some destructive customers on your hand.

    A monopolized universal verification system? I smell a serious black market expansion. True, DRM is probably more hassle than it helps but if the application's worth isn't worth somebody's time then why not use one? I initially started slapping together some ridiculous mind ramblings until I started to ask myself what is the most effective way to do this? I guess I enjoy torturing my brain with puzzles for my sheer entertainment.
    Last edited by nightFix; July 16th, 2011 at 04:59 PM. Reason: misspelling

IMN logo majestic logo threadwatch logo seochat tools logo