Trust issues. How to share a key between people and insure against its loss
It's good to be paranoid. Joyfully. You quickly come up with the idea that you can't trust anyone, and it's best to keep yourself under suspicion just in case. It becomes quite joyful when you get a job in a large company with such a worldview and start designing key services from the point of view of information security. Therefore, I suggest that we discuss how to ensure the safety of valuable secrets in an environment where everyone is a potential attacker.
Secrets are different
Passwords, API keys, certificates, and other secrets are not equal. For any company, the risk of unauthorized access can be expressed in direct and indirect losses. If you multiply the amount of losses from a secret leak by the probability of an attack, you can divide our passwords into several categories:
- No one needs them. I picked up the VM, tested something, and forgot. The maximum that can be stolen is the schedule of watering plants in the office from the script of one admin.
- Potentially significant ones. A test database, some kind of secondary server, or something similar. Unauthorized access in itself will not bring losses, but it can be a "springboard" for deeper penetration into the company's infrastructure.
- Significant ones. Combat database, important log server, and other key systems. If an attacker gets in here, they can either steal valuable information or significantly disrupt the company's operations.
- Awesome critical ones. What could be more frustrating than having an important password compromised? That's right - write out the entire bundle of passwords in its entirety. For example, the Keepass database along with the access key. If an attacker gets to it, the financial damage to the company may be irreparable.
We will talk about the last category that needs to be protected not only from external attacks, but also from internal threats.
All have their own price
Unfortunately, not all people are honest and correct. Have you seen the news about leaked databases that were leaked by employees? And this, by the way, is quite an article of the criminal code. Let's take a look at the heads of such employees.
A person from a regional branch receives a salary of 35 thousand rubles. He was given access to an important database so that he could perform his work tasks. Quite suddenly, a tempting offer comes to him from the depths of the darknet to merge the entire database for $ 7000. An employee looks at their paycheck, assesses their chances of being caught, and takes that risk.
The buyer from the darknet also correlates the cost of bribing an employee and the final benefit from the information received. If the benefits are greater than the risks, he will take risks.
The conclusion is quite simple: there is no perfect protection. The main task is to make the attack unprofitable, when bribing employees and other activities will require more money than the profit from stolen data.
Accordingly, it is necessary to ensure that no employee can gain access to particularly important systems such as centralized password repositories on their own. Let's take a look at how this is implemented in real life, and then return to our digital joys.
Red button for the general
There are very real situations when it is necessary to share responsibility between several key people. Take something fun like launching nuclear missiles. Let's assume that a conditional underground bunker, when communication with the main headquarters is lost, can independently decide to launch a retaliatory strike.
It is a reasonable option to give out the launch keys to several people. For example, the duty officer and the head of a secret base with an ICBM. Thus, an officer who has suddenly gone mad will not be able to arrange a third world war by making a decision on his own. We reduce the chance of unauthorized access by sharing the secret between key people.
They do the same when you need to organize access to a specially protected Bank vault. Permission to open doors must be confirmed simultaneously by several responsible persons. The cost of an attack on the storage immediately increases dramatically, since it is necessary to bribe or Rob at least two people who already have access.
Optimal protection
I want to note right away that it is very difficult to find a good balance between the convenience of encrypting classified information and reliability. Any variant of "backup access codes" in case the main ones are lost weakens the protection and adds additional attack vectors. If we try to divide the secret into several responsible ones, then everything becomes even more complicated.
Safe Deposit box and papers
Let's say we are protecting a conditional super-privileged secret that can only be used in exceptional cases. For example, mobile phones that have access to corporate mail and resources are managed using the MDM (Mobile device management system). We don't want anyone from the information security Department to be able to access data from the employee's phone. At the same time, we need to be able to remotely destroy the contents of the phone or find out its current GPS coordinates if the device is stolen. Accordingly, we need a solution that will allow us to share responsibility between several people.
We can print the password on a piece of paper, put it in an envelope, fill it with sealing wax and solemnly put it in the safe. That's pretty good. We will open and seal them only in the presence of the commission. But it is difficult to back up a piece of paper, it keeps the secret in an open form, which increases the risk of its compromise. It is also a physical object - if one of the mandatory Commission members is on a business trip, emergency access becomes problematic.
Matryoshka doll with passwords
To hell with paper and cardboard daddies. Let's be modern. Let's go the easiest way and make a 7-Zip archive encrypted with AES-256 cryptographic strength. We don't want a single employee to have sole access to the secret, so we will construct a matryoshka doll from nested archives, where each layer is closed with a new person's password. For example, the head of information security and technical Director.
At first glance, everything works fine. The reliability of protection against compromise is growing rapidly in proportion to the number of people. For example, if the probability of a password leak from one person is 0.05, then for six people it is already 0.056 = 1.5625 × 10-8.
Cool. But there is a problem. The probability of permanently losing a protected secret is also increasing. With a person often happens some garbage. For example, if a person walks unsuccessfully under a bus at a red light, or sclerosis attacks. If this is a centralized repository of especially valuable data for the company, their loss can be fatal.
Breaking it down into fragments
Actually, there is a good solution.
There is a very elegant implementation of splitting a secret into several parts - the Shamir scheme. Yes, this is the same ADI Shamir, who is S in the abbreviation RSA. When using this method, the original password is split into kequivalent parts. The peculiarity of the scheme is that only a certain part of the fragments is required to restore the secret. For example, any four out of six. At the same time, if you know three parts out of six, then this will not help you restore the original password in any way.
The size of a single chunk is equal to the original secret, so as in public-key cryptography, it usually doesn't make sense to split up a large amount of data. It is much easier to slice the key from a fast symmetric encryption algorithm and use it to encrypt the entire amount of data. This method scales well. You can add new people who store parts of the shared key. However, the size of the quorum will not change. That is, if earlier it was necessary to collect three keys out of five, now three out of eight is enough.
You can also rotate key fragments. The algorithm implies a scheme in which a sufficient number of people gather and generate a new set. The encrypted shared key remains unchanged. This is a very valuable feature in case of compromise, dismissal of an employee, or other problems.
Most importantly, it implies more flexibility when distributing parts of the key. For example, the CEO can be given three fragments, and all the others one at a time. In this way, you can take into account the degree of importance and trustworthiness of each responsible person in the company.
DRP on people
DRP (Disaster Recovery Plan) is such an important thing that ideally should never come in handy. But if garbage happens, then you open the mailbox with a smart look, leaf through folders with the words "productive database Crash"," Fire in the data center"," t-virus Leak "and, finally, take"Sudden birthday of the Manager". After that, just follow the pre-designed instructions. And in principle, it doesn't matter what exactly happened, but you already have pre-predicted damage maps, plans for emergency migration of the cluster to another site, and so on.
Developing a good DRP is the perfect job for a real paranoid user. But, unfortunately, many people forget that, in addition to hardware, there is another point of failure - these are people. They also need to be backed up to ensure fault tolerance of business systems. For example, food for civil aviation pilots is always prepared in different kitchens and consists of a different set of products. No one wants a synchronous attack of acute diarrhea to interfere with the normal operation of the aircraft.
When developing a clever system with keys, ciphers, closed databases, and all the rest, always think about how you will open it later in an emergency. For example, you chose to split the secret according to the Shamir scheme and gave out six keys, of which you need to enter any four. Everything seems to be fine.
Now imagine the same "bus factor". During the next corporate party, three of the Keepers suddenly drop out forever. It doesn't matter if the boat capsized or someone fried the newly picked mushrooms unsuccessfully. Now you have three keys in your hands and a lost forever database with a cryptographic cipher.
What should I do about it? Keepers should be geographically distributed and not meet at the same time in the same place. This is not so difficult to implement if you have a large company with many branches. Some of the Keepers may be in a "cold reserve" and not be used in normal processes. Yes, all the same principles of geo-distribution and redundancy work here as when building classic fault-tolerant architectures.
Also consider the traditional scheme with a sealed safe under the cells, where the backup doomsday keys that form the quorum will be stored in a beautiful red envelope. Naturally, such a safe is opened only in the presence of the Commission, when it comes to a critical threat to business processes.
Hashicorp Vault
Let's move on to more practical examples. There is Such a wonderful product-hashicorp's Vault. This is when instead of putting up admin passwords on pieces of paper and hardcoding them directly in scripts, you create a centralized virtual storage surrounded by barbed wire and burning crocodiles. All accesses are distributed, each request via the API is logged, and all this is perfectly integrated with CI-CD processes and automated systems.
Architecturally, you have the database itself, which is stored encrypted on the backend in the form of a fault-tolerant
Consul cluster. I won't talk about Consul in detail, just mention that it works on the basis of the extremely stable
raft protocol.
The most interesting thing is that if our database is stored in encrypted form, then Vault nodes need to store the master key for accessing the database in order to provide access to passwords. This is a problem, as they will immediately become the primary target for an attack. The slightest vulnerability of the node, a copy of the VM by an unscrupulous administrator, and the master key has leaked. Along with all the company secrets.
And here comes an interesting feature of Vault. It does not store the password anywhere on the hard disk, swap is disabled, and the appearance of the master key somewhere other than RAM is excluded. After a reboot, the node has no idea how to open the encrypted database, and requires a quorum of Keepers to enter Shamir fragments one by one. This is implemented either through the SSH console or through the web interface, which makes it very easy to unlock the node in the case of a distributed team.
What is the result? The master key is collected from Shamir's fragments, and the key that the database is encrypted with is decrypted with it. The two-step approach is necessary in order to be able to regularly rotate Shamir fragments and change their number without having to re-encrypt the entire database. If you look at the process abstractly, we form a password using a quorum of non-recoverable storage-the contents of the memory of several people. This results in the same non-recoverable master key stored in RAM in most cases.
Primary distribution issue
The most difficult part is the initial key issuance procedure.
- You must ensure that Shamir fragments can be delivered remotely.
- There should not be a person who clicks something in the console, gets all the fragments and sends them to everyone else.
Code:
$ vault operator init
Unseal Key 1: 4jYbl2CBIv6SpkKj6Hos9iD32k5RfGkLzlosrrq/JgOm
Unseal Key 2: B05G1DRtfYckFV5BbdBvXq0wkK5HFqB9g2jcDmNfTQiS
Unseal Key 3: Arig0N9rN9ezkTRo7qTB7gsIZDaonOcc53EHo83F5chA
Unseal Key 4: 0cZE0C/gEk3YHaKjIWxhyyfs8REhqkRW/CSXTnmTilv+
Unseal Key 5: fYhZOseRgzxmJCmIqUdxEm9C3jB5Q27AowER9w4FC2Ck
It is possible to initialize it from the console alone, as in the example above. Then the admin can be safely pushed off the cliff. But there are also more humane mechanisms. Each of the Keepers provides the public part of their GPG key to the Vault admin. Then initialization takes place:
Code:
$ vault operator init -key-shares=3 -key-threshold=2
-pgp-keys="jeff.asc,vishal.asc,seth.asc"
Key 1: wcBMA37rwGt6FS1VAQgAk1q8XQh6yc...
Key 2: wcBMA0wwnMXgRzYYAQgAavqbTCxZGD...
Key 3: wcFMA2DjqDb4YhTAARAAeTFyYxPmUd...
Only the owner of the closed part of GPG will be able to decipher each fragment of Shamir. We have successfully distributed the secret without ever collecting it in one place in clear text.
Conclusions
- Design any system with a healthy dose of paranoia.
- Never forget that it's not enough to encrypt everything carefully. It's important to be able to decipher it all back.
- If your business stops when you lose your keys, be doubly careful.
- Leave a backdoor in the form of paper in the safe.
- People are also part of the mechanism, and they need to be reserved. Reserve it.
And don't trust anyone.
