Quali sono le alternative a ECDSA per un protocollo di autenticazione?

Question

Quali sono le alternative a ECDSA per un protocollo di autenticazione?

#1 da (1 voti)
#2 da (0 voti)

1

In un protocollo di autenticazione , S ha una coppia di chiavi pubblica / privata nota a C, e S e C hanno stabilito un canale sicuro (ad esempio, utilizzando DH o ECDH, o qualsiasi altro scambio di chiavi protocollo). C desidera determinare se il peer su questo canale sicuro possiede la chiave privata.

In ECDSA, la coppia di chiavi è una coppia di chiavi a curva ellittica e l'algoritmo di firma utilizza lo schema DSA (DSS) con la curva ellittica. È noto che lo schema DSA presenta alcune proprietà indesiderabili: i punti deboli del RNG sono una preoccupazione reale, considerando che un utente malintenzionato può ottenere un milione di firme.

Se è richiesta solo l'autenticazione, non è necessario uno schema di firma completo (ovvero, non è richiesta la possibilità di firmare messaggi arbitrari). Quali schemi alternativi potrebbero essere utilizzati per evitare la proprietà terrificante che il riutilizzo della chiave di identificazione in più firme finirà per perderlo?

Segue uno schema semplice:

C utilizza IES per crittografare un nonce N1 e invia questo a S (questo è lo schema di crittografia integrato della curva ellittica).
S quindi invia HMAC(key=Z, N1) alla C, dove Z è un segreto condiviso ottenuto tramite la fase di scambio della chiave (ricorda, abbiamo già stabilito un canale condiviso usando DH o qualche altro metodo).

Ciò dimostra il possesso della chiave privata: è richiesta la chiave privata per S per ottenere N1 da EIS(N1) . Il server non è un oracolo di decodifica - non decifrare messaggi arbitrari per conto di C, ma piuttosto risponde con l'HMAC del valore decrittografato. Infine, poiché il segreto condiviso Z è stato mescolato, che è stato determinato congiuntamente da C e S, la firma non può essere utilizzata per eseguire un uomo nell'attacco centrale: qualcuno che desidera impersonare S a C viene inviato da C al% cifratoN1, ma non può inoltrarlo a S per la firma, perché la firma è legata al Z del canale.

Domanda

Il mio schema semplice-morto ha un nome? È debole? Sembra evitare il problema del DSA in cui più firme potrebbero rivelare la chiave, ma non ho fatto tutta l'algebra per essere sicuro!
Quali sono le soluzioni standard più diffuse al problema? FHMQV è brevettato, purtroppo, ma è progettato esattamente per questa situazione, non è vero? Immagino che la soluzione popolare sembra essere ECDSA (usata in TLS, SSH), che spero di evitare.

Commento

L'articolo di Menezes "schemi di firma di curve ellittiche" nella "Enciclopedia della crittografia e della sicurezza" elenca DSA, Schnorr, Nyberg-Rueppel come i vari schemi di firma della curva ellittica noti. Il DSA è quello che non mi piace, e Nyberg-Rueppel apparentemente ha esattamente la stessa debolezza del DSA (due firme che usano nozioni con alcuni bit noti nelle comuni informazioni sulle chiavi private di perdita). Le firme di Schnorr sembrano buone, ma non sembrano essere ampiamente utilizzate.
L'HCR di Hugo Krawczyk (Hashed Challenge-Response, basato su XCR, Exponential Challenge-Response) sembra molto promettente - è una versione rinforzata di Schnorr che dovrebbe essere più robusta. Penso che sia coperto da Brevetto EP1847062B1 , tuttavia, che scade intorno al 2025 a quanto pare.

authentication cryptography man-in-the-middle key-exchange protocols

posta Nicholas Wilson 10.07.2014 - 13:49

fonte

2 risposte

Leggi altre domande sui tag authentication cryptography man-in-the-middle key-exchange protocols

Come può un attacco di dirottamento del browser cambiare la homepage predefinita del browser? Un virus sull'host può influire sul guest della VM [duplicato]

score 1 · Answer 1

1

In risposta alla domanda 2, potresti usare RSA invece per l'algoritmo della firma. Mentre le persone si stanno spostando verso ECDSA perché è più veloce, non c'è nulla di intrinsecamente sbagliato in RSA ancora.

risposta data 10.07.2014 - 15:26

fonte

score 0 · Answer 2

Sebbene un RNG debole sia un problema per ECDSA, questo può essere risolto in due modi:

Usando un RNG non-debole (che non è così difficile, sui computer moderni, è un sistema embedded a basso costo che potrebbe avere difficoltà a ottenere una discreta fonte di casualità).
Usando derandomization, come descritto in RFC 6979 . Questo è compatibile con ECDSA (usa le stesse coppie di chiavi pubbliche e private, i verificatori sono invariati) ma rimuove la necessità di una fonte casuale (debole o strong) o di qualsiasi stato.

Non è chiaro che cosa stia cercando di raggiungere il tuo protocollo; Sospetto che non faccia quello che vuoi veramente che faccia. Quando si considera una situazione simile a SSH, si desidera che il client e il server stabiliscano un segreto condiviso in modo tale che il client (rispettivamente il server) abbia una ragionevole garanzia che parli al server originale (rispettivamente il client originale). Nel tuo protocollo, presumi che quel client e server abbiano già ottenuto un tale Z condiviso, con la garanzia che il Z è stato prodotto con un DH tra client e server, non tra client e attacker-impersonating-the-server. In altre parole, risolvi il problema assumendo che sia già risolto ...

In generale, l'autenticazione si occupa di assicurarsi che il peer di qualche protocollo sia realmente il proprietario di un determinato valore segreto V . Prendiamo il punto di vista del server. Il server vuole sapere se un presunto client conosce davvero il valore V . I dettagli dipendono quindi da quel V :

Se il valore segreto è noto al client solo , non al server, allora siamo nel regno della crittografia asimmetrica. V deve essere la parte privata di una coppia di chiavi privata / pubblica e una firma è lo strumento giusto per questo.
Se il valore segreto è noto sia al client che al server, questo può essere fatto con la crittografia simmetrica.

Con una connessione SSH:

Il server ha sempre una coppia di chiavi pubblica / privata; il server calcola una firma verificata dal client. Il client autentica il server in virtù della convalida di tale firma per quanto riguarda la chiave pubblica del server noto (i client SSH ricordano le chiavi del server, nel file .ssh/known_hosts ).
Il server potrebbe voler autenticare il client con una password. In tal caso, la password è un segreto condiviso tra client e server; oppure il server può memorizzare solo una versione hash della password. Il client invia semplicemente la password al server e può farlo in modo sicuro perché a quel punto il client ha già autenticato il server e può utilizzare la chiave DH negoziata per crittografare i dati.

Se il server preferisce l'autenticazione client basata su chiave, il client ha una coppia di chiavi pubblica / privata, la chiave pubblica è nota al server (il file .ssh/authorized_keys ) e il client calcola una firma.

In SSL / TLS, la "memorizzazione delle chiavi pubbliche" viene sostituita con i certificati X.509. Il concetto di base rimane lo stesso, tuttavia, e vengono utilizzate le firme.

TLS supporta anche alcuni protocolli di scambio di chiavi meno diffusi da utilizzare quando client e server vogliono autenticarsi l'un l'altro da un segreto condiviso, senza utilizzare alcuna coppia di chiavi pubblica / privata; queste sono le PSK suite di crittografia e SRP (quest'ultimo è più complesso ma molto più potente quando il segreto condiviso ha una bassa entropia, ovvero una password ).