Security & Architecture : Crittografia

Ancora sull’Application Security : SSL è superato dalle specifiche WS-* ??

mfontana — Mon, 22 Jun 2009 08:01:00 GMT

Non credevo di suscitare tanto interesse con questo mio precedente post :-) ma ne sono contento perchè questo conferma una buona sensibilità verso l’application security.

Ho ricevuto molte email riguardo l’uso di SSL alcune delle quali mi chiedevano se tale protocollo è da considerarsi ancora sicuro. Vedo di sintetizzare un po’ di miei pensieri… sperando di continuare il dibattito :-)

**SSL è superato dal WS-*?**

Assolutamente NO... e ci mancherebbe altro! Sono due mattoni importanti per la messa in sicurezza di un sistema. Sono complementari anche se hanno molte "funzionalità" in comune. Infatti, in alcuni contesti devono essere utilizzati obbligatoriamente entrambi, come ad esempio durante lo scambio di un UsernameToken definito dalla specifica WS-Security:

<xsd:element name="UsernameToken">
   <xsd:complexType>
     <xsd:sequence>
       <xsd:element ref="Username"/>
       <xsd:element ref="Password" minOccurs="0"/>
     </xsd:sequence>
     <xsd:attribute name="Id" type="xsd:ID"/>
     <xsd:anyAttribute namespace="##other"/>
   </xsd:complexType>
</xsd:element>

Infatti, in questo caso durante lo scambio del token il network si deve fare carico dell’encryption del canale! Volendo schematizzare le affinità e le differenze tra l’uso di SSL e lo stack WS-*:

Affinità:

- Entrambi garantiscono Autenticazione, Integrità e riservatezza sebbene lo stack WS-* tramite XMLENC e XMLDSIG sia molto più espressivo.

- E’ sempre il sistemista che interviene sulle configurazioni del server per SSL come può intervenire sulle policy del servizio per modificare le caratteristiche dei messaggi SOAP (+ o -).

Differenze:

molte! Prima di tutto WS-* prevede il supporto a SOAP mentre SSL no, WS-* NON è applicabile in tutti i contesti di Web-Applications invece SSL si.

SSL è implementato al livello 5 della famosa pila mentre i WS-* sono in quello definito “nuovo layer 8”. Questo comporta alcune considerazioni di sicurezza importanti..prima tra tutte che il livello 4 (TCP) e 5 da un punto di vista di sicurezza si occupano solamente del mittente. Non è una cosa da poco. Si pensi agli scenari SOA e SaaS. SSL è semplicemente un canale cifrato tra due end-point e non è possibile estendere il conteso di cifratura ad altri server (intermediari) creando possibili “vulnerabilità” nel flusso dei dati. Il contesto di sicurezza dell’applicazione NON è la sommatoria dei singoli contesti. WS-Security & family, al contrario spostando le informazioni di sicurezza direttamente all’interno dell’header del messaggio SOAP, consente di avere un numero arbitrario di intermediari e di protocolli di rete anche non sicuri garantendo però il contesto di sicurezza dell’applicazione.

SSL è un protocollo“state-full” ovvero deve mantenere uno “stato” tra il client e il server; il client instaura una connessione con un determinato server e il suo flusso non può essere deviato ad altri server (l’handshake tra il client e il server ha lo scopo di scambiarsi delle chiavi simmetriche – tramite delle chiavi asimmetriche - che entrambi utilizzano per cifrare il canale) perchè non sono in possesso delle corrette chiavi simmetriche per decifrare i dati. In questo scenario è indispensabile ricorrere ad un intervento sistemistico impostando i valori di “affinity” che associano un client sempre allo stesso server riducendo notevolmente la scalabilità applicativa. Al contrario WS-Security, basando interamente la propria struttura a livello del messaggio può usufruire di scelte infrastrutturali più scalabili.

Se ci spostiamo su WS-SecureConversation, lo scenario cambia nuovamente, ritorniamo alla necessità di avere una chiave simmetrica condivisa, o meglio, un contesto di sicurezza condiviso (SCT- Security Context Token).Per risolvere la ridondanza dei servizi si hanno 3 opzioni:

1) Sistemistico tramite affinity proprio come SSL.

2) Misto:tramite un database di SCT condiviso da tutti i server bilanciati.

3) Applicativo, estendendo lo schema del SCT. (possibili problemi di compatibilità con terze parti o comunque con software non aware del nuovo schema)

Considerazioni su SSL

SSL è un ottimo protocollo crittografico ma per quanto riguarda la sicurezza (non la crittografia) siamo ben lontani !! Innanzitutto il meccanismo di protezione non è efficace per quegli utenti “distratti” che non vanno a verificare TUTTE LE VOLTE l’URL nel browser con l’indirizzo specificato nel certificato. Inoltre, il famoso warning di incongruenza di dati del certificato viene sempre ignorato (= OK) permettendo, se va male, l’attacchi basato su ip-spoofing,ecc... E’ anche vera una riflessioncina : a prescindere da tutto, se un amministratore di un sito gestisce così il protocollo SSL c’è da chiedersi come gestisca l’intero sistema ...Mah..

A questo proposito a partire da Windows Vista è stato introdotto il supporto agli Extended Validation SSL Certificates http://www.microsoft.com/windows/ev. Sicuramente utile ma prima di tutto devono essere adottatti largamente dai gestori dei siti!!!!

SSL fonda la sua sicurezza pesantemente sulla robustezza dei cifrari asimmetrici e simmetrici utilizzati (come anche WS-*), cambia spesso la chiave di sessione (5min di default) e mitiga il reply tramite il Connect_id.

A questo punto volendo schematizzare i pro e i contro nell’ uso di SSL :

*SSL PRO*	*SSL CONTRO*
Standard	Dispendioso per la CPU
Autenticazione, integrità e riservatezza	Session oriented
Nessun vincolo di linguaggi di programmazione	Implementazione solo su HTTP (non per motivi tecnici o di specifica).
Nessun vincolo di pattern di sicurezza applicativa	Valido solo su singolo hop
“Gratis” per chi disegna ed implementa le applicazioni.	Non assicura i dati una volta arrivati al server.
	NON ESONERA GLI SVILUPPATORI DALLO SCRIVERE CODICE SICURO J

Attacchi e Contromisure

Di SSL ormai si sa (quasi) tutto. Gli attacchi principali al protocollo SSL sono noti mentre per lo stack WS-* se ne conoscono ancora relativamente pochi.

Per quanto riguarda SSL l’ultimo in ordine di tempo è l’ attacco basato sul BVO(Bad-version Oracle). (nulla a che vedere con il famoso produttore di Database :-) )

SSL/TLS utilizza l’encoding PKCS#1 (v1.5) per l’encryption del pre-master-secret (valore utilizzato per la derivazione delle session keys).Un hacker che riesce a recuperare il premaster-secret può decifrare l’intera sessione SSL.L’attacco principale è una derivazione dell’attacco di Bleichenbacher per il PKCS#1.Parte dal presupposto che il meccanismo di versioning del PKCS#1 permette di creare un side-channel che permetta di invertire l’encryption recuperando il premaster-secret e/o firmarndosi come server!Questo attacco riesce entro le 54 ore con chiavi asimmetriche a 1024.

Inoltre, se si dispone di proxy server sarebbe consigliato configurare l’analisi dei primi passi del traffico dell’handshake di SSL per evitare che venga fatto del tunneling di un protocollo non autorizzato su una porta aperta (443 di default).

Per quanto riguarda le contromisure agli attacchi a SOAP/WS-* siamo messi (forse) peggio! Già durante la WPC 2007 ho presentato un sunto di vari attacchi a partire da SOAP fino alle specifiche più complesse come WS-Security e spero a breve di riuscire a sintetizzarli in uno o più post !! In questo articolo prendiamo in esame uno degli aspetti più importanti di WS-Security : la dipendenza da XMLENC e XMLDISG (per sapere come sono fatti leggete qui e qui). Infatti da alcuni anni orami sono noti vari attacchi di tipo DoS a queste strutture. L’attacco verte sulla funzione di verifica/decrypt dei dati. Ad esempio in XMLDSIG l’elemento Reference raccoglie l’informazione da firmare. Lo schema di Reference :

mostra chiaramente che il contenuto da firmare non è il documento stesso, ma bensi l’hash del documento (DigestMethod e DigestValue) più le informazioni di rappresentazione.

Poichè il processo di verifica della firma prevede il ricalcolo dell’hash dell’oggetto firmato, cosa succede se l’URI del Reference indica ad esempio il SP1 di Windows 2003 ?? Il Thread di IIS che sta processando il codice applicativo si scarica 315 Mb per poter calcolare l’hash... moltiplichiamo la richiesta n volte e, etvoilà...HABEMUS DoS Attack...

Contromisure? Beh, applicative e di content analisys da parte dei firewall. In alcuni contesti è possibile implementare alcuni pattern di sicurezza come il Message Validator oppure dedicare uno o più Perimeter Service Router applicativi.

In sintesi le contromisure per gli attacchi a SSL sono di competenza dei sistemisti :-) mentre quelli a livello applicativo spesso sono distribuiti tra sistemisti e architetti/sviluppatori.

E’ però importante sottolineare che per quanto riguarda la messa in sicurezza di una applicazione l’uso di SSL o WS-* non significa NULLA o quasi. Gli attacchi applicativi tipo Buffer Overrun, SQL-Injection, XSS, Code-inj.,Canonicalization attacks, Ecc... avvengono ne più ne meno...perchè il 95% di codesti attacchi è riconducibile ad un unico antipattern tipico di chi sviluppa : (mancanza) di INPUT VALIDATION !!!!

Qunidi, alla domanda più ricorrente che ci sia in questo ambito :”quando una applicazione può esserer considerata (più) sicura? non posso che rispondere in questo modo : quando è stata sviluppata seguendo il processo di SDL fin dal principio :-)

--Mario

PS : Se volete saperne di più sulla sicurezza applicativa, da cosa è composta e come dovrebbe essere affrontata leggete questo mio post dal titolo : Perchè la sicurezza applicativa è così ostica ?

C’è ancora chi usa l’ MD5 nelle nuove applicazioni?? Certo !

mfontana — Wed, 29 Apr 2009 12:53:57 GMT

Segnalo questo bel post di Roberto Scaccia sul’analisi di sicurezza del codice e l’utilizzo dell’algoritmo MD5…

--Mario

Visualizzare messaggi SOAP protetti da SSL

mfontana — Tue, 31 Mar 2009 12:00:00 GMT

Durante la mia sessione alla conferenza Basta!Italia ho fatto vedere come analizzare il traffico SOAP tra due servizi protetti da SSL presenti sulla stessa macchina di sviluppo (scenario molto comune quando si programma :-). L’obiettivo era quello di visualizzare il Security Token di tipo Username & Password definito da WS-Security all’interno dell’header SOAP. Nel caso specifico, poichè le Windows Web Services API (WWSAPI) non sono in grado di garantire la sicurezza a livello di messaggio, l’obiettivo era quello di visualizzare il Token creato dalle WWSAPI anche se usavamo SSL per il trasporto !!

Anche in questo caso, come in quello precedente, le impostazioni che faremo sono da considerarsi solo per le macchine degli sviluppatori e non in produzione !! Userò ancora il tag <WARNING> per evidenziare le configurazioni pericolose per la produzione.

In questo scenario ho fatto le seguenti configurazioni:
<WARNING>.

Nel file hosts ho configurato : 127.0.0.1 BastaConferenceWebServices.com
Certificati:

Verificare che il nostro Reverse-Proxy (Charles, ma si può utilizzare anche Fiddler) abbia installato il proprio certificato in Current User->Trusted Root Certification Authorities.
Creare il certificato SSL via makecert.exe (o via CA) con il parametro : -n "BastaConferenceWebServices.com" (Maggiori info qui)
Installare il certificato appena creato in Local Computer ->Trusted Root Certification Authorities e in Local Computer –>Personal .
Associare il certificato appena creato con la porta 127.0.0.1:8444 via netsh.exe (Maggiori info qui)
Impostare l’URL reservation (con l’utility : netsh http add urlacl – maggiori info sempre qui ) dato che sicuramente il Web Service NON lo faremo girare con le credenziai di amministratore, nemmeno durante lo sviluppo… vero??? ;-)

Configurare Charles come Reverse Proxy
Dare OK e lanciare il Web Service e il client.

</WARNING>.

Alla fine della configurazione dovremo avere uno scenario di questo tipo:

dove il client parla sulla 2051 pensando di parlare con il nostro Web Service. Sulla 2051 c’è il Reverse Proxy che crea la connessione SSL con il client, accetta il messaggio SOAP, lo logga e diventa il client SSL per il Web Service (vero) sulla 8444.

Vi sembra familiare?? Ebbene si. Questo è il tipico esempio di attacco Man-in-the-Middle, ma usato a fin di bene :-). Prima che venga il dubbio che quindi SSL non è sicuro ricordo che nessun protocollo è veramente sicuro se sono amministratore di tutto l’ambiente !!!

Infatti in questo modo possiamo visualizzare il messaggio del client:

    1 <s:Envelope … TRONCATO…>
    2   <s:Header>
    3     <a:Action s:mustUnderstand="1">http://Example.org/ICalculator/Add</a:Action>
    4     <a:MessageID>urn:uuid:1bcbe628-18e6-484b-8ed4-363d59ad0fae</a:MessageID>
    5     <a:To s:mustUnderstand="1">https://BastaConferenceWebServices.com:2051/example</a:To>
    6     <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    7       <Timestamp xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    8         <Created>2009-03-26T15:21:04.786Z</Created>
    9         <Expires>2009-03-26T15:26:04.786Z</Expires>
   10       </Timestamp>
   11       <o:UsernameToken>
   12         <o:Username>usr1</o:Username>
   13         <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">
   14           pwd1
   15         </o:Password>
   16       </o:UsernameToken>
   17     </o:Security>
   18   </s:Header>
   19   <s:Body>
   20     <Add xmlns="http://Example.org">
   21       <a>1</a>
   22       <b>2</b>
   23     </Add>
   24   </s:Body>
   25 </s:Envelope>

Con relativa risposta :

    1 <s:Envelope … TRONCATO…>
    2   <s:Header>
    3     <a:Action s:mustUnderstand="1">http://Example.org/ICalculator/AddResponse</a:Action>
    4     <a:RelatesTo>urn:uuid:1bcbe628-18e6-484b-8ed4-363d59ad0fae</a:RelatesTo>
    5     <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    6       <Timestamp xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    7         <Created>2009-03-26T15:21:05.921Z</Created>
    8         <Expires>2009-03-26T15:26:05.921Z</Expires>
    9       </Timestamp>
   10     </o:Security>
   11   </s:Header>
   12   <s:Body>
   13     <AddResponse xmlns="http://Example.org">
   14       <result>
   15         3
   16       </result>
   17     </AddResponse>
   18   </s:Body>
   19 </s:Envelope>

--Mario

Windows Web Services API : Configurazione Certificati e sicurezza per gli esempi con SSL

mfontana — Mon, 30 Mar 2009 14:07:00 GMT

Tutti gli esempi che ho creato nei post precedenti erano su HTTP quindi senza sfruttare la sicurezza di trasporto (SSL). Ora vediamo quali passi sono necessari per configurare la comunicazione su SSL (uso questo esempio su MSDN )

IMPORTANTE !!! In questo post alcune delle configurazioni che faccio sui certificati digitali possono risultare molto pericolose su macchine di produzione… In un ambiente di produzione il rilascio,l’installazione e la manutenzione dei certificati deve essere seguito secondo i processi definiti dalla PKI !! Al contrario, sulle macchine dei sviluppatori spesso risulta necessario farsi delle configurazioni ad hoc per essere autonomi rispetto ai colleghi sistemisti :-) :-). Per facilitare la cosa metterò un tag <WARNING!!> su tutte quelle procedure da non riprodurre in produzione !!

Innanzitutto i passaggi per impostare i progetti client e service e il processo di creazione dei file .c e .h dal wsdl sono sempre i medesimi descritti qui e qui.

Per far si che il nostro Web Service possa utilizzare il protocollo SSL è necessario configurare quale certificato verrà utilizzato per l’inizializzazione del protocollo. Ce lo ricorda anche un commento nel codice presente in tutti gli esempi su MSDN che utilizzano SSL

// NOTE: At the server, the SSL certificate for the listen URI must be
// registered with http.sys using a tool such as httpcfg.exe.

Questa operazione andrà eseguita perchè faremo noi l’hosting del Web Service all’interno di una Win32 console al posto di IIS !!

In questo post utilizzerò l’utility netsh.exe invece di httpcfg.exe

Per prima cosa dovremo procurarci un certificato digitale X509v3. Se non riusciamo ad avere in tempo un certificato da una CA allora seguite questi semplici passi:

<WARNING!!>

usiamo l’utility makecert.exe per creare ed installare il certificato nel certificate store di Windows. (maggiori info sui certificati e sugli store in Windows). Apriamo una console di Visual Studio in Administrator mode e lanciamo :

makecert -r -pe -n "CN= 127.0.0.1" -b 01/01/2009 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

</WARNING!!>

Tramite questo comando abbiamo creato un certificato per “Ensure the identity of a remote computer” e “All issuance policies” ed è stato installato nel certificate store della macchina (local machine). Apriamo la mmc dei certificati e clicchiamo sul certificato in Certificates (Local Computer)->Personal->Certificates e dovremmo vedere una cosa simile a quanto riportato in figura.

a questo punto se proviamo a lanciare il nostro esempio riceviamo il seguente errore :

Failure: errorCode=0x803d0014
There was an error communicating with the endpoint at 'https://127.0.0.1:8999/example’.
The connection with the server was terminated abnormally

questo perchè non abbiamo ancora creato il binding tra l’URI e il certificato digitale nel nostro kernel mode http listener(Http.sys) e quindi il protocollo SSL non può funzionare. Infatti se lanciamo il seguente comando :

netsh http show sslcert

abbiamo una lista dei certificati configurati per SSL con relativo IP:port e hash del certificato! Ovviamente il nostro 127.0.0.1:8999 non esiste. Quindi lo creiamo lanciando il seguente comando :

netsh http add sslcert ipport=127.0.0.1:8999 certhash=a455de0b81ce3251d177d9fb74c62fe237a49ae1 appid={00112233-4455-6677-8899-AABBCCDDEEFF}

In questo caso abbiamo impostato il parametro ipport=127.0.0.1:8999 e certhash con l’hash del nostro certificato appena creato. Per ottenere il valore dell’hash dobbiamo aprire il certificato e alla voce Thumbprint nella tab Details copiare il contenuto. Ricordarsi di togliere gli spazi !!!

se ora rilanciamo il comando

netsh http show sslcert

potremo vedere il nuovo binding sulla porta 8999

Se proviamo ora a lanciare il nostro esempio riceviamo un altro errore:

Failure: errorCode=0x803d000a
There was an error communicating with the endpoint at 'https://127.0.0.1:8999/example’.
The certificate authority is invalid or incorrect

infatti come si vede anche dalla figura 1 il certificato che abbiamo creato ed installato non è valido dal punto di vista della “Certification path”. Per rimediare a questo problema basta copiare il certificato da

<WARNING!!>

Certificates (Local Computer)->Personal->Certificates

a

Certificates (Local Computer)->Trusted Root Certification Authorities->Certificates

</WARNING!!>

a quel punto, se riclicchiamo sul certificato all’interno di Certificates (Local Computer)->Personal->Certificates avremo :

che ci assicura che tutta la “Certification path” è corretta.

Finalmente, se ora lanciamo il Web Service e il client il tutto funziona con il protocollo SSL !!!! Finito?? Non direi :-)

NOOOOO… UN WEB SERVICE CHE GIRA SOLO COME ADMINISTRATOR???

In effetti, se ci fermiamo qui i nostri Web Services girano solo se hanno le credenziali di amministratore !!! Orrore !!! Infatti se creiamo due local Users demo1 e demo2 (aggiungere la policy longon locally se si tratta del server) e dalla nostra console amministrativa lanciamo

runas /user:demo1 cmd.exe (dopo l’invio ci chiede la password)

runas /user:demo2 cmd.exe (dopo l’invio ci chiede la password)

se nella cmd di demo1 ad esempio lanciamo il nostro service (che prima funzionava nella console che gira come admin) avremo come risposta :

Failure: errorCode=0x80070005
Unable to add URL to HTTP URL group.
Access is denied.

Per superare questo ultimo scoglio dobbiamo assegnare i permessi ad un gruppo di utenti (o ad un singolo utente nel nostro caso, per semplicità) per un determinato HTTP URL namespace. Con questa operazione di fatto diamo la possibilità di creare dei servizi di listener su determinati URL a tutti i processi che girano con le credenziali definite. Questa operazione verrà effettuata, ad esempio, durante il processo di installazione dei nostri servizi. Per fare questa operazione lanciamo il comando :

Netsh http add urlacl url=https://127.0.0.1:8999/example user=demo1

e possiamo visualizzare il nuovo namespace reservation tramite il comando :

Netsh http show urlacl

a questo punto se rilanciamo il servizio sempre dalla console demo1 … funzionerà !!! mentre se lo lanciamo dalla console demo2 no !!

La prova del nove? Dalla console amministrativa lanciate il comando:

Netsh http delete urlacl url=https://127.0.0.1:8999/example

che cancella nuovamente la reservation e vedrete che se rilanciate il vostro Web service sempre dalla console demo1 non funzionerà nuovamente :-)

Un paio di Curiosità

1) Dove vengono registrate le info di netsh.exe ?

Tutte le impostazioni vengono salvate nel registy :

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

e in

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\UrlAclInfo

2) Quali API devo utilizzare per crearmi programmaticamente una URL reservation?

Le API di riferimento sono le HTTP Server API Reference.
Alla fine il tutto si risolve tramite le API

ULONG HttpInitialize( __in HTTPAPI_VERSION Version,
__in ULONG Flags,
__reserved PVOID pReserved );

ULONG HttpSetServiceConfiguration(
  __in  HANDLE ServiceHandle,
  __in  HTTP_SERVICE_CONFIG_ID ConfigId,
  __in  PVOID pConfigInformation,
  __in  ULONG ConfigInformationLength,
  __in  LPOVERLAPPED pOverlapped
);

Stavo per scrivere il wrapper in C# via p/Invoke ma grazie a Keith Brown ho risparmiato almeno un’oretta di lavoro :-). Anche in questo caso, esclusi i vari controlli il tutto si riduce nelle due chiamate alle HTTP API.

// Inizializzazioni varie delle HTTP API

…

// Impostazione delle ACL

int errorCode = HttpInitialize(httpApiVersion,HTTP_INITIALIZE_CONFIG, IntPtr.Zero);

errorCode = HttpSetServiceConfigurationAcl(IntPtr.Zero, HttpServiceConfigUrlAclInfo,ref configInfo, Marshal.SizeOf(typeof(HTTP_SERVICE_CONFIG_URLACL_SET)),IntPtr.Zero);

//Chiamte a Funzioni HTTPAPI di CleanUp…

…

Infine, mi raccomando di ricordarsi di cancellare o disattivare gli utenti locali demo1 e demo2 e di cancellare i certificati quanto prima !!!

--Mario

A volte ritornano... CAPICOM - parte 3 - Encryption

mfontana — Thu, 14 Feb 2008 12:58:35 GMT

In crittografia l’informazione in chiaro viene chiamata “plaintext” mentre lo stesso dato cifrato viene denominato “ciphertext”.

L’encryption è la procedura che converte il paintext in ciphertext, il decription è la funzione inversa che converte il ciphertext in plaintext.
Con CAPICOM è possibile effettuare due distinte operazioni di encryption : 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.

IEncryptedData

La cifratura a chiave simmetrica ha la caratteristica di utilizzare la stessa chiave, detta anche session key, per cifrare e decifrare

Queste chiavi sono un numero random 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 Initialization vector (IV) uguale a zero. Infatti questa è la modalità di default della API CryptDeriveKey utilizzata appunto per la generazione delle session key 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. Sulla documentazione MSDN trovate l’ordine di ricerca che CAPICOM effettua in questo caso.

I tre metodi, 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 AES.

Dim enc As New CAPICOM.EncryptedData

Dim cipher As String

Dim secret as String

secret = “:P@assword@01#"

//ENCRYPTION

enc.Content = “WoW…This is a secret!!!!"

enc.Algorithm = CAPICOM_ENCRYPTION_ALGORITHM_AES

enc.SetSecret (secret)

cipher = enc.Encrypt(CAPICOM_ENCODE_BASE64)

//a questo punto cipher contiene il secret cifrato ed encodato in BASE64

//DECRYPTION

Dim plaintext As String

Dim dec As New CAPICOM.EncryptedData

dec.Algorithm = CAPICOM_ENCRYPTION_ALGORITHM_AES

dec.SetSecret (secret)

dec.Decrypt (cipher)

plaintext = dec.Content

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.

Prima di passare a IEnvelopedData facciamo un altro esempio:

Una volta premuto il tasto Encrypt si ottiene il seguente output:

MIGUBgkrBgEEAYI3WAOggYYwgYMGCisGAQQBgjdYAwGgdTBzAgMCAAECAmYCAgIA
gAQIRSuTnPybKWEEEDko8rnajaH9lHfFe4s8IvgESDkTa5RySG7MX4SXPI9KU1vk
xMG08Ne3tm7ziGYoL4PVaKruDNRUKz5ccRZrRKvlpwrl59L/ZwBVLYHfxfkhjae1
Oj3uY3zk2g==

che rappresenta il testo cifrato encodato in BASE64.

Come vedete il codice JScript per queste operazioni è molto semplice.

mentre la funzione di Decrypt :

Può risultare utile la funzione JScript per determinare se CAPICOM è installato in locale:

function IsCAPICOMInstalled()
{
if(typeof(oCAPICOM) == "object")
     {
         if( (oCAPICOM.object != null) )
          {
             // We found CAPICOM!
             return true;
          }
      }
}

Come diceva un mio amico : Semplice ma funzionale :-)

In un prossimo post parlerò di un problemino di compatibilità con il resto del mondo di IEncryptedData e ovviamente come risolverlo!!

IEnvelopedData

Il secondo metodo di cifratura esposto da IEnvelopedData combina la cifratura simmetrica con quella asimmetrica. Innanzitutto CAPICOM internamente genera una session key con la quale cifra il documento (1). La session key viene a sua volta cifrata con la chiave pubblica presente nel certificato di uno o più destinatari (2) ed infine il pacchetto PKCS#7 risultante contiene il documento cifrato e uno copia della chiave di sessione cifrata per ogni destinatario (3) 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 decriptare la session key con la propria chiave privata e successivamente può riottenere il documento in chiaro.

Con CAPICOM non è necessario preoccuparsi dei dettagli crittografici in quanto l’interfaccia IEnvelopedData 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 encryption. Recipients è una collection di destinatari identificati tramite il loro certificato. I metodi Encrypt e Decrypt sono autoesplicativi. Il contenuto del messaggio da inviare contiene le seguenti informazioni: le chiavi di sessione cifrate, il messaggio criptato e i certificati di tutti i destinatari.

Sebbene nella documentazione non sia espressamente dichiarato, 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 nello store MY dei certificati installati localmente sia presente un certificato contenuto nel messaggio. In questo contesto è opportuno precisare che IEnvelopedData non è il formato S/MIME e che è necessario scrivere del codice custom che estende le funzioni di CAPICOM con i requirements della specifica S/MIME.

--Mario

Certificati, Store e un po' di utilities via CryptoAPI

mfontana — Wed, 06 Feb 2008 12:38:53 GMT

Oggi ho dovuto riesumare i ricordi sulle CryptoAPI e C SDK. Ecco un po' di codice per la gestione dei certificati X509, i certificate store, i key containers e un po' di utilities che possono risultare utili :-)

Attenzione, se riutilizzate il codice verificate che si integri con il vostro sistema di Exception Management!!

Certificati

/**************************************************************************

* Function: void CSpy_DumpExtraCertInfo(PCCERT_CONTEXT pcert)

* Purpose : Print additional Certificate information

**************************************************************************/

void CSpy_DumpExtraCertInfo(PCCERT_CONTEXT pcert)

{

TCHAR szName[1000];

PCCERT_CONTEXT pCurrentCert;

PCCERT_CONTEXT pIssuerCert;

DWORD dwVerificationFlags;

LPWSTR lpszString = (LPWSTR)malloc(sizeof(TCHAR) * MAX_PATH);

SYSTEMTIME stNotBefore,stNotAfter;

DWORD dwBitLen;

DWORD dwData;

PBYTE pThumbprint;

PBYTE pData;

__try{

_tprintf(L"\n");

// display leaf name

if(!CertNameToStr(pcert->dwCertEncodingType,

&pcert->pCertInfo->Subject,

CERT_X500_NAME_STR | CERT_NAME_STR_NO_PLUS_FLAG,

szName, (DWORD)sizeof(TCHAR)*(_tcslen(szName)+1)))

{

_tprintf(L"**** Error 0x%x building subject name\n", GetLastError());

}

_tprintf(L" subject: %s\n", szName);

if(!CertNameToStr(pcert->dwCertEncodingType,

&pcert->pCertInfo->Issuer,

CERT_X500_NAME_STR | CERT_NAME_STR_NO_PLUS_FLAG,

szName, (DWORD)sizeof(TCHAR)*(_tcslen(szName)+1)))

{

_tprintf(L"**** Error 0x%x building issuer name\n", GetLastError());

}

_tprintf(L" issuer: %s\n", szName);

_tprintf(L" serial number: ");

dwData = pcert->pCertInfo->SerialNumber.cbData;

for (DWORD n = 0; n < dwData; n++)

{

_tprintf(L"%02X",pcert->pCertInfo->SerialNumber.pbData[dwData - (n + 1)]);

if( n>0&&(1== n % 2))

_tprintf(L" ");

}

_tprintf(L"\n");

FileTimeToSystemTime(&pcert->pCertInfo->NotBefore, &stNotBefore);

wsprintf(lpszString, L"%02d/%02d/%d",stNotBefore.wDay, stNotBefore.wMonth, stNotBefore.wYear);

_tprintf(L" NotBefore : %s\n",lpszString);

FileTimeToSystemTime(&pcert->pCertInfo->NotAfter, &stNotAfter);

wsprintf(lpszString, L"%02d/%02d/%d",stNotAfter.wDay, stNotAfter.wMonth, stNotAfter.wYear);

_tprintf(L" NotAfter : %s\n",lpszString);

//Thumbprint

_tprintf(L" Thumbprint : ");

if (!CertGetCertificateContextProperty(pcert,

CERT_SHA1_HASH_PROP_ID,

NULL,

&dwData))

{

_tprintf(L"Error : CertGetCertificateContextProperty() failed in retrieve memory settings.\n");

return;

}

if (NULL == (pThumbprint = (BYTE*) malloc(dwData)))

{

_tprintf(L"Error [E_OUTOFMEMORY]: malloc() failed.\n");

return;

}

if (!CertGetCertificateContextProperty(pcert,

CERT_SHA1_HASH_PROP_ID,

pThumbprint,

&dwData))

{

_tprintf(L"Error : CertGetCertificateContextProperty() failed.\n");

return;

}

for (DWORD n = 0; n < dwData; n++)

{

_tprintf(L"%02X",pThumbprint[n]);

if( n>0&&(1== n % 2))

_tprintf(L" ");

}

_tprintf(L"\n");

free(pThumbprint);

//UI description

if(CertGetCertificateContextProperty(pcert,

CERT_DESCRIPTION_PROP_ID,

NULL,

&dwData))

{

if (NULL == (pData = (BYTE*) malloc(dwData)))

{

_tprintf(L"Error [E_OUTOFMEMORY]: malloc() failed.\n");

return;

}

if(CertGetCertificateContextProperty(pcert,

CERT_DESCRIPTION_PROP_ID,

pData,

&dwData))

{

_tprintf(L" Description=%s\n",pData);

}

free(pData);

} //end od UI

CSpy_DumpCertificateExtensions(pcert);

//Public Key Infos

_tprintf(L" Public Key :\n");

if (0 != (dwBitLen = CertGetPublicKeyLength(

MY_ENCODING_TYPE,

&pcert->pCertInfo->SubjectPublicKeyInfo)))

_tprintf(L" length=%i\n", dwBitLen);

else

_tprintf(L"**** Error 0x%x in CertGetPublicKeyLength\n", GetLastError());

_tprintf(L" Algorithm ID= ");

//TODO: Add a new function to decode CRYPT_ALGORITHM_IDENTIFIER

int counter=0;

while(pcert->pCertInfo->SubjectPublicKeyInfo.Algorithm.pszObjId[counter] != '\0')

{

_tprintf(L"%c",pcert->pCertInfo->SubjectPublicKeyInfo.Algorithm.pszObjId[counter++]);

}

_tprintf(L"\n");

_tprintf(L" Key=");

dwData = pcert->pCertInfo->SubjectPublicKeyInfo.PublicKey.cbData;

for (DWORD n = 0; n < dwData; n++)

{

_tprintf(L"%02X",pcert->pCertInfo->SubjectPublicKeyInfo.PublicKey.pbData[n]);

if( n>0&&(1== n % 2))

_tprintf(L" ");

}

_tprintf(L"\n");

//_tprintf(L" Private Key : %s",(CSpy_CertificateHasPrivateKey(pcert))?L"Present":L"Not present");

_tprintf(L" Private Key : ");

if(CSpy_CertificateHasPrivateKey(pcert))

{

_tprintf(L"YES\n");

CSpy_DumpCSPInfos(pcert);

}else

{

_tprintf(L"NO\n");

}

// display certificate chain

pCurrentCert = pcert;

while(pCurrentCert != NULL)

{

dwVerificationFlags = 0;

pIssuerCert = CertGetIssuerCertificateFromStore(pcert->hCertStore,

pCurrentCert,

NULL,

&dwVerificationFlags);

if(pIssuerCert == NULL)

{

if(pCurrentCert != pcert)

{

CertFreeCertificateContext(pCurrentCert);

}

break;

}

if(!CertNameToStr(pIssuerCert->dwCertEncodingType,

&pIssuerCert->pCertInfo->Subject,

CERT_X500_NAME_STR | CERT_NAME_STR_NO_PLUS_FLAG,

szName, (DWORD)sizeof(TCHAR)*(_tcslen(szName)+1)))

{

_tprintf(L"**** Error 0x%x building subject name\n", GetLastError());

}

_tprintf(L" CA subject: %s\n", szName);

if(!CertNameToStr(pIssuerCert->dwCertEncodingType,

&pIssuerCert->pCertInfo->Issuer,

CERT_X500_NAME_STR | CERT_NAME_STR_NO_PLUS_FLAG,

szName, (DWORD)sizeof(TCHAR)*(_tcslen(szName)+1)))

{

_tprintf(L"**** Error 0x%x building issuer name\n", GetLastError());

}

_tprintf(L" CA issuer: %s\n\n", szName);

if(pCurrentCert != pcert)

{

CertFreeCertificateContext(pCurrentCert);

}

pCurrentCert = pIssuerCert;

pIssuerCert = NULL;

}

} //end__try

__finally

{

}

/**************************************************************************
* Function: bool CSpy_CertificateHasPrivateKey(PCCERT_CONTEXT pcert)
*
* Purpose : Test if a certificate has the private key
**************************************************************************/

bool CSpy_CertificateHasPrivateKey(PCCERT_CONTEXT pcert)
{
    DWORD cb = 0;

    return CertGetCertificateContextProperty(pcert,
                                             CERT_KEY_PROV_INFO_PROP_ID,
                                             NULL,
                                             &cb)
                                             !=0; //to avoid Compiler warning (level 3) C4800
}

/**************************************************************************
* Function: UINT CSpy_DumpCertificateExtensions(PCCERT_CONTEXT pCertContext)
*
* Purpose : Display cert extensions. Return number of extensions
**************************************************************************/

UINT CSpy_DumpCertificateExtensions(PCCERT_CONTEXT pCertContext)
{

    _tprintf(L" N. Ext. : %d\n",pCertContext->pCertInfo->cExtension);

    if (pCertContext->pCertInfo->cExtension>0)
    {
        for(int x =0; x <(int)pCertContext->pCertInfo->cExtension;x++)
        {
            _tprintf(L"    Critical=%s ",(pCertContext->pCertInfo->rgExtension->fCritical)? L"Yes":L"NO");
            _tprintf(L" OID=");
            int n=0;
            while(pCertContext->pCertInfo->rgExtension->pszObjId[n]!='\0')
                _tprintf(L"%c",(TCHAR)pCertContext->pCertInfo->rgExtension->pszObjId[n++]);
            _tprintf(L"\n");

            pCertContext->pCertInfo->rgExtension++;

        }//endfor(int x =0; x <pCertContext->pCertInfo->cExtension;x++)
    } //endif (pCertContext->pCertInfo->cExtension>0)

    return pCertContext->pCertInfo->cExtension;
}

Certificate Store

/**************************************************************************

* Function: void CSpy_DumpStore(TCHAR *storeName)

* Purpose : Open a list all certificate in a store

**************************************************************************/

void CSpy_DumpStore(TCHAR *storeName)

{

HCERTSTORE hCertStore;

PCCERT_CONTEXT pCertContext = NULL;

DWORD dwFlags=0;

DWORD dwStrType = CERT_OID_NAME_STR;

DWORD cbNameLen;

TCHAR *sz;

long nCerts=0;

if (_tcsclen(storeName) > MAX_PATH )

storeName[MAX_PATH] = '\0';

_tprintf(L"\nDumping '%s' Store.....\n",storeName);

//--------------------------------------------------------------------

// Begin Processing by opening a certificate store.

if(!(hCertStore=CertOpenStore(

CERT_STORE_PROV_SYSTEM,

MY_ENCODING_TYPE,

NULL,

CERT_SYSTEM_STORE_CURRENT_USER|CERT_STORE_OPEN_EXISTING_FLAG ,

storeName)))

{

CSpy_DisplayError(L"The store did not open.");

}

while(pCertContext = CertEnumCertificatesInStore(

hCertStore,

pCertContext))

{

//--------------------------------------------------------------------

// Get and display

// the name of subject of the certificate.

if(!(cbNameLen = CertGetNameString(pCertContext,CERT_NAME_SIMPLE_DISPLAY_TYPE,0,NULL,NULL,0)))

{

CSpy_DisplayError(L"CertGetName 1 failed.");

}

if(!(sz = (TCHAR*) malloc(sizeof(TCHAR) *cbNameLen+1)))

CSpy_DisplayError(L"Memory allocation failed.");

if(CertGetNameString(pCertContext,CERT_NAME_SIMPLE_DISPLAY_TYPE,0,NULL,(LPWSTR)sz,cbNameLen+1))

{

_tprintf(L"\nCertificate n. %d Version=V%d :(%s).",nCerts+1,pCertContext->pCertInfo->dwVersion+1,sz);

}

else

{

CSpy_DisplayError(L"CertGetName failed.");

}

free(sz);

CSpy_DumpExtraCertInfo(pCertContext);

nCerts++;

} // End of while loop

_tprintf(L"\n=>Total : %s store contains %d certificates",storeName,nCerts);

//--------------------------------------------------------------------

// Close the store.

if(CertCloseStore(hCertStore,CERT_CLOSE_STORE_CHECK_FLAG))

{

if(true == g_bverbose)

_tprintf(L"The store is closed. All certificates are released.\n");

}

else

{

if(true == g_bverbose)

_tprintf(L"The store was closed, but certificates still in use.\n");

}

Key Containers

/**************************************************************************
* Function: DWORD CSpy_DeleteKeyContainer(PCCERT_CONTEXT pCertContext)
*
* Purpose :
**************************************************************************/

DWORD CSpy_DeleteKeyContainer(PCCERT_CONTEXT pCertContext)
{
    DWORD nRetCode = 0;
    DWORD cb = 0;
    CRYPT_KEY_PROV_INFO * pKeyProvInfo = NULL;

    __try
    {
        HCRYPTPROV hCryptProv;

        if (!CryptAcquireContext(&hCryptProv,
                                  pKeyProvInfo->pwszContainerName,
                                  pKeyProvInfo->pwszProvName,
                                  pKeyProvInfo->dwProvType,
                                  CRYPT_DELETEKEYSET))
        {
            CSpy_DisplayError (L"Unable to Delete the context.");
            _tprintf(L" %s ",pKeyProvInfo->pwszContainerName);
            __leave;
        }
    }

    __finally
    {
        if (pKeyProvInfo)
        {
            free(pKeyProvInfo);
        }
    }

    return nRetCode;

}

Utilities

/**************************************************************************
* Function: VOID DumpBinaryData( PBYTE pBuffer, ULONG uLen )
*
* Purpose : DumpBinaryData()
**************************************************************************/
VOID CSpy_DumpBinaryData( PBYTE pBuffer, ULONG uLen )
{
    TCHAR *p = (TCHAR *)pBuffer;
    TCHAR     c;
    DWORD    dw;
    UINT     i = 0;

    _tprintf(L"{\n ");
    while( i < uLen ) {
        c = *p;
        dw = (DWORD)(c);
        _tprintf(L"0x%02X, ", dw & 0xFF );
        i++;
        p++;
        if ((i % 8) == 0)
            _tprintf(L"\n " );
    }
    _tprintf(L"\n}\n" );
}

--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

Due parole sulla sicurezza degli algoritmi crittografici.

mfontana — Mon, 04 Feb 2008 03:19:00 GMT

Questo è un micro sunto da ricordare quando si progetta un nuovo software oppure quando si valutano degli applicativi sviluppati da terzi.

La robustezza di un sistema di cifratura a chiave simmetrica è dovuto a due fattori : la robustezza dell'algoritmo e la lunghezza delle chiavi. La robustezza di un algoritmo non è provato in modo analitico ma, al contrario, è dato dalla non violabilità dell'algoritmo stesso per molti anni da parte della comunità di cryptoanalisti.A questa regola esiste però una sola eccezione : One-time pad. Questa tecnica prevede che la chiave utilizzata sia lunga quanto il plain text, che sia un numero random e infine tale chiave deve essere utilizzata solo una volta. Se la chiave generata non è veramente random anche questa tecnica può essere violata come avvenne per il progetto VENONA dove gli Stati Uniti furono in grado, per decenni, di decifrare vari messaggi spia sovietici perchè durante la seconda guerra mondiale i Sovietici inziarono ad riutilizzare le stesse chiavi.

Gli algoritmi a chiave simmetrica si dividono in 2 grandi famigli : Stream Cipher e Block Cipher. Gli algoritmi Stream Chiper, usati principalmente nelle telecomunicazioni., cifrano carattere per carattere di un plain text rendendo più veloci e meno complessi da realizzare con hardware. I Block cipher invece cifrano a blocchi il plain text. La lunghezza delle chiavi è importante perchè se l’algoritmo di cifratura è "sicuro" un attacker generalmente deve utilizzare il brute force attack per risalire al plain text.Al contrario se l'algoritmo non è sicuro è possibile che alcune proprietà matematiche possano essere esposte e quindi utilizzate per violare il codice nonostante la chiave simmetrica sia molto grande. Questa infelice situazione capita spesso quando si cerca di modificare un algoritmo standard “per renderlo più sicuro”.

Se una chiave simmetrica è lunga k bits allora il numero totale di combinazioni è dato da 2^k. Quindi maggiore è la chiave maggiore è il numero di combinazioni. Per k = 40 il numero di chiavi è pari a 2^40. Il tempo di break per un codice codificato con una chiave di queste dimensioni è di poche ore per un centinaio di computer in rete. Per k = 56, utilizzato dall’algoritmo DES, il tempo di break era di qualche mese. Già da qualche anno è stato reso noto che la Electronic Frontier Foundation ha realizzato una macchina specializzata nella ricerca di chiavi crittografiche DES riuscendo a violare la cifratura in soli 3 giorni. Infine per k = 128 il tempo di break per un codice codificato con una chiava di queste dimensioni è di 2^128 = Circa 10^25 anni (l'universo ha 10^10 anni).

Anche la natura dei dati potrebbe rappresentare un punto di vulnerabilità nel nostro sistema di crittografia. Molti plaintext, ad esempio, iniziano con gli stessi dati: le lettere commerciali, gli header dei files di word o di un eseguibile. Un caso a parte, invece, lo occupano i numeri di carta di credito che introducono due punti deboli. Il primo causato dalla conoscenza delle iniziali di questi numeri : tutte le carte VISA iniziano con 4, Mastercard con numeri da 51 a 55 e Amex da 34 a 37. Il secondo punto debole, invece, è dovuto alla lunghezza fissa e alla relazione matematica che lega tali numeri (modulo10)

Per risolvere questa serie di problemi sono stati introdotti gli "Initialization Vectors". Gli IV (generalmente utilizzati in concomitanza con i block cipher in CBC mode) sono un blocco di bits random che viene aggiunto all'inizio del plaintext prima dell'encryption. Questo permette di propagare e di mascherare tutte le regolarità del ciphertext. Le CryptoAPI, le classi del framework .NET e CAPICOM, si occupano di gestire internamente gli IV.

Specificando “high encryption” si indica la dimensione delle chiavi simmetriche a 128 bits. Viceversa, quando si indicano le chiavi asimmetriche per encryption o firma digitale la lunghezza delle chiavi è maggiore (512-1024-2048 bits o supp). Generalmente algoritmi a chiave pubblica/privata devono utilizzare chiavi a lunghezza superiore rispetto a quelle usate negli algoritmi a chiave simmetrica per ottenere lo stesso grado di sicurezza.

BASTA CON QUESTO DES!!!!

DES è un algoritmo di tipo "block cipher" e cifra a blocchi di 64bits. La chiave è di 56 bits ma viene espressa a 64bits utilizzando ogni ottavo bit come parity checking.

Semplificando, l'algoritmo utilizza due tecniche base per l'encryption chiamati : confusion e diffusion;ovvero una sostituzione seguita da una permutazione (chiamato round). DES ha 16 rounds ovvero applica la stessa combinazione di tecniche sul plaintext 16 volte. Dopo la prima permutazione il blocco è diviso in due parti da 32bits (parte destra e sinistra). In seguito avvengono 16 rounds in cui i dati vengono combinati con la chiave. Dopo il 16 round la parte destra e la parte sinistra vengono riunite e dopo l'ultima permutazione (che è l'inverso di quella iniziale) si ha il risulatato dell'algoritmo.

DES è stato "matematicamente" ideato dalla NSA e successivamente implementato da IBM nel 1976. Da 20 anni a questa parte è stato ipotizzato che l'algoritmo contenesse delle "back doors" che permettessero a NSA di decifrare facilmente i dati cifrati con DES. Pur non avendo mai dimostrato la presenza di tali back- door nell’ algoritmo fu ideato TRIPLE-DES che matematicamente non offre alcuna sicurezza aggiuntiva rispetto a DES, ma quantomeno dovrebbe eliminare eventuali back-doors.

Quando usare DES? Solo quando c'è necessità di garantire la compatibilità con vecchi sistemi. In tutti gli altri casi... BASTA DES !!! Al contrario il successore di DES è il nuovo algoritmo Rijndael (ideato da Joan Deamen e Vincent Rijmen) chiamato anche AES (Advanced Encryption Standard) algoritmo a chiave variabile di 128,192 o 256 bits.

Raccomandazioni se non si può progettare per WIndows Server 2008 e Windows Vista come baseline:

Encryption : Uso di AES-128 o superiore.

Firma Digitale : RSA con chiavi a 2048 o superiori.

Hashing : SHA-256 o SHA-512. Se poi avete solo 160 bit a disposizione è preferibile utilizzare SHA-256 e prelevare i primi 160 bits rispetto all'uso di SHA1.

--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