Telemat Lab's home page


Copyright © 1986 Università di Firenze.All rights reserved.

Free license available.

MIDDLE

di Cecconi Alessia e Gallileo Giovanni

Revisori: Franco Pirri e Maurizio Lunghi


Applicazioni

home pageIndicePrec.Succ.

Capitolo 5

Applicazioni della crittografia

Esistono al giorno d'oggi numerosi settori nel mondo della telematica per i quali è (o sarà) necessario un adeguato utilizzo di software crittografico. Si sono visti nei capitoli precedenti diversi tipi di algoritmi di crittografia, che si basano su principi sostanzialmente diversi; è quindi opportuno riuscire a trovare per ciascuno di essi il corretto ambito di utilizzo.
Valgono comunque alcune regole generali che il crittosistema dovrebbe possedere:

  1. La sicurezza di un potente cifrario dovrebbe risiedere nella segretezza della chiave piuttosto che nella supposta segretezza dell'algoritmo; questo vuol dire che anche se un criptoanalista conosce completamente il metodo usato, non riuscirà comunque a rompere il cifrario.

  2. Un forte crittosistema dovrebbe avere uno spazio delle chiavi abbastanza grande, in modo tale da rendere difficoltosa la ricerca della chiave segreta anche utilizzando calcolatori molto potenti.

  3. Un forte crittosistema dovrà essere in grado di produrre un testo cifrato che possa apparire il più possibile "casuale" a tutti i più potenti tests statistici, in maniera tale da nascondere ricorrenze tipiche di un determinato linguaggio.

Avvalendosi di queste regole fondamentali, la crittografia è usata principalmente per:

Autenticazione
Il sistema di autenticazione Kerberos
Crittazione di e-mail e news
PGP
Prologo
Generalità
Algoritmi utilizzati
Gestione e tipi di messaggi
Gestione delle chiavi
Funzioni avanzate
Considerazioni sulla sicurezza
Crittazione della voce
Crittazione dei file
Moneta elettonica


Applicazioni

AUTENTICAZIONE


Applicazioni

Introduzione all'AUTENTICAZIONE

L'autenticazione rappresenta una prova d'identità. Di solito questo prevede un insieme di fattori che ci caratterizzano, di cose che conosciamo e di cose che possediamo. Gli amici, i familiari e i conoscenti in genere ci identificano con qualche cosa di definito e di fisico che ci riguarda. Gli sportelli della Bancomat ci identificano come clienti validi a secondo di ciò che possediamo (la carta Bancomat) e per qualche cosa che conosciamo (il codice segreto).
Gli schemi di autenticazione di Internet comprendono qualche cosa che noi conosciamo, qualche cosa che possediamo o entrambe. Ciò che si sa potrebbe essere il nome di un account e una password; quello che si possiede un dispositivo di autenticazione dell'hardware.
Possiamo avere tre tipi di autenticazione:

Come già detto, le tecniche mediante le quali è possibile identificare host o user sfruttano "quello che sei" (SYA), "quello che sai" (SYK) o "quello che possiedi" (SYH). Al giorno d'oggi le tecniche di autenticazione SYA non sono disponibili per un uso generalizzato su Internet. La forma di autenticazione più usata, in Internet, è SYK, cioè in base a quello che uno possiede, per esempio una password o il nome di un account.
La resistenza dell'autenticazione SYK dipende da quanto ciò che si sa è segreto e da quanto possa essere mantenuto tale. Dato che buona parte delle informazioni SYK possono essere osservate o scoperte di nascosto in molti modi, questo sistema non viene considerato una delle migliori e più sicure forme di autenticazione.
Proprio per come è concepito SYH è il metodo di autenticazione meno sicuro. Infatti il possesso di un oggetto che può essere preso in prestito, rubato o duplicato è chiaramente un metodo poco sicuro per identificare il proprietario. Il valore di SYH migliora moltissimo quando esso viene associato a SYK. Per esempio si pensi alla Bancomat: per fare una transizione sul proprio conto in banca bisogna avere la propria tessera e conoscere il proprio codice segreto.


Applicazioni

Autenticazione USER-TO-HOST

La funzione di questo tipo di autenticazione è di fornire agli utenti dei servizi ai quali sono autorizzati ad accedere e di negare l'accesso a quei servizi ai quali non lo sono. Questi servizi possono comprendere sessioni interattive di login, trasferimenti della posta elettronica alla workstation dell'utente, o l'accesso tramite la rete ai file di sistema dell'host. Gli schemi di autenticazione user-to-host esistenti sono numerosi. Vediamone tre dei più utilizzati che si basano su password statiche, su password one-time e su terzi di fiducia.


Applicazioni

Password statiche

Ovviamente lo schema di autenticazione più presente in Internet è basato sulle password statiche. Un utente sceglie, o gli viene assegnato, un nome di account e una password che rimane segreta e che solo l'utente dovrebbe conoscere. Messe insieme queste due cose convincono l'host dell'identità dell'utente. L'host ha solo il bisogno di avere il modo di confermare che la password introdotta dall'utente è corretta.
Fortunatamente l'identità degli utenti può essere confermata senza dover archiviare delle password in cleartext (non criptate) nel server. Nei sistemi UNIX, per esempio, il database delle password archivia un one-way hash di password degli utenti. Quindi, quando l'utente inserisce la sua password, durante il login, questa viene passata attraverso l'algoritmo che calcola il valore di hash ed il risultato confrontato con quello archiviato, se la password digitata è corretta il riconoscimento dell'utente da parte dell'host è concluso.
Purtroppo questo schema presenta parecchi punti deboli, uno di questi è abbastanza banale: la password può essere rivelata ad altri, intenzionalmente o per errore. Inoltre si sa che gli utenti tendono a scegliere password semplici quando ne hanno la possibilità. E' stato osservato che il 25% delle password può essere indovinato basandosi su:

  1. Nome, indirizzo numero di telefono etc...del possessore della password;
  2. Nomi di persona, luoghi, numeri, frasi volgari, abbreviazioni etc...
  3. Accoppiamente di brevi parole provenienti dal database on line.
  4. Permutazioni di parole, tra cui sostituzioni di lettere con numeri; semplice scrittura a lettere maiuscole e plurali.
Perciò gli utenti dovrebbero essere educati ad una migliore scelta e gestione delle password, dal momento che sono loro i responsabili della propria sicurezza.
Le versioni più aggiornate di UNIX includono dei miglioramenti della sicurezza come shadow passwords e password aging. Queste sono caratteristiche molto utili, di solito implementate insieme, che forniscono delle notevoli misure di sicurezza ad un sistema.
Le shadow password sono nascoste in una "shadow" o "ombra", una directory che può essere letta solo dal superuser.
La password aging è una funzione che spinge gli utenti a cambiare regolarmente la propria password, cosa che essi non fanno se non è strettamente necessario. Quando il periodo di vita concesso ad una password scade l'utente la deve cambiare al successivo login oppure gli verrà negato l'accesso. Una password dovrebbe avere un tempo di vita massimo di un anno, il pericolo di compromissioni e di esposizione ad attacchi aumenta con il tempo.
Le migliori implementazioni di password aging implementano anche la password history (storia della password). Se non viene tenuta memoria delle password cambiate più di recente (registrate in forma cifrata, naturalmente), un utente sprovveduto potrebbe riutilizzarne una vecchia.


Applicazioni

Password one-time

In qualunque meccanismo di autenticazione che si basa sulle password è importante selezionare una password che sia immune da attacchi. Se però viene immessa una password sicura in cleartext in un canale non sicuro, essa diviene automaticamente soggetta a spionaggio di rete e quindi non sicura. A differenza di altri meccanismi di autenticazione basati su password statiche, quelli basati su password one-time non sono messi in pericolo dall'immissione di password in cleartext. Vediamo due meccanismi one-time: S-Key e Smart Cards.


Applicazioni

S-Key

L'idea che sta alla base del sistema one-time password S-Key di Bellcore, descritto nell'RFC 1760, è stata inizialmente concepita da Leslie Lamport e in seguito implementata in software sui sistemi UNIX da Phil Karn. S-Key usa una secret password (password segreta) dell'utente per produrre algoritmicamente una sequenza di password, ognuna delle quali può essere usata una sola volta. Come per le password standard di UNIX, le password one-time di S-Key non vengono registrate in cleartext sul server del sistema. Le secret passord rimangono sempre sconosciute ai loro proprietari e non vengono mai trasmesse sulla rete se non per sbaglio. L'operazione eseguita da S-Key è una funzione hash MD4 o MD5 con input la secret password ed output la password one-time. Questa funzione viene applicata più volte, per esempio supponiamo che n=3 sia il numero di volte che S-Key esegue l'hash (detta f) alla password segreta, il risultato f(f(f(s)))=f³(s) (dove s indica la secret-password) viene registrato nel database delle password. Quando l'utente si collega per la prima volta, riceve il prompt della sua prima one-time password f²(s), che viene trasmessa in cleartext. Il programma di login di S-Key la riceve e fa hash una sola volta calcolando f(f²(s))=f³(s). Se questo valore è identico a quello registrato nel database delle password, l'utente è riconosciuto. In ogni caso f²(s) sostituisce f³(s) nel database delle password. Quando l'utente si collega nuovamente verrà autenticato con f¹(s).
S-Key è disponibile su ftp://ftp.bellcore.com/pub/nmh/.


Applicazioni

Smart Cards

Le Smart Cards sono dei piccoli dispositivi hardware che generano password one-time. Tali autenticatori hanno le dimensioni di una carta di credito ma contengono al loro interno una CPU, un sistema operativo in miniatura, un orologio, una RAM temporanea per i calcoli crittografici, una RAM non volatile o EEPROM (Electrically erasalble read only memory) per la registrazione della chiave.


Applicazioni

Terze parti di fiducia

Dal momento che, quando un utente si collega ad un host, quest'ultimo deve giudicare la sua autenticità sulla base di credenziali (come una password statica o one-time) che l'utente gli fornisce, l'host deve di base avere fiducia. Inoltre vi è un'implicita fiducia da parte dell'utente. Egli infatti fornisce le proprie credenziali al prompt fidandosi del fatto che l'host sia quello che voleva e non un impostore. Questo schema di autenticazione user-to-host comunemente implementato è un modello a due parti di fiducia, nel quale ogni parte decide di fidarsi dell'altra sulla base di alcuni criteri.
Un'altra tecnica prevede una terza parte di fiducia. In questo modello l'host non deve affidarsi solamente alle credenziali fornite dall'utente o da un dispositivo in suo possesso, nello stesso modo l'utente non deve fidarsi dell'host. Entrambe le parti si appoggiano ad una terza entità detta Key Distribution Center (KDC), che controlla le rispettive identità. Solo il KDC detiene la fiducia di tutti.
Nella maggior parte dei casi un KDC non fa distinzione tra utenti e host, o meglio tra programmi server e host. Tratta tutti come principal, entità distinte che condividono un segreto (una key crittografica) con il KDC. Il KDC è in grado di verificare l'identità di un principal basandosi sulla conoscenza del suo segreto. Questa conoscenza gli permette anche di identificare un principal da un altro senza divulgare il segreto di nessuno dei due.
Per esempio, supponiamo che l'utente A voglia autenticare con l'host B. Sia A che B condividono i propri segreti con il KDC. A inizia con il contattare il KDC richiedendo l'autenticazione delle credenziali Cred(A) che intende presentare a B.
Il KDC obbliga A ad inviargli delle credenziali che convinceranno B della sua identità. Queste credenziali sono racchiuse all'interno di due "pacchetti" criptati: quello esterno cifrato per A (quindi con la chiave KeyA) e quello interno criptato per B con KeyB. Se A non riesce a decifrare il pacchetto esterno non potrà neppure estrarre quello interno che deve mandare a B.
Una volta decriptato il pacchetto esterno, A invia il pacchetto interno a B insieme ad altre informazioni. Se B riesce a decriptare il pacchetto (cosa che può fare se conosce la password) ottiene le credenziali di A che sono state preparate dal KDC. B può quindi credere tranquillamente nell'identità di A.
Questo esempio riguarda un tipo di crittografia a secret-key ma si può costruire uno schema di autenticazione con terza parte di fiducia che usi la crittografia a public-key.
Come abbiamo visto gli aspetti dell'autenticazione basata su una terza parte di fiducia si appoggiano alla presenza e alla cooperazione del KDC. Trattandosi dell'arbitro unico e centrale della fiducia, esso deve essere un sistema chiaramente visibile, affidabile e sicuro. E' ovvio che un attentato alla sicurezza del KDC ha come risultato dei disastri.


Applicazioni

Autenticazione HOST-TO-HOST

L'autenticazione host-to-host si occupa dell'identità dei sistemi di computer che si trovano sulla rete. L'RFC 1704 descrive diversi mezzi mediante i quali si può ottenere l'autenticazione host-to-host, vediamone alcuni:


Applicazioni

Nessuna autenticazione

Oggi questa è la condizione della maggior parte delle autenticazioni host-to-host in Internet. Al momento l'unica maniera universale per giudicare l'identità di un host è attraverso la sua presentazione ad un indirizzo di rete IP. La versione attuale di IPv4 non presenta alcuno schema di autenticazione, questo è infatti uno dei maggiori problemi di tale versione (vedere Articolo su IPng, paragrafo "Perché è necessario voltare pagina").
Anche l'autenticazione che si basa sul nome degli host può essere classificato nella categoria "nessuna autenticazione", infatti i nomi esistono principalmente per una questione di comodità per gli uomini. L'uso dell'autenticazione basata sul nome presuppone anche il DNS sia sicuro, cosa che, nell'attuale implementazione, non è. Un host viene convinto facilmente del fatto che un indirizzo usato dalla macchina di un hacker corrisponda al nome di una macchina diversa (di cui magari si fida).


Applicazioni

Rivelazione delle password

Alcuni protocolli host-to-host rivelano le informazioni di autenticazione (password) in cleartext all'interno dei messaggi di protocollo. Questo tipo di tecnica è solo lievemente migliore della "assenza di autenticazione", nel senso che un potenziale attacker dovrebbe quanto meno conoscere le password andando a spiare i messaggi di protocollo. .


Applicazioni

Firme digitali e crittazione

Gli algoritmi di crittografia a secret-key o public-key visti in precedenza possono essere usati anche da host che comunicano tra loro oltre che dagli utenti. Gli host possono scambiarsi dei datagrammi di rete in maniera simile a quella usata dagli utenti per scambiarsi messaggi di e-mail. La prossima versione di IP (versione 6) conterrà delle specificazioni di sicurezza basate su questa linea.


Applicazioni

Autenticazione USER-TO-USER

Esistono vari metodi per svolgere l'autenticazione user-to-user con i quali si dà prova dell'identità di un utente ad un altro utente. Una tecnica potrebbe essere quella di impiegare "firme digitali" tramite funzioni di hash o coinvolgere una terza parte come con il sistema Kerberos.

Bibliografia e sorgenti d'informazione


Telemat Lab's home page
home pageIndicePrec.Succ.


Explore the TELEMAT Site !!!

Ultimo aggiornamento: 24/1/97