Home | Contact Us

Powered by Blogger

Thursday, November 16, 2006

Intellectual Property

I have been doing a lot of research lately on the subject of protecting intellectual property.  As an ISV, we have a compelling need to protect ourselves from unauthorized use of both our products as well as our source code.  While implementing a licensing scheme mostly addresses the first concern, the latter is much more difficult to address due to the nature of how managed code is compiled.


There are a number of 3rd party components available to assist with licensing software.  Microsoft has also provided a licensing framework in .NET via the LicenseProvider class.  Out of the box Visual Studio includes only one implementation of a license provider, and it does not offer any real security.  However, it is relatively straightforward to create your own provider and there are a number of examples available online.

The issue with licensing your managed code, though, is no matter how sophisticated your licensing scheme is it is still vulnerable to an attack if the code can be reverse engineered.  Assuming you have implemented encryption to protect your license keys, where do you put the code to decrypt the license?


When I first looked into protecting our code I assumed I just needed to use an obfuscator and it would produce an assembly that not only could not be decompiled, but would also encrypt any embedded resources to prevent viewing someone from accessing IP by viewing the assembly via a standard text editor.  Unfortunately, this is not the case.  An obfuscator can make it much more difficult to understand your code, but it does not prevent reverse engineering and for the most part is not capable of encrypting embedded resources (embedded strings can be encrypted).

Obfuscation does definitely make the job of reverse engineering code more difficult, and when combined with other security measures it serves a useful purpose.  However, obfuscation can give you a false sense of security if you are not aware of its shortcomings.

Client-side code

In a web application protecting intellectual property becomes even more complicated.  Assuming you are successful in protecting your compiled assemblies, when content is sent over the wire to a client you are once again exposing your intellectual property.  Fortunately, there are ways of protecting client-side code including JavaScript obfuscation and encryption.

Final thoughts

After I realized there is no perfect solution for protecting intellectual property, my focus shifted from complete security to a cost / benefit analysis.  If it takes someone more time and energy to reverse engineer our code than to reproduce it, are we really at risk?  If someone is able and willing to break our licensing scheme were they every going to be a customer in the first place?

Our goal now is to protect our intellectual property from prying eyes by making it difficult (but not impossible) to reverse engineer.  The amount of time it would take someone to decompile, decrypt, and reassemble our products greatly outweighs the benefits of doing so.  In the end we found encryption to be much more powerful than obfuscation, but the combination of the two providing a significantly high level of protection.

Copyright © 2007 AdvantageWorks Software Group, LLC. All rights reserved.