CAPICOM è un wrapper della CryptoAPI presente nel sistema e come tale non aggiunge nessuna nuova funzionalità o nuovi algoritmi crittografici.
Inoltre non esporta tutte le funzionalità presenti nella CryptoAPI ma, al contrario, imposta internamente una serie di valori di default (alcune volte modificabili programmaticamente) rendendo estremamente facile l’uso di funzionalità complesse quali la firma elettronica, la cifratura di dati con chiave simmetrica e asimmetrica e la gestione di certificati. L’installazione di CAPICOM può avvenire in tre modalità: la prima, e la più semplice, necessita della registrazione del solo file capicom.dll tramite regsvr32.exe, oppure installando la DLL con il setup dell’applicazione. La seconda modalità riguarda le applicazioni WEB, e rende possibile l’installazione del componente COM tramite il tag
<object classid=”clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679”
codebase = http://hostname/myApp/capicom.dll#version=1,0,0,1>
Per ragioni di sicurezza il file CAPICOM.DLL è stato firmato da Microsoft facilitando il download del componente anche quando la security di Internet Explorer è impostata a High. Con la terza modalità, infine, si crea un file .INF e tramite le utility makecab.exe o cabarc.exe, si genera un file .CAB, lo si firma con signcode.exe, e si effettua il download da una pagina HTML.
Le ultime versioni di queste utility sono disponibili nel Microsoft Platform SDK. Quando si preferisce installare l’ActiveX tramite il file .CAB è possibile utilizzare lo stesso CLSID di CAPICOM oppure generarne uno con l’utility guidgen.exe. Il vantaggio nell’utilizzo della terza modalità di installazione (file.CAB) è la minore dimensione del componente da scaricare, che dovrebbe essere all’incirca meno della metà dell’ActiveX (100/110 Kb rispetto ai 246 Kb). CAPICOM, nella versione 1, espone ventidue interfacce suddivise in cinque gruppi logici:
1. Le interfacce per la firma digitale comprendono i metodi per firmare e verificare le firme, i metodi per identificare il firmatario e una collection di firmatari.
2. L’interfaccia di cifratura a sua volta implementa proprietà e metodi per cifrare e decifrare tramite una chiave simmetrica ricavata da una password utente.
3. Le interfacce dei certificati comprendono metodi e proprietà per gestire il singolo certificato, una collection di certificati e ottenere informazioni sulla loro validità creando, se necessario, un controllo a catena tra i certificati delle varie CA fino ad arrivare al root certificate.
4. Le interfacce di envelop, come quelle della cifratura, permettono di cifrare dei dati utilizzando però una diversa tecnica. I metodi di queste interfacce generano una chiave di sessione e la cifrano con il messaggio in chiaro sfruttando i meccanismi delle chiavi asimmetriche, permettendo anche in questo caso a più destinatari di decifrare il contenuto disponendo della propria chiave privata.
5. Infine le interfacce di opzioni varie permettono di interrogare e cambiare i valori di default imposti da CAPICOM. Tramite i metodi e le proprietà di queste interfacce è possibile interrogare il sistema crittografico sul tipo di chiavi e sulla loro funzione (IkeyUsage, IExtendedKeyUsage), verificare le proprietà di una firma quali il nome del documento, il time stamp (IAttribute), impostare gli algoritmi e la lunghezza delle chiavi (IAlgorithm), ed infine ricavare alcune proprietà sull’uso dei certificati (IBasicConstraints, IEKU, IEKUs).
In una tipica applicazione Windows DNA oggetti CAPICOM vengono creati all’interno di pagine ASP o gestiti in altri componenti. Indipendentemente da dove si trovi CAPICOM è importante evidenziare in alcuni casi comportamenti particolari: se un thread di IIS gestisce una richiesta di un utente riconosciuto dal sistema, questo thread impersonifica l’utente acquisendone le credenziali. Viceversa, con accesso anonimo IIS impersonifica un utente predefinito chiamato IUSR_MACHINE_NAME dove MACHINE_NAME è il nome della macchina. Quindi IIS in entrambi i casi impersonifica un utente quando elabora delle richieste.
Questo aspetto diventa molto importante lavorando con gli archivi dei certificati poiché ogni utente ha il proprio archivio dei certificati registrato nell’hive privato (HKEY_CURRENT_USER) ed è quindi inaccessibile da codice che gira con credenziali diverse. Un problema analogo si presenta quando CAPICOM è registrato come applicazione COM+ server o library.
Nel caso di COM+ server è possibile configurare l’identità di un qualsiasi utente di sistema, mentre nel caso di COM+ library il codice gira con le credenziali del chiamante. In entrambi i casi, per le applicazioni a 3 livelli, si consiglia di utilizzare, quando possibile, l'archivio di sistema che si trova in HKEY_LOCAL_MACHINE.
Verso la fine di agosto 2001 è stata rilasciata una fix di CAPICOM marcata versione 1.0a modificando a 2 il valore della revision del numero di versione interno (1.0.0.2). Poiché la fix copre un bug server-side il riferimento al numero di versione di CAPICOM nel tag HTML può rimanere invariato (come nel codice precedente). Questo aggiornamento risolve un bug che si presentava in ambiente multithread sotto COM+ con macchine multiprocessore quando il componente veniva sottoposto a grandi quantità di operazioni.
L’introduzione del concetto di firma nell’ambito informatico ha permesso di erogare vari servizi per il controllo di integrità e di non ripudiabilità di documenti (intendendo per documenti una qualsiasi rappresentazione binaria). Alla base della firma elettronica vi è l’utilizzo delle chiavi asimmetriche, ovvero di una coppia di chiavi (numero) utilizzate una per firmare e l’altra per verificare la firma.
Caratteristica delle chiavi di firma asimmetriche è l’improbabilità di ricavare una delle chiavi partendo dall’altra. Delle due chiavi, quella utilizzata per firmare è definita “privata”, mentre quella usata per la verifica della firma e definita “pubblica”.
La chiave privata deve essere mantenuta segreta, mentre quella pubblica deve essere consultabile da terze parti.
Nelle applicazioni PKI (Public Key Infrastructure) vengono normalmente utilizzati due schemi di firma diversi: DSA (Digital Signature Algorithm) e RSA (Rivest, Shamir, Adleman). Il DSA basa la propria sicurezza sfruttando il problema del logaritmo discreto mentre RSA basa la propria sicurezza utilizzando particolari proprietà formali dei numeri primi molto grandi (valori da 1000 bit o più in cui ogni bit è significativo). Nel 1994 DSA fu scelto dal NIST (National Institute of Standards and Technology) e dalla NSA (National Security Agency) come standard per la firma digitale del governo USA. Fin dagli inizi fu sollevata la questione riguardante la velocità di esecuzione durante la verifica delle firme poiché, pur essendo la generazione della firma elettronica più veloce rispetto a quella di RSA, le operazioni di verifica sono decisamente più lente.
Tali obiezioni furono sollevate in quanto in applicazioni PKI sono maggiori le operazioni di verifica rispetto a quelle di firma. Inoltre DSA può essere utilizzato solamente per calcolare le firme digitali e non per la cifratura a chiavi asimmetriche. Viceversa RSA è più veloce nelle operazioni di verifica e può essere utilizzato per la cifratura a chiavi asimmetriche. Questa versatilità ha imposto RSA come maggiore standard mondiale nelle applicazioni PKI. CAPICOM è in grado di lavorare con chiavi di tipo RSA e DSA. L’unico vincolo è che il CSP utilizzato le supporti.
Un altro “attore” presente nelle operazioni di firma e di verifica è l’Hash. Un Hash è il risultato di una funzione che riceve in input una sequenza di simboli binari a dimensione variabile e produce in output un’altra sequenza di simboli binari di dimensioni fisse. Un Hash quindi rappresenta in forma compatta un qualsiasi insieme di bit. Le caratteristiche principali di queste funzioni sono la facilità di calcolo e la compressione. Esistono due grandi famiglie di Hash: Keyed (con chiavi) e Unkeyed (senza chiavi).
Gli Hash MDC, chiamati anche manipulation detection codes, hanno principalmente lo scopo di garantire l’integrità dei dati focalizzandosi maggiormente su due proprietà: one way hash functions (OWHFs) e collision resistant hash functions (CRHFs) o collision free. Con la proprietà OWHF viene assicurata una notevole difficoltà computazionale nel calcolare i bit di input partendo da quelli di output (l’hash), mentre la proprietà CRHF assicura una bassissima percentuale di probabilità di calcolare due valori hash uguali partendo da input diversi.
Sebbene la CryptoAPI supporti molti algoritmi di Hash, CAPICOM per le operazioni di firma utilizza lo SHA-1 e ad oggi non esiste nessuna interfaccia che permetta di cambiare tale algoritmo.
Per completare il quadro, avendo a disposizione la coppia di chiavi e le funzioni di Hash, manca un’entità che associ la persona (l’utente, la macchina o un servizio) alle chiavi: il certificato.
Il certificato è un documento rilasciato da una terza parte di fiducia la quale si assume l’onere di verificare le credenziali del richiedente e dare una validità temporale alle chiavi. In crittografia le operazioni di firma e di verifica si dividono in diverse fasi: la firma elettronica si genera partendo da un hash del documento in chiaro e successivamente si cifra l’hash con la propria chiave privata.
La verifica, un’operazione leggermente più complessa, avviene tramite il certificato del firmatario dal quale si estrae la chiave pubblica utilizzata per decifrare l’hash generato durante la fase di firma. Una volta ottenuto l’hash in chiaro si rigenera indipendentemente l’hash del documento da verificare e se entrambi i valori hash sono uguali, la firma è valida.
In questa fase è possibile controllare la validità del certificato appartenente al soggetto firmatario verificando che il certificato non sia scaduto, sospeso o revocato dalla CA (tramite la pubblicazione in una CRL). Per disporre delle funzionalità di crittografia nei progetti Visual Basic è necessario inserire il reference a CAPICOM nel progetto. A questo punto è possibile utilizzare il componente per apporre la propria firma su qualsiasi dato, binario e di testo. La condizione per cui CAPICOM possa effettuare le operazioni di firma è che nell'archivio di Windows sia presente almeno un certificato con la chiave privata associata.
Esiste però un comportamento diverso da Windows NT e Windows 2000/XP se il certificato risiede su un device esterno come le smart-card: con Windows NT è necessario copiare preventivamente il certificato dalla smart-card nel MY store di Windows mentre con Windows 2000/XP questo avviene automaticamente per i lettori di smart-card Windows compatibile. E’ comunque possibile scrivere delle utility tramite la CryptoAPI, non CAPICOM, per esportare i certificati dalle smart card nel MY store.
A questo punto il progettista software tramite CAPICOM può decidere se preselezionare un certificato automaticamente oppure, nel caso di più certificati, far selezionare all’utente quale utilizzare tramite una DialogBox.
Uno dei primari obiettivi perseguiti durante lo sviluppo di CAPICOM è stato quello di rendere il più semplice possibile alcune operazioni crittografiche. Per apporre una firma digitale, tralasciando i necessari controlli sugli errori, sarebbero sufficienti solamente tre righe:
...
Dim firma As New SignedData
firma.Content = bufferToSign
msgbox firma.Sign…
Questo esempio crea un’istanza dell’oggetto SignedData, gli associa il buffer da firmare ed infine visualizza in una messagebox il risultato dell'operazione di firma codificato. Non avendo selezionato programmaticamente nessun certificato CAPICOM in automatico visualizza una DialogBox contenente la lista dei certificati installati sulla macchina.
Il metodo Sign richiede tre parametri: Signer as Signer, bDetached as Boolean e EncodingType as CAPICOM_ENCODING_TYPE. L’oggetto Signer (primo parametro) rappresenta il firmatario che deve avere accesso alla chiave privata relativa al certificato utilizzato. Sul platform SDK, nella sessione remarks, è possibile trovare una serie di casistiche sul funzionamento del metodo per Signer uguale o diverso da NULL, in concomitanza con il numero di certificati nell'archivio e in relazione alla proprietà booleana Settings.EnablePromptForCertificateUI (per le applicazioni middle-tier impostare sempre Settings.EnablePromptForCertificateUI a FALSE). Il secondo parametro bDetached impostato a TRUE indica che l’hash firmato viene salvato in un file separato rendendo necessario disporre di entrambi i file per l’operazione di verifica. Quando bDetached è FALSE viene creato un unico file contenente il documento in chiaro e la firma. In entrambi i casi i file contenenti le firme vengono salvati nel formato standard PKCS#7 rendendo possibile l’eventuale operazione di verifica anche tramite altre applicazioni PKI.
L’ultimo parametro EncodingType rappresenta il tipo di codifica utilizzata per il buffer contenente la firma. I valori ammessi sono CAPICOM_ENCODE_BASE64 dove i dati vengono salvati in una stringa base64 e CAPICOM_ENCODE_BINARY in cui vengono salvati in formato binario.
Sempre tramite l’interfaccia ISignedData è possibile firmare ripetutamente un documento tramite il metodo Cosign. La firma di più persone su un contratto oppure l’approvazione di documenti all’interno di un processo di workflow sono esempi di utilizzo di tale metodo.
Come in Sign, anche in Cosign valgono le stesse regole sulla presenza di un certificato valido con la propria chiave privata.
L’operazione di verifica avviene anch’essa tramite un metodo esposto da SignedData: SignedData.Verify(SignedMessage as String, bDetached as boolean, VerifyFlag as CAPICOM_SIGNED_DATA_VERIFY_FLAG). Semplicemente richiamando tale metodo vengono effettuati tutti i passi necessari per la verifica della o delle firme associate al documento. I primi due parametri sono equivalenti a quelli presenti in SignedData.Sign mentre l’ultimo indica la politica di controllo. Il tipo dato CAPICOM_SIGNED_DATA_VERIFY_FLAG può assumere due valori: CAPICOM_VERIFY_SIGNATURE_ONLY per controllare solamente la validità della firma, CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE aggiunge il controllo completo sulla validità del certificato.
Sub Signfile(ByVal InputFileName As String, ByVal OutputFileName As String)
On Error goto ErrorHandler
Dim c As String
Dim s As String
Dim MyStore As New Store
Dim Signobj As New SignedData
Dim Signer As New Signer
‘ Nota: Il nome ‘Attribute’ non è un nome unico
‘ e deve essere preceduto da ‘CAPICOM’.
Dim SigningTime As New CAPICOM.Attribute
‘ Apre il MY store e vi preleva il primo certificato.
‘ L’operazione di firma lavorerà solo se questo certificato è
‘ valido ed ha accesso alla chiave privata del firmatario.
MyStore.Open CAPICOM_CURRENT_USER_STORE, “MY”, CAPICOM_STORE_OPEN_READ_ONLY
Signer.Certificate = MyStore.Certificates.Item(1)
‘ Apre il file in input e legge il contenuto che deve essere firmato.
Open InputFileName for Input as #1
Input #1, c
Close #1
‘ Setta il contenuto che deve essere firmato.
Signobj.Content = c
‘ Salva, come attributo del firmatario, la data in cui i
‘ dati sono stati firmati.
SigningTime.Name = CAPICOM_AUTHENTICATED_ATTRIBUTE_SIGNING_TIME
SigningTime.Value = Now
Signer.AuthenticatedAttributes.Add SigningTime
‘ Firma il contenuto usando la chiave privata del firmatario.
‘ Il parametro ‘True’ indica che il contenuto firmato non è
‘ incluso nella stringa di firma.
s = Signobj.Sign(Signer, True)
Open OutputFileName for Output as #2
Write #2, s
Close #2
MsgBox “Firma effettuata – File salvato” & OutputFileName
Set Signobj = Nothing
Set MyStore = Nothing
Set Signer = Nothing
Set SigningTime = Nothing
Exit Sub
ErrorHandler:
If Err.Number > 0 then
MsgBox “Trovato un errore di Visual Basic:” & Err.Description
Else
MsgBox “Trovato un errore di CAPICOM:” & Err.Number
End If
End Sub
Sub CoSignContent(ByVal InputFile1Name as String,
ByVal InputFile2Name as String,
ByVal OutputFileName as String)
On Error goto ErrorHandler
Dim c As String
Dim s As String
Dim CS As String
Dim Signobj As New SignedData
Open InputFile1Name for Input as #1
Input #1, s
Close #1
Open InputFile2Name for Input as #2
Input #2, c
Close #2
Signobj.Content = c
Signobj.Verify s
CS = Signobj.CoSign
Open OutputFileName for Output as #3
Write #3, CS
Close # 3
Set Signobj = Nothing
MsgBox “Cofirma finita. Cofirma salvata nel file.”
Exit Sub
ErrorHandler:
If Err.Number > 0 then
MsgBox “Trovato un errore di Visual Basic:” & Err.Description
Else
MsgBox “Trovato un errore di CAPICOM:” & Err.Number
End If
End Sub
Verifica della firma su un documento
Sub Verifysig(ByVal InputFile1Name as String, ByVal InputFile2Name as String)
On Error goto ErrorHandler
Dim c As String
Dim s As String
Dim sig As SignedData
Set sig = New SignedData
‘ Apre il file e legge la firma.
Open InputFile1Name for Input as #1
Input #1, s
Close #1
‘ Questo esempio verifica una firma distaccata.
‘ Esso apre un file e prende in input il testo
‘ che era stato firmato.
Open InputFile2Name for Input as #2
Input #2, c
Close #2
‘ Setta il contenuto distaccato nel quale è inserita la firma
Sig.Content=c
‘ Verifica la firma.
On Error resume next
Sig.Verify s, True
If Err.Number <> 0 then
MsgBox “Verifica della firma fallita.”
Else
MsgBox “Verifica Completata”
End if
‘ Rilascia l’oggetto SignedData
Set Sig = Nothing
Exit Sub
ErrorHandler:
If Err.Number > 0 then
MsgBox “Trovato un errore di Visual Basic:” & Err.Description
Else
MsgBox “Trovato un errore di CAPICOM:” & Err.Number
End If
End Sub
In crittografia l’informazione in chiaro viene chiamata testo in chiaro mentre lo stesso dato cifrato viene denominato testo cifrato. La cifratura è la procedura che converte il testo in chiaro in testo cifrato, la decifratura è la funzione inversa che converte il testo cifrato in testo in chiaro. Con CAPICOM è possibile effettuare due distinte operazioni di cifratura: a chiave segreta e a chiave pubblica. La prima viene chiamata anche cifratura a chiave simmetrica o “shared secret” utilizzabile tramite l’interfaccia IEncryptedData; la seconda utilizza nuovamente le funzionalità delle chiavi asimmetriche. Quest’ultima viene esposta tramite l’interfaccia IEnvelopedData.
La cifratura a chiave simmetrica ha la caratteristica di utilizzare la stessa chiave, detta anche chiave di sessione, per cifrare e decifrare.
Queste chiavi sono un numero casuale con dimensioni che possono variare da 40 a 2000 bit, spesso generate partendo da un hash. CAPICOM quando genera le chiavi di sessione tramite la cifratura a blocchi le calcola in CBC mode (cipher block chaining) con un vettore di inizializzazione uguale a zero. Infatti questa è la modalità di default della funzione CryptDeriveKey utilizzata appunto per la generazione delle chiavi di sessione non casuali.
IEncryptedData mette a disposizione due proprietà e tre metodi. Le due proprietà, Content e Algorithm indicano rispettivamente il testo da cifrare e l’algoritmo da utilizzare. Quest’ultimo inoltre permette di specificare anche la lunghezza della chiave. Tuttavia se il tipo di algoritmo o la lunghezza della chiave non è fornito dal CSP in uso, CAPICOM cerca nei restanti CSP Microsoft la disponibilità del servizio. I tre moduli, SetSecret, Encrypt e Decrypt permettono rispettivamente di impostare la password, cifrare e decifrare.
Il seguente esempio rappresenta il minimo codice per cifrare con l’algoritmo 3DES.
Dim oCifra As New EncryptedData
...
oCifra.SetSecret “password segreta”
oCifra.Content = “Questo testo viene cifrato”
oCifra.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_3DES
Msgbox oCifra.Encrypt
…
Specificando l’algoritmo 3DES (oppure DES) non è necessario impostare la lunghezza della chiave in quanto derivata dall’algoritmo stesso.
Quindi, tramite l’interfaccia IEncryptedData, è possibile che n persone siano in grado di cifrare e decifrare i loro documenti con il solo vincolo di essere a conoscenza della chiave di sessione (shared secret appunto).
Non sempre questa condizione può essere accettabile, soprattutto quando si rende necessario inviare la chiave di sessione tramite una infrastruttura non sicura come ad esempio Internet. La distribuzione delle chiavi in crittografia è sempre stato uno dei più grossi problemi da affrontare.
Il secondo metodo di cifratura esposto da IEnvelopedData combina la cifratura simmetrica con quella asimmetrica. Innanzitutto CAPICOM internamente genera una chiave di sessione con la quale cifra il documento.
La chiave di sessione viene a sua volta cifrata con la chiave pubblica presente nel certificato del destinatario rendendo di fatto sicuro l’invio della chiave e del documento tramite qualsiasi infrastruttura. A questo punto per il destinatario del documento è semplice decodificare il messaggio: deve decifrare la chiave di sessione con la propria chiave e successivamente può riottenere il documento in chiaro.
Gli utenti di CAPICOM, non dovendosi preoccupare dei dettagli crittografici, hanno a disposizione l’interfaccia IEnvelopedData la quale espone tre proprietà: Content, Algorithm e Recipients.
Analogamente all’interfaccia IEncryptedData la proprietà Content indica il testo in chiaro che dovrà essere inviato, mentre algorithm rappresenta l’algoritmo di cifratura. Recipients è una collezione di destinatari identificati tramite il loro certificato. I metodi Encrypt e Decrypt sono autoesplicativi. Il messaggio da inviare contiene le seguenti informazioni: le chiavi di sessione cifrate, il messaggio cifrato ed i certificati di tutti i destinatari. Il formato del file generato da IEnvelopedData è lo standard PKCS#7.
La modalità di verifica dell’interfaccia IEnvelopedData avviene tramite il metodo Decrypt il quale verifica che nel MY store dei certificati installati localmente sia presente un certificato contenuto nel messaggio. In questo contesto è opportuno precisare che IEnvelopedData non è nel formato S/MIME e che CAPICOM, in questa versione, non lo supporta nativamente.
Sub EncryptMessage(ByVal TobeEncrypted As String,
ByVAl Hidden As String,
Byval FileName As String)
On Error goto ErrorHandler
‘ Dichiarazione ed inizializzazione dell’oggetto EncryptedData.
‘ Algorithm.Name e KeyLength non devono essere settati.
Dim Message As New EncrypteData
Message.Content = TobeEncrypted
Message.SetSecret Hidden
‘ Opzionalmente, l’algoritmo di cifratura e la lunghezza della chiave possono
‘ essere settati. Se queste proprietà non vengono settate, sono usati
‘ l’algoritmo e la lunghezza della chiave di default.
‘ L’informazione sull’algoritmo e la lunghezza della chiave sono salvate
‘ assieme alla stringa cifrata e l’individuo che decifra il messaggio non ha
‘ bisogno di settare queste proprietà.
Message.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES
‘ Dichiarazione della stringa che conterrà il messaggio cifrato.
Dim EncryptedMessage As String
' Cifratura del messaggio e
memorizzazione del risultato nella stringa EncryptedMessage
EncryptedMessage = Message.Encrypt
‘ Controllo della lunghezza della stringa cifrata per essere sicuri che il
‘ metodo di cifratura lavori bene.
If Len(EncryptedMessage) < 1 then
MsgBox “Messaggio non cifrato.”
Else
MsgBox “Il messaggio è di “ & Len(EncryptedMessage) & “caratteri.”
‘ Apertura del file di output e scrittura del messaggio cifrato nel file.
‘ Il file non è aperto se non c’è nessun messaggio da scrivere.
Open FileName for Output as #1
Write #1, EncryptedMessage
Close #1
MsgBox “Messaggio cifrato scritto nel file.”
End If
‘Rilascia l’oggetto EncryptedData
Set Message = Nothing
Exit Sub
ErrorHandler:
If Err.Number > 0 then
MsgBox “Trovato un errore di Visual Basic:” & Err.Description
Else
MsgBox “Trovato un errore di CAPICOM:” & Err.Number
End If
End Sub
Nel paragrafo precedente abbiamo utilizzato i certificati contenuti nell'archivio del sistema operativo per identificare una persona e utilizzare la chiave privata associata.
I certificati sono documenti il cui scopo è quello di “certificare” l’identità di una persona, di un servizio o di un server.
Il certificato ha validità in quanto rilasciato da una certification authority (CA). Una CA è un’entità interna o esterna all’azienda che rilascia dei documenti (certificati) in grado di provare l’identità del richiedente. L’identità viene preventivamente verificata tramite procedure predefinite da un altro servizio: la registration authority (RA). Sebbene in molti casi le funzioni di RA vengono gestite all’interno della stessa CA, bisogna sottolineare che logicamente sono due servizi ben distinti che interagiscono ma con scopi e funzionalità diverse.
Il certificato è pubblico e deve essere consultato durante le operazioni di verifica. In questa circostanza è anche possibile verificare l’integrità e l’autenticità del certificato stesso poiché la CA lo firma con una delle proprie chiavi private. Il campo Authority Key Identifier di un certificato X.509 v3 indica quale delle varie chiavi pubbliche della CA si deve utilizzare per le operazioni di verifica.
I certificati possono contenere differenti tipi di dati. Un certificato X.509 include il nome della CA, il numero di serie, l’algoritmo utilizzato per la firma del certificato, il nome e la chiave pubblica dell’entità a cui si riferisce (utente, servizio, server). X.509 è uno standard definito da ITU-T (International Telecommunications Union-Telecommunication) e ISO (International Organization for Standardization) che stabilisce la struttura dei certificati a chiave pubblica. Il primo documento ufficiale di questo standard risale al 1988 e dopo le modifiche del 1993 e del 1996 si è giunti alla attuale versione 3 (X.509v3). Questa prevede una serie di campi obbligatori definiti con ordine stabilito oltre ad una serie di estensioni tramite campi opzionali. Esistono due tipi di certificati: certificati end-entity e certificati CA.
I certificati end-entity sono tutti i certificati rilasciati a entità che a loro volta non generano altri certificati. I certificati CA sono rilasciati da una CA ad un’altra CA anche con ruoli diversi. In questo contesto parleremo esclusivamente dei certificati end-entity. Inoltre lo standard X.509 ha creato il concetto di politica dei certificati ovvero una serie di informazioni che precisano per quale scopo (o ruolo) sarà utilizzato il certificato. Una politica dei certificati è identificata da un numero univoco OID (Object IDentifier) reso pubblico in modo che la CA e l’utilizzatore del certificato possano riconoscere e identificare le singole politiche. CAPICOM non è in grado di gestire delle specifiche estensioni all’interno dei certificati utilizzando il valore OID. In questa circostanza è indispensabile l’uso della CryptoAPI.
Sebbene CAPICOM sia in grado di gestire l'archivio dei certificati e i certificati stessi, non ha le funzionalità di registrazione di certificati negli archivi software e sulle smart card. Se il programmatore ha necessità di coprire anche la parte di richiesta e generazione dei certificati deve utilizzare il componente COM Certificate Enrollment Control XENROLL. XENROLL prende in input i dati relativi al richiedente del certificato e genera una richiesta in formato PKCS#10 da inviare ad una CA.
Questo meccanismo in realtà avviene tramite molteplici step.
Innanzitutto XENROLL genera localmente una coppia di chiavi asimmetriche e un certificato temporaneo. A questo punto crea e firma con la chiave privata appena calcolata il pacchetto PKCS#10 composto anche del certificato temporaneo e della chiave pubblica del richiedente. La CA tramite le proprie politiche genera un certificato e gli associa, tra le altre informazioni, la chiave pubblica ricevuta dall’applicazione.
Infine la CA firma il nuovo certificato. A questo punto viene restituito all’applicazione un messaggio PKCS#7 contenente il nuovo certificato o una lista di certificati. XENROLL estrae il certificato appena generato dalla CA e lo pubblica nell'archivio a disposizione di tutte le applicazioni e quindi anche di CAPICOM.
