Kickstart with LUKS
-
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.
-
@scottalanmiller said in Kickstart with LUKS:
@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.
Agree, downtime due to a misconfiguration, some failure on the network or the key server would be an issue. What if we look at some back approach: If some removeable storage with a key is present at boot, LUKS will use this key. Otherwise, it tries to pull it from the key server as described above? Should be pretty solid and a backup is in place (key on USB stick) in case something goes south.
This surely is an approach for environments requiring a very high level of security, but I like the idea.
-
@thwr said in Kickstart with LUKS:
@scottalanmiller said in Kickstart with LUKS:
@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.
Agree, downtime due to a misconfiguration, some failure on the network or the key server would be an issue. What if we look at some back approach: If some removeable storage with a key is present at boot, LUKS will use this key. Otherwise, it tries to pull it from the key server as described above? Should be pretty solid and a backup is in place (key on USB stick) in case something goes south.
This surely is an approach for environments requiring a very high level of security, but I like the idea.
I've seen places do that, pop in a key and use that, but you have to trust that people will remove it immediately and store it somewhere.
