XML Signature

src: i.stack.imgur.com

The XML Signature (also called XMLDSig , XML-DSig , XML-Sig ) defines the XML syntax for signatures digital and is defined in the recommendations of W3C XML Signature Syntax and Processing. Functionally, it has much in common with CCP # 7 but it can be further expanded and directed to sign XML documents. These are used by various Web technologies like SOAP, SAML, and others.

An XML signature can be used to sign data-a resource -of any type, usually an XML document, but anything that can be accessed via URL can be signed. The XML signature used to sign the source outside of the containing XML document is called a separate signature; if used to sign several sections of the document containing, it is called enveloped signature; if it contains data signed in itself, it's called a wrap signature.

Video XML Signature

Structure

The XML Signature contains the Signature element in the http://www.w3.org/2000/09/xmssig# namespace. Its basic structure is as follows:

• The SignedInfo element contains or refers signed data and specifies what algorithm to use.
  • The SignatureMethod and CanonicalizationMethod elements are used by SignatureValue elements and are included in SignedInfo to protect them from interference.
  • One or more of the Reference elements specifies the resources signed by the URI reference; and any transformations that will be applied to resources prior to signing. The transformation can be an XPath expression that selects a defined subset of the document tree.
    • DigestMethod specifies a hash algorithm before applying a hash.
    • DigestValue contains a Base64 encoding result that implements a hash algorithm to a transformed resource defined in the Reference element attribute.
• The SignatureValue element contains the result of the Base64 encoded signature - a signature created with the parameter specified in the SignatureMethod element - of the SignedInfo element after applying algorithm specified by CanonicalizationMethod .
The
• KeyInfo element optionally enables signers to provide the key to a recipient validating the signature, usually in the form of one or more X.509 digital certificates. The reliant party must identify the key from the context if KeyInfo is missing.
• The Object element (optional) contains signed data if this is the signature envelope .

Maps XML Signature

Validation and security considerations

When validating an XML Signature, a procedure called Core Validation is followed.

1. Reference Validation: Each node Reference is verified by fetching the appropriate resource and applying any transformation and then the summary method specified for it. The result is compared to the value of DigestValue ; if it does not match, validation fails.
2. Signature Validation: The SignedInfo element is initialized using the canonicalization method specified in CanonicalizationMethod , the key data is retrieved using KeyInfo or any other way, and the signature is verified using the method specified in SignatureMethod .

This procedure specifies whether the resource is actually signed by the alleged party. However, due to the expansion of the canonicalization and transformation methods, the verifying party must also ensure that what is actually signed or digested is really what is in the original data; in other words, that the algorithm used there can be trusted not to change the meaning of signed data.

Because the signed document structure can be tampered with leading to the "signature wrapper" attack, the validation process should also include the structure of the XML document. The signed element and the signature element must be selected using the absolute XPath expression instead of the getElementByName method.

src: i.ytimg.com

Canonicalized XML

Creation of XML Signatures is substantially more complex than creating a regular digital signature because the given XML Document ("Infoset", in common use among XML developers) may have more than one legal serial representation. For example, the space in the XML Element is syntactically insignificant, so & lt; ElemÃ, & gt; syntactically identical to & lt; Elem & gt; .

Because digital signatures are created using asymmetric key algorithms (usually RSA) to encrypt the results of running a serial XML document via a cryptographic hash function (usually SHA1), a one-byte difference will cause the digital signature to vary.

In addition, if the XML document is transferred from computer to computer, the line terminator can be changed from CR to LF to CR LF, etc. Programs that digest and validate XML documents can later render XML documents in different ways, e.g. add excess space between attribute definitions with element definitions, or use relative (vs. absolute) URLs, or by re-ordering namespace definitions. Canonical XML is very important when the XML Signature refers to a document remotely, which can be rendered in various ways of time by the wrong remote server.

To avoid this problem and ensure that identical logical XML documents provide identical digital signatures, the XML canonicalization transformation (often abbreviated C14n ) is used when signing an XML document (to sign SignedInfo , canonicalization is mandatory). This algorithm ensures that identical semantic documents produce identical serial representations.

Another complication arises because of the way the default canonicalization algorithm handles namespace declarations; often signed signed XML documents must be embedded in other documents; in this case the original canonicalization algorithm will not produce the same result as if the document itself is treated. For this reason, called Exclusive Canonicalization , which serializes XML namespace declarations independent of the surrounding XML, has been created.

src: airyurl.com

Benefits

The XML signature is more flexible than other forms of digital signatures such as Pretty Good Privacy and Cryptographic Message Syntax, because it does not operate on binary data, but in XML Infoset, it is possible to work on a subset of data, have various ways to bind signatures and information signed, and transformed. The other core concept is canonicalization, ie simply signing "essence", eliminating meaningless differences like whitespace and ending lines.

src: i.ytimg.com

Problem

There is criticism directed at XML security architecture in general, and on the compatibility of XML canonicalization especially as front end to sign and encrypt XML data due to complexity, inherent processing requirements, and poor performance characteristics. The argument is that doing XML canonicalization causes too much excessive latency to solve for transactional, SOA-sensitive application performance.

These issues are being discussed in the XML Security Working Group.

Without proper policies and implementations, the use of XML Dsig in SOAP and WS-Security can cause vulnerabilities, such as XML signature wrappings.

src: alfresco-addons.skytizens.com

Apps

Some sample applications from XML Signature:

• Digital signing of XBRL's annual report by auditors in the Netherlands. PKIoverheid X.509 Certificate, approved by the Royal National Institute of Chartered Accountants, is required. Electronic signatures are legally binding. The SBR Guarantee Standard is part of the Dutch Standard Business Reporting program.

src: i.ytimg.com

See also

• Canonical XML
• XML Encryption
• XAdES, an extension for XML-DSig for use with advanced electronic signatures
• Cryptographic Message Syntax

src: idmdude.files.wordpress.com

External links

• XML Signature Sync and Processing
• Canonical XML
• Uniform XML Security Uniform Resource Identifier (URI)
• Exclusive Canonicalization
• XMLSignatures Java binding for XMLBeans and JAXB.
• Step by Step Example of how signatures are made.

src: i.ytimg.com

References

Source of the article : Wikipedia