b. Datentransport und Datenverschlüsselung (Datensicherheit)

Auch das IP-Security-Protokoll (IPSec) sowie L2Sec

¹⁶²

sind als

standardisierte

¹⁶³

(Sicherheits-) Tunneling-Protokolle anerkannt. Ergänzend ist anzumerken, dass es sich bei IPSec nicht nur um einen einzigen Standard handelt, sondern die einzelnen Bestandteile von IPSec sind auf ein ganzes Bündel unterschiedlich kombinierbarer Standards bzw. RFCs (Request for Comments) verteilt.

¹⁶⁴

Es gibt im Rahmen eines VPN noch ein weiteres Sicherheitsprotokoll, welches ebenfalls die Datenverschlüsselung ermöglicht, das Point-to-Point-Tunneling-Protokoll (PPTP). Dieses Point-to-Point-Tunneling-Protokoll ist jedoch seitens der IETF

¹⁶⁵

nicht als standardisiertes Protokoll anerkannt und weist auch nicht die Stärke von IPSec auf, insbesondere war die Ableitung des Schlüssels, mit dem die Daten

verschlüsselt werden, aus der Benutzerauthentifizierung in der Vergangenheit Zielscheibe von erfolgreichen Angriffen.

¹⁶⁶

IPSec und L2Sec werden momentan als die besten Sicherheitsstandards eingestuft.

¹⁶⁷

Zu beachten ist aber, dass es eine absolute Sicherheit im Sinne einer mathematischen Unmöglichkeit der

162 Siehe das Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 208/209, wo L2Sec zum einen als standardisiertes Protokoll und zum anderen als Alternative zu IPSec eingestuft wird sowie zu IPSec aaO S. 211 ff. IPSec arbeitet zusätzlich auf der Netzwerkebene (Schicht 3 des OSI-Schichtenmodells), siehe Buckbesch/Köhler, Virtuelle Private Netze, S. 55 ff. Siehe zu L2Sec auch Böhmer, Virtual Private Networks (2. Auflage), S. 226.

163 Zum Begriff des „Standards“ siehe S. 35 Fn. 145. Zu IPSec siehe Lipp, VPN, S. 178. Siehe auch Böhmer (in der 1. Auflage) Virtual Private Networks, S. 229, der darstellt, dass im Laufe der Zeit mehrere ähnliche Tunneling-Protokolle entwickelt worden sind, von denen sich in der Praxis jedoch hauptsächlich IPSec und L2TP (neben PPTP als nicht standardisiertem Protokoll) durchgesetzt haben. Campo/Pohlmann, Virtual Private Networks, S. 151 verweisen darauf, dass mit dem Protokoll IPSec ein in die Zukunft weisender Standard geschaffen worden ist.

164 Siehe hierzu Buckbesch/Köhler, Virtuelle Private Netze, S. 55. Siehe zum Begriff RFC S. 28 Fn. 100.

165 Zum Begriff der IETF siehe S. 28 Fn. 100.

166 Lipp, VPN, S. 180. Der geringe Verschlüsselungsschutz bei PPTP wird als „fahrlässig“

bezeichnet (Böhmer, Virtual Private Networks (2. Auflage), S. 212, der den Begriff „fahrlässig“

jedoch nicht im formal juristischen Sinne verwendet), da ein breites Spektrum von Angriffen denkbar ist (vgl. Campo/Pohlmann, Virtual Private Networks, S. 161).

167 Siehe Böhmer, Virtual Private Networks (2. Auflage), S. 229 mit dem Hinweis, dass zwar darauf verwiesen wird, dass es derzeit keine Alternative zu IPSec gebe (und es besser sei als PPTP und L2TP), aber dass dieses Protokoll dennoch nicht ganz kritiklos gesehen werde.

Siehe ebenso die Ausführungen in der Computerwoche vom 21.01.2006

(http://whitepaper.computerwoche.de/index.cfm?pid=1&fk=61&pk=466) mit dem Hinweis, dass sich seit geraumer Zeit Zeitschriftenbeiträge über IPSec häufen. In diesen Artikeln sei immer wieder die Rede davon, dass IPSec der höchste Sicherheits-Standard und das für jede Netzwerk-Topologie uneingeschränkt einsetzbare VPN-Protokoll sei. Die Autoren möchten in ihrem Beitrag jedoch zeigen, dass IPSec nur in ganz bestimmten Umgebungen ohne

zusätzliche Erweiterungen eingesetzt werden kann.

Entschlüsselung naturgemäß niemals geben kann.

¹⁶⁸

Da IPSec und L2Sec im Gegensatz zu PPTP nicht nur als standardisierte bzw. anerkannte Tunneling-Protokolle bezeichnet sowie als besserer Sicherheitsstandard eingestuft werden,

¹⁶⁹

sondern auch in den aktuellen Produktbeschreibungen

kommerzieller Anbieter als Tunneling-Protokoll im VPN angeboten werden,

¹⁷⁰

wird PPTP hier bei der Darstellung außer Acht gelassen.

IPSec und L2Sec ermöglichen im Gegensatz zu L2TP zusätzlich die Sicherheit bzw. Verschlüsselung der Daten. Bei einem Tunneling-Protokoll wie L2TP wäre es weiterhin notwendig, dass der Kunde zusätzlich seine Daten

verschlüsselt.

¹⁷¹

IPSec ist jedoch lediglich in der Lage ist, das Netzwerkprotokoll IP

weiterzuleiten bzw. einzukapseln und kann gerade nicht bewerkstelligen kann, dass Netzwerke, die nicht auf IP basieren, dennoch über das Internet

miteinander kommunizieren können. Demnach können nur

Unternehmensnetzwerke, die mit dem Netzwerkprotokoll IP arbeiten, IPSec einsetzen.

¹⁷²

Diese „Schwächen“ sollen durch den Einsatz von L2Sec ausgeglichen werden. L2Sec ermöglicht neben IP-Paketen ebenso Daten anderer Netzwerkprotokolle, etwa NetBIOS-, IPX- oder SNA-Daten zu

übertragen. also Daten von Netzwerken, die andere Protokolle als IP nutzen.

¹⁷³

L2Sec sowie IPSec beinhalten beide die Möglichkeit der Datenverschlüsselung und ein Schlüsselmanagement,

¹⁷⁴

wobei Schlüsselmanagement bedeutet, dass ein Verfahren sämtliche benötigten Schlüssel zur Verschlüsselung erzeugen, auf Integrität und Authentizität prüfen und dafür Sorge tragen kann, dass diese

168 Hanau/Hoeren/Andres, Private Internetnutzung durch Arbeitnehmer, S. 18.

169 Vgl. Lipp, VPN, S. 176/178; Buckbesch/Köhler, Virtuelle Private Netze, S. 119/121.

170 Siehe etwa das Angebot von T-Online „SecureVPN-Benutzerhandbuch“ und das Angebot von T-Online, abrufbar unter

ftp://software.t-online.de/pub/service/pdf/directVPN_Benutzerhandbuch.pdf sowie die Angebote von Cable &

Wireless Telecommunication Services GmbH abrufbar unter

http://www.cw.com/docs/services/product_pdfs/internet_vpn.pdf, Claranet GmbH abrufbar unter http://www.claranet.de./ipservices/vpn/vpn_ipsec.php und COLT TELECOM GmbH abrufbar unter http://www.colt.net/de/ge/produkte/data_/colt_ip_vpn_corporate (sämtliche Websites vom30.09.2006).

171 Siehe zu L2TP S. 35 ff. sowie Lipp, VPN, S. 178/303/304.

172 Vgl. Buckbesch/Köhler, Virtuelle Private Netze, S. 75.

173 Siehe das Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 208.

174 Vgl. Lipp, VPN, S. 184 und das Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 208/209.

Schlüssel in einem VPN zur richtigen Gegenstelle, also dem richtigen Netzwerk, übertragen werden.

¹⁷⁵

Verschlüsselungsverfahren sind entweder asymmetrisch oder symmetrisch.

Asymmetrisch bedeutet, dass zwei jeweils unterschiedliche Schlüssel existieren, und zwar ein privater und ein öffentlicher Schlüssel.

¹⁷⁶

Der private Schlüssel ist geheim und nur demjenigen bekannt, der eine

Nachricht zu verschlüsseln hat. Der öffentliche Schlüssel hingegen ist allgemein bekannt und nimmt die Entschlüsselung der Nachricht vor.

¹⁷⁷

Hierfür wird der Begriff „Public-Key-Kryptographie“ benutzt.

¹⁷⁸

Das bekannteste Public-Key-Verfahren ist das so genannte RSA-Public-Key-Verfahren.

¹⁷⁹

Symmetrische

Verschlüsselungsverfahren verwenden für die Verschlüsselung von Daten den gleichen Schlüssel.

¹⁸⁰

Dies bedeutet, dass den Kommunikationspartnern dieser Schlüssel jeweils vorliegen muss.

¹⁸¹

VPN mittels IPSec nutzen die hybride Verschlüsselungstechnik, d.h. dass symmetrische und asymmetrische Verschlüsselungsverfahren kombiniert werden.

¹⁸²

So wird der mittels des symmetrischen Verschlüsselungsverfahren generierte Schlüssel selbst durch einen Algorithmus bzw. durch ein

asymmetrischen Verfahren verschlüsselt und über das Internet zum Kommunikationspartner übertragen wird.

¹⁸³

175 Vgl. Lipp, VPN, S. 54; Lienemann, Virtuelle Private Netzwerke, S. 81. Siehe zu den Begriffen

„Authentizität“ und „Integrität“ auch Jacob, DuD 2000, 5, 10.

176 Siehe hierzu auch die Definition im Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 253.

177 Siehe hierzu auch Schaar, Datenschutz im Internet, Rn. 163.

178 Die Grundpfeiler der Public-Key-Kryptographie sind ungelöste oder schwierige

mathematische Probleme. Besonders geeignet sind mathematische Funktionen, die sich in eine Richtung sehr einfach und schnell berechnen lassen, deren Umkehrung hingegen sehr

schwierig und langwierig ist (Lipp, VPN, S. 131).

179 Das RSA-Verfahren ist benannt nach seinen drei Entdeckern, Ronald Rivest, Adi Shamir und Leonard Adleman (Campo/Pohlmann, Virtual Private Networks, S. 69). So sind bei dem RSA-Verfahren gewisse Teile der Schlüssel bekannt, so dass aufgrund dieser bekannten Elemente der jeweils geheime Teil des anderen Schlüssels berechnet wird (Lipp, VPN, S. 136 ff.).

180 Campo/Pohlmann, Virtual Private Networks, S. 67; Lipp, VPN, S. 191; siehe auch die Definition im Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 265. Symmetrische Verschlüsselungsverfahren ist beispielsweise der DES-Algorithmus (Data Encryption Standard) bzw. Triple-DES-Algorithmus (Campo/Pohlmann, Virtual Private Networks, S. 68).

181 Mit dem so genannten Diffie-Hellman-Verfahren ist es möglich, den Schlüssel (d.h. den symmetrischen Schlüssel) auf beiden Seiten zu erzeugen (Lipp, VPN, S. 225). Dieses Verfahren ist ebenfalls nach seinen Entdeckern benannt: Whitfield Diffie und Martin Hellman (vgl. Lipp, VPN, S. 130).

182 Campo/Pohlmann, Virtual Private Networks, S. 71/82/150.

183 Campo/Pohlmann, Virtual Private Networks, S. 150; Lipp, VPN S. 131.

Dieser Schlüsselaustausch findet bei IPSec regelmäßig aufgrund des Schlüsselaustauschprotokolls IKE (Internet Key Exchange) oberhalb der Sitzungsschicht

¹⁸⁴

(Schicht 5 des OSi-Schichtenmodells) statt.

¹⁸⁵

IKE ist ein Bestandteil des aus mehreren Standards bestehenden IPSec-Protokolls.

¹⁸⁶

Ein Schlüssel ist im Übrigen nichts anderes als eine Regel, nach der die Verschlüsselung der Nachricht erfolgt. Es wird mittels eines Algorithmus eine geheime Zahl erzeugt, die in unterschiedlicher Länge auftreten kann und quasi eine Zusatzinformation zu dem Nachrichtentext darstellt.

Das Entscheidende bei IPSec sowie L2Sec ist außerdem, dass die Möglichkeit besteht, die IP-Pakete des privaten Netzwerkes durch Einfügung eines neuen IP-Headers vollständig in andere IP-Pakete einzukapseln. Header ist der Kopf des Datenpakets, der die Absende- und die Zieladresse enthält.

¹⁸⁷

Die Folge ist, dass die Informationen des Originalpaketes für Dritte nicht sichtbar sind, also weder die übersandten Daten noch die privaten bzw.

originalen Netzwerkadressen des Absenders, da diese vollständig verschlüsselt sind.

¹⁸⁸

Die einzig sichtbare Information bezieht sich lediglich auf die

Gesamtmenge an Paketen, die versendet worden sind.

¹⁸⁹

184 Vgl. zum OSI-Schichtenmodell S. 22 ff.

185 Siehe hierzu das Schaubild bei Böhmer (in der 1. Auflage) Virtual Private Networks, S. 216 sowie die weiteren Ausführungen auf S.250. Lipp, VPN, S. 94/200 bezeichnet IKE ebenso als Sicherheitsprotokoll. Campo/Pohlmann, Virtual Private Networks, S. 166 verweisen darauf, dass IPSec mit einer Reihe von Algorithmen zum Schlüsselaustausch zusammenarbeitet, wobei das am weitesten verbreitete Verfahren IKE ist. Vgl. zu IKE und IPSEC außerdem Buckbesch/Köhler, Virtuelle Private Netze, S. 68; Böhmer, Virtual Private Networks (2. Auflage), S. 248. Siehe hierzu außerdem das Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S.

222, wo mittels Bilddarstellung dieses Verfahren erklärt wird. Vgl. ebenso die Definition im Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 258, wo darauf verwiesen wird, dass IKE als Bestandteil von IPSec für ein sicheres Schlüsselmanagement verantwortlich ist.

186 Vgl. S. 39 und die dort zitierten Ausführungen von Buckbesch/Köhler, Virtuelle Private Netze, S. 55 unter Bezug darauf, dass IPSec aus mehreren Standards besteht.

187 Siehe zu diesem Begriff Schneider, MMR 1999, 571, 571; Pankoke, Von der Presse- zur Providerhaftung, S. 41, der den Header als Briefumschlag mit Absender- und

Empfängeradresse bezeichnet.

188 Siehe Lipp, VPN, S. 203, der darstellt, dass Dritte dadurch keine Informationen über die originalen Adressen erhalten, so dass Angriffe auf das Unternehmensnetzwerk erschwert werden (siehe hierzu auch Lipp, VPN, S. 53/54 mit dem Hinweis, dass Datenvertraulichkeit ebenso erfordert, dass das interne Netzwerk mit seinen Verkehrsbeziehungen, etwa Quell- und Zieladressen, nicht ausgespäht werden kann; vgl. außerdem Campo/Pohlmann, Virtual Private Networks, S. 153 mit dem Hinweis, dass die echten IP-Adressen einem Angreifer verborgen bleiben).

189 Siehe Böhmer (in der 1. Auflage) Virtual Private Networks, S. 262 mit dem Hinweis, dass IPSec lediglich im Gateway implementiert sein muss und nicht in den lokalen Netzen, so dass ein Angreifer nur die Möglichkeit hat, die Anfangs- und Endpunkte des IPSec-Tunnels

festzustellen. Vgl. auch Lipp, VPN, S. 190 mit dem Hinweis, dass ein „Angreifer“ als einzige

Diese Möglichkeit besteht allerdings nur im so genannten Tunnelmodus von

Im Dokument Neue Online-Dienste und Datenschutz am Beispiel von Virtuellen Privaten Netzwerken (Seite 76-80)