I am implementing a licensing library to use across all my companies
applications.

The basis for this system is going to be simple text files that contain the
details of the enclosed license and then an encrypted has of the contents to
validation upon reading in the file just to prevent tampering. I am also
considering making the name of the company issued the license part of the
details so I can ensure that the key file stays with a particular customer
and is not shared.

Now my quandary here is that I want to use asymmetric encryption just to
make sure that the public key I either give out or put into the license
engine can ONLY decrypt the data to use but cannot be used to encrypt any
new data. I do not obviously want to give away to spoof or create false
licenses. I figured that the key I give out as public data would only allow
decryption where as the private key I would keep here would only allow
encryption (or perhaps both).

I was a bit surprised to find out (at the article I found below) that in a
PKI infrastructure the private key is a superset of the public key and it
can be used for both encryption and decryption, whereas the public key can
only be used for encryption.

In my situation I would flip it around a bit I guess and distribute what
would normally be the private key in my library so that it can decrypt the
data and use what would normally be the public key on my backend processes
to create the license files, BUT I get the feeling that this is bad practice
sine the private key can do BOTH encryption and decryption I do not want
that key to be used, so... thus my quandary...

What can I use to allow the creation of files with encrypted data on the
backend and then the decryption of this data on the public side without also
giving away a key that would allow people to in turn create keys that can be
used to spoof my system?

I am looking forward to some of the .NET crypto experts out there to make
any comments on this and hopefully offer some ideas while I do further
research in parallel.

Thanks in advance for what I know will be a useful round of comments and
ideas.

http://www.codeproject.com/dotnet/SimpleEncryption.asp?df=100&forumid=172899&exp=0&select=1434169

From a cryptography standpoint, you want to always use the private key for
either decrypting data encrypted with the public key or signing data.  In
your case, you should be thinking in terms of signing.

From a licensing standpoint, I think a lot of the readers of this group
would suggest that rolling your own licensing system is hard to do and easy
to get wrong, and that you'll be better off using a commercial licensing
program.  Also know that most licensing systems are easily cracked by
someone who knows what they are doing, so make sure you set your
expectations appropriately about how much protection this will really give
you.  If you are thinking in terms of keeping the honest guys honest, you'll
probably be ok.

Joe K.

Show quoteHide quote

We are also looking into signing as well. Thanks.

Thanks for the comments here, and if I was just setting out to build and use
a licensing package I would most likely go that route (buy vs. build) but I
am also looking to market this package as a separate SDK to other
developers. Without giving away any deatils here I think we have some
interesting ideas that can add some significant value to the licensing
market. This is the only reason we are working this project from the ground
up.

We have a prototpye build but it uses symetric encryption right now and
testing has shown that witht he way .NET is, even with obfuscated code, this
opens us up more than we want. We thought that using an asymetric scheme we
would be able to release a key that would allow decrpytion only while
keeping the encryption key safe. Seems not to be the case I guess.

Remember that signing is similar to encrypting the hash with the private key
so that it can be decrypted with the public key, so if you just need to
encrypt the hash, then perhaps signing gets you close.  There may also be a
way you can trick it into signing a hash that is actually a symmetric key in
order to do some sort of bulk encryption.

You really don't want to be thinking in terms of encrypting with the private
key though.  It is bad usage and gets you into trouble.  This is one of the
reasons MS goes out of their way to prevent you from doing this (there are
also historical legal reasons having to do with export laws).  Other crypto
libraries will let you run off and do this, but MS tries to not let you hang
yourself (this time anyway).

It might be beneficial to engage Valery Pryamikov in this discussion as
well, as he knows all the theory and is an expert on licensing and
protecting code assets as well.

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

Joe K.

Show quoteHide quote

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

Joe Kaplan wrote:
Show quoteHide quote

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.





Show quoteHide quote

Ray Cassick (Home) wrote:
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.

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

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

Show quoteHide quoteWindows 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).

Show quoteHide quoteTamperproof dedicated hardware could work ... if you move some part of
your program (for example some volatile parameters calculation) to your
hardware dongle.

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

As other said, you don't want to encrypt anything.  You want to Sign the
text (xml, etc) file with the private key only you know and store at your
site.
Your program will embed the public key in the library.  You will use that to
verify the license file is valid.  Once it is verified, you can just use the
data in the license.  However, we still have a few issues here.  First, the
public key needs to be embedded or found out otherwise in some out-of-band
secure way.  If you embed it, that is one source of attack.  The public key
can be changed and attacker can just sign the license with his private key
and your program will validate it because he changed the public key to
match.  The other issue is just simply jumping around your license logic as
Valery said.  The good news is both those attacks require actually
changing/hacking your Exe.  As that is always possible regardless what you
do, that is about as good as you can do (plus obfuscation).

Show quoteHide quote

William Stacey [MVP] wrote:
Show quoteHide quoteAs I already wrote - there are effective methods that litelary spreads
the license over a very big part of your program. Such as for example
jump networks with blind predicates and dynamic program reference
states; encoding call-tree and others.
The most simple to understand are jump networks - is a lot of extra
jumps that are put through the many different parts of the program (a
subset of function that you choose to use for jump networks), that
depends on the state of one other and/or another set of blind
predicates and/or dynamic program reference states to form a continious
dynamic license check over whole program execution.
Another method is to encode the license  into the call tree, by
complete rewriting/reversing of call tree and tying result to the
license in such way that whenever license criteria are not satisfyed,
at least some part of call tree become corrupted. Only having correct
license guarantees correct call tree.

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

Any links to a commercial program(s) that do this already for .Net
assemblies?  tia

William Stacey [MVP] wrote:
as about commerical programs - I don't know any such commerical program
yet, sorry. I wouldn't say that such commerical program doesn't exist -
i simply didn't checked that carefully.
However I know that there are many research prototype programs
available and there were a lots of academic research articles that were
published about software protection during last decade. But whenever it
concerns to the commerical programs, most of these that I heard of are
either producing pure snake-oil/placebo or hopelessly lagging behind
the research.

If someone compiles a list of available commerical programs, we can try
to contact them and ask about the technology (I can help with a quick
check of the tecnology). Who knows, may be there are some hope ;).

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

Show quote Hide quote Could this be because the companies weigh the cost of impliemnting fool
proof licening scheme (of which I am certain there is no such thing) and the
costs of piracy?

While I agree with alot of what you say I think there is a fine line between
a 'perfect system' in a 'perfect world' and simply acheving a goal of making
things difficiult to copy.

There is something to be said for keeping an honest person honest.

I am a realist when it comes to such things really and I know that if
someone wants to pirate you they will. Just like the best car alarm in the
world is only as good as the nearest tow truck.

While I am interested in keeping my revenue at a specific level by
preventing piracy I am also interested in making money and that requires
that I release something. If my product will keep out 95% of the criminal
element then I think that is acceptable. It is afterall always a trade off
between cost of prevention and cost of recovery so to speak. I could keep my
system very protected and just build it as a web bassed app that I rent out
via a subscription but then that costs me tremendous amounts of cash in
infrstructure and may give the potential customers the willies because of
how quickly comapnies can fold.

I doub't that many companies are that open to devugling thier stratagies in
an open forum.

Show quoteHide quote

Ray Cassick (Home) wrote:
Unfortunately no. I've had chance of talking to several such companies
on exhibitions during couple of last TechEds Europe (I would not name
these companies here for obvious reasons) and it appears that most of
them are totally ignorant to the state of current research in area of
software protection. They were started on someone's "cool" idea (which
actually appears to be quite a stupid idea) and they are trying to
fill-in marked niche selling placebo/snake-oil while as ignoring any
real problem in their products. And why should they? As long as their
programs are used for protecting something that none is actually
interested to steal, they could claim whatever level of protection they
want in their advertisements. And something that is worth stealing is
too rare event for being any threat to their snake-oil/placebo
programs...
   When it concerns fool-proof protection, most of people that I talked
with loose the point when discussing level of protection of software
licensing by mixing it with level of protection that could be provided
by cryptography. With cryptography, the level of protection is such
that is computationally unfeasible to break the protection when you
don't know the key even so you may use together every piece of
computer equipment that was ever produced for millions and billions of
years. That level of protection is definitely unachievable for software
license protection (with rigorous mathematical theorem proving this
fact), but WE DON'T NEED THAT LEVEL OF PROTECTION FOR SOFTWARE
LICENSE ANYWAY! The point of license protection is to ensure that
breaking the license is about as difficult and expensive as independent
development of functional equivalent. The last task (independent
development) is always feasible - after you publish your program you
disclose every externally observable details of its behaviour that
always could be closely emulated by independently developed program.
And this independent development is easier task than original
development, because many design choices are clear without spending
much on design phase. And "as difficult as independent development of
functional equivalent" level of protection is something that is
actually achievable - it could be done, it should be done and it must
be set as requirement for commercial license protection schemes.

If you have protection that ensures that pirate have to use the same
amout of time to break your program as they would have to use to
re-implement your program from scratch - then who cares that it
protection could be broken? The protection has fulfilled its goals
after that point.

Keeping "honest people honest" is a myth invented by DRM people that
are trying to implement something that could never be achieved - i.e.
develop an obscure program with fixed cost that supposes to protect
digital assets that potentially have unlimited value (just think how
much music industry would cost), while as this obscure program can't
rely on any secrets beyond its own obscurity. This kind of protection
is designed to fail and it fails regularly. Software license protection
is very different in this regard - here we are protecting asset of
limited value - i.e. we only have to ensure that breaking our
protection costs about the same as the value of protected asset.

Refuse of disclosing details of license protection scheme is a clear
sign of snake-oil. If the company has real solution - they can patent
it and publish for proving their point. Anything unpublished in this
area is equal to being totally unreliable and unverifiable claims of
someone trying to make quick buck...

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

There is also the Wall height and Width story.  You can make your Wall 1
mile high with PKI, but in some respects it is still only 5 feet wide, so I
can just *walk around it (i.e. with jumps, etc).  So the weak link in any
protection is the height *and the width - you need both.  Valery points out
a solution that would seem to have both, but I can't seem to find a ready
solution either.  When you consider the "width" story, I am starting to
think that a simple solution of embedding a long watermark string in your
code (unique to each copy) is as good as anything in respect to relative
protection and simplicity (naturally adding obfuscation).

Then just give the user a hash of their watermark as the license key to
"unlock" it.  This could also be combined with a machine hash to prevent
user from distro their Exe and the license key to everyone.  A downside is
you need a unique build for *every user which would be major production
issue.  I'd have to think about it more, but maybe a variant of a fixed
watermark (so all Exes can be the same) and a mix of the machine hash would
do.  Current obfuscators do some pretty fair work of hiding the watermark in
the code with various methods (i.e. XenoCode).  So I guess this could be
good enough and would force a code change on the Exe to break it or major
real-time debug inspection - which is about all we can do with normal
methods anyway (i.e. not counting the method outlined by Valery).  I think
something like this could keep all but the "high priests" at bay.

Show quoteHide quote

In regards to reversing and reordering call-trees, you may find this video
interesting from a guy at MSR.
They have a way to refactor the call-tree to reorder the failure cases in
your code to the end, so they can save all that memory.  Then somehow hoist
that code back in if the exception logic is needed (I guess).  Interesting
talk from an Ex-cosmologist who also worked on the PKI stuff at MS.
http://channel9.msdn.com/Showpost.aspx?postid=230438

Show quoteHide quote

Thanks for the link!

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

William Stacey [MVP] wrote:
Show quoteHide quote

How to validate client certificate?
Bad Data. Any idea what this means?
Aplying more than 1 attributes ?????
How to convert string to SecureString?
SignedXml gives false negatives when using namespaces in signed xm
recent security patch prevents desktop.ini CLSID folder-app association and custom icon
Encrypting connection string in app.config
Get role for any given user name ...
Laptop Problems
when my C# service impersonates a secondary account does the secondary account need any special perm