Mattias Lindberg : Security

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>

Lesson learned: Cannot unlock software certificate pincode from code

mattlind — Wed, 14 Jun 2006 22:41:00 GMT

Due to a number of reasons we needed to ensure that the sender of a message, which we were going to sign, really knew the secret password/pincode to the certificate. The basic design of this is actually flawed but we could not change this as we only replace one component in a larger flow of information. But that is not relevant to the topic of this blog...

We were looking at utilizing Windows certificate store to hold the certificates so it was natural (we thought) to associate a pincode when importing the certificate. What happens is that when you try to open the certificate you will be prompted by Windows to enter the pincode through an interactive dialog. Now all we had to do was to write some code that, in run-time, unlocked the certificate without displaying the interactive dialog.

We first tried used the CspParameters.KeyPassword property, but that didn't work due to what seems to a problem with .NET. This would have been really nice and clean solution, using new .NET 2.0 functionality to solve a problem. Had the fortune to discuss this with Shawn Farkas who had some good ideas.

As a result we tried doing CryptoAPI and .NET together. Our code looked something like this:

// Our method for getting a certificate
X509Certificate2 cert = InternalImpl.RetrieveX509CertificateByOrgNumber("984718268");

bResult = CryptAcquireCertificatePrivateKey(cert.Handle, 0, IntPtr.Zero, hCryptProv, dwKeySpec, boolRes);
if (!bResult)
{
int err = Marshal.GetLastWin32Error();
throw new Win32Exception();
}

bResult = CryptSetProvParam(hCryptProv, PP_SIGNATURE_PIN, new ASCIIEncoding().GetBytes("pincode"), 0)

// Do something interesting with the hCryptProv...

But we just kept getting error 0x00000057 (ERROR_INVALID_PARAMETER) when calling CryptSetProvParam. We changed the code and dropped the X509Certificate2 class and used a pure CryptoAPI implementation, but the problem remained the same.

What to do? I sent a mail to an internal mailing list and got a quick response, "CryptSetProvParam(PP_SIGNATURE_PIN) is used to set a PIN on a provider context for a smartcard csp. It is not recognized by software csps." This means that what we were trying to do is not supported!

I guess that the reason for this is that if you lock down a certificate in certificate store you do it to force user intervention. If you could code around this you would break the security.

Lesson learned:
Certificates that have been locked down using a pincode in the certificate store cannot be unlocked using code. A user will always have to enter the pin interactively.

I hope that describing this experience will help someone in the future.

How did we solve our problem?
We decided to put the certificate files (.p12 and .cert) on disk instead and open them using one of the constructor of X509Certificate2 that takes a password as parameter.
cert = new X509Certificate2(fullpath, password);

Actually this is the same design as the old system used, I guess there was a reason for it... But we really wanted to use the certificate store, so did an attempt and failed.

System.Security.Cryptography - Lots of new stuff in .NET 2.0

mattlind — Wed, 14 Jun 2006 01:05:00 GMT

Recently I've been working in a BizTalk project where my main task has been to develop a module that is used to help signing and encrypting messages. I have then had the opportunity to dive a bit deeper into the functionality provided by the classes in System.Security.Cryptography.

I have previously worked with some of the classes but I now realize that there are much new functionality in .NET 2.0. Important examples of new functionality are DPAPI and GZIP support.

Data Protection API (DPAPI) is part of the Win32 API and has been available for a long time on WIndows, but using it on .NET has always required using P/Invoke to declare these APIs. Now there is a class called DpapiCryptographer which makes it much easier to use and more accessible to everyone.

GZIP support is provided by GZipStream. Even though the compression ratio could be improved it appears to be fully compatible with other GZIP implementations. In my tests a 45 kB file was compressed to 6.5 kB by GZipStream while using the external tool GZIP.EXE resulted in a 4.5 kB file.

A great resource regarding cryptography in .NET is Shawn's .NET Security Blog, specifically the Cryptograpghy category which is found at http://blogs.msdn.com/shawnfa/archive/category/2868.aspx.