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

[0pipe0]

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]

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]

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]

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]

è 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

@M4th12 Are you using a leaked key?

[briddarobert]

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]

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]

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]

@thestinger not leaked but given from a developer

[roberto-sartori-gl]

@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]

@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]

@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]

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]

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]

@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]

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]

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.

[roberto-sartori-gl]

@thestinger You are not getting the point.

You're bringing up LineageOS on an issue about permitting GrapheneOS so it's you who brought up this topic

The issue is related to the IT Wallet security requirements, which are not specific to GrapheneOS. We should not discuss specific operating systems otherwise we will end up doing whatever Google is doing, whitelisting specific operating systems.

[thestinger]

GrapheneOS exceeds any security requirements they have. They can use the hardware attestation API to verify the device is running GrapheneOS without compromising their security requirements. The person who filed this issue explicitly described how GrapheneOS preserves security and meets their requirements, which was followed up with a link to our guide for how they can use a hardware attestation API for this.

[roberto-sartori-gl]

GrapheneOS exceeds any security requirements they have.

There is no explicit security requirements for IT Wallet except passing Play Integrity (strong) right now. An explicit set of requirements would actually be appreciated from the team (e.g. locked bootloader, recent security patches, not-AOSP keys and so on).

[thestinger]

Play Integrity API does imply a set of security requirements but they're very weak since there isn't even a minimum patch level beyond the initial minimum patch level for Android 8.

[Prisoner709]

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?

In quale paese sono ubicati i server IO Italia sui quali un giorno verranno inseriti TUTTI i TUOI documenti italiani che non saranno solo patente, carta di identità e tessera sanitaria, ma ogni minima cosa ti riguardi....., lo sai vervo? Magari unendo i puntini...., alla fine si riesce a completare il disegnino.

[orazioedoardo]

they can prove that wrong by adding a check for a patch level from the past 4 months at a bare minimum.

Obviously they won't do it because it would cut off a major portion of devices.

[paolo-caroni]

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.

No, the issue is about a clarification on the FAQ that ask for requirements:

Per attivare Documenti su IO, assicurati che il tuo dispositivo soddisfi questi requisiti minimi:

per iOS: dispositivi con una versione di iOS pari o successiva a quella supportata dagli iPhone 6s e successivi; per Android: dispositivi con Android 8.0 o versioni successive. È 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).

LimeageOS and GrapheneOS are on the same level about this, no default rooting and android >8. If you have not root, have a locked bootloader and android >=8 you should have IT wallet. They actually don't require explicitly integrity API (huawei device?), they don't require hardware attestation, they don't require upgraded android (android 8 is pretty old).

[thestinger]

@paolo-caroni No, you're completely wrong. They're not on the same level at all and LineageOS does compromise the Android security model. It's an insecure hobbyist OS which does not have secure build infrastructure, updates or verified boot. By locked bootloader, they're also talking about having verified boot and attestation which are part of that. Locking for purely aesthetic and performative reasons without having those implemented is not what is being talked about. This issue was filed about GrapheneOS asking why GrapheneOS is wrongly detecting as not passing the requirements despite being more secure and supporting all the standard hardware security features including verified boot and attestation. The solution to this is https://grapheneos.org/articles/attestation-compatibility-guide and supporting an insecure hobbyist OS without the standard security model, these hardware security features or others is not what the issue is about.

[paolo-caroni]

By locked bootloader, they're also talking about having verified boot and attestation which are part of that.

First of all they don't explicitly ask for locked bootloader, we as users have assumed that is required by "non siano state rimosse le restrizioni imposte dal sistema operativo".

Also, you can have LineageOS with AVBv2, you have to compile it on user mode (not userdebug), enable rollback protection (better use a mainline kernel to update firmware in this case, so replicant ishould be better than linege ). But this is offtopic.

On the FAQ they ask for: Android >=8 Restriction by the Operating System not removed (no root)

If they on this list add play integrity they "solve" this issue (in the wrong way).

[0pipe0]

K lets clarify. I opened this issue because my pixel 6a with GrapheneOS installed does not pass the check to use IT Wallet on the IO app and that is in contrast with actual app FAQ because my bootloader is locked and there is no root on the OS, that is most secure and privacy oriented. That's the point. Other users are complaining same problem with custom OS, but this issue is about GrapheneOS.

[thestinger]

@paolo-caroni

First of all they don't explicitly ask for locked bootloader, we as users have assumed that is required by "non siano state rimosse le restrizioni imposte dal sistema operativo".

LineageOS rolls back the standard security model in multiple ways. It also sets an inaccurate Android security patch level and misleads users about that. Since it sets an inaccurate patch level, if they start checking for it, they'll get an inaccurate value there.

Also, you can have LineageOS with AVBv2, you have to compile it on user mode (not userdebug), enable rollback protection (better use a mainline kernel to update firmware in this case, so replicant ishould be better than linege ).

LineageOS makes changes which remove parts of verified boot and also changes which conflict with the security model it uses. Their official releases do not have verified boot and you would have roll back numerous changes and avoid shipping new ones if you wanted to have it. DivestOS tries to do this for certain devices and has had verified boot bypasses from issues with it. Standard LineageOS definitely doesn't have verified boot even if you build it with a user build and lock the device.

Replicant is a highly insecure OS that's many years behind on security patches and doesn't have even a basic privacy and security model. It's a complete joke. Replicant still has proprietary firmware running across the hardware. Replicant is a blatant scam and heavily misleads users with highly dishonest claims about what it provides and about privacy/security. Promoting it is harming people and participating in scamming.

Those insecure operating systems are why it's so hard for GrapheneOS for GrapheneOS to get app developers to realize that it's completely different from them and they can verify it via the standard Android hardware attestation API with a standard library from Google for key attestation by simply permitting the SelfSigned boot state when the verified boot key fingerprint matches one of the official GrapheneOS verified boot keys. That is entirely different from removing their checks, adding support for insecure operating systems, etc. and it's not possible for them to verify those via hardware attestation which is what is being requested here. This issue is NOT requesting that they remove their checks for device security but rather use hardware attestation to verify GrapheneOS alongside permitting Google certified operating systems. Their current checks for Google certified operating systems do very little to check for a secure device, but that's also a separate problem from this issue. They want to do that and convincing them not to do that is unrelated to convincing them to allow GrapheneOS, which is a highly secure OS much more secure than any Google certified OS and supports hardware attestation via the standard Android API.

[0pipe0]

@roberto-sartori-gl ho aperto questa issue specifica per GOS. certo, possiamo parlare anche di altri sistemi operativi. Come @thestinger suggerisce, https://grapheneos.org/articles/attestation-compatibility-guide è un buon punto di partenza per riuscire ad attestare anche gli altri OS custom, ma prima partiamo da GOS, perché in ogni caso implementa un miglior modello di privacy e sicurezza, il che incontra i requisiti necessari per garantire la veridicità di documenti di identità.

[0pipe0]

@roberto-sartori-gl ma la discussione è in ogni caso stimolante, puntiamo a migliorare e fare cultura e questa cosa è bella 😊

[roberto-sartori-gl]

@0pipe0 certo, il problema è che se partiamo da un singolo sistema poi bisogna cominciare a certificare ogni sistema di ogni sviluppatore (come scritto sopra, qualcuno può farsi una build Lineage con le stesse feature di sicurezza) e non si finisce più. Secondo me come prima cosa bisognerebbe effettivamente avere dei requisiti che non siano solo 'play integrity', o che se quello è il requisito sia almeno scritto così ci mettiamo l'anima in pace.

[thestinger]

@paolo-caroni They're not likely to stop checking for device security and they are on the right path to doing it in a reasonable way if they just switch to the standard Android hardware attestation API. Using the Play Integrity API with the strong integrity level is essentially a way to indirectly use the hardware attestation API with revocation checks but with ONLY a check for the verified boot state being Verified without any checks for patch level, etc. They can switch to the hardware attestation API being used directly at no loss to security and then they open up the option to allow alternate operating systems and check the patch level from the hardware attestation data.

It's easy for them to use the hardware attestation API since Google provides an easy to use official library for it. It avoids depending on a Google service, avoids needing an API key, avoids issues if that Google service goes down, is more secure, etc. The hardware attestation API also provides a hardware attested patch level for the vendor, boot and system code which can be optionally used to enforce a minimum patch level. They could start by allowing the oldest possible Android 8 patch level and gradually reduce the gap based on how much ridiculous level of insecurity they actually want to permit. Over time, they can work towards permitting only a patch level from the past 4 months which would be reasonable. The hardware attestation API gives them what they need to do this properly.

GrapheneOS is currently the only OS providing what they need to check for it via hardware attestation (see https://grapheneos.org/articles/attestation-compatibility-guide) so that's not a complicated situation. In the future, when other alternate operating systems support it, they can decide which ones meet their security requirements. GrapheneOS is far more secure than anything certified by Google and has far higher standards than Android certification so it's a no brainer to support it. Supporting insecure old certified Android versions doesn't make much sense but is a separate issue which hardware attestation will enable them to deal with by providing an attested patch level. Play Integrity API doesn't provide an attested patch level and they wouldn't want to encourage checking it since it hurts Google's business model of downplaying the problem posed by highly insecure out-of-date Android devices.

[roberto-sartori-gl]

@thestinger

GrapheneOS is far more secure than anything certified by Google and has far higher standards than Android certification so it's a no brainer to support it

Who said this? GrapheneOS itself? Or do you have external certifications for this?

[thestinger]

Google Play Integrity API is not an external security verification but rather is Google claiming that every Android OS licensing Google Play is secure. Google knows that many of the devices they allow to pass the Play Integrity API check are highly insecure with an ancient patch level. It has also been repeatedly shown that many of the devices which are allowed to pass by it cheated at CTS/CDD certification and in fact do not comply with those standard security requirements.

If you'd like, we can provide you with a certification from the GrapheneOS Foundation and other organizations partnered with us that our code is audited, reviewed and certified to be much more secure than the stock Pixel OS, which is itself far better than the awful security provided by other Android OEMs. What do you want? A fancy certificate from the GrapheneOS Foundation which says that the OS is certified as secure? We can provide that. Does it need to come from a third party? We can provide that too. What does it have to do with actual security? Nothing.

[paolo-caroni]

K lets clarify. I opened this issue because my pixel 6a with GrapheneOS installed does not pass the check to use IT Wallet on the IO app and that is in contrast with actual app FAQ because my bootloader is locked and there is no root on the OS, that is most secure and privacy oriented. That's the point. Other users are complaining same problem with custom OS, but this issue is about GrapheneOS.

Ringrazio per il chiarimento sig. Mazzeo, quindi mi disiscrivo dall'issue, purtroppo evidentemente non mi riguarda... Dividi e comanda funziona sopratutto in età digitale. Sperare di smuovere qualcosa con le percentuali di utenti di una ROM specifica che funziona solo su una ristrettissima cerchia di cellulari è veramente difficile (quanti utenti italiani ci saranno?). Vi faccio i miei auguri, spero vi ascoltino.

P.s. una issue più inclusiva e rispettosa di tutti i diversi punti di vista sarebbe stata gradita. Insieme avremmo potuto fare la differenza, mettere pressioni mediatiche e/o politiche perché un servizio pubblico funzioni a e per tutti.

[0pipe0]

K lets clarify. I opened this issue because my pixel 6a with GrapheneOS installed does not pass the check to use IT Wallet on the IO app and that is in contrast with actual app FAQ because my bootloader is locked and there is no root on the OS, that is most secure and privacy oriented. That's the point. Other users are complaining same problem with custom OS, but this issue is about GrapheneOS.

Ringrazio per il chiarimento sig. Mazzeo, quindi mi disiscrivo dall'issue, purtroppo evidentemente non mi riguarda... Dividi e comanda funziona sopratutto in età digitale. Sperare di smuovere qualcosa con le percentuali di utenti di una ROM specifica che funziona solo su una ristrettissima cerchia di cellulari è veramente difficile (quanti utenti italiani ci saranno?). Vi faccio i miei auguri, spero vi ascoltino.

P.s. una issue più inclusiva e rispettosa di tutti i diversi punti di vista sarebbe stata gradita. Insieme avremmo potuto fare la differenza, mettere pressioni mediatiche e/o politiche perché un servizio pubblico funzioni a e per tutti.

@paolo-caroni una cosa non esclude l'altra, il problema che si sta avendo con grapheneos può essere il precedente per spingere anche su altri sistemi operativi. Le issue vengono aperte per problemi specifici, ma si può certamente generalizzare. In questo caso, diluire il problema su diversi OS non aiuta. Andiamo per gradi, il problema è certamente il metodo di verifica, non oggettivo e orientato alla convenienza di una multinazionale.

[thestinger]

@paolo-caroni GrapheneOS already supports every device meeting reasonable hardware security requirements. It also supports every device with first class alternate OS support. Pixels are currently the only devices with either of those in the Android world. Most Android devices have horrible security and putting another OS on it doesn't fix that. It also generally brings a lot of additional problems due to major security issues with LineageOS, and that includes misleading users with dishonest security claims, a false security patch level, etc. Users are being scammed by not just Android OEMs but alternate operating systems misleading them into believing they have basic privacy and security when they do not.

We do not want to be lumped in with insecure operating systems misleading users which roll back security from AOSP rather than improving. They're not the same thing, just like a device with no security patches for 6 years which passes Play Integrity is not the same as one with the current Android 15 release. Only a subset of security updates even get backported to older releases so anything older than Android 15 only has at best a subset, and most vendors skip a bunch of optional security features since they're only recommended.

As a side note: the stock OS, AOSP, GrapheneOS and other alternate operating systems for these devices are not ROMs. We don't use that terminology and don't want it referred to as a ROM. It makes our job helping people understand it and convincing them not to be biased against due to the many insecure hobbyist operating systems harder if people misunderstand what it is and misinterpret it as a modded OS when it isn't what it is at all.