Is using SecureString in combination with Xor considered secure enough for standalone Windows app?

Question

The environment is Windows. We are using 3rd party tools in our app, and for tools to work they require method call and pass a license key that is a string.
License.Import(string name, string email, string organization, string code)
Since it is an installable Windows app that might not have access to the internet, I don't see any solution, but to store license keys 'inside' the application.
The 'standard' way of protecting from memory dumping the key in C# is using SecureString. However, when initializing SecureString I still need to feed the actual key into it. Which means that someone could decompile the code and get the strings from there. To prevent that I could use XOR with another value to obfuscate the key, but then I would have to store the XOR value somewhere which then could be decompiled and so on...

How to go around this hide the string inside the app circularity? Or is it 'good enough' to just SecureString + XOR the key, and accept that if someone will be determined enough he will crack it no matter what?

Answer 1

Nothing you can do about it. DRM is impossible.

You can try to hide or encrypt your keys, but this only delays the inevitable. The data is on the computer of the customer/attacker, and as such can be found by them. Let me illustrate with some examples:

1. Just leaving the string there

   Even a casual script kiddie could run strings over your application and detect the license key.

2. Using SecureString

   This doesn't stop attackers at all, as SecureString isn't designed to protect against what you want to protect. The idea of a SecureString is to have the user enter some secret data manually (usually a password), and then wipe it from memory when no longer needed. This means if an attacker dumps the process memory after the password was entered, it will not be in the process memory anymore. Since you need to store your license key permanently in the application, it's identical to scenario 1.

3. Encrypting the string and storing the key in the application

   This is like locking your house and hiding the key under the doormat. A determined attacker will be able to find both the encrypted blob and the decryption key, and then manually decrypt the license key. Or, an attacker can simply debug your application and wait for the application itself to decrypt the key and then steal it from there.

4. Encrypting the string and storing the key on your server

   This is the same as 3., except way more difficult for you to implement. An attacker can again simply wait for the application to decrypt the license key and then steal it.

Why is this so hard?

Many many software companies try to implement DRM, and all of them get cracked. The reason for this is because any software that checks whether or not a check succeeded can be manipulated by the attacker to always make the check succeed. It is essentially impossible to make software that the attacker cannot manipulate, unless you use a system that is completely locked down from the hardware up (iPhone, Nintendo Switch, etc.), and even then attackers usually find weak spots that circumvent DRM.