Eric, You are considering a hacker who can extract the symmetric key from your executable as one of the potential attacker. That same hacker should be able to generate a new key-pair, "patch" your EXE to replace your public key with the new one, and then use the private key to sign a new license file.
I think the general idea has been discussed before here but I do not have time to search the archives right now. I seem to recall that "calling home" to a server that you control was part of the answer, including some other "tricks" to prevent direct replacement of the http address in the executable. I don't remember why [or whether] this was any better than using the same method to protect the embedded public key. One way to increase the security is to include self-integrity checks in many different parts of the code. In the end, even that is defeated by a determined attacker that has complete control of the binary. The discussion then moves away from the security technology aspect and onto the financial and human aspect. Essentially, you are trying to decide how much do you raise the bar before it is better for an attacker to buy the license than to spend the time defeating its protection. Other questions include: At what point does it become more of a pain for you and your _paying_ customer than for the hacker? Do the potential hackers include people that will sell your software for profit (as opposed to the "I want to play this game, but I am in high school and I cannot afford it" type of attacker)? Does your program include code for updating itself automatically? HTH, Lorenc -----Messaggio originale----- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di eric.frederich Inviato: giovedì, 06 dicembre 2007 17:38 A: Crypto++ Users Oggetto: License Scheme I need some help choosing encryption algorithms for a basic license scheme. With crypto++ it seems I could create a encrypted license file that includes some hardware information about the PC the software is allowed to run on. Also included in this license file would be an expiration date. I could then sign this file with a private key that only I know. I would hard code the corresponding public key into the binary executable that I distribute. I would distribute a binary executeable, the license file mentioned above, a signature file. When the program starts up it verifies the signature matches the license file using the hard coded public key. It then decrypts the license file itself into plaintext and checks the hardware info and the current date. If everything is okay execution continues. For the signature of the license file I need to use a public/private crypto algorithm right? But what about the encryption of the license file itself, should that be symmetric? I figure it would be symmetric since the executable needs to decrypt the license file to plaintext because of the date. If it were just hardware information I could just compare the hashes of the hardware info, but that date screws things up since it needs to be decrypted back to plaintext for comparison purposes. Am I right in that there is no sense using public-key cryptography for encrypting the license file since it is the untrusted party that would need to use the private key to decrypt it? Here is the scheme again.... I would give the customer an executable which just gathers hardware information and encrypts it using some symmetric cipher. They then send me the encrypted hardware data. Once I receive the data I decrypt it and append an expiration date for the license then re-encrypt it and call it licensefile. I sign the license file using an RSA private key and put the signature in licensefile.sig I distribute the program (which includes the corresponding RSA public key), licensefile, and licensefile.sig Thinking just about the cryptography (not any of the other ways you can run the program like changing the system date or spoofing hardware info) what problems do you see with this scheme? Since a symmetric cipher was used a hacker could get the key from the executable and would be able to decrypt the license file, look and it and create a new one. They'd be able to do that with public key cryptography too by getting the private key from the executable that decrypts it. And with the private key they'd also be able to encrypt a new license file after decrypting it and looking at the format. The only thing they wouldn't be able to do is sign the license file that they'd be able to create since only I would have the private key for that and just the public key is hard coded in the program. So thats it...no more thinking out loud....let me know what you guys think. Thanks, ~Eric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
