Teil 4 der Serie Cyber Security / Pen Testing beschäftigt sich mit dem Thema Publik-Key-Infrastructure und Zertifikate. Es soll verdeutlicht werden, welche Rolle PKIs im Bereich Cyber Security spielen und was es mit Zertifikaten auf sich hat. Nach Teil 3 Cyber Security / Pen Testing (Teil 3): Steganographie wo etwas versteckt wird, wenden wir uns wieder der Kryptographie, der Integrität und Vertraulichkeit zu.

Dieser Beitrag ist Teil 4 der Serie Cyber Security – Pen Testing.

Cyber Security / Pen Testing (Teil 1): Einführung

Cyber Security / Pen Testing (Teil 2): Grundlagen der Kryptographie

Cyber Security / Pen Testing (Teil 3): Steganographie

Cyber Security / Pen Testing (Teil 4): Zertifikate und PKI

Cyber Security – Pen Testing (Teil 5): Authentifizierung und Autorisierung

Zertifikate

Ein digitales Zertifikat ist Datensatz, der bestimmte Eigenschaften von Personen oder Objekten bestätigt und dessen Authentizität und Integrität durch kryptographische Verfahren geprüft werden kann. Ja, man könnte sagen ein Zertifikat ist eine Art Ausweis.

Es soll die Identität des Kommunikationspartners überprüft werden, um ganz sicher zu sein, dass es sich um die Person oder den Computer … handelt von dem ich ohne Ausweis nur glauben kann, dass er er ist, aber ich kann es nicht wissen.

Zertifikate finden unter anderem Anwendung bei: Browsen im Internet über SSL (HTTPS), Einrichten eines Webservers über 443, SSH, WPA2-Enterprise, Digitale Signatur, Schützen von E-Mails mit S/MIME, VPN Verbindungen (L2TP/IPSec, SSTP), 802.1x Authentifizierung über RADIUS, Remotedesktopverbindungen, EFS, Bitlocker, Windows Firewall, PowerShell Web Access, Exchange, Sharepoint, MS Teams und vieles mehr …

Das ist eine verdammt lange Liste. Und sie ist bei weitem nicht vollständig. Wenn sich jemand jetzt noch zu behaupten traut, Know-How über Zertifikate sei nicht wichtig, dem ist nicht mehr zu helfen.

Zertifikate können entweder selbst erstellt werden, oder sie werden gekauft. Wer mit Windows arbeitet kann in PowerShell ein Zertifikat erstellen.

New-SelfSignedCertificate -DnsName pagr@sid-500.com -CertStoreLocation Cert:\CurrentUser\My\

Danach ist das Zertifikat im Zertifikats-Snap-In (certmgr.msc) zu finden.

Manchmal erstellt das System für den Benutzer automatisch ein Zertifikat. So ist es beispielsweise beim Windows Feature EFS (Encrypting File System) der Fall. Mehr dazu in meinem Artikel EFS: Dateien verschlüsseln unter Windows.

Eine weitere Möglichkeit Zertifikate zu beziehen ist die Installation einer eigenen Zertifizierungsstelle. Die CA kann unter Windows installiert werden und die Oberfläche unter Windows Server 2016 sieht dann so aus:

Benutzer können dann über die MMC Konsole certmgr.msc Zertifikate von der internen CA anfordern, oder sie bekommen diese in einer Active Directory Umgebung automatisch per Gruppenrichtlinie zugewiesen.

Ist die Web-Registrierung installiert, dann ist das Anfordern von Zertifikaten auch über eine Web-Oberfläche möglich.

Oder man kauft Zertifikate bei einer externen Zertfizierungsstelle. Davon gibts genug, die Größten – welche fast jeder Browser vertraut – findet man in Windows in certmgr.msc unter den Vertrauenswürdigen Stammzertifizierungsstellen.

Auch in Google Chrome sind diese und auch andere zu finden.

Die Zertifikate kann man sich ansehen.

Der Browser vertraut allen, welche er als vertrauenswürdig einstuft. Und das sind alle Zertifikate, welche von einer Zertifizierungsstelle ausgestellt wurden, welche sich in den Vertrauenswürdigen Stammzertifizierungsstellen befinden.

Jeder kennt das grässliche Bild, welches etwas Unbehagen verursacht.

Nehmen wir Google als Beispiel. Google.at wird von meinem Computer als sicher eingestuft.

Das Zertifikat wurde von GeoTrust Global CA ausgestellt. Nun gut, dann schauen wir mal ob wir es in certmgr.msc unter den Vertrauenswürdigen Stammzertifizierungsstellen finden können. Und da isses:

Zertifikate, Public Key und Private Key in Action

Welche Rolle spielt jetzt der Öffentliche Schlüssel (Public Key), der Private Schlüssel (Private Key) und das Zertifikat in Bezug auf Integrität (Integrity) und Vertraulichkeit (Confidentiality)? Bei Bedarf empfehle ich die Wiederholung dieser Begrifflichkeiten mithilfe des ersten und zweiten Artikels der Serie Cyber Security / Pen Testing (Teil 1): Einführung und Cyber Security / Pen Testing (Teil 2): Grundlagen der Kryptographie.

Als Beispiel ziehe ich die HTTPS Verschlüsselung heran. So gut wie jede gute Website ist heutzutage nur mehr über https erreichbar, also kann das Thema kein unwichtiges sein.

Der Austauch des symmetrischen Session-Keys erfolgt verschlüsselt mithilfe des Public Keys des Servers. Dieser kann dann mithilfe des Private Keys (er ist der Einzige auf diesem Planeten der ihn hat!) das Paket entschlüsseln und den Session-Key lesen. Beide haben nun ein Geheimnis und keiner hats mitgekriegt. Alle Daten werden bei der Übertragung mit diesem Session-Key verschlüsselt.

So, jetzt könnte natürlich ein Angreifer versuchen den Session-Key zu erraten. Ja das wäre möglich. Das Problem ist nur, dass der Client und der Server die Aushandlung eines neuen Session-Keys in kurzen Abständen wiederholen. Das heißt es wird nicht nur dieser eine Session-Key für die gesamte Kommunikation verwendet, sondern mehrere. In diesen kurzen Abständen den derzeit aktuellen Session Key zu erraten ist nur mehr schwer vorstellbar.

PKI (Public-Key-Infrastruktur)

Als Public-Key-Infrastruktur (PKI) bezeichnet man in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Diese PKI wird durch einen oder mehrere Computer repräsentiert und diese Computer nennt man Certification Authority (CA). Allerdings bezeichnet sich das Unternehmen dahinter oft auch so.

Eine CA (Certificate Authority) ist eine Organisation, die Zertifizierungen in bestimmten Bereichen durchführt. Die CA ist im Zertifikat hinterlegt:

Unter Details findet man weitere Informationen wie die AIA (Authority Information Access). Der Eintrag der AIA liefert die Information wo das Zertifikat der CA bezogen werden kann und eventuell weitere Infos zur CA.

Gibt man die URL im Browser ein, dann kann man das Zertifikat der CA manuell herunterladen, genauso wie die Sperrliste.

Zertifikate, welche als nicht mehr vertrauenswürdig eingestuft werden, können von der CA gesperrt werden. Diese werden in eine Sperrliste aufgenommen. Dann kommt das grässliche Bild der https Warnung im Browser. Die Sperrliste kann man sich manuell herunterladen. Einfach den Sperrlisten Verteilungspunkt im Zertifikat suchen und die URL im Browser (am besten in IE) eingeben.

Mehr zu Sperrlisten in meinem Beitrag Active Directory Zertifikatsdienste (Teil 5): Sperrlisten und Sperren eines Zertifikats.

Unter Zertifizierungspfad sieht man die Hierarchie. Hier erkennen wir eine PKI in Form von DigiCert als Root CA (Chef!) und einer untergeordneten CA (Issuing CA, kein Chef, aber darf Zertifikate ausstellen, weil Chef DigiCert erlaubt) mit dem Namen DigiCert SHA2 High Assurance Server CA. Was für ein Name!

Wer eine interne Zertifizierungsstelle unter Windows implementieren möchte, dem empfehle ich meine Serie, bestehend aus 8 Teilen: Active Directory Zertifikatsdienste (Teil 1): Installation einer Enterprise Root-CA. (Einige Teil-Links finden sich hier verstreut schon im Artikel)

Weiter gehts mit dem Thema: Cyber Security / Pen Testing (Teil 5): Authentifizierung und Autorisierung