Google Wallet KO su migliaia di Pixel: Tap-to-Pay bloccato da Play Protect

La vicenda emersa nelle community Pixel nelle ultime settimane e amplificata poi da Reddit, rappresenta un caso esemplare di intersezione tra sicurezza, gestione del ciclo di vita dei dispositivi e responsabilità dei vendor. Migliaia di utenti con dispositivi perfettamente funzionanti — Pixel 4, 4 XL, 4a, 5 e parte dei 5a — si sono ritrovati improvvisamente con Google Wallet inutilizzabile in modalità contactless, accompagnato dal messaggio: “Device doesn’t meet security requirements” (in italiano “Il dispositivo non soddisfa i requisiti di sicurezza“). In altre parole, il meccanismo Tap-to-Pay non è più operativo.

Dietro a questa anomalia si nasconde un problema molto più complesso di una semplice incompatibilità software: si tratta di un fallimento nel sistema di attestazione di integrità gestito da Google Play Protect e dai meccanismi SafetyNet / Play Integrity API, con implicazioni dirette sulla fiducia crittografica del dispositivo mobile.

Cos’è il Tap-to-Pay

In termini tecnici, Tap-to-Pay è un sistema di pagamento NFC (Near Field Communication) che utilizza un portafoglio digitale (come Google Wallet o Apple Wallet) per emulare una carta di pagamento.

Quando si registra una carta sul telefono, i dati reali non sono salvati in chiaro nel dispositivo. Viene invece creato un token digitale — una versione cifrata e temporanea della carta — che può essere utilizzato per le transazioni.

Il Tap-to-Pay integra più livelli di sicurezza:

• Tokenizzazione: i dati reali della carta non sono mai trasmessi.
• Crittografia hardware: le chiavi sono protette in un ambiente sicuro (TEE o Secure Element).
• Autenticazione utente: impronta, PIN o volto.
• Verifica dell’integrità del dispositivo: impedisce l’uso su sistemi modificati o compromessi.

Il nocciolo del problema: l’attestazione di integrità

I pagamenti contactless su Android si basano su un modello di sicurezza a più livelli. Il dispositivo deve dimostrare di essere integro (bootloader non modificato, sistema non alterato), certificato dal produttore, conforme ai requisiti di sicurezza aggiornati.

Nel caso dei Pixel coinvolti, l’errore non è legato all’hardware (il modulo NFC continua a funzionare) né a modifiche dell’utente (dispositivi stock e bootloader bloccato), ma a un fallimento lato server nella validazione dell’integrità.

Bug o declassamento di sicurezza sui vecchi Pixel?

Dalle testimonianze emerge una contraddizione significativa. Da un lato, il supporto Google avrebbe parlato esplicitamente di un “bug” lato backend che colpisce circa 17.000 dispositivi. Dall’altro, i moderatori della community e alcuni esperti parlano di “revoca della fiducia crittografica” dovuta a requisiti di sicurezza aggiornati.

Questa ambiguità è centrale. Dal punto di vista tecnico, le due ipotesi conducono infatti a scenari molto diversi.

Nel primo caso, si tratta di un errore nei sistemi di certificazione, ad esempio una regressione nel processo di attestazione, un mismatch di chiavi o una whitelist errata.

Nel secondo caso, invece, l’azienda di Mountain View avrebbe deliberatamente aggiornato i requisiti di sicurezza, rendendo non più idonei dispositivi fuori supporto (end-of-life). In questo scenario, i telefoni continuano a funzionare ma non sono più considerati “trusted devices” per operazioni sensibili.

Il nodo crittografico: perché “non si può risolvere”

Uno dei punti più controversi è l’affermazione secondo cui il problema sarebbe “tecnicamente irrisolvibile”.

Se la causa fosse una perdita o revoca delle chiavi crittografiche legate all’hardware (TEE o Titan M nei Pixel più recenti), il dispositivo non potrebbe più dimostrare la propria identità in modo affidabile. In un sistema progettato per prevenire frodi finanziarie, reintrodurre manualmente la fiducia su dispositivi compromessi sarebbe estremamente rischioso.

Tuttavia, i modelli Pixel 4 e 5 non adottano lo stesso meccanismo di protezione dei dispositivi più recenti, che integrano il chip di sicurezza Titan M2 (un modulo hardware dedicato alla protezione dei dati e all’avvio sicuro) insieme componenti fisici che permettono di bloccare in modo permanente alcune operazioni. Per questo è ragionevole pensare che il problema dipenda più da una scelta a livello di software o di policy di sicurezza, piuttosto che da un limite tecnico davvero irreversibile dell’hardware.

Il tema della responsabilità: fine supporto o regressione indotta?

Il punto più delicato non è tecnico ma contrattuale e reputazionale. Un dispositivo fuori supporto:

• non riceve aggiornamenti di sicurezza;
• può diventare incompatibile con nuove API;
• ma non dovrebbe perdere funzionalità pubblicizzate durante il suo ciclo di vita.

Se il malfunzionamento deriva da un aggiornamento lato server introdotto dopo la fine del supporto ufficiale, si entra in una zona grigia: l’utente non riceve patch, ma subisce comunque cambiamenti infrastrutturali che degradano il dispositivo.

Dal punto di vista della sicurezza informatica, è comprensibile che un provider limiti l’uso di pagamenti su dispositivi non più aggiornati. Dal punto di vista dell’utente, però, si tratta di una perdita di una funzionalità chiave non causata da un suo comportamento.

Il problema della compensazione e della comunicazione

La gestione del caso solleva criticità evidenti:

• comunicazioni inizialmente errate (negazione della presenza dell’NFC), almeno stando a quanto riportato;
• ammissioni parziali e contraddittorie;
• compensazioni incoerenti (25 dollari) a fronte di un nuovo acquisto sullo store.

Questo tipo di approccio danneggia la fiducia, soprattutto considerando che il problema riguarda un meccanismo di sicurezza finanziaria, ambito in cui la trasparenza è assolutamente fondamentali.