it-swarm-eu.dev

Perché le chiavi master PGP hanno una sola sottochiave e associano la certificazione alla firma per impostazione predefinita?

Dopo aver appreso di più sulle sottochiavi PGP e su come dividere i ruoli di ignizione (S), crittografia (E), autenticazione (A) ed ertificazione (C), ho scoperto che nella maggior parte dei casi (?) Una chiave master predefinita ha una sottochiave per separare il lavoro di crittografia:

pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E

Qui, AAAAAAAA è la chiave principale. S consente la firma del contenuto, C consente di creare nuove sottochiavi. (Un vantaggio di questo è che puoi dare a AAAAAAAA un tempo di scadenza più lungo di BBBBBBBB e quindi creare una nuova chiave di crittografia con AAAAAAAA perché ha C permesso di utilizzo.)

Tuttavia, mi sembra che quanto segue non sarebbe meno sicuro per gli utenti che lavorano su una singola macchina, ma fornirebbero più sicurezza agli utenti che desiderano ricevere posta crittografata, ad esempio da lavoro e da casa:

pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S

Con questa configurazione, la chiave master AAAAAAAA non può firmare/verificare o crittografare/decrittografare, ma può raccogliere la fiducia. Pertanto, è possibile assegnare al master AAAAAAAA un tempo di scadenza più lungo e utilizzarlo per aggiungere nuove sottochiavi. Esportando quindi BBBBBBBB e CCCCCCCC su, diciamo, un computer di lavoro separato che viene spostato molto di più ed è meno sicuro, senza la chiave principale, se il computer di lavoro è compromesso, è possibile revocare le sottochiavi e aggiungere nuove chiavi, senza perdere la reputazione.

(Puoi anche arrivare al punto di mantenere la parte segreta della chiave di certificazione principale in un bunker segreto super sicuro, ovviamente.)

So che l'impostazione di questo sembra essere impossibile tramite una GUI (non sembrano entusiasti delle sottochiavi, né la visualizzazione né la modifica, e tanto meno il controllo di ciò che la chiave master può e non può fare), ma la mia domanda è:

Esiste un motivo specifico per cui ciò non viene fatto con le implementazioni PGP esistenti? L'esportazione di chiavi segrete su altre macchine senza privilegi di certificazione sembra che sarebbe una grande sicurezza vincere. (Se solo le GUI lo rendessero più semplice.) Il mio unico pensiero possibile è che l'importazione di sottochiavi segrete con una chiave segreta master paralizzata non sia ampiamente supportata, come --export-secret-subkeys (Nella pagina man gpg(1)) suggerimenti a:

--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.

Modifica : Sembra che Debian segua questa stessa pratica? https://wiki.debian.org/subkeys

36
Adam Prescott

Ho due punti di vista su questo tema: uno si basa su fatti storici (ed è un po 'tecnico), mentre l'altro è puramente la mia opinione originale.

Indipendentemente da ciò, sembra davvero più sicuro, o almeno più conveniente, usare una chiave separata per le firme; in questo modo, usi la tua chiave principale solo per le certificazioni (e puoi archiviarla) e non devi ripetere tutto il processo di certificazione (riunioni IRL) se la tua chiave è compromessa.

Fatti storici

Dopo aver esaminato attentamente il codice sorgente C delle versioni GnuPG stabili (1.4 e 2.0), ho trovato la funzione responsabile dell'impostazione delle funzionalità predefinite delle chiavi pubbliche; il codice (nel file g10/misc.c) è simile al seguente:

476 int
477 openpgp_pk_algo_usage ( int algo )
478 {
479     int use = 0;
480
481     /* They are hardwired in gpg 1.0. */
482     switch ( algo ) {
483       case PUBKEY_ALGO_RSA:
484           use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG
485                  | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH);
486           break;
487       case PUBKEY_ALGO_RSA_E:
488           use = PUBKEY_USAGE_ENC;
489           break;
490       case PUBKEY_ALGO_RSA_S:
491           use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG;
492           break;
...
509       default:
510           break;
511     }
512     return use;
513 }

Ho trovato questa funzione perché ho prima visto come è stata eseguita la generazione della chiave (g10/keygen.c); è infatti durante la (sotto) generazione di chiavi che GnuPG può assegnare i "ruoli" per le chiavi. Una volta creata una chiave master, non è possibile modificarne le abilità.

Il codice sorgente non diceva molto (tranne che una chiave RSA per firma include anche la possibilità di certificazione), ma eseguendo una ricerca web per commento (riga 481 sopra) mi ha portato a inviare un messaggio pubblicato il 03-08-2005 nella mailing-list gnupg-users, dicendo :

GnuPG non distingue ancora tra C e S. Quindi non ha molto senso scegliere questo.

Quindi, sembra che tali impostazioni predefinite esistano solo perché GnuPG non faceva distinzioni tra le chiavi di firma e le chiavi di certificazione.

Inoltre, queste impostazioni predefinite potrebbero essere presenti a causa di DSA , come Simon Richter ha indicato :

Per un po 'di tempo, gpg ha usato le chiavi DSA per impostazione predefinita, che possono essere utilizzate solo per la firma, quindi ha dovuto allegare una sottochiave elGamal (che può essere utilizzata solo per la crittografia) per ottenere una chiave completamente funzionale.

Per RSA, questo non è necessario, ma è stato mantenuto per qualche motivo.

I sottotipi RSA "sign only" o "encrypt only" non sono limitazioni tecniche dell'algoritmo.

Fatti originali

Al giorno d'oggi, credo che l'unica ragione di ciò (capacità della chiave primaria predefinita impostata su SC e non solo su C) sia per aiutare utenti regolari con firme di verifica.

Supponiamo che tu abbia queste due chiavi nel tuo portachiavi:

pub  4096R/00000001  1970-01-01       usage: C
uid                  Alice Owl
sub  4096R/AE687A0C  1970-01-01       usage: S
sub  4096R/F77A9AF1  1970-01-01       usage: E

pub  4096R/FFFFFFFE  1970-01-01       usage: CS
uid                  Bob Penguin
sub  4096R/00FF42CD  1970-01-01       usage: E
  • Alice Owl è un normale utente di GnuPG, è fiduciosa con OpenPGP e ha generato una coppia di chiavi con il flag --expert Di GnuPG, in modo da poter impostare le proprie abilità chiave. La chiave primaria ha il flag Covviamente , ma firma i documenti con una sottochiave.
  • Bob Penguin non sa quasi nulla della crittografia. L'unica cosa che vuole è un po 'di privacy/intimità. Ha generato la sua chiave come farebbe qualsiasi utente normale (senza toccare alcuna impostazione che non capisce).

Ora, facciamo finta che tu, il lettore, anche tu sia un principiante. Ricevi documenti firmati da Alice e Bob. Conosci le basi di gnupg, e in particolare:

  • Gli utenti vengono identificati con le loro chiavi primarie:
    • Quindi so che Alice è 00000001, e so anche che Bob è FFFFFFFE.
  • Si possono verificare i messaggi con le opzioni --verify O --verify-files Di GnuPG.

Ora, controlliamo i documenti che ti hanno inviato.

$ gpg --verify from-bob.txt.asc
gpg: Signature made <date> using RSA key ID FFFFFFFE
gpg: Good signature from "Bob Penguin"

$ gpg --verify from-alice.txt.asc
gpg: Signature made <date> using RSA key ID AE687A0C
gpg: Good signature from "Alice Owl"

Aspetta cosa? Pensavo che la chiave di Alice fosse 00000001?

In effetti, le firme sui documenti non sono non necessariamente fatte con la chiave principale; sono fatti con la chiave che ha la capacità di firma (S). È improbabile che un principiante lo sappia.


Forse la spiegazione effettiva non ha nulla a che fare con questo assunto ("più principianti usano i tasti SC, meglio è per gli altri principianti "), ma questa è l'unica spiegazione che posso trovare senza disturbare i collaboratori di GnuPG.

27
Diti

Diti ha quasi ragione sul contesto storico, ma la vera ragione storica è nella parte che ha omesso.

Per un po 'di tempo, gpg ha utilizzato le chiavi DSA per impostazione predefinita, che possono essere utilizzate solo per la firma, quindi ha dovuto allegare una sottochiave elGamal (che può essere utilizzata solo per la crittografia) per ottenere una chiave completamente funzionale.

Per RSA, questo non è necessario, ma è stato mantenuto per qualche motivo.

I sottotipi RSA "sign only" o "encrypt only" non sono limitazioni tecniche dell'algoritmo.

8
Simon Richter

Quando crei chiavi diverse per la firma dei dati e per la firma dei certificati, le persone che "firmano la tua chiave" devono effettivamente firmare la tua chiave di certificazione , non i tuoi dati- chiave di firma; in caso contrario, Web of Trust non passa oltre la tua chiave. Tuttavia, quando firmi un'e-mail, lo fai con la tua chiave di firma dei dati, non con la tua chiave di certificazione, e questa è la tua chiave pubblica di firma dei dati che viene copiata nell'e-mail.

È quindi possibile separare le chiavi di firma e certificazione, ma richiede che le persone coinvolte e/o le implementazioni del software siano più attente a ciò che firmano e distribuiscono. Posso immaginare che potresti riscontrare problemi di usabilità.

6
Tom Leek