Inheriti CE : How it works - Simplified

1

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:

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

!!! important “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

Step 2: Share Distribution

A. Validators share’s

We have 2 types of validators shares:

!!! info “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.

![1](img/Initiator Flow-data handling-once-logged-in.png#center)

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.

  1. 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.
  2. Once done, Inheriti check’s if they are the MA for that plan. if they are not MA, it stops there.
  3. 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.
  4. 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.
  5. 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.
  6. After decrypting the SafeKey data, we collect the Private Key from the SafeKey and decrypt the validators share by using the passphrase received earlier.
  7. 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

5 Likes