Re: PKI confusion...

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

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Ray Cassick (Home)" <rcassickNOSPAM@xxxxxxxxxxxxxxxx> wrote in message
news:uOyKKLFzGHA.2640@xxxxxxxxxxxxxxxxxxxxxxx

"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uFocnaAzGHA.772@xxxxxxxxxxxxxxxxxxxxxxx
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.


We are also looking into signing as well. Thanks.

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.


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.



.

Relevant Pages

  • 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)
  • Re: PKI confusion...
    ... My intent here is to encrypt a license key file so ... obfuscating an encryption key in the code. ... this negative user experience is usually also at a time when the user is ... Software license protection has exactly opposite goal - to spread ...
    (microsoft.public.dotnet.security)
  • Re: Encryption of application configuration block
    ... your main concern is about applying encryption ... protection for your client application ... I've performed some research on the new config protection feature in .net ... For creating and exporting/importing RSA key and programmatically encrypt ...
    (microsoft.public.dotnet.general)
  • Re: Securing Software with License
    ... > That by itself is hardly what I'd call protection. ... > is known at all or useful, it'll be on crack sites within minutes. ... doesn't display a popup with "LICENSE VIOLATED", ... So obfuscate the code, sign your ...
    (microsoft.public.dotnet.general)
  • Re: Password protecting?
    ... Something really secure? ... > so to provide any level of protection for your data, ... Now most likely, NTFS ... > encryption, which is pretty simple to implement, will be good ...
    (comp.security.misc)
Quantcast