Creazione di un servizio di posta elettronica sicuro e crittografato

-1

Modello

Le persone che vivono in paesi con regimi totalitari, oppressivi e altri minacciosi dovrebbero essere in grado di utilizzare questo sistema e avere un certo grado di privacy quando comunicano.

Obiettivi

  • La crittografia è difficile da capire per le persone non tecniche, dovrebbe essere facile da usare.
  • Crittografia lato client con OpenPGP.JS
  • Il codice dovrebbe essere minimo e mantenibile.
  • Dovrebbe prendere in considerazione l'anonimato
  • Dovrebbe essere compatibile con yubikey

Domande

  • L'archiviazione delle chiavi private (crittografate) su un server raggiungibile tramite TLS è una buona soluzione?
  • Le chiavi devono essere memorizzate solo nella memoria locale?
  • C'è qualcosa che ci manca qui?

Note

Per favore mantieni il tuo consiglio generale e sii il più specifico possibile, sii utile.

    
posta Herr 08.12.2014 - 20:15
fonte

4 risposte

3

La più grande difficoltà che avrai nella costruzione di questo sistema non è tecnica, ma più politica e legale. Sarai preso di mira da ogni governo nel mondo. Il governo sarà la tua più grande minaccia e non riesco a vedere dove potresti trovare un hosting adeguato senza una qualche forma di "backdoor / canale" per le agenzie governative.

Ad esempio, qui negli Stati Uniti, probabilmente riceverai una Lettera di sicurezza nazionale che significa che hai vinto " È anche possibile riconoscere di essere costretti a consegnare le chiavi. Il governo probabilmente promuoverà il terrorismo e il crimine come ragionamento per la NSL, quindi passerai molto tempo a cercare di farlo decollare in qualsiasi paese del mondo. Quindi sulle parti tecniche di questo, insieme agli ostacoli che dovrai superare per renderlo veramente sicuro.

Inizierò rispondendo alla tua ultima domanda: " C'è qualcosa che ci manca qui? " Ecco in sostanza ciò che stai cercando di fare

PersonUsingService —> connects to your systems —> encrypt/decrypt email 

Scenario 1) La macchina di PersonUsingService è fuori controllo. Qualsiasi software dannoso (rootkit, logger di tasti, ecc.) Significa che il tuo sistema ha fallito, anche se ha fatto il suo lavoro. Immagina di aver costruito qualcosa che ha attirato l'attenzione di EFF / ACLU, hanno usato il servizio solo per scoprirlo, le loro comunicazioni sono finite su Pastebin . Tutto quello che sapranno è che ha attraversato i tuoi sistemi e, alla fine, la tua reputazione soffre.

Scenario 2) PersonUsingService's è MITM prima di raggiungere il tuo server. Di fatto, i governi collocano Narus tap su IXP e / o rubano a titolo definitivo il certificato o pagano pesantemente a una CA. Il tuo sistema fallisce.

Scenario 3) Ti prendi il tempo necessario per creare uno schema meraviglioso ma non hai mai protetto la tua infrastruttura interna, qualcuno fa clic accidentalmente su un link mentre si trova nella tua squadra di sviluppo. Permette ai governi o ai ladri di accedere al tuo sistema di chiavi.

Posso dare dozzine di esempi del perché questa è una battaglia persa. Mentre capisco da dove vieni nel chiedere un tale sistema, la realtà è che è molto complessa non dal lato tecnologico, ma dal campo giuridico.

Torna alle tue domande: "Memorizza le chiavi private (crittografate)" (fermato qui) NESSUNO, ma il proprietario della chiave dovrebbe avere accesso alla propria chiave privata altrimenti il sistema fallisce. L'intero scopo della crittografia era di mantenere private le chiavi private. In un mondo ideale, ci sarebbe comunque fiducia, in quello che inizialmente affermavi: "Le persone che vivono in paesi con regimi totalitari, oppressivi e altri minacciosi" devi ricordare questi tipi di regimi non hanno problemi a usare " Crypto Rubber Hose " per accedere ai tuoi sistemi (e alle tue chiavi).

Dal punto di vista tecnico, forse è meglio dare un'occhiata a Vanish e al modello emanato da loro, e costruisci intorno a questo. Ad esempio:

PersonUsingService —> log in —> create disappearing (24-48hr key) —> encrypt message
System —> 24-48 expiry —> erase keys

In qualcosa di simile a questo modello, era necessario preoccuparsi di memorizzare le chiavi poiché la probabilità di un "raid di risposta rapida" per ottenere una sospensione delle chiavi di crittografia è bassa. La mia percezione del motivo per cui nessuno sta spendendo tempo a rispondere a questo, è perché le aziende hanno provato questo in passato (Hushmail) e bruciato attraverso un sacco di soldi facendo così. Per non parlare, alla fine, la legge supera le opinioni personali, le convinzioni, ecc. Se un governo dichiara di rinunciare alle chiavi, hai una lotta per tutta la vita cercando di dimostrare il tuo punto.

    
risposta data 10.12.2014 - 21:50
fonte
8

Il più grande punto che ti manca è un modello di minaccia. Hai un elenco puntato delle decisioni di sicurezza che hai preso (alcune sono piuttosto discutibili), ma non hai idea di chi stai difendendo o quali sono le loro capacità (sia tecniche che legali). Le opportune precauzioni per difendersi contro il tuo fratellino sono molto diverse da quelle per la difesa contro l'FBI, che a loro volta differiscono da quelle per la difesa contro la mafia russa.

    
risposta data 09.12.2014 - 04:23
fonte
1

Penso che tu abbia un punto giusto qui. Nel modello di thread corrente, l'unica cosa che dovresti considerare è dove e HOW le chiavi sono memorizzate.

La memorizzazione delle chiavi, a condizione che siano crittografate, sul server e trasferendole ESCLUSIVAMENTE tramite TLS non dovrebbe costituire un problema.

Dovresti cercare come hanno fatto i grandi giocatori in quest'area, come i servizi che hai menzionato, fastmail, lavabit e amp; ecc.

    
risposta data 09.12.2014 - 08:13
fonte
1

Forse vuoi crittografia basata su pairing (un sottoinsieme di Crittografia basata su ID ) per risolvere i problemi di keying e memorizzazione delle chiavi.

    
risposta data 10.12.2014 - 20:54
fonte

Leggi altre domande sui tag