End users must be logged in and issued a JWT by Dynamic’s backend API to create and use embedded wallets. This JWT acts as an authentication token allowing the browser to identify a logged in user to the backend. The JWT is signed by a private key that is stored and encrypted using our KMS. A developer could validate Dynamic’s JWT using a standard JWKS endpoint to retrieve the public key. The Dynamic API will reject any request to create or access an embedded wallet if it is unauthenticated or contains an invalid JWT.
All private keys are encrypted and never stored in raw form. End user private keys are not accessible to Dynamic, the developer, or the key management service. All decryption functions to use private keys must be user-initiated and done so in secure enclaves (i.e Trusted Execution Environments).Dynamic does not sign transactions on an end-user’s behalf, and end-users have to take explicit actions to sign transactions. Dynamic also does not offer APIs to sign transactions for end-users.
Data that must remain strictly confidential (such as private keys) is transmitted in encrypted form via an API call to an iFrame running in the end user’s browser, and is decrypted only on the client device. This ensures that at all times, no one but the end-user will ever be able to access that data, and only on their own device.
Recovering a wallet is tied to the authentication method enabled by the application developer. For example, if an application developer allows login with email, the user can always recover their wallet by having access to their email. They can use standard email recovery procedures from their email client to regain access.Dynamic allows users to link other verified credentials to their account such as phone number, Google account, or other Social Media login methods. If users have multiple credentials assigned, they can each be used to recover their wallet.The ability to retrieve keys if Dynamic or the application developer are down is available with our new embedded wallets (using MPC). You can give a user the ability to back up a second share to Google Drive/Icloud. We also provide the ability for you to store a share for fully independent recovery.
A core component of Dynamic-powered embedded wallets is the isolation of any sensitive key material or credentials. All sensitive operations that involve an embedded wallet’s private key occur within secure AWS nitro enclaves.Additionally, token private keys never exist outside of the AWS secure enclave unencrypted. There is no avenue of unilateral access to the secure enclave from any employee of Dynamic, nor our KMS.
By default, Dynamic allows the end-user to use session keys to authenticate and interact with their wallets.Session keys are implemented by creating api keys in the developer website and registering those as valid authentication methods within a secure enclave. Those session keys are retained by the end-user on the developer website and are never sent to Dynamic.Session key registration requires a valid Dynamic JWT, which is obtained via a successful user authentication. Once the session keys expire, they can no longer be used to authenticate into a Dynamic-powered embedded wallet. If you are using our SDK, session keys are automatically refreshed when expired as long as the JWT is valid.Transaction requests are signed by the end-user’s wallet authenticator and validated by our KMS. Upon successful validation, the end-user’s private keys are used to sign the actual transaction within the KMS’s secure enclave.Note that for added account level security, you can enforce TOTP using an authenticator app.
