XML (Extensible Markup Language) hat sich in den letzten Jahrzehnten zu einem Standardformat für den Datenaustausch und die Strukturierung von Informationen entwickelt. Dank seiner Lesbarkeit und Flexibilität wird XML in unzähligen Bereichen verwendet, von Webservices über Konfigurationsdateien bis hin zu komplexen Transaktionssystemen. Dennoch offenbart sich bei genauerer Betrachtung ein gravierendes Problem: Die Sicherheit von XML, insbesondere im Bereich der digitalen Signaturen und der Verschlüsselung, ist seit vielen Jahren ein grundlegender Schwachpunkt. Eine Studie aus dem Jahr 2004 von Peter Gutmann, einem anerkannten Experten auf dem Gebiet der IT-Sicherheit, hat dies klar und unmissverständlich aufgezeigt. Die darin aufgeführten Schwächen stellen bis heute einen wichtigen Referenzpunkt in der Auseinandersetzung mit XML-Sicherheit dar.
Um zu verstehen, warum XML-Sicherheit als gescheitert gilt, muss man zunächst verstehen, was digitale Sicherheit im Zusammenhang mit Datenformaten bedeutet und welche Herausforderungen speziell bei XML auftreten. Die Hauptkritik richtet sich gegen die inhärente Instabilität von XML als Datenformat, die sich insbesondere beim Versuch, XML-Dokumente signierbar zu machen, massiv auswirkt. Digitale Signaturen basieren darauf, dass Daten unverändert bleiben und exakt reproduzierbar sind. Jede kleinste Veränderung am Dokument würde die Signatur ungültig machen. Bei XML aber sind zahlreiche Faktoren wie unterschiedliche Interpretationen von Leerzeichen, Zeilenumbrüchen, Zeichencodierungen oder sogar der Reihenfolge von Attributen problematisch. Diese sogenannten Kanonisierungsmethoden, welche die Daten vor dem Signieren so normalisieren sollen, dass unterschiedliche, aber semantisch gleiche XML-Darstellungen gleichbehandelt werden, erweisen sich in der Praxis als unzureichend.
Die Komplexität wächst noch, wenn man die semantischen Elemente von XML betrachtet: XSLT-Transformationen, XPath-Ausdrücke, externe Definitionen wie Schemata und DTDs, Namespaces und Stylesheets beeinflussen den Inhalt und die Verarbeitung eines Dokuments wesentlich. Das führt dazu, dass es keinen allgemein akzeptierten Weg gibt, um zu definieren, was ein signiertes XML-Dokument inhaltlich wirklich darstellt. Ein typisches Szenario im Einsatz von XML-Signaturen sieht daher so aus, dass sich unterschiedliche Stellen auf unterschiedliche Versionen und kanonische Formen des gleichen Dokuments berufen können – mit gerichtlichen oder wirtschaftlichen Konsequenzen, die schwer abzuschätzen sind. Peter Gutmann zeigt humorvoll und doch nachdrücklich die Absurdität, mit der ein juristischer Fall aussehen könnte, in dem niemand mehr nachvollziehen kann, welche Version eines Dokuments tatsächlich gültig signiert wurde, weil es verschiedene Interpretationen und Versionen in Umlauf gibt.
Trotz der Tatsache, dass andere Sicherheitsstandards wie S/MIME und PGP seit Jahren bewährte und einfache Methoden zur Signierung und Verschlüsselung von Daten besitzen, hat die XML-Sicherheitscommunity in den frühen 2000er Jahren den Fehler gemacht, eigene Standards zu schaffen, die XML-nah sein sollten, aber die grundlegenden Probleme nicht lösen konnten. Die Entscheidung, XML-Dokumente innerhalb von XML selbst zu schützen (also Signaturen und Verschlüsselungen in XML-Strukturen zu verpacken), führte zu einer Vielzahl von Problemen. Ein vorrangiges Problem dabei ist die Aufweichung bewährter, modularer Strukturen, die sonst in Sicherheitsprotokollen vorzufinden sind. Bei Standards wie PGP oder S/MIME lässt sich das signierte oder verschlüsselte Datenobjekt klar abgrenzen und als unmodifizierbares Ganzes behandeln.
Demgegenüber eröffnet XML-Sicherheit eine enorme Flexibilität in der Struktur, die es aber auch ermöglicht, einzelne Teile des Dokuments zu signieren, Header zu unterschreiben, oder sogar separate Schlüssel in das Dokument einzubetten – Praktiken die massiv Angriffspotenzial bieten und deren sichere Implementierung extrem schwierig ist. Gutmann vergleicht diesen Zustand treffend mit dem Überreichen eines Werkzeugsatzes an unerfahrene Anwender ohne Anleitung, wie das Werkzeug richtig angewendet wird, sodass man erwartet, dass Fehler nahezu zwangsläufig passieren müssen. Auch in der Praxis ist dies bestätigt worden: Sicherheitsprobleme bis hin zum vollständigen Unterlaufen der Signaturprüfung durch XML-Manipulationen sind regelmäßig dokumentiert worden.
Ein besonders prominentes Beispiel zeigt, dass es möglich ist, signierte XML-Dokumente so zu verändern, dass ein Kaufbestellungsposten für günstige Artikel im Nachhinein in kostspielige Hardware umgewandelt werden kann – ohne dass die Signatur dadurch ungültig wird. Eine der grundlegenden Ursachen für diese Probleme liegt auch darin, dass XML-Sicherheit untrennbar an das gewählte XML-Verarbeitungsmodell gebunden ist. Um XML-Sicherheit zu implementieren, benötigen Entwickler zwangsläufig eine vollständige XML-Verarbeitungsumgebung, was zusätzliche Komplexität mit sich bringt und die Modularität von Sicherheits-Toolkit-Konzepten untergräbt. Es ist nicht wie bei klassischen Sicherheitsbibliotheken, die einfach ein Blob von Daten signieren oder verschlüsseln und ohne weiteren Kontext verarbeiten. Das führt dazu, dass praktisch alle XML-Sicherheitslösungen entweder proprietär oder sehr komplex sind, schwer zu implementieren und fehleranfällig.
Im Gegensatz dazu ist es bei Protokollen und Standards, die PGP und S/MIME verwenden, möglich, bestehende, erprobte Sicherheitswerkzeuge zu integrieren, was den Entwicklungsaufwand erheblich reduziert und gleichzeitig die Zuverlässigkeit erhöht. Ein Beispiel, das Gutmann hervorhebt, ist das Messaging-Protokoll XMPP (Jabber), das anstelle von XML-Sicherheitsmechanismen auf bewährte Standards wie S/MIME setzt, was der Einfachheit und Sicherheit zugutekommt. Um diesen Herausforderungen zu begegnen, schlagen Experten eine Rückbesinnung auf das einfache Prinzip vor: Signiere und verschlüssele die Daten als Block („Blob“), anstatt über komplizierte XML-Transformations- und Kanonisierungsprozesse zu gehen. Dabei könnte man die Sicherheitsinformationen in XML-Tags wie <PGP></PGP> oder <SMIME></SMIME> schlicht und pragmatisch einbetten, ohne die Sicherheit unnötig zu verkomplizieren.
Alternativ gibt es Projekte wie XML-RSig („Really Simple Signatures“), die das signierte XML-Element als unverändertes Datenblob nehmen und dieses auf einfache Weise kryptografisch schützen, um die Komplexität deutlich zu reduzieren und das Risiko von Implementierungsfehlern zu minimieren. Trotz einiger Bemühungen der W3C und anderer Organisationen, diese Probleme zu beheben und XML-Sicherheitsstandards nachträglich zu reparieren, stellt sich die Frage, wie nachhaltig solche Lösungen sein können. Die Vielzahl an Patches ist ein Indiz dafür, dass der grundlegende Entwurf dieser Standards nicht ideal war. Letztlich zeigt die Geschichte der XML-Sicherheit ein fundamentales Spannungsfeld zwischen der Flexibilität und Ausdruckskraft von XML als Datenformat und den rigiden Anforderungen der Kryptographie.
Während XML mit seinen reichhaltigen Möglichkeiten zur Manipulation von Daten eine hervorragende Sprache für viele Anwendungen ist, entspricht diese Flexibilität nicht den Anforderungen an präzise, eindeutige und sichere digitale Signaturen. Wer heute im Bereich der IT-Sicherheit mit XML arbeitet, sollte sich dieser Probleme bewusst sein und daher lieber auf klare, einfache Modelle setzen, die auf bewährten Sicherheitsprinzipien aufbauen anstatt auf die komplexen und häufig fehleranfälligen nativen XML-Sicherheitsmechanismen. Somit ist der sogenannte „Run Away! “-Ruf vor XML-Dsig keineswegs grundlos. Der Erfahrungswert von Sicherheitsprofis zeigt eindrucksvoll, dass die derzeitigen XML-Sicherheitslösungen eine erhebliche Gefahr darstellen können, wenn sie unkritisch und ohne tiefgehendes Verständnis eingesetzt werden. Im Endeffekt ist die Erkenntnis aus der Analyse von Peter Gutmann und anderen Experten klar: Sicherheit erfordert Einfachheit, Eindeutigkeit und Verlässlichkeit.
XML in seiner jetzigen Form als sicherer Container für kryptographische Maßnahmen einzusetzen, bringt diese fundamentalen Prinzipien in Gefahr und führt häufig zu fehlerhaften Implementierungen. Die Zukunft der XML-Sicherheit liegt deshalb in der Integration bewährter, externer Sicherheitsstandards und nicht in einem ständigen Neudefinieren des Rades innerhalb von XML selbst.
