Wallet di identità digitale UE: perché possono favorire Google e Apple

Il portafoglio europeo di identità digitale o EUDI Wallet (European Digital Identity Wallet) nasce con una promessa ambiziosa: permettere ai cittadini di accedere ai servizi pubblici e privati, dimostrare attributi personali e firmare documenti senza consegnare più dati del necessario.

L’Unione europea lavora sull’identificazione elettronica almeno dal regolamento eIDAS del 2014; la svolta arriva però con il regolamento UE 2024/1183, che introduce il quadro europeo per l’identità digitale e impone agli Stati membri di rendere disponibili i wallet entro la fine del 2026, secondo le regole attuative adottate dalla Commissione.

Circa 450 milioni di cittadini europei dovrebbero poter usare credenziali digitali riconosciute oltre confine, con una base tecnica comune e un livello di sicurezza elevato.

Waag Futurelab, fondazione e centro di ricerca pubblico con sede ad Amsterdam (si occupa del rapporto tra tecnologia e società, con un taglio molto orientato a diritti digitali, valori pubblici, progettazione aperta, inclusione, ricerca civica e critica del potere delle grandi piattaforme), osserva però che un pilastro dell’EUDI Wallet rischierebbe di poggiare proprio sui soggetti dai quali l’Europa vorrebbe ridurre la dipendenza: Google ed Apple.

Perché l’attestazione remota è diventata il tema più delicato

L’analisi pubblicata da Waag richiama l’attenzione su un aspetto molto concreto, spesso invisibile all’utente finale: alcune implementazioni nazionali di EUDI Wallet usano servizi di attestazione remota forniti dalle piattaforme mobili dominanti.

Su Android il riferimento è Google Play Integrity API; su iOS entrano in gioco meccanismi Apple come Managed Device Attestation e App Attest. Prima ancora di discutere di identità, attributi, firme o privacy, il sistema deve decidere se il dispositivo e l’app meritano fiducia. E quella decisione può passare da infrastrutture private.

L’attestazione remota serve a rispondere alla seguente domanda: l’app che sta chiedendo accesso a un servizio critico gira davvero su un dispositivo integro, con codice non alterato e con chiavi protette da hardware sicuro?

Per un wallet di identità digitale è un quesito cruciale: un’app compromessa potrebbe esporre credenziali, intercettare attributi personali, manipolare una richiesta di firma o tentare di clonare una sessione.

Google Play Integrity API nasce proprio per fornire segnali di integrità: l’API aiuta gli sviluppatori a verificare che le richieste arrivino da un binario dell’app non modificato, installato tramite Google Play e in esecuzione su un dispositivo Android considerato genuino. Tecnicamente il flusso tipico prevede che l’app richieda un token di integrità, lo invii al proprio backend e che il server valuti gli indicatori restituiti.

Il concetto di “dispositivo affidabile” coincide però, di fatto, con un Android certificato da Google e integrato con Google Play Services. Un telefono con bootloader sbloccato, una ROM personalizzata o un sistema operativo Android senza componenti Google può risultare sospetto anche quando usa hardware recente, patch aggiornate e un modello di sicurezza rigoroso. Il sistema operativo derivato da Android che punta tutto su privacy e sicurezza, GrapheneOS, ha accusato l’attestazione hardware sostenendo che favorisce i monopoli.

Il caso dei sistemi Android de-Googled

Anche Waag cita esplicitamente sistemi come e/OS e GrapheneOS, due esempi diversi ma accomunati da un obiettivo: ridurre o eliminare la dipendenza da Google nei dispositivi Android.

Come spiegato nella guida su GrapheneOS, questo sistema operativo punta molto su hardening, isolamento delle app, permessi più severi e uso rigoroso delle funzioni di sicurezza dei Pixel. Non si tratta quindi, almeno non necessariamente, di ambienti “meno sicuri”. Spesso è vero il contrario: il dispositivo può avere verified boot, sandboxing robusto e aggiornamenti rapidi senza essere certificato da Google.

Se però un wallet nazionale richiede Play Integrity in modo rigido, il risultato pratico può essere l’esclusione con la conseguente impossibilità di usare l’app per identificarsi online.

Dal punto di vista di una Pubblica Amministrazione usare API già pronte riduce tempi di sviluppo, costi di verifica e responsabilità operative. Ma una soluzione comoda non è sempre una buona soluzione, soprattutto quando diventa prerequisito per accedere a documenti, servizi sanitari, pagamenti, firme qualificate o procedure amministrative.

Il paragone fatto da diversi critici è efficace: sarebbe come se lo Stato rilasciasse una carta d’identità fisica solo a chi usa un portafoglio approvato da due aziende private. Nel mondo digitale la distinzione sembra meno evidente, perché sicurezza, distribuzione software e identità finiscono nello stesso telefono. Ma il principio resta identico.

Il ruolo dell’Architecture Reference Framework: dito puntato sull’Italia

L’Architecture Reference Framework (ARF) del wallet EUDI descrive il ciclo di vita dell’unità wallet, l’installazione dell’app, l’attivazione, il rilascio degli attestati e i rapporti di fiducia tra provider, utenti e soggetti terzi. Nel documento si legge che il wallet dovrebbe arrivare preferibilmente tramite lo store ufficiale del sistema operativo, così sistema operativo e store possono verificare l’autenticità dell’app e ridurre il rischio di installazioni malevole. Il testo ammette anche canali alternativi, a patto che il provider offra meccanismi chiari per verificare l’autenticità, ad esempio tramite confronto dell’hash dell’applicazione scaricata.

ARF non impone esplicitamente l’uso di Google Play Integrity e delle altre soluzioni lato iOS, ma alcune interpretazioni nazionali e alcuni progetti tecnici hanno trattato l’integrazione con Google e Apple come scelta quasi naturale, quando non di fatto obbligata.

Waag segnala Italia e Paesi Bassi come esempi in cui Play Integrity risulta implementato in modo particolarmente vincolante.

Altri Paesi, invece, hanno discusso o scelto approcci più prudenti. La Svizzera, pur non essendo Stato membro dell’UE, è citata come un caso interessante perché ha valutato alternative meno dipendenti da Google per ragioni di protezione dei dati, sovranità e libertà di scelta.

Perché il tema tocca anche il Digital Markets Act

L’Unione europea ha approvato il Digital Markets Act (DMA) proprio per ridurre il potere dei gatekeeper e limitare pratiche che chiudono mercati, utenti e sviluppatori dentro piattaforme dominanti. Per questo l’uso di servizi di attestazione proprietari nei wallet pubblici solleva parecchi dubbi.

Da un lato Bruxelles chiede interoperabilità, apertura e minore dipendenza dai grandi intermediari digitali. Dall’altro, alcuni progetti di identità pubblica rischiano di rafforzare gli stessi intermediari, consegnando loro un ruolo tecnico nel decidere quali dispositivi possano accedere a servizi essenziali.

Per Android, l’uso diretto dell’attestazione hardware può permettere controlli più mirati. Il server potrebbe verificare boot state, proprietà della chiave, patch level (stato degli aggiornamenti di sicurezza installati sul dispositivo), vincoli di uso, presenza di hardware sicuro e certificati del produttore; poi potrebbe applicare una policy pubblica, distinguendo tra rischio reale e semplice assenza dei Google Play Services. Sullo sfondo c’è anche l’iniziativa per un’alternativa europea open source.

La Pubblica Amministrazione dovrebbe inoltre spiegare quali segnali di integrità raccoglie, chi li verifica, per quanto tempo li conservano, quali fornitori intervengono e quali categorie di utenti possono restare escluse. Senza questa trasparenza, il concetto di sicurezza e la fiducia degli utenti possono risultarne annacquati.