Esiste un modo sicuro per condividere una chiave PGP da utilizzare con security.txt?

Question

Esiste un modo sicuro per condividere una chiave PGP da utilizzare con security.txt?

#1 da (3 voti)
#2 da (2 voti)

5

Una delle opzioni per security.txt deve includere un riferimento a una chiave PGP da utilizzare quando si riportano le vulnerabilità in modo privato e sicuro . È perfettamente logico per me che un ricercatore usi PGP per crittografare un messaggio per segnalare una vulnerabilità.

Ma per quanto riguarda il business dall'altra parte? Come dovrebbero implementare in modo sicuro una chiave PGP per tali rapporti?

Un'opzione sarebbe semplicemente usare la chiave personale di una persona (o, più probabilmente, una tantum creata esclusivamente per questo scopo), ma poi c'è il rischio che la persona muoia (indisponibilità) o diventi canaglia (DOS / Rapporti MitM).

Un'altra opzione sarebbe quella di generare una coppia di chiavi per questo scopo e condividerla tra un gruppo di persone fidate. Questo risolve il problema della "morte" e il problema del DOS, ma espande il rischio che una persona riceva un rapporto e ne faccia qualcosa di nefasto.

Una chiave condivisa significa anche che qualsiasi keyholder privato può emettere un messaggio "come" quell'identità. Questo può probabilmente essere risolto chiarendo che la chiave è per "solo-ricevuta" quando si conia.

Esiste un modo standard e / o sicuro per fare cose del genere?

secret-sharing pgp

posta Christopher Schultz 05.09.2018 - 19:07

fonte

2 risposte

Leggi altre domande sui tag secret-sharing pgp

I dispositivi PS / 2 sono un componente hardware rischioso per i moderni dispositivi del punto vendita? Quando è necessario preoccuparsi di perdere informazioni sui tempi in .NET?

score 3 · Answer 1

Un modo in cui suggerirei è la condivisione della sottochiave di crittografia tra i membri del team di sicurezza, ma non le sottosezioni Certify ("master") né Sign. In questo modo, ogni membro del team può decrittografare i messaggi inviati all'indirizzo e-mail elencato in security.txt, ma non inviare di nuovo l'e-mail firmata. Le sottochiavi Certify e Sign possono essere mantenute su un sistema di vault, che può essere utilizzato ai fini di quanto segue:

firma della comunicazione ufficiale
revocare la sottochiave di crittografia condivisa e crearne una nuova nel caso in cui un membro del gruppo lasci

Il sistema di vault può avere quelle sottochiavi su un tipo di HSM che non può essere rimosso fisicamente; allo stesso modo, il sistema stesso o la stanza in cui è tenuto devono richiedere più persone per poter funzionare.

score 2 · Answer 2

Ottima domanda.

Come sempre, si tratta del tuo specifico modello di minaccia.

Esponi un numero di elementi interessanti (ad es. insider, canaglia, morte, ecc ...)

Per la maggior parte della gente che usa security.txt, la domanda si ferma principalmente a "Come faccio a consentire ai ricercatori di comunicare in modo sicuro con la mia azienda" e il presupposto è che l'azienda abbia affrontato queste domande di accesso alla chiave privata, ma ha senso per la loro particolare tolleranza al rischio.

Se solo una persona ha il compito di rispondere ai rapporti di sicurezza, la loro chiave, generata per questo scopo, va bene, e l'azienda accetta i tipi di rischi definiti per un singolo utente. Se si tratta di una squadra, per definizione il team ha accesso e si affronta l'altra classe di rischi.

Una taglia non si adatta a tutti. Se creavo qualcosa e chiedevo di considerare tutte le minacce che descrivevi, andrei con qualcosa del tipo:

Chiave privata della coppia PGP memorizzata in AWS Secrets Manager

link

e accesso gestito tramite ruoli e criteri tramite il servizio di gestione delle chiavi

link

In questo modo l'azienda è responsabile della definizione dei ruoli e delle politiche e dei controlli di accesso appropriati al proprio profilo di rischio e alle minacce a cui si preoccupano.

Nessuna persona o gruppo di persone controlla "la chiave privata" ma l'accesso per usarlo può essere concesso e revocato centralmente, aggiungendo e rimuovendo le autorizzazioni in base alle regole dell'organizzazione.

Questo ti darebbe anche una pista di controllo di quale membro di un gruppo ha usato la chiave per rispondere a una richiesta specifica.