I’m trying to make my openvpn work with my TPM chip, in order to authenticate using a client certificate, with the private key encrypted and protected by TPM.
I did create the key, and the CSR, and got it signed by my CA so I have the client cert. After some struggle I’m able to connect from the command line (as root running openvpn explicitly). But I have to give the --engine tpm switch to openvpn. I can’t figure out how to add this to a NetworkManager VPN connection.
Does anyone know a way? Or does anyone perhaps know of any alternative openssl or openvpn or networkmanager build in some OpenSuse build service repo that could help accomplishing this?
What about using openssl-3 with openvpn? In openssl-3 “engine” has been replaced with “provider”. Does that eliminate the need of command line arguments for using TPM?
He has patched openssl so that it automatically selects the TPM engine based on the key file content. Plus other patches e.g. making the engine first try the “well-known secret” in case the SRK is set to that.
A James Bottomley also has a OpenSuse build service repo. So I suspect that repo contains the patched packages. Remains to be tried out:
I am not intimately familiar with OpenVPN, but you may try passing similar URI where key is expected omitting --engine parameter. If it works, you may try using the same URI for the key in NetworkManager configuration (I have seen examples of PKCS#11 URI for 802.1x keys).
I tried to use the same with TPM 1.2 engine, but it segfaults, at least during some operations. I also am not sure whether OpenSSL 1.1 already implements it.
Yes I am trying to make this work on an old laptop with TPM 1.2. I think the same difficulties apply on a TPM 2.0 host with OpenSuse though.
OpenVPN on OpenSuse is built against OpenSSL 1.1. I suspect building OpenVPN against OpenSSL 3 instead could solve the issue by allowing key file patterns like the one you suggest in the OpenVPN config file.
Or one could build OpenVPN against GNUTLS which also supposedly handles TPM keys.
Then again I’m not sure NetworkManager OpenVPN functionality would work straight off with such configured OpenVPN.
I’m surprised this still not works out-of-the box on all major Linux distros today. TPM 1.2 has been around since 2011 and TPM 2.0 since 2015. Secure boot works and uses TPM, but applications dont.
@svyatko: yes, but the problem is that openvpn (as configured in opensuse) requires command line arguments --engine tpm in order to use the tpm openssl engine. And networkmanager doesn’t have any way to add that command line argument to openvpn.
And as for secure boot: as far as I understand OpenSuse had this working for years. They even have “trusted boot” working, which ensures that a number of critical components are untampered, ultimately based on signatures saved in or protected by the TPM hardware. At least I’ve had “trusted boot” enabled for years now, hoping that it does this right
TrustedGrub2 supports legacy BIOS platform only and measures grub and kernel components to PCR(s). I am not aware of any higher layer that actually used these measurements. Theoretically systemd-cryptsetup supports it, although I am not sure about quality of this support in the version in Leap 15.4, and it still does not allow unsealing of root in grub itself. Today stock grub2 supports TPM(2) and on Tumbleweed is integrated in FDE which means grub2 can be configured to inseal root LUKS key based on PCR measurements, which allows unattended boot when grub2 is installed on encrypted root.
I’m using an old HP laptop with TPM 1.2. The BIOS is set to EFI boot. I always selected “secureboot” and “trustedboot” in opensuse. I’ve done so for years and there is no indication that this doesn’t work. Could it be that stock grub2 also supports TPM 1.2 (and EFI mode)? Or are you telling me that this just silently has never worked? (I’m currently not using disc encryption though, but I expected at least boot loader and kernel to be checked against TPM checksums on boot).
“Secureboot” in YaST bootloader settings is unrelated to TPM and simply makes shim the primary bootloader. For all I can tell, “trustedboot” is only used on legacy BIOS and. This option configures system to use TrustedGRUB2 instead of normal grub2 package.
And who is supposed to do it? Bootloader is loaded by the firmware, so it must be firmware that does this check. grub2 most certainly does not check anything against TPM checksums, at least directly. It only uses TPM2 to unseal LUKS key, and it does not itself checks anything, it simply asks TPM to decrypt it if current PCR values match the predefined ones.
You obviously understand this better than me. But still - selecting “secureboot” and “trustedboot” does NOT trigger trustedgrub2 to be installed on my laptop. It indicates that something in grub2 is supposed to perform the check of at least the kernel image. Also some googling seems to indicate that trustedgrub2 is an abandoned project. Perhaps because the functionality was included in grub2 ?
If not, what are these entries in the grub2 changelog about? See grub changelog
6665 2018-12-12 Matthew Garrett <matthewgarrett@google.com>
6666
6667 verifiers: Add TPM documentation
6668 Describe the behaviour of GRUB when the TPM module is in use.
6669
6670 Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
6671
6672 2018-12-12 Matthew Garrett <mjg59@google.com>
6673
6674 verifiers: Core TPM support
6675 Add support for performing basic TPM measurements. Right now this only
6676 supports extending PCRs statically and only on UEFI. In future we might
6677 want to have some sort of mechanism for choosing which events get logged
6678 to which PCRs, but this seems like a good default policy and we can wait
6679 to see whether anyone has a use case before adding more complexity.
6680
6681 Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
6682
6683 2018-12-12 Matthew Garrett <mjg59@google.com>
6684
6685 verifiers: Verify commands executed by grub
6686 Pass all commands executed by GRUB to the verifiers layer. Most verifiers will
6687 ignore this, but some (such as the TPM verifier) want to be able to measure and
6688 log each command executed in order to ensure that the boot state is as expected.
6689
6690 Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
6691
Yes, it does. As I already told you - grub (trustedgrub2 or grub2) measures boot time components. Nothing more. It is up to other software to actually verify that these measurements match expectations and do something if they do or do not.
Right, so you said, and now I get it. Thanks for bearing with me.
So conclusion is: “trusted boot” is meaningful to enable in addition to “secure boot”, even with EFI boot, but currently only for the purpose of secure/automatic unlocking of LUKS volume. Potentially it could be used also to unseal other server/client certificates later on in the boot process but this is not yet implemented/used in opensuse.
These IMA/EVM related kernel features are apparently supposed to continue after “trusted boot” to perform additional measures (hashing or checking signatures of various vital files), logging results into TPM registers, and potentially affecting unsealing of TPM encryption keys.
