Diplomarbeit. Entwurf und Implementierung eines -Werkzeuges zur vertrauenswürdigen Kommunikation nach dem Stereotypen-Ansatz

Transkript

1 Diplomarbeit Entwurf und Implementierung eines -Werkzeuges zur vertrauenswürdigen Kommunikation nach dem Stereotypen-Ansatz vorgelegt bei: Prof. Dr. Günter Müller Albert-Ludwigs-Universität Freiburg Institut für Informatik und Gesellschaft eingereicht von: Heiko Abraham Matr.-Nr: Juli 2003

2 Diplomarbeit von: Heiko Abraham Dunantstraße 3 D Freiburg i.br. abrahamh@abe-si.de Betreuer: Prof. Dr. Günter Müller Dipl.-Inf. Johannes Kaiser

3 Zusammenfassung Heute ist die Kommunikation per Internet und nahezu selbstverständlich. Mit zunehmender Online-Kommunikation und e-government steigt die Notwendigkeit zur vertrauenswürdigen Kommunikation. Um vertrauenswürdig Nachrichten austauschen zu können bedarf es hierbei der Verwendung von Kryptographie, insbesondere der Verschlüsselung und der digitalen Unterschrift. Werkzeuge, die Verschlüsselung und digitale Unterschrift anwendbar machen, gehören zur Gruppe der Sicherheitsanwendungen. Solche Sicherheitsanwendungen können aber nur dann fehlhandlungssicher, sinnvoll und effizient genutzt werden, wenn die individuellen Fähigkeiten und Bedürfnisse der Benutzer bei der Softwareentwicklung berücksichtigt wurden. Kern der Arbeit ist die Steigerung der Benutzbarkeit eines solchen Werkzeugs zum digitalen Unterschreiben und Verschlüsseln von s. Hierzu wurde eine Benutzerbefragung durchgeführt. Das Ergebnis dieser Befragung floss in den Entwurf eines Werkzeuges für s ein, welches verschiedene Nutzergruppen (als Stereotypen bezeichnet) genügt. Hierdurch wird die Sicherheit des Gesamtsystems erhöht, indem das schwächste Glied der Sicherheitskette, der Benutzer, konkret einbezogen wird. Durch einfache Anwendbarkeit wird zugleich die Akzeptanz für dieses Sicherheitswerkzeug gesteigert. Schlüsselworte: - Verschlüsselung, -Programm - Digitale Unterschrift, Signierwerkzeug, - OpenPGP, OpenPGP/MIME, Schlüsselmanagment - Gestaltungskriterien, modellbasierter Software-Entwurf, Benutzermodell

4

5 Inhaltsverzeichnis 1 Einleitung Sicherheit Dienst Sicherheitsanforderungen Schutzziele Sicherheitsmechanismen Resultat Praktische Implementierungen Privacy Enhanced Mail (PEM) Pretty Good Privacy (PGP) OpenPGP/GnuPG Secure Multipurpose Internet Mail Extension (S/MIME) Wahl des Verfahrens OpenPGP -Einbindung OpenPGP Unterstützung vorhandener -Programme Benutzermodell Motivation Grundlagen Anforderungen und Ziele der Benutzermodellierung Arten der Benutzermodellierung Stereotypen-Ansatz Identifikation durch Umfrage Auswertung der Umfrage Allgemeine Ergebnisse Identifizierende Merkmale Stereotypen-Hierarchie

6 INHALTSVERZEICHNIS 6 4 Implementierung Funktionen Techniken zur Implementierung Die Schlüsselverwaltung Mobile OpenPGP - Schlüssel Die Integration Gesamtsystem Resümee und Ausblick 55 A Kryptologie 57 A.1 Kryptographische Verfahren A.1.1 Symmetrische Verschlüsselung A.1.2 Asymmetrische Verschlüsselung A.1.3 Einwegfunktionen A.1.4 Digitale Umschläge A.1.5 Digitale Unterschrift A.2 Kryptoanalyse A.3 Leistungsfähigkeit B Der Umfrage-Bogen 67 C Ergebnisse der Benutzerumfrage 71 C.1 Methode C.2 Kenntnisstand C.3 Präferenzen C.4 Schlüsselmanagment

7 Abbildungsverzeichnis Transportvorgang , vom Absender-MUA generiert , nach erfolgter Zustellung inklusive Datei-Anhang, vom Absender-MUA generiert Zertifikatkette mit dig. Klartext-Unterschrift nach RFC mit dig. Unterschrift nach RFC im HTML-Format, entsprechend RFC Ergebnis der Signaturprüfung im Microsoft Outlook 5.5/PGP Morphologie zur Benutzermodellierung (nach Mertens und Höhl, 1999) Kenntnisfragen, Durchschnitt aller Befragten Clusterbildung nach Benutzerwissen Benutzer-Präferenzen Benutzer-Präferenzen Schlüsselverwaltung Stereotypenhierarchie Anwendungsfalldiagramm Schlüsselverwaltung Anwendugsfalldiagramm lesen bzw. senden Druid Schlüsselerzeugung Stereotypen-Attribute zur Schlüsselerzeugung Hauptfenster (Anfänger) Hauptfenster (Experte, Zertifkatliste) Zertifikat-Liste (Anfänger) Schlüssel-Export im Vergleich Mobile Schlüssel mit Smart GnuPG Funktionen zum Lesen einer (OpenPGP-)

8 ABBILDUNGSVERZEICHNIS Ergebnis der Signaturprüfung (fehlerhaft) im Balsa Ergebnis der Signaturprüfung (gültig) im Experten-Modus Composer, digitale Unterschrift erstellen Composer, manuelle Schlüsselauswahl (Anfänger) digital Unterschreiben (Szenario 1) digital Unterschreiben (Szenario 2) A.1 Digitale Unterschrift erstellen und prüfen B.1 Umfrage-Bogen, Seite B.2 Umfrage-Bogen, Seite B.3 Umfrage-Bogen, Seite C.1 Umfrage Kenntnisteil: Gesamtergebnis C.2 Umfrage Kenntnisteil: Gruppe 1 (Anfänger) C.3 Umfrage Kenntnisteil: Gruppe 2 (Fortgeschrittener) C.4 Umfrage Kenntnisteil: Gruppe 3 (Experte) C.5 Umfrage: Präferenzen C.6 Umfrage: Präferenzen Schlüsselverwaltung

9 Tabellenverzeichnis 2.1 Vergleich der praktischer Implementierungen OpenPGP Unterstützung verschiedener MUA A.1 Vergleich der äquivalenten Schlüssellängen

10 Kapitel 1 Einleitung Im gleichen Maße, wie die Nutzung des Internets als Kommunikationssysteme wächst, so wächst auch der Bedarf an vertraulicher Kommunikation. Ein Problem des Internet ist die mangelnde Sicherheit dieses Mediums, die sowohl die geschäftliche, wie auch die private Nutzung betrifft. So kann sich ohne entsprechende Vorkehrungen niemand sicher sein, dass seine übertragenen Daten nicht mit-gelesen oder gar verändert beim Empfänger ankommen. Hohes Interesse an derartigen Mißbrauchsmöglichkeiten haben nicht nur Wirtschaftsspione und Geheimagenten, sondern auch die Werbeindustrie. Unter vertrauenswürdiger Kommunikation versteht man, dass insbesondere nur ausgewählte Teilnehmer eine Nachricht lesen können. Weiter sollte die Nachricht nicht unbemerkt veränderbar sein und der Urheber einer Nachricht sollte eindeutig bestimmbar bleiben. Der Dienst stellt im Internet eine der wichtigsten Nutzungsformen für zielgerichtete Kommunikation dar. kann man mit einer Art elektronischer Postkarte vergleichen. Sie wird zwar schnell befördert, kann aber auch leichter von Unbefugten gelesen und sogar automatisch ausgewertet werden. Dies widerspricht den zu schützenden Zielen des Anwenders die aufgrund der Art der Kommunikation zudem bilateralen Charakter annehmen. Um diese bilateralen Schutzziele zu erreichen Bedarf es der Verwendung von Sicherheitswerkzeugen. Diese Werkzeuge sollen helfen die Schutzziele der Anwender sicherzustellen. Hierzu bedienen sich die Sicherheitswerkzeuge der Kryptographie. Derzeitiger Stand der Technik ist aber, dass vom Anwender weitreichendes Verständnis für die zugrunde liegenden Sicherheitskonzepte verlangt wird. Dies sind beispielsweise kryptographische Konzepte, Prinzipien und Protokolle. Gleichzeitig geben Sicherheitswerkzeuge im allgemeinen Ergebnisse ungefiltert an die Benutzeroberfläche weiter, ohne dabei den Kenntnisstand des Benutzers 1 zu berücksichtigen. Infolge entsteht ein Benutzbarkeitsproblem, das nicht selten in dem kompletten Verzicht auf Sicherheit resultiert. Diese Arbeit beschreibt einen Entwurf eines Sicherheitswerkzeuges auf der Basis eines erstellten Stereotypen-Konzeptes. Als Ergebnis wurde ein Werkzeug entwickelt, dass sich bezüglich der Sicherheitsaspekte durch hohe Benutzbarkeit auszeichnet. 1 Statt Benutzer lese man wahlweise auch Benutzerin. 10

11 Kapitel 2 - Sicherheit Dieses Kapitel geht auf das Design und die zugrunde liegenden Standards zur Kommunikation mittels über das Internet ein. Hieraus folgend wird illustriert, aus welchem Grund eine normale nicht für vertrauliche Kommunikation geeignet ist. Hierauf aufbauend wird dargestellt, wie unter Einbindung von Kryptographie die Gewährleistung der vertrauenswürdigen Kommunikation erreicht wird. Diese zugrunde liegende Architektur bildet die Basis für eine darauf aufbauende Benutzerschnittstelle Dienst Der -Dienst stellt heutzutage einen der wichtigsten Dienste des Internet dar, egal ob für private oder geschäftliche Korrespondenz. Weltweit nutzten im Jahr 2001 über 350 Millionen Menschen das Internet. Hierbei stellt der Dienst mit 80% Nutzungsanteil einen der wichtigsten und regelmäßigsten Internet-Dienste dar. Zugleich sind an der Kommunikation alle Alters- und Bildungsschichten vertreten [BvE01]. -Nutzer sind leider oft gar nicht oder nur unzureichend über die Gefahren und Mißbrauchsmöglichkeiten dieser Kommunikationsform aufgeklärt. Verantwortlich hierfür sind das blinde Vertrauen in die Technik bei gleichzeitig geringem technischen Detailwissen. Die Vertraulichkeit einer -Kommunikation kann hierbei auf verschiedene Art unterlaufen werden. So kann eine auf dem Weg zum Empfänger von anderen gelesen und geändert werden. Ebenfalls kann ein Absender eine beliebige Identität vortäuschen, wodurch sich der Empfänger nicht sicher sein kann, ob das was er liest in der Form vom Sender geschrieben wurde und ob die authentisch ist [Kon00]. Die elekronische Postkarte Die umfasst standardisiert sehr viele Unterabschnitte und ist Initial in RFC 822 [Cro82] und als Erweiterung in RFC 2822 [Res01] abgehalten. Weiter gibt es zur sehr viele weiterführende Standards zur Definition von Erweiterungen. Die wohl wichtigsten sind RFC

12 KAPITEL SICHERHEIT 12 (Content-Type Definition [Sir88]) und RFC (MIME-Extensions [NF96a, NF96b, Moo96]). Um die Problematik bezüglich der Unsicherheit einer besser zu verstehen wird im folgenden der -Transportvorgang erläutert. Abbildung 2.1 illustriert das Zusammenspiel beim Senden einer zwischen den -Klienten 1 und dem -Server 2 (durch Verwendung des SMTP-Protokolls 3 ) sowie das Empfangen beim -Klienten. MUA = Mail User Agent MTA = Mail Transfer Agent SMTP = Simple Mail Transfer Protocol POP = Post Office Protocol Disk Adr: hier@gmx.com smtp.gmx.com smtp.web.de Adr: dort@web.de MUA SMTP MTA SMTP MTA POP MUA Benutzer schreibt E Mail versendet diese E Mail wird eingeliefert und weitergeleitet E Mail wird im entsprechendem Benutzer Postfach gespeichert Benutzer leer das Postfach und kann E Mail Nachrichten lesen Abbildung 2.1: -Transportvorgang Der Absender schreibt mittels MUA eine Nachricht. Der MUA kombiniert diese Nachricht (Nachrichtenrumpf oder auch Body genannt) mit einem sogenannten Nachrichtenkopf (auch Header genannt). Diese Kombination ist die eigentliche . Der Absender MUA sendet diese unter Verwendung des SMTP-Protokolls an einen MTA. Dieser nimmt die entgegen und leitet sie falls notwendig weiter. Dazu kommuniziert der MTA nun seinerseits wiederum per SMTP mit dem MTA des Empfängers (spezifiziert durch die Empfänger-Domain). Existiert auf dem MTA des Empfängers ein entsprechendes Postfach, so wird die Nachricht hier zwischengespeichert. Der Empfänger-MUA holt nun per POP-Protokoll 4 entsprechend zwischengespeicherte s vom MTA ab und erhält so die Nachricht des Absenders. Abbildung 2.2 zeigt als Beispiel eine durch den Absender-MUA generierte . Der Nachrichtenkopf enthält die notwendigen Kontrollinformationen für den Versand wie beispielsweise die Absenderadresse ( From: ) und die Empfängeradresse ( To: ). Der Nachrichtenrumpf enthält die eigentlichen Nutzdaten der . Alle Informationen werden hierbei im Klartext übertragen. Jeder an der Übertragung der beteiligte Rechner kann diese Daten nun lesen und modifizieren. Diese Eingriffsmöglichkeiten sind für einen funktionierenden -Versandes sogar notwendig. Leider können diese Möglichkeiten aber auch missbräuchlich verwendet wer- 1 -Klient: Mail User Agent, kurz MUA 2 -Server: kurz MTA, Mail Transfer Agent 3 SMTP: Simple Transport Protocol 4 POP: Post Office Protocol,

13 KAPITEL SICHERHEIT 13 From: hier@gmx.com To: dort@web.de Subject: Demonstration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mit diesem Textblock beginnt die eigentliche Nachricht. Der Nachrichtenrumpf und der Nachrichtenkopf sind durch eine Leerzeile voneinander getrennt. Der Nachrichtentext ist im Klartext lesbar. Abbildung 2.2: , vom Absender-MUA generiert den. Abbildung 2.3 zeigt eine mit Kontrollinformationen angefüllte , wie sie letztlich typischerweise beim Empfänger-MUA ankommt. Received: from [ ] (helo=smtp.gmx.com) by mx07.web.de with esmtp id... for dort@web.de; Tue, 22 Apr :42: Received: from local-dialin-port (unverified) by smtp.gmx.com with SMTP id... for <dort@web.de>; Tue, 22 Apr :26: Date: Tue, 22 Apr :23: From: hier@gmx.com To: dort@web.de Subject: Demonstration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.7 required=5.0 Mit diesem Textblock beginnt die eigentliche Nachricht. Der Nachrichtenrumpf und der Nachrichtenkopf sind durch eine Leerzeile voneinander getrennt. Der Nachrichtentext ist im Klartext lesbar. Abbildung 2.3: , nach erfolgter Zustellung Wird einer noch ein Datei-Anhang beigefügt, so wird der eigentliche Nachrichtenrumpf in separate Unterteile gegliedert und als sogenannter Multipart-Content-Type der als Nachrichtenrumpf angehängt. Hierbei wird für die im Multipart-Nachrichtenrumpf befindlichen Teilnachrichten (in diesen Fall eine Textnachricht und eine kleine Grafik) ein Begrenzer definiert, die boundary -Zeichenkette. Somit ist es dem MUA auf Empfängerseite möglich, die entsprechenden Nachrichtenteile aus dem so gekapselten Nachrichtenrumpf wieder eindeutig zu separieren. Abbildung 2.4 gibt hierzu ein Beispiel. Zusammenfassend bleibt festzuhalten, dass eine mittels SMTP-Protokoll versendet wird und damit keine Zustellgarantie besitzt. Die Adressierungsart einer , ableitbar aus Domäne und Benutzername, ist indirekt. Der Versand geschieht hierbei gepuffert und ist auftrags-

14 KAPITEL SICHERHEIT 14 From: hier@gmx.com To: dort@web.de MIME-Version: 1.0 To: dort@web.de Subject: Demonstration Content-Type: multipart/mixed; boundary=" cec68288cb83dac99a661" Dies ist eine mehrteilige Nachricht im MIME-Format CEC68288CB83DAC99A661 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mit diesem Textblock beginnt die eigentliche Nachricht. Der Nachrichtenrumpf und der Nachrichtenkopf sind durch eine Leerzeile voneinander getrennt. Der Nachrichtentext ist im Klartext lesbar CEC68288CB83DAC99A661 Content-Type: image/jpeg; name="bar2b.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="bar2b.jpg" /9j/4AAQSkZJRgABAQEASABIAAD//gAXQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q/9sAQwAIBgYH BgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIAAgAwEiAAIRAQMRAf/EABYAAQEBAAAAAAAA AAAAAAAAAAAHBv/EABcQAQADAAAAAAAAAAAAAAAAAAAXY6L/xAAWAQEBAQAAAAAAAAAAAAAA AAAABQb/xAAZEQABBQAAAAAAAAAAAAAAAAAAAgQTFVH/2gAMAwEAAhEDEQA/ANfIt2iRbtIy NvTt8J06izSLdokW7SMhTt8E6gLNHVOSOqclw30QKIyLNHVOSOqclw30QKP/2Q== CEC68288CB83DAC99A661-- Abbildung 2.4: inklusive Datei-Anhang, vom Absender-MUA generiert orientiert. Hierbei findet keine semantische Behandlung des -Nachrichtenrumpfes statt. Lediglich der Nachrichtenkopf ist für den Versand relevant und zwingend notwendig. Wohingegen der Nachrichtenrumpf beliebige Daten aufnehmen kann. Hieraus folgt aber auch der Verlust der vertrauenswürdigen Kommunikation. Denn während der Übertragung wird die Nachricht typischerweise über mehrere Rechnerknoten weitergeleitet und hier auch mehrmals in ihrer vollständigen Originalform (typisch Klartext) zwischengespeichert. Damit ist das lesen, auch zeitverzögert, möglich. Hat eine Person in irgendeiner Form Zugriff auf einen MTA erlangt, so kann diese alle ein- und ausgehenden s problemlos lesen, verändern, fälschen oder blockieren. Durch Einsatz von Filterprogrammen ist eine maschinelle Verarbeitung nach Inhalten möglich, welche besonders für Profilbildung, Wirtschaftsspionage, Werbezwecke oder Sonstiges genutzt werden könnten. Wer auf die Manipulation einer Nachricht verzichtet, dem genügt es als Angriff, wenn er nur ein Netzsegment beobachtet, welches für die -Weiterleitung zuständig ist. Dies ist technisch

15 KAPITEL SICHERHEIT 15 sogar noch einfacher wie die Manupulation zu realisieren und bleibt von außen oft vollkommen unentdeckt. 2.2 Sicherheitsanforderungen Im vorherigen Abschnitt wurde beschrieben, wie eine prinzipiell aufgebaut ist und wie deren Versand funktioniert. Hieraus abgeleitet konnte auf Angriffspunkte für einen möglichen Missbrauch eingegangen werden. Um dem entgegen zu wirken und vertrauenswürdige Kommunikation sicherstellen sind entsprechende Maßnahmen notwendig. Deren Anforderungen werden im folgenden definiert Schutzziele Am Kommunikationsvorgang einer über ein dezentrales Netz, wie das Internet, sind mehrere Parteien beteiligt. Jede am Kommunikationsvorgang beteiligte Partei besitzt eigene Sicherheitsmerkmale und entsprechende zu schützende Ziele (sogenannte Schutzziele). So sind beispielsweise dem Netzbetreiber Kosten-Abrechenbarkeit, Robustheit und Verfügbarkeit wichtig. Dem Sender einer kann beispielsweise die Vertraulichkeit wichtig sein. Zwischen den Kommunikationspartnern bildet sich hierbei eine bilaterale Sicherheit aus, die aus den gemeinsamen Schutzzielen entsteht. Zur Gewährleistung sicherer Kommunikation werden folgende Schutzziele vorgeschlagen: Vertraulichkeit Integrität Authentizität Nachweisbarkeit des Ursprungs (Unabstreitbarkeit) Mit Vertraulichkeit ist Schutz des Nachrichteninhaltes vor unbefugtem Mitlesens durch Dritte gemeint. Authentizität bedeutet, dass der Sender einer Nachricht verlässlich festgestellt werden kann. Ein Verlust von Integrität tritt auf, wenn ein unautorisierte und unbemerkte Veränderung der Nachricht stattfindet. Dagegen stellt die Nachweisbarkeit des Ursprungs sicher, dass der Empfänger gegenüber Dritten nachweisen kann, dass der Sender die Nachricht gesendet hat. [GM99] Definition: Innerhalb dieser Arbeit ist vertrauenswürdige Kommunikation das anwenderspezifische gesetzte bilaterale Schutzziel einer nicht leeren Teilmenge aus den Eigenschaften Authentizität, Integrität, Nachweisbarkeit des Ursprungs und Vertraulichkeit.

16 KAPITEL SICHERHEIT Sicherheitsmechanismen Die vier genannten Schutzziele können durch folgend vorgestellte Mechanismen implementiert werden. Typischerweise werden diese in Kombination eingesetzt. Werden noch weitere Mechanismen, wie ein Zeitstempeldienst integriert, können noch höherwertige Sicherheitsanforderungen erfüllt werden [Web98]. Verschlüsselung Die Verschlüsselung oder Kryptographie dient zur Absicherung des Schutzzieles Vertraulichkeit. Hierzu werden die Ergebnisse der Kryptologie verwendet und eine Nachricht in einen Schlüsseltext transformiert. Die Rücktransformation des Schlüsseltextes kann ein Kommunikationsteilnehmer nur durchführen, wenn er im Besitz eines entsprechenden Geheimnisses, dem Schlüssel, ist. Technisch kann zwischen zwei Verfahren unterschieden werden: symmetrische Verschlüsselungsverfahren Beide Kommunikationspartner besitzen gleiche Schlüssel zum Verschlüsseln der Nachricht und zum Entschlüsseln des Schlüsseltextes. Bekannte Vertreter sind die Verfahren: DES, IDEA, 3DES, CAST asymmetrische Verschlüsselungsverfahren Es existieren zwei unterschiedliche Schlüssel. Ein öffentlicher Schlüssel zum Verschlüsseln der Nachricht und ein privater (streng geheim zu haltender) Schlüssel zum Entschlüsseln des Schlüsseltextes. Asymmetrische Verschlüsselungsverfahren werden auch als Public-Key-Verfahren bezeichnet. Bekannte Vertreter sind die Verfahren: RSA, DSA/DSS, ElGamal Hierbei sei angemerkt, dass die Anwendung von Verschlüsselung allein nicht vor dem Wiedereinspielen einer Nachrichten oder dem kompletten Austausch einer Nachricht schützt. Nur die Vertraulichkeit des Inhaltes wird gewährleistet, nicht jedoch die Integrität. Einwegfunkionen Eine Einwegfunktion (auch Hash-Funktion genannt, siehe hierzu auch Seite 61) ist eine injektive Funktion H : M h die einen Nachrichtentext M beliebiger Länge auf einen Hash-Wert h fester Länge abbildet. Dieses Ergebnis wird als komprimierter Fingerabdruck (analog einer Prüfsumme) der Nachricht zur Integritätssicherung verwendet. Eine Eigenschaft der Einwegfunktion ist, dass, wenn sich die Nachricht M ändert, ergeben sich auch deutliche Änderungen an deren Hashwert h.

17 KAPITEL SICHERHEIT 17 Digitale Unterschrift Es besteht kein Zweifel an der Notwendigkeit von eigenhändigen Unterschriften in den unterschiedlichsten geschäftlichen- und auch privaten Bereichen. Seit es Dokumente gibt, werden eigenhändige Unterschriften genutzt, um deren Echtheit zu beweisen. Gleichzeitig erfüllt die eigenhändige Unterschrift neben vielen anderen die folgende Eigenschaften: [GC02, Alb] Authentisch Der Unterzeichner hat das Dokument willentlich und bewusst unterzeichnet. Fälschungssicher Der Unterzeichner und kein anderer hat das Dokument unterzeichnet. Die Unterschrift ist auch nicht kopiert worden. Unwiderrufbar Der Unterzeichner kann nicht glaubhaft leugnen, dass das Dokument von ihm unterschrieben wurde. Warnfunktion Die Ableistung der Unterschrift ist mit einem gewissen Aufwand verbunden. Durch diesen Schutz vor Übereilung kann der Unterzeichnende seine Erklärung nochmals überdenken. Die Abbildung der eigenhändigen Unterschrift in die Welt der digitalen Dokumente wird durch die digitale Unterschrift erreicht. Die digitale Unterschrift entsteht hierbei aus der Anwendung der asymmetrischen Verschlüsselung unter dem Aspekt, dass, wer im Besitz eines entsprechenden privaten Schlüssels ist, auch als authentisch gilt. Hierbei wird gleichfalls die Fälschungssicherheit gewährleistet. Hieraus folgt, dass durch Anwendung der digitalen Unterschrift die im Abschnitt genannten Schutzziele Authentizität, Integrität und Nachweis des Ursprungs erreicht werden. Bedingung hierzu ist, dass der zum Erstellen der digitalen Unterschrift notwendige Schlüssel (als Signaturschlüssel bezeichnet) eindeutig einem Benutzer zuordbar ist. Dieser Fakt wird durch Zertifikate gestützt. Gleichsam darf der Signaturschlüssel nicht kompromittiert worden sein. Digitale Unterschriften stellen damit eine wesentliche Voraussetzung für sichere Systeme dar. Sie werden benötigt, um vertrauenswürdige Aussagen bereitzustellen. Es wird von einer starken digitalen Unterschrift gesprochen, wenn zur Ableistung der digitalen Unterschrift entsprechend hochwertige (sichere) Verschlüsselungsverfahren verwendet wurden. Zertifikate Kryptographische Schlüssel alleine garantieren noch keine vertrauenswürdige Kommunikation. Vielmehr ist zusätzlich die einmalige und eindeutige Zuordnung eines öffentlichen Schlüssels zu den jeweiligen Schlüsselinhaber zwingend notwendig. Nur durch diese eindeutige Zuordnung kann entsprechendes Vertrauen aufgebaut werden.

18 KAPITEL SICHERHEIT 18 Diese Aufgabe, sowie den Schutz der Integrität des jeweiligen Schlüssels, erfüllen sogenannte Zertifikate. Hierbei kann ein Zertifikat zurückziehbar oder zeitlich beschränkt sein. Im diesen Zusammenhang unterscheiden wir zwischen verschiedenen Formen der Vertrauensbildung von Zertifikaten [AJM96]. Web-Of-Trust (Netz des Vertrauens) Das Konzept hierbei ist, dass ein dezentrales Vertrauensnetz aus Benutzern gebildet wird. Hierzu können die Benutzer ihre Schlüssel gegenseitig beglaubigen (zertifizieren). Abbildung 2.5 (a) zeigt dies im Beispiel. Hier hat Alice den Schlüssel von Bob beglaubigt, Bob den Schlüssel von Peter. Als logischen Schluss kann Alice auch den Schlüssel von Peter vertrauen (angedeutet). Certificate Chain (Hierarchische Vertauenskette) Das Konzept von Certificate Chain ist eine strenge hierarchische Ordnung, verdeutlicht in Abbildung 2.5 (b). Es wird auch bei den sogenannten X.509-Zertifikaten verwendet. An oberster Stelle befindet sich die Zertifizierungsinstanz (Certification Authority, kurz CA). Sie gibt zeitlich beschränkte Zertifikate an Unterinstanzen aus. In dieser Struktur haben somit automatisch alle Zertifikate die Gültigkeit ihrer jeweils übergeordneten Instanz. Es kann mehrere unabhängig separierte Zertifizierungsinstanzen für jeweils unabhängige Namensräume geben. Typischerweise können diese Zertifikate nicht zurückgezogen werden oder nur mit teilweisen Vertrauen ausgestattet werden. Multiple Certificate Chain Ähnlich wie Certificate Chain, jedoch bestehen zwischen den obersten Zertifizierungsinstanzen verschiedener Namensräume jeweils gegenseitige Zertifikate. Certificate Chain with reverse certificate Ähnlich zu Certificate Chain, jedoch sind alle Zertifikate entsprechend gegenseitig ausgestellt. Zertifizierungsinstanz Bob Zertifizierungsinstanz Alice Peter Alice Bob (a) Web-Of-Trust (b) Certificate Chain Abbildung 2.5: Zertifikatkette Zu der Unterscheidungsart wie die Kette der Zertifikate aufeinander aufbaut gibt es noch sogenannte qualifizierte Zertifikate. Qualifizierten Zertifikaten werden ausschließlich von gesetzlich autorisierter Stelle ausgestellte. Sie besitzen damit entsprechenden juristischen Wert und sind

19 KAPITEL SICHERHEIT 19 Voraussetzung für die gesetzliche Gleichstellung der digitalen Unterschrift mit der eigenhändigen Unterschrift entsprechend SigG. Rein algorithmisch unterscheiden sich diese Zertifikate jedoch nicht von Anderen, nur ihr Akzeptanzwert wird anders gewertet [Roß01] Resultat Durch Anwendung der zuvor vorgestellten Sicherheitsmechanismen sind die gesetzten Schutzziele für eine erreichbar. Diese Sicherheitsmechanismen finden im Nachrichtenrumpf Anwendung. Hierdurch bleibt die Kompatibilität mit bereits bestehender Infrastruktur voll erhalten. Durch Anwendung der Verschlüsselung kann der Nachrichtenrumpf entsprechend transformiert werden und das Schutzziel Vertraulichkeit kann gewährt werden. Der hierzu notwendige Schlüsselaustausch muss gewährleistet sein. Die Schutzziele Authentizität, Integrität und Nachweis des Ursprungs können unter Anwendung der digitalen Unterschrift gewährleistet werden. Grundlegend hierzu ist, dass nur der Eigentümer eines privaten Schlüssels die digitale Unterschrift ableisten konnte. Zum erreichen des Schutzzieles ist die digitalen Unterschrift auf Korrektheit zu prüfen. Um digitale Unterschrift anwenden zu können ist die eindeutige Bindung eines Schlüssels an einen Benutzer notwendig. Dieser Punkt wird durch sogenannte Zertifikate geleistet. Um diese Sicherheitsmechanismen praktisch anzuwenden bedient man sich sogenannter Sicherheitswerkzeuge. Das Sicherheitswerkzeug hat hierzu die vier grundlegenden kryptographischen Dienste zu erfüllen. Weiter muss es die Schlüsselabsicherung durch Zertifikate erfüllen. 2.3 Praktische Implementierungen Zur Anwendung der im Abschnitt 2.2 vorgestellten Sicherheitsmechanismen im Zusammenhang mit sind in den letzten Jahren einige Sicherheitswerkzeuge entstanden. Die wichtigsten sind PEM, PGP, OpenPGP und S/MIME. Sie werden im Folgenden kurz vorgestellt und ihre Eignung diskutiert Privacy Enhanced Mail (PEM) Privacy Enhanced Mail (kurz PEM) war eines der ersten Standards zum sicheren Übertragen von s. Die erste Version ist durch RFC [Lin93, Ken93, Bal93, Kal93] beschrieben. Heute ist PEM von keiner praktischen Bedeutung. PEM bietet die grundlegenden kryptographischen Dienste an. Dabei benutzt PEM das symmetrische Verschlüsselungsverfahren DES. Zum Austausch des symmetrischen Schlüssels wird RSA zusammen mit dem Hash-Verfahren MD5 verwendet. Das Schlüsselmanagment ist strikt hierarchisch und basiert auf X.509-Zertifikaten. Dabei definiert PEM zwei Stufen von CAs: die

20 KAPITEL SICHERHEIT 20 Policy Certification Authorities (PCA) und die Internet Policy Registration Authority (kurz IR- PA). Jede dieser PCA muss ihre Zertifizierungsrichtlinien veröffentlichen und bei einer IPRA hinterlegen. Designprobleme von PEM waren besonders die Reduktion auf nur 56 Bit-DES-Schlüsseln sowie die Beschränkung auf reine 7 Bit-ASCII-Nachrichten. Eine Erweiterung diesbezüglich stellt MIME Object Security Services (kurz MOSS) als Kombination von PEM und MIME dar. MOSS ist beschrieben in RFC 1848 [CFGM95], erreicht aber keine große Bedeutung Pretty Good Privacy (PGP) Pretty Good Privacy (kurz PGP 5 ) wurde 1991 von Philip R. Zimmermann als Shareware implementiert. Es war im Quellcode verfügbar und unterstützte gleichzeitig mehrere Betriebssystem- Plattformen. Infolge fand das Programm zur Verschlüsselung von Daten und schnell Verbreitung. Die ersten Versionen von PGP setzten dabei das RSA Verfahren in Kombination mit 3DES bzw. IDEA ein. PGP nutzt zur Absicherung der Schlüssel ein Web-Of-Trust. Neuere Versionen von PGP können zusätzlich auch X.509 Zertifikate verwenden. Das Datenaustauschformat für PGP ist in RFC 1991 [DA96] beschreiben. Im privaten Bereich zählt PGP heute zu einem sehr weit verbreiteten Sicherheitswerkzeug. Von Network Associates, Inc. wird zudem eine kommerzielle nicht Quelloffene Version vertrieben OpenPGP/GnuPG OpenPGP Open Pretty Good Privacy (kurz OpenPGP) ist eine offene Respezifikation für PGP mit deutlichen sicherheitstechnischen Erweiterungen. Ziel der OpenPGP Arbeitsgruppe [Atk03] der Internet Engineering Task Force (kurz IETK) ist die Bereitstellung von Standards für die Algorithmen und Formate zur Verarbeitung mittels PGP sowie die Bereitstellung und Definition der entsprechenden MIME-Strukturen zum Transport der entsprechenden PGP-Daten via und anderen Transport-Protokollen. Die OpenPGP-Spezifikation ist in RFC 2440 [JCT98] beschrieben. Hierbei stellt die OpenPGP-Spezifikation eine wesentliche Erweiterung der bereits bestehenden PGP-Spezifikation dar. GnuPG GNU Privacy Guard (kurz GnuPG) ist eine freie Implementierung von OpenPGP. GnuPG verfügt wie PGP über eine Vielzahl von kryptographischen Verfahren. Zudem ist GnuPG durch eine Schnittstelle leicht um neue Algorithmen erweiterbar. Der Quellcode ist frei verfügbar. GnuPG ist für viele Hardwareplattformen und Betriebssystemen erhältlich und wird ständig weiterentwickelt. Zudem ist GnuPG von patentrechtlich bedenklichen Algorithmen befreibar. 5 "PGP" und "Pretty Good Privacy" sind registrierte Marken von Network Associates, Inc.

21 KAPITEL SICHERHEIT Secure Multipurpose Internet Mail Extension (S/MIME) Secure/Multipurpose Internet Mail Extensions (kurz S/MIME) ist ist eine sicherheitstechnische Erweiterung des MIME-Standard [Cro82, NF96a, NF96b] für multimediale . S/MIME basiert hierbei für den Datenaustausch auf den Public Key Cryptography Standard (PKCS [SB93]). Um Nachrichten vertrauenswürdig per versenden zu können werden durch S/MIME eine Reihe neuere Inhaltstypen (Content-Type) definiert [SDLR95]. Die zu versendende Nachricht wird per MIME entsprechend neu strukturiert und anschließend jeder Teil nach Vorgabe verschlüsselt bzw. digital Unterschrieben. Hierzu wird S/MIME entsprechend fest in das E- Mail-Programm integriert. Die Nachteile von S/MIME sind die unflexiblen kryptographischen Algorithmen sowie die recht starke Beschränkung der möglichen Schlüssellänge. S/MIME verwendet ein hierarchisch organisierte Struktur von X.509-Zertifikaten Wahl des Verfahrens Alle hier vorgestellten Verfahren sind generell verwendbar, um die Zielsetzung der vertrauenswürdigen Kommunikation zu erfüllen. Zusammenfassend stellt Tabelle 2.1 die kryptographischen Fähigkeiten im Vergleich dar. PEM PGP OpenPGP S/MIME Standard RFC RFC 1991,2015 RFC 2440, 3156 RFC 2311, 2312 Sym. Verschlüsselung DES 3DES, IDEA, CAST5, RC2/40, CAST5, AES, AES192, 3DES IDEA 3DES, AES256, BLOW-/ TWOFISH Plugin 3 Asym. Verschlüsselung RSA DH/DSS, RSA ElGamal, RSA, DH/DSS, RSA ElGamal, DSA, DH/DSS, DSA Hash-Funktionen MD5 MD5, SHA-1 MD5, SHA1, MD5, SHA-1 RIPEMD-160 Dateninhalt 1 ASCII ASCII und binär ASCII und binär ASCII und binär -Anhänge nein ja, per MIME 2 ja, per MIME ja, per MIME Zertifikate X.509 Web-Of-Trust Web-Of-Trust X wie werden Daten behandelt 2 -Dateianhänge per PGP/MIME, RFC per Plugin leicht erweiterbar, z.b. MD2, Tiger-192, HAVAL, Elliptic Curve, ECDSA, Safer-SK128 Tabelle 2.1: Vergleich der praktischer Implementierungen Die hier vorgestellten Verfahren müssen sich zwei Forderungen unterziehen. Erstens der Bereitstellung zeitgemäßen und sicheren Verschlüsselungsverfahren. Zweitens einer geeigneten und akzeptablen Schlüsselerstellung sowie deren wirkungsvolle Absicherung durch Zertifikate.

22 KAPITEL SICHERHEIT 22 Von der Verwendung der Verschlüsselungsverfahren DES, RC2 und RC4 bei geringer Schlüssellänge ist aus heutiger Sicht abzuraten. Gleichfalls negativ zu bewerten ist die Beschränkung der RSA-Schlüssellänge auf 1024 Bit. Hiervon sind die Implementierungen PEM und S/MIME betroffen. PEM und S/MIME zeichnen sie durch eine streng hierarchisch organisierte Zertifikats-Struktur aus. Damit sind diese Verfahren für Organisationen und Firmen sehr gut geeignet. Ihre Schlüsselerzeugung ist aber nicht sehr transparent. Bei den Verfahren PGP und OpenPGP ist die Schlüsselerzeugung sehr transparent. Die Zertifikate können zudem sehr komplexe gesellschaftliche Vertrauensmuster abbilden. Das hierbei verwendete Netz des Vertrauens (Web-Of-Trust) kommt gesellschaftlichen Formen von Vertrauen sehr nahe. Gleichfalls erfüllen beide Verfahren die Anforderungen für Fortgeschrittene elektronische Signatur gemäß SigG [Roß01]. Aus diesem Grund wurde für diese Arbeit die Entscheidung getroffen, OpenPGP als zugrundeliegendes Sicherheitswerkzeug zu verwenden. In Folge wird der Begriff OpenPGP als Verallgemeinerung für die beiden praktischen Implementierungen GnuPG und PGP betrachtet. 2.4 OpenPGP -Einbindung In dieser Arbeit wird OpenPGP als Sicherheitswerkzeug zur Durchsetzung der Schutzziele entsprechend der vorgestellten Sicherheitsmechanismen verwendet. Hierbei arbeitet OpenPGP, wie im Abschnitt festgestellt, ausschließlich auf den Nachrichtenrumpf einer . Somit bleibt die Kompatibilität für bereits bestehende Infrastruktur zum Transport, Speicherung und Zustellung der erhalten. Anzumerken ist, dass durch OpenPGP keine Informationen aus dem Nachrichtenkopf gesichert werden. Um eine kryptographisch Nachricht im Nachrichtenrumpf einer einzubetten haben sich zwei Standards herausgebildet. Inline-PGP-Format Nachrichtenteil wird direkt ersetzt, Inhaltstyp bleibt erhalten OpenPGP/MIME-Format Nachrichtenteil wird in neuen Inhaltstyp gekapselt Inline-PGP-Format In Anwendung der beschriebenen Datenaustauschformate für PGP und OpenPGP [DA96, JCT98] ist es möglich eine Nachricht in eine sogenannte ASCII-Armor-Hülle zu kapseln. Diese Hülle eignet sich gut zum Transport einer Text-Nachricht per und ersetzt hierbei die eigentlichen Nachricht. Dieses Format wird oft als Inline-PGP-Format oder als ASCII-PGP-Format bezeichnet. Abbildung 2.6 zeigt als Beispiel eine mit digitaler Unterschrift (im Klartext). Die Klartext- Unterschrift ermöglicht das lesen des eigentlichen Nachrichtentext, selbst wenn der Empfänger kein entsprechendes Sicherheitswerkzeug hat, um die Unterschrift zu prüfen.

23 KAPITEL SICHERHEIT 23 From: hier@gmx.com To: dort@web.de Subject: Demonstration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mit diesem Textblock beginnt die eigentliche Nachricht. Der Nachrichtenrumpf und der Nachrichtenkopf sind durch eine Leerzeile voneinander getrennt. Der Nachrichtentext ist im Klartext lesbar BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) id8dbqe/cmilha4l/tutvfaraiipaj9nksmotpeqc/5tresjqvcslblxcqcepa4a LP8caMEfqww6aQXDG6XLX/0= =z8op -----END PGP SIGNATURE----- Abbildung 2.6: mit dig. Klartext-Unterschrift nach RFC 2440 Typisch wird dieses Format nur auf den Nachrichtentext und nicht auf einen Datei-Anhang bezogen. Der Vorteil dieses Formates ist seine große Verbreitung. Technisch kann jedes bestehende E- Mail-Programm leicht um diese Funktion erweitert werden. PGP/MIME-Format bzw. OpenPGP/MIME-Format PGP/MIME ist in RFC 2015, OpenPGP/MIME ist in RFC 3156 [Elk96, ME01] beschreiben. Beide Formate sind relativ äquivalent. Sie stellen eine konkrete Ausweitung von RFC 1991 bzw. RFC 2440 unter dem Aspekt neu definierter Inhaltstypen (MIME-Typen) zur Nachrichtenkapselung dar. Durch die Definition der neuen Inhaltstypen ist es nun möglich eine inklusive allen Datei-Anhängen gesamt zu sichern. Hierzu wird der eigentlich Nachrichtenteil entsprechend rekursiv in die notwendigen neuen Inhaltstypen gekappselt. Soll die Nachricht digital Unterschrieben werden, so wird der gesamte bisherige Nachrichtenrumpf in einen neuen Inhaltstyp (multipart/signed) gekappselt und die entsprechende Signatur angehängt. Soll eine Nachricht verschlüsselt werden, so wird die Nachricht in einen neuen Inhaltstyp (multipart/encrypted) gekappselt. Abbildung 2.7 zeigt als Beispiel eine . Die digitale Unterschrift gemäß RFC 3156 ist separiert und wird der Nachricht als Anhang beigelegt. Die Prüfung der digitalen Unterschrift ist obligatorisch.

24 KAPITEL SICHERHEIT 24 From: hier@gmx.com To: dort@web.de Subject: Demonstration Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ahhllboldkugwu4s" Content-Disposition: inline --AhhlLboLdkugWU4S Content-Type: text/plain; charset=iso Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mit diesem Textblock beginnt die eigentliche Nachricht. Der Nachrichtenrumpf und der Nachrichtenkopf sind durch eine Leerzeile voneinander getrennt. Der Nachrichtentext ist im Klartext lesbar. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) id8dbqa/cmozha4l/tutvfarapkwaj9l9ybnf6ucuzgx6mbyeky6ort+dwcccpen NTYZgySEPxHI91Is9/1CtsY= =lt+x -----END PGP SIGNATURE AhhlLboLdkugWU4S-- Abbildung 2.7: mit dig. Unterschrift nach RFC 3156 Durch die Kapselung ist es nun auch möglich s im HTML- oder Richtext-Format vertrauenswürdig auszutauschen. Abbildung 2.8 verdeutlicht dies am Beispiel einer verschlüsselten und digital Unterschrieben im HTML-Format. Nebenstehend ist exemplarisch die Verschlüsselungs-Hülle aufgebrochen. Das OpenPGP/MIME-Format umfasst hierbei sowohl den Nachrichtentext als auch alle Datei- Anhänge. Weiter definiert dieses Format noch entsprechende Erweiterungen, wie Schlüsseltransport und digitale Unterschriften nur über partielle Teile einer Nachricht. Der Nachteil des OpenPGP/MIME-Formates ist, dass bislang nur wenige -Programme hiermit kompatibel umgehen können.

25 KAPITEL SICHERHEIT 25 From: hier@gmx.com To: dort@web.de Subject: Demonstration Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="=-fq5ewj756rfihnoeew5v" Mime-Version: =-Fq5EWj756RfiHnoeEw5V Content-Transfer-Encoding: 7bit Content-Type: application/pgp-encrypted Version: 1 --=-Fq5EWj756RfiHnoeEw5V Content-Type: application/octet-stream; name=encrypted.asc Content-Description: Eine verschluesselter Nachricht Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.7 (GNU/Linux) hqioa4om4upxdycceaf+pww3phiisizar9ttw5jsl/dz0rl1/0wn+el9c0zcpy7x AC9yI//2Raqao8ZiccUbxEm771U30cNnT8Q06+opaqC5zE25l37s/Y15ECBqBQ0c drzokynm17aaihckbbupexhiqol9csbjih0s9/k7duzrmec1ms+cbn7wbkanweti RquFK1NFBK+S5cGDenqHBIy64vHNmtgcC40BJNNr24u5xV5xTuXB291Y8/WPzPvq 2JJ1Z6FU8mkhOwkqRYkTUJXpGz41ycpswQowMmVA+VSGYHllMcZpRHg2qpZU2CFE ajl7ra/0vpesjvxmtp28fhtjz/ojw9djp1fhmvopywf+p1nxmwp7ha0ocomkh37v Jwq1q4dEt5mRp6lIEZiieyY61bfnytr0WmMJH/2bkfE8PuhjQVXvEXHxl8Q8bnvU fqpith9kfz7869lv/igsall4riskds+kyx+j8dbllzxavwc+bnjdzheix9/f+lys PWfWBUW9FMC8G/WxSlYVBLJhGIILDm6pzmdQejCJOWEdsbB4j+YnVApVdFdB/EjG ktmil0wr929sx7v7/0xgs4grkff9k08xogwqe9xy6xxnutol4dm48dexzm+f2dg7 zebyej7hvlaublc9vcatxkshamdlm6jicnjs8wg3olmiwbbjacuzdrfzlkwc35n2 xtlpafx2vkfxxx4i7tinko5xr+opghdqfx5gffivdhh8dllvg6+a0aw8inbvgtfv ywjbvzlverkde0oypxfxnmknh6jngs10+ynoerhoilnua+ney3caad3vyxlik+lp CUNT79EDHCNx4zK/miqrk/BJkEQlBTJi79O/iBv6OOPr/FvLGwG08i7dqKw3BzTs 3NOz78qeELl8lNVk2xQrejp+jjpr6Wq/2SJO2XeRvi0PPP4Sczxg62Fw82BxFCdn za9hewlepui6wgxs8vqwygqav+sqazi80dk8cjdrybhklxtax2ce8n4ae6ndvoyt tbpyhcneufeeauohr/pazbdihfsccbv9gvdzc/gfxdiiik1x1prayp2vrhivuzl1 HRjOpN8dRZvumPCTXNHOktGl6KXnaed1dnBxUHE8yGTpc7rYVX6/mRGqoHsQV71M Y6ySMvWu1s+URVnCIFYDpblOySQd7991ho4O/COUASIjlfobjrP5Qc1wbZ0K9VqC Z5/6ZJE/OmZMS7E/ne28Lfm7WzXaicdBsQV5UdF4/y0/PkyJLrhOAfOfhJMaOiQ8 D7th6H8LzdKZbQ/eV5TgbAMiTsZ1KK+Jf5B8vhVAlJ9VTT8qah9EpF2sTlIVYVnb WrbvoqJxRUItV2xaUujCaWeSIiOy0fks1SdxwIH/lVoTSA7AWTo5KSsjLXbLNfpS otmz7ieqqarsk0ribjnouudfgyw4hmn5+ahysobpg4/wxhbw/x7dlz8vg0oghar1 23+bcZbWOG5oPINzsrkfXIISV7grOSH7frlxH6p9H3bPemcoSm/kowMpMdc5bvhr Yn3zYpweuKrwcoWid6Z/DphrtOB0srPzecbk188/ObEOLQW1VHO5AnHMzoTmAzrv eqnv9jnjzpkca/m0cnolxqlmlt3uekdm+it2xus82/8fpqxysxceo9kswdequjng aczokd4ppm9+tgeupjmvd/yexynmvdedzghutmosrpx+ybtoh/yggiatcjh5pi4u 7aQr6G6xpJNRmi9fXOJGq31prWTv5frmZM+shPNn =AQMB -----END PGP MESSAGE =-Fq5EWj756RfiHnoeEw5V-- From: hier@gmx.com To: dort@web.de Subject: Demonstration Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cdclznsvcd5+v5wtw/il" --=-cdclznsvcd5+v5wtw/il Content-Type: multipart/alternative; boundary="=-2xmqm/uikh26x5zxlrma" --=-2XMqm/Uikh26x5zXlrmA Content-Type: text/plain; charset=iso Content-Transfer-Encoding: quoted-printable Eine im HTML-Format kann Text auch fett und kursiv formatiert =FCbertragen. --=-2XMqm/Uikh26x5zXlrmA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8"> <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/1.0.4"> </HEAD> <BODY> Eine <TT> </TT> im HTML-Format kann Text auch <BR> <B>fett</B> und <I>kursiv</I> <FONT COLOR=3D"#0000f8">formatiert </FONT> &#2= 52;bertragen. <BR> <BR> </BODY> </HTML> --=-2XMqm/Uikh26x5zXlrmA-- --=-cdclznsvcd5+v5wtw/il Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) id8dbqa/czomict3os+2bharahk4ajkbishltys17yxyll4vwxazd4bplqcgjo7q 7kHtHSf8kCw3PKfqvk+0FGs= =6D8r -----END PGP SIGNATURE =-cdclznsvcd5+v5wtw/il-- Abbildung 2.8: im HTML-Format, entsprechend RFC 3156

26 KAPITEL SICHERHEIT OpenPGP Unterstützung vorhandener -Programme Nur dem sogenannte Mail User Agent (kurz MUA), das eigentliche -Programm das der Benutzer verwendet, obliegt die Unterstützung der Sicherheitsmechanismen. Der MUA hat hierzu den eigentlichen Nachrichtenrumpf entsprechend zu behandeln. Am Markt sind eine Reihe von -Programmen verfügbar. In Tabelle 2.2 ist eine subjektive Auswahl der wohl wichtigsten MUA und ihre Unterstützung für OpenPGP und Open- PGP/MIME dargestellt. MUA Produktname OpenPGP 1 OpenPGP/MIME 2 Bemerkung (RFC2440) (RFC3156) Microsoft Exchange 4.0 nein 3 nein Microsoft Outlook 5.x Plugin 4,6,8 nein 5, Plugin PGP 6.x oder GnuPG 1.x Qualcomm Eudora Plugin nein 5, Plugin PGP 6.x oder GnuPG 1-x Lotus Notes ja nein Netscape Messenger 4.x nein 3 nein 3, unfertige Plugins vorhanden Netscape Messenger 7.x Plugin Plugin 8 5, Enigmail-Plugin Mozilla Mail 1.x Plugin Plugin 8 5, Enigmail-Plugin kmail 1.4 ja nein benötigt installiertes GnuPG 1.x kmail 1.5 ja Plugin benötigt installiertes GnuPG 1.x pine ja nein benötigt installiertes GnuPG 1.x Ximian Evolution ja ja 5, senden nur im RFC3156-Format Emacs ja Plugin benötigt installiertes GnuPG 1.x Sylpheed nein ja benötigt installiertes GnuPG 1.x Apple Mail Plugin Plugin 7 per GPGMail-Plugin 1 OpenPGP: Inline-PGP-Format, auch ASCII-Armor-Format genannt, konform zu RFC1991, RFC OpenPGP/MIME: auch PGP/MIME-Format genannt, konform zu RFC2015, RFC3156, ggf. eingeschränkt 3 über Zwischenablage möglich 4 nur PGP-6.x Unterstützung 5 Unterstützung für S/MIME vorhanden 6 Konfigurationskonflikte zwischen Programm und Plugin vorhanden 7 Automatische Wahl beim senden zwischen RFC2440/ teilweise Probleme, Fehlfunktion Alle Namen sind Eigentum ihrer jeweiligen Inhaber. Tabelle 2.2: OpenPGP Unterstützung verschiedener MUA Es bleibt festzustellen, dass bei den betrachteten MUAs die eine Plugin-Technik verwenden kein Kandidat überzeugen konnte. Offensichtlich ist die Plugin-Schnittstelle nicht flexibel genug, um die gestellte Aufgabe adäquat zu lösen. Gleichfalls integrieren sich die Plugins teilweise nur schlecht in die Programmbenutzerführung. Im Bereich Freier Software sind die Bemühungen zur vollständigen Integration deutlich stärker. Als Beispiel sei hier der Ximian-Deskop oder Bemühungen verschiedener Linux-Distributoren zu nennen. Probleme existieren bei Freier Software jedoch im Bereich Software-Patente.

27 Kapitel 3 Benutzermodell In diesem Kapitel wird dargestellt was ein Benutzermodell ist. Hierzu wird eingangs die Notwendigkeit für dessen Einsatz erläutert, sowie die damit verknüpften Ziele und Forderungen. Abschließend wird unter Einbeziehung der Benutzerumfrage konkret auf die Benutzermodellierung eingegangen. 3.1 Motivation Wie eine Studie zur Online-Nutzung [BvE01] zeigt sind an der Online-Kommunikation alle Alters- und Wissensgruppen repräsentativ vertreten. Diesem Gesellschaftsquerschnitt müssen die Benutzerschnittstellen gerecht werden, um besonders auch Anfängern den Einstieg zu ermöglichen. Eine wesentliche Aufgabe der Benutzerschnittstelle ist es hierbei, Informationen und Abläufe für den Benutzer gemäß individuellen Anforderungen gerecht zu werden, bzw. zu filtern [PM99]. Eine benutzungsgerechte Software zeichnet sich dadurch aus, dass sie Benutzern mit unterschiedlichen Erfahrungen gerecht wird. Dabei ist es von großer Bedeutung, die verschiedenen Benutzererfahrungen so zu kategorisieren, dass die individuellen Unterschiede bei der Implementierung berücksichtigt werden können [Nie93]. Im Hinblick auf Signierwerkzeuge haben Untersuchungen die mangelhafte Benutzbarkeit und die daraus resultierenden Sicherheitsrisiken aufgezeigt [DS00]. Eine Folgerung hieraus ist, dass entsprechende Werkzeuge erst als sicher gelten, wenn sie auch benutzbar sind. Hierzu ist eine Benutzermodellierung notwendig [tmk00, WT99]. Zur Unterstreichung der Notwendigkeit eines Benutzermodells wird im Folgenden ein entsprechendes Negativbeispiel gegeben. Abbildung 3.1 zeigt ein Bildschirmfoto des Produktes Microsoft Outlook Express in Zusammenarbeit mit dem Plugin PGP von Network Associates, Inc. Eine digital unterschriebene Nachricht wird nach Prüfung in einen entsprechenden Statustext (vorangestelltes Sternchen * ) gekapselt und so modifiziert als Nachrichtentext im Dialogfenster präsentiert. Der Benutzer kann somit Statusinformation und eigentliche Nachricht nicht eindeutig trennen. Diese entsprechenden Meldungen besitzen technischen Charakter, weisen nicht auf die Sicherheitsbedeutung hin und sind nur in englischer Sprache gehalten. Das dies 27

28 KAPITEL 3. BENUTZERMODELL 28 Abbildung 3.1: Ergebnis der Signaturprüfung im Microsoft Outlook 5.5/PGP nicht nur ein trauriger Nebeneffekt ist, sondern auch zur vorsätzlichen Täuschung genutzt wird, bestätigen entsprechende Sicherheitsmeldungen Grundlagen Anforderungen und Ziele der Benutzermodellierung In der Vergangenheit wurden in der Regel statische Systeme entwickelt. Diese haben die Eigenschaft, dass lediglich in der Entwurfs- und Implementierungssphase Anforderungen an die Benutzerschnittstelle eingeflossen sind. Während der Betriebsphase sind dann keine Änderungen mehr möglich. Gleichfalls differenzieren derartige Systeme nicht bezüglich unterschiedlichen Anforderungen der Benutzer. Ebenfalls ist eine Erweiterung um benutzerinitiierte- und selektierte Adaption meistens nicht ausreichend, um die Benutzerschnittstellen entsprechend anpassbarer zu machen [HDSH93]. Der Grund hierfür liegt in vielen Fällen in der erwünschten Adaptionsleistung, die nicht angemessen erbracht werde kann [Kob93]. Damit ein Werkzeug einem breiten Benutzerkreis zugänglich ist werden unter anderen folgende Forderungen an die Adaptionsleistung gestellt [Kob93]: Erklärungskomponenten sollen ihren Ausgabetext an den (terminologischen) Wissensstand des Benutzers anpassen. 1 -Wurm W32/Mylife.M,

29 KAPITEL 3. BENUTZERMODELL 29 Es sind die Informationsbedürfnisse der Benutzer zu berücksichtigen, die sich aus dessen Ziele und Interessen ergeben. Das Layout, die Interaktionsoperationen und -formen von Benutzerschnittstellen sollten an die unterschiedlichen Aufgaben, Fähigkeiten und Präferenzen von Benutzern angepasst sein. Dies bedeutet am Beispiel der Prüfung einer digitalen Unterschrift, dass dem Benutzer der Status und die Bedeutung der Prüfung entsprechend seines Wissens zu präsentieren ist. Beispielsweise kann ein Sicherheitslaie Erklärungsbedürfnis für die Folgen einer als fehlerhaft geprüften digitalen Unterschrift haben. Gleichfalls interessiert es den Sicherheitslaien weniger, welches Hash-Verfahren zum Einsatz kam. Der Sicherheitsexperte mag hierzu jedoch detailierte Informationen erwarten. Eine benutzerinitiierte und -selektierte Adaption kann diese Anforderungen in vielen Fällen nicht erfüllen. Aufgabe der Benutzermodellierung ist, ein Computersystem dennoch zu befähigen, den Bedürfnissen eines Benutzers gerecht zu werden. Ein Benutzermodell ist hierbei eine Wissenbasis des Systems, die Annahmen über alle Benutzeraspekte enthält, die für das Dialogverhalten des Systems relevant sind (Wahlster und Kobsa, [AK89]). Im Blick auf Sicherheitswerkzeuge und Anwendung der Benutzermodellierung ergeben sich in Anlehnung an die Arbeit von Mertens und Höhl [PM99] folgende positive Effekte für den Benutzer: geringerer Informationsoverload treffendere und korrekte Interpretation von Sicherheitsaktionen und -Zuständen bedarfgerechtes Produkt größere Benutzerakzeptanz Arten der Benutzermodellierung Im Laufe der letzten Jahre wurde eine große Anzahl von Methoden zur Erstellung eines Benutzermodells vorgeschlagen. Sie lassen sich grundlegend nach folgenden Kriterien unterscheiden [Kob93]: Die Art der über den Benutzer getroffenen Annahmen. Die Integrierbarkeit des Benutzermodellerwerbes, sowie deren Informationensgewinnung. Die verwendete Technik. Die Sicherheit und Stabilität der getroffenen Annahmen im Zeitverlauf des Modells.

30 KAPITEL 3. BENUTZERMODELL 30 Merkmale Ausprägungen Zweck Selektion Präsentation Domäne System Gegenstand Kunde Empfänger Rolle Organis. Gruppe Bediener Individualisierung individuell differenziert Art der Informationen Veränderbarkeit Gewinnung Einsichtigkeit Gültigkeit Wissensakqisition weiche Informationen statisch implizit transparent langfristig personell harte Fakten dynamisch explizit ex anta ex post intransparent kurzfristig lernend Abbildung 3.2: Morphologie zur Benutzermodellierung (nach Mertens und Höhl, 1999) Als aktuellen Ansatz entwickelten Mertens und Höhl [PM99] eine Morphologie zur Benutzermodellierung. Diese wird in Abbildung 3.2 dargestellt. Sie weist die wesentlichen Eigenschaften von Benutzermodellen auf und ermöglicht gleichzeitig eine Einordnung deren Merkmale. Es sind eine Reihe von Techniken zur Umsetzung von Benutzermodellen entwickelt worden. Die wichtigsten hierbei zu nennenden Techniken sind die Erwerbsheuristik, die Stereotypen, sowie die Ziel- und Planerkennung. Erwerbsheuristiken bauen die Regeln für das Benutzermodell unmittelbar aufgrund von Benutzerinteraktion nach üblicherweise domänabhängigen Heuristiken auf. Der Stereotypenansatz verwendet eine a priori bekannte Ansammlung von Charakteristika, die bestimmte Benutzergruppen beschreiben. Sie dienen zur Vereinfachung der komplexen Welt und beruhen auf Erfahrungswerten. Bei der Ziel- und Planerkennung werden die aktuellen Eingaben des Benutzers verwendet und versucht das vermutliche Ziel des Benutzers zu erkennen. Entsprechend der Erkenntnisse soll das Benutzermodell entsprechend reagieren [Kob93]. 3.3 Stereotypen-Ansatz Sicherheitswerkzeugen ist immanent, dass sie von geringer Interaktionstiefe geprägt sind. Gleichzeitig wird vom Benutzer eine korrekte Interpretation von Sachverhalten verlangt, zu denen der Benutzer dem System aber kaum ein Feedback geben kann. Somit sind die Ansätze mit

31 KAPITEL 3. BENUTZERMODELL 31 Erwerbsheuristik und die Ziel- und Planerkennung für Sicherheitswerkzeuge wenig erfolgversprechend. Der Stereotypenansatz hingegen ist für diese Aufgabe besser geeignet. Indirekt wird die Ausformung von differenzierten Benutzerniveaus auch von Markotten et. al. [tmk00] gefordert. Mit dem Stereotypenansatz kann der unterschiedliche Kenntnisstand der Benutzer a priori einbezogen werden. Von E. Rich wurde der Stereotypenansatz in die Benutzermodellierung eingeführt [Ric79]. Hierbei sind Stereotypen eine Ansammlung von Charakteristika, die jeweils bestimmte Benutzergruppen beschreiben. Stereotypen vereinfachen hierbei eine komplexe Welt und beruhen auf a priori bekannten Erfahrungswerten. Somit verfügt das Dialogsystem gleich zu Beginn über entsprechende Annahmen zur Adaption an den Benutzer. Das Aufstellen der Stereotypen erfolgt nach A. Kobsa [Kob93] in folgenden drei Schritten: Identifikation der Benutzergruppen Untergruppe bilden, deren Mitglieder homogene anwendungsspezifische Merkmale besitzen Identifikation von Schlüsselmerkmalen Charakteristische Merkmale für die Zuordbarkeit von Benutzern zu einer Untergruppe. Repräsentation in (hierarchisch) Stereotypen Anwendungsrelevante Charakteristika der identifizierten Benutzergruppen werden geeignet gespeichert. Definition: Das Stereotyp S ist eine nicht leere Menge von anwendungsrelevant charakterisierenden Wertepaaren W aus der Wissenbasis KB zur Adaption des Benutzers B an das System. S B = { KB 1,W 1, KB2,W 2,, KBn,W n } 3.4 Identifikation durch Umfrage Um die notwendige Identifikation für den Stereotypen-Ansatz zu erhalten wurde eine Umfrage unter -Benutzern durchgeführt. Die Befragten konnten hierzu anonym wahlweise einen Papierfragebogen oder ein Online-Fragebogen ausfüllen. Alle Antworten waren als Multiple- Choice-Antworten ausgelegt. Die Umfrage wurde am 7.März 2003 gestartet. Der Fragebogen war in drei Teile gegliedert: Allgemeine Fragen: Angaben zu Geschlecht, Alter, der überwiegende Nutzungsform und -Dauer sowie eine Eigeneinschätzung der Sicherheitskenntnisse. Kenntnisse des Benutzers zur -Sicherheit: Insgesamt 13 Fragen zum Kenntnisstand des Benutzers. Die Fragen hatten verschiedene Schwierigkeitsstufen, die Umgangswissen, praktisches Wissen sowie Detailwissen erforderten.

32 KAPITEL 3. BENUTZERMODELL 32 Präferenzen zu Sicherheitsfunktionalitäten: Gewünschte Funktionalitäten des Benutzers bezüglich des -Programmes, sowie der Schlüsselverwaltung und der Interaktion. Die Fragen aus dem allgemeinen Bereich wurden zur Prüfung der Streuung der Befragten genutzt. Gleichzeitig gestatteten sie entsprechenden Kontrollaufschluss. Um den Kenntnisstand der Benutzer zu ermitteln, wurden Fragen aus den drei Themenbereichen Verschlüsselung, digitale Unterschrift sowie Zertifikate gestellt. Jeder Themenbereich enthielt zudem Fragen mit verschiedenen Schwierigkeitsgraden. Die Schwierigkeitsgrade ersteckten sich hierbei von allgemeinen Fragen über Praxisbezogene Fragen bis hin zu Fragen, die Detailwissen erforderten. Zielsetzung der Fragen des Kenntnisbereiches war, Benutzergruppen zu erkennen, sowie deren Anzahl. Zudem sollten die nicht korrekt beantworteten Fragen Aufschluss auf benutzergruppenbezogene Probleme liefern. Diese Ergebnisse bildeten später die Grundlage für die Stereotypen- Bildung. Der letzte Teil des Fragebogens beinhaltete Angaben zu den Benutzerpräferenzen. Diese waren in zwei Gruppen getrennt, eine für das -Programm und eine für die Schlüsselverwaltung. Primär war es wichtig die vom Nutzer benötigten Funktionen, sowie deren Stellenwert zu erkennen. 3.5 Auswertung der Umfrage Allgemeine Ergebnisse Insgesamt konnten 110 Fragebögen der Umfrage ausgewertet werden. 78% der Befragten waren männlich. Etwa die Hälfte (55%) der Befragten waren jünger als 30 Jahre, 16% gaben an, mindestens das 45. Lebensjahr erreicht zu haben. Die Eigeneinschätzung der Sicherheitskenntnisse ist fast gleichverteilt. Ähnliches gilt für die Nutzungsdauer von etwa einem bis über fünf Jahre. Die Auswertung der Kenntnisfragen ergab, 80% aller Befragten wissen, dass eine keine vertrauliche Kommunikation garantiert. Jedoch können nur weniger als ein Viertel aller Befragten sicher mit dem Status einer Prüfung einer digitalen Unterschrift bzw. eines Zertifikates umgehen. Dies sind wichtige Punkte im Zusammenhang mit dem Umgang von Verschlüsselung und digitaler Unterschrift. (Abbildung 3.3) Es wurde eine Cluster-Analyse durchgeführt um innerhalb der Antworten aus den Kenntnisfragen bestimmte Benutzergruppen feststellen zu können. (Abbildung 3.4 zeigt hierzu die zweidimensionale Antworthäufung.) Diese Analyse ergab nach dem Abstandskriterium drei Benutzergruppen, die nachfolgend als Anfänger, Fortgeschrittener und Experte bezeichnet werden. Für die so bestimmten Cluster von Benutzern wurden die Kenntnisfragen nochmals separat analysiert. Weiter konnte für jede dieser Benutzergruppen die jeweiligen Präferenzen ermittelt werden. Abbildung 3.5 zeigt die Ergebnisse bezogen auf die Funktionen zur vertrauenswürdigen Kommunikation.

33 KAPITEL 3. BENUTZERMODELL 33 Empfängerschlüssel zum verschlüsseln benötigt Unverschlüsselte Mail kann gelesen werden Verschlüsselte Mail kann verändert werden Verschlüsselung einer E Mail umfaßt... Immer gleiche Software notwendig Verschlüsseln mit Passwort Dig. Unterschrift gewährt Integrität Gültigkeit einer digitalen Unterschrift prüfbar Dig. Unterschrift nur mit Passwort Weiß nicht Falsch Richtig Bedeutung eines Zertifikates, Inhalt Zertifikate ausschließlich von auth. Stellen Zeitliche Gültigkeit eines Zertifikates Private Nutzung von beruflichen Zertifikaten 0% 25% 50% 75% 100% Abbildung 3.3: Kenntnisfragen, Durchschnitt aller Befragten 35 Netz Fortgeschr Experte Laie Abbildung 3.4: Clusterbildung nach Benutzerwissen

34 KAPITEL 3. BENUTZERMODELL 34 Anfänger Fortgeschrittener Experte E Mail verschlüsseln E Mail automatisch verschlüsseln Passwort (Mantra) merken E Mail digital Unterschreiben E Mail automatisch digital Unterschreiben Unterschrift automatisch prüfen Unterschrift/Verschlüsselung auch für Anhang Mehrere E Mail Accounts E Mail von mehrere Rechnern lesen/schreiben Aktionen manuell bestätigen Alle Parameter einstellbar Wichtigkeit (1=unwichtig, 5=sehr wichtig) Abbildung 3.5: Benutzer-Präferenzen

35 KAPITEL 3. BENUTZERMODELL 35 Anfänger Fortgeschrittener Experte Neues Schlüsselpaar erzeugen Weitere Benutzer ID hinzufügen Alle Parameter einstellbar Verfallsdatum und Vertrauen änderbar Passwort (Mantra) änderbar Einen existierenden Schlüssel löschen Einen Schlüssel ex bzw. importieren Schlüsselserver verwenden (ex und import) Ein Schlüssel Zertifikat prüfen Ein Schlüssel Zertifikat ausstellen Mehrere private Schlüssel verwenden Keyman durch externes Programm Wichtigkeit (1=unwichtig, 5=sehr wichtig) Abbildung 3.6: Benutzer-Präferenzen Schlüsselverwaltung Klar zu erkennen ist, dass mit steigenden Sicherheitsbewusstsein der Wunsch nach Automatismus sinkt. Sicherheitsexperten bewerten die Funktionalitäten deutlich zielgerichteter, während Sicherheitslaien (Benutzergruppe Anfänger) öfter mit Unsicherheit (Antwort weiß nicht ) antworten. Die Mobilität ist Sicherheitslaien primär am wichtigsten. Das Prüfen einer digitalen Unterschrift erachten alle Benutzergruppen als mindestens so wichtig, wie das erstellen einer digitalen Unterschrift. Jede Benutzergruppe hat jedoch unterschiedliche Kenntnisse zur Prüfung einer digitalen Unterschrift. Für die Schlüsselverwaltung ergeben sich ähnliche Ergebnisse. Nur 35% der Sicherheitsexperten würden jedoch ihren Schlüssel auf einem Schlüsselsserver veröffentlichen wollen, bei der Fortgeschrittenen Benutzern ist es fast die Hälfte der Befragten. Deutlich war hierbei zu erkennen, dass Sicherheitslaien (Anfänger) Probleme mit den Fragen zur Schlüsselverwaltung haben. Nicht selten wurde aus diesem Grund die Frage mit weiß nicht beantwortet. Hier kann direkt die Forderung abgeleitet werden, den Benutzer in diesen Punkt bestmöglichst zu unterstützen, um Ihn möglichst derartige Entscheidungen abzunehmen.

36 KAPITEL 3. BENUTZERMODELL 36 Abschließend bleibt festzuhalten, dass laut Umfrage die Benutzer sehr treffend eigenen Einstufungen zu ihren Sicherheitskenntnissen machen konnten. Somit obliegt es nicht dem Benutzermodell anhand der Interaktion den Wissensstand des Benutzers zu ermitteln, sondern der Benutzer kann selbstständig die jeweilige Gruppenzugehörigkeit treffen Identifizierende Merkmale Als Ergebnis der Umfrage können folgende Merkmale für die jeweiligen Benutzergruppen festgehalten werden. Anfänger (Sicherheitslaie) Benutzer die kaum Wissen zum Thema Kryptographie haben. Ihr Wissen über Sicherheitswerkzeuge ist beschränkt, sie bedürfen deutlicher Hilfestellung. Fortgeschrittener (Fortgeschrittener Benutzer) Benutzer die einige praktische Erfahrung mit Kryptographie haben. Sie haben bereits Sicherheitswerkzeuge benutzt, besitzen aber kein Detailwissen. Experte (Sicherheitsexperte) Benutzer die Detailwissen besitzen. Sie erwarten flexible und zielgerichtete Anwendung, die Ihrem hohen Kenntnisstand entspricht. Das Benutzermodell hat für die Benutzergruppen folgende Eigenschaften zu repräsentieren. Stereotyp Anfänger: Alle Aufgaben sollten nach Möglichkeit automatisch erfolgen. Das kann die Schlüsselerstellung und die Schlüsselauswahl (Senden) umfassen. Jedes unwichtige technische Detail ist zu verbergen. Es genügt ein einziges privates Schlüsselpaar mit Standard- Optionen. Der Umgang mit Zertifikaten ist zu vereinfachen. Kompatibilität mit anderen Programmen ist stärker zu beachten, deshalb sollte das Verfahren nach RFC 2440 verwendet werden. Klartext-Signaturen können Anwendung finden. Die Prüfung einer digitalen Unterschrift hat entsprechende Bedeutungsinformation zu tragen. Schlüsselexport sollte per Datei oder -Anhang erfolgen. Stereotyp Fortgeschrittener: Möglichkeiten der Schlüsselverwaltung können fast uneingeschränkt angeboten werden. Sie sind jedoch im Detailierungsgrad zu beschränken. Mehrere private Schlüssel sollen möglich sein, nicht jedoch mehrere Sub-Schlüssel und andere Spezialitäten. Schlüsselexport bevorzugt per Schlüsselserver. Die Prüfung einer digitalen Unterschrift hat entsprechende Bedeutungsinformation zu tragen. Das sollte möglichst immer automatisch verschlüsselt werden. Stereotyp Experte: Alle Aktionen geschehen manuell. Soweit möglich sind kennzeichnende technische Detail zu nennen. Der Experte verwendet mehrere private Schlüssel, gegebenfalls auch mehrere Benutzer-IDs und weiterte Sub-Schlüssel. Zertifikate sind umfassend zu unterstützen. Das Senden von s sollte per Standard nach RFC 3156 erfolgen. Statusinformationen sind kurz zu halten. Unabhängig vom gewählten Stereotyp sollte das System ständig versuchen die höchst mögliche Sicherheit zu erreichen. Als Beispiel sollte das Verschlüsseln einer vom System vorgeschlagen werden, falls ein entsprechender Schlüssel für den Empfänger vorhanden ist.

37 KAPITEL 3. BENUTZERMODELL Stereotypen-Hierarchie Im Zusammenhang mit den immanent verschiedenen Aufgaben entsteht somit die Stereotypen- Hierarchie nach Abbildung 3.7. Zu beachten sind Abhängigkeiten bei der Klasse der Benutzer zur Darstellung der Schlüsselauswahl. Gleichsam kann die Schlüsselverwaltung durch die Option von Mobilen Schlüssel (beispielsweise per Chipkarte oder mobilen Kleincomputer) vereinfacht bzw. delegiert realisiert werden. Benutzer E Mail Benutzer key select/fetch Wissen Schlüsselverwalter Wissen Sicherheits Anfänger Sicherheits Fortgeschrittener Sicherheits Experte Mobil Client Abbildung 3.7: Stereotypenhierarchie

38 Kapitel 4 Implementierung In diesem Kapitel wird auf die Umsetzung der Ergebnisse der Benutzerumfrage eingegangen. Hierzu werden zu Beginn die notwendigen Funktionen bestimmt und dann im Bezug auf die Benutzerumfrage gemäß den Stereotypen realisiert. 4.1 Funktionen Um vertrauenswürdige Kommunikation zu ermöglichen wurde im Rahmen dieser Arbeit die Entscheidung zur Verwendung von OpenPGP getroffen. Hieraus folgt, dass entsprechende kryptographische Schlüssel notwendig sind. Weiter folgen hieraus, dass bestimmte algorithmische Kernfunktionen für jede Benutzergruppe bereitzustellen sind. Diese Kernfunktionen lassen sich in die folgenden drei Gruppen unterteilen: Schlüsselmanagment Das Erzeugen, Verwalten und Löschen von Schlüsseln. Gleichfalls sollte auch ein initiales Setup für den Benutzer gewährt werden. Als Option fällt in diesen Bereich auch die Schlüsselmobilität. Lesen von s Die Behandlung empfangener s sowie die Erkennung des verwendeten Standards (RFC 2440 oder RFC 3156). Senden von s Die Behandlung zu sendender s sowie die damit verbundene Schlüsselauswahl. Das Schlüsselmanagment ist initial wichtig. Ohne entsprechend vorhandene Schlüssel kann keine digitale Unterschrift erstellt oder geprüft werden. Gleichfalls umfasst das Schlüsselmanagment auch die Visualisierung des Schlüsselbundinhaltes. Beispielsweise kommt diese Visualisierung gegebenenfalls bei der Auswahl zu verwendender Schlüssel zum Senden einer verschlüsselten zum tragen. 38

39 KAPITEL 4. IMPLEMENTIERUNG 39 Sub Key Typ wählbar Sec Key Pub Key Typ wählbar Pri Key Schlüssel löschen Standard werte Schlüssel erstellen Schlüssel zertifizieren Standard werte enable expire Schlüssel Perferenzen 1 default Schlüssel UID trust trust Mantra Schlüssel bearbeiten 1 Schlüssel anzeigen date Typ UID trust db prüfen Benutzer Schlüssel revoke enable ID/FPR Zertifikate Datei Server Zw.Ablage Schlüssel export GnuPG Terminal Schlüssel import Datei Server Zw.Ablage Abbildung 4.1: Anwendungsfalldiagramm Schlüsselverwaltung Abbildung 4.1 stellt die Funktionen des Schlüsselmanagments dar. Hierbei sind die notwendigen Funktionen als gerichtete Assoziation dargestellt. Als Verfeinerung sind in dieser Abbildung die Funktionen mit optionalen Charakter gekennzeichnet. Diese sind typischerweise nur dem Stereotyp Experte komplett verfügbar. Die notwendigen Funktionen folgen transitiv aus den Anforderungen zum lesen bzw. senden einer 1 (Abbildung 4.2). Stellt man die notwendigen Funktionen aus den Anwendungsfalldiagrammen in Beziehung zu den identifizierenden Merkmalen der Stereotypen (Abschnitt auf Seite 36), so kann folgende Entwurfsrichtline aufgestellt werden. Die Benutzermodellierung kann nicht nur alleinig darauf beruhen, nicht benötigte Funktionen gemäß den Präferenzen der Benutzergruppe auszublenden. Vielmehr muss jede Einzelfunktion in ihrer Gestaltung gegenüber der Benutzergruppe Berücksichtigung finden. Dies sollte je nach Art durch treffendere Beschreibungskomponenten erfolgen, oder durch ein einschränkendes Sichtenmodell. Funktionen, die nicht unbedingt notwendig sind, sollten nur Benutzergruppen zugänglich sein, die diese auch interpretieren können. Hier sei als Beispiel die Tiefenprüfung der Vertrauensdatenbank ( trust-db prüfen, Abbildung 4.1) genannt. 1 Respektive eine verschlüsselte oder digital unterschriebene .

40 KAPITEL 4. IMPLEMENTIERUNG 40 Status anzeigen Schlüssel anzeigen Benutzer E Mail lesen dig.unterschrift prüfen Schlüssel import trust expire Mantra E Mail entschlüsseln default Schlüssel Mantra Schlüssel anzeigen Schlüssel auswahl 1 dig.unterschrift erstellen 1..* Benutzer E Mail senden E Mail verschlüsseln Schlüssel export Schlüssel erstellen Abbildung 4.2: Anwendugsfalldiagramm lesen bzw. senden 4.2 Techniken zur Implementierung Entsprechend dem Ergebnis der Benutzerbefragung ist die Schlüsselverwaltung als separates Programm ausgelegt. Um dieses Werkzeug optimal den erkannten Benutzergruppen anpassen zu können, wurde die Entscheidung getroffen, das Schlüsselmanagment komplett neu zu programmieren. Als Basis hierzu wurde die GTK2 Bibliothek verwendet. Alle neuen Dialoge sind entsprechend an die lang diskutierten und stabilen Human Interface Guidelines (kurz HIG [CBR02]) angelehnt. Um die im Abschnitt genannten Sicherheitsmechanismen für die -Kommunikation verfügbar zu machen musste eine entsprechende Integration gefunden werden. Wie bereits in Abschnitt auf Seite 21 festgestellt, ist für eine Implementierung eine auf Plugin-Technik aufbauende Lösung nicht erfolgsversprechend. Aus diesem Grund wurde entschieden, ein bereits bestehendes Quelloffenes -Programm entsprechend zu modifizieren. Als Backend findet jeweils GnuPG 2 in der Version sowie libgpgme 3 in der Version Verwendung. GnuPG kann hierbei um weitere Module dynamisch erweitert werden. Die für die Benutzermodellierung initial notwendigen Eigenschaften werden in einem XML- Schema (Modellbeschreibung) extern gespeichert. Somit können Änderungen am Stereotyp nachträglich einfach erfolgen. Ebenfalls extern gespeichert sind alle Beschreibungstexte, wodurch eine einfache Internationalisierung (i18n) sowie Lokalisierung (l10n) des Werkzeuges möglich ist. 2 GnuPG: GNU Privacy Guard, 3 libgpgme: GnuPG Made Easy, Bibliothek,

41 KAPITEL 4. IMPLEMENTIERUNG Die Schlüsselverwaltung Will man vertraulich mit einem Kommunikationspartner s austauschen, oder dessen digitale Unterschrift prüfen, so benötigt man den öffentlichen Schlüssel des Kommunikationspartners. Gleichfalls sollte man dem Kommunikationspartner seinen öffentlichen Schlüssel bereitstellen können. Diese Managmentaufgabe, sowie die Generierung von einem eigenen Schlüsselpaar sind die primären Aufgaben der Schlüsselverwaltung (kurz keyman genannt). Das Erstellen eines eigenen Schlüsselpaares ist die erste Aufgabe eines Benutzers, um vertrauenswürdige Kommunikation mittels nutzen zu können. Aus diesem Grund muss das Erstellen eines eigenen Schlüsselpaares für jeden Benutzer ohne Probleme möglich sein. (a) Start-Information (b) Benutzer-ID angeben (c) Mantra eingeben (d) Hinweise am Ende Abbildung 4.3: Druid Schlüsselerzeugung Die Schlüsselverwaltung prüft bei jedem Programmstart, ob der Benutzer ein eigenes Schlüsselbund besitzt und ob ein eigenes Schlüsselpaar existiert. Existiert kein eigenes Schlüsselpaar wird der Druid zum Erzeugen eines Schlüsselpaares automatisch gestartet (Abbildung 4.3). Dialogbasiert wird in einzelnen Schritten ohne technische Detailfragen ein Schlüsselpaar erstellt. Falls durch den Administrator nicht anders angegeben, wird ein 1024 Bit ElGamal/DSA- Schlüssel erzeugt. Gemäß den Ergebnissen der Benutzerumfrage wird der öffentliche Schlüs-

42 KAPITEL 4. IMPLEMENTIERUNG 42 selteil nicht automatisch auf einen Schlüssel-Server exportiert 4. Ebenfalls als Ergebnis der Umfrage wurde für die Benutzergruppen Anfänger und Fortgeschrittener die Anzahl an möglichen Schlüsselpaaren begrenzt. Abbildung 4.4 verdeutlicht die jeweiligen Eigenschaftswerte des Modells zur Schlüsselgenerierung im Bezug auf die jeweiligen Benutzergruppen. Benutzer der Gruppe Anfänger können, wie schon beschrieben, keinen Einfluss auf die technischen Details der Schlüsselerzeugung nehmen. Benutzer der Gruppe Fortgeschrittener können dialogbasiert Einfluss auf den Schlüsseltyp sowie die Schlüssellänge nehmen. Hierbei wirkt sich die Schlüssellänge nur auf den Sub-Schlüssel aus. Der Primär-Schlüssel 5, falls laut gewählten Schlüsseltyp möglich, wird immer die maximal mögliche Schlüssellänge erhalten. Benutzer der Gruppe Experte können jede Schlüsselmöglichkeit aktivieren, notfalls unter Zuhilfenahme des GnuPG-Terminals. keyman:generate_key user_id : String passphrase : String default_key : String nummax_seckey : Int gpg_directory() mk_gpg_directory() gpg_version() gpg_store_default_key() gpg_gen_key() <<Beginner>> keyman:druid_gen_key <<Intermediate>> keyman:create_key <<Expert>> keyman:{create_key,term} user_lever = 1 KeyType = 1 user_lever = 2 KeyType {KeyTyp=1,.,7} user_lever = 3 KeyType {KeyType > 0 } KeySize = 1024 KeySize = 1024 KeySize = 1024 SubKeySize = 1024 SubKeySize = 2048 SubKeySize = 2048 use_druid = TRUE use_druid = FALSE use_druid = FALSE checkuid = TRUE MinMantraSize = 5 checkuid = TRUE MinMantraSize = 5 checkuid = TRUE MinMantraSize = 5 expire = 0 expire = 0 expire = has_invalid_char() has_invalid_char() has_invalid_char() Abbildung 4.4: Stereotypen-Attribute zur Schlüsselerzeugung Nach erstellen eines Schlüsselpaares wird der Benutzer durch das Hauptfenster ähnlich Abbildung 4.5 begrüßt. 4 Laut [WT99] ist das Exportieren per Schlüssel-Server kein benutzerrelevantes Problem. 5 Primär-Schlüssel: Typisch der Signaturschlüssel, normal 1024 Bit DSA. Unter GnuPG kann ein Schlüssel aus einem Primär- und mehreren Sub-Schlüsseln bestehen (jeweils mit eigenen preferences und expire - Daten).

43 KAPITEL 4. IMPLEMENTIERUNG 43 Das Hauptfenster teilt sich in folgende Elemente: der Menü- und Werkzeugleiste, der Schlüssel-Listenansicht, dem Kartenreiter mit Detail- und Zertifikatansicht. Abbildung 4.5: Hauptfenster (Anfänger) Die Darstellungsformen des Haupfensters und seinen Elementen variieren an Umfang und Information abhängig von der gewählten Benutzerstufe. In der Benutzerstufe Anfänger enthält die Schlüssel-Listenansicht alle im Schlüsselbund enthaltenen Schlüssel. Jeder Listeneintrag besteht hierbei aus der Benutzer-ID des Schlüsselinhabers, sowie einem vorgestellten Symbol zur Art des Schlüssels (öffentlicher Schlüssel, Schlüsselpaar, erweitere Benutzer-ID). Das Symbol trägt ein rotes Kreuz, falls der Schlüssel ungültig ist (aufgrund von Verfallsdatum oder Widerruf). Zu dem in der Schlüssel-Listenansicht selektierten Schlüssel enthält der Karteireiter am unteren Fensterende weitere Informationen. So werden hier alle zum Schlüssel gehörenden Benutzer-IDs angezeigt, sowie die Foto-ID, falls vorhanden, und der Status der Echtheitsbeglaubigungen. Ist der Toggle-Button 6 Details im Karteireiter aktiviert, so werden weiterführende Informationen angezeigt. Diese Informationen umfassen die kryptographische Fähigkeit des Schlüssels, den Status der Vertrauensstufe sowie das Verfallsdatum. Welche Informationen genau angezeigt werden wird hierbei durch das Benutzermodell geregelt. Insgesamt stehen 12 6 Toggle-Button: Ein Widget-Element das einen einrastbaren Schaltknopf darstellt.

44 KAPITEL 4. IMPLEMENTIERUNG 44 Informationsblöcke zu Verfügung. Primär ist somit dem Anfänger eine Schlüsselmanagment auf Ebene der Benutzer-ID möglich, ohne Ablenkung durch technische Details zu erfahren. Für die Benutzerstufe Experte enthält sowohl die Schlüssel-Listenansicht, wie auch der Karteireiter eine Fülle an Informationen. So beinhaltet die Schlüssel-Listenansicht nicht nur mehr Spalten mit Informationen zum Verfallsdatum, sondern auch Angaben zu den Kryptographieverfahren des Schlüssels. Der Karteireiter enthält ebenfalls umfangreiche Informationen, wie die Schlüssel-Nummern bzw. Schlüssel-Sub-Nummern, den Schlüssel-Fingerabdruck und die Schlüssel-Fähigkeiten. Der zweite Eintrag des Karteireiters Zertifikate enthält eine vollständige Auflistung aller Einzelzertifikate zum jeweils selektierten Schlüssel (Abbildung 4.6). Abbildung 4.6: Hauptfenster (Experte, Zertifkatliste) Abbildung 4.7: Zertifikat-Liste (Anfänger)

45 KAPITEL 4. IMPLEMENTIERUNG 45 Die Benutzergruppe Anfänger erhält in der Darstellung der Schlüssel-Zertifikate nur eine vereinfachte Listendarstellung, die lediglich die Gültigkeit aller Fremd-Zerifikate einmalig auflistet (Abbildung 4.7). Zur Modellierung der Benutzergruppen für die Schlüssel-Listenansicht und die Karteireiter stehen insgesamt 30 Informationsblöcke zur Verfügung, die jeweils durch die extern gespeicherte Modellbeschreibung (XML-Schema, analog zu Abbildung 4.4) konfigurierbar sind. Hiervon sind zudem auch die Funktionen für die Vertrauensdatenbank betroffen. Durch Verwendung der externen Modellbeschreibung ist die Schlüsselverwaltung auch an spätere Informationsbedürfnisse einfach adaptierbar. In der Benutzerstufe Fortgeschrittener liefert der Schlüsselmanager ein Mittel aus den beiden anderen Stereotypen (Anfänger und Experte). Hierbei fehlen jedoch technische Daten, wie Kryptographieverfahren oder ausführliche Angaben zu Einzelzertifikaten. Typisch sind Aktionen von Sicherheitswerkzeugen, wie die der Schlüsselverwaltung, unwiderruflich [tmk00]. Das bedeutet insbesondere, dass nicht nur die Informationspräsentation und der Funktionsumfang den Bedürfnissen der Benutzergruppe anzupassen sind, sondern auch unter dem Aspekt des Kenntnisstandes und der Fehlhandlungssicherheit zu betrachten sind. Hierzu zählen im Bezug auf die Schlüsselverwaltung das Löschen eines privaten Schlüssels oder das versehentliche kompromitieren eines privaten Schlüssels. Aus diesem Grund schränkt die Schlüsselverwaltung keyman für die Benutzergruppe den Funktionsumfang gezielt ein. Beispielsweise sind die Exportmöglichkeiten der Benutzergruppe Anfänger derart eingeschränkt, dass hierdurch kein versehentliches kompromitieren des privaten Schlüssels möglich ist (Abbildung 4.8). Analog wird auch bei den anderen Funktionen, wie das Erstellen eines Zerifikates, dessen Typ oder eines Schlüsselwiderrufes, verfahren. (a) Benutzergruppe Anfänger (b) Benutzergruppe Experte Abbildung 4.8: Schlüssel-Export im Vergleich Generell arbeitet die Schlüsselverwaltung mit modalen Dialogen mit einfacher Tiefe. Somit kann der Benutzer zur gleichen Zeit immer nur eine Funktion aktivieren und die Schlüsselkon-

46 KAPITEL 4. IMPLEMENTIERUNG 46 sistenz ist somit gewährt. Je nach Benutzergruppe wird der Dialog zudem durch Mini-Hilfe 7 unterstützt. Hierbei sind alle Programm-Textausgaben unter Verwendung von i18n und l10n an die jeweilige Muttersprache und deren Lokalisierung extern anpassbar. Dies schließt auch die Online-Dokumentation ein. 4.4 Mobile OpenPGP - Schlüssel Mit der bisher dargestellten Form der Schlüsselverwaltung werden die OpenPGP-Schlüssel ausschließlich lokal gespeichert. Ein Computersystem des Benutzers ist aber typischerweise nicht portabel. Die Ortsunabhängigkeit kann mit lokalen Schlüsseln jedoch nicht sichergestellt werden. Wie die Benutzerumfrage ergeben hat, ist allen Benutzergruppen die Flexibilität, an verschieden Rechnern s schreiben und lesen zu können, keinesfalls unwichtig. Um dies auch im Rahmen mit digitaler Unterschrift und Verschlüsselung ermöglichen zu können, muss zumindest das Schlüsselbund des Benutzers mobil werden. Primär ist hier nur das Schlüsselpaar des Benutzers wichtig. Alle anderen öffentlichen Schlüssel könnten theoretisch bei Bedarf von einem Schlüssel-Server bezogen werden. Voraussetzung hierzu wäre jedoch zusätzlich eine geschlossene Zertifikatkette. Um der Forderung nach Schlüssel-Mobilität gerecht zu werden, ist eine einfach Lösung die Speicherung des Benutzerschlüsselbundes auf einem tragbaren Speichermedium. Im Rahmen der Arbeit wurde hierzu nach einer exemplarischen Lösung gesucht. Folgende Speichermedien scheinen für die Realisierung als geeignet: Diskette im 3,5 Zoll-Format, USB-Speicherstick, Chipkarte, CompactFlash-Card oder SmartMedia-Card. Hierzu wurden zehn Benutzer gefragt, welches Speichermedium sie bevorzugen würden. Als Ergebnis favorisierten acht Benutzer die Lösung per Chipkarte. Somit wurde die Entscheidung für eine exemplarische Lösung per Chipkarte getroffen. Chipkarten haben besonders vorteilhafte Abmessungen und ermöglichen so den OpenPGP-Schlüssel vollkommen neue Mobilität. Gleichzeitig sind entsprechende Lesegeräte heute aufgrund von Online-Banking nicht selten. Das Medium Chipkarte garantiert jedoch keine sichere Verwahrung der Schlüssel. Zudem ist die hier vorgestellte Lösung nicht konform zum Entwurf nach dem Signaturgesetz (SigG), da der verwendete Kartenleser nicht DIN-17.4 entspricht. 7 Mini-Hilfe: Kurzer Erklärungstext, wird angezeigt, wenn der Mauszeiger über einem Widget-Element steht.

47 KAPITEL 4. IMPLEMENTIERUNG 47 Um die Schlüssel-Mobilität nahtlos anknüpfen zu können, wurden folgenden Entscheidungen getroffen: Die OpenPGP-Schlüssel (genauer das gesamte Schlüsselbund) werden auf der Speicher- Chipkarte gespeichert. Zur Ausführung von Verschlüsselungsoperation werden die Schlüssel von der Chipkarte temporär in das Computersystem übertragen. Temporär ins Computersystem übertrage Schlüssel unterscheiden sich von lokal gespeicherten Schlüsseln nicht. Somit ist die Interoperabilität zwischen Sicherheitswerkzeugen garantiert. Die auf der Speicher-Chipkarte abgelegten Daten sind nicht gegen fremdes Auslesen geschützt. Dieser Schutz ist nur durch Verwendung von Prozessor-Chipkarten möglich, diese sind aber auf dem freien Markt derzeit nur mit eingeschränkter Speicherkapazität verfügbar. Statt dessen werden die auf der Karte gespeicherten Daten wahlweise symmetrisch verschlüsselt. Zur Übertragung der Daten wird die CT-API verwendet, die sehr viele Chipkartenleser akzeptieren. Je nach Speichervolumen der Chipkarte und Schlüsselumfang können so ca. 3 bis 30 Schlüssel gespeichert werden. Abbildung 4.9: Mobile Schlüssel mit Smart GnuPG Abbildung 4.9 zeigt eine Bildschirmfoto von Smart GnuPG, das für die Mobilität der OpenPGP- Schlüssel entwickelt wurde. Es verfügt nur über drei Funktionen. Download und Upload garantieren den Datenaustausch von und zur Chipkarte. Shreddern ermöglicht den Benutzer das manuelle Löschen aller temporär erstellten Daten durch mehrfaches Überschreiben. Ein Benutzermodell fand keine weitere Anwendung, da außer den drei Funktionen keine weitere Programminteraktion möglich ist.

48 KAPITEL 4. IMPLEMENTIERUNG Die Integration Um die beschriebenen Sicherheitsmechanismen für den Benutzer einfach bereitstellen zu können, wurde eine Integration in ein bereits bestehendes Programm vorgenommen. Hierzu wurde das Quelloffene Programm Balsa 8 in der Programmversion gewählt. Im Folgenden wird unter dem Namen Balsa immer die entsprechend modifizierte Variante (Branch) verstanden. Um besonders für Sicherheitslaien den Einstieg zu erleichtern wurde das initiale Programmsetup geändert und um die Funktion einer OpenPGP-Schlüsselerzeugung erweitert. Aus den Angaben zum einzurichtenden Konto werden dann Informationen zur Erzeugung eines OpenPGP-Schlüssels entnommen, falls nicht schon ein entsprechender Schlüssel existiert. Dieser Vorgang läuft damit äquivalent zur Schlüsselerzeug im Anfängermodus der Schlüsselverwaltung ab. Infolge ist der Benutzer technisch befähigt, digitale Unterschriften erstellen zu können. Als Abschluss des initialen Programmsetups wird der Nutzer in die Benutzergruppe Anfänger eingestuft, kann dieses aber manuell jederzeit selbstständig ändern. Um die geforderten Sicherheitsmechanismen innerhalb des -Programmes umsetzen zu können, sind entsprechende Funktion nötig. Beispielsweise sind zum Lesen einer die Funktionen MIME-Type Erkennung, sowie das Entschlüsseln bzw. Prüfen der digitalen Unterschrift entsprechend der Art des Nachrichtenrumpfes (Abbildung 4.10) nötig. Analog ist hierzu der Fall zum Senden einer zu betrachten. Zusammen mit dem Anwendungsfalldiagramm Abbildung 4.2 auf Seite 40 ergibt sich somit die Erkenntnis, dass die Ausformung für die jeweiligen Stereotypen nicht durch entsprechende Gruppierung von optionalen bzw. notwendigen Funktionen möglich ist. Vielmehr muss innerhalb des -Programmes für jeden Stereotyp eine geeignete Parametrisierung der Funktionen gefunden werden, die den Präferenzen der Benutzerumfrage entspricht. Mantra eingeben E Mail lesen MIME Typ erkennen */*encrypted */*signed text/plain RFC 3156 MIME Typ prüfen auf RFC 2440 signiert verschlüsselt signiert Unterschr. prüfen Mantra eingeben Unterschr. prüfen signiert signiert E Mail sowie Status an zeigen Abbildung 4.10: Funktionen zum Lesen einer (OpenPGP-) 8 Balsa, auf GTK2 aufsetzendes -Programm,

49 KAPITEL 4. IMPLEMENTIERUNG 49 Neben der Parametrisierung muss die Ausformung der Programmfunktionen deutliche Rücksicht auf den Kenntnisstand des Benutzers nehmen. Um dies zu erreichen wurden entsprechende Bedeutungsnachrichten über den Status einer Sicherheitsprüfung im Programm verankert, die je nach Benutzergruppe unterschiedlich stark ausgeprägt sind. Somit wird dem Kenntnisstand der Benutzer Rechnung getragen. Unter Verwendung von i18n können diese Programmnachrichten zudem ohne Probleme entsprechend internationalisiert werden. Abbildung 4.11: Ergebnis der Signaturprüfung (fehlerhaft) im Balsa Abbildung 4.11 zeigt in Anlehnung zu Abbildung 3.1 auf Seite 28 das Ergebnis einer Prüfung der digitalen Unterschrift. Zur Unterstützung der Ergebnismeldung zum Sicherheitsstatus wurden jeweils entsprechende Logos entworfen. Die Platzierung der Logos ist so gewählt, dass eine Vermischung mit den Nachrichtentext nicht möglich ist. Somit wird eine fehlerhafte Interpretation, wie am eingangs erwähnten Negativbeispiel, vermieden. Zudem wird der Status der Nachricht durch farbliche Balken an der Seite der unterstützt. Hierzu wurden Farben mit entsprechender Signalwirkung verwendet (Abbildung 4.12). Somit bleibt der Bezug zur Sicherheitsmeldung erhalten, selbst wenn der Nachrichtenkopf und das Logo ausserhalb des Sichtbereiches liegt. War die Nachricht zudem verschlüsselt, wird das Logo um ein Schloß symbolisch erweitert. Konnte eine existierende digitale Unterschrift einer Nachricht nicht geprüft werden, weil beispielsweise der hierzu notwendige öffentliche Schlüssel des Absenders im Schlüsselbund des

50 KAPITEL 4. IMPLEMENTIERUNG 50 Abbildung 4.12: Ergebnis der Signaturprüfung (gültig) im Experten-Modus Benutzers fehlt, so erfolgt ein entsprechender Hinweis. Dieser Hinweis gibt dem Benutzer konkrete Angaben, welcher Schlüssel entsprechend zu importieren ist. Möchte der Benutzer eine verschlüsselte lesen, so wird zuvor geprüft, ob der hierzu notwendige Schlüssel vorhanden ist. Ist dieser Schlüssel vorhanden wird per modal-transienten popup-dialog die Eingabe des entsprechenden Mantras (Passwort) gefordert. Hierbei wird der Benutzer informativ unterstützt, dass dieses Mantra zum entschlüsseln notwendig ist. Handelt es sich um eine asymmetrisch verschlüsselte , so wird dem Benutzer durch den Dialog mitgeteilt, um welchen Schlüssel, charakterisiert durch die Benutzer-ID, es sich handelt. In den Benutzergruppen Fortgeschrittener und Experte wird hierbei zusätzlich die entsprechende Schlüssel-Nummer angezeigt. Das Mantra wird hierbei durch den Dialog nicht gespeichert, dies entspricht den Präferenzen der Benutzerumfrage. Balsa unterstützt zudem das Lesen von symmetrisch verschlüsselten . Zum Verfassen einer neuen verwendet der Benutzer den Balsa-Composer. Die Sicherheitsmechanismen Verschlüsselung und digitale Unterschrift sind innerhalb des Composer einfach anwendbar. Die Werkzeugleiste 9 des Composer enthält hierzu direkt neben dem Schaltknopf Abschicken zwei Checkboxen. Mittels dieser Checkboxen wird die Verwendung von Verschlüsselung bzw. digitaler Unterschrift für diese -Nachricht aktiviert. Durch diese spezielle Platzierung der Schaltelemente soll der Benutzer direkter auf die Verwendung der Sicherheitsmechanismen fokusiert werden. Die Aktionen selbst hingegen kommen erst vor dem Senden, bzw. beim Ablegen der -Nachricht in einen Ordner zum tragen. Weiter enthält der Composer im oberen Fensterbereich einen Karteireiter. Dieser Karteireiter sammelt übersichtlich Informationen, unterteilt in Adressbereich, Dateianhänge, sowie Optionen zur Kryptographie. Die Optionen zur Kryptographie variieren entsprechend der gewählten Benutzergruppe. Um Transparenz und Flexibilität für den Benutzer zu erhalten, kann aber für jede zu sendende eine manuelle Einstellung vorgenommen werden. So kann vom Benutzer beispielsweise selektiv das anzuwendende Einbettungsverfahren (RFC 2440 oder RFC 3156) 9 Werkzeugleiste: Deren Funktionsumfang kann variieren.

51 KAPITEL 4. IMPLEMENTIERUNG 51 Abbildung 4.13: Composer, digitale Unterschrift erstellen ausgewählt werden. Auch kann durch eine manuelle Schlüsselauswahl die Verwendung bestimmter Schlüssel erzwungen werden. Diese Funktion ist typischerweise für die Benutzergruppe Anfänger deaktiviert. Die Benutzergruppe Anfänger bemerkt von der komplizierten Schlüsselauswahl nichts, falls die entsprechenden Schlüssel bereits im Schlüsselbund enthalten sind. In diesem Fall wird die Auswahl vollautomatisch 10 getroffen. Gemäß Benutzerumfrage wird die Benutzergruppe Experte jedoch immer um eine manuelle Bestätigung der Schlüsselauswahl gebeten. Abbildung 4.13 zeigt ein Bildschirmfoto des Composers beim Erstellen einer digitalen Unterschrift. Die Aufforderung, das Mantra zur Erstellung der digitalen Unterschrift einzugeben, ist hierbei gleichbedeutend mit einer Hinweis- und Warnfunktion. Der zur Leistung der digitalen Unterschrift notwendige Schlüssel wird gemäß des Standardschlüssels gewählt. Insgesamt kann der Composer damit nicht alle Forderungen erfüllen, die an ein Signierwerkzeug bezüglich der Gestaltungskriterien gestellt werden [Joh01]. Folgende Gestaltungsanforderungen sind an ein Signierwerkzeug gestellt [Joh01]: Die Schutzfunktionen der eigenhändigen Unterschrift sind auch durch das Signierwerkzeug zu erfüllen. Das Signierwerkzeug muss orts- und zeitunabhängig verwendet werden können. 10 Senden verschüsselter Nachrichten unter Verwendung von BCC werden versagt.

52 KAPITEL 4. IMPLEMENTIERUNG 52 Die Schutzfunktionen der eigenhändigen Unterschrift sind in Abschnitt bereits kurz vorgestellt worden. Die Schutzfunktionen Authentizität, Fälschungssicherheit, Unwiderrufbarkeit können durch Anwendung der Kryptographie in der Ausprägung der digitalen Unterschrift gewährleistet werden. Hier wird die Annahme vorausgesetzt, dass das verwendete Kryptograpieverfahren perfekt ist (perfect cryptography assumption). Durch technische Realisierung in Form der Mantra-Anfrage kann zudem die Warnfunktion ebenfalls erreicht werden. Die hier vorgestellte technische Realisierung des Signierwerkzeuges durch den Basla-Composer schützt jedoch nicht vor Ausspähen, Weitergeben oder Vergessen des Mantra inklusive des geheimen Schlüssels. Diese wird oft als die PIN-Problematik bezeichnet. Derzeit gibt es eine Reihe von Arbeiten, die sich der Lösung dieser Problematik anzunehmen versuchen. Intensiv wird hierbei die Einbeziehnung von Biometrie verfolgt. Derzeit ist jedoch noch kein allgemeiner Standard definiert, bzw. bekannt. Auch kann hinterfragt werden, ob in Anbetrach von zunehmender Speicherung biometrischer Daten, solche Ansätze langfristig erfolgsversprechend sind. Der Composer lässt somit diese PIN-Problematik ungelöst. Ebenfalls nur eingeschränkt gelöst ist die Forderung nach orts- und zeitunabhängiger Leistung einer digitalen Unterschrift. Durch Verwendung der vorgestellten Lösung für mobilen OpenPGP-Schlüssel (Abschnitt 4.4) ist diese Forderung nur unter der Nebenbedingung der technisch verfügbaren Ausstattung möglich. Um mögliche fehlerhafte Benutzereingaben zu bereinigen, prüft Balsa vor jedem verschlüsseln bzw. digitalen Unterschreiben einer Nachricht die Existenz der jeweils notwendigen Schlüssel. Hierbei finden verfallene, widerrufene oder deaktivierte Schlüssel keine Verwendung. Falls eine manuelle Schlüsselauswahl notwendig, oder vom Benutzer gewünscht wird, präsentiert der Composer eine entsprechend bereinigte Schlüsselliste, analog zu Abbildung Die Assoziation der öffentlichen Schlüssel wird hierbei durch die Benutzer-ID realisiert und nicht durch die Schlüssel-Nummer. Eine erweiterte Ansicht, analog zur Schlüsselverwaltung, bleibt hierbei dem Experten vorbehalten. Abbildung 4.14: Composer, manuelle Schlüsselauswahl (Anfänger)