Nutzung von Kryptographie in Zusammenhang mit Firewalls...Firewall-Test-Labor fur¨...

Fir ewall-Test-Labor

fur Hochgeschwindigkeitsnetze

Nutzung von KryptographieimZusammenhangmitFir ewalls

StudiedesDFN-FWL

CarstenBenecke undUweEllermann

Universitat Hamburg – Fachbereich Inf ormatik – DFN-FWL

3

Inhaltsverzeichnis

1 Einleitung 7

2 Fir ewalls 7

2.1 Firewall-Komponenten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Packet Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Proxy-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3 Anwendungs-Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.4 WeitereFirewall-Komponenten . . . . . . . . . . . . . . . . . . . . 15

2.2 Firewall-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Packet Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 KombinationenvonPacket ScreenundBastion . . . . . . . . . . . . 18

2.2.3 Gateway-Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.4 Firewall-Erganzungen . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3 Nicht durchFirewallsabgedeckteSicherheitsprobleme. . . . . . . . . . . . 22

3 Kryptographische Verfahren und Protokolle 23

3.1 InformaleDefinition: KryptographieundverwandteBegriffe . . . . . . . . . 24

3.2 Kryptographiefur dieNetzwerksicherheit. . . . . . . . . . . . . . . . . . . 25

3.3 KryptographischeVerfahrenundAlgorithmen . . . . . . . . . . . . . . . . . 26

3.3.1 Algorithmenmit symmetrischenSchlusseln. . . . . . . . . . . . . . 26

3.3.2 Algorithmenmit asymmetrischenSchlusseln . . . . . . . . . . . . . 27

3.3.3 Bitstrom-basierteundBlock-basierteAlgorithmen . . . . . . . . . . 28

3.3.4 WeitereelementareFunktionenfur kryptographischeProtokolle . . . 29

3.4 InformaleDefinition: KryptographischeProtokolle . . . . . . . . . . . . . . 30

3.5 Infrastrukturfur die Schlusselverteilung . . . . . . . . . . . . . . . . . . . . 31

3.6 Protokolle fur dasSchlusselmanagement. . . . . . . . . . . . . . . . . . . . 32

3.6.1 Protokolle basierendaufDiffie-Hellman. . . . . . . . . . . . . . . . 33

3.6.2 Protokolle basierendaufKDC . . . . . . . . . . . . . . . . . . . . . 34

4

4 Kryptographische Protokolle in der TCP/IP-Familie 35

4.1 Protokolle unterhalbvon IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Protokolle aufderIP-Ebene. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.2 SKIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Protokolle aufderTransportebene. . . . . . . . . . . . . . . . . . . . . . . 50

4.3.1 DasTLS RecordProtocol . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.2 DasTLS HandshakeProtocol . . . . . . . . . . . . . . . . . . . . . 53

4.4 Protokolle aufderAnwendungsebene. . . . . . . . . . . . . . . . . . . . . 56

4.4.1 SicheresHTTP (S-HTTP) . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.2 Sicheres“Remote”-Login . . . . . . . . . . . . . . . . . . . . . . . 57

4.4.3 Sicheres“DomainNameSystem”(SecureDNS) . . . . . . . . . . . 61

4.4.4 ISAKMP/OAKLEY . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4.5 PKI-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.5 AnwendungenaußerhalbdesProtokollstapels . . . . . . . . . . . . . . . . . 65

4.6 Nicht durchkryptographischeProtokolle abgedeckteSicherheitsprobleme. . 66

4.7 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5 Vorteile durch einenkombinierten Einsatz 68

5.1 NutzenkryptographischerVerfahrenfur Firewalls . . . . . . . . . . . . . . . 69

5.1.1 Authentisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1.2 Integritat ubertragenerDaten . . . . . . . . . . . . . . . . . . . . . . 72

5.1.3 ErweiterteZugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . 72

5.1.4 FernadministrationvonFirewalls . . . . . . . . . . . . . . . . . . . 72

5.2 Nutzenvon Firewalls fur kryptographischeVerfahren . . . . . . . . . . . . . 73

5.2.1 Firewalls fur offeneProbleme . . . . . . . . . . . . . . . . . . . . . 73

5.2.2 DurchsetzenvonVerschlusselungsrichtlinienamFirewall . . . . . . . 75

5.2.3 Firewall alsVerschlusselungs-Gateway . . . . . . . . . . . . . . . . 75

5.2.4 Zertifikatskontrolleim Firewall . . . . . . . . . . . . . . . . . . . . 76

5.2.5 AnonymisierungderKommunikationmit einemFirewall . . . . . . . 78

5

6 Wechselwirkungendeskombinierten Einsatzes 78

6.1 TechnischeAspektedeskombiniertenEinsatzes. . . . . . . . . . . . . . . . 78

6.1.1 Packet Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.1.2 ProxiesundAnwendungs-Gateways . . . . . . . . . . . . . . . . . . 80

6.2 Performanzbei kombiniertemEinsatz . . . . . . . . . . . . . . . . . . . . . 81

7 Zusammenfassung 85

Abkurzungsverzeichnis 88

Literatur 90

6

Abbildungsverzeichnis

1 VonPacket ScreensausgewerteteInformationen. . . . . . . . . . . . . . . . 10

2 KonzeptionelleSichtaufeinenProxy . . . . . . . . . . . . . . . . . . . . . 13

3 Packet Screen:konzeptionelleSicht . . . . . . . . . . . . . . . . . . . . . . 16

4 KombinationvonPacket ScreenundBastion:konzeptionelleSicht– Bastioninnen 18

5 KombinationvonPacket ScreenundBastion:konzeptionelleSicht– Bastionmittig 18

6 KombinationvonPacket ScreenundBastion:konzeptionelleSicht– Bastionaußen19

7 KombinationvonPacket ScreenundBastion:konzeptionelleSicht– beidseitigabgeschirmteBastion 19

8 GatewayFirewall: konzeptionelleSicht . . . . . . . . . . . . . . . . . . . . 21

9 Diffie-HellmanProtokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

10 KerberosProtokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

11 VerfugbarekryptographischeProtokolle . . . . . . . . . . . . . . . . . . . . 37

12 AufbaueinerEthernetRahmens . . . . . . . . . . . . . . . . . . . . . . . . 38

13 “Bridge” mit Ver- undEntschlusselungauf derEthernet-Ebene. . . . . . . . 39

14 SicherungderEthernet-basiertenVLAN-K ommunikation. . . . . . . . . . . 40

15 “IP AuthenticationHeader”(vgl. [25,S.4ff]) . . . . . . . . . . . . . . . . . 42

16 “IP EncapsulatingSecurityPayload”(vgl. [26,S.4ff]) . . . . . . . . . . . . 44

17 SKIP-Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

18 SKIP-Sendemodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

19 SKIP-Empfangsmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

20 TLS “Handshake” zurAuthentisierungundSchlusselvereinbarung. . . . . . 55

21 TypischerSSH-Protokollstapel . . . . . . . . . . . . . . . . . . . . . . . . . 58

22 SchlusselaustauschundAuthentisierungbeimTLP . . . . . . . . . . . . . . 59

23 Abfragevon Zertifikatenmit LDAP . . . . . . . . . . . . . . . . . . . . . . 66

24 Datendurchsatzbei Verschlusselung . . . . . . . . . . . . . . . . . . . . . . 84

25 CPU-LastaufdemFirewall durchVerschlusselung . . . . . . . . . . . . . . 85

7

1 Einleitung

Die vorliegendenStudiezum “EinsatzkryptographischerVerfahrenim ZusammenhangmitFirewalls” ist einevertiefendeDarstellungder wichtigstenheutigenund zukunftigenSiche-rungsmechanismenfur Rechnernetze.Die Studiesoll Grundlagenwissenin den Bereichen“Firewalls” und“Kryptographie”vermittelnundaufzeigen,wie dieseverschiedenenAnsatzezueinerErhohungderNetzwerksicherheitkombiniertwerdenkonnen.

Die Studieist in zwei Teile gegliedert. Im erstenTeil wird einebreiteEinfuhrungsowohl indenBereich“Firewalls” (vgl. Abschnitt2) alsauchin denBereich“kryptographischeVerfah-ren” (vgl. Abschnitt3) gegeben.Die Einfuhrungvermittelt einenUberblick uberAufgabenundFunktionsweisevon Firewalls einerseitsundkryptographischerVerfahrenundProtokolleandererseits.Besondersausfuhrlichwerdendie praxisrelevantenkryptographischenProtokol-le ausderTCP/IP-Familie diskutiert(vgl. Abschnitt4). Durchdiesegetrennte,unabhangigeDarstellungkanngenauherausgearbeitetwerden,welcheSicherheitsrisiken durchFirewallsverringertwerdenkonnenundfur welcheSicherungsaufgabenkryptographischVerfahrenver-wendetwerdenmussen.Insbesonderewerdendie offenenProblemebeimEinsatzvon Siche-rungsmechanismenausnur einemdieserBereichegenannt.

Im zweitenTeil der Studiewerdendie Vorteile deskombiniertenEinsatzesvon Firewallsund kryptographischerVerfahrendargestellt (vgl. Abschnitt 5). NebenLosungenfur vieleder diskutiertenoffenenProblemewerdenauchvollig neueMoglichkeitenerlautert,die erstdurchdengleichzeitigenEinsatzderSicherungsmechanismenausbeidenBereichendenkbarsind. Dazuwird wiederumunabhangigvoneinanderdargestellt,wie einerseitsFirewalls vonzusatzlichenkryptographischenMechanismenprofitierenundandererseitsdieZugriffskontrol-le nutzbringendin Netzenverwendetwerdenkann,in denenausschließlichkryptographischeSchutzmechanismenverwendetwerden.

Ein kombinierterEinsatzvon kryptographischenVerfahrenmit Firewalls ist nicht immerpro-blemlosmoglich. Teilweisebehindernsich die verschiedenenSicherungsmechanismen.Eswird daheranhandverschiedenerkryptographischerProtokolle und Firewall-Komponentendargestellt,woProblemeauftretenundwiedieseProblemegelostwerdenkonnen.EinSchwer-punkt ist hierbeidie DarstellungdesPerformanz-Problems,dassichbei einemkombiniertenEinsatzin Hochgeschwindigkeitsnetzenergibt (vgl. Abschnitt6).

In der Zusammenfassungwird schließlichauf offeneProblemeeingegangenundeswird einAusblick aufzukunftigeUntersuchungengegeben.

2 Fir ewalls

Firewalls sindZugriffskontrollmechanismenin Netzen.Siewerdeneingesetzt,um eineTren-nung der Netze nach Sicherheitsgesichtspunktenzu erreichen. Ublicherweisewird durcheinenFirewall ein internes,sicherheitskritischesNetzvor Angriffen auseinemexternenNetz

8 2 FIREWALLS

geschutzt.1 Der Firewall setztvorherspezifizierteSicherheitsrichtliniendurch.DemexternenNetzgegenuberstelltderFirewall nureinekleineAnzahlgutgesicherterundstrenguberwach-terDienstezurVerfugung.DamitderFirewall diegesamteKommunikationzwischeninternemundexternemNetzuberwachenkann,mußdurchorganisatorischeMaßnahmendafur gesorgtwerden,daßderFirewall denalleinigenUbergangzwischenbeidenNetzenbildet. Die Kom-munikationzwischenSystemeninnerhalbdesinternenNetzessowie zwischenSystemenimexternenNetzwird durchdenFirewall nicht kontrolliert.

Fir ewall: “Ein Firewall ist eineSchwellezwischenzweiNetzen,dieuberwundenwerdenmuß,umSystemeim jeweilsanderenNetzzuerreichen.Eswird dafur gesorgt, daßjedeKom-munikationzwischendenbeidenNetzenuberdenFirewall gefuhrt werdenmuß.Auf demFirewall sorgen Zugriffskontrolle und Audit dafur, daßdasPrinzip der geringstenBe-rechtigungdurchgesetztwird undpotentielleAngriffeschnellstmoglicherkanntwerden.”[12]

ZunachstwurdenFirewalls primar zur sicherenAnbindungvon Unternehmensnetzenan das(offentliche)Interneteingesetzt.2 Nebendiesen“Internet-Firewalls” ist heutedieAbsicherungbesonderssensitiver AbteilungeninnerhalbeinesUnternehmensnetzesein wichtigerEinsatz-bereichvonFirewalls (“Intranet-Firewalls”). DiesebeidenEinsatzbereicheunterscheidensichdurch:

Kommunikationsanforderungen: ZwischenverschiedenenTeilen einesUnternehmensnet-zesbestehenin derRegelengereKommunikationsbeziehungenalsmit demInternet.Soist meistder Zugriff vom abgesichertenNetz auf Datenbanken im Unternehmensnetznotwendig.

Da dasdurcheinenIntranet-Firewall abgetrennteNetzoft nur wenigeSystemeumfaßt,ist derAufwandzurAbsicherungseltengenutzterDienstekaumzurechtfertigen.DieLi-stederzuunterstutzendenProtokolle wird sichdaherfur Internet-undIntranet-Firewallsunterscheiden.

Sicherheitsanforderungen: Intranet-Firewalls sindeinerhoherenBedrohungausgesetzt,dadie zu schutzendenSystemebesonderskritische Informationenenthalten. Auch derKreis der potentiellenAngreifer unterscheidetsich,da primar mit Angriffen durchfir-meninterneMitarbeiter gerechnetwird. ExterneAngreifer werdenbereitsdurch denInternet-Firewall erkanntundaufgehalten.

Performanzanforderungen: Hochgeschwindigkeitsnetzewerdeninnerhalbvon Unterneh-menfruhereingesetztals bei der Internet-Anbindung.Intranet-Firewalls bilden daherfruhereinenEngpaß.

1 Fur dasdurchdenFirewall geschutzteNetz wird im folgendendie Bezeichnung“ internesNetz” ver-wendet.DasNetzauf deranderenSeitedesFirewallswird als“externesNetz” bezeichnet.

2 Praktischalle Firewalls werden derzeit fur TCP/IP-Protokolle eingesetzt. Eine AnwendungdesFirewall-Konzeptesist prinzipiell aberauchbei anderenProtokollen (ATM, DECNet, ISO-OSI, ...)moglich.

2.1 Firewall-Komponenten 9

Fur denAufbaueinesFirewallswird eineReihevonKomponentenbenotigt, dieexaktaufein-anderabgestimmtsein mussen. Die wichtigstenFirewall-Komponenten— Packet Screen,Proxy-Server und Anwendungs-Gateway — sollen im folgendenAbschnitt 2.1 vorgestelltwerden. Die wichtigstenFirewall-Architekturen,die sich aus den vorgestelltenFirewall-Komponentenaufbauenlassen,werdenim Abschnitt2.2diskutiert.Auf dieVor- undNachteilejederFirewall-Architekturwird dabeiexplizit hingewiesen.

2.1 Fir ewall-Komponenten

Firewall-Komponentensind Mechanismen,ausdenenFirewalls aufgebautwerden.Die Me-chanismenwerdenauf unterschiedlichenEbenenrealisiert.Die erreichteGranularitat derZu-griffskontrollehangtvondenaufderjeweiligenEbenezurVerfugungstehendenInformationenab.

2.1.1 Packet Screen

PacketScreensfuhreneineZugriffskontrolleaufIP-Datagrammendurch.Siegewahrenbzw. un-terbindendieKommunikationzwischenmindestenszweiNetzen,indemsienurdieDatagram-meweiterleiten,derenProtokoll-HeaderaufVermittlungs-undTransportschichtdenvomVer-walterkonfiguriertenFilterregelngenugen.3 EinenUberblickuberHeader-Informationen,dievoneinerPacket Screenausgewertetwerdenkonnen,bietetAbbildung1.

Uber die Sender- und Empfanger-AdressendesIP-Headersist eineBeschrankungder End-systememoglich, die miteinanderkommunizierendurfen. Dadurchkann zum Beispiel derZugriff aufbesonderskritischeSystemeverwehrtwerden.DasProtokoll-FelddesIP-Headersgibt an,zu welchemProtokoll die enthalteneDateneinheitgehort (TCP, UDP, ICMP oderan-dere).Fragment-OffsetundDatagrammlange— in Abbildung1 schwachgedruckt— werdennur von einigenPacket Screensuberpruft, sind aberzur Erkennungvon Fragmentierungsan-griffen notwendig.4 UberSender- undEmpfanger-PortsderProtokoll-Headerauf der Trans-portschichtkonnendiezugegriffenenDiensteidentifiziertwerden.Die IdentifikationderDien-steist jedochnicht besonderszuverlassig,dadurchManipulationderEndsystemeauchnichtstandardisiertePortsverwendetwerdenkonnenundzudemfur RPC-basierteProtokolle keinefesteZuordnungderDienstezubestimmtenPortnummernexistiert. Uberdie AuswertungdesSYN-Flagsim TCP-Headerkannzwischender erstenDateneinheiteinerneuenVerbindungund den nachfolgendenDateneinheitenunterschiedenwerden. Die AuswertungdesSYN-Flagsermoglicht esderPacket Screen,die RichtungeinesVerbindungsaufbauszu erkennen.

3 HaufigwerdendieBegriffe Paket-Filter(“PacketFilter”) undPacketScreenfalschlicherweisesynonymverwendet.Ein Paket-Filter ist ein Filter in Endsystemen,mit demApplikationenwie tcpdump emp-fangenePaketenachbestimmtenMerkmalenselektierenkonnen.

4 Bei fragmentiertenDateneinheitensinddie Transport-Headernur im erstenFragmententhalten,sodaßPacket ScreensfolgendeFragmente(Offset � 0) ohnevollstandigeUberprufungweiterleitenkonnen.DurchnachfolgendeFragmentemit einemkleinenOffsetkonnenbeimEmpfangerTeile desim erstenFragmententhaltenenTransport-Headersuberschriebenwerden.

10 2 FIREWALLS

ICMP

Senderadresse

Empfängeradresse

Protokoll

Fragment-Offset

Datagrammlänge

IP

auf VermittlungsschichtProtokoll-Header Protokoll-Header

auf Transportschicht

ICMP-Typ

TCP

Sender-Port

Empfänger-Port

Flags

UDP

Sender-Port

Empfänger-Port

Abbildung1: VonPacket ScreensausgewerteteInformationen

Da die UbertragungeinerDateneinheitmit SYN-Flagfur denAufbaueinerTCP-Verbindungerforderlichist, kannunterderAnnahme,daßdie Dateneinheitmit SYN-Flagvon derPacketScreenbereitsuberpruft wurde,die Prufung der nachfolgendenDateneinheiten(ohneSYN-Flag) entsprechendeinfacherausfallen. Die meistenPacket ScreensunterstutzenkeineFil-terungvon ICMP-DateneinheitenanhanddesICMP-Typs(Echo,“DestinationUnreachable”,“Source-Quench”,“Timestamp”,“Redirect”, ...). Meist kannnur uberdie AuswertungdesProtokoll-Feldesim IP-Headerdie Ubertragungvon ICMP-Nachrichteninsgesamtunterbun-denwerden.Diesist jedochwenigempfehlenswert,daICMP wichtigeKontroll-Informationenfur die ordnungsgemaßeVerarbeitungvon IP-Dateneinheitentransportiert.5

DynamischePacket Screens: Im Gegensatzzudenbisherbeschriebenen“StatischenPacketScreens”, bei denenjedeeingehendeDateneinheitnacheinemfestgelegtenSatzvon Filterre-gelnunabhangigvon bereitsverarbeitetenDateneinheitenausgewertetwird, kannbei “Dyna-mischenPacket Screens”6 die FilterentscheidungvomKontext bereitsempfangenerDatenein-heitenabhangen.

Die Moglichkeit, FilterentscheidungenanhanddesKontextesbereitsempfangenerDatenein-heitendurchfuhrenzukonnen,hatim WesentlichenzweiVorteile:

5 UberICMP kanneinemSendermitgeteiltwerden,daßderEmpfangernicht erreichbarist. OhneICMPkannderSenderbeiverbindungsorientiertenProtokollenerstnacheinemmehrereMinutenbetragenden“Timeout” erkennen,daßseineDateneinheitennicht bestatigt werden.Bei verbindungslosenProtokol-len ist keineErkennungmoglich.

6 Gelegentlichwird auchdieBezeichnung“StatefulPacketfilter” verwendet.


� DabeiUDPkeinVerbindungsaufbaudurchgefuhrtwird, kanndieRichtungdesZugriffsnicht wie bei TCPuberdasSYN-Flagfestgestelltwerden.OhneKenntnisvorangegan-generDateneinheitenkannnichtentschiedenwerden,obessichbeieinemempfangenenUDP-DatagrammumeineReaktion(Antwort) oderumeinenneuenZugriff handelt.Beieiner “DynamischenPacket Screen”wird eineFilterregel erganzt, die AntwortenaufubertrageneUDP-Datagrammeebenfallspassierenlaßt.NachlangererInaktivitatdieserKommunikationsbeziehungwird die Filterregelwiederentfernt.

� FTPstellt fur Packet Screensein Problemdar, weil Kontroll- undDatenverbindungvonunterschiedlicherRichtungausgeoffnetwerden.“DynamischePacket Screens”konnendasZulasseneinerFTP-Datenverbindungdavonabhangigmachen,obgleichzeitigaucheineKontrollverbindungzwischendenbeidenSystemenexistiert.

Granularit at: DieGranularitatderZugriffskontrolleistbeiPacketScreensaufdieim Protokoll-HeaderenthaltenenInformationenbeschrankt. Somit kannderZugriff nur anhandderHost-Adressen(IP-Adr esse) unddeszugegriffenenDienstes(Port-Nummer) kontrolliert werden.Eine Authentisierungvon Benutzern7 oder eine Kontrolle der ubertragenenDatenist nichtmoglich.

Vorteile einer Packet Screen:

Transparenz: Die Uberprufungvon Dateneinheitenkannin derPacket ScreenohneInterak-tion mit demBenutzererfolgen.EssindauchkeineKonfigurationsanderungenauf denEndsystemennotwendig.

Performanz: Der Filter-AufwandderPacket Screenist relativ gering,sodaßeinegutePer-formanzerreichtwird. Die Performanzauswirkungender Packet ScreenwerdenvomBenutzernicht bemerkt.8

Geringer Installationsaufwand: Die Packet ScreenFunktionalitat ist in heutigenRouternmeistschonvorhanden,sodaßnur die Definition geeigneterFilterregelnnotwendigist.Die Konfigurationerfordertnur einengeringenZeitaufwand.

Kostengunstig: Da Packet Screensmeist im Routerschonverfugbarsind, ist dankdesge-ringenZeitaufwandszurKonfigurationderFilterregeln,derEinsatzeinerPacketScreenrelativ kostengunstig.Wennkein vorhandenerRouteralsPacket Screenverwendetwer-denkann,bietetfrei verfugbarePacket ScreenSoftware(z. B. “Drawbridge”9 oder“IP-Filter”10), die auf einfacherPC-Hardware eingesetztwerdenkann,eine ebenfalls ko-

7 EineAuthentisierungvon Benutzernwarezukunftig mit Hilfe von IPSECdenkbar[14], dieVerfugbar-keit vonentsprechendenPacketScreenImplementationenlaßtsichheutenochnicht absehen.

8 In HochgeschwindigkeitsnetzenkanneinePacketScreenjedochzumEngpaßwerden,wie dieAnalysenin [15] zeigen.

9 ftp://ftp.cert.dfn.de/pub/firewalls/ softw are/d rawbri dge/10 ftp://coombs.anu.edu.au/pub/net/ip-f ilter /

12 2 FIREWALLS

stengunstigeAlternative. KommerzielleLosungenwie die dynamischePacket Screen“Firewall-1” sinddeutlichteurer.

Nachteileeiner Packet Screen:

Granularit at der Zugriffsk ontrolle: Die Zugriffskontrollekannbei Packet Screensnur an-handvon Informationenim Protokoll-Headererfolgen.

SchlechtesAudit: Die in gebrauchlichenRouternenthaltenenPacket ScreenskonnennursehrrudimentareAudit-Datenaufzeichnen.UberdasInternetverbreitetePacket ScreenSoftware(“Drawbridge”und“IP-Filter”) sowiekommerzielleLosungen(z.B. “Firewall-1”) erlaubeneinedetailliertereAufzeichnungvon Auditdaten,jedochstehenkonzept-bedingtbei Packet Screensnur geringeInformationenfur dasAudit zur Verfugung.(vgl. “Granularitat”)

Kontrolle der fr eigegebenenPorts: EinePacketScreenkannnichtkontrollieren,obaneinerfreigegebenenPortnummertatsachlichdervorgeseheneDienstangebotenwird. DurcheinfacheManipulationenandenEndsystemenkanneinePacketScreenleichtumgangenwerden.

Korr ektheit erstellter Filterr egeln: DiekorrekteKonfigurationderFilterregelnerfordertgroßteSorgfalt, dabereitskleineFehlerzu einemnicht erwunschtenVerhaltenfuhrenkonnen.BisherbietennurwenigePacketScreensdemVerwaltereineUnterstutzungbeiderKon-figurierungan.WunschenswertwareaucheineautomatischeUberprufungneuerstellterFilterregeln.

2.1.2 Proxy-Server

Ein Proxy-Server — kurz Proxy(Stellvertreter)— ist ein Prozeßauf Anwendungsebene,derAnfragenfur einenClient an einenServer stellt und die AntwortendesServersan denCli-ent weiterleitet. Bei demEinsatzvon Proxiesin Firewall-Konzeptenwird durchzusatzlicheMaßnahmendie direkteKommunikationzwischenClient undServer unterbunden,sodaßdieKommunikationnur ubereinenProxy moglich ist. Da der Proxy Zugriff auf die AnfragendesClientsund auf die AntwortendesServerserhalt, wird einesehrguteZugriffskontrollemoglich. DerkonzeptionelleAufbaueinesProxiesist in Abbildung2 wiedergegeben.

Eine Anfrage einesClients muß vom Proxy zunachstauthentisiertwerden. Hierfur wer-den kryptographischeVerfahren,Einmal-Paßworte, aberauchunsichereVerfahrenwie dieUberprufungderIP-Absender-Adresseeingesetzt.JenachSicherheitsanforderungenkanndieAuthentisierungeinmaligbeim Verbindungsaufbauoderwiederholtfur jedeAnfragedurch-gefuhrt werden.Bei deranschließendenZugriffskontrollewird uberpruft, ob derZugriff desClientsdenspezifiziertenSicherheitsrichtlinienentspricht. Der Zugriff kann fur bestimmteServer, DiensteoderauchbestimmteUhrzeiteneingeschranktsein. Es ist auchmoglich, denZugriff aufausgewahlteBereicheeinesServerszubeschranken.Die vomProxyandenServer


Audit

Anfrage

Server

Anfrage*kontrolleZugriffs-

tisierungAuthen-

AntwortZugriffskontrolle

Proxy

Client

Antwort*

Abbildung2: KonzeptionelleSichtauf einenProxy

gesendete��

kannsichdaherdurchausvonderursprunglichenAnfragedesClientsun-terscheiden.Die vom Server zuruckgesendetenDatenwerdenvom Proxyebenfalls zunachstuberpruft und gegebenenfalls modifiziert (

�� ), bevor sie an denClient weitergeleitet

werden.Bei derUberprufungderAntwort kommenhauptsachlichScannerfur ausfuhrbareIn-halte(Java-Applets,Java-Script,Makrosusw.) zumEinsatz.Alle drei MechanismenkonnenZugriffe verweigernund sollten in einemderartigenFalle demClient diesesubereineFeh-lermeldungmitteilen (gestricheltePfeile). DasAudit protokolliert normaleund verweigerteZugriffe sowie gegebenenfalls weitereVorkommnisse.Abhangigvon der Sicherheitspolitikkannaufdie ImplementierungeinzelnerMechanismenauchverzichtetwerden.

Granularit at: Mit Proxiesist eine sehrdetaillierteZugriffskontrolle moglich. Die Kon-trolle kann abhangigvon Host-Adressen, vom Dienst, vom Benutzer, von zeitlichen Be-schrankungen, odervom Kontext desZugriffs erfolgen. Insbesonderestehender Zugriffs-kontrolleallezwischenClient undServerausgetauschtenDatenzurVerfugung.

Vorteile einesProxies:

FeineGranularit at: GroßterVorteil vonProxiesist diedetaillierte Zugriffsk ontrolle, durchdie aucheinsehrgutesAudit moglichwird (s.o.).

Authentisierung: EsisteineeinmaligeBenutzerauthentisierungbeimVerbindungsaufbauodereinewiederholteAuthentisierungfur jedeAnfragemoglich.

14 2 FIREWALLS

NachteileeinesProxies:

Transparenz: Zugriffe ubereinenProxy konnenfur denClient nicht transparenterfolgen.Abhangigvon derImplementationdesClientskanngegebenenfalls die fehlendeTrans-parenzgegenuberdemBenutzerverborgenwerden.Dafur ist jedocheineaufdenProxyabgestimmteImplementationundKonfigurationdesClientserforderlich,waseinenho-henInstallations-undVerwaltungsaufwandnachsichzieht. Authentisierungsverfahrenmachenoft eine Interaktionmit dem Benutzererforderlich,so daßeine transparenteLosunghier nichtmoglich ist.

Performanz: Die Verarbeitungvon Anfragenauf AnwendungsebeneerforderteinehohereRechenleistungalsdieUberprufungderProtokoll-Headerin einerPacketScreen.DurchaufwendigeAuthentisierungs-undZugriffskontrollmechanismenkannderProxyschnellzumEngpaßwerden.

Installationsaufwand: Proxieskonnennicht allein eingesetztwerden.AufbauundKonfigu-ration ebenfalls benotigter Komponentenwie Packet Screensund Bastionen(vgl. Ab-schnitt2.2) stelleneinenhohenAufwanddar.

2.1.3 Anwendungs-Gateway

Bei Protokollen, die im Stapelbetrieb(“Batch-Mode”) verarbeitetwerden,wie zum BeispielSMTP (E-Mail) und NNTP (Netnews), ist esvorteilhaft,Zugriffe nicht ubereinenProxy aneinenServer weiterzuleiten,sondernauf demFirewall bereitswesentlicheTeile der Server-funktionalitat zu realisieren.

Die BezeichnungenProxy und Anwendungs-Gateway werdenhaufig synonym verwendet.Anwendungs-GatewayszeichnensichgegenuberProxiesdurcheinehohereKomplexitat aus.Wahrendsich Proxiesmeist auf eine einfacheAuthentisierungbeschranken und anschlie-ßendlediglich DatenzwischendenbeidenVerbindungenkopieren,enthaltenAnwendungs-Gatewaysfur die jeweiligeApplikation spezialisiertenCode,derbereitseineVorverarbeitungdurchfuhrt odereinenTeildienstderAnwendungerbringt. Da auchbei ProxiesZugriffskon-trollmechanismeneingesetztwerdenkonnen,diespeziellaufdieunterstutzteAnwendungaus-gerichtetsind,ist dieGrenzezwischendenAnwendungs-GatewaysundProxiesfließend.

Granularit at: DieGranularitatderZugriffskontrolleunddesAuditsunterscheidensichnichtvon demeinesProxies.

Vorteile von Anwendungs-Gateways: ZusatzlichzudenVorteilenvonProxieshabenAnwendungs-GatewaysfolgendeVorteile:

Verdecken der internenStruktur: DurchErbringenwesentlicherServerfunktionenkanndieinterneStrukturdesdurchdenFirewall geschutztenNetzesverdecktwerden.

2.2 Firewall-Architekturen 15

Verzogerungszeitenweniger relevant: Die stapelorientierteVerarbeitungerlaubtaufwendi-gereZugriffskontroll-Verfahren(z. B. dasScannennachViren in E-Mails), da hohereVerzogerungenalsbei interaktivenProtokollenakzeptabelsind.

Nachteilevon Anwendungs-Gateways: Zusatzlich zu den Nachteilenvon ProxieshabenAnwendungs-GatewaysfolgendeNachteile:

KeineBenutzerinteraktion zur Authentisierung: StapelorientierteAnwendungenschrankendie Liste der einsetzbarenAuthentisierungsverfahrenein, da eineBenutzerinteraktionzurAuthentisierungnichtmoglich ist.

2.1.4 WeitereFir ewall-Komponenten

Audit: Die vondenZugriffskontrollkomponentengemeldetenEreignissemussenaufgezeich-netundausgewertetwerden.Um Angriffe schnellerkennenzukonnen,ist einemaschi-nelleAuswertungderaufgezeichnetenDatennotwendig.

Verschlusselung: In zunehmendemMaßewerdenVerschlusselungsverfahrenin Firewall-Konzepteintegriert. Nebendenbereitseingesetzten“Virtual PrivateNetworks” (VPNs) werdenzukunftig auchin ProxiesundAnwendungs-GatewayskryptographischeVerfahrenzurVerschlusselungderubertragenenDatenoderzurAuthentisierungangewendetwerden.

NAT: Uberdie “Network AddressTranslation”(NAT) konnenPacket Screensnicht-offentli-cheauf offentlicheIP-Adressenabbilden.Systememit nicht-offentlichenIP-Adressenkonnensoauf Diensteim Internetzugreifen.Zudembleibt durchNAT die StrukturdesinternenNetzesverdeckt.

Systemmanagement:Die Konfigurationund WartungeinesFirewalls stellt einesehrkom-plexe Aufgabedar, die einerUnterstutzungdurchgeeigneteWerkzeugebedarf. DieskonnenzumBeispielgrafischeBenutzeroberflachenfur die Erstellungvon FilterregelnoderWerkzeugezurAuswertungvon Auditdatensein.

2.2 Fir ewall-Architekturen

Firewall-ArchitekturenwerdenausFirewall-Komponentenaufgebaut.AusderVielzahlmogli-cherKombinationenwerdenim Folgendendie wichtigstenArchitekturenmit ihrenVor- undNachteilenkurzvorgestellt.

16 2 FIREWALLS

2.2.1 Packet Screens

Die KonfigurationeinerPacketScreenstellt dieeinfachsteFirewall-Architekturdar. TrotzderbereitsdiskutiertenEinschrankungen(vgl. Abschnitt2.1.1) bei derGranularitat derZugriffs-kontrolle und beim Audit kanndie KonfigurationeinerPacket Screenausreichen,wenndieerkanntenDefizitedurchzusatzlicheMaßnahmenkompensiertwerden(vgl. [13]).

Da die Moglichkeit, Filterregeln zu definieren,bereitsin allen gangigenRouternenthaltenist und ein Routerzudemzur AnbindungeinesNetzesan dasInternetoderan ein großeresFirmennetzohnehinbenotigt wird, ist die Packet Screeneine kostengunstigeLosung. DiekonzeptionelleSichteinerFirewall-ArchitekturaufBasiseinerPacketScreenist in Abbildung3 wiedergegeben.

Packet ScreenRouterexternes Netz internes Netz

Abbildung3: Packet Screen:konzeptionelleSicht

Zur ErstellungderFilterregelnkonnenzweiunterschiedlicheAnsatzegewahltwerden:

Verbotsregeln: Uber eine Konfigurierungvon Verbotsregeln fur als gefahrlich eingestufteProtokolle konnenAngriffe an der Packet Screengestopptwerden. Da alle anderenDienstevon diesenRegelnnicht betroffen sind,bleibenbei diesemAnsatzviele Dien-steerreichbar. Fur Benutzerhat diesdenVorteil, daßihre Kommunikationnur seltendurchdie Filterregeln unterbundenwird. Allerdings bleibenso auchviele DienstefurAngriffsversuchegeoffnet,sodaßdieserAnsatznurals“Ad-hocLosung”beikonkretenAngriffenauf einzelneDienstegewahltwerdensollte.

Erlaubnisregeln: Vor derKonfigurationeinerPacket Screenmit Erlaubnisregelnmußgenauanalysiertwerden,welcheKommunikationsanforderungen(benotigte Dienste)und Si-cherheitsanforderungen(akzeptablesRestrisiko) bestehen.ResultatdieserAnalysemußnebeneinerAufstellungweitererAbsicherungsmaßnahmeneinekurzeListe sein,wel-cheDienstevon welchenHostsoderGruppenvon Hostszugreifbarseinmussen.AusdieserListe konnenanschließenddie Erlaubnisregeln fur die KonfigurationderPacketScreenerstelltwerden.Die ListederErlaubnisregelnmußimmerabgeschlossenwerdendurcheineVerbotsregel fur alle nichtexplizit aufgefuhrtenDienste.

EinewichtigeAufgabevon Packet Screensist derSchutzgegenIP-SpoofingAngriffe. DurcheinfachePlausibilitatsuberprufungenkann die Packet Screenfeststellen,ob die Absender-AdresseeinereingegangenenDateneinheitzueinemEndsystemgehort, dasuberdie jeweiligeSchnittstelleerreichbarist. [16]


Wird einePacketScreenin einemRoutermit mehralszweiSchnittstellenkonfiguriert,mußdieKonfigurationvon Filterregelnsowohl vor alsauchnachder Wegfindung(Routing)moglichsein. Auf einer SchnittstellehereinkommendeDateneinheitenmussenvor der Wegfindunguberpruft werden,um IP-SpoofingAngriffe erkennenzu konnen.Erst nachder Wegfindungsolltendiefur dasZielnetzgeltendenFilterregelnangewendetwerden,dazudiesemZeitpunktaufgrundderRouting-EntscheidungnurnochbestimmteZieladressenvorkommenkonnenundsomitnur die aufdieseZieladressenzutreffendenFilterregelnausgewertetwerdenmussen.

NebendengrundsatzlichenVor- und Nachteilender Firewall-Komponente“Packet Screen”(s.Abschnitt2.1.1) werdenabschließendAspektevorgestellt,dieausdemEinsatzeinerPacketScreenalsFirewall-Architekturresultieren.

Vorteile bei ausschließlichemEinsatzeiner Packet Screen:

Kosten: WesentlicherVorteil einerFirewall-Architektur, die nur auseinerPacket Screenbe-steht, sind die niedrigenKostenfur Installationund Betrieb. Die niedrigenKostenkonnenjedochdurchzusatzlich notwendigeAbsicherungsmaßnahmenbei denEndsy-stemenin derGesamtkalkulationzuhohenKostenfuhren.

Nachteilebei ausschließlichemEinsatzeiner Packet Screen:

GroßeAnzahl bedrohter Rechner: Der EinsatzeinerPacket Screenfuhrt ublicherweisezueinerKonfigurationmit einergroßenAnzahlerreichbarerundsomitbedrohterRechner.Die SicherheitdieserLosungrichtetsichdannnachdemschwachsteninternenSystem,da Angreifer, die hier eindringenkonnen,von diesemSystemausauchalle andereninternenSystemedirekterreichenkonnen(“IslandHopping”). Um trotzdemeinesiche-re Installationzu erreichen,ist daherein hoherAbsicherungsaufwandbei deninternenEndsystemennotwendig.

Kontrolle interner Endsysteme: Die SicherheitdieserLosunghangt in hohemMaßevondeninternenEndsystemenab,da von der Packet ScreenhereingelasseneDateneinhei-ten von denEndsystemensicherverarbeitetwerdenmussen.Bei vielen Netzinstalla-tionenunterliegt die VerwaltunginternerEndsystemenicht derKontrolledesFirewall-Verwaltersbzw. bei einigenEndsystemenist eineTrennungzwischenVerwaltungsauf-gabenund normalerBenutzunggar nicht moglich. Nebender versaumtenInstallationsicherheitsrelevanterPatchesundderunsicherenKonfigurationstelltauchdiebeabsich-tigteUmgehungderPacket Screenein Problemdar, weil gesperrteDiensteanalternati-ven,nichtgesperrtenPortsbereitgestelltwerdenkonnen.

Granularit at: Die UberprufungvonProtokoll-Headernreichtfur dieAbwehrvielerAngriffenichtaus.

18 2 FIREWALLS

2.2.2 Kombinationenvon Packet Screenund Bastion

Die Probleme,diedurchdiegroßeAnzahlbedrohterRechnerunddurchdiemangelhafteKon-trolle der Endsystemebei der Packet ScreenArchitektur auftretenkonnen,lassensichdurcheineweitereEinschrankungdesZugriffs losen. Bei Kombinationenvon Packet ScreenundBastionwerdeneineodermehrerePacket Screensso konfiguriert,daßnur nochein einzel-nesEndsystemmit deminternenund dem externenNetz kommunizierenkann; die direkteKommunikationzwischeninternenund externenEndsystemenwird von der Packet Screenunterbunden.DiesesEndsystemwird als“Bastion” bezeichnet.EineBastion wird allgemeindefiniertalseinbesondersabgesichertesSystem,dasuberwundenwerdenmuß,um Endsyste-meim jeweilsanderenNetzzuerreichen.Auf derBastionwerdenProxies(s.Abschnitt2.1.2)undAnwendungs-Gateways(s.Abschnitt2.1.3)eingesetzt,umdie Kommunikationzwischeninternenund externenSystemenmit einersehrfeinenGranularitat bei ZugriffskontrolleundAudit zuermoglichen.DadieBastionnebenderPacketScreenalseinzigesSystemvonbeidenNetzenauserreichbarist, sindhierbesondereSicherungsmaßnahmenerforderlich.

Packet ScreenRouter

Bastion

externes Netz internes Netz

Abbildung4: Kombinationvon Packet Screenund Bastion: konzeptionelleSicht – Bastioninnen

Packet ScreenRouter

Bastion


Abbildung5: Kombinationvon Packet Screenund Bastion: konzeptionelleSicht – Bastionmittig

Bei derKombinationvon Packet ScreenundBastionwird abhangigvon derPositionderBa-stionzwischenvier Konzeptenunterschieden:(sieheauch[12])


RouterPacket Screen

Bastion

Routerexternes Netz internes Netz

Abbildung6: Kombinationvon Packet Screenund Bastion: konzeptionelleSicht – Bastionaußen

Packet ScreenRouter Router

Packet Screen

Bastion


Abbildung7: Kombinationvon Packet ScreenundBastion:konzeptionelleSicht– beidseitigabgeschirmteBastion

Bastion innen (Abbildung4)

Die Installationder Bastionim internenNetz ist die am einfachstenzu realisierendeLosung.JedochbestehthierbeizwischeninternemNetzundderBastionkeineweitereAbschirmung.Angriffe auf die Bastion,die von internenSystemenausgehen,mussenin diesemFall vonderBastionalleinabgewehrtwerden.

Bastionmittig (Abbildung5)

Durchdie InstallationderBastionin einemeigenenNetzaneinerweiterenSchnittstellederPacketScreenkannderZugriff aufdieBastionvomexternenundvominternenNetzbessereingeschranktwerden.

Bastionaußen (Abbildung6)

Die Losung,die Bastionvor der Packet Screenzu installieren,erscheintzunachstalsschlechteWahl, daAngriffe vom Internetausauf die Bastionleicht moglich sind. BeientsprechenderAbsicherungderBastionkannmit dieserLosungubersogenannte

”Paket

Sauger“ (siehe[12,Abschnitt4.4.1])einesehrdetaillierteAufzeichnungvon Angriffenauf denFirewall erfolgen.Zusatzlichkonnenvon derBastionausalle Diensteim Inter-netuneingeschranktzugegriffenwerden.

20 2 FIREWALLS

Bastionbeidseitigabgeschirmt (Abbildung7)

Bei dervorhergehendbeschriebenenInstallationderBastionaußenwerdenzweiRouterbenotigt, vondenenabernureineralsPacketScreenverwendetwird. DerzumexternenNetzhin installierteRouterist in denmeistenFallenzusatzlichnotwendig,um die An-bindungandasInternettechnischzu realisieren.Aus diesemGrundliegt esnahe,auchdenzum Internethin installiertenRouterals Packet Screenzu nutzen. Es ergibt sichdanndie in Abbildung7 vorgestellteKonfigurationmit einerbeidseitigabgeschirmtenBastion.Dasin beideRichtungenhin abgeschirmteSubnetz,andemdie Bastioninstal-liert ist, wird als Grenznetz(“ScreenedSubnet”,“Demilitarized Zone” oder “DMZ”)bezeichnet.

Die LosungderbeidseitigabgeschirmtenBastionmit zwei Packet Screenskannzu derLosungdermittig angeordnetenBastionoptimiertwerden,beidereinePacketScreenlo-gischdie FunktionenderbeidenPacket Screensrealisiert.Die Losungmit zwei PacketScreenshat dieservereinfachtenLosunggegenuberdenVorteil, daßein Angreifer je-weils immernur einePacket Screenangreifenkann,wahrenddie zweitePacket ScreeneinengroßenAnteil derSicherheitdesFirewallsweiterhinaufrechterhaltenkann.

Vorteile der Kombination von Packet Screenund Bastion:

Granularit at: Durch die Kombinationvon Packet Screenund BastionkanneinesehrfeineGranularitat bei ZugriffskontrolleundAudit erreichtwerden. Insgesamtkannein sehrhohesSicherheitsniveauerreichtwerden.

Erweiterbark eit: Durch EinsatzzusatzlicherBastionenkann dieseLosungbei Bedarf anhohereLeistungsanforderungenangepaßtwerden.

Nachteileder Kombination von Packet Screenund Bastion:

Kosten: Zur RealisierungdieseLosungist zunachstein hoherInstallationsaufwandnotwen-dig. WahrenddesBetriebskonnendurchniedrigerenAufwandbei PflegeundUberwa-chungderinternenSystemeKosteneingespartwerden.

2.2.3 Gateway-Firewalls

Ein Gateway ist ein Rechner, der an mindestenszwei Netzeangeschlossenist und der aufAnwendungsebeneeineKommunikationzwischenbeidenNetzenermoglicht. DurchErwei-terungenum Zugriffskontrolle und Audit zusammenmit einerbesonderenAbsicherungdesGatewaysist derEinsatzalsFirewall moglich (vgl. Abb. 8).11 Dabeimußsichergestelltwer-den,daßalle KommunikationsbeziehungenzwischendenangeschlossenenNetzennur uber


Gateway-FirewallVerbindungen auf Applikationsebenekein Weiterleiten von IP-Datagrammen


Abbildung8: GatewayFirewall: konzeptionelleSicht

denFirewall moglich sind. Auf demFirewall kannmit Hilfe von ProxiesundAnwendungs-GatewayseinesehrpraziseZugriffskontrolledefiniertwerden.

DerGateway-Firewall erreichtahnlicheEigenschaftenwieeineKombinationvonPacketScreenundBastion.Wahrendbei letztererLosungdie PacketScreendafur sorgt, daßnur dieBastionmit beidenNetzenkommunizierenkann,mußbei einemGateway-Firewall dergesamteVer-kehruberdiesesSystemgefuhrt werden,dadasGatewayalseinzigerRechneranbeideNetzeangeschlossenist. EinezusatzlicheAbschirmungdesGateway-FirewallsdurchvorgeschaltetePacket Screenskanndie SicherheiteinesGateway-Firewalls kaumerhohen. DasGrenznetzzwischenPacket ScreenundGateway-Firewall eignetsichjedochhervorragendfur die Instal-lationvonInformationsdiensten(Anonymous-FTP, WWW usw.), derenInstallationaufeinemGateway-Firewall ausSicherheitsgrundennichtempfohlenwerdenkann.

Vorteile von Gateway-Firewalls:

Granularit at: DurcheinenGateway-Firewall kanneinesehrfeineGranularitat bei Zugriffs-kontrolleundAudit erreichtwerden. Insgesamtwird ein sehrhohesSicherheitsniveauerreicht.

Viele kommerzielleLosungen: Fur Gateway-Firewallsgibt esviele Anbieter.

Nachteilevon Gateway-Firewalls:

Kosten: Zur RealisierungdieseLosungist zunachstein hoherInstallationsaufwandnotwen-dig. WahrenddesBetriebskonnendurchniedrigerenPflege- und Uberwachungsauf-wandbei internenSystemenKosteneingespartwerden.

Erweiterbark eit: Im Gegensatzzu Kombinationenvon Packet Screenund BastionbestehtkeineErweiterungsmoglichkeit durchdenEinsatzzusatzlicherBastionen.

11 Ein Gateway-Firewall ist perDefinition eineBastion.

22 2 FIREWALLS

2.2.4 Fir ewall-Erganzungen

Nachder Vorstellungder Firewall-Architekturensollen in diesemAbschnittdie wichtigstenErganzungenundVariantenkurzangesprochenwerden.

Inf ormationsdienste: Zusatzlich zur Absicherungdes internenNetzeswird von Firewall-Konzeptenoft auchdiesichereIntegrationvon Informationsdiensten(Anonymous-FTP,WWW usw.) gefordert. DieseDienste,die meist eingesetztwerden,um offentlicheInformationenfur dasexterneNetzbereitzustellen,habenandereSicherheits-undKom-munikationsanforderungenalsdie Systemeim internenNetz. Um eineGefahrdungfurdasinterneNetzdurchdie Informationsdiensteausschließenzu konnen,ist dasBereit-stellender InformationsdienstedurchSystemeim internenNetzoderauf demFirewallselbstnicht akzeptabel.Besserist es,die InformationsdiensteaußerhalbdesFirewallsanzubieten.Da derInformationsserversonichtmehrdurchdenFirewall geschutztwer-denkann,erfordertdieseLosungjedocheinezusatzlicheAbsicherungdesInformati-onsservers.

Virtual PrivateNetworks (VPNs): Die VerbindungentferntvoneinanderliegenderTeilnet-ze kannentwederuberangemietete,teureStandleitungenoderbeim Einsatzvon Ver-schlusselungauchuber offentlicheNetzewie dem Interneterfolgen. Die KoppelunguberoffentlicheNetzemit Hilfe vonVerschlusselungwird als“Virtual PrivateNetwork”(VPN) bezeichnet.EineDateneinheitwird vom VPN-Endpunktverschlusseltundnachder Ubertragungim offentlichenNetz von einemweiterenVPN-Endpunktwiederent-schlusselt.Die Ver- undEntschlusselunggeschiehtfur SenderundEmpfangertranspa-rent.

Die PlanungeinesVPNsmußim Zusammenhangmit demFirewall-Konzeptbetrachtetwerden,daje nachPositionierungderbeidenKonzeptezueinanderunterschiedlicheSi-cherheitseigenschaftenerreichtwerden[28, S. 6f]. In jedemFall ist zu beachten,daßdie miteinandergekoppeltenNetzwerke dasselbeSicherheitsniveauerreichenmussen,da andernfalls Zugriffe auseinemwenigerstarkgesichertenNetzdurchdasVPN eineBedrohungfur bessergesicherteNetzedarstellenkonnen.

2.3 Nicht durch Fir ewallsabgedeckteSicherheitsprobleme

Firewallswerdenoft als“Allheilmittel” fur dieNetzwerksicherheitangesehen.Ein Firewall istein Zugriffskontrollmechanismus,derNetzein verschiedeneSicherheitsbereicheaufteilt. UmfalscheErwartungenzu verhindern,soll auchaufgefuhrt werden,wasFirewalls nicht leistenkonnen.

KeineKontrolle desinternenVerkehrs: Uber denFirewall findet nur die KommunikationzwischeninternemundexternemNetzstatt.DerDatenverkehrzwischeninternenSyste-menuntereinanderkanndurchdenFirewall nicht kontrolliert werden.Fur denSchutz

23

gegenInsider-Angriffe ist daherweiterhineineAbsicherungderinternenSystemeerfor-derlich. In manchenFallen kannaucheineweitereAufteilung desinternenNetzesinmehrereuber(Intranet-)Firewalls getrennteSicherheitszonensinnvoll sein.

Kein SchutzgegenAbhoren oder Manipulation ubertragener Daten: Ein Firewall kannAn-griffe nurdurchUberprufungderubertragenenDatenerkennen.DaeinerPacketScreenfur dieseUberprufung nur die Protokoll-Headerzur Verfugungstehen,sind hier nursehreinfachePlausibilitatstestsmoglich.12 Proxieskonnenzwar auchdie ubertragenenDateninhalteuberprufen, jedochermoglicht auchdies keineErkennungvon Manipu-lationenan ubertragenenDaten(z.B. TCP-Hijacking). StatteinesZugriffskontrollme-chanismussind kryptographischeVerfahrenzur Absicherungder ubertragenenDatenerforderlich.

KeineZugriffsk ontrolle auf verschlusseltenDaten: DerEinsatzkryptographischerVerfah-ren soll dasAbhorenoderdie Manipulationvon ubertragenenDatenverhindern.Da-durchwird gleichzeitigaucheineKontrolle dieserDatendurcheinenFirewall verhin-dert.

BegrenzteKontrollmoglichkeitendesFir ewalls: ProxiesundAnwendungs-Gatewayserhal-tenzwar Zugriff auf alle ubertragenenDaten,waseineVielzahl von Angriffen theore-tischerkennbarmacht.In derPraxisubersteigenaufwendigeUberprufungenjedochdieLeistungsfahigkeit desFirewalls.

Zur Absicherungder aufgefuhrtenProblememussenandereSicherheitsmechanismeneinge-setztwerden.Uberdie aufgefuhrtenProblemehinauskannderFirewall selbstzumZiel vonAngriffen werden,wasschwerwiegendeKonsequenzenhabenkann,wenndie Sicherheital-lein vom Firewall abhangt und die Sicherheitsmaßnahmenauf den internenSystemenver-nachlassigtwurden.

Ein weiteresProblemsind“Denial of Service”Angriffe, daderFirewall gewollt alsFlaschen-hals in der Kommunikationzwischeninternemund externemNetz eingefuhrt wird, um hiereineKontrollezu ermoglichen.“Denial of Service”Angriffe auf diesenEngpaßhabendaherweitreichendeFolgen,wennderFirewall gegendieseAngriffe nicht resistentist.

3 Kryptographische Verfahrenund Protokolle

In diesemAbschnitt wird dargestellt,was Kryptographie ist (vgl. Abschnitt 3.1). Es wirddiskutiert,warumesnotwendigist, Kryptographiezur Sicherungvon einzelnenKommuni-kationsbeziehungeneinzusetzen.Danachkonnenfur immerwiederkehrendeAufgabestellun-gengrundlegendenAlgorithmendiskutiertwerden(vgl. Abschnitt3.3). DaraufaufbauendeSchutzmechanismenwerdenwiederumin kryptographischenProtokolleneingesetzt.

12 IP-SpoofingAngriffe konnenubereinfacheRegeln[16] teilweiseerkanntundabgewehrtwerden.

24 3 KRYPTOGRAPHISCHEVERFAHREN UND PROTOKOLLE

In Abschnitt3.4werdeneinigedieserkryptographischenProtokolle im Detailvorgestellt.Die-seDarstellungsoll einenfundiertenEinblick in die jeweiligenDienstevermitteln,diedasPro-tokoll anbietet.Gleichzeitigwird die Verwendungder kryptographischenMechanismenzurErfullung der Dienstedargestellt. Alle vorgestelltenProtokolle werdenaußerdembewertet.Ziel der Bewertungist es,die EignungdesProtokolls zum Schutzvon Kommunikationsbe-ziehungenherauszustellen.Die Bewertungsoll zeigen,wie gut die Protokolle denjeweiligenDiensterbringen.

Die WahlderProtokolle orientiertsichamTCP/IP-Protokollstapel.Eswird fur jedeSchichtindiesemModell mindestenseinProtokoll vorgestellt,umzuverdeutlichen,daßin Abhangigkeitvom (Schutz)Zieldie gleichenMechanismenauf verschiedenenEbeneneingesetztwerdenkonnen. Gleichzeitigsind die Protokolle so ausgewahlt, daßmit hoherWahrscheinlichkeitauchdie zukunftig im InternetverwendetenkryptographischenProtokolle abgedecktwerden.Esist zurZeit nochnichtmit Sicherheitvoraussagbar, welchedervorgestelltenProtokolle sichlangerfristigdurchsetzenwerden.Immerhinist esmoglichanzugeben,anwelchenProtokollenmit demgroßtenEinsatzgearbeitetwird.

3.1 Inf ormale Definition: Kryptographie und verwandteBegriffe

Als KryptographiebezeichnetmandieKunstundWissenschaft,Nachrichtengeheimzuhalten.DasProblem,Nachrichtengeheimzuhalten,entstehtdadurch,daßBotschaftennormalerweisegezieltaneinenEmpfangergesendetwerden.Dabeigilt fastimmer die implizite Annahme,daßdieseBotschaftausschließlich fur denEmpfangerbestimmtist.

EineMoglichkeit, dieseAnnahmeexplizit auszudruckenundgleichzeitigdie Geheimhaltungder Botschaftwahrendder Ubermittlungdurchzusetzen, bestehtdarin, die Botschaftzu ver-schlusseln. UnterVerschlusselnverstehtmandaherdenVorgang,einenKlartext in einenGe-heimtext umzuwandeln. Der umgekehrteVorgang,die UmwandlungeinesGeheimtextesineinenKlartext, bezeichnetmanalsEntschlusseln.

Als Kryptoanalysebezeichnetmandie Wissenschaftvom unerlaubtenEntschlusselnvon Ge-heimtexten. Die Kryptoanalyseist somit dasGegenstuck zur Kryptographie;beideWissen-schaftenzusammenbildendasFachgebietderKryptologie. KryptographieundKryptoanalysesindin dermodernenWissenschaftengmiteinanderverbunden.Kryptologenunterzieheneige-neneueAlgorithmeneinereingehendenKryptoanalyse,umbereitsvor einerVeroffentlichungdesAlgorithmusmoglicheSchwachstellenaufzudecken. In der wissenschaftlichenKrypto-logie dientdie KryptoanalysedahervielmehrdemZweck,kryptographischeAlgorithmenzuverbessern.

Im Bereichder Netzwerksicherheitwird die Kryptographiezunehmendeingesetzt,um Bot-schaften(Nachrichten)geheimzu halten. Der besondereNutzender Kryptographiebestehtjedochdarin,daßsiedie Grundlagefur eineReiheweitererwichtigerEigenschaftenundda-zugehorenderMechanismenbildet,die im nachstenAbschnittvorgestelltwerden.

3.2 Kryptographiefur die Netzwerksicherheit 25

3.2 Kryptographie fur die Netzwerksicherheit

Die Kryptographiehatim BereichderNetzwerksicherheiteinewichtigeRolle eingenommen.Sie bildet die Grundlagefur eineVielzahl von Mechanismen,mit denenerfolgreichdie fol-gendenEigenschaftendurchgesetztwerdenkonnen:

Vertraulichk eit: Nachrichtensollennur von denEmpfangernlesbarsein,die derSenderan-gibt. Allen anderenpotentiellenEmpfangernderNachrichtsoll derenInhalt (Informati-on) nicht zuganglichsein.

Im Bereichder Netzwerksicherheithat dasKonzeptder Vertraulichkeit eine weitereAuspragung:Es ist unterUmstandenerwunscht,daßnicht nur die Nachrichtsondernauchdie Kommunikationsbeziehungselbstvertraulichist. Dritte sollenkeineErkennt-nisseuberdenNachrichtenaustauschzwischenSendernundEmpfangernerlangenkonnen.

Integrit at: Integritat bezeichnetdie EigenschafteinerNachricht,unverfalschtzu sein. EineManipulationdurchDritte aneinerNachrichtmußbeimEmpfangererkennbarsein.

Authentizit at: Der Empfangereiner Nachrichtmuß die Moglichkeit haben,die NachrichtzweifelsfreieinemSenderzuordnenzukonnen.Essoll nichtmoglichsein,beimSendendie HerkunfteinerNachrichtunerkanntzu falschen.

Unleugbarkeit: Ein SendersolltenichtdieMoglichkeithaben,dasVersendeneinerNachrichtspaterzu leugnen.Empfangermussendie Moglichkeit haben,nachweisenzu konnen,daßeineNachrichtvon einembestimmtenSendertatsachlichgesendetwurde. EbensosollteesdemSendermoglichsein,denEmpfangseinerNachrichtdurchdenEmpfangerjederzeitnachweisenzu konnen.Der EmpfangerkannsomitdenEmpfangeinerNach-richt nicht leugnen(vgl. ‘Einschreiben’beiderBriefpost).

DieseEigenschaftenkannmangrundsatzlichfur alle Arten derKommunikationfordern.Bei-spielsweiseist auchbei der offentlichen“Briefpost” die Vertraulichkeit der Briefsendungen(Nachrichten)gesetzlichgefordert. DasOffnen einesBriefesdurcheinenDritten ist jedochtrivial; esgibt keineneinfachenMechanismus, derdasOffnendesBriefesdurcheinenDrittenverhindert,um die Vertraulichkeit durchzusetzen.Durch die Kryptographieist man jedochheute,insbesonderebei derrechnerbasiertenKommunikation,in derLage,dieseEigenschaf-tenmit Hilfe entsprechenderMechanismendurchzusetzen.13

Resumee: KryptographischeVerfahrenwerdeneingesetzt,umdieGeheimhaltungundInte-gritat ubertragenerDatenzugewahrleisten.AußerdemermoglichensieeinesichereAuthenti-sierungderKommunikationspartnerundderubertragenenDateneinheiten.

13 Andererseitswird aucherst durch die Computer-basierteKommunikationein effizientesund fur dieKommunikationspartnertransparentesAbhorenmoglich.


3.3 Kryptographische Verfahren und Algorithmen

In diesemAbschnittwerdendie grundlegendenkryptographischenVerfahrenvorgestelltundihre inharentenVor- undNachteileaufgezeigt.Die vorgestelltenVerfahrensindvielfaltig an-wendbar, eshandeltsichum Algorithmen, die fur verschiedeneAufgabeneingesetztwerdenkonnen. Die hier vorgestelltenVerfahrenwerdenvon vielen kryptographischenProtokollenverwendet,umVertraulichkeit, IntegritatundAuthentizitatdurchzusetzen(vgl. Abschnitt3.4).EineImplementationeines(Teil-)Verfahrenswird im folgendenalsMechanismusbezeichnet.

In der modernenKryptographiewerdenin der Regel bekannteAlgorithmeneingesetzt.DaderAlgorithmusbekanntist, kannseineGutedurchKryptologenverifiziert werden.Die Of-fenlegungdesAlgorithmusist außerdemdie Grundlagefur denEinsatzhieraufaufbauenderMechanismenin heterogenenverteiltenSystemen.Unmittelbareinsichtigist daher, daßderGeheimtext nicht nur vom Algorithmusabhangendarf. VielmehrwerdenAlgorithmenzumVer- und Entschlusselnvon Nachrichtenauf dasTupel � Nachricht,Schlussel� angewendet.Die Sicherheitbasiertsomitauf derGeheimhaltungdesSchlussels,nicht auf derGeheimhal-tungdesAlgorithmus14.

Die gangigenVerfahrenlassensichanhandderSchlusselin zweiKategorieneinteilen:

� Algorithmenmit symmetrischenSchlusseln(“secret-key algorithms”)

� Algorithmenmit offentlichen(asymmetrischen)Schlusseln(‘public-key algorithms’)

Die Algorithmenbeschreibenmeistenszwei Funktionen:�� ist die Verschlusselungsfunk-tion,diedenKlartext � in denGeheimtext ! umwandelt.Die Entschlusselungsfunktion"��#!$ wird eingesetzt,umdenGeheimtext in denKlartext zuruckzuwandeln.

3.3.1 Algorithmen mit symmetrischenSchlusseln

Kennzeichender symmetrischenAlgorithmenist, daßsie denselbenSchlusselzumVer- undEntschlusselneinerNachrichtbenutzen.Ein Klartext � wird mit demSchlussel% unterVer-wendungderVerschlusselungsfunktion� derartverschlusselt,daßdieEntschlusselungsfunktion" mit demselbenSchlusselausdemGeheimtext wiederdenKlartext zuruckgewinnenkann.Formaldargestelltgilt fur diesymmetrischenAlgorithmen:

& %('*),+-��.�� 0/1!324"5.��6!7 0/8� (1)

) bezeichnetdie Schlusselmenge.Die Schlusselmengeist in der Regel endlich. Die ver-schiedenenWerte,die ein Schlusselin ) annehmenkann,bezeichnetmanalsSchlusselraum(“K eyspace”).

14 Im Idealfall hangt die SicherheiteinesVerfahrensausschließlichvom gewahltenSchlusselab. Ei-ne Disziplin der Kryptoanalysebestehtdarin, SchwacheneinesAlgorithmus aufzudecken, um un-abhangigvom SchlusseldenGeheimtext in Klartext umzuwandeln. Der Vorteil der offentlichenAl-gorithmenbestehtgeradedarin, daßsich ein offentlicherAlgorithmusbei einereingehendenKrypto-analyse“bewahren”kann.Die GuteeinesoffentlichenAlgorithmusist somitbewertbar.

3.3 KryptographischeVerfahrenundAlgorithmen 27

Die HauptvorteilevonAlgorithmenmit symmetrischenSchlusselnsind:

9 Die KomplexitatdieserAlgorithmenist meistgeringeralsvergleichbarsichereasymme-trischeAlgorithmen.Dahererreichtmanmit symmetrischenVerfahrenim allgemeinensehrviel hohereVer- undEntschlusselungsgeschwindigkeiten.

9 Die SchlussellangezumErreicheneinesbestimmtenSicherheitsniveausist bei symme-trischenAlgorithmendeutlichkleineralsbeivergleichbarsicherenasymmetrischenVer-fahren. Dadurchsind symmetrischeVerfahrenauchgut in Bereicheneinsetzbar, beidenendasSchlusselmanagementunter“Platzproblemen”leidet.

DergroßteNachteildieserMethodeliegt im Aufwandfur die Schlusselverwaltung:

1. Bei : Kommunikationspartnern,die alle untereinanderverschlusselteNachrichtenaus-tauschenwollen,mußjederder : Teilnehmer:<;�= symmetrischeSchlusselbereithalten,fallser eineNachrichtvon einemderanderenTeilnehmerbekommt.

2. Die symmetrischenSchlusselmussenubereinensicherenKanalausgetauschtwerden.Wird dersymmetrischeSchlusselinteraktiv ubereinKommunikationssystemvereinbart,ist er abhorbar. DasKommunikationssystem,uberdasdie verschlusseltenNachrichtenspatergesendetwerden,kannnicht ohnezusatzlicheMaßnahmenfur die VereinbarungdessymmetrischenSchlusselsbenutztwerden15.

3.3.2 Algorithmen mit asymmetrischenSchlusseln

Bei diesenAlgorithmen gibt es zwei16 verschiedeneSchlussel. Es gibt einen offentlichenSchlusselzumVerschlusselnderNachricht,derdenKommunikationspartnernzur Verfugunggestelltwird und der nicht geheimgehaltenwerdenmuß. Ein weitererprivater Schlusselwird geheimgehaltenund fur die Entschlusselungder Geheimtexte benutzt,die mit demoffentlichenSchlusselverschlusseltwurden. Da zum Ver- und Entschlusselnzwei verschie-deneSchlusseleingesetztwerden,bezeichnetmandieseAlgorithmenauchalsasymmetrischeVerfahren.

EinewesentlicheAnforderungandieseVerfahrenist, daßderoffentlicheSchlusselkeineBe-rechnungdesprivatenSchlusselsermoglicht.

Analog zu Formel 1 gilt Formel 2 fur die asymmetrischenVerfahren. >@? bezeichnetdenoffentlichenSchlusselzum Verschlusseln. >BA bezeichnetdenprivatenSchlusselzum Ent-schlusselnderNachricht.

?DC�EGF�H�I0J1KML4ANC�OBF#K$IBJ,H (2)

Die HauptvorteiledieserAlgorithmensind:

15 DiesesProblemlaßtsichdurchSchlusselmanagement-Protokolle losen(s.u.)16 In fastallen Fallen gibt esbei asymmetrischenVerfahrenzwei verschiedeneSchlussel. Es gibt auch

Verfahren,diemehrereSchlusselverwenden.


P Die Handhabung der Schlusselvereinfacht sich. Zum Entschlusselnder Nachrichtenbrauchtder Empfangernur einenprivatenSchlussel,unabhangigvom Sender, da alleSenderdenselbenoffentlichenSchlusselfurNachrichtenaneinenbestimmtenEmpfangerbenutzen.

P Eswird kein sichererKanal fur die Schlusselverteilungbenotigt. Alle Empfangerstel-len ihre offentlichenSchlusseljedemzur Verfugung,dereineverschlusselteNachrichtsendenmochte.

Die HauptnachteiledieserAlgorithmensind:

P Die Komplexitat ist hoher als bei vergleichbarensymmetrischenVerfahren. Es wer-denin derRegel geringereVer- undEntschlusselungsgeschwindigkeitenerreichtalsbeisymmetrischenVerfahren.

P Die Schlussellangemußim Vergleichzu derSchlussellangevon symmetrischenAlgo-rithmendeutlichgroßersein,umein vergleichbaresSicherheitsniveauzuerreichen.

P DasProblemderGeheimhaltungeinessymmetrischenSchlusselsverlagertsichbei denasymmetrischenAlgorithmenauf dasProblem,die Authentizitat desSchlusselsfestzu-stellen17.

3.3.3 Bitstr om-basierteund Block-basierteAlgorithmen

Ein weitereswichtigesUnterscheidungsmerkmalder Algorithmenist, ob der Text (KlartextoderGeheimtext) bei denVer- und EntschlusselungsoperationenBit fur Bit verarbeitetwirdoderob mehrereBits zusammenals “Block” verarbeitetwerden. Im erstenFall sprichtmanvon einemBitstrom-basiertenAlgorithmus, auchBitstrom-Chiffre genannt. Im zweitenFallsprichtmanvoneinemBlock-basiertenAlgorithmusoderauchvoneinemBlock-Chiffre.

DiekryptographischenOperationen,diederjeweiligeAlgorithmusausfuhrt,werdenbeiBitstrom-basiertenAlgorithmen auf jedemeinzelnenBit desTextes ausgefuhrt. Bei den Bitstrom-basiertenAlgorithmenist daherdie Textlangebeliebig. Da die Block-basiertenAlgorithmenimmer mehrereBits auf einmal verarbeiten,mussendie Texte in der Regel ein Vielfachesder Blockgroßelang sein. Dazusind die Texte vor demVerschlusselngegebenenfalls durchAnhangenvon weiterenZeichenandie Blocklangeanzupassen.TypischeBlocklangenorien-tierensich in der Regel an der GroßeverbreiteterCPU-Register. So sind beispielsweisedieBlocklangen64Bit und128Bit gebrauchlich.

17 Einfachdargestelltbedeutetdie VeroffentlichungeinesSchlusselsmit demBezeichner“SchlusselderPersonX” nicht, daßdieserSchlusselvon PersonX tatsachlichgeneriertwurde. Die VerknupfungderIdentitat einerPersonoderallgemeineinesSchlusselinhabersmit einembestimmtenSchlusselist nichtBestandteilderasymmetrischenAlgorithmen.

3.3 KryptographischeVerfahrenundAlgorithmen 29

3.3.4 Weitereelementare Funktionen fur kryptographische Protokolle

Es gibt weiterewichtige Funktionen,die in vielen kryptographischenProtokollen eingesetztwerden.DieseFunktionenubernehmenelementare,immerwiederkehrendeAufgabenbeidenProtokollen. Die wichtigstenFunktionenwerdenkurzvorgestellt:

Generieren von kryptographisch starken Zufallszahlen: VielekryptographischeProtokol-le benotigenZufallszahlen,beispielsweisefur Initialisierungenvon Variablenfur kryp-tographischeBerechnungen.Damit die Protokolle nicht aufgrundvon vorhersagbarenPseudozufallszahlenangreifbarsind,benotigt mankryptographisch starke Zufallszahl-generatoren. VondiesenZufallszahlgeneratorenwird verlangt,daßesohnedieKenntnisdesInitialwertesunmoglich18 ist, ausderKenntnisdervorherigenZufallszahlenunddesAlgorithmusdennachstenZufallswertvorherzusagen.

Generieren von kryptographischen Hash-Werten: EineHash-Funktionbildetauseinembe-liebig langenZeichenstromeinenHash-Wert konstanterLange. Die AnwendungvonHash-Funktionenist vielfaltig, beispielsweisezumschnellenVerwaltenvon Symbolta-bellenbeimCompilerbauoderauchzumschnellenZugriff aufDatensatzebeiDatenban-ken. EineHash-Funktionkannauchzur Integritatsprufungeingesetztwerden.StimmtderHash-WerteinerBotschaftvor demVersendenmit demHash-Wert uberein,dernachdemEmpfangberechnetwird, dannist die Botschaftnicht verandertworden.Fur dieseHash-FunktionenmussenjedocheineReihevonRandbedingungeneingehaltenwerden,damitmansiealskryptographisch sicher bezeichnenkann:

Q Esmußunmoglich sein,einenText zu finden,dereinenvorgegebenenHash-Wertergibt. WennjemandeinenbestimmtenHash-Wert vorgibt, danndarf esmit ver-tretbaremAufwandnichtmoglichsein,einengeeignetenEingabetext fur dieHash-Funktionzufinden,sodaßderVorgabewerterrechnetwird.

Q Es muß unmoglich sein, zu einemgegebenenText mit einemdazugehorendenHash-Werteinenzweiten— vomerstenverschiedenen— Text zufinden,derden-selbenHash-Werthat.

Q Es mußunmoglich sein,zwei beliebigeabervoneinanderverschiedeneTexte zuwahlen,sodaßsiedenselbenHash-Werthaben.

Wenndie beidenerstenBedingungenerfullt sind,sprichtmanbereitsvon einerkrypto-graphischsicherenFunktion,einersogenannten“one-way” Funktion.Die dritte Bedin-gungist eineVerscharfungder zweiten. Funktionen,die zusatzlich der dritten Bedin-gunggenugen,werdenalskollisionsfrei (“collision resistant”)bezeichnet(vgl. [34]).

Generieren von hochauflosendenZeitstempeln: Eine Nachricht, die verschlusseltwurde,kannvon einemDritten auchohneweitereKenntnissedesInhaltsmißbrauchtwerden.

18 Mit “unmoglich” wird im folgendenausgedruckt, daßeszur Zeit keinenbekanntenAlgorithmusgibt,dereineeinfacheundschnelleBerechnungermoglicht. “Unmoglich” bedeutetin ZusammenhangmitKryptoanalyse:“Etwas ist aufgrunddesunvertretbarhohenAufwands(Zeit und/oderKosten)nichtmoglich.”


Es sind Angriffe (“replay attacks”)bekannt,bei denenabgehorte Botschaftenbenutztwerden,um sie demselbenEmpfangeroderaucheinemanderenEmpfangererneutzuubermitteln. Dazu werdendie abgehorten Nachrichtenvom Angreifer erneutin dasKommunikationssystemeingespielt.Ist dieBotschaftbeispielsweiseeineverschlusselteBankuberweisung,konntedurcheinenWiederholungsangriff die gleicheUberweisungmehrfachveranlaßtwerden.

Ein einfacherMechanismus,um Wiederholungsangriffe abzuwehren,ist die IntegrationeinesZeitstempelsin die Nachricht.EineNachricht,die mehrfachmit demidentischenZeitstempelbei einemEmpfangereintrifft, kannalsWiederholungidentifiziertwerden.Es handeltsichhierbeinicht um einenkryptographischenMechanismus,allerdingsistauchdie Zeitstempelgenerierungund die damit zusammenhangendeUhrensynchroni-sationvon grundlegenderBedeutungfur viele kryptographischeProtokolle. Eine ho-heAuflosungderZeitstempelist aufgrundderhohenVerarbeitungsgeschwindigkeit derKommunikationssystemeerforderlich.WennmehreretausendNachrichtenproSekundeversendetwerdenkonnen,dannist sicherzustellen,daßentsprechendgenaueZeitstem-pel eineUnterscheidungdereinzelnenNachrichtenermoglichen.

Digitale Signaturen: Mit asymmetrischenVerfahrenist es moglich, Dokumentedigital zu“unterschreiben”.DazuverwendetderUnterzeichnerseinenprivatenSchlussel,ument-wederdasDokumentodereinenHash-Wert (s.o.) desDokumenteszu verschlusseln.Mit demoffentlichenSchlusselkanndannjederdie Herkunft desDokumentesverifi-zieren. DasEntschlusselnmit demoffentlichenSchlusselergibt entwederwiederdenKlartext desDokumentesodereinenHash-Wert, der mit demberechnetenHash-WertdesDokumentesverglichenwerdenkann.

Resumee: Die heuteverwendetenkryptographischenAlgorithmen sind klassifizierbarinsymmetrischeundasymmetrischeVerfahren.Die Algorithmenverarbeitenentwedersequen-tiell einzelneBits odergroßereBitblocke festgelegterLange.Fur denEinsatzin heterogenen,verteiltenSystemenmussenoffentlichbekannteAlgorithmenverwendetwerden.Esgibt wich-tigeelementareFunktionen,dievonvielenkryptographischenProtokollenverwendetwerden.Das Berechnenvon Digitale Signaturenund kryptographischenHash-Wertenist besonderswichtig fur die Authentisierung.

3.4 Inf ormale Definition: Kryptographische Protokolle

Die obendargestelltenVerfahrensinddie Grundlagefur eineVielzahlkryptographischerPro-tokolle. Die kryptographischenProtokolle wurdenentwickelt, um Dienstebereitstellenzukonnen,die Authentizitat,Vertraulichkeit, Integritat undUnleugbarkeit fur Kommunikations-beziehungenanbieten. Der Begriff kryptographischesProtokoll wird auchfur grundlegen-dekryptographischeAlgorithmenbenutzt,wie beispielsweisedas“SimultaneUnterzeichnenvon Dokumenten”(vgl. [38, S.118ff]). Im folgendenwird der Begriff allerdingsauf Kom-munikationsprotokolle eingeschrankt,diekryptographischeAlgorithmenzurAbsicherungder

3.5 Infrastrukturfur dieSchlusselverteilung 31

Kommunikationverwenden.Die folgendeinformaleDefinition faßtdiewesentlichenAspektezusammen:

Ein kryptographischesProtokoll ist eine festgelegte Abfolge von Handlungenzweier odermehrererKommunikationspartner, die der Erfullung einerKommunikationsaufgabedienen.Teil der Handlungenist die Verwendungvon kryptographischenVerfahren,um die in Ab-schnitt 3.2 dargestelltenEigenschaftendurchzusetzenoderzumindestVerstoßegegendieseEigenschaftenzuerkennenbzw. nachzuweisen.

Bevor in Abschnitt4 auf kryptographischeProtokolle innerhalbderTCP/IP-Protokollfamilieeingegangenwird, diskutierendiefolgendenUnterabschnittegrundlegendeAspektederSchlusselverwaltung.Der Zugriff auf offentliche Schlusselerforderteine normierteoder per Konvention festge-legte Infrastruktur. DieserAspektwird in Abschnitt3.5 aufgegriffen. Die Verschlusselungvon Daten einer Kommunikationsbeziehungerfordert bei fast allen Protokollen nebenei-ner Authentisierungmit offentlichenSchlusselndie Etablierungvon sogenanntenSitzungs-schlusseln. DieseSitzungsschlusselwerdenmit speziellenProtokollen etabliert,die alsSub-protokolle in vielen kryptographischenProtokollen vorkommen. Eine Einfuhrungin diesesSchlusselmanagementgibt Abschnitt3.6.

3.5 Infrastruktur fur die Schlusselverteilung

Authentisierungist einesehrwichtige Funktionin verteiltenSystemen.WennDienstenichtoffentlich angebotenwerden,sondernnur bestimmtenPersonen,Rechnernoder Prozessenzuganglichseinsollen,mußvor jedemZugriff die Identitat desDienstanforderndenuberpruftwerden.

Bei der rechnerbasiertenKommunikationist sicherzustellen,daßdie fur eineIdentifizierunggeeignetenInformationennicht verfalschtodervon Dritten vorgetauschtwerden. Wir spre-chendahervon starker Authentisierung, wenn mit Hilfe kryptographischerProtokolle einesichereIdentifizierungder beteiligtenKommunikationspartnermoglich ist19. Wenn fur dieAutorisierungeinesZugriffs uberdie AuthentisierunghinausweitereInformationennotwen-dig sind, mussendieseInformationen(beispielsweise“Credentials”,Tickets,etc.) ebenfallssicherubertragenwerden.

Unmittelbareinsichtigist, daßNachrichten,die mit symmetrischenSchlusselnverschlusseltsind, eindeutigdem Kommunikationspartnerzugeordnetwerdenkonnen. Diesesymmetri-schenSchlusselkonnenvon denkryptographischenProtokollen fur jedeKommunikationsbe-ziehungneuetabliertwerden(vgl. Abschnitt 3.6). Zuvor mussensich jedochdie Kommu-nikationspartneruntereinanderauthentisieren,um sicherzu sein,daßkeinefremdeIdentitatvorgetauschtwird.

Fur dieseinitiale Authentisierungwerdenin derRegel Zertifikateverwendet.HierbeihandeltessichumbeglaubigteoffentlicheSchlussel,beideneneineZuordnungdesSchlusselsmit ei-

19 EssindauchDienstedenkbar, bei denensichnur einerderKommunikationspartneridentifizierenmuß.Zum BeispielauthentisiertsichbeimSSL-Protokoll nurderServerbeimClient (vgl. Abschnitt4.3).


ner Identitat durcheine“CertificationAuthority” (CA) vorgenommenwurde. Im Internet,andasmehrereMillionen Rechnermit entsprechendvielenBenutzernangeschlossensind,mußeseffizienteMethodengeben,Schlusselfur die Kommunikationzu verwalten.Um beispiels-weiseasymmetrischeVerfahrenmit offentlichenSchlusselnim großenUmfangeinsetzenzukonnen,ist eineInfrastrukturerforderlich,dieesjedemBenutzererlaubt,nacheinemeindeutigspezifiziertenVerfahreneinenbestimmtenoffentlichenSchlusselaufzufinden.

TypischeDienstemit entsprechendenProtokollen,diedieseSchlusselverteilungundSchlusselorganisationtechnischrealisierensind:

X.500Verzeichnisdienst: Der X.500 Verzeichnisdienstimplementiertein universellesver-teiltesVerzeichnis,in demauchoffentlicheSchlusselhinterlegt werdenkonnen. Ent-sprechendeProtokollspezifikationenregeln denZugriff auf die Informationenin demverteiltenVerzeichnis. Ein Schlusselkann dannwie jede andereInformation diesesVerzeichnissesabgerufenwerden.Dazubenutztein AnwendereinendemfunktionalenModell von X.500 entsprechenden“Directory UserAgent” (DUA), der seineAnfrageanverteilte,kooperierende“Directory ServiceAgents”(DSA)weiterleitetunddie Infor-mationenfur denBenutzeraufbereitet[19].

SpezialisierteSchlusselverwaltung: NebendemallgemeinenVerzeichnisdienstX.500, derunteranderemauchoffentlicheSchlusselspeichernkann,gibt esspezialisierteDienstefur die Schlusselverwaltungund -verteilung. DasbekanntesteBeispielsind die “K ey-Server” fur PGP-Zertifikate. DiesespezialisiertenServer sind ahnlich den DSAs imInternetverteilt undtauschenuntereinanderneueSchlusselaus.DurchdiesenAbgleichwerdenneueSchlusselinnerhalbkurzerZeit weltweit verfugbarund konnenvon denAnwendernlokal hinterlegt undabgeholtwerden.

Zu denvorgestelltenVerfahrenist anzumerken,daßhierausschließlichdietechnischenAspek-te fur dieVerteilungunddenZugriff auf offentlicheSchlusselgeregeltwerden.Ein sehrwich-tigerAspektist jedochdieVerifizierungderIdentitat,alsodieZuordnungvonPersonen,Grup-penoderProzessenzu hinterlegtenSchlusseln.Hierfur sindeineReihevon organisatorischenMaßnahmenerforderlich,dieunterdemNamen“(Policy) CertificationAuthority” bzw. “TrustCenter”diskutiertwerden.DieseAspektekonnenhiernichtnaherdargestelltwerden,alsEin-stieg in die Thematiksei[22] empfohlen.

3.6 Protokolle fur dasSchlusselmanagement

Fur die Verschlusselungvon Kommunikationsbeziehungenwerdenin der Regel sogenannteSitzungsschlussel(“sessionkeys”) vereinbart. Dies sind kurzlebigeSchlusselfur die DauereinerKommunikationsbeziehung.Die Verwendungvon kurzlebigenSchlusselnhat mehrereVorteile:

R Die SchlusselwerdenbeiBedarfgeneriertundverteilt,siebrauchennichtaufdenloka-lenRechnerplattengespeichertwerden.DadurchsinktdasRisiko,daßbeieinemAngriffaufeinenRechnerderAngreiferZugriff auf fremdeSchlusselerhalt.

3.6 Protokolle fur dasSchlusselmanagement 33

S Da die Schlusselnur fur kurzeZeit benutztwerden,ist der Wert einesdurchKrypto-analysegewonnenenSchlusselsfur einenAngreifersehrbegrenzt.Er kannbestenfallsdie Kommunikationsbeziehungentschlusselnbzw. angreifen,dessenSchlusselgewon-nenwurde. WeitereKommunikationsbeziehungen,die mit anderenSitzungsschlusselnabgesichertwerden,bleibenunberuhrt.

S Jewenigerein Schlusseleingesetztwird, destowenigerGeheimtext kannmit diesemSchlusselfur eineKryptoanalysein Verbindunggebrachtwerden,destoschwierigeristesbeivielenAlgorithmen,denSchlusselzuberechnen.

Es gibt zwei grundsatzlich verschiedeneAnsatze,wie Sitzungsschlusselvereinbartwerdenkonnen.Die Kommunikationspartnerkonnendie Sitzungsschlusselentwederuntersichaus-handeln(vgl. Abschnitt59)odereinenunparteiischenDritten,densievertrauen,in dieSchlusselvereinbarungeinbeziehen(vgl. Abschnitt3.6.2).

3.6.1 Protokolle basierendauf Diffie-Hellman

Bei dennachdenErfindernWhitfield Diffie undMartin HellmanbenanntenAlgorithmuswer-denlediglich zwei NachrichtenzwischendenbeidenKommunikationspartnernausgetauscht,um einenSitzungsschlusselzu vereinbaren.EntscheidendandiesemAlgorithmusist, daßesdurchAbhorender beidenNachrichtennicht gelingt, dassogenanntegemeinsameGeheim-nis (“sharedsecret”),dasals Grundlagefur denSitzungsschlusseldient, zu berechnen.Ab-bildung 9 zeigt dasProtokoll und die Rechenoperationenfur deneinfachenDiffie-HellmanAlgorithmus.

Alice berechnetzuerstdenWert T undschicktdiesenanBob. Bob berechneteinenWert Uundsendetdiesenzuruck anAlice. Die dafur benutztenZahlen V�WYX musseneinigenRandbe-dingungengenugen(vgl. [30]), entscheidendist jedoch,daß TZWYU@W[V�WYX nicht geheimgehaltenwerdenmussen. Es mussenlediglich \]WY^ geheimgehaltenwerdenund esgilt fur denSit-zungsschlussel_ :

_a`1_cbd`8V-e4f mod X (3)

DasDiffie-HellmanProtokoll hat in seinerUrfassungein wesentlichesManko: esist anfalliggegen‘Man in theMiddle’ (MiM)-Angrif fe. Bei dieserArt vonAngriffenkanneinunbekann-ter Dritter die beidenNachrichtenabfangenund manipulierteNachrichtenan der StellederUrsprungsbotschaftweiterleiten.

Das ursprunglicheDiffie-HellmanProtokoll kann auf viele Arten verbessertwerden. Bei-spielsweiseist esmoglich, MiM-Angrif fe dadurchabzuwehren,daßmandie Diffie-HellmanNachrichtenderSchlusselvereinbarungsigniert.

Ein weiteresSchlusselmanagementprotokoll mit demNamen“EncryptedKey Exchange”gehtebenfallsvomkombiniertenEinsatzasymmetrischerundsymmetrischerVerfahrenaus(vgl. [7]).


X

Y

Allice

X=g^x mod n

k= Y^x mod n

Bob

Y=g^y mod n

k‘=X^y mod n

Abbildung9: Diffie-HellmanProtokoll

3.6.2 Protokolle basierendauf KDC

EineandereMoglichkeit,Sitzungsschlusselzuvereinbaren,bestehtdarin,sichaneinenSchlusselverteiler(“K ey DistributionCenter”,KDC) zuwenden.

Dazuist eserforderlich,daßalle Teilnehmermit demKDC einensymmetrischenSchlusselvereinbarthabenoderentsprechendeasymmetrischeSchlusselpaareexistieren.Weiterhinwirdvorausgesetzt,daßalle Kommunikationspartnerdem KDC vertrauenund dieserseinerseitskein Interessehat,einenAngriff aufeinenderKommunikationspartnerdurchzufuhrenoderzuunterstutzen.Man bezeichnetdenKDC auchalsVermittler (“arbitrator”).

In diesemAbschnittwird dasKonzeptdesKDC anhanddesbekanntestenKDC-basiertenPro-tokolls diskutiert.Eshandeltsichum dasKerberos-Protokoll (vgl. [27]), dashier vereinfachtdargestelltwird.

WennAlice eineverschlusselteKommunikationsbeziehungmit Bob eingehenwill, erfragtsieeinenSitzungsschlusselbeimKDC. Im einzelnensindvereinfachtdargestelltfolgendeSchritteerforderlich:

1. Alice sendetdie Anfrage g�hjilk#g7m4npo fur einenSitzungsschlusselmit ihrer und BobsKennung20 anKDC.

35

2. DerKDC generierteinenzufalligenSitzungsschlusselq , einenZeitstempelr undeineZeitspannes , die dieGultigkeit desSchlusselsq angibt.

3. DasTupel t K,T,L u wird nunmit denSchlusselnvon Alice undvon Bob verschlusseltundbeideGeheimtexte ( vxwly#qZz[r{z4s<z4|p}~z~vD�By6qZz[r{z4s<zY��} ) werdenanAlice gesendet.

4. Alice verschlusseltmit demneuenSitzungsschlusseleineNachrichtbestehendausdemZeitstempelund ihrer Identitat und sendetdieseNachricht( vD��y#�7z[r�} ) zusammenmitdervomKDC mit BobsSchlusselverschlusseltenNachricht( vD�@y6qZz[r{zYs{z[��} ) anBob.

BobkanndurchEntschlusselnderzweitenNachricht

� denSitzungsschlusselq erhalten,� die Bestatigungerhalten,daßdie Nachrichtvom Vermittler verschlusseltwurde,

danur dieserseinenSchlusselvD� kennt,� somitderZeitstempelvomVermittlergeneriertwurde,� derVermittlerAlice alsAnfragendeansieht.

5. BobbestatigtdenEmpfangdesSitzungsschlussels,indemer dieNachrichtvD��y�r��8��} anAlice sendet.

Der Sitzungsschlusselist nunetabliertundkannfur alle weiterenVerschlusselungenderSit-zungzwischenAlice und Bob verwendetwerden. DiesesVerfahrenbenutztunteranderemdasGenerierenvon Zeitstempelnund erfordertsynchronisierteUhren bei allen Beteiligten(vgl. Abschnitt3.4). In Abbildung10 ist dasProtokoll graphischdargestellt.

Resumee: Die fur eineVer- undEntschlusselungwichtigenSchlusselmussenvor derVer-schlusselungder KommunikationsicherzwischendenbeteiligtenKommunikationspartnernausgetauschtwerdenbzw. sichervereinbartwerden. DieseSchlusseletablierungkanndurchSchlusselaustausch-Protokolle erfolgen. Verbreitetsind Schlusselaustausch-Protokolle, dieentwederdirekt zwischendenKommunikationspartnerSchlusseletablieren,und Protokolle,die einenvertrauenswurdigenSchlusselverteilerin die Etablierungeinbeziehen.

4 Kryptographische Protokolle in der TCP/IP-Familie

In diesemAbschnitt werdenImplementierungenverschiedenerkryptographischerProtokol-le diskutiert. DieseProtokolle sind heuteverfugbarund beschreibensomit den StandderTechnik. Abbildung 11 zeigt, daßdieseProtokolle auf verschiedenenEbenendesKommu-nikationssystemsangesiedeltsind. Die wichtigstenProtokolle jederEbene(in Abbildung11hervorgehoben)werdenin den folgendenAbschnittengenauerdiskutiert. Die Darstellungkannnicht vollstandigsein,dastandigneueVerfahrenundProtokolle entwickelt werden.

20 Die Kennungdient nur der Beschreibung der Endpunkteder Kommunikationsbeziehung,fur die einSitzungsschlusselangefordertwird. Hiermit wird nochkeineIdentifizierungdurchgefuhrt.

36 4 KRYPTOGRAPHISCHEPROTOKOLLE IN DERTCP/IP-FAMILIE

Anf (A,B)

VA (K, T, L, B), VB(K, T, L, A)

VK(A, T), VB(K, T, L, A)

VK(T+1)

Alice

Alice kenntSitzungsschl.

K

Alice und Bob kennen den Sitzungsschluesselund

beide wissen, dass der andere den Sitzungsschluessel kennt!



KDC

generiere:K, T, L





Bob

Bob kenntSitzungsschl.

K



Abbildung10: KerberosProtokoll

4.1 Protokolle unterhalb von IP

Esgibt eineVielzahlvon NetzwerktechnologienundZugriffsverfahren,die unterhalbvon IPeingesetztwerdenkonnen.Zur Verdeutlichungwird alsBeispieldie Verschlusselungauf Ba-sis von Ethernetdargestellt. Es gibt vergleichbareLosungenfur andereNetztechnologien(beispielsweise“CellCase”fur ATM).

Ethernet,FastEthernetundGigabitEthernethabenein einheitlichesRahmenformat(vgl. Ab-bildung12). Fur dieseProtokolle laßtsicheineinfacherVerschlusselungsmechanismusimple-mentieren,derentwederfur die Endsystemetransparentist odervon denEndsystemenselbstvorgenommenwird.

Um sicherzustellen,daßdie Verschlusselungauf Ethernet-Ebenemit vorhandenenNetzkom-ponenten(Hubs,Switche)kompatibelist,mussenzweiRandbedingungeneingehaltenwerden:

1. Die Praambel,Senderadresse,EmpfangeradresseunddasTyp/Langenfelddurfennichtverschlusseltwerden.Die Praambelwird fur die SynchronisationdesSendersmit den

4.1 Protokolle unterhalbvon IP 37

Anwendungsschicht

(SMTP, HTTP, ...)

(Application Layer)

Transportschicht

(Transport Layer)

(TCP, UDP)

IP-Schicht

(IP)

(Internet Layer)

Mail WWW Payment Andere

SSH Kerberos S-HTTP Secure DNSISAKMP/Oakley

TLS

IPsecSKIP

DESlogin

STel

SRA

DASS

Kryptoknight

EISS TESS

Sesame

SunSecRPC

PEM

PGP

MOSS

S-MIME

HTTP-S STT

SSL

PCT

swIPe

CryptoNodes

CellCase

KryptoLANs

Login, Filetransfer

SEPP...

SET

(Network Interface)

(Ethernet, FDDI, ATM, ...)

Hardware

IP Modell

Netzwerk Schnittstelle

Abbildung11: VerfugbarekryptographischeProtokolle

Empfangernbenotigt. Die Empfangeradressemußerhaltenbleiben,umdenEmpfangeridentifizierenzukonnen.DieSenderadressesolltenichtverandertwerden,davieleSwit-chedieseAdressendynamischihrenSchnittstellenzuordnenunddurchzuviele “Adres-sen”unnotig belastetwerden.Die Typ/Langenangabesolltenicht verandertwerden,danichtausgeschlossenwerdenkann,daßSwitchediesesFeldfur die Speicherverwaltungbenutzen.

2. Die maximaleLangedesRahmensvon 1526Byte darf nicht uberschrittenwerden,daes hier zu unvorhersehbarenFehlernbei der Ubertragungund beim Empfang kom-menkann. Dies ist besondersin denFallen zu berucksichtigen,in denenfur die Ver-schlusselungBlock-basierteAlgorithmen(vgl. Abschnitt3.3.3)verwendetwerden,dahier eventuellzusatzlicheFull-ByteszumErreicheneinesganzzahligenVielfachenderBlocklangeandieDatenangehangtwerdenmussen.

Die Verschlusselungsolltesichdaherauf denDatenbereichbeschranken. Solangedie maxi-maleDatenlangevon 1500Byte nicht uberschrittenwird, brauchtderVerschlusselungsalgo-rithmusauchnicht langenerhaltendzusein.


Daten CRCFS D Empfänger- Sender- LängePräambeladresseadresse Daten

8 Byte 6 Byte 6 Byte 46 - 1500 4 Byte

SFD : Start Frame Delimiter DSAP SSAP Control

8 bit 8 bit

DSAP : Destination Service Access Point

SSAP : Source Service Access Point

Control: Kontroll-Feld

Präambel Typ Daten CRC

8 Byte 6 Byte 6 Byte 46 - 1500 4 Byte

’Frame’-

’LLC-Daten’

’LLC-Daten ’ : LLC-Benutzerdaten

Sender-adresse

Empfänger-adresse

8 (16) bit

Byte

Byte

maximal 1518 Byte

’IEEE 802.2 Logical link control’ (LLC) - Dateneinheit

2 B.

2 B.

Abbildung12: AufbaueinerEthernetRahmens

Ein haufigvorkommendesSzenariofur dieseArt derVerschlusselungist die Koppelungvonzwei Subnetzenuber ein ungesichertes,abhorbaresNetz. Man konntein diesemFall einetransparenteLosungfur diebeteiligtenRechnerdurchzwei“Bridges” erreichen,diezusatzlicheineVerschlusselungbzw. Entschlusselungvornehmen,bevor sieDateneinheitenweiterleiten(vgl. Abbildung13).

Die “Bridges”konntendieVer- undEntschlusselungauchaufBasisderSender- undEmpfangeradressenvornehmen.DashatzweiVorteile:

1. MehrereSubnetzekonnenmit unterschiedlichenSchlusselnkonfiguriertwerden. DieKommunikationzwischenzweiSubnetzenkanndannmit individuellenSchlusselnstatt-finden.

2. Bei speziellenEmpfangeradressen(beispielsweiseeinemRouter)wird keineVerschlus-selungvorgenommen.Damit ist esmoglich, auchunverschlusseltzu kommunizieren,beispielsweisemit Rechnernim unsicherenNetz.

In Abbildung 14 ist die Kommunikationvon Alice ausdemSubnetzI mit Bob im SubnetzII undmit einemInternet-Server (IS) im unsicherenNetzdargestellt.Die “Bridges” ver- und

4.2 Protokolle aufderIP-Ebene 39

virtuelles LAN

Subnetz IBridge

schlüsseln)(Ver/- Ent-

Bridge

schlüsseln)(Ver/- Ent- Subnetz II

(unsicheres Netz)

LAN

Abbildung13: “Bridge” mit Ver- undEntschlusselungaufderEthernet-Ebene

entschlusselnbei Bedarf,also immer dann,wenndie Sende-und Empfangeradressein ver-schiedenenSubnetzeneinesvirtuellenLANs liegen. �7� bezeichnetdie VerschlusselungmitdemsymmetrischenSchlusselder “Bridges”, �$� bezeichnetdie Entschlusselungder Nach-richt.

Ahnliche Verfahrensind auchfur andereNetztechnologiendenkbar. Beispielsweisegibt esVerfahren,die auf Zellen-Ebenein einemATM-Netz verschlusseln. DieseVerfahrenhabendenVorteil, daßsieauchandereProtokolle als IP verschlusselnkonnen.Siesicherndie Ver-traulichkeit derKommunikation,konnenallerdingsnicht zur Authentisierungeingesetztwer-den21. Der Hauptnachteilist, daßdie zur Zeit bekanntenVerfahrenherstellerspezifischundsomitproprietar sind.

Resumee: Die Verschlusselungvon Dateneinheitendurch Protokolle unterhalbvon IP istproprietar underfordertspezialisierteHardware,die auf die verwendeteNetztechnologiezu-geschnittenist. DieseVerfahrensindunabhangigvon IP undkonnendeshalbauchDatenein-heitenvon anderenProtokoll-Familienverschlusseln.

4.2 Protokolle auf der IP-Ebene

Auf derIP-Ebenegibt esmehrerebekannteVerfahren,dieAuthentizitat,IntegritatundVertrau-lichkeit zugewahrleisten.Die wichtigstenProtokollspezifikationenwerdenvoneinerArbeits-gruppe(IPsec)der“InternetEngeneeringTaskForce”(IETF) entwickelt. Eshandeltsichhier-beiumMechanismen,diespeziellfur IPv4undIPv6entwickelt wurden(vgl. Abschnitt4.2.1).

21 Essind hier auchMechanismenzur Authentisierungdenkbar. DieseVerfahrenwurdenabernicht mitdemZiel entworfen,einenMechanismusfur dieAuthentisierungzuentwickeln.


Frame (B, A, Data)

Frame (A, B, Data)

Frame (IS, A, Data)

Frame (A, IS, Data)

Frame (B, A, VB (Data))

Frame (A, B, VB (Data))

Frame (IS, A, Data)

Frame (A, IS, Data)

Frame (B, A, Data)

Frame (A, B, Data)

Alice Bridge I

Verschluesselnvon Data

mit VB

Entschluesselnvon Data

mit EB

IS

Bridge II

Entschluesselnvon Data

mit EB

Verschluesselnvon Data

mit VB

Bob

Abbildung14: SicherungderEthernet-basiertenVLAN-K ommunikation

Ein weitereswichtigesProtokoll auf derIP-Ebeneist SKIP (vgl. Abschnitt4.2.2), dassichzueinemQuasi-Standardentwickelnkonnte.

4.2.1 IPsec

Im folgendenwerdendieSpezifikationenderIPsec-ArbeitsgruppeebenfallsalsIPsecbezeich-net.DieseTerminologieist konformmit derIETF-Terminologie.

IPsecbietetIP basiertenDienstenfolgendeFunktionenan:

� Vertraulichkeit (fur Daten,teilweiseauchfur denVerkehrsfluß)

� AuthentisierungdesPaketursprungs


� Integritat vonverbindungslosenDateneinheiten

� ErkennenundAblehnenvon wiederholtenPaketen

� Zugriffskontrolle

DadieseFunktionenalsDienstderIP-Schichtangebotenwerden,konnensievonallenProto-kollenaufderTransport-undAnwendungsebeneverwendetwerden.

DieseFunktionenwerdenwiederumdurchzweiProtokolle erbracht:

� Spezifikationenbezuglich des“IP AuthenticationHeader”(AH) definierendie Dienstefur die Integritat von verbindungslosenDateneinheiten,AuthentisierungdesPaketur-sprungsundfur dasAblehnenvonwiederholtenPaketen.

� Spezifikationenbezuglichder“IP EncapsulatingSecurityPayload”(ESP)definierendieDienstefur Vertraulichkeit (der Informationenund teilweisefur denVerkehrsfluß)vonverbindungslosenDateneinheiten.ZusatzlichkannauchderESPfur dieIntegritatssicherung,AuthentisierungdesPaketursprungsundAblehnenvonwiederholtenPaketeneingesetztwerden.

Die Protokolle konnenauchkombinierteingesetztwerden,je nachdem,welcheDienstederBenutzeranfordert.

Sowohl AH als auchESPkonnenin zwei verschiedenenModi betriebenwerden. Ublicher-weisewerdendie Dienstefur Transport-oderAnwendungsprotokolle derTCP/IP-Familie er-bracht. AH und ESPwerdenin diesemFall im sogenanntenTransportModus (“transportmode”)betrieben.Es ist aberauchmoglich, IP Dateneinheitenuberein beliebigesNetzhin-weg zu “tunneln”, dasheißt,IP Dateneinheitenwiederumin IP Dateneinheitenzu versenden.In diesemFall werdenESPundAH im TunnelModus(“tunnelmode”)betrieben.

IPsecbenotigt zusatzlichein Schlusselmanagementprotokoll, um Schlusselfur AH und ESPzwischenden Kommunikationspartnernzu vereinbaren. Zu diesemZweck entwickelt dieIPsec-ArbeitsgruppeeineigenesSchlusselmanagementprotokoll unterdemNamen“ISAKMP/OAKLEY”,dasweiteruntenbesprochenwird (vgl. Abschnitt4.4.4).

Ein weitereswichtigesKonzeptder IPsecSpezifikationenist der Sicherheits-Kontext (“se-curity association”,SA). Eine SA ist gekennzeichnetdurchdasTupel � SPI, IPdest,Proto� .“IPdest” ist die Zieladresseder Datagramme,“Proto” gibt an, ob die SA fur ESPoderAHgultig ist22 undder“SecurityParameterIndex” (SPI)dientderUnterscheidungmehrererSAsmit demselbenProtokoll undderselbenZieladresse.

DieseTupel indizierenauf IPsec-Systemeneine“Security AssociationDatabase”(SAD), inder fur jedeSA Kontextparameterabgelegt sind. Dies sind in der Regel Angabenzum ver-wendetenAlgorithmusbeimEinsatzvon AH oderESPundzur Schlussellangesowie andereInformationen,die fur die BearbeitungderDateneinheitenerforderlichsind.

22 SollenESPundAH kombiniertwerden,sindzwei SAsnotwendig.


EinenallgemeinenUberblickzu IPsecfindetmanin [39,24]. In [24] wird die ArchitekturderIPsec-Protokolle dargestellt. In [39] werdenHinweisezum Verstandnisder AbhangigkeitenderverschiedenenDokumentederIPsec-Arbeitsgruppegegeben.

4.2.1.1 IP Authentication Header: Um die Integritat von Datagrammenzu sichernundeine Authentisierungzu unterstutzen,wurde in [25] eine Datenstrukturdefiniert, die in IPDateneinheitenintegriert werdenkann,um daskryptographischeMaterial zu transportieren.Der sogenannte“AuthenticationHeader”(AH) hatdie in Abbildung15dargestellteStruktur.

DasFeld“Next Header”identifiziertdenTypderInformationen,diehinterdenAH-Informationenim Datagrammfolgen.Die Langenangabeerfolgt in 4-ByteWortenabzuglichdemkonstantenWert “2”. SPI identifizierteinenderobenbeschriebenen“SecurityParametersIndex” Werte.Die Sequenznummerwird bei derSA Erstellungmit Null (0) initialisiert undfur jedesPaketinkrementiert. Sollenmehrals �� Paketeversendetwerden,mußrechtzeitigeineneueSAetabliertwerden,da diesesFeld nicht wiederauf Null gesetztwerdendarf. DasFeld varia-bler Lange“AuthenticationData” beinhaltendenWert der Integritatsuberprufung(“IntegrityCheckValue”, ICV).

Security Parameters Index (SPI)

Next Header Length Reserved

Sequence Number Field

Authentication Data (variable)

DataIP TCPAH

Bei der Berechnung von AH berücksichtigte Informationen

AH Header0 7 3115 23 Bit

Abbildung15: “IP AuthenticationHeader”(vgl. [25,S.4ff])

Da die Sequenznummerstrengmonotonsteigendist und im ICV ebenfalls kryptographischabgesichertwird, sind Replay-Angriffe leicht zu erkennen. Nebender Sequenznummerge-hendie in Abbildung15 dargestelltenInformationenmit in die BerechnungdesICV ein. Eshandeltsichhierbeium

� die beim Routing unveranderlichenIP-Header-Informationen(beispielsweiseSender-undEmpfangeradresse)und


� die InformationendesAH-Header(Next Header, Lange,Reserved,SPI,Sequenznum-merundDatenbereichmit notwendigenFull-Byte, die zumZweckderBerechnungaufNull gesetztwerden)sowie

� die NutzdatendesDatagramms(TCP, UDP, ICMP,...)

Zur AuthentisierungkanneineVielzahl von Algorithmeneingesetztwerden. Jedezu IPseckonformeImplementierungmußmindestensdieVerfahren

MD5 “MessageDigest5” (vgl. [37])

SHA-1 “SecureHashAlgorithm 1” (vgl. [31])

unterstutzen.WelchesVerfahreneingesetztwird, mußbei derEtablierungderSA ausgehan-delt werden. Durch die AbsicherungdesDatagrammsmit einemdieserVerfahrenkannderEmpfangerdie IntegritatundAuthentizitatderDatenuberprufen.UnabhangigvomgewahltenStandard-Verfahrenwird der resultierendeHash-Wert auf 96 Bit verkurzt, sodaßderAH imStandardfall eineLangevon24 Bytehat.

4.2.1.2 IP EncapsulatingSecurity Payload: Die HauptaufgabederESPSpezifikationistes,Vertraulichkeit bei derIPsec-basiertenKommunikationsicherzustellen.DaherwurdestatteinesHeaderseinESPPaketdefiniert,umdaskryptographischeMaterialunddieverschlusseltenDatenin IP-Datagrammenzu transportieren.Abbildung87 stellt dasPaketformatgraphischdarundzeigtdie EinbettungdesPaketesin ein Datagrammin Abhangigkeit vom jeweiligenModus.

ESP erfordert symmetrischeVerschlusselung. Damit sowohl Block-basierteals auch Bit-Strom-basierteAlgorithmenverwendetwerdenkonnen,ist im Nutzdatenfeld(“Payload”)einMechanismuszumAnfugenvonFull-Bytesvorgesehen.Eskonnenzwischen0 und255Bytesandie eigentlichenDatenangehangtwerden,beispielsweisezumErreicheneinerbestimmtenBlocklange. Die tatsachlichangefugteAnzahl wird unmittelbarhinter diesenFull-Bytes imFeld“PadLength”eingetragen.DerverwendeteAlgorithmuswird beiderEtablierungdesSAvereinbart.

Die FelderSPIundSequenznummerhabendiegleicheFunktionwie beimAH. OptionalkannmandenESPauchzumAuthentisierenderDatenverwenden.In diesemFall wird derHash-Wert uberdie NutzdatenunddemESP-Kopf gebildetundandenESP-Trailer angehangt. Ei-ne der FunktionenVerschlusselnoder Authentisierenmuß immer vereinbartwerden,beidekonnenmiteinanderkombiniertwerden.

JedeIPseckonformeImplementierungmuß mindestensdie folgendenAlgorithmen fur dieVerschlusselungundAuthentisierungunterstutzen:

DES: “DataEncryptionStandard”im CBCModus(vgl. [1])


ESPTrailer

ESPAuth.

Security Parameters Index (SPI)

Sequence Number

Payload Data with (optional) Padding

Pad Length Next Header

Authentication Data (variable)

Auth.Coverage

Confid.Coverage

Tunnel Mode

ESPTrailer

ESPAuth.

authenticated

DataTCPIPESPIP

encrypted

ESP DataIP

Transport Mode

TCP

authenticated

encrypted

0 8 15 23 31 Bit

ESP Packet

Abbildung16: “IP EncapsulatingSecurityPayload”(vgl. [26, S.4ff])

MD5: “MessageDigest5” (s.o.)

SHA-1: “SecureHashAlgorithm 1” (s.o.)

NULL Authentisierung: Authentisierungwird nicht verlangt

NULL Verschlusselung: Verschlusselungwird nicht verlangt

MD5 undSHA-1 werdenwie bei AH nur zur Authentisierungbenutzt.Die beiden“NULL”-Algorithmenmussendefiniertwerden,dasiebei derInitialisierungderSA vereinbartwerdenmussen,falls keineAuthentisierungoderkeineVerschlusselungerforderlichist.

DESist dereinzigeerforderlicheVerschlusselungsalgorithmus,derimmerimplementiertwer-denmuß.EshandeltsichhierbeiumeinenBlock-basiertenAlgorithmusmit einerBlocklangevon 64 Bit. Der “Cipher Block Chaining” (CBC) Modus(vgl. [2]) legt fest,daßjeweils dervorherige64Bit Geheimtextblockmit demnachsten64Bit KlartextblockdurcheineExklusiv-Oder Operationverknupft wird, bevor der Klartextblock verschlusseltwird. Die einzelnen64 Bit Blocke desGeheimtextessind dadurchnicht mehrunabhangigvoneinander, sondernnur nochzusammenzuentschlusseln.


Der Overheaddurch ein ESP-Paket ergibt sich zu mindestens10 Byte bei Verschlusselungmit DES und mindestens22 Byte bei einer DES-Verschlusselungmit zusatzlicherSHA-1-Authentisierung.Bei der Berechnungsind eventuellnotwendigeFull-Bytes zum ErreichenderDES-Blocklangevon 64Bit nochnicht berucksichtigt.

Nachder Darstellungvon AH und ESPist ersichtlich,daßdie gesamteFunktionalitat alleinvon ESPerbrachtwerdenkann.Ein eigenstandigerAH ist nicht mehrerforderlich.Die IETFentwickelt zurZeit jedochbeideProtokolle weiter.

Bei IPsecist fur die Etablierungeiner SA in der Regel ein Schlusselmanagementprotokollerforderlich. Dasvon IPsecfavorisierteVerfahren“ISAKMP/OAKLEY” wird weiter untendiskutiert(vgl. Abschnitt4.4.4). Die ebenfalls zulassigeaberunpraktikablemanuelleKonfi-gurierungvon SAskannohnezusatzlichesProtokoll vorgenommenwerden.

Sehrungewohnlich ist jedochdie Zusammenarbeitvon IPsecmit einemProtokoll wie bei-spielsweiseISAKMP/OAKLEY, dasein Protokoll auf derAnwendungsebeneist. Zum Auf-bau einer SA muß IPsecden Dienst einesProtokolls der Anwendungsebenein Anspruchnehmen,waseinerUmkehrungdesDienstnehmer/Diensterbringer-Verhaltnissesim Protokoll-stapelgleichkommt. Damit wird zum erstenMal innerhalbder TCP/IP-Protokollfamilie eingrundlegendesEntwurfsprinzipaufgegeben,dasseit JahrenfesterBestandteildesProtokoll-entwurfsist. Normalerweisegilt, daßjedeProtokollschicht denDiensteinerdarunterliegen-denProtokollschicht in Anspruch nimmtund der nachst hoheren Protokollschicht einener-weitertenDienstanbietet.Dies gilt in der KombinationIPsecmit ISAKMP/OAKLEY nichtmehr.

Außerdemwird durchdie EtablierungdesSA zwischenzwei IP-Instanzenquasiein Verbin-dungskontext eingerichtet,obwohl essichbei IP um ein verbindungslosesProtokoll handelt.Die IP-Datagrammesindnicht mehrunabhangigvoneinander, sondernnur durchdie Kontex-tinformationender SA interpretierbar. DadurchkonnenProblemeentstehen,beispielsweisewennzwischenzweiRoutern(“SecurityGateways”,vgl. [24]) verschlusseltwird.

NormalerweisekonnenIP-DateneinheitenzwischenEndsystemenuberbeliebigeWege(“Rou-tes”) unabhangigvoneinandervermitteltwerden.DasInternetkanndaherdurchgeschicktesVermitteln sowohl eine hoheAusfallsicherheitgewahrleisten(durch alternative Routes)alsauchLastverteilungunterstutzen(paralleleRoutes).Dies ist nicht mehrmoglich, wennzweiRoutereinenIPsec-Tunnelaufgebauthaben.Alle Dateneinheitenmussendanndiesendedi-ziertenWeg nehmen.Die Ausfallsicherheitist nicht mehrgewahrleistet,daderAusfall einesderbeidenRouterdieSA zerbrechenlaßt.

EineLastverteilungscheitertauseinemahnlichenGrund.Da die Datagrammenur von Rech-nernentschlusseltwerdenkonnen,die die SA vereinbarthaben,mussendie beidenTunnel-Routerin jedemFall auf der gewahltenRouteliegen,normalerweisemit direktemAnschlußandasjeweiligeSubnetzderKlienten,fur die derTunneletabliertwurde.

Durch die Kontextinformationenist IPsecaußerdemauf eineneueWeiseangreifbar. Wennesgelingt,KontextinformationeneinerSeitezu manipulierenoderzu zerstoren(mit anderenWortendie SA wird angegriffen), tretenFehlerbei der Kommunikationauf (beispielsweise


werdengultige Datagrammeauf derEmpfangsseitealsungultig fehlinterpretiertundvernich-tet). DieseProblememussendurchaufwendigeGegenmaßnahmen,die wiederumdie kriti-sierteVerbindungsorientierungbenotigen,angegangenwerden.

Resumee: IPSecbeschreibtSicherungsmechanismenfur IP-Datagramme.Die gleichnamigeGruppeder IETF arbeitetderzeitan der Standardisierungder Verfahrenzur VerschlusselungundAuthentisierungvonIP-Datagrammen.DazuwerdenzweineueProtokolle (AH undESP)spezifiziert,die einzelnoder in Kombinationverwendetwerdenkonnen. Trotz der vielenkritisiertenProbleme,die dieseProtokolle mit sichbringen,mußdavon ausgegangenwerden,daßsiezukunftig sowohl zurSicherungvonIPv4-alsauchvonIPv6-Dateneinheiteneingesetztwerden.

4.2.2 SKIP

“SimpleKey-Managementfor InternetProtocols”(SKIP, vgl. [6]) beschreibteineweitereSpe-zifikationfur einProtokoll, dasVertraulichkeit undAuthentizitataufderIP-Ebenesicherstellt.

Die wesentlichenUnterschiedezu IPsecmit ISAKMP/OAKLEY bestehendarin,daß

� SKIP keineVerbindungskontextevereinbart,

� SKIP verbindungslosarbeitetundsomitweiterhineinenIP-Datagrammdienstanbietet,

� SKIP uber ein eingebautesSchlusselmanagementprotokoll verfugt und dadurchnichtdenDiensteinesseparatenProtokolls benotigt.

Das eingebauteSchlusselmanagementprotokoll basiertauf zertifiziertenoffentlichenDiffie-HellmanSchlusseln,die entwederuberein beliebigesSchlusselverteilungsprotokoll angefor-dertwerdenkonnen,odervom Systemmanagervor Inbetriebnahmevon SKIP auf denbetei-ligtenRechnerninstalliertwerdenmussen.

Danachkonnenzwei Rechner( � und � ) sichermiteinanderkommunizieren,indemsieeinenimplizitenHauptschlussel(“Master Key”) berechnenund die Dateneinheitenmit einemvondiesem“MasterKey” abgeleitetenSitzungsschlussel(hierPaketschlusselgenannt)verschlusseln.

4.2.2.1 Berechnenvon impliziten Hauptschlusseln: DieBerechnungeinesimplizitenHaupt-schlusselserfolgt ausdemgemeinsamenGeheimnis,daszwischenSender� undEmpfanger� etabliertist. Der offentlicheSchlusselvon � ist gegebendurch �� mod � . NachDiffie-Hellman(vgl. Formel 61, S. 3) existiert dannein gemeinsamesGeheimniszwischen � und� mit �3�[�� -¡¢� mod � , dasin der SKIP-Terminologieauchals “Master Key” ( �a�£� ) fur�x� bezeichnetwird. Mit diesem“Master Key” wird ein zufallig gewahlter Paketschlussel(Kp) mit einemsymmetrischenVerfahrenverschlusselt. Mit demKp werdendie NutzdatendesDatagrammsverschlusselt. In einemSKIP-Paket wird dannder mit dem“Master Key”


ijg mod p

i

öffentlicherSchlüsselSchlüssel

privaterI’s J’s

¤ ¤ ¤¤ ¤ ¤¤ ¤ ¤¤ ¤ ¤

¥ ¥ ¥¥ ¥ ¥¥ ¥ ¥¥ ¥ ¥

g mod pj

IPHdr

Kijn

ijn

Verschlüsselung

VerschlüsselungK

pK Daten¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § § § § § §§ § § § § § § §§ § § § § § § §§ § § § § § § §

pK

Daten¨ ¨ ¨ ¨ ¨ ¨ ¨ ¨¨ ¨ ¨ ¨ ¨ ¨ ¨ ¨¨ ¨ ¨ ¨ ¨ ¨ ¨ ¨¨ ¨ ¨ ¨ ¨ ¨ ¨ ¨

© © © © © © © ©© © © © © © © ©© © © © © © © ©© © © © © © © ©

Daten

Abbildung17: SKIP-Schema

verschlusselteKp zusammenmit denverschlusseltenNutzdatenandenEmpfangergesendet.In Abbildung 17 ist dasGeneriereneinesSKIP-Paketesschematischdargestellt. Der Al-gorithmuszum VersendeneinesIP-Datagrammsdurchein SKIP-Modul ist graphischin derAbbildung18 dargestellt.

BeimEmpfangpruft derEmpfanger, oberbereitsdenPaketschlusselim aktuellenDatagrammentschlusselthat. Dazu fuhrt der Empfangerin typischenImplementationeneineListe mitden Tupeln ª�«7¬M¢®¯#¬±°�²´³Y¬±°jµ und kann so direkt uber den verschlusseltenPaketschlussel( «7¬3¢®�¯6¬±°D² ) den Paketschlussel( ¬±° ) finden. Andernfalls wird (im einfachstenFall uberdie Zuordnungder IP-Senderadressezum offentlichenSchlusseldesSenders)mit Hilfe desoffentlichenSchlusselsdesSendersder“MasterKey” ( ¬a¶£·�² ) berechnet,umsodenverschlusseltenPaketschlusselzuentschlusseln.

Danachkann in beidenFallen der NutzdatenteildesDatagrammsmit dem symmetrischenVerfahrenentschlusseltwerden.DasentschlusselteDatagrammwird dannandie IP-Schichtweitergeleitet. In Abbildung 19 ist der Empfanggraphischdargestellt. Es handeltsich hierallerdingsumeinevereinfachteDarstellung,die die wesentlichenAspektebetont.

4.2.2.2 Schlusselfur Authentisierung und Verschlusselung: DerPaketschlussel¬±° wirdnicht direkt zum Verschlusselnbenutzt. Da SKIP auchdie Moglichkeit zur AuthentisierungderDateneinheitenbietet,werdenzwei Schlusselbenotigt. Ein SchlusselzumVerschlusselnundein SchlusselzumAuthentisieren.DiesebeidenSchlusselwerdenunterVerwendungei-


process type skip_send

IP_WAIT

IP_Datagrammfrom

IP_Layer

lookup_Kp (IP.dst) Suchen eines Paketschluesselsanhand der IP-Empfaengeradresse

Kp fuerIP.dst

gefunden?

Kp, VKij(Kp) Nein

Kp = random()VKij(Kp)

insert_Kp (IP.dst, Kp, VKij(Kp))

DES (Kp, IP.Data)symmetrische DES-Verschluesselung,gibt SKIP.Data zurueck

gen_skip (IP.hdr, VKij(Kp), SKIP.Data)

SKIP_Datagrammto

IP.dst

IP_WAIT

Abbildung18: SKIP-Sendemodul

ner“one-way” Hash-Funktionund ¸±¹ gewonnen,indemdieserPaketschlusselzusammenmiteinigenKonstantenund Bezeichnernfur denverwendetenVerschlusselungs-bzw. Authenti-sierungsalgorithmusverknupft wird.

Die tatsachlichfur dieVerschlusselung( º�»j¼ ) undAuthentisierung( ½�»j¼ ) verwendetenSchlusselergebensichaus ¸±¹ zu:

ºD»j¼ ¾ ¿ÁÀ#¸±¹ZÂ Crypt Alg ÂÄÃ�Å�ÃÇÆ�È<Â�¿]À6¸±¹ÉÂ Crypt Alg ÂÊÃ�Å�Ã�ÃÇÈ (4)

½�»j¼ ¾ ¿ÁÀ#¸±¹ZÂ MAC Alg ÂÄÃ�Å�Ã�ËÇÈ<Â�¿]À6¸±¹ZÂ MAC Alg ÂÄÃ�Å�ÃdÌ�È (5)

DasSymbol Â bedeutet,daßdie Bits derTeilausdrucke aneinandergehangtwerden.SKIP ver-wendetfur ¿]ÀÍÈ beispielsweiseMD5 (vgl. [6]). “MA C Alg” und“Crypt Alg” sindnumerischeWerte,die denjeweiligen Algorithmusidentifizieren,der zum VerschlusselnoderAuthenti-sierenbenutztwird. Von diesemAlgorithmushangtwiederumab,wieviele der 256Bits derSchlusseltatsachlichbenutztwerden.

4.2.2.3 Erneuern desHauptschlussels: In demSKIP-Datagrammist ein Zahlerunterge-bracht,derbenutztwerdenkann,umeinenneuen“MasterKey” durchdenSenderfestzulegen.


process type skip_rec

SKIP_WAIT

SKIP_Datagrammbesteht aus:IP.hdr, VKij(Kp),SKIP.Data

lookup_Kp (IP.src) Suchen eines Paketschluesselsanhand der IP-Senderradresse

Kp fuerIP.src

gefunden?

Kp, VKij(Kp) Nein

Kp = EKij( VKij(Kp)

)

insert_Kp (IP.src, Kp, VKij(Kp))

DES (Kp, SKIP.Data)symmetrische DES-Entschluesselung,gibt IP.Data zurueck

gen_ip (IP.hdr, IP.Data)

IP_Datagrammto

IP_Layer

SKIP_WAIT

Abbildung19: SKIP-Empfangsmodul

Der Hauptschlusselist bei SKIP 256Bit lang. Bei Diffie-HellmankannmanbeliebiggroßeSchlusselvereinbaren,sodaßhier immernur dieniederwertigsten256Bit benutztwerden.

Mit Hilfe desZahlerskann der Senderin jedemPaket anzeigen,welcheInstanz( Î3Ï¢Ð�Ñ ) erzum VerschlusselndesPaketsbenutzthat. Die Instanzwird aus Î3ÏÒÐ und Ó mit Hilfe einer“one-way” Hash-FunktionÔ]Õ6Ö (vgl. Abschnitt3.4) berechnet:

ÎMÏ¢Ð×ÑÙØÚÔ]Õ6Î3ÏÒÐ�ÛÄÓÜÛÄÝ�Þ�Ýdß�Ö<Û�Ô]Õ6ÎMÏ¢Ð�ÛÊÓ*Û�Ý�Þ�Ý�Ý�Ö (6)

4.2.2.4 WeitereFunktionen: SKIPerlaubtauchdieVereinbarungvonGruppenschlusseln.Alle EmpfangerderGruppekonnendanndieNachrichtenentschlusseln.Ermoglichtwird diesdurchentsprechendeIdentifikationsfelderim SKIP-Paket. Diesesogenannten“NameSpace”Bezeichnerermoglichendie Identifikationder Gruppen. Den Gruppensind wiederumver-


schiedeneHauptschlusselzugeteilt. Im einfachstenFall erfolgt die Auswahl einesHaupt-schlusselsjedochuberdie IP-Adressen.

4.2.2.5 Problemebei SKIP: Der SKIP-Paketkopf ist 28 Byte groß. Diese28 Byte fallenzusatzlichzumESP-und/oderAH-Overheadbei jedemIP-Datagramman23. Um Fragmentie-rungenim jeweiligenEndsystemzuvermeiden,wird durchSKIPin derRegeldieMTU-Großeangepaßt.Protokolle wie TCP werdendannihrerseitskleinereSegmentegenerieren,so daßderzusatzlicheSKIP-Overheadnicht zueinerFragmentierungfuhrenmuß(vgl. [5]).

Es gibt keine“perfect forward secrecy”. So langedie Hauptschlusselgeheimsind,nutzt ei-nemAngreiferdaspassiveAbhorenderSKIP-Kommunikationnichts.SollteeinemAngreiferjedochzuirgendeinerZeit derHauptschlusselbekanntwerden,dannkannernachtraglichallein derVergangenheitaufgezeichnetenDatagrammeentschlusseln.

Resumee: SKIPisteinalternativerAnsatzzudemvonIPSecfavorisiertenSchlusselaustausch-Protokoll ISAKMP/OAKLEY. Bei SKIPwerdenallezurEntschlusselungundAuthentisierungnotwendigenInformationenmit jedemDatagrammversendet.Dadurchentstehtein großererOverhead,durchdenaberandererseitsder (verbindungslose)Datagrammdienstvon IP erhal-tenbleibt.

4.3 Protokolle auf der Transportebene

Auf derTransportebenewurdebishervonderIETF einandererAnsatzgewahltalsaufderVer-mittlungsebene.DasTransportprotokoll TCPwird nichtumentsprechendeSicherheitsmecha-nismenerweitert,sondernzwischenTCPundAnwendungsebenewird ein weiteresProtokolleingeschoben.Eshandeltsichhierbeium die unterdemNamen“TransportLayerSecurity”(TLS) spezifiziertenMechanismen[10]. DerHauptvorteil dieservonTCPunabhangigenSpe-zifikation ist, daßTLS auchmit anderenverbindungsorientiertenProtokollen eingesetztwer-denkann.DerHauptnachteildiesesAnsatzesist die schlechteIntegrationin denvorhandenenTCP/IP-Protokollstapel(s.u.). Ein Ansatz,bei demTCP selbstabgesichertwird und somitdie Integrationin denvorhandenenProtokollstapelfur dieAnwendungentransparenterfolgenkann,wird in [41] beschrieben.Leiderwird dieserAnsatznicht von derIETF verfolgt.

Der Grundgedanke hinter TLS ist, der weit verbreitetenClient-Server-Architektur Zertifi-kat-basierteAuthentisierungund VerschlusselungdesDatentransfersbereitzustellen.DiesesProtokoll kann immer danneingesetztwerden,wenn Client und Server sich vor einer ver-schlusseltenTransaktionerst einseitigoder auchgegenseitigauthentisierenmussen. DafurbietetdasProtokoll die Moglichkeit, ZertifikatenacheinemfestzulegendenFormatvor einer

23 Als SKIP spezifiziertwurde,war dasin [3, 4] definiertePaketeformatfur ESPund AH gultig. Un-abhangigvon demjeweiligen Format fur ESPund AH sind die zusatzlichen28 Byte fur denSKIP-Paketkopf in jedesDatagrammeinzutragen.DerOverheadproIP-Datagrammist daherbeiSKIPgroßeralsbei IPsec.

4.3 Protokolle aufderTransportebene 51

Schlusselvereinbarungauszutauschen.Damit lassensichClient undServer von der IdentitatderKommunikationspartneruberzeugen24.

TLS ubernimmtaußerdemdie Verschlusselungder Verbindung. Nachder Authentisierungsetztdie Verschlusselungein, so daßdie Geheimhaltungder TransaktionenzwischenClientundServer sichergestelltist.

TLS soll die Geheimhaltungund Authentizitat von Datenzwischenzwei Anwendungenga-rantieren.DazuwerdenzweiProtokolle spezifiziert:

à “TLS RecordProtocol”(TRP)

à “TLS HandshakeProtocol”(THP)

Das TRP sichertdie Geheimhaltungvon ubertragenenDatenmit Hilfe von symmetrischerVerschlusselung.Außerdemwird die IntegritatderDatendurchzusatzlicheBerechnungeines“MessageAuthenticationCodes”(MAC) gesichert,sodaßManipulationenerkennbarsind.

Die fur die symmetrischeVerschlusselunginnerhalbvon TRPnotwendigenSchlusselmussenvon einemanderenProtokoll etabliertwerden. Hierfur wird bei TLS dasTHP eingesetzt,dasMechanismenfur die Authentisierungder beteiligtenKommunikationspartnervorsieht.Hierfur stehenasymmetrischeundsymmetrischeVerschlusselungenzur Verfugung.Nachei-nerAuthentisierungkonnendieKommunikationspartnermit THPdieerforderlichenSchlusselgeheimaustauschen.AuchderSchlusselaustauschwird durchTHPgesichert,sodaßManipu-lationenDritter andenSchlusselnsoforterkanntwerden.

Problematischan TLS ist die Verknupfungmit der Anwendungbzw. die Einbindungin denProtokollstapel.Intuitiv wurdemanannehmen,daßTLS eineeigene“well known” Portnum-merzugeteiltwird, uberdie dasTLS Protokoll in TCP-Segmentenidentifiziertwerdenkann.Die jeweilige Applikation konntedannwiederumubereinenTLS-Protokolltyp identifiziertwerden. DiesesVorgehenwird von der IETF allerdingsnicht gewahlt. Es gibt bisherzweiAnsatze,nachdenenTLS mit denAnwendungenverknupft werdensoll:

1. Die mit TLS abgesicherteVarianteeinesDiensteswird aufeinemeigenenPortangebo-ten. DieserAnsatzwurdeschlagartigdie Anzahlder bekanntenund festgelegtenPort-nummern(“well known ports”) verdoppeln.

2. DerzeitvonderIETF favorisiertwird derAnsatz,beidemdieAnwendungendiebekann-tenPortsbeibehaltenkonnen.JedeAnwendungmußbeidiesemAnsatzmit derPartner-instanzaushandeln,ob TLS benutztwerdensoll. Dieswurdezu einemnachtraglichen“Einf ugen”derTLS-Protokolle nachderVerbindungseroffnungaufTCP-Ebenefuhren.Beispielefur diesesVorgehenwerdenin [9, 33] gegeben.

24 Der MechanismuszumSichernderAuthentizitat von einzelnenNachrichtenzwischendiesenKommu-nikationspartnernberuhtauf der Verschlusselungmit demgemeinsamenSchlussel,der im Zuge derAuthentisierungzwischenClientundServeretabliertwird.


4.3.1 DasTLS RecordProtocol

Das“TLS RecordProtocol” (TRP)verwaltet fur jedeVerbindungzwei ZustandsvariablenineinemVerbindungskontext. Esgibt jeweilseineZustandsvariablefur ausgehendeDaten(“wri-te”) undfur zu lesendeDaten(“read”). Die Zustandsvariablensindstrukturiertdurchdie fol-gendenBezeichner:

Endpunktbezeichnung (“connectionend”)gibt an,obessichumdenDienstnehmer(Client)oderdenDienstleister(Server) bezuglichderVerbindunghandelt.

Verschlusselungsalgorithmus(“bulk encryptionalgorithm”)gibt denAlgorithmuszumVer-schlusselnderAnwendungsdatenan.

Authentisierungsalgorithmus (“MA C algorithm”)gibt denAlgorithmuszumBerechnendes“MessageAuthenticationCodes”(MAC) an.

Kompressionsalgorithmus(“compressionalgorithm”)bezeichnetdenAlgorithmuszumKom-primierenderAnwendungsdatenvor derVerschlusselungoderAuthentisierung.

Zu Beginn einerneuenVerbindungsinddieseWertealle vorbelegt. Bei derVorbelegunghan-delt essich um “Null”-W erte,die angeben,daßkeineVerschlusselung,AuthentisierungundKomprimierungstattfindet.DieseVorbelegungwird auchals“initial currentstate”bezeichnet[10,S.13].

Nebendieseneherstatischen25 Werten,beinhaltetderKontext weitereInformationen,die furjedesTLS-Paket aktualisiertwerden:

Kompressionszustandist derZustanddesKomprimierungsalgorithmus.

Verschlusselungszustandist der ZustanddesVerschlusselungsalgorithmus.Daskannbei-spielsweiseder Initialisierungsvektor fur einenAlgorithmussein,oderein Zwischen-wert,dernebendeneigentlichenDatenin die BerechnungdesfolgendenGeheimtexteseingeht.

MAC-Schlussel (“MA C secret”)ist dergeheimeSchlusselfur denMAC-Algorithmus.Die-serSchlusselwird nicht verandert,sondernbleibt nachderInitialisierungkonstant.

Sequenznummer ist einestrengmonotonsteigendeZahl, die in jedesPaket kopiertundan-schließendum eins erhoht wird. Damit sind Auslassungenund WiederholungenvoneinzelnenPaketenerkennbar.

Die einzelnenInitialwertefur dieseZustandsvariablenwerdenamAnfangvoneinemgemein-samenGeheimnisabgeleitet,dasdurchdasTHP (s.u.) etabliertwird. DasTRPbietetsomiteinenDienstfur die VerschlusselungundAuthentisierungvon beliebiglangenDatenblockenan.

25 Die Zustandekonnengewechseltwerden. Beispielsweisekannein WechseldesKomprimierungsver-fahrensin einem“pendingstate”vorbereitetwerden,derdanndurchUmschaltenzumneuen“currentstate”wird. Danachwird dieneueKomprimierungsmethodeeingesetzt.


4.3.2 DasTLS Handshake Protocol

DasTLS “Handshake Protocol” (THP) dient primar der Etablierungvon gemeinsamenGe-heimnissenzwischenClient undServer. DanebenfindeteineZertifikat-basierteAuthentisie-rungstatt.WeitereFunktionensindderWechselderVerschlusselungsmethodefur Verbindun-genundderAustauschvon Fehlernachrichten.

THP ist fur dieseAufgabenunterteiltin die drei Sub-Protokolle:

Handshake Protocol: Das“HandshakeProtocol”wird zurAuthentisierungundzumEtablie-rendesgemeinsamenGeheimnisses(“sharedsecret”)benutzt.

ChangeCipher SpecProtocol: DiesesProtokoll wird zumWechselnderVerschlusselungsmethodeeinerbestehendenVerbindungbenutzt.

Alert Protocol: Das“Alert Protocol”wird benutzt,umFehlernachrichtenundsonstigeMeta-MeldungenzwischendenPartnerinstanzenzuversenden.

Auf die beidenletztgenanntenProtokolle brauchthier nicht weiter eingegangenzu werden.Wichtig fur die Schlusselvereinbarungund Authentisierungist das“Handshake Protokoll”.Die dabeiausgetauschtenInformationensind sehrkomplex, so daßeineReihevon speziel-len Nachrichtendefiniert wurde, um die Struktur der transportiertenInformationeneinfachabbildenzukonnen.Eshandeltsichhierbeiumdie folgendenNachrichten:

Hello: Es gibt ein “Client Hello” und ein “Server Hello”. Initiator einerVerbindungist inderRegel derClient. Er sendeteinenZeitstempelundeineZufallszahl,die fur spatereBerechnungenvon Sitzungsschlusselnbenutztwerden.Außerdemkannder Client dieSitzungsIDeinerbereitsetabliertenSitzungangeben,um dieseentwederwiederaufzu-nehmen(“resume”)odereineweiterezu dieserSitzungidentischeSitzungzu eroffnen.Normalerweiseist dieserWert nicht belegt, sodaßeineneueSitzungerstelltwird. DerClientmußaußerdemeineListedervon ihm unterstutztenkryptographischenVerfahren(LKrV) angeben.DieseListe ist priorisiert,d.h.dasvom Client favorisierteVerfahrensolltezuerstangegebenwerden,dannmit absteigenderPrioritat die weiterenbekanntenVerfahren.AnalogzurLKrV gibt derClienteineListederbekanntenKomprimierungs-verfahrenan(LKoV).

DerServergibt nebeneinerProtokollversionundseinemZufallswertdieSitzungsIDan.Im Fall einerwiederaufgenommenenSitzungentsprichtdieseID der vom Client vor-gegebenen,andernfalls wahlt derServereineneue,eindeutigeID. DerServer gibt seineWahl fur die zu verwendendenkryptographischenVerfahren(VerschlusselungundAu-thentisierung)in demFeld GKrV an,dasgewahlteKomprimierungsverfahrenim FeldGKoV.

Certificate: Die Zertifikat-NachrichtdesServersist erforderlich,diedesClientswird nuraufexplizite AnforderungdesServersgesendet.Die NachrichtbeinhalteteineZertifikatsi-dentifizierungundeineListe derjeweiligenZertifikate26.


Certificate Request: DieseoptionaleNachrichtkannder Server an denClient senden,umseinerseitsein Zertifikat desClients anzufordern. In diesemFall mußder Client miteiner“CertificateNachricht”antworten.

Server Hello Done: Mit dieserNachrichtzeigt der Server an, daßvon ihm keineweiterenNachrichtenaußerderabschließenden“Finished”-Nachrichtzu erwartensind.Der Ser-ver kannso nacheiner“Server Key Exchange”-Nachricht(s.u.) anzeigen,daßer kein“Certificate Request”sendenwird. Der Client kann demnachunmittelbarmit seiner“K ey Exchange”-Nachrichtantworten.

KeyExchange: Die NachrichtdesClientsmit Schlussel-Informationenzum Erstelleneinesgemeinsamen“PremasterSecrets”,ausdemweitereSitzungsschlusselabgeleitetwer-den27, ist immererforderlich.Der Server sendetdieseNachrichtnur, wenndie entspre-chendenInformationennicht bereitsausdenZertifikatendesServersabgeleitetwerdenkonnten.

Certificate Verify: DieseNachrichtist der MD5 oderSHA-1 Wert uberalle bisherausge-tauschtenInformationendieses“Handshakes”. Er dient der Uberprufung der bisherubertragenenInformationen. Beispielsweisesind so ManipulationenDritter an denNachrichtenerkennbar. DieseNachrichtkannallerdingsnur versendetwerden,wennderClientzuvor in einer“Client Certificate”NachrichteinZertifikatangegebenhat,mitdemsigniertwerdenkann.

Finished: DieseNachrichtenbeendendieAuthentisierungundSchlusselvereinbarung.Gleich-zeitig werdendie ausgehandeltenSchlusselundAlgorithmenuberpruft, dadieseNach-richtenbereitsverschlusseltwerden.Esist daherunkritisch,daßin dieserNachrichtdas“MasterSecret”ausgetauschtwird. Außerdemwird eineMD5 oderSHA-1PrufsummeuberallebisherausgetauschtenNachrichtendes“Handshakes”in den“Finished”-Nachrichtenangegeben.DiePrufsummensindverschieden,dadiePrufsummedesServersbereitsdie“Finished”-NachrichtdesClientsin die Berechnungeinbezieht.

DasTHP Protokoll kenntweitereoptionaleNachrichten,auf die nicht eingegangenwerdenmuß, um dasTLS-Konzeptzu verstehen.Der generelleVerlauf der NachrichtenzwischenClient undServer ist in Abbildung108graphischdargestellt.

4.3.2.1 EingesetzteVerschlusselungsverfahren: Zur Verschlusselungder Daten in denTRP-Paketenwird DESoder3DESeingesetzt.DiessindsymmetrischeVerfahren,diewieder-um im “CipherBlock Chaining”(CBC) Modusbetriebenwerden(vgl. [1, 2]).

26 Die Zertifikatsidentifizierunggibt denTyp desZertifikatsan.27 DasAbleitendiverserVerschlusselungs-undAuthentisierungsschlusselausdiesem“PremasterSecret”

ist ahnlichdemVerfahrenbei SKIP und brauchtdahernicht weiter diskutiertzu werden. Dasin den“Finished”-Nachrichtenausgetauschte“MasterSecret”wird ebenfallsausdem“PremasterSecret”unddenZufallszahlenvonClient undServerberechnet.


tls_handshake

Client_Hello (Zeitstempel, Zufallswert, SitzungsID, LKrV, LKoV)

Server_Hello (Protokoll Version, Zufallswert,SitzungsID, GKrV, GKoV)

Server_Certificate (Zertifikatstyp, Zertifikatsliste)

Server_Key_Exchange (Schluesselinformationen)

Certificate_Request (Zertifikatstyp, LCA)

Server_Hello_Done()

Client_Certificate (Zertifikatstyp, Zertifikatsliste)

Client_Key_Exchange (Schluesselinformationen)

Certificate_Verify (MAC_Signatur)

Finished (Master_Secret, "client finished", MAC_Signatur)

Finished (Master_Secret, "server finished", MAC_Signatur)

Client

Zertifikate sind akzeptiert, "Premaster Secret" etabliertZertifikate sind akzeptiert, "Premaster Secret" etabliert

Server

Zertifikate sind akzeptiert, "Premaster Secret" etabliert

Abbildung20: TLS “Handshake” zur AuthentisierungundSchlusselvereinbarung

4.3.2.2 EingesetztePaket-Authentisierungsverfahren: Eine Prufsummeuberdie Pake-tinhaltewird wiederumentwedermit MD5 oderSHA-1erstellt(vgl. Abschnitt4.2.1.1).

4.3.2.3 EingesetzteAuthentisierungsverfahren: ZurAuthentisierungdesServerswerdendigital unterzeichneteZertifikateverwendet.DieseZertifikatemussenentwederKonformzumRSA Standardseinoderzum“Digital SignatureStandard”(DSS).RSA ist ein bekanntesundweit verbreitetes“Public Key” Kryptosystem(vgl. [36]). Der DSS wurde von einemUS-amerikanischenStandardisierungsinstitut(NIST) verabschiedet(vgl. [32]).

4.3.2.4 HistorischeEntwicklung: TLS bautauf einerEntwicklungder Firma “NetscapeCommunicationsCorporation”auf. Unter dem Namen“SecureSocket Layer” wurde eineSpezifikationveroffentlicht,diedie GrundlagevonTLS 1.0ist.


Resumee: SSLunddasdarausweiterentwickelteTLS werdeneingesetzt,um verbindungs-orientierteKommunikation(typischerweiseTCP)abzusichern.Dazuwird einSchlusselaustauschzwischendenKommunikationspartnerndurchgefuhrt, die zuvor eineZertifikats-basierteAu-thentisierungdurchfuhren.DasHauptproblemderTLS-Protokolle ist dieschlechteIntegrationin denTCP/IP-Protokollstapel. Gegebenenfalls mussendahereinzelneAnwendungenandieTLS-Protokolle angepaßtwerden.TLS wird zurZeit von derIETF standardisiert.

4.4 Protokolle auf der Anwendungsebene

Auf Anwendungsebenekonnenebenfalls Sicherheitsmechanismenimplementiertwerden.ImUnterschiedzu allen bislangdiskutiertenMechanismensind die Realisierungenauf der An-wendungsebeneimmer anwendungsspezifisch.Die Schutzfunktionenwerdendaherfur eineganzbestimmeAnwendungoderKlassevonAnwendungenspezifiziertundsindnichtuniver-sell einsetzbarwie IPsecundTLS.

In diesemAbschnittwerdendreiProtokolle vorgestellt,dieeineAbsicherungderKommunika-tion fur spezielleAnwendungenermoglichen.Eswird S-HTTPvorgestellt,daszumsicherenUbertragenvon HTML-Dokumentenverwendetwird. Außerdemwird SSHdiskutiert,dasalsGrundlagefur sicheres“Remote”-Logineingesetztwird. Ein weiteresAnwendungsprotokollist “SecureDNS”, umdie “DomainNameSystem”-Kommunikationabzusichern.

4.4.1 SicheresHTTP (S-HTTP)

Das“SecureHTTP” (S-HTTP)ist eineSpezifikation[35], die das“Hypertext TransferProto-col” (HTTP, vgl. [17]) umMechanismenzurAuthentisierung,GeheimhaltungundUnleugbar-keit derSendungerweitert.

Da HTTP und S-HTTPals ASCII-Text versendetwird, gibt eskein dediziertesPaketformatfur die Nachrichten.Es gibt vielmehrneue– an die HTTP-Syntaxangelehnte– Token, diebestimmtekryptographischeInhalte(beispielsweiseZertifikate,Schlusselinformationen,ListederunterstutztenAlgorithmenusw.) kennzeichnen.Alle benotigtenkryptographischenInfor-mationenkonnensoin denHTTP-AnfragendesClientsunddenHTTP-AntwortendesServersuntergebrachtwerden.

Ahnlich wie bei TLS werdenZertifikatefur die AuthentisierungderKommunikationspartnerverwendet.S-HTTPverwendetalsZertifikatformatX.509. Die Zertifikatemussenmit Signa-turenim RSA- oderDSS-Formatunterzeichnetsein. Die Integritat derNachrichtenkannmitdenbereitsvorgestelltenVerfahrenMD5 undSHA-1 gesichertwerden.ZusatzlichkannauchMD2 (einVorgangervonMD5) verwendetwerden.

Die unterstutztensymmetrischenAlgorithmen fur die Verschlusselungsind: DES, “Triple-DES” (3DES)mit zwei oderdrei Schlusseln,eineabgeschwachteDESVersionund“Interna-tionalDataEncryptionAlgorithm” (IDEA) [38,S.319ff].

4.4 Protokolle aufderAnwendungsebene 57

Resumee: S-HTTP ist eineErweiterungvon HTTP. S-HTTP verwendetebenfalls die beiTLS vorgestellteAuthentisierungmit Zertifikaten.

4.4.2 Sicheres“Remote”-Login

In derUNIX-Welt sinddiesogenannten“Remote-Dienste”(rlogin, rsh,remshell)weit verbrei-tet. Es handeltsichhierbeium eineReihevon Client/Server-Programmen,die esBenutzernerlauben,Kommandosoderganzeinteraktive Sitzungen(“Sessions”)auf anderennicht loka-lenRechnernauszufuhren.Dazuwerdenmit speziellenProtokollen[21] dieKommandosoderallgemeindieBenutzereingabenuberdasNetzandenentferntenRechnerubertragenunddortverarbeitet.Die ErgebnissewerdenerneutuberdasNetzzumlokalenRechnerubertragenunddemBenutzerauf seinemlokalenTerminalausgegeben.

Diese“Remote”-Kommandosmit dendazugehorendenProtokollen habeneinegroßeBedeu-tung in der Welt der verteiltenSysteme,da so auf einfacheWeisedie BetriebsmittelweitentfernteroderspezialisierterRechnerbenutztwerdenkonnen.Esgibt jedocheineReihevonProblemenmit diesenProtokollen:

SchwacheAuthentisierung der Kommunikationspartner: Die AuthentisierungeinesCli-entsgegenubereinemServer beruhtim wesentlichenauf der IP-AdressedesClients.DieseAdressekann jedochauf einfacheWeisemanipuliertund vorgetauschtwerden(“IP-Spoofing”),umunerlaubtaufeinenDienstzuzugreifen.

KeineAuthentisierung/Integrit atssicherungder Nachrichten: Die Nachrichten,die zwi-schenClient undServer ausgetauschtwerden,sindnicht authentisiert.SiekonnenvonDritten (“Man in the Middle”) abgefangenund manipuliertwerden. Es konnensogaretablierteVerbindungenvon Drittenganzubernommenwerden(“Hijacking”).

KeineVerschlusselung: Die auf der“Remote-Shell”eingegebenenKommandoswerdenun-verschlusseltubertragen.Die Terminal-Ausgabeder auf denentferntenRechnernge-startetenProgrammewird ebenfalls unverschlusseltuberdasNetz ubertragenund istsomittrivial abhorbar.

UnterdemNamen“SecureShell” (SSH,bzw. secsh)beschaftigt sicheineIETF-Arbeitsgruppemit der Spezifikationvon neuenProtokollen, die dasAusfuhrenvon Kommandosund dasArbeiten mit einer “Remote-Shell”uber ein unsicheresNetz absichernsollen. Die IETF-Arbeitsgruppebeginnterstjetztmit derSpezifikationderProtokolle,dieentsprechendenToolssind aberbereitsauf allen UNIX-Systemenund einigenanderenPlattformenverfugbarundkonnenalsQuasi-Standardfur sichere“Remote-Dienste”angesehenwerden.SSHbeschreibteineProtokollhierarchievondreiProtokollen,dieaufeinemzuverlassigen,verbindungsorien-tiertenProtokoll28 aufsetzen.

28 In der Regel ist diesTCP. Es kannallerdingsauchein anderesProtokoll verwendetwerden,da TLSkeineTCP-spezifischenFunktionenbenotigt. DasProtokoll mußlediglichdiekorrekteUbertragungderDatenundEinhaltungderPaketreihenfolgesichern.


Drei Protokolle werdenspezifiziert,die unterschiedlicheDiensteerbringen:

Transport Layer Protocol: DiesesProtokoll (TLP)sorgt fur eineVerschlusselungderubertragenenDaten,fuhrt Integritatsprufungendurchund ermoglicht eineAuthentisierungdesSer-versbeim Client mit Hilfe von asymmetrischenSchlusseln(“Public Key” Verfahren).ZusatzlichkanneineKomprimierungderDatenvorgenommenwerden.

Authentication Protocol: DiesesProtokoll (AP) setztauf demTLP auf und ermoglicht dieAuthentisierungdesClientsodereinesBenutzersbeimServer.

ConnectionProtocol: DiesesProtokoll (CP) setztwiederumauf demAP auf und bietetin-teraktivenProgrammendie Moglichkeit, diverse“login”-Funktionenauszufuhren.Bei-spielesindPaßwortabfrageund-anderung.AußerdemermoglichtdasCP, mehrere“Ses-sions”ubereineauthentisierteVerbindungzumultiplexen.

Bei VerwendungderSSH-Protokolle innerhalbderTCP/IP-Protokollfamilie ergibt sichsomitder in Abbildung21 dargestellteProtokollstapel. In denfolgendenUnterabschnittenwerdendie einzelnenProtokolle kurzvorgestellt.

Sichere Anwendungen

Connection Protocol

Authentication Protocol

Transport Layer Protocol

Untere Schichten

Internet Protocol (IP)

Transmission ControlProtocol (TCP)

SSH-Protokolle

Abbildung21: TypischerSSH-Protokollstapel

4.4.2.1 Das“T ransport Layer Protocol”: FurdieAuthentisierungwird ein“PublicKey”-Verfahreneingesetzt.Ein Client kann so uberprufen, ob er tatsachlich mit dem angenom-menenServer verbundenist. In einemzweitenSchritt wird mit Hilfe desDiffie-Hellman-Verfahrensein gemeinsamesGeheimnisetabliert,ausdemdannmehrereSchlusselabgeleitetwerden.Fur jedeKommunikationsrichtung(Client zumServer undServer zumClient) wirdeinVerschlusselungsschlusselundeinSchlusselfur die Integritatsprufungerstellt.DerHaupt-aufwandbeim Protokoll entstehtdurchdie Nachrichtenzum Aushandelnder verschiedenen


Verschlusselungs-undHMAC-Verfahren,die fur jedeRichtungverhandeltwerden.Der Pro-tokollablauf laßtsichgrob in drei Phaseneinteilen: Versionsidentifizierung,AushandelnderAlgorithmenundAuthentisierendesServers.Die beidenletztenPhasenwerdenals“K ey Ex-change”mit impliziter Authentisierungbezeichnet.NacherfolgreichemAbschlußdieserPha-senkanndasAP fur dieseVerbindungdie anderenDiensteanfordern,die dannverschlusseltundunterIntegritatsprufungerbrachtwerden.

Ohneweiterauf die StrukturdereinzelnenTLP-Nachrichteneinzugehen,ist derStandardfallfur einenVerbindungsaufbauin Abbildung22abgebildet.

ssh-tlp

Proto_Version ("ssh-cx-cy", Kommentare)

Proto_Version ("ssh-sx-sy", Kommentare)

SSH_MSG_KEXINIT (Liste der bekannten Algorithmen)

SSH_MSG_KEXINIT (Liste der bekannten Algorithmen)

SSH_MSG_KEXDH_INIT (Diffie-Hellman Public Key)

SSH_MSG_KEXDH_REPLY (Diffie-Hellman Public Key, Signatur)

SSH_MSG_NEWKEYS()

SSH_MSG_NEWKEYS()

Client

Protokollversionen und somit die "Features" sind identifiziertProtokollversionen und somit die "Features" sind identifiziert

Client und Server haben sich auf Algorithmen geeinigtClient und Server haben sich auf Algorithmen geeinigt

GemeinsamesGeheimnis (K)

bekannt,Server hat sich

authentisiert!

Schluesselaustausch beendet. Alle folgenden Paketewerden mit den von K abgeleiteten Sitzungsschluesseln verschluesselt und authentisiert.


Server

Protokollversionen und somit die "Features" sind identifiziert

Client und Server haben sich auf Algorithmen geeinigt

GemeinsamesGeheimnis (K)

bekannt!


Abbildung22: SchlusselaustauschundAuthentisierungbeimTLP

4.4.2.2 Das“ Authentication Protocol”: NachdemzwischenClient undServer einegesi-cherteVerbindungmit demTLP hergestelltwurde,kanndie AuthentisierungdesBenutzers


beim Server erfolgen. Das Authentisierungsprotokoll unterstutzt hierfur drei verschiedeneMethoden:

á Authentisierungmit einem“Public Key”

á AuthentisierungdurchinteraktiveAbfrageeinesPaßworts

á AuthentisierungaufGrundlagederIP-Adresse

Bei der erstenMethodewird einemit demprivatenSchlusseldesBenutzerssignierteNach-richt an denServer gesendet,der die BerechtigungdesBenutzersmit Hilfe desoffentlichenSchlusselsdesBenutzersuberprufenkann.DieseMethodeerfordert,daßfur die BenutzereinentsprechendesasymmetrischesSchlusselpaarerstelltwird unddie offentlichenSchlusselaufdemSerververfugbarsind.

Bei der zweitenMethodesendetder Server die Aufforderung,ein Paßwort einzugeben.DasPaßwort wird vomClientzumServersicherubertragen,daAP aufdemverschlusselndenTLPaufsetzt.

Die dritte —nicht zu empfehlende—Methodeentsprichtdemvon den“remote”-KommandosbekanntenVorgehen. Der Benutzernamewird vom Client an den Server ubermittelt. DieAuthentisierungdesBenutzerserfolgt nur lokal beimClient, derServer vertrautdemClient.DieseMethodeist nicht zu empfehlen,da sichder Benutzerbeim Server nicht authentisiert,sondernnurvomClient autorisiertwird.

4.4.2.3 Das“Connection Protocol”: NacherfolgreicherAuthentisierungkonnenmehrereverschlusselteSitzungenmit Hilfe des“ConnectionProtocols”(CP)uberdieauthentisierteundverschlusselteVerbindungverwaltet werden. Der Vorteil desMultiplex-Betriebsliegt darin,daßgegenuberdemEroffnen von neuenVerbindungenalle aufwendigenkryptographischenOperationen(Schlusselaustausch)nicht nocheinmaldurchgefuhrt werdenmussen.DasCPbieteteineReiheweitererDienstean,aufdie hier nichtweitereingegangenwerdenkann.

Die SSH-Protokolle habensichseit Jahrenim UNIX-Umfeld bewahrt. Nachder Installationvon Client und Server, der Generierungund Verteilungvon Host-Keys und der Konfigurie-rung von zu verwendetenVerfahrenkonnendie SSH-Tools transparentfur die Benutzerdieherkommlichen“Remote”-Kommandosersetzen.

Resumee: Die SSH-Protokolle ermoglichenein sicheresinteraktivesArbeiten uber unge-sicherteNetze. Die Sitzungenwerdenverschlusseltund Server sowie BenutzerfuhreneinekryptographischeAuthentisierungdurch. SSH-Implementierungensind ein Quasi-Standardim UNIX-Bereichundweit verbreitet.


4.4.3 Sicheres“Domain NameSystem” (Secure DNS)

Das“Domain NameSystem”(DNS) beschreibteinenhierarchischen,verteiltenNamensraumfur die Zuordnungvon Internet-Adressenzu symbolischenNamen. In diesemNamensraumkonnenweitereInformationen,wie beispielsweisederNameeinesAnsprechpartnersfur einenRechner, gespeichertwerden.

Die verteilteDatenhaltungwird durchdieDNS-Servererbracht.DNS-Clientskonnendadurchihre Anfragenan einenlokalenServer senden,der diesegegebenenfalls weiterleitet,falls erdie gewunschtenInformationennicht lokal gespeicherthat. Typischerweisesind auf jedemEndsystemDNS-Clientsim Betriebssystemintegriert, um fur den BenutzertransparentdieAuflosungeinessymbolischenNamensin eineIP-Adressezuveranlassen.

DasDNS-Protokoll wird seitJahrenim Interneteingesetztundist ein unverzichtbarerDienst.DasHauptsicherheitsproblembestehtdarin,daßdie Informationen,die die Server versenden,nicht authentisiertwerden.Wederein Client nochein andererServer kanndahersichersein,daßdie Informationenvon einemDNS-Server authentischund unverfalschtsind. Aus die-semGrundwird unter demNamen“SecureDNS” an einerErweiterunggearbeitet,die dieAuthentizitatundIntegritat derDNS-Informationensichernsoll [11].

“SecureDNS” implementiertdreiMechanismen:

1. Authentisierungder Datenbei “Zone Updates”29. DNS-Server konnendie von ihnenversendeten“Zone Updates”digital signieren.Dadurchist die Integritat derDatenundderenHerkunft uberprufbar. Dafur ist eserforderlich,eine“Public Key” Infrastrukturbereit zu stellen,so daßdie SignatureneinesServers von anderenServern mit dementsprechendenoffentlichenSchlusseluberpruft werdenkonnen.

2. BereitstelleneinerSchlusselverteilung.Die fur dieUberprufungderSignaturender“Zo-neUpdates”notwendigenoffentlichenSchlusselkonnenebenfallsin derDNS-Datenbankabgespeichertwerden.DamitstehendenDNS-Servernnacheinem“ZoneUpdate”auchdie notigenSchlusselzur Verfugung,um fur weitere“Zone Updates”die offentlichenSchlusseldynamisch30 zu lernen.

3. AuthentisierungderDNS-Anfragenund-Antworten.DerZugriff aufdieDNS-Datenbankist grundsatzlichjedemerlaubt.Daherist eineAuthentisierungderClientsauchnichter-forderlich. Die AntwortenderServer solltenallerdingsauthentisiertsein.Die Herkunftund Integritat der Antwortenmussenuberprufbar sein,damit ein Angreifer denClientnichtunbemerktfalscheAuskunfteerteilenkann.

29 Bei “Zone Updates”werdendie gesamtenDatenbankinformationen,fur die ein Server verantwortlichist (alsodie DatenseinerZone),an einenodermehrereServer versendet,die stellvertretendfur denZone-Serverantwortenkonnen.

30 Wenn ein DNS-Server neu installiert wird, muß diesemServer naturlich mindestensein offentlicherSchlusseleines“Primary Servers” (PS) manuell konfiguriert werden. Die “ResourceRecords”des“Zone Updates”diesesPSkonnendannuberpruft werden.Darin enthalteneSchlusselweitererZonenkonnendynamischgelerntwerdenundstehenohnemanuelleKonfigurationzur Verfugung.


Verwaltetwerdendie offentlichenSchlusselin derDNS-Datenbankmit Hilfe von zwei neu-en “ResourceRecords”(RR). Es gibt denneuenDatentyp“K ey ResourceRecord”, in demoffentlicheSchlusselvon Zonen,PersonenoderRechnern(uberIP-Adresse)gespeichertwer-den. Außerdemgibt esdie “SIG RR”, in denenein DNS-Server digitaleSignaturenuberdievon ihm bei “ZoneUpdates”versendetenRRsablegt.

4.4.3.1 Der “K eyResourceRecord”: NebendemeigentlichenoffentlichenSchlusselwer-den in “K ey ResourceRecords”(Key-RR) weitereInformationengespeichert,die Hinwei-seauf denverwendetenVerschlusselungsalgorithmusgebenalsauchHinweise,wofur dieserSchlusselzu verwendenist. UbermehrereBits wird beispielsweisekodiert,ob derSchlusselaneineMaschine(IP-Adresse)oderaneinePersongebundenist.

4.4.3.2 Der “SIG ResourceRecord”: Der “SIG ResourceRecord” (SIG-RR) wird vondenDNS-Servernbenutzt,um digitaleSignaturenfur die anderenRR in ihrer Datenbankab-zulegen. Der Empfangerkann anhandder RR und der Signaturenuberprufen, ob die Da-ten tatsachlichausder jeweiligenZonekommenundob andenDatendurcheinenAngreiferAnderungenvorgenommenwurden.

Die einzelnenRR einer Zone werdenanhandihres Typs signiert. Im SIG-RR muß daherangegebenwerden,aufwelchenTyp vonRRsichdieSignaturbezieht.WeitereFelderim SIG-RRermoglichen,einAblaufdatumfur dieSignaturanzugeben.Ein weitererwichtigerEintragist derNamedesSignierenden.Hier ist ein Zonennameeingetragen,uberdenderoffentlicheSchlusselzumPrufenderSignaturenin einementsprechendenKey-RRreferenziertwird.

4.4.3.3 Authentisieren der DNS-Antworten: WenneinClienteineAnfrageaneinenSer-versendet,dannmußderServerandasEndederAntwort einenspeziellenSIG-RRanhangen.In diesemSIG-RRwird einemit demprivatenSchlusseldesantwortendenServerserstellteSignaturabgelegt, diesowohl dieAntwortdatenalsauchdievorangegangeneAnfragedesCli-entsabdeckt.DerClient ist dadurchin derLage,nichtnur die Integritat undAuthentizitatderAntwort zu uberprufen,sondernauch,obseineeigeneAnfragevoneinemDrittenabgefangenundmanipuliertandenServerweitergeleitetwurde.

Hervorzuhebenan“SecureDNS” ist,daßhiereineMoglichkeit fur eineallgemeinereSchlusselverwaltungentwickelt wurde. Durch die zusatzlichenUnterscheidungsmerkmale,die in einemKey-RRabgespeichertwerden,ist esmoglich, nicht nur die offentlichenSchlusselvon Rechnernne-ben weiterenAngabenmit der IP-Adressezu verknupfen, sondernauch personenbezoge-ne offentliche Schlusselmit zusatzlichen“Benutzungshinweisen”abzulegen. Dies ist auspraktischenGrundenein nicht unerheblicherVorteil von “SecureDNS” gegenuberanderenVerzeichnisdiensten(namentlichX.500 basierte),da die entsprechendenClientsohnehinaufjedemIP-basiertenRechnervorhandensind. Die Verteilungvon “SecureDNS” basiertenSchlusselnist daherdeutlicheinfacherzu implementieren.


Resumee: Secure-DNSist eine Erweiterungvon DNS, die zusatzlich zu der Namensver-waltung die Authentisierungder Eintrage im DNS-Verzeichnisermoglicht. Dazu werdenzwei neueTypenvon Eintragendefiniert: Ein Key-RR wird zumSpeichernvon offentlichenSchlusselnder Domanenverwendet.SIG-RRsspeichernSignaturender Domanenuberan-dere“ResourceRecords”.Auf eineVerschlusselungbei der Ubertragungwird verzichtet,daDNS-Eintrageoffentlichsind.

4.4.4 ISAKMP/O AKLEY

Das“InternetSecurityAssociationKey ManagementProtocol”(ISAKMP) wird vonderIETFentwickelt. Die IPsec-Arbeitsgruppediskutiert diesesProtokoll als Standardlosungfur dieEtablierungeiner“SecurityAssociation”(SA) fur IPsec(vgl. Abschnitt4.2.1).

Grundsatzlich ist ISAKMP ein allgemeinesProtokoll fur die Verhandlungund Etablierungvon SAs. Es kannauchfur andereProtokolle eingesetztwerden,die ebenfalls — wie IPsec(AH undESP)— ein eigenstandigesProtokoll zur AuthentisierungundSchlusseletablierungbenotigen.ISAKMP stelltdahereinenMechanismuszumsicherenVerhandelnvonVerschlusselungs-undAuthentisierungsmechanismenzurVerfugung.

DiesesProtokoll ist sehrkomplex. Esermoglicht die Aushandlungvon verschiedenenAlgo-rithmenfur VerschlusselungundAuthentisierung.DesweiterenverhandeltesdienotwendigenZertifikatefur die Authentisierung.NacheinersolchenVerhandlungmußanschließendeineSA fur die IPsecKommunikationeingerichtetwerden. DieseEinrichtungder SA ist fur dieanschließendeKommunikationuberIPseckritisch,daeinFehleroderein Angriff beiderEta-blierungdie anschließendeIPsec-Kommunikationkompromittierenwurde. Die EtablierungderSA fur einanderesProtokoll (beispielsweiseIPsecAH oderIPsecESP)mußdaherbereitsubereinengesichertenKanalerfolgen.

ISAKMP etabliertdieSA fur einanderesProtokoll in zweiSchritten.Zuerstwird eingesicher-terKanalfur ISAKMP etabliert,dannkonnenuberdiesengesichertenKanalin einemzweitenSchritt weitereSAs fur IPsecoderein anderesProtokoll etabliertwerden.Um die Verhand-lungenderKommunikationspartnerzu sichern,schutzt ISAKMP dieseVerhandlungendurcheigeneMechanismengegen:

â “Denial of Service”(DoS)-Angriffe

â Wiederholungsangriffe

â “Man-in-the-Middle” (MiM)-Angrif fe

â UbernahmederVerbindungen(“ConnectionHijacking”)

Um diesenSchutzerreichenzu konnen,erfordertISAKMP von denbeteiligtenKommunika-tionspartnernihrerseitsdenEinsatzvon starker Authentisierung.Die Authentisierungwird


mit eineminitialenSchlusselaustauschgekoppelt,sodaßderSchlusselunddieKommunikati-onspartnerauthentisiertsind. Danachkannauf dieserGrundlagedie eigentlicheVerhandlungubereingesetzteZertifikate,AuthentisierungsmechanismenundVerschlusselungsalgorithmenbeginnen(vgl. [29]).

Habensichdie Kommunikationspartnerauf angemesseneMechanismengeeinigt,unterstutztISAKMP anschließendauchdenAustauschvonZertifikatenunddieVereinbarungvonSchlusselnundbietetsomiteineuniversellePlattformfurdieEtablierungbeliebigerSAs.DasvonISAKMPbevorzugteVerfahrenzumSchlusselmanagementist OAKLEY (vgl. [18]).

ISAKMP setztkein Protokoll fur denZugriff auf offentlicheZertifikatsverzeichnissevoraus.Die Uberprufung der ausgetauschtenZertifikate liegt in der Verantwortung der beteiligtenKommunikationspartner, dieeineSA etablierenwollen.

Resumee: ISAKMP/OAKLEY ist ein Protokoll fur dasSchlusselmanagement.EsetabliertzwischenKommunikationspartnernKontextinformationen(“SecurityAssociations”)fur aus-gehandeltekryptographischeAlgorithmen. DieseSAs werdenvon anderenProtokollen furVer- undEntschlusselungundAuthentisierungvonDateneinheitenverwendet.ISAKMP/OAKLEYhatunterdenbekanntenSchlusselmanagementprotokolleneineherausragendeBedeutung,daesvon derIETF fur denSchlusselaustauschbei IPSecfavorisiertwird.

4.4.5 PKI-Pr otokolle

Unter dem Namen“Public Key Infrastructur” (PKI) beschaftigtensich zwei weitereIETF-Arbeitsgruppenmit denorganisatorischenund technischenMaßnahmen,die fur die Verwal-tung und denZugriff auf offentlicheZertifikateerforderlichsind. Eine Gruppe(PKIX) ent-wickelt VerfahrenundProtokolle fur denZugriff aufX.509konformeZertifikate.Die Gruppemit demNamen“Simple PublicKey Infrastructure”(SPKI)will einevon X.509unabhangigeVerwaltungvonZertifikatenerreichen.Teil dieserBemuhungenist die Spezifikationvon Pro-tokollen fur denZugriff auf offentlicheZertifikate.Mit solchenProtokollenkonnenbeispiels-weiseClients,die eineSA mit Hilfe von ISAKMP/OAKLEY etablierenwollen, die empfan-genenZertifikateuberprufen.

Die PKIX bautaufeinerX.500-Verzeichnisstrukturauf. Die Arbeitsgruppedefiniertunteran-deremdie Attributefur Zertifikate,derenBenennungundwie derenVerwaltungerfolgensoll.Fur denZugriff von Clientsauf dieseZertifikateist wiederumein Protokoll erforderlich,dasdie Suchein X.500konformenVerzeichnissenermoglicht. Ein Protokoll, dasvon derPKIX-Arbeitsgruppefur den Zugriff auf offentliche Zertifikate in X.500-Verzeichnissenangepaßtwurde,ist das“Lightweight Directory AccessProtocol” (LDAP, vgl. [42]). Die Erweiterun-genlegenfest,welcheProtokollfunktionenvon LDAP-Implementationenmindestensfur denZugriff auf Zertifikate unterstutzt werdenmussen,so daßnicht unbedingtdie vollstandigeLDAP-Protokollfunktionalitat implementiertwerdenmuß.

4.5 AnwendungenaußerhalbdesProtokollstapels 65

4.4.5.1 LDAP fur Zugriff auf Zertifikate: Fur den Zugriff31 auf Zertifikate konntedasLDAP-Protokoll weitervereinfachtwerden.Ursprunglichist LDAP seinerseitseineVereinfa-chungeinesITU-T Protokolls mit demNamen“Directory AccessProtocol”(DAP).

LDAPwird fur dieKommunikationzwischen“CertificationAuthorities”(CA) mit demX.500-Verzeichnisdiensteingesetzt. Clients konnenebenfalls mit LDAP auf dasVerzeichniszu-greifen,um offentlicheZertifikatezu bekommen. Da die Zertifikatevon einerCA signiertsind,wird dieKommunikationzwischenClientundVerzeichnisservernichtauthentisiert.DieGultigkeit einesZertifikateskannder Client nachdemEmpfangmit Hilfe der CA-Signaturverifizieren. Da essich weiterhinum offentlicheZertifikatehandelt,wird der Zugriff auchnicht verschlusselt.Die ubertragenenZertifikatesindnichtgeheim.

Beim schreibendenZugriff einerCA auf denVerzeichnisdienstmußnaturlich eineAuthen-tisierungstattfinden.LDAP unterstutzt hierfur denKerberos-basiertenTicket-Mechanismus(vgl. Abschnitt3.6.2).

4.4.5.2 Zertifikatabfrage einesClients mit LDAP: Der einfachsteZugriff bestehtin derAbfrageeinesZertifikatsvon einemClient bei einemVerzeichnisserver. LDAP setztauf TCPauf. Vor der Abfragemußzum Erhalt der Kompatibilitat mit DAP eineRegistrierungbeimServer erfolgen,die allerdingsanonym seinkann. Danachkonnenbeliebigviele AbfragenundAntwortenerfolgen,bis sichderClient wiederabmeldet.Ein einfacherZugriff mit zweiAbfragenist in Abbildung137dargestellt.

Der Zugriff erfolgt anonym (Leerstringim “bindRequest”mit der Version2 (V2) desProto-kolls). Eswerdenzwei Zertifikateangefordert.Der Server wird auf jedeAnfrageeineAnt-wort (“searchResult”)senden,in derer angibt,ob ein Fehlerauftrat. Bei dererstenAnfragesendetder Server eineFehlermeldungmit demHinweis, daßer dasangeforderteZertifikatnicht kennt. Die zweite Anfrage ist erfolgreicher. Es werdenein odermehrereZertifikatezuruckgesendet,abhangigvonderSuchanfrage.

Resumee: Verzeichnisdienstefur Zertifikatewerdenbenotigt,damitClientsdievonSchlusselmanagement-Protokollen versendetenZertifikateuberprufenkonnen,ohneselbersamtlicheZertifikatevor-zuhalten. Die Clients kontaktierenmit einemeinfachenDatenbankabfrage-Protokoll einenZertifikatsserver, um die gewunschtenZertifikateanzufordern.Ein Client kanndannprufen,obdasZertifikat einegultigeSignatureinerCA enthalt undmit dembeimSchlusselaustauschempfangenenZertifikat ubereinstimmt.

4.5 Anwendungenaußerhalb desProtokollstapels

KryptographischeVerfahrenwerdenauchaußerhalbdesProtokollstapelsangewendet.GrundsatzlichkannjedesAnwendungsprogrammauf einemEndsystemkryptographischeVerfahreneinset-zen.

31 Zugriff: Eintragen,Suchen,AndernoderLoschen


ldap

LDAPMessage (0, bindRequest, V2, "", 0)

LDAPMessage (0, bindResponse, success)

LDAPMessage (1, searchRequest, Zertifikatsbezeichner,...)

LDAPMessage (2, searchRequest, Zertifikatsbezeichner,...)

LDAPMessage (1,searchResponse, noSuchObject)

LDAPMessage (2, searchResponse, Zertifikat(e), success)

LDAPMessage (3, unbindRequest)

Client Server

Abbildung23: AbfragevonZertifikatenmit LDAP

Besonderswichtig ist “Pretty GoodPrivacy” (PGP).Eshandeltsichhierbeium Festlegungenfur die Verschlusselung,IntegritatssicherungunddasAnbringenvon digitalenSignaturenanelektronischerPost(E-Mail) undumdieDefinitioneinesgeeignetenNachrichtenformatszumVersendenvon verschlusselterE-Mail. Die verschlusseltenE-Mails konnenwie jedeandereE-Mail versendetwerden.PGPist allerdingswederein Protokoll nocheineErweiterungdes“Simple Mail TransportProtocols”(SMTP).Vielmehrstellt PGPdie lokaleSoftwarefur Ver-und Entschlusselungvon beliebigenTexten sowie die Verwaltungvon privat erstelltenoderbezogenenSignaturenzurVerfugung.

WeitereAnwendungenerstellendigitaleSignaturenfur einzelneDateienoderganzeVerzeich-nisbaume. DerartigeSignaturenermoglichendasErkennender Herkunft von Dateienundwerdendaheroft zusammenmit denDateienin FTP-Archivenhinterlegt. Auf dieseAnwen-dungenkannhier nichtweitereingegangenwerden.

Resumee: Esgibt vieleAnwendungsprogramme,diekryptographischeVerfahrenzurVerar-beitungvonInformationenaußerhalbdesKommunikationssubsystemseinsetzen.Etablierthatsichvor allemPGPzumkryptographischenAbsichernvonelektronischerPost.

4.6 Nicht durch kryptographische Protokolle abgedeckteSicherheitsprobleme

Im Abschnitt3.4wurdeeinleitenddargestellt,daßmit Hilfe vonkryptographischenVerfahrendie Vertraulichkeit, Integritat,AuthentizitatundUnleugbarkeit vonNachrichtenin Kommuni-

4.6 Nicht durchkryptographischeProtokolle abgedeckteSicherheitsprobleme 67

kationssystemengesichertwerdenkann.In denvorherigenAbschnittenwurdenverschiedeneProtokolle vorgestellt,die dieseVerfahrennutzen,um auf verschiedenenEbenenim Kommu-nikationssubsystemNachrichtenzuschutzen.

EsgibtabereineReihevonSicherheitsproblemen,dienichtdurchkryptographischeProtokollegelostwerdenkonnen.TeilweiseverscharfensichsogarbekannteProblemedurchdenEinsatzkryptographischerVerfahren.DieseProblemelassensichin folgendeKategorieneinteilen:

Administrationsfehler: Die sichereKonfigurierungvon Dienstenist nicht trivial. Unerfah-reneoderuberlasteteAdministratorenkonnenleicht Fehlerbei derKonfigurierungma-chen,diespatertrotzdesEinsatzesvonAuthentisierungundVerschlusselungzuSicher-heitsproblemenfuhren. Wird beispielsweiseIPv6 eingesetzt,ergibt sich darausnichtzwangslaufig,daßIPsecverwendetwird. Fur einenDienst,derfalschkonfiguriertwur-de, konntedasbedeuten,daßauf ihn ohneAuthentisierungzugegriffen werdenkann,obwohl starkeAuthentisierungvon demDienstpotentiellunterstutztwird.

Geradebeim Einsatzvon kryptographischenVerfahrenist ein sehrspeziellesWissenfur die Administrationerforderlich. Die Materie ist derartkomplex, daßSicherheits-administrationnicht einfach“nebenbei”erledigtwerdenkann. Ein AdministratormußumfangreicheKenntnisseuberdieeingesetztenVerfahren,derenMoglichkeitenundderverbleibendenRestrisikenhaben,um denEinsatzuberhauptplanenzu konnen.Danachist zusatzlichwerkzeugspezifischesWissenerforderlich,umdieausgewahltenVerfahrenim Produktionsbetriebsicherkonfigurierenundbetreibenzukonnen.KryptographischeVerfahrenschutzennicht vor Konfigurations-undAdministrationsfehlern.

Softwarefehler: Ein ahnlichesProblemergibt sich durchSoftwarefehler. Kommerzieller-worbeneSoftware kann meist nicht anhanddesQuellcodesverifiziert werden. Feh-lerhafteSoftwarekonnteunerlaubtDatenverschlusseltoderunverschlusseltversenden(exportieren).

kritische Kommunikationsanforderungen: In Unternehmengibt esoft altereAnwendun-gen,dieunternehmenskritischsindundin jedemFall eingesetztwerdenmussen.Manch-mal kanndieseSoftwarenicht mit kryptographischenVerfahrenzusammeneingesetztwerden,dadasjeweiligeSystemnichtmehrnachtraglichumneueProtokolle wie IPsecoderTLS erweitertwerdenkann. In diesemFall mußeineandereArt der Authenti-sierung– zumBeispielmit Hilfe einesFirewalls – gewahlt werden.KryptographischeVerfahrensindnicht in jedemFall verfugbar.

DoS: Wie nochweiteruntengezeigtwird, ist Verschlusselungsehrrechenaufwendig.AuchandereFunktionen,wie beispielsweiseZertifikatsuberprufungoderAuthentisierungundSchlusselverteilungstellen im Vergleich zur ungesichertenKommunikationeinener-heblichenMehraufwanddar. GeradedieseFunktionenkonnengezielt fur “Denial ofService”-Angriffe ausgenutztwerden. Angreifer partizipierenan diesenFunktionennicht mit demZiel, einegesicherteoderauthentisierteKommunikationsbeziehungein-zugehen,sondernumdieEtablierungandererKommunikationsbeziehungendurchmas-sivenMehraufwandin denbeteiligtenSystemenzu behindern.KryptographischeVer-fahrenschutzennichtgegendenVersuch,siezumißbrauchen.

68 5 VORTEILE DURCH EINEN KOMBINIERTEN EINSATZ

Zugriffsk ontrolle: Die Moglichkeit zur geheimenund authentisiertenKommunikationbe-deutetnicht zwangslaufig, daß jegliche geheimeoder authentisierteKommunikationaucherlaubtist. EineFirma,die beispielsweiseerreichenmochte,daßihre Mitarbeiterzu bestimmtenZeitennicht denWebbrowserbenutzen,kanndiesnicht durchkrypto-graphischeVerfahrendurchsetzen.KryptographischeVerfahrenermoglicheneineAb-sicherungder Kommunikationsbeziehungen,konnenjedochnicht die EinhaltungvonUnternehmensrichtlinienerzwingen.

Resumee: KryptographischeVerfahrenkonnennicht alle Sicherheitsproblemelosen. AlleArten von Software-undAdministrationsfehlersindpotentielleSicherheitslocher. AufgrunddeshohenAufwandes,dermit kryptographischenOperationenverbundenist, sindkryptogra-phischabgesicherteDienstezusatzlichbesondersanfallig gegenDoS-Angriffe.

4.7 Ausblick

Mit AusnahmederSSH-undSSL-Protokolle ist eszur Zeit ungewiß, welchederdiskutiertenProtokolle sich in Zukunft durchsetzenwerden.Fur viele Protokolle gibt esbereitsPrototyp-ImplementationenunderstekommerzielleLosungen,die Testsermoglichen.Esist jedochzufruh,umEmpfehlungenfur denEinsatzbestimmterVerfahrenin ProduktionsnetzenaufBasisdieserPrototypenzugeben.

Aus heutigerSicht zeichnensich allerdingsTendenzenab. So wird die KommunikationimLAN-BereichzunehmenddurchIPSecabgesichertwerden.FurZugriffeaufDNS-Informationenwird “SecureDNS” eingesetztwerden.Es ist davon auszugehen,daßerstdie Server fur ihre“Zone Updates”undspaterauchClientsAuthentisierungundIntegritatsprufungunterstutzenwerden.DieAbsicherungvonWWW-basiertenTransaktionen,insbesondereim “E-Commerce”-Bereich,wird uberSSLbzw. uberTLS (nacheinerStandardisierung)erfolgen.LosungenaufBasisvonSSLwerdenbereitsheuteeingesetzt.

Im Zusammenhangmit dem“E-Commerce”,aberauchdurchdenzunehmendenEinsatzvonPGP, wird der Ausbauvon CAs weiter voranschreiten.Einhermit diesemAusbausteigtderBedarfnachProtokollenzumZugriff aufdieZertifikate,sodaßLDAP anBedeutunggewinnenwird.

Fur die sofortigeAbsicherungvon interaktiven Sitzungenund “Remote”-KommandoskannSSLuneingeschranktempfohlenwerden.

5 Vorteile durch einenkombinierten Einsatz

Aus denin Abschnitt39 undAbschnitt141dargestelltenProblemen,die einerseitsbei reinenFirewall-Losungenundandererseitsbei reinen“Krypto”-L osungenoffen bleiben,ergibt sichderWunsch,die jeweiligenVorteilederVerfahrenzukombinieren.

5.1 NutzenkryptographischerVerfahrenfur Firewalls 69

EshandeltsichbeiZugriffskontrollmechanismenundkryptographischenVerfahrenumortho-gonaleTechniken. ZugriffskontrollebietetSchutzgegenunerlaubtenZugriff, Kryptographiesichertdie Zugriffe selbstab. Aus diesemGrundkann die jeweils andereTechnik bei denoffenenProblemennutzbringendverwendetwerden(s.u.). Esgibt jedochauchProbleme,dasichdie jeweiligenMechanismengegenseitigbehindernkonnen.Auf dieseProblemewird inAbschnitt6 eingegangen.

In den folgendenUnterabschnittenwird dargestellt,wie ein kombinierterEinsatzvon Fire-walls mit kryptographischenVerfahrendie Netzwerksicherheitdeutlicherhohenkann. DieseDarstellungwird einerseitsausderSichteinerexistierendenFirewallumgebungerfolgen,in-demderNutzenfur FirewallsdurchdenzusatzlichenEinsatzvonkryptographischenVerfahrenaufgezeigtwird (vgl. Abschnitt5.1).

Auf der anderenSeitekannmandenStandpunktvertreten,daßdie kryptographischenMe-chanismendie grundlegenderenSicherungsmoglichkeitenbieten. In diesemFall stellt sichdennochdie Frage,wie Firewalls eingesetztwerdenkonnen,um die verbleibendenSicher-heitsrisikeneinzudammen(vgl. Abschnitt5.2).

Die SymbioseeroffnetauchneueMoglichkeiten,die in ZukunfteineneffizienterenundfeinergranuliertenEinsatzvon Sicherungsmechanismenerlauben.

5.1 Nutzenkryptographischer Verfahren fur Fir ewalls

In diesemAbschnittwird gezeigt,wie durchkrytographischeVerfahrendie bei heutigenFire-wallsbestehendenSchwachstellenbeseitigtwerdenkonnen.

5.1.1 Authentisierung

Die Authentisierungist bei heutigenFirewalls fur viele Anwendungsfalle nur unzureichendgelost. JederZugriffskontrollmechanismus,seiesein Firewall oderdie Kontrollevon Datei-zugriffen in einemEndsystem,erfordertzuersteineAuthentisierungdeszugreifendenSub-jekts. Da Packet Screenskeineexplizite Authentisierungdurchfuhrenkonnen,verlassensiesichmit IP-AdressenundPortnummernauf die bekanntermaßenleicht falschbarenInforma-tionen im Protokoll-Header. DieselbenInformationenwerdenteilweiseauchvon einfachenProxiesverwendet,da dieseForm der Authentisierungkeine Interaktionmit dem Benutzererfordert. Bei hoherenSicherheitsanforderungenerfolgt zur Zeit eineAuthentisierungdurch“Einmal-Paßworte” oder “Challenge-Response”Verfahren. Bei “Einmal-Paßworten” erhaltder Benutzereine Liste von Paßworten, die uber eine Einweg-Funktion (z.B. eine Hash-Funktion)voneinanderabhangen. Beim “Challenge-Response”Verfahrensendetder ProxyeinenWert (“Challenge”),denderBenutzerzusammenmit einemPaßwort ubereineEinweg-Funktionverarbeitet.DasErgebnisdieserBerechnung– die “Response”– wird andenProxyzuruckgesendet.NacherfolgreicherAuthentisierungschaltetder Proxy die VerbindungzumgewunschtenZiel durch. Da nur amAnfangeineAuthentisierungdurchgefuhrt wird, besteht


dieGefahr, daßdieVerbindungnacherfolgreicherAuthentisierungvoneinemAngreiferuber-nommenwird. DieseUbernahmekannsowohl im Netz uber “TCP-Hijacking” als auchimEndsystemerfolgen.

Der EinsatzkryptographischerVerfahrenin Protokollen kannzukunftig fur einestarke Au-thentisierungamProxygenutztwerden.Ein wichtigerVorteil desEinsatzeskryptographischerVerfahrenist die VereinfachungderAuthentisierungfur denBenutzer. Einmal-Paßworteund“Challenge-Response”VerfahrenmachtenbisherimmereineInteraktionmit demBenutzerer-forderlich.BeimEinsatzkryptographischerVerfahrenbrauchtderProxynurzuuberprufen,obdie Authentisierungsinformationenmit demprivatenSchlusseldesBenutzersgeneriertwur-den. Dies kannin der Regel transparentfur denBenutzergeschehen.Der privateSchlusselist entwederaufeiner“Smartcard”gespeichertodererwird verschlusseltim Systemabgelegt.Damit Authentisierungsinformationenvon der Client-Applikationgeneriertwerdenkonnen,mußderBenutzerdenprivatenSchlussel“freigeben”,indemer zumBeispieldengespeicher-tenSchlusselubereinePaßphraseentschlusselt.Ob die Freigabewie bei PGPbei jedemZu-griff aufdenSchlusselerfolgenmußoderwie beim“SSH-Agent”einmalbeimEinloggenvomBenutzerfreigegebenwird, laßtsichheutenochnicht vorhersehen.Unabhangigvom EinsatzeinesFirewalls muß der Benutzerden privatenSchlusselbeim Verbindungsaufbauzur Au-thentisierungbeimServerfreigeben,sodaßdieserSchlusselfur eineebenfalls stattfindendenAuthentisierungamProxyohneweitereInteraktionmit demBenutzervom Client eingesetztwerdenkann.

Bei PacketScreenswird durchEinsatzvonIPsecebenfallseineAuthentisierungmoglich. Wiein Abschnitt4.2.1beschrieben,konnenzu jedemDatagrammuberden“AuthenticationHea-der” (AH) Informationenzur Authentisierungund zur Sicherungder Integritat hinzugefugtwerden.Dadie UberprufungdesAH durcheinePacketScreenbei derEntwicklungdesIPsecStandardsnichtberucksichtigtwurde,ist die Integrationschwierig.Die Informationenim AHwerdenmit Hilfe einessymmetrischenkryptographischenVerfahrenserzeugt.Fur die Uber-prufungdesAH wird derselbeSchlusselbenotigt, dervor BeginndesKommunikationsflussesdurchdasKey-Management-Protokoll zwischenSenderundEmpfangervereinbartwird.

Um der Packet Screendie Uberprufung desAH zu ermoglichen,werdenin [14] drei unter-schiedlicheLosungsmoglichkeitenvorgeschlagen:

ã Die naheliegendeundeinfachsteLosungwarees,dasKey-Management-Protokoll sozuerweitern,daßdiePacketScreendenfur dieGenerierungdesAH verwendetenSchlusselbei einemderKommunikationspartnererfragenkann.AllerdingswurdediesderPacketScreennichtnurdiegewunschteKontrolledesAH ermoglichen,sondernauchdieGene-rierungvonPaketenmit korrektemAH. DerEmpfangerkannnichtmehrunterscheiden,ob essichum ein Paket desvermeintlichenSendersoderum ein gefalschtesPaket derPacket Screenhandelt.DieseLosungist dahernichtempfehlenswert.

ã Um dieseMoglichkeit desFalschensvon Paketendurchdie Packet Screenzu vermei-den,mußder Sendermit der Packet ScreeneineneigenenSchlusselvereinbaren.DerSendergeneriertzunachstwie auchim vorigenFall ein Paket, dasan denEmpfangergesendetwerdensoll. Die Packet ScreenweistdiesesPaket abund fordertdenSender

5.1 NutzenkryptographischerVerfahrenfur Firewalls 71

auf, zuersteinenSchlusselzu vereinbaren.NachderVereinbarungdesSchlusselskannderSenderjetzt IP-Datagrammemit “AuthenticationHeader”generieren,diediePacketScreenkontrollierenkann.In diesenDatagrammeneingepacktsinddie IP-Datagrammefur deneigentlichenEmpfanger. Nachder Uberprufung des“AuthenticationHeaders”schicktdie Packet ScreendasenthalteneinnereDatagrammweiterandenEmpfanger.

DasHinzufugenweiterer“AuthenticationHeader”ist nur im “Tunnel-Mode”alsozu-sammenmit einemweiterenIP-Headermoglich. Sind auf demWeg vom SenderzumEmpfangermehrereFirewallszuuberqueren,kanndieAnzahlderHeadersehrgroßwer-den. Fur jedenFirewall mussenmindestens352Bits anHeader-Informationenerganztwerden:160Bits werdenfur einenIPv4Headerbenotigt, weitere192Bits ist dieLangeeines“AuthenticationHeaders”(vgl. Abschnitt 4.2.1). DieseLosungkanndahernurdannverwendetwerden,wennnureinegeringeAnzahlvonFirewalls uberquertwerdenmuß.

ä Eine dritte mogliche Losungist die Verwendungvon asymmetrischenkryptographi-schenVerfahrenzur Berechnungdes“AuthenticationHeaders”. In der Definition des“AuthenticationHeaders”[25] ist bereitsdie Integration weitererVerfahrenzur Be-rechnungderAuthentisierungsdatenvorgesehen.Durchdie Verwendungvon Signatur-Verfahrenwird esmoglich,daßjeder, derim BesitzdesoffentlichenSchlusselsist, den“AuthenticationHeader”uberprufenkann,abernurderSendermit demdazugehorendengeheimenSchlusselden“AuthenticationHeader”erzeugenkann.

LeidererfordernSignatur-VerfahrendeutlichmehrBerechnungenalssymmetrischeVer-fahrenwie MD5. Selbstbei MD5 bestehenschonjetzt Bedenken,ob die Prozessorlei-stungundsomitdieGeschwindigkeit fur alleAnwendungenausreichendseinwird [40].Daherist esnicht sehrwahrscheinlich,daßasymmetrischeVerfahreneinegroßeVer-breitungfindenwerden.

Da asymmetrischeVerfahrenbeim “AuthenticationHeader”nur optional zugelassensind, werdenviele Rechnerund RouterkeineasymmetrischenVerfahrenunterstutzen.KannkeinasymmetrischesVerfahrengefundenwerden,dasalleBeteiligtenunterstutzen,dannmußalskleinstergemeinsamerNennerein nachdemStandarderforderlichesVer-fahrenwie “MD5” benutztwerden.

Ein weiteresProblembestehtdarin,daßdiePacketScreenauchbeidenasymmetrischenVerfahrendasKey-Management-Protokoll nutzenmuß,um denSchlusselzu erhalten,mit dem danndie Signaturenuberpruft werdenkonnen. Bei der großenAnzahl vonVerbindungen,diedurcheinePacketScreenhindurchaufgebautwerden,wird durchdasKey-Management-Protokoll einedeutlicheLasterzeugtwerden.

Inzwischenist diezweiteLosungvonverschiedenenAutorenaufgegriffenwordenundscheintsichdaheralszukunftigeLosungfur diesesProblemabzuzeichnen.

Resumee: Durch denEinsatzvon kryptographischenVerfahrenist einesichereAuthenti-sierungauf demFirewall moglich. DieseAuthentisierungkannaußerdemtransparenterfol-


gen,da auf “ChallengeResponse”-Verfahrenund Einmal-Paßwortebeim Einsatzkryptogra-phischerAuthentisierungverzichtetwerdenkann. Bei derVerschlusselungauf der IP-EbenekanndurchasymmetrischeVerschlusselungeineAuthentisierungder Dateneinheitensowohlfur denEmpfangeralsauchfur einePacket Screenstattfinden.

5.1.2 Integrit at ubertragener Daten

Die SicherungderIntegritat ubertragenerDatendurchdenEinsatzkryptographischerVerfah-rendecktdie Lucke ab,die bei herkommlichenProxiesdadurchentsteht,daßeineAuthenti-sierungnur beimVerbindungsaufbauerfolgt. NacheinererfolgreichenAuthentisierungwirddaraufvertraut,daßalle auf derselbenTCP-VerbindunggesendetenDatenebenfalls vom au-thentisiertenBenutzerstammen.DurchTCP-HijackingAngriffe aufeinebereitsauthentisierteVerbindungkonntenbisherFirewalls umgangenwerden.

5.1.3 Erweiterte Zugriffsk ontrolle

Die starke Authentisierungunddie Wahrungder Integritat ubertragenerDatenermoglicht ei-ne feinergranulierteZugriffskontrolle. BisherigeFirewalls fuhrteneinedienstorientierteZu-griffskontrolledurch.Zugriffe auf bestimmteDienste— SMTP, TELNET, FTP, etc. — wur-denabhangigvon denSicherheitsanforderungendesDienstesgewahrtoderunterbunden.DiesichereAuthentisierungeinesBenutzerskannzu einerbenutzerorientiertenZugriffskontrollefuhren,bei denenBesitzerbestimmterSchlusselfreienZugriff erhalten,wahrenddie Zugrif-fe mit anderenSchlusselnnochstarker kontrolliert werden.Dabeiist esnicht entscheidend,ob die Zugriffskontrolle letztendlichuber“AccessControl Lists” (ACLs) oder“Credentials”implementiertwird.

5.1.4 Fernadministration von Fir ewalls

UberkryptographischeVerfahrenist aucheingesicherterZugangzumFirewall selbstmoglich.Bisherwar fur die sichereAdministrationeinesFirewalls ein Login anderKonsoledesFire-wallsnotwendig.DiesschranktedieFlexibilit ateinundverhinderteeinezentraleAdministra-tion. Mit derdurchkryptographischeVerfahrenermoglichtenFernadministrationwird eserstjetzt praktikabel,zentraleund dezentraleFirewalls miteinanderzu kombinieren. Durch einzentralesManagementkonnensodezentraleFirewalls fur eineweitereAufteilung einesNet-zesin einzelneSubnetzeeingesetztwerden,bei denendie SubnetzenachSicherheitsgesichts-punktenaufgeteiltwerden.DurcheinensolchenAnsatzkanndie Sicherheitweitergesteigertwerden,daexternenAngreifernnacheinemUberwindendesaußerenFirewallsnichtmehrdasgesamteinterneNetz offensteht.Auch gegendie bishernicht abgedecktenInsider-AngriffebietetdieweitereAufgliederungdesinternenNetzeseinenhoherenSchutz.

5.2 NutzenvonFirewalls fur kryptographischeVerfahren 73

Resumee: Durch Verschlusselungder Datenkann ein TCP-Hijackingvon Verbindungenverhindertwerden.Angreiferhabensomit keineMoglichkeit mehr, einenFirewall durchdieUbernahmeeinerauthentisiertenVerbindungzu umgehen.Durch die Authentisierung,Ver-schlusselungundIntegritatssicherungist erstmaligauchein sicheres,dezentralesFirewallma-nagementmoglich.

5.2 Nutzenvon Fir ewallsfur kryptographische Verfahren

In diesemAbschnittwird dargestellt,welcheVorteile sich ausdemzusatzlichenBetriebei-nesFirewalls nebendemEinsatzkryptographischerVerfahrenergeben.Die offensichtlichenProblemedesalleinigenEinsatzesvonkryptographischenVerfahrenwurdenim Abschnitt141zusammengefaßt.DieseProblemekonnendurchFirewallsgelostoderzumindestdeutlichver-ringert werden. Daruberhinausgibt eseinigeneueMoglichkeiten,die ohnegleichzeitigenEinsatzvon FirewallsundkryptographischerVerfahrennichtdenkbarsind.

5.2.1 Fir ewallsfur offeneProbleme

Die in Abschnitt141zusammengefaßtenProblemesollenhier wiederaufgenommenwerden.Fur diemeistenProblemegibt esoffensichtlicheLosungen,dieaufdemEinsatzvonFirewall-mechanismenberuhen.

5.2.1.1 Administrationsfehler und Softwarefehler: EineReihevonAdministrations-undSoftwarefehlern,die direkt die Sicherheiteineszu schutzendenNetzesgefahrden,lassensichtrivial durchZugriffskontrollmechanismenaufeinemFirewall erkennenundeindammen.Bei-spielsweisekann auf einemFirewall erkanntwerden,ob Verbindungenausoder in daszuschutzendeNetz verschlusseltsind odernicht. UnverschlusselteVerbindungenvon und zufalschkonfiguriertenServern,die eigentlichverschlusseltseinsollten,konnenaneinemFire-wall abgelehntwerden. Ein falschkonfigurierterServer, der eineunverschlusselteund un-authentisierteVerbindungannehmenwurde,konntesomitnichtmehrvonaußerhalbangegrif-fen werden,da der Firewall diesenZugriff nicht zulaßt. Dasgleichegilt fur SoftwarefehleroderunerwunschteFunktioneneinerSoftware,dieungewollt DatenubereinNetzexportieren.Auch hier kannein Firewall unterbinden,daßkritischeDatendasgesicherteNetzverlassen.

DurchdieAudit-FunktionenkannderFirewall daruberhinauseingesetztwerden,umfruhzeitigAdministrations-oderSoftwarefehlerim internenNetzanzuzeigen,diezueinerunerwunschtenKommunikationmit externenRechnernfuhrenwurden.Der Firewall verhindertnicht nur dieKompromittierungeinesNetzesdurchAdministrationsfehler, sondernzeigtdiesegegebenen-falls auchan. Beispielsweisekann ein Firewall entdecken, ob eineSoftwareversucht,Re-gistrierungsinformationenoderanderesystemspezifischeInformationenan denHerstellerzusenden.


5.2.1.2 Kritische Kommunikationsanforderungen: Ein Firewall bietetsichimmerdannan, wennkryptographischeVerfahrenzur Absicherungnicht eingesetztwerdenkonnen,derungesicherteDienstaberdennocherforderlichist. In einemSzenario,in demein Dienstauf-grundvonHardware-oderSoftware-RestriktionennichtdurchstarkeAuthentisierungderCli-entsabgesichertwerdenkann,mußdieseAuthentisierungstellvertretendaufdemFirewall er-folgen. Der Firewall ermoglicht die starke AuthentisierungeinesZugriffs von außerhalbundsichertsomitdenZugriff auf kritischeDiensteab. Der Firewall bietetsogardie Moglichkeit,erstmaligsicherauseinemungesichertenNetzaufdiekritischenDienstezuzugreifen(vgl. Ab-schnitt5.2.3).

5.2.1.3 DoS: Die kryptographischenVerfahrensind besondersrechenaufwendigund bie-tensichdaherfur “Denial of Service”-Angriffe geradezuan.Ein Firewall kannauchin diesemFall deutlichdasRisiko verringern. In der Regel gibt esnur wenigeBenutzeroderMaschi-nen,die Zugriff von externenNetzenauf Diensteim internenNetz erhaltensollenund sichzuvor authentisierenmussen.Allen anderenClientssollte nicht einmaldasAushandelnvonAuthentisierungs-undVerschlusselungsverfahrengestattetwerden.

In diesemFall kannder Firewall eineVorauswahl treffen. Aufgrund der typischerweiseun-verschlusseltenAbsenderadressewurdenZugriffe von Rechnern,die nicht ohnehinpotentiellZugriff erhielten,sofort abgeblocktwerden. Von diesenRechnernist dannauchkein DoS-Angriff mehrmoglich. Der Aufwandhierfur ist fur einenFirewall um Großenordnungenge-ringer als auf demServer, falls die Vorauswahl uberIP-Adressenerfolgt. Der Server wurdehingegenin jedemFall versuchen,dieAuthentisierungprozedurenzudurchlaufen,unabhangigvon derHerkunftderDateneinheitenbzw. derVerbindungsanforderungen.

Offensichtlichwird der Vorteil durchdenzusatzlichenEinsatzeinesFirewalls, falls ein be-stimmterDienst ohnehinnur ausdem gesichertenNetz nacheinerstarken Authentisierungzugreifbarseinsoll. OhneeinenFirewall wurdensamtlicheDoS-Angriffe denServer errei-chen.Mit einemFirewall ist ein DoS-Angriff ausdemInternetherausnichtmehrmoglich,daderFirewall VerbindungenzudeminternenSystemapriori ablehnt.

5.2.1.4 Zugriffsk ontrolle: Die Moglichkeit,DatenzuverschlusselnoderZugriffe aufSer-verzuauthentisieren,ist vollig orthogonalzueinerZugriffskontrolle,dieunerwunschteKom-munikationverhindert.Soll derZugriff voneineminternenNetzaufBetriebsmittelim InternetausirgendwelchenGrundenverhindertwerden,ist unbedingtein Firewall erforderlich. DasVerhindernunerwunschterKommunikationkannnicht durchkryptographischeMechanismenerreichtwerden.

Resumee: Der zusatzlicheEinsatzvon Firewalls fur die Zugriffskontrolle verhindertoderlindert verbleibendeSicherheitsrisiken,die nicht durchdenalleinigenEinsatzvon kryptogra-phischenVerfahrenausgeschlossenwerden.Ein Großteilder externenDoS-Angriffe auf re-chenintensive, kryptographischgesicherteDienstekannbereitsamFirewall abgefangenwer-den.


5.2.2 Durchsetzenvon Verschlusselungsrichtlinienam Fir ewall

OhnedenEinsatzeinesFirewalls ist esunmoglich32 durchzusetzen,daßdiekryptographischenMechanismenauchtatsachlicheingesetztwerden.Ein Firewall kannhingegenbestimmteVer-schlusselungs-oderAuthentisierungsverfahrenerzwingen.Diesgilt sowohl fur dieeingehendeKommunikationalsauchfur die ausgehendeKommunikationausdemzu schutzendenNetz.EineFirmakonntebeispielsweiseverlangen,daßDatennur in verschlusselterFormmit exter-nenStellen(Heimarbeiter, Vertretermit Laptops)ausgetauschtwerden,um die Firmendatenzu schutzen.Die EinhaltungdieserRichtlinie ist jedochnur andemzentralenZugangspunktzumNetz— alsoamFirewall — durchsetzbar.

DerartigeVerschlusselungsrichtlinienkonnenbeliebigkomplex gestaltetwerden. AbhangigvonRechnernoderPersonenkonntenbestimmteVerfahrengefordertwerden,die derFirewallindividuell uberpruft unddurchsetzt.

Resumee: Ein Firewall kann durch Zugriffskontrolle den Einsatzvon kryptographischenVerfahrenerzwingen.Firewallskonnendahereingesetztwerden,umbestimmteVerschlusselungsrichtliniendurchzusetzen.ExterneDoS-Angriffe auf kryptographischabgesicherteDienstekonnenamFirewall aufwandsarmabgefangenwerden.

5.2.3 Fir ewall alsVerschlusselungs-Gateway

Ein Beispiel fur einenneuenDienst,dender Firewall anbietenkann, ist die FunktioneinesVerschlusselungs-Gateways. Die starke Authentisierungund anschließendeVerschlusselungeinerVerbindungzu einemFirewall, derdanndie DatenubereinenProxyaneinenkritischen(nicht kryptographischabgesicherten)Dienstweiterleitet,ist ein Beispielfur die VerwendungeinesVerschlusselungs-Gateways. Nebender bereitsobenerwahntenstellvertretendenAu-thentisierungbeimProxyanstellebeimjeweiligenDienstwird sodersichereZugriff aufeinenkritischenDienstausdemungesichertenNetzerstmaligmoglich. Durchdie Verschlusselungder DatenzwischenFirewall und externemRechnerkonnendie zu sicherndenFirmendatendesinternenDienstesbei derUbertragungnichtausspioniertwerden.

HinterdiesemBeispielstehteinviel weitergehendesKonzept.DerFirewall kannin Umgebun-gen mit kryptographischerAbsicherungder Kommunikationals Verschlusselungs-Gatewayeingesetztwerden.EineverschlusselteundeventuellauthentisierteVerbindungwird von ei-nem Firewall-Proxy angenommen.Falls der Dienst, auf den zugegriffen werdensoll, dasjeweilige Verfahrennicht unterstutzt, kannderFirewall eine“Umschlusselung”bzw. Umset-zungdesverwendetenProtokolls durchfuhren. Im obigenBeispielwird lediglich eineEnt-schlusselungohneneueVerschlusselungauf demFirewall durchgefuhrt, da unterdenange-nommenenBedingungenderinterneDienstnicht uberkryptographischeProtokolle ansprech-barist.

32 Die Administrationkonnteversuchen,jedeseinzelneinterneSystemrichtig zukonfigurieren.Problemebereitenin derRegel “PersonalComputer”,dievon ihrenBenutzernselberadministriertwerden.


Die UmschlusselungaufeinemFirewall ist fur dieAnwendernichtmehrtransparent.In einerUmgebung,in derohneFirewall ausschließlicheinekryptographischeAbsicherungderKom-munikationinstalliert ist, magdieseineEinschrankungsein.Zu bedenkenist in diesenFallenjedoch,daßauf den jeweiligen DienstohneUmschlusselungeventuell uberhauptnicht vonaußenzugegriffenwerdenkann.Ein sehreinleuchtendesBeispielist einSzenario,beidemiminternenNetzeinlizenzpflichtigerVerschlusselungs-oderAuthentisierungsalgorithmuseinge-setztwird. Soll derZugriff auchanderenTeilnehmernausdemexternenNetzengewahrtwer-den,mußtensieebenfallsdenlizenziertenAlgorithmusverwendenundgegebenenfalls vorherkommerziellerwerben.DurcheineUmschlusselungauf demFirewall, die auchdie Verifizie-rung von Zertifikatenbei der Authentisierungbeinhaltenkann,konntenexterneTeilnehmereinenanderen(vorhandenenodernicht lizenzierten)Algorithmusverwenden.

Eine Umschlusselungkann außerdemdazubeitragen,den sicherenZugriff auf interneBe-triebsmittelvon außenzu vereinfachen.Falls verschiedeneDiensteintern mit unterschiedli-chenkryptographischenVerfahrenarbeiten,kanndie Umschlusselungeingesetztwerden,umnachaußeneineeinheitlichekryptographischeSchnittstelleanzubieten.Diesist wiederumnurdurcheinenFirewall moglich,derZugriff aufdie netzubergreifendeKommunikationhat.

Resumee: Ein Firewall kanneineUmschlusselungvornehmen,falls in dengetrenntenNet-zenkein Protokoll vorhandenist, daßvon beidenKommunikationspartnernfur die Absiche-rung verwendetwerdenkann. Ein wichtiger Spezialfall ist dasAnbieteneinereinheitlichenkryptographischenSchnittstellezuminternenNetzdurcheinenFirewall.

5.2.4 Zertifikatsk ontrolle im Fir ewall

In einemNetz,dasmit kryptographischenMechanismenabgesichertwird, ist fur die Authen-tisierungundanschließendeVerschlusselungder offentlicheSchlusseldesKommunikations-partnerserforderlich.

In großenverteiltenSystemenistesnichtmehrmoglich,alleZertifikatemit signiertenoffentlichenSchlusselnlokal auf jedemClient vorzuhalten.Vielmehrwird ein Client oderein Server beiBedarfein Zertifikat voneinemZertifikatsserveranfordern.

Auf einemFirewall kannzusatzlicheineZertifikatskontrollestattfinden.Abhangigvom Sze-nario lassensichsoverschiedeneRichtliniendurchsetzen.Am Beispielvon Zertifikaten,diein X.509-Verzeichnissengespeichertwerden,soll diesesVorgehenverdeutlichtwerden. FurdenZugriff wird in diesemBeispieldasobendiskutierteLDAP-Protokoll verwendet(vgl. Ab-schnitt4.4.5.2).

Der Standardfall ist der Zugriff vom Internetauf ein X.509-Verzeichnis,dasauf einemin-ternenRechnerabgelegt ist. Typischerweisewird eineFirma in einemsolchenVerzeichnisalle moglicheninternenZertifikatemit weiterenZusatzinformationenabspeichern.DerartigeZusatzinformationensollenoft nur internzuganglichsein,beispielsweiseRaum-undTelefon-nummereinesMitarbeitersoderseineBurozeiten. Gleichzeitigwird manauchinterneZer-


tifikate, die ausschließlichfur firmeninterneKommunikationbestimmtsind, auf demselbenServerablegen.

Ein Firewall ist in derLage,externeAnfragenzuerkennen.DurcheineZugriffskontrollekannbereitsvor demZugriff auf denServer uberpruft werden,ob essichum eineAnfragenachei-nemZertifikathandelt.In einemsolchenFall mußtesichdieSuchanfragederLDAP-Nachricht(vgl. Abbildung137,S.23)auf folgendeAttributtypen(UserCertificate, CACerti-ficate, CrossCertificatePair ) beschranken. Ein Firewall kann die SuchenachanderenAttributtypenbereitsvor demZugriff auf denServer ablehnen,beispielsweisewennvoneinemexternenRechnerdie RaumnummereinesMitarbeitersabgefragtwird.

Die Antwort desServers sollte ebenfalls vom Firewall uberpruft werden. Auch wenn derZugriff bereitsauf Zertifikateeingeschranktwurde,kannessinnvoll sein,die Herausgabebe-stimmterZertifikatezu unterbinden.Diestrif ft im obigenBeispielaufdie internenZertifikatezu, die nur fur firmeninternenGebrauchvorgesehensind. Die Zertifikatskontrollekannauchverwendetwerden,um die HerausgabeabgelaufenerZertifikate zu unterbinden. Die darinenthaltenenSchlusselnmussenunterUmstandendeutlichlangeraufbewahrt werden,als dieGultigkeitsdauerangibt. Da Schlusselmit abgelaufenenZertifikatenandererseitsnicht mehrverwendetwerdensollen,mußdie Herausgabeunterbundenwerden.

In RichtungdesexternenNetzeskann eine Zugriffskontrolle ebenfalls sinnvoll sein. Fallsein internerRechnerein Zertifikat von einemexternenVerzeichnisdienst(z.B. einemLDAP-Server)anfordert,kannderFirewall beispielsweiseprufen,obdasZertifikateinenachinternenRichtlinienals“akzeptabel”klassifizierteSignaturtragt. Ist diesnicht derFall, kannderFire-wall die WeitergabedesZertifikatesunterbindenund sich gleichzeitig,sozusagenpraventiv,die Zertifikats-undSchlusselidentifikationenmerken.

Sollteein internerBenutzerspaterdenSchlusseldes“inakzeptablen”Zertifikatsdennochbe-nutzen,um beispielsweiseein E-Mail zu verschlusseln,konntederFirewall diesaufgrunddergespeichertenSchlussel-IDsaufwandsarm33 erkennenund die Auslieferungder E-Mail ver-weigern.

EineZugriffskontrollekannselbstverstandlichauchaufanderenAttributenderjeweiligenZer-tifikate bzw. der jeweiligenVerzeichnisdiensteberuhen.Sehrinteressantist die Moglichkeit,uber die in den Zertifikaten angegebenenAlgorithmen zu erkennen,ob es sich um “K eyEscrow”-Algorithmen handelt. Ein Firewall konntesomit Richtlinien durchsetzen,die dieBenutzungdieserAlgorithmenentwedervorschreibenoderauchverbieten.

Resumee: Ein Firewall kanndie Benutzungunddie GutederverwendetenZertifikatekon-trollieren. Zertifikate,die nur fur deninternenGebrauchbestimmtsind, werdenvon einem

33 Bei einerPolicy, dieverlangt,daßalleE-Mailsmit bestimmtensigniertenSchlusselnverschlusseltwer-den,mußderFirewall in jedemFall prufen,welcheSchlussel-IDbenutztwird. Durchdievorangegange-neAnfrageist dieserSchlusselin derRegelschonim “Firewall-Cache”,entwederin einer“allow”- odereiner“deny”-Liste. SollteeineunbekannteID benutztwordensein,mußderFirewall mit erheblichenMehraufwandseinerseitseineAnfragean einenVerzeichnisdienststellen,um denSchlusselbewertenzukonnen.

78 6 WECHSELWIRKUNGEN DESKOMBINIERTEN EINSATZES

Firewall gefiltert. Der Zugriff auf externeZertifikate,die nicht deninternenAnforderungengenugen,kannebenfalls vomFirewall abgelehntwerden.

5.2.5 Anonymisierung der Kommunikation mit einemFir ewall

Ein unterUmstandenunerwunschterEffekt beimEinsatzvon starker Authentisierungist, daßdieIdentitatdesKommunikationspartners—in AbhangigkeitvomgewahltenAuthentisierungsverfahren—sehrgenaubestimmtwird. Abgesehenvon anonymenZertifikatenoderGruppenzertifikaten,die die Identifizierungvon Einzelpersonenverhindern,kannauchein Firewall zur Anonymi-sierungderKommunikationsbeziehungeneingesetztwerden.

Um auchauf der IP-EbeneKommunikationsbeziehungenzumindestteilweiseanonym einge-henzu konnen,kannwiederumderFirewall eingesetztwerden.DurcheinenProxywird dieIdentitat desinternenRechnersgeschutzt. AnstelledesinternenRechnerswird eine“Securi-ty Association”(im Falle von IPsec)zwischenServer undFirewall eingegangen.Der Serverkannnundie Identitat desFirewalls erkennen,jedochnicht die Identitat individuellerClientsim internenNetz.

Resumee: Der Firewall kanntrotz starker Authentisierungzur Anonymisierungvon Kom-munikationsbeziehungeneingesetztwerden.

6 Wechselwirkungendeskombinierten Einsatzes

In diesemAbschnittwerdendie Aspektediskutiert,die durchdenkombiniertenEinsatzvonFirewall-Techniken und Kryptographieentstehen.SchwerwiegendeProblemeentstehenda-durch, daß sich die eingesetztenMechanismengegenseitigbehindern. Dies ist insbeson-deredannder Fall, wennein ZugriffskontrollmechanismusInformationenbenotigt, die ver-schlusseltsind.DiesesProblemwird im Abschnitt6.1genauerdargestellt.

Ein weiteresschwerwiegendesProblementstehtdurchdenhohenRechenaufwandkryptogra-phischerVerfahren,die auf demFirewall eingesetztwerden.Der EngpaßFirewall wird nochpragnanter. Auf diesesProblemwird in Abschnitt6.2eingegangen.

6.1 TechnischeAspektedeskombinierten Einsatzes

In diesemAbschnittwerdendie Aspekteder Kombinationvon kryptographischenVerfahren(Abschnitt4) mit denim Abschnitt2.1 vorgestelltenFirewall-Komponentendiskutiert. DasVorgehenorientiertsich an denFirewall-Komponentenund diskutiert fur jedeKomponentedie sichaucheinerKombinationmit einemodermehrerenkryptographischenVerfahrenerge-bendenAspekte.

6.1 TechnischeAspektedeskombiniertenEinsatzes 79

6.1.1 Packet Screens

IPsecund Skip: DiesebeidenProtokolle konnenTeile von einzelnenIP-Datagrammenver-schlusselnundgreifensomitdirekt in die Moglichkeit derPacket Screenein, die Data-grammezu uberprufen.

Bei AH bleibenHeader zugreifbar: Mit demAuthentication-HeaderwerdenlediglichInformationenzurUberprufungvonAuthentizitatundIntegritatdesIP-Datagrammshinzugefugt. Die von derPacket ScreenausgewertetenIP- undTransport-Headerbleibenweiterhinzugreifbar.

ESPverschlusseltTransport-Header: DurchIPsecwerdendiein einemIP-DatagrammtransportiertenDatenverschlusselt. Fur die Packet Screenbleibennur die Infor-mationenim IP-Headerzugreifbar. Der Transport-Header(TCP oderUDP) liegtnur verschlusseltvor.

ESPTransport- und Tunnel-Modesind nicht unterscheidbar: Beieinerverschlussel-ten ESP-Dateneinheitkann nicht zwischenTransport-und Tunnel-Modeunter-schiedenwerden.Erst der EmpfangerkannnachderEntschlusselungfeststellen,ob die DateneinheitbeimTransport-Modefur denEmpfangerselbstbestimmtist,oder ob sich beim Tunnel-Modeein weiteresIP-Datagrammdarin verbirgt, dasaneinenanderenEmpfangerweitergeleitetwerdenmuß. OhnedieseUnterschei-dungsmoglichkeit zwischenTunnel-undTransport-ModekanneinePacketScreennicht einmaleinesinnvolle Zugriffskontrolle anhandder nochunverschlusseltenaußerenIP-Adressendurchfuhren.

Nutzung von ESPfur VPNs: EinePacket ScreenkannESPim Tunnel-Modenutzen,um “Virtual PrivateNetworks” (VPN) mit einervergleichbarenPacket Screenei-nesentferntenNetzeszuvereinbaren.EingehendeDateneinheitenwerdenvon derPacket Screenverschlusseltundin ESP-Dateneinheitenverpackt.Auf derGegen-seitewerdendie ESP-DateneinheitenwiederentschlusseltundunverschlusseltimsicherenNetzweitergeleitet.

Einsatzvon IPsecerzwingen: Der Einsatzvon IPsecdurchdie EndsystemekannvoneinerPacket Screenerzwungenwerden,indemnur Dateneinheitenweitergeleitetwerden,dieuberAH oderESPverfugen.DasAuswertenderHeader-Informationenfindet dabeijedochausschließlichin denEndsystemenstatt. Die Packet Screenuberpruft nur dasVorhandenseinderHeader.

Nutzung von AH zur Authentisierung: Eine Packet Screenkannvor demWeiterlei-tenvon DateneinheiteneineAuthentisierungdesSendersuberAH verlangen.DerSendermußdannAH im “Tunnel-Mode”mit derPacket Screeneinsetzen.Daten-einheitenwerdenvomSendermit einemzusatzlichenIP-Headerund“Authentication-Header”versehen.Als Empfanger-AdressedesaußerenIP-Headerswird die IP-Adresseder Packet Screeneingetragen.Nur der innereIP-Headererhalt Sender-und Empfanger-Adressender Kommunikationspartner. Die Packet Screenuber-pruft denAH undsendetdie enthaltene,innereIP-Dateneinheitweiter. Hierdurchwird fur die Packet ScreeneineAuthentisierungmoglich. Voraussetzungist, daß


der Sendermit der Packet Screendie Verwendungvon AH im “Tunnel-Mode”zusammenmit einemgeeignetenSchlusselaushandelt.Hierfur mußder SenderzunachstKenntnisvonderPacketScreenerlangen,waszumBeispieldurchICMP-NachrichtenderPacketScreenerfolgenkannoderdurchzusatzliche“Tunnel-Records”(TX) im DNS, die vom Senderabgefragtwerdenmussen.Derzeitwird nocher-forscht, welchealternativen Verfahrenein Sendernutzenkann, um eine PacketScreenmit IPsec-FunktionenaufdemWeg zumEmpfangerzuerkennen.

TLS, S-HTTP, SSHund Secure DNSfur Packet Screennicht relevant: DieProtokolleober-halb der Transportschichtwerdenvon Packet Screensnicht ausgewertet. Da IP- undTransport-HeadervomEinsatzdieserVerschlusselungsverfahrenunberuhrtbleiben,ste-hendieseVerfahrennicht im Konflikt mit Packet Screens.Dahersind nur IPsecundSkip fur Packet Screensrelevant.

Unterhalb von IP liegendeSchichtensind nicht relevant: Fur PacketScreens,die in Kom-binationmit einemRouterimplementiertsind,stellt die Verschlusselungbei denunterIP liegendenSchichtenkeinProblemdar, weil dasRoutingaufderIP-Schichtstattfindetunddie Datenvorherin jedemFall entschlusseltwerdenmussen.Bei Packet Screens,die alsBridgerealisiertsind,konnenKonflikte mit einerVerschlusselungauf denunterIP liegendenSchichtenentstehen,falls die Packet Screennicht selbstandemVerfahrenbeteiligt ist.

Resumee: PacketScreensbenotigenZugriff aufInformationenin deneinzelnenIP-Dateneinheiten.Problemetretendaherauf,fallsaufderIP-Ebeneverschlusseltwird. Diesist beimEinsatzvonESPbei IPSecundSKIP derFall. Bei einigentransparentarbeitendenPacket ScreenskonnenProblemeauftreten,wennunterhalbderIP-Schichtebenfalls verschlusseltwird.

6.1.2 Proxiesund Anwendungs-Gateways

Bei denAspektenderKombinationmit kryptographischenVerfahrengibt eskeineUnterschie-de zwischenProxiesund Anwendungs-Gateways,da es sich in beidenFallen um Prozessehandelt,die oberhalbdesProtokollstapelsaufderAnwendungsebeneausgefuhrt werden.

IPsecund Skip: BeideVerfahrenwirken auf der IP-Ebeneund habensomit keinedirektenAuswirkungauf Verfahrenauf derAnwendungsebene.IPsecgesicherteKommunikati-onsbeziehungenzwischenClientundServer uberdenProxyhinweg sindnichtmoglich.Der Firewall-Rechner, auf demderProxyausgefuhrt wird, ist immerEndpunktfur dieIPsec-SAbzw. fur die SKIP-Datagramme.Der Proxykanndaherauf alle ubertragenenDatenzugreifen.Auf beidenVerbindungenzwischenClient undProxysowie zwischenProxy undServer kannIPsecvom Proxy fur die Zusicherungvon Vertraulichkeit oderzurAuthentisierungeingesetztwerden.

6.2 PerformanzbeikombiniertemEinsatz 81

TLS, S-HTTP und SSHkonnentransparent durchgeschaltetwerden: VoneinemProxykonnendie zwischenClient undServer abgesichertenDatentransparentweitergeleitetwerden.BeimEinsatzvonVerschlusselungkannderProxyin diesemFall jedochkeineZugriffs-kontrolleaufdenubertragenenDatendurchfuhren.Fur dieZugriffskontrollestehenalsolediglichdieIP-AdressenundPortnummernderKommunikationspartnerzurVerfugung.

TLS, S-HTTP und SSHmit Proxy alsEndpunkt: Alternativ zurtransparentenWeiterleitungkonnendiegenanntenProtokolle vomProxyauchselbsteingesetztwerden.Die ubertra-genenDatenwerdendannvomProxyentschlusseltundgegebenenfallsvor derUbertra-gungwiederverschlusselt.Dadurcherhalt derProxyZugriff aufdie ubertragenenDatenund kann auf dieseneine Zugriffskontrolle ausuben. Zusatzlich wird so der EinsatzdieserVerfahrenauchzurAuthentisierungvon Zugriffen uberdenProxymoglich.

Kombination mehrerer Verfahren: WennuberVerfahrenaufeinerunterenSchicht(z.B. IP-sec)bereitseineAuthentisierungamProxydurchgefuhrt wurde,kannderProxygege-benenfallsaufeineEntschlusselungderDatenaufeinerhoherenSchichtverzichtenundzumBeispielTLS VerbindungenzwischenClientundServerohneweiterePrufungauchverschlusseltdurchlassen.

Resumee: Beim Einsatzvon Proxy Servern gibt eskeineProblememit IPSec,SKIP oderProtokollen unterhalbder IP-Schicht. Bereitsauf der IP-Ebenewird eine EntschlusselungdurchIPSecoderSKIPvorgenommen,sodaßdieDatenunverschlusseltaufderAnwendungs-ebenebeimProxyvorliegen.

Beim Einsatzvon TLS oder anderenProtokollen auf der Anwendungsebenehat der Proxylediglich Zugriff auf die Protokoll-Header. ReichendieseInformationennicht fur eineZu-griffskontrolleaus,dannmußderProxyalsVerschlusselungs-Gatewaykonfiguriertwerden.

6.2 Performanz bei kombiniertem Einsatz

KryptographischeVerfahrenerforderneinenhohenRechenaufwand. Firewalls sind bereitsohnedenEinsatzkryptographischerVerfahrenin HSNeinEngpaß,sodaßsichdiesesProblemdurchdenEinsatzkyptographischerVerfahrennochverscharfenwird.

Um die Auswirkungender kryptographischenBerechnungenauf denDurchsatzubereinenFirewall abzuschatzen,wurdenMessungenan einemProxy-Server durchgefuhrt. Da essichbei demProxy-Server um eineEntwicklungdesDFN-FWL handelt,konntendie kryptogra-phischenFunktionenaufwandsarmin denProgramm-Codeintegriertwerden.Auf Messungenmit “Packet Screens”wurde verzichtet,da hierbei keine wesentlichanderenErgebnissezuerwartensind.

Zur Verschlusselungder Datenauf dem Proxy wurdendie beidenVerfahren“3DES” und“RC4” verwendet,dadiesdiezurZeit amhaufigstenverwendetenVerfahrensind.


Proxy mit “3DES”-Verschlusselung: NachdemdiegestiegeneLeistungsfahigkeitdurchschnitt-licher WorkstationsdasetablierteDESmit einerfestenSchlussellangevon nur 56 Bitsnicht mehr ausreichendfur eine sichereKommunikationerscheinenlaßt [8] und inNetzwerken die Berechnungenfur dasBrecheneinesSchlusselsleicht auf viele Pro-zessorenverteilt werdenkonnen34, wird zunehmend“Triple-DES” (3DES) als neuerStandardzur Absicherungder Kommunikationangesehen.Anstelle der einmaligenDES-Verschlusselungtritt bei 3DESeinVerschlusseln,EntschlusselnunderneutesVer-schlusselnmit unterschiedlichenSchlusseln. Der Arbeitsaufwand ist gegenubereinernormalenDES-Verschlusselungdreimalsohoch.DadieVerschlusselungzudemin Soft-wareimplementiertwird, fuhrt derEinsatzvon Verschlusselungauf einemFirewall zueinererheblichen,zusatzlichenProzessor-Belastung.

DES ist eineBlock-Chiffre (“Block Cipher”), die bei jedemDurchlauf64 Bit (bzw. 8Byte) großeBlocke verschlusselt.35 KurzereNachrichtenmussengegebenenfalls durchAnhangenvon Fulldaten(“Padding”) vor der Verschlusselungmit DES (oder 3DES)auf ein Vielfachesvon 8 Byte verlangertwerden. DiesesPaddingbei Block-Chiffrenfuhrt zu einerVerlangerungderubertragenenNachrichten.Im ungunstigstenFall uber-schreitetdie NachrichtnachdemPaddinggeradedie MSS (bzw. MTU), wasdie Ge-nerierungeineszusatzlichen,kurzenTCP-SegmentsoderallgemeineineszusatzlichenDatagrammserforderlichmacht. Die Folge sind ein hohererVerarbeitungsaufwandindenEndsystemen.AußerdemmussenmehrHeader-Informationenubertragenwerden,wodurcheingeringererNetzdurchsatzfur die Ubertragungvon Nutzdatenverbleibt.

Fur die Messungenwird ein Proxy um ein Modul erganzt,dasdie vom Server an denClientengesendetenDatenmit 3DES/CBCverschlusselt.36 Da der Client die empfan-genenDatennicht auswertet,ist eineEntschlusselungauf demClientennicht notwen-dig. Die vom Clientenzum Server gesendetenDaten(“GET-Request”)werdenvomProxynichtverschlusselt,weil dieseDatenvomServerausgewertetwerdenmussenundaufgrundder geringenDatenmengeauchnur geringePerformanzauswirkungendurchdie VerschlusselungdieserDatenzu erwartensind.37 DiesesVorgehenermoglicht dieDurchfuhrungder Messung,ohneVeranderungenan den Meßwerkzeugenvorzuneh-men. Die Meßergebnissekonnendaherdirekt mit denbereitsbei anderenMessungengewonnenenDatenverglichenwerden.

34 RSA schrieb 1997 einen Wettbewerb (http://www.rsa.com/rsalabs/97ch allen ge/ )aus, bei dem ein DES-Schlussel gefunden werden sollte, wobei nur ein Teil desTextes in einer verschlusselten Nachricht bekannt war. Die DESCHALL Gruppe(http://www.frii.com/˜rcv/deschall.h tm) entwickelte hierfur eine verteilte Ap-plikation, bei der jeweils Teile des Schlusselraumsvon einzelnen Systemenim Internet zumEntschlusselnder Nachrichtausprobiertwurden. Bis zu 14.000Systemeim Internetbeteiligtensichzeitweisegleichzeitigan diesem“Brute-Force” Angriff. Nach etwa 4 Monatenund fast å£æ{ç5å£èÄé#êSchlusseln konnte der korrekte Schlussel zur Entschlusselungder Nachricht gefunden werden.(http://www.frii.com/˜rcv/despr4.htm )

35 Da die einzelnenBlocke unabhangigvoneinanderverschlusseltwerden,konntenAngreifer die Rei-henfolgederDatenblocke andern.Um dieseManipulationsmoglichkeit auszuschließen,wird uberdas“Cipher Block Chaining”(CBC)eineAbhangigkeit zwischendeneinzelnenBlockenerzeugt.

36 Die 3DES/CBC-Verschlusselungsfunktionensind dem“SecureShell” (SSH)entnommen.(Verfugbarunterftp://ftp.cert.dfn.de/pub/tools/ne t-cry pt/ssh /ssh- 1.2.2 3.tar. gz )

6.2 PerformanzbeikombiniertemEinsatz 83

Proxy mit “RC4”-V erschlusselung: “RC4” isteinevonRonRivestentwickelteStrom-Chiffre(“StreamCipher”). Im Gegensatzzu Block-Chiffren konnenmit Strom-Chiffren Nach-richtenbeliebigerLangeverschlusseltwerden,so daßein Paddingnicht notwendigistunddie ursprunglicheNachrichtenlangeerhaltenbleibt. Nach[38] soll RC4zudemet-wa10-malschnellerseinalsDES.Die Implementationvon“RC4” im Proxybeschranktdie Verschlusselungwie bei demfur 3DESgewahltenAnsatzauf die vom Server zumClientenubertragenenDaten.38

Um die PerformanzauswirkungenderVerschlusselungaufzuzeigen,sindMessungenmit kur-zenTransaktionenwenig sinnvoll, da derenPerformanzstarkdurchdie Verbindungsaufbau-zeitendominiertwird. Um AuswirkungendurchVerbindungsaufbauzeitenweitestgehendaus-schließenzukonnen,wurdenMessungenmit 30SekundenlangenTransaktionendurchgefuhrt.Da derDatendurchsatzbei etwa 40 parallelenThreadseinbrach,wurdenhauptsachlichMes-sungenmit bis zu 50 Threadsdurchgefuhrt. Zwei weitereMeßpunkteliegenbei 60 und100Threads.

Die Messungen(vgl. Abbildung.24) zeigenstarke Auswirkungendieserzwei VerfahrenaufdenDatendurchsatz.Am starkstensinddieEinbußen,wie erwartet,beider3DES-Verschlusse-lung,mit derlediglicheinDurchsatzvon3,3- 3,4Mbit/s erreichtwerdenkann.AberauchderDatendurchsatzbeiRC4-Verschlusselungerreichtmit maximal44Mbit/s einenWert,derweitunterdemWertvon134Mbit/s liegt,derbeiderreinenKopierfunktionuberProxiesgemessenwurde. Uber mehrereparalleleVerbindungenkann kein hohererGesamtdatendurchsatzer-reichtwerdenalsaufeinereinzelnenVerbindung.DerGesamtdatendurchsatznimmtvielmehrleicht ab, da durchdie BearbeitungmehrererparallelerDatenstromeder Overheadauf demFirewall39 steigt.

Die BelastungdesFirewalls durchdie Verschlusselungzeigendie CPU-Lastkurven40 in Ab-bildung25. Im Gegensatzzu der reinenKopierfunktion,bei derdie CPU-Lasterstbei mehrals40parallelenVerbindungensprunghaftansteigt,benotigendieVerschlusselungsfunktionenbereitsbei einerVerbindungdie gesamteProzessorleistungdesFirewalls. DadurchsteigtdieCPU-Lastauf dem Firewall auf einenWert, der nur knappunter der Anzahl der parallelenVerbindungenliegt.41

37 Bei dendurchgefuhrten30-SekundenMessungenbetragtdie vom Server zumClientengesendeteDa-tenmengeein Vielfachesder vom Clientenan denServer gesendetenDatenmenge.Selbstbei einemDatendurchsatzvon nur 1 Mbit/s konnenin 30 Sekundenfast4 MByte Datengesendetwerden.Dage-genhabendie100Bytedes“GET-Request”vomClientenzumServervernachlassigbargeringenAnteil.

38 Die VerschlusselungsfunktionstammtebenfallsausSSH.Aus patent-undnamensrechtlichenGrunden(sieheauch[38, S.397f]) wird dasVerfahrenbeiSSHals“Arcfour” bezeichnet.

39Der Proxy wurde auf einer Bastion ausgefuhrt, also auf einem Rechnermit nur einer Netzschnittstelle(vgl. Abschnitt2.2.2).

40 Die CPU-Lastgibt die uber einenZeitraum(hier 15 Minuten) gemittelteAnzahl der ProzesseoderThreadsan,diegleichzeitigdie CPUbeanspruchen.

41 WahrendzumBeispiel100Verbindungenaktiv sind,werdenBenutzereingabenvon demFirewall nurmit sehrgroßenVerzogerungenbedient.


0

20

40

60

80

100

120

140

0 20 40 60 80 100

Dat

endu

rchs

atz

[Mbi

t/s]

ë

Anzahl der Threads

Aufsummierter Datendurchsatz über Proxy (30 Sekunden Transaktionen)(Meßwerkzeug: Socket−Größe: 64 KByte, MGproxy: Socket−Größe: 64 KByte, Kopierlänge: 64 KByte)

Kopieren 3DES RC4

Abbildung24: Datendurchsatzbei Verschlusselung

Resumee: Im GegensatzzuMessungenderPerformanzvon Proxiesmit reinerKopierfunk-tion, derenDatendurchsatzin Anbetrachtder Verbindungsaufbauzeitenund desbegrenztenTransaktionsdurchsatzesnur eine geringeBedeutunghat, erweist sich der DatendurchsatzbeimEinsatzvon VerschlusselungsverfahrenalsEngpaß.Zwar werdenbei denVerbindungs-aufbauzeitenund beim Transaktionsdurchsatzkeine besserenWerte erreicht, bei langerenTransaktionentretendieseEffektejedochaufgrunddesgeringenDatendurchsatzesin denHin-tergrund. Da eineVerschlusselungauf nur einerVerbindungdenProzessordesFirewalls be-reitsvoll auslastet,mussenparalleleVerbindungenubergeeigneteVerfahrenaufmehrereFire-wallsverteiltwerden,umakzeptableDatendurchsatzezuerzielen.DergeringeDatendurchsatzvon 3,4Mbit/s bei 3DESwurdeeineAufteilung von mindestens40 Verbindungenauf jeweilseinenFirewall erfordern,umin derSummedenDatendurchsatzeines155Mbit/s ATM-Netzeszu erzielen.AufgrundderdamitverbundenenhohenKostenerscheintderEinsatzvon 3DESzur Verschlusselungvon ubertragenenDatenfur Firewalls kaumdurchfuhrbar.42 Moglicher-weisefuhrteineHardware-Unterstutzungfur 3DESzusammenmit ParallelisierungskonzeptenzuakzeptablenLosungen.

42 DieseEinschatzunggilt nebenFirewalls auchfur andereSysteme,die gleichzeitigmit vielenClientenkommunizierenmussen(z. B. WWW-Server).

85

0

10

20

30

40

50

60

70

80

90

0 20 40 60 80 100

Sys

tem

−La

st a

uf B

astio

n

ì

Anzahl der Threads

Last auf der Bastion (30 Sekunden Transaktionen)MGproxy−Messsung mit Verschlüsselung

(Meßwerkzeug: Socket−Größe: 64 KByte, MGproxy: Socket−Größe: 64 KByte, Kopierlänge: 64 KByte)

Kopieren 3DES RC4

Abbildung25: CPU-LastaufdemFirewall durchVerschlusselung

7 Zusammenfassung

Die Studie“Nutzung von Kryptographiein Zusammenhangmit Firewalls” pladiert fur denkombiniertenEinsatzvon Schutzmechanismenderzwei wichtigstenBereichederNetzwerk-sicherheit:Firewalls und kryptographischeProtokolle mussensich erganzen,um zusammenwirksamSubnetzeundeinzelneKommunikationsbeziehungenzu schutzen.Um die Notwen-digkeit dieseskombiniertenEinsatzesbegrundenzu konnen,wurdendie MoglichkeitenundGrenzenderbeidenBereichevoneinanderunabhangigdargestellt.

In Abschnitt2 wurdendie verschiedenenFirewall-Komponenten(vgl. Abschnitt2.1)unddiedarausrealisierbarenFirewall-Architekturen(vgl. Abschnitt2.2)im Detaildargestellt.Bei derDiskussionwurdeverdeutlicht,daßFirewalls immereineZugriffskontrollezwischenNetzenmit verschiedenenSicherheitsniveausdurchfuhrenund daherals SchwellezwischenNetzeninstalliert werden. Durch die Einschrankung,daßFirewalls Zugriffskontrolle und Audit antopologischgeeigneterStellezwischenSubnetzendurchfuhrenmussen,sindnichtalleSicher-heitsproblememit einemFirewall losbar. Die offenenSicherheitsproblemewurdendaherinAbschnitt 39 genannt. Besonderswichtig ist, daßFirewalls keinenSchutzgegen Abhorenund Manipulierender ubertragenenDatenbietenund keineKontrolle desinternenVerkehrsermoglichen.

DerzweitewichtigeBereichfur dieNetzwerksicherheitist derEinsatzkryptographischerVer-fahrenundProtokolle. In Abschnitt3 wurdederNutzenderKryptographiefur die Netzwerk-sicherheitbenannt:Erstmaligist esbei der Kommunikationuberein Rechnernetzmoglich,

86 7 ZUSAMMENFASSUNG

Vertraulichkeit, IntegritatundAuthentizitatzugewahrleisten.DieseEigenschaftenwerdenmitHilfe verschiedenerAlgorithmensichergestellt,die in Abschnitt3.3 dargestelltwurden. FurdenEinsatzin KommunikationssystemenwerdendieseAlgorithmen in Form von Dienstenangeboten,die durchkryptographischeProtokolle implementiertsind.Abschnitt4 diskutierteeinigekryptographischeProtokolle innerhalbderTCP/IP-Familie. Die DarstellungorientiertesichanderSchichtenstrukturdesProtokollstapels,um zu verdeutlichen,daßdie Algorithmenauf verschiedenenProtokollebeneneingesetztwerdenkonnen,um unterschiedlicheDiensteabzusichern.Leider sind auchdie kryptographischenProtokolle nicht ausreichend,um alleSicherungsaufgabenbei der Kommunikationzu ubernehmen.In Abschnitt 141 wurde ins-besonderedaraufhingewiesen,daßProblememit der Administrationvon Netzensowie mitfehlerhafterSoftwarenicht durchkryptographischeProtokolle gelostwerdenkonnen.

Viele deroffenenProblemekonnendurchdengemeinsamenEinsatzvon Firewalls undkryp-tographischenVerfahrengelost werden. Zudemergebensich neueMoglichkeitenausdemkombiniertenEinsatz. In Abschnitt 5.1 wurde der NutzenkryptographischerVerfahrenfurFirewalls diskutiert. Insbesonderedie Moglichkeit zur starken Authentisierungund zum In-tegritatsschutzder ubertragenenDatenmit Hilfe kryptographischerVerfahrenkannfur eineerweiterteZugriffskontrolleaufdemFirewall eingesetztwerden.Die AuthentisierungamFire-wall kannsicherund transparenterfolgen. Dasgefahrliche“Hijacking” einerauthentisiertenVerbindungenwird unterbundenund erstmaligist eine feingranulierteZugriffskontrolle aufBasisvonACLsund“Credentials”gesichertmoglich.

In Abschnitt5.2 wurdederNutzenvon Firewalls fur kryptographischeVerfahrendargestellt.Firewalls werdenzum einenals Erganzungzu kryptographischenVerfahreneingesetzt,umdie Auswirkungenvon Administrations-und Softwarefehlernzu minimieren. Zum anderenkannein Firewall eingesetztwerden,um VerschlusselungsrichtliniendurchzusetzenoderalsVerschlusselungs-Gateway ein einheitlichekryptographischeSchnittstellezu einemSubnetzanzubieten.

Leiderist derkombinierteEinsatzvon kryptographischenVerfahrenundFirewalls nicht ohneProblememoglich. In Abschnitt6.1 wurdendie technischenAspektedeskombiniertenEin-satzesbeschrieben.DasErgebnisist eineZusammenfassung,unterwelchenUmstandensichdie eingesetztenVerfahrengegenseitigbehindern. Ein weiteresschwerwiegendesProblembeimEinsatzdieserSchutzmechanismenin Hochgeschwindigkeitsnetzenist dieschlechtePer-formanz,die mit heutigenImplementierungender Verfahrenerreichtwird. Eine Leistungs-abschatzungfur denVerschlusselungsaufwandaufeinemFirewall in Abschnitt6.2belegt, daßhier nocherheblicheWeiterentwicklungenfur die Durchsatzsteigerungerforderlichsind,da-mit nichtaufgrundschlechterPerformanzaufSicherheitverzichtetwerdenmuß.

In Zukunft gibt esmehrereSchwerpunkte,die nochgenaueruntersuchtwerdenmussen.Esmuß vertieft analysiertwerden,welcheneuenMoglichkeiten sich durch den kombiniertenEinsatzvon Firewalls und kryptographischenVerfahrenergeben. Die in Abschnitt 5.1 undAbschnitt5.2 dargestelltenAspektebildendie Grundlagefur die ErforschungneuerAnwen-dungen,die dasvolle PotentialdieserwichtigenSchutztechniken fur die Netzwerksicherheitnutzenkonnen.

87

Ein weiteresBetatigungsfeldsind neueProtokolle, die kryptographischeMechanismenein-setzen.Die Darstellungin Abschnitt4 hat verdeutlicht,daßdie von der IETF entwickeltenProtokolle einigeSchwachenaufweisen.Insbesonderedie problematischeEinbettungeinigerProtokolle (namentlichIPsecundTLS) in vorhandeneProtokollstapelmußuberdachtwerden,um vernunftige Alternativen aufzuzeigen.Zur Zeit befindensich viele der in Abschnitt3.4dargestelltenProtokolle nochin derEntwicklung. Esbleibt zu hoffen, daßzumindesteinigederbenanntenMangelvor einerStandardisierungbehohenwerden.

Als dritter Schwerpunktist in Zukunft die Fragezu stellen,wie der BenutzerangesichtsderneuenSicherungsmechanismen,die auf denverschiedenenEbenendesKommunikationssy-stemsangesiedeltsind,beiderAuswahlunterstutztwerdenkann.Nicht jederMechanismusistfur jedeKommunikationsanforderungsinnvoll. Gleichzeitigsinddie WechselwirkungenvonindividuellenSchutzmechanismen,die einzelneBenutzerwahlen,mit denglobalenSchutz-mechanismen,die beispielsweiseaneinemFirewall durchgesetztwerden,nochunzureichenderforscht.Hier wird esin Zukunft einigeProblemegeben,dadie hochspezialisiertenMecha-nismenaufgrundvon individuellenRichtlinieneingesetztwerdenundsomitdasVerhaltendereinzelnenSchutzmechanismenschlechtstandardisierbarist. Beispielsweiseist dasVerhalteneinesProxies(vgl. Abbildung 2, S. 13) im Fall einerZugriffsverweigerungnicht standardi-siert. Ein Proxy konnteeinfachdie Kommunikationunterdrucken oderzusatzlich eineFeh-lermeldungan denBenutzerzuruckgeben,je nachdemwelchesVerhaltender AdministratordesFirewalls fur diesenFall konfiguriert hat. Die Struktur dieserFehlermeldungist nichtstandardisiert.Ein Benutzerkannsich dahernicht auf ein bestimmtesVerhaltender Proxiesverlassen,umautomatischaufeineVerweigerungdesZugriffs reagierenzukonnen.Dasnicht-standardisierteVerhaltenverschiedenerSicherungsmechanismenwird auchdie Fehlersuchebei Kommunikationsstorungendeutlicherschweren.

Abschließendist festzustellen,daßdieVorteilefur dieNetzwerksicherheit,diesichauseinemkombiniertenEinsatzkryptographischerVerfahrenmit Firewallsergeben,diebishererkanntenNachteilebei weitemuberwiegen.DasInternetbrauchtfur eineweitereEntfaltung,insbeson-dereim kommerziellenBereich,sowohl die Absicherungder lokalenNetzedurchFirewallsalsauchdenSchutzindividuellerKommunikationsbeziehungendurchkryptographischeVer-fahren.

88 ABKURZUNGSVERZEICHNIS

Abkurzungsverzeichnis

ACL AccessControlListAH AuthenticationHeaderANSI AmericanNationalStandardInstituteAP AuthenticationProtocolASCII AmericanStandardCodefor InformationInterchangeATM AsynchronousTransferModeBSD Berkeley SoftwareDistributionCA CertificationAuthorityCBC CipherBlock ChainingCERT ComputerEmergency ResponseTeamCP ConnectionProtocolCPU CentralProcessingUnitDAP DatabaseAccessProtocolDEA DataEncryptionAlgorithmDES DataEncryptionStandardDFN DeutschesForschungsNetzDMZ DemilitarizedZoneDNS DomainNameSystemDSA DirectoryServiceAgentDSS Digital SignatureStandardDUA DirectoryUserAgentESP IP EncapsulatingSecurityPayloadFIPS FederalInformationProcessingStandardsFTP File TransferProtocolFWL Firewall-LaborHMAC HashedMessageAuthenticationCodeHSN High SpeedNetworkHTML Hypertext MarkupLanguageHTTP Hypertext TransferProtocolICMP InternetControlMessageProtocolICV Integrity CheckValueIDEA InternationalDataEncryptionAlgorithmIEEE Instituteof ElectricalandElectronicsEngineersIETF InternetEngineeringTaskForceIKE InternetKey ExchangeIP InternetProtocolIPSEC IP Security(WorkingGroup)IS Internet-ServerISAKMP InternetSecurityAssociationKey ManagementProtocolISO InternationalStandardsOrganisationITU IntenationalTelecommunicationUnionKDC Key DistributionCenter

ABKURZUNGSVERZEICHNIS 89

LAN LocalAreaNetworkLDAP LightweightDatabaseAccessProtocolMAC MessageAuthenticationCodeMD MessageDigestMSS MaximumSegmentSizeMTU MaximumTransferUnitNAT Network AddressTranslationNIST NationalInstituteof StandardsandTechnologyNNTP Net NewsTransportProtocolOSI OpenSystemInterconnectionPGP PrettyGoodPrivacyPKI PublicKey InfrastructurePKIX PublicKey Infrastructure(X.509)PS PrimaryServerRFC Requestfor CommentsRPC RemoteProcedureCallRR ResourceRecordRSA Rivest,Shamir, AdlemanSAD SecurityAssociationDatabaseSDL SpecificationandDescriptionLanguageSecDNS SecureDomainNameSystemSHA SecureHashAlgorithmSIG-RR SignatureResourceRecordSKIP SimpleKey-Managementfor InternetProtocolsSMTP SimpleMail TransportProtocolSPI SecurityParameterIndexSPKI SimplePublicKey InfrastructureSSH SecureShellTCP TransmissionControlProtocolTHP TLS HandshakeProtocolTLP TransportLayerProtocolTLS TransportLayerSecurityTRP TLS RecordProtocolUDP UserDatagramProtocolVLAN Virtual LANVPN Virtual PrivateNetworkWWW World WideWeb


Literatur

[1] ANSI X3.92 1981: “American National Standardfor Data Encryption Algorithm(DEA)”, American National StandardsInstitute

[2] ANSI X3.1061983:“AmericanNationalStandardfor InformationSystems—DataEn-cryptionAlgorithm— Modesof Operation”,American National StandardsInstitute

[3] Atkinson,R.1995:“IP AuthenticationHeader”,Network WorkingGroup,RequestforComments: 1826

[4] Atkinson, R. 1995: “IP EncapsulatingSecurityPayload”, Network Working Group,Requestfor Comments:1827

[5] Aziz, A. & Patteson,M. 1995: “Simple Key Managementfor Internet Protocols(SKIP)”, in Proceedings:INET’95, The Inter net: Towards Global Inf ormation In-frastructur e, Holululu, Hawaii, Jun27–30,1995

[6] Aziz, A. & Markson, T. & Prafullchandra, H. 1996: “Simple Key-Management for Internet Protocols (SKIP)”, Technical Document:http://www.skip.org/spec/SKIP.html

[7] Bellovin, S.M. & Merritt, M. 1992: “EncryptedKey Exchange:Password-BasedPro-tocolsSecureAgainstDictionaryAttacks”, in Proceedings:IEEE Computer SocietyConferenceon Research in Security and Privacy, 1992,pp.72–84

[8] Blaze,M. et al. 1996: “Minimal Key Lengthsfor SymmetricCiphersto Provide Ade-quateCommercialSecurity”,Januar1996(ftp://ftp.cert.dfn.de/pub/docs/cryp t/keyl ength .ps.gz )

[9] Boe,M. 1997: “TLS-basedTelnetSecurity”, InternetEngineeringTaskForce,draft-ietf-telnet-tls-00.txt

[10] Dierks,T. & Allen, C.1997:“The TLS ProtocolVersion1.0”, TransportLayerSecurityWorkingGroup,draft-ietf-tls-pr otocol-05.txt

[11] Eastlake, 3rd,D. & Kaufman,C. 1997: “Domain NameSystemSecurityExtensions”,Network WorkingGroup,Requestfor Comments:2065

[12] Ellermann,U. 1993: “Ein Firewall am FachbereichInformatik”, Universitat Ham-burg, Dezember1993.

[13] Ellermann,U. 1995: “NetzabsicherungdurchFirewalls”, 4. IT-Sicherheitskongreß,8. bis 11.Mai 1995,Bonn, Mai 1995.(http://www.cert.dfn.de/team/ue/fw/f ire/ )

[14] Ellermann,U. 1996: “IPv6 andFirewalls”, Proceedingsof SECURICOM — 14thInter national Congresson Computer and Communications Security Protection,Paris, Juni1996(http://www.fwl.dfn.de/eng/˜ue/fw /ipv6 fw/ )

ABKURZUNGSVERZEICHNIS 91

[15] Ellermann,U. & Benecke,C.1998:“Firewallsfur Hochgeschwindigkeitsnetze”,Deut-scherInter net Kongress1998,5. und 6. Mai 1998,CongressCenterMesseFrank-furt , Mai 1998.(http://www.fwl.dfn.de/team/ue/fw/f ire-h sn/ )

[16] Ferguson,P. & Senie,D. 1998: “Network IngressFiltering: DefeatingDenialof Ser-vice Attackswhich employ IP SourceAddressSpoofing”,Network Working Group,Requestfor Comments:2267

[17] Fielding,R. et al. 1997:“Hypertext TransferProtocol– HTTP/1.1”,Network WorkingGroup,Requestfor Comments:2068

[18] Harkins,D. & Carrel,D. 1998: “The InternetKey Exchange(IKE)”, IPSECWorkingGroup,draft-ietf-ipsec-isakmp-oakley-08.txt

[19] ITU-T RecommendationX.5001993:“InformationTechnologie– OpenSystemInter-connection– TheDirectory:Overview of Concepts,Models,andServices”

[20] ITU-T RecommendationX.5091997:“InformationTechnologie– OpenSystemInter-connection– TheDirectory:AuthenticationFramework”

[21] Kantor, B. 1991: “BSD Rlogin”, Network Working Group,Requestfor Comments:1282

[22] Kelm, S. & Kossakowski, K.-P. 1998: “Die Rolle von Public-Key-Infrastrukturen”,Deutscher Inter net Kongress1998, 5. und 6. Mai 1998, CongressCenterMesseFrankfurt , Mai 1998.

[23] Kent,S.1993:“Privacy Enhancementfor InternetElectronicMail: Part II: Certificate-BasedKey Management”,Network WorkingGroup,Requestfor Comments: 1422

[24] Kent,S. & Atkinson,R. 1998: “SecurityArchitecturefor the InternetProtocol”,Net-work WorkingGroup,draft-ietf-ipsec-arch-sec-05.txt

[25] Kent,S. & Atkinson,R. 1998: “IP AuthenticationHeader”,Network Working Group,draft-ietf-ipsec-auth-header-06.txt

[26] Kent,S.& Atkinson,R.1998:“IP EncapsulatingSecurityPayload”,Network WorkingGroup,draft-ietf-ipsec-esp-v2-05.txt

[27] Kohl, J. & Neuman,C. 1993: “The KerberosNetwork AuthenticationService(V5)”,Network WorkingGroup,Requestfor Comments:1510

[28] Kossakowski, K.-P. 1998: “Virtuelle Private Netzwerke: Einsatzmoglichkeiten undTechniken”, 5. DFN-CERT Workshop 1998“Sicherheit in vernetzten Systemen”,4. und 5. Marz 1998,Hamburg, in: DFN-Bericht Nr. 85, Mai 1998.

[29] Maughan,D. etal 1998:“InternetSecurityAssociationandKey ManagementProtocol(ISAKMP)”, IPSECWorkingGroup,draft-ietf-ipsec-isakmp-09.txt


[30] Maurer, U. M. 1995: “Kryptologie: eineneuartigeAnwendungder Mathematik” inElementeder Mathematik , Birkhauser, Vol. 50,Nr. 3, S.89–106

[31] National Institute of Standardsand Technology(NIST) 1995: “Federal InformationProcessingStandards180-1.SecureHashStandard”(FIPS180-1)

[32] National Institute of Standardsand Technology(NIST) 1994: “Federal InformationProcessingStandards186.Digital SignatureStandard”(FIPS186)

[33] Newman,C. 1998: “Using TLS with IMAP4, POP3andACAP”, Network WorkingGroup,draft-newman-tls-imappop-04.txt

[34] Preneel,B. 1997: “Hash FunctionsandMAC Algorithms Basedon Block Ciphers”in Darnell,M. (Ed.) Proceedings:Cryptography and Coding, Cirencester, UK, Dec.1997

[35] Rescorla,E. & Schiffman,A. 1998:“The SecureHyperText TransferProtocol”,draft-ietf-wts-shttp-06.txt

[36] Rivest,R. & Shamir, A. & Adleman,L. M. 1978: “A Methodfor OptainingDigitalSignaturesandPublic-Key Cryptosystems”,Communications of the ACM , Vol. 21,No. 2, pp.120–126,1978

[37] Rivest,R. 1992: “The MD5 Message-DigestAlgorithm”, Network Working Group,Requestfor Comments:1321

[38] Schneier, B. 1996: “Applied Cryptographie.Protocols,Algorithms,andSourceCodein C”, 2ndEdition,JohnWiley & Sons

[39] Thayer, R. & Doraswamy, N. & Glenn,R. 1997: “IP SecurityDocumentRoadmap”,Network WorkingGroup,draft-ietf-ipsec-doc-roadmap-02.txt

[40] Touch,J.1995:“ReportonMD5 Performance”,Network WorkingGroup,RequestforComments: 1810

[41] Tsutsumi,T. & Yamaguchi,S. 1995: “SecureTCP— providing securityfunctionsinTCPlayer”, in Proceedings:INET’95 , 27–30June1995,Honolulu,Hawaii, USA

[42] Yeong,W. et al. 1995: “Lightweight Directory AccessProtocol”, Network WorkingGroup,Requestfor Comments: 1777

Nutzung von Kryptographie in Zusammenhang mit Firewalls...Firewall-Test-Labor fur¨...

Documents

Transcript of Nutzung von Kryptographie in Zusammenhang mit Firewalls...Firewall-Test-Labor fur¨...