Blog di Gianni Barrotta

Vpn

Molte aziende hanno uffici e stabilimenti situati in diverse città, a volte anche in diversi stati. Prima che esistessero le reti pubbliche per i dati, le aziende affittavano dalla compagnia telefonica le linee per collegare fra loro alcune o tutte le loro sedi. Alcune aziende lo fanno ancora. Una rete costruita con i computer aziendali e le linee telefoniche affittate è detta rete privata. Un esempio di rete privata che connette tre siti è mostrata nella figura seguente.

Vpn

Le reti private funzionano bene e sono molto sicure. Quando le uniche linee presenti sono affittate non è possibile che il traffico di rete possa fuoriuscire dall’azienda, salvo che un intruso riesca a intercettare fisicamente le comunicazioni, il che non è affatto facile. Il problema delle reti private è dato dal loro costo. Infatti, affittare una singola linea T1 può costare migliaia di dollari al mese, affittare una T3 molto di più. Quando arrivarono sulla scena le reti pubbliche per i dati e successivamente Internet, molte aziende vollero spostare il loro traffico dati (e se possibile anche vocale) sulle reti pubbliche, ma senza abbandonare la sicurezza delle linee private. Questa domanda portò in breve tempo all’invenzione delle VPN (Virtual Private Network). Le VPN permettono di sovrapporre delle reti sopra le reti pubbliche, ma senza abbandonare le proprietà di sicurezza tipiche delle reti private. Sono chiamate “virtuali” perché sono una mera illusione, così come i circuiti virtuali non sono veri circuiti e la memoria virtuale non è vera memoria. Le VPN possono essere costruite sopra le reti ATM (o frame relay), ma un approccio che diventa sempre più comune consiste nel costruire le VPN direttamente sopra Internet. Una tipica architettura consiste nell’avere un firewall per ogni ufficio e creare dei tunnel attraverso Internet fra tutte le coppie di uffici, come mostrato nella figura precedente. Se viene usato l’IPsec per il tunneling, è possibile aggregare tutto il traffico fra ogni possibile coppia di uffici in una singola SA con autenticazione e cifratura. Questo fornisce controllo dell’integrità, segretezza e anche una considerevole immunità all’analisi del traffico. Ogni coppia di firewall deve negoziare allo startup i parametri della sua SA: i servizi, le modalità, gli algoritmi e le chiavi. Molti firewall sono progettati per gestire le VPN, e ciò vale anche per alcuni normali router. Visto che i firewall sono impiegati principalmente nell’ambito della sicurezza, è naturale che i tunnel delle VPN comincino e finiscano su dei firewall. In questo modo si realizza una chiara separazione fra Internet e l’azienda. Firewall, VPN e IPsec su ESP in modalità tunnel costituiscono una combinazione naturale e molto usata nella pratica. Il traffico comincia a scorrere dopo che sono state stabilite le SA. Per un router su Internet, un pacchetto che viaggia attraverso un tunnel VPN non è altro che un normale pacchetto. L’unica cosa strana è la presenza di un’intestazione IPsec dopo la normale intestazione dell’IP. Visto che le intestazioni extra non hanno effetto sulla procedura di forwarding dei pacchetti, i router semplicemente le ignorano. Impostare le VPN in questo modo presenta il vantaggio fondamentale della completa trasparenza delle operazioni nei confronti degli utenti e del loro software. I firewall impostano e gestiscono le SA. L’unica persona che è al corrente di queste impostazioni è l’amministratore di sistema che deve configurare e gestire i firewall. Per tutti gli altri utenti, è come se ci fosse una rete privata su linea dedicata.

febbraio 10, 2008 Posted by | Sicurezza | Lascia un commento

Ipsec

Affinché dei calcolatori connessi in rete possano reciprocamente scambiarsi informazioni è necessario che gli stessi adottino lo stesso protocollo di comunicazione, che è oramai parte integrante di ogni sistema operativo. Il protocollo di comunicazione (in realtà sono più protocolli) utilizzato dai calcolatori di Internet è noto come TCP/IP (Transmission Control Protocol / Internet Protocol) ed è costituito da diversi protocolli fra cui UDP (User Datagram Protocol) + TCP + IP.
Per consentire la comunicazione tra due calcolatori il TCP/IP stabilisce un “canale” di comunicazione tra il calcolatore del mittente e quello del destinatario. Questo canale attraversa solitamente un numero imprecisato di altri calcolatori, che svolgono le funzioni di “smistatori” (router), il cui compito è quello di indirizzare le informazioni in transito verso il destinatario. La trasmissione di informazioni in Internet è analoga alla trasmissione di una lettera. Per prima cosa la corrispondenza raggiunge l’ufficio postale più vicino al mittente (smistatore di primo livello); questo provvede ad inviare la corrispondenza ad un ufficio centrale, che successivamente la rinvia ad uno o più smistatori intermedi, finché la corrispondenza non arriva all’ufficio postale più vicino al destinatario, dal quale un postino provvede alla consegna. Elemento peculiare del protocollo è che la trasmissione delle informazioni non deve necessariamente seguire sempre la stessa strada, anzi è probabile che due pacchetti dati raggiungano la destinazione seguendo strade diverse. Esistono quindi molti punti in cui l’informazione trasmessa può essere intercettata, letta ed eventualmente modificata. Questa operazione è facilitata dal fatto che le informazioni nell’ambito del protocollo TCP/IP viaggiano in chiaro. Questo rischio può comunque essere evitato operando opportune trasformazioni crittografiche sulle informazioni che devono essere trasmesse. Tali trasformazioni operano una serie di modifiche sul messaggio sino a renderlo illeggibile. Solo il destinatario del messaggio potrà risalire al contenuto originale del messaggio attraverso un’opportuna chiave. IPsec (IP Security) implementa la sicurezza attraverso la cifratura e l’autenticazione dei pacchetti IP. La sicurezza viene quindi fornita a livello rete.
IPsec nasce su iniziativa della Internet Engineering Task Force (IETF) e quindi come Internet Standard. Il progetto completo dell’IPsec definisce un’infrastruttura per fornire molteplici servizi, algoritmi e granularità. La ragione per avere molteplici servizi è che non tutti vogliono pagare il prezzo per avere tutti i servizi disponibili in ogni istante, quindi alcuni servizi vengono resi disponibili su richiesta. IPSEC consente di operare sui messaggi in uscita da un host, le seguenti operazioni:
1. Cifratura dei dati contenuti nei messaggi con appositi algoritmi di crittografia, al fine di consentire la lettura del contenuto originale del messaggio al solo destinatario del messaggio;
2. Autenticazione del mittente: al messaggio vengono aggiunte alcune informazioni supplementari che consentono di verificare l’esatta identità del mittente;
3. Integrità dei dati: al messaggio vengono aggiunte alcune informazioni supplementari che consentono di verificare in fase di ricezione se il contenuto del messaggio rispecchia il contenuto originale oppure se è stato modificato in fase di trasmissione [2].
Tutti questi servizi sono basati sulla crittografia a chiave simmetrica, in quanto le performance sono cruciali. La ragione per avere più algoritmi è data dal fatto che un algoritmo che oggi crediamo sicuro potrebbe essere forzato in futuro. Rendendo l’IPsec indipendente dall’algoritmo, l’infrastruttura può sopravvivere anche se un particolare algoritmo viene forzato. Prevedendo diverse granularità, infine, è possibile proteggere una singola connessione TCP, come tutto il traffico fra due host, oppure il traffico fra due router sicuri, o altre possibilità. Una “connessione” nel contesto deli’IPsec è chiamata SA (Security Association). Una SA è una connessione simplex fra due estremi e ha un identificatore di sicurezza associato. Se è necessario stabilire un traffico sicuro nelle due direzioni, saranno necessarie due SA. Gli identificatori di sicurezza sono trasportati da pacchetti che viaggiano su queste connessioni sicure, e vengono usati (all’anivo dei pacchetti sicuri) per la ricerca delle chiavi e di altre informazioni rilevanti.
Le specifiche tecniche di IPsec contengono due parti principali. La prima parte descrive due nuove intestazioni che possono essere aggiunte ai pacchetti per contenere l’identificatore di sicurezza, i dati di controllo dell’integrità e altre informazioni. L’altra parte, ISAKMP (Intemer Securily Association and Key Management Protocol) concerne lo scambio delle chiavi.
Non tratteremo ulteriormente ISAKMP, in quanto (1) è estremamente complesso, (2) il suo protocollo principale, IKE (Internet Key Exchange), contiene degli errori molto gravi e quindi probabilmente sarà essere rimpiazzato.
IPsec può essere utilizzato in una modalità scelta fra le due possibili. Nella modalità trasporto l’intestazione IPsec viene inserita subito dopo quella dell’IP. Il campo Protocol nell’intestazione IP è cambiato in modo da indicare che un’intestazione IPsec segue quella solita dell’IP (prima dell’intestazione TCP). L’intestazione IPsec contiene le informazioni di sicurezza: principalmente l’identificatore SA, un nuovo numero di sequenza, ed eventualmente un controllo d’integrità del campo payload. Nella modalità tunnel l’intero pacchetto IP. intestazione compresa, viene incapsulato nel corpo di un nuovo pacchetto IP con un’intestazione IP completamente diversa La modalità tunnel è utile quando il tunnel aniva in un posto diverso dalla sua destinazione finale. In alcune situazioni, il tunnel arriva a una macchina con un gateway sicuro, per esempio il firewall dell’azienda. Operando in questo modo, il firewall incapsula e decapsula i pacchetti che lo attraversano. Facendo terminare il tunnel su questa macchina sicura, le machine sulla LAN dell’azienda non devono essere a conoscenza dell’IPsec. Solo il firewall sarà a conoscenza del tunnel IPsec.
La modalità tunnel è utile anche nella situazione in cui si vuole aggregare un’insieme di connessioni TCP, per poi gestirle come un unico flusso cifrato. In questo modo si evita che un intruso possa avere informazioni sul traffico: per esempio chi sta mandando dei pacchetti, a chi li sta mandando e quanti ne sta inviando. Consideriamo il caso in cui, durante una crisi militare, il traffico fra il Pentagono e la Casa Bianca diminuisca di colpo. Simultaneamente, il traffico fra il Pentagono e alcune installazioni militari nelle Montagne Rocciose aumenta della stessa quantità di cui il primo è diminuito. Un intruso potrebbe trarre delle informazioni utili da questi dati. Lo studio della distribuzione del flusso dei pacchetti, anche se cifrati, è chiamato analisi del traffico. La modalità tunnel fornisce un modo per aggirare parzialmente questo tipo di analisi. Lo svantaggio della modalità tunnel è dato dal fatto che aggiunge delle ulteriori intestazioni IP ai pacchetti e quindi aumenta la dimensione del pacchetto in modo sostanziale.
Al contrario, la modalità trasporto non cambia di molto la grandezza del pacchetto. La prima ulteriore intestazione è detta AH (Authentication Header). AH garantisce il controllo dell’integrità e la sicurezza contro gli attacchi di ricezione, ma non la segretezza (cioè non ha cifratura). L’uso di AH nella modalità trasporto è illustrato nella figura seguente.
Nell’IPv.4, AH viene messo fra l’intestazione IP (incluse le eventuali opzioni) e l’intestazione TCP. Nelll’IPv6, AH è gestito come un’altra estensione dell’intestazione e trattata di conseguenza. in effetti, il suo formato è simile a quello di un’estensione standard dell’intestazione IPv6. Il campo payload può essere riempito fino a raggiungere una particolare lunghezza per facilitare l’algoritmo di autenticazione, come mostrato.

Header IPSEC

Header di autenticazione IPsec nella modalità trasporto per IPv4

Nell’intestazione AH, il campo Next header field serve per memorizzare il valore originale che aveva il campo IP Protocol prima di essere rimpiazzato con il valore 51. Quest’ultimo è usato per indicare che segue un’intestazione AH. Nella maggior parte dei casi, il valore sarà il codice per il TCP (6). IL campo Payload length contiene il numero di word a 32 bit nell’intestazione AH meno 2. il Security parameter index è l’identificatore della connessione. Viene inserito dal mittente per indicare un particolare record nel database del ricevente. Questo record contiene la chiave condivisa usata per questa connessione e altre informazioni sempre relative alla connessione. Il campo Sequence number viene usato per attribuire un numero a tutti i pacchetti inviati in un SA. A ogni pacchetto viene attribuito un numero univoco, incluse le ritrasmissioni.
In altre parole, un pacchetto ritrasmesso prende un numero di sequenza diverso dall’originale (anche se il suo numero di sequenza TCP è lo stesso). Lo scopo di questo campo è quello di evitare attacchi di tipo ripetizione. Questi numeri di sequenza non sono riutilizzati in circolo: se vengono usate tutte le 232 possibili combinazioni, dovrà essere stabilito un nuovo SA per poter continuare la comunicazione.
Infine abbiamo Authentication data, che è un campo a lunghezza variabile che contiene la firma digitale del payload. L’algoritmo di firma elettronica da utilizzare è negoziato quando viene stabilito l’SA. Di solito in questo stadio non viene usata la crittografia a chiave pubblica, perché i pacchetti devono essere elaborati in modo estremamente rapido, mentre tutti gli algoritmi a chiave pubblica conosciuti sono troppo lenti per questo compito. Per questo motivo IPsec è basato sulla crittografia a chiave simmatrica. II mittente e il destinatario stabiliscono una chiave comune prima d’instaurare la SA, che viene usata nel calcolo della firma. Un metodo semplice consiste nel calcolare l’hash sui contenuti del pacchetto e della chiave insieme. Ovviamente, la chiave condivisa non viene trasmessa. Uno schema di questo tipo è chiamato HMAC (Hashed Message Authentication Code). È molto più veloce da calcolare della strategia alternativa, che consiste nell’usare prima SHA-1 per poi passare elaborare il risultato con RSA.
L’intestazione AH non permette la cifratura dei dati, quindi è utile principalmente quando è necessario un controllo d’integrità ma non serve la sicurezza. Una funzione importante di AH è data dal fatto che il controllo d’integrità copre alcuni campi dell’intestazione P, in particolare quelli che non cambiano mentre il pacchetto viene trasmesso da router a router. Per esempio, il campo time to live cambia in ogni salto di router e quindi non può essere incluso nel controllo d’integrità. L’indirizzo IP della sorgente viene incluso nel controllo, in questo modo diventa impossibile per un intruso falsificare l’origine del pacchetto.
L’intestazione IPsec alternativa è ESP (Encapsulating Security Payload). Il suo uso, sia per la modalità trasporto sia per quella tunnel, viene mostrato nella figura seguente.

ESP

(a) ESP in modalità trasposto. (b) ESP in modalità tunnel

L’intestazione ESP consiste di due word a 32 bit, che costituiscono i campi security parameters index e sequence number, con funzioni analoghe a quanto abbiamo discusso per AH. Una terza word che di solito segue le prime due (ma che tecnicamente non è parte dell’intestazione) è initialization vector, usato per la cifratura dei dati. Se non viene usata la cifratura, questo campo è omesso.
ESP fornisce un controllo d’intregrità HMAC come AH, ma diversamente da quest’ultimo non lo include nell’intestazione; lo aggiunge invece in coda ai campo payload, come mostrato nella figura precedente. Utilizzare HMAC in coda al payload comporta dei vantaggi nelle implementazioni hardware. in questo caso, HMAC può essere calcolato mentre i bit sono trasmessi verso l’interfaccia di rete, e poi aggiunto alla fine: per lo stesso motivo Ethemet e altre LAN hanno il CRC dopo la fine dei dati, piuttosto che all’inizio. Con AH, invece, il pacchetto va messo in un buffer e la firma calcolata prima di poterlo trasmettere, pertanto questo modo di operare può avere l’effetto di ridurre il numero di pacchetti/sec che possono essere trasmessi.
ESP riesce a fare tutto quello che AH può fare, ha anche delle funzioni aggiuntive ed è più efficiente. La domanda a questo punto e: perché interessarsi ad AH? La risposta ha origini soprattutto storiche: in origine AH si occupava solo d’integrità e ESP solo di segretezza. Successivamente, l’integrità è stata aggiunta a ESP. A questo punto, però, le persone che avevano progettato AH non volevano vederlo morire dopo tutto il lavoro che avevano fatto. Il loro unico punto a favore è che AH controlla parte dell’intestazione IP, mentre ESP non lo fa, ma questo è un argomento debole. Un’altra giustificazione debole è che un prodotto che supporti AH ma non ESP potrebbe avere minori problemi a ottenere una licenza per l’export in quanto non presenta funzioni di cifratura. AH verrà probabilmente eliminato in un prossimo futuro [2].
Il punto di forza di IPSEC è quello di consentire l’esecuzione di tutte queste operazioni in maniera del tutto trasparente rispetto agli utenti e alle applicazioni. Questo significa che è sufficiente installare IPSEC su un host affinché lo stesso possa incominciare a cifrare/autenticare il traffico di rete generato. Nessuna modifica deve essere apportata alle applicazioni o ai servizi che operano sul calcolatore. Un altro aspetto importante è che IPSEC può operare indifferentemente sul traffico di rete generato da una qualunque applicazione senza distinzione alcuna.
I punti di debolezza del protocollo IPSEC possono invece essere così riassunti:
1. E’ uno standard giovane (la sua ultima formulazione risale al 1998) e quindi a oggi è implementato solo su alcune piattaforme (calcolatori e apparati di rete);
2. Le implementazioni dei vari fornitori non sono ancora del tutto compatibili quindi un messaggio IPSEC generato da un host A può non essere riconosciuto da un router o da un altro host B.

Tutto ciò induce ad una accurata valutazione per l’utilizzo di IPSEC su larga scala.
Un ultimo elemento da considerare nell’adozione di tale protocollo è il suo impatto sulle prestazioni del server. IPSEC infatti può appesantire notevolmente l’attività del microprocessore richiedendo continue operazioni di cifratura/decifratura. Nel caso quindi lo stesso debba essere impiegato in sistemi caratterizzati da un elevato traffico di rete si consiglia di valutare con attenzione l’impatto prestazionale

gennaio 23, 2008 Posted by | Sicurezza | Lascia un commento

Firma Digitale

La firma digitale è associata indissolubilmente al concetto di documento elettronico. La recente normativa italiana conferisce ad un documento elettronico firmato digitalmente, utilizzando tecniche di firma asimmetrica, la stessa valenza probatoria di un documento cartaceo munito di firma olografa.
La firma digitale, quindi, esprime un atto volontario di sottoscrizione e, sotto il profilo tecnico organizzativo, deve essere basata su un certificato qualificato (quindi rilasciato da una trusted part detta Certification Authority che, per quanto previsto dalla vigente legislazione nazionale deve essere iscritta nell’elenco pubblico dei certificatori) e creata mediante un dispositivo di firma sicuro (in genere una smart card).
La direttiva europea e la nascita del commercio elettronico, hanno introdotto altri tipi di firma applicabili in contesti diversi da quello di un documento, come per esempio quello dei messaggi di posta elettronica: in questo caso si parla di firma elettronica.
Sia la firma digitale che quella elettronica permettono realizzare un sistema con il quale il mittente possa mandare un messaggio firmato al destinatario in modo che valgano le seguenti condizioni:
1. il destinatario può verificare l’identità dichiarata dal mittente;
2. il mittente non può ripudiare in un secondo tempo il contenuto del messaggio;
3. il destinatario non può falsificare i messaggi del mittente.
Il primo requisito è necessario, per esempio, per i sistemi finanziari. Quando il computer di un cliente ordina al computer della banca di comprare una tonnellata di oro, il computer della banca deve poter essere sicuro che il computer che ha mandato l’ordine appartenga realmente all’azienda sul cui conto verrà addebitato. In altre parole, la banca deve poter autenticare il cliente (e il cliente deve poter autenticare la banca). Il secondo requisito è necessario per proteggere la banca dalle frodi. Supponiamo che la banca compri una tonnellata d’oro e, immediatamente dopo, il prezzo dell’oro cali bruscamente. Un cliente disonesto potrebbe far causa alla banca, dicendo che non ha mai mandato l’ordine di comprare dell’oro. Quando la banca porterà il messaggio in tribunale come prova, il cliente negherà di averlo spedito. Il terzo requisito è necessario per proteggere il cliente, se il prezzo dell’oro sale e la banca tentasse di costruire un messaggio firmato in cui il cliente chiedeva una barra d’oro al posto di una tonnellata. In questo scenario di frode, la banca si tiene per sé il resto dell’oro.
Nel seguito di questo capitolo si illustreranno vari schemi di firma digitale e le loro implementazioni; ove necessario, saranno utilizzati degli esempi di situazioni reali che descrivono i vari scenari in cui ci si può trovare quando si implementano architetture basate sulla firma digitale. Infine si tratteranno brevemente gli aspetti legali legati alla firma digitale.

Firma a chiave simmetrica
Un approccio alle firme digitali è la creazione di un’autorità centrale che le conosce tutte e di cui tutti hanno fiducia: chiamiamolo Big Brother (BB). Ogni utente sceglie una chiave segreta e la porta a mano nell’ufficio di BB. Per maggiore chiarezza chiameremo il primo utente Alice ed il secondo Bob. Quindi, solo Alice e BB conoscono la chiave segreta KA e così via.
Quando Alice vuole mandare un messaggio in chiaro firmato, P, al suo banchiere, Bob, genera KA(B, RA, t, P), dove B è l’identità di Bob, RA è un numero casuale scelto da Alice, t è il timestamp che assicura la freschezza del messaggio e KA(B, RA, t, P) è il messaggio cifrato con la chiave KA. A questo punto Alice manda il messaggio, come nella figura sottostante, BB vede il messaggio da Alice, lo decifra e lo manda a Bob, come mostrato.

Firme digitali usando Big Brother

Il messaggio per Bob contiene il testo in chiaro con il messaggio di Alice e anche il messaggio firmato KBB(A, t, P). Infine Bob compie le azioni richieste da Alice.
Cosa succede se, in un secondo tempo, Alice nega di aver spedito il messaggio? Il passo 1 è che ognuno denuncia tutti gli altri. Infine, quando il caso arriva in tribunale e Alice continua a negare risolutamente di aver mandato il messaggio in questione a Bob, il giudice chiederà a Bob come può essere sicuro che il messaggio proveniva da Alice e non da un intruso (che chiameremo Trudy). Bob, come primo argomento, fa notare che BB non accetta messaggi da Alice se non sono cifrati con KA, quindi non è possibile che Trudy abbia mandato a BB un messaggio falso spacciandosi per Alice, senza che BB se ne sia accorto subito. Bob a questo punto può presentare la prova A: KBB(A, t, P). Bob afferma che questo è un messaggio firmato da BB, che prova che Alice ha inviato P a Bob. Il giudice chiede quindi a BB (di cui tutti si fidano) di decifrare la prova A. Quando BB testimonia che Bob ha detto la verità, il giudice dà ragione a Bob. Il caso è chiuso.
Un potenziale problema con il protocollo di firma della figura precedente è dato dagli attacchi di tipo ripetizione, che Trudy può eseguire con entrambi i messaggi. Per ridurre l’impatto di questo problema, vengono usati i timestamp. Inoltre Bob può controllare tutti i messaggi recenti per vedere se RA era già stato usato. In caso affermativo, il messaggio viene scartato come possibile attacco di ripetizione. Notiamo che, basandosi sul timestamp, Bob rifiuterà i messaggi troppo vecchi. Per proteggersi contro attacchi di ripetizione istantanea, Bob deve solamente controllare che RA di ciascun messaggio non corrisponda a quello di un messaggio ricevuto nell’ultima ora da Alice. In questo caso Bob può assumere che il messaggio sia una nuova richiesta.

Firma a chiave pubblica
Il problema strutturale della crittografia a chiave simmetrica per la firma digitale è dato dal fatto che tutti devono fidarsi di una autorità centrale (Big Brother), la quale può anche leggere i messaggi di tutti. I candidati più logici per una Autority sono il governo, le banche, i contabili e gli avvocati. Sfortunatamente, nessuna di queste organizzazioni riesce a suscitare un senso di sicurezza totale in tutti i cittadini. Quindi è auspicabile avere un metodo per firmare i documenti che non richieda un’autorità fidata.
Fortunatamente, la crittografia a chiave pubblica può dare un contributo importante in quest’area. Assumiamo che gli algoritmi di cifratura e decifrazione abbiamo la proprietà che E(D(P)) = P (D sta per Decript, E sta per Encript), oltre alla proprietà solita D(E(P)) = P. RSA ha questa proprietà, quindi sappiamo già che la nostra richiesta è ragionevole. Sotto queste ipotesti. Alice può trasmettere un documento, P, a Bob inviando EB(DA(P)). È importante notare che Alice conosce sia la sua chiave privata, DA, sia la chiave pubblica di Bob, EB, e in questo modo riesce a costruire il documento da inviare.
Bob, dopo aver ricevuto il messaggio, lo trasforma come al solito usando la sua chiave privata, ottenendo quindi FA(P) come mostrato nella figura successiva. Bob memorizza il messaggio in un posto sicuro e poi applica EA per ottenere il messaggio in chiaro originale.

Firme digitali usando la crittografia a chiave pubblica

Per vedere come funziona la proprietà di firma, supponiamo che Alice in un secondo momento voglia negare di aver mandato il messaggio P a Bob. Quando il caso arriva in tribunale, Bob può presentare sia P sia DA(P). Il giudice può facilmente verificare che Bob ha in effetti un messaggio valido che è stato cifrato con Da, semplicemente applicandogli EA. Visto che Bob non conosce la chiave privata di Alice, l’unico modo in cui Bob può aver ricevuto un messaggio cifrato con quella chiave è una trasmissione da parte di Alice.
Alice avrà diverso tempo libero per pensare a nuovi schemi crittografici a chiave pubblica mentre sarà in prigione per frode e falsa testimonianza.
La crittografia a chiave pubblica per la firma digitale è uno schema elegante, che però presenta alcuni problemi legati principalmente al contesto in cui viene utilizzata, piuttosto che agli algoritmi utilizzati. Come primo punto, Bob può provare che un messaggio è stato realmente mandato da Alice solo se la chiave Da rimane segreta. Se Alice rende pubblica la sua chiave segreta, il discorso non vale più, in quanto chiunque. incluso Bob, potrebbe aver inviato il messaggio.
Per esempio il problema può verificarsi se Bob è l’agente di borsa di Alice. Alice dice a Bob di comprare alcune azioni e obbligazioni. Quasi immediatamente il prezzo cala bruscamente. Con lo scopo di ripudiare il messaggio inviato a Bob, Alice corre dalla polizia dicendo che la sua casa è stata svaligiata e che il PC con la chiave è stato rubato. A seconda delle leggi in vigore nel suo stato di residenza, Alice può essere considerata responsabile del messaggio inviato oppure no; ciò può dipendere anche dal fatto che Alice dichiari di non aver scoperto il furto fino al suo rientro a casa dal lavoro, diverse ore dopo.
Un altro problema con lo schema della firma elettronica si ha quando Alice decide di cambiare la sua chiave. Questa operazione è sicuramente legale, inoltre è una buona idea farla periodicamente. Se in seguito si dovesse andare in tribunale come descritto sopra, il giudice userebbe la chiave corrente EA per verificare DA(P) e scoprirebbe che non produce P.
A questo punto Bob sarebbe in una posizione indifendibile.
In teoria, qualunque algoritmo a chiave pubblica può essere usato per la firma digitale. Lo standard de facto, utilizzato da una grande quantità di prodotti per la sicurezza, è l’algoritmo RSA.

gennaio 12, 2008 Posted by | Sicurezza | Lascia un commento