Rootschlüssel

Rootschlüssel (sog. Kundenrootschlüssel (CRKs - Customer Root Keys)) stellen in Hyper Protect Crypto Services die Primärressourcen dar. Es sind symmetrische Key-Wrapping-Schlüssel, die als Vertrauensgrundlage verwendet werden, um das Wrapping (Verschlüsselung) anderer in einem Datenservice gespeicherter Datenverschlüsselungsschlüssel durchzuführen und dieses Wrapping wieder aufzuheben (Entschlüsselung). Mit Hyper Protect Crypto Services können Sie Rootschlüssel erstellen, speichern und ihren Lebenszyklus verwalten. Rootschlüssel, die in Hyper Protect Crypto Services erstellt werden, sind symmetrische 256-Bit-AES-Schlüssel. Im Gegensatz zu einem Standardschlüssel kann ein Rootschlüssel niemals außerhalb eines Hyper Protect Crypto Services-Service agieren. Weitere Informationen finden Sie in der Einführung in die Envelope-Verschlüsselung und unter Schlüssel verwalten.

Standardschlüssel

Standardschlüssel stellen eine weitere Ressource in Hyper Protect Crypto Services dar, mit der Daten direkt verschlüsselt und entschlüsselt werden können. Sie können Standardschlüssel mithilfe der Schritte in Schlüssel verwalten verwalten.

Datenverschlüsselungsschlüssel

Datenverschlüsselungsschlüssel (DEKs - Data Encryption Keys) sind Verschlüsselungsschlüssel, die Sie für die Datenverschlüsselung verwenden. Sie werden von benutzereigenen Anwendungen bereitgestellt und zum Verschlüsseln von Daten verwendet, die in Anwendungen gespeichert sind. Rootschlüssel, die Sie in Hyper Protect Crypto Services verwalten, dienen als Wrapping-Schlüssel zum Schutz von Datenverschlüsselungsschlüsseln (DEKs). Weitere Informationen finden Sie in der Einführung in die Envelope-Verschlüsselung.

Envelope-Verschlüsselung

Envelope-Verschlüsselung bezeichnet ein Verfahren der Verschlüsselung von Daten mit einem Datenverschlüsselungsschlüssel (DEK) und dem anschließenden Verschlüsseln des DEK mit einem Rootschlüssel, der von Ihnen vollständig verwaltet werden kann. Weitere Informationen finden Sie in der Einführung in die Envelope-Verschlüsselung.

Hardwaresicherheitsmodul

Ein Hardwaresicherheitsmodul (HSM) ist eine physische Einheit, die digitale Schlüssel für starke Authentifizierung schützt und verwaltet und die Verschlüsselungsverarbeitung bereitstellt. HSMs von IBM Cloud Hyper Protect Crypto Services sind mit FIPS 140-2 Stufe 4 zertifiziert. Dies ist das höchstmögliche Sicherheitsniveau für Verschlüsselungshardware. Auf dieser Sicherheitsstufe stellen die physischen Sicherheitsmechanismen eine vollständige Schutzhülle (sog. Envelope) für das Verschlüsselungsmodul bereit, mit der alle unbefugten Versuche des physischen Zugriffs erkannt und auf diese mit entsprechenden Maßnahmen reagiert wird.

Verschlüsselungseinheiten

Eine Verschlüsselungseinheit ist eine einzelne Einheit, die ein Hardwaresicherheitsmodul (HSM) und den entsprechenden Software-Stack darstellt, der dem HSM zur Verschlüsselung zugeordnet ist. In Hyper Protect Crypto Services stehen die folgenden Typen von Verschlüsselungseinheiten zur Verfügung:

• Operative Verschlüsselungseinheit

  Wenn Sie eine Hyper Protect Crypto Services-Instanz erstellen, ist die Anzahl der von Ihnen angegebenen Verschlüsselungseinheiten gleich der Anzahl der operativen Verschlüsselungseinheiten. Für die hohe Verfügbarkeit und die Wiederherstellung nach Störfällen müssen Sie mindestens zwei operative Verschlüsselungseinheiten einrichten. Diese operativen Verschlüsselungseinheiten befinden sich in verschiedenen Verfügbarkeitszonen derselben Region, in der sich Ihre Serviceinstanz befindet. Operative Verschlüsselungseinheiten werden verwendet, um Verschlüsselungsschlüssel zu verwalten und Verschlüsselungsoperationen auszuführen.

• Recovery-Verschlüsselungseinheit

  Wenn Sie Ihre Serviceinstanz in anderen Regionen als Madrid (eu-es) erstellen, werden Ihrer Serviceinstanz automatisch zwei Wiederherstellungsverschlüsselungseinheiten ohne zusätzliche Kosten zugeordnet: eine in derselben Region und eine in der Disaster-Recovery-Region für diese Region. Eine Wiederherstellungsverschlüsselungseinheit wird verwendet, um den zufälligen Masterschlüssel zu generieren, der dann sicher in operative Verschlüsselungseinheiten und die andere Wiederherstellungsverschlüsselungseinheit exportiert wird, um die Serviceinstanz zu initialisieren.

  Recovery-Verschlüsselungseinheiten können auch als Backup-Verschlüsselungseinheiten verwendet werden, die eine Kopie des Masterschlüsselwerts speichern, der von den operativen Verschlüsselungseinheiten verwendet wird. Wenn der Masterschlüssel verloren geht oder gelöscht wird, können Sie den Masterschlüssel mithilfe signierter TKE-Verwaltungsbefehle aus einer Wiederherstellungsverschlüsselungseinheit wiederherstellen.

  Wenn Smartcards zum Laden des Masterschlüssels verwendet werden, sind die Wiederherstellungsverschlüsselungseinheiten nicht anwendbar und können ignoriert werden. Die Sicherung des Masterschlüssels basiert in diesem Fall auf der Sicherung der Smart Cards.

• Failover-Verschlüsselungseinheit

  Failover-Verschlüsselungseinheiten sichern die operativen Verschlüsselungseinheiten und Keystores in einer anderen Region und werden initialisiert, um im Katastrophenfall eine schnelle Funktionsübernahme bereitzustellen. Für die Failover-Verschlüsselungseinheiten fallen zusätzliche Gebühren an. Diese Option ist im Moment nur in den Regionen us-south und us-east verfügbar. D. h., wenn Sie Ihre Instanz in einer der beiden Regionen erstellen, befinden sich die Failover-Verschlüsselungseinheiten in der anderen Region. Weitere Informationen zur Verwendung von Failover-Verschlüsselungseinheiten bei einer regionalen Störung finden Sie im Abschnitt zum Wiederherstellen von Daten mithilfe von Failover-Verschlüsselungseinheiten.

Administratoren

Administratoren können den Zielverschlüsselungseinheiten für die Ausgabe von Befehlen an die Verschlüsselungseinheiten hinzugefügt werden. Sie können bis zu acht Administratoren zu einer Verschlüsselungseinheit hinzufügen, um die Sicherheit zu erhöhen. Jeder Administrator verfügt über einen privaten Signaturschlüssel zur Identitätsauthentifizierung.

Signaturschlüssel

Ein Administrator muss alle an die Verschlüsselungseinheit ausgegebenen Befehle mit einem Signaturschlüssel signieren. Die in Hyper Protect Crypto Services erstellten Signaturschlüssel sind P521-Kurvenschlüssel (Elliptic Curve, EC). Der private Teil des Signaturschlüssels wird verwendet, um Signaturen zu erstellen. Der öffentliche Teil wird in ein Zertifikat gestellt, das in einer Zielverschlüsselungseinheit installiert ist, um einen Administrator für Verschlüsselungseinheiten zu definieren. Befehle, die im Druckmodus ausgegeben werden, müssen nicht mit Signaturschlüsseln signiert werden.

Modus 'imprint'

Die einem IBM Cloud-Benutzer zugeordneten Verschlüsselungseinheiten befinden sich zu Anfang in einem bereinigten Status, der als Modus 'imprint' bezeichnet wird.Die meisten Operationen von Verschlüsselungseinheiten sind im Modus „imprint“ inaktiviert, sodass eine Verschlüsselungseinheit im Modus „imprint“ nicht sicher ist. Im Modus „imprint“ können Sie Administratoren hinzufügen und Sie können den Modus „imprint“ verlassen, indem Sie einen signierten Befehl verwenden.Nachdem die Verschlüsselungseinheit den Modus „imprint“ verlassen hat, müssen alle Befehle zum Konfigurieren einer Verschlüsselungseinheit signiert werden.Sie müssen den Modus 'imprint' verlassen, bevor Sie Masterschlüssel laden können.

Quorumauthentifizierung

Eine Quorumauthentifizierung ist eine Methode, eine Operation durch eine Anzahl von Verschlüsselungseinheitenadministratoren zu genehmigen. Einige sensible Operationen wie das Festschreiben eines Masterschlüsselregisters, das Ändern der Signaturschwellenwerte und das Hinzufügen oder Entfernen von Administratoren, nachdem die Verschlüsselungseinheit den Modus 'imprint' verlassen hat, erfordern eine ausreichende Anzahl von Administratoren für Verschlüsselungseinheiten, um ihre Berechtigungsnachweise einzugeben. Eine Quorumauthentifizierung stellt sicher, dass keine einzelne Person eine kritische Änderung an der Verschlüsselungseinheit vornehmen kann. Vielmehr muss eine Mindestanzahl von Verschlüsselungseinheitenadministratoren (mindestens 2) zusammenarbeiten, um solche Operationen durchzuführen. Eine Quorumauthentifizierung macht es erforderlich, dass mehr als ein Verschlüsselungseinheitenadministrator eine Operation genehmigt, wodurch eine zusätzliche Schutzebene für die Verschlüsselungseinheit eingerichtet wird.

Signaturschwellenwerte

Die Signaturschwellenwerte einer Verschlüsselungseinheit steuern, wie viele Administratorsignaturen benötigt werden, um einen Befehl auszuführen. Im Modus 'imprint' sind die Signaturschwellenwerte auf null gesetzt. Zum Verlassen des Modus 'imprint' setzen Sie die Signaturschwellenwerte auf einen Wert größer als null. Wenn eine Verschlüsselungseinheit mit Nullen aufgefüllt wird, werden die Signaturschwellenwerte auf null gesetzt.

Es gibt zwei Typen von Signaturschwellenwerten für eine Verschlüsselungseinheit. Der Hauptsignaturschwellenwert steuert, wie viele Signaturen benötigt werden, um die meisten Verwaltungsbefehle auszuführen. Der Widerrufssignaturschwellenwert steuert, wie viele Signaturen zum Entfernen eines Administrators benötigt werden.Einige Befehle benötigen unabhängig von der Einstellung des Signaturschwellenwerts nur eine Signatur.

Die Einstellung der Signaturschwellenwerte auf einen Wert größer als 1 ermöglicht eine Quorumauthentifizierung durch mehrere Administratoren für sensible Operationen. Der Maximalwert, auf den Sie den Signaturschwellenwert und den Widerrufssignaturschwellenwert setzen können, ist 8. Dieser Wert ist gleichzeitig die maximale Anzahl von Administratoren, die einer Verschlüsselungseinheit hinzugefügt werden können.

Masterschlüssel

Der Masterschlüssel, der auch als HSM-Masterschlüssel bezeichnet wird, wird verwendet, um die Serviceinstanz für den Schlüsselspeicher zu verschlüsseln. Es handelt sich um einen symmetrischen 256-Bit-AES-Schlüssel. Mit dem Masterschlüssel übernehmen Sie die Eigentümerschaft an der Cloud-HSM und besitzen die Vertrauensgrundlage, mit der die gesamte Verschlüsselungsschlüsselhierarchie, einschließlich der Root- und Standardschlüssel im Schlüsselmanagement-Keystore sowie der Enterprise PKCS #11-Schlüssel (EP11) im EP11-Keystore, verschlüsselt wird. Sie müssen zuerst den Masterschlüssel konfigurieren, bevor Sie Verschlüsselungsschlüssel verwalten können. Eine Serviceinstanz kann nur einen einzigen Masterschlüssel haben. Das Löschen des Masterschlüssels der Serviceinstanz ist ein wirksames Verfahren, um alle Daten kryptografisch zu zerstören, die mit den in dem Service verwalteten Schlüsseln verschlüsselt wurden.

Masterschlüsselteil

Wenn Sie Ihre Serviceinstanz mithilfe von Schlüsselteildateien oder mithilfe von Smartcards zusammen mit den Verwaltungsdienstprogrammen initialisieren, besteht ein Masterschlüssel aus zwei oder drei Masterschlüsselteilen.Masterschlüsselteile, die in Hyper Protect Crypto Services erstellt werden, sind symmetrische 256-Bit-AES-Schlüssel. Aus Sicherheitsgründen kann jeder Schlüsselteil eine andere Person zum Eigner haben.Schlüsselteile werden in den Schlüsselteildateien der Workstation gespeichert, wenn das IBM Cloud-CLI-Plug-in TKE zum Laden des Masterschlüssels verwendet wird.Schlüsselbestandteile werden auf Smartcards gespeichert, wenn die Hyper Protect Crypto Services Managementdienstprogramme verwendet werden, um den Masterschlüssel zu laden.Der Eigentümer des Schlüsselteils muss die einzige Person sein, die das Dateikennwort oder die persönliche Identifikationsnummer (PIN) der Smartcard für das Schlüsselteil kennt.

IBM Cloud-CLI-Plug-in 'Trusted Key Entry'

Das CLI-Plug-in (CLI - Command Line Interface; Befehlszeilenschnittstelle) 'Trusted Key Entry' (TKE) ist ein CLI-Plug-in, das zusammen mit der IBM Cloud-CLI eingesetzt werden kann. Das Plug-in TKE stellt eine Reihe von Funktionen für die Verwaltung von Verschlüsselungseinheiten zur Verfügung, die einem IBM Cloud-Benutzerkonto zugeordnet sind. Sie können das Plug-in TKE verwenden, um Administratoren einzurichten und den Masterschlüssel mit den Anforderungen eines mittleren Sicherheitsniveaus zu laden. Das CLI-Plug-in TKE stellt zwei Ansätze zur Initialisierung von Serviceinstanzen bereit: Serviceinstanzen mithilfe von Schlüsselteildateien initialisieren und Serviceinstanzen mit Wiederherstellungsverschlüsselungseinheiten initialisieren. Eine vollständige Befehlsreferenz finden Sie in der Referenz zum CLI-Plug-in 'Trusted Key Entry'.

Managementdienstprogramme

Die Managementdienstprogramme bieten eine alternative Möglichkeit zum Konfigurieren von Serviceinstanzen mit Signaturschlüsseln und Masterschlüsselteilen, die auf Smartcards mit der höchsten Sicherheitsstufe gespeichert sind.Um die Managementdienstprogramme zu verwenden, müssen Sie von IBM unterstützte Smartcard-Leser und Smartcards bestellen.Ausführliche Anweisungen zur Installation und Konfiguration der Managementdienstprogramme finden Sie im Abschnitt zum Einrichten der Smartcards und Managementdienstprogramme und zum Initialisieren von Serviceinstanzen mithilfe von Smartcards und Managementdienstprogrammen.

Smartcards

Eine Smartcard ähnelt optisch einer Kreditkarte mit einem integrierten Chip.Der Chip kann eine begrenzte Anzahl von Verschlüsselungsoperationen ausführen und wird mit einer angepassten Software geladen.In den Managementdienstprogrammen lädt das Smartcard-Dienstprogramm angepasste Software auf die Smartcard, um zwei Typen von Smartcards zu erstellen:

• Smartcards für Zertifizierungsstelle: Richten eine Gruppe von Smartcards ein, die zusammenarbeiten können und als Smartcard-Zone bezeichnet werden.
• Enterprise PKCS #11-Smartcards (EP11-Smartcards): Enthalten einen Administratorsignaturschlüssel und bis zu 85 Masterschlüsselteile. Mit EP11-Smartcards können Sie einen Befehl mit einem privaten Signaturschlüssel signieren, der auf der Smartcard gespeichert wird, und einen Masterschlüsselteil für die Lieferung an eine Verschlüsselungseinheit verschlüsseln.

Die Smartcards werden durch eine PIN (persönliche Identifikationsnummer) geschützt, die auf dem PIN-Pad eines Smartcard-Lesers eingegeben werden muss, bevor die Smartcard bestimmte Operationen ausführen kann. Die EP11-Smartcard verfügt über eine einzige PIN.Die Smartcard für die Zertifizierungsstelle verfügt über zwei PINs und beide müssen eingegeben werden, um Operationen zu aktivieren.

Wenn auf einer EP11-Smartcard drei Mal eine falsche PIN eingegeben wird, wird die Smartcard gesperrt und kann nicht mehr für Operationen verwendet werden, für die eine PIN-Eingabe erforderlich ist.Eine blockierte EP11-Smartcard kann mit dem Smartcard-Dienstprogramm wieder entsperrt werden.Sie benötigen die Smartcard für die Zertifizierungsstelle, die zum Initialisieren der EP11-Smartcard verwendet wird, um die Blockierung einer EP11-Smartcard aufzuheben.Zum Aufheben der Blockierung einer EP11-Smartcard wählen Sie im Menü EP11-Smartcard > Blockierung der EP11-Smartcard aufheben aus und folgen dann den Eingabeaufforderungen.

Eine Smartcard für die Zertifizierungsstelle wird gesperrt, wenn fünf Mal eine falsche PIN eingegeben wurde.Wenn eine Smartcard für die Zertifizierungsstelle gesperrt wird, dann kann diese Sperre nicht aufgehoben werden.

Smartcard-Leser

Ein Smartcard-Lesegerät ist eine Einheit, die an eine Workstation angeschlossen wird und es der Workstation ermöglicht, mit einer Smartcard zu kommunizieren.Um auf eine Smartcard zugreifen zu können, muss die Smartcard in das Smartcard-Lesegerät eingelegt werden. Die meisten Smartcard-Operationen erfordern die Eingabe der Smartcard-PIN auf dem PIN-Pad des Smartcard-Lesers.

Der Treiber des Smartcard-Lesegeräts muss auf der Workstation installiert werden, bevor das Smartcard-Lesegerät verwendet werden kann.Weitere Informationen hierzu finden Sie im Abschnitt zum Installieren des Treibers für den Smartcard-Leser.

Smartcard-Dienstprogramm

Das Smartcard-Dienstprogramm ist eine der beiden Anwendungen, die als Teil der Managementdienstprogramme installiert werden.Es dient zum Einrichten und Verwalten der Smartcards, die von der Trusted Key Entry-Anwendung (TKE-Anwendung) genutzt werden.

Trusted Key Entry-Anwendung

Die Trusted Key Entry-Anwendung (TKE-Anwendung) ist eine der beiden Anwendungen, die als Teil der Managementdienstprogramme installiert werden.Sie verwendet Smartcards, um Masterschlüssel in Serviceinstanzen zu laden und weitere Konfigurationstasks für Serviceinstanzen auszuführen.

Keep Your Own Key

Von Hyper Protect Crypto Services wird die Funktion 'Keep Your Own Key' (KYOK) unterstützt. Sie können den Masterschlüssel so konfigurieren, dass er die vollständige Steuerung des Cloud-HSM übernimmt. Auf diese Weise erhalten Sie die uneingeschränkte Kontrolle über die Verschlüsselungsschlüssel und alle Berechtigungen für die Verschlüsselungsschlüssel, die Sie selbst bereitstellen, kontrollieren und verwalten können. Nur Sie selbst verfügen über Zugriff auf Ihre Verschlüsselungsschlüssel.

PKCS #11

Die API für Public-Key Cryptography Standards (PKCS) #11 definiert eine plattformunabhängige API für Verschlüsselungstokens, beispielsweise für Hardwaresicherheitsmodule (HSM) und Smartcards. Vorhandene Anwendungen, von denen PKCS #11 verwendet wird, können von der erweiterten Sicherheit aufgrund der sicheren Schlüsselverschlüsselung und der statusunabhängigen Schnittstelle profitieren, da die Verschlüsselungsoperationen wesentlich effizienter sind. Weitere Informationen finden Sie unter PKCS #11 -API.

Cryptoki

Die Schnittstelle für Verschlüsselungstoken (Cryptographic Token Interface), die im PKCS #11-Standard definiert ist. Cryptoki verfolgt einen einfachen objektorientierten Ansatz, der darauf ausgerichtet ist, von Technologie unabhängig zu sein und Ressourcen gemeinsam zu nutzen.

PKCS #11-Bibliothek

Eine PKCS #11-Bibliothek, die die Cryptoki-API-Funktionen implementiert, die im PKCS #11-Standard spezifiziert sind. Mithilfe der PKCS #11-Bibliothek können Ihre Anwendungen die PKCS #11-API für den Zugriff auf das Cloud-HSM von Hyper Protect Crypto Services verwenden, um Verschlüsselungsoperationen durchzuführen. Informationen zur Einrichtung der Bibliothek finden Sie unter Verschlüsselungsoperationen mit der PKCS #11-API durchführen.

Cryptoki-Token

Die logische Ansicht einer Verschlüsselungseinheit, die von Cryptoki definiert wird. Weitere Informationen finden Sie im Handbuch PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40-Logische Ansicht eines Tokens.

Cryptoki-Sitzung

Eine logische Verbindung zwischen einer Anwendung und einem Token. Cryptoki setzt voraus, dass eine Anwendung mindestens eine Sitzung mit einem Token öffnet, um Zugriff auf die Objekte und Funktionen des Tokens zu erhalten. Eine Sitzung kann eine Lese-/Schreibsitzung (R/W - Read/Write) oder eine schreibgeschützte Sitzung (R/O - Read only) sein.Weitere Informationen finden Sie unter Einführung in PKCS #11 - Sitzung.

Cryptoki-Objekt

Ein Element, das in einem Token gespeichert ist. Ein Objekt kann Daten, ein Zertifikat oder einen Schlüssel darstellen. Ein Datenobjekt wird von einer Anwendung definiert.Ein Zertifikatsobjekt speichert ein Zertifikat.Ein Schlüsselobjekt speichert einen Verschlüsselungsschlüssel.Jedes Merkmal des Objekts wird in einem Attribut definiert. Weitere Informationen finden Sie unter Einführung in PKCS #11 - Schlüsselobjekt.

Verfahren

Ein Prozess zur Implementierung einer Verschlüsselungsoperation.

Enterprise PKCS #11

Enterprise PKCS #11 (EP11) ist speziell für Kunden konzipiert, die Unterstützung für offene Standards und erhöhte Sicherheit suchen. Die EP11-Bibliothek stellt eine statusunabhängige Schnittstelle bereit, die der branchenüblichen PKCS #11-API ähnelt. Das HSM, in dem die Verschlüsselungseinheiten ausgeführt werden, unterstützt die EP11-Bibliothek, sodass Benutzer die EP11-API über gRPC für das eigene Schlüsselmanagement und die eigene Datenverschlüsselung aufrufen können. Weitere Informationen finden Sie unter Enterprise PKCS #11(EP11)Library structure document.

gRPC

gRPC ist ein modernes Open-Source-RPC-Framework (RPC - Remote Procedure Call; Prozedurfernaufruf) mit hoher Leistung, das Services in und zwischen Rechenzentren für den Lastausgleich, die Traceerstellung, die Statusprüfung und die Authentifizierung verbinden kann. Anwendungen greifen auf die EP11-Bibliothek von Hyper Protect Crypto Services zu, indem sie die EP11-API per Fernzugriff über gRPC aufrufen. Weitere Informationen zu gRPCfinden Sie in der Dokumentation zu gRPC.

Enterprise PKCS #11 über gRPC

IBM Cloud® Hyper Protect Crypto Services stellt eine Gruppe von Enterprise PKCS #11 (EP11) über gRPC-API-Aufrufe (auch als GREP11bezeichnet) bereit, mit denen alle Verschlüsselungsfunktionen in einem Cloud-HSM ausgeführt werden. EP11 über gRPC ist als statusunabhängige Schnittstelle für Verschlüsselungsoperationen in der Cloud konzipiert. Weitere Informationen zur GREP11-API finden Sie in der Einführung in EP11 über gRPC und in der GREP11-API-Referenz.