Un certificato autofirmato è sufficiente per dimostrare l'integrità del mio eseguibile?

È importante che la persona che riceve il file la controlli contro la tua chiave pubblica. Chiunque può creare un certificato autofirmato e puoi inserire qualsiasi metamodice che desideri. Quindi, due certificati autofirmati possono apparire e comportarsi in modo identico, l'unica cosa che li differenzia è la coppia di chiavi utilizzata per firmarlo.

In altre parole, e rispondendo al tuo commento sulla risposta di Jeff, non puoi visivamente distinguere tra un certificato legittimo e un falso, se per esempio il sistema operativo o il browser o qualunque cosa compaia in una finestra che mostra i suoi dettagli. I certificati firmati da un'autorità fidata, OTOH, verranno mostrati insieme a un nome / collegamento più difficile (quasi impossibile?) Da falsificare.

Ma se la tua chiave pubblica viene pubblicata / inviata ai tuoi clienti, possono verificare (o dimostrare in seguito) se il file è legittimo. Poiché nessun altro conosce la tua chiave privata, non può creare un certificato (autofirmato o meno) che lo abbini, anche se i meta-dati hanno lo stesso aspetto.

Chi vuoi dimostrare l'integrità dell'eseguibile?

Se è per te, puoi semplicemente conservare una copia dell'eseguibile che hai inviato e confrontarlo.

Se è a qualcun altro un certificato autofirmato non aiuta affatto. Chiunque modifichi l'eseguibile può anche generare un certificato autofirmato con proprietà identiche alle tue e firmare nuovamente l'eseguibile.

I would like to know if this ever happen, so that if anyone complains about what they received I can check if the file is really the one I sent or if anyone modified it.

Risponderò a questa domanda secondaria . Il checksum del file (pubblicato) darà a te e ai tuoi clienti meno mal di testa con un livello di protezione paragonabile, ancora di più: nessuno potrà ottenere lo stesso hash SHA2 sul file modificato, come su non modificato.

La tua idea sembra corretta. Nessuno dovrebbe essere in grado di cambiare il file e fare in modo che la firma funzioni ancora. E nessuno dovrebbe essere in grado di creare un'altra firma digitale senza la tua chiave privata.

Una firma dimostra che l'oggetto è stato firmato dal proprietario del certificato. Niente di più. Se il certificato può essere facilmente rintracciato a te, dimostra che è stato firmato da te.

Ora, se qualcuno che l'utente si fida (ad esempio Microsoft, Verisign, ecc.) firma il tuo certificato, allora ciò dimostra che hanno firmato il tuo certificato. Presumibilmente lo faranno solo se si fidano di tu .

Quindi, in teoria, hai una catena di fiducia che risale all'utente, ognuno dei quali si fida di quello successivo, e quindi l'utente si fida implicitamente di te.

Se, d'altra parte, il tuo certificato non è firmato da nessuno (cioè un certificato autofirmato, poiché tutti i certificati hanno una firma), allora l'utente non si fida implicitamente della tua firma , ma se hanno un modo per verificare che il certificato sia tuo (ad esempio lo dai a loro di persona), allora il tuo certificato può diventare un altro punto di riferimento, proprio come i certificati forniti da Verisign o Microsoft.

in modo che se qualcuno si lamenta di ciò che ha ricevuto, posso controllare se il file è veramente quello che ho inviato o se qualcuno lo ha modificato.

Il modo tradizionale di verificare se un file viene modificato è da utilizzare l'utility " md5sum " o il (probabilmente superiore) " sha256sum " utility.

Molte organizzazioni utilizzano questa tecnica per verificare che i file, scaricati da "siti mirror" che sono convenientemente vicini (e quindi più veloci del download dal "sito originale" in qualche altro continente), non siano stati modificati maliziosamente o accidentalmente da qualche parte sul percorso dall'originale, al sito mirror, alla destinazione finale. a b c d e

Usando queste utility, qualcuno con la versione originale del file genera un breve hash md5 o un breve hash sha256 (o entrambi) del file originale, e memorizza quel breve hash in qualche file di testo da qualche parte. (Tipicamente sul "sito originale" e su ogni sito mirror).

Successivamente, qualcuno con un file discutibile esegue la stessa utility, producendo un nuovo valore hash. Se il nuovo valore hash è identico all'hash prodotto dal file originale (che l'hash viene in genere ottenuto dal "sito originale", possibilmente utilizzando un browser Web e https e TLS), allora puoi essere certo che il file discutibile è, infatti, identico al file originale.

Alcuni paranoici scaricano la somma hash da diversi "siti mirror" e altre fonti. (Questo è veloce, perché la somma dell'hash è molto breve, molto più veloce del nuovo download dell'intero file da tutte quelle fonti). La probabilità che tutte quelle fonti siano state sovvertite diventa sempre più improbabile dal momento che vengono consultate più fonti.

(Dato che stai generando l'eseguibile originale, tieni presente che ricompilare esattamente gli stessi file sorgente usando esattamente lo stesso compilatore di solito produce un file eseguibile leggermente diverso, risultando in un hash completamente diverso. Vedi " Come si verifica che 2 copie di un eseguibile VB 6 provenissero dalla stessa base di codice? " per dettagli).

Ci sono molte utility che si basano su md4sum o sha256sum.

• md5deep e hashdeep può fare un "riassunto" di un'intera cartella in un determinato momento: forse la tua home directory, o la directory / bin, o la cartella radice di un intero disco rigido. Successivamente, ti dirà esattamente quali file sono stati aggiunti, cancellati o modificati da quando è stato effettuato il riepilogo. Quando gli hash corrispondono, puoi essere certo che i file eseguibili non siano stati infettati da un virus dopo lo snapshot originale: questo rileva anche nuovi virus che non sono ancora stati riconosciuti da alcun programma antivirus. (Gli scanner antivirus sono ancora utili per rilevare i file infetti da un virus prima dello snapshot originale).

• bittorrent usa sha1 per confermare che pezzi di un file scaricato da macchine completamente non attendibili sono identici ai pezzi originali di quel file.

• rsync usa md5sum per controllare rapidamente se il file locale è identico alla copia master di un file su qualche file server remoto. Se sono diversi, si presuppone che la copia locale sia una versione obsoleta e scarica automaticamente le differenze tra i due file, modificando il file locale finché non diventa identico al file master remoto.

Sono abbastanza sicuro che alcuni protocolli potrebbero essere sviluppati usando un certificato autofirmato che funzionerebbe altrettanto bene che usando sha256sum; ma non vedo come questo nuovo protocollo possa offrire vantaggi rispetto al controllo sha256sum comunemente usato.