IPSec – Sicherer Kanal auf Layer 3

Im Unterschied zu TLS/SSL und SSH setzt IPSec schon auf der dritten Ebene des OSI Modells (Network Layer) an, um Daten im Transit abzusichern. IPSec kann dabei jeglichen IP basierten Verkehr unabhängig vom verwendeten Anwendungsprotokoll absichern. Im Gegensatz zum ungesicherten Standard IPv4 Protokoll bietet die IPSec Protokollsuite auch

  • Nichtabstreitbarkeit durch Signierung,
  • Authentifizierung und
  • Verschlüsselung von Verkehr.
  • Zudem kann durch konfigurierbare Regelsätze der Verkehr zwischen zwei Endpunkten nach bestimmten IP-Adressen, verwendeten Protokollen, Verkehrsrichtung etc. gefiltert werden = Basis-Firewallfunktion auf Protokollebene.

Sinnvolle Einsatzszenarien innerhalb des Unternehmens sind z.B. das End-to-End Absichern des Verkehrs zwischen sicherheitskritischen Servern und Arbeitsstationen. Optional kann IPSec auch als sichere Site-to-Site Tunneling Lösung verwendet werden, falls die beteiligten Endpunkte nicht über ein Standard VPN-Protokoll kompatibel sind. Dies ist allerdings selten der Fall und meist wird nur der Transportmodus für IPSec verwendet. Nichtsdestotrotz gibt es mit L2TP/IPSec ein reines VPN Protokoll auf IPSec-Basis, das weithin Verwendung findet (siehe Kapitel VPN mit Zertifikaten). IPSec profitiert von PKI Diensten, indem für die sichere gegenseitige Authentifizierung der Kommunikationsendpunkte auch die Verwendung von X.509 Zertifikaten ermöglicht wird.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Echte und sichere VPN Authentifizierung über X.509 Zertifikate

Immer dann, wenn Mitarbeiter  außerhalb des Unternehmens (z.B. Roadwarrior im Vertrieb, Homeworker, Smartphone-Einsatz) auf das interne Firmennetzwerk zugreifen müssen, ist besondere Vorsicht geboten.

Um die Kommunikation über ein unsicheres öffentliches Netzwerk wie das Internet sicher zu gewährleisten, werden VPN Tunnel  aufgebaut, die den Verkehr vom Endgerät bis zum VPN Gateway der Firma durchgehend verschlüsseln (End-to-Site Tunneling).  Während der Dauer der VPN-Verbindung befindet sich der Client logisch im Firmen-LAN und der Mitarbeiter kann sich dann z.B. mit RDP auf seinen Arbeitsplatz verbinden und die gewohnte Arbeit durchführen. Ebenso ist es als Alternative zu herkömmlichen Standleitungen möglich, mit VPN Technologien Firmenstandorte über unsichere Netze wie das Internet zu verbinden (Site-To-Site Tunneling).

Verbreitete Protokolle für die Erstellung eines VPN-Tunnels sind z.B.

  • PPTP,
  • L2TP/IPSec,
  • SSL basierte VPN-Protokolle wie SSTP
  • oder in Sonderfällen  auch natives IPSec im Tunnelmodus (siehe IPSec).

1. Verbindungsaufbau der einzelnen VPN Protokolle

Alle diese Protokolle benutzen zum Verbindungsaufbau das PPP (Point-to-Point) Protokoll zusammen mit Benutzerauthentifizierungsmethoden, verwenden dabei aber unterschiedliche Herangehensweisen:

  • PPTP bspw. verschlüsselt die Daten erst (!), wenn bereits über PPP eine erfolgreiche Benutzerauthentifizierung stattgefunden hat,
  • hingegen erstellen SSTP und L2TP/IPSec schon vorab eine gesicherte Verbindung. Hierzu verwendet SSTP ein X.509 Serverzertifikat am Gateway, das sich gegenüber dem VPN-Client authentifiziert – damit kann der Anwender auch sicher sein, dass er seine Zugangsdaten dem richtigen Server anvertraut.
  • L2TP/IPSec setzt zusätzlich noch Client Zertifikate voraus, damit sich auch die VPN-Clients gegenüber dem Server authentifizieren müssen.

Nur mit Zertifikaten kann eine echte, eindeutige Authentifizierung zwischen den Device-Identitäten auf Gateway und Clientseite stattfinden

VPN_Certificate_Based_Device_Authentication

2. Benutzerauthentifizierung im VPN
Ohne eine PKI ist man bei der VPN-Benutzerauthentifizierung auf  passwortbasierte Methoden (PAP, CHAP, MSCHAPv2) beschränkt und die Sicherheit des Systems korreliert direkt mit der Komplexität der verwendeten Benutzerpasswörter.

Durch die Verwendung des EAP-Frameworks ist es aber möglich verschiedene erweiterte Authentifizierungsmethoden in die PPP Authentifizierung mit einzubinden, damit kann die Benutzerauthentifizierung z.B. auch über Benutzerzertifikate oder Smartcards erfolgen (z.B. EAP-TLS, PEAP-TLS), womit das Problem der schwachen Passwörter behoben wird.

X.509 Benutzerauthentifizierung VPN
Erweiterte Flexibilität bei der Kontrolle des VPN-Zugriffs kann zudem durch den Einsatz von RADIUS erzielt werden

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Erweiterte Authentifizierung mittels 802.1x und Radius

Für Netzwerke mit mehreren Zutrittspunkten bietet sich eine zentral gesteuerte Authentifizierung und Protokollierung der Verbindungen an, um den administrativen Aufwand klein zu halten.

802.1x
Mit 802.1x gib es ein solches Zugriffsframework, das den Zugriff auf ein Netzwerk zulässt oder ablehnt. Es besteht in der Regel aus 3 Komponenten:

  • Supplicants: Clients, die den Zugriff auf ein Netzwerk anfordern, indem sie Authentifizierungsanfragen mit dem EAP-Protokoll an einen Authenticator senden.
        • EAP (Extensible Authentication Protocol):Authentifizierungsframework, das die Einbindung verschiedener Authentifizierungsmethoden erlaubt z.B. 2-Faktor über Zertifikate/Smartcards  etc.
  • Authenticator: Zugriffsgateway (VPN Gateway, W-LAN Access Point, Ethernet Switch), das jeglichen Verkehr – außer dem Authentifizierungsverkehr – solange blockt, bis eine erfolgreiche Authentifizierung stattgefunden hat. Der Authenticator leitet alle Authentifizierungsanfragen der Supplicants an den Authentication Server weiter.
  • Authentication Server: zentraler Server, der die  weitergeleiteten Authentifizierungsanfragen mehrerer Authenticator validiert und ihnen das  Ergebnis der Überprüfung rückmeldet. Erst bei positiver Rückmeldung erlaubt der Authenticator dem Supplicant den gewünschten Netzwerkzugang.

RADIUS als Authentication Server für 802.1X
Eine weit verbreitete Implementierung für den Authentication Server ist der RADIUS (Remote Authentication Dial In User Service) Standard, der auch von Internet Providern für den Zugriff auf ihre Backbones verwendet wird. Dieser Standard kann neben der reinen Authentifizierung zusätzlich Autorisierung und Accounting (zentrale Protokollierung der Verbindungen) durchführen.

  1. Dabei prüft der RADIUS Server zuerst die grundsätzliche Authentifizierungsanforderung der Supplicants (korrekte Credentials bzw. Zertifikate) gegenüber einem Verzeichnisdienst wie Active Directory und
  2. wendet bei Erfolg bestimmte Autorisierungsrichtlinien auf die Verbindung an. Diese enorm flexiblen Richtlinien untersuchen, ob bestimmte weitere Bedingungen für die Verbindung erfüllt sind  (z.B. korrekte Benutzer/Computergruppe, Uhrzeit, Zugriffsart, IP-Adresse etc.) und weisen die Verbindung ggf. trotz gültiger Authentifizierungsangaben ab.

Erweiterte Policies und Quarantäne
Eine RADIUS-Implementierung kann ferner mit einem Network Policy Server (NPS) kombiniert werden, der noch erheblich detailliertere Zutrittskontrollen erlaubt. Haben die Supplicants bestimmte Prüf-Agenten installiert, kann der NPS bspw. ermitteln, ob ein Zugriffsclient die aktuellen Virenschutzdefinitionen/ aktuellen Updates installiert hat bzw. die Host-Firewall aktiviert ist. Ist dies nicht der Fall, wird der Client vom NPS temporär in eine vom internen LAN abgeschottete Quarantänezone – meist  ein spezielles V-LAN – verwiesen.

Die Quarantänezone erlaubt dem Client ggf. die fehlenden Komponenten z.B. mit Hilfe eines Update Servers nachzuinstallieren, ehe er über einen weiteren Authentifizierungsvorgang noch einmal versuchen kann, dem internen Netzwerk beizutreten.

Zertifikate in Kombination mit Radius und 802.1x

Alle RADIUS Authentifizierungsversuche müssen stets über das EAP-Protokoll erfolgen, zudem muss auf dem RADIUS Server ein X.509 Serverzertifikat mit Serverauthentifizierungs-EKU installiert sein, um seine Identität gegenüber den Supplicants zu beweisen.

Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

TLS/SSL Verschlüsselung und X.509 Zertifikate

TLS (Transport Layer Security) bzw. vormals SSL (Secure Socket Layer)  Verschlüsselung ist das am weitesten verbreitete Anwendungsszenario einer PKI. TLS ermöglicht die Erstellung eines sicheren Kanals zwischen zwei Endpunkten, indem es bestimmten Anwendungsverkehr (HTTPS, SMTPS, FTP over SSL etc.) auf der Sitzungsschicht des OSI Modells durch Verschlüsselung schützt.

  • In TLS werden asymmetrische Algorithmen für die Authentifizierung und den Schlüsselaustausch verwendet, symmetrische Algorithmen dagegen für die Bulk Encryption der Daten.
  • Neben Vertraulichkeit durch Verschlüsselung bietet TLS auch eine Authentifizierung und eine Integritätsprüfung über Hashalgorithmen an.

Webserver und SSL/TLS – Server beweist seine Identität gegenüber den Clients

Häufige Verwendung findet TLS auf Webservern, die Clients über ein Webserverzertifikat ihren öffentlichen Schlüssel anbieten. Vertraut der Client dem Zertifikat (zusätzlich kann er noch eine Sperrlistenprüfung durchführen – siehe auch Certificate Chaining and Validation), so kann er mit dem öffentlichen Schlüssel des Webservers verschlüsselten Web-Verkehr sicher über ein eigentlich unsicheres Netz übertragen.

ssl tunnel client to webserver

SSL/TLS und Clientauthentifizierung – der Client beweist seine Identität gegenüber dem Webserver

Standardmäßig authentifiziert sich nur der Server gegenüber dem Client indem er sein Zertifikat präsentiert, der Webserver kann aber zusätzlich so konfiguriert werden, dass auch er eine Authentifizierung des Clients über ein Clientzertifikat verlangt.

Dabei gibt es im IIS zwei Möglichkeiten, die beide den potenziellen Anwenderkreis einschränken:

– Zertifikat ohne Certificate Mapping: Der Client benötigt ein Zertifikat mit Clientauthentifizierungs-EKU um sich zu Authentifizieren. Es wird lediglich die Gültigkeit des Zertifikats, sowie die Vertrauenswürdigkeit des Ausstellers geprüft. Ein etwaiges Login Formular muss aber vom Anwender weiterhin manuell mit Benutzername/Passwort ausgefüllt werden.

–  Zertifikat mit Certificate Mapping: Im Verzeichnisdienst oder direkt am Webserver wird eine Zuweisung eines (1:1 Mapping) oder mehrerer Zertifikate (N:1 Mapping) mit einem Benutzerkonto erstellt. Präsentiert der Zugriffsclient dann ein zum Mapping passendes Zertifikat, so wird er automatisch als das entsprechende Benutzerkonto authentifiziert und braucht keine Benutzername/Passwort Kombination mehr einzugeben. Somit sind Erraten des Passwortes, sowie einfache Social Engineering bzw. Brute Force Angriffe auf das selbige kaum mehr möglich.
Exchagne Active Sync mit Client Zertifikaten

  • In einem mittelständischen Unternehmen eignet sich TLS in Kombination mit dem HTTPS Protokoll vor allem, um Kunden einen sicheren Zugriff auf Portal- bzw. Extranetlösungen über das Web zu gewähren.
  • Auch für das sichere Abrufen von Unternehmens-Emails über Smartphones wird TLS in Kombination mit Active Sync over Exchange eingesetzt.
  • Ebenso arbeiten Terminalserver – alternativ zum RDP Protokoll – mit TLS.

Der Nachteil von TLS liegt darin, dass die  IP Quell- und Zieladresse der Kommunikationspartner nicht verborgen werden und es daher anfällig für Datenverkehrsanalysen ist – weiterhin ist keine Garantie der Nichtabstreitbarkeit möglich.


Vgl. Morimoto, Rand et al.: „Windows Server 2003 unleashed“, S. 344-345.

 

Veröffentlicht unter PKI: Anwendungen und Applikationen, PKI: Kryptografische Grundlagen | Hinterlasse einen Kommentar

Smartcardanwendungen

Viele PKI-Anwendungen erlauben den Einsatz von Smartcards. Smartcards sind kreditkartenähnliche Chipkarten, die für kryptografische Operationen (Cryptographic Service Provider) wie z.B. die Erzeugung asymmetrischer Schlüssel ausgerichtet sind. Zusätzlich besitzen sie einen Speicher, in dem die privaten Schlüssel, sowie die Zertifikate einer Entität sicher abgelegt werden können. In der Regel werden Smartcards nach einer Identitätsprüfung personalisiert für bestimmte Nutzer ausgestellt und mit einer PIN versehen, die nur der Benutzer selbst kennt. Die Verwendung von Smartcards hat folgende Vorteile:

  • Sicherheit: Ein Angreifer müsste in Besitz der Karte kommen und die PIN ausspähen, um die Smartcard einsetzen zu können. Social Engineering Angriffe sind schwieriger, da eine personalisierte Smarcard kaum aus der Hand des Besitzers gegeben wird. Auch Brute Force Angriffe auf Passwörter gestalten sich – durch die deutlich höhere Schlüssellänge im Vergleich zu  Standardpasswörtern – als schwierig.
  • Portabilität: Zertifikate und Schlüssel werden portabel. Der Nutzer kann seine Karte an einen beliebigen Rechner mit Smartcardleser einstecken und auf eigene Schlüssel und Zertifikate zugreifen bzw. damit neue Schlüssel generieren, um Zertifikate anzufordern und zwar unabhängig davon ob er Zugriff auf die Daten seines Benutzerprofils hat.
  • Flexibilität: Smartcards können im Gegensatz zu One-Time Password Token mehrere Schlüssel und Zertifikate für verschiedene Zwecke speichern und sind daher deutlich flexibler einsetzbar.

Statt Smartcards gibt es auch sogenannte USB Tokens mit ähnlichen Eigenschaften. Sie haben den Vorteil, dass kein Kartenleser für deren Einsatz nötig ist, dafür sind sie etwas weniger robust und benötigen einen freigeschalteten USB Port, der sie für Hochsicherheitsumgebungen weniger attraktiv macht.

Ein häufiger Einsatzzweck  einer Smartcard ist z.B. die sogenannte  2-Faktor Authentifizierung (Besitz: Karte + Geheimnis: PIN) beim Windows Logon.

Smart Card und USB Token von SafeNET/Aladdin

Folgende weitere Einsatzszenarien für Smartcards sind:

  • Benutzerauthentifizierung bei VPN-Zugriff (EAP-TLS, PEAP-TLS)
  • Benutzerauthentifizierung bei WPA/WPA2 Enterprise W-LAN (EAP-TLS/PEAP-TLS)
  • TLS Benutzerauthentifizierung über Smartcards für Websites
  • EFS Dateiverschlüsselung (möglich ab Windows Vista / Server 2008)
  • Signieren und Verschlüsseln von E-Mails mit S/MIME
  • Code Signing mittels Smartcards
Veröffentlicht unter PKI: Anwendungen und Applikationen | Hinterlasse einen Kommentar

Gültigkeitsdauer und Erneuerung von Zertifikaten in Microsoft CAs

Gültigkeitsdauer von Zertifikaten
Von einer Microsoft CA können keine Zertifikate ausgestellt werden, deren Gültigkeitszeitraum länger ist als die Restgültigkeit des  CA Zertifikats selbst bzw. dessen übergeordneter CA Zertifikate.

Anm.: Dies bedeutet im Gegenzug – wenn das CA Zertifikat ungültig wird, so werden auch alle bereits ausgestellten Zertifikate ungültig – man bezeichnet diesen Vorgang auch als „Time Nesting“.

Im Konfliktfall wird die Gültigkeit eines auszustellenden Zertifikats einfach entsprechend verkürzt.

Bsp.: Ist das Root CA Zertifikat maximal bis Januar 2014 gültig, so kann das untergeordnete CA Zertifikat auch nur bis Januar 2014 gültig sein, auch wenn in der Zertifikatvorlage ein längerer Gültigkeitszeitraum vorkonfiguriert war.

Von der untergeordneten CA ausgestellte Zertifikate orientieren sich wiederum an der Gültigkeit der untergeordneten CA.

Weitere Einschränkungen für die Gültigkeitsdauer eines ausgestellten Zertifikats sind der Registry Key ValidityPeriodUnits der CA, sowie die maximale Gültigkeitsdauer, die in der entsprechenden Zertifikatvorlage konfiguriert wurde.

Ablauf und Erneuerung von Zertifikaten
Wenn ein Zertifikat abgelaufen ist, so kann es im Regelfall von der entsprechenden Anwendung nicht mehr verwendet werden (eine CA stellt bspw. keine Zertifikate mehr aus).

In diesem Fall muss nochmals ein vollständig neuer Zertifikatregistrierungsvorgang mit Identitätsprüfung durchgeführt werden, ein Umstand der zu längeren Unterbrechungen führen kann.   Um dies zu verhindern, kann von der Endentität während der gesamten Zertifikats-Lebensdauer ein Renewal-Request an die CA gestellt werden, um eine Erneuerung des Zertifikats ohne größere Serviceunterbrechung durchzuführen.

Die Erneuerung kann dabei mit einem neuen Schlüsselpaar – mit optional erweiterter Länge – erfolgen, oder das vorhandene wird beibehalten.

  • Bei Verwendung eines neuen Schlüsselpaars  müssen auch die sich im Umlauf befindlichen, zugehörigen öffentlichen Zertifikate neu verteilt werden. Da ansonsten die entsprechenden kryptografischen Signaturen der Certificate Chain im Certificate Chaining Prozess nicht mehr korrekt überprüft werden können
  • Beim Verwenden des alten Schlüsselpaars entfällt dies, die Sicherheit gegenüber Brute Force Angriffen wird aber nicht erneuert.  

CA Zertifikate müssen immer manuell vom CA Administrator erneuert werden. Bei Endentitäten kann der Vorgang auch automatisch erfolgen, falls eine automatische Zertifikatsregistrierung (Autoenrollment) konfiguriert wurde.


Vgl. Microsoft Corporation: „Implementieren und Verwalten der Sicherheit in einem Microsoft Windows 2003 Netzwerk“, S.3-5.

Veröffentlicht unter PKI: Komponenten und Prozesse | 1 Kommentar

Zertifikatverkettung und Validierung im Detail

(Erweiterung des Blogeintrags Certificate Chaining Prozess s.u.)

Der Aufbau der Zertifikatkette und die Auswahl der korrekten Zertifikate der Kette bzw. das Ermitteln der richtigen Reihenfolge der einzelnen Zertifikat geschieht
– abhängig von den befüllten Attributen eines X.509 Endentität-Zertifikats –
(siehe Aufbau von Zertifikaten) durch eine der folgenden Methoden:

  • Exact Match: Wenn die Authority Key Identifier (AKI) Extension im Zertifikat mit dem  Namen der übergeordneten Zertifizierungsstelle und deren Zertifikatseriennummer gefüllt ist, wird nach einem Zertifikat am Client gesucht, das diese Seriennummer und als Antragssteller diesen CA Namen sowie den passenden Keymatch (s.u.) enthält.

ExactMatchDa es pro PKI immer nur eindeutige Seriennummern für Zertifikate gibt, wird mit dieser Methode immer ein eindeutiges Zertifikat gefunden.

Sobald das entsprechende Zertifikat aber einmal erneuert wurde, bringt das Exact Match-Verfahren kein Ergebnis, da bei jeder Zertifikaterneuerung auch eine neue Seriennummer vergeben wird.

  • Key Match: Hält die AKI Extension nur den Hashwert des öffentlichen Schlüssels der übergeordneten CA, so wird ein Zertifikat gesucht, welches bei gleichem Hashalgorithmus einen übereinstimmenden Wert in der SKI Extension hat. Achtung: Dieses Verfahren ist nicht mehr eindeutig, sobald das Zertifikat der  CA mit demselben Schlüsselpaar erneuert wird!

  • Name Match: Hat die AKI Extension keinen gültigen Wert, wird lediglich ein Zertifikat gesucht, das im Feld Subject Name den Wert des Issuer Name Feldes hat. Achtung: Dieses Verfahren verliert die Eindeutigkeit, wenn die übergeordnete CA ihr Zertifikat mit gleichem oder einem neuen Schlüsselpaar erneuert! Bei nicht gelöschten alten Zertifikaten, kann dies zur Ablehnung eines Zertifikats aufgrund falscher Zuordnung führen!

NameMatch

Fehler bei der Zertifikatvalidierung

Not Trusted Certificate im Internet Explorer
Grund fehlender Trust Anchor: dem Zertifikat bzw. dessen Rootzertifikat wird schlicht nicht vertraut oder aber der Aufruf der Website stimmt nicht exakt mit dem Common Name (CN) oder einem der SANs (Subject Alternative Names) die im Zertifikat hinterlegt wurden überein.

IECertificateError

Beispiel: Im Zertifikat gibt es keinen Subject Alternative Name für den www. Alias Aufruf der Website.

fehlender SAN für www Aufruf

Wird nun im Browser bspw. https://www.sslsites.de statt https://sslsites.de angegeben kommt es zu einer Fehlermeldung.

Fehler in der Zertifikatskette

Kette kann nicht aufgebaut werden: Übergeordnetes CA Zertifikat kann nicht gefunden werden z.B. fehlende Internetverbindung, fehlende oder fehlerhafte Befüllung der Certificate Extensions oder importieren der Certificate Chain (.p7b) nötig

Stammzertifizierungsstelle ist nicht vertrauenswürdig: Die zum Zertifikat gehörige RootCA muss erst in die Liste der Trusted Root Authorities am Client aufgenommen werden siehe  Windows Certificate Store und Trustmanagement

ChainConstructionErrorAndTrustErrorDie Signatur ist beschädigt

Grund z.B. ein fehlerhaftes Bit / zerstörte Integrität des Zertifikats – oder aber ein Angreifer hat versucht gespoofte Zertifikate in der Kette unterzubringen.BeschädigteSignatur


Vgl. Komar, Brian: „Windows Server 2008 PKI and Certificate Security“,  Windows Server 2008 Certificate Security , S.240-243.

Veröffentlicht unter PKI: Komponenten und Prozesse, PKI: Kryptografische Grundlagen | Hinterlasse einen Kommentar

Validation Authority / Online Responder

Wenn eine Sperrprüfung für ein Zertifikat durchgeführt wird und sich keine CRL (Certificate Revocation List) im Cache des Clients befindet, so muss immer die gesamte Basis CRL Liste sowie eine Delta Sperrliste heruntergeladen werden. (siehe Sperrlisten und Certificate Chaining Prozess)
Je länger eine CA in Betrieb ist, desto länger werden die Listen und desto häufiger könnte es bei der Sperrprüfung zu Verzögerungen kommen.

Außerdem besteht bei herkömmlichen CRLs das Aktualitätsproblem: Werden Zertifikate zwischen Sperrlistenveröffentlichungsintervallen gesperrt, so kann die Ungültigkeit erst bei der nächsten Prüfung der aktualisierten Sperrliste durchgeführt werden und nicht in Echtzeit.

Bei der Verwendung von Online Respondern, die mit dem OCSP (Online Certificate Status Protocol) Protokoll arbeiten, werden dagegen in Echtzeit nur gezielte Abfragen über den Status bestimmter Zertifikate gemacht.

Nachteil: OCSP wurde von Microsoft erst mit Server 2008 eingeführt – sowohl Windows XP als auch Server 2003, sowie ältere Clients z.B. Linux/Unix basierte Thin/Zero Clients unsterstüzen die OCSP Validierung nicht nativ.
Für maximale Kompatibilität sollte man in Windows Umgebung daher klassiche CRL und Delta CRL Sperrlisten einsetzen – für maximale Sicherheit dagegen klassische CRL und OCSP.

Der Pfad zum Online Responder wird in die AIA Extension der Zertifikate eingetragen. siehe auch Aufbau digitaler Zertifikate

OCSPEintragEinesZertifikats

Erweiterte Kompatibilitätsübersicht von OCSP mit Browsern und Betriebssystemen (Stand Februar 2011)
Adrian Dimcev’s Blog

Speedvergleich OCSP komerzieller CAs – sowie IPv6 Compatibility
OCSP and CRL Performance Report

Vgl. auch  Fischer, Daniel et al.: „Zertifikatskontrolle mit OCSP-Proxies“ in IX 10/2008, S.120-121.

Veröffentlicht unter PKI: Komponenten und Prozesse | Hinterlasse einen Kommentar

Certificate Chaining – Prozess mit dem Anwendungen Zertifikate validieren

Eine Anwendung muss zunächst die Gültigkeit eines Zertifikats (meist mit Hilfe der Crypto-API des Betriebssystems) genau prüfen, bevor sie es sicher verwenden kann.

Der Prozess der Zertifikatsverkettungsprüfung wird  dabei in zwei Teilen- durchgeführt

  • Aufbau der Certificate Chain und
  • Validierung der Certificate Chain

Aufbau der Certificate Chain:

a) Sammeln der Zertifikate für die Kette

Für eine erfolgreiche Zertifikatvalidierung muss sich jedes CA-Zertifikat der zugehörigen Zertifikatkette (von der ausstellenden CA bis zur Root CA) im Zertifikats-Store oder Cache des Clients befinden.

Um die Zertifikate im Cache aufzufinden und in die richtige Ordnung zu bringen, nutzt der Client den Umstand, dass jedes ausgestellte X.509 Zertifikat immer einen Verweis auf die übergeordnete Zertifizierungsstelle hat.

Der Client beginnt dann beim zu validierenden Endanwender-Zertifikat und verwendet – je nachdem welche Extensions im Zertifikat befüllt sind – nacheinander verschiedene Abgleichverfahren, die in ihrer Exaktheit differieren, um jeweils das nächste übergeordnete Zertifikat zu ermitteln

  1. Exact Match: Erstellt immer eine eindeutige Zuordnung über den Namen und die Seriennummer des Zertifikats der übergeordneten CA.
  2. Key Match: Falls Exakt Match fehlschlägt, versucht dieses Verfahren eine Zuordnung über den Public Key Fingerprint der übergeordneten CA.
  3. Name Match: Falls Key Match fehlschlägt, versucht dieses Verfahren eine einfache Zuordnung über den Namen der übergeordneten CA.

AufbauDerCertificateChain

Falls alle Abgleichmethoden fehlschlagen, um das entsprechende Zertifikat am Client zu finden, wird versucht, über die URL (FTP, http, LDAP etc.), die in der Authority Information Access (AIA) Extension hinterlegt ist, online die fehlenden Zertifikate in den Cache herunterzuladen. Wenn auch auf diesem Weg keine entsprechenden Zertifikate gefunden werden, schlägt die Validierung fehl und das Zertifikat wird als unsicher eingestuft.

Siehe auch Zertifikatverkettung und Validierung im Detail

b) Finden der vertrauenswürdigen CA

Andernfalls geht der Certificate Chaining Prozess nun über die erstellte Zertifikatkette immer solange eine CA Ebene nach oben, bis ein Root- oder Intermediate CA Zertifikat in der Kette gefunden wird, das sich in der Liste der vertrauenswürdigen Zertifizierungsstellen der Anwendung befindet.

Wurde ein solcher Trust Anchor gefunden – so wird der Chain Validation Process gestartet. Ist dies dagegen nicht der Fall, so wird das Zertifikat als nicht vertrauenswürdig eingestuft.

FindenTrustAnchorChainValidationAchtung für viele Chaining Implementierungen kann der Trust Anchor nur eine Root CA sein, daher ein Trust Anchor wie in der Grafik auf der Intermediate CA wäre dann nicht möglich – dem Endzertifikat würde nicht vertraut!

Chain Validation:

Nun wird vom gefundenen Trust Anchor aus die Zertifikatskette in  entgegengesetzter Richtung durchlaufen, wobei für jedes Zertifikat folgende Punkte geprüft werden:

  • Gültigkeitszeitraum: Das aktuelle Datum muss zwischen dem Beginn und dem Ende der Gültigkeitsperiode liegen –  ist die Uhrzeit der Rechner im Netzwerk nicht synchron, kann es hier zu großen Problemen kommen
  • Erkennung: Das Zertifikat muss dem X.509 Standard entsprechen.
  • Inhalt: Erforderliche Attribute, kritische Extensions und evtl. Anwendungsrichtlinien müssen korrekt befüllt sein.
  • Integrität: Ein von einer CA signiertes Zertifikat kann jederzeit auf korrekte Integrität geprüft werden.  Dabei wird ein Hashwert über die Payload des Zertifikats gebildet und dann die Digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der CA entschlüsselt. Anschließend wird der entschlüsselte Hashwert mit dem vorher berechneten verglichen – stimmen beide Werte überein, so ist die Integrität gewährleistet.
  • Sperrprüfung – Certificate Revocation Checking: Falls die Anwendung für eine Sperrprüfung konfiguriert wurde, prüft das System mittels der Seriennummer des Zertifikats die Zertifikatsperrliste CRL, um zu ermitteln, ob das Zertifikat gesperrt wurde. Hat der prüfende Client keine aktuelle CRL im Cache, kann er sie über die CRL Distribution Point Extension (CDP), die im Zertifikat referenziert ist, nachladen. Schlägt dies fehl oder ist das Zertifikat auf der Sperrliste, so lehnt die Anwendung das Zertifikat ab

Anm.: Alle seit dem letzten Reboot durchgeführten Verkettungsprozesse werden im Cache hinterlegt und müssen nicht jedes Mal neu durchgeführt werden.

Vgl. De Clercq, Jan et al.: „A Guide to Windows Certification & Public Keys“, S.27-30.
Guide to Windows Certification & Public Keys
Vgl. Microsoft Corporation: „Implementieren und Verwalten der Sicherheit in einem Microsoft Windows 2003 Netzwerk (MOC 2238)“, S.2-34/2-35.

Veröffentlicht unter PKI: Komponenten und Prozesse, PKI: Kryptografische Grundlagen | Hinterlasse einen Kommentar

Sperren von Zertifikaten

Es gibt verschiedene Gründe, warum ein Zertifikat  von einem  CA Administrator gesperrt wird:

  • Der  mit dem Zertifikat verbundene private Schlüssel der Entität wurde kompromittiert bzw. ist im Besitz einer nicht autorisierten Person (z.B. Verlust der Smartcard oder Laptop).
  • Der entsprechende Mitarbeiter ist nicht mehr für die Abteilung  tätig  oder das Gerät wird nicht mehr verwendet.
  • Das Zertifikat wurde mit ähnlichen Parametern bereits neu ausgestellt.
  • Das Zertifikat ist abgelaufen.

Nach der Sperrung wird das Zertifikat in der Datenbank der Zertifizierungsstelle selbst gesperrt, sowie in der Sperrliste (Certificate Revocation List  –  CRL)  mit Seriennummer und Sperrgrund  veröffentlicht,  um anzuzeigen, dass die CA das Zertifikat nicht mehr für vertrauenswürdig hält.

Neben einer Basis Sperrliste, die alle gesperrten Zertifikate enthält, gibt es auch Delta Sperrlisten, die häufiger veröffentlicht werden und nur die Änderungen seit der letzten Basissperrliste enthalten.

Der Ort der Sperrlisten ist in der CRL Distribution Point Extension im jeweiligen Zertifikat vermerkt – z.B. als LDAP/HTTP Verweis oder auch eine FTP,CIFS, SMB URL.

Beispielsperrlsite von D-Trust unter http://www.d-trust.net/crl/d-trust_qualified_ca_1_2006.crl

D-TrustRevocationList

siehe auch Zertifikate im Detail und Parameter digitaler Zertifikate

Anwendungen können, falls sie dazu konfiguriert wurden, im Certificate Chaining Prozess die Zertifikate auf den Sperrstatus überprüfen


 Vgl. Microsoft Corporation: „Implementieren und Verwalten der Sicherheit in einem Microsoft Windows 2003 Netzwerk“, S.2-37/2-38.

 

Veröffentlicht unter PKI: Komponenten und Prozesse | Hinterlasse einen Kommentar