CA on-card con MyEID

Il "piccolo difetto" delle CA "casalinghe" è che la chiave segreta non è conservata in modo particolarmente sicuro. Addirittura, talvolta è tenuta in chiaro proprio sulla macchina più esposta (come nel caso di ZeroShell). Ma una smart card può aiutare molto!

Infatti, se una chiave viene generata direttamente sulla card, non è possibile che un attaccante riesca ad impadronirsene, se non rubando fisicamente la card. Ed anche allora deve disporre del PIN, o non gli servirà a nulla.

Peccato che l'uso di openssl sia piuttosto ostico, e che ZeroShell ancora non preveda l'uso di token. Per questo si possono trovare soluzioni veramente "poderose", che gestiscono tutta la PKI aziendale (come nel caso di EJBCA, che mette anche a disposizione un liveCD, utile per l'uso su una VM) e che supportano l'uso di HSM. Ma per venire incontro a chi ha esigenze più modeste, c'è XCA: un semplice frontend grafico che permette di gestirsi con semplicità una piccola CA. Quale usare dipende, ovviamente, dalle esigenze che si hanno.

Ovviamente, il "difetto" di avere una propria CA è che i certificati generati non sono riconosciuti automaticamente dai client (browser in primo luogo), ed è necessario che l'utente finale decida di fidarsi della vostra CA dopo un messaggio tipo "La connessione potrebbe non essere affidabile" o similari.

Mi è venuto da ridere (in senso buono, ovviamente) a leggere in giro per dei forum di gente che chiedeva come evitare che i browser degli utenti generassero l'avviso. Una tale domanda è di un'ingenuità disarmante: se fosse possibile evitare l'avviso, allora i certificati non servirebbero a nulla! Infatti chiunque potrebbe generare un certificato per qualsiasi sito, senza che l'utente lo noti.

La soluzione è semplice: fornire agli utenti la chiave pubblica della CA, da inserire tra quelle affidabili. Questa chiave "dovrebbe" essere firmata da un'identità certificata (molto difficile che una CA certifichi un'altra CA...), o consegnata di persona agli utenti. Per questo gli utenti devono essere disposti a fidarsi della CA o, in modo abbastanza equivalente, di chi la gestisce. Le CA che emettono i certificati riconosciuti automaticamente da "tutti" i browser, infatti, devono sottostare a tutta una serie di regole che l'utente spesso ignora (chi si è messo a leggere le policy di una CA? Eppure il link si trova nei certificati...). E queste regole prevedono sia i controlli sull'identità di chi richiede un certificato, che una responsabilità sui certificati emessi. Possono anche essere previste ispezioni di terze parti. Per es. Mozilla, per includere una CA tra quelle affidabili, ha una procedura molto rigida, che addirittura ha "tagliato fuori" OpenCA.

Tornando alla gestione di una CA con smartcard, darò per scontato l'uso di XCA, anche se i concetti saranno poi gli stessi qualsiasi gestore si intenda usare ma ovviamente cambieranno i dettagli di gestione. Come card uso le MyEID (le più economiche e capienti che ho trovato ed ultimamente disponibili anche con NFC), per le altre (per esempio i token come ePass2003, o Cryptomate64 che gestisce anche RSA4096, o card e token del progetto OpenPGP anche se con supporto ancora un tantino acerbo) potrebbero esserci piccole differenze nella fase di inizializzazione o di configurazione del sistema.

1. Cambio il profilo "standard" con quello personalizzato: la card potrà essere gestita solo su una macchina che utilizzi lo stesso profilo o si andrà incontro a strane anomalie! Il profilo originale si trova in /usr/share/opensc/myeid.profile e va sostituito con quello allegato. Fate un diff per vedere le modifiche!
2. Cancello tutto quel che c'era sulla card (potrebbe richiedere il SO-PIN precedente):
   

   pkcs15-init -E
   

3. Inizializzo un nuovo token PKCS#15:
   

   pkcs15-init -C --profile pkcs15 --pin 1111 --puk 1111 \
   --so-pin $SOPIN --so-puk $SOPUK -l "CA on card"
   

   Da notare che --pin e --puk servono solo per evitare richieste, ma non vengono creati. SO-PIN e SO-PUK, invece, vengono creati, quindi è bene che vengano specificati i valori giusti. Attenzione a conservare SO-PIN e SO-PUK in modo sicuro: è vero che non si possono estrarre le chiavi segrete, ma chi vi sottrae una card li conosce, sarà in grado di riutilizzarla come gli pare!

4. Inizializzo PIN e PUK per l'accesso alle chiavi delle CA
   

   pkcs15-init -P -a 1 --pin $PIN1 --puk $PUK1 --so-pin $SOPIN \
   -l "CA Auth"

5. Finalizzo la card, così che si attivino i controlli d'accesso
   

   pkcs15-init -F
   

6. Apro XCA e creo un nuovo database, che conterrà lo stato della mia CA (file->New Database), impostando una password sicura
7. da file -> options carico il provider PKCS #11 che mi interessa (per es. /usr/lib64/opensc-pkcs11.so) e mi accerto che la funzione di hash utilizzata non sia MD5 (ormai considerata insicura per l'uso nei certificati: è relativamente facile generare collisioni!)
8. genero una nuova chiave (sulla destra, tasto "New Key"); attenzione ad impostare il valore corretto per "Keytype": RSA, DSA ed EC non usano la card! Per usare la card è necessario selezionare uno dei PIN dalla lista (nel mio caso "CA Auth") come in figura:
   
9. da token -> Manage security token seleziono la chiave appena creata e clicco su Import
10. Se tutto è andato bene, potete vedere la chiave appena creata nel primo tab
11. Andate nel tab "Sertificates" e cliccate "new certificate"; controllate che sia selezionato "create self signed certificate with serial 1" e che l'algoritmo di hashing sia almeno SHA1, selezionate il template '[default] CA' e cliccate "Apply all"
12. Passate ora nel tab "Subject" ed inserite i dati della CA (Internal name può essere qualsiasi cosa, ma suggerisco "Root CA") , controllando attentamente che sotto "Private key" sia selezionata la chiave precedentemente generata; nel tab "Extensions" potrete variare la validità del certificato (se non volete farlo scadere basta che selezionate "no well-defined expiration", ma il default di 10 anni dovrebbe andare bene, anche perché probabilmente tra 10 anni una chiave RSA2048 non sarà più reputata particolarmente sicura...) e alla voce "CRL distribution point" inserite l'URI dove pubblicherete la CRL (a meno che non vogliate usare OCSP, ma in tal caso cosa state legggendo a fare le istruzioni per XCA? Passate ad EJBCA!) come per es. "URI:http://csshl.net/csshl_net_root_ca.crl"; il tab "Key usage dovrebbe essere già a posto, mentre in quello "Netscape" dovrete compilare i campi "CA policy URL" (p.es. "http://csshl.net/csshl_net_root_ca_policy.pdf" e "Comment" (questo si può lasciare in bianco)
13. Cliccando su OK vi verrà richiesto il PIN (state usando la card...) e verrà generato il certificato
14. Vi verrà anche chiesto se memorizzare il certificato sulla card: meglio farlo (quindi dovrete inserire nuovamente il PIN)
15. Selezionate il certificato appena creato ed esportatelo in formato PEM; questo sarà il file che dovrete far installare a chi decide di fidarsi della vostra CA

A questo punto la vostra CA è pronta per generare certificati per i vostri siti ed utenti.
Attenzione, se importate delle CSR, a controlalre attentamente tutti i campi. Consiglio di generare un template per ogni tipologia di certificato che volete emettere, così da sovrascrivere tutti i campi "estesi" della richiesta (vi rimarranno da controllare attentamente solo quelli del tab "subject"). Un errore con i campi estesi potrebbe permettere ad un utente di ottenere un certificato per una sua CA, che potrà poi emettere a sua volta certificati per qualsiasi uso!
Buon lavoro!

Se ci dovessero essere degli strani errori generati da XCA, e non riusciste a creare la chiave, potrebbe essere dovuto alla modalità plug'n'play di pcscd. Provate quindi a chiudere XCA, fermare pcscd ed editare /etc/pcscd.conf per decommentare "plug_and_play = false". A questo punto potete riavviare pcscd ed XCA e tutto dovrebbe funzionare.