XML digital signature security overview

An XML digital signature (XML DSIG) is an electronic, encrypted, stamp of authentication on digital information such as messages. The digital signature confirms that the information originated from the signer and was not altered in transmission. Additionally, with digital signatures that use public key cryptography, the origin of the signed message can be traced to the identity of the sender to satisfy nonrepudiation requirements. Using XML digital signatures (either separately from XML encryption or in conjunction) has potential security implications. However, in general, there are fewer potential security issues with XML encryption than with XML digital signatures.

Digital signatures are part of message-level security. They are important because they ensure end-to-end message integrity, and can also provide authentication information about the originator of a message. To be effective, the digital signature must be part of the application data so it is generated at the time the message is created. Then, the signature can be verified at the time the message is received and processed. At a minimum, sign the message body, security, and addressing headers.

In contrast, cryptographic protocols (such as SSL or TLS) that provide communication security for messages also provide message integrity and message privacy, but only while the message is in transit. After the message is accepted by the consumer, the SSL protection must be removed so that the message can be processed. Therefore, the use of a cryptographic protocol provides only transport-level security between communication endpoints, not message-level security.

B2B Advanced Communications ensures that the key used to sign a message is trusted by verifying the corresponding X.509 certificate (and certificate chain) included in the signed message. Then, it validates the integrity of the SignedInfo element and any Manifest elements before validating references contained in those elements. Reference elements specify URIs, transforms, and canonicalization algorithms. If these fields are not validated, they can potentially be used to create denial of service, data loss, or other attacks.

Important:

Digitally sign all message data that you do not expect to change. Additionally, use a transport-level security protocol such as SSL or TLS to protect the message and the security token.

However, the use of digital signatures can cause security vulnerabilities. One security concern when you use digital signatures involves the use of canonicalization, which can be used with an XML digital signature. Canonicalization is a process for converting data that has more than one physical representation into a standard format that is known as Canonical XML. XML canonicalization (c14n) of an XML document uses a specified algorithm to define the physical changes that can be made to the document without changing the logical representation of the document. The problem is that there is not currently a satisfactory canonicalization algorithm. Even the recommended canonicalization algorithm (Exclusive XML Canonicalization), can allow security issues. This algorithm retains only the visibly used namespace declarations to ensure that the document integrity is protected. However, digital signatures that are constructed with this algorithm are invalidated by the addition or removal of namespace declarations in the surrounding context. Thus, this algorithm works well when a self-contained XML document is constructed, signed, and then inserted into another XML document. But, when an XML document is signed and then transported in a message with an XML network protocol (such as ebXML or WSDL), validation errors can occur when a namespace declaration is added or removed from the enclosing document.

An X.509 certificate specifies a binding between a public key and a set of attributes that include a subject name, issuer name, serial number, and validity interval. Since any public key can be specified in more than one X.509 certificate, ensure that a signature created under an X.509 certificate token uniquely and irrefutably specifies the certificate under which the signature was created. To protect against a certificate substitution attack, include either the certificate or an immutable and unambiguous reference to the certificate within the scope of the signature.

Another potential security concern with XML digital signatures is that there is no satisfactory way to reference arbitrarily inserted content, which can also result in spurious validation errors. The only form of XPath expression that can return arbitrary XML content that is inserted into a protocol message is one referencing an ID attribute. Although the use of an ID attribute eliminates the possibility that content is subsequently added to a message not being flagged, there are a number of problems when using ID attributes to indicate signed content.

Adding or removing ID attributes: A disadvantage to using ID attributes in digital signature references is that the ID is actually part of the signed data. Therefore, if the XML was previously signed and then the ID attribute is added or removed, the signature is invalid.
Semantic importance of ID attributes: When part of the message content is signed and the relative position of the content has semantic import, that can also cause a security threat. For example, if an order form contains a billing address and delivery address, and both addresses are signed independently with an ID attribute reference, it is possible that the addresses can be interchanged without invalidating either signature.
Tip: B2B Advanced Communications verifies that all data that is consumed is verified by the signature. Since the semantic meaning of a signature may vary based on the position of the signature within the message, B2B Advanced Communications checks the position of the signature within the document. Additionally, it checks the position of referenced data and element names to mitigate substitution and wrapping attacks.