Mi hai preceduto di poche ore, stavo per aprire la stessa issue. Pare che il Wallet di IO utilizzi Play Integrity API per validare la sicurezza del dispositivo:

https://github.com/pagopa/io-react-native-wallet/blob/master/src/wallet-instance/README.md
https://github.com/pagopa/io-react-native-integrity/blob/main/README.md

GrapheneOS non può passare l'attestazione anche se con bootloader bloccato e senza root in quanto non allowlisted da Google sebbene sia significativamente più sicuro dell'OS stock dei Pixel e praticamente di ogni altro telefono Android.

Difatti l'app non valida realmente la sicurezza ma solo che il dispositivo passi l'attestazione hardware di Play Integrity, tuttavia questa la può passare un dispositivo Android con mesi addietro di patch di sicurezza (ad esempio privilege escalation and remote code execution regolarmente corrette nei bollettini di sicurezza). Non mi pare Play Integrity o IO facciano questa valutazione.

IO dovrebbe lasciar passare GrapheneOS implementando attestazione hardware con cui è pienamente compatibile, non c'è motivo per rifiutarlo sulla base di un giudizio fuorviante di Play Integrity:

https://grapheneos.org/articles/attestation-compatibility-guide

Corretto, il motivo mi torna, è la stessa validazione hw usata per i tanto agognati pagamenti tramite nfc che su GOS non funzionano. L'attestazione dovrebbe avvenire in altro modo e non in subordine a metodi di un fornitore privato come google.

L'attestazione dovrebbe avvenire in altro modo e non in subordine a metodi di un fornitore privato come google.

Dovrebbe avvenire tramite attestazione standard di Android, possibilmente verificando anche il patch level in modo che non sia un security theater con il solo scopo reale di vietare sistemi operativi alternativi. Immagino alla luce del Digital Markets Act, l'UE non apprezzerebbe l'impiego di Play Integrity API.

è la stessa validazione hw usata per i tanto agognati pagamenti tramite nfc

@0pipe0

Sembrerebbe ancora più forte. Google Wallet funziona se l'esito di Play Integrity include Basic + Device integrity.

Io sono nella situazione per cui ho Basic + Device (ma non Strong integrity), oltre al bootloader che risulta bloccato da Key Attestation Demo.

Tuttavia, IT-Wallet non funziona, dando codice di errore KEY_IS_NOT_HARDWARE_BACKED.
Suppongo richieda anche la Strong integrity, ossia ponga requisiti ancora più elevati di Google Wallet per fare pagamenti NFC

Google Wallet funziona se l'esito di Play Integrity include Basic + Device integrity.

Google Pay occasionalmente oscilla tra MEETS_BASIC_INTEGRITY e MEETS_STRONG_INTEGRITY, probabilmente perché molti dispositivi hanno implementazioni fallate della seconda, il che la dice lunga sulla validità di questi controlli...

Tuttavia, IT-Wallet non funziona, dando codice di errore KEY_IS_NOT_HARDWARE_BACKED.

Sì, IT-Wallet senza dubbio richiede strong integrity, o per lo meno richiede chiave basata su hardware per la quale si basano comunque sul lasciapassare di Google per averne contezza, altrimenti funzionerebbe su GrapheneOS.

IO dovrebbe lasciar passare GrapheneOS

@orazioedoardo IO dovrebbe lasciar passare qualsiasi android, non solo GrapheneOS.
Io per esempio uso LineageOS.
Se proprio gli sviluppatori non vogliono dispositivi con permessi d'amministrazione (root) dovrebbero rilevarlo in altre maniere..

IO dovrebbe lasciar passare qualsiasi android

In base ai README di questo repository e altri di pagoPA è chiaro che si richieda un certo livello di sicurezza dai dispositivi su cui scaricare il digital ID.

Non tutti gli OS di terze parti su Android sono allo stesso livello sotto questo punto di vista, ad esempio LineageOS anche senza root richiede bootloader sbloccato il che facilita accesso fisico alla partizione dati (basta cambiare recovery per fare bruteforce del PIN senza limiti). Inoltre non supporta Verified Boot, il che rende più facile a seguito di un attacco mantenere accesso persistente sul dispositivo dopo il riavvio.

Si potrebbe aprire un'altra issue per discutere e giustificare i requisiti di sicurezza del digital ID in IO (IMHO LineageOS senza root potrebbe essere più che sufficiente considerato che per lo meno rispetto all'OS stock avresti le patch di Android più recenti sebbene non del firmware). È probabile che quanto implementato oggi in IO sia dovuto a una interpretazione di vari requisiti di sicurezza in vista del wallet europeo.

Se proprio gli sviluppatori non vogliono dispositivi con permessi d'amministrazione (root) dovrebbero rilevarlo in altre maniere..

Dovrebbero effettuare una valutazione olistica del dispositivo sulla base dei meriti utilizzando API standard piuttosto che tramite un gatekeeper.

LineageOS anche senza root richiede bootloader sbloccato

Questo dipende dal bootloader e quindi dal modello del cellulare, in alcuni (come il mio) è possibile bloccare il bootloader in seguito all'installazione della ROM. Ma effettivamente sono casi rari. Dispositivi senza GMS o con microg sono invece più comuni.

LineageOS does not preserve the security model. GrapheneOS not only preserves the security mode but substantially improves security. Unlike LineageOS, GrapheneOS supports verified boot and hardware attestation which enables verifying that it's genuine GrapheneOS. See https://grapheneos.org/articles/attestation-compatibility-guide. They should implement this rather than forbidding using GrapheneOS. It will not reduce their device security checks to implement this.

Play integrity è inutile in quanto facilmente bypassabile con PIF + TS.
Basterebbe avvisare l'utente e permettergli di continuare per smettere di frustrare noi modder inutilmente.

Inoltre:
Google a caso sbaglia l'attestazione.
Proprio stamane un amico mi ha contattato perché il suo telefono (ovviamente stock) non passava più l'integrity, completamente senza motivo (dubito sia stato vittima di un 0day).

Un altro problema è che si rende necessario contattare i server di Google. Perché devo chiedere il permesso a Google per avere i MIEI documenti italiani sul telefono?
Vi ricordo che Google è una multinazionale americana, ha anche sede in italia ma non è italiana, i server di play integrity non sono in italia.

Cosa succede se i server di Google vanno giù? Cosa succede se decidono che il telefono di persona importante x non passa più l'integrity?

IO sta creando un grave disservizio agli utenti che desiderano usare sistemi operativi più sicuri senza di fatto ostacolare aggressori che possono spoofare l'attestazione di Play Integrity tramite leaks di chiavi.

È inverosimile che il team di sviluppo non abbia ancora letto questa issue e le altre due/tre dove si evidenzia questo approccio problematico alla sicurezza per cui a voler pensare bene la scelta non dipende da loro.

La situazione non cambierà finché la discussione rimarrà confinata qui. È necessario un approccio concertato che generi più rumore su social network con coinvolgimento di media / siti di tecnologia come avvenne per la questione traccianti e allora forse prenderanno in considerazione.

La FAQ sui documenti in IO a cui si viene indirizzati in caso di errore è fuorviante: https://io.italia.it/documenti-su-io/faq/#n1_12

per Android: dispositivi con Android 8.0 o versioni successive.

Chiedo quanto possa valere l'attestazione di un dispositivo che nel migliore dei casi, ergo OEM benefattore, è indietro di 3 anni e 9 mesi nelle patch di sicurezza, il che si traduce in qualche centinaio di vulnerabilità con elevata severità oltre ovviamente a mancati miglioramenti strutturali alla sicurezza apportati nelle versioni più recenti di Android.

È inoltre necessario che il dispositivo non sia compromesso, ossia non siano state rimosse le restrizioni imposte dal sistema operativo (ad esempio, il jailbreak per iOS o il rooting per Android).

Un dispositivo sottoposto a jailbreak o root non implica sia compromesso. Inoltre sui Google Pixel lo sblocco del bootloader e il successivo blocco con un sistema operativo aftermarket è 100% supportata, non invalida neanche la garanzia, e permette di mantenere l'integrità e la sicurezza del sistema, come avviene con GrapheneOS. Il fatto che la stragrande maggioranza degli OEM azzoppi il telefono quando si cambi OS non rende la dicitura corretta.

Ti ricordiamo infine che eventuali problemi nell’attivazione della funzionalità potrebbero dipendere anche da fattori quali le politiche di sicurezza o restrizioni specifiche imposte da Google o Apple.

Depistaggio, è IO che sceglie di utilizzare Play Integrity per vietare di fatto sistemi di terze parti, non Google.

Quindi..., uno si prende un Pixel per installarci GrapheneOs e poi, per essere più realista del re e primo tra i primi, non appena il sistema da il via si sbatte e si arrovella nel tentativo di installare su quel telefono e su quel sistema operativo, uno di quelli che sarà tra i primi se non il primo strumento di controllo sociale? L'acqua bolle, ma la rana continua a credere che il caldo che sente sia per colpa del cambiamento climatico. Ambo, terno, quaterna, cinquina e tombola...., per il sistema!

Stesso problema vostro, ho installato Lineage 21 sul mio Poco F2 Pro. Solo che anche con STRONG INTEGRITY mi dà che il mio dispositivo non e supportato. Probabilmente guarda se il bootloader e sbloccato

Io giornalismo ha anche una responsabilità sociale. Scaricare dal play store per una persona a caso che passa dalla strada è più sicuro. Io non sono a favore del play store. Se ci fosse un altro store serio con dietro una azienda che ci investe milioni per la sicurezza, ad esempio Microsoft, sarei ben contento.

Ma tutto quello che gira attorno, custom Rom, sideload e simili non potrà mai essere un qualcosa di popolare.

L’avvocato di pagopa pare che abbia scritto chiaramente che mentre l’attestazione hardware garantisce che l’app sia sicura le play integrity api garantiscono anche che sia scaricata dal Play Store.

Mi pare evidente che loro vogliono anche che sia scaricata dal play store.

Anche l'attestazione hardware garantisce che sia stata scaricata dal play store se l'apk scaricato è identico in tutto per tutto a quello che otterresti da altre parti (ed è già stato spiegato più volte)

@robypez GrapheneOS is a production quality operating system. It is not a "custom ROM" which is objectively an inaccurate term and doesn't make sense. Getting apps from the Play Store is not safer than getting them from most other sources. Play Store is filled with malware and is where most Android users obtain malware. Installing apps from random sites is not what anyone is talking about and they can still verify their app with the hardware attestation API regardless of where it's installed from. Checking for installing from the Play Store provides 0 security value over using hardware attestation to verify the signing key matches and the version code is above a minimum they want to enforce. It is in fact more secure than what they are doing.

The claim that GrapheneOS doesn't provide verification of the app is completely false. The fact that this company and the developers would falsely claim this to a regulator is outrageously unethical behavior. Once we're done with shipping our near robust Android 16 port and other short term priority work, we'll get to writing an article about this.

Contrary to what has been falsely claimed in recent articles, the hardware attestation API is not somehow an unsupported API. It's a standard, official Android API with formal support. Play Integrity API strong level is entirely based on using hardware attestation for stronger verification. It uses it in a much weaker way than how it can be used directly. The sole purpose of using the Play Integrity API over the hardware attestation API is enforcing licensing Google Mobile Services. It appears the developers of this app are interested in upholding a Google's monopoly through illegal business practices to the point they're spreading misinformation about GrapheneOS and actively trying to harm it by spreading misinformation.

GrapheneOS Foundation is a non-profit organization in Canada with a formally defined mission of protecting privacy and security on mobile devices. We are legally required to pursue that mission. Google is instead a profit seeking organization with no obligation to provide privacy and security beyond the absolute bare minimum. They pretend highly insecure Android devices with many months or even years of missing patches are safe to use via the Play Integrity API. They knowingly allow devices which have failed to meet the bare minimum security feature and other requirements pass the Play Integrity API. As an example, the Fairphone 4 is known to have a completely insecure implementation of verified boot using publicly available private keys. Despite that, it's allowed to pass the Play Integrity API with the Google Mobile Services stock OS. This is performative security, not real security. Enforcing that to use an app is quite bad. Giving false information to regulators about GrapheneOS is an egregious action which our community will be informed about in the coming weeks. We expect a retraction.

Daniel, I’m not saying you’re wrong.
But picture this scenario: the IO app is altered to capture credentials , obviously it no longer works properly, or it works while talking to some other backend. Or someone makes an app that looks practically identical, just with a few overlays on top. You can’t stop a user from sideloading that version. Your only real line of defense is ensuring people download the app from a trusted place, and for them, rightly or wrongly, that trusted place is the Play Store.

Yes, GrapheneOS, an excellent operating system, is indeed very secure, and yes, hardware attestation is enough to keep that app safe.
However, if we look at the thousands of scam attempts every month, almost all start with someone on the phone persuading a victim to tap a banner and download an app, saying “Go ahead, install it.” Given today’s threats, I think it’s the right message to tell people they’re safer, not safe, just safer, if they install apps from a store. It doesn’t have to be Google’s store, but it should be backed by someone with the money and resources to guarantee security.

APK files remain the biggest vector for scams worldwide…

Your only real line of defense is ensuring people download the app from a trusted place, and for them, rightly or wrongly, that trusted place is the Play Store.

This is completely untrue. The hardware attestation API fully supports cryptographic verification of the app. Verifying that the signing key fingerprint matches and the version code is equal or greater than a required minimum is strictly better than checking where it was installed from. There's no benefit to checking where it was installed from if you're checking the signing key fingerprint and version. It's irrelevant where someone obtained it. Enforcing apps being installed from the Play Store is a clear violation of the EU Digital Markets Act and so are many other parts of the Play Integrity API. It has zero security value and is clearly illegal.

However, if we look at the thousands of scam attempts every month, almost all start with someone on the phone persuading a victim to tap a banner and download an app, saying “Go ahead, install it.” Given today’s threats, I think it’s the right message to tell people they’re safer, not safe, just safer, if they install apps from a store. It doesn’t have to be Google’s store, but it should be backed by someone with the money and resources to guarantee security.

The stock OS permits installing apps from anywhere just like GrapheneOS so this is irrelevant. Play Store is where most Android malware is distributed. It's filled with spyware and malware to the point that most of the top apps are quite privacy invasive and breaking privacy laws. The authenticity/integrity of the apps can be verified on GrapheneOS via the hardware attestation API. The signing key proves the app is the genuine one from the developer and they can check the version code to avoid old versions of their app being used. Client side security checks are not a good approach to security but they can be done with a higher level of assurance on GrapheneOS than elsewhere.

GrapheneOS encourages installing apps in safer ways than the Play Store where people are far less likely to be misled by the many cloned / impersonator apps on the Play Store, etc. There are many apps on the Play Store pretending to be other apps or ones which uploaded a build of an open source app and look official but are actually a third party.

Only installing apps from the Play Store does not avoid malware and spyware.

APK files remain the biggest vector for scams worldwide…

Play Store is the biggest source of Android malware, spyware, etc. by far. Installing APKs from random websites, etc. is less safe than from the Play Store, sure. Installing APKs from trustworthy sites is safer than from the Play Store. Obtaining an open source app from the app developer via Obtainium is safer than trying to figure out if a Play Store entry for it is official or fake. There are also other apps stores like Accrescent.

But you and I know that. The people who use Graphene know it. My mother doesn’t, my father doesn’t, they have no idea what it is. Today, companies still get hit by ransomware because someone clicks an executable in an email. The world simply isn’t educated about security.

99.99% percent of the people who use this app have no idea what GrapheneOS is… they don’t even know how to tell if an app is safe. Unfortunately, however correct your argument is, that’s today’s reality. PagoPA made its choices, whether we agree or not. It’s not an essential service like the Green Pass was during Covid; it’s just a copy of a document.

But you and I know that. The people who use Graphene know it. My mother doesn’t, my father doesn’t, they have no idea what it is. Today, companies still get hit by ransomware because someone clicks an executable in an email. The world simply isn’t educated about security.

Google Mobile Services Android operating systems permit installing apps from outside the Play Store. It's irrelevant to this.

99.99% percent of the people who use this app have no idea what GrapheneOS is… they don’t even know how to tell if an app is safe. Unfortunately, however correct your argument is, that’s today’s reality. PagoPA made its choices, whether we agree or not. It’s not an essential service like the Green Pass was during Covid; it’s just a copy of a document.

They made their choice and will face a public relations disaster and substantial disruption of their business because of it because they're going to become a focus for our efforts to fight the anti-competitive and insecure Play Integrity API. They should not have spread blatant misinformation about GrapheneOS.

It's legal for them to do what they did and it's also legal for us to publish a scathing article about it and actively coordinate our community to protest their actions. Protests can be quite disruptive while still being completely legal. The portion of our community interested in using this app is small but we can involve our whole community in this. It was a mistake to spread misinformation about GrapheneOS falsely claiming that apps cannot be verified on it. We expect a retraction to made for what they submitted.

It’s not an essential service like the Green Pass was during Covid; it’s just a copy of a document.

I casi d'uso di documenti su IO non si limiteranno certamente al mero flex del QR Code di IT-Wallet all'agente del posto di controllo, c'è una roadmap complessa che prevede l'integrazione dei wallet all'interno del framework europeo dell'identità nei prossimi anni. App, siti web e servizi statali e non si aspetteranno o verrà richiesto che gli utenti abbiano il wallet per verificare identità e attributi (ad esempio per visitare siti per adulti).

Apple e Google stanno già cogliendo la palla al balzo difatti le versioni beta dei browser includono supporto a Digital Credentials API per rispondere a questi casi d'uso, pescando dai loro wallet ma anche app di terzi come IO. L'incentivo a adottare queste soluzioni sarà enorme in quanto i sistemi attuali richiedono al servizio di pagare terzi per la verifica e all'utente di fornire i propri dati a aziende ignote, mentre in futuro basterà chiamare un API JavaScript e ottenere i dati già validati. Sarà mai obbligatorio? No. Sarà de-facto essenziale, diciamo entro il ~2030 circa? IO ritengo di sì.

DMA o no, diventa grottesco il fatto che Io sia nominalmente open source, quando di fatto non si può compilare una propria build che sia anche utilizzabile, da mettere su F-Droid o per qualunque altro scopo; quando questa applicazione "open source" può essere installata solo dal Play Store o non funzionerà; quando la remote attestation rimuove quelle libertà che sono parte integrante del software libero.
Se a qualcuno non fosse ancora chiaro perché esiste la GPLv3, a questo punto dovrebbe esserlo.

È open-source ed è compilabile da te è utilizzabile da te senza problemi e in piena libertà. Puoi metterla dove vuoi. Sempre che ti metti da qualche parte anche il tuo backend (sempre open-source).

Sì, certo, a quel punto devo anche farmi il mio Stato personale dove il mio backend personale è valido per i miei documenti personali.

Per favore, piuttosto dimmi "secondo me è giusto così anche se a te non piace e non rispetta il principi del software libero" (ripeto, se le cose tipo remote attestation rispettassero la libertà 0, allora chiaramente non ci sarebbe stato bisogno di creare la GPLv3, quindi non è una cosa che mi sto sognando io), ma almeno non prendermi in giro, grazie.

Ma non può rispettare per principio i principi del software libero. Non possono permettersi di avere altre app o fork che interagiscono con il backend ufficiale

@robypez They can verify it's the official, unmodified app on GrapheneOS with a higher level of security than the Play Integrity API provides. They support a huge number of devices missing many months of critical security patches and important security features but yet somehow we're meant to believe they care about checking for a secure device. If they were checking for a secure device, most Android devices wouldn't qualify, but GrapheneOS certainly would.

Idea per una opzione in più per https://ioapp.it/scarica-io "Scarica da qui":

• Chain of trust dal codice su GitHub fino all'APK (piuttosto che gli AAB del Play Store, firmati da Google e non lo sviluppatore)
• Build riproducibile
• Attestazione hardware di Android
• Notifiche? WebSockets (mitigherebbe anche il problema dello spionaggio tramite FCM/APNS)
• Gli aggiornamenti? Automatici e unattended tramite le API di Android.

Un'app manomessa o un'app che la impersona continuerebbe a non poter interagire col backend come quella distribuita sul Play Store, sarebbe più resiliente, sicura, indipendente e non richiederebbe account per il download.

Ma tutto quello che gira attorno, custom Rom, sideload e simili non potrà mai essere un qualcosa di popolare.

È come dire "Linux non potrà mai essere un qualcosa di popolare" (e intendo distribuzioni Linux per computer, non semanticismi sul fatto che Android usa Linux come kernel): da una parte può darsi che sia vero, ma dall'altra parte, grazie al cielo, negli anni si è creata una coscienza che la libertà di scegliere sistema operativo per il proprio computer sia importante, e anche la pubblica amministrazione si è aperta all'idea e in genere offre soluzioni anche per Linux quando servono driver per leggere le card o altro software vario ed eventuale. L'idea che sia necessario usare Windows per forza per interagire con la pubblica amministrazione è considerata inaccettabile, e questo concetto ha avuto anche risvolti nei regolamenti europei.

Purtroppo, con gli smartphone la situazione si è come resettata: non sono considerati alla stregua di computer, e quindi improvvisamente quello che ci eravamo conquistati con fatica per anni, in termini di libertà di software, è stato velocemente azzerato, anche grazie a strumenti come la remote attestation (Play Integrity o altro che sia), che minano fortemente la libertà digitale individuale: davvero, ma davvero, non riesco a concepire come alcuni di voi trovino anche lontanamente accettabile il fatto che un'app del governo possa arrogarsi il diritto di dire che altre app noi possiamo avere sullo stesso telefono (cosa che succede obbligando all'uso di Play Protect), o che sistema operativo possiamo aver installato.

E al giorno d'oggi, avere installato un sistema operativo stock ha molti più risvolti negativi di 15 anni fa quando si parlava dei soli computer, e non si dava per scontato che un sistema operativo e il software preinstallato mandassero sul cloud qualunque cosa facessimo...