Sistemi di autenticazione. Metodologie di autenticazione. Autenticazione degli utenti. Password (ripetibili) Antonio Lioy < polito.

Transcript

1 LEZIONE 13 Sistemi di autenticazione Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica Cominciamo a usare alcuni dei concetti di sicurezza base per andare a implementare alcune proprietà di sicurezza che avevamo citato come necessarie all'inizio del corso. In questa lezione si parlerà dei sistemi di autenticazione: se non riusciamo a identificare chi sta operando nel sistema (sia esso individuo, programma o nodo di rete) diventa difficile implementare altre funzioni di sicurezza. Metodologie di autenticazione basate su meccanismi diversi ( 1/2/3-factors authentication ): qualcosa che so pippo! (es. una password) qualcosa che posseggo (es. una carta magnetica) qualcosa che sono (es. impronta digitale) possibilità di combinare meccanismi diversi per passare da semplice autenticazione ad identificazione server { UID : f (S UID ) } conservazione dei segreti? verifica della prova? PROBLEMI LATO SERVER Autenticazione degli utenti quando vogliono accedere a risorse su un server richiesta di autenticazione UID richiesta di una prova prova = F (S UID ) trasmissione della prova? PROBLEMI IN RETE utente (UID) segreto (S UID ) conservazione del segreto? introduzione del segreto? PROBLEMI LATO UTENTE Esistono 3 tipologie di dati per autenticare un'entità. Più categorie si usano, più ci avviciniamo all'identificazione. autenticazione: riconoscere chi sta operando in sistema ICT identificazione: saperne l'identità reale (es.: il fatto che qualcuno si identifichi con il mio username e password mi dice che FORSE io mi sia collegato al Portale della Didattica. Però la mia password ce la può avere qualcun altro) Abbiamo un utente identificabile con un user identifier (es.: il mio numero di matricola) che conosce un segreto noto a lui e al server. Dall'altra parte c'è il server che memorizza al suo interno un insieme di coppie (UID, segreto). Il segreto non è conservato direttamente, ma "codificato" con una funzione f. La prova è il risultato di una funzione F applicata al segretodell'utente. Le due funzioni servono una per trasmettere la prova, l'altra per verificare che effettivamente sia corretta (a seconda delle funzioni usate posso ottenere diversi schemi) Dato questo schema generale ci sono una serie di problemi derivanti dal rischio residuo. server { UID : P UID } o { UID : H UID } Password (ripetibili) richiesta di autenticazione UID richiesta della password P UID utente (UID) segreto (P UID ) La password Ci viene data una password che dobbiamo ripetere sempre uguale. Sul server queste password vengono memorizzate in chiaro (semplice ma #nonbene, chiunque ha accesso al server e vede la tabella può sapere le password) o, meglio, ne viene salvato il rispettivo hash (non ci permette di conoscere direttamente le password, un po' meglio di prima ma anche questo ha le sue debolezze). La password viene inviata in chiaro in rete, quindi F in questo caso è la funzione identità. f invece è la funzione identità se ho memorizzato le password tali e quali, o una funzione di hash nel caso siano memorizzate in questo modo.

2 Password ripetibili segreto = la password dell utente (client) creazione e trasmissione prova : F = I (la funzione identità) ossia prova = password (in chiaro!) (server) memorizzazione e validazione della prova caso #1: f = I (la funzione identità) il server conserva le password in chiaro (!), P UID controllo d accesso: prova = P UID? caso #2: f = one-way hash (ossia digest) il server conserva i digest delle password, H UID controllo d accesso: f(prova) = H UID? vantaggi: semplice per l utente conservazione della password lato utente (post-it!) password indovinabile (il nome di mio figlio!) password leggibile durante la trasmissione password o un suo digest non protetto (dictionary attack) Password ripetibili... a condizione che ne abbia una sola! svantaggi: # conservazione/validazione della password lato server il server deve conoscere in chiaro la non usarle :-) Password suggerimenti per renderle meno pericolose: caratteri alfabetici (maiuscoli + minuscoli) + cifre + caratteri speciali lunghe (almeno 8 caratteri) parole non presenti in dizionario cambiate frequentemente (ma non troppo!) uso di almeno una password (o PIN o codice di accesso o...) inevitabile a meno di usare sistemi biometrici < Semplicità di calcolo ma grosso rischio. < Il server non conosce le password in chiaro (le funzioni di hash non sono invertibili). Il prezzo da pagare è che bisogna fare un calcolo un po' più complesso. # Anche usando i digest, occhio che questi devono essere non protetti (plain-hash e non keyed-digest, perchè altrimenti il server dovrebbe avere in chiaro la chiave che serve per il calcolo, quindi siamo punto e a capo). Si può obiettare dicendo che si potrebbero cifrare le password. Questo rende impossibile a chi legge la tabella scoprire le password, però mette il server nella condizione di dover decifrare ogni volta quello che gli arriva. Una soluzione adeguata per proteggere la chiave con cui si proteggono le password cifrate è l'utilizzo di un dispositivo HW, ovvero l'hsm (schede crittografiche dedicate all'operazione di cifratura). Bello, figo, ma sposto solo l'asticella: se mi si rompe l'hsm in cui è memorizzata la chiave sono fregato, dovrei avere un HSM di backup. Il costo ovviamente impenna ABBOMBAZZA. Prima di analizzare i problemi relativi alla sicurezza in rete e lato client, qui ci sono un po' di consigli della nonna sempre utili. E i dizionari sono ben completi, eh. Occhio poi a non esagerare nemmeno. < Alcune idee per non usare una password. Occhio che anche i sistemi biometrici hanno i loro problemi. velocizzabili tramite rainbow table occorre quindi introdurre una variazione Memorizzazione delle password MAI in chiaro! password cifrata? il server deve però conoscere la chiave in chiaro memorizzare un digest della password ma si presta ad attacchi dizionario imprevedibile chiamata salt Una miriade di server memorizza password, quindi bisogna farci attenzione. < La soluzione migliore, oggi come oggi < Per evitare gli attacchi dizionario e arcobaleno bisogna prevedere il sale

3 ipotesi: Attacco dizionario algoritmo di hash noto hash delle password noti / leggibili pre-calcolo: for (each Word in Dictionary) do store ( DB, Word, hash(word) ) attacco: sia HP l hash di una password w = lookup ( DB, HP ) if ( success ) then write ( pwd =, w ) else write ( pwd not in my dictionary ) Rainbow table (I) è una tecnica di trade-off spazio-tempo per memorizzare (e fare lookup) della tabella esaustiva es. tabella per password di 12 cifre esaustiva = righe { P i : HP i } rainbow = 10 9 righe, ognuna rappresenta 1000 pwd usa la funzione di riduzione r : h p pre-calcolo: (NON è h -1 ) CHE NON for ( 10 9 distinct P ) ESISTE! for (p=p, n=0; n<1000; n++) # k = h(p); p = r(k); store ( DB, P, p ) // inizio e fine catena Rainbow table (II) attacco: sia HP l hash di una password for (k=hp; n=0; n<1000; n++) p = r(k) if lookup( DB, x, p ) then exit ( "chain found!" ) k = h(p) exit ( "HP is not in any chain of mine" ) per evitare "fusioni" di catene si usano r 0 r n in vendita tabelle rainbow pre-calcolate per varie funzioni di hash e set di password (es. alfanum) tecnica usata da vari programmi di attacco < Se non lo faccio complico un po' la vita, ma non per tanto Prende tutte le parole all'interno di un dizionario e ne calcola l'hash. A questo punto, se io riesco a prendere un file di password e leggo un hash HP faccio un lookup di HP nel database. Se trovo HP nel database ho fatto bingo. Richiede grosse quantità di memoria e ovviamente se non azzecco la parola è utile quanto un ombrello bucato nella stagione dei monsoni. La tecnica arcobaleno è una tecnica trade-off spazio-tempo. Se io so che c'è una password di 6 caratteri, provo tutte quelle password formate da 6 caratteri (o comunque un sottoinsieme, ad esempio supponiamo 100 possibilità per ogni carattere). Non così infrequente: pensa all'homebanking (password solo numeriche). < Mentre prima ogni riga corrispondeva a una password, qui ogni riga corrisponde a mille password. La funzione di riduzione r, dato un valore di hash, calcola una possibile password. Il precalcolo fatto considera le 10**9 password distinte: a questo punto ogni riga rappresenta 1000 password. Comincio dalla password iniziale, calcolando l'hash di una password e calcolo una nuova password, data da una funzione di riduzione applicata all'hash calcolato. Occhio che in # p a sinistra e p a destra sono diverse. Memorizzo la password da cui ho iniziato e quella finale: tutti gli altri sono impliciti perchè li voglio recuperare Se mi è noto un hash di una password che sono riuscito a sgamare da un server, parto da quell'hash ed esamino se si trova in una catena seguendo l'algoritmo riportato. Se nel database esiste una catena che termina con p ho trovato la catena, altrimenti provo un nuovo k. Si usano tante funzioni r per evitare le fusioni. Se fai un po' di spesa criminale, ti spendi migliaia di euro facili e ti fai spedire un po' di roba a casa, bòn, la trovi. Uso del salt per memorizzare password per ogni utente UID: scegliere / chiedere la pwd generare un salt (diverso per ciascun utente): random (imprevedibile) e lungo (aumenta la complessità del dizionario) meglio se con caratteri poco usati o di controllo calcolare HP = hash ( pwd salt ) memorizzare le triple { UID, HP UID, salt UID } evita di avere HP uguale per utenti diversi ma con stessa pwd grazie al sale! rende praticamente impossibili gli attacchi dizionario (inclusi quelli basati su rainbow table) < Siccome l'utente non lo deve introdurre posso sbizzarrirmi. < Questo non è un keyed digest < Il sale è noto e serve come il vettore di inizializzazione nel CBC: serve a evitare i precalcoli. < Dovrei fare una tabella rainbow per ogni valore del sale. CIAO

4 Attacco a Linkedin giugno 2012, copiate 6.5 M password da Linkedin unsalted, plain SHA-1 hash!!! ricorso a crowdsourcing per fare il cracking delle password almeno 236,578 trovate (prima che venisse bloccato il sito che pubblicava gli hash delle pwd) La soluzione è semplice ma c'è ancora qualche babbo che non la usa. Figura di merda: memorizzavano le password nella maniera più stupida del mondo e mandavano informazioni da uno smartphone (di cui in teoria non gli deve fregare niente) in maniera del tutto scialla. nota: problema quasi simultaneo con scoperta che la app di Linkedin per ipad/iphone mandava dati sensibili (e non di sua competenza) in chiaro da * (per distinguere dal metodo di MySQL < 4.1) esempio (per password "SuperPippo!!!"): *400BF58DFE90766AF20296B3D89A670FC66BEAEC verifica $ echo -n 'SuperPippo!!!' openssl sha1 -binary openssl sha1 -hex (stdin)= 400bf58dfe90766af20296b3d89a670fc66beaec Esempio: password in MySQL username e password nella tabella "user" MySQL (da v4.1) usa un doppio hash (ma non un sale!) per memorizzare la password in modo sicuro sha1( sha1( password ) ) memorizza la codifica hex del risultato, preceduta campo user.password = Sistemi a sfida (simmetrici) una sfida (tipicamente un nonce random) viene inviato all utente che risponde con la soluzione effettuando un calcolo che coinvolge il segreto e la sfida il server deve conoscere in chiaro il segreto spesso la funzione R è una funzione di hash sfida UID utente soluzione = R (sfida, S UID ) { UID : S UID } S UID Mutua autenticazione con protocolli a sfida simmetrici (v1) scambio base solo chi inizia lo scambio indica esplicitamente la propria identità Alice A enc (K AB, S B ) S A S B Bob QUESTA E' ROBA STATE OF THE ART! MALERRIMO! < I bomber pensano di fare sicurezza. E invece no, perchè se uso una rainbow table devo solo calcolare due volte l'hash invece che una. Hanno solo aumentato i tempi di calcolo. -n per togliere gli invii, -binary per dare il risultato in binario. Fino adesso ci siamo concentrati solo sul lato server. Già prima abbiamo identificato il problemone della trasmissione della pwd in rete, e se qualcuno può sniffare la rete può leggere la pwd. Sono stati dunque creati sistemi di autenticazione di vario tipo che ovviano al problema in vari modi. nonce: numero usato una volta sola. Se uso due volte la stessa sfida, l'utente può darmi due volte la stessa risposta e si può sferrare un replay attack. Perchè lo voglio random? Perchè se il nonce fosse prevedibile (es.: data e ora) faccio autenticare l'utente con un nonce "del futuro" su un server fittizio mentre io mi vado ad autenticare sul vero server. Visto che il server conosce per ogni utente la password, se il calcolo che faccio sul server è uguale alla soluzione che mi è stata inviata, allora l'utente la conosce. La password diventa dunque un argomento di una funzione. Il grosso problema della soluzione deriva dal fatto che i segreti vengono conservati in chiaro (non c'è santo che tenga, siccome devo rifare il calcolo devo averle). Gli HSM possono essere predisposti per memorizzare R Attenzione a una serie di dettagli implementativi di protocolli a sfida simmetrici (mutua autenticazione). Alice e Bob vogliono comunicare solo dopo essersi mutuamente autenticati. 1) Alice dice "io sono Alice" 2) Bob chiede una dimostrazione e manda una sfida 3) Alice "fa l'hash" della sfida con una chiave comune ai due 4) Bob fa lo stesso calcolo e si convince che l'altra è Alice 5) Similmente Alice chiede una prova a Bob Questo è un bel modo, implementato però in una forma più semplice perchè vanno trasmessi 5 messaggi. enc (K AB, S A )

5 Mutua autenticazione con protocolli a sfida simmetrici (v2) riduzione del numero di messaggi (migliorano le prestazioni ma non ha impatto sulla sicurezza) usato da IBM SNA A, S A 1) Io sono Alice e questa e la mia sfida per Bob 2) Io, Bob, risolvo la sfida e ti mando una mia sfida 3) Io, Alice, risolvo la sfida Me la cavo con tre messaggi anzichè 5. E' identica a prima, ma diminuisce il numero dei messaggi e si velocizza l'architettura del canale. SNA = architettura di rete per mainframe. Alice S B, enc (K AB, S A ) Bob enc (K AB, S B ) Attacco ai protocolli a sfida simmetrici conn #1 Mike (as Alice) A, S A S B enc conn #2 A, S B enc (K AB, S B ) S B, enc (K AB, S A ) S C, enc (K AB, S B ) Sistemi a sfida (asimmetrici) Bob un numero random R viene cifrato con la chiave pubblica dell autenticando il quale risponde inviando R in chiaro grazie alla sua conoscenza della chiave privata utenti abilitati X.509 cert (Lioy, KpubLioy) sfida = E (R, KpubLioy) soluzione = R utente chiave privata e lo sfidante invia R in chiaro e lo richiede cifrato con la chiave privata... allora lo sfidato ha inconsapevolmente firmato il documento!!! Attacco Marzullo (mi faccio una domanda e mi dò una risposta) Pericoli delle sfide asimmetriche fiducia nella CA che ha emesso il certificato verifica del name costraint sulle CA accettate possibilità di far deporre una firma RSA inconsapevolemente: se R=digest(documento)... 1) Mike dice "Ciao, sono Alice e questa è la mia sfida" 2) Bob risponde e a sua volta inoltra una sfida 3) Mike prepara un trucchettino: prende la sfida che Bob gli ha mandato, a cui non sa rispondere... 3) Apriamo un secondo collegamento verso Bob in cui gli dico "Ciao, sono Alice e questa è la mia sfida" (in realtà è quella di Bob) 4) Bob risponde facendo la cifratura della sua stessa sfida, rispondendosi da solo 5) Prendo la sfida che ha risolto Bob per me (gran bomberata) e sul primo collegamento che avevo aperto gli mando la prova di essere Alice. Il collegamento #2 verrà interrotto perchè si penserà a un attacco di rete, ma in realtà Mike ha tirato su un bel trick per connettersi come Alice. Il problema nasce dal fatto che la chiave è simmetrica. La soluzione sarebbe avere due chiavi note a entrambi, ma usate in opportuni versi. Per risolvere i problemi dei sistemi a sfida simmetrici vengono introdotti i sistemi a sfida asimmetrici. L'ipotesi ora è che l'utente disponga di una certa chiave privata e il server abbia l'elenco degli utenti abilitati ad accedere al servizio. 1) Lioy: "Sono Lioy, questo è il mio certificato con public key" 2) Server: "Sì, dai, ciao. La chiave pubblica la sanno tutti. Prendo un numero random, lo cifro con la tua chiave privata e te lo mando come sfida. Se sei veramente Lioy sai la tua chiave privata e puoi inviarmi il numero R" 3) Lioy: "Miscredente, ecco R!" Sistema estremamente forte. Sul server non sono memorizzate informazioni critiche, tranne gli utenti abilitati: non dovrà più essere segreto ma dovrà godere delle proprietà di autenticazione e integrità (non può entrare chiunque ad aggiungermi utenti, nè me li posso far modificare o eliminare). 1) Devo configurare correttamente le CA che possono emettere certificati per gli utenti che voglio accettare 2) Se io accetto la CA del PoliTO e la CA del PoliMI devo accertarmi che ognuna operi solo sul suo bacino di utenza 3) Se rispetto alla precedente slide implementiamo uno schema del tipo: 1) il server manda R in chiaro 2) chiede all'utente di cifrare R con la chiave privata 3) il server decifrerà con la chiave pubblica potrei incappare in server amici della procura che mi mandano numeri random che in realtà sono digest di documenti, e io ne faccio una firma RSA. In X509 c'era un campo Extended Key Usage: buona norma dunque dare agli utenti diverse chiavi private, differenti per Server autentication e Digital Signature. Così anche se un server fa l'infame se la becca con sabbia (firma apposta con una chiave non adatta)

6 server Password usa-e-getta richiesta di autenticazione UID richiesta della password n. 48 utente (UID) Un'altra possibilità per risolvere lo sniffing della password è fartela vedere, perchè tanto anche se la vedi è usa e getta. Questo è nientemeno il sistema con le chiavettine dell'home banking quando vengono fatti i bonifici. Come fa però il server a sapere qual è la password 48? O il server ha tutto l'elenco delle password di un utente (ciao!) o più semplicemente il server contiene coppie (utente, segreto) e una funzione p con le quali sono state generate le password. UID : S UID P48 = p ( 48, S UID )? P48 UID P50 UID P49 UID P48 UID P47 UID P46 UID... Il server diventa il punto di debolezza perchè contiene i segreti in chiaro. Questo schema è concettuale, ci sono sistemi per implementarlo in modo sicuro. Password usa-e-getta OTP (One-Time Password) idea originale: Bell Labs (braccio di ricerca AT&T) sistema S/KEY implementazione di pubblico dominio implementazioni commerciali con generatori automatici hardware (autenticatore) Come fornire password OTP agli utenti? per uso su postazioni stupide o insicure: password pre-calcolate e scritte su un foglio autenticatori hardware (criptocalcolatrici) per uso su postazioni sicure e intelligenti: programmi di calcolo eventualmente integrati col sw (telnet, ftp,...) o hw (modem) di comunicazione < Semplici terminali (oppure sono a un Internet cafè, un po' come andare a zoccole) Macchinettine che mi fanno un calcolo < Magari il mio laptop o il mio smartphone RFC-1760 P 2 = h (P 1 ) = h( h(s) )... l utente inizializza il server di autenticazione con questa password non verrà mai usata direttamente per l autenticazione, ma solo indirettamente Il sistema S/KEY (I) l utente genera un segreto S l utente calcola N one-time password: P 1 = h (S) idea originale dei Bell Labs l ultima password (es. P 100 ) S/KEY risolve il problema "il server è attaccabile perchè ha le password in chiaro". L'utente si genera da solo un segreto S e un tot. di one time password secondo lo schema qui riportato. L'utente prende l'ultima password e la manda al server. Questa password non verrà mai usata per l'autenticazione.

7 Il sistema S/KEY (II) il server chiede le password in ordine inverso: S: P99? C: X S: se h(x) = P100 allora accesso OK + memorizza X in questo modo: il server non deve conoscere il segreto del client solo il client conosce tutte le password RFC-1760 usa MD4 (possibili altre scelte) Questo perchè il meccanismo funziona così: il server contiene al suo interno la password 100 e chiede all'utente la 99. Il server deve controllare se X fornita dall'utente è veramente P99 e allora prende X e ne fa l'hash. Se H(X) = P100, allora X = P99. Sul server ora mi salvo P99 e la prossima volta ti chiedo la 98. implementazione public-domain per Unix, MS-DOS, Windows, MacOs Il sistema S/KEY (III) Rappresentazione grafica di quanto abbiamo detto. P N = h N (s) h l'utente ha il server ha P N-1 = h N-1 (S) P N-1 P N-1 P N store P N-1 P 2 = h(h(s)) = h 2 (S) P 1 = h(s) initial secret S user password generation h h minimo 8 caratteri P N-2 autenticazione S/KEY S/KEY generazione delle password l'utente inserisce una pass phrase (PP) la PP viene concatenata con un seme (seed) inviato dal server il seme non è segreto (inviato in chiaro da S a C) permette di usare la stessa PP per server diversi (usando diversi semi) e ri-usare in modo sicuro la stessa PP cambiando il seme viene fatto l hash MD4 ed estratto un risultato su 64 bit (effettuando un EX-OR tra primo e terzo gruppo di 32 bit, e tra secondo e quarto gruppo) L'ipotesi che stiamo facendo in questa slide è che l'utente non voglia scriversi le password (perchè magari non ha voglia di portare in giro il bigliettino), ma che si sia fatto un suo programmino di calcolo in cui, a partire da una passphrase, vengono fatti un tot di calcoli per avere Pxy. S/KEY password 64 bit di lunghezza della password sono un compromesso non troppo lunga né troppo insicura possibile inserirla come sequenza di 6 parole inglesi corte scelte da un dizionario di 2048 (es: "A", "ABE", "ACE", "ACT", "AD", "ADA") client e server devono avere lo stesso dizionario Siccome gli utenti non sono bravi a scrivere bit le password vengono scelte come riportato qui.

8 Problemi delle OTP scomode da usare in assoluto scomode da usare per accesso a servizi multipli basati su password (es. POP con check periodico della posta) costose se basate su autenticatori hardware non possono essere usate da un processo ma solo da un umano generazione di buone password random password provisioning (generatore? SMS?) quando per generare le OTP si usa data ed ora, è importante la sincronizzazione temporale tra client e server Problemi degli autenticatori hardware denial-of-service: tentativi falliti appositamente per negare l accesso social engineering: telefonata per denunciare smarrimento e chiedere l inizializzazione di una nuova carta L'utente non può basarsi sulla sua memoria. LEZIONE 14 OTP mi servono quando faccio operazioni estemporanee e non per cose in cui invece faccio operazioni ripetute Se ci basiamo sugli autenticatori HW uno dei problemi tipici è relativo agli attacchi DoS. Ci sono anche tecniche di social engineering ("ho perso il dispositivo, sono in viaggio, dimmi come posso fare per inizializzarne un altro...") Password (usa-e-getta con autenticatore) richiesta di autenticazione server utente (UID) UID richiesta della password delle 11:07 P1107 UID : S UID UID P1107 = p ( 11:07, S UID )? Oggetti che ci vengono dati e sul quale compare la OTP da inserire per fare accesso. 1) Richiesta di autenticazione 2) L'utente comunica UID 3) Autenticazione basata su data e ora: dimmi la password valida alle 11:07 4) Invio password delle 11:07 Per fare il controllo, il server mantiene una tabella di segreti u- tente che serve per fare i calcoli e verificare se la password digitata è corretta. Questi oggettini non sono altro che criptocalcolatrici in cui abbiamo, oltre a un "orologino", anche il segreto precablato (e impossibile da cambiare). Va da sè, dunque, che l'unico attacco sferrabile è quello al server. 8 cifre decimali casuale, non ripetibile deriva massima di 15 s / anno validità massima 4 anni basato su algoritmo di hash proprietario RSA SecurID inventato e brevettato da Security Dynamics meccanismo OTP di tipo sincrono: P UID ( t ) = h ( S UID, t ) codice di accesso ( token-code ): cambia ogni 60 s E' l'oggetto più famoso appartenente a questa categoria. Dopo quattro anni l'orologio può sgarrare di 60 secondi. Siccome non mi sogno minimamente di reinizializzarlo, dopo quattro anni lo prendo e lo butto. Algoritmo proprietario per cercare di rendere più difficile la vita agli attaccanti.

9 SecurID: architettura il client invia al server in chiaro user, PIN, token-code (seed, time) in base a user e PIN il server verifica contro tre possibili token-code: TC -1, TC 0, TC +1 duress code: PIN che fà scattare un allarme (utile sotto minaccia) limite al numero di tentativi di autenticazione errati (default: 10) possibile avere tre diverse chiavi di accesso (per tre diversi sistemi) scarsamente utile data l'architettura SecurID: hardware SecurID Card (es. SD200): carta classica SecurID PinPad (es. SD520): introduzione del PIN ed invio solo di user e token-code* SecurID Key Fob (es. SD600, SID700): portachiavi SecurID Key Fob and smart-card (es. SID800) Lo schema è a due livelli, in quanto il token code è qualcosa che io possiedo (posso anche averlo lasciato sulla scrivania e qualcuno se lo legger), mentre il PIN è qualcosa che io ho nella mia mente. TC0: i due orologi sono perfettamente sincronizzati? Però se siamo un po' fuori fase il server confronta anche coi token code del minuto precedente e del minuto successivo. Viene associato anche un duress code, un cosiddetto codice di resistenza: è un PIN che fa fare autenticazione ma fa scattare l'allarme (mi stanno facendo fare un bonifico con una 44 Magnum puntata e dunque mi autentico a sgamo col PIN con cui lancio una richiesta d'aiuto). Per evitare tentativi esaustivi, dopo 10 tentativi l'accesso viene bloccato (pone problemi DoS). In figura: - in basso a sx la carta classica: introduco user, PIN e leggo il numerino - in basso a dx: batto il PIN direttamente sull'asterisco, mi viene mostrato un token code che "ingloba" il PIN. Posso avere bisogno di una cosa del genere da un terminale non sicuro (perchè magari sotto ci gira un keylogger). - in alto a sx: autenticatore portachiavi, che almeno non te lo dimentichi. Ci sono anche quelli che includono una smart card. SecurID: autenticatori software SoftID come un PinPad ma sw trasmissione automatica o manuale del risultato problema: sincronizzazione dei clock Esiste anche la versione software che è stata fatta per cercare di ridurre i costi. Cosa che puoi installare se hai un ambiente che ritieni sicuro. Problemi se l'utente se ne strasbatte del protocollo NTP. Se la mia ora è sbagliata di più di 60 secondi rispetto a quella del server non riuscirò mai a fare autenticazione. RSA SecurID: prodotti recenti

10 token OK? TELNET server SecurID: architettura ACE client user, PIN, TC TELNET client SecurID (normale) ACE server token OK? ACE client OK! KO! Server DBMS applicativo server = Client del user, TC* servizio di autenticazione SecurID: client Client applicativo DBMS client SecurID (pinpad) Dietro SecurID c'è un'architettura di autenticazione. Quindi non soltanto un protocollo che permette al client di autenticarsi con un server, anche perchè magari voglio autenticarmi con N server e quindi voglio avere un sistema comune che semplifica l'autenticazione Scenario tipico aziendale: ho i miei N server, su cui installo un software che RSA è ben lieta di fornirmi (Access Control Engine). Gli ACE da una parte dialogano con i SecurID che il client userà e dall'altra dialogano con un ACE Server, siccome il singolo server non sa bene come interpretarli. E' l'ace Server a conoscere tutti gli utenti, tutti i PIN, tutti i token code: a domanda, risponde ("sì, tutto bene", "no, qualcosa è sbagliato"). Architettura importante perchè siccome in azienda abbiamo un bel po' di server li vorrei anche gestire con un minimo di sicurezza. ACE/client gestisce il dialogo con l ACE/server canale crittografato e protetto sd_ftp per FTP sicuro disponibile per: Unix Win32 Netware Macintosh TACACS ACE/server: autenticazione con SecurID monitor, audit e report interfaccia di gestione GUI authentication API SecurID: server interfaccia SQL per accesso ad un DBMS avente i dati degli utenti vasto supporto commerciale sia per prodotti di sicurezza (es. firewall) sia di comunicazione (es. comm. server) disponibile per Solaris, AIX, HP-UX, NT, 2000, XP server 3. generazione dati authn una varietà di piattaforme Autenticazione out-of-band 1. richiesta di autenticazione 2. UID + P UID 5. OOB data utente (UID) segreto (P UID ) Monitor: controllare chi si sta collegando Audit: vedere che cosa è capitato in passato, chi si è collegato o meno e generare report API di autenticazione: se io voglio fare una mia app posso chiamare l'api per sapere se i parametri che ho passato mi consentono di fare autenticazione. Interfaccia SQL per acquisire gli utenti da un'altra base dati e- sistente. Siccome è stato stramegavenduto ha suscitato l'attenzione di molti cattivi: un po' criticato perchè si basa un pochino su Security Through Oscurity, ma alla fine si è riusciti ad attaccarlo con un attacco di social engineering. Molte aziende, per non gestirsi loro tutta la struttura, decidono di far gestire gli ACE Server a RSA (e dunque è RSA che ha le chiavi che vanno dentro ai vari token). Attaccato un responsabile di RSA tramite una finta mail, scippati un sacco di segreti delle banche. Quando lo si è notato, l'unica soluzione è stata quella di dire: prendete i token e NON UTILIZZATELI PIU' (chiunque conosce Suid può generare una finta risposta). Danno sia di immagine che economico. Un'altra possibilità per fare autenticazione OTP è fare autenticazione out of band. 1) Richiesta di autenticazione 2) Username e password (trasmissione non sempre sicura) 3) Genero dati OOB... 4)...e glieli mando sul cellulare tramite un SMS 5) L'utente prende gli OOB data ricevuti e li manda come conferma (tipo come fa Postepay quando lavori su poste.it) Anche la conferma può essere inviata OOB se proprio sono un paranoico. In questo modo ho uno schema simile a quello di prima ma senza programmini e oggettini "avanzati". 4. trasmissione OOB

11 Autenticazione di esseri umani come essere certi di stare interagendo con un essere umano e non con un programma (es. che invia una password memorizzata in un file)? due soluzioni: tecniche CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) es. immagini di caratteri distorti tecniche biometriche es. impronte digitali qui in teoria ho anche una specie di autenticazione scansione della retina scansione della pupilla scansione delle vene delle mani utili per sostituire *localmente* un PIN o una Sistemi biometrici misurano una caratteristica biologica dell utente principali caratteristiche usate: impronte digitali voce password : se io prendessi la mia impronta digitale e la mandassi a un server per fare la verifica, comincerebbe tutta la serie di problemi (devo mandarla cifrata, ci dev'essere un DB e blabla... E se ce la rubano? Mi taglio il dito?) Problemi dei sistemi biometrici FAR = False Acceptance Rate FRR = False Rejection Rate Caratteristiche univoche di un essere umano FAR e FRR sono in parte aggiustabili ma dipendono moltissimo dal costo del dispositivo caratteristiche fisiche variabili: ferita su un dito (più dita per fare il login) voce tremante per l emozione vasi oculari dilatati per alcool o droga Occhio che tanti lettori di impronte digitali USB che vengono venduti hanno una qualità pari a quella delle sorpresine dell'ovetto Kinder. Qualcuno tipo lo freghi con un pezzo di plastilina appiccicato su un bicchiere che "prende" l'impronta, altri sono un po' più fini (ad esempio rilevano se nel mentre scorre sangue, se ti hanno tagliato il dito, la temperatura e altre robe da 007) Mentre per le password non ci sono cazzi (o sono giuste o sono sbagliate), per le credenziali biometriche c'è sempre un certo grado di approssimazione: ad esempio è difficile mettere il dito sempre nello stesso modo, fare sempre la stessa pressione. Di più: se bevo un po' o pippo qualcosina ho alterazioni psicofisiche che se interpreto alla lettera mi danno errore di autenticazione. FAR: "ah sì sì sei Maradona", e invece sei il fratello scarso FRR: "sì, vabbè, come no, Maradona", e invece sei proprio lui Sono in parte aggiustabili facendo tuning (ci sono dieci persone? Generati una classificazione in modo da cavartela bene), però se devi gestire un sacco di utenti non ce ne esci più. FAR / FRR Rappresentazione grafica di FAR e FRR. Due gaussiane, ma si sovrappongono: c'è un'area in cui devo decidere. A seconda di dove sposto la linea posso tagliare un certo numero di impronte ok o accettare impronte che non sono ok. Dispositivi biometrici dunque tutt'altro che precisi.

12 Problemi dei sistemi biometrici accettazione psicologica: timore di essere schedati paura di danneggiamento mancanza di API / SPI standard: alti costi di sviluppo dipendenza da un solo fornitore in corso di sviluppo una API / SPI standard ed unitaria basata su CDSA < Ho implementato un nuovo dispositivo biometrico. Come faccio a interfacciarmi con il database, che formato hanno i dati,...? Non c'è uno standard nè API, nè SPI (per i server). API? SPI? middleware! APP1 APP2 API (Application Programming Interface) Questa slide è per fare un po' di chiarezza su SPI. Si immagini di avere N dispositivi fatti da N aziende, ognuno dei quali ha il suo determinato driver e il suo modo di inviare i dati. Lo stesso problema è nato quando sono nate le stampanti: faccio una tabella Excel e devo vedere quali stampanti erano compatibili, perchè lo sviluppatore applicativo aveva dovuto mettere, dentro il software, la modalità di comunicazione con tutte le stampanti supportate. middleware (es. CDSA) SPI (Service Programming Interface) dispositivo / servizio n. 1 dispositivo / servizio n. 2 dispositivo / servizio n. 3 Kerberos Tante parole su vari schemi. Consideriamo una architettura di autenticazione famosissima e usata ancora oggi in vari sistemi. sistema di autenticazione basato su una terza parte Per capire Kerberos è bene entrare un po' nell'ambiente in cui fidata (TTP = Trusted Third Party) è stato sviluppato: siamo al MIT, costi elevatissimi solo per le sviluppato nel progetto Athena al MIT iscrizioni ma si offrono servizi molto buoni agli studenti. Vari mainframe ai quali gli studenti da remoto si collegano con terminali per fare esercizi. A un certo punto è cambiata l'architet- password mai trasmessa ma solo usata localmente come chiave di crittografia (simmetrica) tura: non più terminali, ma PC. Problema enorme perchè può realm = dominio di Kerberos, ossia insieme di sistemi che usano Kerberos come sistema di autenticazione inficiare la sicurezza di tutta quanta l'architettura. Sviluppata una serie di architetture per fare uno schema distribuito che garantisse una certa sicurezza. Kerberos era dedicato all'autenticazione. Tanti anni fa la cifratura asimmetrica era troppo len- credenziale = user.instance@realm Forma con cui l'utente si presenta: questo utente opera ta, quindi ci si basa su cifratura simmetrica. Ogni utente ha uno all'interno di questo realm e ha questa istanza (ognuno username e una password, ma la password non viene mai trasmessa in rete. di noi quando opera in un sistema informatico ha diversi ruoli: tu sei Lioy e ti viene dato un modo veloce per "cambiare cappello". Concetto disponibile in Kerberos, ma le applicazioni non hanno seguito il concetto, quindi il secondo pezzo non si usa) Kerberos Introducendo architetture middleware come questa siamo riusciti a semplificare il problema. Come? Il middleware, ad es. CDSA, dispone di due interfacce: da una parte le API, dall'altra SPI, interfaccia standard in cui tu, creatore di un dispositivo/ servizio, configuri il tuo driver in modo da parlare con le chiamate necessarie definite da SPI. Dall'altra parte, tu, sviluppatore di applicazioni, chiami le API (interfaccia per lo sviluppatore di applicazioni). In questo modo la mia applicazione è indipendente dai dispositivi. Possibilità commerciali migliorate. ticket struttura dati che autentica un client nei confronti di un server durata variabile (V4: max 21 ore = 5 x 255) (V5: illimitata) crittografato con la chiave DES del server a cui è destinato legato all indirizzo IP del client legato ad una sola credenziale autenticazione semplice o mutua Nelle implementazioni attuali DES è stato sostituito con algoritmi sempre simmetrici ma più forti.

13 K UID, K TGS AS Organizzazione di Kerberos Authentication Server { TGT } TGT K S TGS Ticket Granting Server Abbiamo un client e un server applicativo "kerberizzato" e due concetti fondamentali: - AS: server che autentica gli utenti - TGS: server che emette i ticket per usare specifici servizi applicativi AS è fondamentale perchè contiene in chiaro le chiavi di tutti gli utenti. In più contiene la chiave simmetrica del TGS. Il TGS a sua volta contiene le chiavi di tutti i servizi. Queste due macchine sono da proteggere in maniera assoluta. richiesta C client server-id client-id client-address timestamp life K S,C C client KS client T s T s Kerberos: formato dei dati (v4) Richiesta del TGT C, TGS { K C,TGS, { T C,TGS } K TGS } K C Richiesta del Ticket s, { T C,TGS } K TGS, { A C } K C,TGS { { T C,S } K S, K C,S } K C,TGS (application) server Il ticket, sia esso TGT o destinato a uno specifico server, è cifrato in modo simmetrico con una specifica chiave Ks che è quella del server a cui è destinato. All'interno ho vari ID (per il client si mette anche l'indirizzo di rete, per "evitare" di usare ticket su nodi di rete diversi). Ksc è una chiave simmetrica condivisa tra il server e il client, che NON viene negoziata tra i due, ma generata da un terzo fidato (TTP) TICKET AUTENTICATORE < emissione < durata BBBBBBBBBB BBBBBBBBBBB client-id client-address timestamp K S,C A S Authentication Server T G S Ticket Granting Server 1) Sono Tizio, voglio usare un servizio kerberizzato. Richiesta all'as. 2) AS dice "ok, non so se sei tu, ti mando un Ticket Granting Ticket - che serve a prendere il ticket - e questo TGT ti viene trasmesso cifrato con la tua password". Quando mi arriva decifro localmente e se la password è giusta sono in grado di estrarre il TGT. 3) Prendo il TGT e lo mando al TGS, questo dimostra che sono Tizio. Il TGS mi chiede a quali servizi voglio accedere e mi fornisce il ticket specifico per un determinato servizio. 4) Voglio accedere a un determinato servizio? Trasmetto il ticket al server per quel servizio. Il server verifica che il ticket sia giusto, fornirà il servizio ed eventualmente farà mutua autenticazione. Se il client è sicuro allora il sistema è sicuro. Quello che ci viene naturale dire è che il sistema è soggetto ad attacchi di tipo replay, perchè siccome il TGT viene mandato in chiaro al TGS lo intercetto e poi ne faccio replay. Oppure posso intercettare il ticket che viene mandato ai server applicativi. In realtà TGT e TGS sono costruiti con una serie di crittografia simmetrica che consentono di sconfiggere questi attacchi di tipo replay. Sistema abbastanza complesso. Attacchi evitabili se si fosse potuto usare la cifratura asimmetrica. LEZIONE 16 L'autenticatore è una struttura dati, anch'essa cifrata, che viene scambiato tra client e server e dev'essere cifrato con la chiave comune. Timestamp: emissione Se voglio usare servizi kerberizzati devo procurarmi i ticket, ma prima di tutto i superticket. 1) Client contatta AS: "Sono il client con username C e voglio il ticket per parlare col TGS" 2) AS che conosce le password di tutti gli utenti prepara un pacchetto cifrato con la password del cliente. AS non sa chi ha fatto questa richiesta, ma se tu sei il reale utente riesci a decifrare (possibile attacco: mando tante richieste per fare un DoS > ci sono alcune implementazioni di Kerberos che limitano il numero di richieste fattibili). 3) Client decifra: trova la chiave (C, TGS) generata dall'as (terzo fidato) affinchè C possa parlare con TGS. In più la parte BBB è un blob binario: è un oggetto che il client può prendere e trasmettere, perchè è cifrato con la chiave del TGS a cui è destinato. Il client si tiene la chiave, prende il TGT e lo manda al TGS. 4) Client deve contattare TGS per dirgli che ha bisogno di ticket specifici per un determinato servizio S. Per dimostrargli la sua identità gli manda il TGT estratto al pt. 3. In più, siccome in questo modo potrei fare un replay, devo dimostrare di non aver copiato BBBBB da una transazione precedente, ma l'ho effettivamente estratto dalla risposta. Per dimostrarlo è sufficiente cifrarlo con la chiave generata dall'as (C, TGS). Questa chiave era contenuta nel pacchetto precedente. TGS quando riceve il pacchetto, prima ancora di fare tutto, va a vedere se l'autenticatore è valido o meno. Il TGS ovviamente sa la sua chiave e può trovare K(C,TGS). Nel momento in cui la trova, può leggere Ac (chi è il client, da quale IP arriva e quando è stato generato questo autenticatore? Smonto gli attacchi replay!) 5) Ora sostanzialmente si ripete lo stesso schema: TGS conosce tutte le chiavi. Genera un pacchetto cifrato con la chiave comune tra i due in cui c'è la chiave generata come terzo fidato e un blob (il ticket specifico per quel servizio)

14 C client Uso del Ticket { T C,S } K S, { A C } K C,S { timestamp(a C ) + 1 } K C,S Non c'è un motivo fondamentale al riguardo del +1. Protocollo deciso così, bon. server (applicativo) S 6) 7) 8) Io client vado dal server specifico per ottenere quel dato servizio. Mando il ticket (e per dimostrarlo mando un autenticatore cifrato con la chiave comune tra me e il server). Il server conosce Ks. Dal ticket estrae Kcs e da Ac estrae i dati dell'autenticatore. Se io client voglio fare mutua autenticazione chiedo al server di mandarmi il timestamp che c'era in Ac incrementato di 1 cifrato con la chiave comune tra client e server. Se S fosse un impostore non potrebbe generare quella risposta. Questi schemi evitano attacchi replay sia per la modalità d'uso delle chiavi crittografiche, sia perchè contengono timestamp che limitano la riusabilità degli oggetti. Versioni di Kerberos MIT V4 (originale) La prima resa pubblica. MIT V5 (RFC-1510) non solo DES Si può usare qualunque a. simmetrico. durata maggiorata (inizio-fine) Esplicitata. inter-realm authentication forwardable ticket ticket estesi OSF-DCE basata su MIT V5 protocollo a messaggi implementato come RPC invece che come Problemi di Kerberos richiede la sincronizzazione dei clock all interno di una LAN è una cosa comunque utile in WAN crea problemi Kryptoknight (alias IBM NetSP) ha rimosso questa limitazione accesso remoto richiede password in chiaro canale cifrato oppure integrazione con OTP, sfida, o chiave pubblica modem in dial-up Kerberizzati Se gli AS si sono mutuamente fidati l'uno dell'altro hanno definito delle chiavi per più reami. Ticket trasmettibile a un diverso nodo di rete e utilizzato localmente su di esso Qui dentro ciascun implementatore può metterci informazioni addizionali (usabile nel bene e nel male) Non più utilizzata, saltare questo pezzetto. Attacchi di tipo replay risolti ma usando timestamp. I clock dei vari nodi dunque devono essere perfettamente sincronizzati (e questo è IMPOSSIBILE anche in una rete locale con NTP, ci vuole dunque una certa tolleranza). La sincronizzazione LAN è comunque utile per ragioni forensiche. Nelle reti geografiche gli UTC magari si interpretano con fantasia e son dolori. Problema serio quando abbiamo client che si collegano saltuariamente. Un secondo problema è dato dal fatto che Kerberos funziona bene ed è utilissimo se il punto di partenza da cui l'utente fa il login è una postazione kerberizzata. Molte persone agiscono da casa, faccio telnet verso la postazione kerberizzata e la mia password viaggia sulla rete geografica: attacchi di sniffing! O uso canali cifrati, o roba OTP oppure (esistiti per un po' di tempo) modem kerberizzati. il meccanismo dei ticket è ideale per connessioni computer portatili ISDN, WiFi, UMTS crescente supporto commerciale (MS usa Kerberos* a partire da Windows-2000) Vantaggi di Kerberos = SSO (Single Sign On) login unico per tutti i servizi kerberizzati K-POP, K-NFS, K-LPD K-telnet, K-ftp K-dbms intermittenti Siccome ai tempi si pagava in base al tempo per il quale stavo collegato erano frequenti le connessioni+disconnessioni. In uno schema normale dovrei ogni volta fare login. Visto che i ticket di Kerberos hanno una durata posso anche scollegarmi dalla rete senza rifare tutta la procedura. Se io faccio una rete con Windows uso Kerberos. O meglio, una versione *, secondo la classica strategia di Microsoft implement & extend (ci metto qualche chicca che mi rende incompatibile con gli altri). Sostanzialmente ci sono ticket estesi con informazioni tipiche degli account Win. Se uso un AS Win, Unix che non richiede ticket estesi scarta quella parte lì e funziona bellamente. Tecnica per accaparrarsi il mercato server.

15 vero SSO: SSO (Single Sign-On) fornire all utente un unica credenziale con cui autenticarsi per tutte le operazioni su qualunque sistema SSO fittizio: client per sincronizzazione/gestione automatica pwd (alias password wallet ) specifico per alcune applicazioni tecniche di autenticazione multiapplicazione (es. sistemi a sfida asimmetrici, Kerberos) quasi sempre richiede modifica delle applicazioni SSO multi-dominio (es. con token SAML) Interoperabilità dell autenticazione OATH ( interoperabilità dei sistemi di autenticazione basati su OTP, sfida simmetrica e asimmetrica definizione degli standard per il protocollo clientserver e per il formato dati sul client SSO: straganzo e usatissimo in azienda perchè le aziende hanno un sacco di applicazioni che gli utenti devono usare. Un vero incubo gestire le varie user/pwd. Così invece posso dare un'unica credenziale. Proposte diverse soluzioni. - SSO fittizio: c'è un database che sa, per ogni utente che si logga con una data pwd, quali sono le credenziali da usare per una data app. Password wallet implementato su una serie di browser (sul sito di Unicredit, ad esempio, non funziona). - vero SSO: l'architettura di autenticazione è pensata in modo unitario. Concettualmente molto semplice, ma prezzo da pagare altissimo e l'azienda è restia a cambiare il suo parco applicativo se funziona. Nascono problemi di SSO multidominio (fattibile con varie soluzioni, del tipo SAML). Anche rimanendo all'interno di uno specifico protocollo di autenticazione abbiamo un problema. Moltissime soluzioni di autenticazione sono infatti proprietarie: qui abbiamo illustrato i concetti, ma ognuno si definisce il suo protocollo (così compro tutto da un fornitore). E' dunque partita un'iniziativa OATH per garantire interoperabilità. all users all networks universal strong authentication Specifiche OATH HOTP (HMAC OTP, RFC-4226) all devices TOTP (Time-based OTP, RFC-6238) OATH challenge-response protocol (OCRA, RFC-6287) Portable Symmetric Key Container (PSKC, RFC-6030) formato XML per un contenitore di chiavi atto a trasportare chiavi simmetriche ed i relativi meta-dati Dynamic Symmetric Key Provisioning Protocol (DSKPP, RFC-6063) protocollo client-server per fornitura di chiavi simmetriche ad un motore crittografico da un key server