Svolgi una challenge
Prova ad effettuare un attacco bit-flipping su questa challenge, realizzata appositamente: beat-it.challs.scalfarodev.edu.it
CBC garantisce confidenzialità, ma non garantisce né integrità dei dati né autenticazione del mittente che li invia.
Lo schema, infatti, è malleabile: un attaccante che conosce (o può indovinare) parte del plaintext può modificare il ciphertext in modo mirato senza conoscere la chiave.
Supponiamo di voler modificare il secondo blocco di plaintext (PLAIN2) iniettando un valore scelto PLAIN2_inj. Il calcolo da applicare è il seguente, per la proprietà intrinseca dello XOR:
C1_attack = PLAIN2_inj ^ PLAIN2 ^ C1_originale
Modificando il blocco C1 (ciphertext precedente), il blocco PLAIN2 verrà decifrato esattamente come desiderato dall'attaccante.
Questo specifico attacco renderà il blocco
PLAIN1illeggibile (effetto valanga). Tuttavia, se l'attaccante volesse modificare il primo bloccoPLAIN1senza rompere nulla, gli basterebbe applicare la stessa formula modificando direttamente l'IV iniziale.
Questo attacco è possibile solo se l'attaccante conosce (o può prevedere) il plaintext originale di tutta la stringa.
Per questo motivo Cryptea consiglia fortemente di utilizzare sempre l'HMAC (server o utente) quando si sceglie la modalità CBC.
Per ovviare alla mancanza di integrità di CBC, la nostra applicazione implementa due meccanismi di firma:
Il server genera e verifica una firma utilizzando una chiave segreta condivisa solo sul server. Questa firma protegge IV + ciphertext e permette al backend Java di rilevare eventuali modifiche.
L'utente può firmare il messaggio con la propria chiave privata RSA. Il server verifica la firma utilizzando la chiave pubblica corrispondente.
Entrambe le firme vengono calcolate sul concatenamento IV + ciphertext e restituite in codifica Base64 insieme al messaggio cifrato.
Nella cifratura dei file, per ragioni di sicurezza, viene abilitata solamente la modalità CBC + firma con chiave privata.
