I’m curious about the possible uses of the hardware Trusted Protection Module for automatic login or transfer encryption. I’m not really looking to solve anything or pry. I’m just curious about the use cases as I’m exploring network attached storage and to a lesser extent self hosting. I see a lot of places where public private keys are generated and wonder why I don’t see people mention generating the public key from TPM where the private key is never accessible at all.
You must log in or register to comment.
Outside of Microsoft and Windows, what’s the application for it? Does Linux or UNIX have much use for TPM? Pardon, my ignorance, but I bet this is a good place to ask!
Hardware accelerated disk encryption if I’m not mistaken
It scares me. What if the chip dies? How am I gonna be able to get my stuff? I don’t fully understand how it works, but where is the encryption saved? On the chip itself or somewhere else?
What if the chip dies? How am I gonna be able to get my stuff?
You can have backup keys, but if you don’t have that then your data is gone.
I don’t fully understand how it works, but where is the encryption saved? On the chip itself or somewhere else?
Encryption key is stored in the TPM chip.
i use it to auto unlock luks. if someone messed with the hardware/ bios, it will ask for the password next boot.
100% Yes
-
Currently using
systemd-credsto displace any secrets in env -
Spending time getting to grips with Keylime
-
Usually because its not portable. A USB security key costs more than the TPM you already have, but you can make a backup and store it in a safe
I use it in combination with an SSH CA for SSH access. The certificate identifies me, and TPM identifies my device, and the key material can’t be read without some rather annoying surgery and signal probing that doesn’t really exist in my thread model. The certificate allows me to only distribute one single key for all my devices, so I don’t need to bother with copying files or transmitting long lists of trusted public keys to every server.
I know it’s possible to use the TPM for PKCS11 auth, next time I’m messing with that I’m probably using my TPM for that too.
A security module or a key fob/smart card processes the key internally using its own dedicated ram and cpu without any debugging support. This way, even something will full ram and cpu access or a compromise of your machine, there is no way to export or access the key. Data is passed to the module and it returns the scrambled or unscrambled result based on the key which no body knows or has ever seen. A key locked with no way to access can’t be hacked without physically stealing the module, which is where your pin comes in to save you. The TPM is a very important part of a secure boot chain. If you want to secure other things I wouldn’t blame you for using a separate module or fob that isn’t always connected util it’s actually needed and it should only be activated with a physical button or something so you have to be present to engage with it. This adds even more security. So you could use the TPM for boot chain security and a separate fob or data privacy for example.
Personally, I don’t see how a TPM module is more useful than full disk encryption with a password you enter on boot.
I struggle to see how it makes automatic login safer given it does nothing to protect against the really common threat of someone physically stealing your laptop or desktop.
I don’t trust any encryption or authentication system that I don’t have access to the keys for. Microsoft has also kinda made me feel it’s more for vendor lock in, like they did with secure boot.
Still, I’m probably being unreasonably pessimistic about it though - be interested to see any practical use cases of it.
In theory, the TPM can be used to verify that the bootloader, kernel and injtamfs haven’t been tampered with, which is very very useful as FDE (in the running machine) is only good if that remains true.
I’ve heard that before, but there are two main problems that stick out to me:
- A lot of the marketing for TPM (at least when I was setting up bitlocker on Windows) suggests that it’s used to support decrypting drives without a password on boot. But that doesn’t seem to offer any protection from the devices being stolen. The bootloader may be safe but it’s not actually verifying that I’m the one booting the device.
- I can’t think of a situation where someone would be able to actually modify the bootloader without also having full access to the files and secrets. Especially in a single-boot environment where every time the system is running, the device is decrypted.
I’m not saying that it’s all just a scam or anything like that, but it really feels like I’m missing something important and obvious.
While I don’t use TPM myself (I dislike being tied to a specific hardware) the way it protects you is:
Disk is protected through encryption, so you can’t remove and inject anything/hack the password.
If boot is protected/signed/authorized only, a random person can’t load an external OS and modify the disk either.
All this together would say, even if someone acquires your computer, they can’t do anything to it without an account with access, or an exploit that works before a user logs.
In a way, the attack surface can be bigger than if you simply encrypted your disk with a key and password protect that key.
The bootloader is stored unencrypted on your disk. Therefore it is trivial to modify, the other person just needs to power down your PC, take the hard drive out, mount it on their own PC and modify stuff. This is the Evil Maid attack the other person talked about.
Otherwise you simply have a USB boot partition.
Pretty easy to set up, can be taken out to not be modified at run time unless you want plus not being stolen with the computer itself.
I see only drawbacks with a TPM for a computer system like that. In embedded credentials, mobile applications, cold credential storage, etc… it works very well, but it doesn’t solve any problem that someone tech savvy doesn’t have a better solution for, in my opinion.
If you are a big enough target for an evil maid attack, you are either good enough to circumvent it better than an embedded TPM, or you are rich enough to hire someone who is.
I can’t see that being a reasonable approach for them to take, tbh. One option with TPM is that your system logs in automatically to the desktop, in which case they can just turn it on and use it normally. The other is that it requires a password at some point during startup, to which they could just use a (hardware) keylogger.
It only at most auto logs you into the display manager or more generally into login. Then you still need to get root access to modify anything from there. Login would still be based on user password/key/whatever.
If the device is stolen, your disk is still encrypted at all time. If you believe your OS’s login system is reasonably secure, then the attacker should have no way to access your data: they cannot access the data from software because it is blocked by login screen, they cannot access the data from hardware because it is protected by FDE.
One of the misconceptions I had before is that I assumed that the disk will be decrypted when you enter the LUKS password. This is not true, the password is loaded into the ram, and only decrypts necessary parts to RAM. All the data on the disk is never decrypted, even when you are working in your OS.
they cannot access the data from software because it is blocked by login screen
The system may still be vulnerable to over the network exploits. So for example, if the system is running
sshd, and a couple of months from now a root exploit is found (à la heartbleed), the attacker may get inside.It’s somewhat of a long shot, but it’s still a much larger attack surface than butting your head against a LUKS encrypted drive that’s at rest.
they cannot access the data from hardware because it is protected by FDE.
RAM is not protected by FDE. There are (obviously non-trivial) ways to dump the RAM of a running system (Cold Boot attacks, and other forensic tools exist). So if the attacker is dedicated enough, there are ways.
One of the misconceptions I had before is that I assumed that the disk will be decrypted when you enter the LUKS password. This is not true, the password is loaded into the ram, and only decrypts necessary parts to RAM. All the data on the disk is never decrypted, even when you are working in your OS.
Hah! That would be impractical :) Imagine having to decrypt your entire 32TB drive array everytime you booted your computer.
You can use insecure boot and not enter the password. It can’t make stuff meaningfully more secure though, it just plain doesn’t add any protection against evil maid.
The key is only released into ram, so unless the thief can read content from ram they cannot easily decrypt your disk. And most common thief probably do not have that ability.
That being said, you do need a login password to prevent the thief straight up booting into your OS and copy everything using the file manager…
One of the advantage of using TPM with FDE, is that you can use a much longer random password. If I dont use TPM I am forced to use a password I can remember, which is likely the same password I use somewhere else. This means if someone close to me stole my laptop, they will have reasonable chance of guessing my password.
