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

    CK_RV m_GetMechanismList (
      Intervalo CK_SLOT_ID,
      CK_MECHANISM_TYPE_PTR mechs, CK_ULONG_PTR mechslen,
      destino de target_t
    );
    

C_GetMechanismList é usado para obter uma lista de tipos de mecanismos suportados por um token. SlotID é o ID do slot do token e pulCount aponta para o local que recebe o número de mecanismos.

Duas maneiras estão disponíveis para um aplicativo chamar C_GetMechanismList:

1. Se pMechanismList for NULL_PTR, a única coisa que o C_GetMechanismList fará é retornar (em *pulCount) o número de mecanismos, sem retornar uma lista de mecanismos. O conteúdo de *pulCount na entrada para C_GetMechanismList não tem significado nesse caso e a chamada retorna o valor CKR_OK.
2. Se pMechanismList não for NULL_PTR, *pulCount deverá conter o tamanho (em termos de elementos CK_MECHANISM_TYPE) do buffer apontado por pMechanismList. Se esse buffer for grande o suficiente para conter a lista de mecanismos, a lista será retornada nele e CKR_OK será retornado. Caso contrário, a chamada para C_GetMechanismList retornará o valor CKR_BUFFER_TOO_SMALL. Em qualquer caso, o valor *pulCount é configurado para conter o número de mecanismos.

Uma vez que C_GetMechanismList não aloca nenhum espaço próprio, um aplicativo muitas vezes chama C_GetMechanismList duas vezes. No entanto, esse comportamento não é necessário.

    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 (
      Intervalo CK_SLOT_ID,
      CK_MECHANISM_TYPE mech,
      CK_MECHANISM_INFO_PTR mechInfo,
      destino de target_t
    );
    

C_GetMechanismInfo obtém informações sobre um determinado mecanismo que pode ser suportado por um token. slotID é o ID do slot do token, type é o tipo de mecanismo, pInfo aponta para o local que recebe as informações do 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;
    }
    

Implementação de C_GenerateKey de PKCS #11.

As chaves do TDES são geradas com paridade adequada, o que não é observável pelo host. Mas é necessário para uma interoperabilidade adequada: outras implementações do PKCS n° 11 precisam rejeitar chaves do DES com problemas de paridade.

Se um objeto estiver vinculado a uma sessão, (pin, plen) ele deve retornar pelo Login a essa sessão. Deixar pinNULL cria um objeto público, não ligado a uma sessão de login.

(key, klen) retorna o blob da chave. (csum, clen) contém a soma de verificação da chave, ou seja, os bytes mais significativos de um bloco all-zero criptografado pela chave. NULL clen é possível, por exemplo, para mecanismos de chave simétricos sem os parâmetros CKA_CHECK_VALUE (como o RC4).

ptempl será usado somente se o comprimento da chave (ou seja, o atributo CKA_VALUE_LEN) for necessário para o mecanismo. Se o mecanismo especificar implicitamente o tamanho da chave, ptempl não será verificado quanto ao tamanho.

A geração de parâmetro DSA e DH ignora (csum, clen), gerando somente estruturas de parâmetro.

Parâmetros DSA, DH (CKM_DSA_PARAMETER_GEN): contagem de bits do módulo aprovado em CKA_PRIME_BITS de atributos. Escreve P, Q, G estrutura como saída de texto cleartext (isto é, não um blob).

O blob pin era saída de: Login.

O PKCS nº11 phKey não está mapeado para nenhum parâmetro EP11. (A biblioteca do host deve ligar a chave agrupada para manipular.)

    CK_RV m_GenerateKey (
      Mecanismo CK_MECHANISM_PTR,
      Modelo CK_ATTRIBUTE_PTR, CK_ULONG templatelen,
      const unsigned char *pin, size_t pinlen,
      unsigned char * key, size_t * keylen,
      caractere não assinado *checkSum, size_t *checkSumlen,
      destino de target_t
      );
    

C_GenerateKey gera uma chave secreta ou um conjunto de parâmetros de domínio, criando um novo objeto. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de geração, pTemplate aponta para o modelo para a nova chave ou conjunto de parâmetros de domínio, ulCount é o número de atributos no modelo, phKey aponta para o local que recebe o identificador da nova chave ou conjunto de parâmetros de domínio.

Se o mecanismo de geração destinar-se à geração de parâmetro de domínio, o atributo CKA_CLASS terá o valor CKO_DOMAIN_PARAMETERS, caso contrário, ele terá o valor CKO_SECRET_KEY.

Como o tipo de parâmetros de chave ou de domínio a serem gerados é implícito no mecanismo de geração, o modelo não precisa fornecer um tipo de chave. Se ele fornecer um tipo de chave que é inconsistente com o mecanismo de geração, C_GenerateKey falhará e retornará o código de erro CKR_TEMPLATE_INCONSISTENT. O atributo CKA_CLASS é tratado da mesma forma.

Se uma chamada para C_GenerateKey não puder suportar o modelo preciso que é fornecido a ele, ele falha e retorna sem criar um objeto.

O objeto criado por uma chamada bem-sucedida para C_GenerateKey tem o atributo CKA_LOCAL configurado como 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;
    }
    

Implementação de C_GenerateKeyPair de PKCS #11.

Os parâmetros de par de chaves são recuperados dos parâmetros pmech, ppublic e pprivate. Para chaves RSA, ppublic especifica o tamanho do módulo.

No modo FIPS, são suportados apenas os módulos RSA de 1024 + 256 n bits (número inteiro n). O modo não FIPS pode gerar chaves de qualquer número par de bits entre os limites na lista de parâmetros de mecanismo.

A chave pública é formatada como uma SPKI padrão (informação de chave pública de assunto), legível pela maioria das bibliotecas. Ela é protegida com integridade por um MAC específico de chave de transporte, que não faz parte do SPKI em si. A geração de parâmetro DSA retorna uma estrutura não SPKI no campo de chave pública.

Se um objeto for vinculado a uma sessão, (pin, plen) ele deve retornar pelo Login a essa sessão. Deixar pin NULL cria um objeto público, um que sobrevive à sessão de login.

Retorna a chave privada agrupada para (key, klen), chave pública como uma estrutura ASN.1/DER com MAC executado em (pubkey, pklen).

As combinações de parâmetros suportados a seguir com notas especiais estão além do que são documentadas pelo PKCS n° 11:

As chaves RSA rejeitam os expoentes públicos abaixo de 17 (0x11). Os pontos de controle podem restringir ainda mais o mínimo aceito. O expoente Fermat4, 0x10001, é controlado por um ponto de controle específico, combinando restrições de expoente público de FIPS 186-3 (seção B.3.1).

Chaves EC (CKM_EC_KEY_PAIR_GEN): os parâmetros de curva podem ser especificados como OIDs ou nomes simbólicos (nossa variante do namedCurve). Os nomes simbólicos suportados são "P-nnn" para curvas NIST (nnn é uma contagem principal de bits suportada, 192-521), "BP-nnnnR" para a curva BP regular. (Os nomes devem ser fornecidos como sequências ASCII, sem finalização zero.)

Chaves DSA (CKM_DSA_KEY_PAIR_GEN): transmita a estrutura P, Q, G como o atributo CKA_IBM_STRUCT_PARAMS de atributos públicos. Os parâmetros individuais P, Q, G podem não ser transmitidos por meio de parâmetros regulares do PKCS n° 11, eles devem ser combinados a uma única estrutura.

Chaves DH (CKM_DH_PKCS_KEY_PAIR_GEN): transmita a estrutura P, G como o atributo CKA_IBM_STRUCT_PARAMS de atributos públicos. Os parâmetros individuais P, G podem não ser transmitidos por meio de parâmetros regulares do PKCS n° 11, eles devem ser combinados a uma única estrutura. Ao selecionar uma contagem de bits de chave privada (X), use o atributo XCP_U32_VALUE_BITS. Se não estiver presente ou um 0 explícito for fornecido, a contagem de bits será selecionada com base em contagem de bits P.

Uso do estado de sessão (Login) substitui o uso padrão das sessões. O mapeamento está fora do escopo da biblioteca.

O blob pin era saída de: Login.

O PKCS nº11 hSession não está mapeado para nenhum parâmetro EP11. (A chamada não está associada diretamente a nenhuma sessão.)

phPublicKey de PKCS #11 não está mapeado para nenhum parâmetro EP11. (A biblioteca do host deve associar pubkey (SPKI) com o identificador.)

phPrivateKey de PKCS #11 não está mapeado para nenhum parâmetro EP11. (A biblioteca do host deve associar a chave privada com o identificador.)

    CK_RV m_GenerateKeyPair (
      Mecanismo CK_MECHANISM_PTR,
      CK_ATTRIBUTE_PTR pubKeyTemplate, CK_ULONG pubKeyTemplatelen,
      CK_ATTRIBUTE_PTR privKeyTemplate, CK_ULONG privKeyTemplatelen,
      const unsigned char *pin, size_t pinlen,
      caractere não assinado *privKey, size_t *privKeylen,
      caractere não assinado *pubKey, size_t *pubKeylen,
      destino de target_t
      );
    

C_GenerateKeyPair gera um par de chaves pública e privada, criando novos objetos chave. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de geração de chaves, pPublicKeyTemplate aponta para o modelo para a chave pública, ulPublicKeyAttributeCount é o número de atributos no modelo de chave pública, pPrivateKeyTemplate aponta para o modelo para a chave privada, ulPrivateKeyAttributeCount é o número de atributos no modelo de chave privada, phPublicKey aponta para o local que recebe o identificador da nova chave pública, phPrivateKey aponta para o local que recebe o identificador da nova chave privada.

Uma vez que os tipos de chaves a serem gerados são implícitos no mecanismo de geração de par de chaves, os modelos não precisam fornecer tipos de chaves. Se um dos modelos fornecer um tipo de chave que seja inconsistente com o mecanismo de geração de chaves, C_GenerateKeyPair falhará e retornará o código de erro CKR_TEMPLATE_INCONSISTENT. O atributo CKA_CLASS é tratado de forma semelhante.

Se uma chamada para C_GenerateKey não puder suportar o modelo preciso que é fornecido-lhe, ele falha e retorna sem criar nenhum objeto.

Uma chamada para C_GenerateKeyPair nunca cria apenas uma chave e retorna. Uma chamada pode falhar e criar nenhuma chave; ou pode ter sucesso e criar um par de chaves públicas e privadas correspondentes.

Os objetos chave criados por uma chamada bem-sucedida para C_GenerateKeyPair possuem os atributos CKA_LOCAL configurados como CK_TRUE.

Observe cuidadosamente a ordem dos argumentos para C_GenerateKeyPair. Os dois últimos argumentos não têm a mesma ordem que tinham no documento original do Cryptoki Versão 1.0. A ordem desses dois argumentos causou alguma infeliz confusão.

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

Implementação de C_DeriveKey de PKCS #11.

O blob basekey,bklen deve ser mapeado por meio do parâmetro hBaseKey de PKCS #11.

O PKCS nº11 hSession não está mapeado para nenhum parâmetro EP11. (A chamada não está associada diretamente a nenhuma sessão.)

O PKCS nº11 phKey não está mapeado para nenhum parâmetro EP11. (A biblioteca do host deve ligar a chave retornada ao identificador.)

    CK_RV m_DeriveKey (
        Mecanismo CK_MECHANISM_PTR,
        Modelo CK_ATTRIBUTE_PTR, CK_ULONG templatelen,
        const unsigned char *baseKey, size_t baseKeylen,
        const unsigned char *data, size_t datalen,
        const unsigned char *pin, size_t pinlen,
        caractere não assinado *newKey, size_t *newKeylen,
        caractere não assinado *checkSum, size_t *checkSumlen,
        destino de target_t
    );
    

C_DeriveKey deriva uma chave de uma chave base, criando um novo objeto chave. hSession é o identificador da sessão, pMechanism aponta para uma estrutura que especifica o mecanismo de derivação de chave, hBaseKey é o identificador da chave base, pTemplate aponta para o modelo para a nova chave, ulAttributeCount é o número de atributos no modelo e phKey aponta para o local que recebe o identificador da chave derivada.

Os valores dos atributos CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRATABLE e KA_NEVER_EXTRACTABLE para a chave base afetam os valores que esses atributos podem reter para a chave recém-derivada. Veja a descrição de cada mecanismo de derivação de chave específico na Seção 5.16.2 da especificação de API PKCS #11 para quaisquer restrições deste tipo.

Se uma chamada para C_GenerateKey não puder suportar o modelo preciso que é fornecido-ele, ele falha e retorna sem criar nenhum objeto.

O objeto de chave criado por uma chamada bem-sucedida para C_GenerateKey tem o atributo CKA_LOCAL configurado como 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 mecanismo CK_MECHANISM_PTR,
        CK_BYTE_PTR wrapped, CK_ULONG_PTR wrappedlen,
        destino de target_t
    );
    

C_WrapKey agrupa (isto é, criptografa) uma chave privada ou secreta. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de agrupamento, hWrappingKey é o identificador da chave de agrupamento, hKey é o identificador da chave a ser agrupada, pWrappedKey aponta para o local que recebe a chave agrupada e pulWrappedKeyLen aponta para o local que recebe o comprimento da chave agrupada.

C_WrapKey usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

O atributo CKA_WRAP da chave de agrupamento, que indica se a chave suporta ser agrupada, deve ser CK_TRUE. O atributo CKA_EXTRACTABLE da chave a ser agrupada também deve ser CK_TRUE.

Se a chave a ser agrupada não puder ser agrupada por algum motivo específico do token, apesar de ter seu atributo CKA_EXTRACTABLE configurado como CK_TRUE, C_WrapKey falhará com o código de erro CKR_KEY_NOT_WRAPPABLE. Se ela não puder ser agrupada com a chave de agrupamento especificada e o mecanismo somente por causa de seu comprimento, C_WrapKey falhará com o código de erro CKR_KEY_SIZE_RANGE.

C_WrapKey pode ser usado nas situações a seguir:

• Para agrupar qualquer chave secreta com uma chave pública que suporte criptografia e decriptografia.
• Para agrupar qualquer chave secreta com qualquer outra chave secreta. A consideração deve ser dada para o tamanho da chave e a força do mecanismo ou o token pode não permitir a operação.
• Para agrupar uma chave privada com qualquer chave secreta.

Quais tipos de chaves podem ser agrupados com quais mecanismos variam nos tokens.

Para particionar as chaves de agrupamento para que elas possam agrupar apenas um subconjunto de chaves extraíveis, o atributo CKA_WRAP_TEMPLATE pode ser usado na chave de agrupamento para especificar um conjunto de atributos que pode ser comparado com relação aos atributos da chave a ser agrupada. Se todos os atributos correspondem de acordo com as regras C_FindObject de correspondência de atributo, a operação de agrupamento procede. O valor desse atributo é um modelo de atributo e o tamanho é o número de itens no modelo vezes o tamanho de CK_ATTRIBUTE. Se esse atributo não for fornecido, qualquer modelo será aceitável. Se um atributo não estiver presente, ele não é verificado. Se alguma incompatibilidade de atributo ocorrer em uma tentativa de agrupar uma chave, a função retorna 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;
    }
    

Implementação de C_UnwrapKey de PKCS #11.

uwmech especifica o mecanismo de criptografia que é usado para decriptografar dados agrupados. ptempl é uma lista de parâmetros chave(par), que especifica como transformar os dados desagrupados em uma nova chave (deve incluir CKA_KEY_TYPE).

O objeto gerado é retornado em (unwrapped, uwlen) como um blob. As chaves simétricas retornam sua soma de verificação de chave (3 bytes) em (csum, cslen); os objetos de chave pública retornam sua chave pública como um SPKI em (csum, cslen). Ambos os formulários são seguidos por um valor big endian de 4 bytes, codificando a contagem de bits da chave desagrupada.

Quando uma SPKI está sendo transformada em uma SPKI com MAC, deve-se usar CKM_IBM_TRANSPORTKEY como o mecanismo de desagrupamento. Esse modo fornece o SPKI bruto como dados agrupados e ignora o KEK.

UnwrapKey produz chaves de DES ajustadas por paridade (dentro dos blobs), mas tolera entrada com paridade imprópria.

    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 mecanismo CK_MECHANISM_PTR,
        const CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        unsigned char * unwrapped, size_t * unwrappedlen,
        CK_BYTE_PTR checkSum, CK_ULONG *checkSumlen,
        destino de target_t
    );
    

C_UnwrapKey desagrupa (isto é, decriptografa) uma chave agrupada, criando um novo objeto de chave privada ou de chave secreta. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de desagrupamento, hUnwrappingKey é o identificador da chave de desagrupamento, pWrappedKey aponta para a chave agrupada, ulWrappedKeyLen é o comprimento da chave agrupada, pTemplate aponta para o modelo para a nova chave, ulAttributeCount é o número de atributos no modelo, phKey aponta para o local que recebe o identificador da chave recuperada.

O atributo CKA_UNWRAP da chave de desagrupamento, que indica se a chave suporta desagrupamento, deve ser CK_TRUE.

A nova chave tem o atributo CKA_ALWAYS_SENSITIVE configurado como CK_FALSE e o atributo CKA_NEVER_EXTRACTABLE configurado como CK_FALSE. O atributo CKA_EXTRACTABLE é, por padrão, configurado como CK_TRUE.

Alguns mecanismos podem ser modificados ou tentam ser modificados. o conteúdo da estrutura pMechanism ao mesmo tempo em que a chave é desagrupada.

Se uma chamada para C_UnwrapKey não puder suportar o modelo preciso que é fornecido-ele, ele falha e retorna sem criar nenhum objeto.

O objeto de chave criado por uma chamada bem-sucedida para C_UnwrapKey tem seu atributo CKA_LOCAL configurado como CK_FALSE.

Para particionar as chaves de desagrupamento para que elas possam desagrupar apenas um subconjunto de chaves, o atributo CKA_UNWRAP_TEMPLATE pode ser usado na chave de desagrupamento para especificar um conjunto de atributos que é incluído nos atributos da chave a ser desagrupada. Se os atributos não entram em conflito com o modelo de atributo fornecido pelo usuário, em pTemplate, a operação de desagrupar procede. O valor desse atributo é um modelo de atributo e o tamanho é o número de itens no modelo vezes o tamanho de CK_ATTRIBUTE. Se esse atributo não estiver presente na chave de desagrupamento, então nenhum atributo extra será incluído Se ocorrer algum conflito de atributo em uma tentativa de desagrupar uma chave, a função retornará 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;
    }
    

Implementação de C_GetAttributeValue de PKCS #11.

Não representa ou precisa de sessões (parte do blob), portanto, não usa o parâmetro hSession.

O EP11 usa formas mais diretas para decodificação, como enumerar valores reais em vez de ser mais genérico.

    CK_RV m_GetAttributeValue (
        const unsigned char *object, size_t objectlen,
        Atributos CK_ATTRIBUTE_PTR, CK_ULONG templatelen,
        destino de target_t
    );
    

C_GetAttributeValue obtém o valor de um ou mais atributos de um objeto. hSession é o identificador da sessão, hObject é o identificador do objeto, pTemplate aponta para um modelo que especifica quais valores de atributo devem ser obtidos e recebe os valores do atributo, ulCount é o número de atributos no modelo.

Para cada (type, pValue, ulValueLen) triplo no modelo, C_GetAttributeValue executa o algoritmo a seguir:

1. Se o atributo especificado (isto é, o atributo que é especificado pelo campo de tipo) do objeto não puder ser revelado porque o objeto é sensível ou não extraível, então o campo ulValueLen nesse trio será modificado para reter o valor CK_UNAVAILABLE_INFORMATION.
2. Caso contrário, se o valor especificado para o objeto for inválido (o objeto não possui esse atributo), o campo ulValueLen nesse triplo será modificado para conter o valor CK_UNAVAILABLE_INFORMATION.
3. Caso contrário, se o campo pValue tiver o valor NULL_PTR, o campo ulValueLen será modificado para conter o comprimento exato do atributo especificado para o objeto.
4. Caso contrário, se o comprimento especificado em ulValueLen for grande o suficiente para reter o valor do atributo especificado para o objeto, então esse atributo é copiado para o buffer que está em pValue e o campo ulValueLen é modificado para reter o comprimento exato do atributo.
5. Caso contrário, o campo ulValueLen será modificado para conter o valor CK_UNAVAILABLE_INFORMATION.

Se o caso 1 se aplica a qualquer um dos atributos solicitados, então a chamada precisa retornar o valor CKR_ATTRIBUTE_SENSITIVE. Se o caso 2 se aplica a qualquer um dos atributos solicitados, então a chamada precisa retornar o valor CKR_ATTRIBUTE_TYPE_INVALID. Se o caso 5 se aplica a qualquer um dos atributos solicitados, então a chamada precisa retornar o valor CKR_BUFFER_TOO_SMALL. Como de costume, se mais de um desses códigos de erro for aplicável, Cryptoki pode retornar qualquer um deles. Somente se nenhum deles se aplica a qualquer um dos atributos solicitados, CKR_OK é retornado.

No caso especial de um atributo cujo valor é uma matriz de atributos, por exemplo CKA_WRAP_TEMPLATE, em que ele é transmitido com pValue não NULL, se o pValue de elementos dentro da matriz for NULL_PTR, o ulValueLen de elementos dentro da matriz será configurado com o comprimento necessário. Se o pValue de elementos dentro da matriz não for NULL_PTR, o elemento ulValueLen de atributos dentro da matriz deverá refletir o espaço que o pValue correspondente aponta para e pValue será preenchido se houver espaço suficiente. Portanto, é importante inicializar o conteúdo de um buffer antes de C_GetAttributeValue ser chamado para obter esse valor de matriz... Se qualquer ulValueLen dentro da matriz não for grande o suficiente, ele é configurado como CK_UNAVAILABLE_INFORMATION e a função retorna CKR_BUFFER_TOO_SMALL, como faz se um atributo no argumento pTemplate tiver ulValueLen muito pequeno. Qualquer atributo, cujo valor é uma matriz de atributos, é identificável pelo conjunto CKF_ARRAY_ATTRIBUTE do tipo de atributo.

Os códigos de erro CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALIDe CKR_BUFFER_TOO_SMALL não denotam erros verdadeiros para C_GetAttributeValue. Se uma chamada para C_GetAttributeValue retornar qualquer um destes três valores, então a chamada deve, no entanto, ter processado todos os atributos no modelo que é fornecido para C_GetAttributeValue. Cada atributo no modelo cujo valor pode ser retornado pela chamada para C_GetAttributeValue é retornado pela chamada para 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;
    }
    

Implementação de C_SetAttributeValue de PKCS #11.

Compactação de atributo: consulte _GetAttrValue

Atualmente, o EP11 só envia atributos booleanos, e todos os outros atributos são manipulados pelo host (e o EP11 não modifica matrizes, como WRAP_TEMPLATE).

Não representa ou precisa de sessões (parte do blob), portanto, não usa o parâmetro hSession do PKCS #11.

    CK_RV m_SetAttributeValue (
        unsigned char *object, size_t objectlen,
        Atributos CK_ATTRIBUTE_PTR, CK_ULONG templatelen,
        destino de target_t
    );
    

C_SetAttributeValue modifica o valor de um ou mais atributos de um objeto. hSession é o identificador da sessão, hObject é o identificador do objeto, pTemplate aponta para um modelo que especifica quais valores de atributo devem ser modificados e seus novos valores, ulCount é o número de atributos no modelo.

Determinados objetos podem não ser modificados. Chamar C_SetAttributeValue em tais objetos resulta no código de erro CKR_ACTION_PROHIBITED. Um aplicativo pode consultar o atributo CKA_MODIFIABLE do objeto para determinar se um objeto pode ser modificado.

Somente objetos de sessão podem ser modificados durante uma sessão somente leitura.

O modelo pode especificar novos valores para quaisquer atributos do objeto que podem ser modificados. Se o modelo especificar um valor de um atributo incompatível com outros atributos existentes do objeto, a chamada falhará com o código de retorno CKR_TEMPLATE_INCONSISTENT.

Nem todos os atributos podem ser modificados, veja a Seção 4.1.2 da especificação de API PKCS #11 para obter mais informações.

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

Implementação de C_GenerateRandom de PKCS #11.

GenerateRandom é equivalente à função PKCS #11 original. Internamente, a entropia com valor inicial fornecido por hardware é passada por meio de um DRNG compatível com FIPS (ANSI X9.31/ISO 18031, dependendo da versão do Clic).

A biblioteca do host pode gerar números aleatórios sem despachar para o back-end, se a funcionalidade adequada estiver disponível no host. Isso não é feito na implementação atual.

Essa função não suporta uma consulta de tamanho.

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

Implementação de C_EncryptInit de PKCS #11.

O blob (chave, klen) pode ser um objeto de chave publicável, ou um blob de chave secreta. O tipo de chave deve ser consistente com pmech.

Para mecanismos de chave pública, (key, klen) deve conter um SPKI. Essa SPKI tem a integridade protegida com uma chave MAC, conforme retornada por GenerateKeyPair ou, como alternativa, UnwrapKey. O estado Encrypt é criado sem restrições de sessão.

Para mecanismos de chave secreta, o estado Criptografar herda restrições de sessão de objeto de (key, klen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

(key, klen) deve ser um blob de chave.

    CK_RV m_EncryptInit (
        caractere não assinado * estado, size_t * statelen,
        Mecanismo CK_MECHANISM_PTR,
        const unsigned char *key, size_t keylen,
        destino de target_t
    );
    

C_EncryptInit inicializa uma operação de criptografia. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de criptografia, hKey é o identificador da chave de criptografia.

O atributo CKA_ENCRYPT da chave de criptografia, que indica se a chave suporta criptografia, deve ser CK_TRUE.

Após o aplicativo chamar C_EncryptInit, o aplicativo pode chamar a C_Encrypt para criptografar dados em uma única parte; ou chamar C_EncryptUpdate zero ou mais vezes, seguido por C_EncryptFinal, para criptografar dados em várias partes. A operação de criptografia está ativa até que o aplicativo use uma chamada para C_Encrypt ou C_EncryptFinal para obter a parte final do texto cifrado. Para processar dados extras (em partes únicas ou múltiplas), o aplicativo deve chamar C_EncryptInit novamente.

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

Implementação de C_Encrypt de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state era saída de: EncryptInit.

    CK_RV m_Encrypt (
        const unsigned char *state, size_t statelen,
        Simples CK_BYTE_PTR, CK_ULONG plainlen,
        Cifrado CK_BYTE_PTR, CK_ULONG_PTR cipheredlen,
        destino de target_t
    );
    

C_Encrypt criptografa dados de parte única. hSession é o identificador da sessão, pData aponta para os dados, ulDataLen é o comprimento em bytes dos dados, pEncryptedData aponta para o local que recebe os dados criptografados, pulEncryptedDataLen aponta para o local que detém o comprimento em bytes dos dados criptografados.

C_Encrypt usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de criptografia deve ser inicializada com C_EncryptInit. Uma chamada para C_Encrypt sempre finaliza a operação de criptografia ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorna CKR_OK) para determinar o comprimento do buffer que é necessário para reter o texto cifrado.

O C_Encrypt não pode ser usado para finalizar uma operação de múltiplas partes e deve ser chamado após C_EncryptInit sem intervir chamadas C_EncryptUpdate.

Para alguns mecanismos de criptografia, os dados de texto sem formatação de entrada têm certas restrições de comprimento (porque o mecanismo pode criptografar apenas partes relativamente curtas de texto sem formatação ou porque os dados de entrada do mecanismo devem consistir em um número integral de blocos). Se essas restrições não estiverem satisfeitas, então C_Encrypt falhará com o código de retorno CKR_DATA_LEN_RANGE.

O texto simples e o texto cifrado podem estar no mesmo lugar, ou seja, será OK se pData e pEncryptedData apontarem para o mesmo local.

Para a maioria dos mecanismos, C_Encrypt é equivalente a uma sequência de operações C_EncryptUpdate seguida por 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;
    }
    

Implementação de C_EncryptUpdate de PKCS #11.

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state era saída de: EncryptInit.

    CK_RV m_EncryptUpdate (
        unsigned char *state, size_t statelen,
        Simples CK_BYTE_PTR, CK_ULONG plainlen,
        Cifrado CK_BYTE_PTR, CK_ULONG_PTR cipheredlen,
        destino de target_t
    );
    

C_EncryptUpdate continua uma operação de criptografia de várias partes, processando outra parte de dados. hSession é o identificador da sessão, pPart aponta para a parte de dados, ulPartLen é o comprimento da parte de dados, pEncryptedPart aponta para o local que recebe a parte de dados criptografados, pulEncryptedPartLen aponta para o local que detém o comprimento em bytes da parte de dados criptografados.

C_EncryptUpdate usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de criptografia deve ser inicializada com C_EncryptInit. Essa função pode ser chamada qualquer número de vezes em sucessão. Uma chamada para C_EncryptUpdate, que resulta em um erro diferente de CKR_BUFFER_TOO_SMALL, finaliza a operação de criptografia atual.

O plaintext e o ciphertext podem estar no mesmo lugar, ou seja, não há problema de o pPart e o pEncryptedPart apontarem para o mesmo local.

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

Implementação de C_EncryptFinal de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state foi a saída de: EncryptInit, EncryptUpdate.

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

C_EncryptFinal conclui uma operação de criptografia de várias partes. hSession é o identificador da sessão, pLastEncryptedPart aponta para o local que recebe a última parte dos dados criptografados, se houver, pulLastEncryptedPartLen aponta para o local que detém o comprimento da última parte de dados criptografados.

C_EncryptFinal usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de criptografia deve ser inicializada com C_EncryptInit. Uma chamada para C_EncryptFinal sempre finaliza a operação de criptografia ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer necessário para reter o texto cifrado.

Para alguns mecanismos de criptografia de várias partes, os dados de texto simples de entrada têm certas restrições de comprimento porque os dados de entrada do mecanismo devem consistir em um número integral de blocos. Se essas restrições não forem satisfeitas, então C_EncryptFinal falha com o 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 não padrão de Encrypt. Processa dados em uma passagem, com uma chamada. Não retorna nenhum estado para hospedar, apenas dados criptografados.

Esse é o método preferencial de criptografia de dados em uma passagem para aplicativos de reconhecimento de XCP. Funcionalmente ele é equivalente a EncryptInit seguido imediatamente por Encrypt, mas ele economiza roundtrips, agrupamento e desagrupamento.

Se o back-end suportar chaves residentes, a chave também poderá ser um identificador de chave residente.

Consulte também: Encrypt, EncryptInit, DecryptSingle.

O blob key era saída de: GenerateKey, UnwrapKey.

    CK_RV m_EncryptSingle (
        const unsigned char *key, size_t keylen,
        Mecanismo CK_MECHANISM_PTR,
        Simples CK_BYTE_PTR, CK_ULONG plainlen,
        Cifrado CK_BYTE_PTR, CK_ULONG_PTR cipheredlen,
        destino de 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 não padrão de Encrypt. Processa dados em uma passagem, com uma chamada. Não retorna nenhum estado a ser hospedado, apenas os dados recriptografados.

Decriptografa dados com a chave original e, em seguida, criptografa os dados brutos com uma chave diferente dentro do HSM de nuvem.

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey, size_t dkeylen,
        const unsigned char * ekey, size_t ekeylen,
        CK_MECHANISM_PTR decmech,
        CK_MECHANISM_PTR encmech,
        CK_BYTE_PTR in, CK_ULONG inlen,
        Cifrado CK_BYTE_PTR, CK_ULONG_PTR cipheredlen,
        destino de target_t
    );
    

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

    CK_RV m_DecryptInit (
        caractere não assinado * estado, size_t * statelen,
        Mecanismo CK_MECHANISM_PTR,
        const unsigned char *key, size_t keylen,
        destino de target_t
    );
    

C_DecryptInit inicializa uma operação de decriptografia. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de decriptografia, hKey é o identificador da chave de decriptografia.

O atributo CKA_DECRYPT da chave de decriptografia, que indica se a chave suporta decriptografia, deve ser CK_TRUE.

Após o aplicativo chamar C_DecryptInit, o aplicativo pode chamar C_Decrypt para decriptografar dados em uma única parte ou chamar C_DecryptUpdate zero ou mais vezes, seguido por C_DecryptFinal, para decriptografar dados em várias partes. A operação de decriptografia está ativa até que o aplicativo use uma chamada para C_Decrypt ou C_DecryptFinal para obter a peça final de texto sem formatação. Para processar dados extras (em partes únicas ou múltiplas), o aplicativo deve chamar C_EncryptInit novamente.

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

Implementação do PKCS #11 C_Decrypt. Ele não atualiza (state, slen).

O estado, o objeto binário grande (BLOB) slen deve ser mapeado por meio do parâmetro hSession de PKCS #11. O estado BLOB foi a saída 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 de target_t
    );
    

C_Decrypt decriptografa dados criptografados em uma única parte.

• hSession é o identificador de sessão.
• pEncryptedData aponta para os dados criptografados.
• ulEncryptedDataLen é o comprimento dos dados criptografados.
• pData aponta para o local que recebe os dados recuperados.
• pulDataLen aponta para o local que contém o comprimento dos dados recuperados.

C_Decrypt usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de descriptografia deve ser inicializada com C_EncryptInit. Uma chamada para C_Decrypt sempre finaliza a operação de decriptografia ativa, a menos que retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida com CKR_OK retornado para determinar o comprimento do buffer que é necessário para reter o texto simples.

C_Decrypt não pode ser usado para finalizar uma operação de múltiplas partes e precisa ser chamado após C_DecryptInit sem intervir em chamadas para C_DecryptUpdate.

O texto cifrado e o texto sem formatação podem estar no mesmo local, o que significa que é aceitável se pEncryptedData e pData apontarem para o mesmo local.

Se os dados de texto cifrado de entrada não puderem ser decriptografados porque têm um comprimento inadequado, CKR_ENCRYPTED_DATA_INVALID ou CKR_ENCRYPTED_DATA_LEN_RANGE poderá ser retornado.

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

Implementação de C_DecryptUpdate de PKCS #11.

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state foi a saída de: DecryptInit.

    CK_RV m_DecryptUpdate (
        unsigned char *state, size_t statelen,
        Cifrado CK_BYTE_PTR, CK_ULONG cipheredlen,
        Simples CK_BYTE_PTR, CK_ULONG_PTR plainlen,
        destino de target_t
    );
    

C_DecryptUpdate continua uma operação de decriptografia de várias partes, processando outra parte de dados criptografados. hSession é o identificador da sessão, pEncryptedPart aponta para a parte de dados criptografados, ulEncryptedPartLen é o comprimento da parte de dados criptografados, pPart aponta para o local que recebe a parte de dados recuperados, pulPartLen aponta para o local que detém o comprimento da parte de dados recuperados.

C_DecryptUpdate usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de descriptografia deve ser inicializada com C_DecryptInit. Essa função pode ser chamada qualquer número de vezes em sucessão. Uma chamada para C_DecryptUpdate, que resulta em um erro diferente de CKR_BUFFER_TOO_SMALL, finaliza a operação de decriptografia atual.

O texto cifrado e o texto simples podem estar no mesmo local, ou seja, será OK se pEncryptedPart e pPart apontarem para o mesmo local.

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

Implementação de C_DecryptFinal de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state era de saída de: DecryptInit, DecryptUpdate.

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

C_DecryptFinal conclui uma operação de decriptografia de várias partes. hSession é o identificador da sessão, pLastPart aponta para o local que recebe a última parte de dados recuperados, se houver, pulLastPartLen aponta para o local que detém o comprimento da última parte de dados recuperados.

C_DecryptFinal usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de descriptografia deve ser inicializada com C_DecryptInit. Uma chamada para C_DecryptFinal sempre finaliza a operação de decriptografia ativa, a menos que retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer que é necessário para conter o texto sem formatação.

Se os dados de texto cifrado de entrada não puderem ser decriptografados porque têm um comprimento inapropriado, então CKR_ENCRYPTED_DATA_INVALID ou CKR_ENCRYPTED_DATA_LEN_RANGE poderá ser retornado.

    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 não padrão de Decrypt. Processa dados em uma passagem, com uma chamada. Não retorna nenhum estado para hospedar, apenas dados decriptografados.

Esse é o método preferencial de criptografia de dados em uma passagem para aplicativos de reconhecimento de XCP. Funcionalmente ele é equivalente a DecryptInit seguido imediatamente por Decrypt, mas ele salva roundtrips, agrupamento e desagrupamento.

Se o back-end suportar chaves residentes, a chave também poderá ser um identificador de chave residente.

Consulte também: Decrypt, DecryptInit, EncryptSingle.

O blob key era saída de: GenerateKey, UnwrapKey.

    CK_RV m_DecryptSingle (
        const unsigned char *key, size_t keylen,
        Mecanismo CK_MECHANISM_PTR,
        Cifrado CK_BYTE_PTR, CK_ULONG cipheredlen,
        Simples CK_BYTE_PTR, CK_ULONG_PTR plainlen,
        destino de target_t
    );
    

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

    CK_RV m_SignInit (
        caractere não assinado * estado, size_t * statelen,
        Mecanismo CK_MECHANISM_PTR,
        const unsigned char *privKey, size_t privKeylen,
        destino de target_t
    );
    

C_SignInit inicializa uma operação de assinatura, em que a assinatura é um apêndice dos dados. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de assinatura, hKey é o identificador da chave de assinatura.

O atributo CKA_SIGN da chave de assinatura, que indica se a chave suporta assinaturas com apêndice, deve ser CK_TRUE.

Após o aplicativo chamar C_SignInit, o aplicativo pode ligar para C_Sign para assinar em uma única parte; ou chamar C_SignUpdate uma ou mais vezes, seguido por C_SignFinal, para assinar dados em várias partes. A operação de assinatura está ativa até o aplicativo usar uma chamada para que C_Sign ou C_SignFinal obtenham a assinatura. Para processar dados extras (em partes únicas ou múltiplas), o aplicativo deve chamar C_SignInit novamente.

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

Implementação de C_Sign de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era saída de: SignInit.

    CK_RV m_Sign (
        const unsigned char *state, size_t statelen,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Assinatura CK_BYTE_PTR, CK_ULONG_PTR signaturelen,
        destino de target_t
    );
    

C_Sign assina dados em uma única parte, em que a assinatura é um apêndice dos dados. hSession é o identificador da sessão, pData aponta para os dados, ulDataLen é o comprimento dos dados, pSignature aponta para o local que recebe a assinatura, pulSignatureLen aponta para o local que detém o comprimento da assinatura.

C_Sign usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de assinatura deve ser inicializada com C_SignInit. Uma chamada para C_Sign sempre finaliza a operação de assinatura ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer necessário para reter a assinatura.

C_Sign não pode ser usado para finalizar uma operação de múltiplas partes e deve ser chamado após C_SignInit sem intervir chamadas C_SignUpdate.

Para a maioria dos mecanismos, C_Sign é equivalente a uma sequência de operações C_SignUpdate seguida por 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;
    }
    

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era saída de: SignInit.

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

C_SignUpdate continua uma operação de assinatura de várias partes, processando outra parte de dados. hSession é o identificador da sessão, pPart aponta para a parte de dados, ulPartLen é o comprimento da parte de dados.

A operação de assinatura deve ser inicializada com C_SignInit. Essa função pode ser chamada qualquer número de vezes em sucessão. Uma chamada para C_SignUpdate que resulta em um erro finaliza a operação de assinatura atual.

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

Implementação de C_SignFinal de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era a saída de: SignInit, SignUpdate.

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

C_SignFinal conclui uma operação de assinatura de várias partes, retornando a assinatura. hSession é o identificador da sessão, pSignature aponta para o local que recebe a assinatura, pulSignatureLen aponta para o local que detém o comprimento da assinatura.

C_SignFinal usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de assinatura deve ser inicializada com C_SignInit. Uma chamada para C_SignFinal sempre finaliza a operação de assinatura ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer necessário para reter a assinatura.

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

Extensão não padrão, combinação de SignInit e Sign. Assinaturas ou dados de MACs em uma passagem, com uma chamada, sem construir o estado de compilação intermediária. Não retorna nenhum estado para hospedar, apenas resultado.

Essa é a maneira preferencial de assinar, sem uma ida e volta, criptografia e descriptografia extra. Funcionalmente, SignSingle é equivalente a SignInit seguido imediatamente por Sign.

O blob (key, klen) e o mecanismo pmech juntos devem ser transmissíveis para SignInit.

As solicitações de vários dados para assinaturas HMAC e CMAC são suportadas (subvariantes 2 e 3).

Consulte também: SignInit, Sign, VerifySingle.

    CK_RV m_SignSingle (
        const unsigned char *privKey, size_t privKeylen,
        Mecanismo CK_MECHANISM_PTR,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Assinatura CK_BYTE_PTR, CK_ULONG_PTR signaturelen,
        destino de target_t
    );
    

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

Implementação de C_VerifyInit de PKCS #11. Dado um blob de chave (key, klen), inicialize um estado de sessão de verificação em (state, slen). O blob de chave pode ser um objeto de chave pública ou bytes de chave HMAC. O tipo de blob de chave deve ser consistente com pmech.

Para mecanismos de chave pública, (key, klen) deve conter um SPKI. Esse SPKI CKA_UNWRAP pode ser autenticado por MAC (como retornado anteriormente por GenerateKeyPair) ou apenas pelo próprio SPKI (quando obtido de uma origem externa, como um certificado).

Se uma operação HMAC for inicializada, as restrições de sessão do objeto Verify serão herdadas da chave HMAC. Como os SPKIs não estão vinculados às sessões, os estados de Verificação de chave pública são livres de sessão.

O blob key,klen deve ser mapeado por meio do parâmetro hKey de PKCS #11.

Nota: SignInit e VerifyInit são internamente o mesmo para HMAC e outros mecanismos simetric/MAC.

    CK_RV m_VerifyInit (
        caractere não assinado * estado, size_t * statelen,
        Mecanismo CK_MECHANISM_PTR,
        const unsigned char *pubKey, size_t pubKeylen,
        destino de target_t
    );
    

C_VerifyInit inicializa uma operação de verificação, em que a assinatura é um apêndice dos dados. hSession é o identificador da sessão, pMechanism aponta para a estrutura que especifica o mecanismo de verificação, hKey é o identificador da chave de verificação.

O atributo CKA_VERIFY da chave de verificação, que indica se a chave suporta verificação em que a assinatura é um apêndice aos dados, deve ser CK_TRUE.

Após o aplicativo chamar C_VerifyInit, ele poderá chamar C_Verify para verificar uma assinatura em dados em uma única parte; ou chamar C_VerifyUpdate uma ou mais vezes, seguido por C_VerifyFinal, para verificar uma assinatura em dados em várias partes. A operação de verificação está ativa até que o aplicativo chame C_Verify ou C_VerifyFinal. Para processar dados extras (em partes únicas ou múltiplas), o aplicativo deve chamar C_VerifyInit novamente.

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

Implementação de C_Verify de PKCS #11.

Não atualiza (state, slen).

A ordem relativa de dados e assinatura é revertida relativa para VerifySingle.

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era saída de: VerifyInit.

    CK_RV m_Verify (
        const unsigned char *state, size_t statelen,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Assinatura CK_BYTE_PTR, CK_ULONG signaturelen,
        destino de target_t
    );
    

C_Verify verifica uma assinatura em uma operação de parte única, em que a assinatura é um apêndice dos dados. hSession é o identificador da sessão, pData aponta para os dados, ulDataLen é o comprimento dos dados, pSignature aponta para a assinatura, ulSignatureLen é o comprimento da assinatura.

A operação de verificação deve ser inicializada com C_VerifyInit. Uma chamada para C_Verify sempre finaliza a operação de verificação ativa.

Uma chamada bem-sucedida para C_Verify precisa retornar ou o valor CKR_OK (indicando que a assinatura fornecida é válida) ou CKR_SIGNATURE_INVALID (indicando que a assinatura fornecida é inválida). Se a assinatura for inválida puramente com base em seu comprimento, então CKR_SIGNATURE_LEN_RANGE precisa ser retornado. Em qualquer um desses casos, a operação de assinatura ativa é finalizada.

C_Verify não pode ser usado para finalizar uma operação de múltiplas partes e deve ser chamado após C_VerifyInit sem intervir chamadas C_VerifyUpdate.

Para a maioria dos mecanismos, C_Verify é equivalente a uma sequência de operações C_VerifyUpdate seguida por 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;
    }
    

Implementação de C_VerifyUpdate de PKCS #11.

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era saída de: VerifyInit.

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

C_VerifyUpdate continua uma operação de verificação de várias partes, processando outra parte de dados. hSession é o identificador da sessão, pPart aponta para a parte de dados, ulPartLen é o comprimento da parte de dados.

A operação de verificação deve ser inicializada com C_VerifyInit. Essa função pode ser chamada qualquer número de vezes em sucessão. Uma chamada para C_VerifyUpdate que resulta em um erro finaliza a operação de verificação atual.

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

Implementação de C_VerifyFinal de PKCS #11.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era a saída de: VerifyInit, VerifyUpdate.

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

C_VerifyFinal conclui uma operação de verificação de várias partes, verificando a assinatura. hSession é o identificador da sessão, pSignature aponta para a assinatura, ulSignatureLen é o comprimento da assinatura.

A operação de verificação deve ser inicializada com C_VerifyInit. Uma chamada para C_VerifyFinal sempre finaliza a operação de verificação ativa.

Uma chamada bem-sucedida para C_VerifyFinal precisa retornar ou o valor CKR_OK (indicando que a assinatura fornecida é válida) ou CKR_SIGNATURE_INVALID (indicando que a assinatura fornecida é inválida). Se a assinatura for inválida com base em seu comprimento, então CKR_SIGNATURE_LEN_RANGE precisa ser retornado. Em qualquer um desses casos, a operação de verificação ativa é finalizada.

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

Extensão não padrão, combinação de VerifyInit e Verify. Assinaturas ou dados de MACs em uma passagem, com uma chamada, sem construir o estado de compilação intermediária. Não retorna nenhum estado para o host, apenas o resultado da verificação. Nenhuma consulta de tamanho está disponível porque esta função retorna um booleano.

Esta é a maneira preferencial de verificar uma assinatura, sem uma ida e volta, criptografia, descriptografia extra. Funcionalmente, VerifySingle é equivalente a VerifyInit seguido imediatamente por um Verify.

O blob (key, klen) e o mecanismo pmech juntos devem ser transmissíveis para VerifyInit.

Para mecanismos de chave pública, (key, klen) deve conter um SPKI. Esse SPKI poderá ter o MAC executado (como retornado como uma chave pública do GenerateKeyPair) ou apenas o próprio SPKI (se obtido de uma origem externa, como um certificado).

Consulte também: VerifyInit, Verify, SignSingle.

    CK_RV m_VerifySingle (
        const unsigned char *pubKey, size_t pubKeylen,
        Mecanismo CK_MECHANISM_PTR,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Assinatura CK_BYTE_PTR, CK_ULONG signaturelen,
        destino de target_t
    );
    

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

Implementação de C_DigestInit de PKCS #11.

Criar estado de compilação agrupado.

Nota: as consultas de tamanho são suportadas, mas o estado agrupado é sempre retornado pelo back-end, diferentemente da maioria das consultas de tamanho (que retornam um tamanho de saída, em vez de saída real). Os estados Digest são suficientemente pequenos, de modo que não introduzem sobrecarga de transporte perceptível.

Durante as consultas de tamanho, o host apenas descarta o estado retornado e relata o tamanho de blob (em len). Quando o blob estiver sendo retornado, len será verificado com relação ao tamanho retornado.

O blob state,len deve ser mapeado por meio do parâmetro hSession de PKCS #11. (A biblioteca do host deve ligar o blob à sessão.)

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

C_DigestInit inicializa uma operação de compilação de mensagens. hSession é o identificador da sessão, pMechanism aponta para o mecanismo de compilação.

Após o aplicativo chamar C_DigestInit, ele poderá chamar C_Digest para compilar os dados em uma única parte; ou chamar C_DigestUpdate zero ou mais vezes, seguido pelo C_DigestFinal, para compilar os dados em várias partes. A operação de compilação de mensagens estará ativa até que o aplicativo use uma chamada para C_Digest ou C_DigestFinal para obter o trecho da mensagem. Para processar dados extras (em partes únicas ou múltiplas), o aplicativo deve chamar 1C_DigestInit1 novamente.

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

Implementação de C_Digest de PKCS #11.

Se um objeto de compilação tiver exatamente 0 (zero) bytes anexados a ele após a criação, em qualquer combinação de transferências de zero bytes, ele ainda pode executar uma Compilação de transmissão única, mesmo que ele precise ser rejeitado por uma implementação estrita.

Não atualiza (state, slen).

Implementações podem executar DigestUpdate, DigestFinalou Digest chama objetos de compilação de texto não criptografado no código do host, ignorando os backends do HSM completamente. Essa escolha pode ou não ser visível para o código do host e não impacta a segurança da operação (já que objetos sem criptografia podem não compilar dados sensíveis).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. O blob state era de saída de: DigestInit.

    CK_RV m_Digest (
        const unsigned char *state, size_t statelen,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Compilação CK_BYTE_PTR, CK_ULONG_PTR digestlen,
        destino de target_t
    );
    

C_Digest compila dados em uma única parte. hSession é o identificador da sessão, pData aponta para os dados, ulDataLen é o comprimento dos dados, pDigest aponta para o local que recebe o trecho da mensagem, pulDigestLen aponta para o local que detém o comprimento do trecho da mensagem.

C_Digest usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de compilação deve ser inicializada com C_DigestInit. Uma chamada para C_Digest sempre finaliza a operação de compilação ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer necessário para reter a compilação da mensagem.

O C_Digest não pode ser usado para finalizar uma operação de várias partes e deve ser chamado após C_DigestInit sem intervir chamadas C_DigestUpdate.

Os dados de entrada e a saída de compilação podem estar no mesmo lugar, ou seja, não há problema de o pData e o pDigest apontarem para o mesmo local.

C_Digest é equivalente a uma sequência de operações C_DigestUpdate seguida por 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;
    }
    

Implementação de C_DigestUpdate de PKCS #11.

DigestUpdate é polimórfico, aceitando objetos de compilação agrupados ou limpos, atualizando o estado no mesmo formato.

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11. (A biblioteca de host deve mapear a sessão para o estado armazenado.)

O blob state era saída de: DigestInit, DigestUpdate, DigestKey.

Consulte também: DigestInit

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

C_DigestUpdate continua uma operação de compilação de mensagens de várias partes, processando outra parte de dados. hSession é o identificador da sessão, pPart aponta para a parte de dados, ulPartLen é o comprimento da parte de dados.

A operação de compilação de mensagem deve ser inicializada com C_DigestInit. Chamadas para essa função e C_DigestKey podem ser intercaladas quantas vezes forem necessárias e em qualquer ordem. Uma chamada para C_DigestUpdate que resulta em um erro finaliza a operação de compilação atual.

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

Implementação de C_DigestFinal de PKCS #11.

DigestFinal é polimórfico, aceitando ambos os objetos de compilação agrupados ou limpos.

Não atualiza (state, slen).

O blob state,slen deve ser mapeado por meio do parâmetro hSession do PKCS nº11.

O blob state era saída de: DigestInit, DigestUpdate, DigestKey.

    CK_RV m_DigestFinal (
        const unsigned char *state, size_t statelen,
        Compilação CK_BYTE_PTR, CK_ULONG_PTR digestlen,
        destino de target_t
    );
    

C_DigestFinal conclui uma operação de compilação de mensagens de várias partes, retornando o trecho da mensagem. hSession é o identificador da sessão, pDigest aponta para o local que recebe o trecho da mensagem, pulDigestLen aponta para o local que detém o comprimento do trecho da mensagem.

C_DigestFinal usa a convenção que é descrita na Seção 5.2 da especificação de API PKCS #11 sobre a produção de saída.

A operação de compilação deve ser inicializada com C_DigestInit. Uma chamada para C_DigestFinal sempre finaliza a operação de compilação ativa, a menos que ela retorne CKR_BUFFER_TOO_SMALL ou seja uma chamada bem-sucedida (ou seja, uma que retorne CKR_OK) para determinar o comprimento do buffer necessário para reter a compilação da mensagem.

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

Extensão não padrão, combinação de DigestInit e Digest. Compila dados em uma passagem, com uma chamada, sem construir um estado de compilação intermediário e roundtrips desnecessárias.

Esse é o método preferencial de compilação de texto não criptografado para aplicativos direcionados a XCP. Funcionalmente, DigestSingle é equivalente a DigestInit seguido imediatamente por Digest.

Se uma chave precisa ser compilada, deve-se usar DigestInit e DigestKey, uma vez que essa função não manipula blobs de chave.

Não retorna nenhum estado para o host, apenas o resultado da compilação. Não há parâmetros não PKCS #11, uma vez que tudo é usado diretamente da chamada de PKCS #11.

    CK_RV m_DigestSingle (
        Mecanismo CK_MECHANISM_PTR,
        Dados CK_BYTE_PTR, CK_ULONG datalen,
        Compilação CK_BYTE_PTR, CK_ULONG_PTR digestlen,
        destino de target_t
    );