HMAC Qual è il modo sicuro per distribuire il segreto condiviso tra client e server?

Question

HMAC Qual è il modo sicuro per distribuire il segreto condiviso tra client e server?

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

5

Sto cercando modi per proteggere la comunicazione http usando HMAC. La mia comprensione è che in questo scenario il cliente e il server conoscono entrambi un segreto. Ciò significa che il segreto deve essere prima generato sul client (o sul server? Importa da che parte?). A questo punto solo un lato ha il segreto. Come passa il segreto dall'altra parte (o se non viene passato una volta come mai lo si conosce)? Non sarebbe stato necessario inviarlo attraverso una volta sola? In quale altro modo il segreto sarebbe mai stato conosciuto sia dal client che dal server? Se inviarlo durante l'inizializzazione è di fatto la cosa da fare, come può essere fatto in modo sicuro?

Ora mi rendo conto che un canale separato potrebbe essere usato come e-mail, ecc., ma se fosse necessario utilizzare HMAC per stabilire automaticamente il coinvolgimento dell'utente?

rest authentication http hmac

posta Place Places 07.03.2013 - 03:43

fonte

3 risposte

Leggi altre domande sui tag rest authentication http hmac

Protezione degli hash delle password con stored procedure? MAC spoof non funziona?

score 3 · Answer 1

In primo luogo, HMAC è usato per verificare l'originatore di un messaggio e solo il mittente ha bisogno di un segreto. È inutile per scopi di segretezza. Secondo, lo scambio di chiavi è una cosa difficile. Puoi farlo attraverso un canale laterale, ma dal momento che è difficile, è per questo che la maggior parte dei browser lo fa per te attraverso un elenco preinstallato di certificati CA radice che vengono installati con il browser. Questo è il modo in cui il tuo browser riconosce le informazioni provenienti da un determinato server.

Poiché il server conosce un segreto di cui il client può fidarsi, è possibile che il client invii una chiave di sessione che solo il server può leggere e quindi che il segreto condiviso possa essere utilizzato per comunicazioni sicure. Questa è la base dietro SSL e il motivo per cui SSL viene usato così com'è, poiché altrimenti devi eseguire la distribuzione delle chiavi da solo per ogni cliente.

Modifica: come indicato da CodesInChaos, è possibile utilizzare qualsiasi tipo di crittografia per convalidare che il MAC sia valido per il messaggio da una parte autorizzata. Non deve essere pubblico / privato, ma ciò non altera in realtà il fatto che lo scambio di chiavi è il problema in quanto pubblico / privato è più facilmente affrontato in questo caso particolare rispetto all'utilizzo di chiavi simmetriche.

score 1 · Answer 2

Penso che sia necessario mettere in discussione i propri vincoli. Se si fosse in grado di utilizzare HTTP * S * invece di HTTP, sarebbe possibile delegare tutti i noiosi e proni protocolli di scambio di chiavi inclini ai browser o ai sistemi operativi coinvolti.

In realtà, questo è solo scambio di chiavi Diffie-Hellman , e provare a creare un nuovo la soluzione a un vecchio problema è solo un problema.

score 0 · Answer 3

Come Henderson ha detto che il design di HMAC è l'autenticazione, è meglio implementare PGP . In PGP entrambe le parti non hanno bisogno di condividere la propria chiave privata, solo inviando la loro chiave pubblica per l'altra parte per la crittografia dei dati. HMAC aiuta anche a verificare l'integrità dei dati in modo da poter combinare sia PGP che HMAC se si desidera avere comunicazione sicura, autenticazione e integrità dei dati allo stesso tempo.