KeyInfo in XML-DSig: Purpose and Security Risks

This article provides an overview of the KeyInfo element within the XML Digital Signature (XML-DSig) specification. It explores the element’s role in conveying cryptographic key material, details the common structures used within it, and analyzes critical security considerations and vulnerabilities that developers must address when validating signatures.

What is the KeyInfo Element?

In an XML Digital Signature (XML-DSig) structure, <KeyInfo> is an optional element inside the root <Signature> element. Its primary purpose is to carry information that enables the recipient to obtain the public key or certificate necessary to validate the signature.

While <SignedInfo> contains the core cryptographic digest and signature algorithms, <KeyInfo> tells the validating party which key was used to create the signature.

Common Child Elements of KeyInfo

The XML-DSig standard defines several standard child elements that can appear within <KeyInfo>:

• <KeyName>: Contains an identifier or string name for the key (e.g., an email address, username, or key ID) agreed upon by both parties out-of-band.
• <KeyValue>: Contains the explicit public key material, typically using sub-elements like <RSAKeyValue> or <DSAKeyValue>.
• <X509Data>: Contains one or more identifiers or structures related to X.509 PKI, such as <X509Certificate>, <X509IssuerSerial>, <X509SubjectName>, or <X509SKI>.
• <RetrievalMethod>: Uses a URI reference to point to key data stored remotely or elsewhere within the document.
• <PGPData> and <SPKIData>: Contain structures related to PGP and SPKI key architectures.
• <MgmtData>: Contains in-band key agreement or key management data (rarely used due to security limitations).

Security Considerations for KeyInfo

Improper handling of the KeyInfo element is one of the most common vectors for vulnerabilities in XML signature verification implementations.

1. Blindly Trusting KeyInfo Content (Untrusted Key Injection)

A critical flaw occurs when an application accepts any key present in <KeyInfo> and uses it to verify the signature without establishing trust. An attacker can modify an XML document, generate their own key pair, sign the modified content, and replace the <KeyInfo> element with their own public key or certificate.

• Mitigation: The application must never inherently trust the key inside <KeyInfo>. The embedded key or certificate must be validated against a local trust store, a pre-shared public key, or a verified PKI certificate chain.

2. Server-Side Request Forgery (SSRF) and DoS via RetrievalMethod

The <RetrievalMethod> element allows referencing key data via a URI. If the XML parser automatically resolves external URIs, attackers can supply malicious URLs pointing to internal network resources (SSRF) or large files designed to exhaust server memory and CPU (Denial of Service).

• Mitigation: Disable external entity and URI resolution during signature verification. If external retrieval is mandatory, restrict resolution to a strict, pre-approved whitelist of trusted hosts.

3. XML Signature Wrapping (XSW) Attacks

If <KeyInfo> is unsigned or decoupled from the payload validation logic, attackers can manipulate the XML structure to trick the signature processor into validating the signature against an attacker-controlled <KeyInfo> while the business logic consumes the malicious payload.

• Mitigation: Ensure that the signature covers the intended context and elements completely. Enforce strict schema validation and verify that the application logic and cryptographic engine evaluate the same document nodes.

4. Certificate Validation Failures

When using <X509Data>, developers frequently check only that the signature matches the public key embedded in <X509Certificate>, omitting certificate validation steps.

• Mitigation: Perform complete X.509 path validation, including checking certificate expiration dates, trusted root authorities, hostname/subject matching, and revocation status via CRLs or OCSP.

Best Practices Summary

• Pre-shared Keys/Trust Stores: Whenever possible, identify keys via out-of-band configuration or lookup by <KeyName>, matching against a secure internal key repository rather than accepting in-band raw keys.
• Disable Remote Resolution: Prohibit the processing of arbitrary remote URIs in <RetrievalMethod>.
• Strict Validation Pipeline: Separate signature validation into two mandatory phases: cryptographic verification of the XML content and independent authorization/trust verification of the key itself.