Hacker News Reader

> I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually.

LUKS has multiple "key slots" so IIRC you can use one slot for TPM unlock, and a different one for long password unlock.

Have you considered using that as your recovery mechanism?

> It's just for a personal project,

One of the reasons very few hobbyists touch the open source TPM stuff is there are a number of alternatives that scratch similar itches much more easily.

Need to protect a crucial encryption key by locking it up in hardware? Buy a Yubikey.

Disk encryption password on your laptop is inconvenient? Just use standby when you close the lid instead of powering off fully. Login password is inconvenient? Fingerprint reader, or biometric yubikey.

Unattended kiosk, school computer lab or similar that needs to boot without a password? Just put it in a sturdy metal box and chain it to the wall.

Server in a data centre that needs to boot unattended? Move to a data centre with physical security you can trust. Still worried? Dropbear or Tang so it has to be on the right network before it'll boot.

Home lab hobbyist, working with the TPM for fun? Assess whether you're actually having fun working with the TPM, and you'll probably notice you're not.

Surely Windows keeps the FVEK in RAM regardless of whether the TPM requires a PIN to initially obtain it. Otherwise, wouldn't you need to enter your PIN every time a block from the disk needs decrypting? Not to mention the performance impact of calling the TPM on every disk operation.

This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate it.

If you can short the reset pins while the computer is running and make it restart without losing power, then yes, I agree. But if you have to shut down to make your modifications, then you won't get past the PIN prompt.

Why? It means you'll only get one shot at the attack, but nothing here is intrinsically prevented by using a TPM PIN (or even a non-TPM password, the attack doesn't depend on TPM-based Bitlocker in any way other than if the target machine is powered off or your first attempt fails)

I wouldn't underestimate that a PIN prevents this attack on machines that are powered off.

You can then go further up the chain with a UEFI settings password and no usb booting. If the password is hard to decrypt, then that's a pretty good approach.

Then there's custom Secure Boot certificates that replaces the ones from MS. It'll work for Linux, not sure about BitLocker. But my Surface tablet doesn't even support custom sb certs.

It might make it super hard to do an a laptop where you can't usually force reset easily from the power button.

Having said that a number of laptops can still be opened without being powered-off if you do it carefully.

Correct, unless you're using a self-encrypting drive the FVEK sits in RAM once it's been released by the TPM during boot. The TPM is only a root of trust; for fast crypto operations without keeping the key in kernel memory you would need something like Intel SGX or ARM TrustZone.

BitLocker no longer leverages SED by default due to vulnerabilities in drive manufactures firmware as of Sept 2019.

> Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.

https://support.microsoft.com/en-us/topic/september-24-2019-...

https://nvd.nist.gov/vuln/detail/CVE-2018-12037

Holy crap.

https://threadreaderapp.com/thread/1059435094421712896.html

This is amazing.

> The encrypted SSD has a master password that’s set to “”

HN discussion here: https://news.ycombinator.com/item?id=18382975

Original paper here: https://cs.ru.nl/~cmeijer/publications/Self_Encrypting_Decep...

The point is that the TPM PIN prevents the attack if the system is powered off when the attacker obtains it.

If the TPM doesn't have a PIN, this attack works even if the attacker obtains the system when it's powered off. They can start the computer, proceed to the Windows logon screen (that they can't get past and that hence prevents them from exfiltrating data from the running system), then just reset the computer and perform this attack to obtain the encryption key. This obviously doesn't work if the PIN prevents Windows from ever even starting.

I know this is besides the point, but still kinda relevant:

Even on Win11 it's still possible to do the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot), from there you can change account passwords at will.

I think Windows repair prompts for an admin login and the bitlocker key before allowing you to proceed. Assuming the windows install is intact enough to read the security sam.

You can't change something on an encrypted volume without knowing the encryption key

> the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot),

Can you elaborate on this?

Would you be better off using split key encryption or encrypted secret key?

If you have to put a password in before boot that needs to be combined with the TPM key to unlock the drive, it would help in scenarios where a TPM key can be found later.

I’m not sure how much anything helps against this attack though. Retrieving data from RAM in this way should work for most scenarios by changing where you look for the key (as it needs to be held somewhere by the OS to maintain read/write access to the drive).

I would assume Apple devices aren’t vulnerable to this type of attack as IIRC the keys never exit the enclave. Maybe TPM 3.0 needs to look a lot more like that.

> If you have to put a password in before boot that needs to be combined with the TPM key to unlock the drive, it would help in scenarios where a TPM key can be found later.

Bitlocker already does this if you use a PIN/password.

You might know better than I do, but I had believed that Bitlocker used TPM PIN when you use a PIN, which is challenge/response (i.e. if PIN matches then TPM releases key) so wouldn't help in this case.

If Bitlocker PIN is split key then yes that would be ideal, but I think you can change the PIN without re-encryption (which implies it's challenge/response).

> use TPM (PCR 7+11) with a PIN

A power-on password (set in the BIOS) should also work, since without it the system will never get to the point where the TPM unlocks the FVEK, right?

I prefer this setup to a Bitlocker PIN because I can use a fingerprint instead of the power-on password on my Thinkpad, and because it should make the device largely unusable to a thief.

Of course, power-on password and fingerprint auth are only as strong as my TPM, but the same goes for Bitlocker TPM+PIN, right?

Isn't TPM just a honeypot of sorts? It seems strange to me that after successful open source encryption software, there was a shift to TPM, like you'll have a notion of super secure storage provided by big corporations and you should just not worry about it and not question.

Surely there must be a backdoor access for three letter agencies to just download all the pins and passwords and then take a dip in the data, no worries.

Should be good enough for a personal tablet used for mail and browsing. If I drop it and someone curious finds it, I'd like to make it impossible for them to extract anything useful.

I prefer to think of TPM as equivalent to the chip in a smart card.

I think this is a good analogue. A smart card is a challenge-response system where sure you could extract the inner key, but doing so would take time and require destroying the card, which would alert the user— we all learned years ago about skimming and now the payment terminal comes to our table rather than the card being carried off elsewhere.

TPM is one piece of a larger puzzle and provides a middle ground where among other things you can get full disk encryption without needing to input a memorized key on every boot.

I encourage you to read what a TPM is. A TPM isn't an "encryption" software/hardware. It's completely orthogonal to "successful open source encryption software".

"successful open source encryption software" don't solve the main usability problem with encryption: "Where do I store my super secure 4096-bit private key so it's both secure and convenient to use"

I don't see why a TPM couldn't be open? Nobody makes open-source TPMs (because they're put inside CPUs or attached to motherboards with specific pins and protocols) but in theory you could just do it. All you need to do is make sure any secrets stored get wiped permanently whenever you flash new firmware.

It'd be similar to secure boot: usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.

You can make your own HSM using a raspberry pi pico https://www.picokeys.com/pico-hsm/

> usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.

You can control what's your TPM. That's how they work today. Sure their software isn't "open source" but there aren't that many 100% "open source hardware" options around. If you want to be able to flash it, build your own HSM. I don't know if there is a market for a prebuilt microcontroller with something like picokeys preinstalled. I know that the market for "open" hardware is tough.

> I don't see why a TPM couldn't be open? Nobody makes open-source TPMs

The main advantage of the TPM is how it is made physically. It should be designed to make it hard or impossible to read the secrets out of it and those things depends on how the components are manufactured on the silicon wafer.

Maybe the manufacturing process could be published, but I don't think it would help much.

You could probably write your own TPM emulator or modify swtpm a bit and compile it to any microcontroller, but in that case the chip could be easily decapped to make all the secrets readable.

That's a definition of security by obscurity.

Is a yubikey then employing security by obscurity?

100%

They’re built from essentially the same secure MCUs as traditional TPMs and both the hardware and the proprietary crypto libraries used on them have been exploited many times over.

But would you not agree that using a yubikey can improve security? If you chose to label TPMs as security by obscurity, so be it, but it doesn’t make them less useful conceptually. Shitty implementations and complexities of UEFI do that.

Unlike with cryptography, there is no rigorous notion of physical security. Doors, locks and even security systems can all be overcome with sufficient effort, skill and resources. They work because physical attacks require proximity and are very hard to keep anonymous. I seriously doubt that any TPM implementation would last a week against government funded researchers with state of the art technology, but that doesn't mean the TPM is useless.

No, it's the same. Cryptography is like a lock that you can overcome with mathematical force. It's just in different domain than physical objects.

If you know how the lock is built, you can rule out existence of master key for instance. You don't know if your TPM chip has API where three letter agency can just download the keys from it. You are in the dark.

Same with cryptography, you can choose the method, just like you can choose type of lock. There are locks that have not yet been picked, but you can use a hammer, similar with cryptography - you can use quantum computer etc.

Which locks haven't been picked? Abloy Protec 2 got picked, Bowley got picked, StealthKey got picked… I'm not aware of any designs for an unpickable/unbypassable lock. Whereas several AEADs have not been broken.

Some of these features makes it harder to (physically) probe the internal parts of the chip and read out secret values:

https://en.wikipedia.org/wiki/Secure_cryptoprocessor#Feature...

These things make it harder to break into the internals of the chip regardless of they being kept secret, so I wouldn't call it security by obscurity. I'm not even sure you can apply that principle to physical security.

Printing out your 2FA recovery keys and storing them in a safe also is.

No, it's security by intrusion detection, generally. HSMs are designed to be boxes that it's very hard to get a secret out of with physical access. TPMs generally aren't the most paranoid version, but it gets more expensive and less practical as you go further (e.g. a large box which has a battery backup, keeps the secrets in RAM, and will wipe them as soon at it detects any funny business. These are DIYable, but the list of tricks by attackers is long and it's hard to cover all of them at once). A TPM is generally somewhere in between that and a regular micro with no particular effort to prevent readout of internal storage, in that they are small, can persist secrets without power, but are still difficult to attack physically (~maybe at the level of advanced criminal organisations, ~probably at state level if they're willing to spend some money on it, even absent a backdoor).

An open TPM does exist: https://www.qemu.org/docs/master/specs/tpm.html#the-qemu-tpm...

The TPM emulation offers a full TPM implementation in software, for providing TPM functionality to a virtual machine when the host doesn't have one (or, when the TPM needs to be virtualized for other reasons, e.g. migration).

It's in the works. https://opentitan.org/

I am sorry I wasn't clear. I am aware that TPM is a key storage. Just I am not convinced they keys it stores are secure. It smells of security by obscurity and all big corporations are happy clappy to use it and government is silent about it, which likely means they have a backdoor.

Lest one forget NSAKey! /s

This type of /r/ufos|/r/aliens speculation isn't particularly useful. It comes with no evidence of TPMs being backdoor'ed. Have they been compromised [at least pre-2.0]? Yes, in as much as Apple's Secure Enclave has as an example.

Gut feelings aren't always correct and for topics which have a sort of 'correctness' about them, they're not useful.

Otherwise we're debating to prove a negative.

>It smells of security by obscurity and all big corporations are happy clappy to use it and government is silent about it, which likely means they have a backdoor.

The government is also pretty silent about AES. Does it mean that's backdoored as well? More to the point, I'm not sure what the proposed alternative is. Not using TPM, and exposing yourself to bootkits and evil maid attacks?

It is security the same way a lock is. It limits low efforts attempt which is why we put locks in our doors and close our most easily accessible windows in the first place.

You can store it encrypted with a password on a USB memory that you insert when booting the computer, like you would use a key for starting a car.

This is what I actually do. I also store the OS kernel on the USB memory and I boot from there, with the root file system set to mount an internal SSD. The SSDs in the computer are completely encrypted with such long "super secure" keys (distinct for each SSD and selected automatically based on their serial number), and they do not store any information about the keys.

I have used this system for years and I find it very convenient. My computers cannot be booted without inserting the bootable USB memory and also giving the correct password. I have multiple bootable keys stored in different places, for the case when one becomes defective or lost.

Maybe it's different for you, but I don't think any three letter agencies have some kind of TPM backdoor (they don't need to with how often TPM chips end up being vulnerable to common software exploits, the firmware being written in unsafe languages and all). If a government was going after me with enough force to use their TPM bypass trick, I'd probably be in jail for years on fake allegations regardless of encryption status.

TPMs work great against things like common thieves and probably corporate espionage, if set up well. When implemented well, they provide no additional friction (except for having to store a recovery key somewhere) but all the security against a laptop being stolen at the airport you could wish for.

It's not a honeypot, and it does have value when used properly.

Their main purpose is to generate and store keys that cannot leave the device, instead performing signing operations as needed internally and only returning the result, and only if attestation passed. This is a lot better than just having private keys on disk.

People just forget that security isn't absolute, and each solution has a threat model it is appropriate for. In case of full disk encryption, neither a TPM nor user input can protect against evil maid on its own for example - the TPM will unlock for anyone, while user input might be collected by a modified and malicious bootloader. Having both, however, works well.

"TPM" is a bit dated as a term as it's all directly built into the processor nowadays, including for smartphones and such. Another modern feature in that catalogue is memory encryption, which rules out the attack described by OP as the rebooted machine would be unable to read old memory content.

Might need most of PCRs 0-7. Isn’t PCR 4 used to measure the EFI executable booted by UEFI?

Avoid GRUB, difficult to secure with it.

Kernel updates will also be painful…

7+11 is default for BitLocker as far as I know. Binding to other values will bite you later if you update UEFI firmware or change some settings.

GRUB and all other boot loaders are unecessary with UEFI. See my comment history for more.

Kernel updates + Secure Boot is easy with a Debian hook.

The hard part is making it work with TPM when you want to add encryption...

Found the article where I read about PCR 7+11 being the default [1]. The reason I looked it up is because if this is actually true, and the TPM is built into the cpu, what prevents someone from placing the cpu and disk on another motherboard?

Say that you have disabled usb booting and secured UEFI settings with a password. If you extract the cpu (and thereby its tpm) and the disk, then you'd still be able to boot, right? Meaning that without a TPM pin, you'd be able to do OP's attack on a different motherboard even when the original machine was off and UEFI settings secured.

What am I missing? Is it that easy to circumvent UEFI settings protection and maintain the PCR 7 value?

[1] https://blog.scrt.ch/2023/09/15/a-deep-dive-into-tpm-based-b...

From what I know, the state of the UEFI settings is hashed into some PCR registers. Potentially even hardware serial numbers. Sometimes when I modify non-secureboot BIOS settings, Bitlocker complains and enters into recovery mode.

So I really doubt TPM will release the keys on a different motherboard with different UEFI settings.

User changed motherboard and TPM complains: https://old.reddit.com/r/pcmasterrace/comments/vdvni1/swappe...

Odd that you have to recover from changing UEFI settings with Secure Boot! You should be able to change any setting when that's enabled. BitLocker binds to a lot of other things when SB is off and might be fragile in that state. But it does seem that some changes will affect PCR 7:

> PCR 7 changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) are updated. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR. — https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...

It makes sense to use the certificates to generate PCR 7. I wonder if you can swap out the motherboard with one of the same model with the same certificates without modifying the PCR 7 digest...

But if Shim actually modifies the digest, I guess that SB would completely mitigate OP's exploit since the TPM policy is going to fail when the PCR 7 values doesn't match.