Security & Architecture : WInternals

Ci vediamo a ROMA??

mfontana — Fri, 06 Feb 2009 20:41:04 GMT

Il 16-17-18 Marzo a ROMA si tiene la prima edizione della conferenza BASTA! Italia. La più prestigiosa conferenza sullo sviluppo .NET tedesca sbarca in Italia !!

Il 17 mattina terrò una sessione dal titolo : Make your old applications SOA-aware with Web Services API. From Windows XP/2003 to Windows 7/2008 R2.dove parlerò della nuova architettura per i Web Services presenti nelle prossime versioni del sistema operativo Windows 7 e Windows Server 2008 R2. Sarà una sessione di livelllo 400 (Expert) per dare un po’ di internals e capire come queste API unmanged possono essere utilizzate in architetture SOA e in particolare con servizi WCF/Asmx . Per dare un po’ di background sull’argomento nei prossimi giorni pubblicherò una serie di link introduttivi. Farò comunque i primi 10 min della presentazione una overview di massima.

L’abstract:

Con Windows 7 e Windows Server 2008 R2 il sistema operativo si arricchisce di nuove API native (WWSAPI – Windows Web Services API) che permettono di estendere le applicazioni unmanaged verso le architetture a servizi.Analizzeremo le ragioni di queste nuove API, l’architettura, le possibilità di interoperabilità con il mondo .NET e Java, e i principali standard WS-* di riferimento implementati.Tramite varie demo scorreremo i principali scenari di utilizzo evidenziandone i pro e i contro.

--Mario

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

mfontana — Tue, 05 Feb 2008 13:50:35 GMT

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

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

mfontana — Fri, 01 Feb 2008 15:17:00 GMT

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 http://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

A volte ritornano... CAPICOM - parte 2 - Firma Digitale

mfontana — Thu, 31 Jan 2008 22:30:00 GMT

Partendo dall'overview della prima parte, in questa seconda parte affrontiamo il tema dell'architettura di riferimento per CAPICOM e le operazioni di firma!

Architettura su cui si basa CAPICOM

CAPICOM lavora con il paradigma dell’ architettura del sistema di crittografia di Windows XP/2003 il quale comprende tre elementi fondamentali : l’ applicazione, il sistema operativo e i Cryptographic Service Provider (CSP). Le applicazioni comunicano con il sistema operativo tramite le CryptoAPI e il sistema operativo a sua volta comunica con i CSP tramite i Cryptographic Service Provider Interface (CSPI). I CSP sono dei moduli indipendenti che eseguono tutte le operazioni di crittografia, come la generazione di chiavi di sessione (chiavi simmetriche), chiavi asimmetriche (pubblica/privata) e operazioni di firma. Alcuni CSP implementano le loro funzioni via software come ad esempio i tre CSP forniti da Microsoft: Base CSP, Enhanced CSP e Strong CSP, mentre altri le implementano tramite dispositivi hardware esterni come le smart-cards mantenendo però inalterata l’interfaccia di programmazione per il client.

Generalmente i dispositivi hardware vengono utilizzati quando il fattore sicurezza è determinante, come nelle applicazioni che integrano la firma digitale conforme alla Legge (firma di sottoscrizione prevista dal DPR 445/2000, firme digitali utilizzate per “archiviazione ottica sostitutiva” – deliberazione AIPA 24/98), oppure come il logon ad un sistema operativo. Per ragioni di sicurezza e di portabilità le applicazioni che richiedono i servizi di crittografia tramite i CSP possono scegliere varie opzioni come il tipo di algoritmo da usare per la firma elettronica o per l’ encryption e la lunghezza delle chiavi. Tuttavia non è possibile interagire direttamente con i dati interni del CSP, infatti per accedere alle chiavi di crittografia le applicazioni utilizzano come riferimenti degli “opaque handle”.

Ciò che distingue un CSP da un altro è il grado di sicurezza che implementa al suo interno, dato dalla lunghezza delle chiavi che è in grado di gestire e dagli algoritmi implementati.
Fisicamente i CSP sono composti almeno da un file con estensione .DLL che consente le operazioni di crittografia, e da una firma elettronica che Windows utilizza per verificare l’integrità del sistema.

Se il CSP è stato sviluppato per ambienti misti (Windows 98, Windows NT e Windows 2000) la firma utilizzata per garantire l’integrità del CSP risiede nel registry, mentre se il CSP è stato scritto per sistemi operativi Windows 2003/XP la firma può essere una risorsa dello stesso file .DLL. In questo caso si evidenzia che la risorsa deve avere una dimensione fissa di 144 bytes e deve essere identificata dal numero 0x29A, rendendo così meno probabile un disallineamento in fase di installazione o aggiornamento.

Esistono vari esempi di utilizzo dei CSP e delle CryptoAPI da parte del sistema operativo: l’EFS (Encryption File System) di Windows XP/2003, ad esempio, si basa sulle CryptoAPI per la generazione delle chiavi simmetriche e per le operazioni di cifratura; Authenticode, servizio che verifica la provenienza e l’integrità dei componenti scaricati tramite Internet/Intranet, gestisce la verifica della firma dei componenti per mezzo delle CryptoAPI e quindi i CSP. Anche i programmatori hanno a disposizione componenti “out of the box” che fanno largo utilizzo dei CSP, come WININET.DLL, libreria ad alto livello per l’utilizzo - lato client - dei protocolli Internet come HTTP, FTP, Gopher e HTTPS .

Ogni CSP ha un database delle chiavi chiamato “Key database” il quale contiene uno o più “Key containers” all’interno dei quali vengono effettivamente registrate le coppie di chiavi pubblica/privata di tipo signature ed exchange. Le prime sono utilizzate per operazioni di firma elettronica, le altre per cifrare le chiavi di sessione.

Questi key containers hanno un nome univoco che permette ai client di connettersi tramite CryptAquireContext, un’ API appartenente alla famiglia delle CryptoAPI.

L’ActiveX CAPICOM, essendo un wrapper delle CryptoAPI, si interpone tra le applicazioni e le CryptoAPI.

CAPICOM sfrutta la dual interface, ovvero combina i metodi IDispatch e custom all’interno della stessa vTable, permettendo ai client Automation l’uso di una sola parte della vTable. In questo modo viene estesa la possibilità di utilizzo delle funzioni di crittografia ad un ampio ventaglio di ambienti di programmazione anche ad alto livello.

Firma Digitale con CAPICOM

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 (numeri) 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 è 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 signature scheme 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 bits 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 digital signature e non per l’encryption a chiavi asimmetriche. Viceversa RSA è più veloce nelle operazioni di verifica e può essere utilizzato per l’encryption 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 o impronta. 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). In questo contesto parleremo espressamente di Hash unkeyed e in particolare della sottoclasse MDC (Modification detection codes)

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 impronte uguali partendo da input diversi.

Sebbene le CryptoAPI supportano molti algoritmi di Hash, CAPICOM per le operazioni di firma utilizza lo SHA-1 e 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 un 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 operazione 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 entrambe le impronte 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).

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 nello store 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 files 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 files contenenti le firme vengono salvati nel formato standard PKCS#7 rendendo possibile l’eventuale operazione di verifica anche tramite altre applicazioni PKI.

volendo "esplodere" il formato PKCS#7 otteniamo:

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.

Un Sempio in HTML

Anche una semplice pagina HTML può fungere da container per CAPICOM permettendo all' utente di inserire le proprie informazioni e firmarle digitalmente.
Questo esempio lo trovate all'interno del CAB di installazione di CAPICOM.

1) una banalissima form

2) Selezionate il certificato. Dovete avere almeno 1 certificato nel personal store dei certificati, ovvero almeno un certificato con la chiave privata associata.

3) e premete FIRMA. Quello che si vede è il famoso pacchetto PKCS#7 encodato in BASE64

4) Premendo verifica si ottiene il controllo del pacchetto pkcs#7.

Un Sempio .NET/CAPICOM

Un esempio più significiativo che trovate semre nell' SDK è questo progetto .NET che utilizza CAPICOM per creare la struttura di XMLDSIG (EXML DIgital Signature). Il .NET framework è in grado fin dalle prime versioni di gestire la specifica XMLDSIG ma in questo caso si può vedere l'utilizzo congiunto .NET/CAPICOM

Nel prossimo post parlerò delle varie forme di encryption supportate da CAPICOM e alcuni tips & tricks

--Mario

A volte ritornano... CAPICOM - parte 1 - Overview

mfontana — Thu, 31 Jan 2008 02:01:00 GMT

Ieri, essendo a letto con l'influenza, stavo girovagando qua e là per internet (esiste anche un altro termine molto più appropriato :-) che eviterebbe il giro di parole) ed alla fine mi sono ritrovato ad analizzare le keywords più utilizzate per arrivare sul mio blog...e una voce tra le prime 10 mi ha colpito particolarmente : CAPICOM. Mi ha colpito per vari motivi primo fra tutti perchè nei soli ultimi due mesi è stata cercata quasi un centinaio di volte tramite il mio blog. In secondo luogo CAPICOM non è più "giovanissimo" ma pare riscuotere ancora parecchio fascino nonostante la quasi totalità delle sue funzioni siano oggi disponibili nel framework .NET. Infatti qui in Microsoft ogni tanto arrivano ancora richieste di "aiuto" e supporto all'uso di CAPICOM.
La prima volte che scrissi di CAPICOM 1 era nel lontano 2002 sul numero 111 e 112 della rivista Computer Programming (ancora bloccate dalla lettura se non abbonati). Alcune parti di quegli articoli nel tempo sono stati usati/ripresi in varie pubblicazioni di terzi ed è quindi con un po' di dispiacere che ho notato che in un solo caso l'intero contenuto di entrambi gli articoli (disegni e bibliografia compresi) sono stati usati pari pari senza nemmeno mettere me o Infomedia nella bibliografia. Dico questo perchè per la sola parte di overview riutilizzerò alcune parti scritte allora (ovviamente con vari aggiornamenti ed estensioni) e non vorrei essere additato come copista, se non copista di me stesso :-).

Cosa è CAPICOM

Lo sviluppo di applicazioni che integrano elementi di crittografia è stato per molto tempo dominio dei programmatori C++: la programmazione era complessa ed era richiesto un buon grado di conoscenza delle specifiche API del sistema operativo (CryptoAPI) e dei fondamenti di crittografia. Con il rilascio del Microsoft Platform SDK di Febbraio 2001 è stato incluso un nuovo componente COM (CAPICOM.DLL, acronimo di CryptoAPI COM) per le funzioni base di crittografia estendendole quindi in modo “naturale” anche ai programmatori Visual Basic, Visual FoxPro,VB Script, Java Script, ASP e a qualsiasi altro linguaggio che supporti lo standard COM, .NET compreso.

Con .NET 1.0 e 1.1 il supporto alle operazioni di crittografia (soprattutta la firma) era piuttosto lacunoso in quanto non c'era un diretto supporto agli store dei certificati rendendo quindi difficile l'uso in programmi di commercio elettronico o similare. La soluzione migliore era qualla di usare CAPICOM 2.0 per il supporto completo dello store anche se questo comportava delle trasformazioni per passarsi l'oggetto Certificate che in .NET e CAPICOM hanno strutture ben diverse. Fortunatamente con la versione 2.0 del framework non c'è più bisogno di ricorrere a questi escamotage.

CAPICOM permette di aggiungere un insieme di funzionalità base di crittografia a chiave simmetrica e asimmetrica senza entrare nel “variopinto” mondo delle CrytpoAPI tramite una serie di metodi e proprietà. Le principali funzioni del componente sono la firma elettronica, la verifica, l’encryption e il decryption, la gestione dei certificati e la gestione degli store dei certificati, l'uso di hash e di alcune funzioni di utilità varie. Più nel dettaglio CAPICOM supporta lo standard X.509, rendendo possibile l’utilizzo di certificati

Rilasciati da una qualsiasi Certification Authority (CA) commerciale come Verisign e Thawte
Generati da una infrastruttura PKI di Windows.
Autogenerati con l’utility makecert.exe. (certificati di test)

CAPICOM 2.1.0.2 è la versione ad oggi più recente ed è l'unica ad essere supportata in Windows Vista !!! Inoltre CAPICOM esiste solamente nella versione a 32-bits!!!

CAPICOM quindi è un "semplice" wrapper sulle CryptoAPI e come tale non è il veicolo di nessun nuovo algoritmo o classe di algoritmi. Infatti effettua le operazioni di crittografia supportate dal sistema operativo o da eventuali estensioni (non CAPICOM) ed inoltre non esporta tutte le funzionalità presenti nelle CrytoAPI 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, l’ encryption di dati con chiave simmetrica e asimmetrica e la gestione di certificati.

Sebbene in molti esempi che si trovano in giro si faccia sempre riferimento a codice eseguito client-side, CAPICOM è stato sviluppato per girare anche in ambiente server side. Questa caratteristica permette di utilizzare CAPICOM anche all'interno di servizi o Web Services.
In una tipica applicazione a più livelli l' oggetto CAPICOM viene creato all’interno di pagine ASP/ASP.NET o gestiti da 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 (a seconda anche della confiugrazione dell' application pool, del worker process e delle configurazioni del web.config). 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 processa delle richieste. Questo aspetto diventa molto importante lavorando con gli store dei certificati poiché ogni utente ha il proprio store 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’ identity 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 più livelli o comunque a servizi, si consiglia di utilizzare, quanto possibile, lo store di sistema che si trova in HKEY_LOCAL_MACHINE.

CAPICOM serve a...

Volendo schematizzare al massimo le funzionalità di CAPICOM possiamo dire :

Firma digitale con encoding ASN.1 e supporto allo standard PKCS#7
Supporto a smart-card riconosciute da Windows
Encryption a chiave simmetrica
Encryption a chiave asimmetrica (envelop)
Calcolo di Hash
CodeSigning per Authenticode
Utilities per il supporto di conversioni di stringhe e generazioni di numeri pseudo-casuali.
Interfacce di supporto tra le CryptoAPI e gli oggetti CAPICOM e viceversa
Supporto ai certificati X509
Supporto agli store dei certificati.
Ricerche all'interno degli store
Supporto ai Certificate Policies, Application Policies e templates
Supporto per esportazione informazioni sensibili via PFX e PKCS#12
Supporto di AES per l'encryption (solo su XP e superiori)

e come vedremo nei prossimi post quello che colpisce maggiormente è la sua semplicitià di utilizzo.

Installazione e distribuzione di CAPICOM

L’installazione di CAPICOM può avvenire in varie modalità a seconda degli scenari. Il primo scenario, il più semplice (per i tecnici) e il più veloce è sicuramente quella manuale. Questa è l'opzione che spesso utilizzano gli sviluppatori sulle proprie macchine di sviluppo e di test ovvero la registrazione del un solo file capicom.dll tramite regsvr32.exe, oppure installando la DLL con il setup dell’applicazione.

Una seconda modalità in ambiente enterprise è tramite i processi di software distribution.

Una terza modalità riguarda gli scenari WEB based dove non abbiamo la possibilità di creare un processo di deployment controllato. In questo caso l'installazione è possibile tramite l’installazione del componente COM tramite il tag

<object classid="clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679" codebase = http://hostname/myApp/capicom.dll#version=2,1,0,2>

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.

La quarta modalità, infine, prevede la creazione di un file .INF e tramite le utility makecab.exe o cabarc.exe, si genera un file .CAB, lo si firma con signcode.exe(Le ultime versioni di queste utility sono disponibili nel Microsoft Platform SDK.), e si effettua il download da una pagina HTML. 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.

Sistemi supportati

Versione 1.0

Windows 95/98/ME with Internet Explorer 5 or later
Windows NT® 4.0 with SP4+
Windows 2000
Windows XP/.Net Server

(se non per il supporto ad applicativi su W95 e NT4 non c'è ragione di usare la versione 1.0)

Versione 2.0

Windows 2000 Service Pack 4
Windows Server 2003 Service Pack 1
Windows Server 2003 Service Pack 2
Windows XP Service Pack 2
Windows Vista (nella sua ultima versione)

La seconda parte di questa serie di articoli sarà dedicata alla firma digitale con CAPICOM.

--Mario