Tecniche e sistemi di autenticazione - polito.itlioy/03gsd/auth.pdf · v3.2 richiede multi-factor...

Tecniche e sistemi di autenticazione

Antonio Lioy< lioy @ polito.it >

Politecnico di TorinoDip. Automatica e Informatica

Definizioni di autenticazione 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"

© A.Lioy (Politecnico di Torino, 2005-2019) 2

Definizioni di autenticazione autenticazione di un "attore"

essere umano (che interagisce tramite un sw eseguito su un elemento hw)

componente software elemento hardware (che interagisce via sw)

abbreviazione: authN (o anche authC) diverso da autorizzazione (authZ) ma correlato


Fattori di autenticazione conoscenza (knowledge)

qualcosa che solo l'utente conosce,es. password, codice, PIN

possesso (ownership) qualcosa che l'utente possiede

(spesso chiamato "autenticatore"),es. token, smart card, smartphone

essenza (inherence) qualcosa che l'utente è,

es. una caratteristica biometrica(come un'impronta digitale)

pippo


Fattori di autenticazione: rischi conoscenza (es. password)

rischi = memorizzazione e dimostrazione/trasmissione possesso (es. smartphone)

rischi = l'autenticatore stesso per furto, clonazione, uso non autorizzato

essenza (es. dati biometrici) rischi = contraffazione e privacy non può essere rimpiazzato quando "compromesso"

(enorme problema!) da usarsi solo per autenticazione locale, come meccanismo

per sbloccare un segreto o dispositivo


Modello di autenticazione digitale(NIST SP800.63B)

claimantapplicant

subscriber

enrollment &identity proofing

auth

entic

ator

enro

llmen

t / is

suan

ce

validate the bindingauthenticator : credential

authNassertion

attributes

authenticated session RelyingParty

VerifierCSP

authNprotocol

success success


Autenticazione digitale : entità logiche CSP (Credential Service Provider)

emette o registra le credenziali utente verifica e memorizza gli attributi associati

Verifier esegue un protocollo di autenticazione per verificare il

possesso di un autenticatore e credenziali Relying Party (RP)

richiede e riceve un asserzione di autenticazione dal Verifierper certificare l'identità (e gli attributi) utente

questi ruoli posso essere distinti o combinati in una o più entità concrete


Autenticazione degli utenti

utente (UID)

segreto (SUID)

UID

richiesta di una prova

prova = F (SUID)

richiesta di autenticazioneserver

{ UID : f (SUID) }

conservazione del segreto?introduzione del segreto?

trasmissione della prova?

conservazione dei segreti?verifica della prova?


Password (ripetibili)

utente (UID)

segreto (PUID)

UID

richiesta della password

PUID


{ UID : PUID }o

{ UID : HUID }


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 (!), PUID

controllo d’accesso: prova == PUID? caso #2: f = one-way hash (ossia digest)

il server conserva i digest delle password, HUID

controllo d’accesso: f(prova) == HUID ?


Password ripetibili vantaggi:

semplice per l’utente ... 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 password sniffing attacchi al DB delle pwd (se il DB contiene le pwd come

plaintext o offuscate) password guessing (molto pericoloso se fatto offline, es.

contro una lista di hash delle pwd) password 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 di calcolo)

password capture via server spoofing o phishing attacchi MITM


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 lato server:

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” lato client

dovrebbe essere solo nella testa dell'utente … quando abbiamo troppe password, usiamo un file cifrato

(oppure un "password wallet")© A.Lioy (Politecnico di Torino, 2005-2019) 14

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” )


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 = 1012 righe { Pi : HPi } rainbow = 109 righe, ognuna rappresenta 1000 pwd

usa la funzione di riduzione r : h p (NON è h-1) pre-calcolo:

for ( 109 distinct P ) 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 (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 r0( ) … rn( ) 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 , saltUID , HPUID } evita di avere HP uguale per utenti diversi ma con stessa

pwd rende praticamente impossibili gli attacchi dizionario

(inclusi quelli basati su rainbow table)


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)

http://thehackernews.com/2014/05/apple-devices-hacked-by-oleg-pliss-held.html


Autenticazione forte (strong authN) "autenticazione forte" spesso richiesta in varie specifiche … ma mai formalmente definita (o definite in troppi modi

diversi, che è inutile) si intende sempre del "peer"


Autenticazione forte: definizione ECB 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


Autenticazione forte: definizione PCI-DSS v3.2 richiede multi-factor authentication (MFA) per accessi

al CDE (cardholder data environment) da rete (trusted o untrusted non fa differenza) sempre dagli amministratori eccezione: accesso diretto da console (sicurezza fisica)

… e per accesso remoto da rete untrusted da utenti e terze parti (es. per manutenzione)

best practice sino al 2018/01, obbligatoria dopo MFA *non* è due volte lo stesso fattore (es. due password)


Autenticazione forte: altre definizioni Handbook of Applied Cryptography

un protocollo crittografico di autenticazione a sfida più in generale

una tecnica resistente ad un ben definito insieme di attacchi conclusione:

una tecnica di authN pùo essere considerata debole o forte a seconda del modello di attacco es. utenti Internet banking > definizione ECB es. impiegati di un PSP > definizione PCI-DSS

attenzione allo specifico campo applicativo = rischi


Challenge-response authentication (CRA) una sfida viene inviata al Claimant... ... che risponde con una soluzione calcolata usando un

qualche segreto e la sfida il Verifier confronta la risposta con la soluzione calcolata

tramite un segreto correlato al Claimant

claimantID

challenge

response = f (challenge, KC){ ID : KV } KC

response == g ( challenge, KV ) ?© A.Lioy (Politecnico di Torino, 2005-2019) 26

CRA: problemi generali

la sfida deve essere non-ripetibile per evitare attacchi replay di solito la sfida è un (random) nonce

la funzione f deve essere non invertibile altrimenti un ascoltatore sul canale può registrare il traffico e

calcolare facilmente il segreto del Claimant

KC = f-1 (response, challenge)


Sistemi a sfida (simmetrici) una sfida viene inviata al Claimant ... ... che risponde col risultato di un calcolo che coinvolge il

segreto (condiviso col Verifier) il Verifier effettua lo stesso calcolo e confronta il suo

risultato con la risposta

ClaimantID

challenge

response = f (challenge, KID){ ID : KID } KID

response == f ( challenge, KID ) ?© A.Lioy (Politecnico di Torino, 2005-2019) 28

Symmetric CRA: problemi generali

l'implementazione più facile usa una funzione di hash (più veloce che una cifratura) sha1 (deprecato), sha2 (raccomandato), sha3 (futuro

prossimo) Kc deve essere nota in chiaro al Verifier

attacchi contro la tabella { ID:K } del Verifier SCRAM (Salted CRA Mechanism) risolve questo problema

usando hash di password sul Verifier offre anche "channel binding" permette anche mutua autenticazione


Mutua autenticazione conprotocolli a sfida simmetrici (v1)

scambio base solo chi inizia lo scambio indica esplicitamente la propria

identità

A

SB

enc (KAB , SB)

SA

enc (KAB , SA)

Alice Bob


Mutua autenticazione conprotocolli a sfida simmetrici (v2)

riduzione del numero di messaggi (migliorano le prestazioni ma non ha impatto sulla sicurezza)

usato da IBM SNA

A , SA

SB , enc (KAB , SA)

enc (KAB , SB)

Alice Bob


Un attacco al protocollo a sfida simmetrico


Mike(as Alice)

A , CA

CB , enc (KAB , CA)

enc (KAB , CB)

Bob

A , CB

CC , enc (KAB , CB)conn

#1

conn

#2CB

enc

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

claimantcert( ID, kPubID )

C = enc( X, kPubID )

response = dec( C, kPriID ){ ID } kPriID

valid(ID) && response == X ?© A.Lioy (Politecnico di Torino, 2005-2019) 33

Asymmetric CRA: analisi il meccanismo più forte non richiede memorizzazione di segreti sul Verifier implementato per peer authN (client e server) in IPsec, SSH,

e TLS fondamento dell'autenticazione degli utenti in FIDO problemi

procedura lenta se progettata male può condurre ad una firma involontaria da

parte del Claimant problemi di PKI (trusted root, name constraint, revocation)

evitabili se il Verifier memorizza kPubID (sposta i compiti della PKI sul Verifier)


Password usa-e-getta (anche dette OTP)

utente (UID)

P50UIDP49UIDP48UIDP47UIDP46UID

. . .

UID

richiesta della password n. 48

P48UID


UID : SUID

P48 == p ( 48, SUID ) ?


One-Time Password (OTP) password valida solo una volta per il protocollo di

autenticazione la prossima interazione vuole una nuova password

immune allo sniffing soggetto a MITM (serve autenticazione del Verifier) difficile fornire le password ai Subscriber

molte password esaurimento delle password

difficile inserimento delle password costituite da caratteri random per evitare attacchi che mirano

ad indovinarle


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 SID

l’utente calcola N one-time password: P1=h(SID), P2=h(P1), …, PN=h(PN-1)

il Verifier memorizza l'ultima password generata PN

password mai usata direttamente per l’autenticazione, ma solo indirettamente

Verifier chiede PN-1 e riceve X ossia chiede pwd in ordine inverso if (PN != h(X)) then FAIL else {OK; store X as PN-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


l'utente ha … il server ha …

autenticazione S/KEYuser password generation

Il sistema S/KEY (III)

PN = hN(s)

P2 = h(h(S)) = h2(S)

P1 = h(S)

initial secret S

h

PN-2

PN

storePN-1

h

h

PN-1 = hN-1(S) PN-1PN-1


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) 1D6E5001884BD711 (hex) ovvero

2,120,720,442,049,943,313 (decimale)


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, SID)

claimantauthN request

ID, X=p(ID,t)SID

X == p(ID,t) ?

verifier

{ ID : SID }


Time-based OTP: analisi

richiede un calcolo locale al Claimant richiede sincronizzazione dei clock (o tenere traccia delle

deviazioni per ciascun Subscriber) richiede time-slot ed una finestra di autenticazione

X == p(ID,t) || X == p(ID,t-1) || X == p(ID,t+1) una sola autenticazione per time-slot

tipicamente 30" o 60" (non buono per alcuni servizi) attacchi temporali contro Claimant e Verifier

falso server NTP o falsa femtocella di rete mobile database critico sul Verifier

si veda il famoso attacco contro 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, TC0, TC+1

duress code: PIN che fa 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© A.Lioy (Politecnico di Torino, 2005-2019) 48

SecurID: architetturaACE server

SSHserver

ACE client

DBMSserver

ACE client

SSHclient SecurID

(normale)

DBMSclientSecurID

(pinpad)

user, PIN, TC user, TC*

token OK? token OK?

OK! KO!


Event-based OTP usa un contatore intero monotonico C come input oltre al

seed p(ID,C) = h( C, SID)

richiede un calcolo locale presso il Claimant contatore incrementato dal Claimant (es. pulsante) possibile fare autenticazioni a raffica possibile pre-calcolare OTP (anche da avversario che abbia

accesso temporaneo all'autenticatore) il Verifier deve prevedere la possibilità di essere

desincronizzato col Subscriber es. il Subscriber ha premuto il pulsante per sbaglio X==p(ID,C) || X==p(ID,C+1) || X==p(ID,C+2) || … ?


Out-of-band OTP

utente (UID)

segreto (PUID)

2. UID + PUID

5. OTP

1. richiesta di autenticazioneserver

4. trasmissione OOB della OTP

3. generazionedati authN


Out-of-Band OTP al passo 5 serve un canale sicuro con autenticazione del

server per evitare attacchi MITM il canale OOB spesso è un messaggio SMS

attaccabile per problemi di VoIP, user ID nelle reti mobili e protocollo and SS7

NIST SP800-63.B l'uso di PSTN (SMS o voce) come canale OOB è deprecato suggerito l'uso di un meccanismo Push su canale TLS verso

il dispositivo registrato dell'utente


Zero-Knowledge Proof (ZKP) una parte (prover) dimostra all'altra (verifier) che una certa

affermazione è vera … senza fornire altre informazioni simile a CR ma con base di conoscenza diversa per prover

e verifier, quindi necessarie più iterazioni e spesso esisteuna certa approssimazione

es. conoscenza del logaritmo discreto di un valore ha 50% di probabilità di imbroglio, perciò servono 20 ripetizioni per ridurre la probabilità a 10-6

Zero-Knowledge Authentication (ZKA) ZKP usato per autenticazione


Zero-Knowledge Password Proof (ZKPP) password-based ZKA molti algoritmi ZKPP

diversi per vantaggi, svantaggi e brevetti normalmente associata a stabilire una chiave segreta

condivisa può fornire anche mutua autenticazione (se il DB utenti

presso il Verifier è protetto in lettura) può fornire anche channel binding (se la chiave è usata per

cifratura simmetrica o MAC) PAKE (Password-Authenticated Key Exchange) se lo scopo

principale è stabilire una chiave ZKPP è esatto, non approssimato come ZKP


Standard per ZKP ZKPP e (specialmente) PAKE sono temi caldi

IETF, IEEE, ISO, e ITU …nessun chiaro vincitore IETF

SRP (Secure Remote Password) per telnet authN, TLS authN e key-agreement

Augmented PAKE per peer authN e key-exchange in IKEv2 altri schemi PAKE (es. DragonFly) per EAP

IEEE 802.11 usa SAE (Simultaneous AuthN of Equals) perstation authN e key-exchange variante di DragonFly per PAKE basata su ZKP supporta sia FFC sia ECC


Two-/Multi-Factors AuthN (2FA/MFA) uso di più di un fattore

per aumentare la forza dell'utenticazione per proteggere l'autenticatore

es. PIN usato per proteggere l'autenticatore PIN trasmesso assieme all'OTP PIN introdotto per il calcolo dell'OTP PIN (o un fattore di essenza) usato per sbloccare

l'autenticatore, molto rischioso se: debole meccanismo di lock nessuna protezione da tentativi multipli di unlock sblocco valido per un'ampia finestra temporale


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


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


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


Problemi dei sistemi biometrici accettazione psicologica:

timore di essere schedati paura di danneggiamento

privacy è una identificazione

impossibile sostituire se scoperta quindi utili per sostituire *localmente* un PIN o una password

mancanza di API / SPI standard: alti costi di sviluppo dipendenza da un solo fornitore


API? SPI? middleware!

middleware (es. CDSA)

API (Application Programming Interface)

SPI (Service Programming Interface)

APP1 APP2

dispositivo/ servizio n. 1




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 Kerberoscome sistema di autenticazione

credenziale = user.instance@realm


Kerberos 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


Organizzazione di Kerberos

AS TGS

client (application)server

{ TGT }Ts

Ts

TGT

richiesta

AuthenticationServer

TicketGrantingServer

KUID, KTGS KS


server-idclient-idclient-addresstimestamplifeKS,C

KS

Kerberos: formato dei dati (v4)

TICKET

client-idclient-addresstimestamp

KS,C

AUTENTICATORE


Richiesta del TGT

{ KC,TGS , { TC,TGS } KTGS } KC

client AuthenticationServer

C, TGS

CAS


Richiesta del Ticket

s, { TC,TGS } KTGS , { AC } KC,TGS

{ { TC,S } KS , KC,S } KC,TGS

client

C

TicketGrantingServer

TGS


Uso del Ticket

{ TC,S } KS , { AC } KC,S

{ timestamp(AC) + 1 } KC,S

client

C

server(applicativo)

S


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)


universal strong

authentication

OATH (www.openauthentication.org) interoperabilità dei sistemi di autenticazione basati su OTP,

sfida simmetrica e asimmetrica definizione degli standard per il protocollo client-server e per

il formato dati sul client

Interoperabilità dell’autenticazione

all devices

all networks

all users


Specifiche OATH

http://www.openauthentication.org/specifications 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 numerointero con segno)

per generare un codice di accesso da N cifre (6-8):HOTP-code = HOTP(K,C) mod 10N


TOTP come HOTP ma il contatore C è pari al numero di intervalli

TS trascorsi da un'origine prefissata T0C = (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


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 > 000123)


FIDO Fast IDentity Online standard industriale della FIDO Alliance per:

biometric authN = passwordless user experience 2-factor authN = 2nd factor user experience

basato su dispositivi personali capaci di fare crittografiaasimmetrica per rispondere a sfide asimmetriche per firmare digitalmente dei testi

UAF = Universal Authentication Framework U2F = Universal 2nd Factor ASM = Authenticator-Specific Module


FIDO registration


FIDO Login


FIDO U2F registration


FIDO U2F authentication


FIDO: altre caratteristiche biometria

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 presenti solo sull'autenticatore no phishing perché la risposta non può essere riusata

è una firma su vari dati, inclusa l'identità del RP poiché si genera un keypair ad ogni registrazione, non

esiste tracciabilità / collegabilità tra: servizi diversi usati dallo stesso utente account diversi assegnati allo stesso utente

nessun limite pratico perché l'autenticatore non memorizza le chiavi private ma le ricalcola quando necessario, basandosi su un segreto interno e l'identità del RP


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 alleapplicazioni web, basandosi sulla FIDO Web API

Nov.2017: FIDO v2.0


FIDO 2.0 RP appserver

user device

RP app

browser

platform

(platform) authenticator

web authN JS API

(roaming) authenticator

[ USB, BT, NFC ]

FIDOserver

CTAP

FIDO authentication


FIDO 2.0: alcuni dettagli CTAP = Client To Authenticator Protocol gli autenticatori di piattaforma sono elementi crittografici

interni (più o meno sicuri) capaci di memorizzare (ed operare su) chiavi asimmetriche packed attestation = autenticatore con risorse limitate (es.

Secure Element) TPM attestation = TPM come elemento crittografico Android Key attestation = autenticatore di Android Nougat Android SafetyNet attestation = autenticatore di Android

tramite SafetyNet API FIDO U2F attestation = autenticatore FIDO U2F che usa

FIDO-U2F Message Format


Tecniche e sistemi di autenticazione - polito.itlioy/03gsd/auth.pdf · v3.2 richiede multi-factor...

Documents

Transcript of Tecniche e sistemi di autenticazione - polito.itlioy/03gsd/auth.pdf · v3.2 richiede multi-factor...