Re: PKI confusion...

First, thanks for picking this thread up. I have just spent the last two
hours reading your blog. Good material there.

Second, while I do agree with the right tool for the right job scenario I am
still a bit confused. My intent here is to encrypt a license key file so
that only the issuer (me or someone using my library) and the licensed
application can read it. I guess what you are saying is that I should not
worry about encryption to hide the data as much as I should be concerned
about ensuring the contents are not tampered with and that the file actually
came form me, so digital signatures is more the right tool for the job.

Trust me when I say that I am now in full believe about your comments on
obfuscating an encryption key in the code. Based on what I have seen this is
practically impossible, and even less so now with the world of managed code,
even with a really good obfuscator.

What I am really surprised with is that there seems to be no algorithm
already in place that allows a sender to use one key to encrypt a message
and the receive to use one key to ONLY decrypt a message. It seems that this
would allow for a single step (hide and validate) where as most of what I am
reading seems to require several steps (decrypt to get the message and then
another step to validate the origin of the message). Sense I have not delved
deeply into exactly how public and private keys work together (ie: how they
are generated and how they are in fact related) I am probably missing
something that makes what I was envisioning impossible. If so please let me
know.

I have looked at several ways to license software over the last year and
have had experiences my self with it over my years working in IT and SW
development. I am curious about your statement that successful schemes never
rely on encryption. Several examples of what I have been experienced with
are:

Windows Product Authorization - While this seems to be working for them I
think that the process of it (keying the licensing of the software to
specific HW components in the system) leads people to view this in a manner
that gives them a negative user experience. As the system would have it,
this negative user experience is usually also at a time when the user is
frustrated to begin with (changing HW components) and is not always the best
route to take for a consumer product. I considered this type of system and
put it aside for two reasons. First, because I did not want the steps
involved to create and install the license and second, It has been hacked
quite simply over the last few years and I didn't want to have to fall back
onto the same system that MS did (Windows Genuine Advantage) as that just
looks to much to me like shoehorning a poor solution into a poorly designed
system.

MAC address keying - I have seen this used quite a bit in the industry that
I work in (host based media solutions) and while it at first seems simple
enough I think that, like WPA) it ends up providing a negative user
experience at times when the user experience is critical (ie: HW failures
and swap-outs). This usually means that I need a way to issue temporary
licenses as a stop gap until real ownership can be verified and a
replacement license can be shipped. It was my impression that even these
systems had to use some encryption at some point to build and protect the
hashed value of the MAC address. Am I wrong here?

Hardware key - I really looked into this quite a bit and was initially going
to go in this direction until I had a few issues with the support
departments at two of the major vendors I had selected. WE had issues
getting the USB keys to work in a few specific cases and got absolutely no
where with the technical support people there to get this resolved. I also
had a few misgivings about HOW these were implemented because even this
method required that my application provide a vendor specific key
(decryption key) to the API calls required to access the memory on the
device and get the license data. I was worried about this and having it
hacked through decompilation, but since I had control over how was able to
actually get a key and the fact that no-one could get their hands on blank
keys with my vendor code I was not to worried about it happening. Aside form
the support reason I had moved form this for the logistical and financial
reason. This was going to mean that if a customer of mine need to license
300 users they would need to get 300 of these keys. The cost of hardware,
shipping, management, etc... was higher than I wanted to deal with at the
time. I figured this method was best left for server type installs because
of those reasons.

Central licensing server - The implementation of these that I have seen all
seem to require that the client be connected to a network to use the
licensed application and this was not going to work for me since one of my
major use cases was disconnected users.

It seems to me that at some point each of these system use some kind of
encryption to control the use of, control the access to, or validate the
identity of either the user, the key it self or the issuer.





"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message
news:1157012835.386892.315710@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks Joe :)

To OP:
Every task requires use of a right tool. And encryption is a wrong
tool for software license protection!
Encryption provides us with provably secure way of reducing the problem
of protection of large amount of data (plain text) to a problem of
protection of much smaller amount of data (encryption key).
Software license protection has exactly opposite goal - to spread
license protection over the as big part of the program as possible, so
that circumventing license protection would require comparable effort
as independent development of functional equivalent.
In other words (allegorically speaking) - encryptions allows
compressing the big secret to a much smaller key, software protection
requires expansion and spreading of a license over whole program.
There is a rigorously proven mathematical theorem stating that one
could never hide a small secret, such as an encryption key, in a body
of a program (see Barak at al "On (Im)Possibility of Obfuscation").
Trying to do otherwise (i.e. to use encryption for license protection
while as trying to hide encryption key with help of obfuscation or
other tricks) is just as impossible as trying to invent an universal
always compressing lossless compression (there are no way around
counting theory).
There are effective mechanisms of software protection; however they
never rely on encryption!

-Valery.
http://www.harper.no/valery



.

Relevant Pages

  • Re: PKI confusion...
    ... tool for software license protection! ... Encryption provides us with provably secure way of reducing the problem ... Software license protection has exactly opposite goal - to spread ...
    (microsoft.public.dotnet.security)
  • Re: PKI confusion...
    ... you can do something like that, however protection properties of this ... Let say you have a license file that is checked by client code. ... obfuscating an encryption key in the code. ...
    (microsoft.public.dotnet.security)
  • US crypto export regs (was Re: Use of Debian For Non-Profits)
    ... We're trying to find a version of Linux that we could ... > current encryption. ... is subject to an express agreement for the payment of a license fee ... from the compiling of such source code is also eligible for License ...
    (Debian-User)
  • Re: Encryption keys
    ... The app will deserialize them and use the contents to judge ... > Currently the license key and vectors are stored in the code. ... > takes care of part of it but from what I have seen asymmetrical encryption ...
    (microsoft.public.dotnet.general)