XML Security Guide

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.

XML Security Tools

Die XML Security Tools bestehen aus den fünf Komponenten Canonicalization, XML Signature Wizard, XML Signatures View, XML Encryption Wizard und XML Decryption Wizard. Der Fokus liegt stets auf der zu sichernden Ressource, Ausgangspunkt ist also immer ein beliebiges XML-Dokument im XML-Editor der Eclipse Web Tools Platform (empfohlen) oder verschiedenen Views.

Die Wizards erfordern immer zunächst ein zu sicherndes XML-Dokument bevor die Details der Signatur, Verschlüsselung oder Entschlüsselung festgelegt werden können.

Ganz im Sinne einer Lernsoftware ist es das Ziel der XML Security Tools, Ihnen die größtmöglichen Freiheiten zu lassen und das Experimentieren mit der XML-Sicherheit zu fördern. Das bedeutet, dass Sie in den Wizards so viele Einstellungen wie möglich selbst vornehmen müssen und Ihnen so wenige Einschränkungen wie möglich durch das Plug-in gemacht werden. Teilweise hat das zur Folge, dass in den Wizards viele Angaben getätigt werden müssen, bevor das XML-Dokument gesichert werden kann. Auf diese Art können Sie aber am besten die umfangreichen Eigenschaften und Möglichkeiten der XML-Sicherheit kennen lernen.

Die Grundlagen der Kryptografie, also digitale Signaturen und Verschlüsselung, sind nicht Bestandteil der XML Security Tools. Kenntnisse in diesem Bereich sind aber natürlich von Vorteil. Ein hervorragendes und sehr empfehlenswertes Tool hierfür ist das frei erhältliche CrypTool oder dessen Nachfolger JCrypTool.

Zum schnellen Signieren, Verifizieren sowie Ver- und Entschlüsseln stehen die so genannten Quick Functions zur Verfügung. Die dabei verwendeten Einstellungen werden vorab in den Preferences festgelegt, wodurch das Sichern des XML-Dokuments (fast) mit einem Klick erfolgen kann. Zur einfacheren Unterscheidung besitzen die Quick Functions keine Icons im Kontextmenü.

Alle Wizards und Befehle der XML Security Tools lassen sich über das übersichtliche Kontextmenü an verschiedenen Stellen aufrufen:

Zum einen können Sie im Navigator, Package Explorer oder Project Explorer genau ein XML-Dokument markieren. Zum anderen lassen sich sämtliche Funktionen bei einem geöffneten XML-Dokument auch über das Kontextmenü im Eclipse XML-Editor der Web Tools Platform erreichen. Die Funktionen des Plug-ins sind immer mit der rechten Maustaste über das Untermenü XML Security erreichbar.

Kontextmenü

Das XML Security Menü im XML-Editor ist immer vorhanden. In den erwähnten Views ist der Eintrag jedoch nur sichtbar wenn Sie sich in der XML Perspective befinden.

Das Kontextmenü ist stets dasselbe, jedoch kann bei einem Aufruf über die Views in den Signature und Encryption Wizards nicht die Option Selection ausgewählt werden. Auch bei der Quick Signature und Quick Encryption ist das Sichern einer Textmarkierung nicht möglich.

Um eine Textauswahl zu signieren oder zu verschlüsseln muss die Textmarkierung bereits vor dem Aufruf des Wizards im Editor vorhanden sein. Ihre Textauswahl darf die Regeln der Wohlgeformtheit nicht verletzen! Das heißt, dass beim Sichern (Signieren/ Verschlüsseln) eines Elements sowohl das öffnende als auch das schließende Tag mit in die Auswahl einbezogen werden müssen. Der Inhalt eines Elements kann beliebig signiert oder verschlüsselt werden. Das Signieren oder Verschlüsseln von einzelnen Attributen ist nicht möglich. Würde das Signieren oder Verschlüsseln Ihrer Textauswahl die Wohlgeformtheit verletzen, können Sie im jeweiligen Wizard den Eintrag Selection nicht auswählen. Verlassen Sie in diesem Fall den Wizard wieder und korrigieren Sie die Textauswahl oder sichern Sie das ganze Dokument bzw. ein durch einen XPath Ausdruck spezifiziertes Dokumentfragment.

Beim Aufruf eines Wizards über das Kontextmenü des XML-Editors steht die Rückgängig-Funktion von Eclipse zur Verfügung. Alle durch das Plug-in vorgenommenen Änderungen können so mit dieser Funktion rückgängig gemacht werden. Beim Aufruf eines Wizards über eine View werden die Änderungen dagegen direkt in das XML-Dokument geschrieben und können nicht rückgängig gemacht werden. Ist das XML-Dokument aber gleichzeitig im XML-Editor geöffnet können dort auch die Änderungen einer View rückgängig gemacht werden. Bitte beachten Sie daher, dass die Rückgängig-Funktion auch ein entsprechendes Sicherheitsrisiko darstellen kann (der Klartext kann einfach wiederhergestellt werden).

Cheat Sheets

Die Cheat Sheets sind deutsch- bzw. englischsprachige Tutorials (die angezeigte Sprache hängt von den Ländereinstellungen des Betriebssystems ab) speziell für Anfänger und sollen Ihnen den Einstieg in die XML Security Tools und die XML-Sicherheit erleichtern. Mit den fünf verfügbaren Anleitungen werden Sie Schritt für Schritt durch die Generierung einer Signatur, die Verifizierung sowie Ver- und Entschlüsselung und die Verwendung der Quick Functions geführt.

Anzeigen können Sie die Cheat Sheets über den Menüpunkt Cheat Sheets... im Menü Help. Im sich öffnenden Fenster finden Sie eine Rubrik XML Security mit den fünf enthaltenen Cheat Sheets. Nach der Auswahl eines Tutorials und dem Klick auf OK wird die gewünschte Anleitung angezeigt und Sie können diese schrittweise durcharbeiten. Über die Hilfe-Icons neben jedem Eintrag gelangen Sie zu weiterführenden Informationen in der Online-Hilfe.

Einige Abschnitte besitzen Icons zum Starten einer Aktion. Beispielsweise können Sie sich in den Signatur- und Verschlüsselungs-Cheat Sheets ein Projekt und ein XML-Dokument zum Ausprobieren generieren lassen. Außerdem können Sie direkt von aus dem Quick Functions Cheat Sheet in die Preferences Ihres Workspace wechseln.

Selbstverständlich können Sie einzelne Schritte überspringen sofern Sie die darin enthaltenen Aktionen bereits durchgeführt haben (wenn Sie z.B. bereits ein XML-Dokument zum Sichern erstellt haben).

Preferences

In den Benutzereinstellungen können auf der Hauptseite XML Security (zu finden in der Kategorie XML) und den Unterseiten Signature sowie Encryption verschiedene Optionen für die XML Security Tools eingestellt werden. Die Einstellungen auf den Unterseiten betreffen ausschließlich die Quick Functions des Plug-ins. Diese Angaben müssen vollständig ausgefüllt sein, bevor die Einträge zum schnellen Signieren, Verifizieren oder Ver- und Entschlüsseln verwenden können. Fehlen Angaben beim Aufruf einer Quick Function können diese über den angezeigten Link auf der jeweiligen Preference Seite eingegeben werden.

Auf der Hauptseite XML Security können Sie zunächst festlegen, was beim Aufruf der Canonicalization über das Kontextmenü passieren soll. Beim Canonicalization Type können Sie zwischen der inklusiven und der exklusiven Variante auswählen. Mit dem Canonicalization Target können Sie bestimmen, wie ein über das Kontextmenü kanonisiertes XML-Dokument angezeigt werden soll. Mit Same Document wird das angezeigte XML-Dokument selbst kanonisiert, mit New Document öffnet sich ein neues Editorfenster in dem das kanonisierte XML-Dokument angezeigt wird. Das Ursprungsdokument wird dabei nicht verändert. So lassen sich die Unterschiede leichter vergleichen.

Allgemeine XML Security Tools Einstellungen und zur Kanonisierung

Alle weiteren Einstellungen auf den Unterseiten Signature und Encryption betreffen die Quick Functions. Sie müssen hier sämtliche Informationen angeben die Sie normalerweise über den entsprechenden Assistenten angeben würden. Lediglich sicherheitsrelevante Daten wie Passwörter werden nicht gespeichert und müssen direkt beim Aufruf der Quick Functions angegeben werden (ein Popup-Dialog fordert Sie zur Eingabe auf).

Signature Preferences

Die Einstellungen auf der Unterseite Signatures beeinflussen sowohl den Befehl Quick Signature als auch Quick Verification. Wie im Wizard müssen Sie zunächst auswählen welche Ressource Sie signieren möchten und welchen Signaturtyp Sie verwenden wollen (nur enveloping und enveloped stehen zur Verfügung). Anschließend müssen Sie noch die zu verwendenden Algorithmen und einen Java Keystore mit dem Schlüssel auswählen sowie den Aliasnamen dieses Schlüssels angeben. Die Signature ID schließlich entspricht auch der ID nach der bei der Quick Verification gesucht wird. Auf fehlende Angaben werden Sie beim Aufruf von Quick Signature bzw. Quick Verification hingewiesen und können diese Angaben dann entweder nachholen oder die Operation abbrechen.

Einstellungen für die Quick Signature und Quick Verification

Encryption Preferences

Unter Encryption finden Sie alle Einstellungen, die für die Befehle Quick Encryption und Quick Decryption notwendig sind. Dies betrifft die Auswahl der zu verschlüsselnden Ressource, des Verschlüsselungstyps und die gewünschten Algorithmen. Außerdem müssen Sie noch den Schlüsselspeicher und den Aliasnamen des Schlüssels angeben. Auch hier bestimmt die Encryption ID die Verschlüsselung, nach der bei der Entschlüsselung gesucht wird. Auf fehlende Angaben werden Sie beim Aufruf von Quick Encryption bzw. Quick Decryption hingewiesen und können diese dann entweder angeben oder die Operation abbrechen.

Einstellungen für die Quick Encryption und Quick Decryption

Quick Functions

Mit den Quick Functions können Sie schnell ein XML-Dokument(-fragment) signieren, verifizieren sowie ver- und wieder entschlüsseln. Um diese Funktionen nutzen zu können sind daher einige Einstellungen in den Preferences erforderlich. Anschließend ersparen Ihnen diese Befehle das umfangreiche Ausfüllen des jeweiligen Wizards. Abgefragt werden nur noch die sicherheitskritischen Angaben wie Passwörter (ein Popup-Dialog fordert Sie zur Eingabe auf). Alle weiteren Informationen werden in den Workspace Einstellungen gespeichert. Fehlen eine oder mehrere Einstellungen in den Preferences werden Sie beim Aufruf einer Quick Function entsprechend darüber informiert und können direkt in die Preferences wechseln oder die Operation abbrechen.

Passwörter werden grundsätzlich verschlüsselt in den Eingabefeldern angezeigt. Sollten Sie sich bei der Eingabe vertippen erhalten Sie eine entsprechende Fehlermeldung.

Bitte beachten Sie, dass Sie eine Textauswahl nur Signieren oder Verschlüsseln können, sofern Sie die Quick Function in einem Editor mit einem XML-Dokument aufrufen. Über eine View wie den Navigator oder Package Explorer ist das Sichern einer Textauswahl nicht möglich.

Quick Signature ermöglicht das schnelle Signieren eines XML-Dokuments oder eines Dokumentfragments. Sie werden dabei nur nach dem Keystore Password und dem Key Password gefragt. Sollte eines davon nicht korrekt sein erhalten Sie eine entsprechende Fehlermeldung und das XML-Dokument kann nicht signiert werden.

Quick Verification zeigt Ihnen in einem kleinen Dialogfeld an, ob die Signatur mit der angegebenen ID gültig (valid) oder ungültig (invalid) ist. Sollte keine Signatur mit der gespeicherten ID im XML-Dokument vorhanden sein erhalten Sie eine entsprechende Fehlermeldung.

Quick Encryption verschlüsselt ein XML-Dokument oder Teile davon mit einem Klick. Sie werden dabei nur nach dem Keystore Password und dem Key Password gefragt. Sollte eines davon nicht korrekt sein erhalten Sie eine entsprechende Fehlermeldung und das XML-Dokument kann nicht verschlüsselt werden.

Quick Decryption entschlüsselt ein XML-Dokument Sie werden dabei nur nach dem Keystore Password und dem Key Password gefragt. Sollte eines davon nicht korrekt sein erhalten Sie eine entsprechende Fehlermeldung und das XML-Dokument kann nicht entschlüsselt werden.

XML Signature Wizard

Mit dem XML Signature Wizard können Sie assistentengestützt eine Signatur für das von Ihnen gewählte XML-Dokument erstellen. Der XML Signature Wizard stellt einen den umfangreichsten Assistenten im Plug-in dar und ermöglicht viele unterschiedliche Kombinationen und Anwendungsmöglichkeiten. Bei der Signatur handelt es sich um eine Mischung aus einfacher und fortgeschrittener Signatur. Trotz einer erfolgreich verifizierten Signatur (d.h. einem erfolgreich verifizierten Hashwert) muss der Signierende aber nicht der sein, der er vorgibt zu sein (Sie können beim Generieren des Schlüssels jeden beliebigen Namen angeben). Um die Benutzerauthentizität zu garantieren wäre beispielsweise ein Key Management in der Art von XKMS notwendig. Dafür ist es mit den XML Security Tools sehr einfach, einen eigenen Schlüssel auf dem eigenen System zu generieren und diesen in verschiedenen Signaturen zu verwenden.

Der XML Signature Wizard besteht aus drei Seiten, die der Reihe nach von Ihnen ausgefüllt werden müssen. Die zweite Seite hängt dabei von der gewählten Schlüssel-Option ab und unterscheidet sich dadurch. Nur nachdem Sie alle Pflichtfelder einer Seite korrekt ausgefüllt haben können Sie auf die nächste Seite wechseln. Zu Ihrer Unterstützung stellt der Assistent Kurzhinweise im oberen Bereich zur Verfügung. Der XML Signature Wizard kann nur auf der letzten Seite erfolgreich beendet werden. Nach dem Klick auf den Finish Button wird anschließend die Signatur generiert.

Der XML Signature Wizard wird über den Eintrag New Signature... im Kontextmenü aufgerufen. Er besteht aus den Seiten Resource and Signature Type, Keystore and Key und Algorithms and Signature Properties. Über das Hilfe-Icon links unten auf jeder Wizard Seite erhalten Sie eine kontextabhängige Kurzhilfe und können weitergehende Informationen zum Wizard abrufen.

Resource and Signature Type

Auf der ersten Seite des XML Signature Wizard müssen Sie die zu signierende Ressource und die Signatur-Variante auswählen. Außerdem können Sie bestimmen, ob Sie ein vorhandenes Zertifikat verwenden oder im Assistenten ein neues generieren möchten. Mit der Auswahl von Generate a Basic Security Profile compliant signature werden die Auswahlmöglichkeiten im gesamten Assistenten im Hinblick auf die Basic Security Profile Empfehlung eingeschränkt.

Resource and Signature Type

Die erste Auswahlmöglichkeit im Assistent betrifft die Wahl der zu signierenden Ressource. Der Eintrag Document ist immer verfügbar und signiert das vollständige Dokument. Selection ist nur möglich wenn Sie im Editor mindestens ein Element bzw. Elementinhalt vor dem Aufruf des Assistenten markiert haben und der Assistent über das Kontextmenü eines Editors aufgerufen wurde. Die Auswahl muss wohlgeformt sein, d.h. sowohl das öffnende als auch das schließende Tag müssen in der Auswahl vorhanden sein. Werden die Regeln der Wohlgeformtheit verletzt kann Selection nicht aktiviert werden.

Bei der Auswahl von XPath können Sie im Textfeld einen XPath-Ausdruck eingeben. Alternativ können Sie über den Button Browse... einen weiteren Dialog zur Auswahl eines XPath Ausdrucks für das aktuelle XML-Dokument öffnen.

XPath Selection

Damit die XPath-Ausdrücke zu jedem Element angezeigt werden können muss es sich um ein wohlgeformtes XML-Dokument handeln. Insbesondere bei der Verwendung von Namensräumen muss der Namensraum auch definiert werden, d.h. ein xmlns:MeinNamensraum="http://www.namensraum.de" muss bei der Verwendung von MeinNamensraum unbedingt vorhanden sein.

Anschließend müssen Sie die Signatur-Variante bestimmen. Zur Auswahl stehen Enveloped, Enveloping und Detached Signaturen. Nach der Auswahl von Detached müssen Sie im Textfeld den Pfad und Dateinamen zu der zu signierenden Datei angeben. Dies kann ein XML-Dokument oder eine beliebige andere Datei sein. Über den Button Select... können Sie ein Standarddialogfeld zur Auswahl einer Datei öffnen. Die Auswahl einer Detached Signatur schränkt die zu signierende Ressource automatisch auf Document ein.

In der Gruppe Keystore and Key wählen Sie eine Schlüsseloption aus. Mit der Auswahl von Use a Key from an existing Keystore verwenden Sie einen vorhandenen Schlüssel aus einem Java Keystore zum Signieren. Bei Insert a new Key in an existing Keystore erweitern Sie einen vorhandenen Keystore um einen neuen Schlüssel und verwenden diesen gleich zum Signieren. Mit der Auswahl von Create a new Key and a new Keystore legen Sie einen neuen Keystore und darin einen neuen Schlüssel an. Dieser Schlüssel wird ebenfalls gleich zum Signieren verwendet.

Durch das Aktivieren der Basic Security Profile compliant signature wird der Assistent auf zu dieser Empfehlung kompatible Einstellungen eingeschränkt. Enveloping Signaturen werden dadurch deaktiviert. Stattdessen wird die Verwendung von Detached Signaturen empfohlen. Enveloped Signaturen sind möglich, ihre Verwendung wird aber nicht empfohlen.

Um vollständig konform zum Basic Security Profile zu sein muss auf der Use a Key from an existing Keystore Seite ein Schlüssel mit einem RSA Algorithmus ausgewählt oder auf der Seite Insert a new Key in an existing Keystore bzw. Create a new Key and a new Keystore ein entsprechender Schlüssel generiert werden. Auf der Seite Algorithms and Signature Properties werden alle Algorithmen gemäß der Empfehlung eingeschränkt und nur diese zur Auswahl angezeigt.

Nach der korrekten Eingabe aller erforderlichen Daten können Sie mit dem Next Button auf die nächste Seite des XML Signature Wizards wechseln. Je nach Auswahl bei den Schlüssel-Option unterscheidet sich diese: Use a Key from an existing Keystore, Insert a new Key in an existing Keystore oder Create a new Key and a new Keystore.

Keystore and Key

Bei der Verwendung von Schlüsselspeichern (Keystores) und Schlüsseln (Keys) mit Java Keystores haben Sie mehrere Möglichkeiten: Sie können einen vorhandenen Schlüssel aus einem Java Keystore verwenden (Use a Key from an existing Keystore), einen neuen Schlüssel in einen vorhanden Keystore einfügen (Insert a new Key in an existing Keystore) oder auch einen neuen Schlüssel in einem neuen Keystore generieren (Create a new Key and a new Keystore).

Je nachdem für welche dieser Optionen Sie sich entscheiden wird eine andere zweite Seite des XML Signature Wizards aufgerufen. Wenn Sie Ihre Schlüssel-Auswahl ändern wollen können Sie jederzeit mit dem Back Button eine Seite zurückspringen und einen anderen Eintrag markieren.

Keystores werden in dem speziellen Format JKS (Java Keystore) als Datei abgelegt. Das Format beinhaltet eine Verschlüsselung des Inhalts und die Möglichkeit, den Zugriff mit einem Passwort zu schützen. Um den Zugriff auf einen bestimmten Schlüssel zu ermöglichen muss für jedes ein beliebiger Alias Name vergeben werden. Ein Keystore kann damit mehrere Schlüssel auch unterschiedlichen Typs enthalten.

Beim Generieren einer Basic Security Profile compliant encryption kann nur ein RSA Schlüssel verwendet werden. Auch die Generierung von neuen Schlüsseln ist auf RSA beschränkt.

Use a Key from an existing Keystore

Auf dieser zweiten Seite des XML Signature Wizard müssen Sie zunächst den gewünschten Schlüsselspeicher und einen darin enthaltenen Schlüssel auswählen sowie die zugehörigen Passwörter angeben.

Use a Key from an existing Keystore

Zunächst müssen Sie eine Java Keystore Datei (mit der Dateiendung .jks) auswählen. Über den Button Open... öffnen Sie das Standarddialogfeld zur Auswahl einer solchen Datei.

Anschließend sind weitere Angaben zum Schlüsselspeicher und Schlüssel erforderlich. Alle angegebenen Felder sind Pflichtfelder. Mit den Punkt Buttons rechts neben den Passwortfeldern können sie den Klartext in einem Passwortfeld anzeigen lassen und Ihre Eingabe kontrollieren.

Mit dem Keystore Password kann der Schlüsselspeicher selbst geöffnet werden. Anschließend legen Sie mit dem Key Alias fest, welcher Schlüssel aus dem Keystore geladen werden soll. Dieser Schlüssel wird zur Erzeugung des KeyInfo Elements und später zur Verification der Signatur benötigt. Zum Abschluss müssen Sie noch das Passwort des Schlüssels angeben.

Nach der korrekten Eingabe aller erforderlichen Daten können Sie mit dem Next Button auf die nächste Seite des XML Signature Wizards wechseln: Algorithms and Signature Properties.

Insert a new Key in an existing Keystore

Auf dieser zweiten Seite des XML Signature Wizard können Sie einen neuen Schlüssel in einem vorhandenen Java Keystore generieren. Nach Angabe aller erforderlichen Daten wird das Zertifikat unter dem von Ihnen angegebenen Alias im ausgewählten Keystore gespeichert und zur Generierung dieser digitalen Signatur verwendet.

Insert a new Key in an existing Keystore

Zunächst müssen Sie die Daten für den Distinguished Name angeben. Dazu gehören Common Name, Organizational Unit, Organization, Location, State und Country. Lediglich der Common Name ist ein Pflichtfeld, die anderen fünf sind optional. Während der Eingabe der Daten zeigt das Vorschaufeld eine Übersicht Ihrer getätigten Eingaben an.

Anschließend sind einige Angaben zum Schlüssel (Key) erforderlich. Der Alias ist ein Pflichtfeld und muss zwischen 4 und 20 Zeichen lang sein. Das Password für den Schlüssel ist ebenfalls ein Pflichtfeld und muss mindestens 6, maximal jedoch 20 Zeichen lang sein. Mit dem Punkt Button rechts neben den Eingabefeld können Sie sich den Klartext anzeigen lassen und Ihre Eingabe kontrollieren. Aus der Type Auswahlbox können Sie jetzt noch den Typ des Schlüssels auswählen. Möglich sind Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA) und Rivest, Shamir, Adleman (RSA).

Jetzt müssen Sie noch den Java Keystore (mit der Dateiendung .jks) angeben, den Sie um den neuen Schlüssel erweitern wollen. Über den Button Open... öffnen Sie das Standarddialogfeld zur Auswahl einer solchen Datei. Damit der Schlüssel darin gespeichert werden kann ist noch die Eingabe des Keystore Passworts im Password Feld erforderlich. Mit dem Punkt Button rechts neben den Eingabefeld können Sie sich den Klartext anzeigen lassen und Ihre Eingabe kontrollieren.

Nach der korrekten Angabe aller erforderlichen Daten können Sie den Schlüssel über den Button Generate generieren und im angegebenen Keystore speichern lassen.

Den generierten Schlüssel können Sie in Zukunft über die Seite Use a Key from an existing Keystore direkt verwenden. Dazu benötigen Sie neben dem Dateinamen die unter Key Alias, Key Password und Keystore Password angegebenen Daten.

Nach der erfolgreichen Generierung des neuen Schlüssels können Sie mit dem Next Button auf die nächste Seite des XML Signature Wizards wechseln: Algorithms and Signature Properties.

Create a new Key and a new Keystore

Auf dieser zweiten Seite des XML Signature Wizard können Sie einen neuen Keystore mit einem neuen Schlüssel generieren. Nach Angabe aller erforderlichen Daten wird der Schlüssel unter dem von Ihnen angegebenen Alias im Keystore unter dem von Ihnen angegebenen Common Name gespeichert und zur Generierung dieser digitalen Signatur verwendet.

Create a new Key and a new Keystore

Zunächst müssen Sie die Daten für den Distinguished Name angeben. Dazu gehören Common Name, Organizational Unit, Organization, Location, State und Country. Lediglich der Common Name ist ein Pflichtfeld, die anderen fünf sind optional. Während der Eingabe der Daten zeigt das Vorschaufeld eine Übersicht Ihrer getätigten Eingaben an.

Anschließend sind einige Angaben zum Schlüssel (Key) erforderlich. Der Alias ist ein Pflichtfeld und muss zwischen 4 und 20 Zeichen lang sein. Das Password für den Schlüssel ist ebenfalls ein Pflichtfeld und muss mindestens 6, maximal jedoch 20 Zeichen lang sein. Mit dem Punkt Button rechts neben den Eingabefeld können Sie sich den Klartext anzeigen lassen und Ihre Eingabe kontrollieren. Aus der Type Auswahlbox können Sie jetzt noch den Typ des Schlüssels auswählen. Möglich sind Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA) und Rivest, Shamir, Adleman (RSA).

Jetzt müssen Sie nur noch ein Passwort für den neuen Keystore im Password Feld angeben. Das Password muss mindestens 6, maximal jedoch 20 Zeichen lang sein. Mit dem Punkt Button rechts neben den Eingabefeld können Sie sich den Klartext anzeigen lassen und Ihre Eingabe kontrollieren.

Nach der korrekten Angabe aller erforderlichen Daten können Sie den Schlüsselspeicher und den Schlüssel über den Button Create Keystore generieren lassen.

Den generierten Schlüssel können Sie in Zukunft über die Seite Use a Key from an existing Keystore direkt verwenden. Dazu benötigen Sie neben dem Dateinamen die unter Key Alias, Key Password und Keystore Password angegebenen Daten. Über die Seite Insert a new Key in an existing Keystore können Sie diesen Keystore um weitere Schlüssel ergänzen. Dazu benötigen Sie neben dem Dateinamen nur das Keystore Password.

Nach der erfolgreichen Generierung des neuen Schlüssels können Sie mit dem Next Button auf die nächste Seite des XML Signature Wizards wechseln: Algorithms and Signature Properties.

Algorithms and Signature Properties

Auf der letzten Seite des XML Signature Wizard müssen Sie sämtliche Algorithmen zur Canonicalization, Transformation sowie den Message Digest und Signature Algorithmus festlegen. Zusätzlich können Sie zur Signatur beliebige Signature Properties angeben und der Signatur eine optionale beliebige ID geben.

Algorithms and Signature Properties

Sie müssen in jedem der vier Auswahlfelder zu den Algorithmen eine Auswahl treffen. Lediglich beim Transformation Algorithm können Sie auch None auswählen und damit auf eine Transformation verzichten. Wenn Sie auf der Resource and Signature Type Seite des Wizard das Basic Security Profile aktiviert haben sind die Einträge in allen Auswahlfeldern entsprechend eingeschränkt. Die möglichen Signature Algorithm hängen von dem von Ihnen gewählten Zertifikat ab (bei DSA stehen nur DSA Algorithmen zur Auswahl, bei EC nur EC Algorithmen und bei RSA entsprechend nur RSA Algorithmen).

Nicht auf jeder Plattform stehen alle Algorithmen in allen verfügbaren Schlüssellängen zur Verfügung. Bei der Erzeugung der Signatur wird unter Umständen eine Fehlermeldung ausgegeben und die Signierung abgebrochen. Bitte verwenden Sie in diesem Fall einen anderen Algorithmus oder eine kürzere Schlüssellänge. Der Algorithmus RIPEMD160 beispielsweise steht nur auf Systemen mit zusätzlichem Kryptografieprovider (z.B. BouncyCastle) zur Verfügung.

Als Message Digest Algorithm können Sie auch den Algorithmus MD5 auswählen. Dieser gilt jedoch nicht mehr als ausreichend sicher und sollte keinesfalls zur Sicherung von wichtigen Dokumenten verwendet werden. Als ausreichend sicher gelten derzeit Hashwerte ab einer Länge von 160 Bit.

Bei den Signature Properties können Sie zusätzliche Informationen erfassen, die ebenfalls mit signiert werden sollen. Um einen neuen Eintrag hinzuzufügen klicken Sie zunächst auf den + Button neben der Tabelle. Anschließend können Sie die Informationen in der Tabelle eintragen. ID und Target sind dabei Pflichtangaben. IDs müssen außerdem im Dokument eindeutig sein. Einen markierten Eintrag löschen Sie über den - Button.

Eine optionale ID können Sie der Signatur mit Hilfe des Textfelds zuweisen. Erlaubt sind hierfür alle Zeichen bis auf die fünf bekannten XML Entity-Referenzen <, &, >, " und ' bis zu einer maximalen Länge von 20 Zeichen. Diese ID muss im XML-Dokument eindeutig sein, d.h. sie darf in keiner anderen Signatur verwendet werden.

Durch das Markieren der Checkbox Start Encryption Wizard afterwards wird direkt nach dem erfolgreichen Signieren der XML Encryption Wizard aufgerufen.

Nach der korrekten Eingabe aller erforderlichen Daten können Sie mit dem Finish Button den XML Signature Wizard beenden und das XML-Dokument signieren lassen.

XML Signatures View

Der Eintrag New Verification... im XML Security Kontextmenü überprüft alle im gewählten/ geöffneten XML-Dokument enthaltenen XML-Signaturen. Das Ergebnis der Überprüfung wird in der XML Signatures View angezeigt. Je nach Anzahl der im XML-Dokument enthaltenen Signaturen finden Sie hier unterschiedlich viele Einträge die Ihnen neben der Signatur ID den Status der Signatur (gültig, ungültig oder unbekannt) über ein Icon mitteilen. Angezeigt werden auch Informationen über den verwendeten Certificate Type und den Certificate Algorithm.

XML Signatures View

Ein Doppelklick auf einen Eintrag öffnet ein Popup-Dialog mit weiteren Informationen zur gewählten Signatur. Alternativ können Sie auch einen Eintrag markieren und den Menüeintrag Properties auswählen). Um alle Signaturen im geöffneten XML-Dokument erneut zu verifizieren können Sie auf den Button Refresh klicken.

Ungültige Signatur

XML Encryption Wizard

Mit dem XML Encryption Wizard können Sie beliebige XML-Dokumente verschlüsseln und die Verschlüsselung dabei an zahlreichen Stellen ganz nach Ihren Wünschen konfigurieren.

Der Wizard besteht aus drei Seiten, die nacheinander bearbeitet werden müssen. Nur wenn Sie alle Pflichtfelder einer Seite korrekt ausgefüllt haben können Sie auf die nächste Seite wechseln. Beachten Sie zu Ihrer Unterstützung die Textmeldungen oben im Dialog. Der Wizard kann nur auf der letzten Seite zum Generieren der Verschlüsselung beendet werden.

Der XML Encryption Wizard wird über den Eintrag New Encryption... im Kontextmenü aufgerufen. Er besteht aus den Seiten Resource and Encryption Type, Keystore and Key und Algorithms and Encryption Properties. Über das Hilfe-Icon links unten auf jeder Seite erhalten Sie eine kontextabhängige Kurzhilfe und können weitergehende Informationen aufrufen.

Resource and Encryption Type

Auf der ersten Seite des XML Encryption Wizard müssen Sie die zu verschlüsselnde Ressource auswählen und eine Vorauswahl zum kryptografischen Schlüssel treffen. Mit der Aktivierung von Generate a Basic Security Profile compliant encryption werden die Auswahlmöglichkeiten im gesamten Assistenten im Hinblick auf diese Empfehlung eingeschränkt.

Resource and Encryption Type

Die erste Auswahlmöglichkeit betrifft die zu verschlüsselnde Ressource. Document ist immer auswählbar und verschlüsselt das vollständige Dokument. Selection ist nur möglich wenn Sie im Editor mindestens ein Element oder Elementinhalt vor dem Aufruf des Assistenten markiert haben und der Assistent über das Kontextmenü eines Editors aufgerufen wurde. Die Auswahl muss wohlgeformt sein, d.h. sowohl das öffnende als auch das schließende Tag müssen in der Auswahl vorhanden sein. Werden die Regeln der Wohlgeformtheit verletzt kann Selection nicht aktiviert werden.

Bei der Auswahl von XPath können Sie im Textfeld einen XPath-Ausdruck eingeben. Alternativ können Sie über den Button Browse... einen weiteren Dialog zur Auswahl eines XPath Ausdrucks für das aktuelle XML-Dokument öffnen.

XPath Selection

Damit die XPath-Ausdrücke zu jedem Element angezeigt werden können muss es sich um ein wohlgeformtes XML-Dokument handeln. Insbesondere bei der Verwendung von Namensräumen muss der Namensraum auch definiert werden, d.h. ein xmlns:MeinNamensraum="http://www.namensraum.de" muss bei der Verwendung von MeinNamensraum unbedingt vorhanden sein.

Durch das Aktivieren von Generate a Basic Security Profile compliant encryption wird der Wizard auf zu dieser Empfehlung kompatible Einstellungen eingeschränkt. Auf der Seite Algorithms and Encryption Properties werden so alle Algorithmen gemäß der Empfehlung eingeschränkt.

Hierbei werden hinsichtlich der zugelassenen Algorithmen folgende Einschränkungen vorgenommen. Für die EncryptionMethod innerhalb von EncryptedData sind ausschließlich die Algorithmen Triple DES, AES 128 und AES 256 erlaubt. Für EncryptionMethod als Kindelement von EncryptedKey sind die Algorithmen Triple DES Key Wrap, AES-128 Key Wrap und AES-256 Key Wrap zugelassen.

Keystore and Key

Bei der Verwendung von Schlüsselspeichern (Keystores) und Schlüsseln (Keys) mit Java Keystores haben Sie mehrere Möglichkeiten: Sie können einen vorhandenen Schlüssel aus einem Java Keystore verwenden (Use a Key from an existing Keystore), einen neuen Schlüssel in einen vorhanden Keystore einfügen (Insert a new Key in an existing Keystore) oder auch einen neuen Schlüssel in einem neuen Keystore generieren (Create a new Key and a new Keystore).

Je nachdem für welche dieser Optionen Sie sich entscheiden wird eine andere zweite Seite des XML Encryption Wizards aufgerufen. Wenn Sie Ihre Schlüssel-Auswahl ändern wollen können Sie jederzeit mit dem Back Button eine Seite zurückspringen und einen anderen Eintrag markieren.

Keystores werden in dem speziellen Format JKS (Java Keystore) als Datei abgelegt. Das Format beinhaltet eine Verschlüsselung des Inhalts und die Möglichkeit, den Zugriff mit einem Passwort zu schützen. Um den Zugriff auf einen bestimmten Schlüssel zu ermöglichen muss für jedes ein beliebiger Alias Name vergeben werden. Ein Keystore kann damit mehrere Schlüssel auch unterschiedlichen Typs enthalten.

Beim Generieren einer Basic Security Profile compliant encryption kann nur ein RSA Schlüssel verwendet werden. Auch die Generierung von neuen Schlüsseln ist auf RSA beschränkt.

Use a Key from an existing Keystore

Auf dieser Seite müssen Sie den Schlüsselspeicher auswählen, der den gewünschten Schlüssel enthält. Sofern der Schlüsselspeicher mit einem Passwort geschützt ist, müssen Sie dieses hier ebenfalls angegeben. Anschließend benötigen Sie noch den Aliasnamen des Schlüssels und das Passwort mit dem der Schlüssel geschützt ist.

Use a Key from an existing Keystore

Der Assistent speichert automatisch den Pfad zum Schlüsselspeicher und den eingegebenen Aliasnamen. Beim nächsten Aufruf des Assistenten müssen Sie diese Informationen daher nicht nochmals eingeben. Passwörter werden niemals gespeichert und müssen bei jeder Verwendung neu eingegeben werden.

Insert a new Key in an existing Keystore

Auf dieser Seite können Sie einen neuen Schlüssel generieren und diesen in einen vorhandenen Schlüsselspeicher einfügen. Wählen Sie dazu zunächst den zu verwendenden Schlüsselspeicher aus und geben Sie das zugehörige Passwort ein. Schlüsselspeicher können beliebig viele Schlüssel, auch mit unterschiedlichen Algorithmen und Schlüssellängen, enthalten. Lediglich der Aliasname darf nur ein einziges Mal vorhanden sein.

Insert a new Key in an existing Keystore

Anschließend müssen Sie einige Angaben zum Schlüssel vornehmen. Neben dem Algorithmus und einer dazu passenden Länge (die Box passt sich automatisch dem gewählten Algorithmus an) sind das ein Aliasname und ein Passwort für den Schlüssel. Der Aliasname muss im Schlüsselspeicher eindeutig sein.

Nach Angabe bzw. Auswahl aller notwendigen Informationen können Sie den neuen Schlüssel über den Generate Button generieren lassen. Der neue Schlüssel wird automatisch im folgenden Verschlüsselungsprozess verwendet.

Nicht auf jeder Plattform stehen alle Algorithmen in allen möglichen Längen zur Verfügung. Bei der Erzeugung des Schlüssels oder später der Verschlüsselung wird unter Umständen eine Fehlermeldung ausgegeben und die Verschlüsselung abgebrochen. Bitte verwenden Sie in diesem Fall einen anderen oder kürzeren Algorithmus.

Create a new Key and a new Keystore

Auf dieser Seite generieren Sie einen neuen Schlüsselspeicher und fügen gleichzeitig einen neuen Schlüssel ein.

Create a new Key and a new Keystore

Für den Schlüsselspeicher müssen Sie einen Namen und ein Passwort angeben. Anschließend müssen Sie noch einige Angaben zum Schlüssel vornehmen. Neben dem Algorithmus und einer dazu passenden Länge (die Box passt sich automatisch dem gewählten Algorithmus an) sind das ein Aliasname und ein Passwort für den Schlüssel. Der Aliasname muss im Schlüsselspeicher eindeutig sein.

Nach Angabe bzw. Auswahl aller notwendigen Informationen können Sie den neuen Schlüsselspeicher zusammen mit dem neuen Schlüssel über den Generate Button generieren lassen. Der Schlüsselspeicher wird im aktuellen Verzeichnis (i.d.R. das aktive Projekt) abgelegt. Der neue Schlüssel wird automatisch im folgenden Verschlüsselungsprozess verwendet.

Nicht auf jeder Plattform stehen alle Algorithmen in allen möglichen Längen zur Verfügung. Bei der Erzeugung des Schlüssels oder später der Verschlüsselung wird unter Umständen eine Fehlermeldung ausgegeben und die Verschlüsselung abgebrochen. Bitte verwenden Sie in diesem Fall einen anderen oder kürzeren Algorithmus.

Algorithms and Encryption Properties

Auf der letzten Seite müssen Sie noch die beiden zu verwendenden Algorithmen für die Verschlüsselung der Daten und die Verschlüsselung des Schlüssels selbst angeben. Die Angabe einer ID für die Verschlüsselung ist optional, wird aber sehr empfohlen.

Algorithms and Encryption Properties

Zunächst müssen Sie die beiden erforderlichen Algorithmen für die Verschlüsselung der Daten (Encryption Algorithm) und zum Schlüsseltransport (Key Wrap Algorithm) auswählen.

Der Key Wrap Algorithmus dient dem sicheren Schlüsseltransport von einem Teilnehmer zu einem oder mehreren anderen (bspw. bei einer ungesicherten Übertragung über das Internet).

Keep root element as plain text bewirkt, dass nur der Inhalt des gewählten Elements verschlüsselt wird, das Element selbst aber im Klartext erhalten bleibt. Beim Verschlüsseln des vollständigen Dokuments bedeutet das, dass das Wurzelelement (nur dieses) im Klartext erhalten bleibt. Bei einer Textauswahl bleibt das entsprechende temporäre Wurzelelement der Textauswahl im Klartext erhalten. Standardmäßig werden sowohl das Element als auch der Elementinhalt verschlüsselt.

Die Angabe der ID für die Verschlüsselung ist optional. Hier können Sie beliebige Zeichen außer den fünf bekannten XML Entity-Referenzen <, &, >, " und ' bis zu einer maximalen Länge von 20 Zeichen eingeben. Diese ID muss im XML-Dokument eindeutig sein, d.h. sie darf von keiner anderen Verschlüsselung verwendet werden.

Wenn Sie Start Signature Wizard afterwards aktivieren wird nach der erfolgreichen Verschlüsselung automatisch der XML Signature Wizard aufgerufen. Damit können Sie das ausgewählte XML-Dokument direkt im Anschluss an die Verschlüsselung signieren.

Nach der Angabe aller erforderlichen Daten und dem Klick auf Finish erzeugt der Assistent das verschlüsselte XML-Dokument. Der ausgewählte Klartext wird dabei automatisch entfernt und durch den dazu passenden Geheimtext ersetzt.

XML Decryption Wizard

Mit dem XML Decryption Wizard können Sie aIhre verschlüsselten XML-Dokumente wieder entschlüsseln und den Klartext wiederherstellen. Hierfür benötigen Sie den bei der Verschlüsselung verwendeten Schlüsselspeicher und den darin enthaltenen Schlüssel.

Der XML Decryption Wizard wird über den Eintrag New Decryption... im Kontextmenü aufgerufen. Er besteht aus einer einzigen Seite Resource and Key Information. Über das Hilfe-Icon links unten auf jeder Seite erhalten Sie eine kontextabhängige Kurzhilfe und können weitergehende Informationen abrufen.

Resource and Key Information

Auf der ersten und einzigen Seite des Assistenten müssen Sie den bei der Verschlüsselung verwendeten Schlüsselspeicher samt Schlüssel angeben und eine Encryption ID auswählen.

Resource and Key Information

Geben Sie Im Feld Keystore Name den bei der Verschlüsselung verwendeten Schlüsselspeicher an. Über den Button Open... können Sie diesen einfach auswählen. Anschließend tragen Sie in das Feld Keystore Password das Passwort für den Schlüsselspeicher ein.

Neben dem Schlüsselspeicher müssen Sie auch noch einige Informationen zum Schlüssel selbst angeben.

In der Encryption ID Drop-Down-Box wählen Sie die Verschlüsselung aus die Sie wieder entschlüsseln möchten (und die zum angegebenen Schlüssel passt). Die Encryption ID entspricht dabei der ID die Sie beim Verschlüsseln angegeben haben. Haben Sie keine ID festgelegt oder möchten Sie die Entschlüsselung der Reihe nach vornehmen wählen Sie den Eintrag Use first encryption id aus.

Weitere Angaben sind nicht erforderlich. Ein Klick auf Finish entschlüsselt, bei korrekt eingegebenen Daten, das gewählte XML-Dokument und ersetzt den Chiffretext durch den Klartext. Bleibt das XML-Dokument verschlüsselt haben Sie evtl. nicht den Schlüsselspeicher bzw. Schlüssel ausgewählt, der zur Verschlüsselung des XML-Dokuments verwendet wurde. Oder Sie haben einen Schlüsselspeicher/ Schlüssel angegeben, der nicht zur Encryption ID passt. Rufen Sie in diesem Fall den Wizard erneut auf und geben die korrekten Daten an.

Canonicalization

Mit den Menüeinträgen Canonicalization without comments und Canonicalization with comments aus dem Kontextmenü können Sie das gewählte XML-Dokument mit der Exclusive XML Canonicalization oder Inclusive XML Canonicalization kanonisieren. Ob die exclusive oder die inclusive Variante verwendet wird und ob das XML-Dokument direkt aktualisiert wird oder ein weiteres Editorfenster mit der kanonisierten Version erstellt wird hängt von den Einstellungen in den Preferences ab. Beim Aufruf über eine View wie den Navigator und der Zieldokument Einstellung New Document wird das kanonisierte XML-Dokument als [Dateiname]_canon.xml im aktuellen Projekt gespeichert.

Wenn Sie Canonicalization without comments auswählen werden die Kommentare im XML-Dokument entfernt und durch Leerzeilen ersetzt, bei Canonicalization with comments bleiben die Kommentare erhalten. In jedem Fall wird der Befehl sofort ausgeführt (ohne Assistent) und das XML-Dokument entweder im Editor aktualisiert oder im Dateisystem gespeichert.

Die Kanonisierung ist an sich ein sehr einfacher Vorgang. Mit der Möglichkeit diese separat auszuführen sollen Ihnen vor allem die Vorgänge bei der Signierung verdeutlicht werden, was sich hinter dem Stichwort Kanonisierung verbirgt und welche Veränderungen dabei in einem XML-Dokument durchgeführt werden. Die Kanonisierung ist einer der wichtigsten Vorgänge die unter anderem bei der Signierung vor den Blicken des Benutzers verborgen ablaufen.

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