KeyCards vs User Wallets

We introduce a seperate KeyPair for the Store system, called a KeyCard, which is only used to create eth_typedData_v4 signatures for the Store system. This is to avoid the need to sign with the User Wallet, which is a more convoluted and risky operation since it involves prompting the Wallet Software for verification. The KeyCard can be used without any direct user interaction since they are just used for signature creation, not writing to contracts/spending ETH.

Musing on Storage

We are assuming KeyCards are generated locally and saved separately from the wallet, accessible by our software, which is running in the browser. While the KCs are bound in access to the Store and don’t need to hold any ETH themselves, there still is a security risk of impersonation and malicious access to the Store system if they leak. The following presentation gives a good overview of the different schemes to protect such data, namely localStorage and Web Crypto API:

Storing Cryptographic Keys in Persistent Browser Storage 2017.pdf

This Article is also good. It leads down a similar way, using a password in tandem with WebCryptoAPI to lock away JSON data in a pretty comprehensive way (stored at rest and not accessible from xss/injection attacks).

Now, introducing another password would defeat the purpose of the KeyCard, which is blessed via the Users Wallet to begin with. Ideally we would find a way to retrieve the KeyCard key from the WebCryptoAPI with help of the Wallet maybe, like storing a symmetric key, or the keycard secret material itself at that point.

For the time being and first proof-of-concepts we will use plain localStorage.