Qual è il modo consigliato e le best practice per inviare chiavi private e chiavi private SSL? Stavo pensando di comprimere i file, quindi utilizzare gpg :
gpg -c thefile.zip
Il problema diventa quindi come si invia la passphrase utilizzata per crittografare all'altra estremità? C'è una soluzione migliore?
TL;DR: private keys are called private for a reason.
Puoi proteggere le chiavi private senza trasmetterle affatto .
MODIFICA: per il caso di utilizzo dichiarato di chiavi private per un provider di hosting, è ancora meglio generarle sul posto.
GPG può permetterti di inviarli in modo sicuro senza dover inviare una passphrase. Se la destinazione ha la propria chiave GPG, è possibile crittografare il file in modo che solo loro possano aprirlo. Ad esempio, gpg -e -r E9053BDA thefile.zip consentirà solo a me di aprire thefile.zip con la mia chiave GPG senza che nessuno di noi comunichi mai una passphrase. In alternativa gpg-zip -e -r E9053BDA *.crt comprime e crittografa tutti i file *.crt in un unico comando.
Riferimento alla documentazione:
Per trasmettere le chiavi privatamente in modo sicuro (o con qualsiasi chiave / passphrase con cui le hai crittografate), non hai alcuna possibilità che utilizzare un canale affidabile e sicuro prestabilito sin dall'inizio.
A seconda delle tue esigenze e delle possibilità disponibili, questo potrebbe includere
Quale metodo per utilizzare in realtà completamente dipende dai tuoi bisogni e dai potenziali evasori. Se le istituzioni governative e le agenzie segrete sono possibili aggressori, la maggior parte di questi modi sarà compromessa fin dall'inizio: né il telefono, né la posta ordinaria saranno più al sicuro - e probabilmente altri.
Se vuoi solo comunicare con qualcun altro, entrambe le estremità dovrebbero generare coppie di chiavi proprie , distribuire la chiave pubblica mantenendo la chiave privata privata. Devi ancora scambiare informazioni sulle chiavi pubbliche, ad esempio l'impronta digitale, attraverso un canale prestabilito e predeterminato come descritto sopra.
Per prima cosa, leggi ciò che Deer Hunter ha scritto sopra. Il modo migliore per inviare in modo sicuro le chiavi private è di non inviarle mai in primo luogo. Punto fermo.
Detto questo, ci sono probabilmente alcune circostanze in cui potresti legittimamente bisogno di trasferire alcune chiavi private che esistono nelle tue mani e amp; e in una posizione alle mani di qualcun'altro in un'altra posizione. Devi ridurre al minimo questi tempi il più possibile , preferibilmente semplicemente camminando sul client che ne ha bisogno attraverso la generazione delle chiavi stesse. Ma ci possono essere delle volte in cui ciò non è pratico per qualche motivo (o, più probabilmente) non è la tua chiamata da fare. Allora, cosa fai allora?
Bene, fai quello che fanno i governi e le aziende tecnologiche quando hanno bisogno di distribuire chiavi di crittografia molto sensibili (se più spesso in simmetriche o anche in scenari di distribuzione delle chiavi a tempo, piuttosto che con chiavi private asimmetriche) verso un remoto posizione: tu:
(1.) Cripta l'inferno della / e chiave / i da trasferire prima o dopo aver lasciato le tue strutture, usando una chiave "esterna" unica creata solo per un trasferimento e poi distrutta . Se tale chiave di crittografia protettiva viene generata da una password o da una frase di accesso, la password o la frase soddisfa requisiti molto elevati.
(2.) Utilizza un canale con una sicurezza molto migliore di reti esistenti e generiche , ovvero Internet! - per ottenere il pacchetto crittografato destinazione. Il recapito fisico di un dispositivo di memoria contenente la chiave crittografata è il canale più semplice ma non sempre più pratico.
(3.) Mantieni la chiave "esterna" che sblocca la crittografia protettiva (o una password / passphrase che costituisce la base per la chiave) in tuo possesso fino al momento del trasferimento della chiave / s si desidera trasferire e quindi decrittografarli nella posizione del cliente. Ciò vuol dire che sei presente all'evento di trasferimento delle chiavi di persona per decrittografare la crittografia protettiva o inviare la chiave che sblocca la crittografia protettiva utilizzando un altro canale elettronico indipendente ad alta sicurezza per portarlo al posto del cliente al momento della decrittografia.
(Perché non passare alla # 3 e inviare la chiave privata originale che devi trasferire al client da quel canale elettronico di massima sicurezza? Perché non ci fidiamo di nessun canale, nemmeno quello che pensiamo sia uno che ha una sicurezza particolarmente buona, quasi sufficiente per gestire informazioni come una chiave privata. Facciamo in modo che un possibile avversario intercetti almeno due canali / meccanismi di trasferimento , e rendiamo difficile intercettare qualcosa di utile da entrambi , figuriamoci entrambi.
Ora, tutto sembra arduo e complicato. Ma in realtà non deve necessariamente necessariamente esserlo. (Supponendo che siamo in una situazione comune, questa-chiave-è-importante-ma-non-essere-veramente-catastrofica-se-è-stata-compromessa.) Ad esempio potresti:
-Utilizzare un dispositivo USB protetto con crittografia hardware ben considerato - nessuna mancanza di opzioni là fuori - per il trasporto. Scrivi una chiave privata, bloccala con una password / codice / frase strong unica e guidala attraverso la città alla posizione del cliente che ha bisogno della chiave. Collegalo quando arrivi, sbloccalo e copia la chiave privata sul sistema del cliente.
-Grab una chiavetta USB nuova (non precedentemente utilizzata). Utilizzare un programma software di cui si abbia una strong fiducia per crittografare la chiave privata in un file. Trasferisci file su USB. Quindi ricontrolla l'USB, solo per essere sicuro che l'unica cosa su di esso è il pacchetto ora crittografato. Fai la posta raccomandata o FedEx per portarlo sul sito del cliente. Quando arriva, usa Off-the-Record o un'app di sicurezza simile per trasmettere la chiave alla crittografia protettiva (o password / frase necessaria per rigenerarla) al client, che poi decodifica & ottiene la chiave privata.
-Per essere in grado di distribuire ripetutamente le chiavi a un client, su richiesta ed elettronicamente? Cripta la chiave privata nel file come nell'ultimo esempio. Avere un server di accesso sicuro o SSH semplice ma sicuro che si utilizza solo per la distribuzione di file di chiavi crittografate, che il client dispone di informazioni di autenticazione precondivise per l'accesso e che si mantiene normalmente disconnessi da qualsiasi accesso remoto. Quando il cliente ti chiama e ti dice che è pronto a ricevere la chiave, trasferiscila dal tuo ambiente di archiviazione interno al server. Abilita le connessioni remote al server dall'indirizzo IP del client. Il client si connette e afferra il file chiave crittografato. Infine, usi l'app di messaggistica ad alta sicurezza (o qualsiasi altra cosa) per trasferire la chiave protettiva sul tuo client.
Molte opzioni. È vero che c'è del lavoro in ognuno di essi se si vuole che il trasferimento sia ben protetto. Spenti dalla prospettiva di fare il lavoro? È comprensibile. In tal caso, vedi il punto 1 (il punto originale Deer Hunter realizzato): crea una soluzione tecnologica in cui non è necessario trasferire le chiavi private.
Il modo corretto per farlo in un canale non protetto è utilizzare un'infrastruttura a chiave pubblica per inviare una chiave privata.
1) La parte ricevente genera una coppia di chiavi pubblica / privata.
2) La parte mittente utilizzerà quindi la chiave pubblica della parte ricevente per crittografare la chiave privata e inviarla. Questa crittografia può essere decifrata solo dalla chiave privata della parte ricevente che solo il destinatario conosce. In questo modo la chiave privata può essere inviata in modo sicuro su un canale non protetto.
C'è ancora di più da considerare: come può il ricevitore assicurare l'identità del mittente? Per fare ciò, il mittente deve anche generare una coppia di chiavi private / pubbliche.
Il mittente dopo aver crittografato "La chiave privata" con la chiave pubblica del destinatario, il mittente dovrà crittografare il risultato con la sua chiave privata per generare il messaggio finale prima di inviarlo. Dopo aver ricevuto il messaggio, il destinatario dovrà quindi decodificare prima il messaggio con la chiave pubblica del mittente. Se ha successo, può assicurare che il messaggio è autentico.
Sia K la chiave privata deve essere inviata, E è crittografia, D è decrittazione
Mittente: messaggio M = E (E (K, pub-k-ricevitore), pri-k-sender)
Ricevitore: K = D (D (M, pub-k-sender), pri-k-receiver)
Ora il ricevitore deve preoccuparsi se il messaggio è nuovo, cioè non una sorta di vecchi dati che una terza parte ha intercettato e riprodotto in un secondo momento. Di solito un timestamp è incorporato nel messaggio M per risolvere questo problema.
Mittente: Messaggio M = E (E (K + timestamp, pub-k-receiver), pri-k-sender)
Ricevitore: K = D (D (M, pub-k-sender), pri-k-receiver) - timestamp
Generalmente non si dovrebbero inviare chiavi private, ma se si deve assolutamente inviare una chiave privata, allora criptarla con la chiave pubblica del destinatario. Ricorda che il tuo destinatario deve essere disposto a correre il rischio di poter conservare una copia della chiave privata.
Ripeterò ciò che altri hanno detto per primo, quindi aggiungo un altro punto.
Che cosa è stato detto:
Condividi solo le chiavi pubbliche, se possibile - ecco come funziona la sicurezza.
Se le chiavi private devono essere condivise, non inviare attraverso l'infrastruttura condivisa (nota che i telefoni cellulari e le linee di terra non sono completamente sicuri).
Se le chiavi devono essere inviate attraverso l'infrastruttura condivisa, crittografare correttamente e utilizzare canali sicuri. Prendi in considerazione l'invio di una parte attraverso due canali diversi.
Migliore se le chiavi condivise non vengono utilizzate troppo a lungo.
E un nuovo pensiero:
Considera inoltre che utilizza la steganografia per le comunicazioni con le persone con cui spesso interagisci e condividi le foto, sarà più difficile da individuare.
Ma per ribadire, i sistemi come Bitcoin sono forti perché le chiavi private non sono condivise, richiedendo che ogni account venga rotto individualmente. I sistemi con chiavi condivise espongono tutti a singole interruzioni o singoli errori all'interno del gruppo.
Invia la chiave privata da un servizio di posta elettronica anonimo a un indirizzo di servizio di posta elettronica usa e getta da 48 ore. Hai solo bisogno di pubblicare pubblicamente il tuo indirizzo email throwaway con la chiave pubblica in piena vista di tutti e attendere che il tuo partner mittente ti invii il PK entro 48 ore. Dopo 48 ore evapora il buttafuori. Nessuno ha bisogno di fidarsi di nessuno. Le due parti potrebbero sempre utilizzare lo stesso PK per qualsiasi messaggio futuro senza dover ripetere questa transazione. Tuttavia, è meno sicuro farlo in questo modo.
Leggi altre domande sui tag encryption gnupg