Question about Strong Naming (signing), public keys and tampering?

[ola.theander]

Dear subscribers

I have a question related to strong naming (signing) of assemblies to
avoid tampering. The reason for this question is that I'll like to
investigate the means to protect sensitive data in an application.
For starters, one thing that I don't fully understand, is there
anything that prevents a malicious user to tamper with the assembly
and in the same process replace the signature with a new signature
thus making the hash fit the tampered version of the assembly?

Assume for instance that the application have a public key stored in
the assembly to unpack an encrypted license key that validates the use
of the application. If a malicious user can replace the public key in
the assembly with the own public key, he/she can use their own private
key to create a valid license key. Is this operation prevented by
signing?

Is there any alternative storage for this type of protected data, i.e.
data that's not supposed to be tampered with by the user?

Kind regards, Ola Theander

 

[Henning Krause [MVP - Exchange]]

Hello,

if a user has full access to your assembly, he effectively owns it. He can
use ILDASM to decompile it to IL, and then use ILASM to recompile the
assembly with a different name. However, this will change the hash of the
assembly.

This will invalidate CAS Settings which are based on a strong name, but
nothing prevents the malicious user to change those settings, if he is an
administrator of the machine.

If you really want to protect data, don't store them in the assembly, but on
the server. You can use obfuscation to make it harder for that user to
tamper with your assembly, but you can't really avoid this.

Kind regards,
Henning Krause

 

[ola.theander]

Hello,

if a user has full access to your assembly, he effectively owns it. He can
use ILDASM to decompile it to IL, and then use ILASM to recompile the
assembly with a different name. However, this will change the hash of the
assembly.

This will invalidate CAS Settings which are based on a strong name, but
nothing prevents the malicious user to change those settings, if he is an
administrator of the machine.

If you really want to protect data, don't store them in the assembly, but on
the server. You can use obfuscation to make it harder for that user to
tamper with your assembly, but you can't really avoid this.

Kind regards,
Henning Krause

Dear Henning

Thank you for your answer. In my case it would not be possible to
store on a server since the application I'll work on would be a
standalone, out-of-office distributed application. The goal is to
protect the licensing model. Of course, there are plenty commercial
packages that do pretty much this but my intention is to have a
discussion on a more general basis, i.e. what means are available if
you want to protect sensitive data from tampering.

/Ola

 

[Peter Duniho]

Thank you for your answer. In my case it would not be possible to
store on a server since the application I'll work on would be a
standalone, out-of-office distributed application. The goal is to
protect the licensing model. Of course, there are plenty commercial
packages that do pretty much this but my intention is to have a
discussion on a more general basis, i.e. what means are available if
you want to protect sensitive data from tampering.

I believe there are probably newsgroups more specific to cryptographic
techniques and which are more appropriate to your question.

That said, Henning has already provided the basic answer: there is no
way to protect sensitive data from tampering if all of the code that
handles the data is in the hands of the user. You can make it more
difficult, but my general rule of thumb is:

* If your data is so valuable that it's worth trying to prevent a
user from having access to it, it's so valuable that there will be a
user sufficiently motivated to bypass your security implementation.

* Conversely, if you think that you can implement some security
that is sufficiently difficult to bypass that no user will be
sufficiently motivated to bypass it, then your data is not so valuable
as to justify bothering to secure it in the first place.

In other words, there's no point in trying to go to any significant
effort to secure data that you hand to the user. If you need the data
to be secure, you need to not give it to the user in the first place.

Now, that's not to say you can't or shouldn't implement any sort of
obfuscation. You just should not invest much time, effort, or money in
it, you should ensure that whatever you do implement does not interfere
with legitimate user actions (common or not), and you should not expect
your security to remain unbroken.

Your specific need seems to be with respect to license control. IMHO,
this is a particularly pointless area in which to invest significant
efforts. The strongest, most reliable license control systems are not
only ineffective, they also cause lots of headaches for users. Weaker
license control systems are helpful in that they keep generally honest
users honest, but most people who would pirate your software are going
to get around the system just as they would a stronger one (more
easily, obviously). The main advantage of the weaker systems is that
they don't tend to infuriate users.

For what it's worth, one license scheme that I have found to be a
reasonably fair trade-off between user-friendliness and still
protecting the code is one that accepts a license key that is basically
an public-key-encrypted validation. When a license is purchased, you
use the private key to encrypt something that the program requires to
run and deliver that to the user to be entered in the program
somewhere. The public key is delivered with the program (in code) and
is used to decrypt the validation to allow the user to run the program.

This isn't hard to bypass if one wants to, but it provides a basic
hurdle to users so that if they are pirating the software, you can at
least be sure they're doing so consciously (rather than just "oh, I
just forgot to get around to buying a license"). You can also include
whatever information you want in the validation information. For
example, this would allow issuance of time-limited validations, to
allow the program to be used for some trial period.

Pete