La conoscenza zero è possibile con i servizi di e-mail crittografati con webbas?

Lavoro in Mailfence come analista della sicurezza delle informazioni.

Where do they store my key.

Quando generi la tua coppia di chiavi, prima la crittografiamo con la tua passphrase nel browser e poi la memorizziamo sui nostri server. In questo modo, il server non vede mai la chiave in testo semplice e viene stabilita una struttura a conoscenza zero.

If my private key is stored on their servers, can't they decrypt all my mails?

No, non possiamo. Poiché la tua chiave privata è crittografata con la passphrase, che solo tu conosci.

Il blog post Mailfence crittografia end-to-end e firme digitali ti darà più informazioni a riguardo (incluse le librerie open-source che usiamo per eseguire operazioni basate su crittografia).

Siamo sempre aperti a verifiche esterne (legittime) e per rafforzare ulteriormente la nostra trasparenza - abbiamo anche pianificato di andare open-source . Ora è solo una questione di tempo e priorità.

Non sono sicuro di come funzioni esattamente la mailfence, quindi il paragrafo seguente è una teoria su come potrebbe potrebbe funzionare: Mailfence sembra funzionare con crittografia asimmetrica. Quindi non sarebbe necessario inserire una password quando si invia la posta. Ma per leggere la posta crittografata indirizzata a te, devi inserire una password che decrittografa localmente la tua chiave privata. Questo può accadere nel momento in cui accedi al servizio, ad es. alcuni javascript utilizzano le informazioni che inserisci per accedere per recuperare e decifrare la tua chiave, quindi ti autenticano al servizio di posta, possibilmente utilizzando la chiave decrittografata per firmare una sfida. Quindi sì, è possibile creare un servizio di posta elettronica a conoscenza zero.

Tuttavia:

1. Il browser è un ambiente notoriamente insicuro. Non è possibile proteggere javascript. Quindi, se il tuo browser è violato da maware / javascript dannoso, perdi.

2. Mailfence potrebbe diventare malvagio e inviare la chiave privata decrittografata ai loro server in background, una volta decodificata localmente. Nulla che puoi fare per evitarlo.

3. È probabile che mailfence possa leggere la maggior parte della tua posta, poiché la maggior parte dei tuoi partner di comunicazione probabilmente non usa la crittografia, quindi mailfence potrebbe leggere la posta in arrivo non crittografata prima di crittografarla o leggere la posta in uscita da te a qualcuno che non utilizza la crittografia.

Le persone dietro a mailfence sembrano come se stessero provando, ma ci sono molteplici difetti alla base del design ... molti dei quali non possono essere sistemati in quanto intrinsecamente all'architettura sottostante che stanno utilizzando. Mentre ci sono molti problemi, il più grande di questi è:

Richiedono l'upload di una chiave privata

Ok, quindi hanno bisogno di crittografare i tuoi contenuti sul lato client ... e un modo ragionevole per farlo è con una chiave privata ... il problema è che poiché questa è un'app web e avrai bisogno del Private-Key su più dispositivi diversi ... devono inviarlo al server. Questo è un problema per molte ragioni:

• La chiave privata è protetta da passphrase ... giusto? Certo, ma chi ti ha dato l'algoritmo per proteggere quella chiave privata? Inoltre, chi ti ha fornito l'algoritmo per codificare in modo sicuro i tuoi contenuti con la chiave privata? Non ti fidi di mailfence.com con i tuoi contenuti di testo chiari ... ma ti fidi di loro per fornirti il codice per proteggere i tuoi contenuti e la chiave utilizzata per proteggerli da questi contenuti? Ancora una volta, sono sicuro che le persone di mailfence.com siano tutte persone oneste ... ma se hai intenzione di fidarti di loro con la porta, il lucchetto e la chiave del lucchetto ... potresti anche fidarti di loro con cosa è dall'altra parte.
• Anche se mailfence.com usava un cdn di terze parti per ospitare il codice per creare, impiegare e proteggere la tua chiave privata ... e quella terza parte era in qualche modo indiscutibilmente sicura ... il browser ha ancora un runtime malleabile . Ciò significa che se hai caricato super-secure.js da untouchable-cdn.com ... se mailfence.com ha una singola riga di codice javascript proveniente da qualsiasi altra parte ha il potenziale di sovrascrivere le funzioni della libreria super-secure.js ... c'è nessun modo per impedirlo.
• Se hai generato la tua chiave privata tramite la riga di comando con una passphrase e poi incollata nel tuo browser ... stai ancora memorizzando la tua chiave privata sul server. Ciò significa che nel caso in cui ci fosse una violazione della sicurezza su mailfence.com ... qualcuno potrebbe ottenere la chiave privata protetta da passphrase e iniziare la decrittazione della forza bruta. Certo, questo non è più o meno sicuro di Google che genera e utilizza un lato server di crittografia per crittografare tutti i tuoi contenuti utente, tuttavia è molto meno sicuro rispetto a non aver mai dato loro accesso alla tua chiave privata in nessuna forma.

... Ci sono ancora ulteriori problemi alcuni dei quali possono essere trovati here sebbene sia stato scritto nel 2011 e alcuni dei problemi non sono più veri per i browser correnti.

ulteriori argomenti che potrebbero essere elaborati in seguito se trovo il tempo:

• Garbage collection basata su Javascript ... e mancanza di un modo per forzare "l'eliminazione" dei segreti dalla memoria
• mancanza di un generatore di numeri casuali sicuro (non sicuro se questo è ancora vero)
• Un modo per generare e archiviare chiavi private che non dipendono da un'ancora di attendibilità esterna. (parzialmente coperto sopra)