

Platform Description¶

Community Edition¶

This edition is the current Inheriti version, which offers to highest degree of decentralisation in order to make digital assets transferable/inheritable.

DLT/DB : Blockchain
Cold Storage : SafeKey
Key Management : Decentralised

Standard & Business Edition¶

We realise that not all users desire to deal with their digital assets using our platform in the same way. For B2B users, we aim to offer a wide range of other solutions (this does not mean that standard users cannot use these services), which are modular and where different options can be selected.

DLT/DB : Blockchain / local DB / IPFS
Cold Storage : SafeKey / HSM
Key Management : Decentralised / Hybrid

Roles Concept's & Naming conventions¶

Before going further, it is important to get familiar with some basic concepts used in our platform and concepts that are not referred to/explained architecture improvements when comparing to our original whitepaper.

Info

In this section we refer to Inheriti, even when the Inheriti (Safe Haven's Inheritance Platform) acronym is used.

Initiator¶

An initiator is a person/entity that is initiating a protection plan by using Inheriti (Safe Haven’s Inheritrance Platform: Inheriti.com). This can be parent, business executive, that is going to protect digital assets.

Stakeholder¶

A stakeholder is a person/entity that holds shares or that holds access rights to shares belonging to stakeholder before initiated/created protection plan.

Legal Entity¶

A legal entity is an entity that has a TAN memberInheriti and has a verified label, this can be a lawyer or a notary depending on in which jurisdiction the Initiator is based. Those entities are pulled from the TAN database.

TAN website

Our TAN social platform can be found at the following link https://trustalliance.network

Merge Authority¶

TAN usage¶

In this case, a Merge Authority is a verified Trust Alliance network member that has been selected by the Initiator in order to take charge the direct release of the DLT shares once the predefined conditions are all met. By using a TAN MA, the process will not be fully automated

Example Condition

In the case of a next kin scenario, the major condition that needs to be met is the manual verification of a death certificate for instance.

without TAN usage¶

In order to use Inheriti in a full automated way, we introduced the concept of Non-TAN based Merge Authorities and Dead Man Switches. Here the Initiator selects a stakeholder as an MA, the eldest son for instance. It is the MA that needs to initiate the release of the DLT shares and Inheriti that needs to validate the release by using complementary smart contract shares covering 4 different DMS scenarios. (see DMS for more details)

CE-MA usage

In the Community Edition, we only activate the usage of a Merge Authority without the TAN.

in case that a MA loses his SafeKey

In the case that a Stakeholder is a Merge Authority and is in fact the only one to be able to initiate a merge procedure, Safe Haven customer services must be contacted in order for us to give the role as MA to another stakeholder.

DMS (Dead Man Switches)¶

Login
Mail send
SMS Gateway
Call service

Info

More details are going to be published soon.

Data Organiser¶

The Data Organiser is an easy way to create a JSON datastring based on a form in which data is filled and represents what one desires to secure in order to have it organised and comprehensible for shareholders.

DO for Passwords¶

The Data Organiser for Passwords will give the following:

An ID field, which is basicaly just an integer that increments
A UserName field
A Password felfd
Description field

Once created you will have a json looking like this

{
"PP": "$ID",
  "1": [
    {
      "Username": "[email protected]",
      "Password": "test",
      "Description": "My Gmail account"
    },
  ]
  "2": [
    {
      "Username": "[email protected]",
      "Password": "test",
      "Description": "My Facebook account"
    },
  ]
  "3": [
    {
      "Username": "[email protected]",
      "Password": "test",
      "Description": "Microsoft account"
    },
  ]"
}

DO for Private Keys¶

The Data Organiser for Private Keys will give the following:

An ID field, which is basicaly just an integer that increments
A Private Key field
A Seeds field
Description field

Once created you will have a json looking like this

{
"PP": "$ID",
  "1": [
    {
      "PrivateKey": "8da4ef21b864d2cc52...a8b41de8f",
      "Seeds": "12 words(bip39 based) for PK recovery",
      "Description": "addresss:63FaC9...e3BD377, SHA Wallet 1,..."
    },
  ]
  "2": [
    {
      "PrivateKey": "8da4ef21b864d2cc52...a8b41de8d",
      "Seeds": "12 words(bip39 based) for PK recovery",
      "Description": "addresss:63FaC9...e3BD378, SHA Wallet 2,..."
    },
  ]
  "3": [
     {
      "PrivateKey": "8da4ef21b864d2cc52...a8b41de8e",
      "Seeds": "12 words(bip39 based) for PK recovery",
      "Description": "addresss:63FaC9...e3BD378, SHA Wallet 3,..."
    },
  ]"
}

relevant data

You can add fields/data (in the "Data to Secure field) ass you wish, as long the data is relevant and helps your stakeholders to understand relevant pieces.

Again this will be stored in your web browser and linked/pushed to the Data to Secure field.

Max Data String size

The maximum lenght for the CS data storage is currently set on 40k bytes including the private keys necessary to decrypt the shares on the blockchain.

How it works? (simplified)¶

The current version of the Inheriti documentation is mainly focused on the CE (Community Edition). The Beta release includes DMS validators shares in conjunction with Merge Authorities, the production release will pull verified TAN (Trust Alliance Network) legal entities which will be the most logic MA for validators (blockchain stored) smart contract-based shares. The fact we aim to build the most decentralised and secure solution out there, we came up with the following architecture setup for our Community Edition (CE)

To keep everything as decentralised possible we needed to integrate the following building blocks:

Client JavaScript Libraries for splitting & Merging datastrings using SSSS.
Client based Wallet providers that acts as a web browser plugin for Chromium based Web browsers. (cfr. Comet)
Cold Storage device for Secret Share storage (cfr. SafeKey)
SafeHaven's SDP (Share Distribution Protocol) for share distribution.
Blockchain based shares for validators/DMS shares storage.

We don't own your critical information/data

The main goal of our CE (Community Edition) is to create a platform that does not hold your critical data in any way. This chapter is going to explain (in a nutshell) how we accomplished that based on the 8da4ef21b864d2cc52...a8b41de8e Private Key example.

Assume the following:

Secret : 8da4ef21b864d2cc52...a8b41de8e
Number of stakeholders : 3
Number of validators shares : 1
Total number of shares : 7
Threshold for merging : 7
Merge Authority : Stakeholder 1

Step 1: Splitting¶

By using the ssss (Shamir Secret Sharing Scheme ) algorithm we split the secret 8da4ef21b864d2cc52...a8b41de8e into 7 shares

    1-b66b21c1a86309e3a1cc85022d4c9fa33ba54c5a148ab3bc2c4fa93b8f15
    2-763c081e2ea7d0ef23ad572bec4e78d5480936d1a166897d86e106b8e8de
    3-a38ee080a86609dc060840d77414f59bbda5325d4c5131a956f4198005ec
    4-635ebf866a006110744c7c1ebdfa31ea8c830cad7f4d82e11e177aa3b797
    5-6a0cfe92f25f4165d6dd5186cf801d6bd28695c4e5647f98de42dab40be5
    6-c2807eb2d1afdc2aa176c5be2725f82debeb14579002a8bbe15cf542383d
    7-8baa7f5c865b51f67fd2e580b95c5173913aa41812c345844ea10d5514a2

share 1-2 is meant for stakeholder 1

    1-b66b21c1a86309e3a1cc85022d4c9fa33ba54c5a148ab3bc2c4fa93b8f15
    2-763c081e2ea7d0ef23ad572bec4e78d5480936d1a166897d86e106b8e8de

share 3-4 is meant for stakeholder 2

    3-a38ee080a86609dc060840d77414f59bbda5325d4c5131a956f4198005ec
    4-635ebf866a006110744c7c1ebdfa31ea8c830cad7f4d82e11e177aa3b797

share 5-6 is meant for stakeholder 3

    5-6a0cfe92f25f4165d6dd5186cf801d6bd28695c4e5647f98de42dab40be5
    6-c2807eb2d1afdc2aa176c5be2725f82debeb14579002a8bbe15cf542383d

share 7 is foreseen as the validator share

    7-8baa7f5c865b51f67fd2e580b95c5173913aa41812c345844ea10d5514a2

A. Validators share's

We have 2 types of validators shares:

2 types of validators shares

Dead Man Switches shares (DMS) : fully automated as the release happens by triggering smart contracts.
TAN based shares : partial automated as a verified legal entity has to verify the conditions set by the initiator before releasing the share.

The validators share is used by deploying a smart contract on the blockchain. As the blockchain is public, the data can be read. Even if the obtained data is not going to be enough to help merging the 6 shares cold stored on the 3 stakeholders their SafeKeys to the original secret, as the threshold has been set to 7 We still wanted to encrypt the data to not make our internal ID mapping system visual/public.

For that reason, the platform generates (client based) a key-pair using openPGP, which is based on asymmetric cryptography.

By doing that we have the following:

A public key is generated => this key is used to encrypt the validators and backup shares.
A private key is generated => and stored on the cold storage device alongside the stakeholders shares
A passphrase is generated => the passphrase is stored in our local DB (this is in fact the only information we store and own)

Note

So to resume: the validators and backup shares are encrypted by using the before generated public key.

B. Stakeholders share's

The stakeholders shares are cold stored on our SafeKey devices (in the Community Edition) and the data is encrypted as follow:

The master key is wrapped by AES256-CBC with a key based on PBKDF2 hash, derived from user PIN.
Encryption essentially is realized through 256-bit AES-CBCESSIV

this gives us:

IV_record = SHA256( {IV_SALT, data_record_index} )
data_record_encrypted = encrypt(master_aes_key,IV_record, `b66b21c1a86309e3a1cc85022d4c9fa33ba54c5a148ab3bc2c4fa93b8f15;
    763c081e2ea7d0ef23ad572bec4e78d5480936d1a166897d86e106b8e8de`)

where:

IV_SALT is salt used to generate the IV, kept along with AES key, and treated the same way as the master AES key
Master_aes_key is the 256-bit key used to encrypt/decrypt user data
Encrypt(master_aes_key, IV, plaintext) is an AES 256 encryption function, taking AES key master_aes_key, IV initialization vector, and plaintext data plaintext;
decrypt(master_aes_key, IV, ciphertext) is an AES 256 decryption function, taking AES key master_aes_key, IV initialization vector, and encrypted data ciphertext;
{IV_SALT, data_record_index} is a concatenated binary array of data IV_SALT and data_record_index.

Info

See the data-encryption-and-decryption section in our High level design documentation for more details about the Master encryption key details en key usage.

Alongside the shares, we store the private key that belongs to the keypair generated for the encryption of the validators share.

C. Backup shares

Backup shares are dealt with in the same manner as validators shares.

The following flow gives a overall view of the diferent steps discussed before.

Step 3: Merging¶

Stakeholder 1 was elected as Merge Authority (MA) by the initiator in our example so Stakeholder 1 can initiate the share merging to re-establish the secret.

When the MA inserts his SafeKey, we check for any protection plan(s) on it. If there is only one plan, we move to the next step. If there are multiple plans on the key, Inheriti will ask them to choose from one.
Once done, Inheriti check's if they are the MA for that plan. if they are not MA, it stops there.
In case the SafeKey owner is indeed the Merge Authority, we check the deadman shares, if they have not been cleared yet, Inheriti asked the user, "we are confirming the deadman switches, please check back later" and we fire them off if they have not been fired off yet.
If one of the deadman switches are responded to by the owner/initiator, the protection plan is rest and the MA would start the merging procedure all over again.
In the case that the DMS are not responded to, and the allocated time passes, Inheriti gives the Okay to the MA that the owner is dead (for instance), and sends the passphrase to the MA's browser, it reads the shares from the MA SafeKey and asks the MA to insert the next key(s) and it reads from them the missing shares.
After decrypting the SafeKey data, we collect the Private Key from the SafeKey and decrypt the validators share by using the passphrase received earlier.
Once the MA confirms that all shares has been loaded from all SafeKey's the Inheriti tries to merge them and displays the original data.

Decryption SafeKey Shares (point 5)

    1-b66b21c1a86309...bc2c4fa93b8f15 > collected by step 5
    2-763c081e2ea7d0...7d86e106b8e8de > collected by step 5
    3-a38ee080a86609...a956f4198005ec > collected by step 5
    4-635ebf866a0061...e11e177aa3b797 > collected by step 5
    5-6a0cfe92f25f41...98de42dab40be5 > collected by step 5
    6-c2807eb2d1afdc...bbe15cf542383d > collected by step 5
    7-8baa7f5c865b51...844ea10d5514a2 > collected by step 6

By using the ssss (Shamir Secret Sharing Scheme ) algorithm we merge the 7 shares into the original secret 8da4ef21b864d2cc52...a8b41de8e

Decryption Validators Shares (point 6)

As we used the public key to encrypt the validators shares, and we are talking about asymmetric cryptography we can use the private key to decrypt the data using the passphrase recieved after the DMS conditions were met, see openPGP

Smart Contract Interactions¶

Gas/SHA costs

From a "User perspective" we have 2 different types of contracts:

1) StoreFactory

StoreFactory is the main contract. Individual Store(s) can be made from this factory. Making a Store using the factory costs SHA tokens and the amount of SHA tokens is set by the PriceManager contract.

2) PriceManager

The owner of the PriceManager contract can set the price for creating stores using the factory by calling PriceManager.setPrice("StoreFactory", ether(1000)) The fact that our Community Edition API is not yet open for third-party platforms and/or developers, the StoreFactory for Inheriti is owned and managed by a SafeTech owned wallet.

Setting prices for modifying individual stores (like adding/deleting shares to a store) is done similarly by the following call, priceManager.setPrice("Store", ether(100)).

Pricing

So in the above example we set the price for a Protection Plan creation to 1000 SHA and for additional function calls requiring GAS 100 SHA (Adding a stakeholder for instance)

SafeID¶

Authentication¶

SafeID has been designed to offer a SSO (Single Sign-On service) for all Safehaven/Safetech related projects, One account to rule them all!

SafeID Registration

You can create a SafeID account on the following link "https://id.safetech.io

Subscriptions¶

(under construction)

As our goal is to aim for mass adoption, we need to provide solutions in order for non-crypto people to be able using our platforms. Hence the integration of a subscription platform with SafeID, were users can buy Credits than can be used in the backed by users non holding any crypto wallet, we are providing them with crypto from our SHA liquidity pools, as long as the amount of credits alows it to.

We opted for a Stripe integration in order to secure our paiements, other paiement gatways like paypall etc are going to be added over time.

SafeKey¶

Note

For a more detailed explaination about our very own cold storage device SafeKey" please visit the following link : https://docs.safetech.io

Other than offering full FIDO2 capabilities, SSDP is integrated to be compatible with Inheriti, as well. The SafeTech Custom Storage encryption implementation is in line with the AES-CBC-ESSIV standard. SafeKey contains additional features similar to a key-value store (no rigid structure for data, except for the ID field). It allows to store 80 data records of up to 480 bytes capacity (including the ID field, and small storage structure overhead). The Custom Storage (CS) is encrypted with AES256, and accessible only after providing correct PIN. For usability, the CS’ PIN is shared with FIDO2 PIN application. Data are stored as received from the JavaScript application, encoded inside a CBOR structure. For backward-compatibility, and to allow to communicate over any Internet browser, FIDO U2F is chosen as a transport layer

each dataslot = 480 bytes, for a complete CBOR structure;
To store bigger data records, the data has to be split to 480-bytes chunks on the client (JS application using API) side
Total data size : 256k
- bootloader : 20k
- FIDO data : 20k
Current total configured space for the CS is 40 kB, giving 80 slots total
Potentially the size could be extended to 110 kB with a firmware update (code change needed)
Data is encrypted internally on the device using AES256.

The solution was designed under the following threat model:

Warning

Adversary does not have physical access to the device, while it is operating;
Adversary does not have physical access multiple times to the device, while it is not operating;
Used PC has no malware or viruses installed;

The following security messurements has been implemented in our SafeKey:

Data is encrypted
DOS (Denial of Service protection)
PIN Authentication
Unlock passphrase (PUK equivalent) - not for CE
Features activation (SSDP can be enabled and disabled)
Firmware signature
Firmware Downgrade protection

Operation mode

The SafeKey can operate in 2 different modes, our CE edition keeps the SafeKey in the normal operation mode.

The following features has been added in our SafeKey for completeness sake.

Remote Backup (cloud based)
Device To Device Backup

Shop¶

Our Safekey's, the only cold storage device comptabile with our Inheriti products are for sale on our SafeTech Web Shop

Platform Description¶

Community Edition¶

Standard & Business Edition¶

Roles Concept's & Naming conventions¶

Initiator¶

Stakeholder¶

Legal Entity¶

Merge Authority¶

TAN usage¶

without TAN usage¶

DMS (Dead Man Switches)¶

Data Organiser¶

DO for Passwords¶

DO for Private Keys¶

How it works? (simplified)¶

Step 1: Splitting¶

Step 2: Share Distribution¶

Step 3: Merging¶

Smart Contract Interactions¶

SafeID¶

Authentication¶

Subscriptions¶

SafeKey¶

Shop¶