SignedXml.LoadXml() throws a CryptographicException

Question

I have a connection to an external WebService which was running flawless for ages until medio may 2018. Suddenly I started getting a CryptographicException with the message "Malformed XML Signature". My investigation tells me the following:

The exception is thrown from the line LoadXml(signature); in a class that inherits from System.Security.Cryptography.Xml.SignedXml

Here's the code:

public bool CheckAssertionSignature()
    {
        if (Xml == null || Xml.DocumentElement == null)
            return false;

        var xmlass = Xml.DocumentElement.LocalName == "Assertion" ? Xml.DocumentElement : Xml.GetElementsByTagName("Assertion", Namespaces.Saml)[0] as XmlElement;
        var signature = xmlass.GetElementsByTagName("Signature", Namespaces.Ds)[0] as XmlElement;
        if (signature == null) return false;
        LoadXml(signature);
        var cert = KeyInfo.Cast<KeyInfoX509Data>().Select(d => d.Certificates[0] as X509Certificate2).FirstOrDefault(c => c != null);

        return cert != null && CheckSignature(cert, true);
    }

What I've learned so far is: A colleague and I have tested the code locally on two different versions of windows 10. His version is newer than mine. He gets the error and I don't.

The xml processed by the code is identical

The error started on the 16th of may 2018 and on that date the server installed this security update https://support.microsoft.com/da-dk/help/4099635/security-and-quality-rollup-for-net-framework-3-5-4-5-2-4-6-4-6-1-4-6

We know that a similar update earlier caused a similar problem: https://support.microsoft.com/en-us/help/3148821/after-you-apply-security-update-3141780-net-framework-applications-enc

Has anyone an idea about how to solve this problem (and is anybody else experiencing the problem)?

PS. The code is running on a Windows srv 2012 R2 and the problem also exists on a windows srv 2016

pls provide the Windows 10 OS versions (yours and your colle's), and the `SignedXml` document, you should trim any sensitive data from the document, of course. — kennyzx, Jun 26 '18 at 07:21
I am the other colleague... We have discovered that the OS version not necessarily is the actual problem, but more likely an KB-update. Never the less, the OS version governs what updates is installed. A computer running 1511 don't get the exception. A computer running 1607 or 1703 get's the exception. But on one of the computers with Win OS 1703, we have just uninstalled KB4054590 (https://support.microsoft.com/en-us/help/4054530/microsoft-net-framework-4-7-2-offline-installer-for-windows), and now we don't get the exception any more. — baddaydaddy, Jun 26 '18 at 08:34
The update to the operating system probably had nothing to do with the fix except the cookies were deleted in the IE and/or the http version (1.0 vs 1.1). The only real way of debugging these issues is to use a sniffer like wireshark or fiddler. Compare the http headers between working and non working version. Then add missing headers in the request on non working system. For example the Content Type specifies the Webbrowser (IE / Chrome). So the default request may be IE which the server may not accept. Adding Chrome to the request which the server accepts will solve issue. — jdweng, Jun 26 '18 at 09:46
@jdweng I think you have the whole issue wrong. This has nothing to do with a httprequest. It is the handling of xml on the server, that throws up, when LoadXml is called. — baddaydaddy, Jun 26 '18 at 10:31
Have you tried the approaches (editing registry) in the link? Although they are not the same KB, maybe they are actually the same security patch, just one for desktop the other for server. — kennyzx, Jun 26 '18 at 11:48
I tried the SignedXmlAllowDetachedSignature property, and it did nothing (for the exception). The second solution changes the transform algorithm string in the xml from "...xpath..." to "...xslt...". But our has two completely different algorithm strings which is dictated by the response xml. I can not grantee this is NOT the problem, but the service-provider reports no changes and no error from their part. So my assumption is, that the problem is connected to some sort of software change on the server (and those computers that gets the same exception). — baddaydaddy, Jun 26 '18 at 13:59

score 1 · Accepted Answer · answered Jun 27 '18 at 10:53

We found a solution! It seems that the System.Security update has forced a more strict validation of the XML Signatures.

In the XML we receive, the Signature elements id property is written "id". According to Schema for XML Signatures (http://www.w3.org/2000/09/xmldsig#) it should be "Id". The LoadXml method before the security update did not throw up about this, but after it does.

Since the received XML is with the inappropriate attribute , we have create the following workaround to change the attribute:

if (signature.Attributes.GetNamedItem("id") is XmlAttribute oldId)
{
    signature.Attributes.Remove(oldId);
    if (signature.OwnerDocument != null)
    {
        var newId = signature.OwnerDocument.CreateAttribute("Id");
        newId.Value = oldId.Value;
        signature.Attributes.Append(newId);
    }
}

Although we don't understand why the validation should be so strict, that only "Id" validates as ok... Never the less, I doubt we get through to Microsoft, rolling it back :D

SignedXml.LoadXml() throws a CryptographicException

1 Answers1