GrapheneOS accusa l'attestazione hardware di favorire i monopoli: cosa significa

La verifica dell’integrità dei dispositivi sta diventando una delle tecnologie più delicate per l’accesso ai servizi digitali: non controlla solo se un’app è alterata, ma può decidere quali telefoni, sistemi operativi e browser meritano fiducia. Il nodo tecnico è la cosidetta hardware attestation, cioè la prova crittografica che una richiesta arriva da un dispositivo con determinate proprietà hardware e software. GrapheneOS (qui la guida alla versione di Android ultrasicura) contesta le nuove scelte operate da Google ed Apple.

La storia parte da lontano. Android ha introdotto la key attestation con la versione 7.0 del sistema operativo; l’ID attestation con la 8.0; Apple ha successivamente adottato tecnologie simili come DeviceCheck e App Attest.

La key attestation è un sistema che consente di verificare se le chiavi crittografiche utilizzate da un’app sono autentiche e generate da hardware sicuro del dispositivo; l’ID attestation permette di confermare in modo affidabile l’identità del dispositivo stesso. DeviceCheck e App Attest svolgono funzioni analoghe nell’ecosistema Apple, aiutando a distinguere dispositivi e applicazioni legittimi da quelli modificati o compromessi.

Inizialmente queste tecnologie erano pensate soprattutto per contrastare frodi, bot automatizzati, applicazioni manomesse e furti di credenziali. Oggi però il loro utilizzo si sta ampliando: sono integrate nei pagamenti digitali, nei sistemi di identità elettronica, nei servizi pubblici, nei CAPTCHA e persino nei meccanismi di accesso ai servizi web. Di conseguenza, i controlli di integrità rischiano di trasformarsi da semplici strumenti antifrode a requisiti indispensabili per poter utilizzare un dispositivo e accedere ai servizi online.

Play Integrity e App Attest: cosa verificano davvero

Google presenta la Play Integrity API come uno strumento per verificare che richieste e azioni arrivino da un’app autentica, distribuita tramite Google Play e in esecuzione su un dispositivo Android certificato. Il backend riceve un verdetto firmato e decide come reagire: consentire l’operazione, chiedere ulteriori controlli, limitare alcune funzioni o bloccare l’accesso.

Il dettaglio importante è nei livelli di integrità. Il giudizio MEETS_STRONG_INTEGRITY richiede garanzie più robuste sullo stato del dispositivo, compresa la protezione hardware dell’avvio e della catena di fiducia. Il livello più comune, legato all’integrità del dispositivo in uso, ha requisiti meno severi, ma Google sta spingendo gli sviluppatori verso controlli più resistenti agli abusi.

Apple segue una logica simile con App Attest, integrato nel framework DeviceCheck: l’app genera una coppia di chiavi; Apple attesta che quella chiave nasce da un’app legittima su hardware Apple e il server può poi verificare le firme nelle richieste successive.

Dal punto di vista tecnico è un modello pulito: chiavi non esportabili, attestation object, verifica server-side, meccanismi che impediscono replay attack cioè il riutilizzo fraudolento di richieste già inviate. Il punto è che funziona bene proprio perché il produttore controlla hardware, sistema operativo, store e processo di firma.

Il salto dal mobile al Web: agghiacciante per GrapheneOS

Il passaggio più controverso non riguarda l’uso dell’attestazione dentro un’app bancaria ma riguarda il web. Apple ha portato sul browser i Private Access Tokens, costruiti intorno a Privacy Pass: l’utente può dimostrare di usare un dispositivo considerato legittimo senza rivelare direttamente la propria identità. La Mela ha descritto questo approccio come un metodo per ridurre i CAPTCHA, specialmente su iOS e macOS.

La proprietà nascosta di un impianto del genere è problematica: il sito non valuta più solo il comportamento della sessione, ma riceve una prova indiretta sul tipo di ambiente usato. Se questa prova diventa obbligatoria, chi usa Linux desktop, un sistema BSD, un browser che non è tra quelli più comuni o un telefono Android senza Google Mobile Services può trovarsi escluso anche se “non sta facendo nulla di male”.

Google aveva già esplorato un’idea simile con Web Environment Integrity, una proposta poi abbandonata nel 2023 dopo molte critiche. Il progetto mirava a consentire ai siti di ricevere un token firmato da un attestatore sullo stato del client. Un simile meccanismo avrebbe dato a pochi soggetti il potere di stabilire quali browser e sistemi fossero “accettabili” per accedere al web.

reCAPTCHA Mobile Verification e il problema del QR code

La novità più concreta arriva da reCAPTCHA Mobile Verification: la documentazione Google indica che, per completare certe verifiche, l’utente deve usare un dispositivo mobile compatibile: su Android serve Google Play Services 25.41.30 o superiore; su iOS e iPadOS sono richieste versioni specifiche, con supporto diverso tra scansione QR e pulsante “Clicca per verificare“.

Il desktop mostra un QR code, il telefono lo scansiona e l’utente completa la verifica. Un sito visitato da Windows, Linux desktop, OpenBSD o FreeBSD può finire per richiedere, indirettamente, un iPhone/iPad o un Android certificato da Google.

In pratica, il CAPTCHA smette di chiedere “sei umano?” e inizia a chiedere “hai un dispositivo riconosciuto da Apple o Google?”. La differenza è enorme. Un conto è mitigare botnet, automazione aggressiva e credential stuffing; un altro è subordinare l’accesso al web alla disponibilità di hardware e servizi proprietari.

Perché GrapheneOS contesta il modello

GrapheneOS sostiene che Play Integrity e sistemi analoghi non misurino la sicurezza reale del dispositivo, ma l’appartenenza a una lista commerciale e tecnica controllata da Apple o Google.

La critica non nasce dal rifiuto dell’attestazione in sé: come abbiamo visto in precedenza, Android, infatti, dispone di una key attestation standard capace di includere informazioni sull’avvio verificato, sul livello di patching, sull’app che genera la chiave e sulla catena di certificati.

Il dato interessante è che l’attestazione Android può supportare sistemi operativi alternativi attraverso chiavi diverse da quelle del produttore originario. Un servizio potrebbe accettare una root of trust alternativa, verificare il fingerprint della chiave, controllare patch level e proprietà dell’app, e decidere con criteri propri. Non deve per forza usare un verdetto Play Integrity che dipende dalla certificazione Google Mobile Services.

GrapheneOS evidenzia proprio questa contraddizione: un sistema operativo hardened, con sandboxing più severo, permessi ridotti e patch tempestive, può fallire i controlli Play Integrity perché non rientra nel modello Google Mobile Services; al contrario, un dispositivo Android certificato ma vecchio e non aggiornato può risultare più facilmente accettato in alcuni scenari. La sicurezza non coincide con la certificazione commerciale.

Il ruolo di banche, pubblica amministrazione e identità digitale

Le prime ad adottare con forza questi controlli sono spesso banche, wallet, app governative e servizi legati all’identità. La motivazione è comprensibile: frodi finanziarie, SIM swapping, malware bancari, overlay attack e furti di sessione hanno costi reali. Un’app può usare App Attest o Play Integrity per ridurre il rischio che un token di pagamento parta da un ambiente compromesso.

Il problema nasce quando il requisito diventa assoluto: se un cittadino può accedere a un servizio pubblico solo con un dispositivo Apple o con un Android certificato da Google, la scelta tecnica diventa una condizione di accesso ai diritti digitali. Nel caso europeo la discussione è ancora più sensibile, perché il wallet EUDI, la verifica dell’età e i sistemi di identità digitale puntano a garantire interoperabilità, privacy e accesso non discriminatorio.

Alcuni fornitori del settore sostengono che le implementazioni europee non debbano dipendere in modo rigido da Apple e Google. È una posizione ragionevole: un sistema pubblico dovrebbe poter verificare l’integrità dell’app e del dispositivo senza trasformare due piattaforme private in arbitri obbligati dell’accesso.

Le istituzioni dovrebbero pretendere requisiti verificabili e neutrali: patch level, isolamento delle chiavi, integrità dell’app, protezione contro debugging e manomissione. Non dovrebbero invece imporre, direttamente o indirettamente, una dipendenza esclusiva da Google Mobile Services o da hardware Apple. Esistono modelli più aperti, basati su root of trust multiple e policy trasparenti.