|
|
Fattigra,
> In D5 protect product framework has weak places and not recommended
> for use in real application.
>
> Has D6 framework changes in this framework? May use it for protect
> application?
The D5 version was broken; it had several bugs that meant that it didn't
achieve it's designed security level.
In D6, the (known) bugs have been removed. The designed-in security has been
slightly beefed-up, but more importantly the architecture has been rearranged
to make it easier to plug in your own encryption (such as private/public key
encryption) to protect the unlock key.
> Community Edition have several classes from this framework, but they
> not give clear idea about work.
Does the Community Edition have the classes PC1SerialNumberProtector, and
ElgamalSerialNumberProtector ? If so then their comment give a fairly complete
description of what the package provides by default, and how to replace the
defaults if you should so wish.
Anyway, the rough outline of how it works is in two parts.
Part one is that the bytecodes for the methods you want to protect are
encrypted (with RC4 aka PC1) in the delivered executable. Each time the
executable starts it decrypts the bytecodes using a supplied key. That key is
(by default) typed in by the user and stored in the registry.
The second part concerns protecting that key. There is nothing you can do to
prevent users from giving away their keys, so the question is how do you
protect yourself against that ? The approach that the framework takes is that
each key includes not only the key for unlocking the product, but also
information identifying the user who bought it. (A different way would be to
tie the key to the machine on which it executes -- that's not how the framework
works, though, although I see no obvious difficulty in extending it to do so).
The problem here is that the key is available to the user, so you have to stop
them messing around with it in ways that would prevent you from identifying who
it was issued to but which don't stop it working as an unlock key. The
framework encrypts the key (using RC4 again), and that has two potential
weaknesses. One is that the key for decrypting the key is stored in the
executable[*]. The other is that the bits of the keys are not scrambled
together as strongly as they could be, so it is in principle possible to change
some of the bits without actually cracking the encryption. Neither I nor
anyone else can tell you whether that risk is acceptable for your
application -- only /you/ can decide that (or your bosses, since it's basically
a financial decision, not technical). If you do consider it too weak, then you
can plug in a different protection scheme, as illustrated by the
ElgamalSerialNumberProtector example.
Beyond that, I think it's still true that OA intend the framework as the
/begriming/ of a product protection scheme. It's up to you to look it over,
decide what parts meet your needs as they are, and what parts you want to
extend to provide your own features.
Oh, one other thing. I believe that the current D6 patch level has 3 methods
missing from the PP package. I assume they'll be reinstated in the next patch,
but I (obviously) don't know for sure. They are easy enough to add yourself if
you need it now.
-- chris
[*] Not that most casual users would be able to extract it. Come to that I
doubt if most crackers could either -- at least not with their ordinary tools.
They have to work out how to interpret the contents of a Dolphin saved image
(included in the deployed executable), and navigate that to find the relevant
object which holds the data. Not impossible, by any means, and I suspect that
Blair could do it easily. I'd be willing to bet I could do it too; albeit with
more work than is likely to be justified by the ill-gotten gains ;-)
Of course, no application (in any language) can be protected against
sufficiently motivated and skilled crackers...
|
Locked
