Safer key storage in the browser

[joepio]

The decentralized architecture of Atomic Data dictates that changes to information (Commits) are signed using the private key of an Agent (user). This means that, if we want to edit things from the browser, the browser app needs to sign commits using that private key.

Attack risks of current implementation:

• Thief could wait until user leaves desk, go to agent settings, copy the secret / mail it / send it / photograph it. This could be preventable by making the secret only copy-able on creating the Agent, and locking it afterwards.
• Thief could check localStorage on same browser, even after the session.
• Thief could navigate the JS state / the react tree and find the private key value

Possible solutions

I want both a good UX, and a safe solution. Some thoughts:

• Storing the key anywhere where JS has access (localstorage, indexedDB), means that all libraries of Atomic Data Browser have to be trusted.
• The CryptoKey browser API seems interesting. It saves to indexedDB, but in a way that the key itself cannot be retrieved - it can only be used for signing things. I don't think it supports ed25519 signatures, which kind of sucks, because that's what I'm using in this project and the rust implementation of atomic data.

Some resources to check out::

• https://pomcor.com/2017/06/02/keys-in-browser/
• https://www.w3.org/TR/WebCryptoAPI/
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API
• https://www.w3.org/TR/IndexedDB/
• https://www.boxcryptor.com/en/blog/post/building-an-app-with-webcrypto-in-2016/
• https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5
• https://blog.engelke.com/2014/09/19/saving-cryptographic-keys-in-the-browser/

[joepio]

• Curve25519 (including ed25519) support is currently being tested in Chrome and being worked on in FireFox. If this is implemented, we could probably switch to the web.crypto API