Simple Certificate Enrollment Protocol f¼r Linux strongSwan

Studienarbeit

Simple Certificate EnrollmentProtocol für Linux strongSwan

Jan HutterMartin Willi

Hochschule für Technik Rapperswil

Semester: SS 05Betreuer: Prof. Dr. Andreas SteffenDatum: 30. Juni 2005

Studienarbeit „SCEP für Linux strongSwan“ Inhaltsverzeichnis

Inhaltsverzeichnis1 Aufgabenstellung..................................................................................................... 6

1.1 Einführung ......................................................................................................... 61.2 Aufgabenstellung ................................................................................................ 61.3 Links ................................................................................................................ 6

2 Abstract................................................................................................................... 73 Management Summary.............................................................................................8

3.1 Ausgangslage..................................................................................................... 83.2 Vorgehen........................................................................................................... 93.3 Ergebnisse........................................................................................................ 103.4 Ausblick........................................................................................................... 10

4 Einleitung...............................................................................................................114.1 Problemstellung................................................................................................. 114.2 Gliederung des Dokumentes................................................................................ 12

5 Technologien..........................................................................................................135.1 Einleitung......................................................................................................... 135.2 ASN.1.............................................................................................................. 13

5.2.1 Syntax....................................................................................................... 145.2.2 DER-Kodierung........................................................................................... 14

5.2.2.1 Datentypen.......................................................................................... 145.2.2.2 OIDs................................................................................................... 155.2.2.3 Beispiel............................................................................................... 16

5.3 PKCS#1........................................................................................................... 175.3.1 Dateiformat................................................................................................ 17

5.4 PKCS#10.......................................................................................................... 185.5 PKCS#7........................................................................................................... 19

5.5.1 Allgemeiner Aufbau..................................................................................... 195.5.2 Datentyp signedData................................................................................... 20

5.5.2.1 Erstellung der Signatur.......................................................................... 235.5.3 Datentyp envelopedData.............................................................................. 24

5.6 Simple Certificate Enrollment Protocol.................................................................. 265.6.1 Manual vs. automatic Mode.......................................................................... 275.6.2 CA-Zertifikat beziehen................................................................................. 285.6.3 Schlüsselpaar generieren.............................................................................. 295.6.4 Zertifikats-Request erstellen......................................................................... 295.6.5 Request verschlüsseln und signieren.............................................................. 305.6.6 Request absetzen........................................................................................ 315.6.7 Request überprüfen und entschlüsseln........................................................... 315.6.8 Response erstellen...................................................................................... 315.6.9 Response verschlüsseln und signieren............................................................ 32

5.6.9.1 Verschlüsseln der Daten........................................................................ 335.6.10 Beispiel-Message....................................................................................... 34

6 Software-Design.....................................................................................................366.1 Prinzipieller Aufbau............................................................................................ 366.2 Module............................................................................................................. 37

6.2.1 asn1.......................................................................................................... 386.2.2 crypto........................................................................................................ 39

6.2.2.1 crypto_rsa_encrypt............................................................................... 396.2.2.2 crypto_rsa_decrypt............................................................................... 396.2.2.3 crypto_build_md5_rsa_signature............................................................ 406.2.2.4 crypto_verify_md5_rsa_signature........................................................... 40

6.2.3 http........................................................................................................... 416.2.3.1 http_do_scep_request........................................................................... 41

6.2.4 pkcs1........................................................................................................ 43

Gedruckt am: 30.06.2005 Jan HutterSeite 2 von 114 Martin Willi


6.2.4.1 pkcs1_build......................................................................................... 436.2.4.2 pkcs1_get_rsa_key............................................................................... 43

6.2.5 pkcs10....................................................................................................... 446.2.5.1 pkcs10_build....................................................................................... 446.2.5.2 pkcs10_build_chunk............................................................................. 456.2.5.3 pkcs10_write_to_file............................................................................. 46

6.2.6 pkcs7........................................................................................................ 476.2.6.1 pkcs7_encrypt_data.............................................................................. 476.2.6.2 pkcs7_sign.......................................................................................... 486.2.6.3 pkcs7_parse_enveloped_data................................................................. 486.2.6.4 pkcs7_parse_signed_data...................................................................... 48

6.2.7 rsakey....................................................................................................... 496.2.7.1 rsakey_generate_private_key................................................................. 496.2.7.2 rsakey_create_private_key.................................................................... 496.2.7.3 rsakey_create_public_key...................................................................... 49

6.2.8 scep.......................................................................................................... 506.2.8.1 scep_build_pkcs_req_chunk................................................................... 506.2.8.2 scep_build_get_cert_init_req_chunk....................................................... 516.2.8.3 scep_parse_pkcs_rep_chunk.................................................................. 526.2.8.4 scep_parse_get_ca_cert_rep_chunk........................................................ 53

6.2.9 util............................................................................................................ 546.2.10 x509........................................................................................................ 566.2.11 main........................................................................................................ 58

6.2.11.1 Beziehen CA-Zertifikat......................................................................... 586.2.11.2 Enrollment......................................................................................... 58

7 Tests...................................................................................................................... 617.1 Testumgebung.................................................................................................. 61

7.1.1 Windows 2003 CA....................................................................................... 617.1.2 OpenSCEP.................................................................................................. 61

7.2 Automatisches Testen „good cases“...................................................................... 627.2.1 Verwendung............................................................................................... 627.2.2 Testfälle..................................................................................................... 62

7.2.2.1 „cacert“............................................................................................... 627.2.2.2 „pkcs1“............................................................................................... 627.2.2.3 „pkcs10.1“........................................................................................... 637.2.2.4 „pkcs10.2“........................................................................................... 637.2.2.5 „pkcs7.1“............................................................................................ 637.2.2.6 „pkcs7.2“............................................................................................ 637.2.2.7 „enroll.1“............................................................................................. 647.2.2.8 „enroll.2“............................................................................................. 647.2.2.9 „enroll.3“............................................................................................. 647.2.2.10 „enroll.4“........................................................................................... 64

7.3 Testen „bad cases“............................................................................................. 658 Infrastruktur..........................................................................................................66

8.1 Einleitung......................................................................................................... 668.2 Entwicklungsumgebung...................................................................................... 668.3 Dokumentationswerkzeuge................................................................................. 66

8.3.1 Doxygen.................................................................................................... 668.3.1.1 Installation.......................................................................................... 678.3.1.2 Verwendung........................................................................................ 67

8.4 Testserver........................................................................................................ 688.4.1 Testserver Linux ........................................................................................ 69

8.4.1.1 Installation Gentoo............................................................................... 698.4.1.1.1 Auswählen des richtigen Installationsmediums................................... 698.4.1.1.2 Vorbereiten der Festplatte(n)........................................................... 70



8.4.1.1.3 Installation der Gentoo Installations Dateien...................................... 708.4.1.1.4 Installation des Gentoo Basis System................................................ 708.4.1.1.5 Konfiguration des Kernels................................................................718.4.1.1.6 Konfiguration des System............................................................... 718.4.1.1.7 Installation der benötigten System Tools........................................... 728.4.1.1.8 Konfiguration des Bootloaders..........................................................728.4.1.1.9 Konfiguration für SSH-Zugriff.......................................................... 72

8.4.1.2 OpenSCEP........................................................................................... 738.4.1.2.1 Source kompilieren und installieren.................................................. 738.4.1.2.2 OpenSCEP konfigurieren................................................................. 748.4.1.2.3 OpenLDAP installieren und konfigurieren........................................... 758.4.1.2.4 OpenSCEP testen........................................................................... 76

8.4.2 Testserver Windows..................................................................................... 778.4.2.1 Installation Windows 2003 Server........................................................... 778.4.2.2 Benötigte Roles einrichten..................................................................... 778.4.2.3 Einrichten der CA.................................................................................. 788.4.2.4 Testen eines Enrollments....................................................................... 78

9 Installationsanleitung............................................................................................ 799.1 Patchen von strongSwan für SCEP........................................................................ 799.2 Erstellen von strongSwan mit SCEP...................................................................... 799.3 Erstellen der Doxygen-Dokumentation.................................................................. 799.4 Durchführen eines Enrollments............................................................................ 809.5 Erstellen eines Test-Szenarios............................................................................. 80

9.5.1 Konfiguration von moon............................................................................... 809.5.2 Konfiguration von sun.................................................................................. 81

10 Resultate..............................................................................................................8210.1 Ergebnisse...................................................................................................... 82

10.1.1 Geforderte Funktionalitäten........................................................................ 8210.1.2 Zusätzliche Funktionalitäten........................................................................ 83

10.2 Schlussfolgerungen.......................................................................................... 8311 Erfahrungsberichte...............................................................................................84

11.1 Jan Hutter....................................................................................................... 8411.2 Martin Willi..................................................................................................... 85

12 Projektmanagement.............................................................................................8612.1 Projektplan..................................................................................................... 86

12.1.1 Prozessmodell........................................................................................... 8612.1.2 Planung von Projektphasen......................................................................... 8612.1.3 Planung von Arbeitspaketen........................................................................ 8612.1.4 Risikoanalyse............................................................................................ 8612.1.5 Projektphasen........................................................................................... 87

12.1.5.1 Einarbeiten........................................................................................ 8712.1.5.2 Generierung PKCS#10......................................................................... 8812.1.5.3 Generierung SCEP-Request.................................................................. 8812.1.5.4 Speicherung Zertifikat......................................................................... 8912.1.5.5 Erweiterungen.................................................................................... 8912.1.5.6 Abschluss der Studienarbeit................................................................. 89

12.1.6 Projektübersicht........................................................................................ 9012.1.7 Umsetzung............................................................................................... 90

12.2 Risikoanalyse.................................................................................................. 9212.2.1 RSA-Schlüssel kann nicht erstellt werden...................................................... 9212.2.2 Geforderte Ziele aus Zeitmangel nicht erreichbar........................................... 9212.2.3 Kein lauffähiger SCEP-Server...................................................................... 93

12.3 Programmierrichtlinien...................................................................................... 9412.3.1 Code-Dokumentation................................................................................. 9412.3.2 Quellcode................................................................................................. 95



12.3.2.1 Strukturierung.................................................................................... 9512.3.2.2 Namensgebung.................................................................................. 9512.3.2.3 Beispiel............................................................................................. 96

12.4 Protokolle....................................................................................................... 9712.4.1 Protokoll vom 21.03.2005........................................................................... 97

12.4.1.1 Allgemeines....................................................................................... 9712.4.1.2 Besprochene Punkte............................................................................ 9712.4.1.3 Entscheidungen.................................................................................. 9712.4.1.4 Nächste Sitzung................................................................................. 97

12.4.2 Protokoll vom 30.03.2005........................................................................... 9812.4.2.1 Allgemeines....................................................................................... 9812.4.2.2 Besprochene Punkte............................................................................ 9812.4.2.3 Nächste Sitzung................................................................................. 98

12.4.3 Protokoll vom 11.04.2005........................................................................... 9912.4.3.1 Allgemeines....................................................................................... 9912.4.3.2 Besprochene Punkte............................................................................ 9912.4.3.3 Nächste Sitzung................................................................................. 99

12.4.4 Protokoll vom 18.04.2005......................................................................... 10012.4.4.1 Allgemeines..................................................................................... 10012.4.4.2 Besprochene Punkte.......................................................................... 10012.4.4.3 Nächste Sitzung................................................................................ 100

12.4.5 Protokoll vom 25.04.2005......................................................................... 10112.4.5.1 Allgemeines..................................................................................... 10112.4.5.2 Besprochene Punkte.......................................................................... 10112.4.5.3 Entscheidungen................................................................................ 10112.4.5.4 Nächste Sitzung................................................................................ 101




13 Anhang...............................................................................................................10513.1 CD-Struktur................................................................................................... 10513.2 Glossar......................................................................................................... 10613.3 Quellenverzeichnis.......................................................................................... 10913.4 Dokumentenverzeichnis.................................................................................. 11113.5 Tabellenverzeichnis........................................................................................ 11313.6 Abbildungsverzeichnis..................................................................................... 114


Studienarbeit „SCEP für Linux strongSwan“ Aufgabenstellung

1 AufgabenstellungDer nachfolgende Text entspricht der original Aufgabenstellung, wie sie von Prof. Dr. AndreasSteffen formuliert wurde.

1.1 Einführung Die Stärke der Linux OpenSource VPN Lösung strongSwan liegt in der Benutzer- und Host- Authentisierung mittels X.509 Zertifikaten. Um in einem weiteren Entwicklungsschritt die zentralisierte Administrierbarkeit von verteilten strongSwan VPN Gateways und Clients zu verbessern, soll das Simple Certificate Enrollment Protocol (SCEP) in der ProgrammierspracheC implementiert werden. Mit dem HTTP-basierten SCEP Protokoll kann ein VPN End- punkt auf der Basis eines lokal generierten RSA Schlüsselpaars einen Certificate Request an eine PKI senden. Die PKI überprüft den Request und generiert ein signiertes X.509 Zertifikat, dass anschliessend vom VPN Endpunkt via SCEP abgeholt und lokal installiert werden kann.

1.2 Aufgabenstellung – Implementierung eines SCEP Clients in der Programmiersprache C auf der Basis der

vorhandenen strongSwan X.509 und ASN.1 Bibliotheken (kein OpenSSL).– Generierung von RSA Schlüsselpaaren mit spezifizierter Modulgrösse mittels der GNU Multi-

Precision Library libgmp und Abspeicherung in einem RSA Private Key File in /ettc/ipsec.d/private.

– Generierung eines PKCS#10 Certification Requests für eine gewünschte CA.– HTTP Kommunikation mit der PKI auf der Basis von libcurl.– Gesicherte Übertragung des PKCS#10 Certification Requests via PKCS#7 Envelope an die

CA mittels der SCEP PKCSReq Payload.– Als SCEP-fähige PKI kann entweder die Windows 2003 Server CA oder OpenSCEP verwendet

werden. – Automatische Client Authentisierung auf der Basis eines Preshared Secrets.– Abholen des Client Zertifikats via die SCEP CertRep Payload und Abspeicherung in

/etc/ipsec.d/certs.

1.3 Links – strongSwan Projekt: http://www.strongswan.org/– SCEP Internet Draft: http://bgp.potaroo.net/ietf/all-ids/draft-nourse-scep-10.txt – HSR Java SCEP Implementation: http://www.urut.ch/scep/scepclient.pdf – OpenSCEP Projekt: http://openscep.othello.ch/ – GMP Projekt: http://swox.com/gmp/ – cURL Projekt: http://curl.haxx.se/

Rapperswil, 21. März 2005

Prof. Dr. Andreas Steffen


Studienarbeit „SCEP für Linux strongSwan“ Abstract

2 AbstractAbteilung Informatik

Name der Studenten Jan Hutter, Martin Willi

Semester SS 05

Titel der Studienarbeit SCEP für Linux strongSwan

Examinator Prof. Dr. Andreas Steffen

Ziel der ArbeitEin Grossteil heutiger Sicherheitsprotokolle nutzt digitale Zertifikate, um die Authentizität vonBenutzern und Hosts sicherzustellen. Die Verwaltung dieser Zertifikate ist komplex undverlangt meist eine aufwendig zu wartende Public-Key Infrastruktur.

Das „Cisco Systems' Simple Certificate Enrollment Protocol“ ist ein Protokoll zur Verteilungvon digitalen Zertifikaten. Basierend auf etablierten Technologien erlaubt es die sichere undautomatisierte Verteilung von digitalen Zertifikaten.

Auch die IPsec-Implementierung strongSwan nutzt Zertifikate für die Benutzer und Host-Authentisierung. Es fehlt jedoch eine integrierte Möglichkeit, die entsprechenden Zertifikateautomatisiert auf die Rechner zu verteilen.

Mit „SCEP für Linux strongSwan“ soll diese Lücke geschlossen und strongSwan um die Client-Funktionalität des SCEP-Protokolls erweitert werden. Als Voraussetzung dürfen keine neuenAbhängigkeiten z.B. zu OpenSSL geschaffen werden.

ErgebnisseMit dem scepclient ist ein Kommandozeilen-Tool für Linux entstanden, welches diewichtigsten Client-Funktionalitäten von SCEP implementiert. Der scepclient ermöglicht dengesicherten Bezug von digitalen Zertifikaten über SCEP. strongSwan kann somit Zertifikateüber den selben Mechanismus beziehen, wie dies die Geräte von Cisco tun.

Mit Hilfe des scepclients ist strongSwan einfacher in eine bestehende Public-KeyInfrastruktur einzubinden. Dank der Kompatibilität zur mächtigen und verbreiteten Windows2003 CA als auch zu anderen SCEP-Server-Implementierungen ist der Einsatz vonstrongSwan mit dem scepclient in unterschiedlichsten Umgebungen vorstellbar.

Die geforderten Funktionen des scepclients konnten realisiert werden. Zusätzlich ist derscepclient in der Lage, übergeordnete Zertifikate der Zertifizierungskette, sprich CA-Zertifikate, zu beziehen.

AusblickDie Client-Funktionalität von SCEP ist nun mit dem Tool scepclient in strongSwan integriert.Es wäre denkbar, in einem weiteren Schritt die Server-Funktionalität von SCEP ebenfalls instrongSwan zu integrieren und somit die komplette Zertifikatsverteilung über strongSwan zuermöglichen.Des weiteren wäre ein System für die einfache zentrale Administration von digitalenZertifikaten wünschenswert. Die Hemmschwelle, welche aufwendige Public-KeyInfrastrukturen mit sich bringen, könnte so verkleinert werden. Somit würde sich dieAttraktivität zertifikatsbasierter Sicherheitssysteme weiter verbessern.


Studienarbeit „SCEP für Linux strongSwan“ Management Summary

3 Management Summary

3.1 AusgangslageSicherheit durch IPSec Verschlüsselte Kommunikation findet immer mehr Anwendungen.

Egal ob es sich um die Anbindung von Aussenstellen ansFirmennetzwerk oder die Absicherung von Funknetzen handelt, eineverschlüsselte Übertragungen schafft die Grundlage dafür. IPSec istein Standard, der das IP-Protokoll um die Fähigkeiten Vertraulichkeit,Authentizität und Integrität erweitert.

strongSwan Die IPSec-Implementierung strongSwan ist unter einer OpenSource-Lizenz verfügbar und stellt eine umfangreiche und kompletteSoftware für die sichere Kommunikation mittels IPSec zur Verfügung.

Digitale Zertifikate Die Stärke von strongSwan liegt in der Authentisierung mittelsdigitaler Zertifikate. Durch den Einsatz solcher Zertifikate wird einsehr sicheres und flexibles System ermöglicht.

Public-Key Infrastruktur Der Aufwand für die Ausstellung und Verwaltung von digitalenZertifikaten nimmt bei zunehmender Nutzerzahl stark zu, weshalbeine umfangreiche Public-Key Infrastruktur notwendig wird. DasVerteilen dieser Zertifikate muss dabei auf gesicherten Wegenerfolgen, damit die Sicherheit der ganzen Infrastruktur gewährleistetbleibt.

SCEP Das von Cisco Systems entwickelte „Simple Certificate EnrollmentProtocol“ bietet eine Möglichkeit, Zertifikate sicher und möglichstautomatisiert zu beziehen. Es baut auf bewährten Technologien aufund hat sich bereits als de facto Standard etabliert.

Kein OpenSSL Es gibt mehrere OpenSource-Implementierungen von SCEP. Diesebauen auf den kryptographischen Routinen von OpenSSL auf und sinddadurch von amerikanischem Code abhängig. In strongSwan soll dieAbhängigkeit zu OpenSSL deshalb vermieden werden.

SCEP für strongSwan Das Ziel dieser Studienarbeit besteht darin, die Basis-Funktionalitätvon SCEP in strongSwan zu integrieren. Es ist ein Client für dasSCEP-Protokoll zu entwickeln, der lediglich Routinen von strongSwanund dessen Abhängigkeiten nutzt.



3.2 VorgehenEinarbeiten Da SCEP auf vorhandenen Technologien für Kommunikation und

Sicherheit setzt, mussten zuerst Kenntnisse über diese Technologienerarbeitet werden. Wir hatten uns in umfangreiche Standardseinzuarbeiten, um einen Überblick über die Materie zu gewinnen. Da die Implementierung auf strongSwan aufsetzt, war es nötig, auchden Aufbau von strongSwan in fundamentalen Zügen kennen zulernen.

Infrastruktur Weil ein Protokoll zu implementieren war und dieses möglichstinteroperabel zu bestehenden Lösungen sein sollte, wurde eineumfangreiche Infrastruktur eingerichtet. Diese ermöglichte dasTesten unserer Software mit bereits bestehenden Produkten schonwährend der Entwicklungsphase.

SchrittweiseImplementierung

In der Aufgabenstellung ist die Implementierung der Basis-Funktionalität von SCEP vorgeschrieben. Um dieses Ziel auch sicherzu erreichen, wurde die Software schrittweise implementiert. DerStand während der Arbeit konnte dadurch stets nachvollzogen undüberprüft werden.

Reserven genutzt Bereits während der Einarbeitungsphase wurde eine Pufferzeit fürUnvorhergesehenes geplant. Der planmässige Fortschritt der Arbeiterlaubte uns schlussendlich, diese Reservezeit für Software-Erweiterungen zu nutzen, die über die Basis-Funktionalitäthinausgehen.

Abschluss Der letzte Abschnitt der Studienarbeit wurde mit dem Abschliessennoch offener Aufgaben verbracht. Die Software wurde in dieser Zeitnicht mehr verändert.

Betreuer Diese Studienarbeit wurde von Prof. Dr. Andreas Steffenausgeschrieben und betreut. In wöchentlichen Sitzungen konnten wirmit ihm über aufgetretene Probleme und deren Lösung diskutieren.



3.3 Ergebnissescepclient erstellt strongSwan konnte um ein Client für das SCEP-Protokoll erweitert

werden. Dieser scepclient beherrscht das Generieren von RSA-Schlüsseln und das Beziehen von Zertifikaten.

Ziel erreicht Das Ziel eines funktionsfähigen SCEP-Clients für strongSwan konntein dieser Studienarbeit erreicht werden. Die entstandene Softwareentspricht allen geforderten Zielen.

Zusätzliche Funktionen Dank einer guten Planung und genügend Zeit konnte der Client umzusätzliche Funktionen des SCEP-Protokolls erweitert werden. Eswurde das Beziehen von CA-Zertifikaten ebenso wie der manuelleBezug von Zertifikaten realisiert.

Kompatibilität Der erstellte SCEP-Client wurde gegen die Windows 2003 CA mitSCEP-Unterstützung entwickelt und getestet. Zudem konnte auch dieKompatibilität zu der Linux/Unix-basierten SCEP-ImplementierungOpenSCEP erarbeitet werden.

3.4 AusblickServerseitige Integration strongSwan wurde mit dieser Studienarbeit um die Client-

Funktionalität von SCEP erweitert. Eine Implementierung derServerseite von SCEP und die Integration in strongSwan wäredenkbar. Damit könnte die Unabhängigkeit von strongSwan weiterverbessert werden.

Zentrale Administration Die zentrale Administration digitaler Zertifikate setzt meist einekomplizierte Public-Key Infrastruktur voraus. Mit einer einfachen undzentralen Zertifikats-Verwaltung könnte die Attraktivitätzertifikatsbasierter Systeme erhöht werden.


Studienarbeit „SCEP für Linux strongSwan“ Einleitung

4 Einleitung

4.1 ProblemstellungZiel der Studienarbeit „SCEP für strongSwan“ war es, die IPSec-Implementierung strongSwanum die Fähigkeiten des SCEP-Protokolls zu erweitern. Dieser Text soll einen Überblick überSCEP geben und die daraus resultierenden Vorteile für strongSwan aufzeigen.

Für die sichere Authentisierung bietet strongSwan die Möglichkeit, Zertifikate einzusetzen,welche auf Public-Key-Verfahren basieren. Dazu ist allerdings eine umfangreiche Public-KeyInfrastruktur notwendig, die es zu warten gilt. Die Verteilung und das Management vonZertifikaten ist somit ein wesentlicher Nachteil der zertifikatsbasierten Authentisierung.

Mit SCEP wurde ein Protokoll entworfen, welches das sichere Verteilen von X.509-Zertifikatenermöglicht. Der von Cisco Systems entwickelte Standard ist als Draft [SCEPv11] beschriebenund hat sich zum de facto Standard für das Beziehen von Zertifikaten entwickelt. Die Windows2003 Server CA kann mit einem Addon um die serverseitige SCEP-Funktionalität erweitertwerden. Auch in der OpenSource-Welt sind bereits verschiedene Implementierungenvorhanden, wodurch eine Betrieb eines SCEP-Servers auf verschiedensten Systemen möglichist.

StrongSwan bietet eine sehr ausgereifte und umfangreiche Unterstützung für X.509-Zertifikate.Allerdings fehlt die Möglichkeit, diese direkt mittels strongSwan zu beziehen; für das Erstellenvon Schlüsseln und Zertifikaten waren bisher separate Tools notwendig. Zudem steht und fälltdie Sicherheit der ganzen Infrastruktur mit der sicheren Verteilung der Zertifikate.

Durch das Integrieren eines SCEP-Clients erhält strongSwan die Möglichkeit, private Schlüsseldirekt zu erzeugen, ohne dass diese den Host je verlassen müssen. Durch das vereinfachteBeziehen von dazugehörigen Zertifikaten von der CA über SCEP wird die Handhabung derPublic-Key Infrastruktur wesentlich vereinfacht.

Die Studienarbeit hatte das Ziel, einen möglichst kompletten Client für SCEP in strongSwan zuintegrieren. Dieser durfte aber strongSwan nicht von neuen Bibliotheken abhängig machen,das heisst es konnten lediglich Funktionen von strongSwan und zusätzlich von libcurl alsauch libgmp verwendet werden. Auf den Einsatz von kryptographischen Bibliotheken wieOpenSSL musste verzichtet werden, da kein amerikanischer Code in strongSwan einfliessensollte.


Studienarbeit „SCEP für Linux strongSwan“ Einleitung

4.2 Gliederung des DokumentesDie Gliederung der ganzen Dokumentation kann in mehrere Teile aufgeteilt werden.

Der erste Teil der Dokumentation bietet einen Überblick über der Arbeit. Er beginnt mit dereigentlichen Aufgabenstellung, wie Sie vom Betreuer formuliert wurde. DieserAufgabenstellung folgen das Abstract und das Management Summary.

Der zweite Teil bildet der Technische Bericht und ist über mehrere Dokumente verteilt:

– Im Dokument „Technologien“ werden die wichtigsten Technologien beschrieben, die bei derUmsetzung der Studienarbeit „SCEP für Linux strongSwan“ zum Einsatz gekommen sind.

– Der ganze Aufbau der Software scepclient ist im Dokument „Software-Design“ erläutert.Darin wird jedes Modul1 detailliert beschrieben. Das Dokument bietet einen komplettenÜberblick über die Innerein des scepclients und setzt für das VerständnisProgrammierkenntnisse in C voraus.

– Im Dokument „Tests“ wird auf die Test-Thematik eingegangen. Es beschreibt dieTestumgebung und wie automatische Tests mit Hilfe eines Scripts durchgeführt werdenkönnen.

– Die eingesetzte Hard- und Software ist im Dokument „Infrastruktur“ formuliert. Zudembeinhaltet dieses Dokument weitere Anleitungen z.B. zur Installation des Testservers.

– Eine Hilfestellung zur Installation von „SCEP für Linux strongSwan“ ist im Dokument„Installationsanleitung“ enthalten. Darin ist beschrieben, wie der scepclient in strongSwanintegriert wird und wie ein Beispiel-Enrollment aussehen kann.

– Der Technische Bericht wird mit dem Dokument „Resultate“ abgeschlossen. Dieses fasst dieErgebnisse der Studienarbeit zusammen. Aufgrund der Ergebnisse wird zudem eineSchlussfolgerung gezogen.

Der dritte Teil der Dokumentation besteht aus den persönlichen Berichten der beteiligtenStudenten, sowie den Projektmanagement-Dokumenten. Dokumente des Projektmanagementssind Projektplan, Risikoanalyse, Programmierrichtlinien und die Protokolle der Betreuer-Sitzungen. Die Zeitplanung ist Teil des Projektplans und beinhaltet auch eine statistischeAuswertung.

Der vierte und letzte Teil besteht aus dem kompletten Anhang. Darin enthalten sind Glossar,diverse Verzeichnisse und eine Beschreibung der Struktur der abgegebenen CD-ROM. DerAnhang beinhaltet auch das Dokument „Dokumentenverzeichnis“, in welchem der Inhalt jedesDokuments nochmals kurz beschrieben ist.

1 Die Programmiersprache C kennt keine Klassen und Pakete. Als Modul wird darum eine Quellcode-Dateibezeichnet, in welcher jeweils Funktionalitäten zusammengefasst sind.


Studienarbeit „SCEP für Linux strongSwan“ Technologien

5 Technologien

5.1 EinleitungIn diesem Dokument werden folgende, im scepclient eingesetzte Technologien, vorgestelltund beschrieben:

– ASN.1 Der “Abstract Syntax Notation One“-Standard zur abstrakten Beschreibung von Datentypen

– PKCS#1 Ein Public-Key Verfahren auf der Grundlage des RSA-Algorithmus

– PKCS#10 Ein Syntax-Standard für Zertifikatsanfragen

– PKCS#7 Ein Message-Standard für verschlüsselte und signierte Nachrichten

– SCEP Cisco Systems' „Simple Certificate Enrollment Protocol“ zur sicheren Verteilung von digitalen Zertifikaten

Implementierungsspezifische Details können dem Dokument „Software-Design“ entnommenwerden. Es wird erwartet, dass der Leser ein grobes Verständnis von Public-Key Infrastrukturenund Verschlüsselung besitzt und ihm Begriffe wie RSA, MD5, DES und X.509 nicht fremd sind.

5.2 ASN.1Die „Abstract Syntax Notation One“ (ASN.1) ist ein Standard zur abstrakten Beschreibung vonDatentypen. ASN.1 beschreibt diese, ohne auf die spezifische Darstellung auf unterschiedlichenComputer-Architekturen einzugehen. Wie ASN.1 Datentypen in Bits und Bytes dargestelltwerden, ist in verschiedenen Kodierungen, so genannten „Encoding Rules“, definiert. ASN.1zusammen mit einer gemeinsamen Kodierung ermöglicht so die Kommunikation von Systemenmit unterschiedlichen internen Darstellungen. Ein Power-PC kann so beispielsweise mit einemx86-System Daten austauschen, indem beide ASN.1 mit gemeinsamen „Encoding Rules“einsetzen. Viel verbreitete „Encoding Rules“ sind die „Basic Encoding Rules“ (BER) und die„Distinguished Encoding Rules“ (DER).

Im SCEP-Draft [SCEPv11] wird als „Encoding Rules“ DER abwechselnd mit BER verwendet. Esist nicht klar definiert, welche dieser beiden Kodierungen verwendet werden soll. Da aber dieDER-Kodierung ein Subset von BER ist, kann davon ausgegangen werden, dass dieUnterstützung der DER-Kodierung hinreichend ist. Der scepclient unterstützt nur die DER-Kodierung, sowohl beim Parsen, wie auch beim Erstellen von kodierten Daten. Unter 5.2.2 wirdgenauer auf die DER-Kodierung eingegangen.

ASN.1 ist weit verbreitet in der Beschreibung von Protokoll-Nachrichtenelementen des OSI-Modells. SCEP selbst beschreibt alle eingesetzten Datentypen in ASN.1 und nutzt dabei auchbereits existierende Standards, wie beispielsweise PKCS#10, PKCS#1, PKCS#7 oder X.509welche selber auch in ASN.1 beschrieben sind.



5.2.1 Syntax

ASN.1 wird in einer BNF-ähnlichen Darstellung beschrieben, als Beispiel ist nachfolgend dieASN.1-Beschreibung einer PKCS#10-Zertifikatsanfrage aus dem RFC 2986 [RFC2986]aufgeführt:

CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }}, signature BIT STRING}

ASN.1 kennt neben elementaren Typen, wie BOOLEAN oder INTEGER auch zusammengesetzteund spezielle Typen wie SEQUENCE oder OID. Die unterstützten Typen und deren Verwendungkönnen dem Standard von ASN.1 [X680-0207] entnommen werden.

5.2.2 DER-Kodierung

Die DER-Kodierung beschreibt die Darstellung von ASN.1-Datentypen auf Bitebene. DERdefiniert die genaue Kodierung der ASN.1-Datentypen und interpretiert ein Byte nach dem „BigEndian“-Prinzip, wobei das höherwertige Bit links ist.

5.2.2.1 Datentypen

Ein DER-kodierter ASN.1-Datentyp ist nach folgendem Muster aufgebaut:

Abbildung 1 Aufbau eines DER-kodierten ASN.1-Datentyps

Das Feld Typ beinhaltet jeweils den kodierten Typ. Beispielsweise hat der ASN.1-Typ INTEGERden Wert 0x02 und ein SET den Wert 0x31.

Der Wert im Feld Länge kann sich über mehrere Bytes erstrecken und gibt an, wie viele Bytesdie eigentlichen Daten im Feld Inhalt belegen. Solange die Daten im Feld Inhalt nicht mehr als127 Byte belegen, wird deren Länge in einem einzigen Byte kodiert. Bei einem Dateninhalt mitder Länge 67 würde also der Wert 0x43 als Länge kodiert werden. Belegen die Daten im FeldInhalt jedoch mehr als 127 Byte, ist das erste Bit im Feld Länge gesetzt und die restlichen 7 Bitbestimmen die Anzahl Bytes, die für die Kodierung der Länge folgen. Beispielsweise wird dasLängenfeld bei einem Inhalt mit der Länge von 589 Bytes folgendermassen kodiert: 0x82 0x020x4D.

Das Feld Inhalt beinhaltet schlussendlich den Wert des entsprechenden Typs. Die Länge diesesFeldes entspricht der Angabe im Feld Länge.


Typ Länge Inhalt


5.2.2.2 OIDs

Um den Typ von Inhalten oder Bezeichnungen zu definieren, kommen so genannte „ObjectIdentifiers“ oder kurz OIDs zum Einsatz. Es handelt sich dabei um hierarchisch aufgebauteKnoten, welche eine weltweit eindeutige Definition von OIDs erlauben. Eine gute Sammlung zuOIDs ist unter [OID-Tree] zu finden.

Die OID, welche beispielsweise den Typ einer Signatur für MD5 und RSA beschreibt, ist indieser Hierarchie aus folgenden Knoten aufgebaut:

iso.member.usa.rsadsi.pkcs.pkcs1.md5withrsaencryptionEs handelt sich also um eine Definition von der in den USA niedergelassenen „RSA DataSecurity Inc.“, welche diese in PKCS#1 Standard abgelegt hat. Alle Knoten besitzen eineNummer, woraus folgende nummerische Darstellung abgeleitet werden kann:

1.2.840.113549.1.1.4Die Kodierung dieser OID erfolgt nach einem speziellen Schema. Als erstes wird der Typ unddie Länge wie oben beschrieben kodiert. Nun folgt die Kodierung der einzelnen Knoten. Dieersten beiden Nummern werden allerdings zusammengefasst. Dies geschieht, in dem die ersteZahl mit 40 multipliziert und die zweite Zahl dazu gezählt wird.

Des weiteren wird nun jeder Knoten Kodiert, wobei folgende Regeln angewendet werden:

Zahl im Bereich Binäre Codierung

0..127 0xxx xxxx

128..16383 1xxx xxxx 0xxx xxxx

16384..2097151 1xxx xxxx 1xxx xxxx 0xxx xxxx

Tabelle 1 Codierung von Knoten in OIDs

Die mit „x“ gekennzeichneten Bits werden dabei für die Kodierung der Zahl verwendet. Die festdefinierten Null- und Eins-Bits werden einfach dazwischen geschoben.

Unser Beispiel der MD5-RSA-Signatur wird also hexadezimal folgendermassen kodiert:

1.2.840.113549.1.1.4

0x06 0x09 0x2A 0x86 0x48 0x86 0xF7 0x0D 0x01 0x01 0x04

Abbildung 2 Kodieren einer ASN.1 OID

Die Typenbezeichnung für OIDs ist 0x06, die Länge der OID ist 0x09, und der Inhalt ergibt sichaus der Anwendung der beschriebenen Regeln.


LängeTyp 40*1+2 840 113549 1 1 4


5.2.2.3 Beispiel

Nachfolgend wird ein DER-Kodierung anhand von Teilen eines DER-kodierten PKCS#10-Zertifikats-Requests untersucht. Der gesamte DER-kodierte Request sieht dabeifolgendermassen aus, wobei die untersuchten Teile markiert sind:

Abbildung 3 DER-kodierter PKCS#10-Request

Die markierten Teile sind folgendermassen zu interpretieren:Hexwert Bedeutung

02 01 00 Hier handelt es sich um einen kodierten INTEGER mit einem Wert von 0:Typ: 0x02 entspricht IntegerLänge: 0x01 entspricht einer Länge von 1 ByteInhalt: 0x00 entspricht einem Wert von 0

06 03 55 04 06 Dieser Wert entspricht einem kodierten Object Identifier (OID):Typ: 0x06 entspricht OIDLänge: 0x03 entspricht einer Länge von 3 ByteInhalt: 0x55 0x04 0x06 ist die OID für countryName

05 00 Hier handelt es sich um einen kodierten NULL-Wert:Typ: 0x05 entspricht NULL-WertLänge: 0x00 entspricht einer Länge von 0 ByteInhalt: Da eine Länge von 0 Byte angegeben war, hat dieses Feld keinen Inhalt

03 81 81 00 4a...2a 54 8e ed 73

Hier handelt es sich um einen kodierten BIT STRING:Typ: 0x03 entspricht dem Typ BIT STRINGLänge: 0x81 0x81 entspricht einer Länge von 129 Byte. Inhalt: Der Inhalt ist irgend ein binärer beginnend mit dem Wert 0x00

Tabelle 2 DER-Kodierung untersucht am Beispiel eines PKCS#10-Requests



5.3 PKCS#1PKCS#1 beschreibt den RSA-Kryptographie-Standard basierend auf dem RSA-Algorithmus derFirma „RSA Security Inc.“. Neben der Beschreibung des RSA-Algorithmus definiert PKCS#1auch den ASN.1-Syntax zur Speicherung eines RSA-Schlüssels. In dieser Dokumentation wird,wo nicht anders vermerkt, die Bezeichnung PKCS#1 für das ASN.1 Schlüsselformat verwendetund nicht für den eigentliche Kryptographie-Standard. Wir beziehen uns jeweils auf denPKCS#1-Standard in der Version 2.1 [PKCS1v2.1].

5.3.1 Dateiformat

Der scepclient liest und speichert ein privater RSA-Schlüssel im Format, wie dieser im ASN.1Modul von PKCS#1 als Typ RSAPrivateKey definiert ist, wobei die DER-Kodierung verwendetwird. Der Typ RSAPrivateKey wird im ASN.1-Modul von PKCS#1 folgendermassen definiert:

RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

Aus der obigen ASN.1-Typendefinition ist ersichtlich, dass ein privater RSA-Schlüssel eineeinfache Sequenz aus mehreren Integer-Werten und einem optionalen Feld vom TypOtherPrimeInfos darstellt. Im scepclient wird das optionale Feld otherPrimeInfos beimSpeichern eines RSA-Schlüssels nicht erstellt und beim Lesen eines RSA-Schlüssels nichtgeparst.

Der scepclient lädt und speichert im DER-Format kodierte private RSA-Schlüssel. DieInteger-Werte des privaten RSA-Schlüssels werden so gespeichert, dass diese stets einenpositiven Wert annehmen. Dies wird dadurch erreicht, indem während der DER-Kodierung beinegativen Werten ein Byte mit dem Wert 0x00 vor dem eigentlichen Integer-Wert eingefügtwird. Mehr Informationen zur DER-Kodierung kann dem Abschnitt 5.2.2 entnommen werden.



5.4 PKCS#10Im Gegensatz zu PKCS#1 handelt es sich bei PKCS#10 nicht um einen Kryptographie-Standard, sondern um einen Syntax Standard. PKCS#10 beschreibt einen Syntax fürZertifikatsanfragen bei einer Zertifizierungsstelle. Wie fast alle PKCS-Standards ist auchPKCS#10 in einem ASN.1 Modul definiert. Wir beziehen uns jeweils auf den PKCS#10-Standard in der Version 1.7 [PKCS10v1.7].

Ein PKCS#10-Request besteht aus drei Teilen. Der erste enthält die eigentlichen Informationenzum Zertifikats-Request (inklusive Public-Key), im zweiten wird der Algorithmus zurSignaturerstellung definiert, der dritte Teil besteht aus der Signatur:

CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }}, signature BIT STRING }

Der AlgorithmIdentifier ist die OID der verwendeten Algorithmen für die Signatur, z.B. MD5mit RSA. Optional enthält er auch noch für den Algorithmus relevante Parameter, was bei MD5mit RSA jedoch nicht der Fall ist.

Die Signatur ist das Resultat des Signiervorganges, kodiert als ein ASN.1 Bitstring. DieSignatur wird über das ganze DER-kodierte cerficiactionRequestInfo-Feld erstellt. Dabeikommt der Private-Key des Requesters zum Einsatz, welcher zum dem imcertificationRequest vorhandenen Public-Key gehört.

Das CertificationRequestInfo-Feld besteht aus der Version, dem Namen des Requesters als„Distinguished Name“, seinem Public-Key und weiteren Attributen:

CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} }

Im subject wird der „Distinguished Name“ kodiert, für welcher das Zertifikat ausgestelltwerden soll. Das subjectPKInfo-Feld enthält den Public-Key inklusive verwendetemAlgorithmus. In den attributes sind Attribute eingetragen, welche zusätzlich ins Zertifikatübernommen werden sollen. Beispiele hierfür sind die subjectAltNames von X.509v3. Auch inden attributes wird das „challenge password“ kodiert, mit welchem ein Zertifikatzurückgezogen werden kann.

Der verwendete Algorithmus zum Public-Key ist mit einer OID beschrieben.SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE { algorithm AlgorithmIdentifier {{IOSet}}, subjectPublicKey BIT STRING }

Der Public-Key ist spezifisch für den Algorithmus als Bitstring kodiert. Bei der Verwendung vonRSA wird in diesem Bitstring eine Sequenz aus zwei Integers kodiert. Der erste ist derModulus, der zweite ist der öffentliche Exponent.



5.5 PKCS#7Wie bei PKCS#10 handelt es sich bei PKCS#7 um einen Syntax Standard. Genauer ist PKCS#7ein Message-Standard, in welchem ein allgemeines Format zur Übertragung von Datenbeschrieben ist. Dabei erlaubt PKCS#7 die Verschlüsselung oder Signierung der Meldungs-Daten1 und definiert dabei das zu verwendende Format. Der komplette Standard [PKCS#7v1.5]in der aktuellen Version 1.5 ist im RFC 2315 enthalten.

SCEP nutzt PKCS#7, indem die Meldungen zwischen dem SCEP-Server und dem SCEP-Clientim PKCS#7-Format kodiert sind. Dabei können diese Meldungen weitere, verschachteltePKCS#7 Meldungen enthalten. Details zu SCEP können dem Abschnitt 5.6 entnommen werden.

5.5.1 Allgemeiner Aufbau

Eine Message im PKCS#7-Format hat grundsätzlich immer den selben Aufbau. Eine Sequenzbestehend aus dem Inhaltstyp (contentType) und dem eigentlichen Inhalt (content) bildeneine PKCS#7-Message. Die Definition in ASN.1-Schreibweise sieht folgendermassen aus:

ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

Das Feld contentType ist ein „Object Identifier2“ und beschreibt die Art des Inhaltes im Feldcontent. Wie der Inhalt im Feld content behandelt wird ist somit abhängig von der OID imFeld contentType. PKCS#7 unterstützt sechs verschiedene Inhaltstypen:

Inhaltstyp Beschreibung

data Beim Inhaltstyp data ist der Inhalt dieser PKCS#7-Message vom ASN.1-Typ OCTETSTRING. Der Inhalt von content ist somit als binärer Wert zu behandeln. Es ist natürlich möglich, dass der Inhalt des Feldes content selbst wieder ASN.1-kodiert ist. In einem solchen Fall muss die lesende Applikation dafür sorgen, dass derInhalt entsprechend als ASN.1 geparst wird.

signedData Bei diesem Inhaltstyp besteht der Inhalt der PKCS#7-Message aus den eigentlichenDaten und keinem oder mehreren Signaturen des entsprechenden Inhaltes. JedeSignatur ist dabei durch einen anderen Unterzeichner erstellt worden.Typischerweise enthält eine PKCS#7-Message vom Typ signedData lediglich eineSignatur eines einzigen Unterzeichner. Im Abschnitt 5.5.2 wird detaillierter auf denInhaltstyp signedData eingegangen.

envelopedData Der Inhalt der PKCS#7-Message bei diesem Inhaltstyp besteht aus den eigentlichenDaten in verschlüsselter Form und Inhalts-Entschlüsselungs-Schlüssel für einen odermehrere Empfänger. Die Kombination eines solchen Entschlüsselungs-Schlüssel und dem verschlüsseltenDateninhalt wird als „digital envelope“, zu deutsch digitaler Umschlag bezeichnet.Der Entschlüsselungs-Schlüssel selbst ist verschlüsselt und kann nur durch denadressierten Empfänger entschlüsselt werden. Um als Empfänger auf den Verschlüsselten Inhalt zuzugreifen, muss dieser als erstesseinen Entschlüsselungs-Schlüssel entschlüsseln und anschliessend denverschlüsselten Dateninhalt mit dem entschlüsselten Entschlüsselungs-Schlüsselentschlüsseln. Damit wird gewährleistet, dass nur die adressierten Empfänger auf dieverschlüsselten Daten zugreifen können. Im Abschnitt 5.5.3 wird detaillierter auf denInhaltstyp envelopedData eingegangen.

1 Die Bezeichnungen Message und Meldung werden in diesem Abschnitt gleich behandelt2 Die Werte der entsprechenden OIDs können dem RFC von PKCS#7 entnommen werden



Inhaltstyp Beschreibung

signedAndEnvelopedData Der Inhaltstyp signedAndEnvelopedData ist, wie der Name vermuten lässt, dieKombination der Inhaltstypen envelopedData und signedData. Zum einen ist derDateninhalt wie beim Inhaltstyp envelopedData verschlüsselt und kann nur durch dieentsprechenden Empfänger entschlüsselt werden. Zum anderen ist eine oder mehrereSignaturen über die verschlüsselten Daten und Empfänger enthalten. Somit ist dieVertraulichkeit der eigentlichen Daten, sowie die Integrität des ganzen Paketsgewährleistet. Obwohl im SCEP-Protokoll Daten verschlüsselt und signiert werden, macht SCEPkeinen Nutzen von diesem speziellen PKCS#7-Datentyp. Den Effekt der Integritätzusammen mit der Vertraulichkeit erreicht SCEP durch die Verschachtelung vonPkCS#7-Meldungen der Datentypen envelopedData und signedData. Nachfolgendwird deshalb nicht weiter auf den Inhaltstyp signedAndEnvelopedData eingegangen.

digestedData Beim Inhaltstyp digestedData besteht der Inhalt der PKCS#7-Message aus deneigentlichen Daten und einem „digest“ der Entsprechenden Daten. Im Gegensatz zumInhaltstyp signedData ist die so genannte „non-repudiation“ der Daten nichtgewährleistet, da der „digest“ selbst nicht verschlüsselt ist. Der PKCS#7-Standardsieht einen Nutzen dieses Inhaltstyps bei der Kombination mit dem DatentypenvelopedData.Das SCEP-Protokoll macht keinen Nutzen von diesem Inhaltstyp. Aus diesem Grundwird nicht weiter darauf eingegangen.

encryptedData Dieser Inhaltstyp ist, wie der Datentyp envelopedData, für verschlüsselte Datengedacht. Der Unterschied zum Datentyp envelopedData ist jedoch, dass in derentsprechenden PKCS#7-Message keine Angaben über denVerschlüsselungsalgorithmus und auch keine Entschlüsselungs-Schlüssel enthaltensind. Es ist somit Aufgabe der lesenden Applikation, den verschlüsselten Dateninhaltrichtig zu behandeln.Auch dieser Datentyp wird vom SCEP-Protokoll nicht verwendet, weshalb darauf nichtweiter eingegangen wird.

Tabelle 3 Inhaltstypen einer PKCS#7-Message

5.5.2 Datentyp signedData

Der PKCS#7-Datentyp signedData definiert ein Message-Format für signierte Daten. EineSignatur ist dabei ein verschlüsselter „digest“, wobei es sich beim „digest“ um einen Hashwertder Nutzdaten handelt. Der zu verwendete Hash-Algorithmus1 ist nicht vorgegeben.

Der Inhalt des content-Feldes beim Datentyp signedData hat die folgende ASN.1-Struktur:

SignedData ::= SEQUENCE { version Version, digestAlgorithms DigestAlgorithmIdentifiers, contentInfo ContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos}

Auffällig ist hier, dass diese ASN.1-Struktur ein Feld contentInfo und somit eine PKCS#7-Meldung enthält. Der Grund dafür ist, dass somit mehrere PKCS#7-Meldungen einfachgeschachtelt und dadurch unterschiedliche PKCS#7-Datentypen kombiniert werden können.

1 mögliche Hash-Verfahren sind z.B. MD5 oder SHA1



Die einzelnen Felder sollen nun kurz erläutert werden:Feldname Beschreibung

version Versionsnummer des PKCS#7-Standards. Der aktuelle Standard trägt die Version1.

digestAlgorithms Dieses Feld besteht aus einer Liste von „digest“-Algorithmen, die beim Erstellender Signaturen verwendet wurden. Normalerweise beinhaltet eine signedData-Message nur eine Signatur eines einzigen Unterzeichners. In einem solchen Fallbeinhaltet das Feld digestAlgorithms auch nur den für die Signatur verwendeten„digest“-Algorithmus. Mögliche Algorithmen sind beispielsweise MD5 oder SHA1.

contentInfo Dieses Feld beinhaltet die Daten, welche signiert werden. Diese Daten können vonirgend einem PKCS#7-Datentyp sein. Eine Signatur wird über den Inhalt desFeldes content in diesem Feld erstellt.

certificates Dieses Feld ist optional und enthält PKCS#6 oder X.509-Zertifikate, diemöglicherweise zur Verifizierung der Signaturen benötigt werden. Was fürZertifikate dieses Feld enthalten muss, ist im Standard nicht vorgegeben.

crls Auch dieses Feld ist optional und enthält CRLs, die möglicherweise ungültigeZertifikate des Feldes certificates bestimmen.

signerInfos Dieses Feld ist ein SET von SignerInfos. Ein einzelnes SignerInfo beinhaltet eineSignatur eines Unterzeichners und weitere Informationen. Details zu diesem Typund deren Felder sind nachfolgend erläutert.

Tabelle 4 Felder des PKCS#7-Datentyps signedData

Der Typ SignerInfo hat folgende ASN.1-Struktur:SignerInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, digestAlgorithm DigestAlgorithmIdentifier, authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, encryptedDigest EncryptedDigest, unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL }



Felder des Typs SignerInfo:Feldname Beschreibung

version Versionsnummer des PKCS#7-Standards. Der aktuelle Standard trägt die Version1.

issuerAndSerialNumber Wie der Name vermuten lässt, beinhaltet dieses Feld den „Distinguished Name“,sowie die Zertifikats-Seriennummer des Unterzeichners. Anhand dieser Angabenist es dem Empfänger möglich, das entsprechende Zertifikat zu bestimmen unddaraus den Public-Key zur Überprüfung der Signatur zu erhalten.

digestAlgorithm Definiert den verwendeten „digest“-Algorithmus bei der Berechnung der Signatur.Dieser Algorithmus sollte einem der Algorithmen aus dem Feld digestAlgorithmsentsprechen.

authenticatedAttributes Dieses Feld ist optional und beinhaltet ein SET von Attributen, welche signiert(authenticated) sind. Hat das Feld contentType im Feld contentInfo nicht denTyp data, muss dieses Feld vorhanden sein und mindestens folgende zwei Felderenthalten:- ein PKCS#9 content-type Attribut, welches den selben Inhaltstyp des FeldescontentType im Feld contentInfo enthält.- ein PKCS#9 message-digest Attribut, welches den „digest“ der Daten enthält

SCEP nutzt dieses Feld, um darin beispielsweise die Transaction-ID oder den PKI-Status als Attribute zu kodieren.

digestEncryptionAlgorithm Beinhaltet den Algorithmus (z.B. RSA), welcher zur Verschlüsselung des „digest“durch den Unterzeichner verwendet wurde.

encryptedDigest Dieses Feld beinhaltet den verschlüsselten „digest“ in binärer Form. Der Ablauf derGenerierung des „digest“ und anschliessender Verschlüsselung, genauer dieErstellung der Signatur, ist nachfolgend genauer beschrieben.

unauthenticatedAttributes Dieses Feld ist optional und beinhaltet ein SET von Attributen, welche nicht signiert(unauthenticated) sind. Attribute in diesem Feld sind nicht durch eine Signatur vorVeränderung geschützt.SCEP macht keinen Gebrauch von diesem Feld.

Tabelle 5 SignerInfo-Typ des PKCS#7-Datentyps signedData



5.5.2.1 Erstellung der Signatur

Eine Signatur im PKCS#7-Datentyp signedData wird im Feld encryptedDigest kodiert. DerAblauf, wie eine solche Signatur gebildet wird, ist nachfolgend grob beschrieben1:

1. Generierung des Hashwertes über die eigentlichen Daten im Feld content des contentInfo-Feldes. Der Hashwert wird dabei mit dem „digest“-Algorithmus erstellt, welcher im FelddigestAlgorithm angegeben ist. Wir nennen den berechneten Hashwert digest1.

2. Falls das Feld authenticatedAttributes vorhanden ist oder vorhanden sein muss2, wirdein PKCS#9 message-digest Attribut zu den authenticatedAttributes hinzugefügt,welches als Wert den in Schritt 1 berechneten digest1 beinhaltet.

3. Falls das Feld authenticatedAttributes vorhanden ist, wird der Hashwert dieses Feldesberechnet. Auch hier wird wieder der gleiche Algorithmus, wie in Schritt 1 verwendet. Denerhaltenen Hashwert nennen wir digest2.

4. Mit dem privaten Key und dem Algorithmus, der im Feld digestEncryptionAlgorithmangegeben ist, wird nun die Signatur erstellt:

• Ist kein authenticatedAttributes-Feld vorhanden, wird der im Schritt 1 berechnete„digest“ digest1 zusammen mit dem „digest“-Algorithmus in eine ASN.1-Strukturgepackt, DER-kodiert und danach mit dem privaten Schlüssel verschlüsselt.

• Ist das authenticatedAttributes-Feld vorhanden, wird der im Schritt 3 berechnete„digest“ digest2 zusammen mit dem „digest“-Algorithmus in eine ASN.1-Strukturgepackt, DER-kodiert und danach mit dem privaten Schlüssel verschlüsselt.

5. Der Verschlüsselte „digest“ aus Schritt 4 wird nun ins Feld encryptedDigest geschrieben.

1 Für Details sei auf den PKCS#7-Standard [PKCS7v1.5] verwiesen2 Hat das Feld contentType im Feld contentInfo nicht den Typ data, muss dieses Feld vorhanden sein



5.5.3 Datentyp envelopedData

Der PKCS#7-Datentyp envelopedData definiert ein Message-Format für verschlüsselte Daten.Der zu verwendende Verschlüsselungs-Algorithmus ist nicht vorgegeben.

Der Inhalt des content-Feldes beim Datentyp envelopedData hat die folgende ASN.1-Struktur:EnvelopedData ::= SEQUENCE { version Version, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo}

Die einzelnen Felder sollen nun kurz erläutert werden:Feldname Beschreibung

version Versionsnummer des PKCS#7-Standards. Der aktuelle Standard ist in der Version1.

recipientInfos Ist ein SET mit Werten vom Typ RecipientInfo (siehe weiter unten), wobeimindestens ein Eintrag enthalten ist, sprich mindestens ein Empfänger, fürwelcher die verschlüsselte Nachricht bestimmt ist.

encryptedContentInfo Enthält Angaben zum verschlüsselten Inhalt und den verschlüsselten Inhalt selbst.

Tabelle 6 Felder des PKCS#7-Datentyps envelopedData

Die beiden Felder recipientInfos und encryptedContentInfo werden nachfolgend genauerbetrachtet.

Wie bereits erwähnt handelt es sich beim Feld recipientInfos um ein SET mit Werten vomTyp RecipientInfo. Ein solches RecipientInfo enthält die notwendigen Angaben, welcher einEmpfänger der verschlüsselten Nachricht benötigt, um an den Schlüssel zu gelangen, der fürdie Entschlüsselung des verschlüsselten Inhalts notwendig ist. RecipientInfo hat folgendeASN.1-Struktur:RecipientInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey}



Die entsprechenden Felder haben folgende Bedeutung:Feldname Beschreibung

version Versionsnummer des PKCS#7-Standards. Der aktuelle Standard ist in der Version1.

issuerAndSerialNumber Wie der Name vermuten lässt, beinhaltet dieses Feld den „Distinguished Name“,sowie die Zertifikats-Seriennummer des Empfängers. Anhand dieser Angaben istes dem Empfänger möglich, zu bestimmen, ob das RecipientInfo-Feld für ihnbestimmt ist und er den notwendigen Private-Key zum entsprechenden Zertifikatbesitzt.

keyEncryptionAlgorithm Beinhaltet den Algorithmus (z.B. RSA), welcher zur Entschlüsselung des Schlüsselsfür die Inhaltsentschlüsselung verwendet werden muss. Dieser Algorithmus mussder Empfänger auf dem nächsten Feld encryptedKey anwenden. Damit er dies tunkann, muss er jedoch im Besitz des richtigen Private-Keys sein.

encryptedKey Enthält den verschlüsselten Entschlüsselungs-Schlüssel mit welchem anschliessendder verschlüsselte Dateninhalt der PKCS#7-Message entschlüsselt werden kann.

Tabelle 7 RecipientInfo-Typ des PKCS#7-Datentyps envelopedData

Das Feld encryptedContentInfo beinhaltet unter anderem die verschlüsselten Daten, sowieInformationen, die für deren Entschlüsselung notwendig sind. Die ASN.1-Struktur dieses FeldesencryptedContentInfo sieht folgendermassen aus:EncryptedContentInfo ::= SEQUENCE { contentType ContentType, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL}

Die Felder haben folgende Bedeutung:Feldname Beschreibung

contentType PKCS#7-Datentyp der verschlüsselten Daten. Die Daten können von irgend einemPKCS#7-Datentyp sein.

contentEncryptionAlgorithm Algorithmus, mit welchem die Daten verschlüsselt wurden und gegebenenfallsnotwendige Parameter (z.B. Initialisierungsvektor), die zur Entschlüsselungbenötigt werden. Hier verwendete Algorithmen sind beispielsweise DES oder 3DES.

encryptedContent Beinhaltet die verschlüsselten Daten als OCTET STRING.

Tabelle 8 encryptedContentInfo-Typ des PKCS#7-Datentyps envelopedData



5.6 Simple Certificate Enrollment ProtocolDas „Simple Certificate Enrollment Protokoll“ [SCEPv11] ist ein Protokoll zum sicherenVerteilen von Client-Zertifikaten. Dabei ergibt sich grob der folgende Ablauf:

1. Ein Client, oft ein VPN-Gateway oder ähnliches, generiert ein Schlüsselpaar. SCEP verlangthier als Verfahren die RSA-Verschlüsselung, wobei jedoch auch andere denkbar sind.

2. Der Client sendet den Public-Key des generierten Schlüsselpaars zusammen mit Angaben zuseiner Identität wie beispielsweise seinen Namen, seine E-Mail-Adresse, etc. als Zertifikats-Request an den SCEP-Server.

3. Der Server überprüft die Authentizität des Clients und erstellt ein von der CA1

unterschriebenes Zertifikat.

4. Das von der CA unterschriebene Zertifikat wird an den Client zurückgesendet.

Die Interaktion zwischen SCEP-Client und SCEP-Server ist in folgender Abbildung visualisiert:

Abbildung 4 Vereinfachter Ablauf eines Zertifikat-Requests mit SCEP

Die Kommunikation zwischen Client und Server erfolgt über HTTP. Zur Sicherstellung vonIntegrität und Vertraulichkeit sind die übertragenen Daten in PKCS#7-Messages verpackt(Details zu PKCS#7 siehe 5.5).

1 Die Bezeichnung CA und SCEP-Server wird nachfolgend gleichbedeutend verwendet. Es wird angenommen, dassder SCEP-Server zugleich die Rolle als CA inne hat.


Zertifikats-Requesterstellen

CA-Zertifikat beziehen

Schlüsselpaar generieren

Request verschlüsselnund signieren

CA-Zertifikat bereitstellen

Request überprüfen

und entschlüsseln

Response erstellen

SCEP-Client SCEP-Server

Response verschlüsselnund signieren

Private-KeyUnter-

schriebenes Zertifikat

Request

ResponseResponse

überprüfenund entschlüsseln


Die einzelnen Interaktionen aus obiger Abbildung werden in den Abschnitten 5.6.2 bis 5.6.9genauer beschrieben. Zusätzliche Details sind dem Dokument „Software-Design“ und natürlichdem SCEP-Draft zu entnehmen.

5.6.1 Manual vs. automatic Mode

Bevor der Server ein Zertifikat ausstellt, muss er die Authentizität des Requests sicherstellen.dies kann durch einbeziehen eines „challenge password“ geschehen.

Wenn der Server genügend Informationen hat und den Request für gültig hält, kann er dasZertifikat im „automatic mode“ ohne weitere Interaktion zurück liefern.

Abbildung 5 Zertifikatsbezug im "automatic mode"

Benötigt der Server allerdings weitere Informationen für die Authentisierung, so schaltet er inden „manual mode“.

Abbildung 6 Zertifikatsbezug im "manual mode"

Im „manual mode“ wird nicht direkt ein Zertifikat ausgeliefert, sondern der Client wirdinformiert, dass erst die Authentisierung manuell erfolgen muss. Der Client kann nunkontinuierlich abfragen, ob die Authentisierung stattgefunden hat. Sobald dies geschehen ist,erhält der Client auf seine Anfrage das Zertifikat. Für eine manuelle Authentisierung ist dasVergleichen des Fingerprints über Telefon denkbar.



5.6.2 CA-Zertifikat beziehen

SCEP ist ein Protokoll zum sicheren Verteilen von Client-Zertifikaten. Damit jedoch der Clientein Zertifikat beim SCEP-Server beantragen kann, muss er im Besitz des CA-Zertifikates sein.Er braucht dieses, um später seinen eigenen Request verschlüsseln zu können.

SCEP bietet neben dem Verteilen von Client-Zertifikaten auch die Funktion, CA-Zertifikate beimSCEP-Server zu beziehen. Dazu wird ein HTTP-Request an den SCEP-Server gesendet,woraufhin dieser sein oder seine CA-Zertifikate im HTTP-Reply zurücksendet. Im Gegensatz zueinem normalen Zertifikats-Request über SCEP ist diese Übertragung nicht gesichert underfolgt im Klartext.

Der Ablauf beim Beziehen des CA-Zertifikates kann folgendermassen visualisiert werden:

Abbildung 7 Bezug der CA-Zertifikate über SCEP

Besitzt der SCEP-Server nur ein CA-Zertifikat, wird dieses als DER-kodiertes X.509-Zertifikatim HTTP-Reply zurückgesendet. Falls der Server mehrere CA-Zertifikate besitzt, werden diesegepackt in einer abgeänderten PKCS#7-Message im HTTP-Reply zurückgesendet. Dies istbeispielsweise bei einer Windows CA der Fall, bei welcher unterschiedliche CA-Zertifikate fürVerschlüsselung und Signierung eingesetzt werden. Details zum Format der übertragenen CA-Zertifikate können dem SCEP-Draft [SCEPv11] entnommen werden.

Für die Sicherheit der nun folgenden Zertifikats-Request und somit des ganzen Protokolls ist esunabdingbar, dass die bezogenen CA-Zertifikate vertrauenswürdig sind. SCEP bietet hierfürkeinen automatischen Mechanismus. Eine manuelle Prüfung des Fingerprints jedes CA-Zertifikates z.B. über Telefon ist deshalb erforderlich. Nur mit einer solchen manuellen Prüfungkann sichergestellt werden, dass mit dem korrekten CA-Zertifikat gearbeitet wird.



5.6.3 Schlüsselpaar generieren

Damit der Client ein eigenen Zertifikats-Request erstellen kann, muss er lokal im Besitz einesSchlüsselpaars sein. Besitzt er noch kein solches Schlüsselpaar, muss er dieses generieren undabspeichern. Den Private-Key behält er dabei immer für sich, den Public-Key sendet er späterals Teil seines Zertifikats-Request an den Server. Wie bereits erwähnt ist als Verschlüsselungs-Verfahren lediglich RSA vorgeschrieben. Dabei wird für eine genügende Sicherheit eine RSA-Schlüssellänge von mindestens 1024 Bit empfohlen.

Der generierte Schlüssel wird abgespeichert, so dass er später für kryptographische Verfahrenzusammen mit dem erhaltenen Zertifikat verwendet werden kann.

5.6.4 Zertifikats-Request erstellen

Nun wird mit dem Schlüsselpaar ein Zertifikats-Request erstellt. Dieser wird imstandardisierten PKCS#10-Format kodiert (für Details zu PKCS#10 siehe 5.4). DieserPKCS#10-Request nennt sich im SCEP-Draft pkcsCertReq. Der entsprechende ASN.1-Syntaxim SCEP-Draft sieht folgendermassen aus:

pkcsCertReq CertificationRequest ::= { -- PKCS#10 version 0 subject "the requester's subject name" subjectPublicKeyInfo { algorithm {pkcs-1 1} -- Algorithmus für Public-Key (RSA) subjectPublicKey "Kodierter Public-Key" } attributes { challengePassword {{pkcs-9 7} "Passwort" } extensions –- Extensions, welche ins Zertifikat fliessen sollen } signatureAlgorithm {pkcs-1 4} –- Algorithmus für Signatur (z.B. MD5RSA) signature "Signatur über pkcsCertReq ohne signatureAlgorithm" }

Dieser PKCS#10-Request enthält den Namen des Requesters als „Distinguished Name“, seinePublic-Key Informationen, sowie zusätzliche Attribute wie beispielsweise ein „challengepassword“ oder gewünschte X.509v3-Erweiterungen. Diese ganzen Informationen sind durcheine Signatur geschützt, die mit dem Private-Key des Requesters erstellt wurde.

Das „challenge password“ kann zum einen für das automatische Verteilen eines Zertifikats (als„preshared secret“) und zum anderen zur Widerrufung eines bestehenden Client-Zertifikatseingesetzt werden. Details dazu können dem PKCS#10-Standard [PKCS10v1.7] entnommenwerden.

Für Benutzer, die mit dem openssl-Tool vertraut sind, kommt dieser Schritt sicher bekanntvor. Auch bei openssl wird zum Erzeugen eines Zertifikats zuerst ein Zertifikats-Request imPKCS#10-Format erstellt und daraufhin mit diesem ein Zertifikat generiert. Eigentlich könnteman nun diesen PKCS#10-Request an eine CA senden, welche anhand dieses Requests einZertifikat ausstellt und zurücksendet. SCEP ist jedoch so konzipiert, dass die Daten desPKCS#10-Request, auch wenn diese keine privaten Schlüssel beinhaltet, von keinem Drittenweder eingesehen noch modifiziert werden können. Wie dies sichergestellt wird, ist in dennächsten Schritten erläutert.



5.6.5 Request verschlüsseln und signieren

Damit der PKCS#10-Request weder eingesehen noch modifiziert werden kann, wird dieser zurÜbertragung kryptographisch gesichert. Dies geschieht durch eine doppelte Einbettung desPKCS#10-Requests in das PKCS#7-Format (für Details zum PKCS#7-Format siehe 5.5):

Als erstes wird der PKCS#10-Request, im SCEP-Draft mit pkcsCertReq bezeichnet, mit einerhybriden Verschlüsselung verschlüsselt. Daraus entsteht eine PKCS#7-Message vom TypenvelopedData, welche sich im SCEP-Draft pkcsCertReqEnvelope nennt. Ist dies geschehen,wird in einer zweiten Phase die PKCS#7-Message in eine weitere PKCS#7-Message gepacktund signiert, woraus eine PKCS#7-Message vom Typ signedData entsteht, die im SCEP-DraftpkcsCertReqSigned genannt wird. Diese Signierung erfolgt mit einem selbst signiertenZertifikat, wobei der entsprechende „Distinguished Name“ mit dem „Distinguished Name“ imPKCS#10-Request übereinstimmen muss.

Zur Übertragung wird eine PKI-Message erstellt, welche eine Beschreibung des Inhalts sowieden Inhalt gemäss PKCS#7 enthält:

pkcsReq PKIMessage ::= { contentType {pkcs-7 2} content pkcsCertReqSigned }

pkcsCertReqSigned beinhaltet Informationen über den Signatur-Ersteller, die so genanntenSignerInfos. Wiederum darin sind optional authenticateAttributes vorhanden (siehe 5.5).Das SCEP-Protokoll verwendet diese, um weitere Informationen in den Request einzubeziehen.

pkcsCertReqSigned { ... SignerInfo { authenticateAttributes { ... transaction-id {{id-attributes transId(7)} "printable string"} messageType {{id-attributes messageType(2)} "PKCSReq"} senderNonce {{id-attributes senderNonce(5)} <16 Bytes>} ... } ...}

Ein solches Attribut ist dabei immer eine ASN.1-Sequenz: Darin enthalten ist eine OID für dieBeschreibung des Attributs sowie der eigentlich Inhalt des entsprechenden Attributs.

SCEP nutzt dieses Feld authenticateAttributes um transaktionsspezifische Informationen anden SCEP-Server zu übertragen. Folgende Attribute müssen dabei in einem SCEP-Requestenthalten sein:



OID Inhalt

transaction-id Das Attribut vom Typ transaction-id enthält eine eindeutige Identitätskennung derTransaktion. Das SCEP-Draft sieht hier vor, dass dafür irgend eine Hash-Funktion aufden Public-Key angewendet wird. So wird automatisch für einen entsprechenden Keyimmer dieselbe transaction-id verwendet. Weitere Details dazu können demDokument „Software-Design“ entnommen werden.

MessageType In diesem Feld wird der Typ der SCEP-Message als ASN.1 PRINTABLE STRING kodiert.In diesem Falle wird der String „19“ verwendet, welcher für „PKCSReq“ steht.

senderNonce Hier wird eine Zufallszahl als ASN.1 PRINTABLE STRING kodiert, welche vor ReplayAttacken schützt.

Tabelle 9 Attribute eines SCEP-Requests

5.6.6 Request absetzen

Der Client kann nun die SCEP-Anfrage über HTTP an den SCEP-Server senden. Dabei kommtHTTP GET oder optional HTTP POST zum Einsatz. Es muss eine Operation angegeben werden,welche mit den angehängten Daten erfolgen soll. Diese operation heisst für die Anforderungeines Zertifikates PKIOperation.

Bei der Verwendung von GET werden die DER-kodierten Daten, im SCEP-Draft pkcsReqgenannt, zusätzlich base64-kodiert an die URL gehängt:

GET /cgi-bin/pkiclient.exe?operation=PKIOperation&message=BASE64PKCSREQ

Bei der Verwendung von POST werden die Daten binär, d.h. nur DER-kodiert, im Body desRequests übertragen:

POST /cgi-bin/pkiclient.exe?operation=PKIOperation<binär kodierter pkcsReq>

Der Reply des HTTP-Requests ist die vom SCEP-Server erstellte DER-kodierte Response. Wiediese Response aussieht ist unter 5.6.9 beschrieben.

5.6.7 Request überprüfen und entschlüsseln

Die CA kann die Signatur des Requests prüfen. Der Client besitzt in der Regel kein gültigesZertifikat und kann somit den Request nur „selfsigned“ unterschreiben. Somit kann dieAuthentizität nicht automatisch sichergestellt werden. Ist dies allerdings über ein „challengepassword“ möglich, so kann die Ausstellung des Zertifikates erfolgen. Ist dies nicht der Fall,muss die Authentizität manuell sichergestellt werden.

5.6.8 Response erstellen

Ist der Request akzeptiert worden, so erstellt der SCEP-Server ein komplettes X.509-Zertifikataus den Angaben des Requests sowie den gegebenen Policies und unterschreibt dies mit demprivaten Schlüssel der CA.



5.6.9 Response verschlüsseln und signieren

Der Server erstellt nun für den Client eine Antwort. Auf einen SCEP-Request gibt es dreimögliche Antworten:

Status Beschreibung

PENDING Der Request wartet auf manuelle Authentisierung (Manual Mode)

FAILURE Der Request ist fehlgeschlagen

SUCCESS Der Request war erfolgreich, das Zertifikat ist angehängt

Tabelle 10 Mögliche Antworten auf einen SCEP-Request

Bei jedem Meldungstyp handelt es sich um eine PKCS#7-Message vom Typ signedData, dievon der CA unterschrieben wurden:

CertRep PKIMessage ::= { contentType {pkcs-7 2} content CertRepSigned }

Ähnlich wie beim pkcsCertReqSigned des vom Client abgesetzten Request sind in denCertRepSigned-Daten weitere Informationen im AuthenticateAttributes des SignerInfoenthalten:

CertRepSigned { ... SignerInfo { authenticateAttributes { ... messageType {{id-attribute messageType(0)} "CertRep"} transaction-id {{id-attributes transid(7)} "printablestring"} pkiStatus {{id-attributes pkiStatus(3)} "PENDING/FAILURE/SUCCESS"} failInfo {{id-attributes failInfo(4)} "Grund für FAILURE"} recipientNonce {{id-attributes recipientNonce(6)} <16 bytes>} senderNonce {{id-attributes senderNonce(5)} <16 bytes>} ... } ...}

Auch hier ist jedes Attribut wieder eine Sequenz aus der OID als Attributsbezeichnung und denAttribut-Daten.

OID Inhalt

MessageType In diesem Feld wird der MessageType als Printable-String kodiert. In diesem Falle wirdder String „3“ verwendet, welcher für „CertRep“ steht.

transaction-id Enthält dieselbe transaction-id, welche für im Request mitgegeben wurde.

pkiStatus Eine der drei erwähnten Statusbeschreibungen (PENDING, SUCCESS, FAILURE)

failInfo Ist nur bei pkiStatus == FAILURE vorhanden. Beschreibt die Art des Fehlers.

recipientNonce Enthält die senderNonce des Clients vom Request.

senderNonce Als printable string kodierte Zufallszahl, welche vor Replay Attacken schützt.

Tabelle 11 Attribute eines SCEP-Replys

Handelt es sich um eine Message mit pkiStatus == SUCCESS, so enthält das



pkcsCertRepSigned als Content ein pkcsCertRepEnvelope. Diese PKCS#7-Message enthältwiederum ein pkcsCertRep, welches eine Liste von Zertifikaten enthält. Das erste ist dasAngeforderte Zertifikat, optional gefolgt von Zertifikaten der ganzen Zertifikatskette:

pkcsCertRep SignedData ::= { -- PKCS#7 version 1 digestAlgorithm contentInfo { -- leerer Content, Zertifikate separat angehängt contentType {pkcs-7 1} } certificates { certificate – X.509-Zertifikat, welches angefordert wurde certificate –- Optionale weitere Zeritifkate der Zertifikatskette } }

5.6.9.1 Verschlüsseln der Daten

Die Verschlüsselten Daten im PKCS#7-Datentyp envelopedData werden im FeldencryptedContent kodiert. Der Ablauf, wie diese Daten verschlüsselt und die entsprechendePKCS#7-Message erstellt wird, ist nachfolgend grob beschrieben1:

1. Der Input für den Verschlüsselungs-Prozess sind die eigentlichen Daten DER-kodiert ohneAngabe von Typ und Länge, namentlich der Inhalt des Feldes content eines contentInfo-Feldes.

2. Abhängig vom verwendeten Algorithmus müssen die Daten am Ende mit so genannten„Padding-Bytes“ aufgefüllt werden. Bei DES beispielsweise muss die Länge der Daten einvielfaches von 8 Byte betragen. Die Bytes, die gepaddet werden haben alle den Hex-Wertder Anzahl Padding-Bytes. Beispiel:

• 0x01, falls ein Byte „gepaddet“ wird

• 0x02, falls zwei Byte „gepaddet“ werden

• usw.

Damit immer mindestens ein Padding-Byte vorhanden ist, werden bei Daten, welche genauein vielfaches von 8 Byte Länge haben, 8 Bytes mit dem Wert 0x08 „gepaddet“.

3. Die „gepaddeten“ Daten werden mit dem entsprechenden Algorithmus verschlüsselt. Dienotwendigen Parameter (z.B. der IV bei der DES-Verschlüsselung), werden im FeldcontentEncryptionAlgorithm kodiert.

4. Der zur Verschlüsselung verwendete Schlüssel wird nun für jeden Empfänger mit dementsprechenden Public-Keys des einzelnen Empfängers verschlüsselt und in dessenencryptedKey-Feld kodiert.

5. Die PKCS#7-Message kann nun zusammengestellt werden.

1 Für Details sei auf den PKCS#7-Standard [PKCS7v1.5] verwiesen



5.6.10 Beispiel-Message

Zur Anschauung wird nun eine PKCS#7-Message vom Typ signedData genauer untersucht. Beider entsprechenden Message handelt es sich um eine SCEP-Reply auf eine Zertifikatsanfrage.Die Message ist DER-kodiert. Es wird davon ausgegangen, dass der Leser mit der DER-Kodierung vertraut ist.

Hex-Dump Feldname Beschreibung

30 82 07 e4 Beginn Feld vom TypContentInfo

Äusserster ContentInfo.

06 09 2a 86 48 86 f7 0d 01 07 02

ContentType OID des PKCS#7-Datentyps. 02 am Ende steht fürsignedData.

a0 82 07 d5 Beginn Feld content Beginn des contents vom Typ signedData.

30 82 07 d1 Beginn Feld vom TypSignedData

Beginn der signedData-Message.

02 01 01 version Versionsnummer von PKCS#7 = 1.

31 0e 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00

digestAlgorithms Angaben der verwendeten „digest“-Algorithmus alsFeld vom Typ Attribute. Hier ist nur ein Algorithmusangegeben, nämlich MD5. Da MD5 keinezusätzlichen Parameter benötigt, hat der Parameterden Wert NULL.

30 82 05 fa Beginn des inneren Feldesvom Typ ContentInfo

Das innere ContentInfo-Feld beinhaltet dieeigentlichen Daten, die signiert werden.

06 09 2a 86 48 86 f7 0d 01 07 01

ContentType Die Daten des inneren ContentInfo-Feldes sindvom PKCS#7-Typ data.

a0 82 05 eb 04 82 05 e7 ...21 01 85 ed

content Daten vom Typ data. Unter anderem wird dieSignatur über diese Daten erstellt.

31 82 01 bc Beginn Feld vom TypSignerInfos

SET mit den einzelnen Signaturen, welche im TypSignerInfo enthalten sind.

30 82 01 b8 Beginn Feld vom TypSignerInfo

02 01 01 version Versionsnummer von PKCS#7 = 1.

30 49 30 3b 31 12 30 10...00 00 00 03

issuerAndSerialNumber Seriennummer und DN des Unterzeichnenden. MitHilfe dieses Feldes kann das Zertifikat desUnterzeichnenden festgestellt werden.

30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00

digestAlgorithm Angaben des verwendeten „digest“-Algorithmus alsFeld vom Typ Attribute. Auch hier ist MD5 alsAlgorithmus angegeben.

a0 81 c7 Beginn FeldauthenticatedAttributes

Obwohl der Datentyp des inneren ContentInfo-Feldes data ist, enthält diese PKCS#7-Message dasauthenticatedAttributes-Feld.

30 11 06 0a 60 86 48 01...01 09 03 31 03 13 01 30

Attribut vom Typ Attribute SCEP-spezifische authenticationAttributes,beispielsweise die Transaction-ID oder den PKI-Status.

30 18 06 09 2a 86 48 86f7 0d 01 09 03 31 0b 0609 2a 86 48 86 f7 0d 0107 01

PKCS#9 content-type Attribut Angabe des Inhaltstyps des inneren ContentInfo-Feldes. Hier ist die OID für den PKCS#7-Typ datakodiert.

30 1f 06 09 2a 86 48 86f7 0d 01 09 04 31 12 0410 15 75 91 16 9a a6 d4ec 6f 47 84 98 ba be 8bba

PKCS#9 message-digestAttribut

Hash über den Inhalt im inneren ContentInfo-Feldmit dem MD5-Algorithmus.Aus diesem Hex-Dump ist ersichtlich, dass einMD5-Hash die Länge von 16 Byte hat (Dump 04 10...).



Hex-Dump Feldname Beschreibung

30 20 06 0a 60 86 48 01...63 36 36 34 37 64 37 38

Attribut vom Typ Attribute Weitere SCEP-SpezifischeauthenticationAttributes.

30 0d 06 09 2a 86 48 86f7 0d 01 01 01 05 00

digestEncryptionAlgorithm AlgorithmIdentifier des verwendetenVerschlüsselungs-Algorithmus bei der Signatur-Generierung. Hier ist die OID für den RSA-Algorithmus kodiert.

04 81 80 73 8e 9f 65 bb...70 c6 3a 6f ec 9d 25 bc

encryptedDigest Verschlüsselter „digest“ des komplettenauthenticatdAttributes-Feldes. Die Länge dieserSignatur ist 128 Byte. Daraus kann geschlossenwerden, dass der Public-Key des Unterzeichnerseine Grösse von 1024 Bit hat.

Tabelle 12 DER-kodierte PKCS#7-Message

Es fällt auf, dass bei diesem SCEP-Reply keine Zertifikate, CRLs und auch keine unsigniertenAttribute Teil der PKCS#7 signedData-Message sind. Dies ist so, weil das SCEP-Protokoll dieseFelder nicht vorschreibt.


Studienarbeit „SCEP für Linux strongSwan“ Software-Design

6 Software-Design

6.1 Prinzipieller AufbauDer scepclient stellt eine eigene Applikation dar, die Integration in strongSwan erfolgtvorerst über die Datei-Schnittstelle.

Der scepclient ist komplett in C geschrieben, weshalb das Design der Software nicht aufKlassen beruht. Die Funktionalitäten sind in Module gekapselt, die sich auf einzelne Filesabbilden.

Die folgende Abbildung zeigt den prinzipiellen Aufbau des scepclients:

Abbildung 8 Prinzipieller Aufbau des scepclients

Die in obiger Abbildung mit einer gestrichelten Linie umrandeten Bezeichnungen sind externeBibliotheken oder Module, auf die im scepclient zugegriffen wird:

– libgmp ist die „Gnome Multiprecision Library“ und stellt Funktionen für das Arbeiten mitgrossen Zahlen zur Verfügung. Im scepclient werden die Funktionen der libgmpbeispielsweise zur Berechnung der Primzahlen für die RSA-Verschlüsselung verwendet.

– libcurl erledigt die Abwicklung der Anfragen über das HTTP-Protokoll. Da das SCEP-Protokoll das HTTP-Protokoll nutzt, werden die einzelnen Requests mit Hilfe von libcurl anden SCEP-Server gesendet.

– Für den Grossteil der ASN.1-Parsefunktionen wird auf bereits existierenden strongSwan-Funktionen zurückgegriffen. Auch für allgemeine Aufgaben, wie beispielsweise die Debug-Ausgabe oder die „Leak-Detection“ werden bereits existierende strongSwan-Funktionenverwendet.


rsakey

pkcs1

libcurl

libgmp

http

util

pkcs10

pkcs7

x509

asn1 strongswan

crypto

main

scep


6.2 ModuleDie einzelnen Module des scepclients sind in nachfolgender Tabelle zusammengefasst.Anschliessend wird detailliert auf jedes einzelne Modul eingegangen.

Modul Funktionalität

asn1 - Funktionen zum Erstellen von DER-kodierten ASN.1-Strukturen- Funktionen zum Parsen von DER-kodierten ASN.1-Strukturen

crypto - Erstellen von MD5 Hashes- Verschlüsseln / Entschlüsseln mit RSA- Signaturen erstellen und überprüfen

http - Ausführen von Anfragen über das HTTP-Protokoll

pkcs1 - Erstellen des PKCS#1-Datenformates aus einem RSA-Schlüssel- Lesen von RSA-Schlüssel aus dem PKCS#1-Datenformat- Ein-/Ausgabe des PKCS#1-Datenformates

pkcs10 - Erstellen des PKCS#10-Datenformates aus einem RSA-Schlüssel und weiterenAngaben („Distinguished Name“, „challenge cassword“, etc.)- Ein-/Ausgabe des PKCS#10-Datenformates

pkcs7 - Verschlüsseln von Daten und packen ins PKCS#7-Datenformat envelopedData- Signieren von Daten und packen ins PKCS#7-Datenformat signedData- Parsen verschlüsselten Daten im PKCS#7-Datenformat envelopedData- Parsen signierten Daten im PKCS#7-Datenformat signedData- Ein-/Ausgabe des PKCS#7-Datenformates

rsakey - Generierung von RSA-Schlüsseln

scep - Funktionen zum Erstellen von SCEP-Requests- Funktionen zum Parsen von SCEP-Replys

util - Allgemeine Funktionen, z.B. Zur Anzeige von Hexwerten, für das Error-Handling,usw.

x509 - Überprüfung der Gültigkeit eines X.509-Zertifikates- Ausgabe des Zertifikates in Dateien- Erstellen eines selfsigned Zertifikates

main - Parsen der Kommandozeilen-Parameter- Ablaufsteuerung der Gesamtfunktionalität- Ausgabe der Hilfe

Tabelle 13 Module des scepclients



6.2.1 asn1

Das Modul asn1 beinhaltet Funktionen zum Erstellen und zum Parsen von DER-kodierten ASN.1Typen. Die meisten Funktionen sind mit Hilfe der Quellcode-Dokumentation leicht verständlichund müssen hier nicht weiter erklärt werden. Auf die Funktion asn1_wrap möchten wir jedochkurz eingehen, da diese in beinahe jedem Modul des scepclients zum Einsatz kommt undeine einfache Kodierung von DER-kodierten ASN.1-Strukturen erlaubt.

Um die Funktionsweise von asn1_wrap zu verstehen, stellen wir kurz die allgemeine DER-Kodierung von ASN.1-Datentypen vor. Die DER-Kodierung eines ASN.1 Datentyps siehtnormalerweise so aus, dass zuerst der ASN.1 Typ, danach die Länge des Inhalts und zumSchluss der eigentliche Dateninhalt kodiert wird. So kommt es, dass z.B. ein Integer mit demWert 17 folgendermassen DER-kodiert wird:

Abbildung 9 DER-kodierter ASN.1 Integer

Der ASN.1-Typ INTEGER wird als 0x02 kodiert, die Länge des Inhalts als 0x01 und den Inhaltselbst als 0x11, was dezimal dem Wert 17 entspricht. Das selbe Prinzip trifft auch bei ASN.1-Struktur-Typen, wie beispielsweise SET oder SEQUENCE zu. Eine Sequenz von zwei Integernmit den Werten 18 und 19 wird somit folgendermassen DER-kodiert:

Abbildung 10 DER-kodierte ASN.1 Sequenz

Der ASN.1-Typ SEQUENCE wird als 0x30 kodiert, die Länge des Inhalts als 0x06 und der Inhaltselbst ist die Aneinanderreihung der zwei DER-kodierten ASN.1-INTEGER.

Aus den obigen zwei Beispielen ist ersichtlich, dass es bei der DER-Kodierung eines ASN.1-Typs nicht darauf ankommt, ob es sich um einen Strukturtyp wie SEQUENCE oder um einenDatentyp wie INTEGER handelt: Die Kodierung besteht immer aus Typ, Länge und Inhalt.Die Funktion asn1_wrap nutzt diesen Umstand und erlaubt die Erstellung irgend eines ASN.1-Typs aus beliebig vielen Typen. Der Aufrufende muss dazu folgende Angaben machen:– Den gewünschten ASN.1 Typ– Die Anzahl Teile, aus denen der Typ besteht. In obigem Sequenz-Beispiel wären das 2

Stück.– Die zu verwendenden Teile vom Typ chunk_t

Das folgende Codebeispiel zeigt, wie man mit asn1_wrap einfach eine DER-kodierte ASN.1-Sequenz von zwei Integern erhält. Die jeweiligen Integer werden dabei mit der Funktionasn1_build_integer_from_uint erstellt:chunk_t integer1, integer2, sequenz;integer1 = asn1_build_integer_from_uint(18);integer2 = asn1_build_integer_from_uint(19);sequenz = asn1_wrap(ASN1_SEQUENCE,2,integer1,integer2);

In diesem Beispiel sieht man, dass asn1_wrap eine variable Anzahl von Parametern erlaubtund dadurch für diverse Aufgaben eingesetzt werden kann.


0x02 0x01 0x11

0x02 0x01 0x130x02 0x01 0x120x30 0x06


6.2.2 crypto

Im Modul crypto sind, wie der Name vermuten lässt, kryptographische Funktionen abgelegt.Es sind neben einer allgemeinen MD5-Digest-Funktion Routinen für RSA-Ver- und-Entschlüsselung auch Signier- und Verifizier-Funktionen für RSA enthalten.

6.2.2.1 crypto_rsa_encrypt

Die Funktion crypto_rsa_encrypt verschlüsselt Daten asymmetrisch mittels RSA. Esverwendet das im PKCS#1 beschrieben Verfahren, um Daten mit einem privaten RSA Schlüsselzu verschlüsseln. Die Daten können dabei nicht beliebig lange, sondern müssen ein paar Byteskürzer als die Schlüssellänge sein.

Als erstes müssen die gegebenen Daten auf die Länge des Schlüssels gepaddet werden. Diesgeschieht durch das Voranfügen von einem speziellen Bytemuster, gefolgt vonpseudozufälligen Bytes, wiederum gefolgt von einem Nullbyte:

0x01 0x02 || Padding || 0x00 || MeldungDas Padding ist genau so lange, sodass das komplette Bytemuster mit Meldung genau gleichlange ist wie der zu verwendende Schlüssel.

Nun wird das Bytemuster in einen Integer konvertiert. Dazu kommt die strongswan-Funktionn_to_mpz zum Einsatz. Sie konvertiert das Bytemuster in das Integer-Format der libgmp.

Im nächsten Schritt kommt eigentliche Verschlüsselung zum Einsatz, wie sie im PKCS#1-Standard beschrieben ist (RSAEP).

Der aus dieser Operation resultierende Integer wird wieder zurück in ein Bytemustergewandelt. Dies ist mit der Funktion mpz_to_n von strongswan möglich. Daraus entsteht daserwartete Chiffrat.

6.2.2.2 crypto_rsa_decrypt

Zur Entschlüsselung von RSA-Chiffraten kommt die Funktion crypto_rsa_decrypt zumEinsatz. Sie bildet exakt die gegenteilig Funktion zu crypto_rsa_encrypt und ermöglicht dasEntschlüsseln von RSA-Chiffraten mit einem privaten Schlüssel.

Dazu muss das Chiffrat als erstes wieder in ein Format gewandelt werden, in dem gerechnetwerden kann. Genau gleich wie in crypto_rsa_decrypt wird die Funktion n_to_mpzeingesetzt. Ist der Wert nun im libgmp-kompatiblen Format vorhanden, kann die eigentlicheEntschlüsselung durchgeführt werden.

Um zu entschlüsseln wird das im PKCS#1 beschriebene Verfahren (RSADP) angewendet,welches hier nicht genauer beschrieben wird.

Der resultierende Integer kann nun wieder in ein Bytemuster konvertiert werden, waswiederum mit der Funktion mpz_to_n erledigt wird.

Nun muss noch das Padding entfernt werden. Da dieses genau gleich aufgebaut ist, wie es incrypto_rsa_encrypt eingefügt wurde, ist dies nicht sehr schwierig:

0x01 0x02 || Padding || 0x00 || MeldungDie ersten beiden Bytes können verwendet werden, um zu Prüfen, ob die Entschlüsselungerfolgreich war. Anschliessend können alle Bytes bis und mit dem Nullbyte entfernt werden,woraus die ursprünglich verschlüsselte Meldung entsteht.



6.2.2.3 crypto_build_md5_rsa_signature

Die Funktion crypto_build_md5_rsa_signature erstellt eine Signatur über Daten, welche inDER-kodierte Zertifikate oder ähnliches eingebettet werden kann.

Für das Erstellen einer Signatur ist zuerst das generieren eines Digests nötig. Für SCEP ist MD5der Standard Hash-Algorithmus, weshalb dieser eingesetzt wird. Die Erstellung des Digestserfolgt über alle zu signierenden Daten mittels der Funktion crypto_compute_md5_digest.

Die Signatur hingegen wird nicht nur über den Digest erstellt! Es wird eine ASN.1-Sequenzgeneriert, welche die OID des Digest-Algorithmus sowie den Digest enthält. Es wird die ganzeSequenz mit der Funktion RSASP1 von PKCS#1 signiert. Die Um- und Rückwandlung zu undvon rechenbaren Integers erfolgt wiederum mit n_to_mpz bzw. mpz_to_n.

6.2.2.4 crypto_verify_md5_rsa_signature

In der Funktion crypto_verify_md5_rsa_signature wird eine Signatur überprüft, welche mitRSA und MD5 erstellt wurde.

Im das Überprüfen der Signatur zu ermöglichen, muss zuerst ein Digest über die Daten erstelltwerden. Dies geschieht mit MD5 mittels der Funktion crypto_compute_md5_digest. Nun mussdieser Digest gemäss PKCS#1 in einen Octet-String gepackt werden. Anschliessend wird dieserOctet-String zusammen mit der OID von MD5 in eine ASN.1-Sequenz gepackt. Danach wird diezu überprüfende Signatur mit dem in PKCS#1 beschriebenen Prozess RSAVP1 verschlüsseltund mit der Sequenz verglichen. Die Umwandlung von und zu Integern im mpz-Format erfolgtmit n_to_mpz bzw. mpz_to_n. Sind die Daten identisch, ist die Signatur gültig.



6.2.3 http

Das Modul http ist, wie der Name schon sagt, für die Kommunikation mit dem SCEP-Serverüber HTTP zuständig. Es beinhaltet die Funktion http_do_scep_request, über welche einSCEP-Request abgesetzt wird. Für die notwendige HTTP-Kommunikation wird auf dieFunktionen der libcurl-Bibliothek zugegriffen.

Die Funktion http_do_scep_request wird anschliessend genauer beschrieben. Dabei wirdauch kurz auf die verwendeten libcurl-Funktionen eingegangen.

6.2.3.1 http_do_scep_request

Die Funktion http_do_scep_request sendet einen SCEP-Request über das HTTP-Protokoll aneinen SCEP-Server und speichert die Antwort in einer Datei.

http_do_scep_request unterstützt folgende zwei SCEP-Operationen:

– PKI_OPERATION: Diese Operation wird verwendet, um ein Zertifikat anzufordern.

– GET_CA_CERT: Dieser Operation wird verwendet, um ein oder mehrere CA-Zertifikate zuerhalten.

Um die Funktionsweise von http_do_scep_request besser aufzuzeigen, ist die SCEP-Operationen PKI_OPERATION nachfolgend beschrieben und in einem Sequenzdiagrammdargestellt1. Auf die Funktionsweise von http_do_scep_request bei der Verwendung derOperation GET_CA_CERT wird nicht weiter eingegangen, da sich diese nur wenig zurPKI_OPERATION mit HTTP GET unterscheidet.

Bei der SCEP-Operation PKI_OPERATION wird ein SCEP-Request in Form einer PKCS#7-Message an den SCEP-Server gesendet. Dabei wird unterschieden, ob HTTP POST oder HTTPGET zur Übertragung verwendet wird:

– Im Falle von HTTP GET wird die entsprechende PKCS#7-Message in base64 kodiert undanschliessend als Parameter im HTTP GET-Request an den Server gesendet.

– Wird HTTP POST verwendet, wird die PKCS#7-Message binär im Body des Requests an denServer gesendet.

Um mit der libcurl-Bibliothek einen HTTP-Request durchzuführen, bietet diese die Funktioncurl_easy_perform. Die Einstellungen für den entsprechenden Request werden vor demcurl_easy_perform-Aufruf mit dem Befehl curl_easy_setopt gesetzt.

Im folgenden Sequenzdiagramm sieht man grob, was in der Funktion http_do_scep_requestabläuft, wenn ein SCEP-Request mit der Operation PKI_OPERATION durchgeführt wird. ImDiagramm sind auch die wichtigsten libcurl-Aufrufe ersichtlich.

1 Details zum SCEP-Protokoll können dem Dokument „Technologien“ entnommen werden.



Abbildung 11 Ablauf von http_do_scep_request mit PKI_OPERATION



6.2.4 pkcs1

Das Modul pkcs1 enthält ergänzende Funktionen zum Modul rsakey bzw. crypto, welche aberauf die DER-Codierung ausgelegt sind. So ist es mit den Funktionen möglich, aus einem RSA-Schlüssel DER-kodierte Bytefolgen zu erzeugen und umgekehrt.

6.2.4.1 pkcs1_build

Diese Funktion erstellt aus aus einem generierten RSA-Schlüssel (siehe Modul rsakey) eineDER-kodierte PKCS#1-Datenstruktur. Diese kann in diesem Format abgespeichert und wiedergeladen werden.

Die Struktur entspricht der Definition im PKCS#1-Standard und enthält eine Sequenz ausIntegern. Sie werden mit der Funktion asn1_build_integer_from_mpz aus dem mpz_t-Formatin DER kodiert.

6.2.4.2 pkcs1_get_rsa_key

pkcs1_get_rsa_key implementiert die gegenteilige Funktion von pkcs1_build. Durch sie kannvon einer eingelesenen DER-kodierten PKCS#1-Struktur ein RSA-Schlüssel erzeugt werden,mit welchem auch gängige Berechnungen mit der libgmp möglich sind.

Das Parsen erfolgt mit dem im strongSwan verwendeten Parser. Zusätzlich wird dieSchlüssellänge ermittelt, welche für später Operationen notwendig ist.



6.2.5 pkcs10

Das Modul pkcs10 beinhaltet Funktionen zum Erstellen von DER-kodierten PKCS#10-Requests.Wie man aus dem Dokument „Technologien“ entnehmen kann, handelt es sich beim PKCS#10-Format um einen Standard zur Zertifikatsanfrage bei einer Zertifizierungsstelle.

Neben einem „subject“ und einem Public-Key kann eine PKCS#10-Zertifikatsanfrage optionalzusätzliche Attribute enthalten, wie beispielsweise den Verwendungszweck des gefordertenZertifikats oder gewünschte „X.509v3 extended Attributes“.

Die wichtigsten Funktionen des Moduls pkcs10 und deren Aufbau werden nun genauer unterdie Lupe genommen. Für Fragen zum Syntax sei auf die entsprechende Quellcode-Dokumentation verwiesen.

6.2.5.1 pkcs10_build

Die Funktion pkcs10_build erstellt ein PKCS#10-Request der als Objekt vom Typ pkcs10_trepräsentiert wird. Dieses Objekt vom Typ pkcs10_t kann dann später mit der Funktionpkcs10_build_chunk in einen DER-kodierten Request umgewandelt oder mit der Funktionpkcs10_write_to_file in einer Datei gespeichert werden.

pkcs10_build beinhaltet selber keine grosse Funktionalität. Es nimmt die Parameter undkapselt diese in ein Objekt vom Typ pkcs10_t. Der Funktion muss mindestens das „subject“ inLDAP-Schreibweise und der entsprechenden RSA Schlüssels mitgegeben werden.

challenge_password und subject_alt_names sind optionale Parameter. Falls ein „challengepassword“ angegeben ist, wird dem PKCS#10-Request ein Attribut vom Typ „challengepassword“ hinzugefügt. Falls „subjectAltNames“ angegeben sind, werden diese als „ExtensionRequest“ in den PKCS#10-Request übernommen. Mehr Infos dazu können dem Dokument„Technologien“ entnommen werden.



6.2.5.2 pkcs10_build_chunk

Die Funktion pkcs10_build_chunk nimmt ein Objekt vom Typ pkcs10_t und erzeugt ausdiesem einen DER-kodierten PKCS#10-Request.

Dem Dokument „Technologien“ ist zu entnehmen, dass ein PKCS#10-Request als eine Sequenzmit den Feldern certificationRequestInfo, signatureAlgorithm und signaturestrukturiert ist.

In der Funktion pkcs10_build_chunk wird diese Sequenz zusammengebaut, die Kodierung derder Felder jedoch an andere Funktionen delegiert. So wird beispielsweise in der statischenFunktion pkcs10_build_certification_request_info das Feld certificationRequestInfokodiert.

Das folgende Sequenzdiagramm zeigt grob, wie die Funktion pkcs10_build_chunk aufgebautist:

Abbildung 12 Ablauf beim Aufruf von pkcs10_build_chunk



6.2.5.3 pkcs10_write_to_file

Die Funktion pkcs10_write_to_file nimmt ein Objekt vom Typ pkcs10_t, erzeugt aus diesemmit Hilfe der Funktion pkcs10_build_chunk einen DER-kodierten PKCS#10-Request undschreibt diesen anschliessend in eine Datei.

Wie die Funktion pkcs10_write_to_file eingesetzt werden kann, ist in folgendemSequenzdiagramm visualisiert:

Abbildung 13 Ablauf beim Aufruf von pkcs10_write_to_file



6.2.6 pkcs7

Das Modul pkcs7 enthält Funktionen zum Erstellen und zum Parsen von DER-kodiertenPKCS#7 Strukturen. SCEP verwendet die Schachtelung von Verschlüsselten PKCS#7-Envelopesin signierte PKCS#7 Daten. Deshalb wurden Funktionen zum verschlüsseln von Daten,signieren von Daten, verifizieren von signierten Daten, sowie das entschlüsseln von Datenmöglichst unabhängig implementiert.

6.2.6.1 pkcs7_encrypt_data

pkcs7_encrypt_data verschlüsselt beliebige Daten in einer PKCS#7-Envelope. Dazu werdendie Daten zuerst symmetrisch verschlüsselt (DES oder 3DES unterstützt). Zu den Daten wirdeine OID hinzugefügt, welche den Algorithmus beschreibt. Der Initialisierungsvektor wirdebenfalls angehängt.

Für jeden Empfänger werden Informationen (recipientInfo) erzeugt, mit Hilfe dessen derInhalt entschlüsselt werden kann. In unserem Falle ist nur ein Empfänger vorgesehen, nämlichdie CA. Der Schlüssel, welcher für die symmetrische Datenverschlüsselung verwendet wurde,wird asymmetrisch mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.

Abbildung 14 Verschlüsseln der Daten in pkcs7_encrypt_data

Da es sich bei DES um eine Blockverschlüsselung handelt, ist ein Padding der Datennotwendig. In unserem Fall ist die Blockgrösse immer acht Byte. Falls die Länge der Datenbereits ein vielfaches von acht Bytes ist, ist ein hinzufügen von weiteren acht Bytes zwingendnotwendig! Ansonsten funktioniert das entschlüsseln mit anderen Implementierungen nicht.

Für die symmetrische DES Verschlüsselung kommen die Routinen von strongSwan zumEinsatz. Im SCEP-Draft ist lediglich die Verwendung von DES vorgeschrieben. Da dieses abernicht mehr als sicher bezeichnet werden kann, wurde im scepclient zusätzlich 3DESimplementiert.

Die Verschlüsselung des DES-Schlüssels erfolgt mit RSA mit der Funktion crypto_rsa_encryptaus dem Modul crypto. Da die Länge des 3DES-Schlüssels 24 Byte beträgt, verlangt dieImplementierung eine RSA-Schlüssellänge von mindestens 512 Bit, um diese 24 Byteverschlüsseln zu können. Da aber ein kleinerer Schlüssel sowieso als völlig unsicher zubetrachten ist, stellt dies kein Problem dar.


Daten

Padding

Daten

IV

Algorithmus-OID

Empfänger-Info

DES-Schlüssel


6.2.6.2 pkcs7_sign

pkcs7_sign ist für das Signieren von Daten zuständig. Dazu können der Funktion bereitserstellte Authentisierungsdaten (AuthenticationAttribute) angegeben werden. Die Signaturwird somit nicht über die Daten selber erstellt, sondern wird lediglich über dieAuthentisierungsdaten. Deshalb muss die Integrität der Daten mit anderen Mittelngewährleistet werden (konkret über einen Digest in den Authentisierungsdaten).

Abbildung 15 Erstellen der Signatur in pkcs7_sign

In den Signierer-Informationen (singerInfo) wird die Kennung für das verwendete Zertifikatsowie die Signatur selber integriert. Für die Signatur wird ein MD5-Digest über dieAuthentisierungsdaten erstellt, welcher mit dem mitgegebenen RSA-Schlüssel verschlüsseltwird. Dazu kommt die Funktion crypto_build_md5_rsa_signature aus dem Modul cryptozum Einsatz.

6.2.6.3 pkcs7_parse_enveloped_data

Diese Funktion ermöglicht das entschlüsseln von Daten in einer PKCS#7-Envelope. Dazu wirdmit dem strongSwan ASN.1-Parser die Datenstruktur geparst und die benötigtenInformationen extrahiert. Die Entschlüsselung der Daten erfolgt im Prinzip umgekehrt wie dieVerschlüsselung der Funktion pkcs7_encrypt_data.

Es wird der asymmetrisch verschlüsselte DES-Schlüssel mit der Funktion crypto_rsa_decryptentschlüsselt. Der Schlüssel dazu wird der Funktion mitgegeben. Der Dateninhalt wird dann jenach gefundenem Algorithmus (DES oder 3DES) symmetrisch entschlüsselt undzurückgegeben.

6.2.6.4 pkcs7_parse_signed_data

pkcs7_parse_signed_data überprüft signierte Daten auf ihre Integrität und Authentizität. Siebildet das Gegenstück zu pkcs7_sign. Der ASN.1-Parser von strongSwan extrahiert diebenötigten Daten aus der DER-Struktur.

Die Funktion extrahiert die Daten, ohne die Integrität zu überprüfen. Dies ist die Aufgabe desModuls scep. Lediglich die Authentisierungsdaten (AuthenticationAttribute) werdenüberprüft, in dem die Signatur mit der Funktion crypto_verify_md5_rsa_signature desModuls crypto verifiziert wird. Authentisierungsdaten und die Daten selber werden von dieserFunktion zurückgeliefert.


Authentisierungsdaten

Digest

Daten

Signierer-Info

Signatur


6.2.7 rsakey

Im Modul rsakey sind Funktionen zur Handhabung von RSA-Schlüsseln implementiert. Eskönnen kryptographisch sichere RSA-Schlüssel generiert werden, welche für das Verschlüsselnvon Informationen geeignet sind.

6.2.7.1 rsakey_generate_private_key

Die Funktion rsakey_generate_private_key erstellt einen kompletten RSA-Schlüssel. Dazuwird aus einer Zufallszahlenquelle (/dev/random) die benötigten Bytes gelesen. Mit denFunktionen der libgmp werden die gelesenen Zahlen getestet, ob sie prim sind. Ist dies nichtder Fall, wird die Zahl erhöht, bis sie prim ist.

Die Funktion wurde grösstenteils aus strongSwan übernommen, der öffentliche Modulus istjedoch auch für Verschlüsselungsoperationen sicher (0x10001h).

6.2.7.2 rsakey_create_private_key

Mit der Funktion rsakey_create_private_key wird eine Datenstruktur angelegt, welcher dieWerte für einen privaten RSA Schlüssel zugeordnet werden sollen. Die Funktion ist primär dazugedacht, beim Einlesen eines RSA-Schlüssels die benötigte Datenstruktur für das einfüllen derDaten bereitzustellen. Der Speicher für den im Private-Key enthaltenen Public-Key wirdebenfalls alloziert.

6.2.7.3 rsakey_create_public_key

Mittels rsakey_create_public_key wird ähnlich zu rsakey_create_private_key dieDatenstruktur für das einfüllen der Werte vorbereitet.



6.2.8 scep

Das Modul scep beinhaltet Funktionen zum Erstellen von SCEP-Requests und zum Parsen vonSCEP-Replys, welche jeweils im DER-Format kodiert sind. Total beinhaltet das Modul vier nicht-statische Funktionen, welche nun detailliert vorgestellt werden.

6.2.8.1 scep_build_pkcs_req_chunk

Die Funktion scep_build_pkcs_req_chunk erstellt ein Request vom Typ pkcsReq. Ein Requestvom Typ pkcsReq ist der erste Request, welcher an einen SCEP-Server gesendet wird, um einvon der CA unterschriebenes Zertifikat anzufordern. Er beinhaltet alle notwendigenInformationen, welche die CA zur Erstellung eines Zertifikats benötigt, unter anderem Public-Key und Name des Anfordernden. Weitere Details zum Aufbau dieses pkcsReq können demDokument „Technologien“ und dem aktuellen SCEP-Draft [SCEPv11] entnommen werden.

Das folgende Sequenzdiagramm zeigt den groben Ablauf beim Aufruf der Funktionscep_build_pkcs_req_chunk und die Abhängigkeiten zu anderen Modulen1:

Abbildung 16 Ablauf beim Aufruf von scep_build_pkcs_req_chunk

1 Das Diagramm ist nicht vollständig und zeigt lediglich den groben Ablauf der entsprechenden Funktion. DieFunktionsparameter sind nicht aufgeführt und können der Quellcode-Dokumentation entnommen werden.



6.2.8.2 scep_build_get_cert_init_req_chunk

Die Funktion scep_build_get_cert_init_req_chunk erstellt ein Request vom TypGetCertInitial. Ein Request von diesem Typ wird dann an einen SCEP-Server gesendet,wenn der vorherige Request vom Typ pkcsReq einen PENDING-Status zurückgeliefert hat unddadurch das manuelle Enrollment eingeleitet wurde. Der Request beinhaltet alle notwendigenInformationen, welche die CA für die Zuordnung zum entsprechenden pkcsReq-Requestbenötigt, unter anderem die Transaction-ID des Requests und der Name des Anfordernden.Weitere Details zum Aufbau dieses GetCertInitial-Requests können dem Dokument„Technologien“ und dem aktuellen SCEP-Draft [SCEPv11] entnommen werden.

Im Unterschied zum pkcsReq-Request wird bei diesem Request nicht mehr der PKCS#10-Request verschlüsselt, sondern nur noch eine Sequenz bestehend aus dem Namen desAnfordernden und dem Namen der CA. Das folgende Sequenzdiagramm zeigt den grobenAblauf beim Aufruf der Funktion scep_build_get_cert_init_req_chunk und dieAbhängigkeiten zu anderen Modulen1:

Abbildung 17 Ablauf beim Aufruf von scep_build_get_cert_init_req_chunk




6.2.8.3 scep_parse_pkcs_rep_chunk

Die Funktion scep_parse_pkcs_rep_chunk parst den Reply auf ein Request vom Typ pkcsReqoder GetCertInitial. Ein solcher Reply ist eine PKCS#7-Message vom Typ signedData. DerStatus des SCEP-Requests ist als Attribut in diesen Reply kodiert. Weitere Details zum Aufbaueines solchen Replys können dem Dokument „Technologien“ und dem aktuellen SCEP-Draft[SCEPv11] entnommen werden.

Das folgende Sequenzdiagramm zeigt den groben Ablauf beim Aufruf der Funktionscep_parse_pkcs_rep_chunk und die Abhängigkeiten zu anderen Modulen1:

Abbildung 18 Ablauf beim Aufruf von scep_parse_pkcs_rep_chunk




6.2.8.4 scep_parse_get_ca_cert_rep_chunk

Die Funktion scep_parse_get_ca_cert_rep_chunk parst den Reply auf ein Request mit derPKIOperation GetCACert. Ein solcher Reply ist eine PKCS#7-Message vom Typ signedData,welche die CA-Zertifikate des SCEP-Servers enthält. Diese PKCS#7-Message ist nicht PKCS#7-konform und wird deshalb nicht über das Modul pkcs7 geparst, sondern direkt in dieserFunktion.

Jedes gefundene Zertifikat wird als Datei gespeichert, welche im Dateinamen einenaufsteigenden Index enthält.



6.2.9 util

Das Modul util enthält Funktionen, die von verschiedenen Modulen benötigt werden. Diemeisten Funktionen sind mit Hilfe der Quellcode-Dokumentation leicht verständlich undmüssen hier nicht weiter erläutert werden. Einzig die Funktion encode_base64 bedarf einerErklärung.

Die Funktion encode_base64 kodiert einen normalen Bytestream ins base64-Format um. Dader Code dieser Funktion schwer verständlich ist, wird dieser hier genauer unter die Lupegenommen, wobei angenommen wird, dass der Leser mit der base64-Kodierung vertraut ist.

Folgende Schritte werden bei der base64-Kodierung in der Funktion encode_base64durchlaufen:

1. Jeweils drei Bytes des zu kodierenden Bytestream werden genommen und gespeichert. Fallsweniger als drei Bytes zur Verfügung stehen, werden die fehlenden Bytes als 0-Wertebehandelt:

Abbildung 19 Entnehmen von drei Bytes bei der base64-Kodierung

Der entsprechende C-Sourcecode sieht folgendermassen aus, wobei b1 das erste, b2 daszweite und b3 das dritte Byte darstellen. Die Variablen b4 bis b7 werden im nächsten Schrittbesprochen.

unsigned char b1=0, b2=0, b3=0, b4=0, b5=0, b6=0, b7=0;b1 = source->ptr[i];if(i+1<length){

b2 = source->ptr[i+1];}if(i+2<length){

b3 = source->ptr[i+2];}

2. Die drei Bytes werden in vier Bytes aufgeteilt, so dass die zwei „most significant“ Bits nichtbenötigt werden:

Abbildung 20 Aufteilung von drei Bytes in vier Bytes bei der base64-Kodierung

Der entsprechende C-Sourcecode für diese Operation ist sehr kryptisch und siehtfolgendermassen aus, wobei b4 bis b7 die vier neuen Bytes bezeichnen:

b4= b1>>2;b5= ((b1&0x3)<<4)|(b2>>4);b6= ((b2&0xf)<<2)|(b3>>6);b7= b3&0x3f;

3. Jedes der vier Bytes b4 bis b7 wird nun mit Hilfe der Mapping-Funktion encode_byte in einelesbares Zeichen umgewandelt und dieses Anschliessend in den Output geschrieben, wobei



der Pointer write_position auf die aktuelle Position im Output zeigt. Falls zu Beginn derKodierung nicht drei Bytes zur Verfügung standen, wird dies durch das Einfügen desZeichens '=' als Padding markiert. Der C-Sourcecode für diesen Schritt siehtfolgendermassen aus:

*write_position++= encode_byte(b4);*write_position++= encode_byte(b5);if(i+1<length){

*write_position++= encode_byte(b6);} else {

*write_position++= '=';}if(i+2<length){

*write_position++= encode_byte(b7);}else{

*write_position++= '=';}

Wie bereits erwähnt, macht die Funktion encode_byte das Mapping auf ein lesbaresZeichen. Die entsprechende Zuordnungsmatrix kann dem RFC 1421 [RFC1421] entnommenwerden.



6.2.10 x509

Das Modul x509 befasst sich mit X.509-Zertifikaten. Es bietet Funktionen zum Parsen und auchzum Erstellen von X.509-Zertifikaten. Darin ist auch die Funktion atodn enthalten, welche 1:1aus der Datei x509.c von Pluto entnommen wurde. Diese Funktion wurde kopiert, da sonstaufgrund der Abhängigkeiten gegen beinahe alle Pluto-Modulen gelinkt werden müsste.

Die meisten Funktionen in diesem Modul sind mit Hilfe der Quellcode-Dokumentation leichtverständlich und müssen nicht weiter erläutert werden. Auf bestimmte Funktionen wirdnachfolgend genauer eingegangen.

Das Modul x509 bietet die Möglichkeit ein „selfsigned“ Zertifikat zu erstellen. Dabei wird einX.509-Zertifikat erstellt, welches mit dem eigenen RSA-Schlüssel unterschrieben ist. In SCEPwird beispielsweise ein solches Zertifikat verwendet, um eine Zertifikatsanfrage beim SCEP-Server zu machen. Um ein DER-kodiertes „selfsigned“ Zertifikat zu erstellen, werden dieFunktionen x509_selfsigned_build, x509_build_chunk und x509_free verwendet, welche infolgender Reihenfolge aufgerufen werden:

Abbildung 21 Ablauf beim Erstellen eines „selfsigned“ Zertifikats

Das Zertifikat wird erst in der Funktion x509_build_chunk kodiert. Darin wird auch dieSignatur des Zertifikats erstellt. Die Funktion x509_selfsigned_build kapselt die Angabendes Zertifikats in einem Objekt vom Typ x509_t und erstellt zudem die Seriennummer desZertifikats. Beim SCEP-Protokoll muss diese Seriennummer der Transaction-ID des SCEP-



Requests entsprechen. Im SCEP-Draft [SCEPv11] ist definiert, dass dabei die Transaction-IDdem Hash des Public-Keys des Anfordernden entsprechen muss. Über das Format oder den zuverwendeten Hash-Algorithmus wird dabei kein Wort verloren. Während den Tests gegenOpenSCEP mussten wir feststellen, dass es sich bei der Seriennummer um den MD5-Hash desDER-kodierten SubjectPKInfo-Feldes handeln muss, damit der Request von OpenSCEPakzeptiert wird. Deshalb wird zur Kompatibilität mit OpenSCEP in der Funktionx509_selfsigned_build die Seriennummer durch Erstellen eines MD5-Hashes über dem FeldSubjectPKInfo erstellt.



6.2.11 main

Dieses Modul ist neben dem Parsen von Eingabeparametern vor allem für die kompletteAblaufsteuerung verantwortlich. Es ist so aufgebaut, dass anhand der Ein- undAusgabeparameter eruiert wird, welche Aktionen ausgeführt werden müssen.

Der Programmlauf läuft so lange, wie noch weitere Ausgaben anstehen, sind alle definiertenAusgaben durchgeführt, so wird der Programmlauf abgebrochen.

6.2.11.1 Beziehen CA-Zertifikat

Damit eine verschlüsselte Kommunikation mit dem SCEP-Server möglich ist, muss zuerst dasZertifikat der CA bezogen werden:

Abbildung 22 Ablauf beim Beziehen eines CA-Zertifikates

Ein SCEP-Server kann mehrere Zertifikate aushändigen, die für verschiedene Zweckeverwendet werden (Verschlüsselung, Signierung usw.).

6.2.11.2 Enrollment

Das Enrollment führt ein kompletter Ablauf für das Beziehen von einem Zertifikat durch, in derAnnahme, das CA-Zertifikat ist bereits vorhanden. Es wird nur solange durchgeführt, wie nochAusgaben anstehen. Sind alle abgearbeitet, wird der Programmlauf beendet.

Das nachfolgende Diagramm gibt Auskunft über den gesamten Ablauf sowie die dabeiverwendeten Module. Es ist aus Gründen der Übersicht nicht komplett und die Funktions-Signaturen sind vereinfacht übernommen.



Abbildung 23 Ablauf eines Enrollments

1. Ist als Eingabe eine Datei mit privatem Schlüssel (PKCS#1) definiert, so wird diese Datei ineinem ersten Schritt eingelesen (1.1) und in einem zweiten (1.2) daraus der Schlüsselextrahiert.

2. Ist kein privater Schlüssel (PKCS#1) als Eingabe definiert, so wird dieser zuerst generiert(2.1) und anschliessend in das weiterverwendbare Format konvertiert (2.2).

3. Wird PKCS#1 als Ausgabe verlangt, so wird die Datei mit dem privaten Schlüsselgeschrieben.

4. Nun wird ein Request im PKCS#10-Format generiert. Dazu wird ein Private-Key, ein„distinguished name“ und optional ein „challenge passwort“ angegeben. Es können zudem„subjectAltNames“ in den Request übernommen werden.

5. Wenn gewünscht wird der Request in eine Datei gespeichert.

6. Damit mit dem Server verschlüsselt kommuniziert werden kann, wird das CA-Zertifikat fürdie Verschlüsselung geladen. Da die CA für Verschlüsselung und Signierung verschiedeneZertifikate verwenden kann, werden diese beide separat angegeben.

7. Da der Request zusätzlich signiert wird, muss zur Signatur auch ein Zertifikat angegebenwerden. SCEP verwendet dazu ein selbst-signiertes Zertifikat, welches aus dem privatenSchlüssel generiert wird.



8. Der PKCS#10 Request wird verschlüsselt und signiert. Dabei kommen die Zertifikate zumEinsatz, welche in den Schritten sechs und sieben geladen bzw. generiert wurden.

9. Für das Polling im „manual mode“ wird die GetCertInitial-Meldung erstellt. Sie wird immergeneriert, auch wenn der Server im „automatic mode“ arbeitet. Dies ist so gelöst, da hieralle Informationen für diese Meldung zur Verfügung stehen und somit der Ablaufwesentlich einfacher ist.

10. Für das verifizieren der Signatur wird das CA-Zertifikat für Signaturen geladen. Wie gesagtkann es sich von dem Zertifikat aus Schritt sechs unterscheiden und muss deshalb separatgeladen werden.

11. Nun wird der verpackte Request aus Schritt acht an den Server gesendet, seine Antwortwird in die angegebene Datei geschrieben. Das Schreiben des Replys in eine Datei istwesentlich einfacher mit libcurl, weshalb dieser Lösungsansatz gewählt wurde.

12. In diesem Schritt wird nun die Datei wieder eingelesen, um den Reply parsen zu können.

13. Der Reply wird nun geparst, verifiziert, entschlüsselt und falls vorhanden wird dasZertifikat extrahiert. Falls der Server aber im „manual mode“ arbeitet, so muss mittelsPolling auf die Erstellung des Zertifikates gewartet werden. Ist dies der Fall, werden dieSchritte 14, 15 und 16 wiederholt, bis das Zertifikat ausgestellt wurde.

14. Die in Schritt neun erstellte Meldung kommt nun zum Einsatz und wird periodisch an denServer gesendet, die Antwort wird wieder in eine temporäre Datei geschrieben.

15. Die temporäre Datei wird wieder eingelesen, um geparst werden zu können.

16. Die eingelesenen Daten werden geparst. Falls das Zertifikat nun in der Meldung enthaltenist, wird es extrahiert. Wenn der Status weiterhin PENDING ist, wiederholen sich Schritte14, 15 und 16 nach einer definierten Pause.

17. Das extrahierte Zertifikat kann nun an den gewünschten Ort geschrieben werden.


Studienarbeit „SCEP für Linux strongSwan“ Tests

7 Tests

7.1 TestumgebungUm die Funktionalität und auch die Kompatibilität von scepclient zu testen, ist eineTestumgebung notwendig. Es werden zwei verschiedene SCEP-Server eingesetzt. Zum einenist dies die CA auf einem Windows 2003 Server, welche mit dem SCEP-Addon [Win2003 SCEP-Patch] gepatcht wurde. Zum anderen kommt OpenSCEP zum Einsatz, welcher unter Linuxbasierend auf OpenSSL seinen Dienst verrichtet.

Die Installation dieser beiden Server mit weiteren Einzelheiten können dem Dokument„Infrastruktur“ entnommen werden.

7.1.1 Windows 2003 CA

Mit dem SCEP-Addon beherrscht die sehr mächtige Windows 2003 CA auch das Enrollment überSCEP. Sie unterstützt sowohl den „automatic mode“ als auch den „manual mode“, muss jedochabhängig vom Modus entweder als „Standalone CA“ oder als „Enterprise CA“ betrieben werden.Wird die CA als „Standalone CA“ betrieben, so erfolgt das Enrollment immer im „manualmode“. Im Betrieb als „Enterprise CA“ erfolgt das Enrollment im „automatic mode“, d.h. mitder Hilfe von einem „preshared secret“.

Die Authentisierung der Requests kann über ein „preshared secret“ erfolgen, welches als„challenge password“ im Request mitgesendet wird. Wird diese Option bei der Installationgewählt, so kann über die Webseite des SCEP-Servers ein solches angefordert werden. Wirdauf die Authentisierung mit „preshared secret“ verzichtet, findet überhaupt keine automatischeAuthentisierung statt. Bei der „Enterprise CA“ werden dann die Zertifikate automatisch undungeprüft verteilt!

7.1.2 OpenSCEP

OpenSCEP beherrscht ebenfalls das automatische als auch das manuelle Enrollment, braucht fürdie automatische Variante allerdings einen lauffähigen LDAP-Server. Dieser stand nicht zurVerfügung, weshalb gegen OpenSCEP nur im „manual mode“ getestet wurde. Das Erteilen einesZertifikates erfolgt bei OpenSCEP über eine Weboberfläche.

Die Authentisierung erfolgt über einen Vergleich des MD5-Fingerprints. Das Challenge-Passwort im SCEP-Request wird nur für das Widerrufen von Zertifikaten verwendet.



7.2 Automatisches Testen „good cases“Für das automatische Testen der Funktionalität kommt ein kleines Shell-Script zum Einsatz. Esführt einige Enrollments und andere Tests durch und kann so die Funktionalität desscepclients sicherstellen. Zur Verifizierung der Daten kommt der Parser von OpenSSL zumEinsatz. Das Script run_good_cases befindet sich im Unterverzeichnis tests desscepclients.

7.2.1 Verwendung

Da der Umgang mit den Parametern und Zertifikaten zwischen den verschiedenen Servertypenleicht unterschiedlich ist, muss spezifiziert werden, um welchen Typ Server es sich handelt.Zudem muss die URL für das Enrollment spezifiziert werden:

./run_test_cases <url> < win2003 | openscep >Das Script generiert ein temporäres Verzeichnis und legt seine Daten dort ab. Diese können füreine genauere Untersuchung weiter inspiziert werden.

7.2.2 Testfälle

Die folgenden Testfälle werden vom Testscript run_good_cases in entsprechender Reihenfolgedurchgeführt. Bei einigen Testfällen wird ein neuer RSA-Schlüssel generiert, dieser aber nichtgespeichert. Dies ist normalerweise notwendig, wird hier zum Testen aber nicht gemacht.

Details zu den einzelnen Testfällen können direkt aus dem Script entnommen werden.

7.2.2.1 „cacert“

Beschreibung Dieser Test bezieht die CA-Zertifikate vom SCEP-Server und speichert sie temporärab. Alle erhaltenen Zertifikate werden mit OpenSSL geparst und ausgegeben.Dieser Test muss vor allen anderen ausgeführt werden, da die hier bezogenen CA-Zertifikate für den Bezug eines normalen Zertifikats verwendet werden.

Erwartete Resultate Wird gegen den OpenSCEP getestet, soll nur ein CA-Zertifikat zurückgegeben unddieses in der Datei cacert gespeichert werden.Wird gegen die Windows CA getestet, sollten mehrere CA-Zertifikate zurückgegebenwerden und diese mit dem Dateiprefix cacert gespeichert werden.

Resultate Test erfolgreich, Zertifikat oder Zertifikate wurden korrekt abgespeichert undkonnten geparst werden.

Tabelle 14 Testfall "cacert"

7.2.2.2 „pkcs1“

Beschreibung Der Test generiert einen privaten Schlüssel mit 512 Bit Schlüssellänge und speichertihn in der Datei pkcs1 ab. Der Schlüssel wird anschliessend auf seine Strukturgeprüft, indem er mit OpenSSL geparst wird. Die Gültigkeit der Werte im Schlüsselwerden nicht überprüft.

Erwartete Resultate Der Schlüssel sollte erzeugt und gespeichert werden.

Resultate Test erfolgreich, Schlüssel konnte erfolgreich generiert und geparst werden.

Tabelle 15 Testfall "pkcs1"



7.2.2.3 „pkcs10.1“

Beschreibung Der Test generiert einen einfachen PKCS#10 Request, der nur einen „DistinguishedName“ enthält, speichert ihn in der Datei pkcs10.1 und überprüft die Gültigkeit derStruktur. Der notwendige private Schlüssel soll dabei automatisch generiert werden.

Erwartete Resultate Der Request sollte erzeugt werden. Der dazu notwendige Schlüssel sollte die default-Schlüssellänge von 1024 Bit besitzen und der „Distinguished Name“ im Requestenthalten sein.

Resultate Test erfolgreich, Request konnte geparst werden und der „Distinguished Name“ istenthalten. Der Public-Key im Request hat eine erwartete Schlüssellänge von 1024Bit.

Tabelle 16 Testfall "pkcs10.1"

7.2.2.4 „pkcs10.2“

Beschreibung Dieser Test generiert einen erweiterten PKCS#10 Request. Es werden zusätzlich drei„SubjectAltNames“ sowie ein „challenge password“ einbezogen. Als notwendigerRSA-Schlüssel wird der RSA-Schlüssel des Testfalls „pkcs1“ verwendet.

Erwartete Resultate Der Request sollte erzeugt werden. Der Public-Key im Request sollte dem Public-Keydes RSA-Schlüssels pkcs1 entsprechen. Die „subjectAltNames“ zusammen mit dem„challenge password“ sollten im Request enthalten sein.

Resultate Test erfolgreich, Request konnte geparst werden und die erweiterten Attribute sindwie gewünscht enthalten. Auch der Public-Key stimmt mit dem Key in der Dateipkcs1 überein.


7.2.2.5 „pkcs7.1“

Beschreibung Bei diesem Test wird eine PKCS#7-Envelope generiert. Dazu wird ein neuerSchlüssel und ein Request generiert. Der OpenSSL-Parser überprüft den Aufbau derEnvelope, prüft aber den Inhalt nicht. Es wird nur ein „Distinguished Name“verwendet.Der Request wird in der Datei pkcs7.1 gespeichert. Als CA-Zertifikat wird dasZertifikat aus Testfall „cacert“ verwendet.

Erwartete Resultate Der SCEP-Request sollte erzeugt und abgespeichert werden.

Resultate Test erfolgreich, Envelope kann geparst werden. Ob ein entschlüsseln möglich ist,zeigt dieser Test allerdings nicht.


7.2.2.6 „pkcs7.2“

Beschreibung Für diesen Test wird wiederum eine PKCS#7-Envelope erzeugt, allerdings aus einembereits erstellten Request aus dem Testfall „pkcs10.2“.Als CA-Zertifikat wird das Zertifikat aus Testfall „cacert“ verwendet.

Erwartete Resultate Der SCEP-Request sollte erzeugt werden.

Resultate Test schlägt fehl, da das Laden von PKCS#10 Requests aus Zeitgründen nichtimplementiert wurde.




7.2.2.7 „enroll.1“

Beschreibung Dieser Test führt ein Enrollment durch, in dem er die Envelope aus dem Test„pkcs7.1“ lädt und daraus die Abfrage herstellt.Als CA-Zertifikat wird das Zertifikat aus Testfall „cacert“ verwendet.

Erwartete Resultate Der SCEP-Request sollte durchgeführt und das Zertifikat bezogen werden.

Resultate Test schlägt fehl, da das Laden von PKCS#7-Envelopes aus Zeitgründen nichtimplementiert wurde.

Tabelle 20 Testfall "enroll.1"

7.2.2.8 „enroll.2“

Beschreibung Der Test führt ein Enrollment durch, in dem er Schlüssel, Request und daraus eineEnvelope generiert und an den Server sendet. Das erhaltene Zertifikat wird mitOpenSSL geparst und geprüft. Als „challenge password“ wird „passwort“ angegeben.Als CA-Zertifikat wird das Zertifikate aus Testfall „cacert“ verwendet.


Resultate Test erfolgreich, das Zertifikat kann bezogen und geparst werden. Der scepclientgeht nach dem ersten Request automatisch in den „manual mode“.


7.2.2.9 „enroll.3“

Beschreibung Dieser Test führt ein Enrollment wie im Testfall „enroll.2“ durch, diesmal jedochunter der Verwendung von HTTP POST.


Resultate Test schlägt mit beiden CAs fehl, sie scheinen die HTTP POST Methode nicht zuunterstützen.


7.2.2.10 „enroll.4“

Beschreibung Der Test führt ebenfalls ein Enrollment durch. Diesmal wird für die Konfiguration eineDatei verwendet, welche mit „--optionsfrom„ eingelesen wird. Diese wird vom Scriptgeneriert.

Erwartete Resultate Der SCEP-Request sollte durchgeführt und das Zertifikat bezogen werden. AlleOptionen sollten aus der angegeben Datei gelesen werden.

Resultate Test erfolgreich. Alle definierten Parameter werden in den Request undschlussendlich ins Zertifikat übernommen.




7.3 Testen „bad cases“Um das Verhalten von scepclient im Fehlerfall zu untersuchen, kommt ebenfalls ein Shell-Script zum Einsatz. Es simuliert Fehlerfälle (meist Eingaben) und zeigt das Verhalten vonscepclient in den entsprechenden Situationen. Somit kann einfach erkannt werden, ob einFehler richtig behandelt wird.

Es ist im Gegensatz zu den „good cases“ weniger ein automatisches Testen, es zeigt vielmehrein Ausschnitt aus den Tests, für welche das Verhalten von scepclient untersucht wurde. DasScript run_bad_cases befindet sich im Unterverzeichnis tests des scepclients.

Beispiele für Tests im Script run_bad_cases:

– Beziehen eines bereits vorhandenen CA-Zertifikats ohne Angabe der „overwrite“-Option

– Verwendung eines nicht existierenden SCEP-URL

– Verwendung eines falschen URL

– Generierung eines zu kleinen RSA Schlüssels

– Generierung eines RSA Schlüssels mit nicht unterstützter Schlüssellänge

– Verwendung eines falschen Zertifikat zur Signatur-Prüfung

– usw.


Studienarbeit „SCEP für Linux strongSwan“ Infrastruktur

8 Infrastruktur

8.1 EinleitungIn diesem Dokument wird die eingesetzte Hard- und Software der Studienarbeit „SCEP fürLinux strongSwan“ beschrieben. Zusätzlich enthält dieses Dokument spezielle Anleitungen, z.B.zur Verwendung von Doxygen oder zur Installation des Testservers.

8.2 EntwicklungsumgebungDie Entwicklungsrechner wurden von der HSR zur Verfügung gestellt und sind bereits mit demGentoo-Linux vorinstalliert. Folgende Software wurde zur Entwicklung eingesetzt:

Name Version Einsatz / Bemerkung

gcc 3.3.5 Kompilieren des scepclientsGNU make 3.80 Automatisches Kompilieren

libcurl 7.13.1 HTTP Requests

gmp 4.1.4 RSA Rechenoperationen

strongSwan 2.4.1 und 2.4.4 Der scepclient wurde gegen diese beiden Versionen von strongSwangelinkt und mit beiden getestet

Tabelle 24 Eingesetzte Entwicklungs-Software und Bibliotheken

8.3 DokumentationswerkzeugeZur Dokumentation wurden die folgenden Produkte eingesetzt:

Name Version Einsatz / Bemerkung

OpenOffice.org 1.1.4 Dokumentation, Zeiterfassung

Doxygen 1.4.2 Erzeugen der Quellcode-Dokumentation

Imendio Planner 0.12.1 Grafische Projektplanung

Jude Community 1.5.1 Diverse Diagramme

Tabelle 25 Eingesetzte Dokumentationswerkzeuge

8.3.1 Doxygen

Doxygen [Doxygen] ist ein Werkzeug zur Quellcode-Dokumentation. Ähnlich dem Tool JavaDocextrahiert Doxygen die Dokumentationsinformationen in Form spezieller Tags aus demQuelltext. Aus diesen extrahierten Informationen generiert das Tool Dokumentationen inunterschiedlichsten Formaten, beispielsweise HTML-Dokumentationen oder man-pages.Doxygen ist unter der GNU-Lizenz entwickelt worden und läuft auf Linux, Windows, Max OS Xund SUN Solaris 9.

Nachfolgend wird die Installation und die Verwendung von Doxygen unter Gentoo beschrieben.Im Dokument „Programmierrichtlinien“ ist ein Beispiel-Quelltext abgebildet, welcher mitDoxygen dokumentiert ist.



8.3.1.1 Installation

Für Gentoo existiert ein so genanntes ebuild für Doxygen, welches die einfache Installationvon Doxygen erlaubt. Mit dem Befehl

emerge doxygenwird Doxygen automatisch heruntergeladen, kompiliert und installiert. Alle notwendigen Tools,die für den Betrieb von Doxygen notwendig sind, werden dabei automatisch mit installiert.

8.3.1.2 Verwendung

Doxygen wird über die Kommandozeile ausgeführt. Die Einstellungen zur Generierung derDokumentation werden in einer Konfigurationsdatei definiert, die beim Start von Doxygenangegeben wird.

Doxygen bietet einen Parameter zum Erstellen einer Template-Konfigurationsdatei. Der Befehldazu lautet:

doxygen -g <konfigdatei>

Die generierte Konfigurationsdatei beinhaltet alle Konfigurationsparameter von Doxygen undjeweils eine kurze Erklärung dazu. Diese Konfigurationsdatei kann von Hand mit einemTexteditor oder mit dem Tool Doxywizard bearbeitet werden. Doxywizard erlaubt dieBearbeitung der Konfigurationsparameter über ein GUI.

Sobald die Einstellungen in der Konfigurationsdatei vorgenommen sind, kann Doxygen mit derentsprechenden Konfigurationsdatei gestartet werden.

Der Befehl zum Ausführen von Doxygen mit einer bestimmten Konfigurationsdatei lautet:

doxygen <konfigdatei>

Für den scepclient existiert eine Doxygen-Konfigurationsdatei mit dem Namendoxyconfig.DoxyFile, welche sich im scepclient-Verzeichnis befindet. Diese Datei wurdemit dem Tool Doxywizard angepasst.

Die Datei doxyconfig.DoxyFile wurde so angepasst, dass die Dokumentation in denFormaten HTML und man-pages generiert wird.

Die Generierung der Quellcode-Dokumentation des scepclients wurde in das Makefileübernommen und kann mit folgendem Befehl gestartet werden:

make doxygen



8.4 TestserverUm den scepclient testen zu können, wird eine CA mit SCEP-Unterstützung benötigt. Esexistieren verschiedene Produkte, die diese Anforderung erfüllen. Die für die Studienarbeit„SCEP für Linux strongSwan“ in Frage kommenden Produkte sind in der nachfolgender Tabellekurz zusammengefasst:

Name Beschreibung

OpenSCEP OpenSCEP ist eine frei verfügbare Server-Implementierung des SCEP-Protokollsunter Linux/Unix. OpenSCEP baut auf folgenden Produkten auf:- Apache Webserver- OpenSSL- OpenLDAP

OpenCA OpenCA ist eine sehr umfangreiche, auf Linux/Unix basierte, CA. Auch OpenCA hateine SCEP-Unterstützung eingebaut und ist frei verfügbar. OpenCA baut auffolgenden Produkten auf:- OpenSSL- OpenLDAP- Apache Webserver- Apache mod_ssl

Microsoft Windows CA mitSCEP-Addon Microsoft bietet eine eigene CA basierend auf dem Server Betriebssystem Windows

2003 Server. Diese Windows CA ist sehr umfangreich. Über ein so genanntesAddon kann die SCEP-Funktionalität der Windows CA hinzugefügt werden.

Tabelle 26 Verschiedene CAs mit SCEP-Unterstützung im Vergleich

Als Testserver war ursprünglich ein Gentoo-Linux-System geplant, auf welchem der OpenSCEP-Server zum Einsatz kommt. Um den Zertifikats-Austausch mittels „preshared secret“ zuermöglichen, muss OpenSCEP zusätzlich über LDAP mit einem LDAP-Server kommunizierenkönnen. Wegen diverser Probleme beim Einrichten von LDAP für OpenSCEP hat sich dieErstellung der Testserver-Infrastruktur nur mit Hilfe von OpenSCEP bereits zu Beginn derStudienarbeit als zu aufwendig erwiesen. Die Dokumentation enthält nochInstallationshinzweise zu LDAP, eine funktionierende Version konnte allerdings nichtkonfiguriert werden.

Als alternative Lösung wurde anschliessend OpenCA in Betracht gezogen. OpenCA ist eine sehrkomplexe und umfangreiche Software, bei welcher es aber bei der Dokumentation vor allem imBereich von SCEP stark mangelt.

Aufgrund der Probleme mit OpenSCEP und der zu hohen Komplexität von OpenCA wurdeentschieden, die Tests des scepclients mit „preshared secret“ gegen einen Windows 2003Server durchzuführen. Mit einem Addon kann die Windows CA um die SCEP-Funktionalitäterweitert werden.

Die Testumgebung mit dem Linux-Server und OpenSCEP wird somit nur für Tests ohne„preshared secret“ und für den Bezug des CA-Zertifikats eingesetzt. Alle Tests mit einem„preshared secret“ werden nur gegen den Windows 2003 Server gemacht.

Die nachfolgenden Abschnitte beschreiben zum einen die Installation des Testservers unterLinux und zum anderen die Installation des Testservers unter Windows 2003 Server.



8.4.1 Testserver Linux

8.4.1.1 Installation Gentoo

Die Installation des Gentoo-Systems erfolgt gemäss der Installationsanleitung von Gentoo,welche unter [GentooManual] zu finden ist.

Spezielle Einstellungen und Abweichungen zum Handbuch sind hier vermerkt. Die folgendenUnterkapitel sind gleich benannt wie die des deutschen Gentoo-Handbuchs, um dieAnpassungen im Handbuch zu finden. Die Beschreibungen in diesem Dokument sind lediglichErgänzungen zum entsprechenden Handbuch.

8.4.1.1.1 Auswählen des richtigen Installationsmediums

Ausgangslage der Installation ist eine Gentoo-LiveCD, welche das Booten eines Linux-Systemsab einer CD ermöglicht. Zum Einsatz kommt die CD 2004.3 in der minimal-Version.

Nach einlegen und booten ab der CD können wir den Kernel und dessen Optionen auswählen.Wir wählen

gentoo docachedamit die System-Dateien in ein RAM-Drive geladen werden. Somit vermeiden wir das nervigehoch- und runterfahren des CD-ROM-Laufwerks.

Das System startet, wir wählen als Keymap sg.

Nun hätten wir gerne etwas mehr Informationen über die Hardware unseres Testsystems. Mitdem Befehl

lspciwird eine Auflistung unserer PCI-Hardware gegeben. Diese Angaben können wir später für dasKompilieren des Kernels für unser System gebrauchen:

Komponente Informationen

Grafikkarte Intel 82865G

Netzwerkadapter Intel e1000

Tabelle 27 Hardware des Testservers



8.4.1.1.2 Vorbereiten der Festplatte(n)

Nun fahren wir mit der Partitionierung der Festplatte fort. Mit

fdisk /dev/sdapartitionieren wir unser IDE-Harddisk. Wir verzichten auf ein kompliziertesPartitionierungsschema, da es sich nur um ein Testsystem handelt. Wir erstellen eine Ext-Systempartition, bereits vorhandene Partitionen rühren wir nicht an:

Partition Typ Verwendung Grösse

/dev/sda1 hidden FAT 12 Image-Partition der HSR 8 MB

/dev/sda2 W95 FAT32 (LBA) Reserviert für Windows 2003 Server 30 GB

/dev/sda3 Linux Gentoo-System 50 GB

Tabelle 28 Partitionierung des Testservers

Jetzt formatieren wir die Partition:

mke2fs –j /dev/sda3Mittels der Option -j wählen wir die Journal-taugliche Variante des Ext-Dateisystems, sprichExt3.

8.4.1.1.3 Installation der Gentoo Installations Dateien

Nun geht es darum, mit der Population der neuen Partition zu beginnen. Um möglichst schnellan unser Ziel gelangen, wählen wir eine Stage3-Installation. Wir brauchen dazu dieentsprechende Stage-Datei. Mit

links2 www.gentoo.orgsteuern wir die Gentoo-Seite an. Unter Download-Mirrors wählen wir einen nahe liegendenMirror aus und speichern die Datei releases/x86/2005.0/stages/pentium4/stage3-pentium4-2005.0.tar.bz2 nach /mnt/gentoo.

An den Compiler-Optionen müssen wir nicht viel herum schrauben, ein zusätzliches -pipe inden CFLAGS könnte unseren zuvor stehenden Kompilationen allerdings etwas Vorschub geben.

8.4.1.1.4 Installation des Gentoo Basis System

Das Mirrorselect machen wir schneller und genauer von Hand. Ein

mirrorselect -io >> /mnt/gentoo/etc/make.conflässt uns den nahe liegenden Switch-Mirror auswählen.



8.4.1.1.5 Konfiguration des Kernels

Bei der Wahl des Kernels haben wir uns für die gentoo-sources entschieden. Diese sindmeistens auf neustem Stand und enthalten ein paar nützliche Patches der Gentoo-Distribution.Falls wir beim Einspielen von Patches später Probleme bekommen sollten, ist es ein leichtes,auf die ungepatchten Original-development-sources von Linus Torvalds höchst persönlichzurückzugreifen.

Den Kernel konfigurieren wir von Hand. Wir nehmen die Vorschläge des Handbuchs an, fügenaber noch ein paar spezifische Einstellungen hinzu.

Loadable module Support ---> [*] Module unloading Device Drivers ---> Networking support ---> Networking options ---> <*> PF_KEY sockets <*> IP: AH transformation <*> IP: ESP transformation <*> IP: IPComp transformation <*> Ipsec user configuration interface Ethernet (1000 Mbit) ---> [*] Intel(R) PRO/1000 Gigabit Ethernet Support Sound ---> <*> Sound card support Advanced Linux Sound Architecture ---> PCI Devices ---> <*> Intel/Sis/nVidia/AMD/ALi AC97 Controller File systems ---> Pseudo Filesystems ---> [*] /proc file system support [*] /dev file system support (OBSOLETE) [*] Automatically mount at boot [*] Virtual memory file system support (former shm fs) Processor type and features Processor family (Pentium-4/celeron(P4-based)/Pentium-4 M/Xeon) [ ] Symmetric multi-processing supportCryptographic options ---> [*] Cryptographic API: Alles auswählen

8.4.1.1.6 Konfiguration des System

Mit unserem Partitionierungsschema ergibt sich folgendes fstab:

# <fs> <mountpoint> <type> <opts> <dump/pass>/dev/sda3 / ext3 noatime 1 1/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0/dev/fd0 /mnt/floppy auto noauto 0 0none /proc proc defaults 0 0none /dev/shm tmpfs defaults 0 0

Als Hostnamen wählen wir scep, als DNS-Domain hsr.ch. Da der Server am Netz der HSR hängt, verwenden wir für die Netzwerk-Konfiguration DHCP.Das root-Passwort setzen wir auf Lumpy05.



8.4.1.1.7 Installation der benötigten System Tools

Als Keylogger wählen wir den praktischen metalog, dieser bietet etwas mehr Möglichkeiten imVergleich zu anderen Keyloggers, kommt aber ausreichend vorkonfiguriert daher.

Auf die Installation von vixie-cron möchten wir nicht verzichten, man weiss nie wann einCron-Job nützlich sein wird.

Da die IP-Adresse des Rechners per DHCP abgefragt wird, installieren wir auch den DHCP-Dämon dhcpd.

8.4.1.1.8 Konfiguration des Bootloaders

Wir wählen grub als Bootloader, da einige praktische Möglichkeiten gegenüber dem doch etwasin die Jahre gekommenen lilo implementiert wurden. Durch unsere Systemkonfigurationergibt sich folgendes grub.conf:

timeout 10default 0title Gentoo-Linux root (hd0,2) kernel /boot/kernel root=/dev/sda3 vga=0x31Btitle Gentoo-Linux (nofb) root (hd0,2) kernel /boot/kernel root=/dev/sda3

Wir installieren grub von Hand. Dies geschieht für unser System mit folgenden Befehlen:

grubgrub> root (hd0,2)grub> setup (hd0)grub> quit

Das System ist nun in seiner Grundkonfiguration einsatzbereit. Nach einem Neustart bootetdas System mit dem neuen Kernel.

8.4.1.1.9 Konfiguration für SSH-Zugriff

Damit wir auf dem Server arbeiten können, möchten wir gerne per SSH darauf zugreifenkönnen. Dazu starten wir den SSH-Daemon und bewerkstelligen, dass dieser bei jedemNeustart automatisch geladen wird:

/etc/init.d/sshd startrc-update add sshd default

Des Weiteren legen wir zwei Benutzer an, damit wir nicht immer als root arbeiten müssen:

useradd jhuseradd mw

Um mittels Private-/Public-Key einloggen zu können, erstellen wir in denBenutzerverzeichnissen ein Verzeichnis .ssh und fügen darin im File authorized_keys diePublic-Keys der beteiligten Studenten ein.



8.4.1.2 OpenSCEP

OpenSCEP ist eine OpenSource-Implementierung von SCEP. OpenSCEP besteht aus einem SCEP-Server, sowie einen SCEP-Client. Um unseren scepclient zu testen, wird OpenSCEP aufunserem Testrechner installiert. OpenSCEP gibt es nicht als Gentoo-Paket und muss dahermanuell kompiliert und installiert werden.

8.4.1.2.1 Source kompilieren und installieren

Zuerst muss der OpenSCEP-Sourcecode von [OpenSCEP] heruntergeladen werden. Mitconfigure wird geprüft, ob alle Voraussetzungen zur Kompilierung von OpenSCEP erfüllt sind.Damit OpenSCEP gegen OpenSSL in der Version 0.9.7 gelinkt werden kann, muss vorher derQuellcode gepatch werden [OpenSCEP-Patch1]:

cd /usr/src/wget http://openscep.othello.ch/download/openscep-0.4.2.tar.gz tar -xzf openscep-0.4.2.tar.gzcd openscep-0.4.2patch -p1 < [OpenSCEP-Patch1]./configure --with-openscep-dir=/var/openscep \--with-html-install-dir=/var/www/localhost/htdocs/openscep \--with-cgi-install-dir=/var/www/localhost/cgi-bin/openscep \--with-pkiclientexe=/var/www/localhost/cgi-bin/pkiclient.exe

Nun kann mit

makemake checkOpenSCEP kompiliert und getestet werden.

Da OpenSCEP eine Gruppe staff verlangt, wird diese vor der Installation erstellt und dieInstallation anschliessend gestartet:

groupadd staffmake install



8.4.1.2.2 OpenSCEP konfigurieren

Die Konfiguration der CA erfolgt mit dem mitgelieferten Script /usr/local/sbin/openscepsetup. Dabei haben wir folgende Konfiguration verwendet:

...Country Name [CH]:Organization Name (eg, company) [Othello]:HSRCommon Name (eg, your name) []:SCEP-CAPlease enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:seppioptional company name (unstructured) []:Signature ok...

Nun fehlt noch eine Datei, welche die aktuell zu vergebende Seriennummer für die Zertifikateenthält. Dies wird mit

echo „01“ > serialerstellt, wobei das erste Zertifikat die Seriennummer 1 erhält.

Des weiteren muss die Konfigurationsdatei openscep.cnf angepasst werden. Darin wird unteranderem der LDAP-Server konfiguriert. Damit die Änderungen nicht von Hand durchgeführtwerden müssen, kann die Datei folgendermassen gepatcht werden:

patch openscep.cnf < [OpenSCEP-Patch3]

Damit das CGI-Script auf den Verzeichnissen arbeiten kann, müssen einige Dateien undVerzeichnisse dem Benutzer des Webservers zugeordnet werden:

cd /var/openscep/chown apache:apache . pending .rnd granted rejected revoked newcerts \index.txt serial

Das CGI-Script, welches zur Unterzeichnung von Zertifikaten verantwortlich ist, hat noch einenFehler. Die Parameter einer HTTP-Post-Anfrage werden nicht richtig gelesen. Die Dateipending.pl, die sich im Verzeichnis /var/www/localhost/cgi-bin/openscep befindet, mussmit dem Patch [OpenSCEP-Patch2] gepatcht werden.

cd /var/www/localhost/cgi-bin/openscep/patch pending.pl < [OpenSCEP-Patch2]



8.4.1.2.3 OpenLDAP installieren und konfigurieren

Damit OpenSCEP mit „preshared „secret“ arbeiten kann, muss ein LDAP-Server eingerichtetwerden. Auf dem Testserver kommt OpenLDAP zum Einsatz, welcher unter Gentoo einfach mit

emerge openldapinstalliert werden kann.

OpenSCEP braucht einige zusätzliche OpenLDAP-Schemas, darunter auch eines, welches mitOpenSCEP mitgeliefert wird. Um diese einzubinden, müssen in der Datei /etc/openldap/slapd.conf folgende „Includes“ hinzugefügt werden:

include /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/nis.schemainclude /var/openscep/openscep.schema

Nun muss eine Datenbank definiert werden, in welcher die Zertifikate abgelegt werden können.Dazu wird an die Datei /etc/openldap/slapd.conf folgender Eintrag angehängt:

database ldbmsuffix "O=HSR,C=CH"rootdn "cn=Manager,O=HSR,C=CH"rootpw seppidirectory /var/openscep/ldap-dataindex objectClass eqlastmod on



8.4.1.2.4 OpenSCEP testen

Die aufgesetzte Infrastruktur kann nun getestet werden. Da der beim OpenSCEP mitgelieferteClient nicht funktioniert, kommt der SCEP-Client sscep zum Einsatz. Er ist nicht als Gentooebuild verfügbar, kann aber unter [sscep] als Quelltext bezogen und kompiliert werden:

cd /usr/srccp [SSCEP-20040325] ./sscep.tgztar zxf sscep.tgzcd sscepmakecp sscep /usr/bin

Nun sind alle notwendigen Tools für das Testen einsatzbereit. Zuerst muss mit OpenSSL einRSA Key erstellt werden, anschliessend ein Request daraus. Danach kann mit sscep dasZertifikat der CA bezogen werden, worauf das eigentliche Enrollment durchgeführt werdenkann:

openssl genrsa -out test.keyopenssl req -key test.key -new -days 30 -out test.req -outform PEM \-config /var/openscep/openscep.cnf

Country Name [CH]:Organization Name (eg, company) [HSR]:HSRCommon Name (eg, your name) []:testerPlease enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:seppioptional company name (unstructured) []:

sscep getca -u http://scep.hsr.ch/cgi-bin/pkiclient.exe -c CA-Certsscep enroll -u http://scep.hsr.ch/cgi-bin/pkiclient.exe -c CA-Cert \-k test.key -r test.req -l tester.cert -t 5

sscep führt nun einen SCEP-Request durch und geht dabei automatisch in den „manual mode“,indem er alle fünf Sekunden einen SCEP-Request sendet, bis der Request akzeptiert oderabgebrochen wird. Via Webinterface unter http://scep.hsr.ch/openscep muss die Anfragebestätigt werden, woraufhin ein Zertifikat ausgestellt und dem Client zurück gesendet wird.

Hat der Request funktioniert, kann der Client nun das erhaltene Zertifikat betrachten:

openssl x509 -in tester-cert -text -noout



8.4.2 Testserver Windows

Beim Windows-Testserver kommt Windows Server in der Version 2003 Enterprise Editionzum Einsatz. Der Windows-Testserver wird nicht direkt ans HSR-Netz gehängt, sondern erhältein eigenes Netz mit einem separaten Switch. Damit mit diesem Testserver getestet werdenkann, wurde in die Entwicklungsrechner je einen zweiten Netzwerkadapter eingebaut. DieseNetzwerkadapter sind beide über den genannten Switch mit dem Server verbunden.

8.4.2.1 Installation Windows 2003 Server

Damit die zuvor beschriebene Linux-Installation für weitere Tests bestehen bleibt, wirdWindows parallel mit Dualboot installiert. Es findet auf der zweiten Partition platz. GewisseDienste benötigen das NTFS-Dateisystem, weshalb wir die Partition mit NTFS formatieren.

Die weitere Installation des Servers ist sehr intuitiv und muss nicht speziell beschriebenwerden. Neben der Sprache wurden folgende Einstellungen vorgenommen:

Einstellung Wert Beschreibung

Rechnername scep-server Der Server bekommt den Name scep-server, die Domain wirdspäter scep.ch getauft.

Administrator-Passwort Lumpy05 Unser Standard-Passwort für den Server

Tabelle 29 Einstellungen für die Windows 2003 Server-Installation

Windows 2003 Server kommt leider ohne Treiber für den vorhandenen Netzwerkadapter daher,weshalb wir den Treiber [NW-Treiber] nach abgeschlossener Installation manuellnachinstallieren.

8.4.2.2 Benötigte Roles einrichten

Um als Server seine Aufgabe erfüllen zu können, muss dieser noch einige Dienste anbieten. InWindows 2003 werden diese „Roles“ genannt. Da der Server in einem separaten Netzwerkläuft, kommt ein DHCP- als auch ein DNS-Server zum Einsatz. Diese Rollen werdenfolgendermassen eingerichtet:

Rolle Zweck Einstellungen

DHCP-Server Vergeben von IPs an dieEntwicklungsrechner

Server erhält statisch die IP 192.168.0.1, DNS-Adressenwerden zwischen 192.168.0.2 bis 192.168.0.254 vergeben

Domain-Controller Benötigt für eine Enterprise CA Die Domain wird scep.ch benannt. Die Endung .ch ist nichtwirklich sinnvoll, aber ohne mehrteilige Domäne ist dieKonfiguration komplexer.Als Passwort wird wieder Lumpy05 gewählt.

Tabelle 30 Installierte Roles auf dem Windows 2003 Server

Nachdem der Domain-Controller eingerichtet ist, muss dem DHCP-Server erlaubt werden, IPszu verteilen. Dies geschieht folgendermassen:Manage Server -> Manage DHCP-Server -> scep-server -> Actions -> Authorize



8.4.2.3 Einrichten der CA

Um eine CA einzurichten, muss weitere Software unter Control-Panel -> Add/Remove Programs -> Add/Remove Windows Componentsinstalliert werden:

Package Zweck Einstellungen

Certificate Services Verwaltung von Zertifikaten Möchte man das Enrollment der Zertifikate automatischmit „preshared secret“ durchführen, muss die „EnterpriseRoot CA“ eingerichtet werden. Für das manuelleEnrollment muss die „Standalone CA“ eingerichtetwerden.

Für den SCEP-Addon wird ein CA-Name ohne nicht-alphanumerische Zeichen empfohlen, deshalb wirdscepca gewählt.

Application-Server -> IIS Webserver für den SCEP-Zertifikatsaustausch

Tabelle 31 Zusätzliche Softwarepakete auf dem Windows 2003 Server

Nun kann der Patch [Win2003 SCEP-Patch] installiert werden, damit die CA mit dem SCEP-Protokoll kommunizieren kann. Hierbei können die Standard-Einstellungen verwendet werden.Als Name wird scepca verwendet, Company ist HSR, Land CH.

8.4.2.4 Testen eines Enrollments

Nun kann ein Enrollment von einem Linux-Client getestet werden. Dazu wird wieder der sscepverwendet.

Das Passwort für den Request bei automatischem Enrollment muss zuvor bezogen werden.Dies geschieht mit einem Browser über folgende URL:

http://scep-server/certsrv/mscep/mscep.dllAuf dieser Seite kann als Administrator eingeloggt werden. Nun wird das ganze Enrollmentdurchgeführt:

openssl genrsa -out test.keyopenssl req -key test.key -new -days 365 -out test.req -outform PEMsscep getca -u http://scep-server/certsrv/mscep/mscep.dll -c scep-casscep enroll -u http://scep-server/certsrv/mscep/mscep.dll -c \ scep-ca-0 -e scep-ca-1 -k test.key -r test.req -l test.crt

Der Server liefert mehrere CA-Zertifikate, scep-ca-0 bis scep-ca-2. Das erste wird fürSignaturen verwendet, das zweite für Verschlüsselungen, und das dritte signiert die anderenbeiden.

Das erhaltene Zertifikat kann nun inspiziert werden:

openssl x509 -text -in test.crt


Studienarbeit „SCEP für Linux strongSwan“ Installationsanleitung

9 InstallationsanleitungDer scepclient wurde mit der Version 2.4.1 von strongSwan entwickelt. Da gegen Ende derStudienarbeit strongSwan bereits als Version 2.4.4 zur Verfügung stand, wurde dernachfolgend verwendete Patch gegen die Version 2.4.4 von strongSwan erstellt.

9.1 Patchen von strongSwan für SCEPEin Patch erweitert strongSwan um die Funktionalität des SCEP-Protokolls. Im wesentlichenwird ein neues Verzeichnis scepclient in programs generiert, welches den Quellcode desscepclients enthält. Weiter werden einige Änderungen an bereits existierenden strongSwan-Dateien gemacht. So werden beispielsweise neue OIDs definiert oder das Makefile um denscepclient erweitert.

strongSwan in der Version 2.4.4 kann mit wenigen Schritten um die SCEP-Funktionalitäterweitert werden. Als erstes wird der Quellcode von strongSwan ganz normal entpackt:

tar jxvf strongswan-2.4.4.tar.bz2

Als nächstes wird der Patch [scepclientForStrongSwan-Patch] ins extrahierte Verzeichniskopiert:cp [scepclientForStrongSwan-Patch] strongswan-2.4.4

Nun kann der Quellcode von SCEP gepatcht werden:cd strongswan-2.4.4patch -p1 < [scepclientForStrongSwan-Patch]

Der Quellcode von scepclient ist nun erstellt und die notwendigen Anpassungen amQuellcode von strongSwan sind vorgenommen.

9.2 Erstellen von strongSwan mit SCEPDas Erstellen von strongSwan mit gepatchter SCEP-Unterstützung unterscheidet sich nichtvom Ablauf bei der ungepatchten Variante. Beim Erstellen von programs wird zusätzlich derscepclient mit kompiliert. Auch wird beim Installieren die man-page sowie der scepclient insrichtige Verzeichnis installiert. Zur erfolgreichen Erstellung von strongSwan mit SCEP-Unterstützung muss libcurl auf dem System installiert sein.

make programsmake install

9.3 Erstellen der Doxygen-DokumentationDie Quellcode-Dokumentation wird standardmässig nicht automatisch erstellt, da dafür dasTool Doxygen auf dem System vorhanden sein muss. Die Erstellung erfolgt mit dem Makefilevon scepclient.

cd programs/scepclientmake doxygen

Durch diesen Befehl wird die Quellcode-Dokumentation in den Formaten HTML und man-pageim Unterverzeichnis doc erstellt. Wie bereits erwähnt muss dazu das Tool Doxygen auf demSystem installiert sein.



9.4 Durchführen eines EnrollmentsNun kann für strongSwan ein Enrollment durchgeführt werden. Dies geschieht, wie fürstrongSwan üblich, über den Befehl ipsec.

Um die Zertifikate der CA zu beziehen, ist folgender Schritt notwendig:

ipsec scepclient --out cacert --url http://scepserver/cgi-bin/pkiclient.exe

Alle CA-Zertifikate werden so automatisch im Konfigurationsverzeichnis von strongSwanabgelegt. Diese Zertifikate sind allerdings nicht authentisiert, da das Protokoll keineautomatische Authentisierung vorsieht. Eine Überprüfung der Fingerprints ist deshalbnotwendig.

Weiter kann nun ein Request erstellt werden:

ipsec scepclient --out cert --out pkcs1 --in cacert-sig --in cacert-enc –-url \http://scepserver/cgi-bin/pkiclient.exe --dn „C=CH,O=HSR,CN=Tester“

Das Zertifikat sowie der Schlüssel im PKCS#1-Format wird in den entsprechendenstrongSwan-Verzeichnissen abgelegt. Für das Enrollment wird ein Zertifikat für dieVerschlüsselung sowie für die Signaturüberprüfung benötigt. In diesem einfachen Beispiel wirdangenommen, dass der SCEP-Server nur ein einziges CA-Zertifikat zurückgeliefert hat, welchesnun für Verschlüsselung und Signaturüberprüfung verwendet wird.

9.5 Erstellen eines Test-SzenariosUm ein konkretes Szenario der Zertifikatsverteilung mit SCEP durchzuspielen, wird eine kleineTest-Infrastruktur aufgebaut. Konkret verbinden sich die beiden Hosts sun und moon über einenIPSec-Tunnel. Dazu beziehen sie aber zuerst von einem zentralen SCEP-Server die benötigtenZertifikate.

Als SCEP-Server kommt OpenSCEP zum Einsatz, das Enrollment erfolgt im „manual mode“.strongSwan kommt in der wie oben beschriebenen gepatchten Variante zum Einsatz. Eshandelt sich lediglich um ein simples Test-Szenario.

Weitere Möglichkeiten von scepclient können der man-page entnommen werden. Diese wirdnach erfolgreicher Installation vom gepatchten strongSwan mit

man ipsec_scepclientangezeigt.

9.5.1 Konfiguration von moon

Als erstes braucht moon das CA-Zertifikat. Es wird folgendermassen bezogen:ipsec scepclient --out cacert –url http://scepserver/cgi-bin/pkiclient.exe

Das Zertifikat wird somit standardmässig in der Datei /etc/ipsec.d/cacerts/scep-cacert.der gespeichert.

Nun generiert moon einen privaten Schlüssel, mit welchem er ein Zertifikat anfordert:ipsec scepclient --out cert --out pkcs1 --in cacert-sig --in cacert-enc –-url \http://scepserver/cgi-bin/pkiclient.exe --dn „C=CH,O=HSR,CN=moon“



Somit erhält moon das Zertifikat. Es liegt in der Datei /etc/ipsec.d/certs/scep-cert.der.Der private Schlüssel liegt nun in der Datei /etc/ipsec.d/private/scep-key.der.

strongSwan benötigt einen Eintrag für das Passwort des Keys, auch wenn dieser gar nichtgeschützt wird. Deshalb wird in /etc/ipsec.secrets folgendes eingetragen:

: RSA scep-key.der „“

Nun muss die VPN-Verbindung noch konfiguriert werden. Bei moon sieht die Datei /etc/ipsec.conf folgendermassen aus:

config setup plutodebug=allconn scep left=%defaultroute leftcert=scep-cert.der right=sun.hsr.ch rightid="C=CH,O=HSR,CN=sun" auto=start

9.5.2 Konfiguration von sun

Auch für sun muss als erstes das Zertifikat der CA bezogen werden:ipsec scepclient --out cacert –url http://scepserver/cgi-bin/pkiclient.exe

Das Zertifikat wird somit standardmässig in der Datei /etc/ipsec.d/cacerts/scep-cacert.der gespeichert.

Der Host sun generiert einen neuen RSA-Schlüssel und bezieht ein Zertifikat:

ipsec scepclient --out cert --out pkcs1 --in cacert-sig --in cacert-enc –-url \http://scepserver/cgi-bin/pkiclient.exe --dn „C=CH,O=HSR,CN=sun“

Das Zertifikat für sun wird somit in /etc/ipsec.d/certs/scep-cert.der abgelegt. Der privateSchlüssel liegt in der Datei /etc/ipsec.d/private/scep-key.der.

Es fehlt noch der leere Passwort-Eintrag im /etc/ipsec.secrets:

: RSA scep-key.der „“

Nun muss die VPN-Verbindung konfiguriert werden. Bei sun sieht die Datei /etc/ipsec.conffolgendermassen aus:

config setup plutodebug=allconn scep left=%defaultroute leftcert=scep-cert.der right=moon.hsr.ch rightid="C=CH,O=HSR,CN=moon" auto=start

Wenn beide Hosts konfiguriert sind, kann mittels

ipsec setup startdie Verbindung aufgebaut werden.


Studienarbeit „SCEP für Linux strongSwan“ Resultate

10 Resultate

10.1 ErgebnisseMit dem scepclient ist ein in strongSwan integriertes Tool entstanden, mit dem digitaleZertifikate von einer CA sicher über das SCEP-Protokoll bezogen werden können. Dabeikonnten, neben denen in der Aufgabenstellung geforderten Funktionalitäten, zusätzlicheFunktionalitäten implementiert werden. Die Funktionalitäten des scepclients werden nungenauer beschrieben, wobei in geforderte und zusätzliche Funktionalitäten unterschieden wird.

10.1.1 Geforderte Funktionalitäten

Implementiert wurde der scepclient in der Programmiersprache C. Er nutzt Funktionen derstrongSwan-Bibliotheken beispielsweise zur ASN.1-Kodierung oder zum Parsen von ASN.1-Strukturen. Für die Kommunikation mit einem SCEP-Server über HTTP wird die libcurleingesetzt. Für die Generierung von RSA-Schlüsselpaaren und für die RSA-Verschlüsselungwird auf Funktionen der GNU Multi-Precision Library libgmp zurückgegriffen.

Der scepclient generiert ein RSA-Schlüsselpaar mit spezifizierter Schlüssellänge undspeichert dieses DER-kodiert im PKCS#10-Format in einer Datei. Standardmässig wird dasSchlüsselpaar in der Datei /etc/ipsec.d/private/scep-key.der gespeichert.

Aus einem RSA-Schlüsselpaar zusammen mit einem „Distinguished Name“ in LDAP-Schreibweise erzeugt der scepclient einen PKCS#10-Request. Dem Request kann zusätzlichein „challenge password“ hinzugefügt werden, welches als „preshared secret“ im „automaticmode“ oder zum Widerruf eines Zertifikats benutzt werden kann. Der gesamte Request kannDER-kodiert in eine Datei abgespeichert werden.

Der PKCS#10-Request wird vom scepclient in eine PKCS#7-Message vom TypenvelopedData und anschliessend in eine PKCS#7-Message vom Typ signedData verpackt.Die resultierende PKCS#7-Message entspricht schlussendlich dem SCEP-Payload PKCSReq.

Der SCEP-Request wird per HTTP an den SCEP-Server gesendet.

Das Enrollment eines Zertifikats kann entweder mit eine Windows 2003 CA oder mit demOpenSource SCEP-Server OpenSCEP durchgeführt werden. Der scepclient wurde mit beidenProdukten getestet.

Die Authentisierung eines SCEP-Request kann durch ein „preshared secret“ erfolgen. Dieseswird vom scepclient als „challenge password“ in den PKCS#10-Request kodiert.

Die Antwort des SCEP-Servers entspricht dem SCEP-Payload CertRep. Das darin enthalteneX.509-Zertifikat wird vom scepclient entschlüsselt und DER-kodiert abgespeichert.Standardmässig wird das bezogene Zertifikat in der Datei /ipsec.d/certs/scep-cert.dergespeichert.


Studienarbeit „SCEP für Linux strongSwan“ Resultate

10.1.2 Zusätzliche Funktionalitäten

Neben dem Generieren eines RSA-Schlüsselpaars erlaubt der scepclient das Laden einesRSA-Schlüsselpaars aus einer DER-kodierten PKCS#1-Datei.

Zusätzlich zu einem „Distinguished Name“ gestattet der scepclient die Angabe von„subjectAltNames“ für IP-Adresse, Hostname und Emailadresse. Diese „subjectAltNames“ sindErweiterungen des X.503-Standards in der Version 3.

Der scepclient kann die CA-Zertifikate über das SCEP-Protokoll beziehen, wobei derenAuthentizität durch einen Fingerprint-Vergleich sichergestellt werden muss.

Neben dem geforderten „automatic mode“ unterstützt der scepclient auch das Enrollmentüber den „manual mode“ ohne die Nutzung eines „preshared secrets“. Die Authentisierungeines Request im „manual mode“ erfolgt dabei durch einen Fingerprint-Vergleich.

SCEP setzt für die Verschlüsselung in PKCS#7 lediglich DES als zwingend voraus. Da dieses indie Jahre gekommene Verfahren nicht mehr als sicher bezeichnet werden kann, wurdezusätzlich die Verschlüsselung mit Triple-DES realisiert.

10.2 SchlussfolgerungenstrongSwan beherrscht dank dieser Studienarbeit das SCEP-Protokoll. Damit lässt sichstrongSwan einfacher in eine Public-Key Infrastruktur einbinden.

Im Gegensatz zu anderen Implementierungen von SCEP benötigt der scepclient keinOpenSSL. Auf diese Weise bleibt strongSwan frei von amerikanischem Quellcode und unterliegtkeinen jetzigen oder zukünftigen Export-Restriktionen. Der scepclient bring keine neuenAbhängigkeiten mit sich. Ein schlankes und auch sichereres Linux-System benötigt somitlediglich strongSwan, libcurl und libgmp um eine komplette VPN-Installation mit Zertifikatenaufzusetzen. Dank scepclient können die Schlüssel direkt ohne OpenSSL auf dem Systemgeneriert werden, ohne dieses jemals verlassen zu müssen. Zertifikate für das System als auchCA-Zertifikate können mittels SCEP unkompliziert bezogen werden.

Dank der Kompatibilität zu wichtigen Systemen wie etwa Windows 2003 Server oder auchOpenSCEP ist der scepclient für den Praxisgebrauch durchaus einsetzbar. Wird dieZertifikatsverwaltung über Windows 2003 geregelt, vereinfacht sich die Verteilung derZertifikate wesentlich. Ein manuelles Kopieren von Zertifikaten und sensiblen Schlüsselnentfällt.

Obwohl der scepclient die Basisfunktionalität von SCEP unterstützt, wurde nicht das ganzeProtokoll implementiert. So fehlt das Abfragen von unterstützten Algorithmen und Funktionendes Servers oder auch die Unterstützung anderer Verschlüsslungs- bzw. Hashalgorithmennebst RSA, DES und MD5. Lediglich die zusätzliche Unterstützung für 3DES wurdeimplementiert, da DES nicht mehr als sicher betrachtet werden kann.

Durch die freie Lizenz von strongSwan und des integrierten scepclients ist der Quellcodegeeignet für Erweiterungen. Wird die Kompatibilität zu einem anderen SCEP-Server oder dieUnterstützung von weiteren Funktionen erforderlich, so kann der Quellcode auch durch Dritteangepasst werden.


Studienarbeit „SCEP für Linux strongSwan“ Erfahrungsberichte

11 Erfahrungsberichte

11.1 Jan HutterNach nun 15 Wochen schaue ich positiv auf die vergangene Studienarbeit „SCEP für LinuxstrongSwan“ zurück. Während dieser Zeit konnte ich mein Wissen in vielen Bereichen vertiefenund neue Technologien kennen lernen.

Bei der Programmierung in C konnte ich meine Fähigkeiten weiter stärken. Durch die ersteStudienarbeit „RPC_GSS für Windows“ , in der wir auch in C programmierten, war dieEinarbeitung in die Programmiersprache selbst keine grosse Hürde mehr.

Was mich sehr überrascht hat, war, dass die RSA-Verschlüsselung ein relativ einfacherAlgorithmus ist, der sich leicht implementieren lässt. Mit wenigen Zeilen Code hat man bereitseinen der weit verbreitetsten asymmetrischen Algorithmen implementiert.

Das Projektmanagement bei dieser Arbeit war meiner Meinung nach relativ schwierig. MangelsErfahrung konnten wir schlecht abschätzen, wie viel Zeit wir für die einzelnen Teilzielevorsehen müssen. Wieder mussten wir erneut feststellen, dass der Aufwand für dieProgrammierarbeit schnell unterschätzt wird; Debuggen und Fehler suchen haben viel mehrZeit beansprucht, wie wir geplant haben.

Eine zusätzliche Schwierigkeit war das Erstellen eines Software-Designs, wie wir es in denersten beiden Studienjahren gelernt haben. Der fehlende objektorientierte Ansatz vom Cmachte das Erstellen eines Software-Designs sehr schwierig.

Was mich besonders freut, ist, dass ich einen vertieften Einblick in die PKI-Problematikgewonnen konnte. Zertifikate sind mir nicht mehr fremd. Auch erkenne ich die Probleme,welche eine zertifikatsbasierte Sicherheitsinfrastruktur mit sich bringt.

Ja, in dieser Studienarbeit konnte ich vieles dazu lernen. Bezeichnungen, die ich vor einemhalben Jahr noch fragend betrachtet habe, sind mir jetzt sehr vertraut, sei es ASN.1, PKCS#1,PKCS#7, usw. Das Wissen über diese Technologien habe ich primär während der Studienarbeitangeeignet und ich bin sicher, dass mir dieses Wissen in Zukunft auch etwas bringen wird.

Zum Schluss hoffe ich, dass unser Programm seinen Nutzen bringen und vielleicht auch vonder OpenSource-Gemeinde weiterentwickelt wird.


Studienarbeit „SCEP für Linux strongSwan“ Erfahrungsberichte

11.2 Martin WilliAls wir die Zusage für die Studienarbeit "Simple Certificate Enrollment Protocol für LinuxstrongSwan" bekamen, war meine Freude gross. Ich programmiere gerne in der etwas tiefergehenden Programmiersprache C, und unter Linux zu arbeiten war ebenfalls mein Wunsch. DerBereich der sicheren Netzwerkprogrammierung konnte mein Interesse schon vorher gewinnen,weshalb ich sehr motiviert war.

In dieser Studienarbeit ging es darum, eine bestehende Software zu erweitern. Da es sich beistrongSwan um eine ziemlich umfangreiche Software handelt, war dies umsoherausfordernder. Es war nicht immer einfach, die bestehenden Lösungen möglichst elegantmit den eigenen Ideen zu kombinieren. Da der Umfang der zu erstellenden Software ziemlichgross war, musste unbedingt auf bestehenden Teilen aufgebaut werden. Hätten wir das nichtgetan, wäre die Zeit nicht ausreichend gewesen. So war es oftmals notwendig, geeigneteFunktionen in strongSwan ausfindig zu machen, und falls geeignet zu verstehen und zuverwenden.

Sehr viel lernen konnte ich bei diversen Standards. Durch die Verwendung von Technologienwie ASN.1 oder den diversen PKCS. Dabei musste ich feststellen, dass ASN.1 ein fürchterlichkomplizierter Standard ist und ich mich beim Verständnis auf das wesentliche konzentrierenmusste. Einen etwas genaueren Einblick in die Funktionsweise von RSA zu gewinnen war sehrinteressant, und auch die Implementierung von solchen Funktionen konnte mich begeistern.

SCEP, das Protokoll, welches wir implementierten, hat uns einiges an Kopfzerbrechen gebracht.Im Prinzip ist es ein einfacher, auf bewährtem aufbauender Standard. Gewisse Definitionenund Beschreibungen sind aber nicht immer klar und eindeutig. Oft wurde es zu einemprobieren, wie was funktioniert. Meiner Meinung nach ist der Draft nicht sonderlich gutaufgebaut und die benötigten Informationen sind nicht immer einfach zu finden. GewisseEntscheidungen, welche beim Entwurf des Protokoll gemacht wurden, waren für mich nichtimmer nachvollziehbar.

Unterschätzt hatte ich ein wenig die Programmierarbeiten, welche entstehen. Dabei warmeistens nicht das Implementieren von gewissen Funktionen und Algorithmen das Problem,sondern vielmehr die Fehlersuche. Durch das nicht immer klare SCEP-Draft haben wir gewissesfalsch aufgeschnappt und implementiert. Und das einzige Feedback, welches man zum Fehlerbekam, war die Antwort vom SCEP-Server: "Konnte Inhalt nicht lesen". Nun gut, aber warumnicht? Dann hiess es oft, die produzierten Datenpakete zu analysieren, zu entschlüsseln undmit einer anderen Implementierung zu vergleichen. Dies ist bei der Entwicklung von Softwaremit Verschlüsselung alles andere als einfach. So konnten wir uns an gewisse Problemestundenlang herantasten. Oft war man damit beschäftigt, Bits und Bytes zu zählen.

Als Fan der OpenSource-Bewegung hat mir das Projekt einen tieferen Einblick in dieseThematik gebracht. Es werden sicherlich nicht die letzten Zeilen Code gewesen sein, welche dieÖffentlichkeit von mir zu sehen bekommt.


Studienarbeit „SCEP für Linux strongSwan“ Projektmanagement

12 Projektmanagement

12.1 Projektplan

12.1.1 Prozessmodell

Für die Implementierung von „SCEP für Linux strongSwan“ wird nicht nach einem ganzbestimmten Prozessmodell wie etwa RUP vorgegangen. Die Phasen und Meilensteine sind sogeplant, wie man es aus dem Wasserfallmodell kennt, da das Programm scepclient nach undnach um Funktionen erweitert wird. In den einzelnen Phasen jedoch wird iterativ gearbeitet,wie es der RUP vorsieht. Natürlich sollen während dem ganzen Projekt die Fortschrittenachvollzogen und Risiken früh eingeschätzt und erkannt werden können.

12.1.2 Planung von Projektphasen

Um die Studienarbeit überschaubar zu halten, wird sie in Phasen aufgeteilt. Eine Phase sollsich über wenige Wochen erstrecken und mit einem Meilenstein abgeschlossen werden. Klaredefinierte Ziele der Projektphase sollen beim erreichen eines Meilensteins überprüft werdenkönnen und so Aufschluss über den aktuellen Fortschritt im ganzen Projekt geben. Die Phasenselbst sind nicht iterativ geplant, jedoch sollen, wenn möglich, die Zielsetzungen in den Phaseniterativ erarbeitet werden.

Allfällige Entscheide aufgrund der erreichten Resultate nach Abschluss einer Phase werden inForm eines Protokolls festgehalten.

12.1.3 Planung von Arbeitspaketen

Die Planung von Arbeitspaketen erfolgt zu Beginn des Projektes nur grob. Es soll eineAufwandschätzung der einzelnen Phasen und dessen Arbeitspakete erfolgen. Eine genaueAuflistung von Arbeitspaketen ist erst im weiteren Verlauf möglich, da eine solche Auflistungerst durch Erkenntnisse aus abgeschlossenen Projektphasen ermöglicht wird. Zu Beginnwerden Arbeitspakete eher grob geplant, welche dann sukzessive in detailliertere Arbeitspaketevon bis 20 Mannstunden aufgeteilt werden. Die Planung der Pakete wird mit dem effektivverwendeten Aufwand verglichen, um die Einschätzungen zu bewerten und allenfalls fürfolgende Phasen anzupassen.

12.1.4 Risikoanalyse

Eine Risikoanalyse soll Risiken des Projektes aufzeigen und auf mögliche Probleme hinweisen.Mit Hilfe der Risikoanalyse sollte es möglich sein, einzelne Risiken zu erkennen genauer zuuntersuchen. Die Risiken sollen so früh wie irgendwie möglich durch Studien und Testseliminiert oder allenfalls die Planung des Projektes angepasst werden können. Zu jedem Risikowird dessen Stand im Projekt verfolgt um diese während und nach dem Projekt beurteilen zukönnen.


Studienarbeit „SCEP für Linux strongSwan“ Projektplan

12.1.5 Projektphasen

Die Studienarbeit dauert vom Montag, 21. März bis Montag, 4. Juli 2005, was total 15 Wochenentspricht. Die Arbeit ist in folgende Projektphasen aufgeteilt:

Nr. Projektphase Dauer Abschlussdatum

1 Einarbeiten 3 Wochen 7. April 2005

2 Generierung PKCS#10 3 Wochen 28. April 2005

3 Generierung SCEP-Request 3 Wochen 19. Mai 2005

4 Speicherung Zertifikat 2 Wochen 2. Juni 2005

5 Erweiterungen 2 Wochen 16. Juni 2005

6 Abschluss der Studienarbeit 2 Wochen 4. Juli 2005

Tabelle 32 Projektphasen der Studienarbeit

Auf die einzelnen Projektphasen und die Erzeugnisse am Ende der entsprechenden Phase wirdnachfolgend eingegangen. Zeiterfassungs- und Protokolldokumente sowie Glossar undQuellenverzeichniss sind nicht speziell vermerkt. Diese werden während der ganzenStudienarbeit aktuell gehalten.

12.1.5.1 Einarbeiten

In dieser Phase wird die Projektplanung vorgenommen. Die Teammitglieder haben sich amEnde dieser Phase einen groben Überblick über die Thematik verschafft und können denvoraussichtlichen Aufwand ungefähr abschätzen. Genauer beinhaltet dies eine ersteEinarbeitung in vorhandene Standards sowie das genauere Kennenlernen von LinuxstrongSwan. Auch wird in dieser Phase ein SCEP-Server für den späteren Test desscepclients installiert.

Erzeugnis Status am Ende der Phase

Projektplan - Erste Projektplanung definiert- Projekt in Phasen unterteilt- Definition der Arbeitspakete für die erste Phase- Definition der Arbeitspakete für die nächste Phase

Risikoanalyse - Die wichtigsten Risiken erkannt und formuliert- Erste Massnahmen zur Vorbeugung und Behebung definiert

Dokumentvorlagen - Dokumentvorlagen für alle Dokumente erstellt

Programmierrichtlinien - Programmierrichtlinien aufgestellt

Infrastruktur - Programmierumgebung eingerichtet- Allgemeine Arbeitsumgebung einrichten- strongSwan auf Rechnern installiert und konfiguriert- SCEP-Server eingerichtet

Dokumentation Infrastruktur - Beschreibung der eingesetzten Software- Anleitungen für spezielle Installationen oder Konfigurationen

Dokumentation Technologien - Begonnene Dokumentation der eingesetzten Technologien (SCEP, ASN.1,PKCS#10, PKCS#7, etc.)

Software-Design - Grobe Software-Architektur des scepclients definiert

Tabelle 33 Erzeugnisse nach Phase "Einarbeiten"



12.1.5.2 Generierung PKCS#10

Ziel dieser Phase ist es, mit der libgmp-Bibliothek ein RSA-Schlüsselpaar zu erzeugen unddaraus ein PKCS#10 Zertifikats-Request zu generieren. Zur Erzeugung können die ASN.1-Funktionen von strongSwan verwendet und gegebenenfalls erweitert werden.


Projektplan - Definition der Arbeitspakete für die nächste Phase

Risikoanalyse - Status der einzelnen Risiken aktualisiert- Mögliche neue Risiken definiert

Dokumentation Technologien - Dokumentation zu PKCS#10 und ASN.1 ergänzt

Programmierrichtlinien - Programmierrichtlinien definiert

Software-Design - Software-Architektur des scepclients erweitert- Funktionsweise der Generierung beschrieben

scepclient - Beherrscht das Generieren von Schlüsselpaaren und das Erzeugen vonPKCS#10 Zertifikat-Requests

Tabelle 34 Erzeugnisse nach Phase "Generierung PKCS#10"

12.1.5.3 Generierung SCEP-Request

In dieser Phase wird der scepclient um die Funktion erweitert, den zuvor generiertenPKCS#10 Zertifikats-Request mit dem Public-Key der CA zu verschlüsseln und in zweiverschachtelte PKCS#7-Messages zu verpacken. Der Client soll dann mit Hilfe der libcurl-Bibliothek ein HTTP Request an den SCEP-Server senden können. Die Authentisierunggeschieht mit einem „preshared secret“ (SCEP im „automatic mode“). Das Polling-Verfahren,sprich SCEP im „manual mode“, wird eventuell in der Phase Erweiterungen implementiert.


Projektplan - Definition der Arbeitspakete für die nächste Phase

Risikoanalyse - Status der einzelnen Risiken aktualisiert

Dokumentation Technologien - Dokumentation zu PKCS#7 und SCEP ergänzt

Software-Design - Software-Architektur des scepclients erweitert- Funktionsweise der Generierung des Requests beschrieben

scepclient - Beherrscht das Erzeugen der PKCS#7-Messages aus einem PKCS#10Zertifikats-Request mit dem Public-Key der CA- Sendet die PKCS#7-Message per HTTP an den SCEP-Server- Authentisierung des Requests über ein „preshared secret“

Tabelle 35 Erzeugnisse nach Phase "Generierung SCEP-Request"



12.1.5.4 Speicherung Zertifikat

Nach dem Abschluss dieser Phase soll der scepclient die Antwort des SCEP-Servers entgegennehmen und sein Zertifikat mit seinem Private-Key entschlüsseln können. Danach soll er dasentpackte Zertifikat als Datei im strongSwan-Verzeichnisbaum ablegen.


Projektplan - Zu implementierende Erweiterungen sind definiert- Definition der Arbeitspakete für die nächste Phase

Risikoanalyse - Status der einzelnen Risiken aktualisiert

Dokumentation Technologien - Dokumentation zu X.509 und SCEP ergänzt

Software-Design - Software-Architektur des scepclients erweitert- Funktionsweise des Parsen und Abspeichern beschrieben

scepclient - Beherrscht empfangen, entschlüsseln und dekodieren der SCEP-Response- Legt das Zertifikat für strongSwan ab

Tabelle 36 Erzeugnisse nach Phase "Speicherung Zertifikat"

12.1.5.5 Erweiterungen

Je nach vorhandenen Zeitreserven sollen in dieser Phase mögliche Erweiterungenimplementiert werden. Dazu gehört z.B. ein Polling-Verfahren bei einer manuellen Request-Authentisierung.


Dokumentation Technologien - Dokumentation zu den Erweiterungen nachgeführt

Software-Design - Software-Architektur des scepclients erweitert- Funktionsweise der Erweiterungen beschrieben

scepclient - Beherrscht den „manual mode“ mit Hilfe des Polling-Verfahrens- Beherrscht das Empfangen von CA-Zertifikaten

Tabelle 37 Erzeugnisse nach Phase "Erweiterungen"

12.1.5.6 Abschluss der Studienarbeit

In dieser Phase wird die Studienarbeit zum Abschluss gebracht. Dazu gehört das Überarbeitenund Aufbereiten der gesamten Dokumentation und des Quellcodes.


scepclient - Beherrscht alle in der Aufgabenstellung geforderten Funktionen- Client kann komplett über die Kommandozeile konfiguriert und gestartetwerden- Die Software ist Teil der strongSwan-Tools

man-page für scepclient - Der Client ist auf Englisch in einer man-page beschrieben. Darin sind alleKommandozeilenparameter aufgelistet und beschrieben

Quellcode-Dokumentation - Aus dem Quellcode kann mit Doxygen eine HTML-Dokumentation und man-pages erstellt werden

Projektplan - Beinhaltet Statistiken und Auswertungen der Zeiterfassung - Beinhaltet endgültige Version der Zeitplanung

Komplette Dokumentation - Erweitert um: Einleitung, Ergebnisse, Schlussfolgerung,Erfahrungsberichte, Management Summary, Abstract- Überarbeitet und abgeschlossen- Gedruckte Version vorhanden

Tabelle 38 Erzeugnisse am Ende der Studienarbeit



12.1.6 Projektübersicht

In folgender Abbildung sind die sechs verschiedenen Phasen ersichtlich. Die genauereEinteilung in die Arbeitspakete sind auf der CD im Spreadsheet „Tasks“ ersichtlich.

Abbildung 24 Grobe Projektübersicht

12.1.7 Umsetzung

Eine erste Abschätzung des Aufwands erfolgte zu Beginn der Arbeit. Die Stunden wurdenmöglichst exakt über die 14 Arbeitswochen verteilt. Wir rechneten mit einem ca. 15Wochenstunden. Am Ende jeder Phase wurden die Arbeitspakete etwas genauer geschätzt,woraus die Soll-Werte entstanden. In der Woche acht waren Schulferien.

Die folgende Statistik zeigt den Arbeitsaufwand des Projektes im Soll/Ist-Vergleich über alleArbeitswochen hinweg:

Abbildung 25 Arbeitsaufwand Soll/Ist-Vergleich

Die geschätzten Zeiten waren etwas zu tief. Zu Beginn der Arbeit rechneten wir mit rund 15Stunden pro Arbeitswoche, was bei 14 Wochen und zwei Personen ein Total von 420 Stundenergibt. Bei der Verfeinerung der Arbeitspakete erreichten wir ein Total von 401 Stunden. Dietatsächlich geleisteten Stunden belaufen sich für das ganze Projekt auf 490 Stunden.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 150

5

10

15

20

25

30

35

40

45

50

55

Soll

Ist


Gründe für den Mehraufwand sind primär die zu tief geschätzten Programmier- undDebugarbeiten. Wir unterschätzten die sehr schwierige und zeitraubende Fehlersuche. BeimDebugging von Routinen mit kryptographischer Funktionalität ist dies ein grosserMehraufwand.

Der erhöhte Stundenaufwand in den letzten Wochen ist auf zwei Ursachen zurückzuführen:Zum einen wollten wir den scepclient mit zusätzlicher Funktionalität erweitern, damit dieserauch wirklich praxistauglich ist. Zum anderen war die Überarbeitung der Dokumentation unddas Schreiben von Management-Summary, Abstract und usw. ein erheblicher Aufwand.


Studienarbeit „SCEP für Linux strongSwan“ Risikoanalyse

12.2 Risikoanalyse

12.2.1 RSA-Schlüssel kann nicht erstellt werden

Risiko Bei der Generierung des RSA-Schlüsselpaars darf nicht auf die OpenSSL-Bibliotheken zurückgegriffen werden. Es besteht das Risiko, dass aufgrund deszu kleinem Fachwissens bezüglich RSA kein Schlüsselpaar mit der verfügbarenBibliothek generiert werden kann.

Auftrittswahrscheinlichkeit gering

Schwere des Schadens sehr gross

Massnahmen zur Vorbeugung Frühzeitig in die verfügbare Bibliothek libgmp einarbeiten.

Massnahmen zur Behebung Einbezug des Betreuers in die Problematik.

Status 29.03.2005 - Risiko definiert

12.04.2005 - In der Datei programs/rsasigkey/rsasigkey.c des strongSwan-Sourcecodeswird bereits ein RSA-Schlüssel generiert. Diese Funktion kann übernommen undangepasst werden.

28.04.2005 - Risiko konnte eliminiert werden. Der scepclient kann einen RSA-Schlüsselgenerieren und diesen DER-kodiert im PKCS#1-Format abspeichern. DieFunktionsweise des Schlüssels konnte durch Verschlüsselungs-Tests mitopenssl bestätigt werden.

Tabelle 39 Risiko "RSA-Schlüssel kann nicht erstellt werden"

12.2.2 Geforderte Ziele aus Zeitmangel nicht erreichbar

Risiko Die Aufgabenstellung kann sich im Projektverlauf als zu umfangreichherausstellen. Aus Zeitmangel können so nicht alle geforderten Features derSoftware implementiert werden.

Auftrittswahrscheinlichkeit gering bis mittel

Schwere des Schadens mittel

Massnahmen zur Vorbeugung Quellcode der vorhandenen strongSwan-Bibliotheken bereits früh überblickenund Komplexität der zu entwickelnden Software abschätzen.Implementierung Schrittweise planen, damit das Funktionieren der Softwarenicht erst am Schluss des Projektes getestet werden kann.Genügend Puffer planen, um gegebenenfalls eine Phase verlängern zu können.

Massnahmen zur Behebung Falls eine geplante Phase mehr Zeit als geplant in Anspruch nimmt, muss aufdie eingeplante Pufferzeit zurückgegriffen werden.Kann „SCEP für Linux strongSwan“ trotzdem nicht termingerecht implementiertwerden, muss die Aufgabenstellung mit dem Betreuer überarbeitet werden.


12.04.2005 - Das Ziel, ein SCEP-Server bereits Ende der Phase 1 installiert zu haben,konnte nicht erreicht werden.

28.04.2005 - Der PKCS#10-Request konnte in der Phase 2 wie geplant generiert werden.

23.05.2005 - Der SCEP-Request mit einem „preshared secret“ konnte nach Phase 3erfolgreich durchgeführt werden .

23.06.2005 - Risiko konnte eliminiert werden. Die Pufferzeit wurde dazu genutzt, umzusätzliche Features in den scepclient einzubauen.

Tabelle 40 Risiko "Geforderte Ziele aus Zeitmangel nicht erreichbar"


Studienarbeit „SCEP für Linux strongSwan“ Risikoanalyse

12.2.3 Kein lauffähiger SCEP-Server

Risiko Um die Funktionsweise des scepclients zu überprüfen und die Software zuTesten wird ein SCEP-Server benötigt. Da sich keiner der beteiligten Personenin diesem Gebiet auskennt, besteht ein geringes Risiko, dass dieser SCEP-Server nicht lauffähig installiert werden kann.

Auftrittswahrscheinlichkeit gering

Schwere des Schadens mittel

Massnahmen zur Vorbeugung Installation des SCEP-Servers bereits in der Einarbeitungsphase durchführenund Testen.

Massnahmen zur Behebung Alternatives SCEP-Server-Produkt, beispielsweise unter Windows, evaluierenund installieren.


12.04.2005 - Während der Phase 1 wurde versucht, den OpenSource SCEP-ServerOpenSCEP zu installieren. OpenSCEP konnte bis zum Ende der Phase 1 nichtvollständig mit der „preshared secret“-Funktionalität zum Laufen gebrachtwerden. Gemeinsam mit dem Betreuer wurde entschieden, dass anstelle vonOpenSCEP der Microsoft Windows 2003 Server mit SCEP-Unterstützunginstalliert wird.

28.04.2005 - Das Risiko konnte eliminiert werden: Nach dem Wechsel von OpenSCEP zurWindows 2003 CA konnte die SCEP-Funktionalität auch mit „preshared secret“erfolgreich getestet werden.

Tabelle 41 Risiko "Kein lauffähiger SCEP-Server"


Studienarbeit „SCEP für Linux strongSwan“ Programmierrichtlinien

12.3 Programmierrichtlinien

12.3.1 Code-Dokumentation

Die Dokumentation des C Quellcodes erfolgt mit Doxygen. Dabei handelt sich dabei um ein zuJavaDoc ähnliches Tool, welches aus dem Quelltext spezielle Kommentare extrahiert. Ausdiesen Informationen generiert Doxygen Dokumentationen in unterschiedlichsten Formaten,beispielsweise HTML-Dokumentationen oder man-pages. Informationen zur Installation undVerwendung von Doxygen können dem Dokument „Infrastruktur“ entnommen werden.

Um ein Element im Quelltext zu dokumentieren, wird ein spezieller Doxygen-Kommentareingefügt. Wir verwenden dazu die beiden folgenden Syntaxen:

/// Einzeiliger Doxygen-Kommentar /** * Mehr- * zeiliger * Doxygen- * Kommentar */

Folgende C-Kommentare werden von Doxygen nicht als Doxygen-Kommentare erkannt undsomit nicht in die Quellcode-Dokumentation eingenommen:

// Normaler C-Kommentar /* * Mehr- * zeiliger * C- * Kommentar */

Diese normalen C-Kommentare eignen sich z.B. zur Dokumentation von Abläufen innerhalbvon Funktionen, die zum Verständnis der Funktion selbst nicht notwendig sind.

Spezielle Tags ermöglichen das generieren von erweiterten Kommentaren, wobei wir uns aufdie folgenden beschränken1:

Tag Beschreibung

@file Definiert den Dateinamen der Quelltext-Datei

@brief Kurzbeschreibung des Elementes

@param Beschreibung eines Funktionsparameters

@return Beschreibung eines Rückgabewertes

@deprecated Element, welches nicht mehr benutzt werden soll

@bug Bug der noch ausgemerzt werden muss

@see Verweis auf ein anderes Element im Quelltext

Tabelle 42 Verwendete Doxygen-Tags

1 Weitere, von Doxygen unterstützte Tags, können dem Doxygen-Manual [DoxygenManual] entnommen werden.



12.3.2 Quellcode

12.3.2.1 Strukturierung

Bei der Strukturierung des Quellcodes wird der Stil verwendet, welcher in strongSwangrösstenteils zum Einsatz kommt:

– Geschweifte Klammern bei Funktionen auf einen neue Zeile

– Geschweifte Klammern bei Flusskontroll-Konstrukten auf neue Zeile

– Operatoren/Variablen/Zahlen immer mit Leerzeichen trennen

12.3.2.2 Namensgebung

Bei der Namensgebung von neuen Variablen und Funktionen halten wir uns an dieKonventionen, die in der Linux-Welt üblich sind. Bei Bezeichnungen neuer Funktionen undVariablen werden ganze Wörter mit „_“ zusammengesetzt, wobei die Teilwörter kleingeschrieben sind:

– Variablen werden klein geschrieben, zusammengesetzte Wörter mit „_“ zusammengehängt

– Funktionsnamen sind klein geschrieben, zusammengesetzte Wörter mit „_“zusammengehängt

– Strukturen (struct), Enums, typedefs werden klein geschrieben

– Konstantennamen in Grossbuchstaben, Teilwörter mit „_“ getrennt



12.3.2.3 Beispiel

Ein kleines Beispiel soll den Aufbau eines Dokumentes und die Strukturierung verdeutlichen:

/** @file doxytest.c * @brief Beschreibung der Datei. *//// Beschreibung Konstantendefinition#define EINE_KONSTANTE 123/// Beschreibung globale Variableint eine_variable;/** * @brief Kurzbeschreibung der Funktion * * Ausführliche Beschreibung der Funktion * und dessen Verwendung. * * @param[in] int_variable Beschreibung des * Parameters * @return Beschreibung des * Rückgabewertes */int fuktions_name(int int_variable){ //Beschreibung privater Variablen float float_variable = 12.4f; //Erläuterungen Algorithmus usw. if (funktions_aufruf()) { noch_eine_funktion(int_variable); } else { int_variable += 5; } /* Eine etwas ausführlichere * Beschreibung zu dem * was der Algorithmus hier * bewirken soll. */ while (int_ariable) { ///@todo Beschreibung Todo int_variable --; } return int_variable;}

Definition des DateinamensDoxygen-Kurzbeschreibung derDateiDoxygen-Beschreibung einerKonstanteDoxygen-Beschreibung einerVariable

Doxygen-Kommentar einerFunktion, mit Parametern undRückgabewert

Klammern bei Funktionen auf dienächste Zeile

Normaler C-Kommentar

Klammern bei Bedingungen usw.auf der nächsten Zeile,Klammern auch bei einzeiligenBlöcken setzen

Normaler C-Kommentar

Doxygen-Kommentar mit Todo-Vermerk


Studienarbeit „SCEP für Linux strongSwan“ Protokolle

12.4 Protokolle

12.4.1 Protokoll vom 21.03.2005

12.4.1.1 Allgemeines

Ort: HSR

Zeit: 13:00 Uhr

Teilnehmer: as, jh, mw

Protokollant: jh

12.4.1.2 Besprochene Punkte

– Der scepclient muss einen RSA-Schlüssel generieren. Als Hilfe kann der Quellcode vonopenac hinzugezogen werden

– PKCS#1 definiert das Format des Schlüssels (Infos unter www.rsa.com)

– Es muss herausgefunden werden, wie die Response des SCEP-Servers geparst werden kann

– Die Art der Quellcode-Dokumentation wird von den Studenten selbst gewählt => Präferenz:Doxygen

12.4.1.3 Entscheidungen

– Als erster Schritt soll ein eigenständiges Programm entwickelt werden, welches SCEPimplementiert. Vorgeschlagener Name: scepclient.

– Der RSA-Schlüssel muss lediglich im DER-Format gespeichert werden.

– Als erste Aufgabe soll der RSA-Schlüssel ASN.1-kodiert in einer Datei gespeichert werden.

– Der scepclient muss per Kommandozeilenparameter konfiguriert werden können(verwendete CA, Ort des CA-Zertifikats, URL des SCEP-Servers, etc.).

– Als Server kann entweder eine Windows- oder Linux-SCEP-Server verwendet werden.

– Für das PKCS#10-Format muss ein Generator geschrieben werden.

– Der scepclient muss lediglich die Zertifikatsanfrage mit einem „preshared secret“unterstützen. Polling ist optional und kann bei schnellem Vorankommen integriert werden.

– Zur Versionskontrolle kann subversion verwendet werden.

12.4.1.4 Nächste Sitzung

Mittwoch, 30.03.2005 um 13 Uhr, nachher jeden Montag um 13 Uhr



12.4.2 Protokoll vom 30.03.2005


Ort: HSR

Zeit: 13.00 Uhr


Protokollant: mw


– Funktionen für das Parsen von PKCS-Files sind vorhanden => pluto/pkcs.c– Funktionen fürs Synthetisieren von Zertifikaten sind vorhanden => openac– Beispiel für HTTP-Kommunikation mit libcurl ist ebenfalls vorhanden => ocsp– Beispiel für generierung von RSA-Schlüsseln mit libgmp => rsasigkey– libfreeswan enthält allgemeine Funktionen (strings, base64 usw...), siehe man-pages

– „whack“ ist ein Tool zum Steuern von Pluto

– Debugging: siehe log.h, verschiedene Debug-Levels

– Grundlegende Zertifikatsfunktionen => pluto/certs.c– Für Allokationen (malloc/free) stehen Wrapper zur Verfügung => pluto/defs.h– ASN.1 OIDs sind definiert durch oid.c/.h, werden aber durch Script generiert


Montag, 11.04.2005



12.4.3 Protokoll vom 11.04.2005


Ort: HSR

Zeit: 13:00 Uhr


Protokollant: jh


– Herr Steffen wurde darüber informiert, dass das LDAP-Verzeichnis für OpenSCEP noch nichtinstalliert werden konnte. Er konnte uns Beispiele zeigen, wie wir zur Behebung desProblems vorgehen könnten. Zudem wird er uns seine LDAP-Konfiguration per Mailzusenden.

– In der Datei rsasigkey.c ist bereits eine RSA-Schlüsselgenerierung enthalten, jedoch istdort der Wert 3 für den öffentlichen Exponenten des RSA-Schlüssels festgesetzt. Derentsprechende Code kann übernommen und der Exponent auf den Standardwert F4hangepasst werden


Montag, 18.04.2005 um 13:00 Uhr



12.4.4 Protokoll vom 18.04.2005


Ort: HSR

Zeit: 13.00 Uhr


Protokollant: mw


Wir haben mit Herrn Steffen den Stand der Software besprochen:

– Windows CA mit SCEP funktioniert nun endlich

– Das Generieren von RSA-Schlüsseln funktioniert

Den Quellcode dokumentieren wir mit Doxygen. Herr Steffen hat uns gebeten, eineDokumentation dazu zu erfassen, da er dieses ebenfalls für strongSwan einsetzen möchte.

Ouput des Keygens:

– Default in ipsec.d/secrets (als #define)

– Abbruch falls schon vorhanden, option zum Überschreiben (--force)

– Angabe des Dateinamens mit –out

– Ablegen unverschlüsselt als .der (Binär kodiert)

Eingabe des Passwortes:

– -p xxx xxx als Passwort

– -p Aufforderung für Passwort

– ohne Kein Challenge Passwort

Eingabe der Optionen soll über File möglich sein (--optionsfrom „file“)


Montag, 25.04.2005



12.4.5 Protokoll vom 25.04.2005


Ort: HSR

Zeit: 13:00 Uhr


Protokollant: jh


– Der aktuelle Stand der Arbeit wurde demonstriert: Generierung eines RSA-Schlüsselfunktioniert vollständig. Erst ein kleiner Teil des PKCS#10-Request kann bisher generiertwerden. Es wird erwartet, dass der PKCS#10-Request bis zum Ende der laufenden Woche(bis Freitag 29.04.2005) vollständig generiert werden kann.

– Bei der Einbindung einer Email-Adresse in den PKCS#10-Request müssen dieunterschiedlichen Formate für Emailadressen beachtet werden.

– Bei der Generierung des RSA-Schlüssels wird das erste und das letzte Bit der Primzahlen aufEins gesetzt. Laut Herrn Steffen ist dies Sicherheittechnisch kein Problem. Die Sicherheit isttrotzdem noch gewährleistet.

– Die Signierfunktionen sind in der Datei keys.c vom Pluto zu finden. Wie diese Funktionenangewendet werden, kann aus der Datei ocsp.c entnommen werden.

12.4.5.3 Entscheidungen

– Die Attribute des PKCS#10-Requests werden per Kommandozeile über einen Paramterangegeben. Dieser Parameter wird in LDAP-Schreibweise angegeben (z.B:“O=HSR,CN=Tester“). Zum Parsen dieses Parameters kann die bereits vorhandeneParserfunktion atodn verwendet werden.

– Die Projektarbeit wird wie geplant fortgesetzt und die aktuelle Phase per 29.04.2005abgeschlossen


Montag, 02.05.2005 um 13:00 Uhr



12.4.6 Protokoll vom 02.05.2005


Ort: HSR

Zeit: 13.00 Uhr


Protokollant: mw


– Der aktuelle Stand der Arbeiten wurde demonstriert. Das erstellen von PKCS#10-Requestsfunktioniert nun einwandfrei.

– Die Angabe eines „challenge password“ ist möglich, allerdings ist die Aufforderung zurEingabe noch nicht komplett. Dies ist noch zu erweitern.

– Das einbeziehen von SubjectAltNames wäre wünschenswert, um dort E-Mail-Adressen oderHostnamen anzugeben.


Montag, 23.05.2005



12.4.7 Protokoll vom 23.05.2005


Ort: HSR

Zeit: 13.00 Uhr


Protokollant: mw


– Die Implementierung der Request-Absetzung konnte doch noch realisiert werden, diePKCS#7-Verschlüsselung und Signierung hat sich allerdings als schwieriger als erwarteterwiesen.

– Symmetrisch kann mit DES verschlüsselt werden, 3DES wird noch heute eingebaut

– Die Prüfung für das Attribute „KeyUsage“ im CA-Zertifikat kann vorerst weggelassenwerden. Allerdings ist die Angabe von mehreren Zertifikaten notwendig, da z.B. Microsoft-CA verschiedene für „Key Encipherment“ und „Signing“ verwendet

– Dokumentation soll so erstellt werden wie eigentlich geplant:

– Software-Design, welches beschreibt wo welche Funktionen zu finden sind

– Beschreibung der Einzelnen Formate, Protokolle und Standards (PKCS, SCEP, ASN.1),damit auch ein nicht so versierter Leser die Arbeit versteht

– Beschreibung der Implementierung: Warum wurde das so gelöst, warum wurde dieserWege gewählt, usw.

– Definition von Testszenarien, mit Good Cases und auch Bad Cases

– Kurze Beschreibung zu Doxygen verfassen, damit Herr Steffen sich weniger einarbeitenmuss

– Weiteres vorgehen:

– 3DES implementieren, Verwendung von mehreren CA-Zertifikaten erlauben

– Dokumentation nachbessern, da diese in den letzten Wochen gelitten hat

– Reply vom SCEP-Server parsen, entschlüsseln, Zertifikat abspeichern (eigentlicheProjektphase)


Montag, 30.05.2005



12.4.8 Protokoll vom 07.06.2005


Ort: HSR

Zeit: 13.00 Uhr


Protokollant: jh


– Die Unterstützung der drei wichtigsten SubjectAltNames als erweiterte X.509v3 Attributekonnten implementiert werden

– Die Funktionalität zum Abholen der CA-Zertifikate über das SCEP-Protokoll wird nocheingebaut

– optionsfrom zeigt Probleme, wenn die geladene Datei Strings mit Hochkommas besitzt

– Das Laden von PEM-Dateien wird nicht implementiert, da der scepclient sonst gegen zuviele Modulen von Pluto gelinkt werden muss

– Die Memory Leaks konnten behoben werden

– Es wurde das Problem mit der base64-Kodierung gezeigt, wobei der kodierte String nach 64Zeichen ein Zeilenumbruch benötigt

– Das Copyright wird in jeder Source-Datei gleich eingebaut

– Für die --in und --out Parameter werden Standard-Filenamen eingebaut


Nach Absprache


Studienarbeit „SCEP für Linux strongSwan“ Anhang

13 Anhang

13.1 CD-StrukturNeben der Dokumentation zur Studienarbeit „SCEP für Linux strongSwan“ wird eine CD-ROMabgegeben. Die CD-ROM beinhaltet unter anderem die gesamte Dokumentation, denSourcecode des scepclients, sowie Standards und Links.

Die nachfolgende Auflistung1 gibt einen Überblick über den Inhalt dieser CD-ROM. Die ineckigen Klammern geschriebenen Dateinamen entsprechen dabei nicht dem vollständigenDateinamen auf der CD-ROM.

Pfad / Datei Inhalt / Beschreibung

/Codedokumentation/ Mit Doxygen generierte Quellcode-Dokumentation inden Formaten man-pages und HTML.

/Dokumentation/ Komplette Dokumentation im OpenOffice.org-Format.Details dazu sind dem Dokumentenverzeichnis zuentnehmen.

/Links/ Links zu den im Quellenverzeichnis angegebenenInternet-Quellen.

/Source/strongswan-2.4.1/ Quellcode von strongSwan 2.4.1 inkl. dem Quellcodedes scepclients.

programs/scepclient/ Quellcode des scepclients.tests/ Test-Scripts für die automatischen Tests des

scepclients./Standards/ Die im Quellenverzeichnis angegebenen Standards

und Drafts./Stuff/ Diverse Programme, Dokumente und Dateien.

[DoxygenManual] Doxygen Manual in der Version 1.4.2.[NW-Treiber] Windows 2003-Treiber für den Netzwerkadapter des

Testservers.[OpenSCEP-Patch1] Patch, um OpenSCEP kompatibel zu OpenSSL 0.9.7 zu

machen.[OpenSCEP-Patch2] Patch zur Korrektur eines Fehlers auf der OpenSCEP-

Weboberfläche.[OpenSCEP-Patch3] Patch zur Konfiguration der OpenSCEP-

Konfigurationsdatei.[scepclientForStrongSwan-Patch] Patch, um strongSwan in der Version 2.4.4 um die

SCEP-Funktionalität zu erweitern.[SSCEP-20040325] Sourcecode von sscep in der Version vom 25. März

2004.[Win2003 SCEP-Patch] SCEP-Addon für die Windows 2003 CA.jude-community-1_5_1.zip UML-Tool zur Erstellung der Sequenzdiagramme.openscep-0.4.2.tar.gz Quellcode von OpenSCEP in der Version 0.4.2.

1 In dieser Auflistung sind nicht alle Verzeichnisse und Dateien aufgelistet.



13.2 GlossarAusdruck Definition und Erklärung

3DES Triple Data Encryption Standard. Dreifache DES-Verschlüsselung mitdrei unterschiedlichen Schlüsseln.Die Schlüssellänge beträgt dadurch 168 Bit.

AES Advanced Encryption Standard. Symmetrisches Block-verschlüsselungsverfahren. Gilt als Nachfolger von DES und 3DES.Die Schlüssellänge kann 128, 192 oder 256 Bit betragen.

ASN.1 Abstract Syntax Notation One. Standard zur abstrakten Beschreibungvon Datentypen.

AsymmetrischeVerschlüsselung

Die asymmetrische Verschlüsselung ist die Verschlüsselung miteinem Schlüssel bestehend aus Public- und Private-Teil. Daten, diemit dem Public-Teil verschlüsselt wurden, können nur mit demPrivate-Teil entschlüsselt werden. Ein Beispiel von asymmetrischenVerschlüsselungsverfahren ist RSA.

BER Basic Encoding Rules. Definiert eine Kodierung von ASN.1Datentypen.

Block-Verschlüsselung Eine Block-Verschlüsselung kann nur Daten in Blöcken vonbestimmter Länge verschlüsseln. Die Blocklänge bei DES istbeispielsweise 64 Bit, bei RSA entspricht Sie der Länge desverwendeten RSA-Schlüssels.

CA Certification Authority. Zertifizierungsstelle für digitale Zertifikate.Gibt Zertifikate heraus.

challenge password Optionales Passwort, welches in einen PKCS#10-Zertifikats-Requesteinbezogen werden kann. Dieses Passwort kann später dazu genutztwerden, um ein mit diesem PKCS#10-Request erstelltes Zertifikat zuwiderrufen.SCEP verwendet den Wert dieses Feldes als „preshared secret“ zurautomatischen Authentisierung.

CRL Certificate Revocation List. Diese Liste wird normalerweise periodischvon einer CA herausgegeben und beinhaltet zurückgewiesene undsomit ungültige Zertifikate. Anhand dieser Liste kann festgestelltwerden, ob ein Zertifikat noch Gültigkeit hat.

DER Distinguished Encoding Rules. Definiert eine Kodierung von ASN.1Datentypen. DER ist ein Subset von BER.

DES Data Encryption Standard. Symmetrisches Block-Verschlüsselungsverfahren. Die Länge eines DES-Schlüssels beträgt56 Bit.

Digest Siehe Hashwert.



Ausdruck Definition und Erklärung

envelope Umschlag. PKCS#7 verwendet den Begriff für das Verschlüsseln vonDaten in einem virtuellen Briefumschlag, welcher nur vom Empfängergeöffnet werden kann.

GNU Gnu is Not Unix. Freie Implementierung eines kompletten Unix-Systems.

Hash-Funktion Eine Hash-Funktion erstellt aus einem beliebigen Dateninput eineeindeutige Repräsentation dieser Daten, ein so genannter Digest oderHashwert. Dabei muss das Ergebnis für den selben Input stets gleichausfallen. Eine Hash-Funktion ist nicht umkehrbar. Beispiele fürHash-Funktionen sind MD5 und SHA1.

Hashwert Ein Hashwert ist aus einer Hash-Funktion entstandener Wert festerLänge.

hybride Verschlüsselung Unter hybrider Verschlüsselung wird die Kombination dersymmetrischen mit der asymmetrischen Verschlüsselung verstanden.Da die asymmetrische Verschlüsselung mit höheren Schlüssellängenals die symmetrische Verschlüsselung arbeitet und somit die mehrRechenleistung benötigt, werden diese beiden Verfahren kombiniert.In IPsecwird beispielsweise die asymmetrischer Verschlüsselung nur zurAushandlung eines symmetrischen Schlüssel verwendet und dereigentliche Datenverkehr mit symmetrischer Verschlüsselungverschlüsselt.

IPsec IPsec ist ein Sicherheitsprotoll für IP-basierte Kommunikation. MitIPsec wird Vertraulichkeit, Authentizität und Integrität in IP-Netzwerken sichergestellt.

ITU-T ITU Telecommunication Standardization Sector. KordiniertTelekommunikations-Standards im Interesse der InternationalTelecommunication Union (ITU).

MD5 Message Digest Algorithm 5. Hash-Algorithmus der aus einembeliebigen Dateninput eine eindeutige 128 Bit-Repräsentationerstellt.

nonce Number used once. Diese Bezeichnung wird vor allem in derKryptographie verwendet und beschreibt eine Zahl, welche nureinmal benutzt wird. Sie dient dazu um Replay-Attacken zuverhindern.

OID Object Identifier. Eindeutiger Bezeichner, zusammengesetzt ausKnoten einer hierarchischen Struktur.

OSI Open System Interconnect. Teilt die Kommunikation im Netzwerk inunterschiedliche Layer ein.



Ausdruck Definition und Erklärung

PKCS Public Key Cryptographic Standards. Unter PKCS werden mehrerekryptographische Standards zusammengefasst, die von der FirmaRSA Security Inc. entwickelt wurden.

PKCS#1 Dieser Standard beschreibt ein Public-Key Verfahren auf derGrundlage des RSA-Algorithmus.

PKCS#10 Dieser Standard beschreibt einen Syntax für Zertifikatsanfragen.

PKCS#7 In diesem Standard wird das Format zur Übertragung vonbeispielsweise verschlüsselten oder signierten Nachrichten definiert.

PKI Public-Key Infrastruktur.

preshared secret Gemeinsames Geheimnis zweier Parteien. Ein Passwort ist einBeispiel eines „preshared secret“.

Replay-Attacke Von einer Replay-Attacke wird gesprochen, wenn ein Angreifer einDatenpaket abhört und dieses, z.B. zur Vortäuschung einer falschenIdentität, ein zweites mal an den Empfänger sendet.

RFC Request For Comments. Vorschlag eines offenen Standards/Protokollsinklusive dessen genauer Beschreibung.

RSA Asymmetrisches Kryptosystem benannt nach seinen ErfindernRonald L. Rivest, Adi Shamir und Leonard Adleman.

selfsigned certificate Ein selfsigned certificate ist ein digitales Zertifikat, welches mit demprivaten Schlüssel des Zertifikatsbesitzers unterschrieben wurde. EinBeispiel für ein solches selfsigned certificate ist das root-Zertifikateiner Zertifizierungsstelle wie beispielsweise VeriSign.

SHA1 Secure Hash Algorithm 1. SHA1 ist wie MD5 ein Hash-Algorithmus. Ererstellt aus einem beliebigen Dateninput eine eindeutige 160-BitRepräsentation, welche eindeutig ist.

Signatur Mit einer elektronischen Signatur wird die Integrität und Authentizitätelektronischer Daten sichergestellt.

SymmetrischeVerschlüsselung

Unter symmetrischer Verschlüsselung wird eine Verschlüsselung miteinem einzigen Schlüssel verstanden. Mit diesem Schlüssel werdendie Daten verschlüsselt und können auch wieder entschlüsseltwerden. Im Gegensatz zu der asymmetrischen Verschlüsselung istdie symmetrische Verschlüsselung um Faktoren schneller. Beispielevon symmetrische Verschlüsselungsverfahren sind DES, 3DES undAES.

VPN Virtual Private Network. Ein über ein unsicheres Netzwerk gelegtesvirtuelles Netzwerk, welches kryptographisch gesichert ist.Verwendet oft IPSec.

X.509 Der X.509-Standard ist ein Standard der ITU-T für PKIs. Unteranderem wird darin das Format digitaler Zertifikate beschrieben.



13.3 QuellenverzeichnisKürzel Information zur Quelle

[Doxygen] „Doxygen“Offizielle Homepage des Quellcode-Dokumentations-WerkzeugDoxygenhttp://www.stack.nl/~dimitri/doxygen/

[DoxygenManual] Dimitri van Heesch „Doxygen Manual for version 1.4.2“Manual für Doxygen in der Version 1.4.2

[GentooManual] „Gentoo Linux x86 Handbook“Deutsches Installations-Handbuch der Gentoo-Linux Distribution fürx86-Platformenhttp://www.gentoo.org/doc/de/handbook/handbook-x86.xml

[OpenSCEP] „OpenSCEP“Homepage der OpenSource SCEP-Implementierunghttp://openscep.othello.ch/

[OCAGuides] Chris Covell,Michael Bell „OpenCA Guides for 0.9.2+“Online-Version: http://www.openca.org/openca/docs/online/

[OpenCA] „OpenCA“http://www.openca.org

[OID-Tree] „OID assignments“Sammlung von OIDs zum Durchsuchenhttp://www.alvestrand.no/objectid/top.html

[PKCS1v2.1] RSA Laboratories „PKCS #1 v2.1 RSA Cryptography Standard“Version 2.1, 14. Juni 2002

[PKCS7v1.5] RSA Laboratories „PKCS#7 Cryptographic Message Syntax Standard“Version 1.5, 1. November 1993

[PKCS10v1.7] RSA Laboratories „PKCS 10 Certification Request Syntax Standard“Version 1.7, 26. Mai 2000

[RFC1421] J. Linn „Privacy Enhancement for Internet Electronic Mail“RFC 1421, Februar 1993

[RFC2510] C. Adams, Entrust Technologies, S. Farrell„X.509 Public Key Infrastructure Certificate Management Protocols“März 1999

[RFC2986] M. Nystrom, B. Kaliski, RSA Security „Certification Request SyntaxSpecification“Version 1.7, November 2000



Kürzel Information zur Quelle

[SCEPv11] Xiaoyi Liu, Cheryl Madson, David McGrew, Andrew Nourse, CiscoSystems „Cisco Systems' Simple Certificate Enrollment Protocol (SCEP)“SCEP Draft in der Version 11 vom 11. Februar 2005

[SSCEP] „SSCEP - Simple SCEP client for Unix“http://www.klake.org/~jt/sscep/

[X680-0207] ITU-T „Abstract Syntax Notation One (ASN.1) - Specification of BasicNotation“Juli 2002

[Win2003 SCEP-Patch] „SCEP-Addon für Windows 2003 CA“http://go.microsoft.com/fwlink/?LinkId=32060



13.4 DokumentenverzeichnisDokument Dateiname Inhalt

Abstract Abstract.sxw Dieses Dokument beinhaltet das Abstractder Studienarbeit. Darin wird dieStudienarbeit auf einer A4-Seitezusammengefasst.

Aufgabenstellung Aufgabenstellung.sxw Enthält die Aufgabenstellung derStudienarbeit „SCEP für LinuxstrongSwan“, formuliert von Prof. Dr.Andreas Steffen.

CD-Struktur1 CDStruktur.sxw Die Struktur der abgegeben CD-ROM wirdin diesem Dokument beschrieben. Die CD-ROM besteht primär aus der gesamtenDokumentation und dem Sourcecode desscepclients.

Einleitung Einleitung.sxw Beinhaltet die Einleitung zurStudienarbeit. Zielgruppe diesesDokuments sind Ingenieure, die einenÜberblick über die Problemstellung und dieDokumentationsstruktur der Studienarbeitgewinnen möchten.

Erfahrungsberichte Erfahrungsberichte.sxw Dieses Dokument beinhaltet dieErfahrungsberichte der beteiligtenStudenten.

Glossar1 Glossar.sxw Beinhaltet das Glossar zur ganzenDokumentation.

Infrastruktur Infrastruktur.sxw Die verwendete Hard- und Softwarewährend der Studienarbeit ist in diesemDokument beschrieben. Zudem enthältdieses Dokument mehrere Anleitungen,z.B. zur Installation der Windows CA mitSCEP-Unterstützung.

Installationsanleitung Installationsanleitung.sxw Damit „SCEP für Linux strongSwan“genutzt werden kann, muss derstrongSwan-Sourcecode um die SCEP-Funktionalität erweitert werden. Dazu wirdein Patch installiert. Die Anleitung zurInstallation dieses Patches zusammen miteiner Beispielkonfiguration ist diesemDokument zu entnehmen.

1 Dokument ist Teil des Anhangs.



Dokument Dateiname Inhalt

Management Summary ManagementSummary.sxw Dieses Dokument beinhaltet dasManagement Summary, welches sich anPersonen mit wenig bis keineFachkenntnisse richtet.

Programmierrichtlinien Programmierrichtlinien.sxw Die Richtlinien für Code undCodedokumentation sind diesemDokument zu entnehmen.

Projektplan Projektplan.sxw Im Projektplan ist das Vorgehen währendder Studienarbeit definiert. Darin sind diePhasen und die Meilensteine festgehalten.Zusätzlich enthält dieses Dokument auchstatistische Auswertungen.

Protokoll vom XY Protokoll_XY.sxw Jede Betreuer-Sitzung wurde protokolliertund in einem Protokoll festgehalten.

Quellenverzeichnis2 Quellenverzeichnis.sxw Auf die Quellen dieser Arbeit wird indiesen Dokument verwiesen.

Resultate Resultate.sxw Diesem Dokument enthält die Ergebnisseund Schlussfolgerungen der Arbeit.

Risikoanalyse Risikoanalyse.sxw Dieses Dokument beinhaltet dieRisikoanalyse.

Software-Design SoftwareDesign.sxw Beinhaltet die Implementierungs-Detailsdes scepclients. Jedes Modul wird darindetailliert beschrieben.

Tasks2 Tasks.sxc Alle Arbeitspakete der Studienarbeit sinddiesem Dokument zu entnehmen.Zusätzlich ist darin auch der Soll/Ist-Vergleich der Arbeitszeiten ersichtlich.

Technologien Technologien.sxw Der scepclient baut aufunterschiedlichsten Technologien auf. Diewichtigsten Technologien und derenFunktionsweise sind in diesem Dokument,zum Teil sehr ausführlich, beschrieben.

Tests Tests.sxw In diesem Dokument ist dokumentiert,was und wie getestet wurde.

Zeiterfassung J. Hutter3 jh.sxc Beinhaltet die detaillierte Zeiterfassungvon Jan Hutter.

Zeiterfassung M. Willi2 mw.sxc Beinhaltet die detaillierte Zeiterfassungvon Martin Willi.

2 Dokument ist Teil des Anhangs.3 Dokument ist nicht Teil der Dokumentation und ist auf der CD-ROM zu finden.



13.5 TabellenverzeichnisTabelle 1 Codierung von Knoten in OIDs......................................................................... 15Tabelle 2 DER-Kodierung untersucht am Beispiel eines PKCS#10-Requests......................... 16Tabelle 3 Inhaltstypen einer PKCS#7-Message................................................................ 20Tabelle 4 Felder des PKCS#7-Datentyps signedData.........................................................21Tabelle 5 SignerInfo-Typ des PKCS#7-Datentyps signedData............................................ 22Tabelle 6 Felder des PKCS#7-Datentyps envelopedData................................................... 24Tabelle 7 RecipientInfo-Typ des PKCS#7-Datentyps envelopedData....................................25Tabelle 8 encryptedContentInfo-Typ des PKCS#7-Datentyps envelopedData........................25Tabelle 9 Attribute eines SCEP-Requests........................................................................ 31Tabelle 10 Mögliche Antworten auf einen SCEP-Request....................................................32Tabelle 11 Attribute eines SCEP-Replys.......................................................................... 32Tabelle 12 DER-kodierte PKCS#7-Message..................................................................... 35Tabelle 13 Module des scepclients................................................................................. 37Tabelle 14 Testfall "cacert"........................................................................................... 62Tabelle 15 Testfall "pkcs1"............................................................................................ 62Tabelle 16 Testfall "pkcs10.1"....................................................................................... 63Tabelle 17 Testfall "pkcs10.2"....................................................................................... 63Tabelle 18 Testfall "pkcs7.1"......................................................................................... 63Tabelle 19 Testfall "pkcs7.2"......................................................................................... 63Tabelle 20 Testfall "enroll.1"......................................................................................... 64Tabelle 21 Testfall "enroll.2"......................................................................................... 64Tabelle 22 Testfall "enroll.3"......................................................................................... 64Tabelle 23 Testfall "enroll.4"......................................................................................... 64Tabelle 24 Eingesetzte Entwicklungs-Software und Bibliotheken.........................................66Tabelle 25 Eingesetzte Dokumentationswerkzeuge........................................................... 66Tabelle 26 Verschiedene CAs mit SCEP-Unterstützung im Vergleich.................................... 68Tabelle 27 Hardware des Testservers............................................................................. 69Tabelle 28 Partitionierung des Testservers...................................................................... 70Tabelle 29 Einstellungen für die Windows 2003 Server-Installation.....................................77Tabelle 30 Installierte Roles auf dem Windows 2003 Server.............................................. 77Tabelle 31 Zusätzliche Softwarepakete auf dem Windows 2003 Server................................78Tabelle 32 Projektphasen der Studienarbeit.................................................................... 87Tabelle 33 Erzeugnisse nach Phase "Einarbeiten"............................................................. 87Tabelle 34 Erzeugnisse nach Phase "Generierung PKCS#10"..............................................88Tabelle 35 Erzeugnisse nach Phase "Generierung SCEP-Request"....................................... 88Tabelle 36 Erzeugnisse nach Phase "Speicherung Zertifikat".............................................. 89Tabelle 37 Erzeugnisse nach Phase "Erweiterungen"......................................................... 89Tabelle 38 Erzeugnisse am Ende der Studienarbeit...........................................................89Tabelle 39 Risiko "RSA-Schlüssel kann nicht erstellt werden".............................................92Tabelle 40 Risiko "Geforderte Ziele aus Zeitmangel nicht erreichbar".................................. 92Tabelle 41 Risiko "Kein lauffähiger SCEP-Server"............................................................. 93Tabelle 42 Verwendete Doxygen-Tags............................................................................ 94



13.6 AbbildungsverzeichnisAbbildung 1 Aufbau eines DER-kodierten ASN.1-Datentyps............................................... 14Abbildung 2 Kodieren einer ASN.1 OID........................................................................... 15Abbildung 3 DER-kodierter PKCS#10-Request................................................................. 16Abbildung 4 Vereinfachter Ablauf eines Zertifikat-Requests mit SCEP..................................26Abbildung 5 Zertifikatsbezug im "automatic mode".......................................................... 27Abbildung 6 Zertifikatsbezug im "manual mode".............................................................. 27Abbildung 7 Bezug der CA-Zertifikate über SCEP............................................................. 28Abbildung 8 Prinzipieller Aufbau des scepclients.............................................................. 36Abbildung 9 DER-kodierter ASN.1 Integer....................................................................... 38Abbildung 10 DER-kodierte ASN.1 Sequenz..................................................................... 38Abbildung 11 Ablauf von http_do_scep_request mit PKI_OPERATION................................. 42Abbildung 12 Ablauf beim Aufruf von pkcs10_build_chunk................................................ 45Abbildung 13 Ablauf beim Aufruf von pkcs10_write_to_file................................................46Abbildung 14 Verschlüsseln der Daten in pkcs7_encrypt_data........................................... 47Abbildung 15 Erstellen der Signatur in pkcs7_sign........................................................... 48Abbildung 16 Ablauf beim Aufruf von scep_build_pkcs_req_chunk..................................... 50Abbildung 17 Ablauf beim Aufruf von scep_build_get_cert_init_req_chunk.......................... 51Abbildung 18 Ablauf beim Aufruf von scep_parse_pkcs_rep_chunk.....................................52Abbildung 19 Entnehmen von drei Bytes bei der base64-Kodierung.................................... 54Abbildung 20 Aufteilung von drei Bytes in vier Bytes bei der base64-Kodierung................... 54Abbildung 21 Ablauf beim Erstellen eines „selfsigned“ Zertifikats....................................... 56Abbildung 22 Ablauf beim Beziehen eines CA-Zertifikates................................................. 58Abbildung 23 Ablauf eines Enrollments........................................................................... 59Abbildung 24 Grobe Projektübersicht............................................................................. 90Abbildung 25 Arbeitsaufwand Soll/Ist-Vergleich............................................................... 90


Documents

Simple Certificate Enrollment Protocol f¼r Linux strongSwan