[ANN] OpenSSL and license keys
-
Last week I offered (on request) to put online a small tutorial about
using openssl to encrypt license keys (serial numbers) in the thread
about registration issues -- since a few people did actually write me,
and one even told me it was useful :) I figured I'd post the link to
the list also:
http://macromates.com/sigpipe/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 6 Sep 2004, at 11:27, Allan Odgaard wrote:
> Last week I offered (on request) to put online a small tutorial about
> using openssl to encrypt license keys (serial numbers) in the thread
> about registration issues -- since a few people did actually write me,
> and one even told me it was useful :) I figured I'd post the link to
> the list also:
> http://macromates.com/sigpipe/
Allan,
This article is very useful to those new to cryptography wanting to
make strong license keys. I would however suggest some
corrections/changes/additions to it.
You rightly suggest using public key crypto to stop attackers cracking
your license keys by running the program under s debugger and finding
the symmetric keys but you then go on to say "the key size also
dictates the minimum size of the data to be encrypted". This is not
correct. The key size dictates the maximum amount you can encrypt in
one go but when encrypting or signing with RSA we "pad" the message so
there is no minimum size; you simply need to use the -pkcs option on
your call to openssl rsautl when signing. You also go on to use a 248
bit key; this is woefully insecure. If you are assuming that the
attacker has a debugger they can find the public key (in fact they
don't even need a debugger, see [1]). Using easy-to-use tools like
Pari/GP [2] a G5 PowerMac should be able to factor a 248 bit public key
in a few hours, certainly in an overnight run, and once they have the
private key they can forge license keys as easily as with a symmetric
key based system.
Cheers,
Nicko
[1]
http://www.ncipher.com/resources/downloads/files/white_papers/
keyhide2.pdf
[2] http://pari.math.u-bordeaux.fr/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 6. Sep 2004, at 13:01, Nicko van Someren wrote:
> [...] "the key size also dictates the minimum size of the data to be
> encrypted". This is not correct.
True, what I meant was the minimum size of the encrypted data. I.e. the
data the user receives (as his license key).
So with a 1024 bit key, you cannot send the user a 64 characters
license key, which is what I figured was the essence in this context.
> [...] You also go on to use a 248 bit key [...] a G5 PowerMac should
> be able to factor a 248 bit public key in a few hours
Also very true -- I wanted to have added some notes about key sizes and
factoring times, but a quick Google did not reveal anything I could use
as reference, so I put it off till I had some time testing it myself --
I will check your links when I have some more time, and I can add an
update to the article.
Thanks for your comments!
--
http://macromates.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 6 Sep 2004, at 12:11, Allan Odgaard wrote:
> On 6. Sep 2004, at 13:01, Nicko van Someren wrote:
>
>> [...] "the key size also dictates the minimum size of the data to be
>> encrypted". This is not correct.
>
> True, what I meant was the minimum size of the encrypted data. I.e.
> the data the user receives (as his license key).
>
> So with a 1024 bit key, you cannot send the user a 64 characters
> license key, which is what I figured was the essence in this context.
OK. Perhaps the text could be clearer. One thing to note is that if
you use DSA instead of RSA then you can get 320 bit signatures even
with 1024 bit keys.
>
>> [...] You also go on to use a 248 bit key [...] a G5 PowerMac should
>> be able to factor a 248 bit public key in a few hours
>
> Also very true -- I wanted to have added some notes about key sizes
> and factoring times, but a quick Google did not reveal anything I
> could use as reference, so I put it off till I had some time testing
> it myself -- I will check your links when I have some more time, and I
> can add an update to the article.
I can factor 512-bit keys in about four weeks using a rack full of G5
X-servers, which is less resource than many university computer labs
have on tap. At this time 576-bit keys have been factored and 768-bit
is considered suspect for any long term security. Ultimately it boils
down to how much effort you think your attacker will put in and for how
long you want your software to be secure. At the moment we are still
some way from anyone getting close to factoring 1024 bit RSA moduli or
breaking 1024 bit discrete logs (used in DSA) so if you are willing to
risk fake license keys turning up in a decade or so I'd go with 1024
bit keys. If you're selling high value software that people are likely
to rip off then simple software license keys aren't going to do much to
deter the concerted attacker anyway.
Cheers,
Nicko
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sep 6, 2004, at 4:38 AM, Nicko van Someren wrote:
> On 6 Sep 2004, at 12:11, Allan Odgaard wrote:
>> On 6. Sep 2004, at 13:01, Nicko van Someren wrote:
>>
>>> [...] "the key size also dictates the minimum size of the data to be
>>> encrypted". This is not correct.
>>
>> True, what I meant was the minimum size of the encrypted data. I.e.
>> the data the user receives (as his license key).
>>
>> So with a 1024 bit key, you cannot send the user a 64 characters
>> license key, which is what I figured was the essence in this context.
>
> OK. Perhaps the text could be clearer. One thing to note is that if
> you use DSA instead of RSA then you can get 320 bit signatures even
> with 1024 bit keys.
>
>>
>>> [...] You also go on to use a 248 bit key [...] a G5 PowerMac should
>>> be able to factor a 248 bit public key in a few hours
>>
>> Also very true -- I wanted to have added some notes about key sizes
>> and factoring times, but a quick Google did not reveal anything I
>> could use as reference, so I put it off till I had some time testing
>> it myself -- I will check your links when I have some more time, and
>> I can add an update to the article.
>
> I can factor 512-bit keys in about four weeks using a rack full of G5
> X-servers, which is less resource than many university computer labs
> have on tap. At this time 576-bit keys have been factored and 768-bit
> is considered suspect for any long term security. Ultimately it boils
> down to how much effort you think your attacker will put in and for
> how long you want your software to be secure. At the moment we are
> still some way from anyone getting close to factoring 1024 bit RSA
> moduli or breaking 1024 bit discrete logs (used in DSA) so if you are
> willing to risk fake license keys turning up in a decade or so I'd go
> with 1024 bit keys. If you're selling high value software that people
> are likely to rip off then simple software license keys aren't going
> to do much to deter the concerted attacker anyway.
>
>
Although a note about the relative security of keys of different
lengths would be useful in Allan's tutorial, I'd like to point out that
the shorter keys might be appropriate for some users (as long as they
know the likelihood of the key being cracked). There are a lot of ways
of cracking a program other than being able to generate legal keys, so
in order to protect the software you have to make sure there are no
ways of bypassing the protection that are easier than breaking the
license key. I'm oversimplifying a bit because illegitimate license
keys are easier to distribute than patched binaries -- but still, if
you have copy protection that can be broken overnight via some other
paths, it doesn't help that much to have a license key that can't be
broken for ten years.
I'm speaking from the point of view of a shareware author, and my
problem is that the length of the license key is an issue. Ideally, I
would like to use keys that can practically be entered by hand, even
though most people are going to cut and paste. When you get into keys
that are 1024 to 2048 bits in length, you pretty much have to go with a
license file or at least a very long string in email that the user will
have to cut and paste.
In my case, it is not disastrous to have some people cracking the
program, I just want to raise the bar a little. My programs sell for
$15 or $20 and there is a point where it is not worthwhile to spend
time cracking the program. Of course, for software selling for hundreds
or thousands of dollars it is a different matter and that kind of
software needs a high standard of protection. Also, there are people
out there that would rather crack a program than pay for it even if it
costs them a week of effort that far exceeds the actual value of the
software. Shareware authors realize that this is a trade off -- there
will be a certain amount of piracy regardless of the degree of
protection applied, so the author has to balance the effort required to
protect the software against the number of additional registrations
that will be obtained.
Right now, I have my own home-grown scheme for generating license keys
that is basically a hashing algorithm that can be (and has been) broken
very easily in a debugger. Something that takes overnight to break (and
that is after the cracker has figured out the encrypting scheme which
will take a while in itself) might well be all I need (a lot of people
just won't bother) whereas someone with a more popular and/or more
expensive program might need something stronger.
Oh yes, the comment about 320 bit signatures with 1024 bit keys with
DSA was intriguing, could you elaborate further? (Could this be applied
to get more secure license keys of relatively short length?)
- Dennis D.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 7 Sep 2004, at 06:56, Dennis C. De Mars wrote:
> Although a note about the relative security of keys of different
> lengths would be useful in Allan's tutorial, I'd like to point out
> that the shorter keys might be appropriate for some users (as long as
> they know the likelihood of the key being cracked). There are a lot of
> ways of cracking a program other than being able to generate legal
> keys, so in order to protect the software you have to make sure there
> are no ways of bypassing the protection that are easier than breaking
> the license key. I'm oversimplifying a bit because illegitimate
> license keys are easier to distribute than patched binaries -- but
> still, if you have copy protection that can be broken overnight via
> some other paths, it doesn't help that much to have a license key that
> can't be broken for ten years.
I think the critical issue is that not only is it easier to shift
license keys than hacked copies of the binary but once the attacker has
the key it's also impossible to tell the difference between a
legitimate license key and a fake.
> I'm speaking from the point of view of a shareware author, and my
> problem is that the length of the license key is an issue. Ideally, I
> would like to use keys that can practically be entered by hand, even
> though most people are going to cut and paste. When you get into keys
> that are 1024 to 2048 bits in length, you pretty much have to go with
> a license file or at least a very long string in email that the user
> will have to cut and paste.
That's why I suggested using DSA rather than RSA. Keys of 40 bytes are
still quite long but base 64 encoded and with punctuation to make them
easy to read they still fit on one line.
> In my case, it is not disastrous to have some people cracking the...
> program, I just want to raise the bar a little. My programs sell for
> $15 or $20 and there is a point where it is not worthwhile to spend
> time cracking the program.
> Right now, I have my own home-grown scheme for generating license keys
> that is basically a hashing algorithm that can be (and has been)
> broken very easily in a debugger. Something that takes overnight to
> break (and that is after the cracker has figured out the encrypting
> scheme which will take a while in itself) might well be all I need (a
> lot of people just won't bother) whereas someone with a more popular
> and/or more expensive program might need something stronger.
That said it only needs to be broken once. I recently heard from Steve
Sims (who posts to this list) that a fake license key for FontFX7
showed up on the "Serial Box" with a totally bogus licensee name. The
fact that Steve never issued a key to that licensee indicates that
someone bothered to run a debugger on the program and find the
symmetric key that was used. Had a public key system been used they
would have had to either redistribute a real license key (which would
provide the deterrent of legal follow-up) or redistribute the hacked
binary (which is more likely to be stomped on by ISPs hosting the
site).
> Oh yes, the comment about 320 bit signatures with 1024 bit keys with
> DSA was intriguing, could you elaborate further? (Could this be
> applied to get more secure license keys of relatively short length?)
The short answer is that when you use DSA with 1024 bit keys the
signatures are 320 bits long, with no loss in strength, so you can use
this to make shorter license keys.
The slightly longer answer is that the computations are done module a
prime number P which is 1024 bits long but P is constructed as P =
2*(k*Q)+1 where Q is also prime and 160 bits long and the computations
are carried out in a subgroup of size Q. This means that all the
numbers involved in the calculations can be represented by numbers mod
Q and only take up 160 bits each. The signature is two of these
numbers, hence 320 bits total. Breaking 1024 bit DSA with 160 bit long
Q values is thought to be about as hard as breaking 1024 bit RSA. It
would be possible to use a shorter Q, say 128 bits, to give shorter
license keys with reduced security if needed, though you'd have to
generate your own DSA parameters since the OpenSSL will only generate
160 bit Q values.
Cheers,
Nicko
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sep 7, 2004, at 10:08 AM, Nicko van Someren wrote:
> but base 64 encoded and with punctuation to make them easy to read
> they still fit on one line.
WARNING! As I have unfortunately discovered and regretted for a long
time, encoding your key in base 64 will cause you no end of e-mail from
users who try to type the key manually instead of using copy and paste!
Even if you say to use copy and paste right in the e-mail that they get
that contains the code, they will still want to enter it manually, and
they will write you because they get the number one confused with a
lower-case 'l', or get a number zero confused with a capital 'O'. They
will also get frustrated by case sensitivity. The next regcode scheme I
write is probably going to be encoded in base 34, that is, all the
letters except 'O' in uppercase and all the numbers except for zero. It
will cause a longer regcode, but I'll get fewer "This regcode doesn't
work! Issue me a new one NOW!" e-mails.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sep 8, 2004, at 9:30 PM, Charles Srstka wrote:
> On Sep 7, 2004, at 10:08 AM, Nicko van Someren wrote:Or base32, which is A-Z and 2-7. This excludes zero (which can be
>
>> but base 64 encoded and with punctuation to make them easy to read
>> they still fit on one line.
>
> WARNING! As I have unfortunately discovered and regretted for a long
> time, encoding your key in base 64 will cause you no end of e-mail
> from users who try to type the key manually instead of using copy and
> paste! Even if you say to use copy and paste right in the e-mail that
> they get that contains the code, they will still want to enter it
> manually, and they will write you because they get the number one
> confused with a lower-case 'l', or get a number zero confused with a
> capital 'O'. They will also get frustrated by case sensitivity. The
> next regcode scheme I write is probably going to be encoded in base
> 34, that is, all the letters except 'O' in uppercase and all the
> numbers except for zero. It will cause a longer regcode, but I'll get
> fewer "This regcode doesn't work! Issue me a new one NOW!" e-mails.
>
> Charles
confused with "O") and one (which can be confused with an uppercase I
or a lowercase l (which in my font shows up the same -- I was referring
to the letters "i" and "L").
If you combine this with automatic conversion of lower to upper case
and either an error message or automatic conversion when a zero or one
is typed, it results in a fairly friendly reg code system. Using this
system increases key length by about 20% over base64, but if manual
entry is an option then it is worth it to avoid the problems you cite.
- Dennis D.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sep 9, 2004, at 2:47 AM, Dennis C. De Mars wrote:
> Or base32, which is A-Z and 2-7. This excludes zero (which can be
> confused with "O") and one (which can be confused with an uppercase I
> or a lowercase l (which in my font shows up the same -- I was
> referring to the letters "i" and "L").
>
> If you combine this with automatic conversion of lower to upper case
> and either an error message or automatic conversion when a zero or one
> is typed, it results in a fairly friendly reg code system. Using this
> system increases key length by about 20% over base64, but if manual
> entry is an option then it is worth it to avoid the problems you cite.
Good point, I hadn't thought about I.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
