Come garantire l'integrità dei file crittograficamente?

Prima di tutto: da un punto di vista della sicurezza i file corrotti e manomessi sono gli stessi. L'integrità non è più data. Periodo. In entrambi i casi hai bisogno di backup.

I checksum sono un buon approccio. Come hai notato, se il sistema che memorizza i tuoi file è compromesso, hai bisogno di un sistema esterno (questo significa trusted ) per garantire che le tue misure di sicurezza non siano compromesse. Invece di utilizzare i checksum su un sistema esterno, puoi firmare i file e archiviare la firma con loro o utilizzare HMAC anziché SHA256 semplice. Ciò garantisce che un utente malintenzionato non possa falsificare una firma / somma di controllo se apporta modifiche ai file, in modo da notare qualsiasi tipo di manomissione.

In entrambi i casi è sufficiente memorizzare un segreto (chiave privata o chiave HMAC) su un computer esterno. Inoltre, i controlli di integrità possono essere eseguiti da qualsiasi macchina che abbia accesso al segreto (non è necessario un elenco di checksum, in quanto possono essere memorizzati con i file stessi).

Esistono diverse implementazioni di HMAC (o altri algoritmi di hash basati su chiavi) e algoritmi di firma. Ciò che meglio si adatta alle tue esigenze dipende dal tuo ambiente.

Una soluzione semplice sarebbe quella di memorizzare i checksum in un file con firma digitale nella stessa posizione.

Finché si mantiene il controllo della chiave privata utilizzata per la firma, è possibile verificare facilmente l'integrità dell'intero insieme di file senza avere accesso a quella chiave.

Qualcosa di simile è implementabile con PGP .

Se comprendo correttamente il requisito:

1. Hai una collezione di file nella posizione A
2. Vuoi garantire l'integrità dei file nel tempo nella posizione A
3. Hai più backup dei file

La soluzione mi sembra ovvia, il che suggerisce che forse mi sono perso qualcosa nei requisiti. Ma hai già i backup - quindi hai già i checksum (o puoi calcolarli facilmente dai backup).

Se la posizione A è stata compromessa, non è più necessario prendere i file dalla posizione A (e confrontare i loro checksum) - basta prendere i backup!

Ad esempio, ho un sito web wordpress (che è una raccolta di file php, file immagine e un file di backup .sql). I backup dei file tutti i giorni alle 12:00. Se il mio sito è stato compromesso o infettato da malware, eseguo semplicemente il ripristino dal backup.

Finché ho una storia ragionevole di backup (~ 30 giorni per esempio), posso sempre tornare indietro nel tempo, quando l'infezione ha avuto luogo. Ad esempio, gli aggressori compromessi dal file index.php . Potrei tornare indietro e esaminare la cronologia dei file per oltre 30 giorni per capire quando è avvenuta l'infezione e ripristinare dall'ultimo backup "valido".

Il problema nella tua domanda iniziale era che stavi cercando di stabilire l'integrità dei file su un sistema locale usando solo quel sistema locale.

Penso che ciò che ti manca nel ragionamento sia l'importanza della ridondanza. Dici che se hai bisogno di fare affidamento su un sistema esterno o su un supporto esterno di cui ti fidi per archiviare i checksum, allora perché non archiviare i file e dimenticare l'integrità, dal momento che quel sistema o mezzo sarà comunque considerato affidabile? Il fatto è che non devi fidarti di un sistema o di un supporto, ma devi fidarti della "ridondanza", ovvero del fatto che è meno probabile che i dati vengano compromessi contemporaneamente su diversi sistemi o mezzi di comunicazione.

Quindi quello che devi fare è questo:

1. Hai i tuoi file e i tuoi checksum sul sistema o sulla media A.
2. I tuoi file e i tuoi checksum su altri sistemi o supporti, B, C, D, ecc. come backup, quanti ne vuoi. Maggiore è il numero di backup, maggiore è la ridondanza e maggiore è la probabilità di rilevare manomissioni. Nota che devi ridurre la probabilità che tutti i dati vengano compromessi allo stesso tempo, quindi ad esempio puoi tenere A e B in posti diversi, ecc.
3. Per verificare l'integrità su A, calcola i checksum di tutti i file, quindi esegui un diff computed_checksums.txt stored_checksums.txt . Se l'integrità è ok, diff non dovrebbe riportare differenze. Fai lo stesso per gli altri sistemi o supporti, B, C, ecc.
4. Ora hai appena verificato l'integrità semplicemente affidandoti ai checksum memorizzati sullo stesso sistema o supporto. Ma come puoi assicurarti che i checksum siano affidabili? Facile: basta calcolare il checksum dei checksum memorizzati su A (come sha256sum checksums_stored_on_A.txt ), quindi fare lo stesso su B, C, ecc. Se il checksum risultante è lo stesso, significa che tutti i file di checksum sono gli stessi. Possono essere affidabili perché si sta fidando del fatto che è improbabile che tutti siano stati compromessi allo stesso modo in sistemi diversi o su supporti diversi. Se uno o più checksum risultanti risultano diversi dagli altri, ovviamente è necessario scoprire quali backup sono effettivamente sicuri e quali sono stati compromessi.

Un paio di note:

Sistemi infetti. Questo metodo non funziona in teoria se si utilizza un sistema infetto per gestire i file, collegare media esterni, checksum di calcolo, ecc. Il motivo è che in teoria un il sistema infetto non può essere considerato attendibile, quindi anche il comando sha256sum potrebbe essere compromesso, o cp o bash in generale, ecc. Per ridurre la probabilità di problemi relativi a un sistema infetto, è possibile verificare l'integrità su diversi sistemi, magari anche con sistemi operativi diversi, ecc.

Verifica dei checksum. Perché controllo i checksum utilizzando diff computed_checksums.txt stored_checksums.txt , anziché sha256sum -c stored_checksums.txt ? È perché sha256sum -c stored_checksums.txt controllerà solo i file elencati in stored_checksums.txt , e non farà in modo che ogni file del tuo backup abbia un checksum corrispondente da verificare. In altre parole, se un file dannoso è aggiunto al tuo backup, usando sha256sum -c stored_checksums.txt non lo saprai mai. D'altra parte, se usi il mio metodo con diff , verrà visualizzato il file aggiunto: sarà nei checksum calcolati, ma non nei checksum memorizzati.