> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
Trusting your HSM vendor is a requirement if you don't want your keys to be exportable, and there's much less risk in doing so compared to trusting Apple for other things like secure communications (iMessage is e2ee but doesn't tell you when your peer changes/adds keys, plus unencrypted backups are on by default).
Sure, I agree that RPs should not use attestation in most cases. (Enterprise use—where the company has issued specific hardware to clients—is an obvious exception.)
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
> Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
https://www.imperialviolet.org/2019/01/01/zkattestation.html