SOAP - aber sicher
Mario Jeckle und Barbara Zengler
Erschienen in der Ausgabe 1 (Januar/Februar 2002) der Zeitschrift OBJEKTSpektrum

Das „Simple Object Access Protokoll“ (SOAP) bildet eine Basis für den XML-basierten Informationsaustausch zwischen Applikationen. Derzeit wird die Idee durch das World Wide Web Consortium weiterentwickelt und standardisiert. Mögliche Anwendungsszenarien von SOAP stellen sowohl einfache unidirektionale Benachrichtigungsdienste als auch komplexe Interaktionsszenarien, wie entfernte Methodenaufrufe, dar.
Da SOAP selbst keine eigenen Sicherheitsmechanismen vorsieht, erfordert die Verwendung im sicherheitsrelevanten Umfeld den Einsatz zusätzlicher Mechanismen. Ihren Einsatz und ihr Zusammenspiel beschreibt dieser Beitrag.

back to top   Einführung

 

Kryptographie ist die Wissenschaft des Anfertigens von Geheimschriften. Sie trägt dem Wunsch der Geheimhaltung von Geschriebenem Rechnung. Bereits im Altertum wurden durch kryptographische Verfahren verschlüsselte Nachrichten durch Boten versandt, um sie für Dritte unlesbar - eigentlich unverstehbar - werden zu lassen (bereits Cäsar berichtet vom für ihn hilfreichen Einsatz einer Geheimschrift).
Eine andere Rolle nehmen historische Siegel ein, die - unter ein Dokument gesetzt - dessen Echtheit bestätigen sollen. Hierbei wird Öffentlichkeit nicht als störend empfunden, sondern vielmehr gleichgültig hingenommen, solange durch sie die ursprüngliche Nachricht nicht verändert wird. Bei Dokumenten von allgemeinem Interesse, wie Rechts- oder Gesetzestexten, kommt dem besiegelten Original häufig eine besonders beweiskräftige Funktion zu, die teilweise bis in unsere Tage hineinreicht.
Während einerseits Aufwände zur Sicherung des Inhaltes unternommen werden, wachsen auch die Anstrengungen der unerwünschten Interessenten, vermeintlich Geheimes in Erfahrung zu bringen, Dokumente und Urkunden unbemerkt nachträglich zu manipulieren oder sogar selbst vermeintliche Originale zu erzeugen. Bekanntestes Beispiel, mit entsprechender Tragweite, dürfte hier die später als Fälschung entlarvte Konstantinische Schenkung sein.
In unseren Tagen steht mit dem Internet zwar eine leistungsfähige und flexible Plattform zum Austausch von Nachrichten und zur Nutzung verschiedenster Dienste zur Verfügung; die dabei benutzten „Boten“ (die Knoten des Netzwerkes) sind jedoch im Allgemeinen nicht als uneingeschränkt vertrauenswürdig einzustufen. Daher sind die Urwünsche der sicheren Kommunikation auch im modernen Informationsverkehr präsent.

back to top   Anforderungen an eine sichere Datenübertragung

 

Üblicherweise (z.B. in [Sch96]) werden verschiedene Aspekte betrachtet, denen nicht allen gleichzeitig genügt werden muss, um von sicherer Datenübertragung sprechen zu können. Auch existieren für die verschiedenen Sicherheitsmerkmale unterschiedlich „starke“ technische Implementierungen. Konkret geht dies etwa mit dem Verschlüsselungsgrad und dem daher zu investierenden Aufwand der Dechiffrierung oder der hinzugefügten Redundanz zur Konsistenzgewährleistung einher.
Im Detail fächern sich die Sicherheitsaspekte auf in:

Während die Vertraulichkeit durch klassische Verschlüsselungsmechanismen erreichbar ist, welche die Nachricht in ein nur durch den Empfänger zurückverwandelbares Aussehen umsetzen, lässt sich die Berechtigung zur Nutzung eines Dienstes nicht unmittelbar durch kryptographische Verfahren prüfen. Hier benötigt der Aufrufer vielmehr einen digitalen Berechtigungsschein, der ihn als gültigen und zulässigen Nutzer legitimiert.
Dem verständlichen Wunsch nach unverändertem Eintreffen der übermittelten Daten beim Empfänger lässt sich durch ein Echtheitszertifikat nachkommen. Hierbei werden - vergleichbar einem Gutachten - charakteristische Eigenschaften des Originals detailliert beschreiben. Durch den Abgleich (Konsistenzprüfung) der eintreffenden Nachricht mit der verfertigten Beschreibung kann so die Echtheit geprüft werden. Einen denkbaren Anwendungsfall vergleichsweise wenig geheimer Information, die nichts desto trotz unverändert beim Empfänger eingehen sollte, stellen Bestelldaten für weniger wichtige Güter (etwa Bleistifte) eines Unternehmens dar. Erlangen Dritte Kenntnis von der Auftragsinformation (wie Bestellumfang und Liefertermin), so kann dies als wenig kritisch eingestuft werden. Das unbemerkte Heraufsetzen der Bestellmenge würde hingegen einen ernstlichen Eingriff in die Integrität der übermittelten Daten darstellen.
Weiter soll der Sender glaubwürdig der Urheber einer versandten Nachricht sein. Am Beispiel der Bleistiftbestellung: Neben dem unveränderten Eintreffen der Bestellung soll auch für den Empfänger glaubhaft feststehen, dass der vorgebliche Absender auch der tatsächliche ist.
Mit der Anforderung der Glaubwürdigkeit verbindet sich der Wunsch nach Verbindlichkeit zur intuitiven Vorstellung einer Unterschrift im klassischen Sinne. Sie bestätigt in diesem Falle (wie beispielsweise der Autor durch seinen persönlichen Namenszug) rechtsverbindlich die Urheberschaft oder Zustimmung zum Dokumentinhalt.
Zur Realisierung der verschiedenen Sicherheitsaspekte haben sich eine Reihe technischer Lösungen herausgebildet, die sich grob in zwei Verfahrensklassen einordnen lassen:

Während durch kryptographische Bearbeitung der ursprüngliche Nachrichtentext so modifiziert wird, dass er für einen Angreifer nicht (oder nur mit großem Aufwand) lesbar ist, zielt der Einsatz digitaler Unterschriften auf die Bestätigung der Echtheit der inhaltlich unverändert übermittelten Information ab.

back to top   Grundlegende Verfahren - ein kleiner Überblick

 

Kryptographische Verfahren lassen sich prinzipiell wiederum in zwei Kategorien einteilen. Zum einen existieren sogenannte symmetrische Verfahren. Bei diesem Verschlüsselungstyp werden sowohl zur Chiffrierung als auch zur Dechiffrierung eines Nachrichtentextes dieselben Schlüssel benutzt.
Zum anderen markieren asymmetrische Verfahren (auch als „public key“ Verfahren bezeichnet) einen dualen Ansatz. Hier werden verschiedene Schlüssel zur Ver- und Entschlüsselung benutzt. Jeder Teilnehmer ist im Besitz eines Schlüsselpaares, bestehend aus einem privaten und einem öffentlichen Schlüssel. Für den öffentlichen Schlüssel besteht keine Geheimhaltungspflicht, im Gegenteil: Er sollte idealerweise zentral - und so für die Welt zugänglich - abgelegt sein. Zur Verschlüsselung einer Nachricht verwendet der Sender den öffentlichen Schlüssel des Empfängers, der zur Dechiffrierung seinen privaten Schlüssel verwendet.
Das durch mathematische Verfahren erzeugte Schlüsselpaar ist so aufgebaut, daß zu jedem öffentlichen nur ein „sperrender“ privater Schlüssel existiert. Darüberhinaus ist sichergestellt, dass von der Kenntnis des öffentlichen Schlüssels nicht auf den Aufbau des privaten rückgeschlossen werden kann
Die bekannteste Anwendung asymmetrischer Verschlüsselung dürfte die verbreitete Pretty Good Privacy-Architektur (PGP) vgl. PGP sein, die hauptsächlich zur Sicherung des E-Mail-Verkehrs Anwendung findet.
Ein weiteres weit verbreitetes Einsatzgebiet für Kryptographie sind digitale Signaturen. Sie dienen weniger der Sicherung des Nachrichtenverkehrs vor dem lesenden Zugriff Dritter, als vielmehr als Garant der Unverändertheit der Nachricht.
Der Signaturvorgang vollzieht sich in zwei Schritten. Zunächst wird mit Hilfe einer Hash-Funktion über die bestehende Nachricht ein eindeutiger Wert (Message Digest) berechnet, der später zur Validierung der Integrität herangezogen wird. Dieser Message Digest fungiert als charakteristische Eigenschaft der Nachricht, er repräsentiert sie eindeutig wie ein Fingerabdruck. Naturgemäß geht dieser Kompaktifizierungsvorgang mit einem Verlust an Information einher.
Besondere Aufmerksamkeit ist der Wahl einer „guten“ Hash-Funktion zu schenken. Diese muss aufgrund ihrer besonderen Bedeutung (nämlich als Basis der späteren Validierung) so organisiert sein, dass sich (im Gegensatz zum simplen Prüfsummenverfahren) niemals identische Zusammenfassungen für unterschiedliche Nachrichten ergeben.
Aktuell wird zumeist der durch die amerikanische NSA veröffentlichte Secure Hash Algorithm (SHA1) (vgl. [Eas01]) verwendet, der als hinreichend sicher angesehen werden kann. Dieses Verfahren ist auch in PGP-Implementierungen umgesetzt.

Erfüllung der Anforderungen an sichere Datenübertragung

Im Hinblick auf die eingangs formulierten Anforderungen für sichere Datenübertragung lässt sich feststellen, dass weder Verschlüsselung noch digitale Signatur, wie in Abbildung 1 dargestellt, in der Lage sind, eigenständig allen Wünsche gleichermaßen nachzukommen.
Verschlüsselung erlaubt neben der Erfüllung der Basisforderung nach Vertraulichkeit auch implizit Berechtigungsprüfung beim Einsatz asymmetrischer Verschlüsselung. Symmetrische Verschlüsselung hingegen läßt diese Trennschärfe der Aussage nicht zu, da jeder Kommunikationspartner über denselben geheimen Schlüssel verfügt. Selbst wenn dieser Schlüssel nur im Kreise der Vertrauenswürdigen verbleibt, kann durch den Empfänger der ursprüngliche Sender nicht mehr aus dieser Menge potentiell gleichgestellter Partner ermittelt werden.
Die Sicherstellung der Berechtigung liegt daher vielmehr in der Domäne digitaler Signaturen. Bei diesem Anwendungsaspekt tritt stärker der Gedanke der Identität und damit die Gewissheit, dass der vorgebliche auch der tatsächliche Verfasser und Sender ist, in den Vordergrund. Zusätzlich verfolgt die digitale Signatur die Intention, Modifikationen, die nach dem Versenden vorgenommen wurden, für den Empfänger aufzudecken. Durch den Vergleich des durch den Autor erstellten und mitversandten Message Digests mit der durch den Empfänger unter Verwendung derselben Hash-Funktion erstellten Zusammenfassung läßt sich die Konsistenz von Nachricht und Original einfach prüfen.

In der Praxis wird der Grundgedanke digitaler Signaturen mit Ideen der Kryptographie verknüpft, um zusätzlich den Zielen der Verbindlichkeit und Glaubwürdigkeit zu genügen. Hierzu wird der Nachrichten-Fingerabdruck zusätzlich verschlüsselt, um sie mit autoren-spezifischer Information zu kombinieren.
Jenseits der Universalität der skizzierten Ansätze zur Sicherung allgemeinen Nachrichtenverkehrs ergeben sich bei Verengung des Betrachtungsraumes auf SOAP einige bemerkenswerte Besonderheiten. Am augenfälligsten ist sicherlich zunächst die durchgängige Formatierung der übertragenen Daten als XML-Dokument (vgl. [Bra00]). Zwar handelt es sich dabei lediglich um einen Unicode-Textstrom; jedoch ergibt sich aus der Anlage der XML selbst bereits ein Gesichtspunkt, dem bei der Absicherung der Inhalte Aufmerksamkeit zuteil werden muss: die mögliche fein-granulare Steuerung der Sicherheit. Durch die in XML realisierte Separierung von Inhalten und beschreibender Information, die in XML-Elemente und -Attribute zerfällt, lässt sich bereits intuitiv eine Trennlinie ausmachen. So ist es beispielsweise denkbar, lediglich die Nutzinformation eines Dokuments zu verschlüsseln und dabei die Tags unberührt zu belassen. Genauso können wahlfrei auch ganze Elemente unter Einbeziehung ihrer Kindelemente, mithin abgegrenzte Dokumentteile, kryptographisch bearbeitet werden.

Derselbe Freiheitsgrad steht auch für die Anbringung von digitalen Signaturen zur Verfügung. So können sie in variabler Granularität von Einzelelementen bis hin zum gesamten Dokument angebracht werden.

Einen Einblick in die laufenden Aktivitäten des World Wide Web Comsortiums (W3C) zu XML Verschlüsselung und Signaturen liefern [Ima01], [Bar01] und [XMLSec].

back to top   Sichere Seife ...

 

Die XML-Sicherheitsmechanismen sind auch für entfernte Funktionsaufrufe und Nachrichtenaustausch mit dem SOAP-Format (vgl. [Box00]) tauglich. SOAP selbst definiert jedoch ausschließlich ein XML-Vokabular zur Strukturierung von Nachrichten in Umschläge und Nachrichtenrümpfe und lässt Sicherheitsaspekte vollkommen unberücksichtigt, ja die mit der Standardisierung betraute Arbeitsgruppe (vgl. [XMLP]) des W3C klammert sie sogar ausdrücklich aus.

Dies geschieht aus der Absicht heraus, durch SOAP lediglich ein Rahmenwerk zu definieren. Daher wurden spezifische Fragestellungen - etwa nach dem konkret einzusetzenden Verschlüsselungsalgorithmus oder dem Schlüsselerzeugungs- und Austauschverfahren - gezielt ausgeklammert. Obgleich die Zielsetzung der Arbeitsgruppe Sicherheit an verschiedenen Stellen mit einbezieht, bleibt die technische Realisierung dem Anwender überlassen. Das SOAP-Anforderungsdokument (vgl. [App00]) umreißt daher lediglich die in Abbildung 2 dargestellten Ansatzpunkte.

Eingriffspunkte der SOAP-Sicherheitsmechanismen im ISO-OSI-Referenzmodell

In Anlehnung an die Schichten des bekannten ISO-OSI Referenzmodells ([ISO94]) lässt sich SOAP primär als Protokoll der Darstellungsschicht einordnen. Allerdings kann - je nach gebundenem Netzprotokoll, etwa bei den Transportprotokollen TCP oder UDP - auch die Einordnung von SOAP als Protokoll der Sitzungsschicht erfolgen. Letztlich offenbaren sich die harten Schnitte zwischen den Schichten des Referenzmodells hier als ein Nachteil.

Generell läßt sich die Sicherheit der übermittelten Nachrichten „unterhalb“ bzw. „oberhalb“ der SOAP-Schicht einbringen. Zeitlich der SOAP-Nachrichtenerzeugung nachgelagert und damit im Referenzmodell unterhalb der SOAP-Schicht angeordnet sind Sicherheitsmechanismen wie der Secure Sockets Layer (SSL) zu sehen. Diese operieren auf beliebigen Datenströmen, welche durch die darüber liegenden Protokollschichten erzeugt und über definierte Schnittstellen bereitgestellt werden. Die Benutzung dieser Klasse von Kommunikationsabsicherung ist für die SOAP verwendenden Applikationen im Betrieb vollkommen transparent und erfordert nur minimale Eingriffe in den Kommunikationsablauf.
Wird hingegen die Absicherung der im SOAP-Umschlag enthaltenen Daten mit Mitteln der XML-Technologie gewünscht, so sind Eingriffe in die Applikation oder zumindest die Kommunikationskomponente notwendig. Hierfür existieren die beiden eingangs skizzierten Ansätze der XML-Signaturen und der XML-Verschlüsselung, die sich vergleichsweise einfach in das SOAP-Umfeld integrieren lassen. Für den Teilbereich der digitalen Signierung von SOAP-Nachrichten existiert mit [Bro01] bereits ein erster im W3C diskutierter Vorschlag.

back to top   ... und ihre Verwendung

 

XML digital Signatures

Mit dem Standardisierungsvorschlag („Proposed Recommendation“) XML Signature Syntax and Processing (vgl. [Bar01]) wird dem breiteren Einsatz von XML-Signaturen in der Praxis der Weg geebnet. Es ist abzusehen, dass dieser Mechanismus zukünftig vermehrt zur Gewährleistung der an digitale Signaturen erhobenen Anforderungen eingesetzt werden wird.

Ablauf beim Erzeugen und Prüfen digitaler Signaturen in XML

Die Vorgangssequenz zur Erzeugung eines digital signierten SOAP-Aufrufs beim Sender und zur Prüfung der Unterschrift beim Empfänger ist in Abbildung 3 dargestellt.
Derzeit ist es für die Kommunikationspartner nur möglich, mit Signaturen auf der XML-Darstellung der SOAP-Nachrichten zu operieren, da durch die Hochsprachenschnittstellen und Toolkits noch keine spezifische Unterstützung angeboten wird. In absehbarer Zeit, vermutlich parallel zur endgültigen Verabschiedung durch das W3C, werden die verschiedenen Hersteller entsprechende Funktionalität in ihre Produkte integrieren. Für Java ist dies bereits durch [JCP-a] absehbar.
Zur Ausfertigung einer digitalen Signatur für einen Teilbaum eines SOAP-Dokuments ist zunächst das XML-Startelement dieses Teilbaums festzulegen. Naheliegenderweise handelt es sich hierbei zumeist um ein Kindelement von Body. Dieses Rumpfelement leitet die Nutzdaten des Dokumentes ein. Konzeptionell ist zwar ebenfalls die Signierung von im Header plazierter Metainformation denkbar; jedoch würde durch Anbringung der Signatur Information über diese Metainformation generiert, für die kein SOAP-Standardbehandlungsmechanismus vorgesehen ist. Überdies würde die Bedeutung der Metainformation dadurch hin zur Nutzinformation verschoben. Daher ist es für diesen Spezialfall sinnvoll, die (vormalige) Metainformation im SOAP-Rumpf zu plazieren, um eine Gleichbehandlung mit den übrigen signierten Daten zu gewährleisten.

Vor Erstellung der eigentlichen Signatur tritt noch eine technische Besonderheit zu Tage, die gesonderte Behandlung erfordert: XML ist überwiegend formatfrei ausgelegt, d.h. ausschließlich der Formatierung dienende Leerzeichen (sogenannte white spaces, definiert durch die Syntaxregel 3 der XML-Spezifikation, vgl. [Bra00] ) außerhalb von Elementgrenzen können ohne Informationsverlust weggelassen werden; daher können augenscheinlich verschiedene Dokumente durchaus dieselbe physische Information repräsentieren. Vielmehr noch: XML-Prozessoren ist es sogar freigestellt diese Formatierungsanteile wegzulassen.
Wird dieser Freiheitsgrad auf die Verwendung digitaler Signaturen in SOAP bezogen, ergibt sich hieraus die Gefahr, dass eine inhaltlich unverändert beim Empfänger eintreffende Nachricht „versehentlich“ während des Transportes XML-konform umformatiert wurde und daher nicht mehr mit der beim Versenden erstellten Signatur übereinstimmt.
Aus diesem Grunde wurde durch das W3C mit Canonical XML (vgl. [Boy01]) eine eindeutige normalisierte Repräsentation definiert, die aus jedem wohlgeformten XML-Dokument erzeugt werden kann. In dieser Darstellung sind die möglichen Mehrdeutigkeiten eindeutig aufgelöst, sodass inhaltlich gleiche Dokumente mit unterschiedlicher Formatierung, Codierung und ähnlichem auf dasselbe kanonische XML-Dokument abgebildet werden.

Als Ausgangspunkt des Signierungsvorganges wird daher auf das kanonische XML-Dokument zurückgegriffen. Wie im allgemeinen Fall digitaler Signaturen wird auch für XML-Dokumente oder ihre Teile ein mathematisch berechneter charakteristischer Fingerabdruck zur Generierung der Signatur herangezogen. Die W3C-Spezifikation schlägt als einzigen Algorithmus zur Gewinnung des Message Digests den bekannten Secure Hash Algorithm (SHA) vor. Gleichzeitig wird ausdrücklich von der Verwendung des MD5-Algorithmus (vgl. [Rie92]) abgeraten, da sich dieser hinsichtlich kryptoanalytischer Angriffe als anfällig erwiesen hat.
Auf dem Message Digest fußend wird schlußendlich unter Verwendung eines geeigneten Signaturalgorithmus die Unterschrift berechnet. In den Erzeugungsvorgang fließt neben dem Fingerabdruck der Nachricht auch der Schlüssel des Unterzeichnenden ein. Im Rahmen der XML-Signaturen wird hierbei explizit auf Public-Key-Verfahren zurückgegriffen.
Spezifikationskonforme Umsetzungen müssen hierbei mindestens den US-amerikanischen Digital Signatures Standard (DSS) (vgl. [DSS]) und den RSA Algorithmus (vgl. [Kal98]) unterstützen.

(1)<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
(2)<SOAP-ENV:Header>
(3)  <SOAP-SEC:Signature
(4)     xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
(5)     SOAP-ENV:actor="http://www.example.com/soapEndpoint"
(6)     SOAP-ENV:mustUnderstand="1">
(7)   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
(8)      <ds:SignedInfo>
(9)         <ds:CanonicalizationMethod
(10)       Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
(11)         <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
(12)         <ds:Reference URI="#Body">
(13)       <ds:Transforms>
(14)          <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
(15)       </ds:Transforms>
(16)       <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
(17)       <ds:DigestValue>zA9itX3gfzCeYIYyalslJezGwAg=</ds:DigestValue>
(18)         </ds:Reference>
(19)      </ds:SignedInfo>
(20)      <ds:SignatureValue>
(21)         MCpXybqBI2Aa3Yx4IovjN3GgchaMDB3lIF1M6a9+Ngi59MqDwK3LRQ==
(22)      </ds:SignatureValue>
(23)   </ds:Signature>
(24)     </SOAP-SEC:Signature>
(25)  </SOAP-ENV:Header>
(26)<SOAP-ENV:Body xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"
(27)  SOAP-SEC:id="Body">
(28)  <ns1:add xmlns:ns1="urn:NumberAdder"
(29)     SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
(30)     <number1 xsi:type="xsd:int">1</number1>
(31)     <number2 xsi:type="xsd:int">2</number2>
(32)  </ns1:add>
(33)</SOAP-ENV:Body>
(34)</SOAP-ENV:Envelope>
(35)
(36)

Listing 1: Signierte SOAP-Nachricht

Listing 1 zeigt beispielhaft eine vollständige SOAP-Nachricht mit signiertem Inhalt. Ein dieses Nachrichtenformat akzeptierender Dienst offeriert als (NumberAdder genannter) Service, zwei Ganzzahlen zu addieren und dem Aufrufer die Summe als Resultat zu liefern. Hierzu werden in den Zeilen 30 und 31 die notwendigen Parameter übergeben.
Die Signaturdaten werden prinzipiell durch ein eigenes XML-Vokabular dargestellt, das für die Verwendung im Zusammenspiel mit SOAP durch den Namensraummechanismus eingebettet wird.
Hierzu wird im SOAP-Header ab Zeile 3 das Element Signature plaziert. Es kapselt die gesamten signatur-relevanten Metadaten wie das verwendete Kanonisierungsverfahren (Zeile 9 f.) und den Signaturalgorithmus (Zeile 11). Zusätzlich findet sich dort der Verweis auf das signierte Element. Im Beispiel wurde der gesamte SOAP-Body (ab Zeile 26) signiert. Zur Referenzierung wird zunächst mit dem Attribut id ein Anker (hier mit dem Namen Body) definiert (Zeile 27). Hierauf verweist das Metainformationselement aus Zeile 12 ff., das die konkreten Signaturinformationen beinhaltet. So gibt das Element DigestValue (Zeile 17) den mittels des SHA-1-Verfahrens errechneten Message Digest des verwiesenen Ankerelements wieder.

Die durch den in Zeile 11 spezifizierten Signaturalgorithmus erzeugte Signatur wird im Element SignatureValue eingebettet übermittelt.
Message Digest und Signatur werden zu besseren Lesbarkeit und zur Vorbeugung von Übertragungsproblemen mit dem aus dem E-Mail-Verkehr bekannten base64-Verfahren codiert
. Abschließend sei noch zu den in den Zeilen 10, 14 und 16 in Form von URIs (Uniform Resource Identifier) angegebenen Belegungen des Algorithm-Attributs angemerkt, dass diese lediglich der Identifikation der genannten Algorithmen und Verfahren dienen. Ihre Rolle ist daher vielmehr ähnlich den XML-Namensraumbezeichnern zu sehen, als dass sie auf eine dereferenzierbare Ressource verweisen würden.

Wie im unteren Teil der Abbildung 3 schematisch dargestellt, wird der SOAP-Aufruf nebst Signatur und signatur-relevanter Metainformation übermittelt. Der Empfänger vollzieht zur Prüfung der Unterschrift das beim Sender durchgeführte Verfahren mit denselben Parametern nach. Auch er generiert zunächst aus dem eingegangenen SOAP-Aufruf dessen eindeutige kanonische Repräsentation (unter Einsatz des in den Metadaten referenzierten Algorithmus). Mittels des ebenfalls bekannten Kanonisierungsverfahrens gewinnt er eigenständig den charakteristischen Message Digest der empfangenen Nachricht und wendet darauf die in der Nachricht genannte Unterschriftsmethode an. Kommen hier asymmetrische Schlüssel zum Einsatz (d.h. unterscheiden sich die von Sender und Empfänger eingesetzten Schlüssel), so nutzt der Empfänger den öffentlich zugänglichen Schlüssel des Senders. Durch die zugrundeliegende mathematische Gesetzmäßigkeit ist hierbei sichergestellt, dass für beide unterscheidbaren Schlüssel desselben Schlüsselpaares identische Signaturen erzeugt werden können.
Stimmt diese empfängerseitig unabhängig erzeugte Unterschrift mit der in der SOAP-Nachricht eingebetteten überein, so liegt keine Datenmodifikation vor.
Zur Applikationsunterstützung digitaler Signaturen für XML ist primär „lediglich“ die Implementierung der in der W3C-Spezifikation genannten Algorithmen notwendig. Hierfür existieren inzwischen einige Referenzimplementierungen (vgl. [XMLSigImpl]) für die bekannten Programmiersprachen (wie Java oder die C-Sprachfamilie), die in eigene Programme eingebunden werden können.

Sinnvollerweise sollte zur Verwaltung der zur Signierung benötigten öffentlichen Schlüssel auf eine zentrale Schlüsselverwaltung (etwa eine Public Key Infrastruktur) zurückgegriffen werden.
Prägendes Merkmal digitaler Signaturen ist, dass durch sie keine Verschlüsselung der Daten erzielt wird. Sie garantieren daher keine Vertraulichkeit. Vielmehr werden Signaturen hauptsächlich dazu benutzt, um die Authentizität der verbindlichen glaubwürdigen Urheberschaft von Nachrichten und deren Konsistenz überprüfbar zu machen.

Im Zusammenspiel mit kryptographischen Schlüsseln lassen sich durch Signaturen sogar Teile der Berechtigungsprüfung realisieren. Im Kern sind Berechtigungsprüfung und Vertraulichkeit jedoch die Domäne von eigenständigen Verschlüsselungsverfahren. Daher werden die XML Signaturen um XML Encryption ergänzt, die derzeit als letzte Arbeitskopie („Working Draft“) dem W3C zur Abstimmung vorliegen

XML Encryption

Nicht verwunderlich ist es daher, dass XML Encryption als Rahmenwerk ausschließlich auf den Problembereich der Zusicherung von Vertraulichkeit abzielt. Mit Hilfe bekannter Verschlüsselungsalgorithmen werden die zu übertragenden XML-codierten Daten zunächst chiffriert, um dann nach erfolgreicher Übertragung auf der Gegenseite wieder entschlüsselt und somit für die verarbeitende Applikation wieder lesbar gemacht zu werden.
Analog zur digitalen Signatur kann auch hier die Verschlüsselungsgranularität durch den Anwender variiert werden. Neben der frei festlegbaren Bearbeitung von Dokumentteilen (XML-Teilbäumen) ist auch die selektive Verschlüsselung von Elementinhalten ohne Modifikation der bezeichnenden Tags möglich
Auch XML-Verschlüsselungstechniken agieren, wie bereits die Signaturen, direkt auf der XML-Repräsentation der SOAP-Nachricht. Wie auch dort, haben bisher die Hersteller noch keine Unterstützung in Form von Hochsprachenschnittstellen angeboten, welche die komfortable transparente Nutzung ermöglichen würden. Mit [JCP-b] werden bereits Ansätze hierfür erkennbar, die sicherlich nach Verabschiedung des Standards in Produkte umgesetzt werden.

Technisch vollzieht sich die Verschlüsselung von SOAP-Nachrichten in zwei Schritten: Zunächst sind die notwendigen Randbedingungen wie Verschlüsselungsverfahren, etwaige Initialisierungsparameter (z.B. Zufallszahlen), Verschlüsselungsgranularität und der zu verwendende Schlüssel zu fixieren. Unter Einsatz dieser wird dann aus dem XML-Eingangsdokument ein Dokument mit chiffrierten Anteilen erzeugt.
Die für den Empfänger zur späteren Entschlüsselung notwendigen Informationen (gewähltes Verschlüsselungsverfahren und evtl. benötigte Initialisierungsparameter) werden gemeinsam mit dem Chiffrat übertragen. Zur Strukturierung dieser Daten definiert die XML Encryption-Spezifikation ein Vokabular sowie grundlegende Verarbeitungsanweisungen.

Zur Entschlüsselung kehrt der Empfänger den Prozess um und berechnet aus dem Eingangsdokument unter Anwendung des bekannten Algorithmus und eines geeigneten Schlüssels wieder das Originaldokument.
Hierbei ist es laut Spezifikation offengelassen, ob symmetrische oder asymmetrische Verfahren zum Einsatz kommen. Darüber hinaus können Schlüsselinformationen in die übertragene Nachricht eingebettet werden.

(1)<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
(2)xmlns:xsd="http://www.w3.org/2001/XMLSchema"
(3)xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
(4)<SOAP-ENV:Body>
(5)  <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
(6)     Type="http://www.w3.org/2001/04/xmlenc#Element">
(7)     <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc">
(8)   <IV>ZG9uJ3RTcHk=</IV>
(9)     </EncryptionMethod>
(10)     <CipherData>
(11)   <CipherValue>sVjhJIW5QnIeY3brbpamNOcz/Ja+RmnG0pLo7vWnmTp+vpVs53c0Y
(12)   VDeb4gmYEcOBTAe00S8l0cySJpKGkgbVksD9zo6U2LpS466KXIp5NDVRgJcHZnp8tr
(13)   o5mb90g2gB56bw+IyskKh7QDMbvM7ACdT6SGauu0dSGIT3Q5kTT1qQWQ4easDZ1ShH
(14)   pVYrBXPRI//3QGyjrnOOclh8T5eqRhRRAuwUc3A4RqaH7M6QTIb36vOTBRuFbfFESB
(15)   w8648Xi8GlSpu39cVoMjEUTrldnJo1gpWdU5JWFf9RqzhmBQ=</CipherValue>
(16)     </CipherData>
(17)  </EncryptedData>
(18)</SOAP-ENV:Body>
(19)</SOAP-ENV:Envelope>
(20)
(21)

Listing 2: Verschlüsselte SOAP-Nachricht

Der SOAP-Aufruf des Beispiels der Abbildung 2 zeigt eine vollständige Nachricht, deren Body-Element kryptographisch verschlüsselt wurde.
Der Wurzelknoten der Verschlüsselungsdaten ist spezifikationsgemäß mit EncryptedData (Zeile 5) benannt. Er ersetzt als neues Kindelement den Inhalt des verschlüsselten Dokumentknotens. Sein Type-Attribut (Zeile 6) gibt Auskunft darüber, in welcher Granularität die Dokumentinhalte chiffriert wurden. Neben elementweiser Verschlüsselung (wie im Beispiel durch die Belegung http://www.w3.org/2001/04/xmlenc#Element ausgedrückt) ist auch die ausschließliche Bearbeitung von Element-Inhalten vorgesehen. In diesem Falle bleiben die Tag-Namen unangetastet erhalten.
Die zur Entschlüsselung essentiellen Informationen über den gewählten Verschlüsselungsalgorithmus und gegebenenfalls dessen Parameter sind durch das Element EncryptionMethod (Zeile 7 ff.) repräsentiert. Prinzipiell können Sender und Empfänger beliebige Algorithmen vereinbaren und durch das genannte Element einander mitteilen, lediglich die Standardalgorithmen des Advanced Encryption Standard (AES) und Triple DES müssen durch XML Encryption konforme Systeme angeboten werden. Für das Beispiel wurde letztgenannter Algorithmus eingesetzt; die Belegung des Algorithm-Attributes in Zeile 7 zeigt den hierfür vordefinierten Bezeichner.
Optional können im Rumpf des Elements IV (Abk. für Initialization Vector) durch den Algorithmus benötigte Eingangsparameter (im Falle von „Triple-DES 64“ base64-codierte Bit) übergeben werden.
Die verschlüsselte Nutzinformation des ursprünglichen Body-Elements ist im CipherValue-Kind von CipherData wiedergegeben.
Im Gegensatz zum Einsatz der XML Signaturen ist das verschlüsselte XML-Dokument bezüglich seines Schemas nicht mehr gültig. Zwar besteht unverändert Gültigkeit hinsichtlich des SOAP-Envelope-Schemas, welches lediglich wohlgeformten XML-Inhalt für das Body-Element vorsieht. Durch die kryptographische Bearbeitung werden jedoch mindestens der Elementinhalt und möglicherweise sogar die Dokumentstruktur zerstört.
Versuche schema-erhaltender Kryptographie haben sich als wenig erfolgsträchtig - hinsichtlich des zu erzielenden Zugewinns ans Sicherheit - offenbart, da hierbei sowohl das Schema strukturell erhalten werden müsste, als auch die Datentypen nur in den zulässigen lexikalischen Bereich abgebildet werden dürften. Gerade die zweite Forderung lässt offenkundig werden, dass sich auf dieser Basis keine wirkungsvolle Sicherheit erzielen lässt. Während beispielsweise für jede int-Ausprägung nach XML-Schema noch 4.294.967.295 Darstellungsalternativen blieben, könnte die Belegung eines booleschen Wahrheitswertes entweder durch sein Gegenteil oder den Originalwert selbst „verschleiert“ werden. Zusätzlich würden dermaßen behandelte SOAP-Aufrufe eine vergleichsweise leichte Beute für Angriffe durch simples Erraten, eventuell sogar noch unter Ausnutzung von Kontextinformation, darstellen.

In Bezug auf den Einsatz gelten im Wesentlichen die auch für XML-Signaturen getroffenen Aussagen hinsichtlich der Applikationsunterstüzung durch eigene Programmierung. Auch in diesem Falle bietet [XMLEncImpl] einen guten Ausgangspunkt zum Auffinden verfügbarer Implementierungen. Darüber hinaus sollten beim Einsatz asymmetrischer Verschlüsselung als Infrastruktur geeignete Verzeichnisdienste (etwa Public Key Infrastructure, PKI) vorgehalten werden.
Die beiden bisher diskutierten Sicherheitsmechanismen nutzen die Kenntnis der Metastruktur des zu übertragenden Datenstromes aus. Gleichermaßen stellen sie jeweils XML-spezifische Umsetzungen bekannter Verfahren und Ansätze dar, die für den Einsatz im XML-Umfeld adaptiert und optimiert wurden.

Lässt man hingegen dem SOAP-Aspekt der Protokoll-Unabhängigkeit mehr Beachtung zuteil werden, so offenbart sich diese als weiterer vielversprechender Ansatzpunkt für Sicherheitsbetrachtungen.
Zwar dürfte der Nachrichten- und RPC-Transport über das HTTP-Protokoll die bekannteste Verwendung von SOAP sein, jedoch führt die Spezifikation dieses explizit nur als Beispiel ein. Es erscheint daher naheliegend, auf die bekannten und eingeführten Leitungs-Sicherheitsmechanismen - wie den bekannten Secure Sockets Layer zurückzugreifen. Zusätzlich verspricht dieser Ansatz für die Applikation vollkommene Transparenz und daher keinen zusätzlichen Aufwand.

SSL und XML

Der Secure Sockets Layer (SSL)(vgl. [Fre96]) ist ein ursprünglich durch die Firma Netscape entwickeltes - und später durch die Internet-Standardisierung vorangetriebenes - verbindungsorientiertes Protokoll zur sicheren, verschlüsselten Übertragung beliebiger Daten. Es hat aufgrund seiner Applikationsunabhängigkeit große Verbreitung gefunden und wird häufig zum Transport von Web-Inhalten via HTTP oder auch zur Übertragung von E-Mail über das Simple Mail Transfer Protocol (SMTP) eingesetzt. Darüberhinaus wird es durch alle gängigen Web-Browser unterstützt.
Technisch realisiert SSL Sicherheit unter Verwendung symmetrischer Verschlüsselung des kompletten Kommunikationskanals mit vorheriger optionaler wechselseitiger Authentisierung durch die Verhandlung eines gemeinsamen Schlüssels.
Die Realisierung der SSL-Schicht ist unabhängig vom Applikationsprotokoll ausgelegt und wird ihrerseits (wie in Abbildung 2 dargestellt) vom verwendeten Transportprotokoll gekapselt.

Für die Applikation stellt sich der Kommunikationsverkehr dabei unverändert dar, da erst beim Übergang auf die in der Protokollhierarchie tieferliegende Schicht die kryptographische Veränderung der Nutzdateninhalte stattfindet. Daher ergibt sich in der Konsequenz kein Veränderungsbedarf für die SOAP-Sende- und -Empfangsknoten. Jedoch ist diese Aussage dahingehend einzuschränken, dass sie nur für die eigentliche Datenübertragungsphase innerhalb des gesamten Kommunikationsablaufs gilt. Abbildung 1 zeigt die anderen beiden Kommunikationsphasen: Die Verbindungsaufbauphase und die Verhandlungsphase.

SSL-Handshake

Innerhalb der Verbindungsaufbauphase müssen zunächst kryptographische und protokollabhängige Parameter zwischen Client und Server ausgetauscht werden. Dies geschieht durch die beiden Nachrichten ClientHello und ServerHello. Die Hello-Nachrichten spezifizieren zunächst die durch den jeweiligen Kommunikationspartner unterstützte SSL Protokoll-Version.

Darüber hinaus enthält ClientHello eine geordnete Liste der durch den Aufrufer unterstützten kryptographischen Algorithmen in der Reihenfolge der präferierten Verwendung. Überdies können als weitere Parameter Listen unterstützter Schlüsselaustauschalgorithmen und Kompressionsmethoden übermittelt werden.
Die als ServerHello bezeichnete Antwort enthält durch den Server ausgewählte Elemente der Angebotslisten des Aufrufers. Als optionale zusätzliche Nachrichten werden üblicherweise das Zertifikat des Servers, weitere Informationen und Parameter des Schlüsselaustauschs versandt.
Abschließend markiert die durch den Server versandte HelloDone-Nachricht den Übergang in die Verhandlungsphase. Im Falle der Anforderung wird zusätzlich ein Zertifikat übermittelt. Im Anschluss daran erfolgt die Schlüsselübergabe zwischen den Kommunikationspartnern. Ihre inhaltliche Ausgestaltung variiert mit dem verwendeten Schlüsselaustausch-Algorithmus und der gewählten Verschlüsselungsmethode.
Im Rahmen wechselseitiger Berechtigungsprüfung wird anschließend das Server-Zertifikat durch den Aufrufer angefordert. Zusätzlich kann der Client optional die Änderung der durch den Kommunikationspartner erfolgten Auswahl aus den angebotenen Verschlüsselungsalgorithmen beantragen. Der Abschluß der Verhandlungsphase wird durch den Aufrufer in Form der Nachricht Finished signalisiert.
Vor dem ebenfalls durch Finished markierten Abschluss durch den Server kann dieser die vorgeschlagene Änderung des kryptographischen Verfahrens annehmen oder verwerfen.
Wird diese Entscheidung durch den Aufrufer akzeptiert und die ausgetauschten Zertifikate werden wechselseitig als vertrauenswürdig akzeptiert, so ist der SSL-gesicherte Kommunikationskanal etabliert.

Aus dieser Schilderung wird bereits deutlich, dass die unter Sicherheitsgesichtspunkten relevante Periode SSL-gesicherter Kommunikation zeitlich vor dem eigentlichen Datenverkehr angesiedelt ist. Aus diesem Grunde lassen die verfügbaren SOAP-Hochsprachenschnittstellen dieser Zeitspanne kaum Aufmerksamkeit zuteil werden. Daher müssen die notwendigen Schritte zur Durchführung des SSL-Handshakes durch den Anwender implementiert werden.
Das Codefragment in Listing 3 zeigt die wesentlichen Schritte zu Aufbau und Vorbereitung der Kommunikation über eine SSL gesicherte Verbindung

(1)//...
(2)KeyManager []km = null;
(3)TrustManager []tm = {new MyX509TrustManager()};
(4)SSLContext sslContext = SSLContext.getInstance("SSL");
(5)sslContext.init(km,tm,new java.security.SecureRandom());
(6)SSLSocketFactory sf = sslContext.getSocketFactory();
(7)Socket sock=new Socket("alice",443);
(8)SSLSocket sslsock=(SSLSocket)sf.createSocket(sock, "alice", 443, true);
(9)
(10)sslsock.startHandshake();
(11)
(12)X509Certificate[] c = sslsock.getSession().getPeerCertificateChain();
(13)
(14)//Prüfung der Berechtigung und Authentisierung
(15)//Falls Berechtigung erteilt, Speicherung des Zertifikates
(16)//...
(17)KeyStore ks;
(18)//...
(19)ks.setCertificateEntry ("myCert", c[0]);
(20)URL url = new URL("https://alice:443/soap/servlet/rpcrouter");
(21)//unveränderter SOAP-Aufruf ...
(22)
(23)

Listing 3: Umsetzung des SSL-Handshakes mit Java

Essentielle Bedeutung kommt der Behandlung des erhaltenen Zertifikats (in Zeile 14 ff. einzusetzen) zu. Nach Erhalt der Server-Identifikation muss dieses durch den Client auf Vertrauenswürdigkeit geprüft werden. Hierfür sind keine allgemein gültigen Regeln formulierbar, lediglich die Maßgabe, nicht beliebigen Kommunikationspartnern (eigentlich: beliebigen Zertifikaten, der wirkliche Widerpart des Nachrichtenaustausches verbleibt im digitalen Dunkel) a priori zu vertrauen. Dies erhält insbesondere Gewicht dadurch, dass einmal entgegengenommene Zertifikate für alle Kommunikationsansinnen eines Servers Gültigkeit besitzen. Im Allgemeinen sollte ein Zertifikat durch einen vertrauenswürdigen Dritten gegengezeichnet sein, um den versendenden Server überhaupt als Kommunikationspartner für sicherheitsrelevante Daten in Betracht zu ziehen.
Insgesamt offenbart sich die Zusammenarbeit von SSL und SOAP als sinnfällig und applikationsseitig leicht handhabbar. Für den praktischen Einsatz sollten allerdings einige Randbedingungen berücksichtigt werden:

back to top   Welches Verfahren für welche Anwendung?

 

Hinsichtlich der eingangs formulierten fünf Grundforderungen an sichere Kommunikation offenbart sich der SSL-Ansatz durch seine Kombination kryptographischer Verschlüsselung und wechselseitiger Authentisierung als leistungsfähiger Mechanismus zur gleichzeitigen Erfüllung aller definierten Anforderungen.
Im praktischen Einsatz fällt jedoch die inhärente Fokussierung auf wiederholten Nachrichtenaustausch und die damit einhergehende Begünstigung langfristiger SSL-basierter Kommunikationsbeziehungen negativ auf: einerseits durch die dauerhafte Ablage der Zertifikate, die durchaus eine potentielle Sicherheitslücken darstellen können, und andererseits wegen des im Vergleich zu den übertragenen Nutzdaten vergleichsweise aufwendigen Verhandlungsverfahrens.
Insgesamt stellt SSL jedoch wegen seiner Transparenz in Richtung der kommunizierenden Applikation einen interessanten und leicht umzusetzenden Weg dar, der auch nach der Programmentwicklung für einzelne Dienste selektiv verwirklicht werden kann.
Die beiden vorgestellten, direkt auf dem auszutauschenden XML-Datenstrom operierenden Ideen gewährleisten jeweils diejenigen Grundforderungen, die im allgemeinen typisch für diese Algorithmenklasse sind. Dabei generieren die durch XML Encryption berücksichtigten Verschlüsselungsverfahren die Vertraulichkeit der übermittelten Informationen und die XML Signaturen stellen die Berechtigung, Konsistenz, Glaubwürdigkeit sowie die Verbindlichkeit sicher.
Bezogen auf die anzunehmenden Anwendungsfälle empfiehlt sich für Kommunikationsvorgänge, die nicht ausschließlich der kostenfreien Informationsgewinnung - etwa Suchmaschinenanfragen - dienen, generell mindestens die Nutzung digitaler Signaturen, sofern keine sicherheitsrelevanten Daten übertragen werden.
Für vertrauliche Daten aller Couleur sollte auf kryptographische Verfahren zurückgegriffen werden, die die Vertraulichkeit des übermittelten Inhalts hinreichend gewährleisten können. Eine im praktischen Einsatz zu berücksichtigende Randbedingung bildet dabei die Auswahl des einzusetzenden Verschlüsselungsverfahrens. Insbesondere Exportbeschränkungen oder Verwendungsrestriktionen hinsichtlich der zulässigen Schlüssellängen verdienen hier gesonderte eingehende Betrachtung.
Zusätzlich erscheint der integrierte Einsatz von Verschlüsselungs- und Signaturtechniken sinnvoll - das hat nicht zuletzt die heute gängige Absicherung des E-Mail-Verkehrs offenbart.
Jenseits der zunächst offenkundigen Dualität des SSL-basierten Ansatzes zu den XML-spezifischen Techniken lassen sich dennoch Szenarien ausmachen, innerhalb derer ein Einsatz sinnfällig erscheint. Zunächst verlagert sich der Aufwand der physischen Leitungsabsicherung von der Applikation hin zur Netzwerkkomponente. Zusätzlich kann SSL, bei bestehender Infrastruktur, vergleichsweise leicht in bestehende Prozesse integriert werden. Konzeptionell eröffnet sich hierdurch auch der Freiheitsgrad, die angebotene Sicherheit dynamisch auszunutzen oder im Bedarfsfall zu deaktivieren.

back to top   Literatur

 




separator line
Service provided by Mario Jeckle
Generated: 2004-06-07T12:31:02+01:00
Feedback Feedback       SiteMap SiteMap
This page's original location This page's original location: http://www.jeckle.de/secureSOAP.html
RDF metadata describing this page RDF description for this page