According to my previous answer, suggestion by @logneck and a bit of
google-fu, I came to the conclusion that it is possible to implement the scheme requested in the question with available tools and a lot of patience/expertise. This approach should satisfy the OP's request but is only a design guidance, as it has a number of drawbacks/pitfalls. It will help the OP defend from the naive attacker trying to copy data from the encrypted disk.
My previous idea to use a TPM chip remains valid. This guide, which I never tried, displays how to encrypt the disk without having to type a password and by preventing anyone to decrypt the data on another machine.
The TPM is normally embedded in the motherboard, so cannot be moved to other hardware. TPM performs hardware attestation, so that you can verify the hardware environment is compliant, and no third party card has been plugged into your mobo.
If hardware attestation passes, the TPM unlocks itself. Then LUKS module can request the TPM for the encryption key of the disk, which is stored inside the unlocked TPM.
If disk is moved to another machine, you won't have the key with you.
As described in the guide, the procss involves:
- Installing the distro of your choice
- Take ownership of the TPM chip using
trustedgrub2 and use it as bootloader
- Add the LUKS decryption key to the TPM
- Seal the TPM
Sealing the TPM means doing hardware attestation. The guoide I linked speaks about BIOS boot instead of UEFI (UEFI uers are familiar with the concept of secure boot).
trustedgrub2 will measure the software. This can be simplified by checksumming the kernel to make sure it is not altered. TPM will also measure hardware to check that no other PCI card or similar was installed since TPM was sealed.
During the boot process, if hardware has not been touched/tampered with, and the booting kernel is the same who sealed the TPM, then TPM issues the secret LUKS key to the system, so that the system can decrypt itself.
Result: 1) the disk is encrypted, 2) no password is required at boot time, so the user can reboot the machine any time, and 3) the key cannot be recovered by a user because it lives in the hardware storage.
Note that this solution, similar to what Microsoft BitLocker, is not perfect and shares the same security pitfalls as Microsoft's solution. In fact, BitLocker powered only by TPM and not PIN was repeatedly criticized for its weaker security, which I will not be discussing here.