views:

878

answers:

4

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???

+2  A: 

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.

tomasr
I understand that, I just feel it would be neater hidden, also I primarily want to do it so they cannot alter the application's execution, which they could do so very simply by altering the endpoint url. I'm not concerned about security, they can do what they want with the url if they had it, all services are locked behind a usr/pwd combo.
GONeale
You can definitely put your config elsewhere - but where? Database? Is it going to be encrypted there? Basically, if your web server is accessible to outside forces, then you have MORE pressing problems than endpoints in cleartext in your config file, IMHO.
marc_s
+3  A: 

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.

Cheeso
@Cheeso could you give me an example? or link me to an article demonstrating this? I don't know much about signing but it does sound maybe what I am after on the altering side of things.
GONeale
I added some example code above illustrating the idea.
Cheeso
That looks great and would meet my requirements for a tamperproof config. Thnx Cheeso. I'll write back when I get a chance to test it.
GONeale
I still have not had a chance to test this, but is the most relevant answer submitted, cheers dude.
GONeale
+1  A: 

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.

Mehmet Aras
Thanks Mehmet, I haven't been back on this post for a while because I had actually found that url and was following it! Right now I have protected xml elements, but not the stuff in <system.serviceModel> and really don't know if I will be able to at this stage.
GONeale
Yes well I think configuring endpoint and binding info in code is realistic, only for the fact it won't change much, and if it does we have a clickOnce deployment solution which will get it out there to all users.
GONeale
+3  A: 

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.

Paul Betts
As stated in tomasr's post, I am not entirely concerned about them finding out what it's doing, or if they are keen, knowing the url. As it is all password protected, I just don't want them to be able to alter the data. If this turns out too hard, due to it not being a major thing I might forget about it all together..
GONeale
Also.. they can't setup a breakpoint on the WCF endpoint class constructor as they can't even open my class in .NET Reflector.
GONeale
No, they don't need to open your class, they open the *Framework* class in a live debugger. 100% unobfuscated.
Paul Betts