reSee.it - Tweets Saved By @Paul_Reviews

@Paul_Reviews - Paul Moore - Security Consultant 

Let's shift focus and explain why the #EU #AgeVerification concept is fundamentally flawed. Assume: 1. The production app is released. 2. It's 100% secure, 100% private (fantasy land, but stick with me) 3. It cryptographically challenges every step, including hardware attestation which requires a physical device. 4. Every single other attack vector in the surrounding environment is somehow magically patched. aka - it's working exactly as intended/designed. It does not protect against a relay attack. This is a threat they considered and somewhat addressed here: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/architecture-and-reference-framework-main.md With the current design, there's nothing preventing someone running a verification-as-a-service; a remote Android device which returns a valid attestation. Remember, it's not returning "I am over 18", it returns "someone is over 18". Neither the verifier, nor the app has any way to link the session ID to a physical device. Their own docs state this clearly: Remote Cross-Device Presentation: "Note that the Wallet Instance does not see any difference between the cross-device flow and the same-device flow. In both cases, it receives an OpenID4VP-compliant presentation request over the Wallet Instance-platform API described in the previous section." This is a known & well-understood attack vector in all remote credential presentation models; it's just not mitigated in this one... primarily because they can't. CTAP 2.2 won't work with all app flows, hardware attestation doesn't mitigate relay attacks, on-demand liveness detection would be too intrusive & potentially privacy-invasive & timing calculations don't reveal anything useful... all the available options to resolve this break the core design; completely anonymous age verification. The Architecture & Reference Framework (ARF) is technically sound in some respects. They considered external threat actors and discussed solutions to mitigate them, including ZKP. However, the EC applied the wrong threat model, thus arriving at the wrong conclusion. Yes, you need to protect against malicious verifiers, phishing sites, session hijacks, data brokers et al... but that's addressing external threats, it doesn't protect the architecture from the user itself. In virtually every other scenario, the user and system's interests are aligned; protect my biometric asset at all costs. Specifically for age verification, most users do not want to present ID simply to access a website, so whilst the system may adequately protect from external threats, if the user wants to bypass the system, they can... and the architecture doesn't consider this. Every single applied mitigation assumes the user is the protected party, not the threat actor. To those people claiming "it requires physical access to the device and root, this is BS/hyperbole", you too applied the wrong threat model & completely missed the point. These disclosures demonstrate that you, the user, are the threat actor they haven't considered. You have your device. You can root your device. You can create a chrome extension, just as I did. Ironically, it's precisely those under 18 who can't pass verification who are motivated to bypass it. So where does that leave us? A system which replaces "I am over 18" with "someone is over 18", with absolutely no guarantee that it's true... which is the entire purpose of the app.

@Paul_Reviews - Paul Moore - Security Consultant 

Bypassing #EU #AgeVerification using their own infrastructure. I've ported the Android app logic to a Chrome extension - stripping out the pesky step of handing over biometric data which they can leak... and pass verification instantly. Step 1: Install the extension Step 2: Register an identity (just once) Step 3: Continue using the web as normal The extension detects the QR code, generates a cryptographically identical payload and tells the verifier I'm over 18, which it "fully trusts". This isn't a bug... it's a fundamental design flaw they can't solve without irrevocably tying a key to you personally; which then allows tracking/monitoring. Of course, I could skip the enrolment process entirely and hard-code the credentials into the extension... and the verifier would never know.

@Paul_Reviews - Paul Moore - Security Consultant 

Hacking the #EU #AgeVerification app in under 2 minutes. During setup, the app asks you to create a PIN. After entry, the app *encrypts* it and saves it in the shared_prefs directory. 1. It shouldn't be encrypted at all - that's a really poor design. 2. It's not cryptographically tied to the vault which contains the identity data. So, an attacker can simply remove the PinEnc/PinIV values from the shared_prefs file and restart the app. After choosing a different PIN, the app presents credentials created under the old profile and let's the attacker present them as valid. Other issues: 1. Rate limiting is an incrementing number in the same config file. Just reset it to 0 and keep trying. 2. "UseBiometricAuth" is a boolean, also in the same file. Set it to false and it just skips that step. Seriously @vonderleyen - this product will be the catalyst for an enormous breach at some point. It's just a matter of time.

@Paul_Reviews - Paul Moore - Security Consultant 

.@vonderleyen "The European #AgeVerification app is technically ready. It respects the highest privacy standards in the world. It's open-source, so anyone can check the code..." I did. It didn't take long to find what looks like a serious #privacy issue. The app goes to great