Certificati digitali in Windows : tutto quello che un Architetto dovrebbe sapere

Certificati Digitali

I Certificati sono firmati digitalmente dalla Certification Authority (CA) che li ha rilasciati e sono composti da una struttura dati estendibile di campi obbligatori e opzionali.

La struttura dei certificati digitali a chiave pubblica comunemente utilizzata è quella definita dallo standard X.509 specificato da ITU-T (International Telecommunications Union-Telecommunication) e ISO (International Organization for Standardization’s).

Lo scopo dei certificati, come suggerisce il nome, è di certificare l’identità di una persona, di un servizio o di una macchina all’interno di un arco temporale finito (identificato dai campi : Valid to e Valid From) associando la chiave pubblica (anch’essa presente nel certificato) e le informazioni descrittive del richiedente con la chiave privata che deve essere accessibile solamente all’entità a cui è stato rilasciato il certificato. In questo contesto mi preme sottolineare uno dei misunderstanding più comuni : la chiave privata NON risiede nel certificato!!! piuttosto è presente in uno store (Key Store) presente o sul sistema o all'interno di device esterne come ad esempio le smart-card.

Esistono due tipi di certificati: certificati CA e certificati end-entity. I certificati CA vengono rilasciati da una CA padre ad una CA figlia che può avere ruoli diversi all’interno di una struttura gerarchica PKI (Public Key Infrastructure) con l’unica eccezione dei certificati di una Root CA che sono firmati dalla stessa Root CA, mentre i certificati end-entity vengono rilasciati esclusivamente a entità che a loro volta non generano altri certificati.

In Windows quando una Certification Authority crea un certificato end-entity viene ritornato al client un pacchetto in formato PKCS#7 contenente il nuovo certificato rilasciato e la lista di tutti i certificati delle CA intermedie fino ad arrivare alla Root Ca. Questa lista si chiama Certification Path. Nella figura seguente la Certification Path contiene una Root CA di nome NemesisCA e il certificato end-entity senza nessuna CA intermediaria.

All’interno dei certificati sono presenti una serie di estensioni tra cui KeyUsage. Questo campo, che può essere marcato come critico, indica come la chiave pubblica presente nel certificato debba essere utilizzata (e di conseguenza anche la chiave privata). In questo contesto prendiamo in considerazione solamente i valori Digital Signature, Non-Repudiation, Key Encipherment e Data Encipherment perchè sono quelli utilizzati maggiormente nelle nostre applicazioni.
Digital Signature implica che le chiavi asimmetriche possono essere utilizzate per le operazioni di firma digitale mentre Non-Repudiation restringe il campo di utilizzo della chiave ai servizi di non-repudiabilità. L’estensione Key Encipherment indica che la chiave pubblica può essere utilizzata per cifrare altre chiavi, come nella tecnica dell’Envelop descritta nella prima parte di questo articolo, mentre Data Encipherment rappresenta la stessa funzionalità con l’eccezione che le informazioni da cifrare non sono altre chiavi crittografiche ma i dati dell’applicazione.

Quindi i certificati completi di tutti questi flag indicano che le chiavi asimmetriche possono essere utilizzate per la firma elettronica, per lo scambio di chiavi simmetriche (cifrate) e per la cifratura diretta di dati. Ad esempio si considerino 3 utenti : Luca, Antonella e Carlo (La versione italiana di Alice e Bob). Per i primi due il campo KeyUsage contiene tutti e quattro i flag mentre per l’utente Carlo sono previsti solo i primi due flag. Il certificato di Antonella ,in aggiunta, è stato inserito nello store Other People del server. In questa situazione alcune applicazioni che si basano sulla presenza dei certificati negli store di Windows non permetteranno a Carlo di ricevere i dati sensibili dall'applicazione o dai servizi perchè il certificato che lo rappresenta indica che la sua chiave pubblica non può essere utilizzata per cifrare le informazioni e quindi non gli viene data la possibilità di accedere al servizio. Per l’utente Luca il server lo autentica ma non trovando il suo certificato tra quelli presenti nello store Other People non può autorizzarlo e quindi gli ritorna un messaggio SOAP di accesso negato. L’utente Antonella è in grado di essere autenticata e autorizzata a ricevere i dati sensibili dell’applicazione.

Giocare con i certificati

Per effettuare delle prove con i certificati è possibile installare una CA di prova oppure utilizzare l’utility a riga di comando makecert.
Se si utilizza una CA Windows, dopo l’installazione di una Stand-alone root CA si può richiedere un certificato accedendo al servizio di RA (Registration Authority – ovvero la parte di acquisizione dati di una Certification Authority) tramite Internet Explorer digitando l’URL https://localhost/certsrv (se è sulla stessa macchina). La home page di default permette di richiedere manualmente un certificato tramite le scelte : Request a certificate, Advanced certificate request e Create and submit a request to this CA.
Arrivati qui:

l’utente deve inserire i propri dati o quelli del servizio oltre ad alcune impostazioni di crittografia (per una analisi completa delle opzioni fare riferimento alla documentazione del prodotto). In questo caso l’opzione Both indica che la chiave sarà abilitata per la firma digitale e per l’encryption impostando i quattro flag sopra descritti nel campo KeyUsage del certificato che verrà emesso. Il flag Enable strong private key protection richiede una password per l’accesso alla chiave privata.

 

 

Questa opzione permette di aumentare il livello di sicurezza del nostro client non permettendo, idealmente, a utenti diversi di utilizzare i certificati di altre persone. Per una applicazione reale è necessario adottare altre soluzioni come le smart-card.

Dopo aver premuto il pulsante Submit e risposto Yes all’avvertimento di sicurezza si ottiene una pagina che informa il richiedente che la sua richiesta è stata innoltrata al server e di ripassare tra due o tre giorni. Ovviamente non c’è bisogno di aspettare così tanto tempo (questo è un messaggio standard e personalizzabile!).

Attivando lo snap-in della Certification Authority presente negli strumenti di amministrazione del vostro server si può procedere al rifiuto della richiesta oppure alla creazione e al rilascio del certificato.

Una volta creato il certificato sul server l’utente potrà installare il certificato sulla propria macchina accedendo alla home page della CA selezionando la voce View status of a pending certificate request dove comparirà un link al certificato appena emesso.

Una volta installato il certificato è possibile verificare che sia correttamente presente nello store di Windows aprendo Internet Explorer. Dal menù Internet Options si selezioni il tab Content e premendo il pulsante Certificates compare una lista dei certificati installati sulla macchina. Se l’operazione di richiesta e installazione è andata a buon fine il certificato sarà presente nel primo tab chiamato Personal.

Come regola generale, questo tab contiene tutti quei certificati la cui chiave privata associata è presente ed accessibile (store di Windows o Smard Card). Un altro metodo per effettuare la verifica consiste nell’ aprire una Management Console (mmc.exe) e aggiungere lo snap-ins dei certificati. In questo caso la vista è leggermente diversa e verrà analizzata più in dettaglio parlando dello store dei certificati.

La verifica di un certificato avviene tramite i seguenti passi : acquisizione del certificato della CA che lo ha emesso, decifratura dell’hash del certificato da verificare utilizzando la chiave pubblica presente nel certificato della CA, ricalcolo dell’hash del certificato, confronto tra i due hash ottenuti ed infine verifica delle informazioni temporali. Questa verifica può essere estesa a tutta la certification path comprendente le eventuali CA intermediarie e la Root. All’interno del periodo di validità il certificato può essere revocato a causa di innumerevoli ragioni come la perdita della chiave privata (smart-card) oppure un cambio di ruolo rendendo necessario un meccanismo di pubblicazione di tutti i certificati revocati. Ogni CA periodicamente pubblica una lista firmata dei certificati revocati (CLR - Certificate Revocation Lists) rendendola accessibile tramite una o più meccanismi (url, file,ldap...). In questo caso l’applicazione di controllo può aggiungere la verifica dell’estensione CLR presente nel certificato verificando che il numero di serie non sia presente nella CLR pubblica. In realtà esistono anche altri meccanismi di verifica delle revoche di cui ne parleremo in futuro.

Infine le operazioni di richiesta di un certificato e di installazione nello store di Windows possono essere effettuati via codice tramite l’uso di due oggetti COM (XENROLL.DLL e CAPICOM.DLL). XENROLL.DLL permette di eseguire una richiesta di un certificato digitale in formato PKCS#10. La CA risponde con un pacchetto in formato PKCS#7 il quale può essere interpretato tramite CAPICOM.DLL che a sua volta estrae il certificato e lo installa nello store di Windows.

I Certificati e .NET

Le classi per manipolare i certificati digitali X509 sono presenti fin dalla versione 1.0 del framework ma è solo con la versione 2.0 che abbiamo il pieno accesso (soprattutto per gli store). Stiamo parlando del namespace System.Security.Cryptography.X509Certificates.

La classe principale è X509Certificate presesente fin dalla prima versione del framework che nella versione 2.0 del framework è stata estesa da X509Certificate2.

Una funzionalità molto richiesta è la visualizzazione dei certificati digitali come Internet Explorer o di Windows più in generale (sia a mo di lista che la visualizzazione dei dettagli di un certificato) . A questo scopo non è necessario crearsi la finestrella e popolarla di certificati "a mano" ma semplicemente basta ricorrere alla classe X509Certificate2UI che permette di selezionare uno o più certificati dalla lista e visualizzare il contentuo proprio come Windows.
La classe X509Certifacte2UI ha 4 metodi utili a questo scopo :
DisplayCertificate (X509Certifcate2);
DisplayCertificate (X509Certifcate2,IntPtr);
SelectFromCollection(X509Certifcate2Collection,string,string,X509SelectionFlag);
SelectFromCollection(X509Certifcate2Collection,string,string,X509SelectionFlag,IntPtr);

I primi due metodi visualizzano il certificato mentre gli ultimi due permettono di visualizzare la lista dei certificati a seconda dello store aperto.

X509Certificate2Collection scollection = X509Certificate2UI.SelectFromCollection(fcollection,
"Seleziona un certificato",
"Seleziona un certificato dalla lista",
X509SelectionFlag.MultiSelection);

 

 

Premendo su View Certificate si ottiene la classica vista del certificato di Windows. Lo stesso risultato lo si può ottenere anche richiamando direttamente il metodo DisplayCertificate (...)

Il dietro le quinte di questi metodi è molto semplice. Come vedete sia .NET che CAPICOM utilizzano la stessa Win32 Crypto API per la visualizzazione dei certificati permettendo di avere la stessa "user experience" nelle applicazioni e nel sistema.

PCCERT_CONTEXT WINAPI CryptUIDlgSelectCertificateW(
            IN PCCRYPTUI_SELECTCERTIFICATE_STRUCTW pcsc);

 

La stessa cosa vale per:

BOOL WINAPI CryptUIDlgViewCertificate(
__in PCCRYPTUI_VIEWCERTIFICATE_STRUCTW pCertViewInfo,
__out BOOL* pfPropertiesChanged );

dove pCertViewInfo è rappresentato da :

 typedef struct tagCRYPTUI_VIEWCERTIFICATE_STRUCT {
  DWORD dwSize;
  HWND hwndParent;
  DWORD dwFlags;
  LPCTSTR szTitle;
  PCCERT_CONTEXT pCertContext;
  LPCSTR* rgszPurposes;
  DWORD cPurposes;
  union {
    CRYPT_PROVIDER_DATA* pCryptProviderData;
    HANDLE hWVTStateData;
  };
  BOOL fpCryptProviderDataTrustedUsage;
  DWORD idxSigner;
  DWORD idxCert;
  BOOL fCounterSigner;
  DWORD idxCounterSigner;
  DWORD cStores;
  HCERTSTORE* rghStores;
  DWORD cPropSheetPages;
  LPCPROPSHEETPAGE rgPropSheetPages;
  DWORD nStartPage;
} CRYPTUI_VIEWCERTIFICATE_STRUCT, 
 *PCRYPTUI_VIEWCERTIFICATE_STRUCT;
typedef const CRYPTUI_VIEWCERTIFICATE_STRUCT *PCCRYPTUI_VIEWCERTIFICATE_STRUCT;

 

Per l'uso dei certificati via CAPICOM fare riferimento ai post su CAPICOM.

Nel prossimo post dedicato ai certificati approfondirò il tema degli store dei certificati in Windows.

--Mario

Comments

• Anonymous
  February 04, 2008
  Cominciamo con i ricordi... A partire da Windows NT 4 SP3 il sistema operativo è in grado di salvare

• Anonymous
  February 04, 2008
  Cominciamo con i ricordi... A partire da Windows NT 4 SP3 il sistema operativo è in grado di salvare

• Anonymous
  February 06, 2008
  Per approfondire le ultime tecnologie Microsoft, ecco alcuni link di segnalazioni, articoli e tips interessanti

• Anonymous
  February 06, 2008
  Per approfondire le ultime tecnologie Microsoft, ecco alcuni link di segnalazioni, articoli e tips interessanti

• Anonymous
  February 06, 2008
  Per approfondire le ultime tecnologie Microsoft, ecco alcuni link di segnalazioni, articoli e tips interessanti

• Anonymous
  March 31, 2008
  Ciao. Per "giocare" coi certificati, occorre per forza crearsi un certificato "Stand-alone root CA", ma la creazione sia di questo certificato, sia di quello client, si possono fare da IIS, non solo dall'url http://localhost/certsrv, vero? Grazie mille. Utilissimo post.

• Anonymous
  April 02, 2008
  Ciao Antonio, Assolutamente si. L'uso di una CA personale ti permette però di crearti certificati indipendentemente dal Web Server e con scope diversi. --Mario