undefined

points

[-]

Preventing credential duplication is a requirement to achieve high level of assurance. One of its purpose is to limit the potential damage that can be done by attacks. If credentials are bound to hardware-bound keys, attackers will always need access to this key store to make any miss-use. If you don't prevent duplication, attackers may extract credentials and miss-use them at a 1000 places simultaneously.

by subscribed7 hours ago|

parent|

[-]

Okay, but Google certifies phones which are not updates for the last several years.

They can be trivially rooted, then they spoof the signature and get a pass in Integrity while being wide open for malware (or cooying the ID, ID presume).

by pwlb3 hours ago|

parent|

[-]

The documentation clearly outlines that there are multiple signals being analysed. Relying on play integrity alone is definitely not sufficient as you state.

by notpushkin11 hours ago|

prev|

[-]

I’ve just had another, completely stupid but not implausible, idea:

> a local internal WSCD, which is a component within the User device, such as a SIM, e-SIM, or embedded Secure Element,

So you could issue SIM-cards / eSIM profiles that only do signatures and nothing else. The app then connects to such eSIM (and you keep your main SIM/eSIM in another slot).

The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/

by Avamander9 hours ago|

parent|

[-]

> The less stupid variant is, of course, to get mobile operators to issue SIM cards with e-sign capabilities. Estonia has that, for example: https://www.id.ee/en/mobile-id/

It works great. Just keep in mind that newer phones are starting to deprecate physical SIM slots. At the same time certifying eSIM implementations to the same EAL level is an absolutely crazy task.