Autenticazione Protocolli di autenticazione ti i Ing. Michela Cancellaro Ing. Federica Battisti L'autenticazione è il processo che consente di identificare qualcun altro. L'autenticazione deve avvenire on-line, cioè istantaneamente. Deve essere distinta dall'autenticazione di colloqui passati, concetto che investe la firma elettronica. Sulla rete l'autenticazione deve essere effettuata solamente utilizzando scambi di messaggi e dati, che fanno parte di un protocollo di autenticazione. L'autenticazione deve essere fatta prima di iniziare lo scambio di informazioni, quindi il protocollo di autenticazione viene prima degli altri (si parla di protocolli di hand-shaking). In effetti prima di parlare ci si presenta o almeno ci si saluta! quello che si sa L identità di un principal può essere verificata in base a tre fattori: 1. Quello che si sa: password. La password è una chiave che si deve inserire per provare di conocerla. La password dovrebbe essere sufficientemente complessa da essere difficile da indovinare, ed al tempo stesso sufficientemente semplice affinchè l utente la possa ricordare. quello che si ha 2. Quello che si ha: smartcard. Unasmartcard è una carta in plastica, simile ad una carta di credito, contenente al suo interno un micro-chip. Sulla superficie della carta possono essere impresse alcune informazioni: un codice a barre od una striscia magnetica, le generalità del possessore della carta, la data di scadenza della carta ed alcune informazioni riguardanti il produttore. Attraverso i contatti la carta può ricevere alimentazione, i comandi e dati; le carte necessitano infatti di un hardware esterno per operare, che fornisce loro anche la necessaria alimentazione. Recentemente sono state sviluppate della carte prive di contati fisici che comunicano con l esterno tramite una antenna. Le dimensioni della carta sono stabilite dallo standard ISO 7816 che definisce anche le caratteristiche fisiche della plastica, la posizione dei contatti e le modalità di comunicazione.
quello che si è Proprietà dei protocolli di autenticazione 3. Quello che si è: dati biometrici. I meccanismi sono diversi: riconoscimento della voce, delle impronte digitali, delle dimensioni delle dita della mano, della forma dei vasi sanguigni della retina, dei pattern di colore dell iride dell occhio, ecc. In ogni caso sono necessari dei complessi dispositivi fisici per effettuare il riconoscimento. Usi: 1. Autenticazione: l accertamento che la caratteristica sia quella dell utente che la presenta. 2. Identificazione: dato un campione biometrico, si vuole scoprire a chi appartiene. 3. Unicità: dato un campione biometrico, si vuole verificare se il proprietario è gà nel database Reciprocità dell autenticazione Complessità Efficienza computazionale Efficienza della comunicazione Costo Terze parti Se una terza parte è necessaria Se è necessaria in tempo reale Natura della fiducia richiesta dalla terza parte Quali garanzie di sicurezza sono offerte Come e dove sono mantenute le chiavi e/o i segreti Passwords (Autenticazione Debole) Stringhe di 6-8 caratteri che permettono l identificazione Password fisse/pin, password one-time Passwords (Autenticazione Debole) Forma di autenticazione su qualcosa che sai Proprietà Non reciprocità normalmente le password permettono identificazione unilaterale Bassa complessità molto efficienti sia dal punto di vista computazionale che dal punto di vista della comunicazione Normalmente non è richiesta una terza parte, (il Single Sign On rappresenta l eccezione) La chiave è normalmente tenutat a memoria dall utente t ed in un file dal sistema
Attacchi alla Password fisse Attacchi Replay Osservazione durante l inserimento, linserimento, social engineering (attaccante convince in modo subdolo un dipendente a fornirgli le informazioni necessarie per accedere al sistema), cavalli di Troia Eavesdropping su un canale di comunicazione i inchiaro Ricerca esaustiva Random o sistematicamente tentare le password online Ricerca offline su un file di password Attacchi tipo dizionario Si assume che non tutte le password abbiano la stessa probabilità E sufficiente che un utente scelga una password debole L attacco a dizionarioionario prova solamente le possibili password più probabili Attacchi su password note Molti sistemi sono provvisti di password standard (di servizio o ripristino). Sicurezza delle Password Fisse Password criptate Scopo: evitare un troppo facile accesso dallo staff interno Normalmente, la password non è criptata usando una chiave simmetrica, ma piuttosto usando una funzione di hash one-way e.g., la password di Alice è immagazzinata come h(alice,pwd) Regole sulle Password la password deve avere almeno 8 caratteri, o usare passphrase (insieme di parole brevi usate come singola password) la password devee includere maiuscole, minuscole, cifre e caratteri speciali la password non dovrebbe avere un significato è necessario modificare la password con regolarità (tipicamente 30 giorni) non si deve utilizzare la stessa password su sistemi diversi Sicurezza delle Password Fisse Rallentamento nella verifica della password Lo scopo è limitare l uso lusodi programmi per la ricerca esaustiva Normalmente si ottiene applicando in maniera ricorsiva una funzione più semplice in cui l iterazione t+1 usa il risultato dell iterazione t Deve essere accettabile per gli utenti (e.g., un secondo) Salting Scopo: limitare l uso di attacchi simultanei tipo dizionario Aggiunge alcuni bit alla password prima dell hashing Normalmente, qualcosa legato al tempo o allo user id L informazione rimane nel file delle password Personal Identification Numbers Normalmente usati come qualcosa che si conosce in combinazione con qualcosa che si possiede Molto spesso una carta di credito o di bancomat Tipicamente brevi (4 cifre), per essere ricordati a memoria. Per impedire ricerche esaustive, carta viene ritirata (o disabilitata) dopo 3-4 tentativi. Per permettere l uso con dispositivi offline, il PIN può essere immagazzinato sulla carta, alcune volte criptato con una master key Questa è una forma di autenticazione a due livelli, dove la seconda chiave ad alta entropia è immagazzinata sulla carta
Passkeys (passwd-derived keys) Password utente fatta corrispondere (mediante 1WHF) a una chiave crittografica (i.e., DES a 56-bit): chiamata passkey passkey usata per criptare la comunicazione Più resistente della password contro un attacco di tipo replay (se ricerca esaustiva su passwd non piu` facile di passkey) Per ottenere passkey che cambia nel tempo, aggiungere contatore alla password A volte aggiunto salt basato su userid One-time Password Verso autenticazione forte: soluzione parziale contro attacchi tipo eavesdropping e replay. Variazioni: Liste condivise di one-time password Aggiornamento sequenziale delle one-time password Password i+1 concordata quando avviene autenticazione con password i Uso di funzioni one-way per creare una sequenza Lamport: P i =H(P i +1), dove H( ) è una 1WF Nota 1: autenticazione richiede un contatore Note 2: un attacco tipo replay sarebbe possibile se la sequenza fosse in avanti Implementazioni commerciali con generatori automatici hardware Autenticazione basata su un segreto condiviso Protocolli Challenge-response: autenticazione a due vie Identificazione Challenge-Response (Autenticazione Forte) R i sono le richieste (challenge), i indica il richiedente (numeri molto grandi detti NONCE mandati dtiinchiaro) K i sono le chiavi K S è la session key
Autenticazione basata su un segreto condiviso Protocolli Challenge-response: autenticazione a due vie ridotto Regole generali 1. Fare in modo che chi inizi l autenticazione provi la sua identità prima che lo faccia chi risponde. 2. Far sì che i due soggetti usino chiavi differenti per autenticarsi anche se ciò significa usare due chiavi condivise. Purtroppo talvolta l utente C rompe il funzionamento del protocollo con l attacco per riflessione 3. Far sì che i due soggetti usino, perlerichieste, numeri presi da insiemi diversi. 4. Rendere il protocollo resistente ad attacchi che coinvolgono una seconda sessione parallela, dove le informazioni ottenute da una sessione possono essere usate per l altra. Attacco per riflessione Soluzione: HMAC Non c è possibilità di illudere Alice che Trudy sia Bob perché Trudy non riesce ad indurre nessuna delle due parti a cifrare o calcolare l hash di un valore a sua scelta. Entrambi gli HMAC includono dei valori scelti dalla destinazione, cioè qualcosa che Trudy non può controllare.
Scambio di chiave: Deffie-Hellman Autenticazione con KDC Introducendo un centro di distribuzione delle chiavi KDC (key distribution center), ogni utente ha una singola chiave condivisa col KDC cui sono affidate la gestione dell autenticazione e della chiave di sessione Tuttavia Trudy può effettuare un attacco bucket brigade detto man in the middle Svantaggio: il metodo è vulnerabile rispetto al replay attack (attacco di ripetizione) i Soluzioni: timestamp (contrassegno temporale): i messaggi scaduti vengono subito scartati dal destinatario; mettendo un nonce in ogni messaggio, il soggetto scarta tutti i messaggi contenenti nonce già usati. Needham-Schroeder Needham-Schroeder Otway-Rees È una versione modificata di Needham-Schroeder: Dbl Debolezza: ottenendo una vecchia chiave di sessione nel testo in chiaro, Trudy sarà in grado di stabilire una sessione con Bob. Le basterà ripetere il messaggio 3 che corrisponde alla chiave compromessa e Bob sarà convinto di essere in comunicazione con Alice.
Protocollo sicuro Autenticazione con la crittografia asimmetrica Difesa dagli attacchi a sistemi Challenge-Response Attacco replay (l avversario intercetta i messaggi scambiati e li ritrasmette in un esecuzione successiva) Usarenonces, includere l identità nella risposta Attacco di tipo interleaving (Se sono in corso più esecuzioni contemporanee del protocollo, ossia delle sessioni parallele), l avversario può usare in una sessione dati ottenuti in un altra) Concatenare i messaggi del protocollo Attacco man-in-the-middle (l avversario si fa passare per A nei confronti di B e viceversa) Autenticazione reciproca per impedire all avversario di impersonare il sistema partner Attacco reflection (l avversario ritrasmette a una parte dati che la parte stessa ha trasmesso in una sessione parallela) Include l identità del partner, usare chiavi uni-direzionali Attacco su testi scelti Usare un confounder in ogni messaggio Usare protocolli zero-knowledge Il protocollo Kerberos Il protocollo Kerberos Nasce nei primi anni 80 dalla collaborazione di IBM, Digital e M.I.T. Il nome deriva dalla mitologia greca Autorizzazione: determinare se un client è autorizzato ad usufruire di un servizio Autenticazione: determinare se l identità dichiarata dal client è vera Cifratura - accounting: garantire la segretezza della comunicazione e prevenire che parti estranee la modificano o la intercettano
Il protocollo Kerberos È un protocollo distribuito che fornisce la sicurezza di autenticazione su reti aperte e insicure dove la comunicazione tra gli host può essere intercettata. Utilizza uno schema Third Party Trust e si basa sull uso di chiavi segrete per cifrare le informazioni scambiate tra le entità Gli utenti, i client e i server si autenticano a vicenda tramite il KDC, Key Distribution Center. Obiettivi La password dell'utente non viene inviata sulla rete, non viene memorizzata sull host (non dovrebbe essere memorizzata in chiaro neanche nel database del KDC) e viene cancellata dopo l utilizzo Single Sign-On: l'utente inserisce la password all inizio della sessione di lavoro. Può accedere, senza reinserirla durante tale sessione, a tutti i servizi per il quale è autorizzato Mutua autenticazione: anche i server applicativi provano la loro autenticità ai client Obiettivi Il processo di autenticazione risulta invisibile all'utente e realizza uno scambio di Ticket cifrati senza che sulla rete circolino informazioni segrete. Si limita così l invio delle informazioni di autenticazione attraverso la rete ed agisce su host e su server applicativi (imap, pop, smtp, telnet, ftp, ssh, AFS ) considerati vulnerabili. La gestione delle informazioni di autenticazione è centralizzata e protetta sul sistema KDC. Obiettivi Le informazioni di autenticazione dei client non vengono memorizzate sui server applicativi. Viene limitata la ridondanza di informazioni di autenticazione e ridotte le locazioni attaccabili. L'account di un utente può essere disabilitato agendo direttamente sul KDC. Dopo autenticazione e autorizzazione, la connessione tra p, client e server viene impostata come sicura e i dati vengono trasmessi e criptati con l uso delle chiavi.
Il protocollo Kerberos Schema generale Elimina la trasmissione delle informazioni di autenticazione sulla rete riducendo le locazioni attaccabili da utenti estranei. Non si ha la necessità di dimostrare il possesso di informazioni segrete. Il sistema di autenticazione è supportato solo dal KDC e senza l ausilio di certificati digitali contenenti le chiavi pubbliche degli utenti firmate con la chiave privata di un autorità di certificazione. Kerberos è flessibile, per aggiornarlo occorre modificare il KDC, èun pacchetto libero e può essere installato senza costi di licenza, al contrario di SSL. Il protocollo Kerberos Il protocollo Kerberos Si hanno più realm ognuno con il proprio AS etgs. Il realm è l inisieme di sistemi che usano Kerberos come sistema di autenticazione i Client Autenthication Server AS Ticket Granting Server TGS DB REALM 1 Server Client REALM 2 Server Client Application Server Key Distribution Center (KDC) REALM 3 Server Client
Componenti: Realm Componenti: Realm È il dominio amministrativo di autenticazione, entro cui il/i server di autenticazione è responsabile dell'autenticare un utente o un servizio Il nome del Realm coincide con il dominio DNS semplifica la configurazione e l integrazione del sistema Kerberos Rappresenra l'insieme di utenti e di server appartenenti e coordinati da uno specifico Authentication ti ti Server Un utente/servizio t i appartiene ad un Realm seesolosecondivide id un password/chiave con il server di autenticazione AS Dominio DNS example.com Realm Kerberos EXAMPLE.COM Cross-Authentication: l'autenticazione avviene anche se le entità attive fanno parte di Realm differenti Rappresenta la entry del database del KDC Componenti: Principal È l associazione usata per identificare ogni utente, host o servizio all interno del proprio Realm, per assegnare le credenziali di accesso alle risorse component1/component2/.../componentn@realm user@example.com admin/admin@example.com L'istanza è opzionale e si usa per specificare il tipo di utente Componenti: Principal Se le entry sono riferite a servizi, i principal sono definiti come: Servizio/Hostname@REALM imap/mbox.example.com@example.com host/server.example.com@example.comexample afs/example.com@example.com Ci sono principal che non fanno riferimento nè ad utenti nè a servizi, ii ma hanno un ruolo nel funzionamento dl del sistema it di autenticazione krbtgt/realm@realm, t/realm@realm con la cui chiave associata, it viene criptato il Ticket Granting Tickett
Il cuore del sistema è il Key Distribution Center Componenti: KDC È strutturato in tre parti, centralizzate su un unico server: Database, Authentication Server(As), Ticket Granting Server(Tgs) Nel database sono memorizzate le chiavi i degli utenti e le chiavi i dei servizi, ed è in grado di scambiare con ognuno di loro dei messaggi cifrati Kerberos supporta solo algoritmi simmetrici, quindi la stessa chiave è usata sia per criptare che per decriptare Vengono usate come default le porte 88 per il KDC e la porta 749 per il server di amministrazione Componenti: Ticket Contiene informazioni criptate con una chiave segreta: Il principal del richiedente Il principal del server/servizio a cui è destinato Il timestamp, con data ed ora dell inizio della sua validità L'indirizzo IP della macchina client Iltempo massimo di vita La chiave di sessione Ks È usato dal client per dimostrare l autenticità della sua identità ad un server applicativo Esistono diversi tipi ognuno caratterizzato dal valore dei flag: Initial e Pre-authenticated: ti t viene emesso dll AS dall AS. Le opzioni PRE-AUTHENT e HW-AUTHENT possono essere utilizzate per fornire informazioni addizionali nella fase di autenticazione iniziale Componenti: Ticket Le fasi di Kerberos Invalid: indica un ticket non valido Renewable: sono i ticket utilizzati per minimizzare i danni derivanti dal possibile furto di tickets, è caratterizzato da due tempi di scadenza: il tempo di scadenza associato al singolo ticket ed il massimo tempo di rinnovo possibile Postdated: ticket generato per essere utilizzato in seguito Proxiable e proxy: nel caso in cui un principal p permette ad un servizio di effettuare delle operazioni al suo posto. Il servizio sarà in grado di sostituire il client, ma solo per un determinato scopo Forwardable: è una versione particolare di ticket proxy, nella qualeal l servizio i è garantita lasostituizione i i totalet del client Client 1. AS exchange 2. TGS exchange 3. Client Server exchange KDC
Le fasi di Kerberos in dettaglio AS exchange AS_Req Client Fase 1 AS_Rep TGS_Req Fase 2 TGS_Rep AP_Req Autenthication Server AS Ticket Granting Server TGS DB Il client invia all'as una richiesta di autenticazione per accedere ad una applicazione fornita da un server Il messaggio di richiesta contiene: il nome - principal il nome dl del server a cui vuole accedere una data di scadenza calcolata a partire dalla sua data e ora locale Fase 3 Key Distribution Center (KDC) AP_Rep Application Server AS exchange (2) AS exchange (3) Client AS_Req Richiesta Autenticazione Kser AS_Rep Kli Kcli Autenthication Server AS L'AS LASriceve ed invia al client due Ticket di risposta: Uno è detto TGS ed è cifrato con la chiave del server Kser, per cui è stata fatta la richiesta, assieme all'id del client L'altro è detto TGT ed è cifrato con la chiave del client Kcli In entrambi i Ticket c'è la data di scadenza ricevuta dal client ed una copia della chiave di sessione Ks, criptata con l'hash della password dell'utente, valida per l'algoritmo crittografico scelto Ticket Tgs Ticket Tgt
AS exchange (4) La chiave di sessione, presente in entrambi i Ticket, permette di stabilire una comunicazione cifrata con il server interessato Se è abilitata la pre-autenticazione sull'utente, nella richiesta viene inserito un timestamp criptato con l'hash della password Una volta decriptato il timestamp, l AS accertandosi della validità, è certo che nonsi trattatt di un playback attack, cioè di una richiesta precedente, e invierà al client i due Ticket L uso dei timestamp in un sistema distribuito comporta l uso corretto della sincronizzazione TGS exchange Ricevuti i due Ticket, il client decripta il TGT con la sua chiave segreta Kcli: estrae la chiave di sessione (Ks) prepara un Ticket speciale, detto Authenticator, cifrato con la chiave di sessione Ks e inserisce: un timestamp calcolato a partire dalla sua ora locale, un checksum e alcune opzioni di cifratura Il client invia al server TGS: l'authenticator il ticket Tgs, ricevuto dall AS e cifrato con la chiave Kser, a cui vuole accedere TGS exchange (2) TGS exchange (3) Client TGS_Req Kser Ks Ticket Tgs Authenticator TGS_Rep Kservice Ticket Granting Server TGS Il server Tgs decripta il Ticket Tgs con la chiave segreta Kser e così estrae la chiave di sessione Ks, con la quale decripta l'authenticator Ne può verificare la scadenza usando l'informazione contenuta nel Ticket Tgs e si accerta che è stata generata dall AS Decifrando l'authenticator Authenticator, il server verifica l'integrità del Ticket controllando il timestamp e si accerta che non si tratti di un Ticket replica Lo scambio risulta sicuro dato che la richiesta è stata fatta dal client associato all Authenticator, unico a conoscenza della chiave di sessione Ks Ticket Service
TGS exchange (4) Un client in possesso di un TGT con il time-to-live valido invia le sue richieste al TGS e non più all'as Le comunicazioni tra TGS e client sono cifrate con la chiave di sessione Ks Crea in modo random una chiave di sessione, SKService. Crea il Ticket service inserendo il principal p del client richiedente, il principal del servizio, la lista di indirizzi IP, un timestamp del KDC, il lifetime, il valore minimo tra il lifetime del TGT e quello associato al principal i dl del servizio ii e ifi infine la session key SKService Il TGS genera un'altra chiave di sessione, Kservice, utile sia per il client che per l Application server ed invia al client il Service Ticket Client Server Exchange In questa fase il KDC non è coinvolto, perciò non vi è una strategia definita affinchè il client mostri le sue credenziali al server applicativo, ma userà la Kservice per stabilire la sessione Ricevuto il Service Ticket, il client crea un Authenticator contenente il suo principal, un timestamp e cripta tutto con la chiave di sessione Kservice Il server decripta le informazioni usando la propria chiave Kservice, stabilita in precedenza con il Kdc Mutua Autenticazione, se abilitata, il server ritorna un timestamp cifrato con la chiave di sessione del Service Ticket. Non solo il client è stato autenticato, ma anche il server applicativo non ha comunicato direttamente con il Kdc Client Server Exchange (2) Client Server Exchange (3) Client Ks AP_Req SKservice Service Ticket Authenticator ti t AP_Rep Application Server In Kerberos versione 5, nei server applicativi e nel Tgs si è implementata la Replay Cache, ossia la capacità di tener traccia degli Authenticator ricevuti dal Tgs Le richieste con stesso Authenticator, cioè le richieste replicate, sono eliminate e si evita che utenti estranei riescano ad acquisire sia il Ticket che l Authenticator Per garantire il meccanismo di autenticazione è necessario che tutti i pricipal coinvolti abbiano l'orologio di sistema sincronizzato i Accesso al servizio
Client Server Exchange (4) È ammessa l'autenticazione tra Realm differenti tramite l uso della Cross-Realm key, una session key nota tra i differenti AS Il client effettua una richiesta al proprio TGS che individua il TGS remoto appartente all altro Realm Il client riceve il TGT per la richiesta al TGS remoto Questo TGT sarà cifrato con la chiave condivisa tra i due TGS e così il TGS remoto potrà autenticare il client fornendogli un Service Ticket, utile allo scambio con l Application Server remoto Crittografia Kerberos fa largo uso della crittografia nei Ticket scambiati tra le diverse entità coinvolte nell'autenticazione Per implementare lo scambio di messaggi tra AS, client e server, sono necessari tre elementi: un algoritmo di crittografia forte una funzione HASH una funzione per il checksum dell Authenticator Non ci sono limitazioni sulla lunghezza della password dll't dell'utente, t molti algoritmi i di cifratura utilizzano una chiave a lunghezza fissa Crittografia (2) Fino alla versione 4, l'unico algoritmo di crittografia supportato era il DES, a cui era associato l uso di una funzione HASH ottenuta dal DES in una particolare modalità operativa e l'algoritmo CRC-32 per il calcolo dei checksum Nella versione 5, non è stato fissato a priori il numero e il tipo di encryption da supportare, dipende dalla specifica implementazione e dalla piattaforma Latecnicaadottatanelleoperazionidicifraturaèbasatasulla funzione string2key Crittografia (3) È stata introdotta la funzione string2key, che trasforma una password in chiaro in una encryption key, in base al tipo di crittografia, ed è una funzione hash irreversibile, cioè dall encryption key non si può determinare la password Viene richiamata quando un utente cambia la sua password o quando per autenticarsi si avvia una sessione Gli algoritmi disponibili sono: DES e Triplo DES per la crittografia hmac e CRC32 per i chksum sha1, md5 e la funzione derivata da DES-CBC per l'hash
Crittografia (4) Di default il salt aveva un valore nullo, con in nuovo Kerberos v5, come valore di salt, si usa il principal dell utente: Kclient=string2key ( Pclient + client@example.com" ) Kclient diventerà l'encryption key del client, dove Pclient è la password in chiaro, in tal modo si hanno i vantaggi: due principal appartenenti allo stesso Realm ed aventi la stessa password in chiaro, hanno chiavi differenti se un utente ha account su Realm diversi, è possibile che la password in chiaro coincida. Con l uso del salt, si evita un'eventuale compromissione dello stato degli account Un servizio i condivide id con il KDC una chiave e non una password Crittografia (5) Alla stringa composta dalla concatenazione della password edelsalt, viene applicata una funzione HASH, così da rendere la trasformazione dipendente dalla macchina Questa flessibilità ed estensibilità del protocollo ha mostrato dei problemi di interoperabilità tra le varie implementazioni, poiché si può applicare una qualsiasi funzione Hash ed un qualsiasi li i algoritmo per i checksum, occorre stabilire tbili un encryption type in comune Secure Socket Layer (SSL) Secure Socket Layer (SSL) Sistema sviluppato in origine da Netscape e poi da Microsoft La versione 3 sviluppata con review esterna con alcune modifiche, è diventata un progetto di standard noto come TLS TLS = Transport Layer Security SSL ha due strati protocollari Disponibili molte implementazioni e librerie, p.e. Open-SSL Utilizza la crittografia simmetrica e asimmetrica e le funzioni hash per fornire l atentiazione del server, la cifratura dei messaggi e l integrità dei dati. Quando si passa da una pagina pubblica a una sicura, il web server invoca SSL (l utente vede https) e compare un icona (lucchetto) e il client è invitato a mandare i propri parametri di sicurezza.
Cifratura simmetrica Cifratura asimmetrica Firme digitaliit Certificati digitali (X509v.3) Specifichechiare hi e formali Negoziazione dei parametri Handshakeal momento dll della connessione Riutilizzo di parametri negoziati in precedenza SSL: funzionalità Componenti di SSL Handshake protocol Permette alle parti di negoziare i diversi algoritmi necessari per la sicurezza delle transazioni Consente l eventuale autenticazione tra le parti Record protocol Si occupa della compressione, del MAC e della cifratura Alert protocol Notifica situazioni anomale o segnala eventuali problemi Change Cipher Spec protocol Impone l esecuzione di un nuovo handshake per rinegoziare i parametri di sicurezza e ripetere l autenticazione Fase 1 Definisce le caratteristiche di sicurezza Fase 2 Authenticazione del server e scambio chiavi server Fase 3 Authenticazione del client e scambio chiavi client Fase 4 Fine Protocollo Handshake Fase I Il client trasmette: 1. Version Più alta versione del protocollo che il client è in grado di capire 2. Random Timestamp di 32 bit e nonce di 28 bit 3. Identificativo di sessione Valore non nullo: Aggiornamento parametri di connessione esistente Valore nullo. Nuova connessione e sessione 4. Elenco delle cipher suite in ordine di preferenza Protocollo per key exchange e altri parametri 5. Elenco di metodi di compresssione supportati Il server trasmette: 1. Version Più alta versione fornita dal client e che il server può supportare 2. Tempo e nonce del server Indipendenti dai parametri omologhi forniti dal client 3. Identificatore della sessione Se il client ha fornito un valore diverso da zero ò lo stesso valore Diversamente proposto dal server 4. Cipher suite (la prima proposta dal client che sia supportata dal server) 5. Metodo di compressione (il primo proposto dal client che sia supportato dal server)
Fase II Certificate: Richiesto in tutti i casi eccetto che per il Diffie-Hellman anonimo Server Key Exchange: Richiesto in tutti i casi eccetto RSA e fixed Diffie-Hellman. Materiale dipendente dal protocollo. Certificate request: Richiede al client un certificato Server Hello Done: Indica la fine dei messaggi del server Fase III Il client verifica il certificato e i parametri del server. Se tutto è soddisfacente trasmette al server 3 pacchetti: Certificate: Se il client richiede una risorsa per cui serve autenticazione Client Key Exchange: Materiale dipendente dal protocollo Certificate verify: Fornisce verifica esplicita del suo certificato Fase IV Change Cipher Spec: Il client copia il pending CipherSpec nel current CipherSpec Finish: Verifica il successo del processo di autenticazione inviando 2 hash Protocollo record Confidenzialità Ottenuta utilizzando un cipher simmetrico con una shared key definita dal protocollo handshake; usa pure una compressione (?) () Integrità Utilizza un MAC con shared key simileahmac Change Cipher Spec: Il server copia il pending CipherSpec nel current CipherSpec Finish: Comunica il successo del processo
Uso diffuso di SSL OpenSSL OpenSSL è un package open source Commercio elettronico Ordinazioni: le form con cui si ordina un prodotto vengono inviate usando SSL Pagamenti: quando viene inserito un numero di carta di credito, l invio dei dati avviene usando SSL Accesso ad informazioni sicure La consultazione di informazioni accessibili solo da utenti qualificati L invioi di password oaltri dti dati riservati E sottoposto a manutenzione continua E utilizzato per lo sviluppo di importanti applicazioni (modssl) Contiene implementazioni di vari algoritmi di crittografia Contiene implementazioni di Big Number, formati DER, PEM, pkcs7, pkcs12. Implementa il protocollo SSL/TLS Ha i comandi per gestire certificati digitali Transport Layer Security (TLS) TLS definito nella RFC 2246 Molto simile a SSL v3 ma migliore per la sicurezza Tolleranza alla criptoanalisi Conforme ai criteri della FIPS 140-2 (Security Requirements for Cryptographic Modules) Diverso progetto di MAC, funzioni hash, etc Oltre ciò Definiti codici di alert addizionali Cambiamenti nei cipher supportati Variazioni sui tipi di certificati e negoziazioni Variazioni sul calcolo dei parametri criptografici CHAP EAP
CHAP CHAP(Challenge Authentication Password Protocol): metodo di autenticazione nel quale è centrale la conoscenza della password dell utente piuttosto che la password stessa. L'autenticatore, vale a dire il server di accesso remoto o il server IAS (Internet Authentication Server), invia una verifica al client di accesso remoto costituita da un identificativo di sessione e da una stringa casuale di verifica così da generare ogni volta messaggi differenti (challenge string) lunda 8 byte (2 64 stringhe possibili) Il client di accesso remoto usa la stringa di verifica e la propria password per calcolare un impronta MD5; invia quindi al Server una risposta che contiene l impronta Il Server, che può accedere alla password dell utente, ri-esegue il calcolo dell impronta e la confronta con quella ricevuta: se coincidono le credenziali di accesso sono considerate autenticate. MS-CHAP Protocollo di autenticazione implementato da Microsoft per l autenticazione di stazioni Windows Remote, è simile a CHAP ma fornisce formati coerenti con i prodotti Windows. Entrambe le versioni permettono la crittografia simmetrica. v1, la prima versione, fa uso di MD4 ed è facilmente violabile. Consente tra l altro la modifica della password. Usa chiavi di 40 bit e dell algoritmo MPPE (Microsoft Point to Point Encryption) v2, la seconda versione, fa uso di MD5 ed è maggiormente protetta non consente la modifica della password fausodi chiavi i diverse per i dtii dati inviatii ericevuti ti(128 bit) realizza un autenticazione duale (del client e del Server) EAP EAP (Extensible Authentication Protocol) è un'estensione del protocollo PPP (Point-to-Point Protocol) in risposta alla richiesta di un sistema di autenticazione di utenti che accedono da un sistema remoto che consenta di utilizzare altri dispositivi di protezione Fornisce un meccanismo standard per il supporto di metodi di autenticazione aggiuntivi nell'ambito delle connessioni PPP Possibile aggiungere supporto per altri schemi di autent. tra cui: Token card Password temporanee Autenticazione i di chiavi i pubblichetramite i smart card Certificati non è moltoutilizzato tili t PPP PPP (Point-to-Point Protocol ) nasce per la gestione di connessioni punto a punto, cioè per consentire la connettività host-host o router-router. Sviluppato come estensione dell HDLC, cerca di risolvere tutti quei problemi a cui SLIP andava incontro e di sopperire alle limitazioni di HDLC Supporta molti protocolli tra cui IP, IPX e ARA. Comprime automaticamente i dati È dotato di meccanismi di autenticazione quali CHAP, PAP ed EAP Due varianti Microsoft: MS-CHAP v1 e MS-CHAP v2 Fornisce un meccanismo di controllo e di gestione degli errori
PPP Garantisce un metodo non ambiguo per la suddivisione e l incapsulamento dei datagrammi Fornisce possibilità di crittografia che prevedono la scelta iniziale dell algoritmo crittografico (DES, 3DES, ecc.) e della chiave (di solito password utente) PPP è il protocollo utilizzato comunemente da Costruttori DSL e Service Provider. Se un programma rispetta gli standard PPP può essere usato per ricevere chiamate e fornire l accesso a internet (come avviene in Windows 2000/2003 server) Viene abbondantemente utilizzato lungo reti Ethernet e ATM, da qui gli acronimi PPPoE e PPPoA