Usa un hash precalcolato per firmare un file con GnuPG

Questo è possibile, anche se in un livello leggermente diverso da quello che stai chiedendo. Invece di eseguire il comando gpg nella macchina per la firma, esegui invece gpg-agent e inoltra il socket del gpg-agent alla macchina che calcola la firma. Questo è effettivamente lo stesso di quello che stai chiedendo, tranne che eseguiresti il comando gpg / gpg2 sulla macchina che calcola l'hash piuttosto che quello che calcola la firma.

In alternativa, puoi inserire la chiave privata su una smart card OpenPGP, che può fungere da agente chiave.

Tuttavia, per la massima sicurezza, potresti voler avvolgere l'agente gpg in un servizio che crea registri di controllo di qualsiasi cosa venga firmata / crittografata. Molte smart card OpenPGP eseguono questa operazione, sebbene lo spazio di archiviazione limitato in una scheda possa limitare lo spazio di archiviazione del log di una smartcard.

Are there any disadvantages to this security-wise?

Sì, la macchina per le firme sarà cieca firmando tutto ciò che l'hashing dice di firmare. Non ha modo di imporre un criterio su ciò che sta firmando (es. La directory frobnicate deve essere firmata da un'altra persona, sekrit.c deve contenere la stringa "42", il tracker dei problemi deve essere impostato su "Spline reticolare"), hai affidarsi alla macchina di hashing per verificare la politica di firma.

Sono abbastanza sicuro che non c'è modo di renderlo indistinguibile con GnuPG standard. GnuPG è open source quindi potresti ovviamente modificarlo e implementa uno standard aperto in modo da poter usare un'altra implementazione (che può ottenere / utilizzare la chiave di firma) che è probabilmente più facile da modificare, come BouncyCastle almeno nella versione Java (che uso io, non sono un dotnetter) (sebbene sia possibile installare Java su un sistema di sicurezza significativo potrebbe essere un argomento su proprio).

Un'alternativa che è un IME abbastanza comune e accettato consiste nell'utilizzare due fasi :

• usa sha1sum (non più preferito) o sha256sum o simile per creare un file (piccolo), ad es. "hash" contenente il nome e hash (hex) dei file reali; se in una versione logica sono presenti più componenti e / o varianti e / o file correlati, è possibile inserire più hash e nomi in un unico file "hash"

• Segno di stacco PGP o firma chiara del piccolo file "hash"

Il destinatario corrispondentemente

• PGP verifica il file 'hash'

• utilizza sha256sum -c hash o simili per verificare che i file reali corrispondano all'hash (es) nel file 'hash'

Ciò consente a un destinatario che non ha un'implementazione PGP (o non può ottenere o non si fida della chiave di firma, ma è meno probabile) ma chi può ottenere il file "hash" in modo sufficientemente sicuro, ad es. da un sito Web HTTPS, per verificare il / i file / i, che andrebbe da difficile a impossibile con solo una firma PGP.

Ovviamente è necessario assicurarsi che il valore hash nel metodo A, o il file 'hash' nel metodo B, venga trasferito dall'hashing maching alla macchina per la firma da un canale che non può essere bloccato o manomesso da qualsiasi avversario, così come ognuno di loro è al sicuro da solo.

Questa è una domanda interessante. Purtroppo non ho una buona risposta per te, solo alcune altre cose a cui pensare.

Sto pensando lungo le seguenti linee:

Il guadagno più ovvio che si ottiene spostando il passaggio della firma sul proprio host è che è possibile isolare la chiave privata utilizzata per le firme su una macchina che esegue solo la firma e quindi la protegge meglio da eventuali furti o abusi.

Ma poi comincio a chiedermi: è davvero rilevante?

Se mantieni il codice e la chiave di firma su un altro host, dovrai mettere in atto un tipo di servizio che invia all'host della firma gli hash (o file) da firmare e l'host della firma ti restituirà una firma valida .

Ora supponiamo che l'host con i file di rilascio sia stato violato. L'autore dell'attacco sarà probabilmente in grado di utilizzare il servizio di firma per ottenere qualsiasi contenuto che sceglie firmato (e se non lo fa, ciò significa che non ottiene l'accesso completo alla radice e che non avrebbe avuto accesso a una chiave di firma seduta direttamente sull'host, o). Quindi, anche se non controlla la chiave privata utilizzata per la firma, può comunque ottenere ciò che vuole: firme valide sul suo contenuto scelto.

Fondamentalmente, guardalo da questa prospettiva: la sicurezza dell'host che contiene i file di rilascio è assolutamente critica. Se viene violato e un utente malintenzionato riesce a modificare i file di rilascio, non importa se non ha accesso alla chiave di firma.

Inoltre, separando la fase di firma, hai creato una nuova via di attacco: se un utente malintenzionato non può accedere al server che conserva i file di rilascio, potrebbe tentare di ottenere l'accesso al servizio di firma. Se riesce a posare con successo come server che mantiene i file di rilascio, o comunque accede al servizio, hai anche perso.

Quindi, che cosa hai guadagnato in sicurezza separando l'host file e l'host di firma? Se il motivo principale per cui non si firmano i file di rilascio in cui si trovano, ma lo si fa su un host diverso, è in realtà per proteggere la chiave, non è possibile utilizzare una chiave master per firmare una chiave di firma con essa, proteggere la chiave master mantenendolo offline e utilizzando la chiave di firma direttamente sull'host con i file di rilascio?

Se l'host è stato violato, è possibile revocare la chiave di firma e crearne una nuova, nuovamente firmata dalla chiave master.