Software protection and serial numbers

Yes, making things uncrackable is largely a waste of time. I spent a long time trying to make Tracktion secure, used every trick I could think of, and that still gets cracked every time. Amazing really, how much patience the little bastards must have to plow through all that assembly code - definitely a pastime for people with autistic tendencies.

They also managed to create a keygen for an early version of tracktion - that amazed me, because although it wasn’t using strong crypto, all the key file maths was done using strings, and was very, very complicated. So to reverse engineer it, they must have had to figure out what kind of maths operations these string-manipulation functions were doing, in assembly language. I never thought anyone would care enough to bother. Anyway, that’s when I wrote the RSA key functions and did the job properly…

This has been a very helpful thread. This is my first exposure to RSA so I’m not 100% sure I understand how to use it for software licensing. My thinking is that the key generating program on my website knows the public key, and the customer’s plugin has the private key burned in. The key file contains machine id, expiration dates, etc. that the plugin uses to determine whether to run properly or complain.

If the private key is burned into the plugin, then clearly the bad guys can find it. But (here is where I am unsure) because of the magic of the RSA algorithm, the private key can only be used to decode the keyfile, and can’t be used to modify it. Therefore, the private key can be out in the open, but won’t help a hacker tamper with or create a new key file.

Do I have this basically right?

[quote=“OldSkoolMark”]
Do I have this basically right?[/quote]

Almost, but your definitions are reversed. In your released software, you have a built in decrypter which uses a PUBLIC key to decode the license file. (It’s public because it’s exposed and known to anyone who knows how to disassemble your code.) But knowing the exaxt algorithm and the public key, or even having the fully commented source code, won’t help the crackers to make a keygen. RSA’s magic is that to MAKE a message that can be decoded, you need to know the PRIVATE key which you keep secure and nobody has access to except you and your license generator (perhaps living on your web server).

But as I mentioned before, the problem is that the RSA encoding has to be pretty long for it to be effective, certainly over 100 digits, so your license codes become very unweildy and you can’t have a code similar to the common Adobe/Microsoft 8TFZ-AHD4-FJD8-DHDB-HSH7, instead you need something 10 times longer than that.

In some schemes the public key is always thought of as the locking one and the private as the unlocking one, and in that sense Mark has it right. I think RSA works both ways though.

Public means accessable to everyone. Private means only the owner knows it. It doesn’t refer to who is encoding and who is decoding: RSA can securely encode in BOTH directions.

With a private key, I can make a message that anyone can decode with the public key, but nobody else can make a message that can be decoded successfully. This is the mode that is used for license code protection - nobody can make a keygen because they don’t have the private key.

The reverse encoding is also possible, someone with the public key can make a message that only I, with the private key, can decode. Software protection (usually) doesn’t need to use this method. You WOULD use this mode to write a private email to someone, however… you’d be sure that only he could decode it.

RSA can do other tricks too, especially signing. This is also also sometimes used in software protection, especially in imbedded software or firmware (think Tivo, iPhone, or Xbox). This basically lets you attach an unforgable stamp on a file that shows that you are the one who signed it. The system may have checks (even in hardware) to forbid running code unless it’s been signed… making it hard for others to change or swap out your software and run their own.

RSA isn’t the only system for doing these kinds of encodings, but it’s the most common, and no longer patent protected. And it’s pretty straightforward to implement.

Sigh. I know. And I think mark knows too. I just meant that he was confusing private/public with locking and unlocking, and not the meaning of the words private and public in themselves, as you seem to think. But please write another couple of paragraphs on what public means. Public is something I keep to myself, right?

No, a public key is the published half. It might be encoded into your released software and obscured, or posted on a web page explicitly, but it’s the information that you share, that you export, that is accessable.

The private key is your secret. It is not shared anywhere, even in obscured form. It is not hidden in your software even in camouflauge. You could use the description “secret” key instead of private, but the RSA algorithms use the word “private” consistently.

Jules, if you had to do your licensing scheme all over again, would you do it the same way? I’m interested in that tedious web programming, not so much the app’s own handling of licenses. I just wonder how much effort it was to have your server do all of the database and license generation (and credit card processing?). Is it all PHP coding, or custom Apache modules, or what?

Does anyone else have similar experience? I’m trying to design my next generation system and seeing what others have done is a great way to learn.

I also wonder if there are middleware companies (or open source?) that have such systems ready to use instead of everyone rolling their own.

Yes, I think I’d probably do it more or less the same way. I use php and mysql on the server, which are both great. And there’s a little juce app on there to generate the key files. None of it’s rocket science, but for a process that seems simple enough, there’s a lot of stuff to write.

For us the hard part would be writing the juce application that sits on the (linux) webserver and generates the key file(s) because we have no experience in writing cli applications on linux. So it would be perfect if i could encrypt some data with a php script and decrypt that in our Juce app.

Do you think it would be at all possible to decrypt data with RSA in juce that is encrypted with this RSA algorithm in php?
http://pear.php.net/package/Crypt_RSA/docs/1.0.0/Crypt_RSA/_Crypt_RSA-1.0.0_RSA_php.html

It might be possible, but I wouldn’t guarantee it. Writing a command line apps is really easy though, so don’t be afraid of that!

re the public vs private thing mentioned before, please note that with RSA I believe it’s relatively trivial to recreate the public key from the private key (whereas the opposite is computationally nearly impossible), so keeping an RSA public key secret and distributing the private key with the app is not a good idea…

Ok i,ll try the php rsa stuff and report back on my findings.

The programming itself i,m not too worried about it,s just that we have no experience with Linux so it,s a lot of work to install it, get to know it and start developing.

I assume that BinaryBuilder.cpp is a good example of how to do this, and once written, it is invoked via PHP system() call or similar to make it web addressable. I don’t host my own website, so compiling for execution on the ISP server is probably not a viable option for me.

There is no reason in principle why the Juce and PHP RSA implementations shouldn’t interoperate properly, right? Just a question of unknown platform and implementation quirks/bugs?

So I got RSA working nicely with Juce. Encrypting a string and wringing it to a file. Then reading the file back in and actually decrypting what I encrypted.

Nice.

But the whole PHP RSA and Juce RSA do not work together at all. They do not understand each others public or private keys to begin with. Probably has to to with their string representation.

I saw the BinaryBuilder would be a great start to see how a command line Juce app would work but there is only a Visual Studio 8 project file to compile it on windows. How do I go about compiling it on Linux? (or mac)

Very bad news. I will try it myself, but if true, it may be a show stopper for me, as my website is hosted remotely, and I have no administrative access to the webserver. Seems to me that Juce’s RSA support needs to interoperate with something else in order to be useful in the web world. PHP RSA would seem to be a good choice today, but I could live with Java compatibility too.

Auspuff,

Are you using RSA.php from PEAR?

[quote=“OldSkoolMark”]Auspuff,

Are you using RSA.php from PEAR?[/quote]

Yes this one:
http://pear.php.net/package/Crypt_RSA

It works fine, and generating a 2048 bit key pair takes REALLY long :wink:

Its not good when the package documentation only claims to be “RSA-like”. Is RSA interoperability really that hard? Seems like a numerical computation like encryption should be testable for correctness and that any ‘correct’ implementations should interoperate, but what do I know? Been googling ‘RSA interoperate’ and it does look like chaos at the full blown identity management level, but one would hope that fundamental stuff would be more standardized by now …

I’m sure the algorithms are compatible - it’s quite straightforward, really, and just involves a few maths operations. It’ll just be the way the data is laid out that’s messing it up. You might have to dig around in the implementations though, to see what the differences are though…