Welcome to the next video on vault.
In this video, we're gonna learn about the Shamir's secret sharing algorithm, how it's used involved. We're gonna go through the process of ceiling and unsealing our own local vault Instance. And then we're gonna talk about auto unseal capabilities involved.
You may recall, when we looked at the architecture in the prior lesson, we discussed the fact that data gets stored in a stores back in different storage back ends. And there's this cryptographic seal this barrier, right, like a bank vault around all the data when it's held in memory, and then when it gets stored to the back end,
In fact, it's encrypted using a 256 bit a AES encryption. Now, if you recall way back in this series, when we were talking about asymmetric encryption versus symmetric encryption, A s is a symmetric encryption protocol. So this is all this say when the vault server starts up.
If it has existing data that it needs to read, all that data is encrypted, and so it's using A S, and you need the key to decrypt that data
Well, turns out the folks at Hash Corp didn't make it so simple as to say one single key will decrypt all the data in your vault. In fact, they went ahead and used a algorithm called the Shamir's Secret Sharing Algorithm. Ultimately, it's to make it more difficult for a hacker
to decrypt the data in your vault.
all the data itself that is encrypted all the storage data that encryption key itself is encrypted
alongside the data. And then there's a master key that's encrypting that encryption key, right? So where we've got multiple layers of encryption going on to really lock things down and keep them shape safe,
and what ends up happening is to generate that master key. It's actually been split into separate shares,
and in order to regenerate that master key, you need a certain number of those shares, right? So a quorum of key holders to get that master key. And without that master key, you can't do what's called unsealed. The vault decrypt all of that encrypted data and the keys and the secrets and so forth.
So in involved the default settings are it's gonna take that Master key is gonna create five separate key shares.
You need three of those key shares to have what's considered a quorum in other ways. Words. To reconstruct this master key, you need to have three of the five independent key shares. So this brings with it some pros and some cons. The cons are you need five key shares.
You need at least three off the five key shares
to get the vault data decrypted. The pros are any intruder. Anything bad actor also needs to find at least three of those five key shares, so just finding one isn't going to cut it. They need to find three if they're going to decrypt all the vault data as it sits at rest.
The other good thing is you can still lose two of these key shares
and bring up the master key. So you don't have to keep all five.
You should keep all five, But things can happen. You may lose him, and you only need three of the five to bring up the vault server and recreate. So if you could imagine, you could distribute these 5 to 5 different people or store them in five different locations, making it that much more difficult for a bad actor
to obtain all five or even three of the five key shares,
and at the same time you get three of them on when it turned to start up this security, circumstances and procedures really keep it checks and balances in place. It's kind of the analogy. Is the press two buttons to launch the nuke? You need multiple people to decrypt this vault data. So what we're going to do now
is walk through the process of
generating those master keys
an unsealing, a vault ceiling, the vault and unsealing a vault again. So you get a feel for in a production environment how you would actually manage the encrypted data. So let's hop over to the terminal and run through this process with a brand new server
you'll notice in my terminal window right away. I am in the vault concepts subdirectory because they're some files in that sub directory of the repository that we're gonna reference. So it's important if you're following along that you're also in that sub directory
so that those files when you run the command, they exist in the same directory that you're running the actual commands. We're going to start the vault server. Unlike paths where we said Dash, Dev, we're gonna provide it with a configuration file
and started up,
you can see is a little different A little slower, Not quite The same output is when we were doing in the dev mode.
If I hop over to my client window on their involved status,
I'm going to get an air because I need to remember to export the environment. Variable again because, like with the dead mode, the way we've set this one up is to not use TLS
and then we're involved status again.
This time it succeeds. Fortunately, but as you could see, so seal type. Now you know what Shamir means. We've run this false as before. Talked about Shamir. Well, now you know what it is. Samir Shamir's secret sharing approach initialized is false and sealed is true. So that tells us two things wanted sealed so you couldn't get to the data.
But initialized is also false.
So the whole process of creating those five different keys which are used to generate the master key that hasn't even been done.
Let's go ahead and run that process right now. Vault operator
He quickly runs for us in the log over here for the server, you can see some some good stuff pre sealed, tear down, complete, just kind of giving you some insight into what the server was doing. But the shortened skinny is it created an unseal key, five of them as well as a route token. I want to save this information off to the side.
You should, too, because you're going to need this
and a little bit when we actually go through the unsealing process.
Then clear out the screen
and we've initialized it. Let's run another vault command here. Both status.
Okay, initialized is now true,
but it's still sealed. And in order to unseal of all, we have to go through the process of providing three of those unseal keys. And so far it's at zero of three progress in the unseal process. So let's start that unsealed process with another vault operator Command,
I'm gonna go with
Now you're gonna take which, ever one of those five keys which ever one is your favorite. You're gonna go ahead and copy and paste that into here. I don't recommend typing it out because it's a very long qi. Each one of those keys. Here we go unsealed. Progress is now one of three. So rinse and repeat sitting in
another one off the keys that you have.
So now we have two of three keys. At this point,
the vault is still sealed.
And if we were to run vault commands other vault commands, let's say fault. Secret list.
excuse me, it's secrets. Plural.
We get an air about the secrets engines. AP I press five or three years a performing, choking token Check. The vault is sealed, so we need to get through the third unseal operation to truly and fully unseal the vault.
And there we go.
Log says. Vault is unsealed. We'll look here. The vault information. It's been initialized. Yes, and sealed his false. The unsealing process was pretty manual,
and there are many times in situations where people want that vault server to come up automatically, and they don't want to have to manually go through the three steps of unsealing and importing three of the five keys.
There is a way to configure vault that I want to make sure the highlight
and have that Master Key, not Schardt id across five different key shares
but actually stored in a cloud. Vendors Key vault
is stored in an HSM or something like that. And if you look at the documentation, it's called the Seal Stanza that's put in the configuration file. We're gonna go deeper into the server configuration files and subsequent lessons, but I want to make sure you're made a prize of this and aware of it, because it is a very popular way
off managing the key vault. Here. You can see this is the
AWS seal, a tzar key vault if you're familiar with that Google and so forth.
So in certain circumstances, this could be very beneficial because starting up a server, it's up. Once it's up, the process gets up, it's running. It's gonna automatically reach out to wherever this key vote is. It's gonna pull it in, and it's gonna use the key there as the master key to unseal your vaults Data.
The downside to this is
how much do you trust that cloud key vault that has the master key? Right? It it's kind of a trade off, and you there is no single right answer you have to make that decision is an organization. Where do you feel is the weakest link? Is it that I need to be
restarting vault servers on a frequent basis? And I really want to streamline and optimize that process?
Or am I more concerned about keeping those keys five separate keys, making it that much more difficult for a hacker to find all the keys to reassemble and create the master key. So going back to the terminal here, if we had a circumstance, for whatever reason that
we felt our vault
had been compromised and you want to seal your vault without killing the actual process is running on the server. We can run the vault seal command, but in order to do that, you need to be a very high powered account typically is the root account. And so I need to make sure that I'm authenticated using my root account. So I'm gonna run the vault log in,
remember way back when we started and we performed the vault and knit operation. The initial route token was also generated and provided to us, so I'm gonna go ahead. I'm gonna paste that value in here and use that as my token. And so now you can see my token policies that route. So I am a very powerful user,
and from this point I can run the vault operator Seal Command
and now the vault is sealed.
Says it down here in the logs. If we were to perform any interactions with fault, we would notice that the vault has been field. In fact, let's just for good sake. Good measure. Let's access the Web user. You I and see what it has to say. Sure enough, the vault has been sealed. If I had and wanted to enter one of those five key shares,
I could enter this key share through the Web interface.
So everything we did in the unseal process by using the command line weaken, do through the Web interface and similarly weaken do through the rest a p I. And that wraps up our lesson on vault ceiling, an unsealing. So in this lesson, we learned about the Shamir's secret sharing, which is the basis
that vote uses to mass manage its master key.
We went through the process of unsealing our local vault instance. Then we actually sealed the instance as well. And we explored the auto unseal capabilities, which are very powerful if your circumstance allows for you to store the keys in a cloud key vault or you have a physical HSM that you can connect to
to pull that master key from.