La scansione lato client esamina i contenuti sul dispositivo dell’utente, dove possono essere già leggibili prima dell’invio o dopo la ricezione. Può quindi creare un percorso di divulgazione esterno al canale di consegna cifrato. Confrontare il checksum di un APK non dimostra che un’app non contenga codice di scansione. Risponde a una domanda più circoscritta: se i byte selezionati corrispondono a una determinata impronta.
Tenere separate queste affermazioni rende più utili sia la cifratura sia la verifica del software.
Perché la scansione su un dispositivo cambia il confine della privacy
Un’app deve gestire dati in chiaro per mostrare un messaggio o preparare una foto da inviare. Una funzione di scansione può operare in quel punto, anche se il successivo messaggio di rete è cifrato end-to-end. Ciò che lascia il dispositivo dipende dal progetto dello scanner: potrebbe segnalare una corrispondenza, caricare contenuti selezionati o inviare altre informazioni derivate.
Il lavoro di ricerca Bugs in our Pockets esamina rischi tra cui abusi, falsi positivi e ulteriore superficie di attacco. Sono motivi per esaminare i flussi di dati e la governance di un sistema di scansione proposto. Non dimostrano che ogni funzione sul dispositivo sia sorveglianza, né che una legge specifica abbia imposto un obbligo universale di scansione.
Una funzione locale sotto il controllo dell’utente non equivale automaticamente a una segnalazione obbligatoria. Chiedi chi sceglie l’analisi, cosa la attiva, chi può aggiornarne le regole e quali dati possono lasciare il dispositivo.
Quattro forme diverse di evidenza sul software
| Controllo | Cosa può dimostrare | Cosa non può dimostrare da solo |
|---|---|---|
| Checksum SHA-256 | Il file corrisponde a un’impronta di riferimento attendibile | Che il programma di riferimento sia sicuro o corrisponda al codice sorgente |
| Verifica della firma APK | La firma del pacchetto è verificata e identifica un certificato di firma | Che il firmatario sia affidabile o che il codice non abbia comportamenti indesiderati |
| Build riproducibile | Il sorgente e gli input di compilazione specificati possono produrre gli artefatti attesi | Che il sorgente sia privo di vulnerabilità o logica dannosa |
| Revisione e test indipendenti | Risultati relativi a una versione e un ambito definiti | Una garanzia permanente per tutti gli aggiornamenti futuri |
La documentazione di apksigner di Android spiega la verifica dei pacchetti e la visualizzazione delle informazioni sui certificati. La definizione di Reproducible Builds spiega perché sorgente, ambiente di compilazione e istruzioni sono tutti importanti per riprodurre un artefatto.
Un archivio del sorgente e un checksum stampato accanto non sono, da soli, un risultato di build riproducibile. Analogamente, una firma valida su una release malevola rimane una firma valida.
Come controllare un download senza sovrainterpretare il risultato
Identifica prima la release desiderata e ottieni il suo APK e l’impronta attesa tramite un percorso di distribuzione affidabile. Calcola l’impronta localmente. Se differisce, non installare il file finché la discrepanza non è spiegata: una release diversa, un download incompleto o una manomissione possono tutti causare una mancata corrispondenza.
Se corrisponde, registra la release e il risultato. Hai stabilito l’uguaglianza dei byte rispetto a quel riferimento, non l’assenza di scansione lato client. Se lo stesso attaccante può sostituire il download e il checksum visualizzato, il confronto può comunque riuscire. Riferimenti indipendenti, continuità della chiave di firma e trasparenza delle release aiutano ad affrontare parti diverse di questo problema di fiducia.
Per un’affermazione di corrispondenza tra sorgente e binario, cerca istruzioni di compilazione documentate e risultati riprodotti in modo indipendente per la release effettiva. Non dedurre questa proprietà dalle parole «open source».
Gli aggiornamenti restano importanti
La distribuzione del software può essere attaccata, ma evitare indefinitamente gli aggiornamenti di sicurezza non è una valida difesa generale. Gli aggiornamenti correggono anche vulnerabilità sfruttabili. Usa un canale di aggiornamento affidabile, esamina gli avvisi di sicurezza rilevanti e verifica le evidenze della release quando il tuo rischio lo giustifica. Una vecchia versione con una falla nota non è più sicura solo perché il suo checksum una volta corrispondeva.
Cosa dimostra il Proof Lab di Livara
Il Proof Lab di Livara offre un confronto locale dell’impronta degli APK e dimostrazioni crittografiche nel browser. La pagina dichiara che non esegue i ratchet completi LVR1/LGS1 e non costituisce un audit del protocollo. Anche il suo modello di minaccia spiega il limite che emerge quando un attaccante può sostituire sia un file sia la sua impronta attesa.
Questi controlli sono utili entro il loro ambito. Non provano che un telefono su cui l’app è installata sia privo di malware, che Livara abbia release riproducibili in modo indipendente o che la sua applicazione non possa contenere comportamenti non dichiarati. Leggi separatamente la documentazione di sicurezza per conoscere i confini dichiarati della protezione dei messaggi.
La domanda giusta non è se un badge dica «verificato». È quale affermazione sia stata testata, rispetto a quale riferimento affidabile e per quale release esatta.
