Architecture & Security

​

Authentication and JWT

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 encrypted using AWS KMS. A developer could validate Dynamic’s JWT using a standard JWKS endpoint to retrieve the public key. Unauthenticated requests or requests with an invalid JWT for creating or accessing an embedded wallet will be rejected by the Dynamic API.

​

Wallet private key storage

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 a 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.

​

Iframes

For data that must never be exposed except to the end-user i.e. private keys, it is sent encrypted through an API call to an iframe in the end-users browser, and only decrypted 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.

​

Recovery of Wallets

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 support regaining access. Adding additional recovery options through other authentication methods.

Dynamic allows users to link other verified credentials to their account such as phone number, Google or other Social Media login methods. If users have multiple credentials assigned, they can be used to recover their wallet if a single method is lost.

Retrieving Wallet Key if Dynamic or Application Developer are down. (Coming soon) Dynamic will be adding additional fall back support in case an application developer or Dynamic services are down. A custom URL will be available so end-users can log in and export their private key.

​

Trusted Execution Environments (AWS Nitro Enclaves)

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 AWS KMS.

​

Sessions, Signatures, Transactions

Developers can configure Dynamic-powered embedded wallets to require an optional second level of authentication by the end user before performing an action. This is referred to as transactional MFA. There are two transaction MFA methods that we currently support: passkeys and email one time codes.

If transaction MFA is not enabled, 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.

Transactions requests are signed by the end user’s wallet authenticator and validated by AWS KMS. Upon successful validation, the end user’s private keys are used to sign the actual transaction within AWS KMS’s secure enclave.