I personally don't like how it's possible to store data on my device without me being able to access the data. Also most of the time these keys are used for DRM. So... good IMO.
I don't know how Samsungs trust zone implementation works, but the Apple secure elements (Ax,Mx,and T2 coprocessor) burn fuses randomly inside the SoC on first power up. Those fuses are used to further encrypt everything down the line from that. There are APIs on macOS+iOS to create asymmetric keys where the private key is handled by the secure element and cannot ever be extracted. Encryption (or signing) using those keys is performed by the coprocessor.
This is the model you want from any "hardware wallet" you might have, and is the model you want to actually secure your data.
Google "Intel Management Engine" or "AMD PSP" or "ARM TrustZone".
The last of these could, in theory, be less bad, except no ARM licensee except Rockchip (and maybe Apple -- jury is still out there) has chosen the "be less bad" option.
Being able to open a Diffie-Hellman encrypted, mutual-signature-authenticated channel to a remote device to then receive an AES key for disk encryption is far better than some TPM header that can easily be sniffed with physical access.
Would be even better if NVMe SSDs were able to authenticate themselves and let you transfer in a key over a DIffie-Hellman channel so sniffing the PCIe bus wouldn't deliver the key (or a non-PFS-encrypted encapsulated form of it) to an attacker. The speeds of NVMe SSDs unfortunately prevent LUKS from being cheap, and TCG Opal is kind of a joke from a security standpoint (doesn't even (seem to) specify that the provided "password" is used to derive a key, suggesting that it may just be used via a password hash to compare against a database entry to decide whether to unlock a disk encryption key).
Even TPMs don't seem to encrypt the communications channel they use with the CPU/PSP, and they are often socketed which makes MITM attacks easy with physical access. If they'd offer Java Card, they'd at least be somewhat useful...
(I'm not hapy with the x86 situation either, but it's still less bad)
In theory, you shouldn't be able to get the key while booting on some other media (say, your own Windows USB drive).
> Ensuring the integrity of early boot components and boot configuration data. On devices that have a TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to make data accessible only if the computer’s BIOS firmware code and configuration, original boot sequence, boot components, and BCD configuration all appear unaltered and the encrypted disk is located in the original computer. On systems that leverage TPM PCR[7], BCD setting changes deemed safe are permitted to improve usability.
https://docs.microsoft.com/en-us/windows/security/informatio...
Consoles are largely protected by the same technology, how often do you see people achieving code execution on them by tampering with the hardware?
Also, consoles are "protecting" not the user, but the manufacturer - which is exactly the point people are trying to make.
What hardmods do you know of for current gen consoles? Even the previous generation mostly fixed all public hardware based attacks.
This is standardized hardware that would be a relatively soft target to build tooling against, yet modchips are essentially dead because the attacks are just far too difficult.
That there are still no good attacks for the xbox one speaks volumes.
The way security on modern devices with h/w support work is that a random key is generated in hardware. Subkeys are derived from that. Access to these keys (if they're ever directly exposed) is gated on the correct password, but nothing is actually protected by it.
This is what you want as it means you don't have to make a password that is maybe 50 characters long, and actually random (e.g. no word sets).