[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:
    >
    >> 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
    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.

    - 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.
previous month september 2004 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Go to today