Cybersecurity engineer here, these are all great answers I just wanted to add a couple tidbits.
-
Where are the keys stored: In enterprise level security, you never want to store your key in the same system you are securing, so you normally use a “Key manager” or an “HSM” (Hardware security module) These are hardened appliances dedicated to generate keys and store them, then other devices that then use protocols such as KMIP or API calls to retrieve them remotely. The key is encrypted in transfer and never stored permanently in the client that is being encrypted. There’s also a key encryption mechanism … but let’s not goo too far into it. I’ll just mention that there’s usually a data encryption key (DEK) and a Key Encryption Key (KEK) and the DEK is never exposed. HSMs themselves are basically physical key managers that have a tamper proof crypto module built in. Think of them as TPM2 on steroids. If you want to read more about these guys check out the FIPS specification that they’re built to. https://en.wikipedia.org/wiki/FIPS_140-3
-
How does the OS know which key to use: It doesn’t There is usually overlay software than handles this part, typically called an “encryption agent” that runs in the kernel space. Even tho most software is based on open source, encryption agents are usually very complex and secretive. My company’s filesystem encryption agent for example embeds 4Kb of metadata on every file with the name of the key that was used to encrypt it to prevent double encryption and help in file restoration. When a file request comes into the OS, we are loaded into the kernel and use a “filter driver” to decide if the file is encrypted or not, and if it’s encrypted, we route the file request to a virtual file system that then pipes it to our software for processing ACLs and decryption. If you want to learn more you can check out this brochure. https://cpl.thalesgroup.com/encryption/transparent-encryption
Happy to answer any questions.
No one else knows about iode os?
https://iode.tech/iodeos/