Tecniche e sistemi di autenticazione. Definitions of authentication. Definitions of authentication. Antonio Lioy - Politecnico di Torino ( ) 1

Transcript

1 Tecniche e sistemi di autenticazione Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica Definitions of authentication RFC-4949 (Internet security glossary) "the process of verifying a claim that a system entity or system resource has a certain attribute value" whatis.com: "the process of determining whether someone or something is who or what it is declared to be" NIST IR 7298 (Glossary of Key Information Security Terms) "verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system" Definitions of authentication authentication of an "actor" human being (interacting via sw running on hw) software component hardware element (interacting via sw) shorthand: authn different from authorization (authz) but related Antonio Lioy - Politecnico di Torino ( ) 1

2 knowledge Authentication factors pippo something only the user knows, e.g. static pwd, code, personal identification number ownership something only the user possesses, e.g. token, smart card, mobile phone inherence something the user is, e.g. biometric characteristic (such as a fingerprint) Authentication factors: risks knowledge (e.g. password) risks = storage and demonstration/transmission ownership (e.g. smartphone) risks = authenticator itself, theft, cloning, unauthorised usage inherence (e.g. biometrics) risks = counterfeiting and privacy cannot be replaced when "compromised" (big problem!) use it only for local authentication, as a mechanism to unlock a secret or a device Digital authentication model (NIST SP800.63B) authenticated session Relying Party success subscriber success authenticator enrollment / issuance applicant CSP enrollment & identity proofing claimant authn protocol validate the binding authenticator : credential authn assertion Verifier attributes Antonio Lioy - Politecnico di Torino ( ) 2

3 Digital authentication: entities CSP (Credential Service Provider) will issue or enrol user credential verify and store associated attributes Verifier executes an authn protocol to verify possess of a valid authenticator and credential Relying Party (RP) will request/receive an authn assertion from the Verifier to assess user identity (and attrributes) these roles may be separate or collapsed together Autenticazione degli utenti server richiesta di autenticazione UID utente (UID) { UID : f (S UID ) } richiesta di una prova prova = F (S UID ) segreto (S UID ) conservazione dei segreti? verifica della prova? conservazione del segreto? introduzione del segreto? trasmissione della prova? Password (ripetibili) server richiesta di autenticazione UID utente (UID) { UID : P UID } o { UID : H UID } richiesta della password P UID segreto (P UID ) Antonio Lioy - Politecnico di Torino ( ) 3

4 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 Password ripetibili... a condizione che ne abbia una sola! svantaggi: conservazione della password lato utente post-it! client-side password manager o wallet password indovinabile (il nome di mio figlio!) validazione della password lato server il server deve conoscere in chiaro la password o un suo digest non protetto (dictionary attack) Altri problemi delle password pwd sniffing attacchi al DB delle pwd (se il DB contiene le pwd come plaintext o offuscate) pwd guessing (molto pericoloso se fatto offline, es. contro una lista di hash delle pwd) pwd duplication (usare la pwd scoperta per un servizio contro un altro, causa il riuso della pwd da parte degli utenti) cryptography ageing (necessaria flessibilità sugli algoritmi per parare nuovi attacchi e più potenza) pwd capture via server spoofing o phishing attacchi MITM Antonio Lioy - Politecnico di Torino ( ) 4

5 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!) non usarle :-) uso di almeno una password (o PIN o codice di accesso o...) inevitabile a meno di usare sistemi biometrici 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 velocizzabili tramite rainbow table occorre quindi introdurre una variazione imprevedibile chiamata salt Attacco dizionario ipotesi: 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 ) Antonio Lioy - Politecnico di Torino ( ) 5

6 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 (NON è h -1 ) pre-calcolo: for ( 10 9 distinct P ) for (p=p, n=0; n<1000; n++) k = h(p); p = r(k); store ( DB, P, p ) // inizio e fine catena attacco: Rainbow table (II) sia HP l hash (noto) 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 Uso del "sale" 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 rende praticamente impossibili gli attacchi dizionario (inclusi quelli basati su rainbow table) Antonio Lioy - Politecnico di Torino ( ) 6

7 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) nota: problema quasi simultaneo con scoperta che la app di Linkedin per ipad/iphone mandava dati sensibili (e non di sua competenza) in chiaro 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 da * (per distinguere dal metodo di MySQL < 4.1) esempio (per password "SuperPippo!!!"): campo user.password = *400BF58DFE90766AF20296B3D89A670FC66BEAEC verifica $ echo -n 'SuperPippo!!!' openssl sha1 -binary openssl sha1 -hex (stdin)= 400bf58dfe90766af20296b3d89a670fc66beaec Iphone ransomware maggio 2014 violati account icloud (con 1-factor authn) usata funzione "lock remoto" con "find my device" inviato messaggio sul dispositivo (iphone, ipad): "Device hacked by Oleg Pliss!" per riacquistare la funzionalità inviare 100 USD/EUR via Paypal a lock404(at)hotmail.com unica alternativa al pagamento usare "recovery mode" (ma si perdono tutti i dati e le app ) pagare il riscatto non serve! (fake Paypal account) Antonio Lioy - Politecnico di Torino ( ) 7

8 Strong (peer) authn "strong authn" often requested in specifications but never formally defined (or defined in too many different ways, which is useless) Strong authn: ECB definition strong customer authn is a procedure based on the use of two or more of knowledge, ownership, and inherence the elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s) at least one element should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the Internet the strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data Strong authn: PCI-DSS definition v3.2 requires multi-factor authentication (MFA) for access into the cardholder data environment (CDE) from trusted or untrusted network by administrators exception: direct console access (physical security) and for remote access from untrusted network by users and third-parties (e.g. maintenance) best practice until 2018/01, compulsory afterwards MFA is *not* twice the same factor (e.g. two passwords) Antonio Lioy - Politecnico di Torino ( ) 8

9 Strong authn: other definitions Handbook of Applied Cryptography a cryptographic challenge-response identification protocol more in general technique resisting to a well-defined set of attacks conclusion: an authn technique can be regarded as strong or weak depending on the attack model e.g. users of Internet banking > ECB definition e.g. employees of PSP > PCI-DSS definition watch out for your specific application field = risks Challenge-response authentication (CRA) a challenge (typically a random nonce) is sent to the claimant who replies with the solution computed using some secret knowledge and the challenge ID claimant challenge response = f (challenge, K C ) { ID : K V } K C response == g ( challenge, K V )? CRA: general issues the challenge must be non-repeatable to avoid replay attacks usually the challenge is a (random) nonce the function f must be non-invertible otherwise a listener can record the traffic and easily find the shared secret K C = f -1 (response, challenge) Antonio Lioy - Politecnico di Torino ( ) 9

10 Sistemi a sfida (simmetrici) una sfida viene inviata al Claimant che risponde con la soluzione effettuando un calcolo che coinvolge il segreto (condiviso col Verifier) ID claimant challenge response = f (challenge, K ID ) { ID : K ID } K ID response == f ( challenge, K ID )? Symmetric CRA: general issues the easiest implementation uses a hash function (faster than encryption) sha1 (deprecated), sha2 (recommended), sha3 (future) Kc must be known in cleartext to the verifier attacks against the { ID:K } table at the verifier SCRAM (Salted CRA Mechanism) solves this problem by using hashed passwords at the verifier offers also channel binding offers also mutual authentication Mutua autenticazione con protocolli a sfida simmetrici (v1) scambio base solo chi inizia lo scambio indica esplicitamente la propria identità A S B Alice enc (K AB, S B ) Bob S A enc (K AB, S A ) Antonio Lioy - Politecnico di Torino ( ) 10

11 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 Alice S B, enc (K AB, S A ) Bob enc (K AB, S B ) Attacco ai protocolli a sfida simmetrici Mike (as Alice) Bob A, S A S B, enc (K AB, S A ) conn #1 S B enc conn #2 A, S B S C, enc (K AB, S B ) enc (K AB, S B ) Sistemi a sfida (asimmetrici) una sfida viene generata cifrando un random nonce X con la chiave pubblica dell autenticando il quale risponde inviando X in chiaro grazie alla sua conoscenza della chiave privata cert( ID, kpubid ) claimant C = enc( R, kpubid ) response = dec( C, kpriid ) { ID } kpriid valid(id) && response == R? Antonio Lioy - Politecnico di Torino ( ) 11

12 Asymmetric CRA: analysis the strongest mechanism does not require secret storage at the verifier implemented for peer authentication (client and server) in IPsec, SSH, and TLS cornerstone for user authentication in FIDO problems slow if designed inaccurately may lead to an involuntary signature by the claimant PKI issues (trusted root, name constraint, revocation) avoidable if the verifier stores kpubid (moves equivalent PKI effort to the verifier) Password usa-e-getta server richiesta di autenticazione UID utente (UID) richiesta della password n. 48 UID : S UID P48 = p ( 48, S UID )? P48 UID P50 UID P49 UID P48 UID P47 UID P46 UID... One-Time Passwords (OTP) password valid only for one run of the authentication protocol next run requires another password immune to sniffing subject to MITM (needs verifier authentication) difficult provisioning to the subscribers lot of passwords password exhaustion difficult password insertion random characters to avoid guessing Antonio Lioy - Politecnico di Torino ( ) 12

13 Come fornire OTP agli utenti? per uso su postazioni stupide o insicure: password pre-calcolate e scritte su un foglio poor man's OTP autenticatori hardware (criptocalcolatrici) per uso su postazioni sicure e intelligenti: programmi di calcolo tipico per smartphone, tablet, laptop, Il sistema S/KEY (I) prima definizione ed implementazione delle OTP da parte dei Bell Labs (1981) l utente genera un segreto S ID l utente calcola N one-time password: P 1 =h(s ID ), P 2 =h(p 1 ),, P N =h(p N-1 ) Verifier memorizza P N password mai usata direttamente per l autenticazione, ma solo indirettamente Verifier chiede P N-1 e riceve X ossia chiede pwd in ordine inverso if (P N!= h(x)) then FAIL else {OK; store X as P N-1 } Il sistema S/KEY (II) 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) S/KEY è un esempio di Off-line / Pre-computed OTP Antonio Lioy - Politecnico di Torino ( ) 13

14 P N = h N (s) h Il sistema S/KEY (III) 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 N-2 h P 1 = h(s) h initial secret S user password generation autenticazione S/KEY S/KEY generazione delle password l'utente inserisce una pass-phrase (PP) minimo 8 caratteri 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) S/KEY password password di 64 bit sono un compromesso non troppo lunga (complessa) né troppo corta (insicura) inseribile come sei parole inglesi corte, scelte da un dizionario di 2048 (es. 0="A", 1="ABE", 2="ACE", 3="ACT", 4="AD", 5="ADA") client e server devono avere lo stesso dizionario esempio: password (testo) YOU SING A NICE OLD SONG password (numerica) 1D6E BD711 (hex) ovvero 2,120,720,442,049,943,313 (decimale) Antonio Lioy - Politecnico di Torino ( ) 14

15 Problemi delle OTP scomode da usare in assoluto scomode per accesso a servizi con autenticazione ripetuta (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 Time-based OTP la password dipende dal tempo e dal segreto dell'utente: p(id,t) = h( t, S ID ) verifier authn request claimant ID, X=p(ID,t) { ID : S ID } S ID X == p(id,t)? Antonio Lioy - Politecnico di Torino ( ) 15

16 Time-based OTP: analysis requires local computation at the subscriber requires clock synchronization (or keeping track of time-shift for each subscriber) requires authentication window X == p(id,t) X == p(id,t-1) X == p(id,t+1) only one authentication run per time slot typically 30s or 60s (not good for some services) time attacks against subscriber and verifier fake NTP server or mobile network femtocell sensitive database at the verifier see the attack against RSA SecurID Un esempio TOTP: RSA SecurID il Claimant invia al Verifier in chiaro user, PIN, token-code (seed, time) oppure (se usa autenticatore con pinpad) user, token-code* (seed, time, PIN) 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) componenti ACE (Access Control Engine) ACE client (da installare sul Relying Party) ACE server (implementa il Verifier) RSA SecurID: prodotti recenti PINPAD Antonio Lioy - Politecnico di Torino ( ) 16

17 SecurID: architettura ACE server token OK? token OK? ACE client OK! KO! ACE client SSH server DBMS server user, PIN, TC user, TC* SSH client SecurID (normale) DBMS client SecurID (pinpad) Event-based OTP uses a monotonic integer counter C as input besides the seed p(id,c) = h( C, S ID ) requires local computation at the subscriber counter incremented at the subscriber (e.g. button) frequent authentication runs are possible OTP pre-computation (also by adversary who temporarily have access to the authenticator) verifier must accommodate desynchronization the subscriber pushed button unwillingly X==p(ID,C) X==p(ID,C+1) X==p(ID,C+2)? Out-of-band OTP server 1. richiesta di autenticazione utente (UID) 2. UID + P UID 5. OTP segreto (P UID ) 3. generazione dati authn 4. trasmissione OOB della OTP Antonio Lioy - Politecnico di Torino ( ) 17

18 Out-of-Band OTP at step 5 secure channel w/ server authentication needed to avoid MITM attacks OOB channel frequently is text/sms message can be attacked due to problems of VoIP, mobile user identification, and SS7 protocol NIST SP B use of PSTN (SMS or voice) as OOB channel is deprecated suggest using Push mechanism over TLS channel to registered subscriber device Zero-Knowledge Proof (ZKP) one side (prover) demonstrates to the other (verifier) that a given statement is true without conveying other information similar to CR but knowledge at prover and verifier different, hence more rounds are needed and often a certain approximation exists e.g. knowledge of discrete logarithm of a value has 50% cheating probability, so 20 rounds are needed to get cheating down to 10-6 Zero-Knowledge Authentication (ZKA) ZKP used for authentication Zero-Knowledge Password Proof (ZKPP) password-based ZKA many ZKPP algorithms differ for advantages, disadvantages, and patents normally associated to establishment of a secret shared key can provide also mutual authentication (if user DB at verifier is protected from read) can provide also channel binding (if key used for encryption or MAC) if main purpose is key establishment, then named PAKE (Password-Authenticated Key Exchange) ZKPP is exact, not approximated as ZKP Antonio Lioy - Politecnico di Torino ( ) 18

19 Standards for ZKP ZKPP and (especially) PAKE are hot areas work by IETF, IEEE, ISO, and ITU no clear winner IETF SRP (Secure Remote Password) for telnet authn and TLS authn and key-agreement Augmented PAKE for peer authn and key exchange in IKEv2 other PAKE schemes (e.g. DragonFly) for EAP IEEE uses SAE (Simultaneous AuthN of Equals ) for station authn and key exchange variant of DragonFly for PAKE based on a ZKP supports both FFC and ECC Two-/Multi-Factors AuthN (2FA/MFA) use more than one factor to increase authn strength to protect authenticator PIN used for authenticator protection PIN transmitted along with OTP PIN entered to compute the OTP itself PIN (or inherence factor) used to unlock the authenticator, very risky if: lock mechanism weak no protection from multiple unlock attempts unlocking valid for a time window 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 Antonio Lioy - Politecnico di Torino ( ) 19

20 Sistemi biometrici misurano una caratteristica biologica dell utente principali caratteristiche usate: impronte digitali voce scansione della retina scansione della pupilla scansione delle vene delle mani ritmo cardiaco geometria delle mani utili per sostituire *localmente* un PIN o una password Problemi dei sistemi biometrici FAR = False Acceptance Rate FRR = False Rejection Rate FAR e FRR sono in parte aggiustabili ma dipendono moltissimo dal costo del dispositivo caratteristiche fisiche variabili: ferita su un dito voce tremante per l emozione vasi oculari dilatati per alcool o droga FAR / FRR Antonio Lioy - Politecnico di Torino ( ) 20

21 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 API? SPI? middleware! APP1 APP2 API (Application Programming Interface) middleware (es. CDSA) SPI (Service Programming Interface) dispositivo / servizio n. 1 dispositivo / servizio n. 2 dispositivo / servizio n. 3 Kerberos sistema di autenticazione basato su una terza parte fidata (TTP = Trusted Third Party) sviluppato nel progetto Athena al MIT password mai trasmessa ma solo usata localmente come chiave di crittografia (simmetrica) realm = dominio di Kerberos, ossia insieme di sistemi che usano Kerberos come sistema di autenticazione credenziale = user.instance@realm Antonio Lioy - Politecnico di Torino ( ) 21

22 ticket Kerberos 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 Organizzazione di Kerberos K UID, K TGS AS Authentication Server { TGT } TGT K S TGS Ticket Granting Server T s richiesta client T s (application) server Kerberos: formato dei dati (v4) TICKET server-id client-id client-address timestamp life K S,C AUTENTICATORE client-id client-address timestamp KS K S,C Antonio Lioy - Politecnico di Torino ( ) 22

23 Richiesta del TGT C, TGS C A S { K C,TGS, { T C,TGS } K TGS } K C client Authentication Server Richiesta del Ticket C s, { T C,TGS } K TGS, { A C } K C,TGS { { T C,S } K S, K C,S } K C,TGS T G S client Ticket Granting Server Uso del Ticket { T C,S } K S, { A C } K C,S C { timestamp(a C ) + 1 } K C,S S client server (applicativo) Antonio Lioy - Politecnico di Torino ( ) 23

24 Kerberos MIT V4 (originale) poi MIT V5 (anche RFC-1510) non solo DES durata maggiorata (inizio-fine) inter-realm authentication forwardable ticket ticket estesi login unico per tutti i servizi kerberizzati K-POP, K-NFS, K-LPD, K-telnet, K-ftp, K-dbms servizi di un dominio Windows (MS usa Kerberos* a partire da Windows-2000) ideale per connessioni intermittenti (es. WiFi, 4/5G) 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 vero SSO: 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 all users all networks universal strong authentication all devices Antonio Lioy - Politecnico di Torino ( ) 24

25 Specifiche OATH HOTP (HMAC OTP, RFC-4226) 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 HOTP K : chiave segreta condivisa C : contatore (numero intero monotono positivo) h : funzione di hash crittografico (default: SHA1) sel : funzione che seleziona 4 byte da una stringa di byte in una maniera nota HOTP(K,C) = sel(hmac-h(k,c)) & 0x7FFFFFFF nota: la maschera 0x7FFFFFFF imposta MSB=0 (per evitare problemi se il risultato è interpretato come un numero intero con segno) per generare un codice di accesso da N cifre (6-8): HOTP-code = HOTP(K,C) mod 10 N TOTP come HOTP ma il contatore C è pari al numero di intervalli TS trascorsi da un'origine prefissata T0 C = (T T0 ) / TS default (RFC-6238): T0 = Unix epoch (1/1/1970) T = unixtime(now) secondi trascorsi da Unixepoch TS = 30 secondi in pratica C = floor ( unixtime(now) / 30 ) h = SHA1 (ma PUO' usare SHA-256 o SHA-512) N = 6 Antonio Lioy - Politecnico di Torino ( ) 25

26 Google authenticator supporta HOTP e TOTP con le seguenti assunzioni: K è fornita codificata in base-32 C è fornito come uint_64 sel(x) offset = 4 least-significant-bits of X return X[offset offset+3] TS = 30 secondi N = 6 se il codice generato ha meno di 6 cifre significative, farne padding a sinistra con zero (es. 123 > ) FIDO Fast IDentity Online standard industriale della FIDO Alliance per: biometric authn = passwordless user experience 2-factor authn = 2 nd factor user experience basato su dispositivi personali capaci di fare crittografia asimmetrica per rispondere a sfide asimmetriche per firmare digitalmente dei testi UAF = Universal Authentication Framework U2F = Universal 2nd Factor ASM = Authenticator-Specific Module FIDO registration Antonio Lioy - Politecnico di Torino ( ) 26

27 FIDO Login FIDO U2F registration FIDO U2F authentication Antonio Lioy - Politecnico di Torino ( ) 27

28 biometria FIDO: altre caratteristiche metodo di autenticazione locale per abilitare le chiavi FIDO conservate sul dispositivo utente transazioni sicure oltre alla risposta alla sfida viene anche firmato digitalmente un testo relativo alla transazione FIDO backend (o server) per abilitare l'uso di FIDO su un server applicativo FIDO client per creare e gestire credenziali FIDO su un dispositivo utente FIDO: security e privacy autenticazione forte (crittografia asimmetrica) nessuna terza parte (fidata) inclusa nel protocollo nessun segreto conservato lato server (eventuali) dati biometrici conservati solo sul dispositivo utente no tracciabilità / collegabilità tra servizi diversi usati dallo stesso utente no tracciabilità / collegabilità tra account diversi assegnati allo stesso utente Fido: evoluzione Feb.2013: annuncio della FIDO alliance Dic.2014: FIDO v1.0 Giu.2015: Bluetooth e NFC come canali di trasporto per U2F Nov.2015: proposta a W3C di una Web API per accedere alle credenziali FIDO Feb.2016: W3C crea il Web Authentication WG per definire una API client-side che fornisce autenticazione forte alle applicazioni web, basandosi sulla FIDO Web API Antonio Lioy - Politecnico di Torino ( ) 28