Dead Man's Switch


#1

We recently added an article about the “dead man’s switch” to our solutions series–https://blog.enigma.co/tell-no-tales-decentralizing-a-dead-mans-switch-6217e2f4361b

image
Simplified diagram of DMS components in an Enigma implementation

A dead-man’s switch on Enigma would have a secret contract , which is used to store the secret information. A contract on Ethereum would function as the proof of life /check-in, and would have incentivize “time-keepers” to monitor that the user continues to check-in. The “secret contract” can replace both the publisher and the revealers in the previous two models. Time-Keepers, unlike revealers, do not have the option to collude off-chain as they never have access to the decryption secret. Additionally, the secret contract enables straightforward private recipients.

Simple threat model for DMS:

One possible data flow would be:

Initiation

  1. User encrypts all inputs to the secret contract using Enigma.js library: their message, the recipient, the desired check-in interval.

  2. User submits encrypted inputs to the secret contract on Enigma, and submits a hashed copy of these inputs to the Enigma Contract on Ethereum (and creating a Task Record for this contract).

Time-Keeping

  1. The user funds a new Ethereum contract, the “time-keeping contract” and then passes proof of that signed transaction to the DMS secret contract Enigma network. The user must repeat this within the specified interval: submitting a transaction to this contract, and then submitting a proof of this transaction to the secret contract on Enigma. This functions as the “check-in”, with timekeeping established by block.time. Similar to Kimono, this game incentivizes time-keepers to periodically sign the block-time and submit this data to the secret contract on Enigma.

  2. User ceases to check in within the specified interval. Any other user is able to submit a signed transaction block-time to the secret contract. When the elapsed time is greater than the interval specified by the user, the time-keeper receives the reward and the message within the secret contract is able to be released.

Message Release

  1. If private recipient is specified, that user may submit her public encryption key to the secret contract and receive the message exclusively.

In the described scenario, the time-keepers lose the ability to collude off-chain, as none have a share of the secret message. The time-keepers may not be necessary if the intended recipient knows about the contract and is incentivized herself to check it (i.e., in a trust). The time-keeping game should be customized around the specifics of the application. Another variation is to use the secret contract as part of the secret-sharing scheme. This implementation for key-management has already been explored in academia — see paralysis proofs. Enigma provides the infrastructure for solutions such as these — the proposed data flow is only a starting example, and we look forward to feedback and improvements on this scheme.

To recap, the interesting contributions a DMS built with Enigma adds are:

Private Disclosures

Unlike both examples, Enigma enables the payload to be encrypted for an individual or group of recipients rather than the entire world. By submitting the address of the intended recipient to the secret contract, when the time comes for the secret to be disclosed, the recipient can submit their public key to the secret contract and receive the secret that only they can decrypt. This is relevant for scenarios where specific people are the desired recipient of the secret, rather than the public. With Enigma, information about whether a secret has been exposed, how frequently the user checks-in, and the address of the private recipient are all encrypted inputs to the secret contract. This improves overall privacy, because not only is the secret information private, but the metadata associated with this mechanism is also private.

Reducing trusted parties

The “publisher” on Kill Cord as well as the “revealers” on Kimono both provide attack surfaces for a counterparty. Recall the two attack vectors of false positives and false negatives . In Kill Cord, compromising the publisher could give an attacker early access to the decryption key. Attacking the user’s connection to the publisher could also prevent the publisher from publishing the key to the smart contract. Kimono relies on staking incentives to prevent collusion amongst revealers, an approach which is insufficient if the reward for collusion is very high (say, the private key to an exchange or high-balance wallet!)

Complex Conditional Disclosure

Enigma enables private inputs for both the creator of the switch and the intended recipient. Imagine a switch conditional on some other criteria being fulfilled, aside from the user’s apparent demise — for example, allow Alice to access this material, but only if she is accessing it from within a certain region. Or, perhaps to anyone accessing material from within a certain region, like a scavenger hunt. Additionally, the switch can set up to be triggered by more than simple inaction or failure to check-in. Thus, the DMS model can be extrapolated beyond wills, insurance, and trusts, and could also potentially be used in advertising, gaming, or other situations.

Thoughts? Particularly curious about methods for incentivizing the time-keepers in a way that prevents a sybil attack (possibly an interval-based reward? This would also prevent the receipt of an award “proving” that the dead man switch had flipped. Instead of rewarding whoever is first to check after the interval has passed, a la KImono, there is a monthly/yearly/whatever reward (loaded by the initial owner for however long they believe the system should run) to whoever is first to “submit time” in that interval.


#2

Great job on this, Ainsley! Thanks for the thorough write up and analysis.

I don’t completely understand the Time-Keeping section. What is a signed transaction block-time? Who is it signed by, and how is the block.timestamp used in the signed message?

My confusion lies mainly with the use of the time-keeping contract to ensure that timekeepers are submitting the correct time. I can’t think of what a time-keeper could send to the DMS secret contract on the Enigma network that would prove that they obtained the block.timestamp from the time-keeping contract on the Ethereum network, or that they called the time-keeping contract and got the block.timestamp as a return value.


#3

Thanks! It’s a really exciting topic.

re: timestamping, good question. We’re actually still discussing if this is the best approach, so it’s subject to change. But essentially, one way to do it is to have the time-keeping contract submit a hash of it’s result to the Enigma Contract on Ethereum. That way, when the time-keeper user sends the block.timestamp to the DMS contract on enigma, it checks the data to ensure it corresponds to the expected value in the Task Record on the Enigma Contract (on ethereum).

This solution isn’t good for fine grained-time for a few reasons, but would probably be acceptable at least for prototype DMS apps.