Zum Thema Public Key Infrastructure (PKI) werden ja ganze Bücher mit mehreren hundert Seiten geschrieben, deshalb kann dieser Blog Artikel ja nur ein kleiner «Digest» sein. Also ein kurzer Auszug. Ich will mich hier mal auf die notwendigen Fragestellungen konzentrieren, die wir immer vor einer Implementierung einer eigenen PKI gemeinsam mit den Kunden diskutieren, bevor wir die Installation durchklicken.
Basics
Vorab müsste man etwas Theorie-Abgleich machen, was wir hier mal weglassen. Was ein Zertifikat ist und warum so ein Zertifikat vertrauenswürdig ist, das bitte ich im Artikel www.tec-bite.ch/smart-cards-what-happens-in-the-background/ oder sonst im Netz nachzulesen. Wenn hier besonders viele Anfragen in den Kommentaren kommen, dann werde ich dazu einen separaten Artikel auflegen.
Nur kurz: Ein Paar kryptografischer Schlüssel (Private and Public Key) sind durch die Mathematik verbunden. Der Public Key und beschreibende Informationen (Subject etc.) werden durch die digitale Signatur gebunden und vom Aussteller als richtig ausgewiesen. Dem Aussteller müssen wir vertrauen. Diese Informationen sind nicht änderbar, sonst verfällt die digitale Signatur. Der Private Key muss sicher abgelegt und der Zugriff darauf kontrolliert werden. Zum Beispiel mit einem PIN oder Vergleichbarem. Dieser digitale Ausweis kann einem User dazu dienen, den Kommunikationspartner (Server oder anderen User) zu identifizieren oder sich selbst gegenüber anderen auszuweisen.
Folgende Themen sind vorausgesetzt:
-
- Vertrauenskette / Trust Chain (Digital Signing)
- Gültigkeit / Validity
- Zertifikate zurückziehen / Certificate Revocation / OCSP
Wofür Zertifikate – woher beziehen?
Mit der Frage, für wen die Zertifikate vertrauenswürdig sein sollen – ob für externe Partner, jedermann, der interne Mitarbeiter und interne Systeme – ist schnell geklärt, von wem wir die Zertifikate beziehen. Öffentliches Trust Center, also Public Trusted PKI, oder ob wir eine Private Trusted PKI für die internen Zwecke selbst aufbauen.
Wenn wir nun ein System aufbauen wollen, das wir für die Identifizierung von Servern oder Benutzern einsetzen oder für die Verschlüsselung der Kommunikation, müssen wir uns über den Verwendungszweck klar werden und diesen festlegen. Dennoch ist es wichtig, auch hier immer wieder über den Tellerrand oder über den Horizont zu schauen und das System so auszulegen, dass man in Zukunft auch anderen Anforderungen gerecht werden kann. Aber die Abgrenzung für hier und heute ist für den zu leistenden Aufwand, den man betreibt, sehr wichtig, wie auch den Projektumfang auf das Notwendige zu beschränken und die Kosten im Blick zu behalten. Der Wunsch, eine PKI für die nächsten 15 Jahre richtig zu planen, ist eine fast unmögliche Herausforderung, aber man muss und sollte sich dieser genauso stellen.
Server-Zertifikate
Bei den Zertifikaten, die die Kommunikation mit Servern und Services des Unternehmens absichern sollen, müssen wir für externe Zugriffe Zertifikate von öffentlich vertrauenswürdigen Zertifizierungsstellen verwenden und es muss festgelegt werden, für welche Zielsysteme diese verwendet und wie die Zertifikate verteilt werden. Wie wird der Schutz des privaten Schlüssels sichergestellt und Private Key Operationen legitimiert? Nach einigen Tagen, Wochen oder Monaten kommt das Thema Renewing und ab und zu muss ein Zertifikat vorzeitig zurückgezogen werden …. Also der gesamte Life Cycle muss im Vorfeld betrachtet werden.
Dabei bedarf es für ein Host Certificate eines Clients ein ganz anderes Anforderungsprofil als für ein SSL Intercept Certificate auf einem Proxy Server, was in den Zerifikatsvorlagen definiert wird.
Mögliche Verwendungszwecke sollten betrachtet werden:
-
- Hosts
- SSL / TLS Mutual Authentication
- VPN GW (IPSec)
- SSL Intercept
- Client Host für Compliance Check
- Time Sync
- NAC
- WLAN
- Hosts
-
- Services (spezifische OIDs required)
- Ldap
- Kerberos
- SCAMA (Smart Card Authentication Mechanism Assurance)
- Services (spezifische OIDs required)
Benutzer-Zertifikate
Wenn wir nun an E-Mail-Zertifikat denken, das die User für die Signatur und die Verschlüsselung von Nachrichten verwenden sollen, müssen wir daran denken, dass die Zertifikate für den Empfänger vertrauenswürdig sein müssen. Hier wird man um Zertifikate von einem öffentlichen Trust Center (Public Trusted CAs) nicht drumherum kommen. Das kann man sinnvollerweise auf einem E-Mail Security Gateway abbilden, welches on demand auch die notwendigen Zertifikate ziehen kann. Weiteres findet der geneigte Leser hier www.tec-bite.ch/das-1×1-der-e-mail-verschluesselung/
Benutzer-Zertifikate für die Verschlüsselung sollten nach meiner Erfahrung ein symmetrischer Schlüssel für den Data Encryption Key (DEK) sein. Am besten man generiert für die User alle notwendigen DEKs, das sind ja eh symmetrische Schlüssel, und stellt diese als Keyring zur Verfügung, der mit dem Public Key des Users verschlüsselt wird. Zugriff darauf erhält man mit seinem Private Key. Sonst wird das Thema Key Recovery auf der Certificate Authority (CA) enorm wichtig. Auch hier ist die Betrachtung der Erneuerung der Schlüssel ein wichtiger Punkt, denn auch für diese DEKs sollte ein regelmässiges Erneuern organisiert sein. Solche Lösungen gibt es seit mehr als zwanzig Jahren.
Wenn man Benutzer-Zertifikate für Anmeldungen verwenden will, gehören diese optimalerweise auf eine Smart Card, also vor allem der Private Key. Für die Desktop-Anmeldung ist das sowieso ein Muss, aber auch sonst wäre das der richtige Weg. Sollte auf dem Rechner irgendein Angriff stattfinden, kann man die Karte ziehen und der private Schlüssel ist gesichert. Beim Thema Sicherheit für den Private Key werden wir das noch vertiefen. Lösungen für virtuelle Karten blende ich hier mal aus.
-
- User Certificates
- Smart Card
- Encryption
- Document Signing
- Code Signing
- SCAMA (Smart Card Authentication Mechanism Assurance)
- User Certificates
Public Trusted Certificate Authorities
Wenn wir die Vertrauenswürdigkeit der Zertifikate nicht herstellen können, müssen wir auf ein öffentliches Trust Center oder eine öffentliche Zertifizierungsstelle zurückgreifen. Gerade bei E-Mails wird man kaum allen Kommunikationspartnern sagen können, dass sie doch bitte unserer internen Zertifizierungstelle vertrauen sollen. Das eigene VPN Gateway für die Kommunikation mit den eigenen Firmenrechnern kann durchaus ein Zertifikat der eigenen PKI verwenden. Kommen dann wiederum private Geräte zum Einsatz, wird es schwer, diese Vertrauensbasis über einen längeren Zeitraum sinnvoll zu managen.
Der gesamte Lebenszyklus der Zertifikate, die durch die PKI erschaffen und wie diese verwaltet werden, ist dann im Certificate Practice Statement des Trust Centers festgehalten.
Private Trusted Certificate Authorities
Für unsere eigene Public Key Infrastructure müssen wir ganz ähnliche Überlegungen anstellen, aber vielleicht nicht ganz so akribisch dokumentieren, damit sie den Ansprüchen einer öffentlichen Publizierung gerecht wird.
Dennoch ist es wichtig, möglichst viele dieser Punkte zu betrachten und für sich bewusst eine Abgrenzung zu schaffen, warum wir welche Funktionen oder Eigenschaften nicht unterstützen. Und das sollte auch festgehalten werden.
Ein Beispiel: Eine Root CA wird erschaffen und soll für 12 Jahre bestehen. Länger ist unter Rücksicht auf die Entwicklung der CPU und GPU Kapazitäten und kryptografischen Sicherheit kaum noch zu vertreten. Von einer Lebensdauer von 20 oder 30 Jahren haben wir uns längst verabschiedet. Aber allein in dieser Zeit, und wir können auch die Hälfte der Zeit nehmen, wird es Fluktuation geben, Standards und Anforderungen werden sich ändern. Wenn man nach 5 Jahren kein Papier dazu in der Hand hat, dann ist das gesprochene Wort allein recht nutzlos. Alle Vereinbarungen, die man mit seinen Kollegen gemacht hat, sind vergessen oder die Kollegen gar nicht mehr da.
Für die Abwägung zwischen der Länge des Schlüssels, des Algorithmus und der Life Time, verweise ich weiter unten auf unseren Blog-Artikel: www.tec-bite.ch/key-length-versus-life-time/
Seit ca. 17 Jahren sind die Certificate Services in Windows soweit ausgereift, dass sie für die allermeisten Firmen alle Anforderungen abdecken. Alle, die Microsoft für diesen sensiblen Bereich nicht einsetzen wollen, sollten sich selbst und der eigenen Firma gegenüber gut begründen, warum hier eine Alternative die bessere Wahl ist, da dann zusätzliche Kosten entstehen.
Alternativen
-
- EJBCA ist Open Source, EJBCA EE kostet
- Global Sign PKI
- Entrust Digicert
- Nexus PKI
- Open Trust PKI
- Verizon Unicert CA
Grundstruktur
Die Grundstruktur einer PKI ist «recht» einfach. Certificate Authorities, HSM, AIAs, CDPs, Registration Authority, Enrolment Station, Smart Cards hier in einer generellen Übersicht dargestellt.
PKI Hierarchie
Wir brauchen mindestens eine Root CA. Offline und Stand Alone. Diese Zertifizierungsinstanz brauchen wir eigentlich nur zum Ausstellen des Zertifikats der untergeordneten Zertifizierungsinstanz, eventuelles Zurückziehen und für das Generieren der CRL.
Offline heisst, dass wir damit alle netzwerkbasierten Angriffe kategorisch ausschliessen. Und nur für die notwendigen Operationen wird die Maschine hochgefahren. Der Schutz des Private Keys hat natürlich oberste Priorität und sollte auf einem Hardware Security Module (HSM) abgelegt werden. Das ist zwar die beste, aber auch eine teure und aufwendige Variante. Deshalb werden Alternativen immer intensiv geprüft. Dazu aber später mehr.
Mindestens eine subordinated CA, die als ausstellende Zertifizierungsinstanz (Issuing CA) agiert, online und Enterprise Integrated, also die Vorteile einer Directory Enabled Application nutzt. Der Server muss zwar nicht immer für den Betrieb online sein, aber das ist der Normalfall. Kurze Ausfallzeiten sind normalerweise kein Problem, aber auf die automatischen Prozesse möchte wohl keiner verzichten. Das ist das regelmässige Update des CRL-Files und das Auto-Enrollment für wohl einen grossen Teil der Zertifikate. Der Schutz des Private Keys ist hier noch etwas heikler und man wird wohl um das Thema HSM, TPM, heutzutage wohl die Variante Virtual-TPM, bis hin zur Cloud Variante eines HSMs nicht herumkommen.
Die Laufzeiten der Zertifikate und der CRL-Files müssen gut abgestimmt sein und die Aktualisierung der CA Zertifikate muss eingehalten werden, sonst können die Zertifikate nicht in der notwendigen Qualität und nicht zuverlässig zur Verfügung gestellt werden.
Siehe: Life Time – Key Length – Algorithm: www.tec-bite.ch/key-length-versus-life-time/
Schutz der privaten Schlüssel durch HSM – Hardware Security Module
Für die Sicherheit der Private Keys ist die Ablage auf spezieller Hardware der goldene Weg. Heutzutage ist das meist ein Netzwerkdevice, dass den Zugriff auch vor direkten Angriffen schützt. Die interne PCI-Karte ist mit einer Folie gesichert, die bei Verletzung das Wipen der Keys auslöst. Temperatur-Sensoren schützen vor Angriffen mit flüssigem Stickstoff, und und und… Aber mit dem Einsatz eines HSM steigt auch der Aufwand erheblich. Auch wenn der Private Key im Microsoft OS nicht einfach auf der Platte liegt, wie bei den meisten Unix / Linux Derivaten, und auch mit PIN-Abfragen gearbeitet werden kann, besteht ein enormer Unterschied zwischen Hardware- und Software-Sicherheit. Ohne auf Power Shell Scripts zum Extrahieren des Private Keys hinzuweisen, muss man sich darüber im Klaren sein, dass der Zugriff auf den Private Key oder das Auslösen von Private Key Operationen sicher sein muss.
Wenn der Verdacht besteht, dass der Private Key kompromittiert wurde, muss man diesen Erneuern und alle damit erzeugten Signaturen oder Verschlüsselungen ersetzen. Insbesondere bei einer CA müssten dann alle Client Zertifikate zurückgezogen und neu ausgestellt werden. Somit sind auch alle Dokumente die signiert wurden, neu zu signieren, … Ansonsten sind diese eher Makulatur. An dieser Stelle entstehen dann wirklich Kosten und die gilt es zu vermeiden. Deshalb ist der Schutz des Private Keys so entscheidend.
Hier meine kleine Prioritätenliste:
-
- HSM
- TPM / vTPM
- Disk Encryption, mit Pre Boot und 4 vier Augen-Prinzip für das Pre Boot Password
- Cloud Based HSM
Berechtigungskonzept
Die Trennung für verschiedene Verantwortungen ist sehr sinnvoll, leider oft nicht in der Praxis umsetzbar. Dennoch darf es nicht allen Administratoren einfach erlaubt sein, Zertifikate anzufordern, zu erstellen und verwenden. Einer Verwendung für SSL-Intercept und damit für Man-in-the-Middle-Attacks, ist damit dann Tür und Tor geöffnet. Auch hier gilt es schon den Verdacht auf solche Möglichkeiten prinzipiell auszuschliessen.
Zertifikate verteilen und Zertifikatsverwaltung
Host-Zertifikate
Zertifikate mit 2048 Bit RSA Schlüssel werden ab 2022 nicht mehr empfohlen werden. Das ist heute absehbar. Also ist zum einem der Wechsel auf Elliptic Curve Cryptography zu überdenken und zum anderen die Gültigkeitsdauer der Zertifikate zu reduzieren. Deshalb ist die Optimierung bzw. das Automatisieren für das Ausstellen der Zertifikate wichtiger denn je.
Auf Basis der Auto-Enrollment Mechanismen, kann man die Verteilung und das Erneuern der Host-Zertifikate für Windows basierte Mitglieder der Domain gut automatisieren. Für alle anderen muss man dann SCEP verwenden und kann bestimmte Aufgaben noch mit eigenen Skripten abbilden. Auch hier gibt es Alternativen: revocent.com/linux-certificate-auto-enrollment-with-microsoft-ca/
Server-Zertifikate
Für Server-Zertifikate möchte man das Ausstellen eventuell etwas genauer kontrollieren. Gerade bei rollenbasierter Aufgabenverteilung erstellt der Verantwortliche des Servers oder der Applikation eine Zertifikatsanforderung und übermittelt diese, aber wie bei einem öffentlichen Trust Center kann man hier eine manuelle Prüfung einbauen und via «CA Approval» die Zertifikate erstellen und zur Verfügung stellen. In grösseren Umgebungen ein Muss, um Wildwuchs zu vermeiden.
Da die Empfehlungen für die Life Time von SSL-Zertifikaten immer kürzer werden, muss man hier Automatisierungen oder zumindest eine Vereinfachung der Prozesse betrachten.
Client-Zertifikate
Für Benutzer-Zertifikate die nur im Windows Certificate Store abgelegt werden, sind auch hier Automatismen vorhanden. Der Schutz der Private Keys ist dann hier eher die Herausforderung. Das Nutzen des TPM Chips in Verbindung von Auto-Enrollment ist hier schon eine grosse Herausforderung.
Smart Cards / Smart Card Management
Beim Erstellen von Zertifikaten kann man die Aufgabe des Erstellens der Smart Cards durch die Rolle des Enrollment Agents delegieren. Dieser bekommt ein spezielles Zertifikat und bestätigt durch Signatur des Requests seine Legitimierung. Das kann wiederum an einen User, natürlich mit der Enrollment Smart Card, oder auch an eine Enrollment Station gebunden werden.
Bei Smart Cards wird spätestens ab 100 Karten ein Management notwendig. Das kann schon bei kleineren Stückzahlen notwendig werden, wenn man bestimmte Ausnahme-Situationen handhaben möchte.
Für ein Remote Offline Unlock oder ein PIN Change ist so ein System unerlässlich. Jede Karte erhält seinen eigenen individuellen Admin-Key und damit wird der Lebenszyklus der Karte über die definierten Policies und Templates abgebildet. Karte initialisieren, Zertifikate Ausstellen und und und.
Last but not least: Die üblichen Themen für den Betrieb, Aktualisierung der Software, Audit, Monitoring, Backup und Verfügbarkeit vernachlässige ich hier bewusst, sonst wird es doch noch ein Buch. Aber die Aufgaben CA Certificate Renewing und CRL der Root CA Erneuern und Veröffentlichen müssen genau terminiert werden, damit die vollständige Funktionalität der PKI gewährleistet bleibt.
Wichtigste Fragen: Was ist notwendig, was wird gebraucht, was wäre auch noch gut?
