IO, IT-Wallet e Play Integrity: il caso GrapheneOS riapre il tema della dipendenza da Google

Un dispositivo Android può avere il bootloader bloccato, Verified Boot attivo, chiavi custodite nell’hardware e aggiornamenti di sicurezza recentissimi, ma non essere comunque considerato idoneo ad alcune funzioni di IO e IT-Wallet. Il caso più evidente riguarda GrapheneOS, sistema operativo incentrato sulla sicurezza e sulla privacy che da tempo alimenta una discussione tecnica nel repository pubblico dell’app IO.

IO è l’app pubblica che raccoglie in un unico punto servizi, comunicazioni, pagamenti e documenti digitali della Pubblica Amministrazione italiana. La sua gestione e il suo sviluppo fanno capo a PagoPA, società pubblica che gestisce anche la piattaforma pagoPA per i pagamenti verso la PA.

Dentro IO sta inoltre prendendo forma IT-Wallet, il sistema italiano di portafoglio digitale: una prima parte è già operativa con “Documenti su IO“, mentre il progetto completo continua a evolversi verso un’infrastruttura più ampia e interoperabile anche con il futuro European Digital Identity Wallet.

Accesso agli atti negato: il caso IT-Wallet entra in una nuova fase

La vicenda cui abbiamo fatto menzione in apertura ha però assunto una dimensione nuova.

Il 20 agosto 2026 alcuni utenti hanno presentato a PagoPA una nuova istanza di accesso civico generalizzato, chiedendo documenti relativi alle soluzioni di integrità valutate per IT-Wallet, due ticket interni richiamati nel codice pubblico e gli eventuali dati sulle attivazioni respinte o sulle disattivazioni automatiche del wallet.

Stando all’aggiornamento pubblicato da Marco Lodini su GitHub, PagoPA avrebbe risposto il 24 settembre 2026, negando l’accesso ai primi due gruppi di documenti per la tutela degli “interessi economici e commerciali” e dichiarando di non detenere i dati richiesti rispetto al terzo punto.

Gli autori dell’istanza hanno quindi chiesto il riesame al Responsabile della prevenzione della corruzione e della trasparenza (RPCT) di PagoPA.

La controversia documentale si intreccia con una questione tecnica molto più ampia: che cosa significa, esattamente, stabilire che uno smartphone è sufficientemente affidabile per custodire e utilizzare documenti digitali pubblici?

La “pietra dello scandalo”: Play Integrity

La versione Android di IO utilizza Google Play Integrity API come uno degli strumenti per valutare l’ambiente nel quale vengono eseguite determinate funzioni.

Google descrive ufficialmente Play Integrity come un servizio che permette di verificare che azioni e richieste provengano dall’app autentica, installata tramite Google Play e in esecuzione su un dispositivo Android “genuino e certificato“. L’API restituisce differenti verdetti: appIntegrity riguarda l’autenticità dell’applicazione; deviceIntegrity fornisce informazioni sull’affidabilità dell’ambiente di esecuzione.

Avevamo già spiegato in un altro approfondimento perché con Play Integrity alcune app Android non si avviano più.

Il servizio applica il modello di fiducia stabilito da Google, combinando diversi segnali hardware e software e traducendoli in giudizi facilmente utilizzabili dal backend dell’applicazione.

Google precisa che, per ottenere una “valutazione” PLAY_RECOGNIZED, il certificato di firma dell’app deve essere riconosciuto da Google Play; il verdetto LICENSED permette inoltre di verificare che l’app sia stata installata o aggiornata tramite Google Play. Per i livelli relativi al dispositivo entrano poi in gioco segnali hardware-backed e altri requisiti stabiliti dal servizio.

GrapheneOS: sicuro non significa necessariamente certificato da Google

La issue #7199 del repository di IO nasce il 18 luglio 2025 con una richiesta esplicita: evitare la dipendenza esclusiva da Play Integrity e valutare invece soluzioni di hardware attestation disponibili sulla piattaforma Android.

L’autore segnala che l’attuale meccanismo impedisce infatti a GrapheneOS di utilizzare alcune funzioni di IO, compresa l’aggiunta della patente digitale, nonostante il sistema operativo mantenga meccanismi come Verified Boot e possa funzionare con bootloader bloccato. Propone quindi di verificare direttamente l’attestazione hardware e inserire fra le chiavi riconosciute anche quelle dei sistemi operativi alternativi considerati affidabili.

La discussione si è poi allargata ad altri dispositivi privi dei Google Mobile Services (GMS). È il caso di alcuni smartphone Huawei con firmware ufficiale: il sistema non è modificato, ma senza i servizi Google non può soddisfare i controlli richiesti da Play Integrity. Il problema, quindi, non riguarda soltanto GrapheneOS, tanto che nella medesima discussione sono citati produttori europei che distribuiscono Android senza GMS.

Play Integrity, comunque, non è solo un controllo commerciale sulla presenza di Google Play.

Google dichiara esplicitamente di utilizzare segnali di sicurezza sostenuti dall’hardware e il livello MEETS_STRONG_INTEGRITY, sui dispositivi Android 13 e successivi, che include anche il requisito di aggiornamenti di sicurezza recenti. Play Integrity offre inoltre segnali antifrode, controlli sull’applicazione, mitigazioni contro attacchi replay (misure che impediscono di riutilizzare una risposta valida già intercettata per superare nuovamente il controllo) e altri strumenti che un’implementazione autonoma dovrebbe ricostruire o sostituire.

L’alternativa: verificare direttamente le chiavi nell’hardware

Android dispone di un livello più basso sul quale costruire un sistema di fiducia: Key Attestation. Google lo documenta come il meccanismo attraverso cui un’applicazione può verificare che una coppia di chiavi risieda realmente in un keystore protetto dall’hardware.

Il dispositivo fornisce una catena di certificati X.509; il backend deve controllarne firme, root certificate, eventuali revoche e proprietà contenute nelle estensioni dell’attestazione. L’attestazione può indicare, tra le altre cose, se la chiave è protetta da un Trusted Execution Environment (TEE) oppure da StrongBox.

Google raccomanda espressamente di effettuare la verifica su un server separato e attendibile, non sullo stesso dispositivo che si sta controllando: se Android fosse compromesso, una verifica locale non offrirebbe infatti garanzie sufficienti.

GrapheneOS propone di sfruttare proprio questo meccanismo aggiungendo il controllo della Verified Boot Key. In sostanza, il backend può controllare non solo che la risposta provenga realmente dall’hardware del dispositivo, ma anche quale sistema operativo abbia completato la catena di avvio verificato. La guida del progetto suggerisce così di riconoscere esplicitamente le chiavi delle release GrapheneOS considerate attendibili.

Evitare Play Integrity non significa eliminare Google dall’attestazione

La hardware key attestation di Android, citata in precedenza, non implica automaticamente l’assenza di qualsiasi infrastruttura Google.

La documentazione Android spiega che sui dispositivi con hardware-level key attestation, Android 7 o successivo e Google Play Services, la catena di attestazione utilizza una root di attestazione Google. Per verificare il risultato bisogna inoltre controllare l’elenco delle chiavi revocate.

Quindi l’alternativa non va presentata come una magica trasformazione da “Google” a “zero Google”. La differenza fondamentale riguarda piuttosto il livello al quale si prende la decisione. Play Integrity consegna al backend un giudizio già elaborato secondo le regole del servizio Google; con Key Attestation il gestore può analizzare direttamente le proprietà crittograficamente attestate e definire una policy propria.

Caso IO/IT-Wallet: “diverse soluzioni” oppure una valutazione make-or-buy?

Lodini evidenzia una differenza fra le due risposte di PagoPA. Nel 2025 l’ente avrebbe dichiarato di aver confrontato “diverse soluzioni” per i controlli di integrità, formulazione che lascia pensare alla valutazione di tecnologie alternative.

Nella risposta del 2026, invece, PagoPA avrebbe parlato soltanto di una scelta make-or-buy: decidere se sviluppare internamente o acquistare il componente React Native necessario a implementare i controlli.

Sono quindi due valutazioni diverse: quale tecnologia usare nel primo caso, come procurarsi il componente software nel secondo.

Non disponiamo dei documenti sulla vicenda ma è proprio su questo punto che gli autori dell’istanza chiedono maggiore chiarezza.

Sempre secondo Lodini, nella risposta di PagoPA i controlli di integrità sarebbero descritti come chiamate ad “API ufficiali del sistema operativo“. L’autore contesta questa formulazione perché Play Integrity dipende dai servizi Google Play e non appartiene alle API di base di AOSP (Android Open Source Project).

Play Integrity compare nella documentazione Android per gli sviluppatori, ma Google la descrive chiaramente come Google Play Integrity API. Il relativo package è com.google.android.play.core.integrity; il servizio verifica inoltre che l’app sia riconosciuta da Google Play e, in alcuni verdetti, che provenga proprio dal Play Store.

Sulla carte non si tratta di un’API appartenente al nucleo open source di Android. Diverso è il caso delle primitive di Android Keystore e Key Attestation, che fanno parte del modello di sicurezza della piattaforma Android e permettono di interrogare proprietà delle chiavi protette dall’hardware.

Il dato che PagoPA dice di non avere

Il terzo punto dell’istanza merita attenzione per un motivo diverso.

Gli autori avevano chiesto se PagoPA disponesse di dati sul numero di attivazioni di IT-Wallet bloccate dai controlli di integrità e sui casi in cui un wallet già attivo fosse stato successivamente disabilitato in automatico.

Secondo il resoconto pubblicato su GitHub, PagoPA avrebbe dichiarato di non detenere informazioni di questo tipo.

Pochi giorni dopo, un partecipante alla discussione ha richiamato l’informativa dell’Istituto Poligrafico e Zecca dello Stato, nella quale si parla della conservazione per ulteriori 12 mesi delle attestazioni elettroniche relative a documenti revocati o scaduti, chiedendosi se tali informazioni potessero avere qualche relazione con quanto richiesto tramite accesso civico.

Va detto che i dati relativi a un documento revocato o scaduto non coincidono necessariamente con i log relativi a una attivazione respinta a causa di un controllo di integrità.

La domanda resta comunque interessante: quali metriche sono effettivamente raccolte per capire quanti utenti non riescono ad attivare IT-Wallet a causa dei controlli di integrità? Google, curiosamente, raccomanda agli sviluppatori che adottano Play Integrity di raccogliere telemetria prima di applicare restrizioni, proprio per capire quali giudizi restituiscano i dispositivi degli utenti e stimare l’impatto delle policy applicate.

Chi decide cos’è un dispositivo affidabile?

GrapheneOS è soltanto la punte dell’iceberg. Con Play Integrity, parte della risposta è delegata a Google: il servizio interpreta una serie di segnali e restituisce una classificazione.

Con l’hardware attestation diretta il gestore del wallet dovrebbe invece costruire e mantenere una propria policy: quali Verified Boot Key accettare, quale livello minimo di patch richiedere, quali modelli supportare, come gestire revoche, vulnerabilità hardware e sistemi operativi alternativi.

La seconda soluzione offre maggiore controllo, ma introduce anche responsabilità e complessità che Play Integrity nasconde dietro un’API relativamente semplice.

Google stessa insiste sul fatto che Play Integrity non dovrebbe costituire l’unico meccanismo antifrode. Raccomanda di combinarlo con altri segnali, adottare strategie di enforcement graduali e predisporre perfino un piano per eventuali indisponibilità su larga scala del servizio.

Per un wallet pubblico, quali proprietà deve possedere un dispositivo per essere considerato affidabile, chi deve verificarle e chi deve avere l’ultima parola sulla decisione?

Quando la tecnologia protegge patente, tessera sanitaria e, in prospettiva, altre credenziali digitali pubbliche, capire perché una determinata architettura sia stata preferita alle alternative non è una curiosità da sviluppatori. È una parte essenziale del modo in cui viene progettata l’infrastruttura che stabilisce chi può utilizzare i propri documenti digitali e da quali dispositivi.