Verschlüsselungsoptionen und sichere Schlüsselverwaltung

Die verschiedenen Optionen zum Schutz und zum Speichern von privaten Schlüsseln variieren je nach Art des Zertifikats und des Verwendungszwecks (z. B. Best Practices für SSL/TLS-Zertifikate unterscheiden sich von denen für Endbenutzer).

PKI-basierte Lösungen verbreiten sich zunehmend – mehr Websites als je zuvor stellen auf HTTPS um, Unternehmen nutzen digitale Zertifikate als Authentifizierungsfaktor für Benutzer und Rechner, S/MIME stellt seinen Wert unter Beweis, sowohl was die E-Mail-Verschlüsselung anbelangt als auch beim Validieren der E-Mail-Quelle um Phishing entgegenzuwirken – allen diesen Anwendungen liegen Verschlüsselung und Authentifizierung zugrunde. Die sind aber nur so gut wie die hoffentlich ordnungsgemäß durchgesetzte Schlüsselverwaltung.

Jedes Mal, wenn eine CA ein digitales Zertifikat ausstellt oder selbstsigniert, wird ein privates/öffentliches Schlüsselpaar generiert. Best Practice besagt, dass Ihre privaten Schlüssel sicher sind und … privat bleiben müssen! Sollte sich jemand widerrechtlich die Schlüssel aneignen, kann er, je nach Zertifikatstyp, Phishing-Websites mit dem Zertifikat des betreffenden Unternehmens in der Adressleiste erstellen, sich bei Firmennetzwerken authentifizieren, indem derjenige sich als Zertifikatsinhaber ausgibt, so kann er auch Anträge oder Dokumente in Ihrem Namen signieren oder Ihre verschlüsselten E-Mails lesen.

In vielen Fällen sind private Schlüssel die Identitäten der Mitarbeiter (und damit auch eine Erweiterung der Identität des jeweiligen Unternehmens). Die Schlüssel zu schützen ähnelt dem Schutz von Fingerabdrücken, wenn biometrische Berechtigungsnachweise verwendet werden. Und ein Hacker sollte weder an Fingerabdrücke noch an private Schlüssel gelangen.

Dieser Beitrag beschäftigt sich mit Optionen zum Schutz und zum Speichern von privaten Schlüsseln. Diese variieren je nach Art des Zertifikats und des Verwendungszwecks (z. B. Best Practices für SSL/TLS-Zertifikate unterscheiden sich von denen für Endbenutzer).

Betriebssystem und Zertifikat-/Schlüsselspeicher des Browsers

Beispiele: Windows Zertifikatspeicher, Mac OS Schlüsselbund

Einige Betriebssysteme und Browser bieten eigene Zertifikat- oder Schlüsselspeicher an. Dabei handelt es sich um softwarebasierte Datenbanken, die ein öffentliches/privates Schlüsselpaar als Teil eines Zertifikats lokal auf einem Rechner speichern. Diese Art der Schlüsselspeicherung ist beliebt, weil viele Anwendungen automatisch in diesen Datenbanken suchen. Der Anwender muss dann nicht jedes Mal manuell nach der Zertifikatdatei suchen.

Zudem lässt sich diese Art des Speicherns leicht anpassen – Sie können die Exportierbarkeit des privaten Schlüssels aktivieren/deaktivieren, einen starken Schutz des privaten Schlüssels aktivieren (der jedes Mal nach dem Passwort fragt, wenn das Zertifikat verwendet wird), und Sie können Back-ups erstellen, wenn Ihr privater Schlüssel exportierbar ist. Aktiviert man als Windows-User Profil-Roaming, wird das Zertifikat an Ihr Profil gebunden und ist verwendungsbereit, wenn Sie sich mit diesem Profil bei einem anderen Rechner anmelden.

Wenn Sie diese Form der Schlüsselspeicherung verwenden, gilt es einiges zu beachten. Zum einen gibt es Dienstprogramme, die diesen Schutz umgehen (d. h. die Nicht-Exportierbarkeit ist nicht 100%ig garantiert). Auch dann, wenn Sie Ihren privaten Schlüssel als nicht exportierbar markieren. Wenn jemand Zugang zu Ihrem Windows-Account hatte und kein starker Schutz für den privaten Schlüssel aktiviert war (kein Passwort zur Verwendung des Zertifikats erforderlich), kann derjenige das betreffende Zertifikat verwenden. Ist der private Schlüssel als exportierbar markiert, kann jemand, der Ihren Rechner benutzt, ihn exportieren. Selbst wenn der Schutz des privaten Schlüssels aktiviert ist, braucht derjenige dann kein Passwort mehr eingeben.

Chrome und der Internet Explorer nutzen den Windows-Zertifikatspeicher, während Firefox einen eigenen verwendet (von Mozilla zur Verfügung gestellt). Wenn Sie dann den Windows-Speicher importieren, finden Chrome und IE automatisch das Zertifikat, Firefox nicht.

Häufig verwendet für:

• Anwendungen zum digitalen Signieren (z. B. Adobe Acrobat, Microsoft Outlook und Office suchen im Windows [Benutzer] Zertifikatspeicher).
• Microsoft IIS (Windows Server) sucht im Windows [Rechner] Zertifikatspeicher nach SSL-Zertifikaten
• Client-Authentifizierung (Benutzer oder Rechner), sucht, je nachdem, wie sie eingerichtet ist, am häufigsten im Windows Zertifikatspeicher.
• Windows Code Signing (Signieren von Anwendungen oder Treibern).

.pfx- und .jks-Dateien (Schlüsselspeicher)

PKCS#12 (.pfx oder .p12) und .jks (erstellt vom Java Keytool) sind Dateien, die Ihr öffentliches/privates Schlüsselpaar enthalten. Im Gegensatz zu den lokal gespeicherten Schlüsselspeichern von Betriebssystem und Browser können diese Dateien praktisch überall abgelegt werden, wie z. B. auf Remoteservern und sie sind immer passwortgeschützt (d. h., jedes Mal, wenn Sie Ihren privaten Schlüssel verwenden möchten, müssen Sie ein Passwort eingeben). Man kann zudem einfach Kopien verteilen, wenn mehrere Personen das Zertifikat verwenden müssen, da dies letztlich nur Dateien sind.

Wenn Sie Ihre Datei auf einem Remoteserver speichern möchten, sollten Sie besonders sorgfältig darauf achten, den Zugang dazu zu beschränken. Wenn jemand Zugang hat, kann er das Zertifikat verwenden. Sie sollten sorgfältig mit der einfachen Vervielfältigungs- und Verteilungsmöglichkeit umgehen.

Wenn jemand an den Schlüsselspeicher kommt, ist es nicht besonders schwierig, eine Kopie zu erstellen und zu stehlen. Das Passwort für den privaten Schlüssel ist dennoch erforderlich, damit die kopierte Datei effektiv verwendet werden kann. Das ist ein weiterer Grund dafür, starke Passwörter mit 15 und mehr Zeichen zu verwenden, die Klein- und Großbuchstaben, Zahlen und Sonderzeichen enthalten. Bei dieser Speicheroption muss man berücksichtigen, dass die Verantwortung hinsichtlich dessen, wo die Datei aufbewahrt wird und ob sie ordnungsgemäß gespeichert ist, beim Endbenutzer liegt.

Wenn Sie keine kryptografische Hardware oder den Windows Schlüsselspeicher (oben beschrieben) verwenden können, aber trotzdem die Sicherheit erhöhen wollen (statt dass sich nur die Schlüsselspeicher-Datei auf Ihrem Rechner befindet), können Sie diese Dateien auf einem USB-Stick speichern, den Sie an einem sicheren Ort aufbewahren. Natürlich ist Bequemlichkeit das Gegenargument dafür – wenn Sie viel signieren, möchten Sie die Datei evtl. lokal für den leichteren Zugriff halten.

Häufig verwendet für:

• Windows oder Java Code Signing.
• Sowohl FDA ESG als auch IRS IDES nutzen .pfx für die sichere Kommunikation mit Behördendiensten.
• Einige Webserver (z. B. Apache Tomcat oder Jboss).
  Hinweis: Es sieht so aus, als ob Java eine Umstellung von JKS auf PKCS#12 als Standard-Schlüsselspeichertyp plant. Aber es wurde bisher kein Startdatum angekündigt.

Kryptografische Token und Smartcards

Speichert man einen privaten Schlüssel auf einer Hardware bietet das mehr Sicherheit. Allerdings besteht ein großer Unterschied zwischen der Verwendung von kryptografischen Token oder Smartcards und Standard Flash- oder USB-Sticks. Mit kryptografischer Hardware wird der Schlüssel auf der Hardware selbst generiert und ist nicht exportierbar. Das bedeutet, dass der private Schlüssel das Gerät niemals verlässt, was Zugang und Kompromittierung wesentlich erschwert.

Hinweis: Wenn Sie die zusätzliche Sicherheit von Krypto-Hardware für einen privaten Schlüssel nutzen möchten, der bereits generiert wurde (d. h. nicht auf dem Token selbst generiert wurde), können Sie eine .pfx-Datei importieren und dann die ursprüngliche .pfx löschen.

Wenn Sie ein Krypto-Token verwenden, wird jedes Mal ein Passwort verlangt, wenn Sie Ihr Zertifikat verwenden wollen. Wenn jemand den Token entwendet, bräuchte er immer noch das zugehörige Passwort. Wenn Sie Ihren Schlüssel auf einem Token speichern, können Sie das gleiche Zertifikat sicher auf mehreren Rechnern verwenden, ohne Kopien machen und den Export-/Importvorgang durchlaufen zu müssen. Kryptografische Hardware trägt auch zur FIPS Compliance bei, die einigen Branchen- und Behördenvorschriften zugrunde liegt.

Abgesehen von der Verwaltung der Token sollten Sie wissen, dass diese Option möglicherweise nicht mit automatisierten Builds funktioniert, da jedes Mal, wenn das Zertifikat verwendet wird, ein Passwort erforderlich ist. Es gibt keine Möglichkeit, das Zertifikat zu sichern, da der private Schlüssel nicht exportierbar ist. Schließlich gibt es noch einige weniger häufige Szenarien, bei denen diese Speicheroption nicht ideal ist, wie z. B. spezialisierte Geräte, die keine Token oder Smartcards unterstützen, und Situationen, in denen die Mitarbeiter keinen physischen Zugriff auf den Computer haben, sondern ein Remoteterminal verwenden.

Häufig verwendet für:

Im Allgemeinen werden alle oben genannten Anwendungsfälle für BS-/Browser-Schlüsselspeicher (Document Signing, Code Signing, Client-Authentifizierung, Windows IIS) von Krypto-Token oder Smartcards unterstützt. Solange sich ein Treiber auf dem Krypto-Token befindet, der eine Verbindung zum BS-/ Browser-Zertifikatspeicher herstellen kann dient das demselben Zweck. In manchen Fällen ist es aber nicht unbedingt praktisch (z. B. Webserver, automatisierte Build-Prozesse für Code Signing, die jedes Mal ein Passwort verlangen, wenn eine Signatur eingefügt wird).

Compliance ist einer der Hauptgründe warum Krypto-Token eingesetzt werden.

• Erforderlich für Extended Validation (EV) Code Signing, nach CA/Browser Forum Richtlinien.
• Erforderlich für Standard Code Signing, nach CA Security Council Minimum Requirements – Zertifizierungsstellen (CA) sind verpflichtet, Krypto-Hardware als primäre Ausstellungsoption zu empfehlen. Wenn der private Schlüssel nicht auf Krypto-Hardware ausgestellt wird, muss der Kunde zustimmen, dass er auf auswechselbarer Hardware gespeichert wird (die ausgewechselt wird, wenn keine Signierung stattfindet)
• Erforderlich für digitale Signaturen, die in Adobe-Produkten öffentlich vertrauenswürdig sein sollen, nach den Anforderungen der Adobe Approved Trust List (AATL).
• Branchenspezifische Regelungen wie CFR 21 Part 11 der FDA und Anforderungen von State Engineering an digitale Signaturen, besagen oft, dass der private Schlüssel im alleinigen Besitz des Inhabers sein muss. Das Speichern auf Krypto-Hardware erfüllt diese Anforderungen.

Hardware Security Modul (HSM)

HSMs sind eine weitere kryptografische Hardware-basierte Option für die Schlüsselspeicherung. Vor allem, wenn Sie sich nicht auf einzelne Token verlassen wollen oder wenn das zu umständlich ist. Während Token eher auf Endbenutzer mit manuellen oder einmaligen Anwendungen ausgerichtet sind (z. B. Signieren kleinerer Mengen von Dokumenten oder Code, Authentifizierung an VPNs oder anderen Netzwerken), verwenden HSMs APIs und können automatisierte Workflows und Builds unterstützen. Sie tragen dazu bei, der FIPS-Compliance zu genügen und bieten in der Regel ein höheres Rating als Token.

Traditionell sind HSMs physikalische Geräte, die sich vor Ort befinden und die interne Ressourcen zur Verwaltung und Sicherstellung erfordern. Etwa damit Grundanforderungen und SLAs erfüllt werden. In der Vergangenheit scheiterte die Einführung von HSM nicht selten an den Kosten oder dem Fehlen von Ressourcen. In den vergangenen Jahren sind Cloud-basierte HSMs aufgekommen. Sie haben vielfach dieselben Vorteile, sind aber nicht auf interne Ressourcen angewiesen.

Ein Beispiel ist Microsoft Azures Schlüsseltresor, der kryptografische Schlüssel in Microsofts eigenem Cloud-HSM schützt. Gerade kleinere Unternehmen, die keine eigene HSM kaufen und verwalten können, profitieren davon. Die Lösung kann in öffentliche CAs wie etwa GlobalSign integriert werden.

Beim Anwendungsfall Document Signing existieren mittlerweile Digital Signing Services, die Cloud-basierte HSM-Speicher für die privaten Schlüssel nutzen und die individuelle Signieridentitäten unterstützen. In der Vergangenheit konnten die meisten HSM-basierten digitalen Signierszenarien nur eine Identität auf Abteilungs- oder Unternehmensebene nutzen (z. B. Buchhaltung, Marketing, Finanzen) und keine individuelle Identität (z. B. Max Mustermann). Unternehmen, die Berechtigungsnachweise für ihre Mitarbeiter brauchten, mussten sich auf Token verlassen. Das ist hier anderes: digitale Signaturen lassen sich für einzelne Mitarbeiter aktivieren, ohne eine (für Verlust anfällige) Hardware verwalten zu müssen.

Häufig verwendet für:

• Document oder Code Signing für große Volumina
• SSL (abhängig von der Serverkonfiguration).
• CA-Infrastruktur für den Betrieb einer internen CA (Root CA, Sub-CA, RFC 3161 Zeitstempel-Server) – eine kann offline, eine online (Root CA ist generell offline) sein.

Blick nach vorne – Schlüsselspeichermethoden der nächsten Generation

Die oben beschriebenen Optionen zur Schlüsselspeicherung sind traditionelle Methoden, die seit Jahren verwendet werden. Wie so vieles ist auch die Schlüsselspeicherung nicht immun gegen den Einfluss des IoT. Hier werden gerade alternative Modelle entwickelt. Immer mehr Geräte gehen online, authentifizieren sich selbst und müssen sicher kommunizieren. Entwickler und Hersteller wenden sich deshalb PKI-basierten Lösungen zu. Damit gehen wiederrum neue Überlegungen, Anforderungen und Technologien zum Schutz privater Schlüssel einher. Zwei Trends haben wir beobachtet.

Trusted Platform Modul (TPM)

TPMs selbst sind nicht neu, aber sie werden beim Schutz von privaten Schlüsseln zunehmend wichtiger. Ein TPM kann dazu verwendet werden, den Stammschlüssel zu speichern (oder zu umschließen) und schützt zusätzliche, von einer Anwendung erstellte Schlüssel. Die Anwendungsschlüssel können nicht ohne das TPM verwendet werden. Das macht sie zu einer geeigneten Authentifizierungsmethode für Endpunkte wie Laptops, Server und für die IoT-Gerätehersteller. Während viele Laptops aktuell mit TPMs ausgeliefert werden, findet man sie im Unternehmensumfeld eher selten. Verbreitet sind sie im IoT. Dort kommen sie als Hardware Vertrauensanker für eine sichere Geräteidentität zum Einsatz.

Im IoT kommunizieren immens viele Geräte anonym miteinander. Das erleichtert es potenziellen Angreifern die Kommunikation abzufangen oder eine Geräteidentität vorzugeben. Da ein Chip bereits innerhalb des Herstellungsprozesses eingeführt wird, kann man ihn nutzen, um den kryptografischen Schlüssel und damit die Identität des Geräts zu schützen.

Schon während der Fertigung generiert das Gerät ein privates und öffentliches Schlüsselpaar. Der öffentliche Schlüssel wird an die CA geschickt, um ein digitales Zertifikat zu signieren und auszustellen. Der private Schlüssel verlässt nie das Gerät, ist sicher auf dem Chip gespeichert und kann nicht exportiert / kopiert / vernichtet werden. Das Zertifikat ist nun die Identität des Geräts, und der geschützte private Schlüssel bildet den hardwarebasierten Vertrauensanker.

Weitere Informationen finden Sie in der Machbarkeitsstudie: Securely authenticating to and controlling hardware using GlobalSign’s cloud-based Certificate Services and Infineon’s OPTIGA TPM.

Physikalisch unklonbare Funktionen (PUF)

Die Technologie der Physikalisch unklonbaren Funktion (PUF) läutet beim Schutz von Schlüsseln einen Paradigmenwechsel ein. Anstatt Schlüssel zu speichern (die anfällig für physische Angriffe sind), werden Schlüssel stattdessen von eindeutigen physikalischen Eigenschaften des SRAM-Speichers eines Chips abgeleitet und existieren nur beim Einschalten. Das heißt, anstatt den privaten Schlüssel sicher zu speichern, kann der gleiche Schlüssel bei Bedarf immer wieder neu generiert werden (für die Lebensdauer des Gerätes). Mit einer SRAM-basierten PUF wird garantiert, dass sie einzigartig sind, da sie die inhärente Zufälligkeit in Silizium-Bitmustern nutzen.

PUF-Technologie in Verbindung mit einer Trusted Execution Environment (TEE) ist eine Antwort auf die Marktnachfrage nach kostengünstigem, einfach zu integrierendem, ultra-sicherem Schlüsselschutz. PUF in Verbindung mit einer PKI bietet eine umfassende Identitätslösung.

GlobalSigns Partner Intrinsic ID hat ein solches Schlüsselbereitstellungssystem auf Basis von SRAM PUF kreiert, das einzigartige, unmanipulierbare, unklonbare Geräte-Fingerabdruckidentitäten produziert, die in Hardware verankert sind. Mit unseren Zertifikatdiensten können wir diese Fingerabdrücke in digitale Identitäten urladen und PKI-Fähigkeiten hinzufügen. So hat am Ende jedes Gerät ein einzigartiges, nicht zu klonendes Schlüsselpaar, das beim Ausschalten nicht auf dem Gerät gespeichert wird – aber der gleiche Schlüssel bei Bedarf neu generiert werden kann. Das schützt vor Angriffen, wenn das Gerät ausgeschaltet ist.

Weitere Informationen über gemeinsame Identitätslösung für IoT-Geräte bietet dieses aktuelles Webinar: Starke Geräteidentitäten durch SRAM-PUF-basierte Zertifikate.

Verlieren Sie nicht die (privaten) Schlüssel zu Ihrem Schloss!

Das Speichern von privaten Schlüsseln ist keine kryptische Geheimwissenschaft. Letztendlich hängt die richtige Wahl davon ab, wer die Zertifikate benutzt und wofür sie verwendet werden, von Vorschriften die Sie einhalten müssen, den Kosten und der aktuellen Umgebung und verfügbaren internen Ressourcen.

www.globalsign.de