La crittografia sul lato server è possibile con accesso solo utente per i servizi di posta elettronica?

1

Mi sono imbattuto in Lavabit High Scalability Writeup e mi sono incuriosito.

Do you use any particularly cool technologies or algorithms?

The way we encrypt messages before storing them is relatively unique. We only know of one commercial service, and one commercial product that will secure user data using asymmetric encryption before writing it to disk. Basically we generate public and private keys for the user and then encrypt the private key using a derivative of the plain text password. We then encrypt user messages using their public key before writing them to disk.

Per quanto ne so, Lavabit ha offerto anche un client webmail. La crittografia sul lato server è possibile dove solo l'utente può decrittografare i messaggi ma un accesso webmail è offerto allo stesso tempo? Lavabit ha affermato che non poteva recuperare la password se fosse persa, il che significa che non poteva essere reimpostata, vero?

Ciò significherebbe che le credenziali dell'utente devono essere memorizzate nel database al fine di autenticarlo. Questa stessa password viene utilizzata per generare la derivata, che viene quindi nuovamente utilizzata per decrittografare la chiave privata, che può essere utilizzata nuovamente per decrittografare le e-mail crittografate con chiave pubblica.

Questo non significa che Lavabit è / era in possesso delle password? A mio parere, ciò avrebbe senso solo se sono richieste due password. Una password per autenticare l'utente e una passphrase per sbloccare la chiave privata. Laddove la passphrase, al contrario della password, non è memorizzata nel database, ma inserita ogni volta dall'utente senza persistere da qualche parte.

Simili che ho trovato nelle Domande frequenti su MyKolab.com :

Some other providers claim to use server side cryptography to store my data encrypted so they cannot access it. Do you do that as well?

We currently do not have any plans to do that. The reason is simple. With server-side encryption, the provider holds the encrypted data, the key, and the passphrase, as all three need to pass through the web interface and be available on the server. So the provider does have access to all the data despite the encryption.

We don't believe in misleading our users in this way.

The only solution would be client side encryption of everything, but that's very hard to implement and there is a whole set of standards missing on the browser side to do this properly and securely, also keeping in mind that sand boxing in browsers does not work from a security perspective. Therefore, we suggest to use native clients such as Kontact and use GnuPG for end-to-end encryption.

Quindi cosa intendeva dire Lavabit quando hanno detto che il recupero dei messaggi non sarebbe stato possibile? Come può funzionare in modo sicuro, rispettivamente solo come dichiarato da MyKolab.com?

    
posta platzhirsch 14.08.2013 - 12:22
fonte

1 risposta

5

Il "Lavabit High Scalability Writeup", a cui ti colleghi, include questo passaggio, che è illuminante:

Because we need the plain text password to decrypt a user’s private key, we don’t support secure password authentication. We decided to support SSL instead (which encrypts everything; not just the password).

Quindi ecco cosa fanno:

  • Quando l'utente si registra, sceglie una password e la invia al server.
  • Una coppia di chiavi asimmetriche (apparentemente ECDH ) viene generata sul server.
  • Il server memorizza la chiave pubblica ECDH e anche la chiave privata, ma la chiave privata è simmetricamente crittografata con una chiave derivata dalla password dell'utente. La password dell'utente è non memorizzata.
  • Quando viene ricevuta un'email (tramite SMTP ), la crittografano con l'utente Chiave pubblica ECDH (con crittografia ibrida , possibilmente ECIES o una sua variante). Possono farlo perché hanno la chiave pubblica.
  • Quando un utente si connette, tramite POP , IMAP o la Webmail, viene utilizzata l'autenticazione semplice: l'utente mostra la sua password. Il server utilizza quindi la password per decrittografare la chiave privata dell'ECDH; se si ottiene la chiave privata e corrisponde alla chiave pubblica memorizzata, l'utente viene ritenuto autenticato.
  • Finché l'utente è connesso, la chiave privata ECDH viene mantenuta nella RAM del server e il server la utilizza per decrittografare le e-mail dell'utente per lui.

Quindi il server non memorizza mai sul suo disco la password dell'utente o la chiave privata ECDH dell'utente in forma chiara. Tuttavia, ottengono entrambi ad un certo punto, ma mantengono queste cose nella RAM, al riparo da perdite attraverso nastri di backup rubati o attacchi di SQL injection.

"Autenticazione password sicura" è un tipo di sistema di risposta alle sfide in cui il client non mostra la password, ma calcola una risposta a una sfida, la risposta utilizzando sia il valore della sfida (inviato dal server) sia la password. Questo tipo di protocollo è una protezione parziale contro la divulgazione di password quando l'identità del server non è garantita (dal punto di vista del cliente) o la connessione tra client e server potrebbe essere intercettata. Poiché Lavabit utilizza la password dell'utente sia per l'autenticazione che per la decrittazione lato server della chiave privata ECDH, non può supportare l'autenticazione "password sicura". Tuttavia, "autenticazione password sicura" implica l'archiviazione in chiaro della password sul server, quindi non è realmente sicura; una soluzione più completa e più sicura è quella di avvolgere l'intera finestra di dialogo in SSL, che è ciò che Lavabit fa.

Se Lavabit vuole rimuovere le email degli utenti, beh, possono farlo, dato che hanno la chiave privata dell'utente nella RAM in diversi punti (durante la generazione e ogni volta che l'utente si connette). Tuttavia, devono avere anche le e-mail in testo semplice, perché è così che funziona il protocollo SMTP: il server ha necessariamente accesso alle e-mail in chiaro quando viene ricevuto e inviato. In questo senso, l'uso della crittografia lato server in Lavabit non indebolisce il modello.

Se si desidera proteggere i messaggi di posta elettronica dai server (tutti i server coinvolti), è necessario disporre della crittografia sul lato client con software che è non ottenuto dinamicamente dal server, perché altrimenti il server potrebbe ancora alimentare tu software dannoso. Quindi, installa qualcosa come GnuPG . Questo, ovviamente, non funzionerà bene con la Webmail (la Webmail ti permetterà di leggere ... e-mail crittografate) a meno che tu non installi anche un plugin per il browser come FireGPG , tranne per il fatto che questo plug-in non è più disponibile e non è supportato.

Senza la crittografia lato client, direi che ciò che Lavabit fa è soddisfacente e riguarda il meglio che si potrebbe fare. (Non faccio commenti sull'implementazione , che non ho esaminato in alcun modo, sto descrivendo la progettazione concettuale .)

    
risposta data 14.08.2013 - 13:14
fonte

Leggi altre domande sui tag