Repository navigation
Verifying messages signed by a passkey smart-account wallet #613
Description
Our wallet signs messages with a WebAuthn passkey (P-256) over a tagged hash of the message, and connects to dApps through Khie. Its signType is CellulaAccount, which Signer.verifyMessage does not know: it resolves undefined, so the CCC App's Verify says "Signature invalid" for a valid signature.
The check is offline, like verifyMessageJoyId: the identity carries the public key, the signature carries authenticatorData, clientDataJSON and the DER signature, and the check is the usual WebAuthn one with the tagged hash as the challenge. Binding the key to an address stays with the app, as for JoyID sub keys.
Would you take a new SignerSignType and verifier next to the existing ones (we would send the PR with tests), or would you rather keep wallet-specific verifiers out of core?
Activity
Hanssen0 commentedon Oct 28, 2026
This sounds like a disjointed component for CCC: we would have the signature verification functionality but lack an interface for the actual signing process. Given this, I don’t believe that simply adding a new
SignerSignTypeis a good approach. Furthermore, is there truly a requirement for all CCC applications to support the verification of this specific new signature type?Additionally, I’ve recently come to the view that, given CKB’s support for arbitrary cryptographic algorithms, attempting to incorporate every possible signature verification method into CCC (for off-chain use) might be a misguided objective. A potential alternative similar to the approach used in BIP 322, which leverages virtual transactions to verify message signatures, might offer better generalisability. However, I have no immediate plans to pursue this idea further.
LusoCryptoLabs commentedon Oct 28, 2026
Makes sense, a verifier without the signing side would be half a feature. We'll keep it in our own SDK for now. A BIP 322 style check would cover our lock without anything specific to it, so if you pick it up, I'm happy to test it with the smart-account lock on testnet.
LusoCryptoLabs commentedon Nov 4, 2026
Following up on the BIP 322 idea: we built it as Ward, https://github.com/LusoCryptoLabs/ckb-ward (MIT).
The virtual transaction has one input at an out point that cannot exist, derived from the lock hash and the message, and one output carrying the message. The verifier resolves that input itself (capacity u64::MAX, so a capped key cannot prove an account), reads the cell deps live from the chain and runs the lock in ckb-debugger.
No change in CCC was needed: the private key and JoyID signers sign it as is with
prepareTransactionandsignOnlyTransaction. Tested on testnet with secp256k1, JoyID (signed in the JoyID app) and our smart-account lock, with multisig, Omnilock and a Nostr lock in an earlier prototype; secp256k1 and JoyID also on mainnet.Nothing to ask. If a template helper would be useful in CCC, happy to open a PR.