In MindTheClub il contenuto dei messaggi viaggia direttamente tra due dispositivi su un canale peer-to-peer crittografato. Nessun server MindTheClub, e nessuna terza parte, archivia il contenuto dei tuoi messaggi.
Per stabilire quella connessione diretta, due dispositivi devono scambiarsi una piccola quantità di informazioni di configurazione e, se uno dei due dorme, un segnale per svegliarlo. Questi due passaggi di supporto sono gli unici punti in cui è coinvolto un server, e qui sotto descriviamo con precisione cosa ciascuno può e non può vedere.
Prima che tutto questo accada, i due dispositivi devono conoscere l'identità l'uno dell'altro. Lo descriviamo per primo, perché ogni passaggio successivo di questa pagina si basa su di esso.
Ogni passaggio crittografato che segue si basa su un presupposto: ciascun peer usa la chiave pubblica vera dell'altro, non una sostituita da un fornitore nel mezzo. Lo otteniamo con un unico scambio fuori banda e una risposta sigillata, così entrambe le parti risultano verificate dopo una sola scansione di QR o un tocco su un link di invito.
Il tuo codice QR contiene il tuo identificativo utente e un'impronta della tua chiave pubblica, un breve hash crittografico che la identifica in modo univoco. Il tuo link di invito porta le stesse due cose, incorporate nel link stesso. Quindi, che qualcuno scansioni il tuo codice o tocchi il tuo link, il suo dispositivo riceve la stessa impronta da verificare. Mostrare il QR di persona è il canale più forte, ma in entrambi i casi vale la garanzia qui sotto: il fornitore della directory non può mai sostituire la tua chiave senza essere scoperto.
Quando l'altra persona scansiona o tocca, il suo dispositivo recupera la tua chiave pubblica dalla directory e ne calcola l'impronta localmente. Se corrisponde a quella nel QR o nel link, la chiave viene accettata; altrimenti viene rifiutata e non salvata. Una chiave sostituita produce una discrepanza, e il dispositivo la rifiuta.
Il suo dispositivo ti invia poi una richiesta di contatto con la propria impronta sigillata all'interno, crittografata con la tua chiave verificata. Solo tu puoi decifrarla. Il tuo dispositivo esegue lo stesso controllo al contrario, accettando il contatto solo se le impronte corrispondono.
Dopo una scansione o un tocco, entrambi i peer hanno verificato in modo indipendente la chiave dell'altro, e un fornitore che detiene la directory non può sostituirne nessuna delle due senza rompere un controllo che non ha il potere di falsificare.
MindTheClub usa i canali dati WebRTC per trasportare i messaggi. Un canale dati WebRTC è una connessione diretta e crittografata tra due dispositivi. Una volta stabilito tra due peer:
I file grandi vengono divisi in blocchi e inviati sullo stesso canale diretto, con logica di ritrasmissione sul dispositivo mittente per garantire la consegna finale. I blocchi viaggiano peer-to-peer come tutto il resto.
A volte due dispositivi non riescono ad aprire un percorso diretto (NAT restrittivi, firewall degli operatori mobili). In quel caso WebRTC ripiega su un relay TURN per far passare il flusso crittografato. MindTheClub usa il servizio TURN di Cloudflare per questo ripiego. Il relay inoltra pacchetti crittografati; è una parte standard del funzionamento di WebRTC quando una connessione diretta non è possibile. Questo ripiego riguarda solo il percorso di rete del flusso crittografato; non cambia il fatto che il contenuto resta end-to-end tra i due dispositivi.
Prima che un canale WebRTC possa aprirsi, i due dispositivi devono scambiarsi informazioni di «signalling»: descrizioni della connessione e indirizzi di rete candidati (in termini WebRTC, l'offer/answer SDP e i candidati ICE). È un requisito universale di WebRTC: ogni applicazione WebRTC, compresi i siti di videochiamate, lo fa. Le informazioni sono piccole e servono solo a stabilire la connessione: non sono il contenuto dei tuoi messaggi.
La domanda è: chi trasporta quel signalling, e cosa può vedere? In MindTheClub:
Abbiamo progettato il signalling in modo che il relay apprenda il meno possibile:
Se il telefono di Bob dorme o l'app non è in esecuzione, il dispositivo di Alice ha bisogno di un modo per svegliarlo affinché possa unirsi alla connessione. Per questo MindTheClub usa Firebase Cloud Messaging (FCM), il servizio push di Google, perché è il meccanismo che Android mette a disposizione per svegliare in modo affidabile un'app dal background.
Il contenuto del payload di sveglia viene crittografato con la chiave pubblica del destinatario prima di lasciare il mittente. Punto cruciale: l'identità del mittente è dentro quel payload crittografato: non è visibile all'infrastruttura push. È un design a «mittente sigillato»: chi consegna il push non può vedere chi l'ha inviato.
Per consegnare un push, qualsiasi sistema push deve sapere chi lo riceve: è così che funziona la consegna, ed è vero per ogni messenger basato su push. L'indirizzo del destinatario è quindi necessariamente visibile al livello push. Ciò che non è visibile è l'identità del mittente, che resta sigillata dentro il payload crittografato.
Per stabilire la connessione WebRTC, i dispositivi hanno bisogno di credenziali a breve scadenza per il servizio STUN/TURN (i componenti che aiutano due dispositivi a trovare un percorso di rete l'uno verso l'altro). Queste credenziali vengono generate con una chiave segreta che deve restare fuori dal dispositivo.
MindTheClub recupera queste credenziali da un Cloudflare Worker che custodisce il segreto lato server. Nessun servizio Google è coinvolto nell'ottenimento delle credenziali di connessione. Se il recupero fallisce, la connessione ripiega su server STUN pubblici, che aiutano solo un dispositivo a scoprire il proprio indirizzo pubblico e non apprendono nulla su chi sta per contattare.
Mettendo tutto insieme: i peer verificano le chiavi l'uno dell'altro con una scansione di QR o un link, poi si scambiano piccole quantità di informazioni di configurazione crittografate tramite un relay senza stato e un push di sveglia sigillato. Una volta aperto il canale diretto, il contenuto dei messaggi fluisce solo da dispositivo a dispositivo.