Il modo in cui viene verificata l’integrità di un dispositivo sta cambiando radicalmente, e non tutti sono d’accordo sulla direzione presa. GrapheneOS, il sistema operativo Android orientato alla sicurezza e alla privacy, ha sollevato critiche piuttosto nette nei confronti delle scelte di Google e Apple in materia di attestazione hardware. Il punto è semplice da capire, anche se tecnicamente denso: i meccanismi che dovrebbero proteggerci dalle frodi rischiano di trasformarsi in strumenti che decidono chi può accedere ai servizi online e chi no, sulla base del dispositivo posseduto.
La questione ruota attorno a tecnologie come Play Integrity API di Google e App Attest di Apple. Pensate inizialmente per contrastare bot, app manomesse e furti di credenziali, oggi queste tecnologie si stanno espandendo ben oltre il loro scopo originario. Vengono integrate nei pagamenti digitali, nei sistemi di identità elettronica, nei servizi pubblici e persino nei CAPTCHA. Android ha introdotto la key attestation già con la versione 7.0, poi l’ID attestation con la 8.0. Apple ha seguito con DeviceCheck e App Attest. Fin qui, tutto comprensibile. Il problema sorge quando questi controlli smettono di essere facoltativi e diventano requisiti indispensabili per usare un servizio.
Google, con Play Integrity, verifica che le richieste arrivino da un’app autentica, distribuita tramite Google Play e in esecuzione su un dispositivo Android certificato. Apple fa qualcosa di analogo con App Attest, dove l’app genera una coppia di chiavi e Apple attesta che provengono da hardware legittimo. Entrambi i modelli funzionano bene dal punto di vista tecnico, con chiavi non esportabili e meccanismi che impediscono il riutilizzo fraudolento delle richieste. Ma funzionano bene anche perché il produttore controlla tutto: hardware, sistema operativo, store e processo di firma.
Dal mobile al web: quando il CAPTCHA chiede che telefono hai
Il passaggio più controverso riguarda il web. Apple ha portato sul browser i Private Access Tokens, costruiti intorno a Privacy Pass, descrivendoli come un metodo per ridurre i CAPTCHA su iOS e macOS. L’utente può dimostrare di usare un dispositivo considerato legittimo senza rivelare direttamente la propria identità. Sulla carta sembra un progresso. Nella pratica, però, il sito che riceve questa prova finisce per valutare non solo il comportamento della sessione, ma anche il tipo di ambiente utilizzato. Se questa verifica diventa obbligatoria, chi usa Linux desktop, un sistema BSD o un browser meno diffuso rischia di trovarsi tagliato fuori senza aver fatto nulla di sbagliato.
Google aveva già esplorato una strada simile con Web Environment Integrity, proposta poi abbandonata nel 2023 dopo pesanti critiche. E adesso arriva reCAPTCHA Mobile Verification, forse la novità più concreta. La documentazione Google indica che per completare certe verifiche serve un dispositivo mobile compatibile: su Android è richiesto Google Play Services 25.41.30 o superiore, su iOS e iPadOS servono versioni specifiche. Il desktop mostra un QR code, il telefono lo scansiona e la verifica si completa. Tradotto: un sito visitato da Windows, Linux o FreeBSD può finire per richiedere indirettamente un iPhone o un Android certificato da Google. Il CAPTCHA smette di chiedere “sei umano?” e inizia a chiedere “hai un dispositivo riconosciuto da Apple o Google?”. La differenza è enorme.
GrapheneOS e la contraddizione della sicurezza certificata
GrapheneOS non contesta l’attestazione in sé. Android dispone di una key attestation standard capace di includere informazioni sull’avvio verificato, sul livello di patching e sulla catena di certificati. Un servizio potrebbe accettare una root of trust alternativa, verificare il fingerprint della chiave, controllare il patch level e decidere con criteri propri, senza dipendere per forza da un verdetto Play Integrity legato alla certificazione Google Mobile Services.
Ed è proprio qui che GrapheneOS evidenzia la contraddizione più grossa: 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 accettato senza problemi. La sicurezza reale, insomma, non coincide con la certificazione commerciale.
Le prime realtà ad adottare con forza questi controlli sono spesso banche, wallet e app governative. La motivazione è comprensibile: frodi finanziarie, malware bancari, overlay attack e furti di sessione hanno costi reali. Ma quando il requisito diventa assoluto, la questione cambia natura. Se un cittadino può accedere a un servizio pubblico solo con un dispositivo Apple o con un Android certificato da Google, la scelta tecnica si trasforma in una condizione di accesso ai diritti digitali. Nel contesto 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: un sistema pubblico dovrebbe poter verificare l’integrità dell’app e del dispositivo senza trasformare due piattaforme private in arbitri obbligati dell’accesso. Esistono modelli più aperti, basati su root of trust multiple e policy trasparenti, con requisiti verificabili e neutrali come patch level, isolamento delle chiavi, integrità dell’app e protezione contro manomissioni.
