Is there some documentation that I can use ?

[rohde-schwarz]

Is there some documentation that I can use ?

[johnwallace123]

@hunter86bg: TrustedGRUB2 only enables the ability to automatically unlock these, but actually coming up with a method is beyond the scope. For solutions, I would suggest that you look at tpm-luks.

For our solution, we forked the original tpm-luks, and you can see our fork at https://github.com/GeisingerBTI/tpm-luks. I'll work an making the README better, but you'll have to note that we require a feature add to tpm-tools, which you can find at https://github.com/GeisingerBTI/tpm-tools.

I'd be happy to help you automatically unlock your LUKS partition offline if you'd like. Having your feedback will help us make the software better and increase the usability of the documentation.

[hunter86bg]

I agree that it is out of the scope. I opened this "issue" just because I realize that I don't know nothing about the logic behind the TrustedGrub 2.If you wish, we can switch to email communication , in order not to spam the issues section on github.
My mail is [email protected]

[neusdan]

Feel free to discuss this topic here. You're probably not the only person with this kind of questions.

[hunter86bg]

Thanks for the support.
Now, let me present my understanding of the whole process. As I'm new to TPMs - it could be completely wrong.
Current Setup:
1.Centos 7 (latest updates)
2.TrustedGrub 2 installed (grub.cfg and device.map taken from the regular grub)
3.Services "tcsd.service" and "pkcsslotd" are enabled and running
4.Ownership taken with "tpm_takeownership -z"
5.PCRs (00-23) available at /sys/class/tpm/tpm0/device/pcrs

As far as my limited understanding is, the whole process should go like this:
1.BIOS makes initial checks
2.TrustedGrub2 loads (stage 2 with kernel menu)
3.The TPM checks the PCRs and if everything is unmodified (PCRs available match the configured ones), the TPM unseal the key for LUKS device.
4.LUKS opens the device and the boot process resumes as usual.

Now, I have to figure out:
1.How to make the communication between the TPM and LUKS
2.Verify that modification of kernel parameters or adding a USB stick makes LUKS to ask for password.

[johnwallace123]

@hunter86bg, I'd say you've got a pretty good handle on the boot process.

Once TrustedGRUB2 hands off to the kernel (immediately after the initrd command), the PCRs should be set for verification. Now, it's up to the scripts run at initialization to do the following:

1. Find the key file to be used for LUKS unlocking
2. Verify through the TPM that the PCRs are set "as expected"
3. Attempt to use the unsealed key to unlock the LUKS partition
4. If unlocking fails, fall back to passphrase

In the original tpm-luks (https://github.com/shpedoikal/tpm-luks), the key file was stored in the NVRAM of the TPM, and was configured to only be readable when the PCRs are "as expected." I found this method to be difficult and error prone, so I decided to change it to store a key file that was sealed to a given set of PCRs on the unencrypted /boot partition. However, this design change meant that I had to do the following in my initialization script:

• Mount all filesystems present in the computer (other than the one I'm attempting to unlock)
• Search the filesystem for a filename (given in tpm-luks.conf)
• Attempt to unseal the data
• Attempt to unlock the LUKS partition with the unsealed file

In our case, adding a USB stick wouldn't create a password fallback. In fact, the script would likely attempt to mount the USB stick and search it for the sealed keyfile.

As for the modification of kernel parameters getting a password fallback, that can be accomplished by verifying that PCR 11 is "as expected." That is, by far, the most difficult piece of the process. Some have taken the approach of simplifying the grub.cfg to a strictly linear command set, which is then easy to precompute. Personally, I have taken to using the TPM event log to generate a heuristic of "given the hashes at last boot, and assuming that grub.cfg hasn't changed too much, what should the next boot path be?"

And I definitely agree with @neusdan, that this is a great place to ask those questions and get feedback from the community. My apologies if my originial response sounded cranky or standoffish; that was not my intention at all.

[morbitzer]

After playing around a bit with tpm-luks, I also decided that it didn't really match what I needed.
Instead, I created my own scripts that seal the secret in the NVRAM. So mainly I had to put some things, such as the tcsd-daemon, in the initrd. In the end, I achieved that my system will refuse to unlock the LUKS-partition if you even select another GRUB-entry.

@hunter86bg I did make a repo for my documentation. You can find it here
I have done all of this using Debian, so the process might differ slightly for CentOS (for example, CentOS uses dracut insteat of initramfs tools). Still, I hope that it is useful to you.

However, I would also agree that longterm, it would be better to have a working tpm-luks, so I will have a look at the repo of @johnwallace123

I would be happy for feedback on my approach. For example if it would be better to store the secret in a sealed file and use TrustedGRUB2 to decrypt the LUKS-partition, instead of doing it in the initrd as I do now.

[johnwallace123]

@morbitzer: I took a look at your repo, and it looks like a very interesting approach. If you find my repo helpful, I greatly welcome a PR to add packaging for Debian. I've only built RPMs, so that's what I'm familiar with.

I also agree that the initrd is the best place to unlock the LUKS-partition. It gives you options on where to store the key (NVRAM, sealed key on /boot, USB stick). The down side is that messing with the initrd isn't a particularly pleasant experience :).

[securitykernel]

Unfortunately, this project is deprecated and no longer maintained. I will be closing this issue.