Creating a Key
When a user attempts to use OpenSigner from a new device, they must call
the /v1/devices/init
method of the hot storage. The response will contain
a next_action
field with one of these values:
"REGISTER"
: The user has not registered a key yet, therefore it must go through the sign up process."RECOVER"
: The user has registered a key, therefore it must go through a login process.
User with Password Recovery
When using password-based recovery, the entropy used to encrypt the recovery share is completely provided by the user. This ensures the system remains non-custodial and users are in control of their keys.
User with Automatic Recovery
When using automatic recovery, the entropy is managed by the cold storage service. To secure the recovery share, an encryption key is generated in the cold storage, which is then split into 2 shares with a required quorum of 2 for reconstruction. One share kept by the cold storage, and another one is given back to the developer. The developer must secure this encryption share at all times, and it should never be exposed in the client side.
When a request to secure a new recovery share is made, the developer must POST
to the cold storage /project/encryption-session
endpoint with the encryption share.
This endpoint will return an encryption session ID, which the developer must provide to the user during the signup process. This session ID is valid for one time use.
While adding complexity, it allows users to recover their keys without needing to remember a password.
For the system to remain non-custodial, the provider must differ from the cold storage provider.
2FA with Automatic Recovery
User with Passkey Recovery
OpenSigner uses the passkey Pseudo Random Function (PRF) extension to derive an encryption key to symmetrically encrypt/decrypt the cold share.
The user will only need to follow their authenticator's flow for passkey creation/validation. OpenSigner will remember which passkey it should ask for whenever a user wants to recover their cold share.
Both the passkey's private key and the cold share are safe in this scenario, too:
- The passkey's private key cannot leave the authenticator device
- The cold share is encrypted and decrypted client side