Over the past few months with Google/Chrome threatening the rollout of "Web Integrity API", Apple's "Private Access Tokens" having more or less silently been deployed, and Windows 11 effectively mandating a TPM to be able to enforce Measured Boot across the majority of the PC landscape, I have come to the realization that the fight to preserve freedom for those who want to participate in the digital world using software they themselves can control is on the brink of being lost for good. Because of these chess pieces being moved in position, platforms of the present and future will become ever more locked down on the quest to achieve air-tight "security" and "trust", as defined by some compliance boards' checkbox item list.
Originally, I had assumed and hoped that for those of us who would rather write, compile and run their own software would be given enough rope to use (much less convenient,) alternative means to at least perform essential transactions and use necessary services online - things that are necessary to participate in modern society (banking, filing your taxes, etc.), but not driven by DRM-inducing profit regimes. Alas, not even that does seem to be the case...
My government is beginning to phase out its phone-based federal ID service that authenticates requests using a combination of Username/Phone number, passphrase, and an SMS-based OTP code in favor of a mobile app. The proprietary app is available for Android and iOS devices that implement and pass Remote Attestation as decreed by Google and Apple.
Of course, my de-googled Android phone will never pass that particular attestation gate, and my government's ID app will therefore refuse to work on it. However, to also enable people without any kind of smarthpone to use the federal ID service on their PC that using the official ID app enables, there's a supported alternative: one can also use a FIDO "Level 2"-compliant hardware authenticator, that will enable the use of WebAuthn to authenticate its owner against the federal ID service.
Having taken a bit of a dive into the differences of available FIDO/U2F hardware tokens on the market today, I've stumbled over the dismaying fact that WebAuthn, too, integrates Remote Attestation as a first-party concept. Remote attestation seems to be, in fact, the one major thing that separates FIDO "Level 2" certified devices from others that fail to attain that level of certification. FIDO Level 2 devices contain a private key (that is shared between all devices of the same make and model), which had its public key/certificate component signed by a certifying CA. This is used to verify that the WebAuthn assertion keypair of user X has been generated on a genuine, attested "Yubico Security Key NFC" (for example), and not any other kind of WebAuthn-capable device.
This, however, is not the only Remote Attestation-related datum that may hitch a ride on your WebAuthn request to a remote service provider. The docs provided by Mozilla take care to enumerate `android-key`, `android-safetynet`, `tpm`, and others as potential fields in the transmitted `attestationObject`.
To me, this makes it abundantly clear that even the faux escape hatch provided by WebAuthn available will not delay, but to the contrary, actively enable privatized providers of "trust" to kill off Free Software (in way that is useful for participating in everyday life, like my custom-compiled build of Mozilla Firefox on my Archlinux system is right now) for good. Banks et al. will simply (have or want to) deny WebAuthn assertion attempts that cannot cryptographically prove they originate from a SafteyNet- or Windows-11-TPM-attested device, and that's that. No "login successful" for you, dear user, who you were daring enough to build Chromium yourself, or use a fork not having been granted with Google's holy blessings.
1 comment
[ 9.0 ms ] story [ 17.4 ms ] threadOriginally, I had assumed and hoped that for those of us who would rather write, compile and run their own software would be given enough rope to use (much less convenient,) alternative means to at least perform essential transactions and use necessary services online - things that are necessary to participate in modern society (banking, filing your taxes, etc.), but not driven by DRM-inducing profit regimes. Alas, not even that does seem to be the case...
My government is beginning to phase out its phone-based federal ID service that authenticates requests using a combination of Username/Phone number, passphrase, and an SMS-based OTP code in favor of a mobile app. The proprietary app is available for Android and iOS devices that implement and pass Remote Attestation as decreed by Google and Apple.
Of course, my de-googled Android phone will never pass that particular attestation gate, and my government's ID app will therefore refuse to work on it. However, to also enable people without any kind of smarthpone to use the federal ID service on their PC that using the official ID app enables, there's a supported alternative: one can also use a FIDO "Level 2"-compliant hardware authenticator, that will enable the use of WebAuthn to authenticate its owner against the federal ID service.
Having taken a bit of a dive into the differences of available FIDO/U2F hardware tokens on the market today, I've stumbled over the dismaying fact that WebAuthn, too, integrates Remote Attestation as a first-party concept. Remote attestation seems to be, in fact, the one major thing that separates FIDO "Level 2" certified devices from others that fail to attain that level of certification. FIDO Level 2 devices contain a private key (that is shared between all devices of the same make and model), which had its public key/certificate component signed by a certifying CA. This is used to verify that the WebAuthn assertion keypair of user X has been generated on a genuine, attested "Yubico Security Key NFC" (for example), and not any other kind of WebAuthn-capable device.
This, however, is not the only Remote Attestation-related datum that may hitch a ride on your WebAuthn request to a remote service provider. The docs provided by Mozilla take care to enumerate `android-key`, `android-safetynet`, `tpm`, and others as potential fields in the transmitted `attestationObject`.
To me, this makes it abundantly clear that even the faux escape hatch provided by WebAuthn available will not delay, but to the contrary, actively enable privatized providers of "trust" to kill off Free Software (in way that is useful for participating in everyday life, like my custom-compiled build of Mozilla Firefox on my Archlinux system is right now) for good. Banks et al. will simply (have or want to) deny WebAuthn assertion attempts that cannot cryptographically prove they originate from a SafteyNet- or Windows-11-TPM-attested device, and that's that. No "login successful" for you, dear user, who you were daring enough to build Chromium yourself, or use a fork not having been granted with Google's holy blessings.
See also:
A showcase of shard-db. Data from the Hacker News API. Refreshed every 15 minutes.
Source · Live DB stats