Allgemein:Zertifikate-SymmetrischeAsymmetrische

Zertifikate Allgemein

Zertifikate sind selbst für IT-Profis schwierig zu verstehen und oft im täglichen IT-Leben eine Herausforderung. Der korrekte Umgang mit Zertifikaten ist jedoch -speziell in der Security- unerlässlich. Mit dem Begriff "Zertifikat" (certificate) wird dabei sehr "allgemein" Umgegangen und man versteht dabei meistens darunter "öffentliche" Zertifikate und/oder "private" Zertifikate. Dabei ist Wichtig zu wissen, dass ein "öffentliches" (Public Key) Zertifikat auf einem "privaten" (Private Key) Zertifikat basiert.

Ein Webserver-Zertifikat dient der Authentifizierung eines Servers gegenüber dem Browser. Der Server kann sich aber nur dann ausweisen, wenn er auch den "privaten" Schlüssel besitzt. Der Browser hingegen benötigt das Zertifikat (Public Key), um die Authentizität der vom Server erhaltenen Daten zu überprüfen. Folglich benötigt man ein Zertifikat mit "private" Schlüssel, um einen sicheren Kommunikationskanal anzubieten.

Zertifikate - Verschlüsselung

Es gibt Grundsätzlich zwei Arten von Verschlüsselungsverfahren:

       [Symmetrische Verschlüsselung]
       [Asymmetrische Verschlüsselung]

Zertifikate - Symmetrische Verschlüsselung

       [Symmetrische Verschlüsselung]
       
       Symmetrische Verschlüsselung erfordert, dass jeder Kommunikationspartner im Besitz eines gemeinsamen Schlüssels
       ([Pre-Shared Key]) ist. Nur dann ist er in der Lage, verschlüsselte Daten zu lesen, zu senden und zu verändern. 
       Aufgrund der Funktionsweise der symmetrischen Verschlüsselung ist es von grösster Wichtigkeit, dass der Schlüssel
       nicht in die falschen Hände gerät. Mit steigender Anzahl von Teilnehmern erhöht sich auch die Gefahr, dass der 
       Schlüssel kompromittiert wird. Da jeder Teilnehmer denselben Schlüssel verwendet, muss dieser an jeden übermittelt 
       werden, was einen großen Sicherheitsnachteil darstellt. Die bekanntesten Algorithmen zur symmetrischen Verschlüsselung 
       sind:
       
       [Advanced Encryption Standard" (AES)]
       [Data Encryption Standard" (DES)]
       
       NOTE DES stellt den Vorgänger dar von AES und sollte nicht mehr benutzt werden!
       
       

Zertifikate - Asymmetrische Verschlüsselung

       [Asymmetrische Verschlüsselung]
       
       Verwendet einen "öffentlichen" (Public Key) und einen "privaten" (Private Key) Anteil, die "mathematisch" in Verbindung stehen.
       Der geheimer oder privater Schlüssel (Private Key) gehört nur einer einzigen Person und darf nicht öffentlich gemacht oder 
       weitergegeben werden. Der öffentliche Schlüssel (Public Key) darf und "muss" sogar an Kommunikationspartner verteilt werden. 
       Die asymmetrische Verschlüsselung bildet so die Grundlage für Zertifikate.
       
       NOTE Diese Verschlüsselungsart "Asymmetrisch" wird auch "[Public Key Cryptography]" genannt.
       
       

Alles beginnt mit dem "privaten" Schlüssel (Private Key). Aus ihm wird der "öffentliche" Schlüssel (Public Key) erzeugt und kann jeder Zeit wiederhergestellt werden. Daten, die mit einem der beiden "verschlüsselt" wurden, können nur mit dem anderen wieder "entschlüsselt" werden. Die Übermittlung von verschlüsselten Daten beruht darauf, dass die Daten mithilfe des "öffentlichen" Schlüssels (Public Key) des Empfängers "verschlüsselt" werden, so dass nur noch der Empfänger in der Lage ist, den Klartext zu ermitteln. Denn nur er befindet sich im Besitz des passenden "öffentlichen" Schlüssels (Public Key).

Zertifikate - Asymmetrische Verschlüsselung und die "Diffie-Hellman" Problematik

Die Asymetrische Verschlüsselung wie schon im vorherigen Artikel erklärt basiert im Grundsatz auf einem "private" Key und einem darauf basierenden "public" Key. Zur Erinnerung: Alles beginnt mit dem "privaten" Schlüssel (Private Key). Aus ihm wird der "öffentliche" Schlüssel (Public Key) erzeugt und kann jeder Zeit wiederhergestellt werden. Daten die mit einem "Public-Key" verschlüsselt weren können nur mit dem korrespondierenden "Private-Key" entschlüsselt werden. Die Übermittlung von verschlüsselten Daten beruht darauf, dass die Daten mithilfe des "öffentlichen" Schlüssels (Public Key) des Empfängers "verschlüsselt" werden, so dass nur noch der Empfänger in der Lage ist, den Klartext zu ermitteln. Denn nur er befindet sich im Besitz des passenden "privaten" Schlüssels (Public Key). Diese Verschlüsselungsart "Asymmetrisch" wird auch "[Public Key Cryptography]" genannt.

In diesem Verfahren gibt es einem Umstand dem Rechnung zu tragen. Formal besteht ein "Public-Key-Verschlüsselungsverfahren" aus drei Algorithmen:

       - Der Schlüsselerzeugungsalgorithmus erzeugt zu einem gegebenen Sicherheitsparameter (2048bit, 4096bit) ein Schlüsselpaar, das aus einem öffentlichen
         (Oeffentlicher Key "public") und dem dazugehörigen geheimen Schlüssel (Privater Key "private") besteht.
       - Der Verschlüsselungsalgorithmus erzeugt aus einem Klartext unter Verwendung des öffentlichen Schlüssels (Oeffentlicher Key "public") einen Geheimtext (Cyphertext).
       - Der Entschlüsselungsalgorithmus berechnet zu einem Geheimtext (Cyphertext) unter Verwendung des geheimen Schlüssels den passenden Klartext.

Das Problem: Bei der Daten-Übertragung mittels zB SSL/TLS werden mit einem Lanzeitschlüssel (pub-priv-key) sogenannte Sitzungsschlüssel für jede Session erzeugt (Session-keys). Hat ein Angreifer Zugriff auf den Langzeitschlüssel so können sämtliche vergangenen Sitzungsschlüssel errechnet werden und somit die gesamte Kommunikation entschlüsselt werden. Dies wird durch Perfect Forward Secrecy (PFS) unterbunden. Ein möglicher Angreifer kann trotz Kenntnis des Langzeitschlüssels keinerlei Rückschlüsse auf die ausgehandelten Sitzungsschlüssel ziehen. Bei zB. TLS wird dies dadurch erreicht, dass der Langzeitschlüssel zu einem Signaturverfahren gehört und nur benutzt wird, um Kurzzeitschlüssel zu signieren. Mit diesen wird jeweils durch einen Diffie-Hellman-Schlüsselaustausch ein Sitzungsschlüssel ausgehandelt. Wird ein Server kompromittiert, erfährt der Angreifer nur den langfristigen Signaturschlüssel und die Sitzungsschlüssel gerade aktiver Verbindungen. Die Sitzungsschlüssel zurückliegender Verbindungen sind bereits gelöscht und lassen sich nicht mehr rekonstruieren. In diesem Verfahren werden sogenannte "Diffie-Hellmann-Parameter" (auch Diffie-Hellmann-Group) verwendet. Eine DH-Group ist eine Liste von langen Primzahlen welche für das PFS-Verfahren (Perfect Forward Secret) verwendet werden. Bis vor kurzem galten diese Listen als sicherheits-unkritisch und wurden aus diesem Grund vom Hersteller "vorberechnet" und ausgeliefert. Somit verwenden tausende Rechner die gleichen Listen. Seit kurzem steht dieses Verfahren unter Kritik und es wird empfohlen eigene DH-Groups/Params zu erzeugen. Siehe auch:

       https://weakdh.org/sysadmin.html

Diesem Umstand kann abgeholfen werden dh. indem eigenen "DH" Parameter erstellt werden. Dabei ist jedoch zu berücksichtigen, dass man im Vorraus nicht weiss welcher Parameter benutzt werden soll dh. einige Clients kommen mit "hardcoded" Parameter und fordern einen "1024" Code an und andere wiederum "512". Dies zwingt uns e nachdem mehrere dieser "DH" Parameter zur Verfügung zu stellen. Diese "DH" Parameter die erstellt werden sind nicht Installations spezifisch dh. Sie können durchaus auch auf einem anderen Server erstellt werden und für mehrere Installationen benutzt werden. Um so einen "DH" Parameter auf einem Linux System anhand "OpenSSL" zu erzeugen kann folgendes durchgeführt werden:

       # mkdir /opt/DH-Param
       # chmod 700 /opt/DH-Param
       # chown root:root /opt/DH-Param 
       # cd /opt/DH-Param

Nun erzeuge zB einen "256bit" langen "DH" Parameter:

       # openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:256 -out dh256.pem
       ........+......+..............+.......+...+...+..+........+.............++*++*++*++*++*++*++*++*++*++*++*++*

Nach der Erzeugung kann der "DH" Parameter ebenfalls mit folgenden Kommando als "text ausgegeben werden:

       # openssl pkeyparam -text -in dh256.pem 
       -----BEGIN DH PARAMETERS-----
       MCYCIQD1xBUy+F1DHmgT6t7ET7vHXN1Sm2TbvmlXfbQeoP1JSwIBAg==
       -----END DH PARAMETERS-----
       PKCS#3 DH Parameters: (256 bit)
           prime:
               00:f5:c4:15:32:f8:5d:43:1e:68:13:ea:de:c4:4f:
               bb:c7:5c:dd:52:9b:64:db:be:69:57:7d:b4:1e:a0:
               fd:49:4b
           generator: 2 (0x2)

Um einen "DH" Paramter mit höherer Bit Anzahl zu erzeugen zB 512, 1024, 2048 sowie 4096 kann folgendes ausgeführt werden:

       # /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:512 -out dh512.pem
       # /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:1024 -out dh1024.pem
       # /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:2048 -out dh2048.pem
       # /bin/openssl genpkey -genparam -algorithm DH -pkeyopt dh_paramgen_prime_len:4096 -out dh4096.pem

Der Vorgang diese "DH" Parameter selber zu erzeugen ist einfach jedoch diese in den verschiedenen Services wie zB Apache, Postfix usw. einzubinden ist eine Andere. Speziell bei Herstellern basierend auf dem eigenen OS fehlt die Schnittstelle of diese erzeugten "DH" Paramter einzubinden. Die nachfolgende Seite zeigt auf wie bei verschiedenen Service wie Apache, Postfix, Cyrus-IMAP vorzugehen ist um den selbst erzeugten "DH" Paramter einzubinden:

       https://weakdh.org/sysadmin.html

Zertifikate - Asymmetrische Signatur

Die zweite Anwendung von asymmetrischer Verschlüsselung ist das Erstellen von Signaturen, um die Authentizität von Daten zu gewährleisten. Dabei macht man sich zu Nutze, dass die Verschlüsselung von Daten mithilfe des "privaten" Schlüssels (Private Key) durch den "öffentlichen" Schlüssel (Public Key) rückgängig gemacht werden kann. Dadurch ist jeder (mit dem öffentlichen Schlüssel des Absenders) in der Lage, die Signatur zu entschlüsseln. Allerdings konnte nur der Absender die Signatur erzeugen, da nur er sich im Besitz des "privaten" Schlüssels (Private Key) befindet. Für eine Signatur muss aber nicht die gesamte Nachricht wiederholt werden. Stattdessen wird ein so genannter "Hash-Wert" aus der Klartext-Nachricht erzeugt, der dann mit dem "privaten" Schlüssel (Private Key) des Absenders verschlüsselt wird. Die Überprüfung der Signatur verläuft sehr ähnlich zur Erzeugung:

       Der Empfänger erstellt ebenfalls den Hash-Wert der Klartext-Nachricht und vergleicht 
       diesen mit dem entschlüsselten Hash-Wert des Absenders. Sind diese identisch, handelt 
       es sich um eine gültige Signatur und die Nachricht kann als authentische eingestuft werden.
       
       
       
       NOTE Ein Hash-Wert wird durch eine Funktion erstellt, die aus einem Text beliebiger Länge eine 
            eindeutige Zeichenkette  fester Länge erzeugt. Die Funktion ist nicht umkehrbar, so dass 
            es unmöglich (oder wenigstens sehr schwer) ist, den Klartext zu einem Hash-Wert zu ermitteln.

Durch die Verwendung von "Public Key Cryptography" kann die Authentizität und Integrität mithilfe von Signaturen sichergestellt werden. Die Vertraulichkeit beruht auf der Verschlüsselung der Nachricht. Damit Public Key Cryptography funktioniert, muss man offensichtlich seinen öffentlichen Schlüssel (Public Key) mit potentiellen Kommunikationspartnern teilen. Da ein öffentlicher Schlüssel (Public Key) aber nur durch eine unpersönliche Zeichenkette repräsentiert wird, wäre es notwendig, ein "Adressbuch" zu pflegen. Darin müsste zu jedem öffentlichen Schlüssel (Public Key) die Identität des Absenders vermerkt sein. Dieses Adressbuch würde aber ein Angriffsziel darstellen. Sollte ein Angreifer den öffentlichen Schlüssel (Public Key) eines bekannten Empfängers austauschen, wäre die Kommunikation kompromittiert. Daher wurde das Zertifikat erfunden. Es verschmilzt einen öffentlichen Schlüssel (Public Key) mit Identitätsinformationen mithilfe einer Signatur. Beispiele zu diesen Ausführungen wären:

       Pretty Good Privacy (PGP) 
       GNU Privacy Guard (GPG)

Diese basieren auf einem so genannten [Web of Trust], einem Netz aus Vertrauensstellungen. Jeder Teilnehmer kann die Zuordnung eines öffentlichen Schlüssels (Public Key) und den Identitätsinformationen mithilfe einer Signatur bestätigen. Dadurch benötigt jeder Teilnehmer nur wenige enge Freunde. Das Netz spannt sich durch die Signaturen untereinander auf. Erhält ein Teilnehmer eine Nachricht von einem (noch) unbekannten, lässt sich die Authentizität durch eine Kette aus vertrauenswürdigen Unterzeichnern überprüfen. Es handelt sich um einen "Community-basierten" Ansatz und erfordert eine kritische Masse von Teilnehmern, damit Kommunikationspartner verbunden sind.