Autore: Joe Data: To: hackmeeting Oggetto: [Hackmeeting] Il post coi disegnini sulla crittografia end-to-end
nel browser
Ciao a tutti,
dato che mi pare ci sia un po' di confusione sul tema, mi sembra il caso
di chiarire qualche concetto. Ovviamente qui c'e' gente che di
crittografia sa piu' di me e che correggera' eventuali errori/omissioni.
I modelli che nel tumultuoso thread precedente abbiamo confrontato come
metodi di fruizione della crittografia E2E sono i seguenti:
- Una applicazione standalone da scaricare ed installare
- Un'estensione di un browser opportunamente sandboxed
- Una web application che funzioni sul browser "liscio".
Iniziamo dalle basi: quando parliamo di crittografia "end to end"
intendiamo che le comunicazioni tra due utenti, Alice e Bob, sono
cifrate alla sorgente da Alice e sono solo decrittabili da Bob.
Un classico esempio di tale sistema crittografico e' GPG: Alice cifra il
messaggio alla sorgente con la chiave GPG di Bob, e il messaggio lo puo'
leggere solo Bob. O, piu' precisamente, solo qualcuno che sia in
possesso della chiave privata di Bob.
Vediamo come questa applicazione si puo' gestire nei tre casi:
- BROWSER "LISCIO": Alice apre la sua fichissima
webapp-con-supporto-a-gpg e cifra il suo messaggio con la chiave
pubblica di Bob. Bob apre a sua vota la suddetta webapp e legge il
messaggio usando la sua chiave privata. Per fare quello, la chiave
privata deve essere letta dal motore javascript del browser, utilizzando
uno script javascript opportunamente gestito dal server. Peccato che la
sicurezza della chiave privata di Bob dipenda *integralmente* dal fatto
che il gestore del server sia affidabile e che il server in questione
non sia bucato ad *OGNI* richiesta. Se non e' cosi', infatti, il
javascript di cui sopra potrebbe tranquillamente succhiarsi la chiave
privata di Bob, gia' decifrata dalla sua passphrase, e rubarla. Insomma
esattamente l'opposto dello scopo della crittografia e2e: il server deve
essere integro per garantire la cifratura delle comunicazioni.
- ESTENSIONE DEL BROWSER: Sia Alice che Bob scaricano un'estensione del
browser tramite il chrome store. Dopo di che tutto avviene *quasi* come
nel caso precedente, a parte il fatto che la componente javascript sta
dentro l'estensione e non e' possibile per il contesto d'esecuzione del
javascript della pagina web accedere alla chiave privata. Percio' in
questo caso ci dobbiamo solo fidare di Google (o qualsivoglia altro app
store) e di chi ci fornisce la connettivita' verso di esso) quando
scarichiamo l'estensione.
- APPLICAZIONE "TRADIZIONALE": In questo caso Alice e Bob si devono
fidare del sistema di distribuzione del software in questione scelto dal
fornitore (ad es, le firme gpg dei pacchetti debian).
Spero che sia un po' piu' chiaro a tutti qual'e' la criticita' piu' o
meno insormontabile del primo scenario. E perche' comunque ritengo
preferibile affidarmi a debian che a google o a apple :)
Da questa discussione ho volutamente lasciato fuori il problema
interessante e difficile, ovvero come rendere facile e insieme
affidabile la parte complessa della crittografia E2E: la certificazione
dell'identita' del proprio interlocutore. Questo problema e' stato
brillantemente risolto in LEAP con la creazione del nymserver, non sono
certo che sarebbe possibile interagire correttamente con esso
all'interno di una estensione del browser, ma non ho mai affrontato la
questione sul serio.
Integrazioni / correzioni sono sempre benvenute.
Ciao
