Domanda:
Come sapere se un file di testo è stato modificato o manomesso?
Drew Gibson
2016-01-09 19:15:19 UTC
view on stackexchange narkive permalink

È possibile sapere se un file di testo, ad es. in formato XML, è stato modificato o manomesso nel tempo?

Segue il contesto della mia domanda:

Sono uno scienziato nell'industria che utilizza una tecnologia chiamata 'spettrometria di massa (MS) '. La SM è una tecnica analitica utilizzata, ad es. in analisi forense per determinare se un particolare composto è presente in un campione (ad es. droga d'abuso nel sangue o nelle urine).

Mass spec. i file di dati sono solitamente archiviati in formato file flat secondo le specifiche binarie private del fornitore dello strumento: il loro software può elaborarlo, ma nient'altro può farlo. Tuttavia, esistono standard aperti per i dati MS e la maggior parte dei fornitori supporta l'esportazione in almeno una specifica aperta. Questi standard aperti oggigiorno sono principalmente basati su XML (ad es. mzML) e consentono l'elaborazione con applicazioni open source e consentono anche l'archiviazione a lungo termine (> 10 anni) dei dati in un formato che non richiedono di mantenere un computer archiviato e il sistema operativo (o VM) e il software di elaborazione per lunghi periodi.

Il formato binario del fornitore fornisce almeno una certa sicurezza contro la manomissione dei dati, tuttavia i formati XML non lo fanno. Da qui il problema: i formati aperti sono molto utili per fornire l'accesso ai dati su periodi di archiviazione, ma la sicurezza è un problema.

È possibile calcolare gli hash dei file e conservarli in un database protetto (con backup degli originali). Quindi, se sospetti una manomissione, puoi semplicemente ricalcolare gli hash e confrontarli, quindi sostituirli con i backup se necessario.
Chi sei preoccupato di manometterli? Qual è il tuo modello di minaccia?
* Il formato binario del fornitore fornisce almeno una certa sicurezza contro la manomissione dei dati * - Sono abbastanza certo che non lo faccia. Solo perché * tu * non puoi leggerlo e modificarlo quando lo apri con un editor di testo non significa che nessun altro possa decodificare il formato e costruire un editor per esso.
@philipp ha ragione: nella migliore delle ipotesi, questa è "sicurezza dall'oscurità" e non è affatto una protezione contro chiunque abbia una conoscenza rudimentale, un editor esadecimale e un minimo di pazienza.
@JonathanGray: supponendo che i file originali non siano così grandi, in che modo la tua soluzione hash è migliore della semplice archiviazione di un backup dei dati?
@iAdjunct Presumo che l'OP sia preoccupato per i risultati dei test falsificati. Quando hai a che fare con i test antidroga, è una preoccupazione legittima: immagina cosa succederebbe se qualcuno distorcesse i dati di un concorrente per un lavoro ben pagato, facendo sembrare che sia un drogato!
Uhm, leggilo prima e dopo. Se è diverso, è stato modificato. In caso contrario, è lo stesso.
Hai fatto un errore di battitura: il formato binario del fornitore fornisce ** zero ** sicurezza contro la manomissione dei dati
@NeilSmithline Perché gli hash potrebbero essere inviati per la verifica invece di interi file.
Come dice il nostro [help / on-topic], "La sicurezza è un argomento molto contestuale: le minacce che sono ritenute importanti nel tuo ambiente possono essere irrilevanti in quello di qualcun altro e viceversa. [...] Per ottenere le risposte più utili tu dovrebbe dirci: quali risorse stai cercando di proteggere; chi usa la risorsa che stai cercando di proteggere e chi pensi che potrebbe volerne abusare (e perché); quali misure hai già preso per proteggere quella risorsa; quali rischi che ritieni di dover ancora mitigare ". Ti incoraggio a modificare la domanda per aggiungere queste informazioni, in modo da poterti fornire le migliori risposte di qualità.
@philipp fa un ottimo punto. La prima cosa che mi è venuta in mente è stata "dato l'XML di testo semplice e il binario, non mi ci vorrà molto per decodificare il formato di file proprietario". A meno che non stiano effettivamente crittografando, dovrebbe essere semplice. Al massimo, aggiungeranno un'intestazione di identificazione a ciascun valore (https://en.wikipedia.org/wiki/Type-length-value) Temo che dovresti contattare ogni fornitore individualmente e, anche in questo caso, non mi aspetto che rivelino i dettagli della loro "salsa segreta"; al massimo mi aspetterei vaghe rassicurazioni di sicurezza, senza dettagli).
Potresti voler guardare un prodotto software specificamente progettato per l'archiviazione e la gestione dei dati di laboratorio, come un LIMS, ELN (quaderno di laboratorio elettronico) o SDMS (sistema di gestione dei documenti scientifici) - questi sono spesso utilizzati all'interno di sistemi di qualità che devono soddisfare le normative standard come GMP, quindi i fornitori dovrebbero essere esperti in ciò che tali standard si aspettano e su come soddisfarli.
Grazie per tutti i commenti utili. Il problema è la conformità ai requisiti di sicurezza dei dati delle agenzie di regolamentazione. Quelle agenzie potrebbero voler rivedere qualsiasi aspetto dello sviluppo di un composto farmaceutico e l'integrità dei dati è in cima alla loro agenda, ed è giusto che sia così.
Se questo è per il settore farmaceutico, sospetto fortemente che dovresti assumere alcune competenze professionali sulla conformità normativa - presumo che il tuo datore di lavoro non sia in realtà un'azienda farmaceutica, altrimenti lo avresti già in casa?
Questa è una soluzione commerciale, ma probabilmente soddisfa tutte le tue esigenze: prova di integrità e tempo, verificabilità, soluzione a lungo termine ... [www.guardtime.com] (http://www.guardtime.com)
Otto risposte:
Philipp
2016-01-09 20:27:36 UTC
view on stackexchange narkive permalink

La soluzione predefinita sarebbe utilizzare firme crittografiche. Chiedi a ogni tecnico di generare una coppia di chiavi PGP, pubblicare la chiave pubblica e mantenere la chiave privata al sicuro.

Quando un tecnico effettua un'analisi, firma il file dei risultati con la propria chiave privata. Ora chiunque voglia verificare il file può controllare la firma utilizzando la chiave pubblica del tecnico. Quando qualcuno modifica il file, la firma non sarà più corretta.

Considerazioni sulla sicurezza : se la chiave privata di un tecnico viene conosciuta da qualcun altro, quella persona può modificare il file e cambia anche la firma in una che sarà valida. Questo problema può essere mitigato facendo firmare a più persone ogni file dei risultati. Un malintenzionato richiederebbe tutte le chiavi per sostituire tutte le firme con quelle valide.

Soluzione alternativa a bassa tecnologia: Stampa ogni file dei risultati, chiedi al tecnico di firmarlo alla vecchia maniera (con una penna) e depositare il file in un archivio fisicamente sicuro.

A proposito: non dare per scontato che il formato binario specifico del fornitore fornisce una maggiore sicurezza contro la manomissione rispetto a XML. Solo perché non puoi leggerlo e modificarlo quando lo apri con un editor di testo non significa che nessun altro possa decodificare il formato e creare un editor per esso.

I binari specifici del fornitore possono essere ovunque tra davvero facili da cambiare (c'è testo in chiaro, circondato solo da parole), a molto difficili (se usano la crittografia, come questa risposta suggerisce di fare). Non puoi davvero saperlo senza provare probabilmente (a meno che non sia open source).
È MOLTO improbabile che il file binario del fornitore includa la crittografia. Se lo avessero fatto, sarebbe stato fortemente pubblicizzato e sarebbe stato un punto di forza, poiché l'implementazione costa denaro.
Per mitigare la fuga di chiavi private di singoli utenti, potrebbero essere appropriate firme separate da due utenti diversi. Per una conservazione a lungo termine (ovvero quando le chiavi devono essere considerate trapelate semplicemente per la loro età), può essere opportuno dimettersi a intervalli regolari ...
Un piccolo tecnicismo ma non c'è un problema con "Dai a ogni tecnico una coppia di chiavi", in quanto la chiave privata dovrebbe essere nota solo al proprietario? Ogni tecnico non dovrebbe creare la propria coppia di chiavi?
@Qwerky In un mondo perfetto questo sarebbe vero, ma nel mondo reale potrebbero richiedere assistenza.
Stephane
2016-01-09 20:25:48 UTC
view on stackexchange narkive permalink

Va ​​bene qualsiasi forma di firma digitale. Ecco alcuni suggerimenti:

  • Per i dati XML, esiste uno standard di firma digitale ( XMLSign). Sfortunatamente, questo standard è piuttosto scarso e ha un'importante scappatoia di sicurezza (i documenti devono essere normalizzati attraverso una trasformazione XML prima di poter essere firmati. Questo è estremamente difficile da fare in modo sicuro poiché la trasformazione stessa diventa una parte importante della firma).

  • Puoi anche utilizzare PGP o S / MIME per firmare digitalmente i documenti. Questi produrranno nuovi documenti basati su testo e documenti per lo più leggibili ma comunque a prova di manomissione.

  • Infine, puoi usare firme separate. Fondamentalmente, è un altro file che contiene la firma digitale collegata a un altro documento e può essere utilizzato per convalidare i dati originali (indipendentemente dal formato originale).

Lasciami aggiungere alcune informazioni extra qui:

  • Scegliere le proprietà giuste per la firma (algoritmo, tipo e dimensione della chiave, ecc.) dipende molto dalla condizione che imposti: quanto tempo intendi avere i dati al sicuro, contro che tipo di avversario intendi proteggerli (qual è il valore di un falso? quale sarebbe il valore di un attacco che romperebbe tutti i documenti firmati con la stessa chiave?), c'è qualche requisito normativo? Ciò significa che dovresti consultare uno specialista in grado di tradurre questi requisiti aziendali e tradurli in quelli tecnici.
  • Ti consiglio vivamente di aggiungere un timestamp sicuro alla tua firma. Questo non solo ti permetterà di provare che un documento non è stato manomesso, ma ti permetterà anche di provare quando è avvenuta la firma.
Timestamp sicuro? Come provi che una firma è avvenuta in un momento specifico?
Il protocollo è descritto in rfc 3161. Fondamentalmente, prendi un hash dei dati della tua firma, lo invii a un server di timestamp sicuro che ti rimanda una versione firmata dell'hash. Quindi lo aggiungi alla tua firma.
Ahh, quindi è necessario affidare la fiducia a una terza parte.
@BlacklightShining lo fa, ma impedisce vettori di attacco molto reali, ad esempio un insider maligno (ad esempio i tuoi tecnici) o un aggressore con accesso a tutte le * tue * chiavi non sarà comunque in grado di falsificare i timestamp e se quella terza dannoso o compromesso quindi * da solo * non è sufficiente divulgare o modificare i tuoi dati. Uno svantaggio è che la connessione di rete a quel server timestamp può esporre quante firme stai facendo e quando esattamente lo stai facendo, a seconda della tua situazione potrebbe essere irrilevante o pericoloso.
Potresti incorporare l'hash della firma nella blockchain bitcoin, quindi non devi fidarti di una terza parte. Tuttavia, non è abbastanza gratuito.
Tutti gli schemi di firma digitale si baseranno, a un livello o nell'altro, sulla fiducia riposta in una terza parte: è necessario affermare l'identità della chiave utilizzata per la firma. Ciò non significa che sia necessario riporre molta fiducia, in terze parti, duro: ad esempio, l'autorità di timestamp è solo responsabile di garantire che, in un dato momento, un dato specifico già esistesse (attraverso il suo hash).
+1 per il timestamp, soprattutto perché molti casi giudiziari hanno prove chiave rese inammissibili a causa del fatto che i computer che le producono hanno impostato l'ora errata. Molte delle principali autorità di certificazione x509 forniscono servizi di timestamp, ma dovrai utilizzare un formato di file compatibile.
@billc.cn In realtà no, non è necessario utilizzare un formato di file compatibile. Questo è quello che ho spiegato nel mio post: puoi inserire i dati in PGP / SMIME o semplicemente usare una firma separata
Perché non firmare semplicemente il file .xml con PGP?
@Joshua PGP non ha timestamp sicuri.
AilikcnyffCMT http://www.itconsult.co.uk/stamper.htm
@Joshua bene, stanno usando PGP / GPG, ma non puoi usare il tuo GPG / PGP e ottenere solo un timestamp. Devi inviare loro il file (quindi crittografalo prima!) E poi lo firmeranno con PGP e devi fidarti di loro per usare la data corretta e non perdere le chiavi. Sembra non proprio adatto per questo caso d'uso Non conoscevo questo servizio, quindi grazie per aver menzionato che esiste!
Potresti semplicemente inviare loro il file .asc della firma separata per averla firmata.
Artelius
2016-01-11 02:02:39 UTC
view on stackexchange narkive permalink

Descriverò le tre principali opzioni e pro / contro di ciascuna.

Archivia i backup dei file in un luogo sicuro

Abbastanza autonomo esplicativo. La "posizione sicura" può essere un supporto di sola lettura (come i CD), o un'unità di rete che tutti possono leggere ma su cui solo il supervisore può scrivere, o un servizio di archiviazione online (ad esempio Dropbox) che rende ragionevolmente difficile falsificare il file date di modifica.

Pro

  • Dovresti comunque avere un sistema di backup

Svantaggi

  • Se i file sono di grandi dimensioni, scaricarli per la verifica può richiedere molto tempo
  • Se il falsario irrompe nella posizione sicura, può coprire le sue tracce

Archivia gli hash in un luogo sicuro

Un hash è l'impronta digitale di un file che ha un aspetto simile a 8f2e3f53aa90b27bda31dea3c6fc72f6 ; se due file sono leggermente diversi avranno un hash diverso. Prendi un hash del file originale e memorizzalo in modo sicuro, quindi per verificare che un file non sia stato modificato, prendi un hash e confrontalo con l'hash memorizzato.

Pro

  • Devi memorizzare / controllare in modo sicuro un codice di circa 32 cifre invece di un intero file

Svantaggi

  • È ancora necessario accedere a una risorsa esterna per controllare il file
  • Se il falsario entra nella posizione sicura, può coprire le sue tracce

Firme crittografiche

In questo caso, una o più persone possono "firmare" il file e se vengono apportate modifiche queste firme verranno invalidate. Ovviamente, se tutti coloro che hanno bisogno di firmare il file sono disposti a (o indotti con l'inganno a) firmare un file manomesso, puoi farla franca con il file manomesso.

Pro

  • Le informazioni di sicurezza possono essere conservate all'interno del file stesso , o comunque sulla stessa unità, il che significa una verifica più semplice.

Contro

  • Chiunque firmi i file deve essere molto attento a impedire che qualcuno rubi la propria chiave privata.
  • Chiunque firmi i file deve stare molto attento perché sa cosa stanno firmando.
Per Alexandersson
2016-01-11 03:08:10 UTC
view on stackexchange narkive permalink

Prendi il tuo file xml e la tua foto delle vacanze preferita. Concatena i file e calcola diversi valori hash del file risultante.

L'immagine delle vacanze garantisce che sia estremamente difficile produrre una collisione, anche se il file della foto delle vacanze è pubblico. Inoltre, se utilizzi diversi algoritmi di hash, è improbabile che tutti questi vengano interrotti in un arco di tempo di 10 anni.

Concatenare tutti i file di dati con la stessa foto non aiuterà molto. È meglio usare algoritmi di hash più costosi dal punto di vista computazionale su dati puri.
Non è questo "banalmente" sconfitto da un attacco di estensione della lunghezza?
Se la foto delle vacanze non è nota al pubblico, è molto difficile e con più hash, ancora più difficile.
Chris H
2016-01-11 15:19:07 UTC
view on stackexchange narkive permalink

Affrontare la sicurezza del formato di file del fornitore, espandendo ciò che @Philipp dice nei commenti.

Ho avuto un problema con un formato di file del fornitore (non specifica di massa ma abbastanza vicino per questi scopi). È stato reso molto più semplice avendo il software installato, ma non sono esperto in queste cose. Potrei facilmente cambiare i metadati (estrarre i metadati era il mio obiettivo in primo luogo) i dati reali sarebbero stati più difficili ma non impossibili da modificare. Poiché i metadati includono cose come l'ID del campione e la data del test, questa è una vulnerabilità abbastanza grande per cose come "il cui campione era pulito e quando? " come ti sembra pertinente, o "che ha scoperto per primo questo farmaco? " in altri campi.

Alcuni software forniscono alcune funzionalità anti-manomissione (ad es. uso interno di hash, non necessariamente crittografici; autorizzazioni utente durante la modifica utilizzando il loro software ). Il reverse engineering di questi sarebbe poco più che banale per qualcuno con un po 'di abilità decente nella maggior parte dei casi. Con il software installato, anche aggirare le funzionalità integrate potrebbe essere semplice come scrivere un front-end per chiamare le DLL del fornitore, poiché queste funzionalità anti-manomissione sono normalmente componenti aggiuntivi opzionali (in molti campi non sono obbligatori o deprecati ).

(Questa avrebbe potuto essere una sequenza di commenti, ma poiché il mio obiettivo era rendere più chiaro il problema del file del fornitore, mi è sembrato meglio scriverlo correttamente).

billc.cn
2016-01-11 16:30:26 UTC
view on stackexchange narkive permalink

Che ne dici di fare in modo che i tecnici pubblichino coppie di ID file univoci e i loro hash su Twitter utilizzando i propri account?

Ciò dimostrerà che:

  • File di dati con detto id e hash esistevano al momento della pubblicazione
  • La persona che ha accesso all'account si fida del contenuto del file a quel punto
  • Il file non viene modificato dopo il fatto come Twitter non consente la modifica dei tweet

Questo metodo fornisce una sicurezza almeno paragonabile a molte delle risposte e dei vantaggi basati sulla firma digitale come:

  • Molto più semplice da apprendere e utilizzare (nessuna procedura complicata di generazione di chiavi private, apertura o backup)
  • Alta ridondanza (tramite backup di Twitter e siti di scraping di Twitter di terze parti)
  • Timestamp integrato ( che probabilmente rimarrà in un procedimento legale senza molte spiegazioni)

Raccomando di utilizzare almeno SHA256 come algoritmo hash.

gbjbaanb
2016-01-11 21:14:43 UTC
view on stackexchange narkive permalink

Uno dei modi più semplici è creare un hash del file e archiviarlo altrove in modo da sapere se viene modificato. I programmi di rilevamento delle intrusioni utilizzano sempre questa tecnica per verificare l'integrità (o almeno per indicare se qualche utente malintenzionato ha armeggiato con i file di sistema).

Guarda un programma come AIDE , puoi eseguirlo sulla directory contenente i file (ed eventualmente eseguirlo su richiesta quando viene aggiunto un file) per aggiornare il suo database di hash. Ogni notte, eseguilo per controllare e inviarti via email un rapporto che mostra tutte le modifiche ai file.

Se hai bisogno di conoscere l'originale, allora un filesystem con versione potrebbe essere una buona idea. Ogni modifica apportata a un file viene registrata e le vecchie versioni possono essere estratte. In alternativa, potrebbe essere utilizzato un sistema di backup che rileva nuovi file e li esegue il backup in una posizione sicura (e mantiene tutte le vecchie versioni - oppure un utente malintenzionato potrebbe semplicemente modificare il file ripetutamente finché l'originale non viene eliminato).

user96474
2016-01-10 13:28:21 UTC
view on stackexchange narkive permalink

i formati aperti sono molto utili per fornire accesso ai dati su scale temporali di archiviazione, ma la sicurezza è un problema

Grande domanda: come si accede agli archivi?

Il problema con l'hashing di un file di testo semplice è che l'hash è accurato per i caratteri. Cambia un carattere e l'hash sarà completamente diverso. Funziona molto bene per i file binari come i programmi eseguibili (dove un byte fuori posto è solitamente disastroso) ma fallisce su cose come i file di markup: la normalizzazione (o la compattazione) dello spazio cambierà l'hash ma non avrà alcun effetto sui dati.

Se stai distribuendo i file tramite e-mail o condivisione di rete di lettura-scrittura, dovrai disporre di una memoria sicura per l'hash, altrimenti chiunque abbia metà cervello può modificare il file e quindi aggiornare l'hash. Se hai una memoria sicura per l'hash, perché non memorizzare il file di dati nello stesso posto e dimenticare l'hash?

All'inizio sembrerà strano, ma guarda come caricare il file e la descrizione su un'installazione locale di qualcosa come wordpress o mediawiki. L'accesso può essere aperto o sicuro come desideri e le piattaforme hanno controlli di caricamento dei file specifici dell'utente. Una volta che il reparto IT lo ha configurato correttamente, l'accesso in scrittura ai file può essere bloccato quanto necessario.

"* o chiunque abbia un mezzo cervello può modificare il file e quindi aggiornare l'hash *": questo non è possibile quando si utilizza la firma digitale a meno che la chiave privata non sia stata compromessa.
-1, manca le soluzioni standard, che è utilizzare firme crittografiche.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...