247 lines
10 KiB
HTML
247 lines
10 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="{{ page.lang | default: site.lang | default: en }}">
|
|
{%- include head.html -%}
|
|
|
|
<body>
|
|
<div class="container">
|
|
|
|
{%- include header.html -%}
|
|
|
|
<h1>Recovery Policy Wizard</h1>
|
|
<p>
|
|
This wizard will assist you in constructing the set of rules, also
|
|
known as the Recovery Policy, which specifies under which conditions
|
|
your data can be recovered. The policy has been designed with flexibility
|
|
in mind in order to accommodate different use-cases and threat models.
|
|
</p>
|
|
|
|
<form id="wizard-container" onsubmit="generatePolicy(event)">
|
|
<section>
|
|
<h2>Time Based Rules</h2>
|
|
<p>
|
|
Time based rules allow specifying during which time period the policy is <b>active</b>.
|
|
In order to request data recovery, a policy has to be in an active state at the time the
|
|
request is made to recover data. If a policy is <b>mutable</b> (allowed to be updated),
|
|
it can also only happen while the policy is in an active state, and is done by creating
|
|
a new policy which will take place of the old one.
|
|
|
|
The dates are always interpreted in UTC (Coordinated Universal Time), at 12:00AM of the
|
|
selected date.
|
|
|
|
The two dates which are configurable, <b>from_date</b> and <b>to_date</b> allow for
|
|
the following configurations:
|
|
</p>
|
|
|
|
<label for="policy_valid_after_date"><b>from_date</b></label>
|
|
<input type="date" id="policy_valid_after_date" name="policy_valid_after_date">
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<label for="policy_valid_to_date"><b>to_date</b></label>
|
|
<input type="date" id="policy_valid_to_date" name="policy_valid_to_date">
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<div class="timeline">
|
|
<div id="segment-left" class="segment"></div>
|
|
<div id="segment-middle" class="segment"></div>
|
|
<div id="segment-right" class="segment"></div>
|
|
<div class="marker marker-1">
|
|
</div>
|
|
<div class="date-container from-date-container">
|
|
<span id="from-date-arrow"></span>
|
|
<div id="from_date"></div>
|
|
</div>
|
|
<div class="marker marker-2">
|
|
</div>
|
|
<div class="date-container to-date-container">
|
|
<span id="to-date-arrow"></span>
|
|
<div id="to_date"></div>
|
|
</div>
|
|
</div>
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<label for="policy_mutable">
|
|
Is the policy editable (mutable) while it's active?
|
|
</label>
|
|
<br>
|
|
<select required name="policy_mutable" id="policy_mutable">
|
|
<option disabled selected value> -- select an option -- </option>
|
|
<option value="true">Yes</option>
|
|
<option value="false">No</option>
|
|
</select>
|
|
</section>
|
|
|
|
<hr class="divider">
|
|
|
|
<section>
|
|
<h2>Remote Recovery via Cryptographic Signatures</h2>
|
|
<p>
|
|
This type of recovery makes it possible to recover data
|
|
remotely by providing cryptographic signatures to show
|
|
intent of recovery. We support all widely used types of
|
|
signatures such as OpenPGP, ETH, BTC, etc. (Contact us if
|
|
you would like us to support other protocols)
|
|
</p>
|
|
|
|
<label for="remote_available">Can recovery be authorized using threshold based cryptographic
|
|
signing? *</label>
|
|
<br>
|
|
<select required name="remote_available" id="remote_available">
|
|
<option disabled selected value> -- select an option -- </option>
|
|
<option value="true">Yes</option>
|
|
<option value="false">No</option>
|
|
</select>
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<div id="remote_available_container" class="hidden">
|
|
<label>
|
|
What threshold would you like to use for the
|
|
cryptographic signing recovery method? (2/3, 3/5, 4/7,
|
|
etc.)
|
|
</label>
|
|
<br>
|
|
<input type="text" id="remote_threshold" name="remote_threshold">
|
|
<div class="error-field" id="remote_threshold_error"></div>
|
|
<p>
|
|
Please select public keys which can be used for recovery.
|
|
These keys should be valid public keys for whichever
|
|
protocols you would like to use. You may use a mix of
|
|
protocols. Ensure each file only has 1 key:</p>
|
|
<input type="file" id="pub_keys" name="files[]" multiple>
|
|
<br>
|
|
<div class="error-field" id="pub_keys_error"></div>
|
|
</div>
|
|
|
|
</section>
|
|
|
|
<hr class="divider">
|
|
|
|
<section>
|
|
<h2>Recovery via KYC Validation and Statement of Intent</h2>
|
|
<p>
|
|
Recovery via KYC requires that a threshold of authorized
|
|
persons be KYCd in person by legal representatives of Distrust
|
|
and confirm their intent to recover data. This process varies
|
|
based on the jurisdiction it's being conducted in and adds
|
|
time to the recovery process.
|
|
</p>
|
|
|
|
<label>Can recovery be authorized by persons using KYC? *</label>
|
|
<br>
|
|
<select required name="kyc_available" id="kyc_available">
|
|
<option disabled selected value> -- select an option -- </option>
|
|
<option value="true">Yes</option>
|
|
<option value="false">No</option>
|
|
</select>
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<div id="kyc_available_container" class="hidden">
|
|
<label>What threshold would you like to use for the KYC recovery method? (2/3, 3/5, 4/7 etc)</label>
|
|
<br>
|
|
<input type="text" id="kyc_threshold" name="kyc_threshold">
|
|
<div class="error-field" id="kyc_threshold_error"></div>
|
|
|
|
<p>
|
|
Please select KYC data for individuals who can
|
|
participate in recovery. Each person's data should be a
|
|
.toml file. Pictures of front and back of IDs should be
|
|
base64 encoded and listed in the <b>id_images</b> array.
|
|
The supported ID types are Driver's License, Passport,
|
|
National Identity Card:
|
|
</p>
|
|
|
|
<pre>
|
|
<code>
|
|
first_name = "John"
|
|
last_name = "Doe"
|
|
date_of_birth = "1990-01-01"
|
|
id_images = ["<base_64_encoded_image>", "<base_64_encoded_image>", ...]
|
|
country_of_birth = "US"
|
|
</code>
|
|
</pre>
|
|
|
|
<input type="file" id="kyc_data" name="files[]" multiple>
|
|
<br>
|
|
<div class="error-field" id="kyc_data_error"></div>
|
|
</div>
|
|
</section>
|
|
|
|
<hr class="divider">
|
|
|
|
<section>
|
|
<h2>Data Storage</h2>
|
|
<p>
|
|
This part of the policy allows you to select wether you
|
|
would like Distrust to fully back up all your data, or to
|
|
only hold an encryption key in escrow, in which case you are
|
|
responsible for redundantly backing up the encrypted data
|
|
(learn more <a href="/data-storage.html">here</a>)
|
|
</p>
|
|
<label>Type of data storage *</label>
|
|
<br>
|
|
<select required name="data_stroage" id="data_storage">
|
|
<option required disabled selected value> -- select an option -- </option>
|
|
<option value="managed">Fully managed</option>
|
|
<option value="key_escrow">Key escrow only</option>
|
|
</select>
|
|
</section>
|
|
|
|
<hr class="divider">
|
|
|
|
<section>
|
|
<h2>Additional Configurations</h2>
|
|
<label>Are both remote and KYC based recovery required? (If "No", either one can be used for
|
|
recovery) *</label>
|
|
<br>
|
|
<select required name="multi_rule_requirement" id="multi_rule_requirement">
|
|
<option disabled selected value> -- select an option -- </option>
|
|
<option value="true">Yes</option>
|
|
<option value="false">No</option>
|
|
</select>
|
|
|
|
<br>
|
|
<br>
|
|
|
|
<label>Is this a deadman switch?</label>
|
|
<p>
|
|
Deadman switches can only be used with "key-escrow" mode,
|
|
and not "fully managed". If a policy is defined as a deadman
|
|
switch, the escrow key will be emailed to the designated
|
|
email addresses or posted on the Distrust website, or both,
|
|
as preferred.
|
|
</p>
|
|
<br>
|
|
<select required name="multi_rule_requirement" id="multi_rule_requirement">
|
|
<option disabled selected value> -- select an option -- </option>
|
|
<option value="true">Yes</option>
|
|
<option value="false">No</option>
|
|
</select>
|
|
</section>
|
|
|
|
<input type="submit" value="Generate Policy">
|
|
</form>
|
|
|
|
|
|
<form id="policy">
|
|
<textarea
|
|
id="generated-policy-form"
|
|
disabled placeholder="Click 'Generate Policy'">
|
|
</textarea>
|
|
</form>
|
|
|
|
|
|
</main>
|
|
{%- include footer.html -%}
|
|
</div>
|
|
</body>
|
|
|
|
</html> |