Installare e configurare SoftHSM su Ubuntu

Introduzione

Hardware/security tokens e Hardware Security Modules (HSM) sono dispositivi usati per conservare chiavi crittografiche (pubbliche e private) e certificati. SoftHSM è un’implementazione software che emula un HSM offrendo un’interfaccia PKCS#11: utile per sviluppo, test e situazioni in cui non è possibile usare un HSM fisico.

Definizione veloce: PKCS#11 è uno standard che definisce un’API per accedere a token crittografici (HSM, smart card). SoftHSM espone questa API ma mantiene i dati in file sul disco.

Perché usare SoftHSM

• Permette sviluppo e test senza HSM fisici.
• È compatibile con applicazioni che usano PKCS#11 (e.g., OpenDNSSEC, Mozilla Firefox, strumenti PKCS#11).
• Può servire come strato di migrazione verso HSM hardware o come fallback in ambienti limitati.

Nota importante: SoftHSM non fornisce la stessa robustezza fisica e i meccanismi anti-manipolazione di un HSM hardware certificato. Usatelo per test, staging, o architetture dove la protezione fisica non è critica.

Varianti d’uso correlate

• Usare SoftHSM in pipeline CI/CD per test automatizzati.
• Eseguire SoftHSM in contenitori per ambienti di sviluppo isolati.
• Migrare database token da SoftHSM v1 a v2.

Dipendenze

SoftHSM può essere compilato con Botan o OpenSSL come backend crittografico. Se si sceglie Botan, è raccomandato abilitare il supporto per GNU MP (opzione –with-gnump) per migliorare le operazioni su chiavi pubbliche.

Prima di compilare, assicuratevi di avere installati i pacchetti di sviluppo di OpenSSL o Botan e SQLite3 (se servono funzioni di migrazione o store su database).

Scaricare il sorgente

Il sorgente è disponibile sul sito di OpenDNSSEC. Esempio di download con wget:

wget https://dist.opendnssec.org/source/softhsm-2.3.0.tar.gz

Ora estraete il pacchetto:

tar xzf softhsm-2.3.0.tar.gz

Dopo l’estrazione, lanciate lo script di configurazione per verificare le dipendenze:

./configure

Se lo script segnala headers mancanti (ad esempio OpenSSL), installate i pacchetti di sviluppo appropriati. Esempio su Debian/Ubuntu:

sudo apt-get install libssl-dev

Nel mio esempio precedente era indicato “openssl-dev” come nome, ma sui sistemi Debian/Ubuntu il pacchetto corretto è libssl-dev.

Dopo aver installato le dipendenze richieste, rilanciate ./configure: dovrebbe completare senza errori.

Opzioni di configurazione

Lo script configure offre varie opzioni per scegliere backend crittografico, abilitare o disabilitare algoritmi, e integrare p11-kit o SQLite3. Esempio di opzioni:

./configure --help

--disable-ecc       Disable support for ECC (default enabled)
--disable-gost      Disable support for GOST (default enabled)
--disable-visibility    Disable hidden visibilty link mode [enabled]
--with-crypto-backend   Select crypto backend (openssl|botan)
--with-openssl=PATH Specify prefix of path of OpenSSL
--with-botan=PATH   Specify prefix of path of Botan
--with-migrate      Build the migration tool. Used when migrating
        a SoftHSM v1 token database. Requires SQLite3
--with-objectstore-backend-db
            Build with database object store (SQLite3)
--with-sqlite3=PATH Specify prefix of path of SQLite3
--disable-p11-kit   Disable p11-kit integration (default enabled)
--with-p11-kit=PATH Specify install path of the p11-kit module, will
            override path given by pkg-config

Scegliete le opzioni a seconda dello scenario: per ambienti di produzione che useranno OpenSSL di sistema, passate –with-crypto-backend=openssl.

Compilazione e installazione

Per compilare:

make

Per installare (potrebbe richiedere privilegi di root):

sudo make install

File di configurazione

Il file di configurazione di default è /etc/softhsm2.conf. Potete cambiare la posizione impostando la variabile d’ambiente SOFTHSM2_CONF:

export SOFTHSM2_CONF=/percorso/del/file/softhsm2.conf

Nel file di configurazione trovate i percorsi per il token store (directory dove vengono memorizzati i token) e parametri relativi al backend.

Inizializzare un token SoftHSM

Il primo passo per utilizzare SoftHSM è inizializzare un token. Potete usare l’utility softhsm2-util o chiamare l’interfaccia PKCS#11 dall’applicazione.

Esempio di inizializzazione:

softhsm2-util --init-token --slot 0 --label "Token-1"

Durante l’inizializzazione dovrete specificare due PIN: il Security Officer (SO) PIN, usato per operazioni amministrative come la re-inizializzazione, e il PIN utente, che le applicazioni useranno per firmare o decriptare. Conservate questi PIN in modo sicuro.

Dopo aver inizializzato un token, SoftHSM aggiunge automaticamente nuovi slot per token non inizializzati; i token inizializzati vengono assegnati a uno slot basato sul numero di serie del token.

Alcune utilità per gestire e visualizzare i token:

softhsm2-util --show-slots
softhsm2-util --list-tokens

Backup e ripristino

I token e gli oggetti sono memorizzati nel percorso definito nel file softhsm2.conf (di solito una directory contenente file binari). Il backup può essere fatto con una semplice copia dei file, preferibilmente dopo aver arrestato i processi che accedono al token o aver messo il servizio in modalità offline.

Suggerimento: automatizzate backup periodici e verificate l’integrità dei file copiati. Conservate le copie in luoghi sicuri e cifrati.

SoftHSM con gli strumenti OpenSC

Per testare l’integrazione PKCS#11 si possono usare le utility di OpenSC. Installazione su Debian/Ubuntu:

sudo apt-get install opensc

Esecuzione di un test PKCS#11 con pkcs11-tool (flag -t per test):

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -l -t

Il comando chiederà il PIN utente e mostrerà meccanismi supportati e oggetti presenti nel token.

Test, casi di accettazione e checklist rapida

Criteri di accettazione (minimi):

• SoftHSM si compila e installa senza errori su Ubuntu.
• È possibile inizializzare almeno un token e impostare SO e user PIN.
• pkcs11-tool elenca meccanismi e oggetti e consente operazioni di test (-t).
• Configurazione e backup sono documentati e verificabili.

Test case utili:

• Inizializzare token, creare una chiave RSA 2048 e firmare/verificare un messaggio.
• Simulare backup: copiare directory token, ripristinare su altro host e verificare che pkcs11-tool trovi gli stessi oggetti.
• Provare il backend Botan e OpenSSL per confermare compatibilità.

Checklist per l’amministratore:

• Installare dipendenze di sviluppo (libssl-dev, sqlite3, ecc.).
• Compilare con opzioni desiderate (–with-crypto-backend).
• Configurare /etc/softhsm2.conf o variabile SOFTHSM2_CONF.
• Inizializzare token e salvare PIN in vault sicuro.
• Configurare backup e procedure di test di ripristino.
• Automatizzare aggiornamenti e monitoraggio dei permessi della directory token.

Migrazione da SoftHSM v1 a v2

SoftHSM include strumenti di migrazione quando compilato con –with-migrate e richiede SQLite3. Procedura sintetica:

1. Eseguire il tool di migrazione fornito dal sorgente.
2. Verificare che i token migrati siano visibili con softhsm2-util.
3. Eseguire test di firma/verifica sugli oggetti migrati.

Nota: valutate sempre un backup completo prima di iniziare la migrazione.

Quando SoftHSM non è sufficiente

Counteresempi e limiti:

• Requisiti di certificazione FIPS o CC: SoftHSM non soddisfa le stesse certificazioni degli HSM fisici.
• Minaccia fisica: SoftHSM memorizza dati su disco e non fornisce la protezione contro attacchi hardware o furto fisico.
• Carichi di produzione elevati con requisiti di latenza e throughput molto stringenti: un HSM hardware ottimizzato può offrire migliori prestazioni.

Se avete uno di questi vincoli, considerate un HSM hardware o soluzioni cloud KMS con certificazioni adeguate.

Alternative e approcci ibridi

• HSM hardware (p.es. NitroKey, Smartcard-HSM): per protezione fisica e conformità.
• Cloud KMS (AWS KMS, Azure Key Vault, Google Cloud KMS): per gestione chiavi gestita, auditing e scalabilità.
• Container/VM con HSM virtualizzato e uso di moduli TPM per root-of-trust locali.

Approccio ibrido: usare SoftHSM in CI e staging e un HSM hardware in produzione; automatizzare test di compatibilità PKCS#11.

Sicurezza e hardening

Best practice di sicurezza:

• Permessi: limitate l’accesso alla directory di storage dei token a un account specifico (es. runas dell’applicazione).
• Backup cifrati: cifrate i backup dei file token con GPG o un vault centralizzato.
• Rotazione PIN/chiavi: definire una policy di rotazione e procedure per revoca e re-rilascio di token.
• Logging e audit: monitorare accessi ai file di token e alle utility softhsm2-util.
• Isolamento: eseguire SoftHSM su host dedicati o in container limitati, soprattutto in ambienti condivisi.

Privacy e conformità (note GDPR): SoftHSM può memorizzare chiavi che proteggono dati personali. Valutate dove risiedono i backup e applicate controlli di accesso, conservazione e cancellazione coerenti con la normativa.

Troubleshooting comune

• Errore: missing OpenSSL header — installare libssl-dev.
• Il modulo PKCS#11 non viene trovato — verificate il percorso del modulo libsofthsm2.so e i permessi.
• PIN dimenticato — se perdete il SO PIN e non avete backup del token, potrebbe essere necessario re-inizializzare il token e perdere gli oggetti.

Comandi utili per debug:

softhsm2-util --show-slots
pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -l --list-objects
strace -f pkcs11-tool ...   # per debug avanzato

Esempio di mini playbook per deploy

1. Installare dipendenze: libssl-dev, sqlite3, pkg-config, build-essential.
2. Scaricare e compilare SoftHSM con –with-crypto-backend=openssl.
3. Installare e verificare il modulo PKCS#11 in /usr/local/lib/softhsm.
4. Configurare /etc/softhsm2.conf e creare directory token con permessi restrittivi.
5. Inizializzare token con softhsm2-util e salvare PIN in vault.
6. Eseguire test con pkcs11-tool e applicazioni target.
7. Configurare backup automatico e testare il ripristino.

Glossario in una riga

• HSM: dispositivo hardware per protezione chiavi; PKCS#11: API standard per token crittografici; SO PIN: PIN amministrativo del token.

Conclusione

SoftHSM è uno strumento molto utile per sviluppatori e amministratori che devono testare l’integrazione PKCS#11 senza usare HSM fisici. Non sostituisce la sicurezza fisica e le certificazioni di un HSM hardware in ambienti di produzione sensibili, ma facilita sviluppo, test e migrazione.

Riepilogo rapido: compilate con il backend desiderato, inizializzate token, automatizzate backup, e valutate la migrazione verso HSM hardware se servono certificazioni o resistenza agli attacchi fisici.