Pretty Good Privacy Usability im Web of Trust

Masterarbeit

Zur Erlangung des akademischen Grades

Master of Science in Engineering

der Fachhochschule FH Campus Wien Masterstudiengang IT-Security Jahrgang ITS16

Vorgelegt von: Daniel Buchberger

Personenkennzeichen 1410537028

Erstbegutachter: DI Dr. Martin Schmiedecker

Zweitbegutachterin: DI Katharina Krombholz

Eingereicht am: 28. 07. 2017

Erklärung:

Ich erkläre, dass die vorliegende Masterarbeit von mir selbst verfasst wurde und ich keine anderen als die angeführten Behelfe verwendet bzw. mich auch sonst keiner unerlaubter Hilfe bedient habe. Ich versichere, dass ich diese Masterarbeit bisher weder im In- noch im Ausland (einer Beurteilerin/einem Beurteiler zur Begutachtung) in irgendeiner Form als Prüfungsarbeit vorgelegt habe. Weiters versichere ich, dass die von mir eingereichten Exemplare (ausgedruckt und elektronisch) identisch sind.

Datum: ...... Unterschrift: ......

Danksagung

Zunächst möchte ich mich an dieser Stelle bei meinen Eltern, Hermann und Barbara Buchberger für die tatkräftige Unterstützung und Motivation während der Anfertigung dieser Arbeit und des gesamten Studiums bedanken. Daneben gilt mein Dank Herrn DI Dr. Martin Schmiedecker , da er meine Arbeit und somit auch mich betreut, mir mit wertvollen Ratschlägen und Hinweisen geholfen und mit moralischer Unterstützung durch diese Arbeit begleitet, hat. Ebenfalls möchte ich mich bei meinen Studienkollegen und Freunden Carina Kloibhofer, Nenad Milanovic und Rudolf Toro für die außerordentliche Gemeinschaft, Humor und gegenseitige Unterstützung bedanken. Zuletzt möchte ich meinen Freunden, im Besonderen Matthias Klettner und Ronald Peer, für die Hilfestellung und die Mitwirkung dieser Masterarbeit meinen Dank aussprechen.

i

Kurzfassung

Sowohl für den einfachen Privatanwender, als auch für Unternehmen jeglicher Größe ist der Schutz von vertraulichen Daten von grundlegender Bedeutung und vor allem im Bereich der IT hat dieser Aspekt, in den letzten Jahren, enorm an Gewichtung gewonnen. Einen besonders interessanten Ansatz für die Realisierung einer verschlüsselten und sicheren Kommunikation bietet das Konzept des Web of Trusts sowie die darauf basierende Software Pretty Good Privacy. Ziel der vorliegenden Masterarbeit ist es dem Leser einen Einblick in die Thematik der Kryptographie, Public-Key-Verschlüsselungsverfahren und der als Vorreiter geltenden Verschlüsselungssoftware Pretty Good Privacy zu bieten. Gemeinsam mit dem Konzept des Web of Trusts werden diese Themen behandelt, um anschließend die potenziellen Schwächen solcher Verfahren aufzuzeigen. Ein weiteres Bestreben ist die Entwicklung einer Android-Applikation, welche als Hilfestellung für den Schlüsselaustausch von Benutzern dienen soll, gefolgt von einem Fazit der zukünftigen Entwicklung der behandelten Themengebiete.

ii

Abstract

For private users, as well as for companies, the protection of sensitive data is one of the key objectives and especially in the last years, the IT-security sector has gained in importance and prioritization. An interesting approach to realize an encrypted and secure communication is offered by the so called web of trust and the based on software Pretty Good Privacy. This thesis aims to give an insight into cryptography, public-key encryption and particularly the encryption program PGP. Another focus is the concept of a web of trust and the potential weaknesses of those implementations. Followed by the development of an android application, supporting the process of key exchanging. Conclusively a summary of all the covered topics and an outlook for future work and research will be given.

iii

Inhaltsverzeichnis

1. PGP 2

1.1. Funktionsumfang ...... 2 1.2. Schlüssel ...... 3 1.3. Web of Trust ...... 12 1.4. OpenPGP Implementierungen ...... 15 1.5. Geschichtlicher Hintergrund ...... 20 1.6. Schwächen von PGP ...... 24

2. APPLIKATION 33

2.1. Ziel der Applikation ...... 33 2.2. Alternativen zur Applikation ...... 33 2.3. Implementierung ...... 35 2.4. Benutzeroberflächen ...... 36 2.5. Standardszenario ...... 46 2.6. Anwendungsszenarien ...... 47

3. EVALUATION 50

3.1. Verfahren ...... 50 3.2. Funktions-Test ...... 50 3.3. Usability-Test ...... 51 3.4. Ergebnisse ...... 55

4. DISKUSSION UND FAZIT 64

ANHANG 66

GRUNDLAGEN 66

Kryptographie ...... 66 (Digitale) Zertifikate ...... 71

ABBILDUNGSVERZEICHNIS 75

LITERATURVERZEICHNIS 77

iv Einleitung

Einleitung Motivation Sicherheit hat sich in den letzten Jahren zu einer der wichtigsten Thematiken im Bereich der IT entwickelt. Es vergeht kaum ein Tag, an dem nicht wieder ein Artikel über einen Zero-Day-Exploit, einer weiteren Sicherheitslücke oder gar einem Angriff auf Computersysteme publiziert wird. Vor allem die vom ehemaligen CIA-Mitarbeiter Edward Snowden aufgedeckten Enthüllungen weckten das Interesse der Allgemeinheit für dieses Gebiet. Das Hauptaugenmerk eines jeden Nutzers obliegt dabei zumeist dem Schutz der eigenen Daten. Um dieses Ziel umzusetzen, behilft man sich der Kryptographie. Mit den als sicher geltenden Verfahren werden Daten, bei der Übertragung und auch bei der Speicherung, verschlüsselt, um die vier Hauptziele der Computersicherheit - Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit gewährleisten zu können. Besonders Public-Key- Verschlüsselungsverfahren erwiesen sich als wichtiger Bestandteil hierfür. Ein Vorreiter in diesem Bereich ist das von Phil Zimmermann entwickelte Programm Pretty Good Privacy, kurz PGP. Dieses 1991 veröffentlichte Programm ermöglicht die verschlüsselte End-to- End-Kommunikation zweier oder mehrerer User und wird noch heutzutage als sicher angesehen. PGP baut auf dem sogenannten Web of Trust, einem Prinzip, bei dem die zentrale Zertifizierungsstelle durch Vertrauensverbindungen der Benutzer selbst ersetzt wird, auf und ist darauf ausgelegt Nachrichten dauerhaft entschlüsseln zu können. In den letzten Jahren haben auch namentliche Firmen den Nutzen an einem solchen Prinzip erkannt und versuchen sich an ihrer eigenen Implementierung dessen. So ist zum Beispiel Mailvelope [MV16], eine freie Software die eine Ende-zu-Ende-Verschlüsselung von E-Mails ermöglicht ein neuer Ansatz der chiffrierten Kommunikation.

Ziel der Arbeit Ziel dieser Arbeit ist es dem Leser einen Einblick in Public-Key- Verschlüsselungsverfahren, im speziellen auf Pretty Good Privacy sowie die Funktionsweise eines Web of Trusts zu geben, die Schwächen und Stärken dieser aufzuarbeiten und die Entwicklung einer Android Applikation, die den Benutzer bei dem Vorgang des Schlüsselaustausches unterstützen soll. Beginnend mit einer Einsicht in die gängigsten Verfahren und einer Erläuterung der Grundtechniken, sowie die Geschichte PGPs wird kontinuierlich das benötigte Wissen vermittelt. Anschließend werden potenzielle Schwächen und Angriffe solcher Sicherheitsverfahren behandelt, gefolgt von der Entwicklung einer Applikation, die als Hilfestellung für den Schlüsselaustausch bei Keysigning-Partys dienen soll. Abschließend wird ein Fazit aller behandelten Thematiken und ein Ausblick für zukünftige Arbeiten abgegeben.

1 1. PGP

1. PGP 1.1. Funktionsumfang Pretty Good Privacy, ist ein Verschlüsselungsprogramm um die Privatsphäre von (persönlichen) Dateien und Mails zu schützen. Zusätzlich ermöglicht PGP das Signieren von Dateien, Nachrichten und Schlüsseln. Pretty Good Privacy und die Kryptographie an sich beschäftigen sich mit der Realisierung der drei Hauptziele der Informationssicherheit. Diese sind:

• Vertraulichkeit (Confidentiality) – Das erste Schutzziel Vertraulichkeit bezeichnet die Tatsache, dass lediglich autorisierte Personen Zugang zu den für sie bestimmten Daten haben. Dies wird anhand von Verschlüsselung, Passwörtern oder anderen Zugangskontrollen umgesetzt. • Integrität (Integrity) – Ein weiteres Ziel befasst sich mit der unbemerkten Modifizierung, der Richtigkeit und der Vollständigkeit von Daten. Integrität stellt nicht sicher, dass Daten nicht modifiziert werden können, sondern, dass diese nicht unbemerkt verändert werden können. • Verfügbarkeit (Availability) – Das dritte Ziel der Informationssicherheit stellt sicher, dass die Daten für die (autorisierten) Nutzer verfügbar sind.

Diese drei Ziele bilden zusammen das sogenannte CIA-Dreieck (CIA – Confidentiality, Integrity und Availability) der Informationssicherheit, welches mit weiteren Zielen ergänzt werden kann. Ein zusätzliches Schutzziel, welches eine wichtige Rolle in PGP spielt ist die Authentizität.

• Authentizität (Authenticity) – bezeichnet die Eigenschaft der Originalität eines Objektes. Im Allgemeinen versteht man unter Authentizität die Echtheit und Glaubwürdigkeit einer Person, einer Nachricht oder eines Objektes. Es soll möglichst sichergestellt werden, dass eine Person auch wirklich die Person ist, für die sie sich ausgibt.

PGP realisiert dieses Schutzziel mittels (digitaler) Signaturen: Ablauf der Sequenzen in OpenPGP: 1. die Nachricht wird erstellt 2. der Sender generiert, mittels OpenPGP, einen Hashwert der Nachricht 3. mittels des eigenen öffentlichen Schlüssels generiert der Sender eine Signatur des Hashwertes 4. die (binäre) Signatur wird an die ursprüngliche Nachricht angehängt 5. dabei behält die OpenPGP Software des Senders eine Kopie der Nachrichtensignatur 6. zum Verifizieren der Signatur generiert der Empfänger einen neuen Hashwert und vergleicht diesen mit den mitgesandten Wert. Stimmen beide Werte überein wird die Nachricht akzeptiert und gilt als authentisch. [NWG07]

2 1. PGP

Hybride Verschlüsselung Die Hybride Verschlüsselung ist eine Kombination der symmetrischen und der asymmetrischen Verschlüsselung, welche versucht die Vorteile beider Verfahren zu vereinen. Hierfür wird ein zufälliger symmetrischer Schlüssel, der sogenannte Sitzungsschlüssel (Session-Key) erstellt. Dieser Key wird nur einmalig für das symmetrische Verschlüsseln einer Nachricht verwendet. Anschließend wird der verwendete Sitzungsschlüssel mit Hilfe des öffentlichen Schlüssels des Empfängers asymmetrisch verschlüsselt und der Nachricht beigefügt (siehe Abbildung 3). Nach dem Übertragen der Daten entschlüsselt der Empfänger zunächst den Sitzungsschlüssel, mit seinem privaten Schlüssel, und folgend die eigentliche Nachricht. Da asymmetrische Verschlüsselungsverfahren sehr langsam sind und sich nicht für große Datenmengen eignen, wird bei der hybriden Verschlüsselung nur der Session-Key verschlüsselt um die Effizienz möglichst hoch zu halten. [Lin02]

Abb. 1: Hybride Verschlüsselung

1.2. Schlüssel 1.2.1. Schlüsselaufbau Anders als X.509 PKI Architekturen baut das PGP PKI System auf dem „Web of Trust“ auf um Identitäten mit Schlüssel zu verknüpfen. Da das PGP System keinerlei zentrale Zertifizierungsstelle benötigt werden alle zur Verifizierung eines Zertifikats benötigten Informationen und Attribute direkt im Schlüsselzertifikat hinterlegt. [VJ14] Ein PGP Schlüsselzertifikat, meist nur als Schlüssel bezeichnet, beinhaltet drei Hauptabschnitte. (siehe Abbildung 8) Der erste Abschnitt besteht aus dem öffentlichen Primärschlüssel und optionalen Paketen, notwendig für die Schlüsselwiderrufung. Der mittlere Abschnitt beinhaltet ein Set an Paketen zuständig für die User ID, die an den 3 1. PGP

Hauptschlüssel gebunden sind. Angefügt an ein jedes User ID Paket kann optional ein Set an Signatur-Pakete folgen. Jedes Signatur-Paket besteht aus einer Identität, einer Signatur der User ID, sowie dem öffentlichen Schlüssel des Signaturausstellers. Da ein jeder PGP Schlüssel eine Vielzahl von verknüpften User IDs und jede einzelne User ID über eine Sammlung von Signaturelemente verfügen kann, kann ein Schlüssel mit einer Menge von Identitäten, so zum Beispiel mehrere unterschiedliche E-Mail-Adressen derselben Person, von einer Sammlung von Personen signiert werden. Auf diesen Umständen beruht das Web-of-Trust. Der letzte Abschnitt eines Schlüssels ist optional und enthält eine Anzahl von Unterschlüssel. Oft verfügen diese Unterschlüssel nur über eine einzelne Funktion und finden entweder Einsatz bei der Verschlüsselung, bei der Signierung oder für die Authentifizierung. Eine wichtige Grundlage hierbei ist, dass ein jeder Unterschlüssel vom Primärschlüssel signiert ist. [VJ14]

Schlüssel-IDs und Fingerabdruck Ein Jeder Schlüssel verfügt über eine Schlüssel-ID und einen Fingerabdruck. Der Fingerabdruck (fingerprint) eines V3 Schlüssels wird aus dem Hashwerts des Schlüsselmaterials mittels MD5 generiert, wodurch dieser aus 16 Hexadezimalziffern besteht. Bei V4 Schlüssel bildet der 160-Bit SHA-1 Hashwert bestimmter Oktette des öffentlichen Schlüssels den Fingerabdruck. Dieser wird in Form von 20 Hexadezimalziffern notiert. Die jeweilige Schlüssel-ID eines Schlüssels besteht aus den letzten 64-Bit des Fingerabdrucks. [NWG07] Durch das Vergleichen des Fingerprints eines importierten Schlüssels mit dem Fingerprint, welcher dem Erzeuger in den Schlüsseleigenschaften angezeigt wird, durch z.B. ein Telefonat oder ein persönliches Treffen, kann sichergestellt werden, dass die beiden Schlüssel ident sind und die Authentizität des Schlüssels gegeben ist. Eine weitere Hilfeleistung bietet die Schlüssel- ID, welche aus den letzten 8 Stellen des digitalen Fingerabdrucks besteht. Dennoch sollte, falls möglich, der gesamte Fingerabdruck, samt User-ID und E-Mail-Adresse, überprüft werden. Da es problematisch sein kann eine Liste von Hexadezimal-Werte über ein Sprachmedium auszutauschen, liefern neuere Versionen von PGP Desktop zusätzlich zum digitalen Fingerabdruck einen biometrischen Fingerabdruck. Der biometrische Abdruck besteht aus 16 bzw. 20 Wörtern. Mittels einer Hexadezimalziffer lässt sich ein Wert von 0-255 darstellen. Dieser Wert wird beim biometrischen Fingerabdruck mit einem Wort aus einer Wortliste mit 256 unterschiedlichen Einträgen ersetzt und steht als Ersatz für den unhandlichen Wert.

4 1. PGP

Schlüsselstrukturen OpenPGP Schlüssel(zertifikate) ein OpenPGP V3 Schlüssel weist folgendes Format auf:

RSA Public Key [Revocation Self Signature] User ID [Signature ... ] [User ID [Signature ... ] ... ]

Eine jede Signatur zertifiziert den öffentlichen (RSA) Schlüssel sowie den jeweiligen Schlüsselbesitzer (User ID). Dabei kann ein jeder Schlüssel mehrere User IDs und Signaturen aufweisen.

V4 Schlüssel weisen den selben Aufbau wie V3 Schlüssel auf, doch die weiteren Schlüssel werden als Unterschlüssel (Subkeys) an den Primärschlüssel (Primary Key) angehängt

Primary-Key [Revocation Self Signature] [Direct Key Signature ... ] User ID [Signature ... ] [User ID [Signature ... ] [User Attribute [Signature ... ] ... ] [[Subkey [Binding-Signature-Revocation] Primary-Key-Binding Signature] ... ]

Ein jeder Unterschlüssel besitzt immer eine einzelne Signatur angehängt, welches mittels des Primärschlüssels erzeugt und verknüpft wird. (siehe Abbildung 9) Wird diese Signatur (Primary-Key-Binding Signature) widerrufen, wird der gesamte Unterschlüssel entfernt. Bei V4 Schlüsseln ist es möglich, dass die Unterschlüssel einen anderen Typ als der Primärschlüssel aufweisen. So kann ein DSA Primärschlüssel einen RSA Unterschlüssel oder auch einen Elgamal Unterschlüssel besitzen. Bei V3 Schlüsseln ist dies nicht möglich. [NWG07]

5 1. PGP

Vereinfachtes X.509 Schüsselzertifikat im Vergleich zu einem vereinfachten PGP Schlüsselzertifikat:

Abb. 2: x.509 vs PGP Certificate Structure – Quelle: [VJ14]

6 1. PGP

Subkeys Höchste Priorität obliegt bei einem jeden Public-Key-Verschlüsselungsverfahren der Geheimhaltung und dem Schutz des eigenen privaten Schlüssels. Sollte eine andere Person in den Besitz des privaten Schlüssels gelangen, so kann diese jeglichen verschlüsselten Datenaustausch entschlüsseln und sich zusätzlich für den originalen Schlüsselerzeuger ausgeben, mit dem Ziel andere User zu täuschen. Ebenso hätte ein Verlust des eigenen privaten Schlüssels weitere Maßnahmen zur Folge, wie die Notwendigkeit alle Kommunikationspartner über den Verlust zu informieren, den originalen Schlüssel zu widerrufen und die Verbreitung eines neuen öffentlichen Schlüssels um zukünftig wieder sicher kommunizieren zu können. Diese Schritte sollten schnellstmöglich umgesetzt werden um den potenziellen Schaden zu reduzieren. Beim Widerrufen eines Schlüssels gehen auch sämtliche bisher gesammelten Signaturen dessen verloren. Eine weitere Konsequenz, der sich User meist nicht bewusst sind, ist die Tatsache, dass mit dem privaten Schlüssel alle bisher getätigten verschlüsselten Kommunikationen entschlüsselt werden können. Aufgrund der fehlenden Forward Secrecy [siehe Kapitel 1.6 – Fehlende (Perfect) Forward Secrecy] kann ein Angreifer, welcher im Besitz des Schlüssels ist, jeglichen zuvor aufgezeichneten bzw. abgespeicherten chiffrierten Datenaustausch im Nachhinein entschlüsseln. Ein bewährtes Konzept um sich hiervor zu schützen, bieten Subkeys, zu Deutsch Unterschlüssel. Das Grundprinzip von Unterschlüssel ist recht einfach. Zunächst wird ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel erzeugt. Dieses Schlüsselpaar ist das master key pair. Hierbei ist essentiell, dass die Generierung des master key pairs auf einem sicheren Gerät durchgeführt und dieses unter allen Umständen geschützt wird. Anschließend wird ein oder werden mehrere Subkeys erzeugt. Diese Subkeys fungieren wie ein „normaler“ Schlüssel und können sowohl für Signiervorgänge, zum Authentifizieren, als auch zur Verschlüsselung verwendet werden, jedoch sind diese dem master key pair untergeordnet. Die master keys kommen nur bei administrativen Vorgängen, wie das Signieren des Schlüssels eines Kommunikationspartners, das Widerrufen einer Signatur, das Erstellen neuer Subkeys und weiteren Management-Aufgaben zum Einsatz. Oft wird das master key pair daher auf einem offline Datenspeicher abgelegt, vom Erstellgerät gelöscht, sicher aufbewahrt und nur bei Bedarf herangezogen. Bei der Verwendung von Subkeys ändert sich kaum etwas für den alltäglichen Gebrauch der Kryptographieverfahren. Nach wie vor wird ein Schlüssel zur Verschlüsselung von Daten herangezogen und einer oder mehrere unterschiedliche (Unter-)Schlüssel werden für das Signieren von Daten verwendet. Auch die Erstellung und Verwendung eines dritten Subkeys für Authentifizierungsvorgänge erweist sich oft als praktikabel. Somit ist ersichtlich, dass das Hauptaugenmerk der Erstellung und dem Einsatz von Subkeys darauf abzielt die Grundlegenden Aufgaben des Primärsschlüssel auf die Unterschlüssel zu übertragen. Die Vorteile von unterschiedlichen Schlüsseln sind ersichtlich, wenn ein Schlüssel kompromittiert worden ist oder verloren wurde. In solch einem Fall kann der Subkey unkompliziert widerrufen und ein neuer Schlüssel erstellt werden, ohne dass ein komplett neues master key pair erstellt werden muss. [RS17] Ebenfalls eignen sich unterschiedliche Subkeys hervorragend für unterschiedliche Anwendungsbereiche. So

7 1. PGP

kann ein Key, welcher auch auf einem mobilen Gerät, das leichter verloren gehen kann, wie dem Handy gespeichert ist, dazu verwendet werden um mit Freunden zu kommunizieren und um die versendeten Nachrichten zu signieren. Während ein weiterer Subkey, welcher sich nur auf dem abgesicherten Heimcomputer befindet, für geschäftliche Dokumente eingesetzt wird. Somit sind unterschiedliche Stufen von Sicherheitsgraden für verschiedenartige Szenarien realisierbar.

Abb. 3: Aufbau Unterschlüssel

Signieren eines Schlüssels Die erste Möglichkeit einen neuen öffentlichen Schlüssel zu verifizieren, bietet die persönliche Überprüfung bei einem Treffen mit dem Schlüsselinhaber. Oft ist dies jedoch nicht möglich bzw. nicht erwünscht, weshalb noch eine weitere Art der Verifizierung zur Verfügung angeboten wird. Dabei wird in das Überprüfen der Authentizität des Schüssels anderer Benutzer vertraut. Um genauer zu sein in die Signaturen anderer User. Mit dem Signieren eines Schlüssels, eines anderen Teilnehmers, bestätigt man, die Identität des Schlüsselbesitzers überprüft zu haben. In PGP wird dies mit dem Begriff Vertrauen (trust) bezeichnet. Wichtig hierbei ist, dass mit diesem Vertrauen die Legitimität der Identität einer Person und nicht deren Vertrauenswürdigkeit als Person bekräftigt wird. 8 1. PGP

Bevor man eine Signatur für einen Schlüssel erstellt, muss der Schlüsselinhaber folgende Punkte bereitstellen:

• den öffentlichen Schlüssel • die E-Mail-Adresse • den Fingerabdruck des Schlüssels • den Namen des Besitzers • einen Beweis seiner Identität

Aus Sicherheitsgründen sollten diese Werte über unterschiedliche Medien überliefert werden. So kann der Schlüssel von einem Keyserver stammen, der Fingerabdruck per Telefon übertragen und der Beweis in einer Mail versendet werden. Die Anforderungen für einen Identitätsnachweis variieren meist je nach Beziehung zum Schlüsselbesitzer und den zukünftigen Einsatzbereich der Schlüssel. So ist es einfacher einen Schlüssel eines Familienmitglieds oder eines Freundes zu authentifizieren, als den eines Fremden. [Luc06] Beim Signieren eines Schlüssels wird stets nur eine User ID signiert. Verfügt ein Schlüssel über mehrere User IDs und es ist erwünscht, dass alle signiert werden, müssen ebenfalls verschiedene Signaturen benötigt.

Schlüsselwiderruf Bei PGP geschieht das Widerrufen eines Schlüssels oder auch einer Signatur anhand sogenannter Widerrufszertifikate. Zur Erstellung eines solchen Zertifikates benötigt man den privaten Schlüssel. Somit ist es einem Benutzer nicht mehr möglich ein Widerrufszertifikat für sein Schlüsselpaar zu erstellen, sollte dieser das zugehörige Passwort vergessen haben. In der Regel werden Schlüssel widerrufen, wenn der private Schlüssel kompromittiert worden ist, man das Passwort vergessen hat oder man den Schlüssel bzw. ein Gerät auf dem sich der Schlüssel befindet verloren hat. Viele User erstellen bereits kurz nach der Schlüsselgenerierung ein Widerrufszertifikat um den Schlüssel auch bei einem Verlust des Schlüssels widerrufen zu können. Ist dies der Fall ist es wichtig, dass das Zertifikat, genauso wie der geheime Schlüssel an sich, geschützt aufbewahrt wird.

1.2.2. Schlüsselverwaltung Die bisherigen Kapitel gaben einen Einblick in die Funktionsweise von PGP und wie eine verschlüsselte Kommunikation zwischen zweier Parteien bewerkstelligt werden kann. Für dieses Ziel gibt es einige Voraussetzungen. So auch die Verteilung der öffentlichen Schlüssel. Die effektivste Vorgehensweise zur Veröffentlichung der Schlüssel sind Schlüsselserver (engl. Keyserver). Schlüsselserver speichern öffentliche Schlüssel mit allen dazugehörigen Parametern in einer Datenbank, um sie so der Öffentlichkeit zugänglich zu machen. Sie können als eine remote steuerbare Instanz von PGP angesehen werden. Ein jeder Benutzer kann auf einem Schlüsselserver nach einem Schlüssel suchen, einen oder mehrere Schlüssel importieren und nachfolgend eine verschlüsselte Kommunikation aufbauen. Alle öffentlichen Schlüsselserver gleichen ihre Datenbank regelmäßig miteinander ab um den jeweils aktuellen Stand zu besitzen. Somit 9 1. PGP

ist es ausreichend seinen eigenen Schlüssel an nur einen einzigen Server zu übermitteln. Der so ausgewählte Server übernimmt die Weiterverbreitung des Schlüssels, so dass dieser auf jedem Schlüsselserver zur Verfügung steht und von anderen Anwendern importiert werden kann. [Lin02] Solche Keyserver verfügen zumeist über eine grafische Ansicht auf der jeweiligen Webseite und ermöglichen anhand dieser das Importieren und Durchsuchen der Schlüssel. Aber auch eine Kommunikation per E-Mail ist möglich. Ausreichend hierfür ist das Eintragen des auszuführenden Befehls in den Betreff der Mail. Der Nachrichtenkörper wird vom Server ignoriert und ist nicht weiter ausschlaggebend, es sei denn man übermittelt einen Schlüssel-Block oder Signatur-Block in diesem.

Statistiken Alle nachfolgenden Statistiken der Keyserver wurden am 23.04.2017 um 18:39 auf der Webseite https://sks-keyservers.net/status/key_development.php abgerufen.

Schlüssel hinzugefügt heute: 484 Schlüssel hinzugefügt am Vortag: 709 Schlüssel hinzugefügt in den letzten 7 Tagen: 6.324 Schlüssel hinzugefügt in den letzten 30 Tagen: 28.580 Schlüssel hinzugefügt in den letzten 180 Tagen: 182.321 Schlüssel insgesamt: 4.652.951

Abbildung 10 zeigt die Entwicklung der Anzahl aller OpenPGP Schlüssel (des Keyserver- Pools) der letzten 6 Jahre:

Abb. 4: Schlüsselentwicklung der letzten 6 Jahre – Quelle: [KF16]

10 1. PGP

Abbildung 11 zeigt die Entwicklung der Anzahl aller OpenPGP Schlüssel (des Keyserver- Pools) der hinzugefügten Schlüssel pro Tag:

Abb. 5: Entwicklung der hinzugefügten Schlüssel pro Tag – Quelle [KF16]

Schlüsselweitergabe Für die Abwicklung der Schlüsselweitergabe stehen einem jeden User noch weitere Möglichkeiten zur Verfügung.

Versenden in E-Mail-Nachrichten Sollten nur bestimmte Anwender in den Besitz eines Schlüssels gelangen, so kann dieser anstelle des Servers direkt an die Kommunikationspartner per Mail verschickt werden. Dabei steht einem frei, ob der Schlüssel-Block direkt in den E-Mail-Körper kopiert wird oder als Anhang in einer beigefügten Datei. [Lin02]

Weitergabe als Datei Beim Export des öffentlichen Schlüssels als Datei, kann dieser sowohl in einer einfachen Textdatei als auch in einer als ASCII-Armor kodierten Schlüsseldatei gespeichert werden. Aufgrund des, dem Schlüssel vorangehendem und nachfolgendem Textes, erkennt PGP den Schlüsselblock selbstständig und das Angeben der jeweiligen Datei ist ausreichend. Der extrahierte Schlüssel kann anschließend per Mail, CD, USB-Stick, Festplatte oder anderen Datenträgern an den Empfänger übergeben werden und von diesem zum Schlüsselbund hinzugefügt werden. [Lin02]

Schlüssel importieren Die neuesten Versionen von PGP, PGP Desktop, unterstützen das Durchsuchen der Keyserver bereits in der grafischen Oberfläche PGPs, welches den gesamten Vorgang wesentlich unterstützt. Hierfür muss lediglich der gewünschte Keyserver festgelegt werden und anhand von Suchbedingungen und anderen Auswahlmöglichkeiten lässt sich die Ausgabe der Schlüssel eingrenzen. Befindet sich der gewünschte Schlüssel in den

11 1. PGP

ausgegebenen Resultaten, kann dieser dem lokalen Schlüsselbund hinzugefügt werden. [Lin02]

Aus einer Datei importieren Sollte eine der von den Keyserver angebotenen Webseiten für den Import eines öffentlichen Schlüssels genutzt werden, entspricht der Importvorgang dem aus einer Datei, da der Schlüsselblock zuerst in eine Datei kopiert werden muss, bevor dieser dem Schlüsselring hinzugefügt werden kann. Selbiges gilt für den Fall, dass der Schlüsselblock per E-Mail übertragen wird und nicht schon als externe Schlüsseldatei im Anhang mitgeschickt wird. Beim Importieren eines oder mehrerer Schlüssel aus einer Datei muss der Pfad der jeweiligen Datei angegeben werden. Aufgrund der standardisierten Darstellungsform des Schlüsselblockes erkennt PGP diesen selbstständig und ermöglicht den teils automatisierten Import. [Lin02]

Prüfen eines Schlüssels Ein neu importierter Schlüssel wird in PGP zunächst als ungültig und nicht vertrauenswürdig eingestuft. Dieser vorzeitige Zustand ist eine Sicherheitsmaßnahme, da ein Jeder einen öffentlichen Schlüssel auf einen Keyserver hochladen kann und so die Authentizität nicht notwendigerweise gegeben ist. Eine Überprüfung der Authentizität eines jeden Schlüssels ist daher als besonders wichtig zu betrachten. [Lin02]

1.3. Web of Trust Ein Web of Trust, zu Deutsch Netz des Vertrauens, ist eine spezielle Art einer Public-Key- Infrastruktur, mit dem Ziel, der Umsetzung eines Netzwerkes von vertrauenswürdigen und authentisierten digitalen Schlüsseln ohne Notwendigkeit einer zentralen Zertifizierungsstelle (CA). Die zentrale Rolle der Zertifizierung der einzelnen Schlüssel wird im Web of Trust von den Teilnehmern selbst übernommen. Das Funktionsprinzip sieht folgendermaßen aus: Alice möchte mit Bob verschlüsselt kommunizieren. Hierfür besorgt sich Alice als Erstes den öffentlichen Schlüssel von Bob. Damit sie sichergehen kann, dass dieser auch wirklich Bob gehört vergleicht sie bei einem Telefonat oder einem persönlichen Treffen mit diesem den Fingerprint seines Schlüssels und vergewissert sich der Authentizität. Da für Alice die Authentizität des Schlüssels gegeben ist signiert sie Bobs Schlüssel. (Die digitale Signatur eines Schlüssels dient in einem Web of Trust als Zertifikat.) Nun möchte auch Carl mit Bob einen verschlüsselten Kommunikationskanal aufbauen. Carl und Alice verfügen schon über eine vertrauenswürdige Beziehung und haben sich über die Echtheit ihrer Schlüssel bereits vergewissert, weshalb für Carl der von Alice signierte Schlüssel Bobs, ebenfalls als gültig anerkannt wird. Somit vertraut Carl auf die Überprüfung seitens Alice und akzeptiert Bob als Identität des Schlüsselinhabers. Verstärkt wird dieser Faktor, wenn der digitale Schlüssel eines Teilnehmers über mehrere Signaturen unterschiedlicher Teilnehmer verfügt. Anhand dieser Vertrauensbeziehungen der einzelnen Benutzer entsteht ein gesamtes Netzwerk des Vertrauens – das Web of Trust. Ein solches Netzwerk basiert auf zwei Grundfaktoren, die ein jedes Web of Trust aufweist: dem Owner Trust und dem Key Legitimacy-Wert.

12 1. PGP

Owner Trust Den Owner Trust definiert ein jeder Schlüsselring-Besitzer für sich selbst und dieser ist für andere Teilnehmer nicht öffentlich ersichtlich. Er spiegelt den Grad des Vertrauens in eine andere Person bezogen auf die Genauigkeit der Überprüfung und des Signierens anderer Schlüssel wieder. Folgende Stufen kann ein Owner Trust einnehmen:

• „ultimate“ („absolutes Vertrauen“) – diese Stufe gilt als Standard für die eigen erzeugten Schlüssel.

• „complete“ („volles Vertrauen“) – Usern wird mittels dieser Stufe ein volles Vertrauen entgegengebracht. In diesem Fall setzt man auf deren sorgfältige Überprüfung der Identität weiterer Schlüsselbesitzer, bevor sie dessen Schüssel signieren

• „marginal“ („geringes Vertrauen“) – Schlüsselbesitzer mit dieser Deklarierung wird nur eingeschränkt vertraut. Sie machen den Anschein die Identitätsüberprüfung nicht ausreichend genau durchzuführen bevor Signaturen ausgestellt werden

• „none/not trusted“ („kein Vertrauen“) – diese Stufe wird einem Schlüsselbesitzer zugewiesen, dem man nicht vertraut und dessen Signaturen anderer Teilnehmer ignoriert werden

• „unknown“ („unbekannt“) – für Teilnehmer über die der Schlüsselringbesitzer keine Informationen besitzt, wie dieser die Identität eines anderen Schlüssels überprüft [BKW13]

Key Legitimacy Der Key Legitimacy-Wert, zu Deutsch Schlüssel-Legitimitäts-Wert, eines öffentlichen Schlüssels zeigt das Vertrauen in die Authentizität des Schlüssels und den dazugehörigen Schlüsselbesitzer. Dieser Wert kann einen von drei Werten einnehmen:

• „complete“ – zeigt, dass der Schlüsselringbesitzer überzeugt ist, dass der Schlüssel dem angegebenen Schlüsselbesitzer gehört und er derjenige ist für den er sich ausgibt

• „marginal“ – dieser Wert wird Schlüsseln zugewiesen, bei denen man sich nur teilweise sicher ist, dass sie der angegebenen Person zugehörig sind

• „none“ – wenn man sich nicht sicher ist, ob der öffentliche Schlüssel zu einer Person (die User-ID) gehört oder nicht

Während der Owner Trust vom Schlüsselbundbesitzer selbst festgelegt wird, so wird der Key Legitimacy-Wert anhand der bereits vertrauenswürdigen Schlüssel im Schlüsselbund berechnet. In der Regel reicht eine Vertrauensstufe von „complete“ (siehe Abbildung 12) oder drei der Höhe „marginal“ (in Abbildung 13 ersichtlich) aus, damit ein Schlüssel als zugehörig und somit authentisch gilt. Diese Werte können je nach Benutzer angepasst werden. [BKW13]

13 1. PGP

Abb. 6: Key Legitimacy - complete trust chain

Abb. 7: Key Legitimacy - marginal trust chain

Keysigning Partys Keysigning Partys sind Veranstaltungen auf denen sich Leute treffen um ihre öffentlichen Schlüssel austauschen und gegenseitig zu signieren. Die Personengruppen auf solchen Treffen sind sehr vielschichtig und die so entstandenen Kontakte gehen weit über die technische Ebene hinaus. Oft wird diese Art von Partys bei Konferenzen oder Messen abgehalten. Ein klassischer Austragungsort ist die jährlich stattfindende Messe für Informationstechnik CeBIT (Centrum für Büroautomation, Informationstechnologie und Telekommunikation) in Hannover. [KLS03] Der Ablauf von Keysigning Partys ist einfach gehalten und dennoch strukturiert. Die Schlüssel aller angemeldeten Benutzer werden vor der Veranstaltung von den jeweiligen Organisatoren zentral entgegengenommen und in einer Datenbank gespeichert. Auf der Party wird eine Liste der Schlüssel in ausgedruckter Form an alle Teilnehmer verteilt. Solche Listen beinhalten in der Regel Attribute wie den Schlüssel, die Schlüsselart, das Erstellungsdatum, den Schlüsselinhaber, die Schlüssel-ID und den Fingerprint. Da ein öffentlicher Schlüssel als Ganzes sehr unhandlich erscheint, werden meist nur die Schlüssel-IDs (Key-ID) und die dazugehörige Prüfsumme (der Fingerprint) ausgetauscht bzw. verglichen. Des Weiteren muss ein Identitätsnachweis, z.B. mittels Vorlage eines Lichtbildausweises, erfolgen um die Authentizität zu gewährleisten. [KLS03]

14 1. PGP

1.4. OpenPGP Implementierungen GNU/Linux - GNU Privacy Guard – GnuPG Die wohl bekannteste Alternative zu Symantec’s PGP Software ist das seit 1997 von Werner Koch entwickelte Kryptographiesystem GNU Privacy Guard, kurz GnuPG oder GPG. Bei dem in der Vergangenheit von der deutschen Bundesregierung finanziell geförderte und seit 2015 durch Crowdfunding finanzierte Programm, handelt es sich wie bei PGP um ein Tool zum Ver- und Entschlüsseln von Daten, sowie das Erstellen und Überprüfen von (digitalen) Signaturen. Das auf dem PGP basierenden Programm wird für die gängigsten Betriebssysteme Linux, OS X sowie Microsoft Windows angeboten und implementiert den OpenPGP-Standard nach RFC 4880. GPG ist ein Kommandozeilentool und besitzt standardmäßig keinerlei grafische Oberflächen, jedoch werden mittlerweile einige Frontends, welche die Funktionen über eine graphische Oberfläche zur Verfügung stellen, angeboten. GPG wird unter der GNU-GPL (GNU General Public License) vertrieben, kostenfrei angeboten und verwendet nur patentfreie Algorithmen, wie (mittlerweile) RSA, Elgamal, CAST5, Triple-DES (3DES), AES (Rijndael) und Blowfish. Im Allgemeinen sind PGP und GPG kompatibel und unterscheiden sich nur in kleineren Punkten. So ist zum Beispiel der IDEA Algorithmus patentiert und wird nur von PGP unterstützt. Aufgrund der gemeinsamen Verwendung des OpenPGP Standards kann eine jede mittels PGP verschlüsselte Mail oder Datei mit GPG entschlüsselt werden und vice versa. [GPG17]

Windows – Backend – GPG4Win Gpg4win (GNU Privacy Guard for Windows) ist ein im Jahr 2006 vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Auftrag gegebenen Verschlüsselungssoftware. Das freie auf GnuPG basierendes Open Source Softwarepaket für Windows ermöglicht das Ver- und Entschlüsseln von Dateien und Mails, das Überprüfen der Authentizität, sowie der Integrität, der verschlüsselten Daten und dient als GPG Implementierung unter Windows. GPG4Win verwendet GPG als Kern für die kryptographischen Funktionen und die Zertifikatsmanager „Kleopatra“ und „GPA“ für die Verwaltung der Zertifikate. Zusätzlich bietet es mit GpgOL ein Microsoft Outlook Plugin für Emailverschlüsselungen und GpgEx ein weiteres Plugin für den Windows Explorer für die Verschlüsselung von Dateien. Seit der Version 2.0.x unterstützt Gpg4win neben dem OpenPGP den S/MIME-Codierungs-Standard. [GPW17]

Windows – Frontend – PGP Desktop Home 2002 kaufte die PGP Corporation, mit Phil Zimmermann im Führungsteam, die PGP Rechte und legte alle Quelltexte offen. Nur 8 Jahre später wurden diese Rechte erneut an Symantec weiterverkauft. Die nachfolgenden Versionen PGPs, bis hin zur heutzutage aktuellen 10.x Version werden seitens Symantec unter dem Namen PGP Desktop Home vertrieben und sind nicht mehr kostenfrei verfügbar. [Enk13]

15 1. PGP

Windows – Frontend – Pretty Easy Privacy – p≡p Pretty Easy Privacy, kurz pEp oder p≡p, ist ein schweizer Softwareprojekt, welches 2012 vom Softwarearchitekt Volker Birk und dem Chaostreff Winterthur ins Leben gerufen wurde. P≡p ist eine Open-Source-Verschlüsselungssoftware, mit dem Ziel eine sichere und anonyme Kommunikation zu etablieren, die vor allem leicht umzusetzen ist. Das Team on pEp ist überzeugt, dass eine Vielzahl von Verschlüsselungsprogrammen angeboten werden, das Problem jedoch bei dem Verständnis des Endusers obliegt. „Das alleinige Verwenden einer Verschlüsselungssoftware ist noch keine Voraussetzung für eine sichere Kommunikation, erst mit der korrekten Handhabung und dem richtigen Management der Schlüssel wird eine Kommunikation sicher“ – ist die Kernaussage des Teams hinter dem Projekt. [NP17] Pretty Easy Privacy ist eine Crypto-Benutz-Engine, welche als Backend GnuPG und NetPGP unterstützt, und setzt genau an diesem Problem an. Bei der Installation der Software oder des Plugins, da pEp für viele gängige Mailprogramme als Plugin angeboten wird, importiert es automatisch alle lokalen PGP Schlüssel, die auf dem Endgerät gefunden werden. Sollte PGP nicht installiert sein wird automatisch GPG4Win installiert und ein neues Schlüsselpaar generiert. Dies geschieht im Hintergrund der Applikation, ohne dass vom Benutzer Konfigurationen vorgenommen werden müssen. Wird anschließend eine Kommunikation z.B. per Mail gestartet und es liegt vom Empfänger noch kein öffentlicher Schlüssel vor, wird auf den Keyservern nach diesem gesucht. Liegt auf einem Keyserver ein zum Empfänger passender Schlüssel, wird dieser importiert, die Mail mit diesem verschlüsselt und der eigene öffentliche Schlüssel abschließend an die Mail angehängt, bevor diese verschickt wird. Der gesamte Prozess findet im Hintergrund statt und ohne erforderlichem Eingreifen des Users. Zusätzlich setzt Pretty Easy Privacy auf eine vierstufige Farb- und Symbolkodierung, die das „Privacy Level“, sozusagen die Stärke der Sicherheit mit einem Kommunikationspartner und einer bestimmten Nachricht, anzeigt (siehe Abbildung 5). Mittlerweile wird p≡p als App für Android und als kostenpflichtiges Add-in für Outlook angeboten. Weitere Versionen zur Verschlüsselung von Whatsapp-, Twitter-, Facebook- Chats und Apple Mails, eine iOS App, sowie Erweiterungen für die gängigsten Web Browser, Safari, Chrome, Internet Explorer und Mozilla Firefox sind geplant. [PEP17]

Abb. 8: Pretty Easy Privacy – Farbkodierung der „Privacy Level“ – Quelle: [PEP17]

Mac OS X – Backend – MacGPG Mac GNU Privacy Guard, kurz MacGPG, ist die Mac-Implementierung von GPG unter Mac OS X. Im Jahr 2011 wurde auf der offiziellen Webseite macgpg.sourceforge.net verkündet, dass das Mac GPG Project vom Entwickler GPGTools übernommen und von diesem weitergeführt wird. Mittlerweile ist die neue Version MacGPG2 verfügbar, welche auch als Kernstück für die Verschlüsselungssoftware GPG Suite dient. [MGP17]

16 1. PGP

Mac OS X – Frontend – GPG Suite GPG Suite, früher als Mac GNU Privacy Guard bekannt, ist eine von GPGTools entwickelte OpenPGP Software für Apples Unix-Betriebssystem macOS. Es dient als Äquivalent der anderen OpenPGP Implementierungen und stellt die grundlegenden Verschlüsselungsfunktionen zur Verfügung. Die GPG Suite fasst mehrere Softwarepakete zusammen. So dient GPGMail als Plugin für den macOS Mail Client für die Ver- und Entschlüsselung von Mails, der Zertifikatsmanager GPG Keychain wird für die Verwaltung der Schlüssel und MacGPG2 als Portierung für macOS von GnuPG genutzt. [GPT17]

Android – Backend – OpenPGP.js OpenPGP.js ist eine JavaScript-Implementierung des OpenPGP-Protokolls. Das Ziel des Entwicklerteams hinter dieser library ist das zur Verfügung stellen der OpenPGP Funktionalitäten in JavaCript mittels einer Open Source library, welche Standardfunktionalitäten wie das Signieren, Ver- und Entschlüsseln aber auch Verifizieren von Texten, E-Mails und Dateien ermöglicht. [OJS17]

Android – Backend – Bouncy Castle Im Jahr 2000 wurde das Projekt Bouncy Castle, mittlerweile von dem 2013 gegründeten Maintainer Legion of the Bouncy Castle Inc.verwaltet, ins Leben gerufen. Bouncy Calste ist eine Sammlung von quell-offener kryptographischer Programmierschnittstellen für Java und C#. Unter dem Namen Spongy Castle wurde im Frühjahr 2014 ein neues Projekt veröffentlicht, da es aufgrund von Konflikten bei Klassennamen manchen Android Applikationen nicht möglich war Bouncy Castle zu verwenden. [BC17] iOS – Frontend – iPGMail Für die Verwendung des OpenPGP Standards unter iOS eignet sich die Verwendung von iPGMail. Ebenso wie die weiteren Softwarepakete beschrieben in diesem Kapitel ermöglicht iPGMail den Austausch von verschlüsselten Daten und Nachrichten. Grundlegende Funktionen wie das Signieren, das Überprüfen der Authentizität und auch der Integrität werden ebenfalls geboten. Die iPhone/iPad Applikation unterstützt das Generieren von Schlüssel und den Export dieser. Um den Daten und Schlüsselaustausch zu erleichtert, setzt iPGMail auf DropBox und lässt sich in die iOS Mail App integrieren. Dadurch soll der Empfang und der Versand von sicheren privaten Nachrichten möglichst simpel gehalten werden.

Webbrowser Plugin – Mailvelope Mailvelope, ein Produktname zusammengesetzt aus den beidem Begriffen „Mail“ und „Envelope“, zu Deutsch Umschlag, ist eine der ersten Ansätze einer PGP Implementierung in Form einer Browser-Erweiterung. Die von der Mailvelope GmbH im Jahr 2012 veröffentlichte Software versucht die Funktionalitäten einer Ende-zu-Ende- Verschlüsselung für den E-Mail-Verkehr mit einer Benutzeroberfläche auszurüsten um 17 1. PGP

somit eine bessere Benutzerfreundlichkeit zu erreichen. Hierbei erweitert das Addon die Benutzeroberfläche des Webmail Services und die jeweiligen Bedienelemente, die für die Ver- und Entschlüsselung von E-Mails verwendet werden können. Mittlerweile wird Mailvelope von einer Liste an E-Mail-Anbietern vorkonfiguriert angeboten. So bieten bekannte Webmail-Anwendungen wie GMX, WEB.DE, De-Mail, Outlook.com, Yahoo!Mail aber auch Gmail die Integration Mailvelope’s an. [MV16] In der Studie „Why Johnny Still, Still Can’t Encrypt: Evaluating the Usability of a Modern PGP Client“ von 2015 wurde Mailvelope auf die Benutzerfreundlichkeit untersucht. Von allen 20 Testusern, aufgeteilt in Paare zu jeweils 2 Probanden, war es lediglich einem Testpaar möglich den vorgegebenen Task, der verschlüsselte Austausch von Mails, in der festgelegten Zeitspanne, von einer Stunde, zu absolvieren. Auch weitere Schwächen wurden bei diesem Test aufgezeigt. Vor allem in Bereichen der Schlüsselverwaltung, der Bereitstellung von Anweisungen und der Erläuterungen des Grundprinzips gab es deutliche Defizite. Zusätzlich äußerten der Großteil der Testuser eine Frustration und bestätigten somit weithin eine fehlende Massentauglichkeit der Software, beziehungsweise ein enormes Verbesserungspotenzial dieser. [RAZS15]

Abb. 9: Mailvelope Schlüsselverwaltung – Quelle: [MV16]

18 1. PGP

Mail-Plug-In – Thunderbird – Enigmail Das, aus der Bezeichnung einer im Zweiten Weltkrieg verwendeten Schlüsselmaschine ENIGMA und dem Begriff E-Mail zusammengesetzten Wörtern, Add-on Enigmail, ist eine Erweiterung für Mozilla Thunderbird zum Signieren und Verschlüsseln elektronischer Nachrichten sowie Anhänge. Hierfür wird der OpenPGP Standard unter GnuPG verwendet. Enigmail wird unter der Mozilla Public License als freie Software angeboten und kann somit gratis verwendet, modifiziert und verbreitet werden. Im September 2015 wurde bekanntgegeben, dass das Team von Enigmail gemeinsam mit der p≡p-Stiftung an einem neuen Projekt „Enigmail/p≡p“ arbeitet, um zukünftig Emails in Thunderbird standardmäßig, ohne jeglicher Benutzerinteraktion, verschlüsseln zu können. [EM17]

Abb. 10: Enigmail Screenshot – Quelle: [EM17]

19 1. PGP

1.5. Geschichtlicher Hintergrund Phil Zimmermann studierte Computerwissenschaft und arbeitete als Computerfachmann in einem recht bekannten Unternehmen als er gemeinsam mit seiner Frau nach Colorado zog. Zu diesem Zeitpunkt bereiteten die politischen Veränderungen und die aufkommende Hysterie eines möglichen (Nuklear-)Krieges Phil Zimmermann Sorgen. Verstärkt wurden diese Ängste als das junge Paar im Jahr 1980 ein Kind in die Welt setzte und sie nicht wollten, dass ihr Kind in einer wirtschaftlich ruinierten Welt aufwuchs und so fassten sie den Entschluss nach Neuseeland auszuwandern. [Gar95] Im Jahr 1982 sollte es dann soweit sein. Alle benötigten Utensilien wie neue Reisepässe und Immigrationsdokumente waren organisiert und einer Ausreise stand nichts mehr im Weg, doch erneut gab ihnen eine politische Veränderung zu denken. Dieses Mal handelte es sich jedoch um eine positive Bewegung, die Nuclear Weapon Freeze Campaign. Phil hatte das Gefühl als könnte sich durch so eine positive politische Veränderung doch noch alles zum Guten wenden und er beschloss in Colorado zu bleiben und für eine bessere Welt zu kämpfen. Dies war zugleich der Zeitpunkt als in Phil das Interesse in militärische Waffen und Politik erweckt wurde. [Gar95] Zu dieser Zeit wandte sich Phil Zimmermann von seinem Job als Computerfachmann ab und gemeinsam mit ein paar seiner Freunde gründete er sein eigenes Unternehmen, Metamorphic Systems. Seine Firma beschäftigte sich mit einem Aufsatz, welcher es ermöglichen sollte den damaligen ersten Apple Computer mit einem neuen Prozessor auszustatten um somit die Rechenleistung zu erhöhen, ohne dass ein neues Gesamtsystem angeschafft werden muss. [Gar95] Eines Tages bekam Phil Zimmermann einen Anruf von einem Programmierer namens Charlie Merritt. Dieser war sehr an dem System von Metamarphic Systems und besonders an dessen Geschwindigkeit interessiert. Er erzählte Phil, dass er Programme entwarf, welche eine Public-Key-Verschlüsselung mit einem Algorithmus namens RSA durchführten und er dafür ein System mit sehr hoher Rechenleistung benötigen würde. Das Interesse Zimmermanns war geweckt und die Beiden unterhielten sich über das System, sowie allgemein über Kryptographie und tauschten sich sogar über politische Ansichten aus. Von Beginn an waren sie sich sympathisch und vor allem die Abneigung gegenüber der staatlichen Überwachung und Kontrolle schaffte eine Verbundenheit. „Er war die einzige Person die ich jemals traf, welche nichts über Public-Key- Verschlüsselungen wusste und dennoch jedes einzelne Detail, wie man sie bewerkstelligte, wissen wollte.“ sagte Charlie Merritt über Phil Zimmermann (in einem späteren Interview). [Gar95]

A Pretty Good Program Über die Jahre verstärkte sich die Zusammenarbeit von Phil Zimmermann und Charlie Merritt. Fast wöchentlich unterhielten sich die Zwei und Merritt vermittelte sein gesamtes Wissen über Kryptographie an den wissbegierigen Phil. Besonders die Kenntnisse wie man einen solch komplizierten Algorithmus wie RSA und die dahinterliegende Mathematik in einem Programm realisieren kann, gab dieser weiter. Bis eines Tages Zimmermann den Entschluss für ein neues Projekt traf. Eine RSA-Implementierung auf dem zu der damaligen Zeit neu aufkommenden und vielversprechenden IBM PC. Diesbezüglich flog Merrit nach Boulder um mit Phil Zimmermann bei einem persönlichen Treffen über seine zukünftigen Pläne zu sprechen. An dem Treffen nahm noch eine dritte Person teil, Jim 20 1. PGP

Bidzos. Jim Bidzos, mit dem Charlie Merritt schon etwas länger in Kontakt war, war zur damaligen Zeit der Firmenpräsident der RSA Data Security Inc., welche von den drei Entwicklern RSAs gegründet worden ist und bis zum Jahr 2000 das Patent für RSA besaß. Er war somit ein interessanter Partner und könnte für das Projekt noch sehr von Nutzen sein. Doch anders als vorerst erwartet, war die Stimmung zwischen Bidzos und Zimmermann sehr kühl und Merritt sah sich als Vermittler zweier unterschiedlichen Parteien. Auf der einen Seite, der freiheitliche Aktivist Zimmermann und auf der anderen Seite Bidzos, ein Mitglied der US Marine. Bidzos hatte zwei Kopien des neuesten RSADSI Produkts MailSafe dabei. Ein Programm um elektronische Mails zu signieren und zu verschlüsseln, sehr ähnlich dessen, was Zimmermann geplant hatte. Er überreichte die Kopien den beiden Gesprächspartner und den restlichen Abend tauschten sie sich noch über Verschlüsselungen aus. [Gar95] Obwohl Bidzos mit MailSafe ein bereits entwickeltes Programm für die Public-Key- Verschlüsselung aufzeigte, widmete sich Zimmermann weiterhin seinem Ziel einer eigenen Implementierung dessen. Den Namen den er für sein Programm wählte war „Pretty Good Privacy“, kurz PGP, inspiriert von einem Radio Programm „Prairie Home Companion“, in dem einer der Sponsoren den Namen „Ralph’s Pretty Good Groceries“ trug. Es gab nur ein bedeutendes Problem mit „Pretty Good Privacy“ - Zimmermann verfügte über keine RSA Lizenz und Bidzos war nicht bereit ihm eine „freie Lizenz“ zu geben. Vielmehr wies ihn Bidzos darauf hin größere Firmen für sein Produkt zu begeistern, damit diese die benötigten Lizenzen anschaffen würden. Ohne Lizenz jedoch, war es Zimmermann nicht möglich PGP auf legalem Weg zu veröffentlichen. [Gar95] Demungeachtet sollte eine Klausel im 1991 veröffentlichten anti-crime bill alles Bisherige verändern. Auf Seite 266 in der Sektion 2201 hieß es, dass ein jeder Anbieter von elektronischen Kommunikationsdiensten und Hersteller von elektronischem Equipment für Kommunikationssysteme sicherstellen muss, dass die Regierung, sollte diese vom Gesetz dazu autorisiert werden, jeglichen elektronischen Kommunikationsfluss in Klartext einsehen kann. [Gar95]

Die Geburt PGPs – Version 1.0 Viele sahen diese Klausel als Einschnitt in ihre Privatsphäre und wollten dagegen vorgehen. So auch Phil Zimmermann, welcher die Dringlichkeit eines Programms wie PGP erkannte. Daraufhin versuchte er PGP schnellstmöglich fertig zu stellen, um sein Programm publizieren zu können. Er ersetzte den DES Algorithmus in seiner damaligen Version, da er diesem nicht vertraute, durch einen von ihm entwickelten Verschlüsselungsalgorithmus, dem Bass-O-Matic. Die Sicherheit von Bass-O-Matic war aufgrund fehlender Überprüfungen durch die große Masse nicht gegeben, bzw. nicht überprüft, jedoch legte Zimmermann wesentlich mehr Vertrauen in diesen als in den damalig standardisierten DES Algorithmus. Anschließend machte er noch ein paar kleinere Änderungen und im Juni 1991 wurde PGP Version 1.0 veröffentlicht. Eine Kopie des Programms wurde von einem Freund Zimmermanns über Usenet, ein weltweites Netzwerk von UNIX Computer Systemen, verbreitet. [Gar95] Da PGP unter anderem immer noch eine Verschlüsselung mittels RSA anbot und ein potenzieller Konkurrent für MailSafe war, war es Bidzos von Beginn an ein Dorn im Auge. Sobald dieser über die Veröffentlichung PGPs erfuhr kontaktierte er Phil Zimmermann um die weitere Verbreitung zu stoppen. PGP wurde daraufhin zwar von verschiedenen

21 1. PGP

Servern entfernt, so auch von Usenet, dennoch war das Interesse der breiten Masse geweckt und weltweit wurde PGP weiterhin eingesetzt und verbreitet. Der Patentstreit und die Ungewissheit gegenüber Bass-O-Matics Sicherheit bremsten den Erfolg dennoch ungemein. [Gar95]

Bass-O-Matic Als nächsten Schritt wollte sich Zimmermann von der Sicherheit seines Verschlüsselungsalgorithmus vergewissern und so besuchte er im August 1991 die jährliche Crypto Konferenz in Santa Barbara, zu der sich die weltweit besten Kryptographen trafen. Unter den Teilnehmern befand sich auch der international anerkannte Kryptograph Eli Biham, den Zimmermann überzeugen konnte, einen Blick auf Bass-O-Matic zu werfen. In einer Mittagspause analysierte er den Algorithmus und bestätigte, was Zimmermann befürchtete – Bass-O-Matic war unsicher und ein hoffnungsloser Fall. [Gar95]

PGP Version 2.0 PGP wurde weltweit genutzt. Zwar fiel PGP unter das US-Exportgesetz, da aber eine simple Mail mit dem Programm als Anhang genügte um es zu verbreiten und nicht jede Mail von der Regierung überprüft werden konnte, war es kurz nach der Veröffentlichung auch außerhalb der USA verfügbar. [Gar95] Zu Beginn des Jahres 1992 schlossen sich einige Nutzer zusammen um eine verbesserte Version von PGP zu kreieren. Unter diesen Leuten befanden sich unter anderem Branko Lankester aus den Niederlanden und Peter Gutmann aus Neuseeland. Die wichtigste von ihnen vorgenommene Veränderungen war das Ersetzen von Bass-O-Matic mit IDEA, International Data Encryption Algorithm, einem symmetrischen Algorithmus aus der Schweiz. Anschließend wurde PGP Version 2.0 (zeitgleich) in den Niederlanden und in Neuseeland veröffentlicht. Nur kurze Zeit später war die abgeänderte Version auch im Ursprungsland Amerika verfügbar und im Frühjahr 1993 erreichte PGP, nach weiteren kleineren Anpassungen, mit Version 2.3a eine stabile Version. [Gar95] Im Herbst 1992 formte sich eine Gruppe, welche sich für die technischen Freiheiten wie Verschlüsselungen, anonyme Kommunikationen und elektronische Signaturen stark machte – The Cypherpunks. Gegründet wurde die Interessengruppe von Tim May, einem ehemaligen Intel Mitarbeiter und Eric Hughes, welcher in einem großen Unternehmen an der Ostküste arbeitete. Die Cypherpunks erkannten das Potenzial von PGP, aber genauso wie Phil Zimmermann störte sie das Lizenzproblem. Allerdings hatte Tim May eine Lösung zu diesem Problem gefunden. Denn inzwischen hatte RSA Data Security eine zweite Implementierung von RSA entworfen, namens RSAREF (RSA Reference), und diese verfügt über eine Lizenz für den freien Einsatz in nichtkommerziellen Programmen. Der Grundgedanke hinter dieser abgewandelten Version war es unter anderem, Akademiker zu erlauben mit dem RSA Algorithmus zu experimentieren. [Gar95] Es stellte sich heraus, dass die von PGP benötigten Funktionen nicht in der „freien“ RSAREF Lizenz inbegriffen sind und sie Phil Zimmermann nichts nutzte. Stattdessen schlug Phil Zimmermann einen anderen Weg ein. Er schloss sich mit dem Unternehmen Lemcom zusammen. ViaCrypt, eine Abteilung Lemcoms, besaß zu dieser Zeit eine Lizenz für die kommerzielle Verwendung des RSA Algorithmus und so veröffentlichten sie

22 1. PGP

gemeinsam im November 1993 ViaCrypt PGP Version 2.4. Da sich viele Unternehmen erst für freie Software interessieren, wenn diese von einem legitimen Unternehmen unterstützt wird und sich viele User weigerten PGP zu verwenden, solange der Lizenzkonflikt nicht gelöst war, war dies für Zimmermann der beste Weg seine Software möglichst vielen Nutzern zur Verfügung zu stellen. [Gar95]

Das MIT steigt ein Im Sommer 2013 kontaktierte erneut jemand Phil Zimmermann. Diesmal waren es zwei Personen vom MIT, Jeffrey Schiller, MIT’s Netzwerk Manager und James Bruce, der Vize- Präsident für Informationssysteme am MIT. Auch diese Herrschaften waren von PGP begeistert und wollten versuchen das Lizenzproblem der vorherigen Versionen zu beseitigen. Ihnen war bewusst, dass sich RSAREF nicht eignete, doch mittlerweile wurde von der RSA Inc. die RSAREF Version 2.0 veröffentlicht, welche alle nötigen Funktionen für ein nichtkommerzielles Programm anbot. Sie schlugen vor, RSAREF 2.0 in PGP einzubauen und es als PGP Version 2.5 zu veröffentlichen – was auch kurze Zeit später geschah. [Gar95] Bizdos war erneut außer sich. Als er von dem Zusammenschluss Zimmermanns mit dem MIT und von PGP Version 2.5 erfuhr, nahm er mit dem MIT Team Verbindung auf. Es war ihm ein großes Anliegen, dass mit der neuen Version alle älteren Versionen von PGP, welche gegen das Patent verstießen, entfernt werden. Da dies auch im Interesse Zimmermanns war, einigten Sie sich anstelle der Version 2.5 eine neue Version (2.6) zu veröffentlichen, welche zwar Signaturen älterer Versionen unterstützt, dennoch nur mit Version 2.6 und Neueren kompatibel ist, um somit alle Nutzer zu zwingen auf die neueste Version umzusteigen. Mit PGP 2.6 war es das erste Mal seit der Entstehung PGPs, dass dieses ohne jegliche Schattenseite existierte. [Gar95] Daraufhin verbreitete sich PGP 2.6 über FTP Server sowohl in Amerika, als auch in Europa. Doch war nicht 2.6 die meist verbreitetste Version, sondern 2.6ui, eine Abwandlung der Version 2.3, welche mit der Version 2.6 kompatibel ist und dennoch nicht RSAREF verwendet. [Gar95]

PGP Version 5.x und 6.x Der ursprüngliche Erfinder PGP’s Philip Zimmermann gründete im Mai 1996 gemeinsam mit Jonathan Seybold und Dan Lynch die Firma PGP Inc. um sich der Weiterentwicklung des Programms zu widmen. Sie veröffentlichten die Windows-Version von PGP 5.0 und schon kurze Zeit später Versionen für die gängigsten Unix-Versionen. Vor allem die grafische Oberfläche der Windows Version und die erstmalige Verwendung weiterer Algorithmen, wie z.B.: 3DES, ElGamal, DSS/DSA, fanden positiven Anklang in der Community. Die Ankündigung, RSA und IDEA aus dem Programm herauszunehmen wurde mit weniger Begeisterung aufgenommen. Ab Version 5.0 spricht man vom OpenPGP Standard. [CBZ99] Mit der im Jahr 1997 von der PGP Inc. veröffentlichten Version 5.5 enthielt PGP ein neues aufsehenerregendes „feature“. Dieses „feature“ ist unter einer Vielzahl von Namen bekannt, darunter der gängigste ADK (Advanced Decryption Key) oder auch CAK (Company Access to Keys) und bewirkt, dass eine jede verschlüsselte Nachricht zusätzlich mit einem weiteren designierten Schlüssel mitverschlüsselt wird – sprich, dass 23 1. PGP

eine jede Nachricht von einer weiteren Person, z.B. wie angedacht der Arbeitgeber, gelesen werden kann. [CBZ99] Ende des Jahres 1997 kaufte die Firma Network Associates (NAI) die Firma PGP Inc. auf. Unter neuer Führung wurde im Jahr darauf die Version 6.0 publiziert. Diese kommerzielle Version enthielt Neuerungen in der Benutzeroberfläche, neue Funktionalitäten, während sie weiterhin die Verwendung von RSA und IDEA unterstützte, anders als die zeitgleich bereitgestellte Freeware-Version. [CBZ99] Mit Version 6.5 bot PGP wurden weitere Funktionen implementiert, dennoch gerieten NAI und PGP stark in Kritik, da die Quelltexte des Programms nicht mehr öffentlich waren. [CBZ99]

IETF OpenPGP Standard OpenPGP wurde im Jahr 1998 entwickelt und ist ein standardisiertes Datenformat für verschlüsselte und digital signierte Daten. Im Ursprung wurde OpenPGP als Reaktion auf aufgetretene Probleme mit PGP entwickelt. So waren sowohl der IDEA, als auch der RSA Algorithmus geschützt und konnten nicht beliebig verwendet werden. Aber auch das kommerzielle anbieten PGPs, durch die PGP Inc., war einer der Beweggründe für den Standard. Um den Aufbau und die einzigartigen Features des Web of Trust Systems zu unterstützen wurde mit dem IETF OpenPGP Standard ein sehr flexibles Nachrichtenformat entwickelt, welches verschlüsselte Nachrichten, Signaturen, Zertifikate als auch das gesamte Schlüsselmanagement handhabt. OpenPGP wurde zu Zeiten von PGP5 eingeführt und die erste Version des OpenPGP Formats wurde im RFC Standard 2440 definiert. Mittlerweile ist dieser RFC Standard obsolet und wurde vom RFC4880 abgelöst. [NWG07] Weitere RFC Standards, die mittlerweile verfügbar sind, sind RFC 3156, erweitert OpenPGP mit MIME, RFC 5581, fügte den Chiffrieralgorithmus Chamellia hinzu, RFC 6091, spezifiziert wie OpenPGP Schlüssel für TLS verwendet werden können und 2012 wurde mit dem RFC 6637 OpenPGP um Elliptic Curve Cryptography ergänzt. [OPGP17] Alle nach dem RFC 4880 weiteren RFC Standards sind jedoch nur „optional“ und werden von einem Großteil der Produkte, die OpenPGP implementieren, nicht unterstützt. Auch das OpenPGP-Dateiformat an sich wurde über die Jahre erweitert, jedoch sind alle nach der PGP Version 2.6 entwickelten Version abwärtskompatibel.

1.6. Schwächen von PGP Usability for Security Public-Key-Verschlüsselungsverfahren entsprechen allen sicherheitskritischen Anforderungen und setzten sich aufgrund der vielen Vorteile als Standard durch. Diese Verfahren gelten als sicher, sind global akzeptiert, leicht zu verwalten und vereinen die Vorteile der asymmetrischen und symmetrischen Kryptographie. Doch die Tatsache, dass bei einem Web of Trust, auf welchem PGP aufbaut, die Verwendung einer zentralen Schlüsselverwaltungs-Infrastruktur entfällt, spiegelt sich in dem Umstand wieder, dass die Aufgaben direkt an den Endbenutzer übergeben werden. So obliegt es bei Public-Key- Verschlüsselungsverfahren in der Verantwortung des Endbenutzers sich stets vor dem Gebrauch eines öffentlichen Schlüssels über die Authentizität dessen zu vergewissern 24 1. PGP

und den eigenen privaten Schlüssel unter allen Umständen zu schützen. Diese Bürde birgt ein größeres Risiko, als man sich zunächst bewusst ist. Sicherheitsfeatures und Verfahren sind ausgelegt möglichst effektiv und sicher zu sein. Usability als ein Solches, ist meist nur ein Nebenziel. [DD96]

Sicherheit als Benutzerziel Der Benutzer möchte im Internet surfen, Daten übermitteln, mit Freunden kommunizieren oder seine E-Mails abrufen. All dies soll in einer sicheren Art und Weise umgesetzt werden, jedoch steht die Sicherheit für den Benutzer meist nicht im Vordergrund. Vor allem wenn die Sicherheitsaspekte kompliziert sind oder nur durch Mehraufwand realisiert werden können, schreiten User leicht auf die ungesicherte Realisierung zurück und sind abgeneigt Sicherheitsfeatures zu nutzen. [WT99]

Unhandliche Schlüssel Ein Jeder, der sich schon mal mit Public-Key Verschlüsselung versucht hat, stellte sich schon die Frage, wie man am besten den eigenen Schlüssel zum gewünschten Kommunikationspartner bekommt bzw. wie man den öffentlichen Schlüssel publik macht. Man beachte, dass ein solcher Schlüssel meist aus 2048 bis 4096, in seltenen Fällen sogar bis zu 16384, Bits besteht, welche in Form eines ASCII-Armor kodierten Zeichenstrings dargestellt wird. Zusätzlich enthält der Public Key Block, die Darstellungsform eines solchen Schlüssels, auch noch die Benutzer-ID(s), das Erstell- sowie Ablaufdatum des Schlüssels, sowie die Version. Es ist nahezu unmöglich sich einen solchen Schlüssel zu merken und auch die Übermittlung in ausgedruckter Form erweist sich nicht als vorteilhaft. Stattdessen hat sich die Verwendung von Keyservern durchgesetzt. Dennoch kommt man auch bei dieser Art der Verbreitung nicht an der Verifizierung des Schlüssels vorbei.

Passwörter und Private Key Files Da PGP und die verwendeten kryptographischen Algorithmen noch immer als sicher gelten, konzentrieren sich potenzielle Angreifer meist nicht auf die Schwächen des Verfahrens an sich, sondern auf Schwachpunkte der Implementierung PGPs. Die wohl gängigste Art eines Angriffs ist die Kompromittierung des privaten Schlüssels eines Users, die Besitznahme der Passwortphrase mit der dieser Schlüssel geschützt ist oder schlichtweg Beides. Sollte es einem Angreifer gelingen sich Zugriff zum Passwort und zur Datei, in welcher der geheime Schlüssel gespeichert ist, zu verschaffen, ist es ihm möglich jeglichen verschlüsselten Datenverkehr mitzulesen, zu manipulieren und Signaturen mithilfe des kompromittierten Schlüssels zu erstellen. Diese denkbaren Schwachstellen treffen jedoch auf alle Verschlüsselungsverfahren zu, welche auf die Geheimhaltung eines bestimmten Schlüssels bzw. Passwortes beruhen. Vor allem die Wahl eines leicht zu erratenen Kennworts und die Ablage des geheimen Schlüssels in einem zugänglichen Speicherort stellen ein enormes Risiko dar, dessen sich User oft nicht bewusst sind. [Rya03]

25 1. PGP

Dem Angreifer stehen für die Aneignung einer Passwortphrase mehrere Möglichkeiten zur Verfügung. Zum einen gibt es den Einsatz von Brute-Force- oder Wörterbuchangriffen, aber auch Programme wie PGPCrack oder PGPpass, die darauf ausgelegt sind mit PGP verschlüsselte Dateien zu knacken, finden ihren Einsatz. Sollte der Angreifer des Öfteren Zugriff auf den Rechner eines Users haben, so ist es ihm ebenfalls möglich einen Keylogger, welcher alle Eingaben eines Benutzers speichert oder an eine bestimmte Adresse sendet, einzurichten. All diese Angriffstechniken benötigen jedoch einen Zugriff auf das lokale System. [Rya03] Im Gegensatz zu den Angriffen gibt es eine Vielzahl unterschiedlicher Schutzmaßnahmen um gegen Angriffe dieser Art vorzugehen. So sollten Benutzer stets darauf achten wo wichtige Dateien, wie das Public Key File, abgespeichert werden und allzeit über die Kontrolle ihrer Geräte verfügen. Präventiv ist es auch empfehlenswert den privaten Schlüssel auf einem extra Speichermedium, wie einem USB-Stick oder einer externen Festplatte, abzuspeichern und diesen physisch an einem sicheren Platz zu bewahren. Des Weiteren bietet die Wahl eines unzulänglichen Passworts einen zusätzlichen Angriffsvektor. Vor allem wenn sich das abgespeicherte Kennwort und die Datei, mit dem privaten Schlüssel, auf demselben Gerät befinden. Am sichersten wäre die Wahl eines möglichst komplex gewählten Passworts, welches weder niedergeschrieben noch gespeichert wird. Sollte man das es dennoch notieren müssen, so ist dies sicher aufzubewahren. Grundsätzlich ist es, wie bei jedem Kennwort, auch bei der Wahl der Passphrase von PGP notwendig die gängigsten Sicherheitsfaktoren zu beachten. Das Passwort sollte möglichst lang sein, Groß- und Kleinbuchstaben sowie Sonderzeichen und Ziffern beinhalten, nur einmal verwendet werden und die Verwendung realer Wörter und Jahreszahlen sollte vermieden werden. Gelingt es einem Angreifer dennoch den privaten Schlüssel eines Benutzers zu kompromittieren, ist es erforderlich alle anderen User schnellstmöglich darüber in Kenntnis zu setzen. Anhand eines sogenannten Schlüsselwiderrufungs-Zertifikats, kann ein privater Schlüssel gesperrt werden. Meist wird beim Eintreten eines solchen Szenarios ein neues Schlüsselpaar generiert und anschließend mit dem Schlüsselwiderrufungs- Zertifikat an alle Kommunikationspartner übermittelt. [Rya03]

Manipulation des öffentlichen Schlüssels In einem Public-Key-Verschlüsselungsverfahren müssen alle öffentliche Schlüssel verteilt werden, um einen sicheren Datenaustausch zwischen den Benutzern zu ermöglichen. Dabei ist es ausschlaggebend, dass die Authentizität gegeben ist, sprich, dass ein bestimmter öffentlicher Schlüssel auch wirklich der angegebenen Person angehört. Wird die Schlüsselzugehörigkeit vor dem Beginn einer Kommunikation nicht ausreichend überprüft, kann dies schwerwiegende Folgen haben. Somit wäre es einem Betrüger möglich seinen Kommunikationspartner zu täuschen, welcher wiederum vermeintlich sensible Daten übermittelt. Diese wären für den Angreifer in Klartext verfügbar und kann je nach übermittelter Daten, erhebliche Folgen mit sich bringen. [Rya03]

26 1. PGP

PGP Verwender sollten nur öffentlichen Schlüsseln vertrauen, welche sie direkt vom Besitzer bekommen haben oder Schlüssel, die von einer vertrauenswürdigen Person signiert worden sind. Diese Umstände erschweren es einem Betrüger wesentlich eine valide Signatur einer Person zu erlangen, der das potenzielle Opfer vertraut. In anderen Kryptosystemen wird dies durch eine zentrale Zertifizierungsstelle realisiert. Bei PGP übernehmen die User des Systems diese Rolle. [Rya03] Wenn ein Benutzer den öffentlichen Schlüssel eines Zweiten signiert ist es von grundlegender Bedeutsamkeit, dass sich dieser zuvor über Authentizität vergewissert hat. Dieser Tatsache sollten sich alle User bewusst sein. Nur wenn die im Zertifikat des jeweiligen Schüssels angegebene User ID wirklich übereinstimmt, kann der Schlüssel als valide angesehen werden und für weitere Kommunikationspartner signiert werden. Andere User vertrauen der Signatur und sehen den Schlüssel als gültig an, da sie selbst dem Ersteller der Signatur vertrauen. Dieser Grundgedanke des Web of Trust ist sogleich dessen größte Schwäche. [Rya03]

Fehlende (Perfect) Forward Secrecy - PFS Eine weitere Schwäche von PGP, bzw. OpenPGP, die in einer Vielzahl von Statements zu PGP und so auch im Artikel „Op-ed: I’m throwing in the towel on PGP, and I work in security“ von Filippo Valsorda [FV16] zu finden ist, ist das Fehlen von (Perfect) Forward Secrecy bzw. Future Secrecy. Unter Perfect Forward Secrecy, kurz PFS, bezeichnet man die Eigenschaft von Schlüsselaustauschprotokollen, dass die mittels des Langzeitschlüssel generierten Sitzungsschlüssel, für eine jede neue verschlüsselte Sitzung, nach der Beendigung dieser, nicht mehr aus den geheimen Langzeitschlüsseln rekonstruiert werden können. Somit ist sichergestellt, dass auch bei der Kenntnis des geheimen Langzeitschlüssels, bereits vergangene verschlüsselte Kommunikationen nicht nachträglich entschlüsselt und eingesehen werden können. Da bei PGP lediglich der Sitzungsschlüssel mit dem geheimen Langzeitschlüssel, dem privaten Schlüssel, chiffriert wird, ist es einem potenziellen Angreifer möglich, durch das Aufzeichnen bereits vergangener Kommunikationen, den Sitzungsschlüssel ausfindig zu machen und somit den gesamten Datenaustausch einzusehen. Eine Vielzahl von Applikationen, wie der als sicher geltende Messenger Signal, früher TextSecure, oder auch interaktive Protokolle wie TLS bieten die mittlerweile schon als essentiell geltende Eigenschaft Perfect Forward Secrecy. Auch wenn wie von Matthew Green und Ian Miers in der wissenschaftlichen Arbeit „Forward Secure Asynchronous Messaging from Puncturable Encryption“ [GM15] oder im Online-Draft „Forward Secrecy Extension for OpenPGP“ von Ian Brown, Adam Back und Ben Laurie [BBL17] beschrieben, es möglich ist OpenPGP-Systeme mit Forward Secrecy zu erweitern, so wird es derweil von noch keinem PGP basiertem Produkt unterstützt. [KH05]

1.6.1. Technische Angriffe auf PGP Angriffe auf das Betriebssystem Die Funktionsweise vieler Betriebssysteme stellen für PGP Verwender ein weiteres Risiko dar. User sind sich oft nicht bewusst, dass, wenn eine Datei gelöscht wird, nur der 27 1. PGP

Pointer, welcher auf die Speicherstelle der Datei zeigt, entfernt wird und nicht die Datei an sich. Ebenfalls gibt es viele Programme die während dem Arbeiten temporäre Sicherheitskopien erzeugen, welche im Hintergrund erstellt und gelöscht werden. Doch auch diese temporären Dateien befinden sich noch nach dem Entfernen auf dem Datenträger, da auch hier nur ein Eintrag in einer Datenbank entfernt wird. Ein potenzieller Angreifer kann, mit den richtigen Programmen, die Fragmente vermeintlich gelöschter Dateien finden und somit Teile oder gar die gesamte Datei wiederherstellen. PGP User betrifft dieser Umstand insofern, dass Viele davon ausgehen die Originaldatei einfach löschen zu können, sobald eine verschlüsselte Kopie erstellt worden ist. [Rya03] Die neueste Version von PGP, PGP Desktop, bietet auch die Möglichkeit die gesamte Festplatte sowie Teile dieser zu verschlüsseln, um gegen diese Art von Angriff vorzugehen.

Trojanisches Pferd Trojanische Pferde, kurz Trojaner, sind Computerprogramme, die als funktionelles Programm getarnt sind, aber im Hintergrund schädlichen Code beinhalten, welche das Betriebssystem oder Programme wie PGP infizieren können. Ein Angreifer könnte mithilfe des Schadcodes den Klartext einer Nachricht, die geschützte Passphrase oder auch den privaten Schlüssel erhalten. [Rya03] In dem Zeitalter des Internets fungiert dieses als zentrale Downloadstelle jeglicher Software. Nur selten wird die Software vor oder nach dem Download bzw. der Bedienung auf die Originalität überprüft. Vor allem bei PGP und anderen Verschlüsselungsprogrammen ist es bedeutsam, dass das Softwarepaket von einem vertrauenswürdigen Anbieter heruntergeladen bzw. auf die Echtheit überprüft wird, da der Quellcode von vielen PGP Versionen öffentlich zugänglich ist und ein Betrüger eine schädlich modifizierte Version zum Download anbieten kann. Diese veränderte Version könnte sich im Betrieb wie die „echte“ PGP-Software verhalten, aber Signaturen nicht ordnungsgemäß überprüfen, die Zufallszahlgenerierung, welche bei der Schlüsselgenerierung ihren Einsatz findet, könnte manipuliert worden sein oder die erzeugten Schlüssel könnten im Hintergrund, ohne Wissen des Betreibers, an einen Angreifer übermittelt werden. Die Folgen der Verwendung einer modifizierten Version PGPs wären verheerend. [Rya03] Umso wichtiger ist es den Endbenutzer über diese Risiken und mögliche Vorgehensweisen aufzuklären. Benutzer sollten ihre PGP Kopie nur von vertrauenswürdigen Seiten beziehen und die Checksumme von vertrauenswürdigen Seiten, mit denen des Softwarepakets vergleichen. [Rya03]

Nicht-Technische Angriffe Alle zuvor genannten Angriffe setzen ein gewisses Maß an technischem Know-how voraus, doch es gibt auch nicht-technische Angriffe, die billiger, effektiver und meist auch effizienter agieren.

28 1. PGP

Bewusst wird einem wie solche Angriffe stattfinden, wenn man sich den potenziellen Angreifer nicht als anonymen Hacker, sondern als einfachen Arbeitskollegen vorstellt. Dieser benötigt weder aufwändige Trojaner oder ähnliche Schadsoftware um an die gewünschten Informationen zu gelangen. Mittels Social Engineering und einfachem „Shoulder Surfing“, eine Beobachtungstechnik, bei der man versucht geschützte Informationen wie Passwörter oder PINS durch einfaches über die Schulter schauen zu erhalten, kann dieser leicht in Besitz der PGP Passphrase gelangen. Somit müssen sich die Benutzer nicht nur über technische Risiken und Schwachstellen im Klaren sein. [Rya03]

Kollisionsangriffe auf die Key-IDs Diese Art von Angriff fällt ebenfalls in die Kategorie der nicht-technischen Angriffe, da sie nicht die Implementierung von PGP bzw. GPG an sich angreift, sondern darauf abzielt das Opfer zu täuschen. Ziel dieses Angriffes ist es sich für einen anderen User auszugeben bzw. einen Benutzer davon zu überzeugen, dass der Schlüssel des Angreifers der Schlüssel eines anderen (legitimen) Kommunikationspartners ist. [SeS16] PGP verwendet in der Regel Schlüssel in der Länge von 1024 bis zu 8096 Bit. Wie schon in Kapiteln zuvor erläutert [siehe Kapitel 1.2.1 – Schlüsselaufbau] sind diese Schlüssellängen für den Benutzer sehr unhandlich und so behilft man sich eines digitalen Fingerabdrucks. Bei diesem Fingerabdruck handelt es sich um den Hashwert des jeweiligen öffentlichen Schlüssels, welcher als Hilfestellung bei unterschiedlichen Schlüsselverwaltungsaufgaben und der Kennzeichnung des Schlüssels dient. Da dieser Hashwert aus 128Bit bei MD5 und 160Bit bei SHA1, dargestellt als Hexadezimalzahlenkette, besteht und für den User immer noch zu unhandlich ist, greifen viele Benutzer und auch Programme auf die letzten 8 Stellen des Fingerprints zurück. Diese Stellen werden als Short Key ID bezeichnet. Die dazugehörige Long ID besteht aus den letzten 16 Ziffern des Fingerabdrucks. Nachfolgend ein Beispiel:

Fingerprint: 0D29 F56F 12BD BA07 7B37 15AB 851F 799A B4FF 1057 Long ID: 851F 799A B4FF 1057 Short ID: B4FF 1057

Eine jede Hashfunktion bildet eine Zeichenfolge beliebiger Länge auf eine Zeichenfolge fester Länge ab [siehe Anhang – Hash(funktion)]. Da Hashwerte von der Länge sowie von der Zeichenanzahl beschränkt sind, ist es möglich, dass zwei oder mehrere unterschiedliche Inputs den gleichen Hashwert aufweisen. Dieses Vorkommen wird als Kollision bezeichnet und ein potenzieller Angreifer nutzt diese Gegebenheit für den hier beschriebenen Kollisionsangriff aus. Denn obwohl die Chance einer Kollision bei Hashwerten sehr gering ist, ist die Wahrscheinlichkeit einer identen Short ID, bei einer Länge von 8 Ziffern, deutlich höher. So zielt der Angreifer darauf ab, einen Schlüssel zu erzeugen, der die selbe Short ID, wie ein Schlüssel eines anderen Users aufweist, nur um sich anschließend für diesen auszugeben und weitere Benutzer zu täuschen. [SeS16]

29 1. PGP

Laut evil32 einem Projekt von Richard Klafter und Eric Swanson benötigt man mit einem neuwertigen Grafikprozessor rund 4 Sekunden um eine Kollision von 32Bit Key IDs zu generieren. Für die Schlüsselgenerierung wurde das Programm Scallion verwendet. (frei verfügbar unter der Adresse: https://github.com/lachesis/scallion) Schon seit 2011 ist diese Art von Kollisionsangriff bekannt. Zu dieser Zeit zeigte Asheesh Laroia, ein Softwareentwickler, demonstrativ die erfolgreiche Erstellung einer Kollision eines Schlüssels, in Bezug auf die Short ID, und auch im „RFC 4880: OpenPGP Message Format“ im Kapitel 3.3 steht beschrieben, dass nicht davon ausgegangen werden soll, dass Schlüssel-IDs einzigartig sind. Ebenfalls erwähnenswert ist die Tatsache, dass sowohl für Linus Torvalds, Initator des Linux-Kernels und Erfinder der Versionsverwaltungssoftware Git, als auch für Greg Kroah-Hartman, einer der bekanntesten Linux-Kernel-Entwickler, falsche Schlüssel mit einer identen Short Key-ID gefunden worden sind. Schlüssel solch bekannter und einflussreichen Personen können in den Händen von Angreifer zu wertvollen Werkzeugen werden und erheblichen Schaden anrichten. [SeS16] Letztendlich ist die Verwendung einer Short ID nicht unsicher. Vielmehr dienen die Schlüssel-IDs der Erleichterung von Verwaltungsaufgaben und nicht der Validierung von Schlüssel. Hierfür ist es notwendig den gesamten Fingerabdruck eines Schlüssels zu kontrollieren bzw. zu vergleichen. Das alleinige Kontrollieren der ID stellt jedoch ein enormes Risiko dar. [SeS16]

30 1. PGP

Fehlende Überprüfung der Keyserver Schlüsselserver bieten Zugang zu öffentlichen Schlüsseln, unterstützen die Schlüsselverbreitung und sind ein wichtiger Bestandteil des Web of Trusts [siehe Kapitel 1.2.2 – Schlüsselverwaltung]. Dennoch weisen Keyserver einige Problematiken auf. So ist es einem Benutzer bei einem Großteil der Schlüsselserver nicht möglich zuvor publizierte Schlüssel bzw. Teile von Schlüssel zu löschen oder zu widerrufen. Sollte ein Benutzer das für das Schlüsselpaar benötigte Passwort vergessen haben oder der öffentliche Schlüssel kompromittiert worden sein, so ist dieser auch weiterhin auf dem Keyserver verfügbar und für andere User ersichtlich. Nur wenn der User zuvor ein Widerrufszertifikat erstellt hat, ist es ihm bei einem Teil der Keyserver möglich seinen Schlüssel zu widerrufen. Ein User verliert jegliche Kontrolle über die Verbreitung eines Schlüssels sobald dieser auf einen Keyserver übertragen wird. Da es sich hierbei jedoch immer um einen öffentlichen Schlüssel handelt und dieser in der Regel publik zugänglich sein sollte, hält sich die Problematik in Grenzen. Beim Vergessen des Kennwortes eines Schlüsselpaares ist es dem Benutzer nicht mehr möglich neue Nachrichten zu signieren bzw. zu entschlüsseln. Eine weitaus größere Gefahr geht von der fehlenden Überprüfung der Schlüsselserver bezüglich der Authentizität von Schlüsseln aus. Ein Jeder kann einen Schlüssel mit einem beliebig gewählten Namen und einer beliebigen E-Mail-Adresse erstellen. Der Schlüsselserver verifiziert nicht ob der Schlüssel tatsächlich zu der angegebenen Person gehört oder ob der Schlüsselbesitzer über die, in der Benutzer-ID angegebene, E-Mail- Adresse verfügt. Daher befinden sich auf den unterschiedlichen Schlüsselservern eine Vielzahl von nicht vertrauenswürdigen und gefälschten Schlüsseln. Um gegen die soeben beschriebenen Probleme vorzugehen, stellt die Symantec Corporation das PGP Global Directory, ein kostenloser, frei zugänglicher Keyserver zur Verfügung. Dieser Schlüsselserver nutzt laut eigenen Angaben eine Keyserver- Technologie der nächsten Generation und verfügt zusätzlich zu den herkömmlichen Aufgaben über neue Funktionen. So besteht die Möglichkeit der Entfernung von Schlüsseln und ebenfalls wird die Authentizität eines Schlüssels beim Hinzufügen überprüft. Mittels Verifizierungsnachrichten, die an die in der Benutzer-ID eingetragenen E-Mail-Adresse versendet werden, wird überprüft, ob der Schlüsselbesitzer tatsächlich über die Mail-Adresse verfügt. Erst nach dem erfolgreichen Antworten auf diese Nachrichten und das Bestätigen des Hinzufügevorganges, wird der Schlüssel in dem Verzeichnis hinterlegt. Zusätzlich führt das PGP Global Directory alle sechs Monate eine erneute Verifizierung der Schlüssel durch. Hierfür wird erneut eine Verifizierungsnachricht an den Schlüsselbesitzer versendet. Antwortet dieser in der Zeitspanne von zwei Wochen nicht auf die Nachricht, wird der hinterlegte Schlüssel aus dem Verzeichnis entfernt. Diese Funktion stellt sicher, dass alle auf dem Keyserver hinterlegten Schlüssel stets aktuell und valide sind. Das PGP Global Directory ist ein eigenständiger Keyserver, welcher sich nicht mit anderen Schlüsselserver synchronisiert. [SC16]

31 1. PGP

HTTP Keyserver Protocol – HKP Die gesamte Kommunikation mit einem Schlüsselserver findet mit dem sogenannten HTTP Keyserver Protocol statt. Dieses Protokoll findet bei einer jeden Interaktion, so zum Beispiel beim Veröffentlichen eines Schlüssels, bei der Suche nach einem Schlüssel oder bei einem einfachen Synchronisationsablauf mit dem Server, ihren Einsatz. Da dieses Protokoll, wie der Name schon vermuten lässt, auf dem http-Protokoll (HyperText Transfer Protocol) aufbaut und genauso wie dieses alle Informationen unverschlüsselt überträgt, birgt es einige Risiken. So können alle übertragenen Informationen von allen Rechnern und anderen Geräten, die sie im Netzwerk durchlaufen mitgelesen und von potenziellen Angreifern eingesehen und manipuliert werden. Eine Lösung um gegen dieses Problem vorzugehen, bietet das HTTP Keyserver Protocol over HTTPS (HKPS). Dieses Protokoll baut auf dem sicheren Übertragungsprotokoll HTTPS (HyperText Transfer Protocol Secure) auf, welches alle Daten vor der Übertragung mittels SSL/TLS verschlüsselt und somit die Identität des Verbindungspartners und vor Man-in-the-Middle-Angriffen schützt. Einige der öffentlich zugänglichen Schlüsselserver, so auch das zuvor genannte PGP Global Directory, verwenden das sichere HKPS-Protokoll bereits, dennoch gibt es eine Vielzahl von Schlüsselserver, welche nur das HKP-Protokoll unterstützen. [Vdm14] Eine weitere Vorgehensweise bietet die Verwendung des Parcimonie Bash Scripts, welches alle Synchronisationsverbindungen mit dem Server über eine neue Tor-Verbindung aufbaut. [EP16] Bei Tor handelt es sich um ein Anonymisierungsnetzwerk.

32 2. Applikation

2. Applikation Dieses Kapitel der Arbeit umfasst das Konzept der Applikation, eine Dokumentation vom Aufbau bis hin zur Umsetzung, sowie zukünftige Anwendungsszenarien dieser. Die aktuellste Version der Applikation ist auf dem Online-Versionsverwaltungsdienst Git unter https://github.com/danielmdf/KeyExchangeApp zu finden.

2.1. Ziel der Applikation Ziel dieser Arbeit ist es eine Applikation zu erstellen, welche als Hilfestellung für den sicheren Schlüsselaustausch zweier oder mehrerer Personen dient. Augenmerk der Applikation liegt dabei nicht auf der Verwendung und der Verarbeitung von PGP Schlüssel, bzw. die Unterstützung von PGP Schlüssel, vielmehr soll eine Grundlage bzw. ein Framework für zukünftige Schlüsselaustauschapplikationen erstellt werden. Mittels dieser App ist es möglich kryptographische Schlüssel, zum Beispiel den eigenen privaten sowie öffentlichen Schlüssel, in Form eines QR-Codes einzuscannen und in der App zu hinterlegen. Zusätzlich können der eigene öffentliche Schlüssel, in Form einer QR-Code Matrix, dargestellt und öffentliche Schlüssel potenzieller Kommunikationspartner eingescannt werden. Die (öffentlichen) Schlüssel der User werden in einer Listenansicht gespeichert und dargestellt. Für jeden Eintrag in dieser übersichtlichen Darstellungsform gibt es eine weitere Detailansicht, des jeweiligen Schlüssels. In dieser ist es möglich Schlüssel mit dem eigenen privaten Schlüssel zu signieren und Schlüssel samt Signaturen per Mail oder Instant Messaging Dienst zu verschicken. Somit soll der Vorgang des Schlüsselaustauschs, speziell bei Keysigning-Partys, unterstützt und vereinfacht werden. Überdies verfügt die Applikation über eine Challenge-Response Funktion. Ziel dieser Funktion ist die Durchführung einer Überprüfung ob die Authentizität des präsentierten öffentlichen Schlüssels gegeben ist, indem ein wahlfreier Text in verschlüsselter Form als QR-Code dargestellt wird. Diese Matrix wird von dem anderen User, mittels App, eingescannt und automatisch mit dem als privat gekennzeichneten Schlüssel dechiffriert. Stimmen nun der Ausgangstext mit dem Eingabetext überein, ist sichergestellt, dass der User über beide Schlüssel des Paares verfügt.

2.2. Alternativen zur Applikation 2.2.1. APG Android Privacy Guard (APG) ist ein freies Open Source Softwarepaket für Android. APG stellt alle für die Verwendung des OpenPGP Standards benötigten Funktionalitäten zur Verfügung und basiert auf den Spongy Castle APIs. Seit März 2014 wurde das Android Privacy Guard Projekt nicht mehr upgedatet, wird nicht mehr länger entwickelt und wurde mittlerweile von einem neuen Projekt namens OpenKeychain ersetzt.

33 2. Applikation

2.2.2. OpenKeychain: Easy PGP Bei OpenKeychain handelt es sich um eine freie Implementierung des OpenPGP- Standards für Android-Geräte. Diese, im Jänner 2013 veröffentlichte, Applikation ermöglicht grundlegende Funktionen wie das Signieren, Entschlüsseln, Verschlüsseln, Verifizieren, Importieren und Exportieren von GPG-Schlüssel, sowie eine umfassende Schlüsselverwaltung. Die aufgezählten Funktionen können sowohl auf E-Mails, Dateien und Texte angewendet werden. Bei der Verschlüsselung von Mails weist OpenKeychain einen interessanten neuen Ansatz auf. Denn im Gegensatz zu anderen bekannten Applikationen für einen sicheren E-Mail-Austausch fokussiert sich diese Applikation auf eine automatische end-to-end Verschlüsselung bei der eine jede Mail autonom und ohne Benutzereingriff chiffriert wird, sobald der (öffentliche) Schlüssel des Mailempfängers vorliegt. Ebenso, wie die im Zuge dieser Arbeit entwickelten App, findet bei OpenKeychain eine Verwendung von QR-Codes statt. Jedoch wird nicht der Schlüssel an sich beim Austausch mittels QR-Code übertragen, sondern nur der Schlüsselfingerabdruck wird für die Verifizierung des Schlüssels übermittelt. Dadurch wird der Signing-Prozess an sich unterstützt und für den Enduser vereinfacht werden. [SB16] 2016 publizierte das deutsche Bundesamt für Sicherheit in der Informationstechnik eine von ihr finanziell geförderte Studie, welche die aktuell verfügbaren OpenPGP- Implementierungen für mobile Android-Endgeräte auf unterschiedliche Anforderungen prüft. [BSI17] Obwohl die Studie aufzeigt, dass zum aktuellen Zeitpunkt der Erhebung, keine der getesteten Implementierungen eine ausgereift und umfassende Lösung der geforderten Nutzungsszenarien aufweist, wurden vor allem OpenKeychain und GnuPG for Android positiv hervorgehoben und weisen laut den beiden Unterauftragnehmern Dominik Schürmann und Vincent Breitmoser das größte Potenzial auf. [BSI17]

2nd2nd3rd Gnu Privacy Guard (GnuPG) for Android Die beiden Mitglieder der Entwicklergemeinschaft Guardian Project Hans-Christoph Steiner und Abel Luck entwickeln seit Dezember 2011 an der GnuPG Implementierung für Android Endgeräte. Doch trotz dem vielversprechenden Entwicklerteam schnitt die Applikation in der Studie zur Nutzun von OpenPGP auf Android sehr schlecht ab. Beim Testen brach der Installationsvorgang beim erstmaligen Ausführen der App ab, die Schlüsselsuche funktionierte nicht und das Erstellen von neuen Schlüsseln funktionierte während der gesamten Erhebung nicht. Anders als die meisten OpenPGP- Implementierungen setzt diese Applikation auf eine für Android kompilierten Version von GnuPG anstelle der sonst verwendeten Java-Implementierung. Zusätzlich setzt GnuPG for Android auf eine Hybridlösung, da Android-spezifische Teile in Java implementiert sind und über Java Native Interface (JNI) mit der GPGME-Bibliothek kommunizieren. Von den getesteten Applikationen schnitt GnuPG for Android am schlechtesten ab. [BSI17] Auf der offizien Webseite des Guardian Projects ist mittlerweile vermerkt, dass das Projekt der Applikation nicht mehr gepflegt wird und stattdessen wird OpenKeychain empfohlen. [GP17]

34 2. Applikation

2nd2nd4th Monkeysign: OpenPGP Key Exchange for Humans Monkeysign ist ein Ansatz einer Schlüsselaustausch App mit dem Ziel, diese möglichst intuitiv zu gestalten und die Abläufe im Hintergrund autonom auszuführen, damit, so auf der offiziellen Webseite beschrieben, auch die einfachsten Primaten das Tool verstehen und verwenden können. Monkeysign bietet hierfür zwei unterschiedliche Interfaces: ein Kommandozeilen-Interface namens monkeysign und eine grafische Oberfläche mit dem Namen monkeyscan, bei welcher die hexadezimalen Schlüssel in Form von QRCodes dargestellt und per Scan ausgetauscht werden.

2.3. Implementierung Dieses Unterkapitel behandelt die einzelnen Komponenten der Programmierung, von der Programmierumgebung bis zur Erstellung der Anwendung, begleitet von Erläuterungen der Plattformwahl sowie Codebeispielen.

2.3.1. Plattform Das von der Open Handset Alliance entwickelte Android-System ist eine Software, basierend auf dem Linux-Kernel, welche als Betriebssystem und Software-Plattform für unterschiedliche mobile Geräte angeboten wird. Vor allem die Tatsachen, dass es sich um eine freie Software, welche quelloffen entwickelt wurde, die Unterstützung der Entwicklungsumgebungen sowie der weltweite Marktanteil von nun knapp 88% im Bereich der Smartphone Betriebssysteme, waren Beweggründe diese Plattform für die Programmierung der Applikation zu verwenden. [LS16] Des Weiteren bietet Android eine Vielzahl von Entwicklungswerkzeuge und Funktionalitäten für die Programmiersprache Java, deren Laufzeitumgebung und dessen Klassenbibliotheken.

2.3.2. Android-Versionen Nachfolgend zur Auswahl der Entwicklungsplattform ist die Bestimmung der zu verwendeten Android-Version entscheidend. Je höher die zugrundeliegende Version und das damit zusammenhängende API Level sind, desto geringer ist der Smartphone-Anteil, welche die Applikation in weiterer Folge überstützen. Im Gegenzug dafür, bieten neuere Android-Versionen zusätzliche Funktionen und Möglichkeiten der Programmierung von Applikationen. Die Abbildung 14 ist eine visuelle Darstellung der Verteilung aller Android Versionen. Diese Statistik bezieht sich auf alle Geräte, welche in einem Zeitraum von 7 Tagen auf die Google Play Store App zugegriffen haben. (Stand 09.12.2016) Die Applikation dieser Arbeit bezieht sich auf die neueste Android Version, mit einem API- Level von 24. Jedoch ist das Minimum API-Level auf 15 gesetzt, damit auch ältere Geräte alle Funktionalitäten ordnungsgemäß nutzen können. Somit kann ein einwandfreies Arbeiten dieser Applikation auf rund 99% aller aktuellen Android-Geräte gewährleistet werden.

35 2. Applikation

Abb. 11: Google App Store Zugriffe, 7-Tage-Zeitspanne (Stand 07.12.2016)

2.3.3. Entwicklungsumgebung Bei der Programmiersprache fiel die Wahl auf Java, da Android Apps zu einem Großteil in Java programmiert werden und alle für die Applikation notwendigen Android-Bibliotheken in Java zur Verfügung stehen. Das von Google entwickelte Android Studio diente als Entwicklungsumgebung. Dessen aktuelle Version 2.1.2 (Stand 09.12.2016), welches auf IntelliJ IDEA basiert, ermöglicht ein komfortables Entwickeln von Android Applikationen, das ausgiebige Testen dieser, auf den zur Verfügung gestellten Emulatoren, samt einer Vielzahl von Funktionen, die das Erstellen einer Applikation unterstützen.

2.4. Benutzeroberflächen Seit der Konzeption der Applikation war es wichtig, die App schlicht und funktionell zu halten. Um dies zu realisieren, wird auf zwecklose Elemente und Grafiken gänzlich verzichtet. Im Vordergrund steht stets die Funktionalität und die Anordnung der einzelnen Bausteine, sodass ein intuitives Arbeiten realisiert wird.

2.4.1. Startmenü Beim Öffnen der Applikation erscheint als erstes das Startmenü bzw. das Startmenü- Layout, welches in weiterer Folge als Hauptmenü referenziert wird (siehe Abbildung 15). Das Hauptmenü ist einfach gehalten und enthält lediglich einige Buttons, die es dem Benutzer ermöglichen zu den jeweiligen Unterpunkten zu navigieren. Diese Buttons sind der Reihe nach:

36 2. Applikation

Own Private Key: um zur Verwaltungsoberfläche des eigenen privaten Schlüssels zu gelangen Own Public Key: das Gegenstück zum ersten Button, um den eigenen öffentlichen Schlüssel zu verwalten All Public Keys: um zur Listenansicht aller gespeicherten öffentlichen Schlüssel (mit Ausnahme des eigenen öffentlichen Schlüssels) zu navigieren Add A Public Key: um zum Layout zu wechseln, welches das Einscannen und Hinzufügen eines öffentlichen Schlüssels ermöglicht Challenge Response: beim Betätigen dieses „Buttons“, wird in die QR-Code- Scan Ansicht gewechselt

Jeweils die ersten beiden Knöpfe, als auch die zwei Darauffolgenden sind von der vertikalen Anordnung gruppiert, um dem User eine leichtere Unterscheidung zwischen den Menüpunkten, betreffend der eigenen bzw. der fremden Schlüssel zu symbolisieren und diese Abgrenzung visuell zu unterstreichen. In der grünen Kopfleiste des Hauptmenüs ist der Applikationsname „KeyExchangeApp“ hinterlegt, gefolgt von einer Textview mit einem kurzen Begrüßungstext. Diese Kopfleiste bleibt bei allen weiteren Layouts, mit Ausnahme der QR-Code-Scan-Ansicht, im oberen Displaybereich erhalten.

37 2. Applikation

Abb. 12: Main Activity Layout

2.4.2. Own Private Key Der erste Menüpunkt im Hauptmenü ermöglicht das Wechseln zum Private Key Layout. Dieses dient zur Administration des eigenen privaten Schlüssels. In diesem Layout gibt es lediglich einen Knopf mit der Aufschrift „Save/Change Private Key“ und einer Textview unterhalb, die solange kein Schlüssel eingescannt und als privater Schlüssel deklariert wurde, leer ist. Beim Betätigen des Buttons öffnet sich die Kameraansicht und der QR- Scanner startet. In dieser Ansicht wird das von der Kamera fokussierte Bild auf einen QR- Code untersucht und sobald von der Kamera ein QR-Code erkannt wird, beginnt die App mit der Dekodierung des Codes. Anschließend wird der Inhalt des Codes in einen String mit dem „PRIVATE KEY“-Tag gespeichert und in der zuvor erwähnten Textview angezeigt. In diesem Feld wird nicht der String an sich ausgegeben, hingegen wird dieser zuvor in ein Private Key Objekt gewandelt und anschließend wird dessen Inhalt ausgegeben. Ist bereits ein Schlüssel gespeichert worden und man führt diesen Durchgang erneut aus, so wird der bereits hinterlegte Wert mit den neu eingescannten Daten überschrieben. Beim erfolgreichen Scannen und Speichern eines Schlüssels wird am unteren Displayrand eine Meldung, in Form eines Toasts, die das erfolgreiche Hinzufügen bestätigt angezeigt. Das Layout sowie die Toast Meldung sind in den Abbildungen 16, 17 und 18 ersichtlich.

38 2. Applikation

Abb. 13: Private Key Layout Abb. 14: Scan-View

Abb. 15: Toast-Meldung nach dem erfolgreichen Scannen

2.4.3. Own Public Key Das Own Public Key Untermenü beschäftigt sich mit der Administration des eigenen öffentlichen Schlüssels. Anders als im vorherigen Menüpunkt, gibt es in diesem Layout zwei Buttons und eine Textview (siehe Abbildung 19). Der erste Button mit dem Text „Add/Change Own Public Key“ fungiert wie der Hinzufüge-Button der Own Private Key Ansicht, lediglich wird der hier eingespeicherte Schlüssel mit dem Tag „PUBLIC KEY“ abgespeichert. Der zusätzliche zweite Button „Show Own Public Key“ ermöglicht die Ausgabe des eigenen, zuvor eingescannten und gespeicherten Schlüssels als QR-Matrix. Nach dem Betätigen dieses Knopfes wird eine neue View geladen und zentral in dieser wird der gespeicherte String des eigenen öffentlichen Schlüssels, als QR-Code generiert und dargestellt. Abbildung 20 zeigt die Ansicht des hinterlegten öffentlichen Schlüssels in Form einer QR-Matrix. Auch bei diesem Vorgang, wird die erfolgreiche Ausführung mithilfe einer Toast-Meldung, siehe Abbildung 21, visuell unterstrichen.

39 2. Applikation

Abb. 16: Public Key Layout Abb. 17: Show Own Public Key View

Abb. 18: Toast-Meldung nach dem erfolgreichen Speichern

2.4.4. Add A Public Key Zunächst verfügt das Add A Public Key Layout nur über einen einzelnen Button, mit dem Text „Add A Public Key“ (siehe Abbildung 22). Weitere Elemente sind beim Laden dieses Layouts für den User nicht ersichtlich. Beim Klicken auf diesen Button wird, wie schon in den vorherigen Unterpunkten, die View zum Scannen eines Schlüssels aufgerufen. Hat die Kamera nun einen QR-Code erfasst, dekodiert und ausgelesen so gelangt man wieder zurück zum vorherigen Layout, diesmal werden andere Knöpfe und TextView-Elemente sichtbar. Unterhalb des Buttons, zuständig für das Hinzufügen eines Schlüssels, ist ein vertikales LinearLayout hinterlegt, dessen Sichtbarkeit erst durch das erfolgreiche Einscannen eines Schlüssels gegeben ist (siehe Abbildung 23). In diesem Layout befindet sich eine

40 2. Applikation

TextView mit dem Inhalt „Name:“, darunter eine EditText-Box mit dem Standardtext „Name eingeben“ und wiederum eine Ebene darunter ist ein zweiter Button mit der Aufschrift „Public Key Speichern“. Dem Benutzer ist es nun möglich den Namen (des Schlüsselbesitzers) einzutragen. Durch ein einfaches Tippen in die EditText-Box erscheint im unteren Bereich des Displays die Android Tastatur und ermöglicht das Eintragen einer Zeichenkette. Abschließend wird durch das Betätigen des Speicher-Knopfes der eingetragene Name, gemeinsam mit dem zuvor eingescannten Schlüssel, im Speicherbereich des Handys abgelegt. Das erfolgreiche Durchführen dieses Vorgangs wird darauf mit einer kurzen Meldung, einem Toast, veranschaulicht und das Layout wechselt zum Untermenüpunkt „All Public Keys“ (siehe Abbildung 24). Dieses Layout ist ebenfalls durch das Hauptmenü zugänglich.

Abb. 19: Add Public Key Layout Abb. 20: Add Public Key Layout nach dem Scan

2.4.5. All Public Keys Beim All Public Keys Layout handelt es sich um eine simple ListView und einer darüber angeordneten TextView mit dem Inhalt „All Keys:“ (siehe Abbildung 24). Die ListView lädt alle gespeicherten Namen der hinterlegten Schlüssel und stellt diese in Form einer übersichtlichen Liste dar. Neben dem jeweiligen Namen wird zusätzlich der vom dazugehörigen Schlüssel ausgelesene Algorithmus angezeigt. Klickt der User nun auf

41 2. Applikation

einen Eintrag der Liste, gelangt dieser direkt in das DetailKey Layout des jeweiligen Schlüssels.

Abb. 21: ListView Layout

2.4.6. DetailKey Dieses Layout verfügt über wesentlich mehr Inhalte als die bisher erläuterten Untermenüs (siehe Abbildung 25). Im oberen Bereich wird neben den beiden TextView Elementen „ID:“ bzw. „Name:“ der jeweilige Schlüsselbesitzer und dessen ID dargestellt. Bei der ID handelt es sich um eine inkrementierende Nummer, um auch zwischen Schlüsseleinträgen mit gleichem Namen unterscheiden zu können, sowie für administrative Funktionalitäten. Auf gleicher Höhe befindet sich zusätzlich ein „Sign“- Button. Unter diesen, in einem LinearLayout zusammengefassten, Elementen befinden sich drei weitere Knöpfe. Der Oberste ist der rot eingefärbte „Delete Key“-Button, welcher den Schlüssel, samt aller gekoppelten Daten zu diesem Eintrag entfernen lässt. Wird dieser Knopf betätigt, wird der Schlüssel aus dem Speicherbereich entfernt und man gelangt zurück in das darüber liegende All Public Keys Layout. Der „Send Public Key“- Button ermöglicht es dem User, zuvor abgespeicherte öffentliche Schlüssel an andere Personen oder einen Keyserver zu übermitteln. Beim Betätigen dieses Knopfes erscheint am unteren Displayrand eine Abfrage des auszuwählenden Kommunikationsdienstes (siehe Abbildung 27), mit dem man den Schlüssel übermitteln möchte. Hierfür kann eine

42 2. Applikation

Auswahl zwischen dem herkömmlichen E-Mail Client (Abbildung 28), einem Instant Messaging Dienst oder anderen installierten Kommunikationsapplikationen getroffen werden. Wählt der User zum Beispiel den auf dem Gerät konfigurierten E-Mail Dienst, wechselt das Smartphone in die Mailapplikation, erstellt eine neue Mail und fügt automatisch den Namen des Schlüsselbesitzers in den Betreff ein. Im sogenannten Body der E-Mail wird der Public Key Block und falls vorhanden, die Signatur in Form eines Signaturblockes eingefügt. Der dritte Knopf „Create Challenge“ ist gelb hinterlegt und ermöglicht dem User das Erstellen einer Challenge. Wird dieser Knopf gedrückt erscheint anstelle des „Create Challenge“-Buttons ein EditText Eingabefeld und ein neuer Button mit der Aufschrift „Show Challenge“ wird angezeigt. Standardmäßig ist der Text „Enter Challenge Here“ in dem EditText-Element eingetragen. Dieser kann nun, mittels der Android Tastatur, beliebig angepasst werden. Wird anschließend der „Show Challenge“ Knopf ausgewählt so gelangt man in ein neues Layout, in der die Eingabe mit dem öffentlichen Schlüssel verschlüsselt, als QR-Code angezeigt wird. Das Gegenstück hierzu, ist der im Hauptmenü unten angeordnete Button „Challenge Response“. Gedacht ist diese Challenge wie folgt. Ein User möchte überprüfen ob der öffentliche Schlüssel seines Kommunikationspartners der angegebenen Person gehört bzw. ob dieser über den dazugehörigen privaten Schlüssel verfügt. Nachdem der öffentliche Schlüssel mit der App eingescannt und ein neuer Benutzereintrag in der Liste angelegt wurde, öffnet der Benutzer die DetailKey-Ansicht des Schlüssels und betätigt den „Create Challenge“-Button. Nun kann ein von ihm frei gewählter Text, mit einer Länge von bis zu 30 Charakteren eingegeben und anschließend in verschlüsselter Form als QR-Code angezeigt werden. Dem potenziellen Kommunikationspartner ist es nun möglich, mittels des im Hauptmenü angelegten „Challenge Response“ Knopfes in den Scan Modus zu gelangen und die Challenge in Form eines QR-Codes zu erfassen. Sobald der Code eingescannt und dekodiert worden ist, wird dieser noch zusätzlich mit seinem privaten Schlüssel dechiffriert und in einer bisher nicht sichtbaren TextView, im Hauptmenü, ausgegeben. Ist diese Ausgabe mit der Eingabe des Prüfenden ident, kann darauf geschlossen werden, dass der User über den dazugehörigen privaten Schlüssel verfügt und somit die Authentizität der Schlüssel gegeben ist. Unterhalb, all dieser zuvor beschriebenen Elemente, sind insgesamt acht TextView- Felder, welche jeweils als Paare fungieren und in einer übersichtlichen Form die Version, den Fingerprint, die Signatur (falls vorhanden, ansonsten wird das TextView Paar ausgeblendet) und den öffentlichen Schlüssel darstellen. Zuletzt verfügt das DetailKey-Layout noch über einen „Sign“-Button in der rechten oberen Displayecke. Mithilfe dieses Knopfes wird die Signier-Methode aufgerufen und der jeweilige ausgewählte Schlüssel mit dem, als eigenen privaten Schlüssel deklarierten, Schlüssel signiert. In Folge dessen erscheint das TextView-Paar mit der soeben erstellten Signatur und am unteren Displayrand zeigt eine Meldung, ein Toast, an, dass der Signiervorgang erfolgreich durchgeführt worden ist. Im Zuge der Signier-Methode wird außerdem der Text des Sign-Buttons auf „Signed“ abgeändert und er wird nicht mehr klickbar, ersichtlich in der nachfolgenden Abbildung 26.

43 2. Applikation

Abb. 22: DetailKey Layout Abb. 23: DetailKey Layout mit Signatur

44 2. Applikation

Abb. 24: Send Public Key Auswahl Applikation Abb. 25: Schlüsselversand per Mail Applikation

45 2. Applikation

2.5. Standardszenario

Abb. 26: Standardszenario

An dieser Stelle wird das für die KeyExchange-App angedachte Szenario, visuell in Abbildung 29 dargestellt, erläutert. Dieses besteht aus mehreren Abschnitten, beginnend bei der Erstellung eines Schlüsselpaares. Für diesen Vorgang stehen eine Vielzahl von unterschiedlichen Programmen zur Verfügung. Die neueste PGP Version, PGP Desktop, bietet für das Erstellen eines Schlüsselpaares eigens einen Generierungs-Assistenten, mit grafischer Oberfläche, welcher als Hilfestellung dient und auch Personen die mit der Thematik nicht vertraut sind durch diesen Vorgang leitet. Hat sich der User für ein Programm entschieden, kann mit der Schlüsselgenerierung begonnen werden. Hierfür benötigte Angaben sind eine E-Mail-Adresse, der Name bzw. die User-ID, der Schlüsseltyp, die gewünschte Schlüssellänge sowie das Ablaufdatum des Schlüssels. Abschließend ist noch die Eingabe eines Kennwortes, mit dem das zukünftige Schlüsselpaar, bzw. der private Schlüssel, geschützt wird notwendig. Die Wahl dieses Passwortes sollte mit Sorgfalt gewählt werden, da ein schwaches Kennwort ein Sicherheitsrisiko darstellt. Wie schon in vorherigen Kapiteln erläutert ist das Angriffsziel meist nicht der Algorithmus oder der Schlüssel an sich, vielmehr steht das Passwort im Fokus von Angriffen um sich den privaten Schlüssel eines Users anzueignen. Je nach verwendeter Software wird die Schlüsselgenerierung oft anhand von Zufallswerten, durch vom User randomisierte Mausbewegungen und Tastatureingaben, unterstützt. PGP Desktop bietet nach der erfolgreichen Erstellung der Schlüssel zusätzlich die Möglichkeit den soeben erstellten öffentlichen Schlüssel an einen Keyserver zu übermitteln. Der nächste Schritt ist die Konvertierung der jeweiligen Schlüssel in eine QR-Code-Matrix, damit diese vom QR-Code-Scanner der Applikation erfasst und die Schlüsselübertragung auf das Smartphone oder Tablet durchgeführt werden kann. Softwarepakete wie QR- Code-Generatoren eignen sich ideal hierfür. Für die Konvertierung des öffentlichen Schlüssels können auch online QR-Code-Generierungstools verwendet werden, da die Verbreitung des öffentlichen Schlüssels keinerlei Problematiken verursacht. Der private Schlüssel sollte allerdings keinesfalls mit Onlinetools bearbeitet werden. Hierbei ist zu beachten, dass auch lokal installierte Software im Hintergrund keinerlei Verbindungen aufbauen und der private Schlüssel nicht an Dritte übertragen wird. Sobald die Schlüssel in Form von QR-Codes zur Verfügung stehen, können diese mittels der KeyExchange- App eingescannt werden. Die ersten beiden Menüpunkte „Own Private Key“ beziehungsweise „Own Public Key“ lassen den User in die dafür vorgesehenen Untermenüpunkte wechseln. Beim Scannen der Matrizen ist darauf zu achten, dass diese nicht bedeckt sind und auch Spiegelungen oder andere Sichtbeeinträchtigungen sollten vermieden werden. Das erfolgreiche Scannen und Speichern der Schlüssel wird mittels 46 2. Applikation

kurzen Toast-Meldungen am unteren Displayrand angezeigt. Ein Button im Untermenüpunkt „Own Public Key“ ermöglicht das Anzeigen des eigenen öffentlichen Schlüssels, in Form eines QR-Codes. Diese Funktion wird für den Vorgang der Schlüsselübertragung benötigt, auf den diese Applikation abzielt. Bei Ereignissen wie Keysigning-Partys oder anderen Veranstaltungen, mit dem Hauptaugenmerk auf die Verteilung, das gegenseitige Verifizieren und anschließende Signieren von Schlüsseln, unterstützt die Applikation all diese Vorgänge. Die App ermöglicht das Einscannen und Hinzufügen öffentlicher Schlüssel anderer User und ist der eigene private Schlüssel hinterlegt, können Schlüssel signiert werden. Da ein QR- Code als Darstellungsform gewählt wurde, wird die Handhabung der sonst unhandlichen Schlüssel vereinfacht und eine rasche Verbreitung wird ermöglicht. Im Anschluss kann der User entscheiden ob er den Signaturvorgang direkt am Smartphone durchführen möchte oder ob dies auf einem anderen Gerät stattfinden soll. Die Schlüssel und auch die Signaturen lassen sich bequem per Mail an weitere User oder andere Geräte des Users übermitteln. Auch andere, auf dem Smartphone oder Tablet installierte, Kommunikationsdienste können für die Übertragung verwendet werden. Auf diese Weise können weitere User zur verschlüsselten Kommunikation eingeladen oder der soeben signierte Schlüssel an einen Keyserver geschickt werden.

2.6. Anwendungsszenarien Im Anschluss zu der Erläuterung der einzelnen Komponenten der Applikation sowie dessen Funktionsweise, wird nun auf unterschiedliche Anwendungsszenarien eingegangen. Haupteinsatzgebiet der KeyExchange-App ist die unterstützende Verwendung bei Keysigning-Partys, aber auch beim Schlüsselaustausch zweier einzelner Personen, kann die App eingesetzt werden. In den folgenden Use Cases werden drei unterschiedliche User(arten) und die verschiedenen Anwendungsszenarien, welche diese Applikation bietet, erläutert.

Der sicherheitsbewusste Profi Dieser User besitzt ein beachtliches Wissen über die gängigsten Sicherheitstechniken und versucht stets seine Daten bestmöglich zu schützen. Außerdem ist der risikoaverse User des Öfteren bei Keysigning-Partys anzutreffen, tauscht und signiert jedoch nur Schlüssel über deren Authentizität er sich ausgiebig versichert hat. Den eigenen privaten Schlüssel hütet der User unter allen Umständen und den Schlüssel auf sein Smartphone zu laden, obwohl dieses über eine Vielzahl von Sicherheitsfeatures, wie einer Festplattenverschlüsselung, verfügt, erscheint ihm nicht richtig. Vielmehr ist der User im Besitz mehrerer Subkeys für die jeweiligen Einsatzbereiche. Die Applikation und die damit verbundenen Vorzüge, möchte sich der Benutzer nicht entgehen lassen, weshalb der für Keysigning Partys erstellte Subkey mit der Applikation gescannt und als private Key hinterlegt wird. Das problemlose und schnelle Austauschen von Schlüsseln obliegt ganz im Interesse des Users und dank der eingebauten Challenge-Response Funktion, kann er sich zusätzlich über die Authentizität der Schlüssel vergewissern. Die

47 2. Applikation

somit eingescannten Schlüssel werden im Anschluss zu solchen Veranstaltungen per Mail an seinen Computer übermittelt, wo in aller Ruhe die Schlüssel und Signaturen erneut geprüft werden, bevor diese zum Schlüsselbund hinzugefügt werden.

Der Standarduser Im Vergleich zum vorherigen Usecase, hat der Standarduser kein Problem damit, seinen privaten Schlüssel auf sein Smartphone zu transferieren. Dieser User hat schon frühzeitig die Risiken und Schwächen von unverschlüsselten Mails erkannt und möchte zukünftig auf sicherem Weg mit seinen Freunden und Arbeitskollegen kommunizieren. Mithilfe von PGP hat sich der Benutzer ein RSA Schlüsselpaar mit einer Bitlänge von 4096 erstellt und dieses mit einem langen Passwort, das allen Sicherheitsanforderungen entspricht, abgesichert. Anhand dem Untermenüpunkt „Own Private Key“ und dem QR-Code Scanner ist es dem Standarduser möglich den eigenen private Key auf das Handy zu transferieren, sowie die Deklarierung dessen als eigenen privaten Schlüssel. Nachfolgend zu diesem Schritt wird der dazugehörige Schlüssel in eine Matrix gewandelt und mittels Scan übermittelt. Beim anschließenden Treffen mit Freunden sollen die öffentlichen Schlüssel ausgetauscht und signiert werden. Da auch alle anderen beteiligten Personen über die KeyExchange-App verfügen und im Vorhinein ihre eigenen Schlüssel in dieser hinterlegt haben, ist ein problemloses Austauschen, Signieren und Übertragen der Schlüssel möglich. Zeitweise findet auch das Challenge-Response Feature seinen Einsatz um Fehler bei der Übertragung und die Authentizität des jeweiligen Schlüssels zu überprüfen.

Der Sammler Das Hauptaugenmerk dieses Users liegt im schnellen und einfachen Austausch von Schlüsseln. Die Möglichkeit den eigenen Schlüssel auf das Smartphone zu übertragen sowie das Signieren von Schlüsseln werden als Zusatzfeatures angesehen und vom Sammler nur selten genutzt. Ausschließlich der eigene öffentliche Schlüssel ist in der App hinterlegt. Auf Keysigning-Partys werden fremde Schlüssel lediglich eingescannt um im Anschluss per Mail auf den Rechner übermittelt zu werden. Auch zum Verbreiten des eigenen Schlüssels wird die Applikation reichlich genutzt, die Challenge-Response Funktion hingegen findet kaum Einsatz. Bei Arbeitskollegen, Freunden und anderen Kommunikationspartner, denen der User vertraut, setzt dieser auf die Funktionen der Applikation. Hierbei ist der schnelle Austausch per QR-Code ein wichtiger Aspekt. Signiervorgänge, falls diese umgesetzt werden, werden nur auf dem, über den privaten Schlüssel verfügenden, Rechner realisiert.

48 2. Applikation

2.6.1. Bedrohungsmodell Welche Auswirkungen hat es zur Folge, sollte ein Benutzer sein Smartphone verlieren oder gestohlen werden? Sollte es einem Angreifer gelingen sich ein fremdes Smartphone, auf dem sich die KeyExchange-Applikation befindet, anzueignen, so birgt dies ein potenzielles Risiko für den Besitzer des Handys und aller Kommunikationspartner dessen. Da die Applikation bisher über keinerlei Authentifizierungsmethode, wie eine Kennwortabfrage, verfügt, kann der Angreifer auf alle hinterlegte Schlüssel zugreifen. Sollten nur öffentliche Schlüssel. anderer User und des Besitzers gespeichert sein, so ist dies nicht allzu schwerwiegend. Öffentliche Schlüssel sollten stets für Kommunikationspartner zugänglich sein und nur in einzelnen Fällen ist es von einem User nicht erwünscht, dass diese publik sind. Wenn jedoch zusätzlich zu den öffentlichen Schlüsseln der eigene private Schlüssel hinterlegt ist, birgt dies ein weitaus größeres Risiko. Nun ist es dem Angreifer möglich Signaturen für andere Schlüssel auszustellen, Signaturen zu widerrufen und bisher geschützte und verschlüsselte Nachrichten sowie Dateien zu entschlüsseln. Auch die Erstellung von Subkeys wäre ein Ausmaß eines solchen Vorfalls. Als Gegenmaßnahme ist es notwendig, dass der ursprüngliche Besitzer des Smartphones seine Kommunikationspartner über die Kompromittierung, per persönlicher Nachricht oder per Widerrufszertifikat, falls vorhanden, informiert. Filippo Valsorda sieht hierbei eine weitere Problematik von PGP bezüglich der Widerrufung eines Schlüssels [FV16]. Seiner Meinung nach könnten User, die einer möglichen Kompromittierung gegenüberstehen, den Aufwand einer Widerrufung, der neuen Generierung eines Schlüsselpaares und die anschließende Verteilung dessen als zu hoch einschätzen und somit anstelle dessen das Risiko eines kompromittierten Schlüssels ignorieren.

49 3. Evaluation

3. Evaluation Im Zuge dieser Arbeit und um eine nachvollziehbare Bewertung der Applikation zu fertigen, wurde eine ausführliche Evaluation, in Form eines Funktions- und eines Usability-Tests, durchgeführt. In diesem Kapitel werden der Ablauf, die Voraussetzungen sowie die Ergebnisse aufgearbeitet und erläutert.

3.1. Verfahren Um die Applikation auf ihre Funktionalitäten, die Benutzerfreundlichkeit sowie die Effizienz zu überprüfen, fiel die Wahl der Evaluationstechnik auf einen Funktionalitäts- und einen Usability-Test. Diese Art der empirischen Softwareevaluation eignet sich hervorragend um die Gebrauchstauglichkeit einer Software zu überprüfen. Myers beschrieb 1979 mit dem Leitsatz „Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden.“ [Myr91] den Vorgang des Testens und seither hat sich an diesem Grundsatz kaum etwas geändert. Noch heutzutage eignet sich die szenariobasierte Überprüfung eines Testobjekts mit Versuchspersonen bestens für die Evaluation einer Applikation.

3.2. Funktions-Test Bei der Erstellung der Applikation wurden erste Tests der Funktionsweisen sowie das ordnungsgemäße Arbeiten der einzelnen Komponenten, mit dem im Android Studio angebotenen Android Virtual Device (AVD) Feature überprüft. Mittels des Android Virtual Device Managers ist es möglich beliebige Emulatoren, von Android Geräten, zu erstellen, zu verwalten und letztendlich zu löschen. Hierbei ist die Auswahl nicht nur auf Smartphones beschränkt, vielmehr lassen sich alle elektronischen Geräte wie Fernseher, Wearables, unter diesen Begriff fallen tragbare Computersysteme wie Smartwatches und auch Tablets, emulieren. Zunächst wurde für das Testen der Applikation ein Emulator eines Nexus 5, mit einem API-Level von 24, erstellt, da es sich hierbei um ein weit verbreitetes Android-Phone handelt und das API-Level dem Ziellevel der finalen Applikation entspricht. Diesem, im Manager angelegten Device, wurden insgesamt 1536MB RAM, 800MB internen Speicherplatz und 100MB Speicherplatz in Form einer virtuellen SD-Karte zugewiesen. Außerdem wurde die im Laptop integrierte Webcam, eine 720p HD Kamera, als Front-Kamera eingerichtet. Das virtuelle Nexus 5 entspricht vom Funktionsumfang einem originalen Gerät und besitzt keinerlei Einschränkungen. Mit ein paar simplen Konfigurationen ist es zusätzlich möglich den Emulator mit dem Internet zu verbinden, Applikationen aus dem App Store zu laden und bei Eingaben kann die Tastatur des Laptops, ebenso wie die am Display aufgezeigte Tastatur verwendet werden. Im weiteren Verlauf wurden zusätzlich ein Nexus 5 X und ein Nexus 4 emuliert. Auf all diesen Geräten wurden die angebotenen Funktionalitäten der Applikation ausgiebig getestet. Das Einscannen und Anzeigen von Schlüsseln, mittels Webcam, das Löschen von Benutzern wie auch die Challenge-Response Funktion wurden auf die fehlerfreie Implementierung kontrolliert.

50 3. Evaluation

3.3. Usability-Test Zusätzlich zu den Tests mit den Emulatoren wurde die fertige Applikation auf realen Testgeräten mit freiwilligen Testusern geprüft. Bei diesen Benutzertests kamen folgende Geräte zum Einsatz:

Modell: Nexus 4 Android Version: 5.0.1 Build Nummer: LRX22C Seriennummer: 0241f1c6c9cc6e06 API-Level: 21

Modell: Nexus 4 Android Version: 4.2.2 Build Nummber: JDQ39 Seriennummer: 022100c7125909fe API-Level: 17

Testrechner: Systemmodell: HP ZBook 14 G2 Betriebssystem: Microsoft Windows 10 Pro Bereitgestellte Software: Google Chrome (56.0.2924.28), Internet Explorer 11, Editor (Version 1511 Standardapplikation Windows), Microsoft Office 365 ProPlus (16.0.6965.2115), Notepad++ (6.7.5), QR-Code Studio (1.0), Win32 OpenSSL (1.1.0)

KeyExchange-Applikation: Die gesamte Applikation, sowie die letzten Versionen dieser ist unter folgender Adresse zu finden: https://github.com/danielmdf/KeyExchangeApp

Verwendete libraries: open-source library Zxing (“zebra crossing”) verfügbar unter folgendem Link: https://github.com/zxing/zxing (zuletzt aufgerufen am 30.12.2016 um 17:25)

3.3.1. Ziele Ziel des Usability-Tests war die Auswertung der Applikation in Hinblick auf den Funktionsumfang, als auch der Handhabung um mögliche Schwächen sowie Fehlfunktionen aber auch Verbesserungen ausfindig zu machen.

51 3. Evaluation

Die im Laufe dieser Arbeit entwickelte Schlüsselaustausch-Applikation unterstützt das OpenPGP Format bei Schlüsseln nicht. Die Applikation dient lediglich als Framework und das Augenmerk obliegt dem Schlüsselaustausch mittels QR-Codes, nicht der Verwendung von PGP Schlüssel.

3.3.2. Ablauf Der gesamte Ablauf des Benutzertests wurde in mehrere Abschnitte unterteilt. Begonnen wurde mit einer Befragung der Probanden auf ihre Erfahrungen mit Verschlüsselungen, im Genaueren zu Themen wie Public-Key-Verschlüsselungen, der Umgang mit Android-Geräten und das generelle Sicherheitsverständnis. Dieser Abschnitt diente zur Erfassung der Sachkenntnisse der Testuser, um sich einen allgemeinen Überblick über das jeweilige Wissen zu verschaffen. Mithilfe einer kurzen Präsentation wurden die nötigsten Informationen bezüglich Public-Key-Verschlüsselungen erläutert um ein Grundverständnis der Public-Key-Verschlüsselungsverfahren zu liefern sollte es nicht bereits vorliegen. Zusätzlich wurden auf den groben Ablauf des Testes und die Idee sowie die Implementierung der Applikation eingegangen. Daraufhin begann der eigentliche Usability-Test an sich. Zunächst wurden die User beauftragt sich mit Schlüsselerzeugung sowie der Konvertierung der Schlüssel in das für die Applikation benötigte QR-Code-Format auseinander zu setzen. Dieser Abschnitt befasst sich noch nicht mit der KeyExchange-Applikation, sondern nur mit der Schlüsselerzeugung und findet daher auf den extra hierfür bereitgestellten Testrechnern statt. Einer der beiden User begann direkt mit der Suche im Internet nach den gängigsten Programmen und Arten der Schlüsselgenerierung. Der zweite User befasste sich hingegen als Erstes mit den bereits installierten Programmen am Testrechner, um ausfindig zu machen, welche Programme für die Generierung der Schlüssel zur Verfügung standen, ohne weiteren Aufwand betreiben zu müssen. Anschließend öffnete dieser das auf dem Desktop verknüpfte OpenSSL für Windows und begann mit dem Vorgang der Schlüsselpaargenerierung, da ihm dieser Ablauf bekannt war und er schon des Öfteren mit der Thematik zu tun hatte. (Hierbei ist Anzumerken, dass die Testprobanden in Kenntnis gesetzt wurden, dass die Applikation Schlüssel im PKCS8 Format benötigt und somit eine Schlüsselgenerierung mittels PGP nicht möglich ist) Die Abbildung 30 zeigt einen Ausschnitt der Schlüsselgenerierung dieses Users. Kurze Zeit nachdem der erste User bereits sein Schlüsselpaar generiert hatte, begann auch User 2 mit diesem Vorgang, jedoch mit einer Hilfestellung aus dem Internet und des zweiten Testusers. Seine Google Suchanfrage mit den Schlagwörtern „rsa key pair generation“ leitete ihn auf die Webseite wikibooks.org. Dort befindet sich unter der Adresse https://en.wikibooks.org/wiki/Cryptography/Generate_a_keypair_using_OpenSSL (aufgerufen am 26.12.2016 um 11:18) ein Eintrag für die OpenSSL Schlüsselpaar- Erzeugung samt aller möglichen Parameter sowie einer ausführlichen Beschreibung. Mit dieser Hilfe gelang es auch dem zweiten Testprobanden ein Schlüsselpaar zu generieren. Nach etwa 20 Minuten hatten beide Benutzern erfolgreich den ersten Abschnitt abgeschlossen. Der anschließende Exportvorgang konnte ebenfalls von beiden Usern in

52 3. Evaluation

kurzer Zeit durchgeführt werden, doch mit dem darauffolgenden Konvertierungsvorgang des privaten Schlüssels in das für die Applikation benötigte PKCS8 Format hatte einer der User Schwierigkeiten. Mit der in OpenSSL verfügbaren Hilfestellungen war es ihm nicht möglich den Schlüssel erfolgreich zu konvertieren. Erst nachdem erneut die Google- Suchmaschine als Support herangezogen worden ist, diesmal mit den Suchwörtern „rsa key convert to pkcs8“ konnten die Problematiken beseitigt werden. Die so angezeigten Suchergebnisse verwiesen den Probanden zunächst auf einen in der Internetplattform stackoverflow.com, eine Frage- und Antwortplattform zum Thema Softwareentwicklung, gestellten Frageneintrag „Convert PEM traditional private key to PKCS8 private key“. Zwar befand sich auf dieser Seite der für die Konvertierung benötigte Befehl, doch wollte der User sichergehen und besuchte auch noch den zweiten Eintrag der Google- Ergebnisse. Dieser verwies auf die Seite www.herongyang.com. Auf dieser Webseite (aufgerufen am 26.12.2016 um etwa 11:31) befindet sich ein kurzes Tutorial zur Thematik „Mitgrating Keys“, sowie einer kleinen Ansammlung aller notwendigen Befehle für die Schlüsselkonvertierung. Mithilfe dieser war es nun auch dem zweiten Testuser möglich, seinen öffentlichen Schlüssel in das PKCS8 Format zu wandeln.

Abb. 27: Schlüsselkonvertierung eines Probanden

Als nächstes wurden die soeben erzeugten Schlüssel in QR-Matrizen gewandelt, um sie zukünftig mit der KeyExchange-Applikation einzuscannen und somit in der App hinterlegen zu können. Die für Privatanwender frei verfügbare Software QR Code Studio, in der Version 1.0, wurde auf den Testgeräten bereitgestellt und beide User benutzten diese, um die so erstellten RSA Schlüssel in QR-Matrizen zu wandeln. Für diesen Vorgang öffneten einer der User den zuvor exportierten Schlüssel mit dem Windows- Standardprogramm Editor. Der zweite User benutzte den freien Texteditor Notepad++. Mit beiden Programmen war es möglich den Schlüssel in Form von ASCII Zeichen anzuzeigen und den Schlüsselblockinhalt herauszukopieren. Die dadurch in der Zwischenablage hinterlegte Zeichenkette wurde im QR Code Studio eingefügt und durch die einfache Anpassung der Größe, konnten die Schlüssel in Form eines QR-Codes dargestellt werden. Abbildung 31 zeigt einen Ausschnitt der Matrizenerstellung in QR Code Studio.

53 3. Evaluation

Abb. 28: Erstellung der QR-Matrizen im QR-Studio

Im zweiten Abschnitt wurden die mit der App ausgestatteten Testgeräte übergeben und den Usern wurde eine gewisse Zeit gegeben, sich mit dem Gerät sowie der KeyExchange-App auseinanderzusetzen, um sich einen ersten Eindruck dessen zu verschaffen. Diese Phase konzentrierte sich auf den Erstkontakt mit der Applikation, das Übertragen der Schlüssel auf die Testgeräte sowie die Speicherung dieser. Nachdem die Erstellung der QR-Code-Matrizen abgeschlossen wurde, konnte mit dem Transfer der Schlüssel auf die Testgeräte fortgeführt werden. Diese Phase verlief ohne weitere Probleme und dank der Scan-Funktion der App hatten innerhalb kürzester Zeit alle Probanden ihre zuvor erstellten Schlüssel auf das jeweilige Nexus-Phone übertragen. Die User beschrieben den Aufbau und die Gestaltung der App als sehr vorteilhaft. Das Ausbleiben nicht benötigter Grafiken und die gut gewählte Anordnung der einzelnen Buttons beschrieben die Tester zusätzlich als positiv. Um den Usability Test möglichst realitätsnah zu gestalten wurde im dritten Teil des Tests eine Keysigning-Party, im kleineren Ausmaß, simuliert. Die Probanden wurden beauftragt die eigenen Schlüssel zu verbreiten, fremde Schlüssel zur eigenen Sammlung hinzuzufügen, aber auch das Signieren und das Übermitteln der Schlüssel war Teil dieses Tests. Im Gegenteil zu der Schlüsselerstellung, bei der es zu kleineren Komplikationen kam, fiel dieser Teil des Tests bemerkenswert positiv aus. Die KeyExchange-App erwies sich als wertvolles Werkzeug, um die gestellten Aufgaben effektiv und effizient zu erfüllen und so war es allen Probanden möglich die Schlüssel anderer Teilnehmer einzuscannen und in der Applikation mit einem Namen zu versehen. Dank der Verwendung von QR-

54 3. Evaluation

Codes reichte ein kurzes Einscannen der kodierten Schlüssel aus. Nach diesem Schlüsselaustausch begannen die User mit der Übermittlung der Schlüssel. Problemlos konnten die öffentlichen Schlüssel per Mail, per Facebook Chat als auch testweise per WhatsApp an weitere Personen oder dem Testrechner übertragen werden. NOTIZ: Alle bei diesem Testverfahren erstellten Schlüssel wurden anschließend widerrufen.

3.4. Ergebnisse Testproband Matthias Klettner (unverschlüsselter) privater RSA Schlüssel PEM Format (2048 Bit): -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAtL8YM9NzKaTWUIuWeAd3SNcA1Au47fTfQ8YyATV2RNmLSSAJJ vUv6nEu7Cbsh7oKGTT/sg9E4o2ppgzDolRS0sw0UMe3CG5KcbNoDbWpXixfBJ8UdlUIN ky7dmfeYhu5IB/MIjrQ22JAp32uB/xh4+ziTte5QdRBl97bhhEojHGpL+KNp1do1gbE3pPH5t HU0DVNES+CGGM9VSymxmtj6C23FwY10lGwYajlX94Yv8kr895L9V4pxhQDIPbthd44S8 aYd7A8AR7Q9J/hkGgqJFmsmtt678fKjMwh5QhpLs7irSzPObkOdlRoz69x9N7lQS1MLCc7 2eCYVWYWLbblRQIDAQABAoIBAQCQGKka6ECvupKBtEdJeepHT+GBK7dLPiWgyqmi/ RRE34qDyd6CCIciyQk3i/CWZGMYpYAUXMf2NipCD3sIN2GwXMx4ekAZoJQJAZa7F1D nm0hFTu3pSPE7GQF67GQGo0N7sN31jB5mSHZzEWdlRnhkVb42TRWMvcNtaGZrA9Ln 435d5BMN3nxLOASAYtZoh2lfCUMuvMbIYTxI5LYEU6VoORLxTrvJwDJF5D6lazlpedy0jG IyhZIBG54okQLOWlXL9AThfL2Hm+9gmD4lNJSscU3LAg9F/N1UQ3ITtQgQBjchjcp6HUiY uGZB50DU4TfTrYWHDoXySJZvnX9yKV4hAoGBAN8/UNU1wUpXz1hbl5l7m8ofEsluNOI DctalT/tjuM4HLMBUJ9kVSgyQRieHDc9Lq37l1+d6KsQt9Ss7IabdkmY/K+hh0wpXl7Ex0Es aAJEU5EzHwKrpCclVfEHSKTE4mXzBUGPYUVqpTsTx0c7GCgpFX8Z7DgxSPp7fjbktfx WHAoGBAM9DiepfO/45mXVoVXrCZbxr+is+8l3kDzoRz+V4remWELSzksOhQiRvUgVp6g unrxu3tNQLDq+HCr0Q6lkLUtEJ2fzs0O4Qah9s2i1i1Ok28MH0WFd+RltxjlNHouoDEuiHc5/ T0wMlkI/JQo7buOxxGGJGG6t4Cgpukwb2sGHTAoGASytzmUbvXYvxmgvFIP349/a8iayd C9kjatjg9IGgcWcDD4OGo1bCxzYxGRAlez48cY8Mwrlk+weKfNL9QsVqjRkKPMXrnJjfz98 5BoCr3i4NrTi5TBMJo4wwOa19B0DKlbI10li9E+zcQ/40qg4OxWSUmi1HDqkGwtH9U3PZ TbMCgYA9rqvsxErmbd3tww8taY09diUNmb4nkye08HgeorufOLngDVEwR12X2klesxakQ VMrvJBkSqYkNtxLSC12MpiC/ZuSWigTsW7jy1FjEHassV0VW9KutzXZIQJqZndljWSjLyyJ 9FBoL1XGdO8J9Poj48SN+q9haGgUkrPO7ruvYQKBgDhAi0mrjXuaDqlCYRdmF7uR4o+x HthrhWiEL7Mtt0zsNLQnc7yfP0CSBVvNjSuQdJaZqfBX8AqjWN2K3DlOGaLEJXUooTgzv 8GK/fS1tz5vmW0gFUKwFCWn4kITJiHBttq2UE7pOKZy+pDdsII3nzbyhWt2jjNPMoW6Bed 6a3jZ -----END RSA PRIVATE KEY-----

55 3. Evaluation

(unverschlüsselter) privater RSA Schlüssel PKCS8 Format (2048 Bit): -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0vxgz03MppNZQi5 Z4B3dI1wDUC7jt9N9DxjIBNXZE2YtJIAkm9S/qcS7sJuyHugoZNP+yD0TijammDMOiVFLS zDRQx7cIbkpxs2gNtaleLF8EnxR2VQg2TLt2Z95iG7kgH8wiOtDbYkCnfa4H/GHj7OJO17l B1EGX3tuGESiMcakv4o2nV2jWBsTek8fm0dTQNU0RL4IYYz1VLKbGa2PoLbcXBjXSUb BhqOVf3hi/ySvz3kv1XinGFAMg9u2F3jhLxph3sDwBHtD0n+GQaCokWaya23rvx8qMzCHl CGkuzuKtLM85uQ52VGjPr3H03uVBLUwsJzvZ4JhVZhYttuVFAgMBAAECggEBAJAYqRr oQK+6koG0R0l56kdP4YErt0s+JaDKqaL9FETfioPJ3oIIhyLJCTeL8JZkYxilgBRcx/Y2KkIPe wg3YbBczHh6QBmglAkBlrsXUOebSEVO7elI8TsZAXrsZAajQ3uw3fWMHmZIdnMRZ2VG eGRVvjZNFYy9w21oZmsD0ufjfl3kEw3efEs4BIBi1miHaV8JQy68xshhPEjktgRTpWg5EvF Ou8nAMkXkPqVrOWl53LSMYjKFkgEbniiRAs5aVcv0BOF8vYeb72CYPiU0lKxxTcsCD0X8 3VRDchO1CBAGNyGNynodSJi4ZkHnQNThN9OthYcOhfJIlm+df3IpXiECgYEA3z9Q1TXB SlfPWFuXmXubyh8SyW404gNy1qVP+2O4zgcswFQn2RVKDJBGJ4cNz0urfuXX53oqxC3 1Kzshpt2SZj8r6GHTCleXsTHQSxoAkRTkTMfAqukJyVV8QdIpMTiZfMFQY9hRWqlOxPH RzsYKCkVfxnsODFI+nt+NuS1/FYcCgYEAz0OJ6l87/jmZdWhVesJlvGv6Kz7yXeQPOhHP 5Xit6ZYQtLOSw6FCJG9SBWnqC6evG7e01AsOr4cKvRDqWQtS0QnZ/OzQ7hBqH2zaL WLU6TbwwfRYV35GW3GOU0ei6gMS6Idzn9PTAyWQj8lCjtu47HEYYkYbq3gKCm6TBva wYdMCgYBLK3OZRu9di/GaC8Ug/fj39ryJrJ0L2SNq2OD0gaBxZwMPg4ajVsLHNjEZECV7 PjxxjwzCuWT7B4p80v1CxWqNGQo8xeucmN/P3zkGgKveLg2tOLlMEwmjjDA5rX0HQMq VsjXSWL0T7NxD/jSqDg7FZJSaLUcOqQbC0f1Tc9lNswKBgD2uq+zESuZt3e3DDy1pjT12 JQ2ZvieTJ7TweB6iu584ueANUTBHXZfaSV6zFqRBUyu8kGRKpiQ23EtILXYymIL9m5JaK BOxbuPLUWMQdqyxXRVb0q63NdkhAmpmd2WNZKMvLIn0UGgvVcZ07wn0+iPjxI36r2F oaBSSs87uu69hAoGAOECLSauNe5oOqUJhF2YXu5Hij7Ee2GuFaIQvsy23TOw0tCdzvJ8 /QJIFW82NK5B0lpmp8FfwCqNY3YrcOU4ZosQldSihODO/wYr99LW3Pm+ZbSAVQrAUJa fiQhMmIcG22rZQTuk4pnL6kN2wgjefNvKFa3aOM08yhboF53preNk= -----END PRIVATE KEY-----

56 3. Evaluation

Abb. 29: Privater Schlüssel des Testusers Matthias Klettner als QR-Matrix

(unverschlüsselter) öffentlicher RSA Schlüssel (2048 Bit): -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtL8YM9NzKaTWUIuWeAd3S NcA1Au47fTfQ8YyATV2RNmLSSAJJvUv6nEu7Cbsh7oKGTT/sg9E4o2ppgzDolRS0sw0U Me3CG5KcbNoDbWpXixfBJ8UdlUINky7dmfeYhu5IB/MIjrQ22JAp32uB/xh4+ziTte5QdRBl 97bhhEojHGpL+KNp1do1gbE3pPH5tHU0DVNES+CGGM9VSymxmtj6C23FwY10lGwYajl X94Yv8kr895L9V4pxhQDIPbthd44S8aYd7A8AR7Q9J/hkGgqJFmsmtt678fKjMwh5QhpLs 7irSzPObkOdlRoz69x9N7lQS1MLCc72eCYVWYWLbblRQIDAQAB -----END PUBLIC KEY-----

Abb. 30: Öffentlicher Schlüssel des Testusers Matthias Klettner als QR-Matrix 57 3. Evaluation

Ausschnitt der Mail des öffentlichen Schlüssels des Testusers Matthias Klettner:

Abb. 31: Mailausschnitt des öffentlichen Schlüsselversands - Matthias Klettner

Vergleicht man den zu Beginn erstellten RSA Schlüssel mit dem Ausgangswert so sind diese Ident. Man beachte, dass der öffentliche Schlüssel in eine QR-Matrix gewandelt, anschließend per Scan auf das Smartphone übertragen, mit einem erneuten Scan des zweiten Testgerätes erneut transferiert, danach signiert und per Mail an den Testrechner geschickt wurde. All diese Vorgänge können ohne jeglichen Informationsverlust realisiert werden. Dies ist ein essentieller Aspekt der gesamten Applikation. Bei dem Versand des Schlüssels wurde ebenfalls aufgezeigt, dass die Applikation eine Vielzahl von Applikationen für den Versand unterstützt. So können Schlüssel neben dem herkömmlichen Mail und SMS Dienst auch per Bluetooth, Facebook Messenger, Hangouts, LINE, Signal, Skype, Telegram, Viber sowie Signal übermittelt werden.

Verifizierung der Signatur: Bei der Detailansicht eines Schlüssels wird nicht nur überprüft ob der Schlüssel bereits signiert wurde, sondern ebenfalls wird die Signatur verifiziert und nur bei einer erfolgreichen Überprüfung wird die Signatur angezeigt. Die nachfolgenden Ausschnitte der Applikation zeigen die Implementierung dessen (Abbildung 35):

Abb. 32: Methodenaufruf

58 3. Evaluation

Dieser Code-Teil wird aufgerufen, wenn eine Signatur hinterlegt ist und ruft in weiterer Folge die hier angezeigte verifySig-Funktion auf (siehe Abbildung 36), welche mittels der angegebenen Attribute die Signatur überprüft.

Abb. 33: verifySig-Methode

Ist die Signatur erfolgreich überprüft worden, an der verify Boolean-Variable ersichtlich, da diese den Wert „true“ annimmt, dann wird das Linear-Layout, welche die Signatur Textfelder beinhaltet sichtbar.

Abb. 34: Logausgabe

Mittels Logausgaben werden unterschiedliche Informationen und Variablen ausgegeben (siehe Abbildung 37). Unter anderem auch die verified Variable. Ist diese „true“, wurde die Signatur erfolgreich geprüft.

Testproband Ronald Peer: (unverschlüsselter) privater RSA Schlüssel PEM Format (2048 Bit): -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEA2IdgkJ8665OX3O8j3lnJMlWlpMFhR9qOuVVQyZjDbFUObXk95NS5 sTXMN2WJILi78a78JjOUwy+Sz4P6C3ks0oVkmACUJvjFCUUMggjGKiUGDl/0cpN+dx62t FmQ9SfKKA43P7I067qMW75dNjCxyRLV4kSSWg3KRqkIasRoHOWK4XtSglx5ncntv3W3 T9OSFVr4mClKjmw1kvBUPMQ2tz2qEihpwytuSw0xjjXSxmVlVAEAOvEQo7W4y5T4xNbN Z5TyEZAoSL+o/mtLF9YpXb1UblQVIAKK67BRa+z6e6Hx9NlDv5sTAtxMb3sCrQxWStBwz tWen9jkIjPzEjJGiQIDAQABAoIBAGXjtk33j6tBBYoiQdekmmeEI/EWSmecceLGQcDLkNIO 59 3. Evaluation

aD6decGPVF4OOa2rqs5p/46nz+FODmeWoFfj+6qgd7YMrRxV0WFRWK6W/l7GMDGuw F3NS2MLAsyc+E5/gxXJhng40Ei52+s9GkUlnAke+tnqchkKOXAE4zVC30IWcAOAJpKfLjH /OLvMRHnyidX3wPuyaw0tXebhPzhZU+a9YyQwQKkvO1351AA+buGlMY62kz7U8YH0B YsrJebhdQxDs6CUgr0mC9jAuYaOk2gMJvXF3ErOIAUxUrgs0w9yhEhV5jm2iWY6X83DI3 dFU4PlN8Erhb06NTZFeliseJwD7d0CgYEA9ECI9QUBRyjVKqomgfHKcstlTXSvOyDxJ6b Evb9eXgXFfGGRH1VRscaW4wAEfZ1ow5/8fnQQ9XBRi9XEF7vzj2cv/7kXds72DJMEz9U XLKaYjNfQdANBkYte8lJ7/HmzOod2sJre25dra+a0sCEXbWmmBgvNkv5e1mvh2prnulMC gYEA4vF8n3DoyMH/00Ks2xibpY6EBwk1Wcu9Q4Su6Q+jJLGseAXxz3yogJcz3Ppjvng4c SVvXXwm8cJ7M9d2vtYPx2Z5BkmwWCo/zQVFJO5+JYhtFzUSTZmPJJRpWgRNQgUznr OIL70ljuNX9p7MqHQoz8HI8gPW0vikRsox+djiODMCgYAgTDBQBftnR3T4kUtKP4i/qTma BmXtcauxzJGTbayyzhyRF+2ysPt+gH4PQj9VxOzHgW5H4l0jt1hxHzEw2j+YpNJqBDWgFj ne68nlGY5Y7yaY6Si9TnjrH/zMGjAe8JDMmoENVU1GyD0CJZ2a9KU+aIv1nLXwTAaKX/ WbjIQ71QKBgElJiuFCaSpL2/2xTnkCnWD9gQ10n9H7xYcEVifVcO3sorGv2cMTkqbULV9 zTLq5wCBp4mjiKwFvuLGpJyPBpR7TrMmnCleubSQcS5P9oKcmQ3R3Iw4ERQGfG9aCB SEI5P6fI5+nCXX3XPS7m4Pa30MYZXgiXUGMIiDqMvFoZMWZAoGAI0GFOYpYL/h9c5d pomhYgcgRwlCEsGlSpuSe06zfvXYCJwT2W0FD45TybiLzvr/M+z08um7BY/0Tk9IcyDAD Gk71kJvVl4pH9WfYHoKP8K+OESMdRy6hlQWmhd48CfoMpOS/6PUgDFyPi4r3JhMUxJJ NXT0+YkFQBKnOkrIZhJM= -----END RSA PRIVATE KEY-----

(unverschlüsselter) privater RSA Schlüssel PKCS8 Format (2048 Bit): -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQDYh2CQnzrrk5fc7yP eWckyVaWkwWFH2o65VVDJmMNsVQ5teT3k1LmxNcw3ZYkguLvxrvwmM5TDL5LPg/oL eSzShWSYAJQm+MUJRQyCCMYqJQYOX/Ryk353Hra0WZD1J8ooDjc/sjTruoxbvl02MLH JEtXiRJJaDcpGqQhqxGgc5Yrhe1KCXHmdye2/dbdP05IVWviYKUqObDWS8FQ8xDa3Pa oSKGnDK25LDTGONdLGZWVUAQA68RCjtbjLlPjE1s1nlPIRkChIv6j+a0sX1ildvVRuVBUg AorrsFFr7Pp7ofH02UO/mxMC3ExvewKtDFZK0HDO1Z6f2OQiM/MSMkaJAgMBAAECgg EAZeO2TfePq0EFiiJB16SaZ4Qj8RZKZ5xx4sZBwMuQ0g5oPp15wY9UXg45rauqzmn/jqfP 4U4OZ5agV+P7qqB3tgytHFXRYVFYrpb+XsYwMa7AXc1LYwsCzJz4Tn+DFcmGeDjQSL nb6z0aRSWcCR762epyGQo5cATjNULfQhZwA4Amkp8uMf84u8xEefKJ1ffA+7JrDS1d5uE /OFlT5r1jJDBAqS87XfnUAD5u4aUxjraTPtTxgfQFiysl5uF1DEOzoJSCvSYL2MC5ho6TaA wm9cXcSs4gBTFSuCzTD3KESFXmObaJZjpfzcMjd0VTg+U3wSuFvTo1NkV6WKx4nAPt3 QKBgQD0QIj1BQFHKNUqqiaB8cpyy2VNdK87IPEnpsS9v15eBcV8YZEfVVGxxpbjAAR9n WjDn/x+dBD1cFGL1cQXu/OPZy//uRd2zvYMkwTP1RcsppiM19B0A0GRi17yUnv8ebM6h3 awmt7bl2tr5rSwIRdtaaYGC82S/l7Wa+Hamue6UwKBgQDi8XyfcOjIwf/TQqzbGJuljoQHCT VZy71DhK7pD6Mksax4BfHPfKiAlzPc+mO+eDhxJW9dfCbxwnsz13a+1g/HZnkGSbBYKj/ NBUUk7n4liG0XNRJNmY8klGlaBE1CBTOes4gvvSWO41f2nsyodCjPwcjyA9bS+KRGyjH 52OI4MwKBgCBMMFAF+2dHdPiRS0o/iL+pOZoGZe1xq7HMkZNtrLLOHJEX7bKw+36Afg 9CP1XE7MeBbkfiXSO3WHEfMTDaP5ik0moENaAWOd7ryeUZjljvJpjpKL1OeOsf/MwaMB 7wkMyagQ1VTUbIPQIlnZr0pT5oi/WctfBMBopf9ZuMhDvVAoGASUmK4UJpKkvb/bFOeQ KdYP2BDXSf0fvFhwRWJ9Vw7eyisa/ZwxOSptQtX3NMurnAIGniaOIrAW+4saknI8GlHtOsy acKV65tJBxLk/2gpyZDdHcjDgRFAZ8b1oIFIQjk/p8jn6cJdfdc9Lubg9rfQxhleCJdQYwiIOoy 8WhkxZkCgYAjQYU5ilgv+H1zl2miaFiByBHCUISwaVKm5J7TrN+9dgInBPZbQUPjlPJuIv 60 3. Evaluation

O+v8z7PTy6bsFj/ROT0hzIMAMaTvWQm9WXikf1Z9gego/wr44RIx1HLqGVBaaF3jwJ+gy k5L/o9SAMXI+LivcmExTEkk1dPT5iQVAEqc6SshmEkw== -----END PRIVATE KEY-----

Abb. 35: Privater Schlüssel des Testusers Ronald Peer als QR-Matrix

(unverschlüsselter) öffentlicher RSA Schlüssel (2048 Bit): -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2IdgkJ8665OX3O8j3lnJMlWlp MFhR9qOuVVQyZjDbFUObXk95NS5sTXMN2WJILi78a78JjOUwy+Sz4P6C3ks0oVkmAC UJvjFCUUMggjGKiUGDl/0cpN+dx62tFmQ9SfKKA43P7I067qMW75dNjCxyRLV4kSSWg3 KRqkIasRoHOWK4XtSglx5ncntv3W3T9OSFVr4mClKjmw1kvBUPMQ2tz2qEihpwytuSw0x jjXSxmVlVAEAOvEQo7W4y5T4xNbNZ5TyEZAoSL+o/mtLF9YpXb1UblQVIAKK67BRa+z6 e6Hx9NlDv5sTAtxMb3sCrQxWStBwztWen9jkIjPzEjJGiQIDAQAB -----END PUBLIC KEY-----

61 3. Evaluation

Abb. 36: Öffentlicher Schlüssel des Testusers Ronald Peer als QR-Matrix

Ausschnitt der Mail des öffentlichen Schlüssels des Testusers Ronald Peer:

Abb. 37: Mailausschnitt des Schlüsselversands - Ronald Peer

Auch beim zweiten Probanden konnte eine problemlose Übertragung des Schlüssels erfolgreich getestet werden. Abbildung 40 zeigt einen Ausschnitt der erfolgreich versendeten Mail, mit dem zuvor eingescannten öffentlichen Schlüssel als Inhalt. Der zuvor generierte öffentliche Schlüssel und der Ausgangswert sind auch hierbei ident.

62 3. Evaluation

Verifizierung der Signatur:

Abb. 38: Logausgabe Signaturverifizierung

Auch die Signatur dieses Testusers konnte erfolgreich überprüft werden (siehe Abbildung 41).

63 4. Diskussion und Fazit

4. Diskussion und Fazit Ziel dieser Arbeit war es die Themengebiete wie Public-Key-Verschlüsselungsverfahren im Allgemeinen und im Detail die Umsetzung von Pretty Good Privacy, sowie die dahinterliegende Struktur eines Web of Trusts aufzuarbeiten. Ebenso waren die Schwächen solcher Verfahren besonders in Hinsicht auf die Usability und die Erstellung einer Applikation die als Hilfestellung beim Schlüsselaustausch von Benutzern dienen soll, Teil dieser Thesis. Zusammenfassend lässt sich bestätigen, dass sowohl symmetrische als auch asymmetrische Verschlüsselungsverfahren bei der richtigen Umsetzung alle erwünschten Ziele erfolgreich realisieren. Bei der Wahl der richtigen Schlüssellänge, das behutsame Schützen des privaten Schlüssels, sowie das Einhalten der sicherheitskritischen Richtlinien, weisen diese Techniken keinerlei Schwächen auf. Stattdessen liegen die Defizite solcher sicherheitsrelevanten Verfahren und auch Softwarepakete wie PGP in anderen Bereichen, speziell in der Usability. Oft schwächeln diese Systeme bei dem Vorgang dem Benutzer das nötige Verständnis und die schwerwiegenden Folgen einer fehlerhaften Umsetzung zu übermitteln. Ebenso wichtig ist es den User für die Verwendung und das ordnungsgemäße Realisieren zu motivieren. Besonders die dezentrale Version einer hierarchischen Public-Key-Infrastruktur, das Web of Trust, ist anfällig für die Auswirkungen von Fehlverhalten. Da dieses System die Aufgaben und Verpflichtungen direkt an den Benutzer übergibt und es kaum möglich ist eine Fahrlässigkeit oder einen Missbrauch zu erkennen bzw. zu melden, sind viele User von Beginn an abgeneigt sich mit solch einer Verfahrensweise auseinanderzusetzen. So erklärte Filippo Valsorda ein Techniker des Cloudflare Cryptography Teams, welches an der Entwicklung und Verbesserung von TLS 1.3 arbeitet in seinem Blog [FV16] warum PGP für ihn keinerlei Zukunft hat. Filippo nahm an einer Vielzahl von Keysigning-Partys teil und hostete auch eine Vielzahl dieser. In einem seiner Blog-Eintrag gibt er eine Stellungnahme zum enormen Aufwand den er betreiben musste um die richtige Umsetzung PGPs zu realisieren. Er verwahrte seine Schlüssel mit äußerster Vorsicht, kreierte Sub-Keys für jeden möglichen Anwendungsfall und vergewisserte sich stets über die Authentizität von Schlüsseln. All das um, wie er beschreibt, zwei verschlüsselte Nachrichten im Jahr zu erhalten. Dazu kommt das wachsende Angriffsspektrum, welches mit einem jeden neuen Schlüssel eingeht und die stetige Angst, dass ein Schlüssel kompromittiert worden sein könnte. Auch der Aufwand um einen Schlüssel zu widerrufen, weil der Verdacht bestand ein Schlüssel könnte in die falschen Hände gelangt sein, erschien Filippo viel zu hoch. Herauslesen lässt sich in seinem Statement, das die richtige Umsetzung PGPs nicht möglich sei und er schließt mit dem Satz „But it just didn’t work“ ab. Die im Zuge dieser Arbeit programmierte Android-Applikation dient als Hilfestellung um den Schlüsselaustausch zwischen Benutzern zu erleichtern und erfüllte alle an sie gestellten Anforderungen. Dennoch gibt es ein Verbesserungspotenzial dieser. Zum einen könnte der Funktionsumfang der Applikation erweitert werden und so das Erstellen von Schlüsselpaaren und Subkeys unterstützt werden. Aber auch die Möglichkeit Schlüssel optional von Schlüsselservern beziehen zu können wäre ein weiterer Ausbau der

64 4. Diskussion und Fazit

Applikation und von dem ein oder anderen User erwünscht. Zum anderen können noch weitere Signaturalgorithmen hinzugefügt und dem Benutzer eine Auswahlmöglichkeit dieser angeboten werden. Da die Konvertierung der Schlüssel ebenfalls unabhängig von der Applikation erfolgen muss und die App das OpenPGP Format nicht unterstützt bzw. mit dem Format nicht umgehen kann, wäre das Unterstützen aller Schlüsselformate eine Steigerung. Bei der Erhebung der unterschiedlichen PGP-Implementierung fiel auf, dass vor allem bei Apple Geräten die Anzahl verfügbarer Applikationen sehr beschränkt ist und keine der Applikationen alle gewünschten Funktionen anbot. Neben der kostenpflichtigen App ipgmail gibt es kaum Alternativen, so wäre ein weiteres Potenzial der in dieser Arbeit entwickelten Software die Implementierung unter iOS. Alles in allem lässt sich festhalten, dass um das Sicherheitsbedürfnis der Allgemeinheit zu decken eine Vielzahl unterschiedlicher Kryptographiesysteme angeboten werden. Das von Phil Zimmermann entwickelte Verschlüsselungsprogramm PGP ist eines der Bekanntesten und dient als Vorreiter in diesem Gebiet. Zwar wurde es bereits Anfang der 90er Jahre veröffentlicht, doch auch noch heutzutage gilt es, bei der richtigen Handhabung, als sicher. Dieses, nun unter Symantec laufende Produkt, basiert auf dem Ansatz des Web-of-Trusts, einem Konzept einer dezentralisierten Public-Key-Infrastruktur, bei dem die Aufgaben der zentralen Zertifizierungsstelle direkt an die User übergeben wird. Doch genau dieser Ansatz, welcher das Web of Trust so interessant gestaltet, ist auch dessen größte Schwäche. So werden diese Aufgaben von den Endbenutzern meist als Zusatzsaufwand angesehen, was diese vor der Benutzung abgeschreckt. Dazu kommt die Tatsache, dass das Fehlverhalten eines einzigen Users ein potenzielles Risiko für alle anderen User des Web of Trusts darstellt. Kryptologieexperten wie Bruce Schneier [BS16] und Filippo Valsorda [FV16] haben in letzter Zeit ihre Erfahrungen und Meinungen zu PGP bekanntgegeben. Auch sie sind zu der Ansicht gekommen, dass PGP aufgrund der unvermeidbaren Schwächen, sowie dem Aufwand der Umsetzung einer verschlüsselten Kommunikation und der Schlüsselverwaltung bei der heutigen Technologie nicht mehr tragbar sind. Stattdessen setzen sie auf andere verschlüsselte Kommunikationswege wie Open Whisper Systems Instant Messenger Signal. Da das Sicherheitsverständnis der Gesellschaft stetig zu wachsen scheint und vor allem Enthüllungen, wie vom US-amerikanischen Whistleblower Edward Snowden fördern diese Entwicklung. Doch zeitgleich muss an der Usability von Kryptographiesysteme gearbeitet werden, um die Verwendung solcher Programme zu etablieren. PGP Umsetzungen wie die Browser-Erweiterung Mailvelope [MV16] oder die Open-Source-Software Pretty Easy Privacy [PEP17] versuchen bereits eine benutzerfreundliche Implementierung zu realisieren, dennoch liegt auch noch hier ein enormes Verbesserungspotential vor. Ebenso bleibt stets die Frage, wenn der Aufwand der Verbesserungen und der Optimierung von PGP basierten Krypto-Tools so hoch ist, um eine Massentauglichkeit aufweisen zu können, warum nicht komplett von neu beginnen anstatt auf einem rund 30 Jahre alten Programm aufzubauen.

65 Anhang

Anhang Grundlagen Kryptographie Die Kryptographie, in ihrer Urform, ist die Wissenschaft der Verschlüsselung von Informationen. Sei es die schon im dritten Jahrhundert v. Chr. eingesetzte Atbasch Verschlüsselungsmethode, die bekannte Cäsar-Chiffre oder auch die legendäre Schlüsselmaschine ENIGMA, welche im zweiten Weltkrieg eingesetzt wurde um den Nachrichtenverkehr zu chiffrieren - die Menschheit erkannte schon sehr früh den Reiz und den Nutzen Informationen vor unautorisiertem Zugang zu schützen. Die Verfahren der klassischen Kryptographie waren einerseits die Transposition, welche die Nachricht durch einfaches Umordnen der Buchstaben unleserlich machte (z.B. Skytale) oder die Substitution unter die auch die Cäsar-Chiffre fällt. Hierbei werden Buchstaben durch andere Buchstaben oder Symbole ersetzt. Die Schwierigkeit diese Verfahren zu brechen war von heutiger Sicht nicht hoch, dennoch erfüllten Sie zu ihrer Zeit alle Anforderungen.

Moderne Kryptographie An dem Grundprinzip der Kryptographie hat sich bis zur heutigen Zeit nicht viel geändert, denn auch noch heutzutage wird ein jedes Zeichen einer Nachricht, nach einem bestimmten Verfahren, mit einem oder mehreren anderen Zeichen ersetzt. Doch die grundlegende Komplexität solcher Verfahren hat sich deutlich erhöht. Und nicht nur die eingesetzten Verfahren haben sich entwickelt, vielmehr befasst sich die Kryptographie inzwischen mit der gesamten Informationssicherheit. Vor allem die vier Schutzziele Vertraulichkeit, Integrität, Authentizität und Verbindlichkeit spielen eine wesentliche Rolle. Während es in den Anfangszeiten reichte einen Buchstaben durch seinen dritten Nachfolger im Alphabet zu ersetzen, so geschehen beim Cäsar-Chiffre, bekam die moderne Kryptographie im 20ten Jahrhundert einen wichtigen Partner, die Mathematik. Die Methoden der modernen Kryptographie arbeiten nun auch nicht mehr mit einem Buchstaben als Ganzes, hingegen werden einzelne Bits der Daten gehandhabt und die Verfahren basieren auf Operationen in mathematischen Strukturen. Die Sicherheit beruht dabei auf der Schwierigkeit bestimmter Berechnungsprobleme.

Symmetrische Verschlüsselung Die Besonderheit bei der symmetrischen Verschlüsselung oder auch konventionellen Verschlüsselung ist, dass beide Kommunikationspartner denselben Schlüssel verwenden (siehe Abbildung 1). Dieser Schlüssel wird sowohl für das Verschlüsseln der Nachricht, als auch für die Entschlüsselung des Kryptotextes herangezogen. Die Problematik dieser Technik ist die Tatsache, dass beiden Partnern, vor der verschlüsselten Kommunikation, der identischen Schlüssel bekannt sein und sichergestellt werden muss, dass dieser über einen „sicheren Kanal“ ausgetauscht worden ist. Früher geschah dieser Vorgang per

66 Anhang

Boten, welcher den Schlüssel persönlich überbrachte. Heutzutage wird vor allem der Diffie-Hellman-Schlüsselaustausch verwendet, ein Protokoll, das es ermöglicht einen geheimen Schlüssel, über einen unsicheren Kanal, zu vereinbaren.

Abb. 39: Symmetrische Verschlüsselung

DES Der Data Encryption Standard, kurz DES, gilt als der Klassiker unter den symmetrischen Verschlüsselungsverfahren. Das NBS, National Bureau of Standards, heute bekannt als NIST (National Institute of Standards and Technology) sah in den 70er Jahren das Bedürfnis eines einheitlichen Standards für die Verschlüsselung vertraulicher Daten. IBM entwickelte zur damaligen Zeit den Chiffre „Lucifer“ und schlug ihn 1975 zur Standardisierung vor. Die National Security Agency (NSA) akzeptierte, in einem Ausschreiben, eine weiterentwickelte Version von Lucifer und modifizierte den Algorithmus noch zusätzlich, indem die interne Substitution verändert wurde und die Schlüssellänge auf 56 Bits verkürzt wurde. Anschließend veröffentlichten sie den Algorithmus unter der Bezeichnung DES. Allerdings ist genau diese verkürzte Schlüssellänge der Grund warum DES heutzutage als nicht mehr sicher betrachtet wird. Bei einer Schlüssellänge von 56 Bits ist mit heutiger Computerleistung ein vollständiges Durchsuchen des Schlüsselraums, die Menge aller möglichen Schlüssel, in kurzer Zeit möglich. Im Juli 1999 präsentierte die Electronic Frontier Foundation (EFF) eine DES-Entschlüsselungsmaschine, mit der es gelang einen DES-Schlüssel in weniger als 56 Stunden ausfindig zu machen [Fox00].

Triple DES Triple DES oder 3DES ist eine spezielle Variante von DES. Bei dem noch heute als sicher geltenden Algorithmus wird eine zu verschlüsselnde Nachricht dreimal, in der Regel mit drei unterschiedlichen Schlüsseln, per DES chiffriert. Eine 3DES-Verschlüsselung mit

67 Anhang

dem gleichen Schlüssel entspricht einer einfachen DES-Verschlüsselung. Die Schlüssellänge von 3DES ist zwar dreimal so groß wie bei DES – 168 Bit – lediglich liegt die effektive Schlüssellänge aufgrund eines kryptographischen Angriffs, dem Meet-in-the- middle-Angriff, bei nur 112 Bits. [KM14]

AES Im Jahre 1997 schrieb NIST einen Wettbewerb für einen neuen Verschlüsselungsstandard und Nachfolger für DES aus. Bis zur Abgabefrist im Sommer des darauffolgenden Jahres wurden insgesamt 15 Vorschläge eingesandt. Da die Sicherheit des Algorithmus nach dem Kerckhoffs‘ Prinzip von der Geheimhaltung des Schlüssels, nicht jedoch von der Geheimhaltung des Algorithmus abhängt, war der gesamte Wettbewerb öffentlich. Anschließend begann die erste Runde des Testens in der zahlreiche Kryptologieexperten die eingesandten Kandidaten überprüften. Die fünf besten Algorithmen der ersten Runde wurden nachfolgend noch einer zweiten Testphase unterzogen, bis letztendlich am 2. Oktober 2000 eine modifizierte Variante des Rijandel, künftig AES genannt, den Bewerb für sich entscheiden konnte. Dieser Algorithmus erfüllte alle gestellten Anforderungen. Es handelt sich um einen symmetrischen 128Bit- Blockalgorithmus, welcher mit Schlüssellängen von 128, 192 sowie 256 Bits operieren kann und sich als sicher erwies. Zusätzlich verfügte er über die beste Performance sowohl bei Software- als auch bei Hardwareimplementierungen und überzeugte durch seine Einfachheit. [Fis08]

IDEA Der International Data Encryption Standard, kurz IDEA, wurde zu Beginn der 90er Jahre von Xuejia Lai und James L. Massey am ETH-Zürich entwickelt und sollte ebenso wie AES als Nachfolger für DES dienen. Dieser Blockchiffre ist eine Überarbeitung des früheren Kryptosytems PES (Proposed Encryption Standard) und wurde aus diesem Grunde zunächst als IPES (Improved PES) bezeichnet. Da dieser Verschlüsselungsalgorithmus alle von Phil Zimmermann, der Erfinder von PGP, gewünschten Anforderungen erfüllte, als sehr sicher galt und für jedermann frei zugänglich ist, entschied er sich diesen in seinem Programm zu verwenden. Gegenwärtig wird IDEA immer noch als sicher angesehen, da er keinerlei algebraische Schwächen aufweist und es keinen bekannten kryptoanalytischen Angriff auf diesen Algorithmus gibt. Lediglich 2002 wurde bewiesen, dass IDEA beim Einsatz einer Klasse mit „schwachen“ Schlüssel als angreifbar gilt. [HS04]

Asymmetrische Verschlüsselung Im Gegensatz zu der bisher genannten symmetrischen Verschlüsselung werden bei asymmetrischen Verfahren zwei Schlüssel eingesetzt (siehe Abbildung 2). Ein sogenannter öffentlicher Schlüssel, welcher öffentlich zugänglich ist, mit diesem Schlüssel wird der Klartext verschlüsselt und ein privater Schlüssel, mit dem der verschlüsselte Kryptotext wieder entschlüsselt werden kann. Aufgrund des öffentlichen und privaten

68 Anhang

Schlüsselpaares wird diese Art auch Public-Key-Verschlüsselungsverfahren genannt. Die Geheimhaltung des privaten Schlüssels ist bei dieser Art der Verschlüsselung ein essentieller Faktor.

Abb. 40: Asymmetrische Verschlüsselung

RSA-Verschlüsselungsverfahren R. Rivest, A. Shamir und L. Adleman entwickelten 1978 den asymmetrischen RSA- Algorithmus, als sie versuchten zu beweisen, dass Public-Key-Kryptographie unmöglich sei. Das eng mit dem Rabin-Verschlüsselungsverfahren verwandte Kryptosystem basiert auf dem Faktorisierungsproblem großer Zahlen und kann sowohl für das Verschlüsseln, als auch für das Signieren von Nachrichten eingesetzt werden. Zwar gibt es zahlreiche Angriffe, weswegen RSA weit größere Schlüssellängen als alle bisher genannten Verfahren verwendet, gilt jedoch immer noch als ungebrochen. In der Regel ist die Länge des Schlüssels bei mindestens 2048 Bit anzusetzen um als sicher zu gelten. [BSW09]

Elgamal-Verschlüsselungsverfahren Durch eine einfache Modifikation des 1976 publizierten Diffie-Hellman- Schlüsselaustausch-Protokolls gelang es Taher ElGamal 1985 einen asymmetrischen Verschlüsselungsalgorithmus zu entwickeln. Anders als RSA basiert die Sicherheit dieses Verfahrens nicht auf der Schwierigkeit des Faktorisierungsproblems, sondern auf Operationen in einer zyklischen Gruppe endlicher Ordnung. [EG85]

Hash(funktion) Eine Hashfunktion, vom englischen Verb „to hash“, also „zerhacken“, ist eine Transformationsfunktion, welche einen Eingabe-String beliebiger Größe zu einem Ausgabe-String von endlicher und geringer Menge erzeugt. Da der Ausgabebereich von Hashfunktionen meist sehr klein ist, ist das Auftreten von Kollisionen, eine idente Ausgabe

69 Anhang

bei zwei unterschiedlichen Eingaben, möglich. Wogegen diese Funktionen nicht bijektiv sind, sodass es nicht möglich ist, vom Ausgabebild auf das Urbild zu schließen. Eine bedeutende Charakteristik einer Hashfunktion ist, dass bei gleicher Eingabe stets die idente Ausgabe erzeugt wird. So kann ein Hashwert wie ein menschlicher Fingerabdruck dienen. Wird der Hash(wert) einer Nachricht erzeugt, dieser an die Nachricht angehängt und anschließend Beides verschlüsselt, so kann der Empfänger durch das Entschlüsseln der Nachricht und das Vergleichen des von ihm berechneten Hashwertes mit dem vom Sender angehängten Wert, die Integrität einer Nachricht sicherstellen. [KKPD15]

MD5 Die wohl bekannteste kryptographische Hashfunktion, welche auch in PGP ihren Einsatz findet, ist der 1991 von Ronald Rivest entwickelte Message-Digest Algorithm 5 – kurz MD5. Dieser erzeugt, wie jede Hashfunktion, aus einem Input beliebiger Länge eine Zeichenkette fixer Länge, welche als Hashwert bezeichnet wird. Der Hashwert hat in diesem Verfahren eine Länge von 128 Bits, welcher in Form einer 32-stelligen Hexadezimalzahl notiert wird. Heutzutage gilt MD5 jedoch nicht mehr als sicher, da es mit ausreichend Aufwand möglich ist unterschiedliche Inputs mit gleichem MD5-Hashwert zu erstellen. Diese Art von Angriff nennt man Kollisionsangriff.

SHA-1 Der Secure Hash Algorithm, kurz SHA, ist die Weiterentwicklung von MD4, dem Vorgänger von MD5 und wurde ebenfalls wie MD5 zu Beginn der 90er Jahre entwickelt. Diese weit verbreitete Hash-Funktion gilt zwar seit 2004 ebenfalls als nicht mehr sicher, da sie anfällig für Kollisionsangriffe ist, dennoch findet sie noch ihren Einsatz und auch in neueren Versionen von PGP wird sie angeboten. SHA-1 erzeugt einen Hashwert mit einer Länge von 160 Bit. [EK16]

SHA-2 Das National Institute of Standards and Technology, kurz NIST, standardisierte im Jahr 2000 vier neue SHA-Versionen: SHA-224, SHA-256, SHA-384 und SHA-512. Die jeweilige Zahl im Namen lässt auf die Länge des Hash-Wertes schließen. SHA-2 dient als Überbegriff dieser vier Nachfolger, welche zukünftig SHA-1 ablösen sollen. [EK16]

SHA-3 Anfang November 2007 wurde von der NIST ein weiterer Wettbewerb für einen neuen kryptographischen Hash Algorithmus, mit dem Namen SHA-3, verkündet. Insgesamt bis Ende Oktober des darauffolgenden Jahres 64 Kandidaten eingereicht. Bis zur letzten und finalen Runde des Wettbewerbs im Dezember 2010 wurde die Zahl der Finalisten auf fünf reduziert und am 2. Oktober 2012 Keccak zum Gewinner und somit zu SHA-3 gekürt. Ebenso wie SHA-2 sind die Längen des Hashwertes von SHA3 variabel (SHA3-224, SHA3-256, SHA3-384, SHA3-512). [NIST17]

70 Anhang

Digitale Signatur Bei der digitalen Signatur handelt es sich um ein asymmetrisches Kryptoverfahren. Im Unterschied zu der asymmetrischen Verschlüsselung einer Nachricht wird beim digitalen Signaturverfahren nur ein, aus den zu signierenden Daten (z.B. einer Nachricht), berechneter Wert – deren Hashwert – als Basis genommen. Dieser Hashwert durchläuft gemeinsam mit dem privaten Schlüssel des Senders ein Signaturverfahren und erzeugt einen neuen Wert, digitale Signatur genannt (siehe 4). Die digitale Signatur ermöglicht die nichtabstreitbare Urheberschaft und Integrität der Daten zu prüfen, da in der Regel nur der Sender über seinen privaten Schlüssel verfügt. Bei deterministischen digitalen Signaturverfahren ist die Signatur bei gleicher Nachricht und gleichem Schlüssel immer ident, bei probabilistischen digitalen Signaturverfahren fließen Zufallswerte in die Berechnung ein und die Signatur variiert. Bei dem Verfahren der digitalen Signatur mittels RSA, entspricht dies der Verschlüsselung des Hashwertes, da dies jedoch nicht bei allen Signaturverfahren der Fall ist, weicht man davon ab den Vorgang als „Verschlüsselung“ zu deklarieren.

Abb. 41: Digitale Signatur

(Digitale) Zertifikate Digitale Zertifikate entsprechen einem Personalausweis in digitaler Form. Diese Zertifikate werden verwendet um die Authentizität und Integrität von Personen sowie Objekten wie Webseiten zu garantieren. In der Regel werden digitale Zertifikate von zentralen vertrauenswürdigen Stellen, meist Zertifizierungsstellen, ausgestellt und können anhand kryptografischer Verfahren verifiziert werden.

Public-Key-Zertifikate Eine spezielle Form von digitalen Zertifikaten sind Public-Key-Zertifikate, welche in der Praxis oft mit dem Ausdruck „digitale Zertifikate“ gleichgesetzt werden. Public-Key- Zertifikate bestätigen die Zugehörigkeit eines kryptografischen Schlüssels, dem öffentlichen Schlüssel, zu einer Person oder einem Objekt. Somit können Authentizität, Vertraulichkeit und Integrität von Daten und Personen garantiert werden. Ein Zertifikat 71 Anhang

enthält unter anderem Informationen über den Namen des Inhabers, dessen öffentlichen Schlüssels, eine Gültigkeitsdauer, eine Seriennummer, den Namen der Zertifizierungsstelle, mit dessen privaten Schlüssel dieses signiert und von der das Zertifikat ausgestellt worden ist. Mittels des öffentlichen Schlüssels der Zertifizierungsstelle kann die Integrität und Echtheit eines Zertifikates überprüft werden. Der am weitesten verbreitete Standard von digitalen Zertifikaten ist der Standard X.509, welcher aktuell die Version 3 trägt (X.509v3). [PW16]

72 Anhang

PGP Zertifikate Anders als x509 Zertifikate bestehen PGP Zertifikate aus mehreren einzelnen Abschnitten, die zusammen das (Schlüssel)-Zertifikat bilden. Zu Beginn ist stets der öffentliche Hauptschlüssel an sich, gemeinsam mit einem Erzeugungs-, einem Ablaufdatum, als auch einem Fingerabdruck. Der nächste Teil des Zertifikats besteht aus einer oder mehreren User-IDs. Zumeist bildet der Name des Besitzers und die jeweilige E-Mail-Adresse oder auch einem Kommentar die User-ID. Ein jeder PGP-Schlüssel kann über eine Vielzahl von User-IDs verfügen. Den dritten Abschnitt des Zertifikats bilden eventuelle Unterschlüssel gefolgt vom letzten Part, Signaturen des Schlüsselbesitzers oder Dritte, welche die Authentizität des Schlüssels bestätigen. Im Kapitel 1.2 Schlüssel ist der Aufbau dieser genauer dargestellt und beschrieben.

73 Anhang

Public-Key Crpytography Standards (PKCS) #8

Private-Key Information Syntax: PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL }

Version ::= INTEGER PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute

Die Informationsfelder eines privaten Schlüssels weisen die folgenden Werte auf: Die Versionsnummer wird als Zahl im Datenfeld Version notiert. Der verwendete Algorithmus des privaten Schlüssels wird im Tuppel ‚privateKeyAlgorithm‘ angegeben. Der private Schlüssel an sich befindet sich als String, bestehend aus mehreren Oktetten folgend an den Algorithmus im Feld ‚privateKey‘. Das letzte Datenfeld ‚attributes‘ ist optional und kann ein Set von Attributen, zumeist erweiterte Informationen, beinhalten.

Encrypted Private-Key Information Syntax: EncryptedPrivateKeyInfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmIdentifier, encryptedData EncryptionData }

EncryptedAlgorithmIdentifier ::= AlgorithmIdentifier EncryptedData ::= OCTET STRING

Bei der verschlüsselten privaten Schlüssel-Information weist das ‚encryptionAlgorithm‘- Feld den jeweiligen Algorithmus auf, mit welchem das gesamte Paket verschlüsselt wurde. Das gesamte verschlüsselte Datenpaket der Private-Key Information befindet sich im angehängten Feld ‚encryptedData‘

74 Anhang

Abbildungsverzeichnis Anmerkung: Abbildungen ohne Quellenangabe wurden selbst erstellt. Abb. 1: Hybride Verschlüsselung ...... 3 Abb. 2: x.509 vs PGP Certificate Structure – Quelle: [VJ14] ...... 6 Abb. 3: Aufbau Unterschlüssel ...... 8 Abb. 4: Schlüsselentwicklung der letzten 6 Jahre – Quelle: [KF16] ...... 10 Abb. 5: Entwicklung der hinzugefügten Schlüssel pro Tag – Quelle [KF16] ...... 11 Abb. 6: Key Legitimacy - complete trust chain...... 14 Abb. 7: Key Legitimacy - marginal trust chain ...... 14 Abb. 8: Pretty Easy Privacy – Farbkodierung der „Privacy Level“ – Quelle: [PEP17] ...... 16 Abb. 9: Mailvelope Schlüsselverwaltung – Quelle: [MV16] ...... 18 Abb. 10: Enigmail Screenshot – Quelle: [EM17] ...... 19 Abb. 11: Google App Store Zugriffe, 7-Tage-Zeitspanne (Stand 07.12.2016) ...... 36 Abb. 12: Main Activity Layout ...... 38 Abb. 13: Private Key Layout ...... 39 Abb. 14: Scan-View ...... 39 Abb. 15: Toast-Meldung nach dem erfolgreichen Scannen ...... 39 Abb. 16: Public Key Layout ...... 40 Abb. 17: Show Own Public Key View ...... 40 Abb. 18: Toast-Meldung nach dem erfolgreichen Speichern ...... 40 Abb. 19: Add Public Key Layout ...... 41 Abb. 20: Add Public Key Layout nach dem Scan ...... 41 Abb. 21: ListView Layout ...... 42 Abb. 22: DetailKey Layout ...... 44 Abb. 23: DetailKey Layout mit Signatur ...... 44 Abb. 24: Send Public Key Auswahl Applikation ...... 45 Abb. 25: Schlüsselversand per Mail Applikation ...... 45 Abb. 26: Standardszenario ...... 46 Abb. 27: Schlüsselkonvertierung eines Probanden ...... 53 Abb. 28: Erstellung der QR-Matrizen im QR-Studio ...... 54 Abb. 29: Privater Schlüssel des Testusers Matthias Klettner als QR-Matrix ...... 57 Abb. 30: Öffentlicher Schlüssel des Testusers Matthias Klettner als QR-Matrix .. 57 Abb. 31: Mailausschnitt des öffentlichen Schlüsselversands - Matthias Klettner .. 58 Abb. 32: Methodenaufruf ...... 58 Abb. 33: verifySig-Methode ...... 59 Abb. 34: Logausgabe ...... 59

75 Anhang

Abb. 35: Privater Schlüssel des Testusers Ronald Peer als QR-Matrix ...... 61 Abb. 36: Öffentlicher Schlüssel des Testusers Ronald Peer als QR-Matrix ...... 62 Abb. 37: Mailausschnitt des Schlüsselversands - Ronald Peer ...... 62 Abb. 38: Logausgabe Signaturverifizierung ...... 63 Abb. 39: Symmetrische Verschlüsselung ...... 67 Abb. 40: Asymmetrische Verschlüsselung ...... 69 Abb. 41: Digitale Signatur ...... 71

76 Anhang

Literaturverzeichnis Bücher und Publikationen [BKW13] Buchmann J., Karatsiolis E., Wiesmaier A.: Introduction to Public Key Infrastructures, Springer Science+Business Media, 2013 [BSW09] Beutelspacher, A., Schwenk J., Wolfenstetter KD.: Moderne Verfahren der Kryptographie. Von RSA zu Zero-Knowledge, 7. überarbeitete Auflage, Vieweg+Teubner GWV Fachverlage GmbH, Wiesbaden 2009 [CBZ99] Creutzig C., Buhl A., Zimmermann Ph.: PGP Pretty Good Privacy: der Breifumschlag für Ihre elektronische Post, 1999 [GM15] Green M. D., Miers I.: Forward Secure Asynchronous Messaging from Puncturable Encryption, The Johns Hopkings University, USA, Baltimore, 2015 [EG85] ElGamal, T.: A public-key cryptosystem and a signature scheme based on discrete logarithms, IEEE, Transactions on Information Theory, VOl. IT-31, Springer Verlag, 1985. [Enk13] Enkert A.: Funktionsweise und Sicherheit der Verschlüsselung mit Pretty-good- Privacy (PGP) Analyse eines gängigen Public-Key-Verschlüsselungsverfahren, Band 1645, Grin Verlag, 2013 [Fis08] Fischer, M.: Advanced Encryption Standard, HBS Kryptologie, Kapitel 8, 174-175, 2008. [Fox00] Fox, D.: Data Encryption Standard (DES) DuD Datenschutz und Datensicherheit 24 2000, 736 [Gar95] Garfinkel, S.: PGP Pretty Good Privacy. Encryption for Everyone, 1. überarbeitete Auflage, O’Reilly & Associates, Inc, 1995 [HS04] How-Shen, Ch.: International Data Encryption Algorithm, CS-627-1, 2004 [KH05] Krawczyk, H.: Encyclopedia of Cryptography and Security, 2005 [KKPD15] Klenk A., Keller HB., Plöderer E., Dencker P.: Automotive – Safety & Security 2015 – Sicherheit und Zuverlässigkeit für automobile Informationstechnik, Bonn, Köllen Druck + Verlag GmbH, volume P-240 of Lecture Notes in Informatics, April 2015 [KLS03] Krüger O., Lübke D., Schimanski S.: E-Mail-Verschlüsselung 2003, 2003 [KM14] Karthik S., Muruganandam A., D.: Data Encryption and Decryption by Using Triple DES and Performance Analysis of Crypto System IJSER, Volume 2 Issue 11, November 2014 [Lin02] Lindhorst, A.: Sichere E-Mails mit PGP, 1. Auflage, verlag moderne industrie Buch AG & Co. KG, 2002 [Luc06] Lucas M.: PGP & GPG – E-Mail for the practical paranoid, No Starch Press, Inc., 2006 [Myr91] Myers, G. J.: Methodisches Testen von Programmen, 4. Auflage Oldenbourg Verlag, München/Wien, 1991

77 Anhang

[RAZS15] Ruoti S., Andersen J., Zappala D., Seamons K.: Why Johnny Still, Still Can’t Encrypt: Evaluating the Usability of a Modern PGP Client, Brigham Young University, 2015 [Rya03] Ryan T.: Attacks on PGP: A Users Perspective, SANS Institute, 2003 [VJ14] Vacca, R. J.: Cyber Security and IT Infrastructure Protection, Waltham, USA, 2014 [Vdm14] Van der Meer, M.: Pratical Security and Key Management, University of Amsterdam, Juli 2014 [WT99] Whitten A., Tygar J. D.: Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0, 1999 Links [APG17] APG: Android Privacy Guard Online im Internet: http://www.thialfihar.org/ (aufgerufen am 25.07.2017 um 15:10) [BBL17] Brown I., Back A., Laurie B.: Forward Secrecy Extensions for OpenPGP. Online im Internet: https://tools.ietf.org/html/draft-brown-pgp-pfs-03 (aufgerufen am 14.03.2017 um 17:47) [BC17] Bouncy Castle: Online im Internet: https://www.bouncycastle.org/ (aufgerufen am 25.07.2017 um 12:10) [BS16] Bruce Schneier: The Pro-PGP Position. Online im Internet: https://www.schneier.com/blog/archives/2016/12/the_pro-pgp_pos.html (aufgerufen am 24.10.2016 um 08:02) [BSI17] Bundesamt für Sicherheit in der Informationstechnik: Nutzung von OpenPGP auf Android, Online im Internet: https://www.bsi.bund.de/DE/Publikationen/Studien/OpenPGP/openpgpandroid.html (aufgerufen am 14.06.2017 um 08:11) [RS17] Roberto Sanchez: Connexer: Improve the Security of Your OpenPGP Key by Using Subkeys. Online im Internet: http://www.connexer.com/articles/openpgp-subkeys (aufgerufen am 28.04.2017 um 08:52) [DD96] Don Davis: Compliance Defects in Public-Key. Online im Internet: https://www.usenix.org/legacy/publications/library/proceedings/sec96/full_papers/d avis/davis.txt (Stand 28.05.1996 aufgerufen am 11.11.2016 um 19:55) [EK16] Elektronik Kompendium: SHA – Secure Hash Algorithm. Online im Internet: http://www.elektronik-kompendium.de/sites/net/1910161.htm (aufgerufen am 14.10.2016 um 16:32) [EM17] Enigmail: A simple interface for OpenPGP email security. Online im Internet: https://www.enigmail.net/index.php/en/ (aufgerufen am 22.04.2017 um 07:56) [EP16] Etienne Perot: Parcinomie.sh Script. Online im Internet: https://github.com/EtiennePerot/parcimonie.sh (aufgerufen am 05.01.2017 um 16:10)

78 Anhang

[FV16] Filippo Valsorda: Op-ed: I’m throwing in the towel on PGP, and I work in security. Online im Internet: http://arstechnica.com/security/2016/12/op-ed-im-giving-up-on- pgp/ (aufgerufen am 14.12.2016 um 19:02) [GPG17] GnuPG: The Gnu Privacy Guard. Online im Internet: https://www.gnupg.org/ (aufgerufen am 25.04.2017 um 12:10) [GPW17] GPG4Win: GNU Privacy Guard for Windows. Online im Internet: https://www.gpg4win.de/about-de.html (aufgerufen am 25.07.2017 um 10:09) [GPT17] GPGTools. Online im Internet: https://gpgtools.org/ (aufgerufen am 25.07.2017 um 11:01) [GP17] GnuPG::OpenPGP Encryption, Online im Internet: https://guardianproject.info/code/gnupg/ (aufgerufen am 25.06.2017 um 07:19) [KF16] Kristian Fiskerstrand: sks-keyservers.net – key development Online im Internet: https://sks-keyservers.net/status/key_development.php (aufgerufen am 05.01.2017 um 11:10) [KS16] Klafter R., Swanson E.: evil32 Online im Internet: https://evil32.com/ (aufgerufen am 05.01.2017 um 16:24) [LS16] Linda Sui: Strategy Analytics: Android Captures Record 88 Percent Share of Global Smartphone Shipments in Q3 2016. Online im Internet: https://www.strategyanalytics.com/strategy-analytics/news/strategy-analytics- press-releases/strategy-analytics-press-release/2016/11/02/strategy-analytics- android-captures-record-88-percent-share-of-global-smartphone-shipments-in-q3- 2016#.WGUX69g19QB (aufgerufen am 02.11.2016 um 07:12) [MGP17] MacGPG: Mac GNU Privacy Guard. Online im Internet: http://macgpg.sourceforge.net/ (aufgerufen am 22.07.2017 um 11:10) [MV16] Mailvelope: Verschlüsselung mit OpenPGP für Webmail. Online im Internet: https://www.mailvelope.com/de (aufgerufen am 30.12.2016 um 13:10) [NIST17] NIST National Institute of Standards and Technology: Cryptographic Hash – The SHA-3 Project. Online im Internet: http://csrc.nist.gov/groups/ST/hash/index.html (aufgerufen am 10.05.2017 um 14:10) [NP17] Netzpolitik.org: pretty Easy Privacy – Whatsapp verschlüsseln. Und Facebook- Nachrichten. Auch mit Outlook. Online im Internet https://netzpolitik.org/2014/pretty-easy-privacy-whatsapp-verschluesseln-und- facebook-nachrichten-auch-mit-outlook/ (aufgerufen am 01.05.2017 um 17:25) [OPGP17] OpenPGP.js: OpenPGP JavaScript Implementation. Online im Internet: http://openpgp.org/ (aufgerufen am 22.04.2017 um 22:10) [OJS17] OpenPGP: Email encryption. Online im Internet: https://openpgpjs.org/ (aufgerufen am 22.07.2017 um 06:10) [PEP17] Pretty Easy Privacy: Privacy per Default. Online im Internet: https://prettyeasyprivacy.com/ (aufgerufen am 30.04.2017 um 13:56)

79 Anhang

[PW16] PentaWare: What is a Digital Certificate? Online im Internet: http://pentaware.com/PW/What_is_a_digital_Certificate.htm (aufgerufen am 14.10.2016 um 11:33) [NWG07] Network Working Group: OpenPGP Message Format Online im Internet: https://tools.ietf.org/html/rfc4880 (aufgerufen am 05.06.2017 um 11:51) [SB16] Schürmann D., Breitmoser V.: German Study Published:“Usage of OpenPGPon Android, Online im Internet: https://www.openkeychain.org/bsi-study (aufgerufen am 05.07.2017 um 14:14) [SC16] Symantec Corporation: Global Directory FAQ. Online im Internet: https://keyserver.pgp.com/vkd/VKDHelpPGPCom_de.html (aufgerufen am 05.10.2017 um 14:51) [SeS16] SearchSecurity: How can PGP short key IDs be protected from collision attacks? Online im Internet http://searchsecurity.techtarget.com/answer/How-can-PGP- short-key-IDs-be-protected-from-collision-attacks (aufgerufen am 03.01.2017 um 21:51)

80 Anhang

Persönliche Daten

Name: Daniel Buchberger Geburtsdatum: 21.03.1991 Geburtsort: Wien Nationalität: Österreich

Schulbildung

Schule: Volksschule Mannersdorf am Leithagebirge Bundesgymnasium Eisenstadt Hochschulzugang: PANNONEUM, Höhere Lehranstalt für wirtschaftliche Berufe, Neusiedl am See, Ausbildungsschwerpunkt Medieninformatik Abschlussdatum: 08.06.2010, Reife- und Diplomprüfung an der HLW PANNONEUM

Studium

Dauer: 09/2011 – 07/2014 Hochschule: FH-Burgenland, Bachelorstudiengang IT Infrastruktur- Management Abschluss: 24.06.2014, Bachelor of Science in Engineering (BSc.) Titel der ersten Vergleich von Open-Source Bachelorarbeit: Versionsverwaltungssysteme für Klein- und Mittelunternehmen Betreuer der ersten Bachelorarbeit: Mag. David Rückel Titel der Sicherheitsstandards von drahtlosen Netzwerken bei zweiten Bachelorarbeit: Klein- und Mittelunternehmen Betreuer der zweiten Bachelorarbeit: DI. Dr. Christian Büll

Berufspraxis

Sonstiges

81