View previous topic :: View next topic |
Author |
Message |
are Apprentice
Joined: 03 Jan 2006 Posts: 188
|
Posted: Sat Dec 08, 2012 10:10 am Post subject: Implementing a license validation, how to |
|
|
Dear All,
please I need some enlightenment. I would like to protect my software with a license-validation. So basically I build a license file (which contains a unique HW ID and a valid-date) on the client and send that to my private server. There I create a salted hash and sign that with my private secret key and store that in a license-file which I send back to the client.
The software itself contains the public key and the original license-information. Whenever it starts, it reads the license-file and checks:
a) that the signature of the hash is valid (by using the public key) and
b) that the hash matches with the unique HW ID and the valid-date
Of course I also obfuscicate the software in order to prevent identification or work around the IF (License.invalid()) exit(1);
So far so good but there is one question which bugs me: It is rather difficult to hide the public and I have to assume it is known to anyone. Furthermore I have to assume the the hash funtion can be identified and engaged even when obfuscicated.
Now how do I prevent any cracker from:
1) creating his own keypair and replacing the public key in the software
2) creating his own hash and sign it with his own private key
Any hints or ideas please?
Best regards |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10589 Location: Somewhere over Atlanta, Georgia
|
Posted: Sat Dec 08, 2012 2:48 pm Post subject: |
|
|
Two pieces of advice.- First, don't try to invent your own hash. Use one of the currently accepted, strong hash algorithms that has withstood professional scrutiny. That decision being made, it's not worth the effort of obscuring the hash algorithm: there are just too few of them to give this obscurity any strength. If you really want some obscurity there, salt the hash with an obscured string of constant (but randomly chosen) bits.
- Second, the best you're going to be able to achieve with the public key is hiding: so-called security by obscurity. I have written function generators that take a cleartext secret and emit a lot of random garbage executable C code that when called at runtime (sometimes in multiple parts), results in the public key being reconstructed. The weakness of this approach is that, if the entry point can be discovered, there's a ready-made function that will construct the public key. Be sure to ship a symbol-stripped binary.
In our products, when we really care about the integrity of a public key, we use hardware to protect it (or a hardware-rooted chain of trust). These are two very different properties that modern cryptosystems need to possess in various parts: confidentiality vs. integrity. For public keys, there's no value at all in keeping them secret: all they need is integrity, but that's really impossible to achieve with any degree of hardness with software only.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
are Apprentice
Joined: 03 Jan 2006 Posts: 188
|
Posted: Sat Dec 08, 2012 3:04 pm Post subject: |
|
|
John, thanks a lot!
John R. Graham wrote: | Two pieces of advice.- First, don't try to invent your own hash. Use one of the currently accepted, strong hash algorithms that has withstood professional scrutiny. That decision being made, it's not worth the effort of obscuring the hash algorithm: there are just too few of them to give this obscurity any strength. If you really want some obscurity there, salt the hash with an obscured string of constant (but randomly chosen) bits.
|
I use standard java features here with salt. It is unlikely to break the hash, it is even not necessary. The system needs to hash the original license-info every time in order to create the hash, which is tested against the signature then.
John R. Graham wrote: |
Second, the best you're going to be able to achieve with the public key is hiding: so-called security by obscurity. I have written function generators that take a cleartext secret and emit a lot of random garbage executable C code that when called at runtime (sometimes in multiple parts), results in the public key being reconstructed. The weakness of this approach is that, if the entry point can be discovered, there's a ready-made function that will construct the public key. Be sure to ship a symbol-stripped binary.In our products, when we really care about the integrity of a public key, we use hardware to protect it (or a hardware-rooted chain of trust). These are two very different properties that modern cryptosystems need to possess in various parts: confidentiality vs. integrity. For public keys, there's no value at all in keeping them secret: all they need is integrity, but that's really impossible to achieve with any degree of hardness with software only.
- John |
Well, I protect the public key by a passphrase and check a checksum and accept the key only when both fits. However it is still obvious that both, the password and the checksum must be hidden in the code.
So basically you confirm my concern: the weak spot of the whole approach is replacing the public key with attackers own public key and then providing self-signed license-info. Right? |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10589 Location: Somewhere over Atlanta, Georgia
|
Posted: Sat Dec 08, 2012 3:10 pm Post subject: |
|
|
Right.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
are Apprentice
Joined: 03 Jan 2006 Posts: 188
|
Posted: Sun Dec 09, 2012 3:07 pm Post subject: |
|
|
Just for reference, my public key looks now like:
private final static String pubKey= new ObfuscatedString(new long[] {
0xF0425731E7F6BF86L, 0x224C1EDE428B2D2L, 0x1A57899CA886D004L, 0x8285EBB785AF3A8DL, 0x6B7A3FD43AE3B391L
, 0x4A65A470B98FEA0BL, 0xF9B5DC53B293A525L, 0xFE53DB224DCD8CE2L, 0x9735B2C0C40FA8D4L, 0x79A730D59BD2A0DFL
, 0x97472818D525CB58L, 0x97565D782FE88DB9L, 0x6AF76BEFB5F69156L, 0xF96457D19ADF583FL, 0x668564090C4146F6L
, 0xE7AFBE789D41AA6DL, 0xAF7136D8EF4A875CL, 0x60DF53892F476085L, 0x100E2DBC0A939DD9L, 0x3CF3ED43F9EE3BC7L})
.toString();
It is not unbreakable, but who ever is going to find and replace that definitely deserves to own a copy. Name of the variable and the method is of course subject to obfuscication. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54270 Location: 56N 3W
|
Posted: Sun Dec 09, 2012 3:46 pm Post subject: |
|
|
are,
Use a hardware dongle for best security - I would never buy such software as I've seen what happens when the software vendor goes out of business and liciences expire.
There is nowhere to go. That just puts potential users off.
Its always possible to break software only security or work around it by finding the key validation routine and editing the binary to hard code the right answer (even if the binary is CRC protected too).
Look at the bluray software only players the have had their keys discovered.
I think the secret is in the price performance ratio. You price the product so its not worth while poking about in the code to circumvent the security that prevents unauthorised use. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
are Apprentice
Joined: 03 Jan 2006 Posts: 188
|
Posted: Sun Dec 09, 2012 4:09 pm Post subject: |
|
|
Thank you for advice. As you pointed out it will not serve for consumer and retail business.
However in my niche there are only a few customers and not much competitors. Mostly individual consulting and implementation. I need a leverage to ensure the bill is paid in the end. |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Mon Dec 10, 2012 1:00 am Post subject: |
|
|
That's not really a good idea, you are now adding trouble to your "honest" users, just to complicate the life of "some evil users".
Like if your system won't kept your "evil users" to stay evil.
But what your system will do is certainly bug the "honest" users, as they will need to validate the license with all the shit this imply, server down, always re-signing a program for nothing just because date is different or they change that piece of hardware, or just because they update udev that wish play with HDIW...
At end you will in fact teach "honest" user to be evil ones, because they will get so bored of your security system that bug them and never bug evil users. After they taste the feeling of running your software without that stupid check, they might just taste the feeling of using it without paying it, just because your system don't deserve to get any money.
Because going into the path of validating license and all the stuff, you will see, you will put more and more code to fight the <few> (let's say even 95% of your users will be evil ones) instead of removing bug, improving feature of your software, at the cost of making your 5% honest users angry and having pain at using your program. Not speaking about bugs you will add because of the complexity of the protection.
Just because you're now trying to crypt/protect your key, but without integrity check like JRG already told you, all your code is useless and will fail as instead of trying to add its key or discover your key, the attacker will just jump at line where you have done the validation : game over.
You said: "Mostly individual consulting" : they could just pay for that, individual = not as everyone, even the program is free of protection, the program itself cannot provide individual answer, only you can provide that, just make them pay that instead of the program. Or if really so few program exist, they will gladly pay it just to make sure the program will still be maintain else it might disappears leaving them with no solution to do the job or because other programs aren't as good as your... |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Dec 10, 2012 6:18 am Post subject: |
|
|
What krinn said.
If you're consulting and someone doesn't pay, take them to small claims court. Don't compromise the job you do, just in case your client turns out to be someone who won't pay. If anything, learn from it and vet your clients better next time around. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21648
|
Posted: Tue Dec 11, 2012 2:41 am Post subject: |
|
|
I concur with those who are advocating that you use legal, not technical, methods to control access to the work. If you still insist on using a technical measure, I think you can substantially comfort your "good" users if you remove the private server from the equation. Ship a signed license file that specifies a start date, and end date, and the feature(s) enabled. The software will check the file locally and make a decision based solely on that. This design is subject to certain attacks that your design prevents, but it has the advantage that the customer can use the software on a network which cannot reach your server. Additionally, it relieves your customer of the concern that you might one day cease to operate that server. |
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Tue Dec 11, 2012 3:50 am Post subject: |
|
|
are wrote: | Thank you for advice. As you pointed out it will not serve for consumer and retail business.
However in my niche there are only a few customers and not much competitors. Mostly individual consulting and implementation. I need a leverage to ensure the bill is paid in the end. |
From personal experience, I purchased software that is almost exactly this type, specifically, turboCAD. I choose it over AutoCAD because (at least at the time) it had more features that I was interested in. Basically, had its "killer app" so to speak. It came with two licenses. After a hardware problem I tried to use the second license, but it would not work and tried to get me to pay $60 for a new one, so I left it on a self where it sits gathering dust to this day. From that experience, I will never purchase their software again even though it is arguably the best in the business and there is not really much, if any, competition (and believe me, I have looked). You may want to think about these types of consequences. _________________ First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|