2024-09-05 16:59:32 +00:00
|
|
|
---
|
|
|
|
title: Recovery
|
|
|
|
layout: default
|
|
|
|
permalink: /recovery.html
|
|
|
|
---
|
|
|
|
|
|
|
|
# Recovery
|
|
|
|
|
|
|
|
Distrust performs recovery ceremonies 4 times a year, and paying customers can
|
|
|
|
be part of these recovery ceremonies for free.
|
|
|
|
|
|
|
|
During the quarterly ceremony, Distrust will publish a signature of the latest
|
|
|
|
bitcoin block to prove control of the decryption keys.
|
|
|
|
|
|
|
|
If a client requires an expedited recovery, additional fees apply (available
|
2024-09-06 17:54:15 +00:00
|
|
|
on the [pricing page](/pricing.html)).
|
2024-09-05 16:59:32 +00:00
|
|
|
|
|
|
|
## Recovery Policy
|
|
|
|
|
|
|
|
The recovery policy is a document which is a set of rules or conditions under
|
|
|
|
which the recovery may be made. The different conditions can be sufficient on
|
|
|
|
their own, or a multitude of them has to be satisfied in order to constitute a
|
|
|
|
valid recovery request.
|
|
|
|
|
|
|
|
The main conditions of a Recovery Policy are:
|
|
|
|
* Time lock until year/month/day
|
2024-09-30 21:39:00 +00:00
|
|
|
* n of m cryptographic signatures (FIDO2, PGP)
|
2024-09-05 16:59:32 +00:00
|
|
|
* n of m KYC verifications
|
|
|
|
|
|
|
|
At least one of cryptographic signature or kyc verification is always required.
|
|
|
|
One may choose to require both.
|
|
|
|
|
|
|
|
If you are interested in different or custom rules, please reach out to use at
|
2024-09-06 17:54:15 +00:00
|
|
|
sales@distrust.co.
|
2024-09-05 16:59:32 +00:00
|
|
|
|
|
|
|
## Time Lock
|
|
|
|
|
|
|
|
Time locks allow the user to set a date after which the recovery will be
|
|
|
|
possible. The data will not be recoverable until the day after the lock date.
|
|
|
|
|
|
|
|
## Cryptographic Signature Verification
|
|
|
|
|
2024-09-30 21:39:00 +00:00
|
|
|
This method supports several cryptographic signature schemes including PGP and
|
|
|
|
FIDO2. One may register as many as 32 public keys, and set how many of those
|
|
|
|
keys are required for a valid recovery request, for example, 3 of 7.
|
2024-09-06 17:54:15 +00:00
|
|
|
<!-- TODO: add BTC and ETH when it's supported -->
|
2024-09-05 16:59:32 +00:00
|
|
|
|
|
|
|
## KYC Verification
|
|
|
|
|
|
|
|
KYC Verification is based on verifying both the individuals identity and their
|
|
|
|
intent to recover data.
|
2024-09-06 17:54:15 +00:00
|
|
|
* The data is gathered at the beginning of the relationship.
|
|
|
|
The [Distrust Disaster Recovery Wizard](todo) can be used to aid you in the
|
|
|
|
process. Distrust will verify your data once it's submitted during a video chat.
|
|
|
|
* During recovery, the identity of authorized individuals is verified in person
|
|
|
|
by Distrust staff or legal council representatives. They will verify the
|
|
|
|
individual in person using visual verification, ID documentation, and record a
|
|
|
|
video of the individual's intent to recover which is then cryptographically
|
|
|
|
signed by Distrust.
|
|
|
|
* The KYC verification is threshold based, so one may list any number of
|
2024-09-05 16:59:32 +00:00
|
|
|
individuals, and require any number of individuals to express intent to recover.
|
|
|
|
For example, the total number of individuals may be 7, and 3 of them are
|
|
|
|
required to initialize the recovery process.
|
2024-09-30 21:39:00 +00:00
|
|
|
|
|
|
|
## When and How The Policy Can Be Changed
|
|
|
|
|
|
|
|
A policy can only be updated by providing the authentication required to recover
|
|
|
|
the data.
|
|
|
|
|
|
|
|
A policy can be defined to be valid:
|
|
|
|
|
|
|
|
* After a specific date
|
|
|
|
* Between specific dates
|
|
|
|
* Before a specific date
|
|
|
|
|
|
|
|
Additionally, the policy can be made updateable, or non-updateable.
|
|
|
|
|
|
|
|
There is also a cooldown period, which requires a specific amount of time to
|
|
|
|
elapse before the policy is updated upon request.
|
|
|
|
|
|
|
|
For example, one may choose to create a policy that's only in effect after a
|
|
|
|
specific date, and can be updated, creating a lock on the data and the ability
|
|
|
|
to update until after that date. Conversely, a policy can be created which is
|
|
|
|
only valid up to a specific date and can not be updated, effectively expiring
|
|
|
|
after that date, making the data non-recoverable.
|