A quale livello di attendibilità dovrei fornire le chiavi necessarie per la crittografia?

8

Poiché sto crittografando i backup del server, di solito installo la mia chiave GPG pubblica da un server delle chiavi nel portachiavi del server:

gpg --search-keys 6569758F

Importa la chiave nel mio mazzo di chiavi.

Quindi tento di crittografare un file:

gpg --encrypt --recipient 6569758F myfile.log

Ora mi viene presentato qualcosa di simile a questo:

gpg: EE928AAF: There is no assurance this key belongs to the named user

pub  4096R/EE928AAF 2013-12-05 Naftuli Tzvi Kay <[email protected]>
 Primary key fingerprint: 0E26 BDF1 BD1C 4A16 9571  21A8 8938 1D75 6569 758F
      Subkey fingerprint: 65F4 87F2 C898 F0E7 0377  EBA1 8484 EC48 EE92 8AAF

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 

Ora ho bisogno di 'fidarmi' della chiave. Tuttavia, ho scoperto che a meno che non mi fidi della chiave "in definitiva", vale a dire: livello 5, ottengo questo prompt ogni volta che ho bisogno di crittografare qualcosa, che non funziona troppo bene per gli script di shell.

Devo davvero fidarmi di una chiave, in definitiva, semplicemente di crittografare i file con essa?

    
posta Naftuli Kay 06.12.2013 - 22:34
fonte

2 risposte

5

Il titolo del post e la domanda effettiva che stai chiedendo non corrispondono esattamente. Se sto leggendo questo, stai chiedendo il modo migliore di usare la tua chiave PGP pubblica per crittografare i backup. D'altra parte, il titolo della domanda è di assegnare i livelli di attendibilità alle chiavi per la crittografia. Mi sembra che tu stia usando la tua chiave per la crittografia, quindi assegnarti un livello di fiducia non è quello che stai cercando. IMHO stai usando il 'trust model' errato di GPG per il problema del backup.

Puoi bypassare esplicitamente tutta la convalida della chiave in GPG modificando il 'modello di attendibilità' per il comando che stai eseguendo. Per impostazione predefinita viene utilizzato il modello di trust 'PGP', motivo per cui GPG si aspetta che tu segni esplicitamente le chiavi come affidabili. In alternativa, puoi indicare a GPG di utilizzare il modello di trust "sempre" che ignorerà il messaggio visualizzato:

--trust-model always

Penso che questo ti porterà il comportamento che cerchi. Tuttavia, tieni presente che lo script sta scaricando una chiave da un host remoto che non controlli, quindi non hai alcuna garanzia che sia la chiave che ti aspetti (compromissione del server chiave). Se si prevede di utilizzare l'unica chiave per crittografare i backup, potrebbe essere sufficiente incorporare semplicemente la chiave pubblica nello script (non è sensibile) e tagliare completamente il server di chiavi dall'architettura. Questo rimuoverà ogni affidamento sul server delle chiavi e semplificherà le relazioni di fiducia nella soluzione di backup.

Solo un pensiero. Spero che questo aiuti.

Come richiesto ecco un esempio. Supponiamo di voler raccogliere i dati di backup su un sistema che gestisco. Voglio solo che questi dati di backup siano recuperabili da solo. Per raggiungere questo obiettivo, voglio che tutti i dati raccolti nello script vengano crittografati con la mia chiave PGP pubblica. Suppongo anche che l'account utente che esegue il backup non sia utilizzato per scopi diversi dai backup, quindi non c'è nulla di importante nella directory ~ / .gnupg e che posso eliminarlo senza preoccuparmi di perdere le chiavi.

RIMUOVI SEMPRE la directory .gnupg prima di giocare con questo!

Quello che segue è un semplice script bash che crittografa del testo con una chiave pubblica incorporata nello script:

#!/bin/bash -e                                                                 

gpg --trust-model always --import <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

xxxxxx
...
...
-----END PGP PUBLIC KEY BLOCK-----
EOF

echo "backup data" | gpg --trust-model always --armor  --encrypt --recipient [email protected] > backup-data.enc

La 'magia' in questo script è l'uso della shell ' Qui documento (vedere i marcatori EOF) per incorporare la mia chiave pubblica nello script mentre la si passa a gpg su stdin per importare la chiave prima di eseguire l'attività di crittografia / backup. Ovviamente nel mio esempio dovrai mettere tutta la tua chiave pubblica blindata ASCII al posto di "...". Assicurati inoltre di sostituire "[email protected]" con l'ID associato alla tua chiave pubblica. In genere questa è la tua email.

C'è un milione di modi per pulire questo esempio e renderlo più utile. L'importazione della chiave pubblica in ogni esecuzione è un po 'ridicola, quindi controllando se la chiave è già sul ring è dove iniziare:)

Buona fortuna!

    
risposta data 06.12.2013 - 23:41
fonte
1

Quando attribuisci la massima fiducia in una chiave, la definisci come tua.

Fiducia consente di prendere in considerazione una chiave valida durante il calcolo della validità di altre chiavi. Per essere valido, è necessario avere un percorso di fiducia per questa chiave, che si realizza firmandolo (o avere il percorso delle firme dalla chiave alla chiave, tutto considerato attendibile).

Questo è piuttosto confuso all'inizio, soprattutto perché i termini sembrano confusi. ho spiegato il web di fiducia in ulteriori dettagli in questa risposta.

Se sai chi è il proprietario della chiave e lo hai verificato, puoi semplicemente firmare la chiave (e magari anche inviarla a un server delle chiavi). Se non sei troppo sicuro, puoi utilizzare una firma locale (che non verrà mai caricata / esportata) usando la tua chiave. Entrambi si assicureranno che la chiave sia valida, non devi fidarti di essa!

    
risposta data 07.12.2013 - 01:23
fonte

Leggi altre domande sui tag