XML Signature
Die XML-Signature (XML-Sig, auch XML-DSig, XMLDsig) ist eine Spezifikation, um bestehende digitale Signaturen in XML-Schreibweise nutzen zu können. Funktionell hat sie viel mit PKCS #7 gemeinsam, ist aber erweiterbar und auf das Signieren von XML-Dokumenten ausgerichtet. Sie findet Einsatz in vielen weiterführenden Web-Standards wie etwa SOAP, SAML oder dem deutschen Online-Banking-System FinTS.
Mit XML-Signaturen können Daten jedes Typs signiert werden, sofern sie in das XML-Dokument der Signatur eingebettet worden sind oder mit einer URL adressiert werden können – erstere wird als enveloped signature[1], letztere als detached (losgelöste) signature[2] bezeichnet.
Struktur
[Bearbeiten | Quelltext bearbeiten]Eine XML-Signatur besteht aus einem Signature
Element im Namensraum http://www.w3.org/2000/09/xmldsig#
. Die Grundstruktur ist wie folgt:
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
<Reference /> etc.
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
- Das
SignedInfo
Element enthält oder referenziert die signierten Daten und gibt an, welche Algorithmen verwendet werden.- Die Elemente
SignatureMethod
undCanonicalizationMethod
werden vom ElementSignatureValue
verwendet und sind inSignedInfo
enthalten, um sie vor Manipulationen zu schützen. - Ein oder mehrere
Reference
Elemente definieren die zu signierende Ressource durch eine URI-Referenz und alle Transformationen, die vor der Signierung auf die Ressource anzuwenden sind.Transforms
enthält die Transformationen, die auf die Ressource vor dem Signieren angewendet werden. Eine Transformation kann ein XPath-Ausdruck sein, der eine bestimmte Teilmenge des Dokumentenbaums auswählt.[3]DigestMethod
gibt den Hash-Algorithmus vor der Anwendung des Hashes an.DigestValue
enthält das Base64-kodierte Ergebnis der Anwendung des Hash-Algorithmus auf die in den Attributen des ElementsReference
definierte(n) transformierte(n) Ressource(n).
- Die Elemente
- Das
SignatureValue
enthält das Base64-kodierte Signaturergebnis – die mit den imSignatureMethod
Element angegebenen Parametern erzeugte Signatur – desSignedInfo
Elements nach Anwendung des durch dieCanonicalizationMethod
angegebenen Algorithmus. - Das
KeyInfo
Element ermöglicht es dem Unterzeichner optional, den Empfängern den Schlüssel zur Verfügung zu stellen, der die Signatur validiert, normalerweise in Form eines oder mehrerer digitaler X.509-Zertifikate. Die vertrauende Partei muss den Schlüssel aus dem Kontext identifizieren, wennKeyInfo
nicht vorhanden ist. - Das (optionale) Element
Object
enthält die signierten Daten, wenn es sich um eine umschließende Signatur handelt.
Validierung und Sicherheitsaspekte
[Bearbeiten | Quelltext bearbeiten]Bei der Validierung einer XML-Signatur wird ein Verfahren namens Core Validation angewandt.
- Referenz-Validierung: Der Digest jeder
Reference
wird überprüft, indem die entsprechende Ressource abgerufen und alle Transformationen und dann die angegebene Digest-Methode auf sie angewendet werden. Das Ergebnis wird mit dem aufgezeichnetenDigestValue
verglichen; wenn sie nicht übereinstimmen, schlägt die Validierung fehl. - Signatur-Validierung: Das
SignedInfo
Element wird mit der inCanonicalizationMethod
angegebenen Kanonisierungsmethode serialisiert, die Schlüsseldaten werden mitKeyInfo
oder auf andere Weise abgerufen, und die Signatur wird mit der inSignatureMethod
angegebenen Methode überprüft.
Mit diesem Verfahren wird festgestellt, ob die Ressourcen wirklich von der angeblichen Partei signiert wurden. Aufgrund der Erweiterbarkeit der Kanonisierungs- und Transformationsmethoden muss die überprüfende Partei jedoch auch sicherstellen, dass das, was tatsächlich signiert oder verdaut wurde, auch wirklich das ist, was in den ursprünglichen Daten vorhanden war, mit anderen Worten, dass den dort verwendeten Algorithmen vertraut werden kann, dass sie die Bedeutung der signierten Daten nicht verändern.
Da die Struktur des signierten Dokuments manipuliert werden kann, was zu „Signature Wrapping“-Angriffen führt, sollte der Validierungsprozess auch die Struktur des XML-Dokuments umfassen. Signierte Elemente und Signaturelemente sollten mit absoluten XPath-Ausdrücken und nicht mit getElementByName
Methoden ausgewählt werden.[4]
XML-Normalisierung (Kanonisierung)
[Bearbeiten | Quelltext bearbeiten]Die Erstellung von XML-Signaturen ist wesentlich komplexer als die Erstellung einer gewöhnlichen digitalen Signatur, da ein bestimmtes XML-Dokument (ein „Infoset“, wie es unter XML-Entwicklern üblich ist) mehr als eine legale serialisierte Darstellung haben kann. So ist beispielsweise Leerraum innerhalb eines XML-Elements syntaktisch nicht von Bedeutung, sodass <Elem >
syntaktisch identisch mit <Elem>
ist.
Da die digitale Signatur die Datenintegrität gewährleistet, würde ein Unterschied von nur einem Byte dazu führen, dass sich die Signatur ändert. Wird ein XML-Dokument von einem Computer auf einen anderen übertragen, kann sich außerdem das Zeilenende von CR zu LF zu CR LF usw. ändern. Ein Programm, das ein XML-Dokument verdaut und validiert, kann das XML-Dokument später anders darstellen, z. B. durch Hinzufügen von überflüssigem Leerraum zwischen Attributdefinitionen und Elementdefinitionen, durch Verwendung relativer (statt absoluter) URLs oder durch Umordnung von Namespace-Definitionen. Kanonisches XML ist besonders wichtig, wenn eine XML-Signatur auf ein entferntes Dokument verweist, das von einem fehlerhaften entfernten Server auf zeitlich variierende Weise gerendert werden kann.
Um diese Probleme zu vermeiden und zu gewährleisten, dass logisch identische XML-Dokumente identische digitale Signaturen ergeben, wird beim Signieren von XML-Dokumenten eine XML-Kanonisierungstransformation (häufig mit C14n abgekürzt) verwendet (für das Signieren der SignedInfo
ist eine Normalisierung obligatorisch). Diese Algorithmen garantieren, dass semantisch identische Dokumente exakt identische serialisierte Darstellungen erzeugen.
Eine weitere Komplikation ergibt sich aus der Art und Weise, wie der Standard-Kanonisierungsalgorithmus mit Namensraumdeklarationen umgeht; häufig muss ein signiertes XML-Dokument in ein anderes Dokument eingebettet werden; in diesem Fall liefert der ursprüngliche Kanonisierungsalgorithmus nicht dasselbe Ergebnis, als wenn das Dokument allein behandelt wird. Aus diesem Grund wurde die sogenannte Exklusive Kanonisierung geschaffen, die XML-Namensraumdeklarationen unabhängig vom umgebenden XML serialisiert.
Vorteile
[Bearbeiten | Quelltext bearbeiten]Die XML-Signatur ist flexibler als andere Formen digitaler Signaturen wie Pretty Good Privacy und Cryptographic Message Syntax, da sie nicht mit Binärdaten, sondern mit dem XML-Infoset arbeitet, sodass Teilmengen der Daten bearbeitet werden können (dies ist auch mit Binärdaten auf nicht standardisierte Weise möglich, z. B. durch Kodierung von Blöcken von Binärdaten in Base64-ASCII), wobei es verschiedene Möglichkeiten gibt, die Signatur und die signierten Informationen zu verbinden und Transformationen durchzuführen. Ein weiteres zentrales Konzept ist die Kanonisierung, d. h., es wird nur das Wesentliche signiert, wobei bedeutungslose Unterschiede wie Leerzeichen und Zeilenenden eliminiert werden.
Kritik
[Bearbeiten | Quelltext bearbeiten]Es gibt Kritik an der Architektur der XML-Sicherheit im Allgemeinen[5] und an der Eignung der XML-Kanonisierung im Besonderen als Front-End zum Signieren und Verschlüsseln von XML-Daten aufgrund ihrer Komplexität, ihrer inhärenten Verarbeitungsanforderungen und ihrer schlechten Leistungsmerkmale[6][7][8]. Das Argument ist, dass die Durchführung der XML-Kanonisierung eine übermäßige Latenzzeit verursacht, die für transaktionale, leistungsempfindliche SOA-Anwendungen einfach zu groß ist.
Diese Fragen werden in der XML Security Working Group behandelt.[9][10]
Ohne angemessene Richtlinien und Implementierung[4] kann die Verwendung von XML Dsig in SOAP und WS-Security zu Schwachstellen führen,[11] wie etwa XML-Signatur-Wrapping.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ XML Signature Syntax and Processing Version 1.1. Abgerufen am 22. September 2023 (englisch).
- ↑ XML Signature Syntax and Processing Version 1.1. Abgerufen am 22. September 2023 (englisch).
- ↑ XML-Signature XPath Filter 2.0
- ↑ a b Pawel Krawczyk: Secure SAML validation to prevent XML signature wrapping attacks. Archiviert vom (nicht mehr online verfügbar); abgerufen am 9. Januar 2015 (englisch). , 2013
- ↑ Why XML Security is Broken. Abgerufen am 22. September 2023 (englisch).
- ↑ Performance of Web Services Security ( des vom 24. Februar 2021 im Internet Archive) Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.
- ↑ Performance Comparison of Security Mechanisms for Grid Services
- ↑ Jimmy Zhang: Accelerate WSS applications with VTD-XML. In: InfoWorld. 9. Januar 2007, abgerufen am 22. September 2023.
- ↑ W3C Workshop on Next Steps for XML Signature and XML Encryption. Abgerufen am 22. September 2023 (englisch). , 2007
- ↑ XML Security 2.0 Requirements and Design Considerations. Abgerufen am 22. September 2023 (englisch).
- ↑ Juraj Somorovsky, Andreas Mayer, Jorg Schwenk, Marco Kampmann, Meiko Jensen: On Breaking SAML: Be Whoever You Want to Be. Abgerufen am 22. September 2023 (englisch). , 2012
Siehe auch
[Bearbeiten | Quelltext bearbeiten]Literatur
[Bearbeiten | Quelltext bearbeiten]- Michael Häusler, Michael Merz, Michel Wichers: Digitales Signieren mit XML. In: iX – Magazin für professionelle Informationstechnik. Nr. 6, 2004, S. 104–109 (heise.de [abgerufen am 9. Juli 2019]).
Normen und Standards
[Bearbeiten | Quelltext bearbeiten]- XML-Signature Syntax and Processing (W3C, englisch). Die aktuelle Version ist 1.1 von 2013.
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Einführung in XML-Signaturen (englisch)