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, letztere als detached (losgelöste) signature bezeichnet.

Struktur

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 und CanonicalizationMethod werden vom Element SignatureValue verwendet und sind in SignedInfo 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.
      • 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 Elements Reference definierte(n) transformierte(n) Ressource(n).
  • Das SignatureValue enthält das Base64-kodierte Signaturergebnis – die mit den im SignatureMethod Element angegebenen Parametern erzeugte Signatur – des SignedInfo Elements nach Anwendung des durch die CanonicalizationMethod 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, wenn KeyInfo nicht vorhanden ist.
  • Das (optionale) Element Object enthält die signierten Daten, wenn es sich um eine umschließende Signatur handelt.

Validierung und Sicherheitsaspekte

Bei der Validierung einer XML-Signatur wird ein Verfahren namens Core Validation angewandt.

  1. 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 aufgezeichneten DigestValue verglichen; wenn sie nicht übereinstimmen, schlägt die Validierung fehl.
  2. Signatur-Validierung: Das SignedInfo Element wird mit der in CanonicalizationMethod angegebenen Kanonisierungsmethode serialisiert, die Schlüsseldaten werden mit KeyInfo oder auf andere Weise abgerufen, und die Signatur wird mit der in SignatureMethod 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.

XML-Normalisierung (Kanonisierung)

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

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

Es gibt Kritik an der Architektur der XML-Sicherheit im Allgemeinen 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. 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.

Ohne angemessene Richtlinien und Implementierung kann die Verwendung von XML Dsig in SOAP und WS-Security zu Schwachstellen führen, wie etwa XML-Signatur-Wrapping.

Einzelnachweise

  1. ↑ XML Signature Syntax and Processing Version 1.1. Abgerufen am 22. September 2023 (englisch).
  2. ↑ XML Signature Syntax and Processing Version 1.1. Abgerufen am 22. September 2023 (englisch).
  3. ↑ XML-Signature XPath Filter 2.0
  4. 1 2 Pawel Krawczyk: Secure SAML validation to prevent XML signature wrapping attacks. (Nicht mehr online verfügbar.) Archiviert vom Original; abgerufen am 9. Januar 2015 (englisch)., 2013
  5. ↑ Why XML Security is Broken. Abgerufen am 22. September 2023 (englisch).
  6. ↑ Performance of Web Services Security
  7. ↑ Performance Comparison of Security Mechanisms for Grid Services
  8. ↑ Jimmy Zhang: Accelerate WSS applications with VTD-XML. In: InfoWorld. 9. Januar 2007, abgerufen am 22. September 2023.
  9. ↑ W3C Workshop on Next Steps for XML Signature and XML Encryption. Abgerufen am 22. September 2023 (englisch)., 2007
  10. ↑ XML Security 2.0 Requirements and Design Considerations. Abgerufen am 22. September 2023 (englisch).
  11. ↑ 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

Literatur

Normen und Standards

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.