XML und IT-Security
Konzeption einer sicheren Web Services-Infrastruktur
					
	
		©2002
		Diplomarbeit
		
			
				188 Seiten
			
		
	
				
				
					
						
					
				
				
				
				
			Zusammenfassung
			
				Inhaltsangabe:Einleitung:	
Der Siegeszug des Internets in den vergangenen 10 Jahren hatte auch erhebliche Auswirkungen auf die Art und Weise, wie Unternehmensanwendungen heute entwickelt werden. Diese Revolution in der Softwareentwicklung wurde mitbegründet durch die von der Internet Engineering Task Force (IETF) auf den Weg gebrachten Standards. Dazu zählen u.a. HTML, HTTP und XML, ein Internet-Standard zum Austausch von strukturierten Dokumenten.
Web Services machen gerade durch die Nutzung von SOAP einen intensiven Gebrauch von diesen Internet-Standards. Ein Web Service stellt eine Komponente dar, in der spezifische Geschäftsfunktionalitäten gekapselt sind. Diese Funktionalitäten werden über ein Netzwerk, wie dem Internet, anderen Anwendungen oder Komponenten zur Verfügung gestellt, wodurch Transaktionen über Unternehmensgrenzen hinweg abgebildet werden können.
Damit ergeben sich aber auch ganz neue Sicherheitsherausforderungen für die Unternehmen. Web Services basieren zwar auf bestehenden Internet-Technologien, erfordern aber im Vergleich zur Sicherung von Web Sites eine ganz andere Herangehensweise. Trotz dieser unterschiedlichen Herangehensweise können eine Vielzahl von Tools und Technologien, die zur Sicherung von Web Sites verwendet werden, auch für Web Services eingesetzt werden.
Die Klärung und Lösung dieser sicherheitsrelevanten Problemstellungen ist von entscheidender Bedeutung für den erfolgreichen Einsatz von Web Services im EAI-Umfeld.
Gang der Untersuchung:
Ausgehend von Kapitel 2, in dem eine kurze Einführung in die Funktionsweise von Web Services gegeben wird, soll in Kapitel 3 ein konkretes Beispiel-Szenario aufgebaut werden, das durch die sukzessive Lösung von Sicherheitsanforderungen und der Implementierung geeigneter Protokolle und Standards in den nachfolgenden Kapiteln erweitert werden soll.
In Kapitel 4 werden Grundlagen der Internet-Sicherheit dargestellt. Insbesondere werden dabei Sicherheitseigenschaften für Web Services und die Eigenschaften der Internet-Protokollfamilie erarbeitet. Die sich daraus ergebenden Sicherheitsprobleme der Internet-Protokollfamilie sowie deren mögliche Lösung stehen schließlich am Ende der Betrachtung.
In dem Kapitel 5 erfolgt zunächst eine allgemeine Einführung in kryptographische Verfahren, Hashfunktionen und digitale Signaturen. Das Schlüsselmanagement und Fragen der Authentizität und Autorisation bilden den Schlußpunkt dieser Betrachtung. Im Anschluß daran werden XML-basierte […]
	Der Siegeszug des Internets in den vergangenen 10 Jahren hatte auch erhebliche Auswirkungen auf die Art und Weise, wie Unternehmensanwendungen heute entwickelt werden. Diese Revolution in der Softwareentwicklung wurde mitbegründet durch die von der Internet Engineering Task Force (IETF) auf den Weg gebrachten Standards. Dazu zählen u.a. HTML, HTTP und XML, ein Internet-Standard zum Austausch von strukturierten Dokumenten.
Web Services machen gerade durch die Nutzung von SOAP einen intensiven Gebrauch von diesen Internet-Standards. Ein Web Service stellt eine Komponente dar, in der spezifische Geschäftsfunktionalitäten gekapselt sind. Diese Funktionalitäten werden über ein Netzwerk, wie dem Internet, anderen Anwendungen oder Komponenten zur Verfügung gestellt, wodurch Transaktionen über Unternehmensgrenzen hinweg abgebildet werden können.
Damit ergeben sich aber auch ganz neue Sicherheitsherausforderungen für die Unternehmen. Web Services basieren zwar auf bestehenden Internet-Technologien, erfordern aber im Vergleich zur Sicherung von Web Sites eine ganz andere Herangehensweise. Trotz dieser unterschiedlichen Herangehensweise können eine Vielzahl von Tools und Technologien, die zur Sicherung von Web Sites verwendet werden, auch für Web Services eingesetzt werden.
Die Klärung und Lösung dieser sicherheitsrelevanten Problemstellungen ist von entscheidender Bedeutung für den erfolgreichen Einsatz von Web Services im EAI-Umfeld.
Gang der Untersuchung:
Ausgehend von Kapitel 2, in dem eine kurze Einführung in die Funktionsweise von Web Services gegeben wird, soll in Kapitel 3 ein konkretes Beispiel-Szenario aufgebaut werden, das durch die sukzessive Lösung von Sicherheitsanforderungen und der Implementierung geeigneter Protokolle und Standards in den nachfolgenden Kapiteln erweitert werden soll.
In Kapitel 4 werden Grundlagen der Internet-Sicherheit dargestellt. Insbesondere werden dabei Sicherheitseigenschaften für Web Services und die Eigenschaften der Internet-Protokollfamilie erarbeitet. Die sich daraus ergebenden Sicherheitsprobleme der Internet-Protokollfamilie sowie deren mögliche Lösung stehen schließlich am Ende der Betrachtung.
In dem Kapitel 5 erfolgt zunächst eine allgemeine Einführung in kryptographische Verfahren, Hashfunktionen und digitale Signaturen. Das Schlüsselmanagement und Fragen der Authentizität und Autorisation bilden den Schlußpunkt dieser Betrachtung. Im Anschluß daran werden XML-basierte […]
Leseprobe
Inhaltsverzeichnis
ID 6233 
Merz, Thorsten: XML und IT - Security - Konzeption einer sicheren Web Services-
Infrastruktur 
Hamburg: Diplomica GmbH, 2002  
Zugl.: Frankfurt am Main, Universität, Diplomarbeit, 2002 
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, 
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von 
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der 
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, 
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung 
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen 
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik 
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich 
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des 
Urheberrechtes. 
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in 
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, 
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei 
zu betrachten wären und daher von jedermann benutzt werden dürften. 
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können 
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die 
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine 
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen. 
Diplomica GmbH 
http://www.diplom.de, Hamburg 2002 
Printed in Germany
 I
Inhaltsverzeichnis 
INHALTSVERZEICHNIS
...I
ABBILDUNGSVERZEICHNIS
... IV
SOURCE  CODE VERZEICHNIS
... VI
TABELLENVERZEICHNIS
... VIII
ABKÜRZUNGSVERZEICHNIS
... IX
1.
EINLEITUNG...1
2.
WEB SERVICES ...2
2.1 Einführung... 2 
2.2 Definition... 2 
2.3 Eigenschaften, Anforderungen und Nutzenpotentiale für EAI ... 3 
2.4 Implementierung und Aufruf von Web Services ... 6 
3.
DAS BEISPIEL  SZENARIO...7
4.
INTERNET  SICHERHEIT...11
4.1 Einführung... 11 
4.2 Definition... 12 
4.3 Sicherheitseigenschaften... 13 
4.4 Internet  Protokollfamilie ... 16 
4.4.1 Das ISO / OSI  Referenzmodell... 16 
4.4.2 Das TCP / IP  Referenzmodell ... 18 
4.4.3 TCP / IP... 20 
4.4.3.1 Das Internet Protokoll IP... 20 
4.4.3.2 Das Transportprotokoll TCP ... 21 
4.5 Sicherheitsprobleme... 22 
4.5.1 Sicherheitsprobleme von IP... 22 
4.5.2 Sicherheitsprobleme von TCP... 23 
4.6 Absicherung der Internet  und Transportprotokolle ... 24 
4.6.1 SSL / TLS ... 24 
II
4.6.2 IPsec... 25 
4.7 Schlußfolgerung... 26 
5.
XML  SECURITY...29
5.1 Einführung... 29 
5.2 Grundlagen der Kryptographie... 32 
5.2.1 Kryptographische Verfahren ... 32 
5.2.1.1 Symmetrische Verschlüsselungsverfahren... 32 
5.2.1.2 Asymmetrische Verschlüsselungsverfahren ... 35 
5.2.2 Hashfunktionen und digitale Signaturen ... 38 
5.2.2.1 Einführung... 38 
5.2.2.2 Hashfunktionen ... 38 
5.2.2.3 Digitale Signaturen... 40 
5.2.3 Schlüsselmanagement ... 42 
5.2.4 Authentizität und Autorisation... 46 
5.3 XML basierte Sicherheitsstandards und Spezifikationen ... 48 
5.3.1 Einführung... 48 
5.3.2 XML Encryption ... 53 
5.3.2.1 Granulare Verschlüsselung ... 53 
5.3.2.2 Der XML Encryption - Syntax... 54 
5.3.2.3 Die XML Encryption Processing Rules ... 60 
5.3.2.4 Sicherheitserwägungen... 64 
5.3.3 XML Signature... 65 
5.3.3.1 Der XML Signature - Syntax ... 66 
5.3.3.2 Die XML Signature Processing Rules ... 73 
5.3.3.3 Sicherheitserwägungen... 76 
5.3.4 XKMS (XML Key Management Specification)... 78 
5.3.4.1 X-KISS : Das Tier  basierte Service  Modell ... 79 
5.3.4.2 Der X-KISS Syntax... 82 
5.3.4.3 X-KRSS : Der Registration Service... 87 
5.3.4.4 Der X-KRSS Syntax... 88 
5.3.4.5 Sicherheitserwägungen... 92 
5.3.5 XML  basierte Authentizität und Autorisation ... 93 
5.3.5.1 SAML ( Security Assertion Markup Language) ... 93 
5.3.5.2 XACML (eXtensible Access Control Markup Language)... 112 
5.4 Schlußfolgerung... 121 
6.
SOAP - SECURITY EXTENSIONS ...129
6.1 Einführung... 129 
6.2 WS - Security (Web Services Security) ... 130 
6.2.1 Einführung... 130 
6.2.2 Der WS  Security Syntax ... 130 
6.2.3 Integration des XML Signature Syntax ... 133 
6.2.4 Integration des XML Encryption Syntax ... 133 
6.2.5 Sicherheitserwägungen ... 135 
III
6.3 Schlußfolgerung... 136 
7.
ZUSAMMENFASSUNG UND AUSBLICK ...137
ANHANG
... XII
RESSOURCENVERZEICHNIS
... XXXVI
LITERATURVERZEICHNIS
... XXXVII
IV
Abbildungsverzeichnis 
Abbildung 1:   XML  basierte Internet  Komponenten sprechen miteinander.                                        
[Quelle : Stal 2001, S.16] ... 6
Abbildung 2:   Das Beispiel  Szenario : Die IT  Infrastruktur der Firma IQ  Technology                 
[Quelle : Thomas 1999, S.4] ... 8
Abbildung 3:   Das Beispiel  Szenario : Business Partner Connectivity ... 9
Abbildung 4:   Elemente von Sicherheit [Quelle : Rannenberg 2000, S.490] ... 13
Abbildung 5:   Wechselwirkungen zwischen den Sicherheitsforderungen für Webdienste ... 15
Abbildung 6:   Das ISO / OSI  Referenzmodell [Quelle : Nusser 1998, S.10]... 16
Abbildung 7:   Vergleich OSI und TCP / IP Protokollstack [Quelle : Bernert 1999, S.21]... 19
Abbildung 8:   Der TCP / IP Protokollstack [Quelle : Fuhrberg 1998, S.10]... 20
Abbildung 9:   Das Beispiel  Szenario : Einbeziehung von SSL in die Business Partner Connectivity... 27
Abbildung 10: CBC  Modus bei Blockalgorithmen [Quelle : Fuhrberg 1998, S.80] ... 33
Abbildung 11: Triple  DES Operationen [Quelle : Dournaee 2002, S.9] ... 34
Abbildung 12: Die digitale Signatur [Quelle : Fuhrberg 1998, S.93]... 41
Abbildung 13: Hierarchische Struktur der Zertifizierungsstellen [Quelle : Fuhrberg 1998, S.96]... 44
Abbildung 14: HTTP  Authentizitätsmechanismen [Quelle : Kirtland 2002, S.3]... 46
Abbildung 15: Das Beispiel  Szenario :  Darstellung der Sicherheitsspanne und Transaktionsspanne... 48
Abbildung 16: Das Web Services Trust Framework von Entrust [Quelle : Entrust 2002, S.4]... 51
Abbildung 17: XML Encryption : Der Encryptor - Prozeßablauf [Quelle : Dournaee 2002, S.267] ... 62
Abbildung 18: XML Encryption : Der Decryptor - Prozeßablauf [Quelle : Dournaee 2002, S.270] ... 64
Abbildung 19: XML Signature : Die Reference - und Signature Generation... 74
Abbildung 20: XML Signature : Die Reference - und Signature Validation ... 76
Abbildung 21: XKMS : Minimierung der PKI  Komplexität... 78
Abbildung 22: XKMS : ,,XML Signature Verification and Trust" [Quelle : Dournaee 2002, S.334] ... 79
Abbildung 23: XKMS : Der Locate Service [Quelle : Dournaee 2002, S.338]... 80
Abbildung 24: XKMS : Der Validate Service [Quelle : Dournaee 2002, S.341]... 81
Abbildung 25: XKMS : Schlüsselgenerierung und Registration Request ... 89
Abbildung 26: SAML : Das SAML  Domain Modell [Quelle : Maler; Hallam  Baker, 2002, S.7]... 94
Abbildung 27: XACML : Das Data  Flow Modell [Quelle : Godik; Moses 2002, S.16] ... 112
Abbildung 28: XACML : Das Policy - Laguage Modell [Quelle : Godik; Moses 2002, S.18]... 115
Abbildung 29: Das Beispiel  Szenario : Die Grundlagen einer sicheren Web Services  Infrastruktur . 122
Abbildung 30: Das Beispiel  Szenario : Die Trust Context  Komponente                                             
[Quelle : Netegrity 2002, S.2] ... 123
Abbildung 31: Das Beispiel  Szenario : Implementierung der Trust Context -, Trust Service  und 
Trusted XML Messaging  Komponente ... 128
Abbildung 32: Der XML Encryption  Syntax : Darstellung der wichtigsten Elemente und Attribute .. XVI
Abbildung 33: Der XML Signature  Syntax : Darstellung der wichtigsten Elemente und Attribute ...XVII
Abbildung 34: Der X-KISS  Syntax : Darstellung der wichtigsten Elemente und Attribute... XVIII
Abbildung 35: Der X-KRSS  Syntax : Darstellung der wichtigsten Elemente und Attribute ... XIX
V
Abbildung 36: Der SAML  Syntax (I) : Darstellung der wichtigsten Elemente und Attribute ... XX
Abbildung 37: Der SAML  Syntax (II) : Darstellung der wichtigsten Elemente und Attribute ... XXI
Abbildung 38: Der XACML  Syntax (I) : Darstellung der wichtigsten Elemente und Attribute ...XXII
Abbildung 39: Der XACML  Syntax (II) : Darstellung der wichtigsten Elemente und Attribute... XXIII
VI
Source  Code Verzeichnis
Source Code 1:   XML Encryption : Das <EncrytedType> Element ... 55
Source Code 2:   XML Encryption : Das <EncryptionMethod> Element                                            
[Quelle : Dournaee 2002, S.236]... 55
Source Code 3:   XML Encryption : Das <Transforms> Element [Quelle : Dournaee 2002, S.239]... 56
Source Code 4:   XML Encryption : Das <EncryptionProperties> Element ... 57
Source Code 5 :  XML Encryption : Das <ds :RetrievalMethod> Element ... 57
Source Code 6:   XML Encryption : Das <EncryptedKey> Element... 59
Source Code 7:   XML Encryption : Das <AgreementMethod> Element... 60
Source Code 8:   XML Signature : ,,Enveloped, enveloping and detached XML Signature"                 
[Quelle : Dournaee 2002, S.120]... 65
Source Code 9:   XML Signature : Das <Signature> Element ... 66
Source Code 10: XML Signature : Das <SignatureValue> Element... 66
Source Code 11: XML Signature : Das <CanonicalizationMethod> Element                                       
[Quelle : Dournaee 2002, S.123]... 67
Source Code 12: XML Signature : Das <SignatureMethod> Element [Quelle : Dournaee 2002, S.123].. 67
Source Code 13: XML Signature : Das Type  Attribut des <Reference> Elements... 69
Source Code 14: XML Signature : Das <Reference> Element [Quelle : Dournaee 2002, S.149] ... 69
Source Code 15: XML Signature : Das <KeyInfo> Element ... 70
Source Code 16: XML Signature : Das <Object> Element... 71
Source Code 17: XML Signature : Das <Signature> Element in Verbindung mit dem                     
<Manifest> Element [Quelle : Dournaee 2002, S.142] ... 72
Source Code 18: XML Signature : Das <SignatureProperties> Element... 73
Source Code 19: XKMS : Der Locate Service : Der Syntax der Request  und                                
Response  Nachrichten ... 83
Source Code 20: XKMS : Der Validate Service : Der Syntax der Request  und                               
Response  Nachrichten ... 86
Source Code 21: XKMS : Das <AuthServerInfo> - und  <AuthUserInfo> Element ... 88
Source Code 22: XKMS : Der Registration Service (I):: Der Syntax der Request  und                        
Response  Nachrichten ... 89
Source Code 23: XKMS : Der Registration Service (II): Der Syntax der Request  und                    
Response  Nachrichten ... 90
Source Code 24: XKMS : Der Registration Service (III): Der Syntax der Request  und                        
Response  Nachrichten ... 90
Source Code 25: SAML : Das <Conditions> Element... 97
Source Code 26: SAML : Das <SubjectStatement> Element ... 98
Source Code 27: SAML : Das <AuthenticationStatement> Element... 99
Source Code 28: SAML : Das <AuthorizationDecisionStatement> Element ... 100
Source Code 29: SAML : Das <AttributeStatement> Element ... 100
Source Code 30: SAML : Das <Assertion> Element ... 101
VII
Source Code 31 : SAML : Das <Request> Element ... 102
Source Code 32: SAML : Das <Response> Element ... 104
Source Code 33: XACML : Das <Rule> Element ... 116
Source Code 34: XACML : Das <PolicyStatement> Element... 118
Source Code 35 : XACML : Das <PolicySetStatement> Element... 119
Source Code 36: WS  Security : Das <UsernameToken> Element... 131
Source Code 37: WS  Security : Das <BinarySecurityToken> Element... 132
Source Code 38: WS  Security : Das <SecurityTokenReference> Element... 132
Source Code 39: Das Beispiel  Szenario : Das DTD  Schema ,,schema.dtd"...XII
Source Code 40: Das Beispiel  Szenario :  Das XML  Dokument ,,transfer.xml"... XIV
Source Code 41: Das Beispiel  Szenario : Das modifizierte XML  Dokument ,,transfer.xml" (I) ..XXVII
Source Code 42: Das Beispiel  Szenario : Der Locate  und Validate Service der                                   
Trust Services  Komponente (I) ... XXIX
Source Code 43: Das Beispiel  Szenario : Das modifizierte XML  Dokument ,,transfer.xml" (II).XXXII
Source Code 44: Das Beispiel  Szenario : Der Locate  und Validate Service der                                    
Trust Services  Komponente (II) ... XXXIV
Source Code 45: Das Beispiel  Szenario : Die Übermittlung von Authentifizierungsdaten an die           
Trust Context  Komponente ...XXXV
VIII
Tabellenverzeichnis 
Tabelle 1:   SAML : Die Gültigkeit einer Assertion in Abhängigkeit vom <Conditions> Element... 97
Tabelle 2:   SAML : Das <StatusCode> Element und die möglichen Ausprägungen des                         
Value  Attributes ... 104
Tabelle 3:   SAML : Eine Unterscheidung zwischen der dienstgebunden  und der  
informationsgebundenen Sicherheit ... 105
Tabelle 4:   SAML : Sicherheitserwägungen für die SAML  Protocol Bindings ... 109
Tabelle 5:   SAML : Sicherheitserwägungen für die SAML  Protocol Profiles ... 111
Tabelle 6:   XACML : Die ,,Rule truth table" [Quelle : Godik, Simon; Moses, Tim 2002, S.19]... 117
Tabelle 7:   Das Beispiel  Szenario : Die Bedeutung der einzelnen Symbole ... 124
Tabelle 8:   Das Beispiel  Szenario : Die Web Services  gesteuerten Prozesse innerhalb der         
einzelnen Transaktionsschritte ... 127
Tabelle 9:   WS  Security : Das Konzept der Security Token [Quelle : Atkinson; Hada 2002, S.7
]
... 131
Tabelle 10: WS  Security : Das Type  Attribut des <Password> Elements                                     [Quelle 
: Atkinson; Hada 2002, S.11
]
... 132
Tabelle 11: WS  Security : Einordnung der XML Signature und Encryption  Elemente in die          
SOAP - Elementenstruktur... 134
Tabelle 12: Das DTD Schema : Die inhaltliche Bedeutung der einzelnen Elemente... XV
Tabelle 13: Ein Überblick über die verwendeten Namespaces ... XXIV
IX
Abkürzungsverzeichnis
ACL Access 
Control 
List 
AES 
Advanced Encryption Standard 
AH 
IP Authentification - Header 
BPEL 
Business Process Execution Language  
BPMI 
Business Process Management Initiative 
bspw. beispielsweise 
BTP 
Business Transactions Protocol 
bzgl. bezüglich 
CBC 
Cipher Block Chaining 
DES 
Data Encryption Standard
DOS 
Denial of Service 
DSA 
Digital Signature Algorithm 
DTD 
Document Type Declaration 
EAI Enterprise 
Application 
Integration 
ebXML Electronic 
Business 
XML 
engl. englisch 
ESP 
IP Encapsulation Security Payload 
FTP 
File Transfer Protocol 
geg. gegebenenfalls 
HTML 
Hyper Text Markup Language 
HTTP 
Hypertext Transfer Protocol 
HTTPR reliable 
HTTP 
i.S.v. 
im Sinne von 
IETF 
Internet Engineering Task Force 
IIS 
Microsoft Internet Information Server 
insbes. insbesondere 
IP Internet 
Protocol 
IV Initialisierungsvektor 
J2EE 
Java 2 Platform, Enterprise Edition 
L Lieferant 
LDL Logistikdienstleister 
MAC 
Message Authenticate Code 
X
MIME 
Multipurpose Internet Mail Extensions 
OAEP 
Optimal Asymmetric Encryption Padding 
OASIS 
Organisation for the Advancement of Structured Information 
Standards 
PAP 
Policy Administration Point 
PDP 
Policy Decision Point 
PEP 
Policy Enforcement Point 
PGP 
Pretty Good Privacy 
PIP Policy 
Information 
Point 
PKCS 
Public Key Cryptography Standards 
PKI 
Public Key Infrastructure  
PKIX 
Public - Key Infrastructure (X.509) 
POP 
Proof of Possession 
PRP 
Policy Retrieval Point 
ROI Return 
on 
Investment 
RPC 
Remote Procedure Call 
SA Security 
Association 
SHA 
Secure Hash Algorithm 
SigG Deutsches 
Signaturgesetz 
SMTP 
Simple Mail Transfer Protocol 
SOAP 
Simple Object Access Protocol 
SPKI Simple 
PKI 
SSH Secure 
Shell 
SSL Secure 
Socket 
Layer 
TCP 
Transmission Control Protocol 
TLS Transport 
Layer 
Security 
u.a. unter 
anderem 
u.U. unter 
Umständen 
UDDI 
Universal Description, Discovery and Integration 
UDP 
User Datagram Protocol 
URI Uniform 
Resource 
Identifier 
URL Uniform 
Resource 
Location 
W3C 
World Wide Web Consortium 
WS - Routing 
Web Services Routing Protocol 
XI
WS  Security 
Web Services Security  
WSDL 
Web Services Description Language 
WSFL 
Web Services Flow Language 
WS-I 
Web Services Interoperability Organization 
XAML 
Transaction Authority Markup Language 
X-KISS 
XML Key Information Service Specification 
XKMS 
XML Key Management Specification 
X-KRSS 
XML Key Registration Service Specification 
XML eXtended 
Markup 
Language 
XTASS 
XML Trust Assertion Service Specification 
z.B. zum 
Beispiel 
ZS Zertifizierungsstelle 
1. Einleitung 
1 
1. Einleitung 
Der Siegeszug des Internets in den vergangenen 10 Jahren hatte auch erhebliche  
Auswirkungen auf die Art und Weise, wie Unternehmensanwendungen heute entwickelt 
werden. Diese Revolution in der Softwareentwicklung wurde mitbegründet durch die 
von der Internet Engineering Task Force (IETF) auf den Weg gebrachten Standards. 
Dazu zählen u.a. HTML, HTTP und XML, ein Internet  Standard zum Austausch von 
strukturierten Dokumenten. 
1
Web Services machen gerade durch die Nutzung von SOAP einen intensiven Gebrauch 
von diesen Internet  Standards. Ein Web Service stellt eine Komponente dar, in der 
spezifische Geschäftsfunktionalitäten gekapselt sind. Diese Funktionalitäten werden 
über ein Netzwerk, wie dem Internet, anderen Anwendungen oder Komponenten zur 
Verfügung gestellt, wodurch Transaktionen über Unternehmensgrenzen hinweg 
abgebildet werden können. 
,,The  evolution of business on the Internet is putting enterprise functionality 
near the fringes of  the company firewall" 
Damit ergeben sich aber auch ganz neue Sicherheitsherausforderungen für die 
Unternehmen. Web Services basieren zwar auf bestehenden Internet  Technologien, 
erfordern aber im Vergleich zur Sicherung von Web Sites eine ganz andere 
Herangehensweise. Trotz dieser unterschiedlichen Herangehensweise können eine 
Vielzahl von Tools und Technologien, die zur Sicherung von Web Sites verwendet 
werden, auch für Web Services eingesetzt werden. 
2
Die Klärung und Lösung dieser sicherheitsrelevanten Problemstellungen ist von 
entscheidender Bedeutung für den erfolgreichen Einsatz von Web Services im EAI  
Umfeld. 
Ausgehend von Kapitel 2, in dem eine kurze Einführung in die Funktionsweise von 
Web Services gegeben wird, soll in Kapitel 3 ein konkretes Beispiel  Szenario 
aufgebaut werden, das durch die sukzessive Lösung von Sicherheitsanforderungen und 
der Implementierung geeigneter Protokolle und Standards in den nachfolgenden 
Kapiteln erweitert werden soll. 
In Kapitel 4 werden Grundlagen der Internet  Sicherheit dargestellt. Insbesondere  
werden dabei Sicherheitseigenschaften für Web Services und die Eigenschaften der 
Internet  Protokollfamilie erarbeitet. Die sich daraus ergebenden Sicherheitsprobleme 
1
 Vgl. Sun Microsystems, Inc. 1999, S.10  
2
 Vgl. Sundsted 2002, S.1 
2. Web Services 
2 
der Internet  Protokollfamilie sowie deren mögliche Lösung stehen schließlich am 
Ende der Betrachtung. 
In dem Kapitel 5 erfolgt zunächst eine allgemeine Einführung in kryptographische 
Verfahren, Hashfunktionen und digitale Signaturen. Das Schlüsselmanagement und 
Fragen der Authentizität und Autorisation bilden den Schlußpunkt dieser Betrachtung. 
Im Anschluß daran werden XML  basierte Sicherheitsstandards und Spezifikationen 
dargestellt und mit den zuvor beschriebenen Sicherheitskonzepten in Verbindung 
gebracht. 
Die SOAP  Security Extensions werden in Kapitel 6 vorgestellt und bilden den 
Abschluß dieser Arbeit. 
2. Web Services 
2.1 Einführung 
Web Services stellen ein Framework bereit, welches eine dynamische Integration von 
Applikationen und Unternehmen über das Internet ermöglicht. 
Zukünftig können Web Services für den Wachstum der IT  Branche von 
entscheidender Bedeutung sein. Insbesondere die Stagnation im EAI  Bereich könnte 
damit überwunden werden.   
Dem stehen jedoch auch sicherheitsrelevante Fragestellungen gegenüber, die es zu lösen 
gilt. Das Kapitel 2 soll einen Einblick über die Funktionsweise von Web Services 
geben, um darauf aufbauend ein Beispiel  Szenario entwickeln zu können, das durch 
sukzessives Lösen der aufgeworfenen Sicherheitsanforderungen erweitert werden soll.  
2.2 Definition 
Innerhalb dieses Kapitels ist eine Abgrenzung zwischen Enterprise Application 
Integration (EAI) und Web Services erforderlich. 
Web Services können folgendermaßen definiert werden: 
3
,,A collection of functions that are packaged as a single entity and published to the 
network for use by other programs. Web services are building blocks for creating 
open distributed systems, and allow companies and individuals to quickly and 
cheaply make their digital assets available worldwide" 
3
 Vawter; Roman 2001, S.3 
2. Web Services 
3 
Auf der anderen Seite muß noch der Begriff EAI erläutert werden : 
4
,,Enterprise Application Integration combines the technologies and processes that 
enable custom  built and / or packaged business applications to exchange business 
 level information in format and contexts that each understands" 
Letztendlich stellen Web Services aus technologischer Sicht keine grundlegende 
Neuerung im Bereich der verteilten Anwendungsentwicklung dar. Vielmehr können sie 
als natürliche Weiterentwicklung bestehender XML  basierter Lösungen verstanden 
werden, deren Aufgabe in der strukturierten Darstellung sowie dem Austausch und der 
Weiterverarbeitung von Geschäftsdaten bestand. 
2.3 Eigenschaften, Anforderungen und Nutzenpotentiale für EAI 
Durch EAI sollen gerade systemübergreifende Geschäftsprozesse mit Hilfe geeigneter 
Technik derart abgebildet werden, daß alle am Geschäftsprozeß beteiligten Systeme die 
prozeßrelevanten Daten miteinander in geeigneter Form austauschen können und 
insbesondere bezüglich der Daten ein gleiches Verständnis haben.
5
 Bis zur Entwicklung 
von Web Services waren eben diese Integrationstätigkeiten, aufgrund der Heterogenität 
der innerhalb der Unternehmen verwendeten Programmiersprachen und Middleware, 
sehr schwierig. Durch die Nutzung von Web Services ist eine schnelle und 
kostengünstige Integration von Internet / Intranet  fähigen Anwendungen ohne 
Probleme möglich. Als Basis dient SOAP, das Internet  Standards, wie beispielsweise 
XML, für den Austausch von Geschäftsdaten und deren Übermittlung durch HTTP 
verwendet. Diese Standards werden von allen Programmiersprachen, Middleware -  und 
Plattformanbietern unterstützt.  
Aus technologischer Sicht stellen sie also weiterhin XML  basierte Verbindungen zu 
Unternehmen, Anwendungen und Systemdiensten dar. 
6
  Web Services können zum 
einen als Integrationssoftware für unternehmensinterne Anwendungen, zum anderen 
aber auch als eine auf dem Internet  Standard XML basierende Middleware verstanden 
werden, die eine direkte Kommunikation zwischen Applikationen über das Internet 
ermöglicht. Für eine vollständige Integration ist jedoch ein umfassendes Framework 
erforderlich. 
7
4
 Sailer 2001, S.208 
5
 Vgl. Sailer 2001, S. 208 ff. 
6
 Vgl. Vawter; Roman 2001, S.4 ff. 
7
 Vgl. Stal 2001, S.16 
2. Web Services 
4 
Sämtliche von einem Web Service benötigten Daten bzw. Informationen zur 
Durchführung seiner angebotenen Dienste sind entweder direkt Teil des SOAP  
Requests oder Informationen, die innerhalb einer Datenbank verwaltet werden und 
durch den SOAP  Request dem Web Service verfügbar gemacht werden. Web Services 
sind also stets zustandslos (engl. Stateless). Weiterhin enthält ein Web Service alle für 
einen Prozeß relevanten Funktionalitäten und Methoden, um diesen eigenständig in 
konsistenter Weise durchführen zu können. Web Services sind folglich atomar (engl. 
Atomic). 
8
Daraus ergeben sich besondere Erfordernisse an die Sicherheit bzgl. der Übertragung 
und der Informationssicherheit der auszutauschenden XML  Dokumente. 
Eine Web Services - Infrastruktur bezieht eine Vielzahl von heterogenen und verteilten 
Systemen bei der Integration von Geschäftsprozessen ein und kann durch folgende 
Charakteristika beschrieben werden : 
 Dezentralisierte Architektur und Administration 
 Heterogenität bzgl. der Implementationstechnologien 
 Verbindung zu einer Vielzahl von unterschiedlichen Abteilungen und Unternehmen 
 Peer  basierte Architektur 
 ,,Offenheit" der Infrastruktur 
Alle genannten Charakteristika stellen erhebliche Sicherheitsanforderungen und 
Herausforderungen an das gesamte System. 
9
So muß insbesondere bei der Verwendung von Web Services darauf geachtet werden, 
daß bei jeder Form der Integration von Geschäftsprozessen über das Internet bzgl. des 
verwendeten Messaging - Protokolls gewisse Anforderungen zu stellen sind. 
Insbesondere muß auch SOAP einen konsistenten und zuverlässigen 
Kommunikationsmechanismus zwischen den am Datenaustausch beteiligten Parteien 
ermöglichen. 
8
 Vgl. Microsoft Corporation 2002b, S.2 
9
 Vgl. Posts 2002, S.1 
2. Web Services 
5 
Für einen voll funktions - und leistungsfähigen Datenaustausch über das Internet sind 
eine Vielzahl von Mechanismen und Diensten erforderlich, die im einzelnen folgende 
Aspekte betreffen : 
 Authentifikation and Authorization 
 Signatures and Encryption 
 Interest  based routing (publish / subscribe) 
 Message correlation 
 Business process orchestration (workflow) 
 Message content transformation 
 Attachements and MIME encapsulation (packaging) 
Die Servicequalität (engl. Quality of Service) zeichnet sich gerade auch dadurch aus, 
den Sender und Empfänger  Service authentifizieren zu können. Der Ursprung einer 
Nachricht muß genauso nachvollziehbar sein wie die Tatsache, daß jede gesandte 
Nachricht nur einmal empfangen werden kann. Eine fehlerhafte Übertragung muß 
beiden Parteien bekannt gegeben werden können und Nachrichten müssen in der 
gleichen Reihenfolge beim Empfänger eintreffen, wie sie vom Sender verschickt 
wurden. 
10
Inwieweit die bis dahin genannten Sicherheitsanforderungen durch ein geeignetes 
Protokoll  Design erfüllt werden können, wird Gegenstand des Kapitels 4 sein. Dort 
wird dann besonders auf die von SOAP verwendeten Protokolle der Internet  und 
Transportschicht Bezug genommen. 
Bei der Entwicklung von Web Services muß weiterhin darauf geachtet werden, daß 
diese gewisse Kriterien erfüllen, welche sich grundsätzlich nicht sehr von denen 
unterscheiden, die andere Unternehmensanwendungen erfüllen müssen. Dazu zählen 
Fehlertoleranz, Skalierbarkeit und Zuverlässigkeit. Sowohl bei J2EE als auch bei .NET 
laufen Web Services innerhalb von Containern ab, welche die Interaktion mit anderen 
Diensten, Anwendungen und Unternehmen regeln und steuern. Damit können sich 
Unternehmen bei der Entwicklung von Web Services auf ihr Spezialwissen 
konzentrieren und müssen sich nicht um die Integration ihrer Lösung innerhalb einer 
gegebenen Systemlandschaft kümmern. Die Vision geht letztendlich dahin, daß Web 
10
 Vgl. Brown 2002, S.1 ff. 
2. Web Services 
6 
Services sich vollständig selbst beschreiben und bei Bedarf dynamisch miteinander 
interagieren können.
11
2.4 Implementierung und Aufruf von Web Services 
Bei der Implementierung von Web Services sind XML  basierte Komponenten 
erforderlich, die über das SOAP  Protokoll automatisiert Daten austauschen. 
Insbesondere sind Unternehmen und Entwickler via SOAP in der Lage auf Web 
Services zuzugreifen. Für den Aufruf und die Verwendung von Web Services sind 
WDSL und UDDI, zwei spezielle XML  - basierte Standards, von Bedeutung.  
Abbildung 1: XML  basierte Internet  Komponenten sprechen miteinander. [Quelle : Stal 2001, S.16] 
Der Web Service wird zunächst durch den Anbieter in der WDSL beschrieben. Diese 
Detailinformationen werden durch Festschreibung in der UDDI  Registry 
übernommen. Damit ist der  Web Service für Anwendungen verfügbar. Wenn nun eine 
Anwendung über das Internet Informationen abfragen will, erfolgt der Datenaustausch 
und die Einbindung des Web Service unter Verwendung des SOAP  Protokolls. Ein 
SOAP  Client, der mit der anfragenden Anwendung verbunden ist, sucht unter 
Verwendung der UDDI  Registry nach einem geeigneten Web Service. Die UDDI  
11
 Vgl. Vawter; Roman 2001, S.4 ff.  
SOAP - Client 
SOAP - Server
Integrierte 
Applikation, etwa 
Abrechnungssoftware 
Integrierte 
Applikation, 
etwa 
Datenbank 
UDDI - Registry 
3. Das Beispiel  Szenario 
7 
Registry zeigt nun wie dieser Web Service aufgerufen werden kann. Anschließend 
erfolgt der Aufruf des SOAP  Client an den vorgeschlagenen SOAP  Server. 
12
3.  Das Beispiel  Szenario 
Innerhalb dieses Kapitels soll ein Beispiel  Szenario für eine Web Services - 
Infrastruktur aufgebaut werden. Dabei stehen lediglich die für das Thema unmittelbar 
relevanten Inhalte im Mittelpunkt der Betrachtung. In diesem Zusammenhang werden 
folgende Annahmen implizit unterstellt : 
1.) Sicherheitsrelevante Problemstellungen, die unmittelbar den Intranet  Bereich der 
beteiligten Geschäftspartner betreffen, werden ausgeblendet. Es wird demzufolge 
unterstellt, daß alle Geschäftspartner  eine voll funktionsfähige Sicherheitspolitik 
adaptiert haben. Dies betrifft insbesondere die Konfiguration der Firewall, die 
lokalen Authentizitäts - und Autorisationsroutinen und die sichere Aufbewahrung 
von  sensitiven Benutzerdaten. 
2.) Die Web Server sind unter sicherheitskritischen Gesichtspunkten konfiguriert. Dies 
schließt vor allem eine fehlerfreie Konfiguration von Netzdiensten, wie etwa dem 
Domain Name Service (DNS), ein. Nicht benötigte Netzdienste sind deinstalliert, 
um keine unnötigen Angriffspunkte zu liefern. 
Abbildung 2 zeigt eine vereinfachte Darstellung der IT  Infrastruktur der Firma IQ  
Technology. In der Middle Tier wird sowohl von der Implementierung eines konkreten 
Frameworks, wie J2EE oder .NET, als auch von der genauen Verarbeitungsweise 
innerhalb des Web Service - Containers abstrahiert.  
12
 Vgl. Stal 2001, S.16 
3. Das Beispiel  Szenario 
8 
Abbildung 2: Das Beispiel  Szenario : Die IT  Infrastruktur der Firma IQ  Technology                 
[Quelle : Thomas 1999, S.4] 
Innerhalb dieser Infrastruktur wird ein Web Service angeboten, der für die noch zu 
formulierende Aufgabenstellung des Beispiel  Szenarios die benötigte Funktionalität 
bereitstellt. Der Geschäftsprozeß, der durch den Web Service abgebildet wird, enthält 
die gesamten Funktionen, die für die Bestellabwicklung zwischen den beteiligten 
Parteien erforderlich sind. 
Abbildung 3 zeigt alle an dem Geschäftsprozeß beteiligten Parteien. Aus den zuvor 
gemachten Annahmen wird sofort ersichtlich, daß lediglich die durch die Pfeile 
dargestellten Informationsflüsse Gegenstand sicherheitsrelevanter Überlegungen sein 
können. Dies betrifft gerade die Verbindung zwischen den beteiligten 
Kommunikationspartnern und die in den auszutauschenden Geschäftsdokumenten 
enthaltenen Informationen. 
Firewall 
Client Tier 
Middle Tier
Data Tier 
Client 
Client 
Client 
Client 
Client 
Web Server
HTML 
XML
Application Server
EIS 
Systems 
RDBMS 
Legacy 
ERP
Web  
Service 
Container 
3. Das Beispiel  Szenario 
9 
Abbildung 3: Das Beispiel  Szenario : Business Partner Connectivity 
Genau hier findet der Aufruf und die Einbindung des Web Services durch den 
entsprechenden Client sowie der Austausch von Geschäftsdaten mittels SOAP statt. 
Gemäß dem Kapitel 2 impliziert dies aber wiederum die Nutzung von XML, für den 
Austausch von Geschäftsdaten, und deren Übermittlung durch HTTP. Diese beiden 
Teilgebiete sind dann letztendlich Gegenstand von Sicherheitsüberlegungen. Während 
in Kapitel 4 Vorschläge für eine Absicherung der Internet  und Transportprotokolle 
gemacht werden, setzen sich Kapitel 5 und 6 mit neueren Standards und Spezifikationen 
zur Absicherung von XML  Dokumenten und den sogenannten SOAP Security -  
Extensions auseinander. 
Web Server
HTML 
XML
Web  
Service 
Container 
Firma IQ - Technology 
Firewall 
Logistikdienstleister 
(LDL) 
E - Logistic
Zulieferer (L) 
 Firma Hansen 
Firewall 
Firewall 
Client 
Client 
Client 
SOAP  Request via HTTP 
SOAP  Response via HTTP 
HTTP HTTP 
HTTP 
HTTP 
HTTP 
HTTP 
2.
1.
2.  5. 
2. 
5. 
3. 
4. 
  3.  4. 
5.
Web  Service 
Container 
Web  Service 
Container 
3. Das Beispiel  Szenario 
10 
Der durch den Web Service dargestellte Geschäftsprozeß setzt sich aus folgenden 
aufeinander aufbauenden Transaktionen zusammen : 
13
1. Transaktionsschritt : 
 Bedarfsermittlung durch dynamische Lagerbestandsplanung innerhalb des ERP  
Systems der Firma IQ  Technology. 
2. Transaktionsschritt : 
 Automatische Bestellung und Übermittlung der relevanten Daten an den 
entsprechenden Lieferanten und den Logistikdienstleister. 
3. Transaktionsschritt : 
 Durchführung der Bestellung sofern der entsprechende Lieferant in der Lage ist die 
Bestellung auszuführen, d.h. Durchführung einer Verfügbarkeitsprüfung der Ware 
beim entsprechenden Lieferanten. 
4. Transaktionsschritt : 
 Bestellfortschrittskontrolle und gegenwärtiger Ort / Status der verschickten Ware 
beim Logistikdienstleister. 
5. Transaktionsschritt : 
 Automatische Bestandsaktualisierung bei Eintreffen der Ware innerhalb des ERP  
Systems der Firma IQ  Technology. 
 Automatische Buchung / Verrechnung des zu zahlenden Betrags innerhalb des ERP 
 Systems der Firma IQ  Technology sowie deren Transaktionspartner. 
Das XML  Dokument ,,transfer.xml" beinhaltet alle für den vorliegenden 
Geschäftsprozeß relevanten Daten, wobei der Dokumentenstruktur ein gültiges DTD  
Schema ,,schema.dtd" zugrundegelegt sei. Beide Dokumente sind zusammen mit der 
konkreten Ausprägung und Erklärung der einzelnen Elemente und Attribute im Anhang 
dargestellt. 
13
 Diese einzelnen Transaktionsschritte sind in Abbildung 3 durch eine entsprechende Nummerierung der 
Pfeilendungen hervorgehoben. 
4. Internet  Sicherheit 
11 
4.  Internet  Sicherheit 
4.1 Einführung 
Eine der einfachsten Methoden XML  basierte Web Services sicher zu gestalten, ist die 
Möglichkeit, die Verbindung zwischen SOAP - Client und SOAP  Server abzusichern. 
Dafür stehen eine Vielzahl von Technologien bereit, die von Firewall  basierten Rollen 
über Secure Sockets Layer (SSL) bis zu Virtual Private Networks (VPN) reichen. 
14
Durch die Verwendung von Web Services und den damit verbundenen Austausch von 
sensitiven Daten über das Internet, ergeben sich eine Vielzahl von 
Sicherheitsbedrohungen. Diese betreffen, neben dem unautorisierten Lesen und 
Verändern von Daten, auch das Maskieren und Vortäuschen einer falschen 
Absenderidentität. Aus diesem Grund beschäftigt sich das Kapitel 4 mit 
Sicherheitsfragen im Zusammenhang mit den für das Internet festgelegten 
Kommunikationsprotokollen der  Internet  Protokollfamilie. 
15
Hierbei ist es hilfreich, sich mit den Aufgaben und Funktionen, die für die Übertragung 
von Daten zwischen zwei Computern notwendig sind, vertraut zu machen. Diese 
werden in der Regel in Schichten organisiert, wobei jede Schicht für die jeweils 
übergeordnete Schicht spezifische Dienste zu leisten hat.  
Die Regeln zur Steuerung dieser Kommunikation werden unter dem Begriff des 
Protokolls zusammengefaßt. Wenn nun ein Computer mit einem anderen Computer 
Daten austauschen möchte, erfolgt diese Kommunikation derart, daß die jeweils n-te 
Schicht des einen Computers mit der n  ten Schicht des anderen Computers 
kommuniziert. Das dafür verwendete Protokoll wird dann allgemein als Schicht  n  
Protokoll bezeichnet. Dabei werden die Daten von der höchsten Schicht an die nächst 
niedrigere Schicht übergeben, bis die unterste Schicht erreicht ist, die als physikalisches 
Übertragungsmedium bezeichnet wird. Dabei werden die Daten eingekapselt, indem 
von jeder Schicht spezifische Steuerinformationen zu den eigentlichen Nutzdaten 
hinzugefügt werden. 
16
Angefangen mit der allgemeinen Definition eines IT  Systems und dessen 
unterschiedlichen Ausprägungen, beschäftigt sich Kapitel 4.3 mit der Formulierung von 
Sicherheitseigenschaften, die von der sukzessiv zu entwickelnden Web Services  
Infrastruktur zu erfüllen sind.  
14
 Vgl. Microsoft Corporation 2002a, S.2 
15
 Vgl. Eckert 2001, S.39 
16
 Vgl. Fuhrberg 1998, S.5 
4. Internet  Sicherheit 
12 
Kapitel 4.4 gibt einen kurzen Einblick in die Internet  Protokollfamilie. Es wird das 
ISO / OSI  und das TCP / IP  Referenzmodell vorgestellt, wobei der spätere Focus auf 
die Internet  und Transportschicht gelegt wird. Auf der Internetschicht wird das 
Internet Protocol IP und auf der Transportschicht das Transmission Controll Protocol 
TCP in deren grundlegendsten Eigenschaften und Funktionsweisen behandelt. Dort 
werden dann auch mögliche Sicherheitsprobleme aufgezeigt und zugleich 
Lösungsmöglichkeiten vorgeschlagen. 
4.2 Definition 
Für die nachfolgende Betrachtung ist es erforderlich grundlegende Begriffe der IT  
Sicherheit zu definieren. Dabei soll auf die Definition eines IT  Systems im 
allgemeinen und auf den Unterschied zwischen geschlossenen und offenen Systemen 
eingegangen werden.  
Ein IT  System kann folgendermaßen definiert werden : 
17
,,Ein IT  System ist ein geschlossenes oder offenes, dynamisches und 
technisches System mit der Fähigkeit zur Speicherung und Verarbeitung von 
Informationen" 
Geschlossene Systeme bauen dabei auf der Technologie eines Herstellers auf, sind zu 
Konkurrenzprodukten inkompatibel und deren Verbreitung ist auf ein bestimmtes 
räumliches Gebiet und einen bestimmten Teilnehmerkreis beschränkt. Sie werden in 
aller Regel zentral verwaltet und sind homogen. Offene Systeme stellen im Gegensatz 
dazu vernetzte, physisch verteilte Systeme dar, die sich an Standards zum 
Informationsaustausch mit anderen Systemen orientieren. Sie sind also offen in der 
Kommunikation mit anderen Systemen und insbesondere darin gekennzeichnet, daß sie 
dezentral verwaltet werden und sich aus heterogener Hard  und Software 
zusammensetzen. 
18
Innerhalb unserer Betrachtung gehen wir von offenen Systemen aus, die unter 
Verwendung des in dem Beispiel  Szenario beschriebenen Web Service miteinander 
kommunizieren und Daten über das Internet austauschen. 
17
 Eckert 2001, S. 1 
18
 Vgl. Eckert 2001, S.1 ff 
4. Internet  Sicherheit 
13 
4.3 Sicherheitseigenschaften 
Der Begriff Sicherheit soll im Sinne von Sicherheit von Information und 
Kommunikation verwendet werden und sich dabei vorwiegend auf immaterielle 
Schutzgüter und den Schutz vor beabsichtigten Angriffen beziehen. Der so definierte 
Begriff der Sicherheit soll dabei mit dem Begriff Security gleichgesetzt werden. 
Insbesondere stellt dieser Begriff dann auch die Basis für die Sicherheit IT  gestützter 
Geschäftsprozesse, insbesondere von XML  basierten Web Services, dar.
 19
Informationen bzw. Daten sind die zu schützenden Güter von informationssicheren bzw. 
datensicheren Systemen. Unter anderem darf der Zugriff nur durch autorisierte Subjekte 
erfolgen, was durch die Sicherheitseigenschaft der Authentizität zu erreichen ist. 
20
Die Erreichung von Sicherheitszielen birgt jedoch auch einen menschlichen Zwiespalt, 
der in Abbildung 4 dargestellt wird.  
Abbildung 4: Elemente von Sicherheit [Quelle : Rannenberg 2000, S.490] 
19
 Vgl. Rannenberg 2000, S.489 ff. 
20
 Vgl. Eckert 2001, S. 4 ff. 
Ein sehr menschlicher 
Zwiespalt 
 Privatheit 
Die eigene Sphäre und die 
eigenen Güter schützen 
Verbindlichkeit
Vertrauen (bei Partnern) 
gewinnen 
Eine eher technische 
Gliederung 
 Vertraulichkeit 
Informationen nicht an die 
Falschen 
 Integrität 
Keine Verfälschung von 
Informationen 
 Verfügbarkeit 
Kein Ausfall von Ressourcen 
 Zurechenbarkeit 
Keine unerwarteten Aktionen 
Sicherheit
4. Internet  Sicherheit 
14 
Bei der Darstellung dieser Sicherheitsziele beziehe ich mich im folgenden auf Brandt; 
Bonte 2002, S.1 ff. in Verbindung mit Röhrig; Knorr; Noser 2000, S.500 : 
 Verfügbarkeit 
Daten und Funktionen müssen für den autorisierten Benutzer bei Bedarf  bzw. in 
angemessener Zeit verfügbar sein. 
Die Verfügbarkeit kann nicht durch die in Kapitel 5 dargestellten 
Sicherheitsverfahren ermöglicht werden, und stellt daher auch keine Anforderung an 
die noch einzuführenden XML  basierten Sicherheitsstandards und Spezifikationen 
dar. 
 Integrität 
Die Integritätsforderung zielt darauf ab, daß Daten weder absichtlich noch 
versehentlich unbefugt geändert werden können. Sie garantiert damit die Korrektheit 
und Vollständigkeit der auszutauschenden Daten. Kryptographische Verfahren, wie 
beispielsweise Hashfunktionen, stellen eine perfekte Möglichkeit dar, Änderungen 
an der Ursprungsnachricht aufzudecken. Dieser Sachverhalt wird in Kapitel 5.2.2.2 
näher dargestellt. Somit sind XML  basierte Sicherheitsstandards und 
Spezifikationen, wie die XML Signature - Empfehlung oder der XML Encryption - 
Entwurf, in der Lage die Integrität von Daten zu gewährleisten. 
 Vertraulichkeit 
Vertraulichkeit schützt Daten vor unbefugter Kenntnisnahme durch Personen, 
Prozesse o.ä.. Wie wir noch sehen werden verfügen XML  basierte 
Sicherheitsstandards und Spezifikationen über ausgezeichnete Möglichkeiten, die 
Vertraulichkeit sensitiver Daten zu ermöglichen. 
 Zurechenbarkeit 
Diese Sicherheitseigenschaft soll gewährleisten, daß Handlungen den betreffenden 
Individuen zugerechnet werden können. Dies ist indirekt durch die Public  Private 
Key Beziehung bei der Verschlüsselung von sensitiven Daten möglich und auch ein 
wichtiger Einsatzbereich des Schlüsselmanagements, wie der XKMS  
Spezifikation. 
Die Zurechenbarkeitsforderung macht es dem Sender einer Nachricht unmöglich, im 
nachhinein das Senden seiner Nachricht abzustreiten. Man spricht in diesem 
Zusammenhang von der Unabstreitbarkeitsforderung (engl. Nonrepudiation). Der 
Sender einer Nachricht muß also zweifelsfrei nachweisen können, daß er auch 
wirklich die Person ist, die er vorzugeben scheint.  
4. Internet  Sicherheit 
15 
Erfüllt wird die Authentizitätsforderung durch die XML Signature - Empfehlung. In 
diesem Zusammenhang spielt auch die Überprüfbarkeit des Nachrichtenursprungs 
(engl. Proof of Origin) eine wichtige Rolle. Es muß gewährleistet sein, daß die 
Nachricht von einem zweifelsfrei identifizierten Absender stammt, und nicht eine 
Wiedereinspielung einer zuvor übertragenen Nachricht ist. 
21
 Somit sollen 
sogenannte Replay  Attacken  vermieden werden. 
22
Abschließend sei darauf hingewiesen, daß zwischen einigen dieser 
Sicherheitseigenschaften gewisse Wechselwirkungen und Abhängigkeiten bestehen, die 
in Abbildung 5 kurz dargestellt werden. Diese Sachverhalte ergeben sich unmittelbar 
aus den zuvor beschriebenen Sicherheitseigenschaften.  
Abbildung 5: Wechselwirkungen zwischen den Sicherheitsforderungen für Webdienste 
[Quelle : Leung; Nadalin; Rich 2002, S.3] 
In Abbildung 5 wird zur Veranschaulichung der Wechselwirkung bzw. der 
Abhängigkeit zwischen der Nonrepudiation  und der Proof of Origin  Forderung 
bereits auf die Verwendung einer Hashfunktion zur Überprüfung eines ausgetauschten 
Dokuments auf dessen authentischen Ursprung hingewiesen, ein sogenannter Message 
21
 Vgl. Leung; Nadalin; Rich 2002, S.3 
22
 Dieser Sachverhalt wird in Kapitel 5.2 noch einmal aufgegriffen und näher erläutert. Zum jetzigen 
Zeitpunkt ist ein genaues Verständnis dieser Sicherheitsforderung noch nicht erforderlich. 
Nonrepudiation
Proof of Origin
Data Integrity
impliziert 
Die 
Integritätsforderung 
schützt nicht vor 
Replay  Attacken, da 
sie die Daten einer 
Nachricht nur auf 
Vollständigkeit und 
Korrektheit überprüft. 
Ein HMAC ist 
für die Proof of 
Origin  
Forderung, nicht 
jedoch für die 
Nonrepudiation  
Forderung 
ausreichend.  
4. Internet  Sicherheit 
16 
Authentification Code (MAC) bzw. HMAC.
23
 Dieses Konzept wird jedoch erst in 
Kapitel 5.2.2 näher betrachtet, und ist für das jetzige Verständnis noch nicht 
erforderlich. 
4.4 Internet  Protokollfamilie 
4.4.1 Das ISO / OSI  Referenzmodell 
Das Open System Interconnection (OSI) Referenzmodell wurde Ende der siebziger 
Jahre durch die International Standardization Organization (ISO) geschaffen, um eine 
Vereinheitlichung, der vielen verschiedenen bis dahin entstandenen Protokolle und 
Techniken zur Vernetzung von Computern, zu ermöglichen. Das Ziel dieser 
Vereinheitlichung bestand also darin, durch eine Verwendung von einheitlichen 
Schnittstellen eine Möglichkeit zu schaffen, unterschiedliche Netz  Komponenten von 
verschiedenen Herstellern zusammen einsetzen zu können. Bei der Übertragung von 
Daten durchlaufen diese sieben Schichten, die auf beiden Computern implementiert sein 
müssen. 
24
Abbildung 6 zeigt den genauen Aufbau der Schichten im ISO / OSI  Referenzmodell. 
Abbildung 6: Das ISO / OSI  Referenzmodell [Quelle : Nusser 1998, S.10] 
23
 Vgl. Eckert 2001, S.245 
24
 Vgl. Fuhrberg 1998, S.7 
Anwendungsschicht 
Präsentationsschicht 
Sitzungsschicht 
Transportschicht 
Netzwerkschicht 
Datensicherungsschicht
Bitübertragungsschicht
Anwendungs - 
system 
Transport 
system 
Dienste 
(Dateitransfer, Mail) 
Transformation von 
Daten 
Management virtueller 
Verbindungen 
Transportadressen, Ende 
 zu  Ende- Verbindung 
Wegewahl, Prioritäten 
Zugang, Fehlerkorrektur 
Übertragungsmedium, 
Schnittstellen 
4. Internet  Sicherheit 
17 
Das ISO / OSI  Referenzmodell besteht also aus sieben Schichten, deren Funktionen 
nachfolgend kurz erläutert werden sollen. Dabei folge ich den Ausführungen von 
Bernert 1999, S16 ff. und Nusser 1998, S.9 ff.. 
Die  Bitübertragungsschicht (engl. Physical Layer) stellt die hardwarenächste Schicht 
dar und regelt die physikalische Verbindung auf dem Medium. Sie legt also die 
Eigenschaften des physikalischen Übertragungsmediums und der benötigten 
Steckverbindungen fest. 
Die  Datensicherungsschicht (engl. Data Link Layer) nutzt die Dienste der 
Bitübertragungsschicht, um die Bits zu logischen Einheiten, den sogenannten Frames 
oder Rahmen, zusammenzufassen und zu übertragen. Es beinhaltet also all diejenigen 
Standards, die für die Übertragung von Daten über ein bestimmtes physisches Teilnetz 
benötigt werden. 
Die  Vermittlungs, - bzw. Netzwerkschicht (engl. Network Layer) besitzt als 
Hauptaufgabe die Vermittlung der Pakete zwischen einzelnen Netzwerken, auch 
Routing genannt. Dafür standardisiert sie die Adressierung und die automatische 
Weiterleitung der Pakete über unterschiedliche physikalische Teilnetze hinweg. Darüber 
hinaus regelt sie den Datenfluß auf dem Netzwerk und führt Aufgaben zur 
Überlastungsüberwachung durch. Das Internet Protokoll (IP) gehört zu dieser Kategorie 
der Vermittlungsschicht - Protokolle. 
Die  Transportschicht (engl. Transport Layer) sorgt für eine korrekte Verbindung 
zwischen zwei Computern, und stellt somit den darüberliegenden Schichten eine 
verläßliche Verbindung zur Verfügung. Sie sorgt für eine Korrektur von 
Übertragungsfehlern auf den unteren Schichten und legt Adressen auf Transportebene 
fest. Innerhalb der Internet Protocol Suite (IPS) werden diese Leistungen durch das 
Transmission Control Protocol (TCP) erbracht. 
Die  Sitzungsschicht (engl. Session Layer) verwaltet virtuelle Verbindungen zwischen 
zwei Anwendungen, und ist im TCP / IP  Stack nicht implementiert. Die in diesem 
Bereich enthaltenen Standards üben hauptsächlich Ordnungsfunktionen aus, wie den 
Aufbau und Abbau solcher Verbindungen, den automatischen Abbau einer Verbindung 
nach längerer Inaktivität, oder die Wiederherstellung von Verbindungen nach einer 
Unterbrechung auf einer der unteren Ebenen durch das Setzen von sogenannten 
Synchronisationspunkten. 
Die  Präsentationsschicht (engl. Presentation Layer) standardisiert das Format der 
auszutauschenden Daten auf oberster Ebene. Auf dieser Ebene sollte auch die 
4. Internet  Sicherheit 
18 
Verschlüsselung der Daten stattfinden, wenngleich solche Sicherheitsaspekte in der 
Praxis häufig auf der Anwendungs  oder der Vermittlungsschicht, wie z.B. bei IPv6, 
implementiert werden. Weiterhin soll innerhalb dieser Schicht, gemäß der ISO 
Konvention, eine international gültige Repräsentation von nationalen Zeichensätzen 
angesiedelt sein.  
Die  Anwendungsschicht (engl. Application Layer) beinhaltet anwendungsspezifische 
Funktionen. Sie enthält typischerweise diejenigen Netzwerkfunktionalitäten mit denen 
der Benutzer direkt konfrontiert ist.  
4.4.2 Das TCP / IP  Referenzmodell 
Wie der Begriff TCP / IP  Referenzmodell veranschaulicht, spielen TCP und IP eine 
zentrale Rolle innerhalb dieses Referenzmodells. Der Großteil der Internet  Dienste 
nutzt diese beiden Netzwerkprotokolle als Grundlage. Die darauf aufbauenden 
Protokolle der Anwendungsebene werden in diesem Zusammenhang oft auch als 
Protokollfamilie TCP / IP oder TCP / IP Protokollsuite bezeichnet.  
Bei der Entwicklung des TCP / IP  Stacks wurde das Ziel verfolgt, Computer 
unterschiedlicher, paketorientierter Netzwerke miteinander zu verbinden.
25
Daraus resultierten die wichtigsten Charakteristika der Protokollfamilie TCP / IP : 
26
  Die Protokollfamilie TCP / IP zeichnet sich durch eine Unabhängigkeit vom 
physischen Übertragungsmedium und dem eingesetzten Protokoll auf 
Sicherungsebene aus. 
  Offene Standards, die unabhängig von einer speziellen Hardware oder einem 
bestimmten Betriebssystems entwickelt wurde, stellen die Grundlage der Internet - 
Protokolle dar. 
  Wichtiger Bestandteil der Internet  Protokolle ist ein weltweit einheitlicher 
Adressierungsmechanismus, der eine Rechner - Kommunikation über das 
Netzwerk, mit jedem Rechner der über einen Internet  Anschluß verfügt,  
ermöglicht. 
  Die Protokollfamilie TCP / IP besteht aus zahlreichen Protokollstandards der 
Anwendungsebene, welche eine konsistente Grundlage für die gängigsten Internet 
 Dienste, wie beispielsweise FTP für den elektronischen Dateitransfer oder 
SMTP für den E  Mail Versand, bereitstellen. 
25
 Vgl. Nusser 1998, S.11 ff. 
26
 Nusser 1998,  S.12 ff. 
4. Internet  Sicherheit 
19 
Abbildung 7: Vergleich OSI und TCP / IP Protokollstack [Quelle : Bernert 1999, S.21] 
Der konzeptionelle Unterschied der beiden in der Abbildung 7 dargestellten Modelle 
besteht letztendlich darin, daß das OSI  Modell aus Schichten und das TCP / IP  
,,Modell" aus Protokollen besteht. Damit kann mit dem TCP / IP  ,,Modell" kein 
anderer Protokollstapel als der eigene beschrieben werden. 
27
Dadurch, daß im TCP / IP  ,,Modell" die Anwendungsschicht direkt auf der 
Transportschicht aufsetzt, also keine ausgleichende Zwischenschicht vorhanden ist, 
wirken sich damit Sicherheitsprobleme der TCP / IP  Protokolle unmittelbar auf die 
Anwendungsprotokolle aus. 
28
 Dieser Sachverhalt wird abschließend in Abbildung 8 
graphisch dargestellt. Graphisch hervorgehobene Protokolle sind für die Verwendung 
des im Beispiel  Szenario beschriebenen XML  basierten Web Services von 
besonderer Bedeutung, und werden daher in den Kapiteln 4.4.3 und 4.4.4 näher 
beschrieben. Dabei sollen zunächst die Eigenschaften und Funktionsweisen dieser 
Protokolle dargestellt werden, um darauf aufbauend Sicherheitsprobleme identifizieren 
zu können. Diese Sicherheitsprobleme werden im Anschluß daran, durch eine 
Absicherung eben dieser Protokolle, eliminiert. 
27
 Vgl. Bernert 1999, S.21 ff. 
28
 Vgl. Eckert 2001, S.44 
Anwendungsschicht
Präsentationsschicht
Sitzungsschicht
Netzwerkschicht
Datensicherungsschicht
Bitübertragungsschicht
 OSI  7 - Schichtenmodell 
Anwendungsschicht 
Internetschicht
Transportschicht
Linkschicht 
 TCP / IP - Stack 
Transportschicht
4. Internet  Sicherheit 
20 
Abbildung 8: Der TCP / IP Protokollstack [Quelle : Fuhrberg 1998, S.10] 
4.4.3 TCP / IP
4.4.3.1 Das Internet Protokoll IP 
Das Internet Protokoll stellt die unterste einheitliche Schicht einer jeden 
Kommunikation über das Internet dar. Wie in Abbildung 7 zu sehen ist,  übernimmt es 
die Aufgaben der Netzwerkschicht und bietet für diese einen paketvermittelnden, 
verbindungslosen Dienst an, der auch als unzuverlässiger Dienst bezeichnet wird, da er 
den Erhalt von Datenpaketen nicht bestätigt. Jedes Datenpaket kann bei der 
Übertragung an das Zielsystem eine Vielzahl von Vermittlungsrechnern durchlaufen 
(engl. Routing). 
Es enthält jedoch weder Maßnahmen zur Gewährleistung der Vollständigkeit der 
gesendeten Pakte bzw. Fragmente noch Mechanismen, die überprüfen können, ob die 
Datenpakete in der gesendeten Reihenfolge oder überhaupt beim Empfänger 
angekommen sind. 
29
29
 Vgl. Eckert 2001, S.45 ff. 
TCP
UDP 
X.25
Ethernet
IP
HTTP
Telnet 
SMTP
FTP
DNS 
Anwendungs  
schicht 
Transport  
schicht 
Internetschicht 
Linkschicht 
4. Internet  Sicherheit 
21 
Gerade durch die verbindungslose Natur des Internet  Protokolls fehlen jegliche 
Spezifikationen zum Verbindungsaufbau (engl. Handshake) oder zur Fehlerkontrolle. 
Eben diese Funktionalitäten werden durch das TCP - Protokoll auf der Transportschicht 
zur Verfügung gestellt, woraus sich gerade der Name der Protokollfamilie TCP / IP 
ergibt.  
Für sicherheitsrelevante Überlegungen sind, wie wir in Kapitel 4.5 noch sehen werden, 
zwei Aspekte von herausragender Bedeutung. Diese betreffen zum einen den genauen 
Aufbau eines IP  Datagramms, insbesondere des IP  Headers, zum anderen aber auch 
den Vorgang der Routenwahl. 
30
4.4.3.2 Das Transportprotokoll TCP 
Das Transportprotokoll TCP setzt auf dem IP  Protokoll auf und stellt ein 
verbindungsorientiertes Protokoll dar, das immer dann angewendet wird, wenn 
Empfänger und / oder Absender eine zuverlässige Übertragung möchten. Dabei nimmt 
TCP eine Verbindung mit dem Empfänger auf, überprüft ob dieser für den 
Datenempfang bereit ist, überträgt daraufhin die Daten, korrigiert evtl. Fehler in der 
Übertragung, wie z.B. fehlende oder defekte Pakete, falsche Reihenfolge usw., und 
beendet die Verbindung gesichert. 
31
Diese Aufgaben stellen gerade die sicherheitskritischen Methoden dar, die in Kapitel 
4.5 näher dargestellt werden sollen. 
Das TCP  Protokoll ist jedoch nicht nur in der Lage eine Ende  zu  Ende  
Verbindung zwischen zwei Endsystemen, sondern auch zwischen einzelnen Prozessen 
und Diensten herzustellen. Zur Identifikation dieser Dienste bzw. 
Kommunikationsendpunkte wird das Port  Konzept verwendet, das unter Verwendung 
von Portmappern auf der Anwendungsebene die Zuteilung von Port  Adressen zu den 
jeweiligen Netzdiensten realisiert. Dabei besitzt jeder allgemein bekannte Netzdienst 
eine eindeutige, ihm zugeordnete Port  Nummer. Der für unsere Betrachtung relevante 
HTTP  Dienst besitzt die Port  Adresse 80, über welche die Verbindung zwischen 
Endsystemen aufgebaut wird. 
32
30
 Vgl. Nusser 1998, S.15 ff. 
31
 Vgl. Bernert 1999, S.59 
32
 Vgl. Eckert 2001, S.48 
4. Internet  Sicherheit 
22 
4.5 Sicherheitsprobleme  
4.5.1 Sicherheitsprobleme von IP 
Für das IP  Protokoll ergeben sich bzgl. der in Kapitel 4.3 eingeführten 
Sicherheitseigenschaften sicherheitsrelevante Problemstellungen. Routing  Angriffe 
können insbesondere die Vertraulichkeit,  Integrität und Verfügbarkeit des IP  
Protokolls gefährden. 
33
 Authentizität 
Das IP  Protokoll vertraut den Angaben in den Adresseinträgen der Pakete. Weder 
Absender noch Empfänger werden authentifiziert, obgleich diese Adressen gefälscht 
werden können, sodaß ein Angreifer in der Lage ist, seine eigenen IP  Pakete 
einzuschleusen. Einer der häufigsten Angriffe im Internet, das sogenannte Address 
Spoofing nutzt eben diese Schwachstelle, indem sich ein Angreifer maskiert und 
dem Kommunikationspartner eine gefälschte Identität vortäuscht. Darauf aufbauend 
werden häufig Denial  of  Service Angriffe gestartet, die einen fremden Rechner 
solange mit ,,künstlich" erzeugten Datenpaketen beschicken, bis dieser aufgrund der 
enormen Last zusammenbricht. Für einen solchen Angriff werden meist 
ungeschützte Ports verwendet, also solche die bespielsweise nicht durch Firewalls 
blockiert sind. Wie wir in Kapitel 6 noch sehen werden kommt diesem Problem 
unter Verwendung von SOAP eine besondere Bedeutung zu. SOAP nutzt HTTP zur 
Übermittlung von Geschäftsdaten, so daß SOAP  Nachrichten als HTTP  Pakete 
getarnt die Firewall ungeprüft durchlaufen können. 
34
 Vertraulichkeit 
Die Nutz  und Verwendungsdaten (IP  Headerdaten) eines IP  Pakets werden 
unverschlüsselt übertragen, so daß auf allen Kommunikationsverbindungen sowie in 
allen Vermittlungsstellen diese mitunter sehr sensitiven Daten im Klartext vorliegen. 
Somit ist ein Angreifer durch eine Verkehrsflußanalyse in der Lage, Zugriffs  und 
Kommunikationsprofile zu erstellen, wodurch die Anonymität der 
Kommunikationspartner nicht mehr gewährleistet sein kann. 
33
 Vgl. Eckert 2001, S.50 ff. 
34
 Vgl. Computer Zeitung 2002a, S.13 
4. Internet  Sicherheit 
23 
 Integrität 
Hashfunktion oder MAC's, zur Überprüfung der Integrität der übertragenden 
Nutzdaten sind kein Bestandteil des Internet  Protokolls IP. Damit ist es für den  
Empfänger eines Nachrichtenpakets nicht möglich unautorisierte Modifikationen zu 
erkennen und geeignete Maßnahmen zur Abwehr der sich daraus ergebenden 
Angriffe zu ergreifen. 
 Verbindlichkeit 
IP  basierte Aktionen sind nicht verbindlich, da die Identifikation des 
Kommunikationspartners nur durch die in den IP  Paketen enthaltene, nicht 
fälschungssichere IP  Adresse erfolgt. Digitale Signaturen bleiben 
unberücksichtigt. 
Es sei jedoch darauf hingewiesen, daß die aktuelle IP  Protokollversion IPv6 um 
spezielle Mechanismen zur Sicherstellung von Vertraulichkeit und Authentizität auf der 
Internetschicht erweitert wurde. Deren Berücksichtigung erfolgt durch Implementierung 
der IPsec  Spezifikation, die für IPv6 verpflichtend ist und in Kapitel 4.6.2 kurz 
betrachtet werden soll. 
35
4.5.2 Sicherheitsprobleme von TCP
Wie wir im vorherigen Kapitel gesehen haben, bietet TCP auf der Transportschicht ein 
geeignetes Medium, um Sicherheitsmaßnahmen, die auf der Internetschicht aufbauen, 
zu realisieren. So bietet das TCP  Protokoll gewisse Sicherheitsmaßnahmen zur 
Identifikation und Authentizität der Kommunikationspartner an, die über die 
fälschbaren IP  Adressen hinausgehen. Sequenzierung, Fehlerkorrektur und 
Flußkontrolle stellen Sicherheitsmaßnahmen für höherliegende Schichten dar und 
sorgen für eine verläßliche Übertragung. Leider reichen diese Maßnahmen jedoch nicht 
aus, um den Ansprüchen des kommerziellen Internet  Einsatzes und damit auch der 
Nutzung von XML  basierten Web Services gerecht werden zu können. 
36
Sequenznummerangriffe unter TCP können die Grundlage für Maskeraden sein durch 
die ein Angreifer dem Empfänger eine falsche Identität vortäuschen kann.  
35
 Vgl. Fuhrberg 1998, S. 18 ff. 
36
 Vgl. Nusser 1998, S.34  
4. Internet  Sicherheit 
24 
Sofern der Angreifer Kenntnis über den aktuellen Zählerstand der Sequenznummer 
besitzt, ist es ihm möglich, die Sequenznummer, die ein System für den nächsten 
Verbindungsaufbau benutzt, mit hoher Wahrscheinlichkeit korrekt zu bestimmen. Dies 
ist nur dadurch möglich, daß die Sequenznummern in aller Regel nicht zufällig generiert 
werden, also keinen Zufallsgenerator verwenden, sondern einen einfachen 32  Bit 
Zähler. 
Weiterhin kann ein Angreifer versuchen, eine bestehende Verbindung zwischen Server 
und Client zu übernehmen, in dem die ursprünglichen Kommunikationspartner 
desynchronisiert werden. Durch einen anschließenden Maskerade  Angriff kann er nun 
die Stelle einer der beiden Partner übernehmen und ist dadurch in der Lage eigene 
Pakete einzuschleusen. Damit sind Protokolle erforderlich, die den gesamten 
Nachrichtentransport absichern. 
37
4.6 Absicherung der Internet  und Transportprotokolle 
4.6.1 SSL / TLS 
Durch die Erweiterung der Transportschicht um Sicherheitsaspekte kann diese der 
Internetschicht Mechanismen bereitstellen, auf welche die Internetschicht aufbauen 
kann. Solche Erweiterungen der Protokollfamilie können damit gerade auch die 
Voraussetzung für sichere Anwendungsprotokolle wie HTTP sein. 
38
Sicherheitsprotokolle auf dieser Schicht bieten eine Ende  zu  Ende Verschlüsselung 
zwischen zwei Kommunikationspartnern, die Daten liegen an den Endrechnern also in 
unverschlüsselter Form vor. Sie stellen anwendungsunabhängige Sicherheitsdienste zur 
Verfügung und können daher beliebige Anwendungsprotokolle um Dienste  zur 
Gewährleistung der Kommunikationsvertraulichkeit, der Datenintegrität und der 
Authentizität von Kommunikationspartnern erweitern.  Dabei ist jedoch zu beachten, 
dass es sich innerhalb unseres Beispiel - Szenarios eigentlich um Punkt  zu  Punkt 
Sicherheitsprotokolle handelt, da diese jeweils nur eine sichere Verbindung zwischen 
zwei bestimmte Transaktionsknoten innerhalb der Wertschöpfungskette jedoch nicht 
direkt zwischen dem Start  und Zielknoten herstellen können.  
37
 Vgl.Eckert 2001, S.58 ff. 
38
 Vgl. Nusser 1998, S.34 
4. Internet  Sicherheit 
25 
Bespiele für sichere Protokolle der Transportschicht sind neben Secure Socket Layer 
(SSL) auch Transport Layer Security (TLS). Das TLS - Protokoll, eine 
Weiterentwicklung des SSL  Protokolls, das insbesondere um das HMAC  Verfahren 
erweitert wurde, bildet einen de facto Standard für die sichere HTTP  Kommunikation. 
Für SSL  basiertes HTTP (HTTPS) wird dafür die Portadresse 443 reserviert. 
Das SSL - Protokoll ermöglicht zum einen die Authentizität der 
Kommunikationspartner unter Verwendung von asymmetrischen 
Verschlüsselungsverfahren und Zertifikaten, zum anderen aber auch eine vertrauliche 
Datenübertragung unter Verwendung eines gemeinsamen Sitzungsschlüssels und die 
Sicherung der Nachrichtenintegrität unter Nutzung von MAC's. Dabei stellen das 
Aushandeln der verwendeten Verfahren sowie der Austausch der benötigten Schlüssel 
einen integralen Bestandteil des SSL  Protokolls dar.  
Die Sicherheit des Protokolls hängt dabei ganz entscheidend von den ausgehandelten 
kryptographischen Verfahren ab.  
Da die zu übertragenden Daten nicht signiert werden, ermöglicht SSL keine 
Gewährleistung der Verbindlichkeit von Aktionen.
39
4.6.2 IPsec 
IPsec erweitert den IP  Header um zwei wichtige Einträge. Der IP Authentification  
Header (AH) ermöglicht eine Sicherung des Datenverkehrs bzgl. Integrität und 
Authentizität auf IP  Ebene. Daten können nicht ohne Verletzung deren Integrität 
unerkannt verändert werden. Weiterhin ermöglicht der IP Authentification  Header  
einen eindeutigen Nachweis über den Absender des IP  Pakets. Die zweite wichtige 
Erweiterung stellt der IP Encapsulation Security Payload (ESP)  Header dar. Dieser 
Header ermöglicht die Übertragung von Daten, ohne daß deren Vertraulichkeit 
unerkannt verloren oder deren Integrität unerkannt verändert werden kann. Weiterhin 
ermöglicht dieser Header einen eindeutigen Nachweis über den Absender eines IP  
Pakets. Die zu schützenden Daten werden dabei gekapselt und darauf 
Verschlüsselungsverfahren zur Gewährleistung der Vertraulichkeit und zusätzlich 
kryptographische Prüfsummen zur Sicherstellung der Integrität angewendet.   
39
 Vgl. Eckert 2001, S.476 ff. 
4. Internet  Sicherheit 
26 
Grundlage dieser Sicherheitserweiterungen ist das Konzept der Security Association 
(SA), auf das jedoch nicht weiter eingegangen werden soll. 
40
Man kann sich eine IPsec Security Association als ein Abkommen zwischen zwei oder 
mehr Kommunikationspartnern vorstellen, das unter anderem Informationen bzgl. der 
verwendeten Authentizitätsverfahren, Modi und Schlüssel für das AH  Protokoll und 
die verwendeten Authentizitätsverfahren, Modi und Schlüssel für das ESP  Protokoll 
enthält. 
41
Fragen zur Zugriffskontrolle und zur Verbindlichkeit bleiben jedoch offen.  
4.7 Schlußfolgerung 
Die Absicherung der Internet  und Transportschicht sind von entscheidender 
Bedeutung für eine sichere Übertragung von sensitiven Daten. Dies ist insbesondere 
auch für XML  basierte Web Services von Bedeutung, da diese sensitive Daten als 
SOAP  Nachrichten empfangen, verarbeiten und an die entsprechenden 
Geschäftspartner unter Nutzung von HTTP weiterleiten. Wie in Abbildung 8 dargestellt 
ist HTTP ein Dienst auf der Anwendungsschicht, der unmittelbar auf den vorgestellten 
Protokollen der Internet  und Transportschicht aufsetzt. Diese Protokolle liefern den 
Diensten der Anwendungsschicht, insbesondere HTTP, anwendungsübergreifende 
Sicherheitsfunktionalitäten. 
Durch Anwendung der in Kapitel 4.6 vorgeschlagenen Protokolle, zur Absicherung der 
Internet  und Transportschicht auf unser Beispiel  Szenario, erhalten wir folgende 
Modifikationen für die Abbildung 3 : 
40
 Vgl. Fuhrberg 1998, S. 18 ff. 
41
 Eckert 2001, S.481 ff. 
4. Internet  Sicherheit 
27 
Abbildung 9: Das Beispiel  Szenario : Einbeziehung von SSL in die Business Partner Connectivity  
Die Protokolle der Transportschicht sind lediglich in der Lage die Verbindung zwischen 
zwei Geschäftspartnern abzusichern, d.h. die Daten liegen an den beiden Endknoten 
ungeschützt als Klartext vor. Das SSL Protokoll gehört zu den  Ende  zu  Ende 
Sicherheitsprotokollen und stellt dabei ein CPU  intensiver Prozeß dar. Eine SSL  
Verbindung besteht jeweils nur für zwei bestimmte Geschäftspartner, die sich zuvor 
bzgl. der verwendeten Verfahren verständigt, und die individuellen Schlüssel des  
jeweiligen Partners ausgetauscht haben. Einer dieser Geschäftspartner kann diese 
Verbindung also nicht ohne weiteres für eine sichere Kommunikation mit einem 
anderen Geschäftspartner nutzen. 
Dies erscheint gerade innerhalb des EAI  Umfeldes wenig praktikabel. Durch den in 
einem Web Service gekapselten Geschäftsprozeß sollen gerade alle an diesem Prozeß 
beteiligten Geschäftspartner und geg. adhoc neue Kommunikationspartner eingebunden 
werden, wobei einige dieser Transaktionsknoten lediglich Intermediäre darstellen 
können, die die erhaltenen Dokumente an andere Knoten weiterleiten. Am Beispiel 
eines Automobilkonzerns wird deutlich, daß die Anzahl der Geschäftspartner sehr 
schnell eine Vielzahl von Zulieferern, Speditionen usw. annehmen kann. Verbunden mit 
den Schwächen dieser Ansätze erscheint eine andere bzw. ergänzende 
Herangehensweise erforderlich.  
SOAP  Response via HTTPS 
Web Server
HTML 
XML
Web  
Service 
Container 
Firma IQ - Technology 
Firewall 
Logistikdienstleister 
(LDL) 
E - Logistic 
Zulieferer (L) 
 Firma Hansen 
Firewall 
Firewall 
Client 
Client 
Client 
SOAP  Request via HTTPS 
HTTPS HTTPS 
HTTPS 
HTTPS 
HTTP 
HTTP 
2.
1.
2.  5. 
2. 
5. 
3. 
4. 
  3.  4. 
5.
Web  Service 
Container 
Web  Service 
Container 
Details
- Seiten
 - Erscheinungsform
 - Originalausgabe
 - Erscheinungsjahr
 - 2002
 - ISBN (eBook)
 - 9783832462338
 - ISBN (Paperback)
 - 9783838662336
 - DOI
 - 10.3239/9783832462338
 - Dateigröße
 - 1 MB
 - Sprache
 - Deutsch
 - Institution / Hochschule
 - Johann Wolfgang Goethe-Universität Frankfurt am Main – Wirtschaftswissenschaften
 - Erscheinungsdatum
 - 2002 (Dezember)
 - Note
 - 1,0
 - Schlagworte
 - soap saml xums xml-signature xml-encryption
 - Produktsicherheit
 - Diplom.de