How can I "protect" my public key in my .NET code once deployed?
<p>I am designing the licensing part of my application.  It will using something like <a href="https://jwt.io/" rel="nofollow">JWT</a> from my licensing server to issue claims that my code running on workstations will use to enable functionality.</p>

<p>The server will sign the claim with its private key, and the client will use the public key to verify the signature.  As it currently stands this will be done in .NET with C#.</p>

<p>If an attacker can replace my server's public key with their own, they can set up a fake server to issue licensing claims and enable functionality they are not entitled to.</p>

<p>What steps can I take to make it hard for an attacker to find and substitute a public key in C#?</p>

<p>Specifically, should I use and trust as robust an obfuscation library?</p>

<p>I recognise no protection is absolute.  If I allow my code to be run on a machine I do not control, then with enough skill, motivation and resources an attacker will be able to recover the data.  I will settle for making it hard enough for moderately skilled individuals with the resources of a person or a small corporation.</p>

<p>One of the open source obfuscators available that I plan to investigate is <a href="http://yck1509.github.io/ConfuserEx/" rel="nofollow">ConfuserEx</a>.</p>

<p><strong>Edit:</strong></p>

<p>Some responders think I've got the issue around the wrong way.  I respectfully disagree.  The issue is a <em>little</em> analogous to an attacker adding their own certificate to a browser's certificate score, and setting up their own rogue banking banking site that fools the browser.</p>

<p>However the analogy fails here.  The issue is not the classical one of PKI, "how does the end user's (trusted) client verify trust in the server", but more that of DRM in a semi-hostile environment.  The risk under consideration is not loss of confidentiality or integrity for the user, but of control of where, when and how the core application is run.</p>

<p>Up until now I hadn't been thinking in terms of DRM, but I think that is the best description, and I admit that doesn't sit well with me.  DRM generally has a negative user impact and requires massive effort from the developer/provider, and still ends up broken, sometimes trivially.</p>

<p>Still, I feel the original question still stands, as I want to take reasonable steps to protect my work.</p>