this was such an amazing explanation, thanks a ton I'm doing research on how web3 authentication providers and password-less auth providers manage keys securely and naturally HSMs came up appreciate the illustrations and simple before/after diagrams!
Nothing does. The HSM only stops the hacker from taking the key, but it doesn't handle the attack you mentioned. The good part is that if the hacker decrypts using the HSM, the use will be logged by the HSM's audit log. Secondly, if access to the HSM is cut off, the hacker can't decrypt anymore. Both of these are better than if the hacker steals the key.
Well, definitely HSM has its benefits in many many ways. But if the service is compromised, then the hacker can not only read the key (without HSM), but also read the returned output from the HSM (with HSM), no? So this is just a part of a security implementation but other things should be taken care of too. Great video by the way. Really liked your way of explaining the complex mechanism. Kudos 👏
Hi, thank you for the explanation..it was good and very clear. I hope hope you can enlighten me on the following: if the service get compromised, can the malicious actor obtain the decrypted text from the HMS?
You explained this so effortlessly but have a question, You mentioned that Service is calling HSM to decrypt the encrypted text and HSM decrypts and sends back the row text, but how service calling to HSM, service must need to pass some sort of info (I mean some kind of key again) so HSM can validate that this is the legit request and let me decrypt it now. I f you answer this then i have follow-up question
The public and private keys work together. The HSM private key can only decrypt the message if it was encrypted with a corresponding public key. Otherwise it will(and it should) fail.
When the service calls the HSM, it needs to pass valid credentials. The HSM has a list of valid username and passwords in it, and the service needs to provide valid credentials to use the HSM.
Hi Alex, very good explanation on HSM - many thanks for that. Now I need to understand the differences between HSM and SHE. Seems to be related to the decoding capabilaties (symetric vs. asymetric key) - any hint?
Yes but if all it takes is to instruct the service to make a call to HSM to get the decrypted info what prevent an Hacker to just use that service to send that call request to the HSM?
Great question! It's true that a hacker can use the service to send a request. However, two things are better than not using the HSM: 1. The calls will show up in the audit logs of the HSM, which can help you figure out what data's been decrypted. 2. You can shut off access from the service to the HSM to cut off the hacker. Without the HSM, if the hacker has the encrypted data and the key, there's nothing you can do about it.
so is the HSM a separate system that is attached to the network? Also, if we have a really popular website that gets many requests and has multiple webservers, each time a request comes in it would need to contact the HSM to perform encryption. This means that the HSM will be getting lots of traffic so is it possible to have multiple HSMs and load balance between them?
Fantastic explanation! The HSM is tamper-proof by erasing the key when it's physically compromised. But then how are all the encrypted data decrypted afterwards?
If the key is erased, then the encrypted data can't be decrypted. But, if you think about it, if someone steals the HSM and it doesn't erase the key, you've still lost the key because the attacker stole it!
That's why you have "multiple HSMs" within your Security Domain for high availability. I would imagine most companies probably use 3 or more HSMs for utmost protection. That way if an HSM was stolen, failed or whatever, you still have the keys balanced amongst the HSMs or that can be re-generated across the other available HSMs.
I feel I may be misunderstanding but does this not simply shift the problem to finding a safe way to access the HSM? If a hacker were to compromise the system, couldn’t they simply make fake requests to the HSM themself?
Nice presention indeed + so what happen if HSM cheap or board manufacturer is set to prevent you from using hardware that the manufacturer don't agree with? like Microsoft preventing older hardware from being used on Windows 11 for example?
Ok I see the benefits. But if an attacker has access to the service, he can make the same API calls to the HSM and use it to sign malicious data for example, correct?
Great explaination but i wonder what if the attacker attacks the service and act as the service and requested to the HSM. How does the HSM knows the service is genuine, not an attacker?
When the service calls the HSM, it needs to pass valid credentials. The HSM has a list of valid username and passwords in it, and the service needs to provide valid credentials to use the HSM. So it's not possible to call the HSM out of the blue, since you need valid credentials. If the service is compromised, it might be able to make bad requests using the service's credentials. There's not really a way to prevent this since a service being compromised means that an attacker can do anything the service does. The advantage of the HSM is that a service being compromised does not leak the keys.
Thank you for the concise explanation! Some of the explanations that I found prior to this made it sound like one would retrieve the key from the HSM, not the encrypted or decrypted values. /edit typos
Here's the question I have Alex, that I've yet to see anyone break down and explain it succinctly. We're talking about protecting the Service Key that is on say, a Windows Server running Microsoft SQL Server. The question I have is, what are the precise steps whereby the Key, that is created on the HSM, what is it called? i.e. KEK, Public/Private Key Pair, etc.? And does it encrypt/decrypt the key on the SQL Server via this "mystery HSM Key", and what is that process? I've yet to find anyone who can break down how this process works in finer detail. You're steps are great but I think they need a further breakdown in the process. Thank you again for your great videos!
This is a slightly different topic from HSMs, which is cryptography and encryption. It depends on what the setup is for protecting this key, which I don't have a clear understanding of from your description. Keys are usually generated inside the HSM, so that they never ever leave the HSM. So if you want to protect _another_ key, you can use the HSM to encrypt the key. Normally, a HSM would encrypt data, but in this case, your service key is just another piece of data, so you can encrypt it with the HSM key. Then, you store the encrypted key somewhere. When you want to use the key, you ask the HSM to decrypt your encrypted key, getting the original key, then you use the key and then delete it from memory when you're done. This is a technique called envelope encryption. Hope that helps!
It's actually pretty simple - with SQL in particular, when you enable encryption you're actually enabling SQL to create and use a LOCAL (to the SQL server) symmetric key (the same key is used to encrypt and decrypt; usually a smaller bit length and much faster than asymmetric keys by several orders of magnitude. Commonly AES256 algorithm.) Obviously, having the key with the server is bad (as Alex explained in this example) but moving that key off to an HSM would be equally bad (as it would introduce significant latency and hamper performance.) Instead, when we introduce an HSM to the architecture - SQL will utilize the HSM to "wrap" the local symmetric SQL key with an asymmetric key pair (usually RSA - i.e. public/private keys) that are protected within the HSM. You're basically encrypting the local SQL key so that if the key and data are stolen - the data itself is encrypted by that local SQL key but the key itself is also encrypted externally - thus you can't decrypt that data. You'd have to have access to that asymmetric key within the HSM. It usually only decrypts the key during startup in the case of SQL (not every database does it the same - Oracle is different.) No latency is introduced as the local key is cached in its unencrypted state. This doesn't prevent an attacker from gaining access to the database itself and reading data, only protects against an attacker exfiltrating the file that contains the database (and it's local decryption key.) To truly protect against an attacker getting the data, you have to encrypt the data at the column level within the database itself. This is usually done with software although there are some HSM's out there that can do it as well (which protect the key material to do so much better than software will.)
What about a web app which needs to query its data from the database? Does the index work? Isn't it super slow to query for the keys after query the actual data from the db?
If you mean "can you use an index with encrypted data", the answer is no, since the data is scrambled while it's in the database. Let me know if I misunderstood your question.
If you have a table with a column C, and you want to do a query like "SELECT * WHERE C = 'something'", and you encrypt the data in C with a symmetric deterministic method before storing it in the table, then you can find rows with "SELECT * WHERE C = 'encrypt(something)'", but you won't be able to do range queries like "SELECT * WHERE C > something" or "ORDER BY C". In addition, deterministic encryption is less secure than encryption that uses a randomized initialization vector because it means that if you encrypt the same thing twice, it will have the same ciphertext. So it would be possible to find matching groups of Cs in your table, which, depending on what you're building, could be pretty bad. I cover some of this in my encryption video ua-cam.com/video/AXkRoFOP-ug/v-deo.html Hope that helps!
![[UA] Eternal Fire проти NAVI | EPL Season 20 Malta](http://i.ytimg.com/vi/chvlsDygrZM/mqdefault.jpg)
I am literally on this page after typing HSM into youtube search and getting High School Musical.
I wish you have more and more videos. I found your encryption video today and then watched all of your videos in a single sitting.
this was such an amazing explanation, thanks a ton
I'm doing research on how web3 authentication providers and password-less auth providers manage keys securely and naturally HSMs came up
appreciate the illustrations and simple before/after diagrams!
what stops the hacker from simply calling the HSM from the server running the service and letting the HSM do all the work for them?
Nothing does. The HSM only stops the hacker from taking the key, but it doesn't handle the attack you mentioned. The good part is that if the hacker decrypts using the HSM, the use will be logged by the HSM's audit log. Secondly, if access to the HSM is cut off, the hacker can't decrypt anymore. Both of these are better than if the hacker steals the key.
This channel is underrated. I never found a better explanation before I watched this video. Keep up the good work!
plain and simple explanation, great job
Great explanation!!
Excellent, simple and to the point...
thanks alot you deserve a thumps up
Well, definitely HSM has its benefits in many many ways. But if the service is compromised, then the hacker can not only read the key (without HSM), but also read the returned output from the HSM (with HSM), no?
So this is just a part of a security implementation but other things should be taken care of too.
Great video by the way. Really liked your way of explaining the complex mechanism. Kudos 👏
Perfectly explained and well done 👍
Fantastic video. Thank you.
Really well explained !!. Thank you so much
great explanation! Exactly what I was looking for!
woww this was so clear 🤩
Mannnnnnnnn This was the best, and simplest HSM explanation ever!
Thanks you very much for your clear explanation
Good Explanation
Thanks for this, really great video! 😊
Such an amazing video!!! Thanks you :)
Great overview!! Thanks!
Awesome explanation!
Hi, thank you for the explanation..it was good and very clear. I hope hope you can enlighten me on the following:
if the service get compromised, can the malicious actor obtain the decrypted text from the HMS?
You explained this so effortlessly but have a question, You mentioned that Service is calling HSM to decrypt the encrypted text and HSM decrypts and sends back the row text, but how service calling to HSM, service must need to pass some sort of info (I mean some kind of key again) so HSM can validate that this is the legit request and let me decrypt it now. I f you answer this then i have follow-up question
The public and private keys work together. The HSM private key can only decrypt the message if it was encrypted with a corresponding public key. Otherwise it will(and it should) fail.
When the service calls the HSM, it needs to pass valid credentials. The HSM has a list of valid username and passwords in it, and the service needs to provide valid credentials to use the HSM.
Very helpful thanks
Hi Alex, very good explanation on HSM - many thanks for that.
Now I need to understand the differences between HSM and SHE. Seems to be related to the decoding capabilaties (symetric vs. asymetric key) - any hint?
Great video! Can you do one on a hierarchy of different types of keys used with HSM and their use cases? Struggling to understand this
Yes but if all it takes is to instruct the service to make a call to HSM to get the decrypted info what prevent an Hacker to just use that service to send that call request to the HSM?
Great question! It's true that a hacker can use the service to send a request. However, two things are better than not using the HSM:
1. The calls will show up in the audit logs of the HSM, which can help you figure out what data's been decrypted.
2. You can shut off access from the service to the HSM to cut off the hacker. Without the HSM, if the hacker has the encrypted data and the key, there's nothing you can do about it.
so is the HSM a separate system that is attached to the network? Also, if we have a really popular website that gets many requests and has multiple webservers, each time a request comes in it would need to contact the HSM to perform encryption. This means that the HSM will be getting lots of traffic so is it possible to have multiple HSMs and load balance between them?
Fantastic explanation! The HSM is tamper-proof by erasing the key when it's physically compromised. But then how are all the encrypted data decrypted afterwards?
If the key is erased, then the encrypted data can't be decrypted. But, if you think about it, if someone steals the HSM and it doesn't erase the key, you've still lost the key because the attacker stole it!
@@StudyingWithAlex how about a tpm?
That's why you have "multiple HSMs" within your Security Domain for high availability. I would imagine most companies probably use 3 or more HSMs for utmost protection. That way if an HSM was stolen, failed or whatever, you still have the keys balanced amongst the HSMs or that can be re-generated across the other available HSMs.
great video, can you do something on code signing ...
I feel I may be misunderstanding but does this not simply shift the problem to finding a safe way to access the HSM? If a hacker were to compromise the system, couldn’t they simply make fake requests to the HSM themself?
Nice presention indeed +
so what happen if HSM cheap or board manufacturer is set to prevent you from using hardware that the manufacturer don't agree with?
like Microsoft preventing older hardware from being used on Windows 11 for example?
Ok I see the benefits. But if an attacker has access to the service, he can make the same API calls to the HSM and use it to sign malicious data for example, correct?
Found the answer further below on another comment
which type of HSMs are most secured and yet affordable?
"I've read thousands of lines of documental mess so you don't have to"
Great explaination but i wonder what if the attacker attacks the service and act as the service and requested to the HSM. How does the HSM knows the service is genuine, not an attacker?
When the service calls the HSM, it needs to pass valid credentials. The HSM has a list of valid username and passwords in it, and the service needs to provide valid credentials to use the HSM. So it's not possible to call the HSM out of the blue, since you need valid credentials. If the service is compromised, it might be able to make bad requests using the service's credentials. There's not really a way to prevent this since a service being compromised means that an attacker can do anything the service does. The advantage of the HSM is that a service being compromised does not leak the keys.
@@StudyingWithAlex thanks for the detail explaination. Keep up the good work here. 👍🏻
may i ask what is server modules and add ons and how it works?
is ther any opensource HSM avilable to run our own ? also how to conduct key ceremonies ?
HSMs are a piece of hardware, so it's something you'll need to buy or build yourself. As for key ceremonies, that's part of the HSM feature set.
Bro why is there some siren noise in the background of your video lol
Help me
526802
Thank you for the concise explanation! Some of the explanations that I found prior to this made it sound like one would retrieve the key from the HSM, not the encrypted or decrypted values.
/edit typos
Depends on the HSM type and vendor implementation.
Example MKEK is stored on HSM and wraps all other keys off the box in an encrypted format.
don't stop keep posting (y) well done!!
Here's the question I have Alex, that I've yet to see anyone break down and explain it succinctly. We're talking about protecting the Service Key that is on say, a Windows Server running Microsoft SQL Server. The question I have is, what are the precise steps whereby the Key, that is created on the HSM, what is it called? i.e. KEK, Public/Private Key Pair, etc.? And does it encrypt/decrypt the key on the SQL Server via this "mystery HSM Key", and what is that process? I've yet to find anyone who can break down how this process works in finer detail. You're steps are great but I think they need a further breakdown in the process. Thank you again for your great videos!
This is a slightly different topic from HSMs, which is cryptography and encryption. It depends on what the setup is for protecting this key, which I don't have a clear understanding of from your description. Keys are usually generated inside the HSM, so that they never ever leave the HSM. So if you want to protect _another_ key, you can use the HSM to encrypt the key. Normally, a HSM would encrypt data, but in this case, your service key is just another piece of data, so you can encrypt it with the HSM key. Then, you store the encrypted key somewhere. When you want to use the key, you ask the HSM to decrypt your encrypted key, getting the original key, then you use the key and then delete it from memory when you're done. This is a technique called envelope encryption. Hope that helps!
It's actually pretty simple - with SQL in particular, when you enable encryption you're actually enabling SQL to create and use a LOCAL (to the SQL server) symmetric key (the same key is used to encrypt and decrypt; usually a smaller bit length and much faster than asymmetric keys by several orders of magnitude. Commonly AES256 algorithm.) Obviously, having the key with the server is bad (as Alex explained in this example) but moving that key off to an HSM would be equally bad (as it would introduce significant latency and hamper performance.) Instead, when we introduce an HSM to the architecture - SQL will utilize the HSM to "wrap" the local symmetric SQL key with an asymmetric key pair (usually RSA - i.e. public/private keys) that are protected within the HSM. You're basically encrypting the local SQL key so that if the key and data are stolen - the data itself is encrypted by that local SQL key but the key itself is also encrypted externally - thus you can't decrypt that data. You'd have to have access to that asymmetric key within the HSM.
It usually only decrypts the key during startup in the case of SQL (not every database does it the same - Oracle is different.) No latency is introduced as the local key is cached in its unencrypted state. This doesn't prevent an attacker from gaining access to the database itself and reading data, only protects against an attacker exfiltrating the file that contains the database (and it's local decryption key.) To truly protect against an attacker getting the data, you have to encrypt the data at the column level within the database itself. This is usually done with software although there are some HSM's out there that can do it as well (which protect the key material to do so much better than software will.)
What about a web app which needs to query its data from the database? Does the index work? Isn't it super slow to query for the keys after query the actual data from the db?
If you mean "can you use an index with encrypted data", the answer is no, since the data is scrambled while it's in the database. Let me know if I misunderstood your question.
@@StudyingWithAlex what about a symmetric deterministic encryption? Does the index search work with that?
If you have a table with a column C, and you want to do a query like "SELECT * WHERE C = 'something'", and you encrypt the data in C with a symmetric deterministic method before storing it in the table, then you can find rows with "SELECT * WHERE C = 'encrypt(something)'", but you won't be able to do range queries like "SELECT * WHERE C > something" or "ORDER BY C". In addition, deterministic encryption is less secure than encryption that uses a randomized initialization vector because it means that if you encrypt the same thing twice, it will have the same ciphertext. So it would be possible to find matching groups of Cs in your table, which, depending on what you're building, could be pretty bad. I cover some of this in my encryption video ua-cam.com/video/AXkRoFOP-ug/v-deo.html Hope that helps!