Applicazione

Un'applicazione viene eseguita all'interno di un singolo spazio di indirizzo. Tutti i thread di controllo sono in esecuzione nell'applicazione. Un'applicazione diventa un'applicazione Cryptoki richiamando la funzione Cryptoki C_Initialize da uno dei thread. Una volta effettuata questa chiamata, l'applicazione può richiamare altre funzioni Cryptoki. Quando l'applicazione termina di utilizzare Cryptoki, richiama la funzione Cryptoki C_Finalize e cessa di essere un'applicazione Cryptoki.

Se si sta eseguendo un'applicazione Java PKCS #11 utilizzando il provider SunPKCS11 sulla piattaforma IBM Z (s390x), assicurarsi di utilizzare la JVM IBM Semeru più recente e specificare l'opzione -Xjit:noResumableTrapHandler Java quando si avvia l'applicazione. Puoi scaricare la versione s390x più recente di IBM Semeru JVM modificando il campo del filtro Architettura in s390x nella pagina IBM Semeru Runtime Downloads.

Utente

Lo standard PKCS #11 definisce due tipi di utenti per il login: un responsabile della riservatezza (SO) e un utente normale. Se un utente non accede utilizzando la funzione C_Login Cryptoki, l'utente è anche noto come utente anonimo. Solo l'utente normale può accedere agli oggetti privati sul token e tale accesso viene concesso solo dopo che l'utente normale viene autenticato. Nell'implementazione Hyper Protect Crypto Services PKCS #11 , i responsabili della protezione e gli utenti normali vengono autenticati dalle chiavi API. Sono supportati anche utenti anonimi. Per istruzioni sull'impostazione dei tipi di utente PKCS #11 , consultare Procedure ottimali per l'impostazione dei tipi di utente PKCS #11.

Sessione

L'API Cryptoki richiede che un'applicazione apra una o più sessioni con un token per ottenere l'accesso agli oggetti e alle funzioni del token. Una sessione fornisce una connessione logica tra l'applicazione e il token. Una sessione può essere una sessione di lettura/scrittura (R/W) o una sessione di sola lettura (R/O).

Per ottenere l'accesso agli oggetti privati del token, l'utente normale deve accedere ed è autenticato. Per un'analisi approfondita delle sessioni, consultare PKCS #11 Cryptographic Token Interface Usage Guide.

Oggetto chiave

Gli oggetti chiave sono memorizzati nel keystore in memoria che si trova con l'applicazione PKCS #11 o in un keystore supportato dal database. Se l'attributo CKA_TOKEN è impostato su true per l'oggetto chiave, l'oggetto chiave viene archiviato nel keystore supportato dal database. Altrimenti, l'oggetto chiave viene memorizzato nel keystore in memoria.

Gli oggetti chiave nel keystore in memoria non vengono ruotati automaticamente dopo la rotazione della chiave principale. Se i keystore PKCS #11 sono abilitati nella propria istanza del servizio, è necessario riavviare tutte le applicazioni PKCS #11 attive per cancellare il keystore in memoria una volta completata la rotazione della chiave principale.

Come mostrato nel seguente diagramma, un oggetto chiave PKCS #11 è un esempio di una classe oggetto PKCS #11 :

• Dati: un oggetto di dati è definito dall'applicazione.
• Certificati: un oggetto certificato memorizza un certificato.
• Chiavi: un oggetto chiave memorizza una chiave crittografica. La chiave può essere una chiave pubblica, una chiave privata o una chiave segreta. Ogni tipo di queste chiavi ha sottotipi da utilizzare in meccanismi specifici.
  • Chiave pubblica: il componente pubblico di una coppia di chiavi utilizzato da chiunque per crittografare i messaggi destinati a un particolare destinatario che ha accesso alla chiave privata della coppia di chiavi. La chiave pubblica viene utilizzata anche per verificare le firme create dalla chiave privata.
  • Chiave privata: il componente privato di una coppia di chiavi utilizzato per decodificare i messaggi. La chiave privata viene utilizzata anche per creare le firme.
  • Chiave segreta: una chiave segreta è un flusso generato di bit che viene utilizzato per codificare e decodificare i messaggi simmetricamente.

Cloud Identity and Access Management

IBM Cloud Identity and Access Management (IAM) fornisce l'autenticazione utente e il controllo dell'accesso per l'implementazione dell'API PKCS #11 . Utilizzando le chiavi API, la libreria PKCS #11 ottiene i token di connessione utilizzati per eseguire le chiamate API Cryptoki.

Questa implementazione di PKCS #11 equivale ad una chiave API con un PIN dell'utente. Per ulteriori informazioni sull'impostazione dell'ID servizio e della corrispondente chiave API, vedi Crea gli ID servizio per l'utente SO, l'utente normale e l'utente anonimo.

Servizio crittografico

Come parte del processo di iniziazione della libreria PKCS #11 , viene effettuata una connessione gRPC dalla libreria PKCS #11 a IBM Cloud. La connessione gRPC facilita la libreria PKCS #11 per richiamare funzioni Cryptoki, come C_Encrypt, C_Decrypt, C_Sign e C_Verify, che richiedono l'uso di HSM (Hardware Security Module).

Keystore

Sono disponibili due tipi principali di keystore:

• Keystore in memoria: memorizza temporaneamente gli oggetti chiave in memoria. Gli oggetti chiave memorizzati nel keystore in memoria sono noti anche come oggetti sessione. Gli oggetti sessione in una sessione specifica vengono eliminati quando si richiama la funzione C_CloseSession per quella sessione. Gli oggetti sessione in tutte le sessioni vengono eliminati dopo il richiamo della funzione C_Finalize.
• Keystore supportati dal database: memorizza gli oggetti chiave nei database. Gli oggetti chiave memorizzati nel keystore supportato dal database sono noti anche come oggetti token. Se il parametro sessionauth è abilitato e viene configurata una password per il keystore, il keystore supportato dal database viene codificato e autenticato. Per impostazione predefinita, il parametro sessionauth è disabilitato. Per ogni istanza del servizio sono supportati un massimo di cinque keystore autenticati. È possibile abilitare il parametro sessionauth per codificare le chiavi generate nel keystore o per decodificare la chiave prima di utilizzarla. La password può contenere da 6 a 8 caratteri.

Le password del keystore non sono memorizzate nell'istanza del servizio. L'amministratore del keystore è responsabile della gestione di una copia locale delle password. Se una password viene persa, è necessario contattare il team di supporto per reimpostare il keystore, il che significa che tutti i dati nel keystore vengono cancellati.

I keystore in memoria e i keystore supportati dal database sono composti dai seguenti tipi di keystore:

• Keystore pubblico: memorizza le chiavi che sono meno sensibili e a cui deve accedere qualsiasi tipo di utente.
• Keystore privato: memorizza le chiavi che codificano i dati sensibili e a cui devono accedere solo gli utenti normali.

In base ai tipi utente e alle impostazioni degli attributi chiave, le chiavi generate vengono memorizzate in keystore differenti. Il seguente elenco riepiloga i criteri di memorizzazione delle chiavi:

• Il valore dell'attributo CKA_TOKEN decide se la chiave generata è memorizzata in un keystore in memoria o in un keystore supportato dal database.

  Se si desidera archiviare la chiave nel keystore supportato dal database, impostare CKA_TOKEN su TRUE nei modelli di generazione chiave o coppia di chiavi. Il processo di inizializzazione della libreria PKCS #11 stabilisce una connessione gRPC con IBM Cloud, che facilita l'archiviazione e il richiamo degli oggetti chiave nel o dal keystore supportato dal database. Per impostazione predefinita, CKA_TOKEN è impostato su FALSE, il che significa che l'oggetto chiave viene archiviato in un keystore in memoria all'interno dello spazio di indirizzi del processo dell'applicazione PKCS #11 .

• Il valore dell'attributo CKA_PRIVATE decide se una chiave generata da utenti normali deve essere memorizzata in un keystore pubblico o privato.

  Per impostazione predefinita, se un utente ha eseguito l'accesso come utente normale, le chiavi generate vengono memorizzate nei keystore privati, ad eccezione del caso in cui CKA_PRIVATE è impostato su FALSE. Se un utente è collegato come utente SO o non è collegato (noto come utente anonimo), le chiavi generate vengono sempre archiviate nei keystore pubblici. Se un utente SO o un utente anonimo specifica CKA_PRIVATE per TRUE nei template di generazione chiavi, viene restituito un errore dal server.

  Per una coppia di chiave asimmetrica, è necessario impostare l'attributo CKA_PRIVATE separatamente sia per le chiavi pubbliche che per quelle private, il che significa che le coppie di chiavi possono essere memorizzate in keystore differenti.

Fare riferimento alla seguente tabella per le spiegazioni dettagliate della relazione tra i tipi di utente, gli attributi chiave e i keystore e la modalità di memorizzazione delle chiavi.