XML Digital Signatures with SignedXML, Part 1

The SignedXML class creates an XML Signature tag (node) that wraps around (encapsulates) the XML data that is signed. Shown below is an outline of the basic XMLDSIG Signature as created by the .NET implementation with the DigestValue, SignatureValue, and RSAKeyValue element contents removed for readability. The message that is signed appears in the XML within an Object node that is assigned an object ID during the signature creation shown in Listing One.

<Signature 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="#Message"><DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue> </DigestValue>
</Reference></SignedInfo>
<SignatureValue> </SignatureValue>
<KeyInfo><KeyValue xmlns="http://www.w3.org/2000/09/xmldsig#">
<RSAKeyValue><Modulus> </Modulus>
<Exponent> </Exponent>
</RSAKeyValue></KeyValue></KeyInfo>
<Object Id="Message"><Plaintext xmlns="msg">This is the plaintext message.

Verifying XMLDSIG Signatures

Verifying a signature that has previously been attached to signed XML requires fewer steps because the key and hash information is already selected for us by whomever or whatever created the XMLDSIG Signature tag. The SignedXML class automatically creates the proper objects and extracts the public key from the signature's KeyValue tag, uses it to decrypt the hash code, and then recomputes the hash code of the original data (the message) to confirm that it matches the one found in the signature. Listing Two shows the steps required to verify an XML signature:

Listing Two

AsymmetricAlgorithm pubkey;
XmlDocument xmlsignature = new XmlDocument();
xmlsignature.PreserveWhitespace = true;
xmlsignature.LoadXml(signature);
System.Security.Cryptography.Xml.SignedXml sigverif = new SignedXml();
sigverif.LoadXml(xmlsignature.DocumentElement);
if (sigverif.CheckSignatureReturningKey(out pubkey)) 
{ Console.Out.WriteLine("Signature Verified. Public Key:
 " + pubkey.ToXmlString(false));
} 

The System.Security.Cryptography.Xml namespace is provided as part of .NET Framework version 1.1 and was not available under version 1.0; therefore, Visual Studio .NET 2003 was the first edition of Visual Studio .NET that was capable of using the SignedXML class. We'll take a deeper look at this namespace and other features of .NET that integrate cryptography with XML in the next newsletter.

Correcting a Mistake

The last article in this newsletter contained a rough sample application written in C# that was intended to extract the public key and information about its apparent owner from a digitally signed file. Unfortunately, the sample was a little too rough and it didn't compile as shown. Below is a replacement sample that does compile, with a minor usage modification whereby errors caught in the try/catch blocks are output to standard error rather than standard output. This makes it possible to redirect the output of the program to a file, giving you only the signatures, one per line, and no extraneous information in the file.

using System.Security.Cryptography.X509Certificates;
using System.IO;
namespace PKInventory 
 { class main 
     { [STAThread] static void Main(string[] args) 
        { X509Certificate xcert = null;
         try { DirectoryInfo d = new DirectoryInfo
               (Directory.GetCurrentDirectory());
         FileInfo[] allFiles = d.GetFiles();
         foreach (FileInfo f in allFiles) { try { xcert = 
         X509Certificate.CreateFromSignedFile(f.Name);
         Console.Out.WriteLine(f.Name + "\t" + xcert.GetName() + "\t" 
         + xcert.GetPublicKeyString());
         } 
      catch (Exception sigErr) 
        { Console.Error.WriteLine(f.Name + 
          ": Unable to read DER-encoded signature.");
        }
      }
    } 
    catch (Exception e) 
      {Console.Error.WriteLine(
        "Unable to read directory. Error: " + e);}
    }
  }
}

It should also have been noted in the previous article that most Windows binaries ship without a digital signature. Instead of signing each file, Microsoft relies on Windows File Protection (WFP) and the Security Catalog (.CAT file) mechanism to do whatever it was that Microsoft thought WFP was supposed to do (i.e., put an end to DLL Hell) with the help of these detached signatures. As discussed previously in this newsletter, WFP has some serious design flaws that pose security risks and that also undermine the relief from DLL Hell that WFP might otherwise provide. Use the code shown here to extract signature details from each .CAT file that you find under \system32\CatRoot\ in addition to directories that contain actual signed binaries in order to get a more complete picture of the software publisher key rings upon which your trust policies are presently based. If we don't manually examine keys and keep track of the ones that we already trust, then we do away with any meaningful security protection that PKI is supposed to provide for interorganization trust. After all, the whole point of relying on PKI for service identity authentication or software publishing is to improve our ability to make judgment calls about interorganization trust.

Jason Coombs works as forensic analyst and expert witness in court cases involving digital evidence. Information security and network programming are his areas of special expertise. He can be reached at [email protected].