Crittografia utente-utente oltre a SSL per i telefoni cellulari?

Crittografando machine-to-machine, voi (ordinate) proteggete i dati in transito, ma la crittografia da utente a utente protegge i dati in transito, da parti della macchina (più in alto nello stack), così come proteggerlo in deposito. Un ulteriore vantaggio della crittografia a livello utente è il controllo migliore sul processo di crittografia, nel caso in cui non si abbia il controllo del processo SSL in qualsiasi momento.

La domanda diventa "da chi stai proteggendo i dati?"

Il client di chat di Pidgin, ad esempio, può essere configurato per utilizzare la crittografia a livello utente e ottiene i vantaggi che ho delineato .

SSL stabilisce un tunnel di dati protetto su un tunnel di dati non protetto. Puoi fare SSL tra due macchine (anche se le macchine sono smartphone) ma la configurazione pratica può essere difficile: le connessioni dirette smartphone-smartphone sono rare, perché in una normale connessione, una macchina ha il ruolo di client e l'altro è un server (il "client" è quello che parla per primo, il "server" è quello che attende il cliente per parlare). L'avvio di tale connessione richiede che il client "sappia" in qualche modo l'indirizzo IP del server. I provider di rete per smartphone non lo rendono facile (e, a quel punto, nemmeno l'ISP per gli utenti domestici).

Usi comuni di SSL da smartphone sono tra il telefono e un server. Se due telefoni si connettono allo stesso server, quel server potrebbe fungere da relè per i pacchetti di dati inviati da un telefono all'altro, consentendo qualsiasi protocollo di comunicazione, anche SSL. La crittografia da utente a utente, o almeno la crittografia da telefono a telefono, ha molto senso se non ci si fida del server di inoltro. Questo è esattamente il modello di sicurezza per "emailing sicuro" come è incorporato da PGP.

Schroeder lo metti abbastanza correttamente, e questa singola frase può davvero (quasi da sola) rispondere alla tua domanda .

The question becomes, "who are you protecting the data from?"

Mi piacerebbe approfondire un po ', però.

Se la tua unica preoccupazione è proteggere i dati dagli intercettatori occasionali (ad es. quel ragazzo inquietante accanto a te nella caffetteria), allora le tecnologie di sicurezza di connessione machine-to-machine come SSL sono in genere sufficienti. Presumendo che il meccanismo di protezione di per sé non sia debole in qualche modo, in genere si ha poco da temere dalle persone che spiano il traffico.

Tuttavia, se sei preoccupato di proteggere i tuoi dati dalle agenzie governative, dagli insider malintenzionati del tuo ISP, dai malintenzionati nell'host dell'app, dai sistemi di monitoraggio del tuo datore di lavoro o da altri aggressori avanzati con posizionamento man-in-the-middle, quindi soluzioni end-to-end come PGP sono la strada da percorrere.

SSL generalmente protegge la connessione tra te e l'host dell'app. Tuttavia, se la connessione SSL è compromessa (vale a dire la tua azienda utilizza un proxy SSL per monitorare tutto il traffico sulla rete come se fosse un testo in chiaro), i tuoi dati sono vulnerabili. Inoltre, SSL non protegge i dati a riposo nei server dell'host dell'app in cui gli utenti interni malevoli potrebbero essere in grado di sfruttarli.

PGP protegge i dati lungo l'intero percorso, dalla sua origine alla sua destinazione finale , e protegge i dati a riposo. L'unico modo per compromettere i dati è quello di compromettere una delle macchine endpoint, ottenere una copia di una chiave privata autorizzata o trovare un punto debole negli algoritmi di crittografia utilizzati. In generale, questo ti proteggerà da attacchi interni malevoli e attacchi man-in-the-middle. Tuttavia, devi comunque essere vigile contro malware e attori malintenzionati con accesso fisico a entrambi gli endpoint.

Riguardo a quest'ultimo punto, è bene ricordare alcune Dieci leggi di sicurezza immutabili :

Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
...
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
...
Law #10: Technology is not a panacea.

Tuttavia, se hai davvero paura di quelle agenzie governative o di altri "cattivi", dovresti probabilmente mantenere questo in mente.

Risposta breve, sì, ci possono essere alcuni casi selezionati che saranno di aiuto quando si parla direttamente tra due client se le applicazioni sono estremamente resistenti. Ce ne sono anche molti quando i dati devono viaggiare all'aperto su un intermediario non fidato (es. Server di posta, server di chat, ecc.).

Risposta lunga. Ci sono un paio di cose che vale la pena menzionare qui. In primo luogo, SSL generalmente fornisce solo l'autenticazione di una macchina, quindi non fa nulla per garantire che il client che si connette a un server sia un client particolare (oltre ad attestare che si tratta dello stesso client che ha avviato la sessione SSL). Solitamente il server ha generalmente un certificato attendibile. Vi è il supporto per i certificati lato client in SSL, che verificherebbe un particolare client, ma è usato piuttosto raramente.

Successivamente, la crittografia da utente a utente come lo hai descritto qui va leggermente oltre, ma non in modo significativo. In un sistema come PGP, si dispone dell'autenticazione reciproca poiché entrambe le parti dispongono di certificati che devono essere convalidati tramite un qualche tipo di infrastruttura a chiave pubblica (PKI), ma ciò potrebbe essere fatto solo con SSL. Spostare la crittografia sul livello dell'applicazione (anziché sul trasporto) può essere significativo in alcuni rari casi, ma se qualcuno dovesse compromettere i dati SSL, dovrebbe aver compromesso uno degli endpoint (molto probabilmente lo stack di rete). Se uno degli endpoint è compromesso, il client software non può essere necessariamente considerato attendibile poiché l'attacker avrebbe bisogno di un accesso a livello kernel a uno degli endpoint per dirottare lo stack di rete e potrebbe quindi dirottare I / O da / a l'applicazione. Ridurrebbe alcune minacce minime se l'applicazione è progettata per essere altamente sicura contro qualsiasi tipo di accesso da un altro programma, ma ciò richiederebbe un approccio alla sicurezza molto più approfondito rispetto alla semplice crittografia dei dati a livello di applicazione.

Ciò che è più importante è assicurarsi che SSL sia ben utilizzato da un'applicazione. È necessario che si verifichi il login per attestare che il client e le sessioni SSL devono essere correttamente chiuse se un endpoint lascia la sessione. (cioè, quindi non posso sederti al tuo computer e usarlo come te.) Nota che questo ultimo punto conta anche se è un'applicazione all'applicazione.

Per quanto riguarda il passaggio da un intermediario non fidato, il problema con SSL è che non si tratta di una connessione protetta continuamente se si attraversa un punto intermedio o più di un tipo di trasporto. La crittografia fornita dal cliente finale proteggerà i dati indipendentemente dal trasporto e proteggerà anche attraverso qualsiasi gestione. Molti sistemi utilizzano "buste" in cui le informazioni vengono crittografate in anticipo per più passaggi del viaggio. Ogni sistema può aprire la busta più esterna, determinare cosa deve fare con le informazioni e quindi trasmetterle al sistema successivo. Alla fine, l'utente all'altra estremità può aprire la busta finale e ottenere il messaggio originale, ma nessuno in mezzo può accedervi.