Re: PKI confusion...
- From: "Valery Pryamikov" <valery@xxxxxxxxx>
- Date: 31 Aug 2006 16:01:43 -0700
Ray Cassick (Home) wrote:
First, thanks for picking this thread up. I have just spent the last twothanks :)
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.
you can do something like that, however protection properties of this
scheme will be more like placebo (ie. == no protection).
Let say you have a license file that is checked by client code.
in this case client code has to do something like following
(pseudocode)
if (IsValidLicense() == false) then
exit();
....
which translates to
call IsValidateLicense
jnz runProgram
exit
runProgram:
....
the only thing that is required to do in client aplication (that runs
on client computer) is to replace conditional jump (jnz) with
unconditional jump (jmp).
there are programs that do automatic jump correction that could be used
by these who have very little idea about programming.
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.
I'm not sure what you are talking about here because you seems often
mixing context. If you are talking about secret decryption key and
public encryption key (proper for public key cryptography) - there
are such schemes, for example raw RSA with random encryption exponent
allows that, and there are other schemes that allows that as well (but
frankly you don't want to use raw RSA unless you have studied for
many years).
If you are talking about the other way around, ie. signatures, zero
knowledge proofs and disclosures - most of them allows that...
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.
I didn't say successful - I say *effective* (unfortunately, in our
business successful isn't equal effective or even working ;)
For the license you really don't want it to be packed in a little piece
of data, but you want it to be spread all over your program so that
tricks like jump correction wouldn't work, as well as you want to
account for most of more sophisticated ways of circumventing your
license as well...
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.
Windows Product Authorization has a huge advantage over any other
programs - it protects an ANORMOUSLY GIGANTIC program that there is no
one person who knows even one-hundredth part of it. This enormously
gigantic program lives in millions of configurations that makes almost
impossible to find two equal installations. It has something between
tree and four hundred million lines of code base that changes
constantly with the rate of many thousands of lines of code per months
(just think of all updates + new products). This give a hell a lot of
freedom to put something somewhere ... and when someone find where it
is, to move it to another place...
You don't have such luxury - so, don't try to copy what would not be
working for smaller programs (let say less than 4-5 million lines of
code).
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.
Tamperproof dedicated hardware could work ... if you move some part of
your program (for example some volatile parameters calculation) to your
hardware dongle.
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.
in case if you have remote server/tamperproof hardware
dongle/telepathic abilities, or any other way of running a piece of
important program logic separately from client computer, then it can
provide degree of protection (up to a very good protection if designed
properly). In that case, yes - you have to use cryptography to protect
communication, and this is right place for cryptography (it belongs
here). But remember important part here - important piece of program
logic that is beyond user control running on some remote equipment.
However, in cases when your client runs disconnected and you want them
to obey your license - you really want to spread your license all over
your program instead of putting it in a small piece of data that is
readily available to your program running on your client computer and
that means that it is also ready available to your client whom you want
to restrict...
So, I'll repeat it again - encryption is a wrong tool for software
license protection!
-Valery.
http://www.harper.no/valery
.
- Next by Date: How to determine required privileges?
- Next by thread: Re: PKI confusion...
- Index(es):
Relevant Pages
|
