Stand der Technik von Sicherheitskonzepten für Software-Anwendungen im Mobil-Bereich

Transkript

1 Stand der Technik von Sicherheitskonzepten für Software-Anwendungen im Mobil-Bereich Martin Herbort, BSc. RWTH Aachen Abstract In einer Zeit, in der es einen Trend hin zu hochgradig verteilten Anwendungen gibt, stellt sich auch die Frage nach der Datensicherheit (security). Speziell Unternehmen, deren Mitarbeiter z.t. durch mobile Geräte (PDAs, Laptops, Smartphones) mit der Firmen-IT verbunden sind, haben ein hohes Maß an Interesse für sichere Kommunikation. Aktuelle Mobilentwicklungsplattformen wie Java ME (Java Platform, Micro Edition, vormals J2ME) und.net Compact Framework unterstützen u.a. die Nutzung von Web Services, welche hier als Haupt-Schnittstelle zwischen der bestehenden Firmensoftware und den mobilen Clients des Außendienstes gesehen werden. Diese Arbeit fasst aktuelle Konzepte aus dem Bereich Web Services insoweit zusammen, als sie für eine sichere Kommunikation zwischen Firmen-IT und Außendienst relevant sind. Zu diesen gehören neue Konzepte nach dem Web Service-Security Standard von OASIS aber auch bewährte Konzepte wie Zertifikate und SSL. Insbesondere wird auf die Sicherung von Inhalten anstelle der zu Grunde liegenden Kommunikationsverbindung eingegangen. Ziel dieser Arbeit ist die Vermittlung eines Verständnisses von Konzepten zur sicheren Datenkommunikation zwischen Firmen-IT und mobilen Clients über eine Web Service-Schnittstelle. Web Service Ein Web Service ist eine offene Software- Schnittstelle, die auf Anfrage eine bestimmte Dienstleistung (Service) erbringt und eine entsprechende Antwort an den Anfrager zurücksendet. Anfrage und Antwort werden als Nachrichten in einem spezifizierten Format gesendet. In der Regel sind Web Services über das Internet für jedermann erreichbar und erfordern somit gründliche Überlegungen bzgl. der Informationssicherheit. Dieser Beitrag entstand im Rahmen des Konferenzseminars "Verlässliche Verteilte Systeme", das im Wintersemester 2005/2006 vom Lehrund Forschungsgebiet Informatik 4 der RWTH Aachen durchgeführt wurde. Ich möchte mich hiermit sehr für die wertvollen Hinweise der beteiligten Reviewer bedanken! Serviceorientierte Architektur Jede Software in einem Geschäftskontext erfüllt bestimmte Aufgaben. Ob eine Software einer serviceorientierten Architektur (SOA) entspricht, entscheidet sich an der Frage, wie die Software diese Aufgaben erfüllt: Falls ihre Kernfunktionen in einzelne, miteinander agierende Dienste (Services) gegliedert ist, folgt der Aufbau der Software einer SOA. Im Gegensatz dazu erfüllt z.b. monolithisch angelegte Software, dieses Kriterium nicht. 1. Einführung Im Rahmen einer Serviceorientierten Architektur stellen Web Services die Infrastruktur für die Kommnikation und den Datenaustausch dar [15]. Ein Unternehmen kann Geschäftsprozesse oder Teile von ihnen derart über ein Netzwerk zur Verfügung stellen, dass Mitarbeiter, Lieferanten oder Kunden Zugriff auf bestimmte, IT-bezogene Leistungen haben. Als Beispiel diene ein Konsumgüterkonzern, dessen Außendienst für die Beschaffung von Aufträgen und auch für die Kundenpflege zuständig ist. Ein konkreter Außendienst-Mitarbeiter fährt in seinem Einzugsgebiet viele verschiedene Kunden an und nimmt Aufträge sowie Stammdatenänderungen des Kunden entgegen. Diese Daten werden oftmals auf einem Laptop, der als Offline-Client des zentralen Systems zum Auftrags- und Stammdatenmanagement agiert, gespeichert und in der Firma mit diesem System verbunden und dort abgeglichen. Ein typisches Problem dieser Vorgehensweise liegt darin, dass z.b. etwaige Stammdatenänderungen (wie Ansprechpartner, Adresse, Kontaktdaten) nicht direkt erfasst und später, zurück in der Firma, vergessen werden. Die Folge ist ein mangelhaft gepflegter Kundenstamm. Der Grund dafür besteht mitunter in der Umständlichkeit der Laptop- Benutzung vor Ort beim Kunden. Deshalb statten immer mehr Unternehmen Ihre Mitarbeiter mit mobilen Geräten wie PDAs (Personal Digital Assistants) und Smartphones aus [1]. Diese sollen es den im Feld operierenden Mitarbeitern ermöglichen, bestimmte Aufgaben (wie die Stammdatenpflege oder die Auftragserfassung) besser oder überhaupt vor Ort online zu erledigen. B-1

2 An dieser Stelle können Web Services sehr gut eingesetzt werden, da es sich um logisch abgeschlossene Aufgaben handelt, z.b. die Änderung des Ansprechpartners im Kunden-Datensatz in der zentralen Datenbank. Da bei Web Services Nachrichten über ein öffentliches Netzwerk geschickt werden (typischerweise das Internet), muss die Kommunikation gegen den Zugriff Dritter abgesichert werden. Sicherheit bezieht sich hier auf die Aspekte Unversehrtheit, Vertraulichkeit und Authentifikation. Dabei stehen jeweils folgende Fragen im Blickpunkt: Unversehrtheit: Kommt die Nachricht exakt so an, wie sie losgeschickt wurde? Vertraulichkeit: Kann der Inhalt der Nachricht auf dem Weg durchs Netzwerk von Dritten eingesehen werden? Authentifikation: Ist mein Kommunikationspartner derjenige, für den er sich ausgibt? Sämtliche zwischen beiden Kommunikationsteilnehmern (hier Außendienst-Mitarbeiter auf der einen und zentrale Firmen-IT auf der anderen Seite) geschickten Nachrichten entsprechen dem SOAP-Standard (Simple Object Access Protocol [20]) und sind in XML-Syntax. Diese werden in der Regel mittels einer HTTP-Verbindung übertragen. Kapitel 2 beschreibt einen naiven Ansatz, bei dem es um die Sicherung der Kommunikationsverbindung geht. Daran anschließend wird in Kapitel 3 ein Ansatz vorgestellt, der sich mit der Verschlüsselung der Kommunikationsinhalte, d.h. der XML-Nachrichten selbst, befasst. Auch die damit verbunden weiteren Maßnahmen (z.b. Kanonisierung von XML-Dokumenten) werden dort erläutert. Kapitel 4 geht auf weiter gehende Konzepte ein. Kapitel 5 beschreibt, inwieweit die vorgestellten Konzepte auf verschiedenen Mobilentwicklungsplattformen bereits umgesetzt worden sind. Eine abschließende Betrachtung wird in Kapitel 6 geliefert. 2. Transportsicherung Unter Transportsicherung versteht man die Absicherung der Kommunikationsverbindung auf der Transportschicht gemäß dem OSI-Referenzmodell [6]. Da Web Services im Allgemeinen über das HTTP-Protokoll angesprochen und genutzt werden, bedeutet Transportsicherung hier Absicherung des HTTP-Protokolls. Es gibt eine etablierte Methode, die dies sicherstellt. Die Idee besteht dabei in der Nutzung des SSL-Protokolls (Secure Sockets Layer) bzw. seines Nachfolgers TLS (Transport Layer Security) [9, 8]. SSL/TLS ermöglicht die gegenseitige Authentifikation von Kommunikationsteilnehmern sowie die Verschlüsselung der Kommunikation. Der Aufbau einer SSL-Verbindung gliedert sich in die folgenden Phasen: 1. Aushandeln der verwendeten Krypto-Algorithmen 2. Zertifikate-basierte Authentifikation und Austausch (basierend auf der Nutzung öffentlicher Schlüssel) eines symmetrischen Schlüssels für die weitere Kommunikation 3. Symmetrische Verschlüsselung der weiteren Kommunikation Der entscheidende Punkt ist der dritte. Weitere Kommunikation bedeutet im Falle der Absicherung des HTTP- Protokolls, dass alle HTTP-Daten symmetrisch verschlüsselt, übertragen und schließlich wieder entschlüsselt werden. Die HTTP-Daten reisen sozusagen huckepack auf der SSL-Verbindung durch das Netzwerk. Man spricht dann auch von einer HTTP-over-SSL-Verbindung, oder HTTPS Anwendung auf die Nutzung von Web Services durch mobile Geraete Heute verbreitete Programmierplattformen und Frameworks für die Mobil-Entwicklung unterstützen Web Services. Siehe hierzu auch Kapitel 5. Abb. 1 zeigt schematisch den Aufbau eines Systems, in dem mobile Clients über das Internet einen Web Service aufrufen. Die Pfeilspitze seitlich des SSL-Kanals kennzeichnet die Aufrufrichtung. Auf Clientseite sind gemäß dem in Kapitel 1 geschilderten Anwendungsfall Laptop-Computer, PDAs und Smartphones zu erwarten. Auf Server-Seite sieht es etwas komplizierter aus. In der Regel sind die eigentlichen diensterbringenden Maschinen andere als diejenigen, die von Außen erreichbar sind. Ein Server, der von einem Client tatsächlich als Ziel eines Web Service-Aufrufs angesprochen wird, heißt Web Service-Endpunkt. Zwischen dem Client und diesem Web Service-Endpunkt besteht eine SSL-geschützte Verbindung. Auf dem weiteren Weg bis hin zum eigentlichen Diensterbringer (z.b. ein Applikationsserver) existieren nur unverschlüsselte Kommunikationskanäle. Daher sind die SOAP- Nachrichten innerhalb dieses Teiles des Firmen-Netzwerks (Intranet) ungeschützt. Sichere Web Service-basierte Anwendungen, die die Übermittlung sehr sensibler Daten erfordern, sind deshalb so nicht zu realisieren. Das Problem besteht darin, dass das SSL-Protokoll nur auf einem Teil der eigentlich zurückzulegenden Strecke eingesetzt werden kann, weil der Großteil der Firmen-IT z.b. durch Firewalls von Außen nicht erreichbar ist. Allgemeiner: Zwischen je zwei Punkten auf dem Weg vom Sender zum Empfänger haben die Nachrichten einen eigenen Sicherheitskontext (Punkt-zu-Punkt Sicherung). Eine Möglichkeit, mit diesem Umstand umzugehen besteht darin, die Geschäftslogik direkt am Web Service-Endpunkt zu platzieren. Auf Grund der Vielzahl B-2

3 Standard-Web-Protokolle (HTTP, SSL, SOAP) Proprietäre Protokolle der Firmen-IT Standard-Web-Protokolle (HTTP, SOAP) Proprietäre Protokolle der Firmen-IT Internet Internet Clients (Laptop, PDA, Smartphone etc.) R SSL-Kanal (HTTP-over-SSL) Web Service- Endpunkt Load-Balancer, Applikationsserver etc. Clients (Laptop, PDA, Smartphone etc.) Web Service- Endpunkt Load-Balancer, Applikationsserver etc. Abbildung 1. Schematische Darstellung der Transportsicherung Die Nachricht Abbildung 2. Schematische Darstellung der Nachrichtensicherung und Komplexität heutiger Geschäftsprozesse sowie aus sicherheitstechnischen Erwägungen ist das jedoch nicht praktikabel. Das folgende Kapitel stellt daher einen anderen Ansatz vor. Bei diesem geht es um das Absichern der Nachricht selbst. Unter Absicherung wird hier Verschlüsselung und digitale Signatur verstanden. 3. Nachrichtensicherung Nachdem im vorigen Kapitel von der Absicherung der Kommunikationsverbindung zwischen einem mobilen Client und einem Web Service-Endpunkt die Rede war, geht es nun darum, zu zeigen, wie SOAP-Nachrichten durch Verschlüsselung und Signatur derart abgesichert werden, dass sie vom Beginn der Übertragung bis zu ihrer endgültigen Verarbeitung in demselben Sicherheitskontext bleiben. Diese Art der Sicherung heißt Ende-zu-Ende Sicherung. Siehe hierzu Abbildung 2. Während bei der Transportsicherung die sichere Übertragung völlig isoliert von den eigentlichen Web Service-Nachrichten betrachtet werden konnte, ist hier das Gegenteil der Fall. Es werden Verfahren und Sicherheitsmerkmale vorgestellt, die inhärent mit den SOAP- Nachrichten verbunden sind. Mit anderen Worten: Sicherheit wird ein Teil der Nachricht selbst. Mit dem Standard Web Services Security [10] (im weiteren WSS) existiert eine Spezifikation, die die Unversehrtheit (integrity), Vertraulichkeit (confidentiality) und Authentifikation (authentication) von SOAP-Nachrichten gewährleisten soll (vgl. Kap 1). Dabei kommt zur Sicherstellung der Unversehrtheit und Authentifikation die digitale Signatur [19] zum Einsatz. Dagegen sorgen Verschlüsselungsverfahren für die Vertraulichkeit [18]. Um die erforderlichen Metadaten abzulegen, wird der SOAP-Header um ein wsse:security-element erweitert. Abb. 3 zeigt die vereinfachte Version einer SOAP- Nachricht zur Stammdatenänderung eines Kundendatensatzes. Ihre Aussage ist: Ändere die Adresse des Kunden <?xml version="1.0" encoding="utf-8"?> <customer> <id>123</id> <address> <street>am Hohlen Berg 25</street> <postcode>40627</postcode> <city>düsseldorf</city> </address> </customer> Abbildung 3. XML-Repraesentation einer Stammdatenaenderung mit der Nummer 123 gemäß der nachstehenden aktualisierten Adressdaten. Eine solche Nachricht könnte ein Außendienstler an seine Zentrale übermitteln, nachdem er beim Kunden die Änderungen in seinen PDA eingegeben hat. Ein entsprechender Web Service hat u. A. die Aufgabe, solche Adressänderungen in die zentrale Kundendatenbank einzupflegen. Wie stellt man sicher, dass nur solche Stammdatenänderungen verarbeitet werden, die von einem dazu befugten Mitarbeiter stammen? Anders gesagt: Wie verhindert man böswillige Manipulationen an sensiblen Daten, auf die über einen Web Service zugegriffen werden kann? Eine mögliche Antwort besteht in der digitalen XML- Signatur. D.h. SOAP-Nachrichten oder Teile von ihnen werden digital unterschrieben. Analog zu einer handschriftlichen Signatur ( Unterschrift ) ist auch eine digitale Signatur einmalig und daher identifizierend. Zusätzlich bietet eine digitale Signatur die Möglichkeit, zu überprüfen, ob eine Nachricht auf dem Weg vom Sender zum Adressaten verändert wurde. Kapitel 3.1 behandelt die Signatur von SOAP- Nachrichten gemäß dem WSS-Standard. In anderen Anwendungsfällen ist es erforderlich, die B-3

4 Vertraulichkeit von Nachrichten zu wahren. Im Kontext der Tätigkeit eines Aussendienstmitarbeiters ist hier die verschlüsselte Übermittlung von Kundenbestellungen denkbar. Auch hierzu enthält WSS Richtlinien und Empfehlungen. Siehe Kapitel XML-Signatur Grundsätzlich sind für eine Signatur zwei Dinge erforderlich: 1. Prüfsumme der zu unterzeichnenden Daten (digest) 2. Geheimer, digitaler Schlüssel Im Kontext von WSS handelt es sich bei den zu unterzeichnenden Daten entweder um ganze SOAP-Nachrichten oder um einzelne XML-Elemente von ihnen. Die Information darüber, welche Teile der Nachricht signiert wurden, d.h. für welche Daten die Prüfsumme berechnet und verschlüsselt wurde, ist im erweiterten Header abgelegt. Eine digitale Signatur ist das Ergebnis der Verschlüsselung der Prüfsumme der zu unterzeichnenden Daten (siehe Punkt 1) mit einem geheimen, digitalen Schlüssel (siehe Punkt 2). Entscheidend ist hier die Tatsache, dass es eine praktisch unendlich große Anzahl digitaler Schlüssel gibt. Daher existiert eine Abbildung von einem Schlüssel zur Identität seines Eigentümers. Somit kann der Sender von SOAP- Nachrichten zweifelsfrei identifiziert werden. Da eine Signatur zudem eine Prüfsumme repräsentiert, wird sofort sichtbar, wenn die Nachricht auf dem Weg zum Empfänger verändert wurde. Dann nämlich weicht die in der Signatur vorliegende verschlüsselte Prüfsumme von derjenigen Prüfsumme ab, die der Empfänger nach erhalt der Nachricht berechnet. Somit sind die Unversehrtheit signierter Nachrichten sowie die Authentifikation ihrer Absender gewährleistet. Auf die theoretischen Sicherheitsrisiken der Verwendung digitaler Schlüssel wird hier nicht weiter eingegangen. Siehe hierzu z.b. [14] Verifikation der XML-Signatur Die bloße Existenz einer digitalen Signatur innerhalb einer SOAP-Nachricht reicht jedoch nicht aus, um sicherzustellen, dass die Nachricht tatsächlich von einem vertrauenswürdigen Verfasser stammt. Ein vertrauenswürdiger Verfasser ist jemand, der dem Web Service-Anbieter als solcher bekannt ist. Es muss also überprüft werden, ob die Signatur von einem solchen Verfasser stammt. Der damit verbundene Prozess heißt Verifikation der Signatur. Eine Menge von Daten, die der Absender zum Zwecke seiner Authentifikation und somit der Signatur-Verifikation in den Web Service-Aufruf integriert, heißt Sicherheitsmarke (security token). WSS definiert diesbezüglich, wie solche Sicherheitsmarken in SOAP-Nachrichten einzubetten sind. Der Standard gibt jedoch nicht vor, von welchem Typ die Sicherheitsmarken sein müssen. So kann eine angegebene Kombination aus Benutzername und verschlüsseltem Passwort ebenso als Sicherheitsmarke dienen wie ein X.509-Zertifikat [7]. Auch proprietäre Formate sind möglich. Die Verifikation der Signatur erfolgt auf der Seite des Web Service-Anbieters in Abhängigkeit vom Typ der Sicherheitsmarke. Wie dies zu erfolgen hat, wird nicht festgelegt. Im Falle des Einsatzes von Client-Zertifikaten im X.509-Format bedeutet Verifikation der Signatur typischerweise die Authentifikation des Clients anhand des in der Nachricht integrierten Zertifikats. Dieser Prozess gliedert sich wie folgt. 1. Prüfen, ob das mitgelieferte bzw. referenzierte Zertifikat gültig ist. 2. Prüfsumme der signierten Daten berechnen (=Ist- Prüfsumme). 3. Mitgelieferte Signatur mit dem mitgelieferten öffentlichen Schlüssel entschlüsseln (=Referenz-Prüfsumme). 4. Ist-Prüfsumme mit Referenz-Prüfsumme vergleichen. Wenn einer dieser Schritte fehlschlägt, ist die Signatur ungültig. Anderenfalls ist sie gültig. Was im Falle ungültiger Signaturen mit der SOAP-Nachricht zu geschehen hat, hängt vom Anwendungsfall ab. Eine Möglichkeit ist das Ignorieren der Nachricht XML-Verschluesselung Für die Verschlüsselung von XML-Elementen gemäß WSS sind im Wesentlichen zwei Informationen im verschlüsselten Dokument abzulegen: 1. Die verschlüsselten Elemente bzw. Elementinhalte. 2. Informationen über den verwendeten Schlüssel. Man unterscheidet symmetrische und asymmetrische Verschlüsselungsverfahren. Bei der symmetrischen Verschlüsselung wird zum Ver- und Entschlüsseln der gleiche Schlüssel verwendet. Bei der asymmetrischen Verschlüsselung werden jeweils verschiedene Schlüssel eingesetzt. Letztere wird insbesondere in Public-Key Infrastrukturen verwendet. WSS definiert ein generisches Format, mit dem sich verschiedene Teile von Nachrichten mit unterschiedlichen Schlüsseln verschlüsseln lassen. Dies ermöglicht es, dass B-4

5 <?xml version="1.0" encoding="utf-8"?> <order> <cust_id>123</cust_id> <order_items> <order_item> <item_id>48</item_id> <count>2</count> </order_item> <order_item> <item_id>57</item_id> <count>12</count> </order_item> </order_items> <payment_info allowanceuntil=" " termofpayment=" "> <debit> <account_no> </account_no> <bank_code> </bank_code> </debit> </payment_info> </order> Abbildung 4. Bestellung in XML Nachrichten, die ein Client von Außen schickt, von immer demselben Web Service-Endpunkt entgegen genommen werden, jedoch von verschiedenen Instanzen im Firmennetzwerk abgearbeitet werden können mit der Eigenschaft, dass jede beteiligte Instanz nur den für sie bestimmten Teil der Nachricht einsehen kann. Abb. 4 zeigt eine Bestellung im XML-Format. Oft sind in Unternehmen verschiedene Stellen für Fakturierung und Abrechnung einer Bestellung verantwortlich. Solche Bestellungen sind in der Regel vor der Öffentlichkeit geheim zu halten. Weiterhin ist die Fakturierungsabteilung nur daran interessiert, zu wissen, welcher Kunde welche Waren in welcher Menge erhält. Dagegen braucht die Rechnungsabteilung nur die Daten über die Rechnungssumme und Zahlungsmodalitäten. Daher bietet es sich hier an, das order_items-element mit einem und das payment_info- Element mit einem anderen Schlüssel zu verschlüsseln. Die feingranulare Nutzung von XML-Verschlüsselung stellt demnach sicher, dass jede Information nur an den zuständigen Stellen gelesen werden kann Kanonische XML-Formen Es existiert zu jedem XML-Dokument eine unendliche Anzahl weiterer, formal unterschiedlicher XML- Dokumente, die bezüglich der relevanten Informationen äquivalent sind. Z.B. ändert sich die Semantik eines XML- Elements durch Vertauschung von Attributen nicht. Abb. 5 zeigt die Struktur einer Bestellung im XML-Format. Sie unterscheidet sich von der Bestellung aus Abb. 4 in der Rei- <?xml version="1.0" encoding="utf-8"?> <order> <cust_id>123</cust_id> <order_items> <order_item> <item_id>48</item_id> <count>2</count> </order_item> <order_item> <item_id>57</item_id> <count>12</count> </order_item> </order_items> <payment_info termofpayment=" " allowanceuntil=" "> <debit> <account_no> </account_no> <bank_code> </bank_code> </debit> </payment_info> </order> Abbildung 5. Alternative, aequivalente Bestellung henfolge der Attribute im payment_info-element. Der Informationsgehalt ist jedoch der gleiche. In beiden Fällen ist klar, bis wann der Kunde spätestens bezahlen muss und bis wann ihm ein Skonto gutgeschrieben wird. Bezogen auf die XML-Signatur macht es jedoch einen Unterschied, welches Dokument der Empfänger der Bestellung erhält. Es könnte z.b. sein, dass der XML-Serialisierer des Senders alle Attribute eine Elements in alphabetischer Reihenfolge ausgibt, der XML-Parser des Empfängers jedoch in umgekehrt alphabetischer Reihenfolge. Dann würde die Ist-Prüfsumme von der Referenz-Prüfsumme immer abweichen (siehe Kap. 3.2), d.h. die Verifikation der Signatur schläge fehl, obwohl die empfangene und die gesendete Bestellung semantisch identisch sind. Daher ist es entscheidend, dass unmittelbar vor der Signatur und unmittelbar vor deren Verifikation, das zu signierende bzw. signierte XML-Dokument in einer eindeutigen, d.h. kanonischen Form vorliegt. Es gibt verschiedene Varianten der Kanonisierung. Diese unterscheiden sich hinsichtlich der Behandlung von XML-Namespace- Deklarationen und XML-Kommentaren. WSS empfiehlt die XML-Kanonisierung gemäß [17]. Die Nutzung kanonischer XML-Formen erlaubt also technologische Freiheiten auf beiden Seiten des Kommunikationskanals. B-5

6 3.5. Bewertung Die beschriebenen Verfahren zeigen, wie es gelingen kann, dass Nachrichten auf dem Weg vom Sender zum Adressaten in demselben Sicherheitskontext verbleiben. Für die Kommunikationsstruktur von Unternehmen bedeutet dies, dass eine Sicherung auf Transportebene, wenn überhaupt, ein zusätzlicher aber kein notwendiger Sicherheitsfaktor ist. Dies erleichtert eine Migration hin zu serviceorientierten Architekturen. Es können zur Nutzung von Web Services Standard-Protokolle wie HTTP verwendet werden. Dies trifft auch für Dienste zu, die die Übermittlung sensibler Daten wie z.b. Stammdaten erfordern. Der Web Services Security-Standard stellt ein kompaktes Rahmenwerk für XML-Signatur und XML- Verschlüsselung dar. Dennoch bietet er Spielraum für unternehmenseigene Sicherheitsrichtlinien. So wird beispielsweise das Format von Sicherheitsmarken festgelegt (siehe Kap. 3.2), nicht jedoch, wie diese verarbeitet werden. Auch sind Nachrichten denkbar, deren einzelne Teile mit verschiedenen Schlüsseln signiert oder verschlüsselt werden (siehe Kap. 3.3). Die bloße Einhaltung eines Standards garantiert jedoch noch keine Datensicherheit. So müssen auch die hier vorgestellten Techniken im Kontext anderer Sicherheitsmechanismen verstanden werden. Auch bedingt der Einsatz einiger Techniken die Einbeziehung anderer Verfahren. Z.B. setzt die Anwendung digitaler Signaturen die Gültigkeitsprüfung von Zertifikaten voraus. Im Folgenden werden einige mögliche Sicherheitslöcher angesprochen. Wiederholtes Senden Das wiederholte Senden der gleichen Nachricht (Replay-Attacke) kann sicherheitskritisch sein, z.b. ein Web Service-Aufruf, der das Abbuchen eines Rechnugsbetrages von einem Kundenkonto bewirkt. Daher sollten SOAP-Nachrichen einen Zeitstempel oder etwas Vergleichbares beinhalten, z.b. eine Sequenznummer oder einen Gültigkeitszeitraum. Da auch ein Zeitstempel manipulierbar ist, kann man die Signatur auf einen solchen ausdehnen. Unverschlüsselte Signatur Eine Angriffsfläche entsteht durch den nicht-durchdachten Einsatz von XML-Signatur und XML-Verschlüsselung. Wenn SOAP-Nachrichten zwar verschlüsselt sind, die Signatur aber unverschlüsselt übertragen wird, sind Klartext-Rate-Attacken denkbar. Ein Angreifer generiert zufällig Nachrichten und vergleicht die eigene mit der mitgeschickten Prüfsumme. Ersetzung von Öffentlichen Schlüsseln Auf dem Weg einer Nachricht vom Sender zum Empfänger könnte ein Dritter einen mitgelieferten öffentlichen Schlüssel, den der Empfänger zur Verschlüsselung der Antwort nutzen soll, durch einen anderen Schlüssel ersetzen. Die Antwortnachricht könnte der Angreifer somit entschlüsseln. 4. Weitere Konzepte 4.1. WS*-Standards Die Gemeinde rund um den Web Services Security- Standard (WSS), der bereits von OASIS (Organization for the Advancement of Structured Information Standards) offiziell verabschiedet wurde, arbeitet aktuell an weiteren Standards, die WSS erweitern bzw. darauf aufsetzen. Jeder dieser sogenannten WS*-Standards stellt wie auch WSS einen Baustein dar. Aus diesen Bausteinen lassen sich eine ganze Reihe unterschiedlicher Sicherheitsmodelle konstruieren. Jeder WS*-Standard bietet allerdings auch eine Angriffsfläche für Dritte. Diesbezüglich wird auf die jeweilige Spezifikation verwiesen. Nachdem im vorhergehenden Kapitel das Hauptaugenmerk auf der XML-Verschlüsselung und XML-Signatur lag, werden in den folgenden Abschnitten diese Basis- Mechanismen in einen größeren Zusammenhang gestellt. Die Beschreibung einiger weiterer WS*-Standards hat das Ziel, zu zeigen, wie aus den einzelnen Bausteinen Sicherheitsmodelle zusammengebaut werden können, die sich an die konkreten Sicherheitsanforderungen einer spezifischen Geschäftsanwendung anpassen lassen. Beispiele hierzu sind im Anhang zu finden (Abschnitt 7). Web Services-Policy (WS-Policy) Die Nutzung Web Service-basierter Geschäftsanwendungen setzt typischerweise voraus, dass sich der Aufrufer an bestimmte Richtlinien hält. Diese Richtlinien (policies) können sicherheitsbezogene und andere Bedeutung haben. Z.B. kann ein Web Service zur Stammdatenänderung die Nutzung von Kerberos zur Signatur und Verschlüsselung voraussetzen. Auch könnte festgelegt werden, welche Teile einer SOAP- Nachricht zu signieren und zu verschlüsseln sind. Die Familie der WS-Policy-Standards [2] definiert ein generisches Modell zur Zusammenstellung von Aussagen (policy assertions), um Anforderungen, Fähigkeiten und Verhalten von Web Services auszudrücken. Das Vokabular von Aussagen wird in separaten, domänen-spezifischen Standards festgelegt. Z.B. werden Vokabular und Grammatik sicherheitsrelevanter Aussagen im WS-SecurityPolicy-Standard [4] spezifiziert. Web Services-Trust (WS-Trust) In den bisherigen Beispielen wurde von einem Web Service ausgegangen, der selbst die Authentifikation seiner Nutzer durchführt (siehe Abb. 6). Um die Verantwortlichkeiten für Authentifi- B-6

7 Requester R Web Service soapresponse := soaprequest (identity, requestdata) Abbildung 6. Web Service mit eigener Authentifikation Security Token Service R Requester st := requestsecuritytoken (identity) R Web Service soapresponse := soaprequest (st, requestdata) Abbildung 7. Web Service mit separater Authentifikation kation und Dienst-Erbringung sauber voneinander zu trennen, kann man in der Kommunikationsinfrastruktur einen separaten Web Service vorsehen, dessen einzige Aufgabe die Authentifikation der Nutzer der eigentlichen Geschäfts- Web Services ist (siehen Abb. 7). Für dieses und andere, komplexere Szenarien bietet der Standard Web Services-Trust (WS-Trust) [5] eine Grundlage. Er spezifiziert ein Modell für direkte und indirekte Vertrauensbeziehungen (trust relationships). Weiterhin stellt er die Basis für die Implementierung von Web Services zur Ausstellung von Sicherheitsmarken (security token issuance services) dar. Ein Aufrufer, der einen Web Service nutzen will, der eine gültige Sicherheitsmarke verlangt, muss sich zuerst eine solche Marke von einem Ausstellungsservice für Sicherheitsmarken holen. Web Services-SecureConversation (WS- SecureConversation) Oftmals werden im Rahmen der Nutzung eines Web Services mehrere Nachrichten hin und hergeschickt. Im bislang vorgestellten Modell für Web Service-Sicherheit wurde jede Nachricht einzeln abgesichert. Die Gefahr von Replay-Attacken ist einer der Gründe, warum Sicherheitsmarken nicht mehrfach verwendet werden sollten. Um für den Zeitraum des Austauschs mehrerer Nachrichten nicht für jede Nachricht neue Sicherheitsmarken benutzen zu müssen, sind Sicherheitskontexte nötig. Der Standard Web Services-SecureConversation (WS-SecureConversation) [3] definiert, wie solche Sicherheitskontexte eingerichtet werden, innerhalb derer mehrere Nachrichten sicher ausgetauscht werden. Ein Sicherheitskontext (security context) ist ein abstraktes Konzept, dass sich auf einen gültigen Authentifikationsstatus, einen oder mehrere ausgehandelte Schlüssel sowie möglicherweise weitere, sicherheitsrelevante Informationen bezieht. Sicherheitskontexte werden durch spezielle Marken repräsentiert (security context tokens). WS-SecureConversation regelt u.a., wie diese Marken angefordert, referenziert und genutzt werden. Dabei können Vertrauensbeziehungen gemäß WS-Trust (siehe 4.1, Abschnitt Web Services-Trust ) involviert werden. Des Weiteren definiert der Standard, wie aus bereits ausgetauschten Informationen neue Schlüssel abgeleitet werden können (derived keys). Die Besonderheit der Schlüssel- Ableitung besteht darin, dass der Ableitungsprozess auf beiden Seiten (Nachrichten-Sender und -Empfänger) autonom stattfindet. Dies erleichtert die Nutzung symmetrischer Verschlüsselungsverfahren und trägt somit zur Gesamt- Performanz sowie zur Sicherheit des Web Services bei. Zusammenfassung Die drei Standards WS-Policy, WS- Trust und WS-SecureConversation bieten viele Möglichkeiten zur weiteren Absicherung von Web Services. Es handelt sich - wie auch bei WSS - um recht junge Standards, die ihre Eignung im Geschäftsumfeld erst noch belegen müssen (siehe auch Kap. 5). Alle zugehörigen Spezifikationen sind an entscheidenden Stellen um eigene Konzepte erweiterbar (insbes. WS-Policy). Bild 8 stellt die wesentlichen Zusammenhänge und Beziehungen der vorgestellten WS*-Standards (inklusive WSS) grafisch dar Signieren von Programmcode Neben der Nutzung von Web Service-basierten Geschäftsanwendungen gibt es noch weitere Anwendungsfälle für die digitale Signatur. Einer dieser Anwendungsfälle ist die Auslieferung von Anwendungen an die Nutzer. Ab einem gewissen Verteilungsgrad einer Geschäftsanwendung ist es nicht mehr praktikabel, alle Installations-, Wartungsund Aktualisierungsprozesse im Haus von einer bestimmten Abteilung durchführen zu lassen. Dies trifft insbesondere auf Programme zu, die außer Haus auf Laptops und kleineren Mobilgeräten eingesetzt werden. Hier werden Softwareupdates oft automatisch online geladen und installiert. Diese Art der Programmverteilung impliziert gewisse Anforderungen bezüglich der Sicherheit. So muss ähn- B-7

8 WS-SOAP Message Security (WSS) directly extensible by directly extensible by directly extensible by WS-Policy WS-SecurityPolicy WS-SecureConversation WS-Trust contributes to vocabulary of directly extensible by Abbildung 8. Metamodell der WS*-Standards lich der Nutzung von Web Services sichergestellt werden, dass die Daten von einem vertrauenswürdigen Absender stammen. Im vorgestellten Anwendungsfall ist dies meistens die IT-Abteilung der Firma oder ein beauftragter IT- Dienstleister. Ferner muss geprüft werden, dass die Daten unverändert bei den Nutzern ankommen. Aus diesem Grund ist auch hier die digitale Signatur eine mögliches Verfahren, das die gestellten Sicherheitsanforderungen adressiert. Die digitale Signatur von Programmcode wird am Beispiel von Java JAR-Dateien in Kap. 5 schematisch dargestellt. 5. Stand der Technik Neben Laptop-Computern mit Standard- Betriebssystemen spielen Mobilgeräte wie PDAs, Smartphones und andere Kleinstcomputer in Zusammenhang mit mobilen Geschäftsanwendungen eine Rolle (siehe Einführung, Kap. 1). Aufgrund der geringen Größe und dem Bedienkonzept stellen sie eine Alternative zum Laptop- Computer dar. Wie schon in der Einführung erläutert, ist die Bedienbarkeit ein sehr wichtiger Faktor, was die Bedeutung solcher Geräte für mobile Geschäftsanwendungen weiter steigern wird [1]. Diese Geräte laufen unter speziellen Betriebssystemen, die hinsichtlich Ressourcenverbrauch und Funktionsumfang optimiert sind. Die Hauptakteure im Bereich der mobilen Betriebssysteme, die auch eine umfangreiche Programmierplattform anbieten, sind Symbian OS und Microsoft Windows Mobile. Dazu kommen die proprietären Systeme der einzelnen Hersteller. Die folgenden Abschnitte stellen mit Microsofts.NET Compact Framework eine betriebssystemgebundene und mit Java ME eine platformübergreifende Mobilentwicklungsplatform mit Blick auf die Unterstützung der hier vorgestellten Standards und Konzepte vor NET Compact Framework Das.NET Compact Framework (.NET-CF) ist Microsofts Klassenbibliothek für Mobilgeräte. Es stellt ein High- Level-API u.a. für Benutzungsschnittstellen, Kommunikation, und Web Services dar..net-cf ist eine angepasste Untermenge des.net Frameworks für Desktop- und Server-PCs. Es hat somit auch dessen Common Language Runtime (CLR) geerbt, die die Entwicklung funktional identischen Codes mit verschiedenen Sprachen (hauptsächlich Visual Basic.NET und C#) ermöglicht..net-cf wird von Geräten genutzt, die auf dem Betriebssystem Windows CE laufen. Windows CE setzt direkt auf der Hardware-Platform des jeweiligen Geräts auf. Die Nutzung von.net-cf erfordert jedoch eine zusätzliche Abstraktionsschicht. Diese wird durch Windows Mobile realisiert. Eine ihrer wichtigsten Aufgabe ist die Bereitstellung einer Ablaufumgebung für managed code, d.h. Programmcode auf Basis von.net-cf..net-cf ist sehr umfangreich und bietet bei Web Services, die im Fokus dieser Arbeit stehen, viele Möglichkeiten. Diese Komplexität trägt dazu bei, dass Windows- Mobile-Geräte gerade im Vergleich zu Java ME (siehe Kap. 5.2) eine hohe Rechen- und Speicherkapazität benötigen..net-cf bietet neben einem Kryptographie-API für Verschlüsselung, Signatur und Zertifikate auch Untersützung für Programmcode-Signatur (siehe Kap. 4.2). Das Open-Source-Projekt OpenNETCF.org [21] stellt eine Portierung von Microsofts Web Services Enhancements 2.0 für das Compact Framework bereit, das somit Web Service-Standards wie WSS, WS-Policy, WS-Trust, WS- SecureConversation und weitere unterstützt Java Platform, Micro Edition Die Java Platform, Micro Edition (Java ME) von Sun Microsystems ist eine abgespeckte und für den Einsatz auf mobilen Geräten angepasste Version der Java Platform, Standard Edition (vormals J2SE). Somit eignet sie sich zur Programmierung platformübergreifender Mobil-Lösungen. Praktisch alle Hersteller statten Ihre Geräte mit der entsprechenden Java-Laufzeitumgebung aus (Kilobyte Virtual Machine, KVM). Man findet sie auf fast allen aktuellen Handys und PDAs vor. Die Architektur von Java ME gliedert sich hauptsächlich in die folgenden Komponenten: Laufzeitumgebung (KVM) B-8

9 Transportsicherung mit SSL Digitale Signatur von Programmcode Insbesondere für die Sicherung der Kommunikation mit Web Services auf Nachrichtenebene gemäß Kap. 3 bietet Sun noch keine vollwertige, eigene Lösung an. Das optionale Paket SATSA (Security and Trust Services API) bietet jedoch eine Grundlage für Signatur, Verschlüsselung und Zertifikat-Verwaltung (siehe untenstehender Abschnitt über Nachrichtensicherung). Abbildung 9. Java ME im Kontext anderer Java-Technologien (Quelle: [12]) Basisklassen, die die Datentypen und grundlegende Funktionalität implementieren. High-Level APIs für Applikationsmanagement, GUI, Konnektivität und weitere Funktionen Optionale Pakete, z.b. für die Nutzung von Web Services Abb. 9 zeigt den Aufbau der Java ME-Architektur im Kontext anderer Java-Technologien. Nicht alle Java-fähigen Geräte unterstützen Java ME in vollem Umfang. Das hängt damit zusammen, dass die Geräte hinsichtlich der zur Verfügung stehenden Ressourcen sehr unterschiedlich sind. Daher hat Sun die Gesamtfunktionalität der Java ME nach Konfigurationen und Profilen klassifiziert. Eine Konfiguration beschreibt eine Menge von Basisklassen. Für Handys ist z.b. die Connected Limited Device Configuration Version 1.1 (CLDC 1.1) aktuell. Ein Profil definiert im Wesentlichen, welche High-Level APIs unterstützt werden. Hier ist das Mobile Information Device Profile Version 2.0 (MIDP 2.0) Stand der Technik. Geräte werden durch Konfigurationen, Profile und optionale Pakete mit einer maßgeschneiderten Java ME-Umgebung ausgestattet. Dies ist die Grundlage für eine hohe Gesamt- Leistungsfähigkeit, weil Java ME somit der Ressourcen- Knappheit Rechnung trägt Sicherheitsfeatures von Java ME Java ME verfügt standardmäßig über folgende sicherheitsrelevanten Merkmale: Transportsicherung mit SSL Die Absicherung von HTTP-Verbindungen gemäß Kap. 2 gestaltet sich mit Java ME sehr einfach. Listing 1 zeigt einen Code-Abschnitt zum Aufbau einer HTTPS-Verbindung zur URL url. Der Antwort-Code responsecode wird im Hauptformular der Benutzeroberfläche gui dargestellt. Im Falle einer Ausnahme wird die Fehlermeldung in der Benutzeroberfläche dargestellt. Natürlich muss die Java ME-Laufzeitumgebung Zugriff auf die nötigen Stamm-Zertifikate haben, um eine SSL-Verbindung aufbauen zu können. HttpsConnection c = null; InputStream is = null; try { c = (HttpsConnection)Connector.open(url); is = c.opendatainputstream(); int responsecode = c.getresponsecode(); gui.setresponsecode( String.valueOf(responseCode)); } catch(exception ex) { gui.setmessage(ex.tostring()); System.out.println(ex.toString()); } Listing 1. HTTPS-Verbindung mit J2ME Digitale Signatur von Programmcode Um die digitale Signatur von Programmcode (siehe auch Kap. 4.2) in Bezug auf Java ME verstehen zu können, ist ein Grundverständnis von der Form eines Java ME-Programms nötig. Programme auf Basis der Java ME heißen Midlets. Ein kompiliertes Midlet besteht aus einem JAR-Archiv mit dem eigentlichen Programmcode und einer Manifest-Datei, die Metadaten enthält. Die Signatur von Midlets gliedert sich in die folgenden Schritte: Kompilation des Midlets in ein JAR-Archiv und Anlage eines Manifests. Berechnung einer Prüfsumme für das JAR-Archiv. B-9

10 Verschlüsselung der Prüfsumme mit einem geheimen Schlüssel. Eintragung der Signatur in das Manifest. Der verwendete Schlüssel ist in der Regel der private Schlüssel eines Paares aus einem öffentlichen und einem privaten Schlüssel. Zu diesem Paar gehört ein X.509- Zertifikat, das die Gültigkeit der beiden Schlüssel sowie die Identität des Eigentümers des privaten Schlüssels dokumentiert. Die erfolgreiche Verifikation der Signatur auf Empfängerseite setzt die Kenntnis dieses Zertifikats voraus. Der Empfänger kann z.b. ein Außendienst-Mitarbeiter sein, der im Rahmen eines Programmupdates der Kundenverwaltung ein Midlet auf sein PDA herunterläd. Gerade auf geschäftlich genutzten Geräten befinden sich oftmals sensible Daten. Nach dem Java ME-Ansatz werden nur Midlets, die eine gültige Signatur haben, bestimmte Berechtigungen erteilt (siehe [13], Abschnitt Security for MIDP Applications ). Es gibt u.a. Berechtigungen zum Zugriff auf das lokale Dateisystem sowie die Nutzung von Netzwerkverbindungen. So wird z.b. verhindert, dass ein bösartiges Midlet, auf dem Gerät gespeicherte Geschäftsdaten via GPRS an einen Dritten sendet. Nachrichtensicherung Das API, das die Nutzung von Web Services in Java ME erlaubt, heißt JAX-RPC (Java API for XML-based Remote Procedure Calls). Es ist auf einem hohen Abstraktionsniveau angelegt. Dies hat den Vorteil einfacher Programmierung von Web Service-basierten Geschäftsanwendungen. Da man aber wegen dieses Abstraktionsniveau an die eigentlichen SOAP-Nachrichten nicht herankommt, gibt es zunächst keine Möglichkeit, diese Nachrichten oder Teile von ihnen gemäß dem Web Services Security-Standard zu verschlüsseln oder zu signieren (siehe Kap. 3.1). Dagegen existiert mit dem Security and Trust Services API (SATSA) ein Rahmenwerk für Signatur und Verschlüsselung beliebiger Inhalte. Die Nutzung eines anderen SOAP-APIs in Verbindung mit SATSA erscheint als eine praktikable Möglichkeit, WSS auf der Java ME-Platform zumindest teilweise zu implementieren. Diesbezüglich hat der Autor mit der Open-Source SOAP-Implementierung ksoap [11] gute Erfahrungen gesammelt. 6. Zusammenfassung und Ausblick Nach der generellen Motivation zur Anbindung mobiler Clients an eine bestehende IT-Infrastruktur über eine Web Services-Schnittstelle hat diese Arbeit die Konzepte Transportsicherung und Nachrichtensicherung kontrovers diskutiert. Web Service-Aufrufe und Rückantworten passieren auf dem Weg vom Sender zum Empfänger in der Regel einige Zwischenstationen (z.b. Firewalls, Vermittlungsserver). Bei der Transportsicherung befinden sich die Nachrichten zwischen je zwei solcher Zwischenstationen in einem eigenen Sicherheitskontext (Punkt-zu-Punkt-Paradigma). Bei der Nachrichtensicherung dagegen manifestieren sich Sicherheitskonzepte direkt in der SOAP-Repräsentation der Nachricht und erlauben somit einen durchgehenden Sicherheitskontext (Ende-zu-Ende-Paradigma). Zu diesen Sicherheitskonzepten gehören der Web Services Security-Standard (WSS) sowie die WS*-Standards. Der Blick auf die Mobilentwicklungs-Platformen.NET Compact Framework und Java ME hat gezeigt, dass in dieser Domäne bislang allenfalls Basis-Konzepte wie Digital- Signatur, Verschlüsselung und Zertifikate-Management standardmäßig unterstützt werden. Für das Compact Framework existieren jedoch Implementierungen von Dritt- Anbietern für alle vorgestellten WS*-Standards. Es ist davon auszugehen, dass sich die Spezifikationen der insgesamt sehr jungen Standards (Version 1.0 zwischen 2002 und 2004) noch kräftig ändern werden. Grund für diese Annahme ist die schon jetzt hohe Modell-Komplexität sowie die Feststellung, dass die vorgestellten Standards von einem immer sehr kongruenten Personenkreis ausgearbeitet wurden. Erfahrungen und Mitarbeit von Anwendern wird hier vermutlich noch einiges bewirken können. Dennoch bergen die WS*-Standards viel Potential, aus dem zukünftige Mobilentwicklungen schöpfen können, wenn erst einmal umfassende und verlässliche Implementierungen vorliegen. Literatur [1] Mobile workers, mobile consumers, mobile businesses? Technical report, Computer Sciences Corporation (CSC), [2] IBM Corp., Microsoft, Inc. et al. Web Services Policy Framework (WSPolicy), [3] IBM Corp., Microsoft, Inc. et al. Web Services Secure Conversation Language (WS-SecureConversation), [4] IBM Corp., Microsoft, Inc. et al. Web Services Security Policy Language (WS-SecurityPolicy), [5] IBM Corp., Microsoft, Inc. et al. Web Services Trust Language (WS-Trust), [6] International Organization for Standardization. Open Systems Interconnection - Basic Reference Model, [7] International Telecommunication Union, ITU. ITU-T Recommendation X.509, ISO/IEC :2001, [8] The Internet Engineering Task Force, IETF. The TLS Protocol Version 1.0, [9] Netscape Communications. The SSL Protocol Version 3.0, [10] Organization for the Advancement of Structured Information Standards, OASIS. Web Services Security: SOAP Message Security 1.0, [11] Sourceforge. ksoap - a SOAP implementation suitable for J2ME, B-10

11 [12] Sun Microsystems, Inc. Datasheet Java 2 Platform, Micro Edition, [13] Sun Microsystems, Inc. Mobile Information Device Profile 2.0, API Documentation, [14] U.S. Department of Commerce/National Institute of Standards and Technology. Digital Signature Standard (DSS), [15] H. Wöhr. Web-Technologien. dpunkt.verlag GmbH, Heidelberg, [16] World Wide Web Consortium, W3C. XML Path Language (XPath) Version 1.0, [17] World Wide Web Consortium, W3C. Exclusive XML Canonicalization Version 1.0, [18] World Wide Web Consortium, W3C. XML Encryption Syntax and Processing, [19] World Wide Web Consortium, W3C. XML-Signature Syntax and Processing, [20] World Wide Web Consortium, W3C. SOAP Version 1.2 Part 1: Messaging Framework, [21] OpenNETCF.org - A repository for information and shared-source projects specifically targeting the Microsoft.NET Compact Framework, Anhang 7.1. Beispiele zu WS*-Standards In den Beispielen werden XML-Entitäten mit XPath- Ausdrücken [16] adressiert. <?xml version="1.0" encoding="utf-8"?> <wsp:policy xmlns:wsp=" " xmlns:sp=" "> <sp:symmetricbinding > <wsp:policy> <sp:protectiontoken> <wsp:policy> <sp:kerberosv5apreqtoken sp:includetoken =".../IncludeToken/Once"/> </wsp:policy> </sp:protectiontoken> <sp:signbeforeencrypting /> <sp:encryptsignature/> </wsp:policy> </sp:symmetricbinding > <sp:signedparts> <sp:body/> <sp:header Namespace=" "/> </sp:signedparts> <sp:encryptedparts> <sp:body/> </sp:encryptedparts> </wsp:policy> Abbildung 10. WS-Policy Beispiel (Quelle: [4]) Drückt die Anforderung nach einer Kerberos V5-APREQ- Marke aus, die beide Kommunikationsteilnehmer benutzen müssen. sp:signbeforeencrypting Drückt aus, dass zuerst signiert und dann verschlüsselt wird. Es muss also der Klartext signiert werden. WS-Policy Standard. /wsp:policy Abb. 10 zeigt ein Beispiel zum WS-Policy- sp:encryptsignature Drückt aus, dass die Signatur verschlüsselt werden muss. /wsp:policy/sp:signedparts Definiert eine Richtlinie. Alle enthalten Aussagen müssen erfüllt werden, damit die Nutzung des Web Services gestattet wird. /wsp:policy/sp:symmetricbinding Legt fest, dass mit derselben Sicherheitsmarke signiert und verschlüsselt wird. sp:symmetricbinding/wsp:policy Enthält zu erfüllende Aussagen. sp:symmetricbinding/wsp:policy/sp:protectiontoken Drückt die Anforderung nach einer Sicherheitsmarke aus. sp:protectiontoken/wsp:policy Enthält Aussagen zum Typ der Sicherheitsmarke. wsp:kerberosv5apreqtoken Spezifiziert die zu signierenden Teile einer Nachricht. In diesem Fall werden der SOAP-Body sowie alle Header im angegebenen Namespace signiert. /wsp:policy/sp:encryptedparts Spezifiziert die zu verschlüsselnden Teile einer Nachricht (hier also nur der SOAP-Body). WS-Trust Das Beispiel in Abb. 11 zeigt eine SOAP-Nachricht zur Anforderung einer solchen Marke. Dabei transportiert das Element /S11:Envelope/S11:Header/wsse:Security eine Sicherheitsmarke, mit der sich der Nutzer gegenüber dem Ausstellungsservice authentifiziert. /S11:Envelope/S11:Body/wst:RequestSecurityToken enthält (als Sub-Elemente) Informationen über den Typ der angeforderten Marke (wst:tokentype) als auch Informationen zur Anforderung selbst (wst:requesttype). Die zu diesem Aufruf gehörende Antwort enthält eine Sicherheitsmarke zur Verwendung am Web Service für die Geschäftslogik. B-11

12 <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:s11="..." xmlns:wsu="..." xmlns:wsse="..." xmlns:xenc="..." xmlns:wst="..."> <S11:Header> <! > <wsse:security> <xenc:referencelist >...</xenc:referencelist> <xenc:encrypteddata Id="encUsername"> </xenc:encrypteddata> <ds:signature xmlns:ds="..."> <! > <ds:keyinfo> <wsse:securitytokenreference > <wsse:reference URI="#myToken"/> </wsse:securitytokenreference > </ds:keyinfo> </ds:signature> </wsse:security> <! > </S11:Header> <S11:Body wsu:id="req"> <wst:requestsecuritytoken > <wst:tokentype> </wst:tokentype> <wst:requesttype> </wst:requesttype> </wst:requestsecuritytoken > </S11:Body> </S11:Envelope> <?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:s11="..." xmlns:ds="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:wsc="..."> <S11:Header> <! > <wsse:security> <wsc:securitycontexttoken wsu:id="myid"> <wsc:identifier>uuid:...</wsc:identifier> </wsc:securitycontexttoken > <ds:signature> <! > <ds:keyinfo> <wsse:securitytokenreference > <wsse:reference URI="#MyID"/> </wsse:securitytokenreference > </ds:keyinfo> </ds:signature> </wsse:security> </S11:Header> <S11:Body wsu:id="msgbody"> <tru:stocksymbol xmlns:tru=" "> QQQ </tru:stocksymbol> </S11:Body> </S11:Envelope> Abbildung 12. WS-SecureConversation Beispiel (Quelle: [3]) WS-SecureConversation Abb. 12 zeigt die SOAP- Nachricht eines Web Service-Aufrufs. Das Attribut referenziert den Sicherheitskontext MyID ]. Dieser Sicherheitskontext enthält die für die Signatur (hier über den SOAP-Body) verwendeten Informationen. Abbildung 11. WS-Trust Beispiel (Quelle: [5]) B-12