La sincronizzazione delle chiavi private è una buona idea?

Le FAQ sulla sicurezza di Ubuntu One indicano che Canonical crittografa le connessioni e limita l'accesso ai dati dell'utente. Tutto bene, e mi fido di SSL per l'online banking e altre cose più preziose delle mie chiavi private.

Detto questo, sono piuttosto ansioso di mettere il mio ~/.ssh/id_dsacloud. Ovviamente, nessun sistema è totalmente sicuro. Qualche parte esperta potrebbe quindi quantificare pragmaticamente i rischi?

Lo spazio di archiviazione di Ubuntu One non è crittografato con una chiave crittografica dell'utente

Come Dropbox, Ubuntu One store non è crittografato con una passphrase speciale. Pertanto, sarebbe tecnicamente possibile per qualcuno ottenere l'accesso ai tuoi dati, da un dipendente inaffidabile o da una violazione della sicurezza. Vedi questo bug report sulla crittografia dei dati di archiviazione di UbuntuOne è ancora una lista dei desideri.

Quindi non avrei sincronizzato la mia cartella ~ / .ssh sul cloud. A meno che non imposti un contenitore crittografato che viene quindi inviato al cloud, ma per le chiavi SSH non è sempre così utile. Ma ti do ancora modi pratici per crittografare i tuoi dati:

• Salvaguardare la tua memoria su Ubuntu One
• Utilizzo sicuro del cloud storage

Maggiori informazioni

Ubuntu One utilizza la crittografia per la connessione (come detto nel fatto), significa che sostanzialmente i dati vengono trasmessi su una sorta di HTTPS. Puoi usare un'animazione davvero ben fatta di ciò che è visibile agli intercettatori quando usi HTTPS , per gentile concessione di EFF (Electronic Frontier Foundation) .

Facendo clic sul pulsante HTTPS nell'animazione EFF, sarai in grado di vedere ciò che è visibile a tutti quando metti le tue chiavi SSH in un contenitore Dropbox o Ubuntu One. Come dice l'animazione, molte persone su site.com (ad esempio one.ubuntu.com) sarebbero in grado di visualizzare i tuoi dati (e molti altri). Anche se utilizzassi qualcosa come Tor per indirizzare tutto il tuo traffico, ciò significherebbe comunque che le persone su site.com possano accedere ai dati.

Quindi devi crittografare i dati prima che lascino il tuo computer. Quindi arriva crittografato su site.com con credenziali di cui non sono a conoscenza. Ovviamente, dovresti usare un forte meccanismo di crittografia in modo che sia estremamente lento per le persone di site.com decifrarlo.

Naturalmente nel caso di una banca, non puoi crittografare i tuoi soldi, poiché paghi la banca per gestirli per te. Quindi non hai altra scelta che affidarti alla banca per rendere il loro sistema IT sicuro quanto i loro depositi fisici in modo che solo un piccolo sottoinsieme di dipendenti (quelli che gestiscono il tuo account) possano visualizzare e modificare i tuoi dati.

Sono piuttosto ansioso di mettere il mio ~ / .ssh / id_dsa nel cloud.

Bene, una soluzione è ciò che faccio con le mie chiavi private ssh e gpg con Dropbox: crittografarle in un archivio ed eliminare gli originali "grezzi". Ogni volta che è necessario, lo estraggo temporaneamente e quindi lo elimino al termine.

Uso p7zip(utilizza la crittografia AES-256), ma è possibile utilizzare numerosi altri strumenti. In questo modo, tutto ciò che viene sincronizzato è l'archivio crittografato e, anche se l'archiviazione cloud è compromessa, nessuno può estrarre le chiavi private se non conoscono la passphrase per l'archivio.

Per rendere la vita più facile per le cose che fai frequentemente (diciamo, decrittografia gpg), puoi avere un semplice script bash che gestisca la parte temporanea di decrittazione / uso / cancellazione; dovrebbe anche disabilitare temporaneamente tutti i demoni di sincronizzazione in modo che le chiavi estratte non vengano sincronizzate accidentalmente.

Puoi salvare le tue chiavi su U1 tramite lo strumento di backup Deja-dup. Se si imposta una password, i file di backup vengono crittografati automaticamente su U1. Non è necessario farlo manualmente.

Esistono diverse metriche disponibili per la definizione del rischio, ma è necessario tenere conto del valore dei dati o dei sistemi a cui la chiave potrebbe dare accesso. Se la chiave viene persa e alcune entità possono utilizzarla per ottenere l'accesso, cosa verrà compromesso? La paura sarà l'esposizione di dati riservati, la perdita di dati, la possibilità di compromettere account a livello amministrativo o di account, ecc.? Se riesci a ricreare dati che non sono confidenziali e se hai dati riservati memorizzati in modo sicuro (ad esempio, crittografati), ciò è meno urgente. Penso che enumerare le soluzioni alternative per i diversi punti deboli del sistema faccia parte della definizione del rischio globale. Pragmaticamente, è improbabile che l'archiviazione di .id_rsa costituisca un problema, soprattutto se si ruotano le chiavi a un certo intervallo. Ciò si basa su diversi presupposti, ma tuttavia

Soluzione semplice. Una specie di. Se non è possibile utilizzare qualcosa come un'unità flash USB, inserire una passphrase sulla chiave SSH. Autenticazione istantanea a due fattori (sorta di). Non è nemmeno necessario caricare una nuova chiave pubblica.