GrapheneOS sotto attacco: la vera storia del progetto, tra polemiche e sicurezza Android

La polemica nata attorno a un “dossier” su GrapheneOS pubblicato da una testata USA tocca un punto molto delicato, cioè il rapporto tra storia di un progetto open source, controllo tecnico dell’infrastruttura e credibilità pubblica di una piattaforma che oggi occupa una posizione precisa nella sicurezza mobile. Come spiegato nella guida a GrapheneOS non si tratta di un progetto marginale nato da una discussione sui social: la sua storia documentata sul sito ufficiale fa risalire le origini al 2014; la fondazione senza scopo di lucro che sostiene raccolta e distribuzione delle donazioni esiste in Canada dal 17 marzo 2023.

In mezzo c’è un passaggio cruciale: il progetto che in origine portava il nome CopperheadOS è stato rinominato prima Android Hardening Project e poi GrapheneOS.

Il team di GrapheneOS prova a spostare una narrazione definita come quasi romanzata a una sequenza di eventi verificabili: nascita del progetto prima della società Copperhead, controllo mantenuto da Daniel Micay sull’opera open source, rottura del 2018 sulla gestione del progetto e sul tema delle signing keys, prosecuzione del lavoro sotto il nome GrapheneOS. I responsabili del progetto osservano che trattasi di una distinzione meno spettacolare di una faida personale, ma molto più importante per chi si occupa davvero di sicurezza software.

GrapheneOS: la frattura con Copperhead non è solo una vicenda societaria

Secondo la ricostruzione condivisa da GrapheneOS, il progetto tecnico precedeva la società e non il contrario. È una differenza enorme: quando un progetto nasce in forma open source e una società prova successivamente a costruirci sopra un’attività commerciale, i confini fra sponsor, controllo del codice, marchio, infrastruttura e governance devono essere cristallini. Se non lo sono, il conflitto si manifesta quasi sempre nel punto peggiore: la catena di rilascio.

Qui entrano in scena le signing keys, cioè le chiavi crittografiche usate per firmare gli aggiornamenti del sistema operativo. Chi controlla quelle chiavi controlla, di fatto, chi può distribuire software ritenuto autentico dai dispositivi. È l’elemento che tiene in piedi il modello di fiducia dell’intero sistema di update: GrapheneOS spiega che se una controparte pretende accesso diretto a quelle chiavi per motivi commerciali o contrattuali, il problema non è solo giuridico: è architetturale.

La rottura con Copperhead è descritta come il momento in cui esigenze di monetizzazione, richieste di accesso privilegiato e pressioni sulla direzione del progetto hanno smesso di essere compatibili con un modello open source centrato sulla sicurezza degli utenti. Va detto però che, al di là dei toni molto duri usati contro James Donaldson, CEO di Copperhead, la parte più rilevante dell’intera vicenda è il fatto che un progetto di sicurezza mobile di primo piano possa essere trascinato in una crisi esistenziale quando business e root of trust finiscono nello stesso scontro.

La storia tecnica ufficiale racconta un progetto nato prima del brand GrapheneOS

Il progetto, fondato alla fine del 2014, nasce come iniziativa individuale per rafforzare la sicurezza di Android (hardening, cioè l’insieme di tecniche per ridurre le vulnerabilità del sistema): include l’adattamento (porting) del sistema di gestione della memoria malloc di OpenBSD all’interno della libreria di sistema Bionic libc, l’integrazione di modifiche di sicurezza derivate dal progetto PaX (noto per le sue protezioni contro exploit) e ulteriori interventi mirati al miglioramento dell’isolamento delle applicazioni (sandboxing), degli strumenti di compilazione (compiler toolchain) e delle difese a basso livello del sistema operativo.

Non si tratta, quindi, di una ROM Android qualunque rifinita con qualche impostazione privacy: fin dalle origini l’idea era intervenire su meccanismi interni del sistema operativo per rendere più costoso lo sfruttamento di intere classi di vulnerabilità.

GrapheneOS si distingue da molte distribuzioni Android alternative che lavorano soprattutto su interfaccia, scelta delle app di sistema o “degoogleizzazione“.

Il baricentro del lavoro svolto su GrapheneOS è spostato sulla riduzione della superficie d’attacco, sullo sviluppo di mitigazioni contro la corruzione della memoria, controlli più granulari sui permessi e rafforzamento dei confini tra processi e profili utente.

Quando il sito ufficiale spiega che varie modifiche storiche sono state abbracciate da Google in AOSP (Android Open Source Project) o hanno influenzato cambiamenti a monte, sta dicendo una cosa precisa: parte del valore tecnico del progetto non è confinata al suo ramo locale, ma ha inciso anche sul codice Android più ampio.

Cosa rende GrapheneOS diverso sul piano tecnico

Se si toglie il rumore della disputa personale, resta il motivo per cui GrapheneOS conta davvero: il livello di lavoro svolto sull’architettura difensiva di Android.

Le vulnerabilità più comuni rinvenute nei componenti software scritti con linguaggi memory-unsafe continuano a ruotare attorno a overflow, use-after-free, type confusion e primitive simili. Alzare il costo di sfruttamento di questi attacchi significa costringere l’aggressore a concatenare più tecniche, ridurre l’affidabilità degli exploit e limitare i casi in cui una singola falla consente di trasformare un bug in esecuzione di codice persistente sul dispositivo mobile.

GrapheneOS aggiunge poi una serie di controlli che, messi insieme, fanno la differenza nell’uso quotidiano. Il Network permission toggle consente di negare l’accesso alla rete a livello di sistema; quando è disattivato, l’app vede la rete come assente. Proprio in un altro articolo abbiamo visto che le app Android di norma possono verificare se l’utente, ad esempio, sta usando una VPN.

Il Sensors permission toggle permette di azzerare l’accesso a sensori come accelerometro, giroscopio e bussola. Con Storage Scopes e Contact Scopes l’utente può offrire a un’app una vista limitata di file e contatti, evitando il classico aut-aut fra accesso totale e diniego completo.

Una parte molto interessante riguarda anche il contenimento dell’esecuzione dinamica di codice. La documentazione di GrapheneOS descrive blocchi o restrizioni su JIT e dynamic code loading in ampie porzioni del sistema, con toggle specifici per le app utente.

È un’area tecnica poco visibile al pubblico, ma fondamentale: molte catene di exploit moderne traggono vantaggio proprio da componenti che generano, caricano o trasformano codice in memoria. Ridurre questi spazi significa togliere appigli utili all’attaccante pur tollerando qualche compromesso di compatibilità.

Sandboxed Google Play: il compromesso meglio riuscito del progetto

Una delle caratteristiche distintive di GrapheneOS è il Sandboxed Google Play, affiancato dal layer di compatibilità GmsCompat.

Su GrapheneOS, i componenti ufficiali di Google Play non ricevono privilegi speciali di sistema e girano come normali app nella sandbox standard di Android. In altri ambienti Android, i Play Services agiscono come componente dotato di privilegi molto ampi.

L’utente può installare Google Play solo in un determinato profilo, limitare i permessi app per app e tenere i servizi Google fuori dal ruolo di backend implicito del sistema. La compatibilità, secondo la documentazione ufficiale, resta vicina a quella completa per la gran parte delle app dipendenti da Google Play. Questo è il punto che spesso sfugge a chi guarda GrapheneOS solo come un prodotto per “puristi”: il progetto non prova a vincere cancellando il software dominante, prova a neutralizzarne i privilegi superflui.

Una fondazione non profit cambia la governance, non cancella i limiti

La costituzione della GrapheneOS Foundation in Canada nel marzo 2023 merita attenzione perché segnala un cambio di maturità organizzativa. La fondazione, secondo le informazioni pubbliche del progetto e del registro federale canadese, serve a gestire donazioni e a offrire uno schermo legale per il lavoro degli sviluppatori. È una risposta abbastanza tipica per progetti open source che crescono oltre la fase “artigianale” e si espongono a pressioni legali, reputazionali e operative.

Il team di GrapheneOS, nel suo accorato intervento, rivendica una crescita sostanziale del numero di sviluppatori retribuiti grazie alle donazioni e sottolinea che nessuno si sta arricchendo tramite la fondazione.

Resta però un limite concreto: i progetti di sicurezza più seri hanno bisogno di fondi stabili, processi interni solidi e comunicazione pubblica disciplinata.

Sul piano tecnico GrapheneOS ha accumulato credibilità reale; sul piano relazionale continua invece a convivere con un’eredità fatta di accuse, smentite e battaglie pubbliche. Per un sistema operativo orientato alla sicurezza è un costo reputazionale non banale, perché gli utenti devono fidarsi non solo del codice, ma anche della qualità dei processi e della lucidità di chi lo mantiene.

La contestazione del team di GrapheneOS alla testata USA, al netto delle formulazioni pesanti, mette il dito su una questione vera: raccontare un progetto di sicurezza come storia di caratteri forti, ossessioni personali e rotture drammatiche è giornalisticamente seducente; spiegare signing keys, licenze, compatibilità con AOSP, upstreaming e  tecniche di hardening è molto meno semplice. Eppure è lì che si trova la sostanza: secondo GrapheneOS, infatti, un errore nelle ricostruzioni biografiche può distorcere la percezione pubblica; un errore sulla catena di fiducia di un sistema operativo può mettere a rischio gli utenti.