Verschlüsselungsoperationen: GREP11-API

    message GetMechanismListRequest {
    }
    message GetMechanismListResponse {
      repeated uint64 Mechs = 2;
    }
    

    CK_RV m_GetMechanismList (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE_PTR mechs, CK_ULONG_PTR mechslen,
      Ziel 'target_t'
    );
    

C_GetMechanismList wird verwendet, um eine Liste der von einem Token unterstützten Mechanismen abzurufen. SlotID ist die ID des Slots des Tokens. pulCount verweist auf die Position, die die Anzahl der Mechanismen empfängt.

Es gibt zwei Möglichkeiten für eine Anwendung, C_GetMechanismList aufzurufen:

1. Wenn pMechanismList den Wert NULL_PTR hat, gibt C_GetMechanismList ausschließlich (in *pulCount) die Anzahl der Mechanismen zurück, jedoch nicht die Liste der Mechanismen. Der Inhalt von *pulCount bei der Eingabe für C_GetMechanismList hat in diesem Fall keine Bedeutung, und der Aufruf gibt den Wert CKR_OK zurück.
2. Wenn pMechanismList nicht NULL_PTR lautet, muss *pulCount die Größe (in Bezug auf CK_MECHANISM_TYPE-Elemente) des Puffers enthalten, auf den pMechanismList verweist. Wenn dieser Puffer groß genug ist, um die Liste der Mechanismen zu speichern, wird die Liste darin zurückgegeben und CKR_OK wird zurückgegeben. Wenn nicht, gibt der Aufruf von C_GetMechanismList den Wert CKR_BUFFER_TOO_SMALL zurück. In beiden Fällen wird der Wert für * pulCount so festgelegt, dass die Anzahl der Mechanismen gespeichert wird.

Da C_GetMechanismList keinen eigenen Speicherplatz zuordnet, ruft eine Anwendung häufig C_GetMechanismList zweimal auf. Dieses Verhalten ist jedoch keineswegs erforderlich.

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismList)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE_PTR pMechanismList,
      CK_ULONG_PTR pulCount
    );
    

    message GetMechanismInfoRequest {
      uint64 Mech = 2;
    }
    message GetMechanismInfoResponse {
      MechanismInfo MechInfo = 3;
    }
    

    CK_RV m_GetMechanismInfo (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE mech,
      CK_MECHANISM_INFO_PTR mechInfo,
      Ziel 'target_t'
    );
    

Informationen zu C_GetMechanismInfo ruft Informationen zu einem bestimmten Mechanismus ab, der von einem Token unterstützt wird. slotID ist die ID des Tokenslots; type ist der Typ des Mechanismus, pInfo verweist auf die Position, an der die Mechanismusinformationen empfangen werden.

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismInfo)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE type,
      CK_MECHANISM_INFO_PTR pInfo
    );
    

    message GenerateKeyRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> Template = 6;
    }
    message GenerateKeyResponse {
      bytes KeyBytes = 4;
      bytes CheckSum = 5;
    }
    

Implementierung der PKCS #11-Funktion C_GenerateKey.

TDES-Schlüssel werden mit der richtigen Parität generiert, die vom Host nicht beobachtet werden kann. Dies ist jedoch für die ordnungsgemäße Interoperabilität erforderlich: andere PKCS #11-Implementierungen müssen die DES-Schlüssel mit Paritätsproblemen zurückweisen.

Wird ein Objekt an eine Sitzung gebunden, muss (pin, plen) bei der Anmeldung bei dieser Sitzung von Login zurückgegeben worden sein. Bei der Beibehaltung von pin NULL wird ein öffentliches Objekt erstellt, das nicht an eine Anmeldesitzung gebunden ist.

(key, klen) gibt den Schlüssel-BLOB zurück. (csum, clen) enthält die Kontrollsumme des Schlüssels, d. h. die höchstwertigen Byte eines durch den Schlüssel verschlüsselten Blocks mit allen Nullen. NULL clen ist möglich, beispielsweise für symmetrische Schlüsselmechanismen ohne CKA_CHECK_VALUE-Parameter (z. B. RC4).

ptempl wird nur verwendet, wenn die Schlüssellänge (d. h. das Attribut CKA_VALUE_LEN) von dem Mechanismus benötigt wird. Wenn der Mechanismus implizit die Schlüsselgröße angibt, wird die Größe von ptempl nicht überprüft.

Beim Generieren von DSA-und DH-Parametern wird (csum, clen) ignoriert, sodass nur Parameterstrukturen generiert werden.

DSA, DH-Parameter (CKM_DSA_PARAMETER_GEN): Übergeben die Modulusbitanzahl im Teil CKA_PRIME_BITS der Attribute. Die "P,Q,G"-Struktur wird als Klartext ausgegeben (also nicht als BLOB).

Das BLOB pin wurde von Login ausgegeben.

Der PKCS #11-Schlüssel phKey ist keinem EP11-Parameter zugeordnet. (Die Hostbibliothek muss den Schlüssel mit Wrapping an die Kennung binden.)

    CK_RV m_GenerateKey (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
      const unsigned char *pin, size_t pinlen,
      Zeichen ohne Vorzeichen * key, size_t * keylen,
      Zeichen ohne Vorzeichen *checkSum, size_t *checkSumlen,
      Ziel 'target_t'
      );
    

C_GenerateKey generiert einen geheimen Schlüssel oder eine Gruppe von Domänenparametern und erstellt ein neues Objekt. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Generierungsmechanismus, pTemplate verweist auf die Vorlage für den neuen Schlüssel oder die neue Gruppe von Domänenparametern, ulCount ist die Anzahl der Attribute in der Vorlage, phKey verweist auf die Position, an der die Kennung des neuen Schlüssels oder der neuen Gruppe von Domänenparametern empfangen wird.

Wenn der Generierungsmechanismus für die Generierung von Domänenparametern vorgesehen ist, hat das Attribut CKA_CLASS den Wert CKO_DOMAIN_PARAMETERS, andernfalls den Wert CKO_SECRET_KEY.

Da der Typ des Schlüssels oder der Domänenparameter, die generiert werden sollen, implizit im Generierungsmechanismus vorhanden ist, muss die Vorlage keinen Schlüsseltyp bereitstellen. Wenn ein Schlüsseltyp angegeben wird, der mit dem Generierungsmechanismus nicht konsistent ist, schlägt C_GenerateKey fehl und gibt den Fehlercode CKR_TEMPLATE_INCONSISTENT zurück. Das Attribut CKA_CLASS wird auf dieselbe Weise behandelt.

Wenn ein Aufruf von C_DeriveKey die dafür bereitgestellten Vorlagen nicht unterstützen kann, schlägt er fehl und wird ohne die Erstellung eines Schlüsselobjekts zurückgegeben.

Das Objekt, das durch einen erfolgreichen Aufruf von C_GenerateKey erstellt wurde, hat das Attribut CKA_LOCAL auf CK_TRUE gesetzt.

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKey)(
      CK_SESSION_HANDLE hSession
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pTemplate,
      CK_ULONG ulCount,
      CK_OBJECT_HANDLE_PTR phKey
      );
    

    message GenerateKeyPairRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> PrivKeyTemplate = 7;
      map<uint64,AttributeValue> PubKeyTemplate = 8;
      }
    message GenerateKeyPairResponse {
      bytes PrivKeyBytes = 5;
      bytes PubKeyBytes = 6;
    }
    

Implementierung der PKCS #11-Funktion C_GenerateKeyPair.

KeyPair-Parameter werden aus den Parametern pmech, ppublic und pprivate abgerufen. Bei RSA-Schlüssel gibt ppublic die Modulusgröße an.

Im FIPS-Modus werden nur RSA-Modulverwendungen von 1024 + 256 n Bit unterstützt (Ganzzahl n). Im Nicht-FIPS-Modus lassen sich Schlüssel mit einer beliebigen Anzahl von Bit innerhalb der Grenzwerte in der Parameterliste des Mechanismus generieren.

Der öffentliche Schlüssel ist als Standard-SPKI (Subject Public Key Information) formatiert, die von den meisten Bibliotheken gelesen werden kann. Seine Integrität wird durch eine transportschlüsselspezifische MAC-Operation geschützt, die nicht zur eigentlichen SPKI gehört. Die Generierung von DSA-Parametern gibt eine Nicht-SPKI-Struktur im Feld für den öffentlichen Schlüssel zurück.

Wird ein Objekt an eine Sitzung gebunden, muss (pin, plen) bei der Anmeldung bei dieser Sitzung von Login zurückgegeben worden sein. Wenn pin NULL belassen wird, wird ein öffentliches Objekt erstellt, das die Anmeldesitzung überdauert.

Gibt einen privatem Schlüssel mit Wrapping an (key, klen) und einen öffentlichen Schlüssel als mit MAC verarbeitete ASN.1/DER-Struktur in (pubkey, pklen) zurück.

Die folgenden unterstützten Parameterkombinationen mit speziellen Hinweisen gehen über die PKCS #11-Dokumentation hinaus:

RSA-Schlüssel weisen öffentliche Exponenten unter 17 (0x11) zurück. Kontrollpunkte können das akzeptierte Minimum weiter einschränken. Der Fermat4-Exponent, 0x10001, wird von einem speziellen Kontrollpunkt gesteuert, der die Einschränkungen für öffentliche Exponenten von FIPS 186-3 erfüllt (Abschnitt B.3.1).

EC-Schlüssel (CKM_EC_KEY_PAIR_GEN): Kurvenparameter können als OIDs oder symbolische Namen (unsere namedCurve-Variante) angegeben werden. Unterstützte symbolische Namen sind "P-nnn" für NIST-Kurven (nnn ist eine unterstützte Bitanzahl für Primzahlen, 192-521), "BP-nnnR" für reguläre BP-Kurven. (Namen müssen als ASCII-Zeichenfolgen angegeben werden, ohne Nullen am Ende.)

DSA-Schlüssel (CKM_DSA_KEY_PAIR_GEN): Übergeben die "P,Q,G"-Struktur als Attribut CKA_IBM_STRUCT_PARAMS öffentlicher Attribute. P,Q,G-Parameter können nicht einzeln durch reguläre PKCS #11-Parameter übergeben werden, sie müssen zu einer Struktur kombiniert werden.

DH-Schlüssel (CKM_DH_PKCS_KEY_PAIR_GEN): Übergeben die "P,G"-Struktur als Attribut CKA_IBM_STRUCT_PARAMS öffentlicher Attribute. P,G-Parameter können nicht einzeln durch reguläre PKCS #11-Parameter übergeben werden, sie müssen zu einer Struktur kombiniert werden. Verwenden Sie zur Auswahl einer Bitanzahl privater Schlüssel (X) das Attribut XCP_U32_VALUE_BITS. Wenn es nicht vorhanden ist oder explizit der Wert 0 angegeben wird, wird die Bitanzahl auf Basis der P-Bitanzahl ausgewählt.

Die Verwendung des Sitzungsstatus (Anmeldestatus) ersetzt die Standardverwendung von Sitzungen. Die Zuordnung erfolgt außerhalb des Bibliotheksbereichs.

Das BLOB pin wurde von Login ausgegeben.

Der PKCS #11-Schlüssel hSession ist keinem EP11-Parameter zugeordnet. (Der Aufruf wird keiner Sitzung direkt zugeordnet.)

Der PKCS #11-Schlüssel phPublicKey ist keinem EP11-Parameter zugeordnet. (Die Hostbibliothek muss den öffentlichen Schlüssel (SPKI) der Kennung zuordnen.)

Der PKCS #11-Schlüssel phPrivateKey ist keinem EP11-Parameter zugeordnet. (Die Hostbibliothek muss den privaten Schlüssel der Kennung zuordnen.)

    CK_RV m_GenerateKeyPair (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR pubKeyTemplate, CK_ULONG pubKeyTemplatelen,
      CK_ATTRIBUTE_PTR privKeyTemplate, CK_ULONG privKeyTemplatelen,
      const unsigned char *pin, size_t pinlen,
      Zeichen ohne Vorzeichen *privKey, size_t *privKeylen
      unsigned char *pubKey, size_t *pubKeylen,
      Ziel 'target_t'
      );
    

C_GenerateKeyPair generiert ein Paar aus öffentlichem und privatem Schlüssel und erstellt neue Schlüsselobjekte. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Mechanismus zur Schlüsselgenerierung, pPublicKeyTemplate verweist auf die Schablone für den öffentlichen Schlüssel, ulPublicKeyAttributeCount ist die Anzahl der Attribute in der Schablone für öffentliche Schlüssel, pPrivateKeyTemplate verweist auf die Schablone für den privaten Schlüssel, ulPrivateKeyAttributeCount ist die Anzahl der Attribute in der Schablone für private Schlüssel; phPublicKey verweist auf die Position, welche die Kennung des neuen öffentlichen Schlüssels erhält, phPrivateKey verweist auf die Position, an der die Kennung des neuen privaten Schlüssels empfangen wird.

Da die Typen der zu generierenden Schlüssel implizit im Mechanismus für die Schlüsselpaargenerierung enthalten sind, müssen die Vorlagen keine Schlüsseltypen bereitstellen. Wenn eine der Vorlagen einen Schlüsseltyp angibt, der nicht mit dem Schlüsselgenerierungsmechanismus konsistent ist, schlägt C_GenerateKeyPair fehl und gibt den Fehlercode CKR_TEMPLATE_INCONSISTENT zurück. Das Attribut CKA_CLASS wird ähnlich behandelt.

Wenn ein Aufruf von C_GenerateKeyPair die dafür bereitgestellten Vorlagen nicht unterstützen kann, schlägt er fehl und wird ohne die Erstellung von Schlüsselobjekten zurückgegeben.

Ein Aufruf von C_GenerateKeyPair erstellt nie nur einen Schlüssel und kehrt dann zurück. Ein Aufruf kann fehlschlagen und keine Schlüssel erstellen; oder er kann erfolgreich sein und ein Paar aus öffentlichem und privatem Schlüssel erstellen.

Für die Schlüsselobjekte, die durch einen erfolgreichen Aufruf von C_GenerateKeyPair erstellt wurden, ist das Attribut CKA_LOCAL auf CK_TRUE gesetzt.

Beachten Sie die Reihenfolge der Argumente für C_GenerateKeyPair genau. Die beiden letzten Argumente haben nicht dieselbe Reihenfolge wie im ursprünglichen Cryptoki-Dokument Version 1.0. Unglücklicherweise stiftete die Reihenfolge dieser beiden Argumente Verwirrung.

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKeyPair)(
      CK_SESSION_HANDLE hSession,
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pPublicKeyTemplate,
      CK_ULONG ulPublicKeyAttributeCount,
      CK_ATTRIBUTE_PTR pPrivateKeyTemplate,
      CK_ULONG ulPrivateKeyAttributeCount,
      CK_OBJECT_HANDLE_PTR phPublicKey,
      CK_OBJECT_HANDLE_PTR phPrivateKey
      );
    

    message DeriveKeyRequest {
        Mechanism Mech = 1;
        bytes BaseKey = 3;
        bytes Data = 4;
        map<uint64,AttributeValue> Template = 8;
    }
    message DeriveKeyResponse {
        bytes NewKeyBytes = 6;
        bytes CheckSum = 7;
    }
    

Implementierung der PKCS #11-Funktion C_DeriveKey.

Das BLOB basekey,bklen muss aus dem PKCS #11-Parameter hBaseKey zugeordnet werden.

Der PKCS #11-Schlüssel hSession ist keinem EP11-Parameter zugeordnet. (Der Aufruf wird keiner Sitzung direkt zugeordnet.)

Der PKCS #11-Schlüssel phKey ist keinem EP11-Parameter zugeordnet. (Die Hostbibliothek muss den zurückgegebenen Schlüssel an die Kennung binden.)

    CK_RV m_DeriveKey (
        CK_MECHANISM_PTR mech,
        CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        const unsigned char *baseKey, size_t baseKeylen,
        const unsigned char *data, size_t datalen,
        const unsigned char *pin, size_t pinlen,
        unsigned char *newKey, size_t *newKeylen,
        Zeichen ohne Vorzeichen *checkSum, size_t *checkSumlen,
        Ziel 'target_t'
    );
    

C_DeriveKey leitet einen Schlüssel aus einem Basisschlüssel ab und erstellt ein neues Schlüsselobjekt. hSession ist die Kennung der Sitzung, pMechanism verweist auf eine Struktur, welche die Schlüsselableitungsstruktur angibt, hBaseKey ist die Kennung des Basisschlüssels, pTemplate verweist auf die Vorlage für den neuen Schlüssel, ulAttributeCount ist die Anzahl der Attribute in der Vorlage und phKey verweist auf die Position, an der die Kennung des abgeleiteten Schlüssels empfangen wird.

Die Werte der Attribute CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE und KA_NEVER_EXTRACTABLE für den Basisschlüssel wirken sich auf die Werte aus, die diese Attribute für den neu abgeleiteten Schlüssel enthalten können. Informationen zu Einschränkungen dieses Typs finden Sie in der Beschreibung der einzelnen Schlüsselableitungsmechanismen in Abschnitt 5.16.2 der PKCS #11-API-Spezifikation.

Wenn ein Aufruf von C_DeriveKey die dafür bereitgestellte Vorlage nicht unterstützen kann, schlägt er fehl und wird ohne die Erstellung eines Schlüsselobjekts zurückgegeben.

Das Attribut CKA_LOCAL des Schlüsselobjekts, das mit einem erfolgreichen Aufruf von C_DeriveKey erstellt wird, wird auf CK_FALSE eingestellt.

    CK_DEFINE_FUNCTION(CK_RV, C_DeriveKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hBaseKey,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message WrapKeyRequest {
        bytes Key = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 4;
    }
    message WrapKeyResponse {
        bytes Wrapped = 5;
    }
    

    CK_RV m_WrapKey (
        const unsigned char *key, size_t keylen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const CK_MECHANISM_PTR mech,
        CK_BYTE_PTR wrapped, CK_ULONG_PTR wrappedlen,
        Ziel 'target_t'
    );
    

C_WrapKey schließt einen privaten oder geheimen Schlüssel ein (d. h. verschlüsselt). hSession ist die Kennung der Sitzung, pMechanism verweist auf den Wrapping-Mechanismus, hWrappingKey ist die Kennung des Wrapping-Schlüssels, hKey ist die Kennung des Schlüssels, der eingeschlossen werden soll, pWrappedKey verweist auf die Position, an der der eingeschlossene Schlüssel empfangen wird, und pulWrappedKeyLen verweist auf die Position, an der die Länge des eingeschlossenen Schlüssels empfangen wird.

C_WrapKey verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Das Attribut CKA_WRAP des Wrapping-Schlüssels, das angibt, ob der Schlüssel die Wrapping-Operation unterstützt, muss CK_TRUE sein. Das Attribut CKA_EXTRACTABLE des Schlüssels, für den Wrapping ausgeführt werden soll, muss ebenfalls CK_TRUE sein.

Wenn das Wrapping für den entsprechenden Schlüssel aufgrund einer tokenspezifischen Ursache nicht ausgeführt werden kann, obwohl sein Attribut CKA_EXTRACTABLE auf CK_TRUE eingestellt wurde, schlägt C_WrapKey mit dem Fehlercode CKR_KEY_NOT_WRAPPABLE fehl. Wenn das Wrapping des Schlüssels mit dem angegebenen Wrapping-Schlüssel und -Mechanismus nur aufgrund seiner Länge nicht möglich ist, schlägt C_WrapKey mit dem Fehlercode CKR_KEY_SIZE_RANGE fehl.

C_WrapKey kann in den folgenden Situationen verwendet werden:

• Zum Wrapping eines geheimen Schlüssels mit einem öffentlichen Schlüssel, der die Verschlüsselung und Entschlüsselung unterstützt.
• Zum Wrapping eines geheimen Schlüssels mit einem beliebigen anderen geheimen Schlüssel. Dabei ist auf die Schlüsselgröße und die Stärke des Mechanismus zu achten. Andernfalls lässt das Token die Operation möglicherweise nicht zu.
• Zum Wrapping eines privaten Schlüssels mit einem beliebigen geheimen Schlüssel.

Token variieren in Bezug darauf, für welche Schlüsseltypen das Wrapping mit welchen Mechanismen durchgeführt werden kann.

Um die Wrapping-Schlüssel zu partitionieren, sodass sie nur eine Teilmenge der extrahierbaren Schlüssel einschließen können, kann das Attribut CKA_WRAP_TEMPLATE im Wrapping-Schlüssel verwendet werden, um eine Attributgruppe anzugeben, die mit den Attributen des Schlüssels verglichen werden kann, der eingeschlossen werden soll. Wenn alle Attribute den C_FindObject-Regeln zum Attributabgleich entsprechen, wird die Wrapping-Operation fortgesetzt. Der Wert dieses Attributs ist eine Attributvorlage, und die Größe ist die Anzahl der Elemente in der Vorlage, multipliziert mit der Größe von CK_ATTRIBUTE. Wenn dieses Attribut nicht angegeben wird, ist jede beliebige Vorlage akzeptabel. Wenn ein Attribut nicht vorhanden ist, wird es nicht überprüft. Weist ein Attribut bei einem Wrapping-Versuch für einen Schlüssel eine fehlende Übereinstimmung auf, gibt die Funktion CKR_KEY_HANDLE_INVALID zurück.

    CK_DEFINE_FUNCTION(CK_RV, C_WrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hWrappingKey,
        CK_OBJECT_HANDLE hKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG_PTR pulWrappedKeyLen
    );
    

    message UnwrapKeyRequest {
        bytes Wrapped = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 5;
        map<uint64,AttributeValue> Template = 9;
    }
    message UnwrapKeyResponse {
        bytes UnwrappedBytes = 7;
        bytes CheckSum = 8;
    }
    

Implementierung der PKCS #11-Funktion C_UnwrapKey.

uwmech gibt den Verschlüsselungsmechanismus an, der zum Entschlüsseln eingeschlossener Daten verwendet wird. ptempl ist eine Schlüssel(-paar) -Parameterliste, die angibt, wie die nicht eingeschlossenen Daten in einen neuen Schlüssel umgewandelt werden sollen (muss CKA_KEY_TYPE enthalten).

Das generierte Objekt wird unter (unwrapped, uwlen) als BLOB zurückgegeben. Symmetrische Schlüssel geben ihre Schlüsselkontrollsumme (3 Byte) unter (csum, cslen)zurück. Objekte mit öffentlichem Schlüssel geben ihren öffentlichen Schlüssel als SPKI in (csum, cslen) zurück. Auf beide Formate folgt ein 4-Byte-Big-Endian-Wert, der die Bitanzahl des Schlüssels mit aufgehobenem Wrapping codiert.

Wenn eine SPKI in eine MACed SPKI umgesetzt wird, muss CKM_IBM_TRANSPORTKEY als Unwrapping-Mechanismus verwendet werden. Dieser Modus stellt die unformatierte SPKI als Daten mit Wrapping bereit und ignoriert den KEK.

UnwrapKey erzeugt paritätsbereinigte DES-Schlüssel (innerhalb der Blobs), toleriert jedoch Eingaben mit unzulässiger Parität.

    CK_RV m_UnwrapKey (
        const CK_BYTE_PTR wrapped, CK_ULONG wrappedlen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const unsigned char *pin, size_t pinlen,
        const CK_MECHANISM_PTR mech,
        const CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        unsigned char * unwrapped, size_t * unwrappedlen,
        CK_BYTE_PTR checkSum, CK_ULONG *checkSumlen,
        Ziel 'target_t'
    );
    

C_UnwrapKey hebt das Wrapping eines eingeschlossenen Schlüssels auf (d. h. entschlüsselt ihn) und erstellt einen neuen privaten Schlüssel oder ein neues Objekt für einen geheimen Schlüssel. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Unwrapping-Mechanismus, hUnwrappingKey ist die Kennung des Unwrapping-Schlüssels, pWrappedKey verweist auf den eingeschlossenen Schlüssel, ulWrappedKeyLen ist die Länge des eingeschlossenen Schlüssels, pTemplate verweist auf die Vorlage für den neuen Schlüssel, ulAttributeCount ist die Anzahl der Attribute in der Vorlage, phKey verweist auf die Position, an der die Kennung des wiederhergestellten Schlüssels empfangen wird.

Das Attribut CKA_UNWRAP des Schlüssels zum Aufheben des Wrappings, das angibt, ob der Schlüssel die Unwrapping-Operation unterstützt, muss CK_TRUE sein.

Das Attribut CKA_ALWAYS_SENSITIVE des neuen Schlüssels wird auf CK_FALSE eingestellt und das Attribut CKA_NEVER_EXTRACTABLE auf CK_FALSE. Das Attribut CKA_EXTRACTABLE wird standardmäßig auf CK_TRUE eingestellt.

Einige Mechanismen können Änderungen vornehmen oder dies versuchen. Der Inhalt der pMechanism-Struktur zu dem Zeitpunkt, an dem das Wrapping des Schlüssels aufgehoben wird.

Wenn ein Aufruf von C_UnwrapKey die dafür bereitgestellte Vorlage nicht unterstützen kann, schlägt er fehl und wird ohne die Erstellung eines Schlüsselobjekts zurückgegeben.

Das Attribut CKA_LOCAL des Schlüsselobjekts, das mit einem erfolgreichen Aufruf von C_UnwrapKey erstellt wird, wird auf CK_FALSE eingestellt.

Um die Unwrapping-Schlüssel zu partitionieren, sodass sie das Wrapping nur für eine Untergruppe von Schlüsseln aufheben können, kann das Attribut CKA_UNWRAP_TEMPLATE auf den Unwrapping-Schlüssel angewendet werden, um eine Attributgruppe anzugeben, die zu den Attributen des Schlüssels hinzugefügt wird, für den das Wrapping aufgehoben werden soll. Wenn es keinen Konflikt zwischen den Attributen und der vom Benutzer bereitgestellten Attributvorlage in pTemplate gibt, wird die Operation zum Aufheben des Wrappings fortgesetzt. Der Wert dieses Attributs ist eine Attributvorlage, und die Größe ist die Anzahl der Elemente in der Vorlage, multipliziert mit der Größe von CK_ATTRIBUTE. Wenn dieses Attribut im Unwrapping-Schlüssel nicht vorhanden ist, werden keine zusätzlichen Attribute hinzugefügt. Wenn bei dem Versuch, das Wrapping eines Schlüssels aufzuheben, ein Attributkonflikt auftritt, gibt die Funktion SHALL den Wert CKR_TEMPLATE_INKONSISTENT zurück.

    CK_DEFINE_FUNCTION(CK_RV, C_UnwrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hUnwrappingKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG ulWrappedKeyLen,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message RewrapKeyBlobRequest {
    	bytes WrappedKey = 1;
    }
    message RewrapKeyBlobResponse {
    	bytes RewrappedKey = 1;
    }
    

    message GetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message GetAttributeValueResponse {
        map<uint64,AttributeValue> Attributes = 4;
    }
    

Implementierung der PKCS #11-Funktion C_GetAttributeValue.

Benötigt keine Sitzungen (Teil eines BLOB) und stellt keine Sitzungen dar, verwendet daher nicht den Parameter hSession.

EP11 verwendet unkompliziertere Entschlüsselungsmethoden wie z. B. das Nummerieren tatsächlicher Werte anstelle generischerer Verfahren.

    CK_RV m_GetAttributeValue (
        const unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        Ziel 'target_t'
    );
    

Das Attribut c_GetAttributeValue ruft den Wert eines oder mehrerer Attribute eines Objekts ab. hSession ist die Kennung der Sitzung, hObject ist die Kennung des Objekts, pTemplate verweist auf eine Vorlage, die angibt, welche Attributwerte abgerufen werden sollen, und empfängt die Attributwerte, ulCount ist die Anzahl der Attribute in der Vorlage.

Für jedes Tripel (type, pValue, ulValueLen) in der Vorlage führt C_GetAttributeValue den folgenden Algorithmus aus:

1. Wenn das angegebene Attribut (d. h. das durch das Typfeld angegebene Attribut) für das Objekt nicht angezeigt werden kann, weil das Objekt sensibel oder nicht extrahierbar ist, wird das Feld ulValueLen in diesem Tripel so geändert, dass es den Wert CK_UNAVAILABLE_INFORMATION enthält.
2. Andernfalls, wenn der angegebene Wert für das Objekt ungültig ist (wenn das Objekt kein solches Attribut besitzt), wird das Feld ulValueLen in diesem Tripel so geändert, dass es den Wert CK_UNAVAILABLE_INFORMATION enthält.
3. Andernfalls, wenn das Feld pValue den Wert NULL_PTR aufweist, wird das Feld ulValueLen so geändert, dass es die genaue Länge des angegebenen Attributs für das Objekt enthält.
4. Andernfalls, wenn die in ulValueLen angegebene Länge groß genug ist, um den Wert des angegebenen Attributs für das Objekt zu enthalten, wird dieses Attribut in den Puffer unter pValue kopiert, und das Feld ulValueLenwird so geändert, dass es die genaue Länge des Attributs enthält.
5. Andernfalls wird das Feld ulValueLen so geändert, dass es den Wert CK_UNAVAILABLE_INFORMATIONenthält.

Wenn Fall 1 auf eines der angeforderten Attribute zutrifft, muss der Aufruf den Wert CKR_ATTRIBUTE_SENSITIVEzurückgeben. Wenn Fall 2 auf eines der angeforderten Attribute zutrifft, muss der Aufruf den Wert CKR_ATTRIBUTE_TYPE_INVALIDzurückgeben. Wenn Fall 5 auf eines der angeforderten Attribute zutrifft, muss der Aufruf den Wert CKR_BUFFER_TOO_SMALLzurückgeben. Wenn mehrere dieser Fehlercodes zutreffen, kann Cryptoki wie üblich einen beliebigen dieser Fehlercodes zurückgeben. Nur wenn keiner von ihnen auf eines der angeforderten Attribute zutrifft, wird CKR_OK zurückgegeben.

Im besonderen Fall eines Attributs, dessen Wert ein Array aus Attributen darstellt, wie zum Beispiel CKA_WRAP_TEMPLATE, und das mit pValue ungleich NULL weitergegeben wird, lautet der pValue der Elemente innerhalb des Arrays NULL_PTR und ulValueLen der Elemente innerhalb des Arrays wird auf die erfordrliche Länge gesetzt. Wenn der Wert pValue von Elementen in dem Array nicht NULL_PTR ist, muss das Element ulValueLen von Attributen in dem Array den Speicherplatz angeben, auf den der entsprechende Wert pValue verweist und der mit pValue gefüllt wird, wenn der Speicherplatz ausreicht. Daher ist es wichtig, den Inhalt eines Puffers zu initialisieren, bevor C_GetAttributeValue aufgerufen wird, um einen solchen Array-Wert abzurufen. Wenn ein Wert für ulValueLen in dem Array nicht groß genug ist, wird er auf CK_UNAVAILABLE_INFORMATION festgelegt, und die Funktion gibt CKR_BUFFER_TOO_SMALL zurück, ebenso wie in dem Fall, dass ein Attribut im Argument pTemplate einen zu kleinen Wert für ulValueLen hat. Jedes Attribut, dessen Wert ein Array von Attributen ist, kann anhand der Gruppe CKF_ARRAY_ATTRIBUTE des Attributtyps identifiziert werden.

Die Fehlercodes CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALID und CKR_BUFFER_TOO_SMALL bedeuten keine wirklichen Fehler für C_GetAttributeValue. Wenn ein Aufruf von C_GetAttributeValue einen dieser drei Werte zurückgibt, muss der Aufruf trotzdem jedes Attribut in der Vorlage verarbeitet haben, die an C_GetAttributeValue bereitgestellt wird. Jedes Attribut in der Vorlage, dessen Wert mit einem Aufruf von C_GetAttributeValue zurückgegeben werden kann, wird mit dem Aufruf von C_GetAttributeValue zurückgegeben.

    CK_DEFINE_FUNCTION(CK_RV, C_GetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message SetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message SetAttributeValueResponse {
        bytes Object = 1;
    }
    

Implementierung der PKCS #11-Funktion C_SetAttributeValue.

Attributliste: siehe _GetAttrValue

Derzeit sendet Ep11 nur boolesche Attribute. Alle anderen Attribute werden vom Host verarbeitet (und Ep11 modifiziert keine Arrays wie WRAP_TEMPLATE).

Benötigt keine Sitzungen (Teil eines BLOB) und stellt keine Sitzungen dar, verwendet daher nicht den PKCS #11-Parameter hSession.

    CK_RV m_SetAttributeValue (
        unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        Ziel 'target_t'
    );
    

C_SetAttributeValue ändert den Wert eines oder mehrerer Attribute eines Objekts. hSession ist die Kennung der Sitzung, hObject ist die Kennung des Objekts; pTemplate verweist auf eine Vorlage, die angibt, welche Attributwerte geändert werden sollen, sowie ihre neuen Werte; ulCount ist die Anzahl der Attribute in der Vorlage.

Bestimmte Objekte können nicht geändert werden. Wenn Sie C_SetAttributeValue für solche Objekte aufrufen, wird der Fehlercode CKR_ACTION_PROHIBITED angezeigt. Eine Anwendung kann mithilfe des Attributs CKA_MODIFIABLE des Objekts bestimmen, ob ein Objekt geändert werden kann.

Nur Sitzungsobjekte können während einer schreibgeschützten Sitzung geändert werden.

Die Vorlage kann neue Werte für alle Attribute des Objekts angeben, die geändert werden können. Wenn die Schablone einen Wert für ein Attribut angibt, das mit anderen vorhandenen Attributen des Objekts nicht kompatibel ist, schlägt der Aufruf mit dem Rückkehrcode CKR_TEMPLATE_INCONSISTENT fehl.

Nicht alle Attribute können geändert werden. Weitere Informationen hierzu finden Sie im Abschnitt 4.1.2 der PKCS #11-API-Spezifikation.

    CK_DEFINE_FUNCTION(CK_RV, C_SetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message GenerateRandomRequest {
        uint64 Len = 1;
    }
    message GenerateRandomResponse {
        bytes Rnd = 1;
    }
    

Implementierung der PKCS #11-Funktion C_GenerateRandom.

GenerateRandom ist äquivalent zu der ursprünglichen PKCS #11-Funktion. Intern wird eine durch die Hardware ausgelöste Entropie über einen FIPS-konformen DRNG (ANSI X9.31/ISO 18031, je nach Clic-Version) übertragen.

Die Hostbibliothek könnte Zufallszahlen generieren, ohne sie an das Back-End zu senden, wenn die entsprechende Funktionalität auf dem Host verfügbar wäre. Dies wird in der aktuellen Implementierung nicht gemacht.

Diese Funktion unterstützt keine Größenabfrage.

    CK_RV m_GenerateRandom (
        CK_BYTE_PTR rnd, CK_ULONG rndlen,
        Ziel 'target_t'
    );
    

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateRandom)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pRandomData,
        CK_ULONG ulRandomLen
    );
    

    message EncryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message EncryptInitResponse {
        bytes State = 1;
    }
    

Implementierung der PKCS #11-Funktion C_EncryptInit.

Das BLOB (key, klen) kann ein Objekt mit öffentlichem Schlüssel oder ein BLOB mit geheimem Schlüssel sein. Der Schlüsseltyp muss mit pmech konsistent sein.

Bei Mechanismen mit öffentlichem Schlüssel muss (key, klen) eine SPKI enthalten. Dieses SPKI verfügt über einen Integritätsschutz mit einem MAC-Schlüssel, der von GenerateKeyPair zurückgegeben wird (alternativ auch UnwrapKey). Der Verschlüsselungsstatus wird ohne Sitzungseinschränkungen erstellt.

Bei Mechanismen für geheime Schlüssel übernimmt der Verschlüsselungsstatus die Einschränkungen für die Objektsitzung aus (key, klen).

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

(key, klen) muss ein Schlüssel-BLOB sein.

    CK_RV m_EncryptInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        Ziel 'target_t'
    );
    

C_EncryptInit initialisiert eine Verschlüsselungsoperation. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Verschlüsselungsmechanismus, hKey ist die Kennung des Verschlüsselungsschlüssels.

Das Attribut CKA_ENCRYPT des Verschlüsselungsschlüssels, das angibt, ob der Schlüssel die Verschlüsselung unterstützt, muss CK_TRUE sein.

Nach dem Anwendungsaufruf von C_EncryptInit kann die Anwendung entweder C_Encrypt aufrufen, um Daten in einem einzigen Teil zu verschlüsseln, oder sie kann C_EncryptUpdate null Mal oder mehrmals aufrufen, gefolgt von C_EncryptFinal, um Daten in mehreren Teilen zu verschlüsseln. Die Verschlüsselungsoperation ist so lange aktiv, bis die Anwendung den endgültigen Abschnitt mit verschlüsseltem Text mit einem Aufruf an C_Encrypt oder C_EncryptFinal abruft. Zur Verarbeitung weiterer Daten (in einem oder mehreren Teilen) muss die Anwendung C_EncryptInit erneut aufrufen.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message EncryptRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptResponse {
        bytes Ciphered = 3;
    }
    

Implementierung der PKCS #11-Funktion C_Encrypt.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von EncryptInit ausgegeben.

    CK_RV m_Encrypt (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        Ziel 'target_t'
    );
    

C_Encrypt verschlüsselt einteilige Daten. hSession ist die Kennung der Sitzung, pData verweist auf die Daten, ulDataLen ist die Länge der Daten in Byte, pEncryptedData verweist auf die Position, welche die verschlüsselten Daten empfängt, pulEncryptedDataLen verweist auf die Position, welche die Länge der verschlüsselten Daten in Byte enthält.

C_Encrypt verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Verschlüsselungsoperation muss mit C_EncryptInit initialisiert werden. Ein Aufruf von C_Encrypt beendet stets die aktive Verschlüsselungsoperation, es sei denn, es wird CKR_BUFFER_TOO_SMALL zurückgegeben oder es ist ein erfolgreicher Aufruf (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der zum Speichern des verschlüsselten Texts erforderlich ist.

C_Encrypt kann nicht verwendet werden, um eine mehrteilige Operation zu beenden, und muss ohne intervenierende C_EncryptUpdate-Aufrufe nach C_EncryptInit aufgerufen werden.

Bei einigen Verschlüsselungsmechanismen haben die eingegebenen Klartextdaten bestimmte Längenbeschränkungen (entweder weil der Mechanismus nur relativ kurze Klartextteile verschlüsseln kann oder weil die Eingabedaten des Mechanismus aus einer ganzzahligen Anzahl von Blöcken bestehen müssen). Wenn diese Bedingungen nicht erfüllt sind, schlägt C_Encrypt mit dem Rückgabecode CKR_DATA_LEN_RANGE fehl.

Der Klartext und der verschlüsselte Text können sich an derselben Position befinden, d. h., es ist OK, wenn pData und pEncryptedData auf dieselbe Position verweisen.

Bei den meisten Mechanismen ist C_Encrypt äquivalent zu einer Folge von C_EncryptUpdate-Operationen mit anschließendem C_EncryptFinal.

    CK_DEFINE_FUNCTION(CK_RV, C_Encrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG_PTR pulEncryptedDataLen
    );
    

    message EncryptUpdateRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptUpdateResponse {
        bytes State = 1;
        bytes Ciphered = 3;
    }
    

Implementierung der PKCS #11-Funktion C_EncryptUpdate.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von EncryptInit ausgegeben.

    CK_RV m_EncryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        Ziel 'target_t'
    );
    

C_EncryptUpdate setzt eine mehrteilige Verschlüsselungsoperation fort und verarbeitet einen anderen Datenabschnitt. hSession ist die Kennung der Sitzung, pPart verweist auf den Datenteil, ulPartLen ist die Länge des Datenteils, pEncryptedPart verweist auf die Position, die den verschlüsselten Datenteil empfängt, pulEncryptedPartLen verweist auf die Position, welche die Länge des verschlüsselten Datenteils in Byte enthält.

C_EncryptUpdate verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Verschlüsselungsoperation muss mit C_EncryptInit initialisiert werden. Diese Funktion kann beliebig oft hintereinander aufgerufen werden. Ein Aufruf von C_EncryptUpdate, der zu einem Fehler führt (mit Ausnahme von CKR_BUFFER_TOO_SMALL), beendet die aktuelle Verschlüsselungsoperation.

plaintext und ciphertext können sich an derselben Position befinden, d. h., es ist zulässig, wenn pPart und pEncryptedPart auf dieselbe Position verweisen.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG_PTR pulEncryptedPartLen
    );
    

    message EncryptFinalRequest {
        bytes State = 1;
    }
    message EncryptFinalResponse {
        bytes Ciphered = 2;
    }
    

Implementierung der PKCS #11-Funktion C_EncryptFinal.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von EncryptInit und EncryptUpdate ausgegeben.

    CK_RV m_EncryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        Ziel 'target_t'
    );
    

C_EncryptFinal beendet eine mehrteilige Verschlüsselungsoperation. hSession ist die Kennung der Sitzung, pLastEncryptedPart verweist auf die Position, die den letzten verschlüsselten Datenabschnitt empfängt (falls vorhanden), pulLastEncryptedPartLen verweist auf die Position, welche die Länge des letzten verschlüsselten Datenabschnitts enthält.

C_EncryptFinal verwendet die in Abschnitt 5.2 von PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Verschlüsselungsoperation muss mit C_EncryptInit initialisiert werden. Ein Aufruf von C_EncryptFinal beendet immer die aktive Verschlüsselungsoperation, sofern er nicht CKR_BUFFER_TOO_SMALL zurückgibt oder ein erfolgreicher Aufruf ist (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der für die Aufnahme des verschlüsselten Texts erforderlich ist.

Bei einigen mehrteiligen Verschlüsselungsmechanismen gelten für die Klartexteingabedaten bestimmte Längenbeschränkungen, da die Eingabedaten des Mechanismus aus einer ganzzahligen Anzahl von Blöcken bestehen müssen. Wenn diese Bedingungen nicht beachtet werden, schlägt C_EncryptFinal mit dem Rückkehrcode CKR_DATA_LEN_RANGE fehl.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastEncryptedPart,
        CK_ULONG_PTR pulLastEncryptedPartLen
    );
    

    message EncryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Plain = 3;
    }
    message EncryptSingleResponse {
        bytes Ciphered = 4;
    }
    

Vom Standard abweichende Variante von Encrypt. Verarbeitet Daten in einem Durchgang, mit einem einzigen Aufruf. Gibt keinen Status an den Host zurück, nur die verschlüsselten Daten.

Das ist die bevorzugte Methode zur Verschlüsselung von Daten in einem Durchgang für XCP-sensitive Anwendungen. Sie ist funktional äquivalent zu EncryptInit mit sofort anschließendem Encrypt, erspart jedoch Umläufe und Wrapping/Unwrapping.

Wenn das Back-End residente Schlüssel unterstützt, kann es sich bei dem Schlüssel auch um eine Kennung mit residenten Schlüsseln handeln.

Siehe auch: Encrypt, EncryptInit, DecryptSingle.

Das BLOB key wurde von GenerateKey und UnwrapKey ausgegeben.

    CK_RV m_EncryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        Ziel 'target_t'
    );
    

    message ReencryptSingleRequest {
        bytes DecKey = 1;
        bytes EncKey = 2;
        Mechanism DecMech = 3;
        Mechanism EncMech = 4;
        bytes Ciphered = 5;
    }
    message ReencryptSingleResponse {
        bytes Reciphered = 6;
    }
    

Vom Standard abweichende Variante von Encrypt. Verarbeitet Daten in einem Durchgang, mit einem einzigen Aufruf. Gibt keinen Status an den Host zurück, nur die erneut verschlüsselten Daten.

Entschlüsselt Daten mit dem Originalschlüssel und verschlüsselt dann die Rohdaten mit einem anderen Schlüssel innerhalb des Cloud-HSM.

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey, size_t dkeylen,
        const ohne Vorzeichen char * ekey, size_t ekeylen,
        CK_MECHANISM_PTR decmech,
        CK_MECHANISM_PTR encmech,
        CK_BYTE_PTR in, CK_ULONG inlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        Ziel 'target_t'
    );
    

    message DecryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message DecryptInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_DecryptInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        Ziel 'target_t'
    );
    

C_DecryptInit initialisiert eine Entschlüsselungsoperation. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Entschlüsselungsmechanismus, hKey ist die Kennung des Entschlüsselungsschlüssels.

Das Attribut CKA_DECRYPT des Entschlüsselungsschlüssels, das angibt, ob der Schlüssel die Entschlüsselung unterstützt, muss CK_TRUE sein.

Nachdem die Anwendung C_DecryptInit aufgerufen hat, kann die Anwendung entweder C_Decrypt aufrufen, um Daten in einem einzelnen Abschnitt zu entschlüsseln, oder C_DecryptUpdate null oder mehrere Male aufrufen, gefolgt von C_DecryptFinal, um Daten in mehreren Abschnitten zu entschlüsseln. Die Entschlüsselungsoperation ist so lange aktiv, bis die Anwendung den endgültigen Abschnitt mit Klartext mit einem Aufruf an C_Decrypt oder C_DecryptFinal abruft. Zur Verarbeitung weiterer Daten (in einem oder mehreren Teilen) muss die Anwendung C_DecryptInit erneut aufrufen.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptInit)(
        K_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message DecryptRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptResponse {
       bytes Plain = 3;
    }
    

Implementierung von PKCS #11 C_Decrypt. (state, slen) wird nicht aktualisiert.

Das große Binärobjekt (BLOB) "state, slen" muss aus dem PKCS #11-Parameter hSession zugeordnet werden. Das BLOB "state" wurde von DecryptInit ausgegeben.

    CK_RV m_Decrypt (const unsigned char *state, size_t slen,
        CK_BYTE_PTR cipher, CK_ULONG clen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plen,
        Ziel 'target_t'
    );
    

C_Decrypt entschlüsselt verschlüsselte Daten in einem einzigen Teil.

• hSession ist die Sitzungskennung.
• pEncryptedData verweist auf die verschlüsselten Daten.
• ulEncryptedDataLen ist die Länge der verschlüsselten Daten.
• pData verweist auf die Position, die die wiederhergestellten Daten empfängt.
• pulDataLen verweist auf die Position, die die Länge der wiederhergestellten Daten enthält.

C_Decrypt verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Entschlüsselungsoperation muss mit C_DecryptInit initialisiert werden. Ein Aufruf von C_Decrypt beendet immer die aktive Entschlüsselungsoperation, es sei denn, es wird CKR_BUFFER_TOO_SMALL zurückgegeben oder es handelt sich um einen erfolgreichen Aufruf mit der Rückgabe von CKR_OK , um die Länge des Puffers zu ermitteln, der zum Speichern des Klartexts erforderlich ist.

C_Decrypt kann nicht verwendet werden, um eine mehrteilige Operation zu beenden, und muss ohne intervenierende C_DecryptUpdate-Aufrufe nach C_DecryptInit aufgerufen werden.

Der verschlüsselte Text und der einfache Text können sich an derselben Stelle befinden. Dies bedeutet, dass es zulässig ist, wenn pEncryptedData und pData auf dieselbe Position verweisen.

Wenn die eingegebenen verschlüsselten Textdaten nicht entschlüsselt werden können, weil sie eine unzulässige Länge aufweisen, kann CKR_ENCRYPTED_DATA_INVALID oder CKR_ENCRYPTED_DATA_LEN_RANGE zurückgegeben werden.

    CK_DEFINE_FUNCTION(CK_RV, C_Decrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG ulEncryptedDataLen,
        CK_BYTE_PTR pData,
        CK_ULONG_PTR pulDataLen
    );
    

    message DecryptUpdateRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptUpdateResponse {
        bytes State = 1;
        bytes Plain = 3;
    }
    

Implementierung der PKCS #11-Funktion C_DecryptUpdate.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von DecryptInit ausgegeben.

    CK_RV m_DecryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        Ziel 'target_t'
    );
    

C_DecryptUpdate setzt eine mehrteilige Entschlüsselungsoperation fort und verarbeitet einen weiteren verschlüsselten Datenabschnitt. hSession ist die Kennung der Sitzung, pEncryptedPart verweist auf den Abschnitt für verschlüsselte Daten, ulEncryptedPartLen ist die Länge des Abschnitts für verschlüsselte Daten, pPart verweist auf die Position, die den Abschnitt für wiederhergestellte Daten empfängt, pulPartLen verweist auf die Position, welche die Länge des Abschnitts für wiederhergestellte Daten enthält.

C_DecryptUpdate verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Verschlüsselungsoperation muss mit C_DecryptInit initialisiert werden. Diese Funktion kann beliebig oft hintereinander aufgerufen werden. Ein Aufruf von C_DecryptUpdate, der zu einem Fehler führt (mit Ausnahme von CKR_BUFFER_TOO_SMALL), beendet die aktuelle Entschlüsselungsoperation.

Der verschlüsselte Text und der einfache Text können sich an derselben Stelle befinden, d. h., es ist OK, wenn pEncryptedPart und pPart auf dieselbe Position verweisen.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG ulEncryptedPartLen,
        CK_BYTE_PTR pPart,
        CK_ULONG_PTR pulPartLen
    );
    

    message DecryptFinalRequest {
        bytes State = 1;
    }
    message DecryptFinalResponse {
        bytes Plain = 2;
    }
    

Implementierung der PKCS #11-Funktion C_DecryptFinal.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von DecryptInit und DecryptUpdate ausgegeben.

    CK_RV m_DecryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        Ziel 'target_t'
    );
    

C_DecryptFinal beendet eine mehrteilige Entschlüsselungsoperation. hSession ist die Kennung der Sitzung, pLastPart verweist auf die Position, die den zuletzt wiederhergestellten Datenteil empfängt (falls vorhanden), pulLastPartLen verweist auf die Position, welche die Länge des zuletzt wiederhergestellten Datenteils enthält.

C_DecryptFinal verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Verschlüsselungsoperation muss mit C_DecryptInit initialisiert werden. Ein Aufruf von C_DecryptFinal beendet immer die aktive Entschlüsselungsoperation, es sei denn, es gibt CKR_BUFFER_TOO_SMALL zurück oder es handelt sich um einen erfolgreichen Aufruf (d. h. einen Aufruf, der CKR_OKzurückgibt), um die Länge des Puffers zu ermitteln, der zum Speichern des Klartexts erforderlich ist.

Wenn die eingegebenen verschlüsselten Textdaten nicht entschlüsselt werden können, weil sie eine unzulässige Länge aufweisen, kann CKR_ENCRYPTED_DATA_INVALID oder CKR_ENCRYPTED_DATA_LEN_RANGE zurückgegeben werden.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastPart,
        CK_ULONG_PTR pulLastPartLen
    );
    

    message DecryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Ciphered = 3;
    }
    message DecryptSingleResponse {
        bytes Plain = 4;
    }
    

Vom Standard abweichende Variante von Decrypt. Verarbeitet Daten in einem Durchgang, mit einem einzigen Aufruf. Gibt keinen Status an den Host zurück, nur die entschlüsselten Daten.

Das ist die bevorzugte Methode zur Verschlüsselung von Daten in einem Durchgang für XCP-sensitive Anwendungen. Sie ist funktional äquivalent zu DecryptInit mit sofort anschließendem Decrypt, erspart jedoch Umläufe und Wrapping/Unwrapping.

Wenn das Back-End residente Schlüssel unterstützt, kann es sich bei dem Schlüssel auch um eine Kennung mit residenten Schlüsseln handeln.

Siehe auch: Decrypt, DecryptInit, EncryptSingle.

Das BLOB key wurde von GenerateKey und UnwrapKey ausgegeben.

    CK_RV m_DecryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        Ziel 'target_t'
    );
    

    message SignInitRequest {
        Mechanism Mech = 2;
        bytes PrivKey = 3;
    }
    message SignInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_SignInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *privKey, size_t privKeylen,
        Ziel 'target_t'
    );
    

C_SignInit initialisiert eine Signaturoperation, bei der die Signatur einen Anhang der Daten darstellt. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Signaturmechanismus, hKey ist die Kennung des Signaturschlüssels.

Das Attribut CKA_SIGN des Signaturschlüssels, das angibt, ob der Schlüssel die Signatur unterstützt, muss CK_TRUE sein.

Nach dem Anwendungsaufruf von C_SignInit kann die Anwendung entweder C_Sign aufrufen, um Daten in einem einzigen Teil zu signieren, oder sie kann C_SignUpdate einmal oder mehrmals aufrufen, gefolgt von C_SignFinal, um Daten in mehreren Teilen zu signieren. Die Signaturoperation ist so lange aktiv, bis die Anwendung die Signatur mit einem Aufruf an C_Sign oder C_SignFinal abruft. Zur Verarbeitung weiterer Daten (in einem oder mehreren Teilen) muss die Anwendung C_SignInit erneut aufrufen.

    CK_DEFINE_FUNCTION(CK_RV, C_SignInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message SignRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignResponse {
        bytes Signature = 3;
    }
    

Implementierung der PKCS #11-Funktion C_Sign.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von SignInit ausgegeben.

    CK_RV m_Sign (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        Ziel 'target_t'
    );
    

C_Sign signiert Daten in einem einzelnen Abschnitt, wobei die Signatur ein Anhang der Daten ist. hSession ist die Kennung der Sitzung, pData verweist auf die Daten, ulDataLen ist die Länge der Daten, pSignature verweist auf die Position, an der die Signatur empfangen wird, pulSignatureLen verweist auf die Position, welche die Länge der Signatur enthält.

C_Sign verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Signieroperation muss mit C_SignInit initialisiert werden. Ein Aufruf von C_Sign beendet immer die aktive Signieroperation, sofern er nicht CKR_BUFFER_TOO_SMALL zurückgibt oder ein erfolgreicher Aufruf ist (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der für die Aufnahme der Signatur erforderlich ist.

C_Sign kann nicht verwendet werden, um eine mehrteilige Operation zu beenden, und muss ohne intervenierende C_SignUpdate-Aufrufe nach C_SignInit aufgerufen werden.

Bei den meisten Mechanismen ist C_Sign äquivalent zu einer Folge von C_SignUpdate-Operationen mit anschließendem C_SignFinal.

    CK_DEFINE_FUNCTION(CK_RV, C_Sign)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignUpdateResponse {
        bytes State = 1;
    }
    

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von SignInit ausgegeben.

    CK_RV m_SignUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        Ziel 'target_t'
    );
    

C_SignUpdate setzt eine mehrteilige Signaturoperation fort und verarbeitet einen anderen Datenabschnitt. hSession ist die Kennung der Sitzung, pPart verweist auf den Datenteil, ulPartLen ist die Länge des Datenteils.

Die Signaturoperation muss mit C_SignInit initialisiert werden. Diese Funktion kann beliebig oft hintereinander aufgerufen werden. Ein Aufruf von C_SignUpdate, der zu einem Fehler führt, beendet die aktuelle Signaturoperation.

    CK_DEFINE_FUNCTION(CK_RV, C_SignUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message SignFinalRequest {
        bytes State = 1;
    }
    message SignFinalResponse {
        bytes Signature = 2;
    }
    

Implementierung der PKCS #11-Funktion C_SignFinal.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von SignInit und SignUpdate ausgegeben.

    CK_RV m_SignFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        Ziel 'target_t'
    );
    

C_SignFinal beendet eine mehrteilige Signaturoperation und gibt die Signatur zurück. hSession ist die Kennung der Sitzung, pSignature verweist auf die Position, welche die Signatur empfängt, pulSignatureLen verweist auf die Position, welche die Länge der Signatur enthält.

C_SignFinal verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Signieroperation muss mit C_SignInit initialisiert werden. Ein Aufruf von C_SignFinal beendet immer die aktive Signieroperation, sofern er nicht CKR_BUFFER_TOO_SMALL zurückgibt oder ein erfolgreicher Aufruf ist (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der für die Aufnahme der Signatur erforderlich ist.

    CK_DEFINE_FUNCTION(CK_RV, C_SignFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignSingleRequest {
        bytes PrivKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
    }
    message SignSingleResponse {
        bytes Signature = 4;
    }
    

Vom Standard abweichende Erweiterung, Kombination von SignInit und Sign. Signiert Daten oder verarbeitet sie mit MAC in einem Durchgang, mit einem einzigen Aufruf, ohne einen temporären Digest-Status aufzubauen. Sie gibt keinen Status an den Host zurück, nur das Ergebnis.

Dies ist die bevorzugte Art der Signierung, ohne einen zusätzlichen Umlauf und ohne zusätzliche Verschlüsselung und Entschlüsselung. Funktional ist SignSingle äquivalent zu SignInit mit sofort anschließendem Sign.

Das BLOB (key, klen) und der Mechanismus pmech müssen zusammen an SignInit übergeben werden können.

Mehrdatenanforderungen für HMAC- und CMAC-Signaturen werden unterstützt (Untervarianten 2 und 3).

Siehe auch: SignInit, Sign, VerifySingle.

    CK_RV m_SignSingle (
        const unsigned char *privKey, size_t privKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        Ziel 'target_t'
    );
    

    message VerifyInitRequest {
        Mechanism Mech = 2;
        bytes PubKey = 3;
    }
    message VerifyInitResponse {
        bytes State = 1;
    }
    

Implementierung der PKCS #11-Funktion C_VerifyInit. Initialisieren Sie bei einem Schlüssel-BLOB (key, klen) einen Status zur Sitzungsverifizierung in (state, slen). Das Schlüssel-BLOB kann ein Objekt mit öffentlichem Schlüssel oder HMAC-Schlüsselbyte sein. Der Typ des Schlüssel-BLOBs muss mit pmech konsistent sein.

Bei Mechanismen mit öffentlichem Schlüssel muss (key, klen) eine SPKI enthalten. Diese SPKI CKA_UNWRAP kann mit MAC verarbeitet werden (wie zuvor von GenerateKeyPair zurückgegeben) oder es kann sich lediglich um die SPKI selbst handeln (wenn sie aus einer externen Quelle wie einem Zertifikat abgerufen wird).

Bei der Initialisierung einer HMAC-Operation werden Sitzungseinschränkungen des Objekts Verify von dem HMAC-Schlüssel übernommen. Da SPKIs nicht an Sitzungen gebunden sind, sind die Verifizierungszustände von öffentlichen Schlüsseln sitzungsfrei.

Das BLOB key,klen muss aus dem PKCS #11-Parameter hKey zugeordnet werden.

Hinweis: SignInit und VerifyInit sind intern die für HMAC und andere Symmetrie-/MAC-Mechanismen.

    CK_RV m_VerifyInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *pubKey, size_t pubKeylen,
        Ziel 'target_t'
    );
    

C_VerifyInit initialisiert eine Verifizierungsoperation, wobei die Signatur ein Anhang der Daten ist. hSession ist die Kennung der Sitzung, pMechanism verweist auf die Struktur, die den Prüfmechanismus angibt, hKey ist die Kennung des Prüfschlüssels.

Das Attribut CKA_VERIFY des Verifizierungsschlüssels, das angibt, ob der Schlüssel die Verifizierung unterstützt, wobei die Signatur ein Anhang an die Daten ist, muss CK_TRUE sein.

Nach dem Anwendungsaufruf von C_VerifyInit kann die Anwendung entweder C_Verify aufrufen, um eine Signatur für Daten in einem einzigen Teil zu verifizieren, oder sie kann C_VerifyUpdate einmal oder mehrmals aufrufen, gefolgt von C_VerifyFinal, um eine Signatur für Daten in mehreren Teilen zu verifizieren. Die Verifizierungsoperation ist aktiv, bis die Anwendung C_Verify oder C_VerifyFinal aufruft. Zur Verarbeitung weiterer Daten (in einem oder mehreren Teilen) muss die Anwendung C_VerifyInit erneut aufrufen.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message VerifyRequest {
        bytes State = 1;
        bytes Data = 2;
        bytes Signature = 3;
    }
    message VerifyResponse {
    }
    

Implementierung der PKCS #11-Funktion C_Verify.

Aktualisiert (state, slen) nicht.

Die relative Reihenfolge von Daten und Signatur ist umgekehrt. in VerifySingle.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von VerifyInit ausgegeben.

    CK_RV m_Verify (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        Ziel 'target_t'
    );
    

C_Verify überprüft eine Signatur in einer einteiligen Operation, wobei die Signatur ein Anhang der Daten ist. hSession ist die Kennung der Sitzung, pData verweist auf die Daten, ulDataLen ist die Länge der Daten, pSignature verweist auf die Signatur, ulSignatureLen ist die Länge der Signatur.

Die Verifizierungsoperation muss mit C_VerifyInit initialisiert werden. Ein Aufruf von C_Verify beendet immer die aktive Verifizierungsoperation.

Ein erfolgreicher Aufruf von C_Verify muss den Wert CKR_OK (gibt an, das die bereitgestellte Signatur gültig ist) oder CKR_SIGNATURE_INVALID (gibt an, dass die bereitgestellte Signatur ungültig ist) zurückgeben. Wenn die Signatur nur aufgrund ihrer Länge ungültig ist, dann muss CKR_SIGNATURE_LEN_RANGE zurückgegeben werden. In allen diesen Fällen wird die aktive Signieroperation beendet.

C_Verify kann nicht verwendet werden, um eine mehrteilige Operation zu beenden, und muss ohne intervenierende C_VerifyUpdate-Aufrufe nach C_VerifyInit aufgerufen werden.

Bei den meisten Mechanismen ist C_Verify äquivalent zu einer Folge von C_VerifyUpdate-Operationen mit anschließendem C_VerifyFinal.

    CK_DEFINE_FUNCTION(CK_RV, C_Verify)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifyUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message VerifyUpdateResponse {
        bytes State = 1;
    }
    

Implementierung der PKCS #11-Funktion C_VerifyUpdate.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von VerifyInit ausgegeben.

    CK_RV m_VerifyUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        Ziel 'target_t'
    );
    

C_VerifyUpdate setzt eine mehrteilige Verifizierungsoperation fort und verarbeitet einen anderen Datenabschnitt. hSession ist die Kennung der Sitzung, pPart verweist auf den Datenteil, ulPartLen gibt die Länge des Datenteils an.

Die Verifizierungsoperation muss mit C_VerifyInit initialisiert werden. Diese Funktion kann beliebig oft hintereinander aufgerufen werden. Ein Aufruf von C_VerifyUpdate, der zu einem Fehler führt, beendet die aktuelle Verifizierungsoperation.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message VerifyFinalRequest {
        bytes State = 1;
        bytes Signature = 2;
    }
    message VerifyFinalResponse {
    }
    

Implementierung der PKCS #11-Funktion C_VerifyFinal.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von VerifyInit und VerifyUpdate ausgegeben.

    CK_RV m_VerifyFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        Ziel 'target_t'
    );
    

C_VerifyFinal beendet eine mehrteilige Verifizierungsoperation und überprüft die Signatur. hSession ist die Kennung der Sitzung, pSignature verweist auf die Signatur, ulSignatureLen ist die Länge der Signatur.

Die Verifizierungsoperation muss mit C_VerifyInit initialisiert werden. Ein Aufruf von C_VerifyFinal beendet immer die aktive Verifizierungsoperation.

Ein erfolgreicher Aufruf von C_VerifyFinal muss den Wert CKR_OK (gibt an, das die bereitgestellte Signatur gültig ist) oder CKR_SIGNATURE_INVALID (gibt an, dass die bereitgestellte Signatur ungültig ist) zurückgeben. Wenn die Signatur aufgrund ihrer Länge ungültig ist, dann muss CKR_SIGNATURE_LEN_RANGE zurückgegeben werden. In allen diesen Fällen wird die aktive Verifizierungsoperation beendet.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifySingleRequest {
        bytes PubKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
        bytes Signature = 4;
    }
    message VerifySingleResponse {
    }
    

Vom Standard abweichende Erweiterung, Kombination von VerifyInit und Verify. Signiert Daten oder verarbeitet sie mit MAC in einem Durchgang, mit einem einzigen Aufruf, ohne einen temporären Digest-Status aufzubauen. Sie gibt keinen Status an den Host zurück, nur das Verifizierungsergebnis. Es gibt keine Größenabfrage, da diese Funktion einen booleschen Wert zurückgibt.

Dies ist die bevorzugte Art der Signaturprüfung, ohne einen zusätzlichen Umlauf und ohne zusätzliche Verschlüsselung und Entschlüsselung. Funktional ist VerifySingle äquivalent zu VerifyInit mit sofort anschließendem Verify.

Das BLOB (key, klen) und der Mechanismus pmech müssen zusammen an VerifyInit übergeben werden können.

Bei Mechanismen mit öffentlichem Schlüssel muss (key, klen) eine SPKI enthalten. Diese SPKI kann mit MAC verarbeitet (beispielsweise als öffentlicher Schlüssel von GenerateKeyPair zurückgegeben) werden oder es kann sich lediglich um die SPKI selbst handeln (wenn sie aus einer externen Quelle wie einem Zertifikat abgerufen wird).

Siehe auch: VerifyInit, Verify, SignSingle.

    CK_RV m_VerifySingle (
        const unsigned char *pubKey, size_t pubKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        Ziel 'target_t'
    );
    

    message DigestInitRequest {
        Mechanism Mech = 2;
    }
    message DigestInitResponse {
        bytes State = 1;
    }
    

Implementierung der PKCS #11-Funktion C_DigestInit.

Erstellt einen Digest-Status mit Wrapping.

Hinweis: Größenabfragen werden unterstützt, aber im Gegensatz zu den meisten Größenabfragen (die anstelle der tatsächlichen Ausgabe eine Ausgabegröße zurückgeben) wird der Wrappingstatus immer vom Back-End zurückgegeben. Digest-Zustände sind so klein, dass sie keinen spürbaren Systemaufwand für Transport verursachen.

Bei Größenabfragen verwirft der Host nur den zurückgegebenen Status und meldet die BLOB-Größe (in len). Bei der Rückgabe eines BLOB wird len mit der zurückgegebenen Größe abgeglichen.

Das BLOB state,len muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss das BLOB an die Sitzung binden.)

    CK_RV m_DigestInit (
        unsigned char * state, size_t * len,
        const CK_MECHANISM_PTR mech,
        Ziel 'target_t'
    );
    

C_DigestInit initialisiert eine Message-Digest-Operation. hSession ist die Kennung der Sitzung, pMechanism verweist auf den Digest-Mechanismus.

Nach dem Anwendungsaufruf von C_DigestInit kann die Anwendung entweder C_Digest aufrufen, um Daten in einem einzigen Teil zu verarbeiten, oder sie kann C_DigestUpdate null Mal oder mehrmals aufrufen, gefolgt von C_DigestFinal, um Daten in mehreren Teilen zu verarbeiten. Die Message-Digest-Operation ist aktiv, bis die Anwendung einen Aufruf von C_Digest oder C_DigestFinal ausführt, um den Message-Digest abzurufen. Zur Verarbeitung weiterer Daten (in einem oder mehreren Teilen) muss die Anwendung 1C_DigestInit1 erneut aufrufen.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism
    );
    

    message DigestRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestResponse {
        bytes Digest = 3;
    }
    

Implementierung der PKCS #11-Funktion C_Digest.

Wenn ein Digest-Objekt genau 0 (null) Bytes hat, die nach der Erstellung in einer beliebigen Kombination von Null-Byte-Übertragungen angehängt werden, kann es trotzdem einen One-Pass-Digest durchführen, auch wenn es von einer strikten Implementierung zurückgewiesen werden muss.

Aktualisiert (state, slen) nicht.

Implementierungen können DigestUpdate-, DigestFinal-oder Digest -Aufrufe für Klartext-Digest-Objekte im Host-Code unter Umgehung von HSM-Back-Ends. Diese Auswahl kann für den Host-Code sichtbar sein oder nicht und wirkt sich nicht auf die Sicherheit der Operation aus (da Klartextobjekte keine sensiblen Daten verarbeiten können).

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. Das BLOB state wurde von DigestInit ausgegeben.

    CK_RV m_Digest (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        Ziel 'target_t'
    );
    

C_Digest verarbeitet Daten in einem einzelnen Teil. hSession ist die Kennung der Sitzung, pData verweist auf die Daten, ulDataLen ist die Länge der Daten, pDigest verweist auf die Position, die den Nachrichtenauszug empfängt, pulDigestLen verweist auf die Position, welche die Länge des Nachrichtenauszugs enthält.

C_Digest verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Digest-Operation muss mit C_DigestInit initialisiert werden. Ein Aufruf von C_Digest beendet immer die aktive Digest-Operation, sofern er nicht CKR_BUFFER_TOO_SMALL zurückgibt oder ein erfolgreicher Aufruf ist (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der für die Aufnahme des Message-Digests erforderlich ist.

C_Digest kann nicht verwendet werden, um eine mehrteilige Operation zu beenden, und muss ohne intervenierende C_DigestUpdate-Aufrufe nach C_DigestInit aufgerufen werden.

Die Eingabedaten und die Digest-Ausgabe können sich an derselben Position befinden, d. h., es ist zulässig, wenn pData und pDigest auf dieselbe Position verweisen.

C_Digest ist äquivalent zu einer Folge von C_DigestUpdate-Operationen mit anschließendem C_DigestFinal.

    CK_DEFINE_FUNCTION(CK_RV, C_Digest)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestUpdateResponse {
        bytes State = 1;
    }
    

Implementierung der PKCS #11-Funktion C_DigestUpdate.

DigestUpdate ist polymorph, Akzeptieren von eingeschlossenen oder leeren Digest-Objekten und Aktualisieren des Status in demselben Format.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden. (Die Hostbibliothek muss die Sitzung dem gespeicherten Status zuordnen.)

Das BLOB state wurde von DigestInit, DigestUpdate und DigestKey ausgegeben.

Siehe auch: DigestInit

    CK_RV m_DigestUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        Ziel 'target_t'
    );
    

C_DigestUpdate setzt eine mehrteilige Message-Digest-Operation fort und verarbeitet einen anderen Datenteil. hSession ist die Kennung der Sitzung, pPart verweist auf den Datenteil, ulPartLen ist die Länge des Datenteils.

Die Message-Digest-Operation muss mit C_DigestInit initialisiert werden. Aufrufe an diese Funktion und an C_DigestKey können beliebig oft in beliebiger Reihenfolge eingefügt werden. Ein Aufruf von C_DigestUpdate, der zu einem Fehler führt, beendet die aktuelle Digest-Operation.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message DigestFinalRequest {
        bytes State = 1;
    }
    message DigestFinalResponse {
        bytes Digest = 2;
    }
    

Implementierung der PKCS #11-Funktion C_DigestFinal.

DigestFinal ist polymorph und akzeptiert sowohl Digest-Objekte mit Wrapping als auch in Klartext.

Aktualisiert (state, slen) nicht.

Das BLOB state,slen muss aus dem PKCS #11-Parameter hSession zugeordnet werden.

Das BLOB state wurde von DigestInit, DigestUpdate und DigestKey ausgegeben.

    CK_RV m_DigestFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        Ziel 'target_t'
    );
    

C_DigestFinal beendet eine mehrteilige Message-Digest-Operation und gibt den Message-Digest zurück. hSession ist die Kennung der Sitzung, pDigest verweist auf die Position, die den Nachrichtenauszug empfängt, pulDigestLen verweist auf die Position, welche die Länge des Nachrichtenauszugs enthält.

C_DigestFinal verwendet die in Abschnitt 5.2 der PKCS #11-API-Spezifikation beschriebene Konvention für die Ausgabeerstellung.

Die Digest-Operation muss mit C_DigestInit initialisiert werden. Ein Aufruf von C_DigestFinal beendet immer die aktive Digest-Operation, sofern er nicht CKR_BUFFER_TOO_SMALL zurückgibt oder ein erfolgreicher Aufruf ist (d. h. ein Aufruf, der CKR_OK zurückgibt), um die Länge des Puffers zu bestimmen, der für die Aufnahme des Message-Digests erforderlich ist.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestSingleRequest {
        Mechanism Mech = 1;
        bytes Data = 2;
    }
    message DigestSingleResponse {
        bytes Digest = 3;
    }
    

Vom Standard abweichende Erweiterung, Kombination von DigestInit und Digest. Verarbeitet Daten in einem Durchgang, mit einem einzigen Aufruf, ohne einen temporären Digest-Status und unnötige Umläufe aufzubauen.

Das ist die bevorzugte Methode für Digest-Operationen mit Klartext für XCP-sensitive Anwendungen. Funktional ist DigestSingle äquivalent zu DigestInit mit sofort anschließendem Digest.

Wenn ein Schlüssel verarbeitet werden muss, müssen DigestInit und DigestKey verwendet werden, da diese Funktion keine Schlüssel-BLOBs verarbeitet.

Gibt keinen Status an den Host zurück, nur das Ergebnis der Digest-Operation. Es gibt keine anderen Parameter als PKCS #11-Parameter, da alles direkt aus dem PKCS #11-Aufruf verwendet wird.

    CK_RV m_DigestSingle (
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        Ziel 'target_t'
    );