Come trasferisco l'HMAC?

4

Ho un file che mi piacerebbe criptare con una chiave simmetrica usando AES-256 e quindi utilizzare un HMAC per l'integrità. Quindi non faccio un "mio schema" che so essere un grosso errore, quali sono gli standard per usare l'HMAC una volta creato? E 'questo quello che sta per GCM? Posso semplicemente archiviare l'HMAC con le chiavi o dovrebbe essere incluso nel file crittografato in qualche modo pre-inserendolo o aggiungendolo al messaggio finale? Ho visto molto su come creare l'HMAC e su quali dati per calcolarlo, ma nulla su cosa fare con una volta ottenuto. Forse sto solo cercando nel posto sbagliato o rendendo le cose troppo complicate.

    
posta jeffaudio 06.03.2013 - 17:42
fonte

3 risposte

5

La combinazione di MAC e crittografia è difficile . A seconda di come lo fai, il risultato sarà sicuro, o meno, o solo "per lo più sicuro" modulo una miriade di dettagli di implementazione. GCM è un Autenticato Modalità di crittografia che fa tutto il lavoro duro per te, quindi è consigliato caldamente che usi GCM (o una modalità equivalente come EAX ) invece di progettare il tuo protocollo.

Solo a scopo di ricerca , il valore MAC sarà parte dei dati crittografati se utilizzi MAC-then-encrypt, mentre dovrà essere trasmesso o memorizzato separatamente se usi encrypt-then -MAC o encrypt-and-MAC. Successivamente questa è solo una questione di codifica. "Encrypt-then-MAC" è raccomandato in particolare perché poiché il MAC opera sui dati crittografati , non può rivelare nulla sui dati in testo normale, quindi il valore MAC può essere mostrato a tutti senza alcun effetto negativo.

    
risposta data 06.03.2013 - 18:37
fonte
2

Bene, GCM è una modalità autenticata che raggiunge lo stesso obiettivo, come CCM (Counter with CBC-MAC), e l'una o l'altra sarebbe preferibile a un'implementazione home-brew. Ma se per qualsiasi motivo non si ha accesso a una libreria di primitive incorporata che può utilizzare queste modalità (gli algoritmi di System.Security.Cryptography di .NET, ad esempio, non hanno questi, ma sono disponibili varie opzioni di aftermarket ), una combinazione di HMAC e una modalità non autenticata può fornire un'autenticazione del messaggio simile.

In breve, è generalmente meglio crittografare, quindi calcolare un HMAC del testo cifrato e anteporre il MAC (che è di lunghezza fissa e quindi può essere facilmente separato quando posizionato per primo) nel testo cifrato. Questo è noto come approccio "Encrypt-then-Authenticate" ed è un metodo generalmente accettato per creare una modalità di crittografia autenticata da una non autenticata.

Altre permutazioni come "Authenticate-then-Encrypt" (calcola l'HMAC del testo in chiaro e quindi crittografa l'HMAC e il testo in chiaro in ciphertext, questo è l'approccio di base di SSL / TLS) o "Autentica e Encrypt "(calcola l'HMAC del testo in chiaro, quindi crittografa il testo in chiaro e antepone l'HMAC al testo cifrato) si mostra più vulnerabile nel caso generale. Alcune implementazioni potrebbero essere ancora protette (AtE è sicuro quando si utilizza la modalità CBC o un codice di streaming, se gli attacchi di riempimento e temporizzazione vengono conteggiati in CBC).

Il metodo EtA è il più sicuro in assoluto, se correttamente implementato, e quindi consigliato per le situazioni in cui uno sviluppatore deve implementare la propria modalità autenticata. Funzionerà con qualsiasi modalità di crittografia e crittografia sicura e qualsiasi algoritmo MAC sicuro. Tuttavia , è necessario prestare attenzione. Prima di tutto, l'HMAC deve includere più del testo cifrato; dovrebbe anche includere l'IV e, in situazioni che richiedono "flessibilità algoritmica", un identificatore univoco della permutazione dei primitivi crittografici utilizzati (come AES128-CBC-HMAC-SHA256). Ciò impedisce a un utente malintenzionato di eseguire determinati exploit con un IV o un algoritmo diverso.

Un'altra cosa da tenere a mente è la possibilità di un "attacco a tempo". EtA ha una modalità di errore iniziale molto veloce (il MAC non corrisponde al testo cifrato), ma se il MAC dovesse corrispondere, il successivo errore possibile (un errore di riempimento) richiederà più tempo per essere rilevato. Un utente malintenzionato può utilizzare la differenza nel tempo di calcolo tra un errore MAC e un errore di riempimento per capire quale è, anche se non si fornisce questo livello di dettaglio nel feedback a un client. Possono quindi usarlo per eseguire un attacco di testo cifrato scelto. È una preoccupazione relativamente minore, perché questo schema rende le possibilità che persino un cambiamento ingegnosamente ingegnerizzato passi ancora l'HMAC estremamente basso, ma per mitigare questa possibilità, considera la possibilità di costruire in una sorta di ritardo tale da garantire che la quantità di tempo necessaria per restituire un errore dipende da qualcosa di diverso dal tempo di calcolo non elaborato.

    
risposta data 06.03.2013 - 18:14
fonte
1

Per estendere la risposta di Thomas Pornin, si consiglia anche encrypt-then-mac dal momento che in primo luogo si prende il mac del testo crittografato e lo si confronta con il mac inviato dal mittente. Si eseguirà l'attività di decifratura del processore solo se i due MAC sono uguali e si dimostra che i dati non sono temperati. Se i due MAC non sono uguali, non vi è alcun motivo di decodificare il pacchetto poiché è già stato dimostrato che i dati non sono autentici. Se esegui mac-then-encrypt, devi prima eseguire la decrittografia e quindi prendere il mac del messaggio e confrontarlo con il mac originale. Moxie Marlinspike chiama questo The Cryptographic Doom Principle

    
risposta data 06.03.2013 - 19:23
fonte

Leggi altre domande sui tag