Mattias Lindberg : .NET Framework

Validating XML Digital Signatures with References Using Unrecognized URI Prefixes

mattlind — Tue, 10 Oct 2006 15:16:00 GMT

During the last few month I have been working on and off on a solution which implements security features for a larger project, part of this work has been to create a wrapper around the XML Digital Signature functionality of .NET Framework 2.0. I thought that I would share a solution to a problem related to validating messages that has reference URIs on the form "cid:<somename>", some of you may recognize this as a reference to a Content-ID (cid) in a MIME message.

I had a signed message that looked something like the sample at the end of this post. Make note of the <Reference> elements and examine the URI attributes.

This XML message was the body of a multipart MIME message and each URI references a message part in the MIME message through the MIME Content-ID. If you load this message in a SignedXml instance and call CheckSignature you will receive the error: "The URI prefix is not recognized". This error is not unreasonable as SignedXml tries to use the URI to resolve the reference but cannot do that, but I still needed to validate the reference.

I tried various ways to work around this problem. The one that I thought had most merit tried to add Reference instances (associated to the SignedXml instance) which were loaded with the proper data and URI, but neither that nor any other attempt involving pre-populating data in the SignedXml were successful. However, while working with this problem I was examining the call stack of the "The URI prefix is not recognized" error when the solution became obvious to me. Below is a recreation of the call stack:

System.NotSupportedException: The URI prefix is not recognized.
at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
at System.Net.WebRequest.Create(Uri requestUri)
at System.Security.Cryptography.Xml.Reference.CalculateHashValue(XmlDocument document, CanonicalXmlNodeList refList)
at System.Security.Cryptography.Xml.SignedXml.CheckDigestedReferences()
at System.Security.Cryptography.Xml.SignedXml.CheckSignature()

I realized that it was WebRequest.Create that threw the error, but as this is an extensible part of .NET all I have to do is to registering "cid" as a valid URI with .NET! If you enable "cid" by calling WebRequest.RegisterPrefix then WebRequest.Create will be able to lookup the reference based on the URI. Below is a description of the steps involved in the solution:

To register "cid" as an URI in .NET you do this: bool registrationResult = WebRequest.RegisterPrefix("cid:", new CidRequestCreator());
Use the classes and techniques described in http://support.microsoft.com/kb/812409/EN-US/ to create the CidRequestCreator, CidWebRequest and CidWebResponse. The KB article describes how to do implement support for the "FTP" URI prefix, so I modified it to work with "cid" the way I wanted it to (read the data stream from a file based on the URI).
Before calling SignedXml.CheckSignature you need to save the attachments to the folder from which the CidWebRequest classes read messages.

Below is a high-level example of the logical steps that needs to be performed in my solution:

RegisterCidUriPrefix();
foreach(string uri in _attachments.Keys)
{
SaveAttachmentToDisk(uri, _attachments[uri]);
}

SignedXml signedXml = new SignedXml(xmlDocument);
XmlNodeList nodeList = xmlDocument.GetElementsByTagName("Signature");
signedXml.LoadXml((XmlElement)nodeList[0]);

res = signedXml.CheckSignature();

Please note that RegisterPrefix is only required to be called once per process (or it might be per application domain), this means that if you call it multiple times it will only return true the first time and additional calls will return false. I do not know how expensive the call the RegisterPrefix is, but it might be a good optimization to keep track of if you already have called RegisterPrefix and avoid calling it multiple times.

While customizing the FTP-sample I was able to remove most of the properties of request and response classes, but I also needed to add a Close method to the CidWebResponse class as the stream to the file needs to be closed. The file stream was opened in the constructor of the CidWebRequest class.

Sample of a signed XML message:

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Header>
    <DroppedStuffNotRelevantToThisDiscussion />
    <Signature xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
              <XPath xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">not(ancestor-or-self::node()[@SOAP:actor="urn:oasis:names:tc:ebxml-msg:actor:nextMSH"] | ancestor-or-self::node()[@SOAP:actor="http://schemas.xmlsoap.org/soap/actor/next"])</XPath>
            </Transform>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>qBkMHkzxhFGG9HJ1j01u+rrVfGM=</DigestValue>
        </Reference>
        <Reference URI="cid:msg400123456">
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>WHi7LauQVMt1IfJ3fXqorKEnWFs=</DigestValue>
        </Reference>
        <Reference URI="cid:msg400123456">
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>+3ZwEOqRmtGtrSfzhicq8lem0w4=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>Ay1DK.../OdTLc=</SignatureValue>
      <KeyInfo>
        <X509Data>
          <X509Certificate>MIID9...stEw</X509Certificate>
        </X509Data>
      </KeyInfo>
  </Signature>
  </SOAP:Header>
<SOAP:Body>
</SOAP:Body>
</SOAP:Envelope>

Notes on .NET 3.0 (WinFX) Tour Video

mattlind — Fri, 11 Aug 2006 10:30:00 GMT

MSDN Showtime has a show related to .NET 3.0, the show is called .NET 3.0 (WinFX) Tour and was recorded in Rotterdam (Netherlands). The show covers Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), InfoCard and Windows Workflow Foundation (WF). There are two shows with a total of almost 2 hours of info.

The first show (50 min), presented by Ami Vora, starts with an introduction to .NET 3.0 followed by a small demo of InfoCard. I must admit that this was the first time I really took time to listen/read about what InfoCard is all about, and I was a bit surprised... My impression from this show was that it looks like an advanced version of Passport. The main part of the show (25 min) is about WCF and the most of the time is spent on creating a small demo application by live coding.

The second show (1 hour) is about WF and WPF. Clemens Vaster is the presenter for WF and I think he makes a good case for WF. However, I think the demo coding (30 min) was not as structured as I would have liked it to be, I was having problems understanding exactly what he was doing and why. The WF stuff gets hidden in all the coding and talking. In the end there is 10 min on WPF presented by Paul Tallet, which to me felt as too short!

One thing I did learn during Clemens demo was that there is a static method on System.String called IsNullOrEmpty. Using this method eliminate the errors you can do when writing if(str == null || str.Length == 0).

As I'm someone who focuses on distributed applications and BizTalk I found the WCF and WF information most interesting, even though I had heard most of it before. If you like to learn more about .NET 3.0 (WinFx) I think this is a good introduction, specifically I think the first part is very good.

traceHelper: Multi-level tracing to OutputDebugString and file

mattlind — Mon, 17 Jul 2006 12:00:00 GMT

The third and final (for now) support class I wish to describe is called traceHelper, as the name suggests this class helps you to include tracing capabilities in your applications. It allows you to use a multi-level trace system where you at run-time can control how much of the trace information is outputted.

In its simplest usage this class is simply a wrapper around System.Diagnostics.Trace, but is can also be used to trace to file while controlling the amount of trace that is written to the log (using the traceLevel feature).

Please note that this class has a dependency on the configurationHelper class, which is described and can be downloaded here. If you wish to use some other configuration tool you will have to modify the code!

Sample Usage

void SomeMethod(int maxRows)
{
    traceHelper.WriteLine(3, "SomeMethod: Entry");

    if(maxRows < 1)
    {
        traceHelper.WriteLine(2, "SomeMethod: Warning: maxRows was <1, defaulting to 1");
        maxRows = 1;
    }

    try
    {

        // do something
    }
    catch(Exception ex)
    {
        traceHelper.WriteLine(1, "SomeMethod: Error retrieving data from database: " + ex.ToString());
        throw;
    }
}

Using traceLevels

Trace levels are positive numbers with no restriction to any hard-coded values, use whatever you like. However, I always try to use the following guidelines for trace levels:

1 - Errors: Used in catch-blocks and before returning error codes to callers.
2 - Warnings: I have to admit I don't use this much, but when needed it's there.
3 - Information: Interesting stuff that may help to understand the flow of the application when "debugging" in a production environment. Examples are: high-level method entry/exit and useful data which can be used to understand how the application executes.
5 - Very Detailed Information: Things that will not be interesting to other people than the developer of the specific code. Examples are: method execution times (using timerHelper), chosen case-statement in a switch and low-level method entry/exit.

Controlling Trace Output

traceHelper will always trace using System.Diagnostics.Trace (which ultimately calls OutputDebugString) and it can optionally also log to a file. You can specify the path to the log file as well as the base filename, but traceHelper will append the date and time (formatted as yyyyMMddTHHmmss) along with the process id of the tracing application. I always use DebugView from sysinternals.com to view trace output.

You may control the maximum size of each trace file as well as the maximum total trace size (sum of all trace files), when the max size of a single trace file is reached a new file is created. The max total trace size is useful to ensure that the log files don't fill the disk.

During the development phase of a project there is an inconvenience related to the max total trace size... Checking and removal of old trace files is only performed a trace file reaches max size. This means that when you during development (and test) constantly restart your application you will always get a new trace file and the max size is never reached. As a result you may have 100 0.5 MB files even though max total size is 20 MB, but as soon as a single file reaches the 1 MB limit trace files will be removed to ensure that only 20 MB is used in total. However, in a production environment this should not be a problem as you don't restart the application all the time.

Configuration for traceHelper

Below is a sample config-file (to be parsed by configurationHelper) which controls some of the settings for traceHelper.

<?xml version="1.0" encoding="utf-8"?>
<configurationHelper>
    <appSettings>
        <appSetting name="traceHelper.TraceEnabled" value="true" />
        <appSetting name="traceHelper.TraceLevel" value="3" />
        <appSetting name="traceHelper.File.Enabled" value="true" />
        <appSetting name="traceHelper.File.Filename" value="MyApplication" />
        <appSetting name="traceHelper.File.Path" value="C:\Temp\" />
        <appSetting name="traceHelper.File.MaxFileSizeInMb" value="5" />
        <appSetting name="traceHelper.File.MaxTotalFileSizeInMb" value="20" />
    </appSettings>
</configurationHelper>

Conclusion

I find this class very useful (hence sharing it with you) as I can add any amount of tracing to my application and then turn everything off but the essential stuff, and if I need more information I can turn it on at any time I choose. But what makes it really useful is the ability to also log to file, that way you can go back a few hours or days and see what caused a problem without having to try to reproduce it.

When debugging in test or production systems I usually use DebugView to monitor the trace live on one machine and when an error occur I use the log files from the other machines to see what they were doing at the same time.

I hope you find this class as useful as I do.

configurationHelper: Easy to use config-store

mattlind — Mon, 10 Jul 2006 23:30:00 GMT

configurationHelper is the second utility class I will discuss, it provides a simple and flexible configuration system that do not require you to predefine configuration entities in a schema.

Location of config-file
The configuration information is stored as key-value pairs in an XML file. The file is stored on disk and the location of the file is stored in the Registry, when the configuration information is first accessed it is read from disk and cached as a static field.

For each customer where I implement this I customize the Registry key to match the company name, hence I have used Contoso in the example below. The filename is stored in the default value for the key HKLM\Software\Contoso\Configuration, and it is a complete path and filename.

Access configuration values
All access to configuration information is done using calls to a static property, so there is no need to create instances of the class. Here is a typical example of accessing config information: string level = configurationHelper.AppSettings["traceHelper.TraceLevel"];

All configuration values are strings, so if you wish to store integers or boolean values you will have to convert them to their proper type. Typically this can be done using Convert.ToInt32(configValue).

Format of config-file
As mentioned above the configuration information is in the form of key-value pairs. All keys that are inserted will automatically be available to users, there is no need to register a config key in a schema or anything like that. An example of a config-file is:
<configuration>
<appSettings>
    
    <appSetting name="traceHelper.TraceEnabled" value="true" />
    <appSetting name="traceHelper.TraceLevel" value="5" />
</appSettings>
</configuration>

Reloading values when config-file is updated
Even though the configuration information is cached it is very dynamic. During initialization it creates a FileSystemWatcher which monitors changes to the config-file, and if it is updated the contents is reloaded. This means that if you change, add or remove a value it will immediately take affect. At least this works for windows applications and web applications, but when I used it in a BizTalk (2004) project it did not reload when the file was changed. I have no explanation for this behavior (perhaps it’s related to security/privileges) but now you know that there might be a problem…

Pros and cons
I find the biggest advantage of this class to be its flexibility and ability to be used in many different types of applications. When a developer needs a new configuration value he simply adds it to the config-file.

The flexibility may also be a disadvantage when working in a multi-developer multi-server environment. When a developer adds a new configuration value it might affect all developers and if the application is in production the change has to be migrated to multiple servers.

You can also consider access to config-info a security issues, especially if you keep username and/or passwords in clear-text. You can always use ACLs on the config-file, but the real solution is to NEVER store sensitive information unecrypted regardless if the storage is a file or a database.

Having a central storage of configuration information would make it simpler in some cases. If you consider central storage a requirement then you should look at the Enterprise Library, it’s more complex but also allows for less flexibility.

timerHelper: Provides high-precision timing

mattlind — Mon, 26 Jun 2006 12:00:00 GMT

The first utility class I intend to describe is timerHelper. The purpose of this class is to provide a high-precision timing function. Please note that it is not a timer that issues events, instead is used to measure how long something has taken to execute. The purpose of providing an additional timer (there are several available in .NET Framework) is that this implementation provides more accurate timings.

I use it to time frequently called or long-running methods in my code to gain an understanding of how long these tasks take. With the new code profiling features of Visual Studio 2005 you can get this information during system testing, however using the timerHelper class you can get the timings even in a production environment which may help you understand where your bottlenecks are in a live system. Also, I sometimes think that the VS profiling provides you with too much information to drill down into (which also is a good thing).

Another reason I prefer this class over VS profiling is that I can use it in any type of application; windows app, windows service, web, BizTalk, MIIS, etc. Most of my projects involve BizTalk and there is no profiling support for BizTalk.

The implementation is based on a utility class got sent to me on a mailing alias in September 2001. I took that class and made a few simplifications, e.g. removing some statistical functions. Over the years the class has only had minor changes made to it, and just recently I made it even simpler to use by starting the timer in the constructor (previously you had to call Start).

Typically the class is used like this:

timerHelper timer = new timerHelper();

// Execute some code here which should be timed!

Trace.WriteLine("methodname: Duration: " + timer.StopDuration() + " ms");

There some more "advanced" scenarios where you stop and get the duration multiple times, thereby getting partial and complete timings. Each call to Stop will only timestamp the end time, the start time remains the same, so by not restarting the timer you can get "lap times" while still getting the full "race" time.

The actual implementation of timerHelper is an encapsulation of the Win32 APIs QueryPerformanceCounter and QueryPerformanceFrequency.

You can find the implementation file as an attachment. Download it and give it a go!

An alternative implementation can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto09.asp. I guess we have started from the same file back in 2001 as the basic design is identical to my class. However, this class uses nanoseconds instead of milliseconds so if you need extreme precision this might be an option. For me milliseconds are just fine as I mostly time things that are in the millisecond range (if not even seconds).

[Update]:

As Richard noted in his comment .NET 2.0 provides us with the System.Diagnostics.Stopwatch class, which does essentially the same thing.

Utility classes for timing, tracing and configuration

mattlind — Mon, 26 Jun 2006 11:59:00 GMT

In a series of four articles (including this) I will discuss three utility classes that I frequently use when I as a consultant write code for my customers. These classes have been in development for a long time, timerHelper since 2001 and the other for a couple of years, and most times I have used them in a project they have been extended and bugs have been fixed. The classes I will discuss are:

timerHelper: High-precision timer class. Used to measure duration of millisecond operations.
configurationHelper: Easy to use configuration store, can be shared among multiple applications.
traceHelper: Support for multi-level tracing which can write to both OutputDebugString and to file.

The functionality of two of these classes, configurationHelper and traceHelper, are at least partially available in the Enterprise Library for .NET Framework 2.0 (EL). Why have I, as a Microsoft employee, choosen not to use EL? The reason is simple, EL is big and complex while my classes are extremely light-weight and easy to use. If the customer I work with already have chosen to use a utility framework (either EL or something else) I will have no problem using that (but hasn’t happened yet :-).

I admit that using these classes has an element of "not invented here", when someone suggests something else I make an argument for my classes. But if I can get other people to accept the simplicity of my classes then I guess they must have something that is worth having.

I intend to include source code for all three of these classes. And while all have been used in production environments for a while I make no guarantees of functionality (proper disclaimer will be included!).

The first class discussed will be timerHelper. Next up is the configurationHelper and last will be the traceHelper. The reason for this order is that timerHelper is simplest so it's easiest to start with, and as traceHelper uses configurationHelper it cannot be discussed before that class.

Confusion among developers: .NET Framework vs. CLR versions

mattlind — Wed, 21 Jun 2006 16:02:00 GMT

As you have already heard it was annonced some two weeks ago that WinFX will now be called .NET Framework 3.0.

While it might make sense from a markering perspective to do this it will probably create confusion among developers. The reason is that .NET Fx 3.0 will contain Common Language Runtime (CLR) 2.0 along with C# 2.0 and other components of the .NET Framework 2.0. In essence, .NET Fx 3.0 is .NET Fx 2.0 extended with a set of new libraries for WCF, WF, WPF and InforCard.

The problem with decoupling the .NET Fx version from the CLR version is that it becomes ambiguous what we mean when we say .NET.

Up to now it has been quite easy to understand which component of .NET belongs to which version. A statement like "I'm running .NET 1.1" clearly identify CLR version and Framework version. In the future when you hear "I'm running .NET 3.0" you will have to ask if it's .NET Fx 3.0 or CLR 3.0 (which may be part of .NET Fx 4.0).

And it's not like we haven't had this problem before. In the mid-90s Microsoft skipped versions in Visual C++ to syncronize Visual C++, MFC and Visual Studio version numbers. And who doesn't remember the more recent talk about Windows .NET Server, Office .NET and .NET Enterprise Servers a couple of years ago when everything should be .NET.

Those of us who continue working with .NET Framework and CLR will see if the versions will diverge or converge. But for now (and a couple of years ahead) we will have to practice causion and not draw immediate conclusions about which version of .NET Fx and CLR people are talking about.

Library for creating MIME messages

mattlind — Mon, 19 Jun 2006 12:13:00 GMT

A tool that I have recently made use of is a library from Code Project. The library helped me to easily build MIME messages. As I was providing a high-level API to another caller I created a wrapper around the specific classes and methods exposed by this library.

The library can be found at http://www.codeproject.com/useritems/MIME_De_Encode_in_C_.asp. If you need to create MIME messages then check this out!

PInvoke.net

mattlind — Thu, 15 Jun 2006 14:48:00 GMT

During my adventures in CryptoAPI land I found a web site that has helped me to create appropriate P/Invoke declarations.

The site is called www.pinvoke.net and it contains P/Invoke declarations for a large number of Win32 APIs (always in C# and sometimes in VB) as well as a few examples. Even though not all Win32 APIs can be found there I found most of the ones I was looking for.

A great resource!

An example:

[DllImport("CRYPT32.DLL", EntryPoint="CertOpenStore", CharSet=CharSet.Auto, SetLastError=true)]
public static extern IntPtr CertOpenStoreIntPtrPara( int storeProvider, int encodingType, IntPtr hcryptProv, int flags, IntPtr pvPara);

First post

mattlind — Wed, 14 Jun 2006 00:06:00 GMT

There are lots of interesting stuff happening right now! Primarily I'm thinking about BizTalk Server 2006 R2 and .NET Framework 3.0 which was both announced last week. Therefore I felt that this was a great time start blogging, lots of news to keep the interest up (both for me and for any readers).

BizTalk Server 2006 R2 will improve several areas of BizTalk, among those are built-in support for EDI/AS2 and RFID. Current version has a Base EDI adapter but the new functionality will provide a more complete implementation. Read more at http://www.microsoft.com/presspass/press/2006/jun06/06-06EtEBusinessProcessPR.mspx.

.NET Framework 3.0 was announced on Friday at http://blogs.msdn.com/somasegar/archive/2006/06/09/624300.aspx, the poster is the Corporate VP of the Microsoft Developer Division. In short Microsoft has decided to offically name what was previously called WinFX to .NET Framework 3.0. WinFX consists of technologies such as Windows Presentation Foundation (WPF, previously Avalon), Windows Communication Foundation (WCF, previously Indigo), Windows Workflow Foundation (WF) and the components from .NET Framework 2.0 (CLR 2.0, ADO.NET, etc.).

I'm sure both of these are topic to revisit in coming weeks and months.