Re: [webauthn] devicePubKey → supplementalPubKeys (#1957)

> Reason why I want to move this logic into the Passkey sync fabric is to keep implementation for RPs easy.

We continue to strongly recommend that regular sites use passkeys as is and don't bother with any supplemental key stuff.

Given that, your suggestion to do imports into enclaves is a good one in general(*) for security. (Although with the caveat that, taking two major platforms as examples, Android Keystore doesn't support the import of asymmetric keys at all, and Apple still supports devices that don't have a secure enclave.)

In your example, the provider is the one that seemingly blesses the import/export operation. The provider will need to authenticate the new device before instructing the old one to move keys into it and the details of that level of authentication are what needs to be included in the attestation. E.g. if the provider always does two-factor authentication, that's the sort of fact that sites may be able to use.

Now, to motivate using multiple keys:

We can't call keys that can be exported from a device "device bound", because they aren't! Storing them in the enclave protects against local attacks, which is great, but a site that wants device bound properties for compliance reasons isn't satisfied by any key that the provider can cause to be exported, even if it can only be moved to another hardware enclave.

So, to meet any device-bound requirements we need a second key.

And, if the provider is going to build a system that only moves keys between devices based on its attested two-factor authentication, then that precludes ever supporting moving passkeys between providers. But we don't want to preclude that because we don't want to exclude 3rd-party providers. And thus we split that key off and we end up with the supplementalPubKeys design.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1957#issuecomment-1709206663 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 September 2023 22:27:06 UTC