30.3 Den Durchblick behalten
In der IT werden Verschlüsselungen hauptsächlich zur Absicherung von Kommunikation, zur sicheren Aufbewahrung von Daten und zur Prüfung der Integrität und Authentizität verwendet. Dabei entsteht das Problem, die benötigten Schlüssel sicher zu übertragen.
30.3.1 Das Grundproblem
Jede Verschlüsselung muss folgende drei Punkte sicherstellen:
-
Vertraulichkeit
Nur dazu berechtigte Personen sollen in der Lage sein, Daten zu entschlüsseln. -
Integrität
Die Daten müssen vollständig und unverändert sein. -
Authentizität
Der Absender muss identifizierbar sein.
Zwei Konzepte haben sich zum Erreichen dieser Ziele durchgesetzt: zum einen die Public Key Infrastructure (PKI)[ 57 ] und zum anderen das Prinzip der Pretty Good Privacy (PGP).
30.3.2 Verwendungszwecke
Vorab muss noch darauf hingewiesen werden, dass sich Verschlüsselung nicht nur auf Daten oder Nachrichten bezieht. Typische Anwendungen von Verschlüsselungen sind:
-
elektronische Signaturen (elektronischer Ausweis)
-
Absicherung von Netzwerkprotokollen (zum Beispiel HTTPS, IPsec oder SSH)
-
Schutz von E-Mails (S/MIME oder PGP)
30.3.3 Umsetzung mithilfe einer PKI
Eine Public Key Infrastructure stellt eine hierarchische Struktur bereit. Eine Kopfstelle (CA[ 58 ]) stellt Zertifikate für Personen oder Server aus. Diese Zertifikate enthalten alle notwendigen Daten und können über die CA geprüft werden. Eine PKI besteht aus den in Abbildung 30.4 dargestellten Elementen.
Abbildung 30.4 Aufbau einer PKI
Der Antragsteller identifiziert sich, je nach benötigtem »Grad« der Sicherheit, bei der RA[ 59 ], Schritt (1). Dies kann über die Angabe einer E-Mail-Adresse erfolgen, über die Postzustellung einer Kopie des Ausweises oder über weitere Maßnahmen. Die RA prüft die Daten und erteilt der CA, wenn die entsprechenden Anforderungen erfüllt sind, den Auftrag, ein Zertifikat für den Antragsteller zu erstellen (2). Dieses Zertifikat (3) besteht wiederum aus zwei Elementen: zum einen aus dem eigentlichen Zertifikat, an das der öffentliche Schlüssel angehängt ist, und zum anderen aus dem privaten Schlüssel. Die CA teilt die ausgestellten Zertifikate wiederum der VA[ 60 ] mit. Über die VA kann die Gültigkeit des Zertifikats von Dritten (Reviewer in Abbildung 30.4) geprüft werden (4–6).
Ein weiterer wesentlicher Bestandteil einer PKI ist die CRL[ 61 ]. Wenn ein Zertifikat korrumpiert wurde oder verloren ging, kann es gesperrt werden. Die zuständige CA nimmt dieses Zertifikat dann in die CRL auf, sodass bei einer Prüfung das Zertifikat abgelehnt wird. Die Prüfung kann über den Download von CRLs erfolgen oder aber online. Dafür wurde das Online Certificate Status Protocol (OCSP) geschaffen, das eine Online-Abfrage ermöglicht.
Es wird zwischen privaten und offiziellen PKIs unterschieden. Der Verschlüsselungsstandard einer privaten PKI entspricht dem einer öffentlichen, nur dass bei einer privaten PKI nicht für jedermann die Gültigkeit und Authentizität geprüft werden kann. Gerade im Bereich Webserver (HTTPS) empfiehlt es sich daher, ein offizielles Zertifikat einzusetzen.
Diese kostenpflichtigen offiziellen Zertifikate verhindern, dass die Benutzer eine Warnmeldung erhalten, da ein selbst erstelltes Zertifikat nicht bei einer der bekannten Stellen geprüft werden kann. Diese offiziellen PKIs werden als TrustCenter bezeichnet. In Deutschland gibt es eine Vielzahl von TrustCentern; hier eine kleine Auswahl:
-
TCTrust (www.tctrustcenter.de)
-
Telesec (www.telesec.de)
-
Verisign (www.verisign.de)
-
PSW Group (www.psw.net)
30.3.4 X.509
Bei X.509 handelt es sich um den De-facto-Standard für Zertifikate. Ein Zertifikat, das nach der aktuellen Version X.509v3 erstellt wurde, beinhaltet folgende Elemente:
-
Version
-
Seriennummer
-
Algorithmen-ID
-
Aussteller
-
Gültigkeit (von/bis)
-
Zertifikatsinhaber
-
Subject Public Key Info:
-
Public-Key-Algorithmus
-
Subject Public Key
-
-
eindeutige ID des Ausstellers (optional)
-
eindeutige ID des Inhabers (optional)
-
Erweiterungen
-
Zertifikatssignaturalgorithmus
-
Zertifikatssignatur
Diese Zertifikate können nicht nur für Personen ausgestellt werden, sondern ebenso für Gruppen, Server, Clients oder explizite andere Verwendungszwecke. X.509-Zertifikate werden für Einzelpersonen in vier unterschiedlichen Klassen ausgestellt:
-
Class 0
Demo-Zertifikate, die nur für Testzwecke gedacht und mit beschränkter Gültigkeitsdauer versehen sind -
Class 1
Zertifikat mit geringem Nachweis der Identität. Es wird lediglich sichergestellt, dass eine E-Mail-Adresse existiert und der Besitzer des öffentlichen Schlüssels Zugriff auf dieses E-Mail-Konto besitzt. Diese Zertifikate finden oft im privaten Sektor Anwendung. -
Class 2
Zertifikat dieser Klasse werden auch als Unternehmenszertifikate bezeichnet. Hierbei genügen eine Kopie des Handelsregisterauszugs zur Feststellung der zeichnungsberechtigten Person sowie ein schriftlicher Auftrag. -
Class 3
Zertifikate mit persönlicher Identitätsprüfung. Der Aussteller bestätigt mit diesem Zertifikat, dass der Besitzer einwandfrei identifiziert wurde (Personalausweis/Reisepass). Hauptsächliche Einsatzgebiete sind das Internet-Banking, das Online-Shopping und die elektronische Kommunikation mit Behörden (Übermittlung von Steuerdaten und die elektronische Antragstellung).
Zertifikate werden in unterschiedlichen Formaten ausgeliefert. Tabelle 30.3 zeigt übliche Formate (Dateinamenerweiterungen) für X.509-Zertifikate.
Endung | Typ |
---|---|
.CER | Canonical Encoding Rules-kodiertes Zertifikat oder Zertifikatsfolgen |
.CRT | Distinguished Encoding Rules- oder Base64-kodiertes Zertifikat |
.CSR | Base64-kodierte Zertifizierungsanfrage des öffentlichen Schlüssels (plus weitere Metadaten des Besitzers) an eine CA, umschlossen von -----BEGIN CERTIFICATE REQUEST----- und -----ENDCERTIFICATE REQUEST----- |
.DER | Distinguished Encoding Rules-kodiertes Zertifikat |
.P12 | PKCS#12, kann öffentliche Zertifikate und private Schlüssel (kennwortgeschützt) enthalten |
.P7C | PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertifikat(en) oder Zertifikatsperrliste(n) |
.P7B | siehe .P7C |
.PEM | Base64-kodiertes Zertifikat, umschlossen von -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- |
.PFX | siehe .P12 |
Tabelle 30.3 Dateinamenerweiterungen für X.509-Zertifikate
30.3.5 Ein anderer Ansatz: PGP (Web-of-Trust)
Bei einem Web-of-Trust handelt es sich um eine sogenannte Vertrauenskette. Dieser liegt folgende Überlegung zugrunde:
Person Alpha vertraut der Person Beta. Da Person Beta auch Person Gamma vertraut, kann auch Person Alpha der Person Gamma vertrauen.
Dieses Prinzip findet bei Pretty Good Privacy (PGP) Anwendung. Dieses von Peter Zimmermann initiierte Konzept wurde geschaffen, um jedermann das Recht auf Privatsphäre auch im E-Mail-Verkehr zu ermöglichen. Da dieses Tool von den US-Behörden als starke Kryptografie eingestuft wurde und somit unter das Waffenexportgesetz fiel, konnte die Veröffentlichung in Europa nur über einen Trick erfolgen: Peter Zimmermann veröffentlichte den Quellcode in Buchform, sodass dieser in Europa nachgebildet werden konnte.
Da PGP patentgeschützt ist, gibt es die freie Implementierung GnuPG (GNU Privacy Guard), die nach demselben Verfahren arbeitet, dabei aber ausschließlich auf patentfreie Algorithmen zurückgreift.[ 62 ] Mit diesem Verfahren können Daten/Nachrichten signiert und sogar vollständig verschlüsselt werden. GnuPG implementiert sowohl den OpenPGP-Standard als auch – seit der Version 2.0 – S/MIME.