>It also solved the issue I had with entering a password on FDE (full disk encryption) systems

I've fixed that with secure boot (my own keys, not Microsoft's) and TPM2. From that host I can run a program named Tang, which operates in conjunction with another program named Clevis.

On hosts without secure boot such as RPis and other ARM SBCs, Clevis will contact Tang at boot time and decrypt the disk.

Incidentally my x86 with secure boot has intel vPro so the KVM is not needed. The remaining sisters have a piece of lost technology used for decades to solve the KVM problem: serial (UART specifically) connections.

Some seasoned sysadmins might have memories of dialing their Sun servers serial ports for remote administration.

▲

jchw 3 hours ago | parent [-]

To me, it is a feature to have a password required at boot to unlock the drive. Relying on TPM for keymatter is convenient but comes with caveats I don't like. I don't personally trust that the boot chain and OS on a modern system are secure enough for this model to be similarly secure to using a passphrase properly. And if I care enough to try to secure something in this way, I definitely care enough to pick something that I believe would be at least truly secure at rest with a decent degree of certainty.

TPM based unlock does at least still fulfill the goal of ensuring data stored to disk is encrypted so that it can't easily be recovered from a discarded drive.

	▲	doubled112 2 hours ago \| parent [-]
		I am using Tang and Clevis without a TPM on an Orange Pi 5. The key is stored on my Tang server. No TPM required. It is either on my LAN with that server available, or you will need to enter a key. It am only trying to prevent casual snooping if it goes missing from my garage though. Anybody more sophisticated can have my garage YouTube browsing history.