Locker contract
NOTE: This is a proposal under review and is not implemented yet
TODO: review the names used. The names "proxy" and "seed" might not be ideal.
Motivation
The purpose of the locker contract is to add a layer of public key cryptography on top of existing contracts.
The protection against the replay attacks is usually done using a nonce. In Rholang, because of the parallelism, managing nonces is not simple, as it requires some form of synchronisation. For this reason we will use Rholang's unforgeable channels instead of "classic" nonces.
Locker Protocol
The locker protects the seed from the unauthorised users. Once the locker is created with a given public key and a given seed, only the owner of the corresponding private key can access the seed.
In the diagrams below the red processes are Rholang "unforgeable names" that need to be kept private.
Creating the locker
The locker factory is a contract that creates the lockers and is registered in the RChain registry.
Using the locker
The usage happens as described below:
the session is initiated as the owner opens the locker and obtains a proxy
the owner sends messages to the proxy, which forwards them to the seed
the session ends when the proxy goes out of scope and thus the seed is no longer available
The body of the message "getAccess" contains a private receive channel and a signature over this channel. The signature over the receive channel guarantees that it is owned by the one who also owns the private key. The channel name must be known only by the owner of the locker. An attacker who knows this name will be able to receive the proxy and get access to the locker content.
The session ends when the owner lets the proxy go out of scope. Beyond this point there is no way to access the locker content unless, of course, a new session is initiated.
Comment from @Former user (Deleted) via discord
Thoughts on the locker writeup
* I can't think of a specific attack, and there likely isn't one. But it occurs to me that by allowing the user to send in the return channel which replaces the nonce, we give the user/attacker some degree of control over what challenge needs to be signed.
* Maybe instead of "assume signature is valid" write "if signature is valid"
* Using the proxy gives a nice clear sense of session, but isn't strictly necessary (the locker could return the seed directly) and increases comm events. I don't have strong oppinions on that design choice either way, just calling it out.
* I love this. I'm really happy to see that the locker design pattern is gaining support rather than making every dApp reimplement the sig-verification.