Entwurf eines Prototypen zur Verteilung von X.509-Zertifikaten mit Python und MySQL unter besonderer Berücksichtigung der Sicherheitsaspekte

Aus Winfwiki

Name des Autors / der Autoren:	Christian Schmidt
Titel der Arbeit:	"Entwurf eines Prototypen zur Verteilung von X.509-Zertifikaten mit Python und MySQL unter besonderer Berücksichtigung der Sicherheitsaspekte"
Hochschule und Studienort:	FOM Essen

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einführung 3.1 Problemstellung 3.2 Zielsetzung 3.3 Aufbau der Arbeit 3.4 Verwendete Werkzeuge 4 Grundlagen 4.1 Symmetrische Verschlüsselung 4.2 Asymmetrische Verschlüsselung 4.3 Digitale Signaturen 4.4 Zertifikate 4.5 Public Key Infrastruktur 5 Entwicklung des Prototypen 5.1 Theoretische Vorüberlegungen 5.1.1 Ziele des Prototypen 5.1.2 Funktionalität des Prototypen 5.1.3 Sicherheitskonzept 5.2 Implementierung 5.2.1 Datenstrukturen 5.2.2 Zertifikatsverwaltung 5.2.3 User-Interface 5.3 Nachüberlegungen und Offene Punkte 6 Fazit 7 Anhang 7.1 Fußnoten 7.2 Literatur- und Quellenverzeichnis 7.3 Betrieb des Prototypen 7.3.1 Download 7.3.2 Installation 7.3.3 Konfiguration 7.3.4 Starten des Servers

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
C	Chiffretext
CA	Certificate Authority
CRL	Certificate Revocation List
M	Message (Nachricht)
PKI	Public Key Infrastruktur

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Vereinfachtes ERM des Prototypen
2	Start-Seite
3	Sicherheitshinweise
4	Benutzerprofil mit Zertfikatslisten
5	Flussdiagramm zur Erstellung eines Zertifikats
6	Registrierung
7	Zertifikat beantragen
8	Privaten Schlüssel herunterladen

3 Einführung

3.1 Problemstellung

Kommunikation über das Internet ist heute für jeden selbstverständlich. Doch dass Internet unterliegt einigen Gefahren, wie z.B. das Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein zusammenfasst:^[1]

"Der Staat kann für die Sicherheit von Daten im Internet nicht garantieren. Daher obliegt es jedem Teilnehmer selbst, für den Schutz seiner Daten zu sorgen. [...] Jeder Bürger kann mit wirksamen Verschlüsselungsverfahren seine Daten nach seinen Anforderungen selbst schützen. Damit sind Kryptoverfahren ein ideales Mittel für den Datenschutz und ein Beispiel für wirksamen Datenschutz durch Technik."

Obwohl notwendige Software bereits seit über 10 Jahren verfügbar ist^[2], hat sich die verschlüsselte Kommunikation im privaten Bereich noch immer nicht durchgesetzt. Dafür sind verschiedene Ursachen denkbar:

1. Die notwendigen Schritte zum Einsatz der kryptographischen Methoden sind schlicht unbekannt.
2. Die Erstellung der dafür notwendigen Zertifikate ist für den durchschnittlichen Privatanwender zu kompliziert^[3].
3. Die Signierung der Zertifikate von "anerkannten", professionellen Stellen ist mit hohen Kosten verbunden^[4].

3.2 Zielsetzung

Ziel dieser Seminararbeit ist es, einen Prototypen zur Verteilung von X.509-Zertifikaten zu erstellen. Diese Zertifikate sind standardisiert und können zu sehr unterschiedlichen Zwecken heranzgezogen werden, z.B. zur Verschlüsselung von Emails, zur Signierung von Emails oder zur Verschlüsselung von VPN-Verbindungen.

Der Prototyp richtet sich an Privatanwender, die mit der Materie weniger vertraut sind, um diese an die zu Grunde liegenden Techniken zu gewöhnen. D.h. der Fokus dieses Prototypen liegt auf Einfachheit und Benutzbarkeit. Im Rahmen dieses Ziels werden bewusst Abstriche, hinsichtlich der Sicherheit des Gesamtsystems, gemacht. Diese werden jedoch explizit ausgewiesen.

3.3 Aufbau der Arbeit

Für das grundsätzliche Verständnis vermittelt Kapitel 4 die notwendigen Grundlagen. Dies geschieht anhand einer kurzen Einführung in die Kryptographie und der im Prototypen verwendeten Elemente daraus.

Kapitel 5 beschäftigt sich mit dem Prototypen selbst. Dabei werden zunächst die theoretischen Vorüberlegungen erläutert. Anschließend erfolgt eine Beschreibung der erfolgten Implementierung. Zuletzt werden noch einmal die offenen Punkte beschrieben.

Eine abschließende Zusammenfassung erfolgt in Kapitel 6.

3.4 Verwendete Werkzeuge

Für die Umsetzung des Prototypen wird auf Python und MySQL zurückgegriffen. Darüber hinaus kommt das Turbogears-Framework in Version 2.0 zum Einsatz. Python/Turbogears bietet einen vollständigen Web-Stack für eine schnelle Umsetzung des Prototypen nach dem Model-View-Controller-Schema. Für die Erzeugung und Verwaltung der X.509-Zertifikate wird darüber hinaus OpenSSL in Version 1.0.0a eingesetzt.

4 Grundlagen

Für die nachfolgenden Erläuterungen sei zunächst folgendes Szenario angenommen:

Alice möchte mit Bob auf sicherem Wege kommunizieren. Die zu übermittelnde Nachricht sei als M (abgeleitet von Message) bezeichnet. Die verschlüsselte Nachricht bezeichnen wir als C (abgeleitet von Chiffretext).

Es existiert jedoch noch eine dritte Person, Oskar, der diese Kommunikation belauschen und ggfs. sogar aktiv verändern kann, um daraus einen Vorteil zu ziehen.

4.1 Symmetrische Verschlüsselung

Bei symmetrischen Algorithmen wird für die Verschlüsselungsfunktion E und Entschlüsselungsfunktion D der gleiche Schlüssel k benötigt. Daraus ergibt sich folgendes Bild:^[5]

Sofern anerkannte und wissenschaftlich geprüfte Algorithmen angewandt werden, beruht die Sicherheit dieses Verfahrens ausschließlich auf der Geheimhaltung des Schlüssels k^[6][7]. Dies setzt jedoch voraus, dass Alice und Bob überhaupt die Möglichkeit haben auf einem sicheren Weg diesen Schlüssel auszutauschen, was nicht immer gegeben ist.

Darüber hinaus ergibt sich das Problem einer Schlüsselverteilung wenn mehrere Personen beteiligt sind, da für ein Netzwerk von n Teilnehmern n*(n-1)/2 Schlüssel erzeugt und verwaltet werden müssen.^[8]

4.2 Asymmetrische Verschlüsselung

Bei asymmetrischen Algorithmen kommen für die Verschlüsselung und Entschlüsselung zwei verschiedene Schlüssel zum Einsatz. Der Schlüssel für die Verschlüsselung wird auch als öffentlicher Schlüssel (hier k_pub) bezeichnet, da dieser öffentlich für jeden verfügbar ist. Nur der Besitzer des privaten Schlüssels (hier k_pr) kann diese Nachricht jedoch wieder entschlüsseln. Daraus ergibt sich folgendes Bild:

Die asymmetrische Kryptographie hat den großen Vorteil, dass für die Kommunikation in einem Netzwerk von n Personen auch nur n Schlüsselpaare erzeugt werden müssen. Die Sicherheits dieser Verfahren beruht prinzipiell nur noch auf der Geheimhaltung der privaten Schlüssel.^[9]

Der öffentliche Schlüssel muss zwar nicht geheimgehalten werden, es muss jedoch sichergestellt sein, dass Alice wirklich den öffentlichen Schlüssel von Bob erhält und verwendet. Wenn es Oskar jedoch gelingt, den öffentlichen Schlüssel von Bob durch seinen eigenen zu Ersetzen, kann dieser die Nachricht zuvor entschlüsseln, verändern und dann erst mit Bobs öffentlichen Schlüssel verschlüsseln. Besonders problematisch an diesem Angriff ist, dass er nicht festgestellt werden kann. Diese Art von Angriff wird als "Man-in-the-middle-attack" bezeichnet. Dies stellt sich schematisch wie folgt dar:^[10]

1. Oskar schiebt Alice den eigenen öffentlichen Schlüssel k_{pub, Oskar} unter.
2. Alice verschlüsselt die Nachricht und schickt sie ab, diese wird jedoch von Oskar abgefangen und entschlüsselt.
   
3. Oskar manipuliert die Nachricht (aus M wird M').
4. Oskar verschlüsselt die Nachricht mit Bobs echtem Schlüssel k_{pub, Bob}, schickt diese an Bob, welcher diese entschlüsselt.
   

Darüber hinaus haben asymmetrische Algorithmen einen weiteren großen Nachteil: ihre Berechnung ist äußert komplex und zeitaufwendig und daher nur eingeschränkt zur Verschlüsselung von größeren Textmengen geeignet. Aus diesem Grunde werden die asymmetrischen Verfahren nicht zur Verschlüsselung der Nachricht selbst, sondern zur Verschlüsselung eines symmetrischen Schlüssels eingesetzt.^[11] Die genauen Spezifika werden in verschiedensten Protokollen definiert und sollen an dieser Stelle nicht weiter ausgeführt werden.

4.3 Digitale Signaturen

Die Probleme bei der Man-in-the-middle-attack verdeutlichen ein grundsätzliches Problem, das bei der Verwendung asymmetrischer Verschlüsselung auftritt. Während bei der symmetrischen Verschlüsselung der Absender bekannt ist, da der verwendete Schlüssel ihn eindeutig authentifiziert, geht bei der Verwendung von öffentlichen Schlüsseln diese Eigenschaft zunächst verloren.

Doch die die asymmetrische Kryptographie bietet für dieses Problem selbst eine Lösung an, welche heute unter "digitale Signaturen" zusammengefasst werden kann. Im vorhergehenden Kapitel wurde für die Verschlüsselung der öffentliche Schlüssel verwendet und für die Entschlüsselung der private Schlüssel. Die asymmetrische Kryptographie kann jedoch in bestimmten Fällen auch andersherum angewendet werden. In diesem Fall spricht man von "reversiblen" Algorithmen^[12]. Dabei ergibt sich folgendes Bild:

Die versendete Nachricht wird mit dem privaten Schlüssel des Absenders verschlüsselt. Mit Hilfe des öffentlichen Schlüssels kann überprüft werden, ob das Chiffrat (= die Signatur) auch dem Klartext entspricht. Ist dies der Fall, so ist davon auszugehen, dass die Nachricht wirklich vom angegebenen Absender stammt. Da die Berechnung der ganzen Nachricht, wie bereits angesprochen, sehr aufwändig ist, wird in der Regel nur ein "Fingerabdruck" der Nachricht signiert. Dieser "Fingerabdruck" wird i.A. durch eine Hashfunktion erzeugt.^[13]

Digitale Signaturen allein sind allerdings genauso anfällig für Man-in-the-Middle-Angriffe. Eine Lösung für dieses Problem bieten Zertifikate, die im folgenden Abschnitt vorgestellt werden.

4.4 Zertifikate

Ein Zertifikat dient dazu, einen beliebigen öffentlichen Schlüssel mit der Identität einer bestimmten Person oder Organisation fest zu verknüpfen. Die grundlegende Fragestellung dabei ist, wer diese Information bestätigt. In der Praxis haben sich dazu zwei verschiedene Modelle entwickelt:

1. Der Web of Trust ist ein Modell, in dem sich die Benutzer gegenseitig oder über gemeinsame Bekannte anerkennen indem sie ihre Schlüssel gegenseitig signieren. Der Web of Trust wird vor allem im Umgang mit dem OpenPGP-Standard verwendet.^[14]
2. Die Public Key Infrastruktur (PKI) ist ein Modell, indem es eine vertrauenswürdige, neutrale Instanz gibt, die eindeutig authentifizierte Zertifikate signiert. Diese Instanz wird "Certificate Authority" (CA) genannt.^[15] Eine Implementierung dafür bietet der X.509-Standard.

4.5 Public Key Infrastruktur

Vereinfacht ausgedrückt ist eine PKI zuständig für die Verteilung und Speicherung der öffentlichen und privaten Schlüssel.^[16] Diese Definition erfasst die Bedeutung der PKI jedoch nicht vollständig. Genauer definiert, bezeichnet PKI ein komplexes Managementsystem zur Gewährleistung der Integrität und Vertrauenswürdigkeit der damit verbunden Sicherheitsanwendungen. Dazu zählen die

• Erzeugung,
• Zuordnung,
• Ausgabe,
• Beglaubigung,
• Verteilung und
• Sperrung

von Schlüsseln bzw. Zertifikaten, welche die Kommunikation absichern sollen.^[17]

5 Entwicklung des Prototypen

5.1 Theoretische Vorüberlegungen

5.1.1 Ziele des Prototypen

Das Ziel der Prototypen ist die Bereitstellung einer Public-Key-Infrastruktur im Rahmen einer privaten, nicht-gewerblichen Nutzung. Dazu soll eine webbasierte Certificate Authority entwickelt werden. Die CA wendet sich gleichermaßen an Nutzer die mit der Materie bereits betraut sind, wie an Nutzer, die mit PKI noch keine Berührungspunkte hatten.

Aufgrund der anvisierten Zielgruppe muss die CA möglichst einfach gehalten und äußert benutzerfreundlich sein. Um dies zu erreichen, bietet es sich an, dem Nutzer möglichst alle Schritte abzunehmen, die auch von der CA selbst erledigt werden können. Dieses Ziel steht in Konflikt mit den Sicherheitsanforderungen, die eine CA prinzipiell auszeichnet. Dieser Zielkonflikt wird im Rahmen dieser Arbeit näher betrachtet und die daraus resultierenden Entscheidungen dokumentiert.

5.1.2 Funktionalität des Prototypen

Für den Betrieb einer CA definiert Buchmann folgende Funktionalität:^[18]

1. Registrierung
2. Schlüsselerzeugung
3. Zertifizierung
4. Archivierung
5. Transfer der Schlüssel in die persönliche Sicherheitsumgebung
6. Verzeichnisdienst
7. Schlüssel-Update
8. Rückruf von Zertifikaten
9. Zugriff auf ungültige Schlüssel
10. Zertifikatsketten

Für die Registrierung schlägt Buchmann eine persönliche Identifikation mit einem amtlichen Dokument vor. Dies ist in einem automatisierten System allerdings nicht praktikabel. Darüber hinaus soll das hier entworfene System auch Nutzern, die sich ausschließlich unter einem Pseudonym anmelden, die volle Funktionalität bieten. Daher wird der Prototyp nur eine einfache Registrierung per Web-Formular erfordern.

Die Schlüsselerzeugung kann auf zwei Wegen erfolgen: entweder durch die CA oder durch den Anwender selbst. Da der Fokus des hier vorgestellten System auf Einfachheit und Benutzbarkeit liegt, kommt nur eine Erzeugung bei der CA selbst in Frage. Dies ist jedoch mit zusätzlichen Sicherheitsrisiken verbunden.

Mit Zertifizierung ist der Vorgang gemeint, bei dem der generierte öffentliche Schlüssel mit den Informationen über den Anwender in ein Zertifikat zusammengeführt wird. Der Prototyp kann beide Schritte sofort hintereinander durchführen. Das erstellte Zertifikat entspricht dann dem X.509 Standard.

Die Aufbewahrungsfrist für Zertifikate hängt vom Verwendungszweck der Zertifikate ab. Aus Gründen der Einfachheit archiviert der Prototyp schlicht alle jemals erzeugten Zertifikate. Da diese vergleichsweise wenig Speicherplatz benötigen (unter 5KB), führt dies nicht zu nennenswerten Problemen.

Der Transfer der Schlüssel in die persönliche Sicherheitsumgebung ist eine heikle Angelegenheit. Hierbei handelt es sich um einen Single Point of Failure, der bei falscher Handhabung die Sicherheit der gesamte PKI untergraben kann. Daher unterliegt dieser Punkt einer näheren Betrachtung (vgl. nachfolgendes Kapitel).

Unter einem Verzeichnisdienst versteht Buchmann eine Auflistung aller registrierten Anwender und deren Zertifikate. Dieser Punkt entfällt im Prototypen aufgrund von Sicherheitsaspekten (vgl. nachfolgendes Kapitel).

Schlüssel-Update bedeutet nach Buchmann, dass es möglich sein muss ablaufende Schlüssel durch neue zu ersetzen. Da der Prototyp ermöglich beliebig viele Zertifikate zu erzeugen, stellt dies keine besondere Anforderung dar.

Im Fall des Verlusts oder der Komprommitierung eines privaten Schlüssels, muss der zugehörige öffentliche Schlüssel jederzeit widerrufbar sein. Nur so kann sichergestellt werden, dass er von keinem Beteiligten mehr akzeptiert wird. Eine Aufstellung aller widerrufenen Zertifikate wird als "Certificate Revocation List" bezeichnet. Diese wird im Prototypen implementiert.

Gemäß Buchmann sollte ein Zugriff auf ungültige Schlüssel zu Nachweiszwecken auch nachträglich immer möglich sein. Der Prototyp soll grundsätzlich alle öffentlichen Zertifikate ausweisen und dabei in die Zustände "active", "revoked" und "expired" unterscheiden.

Zertifikatsketten dienen laut Buchmann dazu ein Benutzer-Zertifikat zu validieren, welches von einer anderen CA stammt. Dazu muss die eigene CA das Zertifikat der anderen CA im Bestand haben. Dies wird im Prototyp aus Gründen der Einfachheit noch nicht berücksichtigt.

5.1.3 Sicherheitskonzept

Vor der Aufstellung eines Sicherheitskonzeptes stellt sich zunächst die Frage, auf welche Weise die eine PKI prinzipiell gefährdet werden kann und welche Folgen sich daraus ergeben können. Gemäß den Analysen des BSI ergeben sich für Kryptosysteme folgende Gefährdungspotentiale:^[19]

• Organisatorische Mängel, durch
  • Fehlende oder unzureichende Regelungen, oder mangelnde Kenntnis darüber
  • Unzureichende Kontrolle der Sicherheitsmaßnahmen
  • Unzureichendes Schlüsselmanagement bei Verschlüsselung
• Menschliche Fehlhandlungen, resultierend aus
  • Vertraulichkeits- oder Integritätsverlust von Daten durch Fehlverhalten
  • Verstößen gegen rechtliche Rahmenbedingungen beim Einsatz von kryptographischen Verfahren
  • Fehlbedienung von Kryptomodulen
• Technisches Versagen, bedingt durch
  • Software-Schwachstellen oder -Fehler
  • Schlechte oder fehlende Authentikation
  • Ausfall eines Kryptomoduls
  • Unsichere kryptographische Algorithmen
  • Fehler in verschlüsselten Daten
• Vorsätzliche Handlungen, wie z.B.
  • Vertraulichkeitsverlust schützenswerter Informationen
  • Unautorisierte Benutzung eines Kryptomoduls
  • Manipulation eines Kryptomoduls
  • Kompromittierung kryptographischer Schlüssel
  • Gefälschte Zertifikate
  • Integritätsverlust schützenswerter Informationen

Für die nachfolgenden Betrachtungen wird davon ausgegangen, dass der Prototyp auf einem an sich sicheren Server zum Einsatz kommt, welcher keinerlei eigene Angriffspunkte bietet, da die Absicherung eines Servers zu komplex ist, um hier dargestellt zu werden.

Für die geplante Public-Key-Infrastruktur gibt es drei Punkte, an denen sich die vorgestellte Gefährdungspotentiale auswirken können:

1. In der web-basierten CA (= dem Prototypen)
2. Beim Anwender
3. In der Kommunikation zwischen CA und Anwender

Ein grundsätzliches organisatorisches Problem beim Betrieb einer Certificate Authority ist die Geheimhaltung des privaten Schlüssels der CA. Es muss prinzipiell sichergestellt sein, dass unautorisierte Zugriffe auf den Schlüssel nicht möglich sind.^[20] Unter Zugriff auf den privaten Schlüssel wäre es beispielsweise möglich, ein selbst erzeugtes Zertifikat auf den Namen von jemand anders zu signieren. Damit wäre wieder ein Man-in-the-Middle-Angriff möglich. Für das vorgesehene Konzept muss der private Schlüssel allerdings jederzeit verfügbar sein, da die Zertifikate automatisiert signiert werden sollen. Das bedeutet, dass der private Schlüssel permanent und unverschlüsselt auf dem Server vorliegen muss. Es gilt also durch geeignete Konfiguration des Servers sicherzustellen, dass nur ein berechtigte Personenkreis (= die Betreiber der CA bzw. deren Bevollmächtigte) Zugriff auf den Schlüssel haben.

Ein weiteres organisatorisches Problem betrifft die privaten Schlüssel der Anwender. So empfiehlt die Literatur den Einsatz von Chipkarten mit kryptographischen Funktionen, da hier die Erzeugung, Verwendung und Zerstörung des Schlüssels gezielt gesteuert werden kann.^[21] Eine Chipkarte kommt bei einer webbasierten Lösung aufgrund der Kosten und des Aufwands für den physischen Transport nicht in Frage. Damit verbleiben reine Dateien als Speichermedium. Diese gilt es jedoch auch zu schützen. Eine Lösung für dieses Problem stellt das PKCS#12-Dateiformat dar, welches privaten Schlüssel und Zertifikat passwortgeschützt speichern kann.^[22] Da dieses Format von gängigen Systemen akzeptiert wird (z.B. Mozilla-Produkte, Windows XP / Vista / 7), steht einem Einsatz nichts im Weg.

Neben der Art der Speicherung ist jedoch auch grundsätzlich der Ort der Speicherung zu klären. Hier gibt es zwei Möglichkeiten. Die erste Möglichkeit besteht darin, dass die CA den privaten Schlüssel, auch nachdem er dem neuen Besitzer ausgehändigt wurde, noch im eigenen Datenbestand vorhält. Der Zweck besteht darin, dass im Falle einer versehentlichen Löschung oder Zerstörung des Schlüssels durch den Besitzer eine Sicherheitskopie existiert, mit der Daten auch nachträglich noch entschlüsselt werden können.^[23] Die privaten Schlüssel können jedoch nicht an einem physisch getrennten Ort auf Chipkarten gelagert werden können (s.o.), daher würden alle privaten Schlüssel auf dem Server der CA verbleiben. Da damit durch einen einzigen erfolgreichen Angriff alle privaten Schlüssel auf einmal erspäht werden könnten, ist das Risiko für diese Variante deutlich zu groß. Aus diesem Grund werden die privaten Schlüssel nach der Übertragung sofort vom Server gelöscht.

Menschliches Fehlverhalten ist durch den angestrebten Grad von Automatisierung zumindest auf Seiten der CA minimiert. Fehlerpotentiale liegen hier aber immernoch in den Bereichen Installation, Konfiguration und Wartung. Auf der Anwenderseite gibt es jedoch mehrere Fehlerquellen: Da sind zum einen mangelhafte bzw. unsicher gewählte Passwörter. Dies kann durch klare Passwortregelungen gemindert, aber nicht ausgeschaltet werden. Weiterhin problematisch sind Fehler im Umgang mit den Zertifikaten selbst (z.B. Verwendung eines Zertifikats für Verschlüsselung und Signatur). Hierfür gibt es, außer durch Aufklärung im Vorfeld, keinen wirksamen Schutz. Auch gibt es keinen Weg zu verhindern, dass der Anwender seine Schlüssel nicht entsprechend sichert (Sicherheitskopien, Zugangsbeschränkung, etc.). Ab dem Transport des privaten Schlüssels zum Benutzer, ist dieser ausschließlich für dessen Sicherheit verantwortlich.

Technisches Versagen ist vor allem ein Problem auf der Serverseite. Software-Schwachstellen oder -Fehler sind im Vorfeld kaum zu entdecken und können nur durch einen kontinuierlichen Kontrollprozess vermieden werden. Der Prototyp wird ausschließlich OpenSSL als Kryptomodul verwenden. Ein Ausfall würde vorübergehend dazu führen, dass keine neuen Zertifikate erzeugt werden können. Er würde jedoch nicht die Integrität der gesamten CA verletzen. Schwieriger wird es, wenn sich einer der verwendeten kryptographischen Algorithmen als unsicher erweist. Hier wäre sofort eine Erneuerung aller Zertifikate erforderlich. Dies ist jedoch ein prinzipielles Problem beim Betrieb von PKIs, für dass es keine eindeutige Lösung gibt.

Fehler während der Kommunikation zwischen Server und Anwender könnten dazu führen, dass die übertragenen Daten verloren gehen oder zerstört werden. Dies würde jedoch nicht zu einer Gefährdung der Sicherheit führen. Geht z.B. der private Schlüssel bei der Übertragung verloren, kann er nicht noch einmal versandt werden, da er nach dem Transport sofort gelöscht wird auf Seiten des Servers. Dies wäre zwar ärgerlich, kann jedoch durch das Anfordern eines neuen Schlüssels schnell behoben werden.

Technisches Versagen auf Seiten der Nutzer liegt prinzipiell außerhalb der Reichweite der CA. Ein Hardware-Defekt kann zu einem vollständigen, unwiderruflichen Verlust aller privaten Schlüssel führen, wenn keine entsprechenden Sicherheitskopien gemacht wurden. Dafür ist der Anwender jedoch selbst verantwortlich.

Vorsätzliche Handlungen stellen das größte Bedrohungspotential dar, da diese i.d.R. darauf abzielen die Sicherheit der gesamtem PKI zu zerstören. Ein solches Szenario liegt vor, wenn ein Angreifer unbeschränkten Zugriff auf den Server der CA erlangt. Wenn der Angreifer nur passiv bleibt (d.h. aktiv keine Dateien verändert), kann er alle privaten Schlüssel abhören, die in der Zeit erzeugt werden, in der er Zugriff hat. Problematisch bei passiven Angriffen ist, dass diese nur schwer zu bemerken sind. Ein aktiver Angreifer könnte dagegen seine eigenen Zertifikate erzeugen, diese auf dem Server signieren lassen und anschließend die Zertifikate anderer Benutzer durch seine eigenen ersetzen. Dies könnte jedoch auffallen, wenn ein Empfänger seine eigenen Emails nicht mehr entschlüsseln kann, oder auffällt, dass eine alte Signatur nicht mehr validiert werden kann.

Neben reinen Angriffen auf die Server der CA sind prinzipiell auch andere Angriffe denkbar. Ein möglicher Angriff besteht darin, sich gezielt mit einer falschen Identität zu registrieren. Diese Identität kann noch gar nicht registriert sein, oder sie weicht minimal von einer bestehenden ab. In beiden Fällen ist das Ziel dieses Angriffs, dass jemand auf die Einträge in der Nutzerdatenbank vertraut und das Zertifikat als echt ansieht. Um dieses Problem zu unterbinden wird der Prototyp keinen Verzeichnisdienst anbieten, in dem die jeweilige Identität herausgesucht werden kann. Stattdessen erhalten alle Nutzer einen alphanumerischern Code, der sie eindeutig identifizierbar macht. Dieser Code kann relativ schnell ausgetauscht werden (z.B. am Telefon, über eine Visitenkarte, o.Ä.).

Ein weiterer Angriff, der an die bereits vorgestellte Man-in-the-Middle-Attacke erinnert, ist das sogenannte "DNS Hijacking", bei dem der Benutzer unbewusst auf einen anderen Server umgeleitet wird als eigentlich gewollt.^[24] Dort wird ihm eine exakte Kopie der CA vorgespielt, die jedoch gefältschte Zertifikate beeinhaltet. Ein Schutz vor diesem Angriff läge darin, dass Verbindung ausschließlich verschlüsselt zugelassen werden und das Zertifikat die Echtheit der Domain bestätigt (es muss also ein Zertifikate-Anbieter zum Einsatz kommen, der in den meisten Browsern vorinstalliert ist). Die Verschlüsselung muss aus Gründen des Passwortschutzes und der transportierten privaten Schlüssel ohnehin erfolgen. Der Prototyp wird jedoch aus Kostengründen nicht mit einem solchen Zertifikat ausgestattet sein.

5.2 Implementierung

5.2.1 Datenstrukturen

Durch die Verwendung des Turbogears-Framework sind Teile der Datenbankstruktur für die Benutzer-Verwaltung bereits vorgegeben. Im Prototypen kommt jedoch kein ausgefeilte Berechtigungskonzept zum Einsatz. Abb. 1 zeigt daher ein auf das wesentliche reduzierte Entity-Relationship-Modell der Datenbank.

Es gibt nur zwei relevante Entitäten: den Benutzer und die Zertifikate. Ein Benutzer kann dabei beliebig viele Zertifikate haben, wobei jedes Zertifikat nur zu einem Benutzer gehört.

Der Benutzer hat aus Sicherheitsgründen einen vom Anzeigenamen abweichenden Benutzernamen (verwendet für den Login). Sowohl Benutzername, als auch Anzeigename und Emailadresse müssen darüber hinaus einmalig sein. Das Passwort wird in gehashter Form gespeichert.

Das Zertfikat besteht aus verschiedenen Attributen, die sich logisch voneinander trennen lassen:

1. Die Verwaltungsdaten, die die Gültigkeit und den Status überwachen.
2. Die "Stammdaten" des Zertifikats, also alle Daten, die in das öffentliche Zertifikat eingespeichert werden um es eindeutig einem Benutzer zuzuordnen.
3. Die binären Daten. Das Feld Cert enthält das öffentliche Zertifikat, das Feld PKCS12 speichert vorübergehend den privaten und den öffentlichen Schlüssel im binären PKCS#12 Format.

5.2.2 Zertifikatsverwaltung

Für die Zertifikatsverwaltung kommt OpenSSL zum Einsatz. Für die jeweiligen Aktionen wird eine eigene Instanz innerhalb des Servers geöffnet und die Parameter wie auf der Kommandozeile übergeben oder zum Verwendungszeitpunkt in einer dynamisch erzeugten Konfigurationsdatei abgelegt.

Zum Betrieb der CA ist vorab das Erzeugen eines privaten Schlüssel notwendig und die Erstellung eine selbstsignierten Zertifikats (oder alternativ das Beschaffung eines Zertifikats von einer vertrauenswürdigen professionellen Organisation).

Zum Erzeugen der Benutzerzertifikate werden dann jeweils die folgenden Schritte ausgeführt:

1. Speichern der Zertifikatsdaten in einer Konfigurationsdatei
2. Erzeugen des privaten Schlüssels und einer Zertifikatsanfrage (OpenSSL ermöglicht beides in einem Schritt)
3. Signierung der Zertifikatsanfrage mit dem privaten Schlüssel der CA (dabei führt OpenSSL nebenbei gleichzeitig eine Liste aller jemals ausgestellten Zertfikate in einer .txt-Datei)
4. Zusammenführen von privatem Schlüssel und öffentlichem Zertifikat ins PKCS#12-Format
5. Einlesen des öffentlichen Zertifikats und der PKCS#12-Datei in die Datenbank
6. Löschen aller verbliebenen Dateien (ausgenommen eine Kopie des öffentlichen Schlüssels in einem separaten Verzeichnis)

Beim Widerrufen eines Zertifikates ist ebenfalls OpenSSL im Einsatz, damit dieses die intern geführte Zertifikatsliste aktualisiert. Diese ist notwendig um die signierte CRL zu erstellen. Diese weist zwar eine Gültigkeitsdauer von 7 Tagen aus (oder abweichend, wenn die Konfiguration geändert wurde), wird jedoch bei jedem Abruf neu erzeugt.

5.2.3 User-Interface

Beim Betreten der Webseite des Prototypen soll der Besucher zunächst einmal mit dem Sinn der Seite vertaut gemacht werden. Darüber hinaus wird auch an dieser zentralen Stelle noch einmal ein Fingerabdruck (Hash) des öffentlichen Zertifikats der CA bereitgestellt (Abb. 2). Gleichzeitig wird jedoch auch auf die allgemeinen Sicherheitshinweise verwiesen, welche in Abb. 3 zur Geltung kommen.

Zu jeder Zeit und an zentraler Stelle sichtbar sind darüber hinaus Links zu Benutzerprofilen (Abb. 4), in denen die öffentlichen Zertifikate eines Benutzer bereitstehen, sowie zu den Dateien des öffentlichen Zertifikats und der aktuellen CRL.

Abb. 2 : Start-Seite

Abb. 3 : Sicherheitshinweise

Abb. 4 : Benutzerprofil mit Zertfikatslisten

Entscheidet sich ein Besucher dazu, selber ein Zertifikat zu erzeugen, so muss er die Schritte des Flussdiagramms in Abb. 5 befolgen. Dabei erfordern nur die rot markierten Vorgängen tatsächlich eine Interaktion vom Benutzer. Der Rest läuft automatisiert im Hintergrund. Die dabei verwendeten Formulare bzw. Seiten zeigen die Abbildungen 6-8.

Abb. 6 : Registrierung

Abb. 7 : Zertifikat beantragen

Abb. 8 : Privaten Schlüssel herunterladen

5.3 Nachüberlegungen und Offene Punkte

Sowohl die theoretischen Vorüberlegungen als auch die praktische Anwendung haben noch einige offene Punkte aufgezeigt, die es aus Gründen der Komplexität oder des Aufwandes nicht in den Prototypen geschafft haben.

Insbesondere die Absicherung des Servers im laufenden Betrieb ist ein zwingend erforderlicher Schritt, um die Sicherheit des privaten Schlüssels zu gewährleisten. Eine detailliertere Ausführung der Maßnahmen würde jedoch zu stark am Thema dieser Arbeit vorbeigehen.

Neben der Absicherung des Servers ist eine Absicherung der Kommunikationsverbindung des Prototypen mit dem TLS-Protokoll dringlichst empfohlen. Dies ist jedoch eine reine Konfigurationsfrage. Da der spätere Betrieb der CA als Modul eines Webserver (wie z.B. den Apache HTTP Server) empfehlenswert ist, wurde im Prototypen darauf verzichtet.

Bei der Benutzerregistrierung sind noch einige Verbesserungspotentiale vorhanden. Da wäre zum einen die obligatorische Validierung der Email-Addresse durch das Versenden eines Aktivierungslinks. Darüber hinaus wäre es denkbar, neue Benutzer nur durch Bestätigung vorhandener Benutzer oder durch Benutzer mit erweiterten Berechtigungen freizuschalten. Damit wäre auch ein Betrieb des Prototypen in einem klar umrissenen privaten Umfeld möglich.

Ein weiterer offener Punkt ist die Einschränkung der Zertifikatsverwendung durch den Einsatz von X.509 Extensions. Da diese Funktionalität ebenfalls zu deutlich höherer Komplexität bei der Erstellung der Zertifikate geführt hätte, ist diese nicht im Prototypen realisiert.

Ein letzter Punkt wäre die Internationalisierung durch die Verwendung der vom TurboGears unterstützten Übersetzungswerkzeuge. Da dieser Punkt jedoch keinen zusätzlichen Nutzen zur eigentlichen Problemstellung bringt, ist nur die Sprache Englisch verfügbar.

6 Fazit

Nach einer Einführung in die Grundlagen der Kryptographie wurden zunächst theoretische Vorüberlegungen zum Prototypen gemacht. Dabei wurden zunächst die Ziele des Prototypen festgehalten und anschließend die dafür erforderliche Funktionalität geklärt. Diese besteht aus den folgenden Punkten:

• Registrierung
• Zertifikatserzeugung
• Download des Zertifikats mit dem privaten Schlüssel (einmalig)
• Widerruf von Schlüsseln
• Abruf von öffentlichen Zertifikaten (inkl. Unterscheidung nach dem Gültigkeitsstatus)
• Generierung und Download der CRL

Die anschließenden Sicherheitsüberlegungen haben ergeben, dass der hier genannte Prototyp nicht mit kommerziell erstellten Zertfikaten vergleichbar ist. Tatsache ist jedoch auch, dass ein erhöhte Grad an Sicherheit immer auch mit entsprechendem Mehraufwand verbunden ist. Der Prototyp hatte aber auch nicht als Zielsetzung, kommerzielle Systeme zu verdrängen, sondern langsam und einfach an die Thematik heranzuführen. Dies geschieht zum einen, indem dem Benutzer möglichst viele Schritte abgenommen werden und zum anderen, indem dem Benutzer möglichst viel Hintergrundwissen bereitgestellt wird. Beide Punkte erfüllt der Prototyp.

Dabei konnten die notwendigen Schritte zum Erzeugen des persönlichen Schlüsselpaars auf ein Minimum reduziert werden. Dabei reichen die Schritte Registrieren, Zertifikat beantragen und privaten Schlüssel herunterladen bereits aus.

Darüber hinaus wurde festgestellt, dass die Sicherheit des Prototypen und der Kommunikation zwischen Prototyp und Anwender durch entsprechende Maßnahmen positiv beeinflusst werden kann, nicht jedoch die Sicherheit im Umfeld des Anwenders.

Die offenen Punkte zeigen, dass noch Optimierungspotential am Prototypen vorhanden ist. Dieses sollte vor einer produktiven Verwendung des Prototypen umgesetzt werden.

7 Anhang

7.1 Fußnoten

1. ↑ Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein, Warum Verschlüsselung?, 2010, https://www.datenschutzzentrum.de/material/themen/pgp/index.htm (Abruf vom 05.07.2010)
2. ↑ OpenSSL existiert beispielswiese seit 1999, vgl. http://www.openssl.org/
3. ↑ Als Beispiel sei hier die Dokumentation von OpenSSL angeführt (siehe http://www.openssl.org/docs)
4. ↑ Zum Stand 05.07.2010 kostet das günstigste Zertifikat von GlobalSign 179€ (siehe http://eu.globalsign.com/ssl/index.html)
5. ↑ Vgl. auch Buchmann 2004, S.59f
6. ↑ Vgl. Schneier 1996, S.33
7. ↑ Es gibt zwar noch eine Reihe weiterer Angriffe auf symmetrische Algorithmen, diese sind jedoch von der spezifischen Anwendung her unterschiedlich und sollen an dieser Stelle nicht weiter erörtert werden.
8. ↑ Vgl. Schneier 1996, S.34
9. ↑ Vgl. Schneier 1996, S.37ff
10. ↑ Vgl. Schneier 1996, S.58f
11. ↑ Vgl. Schneier 1996, S.37ff
12. ↑ Vgl. Menezes et al. 1997, S.28
13. ↑ Vgl. Bitzer, Brisch 1999, S.21ff
14. ↑ Vgl. Beutelspacher et al. 2005, S.288
15. ↑ Vgl. Buchmann 2004, S.241
16. ↑ Vgl. Buchmann 2004, S.239
17. ↑ Vgl. Beutelspacher et al. 2005, S.212f
18. ↑ Vgl. Buchmann 2004, S.241-245
19. ↑ Vgl. Bundesamt für Sicherheit in der Informationstechnik (BSI), IT-Grundschutz-Kataloge, 2010, https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html (Abruf vom 09.07.2010)
20. ↑ Vgl. Eckert 2008, S.381
21. ↑ Vgl. Beutelspacher et al. 2005, S.212ff
22. ↑ Die Spezifikation findet sich unter ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf
23. ↑ Vgl. Bitzer, Brisch 1999, S.34
24. ↑ Vgl. Young, Aitel 2004, S.335ff

7.2 Literatur- und Quellenverzeichnis

Literaturquellen

• Beutelspacher, Albrecht; Neumann, Heike B.; Schwarzpaul, Thomas (2005): Kryptografie in Theorie und Praxis. Mathematische Grundlagen für elektronisches Geld, Internetsicherheit und Mobilfunk. 1. Aufl. Wiesbaden: Vieweg
• Bitzer, Frank; Brisch, Klaus M. (1999): Digitale Signatur. Grundlagen, Funktion und Einsatz. Berlin: Springer
• Buchmann, Johannes (2004): Einführung in die Kryptographie. 3., erw. Aufl. Berlin: Springer
• Eckert, Claudia (2008): IT-Sicherheit. Konzepte - Verfahren - Protokolle. München: Oldenbourg
• Menezes, Alfred J.; van Oorschot, Paul C.; Vanstone, Scott A. (1997): Handbook of applied cryptography. Boca Raton: CRC Press
• Schneier, Bruce; Karsunke, Katja (1996): Angewandte Kryptographie. Protokolle, Algorithmen und Sourcecode in C. Bonn: Addison-Wesley
• Young, Susan Elizabeth; Aitel, Dave (2004): The hacker's handbook. The strategy behind breaking into and defending networks. Boca Raton: Auerbach

Internetquellen

• Bundesamt für Sicherheit in der Informationstechnik (BSI): IT-Grundschutz-Kataloge (2010) https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html (Abruf vom 09.07.2010)
• Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein: Warum Verschlüsselung? (2010) https://www.datenschutzzentrum.de/material/themen/pgp/index.htm (Abruf vom 05.07.2010)

7.3 Betrieb des Prototypen

7.3.1 Download

Der Prototyp steht hier in zwei Versionen zum Download zur Verfügung.

1. Nur der Prototyp (Prototyp.zip)
2. Eine fertige virtuelle Umgebung für Windows-System größer als Windows XP (VirtualEnvironment.7z, zum Entpacken wird das Programm 7-zip benötigt.)

7.3.2 Installation

Der Prototyp wurde unter Windows XP in einer virtuellen Python-Umgebung entwickelt. Für einen Test des Prototypen unter Windows bietet sich daher der Download der virtuelle Umgebung an.

TurboGears ist jedoch grundsätzlich ein betriebssystemunabhängiges Framework. Zum Testen auf einer anderen Plattform als Windows, muss TurboGears von Hand auf dem System installiert werden. Eine Beschreibung zum einrichten von TurboGears in einer virtuellen Umgebung befindet sich hier. Anschließend muss der Code des Prototypen in einem eigenen Verzeichnis auf der gleichen ebene wie "Libs" und "Scripts" entpackt werden.

7.3.3 Konfiguration

Die Datei "development.ini" stellt die Konfigurationsdatei dar. Es können beliebig viele erzeugt werden, welche dann beim Start des Servers angegeben wird.

Auf jeden Fall sollte dort der Parameter "openSSL_path" angepasst werden. Dieser muss auf den Pfad der auf dem System hinterlegten ausführbaren OpenSSL-Anwendung hinterlegt sein (unter Windows: openssl.exe).

Dies mitgelieferte Konfigurationsdatei verwendet der Einfachheit halber nicht MySQL sondern SQLite3 und speichert die Datenbank in der Datei "webcert\devdata.db". Um MySQL einzusetzen muss der Parameter "sqlalchemy.url" entsprechend angepasst werden:

 sqlalchemy.url = mysql://username:password@host:port/database

Wenn Sie eine abweichende Datenbank eingestellt haben, muss diese zunächst initialisiert werden. Im folgenden Beispiel befindet sich die virtuelle Umgebung unter "D:\tg2env" und der Prototyp im Unterordner "webcert".

 D:\tg2env> Scripts\activate.bat
 <tg2env> D:\tg2env> cd Webcert
 <tg2env> D:\tg2env\Webcert> paster setup-app development.ini

Darüber hinaus lasssen sich in der Konfigurationsdatei weitere Einstellungen treffen, u.a. der verwendete Host, Port.

Die mitgeliferte Datei bringt schon ein Schlüsselpaar für die CA mit. Für eine öffentliche Verwendung muss dieses natürlich geändert werden, ebenso der Fingerprint des Zertifikats, welches auf der Start-Seite angezeigt wird. Dieses findet sich unter "WebCert\webcert\templates\index.html".

7.3.4 Starten des Servers

Im folgenden Beispiel befindet sich die virtuelle Umgebung unter "D:\tg2env" und der Prototyp im Unterordner "webcert".

 D:\tg2env> Scripts\activate.bat
 <tg2env> D:\tg2env> cd Webcert
 <tg2env> D:\tg2env\Webcert> paster serve development.ini