Perché garantire la coerenza dei dati crittografati con un hashing strong?

La decisione di utilizzare SHA1 per l'autenticazione dei messaggi fa parte delle specifiche di progettazione del trasporto formale ( RFC 4253 ). Inoltre, SHA2 è ora consigliato come aggiornamento del protocollo ( RFC6668 ).

In base a questo riferimento l'uso non solo garantisce l'integrità dei dati ma impedisce anche gli attacchi di riproduzione. SSH era in origine più simile a quello che stai suggerendo di utilizzare solo i controlli CRC. La funzione che stai interrogando è stata aggiunta per risolvere specificamente le debolezze in quel design più semplice.

In senso stretto, non si tratta di "coerenza" ma di "integrità", cioè i dati ricevuti da B sono gli stessi inviati da A.

XOR è un'operazione semplice e reversibile, con molti possibili vettori di attacco anche per i dati crittografati. Un attaccante può ad esempio cambiare un bit da 0 a 1 e un altro da 1 a 0 nel testo cifrato e questo potrebbe non essere rilevato da XOR.

Questo attacco è più o meno applicabile a diversi tipi di cifrario, ma per i codici di flusso è spesso banale da eseguire. Quindi, se uno non si limita a un certo insieme di cifre che sono immuni da questo tipo di attacco, si dovrà garantire l'integrità con altri mezzi: MAC.

Anche se un utente malintenzionato non può introdurre dati arbitrari nel flusso di dati crittografato, non dovrebbe nemmeno essere in grado di distruggere le informazioni in transito inosservato.

Solo un'ipotesi, ma XOR non è un ottimo modo per rilevare i difetti nei dati, e quindi non è un ottimo modo per verificare qualcosa. Se si XOR ciascuno dei blocchi e si ha un errore di bit in due dei blocchi nella stessa posizione, il valore XOR finale sarebbe lo stesso di se non ci fosse un errore. Con un checksum di hash, qualsiasi piccola modifica si rifletterà nel valore di checksum finale, rendendolo un indicatore più strong del fatto che qualcosa nei dati è rovinato.

EDIT: zedman9991 ha la risposta corretta. Avevo dimenticato che SSH è racchiuso in TCP o UDP, che forniscono entrambi i propri checksum per l'integrità dei dati, il che significa che l'hash nei dati SSH è inteso specificamente sia per l'inregrità che per la prevenzione di un attacco di replay.

Solo XORing dei blocchi di testo in chiaro non impedisce alcuni tipi di attacco.

Ad esempio:

• Se il primo o l'ultimo blocco del messaggio consiste interamente di byte nulli, puoi semplicemente eliminare l'IV (quindi il primo blocco crittografato sarà considerato l'IV) o l'ultimo blocco crittografato e il messaggio sarà ancora essere giudicato valido.

• Allo stesso modo, se i primi due o gli ultimi due blocchi sono identici, puoi eliminare i primi due o gli ultimi due blocchi della trasmissione.

Il protocollo è in realtà come [dati, HMAC-SHA1 (dati)] (o con un altro hash invece di SHA-1). Ciò che è necessario qui è autenticare i dati, ad esempio per garantire che provenga da una fonte che conosce una particolare chiave segreta. Un hash consente al destinatario di verificare che i dati siano uguali a qualcos'altro, ma il destinatario non ha nulla da confrontare. Al contrario, un MAC consente al destinatario di verificare che sia stato generato da un'entità che conosce la chiave segreta.

Stai cercando di costruire un MAC sopra un codice a blocchi. Questo è possibile, ma lo stai facendo male. Supponiamo, come fai tu, che i dati siano crittografati con un codice a blocchi in modalità CBC.

The data and checksum itself are encrypted, and any small change in the encrypted data would change at least one entire block (unpredictably by a possible attacker).

È vero: un blocco cambia in modo imprevedibile. Tuttavia, questo non è abbastanza buono: devi considerare le conseguenze sugli altri blocchi.

Due to encryption mode (CBC) and the fact, the hash is stored at the end of the packet, I suppose even the hash would change unpredictably.

No, l'hash non cambierà in modo imprevedibile se l'attaccante sta attento. In effetti è piuttosto semplice evitare di cambiare l'hash che hai scelto, che è lo XOR di tutti i blocchi. CBC usa XOR internamente, quindi questo non dovrebbe essere una sorpresa completa.

Considera un messaggio costituito da tre blocchi P₁ , P₂ , P₃ e il checksum P₊ crittografato con CBC e lascia che C₁ , C₂ , C₃ , C₊ sia il corrispondente testo cifrato. Scriverò E per la funzione di crittografia dei blocchi e D per la decrittografia.

C₁ = E(P₁ ⊕ IV)
C₂ = E(P₂ ⊕ C₁)
C₃ = E(P₃ ⊕ C₂)
C₊ = E(P₊ ⊕ C₃)         where P₊ = P₁ ⊕ P₂ ⊕ P₃

Il lato ricevente decripta con

P₁ = D(C₁) ⊕ IV
P₂ = D(C₂) ⊕ C₁
P₃ = D(C₃) ⊕ C₂
P₊ = D(C₊) ⊕ C₃

Un attaccante man-in-the-middle ribalta C₁ e C₂ . Ecco cosa vede il destinatario:

P₁' = D(C₂) ⊕ IV
P₂' = D(C₁) ⊕ C₂
P₃' = D(C₃) ⊕ C₁
P₊' = D(C₊) ⊕ C₃

Si noti che P₊' = P₊ - perturbante un testo cifrato CBC ha solo un effetto fino al prossimo blocco dopo la perturbazione, il resto rimane intatto. E

P₁' ⊕ P₂' ⊕ P₃' = D(C₂) ⊕ IV ⊕ D(C₁) ⊕ C₂ ⊕ D(C₃) ⊕ C₁
P₁ ⊕ P₂ ⊕ P₃ = D(C₁) ⊕ IV ⊕ D(C₂) ⊕ C₁ ⊕ D(C₃) ⊕ C₂

Oh, guarda, sono uguali. Il checksum sul messaggio modificato è corretto.

È è possibile progettare un algoritmo MAC basato su CBC, ma devi stare più attento di questo. Un ingenuo CBC-MAC consente attacchi del tipo che hai notato, giocando con la lunghezza. Ci sono varianti che non hanno questo problema. Tuttavia, c'è un problema: non si deve usare la stessa chiave per la crittografia CBC e CBC-MAC! Questo perché se si utilizza la stessa chiave e l'utente malintenzionato ha il controllo su parte del testo in chiaro, l'autore dell'attacco può far sì che il mittente calcoli un MAC per lei. Ad esempio, CBC-MAC di un messaggio a blocco singolo è solo il risultato della crittografia di quel blocco. Pertanto, se l'utente malintenzionato desidera inviare un messaggio a blocco unico, tutto ciò che devono fare è disporre che il mittente crittografi un messaggio che inizia con quel blocco e legge il risultato. È un principio generale che l'uso della stessa chiave per due cose diverse è pericoloso perché consente errori di confusione del protocollo in cui lo stesso calcolo produce dati che devono essere pubblici per uno degli usi della chiave e privati per l'altro uso.

Xor è non buono come un MAC. Infatti, anche la tua lettura iniziale del tag di autenticazione come [dati, SHA1 (dati)] non funzionerebbe, perché La crittografia CBC di un hash non è sicura (il difetto è più sottile che con xor, ma esiste).