XML Security Basics

Tutorial aktualisiert am 14.12.2009

Dieses Tutorial ist Bestandteil der XML Security Tools (früher XML-Security Plug-In), dem Open Source eLearning Plug-in für XML-Sicherheit mit Eclipse ab Version 3.0. Mit den XML Security Tools können Sie beliebige XML-Dokumente sichern und XML Canonicalization, XML Signature sowie XML Encryption in beliebigen XML-Dokumenten ausprobieren und anwenden. Verschiedene Cheat Sheets erleichtern Einsteigern die ersten Schritte mit dem Plug-in und der XML-Sicherheit. Die umfangreichen Tutorials und in Teilen auch die Online-Hilfe des Plug-ins enthalten ausführliche Informationen zu den W3C Empfehlungen und Hintergründe zu Signaturen und Verschlüsselung mit der Extensible Markup Language sowie Anleitungen zur Verwendung der XML Security Tools.

Im Fokus der XML Security Tools stehen die praktische Anwendung und das Experimentieren mit den vielfältigen Möglichkeiten der XML-Sicherheit: beliebige XML-Dokumente können kanonisiert, signiert, verifiziert sowie ver- und entschlüsselt werden. Die theoretischen Informationen und Hintergründe zu den umfangreichen W3C Empfehlungen stehen in diesen Tutorials verständlich zum Nachlesen bereit.

Für die XML Security Tools sind Kenntnisse in XML erforderlich, XPath Expressions und Namespaces sind hilfreich, aber nicht zwingend notwendig. Empfehlenswert sind außerdem Kenntnisse in XML Schema (XSD) und XSL Transformations (XSLT). Kenntnisse in der Kryptografie (Digitale Signaturen, Verschlüsselung, Hashfunktionen) sind hilfreich aber nicht unbedingt erforderlich. Für die XML Security Tools sollten dafür grundlegende Eclipse Kenntnisse vorhanden sein.

Die Homepage zu den XML Security Tools und zur XML-Sicherheit für Support, Tipps und vielem mehr ist verfügbar unter www.xml-sicherheit.de. Der Source Code des nicht mehr weiterentwickelten XML-Security Plug-in findet sich auf der SourceForge Projektseite unter http://sourceforge.net/projects/xml-security. Der aktuelle Source Code der XML Security Tools befindet sich unter http://dev.eclipse.org/viewcvs/index.cgi/incubator/sourceediting/?root=WebTools_Project.

Die XML Security Tools stehen unter der Eclipse Public License Version 1.0, einsehbar unter http://www.eclipse.org/legal/epl-v10.html. Die für die XML Security Tools notwendige Apache XML Security API (Santuario) im Plug-in org.apache.xml.security, Apache Commons Logging im Plug-in org.apache.commons.logging, Apache Xalan im Plug-in org.apache.xalan sowie Apache Xerces im Plug-in org.apache.xerces stehen unter der Apache Software License Version 2.0. Diese ist einsehbar unter http://www.apache.org/licenses/LICENSE-2.0.html.

Seit Oktober 2008 ist das XML-Security Plug-In ein offizielles Eclipse Plug-in und wird nicht mehr eigenständig weiterentwickelt. Unter dem Namen XML Security Tools sind neue Versionen des Plug-ins nun im Incubator der Eclipse Web Tools Platform (WTP) zu finden.

Fehler im Tutorial? Unverständliche oder unvollständige Erklärung? Mehr Informationen gewünscht? Den Entwickler und Autor Dominik Schadow erreichen Sie per Email über info@xml-sicherheit.de oder über die zahlreichen Kontaktmöglichkeiten auf der Homepage.

XML Security Basics

Die Empfehlung zur Extensible Markup Language aus dem Jahr 1998 beschreibt in ihrer ersten Version und allen weiteren Überarbeitungen zehn vom World Wide Web Consortium (W3C) definierte Entwurfsziele (XML in 10 Points) für die Metasprache XML. Sicherheitsmechanismen wie Signaturen oder Verschlüsselung finden hierin jedoch keinerlei Beachtung.

Unter dem Stichwort XML-Sicherheit (XML Security) werden daher seit einigen Jahren Mechanismen zum Signieren sowie zum Verschlüsseln (mit) der Extensible Markup Language zusammengefasst. Die XML-Sicherheit stellt dabei einen deutlichen Paradigmenwechsel von auf der Abstract Syntax Notation One (ASN.1) basierten Binärstandards hin zu vollständig portablen und textbasierten XML-Lösungen dar. Im Gegensatz zur XML-Sicherheit ist ASN.1 eine Notationsart für die Beschreibung von abstrakten Datentypen und Werten. Interessant sind XML-Signaturen und XML-Verschlüsselung neben normalen XML-Anwendungen auch für Security Assertion Markup Language (SAML) und die umfangreichen WS-Security (Web Service Security) Empfehlungen.

Die W3C Empfehlungen zur Signatur und Verschlüsselung mit XML führen dabei keinerlei neuen Sicherheitsmechanismen ein. Sie legen vielmehr fest wie XML-Dokumente oder XML-Dokumentfragmente signiert bzw. verschlüsselt werden und wie diese Sicherheitselemente in das XML-Dokument eingebettet werden. Die Empfehlungen des W3C bringen so bekannte und vor allem bewährte kryptografische Algorithmen und Techniken mit der Extensible Markup Language zusammen. XML-Signaturen und XML-Verschlüsselung nutzen somit die Vorteile, die das Internet und XML bieten und bilden gängige Sicherungstechniken in die XML-Syntax ab. Die Sicherheit und Vertrauenswürdigkeit selbst werden auch nicht durch die Empfehlung vorgeschrieben, sondern vollständig der Implementierung überlassen.

Bezüglich der erlaubten Algorithmen machen die W3C-Empfehlungen dabei nur einige wenige Vorschläge. Meist werden aus jeder Algorithmenfamilie (beispielsweise symmetrische und asymmetrische Algorithmen) zumindest ein oder zwei Algorithmen angegeben, die für die W3C Konformität implementiert werden müssen. Was wie beim annähernd kompromittierten SHA-1 Algorithmus zu Problemen führen kann (ein Algorithmus der implementiert werden muss!). Außerdem folgen meist noch einige optional zu implementierende Algorithmen. Diese Vorgaben gewährleisten eine gewisse Interoperabilität und gleichzeitig eine leichte Erweiterbarkeit. Weitere Algorithmen können daher von einer konkreten Implementierung ergänzt werden, worunter allerdings die Interoperabilität leiden kann.

Vor allem die Festlegung bestimmter Algorithmen zeigt ein Problem auf: die W3C-Empfehlungen benötigen bekanntermaßen meist längere Zeit bis eine Candidate Recommendation daraus entsteht und sind dann auch für längere Zeit gültig. Im Gegensatz dazu kann aber ein lange als sicher geglaubter Algorithmus sehr schnell als unsicher eingestuft werden.

Feingranulare Sicherheit

Der größte Vorteil der XML-Sicherheit überhaupt gegenüber herkömmlichen Sicherungsmethoden liegt vor allem in der Möglichkeit, feingranular zu sichern. Mit Hilfe dieser Granularität lassen sich sowohl ganze XML-Dokumente als auch ausgewählte Fragmente (beispielsweise einzelne Elemente oder auch Elementinhalt) digital signieren und verschlüsseln:

• Erhaltung der Dokumentstruktur: Nicht sicherheitsrelevante Teile bleiben weiterhin im Klartext erhalten und können wie bisher weiterverarbeitet werden, geschützte Dokumentbereiche bleiben weiterhin geschützt. Damit können nur die relevanten Informationen gesichert werden, die gesicherten Bestandteile können gleichzeitig nahtlos in XML integriert werden.
• Verwendung mehrerer Zertifikate: Verschiedene Dokumentteile können mit unterschiedlichen Schlüsseln/ Zertifikaten signiert oder verschlüsselt werden. Somit ist eine feine Abstufung möglich, welche Kommunikationspartner welche Bereiche lesen oder bearbeiten dürfen und welcher Kommunikationspartner für welchen Bereich die Verantwortung übernimmt.

Informationsgebundene Sicherheit

Sowohl bei den XML-Signaturen als auch bei der XML-Verschlüsselung spricht man von einer so genannten Ende-zu-Ende-Sicherheit (End-to-End-Security) oder auch informationsgebundenen Sicherheit. Das bedeutet, dass die Daten auch bei der Weiterverarbeitung verschlüsselt und signiert bleiben können und die Sicherheit nicht von einem bestimmten Dienst abhängt (bekanntestes Beispiel ist hier neben der XML Security auch PKCS#7). Somit kann die Signatur zusammen mit den verschlüsselten Daten auf dem Server, in der Datenbank oder anderswo gespeichert werden.

Das Gegenteil zur informationsgebundenen Sicherheit ist die so genannte Punkt-zu-Punkt-Sicherheit (Hop-to-Hop-Security) oder auch transportgebundene Sicherheit. Dabei ist die Sicherheit nur von einer Entität zur benachbarten Entität gewährleistet. Hierbei wird auch von dienstgebundener Sicherheit gesprochen (bekanntestes Beispiel ist hier https bzw. SSL). Am Endpunkt angekommen gibt es somit keine Sicherheit mehr, die Daten werden im Klartext gespeichert (Sicherheit des Übertragungskanals aber keine Sicherheit der Daten) oder erneut mit anderen Mechanismen verschlüsselt.

Vorteil der informationsgebundenen Sicherheit ist neben dem Speichern der gesicherten Daten auch, dass die Daten während des Transports durch berechtigte Beteiligte verarbeitet, ergänzt und modifiziert werden können. Die informationsgebundene Sicherheit ist gleichzeitig unabhängig von Anwendung und Protokoll. Bei der dienstgebundenen Sicherheit kann das nur der Empfänger am Endpunkt. Außerdem gilt bei der dienstgebundenen Sicherheit das Prinzip ganz oder gar nicht, d.h. entweder wird alles signiert bzw. verschlüsselt oder überhaupt nichts. Das verursacht spätestens bei den Web Services Probleme, da hier bestimmte Bereiche des XML-Dokuments Transportinformationen enthalten können auf die auch während der Übertragung zugegriffen werden müssen. Außerdem kann eine SOAP Nachricht (die ja nichts anderes ist als ein XML-Dokument) von mehreren Web Services erstellt/ ergänzt werden. Nachteile der informationsgebundenen Sicherheit sind allerdings die höhere Komplexität und der höhere Aufwand beim Verarbeiten der Nachrichten. Dieser höhere Aufwand entsteht durch das Sichern der Anwendungsschicht, die Nachrichten werden im Gegensatz zu SSL auf der Transportschicht auch inhaltlich modifiziert.

Signierte Verschlüsselung vs. verschlüsselte Signatur

Die übliche Frage, zuerst signieren oder verschlüsseln, stellt sich natürlich auch bei der XML-Sicherheit. Bewährt hat sich die Reihenfolge, die Nachricht zuerst zu signieren und anschließend zu verschlüsseln. Zum einen liegt dies daran, dass der Signierende einen verschlüsselten Text unter Umständen nicht lesen kann und damit überhaupt nicht weiß, was er signiert. Dadurch können rechtliche Probleme aufgeworfen werden. Eine Signatur über den Klartext bestätigt daher, dass der Signierende die Nachricht verfasst hat oder zumindest Kenntnis davon hat. Außerdem lässt sich eine Signatur in einem verschlüsselten Dokument nicht entfernen und durch eine andere ersetzen. Gleichzeitig besteht damit die Möglichkeit, dass der Signierende so lange anonym bleibt, bis die Nachricht vom Empfänger entschlüsselt wird. Ein weiterer Punkt ist, dass eine Signatur über ein verschlüsseltes Dokument zwangsläufig ungültig wird, sobald dieses entschlüsselt wird. Auf der anderen Seite ist es bei der Reihenfolge zuerst Signatur dann Verschlüsselung durchaus möglich, dass nicht der Signierende die Verschlüsselung durchgeführt hat.

Bei der anderen Vorgehensweise, zuerst Verschlüsselung dann Signatur, steht fest, dass der Signierende den Geheimtext erzeugt hat oder ihn zumindest bewusst durch seine Signatur bestätigt. Es ist jedoch nicht sicher, ob der Signierende den Klartext überhaupt kennt.

Signaturarten

Wie bei den herkömmlichen digitalen Signaturen unterscheidet man auch bei den XML Signaturen drei verschiedene Arten: einfache, fortgeschrittene und qualifizierte Signaturen. Nur die qualifizierte Signatur ist dabei der eigenhändigen Unterschrift gleichgestellt. Diese gilt dabei im Gegensatz zu den beiden anderen Arten im Streitfall automatisch (bis zum Beweis des Gegenteils) als echt.

Qualifizierte Signaturen verwenden ein von einem Trustcenter ausgestelltes Zertifikat, das in der Regel auf einer Smartcard gespeichert wird. Fortgeschrittene Signaturen können dagegen auch mit Softwaremitteln erzeugt werden; der Erzeuger muss nur gewährleisten, dass ausschließlich er die Signatur generieren kann (z.B. durch ein Passwort). Einfache Signaturen schließlich entsprechen der Unterschrift, z.B. unter einem beliebigen digitalen Dokument wie einer Email. Sie gewährleisten folglich nicht einmal die Integrität des Dokuments (die beiden anderen Signaturarten stellen das durch den signierten Hashwert sicher). Außerdem kann eine solche digitale Unterschrift natürlich von jedem erstellt werden.

Beispiel

Auf das folgende XML-Dokument wird in den Tutorials und den Cheat Sheets der XML Security Tools immer wieder zurückgegriffen. Das XML-Dokument stellt eine fiktive Rechnung dar und wird im Verlauf des Tutorials signiert und verschlüsselt werden. Bei Verwendung der Cheat Sheets wird damit das XML-Dokument FirstSteps.xml in dem ebenfalls angelegten Projekt XML Security erstellt.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice>
 <ID>IN 2008/00645</ID>
 <IssueDate>2008-03-30</IssueDate>
 <BuyerParty>
  <ID>458746</ID>
  <name>John Doe</name>
 </BuyerParty>
 <PaymentMeans>
  <PayeeFinancialAccount>
   <ID>07044961</ID>
   <Name>The Specialists Company</Name>
   <AccountTypeCode>Credit</AccountTypeCode>
   <FinancialInstitutionBranch>
    <ID>776631</ID>
    <Institution>LOYDGB852</Institution>
   </FinancialInstitutionBranch>
  </PayeeFinancialAccount>
 </PaymentMeans>
 <TotalAmount currencyID="€">382.00</TotalAmount>
 <!-- item 1 -->
 <InvoiceLine id="1">
  <Quantity>2</Quantity>
  <LineAmount currencyID="€">205.00</LineAmount>
  <Item id="236WV">
   <BasePrice currencyID="€">102.50</BasePrice>
  </Item>
 </InvoiceLine>
 <!-- item 2 -->
 <InvoiceLine id="2">
  <Quantity>1</Quantity>
  <LineAmount currencyID="€">177.00</LineAmount>
  <Item id="193DX">
   <BasePrice currencyID="€">177.00</BasePrice>
  </Item>
 </InvoiceLine>
</Invoice>

Das Beispiel signiert (enveloped, enveloping, detached) oder verschlüsselt (enveloping, detached).

Das Basic Security Profile

Das Basic Security Profile (BSP) der Web Services Interoperability Organization (WS-I) basiert auf einer ganzen Reihe von herstellerunabhängigen (non-proprietary) Web Service Spezifikationen. Das Basic Security Profile ist dabei eine Erweiterung des Basic Profile um Sicherheitsmechanismen. Ziel des BSP ist es, die Interoperabilität zwischen verschiedenen Web Services zu erhöhen. Teilweise geht mit diesem Ziel eine Erhöhung der Sicherheit einher, was aber selbst kein primäres Ziel des Profils darstellt. Die Anmerkungen und Einschränkungen des Basic Security Profile zu den Signaturen und der Verschlüsselung mit XML (sowie natürlich auch alle anderen Angaben) beziehen sich ausschließlich auf die Verwendung in Web Services. Das BSP macht damit keinerlei Aussagen zur generellen Verwendung der XML-Sicherheit noch bewertet es diese.

Neben den Signaturen und der Verschlüsselung mit XML beschäftigt sich das Basic Security Profile zum Beispiel noch mit der Transport Layer Security sowie in Ansätzen mit X.509 Zertifikaten. Generell ist das BSP auf moderne Standards ausgelegt. Als Algorithmus kommt daher häufiger der moderne Advanced Encryption Standard (AES) als das schon etwas ältere Triple DES zum Zug.

Warum unterstützen nun die XML Security Tools das Basic Security Profile und macht die XML-Sicherheit noch etwas komplizierter und umfangreicher? Das Plug-in stellt ja primär eine Lernsoftware für die XML-Sicherheit dar, die Interoperabilität der generierten Signaturen oder Verschlüsselung in Web Services ist damit nicht unbedingt erforderlich.

Die XML Security Tools wollen neben der Theorie auch Anwendungen der XML-Sicherheit zeigen und auch einen praktischen Einsatz der gesicherten XML-Dokumente ermöglichen. Web Services verwenden bekanntermaßen XML (bzw. die SOAP Nachrichten bestehen aus XML) und sind gleichzeitig, bedingt durch die Offenheit des Internets, auch ideale Kandidaten für die XML-Sicherheit. Das Plug-in will mit dem BSP zeigen, welche Einschränkungen auch für offene und herstellerunabhängige W3C Empfehlungen gemacht werden (müssen), um die Interoperabilität bei den Web Services zu erhöhen.

Hier in der Hilfe wird dabei nicht das gesamte umfangreiche Basic Security Profile wiedergegeben. Stattdessen werden nur einige ausgewählte Aspekte erwähnt (vornehmlich die durch die Empfehlung vorgegebenen Einschränkungen). Sollten Sie am BSP interessiert sein, können Sie das BSP im XML Signature Wizard und im XML Encryption Wizard aktivieren und BSP konforme Signaturen und Verschlüsselungen generieren.

Digitale Signaturen

Bei den Empfehlungen des W3C zu den Signaturen legt das Basic Security Profile einige Einschränkungen bei den Signaturvarianten sowie bei den verwendeten Algorithmen auf. So erlaubt das BSP nicht die Verwendung einer enveloping signature. Begründet wird dies mit den Eigenschaften des SOAP Processing Models, bei dem die Kindelemente des Header/ Body auch von Zwischenstationen (SOAP Intermediaries) einfach erkannt werden müssen. Da enveloping signatures die signierte Nachricht als Kindelement innerhalb der Signatur enthalten, ist diese Signaturvariante ungeeignet. Eine enveloped signature kann dagegen verwendet werden. Da diese Signaturvariante die Nachrichtenverarbeitung jedoch zumindest einschränkt, wird von ihrer Verwendung aber abgeraten. Das Basic Security Profile empfiehlt daher die Verwendung einer detached signature, also die Trennung von Signatur und signierten Daten.

Auch bezüglich der Algorithmen werden verschiedene Einschränkungen vorgegeben. Für die Kanonisierung muss so eine Exclusive XML Canonicalization without Comments verwendet werden. Als Message Digest gibt es nur SHA1. Bei den Key Signature Algorithms sind der symmetrische Algorithmus HMAC-SHA1 und der asymmetrische Algorithmus RSA-SHA1 zugelassen.

Dies sind nur einige der vorhandenen Eigenschaften des Basic Security Profile zu den XML Signaturen. Die vollständige Dokumentation findet sich im Basic Security Profile in Abschnitt acht.

Verschlüsselung

Bei der XML-Verschlüsselung macht das Basic Security Profile vor allem Vorgaben, wann welche Attribute erscheinen dürfen/ müssen und wann nicht. So darf z.B. ein EncryptedKey Element nicht die Attribute Type, MimeType und Encoding enthalten. Das Element EncryptedData muss dagegen ein Id Attribut besitzen. EncryptedData und EncryptedKey müssen beide ein EncryptionMethod Kindelement haben.

Auch so - eigentlich selbstverständliche - Dinge wie das Ersetzen des Klartexts durch den Chiffretext gibt das Basic Security Profile vor.

In Bezug auf die Algorithmen zur Datenverschlüsselung (Data Encryption Algorithm) schreibt das BSP derzeit die Verwendung von Triple DES, AES 128 oder AES 256 (jeweils im CBC Modus) vor. Als Schlüsseltransportalgorithmus (Key Transport Algorithm) sind derzeit die Algorithmen RSA PKCS#1.5 sowie RSA-OAEP erlaubt. Bei den Key Wrap Algorithmen sind Triple DES Key Wrap sowie AES 128 und AES 256 Key Wrap zugelassen.

Sowohl bei digitalen Signaturen als auch der Verschlüsselung sollte die Anwendung sicherstellen, dass vergebene IDs im XML-Dokument eindeutig sind. Dies wird zwar auch von der XML-Empfehlung gefordert aber lediglich von validierenden Parsern überprüft.

Die vollständigen Eigenschaften des Basic Security Profiles zur XML-Verschlüsselung finden sich in Abschnitt neun der Empfehlung.

Signaturen Grundlagen

Gemeinsam mit der Internet Engineering Task Force (IETF) hat das W3C am 12. Februar 2002 die erste Version der XML Signature Syntax and Processing Recommendation freigegeben. In dieser Empfehlung (und im identischen RFC der IETF) ist exakt und umfassend festgelegt, welche Form eine Signatur mit XML besitzt und wie diese verarbeitet werden kann. Die Empfehlung beschreibt dabei sowohl das Signieren beliebiger Elemente eines XML-Dokuments als auch beliebiger, auch binärer, externer Daten mit gängigen kryptografischen Standards und bietet vielfältige Möglichkeiten zur Erstellung einer Signatur.

XML-Signaturen basieren auf der Metasprache XML und beschreiben ein auf XML basierendes Format für digital signierte Daten. XML Signaturen sorgen für Nachrichtenintegrität, Nachrichten- und Teilnehmerauthentizität sowie Verbindlichkeit (Nicht-Abstreitbarkeit) für Daten beliebigen Typs (arbitrary data), egal ob die Daten innerhalb oder außerhalb des XML-Dokuments mit der Signatur liegen.

Kurz gesagt bindet eine digitale Signatur eine Nachricht eindeutig an eine Nachrichtenquelle. Die Integrität gewährleistet dabei, dass die Informationen vollständig und unverändert vorliegen. Nachrichtenauthentizität bedeutet, dass die Informationen einem bestimmten Urheber zugeordnet werden können, Teilnehmerauthentizität steht für die zweifelsfreie Nachweisbarkeit der Identität des Senders. Die Verbindlichkeit sorgt schließlich für den Nachweis, dass eine bestimmte Nachricht von einem bestimmten Sender stammt. Die von Cisco im Februar 2003 als Ergänzung (W3C Note) veröffentlichten XML Advanced Electronic Signatures (XAdES) widmet sich ganz dieser Thematik. XAdES Signaturen bauen auf XML Signaturen auf und verwenden deren Erweiterungsmechanismen (das ds:Object Element). XAdES ergänzt XML Signaturen also um einige weitere Möglichkeiten wie Langzeitsignaturen, Unwiderrufbarkeit und verschiedene andere gesetzliche Aspekte.

XML-Signaturen sind zwar vorrangig für XML-Dokumente vorgesehen aber keineswegs auf diese beschränkt. Vielmehr lassen sich mit XML alle Daten, die durch einen Uniform Resource Identifier (URI) referenziert werden können, inhalts- und herstellerunabhängig signieren. Einer XML-Signatur ist immer mindestens eine Ressource (XML-Baum oder beliebige Binärdaten) zugeordnet. Es spielt dabei keine Rolle ob sich diese Daten innerhalb oder außerhalb des XML-Dokuments befinden.

Der Inhalt der übertragenen Daten wird durch die Signatur nicht verändert, allerdings verändert sich die Struktur des XML-Dokuments. Trotz der Veränderungen durch die Signatur bleibt das XML-Dokument auch weiterhin für Dritte lesbar, Schemata oder DTDs für validierende Parser müssen unter Umständen aber entsprechend angepasst werden.

Präsentationsproblem

Beim Signieren mit XML gilt die Redensart What You See Is What You Sign (WYSIWYS). Also eigentlich genau das, was der Anwender erwartet: das was er sieht wird auch von ihm signiert. Das ist eine gefährliche Behauptung wie das folgende Beispiel gleich zeigen wird. Nehmen wir z.B. ein XML-Dokument und dazu ein XSL-Stylesheet. Wird die Signatur nur über das Daten-XML berechnet kann das Stylesheet ohne Auswirkung auf die Signatur ausgetauscht oder modifiziert werden. Als Folge davon kann das angezeigte XML-Dokument erheblich vom Original abweichen, obwohl die Signatur über dem Daten-XML immer noch gültig ist. Das Daten-XML wurde ja nicht verändert, mit dem Stylesheet können aber beliebig viele Transformationen, z.B. Berechnungen, darauf angewendet werden. Diese Probleme sind bekannt und auch nicht rein auf XML beschränkt. Generell spricht man hierbei vom Präsentationsproblem.

Eine Lösung besteht darin, mit dem Daten-XML auch alle verbundenen XML-Dokumente (XSLT, Schema, DTD, ...) zu signieren. Ganz so einfach lässt sich das Problem aber nicht aus der Welt schaffen. XSL-Stylesheets können weitere Stylesheets importieren usw., das Berechnen der Signatur, in erster Linie das Zusammensuchen der XML-Dokumente, kann beliebig aufwändig und komplex werden. Gleichzeitig müssen ja alle zu signierenden Ressourcen auch noch verfügbar (zugreifbar) sein.

Die nächste auftretende Frage ist dann, wie dem Anwender ein ungültiges Stylesheet (das kann eines von vielen sein oder auch alle) präsentiert wird. Sprich die Signatur über das XML-Dokument ist gültig, aber eines oder mehrere Stylesheets wurden nach dem Signieren verändert oder sind einfach nicht mehr vorhanden. Die Herausforderung ist hier eine verständliche Anzeige für den Anwender. Am einfachsten ist es sicherlich, die ganze Signatur als ungültig darzustellen. Nur ist das nicht ganz korrekt. Wird dem Anwender jedoch mitgeteilt, dass Teile der Signatur ungültig sind, benötigt er umfangreichere XML-Kenntnisse als er vielleicht hat. Weiterhin ist es ja auch so, dass nicht alle Manipulationen am Stylesheet eine (negative) Auswirkung auf die Darstellung haben müssen.

Die beste Lösung ist meiner Ansicht nach die Darstellung mit zwei Fehlerarten: das Daten-XML ist ungültig und/ oder eine zur Darstellung verwendete Ressource ist ungültig bzw. nicht mehr erreichbar. Bei einem ungültigen Daten-XML ist der Fall klar. Bei einem ungültigen Stylesheet sollte der Anwender auf das reine Daten-XML hingewiesen werden. Auch wenn der Anwender selbst nicht über genügend Kenntnisse verfügt kann sich immer noch ein Experte die Daten ansehen und bewerten. In jedem Fall nehmen aber die Fehlerarten zu, die Verantwortung wie letztlich damit umgegangen wird, liegt aber beim Anwender.

Kanonisierung und Transformation

Zwei Begriffen kommen bei einer Signatur mit XML eine große Bedeutung zu: Kanonisierung (canonicalization, auch C14N) und Transformation (transformation). C14N übrigens deshalb, weil zwischen dem ersten Buchstaben C und dem letzten n von Canonicalization genau 14 weitere Buchstaben stehen.

Bei der Kanonisierung eines XML-Dokuments wird dieses in einheitlicher Form in einen Bytestrom überführt. Kanonisierung steht somit für die Normalisierung von XML-Dokumenten, um robuste und sichere Signaturen zu ermöglichen. Neben dem Einsatz bei Signaturen ist die Kanonisierung beispielsweise auch wichtig bei der XML-basierten Versionskontrolle (d.h. beim diff).

Mit Transformationen beschreibt XML die Umwandlung von referenzierten Daten vor der Signierung auf verschiedenste Art und Weise.

Kanonisierung

Trotz logischer Gleichheit der reinen Dokumentdaten lassen sich Veränderungen am physischen Dokument durch die Verarbeitung, beispielsweise auf verschiedenen Plattformen oder in unterschiedlichen Editoren/ Anwendungen, nicht verhindern. Um ungültige Signaturen auszuschließen, wird daher vor dem Signieren ein Kanonisierungs-Algorithmus auf das wohlgeformte XML-Dokument angewandt. Hiermit werden syntaktische Unterschiede - wie beispielsweise der Zeichensatz, Zeilenumbrüche, leere Tags und die Reihenfolge der Attribute - von ansonsten semantisch identischen XML-Dokumenten kanonisiert. Eine andere Bezeichnung für Kanonisierung ist Normalisierung. Der Kanonisierungs-Algorithmus stellt dabei sicher, dass immer dieselben Bytes in die Hashwertberechnung einfließen und anschließend signiert werden. Die bei Signaturen zahlreich vorhandenen URIs werden jedoch niemals kanonisiert.

Auffällig ist, dass zwar die XML-Deklaration zur Kanonisierung herangezogen wird, diese Deklaration im kanonisierten XML-Dokument aber nicht mehr enthalten ist. Das ist nur konsequent, die Angabe des encodings ist überflüssig da ein kanonisches XML-Dokument immer in einer UTF-8 Kodierung vorliegt und eine fehlende Versionsangabe immer XML Version 1.0 bedeutet. Das erfordert allerdings, dass bei einer neuen XML-Version auch die Kanonisierung überarbeitet wird.

Beim Kanonisieren eines XML-Dokuments finden die folgenden Aktionen statt:

• Das Dokument wird in UTF-8 kodiert
• Zeilenumbrüche werden vor dem Parsen normalisiert zu #xA
• Attributwerte werden normalisiert (wie bei einem validierenden Parser)
• Character- und parsed-entity Referenzen werden ersetzt
• CDATA Abschnitte werden durch ihren Inhalt ersetzt
• Die XML-Deklaration und eine möglicherweise vorhandene DTD werden entfernt
• Leere Elemente werden zu Start-End-Tag Paaren umgewandelt
• Whitespace außerhalb des Dokumentelements und innerhalb von Start- und End-Tags wird normalisiert
• Whitespace in Textknoten wird beibehalten (gilt jedoch nicht für Zeichen die bei der Normalisierung der Zeilenumbrüche entfernt wurden)
• Attributwerte werden in doppelten Anführungsstrichen eingeschlossen
• Sonderzeichen in Attributwerten und Textknoten werden durch Zeichenreferenzen ersetzt
• Überflüssige Namespace Deklarationen werden von jedem Element entfernt
• Defaultattribute werden zu den jeweiligen Elementen hinzugefügt
• Namespace Deklarationen und Attribute werden alphanumerisch sortiert

Zu kanonischem XML existieren seit 15. März 2001, 18. Juli 2002 bzw. 29. Januar 2008 drei Empfehlungen des W3C: Canonical XML 1.0 (C14N 1.0), Canonical XML 1.1 (C14N 1.1) und Exclusive XML Canonicalization 1.0. Drei Empfehlungen, die alle mehr oder weniger das Gleiche tun...

Nun ja, es gibt einige Unterschiede: So wird die exclusive Variante unter anderem für Protokolle wie SOAP und damit Web Services benötigt und sollte auch in Zusammenhang mit xml:id verwendet werden. Mit der gebräuchlicheren Exclusive XML Canonicalization 1.0 wird ein XML-Dokument soweit wie möglich ohne den dazugehörigen Kontext (d.h. Namensräume der Vorfahren) normalisiert. Damit wird eine Signatur auch nicht ungültig falls ein kanonisiertes Dokumentfragment aus dem Kontext entfernt und/ oder in ein anderes XML-Dokument eingefügt wird.

Alternativ kann bei Verwendung von xml:id oder xml:base Attributen auch die aktualisierte Canonical XML 1.1 Empfehlung angewendet werden, mit Canonical XML 1.0 gibt es hier Probleme. Canonical XML 1.0 und Canonical XML 1.1 machen jedoch prinzipiell dasselbe, die Verwendung der aktualisierten Version 1.1 wird aber empfohlen. Es wurde weiter oben schon angesprochen, bei der Kanonisierung von Dokumentfragmenten kann der übergeordnete Kontext verloren gehen. Damit das XML-Dokument z.B. durch eine nach der Kanonisierung fehlende Namespace Deklaration nicht ungültig wird, werden Attribute kopiert. Auch solche im xml Namespace wie z.B. xml:base und xml:id. Und mit diesen beiden gibt es Probleme. Während bei xml:base einfach auch der Attributwert (d.h. der darin enthaltene Pfad) angepasst werden muss, ist das Kopieren von xml:id schlichtweg falsch. xml:id ist eine Empfehlung vom September 2005 und beschreibt kurz gesagt eine Möglichkeit, Elemente mit eindeutigen IDs auszustatten. Eine ID muss eindeutig sein, nach dem Kopieren ist das aber nicht mehr der Fall. C14N 1.1 wurde dahingehend erweitert, dass xml:base Attribute angepasst werden und xml:id nicht kopiert, d.h. nicht in den Kontext eines Subdokuments übernommen werden. Bei der Verwendung von C14N 1.0 können hier xml:id errors auftreten. Das sind zwar keine fatalen Fehler, d.h. das XML-Dokument kann weiterverarbeitet werden, trotzdem kann das XML-Dokument später unbrauchbar sein.

Die Exclusive XML Canonicalization 1.0 und auch Canonical XML 1.1 weisen dieses Feature (es handelt sich tatsächlich ein Feature und nicht um einen Bug) nicht auf, daher sollte bei XML-Dokumenten mit xml:id Attributen besser auf einen dieser Kanonisierungs-Algorithmen zurückgegriffen werden.

Canonical XML 1.1 ist übrigens, auch wenn es der Name andeuten mag, nicht für XML 1.1 geeignet. Für XML 1.1 steht noch keine Kanonisierungsmöglichkeit zur Verfügung; XML Signaturen können daher mit XML 1.1 derzeit nicht verwendet werden. Mangels Rückwärtskompatibilität wird XML 1.1 wohl ohnehin nur für wenige Anwendungsgebiete und Entwickler interessant sein, daher lässt sich das wohl verschmerzen. Elliotte Rusty Harold empfiehlt XML 1.1 ohnehin nur einer eingeschränkten Zielgruppe: "XML 1.1 has a number of new features that make it much more suitable for use by IBM mainframe programmers and people whose native language is Amharic, Burmese, or Cambodian.". Alle anderen können ohne schlechtes Gewissen auch weiterhin XML 1.0 verwenden.

Aber ganz egal welche Kanonisierung verwendet wird, es stehen immer jeweils zwei Möglichkeiten zur Kanonisierung zur Verfügung. Bei der einen Version werden die Kommentare im kanonisierten XML-Dokument entfernt (canonical XML omits comments), bei der anderen Version bleiben die Kommentare erhalten (canonical XML with comments). Auch bei der Kanonisierung ist es möglich, nur XML-Dokumentfragmente zu kanonisieren und die restlichen Dokumentteile in ihrer ursprünglichen Form zu belassen. Im Gegensatz zum vollständigen Kanonisieren eines XML-Dokuments kann es bei einer XML-Dokument Untermenge (document subset) durchaus vorkommen, dass das resultierende XML-Dokument nicht mehr wohlgeformt ist.

Die vorhandenen Kanonisierungs-Algorithmen und die zugehörigen Uniform Resource Identifier zeigt die folgende Tabelle. Identifiziert wird der gewünschte Algorithmus immer über den jeweiligen URI.

Transformation

Mittels Transformationen können die durch das URI Attribut adressierten Daten vor der Hashwertberechnung umgewandelt und gezielt Dokumentfragmente zum Signieren ausgewählt werden.

Base64 wandelt Base-64 Zeichenketten zurück in die entsprechenden Oktette. Base-64 ist ein von der IETF spezifiziertes Kodierungsverfahren für Binärdaten und ermöglicht die Einbettung beliebiger Daten in das XML-Dokument. Der Name Base-64 kommt daher, dass zur Kodierung von Daten aller Art nur die 64 Zeichen a-z, A-Z, 0-9,+,/ verwendet werden. Binäre Zeichen könnten sonst nicht in XML dargestellt werden. Die so eingebetteten Binärdaten werden im Base-64 encoding dadurch allerdings um 33% größer als die Ursprungsdaten im Binärformat.

Die Enveloped Signature Transform verhindert, dass Signaturen sich selbst signieren, indem vor dem Signieren alle zur Signatur gehörenden Elemente durch die Transformation entfernt werden.

Das XPath Filtering verarbeitet XPath-Knoten. Mit diesen Transformationen können Knoten aus einer XML-Knotenmenge ausgewählt werden, die beim Signieren berücksichtigt werden sollen. Der Rest des Dokuments wird nicht in die Signatur miteinbezogen. Wird XPath als Transformation einer XML-Signatur verwendet, wird es als Filtermechanismus angewandt und nicht als Auswahlmechanismus. Der XPath Filter 2.0 besitzt die gleichen Funktionen wie die ursprünglichen XPath Transformationen, arbeitet aber sehr viel effizienter und besitzt eine einfachere Syntax.

Eine XSLT Transform transformiert die zu signierenden Daten mit den Extensible Stylesheet Language Transformations (XSLT). Mit XSLT können die XML-Daten beispielsweise vor dem Signieren in die HyperText Markup Language (HTML) umgewandelt werden.

Möglich sind die in der folgenden Tabelle aufgeführten Transformationen. Zusätzlich zu den hier aufgeführten Algorithmen gehören auch die bereits bei der Kanonisierung genannten Algorithmen zu den Transformationen.

Signaturvarianten

Wie bereits erwähnt können mit XML erstellte Signaturen mittels Referenzen verschiedene Typen von Objekten signieren. Die Signaturen lassen sich daher in drei verschiedenen Varianten erzeugen: enveloped signature (eingebettet), enveloping signature (einbettend) und detached signature (getrennt). Der wesentliche Unterschied zwischen diesen drei Varianten ist, an welcher Stelle im XML-Dokument die Signatur dargestellt wird. Signaturen vom Typ enveloped und enveloping werden im gleichen XML-Dokument wie die zu signierenden Daten abgelegt, signiertes Dokument und Signatur weisen daher eine enge Bindung auf. Bei detached Signaturen liegt die Signatur normalerweise in einer separaten Datei, signiertes Dokument und Signatur haben damit eine eher lose Bindung.

Es gibt keine generelle Empfehlung, wann welche Signaturvariante zu verwenden ist. Letztendlich hängt dies von der Applikation und weiteren Anforderungen ab. Grob orientieren kann man sich an den folgenden Empfehlungen: Eine enveloped signature ist ideal geeignet zum Signieren von einfachen XML-Dokumenten. Die enveloping signature ist besser geeignet, wenn zu den signierten Daten weitere Informationen wie z.B. ein Zeitstempel hinzugefügt werden sollen (und natürlich ebenfalls mit signiert werden). Die detached signature schließlich ist ideal, wenn die zu signierende Ressource nicht modifiziert werden kann oder soll.

Weitergehende Möglichkeiten als die bekannten herkömmlichen Signaturverfahren bieten XML-Signaturen beim Signieren von Teilbäumen, Dokumentfragmenten und mehreren Dokumenten gleichzeitig. Der entscheidende Vorteil von digitalen Signaturen mit XML - das Signieren von Dokumentfragmenten - kann natürlich nur ausgespielt werden, wenn das Dokument selbst in XML-Syntax vorliegt.

XML-Digitale Signaturen ermöglichen es daher, ein oder mehrere Knoten eines XML-Baums auszuwählen und nur diese zu signieren. Vorteilhaft ist das beispielsweise, wenn ein Anwender nur ausgewählte Teile eines Dokuments digital signieren will. Ein weiterer Anwender kann bestimmte Dokumentteile anschließend trotzdem verändern, ohne dass die vorherige Signatur ungültig wird. Anschließend kann dieser Anwender ein weiteres Dokumentfragment (oder auch das gesamte XML-Dokument) signieren. Gleichzeitig bedeutet das aber, dass nicht signierte Dokumentfragmente wie gezeigt verändert werden können, ohne dass dies von der Signatur bemerkt wird. Nur signierte Bestandteile eines Dokuments können als sicher betrachtet werden.

Enveloped Signature

Bei einer enveloped signature stellt das zu signierende Dokument das Elternelement zum Signature Element dar. Das Signature Element ist somit vom zu signierenden Dokument umgeben und damit in der Baumstruktur der zu signierenden Daten enthalten. Diese Variante ist mit einer herkömmlichen handschriftlichen Unterschrift vergleichbar.

Enveloped Signature

Der XML-Baum hat damit den folgenden Aufbau:

<DocumentData>
  <Signature>
  </Signature>
</DocumentData>

Enveloping Signature

Werden die zu signierenden Daten als Kindelemente der Signatur dargestellt, wird dies als enveloping signature bezeichnet. Der signierte Inhalt steht bei dieser Signaturvariante als Kindelement von Object innerhalb des Signature Elements.

Enveloping Signature

Der XML-Baum hat damit den folgenden Aufbau:

<Signature>
  <DocumentData>
  </DocumentData>
</Signature>

Detached Signature

Bei einer detached signature gibt es keine Eltern-Kind-Beziehung zwischen Signatur und Dokument. Das Originaldokument ist vielmehr eine separate Ressource. Das zu signierende Dokument wird bei einer detached signature nicht verändert. Der signierte Inhalt kann sich im selben Dokument wie die Signatur oder in einem anderen Dokument befinden.

Detached Signature

Der XML-Baum hat damit den folgenden Aufbau:

<Signature>
</Signature>
<DocumentData>
</DocumentData>

Syntax

XML Signaturen basieren auf einer großen Anzahl verschiedener XML und kryptografischer Techniken. Die Syntax zeichnet sich daher durch eine starke Strukturierung sowie eine weit reichende Erweiterbarkeit und Flexibilität aus.

Zunächst einmal werden alle relevanten Signaturdaten (die signierten Ressourcen, verwendete Algorithmen, usw.) in das XML-Dokument eingebettet. Der Empfänger bzw. die empfangende Applikation findet somit alle notwendigen Informationen im XML-Dokument vor die für eine erfolgreiche Verifizierung benötigt werden.

Innerhalb einer XML-Signatur werden wie gesagt stets die verwendeten Algorithmen angegeben. Diese Algorithmen werden mit einem URI identifiziert, unter dem im Normalfall eine Beschreibung des jeweiligen Verfahrens abgelegt ist.

Das folgende Listing zeigt alle vorhandenen Elemente einer XML-Signatur. ? erlaubt das null- bis einmalige, + das mindestens ein- bis mehrmalige und * das null- bis mehrmalige Vorkommen als Attribut oder Element. Die vollständige Syntax beschreibt das Schema zu den digitalen Signaturen mit XML.

<ds:Signature ID?>
  <ds:SignedInfo>
   <ds:CanonicalizationMethod/>
   <ds:SignatureMethod/>
   (<ds:Reference URI?>
    (<ds:Transforms/>)?
    <ds:DigestMethod/>
    <ds:DigestValue/>
   </ds:Reference>)+
  </ds:SignedInfo>
  <ds:SignatureValue/>
  (<ds:KeyInfo/>)?
  (<ds:Object ID?/>)*
</ds:Signature>

Das Signature Element

Das Wurzelelement einer digitalen Signatur mit XML wird durch das Element Signature dargestellt.

Signature besitzt ein optionales Attribut Id vom Typ ID zur Identifikation der Signatur. Dieses Attribut ermöglicht die Identifikation einer bestimmten Signatur, falls ein XML-Dokument mehrere Signaturen enthält. Des Weiteren deklariert das Element den Namensraum (namespace) der Signatur mit dem Attribut xmlns. Das Namensraum Attribut kennzeichnet gleichzeitig auch die Version der XML-Signatur, eine Versionsangabe wie beispielsweise bei den XSL Transformations ist daher nicht notwendig. Derzeit gibt es für den Namensraum einen einzigen Wert: http://www.w3.org/2000/09/xmldsig# der an das Präfix ds gebunden wird. Neuere Versionen der Empfehlung werden einen anderen Namensraum verwenden.

Signature besitzt vier Kindelemente, wovon die beiden Elemente SignedInfo und SignatureValue Pflicht sind. Des Weiteren kann ein KeyInfo Element angegeben werden sowie beliebig viele Object Elemente (auch null). Im Minimalfall besteht die XML-Signatur somit nur aus den Elementen SignedInfo und SignatureValue.

Das SignedInfo Element

Das erste und auch komplexeste Element innerhalb von Signature ist SignedInfo und enthält die verwendeten Algorithmen zur Kanonisierung und Signierung, eine oder mehrere Referenzen auf die signierten Daten, eventuelle Transformationen und die Hashwerte dieser Daten. SignedInfo enthält also alle Informationen zu den zu signierenden Ressourcen und ist damit der Teil, über den die digitale Signatur erstellt wird.

Mit dem Signieren der verwendeten Algorithmen erhöht sich die Sicherheit. Ein sicherer Algorithmus kann so nicht gegen einen unsicheren ausgetauscht werden, ohne dass die Signatur ungültig wird.

Weitere Eigenschaften, wie z.B. ein Zeitstempel oder die Seriennummer der verwendeten kryptografischen Hardware, können nur durch ein oder mehrere optionale Kindelemente SignatureProperties in einem Object Element angegeben werden. Für einen Zeitstempel existiert dazu beispielsweise das Element timestamp, mit dem ein Zeitstempel vor der Erstellung der Signatur in die signierten Daten eingebunden werden kann.

SignedInfo kann ein optionales Attribut Id enthalten mit dem das Element z.B. von anderen Signaturen referenziert werden kann. Kindelemente von SignedInfo sind die Pflichtelemente CanonicalizationMethod und SignatureMethod sowie ein oder mehrere Reference Elemente.

CanonicalizationMethod

Das leere Pflichtelement CanonicalizationMethod enthält ein Algorithm Attribut zur Identifikation des Kanonisierungs-Algorithmus, der vor der Signaturberechnung auf die Daten in SignedInfo angewendet wird. Die möglichen Werte des URI finden sich in der Tabelle bei der Kanonisierung.

SignatureMethod

SignatureMethod ist ebenfalls ein leeres Pflichtelement mit einem Algorithm Attribut und gibt den zur Signaturgenerierung (und später zur Verifizierung) verwendeten Algorithmus an. Mit diesem Algorithmus wird das kanonische SignedInfo Element in den SignatureValue konvertiert. Der URI kann die in der folgenden Tabelle aufgeführten Werte annehmen. Die Verwendung von weiteren Algorithmen ist möglich, aber von der konkreten Implementierung abhängig.

Reference

Es folgen mindestens ein oder mehrere Reference Elemente, die angeben, welche beliebigen, auch binären, Daten in die Signaturberechnung miteinbezogen werden sollen. Die Reference Elemente stellen somit den Kern einer Signatur dar. Mehrere Reference Elemente entsprechen einer Sammelsignatur, also dem Signieren von mehreren Objekten mit einer Signatur. Jedes Element steht dabei für einen signierten Inhalt.

XML-Signaturen signieren niemals direkt die Ressourcen, sondern legen zunächst eine Liste von Hashwerten dieser an. Diese Liste wird dann mit einem Signatur-Algorithmus signiert. Damit wird nicht nur die Signatur-Operation beschleunigt, sondern auch ein einfacher Weg angeboten, um mehrere Ressourcen gleichzeitig zu signieren.

Zum Reference Element gehören drei optionale Attribute: Id, Type und URI. Id vom Typ ID dient der Identifizierung der Referenz. Das Attribut Type vom Typ anyURI bestimmt mit dem als Attributwert angegebenen URI den Typ der Referenz. Das Attribut bezieht sich nicht auf die referenzierten Daten, sondern auf den Container, der die Daten enthält. Damit kann angezeigt werden ob es sich bei der Referenz um ein Object, SignatureProperty oder Manifest Element handelt.

Das dritte Attribut URI ist ebenfalls vom Typ anyURI und enthält die Adresse, unter der die zu signierenden Daten verfügbar sind. Die Daten, auf die sich die digitale Signatur bezieht, müssen nicht im Signature Element selbst vorhanden sein, sondern können auch über das lokale Dateisystem oder eine Internet-Adresse referenziert werden. Enthält das Attribut also eine Webadresse handelt es sich um eine detached signature.

Daneben gibt es noch URIs, die auf das aktuelle Dokument verweisen wie z.B. URI="". Dieser spezielle Uniform Resource Identifier steht für alle XML-Knoten des aktuellen XML-Dokuments, jedoch ohne die möglicherweise vorhandenen Kommentare. Die zur Signatur gehörenden Knoten sind in der Auswahl jedoch enthalten.

Auch das gezielte Auswählen von Teildokumenten (fragment identifier) oder Elementen ist mittels XPointer und XPath möglich. Werden mehrere Reference Elemente angegeben darf das URI Attribut nur bei einem ausgelassen werden. In diesem Fall ist die Applikation dafür zuständig, die zu signierenden Daten zu bestimmen.

Reference besitzt drei Kindelemente: Transforms (optional) sowie die Pflichtelemente DigestMethod und DigestValue.

Transforms

Wird das optionale Element Transforms angegeben, so durchlaufen die referenzierten Daten zunächst der Reihe nach sämtliche in den Transform Kindelementen aufgeführten Transformationen. Der Hashwert wird vom Ergebnis der letzten Transformation berechnet, die Reihenfolge der Transformationen ist also von Bedeutung. In dem Fall wird damit nicht das ursprüngliche, sondern das transformierte Dokument(fragment) signiert. Fehlt das Transforms Element wird der Hashwert vom gesamten referenzierten Objekt berechnet.

Jedes Transforms Element besteht dazu aus einem Algorithm Attribut mit dem anzuwendenden Transformations-Algorithmus.

DigestMethod

Das leere Pflichtelement DigestMethod enthält im Algorithm Attribut ausschließlich einen URI zur Identifikation des Message Digest Algorithmus. Der URI kann die in der folgenden Tabelle aufgeführten Werte annehmen.

DigestValue

Mit dem in DigestMethod angegebenen Algorithmus wird der DigestValue, ein eindeutiger Hashwert des signierten Objekts, berechnet und per Base-64 encoding in diesem Element gespeichert. Der Hashwert, der auch als digitaler Fingerabdruck bezeichnet werden kann, ist meist kürzer als die signierten Daten und kann somit im folgenden Schritt schneller signiert werden. Es ist praktisch unmöglich, aus einem gegebenen Hashwert die ursprüngliche Nachricht zu ermitteln. Außerdem sollte es unmöglich sein, dass zwei beliebige Nachrichten denselben Hashwert ergeben (Kollision und Geburtstagsparadoxon).

Das SignatureValue Element

Das Element SignatureValue enthält in binärer Form (immer Base-64 encoding) den über das gesamte SignedInfo Element berechneten Hashwert der Signatur. Dieser Hashwert wird mit dem in der SignatureMethod angegebenen Algorithmus, den kanonisierten Daten und dem privaten Schlüssel berechnet. Damit wird nicht die Nachricht selbst, sondern deren - in der Regel viel kürzerer - Hashwert unterschrieben (Hash-Then-Sign Paradigma).

In den unterschriebenen Daten sind somit sämtliche Informationen über die signierten Referenzen und deren Hashwerte enthalten. Damit ist es nicht erforderlich, dass die Daten selbst im Dokument vorliegen. Die Angaben über die verwendeten Algorithmen fließen jedoch mit in die Signaturberechnung ein. Dadurch werden nachträgliche Manipulationen verhindert.

Da alle Referenzen vor dem Signieren zusammengefasst und gemeinsam signiert werden existiert für die gesamte Signatur immer genau ein SignatureValue Element.

Das KeyInfo Element

Das optionale und mitunter sehr komplexe KeyInfo enthält Informationen zur Verifizierung einer XML-Signatur in Form eines öffentlichen Schlüssels oder eines X.509-Zertifikats, das wiederum den öffentlichen Schlüssel enthält. Im Gegensatz zur restlichen Empfehlung ist dieses Element weit weniger spezifiziert als alle anderen Elemente. Das Element ist optional da der Empfänger der Nachricht den richtigen Schlüssel zur Verifizierung evtl. auch mit Hilfe der verwendeten Applikation oder über den Anwendungskontext ermitteln kann. Damit kann der Sender auch bestimmen, welcher Empfänger seine Schlüsselinformationen erhalten darf oder nicht.

Das KeyInfo Element wird standardmäßig nicht mit signiert, kann aber leicht über eine zusätzliche Reference ebenfalls mit in die Signatur einbezogen werden.

Jedes KeyInfo Element kann null bis mehrere Kindelemente besitzen, die entweder den verwendeten öffentlichen Schlüssel enthalten oder mit einer Referenz auf diesen verweisen.

Zu den Kindelementen gehören neben einigen anderen KeyName, KeyValue, RetrievalMethod und X509Data. KeyName dient der Benennung des Schlüssels, wobei in diesem Namen auch Leerzeichen von Bedeutung sind. KeyValue enthält einen einzelnen öffentlichen Schlüssel zur Validierung der enthaltenen Signatur. Das Element X509Data beinhaltet in seinen Kindelementen den Schlüsselbezeichner oder ein bis mehrere Zertifikate nach X.509 innerhalb der XML-Struktur. X.509 ist ein weit verbreiteter Standard für den Aufbau und die Kodierung von Zertifikaten und Authentifizierungsdiensten.

Die Schlüsselinformationen spielen eine wichtige Rolle bei der XML Key Management Specification (XKMS) und damit beim Schlüsselmanagement, das im XML Security Plug-In aber nicht behandelt wird. Kurz gesagt hat das Key Management die Aufgabe, Schlüsselbeziehungen zwischen verschiedenen autorisierten Entitäten einzurichten und zu pflegen. XKMS stellt dazu Protokolle bereit, um öffentliche Schlüssel zu verbreiten. Die Key Management Protokolle erfordern ihrerseits einen sicheren Austausch der Schlüsselinformationen zwischen Client und Server. Diese Sicherheit beruht auf XML Encryption und XML Signatures. XKMS deckt damit die Sicherheitsanforderungen Authentifizierung und Vertraulichkeit ab.

Das Object Element

Das letzte Element Object kann Daten beliebigen Typs enthalten, aber auch XML-Dokumente oder Teile davon und beliebig oft vorkommen. Diese Daten gehören zur Signatur, werden aber außerhalb des Elements SignedInfo gespeichert. Binärdaten müssen vor der Verwendung so transformiert werden, dass sie in XML-Dokumenten dargestellt werden können (wiederum Base-64 encoding).

Object besitzt drei optionale Attribute: Id, MimeType und Encoding. Id dient wiederum zur Referenzierung des Object Elements von anderen Stellen innerhalb der digitalen Signatur und ist wiederum vom Typ ID. MimeType vom Typ String bestimmt den Typ der Daten in Object. Dieses Attribut wird beim Erzeugen der digitalen Signatur nicht beachtet, steht aber verarbeitenden Applikationen zur Verfügung. Encoding vom Typ anyURI identifiziert mit dem URI den Kodierungs-Mechanismus zur Verarbeitung der Daten. Derzeit wird nur das Base-64 encoding unterstützt.

Das Element Object kann als Kindelemente die Elemente SignatureProperties und Manifest enthalten.

SignatureProperties enthalten beispielsweise weitere Informationen wie die Signaturzeit oder Informationen über die verwendete Hardware.

Ein Manifest Element enthält ausschließlich eine Sammlung von Referenzen auf Daten in Form einer Liste von Reference Elementen. Im Unterschied zu den normalen Reference Elementen hat bei einem Manifest die zugehörige Applikation die Kontrolle darüber, was passiert, wenn die Validierung einer oder mehrerer Referenzen fehlschlägt. Normalerweise würde in diesem Fall ja die gesamte Signatur ungültig. Um das zu verhindern wird bei einem Manifest nicht der Inhalt der angegebenen Referenzen validiert, sondern die Struktur des Manifests. Die Validierung der Referenzen steht hierbei also vollkommen unter der Kontrolle der Applikation. Manifeste sind ebenfalls interessant wenn sehr viele Signaturen mit unterschiedlichen Schlüsseln über eine große Anzahl von Dokumenten erstellt werden.

Beispiel - Signiert

Die folgenden Beispiele zeigen die drei Signaturvarianten im von oben bekanntem Beispiel XML-Dokument. Zur übersichtlicheren Darstellung wurden alle Beispiele nachträglich formatiert und können daher auch nach einer Kanonisierung nicht mehr erfolgreich verifiziert werden.

Enveloped Signature

<?xml version="1.0" encoding="UTF-8"?>
<Invoice>
 <ID>IN 2008/00645</ID>
 <IssueDate>2008-03-30</IssueDate>
 <BuyerParty>
  <ID>458746</ID>
  <name>John Doe</name>
 </BuyerParty>
 <PaymentMeans>
  <PayeeFinancialAccount>
   <ID>07044961</ID>
   <Name>The Specialists Company</Name>
   <AccountTypeCode>Credit</AccountTypeCode>
   <FinancialInstitutionBranch>
    <ID>776631</ID>
    <Institution>LOYDGB852</Institution>
   </FinancialInstitutionBranch>
  </PayeeFinancialAccount>
 </PaymentMeans>
 <TotalAmount currencyID="€">382.00</TotalAmount>
 <!-- item 1 -->
 <InvoiceLine id="1">
  <Quantity>2</Quantity>
  <LineAmount currencyID="€">205.00</LineAmount>
  <Item id="236WV">
   <BasePrice currencyID="€">102.50</BasePrice>
  </Item>
 </InvoiceLine>
 <!-- item 2 -->
 <InvoiceLine id="2">
  <Quantity>1</Quantity>
  <LineAmount currencyID="€">177.00</LineAmount>
  <Item id="193DX">
   <BasePrice currencyID="€">177.00</BasePrice>
  </Item>
 </InvoiceLine>
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="enveloped-sample">
  <ds:SignedInfo>
   <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/>
   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
   <ds:Reference URI="">
    <ds:Transforms>
     <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <ds:DigestValue>eFlanbs4nTiHuhG6WvG9gkdGVTQ=</ds:DigestValue>
   </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue>hfC4X3wn66WeEsk8/cowxbsQ60JseyNNASjWO8idbR4kSczmTWcCkg==</ds:SignatureValue>
  <ds:KeyInfo>
   <ds:X509Data>
    <ds:X509Certificate>
     MIIC4TCCAp+gAwIBAgIER++fqzALBgcqhkjOOAQDBQAwVDEMMAoGA1UEBhMDZG9zMQwwCgYDVQQI
     EwNkb3MxDDAKBgNVBAcTA2RvczEMMAoGA1UEChMDZG9zMQwwCgYDVQQLEwNkb3MxDDAKBgNVBAMT
     A2RvczAeFw0wODAzMzAxNDExNTVaFw0wOTAzMzAxNDExNTVaMFQxDDAKBgNVBAYTA2RvczEMMAoG
     A1UECBMDZG9zMQwwCgYDVQQHEwNkb3MxDDAKBgNVBAoTA2RvczEMMAoGA1UECxMDZG9zMQwwCgYD
     VQQDEwNkb3MwggG3MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QA
     wx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX
     /rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSML
     zLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP
     5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvM
     pPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhAACgYAis6u62/7EEpM6MiavL8lmfWOm
     tzBYkh9acc5NOlqo77lMlZw4Fzrmyeco14LTcs0zA2A6KZJeZ4/NFdLHOPbxu6Os6KgtHeTCcxr2
     iJpngedSona97jiEv4zjJlGJC7dzi9/gyjB4H9U7yUwe5DkwnHBLXaJDJT3VjwrlSo7G7zALBgcq
     hkjOOAQDBQADLwAwLAIUcmTX6EqCSO3U7QgUq8m3mGhZv4ACFDHCHiqH6wjgV4dnGWj5/tudEVRJ
    </ds:X509Certificate>
   </ds:X509Data>
   <ds:KeyValue>
    <ds:DSAKeyValue>
     <ds:P>
      /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuA
      HTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOu
      K2HXKu/yIgMZndFIAcc=
     </ds:P>
     <ds:Q>l2BQjxUjC8yykrmCouuEC/BYHPU=</ds:Q>
     <ds:G>
      9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3
      zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKL
      Zl6Ae1UlZAFMO/7PSSo=
     </ds:G>
     <ds:Y>
      IrOrutv+xBKTOjImry/JZn1jprcwWJIfWnHOTTpaqO+5TJWcOBc65snnKNeC03LNMwNgOimSXmeP
      zRXSxzj28bujrOioLR3kwnMa9oiaZ4HnUqJ2ve44hL+M4yZRiQu3c4vf4MoweB/VO8lMHuQ5MJxw
      S12iQyU91Y8K5UqOxu8=
     </ds:Y>
    </ds:DSAKeyValue>
   </ds:KeyValue>
  </ds:KeyInfo>
 </ds:Signature>
</Invoice>

Enveloping Signature

<?xml version="1.0" encoding="UTF-8"?>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="enveloping-sample">
 <ds:SignedInfo>
  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
  <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
  <ds:Reference URI="#Invoice">
   <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <ds:DigestValue>6DoxsZRaVy6fYXt5ezkMv81EjPM=</ds:DigestValue>
  </ds:Reference>
 </ds:SignedInfo>
 <ds:SignatureValue>OvQ0ruu0XQxzmT9cWSC1s2z+3FQYlDXARhB5HxWgn4LHg5DMYMH0Ag==</ds:SignatureValue>
 <ds:KeyInfo>
  <ds:X509Data>
   <ds:X509Certificate>
    MIIC4TCCAp+gAwIBAgIER++fqzALBgcqhkjOOAQDBQAwVDEMMAoGA1UEBhMDZG9zMQwwCgYDVQQI
    EwNkb3MxDDAKBgNVBAcTA2RvczEMMAoGA1UEChMDZG9zMQwwCgYDVQQLEwNkb3MxDDAKBgNVBAMT
    A2RvczAeFw0wODAzMzAxNDExNTVaFw0wOTAzMzAxNDExNTVaMFQxDDAKBgNVBAYTA2RvczEMMAoG
    A1UECBMDZG9zMQwwCgYDVQQHEwNkb3MxDDAKBgNVBAoTA2RvczEMMAoGA1UECxMDZG9zMQwwCgYD
    VQQDEwNkb3MwggG3MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QA
    wx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX
    /rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSML
    zLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP
    5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvM
    pPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhAACgYAis6u62/7EEpM6MiavL8lmfWOm
    tzBYkh9acc5NOlqo77lMlZw4Fzrmyeco14LTcs0zA2A6KZJeZ4/NFdLHOPbxu6Os6KgtHeTCcxr2
    iJpngedSona97jiEv4zjJlGJC7dzi9/gyjB4H9U7yUwe5DkwnHBLXaJDJT3VjwrlSo7G7zALBgcq
    hkjOOAQDBQADLwAwLAIUcmTX6EqCSO3U7QgUq8m3mGhZv4ACFDHCHiqH6wjgV4dnGWj5/tudEVRJ
   </ds:X509Certificate>
  </ds:X509Data>
  <ds:KeyValue>
   <ds:DSAKeyValue>
    <ds:P>
     /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuA
     HTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOu
     K2HXKu/yIgMZndFIAcc=
    </ds:P>
    <ds:Q>l2BQjxUjC8yykrmCouuEC/BYHPU=</ds:Q>
    <ds:G>
     9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3
     zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKL
     Zl6Ae1UlZAFMO/7PSSo=
    </ds:G>
    <ds:Y>
     IrOrutv+xBKTOjImry/JZn1jprcwWJIfWnHOTTpaqO+5TJWcOBc65snnKNeC03LNMwNgOimSXmeP
     zRXSxzj28bujrOioLR3kwnMa9oiaZ4HnUqJ2ve44hL+M4yZRiQu3c4vf4MoweB/VO8lMHuQ5MJxw
     S12iQyU91Y8K5UqOxu8=
    </ds:Y>
   </ds:DSAKeyValue>
  </ds:KeyValue>
 </ds:KeyInfo>
 <ds:Object Id="Invoice">
  <Invoice>
   <ID>IN 2008/00645</ID>
   <IssueDate>2008-03-30</IssueDate>
   <BuyerParty>
    <ID>458746</ID>
    <name>John Doe</name>
   </BuyerParty>
   <PaymentMeans>
    <PayeeFinancialAccount>
     <ID>07044961</ID>
     <Name>The Specialists Company</Name>
     <AccountTypeCode>Credit</AccountTypeCode>
     <FinancialInstitutionBranch>
      <ID>776631</ID>
      <Institution>LOYDGB852</Institution>
     </FinancialInstitutionBranch>
    </PayeeFinancialAccount>
   </PaymentMeans>
   <TotalAmount currencyID="€">382.00</TotalAmount>
   <!-- item 1 -->
   <InvoiceLine id="1">
    <Quantity>2</Quantity>
    <LineAmount currencyID="€">205.00</LineAmount>
    <Item id="236WV">
     <BasePrice currencyID="€">102.50</BasePrice>
    </Item>
   </InvoiceLine>
   <!-- item 2 -->
   <InvoiceLine id="2">
    <Quantity>1</Quantity>
    <LineAmount currencyID="€">177.00</LineAmount>
    <Item id="193DX">
     <BasePrice currencyID="€">177.00</BasePrice>
    </Item>
   </InvoiceLine>
  </Invoice>
 </ds:Object>
</ds:Signature>

Detached Signature

<?xml version="1.0" encoding="UTF-8"?>
<root>
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="detached-sample">
  <ds:SignedInfo>
   <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
   <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
   <ds:Reference URI="invoice.xml">
    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <ds:DigestValue>3L2BX8RM8edeO+/fAhHXm6pcWtISDyJYDQxHe+JisXg=</ds:DigestValue>
   </ds:Reference>
  </ds:SignedInfo>
  <ds:SignatureValue>BSv5aeWsbpWB06b51jDuJex1olkfI9EwQNeh9+DmXq4qkas/BYLPJQ==</ds:SignatureValue>
  <ds:KeyInfo>
   <ds:X509Data>
    <ds:X509Certificate>
     MIIC4TCCAp+gAwIBAgIER++fqzALBgcqhkjOOAQDBQAwVDEMMAoGA1UEBhMDZG9zMQwwCgYDVQQI
     EwNkb3MxDDAKBgNVBAcTA2RvczEMMAoGA1UEChMDZG9zMQwwCgYDVQQLEwNkb3MxDDAKBgNVBAMT
     A2RvczAeFw0wODAzMzAxNDExNTVaFw0wOTAzMzAxNDExNTVaMFQxDDAKBgNVBAYTA2RvczEMMAoG
     A1UECBMDZG9zMQwwCgYDVQQHEwNkb3MxDDAKBgNVBAoTA2RvczEMMAoGA1UECxMDZG9zMQwwCgYD
     VQQDEwNkb3MwggG3MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QA
     wx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX
     /rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSML
     zLKSuYKi64QL8Fgc9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP
     5nEHEIGAtEkWcSPoTCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvM
     pPG+qFGQiaiD3+Fa5Z8GkotmXoB7VSVkAUw7/s9JKgOBhAACgYAis6u62/7EEpM6MiavL8lmfWOm
     tzBYkh9acc5NOlqo77lMlZw4Fzrmyeco14LTcs0zA2A6KZJeZ4/NFdLHOPbxu6Os6KgtHeTCcxr2
     iJpngedSona97jiEv4zjJlGJC7dzi9/gyjB4H9U7yUwe5DkwnHBLXaJDJT3VjwrlSo7G7zALBgcq
     hkjOOAQDBQADLwAwLAIUcmTX6EqCSO3U7QgUq8m3mGhZv4ACFDHCHiqH6wjgV4dnGWj5/tudEVRJ
    </ds:X509Certificate>
   </ds:X509Data>
   <ds:KeyValue>
    <ds:DSAKeyValue>
     <ds:P>
      /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9subVWzXgTuA
      HTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYVDwT7g/bTxR7DAjVUE1oWkTL2dfOu
      K2HXKu/yIgMZndFIAcc=
     </ds:P>
     <ds:Q>l2BQjxUjC8yykrmCouuEC/BYHPU=</ds:Q>
     <ds:G>
      9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0HgmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3
      zwkyjMim4TwWeotUfI0o4KOuHiuzpnWRbqN/C/ohNWLx+2J6ASQ7zKTxvqhRkImog9/hWuWfBpKL
      Zl6Ae1UlZAFMO/7PSSo=
     </ds:G>
     <ds:Y>
      IrOrutv+xBKTOjImry/JZn1jprcwWJIfWnHOTTpaqO+5TJWcOBc65snnKNeC03LNMwNgOimSXmeP
      zRXSxzj28bujrOioLR3kwnMa9oiaZ4HnUqJ2ve44hL+M4yZRiQu3c4vf4MoweB/VO8lMHuQ5MJxw
      S12iQyU91Y8K5UqOxu8=
     </ds:Y>
    </ds:DSAKeyValue>
   </ds:KeyValue>
  </ds:KeyInfo>
 </ds:Signature>
</root>

Das Beispiel verschlüsselt (enveloping, detached) oder im Original.

Signierung

Die Erzeugung von digitalen Signaturen (core generation) mit der Extensible Markup Language verläuft in zwei aufeinander folgenden Schritten. Zuerst wird das zu signierende XML-Dokument aufbereitet und für die Signierung vorbereitet (reference generation), anschließend folgt die Generierung der Signatur (signature generation).

Reference Generation (Generierung der Reference-Elemente)

Für jedes zu signierende Datenobjekt werden nach dem Laden der Ressource

1. alle angegebenen Transformationen angewandt,
2. wird aus dem Ergebnis der letzten Transformation für jede kanonisierte Ressource der Hashwert berechnet
3. und zuletzt das Reference Element zusammen mit Angabe der angewandten Transformationen, einer optionalen ID, der DigestMethod und des DigestValue Elements erzeugt.

Signature Generation (Generierung der Signatur)

1. Zunächst wird das SignedInfo Element zusammen mit den Kindelementen SignatureMethod, CanonicalizationMethod und ein bis mehreren Reference Elementen generiert.
2. Die Elemente werden in das Element SignedInfo eingeschlossen und die Kanonisierung dieses Elements durchgeführt. Über diese kanonische Form wird dann der SignatureValue basierend auf den in SignedInfo angegebenen Algorithmen berechnet.
3. Mit diesen Daten wird das vollständige Signature Element erstellt und der Wert der Signatur im Base-64 encoding in SignatureValue abgelegt. Optional können noch weitere Schlüsselinformationen (der öffentliche Schlüssel des Signierenden) mittels des Elements KeyInfo zur Signatur hinzugefügt werden. Der öffentliche Schlüssel wird für eine spätere Verifizierung der Signatur benötigt. Im Falle einer qualifizierten Signatur fordert das Gesetz, dass das Zertifikat mit in die Signaturberechnung eingeht. Daher kann an dieser Stelle auch das gesamte Zertifikat und nicht nur der öffentliche Schlüssel angegeben werden. Mit einer Referenz auf dieses Element wird dieses dann ebenfalls mit in die Signaturberechnung einbezogen.

Mit einem Manifest können mehrere Ressourcen auf ein Mal signiert werden. Hierbei hat auch die Anwendung die Kontrolle über die weiteren Aktionen, wenn z.B. die Verifizierung einer Referenz fehlschlägt. Normalerweise würde bei nur einer ungültigen oder nicht erreichbaren Ressource automatisch die gesamte Signatur ungültig. Mit einem Manifest ist es außerdem möglich, mit mehreren Schlüsseln effizient dieselben Ressourcen zu signieren.

Verifizierung

Bei der Verifizierung einer Signatur (core validation) müssen alle beiden Schritte erfolgreich verlaufen. Zunächst erfolgt die Überprüfung der Ressourcen (reference validation), anschließend die Verifizierung der Signatur (signature validation). Die in den URI Attributen der Reference Elemente angegeben signierten Daten müssen dafür zugänglich sein.

Reference Validation (Verifikation der Reference-Elemente)

1. Zunächst wird die Kanonisierung des SignedInfo Elements mit der angegebenen CanonicalizationMethod durchgeführt.
2. Für jedes Reference Element in SignedInfo werden
1. die signierten Daten ermittelt und die möglicherweise bei der Generierung der Signatur angewandten Transformationen durchgeführt.
2. Von den transformierten Daten wird mit dem in der DigestMethod angegebenen Algorithmus der Hashwert berechnet.
3. Anschließend wird der berechnete Hashwert mit dem im DigestValue übermittelten Hashwert verglichen. Jeglicher Unterschied lässt die gesamte Verifizierung scheitern (auch wenn nur ein Hashwert von vielen eine Abweichung aufweist).

Signature Validation (Verifikation der Signatur)

1. Der öffentliche Schlüssel wird aus dem KeyInfo Element oder einer externen Quelle ermittelt.
2. Das SignedInfo Element wird kanonisiert. Mit den Schlüsselinformationen und dem kanonisierten SignedInfo Element wird der SignatureValue berechnet und mit dem übermittelten Wert verglichen.

Ein möglicherweise durch eine Referenz ebenfalls signiertes KeyInfo Element wird auf die gleiche Art verifiziert.

Ist bei der Verifizierung auch nur eine der angegebenen Referenzen ungültig oder stimmen zwei Werte nicht überein, schreibt die Empfehlung des W3C vor, dass die gesamte Signatur ungültig wird. Die Signatur wird ebenfalls ungültig, wenn ein URI nicht aufgelöst werden kann, die Daten somit nicht erreichbar sind. Alle Schritte der Verifizierung müssen damit für eine gültige Signatur erfolgreich abgeschlossen werden.

Verschlüsselung Grundlagen

Die Verschlüsselung mit XML beschreibt die XML Encryption Syntax and Processing Recommendation des World Wide Web Consortiums vom 10. Dezember 2002. Diese Empfehlung spezifiziert die Syntax zur Repräsentation von beliebigen verschlüsselten Daten (ein XML-Dokument, ein XML-Element oder XML Elementinhalt) in XML-Dokumenten.

Die XML-Verschlüsselung greift teilweise auf Elemente und Konzepte der XML-Digitale Signaturen zurück und schützt die Vertraulichkeit von XML-Dokumenten. Die Vertraulichkeit gewährleistet den Schutz der Informationen vor unbefugter Preisgabe. Nur der rechtmäßige Empfänger kann aus dem Geheimtext wieder den ursprünglichen Klartext gewinnen.

Verschlüsselt werden kann ein einzelnes XML-Element (element), ein XML-Element samt seiner Kindelemente (elements) und auch der Inhalt eines XML-Elements (character data). Außerdem ist natürlich die Verschlüsselung eines vollständigen XML-Dokuments sowie anderer binärer Daten möglich. Ein Spezialfall ist die Mehrfachverschlüsselung bereits verschlüsselter Daten (super-encryption).

Beim Verschlüsseln von Inhalten die kein XML sind werden die zur Entschlüsselung erforderlichen Informationen (z.B. Verschlüsselungsmethode oder Schlüsselinformationen) in XML-Form gespeichert. Die verschlüsselten Daten können dann entweder im Base-64 encoding integriert oder referenziert werden.

Mit der Mehrfachverschlüsselung lassen sich fein abgestufte Zugriffsrechte realisieren. Zu diesem Zweck existiert die Möglichkeit, verschiedene Dokumentteile mit unterschiedlichen Schlüsseln zu verschlüsseln. Ein Empfänger kann damit nur die für ihn relevanten Teile entschlüsseln und lesbar machen. Mehrfach verschlüsselte Daten besitzen die gleiche Syntax und Semantik wie einfach verschlüsselte Daten.

Bei der Verschlüsselung ist eine sehr feine Granularität möglich. Damit erhält man die Möglichkeit, XML-Dokumentfragmente - einzelne Elemente oder nur deren Inhalte - zu verschlüsseln. Sinnvoll ist das beispielsweise bei der Verschlüsselung von Online-Bestellungen, bei denen nur die Kreditkarteninformationen geschützt werden müssen. Die Verschlüsselung von einzelnen Attributen ist, ebenso wie deren Signierung, derzeit nicht möglich. Dieses wurde lange diskutiert, dann aber aus Komplexitätsgründen noch nicht umgesetzt.

Im Gegensatz zu den XML-Signaturen kann die Struktur des verschlüsselten XML-Dokuments verändert (verborgen) werden, je nachdem, welche Dokumentteile verschlüsselt werden. So wird beim Verschlüsseln eines XML-Elements oder XML-Elements mit weiteren Kindelementen dieser Klartext im verschlüsselten XML-Dokument ersetzt. Beim Verschlüsseln beliebiger Daten (auch binär) oder des gesamten XML-Dokuments kann das Element EncryptedData entweder zum neuen Wurzelelement oder zu einem Kindelement werden.

In jedem Fall ist das XML-Dokument weiterhin wohlgeformt, jedoch werden durch die kryptografische Bearbeitung zumindest der Elementinhalt und möglicherweise auch die Dokumentstruktur verändert. Das verschlüsselte XML-Dokument ist daher nicht mehr unbedingt gültig zu seiner ursprünglichen DTD oder Schema Definition. Nach der Entschlüsselung steht selbstverständlich wieder das ursprüngliche Dokument, in seiner ursprünglichen Struktur und mit all seinen Elementen, zur Verfügung.

Syntax

Alle relevanten Daten (die verwendeten Algorithmen) werden, analog zur XML-Signatur, in das XML-Dokument eingebettet. Neben den verschlüsselten Daten sind somit auch die Informationen enthalten, wie der Geheimtext wieder zu entschlüsseln ist.

Das folgende Listing zeigt alle möglichen Elemente einer XML-Verschlüsselung. ? erlaubt das null- bis einmalige, + das mindestens ein- bis mehrmalige und * das null- bis mehrmalige Vorkommen als Attribut oder Element. Elemente mit dem Namespace-Präfix ds stammen von den XML Signaturen. Die vollständige Syntax beschreibt das Schema zur Verschlüsselung mit XML.

<xenc:EncryptedData Id? Type? MimeType? Encoding?>
  <xenc:EncryptionMethod/>?
  <ds:KeyInfo>
    <xenc:EncryptedKey/>?
    <xenc:AgreementMethod/>?
    <ds:KeyName/>?
    <ds:RetrievalMethod/>?
    <ds:*/>?
  </ds:KeyInfo>?
  <xenc:CipherData>
    <xenc:CipherValue/>?
    <xenc:CipherReference URI?/>?
  </xenc:CipherData>
  <xenc:EncryptionProperties/>?
</xenc:EncryptedData>

EncryptedType

EncryptedType ist der abstrakte Typ von dem die Elemente EncryptedData und EncryptedKey abgeleitet werden. Abstrakt bedeutet, dass EncryptedType nicht selbst als Element, sondern ausschließlich zur Ableitung verwendet werden kann. Ein EncryptedType Element wird also niemals in einem gültigen verschlüsselten XML-Dokument auftauchen. Die beiden Elemente EncryptedData und EncryptedKey sind sich jedoch sehr ähnlich, weswegen ein gemeinsamer Supertyp Sinn macht.

EncryptedType besitzt insgesamt vier optionale Attribute: Id, Type, MimeType und Encoding.

Das optionale Attribut Id ist vom Typ ID. Mit diesem Attribut kann die Verschlüsselung identifiziert und referenziert werden, bei mehreren verschlüsselten Daten in einem XML-Dokument ist die Verwendung daher sehr sinnvoll.

Das ebenfalls optionale Attribut Type vom Typ anyURI legt fest, welche Arten von Daten verschlüsselt werden und unterscheidet sich je nach den verschlüsselten Informationen. Wird ein XML-Element mit oder ohne weitere Kindelemente verschlüsselt lautet der Attributwert http://www.w3.org/2001/04/xmlenc#Element. Beim Verschlüsseln des Inhalts eines Elements oder mehrerer XML-Elemente nimmt das Attribut den Wert http://www.w3.org/2001/04/xmlenc#Content an. Auch wenn das Attribut optional ist wird die Verwendung sehr empfohlen. Eine automatische Entschlüsselung und Wiederherstellung von Elementen oder Elementinhalt ist ohne dieses Attribut nicht möglich.

Werden binäre Daten (arbitrary data) oder ganze XML-Dokumente verschlüsselt kennzeichnet das optionale Attribut MimeType vom Typ String den MIME-Typ der Daten. Der von der IETF in verschiedenen RFCs spezifizierte MIME-Typ (Multipurpose Internet Mail Extensions) sollte ursprünglich den Typ von Email-Anhängen angeben, wurde dann aber auch für HTTP, und daher auch für die XML Encryption, verwendet. Für XML-Dokumente hat das Attribut beispielsweise den Wert text/xml.

Das letzte ebenfalls optionale Attribut Encoding vom Typ anyURI identifiziert über den angegebenen URI den Kodierungs-Mechanismus zur Verarbeitung der Daten (meist Base-64 encoding).

EncryptedType besitzt die vier Kindelemente EncryptionMethod (optional), KeyInfo (optional), CipherData (pflicht) und EncryptionProperties (optional).

Das EncryptedData Element

Das EncryptedData Element ist das Wurzelelement bei der Verschlüsselung mit XML. Daten, die verschlüsselt werden, werden durch ihre Verschlüsselung in dem Element EncryptedData an der gleichen Stelle ersetzt. Das Element EncryptedData kann dabei das neue Wurzelelement eines XML-Dokuments werden (beim Verschlüsseln von beliebigen Daten oder des vollständigen XML-Dokuments) oder in ein bestehendes XML-Dokument integriert werden (beim Verschlüsseln eines XML-Elements oder eines XML-Elements mit weiteren Kindelementen).

EncryptedData wird vom abstrakten Typ EncryptedType abgeleitet und kann damit alle dort definierten Kindelemente und Attribute besitzen. Zusätzlich besitzt es noch das Attribut xmlns mit dem derzeitig einzig gültigen Wert xmlns:xenc="http://www.w3.org/2001/04/xmlenc#". Wie bei den digitalen Signaturen identifiziert der Namensraum nebenbei noch die verwendete Version der Empfehlung. Zukünftige Versionen werden daher auch hier einen anderen Namensraum besitzen.

Ein XML-Dokument kann beliebig viele EncryptedData Elemente und damit beliebig viele unterschiedliche Verschlüsselungen enthalten. Jedes dieser Elemente repräsentiert die verschlüsselte Form eines bzw. mehrerer Elemente oder eines Elementinhalts und kann mit verschiedenen Schlüsseln chiffriert werden.

EncryptedData darf jedoch nicht Eltern- oder Kindelement von einem anderen EncryptedData Element sein. Die tatsächlichen verschlüsselten Daten können aber auch die Elemente EncryptedData oder EncryptedKey enthalten (z.B. bei der Mehrfachverschlüsselung).

Das EncryptionMethod Element

Das optionale Element EncryptionMethod bestimmt mit dem Attribut Algorithm den verwendeten Verschlüsselungsalgorithmus und mögliche zugehörige Parameter. Fehlt dieses Element muss dem Empfänger oder der verarbeitenden Applikation der zur Verschlüsselung verwendete Algorithmus bekannt sein.

Zwei der möglichen Kindelemente sind KeySize und OAEPparams die den verwendeten Algorithmus durch Angabe der Schlüssellänge und weiterer Parameter näher beschreiben. Welche Kindelemente jeweils erlaubt bzw. erforderlich sind hängt vom gewählten Algorithmus ab der über das Algorithm Attribut bestimmt wird.

Das Algorithm Attribut der EncryptionMethod kann u.a. die in der folgenden Tabelle aufgeführten URIs annehmen.

Zum Kodieren von geheimen Schlüsseln dienen die symmetrischen Algorithmen mit dem Zusatz Key Wrap in der folgenden Tabelle. EncryptionMethod muss dazu ein Kindelement von EncryptedKey sein.

Die RSA Algorithmen RSA-v1.5 und RSA-OAEP sind asymmetrische Algorithmen zum sicheren Schlüsseltransport. Diese Algorithmen können nur verwendet werden, wenn EncryptionMethod ein Kindelement von EncryptedKey ist.

Prinzipiell können beliebige weitere Algorithmen verwendet werden. Dies ist von der konkreten Implementierung abhängig. Die Empfehlung des W3C lässt dabei offen, ob symmetrische oder asymmetrische Algorithmen verwendet werden.

Das KeyInfo Element

Das Element KeyInfo stammt von den XML-Digitalen Signaturen und weist dieselben Eigenschaften auf. Das Element befindet sich auch bei der XML-Verschlüsselung im Namensraum der digitalen Signaturen und benötigt daher ein eigenes xmlns Attribut zur Deklaration des Namensraumes der digitalen Signaturen (xmlns:ds="http://www.w3.org/2000/09/xmldsig#"). KeyInfo stellt bei der XML-Verschlüsselung Informationen über den zur Entschlüsselung von Daten oder Schlüsseln benötigten Schlüssel bereit.

Zusätzlich enthält KeyInfo bei der Verschlüsselung die beiden optionalen Kindelemente EncryptedKey und AgreementMethod.

EncryptedKey

Mit dem Element EncryptedKey wird der verwendete Schlüssel (content encryption key) innerhalb von KeyInfo mit einem Public-Key-Verfahren verschlüsselt vom Sender zum Empfänger übertragen. Verschlüsselt wird dieses Element dabei von einem Verschlüsselungsalgorithmus zum sicheren Schlüsselaustausch wie Diffie-Hellman oder einem anderen Key Wrap Algorithmus. Das Element ist optional und kann mehrfach vorkommen.

EncryptedKey wird ebenfalls vom abstrakten Typ EncryptedType abgeleitet und besitzt damit alle dort definierten Elemente und Attribute. Zusätzlich enthält das Element ein optionales Attribut Recipient, mit dem der Anwendung ein Hinweis auf den Empfänger gegeben werden kann.

EncryptedKey besitzt außerdem die beiden optionalen Kindelemente ReferenceList und CarriedKeyName. Diese beiden Kindelemente können ein optionales Element Transforms enthalten, mit dessen Hilfe vor der Verschlüsselung die bereits erwähnten Transformationen durchgeführt werden können.

ReferenceList verfügt über ein oder mehrere Kindelemente DataReference und KeyReference. Diese Elemente verweisen über einen URI auf verschlüsselte Daten bzw. Schlüssel, die mit Hilfe des angegebenen Schlüssels chiffriert worden sind.

Das Element CarriedKeyName dient der Identifizierung und Referenzierung des chiffrierten Schlüsselwerts mit einem eindeutigen Schlüsselnamen.

AgreementMethod

AgreementMethod enthält weitere Informationen zum verwendeten Schlüssel und ein Algorithm Attribut zur Bestimmung des verwendeten Algorithmus zum Schlüsselaustausch (key agreement algorithm). Mögliche Algorithmen sind Diffie-Hellman, die SHA Varianten und RIPEMD-160.

Das CipherData Element

Das Pflichtelement CipherData enthält die eigentlichen verschlüsselten Daten. Die verschlüsselten Daten können dabei entweder eingehüllt oder referenziert werden.

Bei eingehüllten Daten (enveloping encryption) werden die verschlüsselten Daten im Base-64 encoding im Kindelement CipherValue direkt im XML-Dokument angezeigt.

Enveloping Encryption

Das Element hat bei einer eingehüllten Verschlüsselung den folgenden Aufbau:

<CipherData>
  <CipherValue>
  </CipherValue>
</CipherData>

Werden die Daten referenziert (detached encryption) wird durch das Element CipherReference und einem URI Attribut auf die externen verschlüsselten Daten verwiesen.

Detached Encryption

Das Element hat bei einer referenzierten Verschlüsselung den folgenden Aufbau:

<CipherData>
  <CipherReference URI/>
</CipherData>

Transforms

Das optionale Kindelement Transforms erlaubt bei einer detached encryption, wie bei der digitalen Signatur, vor der Verschlüsselung verschiedene Transformationen der referenzierten Daten in einer bestimmten Reihenfolge durchzuführen.

Das EncryptionProperties Element

Mit dem optionalen EncryptionProperties Element können zusätzliche Informationen angegeben werden, die von der entschlüsselnden Anwendung interpretiert werden sollen und nicht Teil der offiziellen W3C-Empfehlung darstellen. Diese Parameter können ergänzende Informationen zur Verschlüsselung, wie beispielsweise einen Zeitstempel oder auch zusätzliche Informationen über die verschlüsselten Daten oder den verschlüsselten Schlüssel, enthalten.

EncryptionProperty

Das EncryptionProperties Element enthält dazu mindestens ein Kindelement EncryptionProperty in dem die zusätzlichen Parameter definiert werden können.

Beispiel - Verschlüsselt

Die folgenden Beispiele zeigen die zwei Verschlüsselungsvarianten im von oben bekanntem Beispiel XML-Dokument. Zur übersichtlicheren Darstellung wurden alle Beispiele nachträglich formatiert.

Enveloping Encryption

<?xml version="1.0" encoding="UTF-8"?>
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
 Id="enveloping-sample" Type="http://www.w3.org/2001/04/xmlenc#Element">
 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
   <xenc:CipherData>
    <xenc:CipherValue>rojIk5KAKQLdxwsvNzKL1slqdrAbvhQa</xenc:CipherValue>
   </xenc:CipherData>
  </xenc:EncryptedKey>
 </ds:KeyInfo>
 <xenc:CipherData>
  <xenc:CipherValue>
   IxZg5/ybM3tKnRK7krng3YE+GmosiCY7u1ZJB3s7LoTDf4KvGnSTh+CUQ50g5lz2SnRFgUj4PpxG
   4EBX6MOPWG7Idx+JlzOx0+PCnVLU7JNIYi8MXGKtmj3yxtFr6Lx9kT6lPPqoorhWm/jaQqsdRhMc
   XbLQLRMfY2ZqckcLpd7w55K8iMu5P8w1l4RRV4tw0XLI3TDj++204NFiBzyd5joVyDfCibuP+UXs
   ArtPsGVGoF5zIy/1d9dW96hTpiLIeU82mYCLF3d+2dLAGi0Gd4Awp3eoYKPti9l60r3NqMfZIW+s
   5oDzUc3b7DrtXUYEp4oxb5CXdWuVdnStFG03uBOgMqk189EZaBUZWpx0wabxAs3yHQktFIKsIHKk
   a4MOK9dHCiqc7ja/CHDUKAhCyrg+H5xE5E60+p0JYnWUovax+wa/x+QnbjYH9JyV9+41H7wpb3pA
   0ONHyrciJbQtZJKLvkMGOv7Q1Qx1TjM4PPiUqs71KyizqJ40Y8yG4bBlUD/2T+eyCXN1iLHZwInQ
   SUqceU094kAtQA5IErwUh/yZlVFw90H5gVeyhddQhXb2ggQ4ENyLSWY/tgdsE0qPz7Z2bU06wmOs
   Tj1cQUCQIiCuoGu9DqF16uExNtZ/QPwHTeFiUmCwOLi7blPPlFzz2P2r9GjJFVTrNSAODLUE7wRE
   j+qLyIO8sUBHrl6BeDwBcGdHtmuLeTh4uSrCORib8l65Djr+pmCo0/LPHwBhH4s2o1tU1Kcvde4Q
   Fpt3jtBsAxARueRSBqg0PqR8GDerBu6tS8FvsGDz1D4IwwY/Xq3SD0ew4XLQc2vcSMKN5hRSuYDm
   5jEPNpy0JEXYn94OarnnfMfvHEATFi9nX/egmc8kmLXFMB5B6R9GD6SCuNcnyqvX+VM+v98yy3mb
   ub2XOeshOnhqox3DA5r/7LXLv6BOYWWqpNjFJEOoPizOow4NQLzd5SpbHY7FJhuDkMkYrWLJGg3B
   x/JMueEGmYOPuutVTh9m9L8bbWFflE+/etTs+ZYvl9rt4rcXJxK6Dk06hUMgzEpFNjFHCY84bbYp
   Zkk/31x6BxhJgmAPR+E5e0cZUuqzG2Q2FNgAMt+OpOUHtWi8EPp8Am2GMlUOs3hJH/+4g9gz6WiI
   ZZFT3e35OGyadFEQNiobzBCTbp9ymu7U+A9WAohXFg0jlRGWVUPFHByjw7QKqyGJIlSPJSyfeG1j
   U+Gcbrb9Zy4Jv/cwgYVx9zJNbnlURbtVBt5+996YTtcIOcVRKNuxozUI8H8Q8KO7
  </xenc:CipherValue>
 </xenc:CipherData>
</xenc:EncryptedData>

Detached Encryption

<?xml version="1.0" encoding="UTF-8"?>
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
 Id="detached-sample" Type="http://www.w3.org/2001/04/xmlenc#Element">
 <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
 <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>
   <xenc:CipherData>
    <xenc:CipherValue>8PSWTVBjn4m5Q0fDV2Q4c6FZ2BigxoCi</xenc:CipherValue>
   </xenc:CipherData>
  </xenc:EncryptedKey>
 </ds:KeyInfo>
 <xenc:CipherData>
  <xenc:CipherReference URI="invoice.xml"/>
 </xenc:CipherData>
</xenc:EncryptedData>

Das Beispiel signiert (enveloped, enveloping, detached) oder im Original.

Verschlüsselung

Für jede zu verschlüsselnde Ressource (EncryptedData oder EncryptedKey)

1. werden der Algorithmus und falls notwendig die Parameter bestimmt,
2. der Schlüssel ermittelt und optional abgebildet
1. falls der Schlüssel identifiziert werden soll (über den Namen, URI oder in einem Kindelement) muss das KeyInfo Element generiert werden
2. falls der Schlüssel selbst verschlüsselt werden soll muss das EncryptedKey Element generiert werden. Dieses Element kann entweder als Kindelement an KeyInfo oder anderswo eingefügt werden
3. die Daten verschlüsselt
1. falls die zu verschlüsselnden Daten vom Typ element oder content sind werden die Daten UTF-8 kodiert abgelegt,
2. falls die Daten nicht vom Typ octect sind müssen diese als Oktette serialisiert werden,
3. anschließend werden die Daten mit dem Algorithmus und dem Schlüssel aus den Schritten 1 und 2 verschlüsselt
4. und der Typ der verschlüsselten Daten hinzugefügt
4. die EncryptedType (EncryptedData oder EncryptedKey) Struktur erstellt
1. falls die verschlüsselten Daten innerhalb von CipherData angezeigt werden sollen wird ein CipherValue Element mit den Base-64 kodierten Daten eingefügt
2. falls die verschlüsselten Daten außerhalb von CipherData angezeigt werden sollen werden ein oder mehrere CipherReference Elemente mit den URIs eingefügt
5. und zum Abschluss EncryptedData verarbeitet
1. falls der Typ der verschlüsselten Daten element oder content ist kann der Applikation das vollständige EncryptedData Element zurückgegeben und der ursprüngliche Klartext durch den Geheimtext ersetzt werden
2. falls der Typ der verschlüsselten Daten nicht element oder content sind muss der Applikation das vollständige EncryptedData Element zurückgegeben und der ursprüngliche Klartext durch den Geheimtext ersetzt werden.

Entschlüsselung

Für jeden zu entschlüsselnden EncryptedType (EncryptedData oder EncryptedKey) müssen

1. das Element verarbeitet und der Algorithmus mit allen Parametern sowie das KeyInfo Element festgelegt werden (falls eine oder mehrere dieser Informationen nicht vorhanden sind müssen diese durch die Applikation festgelegt werden),
2. der data encryption key samt möglicher Kindelemente lokalisiert werden. Falls dieser ebenfalls verschlüsselt ist muss dieser zunächst mit dem zugehörigen Schlüssel entschlüsselt werden.
3. Anschließend werden die verschlüsselten Daten innerhalb von CipherData entschlüsselt;
1. falls diese in einem CipherValue Element vorliegen wird der Text abgerufen und Base-64 dekodiert um die verschlüsselte octect Sequenz zu erhalten
2. falls diese in einem CipherReference Element vorliegen wird die URI und mögliche Transformationen angewandt um die verschlüsselte octect Sequenz zu erhalten
3. und anschließend die erhaltene octect Sequenz mit dem angegebenen Algorithmus, dessen Parametern und dem Schlüssel aus den Schritten 1 und 2 entschlüsselt.
4. Anschließend werden die entschlüsselten Daten vom Typ element oder content
1. als UTF-8 kodierte Daten interpretiert
2. und als UTF-8 kodierte XML-Daten an die Applikation zurückgegeben.
3. Abschließend wird der Geheimtext im XML-Dokument durch den Klartext ersetzt. Falls das Zieldokument dabei nicht als UTF-8 kodiertes XML-Dokument vorliegt werden die entschlüsselten Daten zunächst in das Encoding des Zieldokuments transformiert.
5. Falls die entschlüsselten Daten nicht vom Typ element oder content sind
1. wird der ermittelte Klartext mit den Attributen Type, MimeType und Encoding an die Applikation zur weiteren Verarbeitung zurückgegeben.

Lizenz

Die XML Security Tools und auch das XML-Security Plug-in stehen unter der Eclipse Public License Version 1.0. Diese ist verfügbar unter http://www.eclipse.org/legal/epl-v10.html.

Die für die XML Security Tools notwendige Apache XML Security API (Santuario) im Plug-in org.apache.xml.security, Apache Commons Logging im Plug-in org.apache.commons.logging, Apache Xalan im Plug-in org.apache.xalan sowie Apache Xerces im Plug-in org.apache.xerces stehen unter der Apache Software License Version 2.0. Diese ist einsehbar unter http://www.apache.org/licenses/LICENSE-2.0.html.

Glossar