XML Signature (también llamada XMLDSig , XML-DSig , XML-Sig ) define una sintaxis XML para firmas digitales y se define en la recomendación de W3C Sintaxis y procesamiento de firmas XML. Funcionalmente, tiene mucho en común con PKCS #7 pero es más extensible y está orientada a la firma de documentos XML. Se utiliza en varias tecnologías web como SOAP , SAML y otras.
Las firmas XML se pueden utilizar para firmar datos (un recurso ) de cualquier tipo , normalmente documentos XML, pero se puede firmar cualquier cosa a la que se pueda acceder mediante una URL . Una firma XML utilizada para firmar un recurso fuera del documento XML que lo contiene se denomina firma separada ; si se utiliza para firmar alguna parte del documento que lo contiene, se denomina firma envuelta ; [1] si contiene los datos firmados en su interior, se denomina firma envolvente . [2]
Una firma XML consta de un Signature
elemento en el http://www.w3.org/2000/09/xmldsig#
espacio de nombres. La estructura básica es la siguiente:
<Firma> <InformaciónFirmada > <MétodoCanonicalización /> <MétodoFirma /> <Referencia> <Transformaciones /> <MétodoDigest /> <ValorDigest /> </Referencia> <Referencia /> etc. </InformaciónFirmada> <ValorFirmada /> <InformaciónClave /> <Objeto /> </Firma>
SignedInfo
elemento contiene o hace referencia a los datos firmados y especifica qué algoritmos se utilizan.SignatureMethod
y CanonicalizationMethod
son utilizados por el SignatureValue
elemento y se incluyen SignedInfo
para protegerlos contra manipulaciones.Reference
elementos especifican el recurso que se está firmando mediante la referencia URI y cualquier transformación que se aplicará al recurso antes de la firma.Transforms
Contiene las transformaciones aplicadas al recurso antes de la firma. Una transformación puede ser una expresión XPath que selecciona un subconjunto definido del árbol del documento. [3]DigestMethod
especifica el algoritmo hash antes de aplicar el hash.DigestValue
contiene el resultado codificado en Base64 de aplicar el algoritmo hash a los recursos transformados definidos en los Reference
atributos del elemento.SignatureValue
elemento contiene el resultado de la firma codificada en Base64 (la firma generada con los parámetros especificados en el SignatureMethod
elemento) del SignedInfo
elemento después de aplicar el algoritmo especificado por CanonicalizationMethod
.KeyInfo
El elemento permite opcionalmente al firmante proporcionar a los destinatarios la clave que valida la firma, normalmente en forma de uno o más certificados digitales X.509KeyInfo
. La parte que confía debe identificar la clave a partir del contexto si no está presente.Object
elemento (opcional) contiene los datos firmados si se trata de una firma envolvente .Al validar una firma XML, se sigue un procedimiento llamado Validación del núcleo .
Reference
resumen de se verifica recuperando el recurso correspondiente y aplicándole las transformaciones y luego el método de resumen especificado. El resultado se compara con el registrado DigestValue
; si no coinciden, la validación falla.SignedInfo
elemento se serializa utilizando el método de canonización especificado en CanonicalizationMethod
, los datos de la clave se recuperan utilizando KeyInfo
o por otros medios, y la firma se verifica utilizando el método especificado en SignatureMethod
.Este procedimiento permite establecer si los recursos fueron realmente firmados por la supuesta parte. Sin embargo, debido a la extensibilidad de los métodos de canonización y transformación, la parte verificadora también debe asegurarse de que lo que realmente fue firmado o digerido sea realmente lo que estaba presente en los datos originales, es decir, que se puede confiar en que los algoritmos utilizados allí no cambiarán el significado de los datos firmados.
Debido a que la estructura del documento firmado puede ser alterada y dar lugar a ataques de "envoltura de firma", el proceso de validación también debe cubrir la estructura del documento XML. El elemento firmado y el elemento de firma deben seleccionarse utilizando una expresión XPath absoluta , no getElementByName
métodos. [4]
La creación de firmas XML es sustancialmente más compleja que la creación de una firma digital común porque un documento XML determinado (un " conjunto de información ", de uso común entre los desarrolladores de XML) puede tener más de una representación serializada legal. Por ejemplo, los espacios en blanco dentro de un elemento XML no son sintácticamente significativos, por lo que <Elem >
son sintácticamente idénticos a <Elem>
.
Dado que la firma digital garantiza la integridad de los datos, una diferencia de un solo byte haría que la firma varíe. Además, si un documento XML se transfiere de un ordenador a otro, el terminador de línea puede cambiar de CR a LF a CR LF, etc. Un programa que digiere y valida un documento XML puede posteriormente representar el documento XML de una manera diferente, por ejemplo, añadiendo espacio adicional entre las definiciones de atributos con una definición de elemento, o utilizando URL relativas (en lugar de absolutas), o reordenando las definiciones de espacios de nombres. El XML canónico es especialmente importante cuando una firma XML hace referencia a un documento remoto, que puede ser representado de maneras que varían en el tiempo por un servidor remoto errante.
Para evitar estos problemas y garantizar que los documentos XML lógicamente idénticos proporcionen firmas digitales idénticas, se utiliza una transformación de canonización XML (abreviada frecuentemente como C14n ) al firmar documentos XML (para firmar SignedInfo
, es obligatoria una canonización). Estos algoritmos garantizan que los documentos semánticamente idénticos produzcan representaciones serializadas exactamente idénticas.
Otra complicación surge debido a la forma en que el algoritmo de canonización predeterminado maneja las declaraciones de espacios de nombres; con frecuencia, un documento XML firmado debe incrustarse en otro documento; en este caso, el algoritmo de canonización original no arrojará el mismo resultado que si el documento se tratara solo. Por esta razón, se creó la denominada Canonicalización Exclusiva , que serializa las declaraciones de espacios de nombres XML independientemente del XML circundante.
XML Signature es más flexible que otras formas de firmas digitales como Pretty Good Privacy y Cryptographic Message Syntax , porque no opera sobre datos binarios , sino sobre el XML Infoset , lo que permite trabajar sobre subconjuntos de los datos (esto también es posible con datos binarios de formas no estándar, por ejemplo codificando bloques de datos binarios en ASCII base64), teniendo varias formas de vincular la firma y la información firmada, y realizar transformaciones. Otro concepto central es la canonización, es decir firmar solo la "esencia", eliminando diferencias sin sentido como espacios en blanco y finales de línea.
Existen críticas dirigidas a la arquitectura de seguridad XML en general, [5] y a la idoneidad de la canonización XML en particular como interfaz para firmar y cifrar datos XML debido a su complejidad, requisito de procesamiento inherente y características de rendimiento deficientes. [6] [7] [8] El argumento es que realizar la canonización XML causa una latencia excesiva que es simplemente demasiado para superar para aplicaciones SOA transaccionales y sensibles al rendimiento .
Estas cuestiones se están abordando en el Grupo de Trabajo de Seguridad XML. [9] [10]
Sin una política y una implementación adecuadas [4], el uso de XML Dsig en SOAP y WS-Security puede generar vulnerabilidades [11] , como el envoltorio de firmas XML. [12]
Un ejemplo de aplicaciones de firmas XML: