Firma elettronica e certificati digitali per le operazioni ... · corso multimediale completo su CD...

ITAdministrator - Sicurezza informatica Lezione 3

www.pcopen.it30

Riassumiamo i principali caratteri distintivi dei due mo-delli di crittografia. Nella prima parte della lezione 2abbiamo visto in dettaglio le differenze tra crittogra-

fia simmetrica (a chiave segreta) e crittografia asimmetri-ca (a chiave pubblica e privata). Rivediamoli brevemente.

Simmetrica: 1) migliori prestazioni, 2) adatta per cifraremessaggi lunghi, 3) chiavi brevi, 4) pone il problema delladistribuzione delle chiavi, 5) facile uso con PRGN (Pseudo-Random Number Generator) e funzioni di hash, 6) utilizza-bili come componenti di uno schema ad alta sicurezza, 7)lunga storia, 8) tecnologia collaudata

Asimmetrica: 1) chiavi molto lunghe, 2) cattive presta-zioni, 3) adatta per cifrare dati brevi, 4) risolve il problemadella distribuzione delle chiavi, 5) la chiave può essere au-tenticata; 6) le chiavi pubbliche possono essere accessibi-li pubblicamente, presso terze parti fidate, 7) vita più lun-ga delle chiavi, 8) utilizzabile per la firma digitale, 9) storiabreve (anni ’70)

PRNG significa Pseudo-Random Number Generator (ge-neratore di numeri pseudo-casuali), una funzione che tra ivari impieghi include la generazione di chiavi simmetrichedi sessione.

Per la lunghezza delle chiavi, Schneier, in Applied Cryp-tography (scritto nel 1995), raccomandava almeno 112 bitper le chiavi simmetriche (come nel 3DES a due chiavi) eprevedeva, per il periodo 2005-2010, la necessità di usarechiavi asimmetriche lunghe 1.280, 1.536 o 2.048 bit rispet-

tivamente per utilizzo personale, aziendale o governativo.Secondo le linee guida del NIST (Key Management Guideli-ne, novembre 2001), una chiave 3DES di 112 bit ha la robu-stezza di una chiave RSA di 2.048 bit, mentre una chiaveAES di 256 bit equivale a una chiave RSA di 15.360 bit.

Vantaggi della crittografia simmetrica- utilizza algoritmi molto veloci, che possono cifrare/deci-frare grandi quantità di dati per secondo, dell’ordine del-le centinaia di MByte al secondo.

Applicazioni pratiche delle più moderne tecniche di crittografia edei protocolli che regolano le transazioni on-line. La lezione, oltrea essere un requisito per il conseguimento della certificazioneufficiale EUCIP IT Administrator – Sicurezza Informatica, validain tutta Europa, spiega come condurre operazioni sicuremediante il PC garantendo riservatezza, integrità e autenticitàdei documenti e delle persone in gioco, oltre che il non ripudiodelle decisioni concordate. I contenuti si articolano in quattroelementi: un articolo sinteticosulla rivista che riepiloga soloi concetti essenziali, l’articolocompleto in formato PDF e uncorso multimediale completo su CD e DVD di Giorgio Gobbi

Materiale didatticovalidato da AICACertificazione EUCIPIT AdministratorModulo 5 - IT SecuritySicurezza informatica

"AICA Licenziatariaesclusiva in Italia delprogramma EUCIP(European Certificationof InformaticProfessionals), attestache il materiale didatticovalidato coprepuntualmente eintegralmente gliargomenti previsti nelSyllabus IT Administratore necessari per ilconseguimento dellacertificazione ITAdministrator ITSecurity. Diconseguenza AICAautorizza sul presentemateriale didattico l'usodel marchio EUCIP,registrato da EUCIP Ltde protetto dalle leggivigenti"

Obiettivo del corso IT AdministratorSicurezza InformaticaFornire al lettore familiarità con i vari modi diproteggere i dati sia su un singolo PC sia in una LANconnessa a Internet. In particolare, metterlo nellecondizioni di proteggere i dati aziendali controperdite, attacchi virali e intrusioni. Inoltre, metterlonelle condizioni di conoscere e utilizzare le utility e iprogrammi più comuni destinati a tali scopi.Riferimento Syllabus

2.0 (curriculumufficiale AICA)

5.2.5. Confronto trai metodi di cifratura

5.2.5.1 Vantaggi esvantaggi dellacrittografiasimmetrica easimmetrica

I contenuti delle 8 lezioni Lezione 1: Informazioni generaliLezione 2: parte 1Crittografia -

fondamenti e algoritmiLezione 2: parte 2Crittografia -

applicazioniLezione 3: Autenticazione

e controllo degli accessiLezione 4: DisponibilitàLezione 5: Codice malignoLezione 6: Infrastruttura a chiave pubblicaLezione 7: Sicurezza della reteLezione 8: Aspetti sociali, etici e legali della

sicurezza informatica

In collaborazionecon:

� Applicazioni della crittografia

Firma elettronica ecertificati digitali per le operazioni elettroniche

www.pcopen.it31

Lezione 3 IT Administrator - Sicurezza informatica

5.2.5.2 Saperdistinguere tra idiversi livelli disicurezza e il relativopeso

- può cifrare e decifrare messaggi e documenti di lunghez-za illimitata

- le chiavi utilizzate sono relativamente brevi; AES, peresempio, utilizza chiavi di 128, 192 o 256 bit (la scelta del-la lunghezza della chiave dipende dai requisiti di sicurez-za presente e futura)

- gli algoritmi a chiave simmetrica possono essere integra-ti nella realizzazione di schemi di cifratura più complessi,insieme a funzioni hash e a generatori PRNG

- più algoritmi simmetrici, non abbastanza robusti se uti-lizzati singolarmente, possono essere combinati per otte-nere schemi di cifratura di notevole robustezza (come nelcaso di 3DES costruito utilizzando l’ormai superato DES)

- la crittografia simmetrica si è sviluppata in un lungo arcodi tempo e utilizza meccanismi ben studiati e collaudati.

Vantaggi della crittografia asimmetrica - un utente deve conservare solo una chiave privata, men-tre la chiave pubblica è resa disponibile a tutti (anche serichiede l’onere della certificazione per essere ritenuta au-tentica)

- per la gestione delle chiavi sulla rete è sufficiente la pre-senza di una CA (Autorità di certificazione) affidabile, manon necessariamente sempre online

- la coppia chiave privata/chiave pubblica può restare in-variata per lunghi periodi di tempo (anche anni, se il tipod’impiego non è critico)

- in una rete di grandi dimensioni, è necessario un numerodi chiavi limitato (proporzionale al numero di utenti, an-ziché in relazione quadratica come nel caso di chiavi sim-metriche)

Problemi della crittografia simmetrica- la chiave usata per la cifratura e decifratura da una coppiadi interlocutori deve restare segreta ed essere cambiata difrequente; la soluzione migliore è la generazione di unachiave casuale per ogni sessione di comunicazione abbi-nata a uno dei meccanismi di scambio sicuro delle chiavi

- in una rete con N utenti, a meno che si usino chiavi di ses-sione, il numero di chiavi simmetriche è pari a N(N-1)/2; segestite da una terza parte fidata, ne farebbero il punto de-bole del sistema

I due interlocutori devono avere un canale sicuro perscambiarsi la chiave segreta; una soluzione efficace utiliz-za i meccanismi di scambio delle chiavi che hanno dato vi-ta alla crittografia asimmetrica (vedi l’esempio alla sezione5.2.3.1 - Principi di crittografia asimmetrica).

Problemi della crittografia asimmetrica - richiede una modalità di autenticazione delle chiavi pub-bliche

- gli algoritmi di cifratura sono lenti (tipicamente mille vol-te più lenti rispetto ai simmetrici)

- è applicabile a dati di breve lunghezza (inferiore alla lun-ghezza della chiave)

- le chiavi asimmetriche sono di lunghezza decisamentemaggiore rispetto alle chiavi simmetriche (non meno di1.024 bit)

- nessun metodo utilizzato dagli algoritmi asimmetrici (co-me la fattorizzazione del prodotto di numeri primi o il cal-colo del logaritmo discreto) è stato matematicamente di-mostrato essere sicuro; la loro sicurezza si basa sull’e-strema difficoltà, con i mezzi correnti, di risolvere deter-minati problemi della teoria dei numeri

- nel 2003 l’ufficio federale tedesco per la sicurezza infor-matica ha violato il metodo di fattorizzazione alla base diRSA per numeri di 174 cifre decimali, corrispondenti aRSA-576; la crescita della lunghezza delle chiavi potrebbedover essere più rapida del previsto, dopo che il mate-matico Bernstein, con il suo articolo “Circuits for IntegerFactorization” del 2001, ha scosso la fiducia nel sistema dicifratura/decifratuira di RSA e ha teorizzato la vulnerabi-

lità delle chiavi di 1.536 bit (mentre la maggior parte dei si-stemi, come HTTPS, SSH, IPSec, S/MIME e PGP utilizzanoRSA con chiavi di lunghezza limitata)

Livelli di sicurezza Dato che non esiste un singolo algoritmo di crittografia

ideale per tutte le occasioni, si dovranno considerare di-versi fattori nell’operare la scelta dell’algoritmo, o più spes-so della combinazione di algoritmi, da utilizzare per unacerta applicazione. Alcuni criteri di base sono i seguenti:- stima del livello di affidabilità sulla base degli anni di uti-lizzo, dell’analisi di robustezza, degli attacchi subiti, valu-tando anche la presumibile durata futura

- dimensione della chiave in base alle esigenze di sicurezzae alla progressiva estensione della chiave, negli anni, perpreservare la robustezza di un algoritmo

- efficienza di calcolo e consumo di risorse in relazione al-le piattaforme hardware/software da utilizzare.

Come anche citato in precedenza, la dimensione dellachiave gioca un ruolo fondamentale, riassumibile in dueaspetti:- nella crittografia simmetrica, DES (con chiave di 56 bit) ea maggior ragione gli algoritmi a 40 bit sono da conside-rare obsoleti perché non sicuri e violabili con comunicomputer; è necessario utilizzare 3DES o algoritmi conchiave di almeno 128 bit, come AES

- nella crittografia asimmetrica, chiavi inferiori a 1.024 bitnon offrono più garanzie sufficienti; sono adeguate le chia-vi di 1.024 bit per uso personale e durata annuale (comu-ni nei certificati digitali usati per la posta elettronica) e lechiavi di 2.048 bit per uso più generale e durata plurien-nale.

Sulle categorie di attacco, sui livelli di sicurezza neces-sari per le categorie di utenza (privata, business, governa-tiva, eccetera), sulla longevità e robustezza degli algoritmie sulla crescita delle chiavi col passare degli anni, si trovaabbondante documentazione, per esempio presso i siti diNIST e di SANS Institute. Mostriamo due tabelle, una sullarobustezza equivalente delle chiavi tra diversi algoritmi el’altra su algoritmi raccomandati e lunghezza minima dellechiavi, tratte dalla versione 2003 del citato Key Manage-ment Guideline di NIST, Parte 1 (http://csrc.nist.gov/Cryp-toToolkit/KeyMgmt.html)

L’articolo “A Discussion of the Importance of Key Lengthin Symmetric and Asymmetric Cryptography” di SANS(http://www.giac.org/practical/gsec/Lorraine_Williams_GSEC.pdf) passa in rassegna diverse fonti d’informazione sul-la lunghezza delle chiavi e include tra l’altro due tabelle:una stima del 1997 sulla lunghezza delle chiavi in funzionedei tipi di attacco e una stima sulla lunghezza minima del-le chiavi pubblicata da Schneier nel suo classico “Applied

Una mappa dellarobustezza delle chiavisecondo i valori diequivalenza calcolati dal NIST

www.pcopen.it32


Cryptography” del 1996. Un decennio di sviluppi hardwaree software, di evoluzioni concettuali e di attacchi andati abuon fine oltre le previsioni, suggeriscono stime legger-mente meno ottimistiche e il frequente aggiornamento delrapporto tra livelli di sicurezza e algoritmi e lunghezza del-le chiavi. La prima tabella si riferisce a chiavi asimmetriche,la seconda a chiavi simmetriche; entrambe sono ottimisti-che sulla distanza.

Distribuzione delle chiavi Nei capitoli precedenti abbiamo citato i problemi con-

nessi con la trasmissione e lo scambio di chiavi, derivantidalla necessità di mantenere segrete le chiavi simmetrichee di assicurare l’integrità e l’autenticità dei dati trasmessi.Vediamo in sintesi gli argomenti principali.

Distribuzione delle chiavi simmetrichePer utilizzare la crittografia simmetrica, i due interlocu-

tori devono disporre della stessa chiave, che deve restaresegreta per chiunque altro. Inoltre, per limitare i danni po-tenziali di una chiave compromessa, la chiave segreta do-vrebbe essere sostituita di frequente. Ne consegue che, perquanto sia robusto il cifrario utilizzato, la sicurezza di un si-stema crittografico simmetrico dipende dalla tecnica di di-stribuzione delle chiavi, ossia dai modi di consegnare unachiave a due interlocutori A e B senza che altri la possanovedere.

Vediamo alcuni approcci:1) A sceglie una chiave e la consegna fisicamente a B2) Una terza parte fidata sceglie una chiave e la consegna

fisicamente ad A e B3) Se A e B hanno già usato una chiave di recente, uno di lo-

ro trasmette all’altro la nuova chiave cifrata con quellavecchia

4) Se A e B hanno una connessione cifrata con una terzaparte C, questa può consegnare una chiave ad A e B at-

traverso i collegamenti cifratiLe soluzioni 1 e 2 sono praticabili solo nel caso di due in-

terlocutori che utilizzano un dispositivo di cifratura per ci-frare il collegamento (tutto ciò che passa sulla linea), manon sono applicabili a trasmissioni da un punto all’altro diun sistema distribuito. In una rete, la scala del problema di-pende dal numero di punti terminali in comunicazione. Sela cifratura è applicata allo strato 3 di rete, vale a dire al pro-tocollo IP (considerando il modello OSI oppure il modelloTCP/IP) e ci sono N host (computer collegati alla rete), ilnumero di chiavi necessarie è N(N-1)/2. Se la cifratura vie-ne eseguita a livello applicativo, serve una chiave per ognicoppia di utenti o processi in comunicazione, il che ci por-ta a un ordine di grandezza superiore al numero di host.Una rete con 1.000 nodi e cifratura a livello di nodo avreb-be bisogno di distribuire mezzo milioni di chiavi, ma se lastessa rete avesse 10.000 applicazioni in funzione, ciascu-na con la propria cifratura delle comunicazioni, le chiavi dadistribuire sarebbero dell’ordine dei 50 milioni.

La soluzione 3 è praticabile sia a livello di collegamento(link) sia tra i punti di una rete, ma se un nemico si procu-ra una chiave, avrà scoperto tutte le chiavi successive. Perla cifratura tra punti di una rete, la soluzione 4 è la più uti-lizzata. Si basa su un Key Distribution Center (KDC, centrodi distribuzione delle chiavi) che, quando necessario, di-stribuisce una chiave a una coppia di utenti (host, proces-si o applicazioni). Ogni utente condivide con il KDC unachiave segreta usata per la distribuzione delle chiavi.

Quando A vuole stabilire una connessione logica con B,invia al KDC la richiesta di una chiave simmetrica tempo-ranea (chiave di sessione) da usare nella comunicazionecon B e, per identificare la richiesta in modo univoco (ascopo di sicurezza), include nonce, ovvero un numero ca-suale, progressivo o segnatempo, sempre diverso per ognirichiesta. Il KDC risponde inviando ad A un messaggio ci-frato con la chiave condivisa tra A e il KDC. Questo mes-saggio contiene: 1) la chiave di sessione da usare tra A e B2) il messaggio originale con il nonce per abbinare la ri-

sposta alla richiesta 3) una parte destinata a B e cifrata con la chiave che B con-

divide col KDC, contenente la chiave di sessione e unidentificatore di A (per esempio il suo indirizzo di rete).Tali contenuti proteggono la riservatezza, l’integrità el’autenticazione dei dati. A memorizza la chiave di ses-sione e inoltra a B la chiave di sessione e il proprio iden-tificatore cifrati con la chiave di B, che solo il KDC po-trebbe aver confezionato. B usa la chiave di sessione perinviare ad A un nonce di propria scelta. A, sempre usan-do la chiave di sessione, risponde a B con qualche tipodi trasformazione concordata del nonce, che mostra a Bche il messaggio è autentico e non una ripetizione usataper trarlo in inganno.Questa è la traccia di base, soggetta a varianti ed evolu-zioni (per esempio la gerarchia di KDC e la distribuzionedecentralizzata delle chiavi) per adattarsi alle diverse ap-plicazioni.

Distribuzione delle chiavi asimmetricheConsideriamo, per prima cosa, la distribuzione delle

chiavi pubbliche, visto che la chiave privata deve esserecustodita al sicuro sul computer della persona a cui ap-partiene. La maggior parte delle tecniche di distribuzionerientra in questi quattro schemi:

1) Annuncio pubblico2) Directory di pubblico accesso3) Autorità per le chiavi pubbliche4) Certificati di chiave pubblica.Nel caso 1, i partecipanti possono inviare ad altri la chia-

ve, farne il broadcast (totale diffusione) in una comunità,pubblicare la chiave su una mailing list, su un newsgroupo su un sito. Il punto debole fondamentale di tale approc-

5.2.5.3 Conoscere iproblemi didistribuzione dellechiavi nellacrittografiasimmetrica easimmetrica

Algoritmi raccomandatiin funzione dellalunghezza minima dellechiavi.

Una stima, ottimistica,della robustezza dei varitipi di chiave in funzione

dell’attacco subitopubblicata da SANS

(SysAdmin, Audit,Network, Security

Institute ) nel 1997

Una stima sullalunghezza minima delle

chiavi pubblicata daSchneier nel 1996


cio è che chiunque può fingere di essere l’utente A e invia-re o pubblicare una chiave pubblica. Prima che A se ne ac-corga e avvisi gli interessati, l’impostore avrà letto i mes-saggi cifrati destinati ad A e avrà usato le chiavi fasulle perl’autenticazione.

Il caso 2 consiste nell’affidare la manutenzione e distri-buzione delle chiavi pubbliche a una terza parte fidata.Questa entità mantiene una directory con una voce (nomee chiave pubblica) per ogni partecipante. Ogni parteci-pante registra la sua chiave pubblica di persona o attra-verso una comunicazione autenticata; quando lo desidera,può sostituire la chiave (per esempio dopo un certo perio-do d’uso o perché la chiave privata è stata compromessa).La directory può essere aggiornata e pubblicata periodi-camente anche su media off-line. I partecipanti possono ac-cedere alla directory solo attraverso comunicazioni au-tenticate dal gestore. Lo schema 2 è più sicuro del caso 1,ma se un nemico riesce a procurarsi la chiave privata delgestore della directory, può iniziare a far circolare falsechiavi pubbliche, a impersonare qualunque partecipante(impostura) e a intercettare i messaggi diretti ai parteci-panti. Lo stesso scopo può essere raggiunto attraversoun’intrusione che riesca ad accedere alle registrazioni te-nute dal gestore.

Il caso 3 è realizzato partendo dal caso 2 ed esercitandoun controllo più stretto sulla distribuzione delle chiavi pub-bliche. Ora ogni partecipante conosce la chiave pubblicadell’autorità, la quale è l’unica a conoscere la propria chia-ve privata. Vediamo i passi da eseguire quando A vuole co-municare con B. A invia all’autorità la richiesta della chia-ve pubblica di B e un timestamp con la registrazione tem-porale (data, ore, minuti, eccetera). L’autorità risponde conun messaggio cifrato mediante la propria chiave privata,che contiene la chiave pubblica di B e una copia della ri-chiesta e del timestamp (A ora dispone della certezza cheil messaggio viene dall’autorità, che non è stato alterato eche risponde alla richiesta corrente). A memorizza la chia-ve pubblica di B e la usa per cifrare un messaggio indiriz-zato a B contenente un identificatore di A e un nonce N1usato per identificare la transazione in modo univoco. Bcontatta l’autorità per ricevere la chiave di A (invia la ri-chiesta e il timestamp). L’autorità risponde a B inviando, ci-frati con la propria chiave privata, la chiave di A, la richie-sta e il timestamp. Ora B risponde ad A cifrando, con lachiave pubblica di A, il nonce N1 ricevuto da A e un nuovononce N2 generato da B. Per finire, A invia a B un messag-gio di conferma, cifrato con la chiave di B, contenete il non-ce N2. I quattro messaggi con cui A e B si procurano le chia-vi pubbliche del loro interlocutore avvengono raramente,mentre la comunicazione tra A e B avviene per un certo pe-riodo di tempo utilizzando le chiavi ricevute, in base allestime e ai requisiti di sicurezza.

Un punto debole di questo schema è la centralizzazionedell’autorità, a cui gli utenti devono rivolgersi ogni voltache vogliono usare la chiave pubblica di un altro utente,creando un conseguente collo di bottiglia. Inoltre, come nelcaso 2, la directory dei nomi e delle chiavi pubbliche è sog-getta a intrusioni e manomissioni.

Il caso 4 prevede l’uso dei public-key certificate, ossiacertificati di chiave pubblica (chiamati anche certificati achiave pubblica). I certificati servono agli utenti per scam-biare le chiavi pubbliche senza dover contattare un’auto-rità, ma con lo stesso grado di sicurezza che si avrebbe sele chiavi fossero fornite direttamente dall’autorità che am-ministra la directory. Ogni certificato contiene la chiavepubblica e varie informazioni; è creato da una CertificationAuthority ed è consegnato all’utente. Un utente A trasmet-te la propria chiave pubblica a un utente B inviandogli ilcertificato; B verifica che il certificato sia stato creato dal-l’autorità dei certificati.

Lo schema 4 funziona in questo modo: un utente A ri-chiede alla CA (di persona o via comunicazione autentica-

ta) un certificato, fornendo la propria chiave pubblica; laCA risponde ad A con un messaggio cifrato con la propriachiave privata e contenente il tempo, l’identificatore di A ela sua chiave pubblica; A trasmette il certificato (cifrato) aB; B decifra il certificato ricevuto usando la chiave pubbli-ca della CA, accertando così che il certificato di A provie-ne dalla CA e verificando l’integrità e la validità dei conte-nuti (tempo, identità di A e chiave di A). B può ripetere lestesse operazioni e inviare ad A il proprio certificato, ci-frato dalla CA in modo da garantirne la sicurezza. In questoschema, il tempo contenuto nel certificato determina il li-mite di validità; se la chiave privata di un utente viene com-promessa e il titolare, dopo la notifica alla CA, non riesce adavvisare tutti gli interessati, il certificato cessa di valere tra-scorso un certo tempo dal timestamp.

In questo schema, descritto da Stallings in Crypto-graphy and Network Security, vediamo un antesignano deimoderni certificati digitali, che hanno struttura e utilizzo di-versi rispetto al modello riportato sopra. Oggi il tipo più co-mune di certificato digitale è conforme allo standard ITUX.509, versione 3, del 1997, che comprende una serie diinformazioni, la chiave pubblica e una firma digitale appli-cata dalla CA, con la propria chiave privata, a un hash (o di-gest) calcolato sui campi precedenti (le informazioni e lachiave pubblica). In questo modo la CA certifica tutte leinformazioni del certificato e la loro associazione alla chia-ve pubblica. La gestione delle chiavi e dei certificati X.509fa parte della PKI (Public Key Infrastructure - infrastruttu-ra a chiave pubblica, basata su una gerarchia di Certifica-tion Authority). Uno standard per i certificati, più semplicedell’X.509, è quello dei certificati PGP (Pretty Good Privacy)citati in precedenza, che non sono firmati da una CA, mapossono essere firmati da parecchi individui quale atte-stazione di fiducia.

Distribuzione di chiavi simmetriche tramite chiaviasimmetriche

Nella sezione 5.2.3.1 (Principi di crittografia asimmetri-ca) abbiamo mostrato un esempio di distribuzione di unachiave segreta (simmetrica) tramite crittografia asimme-trica RSA. L’esempio ci ricorda che la crittografia asimme-trica è lenta e si applica a dati di piccole dimensioni, men-tre quella simmetrica è anche mille volte più veloce e ac-cetta dati di qualsiasi lunghezza. La distribuzione dellechiavi simmetriche non si limita quindi all’uso di un centrodi distribuzione, ma può utilizzare i meccanismi della crit-tografia asimmetrica, a partire dal primo che è stato pub-blicizzato: lo scambio di chiavi secondo Diffie-Hellmann.

Whitfield Diffie e Martin Hellmann pubblicarono il primoarticolo sui crittosistemi a chiave pubblica (“New Direc-tions in Cryptography”) nel 1976, descrivendo un metodoper stabilire un dato segreto condiviso sulla base delloscambio d’informazioni non segrete su un canale non si-curo. Lo scambio di chiavi Diffie-Hellmann non è studiatosolo per ragioni storiche; è tuttora alla base, per esempio,del protocollo IKE (Internet Key Exchange) di scambio del-le chiavi utilizzato da IPSec, la forma più avanzata di sicu-rezza a livello IP (IPSec è lo standard più sicuro per le retiprivate virtuali o VPN).

Mostriamo brevemente come funziona lo scambio Diffie-Hellmann. Supponiamo che Alessandro e Bruno siano i par-tecipanti allo scambio e che, per prima cosa, concordinosulla scelta di un numero primo p e di un generatore g. Loscambio avviene in due parti. Nella prima parte, sia Ales-sandro sia Bruno scelgono un numero privato casuale, aper Alessandro e b per Bruno, e lo usano come esponentenelle espressioni seguenti per produrre un valore pubblico(A per Alessandro e B per Bruno). Ricordiamo che mod p(modulo p) indica il resto della divisione per p.

Alessandro BrunoA=ga mod p B=gb mod p

www.pcopen.it33

NOTA: CertificateAuthority oCertificationAuthority?Nella letteratura, unaCA viene spessodefinita unaCertificate Authorityanziché unaCertificationAuthority. Comefanno rilevare Adamse Lloyd nel loroeccellente“Understanding PKI”,ciò è scorrettotecnicamente elogicamente, perchénon esiste una“Certificate Authority”nell’X.509 e perchéla CA non ha autoritàsui certificati. NellaPKI, l’autorità suicertificati è unapolicy authority (ossiapolicy managementauthority), mentreuna CA è solo lostrumento cheemette i certificati inconformità allaCertificate Policy(politica deicertificati) dettatadalla policy authority.Anche l’autorevole“Digital Signatures”di RSA Press utilizzala forma CertificationAuthority.

www.pcopen.it34


Ora Alessandro e Bruno si scambiano i valori pubblici:Alessandro invia A a Bruno e Bruno invia B ad Alessandro.Alessandro e Bruno elevano a potenza i valori pubblici ri-cevuti, usando come esponente il proprio valore privato.

Alessandro BrunoBa mod p = gab mod p = Ab mod p

Il valore ottenuto è il segreto condiviso; ora Alessandroe Bruno possono usarlo per proteggere le loro comunica-zioni. A e B sono stati trasmessi su una rete insicura senzanessun rischio per la sicurezza. Neppure g e p hanno biso-gno di essere tenuti segreti, perché non permettono di sco-prire il segreto.

Questa versione dello scambio di chiavi è vulnerabile altipo di attacco chiamato man-in-the-middle (l’uomo inmezzo), dove il nemico si presenta ad Alessandro come sefosse Bruno e a Bruno come se fosse Alessandro, racco-gliendo e decifrando le informazioni trasmesse. Questa vul-nerabilità viene eliminata facendo in modo che Alessandroe Bruno firmino digitalmente i propri valori pubblici, il cheimpedisce all’uomo in mezzo d’ingannare Alessandro eBruno, come avviene in IKE (Internet Key Exchange). Un ot-timo riferimento a riguardo è “IPSec” di Nagand Dora-swamy e Dan Harris (l’autore del protocollo IKE).

Questo capitolo ha proposto una serie (non completa)di spunti sul tema della gestione e distribuzione delle chia-vi. Come ultimo argomento, citiamo alcuni possibili ap-procci alla generazione delle chiavi asimmetriche, unaspetto legato alla loro distribuzione. Abbiamo già distintotra l’uso di PGP (e delle sue varianti Open Source) e la ge-nerazione autonoma della coppia di chiavi e il ricorso a unaCertification Authority per la generazione dei certificati edelle relative chiavi su cui tali certificati si basano. Duran-te la richiesta di un certificato, la Certification Authority faeseguire al computer dell’utente la generazione della cop-pia di chiavi e si prende unicamente la chiave pubblica alfine di generare il certificato che rilascia contestualmente.La chiave pubblica viene quindi mantenuta negli archividella CA e il proprietario ne dispone di una copia locale as-sieme alla chiave privata che dovrà mantenere segreta, ma-gari rimuovendola anche dal computer perché la relativasegretezza costituisce l’unica garanzia ai fini dell’autenti-cazione. Nell’ambito della PKI (infrastruttura a chiave pub-blica), le coppie di chiavi possono anche essere generatesul computer della CA, ma tale approccio non viene utiliz-zato nella pratica poiché consente il ripudio, visto che l’u-tente non sarebbe l’unico possessore della chiave privata.Di conseguenza la coppia di chiavi viene sempre generatasul computer dell’utente (per esempio mediante le funzio-ni del browser) e solo la chiave pubblica viene trasmessaalla CA o alla RA (Registration Authority, un elemento op-zionale della PKI a cui la CA può delegare parte dei propricompiti). I libri sulla PKI e sulle firme digitali espandono ta-le argomento, oggetto di discussioni e di varie soluzioni.

Ruolo del software libero nella crittografiaPer software libero (traduzione di free software), s’in-

tende software che 1) può essere liberamente eseguito per qualunque scopo 2) può essere studiato e adattato da chiunque, data la pub-

blica disponibilità del codice sorgente 3) può essere liberamente ridistribuito, in modo da aiutare

altri utenti 4) può essere migliorato e rilasciato al pubblico, così che

l’intera comunità ne tragga beneficio. La definizionecompleta di software libero è pubblicata nel sito dellaFree Software Foundation alla pagina www.fsf.org/licen-sing/essays/free-sw.html. GNU (pronuncia gutturale co-me in Wagner), acronimo ricorsivo di “GNU is Not Unix”,è un esempio di software libero compatibile con Unix eoggi ampiamente utilizzato nelle varianti GNU/Linux

che utilizzano il kernel (nucleo) di Linux.Il software libero, grazie alla vitalità delle comunità di

utenti e sviluppatori, ha dato un grosso contributo alla dif-fusione del software crittografico e all’evoluzione delle ca-ratteristiche di robustezza e prestazioni di tutte le imple-mentazioni.

La moderna crittografia si basa sul principio già citatoche è preferibile rendere pubblici gli algoritmi e puntaresulla segretezza e sulle caratteristiche delle chiavi per ot-tenere il massimo livello di sicurezza. La robustezza di uncrittosistema si basa, in primo luogo, sulla validità dell’al-goritmo (o algoritmi) e sulla lunghezza delle chiavi (altri fat-tori in gioco sono, ad esempio, la qualità e la correttezzadell’implementazione e l’efficacia della gestione delle chia-vi). Se l’algoritmo è robusto, basta utilizzare chiavi abba-stanza lunghe per dilatare a piacere (anche trilioni d’anni)il tempo presumibilmente necessario per ricostruire unachiave o comunque violare l’algoritmo.

Vista la complessità e la delicatezza del software critto-grafico, dove un errore può sfuggire più facilmente che nel-le normali implementazioni, la disponibilità delle specifichedegli algoritmi ha consentito un ampio studio dei loro proe contro e la nascita di numerosi progetti open source e re-lative implementazioni. Il confronto tra diverse implemen-tazioni, la partecipazione di esperti e l’utilizzo da parte diun esercito di utenti che non sarebbe stato raggiungibiledal software a pagamento, ha permesso a tali progetti diprodurre software di qualità eccellente. Anche le aziendeprivate hanno contribuito allo sviluppo di tale software,rendendo disponibili implementazioni di riferimento e an-teponendo i benefici derivanti dalla qualità dei sorgenti,ampiamente diffusi, al possibile inconveniente del riutiliz-zo da parte di terzi, che caratterizza il software libero. Inol-tre, l’ampia diffusione e l’assenza di barriere artificiali hapermesso ai produttori di software crittografico di esegui-re test d’interoperabilità dei loro prodotti a costo più bas-so e con la necessità di eseguire meno test con i concor-renti, potenzialmente dispendiosi in termini di tempo e dienergie.

Perciò il software libero non va inteso come softwaregratuito, anche se può esserlo; talvolta il software libero,anche nella crittografia, fornisce maggiori garanzie rispet-to al software commerciale. La disponibilità dei sorgentipermette agli utenti che dispongono delle competenze ne-cessarie di accertarsi che il software sia ben realizzato, im-plementi fedelmente le specifiche e non nasconda qualchebackdoor.

Una lista non completa, ma significativa di progetti freesoftware in corso è la seguente.

- Progetto OpenSSL (www.openssl.org): si basa sull’ec-cellente libreria software SSLeay sviluppata da Eric Younge Tim Hudson e mette a disposizione un’implementazionemolto robusta dei protocolli SSLv2 e SSLv3 (http://wp.net-scape.com/eng/ssl3/) e TSLv1 (RFC 2246) e una libreria difunzioni crittografiche di uso generale, utilizzate sia da al-tri progetti open source sia da applicazioni software com-merciali.

- OpenCA Labs (ex Progetto OpenCA, www.openca.org):è un’organizzazione aperta avente lo scopo di studiare esviluppare progetti relativi alla PKI. Il progetto originale èstato suddiviso in unità più piccole per accelerare e meglioorganizzare gli sforzi. Il progetto OpenCA di sviluppo di unaPKI è uno sforzo collaborativo per sviluppare una Certifi-cation Authority open source attraverso l’uso dei proto-colli crittografici più robusti e ampiamente accettati. Open-CA si basa su diversi progetti open source, come OpenL-DAP, OpenSSL, Apache e Apache mod_ssl.

- Progetti Open Source PKI Mozilla(www.mozilla.org/projects/security/pki): librerie critto-grafiche per lo sviluppo di applicazioni, tra cui Network Se-curity Services (NSS), Network Security Services for Java(JSS), Personal Security Manager (PSM) e PKCS #11 Confor-

5.2.5.4 conoscere ilruolo giocatodall'open source nelgarantire larobustezza e ladisponibilità dellacrittografia


mance Testing. Gli obiettivi generali di questi progetti sono:migliorare la qualità, scalabilità e set di funzionalità del co-dice usato per creare prodotti PKI, incoraggiare lo svilup-po di applicazioni PKI, migliorare la fiducia nel software disicurezza e accelerare la crescita di una piattaforma di si-curezza basata sugli standard per l’e-commerce e per In-ternet.

- Progetto OpenLDAP (www.openldap.org): un’imple-mentazione open source completa di un server LDAP (Li-ghtweight Directory Access Protocol) e dei relativi stru-menti di sviluppo. Pur non essendo software crittograficoin senso stretto, è un componente di base delle infrastrut-ture a chiave pubblica.

- Progetto MUSCLE (www.linuxnet.com/): librerie per ilsupporto crittografico e smartcard per i sistemi operatividella famiglia Unix/Linux e Mac OS X. MUSCLE significa Mo-vement for the Use of Smart Cards in a Linux Environment.

- GnuPG (GNU Privacy Guard, www.gnupg.org): è uncompleto sostituto (libero) del commerciale PGP, che nonusa algoritmi brevettati ed è stato riscritto per essere di-stribuito con licenza GPL. E’ una completa implementazio-ne di OpenPGP (RFC 2440) e può utilizzare gli algoritmi dicifratura ed hash ElGamal, DSA, RSA, AES, 3DES, Blowfish,Twofish, CAST5, MD5, SHA-1, RIPEMD-160 e TIGER. Di persé, GnuPG è uno strumento a linea di comando; può esse-re utilizzato dalla linea di comando, da script di shell o daaltri programmi, come i front-end grafici disponibili perWindows e per Linux.

Uso della crittografiaCome anticipato nei capitoli precedenti, una delle ap-

plicazioni delle tecniche crittografiche a un dato, un docu-mento oppure un messaggio, consiste nell’accertarne laprovenienza, verificandone l’autenticità.

Una tecnica semplice, applicabile ai rapporti bilateralitra due interlocutori, è l’uso di una chiave segreta. Le dueparti concordano l’uso di un algoritmo simmetrico e stabi-liscono una chiave segreta, che può essere comunicata dipersona o inviata in modo sicuro (la chiave dovrebbe es-sere modificata di frequente).

Il mittente può cifrare l’intero messaggio con la chiavesegreta e inviarlo al destinatario. Costui lo decifra e, sicu-ro che la chiave non sia nota ad alcun estraneo, deduce cheil messaggio proviene effettivamente dal mittente appa-rente. In tal caso, visto che il messaggio è cifrato, viene as-sicurata sia l’autenticità sia la riservatezza.

Se peraltro il messaggio non fosse confidenziale e ci ba-stasse garantirne l’autenticità, anziché cifrare l’intero mes-saggio, potremmo utilizzare un MAC (Message Authenti-cation Code). Nel capitolo sulle funzioni hash abbiamo vi-sto che si può calcolare un hash (o digest), tipicamente di128 o 160 bit, sul messaggio a cui è stata aggiunta la chiavesegreta, dopo di che si spedisce il messaggio più l’hash. Ta-le hash prende il nome di MAC (codice di autenticazionedel messaggio) perché consente al destinatario di appura-re se il messaggio è autentico, cioè proveniente dal mit-tente dichiarato. Nell’ipotesi che la chiave sia nota solo al-le due controparti (basata unicamente sulla fiducia), nes-sun altro potrebbe impersonare il mittente o modificarneun messaggio senza farsi scoprire dal destinatario. Que-st’ultimo ricalcola l’hash sul messaggio più la chiave e loconfronta con il MAC ricevuto; se sono uguali, il messaggioè autentico e integro.

Vista l’efficienza con cui si calcola un MAC e la compat-tezza tanto del MAC quanto della chiave segreta, la tecnicapuò essere utilizzata anche su dispositivi con risorse e me-moria limitate, come le smartcard (in teoria si chiamanoSmart Card, semplificato poi a smart card e, nell’uso co-mune, a smartcard).

Un limite del MAC è il suo carattere bilaterale, che nonlo rende estendibile a più interlocutori. Se da un lato due in-terlocutori sono pochi, dall’altro sono troppi: un altro li-mite del MAC è che la chiave segreta non è associata a unsingolo proprietario, quindi in caso di controversia non èfacile appurare le responsabilità. Quando il proprietariodella chiave è un programma, anziché una persona, la so-luzione è usare chiavi simmetriche di sessione generate inmodo casuale e di breve durata.

Una tecnica di autenticazione più efficace consiste nel-l’utilizzo della crittografia a chiave pubblica, vale a dire nel-l’uso di algoritmi a chiavi asimmetriche. Il mittente cifra ildato di cui vuole garantire l’autenticità con la propria chia-ve privata. Chiunque potrà decifrarlo con la chiave pub-blica del mittente, accertandone la provenienza (nessun al-tro può usare la sua chiave privata). Tale meccanismo vie-ne utilizzato per la firma digitale, che essenzialmente è unhash calcolato sul messaggio e cifrato con la chiave priva-ta del mittente (la firma digitale è trattata in una delle pros-sime lezioni).

Hashing per garantire integrità e autenticazioneLe funzioni hash sono diventate uno dei componenti di

base dei crittosistemi sia simmetrici, sia asimmetrici. Negliesempi precedenti abbiamo visto che l’hashing può essereusato in due modi: 1) per produrre un dato di lunghezzabreve e limitata (l’hash o digest), ricavato da un input dilunghezza variabile e 2) per produrre l’hash sulla base delmessaggio e di una chiave segreta condivisa tra due inter-locutori.

Nel primo caso, la funzione di hash si chiama one-wayhash function perché produce una trasformazione a sensounico, dove a N possibili input corrisponde un output, dacui non è possibile risalire all’input. La corrispondenza N:1deriva dal fatto che i possibili input sono praticamente illi-mitati, mentre i possibili valori di output sono 2L, dove L èla lunghezza dell’hash (per esempio 128 o 160 bit).

Nel secondo caso il codice di hash viene chiamato MAC(codice di autenticazione del messaggio) e la tecnica di fardipendere l’hash dal messaggio e da una chiave segreta vie-ne chiamata keyed hashing.

Il keyed hashing viene usato nella crittografia simmetri-ca per produrre i codici MAC utilizzati per autenticare imessaggi e garantirne l’integrità: solo i due interlocutoriposseggono la chiave segreta (solitamente una session keydi breve durata) e qualsiasi modifica al messaggio sarebbescoperta dal mittente nel ricalcolare il MAC e nel confron-tarlo con il MAC ricevuto.

La variante HMAC descritta nel capitolo 5.2.4.1 (Princi-pi di hashing), più sicura di un semplice MAC, viene cor-rentemente usata in molte applicazioni di sicurezza per laprotezione delle comunicazioni su reti TCP/IP (Internet ereti locali).

L’hashing one-way viene usato nella crittografia asim-metrica per produrre le firme digitali (ad esempio con gli al-goritmi RSA o DSA), anche in questo caso per assicurarel’autenticità e l’integrità dei dati trasmessi o archiviati.

In pratica, l’autenticazione viene eseguita tramite HMACo tramite firme digitali, ma in entrambi i casi si usano i me-desimi algoritmi di hashing, come MD5 e SHA1. Spesso ledue forme di cifratura, simmetrica e asimmetrica, vengonoimpiegate contemporaneamente. Per esempio, SSL utilizzai certificati a chiave pubblica per la fase di autenticazioneiniziale (almeno del server, in opzione anche del client, chenormalmente è un browser) e utilizza gli HMAC sia nella fa-se di handshaking (scambio di chiavi e accordo sui cifrarida usare) sia durante la trasmissione del messaggio per ga-rantirne la riservatezza e l’integrità.

Schemi ibridi analoghi si trovano, ad esempio, nei pro-

www.pcopen.it35

5.2.6.2 essereconsapevoli dell'usodi hashing e digestnel garantire integritàe autenticazione

5.2.6. Uso dellacrittografia

5.2.6.1 conoscerecome utilizzare imeccanismi dellacrittografia perottenereautenticazione.


tocolli IPSec (sicurezza allo strato di rete) e SHTTP (sicu-rezza allo strato applicativo), con autenticazione dei com-puter tramite certificato e autenticazione dei messaggi tra-mite HMAC.

Nell’autenticazione dei messaggi di posta elettronica, lacrittografia asimmetrica viene usata per firmare digital-mente il messaggio, vale a dire per cifrare un hash del mes-saggio con la chiave privata del mittente.

Autenticazione e non ripudio mediante firmadigitale

I cifrari asimmetrici e gli algoritmi di hashing permetto-no di verificare l’autenticità e l’integrità di un messaggio at-traverso una firma digitale. Prima di scendere in maggiordettaglio, vediamo quali sono i requisiti di una firma e se lafirma digitale equivale a una firma autografa.

Una firma autografa serve, principalmente, a fornire cer-tezza legale e commerciale riguardo: 1) l’intenzione e l’im-pegno a realizzare quanto stipulato, 2) l’autenticità del do-cumento, che le firme legano ai firmatari, e 3) l’approva-zione o l’autorizzazione (la firma testimonia che i firmata-ri hanno letto e approvato il documento). Altri aspetti ri-guardano la sicurezza di una transazione e l’aspetto ceri-moniale (la firma avverte che si sta prendendo un impegnovincolante e suggerisce al firmatario di ponderare sul do-cumento e prendere consapevolezza del suo significato edelle conseguenze, prima di firmarlo).

Una firma dev’essere difficile da falsificare, non ripudia-bile (non può essere cancellata o disconosciuta), inaltera-bile (dopo l’apposizione della firma, non deve essere pos-sibile modificare il documento) e non trasferibile (da un do-cumento a un altro).

Il presupposto per la validità delle firme è che le chiaviprivate siano tenute al sicuro e che i titolari siano respon-sabili del loro utilizzo fino al momento di un’eventuale de-nuncia di furto o smarrimento. L’impiego del timestampnelle firme è necessario affinché una successiva compro-missione (anche volontaria) delle chiavi segrete non portiall‘invalidazione di tutti i documenti firmati, precedenti al-la compromissione stessa. Ciò significa che, se le chiavi e idigest hanno lunghezza adeguata, la firma è pressoché im-possibile da falsificare e lega il documento al firmatario,che non potrà ripudiare il documento firmato. Dato che lafirma dipende dal contenuto del documento, l’integrità èassicurata. Un documento cartaceo firmato potrebbe es-sere alterato con maggiori probabilità di successo di quan-to avvenga per un documento digitale. Per lo stesso moti-vo, la firma non è trasferibile a un altro documento, vistoche è strettamente legata al contenuto del documento, adifferenza di una firma autografa che ha sempre lo stessoaspetto.

Come abbiamo visto, la firma digitale si basa sulla cifra-tura asimmetrica di un hash o digest calcolato sul conte-nuto del documento o messaggio. L’hash costituisce un’im-pronta del documento: è assai improbabile che documen-ti diversi producano lo stesso hash, così com’è pressochéimpossibile creare un documento capace di produrre uncerto hash. Gli algoritmi di hash più usati sono MD5 e SHA-1, quest’ultimo è preferibile perché più sicuro.

La firma viene ottenuta cifrando l’hash con un algoritmoasimmetrico e utilizzando la chiave privata del firmatario.I cifrari più utilizzati sono il commerciale RSA o il pubblicoDSA che, insieme a SHA-1, fa parte dello standard DSS di fir-ma digitale definito dal governo degli Stati Uniti.

L’affidabilità di un sistema di firma digitale dipende davari fattori: la robustezza degli algoritmi di hash e cifratu-ra, la dimensione delle chiavi e degli hash, il livello di pro-tezione con cui è gestita (creata, trasmessa, custodita) lachiave privata e il grado di certezza che la chiave pubblicasia autentica, cioè appartenga al firmatario del documento.Se la chiave pubblica viene sostituita, l’intero sistema ècompromesso, visto che si può firmare qualunque cosa

con la chiave privata corrispondente alla falsa chiave pub-blica.

La verifica della firma digitale consiste di tre passi: 1) sidecifra la firma utilizzando la chiave pubblica del firmata-rio, ricostruendo l’hash originale del messaggio, 2) si cal-cola l’hash sul contenuto del messaggio (utilizzando lostesso algoritmo usato dal mittente), 3) si confrontano idue hash, quello della firma e quello ricalcolato: se coinci-dono, significa che il messaggio non è stato alterato e chela chiave privata con cui è stato firmato il documento ap-partiene allo stesso proprietario della chiave pubblica concui è stata decifrata la firma.

Dato che per ogni chiave pubblica esiste una sola chia-ve privata, la verifica di una firma digitale assicura che chiha firmato il documento è il possessore della chiave priva-ta. Perché la firma non possa essere ripudiata, occorre sod-disfare una serie di condizioni. Le principali sono l’asso-ciazione certa tra il firmatario e la sua chiave pubblica, lacustodia sicura della chiave privata e l’utilizzo da parte delfirmatario di un software che consenta la visualizzazionedel documento all’atto della firma, in modo da avere la cer-tezza del contenuto.

Il ruolo di una struttura nell’uso della firma digitale

Abbiamo visto le tecniche e gli algoritmi che si possonoutilizzare per garantire l’autenticazione, l’integrità, la ri-servatezza e il non ripudio nello scambio di messaggi at-traverso un canale di comunicazione non sicuro. Inoltre ab-biamo notato l’esigenza di soddisfare una serie di requisi-ti affinché sia possibile utilizzare queste tecnologie e affin-ché esse permettano di raggiungere gli obiettivi di sicurez-za.

Facciamo un esempio applicato alla posta elettronica,chiedendoci in che modo il destinatario di un messaggiopossa essere certo dell’identità del mittente. Supponiamoche il mittente apponga la firma digitale al messaggio nelmodo visto sopra (hashing più cifratura asimmetrica). Per-ché il destinatario possa verificare la validità della firma, ènecessario che 1) egli possa procurarsi la chiave pubblicadel mittente in modo sicuro, 2) conosca il formato dei datie 3) conosca gli algoritmi utilizzati per la composizione e lafirma del messaggio.

www.pcopen.it36

5.2.6.3 Conoscere iprincipali aspettidella firmaelettronica nelgarantire il non-ripudio el'autenticazione

Procedura per lacreazione di una firma

digitale

Verifica di validità dellafirma digitale


Per soddisfare queste condizioni, è possibile introdurreuna struttura comune (condivisa da una comunità di uten-ti) che consenta alle entità che devono comunicare (comeutenti e processi) d’interoperare con successo. In partico-lare, si può risolvere il problema della distribuzione sicuradelle chiavi ricorrendo a una struttura gerarchica, la già ci-tata Certification Authority (CA), che si faccia garante del-l’identità di tutte le entità titolari di una chiave pubblica (eprivata). Inoltre, i messaggi e i protocolli di comunicazionedevono essere conformi a determinati standard, indipen-denti dal sistema operativo, dal software applicativo e daqualsiasi peculiarità del sistema utilizzato.

La CA garantisce le chiavi pubbliche delle entità delproprio dominio mediante l’emissione dei “certificati digi-tali” in formato standard, contenenti:

1) una serie d’informazioni, tra cui il nome del titolaredel certificato, la sua chiave pubblica, il periodo di validitàdel certificato e altre informazioni che concorrono a iden-tificare il titolare e l’autorità che emette il certificato; 2) lafirma digitale, apposta alle suddette informazioni utiliz-zando la chiave privata della CA.

Tutte le entità che fanno parte del dominio (o dominiodi trust) della CA devono ricevere in modo sicuro la chia-ve pubblica della CA, in modo da poter verificare la validitàdi qualunque certificato del proprio dominio. Nel contestodi una struttura che faccia uso delle CA per l’emissione deicertificati e la generazione delle chiavi asimmetriche, il for-mato dei certificati per le chiavi pubbliche è definito dallanorma ITU X.509 Versione 3. L’utilizzo di PGP per la cifra-tura e firma dei messaggi di e-mail è alternativo all’uso diuna CA ed è orientato a comunità limitate d’individui inrapporto di reciproca fiducia. Può utilizzare i certificati, maessi hanno un formato diverso dall’X.509. Nel campo delleimprese e delle pubbliche istituzioni, vengono usate le CAe i certificati nell’ambito di una PKI (infrastruttura a chiavipubbliche). Rimandiamo a una sezione successiva (5.2.7.3)la spiegazione in dettaglio del funzionamento di PGP.

Il formato con cui sono codificati i messaggi creati conla cifratura asimmetrica è definito dallo standard PKCS #7Cryptographic Message Syntax (CMS). PKCS significa Pu-blic Key Cryptographic Standard e comprende un’intera se-rie di standard che hanno l’obiettivo di agevolare l’imple-mentazione delle tecnologie PKI (per esempio, PKCS #1 de-scrive lo standard di cifratura RSA). PKCS #7 specifica i for-mati binari usati per la firma digitale e per la “busta elet-tronica”. Una busta elettronica (digital envelope) consistedi un messaggio che usa la cifratura simmetrica a chiave se-greta e una chiave segreta cifrata in modo asimmetrico (co-me nell’esempio del capitolo 5.2.3.1 - Principi di crittogra-fia asimmetrica). Qualunque messaggio formattato conCMS può essere incapsulato dentro un altro messaggioCMS, applicando ricorsivamente la busta elettronica. Ciòpermette agli utenti di firmare una busta digitale, di cifrareuna firma digitale o di eseguire varie altre funzioni. Lo stan-dard PKCS #7 è stato adottato dall’IETF nella RFC 2315, ag-giornata dalla RFC 2630.

Altre proprietà del formato CMS sono: 1) gestisce la fir-ma congiunta di più firmatari, 2) gestisce la firma per un nu-mero arbitrario di destinatari, 3) consente di aggiungere at-tributi firmati al messaggio, come la data e l’ora della firma,4) consente di allegare al messaggio i certificati dei firma-tari, agevolando la verifica della firma, 5) include gli iden-tificatori degli algoritmi crittografici utilizzati e gli elemen-ti che facilitano la decifratura e la verifica della firma.

Uso della crittografia per ottenere la riservatezza

Come abbiamo visto nei capitoli precedenti, la riserva-tezza (o confidenzialità) viene ottenuta cifrando i dati, imessaggi o i documenti da archiviare o da trasmettere. Aseconda delle applicazioni, si utilizzano cifrari simmetrici(a chiave segreta) o asimmetrici (con chiave privata e chia-

ve pubblica). I cifrari simmetrici possono essere applicatia dati di dimensioni illimitate, mentre quelli asimmetricifunzionano per input di poche decine di byte.

Un cifrario simmetrico richiede che due interlocutori(persone o componenti hardware/software) concordinosull’uso di un algoritmo e scelgano una chiave segreta dausare per cifratura e decifratura. Il mittente cifra il mes-saggio e lo trasmette; il destinatario decifra il messaggiocon la stessa chiave usata dal mittente e ripristina il con-tenuto in chiaro.

Un’altra possibilità è utilizzare un programma separatoper la cifratura e decifratura dei file e inviare i dati cifrati co-me allegati. Ci sono applicazioni di questo tipo sia per uten-ti finali sia per utenti più esperti che vogliono controllarel’algoritmo usato e la lunghezza della chiave.

La crittografia simmetrica è semplice da usare ed effi-ciente, ma presenta il problema della gestione delle chiavi,che devono essere diverse per ogni coppia d’interlocutorie devono essere sostituite di frequente.

Se si utilizza la crittografia asimmetrica, ogni interlocu-tore possiede due chiavi: custodisce al sicuro la chiave pri-vata e mette a disposizione di chiunque la chiave pubblica.Il mittente si procura la chiave pubblica del destinatario, lausa per cifrare il messaggio tramite un cifrario asimmetri-co e invia il messaggio cifrato. Il destinatario decifra il mes-saggio usando lo stesso cifrario e la sua chiave privata. Intal modo, si risolve un problema di distribuzione delle chia-vi, ma se ne creano altri due: i cifrari asimmetrici sono mol-to lenti e possono ricevere in input dati molto brevi, perciòdebbono lavorare cifrando il messaggio in blocchi il che ral-lenta ulteriormente le operazioni .

La soluzione sta nell’utilizzo contemporaneo dei due ti-pi di crittografia: asimmetrica per gestire lo scambio dellechiavi e simmetrica per cifrare i messaggi. La procedura èla seguente:1) si sceglie un algoritmo simmetrico e uno asimmetrico 2) il mittente si procura la chiave pubblica del destinatario3) il mittente genera in modo casuale una chiave segreta

appropriata4) il mittente cifra il messaggio utilizzando la chiave segre-

ta5) il mittente cifra la chiave segreta utilizzando la chiave

pubblica del destinatario6) il mittente invia al destinatario il messaggio cifrato e la

chiave segreta cifrata, insieme alle informazioni neces-sarie per la decifratura

7) il destinatario decifra la chiave segreta utilizzando la pro-pria chiave privata

8) il destinatario decifra il messaggio utilizzando la chiavesegreta.

Tale meccanismo è comunemente usato dalle applica-zioni di comunicazione sicura su Internet, come i client diposta elettronica, e dai protocolli di trasmissione sicura,

www.pcopen.it37

5.2.6.4 Conoscere iprincipi e le principalicaratteristiche dellacifratura nel garantirela confidenzialità

Uso della crittografiaasimmetrica per gestire loscambio delle chiavi esimmetrica per cifrare imessaggi (immagini da 1a 7)

1

2


come SSL (Secure Sockets Layer). In quest’ultimo caso, ilprotocollo opera allo strato di trasporto (sopra il TCP),quindi non protegge singoli messaggi, ma tutti i dati tra-smessi nell’ambito di una connessione Internet.

Le tecniche per ottenere la riservatezza delle informa-zioni sono utilizzabili anche per la privacy delle informa-zioni archiviate, in modo che non siano accessibili da estra-nei. In tal caso si utilizzano solitamente algoritmi simme-trici; dato che mittente e destinatario coincidono, non c’èil problema della trasmissione della chiave segreta, è suffi-ciente che l’utente scelga una chiave abbastanza lunga ecomplessa e la tenga al sicuro. Tra gli esempi citiamo l’En-cryption File System di Windows XP (per cifrare file e car-telle) e applicazioni stand-alone come Axcrypt (http://ax-crypt.sourceforge.net/), che utilizza AES con chiavi di 128bit ed è particolarmente comodo da usare.

A parte le applicazioni specificamente crittografiche, iprogrammi di office automation e le utility di archiviazionee compressione offrono solitamente opzioni di protezionedei dati tramite password, generalmente realizzate con crit-tografia simmetrica.

Tale crittografia viene spesso implementata con unsemplice XOR e assicura un livello di protezione del tuttoinsufficiente, valido unicamente a difendersi dagli incom-petenti, ma non certo per bloccare persone determinate aviolarla (nemmeno se queste sono semplici utenti).

Tuttavia, non sempre documentano l’algoritmo usato, il

quale rischia di non essere abbastanza robusto per pro-teggere dati importanti. Per garantire la riservatezza, è ne-cessario che l’algoritmo sia robusto (come 3DES e AES),che la chiave sia di lunghezza adeguata (per esempio 128bit) e che il suo valore sia non prevedibile e sia mantenutosegreto.

ApplicazioniUn vasto campo di applicazione delle misure di prote-

zione crittografiche è quello degli affari e della pubblica am-ministrazione. La possibilità di eseguire transazioni da ca-sa e ufficio attraverso Internet ha portato in primo pianol’esigenza di utilizzare meccanismi di sicurezza adeguati.Consideriamo l’utilizzo di Internet per accedere ai servizibancari online (conti correnti, pagamenti, investimenti,ecc.) e per eseguire operazioni di acquisto e vendita online.Indipendente dalle reali implementazioni, possiamo svi-luppare alcune considerazioni.

Le operazioni di e-banking e di e-commerce che un uten-te può eseguire on-line sono di due tipi:1) operazioni di carattere informativo, come la visualizza-

zione di un estratto conto, la situazione dei bonifici, lostato degli ordini oppure lo stato di un’asta elettronica,

2) operazioni di tipo dispositivo, come un ordine di acqui-sto, un ordine di bonifico, la vendita di azioni oppure ilpagamento di un’utenza.Le operazioni di carattere informativo forniscono ac-

cesso ai dati in lettura e non danno origine a flussi di de-naro. Normalmente è sufficiente proteggere il canale di co-municazione e il protocollo SSL incorporato nei browser èperfettamente adeguato allo scopo.

Per le operazioni di tipo dispositivo sono ipotizzabili di-verse strade. Il protocollo SSL, spesso utilizzato, può risul-tare adeguato nei casi in cui gl’importi in gioco non sugge-riscano di adottare meccanismi di protezione più robusti.Sebbene SSL utilizzi algoritmi crittografici affidabili, l’e-ventuale punto debole è che protegge solo il canale di co-municazione, dopo di che i dati sono messi in chiaro dalserver web, senza un controllo preciso di chi possa acce-dere alle informazioni.

La protezione crittografica della rete viene spesso di-stinta in due categorie: link encryption ed end-to-end en-cryption. La protezione del collegamento (link) si applicaagli strati inferiori dei protocolli di comunicazione, fino al-lo strato di trasporto in cui opera SSL. Il modello end-to-endsi applica allo strato applicativo: end-to-end significa chesono le applicazioni, ai due estremi (end) della comunica-zione, che controllano la cifratura e decifratura e quindi lamessa in chiaro dei dati. In tal modo i dati sono più protet-ti e meno soggetti a intrusioni da parte di altre entità del si-stema.

Esempi di protocolli di sicurezza allo strato applicativosono S-HTTP (Secure Hypertext Transport Protocol) e SET(Secure Electronic Transaction), scarsamente usati rispet-to a SSL e alla recente variante TLS. Utilizzando l’approccioend-to-end, l’applicazione può utilizzare le tecniche di ci-fratura viste in precedenza sulle singole disposizioni (i mo-vimenti economici ordinati dall’utente) e provvede sia a da-re corso alle transazioni sia a conservare in modo sicuro imessaggi degli utenti, esponendo le informazioni alla visi-bilità strettamente necessaria.

Firma digitale e non ripudio nei servizi di e-banking e di e-mail

Abbiamo visto che la firma digitale annovera tra le suefunzioni il non ripudio di un messaggio. Normalmente, pos-siamo supporre che gli accessi di tipo informativo non ab-biano bisogno di firma digitale, mentre è prevedibile che ledisposizioni debbano essere firmate dal richiedente. In tal

www.pcopen.it38

3

4

5

6

7

5.2.7. Applicazioni

5.2.7.1 Essereconsapevole dell'usodella crittografia perproteggere i dati nelletransazioni on-linecome avviene nell'e-commerce e nell'e-banking

5.2.7.2 Essereconsapevole dell'usodella firma digitaleper garantire il non-ripudio


modo, se la firma non risultasse valida (per esempio a cau-sa di un certificato scaduto o revocato), la disposizionenon verrebbe eseguita. Inoltre i messaggi sono registrati,così che la banca o altra organizzazione possa sempre di-mostrare di aver ricevuto una disposizione valida firmatadal cliente e non ripudiabile.

Il non ripudio può non essere sufficiente se non è asso-ciato in modo certo all’istante temporale della firma. Per-ciò, la firma digitale può essere utilmente affiancata da unservizio di marcatura temporale (timestamp). Si tratta diun servizio fornito da una Time Stamp Authority (TSA), unaterza parte fidata che attesta il tempo di produzione o d’in-vio di un documento tramite una “marca temporale”, che èdi fatto una controfirma del documento contenente un ha-sh del documento, il riferimento temporale e altre infor-mazioni.

Nel campo del software libero, OpenTSA (www.opent-sa.org) sta sviluppando una TSA aperta e gratuita confor-me alla RFC 3161 (Internet X.509 Public Key InfrastructureTime-Stamp Protocol - TSP). Trai componenti software giàprodotti c’è anche la Time Stamp patch for OpenSSL, un’e-stensione di OpenSSL con marcatura temporale.

Il funzionamento di PGPPretty Good Privacy (PGP) è un programma di sicurez-

za per la posta elettronica realizzato da Phil Zimmermanne pubblicato inizialmente nel 1991 come freeware. Le fun-zioni di PGP sono: firma digitale, cifratura dei messaggi,compressione, conversione in ASCII (in base 64) e seg-mentazione dei messaggi; di queste, le prime due rientranonel contesto delle applicazioni crittografiche.

PGP fu fatto circolare liberamente (incluso il codice sor-gente) e conquistò una rapida popolarità. Per cifrare e fir-mare i messaggi, PGP utilizza la crittografia simmetrica easimmetrica. Inizialmente, il cifrario asimmetrico era RSAe quello simmetrico, dopo un breve periodo con un algo-ritmo rivelatosi poco sicuro, era IDEA. La chiave segretanon fu mai inferiore a 128 bit, contravvenendo alle leggiUSA del tempo. Inoltre RSA negò di aver dato un assensoverbale all’uso del proprio cifrario (brevettato fino al 2000)e il brevetto di IDEA scade nel 2007. Seguirono anni di que-stioni giudiziarie che man mano si sono risolte senza dan-no, grazie anche al successo di PGP e ad accomodamentisui vari fronti. Oggi esiste l’azienda PGP che vende le ver-sioni commerciali del programma e offre una versione li-mitata freeware abbastanza scomoda da usare perché nonintegrata nei programmi di posta. Tuttavia nel 1997 PGP haconsentito all’IETF di pubblicare uno standard aperto colnome di OpenPGP. Le RFC pubblicate sono la 2440(OpenPGP Message Format) del 1998 e la 3156 (MIME Se-curity with OpenPGP) del 2001. La Free Software Founda-tion ha pubblicato la propria versione di PGP (GNU PrivacyGuard: GnuPG o GPG) conforme alle specifiche OpenPGP;è disponibile gratuitamente per diverse piattaforme, tra cuiLinux, MAC OS X e Windows.

Oggi sia PGP sia GPG supportano la maggior parte deimoderni algoritmi crittografici (cifrari simmetrici e asim-metrici e funzioni hash), tra cui RSA, Diffie Hellmann, El-Gamal, 3DES, AES, IDEA, CAST5, SHA, RIPEMD-160 e altri. Adifferenza di PGP, OpenPGP non utilizza IDEA, che non è an-cora libero da brevetti.

Il funzionamento della firma elettronica in PGP avvienenel modo seguente: 1) il mittente scrive un messaggio, 2)viene calcolato un hash del messaggio, 3) l’hash è cifratocon la chiave privata del mittente, 4) il mittente invia il mes-saggio insieme all’hash cifrato, 5) il destinatario riceve ilmessaggio con l’hash, 6) l’hash è decifrato con la chiavepubblica del mittente, 7) viene ricalcolato l’hash sul mes-saggio, 8) vengono confrontati l’hash decifrato e quello cal-colato, 9) se i due hash coincidono, il messaggio è autenti-co e integro.

La riservatezza viene ottenuta nel modo seguente: 1) il

mittente scrive un messaggio, 2) il programma genera unnumero casuale utilizzato come chiave di sessione, ovverouna chiave di cifratura simmetrica usata solo per quel mes-saggio, 3) il messaggio viene cifrato con un algoritmo sim-metrico usando la chiave di sessione generata, 4) la chiavedi sessione è cifrata con la chiave pubblica del destinatario,5) il messaggio cifrato e la chiave cifrata sono inviati al de-stinatario, 6) presso il destinatario, il programma decifra lachiave di sessione utilizzando la chiave privata del desti-natario, 7) il messaggio è decifrato utilizzando la chiave disessione decifrata.

Firma e cifratura possono essere applicate insieme inquesto modo: 1) il mittente scrive un messaggio, 2) il mit-tente firma il messaggio come visto sopra, 3) messaggio edhash sono cifrati come appena visto, 4) messaggio ed hashcifrati sono inviati al destinatario, 5) presso il destinatario,la chiave segreta cifrata è decifrata con la chiave privata,ottenendo la chiave di sessione, 6) il resto del messaggio ri-cevuto è decifrato con la chiave simmetrica di sessione, 7)la prima parte del messaggio decifrato (l’hash) viene deci-frato con la chiave pubblica del mittente, 8) sul resto delmessaggio viene calcolato l’hash, 9) vengono confrontatil’hash decifrato e quello calcolato, 10) se i due hash coin-cidono, il messaggio è autentico e integro.

Come si vede, anche PGP sfrutta i principi visti in pre-cedenza: 1) l’integrità del messaggio viene verificata su unhash del messaggio, non sull’intero messaggio (è molto piùveloce), 2) il messaggio è cifrato con un algoritmo simme-trico, veloce e non vincolato alla lunghezza dei messaggi, 3)l’algoritmo asimmetrico viene usato per lo scambio dellechiavi simmetriche.

Le operazioni sono svolte automaticamente dal softwa-re, senza interventi dell’operatore (dopo la generazione ini-ziale della coppia di chiavi asimmetriche). PGP offre diver-se versioni di software commerciale che si integrano con leapplicazioni di posta. La versione freeware richiede invecela cifratura e decifratura del file o del clipboard, da copia-re a mano nel programma di posta. GPG viene usato comemodulo di base o attraverso un’interfaccia grafica (ne esi-stono per i vari sistemi operativi e hanno nomi diversi) epuò essere integrato con Mozilla e Thunderbird tramite unadd-in chiamato Enigmail.

Per la sicurezza nell’uso di PGP si devono consideraredue aspetti: 1) i numeri “casuali” usati come chiavi di ses-sione devono essere il più possibile realmente casuali; siusano algoritmi PRNG (pseudo-random number generator)e meccanismi che sfruttano eventi casuali naturali per ge-nerare sequenze di numeri casuali e non ripetibili; 2) lechiavi pubbliche devono essere effettivamente tali e verifi-cabili; le implementazioni più moderne di PGP e GPG si ba-sano su un server di distribuzione delle chiavi pubbliche,ma inizialmente le chiavi erano pubblicate su qualche ser-ver e gli utenti si scambiavano gli hash delle chiavi per con-sentire il controllo dell’autenticità.

Installare e configurare un prodotto PGPLe versioni commerciali e la versione freeware di PGP,

con la relativa documentazione, sono disponibili presso ilsito di PGP Corporation (www.pgp.com). La versionefreeware limitata per Windows è scaricabile alla paginawww.pgp.com/downloads/freeware/freeware.html ed è fa-cilmente installabile eseguendo il file scaricato. Un’iconanella barra di notifica di Windows (in basso a destra) dà ac-cesso alle funzioni disponibili (le principali sono genera-zione chiavi, firma, cifratura, firma e cifratura, decifratura).I messaggi possono risiedere in un file o nel clipboard diWindows. Solo le versioni a pagamento includono un plu-gin per i programmi di posta, come Outlook, in modo da fir-mare, cifrare e decifrare i messaggi dall’interno del pro-gramma.

GPG è già incluso in diverse distribuzioni Linux (comeSuSE Linux 9.2 e Fedora 3), inoltre è scaricabile per vari si-

www.pcopen.it39

5.2.7.4 Essere ingrado d'installare econfigurare unprodotto che gestiscail protocollo PGP

5.2.7.3 Conoscere iprincipali aspettioperativi di PGP


stemi operativi presso www.gnupg.org e i siti collegati. Laversione per Windows è a linea di comando, ma esistonoplugin GPG per i programmi di posta, come EudoraGPG perEudora sotto Windows (http://eudoragpg.sourceforge.net/ver2.0/en/).

In Windows, GPG può essere utilizzato direttamenteaprendo il file eseguibile, oppure può essere installato se-condo i canoni di Microsoft editando il registro di sistema.Le istruzioni presso http://enigmail.mozdev.org/gpgcon-fig.html guidano all’installazione e configurazione di GPG inWindows 9x e in Windows NT/2000/XP.

Una sintetica guida in italiano all’uso di GPG è reperibi-le presso www.gnupg.org/(en)/howtos/it/GPGMiniHow-to.html. Un’ottima guida per usare la versione di GPG a li-nea di comando per Windows è www.glump.net/content/gpg_intro.pdf.

L’ambiente idealeper utilizzare GPGè SuSE Linux, datoche il client di po-sta KMail e l’utilitydi gestione dellechiavi KGpg fannoparte dell’interfac-

cia standard KDE. Fedora 3 usa per default l’interfacciaGNOME, ma include parecchie applicazioni KDE, comeKMAIL e KGpg (utilizzabili modificando le applicazioni pre-ferite nelle preferenze).

Per utilizzare GPG s’inizia creando una coppia di chiaviin KGpg. La scelta dell’algoritmo asimmetrico è tra RSA e lacoppia DSA/ElGamal (firma e scambio chiavi).

5.2.7.5 Secure Shell - SSHSecure Shell (SSH) è un protocollo per realizzare un col-

legamento remoto sicuro da un computer a un altro attra-verso una rete insicura. Supporta il login remoto sicuro, iltrasferimento sicuro di file e l’inoltro sicuro del traffico ditipo TCP/IP e X Window. SSH è in grado di autenticare, ci-frare e comprimere i dati trasmessi. Sebbene si chiami Se-cure Shell, SSH non è un vero shell come il Bourne shell(l’interprete dei comandi) o il C shell di Unix e non è un in-terprete di comandi. SSH crea un canale sicuro per esegui-re uno shell da un computer remoto, in modo simile al co-mando rsh (remote shell) di Unix, ma con cifratura end-to-end (da un’applicazione all’altra) tra il computer locale e ilcomputer remoto. A differenza di rsh, SSH assicura l’au-tenticazione, la riservatezza e l’integrità alla trasmissionein rete. Esistono molti prodotti basati su SSH, per i diversisistemi operativi e in versioni sia commerciali sia a liberadistribuzione.

Una comunicazione con il protocollo SSH implica la par-tecipazione di due attori: il client da cui parte la richiestadi collegamento e il server a cui la richiesta è indirizzata.Client e server operano secondo uno schema che prevedenumerose varianti. Inoltre esistono due versioni di proto-collo, SSH-1 e SSH-2, tra loro incompatibili. La prima è sup-portata da tutti i prodotti, ma è vulnerabile; la seconda, piùarticolata e sicura, non è supportata da alcuni prodotti, co-me TGSSH per PalmOS. I programmi recenti supportano en-trambe le versioni e sono quindi in grado di connettersi aqualunque tipo di server.

Il termine SSH indica in genere sia una versione di pro-tocollo che un prodotto software. Per distinguere tra i pro-

www.pcopen.it40

Generazione chiave GPGcon SUSE.

Viene chiesta unapassphrase, o frase

segreta, per proteggerel’accesso alle chiavi.

Le chiavi vengonogenerate e identificate,come indicato da KGpg.

La coppia di chiavi vienequindi elencata nelrepertorio di chiavi

disponibili

Ora occorre configurareKMail nella sezione

Identità, che fariferimento alle chiavi

KGpg

Per firmare e cifrare imessaggi in KMail, si

compone il messaggio,si seleziona un’identità(coppia di chiavi GPG) e

si premono le icone difirma e di cifratura.

Un messaggio firmato e cifrato in KMail,

spedito a se stessi,viene così decifrato e

verificato

5.2.7.5 Conoscere iprincipi operativi diSSH


tocolli e i prodotti commerciali, spesso si usa la seguenteterminologia: SSH-1 e SSH-2 indicano i protocolli (per esem-pio SSH-1-5); SSH1 e SSH2 indicano due prodotti di SSHCommunications Security (formata dal finlandese TatuYlönen, autore della prima versione del protocollo); OpenS-SH è una versione gratuita multipiattaforma di OpenBSDProject; OpenSSH/1 e OpenSSH/2 indicano il comporta-mento di OpenSSH in relazione all’uso di SSH-1 e SSH-2; sshindica un programma client incluso in SSH1, SSH2, OpenS-SH, F-Secure SSH e altri prodotti. SSH e OpenSSH sono de-scritti in vari documenti IETF (nel 2005 ancora a livello dibozza - draft).

Stabilire la connessioneIl funzionamento di SSH è complesso e ricco di funzio-

nalità e opzioni, tanto da richiedere un libro per una de-scrizione completa (il più noto è “SSH, The Secure Shell:The Definitive Guide” di Barret e Silverman, pubblicato daO’Reilly). Vediamo lo schema di funzionamento di SSH-1nella fase in cui viene stabilita la connessione.

1) Il client contatta il server, inviando una richiesta diconnessione alla porta TCP 22 del server; 2) Il server ri-sponde con una stringa (del tipo SSH-1.99-OpenSSH_2.3.0)che indica la versione del protocollo e del prodotto. Se ilclient non supporta la versione (o una delle versioni) delserver, chiude la connessione, altrimenti risponde con unastringa simile. Quando client e server supportano entram-be le versioni di SSH, decidono quale utilizzare.

3) Il client e il server passano all’uso di un formato dipacchetto più sicuro, al di sopra del TCP che funge da tra-sporto, in modo da sventare attacchi al testo in chiaro.

4) Il server identifica se stesso al client e fornisce i pa-rametri per la sessione. Invia le seguenti informazioni inchiaro: la chiave pubblica dell’host (fissata all’installazio-ne), la chiave pubblica del server (rigenerata periodica-mente per sventare tentativi di crittoanalisi), una sequen-za casuale di otto byte (check bytes o cookie) che il clientdovrà ripetere e liste dei metodi di cifratura, di compres-sione e di autenticazione supportati dal server.

5) Sia il client sia il server calcolano un identificativo disessione comune di 128 bit, usato nelle operazioni succes-sive per identificare in modo univoco la sessione SSH. Sitratta di un hash MD5 sull’insieme di chiave host, chiaveserver e cookie.

6) Il client verifica che la chiave host del server corri-sponda alla chiave già memorizzata (la prima volta chiedeconferma). In caso di discrepanza, la connessione termina(il server connesso potrebbe essere quello di un terzo in-comodo che tenta di eseguire un attacco “man in the midd-le” per appropriarsi della connessione).

7) Il client genera una chiave di sessione, ottenuta ge-nerando un numero casuale di 256 bit, calcolando l’OResclusivo tra l’identificativo di sessione e i primi 128 bit del-la chiave di sessione. Scopo della chiave di sessione è ci-frare e decifrare i messaggi tra client e server. Dato che lacifratura non è ancora attiva, la chiave non può essere tra-smessa in chiaro. Perciò il client cifra questa chiave duevolte, sia con la chiave host sia con la chiave server sopracitate. Dopo la cifratura, il client invia la chiave di sessione,insieme al cookie e a una lista di algoritmi, scelti tra quellisupportati dal server.

8) Dopo l’invio della chiave di sessione, entrambe le par-ti iniziano a cifrare i dati con tale chiave e l’algoritmo sim-metrico prescelto. Prima d’inviare dati, però, il client at-tende un messaggio di conferma dal server, cifrato con lachiave di sessione. Esso fornisce l’autenticazione del ser-ver: solo il vero server è in grado di decifrare la chiave disessione, cifrata con la chiave host verificata in preceden-za a fronte della lista degli host noti.

Autenticazione del clientUna volta stabilita la connessione (inclusa autentica-

zione del server), inizia la fase di autenticazione del client.Nel caso più semplice, essa si limita all’invio dell’identifi-cativo di utente e della password; sebbene siano trasmes-si cifrati, tale metodo è poco sicuro e sconsigliato, soprat-tutto per la diffusa abitudine di scegliere password deboli.Normalmente si consiglia di utilizzare una coppia di chiaviRSA o DSA per l’autenticazione del client (SSH accetta co-munque anche altri tipi di autenticazione).

L’autenticazione del client con chiavi RSA in SSH-1 av-viene secondo i passi che seguono. Per accedere a un ac-count su una macchina in funzione di server (client e ser-ver possono comunque scambiarsi i ruoli), il client dimo-stra di possedere la chiave privata corrispondente a unachiave pubblica autorizzata. Una chiave è “autorizzata” sela componente pubblica è contenuta nel file di autorizza-zione dell’account (per esempio ~/.ssh/authorized_keys).

Ecco la sequenza delle azioni.1) Il client invia al server una richiesta di autenticazione

con chiave pubblica e indica quale chiave intende usare(trasmette il modulo e l’esponente, vale a dire i due ele-menti dell’algoritmo RSA che costituiscono la chiavepubblica).

2) Il server legge il file delle autorizzazioni per l’accountdell’utente e cerca una voce contenente la stessa chiave(in sua assenza, l’autenticazione con chiave fallisce). Seil controllo è positivo e non ci sono restrizioni all’uso ditale chiave da parte del client e del suo host, il processocontinua.

3) Il server genera una stringa casuale di 256 bit come chal-lenge, la cifra con la chiave pubblica dell’utente e la in-via al client.

4) Il client riceve il challenge e lo decifra con la corrispon-dente chiave privata; in tale fase il programma di solitochiede all’utente una passphrase (frase segreta) che ser-ve unicamente a decifrare la chiave privata, che per si-curezza è salvata cifrata. Dopo di che il client combina ilchallenge con l’identificativo di sessione, ne calcola l’ha-sh con MD5 e lo invia al server in risposta al challenge.

5) Il server confronta il digest ricevuto con quello calcola-to e, se coincidono, considera autenticato l’utente.La descrizione appena fornita si riferisce a SSH-1; SSH-2

non è molto diverso, ma è più sicuro, più elegante e più fles-sibile. SSH-1 ha una struttura monolitica ed esegue più fun-zioni in un singolo protocollo; SSH-2 è articolato in tre com-ponenti principali: Transport Layer Protocol, ConnectionProtocol e Authentication Protocol. 1) SSH Transport Layer Protocol. Le connessioni negozia-

te con tale protocollo godono di cifratura forte, autenti-cazione del server e protezione dell’integrità. Può esse-re fornita anche la compressione.

2) SSH Connection Protocol. Permette ai nodi client di ne-goziare canali aggiuntivi per convogliare (multiplex) di-versi flussi (stream) di pacchetti da più applicazioni at-traverso il tunnel SSH originario. I diversi flussi vengonomescolati secondo un preciso metodo al fine di convo-gliarli tutti attraverso il medesimo tunnel e quindi sepa-rarli di nuovo (de-multiplex) all’uscita dal tunnel. Di-sporre il Connection Protocol sopra il Transport LayerProtocol riduce anche il carico di elaborazione, perchél’utente non è costretto a impostare una nuova connes-sione per ogni applicazione.

3) SSH Authentication Protocol. Il processo di autentica-zione è separato dal Transport Layer Protocol, perchénon sempre è necessario autenticare l’utente. Quando èrichiesta l’autenticazione, il processo viene protettodalla connessione sicura originaria stabilita dal Tran-sport Layer Protocol.Come abbiamo visto, l’instaurazione del collegamento e

l’autenticazione costituiscono una procedura complessa,ma, salvo per la richiesta della passphrase, si tratta di una

www.pcopen.it41


procedura automatica e pressoché istantanea. Il meccani-smo di SSH è molto sicuro a patto di utilizzarlo corretta-mente.

Vediamo alcuni potenziali rischi.1) L’utilizzo di un cifrario simmetrico debole per cifrare i

dati. Per esempio, DES (supportato da SSH-1, ma nonSSH-2) va evitato perché facilmente violabile; si possonousare 3DES, AES e altri algoritmi forti.

2) Utilizzo di nome utente e password. Non dovrebbe es-sere usato perché offre un’autenticazione meno sicura ri-spetto all’uso delle chiavi asimmetriche, anche nel casodi password scelte oculatamente.Vediamo alcuni punti deboli delle implementazioni. Il

principale limite alla sicurezza è posto talvolta dalla scel-ta del software e dalla sua versione. E’ consigliabileconsultare i report di sicurezza (advisories) diwww.cert.org per conoscere i punti deboli delleimplementazioni di SSH per le varie piattaforme (per unadescrizione delle funzioni di CERT, Computer EmergencyResponse Team, vedi la sezione 5.1.3.5 della primalezione: “CERT, CSIRT e la gestione degli incidenti”,pubblicata come capitolo 11 nel corso multimediale suCD). Per esempio, l’advisory www.cert.org/advisories/CA-2002-36.html elenca numerose implementazioni di SSH ene riporta gli eventuali punti deboli. In generale, è preferi-bile utilizzare la versione 2 di SSH, a meno che non visiano validi motivi per scegliere la prima versione. In ognicaso, oggi esistono diversi prodotti SSH-2 per diversepiattaforme, incluso Palm OS (vedi www.tussh.com/ www.palmgear.com/index.cfm?fuseaction=software.show-software&PartnerREF=&siteid=1&prodid=72847&siteid=1www.sealiesoftware.com/pssh http://staff.deltatee.com/ ~angusa/TuSSH_old.html).

Finora abbiamo menzionato il funzionamento di ssh, ilclient SSH per il login remoto. Altri esempi di client SSH so-no scp per il trasferimento sicuro dei file, sftp per la con-nessione sicura FTP e ssh-agent, un agente che permettel’autenticazione sicura con parecchi computer in rete sen-za bisogno di ricordare tutte le passphrase. Il daemon sshdviene invece utilizzato per restare in ascolto in attesa del-le chiamate dai client SSH.

Installare un prodotto che gestisce il protocollo SSH

SSH è solitamente supportato dalle moderne distribu-zioni Linux (in versione OpenSSH) attraverso applicazionicome ssh, scp, ssh-keygen, sshd e sftp. Anche MAC OS X èdotato di SSH (1.5 e 2.0). OpenSSH è disponibile per vari si-stemi operativi, incluso Windows. Per Palm OS esistonoTop Gun SSH (solo SSH-1) e TuSSH (SSH-1 e SSH-2). Per Win-dows esistono diverse versioni, elencate in www.opens-sh.com/windows.htm; tra queste, una delle più note èPuTTY, un client Telnet, Rlogin e SSH per il login remoto. E’concesso in licenza gratuita dall’MIT ed è facile da usare,anche se meno sicuro della versione OpenSSH(http://sshwindows.sourceforge.net/); sia PuTTY siaOpenSSH for Windows supportano le due versioni di SSH.

I computer che agiscono da server devono avere instal-lata anche un’applicazione SSH server, il che è frequente,ma non sempre accade (per esempio PuTTY è solo client).In Linux e Mac OS X, SSH è implementato anche come ser-ver; per Windows esistono versioni server (sshd) com-merciali come WinSSHD (http://www.bitvise.com/wins-shd.html).

Alcune applicazioni SSH, vedi OpenSSH, sono del tiposoftware libero, distribuite anche come sorgenti. Normal-mente ci si limita a scaricare i file eseguibili per la piat-taforma desiderata (per esempio Win32 su hardware x86).Se occorre, bisogna espandere i file compressi, per esem-pio con tar (formati tar e tgz), rpmI (formato rpm), dpkg(formato debian) o Winzip (formato zip).

Installato, se occorre, il software SSH, sarà bene utiliz-

zare quando possibile la versione 2 e comunque evitare diutilizzare DES se si usa la versione 1. In OpenSSH si posso-no modificare le impostazioni SSH a livello di sistema nei fi-le /etc/ssh/ssh_config e /etc/ssh/sshd_config.

Quanto all’autenticazione, è senz’altro preferibile utiliz-zare le chiavi asimmetriche. Basta generare le chiavi conl’apposita utility (come ssh-keygen) e copiare le chiavi pub-bliche sul server come specificato per la versione di SSHutilizzata (vedi l’esempio in Linux più avanti).

In Linux, i parametri Cipher e Ciphers in ssh_config han-no i seguenti valori di default:Cipher 3desCiphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

Il parametro PasswordAuthentication vale solo per i ser-ver ed è preferibile sia impostato a no.

Il parametro PermitRootLogin, per i server, permette dicollegarsi come root; si consiglia yes qualora le passwordnon fossero abilitate, altrimenti si consiglia il valorewithout-password, in modo da forzare l’uso delle chiavi perl’autenticazione.

Creare una chiave con un pacchetto compatibile SSH

Nella maggior parte dei casi, la generazione delle chiaviè assai semplice, come si vede in questo esempio di dialo-go in Linux, dove è richiesta la generazione di chiavi DSA el’uso della versione 2 di SSH.

La passphrase può essere omessa, ma il suo uso è con-sigliato per proteggere la chiave privata, che deve restaresegreta.

gobbi@linux:~> ssh-keygen -t dsaGenerating public/private dsa key pair.Enter file in which to save the key

(/home/gobbi/.ssh/id_dsa):Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in

/home/gobbi/.ssh/id_dsa.Your public key has been saved in

/home/gobbi/.ssh/id_dsa.pub.The key fingerprint is:bc:ed:44:26:7a:29:66:1b:5f:6a:d3:15:cb:ef:b6:6d

gobbi@linux

Le versioni di OpenSSH permettono di operare come se-gue.

Nelle versioni non recenti di SSH ci si può limitare a usa-re ssh-keygen per generare una coppia di chiavi RSA. Nelleversioni recenti si può scegliere fra tre modalità:1) ssh-keygen -t rsa1 per chiavi RSA con versione 1 di SSH2) ssh-keygen -t rsa per chiavi RSA con versione 2 di SSH3) ssh-keygen -t dsa per chiavi DSA con versione 2 di SSH

Vengono chieste due informazioni: il nome del file dovesi vuole memorizzare la chiave privata (la chiave pubblicaviene salvata in un file con lo stesso nome e suffisso .pub)e la passphrase di sblocco della chiave privata.

Se, per generare le chiavi, si usa PuTTY in Windows, ba-sta eseguire Puttygen.exe e specificare in basso una delletre opzioni, equivalenti a quelle viste per OpenSSH; si con-siglia di usare una delle due previste per SSH-2. Si può mo-dificare la lunghezza della chiave, ma il default di 1.024 èadeguato.

Dopo il clic su Generate, viene chiesto di muovere ilmouse sopra la finestra del programma, in modo da gene-rare eventi casuali che aiutano a produrre valori casuali.Dopo la generazione, si scrive la passphrase per protegge-re la chiave privata. Le chiavi pubblica e privata sono sal-vate separatamente ed è preferibile che abbiano lo stessonome (viene aggiunto .ppk a quella pubblica).

www.pcopen.it42

5.2.7.6 Essere ingrado d'installare econfigurare unprodotto softwareche gestisca ilprotocollo SSH


Inserire chiavi su un server per autenticarne i proprietari

Nell’autenticazione con chiavi, il server deve conoscerele chiavi pubbliche dei client che si collegano. Ciò avvienecopiando le chiavi pubbliche in una data posizione del ser-ver. Nel caso di un utente che utilizza OpenSSH su un si-stema Linux o Mac OS X, si procede come segue.1) Si decide quale identificativo di utente (user-id) va as-

sociato al client. 2) Ci si sposta nella sua home directory (per esempio /ho-

me/gobbi). 3) Ci si sposta nella sottostante cartella .ssh. 4) Si crea il file authorized_keys se si usa la versione 1 o

authorized_keys2 se si usa la versione 2 (per esempiotouch authorized_keys2); si limitano gli accessi con ch-mod 600 authorized_keys2.

5) Si copia la chiave pubblica del client remoto in authori-zed_keys2; per esempio, se si è trasferita la chiave su unfloppy che poi è stato montato in /mnt sul server e la di-rectory corrente è /home/gobbi/.ssh, si può usare cat/mnt/id_dsa.pub >> authorized_keys2.

6) Altrimenti si può trasferire la chiave al server remotocon un comando del tipo scp id_dsa.pub [email protected]:./id_dsa.pub, che esegue una copia si-cura del file dalla directory .ssh del client alla home di-rectory sul server.Nell’uso di SSH è particolarmente utile l’opzione -v (ver-

bose) per vedere ciò che accade a ogni passo. La connes-sione SSH (versione 2) dell’utente gobbi (su Linux SuSE) alcomputer con indirizzo 192.168.0.190 (con Linux Fedora),autenticata con chiavi DSA, ha il seguente aspetto. Dopo loscambio d’informazioni e di chiavi, la scelta dei protocollie l’autenticazione con chiavi asimmetriche, inizia la ses-sione interattiva. In assenza dell’autenticazione con chiavi,verrebbe chiesta la password di Gobbi sul server.

gobbi@linux:~/.ssh> ssh -2 -v [email protected]_3.9p1, OpenSSL 0.9.7d 17 Mar 2004debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Connecting to 192.168.0.190 [192.168.0.190]

port 22.debug1: Connection established.debug1: identity file /home/gobbi/.ssh/id_rsa type 1debug1: identity file /home/gobbi/.ssh/id_dsa type 2debug1: Remote protocol version 1.99, remote software

version OpenSSH_3.9p1debug1: match: OpenSSH_3.9p1 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_3.9p1

debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST

(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host '192.168.0.190' is known and matches the

RSA host key.debug1: Found key in /home/gobbi/.ssh/known_hosts:1debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue:

publickey,gssapi-with-mic,passworddebug1: Next authentication method: publickeydebug1: Offering public key: /home/gobbi/.ssh/id_rsadebug1: Authentications that can continue:

publickey,gssapi-with-mic,passworddebug1: Offering public key: /home/gobbi/.ssh/id_dsadebug1: Server accepts key: pkalg ssh-dss blen 433debug1: read PEM private key done: type DSAdebug1: Authentication succeeded (publickey).debug1: channel 0: new [client-session]debug1: Entering interactive session.Last login: Thu Apr 7 15:51:48 2005[gobbi@host ~]$

Secure/Multipurpose Internet Mail Extensions - S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions)è un protocollo che aggiunge la cifratura e la firma elettro-nica ai messaggi MIME descritti nella RFC 1521 (Mechani-sms for Specifying and Describing the Format of InternetMessage Bodies). MIME è lo standard che specifica comedevono essere trasferiti i dati multimediali e gli allegati die-mail. I messaggi di posta su Internet consistono di dueparti, l’intestazione e il corpo. L’intestazione raccoglie unaserie di coppie campo/valore che forniscono informazioniessenziali per la trasmissione del messaggio, secondo lastruttura specificata nella RFC 822. Il corpo di solito non èstrutturato a meno che il messaggio sia in formato MIME.MIME definisce la struttura del corpo del messaggio in mo-do da permettere d’includere testo con attributi, grafica,audio e altri contenuti in modo standardizzato. MIME nonfornisce alcun servizio di sicurezza. Lo scopo di S/MIME èquindi definire tali servizi secondo la sintassi definita dalformato PKCS #7 (citato in precedenza) per la firma e la ci-fratura. S/MIME estende lo standard MIME e permette la ci-fratura del messaggio e degli allegati. Gli algoritmi di cifra-tura e hash possono essere specificati dall’utente nelle im-postazioni del programma di posta, come visto nel capito-lo 5.2.2.1 (Principi di crittografia simmetrica). S/MIME ga-rantisce la riservatezza mediante l’algoritmo di cifratura,l’integrità mediante l’algoritmo di hash, l’autenticazionemediante l’uso di un certificato a chiave pubblica X.509 e ilnon ripudio mediante la firma digitale.

S/MIME è stato sviluppato in origine da RSA; in seguitoè passato all’IETF. La sua standardizzazione è oggetto del-l’S/MIME Working Group dell’IETF (vedi www.imc.org/ietf-smime/index.html per l’elenco dei documenti disponibili).

Ecco alcune caratteristiche di S/MIME.1) Formato del messaggio: binario, basato su CMS (vedi

PKCS #7)2) Formato del certificato: binario, basato su X.5093) Algoritmo simmetrico: TripleDES (DES EDE3 CBC)

www.pcopen.it43

5.2.7.7 Conoscere iprincipi difunzionamento diS/MIME.


4) Algoritmo di firma: Diffie-Hellman (X9.42) con DSS5) Algoritmo hash: SHA-1

Un modo per proteggere la posta elettronica con S/MI-ME consiste nel procurarsi un certificato personale per e-mail da Thawte (www.thawte.com/email/ ), che lo forniscegratuitamente, rinnovabile di anno in anno.

S/MIME è supportato da vari client e-mail: Outlook e Ou-tlook Express di Microsoft, Netscape Messenger 7.x, Mo-zilla Mail, Mail in Mac OS X e altri, ma non da Eudora (peril quale esistono plug-in in ambiente Windows).

Secure Sockets Layer - SSLSecure Sockets Layer (SSL) è un protocollo per la pro-

tezione di un canale di comunicazione attraverso una retee funziona allo strato di trasporto, tra i protocolli di tra-sporto e di applicazione. Come altri protocolli di sicurezzadi rete, SSL utilizza la crittografia simmetrica e asimmetri-ca e le funzioni di hash per fornire l’autenticazione del ser-ver (e in opzione anche del client), la cifratura dei messag-gi e l’integrità dei dati. Quando un client (tipicamente unbrowser) accede a un sito web, è possibile che trovi unaparte delle pagine protette, come accade nei siti che sup-portano transazioni bancarie o commerciali e la raccolta diinformazioni personali tramite moduli da compilare (form).

Quando il client passa da una pagina pubblica a una pa-gina sicura, il web server invoca SSL per proteggere la co-municazione (l’utente se ne accorge perché l’URL della pa-gina è preceduto da https - cioè HTTP over SSL - anzichéhttp) inoltre compare solitamente un’icona nella finestradel browser che segnala la presenza di una connessioneprotetta. Nel caso di Internet Explorer in Windows, adesempio, l’icona ha la forma di un piccolo lucchetto dora-to che compare in basso a destra. Il server risponde alclient indicando che dev’essere stabilita una sessione si-cura e il client invia i propri parametri di sicurezza. Nellaprima fase, opera l’Handshake Protocol, il primo dei trecomponenti di SSL. In tale fase client e server negoziano iparametri crittografici da usare: versione del protocollo,identificativo di sessione, selezione degli algoritmi critto-grafici e del metodo di compressione, generazione di nu-meri casuali iniziali, autenticazione del server (solitamen-

te con un certificato), eventuale autenticazione del client(rara benché possibile), accordo finale sulla suite di cifra-ri da usare.

Nella fase di handshake, il client si connette al server, in-via una serie di dati (versione supportata, un numero ca-suale che sarà usato per lo scambio delle chiavi, un ID disessione, la lista degli algoritmi supportati e il metodo dicompressione) e attende risposta.

Il server risponde con un messaggio analogo, con nu-mero di versione, altri dati casuali, lo stesso ID di sessionee gli algoritmi scelti dal server per lo scambio delle chiavi(RSA, Diffie-Hellmann e altri), la cifratura simmetrica, l’ha-sh e la compressione.

Il server dimostra la propria identità inviando al client ilsuo certificato digitale; tale scambio può includere, in op-zione, l’intera catena di certificati fino al certificato root (ra-dice) della Certification Authority (CA). Se richiesto dal me-todo di scambio chiavi adottato, il server invia al client unmessaggio di scambio chiavi contenente materiale per lagenerazione della chiave simmetrica.

Il server può quindi iniziare a richiedere l’autenticazio-ne del client con un certificato, ma nella maggior parte deicasi ciò non accade.

Il client verifica il certificato o i certificati del server inbase alle date di validità e controlla la presenza della firmadi una CA fidata.

Il client invia un messaggio di scambio chiavi il cui con-tenuto dipende dall’algoritmo usato.

Il server verifica il certificato del client, se presente.Il client e il server generano la chiave di sessione utiliz-

zando i dati che si sono scambiati nei messaggi preceden-ti.

Il secondo componente di SSL è il Record Protocol, usa-to per lo scambio di dati tra le applicazioni dopo aver crea-to il canale sicuro di comunicazione. I messaggi sono fram-mentati in blocchi facili da gestire e opzionalmente vengo-no compressi; si applica un MAC (codice di autenticazionedel messaggio) e il risultato viene cifrato e trasmesso. Il ri-cevente decifra i dati, verifica il MAC, decomprime e rias-sembla il messaggio e fornisce il risultato al protocollo ap-plicativo.

www.pcopen.it44

5.2.7.8 Conoscere iprincipi difunzionamento diSSL


Il terzo componente, l’Alert Protocol, è usato per indi-care il verificarsi di un errore o la terminazione di una ses-sione tra due host.

L’uso di SSL richiede un server con capacità SSL; i brow-ser includono generalmente il supporto SSL 2.0 e 3.0. In pre-cedenza abbiamo messo a confronto la protezione a livel-lo di collegamento con la protezione (superiore) a livello diapplicazione. SSL, collocato allo strato di trasporto (doveopera il protocollo di rete TCP, per intenderci), fornisce lasicurezza della connessione, ma non la sicurezza dei datiuna volta ricevuti e decifrati. L’utente di una connessioneSSL può contare su una comunicazione protetta, ma deveavere fiducia nell’istituzione a cui trasmette i dati per la si-curezza con cui essi saranno trattati e conservati.

Una variante rispetto all’SSL versione 3 di uso correnteè il protocollo TLS (Transport Layer Security) definito dal-l’IETF nella RFC 2246, simile a SSL, ma con differenze so-prattutto negli algoritmi crittografici utilizzati. TLS è già im-plementato e si può prevedere una sua graduale adozione.

5.2.7.9 Uso delle smartcardLe smartcard, piccole schede di plastica che includono

capacità logiche e memoria, sono utilizzate per memoriz-zare in modo sicuro le chiavi private usate per la firma di-gitale e per la decifratura. In tal modo si evita di conser-varle o dimenticarle sul computer, ossia in un ambiente po-co sicuro.

In sintesi, una smartcard oggi è costituita da un micro-processore dotato di una certa quantità di RAM e da unamemoria EEPROM (Electrically Erasable ProgrammableRead-Only Memory) che alloggia il software di gestione e lechiavi e il cui contenuto non si cancella col tempo, ma puòessere modificato mediante apposite apparecchiature. Lasmartcard dialoga con il mondo esterno attraverso un’in-terfaccia seriale (secondo la disposizione a otto contatti

dello standard ISO7816 Part 1) o senza contatti, medianteun’interfaccia radio.

Il programma residente sulla scheda riconosce i co-mandi che arrivano dall’esterno e risponde di conseguen-za. Fondamentalmente, i comandi inviati a una smartcardsono del tipo seguente:1) richiesta di generazione di chiavi2) richiesta della chiave pubblica3) richiesta di cifrare un blocco di dati con la chiave privata4) richiesta di memorizzazione del certificato della CA che

ha emesso il certificato dell’utente in base alla chiavepubblica estratta dalla smartcard.Una trattazione dettagliata può essere trovata su Smart

Card Handbook, Secon Edition di Rankl ed Effing.Le smartcard possono generare, su richiesta, coppie di

chiavi (pubblica e privata); non c’è modo di estrarre lachiave privata dalla scheda, mentre la chiave pubblica è di-sponibile per l’uso nei sistemi PKI. La custodia sicura del-la chiave privata permette di usare le smartcard per firmedigitali con validità legale e garanzia di non ripudio.

A causa della capacità limitata del processore e dellamemoria di una smartcard, le operazioni di generazione dichiavi e di cifratura sono piuttosto lente, ma ciò non è gra-ve se si considera che le chiavi sono generate non più diuna volta l’anno e che le operazioni avvengono su hash dilunghezza ridotta.

L’accesso alle smartcard (come ad altri dispositivi crit-tografici) avviene mediante un’API (interfaccia program-matica) definita dallo standard PKCS #11 (CryptographicToken Interface Standard, detto Cryptoki). L’interfacciastandard permette di sviluppare software indipendentedalla smartcard utilizzata.

Un esempio di smartcard ad uso dei cittadini è la cartadei servizi della Regione Lombardia (vedi www.crs.lom-bardia.it/). �

www.pcopen.it45

5.2.7.9 Essereconsapevoli dell’usodelle smartcard

Firma elettronica e certificati digitali per le operazioni ... · corso multimediale completo su CD...

Documents

Transcript of Firma elettronica e certificati digitali per le operazioni ... · corso multimediale completo su CD...