Vedo che nella comunita’ di quelli che dicono di amare la privacy si continua ad esaltare il protocollo Matrix, facendo credere che sia sicuro quanto Signal , (ovvero, quanto lo sarebbe signal se non avesse usato alcune librerie per costruire il server) con un abuso assurdo della parola E2EE.
La cosa che mi sta urtando particolarmente in tutto questo e’ che chi usa Matrix, o suggerisce di usarlo, continua a parlare come se fosse altrettanto sicuro del protocollo Signal, cosa che non e’: Matrix e’ un compromesso.
Provo a spiegare perche’.
Il protocollo di Signal / Olm / Double Ratchet cryptography, a seconda del gergo che volete usare, usa un metodo per la generazione di chiavi uniche che e’ ricorsivo. Cosa significa?
Significa che durante la conversazione non state crittografando il vostro messaggio sempre con la stessa chiave, ma la chiave cambia (viene aggiornata) ad ogni messaggio che inviate.
- ciao (chiave: 6f0378f21a495f5c13247317d158e9d51da45a5bf68fc2f366e450deafdc8302)
- come stai (chiave: 615452c145c402b73764ddecdd5a76e59faa25b68258474cfd259536c1c39a06)
- e a casa? (chiave: 5c2fb30bed30bd2cce6700122cae3c8b839cbffbca29a6e95408b32290a16ba4)
il trucco e’ quello che si usa anche con google authenticator, cioe’ si una una funzione che lavora solo “in avanti” ma non puo’ “tornare indietro”. Il risultato e’ che se anche qualcuno rubasse la chiave numero due, non riuscirebbe a leggere il messaggio numero tre, perche’ la chiave e’ diversa.
Ovviamente il server e il client devono essere sincronizzati, quindi mentre aprite un account non fate altro che stabilire il valore iniziale e il numero di messaggi usati.
Sin qui tutto bene. Ma sapete bene che i protocolli di chat non servono a comunicare persona-a-persona, ma client-a-client: significa che magari avete un client sul computer, uno sul cellulare bello, uno su quello sgrauso, eccetera.
E adesso la domanda e’: ma come fanno tutti i client ad essere sincronizzati? Cioe’, se avete piu’ cellulari e scrivete sulla stessa room, ma i cellulari non sanno di preciso a che numero di messaggi sono, come fanno ad allinearsi? E se si allineassero, come farebbero ad essere sicuri di essersi allineati nella maniera giusta?
La soluzione scelta e’ quasi sempre quella di associare il vostro cellulare (l’ MSISDN , cioe’ il numero di telefono) al client. Poi, mediante un QRCODE, potrete aggiungere altri dispositivi, ma solo per usare un’interfaccia web: ci pensera’ poi il server , che e’ sempre allineato col client primario, a tenere il conto della chiave e dell’iterazione in cui vi trovate.
Ma non solo. Anche se vi rubassero un laptop, per tagliarlo fuori basta fare in modo che esso sia disassociato alla chiave, generandone un’altra, che invece funziona per gli altri client, ed ecco che il portatile rubato non riuscirebbe piu’ a comunicare o a leggere nulla.
In breve:
- Ogni messaggio è crittografato con una chiave diversa. Se un attaccante ottiene la chiave di un messaggio, può decodificare solo quel messaggio.
- Se il client non conserva ognuna di queste chiavi, ogni messaggio può essere decodificato solo una volta, perche’ ad ogni lettura cambia la chiave.
- Se un attaccante ottiene l’accesso ai dati che generano le chiavi (il cricchetto della chiave), può decrittare i messaggi solo fino a quando i partecipanti alla conversazione completano un ciclo di invio-risposta (perché la doppietta DH che viene utilizzata per generare il modulo della chiave sarà sostituita).
- L’attaccante non può decrittare i messaggi passati perche’ non ha le chiavi passate
- Una volta decodificati, i messaggi sono in “deniability”: Non è possibile provare che l’altra parte li ha inviati.
Bene.
Tutto bene? No.
Stiamo parlando di un protocollo che lavora tra Me e Te. Se siamo solo in due, esso e’ radicalmente sicuro, e peraltro riusciro’ sempre ad essere sicuro che Te sia proprio Te, visto che chiunque altro non avrebbe le chiavi passate, e peraltro se anche avesse rubato il dispositivo client (cellulare o laptop) , al primo messaggio i due sarebbero disallineati, e un nuovo DH verrebbe generato.
Ma se per esempio entriamo in una stanza con molte persone, e abbiamo due client, che succede? Se i due client sono come Signal o Whatsapp, in realta’ avremo UNA SOLA DH, condivisa tramite qcode mediante web e generata al momento , e quindi non avremmo problemi.
Ma specialmente, siccome non abbiamo condiviso la DH con ognuno dei partecipanti, ed essa e’ stata cambiata ad ogni messaggio, come facciamo a decodificare i messaggi passati, e come facciamo a distinguere due client della stessa persona?
Matrix risolve il problema con un compromesso: smette di usare l’algoritmo “duro”, quello sicuro, e vi fa usare un algoritmo meno potente, per trovare un algoritmo. Questo algoritmo si chiama “MegOlm”. (https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md)
Il problema di MegOlm e’ che rispetto al Double Ratchet classico (come quello di Signal), questa implementazione e’ meno robusta, e perde alcune feature di sicurezza.
Lo potete vedere qui, alla voce Limitations: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#limitations
Perche’ questa cosa fa male all’utente?
- perche’ si tolgono requisiti alla criptazione, per esempio non avete piu’ la stessa certezza di parlare con chi credete di parlare, come la avreste con OLM/Double Ratchet.
- NON VIENE DETTO ALL’UTENTE.
Se voi andate a leggere i cazzari della sicurezza e della praivaci che parlano ovunque, vedrete che vi descriveranno Matrix come alternativa a signal, lasciando intendere che abbiate lo stesso livello di sicurezza rispetto ad un client che si premura di tenere OLM e un DH unico.
E la cosa ancora piu’ triste e’ che il problema si poteva risolvere: anziche’ condividere un DH con chiunque abbia un dato numero di telefono verificato, la verifica si poteva fare usando un OTP (One Time Password) come Google Authenticator, o qualche OTP open source.
Allora, quando si ripudia Signal perche’ “non e’ trasparente” per poi andare su Matrix, che non informa l’utente del fatto che potrebbe non parlare davvero con chi crede di parlare, a me sembra doveroso alzare la mano e dire “ehm… no”.
Perche’ questo fa male alla community:
dopo questo “compromesso” alla sicurezza, MegOlm e’ sicuro quando lo e’ un server XMPP/Jabber quando usa un client (Dino, per esempio) con OMEMO e OpenPGP.
Anzi, leggermente meno, perche’ Dino vi consente di settare se volete “Blind Trust by default” oppure no, mentre Matrix fa Blind Trust SEMPRE:
Ma la differenza e’ che usando un semplice RaspBerry chiunque puo’ ospitare a casa propria, usando il router domestico, un server leggero come Prosody. E’ semplice da mettere in selfhosting , e su un Raspi 4 puo’ reggere centinaia di utenti.
Quando parliamo di Matrix, invece, parliamo di un’implementazione che come minimo richiede 4GB di RAM e un processore decisamente potente, per ospitare UN utente. E non sto scherzando.
In poche parole, si sta rendendo piu’ difficile il selfhosting (che consentirebbe alle varie organizzazioni di costruire facilmente ed economicamente degli host per i propri utenti , a spese delle comunita’, che magari hanno bisogno di poter far girare tutto con pochi soldi, in paesi ove i server di chat principali sono tutti sorvegliati.
IN generale, trovo l’ Hype per matrix estremamente dannoso, perche’:
- fornisce un falso senso di sicurezza
- non informa correttamente l’utente del compromesso in corso
- limita il selfhosting a chi e’ abbastanza ricco da pagarsi un server potente
e quindi, mi spiace… ma anche Matrix no.
