​
Key Management

Key Management is an extremely important aspect of the security. One thing to note here however is that how securely one can manage the keys is platform dependent, for example a mobile app with access to local keystore/keychain is a lot more secure compared to a web browser.

Our current client side key management is only on the web. Given the constraints, we do take adequate security measures on the browser.

The ephemeral keypair is encrypted and safely stored in the user’s browser using IndexedDB, an in-browser database. When a user initiates an action, such as signing and sending a transaction, the session token signs the transaction using the temporary key pair. The smart contract can then validate the transaction, confirming that the user’s wallet authorized the session token.\

  1. Generate a random keypair using web3.Keypair.generate()
  2. Generate a random encryption key
  3. Using the encryption key encrypt the generated keypair.
  4. Store the encrypted key in IndexedDB

​
Security Model

1. The session keys are like your JWT Token adapted to web3

2. These keys have an expiry and a scope

3. Once the key has expired they can’t be reused in the target program. A new session token is to be generated.

4. They are also designed to be revokable, so that in the worst case if something wrong happens the attack surface is limited to the ephemeral keypair and the assets contained in them. i.e 0.01 SOL

​
Note on IndexedDB

Web Browser is an extremely adverserial environment, no amount of security is enough there, right from cookies to session to extension’s sandbox.

Attackers could always inject arbitrary code via XSS or malicious extension. This is why users are discouraged from storing serious funds in a browser wallet, they are only for day to day expenses and it is really important to establish the distinction that Session Keys are not burner wallets.

However, majority of web3 today is on web browsers and that’s how users primarily interact with other dApps. Given the constraints of today, we have to design around them and harden them via other means.

  1. Drastically reduce the scope of what’s possible with an ephemeral signer, they are highly context and use case specific.
  2. This is similar to the approach to JWT in a typical client server architecture in web2.
  3. For example the session or JWT tokens on Facebook, twitter or even banking website could be vulnerable to the same issue. The way they address is this by limiting the scope of what you can do with a token, have intelligent systems in place to revoke them and further introduce 2FA for suspicious activity.
  4. We follow a similar model to limit the scope, we are also working on adding intelligent revocation systems which can revoke a compromised token as soon as we witness a malicious transaction like out of scope usage etc. The absolute worst case scenario in terms of loss of funds is the 0.01 SOL topped up to pay for the gas fee.
  5. Also**, developers can work around this today by pairing it with a gasless relay like octane and setting topUp to false**. However, we don’t have a seamless way to do it directly from our SDK yet, although it is on our roadmap.

Was this page helpful?