Programmatically creating the WCF certificate identity tag

SvcUtil let you automatically create the client configuration for a WCF service.

When you use a certificate on the server side, its public key is encoded in Base64 in the client web.config.

   1: <identity>
   2:      <certificate encodedValue="AwAAAA ...." />
   3: </identity>

Obviously SvcUtil create this information from metadata (wsdl).

Unfortunately there are cases where the service configuration is complex and you cannot enable mex endpoint easily. I had this problem when moving a WCF project from the desktop PC to the notebook and finally deploying.

The solution seems very simple:

   1: private static string GetEncoded(X509Certificate2 cert)
   2: {
   3:     byte[] export = cert.Export(X509ContentType.SerializedCert);
   4:     string encoded = Convert.ToBase64String(export);
   5:     return encoded;
   6: }

Please don’t do this at home 🙂 … this value is correct in many cases but for many other has a very dangerous side-effect. Export method exports a certificate in its whole. This means that if the certificate was installed with the private key, the export method write it too! For the sake of completeness, when you install a certificate you can choose to install the private key or not.

Certainly the private key should never go on a client machine, it would be like giving away your home keys to a stranger. GetEncoded method is correct but it writes too much information. We have to strip the certificate from the private key before exporting it.

So I digged the best way to strip the private key from the certificate. After some tests, I asked to a dear friend Mario Fontana (some CAPICOM stuff comes from his fingers) that remembered me that the DER format (the one that contains only the public key) can be obtained simply exporting the certificate with the parameter “X509ContentType.Cert”.

   1: byte[] der = certRaf.Export(X509ContentType.Cert); // solo public key

This is not sufficient since we absolutely need to export with SerializedCert parameter. The solution is easy: re-import the certificate.

   1: private static X509Certificate2 ImportFromBlob(byte[] certBlob)
   2: {
   3:     X509Certificate2Collection certs = new X509Certificate2Collection();
   4:     certs.Import(certBlob);
   5:     X509Certificate2 imported = certs[0];
   6:     return imported;
   7: }

The final step is obvious. Export the certificate obtained from the “ImportFromBlob” method using “GetEncoded” at the top of this post.
We now have the magic string used in the client WCF configuration.

Pay attention, this procedure is not “optional”. Giving away a private key is the worst thing in security you can do.

My TechEd interview has gone live

During the last TechEd developers in Barcelona, I was at the Ask The Expert in the Security Development Lifecycle booth with the SDL team and Michael Howard in person.
I had the chance to be interviewed in the Fishbowl, as a Threat Modeling expert.


On Monday I discovered that the video has gone live. In the video I talk about the importance of SDL, the new approach CIA / PI that simplify the DREAD / STRIDE classic concepts, and the Threat Modeling and Analisys tool by ACE team.

The video Url is the following:

Standard damages

I am evaluating a new device that has its own internal webserver. It’s a box that deals with some input signals that can be used via TCP/IP. It sounds great since it provides also WiFi port and is security enabled. All great standard way to communicate with a device, but (there is always a but smile_regular) …

  • Security is provided by encrypting the password with MD5. Sadly MD5 is completely defeated and should be used only for compatibility reasons. It’s very easy to crack MD5 in minutes by using MD5 Rainbow Tables. Simply MD5 should never be used for new things.
  • WiFi option is provided by using WEP encryption. Oh yes, the most standard thing about WEP is the crack!!! Its algorithm is completely compromised. By using reply-attacks anyone can crack a Wep in few minutes … you can do it also in seconds under certain conditions.

I had the chance to show Rainbow Tables techniques, WiFi and Pre-shared key WPA, and many other cracks during last october WPC conference in Milano. Showing hacking techniques it’s a good way to warn developers and adminstrators about the risks they assume.

Standards are a good thing but, even when they are proved to do the bad thing, you’ll have to keep them around for a long time. So we should all hope that standards don’t grow under the trees.

RafCollection is on Codeplex

I just finished uploading on Codeplex my RafCollection project that focus on a collection for building object models, support binding, etc.

You may think that’s too much for a collection class but the project is larger from what you may initially think. The main class is 2243 source rows and with the other classes the total is 3387 source rows.

Why all this stuff? Because I needed to have a super-powerful collection in order to keep my entities as simple as possible. So the collection takes care about full binding support, sorting, filtering, finding, building views, transactional support (AcceptChanges, RejectChanges, ..) and obviously state handling.
Well, to test the collection I needed few other things that are included in the project workspace. I am talking about an idea to load entities from the database and dealing with DBNulls, and obviously a small UI test project.

You may find on the projecy home page a long document that explain how it works and the reasons for all the choices I did in building this collection.

I was forgetting … sorry for my English, I hope the mistakes in the doc (and here in my new English blog) are greater than the bugs in the project [:)]

Enjoy! … and report bugs please [;)]