Kickstart with LUKS
-
So before I got here, kickstarts have been done with a CD. I was going to implement a small HTTP server to hold the .cfg files and pull them in during the install. The issue is, in the .cfg file the LUKS password is plain text. So anyone with access to the network could open the .cfg file and read the LUKS passphrase. I haven't found an option to obfuscate the passphrase like with the root password or the GRUB password. Both of those have an
--iscryptedflag. Has anyone ran into this issue before? -
We could use NFS, but that kind of has the same issues, you would just need to know how to mount the NFS share (just obscuring the issue, not really solving it).
-
This reminded me of how TrueCrypt just got erased from history mysteriously. I wonder what happened with that.
EDIT: This is actually not true. I stand corrected.
-
@wirestyle22 said in Kickstart with LUKS:
This reminded me of how TrueCrypt just got erased from history mysteriously. I wonder what happened with that.
No it didn't. It is alive and kicking. It was forked and is now the popular VeraCrypt project hosted by Microsoft's open source code repository. TC is doing very well and is anything but erased, it is more well known now than before.
-
Having used LUKS for a massively large and insanely high security environment... there is no way to have its password exist on the same system that you want decrypted without completely defeating the entire purpose. No matter how you encrypt it, it has to ultimately be easily decrypted for it to be automated.
Using LUKS means that you are either going to build your own external security automation system using other systems OR you are going to have a human intervene on every reboot. Those are the only options.
-
@scottalanmiller said in Kickstart with LUKS:
Having used LUKS for a massively large and insanely high security environment... there is no way to have its password exist on the same system that you want decrypted without completely defeating the entire purpose. No matter how you encrypt it, it has to ultimately be easily decrypted for it to be automated.
Using LUKS means that you are either going to build your own external security automation system using other systems OR you are going to have a human intervene on every reboot. Those are the only options.
We plan on having a person be at the machine for the reboot password, however I'm just trying to figure out a way to initially set up the password without it being plain text.
I was kind of looking for an
--iscryptedoption like with the root and GRUB passwords. If it's not an option, we can go another way, but I was hoping to obfuscate the password in the kickstart file just for the initial install. -
@scottalanmiller said in Kickstart with LUKS:
@wirestyle22 said in Kickstart with LUKS:
This reminded me of how TrueCrypt just got erased from history mysteriously. I wonder what happened with that.
No it didn't. It is alive and kicking. It was forked and is now the popular VeraCrypt project hosted by Microsoft's open source code repository. TC is doing very well and is anything but erased, it is more well known now than before.
I stand corrected. Good to hear!
-
@johnhooks said in Kickstart with LUKS:
We plan on having a person be at the machine for the reboot password, however I'm just trying to figure out a way to initially set up the password without it being plain text.
Oh okay. Can't think of a good way for that either
-
Just something coming to mind: What about storing the LUKS key in the TPM module and let LUKS retrieve it?
Found a few topics about that on a quick search. -
@thwr said in Kickstart with LUKS:
Just something coming to mind: What about storing the LUKS key in the TPM module and let LUKS retrieve it?
Found a few topics about that on a quick search.Ill take a look at that, thanks. From some other places I've seen if you just don't supply a passphrase, it will ask you for one during the kickstart. This is fine since we will be at the workstation to initiate the kickstart.
-
@thwr said in Kickstart with LUKS:
Just something coming to mind: What about storing the LUKS key in the TPM module and let LUKS retrieve it?
Found a few topics about that on a quick search.If you do that, how do you keep them from being read out automatically?
-
@scottalanmiller oh, that was just one of these "what if" moments. Never played with TPM, but used to play with smartcards and their "secure elements" a bit.
Just took a look into TPM. From https://en.wikipedia.org/wiki/Trusted_Platform_Module: "[...] Trusted Platform Module [...] also includes capabilities such as [...] sealed storage [...]".
Digging a bit deeper, I found this: LUKS support for storing keys in TPM NVRAM https://github.com/shpedoikal/tpm-luks
Looks promising
-
Just did some more reading. From the tpm-luks site:
D. Sealing your NVRAM area to PCR state
Sealing means binding the TPM NVRAM data to the state of your machine. Using sealing, you can require any arbitrary software to have run and recorded its state in the TPM before your LUKS secret would be released from the TPM chip. The usual use case would be to boot using a TPM-aware bootloader which records the kernel and initramfs you've booted. This would prevent your LUKS secret from being retrieved from the TPM chip if the machine was booted from any other media or configuration."This would at least prevent someone grabbing the key from owning the hardware alone. I guess we are still facing the chicken-egg-dilemma here. But, what if we don't place the actual key in TPM but to an external webservice maybe?
- Have some password / RSA key stored in TPM
- Retrieve it during the grub stage from TPM
- Ask the webservice to give you the key by providing the password / your key
This way, we don't have the actual key on the hardware itself and the webservice can only be queried during boot. This would require some hacking in tpm-luks, but the longer I think about it... could be a valid solution.
Conn: Works only on-site, so not a good solution for notebooks. You will also need some kind of access to your network (NIC drivers and TCP/IP stack).
Edit: Some more reading on TPM and LUKS: http://resources.infosecinstitute.com/linux-tpm-encryption-initializing-and-using-the-tpm/
-
@thwr I think that storing on the TPM is good if the goal is only to prevent the drives from walking and not the server. You could do that with SD card or something too, but TPM is obviously better (unless the server gets damaged and you lose all of your data.)
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
-
What I had proposed to a bank some years ago was having a system by which a decryption script would call out to a service on the LAN and request the passphrase. It's not nearly as secure as a person, but you could put a lot of security in place if needed (make it check with a person via email before releasing it, only do it for planned reboots or at certain times, etc.) This way if a server is stolen, it's totally encrypted. You would need to have two, unrelated breaches, in order to access the encrypted drives. Could still happen, but it would eliminate the human break point while adding a technical one. But it would allow systems to be rebooted automatically while keeping them encrypted.
-
@scottalanmiller said in Kickstart with LUKS:
What I had proposed to a bank some years ago was having a system by which a decryption script would call out to a service on the LAN and request the passphrase. It's not nearly as secure as a person, but you could put a lot of security in place if needed (make it check with a person via email before releasing it, only do it for planned reboots or at certain times, etc.) This way if a server is stolen, it's totally encrypted. You would need to have two, unrelated breaches, in order to access the encrypted drives. Could still happen, but it would eliminate the human break point while adding a technical one. But it would allow systems to be rebooted automatically while keeping them encrypted.
My proposal is basically the same, just adding TPM as a secure element to the equation. Using TPM, we can be sure that the machine pulling the key from LAN is actually ours / a known one.
We like to see the best possible security approach at work as a combination of knowing (e.g. passwords, PINs), being (e.g. biometrics or TPM here) and owning (smartcards or RSA tokens for example). The more factors you bring in, the better. -
@thwr said in Kickstart with LUKS:
My proposal is basically the same, just adding TPM as a secure element to the equation. Using TPM, we can be sure that the machine pulling the key from LAN is actually ours / a known one.
IP Address that is local will do that pretty well too. The two together is ideal. TPM only, the machine might be removed from the location and still used if network access is found. If IP only, the request might be a different machine using the stolen ones IP address. Put the two together for even more security.
-
@scottalanmiller said in Kickstart with LUKS:
@thwr I think that storing on the TPM is good if the goal is only to prevent the drives from walking and not the server. You could do that with SD card or something too, but TPM is obviously better (unless the server gets damaged and you lose all of your data.)
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
You would need to reset TPM as you would reset your HDD. In fact, it should be good enough to reset the TPM. You could store the passphrase / key additionally on some secure place outside of the individual host - better safe than sorry.
-
@thwr said in Kickstart with LUKS:
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.
For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.
Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.
-
@thwr said in Kickstart with LUKS:
@thwr said in Kickstart with LUKS:
But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.
Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.
For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.
Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.
Exactly, something externally has to trust that the system is where it is supposed to be physically so that it will release the key. We considered using this but decided that security trumped downtime and kept the system requiring human intervention and just accepted large downtimes in the event of a reboot.
