Foxboron

At which point us, the Linux packagers and other package maintainers, is just going to patch it out. I wouldn't be very worried.

You could also include SSH keys as public secrets.

https://github.com/Foxboron/ssh-tpm-agent

> Not to mention that much of Nix packages are reliably bit-for-bit reproducible.

We don't know that. Nobody has even attempted to build more then an incredibly small fraction of the packages `nixpkgs` provides.

> Is that not correct?

It's not. That would be comparable to magic.

> Hi Fox, i'm not aware of any other usages on the platform i'm familiar with sorry, maybe a gap in my understanding.

The TPM as a device is completely democratized and accessible by the normal user.

You can use it for platform attestation (which is this post is trying to point out might be broken in some cases), but it also works as a "discount" smartcard where you can seal data and shield keys.

Two examples here which I have written:

A file encryption utility for `age` that shields the keys in the TPM.

https://github.com/Foxboron/age-plugin-tpm

`ssh-tpm-agent` is an `ssh-agent` implementation that enables you to create TPM shielded keys and does signing operation on the TPM.

https://github.com/Foxboron/ssh-tpm-agent

Conceptually both of these tools can also use PCR policy sealing as a form of platform attestation, but I have not implemented that yet as it's a bit hard to do this in a user friendly way UX wise.

As noted by others, you can also do disk encryption. `systemd-cryptsetup` does this on Linux.

https://www.freedesktop.org/software/systemd/man/latest/syst...

> Afaik, if you want access to a chip like TPM, the OS will need to cooperate as such I/O access or MMIO or however it's accessed, will be privileged instructions likely.

Not really? `/dev/tpmrm0` is a TPM resource manager for Linux that is accessible by being part of the `tss` group.

> I'd find it somewhat logical an OS or loader component starts verification, and then components upwards in the chain are well, chained together via verification, taking away the need to access the TPM after the initial modules are verified.

This is only one of several use-cases of a TPM :)

This is also orthogonal of whether or not Secure Boot is part of the chain, depending on the operating system.

If ARM implements the UEFI specification then there are escape hatches to enroll your own PKI.

I don't own ARM machines with UEFI so I have no clue.

> Hyperbolic or fairly extreme-sounding scenarios are common when discussing this kind of thing, partly because it makes discussion about a fairly boring topic a little bit more interesting. Don’t get distracted by that.

It's not. They are very much intended to derail serious discussions around threat models.

> That being said, using a TPM-based TOTP is pretty extreme sounding in and of itself.

It's not. It's trivial to implement.

> Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.

All of them.

The Secured Core machines still allows you to reset Secure Boot into user mode as mandated by the spec.

> You're not binding the secret to PCR values? I thought TPM fans loved those things?

Binding things to PCR values doesn't imply you need Secure Boot, signed initrd, lockdown mode, shim and signed kernel modules. All of these things are individual security measures that can be combined depending on your threat model.

> I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

The v2.0 version of TPM doesn't really make PCR policies easier to use, so I've had troubles getting them properly integrated into the tools I write as you need to deal with a key to sign updated policies. `systemd-pcrlock` might solve parts of this but it's all a bit.. ugly to deal with really.

The entire TPM specc is not great. But I find TPMs too useful to ignore.

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on

None of this is needed to take advantage of TPMs.

> Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

Yubikeys are expensive devices, and TPMs are ubiquitous. Better tooling solves this problem.

> Do i need to? That the user presses the power button does not mean the machine will freshly boot. It could also be an unsuspend/wakeup or some regular ACPI event if the machine is only appearing to be off.

This is a completely imaginary scenario. I'd be amazed to see it pulled off.

EDIT: I hear Amazon is still getting pitches for Hacker 2. You might have a shot.

> The OS does not matter?

Of course it does. You are replaying the logos and screens.

> Grab the video output via HDMI/DisplayPort and insert the keypresses via USB. Thats likely gonna work. Basically what modern KVM switches do. And setup the fake laptop as VNC client. Same tech that companies can use to remotely manage servers.

You believe you can boot up an entire VNC client to display something that would take most machines under a second to display?

It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain.

This is a common misconception.

> But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off.

It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

> And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.

Assuming they can edit the file.

> That's why Yubikeys and U2F keys and suchlike have a physical button.

The TPM spec has a policy setup to account for some fingerprint reader that can be used to authenticate. I haven't been able to figure out how/what/whys of the implementation here but this is very much a thing.

> The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. Also any authentication to generate that TOTP in the first place. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard.

This is a hollywood level threat scenario.

It involves the attacker having intimate familiarity with the operating system, and having to break inn twice to even get this attack done.

If you do put inn the effort then I deserve to be hacked and can pick up sheep farming in the country side.

It's never unsealed. `tpm2-totp` does an encrypted session to the TPM and runs `TPM2_HMAC` on the TPM shielded key, you can also include PCRs to add further authentication to this entire exchange.

What do you mean with "relay"?

(All of this is trivially solved with glitter nail polish anyway.)

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop?

The TOTP token here is sealed inside TPM.

> For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.

TPMs give you fine and adequate protections in many scenarios, even physical ones.

They also provide you with better protection for private key material.

I'll even give you an example:

https://github.com/Foxboron.keys

The last key is a TPM key from my `ssh-tpm-agent` project: https://github.com/Foxboron/ssh-tpm-agent

Here is the private key: https://paste.xinu.at/9fc2YJQuUCbg1Sa/

I don't remember if the key has a PIN (it was for a presentation/demonstration), but if it has it's like 4 digits long.

`tpm2-totp` defeats the entire "replace the laptop" threat scenario.

https://github.com/tpm2-software/tpm2-totp

Glitter nailpolish on your machine seams/screws and tamper detection. Keyboard sniffing is not as trivial as people make it out to be.

BUS interposers are trivially defeated with encrypted sessions and a PIN.

Bitlocker is traditionally the implementation susceptible for this attack, but for that I'll just defer to Chris Fenner.

https://www.dlp.rip/tpm-genie

A lot of Linux distributions has moved away from the dbus implementation that was merged into systemd to the `dbus-broker` project which has an optional dependency on systemd.

So the answer is "yes", alternative projects exists.

Got served carbonated gammel dansk from this tap, and tortured by "När man festar festar man" on repeat for 6 days during Chaos Communication Camp.

10/10, no notes.

Would do again.

For fun, https://aur.archlinux.org is a single git repository with each package represented as their own namespace.

An mirror for the `aur.git` repository can be found on Github.

https://github.com/archlinux/aur

Matthew was shitting on systemd and pulling no shots. Poettering calling Matthew a scriptkiddie is mild.

He did call me a "facist weenie" with no clear reason why beyond me pushing back on their grand claims.

They have blocked me so I can't read their tweets.

I think it's worth pointing out that all demonstrations of this issue either needs yama to be disabled for `ptrace` to work (this is what reptyr does under the hood), or you need to be part of the parent process to abuse the tty terminal.

The other demonstration shows the latter part, but requires you to have a reverse shell in the parent and can't be abused across users.

https://twitter.com/hackerfantastic/status/17860809689581612...

Generally, this issue is overblown. Both of these "exploits" works on `su`, `sudo` and probably `doas` because of session caching or because you have access to `ptrace`.

I'm not sure what security boundary you are breaking and this seems more like a cheap dig at `systemd` to feed into the decade-old hate train at this point.

Bro, you should really take the hint soon.

I think we are talking past each other. I'm just trying to clear up a misconception on how nix works, not anything about the docker portion of what you have written.

>It's content addressable, just what are you addressing?

In the case of Nix it's addressed by the input. Not the content of the build. It's an important distinction and one Nix also makes.

https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

But doing this is going to give you a slight headace as most of the package repository in Nix is not checked for reproducible builds and there are no way to guarantee the hashes are actually static.