I’m long overdue to comment here, but better late than never. First of all, kudos to @rishotics and the rest of the Banana SDK team for leading this conversation. As the maintainer of Passkeys[dot]is I see the potential of the tech to be applied in crypto despite some caveats already identified.
For me, there are a couple of minimal requirements needed for this setup to work:
-
Multi-sig smart account - Although Passkeys are an ideal “kickstart” mechanism to onboard a user, it has a few flaws already pointed in the thread that make it unsuitable to make it a long-term solution as the only signer setup within a smart account. Here I envision something like a Safe that can be initially provisioned by a Passkey, yet can add other signers and even remove itself if needed.
-
Pure client implementation - Right now we are trying to go through the traditional
webauthnworkflow, which involves a server that creates a request and pairs it against the user name passed as part of the key creation params. However, relying on a server to “allow” usernames instead of passing the ECDSA signature might create a unwanted centralised point of failure not required for a smart wallet. -
Lazy deployment - Because of the way Passkeys work, we can generate a public key during the generation of the first instance of the account. This key can then be passed to a contract and an
entrypointto provide a smart account address. We could use this address from day 0 until we would want to deploy it, allowing us minimal engagement with it until needed (e.g. airdrop to the account). Seems like @nlok5923 has already a way to have this address available. -
Minimal gas cost - Even on L2s, the current cost of a
secp256r1signature verification is circa 1.2m, which is a pretty penny. There are multiple groups exploring the reduction of this cost (gas bad) including doing Elliptic-curve optimisations (see Ledger’s team presentation for EthCC '23), but nothing is “official” yet. Even my own demo on github (passkeys-webauth) has this cost. -
Audit - At the end of the day we are verifying a ECDSA signature manually, since current’s Ethereum
ecrecoveris unable to parse this curve. Thus, it would be beneficial to the community to rally over an audit around a standard that can be used across the industry and benefit smart wallet creators as equal instead of building yet another lego block.
If we can tackle these points, I believe the other concerns can be partially or fully mitigated. For instance, we can work around Apple’s iCloud Keychain native syncing, and trusting their HSM setup provides a similar attack vector than, let’s say, a Web2 OAuth login like Web3Auth. Even then I would argue that Passkeys provide a better alternative, since they can work offline and w/o any server interface, as long as navigator.credentials is supported by the browser.
Now to answer some questions:
-
MicahZoltu - The keys are stored in the device and synced to iCloud for iOS devices (other devices do not have automatic cloud storage). In iOS, you can’t enable Passkeys w/o iCloud Keychain enabled, but you can remove the key from iCloud once it’s synced, and only from iCloud. In terms of security, in theory, and based on statements made by various Apple spokespeople, Apple stores user’s credentials KEK’s in their HSMs, which would be wiped after 10 failed attempts to the user’s iCloud. Thus, even on the case of a governmental seizure, they would technically be unable to share the key. Of course, metadata and other IP related information, even to the point of device fingerprinting, would still be likely possible. plusminushalf shared more on this in a previous post.
-
drortirosh yes, this is correct. What’s even funnier, is that the actual signing payload doesn’t matter. Because of the way
webauthnworks, we always sign on top of theauthenticatorDataand can not make use of the payload. So, the only thing we can learn from this request is “it has been signed”. It doesn’t matter what the user signs, just that it signed something at X point in time. -
Victor928 it would be safe to assume that all transactions through a Passkey-based smart account would have a minimal requirement of the
secp256r1verification, currently at 1.2m cost on a naive implementation, some research pointing it going down as low as 300k-60k (see Ledger’s presentation for EthCC '23 on this). -
Joseph under a single 1-out-of-1 naive implementation of a Passkey-based smart account, there’s no key revocation, and thus, would be awful if you need to rotate. Right now, the only way to “share” a Passkey is physically via Airdrop to a contact nearby, or using a roaming authenticator (e.g., Yubikey). Thus a multi-sig setup would likely be preferred. Other comments were already answered by @rishotics in the last post.
(NB: Someone with more rights kindly update to mention the people tagged).
