Corso per figli di imprenditori 💀🗿

Penso che a 14 gradi morirei assiderato

Ho appena scoperto con piacere che proprio Arke è stato menzionato in un commento alla RFC:
github.com/bluesky-soci...

I vari link che ho mandato si riferiscono tutti a protocolli diversi: il paper del 2024 parla di "Arke", che sviluppa un'idea da un paper del 2020 che parla di "UDM"; Signal ha usato gli HSM.
Mi sembra che BS migliori su Signal e UDM, ma possa fare di più con gli HSM. Non so dire su Arke

Tuttavia sarebbe sempre un compromesso, perché i sistemi basati su hardware sicuro dipenderebbero da tecnologie proprietarie dei produttori di CPU e comunque richiederebbero di mandare i numeri di telefono
La ricerca si sta avvicinando a una soluzione pratica e solida ma forse non ci siamo ancora

Secondo me, potenzialmente BS potrebbe migliorare il protocollo senza stravolgerlo usando alcune delle tecniche che usa Signal, e in effetti loro stessi lo accennano in fondo alla RFC, ma mi dispiace che non vogliano farlo per ora.

Questo descritto in un paper del 2020 (par.nsf.gov/biblio/10160...), da quel che ho capito senza approfondire troppo, protegge adeguatamente i grafi sociali degli utenti ma non i numeri dei contatti registrati al servizio. -->

Dal 2017 a oggi, Signal prende i numeri dei contatti, usando "hardware sicuro" lato server per evitare che Signal possa leggerli, ma soffre almeno di attacchi di enumerazione.
signal.org/blog/contact...
signal.org/blog/private... -->

Anche qui evitare di ricevere i numeri potrebbe non essere semplicissimo: sembra che la ricerca privata dei contatti sia un problema irrisolto (o forse risolto con compromessi) e tuttora argomento di ricerca: l'ultimo paper che trovo è del 2024 (eprint.iacr.org/2023/1218) e sembra interessante -->

Alla fine sono d'accordo ma non è così semplice: se l'attaccante conosce #C allora conosce automaticamente anche hash(#C) e qualsiasi sua trasformazione che non si basa su un segreto noto solo a C e BS. All'attaccante basterebbe sapere questo dettaglio del protocollo per continuare a impersonare C.

Ci sarebbe anche un problema di scoperta dei grafi sociali: se una persona con # noto è su BS, potrei impersonarla e trovare i suoi contatti su BS. Non so se questo possa essere generalizzato per trovare i grafi sociali di tutti, attaccando tutti i possibili #A, però è un'altra cosa da considerare

O, alternativamente, si inviano i contatti e il server aspetta la verifica del numero prima di salvare gli hash nel db. Non so come faccia Bluesky ma credo che funzioni ugualmente.

L'attaccante otterrebbe così:
-la scoperta che #A è un numero di telefono valido, se trova un qualsiasi match
-la scoperta, via ricerca binaria come descritto nella RFC, dei numeri dei match (tra i vari #B) e delle associazioni tra #B e account Bluesky, se B ha il contatto di A. (5/5)

Mi sembra che, in caso di invio diretto degli hash, un attaccante potrebbe fingere di possedere uno o più numeri che non ha (chiamiamoli #A), e passare un gran numero di Hash(#A, #B), con #B variabile sul libretto dei contatti. Per semplicità diciamo che #B > #A. (4/5)

Premettiamo che le coppie di numeri vanno ordinate prima di fare l'hash, altrimenti la coppia (#A, #B) data da A darebbe un risultato diverso dalla coppia (#B, #A) data da B, e A e B non si troverebbero. Diciamo che sono in ordine crescente. (3/5)

Bluesky fa quindi l'hash delle coppie (#C, #contatto) e non trova match, perché i contatti non hanno C come contatto. Bluesky non suggerisce utenti a C, l'attacco fallisce.
Se si inviassero direttamente gli hash invece dei numeri, potrebbe esserci paradossalmente un problema di privacy. (2/5)

Una volta che il client (C) ha verificato il proprio numero, c'è una finestra in cui il server ricorda il numero di C.
In questa finestra, C invia la lista dei contatti e può inviare contatti arbitrari, ma non può mentire sul proprio numero. (1/5)

Ciao Christian, intanto scusa perché ieri ho frainteso completamente il tuo articolo, ignorando che gli hash vengono calcolati sulle coppie di numeri. Questo cambia tutto in caso di furto di db.
Invece su questo punto ho risposto qui (e sul commento di livello superiore):
bsky.app/profile/gees...

Il problema fondamentale è che non si può fare questa verifica lato app, perché non si può fare affidamento su un client controllato da un attaccante. C'è bisogno di un round trip, come si fa per la verifica delle email.

Request For Comments: A secure contact import scheme for social networks | Bluesky This article outlines plans for a future Bluesky feature \- it doesn’t exist yet\! By sharing our ideas early, we hope to solicit feedback from the community.

Letta, c'è decisamente molto lavoro dietro.
Rileggendo l'articolo di Christian, ho capito di aver perso il dettaglio importante che fanno hash di coppie di contatti, non dei singoli numeri. Però spiegano anche che i numeri servono a verificarne il possesso per evitare un'enumerazione lato app

E comunque richiederebbe a qualche programmatore di conoscere il segreto.
<Aggiunta in seguito a eliminazione vecchio commento>:
Anzi, non avrebbe proprio senso perché il segreto sarebbe esposto nell'app prima di finire nel SE.
Quindi una black box del genere non potrebbe essere fatta client side

Apparentemente esiste l'idea di sale segreto, si chiama pepe:
en.wikipedia.org/wiki/Pepper_...
Tutto sommato la black box si potrebbe tentare anche lato client con i Secure Element, ma non è così semplice: per esempio, avendo rubato il db degli hash, si potrebbe pensare di usare l'app come oracolo.

Naturalmente per me l'alternativa migliore è non prendere né i numeri di telefono né gli hash, con sale o meno.

È sicuramente strano parlare di sale come segreto e questa è solo una cosa che ho pensato al momento, ma non so se la scarterei immediatamente come security by obscurity.
Bisogna comunque confrontare questo con l'alternativa di conservare soltanto gli hash senza sale, che chiunque potrebbe invertire

..si può prendere il numero di telefono e passarlo a una black box che aggiunge il sale segreto e fa l'hash.
Poi si salva il risultato nel db e, si spera, si scarta il numero di telefono senza lasciare accidentalmente copie in memoria permanente. (4/4)

Per questo andrebbe usato il sale, ma se è sempre lo stesso ed è salvato nel db allora è come se non ci fosse; se è sempre diverso, la scoperta dei contatti non può funzionare.
Quindi invece... (3/4)

Il grosso problema dell'invio diretto degli hash è che, in caso di breccia dati, questi hash sono inutili: siccome lo spazio dei numeri di telefono è molto piccolo, è banale craccare tutti gli hash provando uno a uno tutti i possibili numeri. (2/4)

Penso che ci possa essere una valida spiegazione tecnica, che spiegherebbe anche l'uso del sale apparentemente inutile.
In particolare, calcolare gli hash lato server potrebbe aver senso se si tratta il sale come segreto. (1/4)

Can you tell me more about it or shoot me a DM when this happens again? I've been looking into these issues.

Political Microtargeting by EU Commission illegal EDPS issues decision finding that the European Commission has illegally targeted advertising at citizens

Per chi non sappia: noyb.eu/en/political...