Come avere la crittografia client senza chiave di crittografia del server

Question

Come avere la crittografia client senza chiave di crittografia del server

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

1

Voglio creare un servizio in cui le persone possano scambiarsi messaggi tramite il proprio dispositivo mobile in modo da crittografare tutte le informazioni sul proprio dispositivo e non sul mio server. Fondamentalmente voglio che due persone si scambino messaggi in modo sicuro e confidano che i miei server e nessun altro possano avere alcuna conoscenza o accesso ai loro dati senza le loro autorizzazioni. Sono particolarmente cauto nel prevenire gli attacchi mitm.

Attualmente tutti i miei messaggi funzionano attraverso i miei server rabbitmq negli Stati Uniti, ma voglio che i messaggi di dati che transitano su rabbitmq vengano crittografati prima di arrivare ai miei server mq. Capisco che questo è ciò che fondamentalmente SSL è, ma è davvero l'opzione migliore là fuori, soprattutto se i server dei certificati sono basati negli Stati Uniti? È possibile avere le chiavi dei client generate dinamicamente solo su dispositivi mobili che non possono essere incrinate da me? Quello che temo è che il governo chieda che le mie chiavi di crittografia decifri il traffico dei miei clienti in caso di una causa imminente.

encryption openssl tls

posta encryption man 05.03.2016 - 22:39

fonte

3 risposte

Leggi altre domande sui tag encryption openssl tls

È una correzione di sessione Github Pages Security, da .com a .io

score 4 · Answer 1

Primo: la primissima regola della crittografia: Non eseguire il crypto!

Secondo: Perché vuoi configurare questo servizio? Segnale (+ OTR o Axolotl ) fa tutto questo già per: È aperto- fonte, consente la verifica tra pari, offre crittografia end-to-end, offre memoria crittografata lato client e è considerata affidabile da tutti i crittografi noti.
Divulgazione: uso Signal e sono convinto della sua qualità, non sto lavorando per OpenWhisperSystems o altrimenti affiliato.

Ma ora, andiamo a rispondere alle tue domande:

I understand that this is what SSL basically is, but is it really the best option out there especially if the certificate servers are US based?

SSL (o più recentemente chiamato TLS ) di solito fornisce sicurezza di trasporto tra i terminali utente e i tuoi server. Di per sé non fa nulla oltre a questo. È possibile consentire ai client di stabilire sessioni TLS tra loro (con conseguente buona crittografia end-to-end), tuttavia TLS è più progettato per essere un protocollo di sicurezza (in qualche modo) in tempo reale. Per quanto riguarda i certificati, se si utilizza qualcosa di diverso dallo scambio di chiavi RSA , una perdita della chiave privata non consentirà la decrittografia dei dati TLS (se hai eliminato l'effimero (EC) DHE chiavi) ma consentirebbe attacchi man in the middle (questo presuppone l'utilizzo di DHE anonimo / effimero (EC). Adattare un approccio TOFU o un altro meccanismo di aggiornamento chiave potrebbe rendere la connessione resistente all'uomo nel mezzo attacchi dopo la connessione iniziale.

Is it possible to have dynamically generated client keys only stored on mobile devices that can't be cracked by me?

Assolutamente. OTR include già tale funzionalità. Fondamentalmente vuoi finire come un relay per i messaggi che i client trasmettono (proprio come l'infrastruttura internet standard) mentre negoziano in modo sicuro un segreto condiviso tramite i tuoi server. Puoi verificare il tuo pari che confrontando gli hash del segreto Diffie-Hellman condiviso (o la chiave pubblica dell'altra parte utilizzata per autenticare le chiavi pubbliche Diffie-Hellman) out-of-band .

score 2 · Answer 2

Sembra che tu possa adottare uno schema simile a quello che ProtonMail utilizza per email crittografate end-to-end sicure.

ProtonMail afferma di non avere accesso alle informazioni degli utenti. Ogni utente genera una coppia di chiavi sul proprio dispositivo e ProtonMail ha la chiave pubblica di ogni utente. I messaggi sono crittografati sul lato client e solo i messaggi crittografati vengono inviati attraverso i server di ProtonMail. Per maggiori informazioni, vedi link .

score 0 · Answer 3

Anche se alcuni su questo thread dicono di non eseguire il proprio sistema crittografico, argomenterò altrimenti che è necessario facilitare il vero apprendimento. Detto questo, è meglio usare una soluzione temprata controllata da altri esperti come menzionato dalle persone su questo forum.

Quello che stai cercando è la crittografia lato client usando la crittografia a chiave asimmetrica. Mentre lo schema va, si scambiano le chiavi pubbliche con chiunque si voglia parlare. Un buon algoritmo da utilizzare è la chiave pubblica RSA. Con le chiavi pubbliche RSA, puoi fare cose come ... firme digitali per autenticare la persona che ha davvero una coppia di chiavi privata con la chiave pubblica che hai.

Ciò che puoi fare è far sì che la tua app generi un lato client di coppie di chiavi e fornisca la chiave pubblica al tuo server. Quando qualcun altro vuole parlare con il tuo cliente, il tuo server passerà quella chiave pubblica a quel client e ora potrai scambiare messaggi crittografati tramite RSA.

Ho sorvolato alcuni dettagli ma è così che si costruisce un protocollo MITM resistente. Se c'è qualcosa da guadagnare da questo, ...

La chiave pubblica RSA deve essere utilizzata solo per crittografare, mentre la chiave privata viene utilizzata solo per decrittografare. Non consegnare mai la chiave privata a nessuno, incluso il tuo server. Dicono che RSA 2048 è abbastanza sicuro, ma di solito faccio RSA 4096 solo perché.