blob: 07932d5eb3d430df52fbfb4fd0c7a7f5b3dafbae [file] [log] [blame]
<html xmlns:sec="http://www.xml-sicherheit.de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" type="text/css" href="../format.css">
</head>
<body>
<h1>XML-Security Basics</h1>
<p>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 (<em>XML in 10 Points</em>) für die Metasprache XML. Sicherheitsmechanismen wie digitale Signaturen oder Verschlüsselung finden hierin jedoch keinerlei
Beachtung.
</p>
<p>Unter dem Stichwort XML-Sicherheit (<em>XML Security</em>) werden daher seit einigen Jahren Mechanismen zum digitalen Signieren sowie zum Verschlüsseln (mit) der Extensible Markup
Language zusammengefasst. Die XML-Sicherheit stellt dabei einen deutlichen Paradigmenwechsel von auf der <em>Abstract Syntax Notation One</em> (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 <em>normalen</em> XML-Anwendungen auch für <em>Security Assertion Markup Language</em> (SAML) und die umfangreichen <em>WS-Security</em> (<em>Web Service Security</em>) Empfehlungen.
</p>
<p>Die W3C Empfehlungen zur digitalen Signatur und Verschlüsselung mit XML führen dabei keinerlei neuen Sicherheitsmechanismen
ein. Sie legen vielmehr fest wie XML-Dokumente oder XML-Dokumentfragmente digital 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-Digitale 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.
</p>
<p>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 <em>SHA-1</em> 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.
</p>
<p>Vor allem die Festlegung bestimmter Algorithmen zeigt ein Problem auf: die W3C-Empfehlungen benötigen bekanntermaßen meist
längere Zeit bis eine <em>Candidate Recommendation</em> 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.
</p>
<h2 id="Feingranular">Feingranulare Sicherheit</h2>
<p>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:
</p>
<ul>
<li>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.
</li>
<li>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.
</li>
</ul>
<h2 id="End-to-End-Security">Informationsgebundene Sicherheit</h2>
<p>Sowohl bei den XML-Signaturen als auch bei der XML-Verschlüsselung spricht man von einer so genannten Ende-zu-Ende-Sicherheit
(<em>End-to-End-Security</em>) 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 <em>XML Security</em> auch <em>PKCS#7</em>). Somit kann die Signatur zusammen mit den verschlüsselten Daten auf dem Server, in der Datenbank oder anderswo gespeichert
werden.
</p>
<p>Das Gegenteil zur informationsgebundenen Sicherheit ist die so genannte Punkt-zu-Punkt-Sicherheit (<em>Hop-to-Hop-Security</em>) 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 <em>https</em> bzw. <em>SSL</em>). Am Endpunkt angekommen gibt es somit keine Sicherheit mehr, die Daten werden im Klartext gespeichert (Sicherheit des Übertragungskanals
aber keine Sicherheit der Daten).
</p>
<p>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 <em>ganz oder gar nicht</em>, 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.
</p>
<h2 id="Reihenfolge">Signierte Verschlüsselung vs. verschlüsselte Signatur</h2>
<p>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 digitale 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.
</p>
<p>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.
</p>
<h2 id="Signaturarten">Signaturarten</h2>
<p>Wie bei den herkömmlichen digitalen Signaturen unterscheidet man auch bei den XML Digitalen 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.
</p>
<p>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.
</p>
</body>
</html>