C'è qualche rischio per la sicurezza, se il database con i maniglie delle chiavi per i dispositivi U2F è trapelato?

4

C'è qualche rischio, se un database di maniglie di chiavi del dispositivo U2F è trapelato?

La registrazione di una chiave funziona con:

  • Invia la richiesta di registrazione con "AppID" al dispositivo U2F.
  • Il dispositivo U2F risponde con "Chiave, chiave pubblica".

Autenticazione funziona da:
Invia richiesta di autorizzazione con "AppID, Key Handle, Challenge" al dispositivo U2F. Il dispositivo U2F lo firma e restituisce "Firmato la sfida" al server.

"L'handle chiave" è un elemento opaco, che potrebbe essere una chiave privata crittografata, crittografata dal controller smart card U2F, ma potrebbe anche essere un'informazione utilizzabile solo dal controller della smart card per rigenerare la chiave privata , come un seme che viene inserito in un RNG deterministico che è unico per quel dispositivo U2F, una routine di generazione HMAC (Yubico U2F usa questo), oppure potrebbe essere semplicemente un ID che punta alla memoria interna nella chiave U2F, ma che limiterebbe il numero di siti web con cui la chiave U2F può essere registrata.

Secondo lo standard, l'utente deve essere autenticato da username + password Prima di avviare l'autenticazione U2F.

Ma diciamo che omettiamo completamente la password, e invece autorizziamo l'utente a inserire il loro nome utente, poi vengono portati all'autenticazione U2F, e voilá, sono dentro.

Ciò, tuttavia, significherebbe che un utente malintenzionato potrebbe enumerare tutti gli handle delle chiavi, perdendo così tutti gli handle delle chiavi nel database.

Le manche chiave trapelate sarebbero un rischio per la sicurezza? Sembra che non dovrebbe essere, ma dal momento che gli handle chiave potrebbero contenere chiavi private crittografate, potrebbero essere (?). L'handle di una chiave non sarebbe comunque utilizzabile da un altro sito rispetto al suo designato AppID, poiché il dispositivo U2F rifiuterebbe qualsiasi tentativo di autenticazione che utilizza un handle di chiavi "rubate". Tuttavia, questo viene applicato dal software / browser del client, poiché un software / browser malintenzionato potrebbe semplicemente falsificare l'AppID.

    
posta sebastian nielsen 10.01.2015 - 02:09
fonte

2 risposte

1

Bottom line: Se per "rischio" intendi il rischio di esporre il tuo servizio al potenziale per l'attacco remoto, allora no, non vi è alcun rischio aggiuntivo fino a quando i token FIDO U2F sono stati implementati correttamente.

Tuttavia, l'accesso a queste informazioni consente a qualcuno con accesso fisico (tramite NFC, ad esempio) al token di verificare facilmente se un determinato token è associato a un account specifico o meno. Ad esempio, se sospetto un'associazione tra una persona specifica (che usa un token U2F NFC, come un YOOkey NEO) e un utente sul tuo sito web, allora potrei facilmente verificare questo sospetto a loro insaputa se riesco a essere abbastanza vicino fisicamente al loro token.

Diversi token possono anche avere lunghezze diverse del manico del tasto. Se l'utente utilizza un token con una lunghezza di handle di chiave insolita, questo potrebbe essere un metodo per aiutare a escludere i modelli di token.

Se vi è una debolezza nell'implementazione FIDO U2F sul token che un utente sta usando, allora c'è una possibilità che possa essere sfruttata, ma in questo caso l'implementazione del token è probabilmente il problema più grande.

In definitiva penso che la decisione di fare qualcosa del genere dipenda dai tuoi requisiti di sicurezza. Quali sono le implicazioni di qualcuno che associa uno dei tuoi account a uno specifico token / persona?

Tieni presente che l'eliminazione dei requisiti della password riduce l'autenticazione a fattore singolo.

    
risposta data 20.01.2015 - 05:49
fonte
0

Sì, la perdita delle coppie "AppParam / KeyHandle" di U2F deve essere considerata un rischio per la sicurezza. Secondo l'informativa sulla privacy di FIDO: "i dispositivi di identificazione rivelerebbero un identificatore univoco per un dispositivo su origini non correlate, violando la privacy dell'utente". (c) Specifiche FIDO. Quindi questa perdita permetterà almeno a un aggressore di essere in grado di identificare il particolare dispositivo.

Si noti inoltre che un malware su host Windows può facilmente enumerare un migliaio di coppie (AppParam, KeyHandle) con un dispositivo U2F inserito senza iterazione dell'utente. Una volta identificato il KeyHandle valido, un malware può quindi simulare facilmente alcune azioni dell'interfaccia utente e fare in modo che l'utente prema un pulsante su U2F per generare una firma. E ora supponiamo che ci sarà una vulnerabilità di 0 giorni scoperta in U2F che consente di firmare qualsiasi Digest senza iterazione dell'utente?

E sì, hai ragione, KeyHandle è una chiave privata crittografata dalla coppia di chiavi ECDSA. Ecco la dichiarazione dei progettisti FIDO per quanto riguarda KeyHandle: link

It should be noted that key wrapping is an optional optimization vendors may employ, and that our implementation is one approach. The FIDO U2F specifications allow device manufacturers to choose any approach for key wrapping.

NonhomaivistoalcunaimplementazioneopensourcedeldispositivoFIDOU2F,ancheyubikohadecisodimantenerequestariservatezza: link

    
risposta data 21.04.2018 - 10:30
fonte

Leggi altre domande sui tag