Anwendung

Eine Anwendung wird in einem einzelnen Adressraum ausgeführt. Alle Steuerungsthreads werden in der Anwendung ausgeführt. Eine Anwendung wird zu einer Cryptoki-Anwendung, indem sie die Cryptoki-Funktion C_Initialize aus einem der Threads heraus aufruft. Wenn dieser Aufruf erfolgt ist, kann die Anwendung weitere Cryptoki-Funktionen aufrufen. Wenn die Anwendung mit Cryptoki beendet wird, ruft sie die Cryptoki-Funktion C_Finalize auf und ist dann keine Cryptoki-Anwendung mehr.

Wenn Sie eine Java PKCS #11 mit dem SunPKCS11-Provider auf der Plattform IBM Z (s390x) ausführen, stellen Sie sicher, dass Sie beim Starten Ihrer Anwendung die neueste IBM Semeru-JVM verwenden und die Option -Xjit:noResumableTrapHandler Java angeben. Sie können die neueste s390x-Version der IBM Semeru-Java Virtual Machine (JVM) herunterladen, indem Sie das Filterfeld Architektur auf der IBM Semeru Runtime-Downloadseitein s390x ändern.

Benutzer

Der PKCS #11-Standard definiert zwei Typen von Benutzern für die Anmeldung: einen Sicherheitsbeauftragten (SO - Security Officer) und einen Normalbenutzer.Wenn sich ein Benutzer nicht mit der Cryptoki-Funktion C_Login anmeldet, wird der Benutzer auch als anonymer Benutzer geführt.Nur der Normalbenutzer kann auf private Objekte für das Token zugreifen und der Zugriff wird erst erteilt, nachdem der Normalbenutzer authentifiziert wurde. In der PKCS #11-Implementierung von Hyper Protect Crypto Services werden Sicherheitsbeauftragte und Normalbenutzer durch API-Schlüssel authentifiziert. Anonyme Benutzer werden ebenfalls unterstützt.Anweisungen zur Einrichtung von PKCS #11-Benutzertypen finden Sie unter Bewährte Verfahren zum Einrichten von PKCS #11-Benutzertypen.

Session

Die Cryptoki-API 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 stellt eine logische Verbindung zwischen der Anwendung und dem Token bereit. Eine Sitzung kann eine Lese-/Schreibsitzung (R/W - Read/Write) oder eine schreibgeschützte Sitzung (R/O - Read only) sein.

Um Zugriff auf die privaten Objekte des Tokens zu erhalten, muss sich der normale Benutzer anmelden und authentifiziert werden. Ausführliche Informationen zu Sitzungen finden Sie im Handbuch PKCS #11 Cryptographic Token Interface Usage Guide.

Schlüsselobjekt

Schlüsselobjekte werden entweder im speicherinternen Keystore, der sich in der PKCS #11-Anwendung befindet, oder in einem datenbankgestützten Keystore gespeichert.Wenn das Attribut CKA_TOKEN auf den Wert true für das Schlüsselobjekt gesetzt ist, wird das Schlüsselobjekt in dem datenbankgestützten Keystore gespeichert. Andernfalls wird das Schlüsselobjekt im speicherinternen Keystore gespeichert.

Schlüsselobjekte im speicherinternen Keystore werden nach der Rotation des Masterschlüssels nicht automatisch rotiert. Wenn die PKCS #11 -Keystores in Ihrer Serviceinstanz aktiviert sind, müssen Sie alle aktiven PKCS #11 -Anwendungen neu starten, um den speicherinternen Keystore nach Abschluss der Rotation des Masterschlüssels zu löschen.

Wie im folgenden Diagramm gezeigt, ist ein PKCS #11-Schlüsselobjekt ein Beispiel für eine PKCS #11-Objektklasse:

• Daten: Ein Datenobjekt wird von einer Anwendung definiert.
• Zertifikate: Ein Zertifikatsobjekt speichert ein Zertifikat.
• Schlüssel: Ein Schlüsselobjekt speichert einen Verschlüsselungsschlüssel.Der Schlüssel kann ein öffentlicher Schlüssel, ein privater Schlüssel oder ein geheimer Schlüssel sein. Jeder Typ dieser Schlüssel besitzt Untertypen für die Verwendung in bestimmten Mechanismen.
  • Öffentlicher Schlüssel: Die öffentliche Komponente eines Schlüsselpaares, die von jeder beliebigen Person zum Verschlüsseln von Nachrichten verwendet wird, die für einen bestimmten Empfänger gedacht sind, der Zugriff auf den privaten Schlüssel des Schlüsselpaares hat. Der öffentliche Schlüssel wird außerdem zur Prüfung von Signaturen verwendet, die mithilfe des privaten Schlüssels erstellt werden.
  • Privater Schlüssel: Die private Komponente eines Schlüsselpaares, die zum Entschlüsseln von Nachrichten verwendet wird. Der private Schlüssel wird außerdem zum Erstellen von Signaturen verwendet.
  • Geheimer Schlüssel: Ein geheimer Schlüssel ist ein generierter Bitstrom, der zur symmetrischen Ver- und Entschlüsselung von Nachrichten verwendet wird.

Cloud Identity and Access Management

IBM Cloud Identity and Access Management (IAM) stellt die Benutzerauthentifizierung und Zugriffssteuerung für die Implementierung der PKCS #11-API bereit. Durch die Verwendung von API-Schlüsseln ruft die PKCS #11-Bibliothek Trägertoken ab, die für die Ausführung von Cryptoki-API-Aufrufen verwendet werden.

In dieser Implementierung von PKCS #11 wird ein API-Schlüssel der PIN eines Benutzers gleichgesetzt. Weitere Informationen zum Einrichten der Service-ID und des entsprechenden API-Schlüssels finden Sie im Abschnitt zum Erstellen von Service-IDs für den SO-Benutzer, den normalen Benutzer und den anonymen Benutzer.

Crypto-Service

Im Rahmen des Initialisierungsprozesses für die PKCS #11-Bibliothek wird eine gRPC-Verbindung von der PKCS #11-Bibliothek zur IBM Cloud hergestellt. Die gRPC-Verbindung ermöglicht es der PKCS #11-Bibliothek, Cryptoki-Funktionen wie C_Encrypt, C_Decrypt, C_Sign und C_Verify aufzurufen, was die Verwendung eines Hardwaresicherheitsmoduls (HSM) erfordert.

Keystore

Es stehen zwei Haupttypen von Keystores zur Verfügung:

• Speicherinterne Keystores: Speichern Schlüsselobjekte temporär im Speicher. Schlüsselobjekte, die im speicherinternen Keystore gespeichert werden, werden auch als Sitzungsobjekte bezeichnet. Sitzungsobjekte in einer bestimmten Sitzung werden gelöscht, wenn Sie die Funktion C_CloseSession für diese Sitzung aufrufen. Sitzungsobjekte in allen Sitzungen werden gelöscht, wenn die Funktion C_Finalize aufgerufen wurde.
• Datenbankgestützte Keystores: Speichern Schlüsselobjekte in Datenbanken. Schlüsselobjekte, die im datenbankgestützten Keystore gespeichert werden, werden auch als Tokenobjekte bezeichnet. Wenn der Parameter sessionauth aktiviert und ein Kennwort für den Keystore konfiguriert wird, wird der datenbankgestützte Keystore verschlüsselt und authentifiziert. Standardmäßig ist der Parameter sessionauth inaktiviert. Für jede Serviceinstanz werden maximal fünf authentifizierte Keystores unterstützt. Sie können den Parameter sessionauth aktivieren, um die generierten Schlüssel im Keystore zu verschlüsseln oder den Schlüssel zu entschlüsseln, bevor Sie ihn verwenden. Das Kennwort kann 6 bis 8 Zeichen lang sein.

Die Keystore-Kennwörter werden nicht in der Serviceinstanz gespeichert. Als Keystore-Administrator sind Sie für die Verwaltung einer lokalen Kopie der Kennwörter verantwortlich. Wenn ein Kennwort verloren geht, müssen Sie sich an den IBM Support wenden, um den Keystore zurücksetzen zu lassen. Dies bedeutet, dass alle Daten im Keystore gelöscht werden.

Sowohl die speicherinternen Keystores als auch die datenbankgestützten Keystores setzen sich aus den folgenden Typen von Keystores zusammen:

• Öffentlicher Keystore: Speichert Schlüssel, die weniger sensibel sind und auf die beliebige Benutzertypen zugreifen können müssen.
• Privater Keystore: Speichert Schlüssel, mit denen sensible Daten verschlüsselt werden und auf die nur Normalbenutzer zugreifen können sollen.

Abhängig von den Einstellungen für Benutzertypen und Schlüsselattribute werden die generierten Schlüssel in verschiedenen Keystores gespeichert. In der folgenden Liste sind die Kriterien für die Speicherung der Schlüssel zusammengefasst:

• Der Attributwert CKA_TOKEN entscheidet, ob der generierte Schlüssel in einem speicherinternen Keystore oder in einem datenbankgestützten Keystore gespeichert wird.

  Wenn Sie den Schlüssel im datenbankgestützten Keystore speichern möchten, legen Sie CKA_TOKEN in den Vorlagen zur Schlüssel- oder Schlüsselpaargenerierung auf TRUE fest. Durch den Initialisierungsprozess für die PKCS #11-Bibliothek wird eine gRPC-Verbindung mit der IBM Cloud eingerichtet, die das Speichern und Abrufen von Schlüsselobjekten im datenbankgestützten Keystore ermöglicht. Standardmäßig ist CKA_TOKEN auf den Wert FALSE festgelegt, d. h. das Schlüsselobjekt ist in einem speicherinternen Keystore innerhalb des Prozessadressraums der PKCS #11-Anwendung gespeichert.

• Der Attributwert CKA_PRIVATE entscheidet, ob ein Schlüssel, der von Normalbenutzer generiert wird, in einem öffentlichen oder privaten Keystore gespeichert werden soll.

  Wenn ein Benutzer als Normalbenutzer angemeldet ist, werden die generierten Schlüssel standardmäßig in den privaten Keystores gespeichert, es sei denn, CKA_PRIVATE ist auf FALSE festgelegt. Ist ein Benutzer als SO-Benutzer angemeldet oder gar nicht angemeldet (anonymer Benutzer), werden die generierten Schlüssel immer in den öffentlichen Keystores gespeichert. Wenn ein SO-Benutzer oder ein anonymer Benutzer für CKA_PRIVATE den Wert TRUE in den Schlüsselgenerierungsvorlagen angibt, wird ein Fehler vom Server zurückgegeben.

  Bei einem asymmetrischen Schlüsselpaar müssen Sie das Attribut CKA_PRIVATE für private und öffentliche Schlüssel separat festlegen, d. h., die Schlüsselpaare können in verschiedenen Keystores gespeichert werden.

In der folgenden Tabelle finden Sie ausführliche Erläuterungen der Beziehungen zwischen Benutzertypen, Schlüsselattributen und Keystores sowie zur Speicherung von Schlüsseln.