Store dei certificati in Windows : tutto quello che un Architetto dovrebbe sapere

Cominciamo con i ricordi...
A partire da Windows NT 4 SP3 il sistema operativo è in grado di salvare i certificati X509 in una struttura persistente chiamata “Certificate store”. A quel tempo il supporto per la gestione dei certificati era molto limitata nelle performance, essendo un’operazione gestita in singled-Threaded, e nelle funzionalità, perchè era una semplice struttura dati salvata all’interno del registry e caricata in memoria per renderla disponibile all’applicazione. Una volta chiuso lo store i dati venivano riscritti nel registry.Inoltre, non era possibile creare dei filtri, delle viste e neppure utilizzare più store contemporaneamente.

A partire da Windows 2000 sono stati superati molti limiti presenti nelle versioni precedenti e sono state introdotte parecchie nuove funzionalità come gli store logici, la gerarchia e l’ereditarietà tra store, l’accesso remoto, il supporto per le notifiche e il multi-threaded . Il nome “store dei certificati” è rimasto nella documentazione di Microsoft anche per le versioni correnti dei sistemi operativi ma da Windows 2000 in poi tale nome è piuttosto riduttivo in quanto questi store sono dei veri e propri database specializzati per il salvataggio e la gestione di oggetti PKI come le CLR, le CTL (Certificate Trust List) oltre ovviamente ai certificati. All’interno della PKI di Microsoft le chiavi crittografiche e gli store dei certificati sono gestiti all’interno del sotto sistema di crittografia delle CryptoAPI

Figura 1 - Sistema di crittografia di Windows

Gli oggetti PKI in questo sotto sistema sono rappresentati con il termine di contesto. Un contesto è una struttura dati che contiene la forma cifrata dell’oggetto oltre ad una parte in chiaro. Gli store dei certificati non sono altro che una collezione di contesti e i certificati vengono passati all’interno del sistema tramite dei puntatori ai contesti.

Figura 2- Struttura degli store

Questo sotto sistema di crittografia è alla base di quasi tutte le operazioni di sicurezza del sistema operativo ed è messa a disposizione degli sviluppatori tramite un insieme di API, oggetti COM e codice .NET

Windows identifica gli store di default con un nome, come ad esempio Personal, Other people, Intermediate Certification Authorities, Trusted Roots e Untrusted Certificates.

Nella figura sottostante sono riportati gli store di default per un utente in Windows Server.

Figura 3- Viste sugli store dei certificati

Lo store Personal,chiamato anche MY, include tutti i certificati dell’utente, ovvero tutti quei certificati che hanno la chiave privata associata, mentre in Other people, chiamato anche Address Book, sono presenti i certificati delle persone con le quali scambiamo messaggi in modalità Envelop. Anche Outlook utilizza questo store per inserire i certificati delle persone con le quali si ha uno scambio di email cifrate (da qui il nome Address Book).

Intermediate Certification Authorities è lo store delle C.A. intermediarie, ovvero quelle che hanno i certificati di tipo C.A. ma non sono root C.A . mentre Trusted Roots include tutte le root C.A. che il sistema operativo deve considerare attendibili. Infine Untrusted Certificates è lo store di quei certificati che devono essere esplicitamente considerati non validi, una funzionalità molto simile a quella della CLR. Il sistema di crittografia di Windows crea delle viste sugli store per la macchina e per ogni profilo utente permettendo di accedere a oggetti PKI privati - i certificati nel Personal store, le chiavi private e Other People - e condivisi a tutte le viste come ad esempio Intermediate Certification Authorities e Trusted Roots.

Nello store Personal, a differenza di tutti gli altri store, la struttura dati dei certificati può includere delle proprietà che indicano il CSP (Cryptographic Service Provider) e il nome del Key-set (database delle chiavi private) contenente la corrispettiva chiave privata da utilizzare. Infatti la chiave privata non è ovviamente presente nel certificato e deve essere utilizzata solamente dal proprietario del certificato. Quando un’applicazione ha selezionato il certificato dallo store, il sotto sistema di crittografia utilizza queste informazioni per aprire un contesto con un CSP e tramite esso utilizzare la chiave privata corretta (vedi figura 2) E' compito del sistema di crittografia gestire la sicurezza e la cifratura di tali chiavi.

Quando si vuol far scegliere all'utente il certificato il modo più corretto è quello che ho descritto nel post precedente. Di solito il client (l'utente) utilizza una finestra per la scelta del certificato la quale è popolata da tutti i certificati presenti nello store Personal che hanno associato un link a un CSP (ovvero hanno una chiave privata accessibile dall’utente).

Infine, solo tramite codice unmanaged, è possibile crearsi dei propri store di certificati per registrarvi non solo certificati ma CTL, CRL ecc... Sebbene questa tecnica sia possibile è da valutare con cura la reale necessità. Una volta creato il proprio store è possibile linkarlo dinamicamente agli store logici per l'utente o per la macchina permettendo all'intero sistema delle CrypoAPI di effettuare le normali operazioni di ricerca, visualizzazione, ecc...

 BOOL WINAPI CertAddStoreToCollection(
  __in      HCERTSTORE hCollectionStore,
  __in_opt  HCERTSTORE hSiblingStore,
  __in      DWORD dwUpdateFlag,
  __in      DWORD dwPriority
);

--Mario