HOCHSCHULE FÜR ANGEWANDTE WISSENSCHAFTEN LANDSHUT FAKULTÄT ELEKTROTECHNIK UND WIRTSCHAFTSINGENIEURSWESEN

Größe: px
Ab Seite anzeigen:

Download "HOCHSCHULE FÜR ANGEWANDTE WISSENSCHAFTEN LANDSHUT FAKULTÄT ELEKTROTECHNIK UND WIRTSCHAFTSINGENIEURSWESEN"

Transkript

1 HOCHSCHULE FÜR ANGEWANDTE WISSENSCHAFTEN LANDSHUT FAKULTÄT ELEKTROTECHNIK UND WIRTSCHAFTSINGENIEURSWESEN Implementierung von TLS in das POP3-Protokoll unter Unix B a c h e l o r a r b e i t vorgelegt von Alexander Ausserstorfer Eingereicht: 16. August 2013 Betreuer: Prof. Dr. rer. nat. Tippmann-Krayer

2 I. Inhaltsverzeichnis I. Inhaltsverzeichnis Übersicht über die vorliegende Bachelor-Arbeit Zielsetzung der Arbeit Struktur dieser Arbeit Grundlagen Symmetrische und asymmetrische Verschlüsselungen Das Schlüsselverteilungsproblem Das Diffie-Hellmann-Verfahren (DHE) Der Algorithmus von Ron Rivest, Adi Shamir und Len Adelman (RSA) Verschlüsselung Entschlüsselung The-man-in-the-middle-attack Digitale Signaturen Hash-Funktion Digitale Zertifikate Streng hierarchische Public-Key-Infrastruktur Web of Trust Realisierung Die verwendeten Werkzeuge Gnu Compiler Collection (GCC) Cygwin Domainnamen in IP-Adressen konvertieren Verbindungsaufbau und Datenaustausch mit dem Server Das Post Office Protocol (POP) Einbinden von GnuTLS POP3S und STARTTLS Aufbau, Nutzung und Beendigung der verschlüsselten Verbindung Authentifizierung des POP-Servers durch digitale Zertifikate Authentifizierung des Clients mittels Secure Remote Password (SRP) Einrichten der TLS-Sitzung (Client und Server) Aushandlung der erlaubten cipher suites und Protokolle handshake durchführen Datentransfer Verschlüsselte Verbindung sicher beenden Durchführung einer TLS-Sitzung Fazit und Ausblick Seite 2 -

3 Anhang A Beispielprogramm in C Anhang B Verwendete Abkürzungen und Begriffe Anhang C Häufig verwendete Unix-Befehle Anhang D Abbildungsverzeichnis Anhang E Quellenverzeichnis Anhang F Verwendete Formelzeichen Seite 3 -

4 1. Übersicht über die vorliegende Bachelor-Arbeit 1.1 Zielsetzung der Arbeit Das Ziel der vorliegenden Bachelor-Arbeit ist die Untersuchung und Realisierung einer verschlüsselten Verbindung zwischen einem Endgerät und einem POP3 1 -Server 2 über ein auf den IP 3 /TCP 4 -Protokollen basierendes Netzwerk (Internet). Bei dem Endgerät handelt es sich in vorliegender Arbeit ausschießlich um den Computer des Anwenders, der seine s aus dem elektronischen Postfach abrufen möchte. Das Endgerät wird im englischen Sprachgebrauch auch client genannt. Der POP3-Server ist jener Dienst, der das elektronische Postfach rund um die Uhr bereitstellt. Dieser Dienst läuft in der Regel auf einem anderen Rechner. 5 Der POP3-Server nimmt an eine bestimmte -Adresse geschickte s entgegen, speichert diese im elektronischen Postfach ab und reicht sie auf Anfrage des Postfach-Besitzers an diesen weiter. Die s werden auf diese Weise hinterlegt, damit der Empfänger einer nicht rund um die Uhr mit dem Internet verbunden sein muss. Ein POP3-Server beherbergt in der Regel viele verschiedene elektronische Postfächer, die alle verschiedenen Besitzern gehören. Um Zugriff auf ein -Konto zu haben, muss sich der Besitzer eines elektronischen Postfaches daher dem POP3-Server gegenüber mit Benutzername und Passwort ausweisen (beide im folgenden auch unter dem Begriff Steuerbefehle zusammengefasst). Benutzername und Passwort sind die Schlüssel für sein elektronisches Postfach. Ohne weitere Maßnahmen werden beim POP3-Protokoll diese Daten jedoch in Klartext an den POP3-Server gesendet, was ein großes Sicherheitsdefizit darstellt. In diesem Fall braucht ein Angreifer nur den Datenverkehr zwischen den beiden Rechnern mitzuschneiden und zu sichten, um an die Schlüssel heranzukommen. Damit genau das nicht passiert, wird in vorliegender Arbeit der komplette Datenverkehr zwischen dem rechtmäßigen Empfänger der E- Mails sowie dem POP3-Server verschlüsselt. Man muss an dieser Stelle grundsätzlich unterscheiden, ob der komplette Datenverkehr einschließlich aller Steuerbefehle zwischen zwei direkt miteinander verbundenen Kommunikationspartnern (2-Punkt-Verbindung) verschlüsselt wird oder nur die zu übertragenden Nutzdaten (oder auch nur bestimmte Teile davon) verschlüsselt werden. Fall 1: Die Rechner A und B kommunizieren direkt miteinander. Wird der Datenverkehr zwischen den zwei Rechnern A und B verschlüsselt, werden sämtliche Daten einschließlich aller Steuerbefehle vom Rechner A verschlüsselt abgesendet und kommen auch verschlüsselt am Rechner B an. Dieser entschlüsselt die Daten sofort wieder, womit diese im Klartext auf dem Rechner B vorliegen und spätestens ab hier nicht mehr verschlüsselt sind. Wer immer Zugriff zum Dienst (Server) auf Rechner B hat, kann damit die empfangenen Daten im Klartext 1 POP: engl. Post Office Protocol, elektronischer Postdienst im Internet 2 Server: engl. server, dt. Diener. Prozess bzw. Computer im Internet, welcher einen Dienst (z. B. s, Webseiten) zur Verfügung stellt. 3 IP: engl. Internet Protocol 4 TCP: engl. Transmission Control Protocol 5 Auf dem gleichen Rechner können gleichzeitig mehrere verschiedene Dienste (Server) laufen. - Seite 4 -

5 lesen. Werden die Daten vom Rechner B an einen Dritten C weitergegeben, so geschieht dies im Klartext oder durch eine neue Verschlüsselung. Fall 1 wird in der vorliegenden Arbeit mit verschlüsselter Verbindung bezeichnet. s werden für gewöhnlich vom Sender bis zum Empfänger über eine ganze Kette von Mailservern geschoben (Abb. 1.1). Grund hierfür ist die dezentrale Organisation und damit die Verfügbarkeit vieler usw.). Bis hingehend zum Postfach (POP3-Server) des Empfängers kann im Fall 1 die daher in Klartext bzw. ASCII-codiert übertragen und damit problemlos von einem Dritten mitgehorcht werden. Das in der vorliegenden Bachelor-Arbeit dargestellte Verfahren hat auf den Weg der E- Mail vom Sender bis zum elektronischen Postfach des Empfängers, welches vom POP3-Server zur Verfügung gestellt wird, keinen Einfluss. Empfänger der Steuerbefehle -Postfach [...] Sender der (Client) (POP3-Server) n-mail- Server Mail-Server zeitlich temporäre und verschlüsselte Verbindung zwischen Client und POP3- Server. Abb. 1.1: Prinzipdarstellung des Weges einer vom Sender zum Empfänger Aber selbst, wenn sämtliche Teilstrecken zwischen den Mailservern jeweils seperat, also unabhängig voneinander, verschlüsselt würden, hätte jeder, der Zugriff auf einen Mailserver hat, automatisch auch Zugriff auf die im Klartext codierten Daten. Fall 2: Werden bestimmte Nutzdaten verschlüsselt, z. B. zu übertragende Dateien oder Inhalte, können die einmalig verschlüsselten Daten ohne weitere Verschlüsselung auf beliebig viele Rechner und Datenträger übertragen werden. Sie sind immer verschlüsselt und damit vor unbefugtem Zugriff geschützt. Die Fälle 1 und 2 unterscheiden sich hinsichtlich der Softwarearchitektur. Im Fall 1 geschieht die Verschlüsselung hinter dem eigentlichen Anwendungs-Protokoll (hier POP3), im Fall 2 jedoch noch vor dieser. Im Fall 2 werden damit aber keine Befehle und damit auch nicht die Übertragung von Benutzernamen / Passwörter verschlüsselt, welche ja erst durch das POP3-Protokoll bestimmt werden. Dies ist jedoch das Ziel der vorliegenden Arbeit. Um das Ziel einer verschlüsselten Verbindung (Fall 1) zu erreichen, wird in der Anwendungsschicht zwischen POP3-Protokoll und Transportschicht eine weitere Schicht, die - Seite 5 -

6 TLS 6 genannt wird, eingebaut (siehe hierzu auch Abb. 1.2). Diese zusätzliche Schicht (TLS) kann ebenfalls zur Anwendungsschicht gezählt werden, weil ab der Transportschicht mit den Protokollen TCP oder UDP alle weiteren Schichten von Betriebssystem und Hardware zur Verfügung gestellt werden. Schon allein aus Kompatibilitätsgründen darf nichts an diesen unteren Schichten geändert werden. Praktisch muss das TLS-Protokoll in das Anwendungsprogramm, welches ebenfalls das POP3-Protokoll verwendet, implementiert werden. Die Verschlüsselung geschieht aber erst nach Verwendung des POP3-Protokolls. In der vorliegenden Arbeit wird der Schwerpunkt auf die Authentifierzung 7 durch digitale Zertifikate gelegt. Denn nur wenn sichergestellt wird, dass die richtigen Kommunikationspartner verschlüsselt miteinander sprechen, macht die Verschlüsselung auch Sinn. Ein Angreifer könnte sich sonst für den POP3-Server ausgeben. Damit würde der Client eine verschlüsselte Verbindung zu dem Angreifer und damit falschen Dienst aufbauen. Dies ist möglich, da die Verschlüsselungsverfahren allgemein bekannt sind. Der Angreifer könnte nun die vom Client gesendeten Benutzernamen und Passwörter sofort in Klartext abfangen und mit Hilfe dieser in das eigentliche elektronische Postfach einbrechen. Damit würde die Verschlüsselung nichtig werden. Im vorliegenden Fall (POP3) ist das Ziel also die verschlüsselte Übertragung von Benutzername und Passwort (Zugangsdaten eines elektronischen Postfachs) vom Empfänger zum POP3- Server. Dass dabei auch die Daten in umgekehrter Richtung vom POP3-Server zum Empfänger verschlüsselt werden, was in dem vorliegenden Fall wenig sinnvoll ist 8, liegt daran, dass TLS ein allgemeines Verfahren ist, das nicht nur bei s zum Einsatz kommt. In anderen Anwendungsfällen kann der umgekehrte Weg, nämlich Daten verschlüsselt vom Server zum Clienten zu schicken, durchaus Sinn machen. Das TLS-Protokoll wird nicht nur in Verbindung mit s (POP3), sondern für viele verschiedene Anwendungsprotokolle wie z. B. auch HTTP 9 genutzt. Manchmal werden beide Protokolle, das eigentliche Anwendungsprotokoll (POP3, HTTP) sowie das TLS-Protokoll, in einem einzigen, neuen Protokollnamen zusammengefasst. So steht POP3S für das Post Office Protocoll Version 3 in Verbindung mit TLS und HTTPS für HTTP in Verbindung mit TLS. 6 TLS: engl Transport Layer Security, zu dt. etwa Transportschichtsicherheit, Nachfolger des SSL-Protokolls (SSL: engl. Secure Socket Layer). 7 Authentifierzung: hat hier in etwa die Bedeutung von Feststellung einer Identität mittels eines Ausweises. 8 Erinnerung: s werden für gewöhnlich über eine Vielzahl von Mailservern geschoben. 9 HTTP: engl. Hypertext Transfer Protocol, Protokoll zur Übertragung von Webseiten. - Seite 6 -

7 Schichten: Protokolle: Anwendung Betriebssystem Empfänger POP3 TLS Anwendung Transport Internet POP3-Server POP3 TLS Ports TCP/UDP IP (IPv4, IPv6) Sockets Hardware 1. Netzzugang Ethernet, etc. Daten Abb. 1.2: Schichtenmodell mit POP3 und TLS in der Anwendungsschicht Diese Arbeit ist Teil eines größeren Projektes mit dem Ziel, einen -Fetcher zu schreiben. Ein -Fetcher ist ein Programm, das dazu dient, s, die sich auf einem POP3-Server befinden, abzurufen und auf den heimischen Rechner zu übertragen. Die vorliegende Bachelor- Arbeit stellt die für den verschlüsselten Verbindungsaufbau notwendige Basis zur Verfügung. 1.2 Struktur dieser Arbeit Abschnitt 1 gibt eine Übersicht über die vorliegende Bachelor-Arbeit. In Abschnitt 2 wird auf die notwendigen theoretischen Hintergründe eingegangen, um die Realisierung des Verbindungsaufbaus in Abschnitt 3 besser verstehen zu können. Bei der Realisierung in Abschnitt 3 werden zuerst die verwendeten Werkzeuge (Software) kurz vorgestellt. Anschließend wird im ersten Schritt ein Domainname in eine IP-Adresse umgewandelt. Im zweiten Schritt wird die (noch unverschlüsselte) Verbindung zwischen Client und Server realisiert. Dabei wird für Demonstrationszwecke das POP3-Protokoll angewandt. Im dritten und letzten Schritt wird dann die verschlüsselte Verbindung mit Hilfe der Softwarebibliothek GnuTLS realisiert. - Seite 7 -

8 2 Grundlagen 2.1 Symmetrische und asymmetrische Verschlüsselung Symmetrische Verschlüsselungen basieren auf einem gemeinsamen Schlüssel, der von beiden Seiten zur Ver- und Entschlüsselung verwendet wird. Symmetrische Verschlüsselungen benötigen wenige Rechenschritte und sind damit sehr schnell. Rechner A Daten ver- und entschlüsseln mit gemeinsamen Schlüssel öffentliches Netzwerk verschlüsselte Daten Rechner B Daten ver- und entschlüsseln mit gemeinsamen Schlüssel Daten im Klartext Daten im Klartext Abb. 2.1: Symmetrische Verschlüsselung beruht auf einem gemeinsamen Schlüssel Asymmetrische Verschlüsselungen beruhren auf dem Konzept eines Schlüsselpaares. Jeweils Rechner A und Rechner B verfügen über ein solches Schlüsselpaar. Ein Schlüsselpaar besteht aus einem öffentlichen 10 sowie einem privaten 11 Schlüssel. Aus einem öffentlichen Schlüssel kann nicht der private Schlüssel abgeleitet werden et reversa. Mit dem öffentlichen Schlüssel verschlüsselte Nachrichten können nur mit dem privaten Schlüssel wieder entschlüsselt werden. Asymmetrische Verschlüsselungsverfahren sind sehr rechenintensiv und damit langsam. 10 engl. public key, für die Öffentlichkeit bestimmt. 11 engl. private oder secret key. Darf nur dem Empfänger bekannt sein. - Seite 8 -

9 Rechner A Senden Daten verschlüsseln mit öffentlichem Schlüssel von B öffentliches Netzwerk verschlüsselte Daten Rechner B Empfangen Daten entschlüsseln mit privatem Schlüssel von B Daten im Klartext Daten im Klartext Empfangen Daten entschlüsseln mit privatem Schlüssel von A verschlüsselte Daten Senden Daten verschlüsseln mit öffentlichem Schlüssel von A Daten im Klartext Daten im Klartext Abb. 2.2: Asymmetrische Verschlüsselung beruht auf einem Schlüsselpaar pro Übertragungsrichtung (Sender / Empfänger). 2.2 Das Schlüsselverteilungsproblem Ein Problem bei den symmetrischen Verschlüsselungen ist, dass beide Seiten (Rechner A und Rechner B) über einen gemeinsamen Schlüssel verfügen müssen. Ein symmetrischer Schlüssel kann also nicht einfach über das Netz geschickt werden, da ein potentieller Angreifer diesen abfangen und damit sofort alle damit verschlüsselten Nachrichten entschlüsseln kann Das Diffie-Hellman-Verfahren (DHE) Früher gab es zur Verschlüsselung Codebücher und Strichlisten, die aufwändig traditionell per Kurier oder Postbote verteilt werden mussten. Mit der Erfindung des Diffie-Hellman- Verfahrens gelang es, diesen Aufwand zu umgehen, indem sich beide Seiten über eine unsichere Datenverbindung dermaßen auf einen gemeinsamen Schlüssel einigen, ohne dass ein Dritter aus dem Datenverkehr den gemeinsamen Schlüssel ableiten kann. - Seite 9 -

10 Das Diffie-Hellman-Verfahren wurde gemeinsam von Whitfield Diffie 12, Martin Hellman 13 und Ralph Merkle 14 entwickelt. Es wurde 1976 an der Standford-University (Kalifornien) veröffentlicht. Es war das erste offiziel bekannte Verfahren dieser Art 15 und setzte bisher eingesetzen Codebüchern und der damit einhergehenden traditionell verwendeten aufwändigen Schlüsselverteilung mittels Kurier oder Postbote ein Ende. Das Verfahren soll an dieser Stelle kurz geschildert werden. Alle Teilnehmer einigen sich auf eine Primzahl p und eine auch als Generator bezeichnete Basis g. Die Primzahl p sowie die Basis g sind öffentlich bekannt. Die Primzahl p sowie die Basis g können nicht beliebig gewählt werden. Sie müssen so gewählt werden, dass die Gleichung g d i mod p (DHE.1) die Zahlen von 1 bis p 1 durchläuft, wenn d i die Zahlen von 0 bis p 2 (oder von 1 bis p 1) durchläuft 16, 17. Allerdings geschieht letzteres in einer anderen Reihenfolge. Dies ist unter 2 Bedingungen gewährleistet: 1. Die Primzahl p hat einen großen Primteiler q, d. h. es gilt: p = q j + 1 (DHE.2) mit einer natürlichen Zahl j (meist wird j = 2 gewählt). Primzahlen, welche dieser Bedingung standhalten, bezeichnet man auch als sichere Primzahlen. 2. Die Basis g muss eine sogenannte Primitivwurzel sein. Dies ist dann gegeben, wenn sich alle Elemente der primen Restklassengruppe als Potenz der Primitivwurzel darstellen lassen [17]. Dieser Fall ist für sichere Primzahlen erfüllt, wenn gilt: g 2 mod p 1 (DHE.3) und 12 Whitfield Diffie (geb in Washinton D. C.), US-amerikanischer Experte für Kryptographie 13 Martin E. Hellman (geb in New York City), US-amerikanischer Kryptologe 14 Ralph C. Merkle (geb in den USA), US-amerikanischer Kryptologe 15 Bereits in den 1960er Jahren gab es Arbeiten des britischen Government Communication Headquarters (GCHQ), welche dem Diffie-Hellman-Verfahren ähnelten. Diese Arbeiten standen jedoch unter Geheimhaltung und wurden erst 1997 öffentlich bekannt. 16 Bei weiterer Erhöhung der Potenz d ergibt sich eine periodische Wiederholung der Menge Z * p. 17 Mod bedeutet hier der ganzzahlige Rest einer Division. Konkretes Beispiel: 12 / 7 = 1 ganzzahliger Rest 5, d. h = 12. Damit: 12 mod 7 = 5. - Seite 10 -

11 g q mod p 1 (DHE.4) Die Basis g erzeugt mit (DHE.1) die Menge Z * p = {1, 2, 3,..., p - 1}. Dies wird auch als diskrete Exponentation bezeichnet. Dies deshalb, weil ausschließlich mit ganzen Zahlen gearbeitet wird. Diskretes Zahlenbeispiel: 1. Wir wählen den Primteiler q = 5. Mit der natürlichen Zahl j = 2 ergibt sich daraus die sichere Primzahl p = = Als Basis wählen wir die Primitivwurzel g = 2, da nach (DHE.3) und nach (DHE.4) 2 2 mod 11 = 4 mod 11 = 4 1 Damit ergeben sich folgende Werte: 2 5 mod 11 = 32 mod 11 = 10 1 g d i = x x mod p = e i 2 0 = 1 1 mod 11 = = 2 2 mod 11 = = 4 4 mod 11 = = 8 8 mod 11 = = mod 11 = = mod 11 = = mod 11 = = mod 11 = = mod 11 = = mod 11 = = mod 11 = 1 Man sieht, dass d i hier die ganzen Zahlen von 0 bis 9 durchläuft. Für e i ergeben sich die gleichen Zahlen (ganz korrekt: 1), jedoch stehen diese Zahlen in einer anderen Reihenfolge. Das bedeutet, dass die Basis g eine Primitivwurzel modulo 11 darstellt, da sich alle Elemente - Seite 11 -

12 von e i durch Potenzen d i der Basis g darstellen lassen. Ab 2 10 wiederholen sich die Zahlen in gleicher Reihenfolge für. e i d i e i Die Zahlenmengen, welche durch und dargestellt werden, entsprechen zueinander. Die einzelnen Zahlen sind von vornherein bekannt. Jedoch unterscheidet sich deren Zuordnung für jede gewählte Basis g und Primzahl p. Die Zuordnungen von d i und e i werden also erst durch die Festlegung der Basis g sowie der Primzahl p definiert. Wichtig ist, dass in der erzeugten Menge keine Zahl doppelt vorkommt. Deshalb auch die Bedingungen 1 und 2. Z * p Wie diese Zuordnung von d i und e i bei gewählter Basis g und Primzahl g zustande kommt, ist unbekannt. Wäre sie bekannt, könnte vermutlich recht einfach ein Verfahren gefunden werden, welche das Verfahren umdreht (um bei gegebener Basis g und Primzahl p direkt von e i auf d i zurückzurechnen). Damit wäre aber das Diffie-Hellman-Verfahren nicht mehr sicher. Sortiert man die für e i entstandenen Zahlen aufsteigend nach deren Größe, ergibt sich die Umkehrfunktion der diskreten Exponentation, nämlich der diskrete Logarithmus: i e j d i Bis heute ist kein schnelles Verfahren bekannt, um den diskreten Logarithmus zu bestimmen, also bei bekannter Basis und bekannter Primzahl von auf zurückzurechnen. g p e i d i In der Praxis wird mit viel größeren Primzahlen p gearbeitet (gewöhnlich um die 200 Stellen). Die Basis oder der Generator g erzeugt damit eine viel größere Menge Z * p als in unserem Beispiel. Damit wird es unmöglich, über (DHE.1) in vernünftiger Zeit die zu e i zugehörige Zahl zu bestimmen, da man hierzu sämtliche Zuordnungen i einzeln ausrechnen muss. d i Jeder Teilnehmer wählt nun eine natürliche Zahl berechnet damit gemäß Gleichung (DHE.1) d i als seinen geheimen Schlüssel 18 und e i = g d i mod p (DHE.5) einen öffentlichen Schlüssel e 19 i. Damit wird der private Schlüssel d i quasi im öffentlichen Schlüssel e i versteckt. Auf Grund der Tatsache, dass hier in der Praxis mit sehr großen Primzahlen p gearbeitet wird und kein wirklich schneller Algorithmus zur Verfügung steht, um bei trotz bekannten Zahlen g und p aus dem öffentlichen Schlüssel e i auf den gewählten geheimen Schlüssel d i zurückzurechnen, kann das Verfahren als sicher betrachtet werden, da der geheime Schlüssel di nicht in vernünftiger Zeit berechenbar ist. 18 d von engl. decryption: Entschlüsselung 19 e von engl. encryption: Verschlüsselung - Seite 12 -

13 Eine zentrale Schlüsselverwaltung muss sicherstellen, dass sich die öffentlichen Schlüssel aller Teilnehmer unterscheiden und damit kein öffentlicher Schlüssel e i (und damit zwangsläufig auch kein privater Schlüssel d i ) doppelt vorkommt. Der öffentliche Schlüssel e i ist allen Teilnehmern des Verfahrens zugängig. Will jetzt Teilnehmer A einem anderen Teilnehmer B eine verschlüsselte Nachricht schicken, so nimmt Teilnehmer A den öffentlichen Schlüssel e B von Teilnehmer B und berechnet mit Hilfe seines eigenen, geheimen Schlüssels einen weiteren gemeinsamen Schlüssel d A k AB e i k AB = e d A B mod p (DHE.6) Der gleiche Schlüssel k AB wird ebenfalls von Teilnehmer B mit Hilfe des öffentlichen Schlüssels von Teilnehmer A und des eigenen privaten Schlüssels berechnet: e A d B k AB = e d B A mod p (DHE.7) Dass beide Teilnehmer den gleichen Schlüssel berechnen, liegt daran, dass die Matrix der Schlüssel symmetrisch ist ( a b = b a). Man sieht das aber auch, wenn man (DHE.5) in (DHE.6) und (DHE.7) einsetzt. k AB k AB = e d A B mod p = (g d B mod p) d A mod p = g d A d B mod p k AB = e d A mod p = (g d A mod p) d B mod p = g d A d B mod p An dieser Stelle wurde die von bereits Euclid 20 gefundene oder aufgezeichnete Beziehung verwendet. e d y mod p = (g d x mod p) d y mod p = g d x d y mod p k AB Dieser neu erzeugte Schlüssel liegt beiden Teilnehmern vor und wird von beiden Teilnehmern jeweils für die Verschlüsselung wie auch für die Entschlüsselung der Nachrichten verwendet. Er ist symmetrisch. Der auf diese Weise erzeugte gemeinsame Schlüssel k AB kann daher nun für die weitere schnelle symmetrische Verschlüsselung verwendet werden. Ein dritter Teilnehmer C kann den Schlüssel k AB trotz Kenntnis von Basis g sowie Primzahl p und den öffentlichen Schlüsseln e A, e B nicht berechnen, weil ihm weder d A noch d B bekannt sind. Er könnte bei Kenntnis der Basis g sowie der Primzahl c höchstens für sich selbst einen dritten privaten Schlüssel d C und damit auch einen neuen öffentlichen Schlüssel e C berechnen. Mit diesen ließe sich in Verbindung mit den öffentlichen Schlüsseln von Teilnehmer A oder Teilnehmer B jeweils wieder einen neuer gemeinsamer symmetrischer Schlüssel k AC oder k BC generieren. Die symmetrischen Schlüssel k AB, k AC und k BC unterscheiden sich aber voneinander, 20 Euklid von Alexandria, griechischer Mathematiker, lebte wahrscheinlich im 3. Jahrhundert v. Chr. in Alexandria - Seite 13 -

14 solange jeder Teilnehmer einen anderen privaten Schlüssel d i wählt, was wie bereits erwähnt eine zentrale Schlüsselverwaltung über die öffentlichen Schlüssel von allen Teilnehmern sicherstellen muss. Das Diffie-Hellman-Verfahren wird heute tagtäglich im Internet in Kombination mit anderen weiteren Verschlüsselungsverfahren z. B. in der Transport-Layer-Security (TLS) zur Verschlüsselung des Datenstromes einer 2-Punkt-Verbindung verwendet. Siehe hierzu auch Abb C Supported Ciphersuites Ciphersuite name TLS ID Since TLS RSA NULL MD5 0x00 0x01 SSL3.0 TLS RSA NULL SHA1 0x00 0x02 SSL3.0 TLS RSA NULL SHA256 0x00 0x3B TLS1.2 TLS RSA ARCFOUR SHA1 0x00 0x05 SSL3.0 TLS RSA ARCFOUR MD5 0x00 0x04 SSL3.0 TLS RSA 3DES EDE CBC SHA1 0x00 0x0A SSL3.0 TLS RSA AES 128 CBC SHA1 0x00 0x2F SSL3.0 TLS RSA AES 256 CBC SHA1 0x00 0x35 SSL3.0 TLS RSA CAMELLIA 128 CBC SHA1 0x00 0x41 TLS1.0 TLS RSA CAMELLIA 256 CBC SHA1 0x00 0x84 TLS1.0 TLS RSA AES 128 CBC SHA256 0x00 0x3C TLS1.2 TLS RSA AES 256 CBC SHA256 0x00 0x3D TLS1.2 TLS RSA AES 128 GCM SHA256 0x00 0x9C TLS1.2 TLS DHE DSS ARCFOUR SHA1 0x00 0x66 TLS1.0 TLS DHE DSS 3DES EDE CBC SHA1 0x00 0x13 SSL3.0 TLS DHE DSS AES 128 CBC SHA1 0x00 0x32 SSL3.0 TLS DHE DSS AES 256 CBC SHA1 0x00 0x38 SSL3.0 TLS DHE DSS CAMELLIA 128 CBC SHA1 0x00 0x44 TLS1.0 TLS DHE DSS CAMELLIA 256 CBC SHA1 0x00 0x87 TLS1.0 TLS DHE DSS AES 128 CBC SHA256 0x00 0x40 TLS1.2 TLS DHE DSS AES 256 CBC SHA256 0x00 0x6A TLS Abb. 2.3: Auszug aus den von GnuTLS unterstützten Verschlüsselungsmethoden (engl. chiper suites) [10]. DHE weist auf das Diffie-Hellman-Verfahren hin Der Algorithmus von Ron Rivest 21, Adi Shamir 22 und Len Adlemann 23 (RSA) Grundlagen für dieses Verfahren sind Falltürfunktionen, also Funktionen, die leicht zu 21 Ron Linn Rivest (geb in Schenectady, New York), US-amerikanischer Mathematiker u. Kryptologe 22 Adi Shamir (geb in Tel-Aviv), israelischer Kryptologieexperte 23 Leonard Adleman (geb in San Franzisko), US-amerikanischer Professor für Informatik und Molekularbiologie an der University of Southern California (Los Angeles) - Seite 14 -

15 berechnen, aber ohne Geheimnis (die sogenannte Falltür ) praktisch nicht umkehrbar sind. Das RSA-Verfahren wurde von Ron Rivest, Adi Shamir und Len Adleman 1977 begründet. Es beruht, wie Abb. 2.2 auf Seite 9 zeigt, auf einem Schlüsselpaar. Jede Seite (Rechner A, Rechner B) verfügt über einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten Schlüssel (mit dem Geheimnis) zum Entschlüsseln der Daten. Der private Schlüssel darf dabei nicht aus dem dazugehörigen öffentlichen Schlüssel sowie den verschlüsselten Daten rekonstruierbar sein. 1. Es werden zufällig und stochastisch unabhängig zwei Primzahlen p q bestimmt. Eine Primzahl ist eine ganzzahlige, positive und damit natürliche Zahl, die ganz genau zwei natürliche Zahlen als Teiler hat: die eins und sich selbst. Die ersten Primzahlen sind: {2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97...} In der Praxis werden für das RSA-Verfahren Primzahlen mit mindestens ca. 150 Dezimalstellen verwendet (ca. 512 Bit). Die Zahlen müssen so groß gewählt werden, damit es nicht möglich ist, das Verfahren in vernünftiger Zeit mittels Brut Force zu knacken (d. h. alle möglichen Kombinationen auszuprobieren). 2. Es wird das RSA-Modul N = p q (RSA.1) berechnet. Das RSA-Modul N besteht in der Praxis aus ca oder mehr Bits. 3. Bestimmung der Eulerischen φ-funtion 24 des RSA-Modules N φ(n) = (p 1) (q 1) (RSA.2) Die Eulerische Funktion φ (x) gibt für die natürliche Zahl x die Anzahl der zu x teilerfremden Zahlen an, welche kleiner sind als die Zahl x selbst. Zwei natürliche Zahlen a, b sind dann teilerfremd, wenn es keine natürliche Zahl außer der Eins gibt, die beide Zahlen teilt. Die zwei natürlichen Zahlen a, b sind also dann teilerfremd, wenn sie keine gemeinsamen Primfaktoren aufweisen. Beispiele: Die Zahlen 18 und 35 sind teilerfremd, da sich für sie die Primfaktoren 18 = und 35 = 5 7 ergeben. Sie weisen also keine gemeinsamen Primfaktoren auf. 24 griechischer Buchstabe Phi (groß Φ, klein ϕ, alternativ klein auch als φ) - Seite 15 -

16 Die Zahlen 10 und 12 sind nicht teilerfremd, da für sie die Zerlegung in Primfaktoren gilt: 10 = 2 5 und 12 = Beide Zahlen, 10 und 12, haben also den gleichen Primfaktor Zu φ (N) wird eine teilerfremde Zahl e mit der Bedingung 1 < e < φ(n) (RSA.3) bestimmt. e dient zur Verschlüsselung und heißt daher Verschlüsselungsexponent Der Entschlüsselungsexponent 26 d wird berechnet. Dabei muss die Kongruenz 27 e d mod φ(n) = 1 (RSA.4) erfüllt sein. Diese Bedingung geht auf die von bereits Euclid gefundene oder aufgezeichnete Beziehung m = c d mod N = (c e mod N) d mod N = m ed mod N = m zurück. 28 Der Entschlüsselungsexponent d kann mit Hilfe der Gleichung d = (k φ(n) + 1) e (RSA.5) gefunden werden. Dabei wird k beginnend von 1 durchlaufen ( k = 1, 2, 3, 4, 5... ), bis sich ein ganzzahliges (positives) Ergebnis für d ergibt. Bei dem Entschlüsselungsexponenten d handelt es sich um den geheimen Schlüssel. Dieser muss geheim gehalten werden und darf nicht aus der Hand gegeben werden. Es handelt sich dabei um die in der Einleitung dieses Abschnittes erwähnte Falltür. Wichtig ist auch, dass d e gilt, denn sonst wären der öffentliche und der private Schlüssel identisch und somit das gesamte Verfahren hinfällig. Beide Arten von Schlüsseln bestehen damit aus einem Zahlenpaar: öffentlicher Schlüssel (e, N) zur Verschlüsselung privater Schlüssel (d, N) für die Entschlüsselung Beiden Schlüsseln (privat, öffentlich) ist das RSA-Modul N gleich. Die beiden für die 25 engl. encryption: Verschlüsselung 26 engl. decryption: Entschlüsselung 27 Kongruenz: Zahlentheorie. Zwei Zahlen sind in Bezug auf ein Modul (eine weitere Zahl) kongruent, wenn sich bei ihnen bei Division durch das Modul der gleiche Rest ergibt. 28 Wir bezeichnen die unverschlüsselte Nachricht mit m (engl. message) und die verschlüsselte Nachricht mit c (engl. code). - Seite 16 -

17 Berechnung verwendeten Primzahlen p und q werden nicht mehr gebraucht und daher verworfen. Das Verfahren funktioniert nur, weil nicht bekannt ist, wie man von dem RSA- Modul N mit wenig Aufwand auf die beiden Primzahlen p und q zurückrechnen kann. Es handelt sich um das Problem der Primfaktorzerlegung bei großen Zahlen. Beispiel: 1. Wir wählen die beiden Primzahlen p = 5; q = 11 aus. 2. Das RSA-Modul berechnet sich damit nach Gleichung (RSA.1) zu N = p q = 5 11 = Bestimmung der Eulerischen φ-funtion des RSA-Modules N nach Gleichung (RSA.2) φ(n) = (p 1) (q 1) = (5 1) (11 1) = 4 10 = = Bestimmung einer zu φ (N) = = 40 teilerfremden Zahl e, welche zwischen 1 und φ (N) = = 40 liegen muss. Diese Zahl dient als Verschlüsselungsexponent und somit als öffentlicher Schlüssel (allgemein bekannt). Wir wählen e = Berechnung der Inversen zu e mit Hilfe der Gleichung (RSA.5). Wir erhalten bereits für k = 2 das Ergebnis d = 27. Damit kommen wir zu dem Ergebnis d = 27 und k = 2. Während d = 27 als Entschlüsselungsexponent dient (geheimer Schlüssel, welcher unbedingt geheimgehalten werden muss), kann das Ergebnis k = 2 verworfen werden. Damit ergeben sich die für das Verfahren notwendigen und hiermit für einen Schlüsselsatz festgelegten Parameter RSA-Modul N = 55, Verschlüsselungsexponent e = 3 (öffentlicher Schlüssel) und Entschlüsselungsexponent d = 27 (geheimer Schlüssel). (Diese Parameter stimmen mit [3], S. 127 überein.) Verschlüsselung Für die Verschlüsselung c der Nachricht m dient die Gleichung c = m e Empfänger mod N (RSA.6) Im vorhergehenden Beispiel sähe die Verschlüsselung c der Nachricht m = 4 folgendermaßen aus: - Seite 17 -

18 c= m e Empfänger mod N = 4 3 mod 55 = Entschlüsselung Für die Entschlüsselung m des Geheimtextes c dient m = c d Empfänger mod N (RSA.7) Für das vorgenannte Beispiel berechnet sich die ursprüngliche Nachricht m des Geheimtextes c = 9 nach Gleichung (RSA.7) zu m = c d Empfänger mod N = 9 27 mod 55 Die dabei unter Umständen auftretenden hohen Potenzen können mit Hilfe der Rechenregel umgangen werden. (a b) mod c = [(a mod c) (b mod c)] mod c (RSA.8) Nebenrechnungen: 9 27 mod 55 = [(9 4 ) ] mod 55 = (9 3 ) mod 55 = 729 mod 55 = 14 Damit (9 4 )mod 55 = (6561) mod 55 = 16 = 9 27 mod 55 = [(9 4 ) ] mod 55 = {[(9 4 ) mod 55] 6 [9 3 mod 55]} mod 55 = ( ) mod 55 == mod 55 = 4 Es ergibt sich also wieder die ursprüngliche Nachricht m. In der Regel wird das RSA-Verfahren dazu verwendet, um einen dritten, symmetrischen Schlüssel sicher über eine unsichere Datenverbindung zu übertragen (Schlüsselverteilungsproblem). Der symmetrische Schlüssel wird mit dem öffentlichen - Seite 18 -

19 Schlüssel eines Teilnehmers A verschlüsselt und damit von Teilnehmer B sicher an Teilnehmer A geschickt. Dieser entschlüsselt den symmetrischen Schlüssel mit Hilfe seines privaten Schlüssels wieder. Der symmetrische Schlüssel kann anschließend von beiden Teilnehmern zur Verschlüsselung der weiteren Kommunikation verwendet werden. Dies wird deshalb gemacht, weil asymetrische Verschlüsselungsmethoden rechen- und damit auch zeitaufwändig sind. Symmetrische Verschlüsselungsverfahren sind schneller und weniger aufwändig. Auch das RSA-Verfahren wird heute tagtäglich im Internet in Kombination mit anderen (symmetrischen) Verschlüsselungsverfahren in der Transport-Layer-Security (TLS) zum Aufbau einer verschlüsselten Datenverbindung verwendet. Siehe hierzu ebenfalls Abb Das RSA-Verfahren wird darüber hinaus auch für PGP 29 zur Verschlüsselung und Entschlüsselung von s sowie zur digitalen Unterschrift von Dokumenten und zur Zertifizierung verwendet. 2.3 The man-in-the-middle-attack 30 Da die Verschlüsselungsverfahren allgemein bekannt sind, wäre es einem potentiellen Angreifer möglich, sich zwischen beide Kommunikationspartner zu schalten und zu beiden jeweils eine eigene verschlüsselte Verbindung aufzubauen, ohne dass die anderen Kommunikationspartner es merken würden. Das funktioniert so (siehe Abb. 2.4): Fall 1: Der Angreifer gibt sich dem Rechner A gegenüber als Rechner B aus (Abb. 2.4). Rechner A meint also, mit dem Rechner B zu kommunizieren, obwohl er in Wahrheit mit dem Angreifer kommuniziert. Der Angreifer schickt dem Rechner A seinen eigenen öffentlichen Schlüssel e Angreif er. Rechner A verschlüsselt mit dem öffentlichen Schlüssel e Angreif er des Angreifers seine Daten und schickt diese verschlüsselt dem Angreifer (Abb Position a). Der Angreifer entschlüsselt diese Daten mit Hilfe seines eigenen privaten Schlüssels d Angreif er. Anschließend verschlüsselt er die Daten wieder mit dem öffentlichen Schlüssel von Rechner B und schickt diesem die so erneut verschlüsselten Daten (Abb Position b). Rechner B entschlüsselt die vom Angreifer empfangenen Daten mit Hilfe seines eigenen privaten Schlüssels d B. Rechner B kann ohne Identitätsprüfung nicht feststellen, ob er die Daten von Rechner A oder von einem Angreifer empfangen hat. Fall 2: Verläuft analog zu Fall 1, nur in umgekehrter Richtung. Der Angreifer gibt sich dem Rechner B gegenüber als Rechner A aus und schickt diesem auf Anfrage seinen eigenen öffentlichen Schlüssel e Angreif er. Rechner B verschlüsselt unter Verwendung des öffentlichen Schlüssels e Angreif er seine Daten und schickte diese dem Angreifer (Abb Position c). Der Angreifer entschlüsselt die von Rechner B empfangenen verschlüsselten Daten mit seinem privaten Schlüssel d Angreif er. Daraufhin verwendet er den öffentlichen Schlüssel e A von Rechner A zur erneuten Verschlüsselung und sendet die damit verschlüsselten Daten weiter an Rechner A (Abb Position d). Rechner A verwendet seinen eigenen privaten Schlüssel d A zur Entschlüsselung der vom Angreifer empfangenen Daten. Auch hier kann Rechner A ohne 29 PGP steht für engl. pretty good privacy, zu dt. etwa "ziemlich gute Privatspähre". Es handelt sich dabei um ein von Phil Zimmermann (USA) 1991 veröffentlichtes Programm zur Verschlüsselung von s. 30 engl., ein Angriff (engl. "attack"), bei dem sich der Angreifer (engl. "man") zwischen (engl. "in the middle") zwei Kommunikationspartner schaltet und sich jeweils für den anderen ausgibt. Der ganze Datenfluss läuft über den Angreifer, ohne dass es die anderen bemerken. - Seite 19 -

20 Identitätsprüfung nicht unterscheiden bzw. feststellen, von wem er die Daten empfangen hat. Rechner A e Angreifer d A a) Daten d) Angreifer d Angreifer e B e A d Angreifer b) Daten c) Abb. 2.4: Der Man-in-the-middle-Angriff d B e Angreifer Rechner B Der Datenstrom würde somit im Klartext über den Angreifer laufen, ohne dass es Recher A oder Rechner B bemerken würden. Der wichtigste Punkt bei einer verschlüsselten Verbindung ist deshalb die vorausgehende Authentifizierung: Bevor verschlüsselte Daten gesendet werden, müssen die beiden Kommunikationspartner A und B ihre Identitäten mit Hilfe von Ausweispapieren dem jeweils anderen gegenüber bestätigt haben. Beim POP3-Protokoll (ohne zusätzliche Verschlüsselungsschicht) verwendet der Client grundsätzlich Passwort und Benutzername für sein elektronisches Postfach. Dies ist bereits so eine Art primitive Authentifizierung gegenüber dem POP3-Server. Wie bereits erwähnt, wird beides in Klartext zum POP3-Server geschickt. Einem Angreifer wäre es nun leicht möglich, den Datenverkehr auf der Leitung mitzuschneiden. Er käme somit ganz leicht an das verwendete Passwort sowie den Benutzernamen heran und könnte beides dazu verwenden, unberechtigt ein fremdes elektronisches Postfach aufzusperren. Damit das nicht passieren kann, baut man zwischen Client und Server eine Verschlüsselungsschicht ein. Diese heißt TLS. Damit wird der komplette Datenverkehr einschließlich aller Steuerbefehle des POP3-Protokolls und damit auch einschließlich Benutzername und Passwort zwischen beiden Endpunkten verschlüsselt. Zuerst meldet sich der Server mit einem digitalen Zertifikat. Dieses digitale Zertifikat muss vom Client überprüft werden. Erst danach darf der Client verschlüsselt Benutzername und Passwort senden. Nach dem erfolgreichen Aufbau der verschlüsselten Verbindung gelten die für das Post Office Protokoll 3 (POP3) üblichen Befehle. Das gilt somit aber auch für das Einloggen: Nachdem mit Hilfe von Benutzername und Passwort die verschlüsselte Verbindung aufgebaut worden ist, befindet man sich erneut im Authentifizierungszustand diesmal des POP3-Protokolls. D. h. man muss, obwohl Passwort und Benutzername bereits für den Aufbau der verschlüsselten Verbindung benutzt worden sind, diese nach dem Verbindungsaufbau noch einmal anwenden, um so das berechtigte -Konto aufzusperren. Die POP-Protokolle entstanden lange vor TLS. Bei der Erweiterung des POP3-Protokolls durch TLS wurde das POP3-Protokoll vollständig unangetastet gelassen. Außerdem ist das - Seite 20 -

21 TLS-Protokoll komplett unabhängig vom POP3-Protokoll. Beides führt dazu, dass im vorliegenden Fall zweimal nacheinander eine Authentifizierung angewendet wird. Natürlich könnte man auch zwei verschiedene Benutzername-Passwort-Kombinationen verwenden: eine Benutzername/Passwort-Kombination für den verschlüsselten Verbindungsaufbau (TLS) und eine weitere Benutzername-Passwort-Kombination zum Einloggen in das elektronische Postfach (POP3) Das wird in der Praxis aber so nicht gemacht. Der Grund liegt vermutlich darin, dass man dem Besitzer eines elektronischen Postfaches eine weitere Benutzername-Passwortkombination ersparen wollte. 2.4 Digitale Signaturen Beim RSA-Verfahren existiert ein Schlüsselpaar: Ein öffentlicher Schlüssel mit dem Wertepaar e, N, sowie ein privater Schlüssel (der unbedingt geheim bleiben muss) mit dem Wertepaar d, N. Beim Verschlüsseln einer Nachricht wird zuerst die Gleichung (RSA.6) c = m e Empfänger mod N auf die Nachricht m angewandt, und zum Entschlüsseln der Geheimnachricht c dient (RSA.7) Nun gilt aber m = c d Empfänger mod N m = (m e mod N) d mod N = (m d mod N) e mod N = m Der geheime und der private Schlüssel lassen sich vertauschen. Wenn man zuerst den privaten Schlüssel d und anschließend den öffentlichen Schlüssel e auf eine Nachricht m anwendet, erhält man - genau wie im umgedrehten Fall - wieder die Nachricht m. Jedoch mit einem anderen Zwischenergebnis s c nach der Anwendung des privaten Schlüssels d auf die Nachricht m. 31 Diese Eigenschaft lässt sich ausnutzen, um ein Dokument digital zu unterzeichnen. Dazu wendet der Sender als Inhaber des privaten Schlüssels mit Gleichung d Sender 31 s: von engl. signature, zu dt. Unterschrift; zur Definition siehe (DZ.1) auf Seite 22 - Seite 21 -

22 s = m d Sender mod N (DZ.1) diesen auf ein Dokument an. Die so erzeugte Signatur s wird dem Dokument hinzugefügt. Nun wird das Dokument mit dem öffentlichen Schlüssel e Empf änger des Empfängers verschlüsselt und an diesen geschickt. Der Empfänger entschlüsselt mit Hilfe seines privaten Schlüssels Dokument mit Hilfe der Gleichung d Empf änger das verschlüsselte m = s e Sender mod N (DZ.2) Anschließend wendet er den öffentlichen Schlüssel e Sender des Senders auf die Signatur s an und vergleicht sie mit dem ursprünglichen Dokument oder einem Teil davon 32. Stimmt das Ergebnis mit dem ursprünglichen Dokument oder einem Teil davon überein, ist dessen Authentizität 33 und Integrität 34 gewährleistet, da für die Signatur des Dokuments der geheime Schlüssel d Sender des Senders bekannt sein muss. (Über diesen darf ausschließlich der Sender der Nachricht m verfügen.) Beispiel: Wir wenden zuerst Gleichung (DZ.1) auf die Nachricht m = 4 mit den in Abschnitt RSA-Verfahren genannten Parametern RSA-Modul N = 55, öffentlicher Schlüssel e = 3 und privater Schlüssel d = 27 an, um zu zeigen, dass sich die so daraus entstehende Signatur s von der in Abschnitt Verschlüsselung ermittelten Geheimnachricht c unterscheidet. Die dabei auftretende hohe Potenz kann wieder mit Hilfe von Formel (RSA.7) umgangen werden. s = m d Sender mod N = 4 27 mod 55 = [(4 4 ) ] mod 55 = = [{(4 4 ) 6 mod 55} {4 3 mod 55} ] mod 55 = = [{[(4 4 )mod 55] 6 mod 55} {4 3 mod 55} ] mod 55 = Nebenrechnungen: (4 4 ) mod 55 = 36 (36 6 ) mod 55 = auch als Signaturblock bezeichnet. Diese beinhaltet jedoch nicht die vollständige Integrität eines Dokuments. 33 Authentizität: bedeutet, dass die Daten tatsächlich von einer ganz bestimmten Person stammen. 34 Integrität: bedeutet, dass die Daten unverändert übertragen worden sind. Sie wurden auf dem Weg vom Sender zum Empfänger also nicht verändert. - Seite 22 -

23 (4 3 )mod 55 = 9 Damit ergibt sich die Signatur s = (36 9) mod 55 = 324 mod 55 = 49 Diese wird an den Empfänger geschickt. Der Empfänger wendet nun mit Gleichung (DZ.2) den öffentlichen Schlüssel des Senders auf diese Signatur s an: e Sender m = s e Sender mod N = 49 3 mod 55 = mod 55 = 4 Wir erhalten also auch hier wieder die ursprüngliche Nachricht m. Die digitale Unterschrift oder Signatur s unterscheidet sich jedoch von der in Abschnitt Verschlüsselung ermittelten Geheimnachricht c. Es ist zu beachten, dass es sich im realen Fall um zwei verschiedene Schlüsselpaare, nämlich um die des Senders und um jene des Empfängers, handelt. Da eine digitale Signatur s von dem unterzeichneten Dokument m abhängt, ist deren Sicherheit höher als die einer herkömmlichen (handschriftlichen) Unterschrift, welche ja - unabhängig vom unterzeichneten Dokument - immer die selbe ist. 2.5 Hash-Funktion (Streuwertfunktion) Asymmetrische Verschlüsselungsverfahren sind aufwändig und rechenintensiv. Sie eignen sich daher wenig, um eine umfangreiche Nachricht m digital zu unterzeichnen 35. Zwar lassen sich Signaturblöcke verwenden. Aber diese decken nur einen Teil der Nachricht m ab. Aus diesem Grund wendet man oftmals eine Hash-Funktion auf die Nachricht m an. Eine Hash 36 - oder Streuwertfunktion bildet eine große Eingabemenge K, welche in diesem Zusammenhang auch Schlüssel oder key genannt wird, auf eine kleine Ausgabemenge H ab. Die Ausgabemenge H wird auch als engl. hash oder zu dt. als Prüfsumme bezeichnet. Die Größe der Eingabemenge K kann dabei variabel bzw. von unterschiedlicher Länge sein. Die Größe der Ausgabemenge H ist jedoch in der Regel für jede (beliebig lange) Eingabemenge K gleich lang bzw. konstant. Das Ziel einer guten Hash-Funktion ist, dass möglichst jede Eingabemenge K i eine andere Ausgabemenge H j liefert. Außerdem soll das Umkippen eines auch nur einzigen Bits gravierend die Ausgabemenge H verändern. Liefert die Hash-Funktion zu den zwei verschiedenen Eingabemengen K 1 und K 2 die gleiche Ausgabemenge H, so spricht man von einem Konflikt. In Abb. 2.5 auf Seite 24 ergeben z. B. die beiden Eingabemengen K 1 = {K, l, a, u, s] und K 2 = {L, e, o] die gleiche Prüfsumme H = Mit dem Begriff Nachricht kann auch ein digitales Dokument gemeint sein. 36 engl. to hash: zerhacken, zerkleinern - Seite 23 -

24 Die Hash-Funktion soll möglichst eine Einwegfunktion sein, d. h. sie soll nicht umkehrbar sein. Wichtig bei der Verwendung einer Hash-Funktion in Bezug auf Integrität und Authentizität einer Nachricht m ist, dass die durch sie entstandene Ausgabemenge H mit Hilfe des eigenen privaten Schlüssels signiert wird. d Sender Der Empfänger wendet den öffentlichen Schlüssel e Sender des Senders auf die Signatur s an sowie die Hashfunktion auf die übermittelte Nachricht m. Stimmen die so ermittelten beiden Prüfsummen H 1, H 2 überein, wurde die Nachricht m unverändert übermittelt. An dieser Stelle soll ergänzend erwähnt werden, dass die Nachricht m durchaus auch noch mit dem öffentlichen Schlüssel e Empf änger des Empfängers verschlüsselt sein kann. Die auf diese Weise codierte Nachricht c muss in diesem Fall dann zuvor mit dem privaten Schlüssel d Empf änger des Empfängers in die Nachricht m entschlüsselt werden, bevor der öffentliche Schlüssel des Senders auf die digitale Signatur s angewandt werden kann. e Sender Das Anwenden des privaten Schlüssels d Sender des Senders auf die Prüfsumme H ist notwendig, weil die verwendete Hash-Funktion zur Überprüfung auch dem Empfänger bekannt sein muss. Ein Angreifer könnte sonst die auch möglicherweise ihm bekannte Hash-Funktion auf die veränderte Nachricht m verändert anwenden und damit eine neue, für die veränderte Nachricht korrekte Prüfsumme erzeugen. m verändert H verändert Eingabemenge (Schlüssel) keys Peter Betina Klaus Leo... Streuwertfunktion hash function Kollision Streuwerte (Prüfsumme, Fingerabdrücke) hashes (fingerprints) Abb. 2.5: Beispiel für eine Hash- oder Streuwertfunktion Da die kleine Ausgabemenge H einer Hash-Funktion eindeutig eine größere Eingabemenge K kennzeichnet, wird diese Ausgabemenge H in Anspielung auf den Menschen auch als engl. fingerprint oder zu dt. als Fingerabdruck bezeichnet. 2.6 Digitale Zertifikate Die bis an dieser Stelle dargestellten Mechanismen versagen, wenn es darum geht zu überprüfen, ob ein öffentlicher Schlüssel tatsächlich zu einer ganz bestimmten Person gehört. Gelöst werden kann das Problem, indem mindestens eine dritte unabhängige Person oder Instanz für die Echtheit des öffentlichen Schlüssels bürgt. Dieser öffentliche Schlüssel wird - Seite 24 -

25 dann mit dem privaten Schlüssel der dritten unabhängigen Person bzw. Instanz unterschrieben (signiert). Will man die Echtheit eines Schlüssels überprüfen, muss man damit zwangsläufig einer dritten Stelle vertrauen. Ein Zertifikat besteht damit mindestens aus dem öffentlichen Schlüssel des Zertifikatsinhabers sowie der digitalen Signatur des Aussstellers In der Praxis gibt es Zertifizierungsstellen, welche digitale Zertifikate ausstellen. Die digitale Signatur kann dann mit Hilfe des öffentlichen Schlüssels der Zertifizierungsstelle und damit die Echtheit des Zertifikats überprüft werden Streng hierarchische Public-Key-Infrastruktur Der öffentliche Schlüssel der Zertifizierungsstelle lässt sich wiederum mit der Signatur und dem öffentlichen Schlüssel von deren eigenen Zertifizierungsstelle überprüfen. Auf diese Weise lässt sich eine Baumstruktur gemäß Abb. 2.6 aufbauen. Deutsche Telekom Wurzelzertifizierungsinstanz (root certificate authority) DFN-Verein PCA Global - G01 (Deutsches ForschungsNetz) Zertifizierungsstelle (certificate authority) [...] Hochschule Landshut Zertifizierungsstelle (certificate authority) [...] Student 1 Anwender (Student 1 user) Student 2 Anwender (Student 2 user) [...] ([...]: weitere) Abb. 2.6: Beispiel einer streng hierarchischen Public-Key-Infrastruktur am Beispiel der Hochschule Landshut - Seite 25 -

26 Das System endet bei einer Wurzelzertifizierungsinstanz, der alle Teilnehmer ohne weitere Überprüfung vertrauen müssen. In der Praxis existieren in der Regel verschiedene Wurzelzertifizierungsinstanzen nebeneinander. Zertifikate nach dem weitverbreiteten Standard X.509 der internationalen Fernmeldeunion, welche u. a. im RFC festgelegt ist, funktionieren auf diese Weise. Einige Betriebssysteme (Windows) bieten die Möglichkeit einer zentralen Zertifikatsverwaltung, auf die alle Programme zurückgreifen können. 38 Da dieser Mechanismus jedoch bei verschiedenen Betriebssystemen unterschiedlich realisiert oder gar nicht vorhanden ist, enthalten viele portierbare 39 Programme (z. B. Thunderbird, Firefox...) bereits eine eigene Datei mit Zertifikaten oder einen eigenen Zertifikatsspeicher. Abb. 2.7: Die mit dem Webbrowser Netsurf bereits mitgelieferten X.509-Zertifikate in der Datei ca-bundle. (Ursprung: Mozilla) Im Falle der Hochschule Landshut ist es so, dass jeder Student eine Datei vom Rechenzentrum erhält. Diese Datei ist im PFX-Format 40. Diese Datei endet auf.pfx oder.p12. Sie beinhaltet 37 Es gibt verschiedene Versionen, die sich zeitlich nacheinander entwickelt haben und alle in verschiedenen RFCs festgelegt wurden. 38 Unter Windows kann diese zentrale Zertifikatsverwaltung mit Hilfe des Befehls certmgr.exe aus einem Kommandofenster (cmd.exe) oder über die Windows-Hilfe aufgerufen werden. 39 portierbar: der Quellcode eines Programmes ist mit Hilfe eines Compilers für verschiedene Systeme umsetzbar 40 PFX: engl. Personal Information Exchange, zu dt. privater Informationsaustausch, gerne auch als PKCS #12 bezeichnet. PFX kann in einer einzigen Datei ein digitales Zertifikat sowie den dazugehörigen privaten Schlüssel sicher, weil passwortgeschützt, ablegen. - Seite 26 -

27 das digitale Zertifikat mit dem öffentlichen Schlüssel und der Signatur des Ausstellers, den Zertifizierungspfad sowie einen privaten Schlüssel. Letzterer ist durch ein Passwort geschützt. Der private und der öffentliche Schlüssel müssen gemeinsam erzeugt werden. Der private Schlüssel liegt in diesem Fall damit nach Herausgabe des Zertifikats jedoch mindestens zwei Parteien vor: der Hochschule Landshut sowie dem Studenten Das kann nachteilig sein, weil beide Parteien keine Kontrolle über die jeweils andere Seite hat. Sicherer wäre es, wenn der Student sich selbst ein Schlüsselpaar erzeugen und sich dann den öffentlichen Schlüssel von der HS Landshut digital signieren lassen würde. Zuvor müsste die HS Landshut natürlich die Identität des Schlüsselinhabers als eingeschriebener Student überprüfen. Damit blieben die private Schlüssel allein in den Händen der Studenten. Grundsätzlich ist es bei dieser Hierarchie für den Zertifikatsinhaber recht umständlich bis schwierig, wenn - aus welchen Gründen auch immer - ein neues Zertifikat benötigt wird. Er muss sich immer an die Zertifizierungsstelle wenden und sich ein neues Zertifikat ausstellen lassen, was unter Umständen auch noch mit einem zu entrichtenden Entgeld verbunden ist. Ganz aufwändig wird es, wenn z. B. der private Schlüssel der Wurzelzertifizierungsinstanz öffentlich bekannt werden würde. In diesem Fall müsste die Wurzelzertifizerungsinstanz sich selbst ein neues Schlüsselpaar bzw. Zertifikat ausstellen und damit auch jeder nachfolgenden Stelle, welche wiederum ihren nachfolgenden Stellen neue Zertifikate ausstellen müssten etc. (Lawineneffekt). Eine Alternative, bei der sich jeder selbst Zertifikate ausstellen und von anderen signieren lassen kann, bietet die Software OpenPGP. Diese Alternative beruht auf dem Prinzip Web of Trust Web of Trust Bei dem Web of Trust kann sich jeder mit Hilfe spezieller Software wie z. B. das bereits genannte OpenPGP selbst Zertifikate ausstellen sowie die öffentliche Schlüssel anderer signieren. Je mehr Zertifikate einem Schlüssel anhängen, desto größer ist die Sicherheit darüber, dass dieser Schlüssel tatsächlich zu einer ganz bestimmten Person gehört. 41 engl. Web of Trust, zu dt. etwa Netz des Vertrauens - Seite 27 -

28 Benutzer 1 direktes Vertrauen Benutzer 3 direktes Vertrauten indirektes Vertrauen direktes Vertrauten Benutzer 2 Benutzer 4 direktes Vertrauen Abb 2.8: Prinzipdarstellung des Web of Trust Dieses System wird hauptsächlich für die Signierung und Verschlüsselung von s verwendet. Die von (Open)PGP verwendeten Zertifikate unterscheiden sich prinzipbedingt grundlegend vom X.509-Standard und werden im Standard RFC 4880 festgelegt. Sie sind für diese Arbeit jedoch nicht relevant. - Seite 28 -

29 3 Realisierung 3.1 Die verwendeten Werkzeuge UNIX ist ein Betriebssystem, welches bereits sehr früh für Netzwerke ausgelegt worden war. Die Besonderheit besteht darin, dass es in seiner Geschichte einerseits schon sehr bald internetfähig war und andererseits gleichzeitig mit dem Entstehen von Unix die neue Programmiersprache C für dessen Entwicklung geschaffen worden ist. Das Ziel von C war es, den Programmcode möglichst hardwareunabhängig zu machen. Statt den kompletten Code für eine andere Umgebung, Plattform oder Rechnerarchitektur selbst immer wieder neu schreiben zu müssen, übernahm das jetzt selbst ein Programm. Damit reicht es im Idealfall aus, einen neuen Compiler zu schreiben, der den Quellcode in die jeweils endgültige Maschinensprache der Zielplattform oder verwendeten Rechnerarchitektur übersetzt. UNIX wurde ab 1976 kostenlos als Quellcode an Universitäten vertrieben. Es wurde im Laufe der Jahre weiterentwickelt und verbessert. Die letzte UNIX-Version, deren Quellcode frei verfügbar war, war Version 7 (V7). Danach trat in der Software-Industrie ein allgemeines Umdenken auf: Software wurde von da an meist nicht mehr als Quellcode, sondern fast nur noch kommerziell als binäre, bereits für verschiedene Prozessorarchitekturen ausführbare Maschinenprogramme verkauft. Dieses Umdenken betraf auch spätere Versionen von UNIX. Deshalb wurde von Richard Stallmann, ehemaliger Mitarbeiter am Massachusetts Institute of Technology (kurz: MIT) in den USA, in den Achtziger Jahren eine Software-Initiative namens GNU ( GNU's not Unix ) 42 gegründet, deren Ziel es war, völlig freie Software zu entwickeln, an der jeder mitarbeiten und die jeder verwenden und zu seinen eigenen Zwecken abändern konnte und durfte. Stallmann kündigte 1984 seine Stelle am MIT und begann unter der von ihm geschaffenen GNU-Lizenz, an einem völlig freien Betriebssystem zu arbeiten. Bis Anfang der Neunziger Jahre waren große Teile dieses Betriebssystems fertiggestellt. Was allerdings noch fehlte, das war ein brauchbarer Betriebssystemkern. Diesen steuerte im September 1991 erstmals Linus Torwald (Finnland) bei und ist unter dem Namen Linux bekannt geworden. Linux und GNU sind nicht zu verwechseln. Während Linux nur einen frei verfügbaren Betriebssystemkern bezeichnet, ist die Absicht von GNU generell die Erzeugung und Verbreitung frei verfügbarer Software samt Quellcode und nach wie vor insbesondere einem freien Betriebssystem, das sich in seiner Architektur stark an UNIX orientiert. Heute werden meist Kombinationen von GNU in Verbindung mit dem Linux-Kern eingesetzt. Es gibt inzwischen jedoch auch von der GNU entwickelte Betriebssystemkerne, die vom Linux- 42 GNU ist ein rekursives Akronym, d. h. eine Abkürzung, die in der Bedeutung auf sich selbst verweist. Es handelt sich dabei um ein Paradoxon, da als rekursives Akronym ihre eigene Bedeutung undefiniert ist. Rekursive Akronyme kommen besonders häufig in der freien Software-Szene vor. - Seite 29 -

30 Kern unabhängig sind. Dementsprechend werden solche Betriebssysteme korrekterweise als GNU/Linux (mit Linux-Kern) oder als GNU (ausdrücklich ohne Linux-Kern, dafür aber mit einem unter der GNU-Lizenz geschaffenen Kern) bezeichnet. In der einschlägigen Literatur werden heute Betriebssysteme, welche auf den tatsächlich Anfang der 1970er Jahre in den Bell Labs von Ken Thompson und Dennis Ritchie geschaffenen UNIX-Quellcode zurückzuführen sind, als UNIX 43 bezeichnet, wohingegen unixartige, aber vom ursprünglichen UNIX-Quellcode unabhängige Betriebssysteme als Unix 44 bezeichnet werden GNU Compiler Collection (GCC) Unter dem GNU-Projekt wurden viele Systemprogramme und insbesondere ein frei verfügbarer C-Compiler namens GCC (GNUs C Compiler) entwickelt, der sich zwischenzeitlich zu einer komplexen Compiler-Sammlung (GNUs Compiler Collection) entwickelt hat. Diese Compiler-Sammlung läuft inzwischen auf vielen verschiedenen Plattformen und Rechnerarchitekturen sowie Betriebssystemen. Ebenfalls sind unter der GNU-Lizenz zum Teil sehr mächtige Programm-Bibliotheken samt Dokumentation verfügbar. Dies hat die großen Vorteile, dass ein einmal geschriebener Quellcode für viele verschiedene Rechner- Architekturen übersetzt werden kann und eine große Sammlung von Programmbibliotheken zur Verfügung steht, deren Quellcode vollständig einsehbar ist. Letzterer Punkt ist ein wesentliches Merkmal einer sicheren Verschlüsselungstechnik: Ein Verschlüsselungsverfahren kann nur dann als allgemein sicher gelten, wenn die Mechanismen und damit auch der Quellcode der Öffentlichkeit vollständig bekannt und überprüfbar sind. In der vorliegenden Bachelor-Arbeit wird aus all diesen Gründen ausschließlich mit diesem C- Compiler der GNU Compiler Collection (kurz GCC) gearbeitet, welche unter der Netzadresse samt Bibliotheken für verschiedene Systeme zum kostenlosen Download zur Verfügung steht. Neben den bereits für verschiedene Rechnerarchitekturen erzeugten, direkt laufbaren Versionen von GCC kann dort auch der Quellcode eingesehen werden. Es sei an dieser Stelle noch erwähnt, dass es neben GNU / Linux noch weitere freie, unixoide Betriebssysteme wie z. B. FreeBSD gibt, die nicht mehr auf den ursprünglichen UNIX-Kern zurückgehen. Diese sind selbständige Entwicklungen und stehen kaum oder überhaupt nicht in Verbindung zu GNU / Linux Cygwin Cygwin (http://www.cygwin.com) erlaubt die Verwendung von unixartigen Werkzeugen unter Windows. Es bietet eine unixoide Arbeitsumgebung, die unter Windows lauffähig ist. Damit können auch Programme der GNU Compiler Collection unter Windows compiliert und 43 BSD (frühere Versionen), HP-UX (Hewlett-Packard), DG/UX (Data General), AIX (IBM), IRIX (Silicon Graphics), Solaris (Sun), Mac OS X (Apple) 44 BSD (neuere Versionen), GNU, Linux, QNX - Seite 30 -

31 ausgetestet werden, wie wenn es sich direkt um einen mit GNU/Linux betriebenen Rechner handeln würde. Es handelt sich dabei jedoch nur um eine Anwendungsprogrammierschnittstelle (engl. application programming interface - kurz API). Ausführbare Programme, die bereits auf Rechnern direkt unter Unix erzeugt wurden, sind unter Cygwin nicht lauffähig. Damit diese lauffähig sind, müssen sie unter Cygwin neu aus dem Quellcode compiliert werden. Mangels eines mit Unix betriebenen Rechners wird das in der vorliegenden Arbeit zu entwickelnde Programm unter Cygwin compiliert und ausgetestet. 3.2 Domainnamen in IP-Adressen konvertieren Im Internet verfügt jeder Teilnehmer über eine eindeutige Identifikationsnummer: die Internet- Protokoll- oder kurz IP-Nummer. Bei der Version 4 des Internet-Protokolls (kurz: IPv4) handelt es sich dabei um ein weltweit eindeutiges, 32-Bit langes Codewort. D. h. dass jedem Teilnehmer eine einmalige IP-Nummer zugeordnet ist. IP-Nummern dürfen nicht mehrfach vergeben werden. Version 6 des Internet-Protokolls (kurz: IPv6) wurde eingeführt, weil zwischenzeitlich alle verfügbaren IP-Nummern unter Version 4 verbraucht waren. Version 6 arbeitet mit einem etwas abgeänderten Protokoll; zudem sind die Adressen hier 128-Bit lang, so dass sich eine wesentlich höhere Anzahl an verfügbaren IP-Nummern ergibt. Grundsätzlich ändert dies aber nichts an der Art der Programmierung. Statt Funktionen für IPv4 aufzurufen, werden jene für IPv6 verwendet. Diese Funktionen sind äquivalent (gleichwertig). Die binäre Codierung dieser IP-Nummern ist für Menschen jedoch ungeeignet. Daher hat man das sogenannte Domain Name System (DNS) eingeführt. Dabei handelt es sich um einen Dienst, der Buch über alle weltweit an das Internet angeschlossenen Teilnehmer führt. In den elektronischen Listen sind symbolische Namen den entsprechenden IP-Nummern zugeordnet. Im folgenden werden diese symbolische Namen, welche stellvertretend für IP-Nummern stehen, als Hostnamen bezeichnet. Die Bezeichnung Host 45 steht generell als Synonym für einen an das Internet angeschlossenen Knoten- (Router) oder auch Endpunkt (Client, Server). Genaugenommen müsste man noch zwischen den verschiedenen Netzwerkkarten eines Computers unterscheiden, da eine IP-Nummer nicht einem Computer, sondern einer Netzwerkkarte zuzuordnen ist. Ein Computer kann durchaus gleichzeitig mehrere verschiedene Netzwerkkarten (z. B. Funk, Kabel) betreiben. Damit kann er dann gleichzeitig über mehrere verschiedene IP-Nummern und damit auch Hostnamen erreichbar sein. Im Internet bauen sich die Hostnamen in einem hierarchischen System auf, das in Domänen bzw. Bereiche (engl. domains) und Unterdomänen bzw. Unterbereiche (engl. subdomains) aufgegliedert ist. Diese Bereiche werden von verschiedenen Organisationen und damit auch verschiedenen Servern verwaltet. Der vollständige Name einer Domäne, der einer IP-Nummer zugeordnet werden kann, wird im Englischen als Fully Qualified Domain Name oder kurz als FQDN bezeichnet. Wir wollen sie hier aber nur schlicht als Hostnamen bezeichnen. Für weitere 45 engl. host: zu deutsch Gastgeber, Wirt - Seite 31 -

32 Details des DNS wird auf spezielle Literatur verwiesen. Wurzel (engl. root):. Top Level Domain: (TLD) com org net de fh-landshut mail Fully Qualified Domain Name: mail.fh-landshut.de Abb. 3.1: Aufbau des Domain Name Systems (DNS) Bei den Hostnamen handelt es sich um alphanummerische und einige Sonderzeichen (Punkt, Strich etc.) beinhaltende Namen, welche für Menschen wesentlich besser als ein 32-Bit- Codewort les- und merkbar sind. Wie in Abb. 3.1 zu sehen ist, sind verschiedene Schichten der Hierarchie im Hostnamen durch Punkte voneinander getrennt. Neben den Hostnamen existiert für IP-Adressen noch eine Nummern-Punkt-Schreibweise. Diese ist jedoch nicht mit der eigentlichen binären 32-Bit- oder 128-Bit-langen IP-Adresse selbst zu verwechseln. Hostname IP-Nummer mail.fh-landshut.de Tabelle 3.1: IPv4 Hostname und -nummer (letzteres in der Nummern-Punkt-Schreibweise) Die Internet-Protokolle und somit auch alle Vermittlungsstellen (Router) kennen nur die 32-Bitbzw. 128-Bit-langen Codewörter als Adressen. Will man einen entfernten Teilnehmer ansprechen, benötigt man daher seine binäre IP-Nummer. Üblicherweise erlaubt ein Programm die Eingabe eines Hostnamens oder einer IP-Nummer in der Nummern-Punkt-Schreibweise. In beiden Fällen muss der Eintrag zur internen Verwendung zuerst in die verwendbare, sprich 32-Bit- oder 128-Bit- lange binäre Form einer IP-Adresse umgewandelt werden. Die Nummern-Punkt-Schreibweise kann direkt in eine IP-Nummer umgerechnet werden, also ohne externe Server des Domain Name Systems (DNS) befragen zu müssen. Bei Verwendung eines Hostnamens muss jedoch vor einem Verbindungsaufbau mit Hilfe des Domain Name Systems (DNS) über externe Server die richtige IP-Nummer ermittelt werden. - Seite 32 -

33 Für die Umwandlung der Nummern-Punkt-Schreibweise bzw. des Hostnamen in die binäre IP- Nummer stellt uns die Bibliothek clib 46 der GCC verschiedene Datentypen und Funktionen zur Verfügung. Um einen Hostnamen mit Hilfe des DNS in eine IP-Nummer aufzulösen, existiert u. a. die Funktion struct hostent * gethostbyname (const char *name). Für Näheres, siehe [2], S. 403 u Abb. 3.2: DNS-Namensauflösung unter Cygwin 3.3 Verbindungsaufbau und Datenaustausch mit dem Server Die IP-Nummer ist Voraussetzung für eine Internet-Verbindung. Nachdem wir die IP-Nummer ermittelt haben, können wir damit im nächsten Schritt eine Verbindung zu dem Server aufbauen. Um dies zu realisieren, gibt es das Konzept der Sockets 47. Bei Sockets handelt es sich um Software-Schnittstellen zur Interprozess- oder Netzwerkkommunikation. Die Bibliothek clib stellt auch für dieses Konzept verschiedene Funktionen bereit. Jedoch müssen Sockets auch vom Betriebssystem unterstützt werden, damit sie erfolgreich angewandt werden können. Der Funktionsaufruf funktioniert sonst (stillschweigend) nicht. Ein Socket dient üblicherweise dazu, eine temporäre Verbindung über ein Rechnernetz zu einem anderen Rechner einzurichten. Über eine Software-Schnittstelle ist es dann möglich, Daten bidirektional 48 zwischen den beiden Rechnern auszutauschen. Sockets können jedoch auch dazu dienen, um verschiedene Prozesse auf dem gleichen Computer miteinander sprechen zu lassen. (Interprozesskommunikation). Ein Socket dient nicht allein dazu, um eine Verbindung zwischen zwei entfernten und über ein Netz miteinander verbundenen Rechnern aufzubauen. Die Verbindung geht weiter darüber hinaus und beinhaltet auch bestimmte Programme und Prozesse. Damit verschiedene Programme und Prozesse miteinander kommunizieren können, sind mehrere eingerichtete Sockets notwendig - jeweils ein eigenes Socket für zwei miteinander sprechende Programme. 46 Der vollständige Name lautet GNU C Library. 47 socket: engl. für Steckdose, Anschluss 48 bidirektional: gleichzeitig in beide Richtungen - Seite 33 -

34 Schichten: Protokolle: Rechner A Rechner B Anwendung Betriebssystem Anwendungen Transport Internet Ports TCP/UDP IP (IPv4, IPv6) Sockets Hardware 1. Netzzugang Ethernet, etc. Daten Abb. 3.3: Das TCP/IP-Referenzmodell Abb. 3.3 stellt das TCP/IP-Referenzmodell dar. Datenströme (Pfeile) laufen über verschiedene Schichten zwischen den Rechnern A und B hin und her. Aus diesem Bild wird ersichtlich, dass es mehrere Protokolle gibt, die ineinandergreifen (Anwendungsprotokoll, TCP, IP etc.). Daten, die von einer Anwendung auf Rechner A an eine Anwendung auf Rechner B geschickt werden, werden von der Anwendung auf Rechner A an die Transportschicht übergeben. In der Transportschicht werden die Daten mit Zusatzinformationen versehen. Die Zusatzinformationen dienen nur zum weiteren Transport. Anschließend gibt die Transportschicht die Daten an die Internetschicht weiter. Diese fügt den Daten wieder Zusatzinformationen hinzu. Bis hierher spielt sich der Vorgang komplett auf Rechner A ab. Anschließend werden die Daten der Netzwerkschicht (in obiger Darstellung Netzzugang genannt) übergeben. Die Daten laufen nun durch das Netzwerk zum Rechner B. Dort spielt sich der auf Rechner A geschilderte Vorgang in umgekehrter Reihenfolge ab, d. h. die Daten durchlaufen nacheinander die Internetschicht (2.), die Transportschicht (3.) und landen zuletzt in der Anwendungsschicht (4.), wobei bei einem Wechsel von einer Schicht in eine andere ein jedes Mal die entsprechenden, zuvor auf Rechner A hinzugefügten Zusatzdaten der einzelnen Schichten für den Transport wieder entfernt werden. Die Portnummer gibt das vom Anwendungsprogramm verwendete Protokoll an. Beispiele für Portnummern sind etwa 110 für die 3. Generation des Post Office Protocoles, welches zum Abrufen von s dient, oder die Portnummer 80, das für das Hypertext Transfer Protocol steht und zur Übertragung von Webseiten dient. Ein Socket stellt in diesem Modell eine Verbindung zwischen den Anwendungen zweier über ein Netz verbundener Rechner her. Eine bestimmte Anwendung auf Host A richtet ein Socket ein, das von einer Anwendung des Kommunikationspartners B ebenfalls mit einem Socket verbunden werden kann. Dabei gibt es zwei verschiedene Arten von Sockets: eines für den Server (das immer vorhanden ist und auf Verbindungsanfragen lauscht) sowie eines für den Client. Im Rahmen dieser Arbeit werden nur Sockets für den Client betrachtet. - Seite 34 -

35 Eine Anwendung hat "nichts weiter" zu tun, als ein Socket einzurichten, sich mit einem weiteren Socket zu verbinden und das eingerichtete Socket entsprechend anzusteuern. Um den Rest kümmern sich die schon bereits vorhandene Software (Betriebssystem) und Peripherie (Netzwerkkarte, Leitung etc.). Socket einrichten socket (...) Socket verbinden connect (...) Daten senden und empfangen read (...), write (...) Verbindung beenden close(...) Abb. 3.4: Ablaufschema einer Internet-Verbindung mit Hilfe von Sockets Bei der Einrichtung eines Sockets muss ein Übertragungsprotokoll angegeben werden: SOCK_STREAM: richtet eine zuverlässige Zwei-Wege-Verbindung zwischen zwei Endpunkten ein. Daten können gleichzeitig in beide Richtungen geschickt werden (sogenannter Vollduplexbetrieb). Das zu diesem Dienst gehörende Internetprotokoll trägt den Namen Transmission Controll Protocol (kurz TCP). SOCK_DGRAM: Hier werden einzelne unabhängige Datenpakete mit einer Zieladresse versehen verschickt. Dieser Dienst ist unzuverlässig. Das zugehörige Internetprotokoll heißt User Datagram Protocol (kurz UDP). Jedem Socket wird bei Einrichtung bzw. Initialisierung eine Identifikationsnummer zugewiesen, an Hand derer es angesprochen wird. Ein Socket ist damit aber noch nicht verbunden. Dies geschieht erst mittels dem Funktionsaufruf connect(...). Für eine Verbindungsherstellung über das Internet werden folgende Parameter benötigt: Namensbereich: Adresse: Port: AF_INET Internet-Protokoll-Nummer (IP-Nummer) Portnummer des zu verwendenden Protokolls - Seite 35 -

36 Da für verschiedene Namensbereiche (lokal, Internet) verschiedene Adressformate existieren, gibt AF_INET die für das IPv4-Protokoll zu verwendende Adressform an (hier: binäre 32-Bit- Adresse). AF_INET6 dagegen würde die für das Internet Protokoll Version Bit-lange IP- Nummer angeben. Nachdem die Verbindung erfolgreich aufgebaut wurde, können mittels der Funktionen read(...) und write(...) Daten übertragen werden. Beendet wird die Verbindung wieder mit close(...). 3.4 Das Post Office Protocol (POP) Nachdem die Verbindung zu einem Server hergestellt wurde, können mit diesem Daten ausgetauscht werden. In dieser Bachelor-Arbeit wird die Verbindung zu einem -Server aufgebaut. Die Regeln für die Kommunikation sind in einem Protokoll festgelegt. Um auf dem -Server eingegangene s zu verwalten, existieren grundsätzlich zwei Möglichkeiten: Die s werden gesammelt vom -Server auf den heimischen Rechner übertragen und dann dort vom Anwender ohne Verbindung zum -Server (offline) per -Client 49 gelesen und bearbeitet. Eventuell wird die nach Übertragung noch vom -Server gelöscht. Hierfür existiert das Post Office Protocol (POP). Dieses Vorgehen ist das älteste Verfahren, weil früher die Verbindungszeit in Rechnung gestellt wurde. Die s werden in ständiger Verbindung zum -Server einzeln aufgerufen und auf letzterem bearbeitet. Dafür existiert das Internet Message Access Protocol (IMAP). IMAP baut auf POP auf und erweitert dieses um zusätzliche Befehle. Zum Versenden von s dient dagegen das Simple Mail Transfer Protocol (SMTP). In der vorliegenden Bachelorarbeit wird das Post Office Protocol verwendet. Deshalb wird dieses an dieser Stelle kurz vorgestellt. Ursprünglich wurde das POP-Protokoll mittels einem Terminalprogramm genutzt. 49 Ein -Client ist ein Programm, das zum Lesen und Bearbeiten von s dient. - Seite 36 -

37 Abb. 3.5: Einloggen in einen POP3-Server mittels Terminalprogramm (unter RISC OS) Abb. 3.5 zeigt dieses Verfahren. Nachdem eine Verbindung zu dem POP-Server aufgebaut ist, werden die einzelnen Befehle getippt. Jeder Befehl wird mittels einem Druck auf die <Return>- Taste ASCII-codiert an den Server übermittelt. Die Bedeutung der <Return>-Taste entsprechen dabei in der Programmiersprache C einem Wagenrücklauf \r gefolgt von einem Zeilenvorschub \n. Nachdem also eine Verbindung zu einem POP-Server aufgebaut wurde, werden die Befehle mittels write() im Klartext (d. h. ASCII-codiert) einzeln an den POP-Server geschickt. Der POP-Server führt diese Befehle aus und gibt entsprechende Antworten, die wir mit der Funktion read() lesen können. Alle diese Befehle müssen mit einem <Return> abgeschlossen werden. Einige geläufige Befehle des POP-Protokolls sind: USER <username>: Dient zum Einloggen in ein bestimmtes -Konto. Ein POP- Server kann viele verschiedene -Konten verwalten und muss daher wissen, welches für die aktuelle Sitzung verwendet werden soll. PASS <password>: Zur Sicherheit wird nach der Eingabe von USER <username> die Eingabe eines Passwortes verlangt. STAT: Gibt Auskunft über Anzahl (erste Zahl) und belegter Datenspeicher (zweite Zahl) aller vorhandenen s auf dem POP-Server an. QUIT: Beendet eine Sitzung. Der POP-Server kappt anschließend aber auch die zuvor mittels connect() zu ihm aufgebaute TCP-Verbindung. Das bedeutet in unserem Fall, dass man nach einem QUIT mittels connect() wieder eine Verbindung zu dem POP-Server aufbauen muss, um sich erneut in ein -Konto einloggen zu können. - Seite 37 -

38 Die Spezifikationen des POP3 50 -Protokolls können im Standard RFC der Network Working Group nachgelesen werden. Sämtliche Daten zwischen POP-Server und dem Nutzer (Client) laufen im Klartext hin- und her. Spätestens an dieser Stelle wird aber klar, dass das dann auch für Benutzername (engl. user, user name), dem Passwort (engl. password) sowie allen abzurufenden s gilt. Wenn ein Dritter in der Lage ist, den Datenverkehr zwischen beiden Rechnern mitzuschneiden, kann er damit sofort alle Daten im Klartext lesen. Um dieses Problem zu beseitigen, hat man sich bemüht, zwischen der Anwendungs- und der Transportschicht eine zusätzliche Schicht einzubauen. Früher hießt diese Schicht SSL (engl. Secure Sockets Layer). Die zum Zeitpunkt der Niederschrift dieser Arbeit aktuelle Version dieser zusätzlichen Schicht nennt man engl. transport layer security oder kurz TLS. Sie dient dazu, die zu sendenden Daten zu ver- und auf der Empfangsseite wieder zu entschlüsseln. TLS wird nicht nur für das POP-Protokoll, sondern für viele weitere Anwendungsprotokolle verwendet (z. B. https...). Das POP-Protokoll dient in dieser Arbeit nur als Beispiel. 3.5 Einbinden von GnuTLS Um GnuTLS verwenden zu können, muss dieses in den vorhandenen Compiler eingebunden werden. Der Installer von Cygwin bietet GnuTLS bereits an. Allerdings müssen die benötigten Pakete für die Installation ausgewählt werden, damit der Compiler die benötigten Libraries später auch finden kann. Siehe hierzu auch Abb Abb. 3.6: Die Installation von Cygwin mit den für GnuTLS erforderlichen Paketen 50 POP3: Version 3 des Post Office Protokolls (POP). 51 engl. Request For Comments, zu dt. etwa: Verlangen nach Bemerkungen, Kommentaren. Anfangs wurden darunter nur zu diskutierende Vorschläge verstanden; inzwischen sind RFCs jedoch zu festen Standards (Normen) für das Internet geworden. - Seite 38 -

39 Der Kopf (engl. header) der GnuTLS-Library muss mit #include <gnutls/gnutls.h> in jede C-Quelldatei eingebunden werden, welche Funktionen dieser Library verwendet. Außerdem hat man beim Kompilieren (Übersetzen und Zusammenbauen des Programms) mittels gcc den Parameter -lgnutls hinzuzufügen. Der Parameter -llibrary bindet eine Library beim Verketten (engl. linking) mit ein. Mit diesem Parameter wird die Library dem Compiler bekannt gemacht. Der Compiler kann sonst sämtliche Funktionen und Parameter von GnuTLS nicht verarbeiten und bricht spätestens beim Verketten (engl. linking) mit einer Fehlermeldung ab. 3.6 POP3S und STARTTLS Ursprünglich sprachen Client und POP-Server unverschlüsselt miteinander. Dafür wurde Port 110 reserviert. Später baute man ein zusätzliches Protokoll zwischen POP- und TCP-Protokoll ein, das für die Verschlüsselung zuständig war. Aus der Sicht des TCP/IP-Referenzmodells lag in der Anwendungsschicht nun ein neues Protokoll vor, das POP3S 52 genannt wurde (S: engl. security - dt. geheim). Für dieses neue Anwendungsprotokoll wurde Port 995 reserviert (siehe hierzu auch Abb. 3.3: Das TCP/IP-Referenzmodell). Bei POP3S setzt der Aufbau einer verschlüsselten Verbindung unmittelbar nach Verbindung bzw. Kontaktaufnahme des Clients mit dem Server ein. Kann eine verschlüsselte Verbindung nicht hergestellt werden, kommt es zwangsläufig zum Abbruch. Der Nachteil dieses Verfahrens ist, dass ein Anwender oder Administrator unter Umständen erst verschiedene Ports ausprobieren muss, wenn nicht bekannt ist, ob ein POP-Server TLS bietet oder nicht. Außerdem können die Systeme vor Aufbau der verschlüsselten Verbindung nicht klären, mit welcher Art von Zertifikaten der -Server arbeitet (z. B. X.509-Zertifikate oder OpenPGP-Zertifikate). Auch in diesem Fall kann es unter Umständen zu einem unschönen Fehler und damit Abbruch kommen. STARTTLS umgeht dieses Problem, indem sich Server und Client nach Verbindungsaufbau zuerst im Klartext und unverschlüsselt miteinander unterhalten können. Dies geschieht auf dem für das ursprüngliche POP reservierten Port 110. Sie können sich so über ihre Fähigkeiten im Klaren werden. Die Fähigkeiten (d. h. die dem Server bekannten Befehle) werden vom Client mit dem Befehl CAPA 53 abgerufen. Bietet der Mail-Server eine Verschlüsselung an, so muss diese Fähigkeit mit dem Befehl STLS in der mittels CAPA abgerufenen Befehlsliste enthalten sein. Die verschlüsselte Verbindung wird erst mittels dem Befehl STLS aufgebaut, welche der Client an den POP-Server zu senden hat. Wichtig ist, dass in jedem Fall ein Einloggen mittels den bekannten Befehlen USER und PASS 52 Die Drei steht für die dritte Generation des POP-Protokolls. 53 engl. capabilities, zu dt. Fähigkeiten - Seite 39 -

40 in Klartext unterbunden wird, weil ein Angreifer dem Client vortäuschen könnte, dass der E- Mail-Server kein STARTTLS bietet. In diesem Fall muss der Vorgang abgebrochen und dem Anwender eine Nachricht ausgegeben werden. Bei einem Einloggen mittels Klartextübertragung könnte der Angreifer sonst ohne weiteres Benutzername und Passwort mithorchen und sich damit kurz später Zugang zu dem elektronischen Postfach verschaffen. Grundsätzlich ist es so, dass die Entscheidung eines Sicherheitsrisikos letzten Endes immer dem Anwender überlassen werden muss und dieser somit die gesamte Verantwortung für den Vorgang trägt. Der auslösende Grund für die vorliegende Arbeit war, dass die Hochschule Landshut zum Abruf der elektronischen Postfächer ( -Accounts) ab dem Jahr 2012 STARTTLS auf den Rechnern der Endanwender voraussetzte. Da es zu diesem Zeitpunkt für das Betriebssystem RISC OS keine Software gab, die das konnte, war es notwendig geworden, hierfür selbst eine zu schreiben. Der Autor der vorliegenden Arbeit hätte sonst von RISC OS aus keinen Zugang mehr zu seinen s der Hochschule Landshut gehabt. Aus diesem Grund wird in der vorliegenden Arbeit das Ziel von STARTTLS verfolgt. Die Tests wurden mit dem POP-Server der Hochschule Landshut unter realen Bedingungen über das Internet gemacht. Die Ergebnisse sind in vorliegender Arbeit aufgeführt. Normalerweise stellt ein Internet-Provider dem Besitzer einer -Adresse gleich mehrere Möglichkeiten zum Abruf der s zur Verfügung (POP3, POP3S, STARTTLS usw.). Der Besitzer kann dann selbst über das gewünschte Verfahren entscheiden. Eine Bevormundung von seitens des Providers ist hier untyptisch und auch in keinster Weise kundenorientiert oder erwünscht. STARTTLS wird nicht nur in Verbindung mit POP, sondern auch in Verbindung mit den E- Mail-Protokollen IMAP und SMTP verwendet. 3.7 Aufbau, Nutzung und Beendigung der verschlüsselten Verbindung Im vorliegenden Abschnitt 3.7 Aufbau, Nutzung und Beendigung der verschlüsselten Verbindung geht es in erster Linie um die für die verschlüsselte Verbindung (in Abb. 3.7 auf Seite 41 auch konkret TLS-Sitzung genannt 54 ) notwendigen Ausweispapiere von Client und Server in Form von Benutzernamen, Passwörter und digitalen Zertifikaten. Denn diese Daten müssen der Sicherheitsschicht TLS für die Authentifizierung der Kommunikationspartner zur Verfügung gestellt und entsprechend überprüft werden. Damit werden die Identitäten von Client und POP3-Server überprüft. Abb. 3.7 zeigt die dazugehörige Verknüpfung für die Seite des Clients. Nur diese Seite soll in vorliegender Arbeit betrachtet werden. Wurde das vom POP3-Server geschickte digitale Zertifikat nicht erfolgreich überprüft, muss vom Clienten sofort die Verbindung abgebrochen werden. In diesem Fall kann es sein, dass der 54 Ganz allgemein wurde der Begriff verschlüsselte Verbindung eingeführt. Im konkreten (praktisch vorliegenden und zu realisierenden) Fall handelt es sich dabei um eine TLS-Sitzung. - Seite 40 -

41 Client mit einem Angreifer kommuniziert. Folglich darf auch der handshake nicht durchgeführt werden, weil sonst ein Angreifer die Vereinbarungen für die Verschlüsselung kennen und damit die vom Clienten geschickten Daten (Passwort, Benutzername) entschlüsseln könnte. Wurde dagegen die Identität des POP3-Servers an Hand der von ihm geschickten digitalen Zertifikate erfolgreich überprüft, kann der handshake durchgeführt werden: Client und POP3- Server einigen sich dabei auf ein ganz bestimmtes Verschlüsselungsverfahren (engl. chiper suite). Bei diesem handshake weist sich der Client dem POP3-Server gegenüber erstmals mit Benutzername und Passwort aus. Beide werden jedoch bereits verschlüsselt gesendet und bleiben damit einem Lauschangriff verborgen. Ein Zuhörer versteht nur Chaos. Nachdem der handshake erfolgreich durchgeführt wurde, können verschlüsselt Nutzdaten geschickt und empfangen werden. In diesem Zustand kann sich der Client nun in das elektronische Postfach seiner zugehörigen -Adresse einloggen, wobei hier das eigentliche Ziel, Benutzername und Passwort verschlüsselt zu senden, erreicht wird. Damit ein Angreifer nicht einfach die aktuelle TLS-Sitzung unterbrechen oder gar auflösen kann, wird am Ende von Abschnitt 3.7 noch kurz auf die ordnungsgemäße Beendigung bzw. den ordnungsgemäßen Abbruch der aktuellen TLS-Sitzung eingegangen. Client Ausweispapiere Server Ausweispapiere TLS-Sitzung Socket Netz Abb. 3.7: Übersicht aller erforderlichen Verknüpfungen für den handshake. Es gibt viele verschiedene Verschlüsselungsmethoden. GnuTLS kennt deren über 56 verschiedene, welche engl. als cipher suite ( Chiffrier- oder Schlüsselsatz) bezeichnet wird. Die zu verwendende Verschlüsselungsmethode (Schlüsselsatz) wird beim Aufbau der sicheren Verbindung von Client und Server ausgehandelt: Der Client teilt dem Server mit, welche cipher suites er kennt. Der Server sucht sich dann einen bestimmten Schlüsselsatz davon aus. Diesen Vorgang bezeichnet man engl. als handshake (dt. Händedruck). Erst danach bauen Client und Server die verschlüsselte Verbindung auf. Für STARTTLS in Verbindung mit POP wird in [7] ausdrücklich die cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA vorausgesetzt. Weitere cipher suites sind möglich, jedoch keine Grundvoraussetzung. Bevor man Funktionen der GnuTLS-Library verwenden kann, muss man die Funktion int - Seite 41 -

42 gnutls_global_init(void) aufrufen. Diese Funktion weist der Library GnuTLS Speicher zu und setzt alle globalen Daten auf ihre Voreinstellungen. Sie initialisiert außerdem die Library libgrypt (falls noch nicht geschehen). Im Erfolgsfall gibt die Funktion den Wert GNUTLS_E_SUCCESS (0) zurück. Andernfalls wird ein Fehlercode zurückgeliefert. gnutls_global_init (void); [...] gnutls_global_deinit (void); Abb. 3.8: globale Resourcenreservierung und -freigabe in GnuTLS Wird GnuTLS nicht mehr gebraucht, sollte man die reservierten Mittel wieder mittels der Funktion void gnutls_global_deinit (void) freigeben. Im nächsten Schritt müssen die Einstellungen für eine Sitzung vorgenommen werden. Eine Sitzung, das ist ein bestimmter, einmaliger Verbindungsaufbau zu einem Server, zu dem eine verschlüsselte Verbindung hergestellt werden soll. Um diese Verbindung aufzubauen, benötigt das System bestimmte Informationen über Client und Server. Für beide Seiten (Client und Server) existieren hierfür Strukturen. Mittels von GnuTLS bereitgestellten Funktionen werden die notwendigen Daten in diese Strukturen geschrieben bzw. kopiert Authentifizierung des POP-Servers durch digitale Zertifikate Der POP-Server weist sich noch vor dem handshake mit mehreren digitalen Zertifikaten aus. Weitverbreitet sind X.509-Zertifikate, welche auf einer Hierachie von Zertifizierungsstellen beruhen und in [9] näher beschrieben werden. X.509-Zertifikate werden ebenfalls von GnuTLS unterstützt. Der Server schickt zuerst sein eigenes Zertifikat, gefolgt von dem Zertifikat seiner Zertifizierungsstelle, gefolgt von dem Zertifikat der Zertifizierungsstelle der Zertifizierungsstelle des Servers usw. bis hin zu dem Wurzelzertifikat, an welchem die Hierarchie endet. Die Zertifikate sind im binären.der-format. Die vom Server geschickten Zertifikate müssen mit dem Zertifikat (beinhaltet öffentlichen Schlüssel) des jeweiligen Ausstellers überprüft werden. Die Zertifikate der Aussteller dürfen nicht von dem Server kommen, zu dem die sichere Verbindung aufgebaut werden soll. Sie müssen von dritter, unabhängiger Seite kommen. Cygwin beinhaltet die Zertifikate gängiger Aussteller bereits unter dem Pfad /usr/ssl/ certs/. Die schon mitgelieferten digitalen Zertifikate funktionieren mit GnuTLS jedoch ausdrücklich nicht, da sie im falschen Format vorliegen. Man muss sich daher selbst die - Seite 42 -

43 benötigten Zertifikate holen und entsprechend zusammenstellen. Die digitalen Zertifikate findet man z. B. auf den Webseiten der Zertifizierungsstellen, denen man vertrauen möchte. Zertifikate gibt es in verschiedenen Formaten. Dazu sollte man einiges wissen. Das Zertifikat Root CA 2 der Deutschen Telekom sieht in der Textdarstellung nach ASN.1 55 z. B. folgendermaßen aus: Certificate: Data: Version: 3 (0x2) Serial Number: 38 (0x26) Signature Algorithm: sha1withrsaencryption Issuer: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2 Validity Not Before: Jul 9 12:11: GMT Not After : Jul 9 23:59: GMT Subject: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2 Subject Public Key Info: Public Key Algorithm: rsaencryption Public-Key: (2048 bit) Modulus: 00:ab:0b:a3:35:e0:8b:29:14:b1:14:85:af:3c:10: e4:39:6f:35:5d:4a:ae:dd:ea:61:8d:95:49:f4:6f: 64:a3:1a:60:66:a4:a9:40:22:84:d9:d4:a5:e5:78: 93:0e:68:01:ad:b9:4d:5c:3a:ce:d3:b8:a8:42:40: df:cf:a3:ba:82:59:6a:92:1b:ac:1c:9a:da:08:2b: 25:27:f9:69:23:47:f1:e0:eb:2c:7a:9b:f5:13:02: d0:7e:34:7c:c2:9e:3c:00:59:ab:f5:da:0c:f5:32: 3c:2b:ac:50:da:d6:c3:de:83:94:ca:a8:0c:99:32: 0e:08:48:56:5b:6a:fb:da:e1:58:58:01:49:5f:72: 41:3c:15:06:01:8e:5d:ad:aa:b8:93:b4:cd:9e:eb: a7:e8:6a:2d:52:34:db:3a:ef:5c:75:51:da:db:f3: 31:f9:ee:71:98:32:c4:54:15:44:0c:f9:9b:55:ed: ad:df:18:08:a0:a3:86:8a:49:ee:53:05:8f:19:4c: d5:de:58:79:9b:d2:6a:1c:42:ab:c5:d5:a7:cf:68: 0f:96:e4:e1:61:98:76:61:c8:91:7c:d6:3e:00:e2: 91:50:87:e1:9d:0a:e6:ad:97:d2:1d:c6:3a:7d:cb: bc:da:03:34:d5:8e:5b:01:f5:6a:07:b7:16:b6:6e: 4a:7f Exponent: (0x10001) 55 ANS: engl. Abstraction Syntax Notation - Seite 43 -

44 X509v3 extensions: X509v3 Subject Key Identifier: 31:C3:79:1B:BA:F5:53:D7:17:E0:89: 7A:2D:17:6C:0A:B3:2B:9D:33 X509v3 Basic Constraints: CA:TRUE, pathlen:5 X509v3 Key Usage: critical Certificate Sign, CRL Sign Signature Algorithm: sha1withrsaencryption 94:64:59:ad:39:64:e7:29:eb:13:fe:5a:c3:8b:13:57:c8:04: 24:f0:74:77:c0:60:e3:67:fb:e9:89:a6:83:bf:96:82:7c:6e: d4:c3:3d:ef:9e:80:6e:bb:29:b4:98:7a:b1:3b:54:eb:39:17: 47:7e:1a:8e:0b:fc:1f:31:59:31:04:b2:ce:17:f3:2c:c7:62: 36:55:e2:22:d8:89:55:b4:98:48:aa:64:fa:d6:1c:36:d8:44: 78:5a:5a:23:3a:57:97:f5:7a:30:4f:ae:9f:6a:4c:4b:2b:8e: a0:03:e3:3e:e0:a9:d4:d2:7b:d2:b3:a8:e2:72:3c:ad:9e:ff: 80:59:e4:9b:45:b4:f6:3b:b0:cd:39:19:98:32:e5:ea:21:61: 90:e4:31:21:8e:34:b1:f7:2f:35:4a:85:10:da:e7:8a:37:21: be:59:63:e0:f2:85:88:31:53:d4:54:14:85:70:79:f4:2e:06: 77:27:75:2f:1f:b8:8a:f9:fe:c5:ba:d8:36:e4:83:ec:e7:65: b7:bf:63:5a:f3:46:af:81:94:37:d4:41:8c:d6:23:d6:1e:cf: f5:68:1b:44:63:a2:5a:ba:a7:35:59:a1:e5:70:05:9b:0e:23: 57:99:94:0a:6d:ba:39:63:28:86:92:f3:18:84:d8:fb:d1:cf: 05:56:64:57 Trusted Uses: Code Signing, Protection, TLS Web Server Authentication No Rejected Uses. In der Praxis wird das Zertifikat jedoch meist binär gespeichert. Dazu verwendet man die Distinguished Encoding Rules, welche im Standard ITU-T X.690, 2002 festgelegt sind. In der Regel erkennt man eine mit Hilfe der Distinguished Encoding Rules binär codierte Datei an der Dateiendung.DER. Da das SMTP 56 -Protokoll ursprünglich nur für ASCII-Zeichen ausgelegt wurde und den Umgang mit binären Dateien nicht kann, hat man eine weitere Codierung eingeführt: BASE64. Mit dieser Codierung ist es möglich, binär codierte Zeichen ASCII-Zeichen-gerecht darzustellen. Damit kann man z. B. beliebig binär-codierte Dateien an s anhängen (Bilder, Dokumente etc.). Leider geht dies einher mit einem Kompressionsverlust; BASE64- codierte Dateien sind größer als die entsprechenden, ursprünglich binär codierten Dateien. Werden mit Hilfe der Distinguished Encoding Rules (.DER) binär-codierte Zertifikate BASE64-56 SMTP: engl. Simple Mail Transfer Protocol, Transport-Protokoll für elektronische Mail - Seite 44 -

45 codiert, hat man eine Darstellung, welche meistens die Dateiendung.PEM 57 aufweisen. So sieht das Zertifikat ROOT 2 der Deutschen Telekom BASE64-codiert z. B. folgendermaßen aus: -----BEGIN TRUSTED CERTIFICATE----- MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENB IDIwHhcNOTkwNzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxl U2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290 IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrC6M14IspFLEU ha88eoq5bzvdsq7d6mgnlun0b2sjgmbmpklaiotz1kxlejmoaagtuu1cos7tukhc QN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1Mjwr rfda1speg5tkqayzmg4isfzbavva4vhyaulfcke8fqybjl2tqrittm2e66foai1s NNs671x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0moc QqvF1afPaA+W5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoH txa2bkp/agmbaagjqjbamb0ga1uddgqwbbqxw3kbuvvt1xfgixotf2wksyudmzap BgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOC AQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756Abrsp tjh6sttu6zkxr34ajgv8hzfzmqsyzhfzlmdinlxiitijvbsyskpk+tycntheefpa IzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl 6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+ xbrynusd7odlt79jwvngr4gun9rbjnyj1h7p9wgbrgoiwrqnnvmh5xafmw4jv5mu Cm26OWMohpLzGITY+9HPBVZkVzAgMB4GCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYB BQUHAwE= -----END TRUSTED CERTIFICATE----- Dateien mit der Datei-Endung.crt können eine ganze Liste von Zertifikaten (z. B..PEM) enthalten. Es gibt darüber hinaus noch weitere Datentypen und Darstellungen für digitale Zertifikate, die an dieser Stelle aber nicht behandelt werden, da sie für diese Arbeit nicht relevant sind. Bei den Dateiendungen für Zertifikate gibt es leider Verwirrung, weil sie nicht wirklich einheitlich festgelegt worden sind. Daher werden die gleichen Dateiendungen wie.crt durchaus für verschiedene Arten von Zertifikaten verwendet. Deshalb kann man letzten Endes das verwendete Format eines Zertifikats nur mit Hilfe eines Editors sicher feststellen - indem man sich den Dateiinhalt anschaut. Es hat sich gezeigt, dass es in GnuTLS reicht, wenn man zur Überprüfung das Wurzelzertifikat 57 PEM: engl. Privacy Enhanced Mail, ein Sicherheitskonzept für s von etwa 1990, Näheres dazu findet sich in den RFCs Seite 45 -

46 in den Zertifizierungsspeicher lädt. Abb. 3.9: Die Wurzelzertifikate der Deutschen Telekom Der zugehörige Quellcode für die Initialisierung der Resourcen58 für die Server-Zertifikate ist in Abb dargestellt. Struktur erzeugen gnutls_certificate_credentials_t cert_cred; Struktur initialisieren gnutls_certificate_allocate_credentials (&cert_cred); lokal gespeicherte Zertifikate laden gnutls_certificate_set_x509_trust_file (cert_cred, CAFILE, GNUTLS_X509_FMT_PEM); Abb. 3.10: Initialisierung der Resourcen für die Server-Zertifikate Die vom Server geschickten Zertifikate müssen überprüft werden, bevor der verschlüsselte 58 Initialisierung der Resourcen: Einrichten und Bereitstellen verschiedener Mittel wie Speicher, Strukturen etc. für die Aufnahme bzw. Speicherung von empfangenen Zertifikaten. - Seite 46 -

47 Verbindungsaufbau beginnt. Dafür stellt GnuTLS die Funktion gnutls_certificate_set_verify_function (...) zur Verfügung. Diese Funktion spring ein vom Anwender geschriebendes Unterprogramm an, sobald der Client vom Server die Zertifikate erhält. Die Überprüfung geschieht noch vor dem handshake. Um den Zeitpunkt des Ansprunges (des Unterprogrammes) kümmert sich GnuTLS bzw. die Funktion gnutls_certificate_set_verify_function(...) selbst. Status der vom Server geschickten Zertifikate überprüfen ret = gnutls_certificate_verify_peers2(session, &status); ret < 0? ja Fehlerwert zurückgeben nein n Statusbit n gesetzt? ja zugehörige Meldung ausgeben Bit GNUTLS_CERT_INVALID gesetzt? ja Fehlerwert zurückgeben nein Hostname überprüfen Abb. 3.11: Überprüfung der vom Server geschickten Zertifikate Die Überprüfung der vom Server geschickten Zertifikate kann auch weggelassen werden. Dann setzt der handshake unmittelbar ohne Überprüfung der Zertifikate ein. In diesem Falle ist aber nicht gewährleistet, dass der Client mit dem richtigen Server kommuniziert. Deshalb stellt ein Fehlen der Überprüfung der vom Server geschickten Zertifikate eine große Sicherheitslücke dar. Nach erfolgreichem Funktionsaufruf enthält status das Ergebnis der Überprüfung. Mit Hilfe des bitweisen UND (engl. AND, in C: &) kann überprüft werden, ob ein bestimmtes Bit in status gesetzt ist (s. Abb auf S. 48 Beispiel 1) oder nicht (s. Abb auf S. 48 Beispiel 2). Es dient somit als Filter, um ein entsprechend gesetztes Bit aus einer Vielzahl von Bits herauszufischen (für gewöhnlich kann ein Computer immer nur mit einer Vielzahl von Bits - z. B. 8 Bits - gleichzeitig arbeiten, weshalb in diesem Fall die anderen ausgegrenzt werden müssen). - Seite 47 -

48 & AND AND a) Konjuktionstabelle b) Beispiel 1 c) Beispiel 2 Abb. 3.12: UND-Verknüpfung Die Bedeutung der einzelnen mittels gnutls_certificate_set_verify_function (...)in status gesetzten Ergebnisbits finden sich in [10], Table 3.4. Da alle Statusmeldungen wie Zertifikat abgelaufen, Aussteller unbekannt etc. ausgegeben und dann aber sofort das Unterprogramm mit der Rückgabe des Fehlerwertes GNUTLS_E_CERTIFICATE_ERROR verlassen werden soll, sollte erst am Ende der Überprüfung aller Statusbits von status das Statusbit GNUTLS_CERT_INVALID geprüft werden. Dieses Bit wird grundsätzlich gesetzt, wenn die überprüften Zertifikate als ungültig betrachtet werden. - Seite 48 -

49 Vom Server geschickte Zertifikate sind im X.509-Format? gnutls_certificate_type_get(...) Struktur für ein Zertifikat einrichten gnutls_x509_crt_init (&cert) ja nein Fehlerwert zurückgeben Vom Anwender eingegebenen Hostnamen holen gnutls_session_get_ptr(...) Adresse des Zertifikatsspeichers holen gnutls_certificate_get_peers(...) nein ja kein(e) Zertifikat(e) empfangen Fehlerwert zurückgeben Das erste vom Server geschickte Zertifikat holen und importieren gnutls_x509_crt_import(...) Überprüfung des Hostnamens gnutls_x509_crt_check_hostname(...) Stimmt Hostname? ja Nullwert zurückgeben und damit handshake durchführen nein Fehlerwert zurückgeben Abb. 3.13: Überprüfung des Hostnamens vom POP-Server Ein Zertifikat im X.509-System ist immer auch an einen oder mehreren distinguished 59 names wie einen Hostnamen gebunden. Der im ersten Zertifikat (im vom Server geschickten Zertifikat) enthaltene Hostname muss mit dem vom Anwender eingegebenen Hostnamen übereinstimmen. Voraussetzung dafür, dass dieses Verfahren sicher ist, ist laut [7] die Verwendung eines secure DNS-lockups, da der Hostname nicht direkt mit der zurückgelieferten IP-Adresse gegengeprüft werden kann. Um letzteres zu erreichen, müsste ebenfalls die richtige IP-Adresse im Zertifikat 59 engl. distinguished: hervorragend, ausgezeichnet - Seite 49 -

50 des Servers stehen. Dies ist nicht der Fall. secure DNS-lockup bedeutet, dass der vom Anwender eingegebene Hostname des POP3- Servers auf jeden Fall in die richtige IP-Adresse aufgelöst wird. Damit wird es einem Angreifer unmöglich, die Auflösung eines Hostnamens in die zugehörige IP-Adresse zu verfälschen und damit die Datenverbindung vom Client auf einen falschen Rechner mit einer anderen IP- Adresse zu lenken. Dies wird deshalb vorausgesetzt, weil die Authentifizierung durch digitale Zertifikate bei diesem Verfahren allein nicht hinreichend ist: Der Server schickt nur digitale Zertifikate, welche vom Clienten überprüft werden müssen. Nun kann ein Angreifer aber ebenfalls diese digitalen Zertifikate schicken, da die digitalen Zertifikate öffentlich bekannt sind. Damit allein ist aber das gesamte Verfahren hinfällig. Wünschenswert wäre an dieser Stelle die Verwendung einer eigenen digitalen Signatur des Servers: Nachdem der Server dem Client die Zertifikate geschickt hätte, müsste nach der Überprüfung der Zertifikate der Client dem Server unverschlüsselte und zufällige Daten schicken. Der Server müsste die zufälligen Daten mit Hilfe seines eigenen privaten Schlüssels signieren und diese Signatur an den Client zurückschicken. Der Client müsste nun den im überprüften Zertifikat des Servers enthaltenen öffentlichen Schlüssel auf die Signatur der Daten anwenden und das so entstandene Resultat mit den ursprünglichen, an den Server geschickten Daten vergleichen. Nur, wenn beide übereinstimmen, wäre an dieser Stelle gewährleistet, dass der Client mit dem richtigen Server kommuniziert. Denn nur der richtige POP3-Server würde über seinen eigenen privaten Schlüssel verfügen. Ein Angreifer könnte die zufälligen Daten nicht signieren, da er den privaten Schlüssel nicht hat. Aber scheinbar wird dies nicht gemacht. Sonst wäre die in [7] verlangte Verwendung eines secure DNS-lockups nicht notwendig. Weder die Verwendung eines secure DNS-lockups noch das eben geschilderte Verfahren der Anwendung einer Signatur auf eine Zufallsnachricht wurden aus Zeitgründen in vorliegender Arbeit näher überprüft. Hat das Zertifikat alle Überprüfungen erfolgreich bestanden, kann das Unterprogramm mittels dem Rückgabewert return(0); verlassen werden. Nur in diesem Fall wird der handshake durchgeführt. Tritt ein Fehler auf oder wird das Zertifikat für ungültig erklärt, wird das Unterprogramm sofort verlassen und ein Fehlerwert zurückgegeben. In diesem Fall muss zum Ende des Hauptprogrammes gesprungen und die Verbindung sofort ordentlich beendet werden, damit es gar nicht erst zu einem handshake kommt Authentifizierung des Clients mittels Secure Remote Password (SRP) Bei TLS in Verbindung mit POP muss sich zu Anfang (während dem handshake oder Händedruck bzw. dem Aushandeln der Verschlüsselung) der Client gegenüber dem Server mit - Seite 50 -

51 Benutzernamen und Passwort ausweisen. Im Englischen nennt man dies secure remote password (SRP) authentication. Im wesentlichen handelt es sich dabei um ein eigenes Protokoll, das in GnuTLS integriert ist. Struktur erzeugen gnutls_srp_client_credentials_t srp_cred; Struktur initialisieren gnutls_srp_allocate_client_credentials (&srp_cred); Benutzername und Passwort einschreiben gnutls_srp_set_client_credentials (srp_cred, USER, PASS); [...] Struktur freigeben gnutls_srp_client_credentials (srp_cred); Abb. 3.14: Verfügungsstellung der Daten für die Authentifizierung durch Benutzername und Passwort des Clienten Nach Sitzung und Auflösung der TCP-Verbindung soll die für die Benutzername-Passwort- Authentifizierung des Clients notwendige Struktur wieder freigegeben werden Einrichtung der TLS-Sitzung (Client und Server) Nachdem die Informationen und Mittel über POP-Server und Client zur Verfügung stehen, müssen diese für die zu verwendende Sitzung bereitgestellt werden. Dies geschieht, indem man eine Struktur session vom Typ gnutls_session_t initialisiert und die Strukturen für POP-Server und Client mit Hilfe der Funktion gnutls_credentials_set (...) dorthin übernimmt. gnutls_credentials_set (...) wird ausdrücklich für beide Strukturen, d. h. für Server und Client, gleichermaßen verwendet. Die Funktion erkennt am Typ der zu übergebenden Struktur, ob es sich um Server oder Client handelt. Zusätzlich muss jeweils noch der Typ der Authentifizierung mit angegeben werden. Da sich der Client mit Benutzername und Passwort ausweist, muss hier der Typ GNUTLS_CRD_SRP für secure remote passwort angegeben werden. GNUTLS_CRD_CERTIFICATE gibt die - Seite 51 -

52 Authentifizierung mittels Zertifikat an und gilt in unserem Fall nur für den Server. Nach Beendigung der Sitzung soll die Struktur session ebenfalls wieder freigegeben werden. Neue Sitzung einrichten gnutls_init(&session, GNUTLS_CLIENT); Informationen über den Server in die neue Sitzung übernehmen gnutls_credentials_set(...) Informationen über den Clienten in die neue Sitzung übernehmen gnutls_credentials_set(...) [...] Sitzungsspeicher wieder freigeben gnutls_deinit (session); Abb. 3.15: Für den handshake erforderliche Informationen Aushandlung der erlaubten cipher suites und Protokolle Nach der Initialisierung der Sitzung müssen die Einstellungen für die erlaubten cipher suites vorgenommen werden. Damit werden die Verschlüsselungsverfahren und weitere Einstellungen angegeben. Laut [7] wird für TLS in Verbindung mit POP als Mindestvoraussetzung die chiper suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA vorausgesetzt. Andere chiper suites können alternativ verwendet werden, falls der Kommunikationspartner ebenfalls über die gleiche alternative chiper suite verfügt. Bevor der handshake durchgeführt werden kann, müssen als letztes noch das eingerichtete Socket mit der aktuellen TLS-Sitzung verknüpft werden (Erinnerung: Es können mehrere verschlüsselte Verbindungen gleichzeitig zu und von einem Computer existieren). Dazu wird die Nummer des eingerichteten Sockets mittels gnutls_transport_set_ptr (...) in die Struktur session geschrieben. Nach dem Auslesen der Socketnummer muss hierbei wie - Seite 52 -

53 so oft evtl. noch eine Typkonvertierung mit Hilfe des Umwandlungsoperators () vorgenommen werden. Die Funktion gnutls_transport_set_ptr (...) eignet sich nur für das TCP- Protokoll. Für andere Protokolle müssen andere Funktionen herangezogen werden. Bevorzugte chiper suite angeben gnutls_priority_set_direct (...) Sichere Sitzung mit zuvor eingerichtetem Socket verknüpfen gnutls_transport_set_ptr(...) Weiter mit handshake Abb. 3.16: Angabe der zu bevorzugenden chiper suite sowie die Verknüpfung der Sitzung mit dem Socket handshake durchführen Sind alle vorausgegangenen Parameter und Beziehungen in der Struktur session geklärt und verknüpft, kann jetzt der handshake mittels dem Funktionsaufruf gnutls_handshake (...) durchgeführt werden. Erst mit Hilfe dieser Funktion findet der tatsächliche Schlüsselaustausch zwischen Client und Server und damit der verschlüsselte Verbindungsaufbau statt Datentransfer Hat man die verschlüsselte Verbindung erfolgreich aufgebaut, können nun Daten verschlüsselt zwischen Server und Client übertragen werden. Unverschlüsselt dienten dazu die gewöhlichen Funktionen write(...) (senden) und read(...) (empfangen) der Standard C Library. Für das verschlüsselte Senden und Empfangen werden von GnuTLS eigene Funktionen bereitgestellt. Sie kümmern sich selbst um das Ver- und Entschlüsseln der Daten. Für das verschlüsselte Senden existiert die Funktion gnutls_record_send (...), und für das Empfangen gnutls_record_recv (...). Die zu sendenden Daten werden im - Seite 53 -

54 Klartext der Funktion gnutls_record_send (...) übergeben, und die empfangenen Daten ebenfalls im Klartext von der Funktion gnutls_record_recv (...) dem restlichen Programm bereitgestellt Verschlüsselte Verbindung sicher beenden Mit Hilfe der Funktion gnutls_bye (...) kann dem Kommunikationspartner (in unserem Fall der POP-Server) auf sicherem Wege mitgeteilt werden, dass die (verschlüsselte) Verbindung aufgelöst werden soll. Damit lässt sich ein beabsichtigtes Beenden von Seiten des Kommunikationspartners von einer arglistigen Unterbrechung unterscheiden. Wird die TCP-Verbindung nicht mehr gebraucht, kann das Socket mit close (...) aufgelöst, der von der aktuellen Sitzung belegte Speicher mit gnutls_deinit (...) sowie der von den Ausweispapieren von Client und Server belegte Datenspeicher mittels gnutls_srp_free_client_credentials (...) und gnutls_certificate_free_credentials (...) wieder freigegeben und ganz zum Schluss noch GnuTLS mit gnutls_global_deinit (...) ordnungsgemäß beendet werden Durchführung einer TLS-Sitzung In Abb auf Seite 56 ist das Ergebnis der vorliegenden Arbeit zu sehen. Es handelt sich dabei um das in Anhang A aufgeführte Programm. Im folgenden wird Abb näher erläutert: Mit./cert7b wird das Programm gestartet. Dann werden die notwendigen Daten zum Verbindungsaufbau eingegeben: Server: mail.fh-landshut.de User: aaussers Password: Das Passwort wird eingegeben, aber zur Sicherheit nicht am Bildschirm ausgegeben. Anschließend wird der eingegebene Hostname mail.fh-landshut.de mittels DNS in seine IP-Adresse aufgelöst, in ASCII-Codierung umgewandelt und letztere zusätzlich am Bildschirm ausgegeben: IP: Die Meldung +OK Dovecot ready. wird bereits vom Mailserver der Hochschule Landshut empfangen. Ab dieser Zeile ist also bereits eine Verbindung zum Mailserver hergestellt. - Seite 54 -

55 Danach werden mittels STARTTLS die Fähigkeiten (Befehl CAPA, engl. capabilities) des Mailservers abgerufen und ebenfalls am Bildschirm ausgegeben: CAPA TOP UIDL RESP-CODES PIPELINING STLS SASL An dieser Stelle soll uns nur der Befehl STLS interessieren. Er bedeutet, dass mittels ihm eine TLS-Sitzung (verschlüsselte Verbindung) gestartet werden kann. Dies wurde in Zeile (Abb. 3.17) +OK Begin TLS negotiation now. bereits getan. Anschließend erfolgt die Verarbeitung der vom Mailserver empfangenen Zertifikate: Anzahl der Verarbeiteten Zertifikate: 3 Der Mailserver der Hochschule Landshut hat damit drei Zertifikate geschickt. Diese drei empfangenen Zertifikate sind in Abb. 2.6 auf Seite 25 zu sehen: Es handelt sich dabei um das Zertifikat der Hochschule Landshut, das Zertifikat des Deutschen Forschungsnetzes sowie das Wurzelzertifikat der Deutschen Telekom (in dieser Reihenfolge). Mit Ausgabe der Meldung Herstellung der verschluesselten Verbindung erfolgreich. wurde der handshake erfolgreich durchgeführt. Ab hier läuft der komplette Datenverkehr einschließlich aller POP3-Befehle zwischen Client und Mailserver der Hochschule Landshut verschlüsselt. Nun befindet sich das System im Authentifizierungszustand des eigentlichen POP3-Servers. Der Client schickt den POP3-Befehl USER aaussers und empfängt vom Mailserver die Meldung 5 Bytes empfangen: +OK - Seite 55 -

56 Anschließend wird mittels PASS <password> das Passwort gesendet. Der Server gibt die Meldung 16 Bytes empfangen: +OK Logged in. zurück. Nun kann man z. B. seine s abrufen oder löschen. Im Programm wird die erste im Postfach enthaltene mittels dem POP3-Befehl RETR 1 abgerufen. Die ersten 1024 Bytes davon werden vom Programm entgegengenommen und anschließend am Bildschirm ausgegeben. Zu sehen ist in Abb deshalb nur ein Teil des Kopfes (engl. header) mit den Transportinformationen, der üblicherweise dem Leser einer verborgen bleibt. Danach wird die komplette Verbindung zum Mailserver ordnungsgemäß beendet und zur Kommandozeile zurückgekehrt. Abb. 3.17: Erfolgreiches Abrufen einer über eine mittels TLS verschlüsselten Datenverbindung (Listing cert.c) - Seite 56 -

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

IT-Sicherheit: Kryptographie. Asymmetrische Kryptographie

IT-Sicherheit: Kryptographie. Asymmetrische Kryptographie IT-Sicherheit: Kryptographie Asymmetrische Kryptographie Fragen zur Übung 5 C oder Java? Ja (gerne auch Python); Tips waren allerdings nur für C Wie ist das mit der nonce? Genau! (Die Erkennung und geeignete

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Emailverschlüsselung mit Thunderbird

Emailverschlüsselung mit Thunderbird Emailverschlüsselung mit Thunderbird mit einer kurzen Einführung zu PGP und S/MIME Helmut Schweinzer 3.11.12 6. Erlanger Linuxtag Übersicht Warum Signieren/Verschlüsseln Email-Transport Verschlüsselung

Mehr

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine)

Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen. Public-Key-Kryptographie (2 Termine) Digital Rights Management (DRM) Verfahren, die helfen Rechte an virtuellen Waren durchzusetzen Vorlesung im Sommersemester 2010 an der Technischen Universität Ilmenau von Privatdozent Dr.-Ing. habil. Jürgen

Mehr

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo Kryptographische Verfahren zur Datenübertragung im Internet Patrick Schmid, Martin Sommer, Elvis Corbo 1. Einführung Übersicht Grundlagen Verschlüsselungsarten Symmetrisch DES, AES Asymmetrisch RSA Hybrid

Mehr

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner Adressübersetzung und Tunnelbildung Bastian Görstner Gliederung 1. NAT 1. Was ist ein NAT 2. Kategorisierung 2. VPN 1. Was heißt VPN 2. Varianten 3. Tunneling 4. Security Bastian Görstner 2 NAT = Network

Mehr

RSA Verfahren. Kapitel 7 p. 103

RSA Verfahren. Kapitel 7 p. 103 RSA Verfahren RSA benannt nach den Erfindern Ron Rivest, Adi Shamir und Leonard Adleman war das erste Public-Key Verschlüsselungsverfahren. Sicherheit hängt eng mit der Schwierigkeit zusammen, große Zahlen

Mehr

Was ist Kryptographie

Was ist Kryptographie Was ist Kryptographie Kryptographie Die Wissenschaft, mit mathematischen Methoden Informationen zu verschlüsseln und zu entschlüsseln. Eine Methode des sicheren Senden von Informationen über unsichere

Mehr

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen

Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Content-Verwertungsmodelle und ihre Umsetzung in mobilen Systemen Digital Rights Management 4FriendsOnly.com Internet Technologies AG Vorlesung im Sommersemester an der Technischen Universität Ilmenau

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Grundlagen der Kryptographie

Grundlagen der Kryptographie Grundlagen der Kryptographie Seminar zur Diskreten Mathematik SS2005 André Latour a.latour@fz-juelich.de 1 Inhalt Kryptographische Begriffe Primzahlen Sätze von Euler und Fermat RSA 2 Was ist Kryptographie?

Mehr

1. Asymmetrische Verschlüsselung einfach erklärt

1. Asymmetrische Verschlüsselung einfach erklärt 1. Asymmetrische Verschlüsselung einfach erklärt Das Prinzip der asymmetrischen Verschlüsselung beruht im Wesentlichen darauf, dass sich jeder Kommunikationspartner jeweils ein Schlüsselpaar (bestehend

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden Vorwort In unserem elektronischen Zeitalter erfolgt der Austausch von Informationen mehr und mehr über elektronische Medien wie zum Beispiel

Mehr

Einführung in Computer Microsystems

Einführung in Computer Microsystems Einführung in Computer Microsystems Kapitel 9 Entwurf eines eingebetteten Systems für Anwendungen in der IT-Sicherheit Prof. Dr.-Ing. Sorin A. Huss Fachbereich Informatik Integrierte Schaltungen und Systeme

Mehr

SSL/TLS: Ein Überblick

SSL/TLS: Ein Überblick SSL/TLS: Ein Überblick Wie funktioniert das sichere Internet? Dirk Geschke Linux User Group Erding 28. März 2012 Dirk Geschke (LUG-Erding) SSL/TLS 28. März 2012 1 / 26 Gliederung 1 Einleitunng 2 Verschlüsselung

Mehr

Die Idee des Jahres 2013: Kommunikation verschlüsseln

Die Idee des Jahres 2013: Kommunikation verschlüsseln Die Idee des Jahres 2013: Kommunikation verschlüsseln Kommunikationsschema bei Email MailServer MailServer Internet PC PC Sender Empfänger Verschlüsselung ist... immer eine Vereinbarung zwischen zwei Kommunikationspartnern:

Mehr

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Agenda 1. Kerckhoff sches Prinzip 2. Kommunikationsszenario 3. Wichtige Begriffe 4. Sicherheitsmechanismen 1. Symmetrische Verschlüsselung

Mehr

Kryptographie. nur mit. Freier Software!

Kryptographie. nur mit. Freier Software! Michael Stehmann Kryptographie nur mit Freier Software! Kurze Einführung in Kryptographie ErsterTeil: Bei der Kryptographie geht es um die Zukunft von Freiheit und Demokratie Artur P. Schmidt, 1997 http://www.heise.de/tp/artikel/1/1357/1.html

Mehr

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen Immo FaUl Wehrenberg immo@ctdo.de Chaostreff Dortmund 16. Juli 2009 Immo FaUl Wehrenberg immo@ctdo.de (CTDO) SSL/TLS Sicherheit

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Verschlüsselungsverfahren

Verschlüsselungsverfahren Verschlüsselungsverfahren Herrn Breder hat es nach dem Studium nach München verschlagen. Seine Studienkollegin Frau Ahrend wohnt in Heidelberg. Da beide beruflich sehr stark einspannt sind, gibt es keine

Mehr

Vortrag Keysigning Party

Vortrag Keysigning Party Vortrag Keysigning Party Benjamin Bratkus Fingerprint: 3F67 365D EA64 7774 EA09 245B 53E8 534B 0BEA 0A13 (Certifcation Key) Fingerprint: A7C3 5294 E25B B860 DD3A B65A DE85 E555 101F 5FB6 (Working Key)

Mehr

Homomorphe Verschlüsselung

Homomorphe Verschlüsselung Homomorphe Verschlüsselung Sophie Friedrich, Nicholas Höllermeier, Martin Schwaighofer 11. Juni 2012 Inhaltsverzeichnis Einleitung Motivation Mathematische Definitionen Wiederholung Gruppe Ring Gruppenhomomorphisums

Mehr

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis Wie Interoperabel ist IPsec? Ein Erfahrungsbericht Arturo Lopez Senior Consultant März 2003 Agenda Internet Protokoll Security (IPsec) implementiert Sicherheit auf Layer 3 in OSI Modell Application Presentation

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

Datensicherheit durch Kryptographie

Datensicherheit durch Kryptographie Datensicherheit durch Kryptographie Dr. Michael Hortmann Fachbereich Mathematik, Universität Bremen T-Systems Michael.Hortmann@gmx.de 1 Kryptographie: Klassisch: Wissenschaft und Praxis der Datenverschlüsselung

Mehr

Seminar Internet-Technologie

Seminar Internet-Technologie Seminar Internet-Technologie Zertifikate, SSL, SSH, HTTPS Christian Kothe Wintersemester 2008 / 2009 Inhalt Asymmetrisches Kryptosystem Digitale Zertifikate Zertifikatsformat X.509 Extended-Validation-Zertifikat

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer

Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer Das RSA-Verschlüsselungsverfahren 1 Christian Vollmer Allgemein: Das RSA-Verschlüsselungsverfahren ist ein häufig benutztes Verschlüsselungsverfahren, weil es sehr sicher ist. Es gehört zu der Klasse der

Mehr

Stammtisch 04.12.2008. Zertifikate

Stammtisch 04.12.2008. Zertifikate Stammtisch Zertifikate Ein Zertifikat ist eine Zusicherung / Bestätigung / Beglaubigung eines Sachverhalts durch eine Institution in einem definierten formalen Rahmen 1 Zertifikate? 2 Digitale X.509 Zertifikate

Mehr

9 Schlüsseleinigung, Schlüsselaustausch

9 Schlüsseleinigung, Schlüsselaustausch 9 Schlüsseleinigung, Schlüsselaustausch Ziel: Sicherer Austausch von Schlüsseln über einen unsicheren Kanal initiale Schlüsseleinigung für erste sichere Kommunikation Schlüsselerneuerung für weitere Kommunikation

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

Verschlüsselung mit PGP (Pretty Good Privacy)

Verschlüsselung mit PGP (Pretty Good Privacy) Verschlüsselung mit PGP (Pretty Good Privacy) Funktionsweise, Installation, Konfiguration, Benutzung und Integration in EMail-Clients Referent: Dominique Petersen email@dominique-petersen.com Linux User

Mehr

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat?

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? 1 / 32 Veranstaltungsreihe Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? Veranstalter sind: 15. Mai bis 3. Juli 2008 der Arbeitskreis Vorratsdatenspeicherung

Mehr

Linux-Info-Tag Dresden - 8. Oktober 2006

Linux-Info-Tag Dresden - 8. Oktober 2006 E-Mails signieren & verschlüsseln Linux-Info-Tag Dresden - 8. Oktober 2006 1 Einleitung 1.1 Willkommen Karl Deutsch Österreich Seit 1985 im IT-Bereich Seit 1997 Linux als Desktopbetriebssystem IT Berater

Mehr

Probabilistische Primzahlensuche. Marco Berger

Probabilistische Primzahlensuche. Marco Berger Probabilistische Primzahlensuche Marco Berger April 2015 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung 4 1.1 Definition Primzahl................................ 4 1.2 Primzahltest...................................

Mehr

Kryptographie praktisch erlebt

Kryptographie praktisch erlebt Kryptographie praktisch erlebt Dr. G. Weck INFODAS GmbH Köln Inhalt Klassische Kryptographie Symmetrische Verschlüsselung Asymmetrische Verschlüsselung Digitale Signaturen Erzeugung gemeinsamer Schlüssel

Mehr

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

Methoden der Kryptographie

Methoden der Kryptographie Methoden der Kryptographie!!Geheime Schlüssel sind die sgrundlage Folien und Inhalte aus II - Der Algorithmus ist bekannt 6. Die - Computer Networking: A Top außer bei security by obscurity Down Approach

Mehr

Ein Überblick über Security-Setups von E-Banking Websites

Ein Überblick über Security-Setups von E-Banking Websites Ein Überblick über Security-Setups von E-Banking Websites Stefan Huber www.sthu.org Linuxwochen Linz 2015 31. Mai 2015 Basierend auf Testergebnissen vom 28.03.2015 aus https://www.sthu.org/blog/11-tls-dnssec-ebanking/

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

IT-Sicherheit: Übung 6

IT-Sicherheit: Übung 6 IT-Sicherheit: Übung 6 Zertifikate, Kryptographie (Diffie-Hellman), Sicherheitsprotokolle (SSL/TLS) Zertifikate! Problem: Woher weiß Bob, dass K E Alice zu Alice gehört?! Persönlicher Austausch des öffentlichen

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

Online Banking. de Lorenzo, Hopfgartner, Leupold. February 13, 2011. de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29

Online Banking. de Lorenzo, Hopfgartner, Leupold. February 13, 2011. de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29 Online Banking de Lorenzo, Hopfgartner, Leupold February 13, 2011 de Lorenzo, Hopfgartner, Leupold Online Banking February 13, 2011 1 / 29 Übersicht Geschichte Bedenken Verschlüsselungsarten Netzwerkarchitektur

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover

UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover UH-CA: Zertifikate für digitale Signaturen und Verschlüsselung an der Universität Hannover Sicherheitstage WS 04/05 Birgit Gersbeck-Schierholz, RRZN Einleitung und Überblick Warum werden digitale Signaturen

Mehr

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase

Verteilte Systeme. Sicherheit. Prof. Dr. Oliver Haase Verteilte Systeme Sicherheit Prof. Dr. Oliver Haase 1 Einführung weitere Anforderung neben Verlässlichkeit (zur Erinnerung: Verfügbarkeit, Zuverlässigkeit, Funktionssicherheit (Safety) und Wartbarkeit)

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

E-Mails versenden aber sicher!

E-Mails versenden aber sicher! E-Mails versenden aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Dateien und EMails verschlüsseln mit GPG

Dateien und EMails verschlüsseln mit GPG Dateien und EMails verschlüsseln mit GPG Linuxwochen Linz 2013 Mario Koppensteiner June 16, 2013 Table of contents Theorie Software was man braucht Schlüssel erstellen Schlüsselserver Beispiele Fragen

Mehr

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt April 2011 Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt 1. Einleitung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen Netze leicht mitlesen oder verändern.

Mehr

Wiederholung: Informationssicherheit Ziele

Wiederholung: Informationssicherheit Ziele Wiederholung: Informationssicherheit Ziele Vertraulichkeit: Schutz der Information vor unberechtigtem Zugriff bei Speicherung, Verarbeitung und Übertragung Integrität: Garantie der Korrektheit (unverändert,

Mehr

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012

IT-Sicherheit WS 2012/13. Übung 5. zum 28. November 2012 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2012/13 Übung 5 zum 28. November 2012 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 X.509-Zertifikate Zertifikate nach dem X.509-Standard

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Kurze Einführung in kryptographische Grundlagen.

Kurze Einführung in kryptographische Grundlagen. Kurze Einführung in kryptographische Grundlagen. Was ist eigentlich AES,RSA,DH,ELG,DSA,DSS,ECB,CBC Benjamin.Kellermann@gmx.de GPG-Fingerprint: D19E 04A8 8895 020A 8DF6 0092 3501 1A32 491A 3D9C git clone

Mehr

Netzwerksicherheit Übung 5 Transport Layer Security

Netzwerksicherheit Übung 5 Transport Layer Security Netzwerksicherheit Übung 5 Transport Layer Security Tobias Limmer, Christoph Sommer, David Eckhoff Computer Networks and Communication Systems Dept. of Computer Science, University of Erlangen-Nuremberg,

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Authentikation und digitale Signatur

Authentikation und digitale Signatur TU Graz 23. Jänner 2009 Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Überblick: Begriffe Authentikation Digitale Signatur Begriffe Alice und

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

PKI Was soll das? LugBE. Public Key Infrastructures - PKI

PKI Was soll das? LugBE. Public Key Infrastructures - PKI Key Infrastructures - PKI PKI Was soll das? K ennt jemand eine nette G rafik z u PKI s? LugBE 23. März 2006 Markus Wernig Einleitung Symmetrisch vs. asymmetrisch Trusted Third Party Hierarchisches Modell

Mehr

Sicher Surfen IV: Verschlüsselung & Kryptographie

Sicher Surfen IV: Verschlüsselung & Kryptographie Sicher Surfen IV: Verschlüsselung & Kryptographie Georg Wagner 25. Mai 2001 1 Was ist Kryptographie? Kryptographie ist aus den griechischen Wörtern für Verstecken und Schreiben zusammengesetzt und kann

Mehr

Signieren und Verschlüsseln mit Outlook 2013

Signieren und Verschlüsseln mit Outlook 2013 Anleitung: Von Tobias Neumayer (support@thi.de) MAIL-VERSCHLÜSSELUNG / SIGNIERUNG Einführung Die meisten Mailprogramme unterstützen den Umgang mit S/MIME-Zertifikaten zur Verschlüsselung bzw. Signierung

Mehr

Martin Vorländer PDV-SYSTEME GmbH

Martin Vorländer PDV-SYSTEME GmbH SSH - eine Einführung Martin Vorländer PDV-SYSTEME GmbH Das Problem TCP/IP-Dienste (z.b. Telnet, FTP, POP3, SMTP, r Services, X Windows) übertragen alle Daten im Klartext - auch Passwörter! Es existieren

Mehr

Verschlüsselung und Signatur

Verschlüsselung und Signatur Verschlüsselung und Signatur 1 Inhalt Warum Verschlüsseln Anforderungen und Lösungen Grundlagen zum Verschlüsseln Beispiele Fragwürdiges rund um das Verschlüsseln Fazit Warum verschlüsseln? Sichere Nachrichtenübertragung

Mehr

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR

Sicherheitskonzept und Sicherheitspru fung. Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Sicherheitskonzept und Sicherheitspru fung Internetanbindung Befundserver MVZ Labor PD Dr. Volkmann und Kollegen GbR Einführung Die Firma MVZ Labor PD Dr. Volkmann und Kollegen GbR, nachstehend als Labor

Mehr

Mehr Sicherheit durch PKI-Technologie

Mehr Sicherheit durch PKI-Technologie Mehr Sicherheit durch PKI-Technologie Verschlüsselung allgemein Die 4 wichtigsten Bedingungen Bei einer Übertragung von sensiblen Daten über unsichere Netze müssen folgende Bedingungen erfüllt sein: Vertraulichkeit

Mehr

Verschlüsselung, Signaturen und Zertifikate

Verschlüsselung, Signaturen und Zertifikate Verschlüsselung, Signaturen und Zertifikate 1) Einführung Wenn eine Benutzerin Alice eine Nachricht sicher übertragen will, müssen folgende Bedingungen erfüllt sein: a) Niemand soll Alices Nachricht lesen

Mehr

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch

Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen. Fabian Pretsch Bewertung der Einsatzmöglichkeiten von XML Sicherheitslösungen in mobilen Kommunikationsumgebungen Fabian Pretsch Ziel Implementierung von XML Encryption/Signature in Java Testen der Implementierung auf

Mehr

Seminar Neue Techologien in Internet und WWW

Seminar Neue Techologien in Internet und WWW Seminar Neue Techologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Christian Raschka chrisra@informatik.uni-jena.de Seminar Neue Internettechnologien

Mehr

OpenChaos-Reihe Digitale VerhütungTeil 2: Sichere Kommunikation

OpenChaos-Reihe Digitale VerhütungTeil 2: Sichere Kommunikation OpenChaos-Reihe Digitale Verhütung Teil 2: Sichere Kommunikation Chaos Computer Club Cologne e.v. http://koeln.ccc.de Köln 25.10.2007 Gliederung 1 Warum Kommunikationsverschlüsselung? 2 Praxis 3 Letzte

Mehr

Empfehlungen für den sicheren Einsatz. SSL-verschlüsselter Verbindungen. Dipl.-Inform. Lars Oergel Technische Universität Berlin. 13.

Empfehlungen für den sicheren Einsatz. SSL-verschlüsselter Verbindungen. Dipl.-Inform. Lars Oergel Technische Universität Berlin. 13. Empfehlungen für den sicheren Einsatz SSL-verschlüsselter Verbindungen Dipl.-Inform. Lars Oergel Technische Universität Berlin 13. Januar 2014 1 Motivation Edward Snowden: Encryption works. Properly implemented

Mehr

IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie

IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie IT-Sicherheitsmanagement Teil 8: Einführung in die Kryptographie 28.04.15 1 Literatur I mit ein paar Kommentaren [8-1] Burnett, Steve; Paine, Spephen: Kryptographie. RSA Security s Official Guide. RSA

Mehr

Anlage 3 Verfahrensbeschreibung

Anlage 3 Verfahrensbeschreibung Anlage 3 Verfahrensbeschreibung Stand September 2015 1 INHALTSVERZEICHNIS 1 EINLEITUNG... 2 2 SYSTEMVORAUSSETZUNGEN... 3 2.1 Technische Voraussetzung beim Kunden... 3 2.2 Ausstattung des Clients... 3 3

Mehr

Lenstras Algorithmus für Faktorisierung

Lenstras Algorithmus für Faktorisierung Lenstras Algorithmus für Faktorisierung Bertil Nestorius 9 März 2010 1 Motivation Die schnelle Faktorisierung von Zahlen ist heutzutage ein sehr wichtigen Thema, zb gibt es in der Kryptographie viele weit

Mehr

Linux User Group Tübingen

Linux User Group Tübingen theoretische Grundlagen und praktische Anwendung mit GNU Privacy Guard und KDE Übersicht Authentizität öffentlicher GNU Privacy Guard unter KDE graphische Userinterfaces:, Die dahinter

Mehr

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur.

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur. Referat im Proseminar Electronic Commerce Thema: Anwendungen von Kryptographie für E-Commerce Betreuer: Michael Galler Stoffsammlung/Grobgliederung Problem der Sicherheit des E-Commerce - nötig für Sicherheitsgarantie:

Mehr

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Remote Tools SSH SCP Proxy SFTP Port X11 christina.zeeh@studi.informatik.uni-stuttgart.de Grundlagen SSH Inhalt Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Verschlüsselung und elektronische Signaturen. Joerg.Schulenburg_at_ovgu.de. 11.10.2008 Magdeburger Open Source Tag 1

Verschlüsselung und elektronische Signaturen. Joerg.Schulenburg_at_ovgu.de. 11.10.2008 Magdeburger Open Source Tag 1 GnuPG Verschlüsselung und elektronische Signaturen Verschlüsselung und elektronische Signaturen Joerg.Schulenburg_at_ovgu.de 11.10.2008 Magdeburger Open Source Tag 1 GnuPG Verschlüsselung und elektronische

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

SelfLinux-0.12.3. Glossar. Autor: Mike Ashley () Formatierung: Matthias Hagedorn (matthias.hagedorn@selflinux.org) Lizenz: GFDL

SelfLinux-0.12.3. Glossar. Autor: Mike Ashley () Formatierung: Matthias Hagedorn (matthias.hagedorn@selflinux.org) Lizenz: GFDL Glossar Autor: Mike Ashley () Formatierung: Matthias Hagedorn (matthias.hagedorn@selflinux.org) Lizenz: GFDL Glossar Seite 2 1 Glossar 1.1 3DES Triple DES. Symmetrischer Verschlüsselungsalgorithmus, der

Mehr

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de

Rosa Freund SSL/TLS 26.10.2005 SSL/TLS 26.10.2005. Institut für Mathematik, TU Berlin. Rosa Freund -- rosa@pool.math.tu-berlin.de 1 SSL/TLS 26.10.2005 Institut für Mathematik, TU Berlin Rosa Freund -- rosa@pool.math.tu-berlin.de 2 Übersicht Einführung SSL vs. TLS SSL: Anwendung und PKI SSL Protokoll: Record Protocol und Handshake

Mehr

Einführung in die symmetrische und asymmetrische Verschlüsselung

Einführung in die symmetrische und asymmetrische Verschlüsselung Einführung in die symmetrische und asymmetrische Verschlüsselung Enigmail Andreas Grupp grupp@elektronikschule.de Download der Präsentation unter http://grupp-web.de by A. Grupp, 2007-2010. Dieses Werk

Mehr

1 Kryptosysteme 1 KRYPTOSYSTEME. Definition 1.1 Eine Kryptosystem (P(A), C(B), K, E, D) besteht aus

1 Kryptosysteme 1 KRYPTOSYSTEME. Definition 1.1 Eine Kryptosystem (P(A), C(B), K, E, D) besteht aus 1 RYPTOSYSTEME 1 ryptosysteme Definition 1.1 Eine ryptosystem (P(A), C(B),, E, D) besteht aus einer Menge P von lartexten (plaintext) über einem lartextalphabet A, einer Menge C von Geheimtexten (ciphertext)

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 mit den eingetragenen Materialnummern Inhalt Inhalt... 2 1 Vorwort... 3 2 Allgemeines zur Verschlüsselung...

Mehr

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

5. Übung zum G8-Vorkurs Mathematik (WiSe 2011/12)

5. Übung zum G8-Vorkurs Mathematik (WiSe 2011/12) Technische Universität München Zentrum Mathematik PD Dr. hristian Karpfinger http://www.ma.tum.de/mathematik/g8vorkurs 5. Übung zum G8-Vorkurs Mathematik (WiSe 2011/12) Aufgabe 5.1: In einer Implementierung

Mehr