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,
      destinazione_t
    );
    

C_GetMechanismList viene utilizzato per ottenere un elenco di tipi di meccanismo supportati da un token, SlotID è l'ID dello slot del token; pulCount punta all'ubicazione che riceve il numero di meccanismi.

Sono disponibili due modi per un'applicazione per richiamare C_GetMechanismList:

1. Se pMechanismList è NULL_PTR, tutto ciò che C_GetMechanismList restituisce (in *pulCount) il numero di meccanismi, senza restituire un elenco di meccanismi. Il contenuto di *pulCount restituito richiamando C_GetMechanismList non ha alcun significato in questo caso e la chiamata restituisce il valore CKR_OK.
2. Se pMechanismList non è NULL_PTR, *pulCount deve contenere la dimensione (in termini di elementi CK_MECHANISM_TYPE ) del buffer puntato da pMechanismList. Se tale buffer è abbastanza grande da contenere l'elenco di meccanismi, in esso viene restituito l'elenco e viene restituito CKR_OK. In caso contrario, la chiamata a C_GetMechanismList restituisce il valore CKR_BUFFER_TOO_SMALL. In entrambi i casi, il valore *pulCount è impostato per contenere il numero di meccanismi.

Poiché C_GetMechanismList non assegna alcuno spazio, un'applicazione spesso richiama C_GetMechanismList due volte. Tuttavia, questa modalità di funzionamento non è affatto richiesta.

    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,
      destinazione_t
    );
    

C_GetMechanismInfo ottiene informazioni su un particolare meccanismo che potrebbe essere supportato da un token. slotID è l'ID dello slot del token; type è il tipo di meccanismo; pInfo punta all'ubicazione che riceve le informazioni sul meccanismo.

    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> Modello = 6;
    }
    message GenerateKeyResponse {
      byte KeyBytes = 4;
      bytes CheckSum = 5;
    }
    

Implementazione di C_GenerateKey PKCS #11.

Le chiavi TDES vengono generate con la parità appropriata, che non può essere osservata dall'host. Ma è necessario per una corretta interoperabilità: altre implementazioni PKCS #11 devono rifiutare le chiavi DES con problemi di parità.

Se un oggetto è collegato a una sessione, (pin, plen) deve essere restituito da Login a tale sessione. Lasciare pin NULL crea un oggetto pubblico, uno non collegato a una sessione di accesso.

(key, klen) restituisce il blob chiave. (csum, clen) contiene il checksum della chiave, ossia i byte più significativi di un blocco all - zero codificato dalla chiave. NULL clen è possibile, ad esempio, per i meccanismi di chiave simmetrica senza parametri CKA_CHECK_VALUE (come ad esempio RC4).

ptempl viene utilizzato solo se la lunghezza della chiave (ovvero, l'attributo CKA_VALUE_LEN ) è richiesta dal meccanismo. Se il meccanismo specifica in modo implicito la dimensione della chiave, non viene eseguita la verifica di ptempl per rilevare la dimensione,

La generazione di parametri DSA e DH ignora (csum, clen), generando solo strutture di parametri.

Parametri DSA, DH (CKM_DSA_PARAMETER_GEN): passa conteggio bit modulo in CKA_PRIME_BITS di attributi. Scrive la struttura P, Q, G come output cleartext (cioè, non un blob).

Il blob pin veniva generato in output da: Login.

phKey PKCS #11 non è associata ad alcun parametro EP11. (La libreria host deve associare la chiave impacchettata al bundle).

    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,
      destinazione_t
      );
    

C_GenerateKey genera una chiave segreta o una serie di parametri di dominio, creando un nuovo oggetto. hSession è l'handle della sessione; pMechanism punta al meccanismo di generazione; pTemplate punta al modello per la nuova chiave o serie di parametri di dominio; ulCount è il numero di attributi nel modello; phKey punta all'ubicazione che riceve l'handle della nuova chiave o serie di parametri di dominio.

Se il meccanismo di creazione è per la creazione di parametri di dominio, l'attributo CKA_CLASS ha il valore CKO_DOMAIN_PARAMETERS; altrimenti, ha il valore CKO_SECRET_KEY.

Poiché il tipo di parametri di dominio o chiave da generare è implicito nel meccanismo di generazione, il template non ha bisogno di fornire un tipo di chiave. Se fornisce un tipo di chiave che non è congruente con il meccanismo di generazione, C_GenerateKey ha esito negativo e restituisce il codice di errore CKR_TEMPLATE_CONSISTENTI. L'attributo CKA_CLASS viene trattato allo stesso modo.

Se una chiamata a C_GenerateKey non è in grado di supportare il modello preciso fornito, ha esito negativo e viene restituita senza creare un oggetto.

L'oggetto creato da una chiamata eseguita correttamente a C_GenerateKey ha l'attributo CKA_LOCAL impostato su 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 {
      byte PrivKeyByte = 5;
      byte PubKeyByte = 6;
    }
    

Implementazione di C_GenerateKeyPair PKCS #11.

I parametri di coppia di chiavi vengono richiamati dai parametri pmech, ppublic e pprivate. Per le chiavi RSA, ppublic specifica la dimensione del modulo.

In modalità FIPS, sono supportati solo i moduli RSA di 1024 + 256 n bit (numero intero n). La modalità non FIPS può generare chiavi di qualsiasi numero pari di bit compresi tra i limiti nell'elenco dei parametri del meccanismo.

La chiave pubblica è formattata come SPKI standard (informazioni sulla chiave pubblica dell'oggetto), leggibile dalla maggior parte delle librerie. È protetta a livello di integrità da una chiave MAC specifica per la chiave di trasporto, che non fa parte della SPKI stessa. La generazione dei parametri DSA restituisce una struttura non SPKI nel campo della chiave pubblica.

Se si collega un oggetto a una sessione, (pin, plen) deve essere restituito da Login a tale sessione. Se si lascia pin NULL si crea un oggetto pubblico, uno che sopravvive alla sessione di accesso.

Restituisce la chiave privata impacchettata a (key, klen), public come una struttura ASN.1/DER con protezione mediante chiave MAC in (pubkey, pklen).

Le seguenti combinazioni di parametri supportate con note speciali vanno oltre quanto documentato da PKCS #11:

Le chiavi RSA rifiutano gli esponenti pubblici al di sotto di 17 (0x11). I punti di controllo possono limitare ulteriormente il minimo accettato. L'esponente Fermat4, 0x10001, è controllato da un punto di controllo specifico, corrispondente alle restrizioni dell'esponente pubblico di FIPS 186-3 (sezione B.3.1).

Chiavi EC (CKM_EC_KEY_PAIR_GEN): i parametri della curva possono essere specificati come OID o nomi simbolici (variante namedCurve ). I nomi simbolici supportati sono "P - nnn" per le curve NIST (nnn è un numero di bit primario supportato, 192 - 521), "BP -nnnR" per la normale curva BP. (I nomi devono essere forniti come stringhe ASCII, senza terminazione zero.)

Le chiavi DSA (CKM_DSA_KEY_PAIR_GEN): passano la struttura P,Q,G come attributo CKA_IBM_STRUCT_PARAMS degli attributi pubblici. I singoli parametri P, Q, G potrebbero non essere passati attraverso i normali parametri PKCS #11 , devono essere combinati in una singola struttura.

Le chiavi DH (CKM_DH_PKCS_KEY_PAIR_GEN): passano la struttura P,G come attributo CKA_IBM_STRUCT_PARAMS degli attributi pubblici. I singoli parametri P, G potrebbero non essere passati attraverso i normali parametri PKCS #11 , devono essere combinati in una singola struttura. Quando si seleziona un bitcount di chiave privata (X), utilizzare l'attributo XCP_U32_VALUE_BITS . Se non è presente, o se viene fornito uno 0 esplicito, il conteggio di bit viene selezionato in base al conteggio di bit P.

L'uso dello stato della sessione (Login) sostituisce l'uso standard delle sessioni. L'associazione è esterna all'ambito della libreria.

Il blob pin veniva generato in output da: Login.

hSession PKCS #11 non è associata ad alcun parametro EP11. (La chiamata non è direttamente associata ad alcuna sessione).

phPublicKey PKCS #11 non è associata ad alcun parametro EP11. (La libreria host deve associare la chiave pubblica (SPKI) all'handle).

phPrivateKey PKCS #11 non è associata ad alcun parametro EP11. (La libreria host deve associare la chiave privata all'handle).

    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,
      destinazione_t
      );
    

C_GenerateKeyPair genera una coppia di chiavi pubblica e privata, creando nuovi oggetti chiave. hSession è l'handle della sessione; pMechanism punta al meccanismo di generazione delle chiavi; pPublicKeyTemplate punta alla maschera per la chiave pubblica; ulPublicKeyAttributeCount è il numero di attributi nella maschera della chiave pubblica; pPrivateKeyTemplate punta al modello per la chiave privata; ulPrivateKeyAttributeCount è il numero di attributi nel modello di chiave privata; phPublicKey punta all'ubicazione che riceve l'handle della nuova chiave pubblica; phPrivateKey punta all'ubicazione che riceve l'handle della nuova chiave privata.

Poiché i tipi di chiave da generare sono impliciti nel meccanismo di generazione di coppie di chiavi, i template non hanno bisogno di fornire i tipi di chiave. Se uno dei modelli fornisce un tipo di chiave che non è congruente con il meccanismo di generazione chiavi, C_GenerateKeyPair ha esito negativo e restituisce il codice di errore CKR_TEMPLATE_CONSISTENTI. L'attributo CKA_CLASS viene trattato in modo simile.

Se una chiamata a C_GenerateKeyPair non può supportare i modelli precisi forniti, ha esito negativo e viene restituita senza creare alcun oggetto chiave.

Una chiamata a C_GenerateKeyPair non crea mai una sola chiave e restituisce. Una chiamata può avere esito negativo e non creare alcuna chiave; oppure può avere esito positivo e creare una coppia di chiavi pubblica e privata corrispondente.

Gli oggetti chiave creati da una chiamata riuscita a C_GenerateKeyPair hanno gli attributi CKA_LOCAL impostati su CK_TRUE.

Osserva attentamente l'ordine degli argomenti per C_GenerateKeyPair. Gli ultimi due argomenti non hanno lo stesso ordine che avevano nel documento Cryptoki versione 1.0 originale. L'ordine di questi due argomenti ha causato una spiacevole confusione.

    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> Modello = 8;
    }
    message DeriveKeyResponse {
        byte NewKeyByte = 6;
        bytes CheckSum = 7;
    }
    

Implementazione di C_DeriveKey PKCS #11.

Il blob basekey,bklen deve essere associato dal parametro hBaseKey PKCS #11

hSession PKCS #11 non è associata ad alcun parametro EP11. (La chiamata non è direttamente associata ad alcuna sessione).

phKey PKCS #11 non è associata ad alcun parametro EP11. (La libreria host deve associare la chiave restituita al bundle).

    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,
        destinazione_t
    );
    

C_DeriveKey deriva una chiave da una chiave di base, creando un nuovo oggetto chiave. hSession è l'handle della sessione; pMechanism punta a una struttura che specifica il chanismo di derivazione della chiave; hBaseKey è l'handle della chiave di base; pTemplate punta al modello per la nuova chiave; ulAttributeCount è il numero di attributi nel template; e phKey punta alla posizione che riceve l'handle della chiave derivata.

I valori degli attributi CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLEe KA_NEVER_EXTRACTABLE per la chiave di base influiscono sui valori che questi attributi possono contenere per la chiave appena derivata. Consultare la descrizione di ogni particolare meccanismo di derivazione chiave nella Sezione 5.16.2 della specifica API PKCS #11 per eventuali vincoli di questo tipo.

Se una chiamata a C_DeriveKey non è in grado di supportare il modello preciso fornito, ha esito negativo e viene restituita senza creare alcun oggetto chiave.

L'oggetto chiave creato da una chiamata riuscita a C_DeriveKey ha l'attributo CKA_LOCAL impostato su CK_FALSE.

    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,
        destinazione_t
    );
    

C_WrapKey esegue il wrapping (cifratura) di una chiave privata o segreta. hSession è l'handle della sessione; pMechanism punta al meccanismo di impacchettamento; hWrappingKey è l'handle della chiave di impacchettamento; hKey è l'handle della chiave da impacchettare; pWrappedKey punta all'ubicazione che riceve la chiave impacchettata; e pulWrappedKeyLen punta all'ubicazione che riceve la lunghezza della chiave impacchettata.

C_WrapKey utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione di output.

L'attributo CKA_WRAP della chiave di impacchettamento, che indica se la chiave supporta l'impacchettamento, deve essere CK_TRUE. L'attributo CKA_EXTRACTABLE della chiave da impacchettare deve anche essere CK_TRUE.

Se la chiave da impacchettare non può essere impacchettata da per qualche motivo specifico del token, nonostante abbia il suo attributo CKA_EXTRACTABLE impostato su CK_TRUE, C_WrapKey non riesce con il codice di errore CKR_KEY_NOT_WRAPPABLE. Se non può essere impacchettata con la chiave e il meccanismo di impacchettamento specificati solo a causa della sua lunghezza, C_WrapKey non riesce con il codice di errore CKR_KEY_SIZE_RANGE.

C_WrapKey può essere utilizzata nelle seguenti situazioni:

• Per impacchettare qualsiasi chiave segreta con una chiave pubblica che supporta la crittografia e la decrittografia.
• Per impacchettare qualsiasi chiave segreta con qualsiasi altra chiave segreta. È necessario considerare la dimensione della chiave e l'intensità del meccanismo oppure il token potrebbe non consentire l'operazione.
• Per impacchettare una chiave privata con qualsiasi chiave segreta.

I token variano in base a quali tipi di chiavi possono essere impacchettati con quali meccanismi.

Per partizionare le chiavi di impacchettamento in modo che possano impacchettare solo un sottoinsieme di chiavi estraibili, è possibile utilizzare l'attributo CKA_WRAP_TEMPLATE sulla chiave di impacchettamento per specificare una serie di attributi che è possibile confrontare con gli attributi della chiave da impacchettare. Se tutti gli attributi corrispondono in base alle regole C_FindObject di corrispondenza degli attributi, l'operazione di impacchettamento procede. Il valore di questo attributo è un template di attributi e la dimensione è il numero di elementi nel template moltiplicato per la dimensione di CK_ATTRIBUTE. Se questo attributo non viene fornito, qualsiasi modello è accettabile. Se un attributo non è presente, non viene selezionato. Se si verifica una mancata corrispondenza di attributi durante un tentativo di impacchettamento di una chiave, la funzione restituisce 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> Modello = 9;
    }
    message UnwrapKeyResponse {
        byte UnwrappedBytes = 7;
        bytes CheckSum = 8;
    }
    

Implementazione di C_UnwrapKey PKCS #11.

uwmech specifica il meccanismo di codifica utilizzato per decodificare i dati impacchettati. ptempl è un elenco di parametri key (pair) che specifica come trasformare i dati non impacchettati in una nuova chiave (deve includere CKA_KEY_TYPE).

L'oggetto generato viene restituito in (unwrapped, uwlen) come un blob. Le chiavi simmetriche restituiscono il loro checksum di chiavi (3 byte) in (csum, cslen); gli oggetti di chiave pubblica restituiscono la loro chiave pubblica come una SPKI in (csum, cslen). Entrambe le forme sono seguite da un valore big-endian di 4 byte, che codifica il conteggio di bit della chiave spacchettata.

Quando un SPKI viene trasformato in un SPKI MACed, è necessario utilizzare CKM_IBM_TRANSPORTKEY come meccanismo di unwrapping. Questa modalità fornisce la SPKI non elaborata come dati impacchettati, e ignora la KEK.

UnwrapKey produce chiavi DES corrette per la parità (all'interno dei blob), ma tollera l'immissione con parità non corretta.

    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,
        destinazione_t
    );
    

C_UnwrapKey esegue l'unwrapping (ossia, la decodifica) di una chiave impacchettata, creando una nuova chiave privata o un nuovo oggetto chiave segreta. hSession è l'handle della sessione; pMechanism punta al meccanismo di spacchettamento; hUnwrappingKey è l'handle della chiave di spacchettamento; pWrappedKey punta alla chiave impacchettata; ulWrappedKeyLen è la lunghezza della chiave impacchettata; pTemplate punta al modello per la nuova chiave; ulAttributeConteggio è il numero di attributi nel modello; phKey punta all'ubicazione che riceve l'handle della chiave recuperata.

L'attributo CKA_UNWRAP della chiave di spacchettamento, che indica che se la chiave supporta lo spacchettamento, deve essere CK_TRUE.

La nuova chiave ha l'attributo CKA_ALWAYS_SENSITIVE impostato su CK_FALSEe l'attributo CKA_NEVER_EXTRACTABLE impostato su CK_FALSE. L'attributo CKA_EXTRACTABLE è per impostazione predefinita impostato su CK_TRUE.

Alcuni meccanismi possono modificare o tentare di modificare. Il contenuto della struttura pMechanism nello stesso momento in cui la chiave viene annullata.

Se una chiamata a C_UnwrapKey non può supportare il modello preciso fornito, ha esito negativo e viene restituita senza creare alcun oggetto chiave.

L'oggetto chiave creato da una chiamata riuscita a C_UnwrapKey ha il suo attributo CKA_LOCAL impostato su CK_FALSE.

Per partizionare le chiavi di spacchettamento in modo che possano spacchettare solo un sottoinsieme di chiavi, è possibile utilizzare l'attributo CKA_UNWRAP_TEMPLATE sulla chiave di spacchettamento per specificare una serie di attributi che viene aggiunta agli attributi della chiave da spacchettare. Se gli attributi non sono in conflitto con il modello di attributo fornito dall'utente, in pTemplate, l'operazione di spacchettamento procede. Il valore di questo attributo è un template di attributi e la dimensione è il numero di elementi nel template moltiplicato per la dimensione di CK_ATTRIBUTE. Se questo attributo non è presente nella chiave di spacchettamento, non vengono aggiunti ulteriori attributi. Se si verifica un conflitto di attributi durante un tentativo di spacchettamento di una chiave, la funzione SHALL restituisce CKR_TEMPLATE_INCONGRUENTE.

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

    messaggio RewrapKeyBlobRequest {
    	byte WrappedKey = 1;
    }
    messaggio RewrapKeyBlobResponse {
    	byte RewrappedKey = 1;
    }
    

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

Implementazione di C_GetAttributeValue PKCS #11.

Non rappresenta o ha bisogno di sessioni (parte di blob), quindi non utilizza il parametro hSession .

EP11 utilizza modi più semplici per eseguire la decodifica, come ad esempio l'enumerazione di valori effettivi, invece di essere più generica.

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

C_GetAttributeValue ottiene il valore di uno o più attributi di un oggetto. hSession è l'handle della sessione; hObject è l'handle dell'oggetto; pTemplate punta a un modello che specifica quali valori attributo devono essere ottenuti e riceve i valori attributo; ulCount è il numero degli attributi nel modello.

Per ogni tripla (type, pValue, ulValueLen) nel template, C_GetAttributeValue esegue questo algoritmo:

1. Se l'attributo specificato (ovvero, l'attributo specificato dal campo tipo) per l'oggetto non può essere rivelato perché l'oggetto è sensibile o non estraibile, il campo ulValueLen in tale tripla viene modificato per contenere il valore CK_UNAVAILABLE_INFORMATION.
2. Altrimenti, se il valore specificato per l'oggetto non è valido (l'oggetto non possiede tale attributo), il campo ulValueLen in tale tripla viene modificato per contenere il valore CK_UNAVAILABLE_INFORMATION.
3. Altrimenti, se il campo pValue ha il valore NULL_PTR, il campo ulValueLen viene modificato per contenere la lunghezza esatta dell'attributo specificato per l'oggetto.
4. In caso contrario, se la lunghezza specificata in ulValueLen è abbastanza grande da contenere il valore dell'attributo specificato per l'oggetto, tale attributo viene copiato nel buffer che si trova in pValuee il campo ulValueLen viene modificato per contenere la lunghezza esatta dell'attributo.
5. Altrimenti, il campo ulValueLen viene modificato per contenere il valore CK_UNAVAILABLE_INFORMATION.

Se il caso 1 si applica a uno qualsiasi degli attributi richiesti, la chiamata deve restituire il valore CKR_ATTRIBUTE_SENSITIVE. Se il caso 2 si applica ad uno qualsiasi degli attributi richiesti, la chiamata deve restituire il valore CKR_ATTRIBUTE_TYPE_INVALID. Se il caso 5 si applica a uno qualsiasi degli attributi richiesti, la chiamata deve restituire il valore CKR_BUFFER_TOO_SMALL. Come al solito, se è applicabile più di uno di questi codici di errore, Cryptoki può restituire uno qualsiasi di essi. Solo se nessuno di essi si applica a uno degli attributi richiesti, viene restituito CKR_OK .

Nel caso speciale di un attributo il cui valore è un array di attributi, ad esempio CKA_WRAP_TEMPLATE, dove viene passato con pValue not NULL, se pValue degli elementi all'interno dell'array è NULL_PTR, ulValueLen degli elementi all'interno dell'array è impostato sulla lunghezza richiesta. Se il pValue degli elementi all'interno dell'array non è NULL_PTR, l'elemento ulValueLen degli attributi all'interno dell'array deve riflettere lo spazio a cui punta il corrispondente pValue e il pValue viene inserito se c'è spazio a sufficienza. Pertanto, è importante inizializzare il contenuto di un buffer prima che C_GetAttributeValue venga richiamato per ottenere tale valore di array. Se un ulValueLen all'interno dell'array non è sufficientemente grande, viene impostato su CK_UNAVAILABLE_INFORMATION e la funzione restituisce CKR_BUFFER_TOO_SMALL, come se un attributo nell'argomento pTemplate avesse ulValueLen troppo piccolo. Qualsiasi attributo il cui valore è un array di attributi è identificabile dalla serie CKF_ARRAY_ATTRIBUTE del tipo di attributo.

I codici di errore CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALIDe CKR_BUFFER_TOO_SMALL non indicano errori veri per C_GetAttributeValue. Se una chiamata a C_GetAttributeValue restituisce uno di questi tre valori, la chiamata deve comunque aver elaborato ogni attributo nel template fornito a C_GetAttributeValue. Ogni attributo nel modello il cui valore può essere restituito dalla chiamata a C_GetAttributeValue viene restituito dalla chiamata 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> Attributi = 3;
    }
    message SetAttributeValueResponse {
        bytes Object = 1;
    }
    

Implementazione di C_SetAttributeValue PKCS #11.

impacchettamento di attributo: vedi _GetAttrValue

Attualmente, EP11 invia solo attributi booleani; tutti gli altri attributi sono gestiti dall'host (e EP11 non modifica gli array, come ad esempio WRAP_TEMPLATE).

Non rappresenta o necessita di sessioni (parte di blob), quindi non utilizza il parametro PKCS #11 hSession .

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

C_SetAttributeValue modifica il valore di uno o più attributi di un oggetto. hSession è l'handle della sessione; hObject è l'handle dell'oggetto; pTemplate punta a un template che specifica quali valori di attributi devono essere modificati e i nuovi valori; ulCount è il numero di attributi nel modello.

Alcuni oggetti potrebbero non essere modificati. Il richiamo di C_SetAttributeValue su tali oggetti risulta nel codice di errore CKR_ACTION_PROIBITA . Un'applicazione può consultare l'attributo CKA_MODIFIABLE dell'oggetto per determinare se un oggetto può essere modificato.

Solo gli oggetti di sessione possono essere modificati durante una sessione di sola lettura.

Il modello può specificare nuovi valori per qualsiasi attributo dell'oggetto che può essere modificato. Se il modello specifica un valore di un attributo che non è compatibile con altri attributi esistenti dell'oggetto, la chiamata ha esito negativo con il codice di ritorno CKR_TEMPLATE_CONSISTENTI.

Non è possibile modificare tutti gli attributi; per ulteriori informazioni, consultare la sezione 4.1.2 della specifica API PKCS #11 .

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

Implementazione di C_GenerateRandom PKCS #11.

GenerateRandom è equivalente alla funzione PKCS #11 originale. Internamente, l'entropia con seeding hardware viene passata tramite una DRNG (ANSI X9.31/ISO 18031 conforme a FIPS, a seconda della versione Clic).

La libreria host può generare dei numeri casuali senza distribuzione al backend, in caso di disponibilità sull'host di funzionalità adatta. Nell'attuale implementazione, tale operazione non viene eseguita.

Questa funzione non supporta una query di dimensione.

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

Implementazione di C_EncryptInit PKCS #11.

Il blob (key, klen) può essere un oggetto chiave pubblica o un blob chiave segreta. Il tipo di chiave deve essere congruente con pmech.

Per i meccanismi a chiave pubblica, (key, klen) deve contenere una SPKI. L'integrità di questa SPKI è protetta con una chiave MAC, come restituita da GenerateKeyPair o in alternativa UnwrapKey. Lo stato Ecrypt viene creato senza restrizioni della sessione.

Per i meccanismi della chiave segreta, lo stato Codifica eredita le limitazioni della sessione oggetto da (key, klen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

(key, klen) deve essere un blob chiave.

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

C_EncryptInit inizializza un'operazione di codifica. hSession è l'handle della sessione; pMechanism punta al meccanismo di codifica; hKey è l'handle della chiave di crittografia.

L'attributo CKA_ENCRYPT della chiave di crittografia, che indica se la chiave supporta la crittografia, deve essere CK_TRUE.

Dopo che l'applicazione ha richiamato C_EncryptInit, l'applicazione può richiamare C_Encrypt per crittografare i dati in una singola parte; oppure richiamare C_EncryptUpdate zero o più volte, seguito da C_EncryptFinal, per crittografare i dati in più parti. L'operazione di crittografia è attiva fino a quando l'applicazione non utilizza una chiamata a C_Encrypt o C_EncryptFinal per ottenere la parte finale del testo cifrato. Per elaborare ulteriori dati (in una o più parti), l'applicazione deve richiamare nuovamente 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;
    }
    

Implementazione di C_Encrypt PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_Encrypt codifica i dati di una singola parte. hSession è l'handle della sessione; pData punta ai dati; ulDataLen è la lunghezza in byte dei dati; pEncryptedData punta all'ubicazione che riceve i dati codificati; pulEncryptedDataLen punta all'ubicazione che contiene la lunghezza in byte dei dati codificati.

C_Encrypt utilizza la convenzione descritta nella Sezione 5.2 della specifica API PKCS #11 sulla produzione di output.

L'operazione di codifica deve essere inizializzata con C_EncryptInit. Una chiamata a C_Encrypt termina sempre l'operazione di codifica attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una chiamata che restituisce CKR_OK) per determinare la lunghezza del buffer necessario per contenere il testo cifrato.

C_Encrypt non può essere utilizzata per terminare un'operazione in più parti e deve essere richiamata dopo C_EncryptInit senza chiamate C_EncryptUpdate intermedie.

Per alcuni meccanismi di crittografia, i dati di input in testo semplice hanno determinati vincoli di lunghezza (perché il meccanismo può crittografare solo parti relativamente brevi di testo semplice, o perché i dati di input del meccanismo devono essere costituiti da un numero integrale di blocchi). Se questi vincoli non vengono soddisfatti, C_Encrypt ha esito negativo con codice di ritorno CKR_DATA_LEN_RANGE.

Il testo semplice e il testo cifrato possono trovarsi nella stessa posizione, vale a dire, se pData e pEncryptedData puntano alla stessa ubicazione.

Per la maggior parte dei meccanismi, C_Encrypt è equivalente a una sequenza di operazioni C_EncryptUpdate seguita da 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;
    }
    

Implementazione di C_EncryptUpdate PKCS #11.

Il blob state, slen deve essere associato dal parametro PKCS #11 hSession .

Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_EncryptUpdate continua un'operazione di codifica a più parti, elaborando un'altra parte di dati. hSession è la gestione della sessione; pPart punta alla parte dati; ulPartLen è la lunghezza della parte dati; pEncryptedPart punta alla posizione che riceve la parte dati codificati; pulEncryptedPartLen punta alla posizione che contiene la lunghezza in byte della parte dati codificati.

C_EncryptUpdate utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione di codifica deve essere inizializzata con C_EncryptInit. Questa funzione può essere chiamata un numero qualsiasi di volte in successione. Una chiamata a C_EncryptUpdate che produce un errore diverso da CKR_BUFFER_TOO_SMALL termina l'attuale operazione di crittografia.

Il testo semplice e il testo cifrato possono trovarsi nella stessa posizione, vale a dire, se pPart e pEncryptedPart puntano alla stessa posizione.

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

Implementazione di C_EncryptFinal PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

Il blob state veniva generato in output da: EncryptInit, EncryptUpdate.

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

C_EncryptFinal termina un'operazione di codifica a più parti. hSession è l'handle della sessione; pLastEncryptedPart punta alla posizione che riceve l'ultima parte di dati codificata, se presente; pulLastEncryptedPartLen punta alla posizione che contiene la lunghezza dell'ultima parte di dati codificati.

C_EncryptFinal utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione di output.

L'operazione di codifica deve essere inizializzata con C_EncryptInit. Una chiamata a C_EncryptFinal termina sempre l'operazione di codifica attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una che restituisce CKR_OK) per determinare la lunghezza del buffer necessaria per contenere il testo cifrato.

Per alcuni meccanismi di crittografia multi - parte, i dati di testo semplice di input hanno alcuni vincoli di lunghezza perché i dati di immissione del meccanismo devono essere costituiti da un numero integrale di blocchi. Se questi vincoli non vengono soddisfatti, C_EncryptFinal ha esito negativo con codice di ritorno 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 non standard di Encrypt. Elabora i dati in un singolo passaggio, con una singola chiamata. Non restituisce alcuno stato all'host, solo i dati crittografati.

Questo è il metodo preferito per crittografare i dati in un singolo passaggio per le applicazioni in grado di riconoscere XCP. Funzionalmente è equivalente a EncryptInit seguito immediatamente da Encrypt, ma salva roundtrip, wrapping e unwrapping.

Se il backend supporta le chiavi residenti, la chiave può essere anche un handle di chiave residente.

Vedi anche: Encrypt, EncryptInit, DecryptSingle.

Il blob key veniva generato in output da: 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,
        destinazione_t
    );
    

    Richiesta ReencryptSinglemessaggio {
        byte DecKey = 1;
        byte EncKey = 2;
        Meccanismo DecMech = 3;
        Meccanismo EncMech = 4;
        byte cifrati = 5;
    }
    messaggio ReencryptSingleRisposta {
        byte cifrati = 6;
    }
    

Variante non standard di Encrypt. Elabora i dati in un singolo passaggio, con una singola chiamata. Non restituisce alcun stato all'host, solo i dati ricodificati.

Decodifica i dati con la chiave originale e quindi crittografa i dati non elaborati con una chiave diversa all'interno del cloud HSM.

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey, size_t dkeylen,
        const unsigned char * ekey, size_t ekeylen,
        CK_MECHANISM_PTR decmech,
        Mech CK_MECHANISM_PTR,
        CK_BYTE_PTR in, CK_ULONG inlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        destinazione_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,
        destinazione_t
    );
    

C_DecryptInit inizializza un'operazione di decodifica. hSession è l'handle della sessione; pMechanism punta al meccanismo di decodifica; hKey è l'handle della chiave di decodifica.

L'attributo CKA_DECRYPT della chiave di decrittografia, che indica se la chiave supporta la decrittografia, deve essere CK_TRUE.

Dopo che l'applicazione ha richiamato C_DecryptInit, l'applicazione può richiamare C_Decrypt per decodificare i dati in una singola parte oppure richiamare C_DecryptUpdate zero o più volte, seguito da C_DecryptFinal, per decodificare i dati in più parti. L'operazione di decodifica è attiva fino a quando l'applicazione non utilizza una chiamata a C_Decrypt o C_DecryptFinal per ottenere la parte finale del testo in chiaro. Per elaborare ulteriori dati (in una o più parti), l'applicazione deve richiamare nuovamente 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;
    }
    

Implementazione di PKCS #11 C_Decrypt. Non aggiorna (state, slen).

IL BLOB (binary large object) state, slen deve essere associato dal parametro hSession PKCS #11. Il BLOB state veniva generato in output da 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,
        destinazione_t
    );
    

C_Decrypt decrittografa i dati crittografati in una singola parte.

• hSession è l'handle di sessione.
• pEncryptedData punta ai dati crittografati.
• ulEncryptedDataLen è la lunghezza dei dati crittografati.
• pData punta all'ubicazione che riceve i dati ripristinati.
• pulDataLen punta all'ubicazione che conserva la lunghezza dei dati ripristinati.

C_Decrypt utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione di output.

L'operazione di decodifica deve essere inizializzata con C_DecryptInit. Una chiamata a C_Decrypt termina sempre l'operazione di decodifica attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o non sia una chiamata riuscita con CKR_OK restituito per determinare la lunghezza del buffer necessario per contenere il testo semplice.

C_Decrypt non può essere utilizzato per terminare un'operazione a più parti e deve essere richiamato dopo C_DecryptInit senza intervenire sulle chiamate C_DecryptUpdate .

Il testo cifrato e il testo semplice possono essere nella stessa posizione, il che significa che è accettabile se i dati pEncryptede pData puntano alla stessa ubicazione.

Se i dati del testo cifrato di input non possono essere decrittografati perché hanno una lunghezza inappropriata, possono essere restituiti 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;
    }
    

Implementazione di C_DecryptUpdate PKCS #11.

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_DecryptUpdate continua un'operazione di decodifica di più parti, elaborando un'altra parte di dati codificati. hSession è l'handle della sessione; pEncryptedPart punta alla parte di dati codificati; ulEncryptedPartLen è la lunghezza della parte di dati codificati; pPart punta alla posizione che riceve la parte di dati ripristinata; pulPartLen punta alla posizione che contiene la lunghezza della parte di dati ripristinati.

C_DecryptUpdate utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione di decodifica deve essere inizializzata con C_DecryptInit. Questa funzione può essere chiamata un numero qualsiasi di volte in successione. Una chiamata a C_DecryptUpdate che produce un errore diverso da CKR_BUFFER_TOO_SMALL termina l'attuale operazione di decrittografia.

Il testo cifrato e il testo semplice possono trovarsi nella stessa posizione, vale a dire, è corretto se pEncryptedPart e pPart puntano alla stessa posizione.

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

Implementazione di C_DecryptFinal PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

Il blob state veniva generato in output da: DecryptInit, DecryptUpdate.

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

C_DecryptFinal termina un'operazione di decodifica di più parti. hSession è l'handle della sessione; pLastPart punta all'ubicazione che riceve l'ultima parte di dati ripristinata, se presente; pulLastPartLen punta all'ubicazione che contiene la lunghezza dell'ultima parte di dati ripristinata.

C_DecryptFinal utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione di decodifica deve essere inizializzata con C_DecryptInit. Una chiamata a C_DecryptFinal termina sempre l'operazione di decodifica attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una chiamata che restituisce CKR_OK) per determinare la lunghezza del buffer necessaria per contenere il testo semplice.

Se i dati del testo cifrato di input non possono essere decodificati perché hanno una lunghezza inappropriata, è possibile restituire 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 non standard di Decrypt. Elabora i dati in un singolo passaggio, con una singola chiamata. Non restituisce alcuno stato all'host, solo i dati decrittografati.

Questo è il metodo preferito per crittografare i dati in un singolo passaggio per le applicazioni in grado di riconoscere XCP. Funzionalmente è equivalente a DecryptInit seguito immediatamente da Decrypt, ma salva i viaggi di andata e ritorno a capo, e lo spacchettamento.

Se il backend supporta le chiavi residenti, la chiave può essere anche un handle di chiave residente.

Vedi anche: Decrypt, DecryptInit, EncryptSingle.

Il blob key veniva generato in output da: 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,
        destinazione_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,
        destinazione_t
    );
    

C_SignInit inizializza un'operazione di firma, dove la firma è un'appendice ai dati. hSession è l'handle della sessione; pMechanism punta al meccanismo di firma; hKey è l'handle della chiave di firma.

L'attributo CKA_SIGN della chiave di firma, che indica se la chiave supporta le firme con l'appendice, deve essere CK_TRUE.

Dopo che l'applicazione ha richiamato C_SignInit, può richiamare C_Sign per accedere a una singola parte oppure C_SignUpdate una o più volte, seguito da C_SignFinal, per firmare i dati in più parti. L'operazione di firma è attiva fino a quando l'applicazione non utilizza una chiamata a C_Sign o a C_SignFinal per ottenere la firma. Per elaborare ulteriori dati (in una o più parti), l'applicazione deve richiamare nuovamente 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;
    }
    

Implementazione di C_Sign PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_Sign firma i dati in una singola parte, dove la firma è un'appendice ai dati. hSession è la gestione della sessione; pData punta ai dati; ulDataLen è la lunghezza dei dati; pSignature punta all'ubicazione che riceve la firma; pulSignatureLen punta alla posizione che contiene la lunghezza della firma.

C_Sign utilizza la convenzione descritta nella Sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione di firma deve essere inizializzata con C_SignInit. Una chiamata a C_Sign termina sempre l'operazione di firma attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una che restituisce CKR_OK) per determinare la lunghezza del buffer necessario per conservare la firma.

C_Sign non può essere utilizzata per terminare un'operazione in più parti e deve essere richiamata dopo C_SignInit senza chiamate C_SignUpdate intermedie.

Per la maggior parte dei meccanismi, C_Sign è equivalente a una sequenza di operazioni C_SignUpdate seguita da 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;
    }
    

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: SignInit.

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

C_SignUpdate continua un'operazione di firma a più parti, elaborando un'altra parte di dati. hSession è l'handle della sessione, pPart punta alla parte di dati; ulPartLen è la lunghezza della parte di dati.

L'operazione di firma deve essere inizializzata con C_SignInit. Questa funzione può essere chiamata un numero qualsiasi di volte in successione. Una chiamata C_SignUpdate che produce un errore termina l'attuale operazione di firma.

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

Implementazione di C_SignFinal PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: SignInit, SignUpdate.

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

C_SignFinal termina un'operazione di firma a più parti, restituendo la firma. hSession è l'handle della sessione; pSignature punta all'ubicazione che riceve la firma; pulSignatureLen punta all'ubicazione che contiene la lunghezza della firma.

C_SignFinal utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione di output.

L'operazione di firma deve essere inizializzata con C_SignInit. Una chiamata a C_SignFinal termina sempre l'operazione di firma attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una che restituisce CKR_OK) per determinare la lunghezza del buffer necessario per conservare 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;
    }
    

Estensione non standard, combinazione di SignInit e Sign. Firma o protegge con una chiave MAC i dati in un singolo passaggio, con una singola chiamata, senza creare uno stato di digest intermedio. Non restituisce alcuno stato all'host, solo il risultato.

Questo è il modo preferito di firma, senza un ulteriore roundtrip, crittografia e decrittografia. Funzionalmente, SignSingle è equivalente a SignInit seguita immediatamente da Sign.

Il blob (key, klen) e il meccanismo pmech insieme devono essere passabili a SignInit.

Sono supportate le richieste multi - dati per le firme HMAC e CMAC (sottovariante 2 e 3).

Vedi anche: 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,
        destinazione_t
    );
    

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

Implementazione di C_VerifyInit PKCS #11. Dato un blob chiave (key, klen), inizializza uno stato di verifica della sessione in (state, slen). Il blob chiave può essere un oggetto chiave pubblica o byte chiave HMAC. Il tipo di blob chiave deve essere congruente con pmech.

Per i meccanismi a chiave pubblica, (key, klen) deve contenere una SPKI. Questo SPKI CKA_UNWRAP può essere MACed (come restituito in precedenza dalla coppia GenerateKeyPair) o solo lo stesso SPKI (se ottenuto da un'origine esterna, come un certificato).

Se viene inizializzata un'operazione HMAC, le limitazioni di sessione dell'oggetto Verifica vengono ereditate dalla chiave HMAC. Poiché le SPKI non sono collegate alle sessioni, gli stati Verify di chiave pubblica sono senza sessione.

Il blob key,klen deve essere associato dal parametro hKey PKCS #11

Nota: SignInit e VerifyInit sono internamente i lo stesso per HMAC e altri meccanismi simmetrici / MAC.

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

C_VerifyInit inizializza un'operazione di verifica, in cui la firma è un'appendice ai dati. hSession è l'handle della sessione; pMechanism punta alla struttura che specifica il meccanismo di verifica; hKey è l'handle della chiave di verifica.

L'attributo CKA_VERIFY della chiave di verifica, che indica se la chiave supporta la verifica dove la firma è un'appendice ai dati, deve essere CK_TRUE.

Dopo che l'applicazione ha richiamato C_VerifyInit, l'applicazione può richiamare C_Verify per verificare una firma sui dati in una singola parte; oppure richiamare C_VerifyUpdate una o più volte, seguito da C_VerifyFinal, per verificare una firma sui dati in più parti. L'operazione di verifica è attiva finché l'applicazione non richiama C_Verify o C_VerifyFinal. Per elaborare dati supplementari (in una o più parti), l'applicazione deve richiamare nuovamente 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 {
    }
    

Implementazione di C_Verify PKCS #11.

Non aggiorna (state, slen).

L'ordine relativo dei dati e della firma sono invertiti in VerifySingle.

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_Verify verifica una firma in un'operazione a parte singola, dove la firma è un'appendice ai dati. hSession è la gestione della sessione; pData punta ai dati; ulDataLen è la lunghezza dei dati; pSignature punta alla firma; ulSignatureLen è la lunghezza della firma.

L'operazione di verifica deve essere inizializzata con C_VerifyInit. Una chiamata a C_Verify termina sempre l'operazione di verifica attiva.

Una chiamata eseguita correttamente a C_Verify deve restituire il valore CKR_OK (che indica che la firma fornita è valida) o CKR_SIGNATURE_INVALID (che indica che la firma fornita non è valida). Se la firma non è valida esclusivamente in base alla sua lunghezza, è necessario restituire CKR_SIGNATURE_LEN_RANGE . In uno qualsiasi di questi casi, l'operazione di firma attiva viene terminata.

C_Verify non può essere utilizzata per terminare un'operazione in più parti e deve essere richiamata dopo C_VerifyInit senza chiamate C_VerifyUpdate intermedie.

Per la maggior parte dei meccanismi, C_Verify è equivalente a una sequenza di operazioni C_VerifyUpdate seguita da 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;
    }
    

Implementazione di C_VerifyUpdate PKCS #11.

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: VerifyInit.

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

C_VerifyUpdate continua un'operazione di verifica di più parti, elaborando un'altra parte di dati. hSession è la gestione della sessione, pPart punta alla parte di dati; ulPartLunghezza è la lunghezza della parte di dati.

L'operazione di verifica deve essere inizializzata con C_VerifyInit. Questa funzione può essere chiamata un numero qualsiasi di volte in successione. Una chiamata a C_VerifyUpdate che causa un errore termina l'operazione di verifica corrente.

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

Implementazione di C_VerifyFinal PKCS #11.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: VerifyInit, VerifyUpdate.

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

C_VerifyFinal termina un'operazione di verifica di più parti, controllando la firma. hSession è l'handle della sessione; pSignature punta alla firma; ulSignatureLen è la lunghezza della firma.

L'operazione di verifica deve essere inizializzata con C_VerifyInit. Una chiamata a C_VerifyFinal termina sempre l'operazione di verifica attiva.

Una chiamata eseguita correttamente a C_VerifyFinal deve restituire il valore CKR_OK (che indica che la firma fornita è valida) o CKR_SIGNATURE_INVALID (che indica che la firma fornita non è valida). Se la firma non è valida in base alla sua lunghezza, è necessario restituire CKR_SIGNATURE_LEN_RANGE . In uno qualsiasi di questi casi, l'operazione di verifica attiva viene terminata.

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

Estensione non standard, combinazione di VerifyInit e Verify. Firma o protegge con una chiave MAC i dati in un singolo passaggio, con una singola chiamata, senza creare uno stato di digest intermedio. Non restituisce alcuno stato all'host, fatta eccezione per il risultato della verifica. Nessuna query di dimensione disponibile perché questa funzione restituisce un valore booleano.

Questo è il modo preferito di verificare una firma, senza un ulteriore roundtrip, crittografia, decrittografia. Funzionalmente, VerifySingle è equivalente a VerifyInit seguita immediatamente da una Verify.

Il blob (key, klen) e il meccanismo pmech insieme devono essere passabili a VerifyInit.

Per i meccanismi a chiave pubblica, (key, klen) deve contenere una SPKI. Questo SPKI può essere MACed (come ad esempio restituito come una chiave pubblica da GenerateKeyPair) o solo lo stesso SPKI (se ottenuto da un'origine esterna, come ad esempio un certificato).

Vedi anche: 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,
        destinazione_t
    );
    

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

Implementazione di C_DigestInit PKCS #11.

Crea uno stato di digest impacchettato.

Nota: le query di dimensione sono supportate ma lo stato impacchettato viene sempre restituito dal backend, a differenza della maggior parte delle query di dimensione (che restituiscono una dimensione di output, invece dell'output effettivo). Gli stati Digest sono sufficientemente piccoli da non introdurre un sovraccarico rilevante del trasporto.

Durante le query di dimensione, l'host semplicemente scarta lo stato restituito e notifica la dimensione di blob (in len). Quando viene restituito blob, len viene controllato rispetto alla dimensione restituita.

Il blob state,len deve essere associato dal parametro hSession PKCS #11. (La libreria host deve collegare il blob alla sessione).

    CK_RV m_DigestInit (
        unsigned char * state, siz_t * len,
        const CK_MECHANISM_PTR mech,
        destinazione_t
    );
    

C_DigestInit inizializza un'operazione di digest del messaggio. hSession è l'handle della sessione; pMechanism punta al meccanismo di digestione.

Dopo che l'applicazione ha richiamato C_DigestInit, l'applicazione può richiamare C_Digest per digest i dati in una singola parte oppure richiamare C_DigestUpdate zero o più volte, seguito da C_DigestFinal, per digest i dati in più parti. L'operazione di digest del messaggio è attiva finché l'applicazione non utilizza una chiamata a C_Digest o C_DigestFinal per ottenere il digest del messaggio. Per elaborare ulteriori dati (in una o più parti), l'applicazione deve richiamare nuovamente 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;
    }
    

Implementazione di C_Digest PKCS #11.

Se un oggetto digest ha esattamente 0 (zero) byte che vengono accodati ad esso dopo la creazione, in qualsiasi combinazione di trasferimenti zero - byte, può ancora eseguire un Digest one - pass, anche se deve essere rifiutato da un'implementazione rigorosa.

Non aggiorna (state, slen).

Le implementazioni potrebbero essere eseguite DigestUpdate, DigestFinalo Digest richiama oggetti digest in testo non codificato nel codice host, ignorando completamente i backend HSM. Questa scelta potrebbe essere visibile o meno al codice host e non influisce sulla sicurezza dell'operazione (poiché gli oggetti di eliminazione potrebbero non digest i dati sensibili).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. Il blob state veniva generato in output da: 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,
        destinazione_t
    );
    

C_Digest esegue il digest dei dati in una singola parte. hSession è l'handle della sessione, pData punta ai dati; ulDataLen è la lunghezza dei dati; pDigest punta all'ubicazione che riceve il messaggio digest; pulDigestLen punta all'ubicazione che contiene la lunghezza del messaggio digest.

C_Digest utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione digest deve essere inizializzata con C_DigestInit. Una chiamata a C_Digest termina sempre l'operazione digest attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una che restituisce CKR_OK) per determinare la lunghezza del buffer necessario per conservare il digest del messaggio.

C_Digest non può essere utilizzata per terminare un'operazione in più parti e deve essere richiamata dopo C_DigestInit senza chiamate C_DigestUpdate intermedie.

I dati di input e l'output del digest possono essere nello stesso posto, vale a dire, è OK se pData e pDigest puntano alla stessa ubicazione.

C_Digest è equivalente a una sequenza di operazioni C_DigestUpdate seguita da 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;
    }
    

Implementazione di C_DigestUpdate PKCS #11.

DigestUpdate è polimorfico, accettare entrambi gli oggetti digest con o senza ritorno a capo, aggiornando lo stato nello stesso formato.

Il blob state,slen deve essere associato dal parametro hSession PKCS #11. (La libreria host deve associare la sessione allo stato archiviato).

Il blob state veniva generato in output da: DigestInit, DigestUpdate, DigestKey.

Vedi anche: DigestInit

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

C_DigestUpdate continua un'operazione di digest di più parti, elaborando un'altra parte di dati. hSession è l'handle della sessione, pPart punta alla parte di dati; ulPartLen è la lunghezza della parte di dati.

L'operazione di digest del messaggio deve essere inizializzata con C_DigestInit. Le chiamate a questa funzione e C_DigestKey possono essere intervallate un numero qualsiasi di volte in qualsiasi ordine. Una chiamata C_DigestUpdate che produce un errore termina l'attuale operazione di digest.

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

Implementazione di C_DigestFinal PKCS #11.

DigestFinal è polimorfico, che accetta sia oggetti digest in chiaro che impacchettati.

Non aggiorna (state, slen).

Il blob state,slen deve essere associato dal parametro hSession PKCS #11.

Il blob state veniva generato in output da: DigestInit, DigestUpdate, DigestKey.

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

C_DigestFinal termina un'operazione di digest del messaggio in più parti, restituendo il digest del messaggio. hSession è l'handle della sessione; pDigest punta all'ubicazione che riceve il digest del messaggio; pulDigestLen punta all'ubicazione che contiene la lunghezza del digest del messaggio.

C_DigestFinal utilizza la convenzione descritta nella sezione 5.2 della specifica API PKCS #11 sulla produzione dell'output.

L'operazione digest deve essere inizializzata con C_DigestInit. Una chiamata a C_DigestFinal termina sempre l'operazione digest attiva a meno che non restituisca CKR_BUFFER_TOO_SMALL o sia una chiamata riuscita (ovvero, una chiamata che restituisce CKR_OK) per stabilire la lunghezza del buffer necessaria per conservare il digest del messaggio.

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

Estensione non standard, combinazione di DigestInit e Digest. Esegue il digest dei dati in un singolo passaggio, senza creare uno stato di digest intermedio e roundtrip non necessari.

Questo è il metodo preferito di esecuzione di digest di testo non crittografato per le applicazioni in grado di riconoscere XCP. Funzionalmente, DigestSingle è equivalente a DigestInit seguita immediatamente da Digest.

Se deve essere eseguito il digest di una chiave, devi utilizzare DigestInit e DigestKey, poiché questa funzione non gestisce i blob di chiave.

Non restituisce alcuno stato all'host, fatta eccezione per il risultato del digest. Non ci sono parametri non PKCS #11 poiché tutto viene utilizzato direttamente dalla chiamata 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,
        destinazione_t
    );