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,
      destino target_t
    );
    

C_GetMechanismList se utiliza para obtener una lista de los tipos de mecanismo admitidos por una señal. SlotID es el ID de la ranura de señal; pulCount apunta a la ubicación que recibe el número de mecanismos.

Hay dos formas disponibles para que una aplicación llame a C_GetMechanismList:

1. Si pMechanismList es NULL_PTR, entonces todo lo que hace C_GetMechanismList es devolver (en *pulCount) el número de mecanismos, sin devolver una lista de mecanismos. El contenido de *pulCount en la entrada a C_GetMechanismList no tiene ningún significado en este caso y la llamada devuelve el valor CKR_OK.
2. Si pMechanismList no es NULL_PTR, *pulCount debe contener el tamaño (en términos de elementos CK_MECHANISM_TYPE) del almacenamiento intermedio al que apunta pMechanismList. Si ese almacenamiento intermedio es suficientemente grande para contener la lista de mecanismos, entonces, se devolverá la lista al almacenamiento y se devolverá CKR_OK. Si no es así, la llamada a C_GetMechanismList devolverá el valor CKR_BUFFER_TOO_SMALL. En cualquier caso, el valor *pulCount se establece para contener el número de mecanismos.

Dado que C_GetMechanismList no asigna ningún espacio propio, una aplicación suele invocar C_GetMechanismList dos veces. Sin embargo, este comportamiento no es necesario en absoluto.

    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,
      destino target_t
    );
    

C_GetMecanismoInfo obtiene información sobre un mecanismo determinado que puede ser soportado por una señal. slotID es el ID de la ranura de la señal; type es el tipo de mecanismo; pInfo apunta a la ubicación que recibe la información del mecanismo.

    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;
    }
    

Implementación de C_GenerateKey de PKCS #11.

Las claves TDES se generan con una paridad adecuada, que no puede observar el host. Pero es necesaria para una interoperatividad adecuada: otras implementaciones de PKCS #11 se necesitan para rechazar las claves DES con problemas de paridad.

Si un objeto está vinculado a una sesión, (pin, plen) debe regresar a esta sesión mediante Login. Si se deja pin, NULL crea un objeto pública, uno que no está enlazado a ninguna sesión de inicio de sesión.

(key, klen) devuelve el blob de la clave. (csum, clen) contiene la suma de comprobación de la clave, es decir, los bytes más significativos de un bloque de todo ceros cifrado por la clave. El valor NULL clen es posible, por ejemplo para mecanismo de clave simétrica sin parámetros CKA_CHECK_VALUE (como, por ejemplo, RC4).

ptempl se utiliza solamente si el mecanismo necesita la longitud de la clave (es decir, el atributo CKA_VALUE_LEN). Si el mecanismo especifica implícitamente el tamaño de clave, no se comprobará el tamaño de ptempl.

La generación de parámetros DSA y DH hace caso omiso de (csum, clen), generando solamente estructuras de parámetro.

Parámetros DSA, DH (CKM_DSA_PARAMETER_GEN): pasar el recuento de bits del módulo en CKA_PRIME_BITS de los atributos. Escribe la estructura P,Q,G como salida de texto simple (es decir, no un blob).

El blob pin era una salida de: Login.

PKCS #11 phKey no se correlaciona con ningún parámetro de EP11. (La biblioteca de host debe vincular la clave envuelta para la tarea de manejo.)

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

C_GenerateKey genera una clave secreta o un conjunto de parámetros de dominio, creando un objeto nuevo. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de generación; pTemplate apunta a la plantilla para la nueva clave o conjunto de parámetros de dominio; ulCount es el número de atributos de la plantilla; phKey apunta a la ubicación que recibe el descriptor de contexto de la nueva clave o conjunto de parámetros de dominio.

Si el mecanismo de generación es para la generación de parámetros de dominio, el atributo CKA_CLASS tiene el valor CKO_DOMAIN_PARAMETERS; de lo contrario, tiene el valor CKO_SECRET_KEY.

Puesto que el tipo de parámetros de clave o dominio que se han de generar está implícito en el mecanismo de generación, no es necesario que la plantilla proporcione ningún tipo de clave. Si proporciona un tipo de clave que es incoherente con el mecanismo de generación, C_GenerateKey falla y devuelve el código de error CKR_TEMPLATE_INCONSISTENT. El atributo CKA_CLASS se trata de la misma manera.

Si una llamada a C_GenerateKey no puede dar soporte a la plantilla exacta que se le ha suministrado, falla y regresa sin crear un objeto.

El objeto creado por una llamada a C_GenerateKey correcta tiene establecido el atributo CKA_LOCAL en CK_TRUE.

    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;
    }
    

Implementación de C_GenerateKeyPair de PKCS #11.

Los parámetros de par de claves se recuperan de los parámetros pmech, ppublic y pprivate. Para claves RSA, ppublic especifica el tamaño del módulo.

En modalidad FIPS, sólo se da soporte a los módulos RSA de 1024+256 n bits (entero n). La modalidad no FIPS puede generar claves de cualquier número par de bits entre los límites de la lista de parámetros del mecanismo.

La clave pública está formateada como una SPKI estándar (información de clave pública), legible por la mayoría de las bibliotecas. Un MAC específico de la clave de transporte protege la integridad. Dicho MAC no forma parte del propio SPKI. La generación de parámetros DSA devuelve una estructura no SPKI en el campo de clave pública.

Si vincula un objeto a una sesión, (pin, plen) se debe devolver mediante Login para esta sesión. Si se deja pin NULL se crea un objeto público, uno que sobrevive a la sesión de inicio de sesión.

Devuelve una clave privada envuelta en (key, klen), una clave pública como una estructura ASN.1/DER con cálculo de MAC en (pubkey, pklen).

Las siguientes combinaciones de parámetros soportadas con notas especiales van más allá de lo documentado por PKCS #11:

Las claves RSA rechazan los exponentes públicos por debajo de 17 (0x11). Los puntos de control pueden restringir más adelante el mínimo aceptado. El exponente Fermat4, 0x10001, se controla mediante un punto de control específico, que coincide con las restricciones de exponente público de FIPS 186-3 (sección B.3.1).

Las claves de EC (CKM_EC_KEY_PAIR_GEN): los parámetros de curva se pueden especificar como OID o nombres simbólicos (nuestra variante de namedCurve). Los nombres simbólicos soportados son "P-nnn" para las curvas NIST (nnn es un recuento de bits primarios soportado, 192 - 521), "BP-nnnR" para la curva BP normal. (Se deben suministrar nombres como series ASCII, sin terminación de cero.)

Claves DSA (CKM_DSA_KEY_PAIR_GEN): pasan la estructura P,Q,G como atributo CKA_IBM_STRUCT_PARAMS de atributos públicos. Es posible que los parámetros P,Q,G individuales no se pasen a través de los parámetros habituales de PKCS #11; se deben combinar con una única estructura.

Claves DH (CKM_DH_PKCS_KEY_PAIR_GEN): pasan la estructura P,G como atributo CKA_IBM_STRUCT_PARAMS de atributos públicos. Es posible que los parámetros P,G individuales no se pasen a través de los parámetros habituales de PKCS #11; se deben combinar con una única estructura. Cuando seleccione un recuento de bits de clave privada (X), utilice el atributo XCP_U32_VALUE_BITS. Si no está presente, o si se suministra un 0 explícito, se selecciona un recuento de bits basado en el recuento de bits P.

El uso del estado de sesión (Inicio de sesión) sustituye al uso estándar de las sesiones. La correlación está fuera del ámbito de la biblioteca.

El blob pin era una salida de: Login.

PKCS #11 hSession no se correlaciona con ningún parámetro de EP11. (La llamada no está asociada directamente a ninguna sesión.)

PKCS #11 phPublicKey no se correlaciona con ningún parámetro de EP11. (La biblioteca de host debe asociar el valor de pubkey (SPKI) con el controlador.)

PKCS #11 phPrivateKey no se correlaciona con ningún parámetro de EP11. (La biblioteca debe asociar la clave privada con el controlador.)

    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,
      unsigned char *privKey, size_t *privKeylen,
      unsigned char *pubKey, size_t *pubKeylen,
      destino target_t
      );
    

C_GenerateKeyPair genera un par de claves públicas y privadas, creando nuevos objetos de clave. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de generación de claves; pPublicKeyTemplate apunta a la plantilla para la clave pública; ulPublicKeyAttributeCount es el número de atributos de la plantilla de clave pública; pPrivateKeyTemplate apunta a la plantilla para la clave privada; ulPrivateKeyAttributeCount es el número de atributos de la plantilla de clave privada; phPublicKey apunta a la ubicación que recibe el manejador de la nueva clave pública; phPrivateKey apunta a la ubicación que recibe el manejador de la nueva clave privada.

Puesto que los tipos de claves que se van a generar están implícitos en el mecanismo de generación de pares de claves, las plantillas no necesitan proporcionar tipos de clave. Si una de las plantillas proporciona un tipo de clave que es incoherente con el mecanismo de generación de claves, C_GenerateKeyPair falla y devuelve el código de error CKR_TEMPLATE_INCONSISTENT. El atributo CKA_CLASS se trata de forma similar.

Si una llamada a C_GenerateKey no puede dar soporte a las plantillas exactas que se le han suministrado, falla y regresa sin crear objetos de clave.

Una llamada a C_GenerateKeyPair nunca crea una única clave y regresa. Una llamada puede fallar y no crear claves; o puede ejecutarse correctamente y crear un par de claves pública y privada coincidentes.

Los objetos de clave creados por una llamada satisfactoria a C_GenerateKeyPair tienen los atributos CKA_LOCAL establecidos en CK_TRUE.

Anote minuciosamente el orden de los argumentos en C_GenerateKeyPair. Como mínimo hay dos argumentos que no tienen el mismo orden que tenían en el documento original Cryptoki de la versión 1.0. El orden de estos dos argumentos ha causado cierta confusión desafortunada.

    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;
    }
    

Implementación de C_DeriveKey de PKCS #11.

El blob basekey,bklen debe estar correlacionado desde el parámetro PKCS #11 hBaseKey.

PKCS #11 hSession no se correlaciona con ningún parámetro de EP11. (La llamada no está asociada directamente a ninguna sesión.)

PKCS #11 phKey no se correlaciona con ningún parámetro de EP11. (La biblioteca de host debe vincular la clave devuelta con el controlador.)

    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,
        unsigned char *checkSum, size_t *checkSumlen,
        destino target_t
    );
    

C_DeriveKey deriva una clave de una clave base, creando un nuevo objeto de clave. hSession es el manejador de la sesión; pMechanism apunta a una estructura que especifica el mecanismo de derivación de claves; hBaseKey es el manejador de la clave base; pTemplate apunta a la plantilla para la nueva clave; ulAttributeCount es el número de atributos de la plantilla; y phKey apunta a la ubicación que recibe el manejador de la clave derivada.

Los valores de los atributos CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE y KA_NEVER_EXTRACTABLE para la clave base afectan a los valores que pueden contener estos atributos para la clave recién derivada. Consulte la descripción de cada mecanismo de derivación de claves particular en la sección 5.16.2 de la especificación de API PKCS #11 para cualquier restricción de este tipo.

Si una llamada a C_GenerateKey no puede dar soporte a la plantilla exacta que se le ha suministrado, falla y regresa sin crear un objeto.

El objeto creado por una llamada a C_GenerateKey correcta tiene establecido el atributo CKA_LOCAL en CK_TRUE.

    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,
        destino target_t
    );
    

C_WrapKey envuelve (es decir, cifra) una clave privada o secreta. hSession es el descriptor de contexto de la sesión; pMechanism apunta al mecanismo de ajuste; hWrappingKey es el manejador de la clave de encapsulado; hKey es el manejador de la clave que se va a envolver; pWrappedKey apunta a la ubicación que recibe la clave envuelta; y pulwrappedKeyLen apunta a la ubicación que recibe la longitud de la clave envuelta.

C_WrapKey utiliza el convenio que se describe en la sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

El atributo CKA_WRAP de la clave de envolvimiento, que indica si la clave admite el envolvimiento, debe ser CK_TRUE. El atributo CKA_EXTRACTABLE de la clave que se debe envolver también debe ser CK_TRUE.

Si la clave que se ha de envolver no se puede envolver por algún motivo específico de la señal, a pesar de que tenga el atributo CKA_EXTRACTABLE establecido en CK_TRUE, entonces C_WrapKey falla con el código de error CKR_KEY_NOT_WRAPPABLE. Si no se puede envolver únicamente con la clave de envolvimiento especificada y el mecanismo debido a su longitud, entonces C_WrapKey falla con el código de error CKR_KEY_SIZE_RANGE.

C_WrapKey se puede utilizar en las situaciones siguientes:

• Para envolver cualquier clave secreta con una clave pública que admita el cifrado y el descifrado.
• Para envolver cualquier clave secreta con cualquier otra clave secreta. Se debe tener en cuenta el tamaño de la clave y la potencia del mecanismo o puede que la señal no permita la operación.
• Para envolver una clave privada con cualquier clave secreta.

Las señales varían en función de los tipos de claves se pueden envolver con qué mecanismos.

Para particionar las claves de encapsulado de modo que sólo puedan envolver un subconjunto de claves extraíbles, el atributo CKA_WRAP_TEMPLATE se puede utilizar en la clave de encapsulado para especificar un conjunto de atributos que se puede comparar con los atributos de la clave que se va a envolver. Si todos los atributos coinciden según las reglas de C_FindObject de coincidencia de atributos, la operación de envolver continúa. El valor de este atributo es una plantilla de atributo y el tamaño es el número de elementos de la plantilla que tiene el tamaño de CK_ATTRIBUTE. Si no se proporciona este atributo, no se aceptará ninguna plantilla. Si un atributo no está presente, no se comprueba. Si se produce una discrepancia de los atributos en un intento de envolver una clave, la función devuelve CKR_KEY_HANDLE_INVALID.

    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;
    }
    

Implementación de C_UnwrapKey de PKCS #11.

uwmech especifica el mecanismo de cifrado que se utiliza para descifrar datos envueltos. ptempl es una lista de parámetros de clave(par), que especifica cómo transformar los datos desenvueltos en una nueva clave (debe incluir CKA_KEY_TYPE).

El objeto generado se devuelve en (unwrapped, uwlen) como blob. Las claves simétricas devuelven la suma de comprobación de claves (3 bytes) en (csum, cslen); los objetos de clave pública devuelven la clave pública como SPKI en (csum, cslen). Ambas formas van seguidas de un valor big-endian de 4 bytes, que codifica el recuento de bits de la clave desenvuelta.

Cuando un SPKI se está transformando en una SPKI MACed, se debe utilizar CKM_IBM_TRANSPORTKEY como mecanismo para desenvolver. Esta modalidad proporciona el SPKI sin formato, como datos envueltos, y hace caso omiso de KEK.

UnwrapKey Genera claves DES ajustadas por paridad (en los blobs), pero tolera la entrada con paridad incorrecta.

    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,
        destino target_t
    );
    

C_UnwrapKey desenvuelve (es decir, descifra) una clave envuelta, creando una nueva clave privada o un objeto de clave secreta. hSession es el descriptor de contexto de la sesión; pMechanism apunta al mecanismo de desenvolver; hUnwrappingKey es el manejador de la clave para desenvolver; pWrappedKey apunta a la clave envuelta; ulWrappedKeyLen es la longitud de la clave envuelta; pTemplate apunta a la plantilla para la nueva clave; ulAttributeCount es el número de atributos de la plantilla; phKey apunta a la ubicación que recibe el manejador de la clave recuperada.

El atributo CKA_UNWRAP de la clave de desenvolvimiento, que indica si la clave admite el desenvolvimiento, debe ser CK_TRUE.

La nueva clave tiene el atributo CKA_ALWAYS_SENSITIVE establecido en CK_FALSE, y el atributo CKA_NEVER_EXTRACTABLE establecido en CK_FALSE. El atributo CKA_EXTRACTABLE se establece de forma predeterminada en CK_TRUE.

Algunos mecanismos pueden modificar o intentar modificar. El contenido de la estructura pMechanism al mismo tiempo que se desenvuelve la clave.

Si una llamada a C_GenerateKey no puede dar soporte a la plantilla exacta que se le ha suministrado, falla y regresa sin crear ningún objeto de clave.

El objeto de clave creado mediante una llamada a C_UnwrapKey correcta tiene establecido el atributo CKA_LOCAL en CK_FALSE.

Para particionar las claves de desenvolver para que sólo puedan desenvolver un subconjunto de claves, el atributo CKA_UNWRAP_TEMPLATE se puede utilizar en la clave de desenvolver para especificar un conjunto de atributos que se añade a los atributos de la clave que se va a desenvolver. Si los atributos no entran en conflicto con la plantilla de atributos proporcionada por el usuario, en pTemplate, la operación de desenvolver continúa. El valor de este atributo es una plantilla de atributo y el tamaño es el número de elementos de la plantilla que tiene el tamaño de CK_ATTRIBUTE. Si este atributo no está presente en la clave de desenvolvimiento, no se añaden atributos adicionales. Si se produce algún conflicto de atributos en un intento de desenvolver una clave, la función DEVOLVERÁ CKR_TEMPLATE_INCONSISTENT.

    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;
    }
    

Implementación de C_GetAttributeValue de PKCS #11.

No representa ni necesita sesiones (parte de blob); por lo tanto, no utiliza el parámetro hSession.

EP11 utiliza más formas directas para decodificar como, por ejemplo, la enumeración de los valores reales en lugar de ser más genérico.

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

C_GetAttributeValue obtiene el valor de uno o más atributos de un objeto. hSession es el manejador de la sesión; hObject es el manejador del objeto; pTemplate apunta a una plantilla que especifica qué valores de atributo se van a obtener y recibe los valores de atributo; ulCount es el número de atributos de la plantilla.

Para cada triplete en la plantilla (type, pValue, ulValueLen), C_GetAttributeValue realiza el algoritmo siguiente:

1. Si el atributo especificado (es decir, el atributo especificado por el campo Tipo) para el objeto no se puede revelar porque el objeto es confidencial o no extraíble, entonces, se modifica el campo ulValueLen, en ese triplete, para que contenga el valor CK_UNAVAILABLE_INFORMATION.
2. De lo contrario, si el valor especificado para el objeto no es válido (el objeto no posee dicho atributo), entonces, se modifica el campo ulValueLen en ese triplete para que contenga el valor CK_UNAVAILABLE_INFORMATION.
3. De lo contrario, si el campo pValue tiene el valor NULL_PTR, entonces, se modifica el campo ulValueLen para que contenga la longitud exacta del atributo especificado para el objeto.
4. De lo contrario, si la longitud especificada en ulValueLen es lo suficientemente grande para contener el valor del atributo especificado para el objeto, se copia este atributo en el almacenamiento intermedio que está en pValue, y se modifica el campo ulValueLen para que contenga la longitud exacta del atributo.
5. De lo contrario, se modifica el campo ulValueLen para que contenga el valor CK_UNAVAILABLE_INFORMATION.

Si se aplica el caso 1 a cualquiera de los atributos solicitados, la llamada debe devolver el valor CKR_ATTRIBUTE_SENSITIVE. Si se aplica el caso 2 a cualquiera de los atributos solicitados, la llamada debe devolver el valor CKR_ATTRIBUTE_TYPE_INVALID. Si se aplica el caso 5 a cualquiera de los atributos solicitados, la llamada debe devolver el valor CKR_BUFFER_TOO_SMALL. Como de costumbre, si se aplica más de uno de estos códigos de error, puede que Cryptoki devuelva alguno de ellos. Únicamente si ninguno de estos se aplica a ninguno de los atributos solicitados, se devuelve CKR_OK.

En el caso especial de un atributo cuyo valor es una matriz de atributos, por ejemplo CKA_WRAP_TEMPLATE, donde se pasa con pValue no NULL, si el pValue de elementos dentro de la matriz es NULL_PTR, el ulValueLen de elementos dentro de la matriz se establece en la longitud necesaria. Si el valor pValue de los elementos en la matriz no es NULL_PTR, entonces, el elemento ulValueLen de atributos en la matriz deberá reflejar el espacio al que apunta el correspondiente pValue y pValue se completará si hay espacio suficiente. Por lo tanto, es importante inicializar el contenido de un almacenamiento intermedio antes de que se llame a C_GetAttributeValue para obtener dicho valor de matriz. Si cualquier ulValueLen incluido en la matriz no es lo suficientemente grande, se establece en CK_UNAVAILABLE_INFORMATION y la función devuelve CKR_BUFFER_TOO_SMALL, del mismo modo que lo hace si un atributo del argumento pTemplate tiene un valor de ulValueLen demasiado pequeño. Cualquier atributo cuyo valor sea una matriz de atributos se puede identificar mediante el conjunto CKF_ARRAY_ATTRIBUTE del tipo de atributo.

Los códigos de error CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALID y CKR_BUFFER_TOO_SMALL no indican errores verdaderos para C_GetAttributeValue. Si una llamada a C_GetAttributeValue devuelve cualquiera de estos tres valores, de todos modos, la llamada debe haber procesado cada uno de los atributos de la plantilla que se han suministrado a C_GetAttributeValue. Cada uno de los atributos de la plantilla cuyo valor se puede devolver mediante la llamada a C_GetAttributeValue se devuelve mediante la llamada a C_GetAttributeValue.

    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;
    }
    

Implementación de C_SetAttributeValue de PKCS #11.

Empaquetado de atributos: consulte _GetAttrValue

Actualmente, Ep11 envía solamente atributos booleanos, todos los demás atributos los gestiona el host (y EP11 no modifica las matrices como, por ejemplo, WRAP_TEMPLATE).

No representa ni necesita sesiones (parte de blob); por lo tanto, no utiliza el parámetro hSession de PKCS #11.

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

C_SetAttributeValue modifica el valor de uno o más atributos de un objeto. hSession es el manejador de la sesión; hObject es el manejador del objeto; pTemplate apunta a una plantilla que especifica qué valores de atributo se van a modificar y sus nuevos valores; ulCount es el número de atributos de la plantilla.

Es posible que algunos objetos no se puedan modificar. Cuando se invoca C_SetAttributeValue en estos objetos se genera el código de error CKR_ACTION_PROHIBITED. Una aplicación puede consultar el atributo CKA_MODIFIABLE del objeto para determinar si un objeto se puede modificar.

Solamente se pueden modificar los objetos de sesión durante una sesión de solo lectura.

La plantilla puede especificar valores nuevos para los atributos del objeto que se pueden modificar. Si la plantilla especifica un valor de un atributo que es incompatible con otros atributos existentes del objeto, la llamada falla con el código de retorno CKR_TEMPLATE_INCONSISTENT.

No todos los atributos se pueden modificar; consulte la Sección 4.1.2 de la especificación de API PKCS #11 para obtener más información.

    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;
    }
    

Implementación de C_GenerateRandom de PKCS #11.

GenerateRandom equivale a la función original de PKCS #11. Internamente, la entropía con semillas generadas por hardware se pasa a través de DRNG compatible con FIPS (ANSI X9.31/ISO 18031, dependiendo de la versión de Clic).

La biblioteca del host podría generar números aleatorios sin asignarlos al programa de fondo, si la funcionalidad adecuada estuviera disponible en el host. Esto no ocurre en la implementación actual.

Esta función no da soporte a la consulta de tamaño.

    CK_RV m_GenerateRandom (
        CK_BYTE_PTR rnd, CK_ULONG rndlen,
        destino 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;
    }
    

Implementación de C_EncryptInit de PKCS #11.

El blob (key, klen) puede ser un objeto de clave pública o un blob de clave secreta. El tipo de clave debe ser coherente con pmech.

Para los mecanismos de clave pública, (key, klen) debe contener un SPKI. Este SPKI protege la integridad con una clave MAC, tal como lo devuelve GenerateKeyPair o, de forma alternativa, UnwrapKey. El estado de cifrado se crea sin restricciones de sesión.

Para los mecanismos de clave secreta, el estado de cifrado hereda las restricciones de sesión de objeto de (key, klen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

(key, klen) debe ser un blob de clave.

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

C_EncryptInit inicializa una operación de cifrado. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de cifrado; hKey es el manejador de la clave de cifrado.

El atributo CKA_ENCRYPT de la clave de cifrado, que indica si la clave admite el cifrado, debe ser CK_TRUE.

Después de llamar a C_EncryptInit, la aplicación puede llamar a C_EncryptUpdate cero o más veces, seguido de C_EncryptFinal, para cifrar datos en varias partes. La operación de cifrado está activa hasta que la aplicación utilice una llamada a C_Encrypt o C_EncryptFinal para obtener la parte final del texto cifrado. Para procesar datos adicionales (en una única parte o en varias partes), la aplicación debe volver a invocar C_EncryptInit.

    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;
    }
    

Implementación de C_Encrypt de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: EncryptInit.

    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,
        destino target_t
    );
    

C_Encrypt cifra datos de una sola pieza. hSession es el manejador de la sesión; pData apunta a los datos; ulDataLen es la longitud en bytes de los datos; pEncryptedData apunta a la ubicación que recibe los datos cifrados; pulEncryptedDataLen apunta a la ubicación que contiene la longitud en bytes de los datos cifrados.

C_Encrypt utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de cifrado debe inicializarse con C_EncryptInit. Una llamada a C_Encrypt siempre termina la operación de cifrado activa a menos que devuelva CKR_BUFFER_TOO_SMALL o sea una llamada satisfactoria (es decir, una que devuelva CKR_OK) para determinar la longitud del almacenamiento intermedio que es necesario para contener el texto cifrado.

C_Encrypt no se puede utilizar para finalizar una operación de varias partes y se debe invocar después de C_EncryptInit sin que intervenga ninguna llamada C_EncryptUpdate.

Para algunos mecanismos de cifrado, los datos de texto sin formato de entrada tienen ciertas restricciones de longitud (ya sea porque el mecanismo sólo puede cifrar partes relativamente cortas de texto sin formato, o porque los datos de entrada del mecanismo deben constar de un número integral de bloques). Si no se cumplen estas restricciones, C_Encrypt falla con el código de retorno CKR_DATA_LEN_RANGE.

El texto sin formato y el texto cifrado pueden estar en el mismo lugar, es decir, es correcto si pData y pEncryptedData apuntan a la misma ubicación.

Para la mayoría de los mecanismos, C_Encrypt equivale a una secuencia de operaciones C_EncryptUpdate seguida de 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;
    }
    

Implementación de C_EncryptUpdate de PKCS #11.

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: EncryptInit.

    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,
        destino target_t
    );
    

C_EncryptUpdate continúa una operación de cifrado de varias partes, procesando otra parte de datos. hSession es el manejador de la sesión; pPart apunta a la parte de datos; ulpartLen es la longitud de la parte de datos; pEncryptedPart apunta a la ubicación que recibe la parte de datos cifrada; pulEncryptedPartLen apunta a la ubicación que contiene la longitud en bytes de la parte de datos cifrados.

C_EncryptUpdate utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de cifrado debe inicializarse con C_EncryptInit. Se puede llamar a esta función las veces que se quiera seguidas. Una llamada a C_EncryptUpdate que genera un error distinto de CKR_BUFFER_TOO_SMALL finaliza la operación de cifrado actual.

texto sin formato y ciphertext pueden estar en el mismo lugar, es decir, estaría bien si pPart y pEncryptedPart apuntaran a la misma ubicación.

    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;
    }
    

Implementación de C_EncryptFinal de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: EncryptInit, EncryptUpdate.

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

C_EncryptFinal finaliza una operación de cifrado de varias partes. hSession es el manejador de la sesión; pLastEncryptedPart apunta a la ubicación que recibe la última parte de datos cifrados, si la hay; pulLastEncryptedPartLen apunta a la ubicación que contiene la longitud de la última parte de datos cifrados.

C_EncryptFinal utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de cifrado debe inicializarse con C_EncryptInit. Una llamada a C_EncryptFinal siempre finaliza la operación de cifrado activa, a menos que devuelva CKR_BUFFER_TOO_SMALL, o que sea una llamada satisfactoria (es decir, una que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio necesario para contener el texto cifrado.

Para algunos mecanismos de cifrado de varias partes, los datos de texto sin formato de entrada tienen ciertas restricciones de longitud porque los datos de entrada del mecanismo deben constar de un número integral de bloques. Si no se cumplen estas restricciones, C_EncryptFinal falla con el código de retorno CKR_DATA_LEN_RANGE.

    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;
    }
    

Variante no estándar de Encrypt. Procesa los datos de un paso con una llamada. No devuelve ningún estado al host, solamente datos cifrados.

Se trata del método preferido a la hora de realizar el cifrado de datos en un paso para aplicaciones compatibles con XCP. Funcionalmente, equivale a EncryptInit seguido inmediatamente de Encrypt, pero guarda los viajes de ida y vuelta así como los envolvimientos y desenvolvimientos.

Si el programa de fondo admite claves residentes, la clave también puede ser un controlador de claves residentes.

Consulte también: Encrypt, EncryptInit, DecryptSingle.

El blob key era una salida de: GenerateKey, UnwrapKey.

    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,
        destino target_t
    );
    

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

Variante no estándar de Encrypt. Procesa los datos de un paso con una llamada. No devuelve ningún estado al host, solo los datos que se han vuelto a cifrar.

Descifra los datos con la clave original y, a continuación, cifra los datos sin formato con una clave diferente dentro del HSM de nube.

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey, size_t idkeylen,
        const unsigned 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,
        destino 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,
        destino target_t
    );
    

C_DecryptInit inicializa una operación de descifrado. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de descifrado; hKey es el manejador de la clave de descifrado.

El atributo CKA_DECRYPT de la clave de descifrado, que indica si la clave admite el descifrado, debe ser CK_TRUE.

Después de que la aplicación llame a C_DecryptInit, la aplicación puede llamar a C_Decrypt para descifrar datos de una sola parte; o llamar a C_DecryptUpdate cero o más veces, seguido de C_DecryptFinal, para descifrar datos en varias partes. La operación de descifrado está activa hasta que la aplicación utilice una llamada a C_Decrypt o C_DecryptFinal para obtener la parte final del texto sin formato. Para procesar datos adicionales (en una única parte o en varias partes), la aplicación debe volver a llamar a C_DecryptInit.

    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;
    }
    

Implementación de PKCS #11 C_Decrypt. No actualiza (estado, slen).

El objeto binario grande (BLOB) state, slen debe correlacionarse con el parámetro hSession de PKCS #11. El BLOB state era una salida de DecryptInit.

    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,
        destino target_t
    );
    

C_Decrypt descifra datos cifrados en una sola parte.

• hSession es el controlador de sesiones.
• pEncryptedData apunta a los datos cifrados.
• ulEncryptedDataLen es la longitud de los datos cifrados.
• pData apunta a la ubicación que recibe los datos recuperados.
• pulDataLen apunta a la ubicación que conserva la longitud de los datos recuperados.

C_Decrypt utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de descifrado se debe inicializar con C_DecryptInit. Una llamada a C_Decrypt siempre termina la operación de descifrado activa a menos que devuelva CKR_BUFFER_TOO_SMALL o sea una llamada satisfactoria con CKR_OK devuelto para determinar la longitud del almacenamiento intermedio que se necesita para contener el texto sin formato.

C_Decrypt no se puede utilizar para finalizar una operación de varias partes, y se debe invocar después de C_DecryptInit sin intervenir en las llamadas C_DecryptUpdate.

El texto cifrado y el texto sin formato pueden estar en el mismo lugar, lo que significa que es aceptable si pEncryptedData y pData apuntan a la misma ubicación.

Si los datos de texto cifrado de entrada no se pueden descifrar debido a que tienen una longitud inadecuada, es posible que se devuelva CKR_ENCRYPTED_DATA_INVALID o CKR_ENCRYPTED_DATA_LEN_RANGE.

    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;
    }
    

Implementación de C_DecryptUpdate de PKCS #11.

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: DecryptInit.

    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,
        destino target_t
    );
    

C_DecryptUpdate continúa una operación de descifrado de varias partes, procesando otra parte de datos cifrados. hSession es el manejador de la sesión; pEncryptedPart apunta a la parte de datos cifrados; ulEncryptedPartLen es la longitud del componente de datos cifrados; pPart apunta a la ubicación que recibe la parte de datos recuperada; pulPartLen apunta a la ubicación que contiene la longitud de la parte de datos recuperada.

C_DecryptUpdate utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de descifrado se debe inicializar con C_DecryptInit. Se puede llamar a esta función las veces que se quiera seguidas. Una llamada a C_DecryptUpdate que genera un error distinto de CKR_BUFFER_TOO_SMALL finaliza la operación de descifrado actual.

El texto cifrado y el texto sin formato pueden estar en el mismo lugar, es decir, es correcto si pEncryptedPart y pPart apuntan a la misma ubicación.

    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;
    }
    

Implementación de C_DecryptFinal de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: DecryptInit, DecryptUpdate.

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

C_DecryptFinal finaliza una operación de descifrado de varias partes. hSession es el manejador de la sesión; pLastPart apunta a la ubicación que recibe la última parte de datos recuperada, si la hay; pulLastPartLen apunta a la ubicación que contiene la longitud de la última parte de datos recuperados.

C_DecryptFinal utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de descifrado se debe inicializar con C_DecryptInit. Una llamada a C_DecryptFinal siempre termina la operación de descifrado activa a menos que devuelva CKR_BUFFER_TOO_SMALL o sea una llamada satisfactoria (es decir, una llamada que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio que se necesita para contener el texto sin formato.

Si los datos de texto cifrado de entrada no se pueden descifrar debido a que tienen una longitud inadecuada, es posible que se devuelva CKR_ENCRYPTED_DATA_INVALID o CKR_ENCRYPTED_DATA_LEN_RANGE.

    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;
    }
    

Variante no estándar de Decrypt. Procesa los datos de un paso con una llamada. No devuelve ningún estado al host, solamente datos descifrados.

Se trata del método preferido a la hora de realizar el cifrado de datos en un paso para aplicaciones compatibles con XCP. Funcionalmente, equivale a DecryptInit seguido inmediatamente de Decrypt, pero guarda los viajes de ida y vuelta así como los envolvimientos y desenvolvimientos.

Si el programa de fondo admite claves residentes, la clave también puede ser un controlador de claves residentes.

Consulte también: Decrypt, DecryptInit, EncryptSingle.

El blob key era una salida de: GenerateKey, UnwrapKey.

    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,
        destino 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,
        destino target_t
    );
    

C_SignInit inicializa una operación de firma, donde la firma es un apéndice de los datos. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de firma; hKey es el manejador de la clave de firma.

El atributo CKA_SIGN de la clave de firma, que indica si la clave admite firmas con apéndice, debe ser CK_TRUE.

Después de llamar a C_SignInit, la aplicación puede llamar a C_Sign para firmar una sola parte; o llamar a C_SignUpdate una o más veces, seguido de C_SignFinal, para firmar datos de varias partes. La operación de firma está activa hasta que la aplicación utiliza una llamada a C_Sign o C_SignFinal para obtener la firma. Para procesar datos adicionales (en una única parte o en varias), la aplicación debe volver a invocar C_SignInit.

    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;
    }
    

Implementación de C_Sign de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: SignInit.

    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,
        destino target_t
    );
    

C_Sign firma datos en una sola pieza, donde la firma es un apéndice de los datos. hSession es el manejador de la sesión; pData apunta a los datos; ulDataLen es la longitud de los datos; pSignature apunta a la ubicación que recibe la firma; pulSignatureLen apunta a la ubicación que contiene la longitud de la firma.

C_Sign utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de firma se debe inicializar con C_SignInit. Una llamada a C_Sign siempre finaliza la operación de firma activa a menos que devuelva CKR_BUFFER_TOO_SMALL o que sea una llamada satisfactoria (es decir, una que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio necesario para contener la firma.

C_Sign no se puede utilizar para finalizar una operación de varias partes y se debe invocar después de C_SignInit sin que intervenga ninguna llamada C_SignUpdate.

Para la mayoría de los mecanismos, C_Sign equivale a una secuencia de operaciones C_SignUpdate seguida de 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;
    }
    

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: SignInit.

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

C_SignUpdate continúa una operación de firma de varias partes, procesando otra parte de datos. hSession es el manejador de la sesión, pPart apunta a la parte de datos; ulpartLen es la longitud de la parte de datos.

La operación de firma se debe inicializar con C_SignInit. Se puede llamar a esta función las veces que se quiera seguidas. Una llamada a C_SignUpdate que da como resultado un error finaliza la operación de firma actual.

    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;
    }
    

Implementación de C_SignFinal de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: SignInit, SignUpdate.

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

C_SignFinal finaliza una operación de firma de varias partes, devolviendo la firma. hSession es el manejador de la sesión; pSignature apunta a la ubicación que recibe la firma; pulSignatureLen apunta a la ubicación que contiene la longitud de la firma.

C_SignFinal utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de firma se debe inicializar con C_SignInit. Una llamada a C_SignFinal siempre finaliza la operación de firma activa a menos que devuelva CKR_BUFFER_TOO_SMALL o que sea una llamada satisfactoria (es decir, una que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio necesario para contener la firma.

    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;
    }
    

Combinación de extensión no estándar de SignInit y Sign. Firma o calcula el MAC de los datos de un paso con una llamada sin crear ningún estado de resumen intermedio. No devuelve ningún estado al host, solamente el resultado.

Este es el modo preferido de firmar, sin un viaje de ida y vuelta adicional, de cifrado y descifrado. Funcionalmente, SignSingle equivale a SignInit seguido inmediatamente de Sign.

El blob (key, klen) y el mecanismo pmech juntos se deben poder pasar a SignInit.

Se admiten solicitudes de datos múltiples para firmas HMAC y CMAC (subvariantes 2 y 3).

Consulte también: 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,
        destino target_t
    );
    

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

Implementación de C_VerifyInit de PKCS #11. A partir de un blob de clave (key, klen), inicialice un estado de sesión de verificación en (state, slen). El blob de clave puede ser un objeto de clave pública o bytes de clave de HMAC. El tipo de blob de clave debe ser coherente con pmech.

Para los mecanismos de clave pública, (key, klen) debe contener un SPKI. Se puede calcular el MAC de este SPKI (tal como lo ha devuelto anteriormente GenerateKeyPair) o puede ser solo SPKI (si se obtiene de una fuente externa como, por ejemplo, un certificado).

Si se inicializa una operación de HMAC, las restricciones de sesión del objeto Verify se heredan de la clave de HMAC. Puesto que los SPKI no están vinculados a sesiones, los estados de clave pública de Verify no están sujetos a la sesión.

El blob key,klen debe estar correlacionado desde el parámetro PKCS #11 hKey.

Nota: SignInit y VerifyInit son internamente igual para HMAC y otros mecanismos simétricos/MAC.

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

C_VerifyInit inicializa una operación de verificación, donde la firma es un apéndice de los datos. hSession es el manejador de la sesión; pMechanism apunta a la estructura que especifica el mecanismo de verificación; hKey es el manejador de la clave de verificación.

El atributo CKA_VERIFY de la clave de verificación, que indica si la clave admite verificación siendo la firma un apéndice a los datos, debe ser CK_TRUE.

Después de llamar a C_VerifyInit, la aplicación puede llamar a C_Verify para verificar una firma en los datos de una sola parte; o llamar a C_VerifyUpdate una o varias veces, seguido de C_VerifyFinal, para verificar una firma en datos de varias partes. La operación de verificación está activa hasta que la aplicación llama a C_Verify o C_VerifyFinal. Para procesar datos adicionales (en una única parte o en varias), la aplicación debe volver a invocar C_VerifyInit.

    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 {
    }
    

Implementación de C_Verify de PKCS #11.

No actualiza (state, slen).

El orden relativo de los datos y la firma son relativos invertidos a VerifySingle.

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: VerifyInit.

    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,
        destino target_t
    );
    

C_Verify verifica una firma en una operación de una sola parte, donde la firma es un apéndice de los datos. hSession es el manejador de la sesión; pData apunta a los datos; ulDataLen es la longitud de los datos; pSignature apunta a la firma; ulSignatureLen es la longitud de la firma.

La operación de verificación se debe inicializar con C_VerifyInit. Una llamada a C_Verify siempre finaliza la operación de verificación activa.

Una llamada satisfactoria a C_Verify debe devolver el valor CKR_OK (lo que indica que la firma proporcionada es válida) o CKR_SIGNATURE_INVALID (lo que indica que la firma proporcionada no es válida). Si la firma no es válida basándose únicamente en su longitud, es necesario que se devuelva CKR_SIGNATURE_LEN_RANGE. En cualquier caso, finaliza la operación de firma activa.

C_Verify no se puede utilizar para finalizar una operación de varias partes y se debe invocar después de C_VerifyInit sin que intervenga ninguna llamada C_VerifyUpdate.

Para la mayoría de los mecanismos, C_Verify equivale a una secuencia de operaciones C_VerifyUpdate seguida de 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;
    }
    

Implementación de C_VerifyUpdate de PKCS #11.

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: VerifyInit.

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

C_VerifyUpdate continúa una operación de verificación de varias partes, procesando otra parte de datos. hSession es el manejador de la sesión, pPart apunta a la parte de datos; ulPartLen es la longitud de la parte de datos.

La operación de verificación se debe inicializar con C_VerifyInit. Se puede llamar a esta función las veces que se quiera seguidas. Una llamada a C_VerifyUpdate que da como resultado un error termina la operación de verificación actual.

    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 {
    }
    

Implementación de C_VerifyFinal de PKCS #11.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: VerifyInit, VerifyUpdate.

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

C_VerifyFinal finaliza una operación de verificación de varias partes, comprobando la firma. hSession es el manejador de la sesión; pSignature apunta a la firma; ulSignatureLen es la longitud de la firma.

La operación de verificación se debe inicializar con C_VerifyInit. Una llamada a C_VerifyFinal siempre finaliza la operación de verificación activa.

Una llamada satisfactoria a C_VerifyFinal debe devolver el valor CKR_OK (lo que indica que la firma proporcionada es válida) o CKR_SIGNATURE_INVALID (lo que indica que la firma proporcionada no es válida). Si la firma no es válida basándose en su longitud, se debe devolver CKR_SIGNATURE_LEN_RANGE. En cualquier caso, finaliza la operación de verificación activa.

    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 {
    }
    

Combinación de extensión no estándar de VerifyInit y Verify. Firma o calcula el MAC de los datos de un paso con una llamada sin crear ningún estado de resumen intermedio. No devuelve ningún estado al host, solamente el resultado de la verificación. No hay consulta de tamaño puesto que esta función devuelve un valor booleano.

Este es el modo preferido de verificar una firma, sin un viaje de ida y vuelta adicional, de cifrado, descifrado. Funcionalmente, VerifySingle equivale a VerifyInit seguido inmediatamente de Verify.

El blob (key, klen) y el mecanismo pmech juntos se deben poder pasar a VerifyInit.

Para los mecanismos de clave pública, (key, klen) debe contener un SPKI. Se puede calcular el MAC de este SPKI (tal como lo ha devuelto GenerateKeyPair) o puede ser solo SPKI (si se obtiene de una fuente externa como, por ejemplo, un certificado).

Consulte también: 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,
        destino target_t
    );
    

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

Implementación de C_DigestInit de PKCS #11.

Crea el estado de resumen envuelto.

Nota: las consultas de tamaño reciben soporte pero el estado envuelto siempre lo devuelve el programa de fondo, al contrario que ocurre con la mayoría de las consultas de tamaño (que se devuelve un tamaño de salida, en lugar de la salida real). Los estados Digest son suficientemente pequeños para no introducir una sobrecarga de transporte significativa.

Durante las consultas de tamaño, el host solamente descarta el estado devuelto e informa del tamaño del blob (en len). Cuando se devuelve blob, se comprueba len para el tamaño devuelto.

El blob state,len debe correlacionarse con el parámetro hSession de PKCS #11. (La biblioteca de host debe vincular el blob a la sesión.)

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

C_DigestInit inicializa una operación de resumen de mensajes. hSession es el manejador de la sesión; pMechanism apunta al mecanismo de resumen.

Después de llamar a C_DigestInit, la aplicación puede llamar a C_Digest para resumir datos de una sola parte, o puede llamar a C_DigestUpdate cero o más veces, seguido de C_DigestFinal, para resumir datos de varias partes. La operación de resumen de mensajes está activa hasta que la aplicación utiliza una llamada a C_Digest o C_DigestFinal para obtener el resumen del mensaje. Para procesar datos adicionales (en una única parte o varias), la aplicación debe volver a invocar 1C_DigestInit1.

    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;
    }
    

Implementación de C_Digest de PKCS #11.

Si un objeto de resumen tiene exactamente 0 (cero) bytes que se le añaden después de crearlo, en cualquier combinación de transferencias de cero bytes, todavía puede realizar un resumen de un paso, incluso si es necesario rechazarlo mediante una implementación estricta.

No actualiza (state, slen).

Las implementaciones pueden realizar DigestUpdate, DigestFinalo Digest llama a objetos de resumen de texto simple en el código de host, omitiendo por completo los programas de fondo HSM. Esta opción puede estar visible o no para el código de host y no tiene ningún impacto sobre la seguridad de la operación (porque los objetos de deselección no realizan resúmenes de datos confidenciales).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. El blob state era una salida de: DigestInit.

    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,
        destino target_t
    );
    

C_Digest resume los datos en una sola parte. hSession es el manejador de la sesión, pData apunta a los datos; ulDataLen es la longitud de los datos; pDigest apunta a la ubicación que recibe el resumen del mensaje; pulDigestLen apunta a la ubicación que contiene la longitud del resumen del mensaje.

C_Digest utiliza el convenio que se describe en la sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de resumen se debe inicializar con C_DigestInit. Una llamada a C_Digest siempre finaliza la operación de resumen activa a menos que devuelva CKR_BUFFER_TOO_SMALL o que sea una llamada satisfactoria (es decir, una que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio necesario para contener el resumen de mensajes.

C_Digest no se puede utilizar para finalizar una operación de varias partes y se debe invocar después de C_DigestInit sin que intervenga ninguna llamada C_DigestUpdate.

Los datos de entrada y la salida de resumen pueden estar en el mismo lugar, es decir, estaría bien si pData y pDigest apuntaran a la misma ubicación.

C_Digest equivale a una secuencia de operaciones de C_DigestUpdate seguido de 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;
    }
    

Implementación de C_DigestUpdate de PKCS #11.

DigestUpdate es polimórfico, aceptando ambos objetos de resumen envueltos o borrados, actualizando el estado en el mismo formato.

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession. (La biblioteca de host debe correlacionar la sesión con el estado almacenado.)

El blob state era una salida de: DigestInit, DigestUpdate, DigestKey.

Consulte también: DigestInit

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

C_DigestUpdate continúa una operación de resumen de mensajes de varias partes, procesando otra parte de datos. hSession es el manejador de la sesión, pPart apunta a la parte de datos; ulPartLen es la longitud de la parte de datos.

La operación de resumen de mensajes se debe inicializar con C_DigestInit. Las llamadas a esta función y a C_DigestKey se pueden intercalar tantas veces como se quiera y en cualquier orden. Una llamada a C_DigestUpdate que da como resultado un error termina la operación de resumen actual.

    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;
    }
    

Implementación de C_DigestFinal de PKCS #11.

DigestFinal es polimórfico, acepta tanto objetos de resumen envueltos como limpios.

No actualiza (state, slen).

El blob state,slen debe estar correlacionado desde el parámetro PKCS #11 hSession.

El blob state era una salida de: DigestInit, DigestUpdate, DigestKey.

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

C_DigestFinal finaliza una operación de resumen de mensajes de varias partes, devolviendo el resumen del mensaje. hSession es el manejador de la sesión; pDigest apunta a la ubicación que recibe el resumen del mensaje; pulDigestLen apunta a la ubicación que contiene la longitud del resumen del mensaje.

C_DigestFinal utiliza el convenio que se describe en la Sección 5.2 de la especificación de API PKCS #11 en la producción de la salida.

La operación de resumen se debe inicializar con C_DigestInit. Una llamada a C_DigestFinal siempre finaliza la operación de resumen activa a menos que devuelva CKR_BUFFER_TOO_SMALL o que sea una llamada satisfactoria (es decir, una que devuelve CKR_OK) para determinar la longitud del almacenamiento intermedio necesario para contener el resumen del mensaje.

    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;
    }
    

Combinación de extensión no estándar de DigestInit y Digest. Resumen datos en un paso, con una llamada, sin crear ningún estado de resumen intermedio ni viajes de ida y vuelta innecesarios.

Se trata del método preferido a la hora de realizar un resumen de texto simple para aplicaciones compatibles con XCP. Funcionalmente, DigestSingle equivale a DigestInit seguido inmediatamente de Digest.

Si se tiene que resumir un clave, se debe utilizar DigestInit y DigestKey, porque esta función no gestiona los blobs de claves.

No devuelve ningún estado al host, solamente el resultado del resumen. No hay parámetros que no sean de PKCS #11 porque todo se utiliza directamente a partir de la llamada de PKCS #11.

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