Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It Wallet - [Graphene OS] - Criteri di sicurezza Documenti su IO #6327

Open
0pipe0 opened this issue Oct 23, 2024 · 320 comments
Open

It Wallet - [Graphene OS] - Criteri di sicurezza Documenti su IO #6327

0pipe0 opened this issue Oct 23, 2024 · 320 comments

Comments

@0pipe0
Copy link

0pipe0 commented Oct 23, 2024

Salve, come da titolo non passo i requisiti minimi di sicurezza con pixel 6a.
Non uso l'os stock, ma ho installato Graphene OS proprio per ragioni di privacy e sicurezza. Non ho infatti alcun root al telefono e ho il bootloader bloccato (come la FAQ relativa suggerisce).

Android 15
GraoheneOS: build 2024102100

Grazie!

@orazioedoardo
Copy link

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

@0pipe0
Copy link
Author

0pipe0 commented Oct 24, 2024

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.

@orazioedoardo
Copy link

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.

@simonesestito
Copy link

è 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

@orazioedoardo
Copy link

orazioedoardo commented Oct 25, 2024

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.

@paolo-caroni
Copy link

paolo-caroni commented Oct 26, 2024

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..

@orazioedoardo
Copy link

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.

@paolo-caroni
Copy link

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.

@thestinger
Copy link

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.

@ElDavoo
Copy link

ElDavoo commented Oct 28, 2024

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.

@ElDavoo
Copy link

ElDavoo commented Oct 28, 2024

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?

@orazioedoardo
Copy link

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.

@orazioedoardo
Copy link

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.

@Prisoner709
Copy link

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!

@M4th12
Copy link

M4th12 commented Nov 3, 2024

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

@thestinger
Copy link

@M4th12 Play Integrity API is supposed to be checked on the service, not in the app. Locally spoofing it for an app checking it won't bypass it for a proper implementation. Tricking the strong integrity check requires a leaked key which they can revoke once they detect it with their fingerprinting, although they probably won't for ones only used by a single person.

@M4th12
Copy link

M4th12 commented Nov 3, 2024

True, but in the meantime I found a solution using a Module called Tricky Store, now I can use all the functions without an error. (I know is not the best for security, but I don't want to have a bad experience with the stock ROM)

@thestinger
Copy link

@M4th12 Are you using a leaked key?

@briddarobert
Copy link

Caro team di IO, rispetto molto il vostro lavoro e vi sono grato per l'esempio virtuoso che date a tutta la PA per la gestione del progetto in maniera aperta. Mi sento però in questo momento di dover chiedere come mai, a due settimane dall'apertura dell'issue, non sia pervenuta ancora una risposta almeno ufficiosa. Andando avanti la discussione inevitabilmente si allargherà e sarà più difficile gestire il tutto. Già adesso il discorso si è esteso prendendo in considerazione la sicurezza di varie ROM e come bypassare il controllo da voi imposto, quando il problema è uno e molto semplice: l'API che usate è sbagliata in principio. Stiamo ricevendo anche il contributo del fondatore di quella che è probabilmente la ROM Android più sicura di sempre. Capisco che abbiate avuto le vostre gatte da pelare grazie ai tuttologi che su Twitter sono arrivati ad accusarvi di gestire male il progetto senza capirne niente, capisco anche che sia faticoso gestire un progetto open contribution, questo però non giustifica una totale negligenza nella comunicazione con il pubblico rispetto ad un problema che riguarda l'identità digitale del cittadino, un argomento che a poco a poco diventerà sempre più importante.

@0pipe0
Copy link
Author

0pipe0 commented Nov 6, 2024

Ho segnalato sul post dedicato a it wallet di IO su linkedin le due issues (questa e #6346 ). Un'altra soluzione è spingere google (aiutati da pagopa) ad ammettere GrapheneOS nella whitelist delle play untegrity api.

@orazioedoardo
Copy link

L'issue su traffico in chiaro sembra avere una spiegazione semplice che ho appena aggiunto.

Certo per GrapheneOS sarebbe ideale se Google lo aggiungesse in allowlist di Play Integrity in modo che funzioni con ogni app che ne fa uso, tuttavia la vedo dura e non affronterebbe il problema più grande, cioè l'uso stesso dell'API.

@M4th12
Copy link

M4th12 commented Nov 6, 2024

@thestinger not leaked but given from a developer

@roberto-sartori-gl
Copy link

@thestinger not leaked but given from a developer

Gli sviluppatori non hanno accesso ai keybox. È una chiave leaked di certo se passi strong integrity.

Detto ciò, io ora ho un problema ancora più grande perché il mio telefono è stato rilasciato con Android 7, aggiornato fino ad Android 10, ma non supporta neanche con sistema stock la STRONG INTEGRITY di Play Integrity. Di fatto non posso usare IT Wallet, se non appunto con trucchi vari, sul mio telefono stock con Android 10 (l'attestazione hardware non era un requisito con Android 7). Ovviamente usando custom rom con versioni più recenti di Android vale lo stesso, ma il fatto che io non possa usare una funzionalità come IT Wallet su un telefono stock mi pare alquanto assurdo.

@thestinger
Copy link

@roberto-sartori-gl Strong integrity depends on hardware key attestation which was required for devices launched with Android 8 and later so your device is too old. It's worth noting that only Android 12 or later has security support so devices with earlier versions lack security patches. It's ridiculous that a device with no patches for 8 years can pass Play Integrity device integrity but yet GrapheneOS is forbidden. GrapheneOS should pass both device and strong integrity, but unfortunately Google is taking a highly anti-competitive approach and apps like this are participating it. It's clearly illegal and we're not only considering legal action against Google but also app developers.

@roberto-sartori-gl
Copy link

@thestinger

My point is that the requirement for IT Wallet is 'Android 8', which is not true. The real requirement on Android is Play Integrity (with hardware attestation).

Anyway, I don't think this is the thread to discuss GrapheneOS or not GrapheneOS. There are a lot of phones which don't have GraheneOS available so discussing GrapheneOS is not the point. Even Lineage may be considered more secure on old phones compared to the stock OEM OS.

@thestinger
Copy link

This thread was created about GrapheneOS, which not only preserves the standard security model (unlike LineageOS) but substantially improves security. A device without Android 12 or later with current security patches wouldn't pass their checks if they cared at all about security rather than doing performative security with a clearly illegal anti-competitive approach to pretend they care. They should either implement https://grapheneos.org/articles/attestation-compatibility-guide as a staritng point to permitting secure alternate operating systems or remove their checks. This thread was not created about LineageOS and LineageOS genuinely does not preserve the standard security model and features so convincing them to allow it is an entirely different topic from convincing them to allow a secure OS. Their lack of forbidding clearly insecure devices without security patches is simply strong evidence that they do not actually care about security but rather want to pretend they do, but they can prove that wrong by adding a check for a patch level from the past 4 months at a bare minimum.

@thestinger
Copy link

Even Lineage may be considered more secure on old phones compared to the stock OEM OS.

It still lacks most of the privacy/security patches, Nothing secure about that, and an app which wants to permit only secure devices would be checking for a current patch level and not allowing operating systems setting a fake patch level to mislead users like LineageOS does... LineageOS is a major part of the reason for why app developers are hostile towards alternate operating systems because they wrongly believe all of them have the same awful security as LineageOS, which is wrong. The person who filed this issue filed it about GrapheneOS and bringing up an insecure hobbyist OS is just weakening the attempt at getting them to follow https://grapheneos.org/articles/attestation-compatibility-guide.

@roberto-sartori-gl
Copy link

roberto-sartori-gl commented Nov 6, 2024

@thestinger the fact that the user who opened the issue is using GrapheneOS does not mean that we should discuss GrapheneOS only. We are in the io-app repository discussing IT Wallet. If you want to discuss GrapheneOS vs Lineage, you can discuss it on the Graphene OS repositories, I assume.

Like I said, I have the same issue using the stock OS from the vendor of my phone. No Lineage or custom ROM.

@thestinger
Copy link

GrapheneOS supports hardware-based attestation which can be used to verify the device is running GrapheneOS as explained in https://grapheneos.org/articles/attestation-compatibility-guide. LineageOS doesn't support this so even if they wanted to allow it, there isn't a way for them to do it within their model of wanting to check the OS based on hardware attestation.

This issue is about them implementing https://grapheneos.org/articles/attestation-compatibility-guide to verify the device is running either GrapheneOS or another alternate OS preserving the security model and supporting hardware attestation. We aren't aware of any others, but they could whitelist their keys very easily after they implement this.

LineageOS doesn't provide current privacy/security patches, sets an inaccurate Android security patch level which misleads users, doesn't preserve the standard privacy/security model, doesn't leverage important hardware-based security features and introduces major issues. You're also talking about a phone running the stock OS which hasn't had security patches for years. Android 12 is the oldest Android OS version with ongoing security support and if this app cared about security instead of only performative security to pretend they're doing something for perception and legal reasons it would be the minimum OS version.

You're bringing up LineageOS on an issue about permitting GrapheneOS so it's you who brought up this topic. LineageOS is indeed off topic for this issue, as is using a device with the stock OS that hasn't received security patches for years. It's not what the issue was filed about and all you're distracting from getting GrapheneOS permitted as it should be via our attestation compatibility guide.

@thestinger
Copy link

If they implement what's covered in our attestation compatibility guide by using the native Android hardware attestation API to verify the device is running either the stock OS or GrapheneOS, then they can easily add other operating systems. That is the starting point for adding other operating systems.

@Darkon82
Copy link

Darkon82 commented Jan 13, 2025

ma il senso di play integrity non era quello di AUMENTARE la sicurezza?

In realtà no. Il senso di play integrity è soprattutto quello di tutelare gli interessi di google come ad esempio creare difficoltà a chi blocca gli ads o a chi modifica il sistema per far arrivare meno dati a google stessa.
Al di là del marketing play integrity non ha mai avuto particolari velleità di essere un baluardo di sicurezza.

Non a caso google o altri non può impedirti di rootare o di installare custom rom altrimenti sarebbe bastato agire in tal senso ed eri tagliato fuori. Play Integrity è quindi da considerarsi a tutti gli effetti un sistema di tutela nato per gli interessi di google come condizione per poterne usufuire.

@MisterEskere
Copy link

solo che per assurdo chi ha problemi di errore 409 li risolve rootando il dispositivo. Fa un po' ridere.

Secondo me questa è una delle falle principale di Play Integrity alla quale spesso non si pensa. Se hai un dispositivo con una custom rom e bootloader sbloccato ma senza root, per passare l'integrità viene spinto ad aggiungere root e svariati moduli magisk (spesso di dubbia provenienza), entrambe cose che riducono (ulteriormente) la sicurezza (stesso si applica in caso di dispositivo che non passa l'integrità già stock per motivi ignoti, ed è ancora più problematico in quel caso ovviamente). ma il senso di play integrity non era quello di AUMENTARE la sicurezza? se gli sviluppatori dell'app io aggiungessero un semplice tasto "continua comunque, mi assumo le responsabilità" sulla schermata "dispositivo non idoneo" aumenterebbero in ogni caso la sicurezza per tutti quegli utenti alla quale non importa di rischi e pericoli e che di conseguenza hanno dovuto ricorrere a tali stratagemmi. In un universo parallelo in cui play integrity è un sistema perfetto e inviolabile che non può essere aggirato in nessun modo il discorso sarebbe leggermente diverso.

Il problema non è play integrity (google che cerca di monopolizzare android, che gli puoi dire) ma il fatto che i dev (che paghiamo, perchè va detto anche questo) ignorino completamente il problema senza manco dirci nulla. Questa è la issue più commentatta su tutto il repo... evidentemente non siamo in 4 polli a usare costum rom ma molte persone. Sono daccordo con le persone che dicono che si possa vivere anche senza i documenti sul telefono ma per una volta che l' italia fa qualcosa di bello e utile in campo informatico girano le scatole vederla andare male per accomodare gli americani.

@Darkon82
Copy link

Darkon82 commented Jan 13, 2025

Il problema non è play integrity (google che cerca di monopolizzare android, che gli puoi dire) ma il fatto che i dev (che paghiamo, perchè va detto anche questo) ignorino completamente il problema senza manco dirci nulla. Questa è la issue più commentatta su tutto il repo... evidentemente non siamo in 4 polli a usare costum rom ma molte persone. Sono daccordo con le persone che dicono che si possa vivere anche senza i documenti sul telefono ma per una volta che l' italia fa qualcosa di bello e utile in campo informatico girano le scatole vederla andare male per accomodare gli americani.

Il problema allo stato delle cose è molto probabilmente dovuto a una discordanza tra key e lo spoof che viene fatto delle prop. Non a caso con la nuova implementazione almeno per il momento la situazione si è risolta. Direi quindi che non dipende da IO in quanto tale e nemmeno da wallet ma semplicemente che il precedente strong integrity anche se rilevato come valido non era ancora completo.

Inutile dire che se tale informazione fosse confermata non c'è alcuna speranza per chi ha un errore 409 se non rootando in quanto non c'è un modo per sistemare eventuali discordanze senza accedere al root.

In ogni caso lo stesso problema via via sarà presente su tutte le app che riterranno necessaria la strong integrity motivo per il quale se diventasse pratica diffusa richiedere lo strong praticamente le custom rom senza root diventerebbero inutilizzabili.

@Ciancy28
Copy link

In realtà no. Il senso di play integrity è soprattutto quello di tutelare gli interessi di google

Su questo siamo tutti d'accordo, il mio era solo l'ennesimo tentativo di far ragionare gli sviluppatori (che comunque ormai non credo ci stiano leggendo) convinti che il suo scopo sia quello li, spiegandogli che se lo usano per tale scopo, non ha senso spingere gli utenti a compromettere i loro dispositivi vanificando il tutto piuttosto che mettere un tastino per ignorare l'avviso.
Probabilmente hanno subito una buona dose di brainwashing da parte di google e se gli spieghi le vere motivazioni dell'esistenza di play integrity api vieni visto come un complottaro, meglio tentare di ottenere risultati facendo leva da altre parti (secondo me).

@MSnaker
Copy link

MSnaker commented Jan 13, 2025

Confermo che adesso funziona anche senza usare la 2.80.09 solo che per assurdo chi ha problemi di errore 409 li risolve rootando il dispositivo. Fa un po' ridere.

@Darkon82 io credo che la cosa non sia così scontata, perché a me non funziona. Pixel 7a, GrapheneOS, sia con app=2.80.0.10 da apk github, che con app=2.80.0.9 da GPlay

@Darkon82
Copy link

@Darkon82 io credo che la cosa non sia così scontata, perché a me non funziona. Pixel 7a, GrapheneOS, sia con app=2.80.0.10 da apk github, che con app=2.80.0.9 da GPlay

Devi fare tutta la procedura eh... non è che basta installare Tsupport. Quello è il primo passo poi ce ne sono altri da fare che non posso scrivere qua.

@MSnaker
Copy link

MSnaker commented Jan 13, 2025

Devi fare tutta la procedura eh... non è che basta installare Tsupport. Quello è il primo passo poi ce ne sono altri da fare che non posso scrivere qua.

Ah, credevo che dicessi che il problema si fosse risolto anche per chi non ha il root. Mi informerò su quali siano le vie traverse, e se valga la pena compromettere l'integrità del mio OS.

Ne approfitto per unirmi alle voci che chiamano "truffa al consumatore" il sistema di Google Play Integrity. Ricordiamo quando il motto di Google era ancora "Don't be evil".

@Darkon82
Copy link

Ah, credevo che dicessi che il problema si fosse risolto anche per chi non ha il root. Mi informerò su quali siano le vie traverse, e se valga la pena compromettere l'integrità del mio OS.

No no, se leggi bene prima anche con un altro utente commentavamo che per assurdo col root adesso funziona invece se hai graphene o qualsiasi altra custom senza root non funziona. In pratica stanno spingendo chiunque abbia custom rom a rootare.

Ne approfitto per unirmi alle voci che chiamano "truffa al consumatore" il sistema di Google Play Integrity. Ricordiamo quando il motto di Google era ancora "Don't be evil".

È spinosa come questione perché per come è nata aveva anche senso: era una API per dire che google ti offre gratis tot servizi ma devi stare a determinate regole. Il problema quindi non era alla nascita dove tutto sommato poteva anche essere una scelta legittima ma successivamente quando gli sviluppatori hanno preso una API che doveva essere dedicata ai soli prodotti google, l'hanno fraintesa come una sorta di misura di sicurezza e praticamente l'hanno imposta come condizione assoluta.

Sinceramente, sia chiaro parere personale, più che google a non dover essere cattiva sono i dev delle varie app a non pretendere regole assurde che poco hanno a che fare con la sicurezza.

@thestinger
Copy link

@Darkon82 Google is heavily promoting the Play Integrity API to app developers and is misrepresenting it as a security feature. Google are the ones defining it as only permitting devices licensing Google Mobile Services. It's certainly their intention for a bunch of non-Google apps to adopt it and help them prevent competition with Google services by locking people into them in a whole new way. They're trying to prevent a bunch of Android apps being used outside devices licensing Google Mobile Services which includes a bunch of anti-competitive terms such as including certain Google apps and making them the default. It has very little to do with security.

There are only bare minimum security standards for licensing Google Mobile Services and providing security updates isn't one of those. These apps are permitting a device with no security patches for literally a decade but not a phone running a far more secure OS than anything licensing Google Mobile Services (GrapheneOS).

There's no good excuse for disallowing using anything other than an iPhone or an Android phone licensing Google Mobile Services. GrapheneOS fully supports verifying the device via the standard Android hardware attestation API if the app developers insist on doing that for one reason or another.

There's no actual security value in checking that a device licensed Google Mobile Services which is all the Play Integrity API actually provides. It can be trivially bypassed by attackers which is easy for people to see considering that users simply have to put a rootkit on their device hiding itself and pretending that it's a certified device.

@orazioedoardo
Copy link

Su questo siamo tutti d'accordo, il mio era solo l'ennesimo tentativo di far ragionare gli sviluppatori

Guarda secondo me non ci credono neanche loro a Play Integrity, se ne saranno sicuramente resi conto. È palese che non sia in grado di proteggere i documenti su IO contro un attaccante con privilegi completi sul sistema (root + esterno della sandbox).

Supportasse SOLO GrapheneOS allora forse sarebbe utile, ma quando hai una platea così vasta di dispositivi in cui la maggior parte degli OEM fa un lavoro mediocre o scadente, Play Integrity è un minimo comune denominatore che non garantisce nulla.

comunque ormai non credo ci stiano leggendo

In realtà sì, a giudicare dalle reazioni ad alcuni commenti come quelli del giornalista di DDAY e alcuni commenti “coloriti”.

@MethAddicted
Copy link

@MSnaker legg questo thread

https://xdaforums.com/t/multiple-italian-official-apps-now-detect-root-need-help-bypassing.4699403/page-6

ho scritto una piccola guida per avere la strong integrity, e poi dopo leggi anche i messaggi successivi.

@MethAddicted
Copy link

@Darkon82 Google is heavily promoting the Play Integrity API to app developers and is misrepresenting it as a security feature. Google are the ones defining it as only permitting devices licensing Google Mobile Services. It's certainly their intention for a bunch of non-Google apps to adopt it and help them prevent competition with Google services by locking people into them in a whole new way. They're trying to prevent a bunch of Android apps being used outside devices licensing Google Mobile Services which includes a bunch of anti-competitive terms such as including certain Google apps and making them the default. It has very little to do with security.

There are only bare minimum security standards for licensing Google Mobile Services and providing security updates isn't one of those. These apps are permitting a device with no security patches for literally a decade but not a phone running a far more secure OS than anything licensing Google Mobile Services (GrapheneOS).

There's no good excuse for disallowing using anything other than an iPhone or an Android phone licensing Google Mobile Services. GrapheneOS fully supports verifying the device via the standard Android hardware attestation API if the app developers insist on doing that for one reason or another.

There's no actual security value in checking that a device licensed Google Mobile Services which is all the Play Integrity API actually provides. It can be trivially bypassed by attackers which is easy for people to see considering that users simply have to put a rootkit on their device hiding itself and pretending that it's a certified device.

this thread really touched my heart https://xdaforums.com/t/discussion-magisk-kernelsu-apatch-the-root-hiding-and-mod-hiding-cat-and-mouse-game.4425939/

@sirtao
Copy link

sirtao commented Jan 14, 2025

Aggiorno anche qui: con la 2.80.0.9 da google play si è risolto il problema... per ora.

Seriamente qui la grana è al 80% la mancana di adeguata comunicazione... un banale "stiamo cercando la grana", "abbiamo trovato la grana e stiamo lavorando per risolverla, non necessariamente nel prossimo aggiornamento" e "rilasciato l'aggiornamento con la grana risolta" sarebbero bastati

@Lppsoeht
Copy link

Aggiorno anche qui: con la 2.80.0.9 da google play si è risolto il problema... per ora.

Seriamente qui la grana è al 80% la mancana di adeguata comunicazione... un banale "stiamo cercando la grana", "abbiamo trovato la grana e stiamo lavorando per risolverla, non necessariamente nel prossimo aggiornamento" e "rilasciato l'aggiornamento con la grana risolta" sarebbero bastati

A me non risulta nessun cambiamento, dà sempre lo stesso errore.

@Darkon82
Copy link

A me non risulta nessun cambiamento, dà sempre lo stesso errore.

Perché torno a ribadire che il problema non lo risolvi con aggiornamenti dell'app. Il problema si risolve o tramite la nuova procedura root (ma devi rootare) oppure va risolto lato "server".

L'app di per sé tra la 2.79 e la 2.80 non ha cambiamenti che almeno a quanto posso capirne io possano in alcun modo risolvere l'errore 409.

@sirtao
Copy link

sirtao commented Jan 15, 2025

A me non risulta nessun cambiamento, dà sempre lo stesso errore.

Perché torno a ribadire che il problema non lo risolvi con aggiornamenti dell'app. Il problema si risolve o tramite la nuova procedura root (ma devi rootare) oppure va risolto lato "server".

L'app di per sé tra la 2.79 e la 2.80 non ha cambiamenti che almeno a quanto posso capirne io possano in alcun modo risolvere l'errore 409.

Eppure senza cambiamento lato device adesso a me funziona.
Questo implica che è un problema della app, che sia nel codice di controllo della sicurezza interno o di come comunica con i server.

@BoGnY
Copy link

BoGnY commented Jan 15, 2025

il problema si risolve rimuovendo il blocco e mettendo un semplice avviso, come fanno tutte le app...
bloccare gli utenti per scelta millantando che la strong dia una pseudo sicurezza aggiuntiva è una putt*nata bella e buona, perché come detto anche da thestinger qualche messaggio più su la play integrity nulla ha a che fare con la sicurezza ma è solo una tutela per google per permettere solo device dei suoi partner commerciali

@sirtao
Copy link

sirtao commented Jan 15, 2025

Francamente qui il problema non è quello, ma una implementazione errata di qualcosa.
E non necessariamente di quello legato a Play Security, che tra l'altro mi pare di capire sia un requisito tennico per il wallet europeo quindi hanno ben poca scelta nella implementazione.

@Pietro395
Copy link

Francamente qui il problema non è quello, ma una implementazione errata di qualcosa. E non necessariamente di quello legato a Play Security, che tra l'altro mi pare di capire sia un requisito tennico per il wallet europeo quindi hanno ben poca scelta nella implementazione.

No, non sono un requisito

Vorrei far notare che i requisiti formali di eudi wallet non richiedono Google Play Integrity; https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/tree/main

L'implementazione di riferimento è solo un esempio: https://github.com/eu-digital-identity

@thestinger
Copy link

GrapheneOS fully supports verifying the device, OS and the app's signing key(s) + version via the hardware attestation API. They're choosing to ban people from using a more private and secure OS without a justification for it.

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

There's no legitimate excuse for permitting a device with no security patches for a decade but not a much more secure device running GrapheneOS which supports a more secure, standard way to verify it than the Play Integrity API.

@sirtao
Copy link

sirtao commented Jan 15, 2025

They're choosing to ban people from using a more private and secure OS without a justification for it.

Look, I get where you are coming from. I like the project, I agree with many of the choices etc etc but you are starting to sound more like a spambot. Can you make ONE post without referring to GrapheneOS?

Especially this is the "General" topic about security standards and not just the GrapheneOS topic, and has been for almost one month.
@0pipe0 is possible for you as OP to edit the title to better reflect this change?
(though perhaps opening dedicated Discussions might be for the better instead of relying on a Issue)

@thestinger
Copy link

Look, I get where you are coming from. I like the project, I agree with many of the choices etc etc but you are starting to sound more like a spambot. Can you make ONE post without referring to GrapheneOS?

The issue is specifically about GrapheneOS support, where else would it be talked about?

Especially this is the "General" topic about security standards and not just the GrapheneOS topic, and has been for almost one month.

You're treating it that way because other issues were closed but they aren't the same thing. GrapheneOS supports hardware-based attestation for verifying it and that is what is being requested here. Other operating systems could preserve the security model and support hardware-based attestation too, but they have to start somewhere. https://grapheneos.org/articles/attestation-compatibility-guide is something they could implement quickly and ship out to users, then add support for other operating systems offering the same thing.

@sirtao
Copy link

sirtao commented Jan 15, 2025

 You're treating it that way because other issues were closed but they aren't the same thing.

They were closed with the explicit instruction this was the correct venue for those. It made this, for all purposes and intents, the "General" topic.
I wholeheartedly agree it was a foolish move that can onlu generate confusion and frustration.
But THE MODS make the rules, not I. And Internet is not a democracy anyway.

On this note: I made a Survey to ask the community what they think about removing Play Integrity: #6604
I invite everybody to vote and, possibly, elaborate their position

@thestinger
Copy link

They're expected to check the integrity of the hardware, OS and app. We're providing a way for them to do that in a better way than they do now to permit much more secures devices. That's something they can realistically implement and there's no clear reason why they can't do it. We're seeking a very realistic end result. Having it completely derailed is not helping you either.

@Ciancy28
Copy link

Ciancy28 commented Jan 15, 2025

piccolo aggiornamento: da stamattina passo solo basic, funziona ancora.

sempre post primo setup immagino

Si, non penso di voler tentare una riconfigurazione al momento

Il Pixel 4a in questione si è rotto (batteria gonfia che ha danneggiato il display, si lo so che dovrei liberarmene o farlo riparare prima che esploda ma questo è off-topic e ho voluto fare da cavia per motivi scientifici), l'assistenza google me ne ha spedito uno nuovo/ricondizionato.
Reinstallato la stessa rom (ultima versione di PixelBuilds) sul 4a nuovo, sempre senza fare nessun mageggio con keybox o altro, stesso livello di integrità (niente strong, ma passa nuovamente device integrity in seguito a un aggiornamento), al primo tentativo ho ricevuto il classico errore che "non supporta i documenti su io" ma riprovando il giorno dopo (avrò solo fatto un riavvio forse) sono riuscito a configurare il wallet senza problemi proprio come sul dispositivo precedente (che ironia della sorte, in seguito al log-out automatico invece non risulta più idoneo).
Tutt'ora non ho la minima idea di come mai proprio questa rom su questo preciso modello di telefono riesce a superare i requisiti di sicurezza (ma non sempre) senza integrità strong, senza keybox e senza bootloader bloccato.
Mi sono dimenticato di fare lo split screen con il risultato del controllo ma fidatevi che non è cambiato nulla su nessuno dei due dispositivi.
photo_2025-01-15_02-14-58

@thestinger
Copy link

@Ciancy28 They're only requiring device integrity meaning a highly insecure end-of-life device running an OS not trying to keep the security model intact which includes spoofing to mimic the stock OS on another device is permitted. Meanwhile, a very secure device is not permitted. That's exactly what this app is requiring.

@BoGnY
Copy link

BoGnY commented Jan 15, 2025

sono appena riuscito ad entrare su Documenti senza strong, ma rimuovendo ! alla fine del nome app dal file target.txt (va lasciato senza niente alla fine, oppure semplicemente si può anche omettere dal file target.txt)
pif e bbox casuali, cellulare oneplus con tee broken

@Ciancy28
Copy link

Ciancy28 commented Jan 15, 2025

@Ciancy28 They're only requiring device integrity

So to clear this up once and for all: the fact that it wallet is supposed to require strong integrity is false and that's just a rumor that's been spreading (or prehaps a misunderstanding on my part)? correct? my experience would definitely be consistent with that.

@thestinger
Copy link

It doesn't require strong integrity. They aren't willing to make any significant sacrifice, just ban users on secure alternate operating systems but not ones where people install a rootkit and are doing spoofing which gets the app temporarily working with a back and forth as Google very slowly blocks forms of spoofing while not being willing to even drop support for devices with no patches for 10 years which ties their hands. They actually push people to using less secure devices and operating systems with the feature.

@sirtao
Copy link

sirtao commented Jan 16, 2025

@Ciancy28
So to clear this up once and for all: the fact that it wallet is supposed to require strong integrity is false and that's just a rumor that's been spreading (or prehaps a misunderstanding on my part)? correct? my experience would definitely be consistent with that.

Well, a problem is... I don't think they have ever published the system\security requirements anywhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests