Vulnerabilità dell'utilizzo di HMAC di ID casuale come segreto condiviso?

Naviga le tue risposte
3

Supponiamo che un server abbia un% casuale segreto dikey, lo utilizzi per generare tuple di credenziali di <id = random(), secret = hmac(id, key)> e consegna queste tuple <id, secret> ai client liberamente (tramite una connessione protetta).

Ci sono dei punti deboli in un client che usa il suo secret per crittografare simmetricamente i messaggi diretti sul server?

Ad esempio:

1. Configurazione del server

  1. Il server è caricato con il segreto casuale key

2. Credenziali fornite al cliente

  1. Il cliente richiede le credenziali sul canale protetto
  2. Il server genera un% casuale diid
  3. Il server genera un secret di HMACing id con il suo key
  4. Il server risponde (su canale sicuro) con <id, secret> tupla

3. Il client invia un messaggio al server

  1. Il client crea un messaggio M da inviare al server
  2. Il client genera M' crittografando simmetricamente M e quindi MACing con secret
  3. Il client invia <id, M'> tuple al server su un canale non protetto

4. Il server riceve un messaggio dal client

  1. Il server riceve <id, M'> tupla sul canale non protetto
  2. Il server deriva secret da HMACing id con il suo key
  3. Il server autentica e decodifica M' utilizzando secret

Per me, questo offre il vantaggio del server che non ha bisogno di mantenere ID o segreti, ed è anche veloce (rispetto alla generazione di coppie di chiavi RSA).

Ma non vedo l'orrore di usare HMAC come questo per generare chiavi segrete?

Ho provato a cercare su Google questo schema ma il mio Google-fu non deve essere abbastanza strong ( questa domanda e risposta sembrano quasi chiuse , ma questa non è la "Key Derivation", vero?). Ci deve essere una buona ragione per cui questo non è più comune.

Inoltre, c'è un nome per questo?

    
posta Matt Thomas 05.04.2017 - 15:12
fonte

1 risposta

0

HMAC è un buon candidato per generare chiavi del genere.

Dopo alcuni scavi ho trovato questo libro, che chiama la tecnica " Generazione algoritmica di chiavi simmetriche da un segreto di base ", e che raccomanda specificamente l'uso di HMAC: link

[To create a key,] mix a base secret and any unique information you have available, passing them through a pseudo-random function (PRF), as discussed in the following section.

In seguito chiamano le "informazioni univoche" il distinguisher . Per i nostri scopi questo è equivalente al id generato casualmente.

Continuano a elencare diverse opzioni per un PRF, incluse le funzioni hash:

[...] a one-way hash is often good as a PRF.

Si espandono un po 'sull'idea di usare una funzione di hash come PRF:

[...] you can concatenate a base key with unique data and pass the string through SHA1.

La citazione sopra è simile in linea di principio a la definizione di HMAC . In effetti gli autori citano specificamente HMAC come candidato :

The easiest way to get a solid solution that will resist potentially practical attacks is to use HMAC in counter mode.

Questa citazione è nel contesto della generazione di chiavi più lunghe della dimensione del blocco hash. La modalità contatore significa semplicemente aggiungere un numero sequenziale al distinguisher mentre generi i dati chiave. Lo scopo di un contatore è quello di mantenere l'input dell'HMAC univoco in modo che la concatenazione dei blocchi di output (allo scopo di generare una chiave lunga) non si stia semplicemente ripetendo.

Per i nostri scopi, non è necessario utilizzare la modalità contatore a meno che secret debba essere più lungo della dimensione del blocco hash.

Nelle parole dell'autore:

If a [generated] key is compromised, it should be impossible to recover the base secret.

Inoltre menzionano un ulteriore vantaggio :

Multiple entities in the system should be able to compute the same derived key if they have the right base secret.

Q.E.D.

    
risposta data 07.04.2017 - 14:38
fonte

Leggi altre domande sui tag

Dove si nascondono i malware in genere in una macchina Windows? [chiuso] Segnale: metodo sicuro per trasferire le immagini dalla chat crittografata?