WCF Encryption solution for App.config viewable to a client?

Question

I have a desktop application which contains an App.config (program.exe.config at release) with clearly visible elements which define my WCF endpoints and WCF implementation.

I would ideally like to hide this from the users eyes, from simple hacking, view and change.

Should I: -

1. Programmatically create and store my WCF endpoints and binding configuration in code. or;
2. Implement some protection scheme over the App.config (if so, what, how), effectively obfuscating/encrypting these elements from public view, but understandable from my code?

I already utilise .NET Reactor to obfuscate and protect my program from reflection techniques.

Update 13-May-09 3:32 GMT+10 Alright well I managed to encrypt system.serviceModel but then it proved unusable when the app went to launch as an exception was thrown (System.TypeInitializationException: The type initializer for 'System.ServiceModel.DiagnosticUtility' threw an exception.)

  <system.serviceModel>
    <!-- [bindings] -->
    <bindings configProtectionProvider="DPAPIProtection">
      <EncryptedData>
        <CipherData>
          <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+...

So there goes that idea. I'll either ditch this idea, or set my endpoints in code which is behind encryption.

Isn't anybody else concerned about their endpoint addresses clearly visible in config???

Answer 1

I would ideally like to hide this from the users eyes, from simple hacking, view and change.

You really can't protect against this, because anyone who wants to figure out what it's doing just sets a breakpoint on the WCF Endpoint class constructor then hits "go". No amount of obfuscation will help you there.

Answer 2

Protecting it from change is easier that protecting it from view.

If it is simply change/hacking you are worried about, you can just compute a digital signature on the XML elements that comprise your unchangeable WCF settings, using your public key. If the customer changes anything, the sig won't match.

I don't know a good way to protect it from view, really, because a determined person is going to be able to find out what you are doing in WCF (as the previous poster pointed out). You could make it more difficult, but that wouldn't be preventing someone from viewing or learning the information.

UPDATE :

You need to use your own RSA private key for signing. Maybe you have an RSA keypair already. If not, you might generate a keypair, once, to do the signing. Like this.

        int keySize = 1024; // you choose
        byte[] key = Keys.GenerateKeyPair(keySize);

        RSACryptoServiceProvider rsaKey = new RSACryptoServiceProvider();
        rsaKey.ImportCspBlob(key);

Once you have that, you can export and save it. For your own use, signing, you want the private key. For verification, apps will use the public key. This is how you get them.

        string PublicKeyXml = rsaKey.ToXmlString(false);
        string PrivateKeyXml = rsaKey.ToXmlString(true);

Store these. If you ever want to sign something again using the same private key, get the RSA CSP with the FromXmlString() method, passing the PrivateKeyXml. If you want to verify, use FromXmlString() passing the PublicKeyXml.

Once you have the key and the XML to be signed, you can do the signing. This happens just during packaging and deployment, when you create and finalize the configuration.

    // Sign an XML file. 
    // This document cannot be verified unless the verifying 
    // code has the key with which it was signed.
    public static void SignXml(System.Xml.XmlDocument Doc, RSA Key)
    {
        // Check arguments.
        if (Doc == null)
            throw new ArgumentException("Doc");
        if (Key == null)
            throw new ArgumentException("Key");

        // Create a SignedXml object.
        System.Security.Cryptography.Xml.SignedXml signedXml = new SignedXml(Doc);

        // Add the key to the SignedXml document.
        signedXml.SigningKey = Key;

        // Create a reference to be signed.
        Reference reference = new Reference();
        reference.Uri = "";

        // Add an enveloped transformation to the reference.
        var env = new XmlDsigEnvelopedSignatureTransform();
        reference.AddTransform(env);

        // Add the reference to the SignedXml object.
        signedXml.AddReference(reference);

        // Compute the signature.
        signedXml.ComputeSignature();

        // Get the XML representation of the signature and save
        // it to an XmlElement object.
        XmlElement xmlDigitalSignature = signedXml.GetXml();

        // Append the element to the XML document.
        Doc.DocumentElement.AppendChild(Doc.ImportNode(xmlDigitalSignature, true));
    }

Then, embed the signed XML into app.config or as a string in the app, or whatever. When the app runs, you verify the signature at runtime, using the public key blob.

        // Verify the signature of the signed XML.
        RSACryptoServiceProvider rsaCsp = new RSACryptoServiceProvider();
        rsaCsp.FromXmlString(PublicKeyXml);

        bool isValid = VerifyXml(xmlDoc, rsaCsp);

Here's some code that does signature verification:

    // Verify the signature of an XML file against an asymmetric 
    // algorithm and return the result.
    public Boolean VerifyXml(XmlDocument Doc, RSA Key)
    {
        // Check arguments.
        if (Doc == null)
            throw new ArgumentException("Doc");
        if (Key == null)
            throw new ArgumentException("Key");

        // Create a new SignedXml object and pass it
        // the XML document class.
        System.Security.Cryptography.Xml.SignedXml signedXml = new SignedXml(Doc);

        // Find the "Signature" node and create a new XmlNodeList object.
        XmlNodeList nodeList = Doc.GetElementsByTagName("Signature");

        // Throw an exception if no signature was found.
        if (nodeList.Count <= 0)
        {
            throw new CryptographicException("Verification failed: No Signature was found in the document.");
        }

        // Though it is possible to have multiple signatures on 
        // an XML document, this app only supports one signature for
        // the entire XML document.  Throw an exception 
        // if more than one signature was found.
        if (nodeList.Count >= 2)
        {
            throw new CryptographicException("Verification failed: More that one signature was found for the document.");
        }

        // Load the first <signature> node.  
        signedXml.LoadXml((XmlElement)nodeList[0]);

        // Check the signature and return the result.
        return signedXml.CheckSignature(Key);
    }

To test that your signature and verification actually does work, modify either the signature or the xml content that has been signed. You should see the verification fail. In the case of failed verification, your app might throw, or exit, or whatever.

Answer 3

I'm guessing option 1 is probably your best bet. That said, I do wonder if it's worth it (assuming you don't have anything really sensitive on the config file, like credentials or anything else). Reason I bring this up is that, if you're concerned about your endpoint URLs and such, well, anyone with very basic tools can figure that out in a few seconds using a network protocol analyzer.

Answer 4

You can give protected configuration in .NET a try but it is not very simple. You need to encrypt the config file on the client machine as the protected configuration providers may produce machine specific encypted data. In other words, if you encrypt the configuration section on your machine or the build machine, you may not be able to decrypt it on client machines. You may also export and import encryption keys onto client machine. Therefore, you will have to do something during the installation where you install a key on the client machine and you use that key to encrypt the configuration section. Take a look at Implementing Protected Configuration With Windows Apps . As you can see, this is really not a very easy and clean solution and adds up complexity in terms of deployment.

On the other hand, configuring WCF on the client side programmatically is easy. You can set up the binding and endpoint in the code. You may want to keep the address or url in the config file if you still want to leave some flexibility via configuration to direct clients to a different url without a new build. I think this is the best approach as I don't think that your bindings and endpoints are likely to change once you test and deploy your application. But you know your requirements better :-) I would say don't overengineer or apply a heavy and expensive solution to something that may really not be a realistic concern.