È un metodo sicuro per autenticare i pacchetti?

Naviga le tue risposte
2

Ho un'architettura client / server che invia periodicamente pacchetti UDP molto piccoli (circa 10 byte) avanti e indietro, che mi piacerebbe autenticare senza un grande sovraccarico di larghezza di banda o elaborazione. Nota che non mi interessa un avversario che vede il testo in chiaro, solo che mi piacerebbe impedire loro di modificare e ritrasmettere i pacchetti.

Ecco il processo che sto immaginando:

  1. L'utente si autentica con un nome utente / password su HTTPS. Niente di straordinario qui.
  2. Il server risponde con un messaggio di successo e N byte (forse circa 32 byte) di dati casuali generati crittograficamente. Sia il client che il server ricordano questa stringa di dati come common_secret .
  3. A questo punto la connessione HTTPS viene chiusa e tutte le ulteriori comunicazioni avverranno tramite piccoli pacchetti UDP, utilizzando questo schema per l'autenticazione:
  4. packet = plaintext + sha2(plaintext + common_secret)
  5. Alla ricezione di un pacchetto, il server calcolerà lo stesso sha2 dal testo in chiaro e il suo common_secret , e verificherà che corrisponda all'hash alla fine del pacchetto.

Un avversario non sarà in grado di costruire un pacchetto valido senza conoscere common_secret . Si tratta di uno schema di autenticazione valido?

    
posta Joel 03.08.2016 - 17:57
fonte

3 risposte

3

Vulnerabilità nel tuo metodo

La tua costruzione è molto probabilmente vulnerabile a un attacco di estensione della lunghezza che consente la modifica del messaggio, così come un attacco di replay che consente di inviare nuovamente messaggi precedentemente inviati.

Obbligatorio: è per questo che non dovresti lanciare il tuo . Invece, usa le soluzioni esistenti per i problemi che vuoi risolvere.

Approcci sicuri

Una soluzione contro il primo problema è utilizzare un HMAC appropriato. Se hai bisogno di protezione contro gli attacchi di replay, devi scambiare i nonces o simili.

    
risposta data 03.08.2016 - 19:00
fonte
2

No, non è sicuro. Come sottolinea @ paj28, ci sono attacchi di replay "evidenti". C'è un motivo per ogni bit di overhead in DTLS e nella modalità auth di IPsec. (Bene, la maggior parte della modalità di autenticazione di IPSec.) Dovresti semplicemente usarne uno.

La stessa logica che porta a "Coloro che non capiscono il TCP / IP sono destinati a reinventarlo, male" si applica qui.

    
risposta data 03.08.2016 - 19:00
fonte
0

il tuo algoritmo sembra che tu stia cercando di completare l'integrità. usa un HMAC invece per la tua firma. l'aggiunta di un nonce richiederà lo scambio di ulteriori punti, aggiungendo la complessità di doverli scambiare di nuovo.

forse usare

HMAC con EPOCH

ma ora è necessario assicurarsi che entrambi gli orologi siano sincronizzati e continuare a lavorare con l'ora legale se ciò si verifica, l'epoca ovviamente consente solo di confermare la freschezza entro x secondi a seconda della latenza della rete.

quindi forse;

plaintext + HMAC (plaintext + epoch)

il fatto che stai usando un HMAC significa che il tuo segreto è ora la chiave per l'HMAC.

come altri hanno detto che inventare la tua cripto è di solito una cattiva idea.

perché non firmare con la crittografia asimmetrica se disponibile?

    
risposta data 03.08.2016 - 21:07
fonte

Leggi altre domande sui tag

Quale può essere una ragione per cui NON vuoi utilizzare la porta 443 per le comunicazioni SSL Dovrei anche cancellare l'ID della mia sessione prima di memorizzarlo nel database? [duplicare]