History: Shared Secrets
Preview of version: 27
Shamir's Shared Secrets and Team Password Management via Trackers
This feature introduced in Tiki22 allows you to encrypt password or any other sensitive info with an encryption key. These passwords or sensitive data are stored in the Trackers based on Shamir's Shared Secret algorithm. This is an improved version of shared secret encryption (symmetrical encryption) as we do not need to secure shared keys to the point where they cannot be used alone to decrypt data. Even if a hacker accesses the Tiki database, he still won't be able to decrypt the data (easily) without a second shared key. None of the users will be able to decrypt the data alone without the key in the Tiki database. We use https://github.com/teqneers/shamir
Overview
Imagine a door lock that requires at least 3 keys at the same time to open it. So, if you divide the secret key into 5 parts and give them to different users and use a minimum threshold of 3, at least 3 people must provide their share in order to reconstruct the secret. What will happen ? Here is the idea:
- encrypt password or any other sensitive info with an encryption key
- run the key through SSS algorithm with number of shares = number of people to be shared with + 1 and threshold of 2
- store one of the shares in Tiki db
- distribute the rest of the shares to all people that need access to the sensitive info
- then, whenever someone comes, they supply their shared secret and we use the other one stored in Tiki db. Since threshold is 2, they will be able to decrypt the sensitive info.
- This goes beyond the User Encryption feature.
How it works ?
Requirement
Starting with the activation of User encryption that requires the Sodium PHP extension for encryption otherwise you will not be able to activate it. "System Menu" > "Security" > "General Security" tab > "User encryption" (https://example.org/tiki-admin.php?page=security#content_admin1-1).
Create encryption key
Once "User encryption" is active, you can then proceed to create the key by proceeding as follows: "System Menu" > "Security" > "Encryption" tab > "Create key" tab, (https://example.org/tiki-admin.php?page=security#contentencryption-2)
Generated keys
After the creation of the encryption key, a number of keys will be generated according to the number of selected users, each of which can be used to encrypt and decrypt data.
Encrypted keys list
When changing encryption key, enabling the option "Regenerate shares" will create new secret shares with the defined number of shares. Old shares will no longer be valid, so you will need to distribute the new shares to team members again. Data encrypted with existing key will stay intact and new shares will be able to decrypt it.
No data loss occurs as long as you keep the shared keys known. Use this option to increase or decrease the number of people with shared keys for this domain. If User Encryption is turned on, newly generated keys will be automatically saved to relevant user accounts.
You add the name of the key, the description and you select the users to share it with.
All the encryption keys added are listed: (https://example.org/tiki-admin.php?page=security#contentencryption-1)
Add encryption option to field
It is therefore necessary to create a Tracker to take advantage of the benefits of this feature.
You have to change the "Encryption key" parameter of the field you want to create. This parameter is found in "Advanced Options" > in the tab "Advanced" > the field "Encryption key", select the key.
Create Tracker item
When creating the item, you will see the message "Field data is encrypted using key" followed by the name of the key used below the field. As on the image below:
Using keys
We copied one of the keys to finally use it and have access to the encrypted information.
If when using a key you see the message "Given keys are incompatible", this is a case where you are using a different key from those generated by the key, it is the same case when you see the message "Given keys vary in key length".
Notes
- Users with whom the keys have been shared have direct access to the data of the encrypted fields regardless of the group they belong to as in this case with the user "admin", i.e. they do not need to use their key to decrypt the item field. Remember that the key was initially shared with two other users: "user 1" and "user 2" during its creation.
- Tracker permissions must be changed to allow non-admin users to access it.
- Other users with whom the key has not been shared must use the key to access the field data because it is hidden from them.