Turtle shells all the way down
Security most of the times resembles turtle shells all the way down. You never seem to be able to stop creating the keys, secrets, rotating them, creating new software for them, and eventually the complexity of the levels of indirection creeps in.
A contrived example of something turning into turtle shells in a production enviornment could be a web server setup. Most people will setup a web server by adding a public/private key pair to the system in order to secure their HTTPS traffic. However, following guidelines and practices they might decide to encrypt their asymmetric private key using a symmetric AES cipher and pass phrase.
This looks great so far! Anyone who gets the private key will not be able to view the contents without the passphrase.
No problem, right?
None, until your web server needs to be rebooted and it asks for the pass phrase to be (re)entered.
Ah! But I will put the passphrase into a file and configure my apache/nginx/nodeJS nodes to read from there and do chmod/chown tricks on that file to keep things reasonably secure.
Well, now you have another secret on the file system and if they can read the private key, they probably can read that secret.
Ah, but I will actually create a virtual file system where I temporarily put the password file on startup (using maybe a vendor tool like vault) for only the short period the web server needs to startup correctly, then un-mount and delete the file using the linux command shred.
Well, now you have installed a vendor based product that requires 3 operators to seal and unseal it if you reboot the node running the vendor tool.
Ah, but I will either change that configuration to end these turtle shells or I will actually play by those additional rules.
Ok, well if you play by the additional rules you now you have to setup PGP keys and ensure that each operator has their private keys generated and they have those stored securely. Maybe with a AES symmetric key? ;-)
So on, so forth, until you find yourself almost a Certificate Authority and you’re reading over baseline requirements and forgot what you originally was trying to do a few weeks prior.
Along the way you also might realize you have accidentally messaged, emailed, or double copied a set of one of the private keys while creating these turtle shells with a initial passphrase somewhere and you need to start over and shred those areas or delete history knowing they could have leaked as you learn more of baseline requirements.
There’s nothing wrong with the levels of indirection as you harden, improve, and iterate over your security. Most companies grow and improve to the point of needing those levels of indirection.
In most cases a compromise of one section of the turtle shells will not impact the others below or above it and those are the reasons for the turtle shell model.
In other cases it is a convenience over security and cost consideration on how many turtle shells to deploy and maintain.
