[HN Gopher] TPM GPIO fail: How bad OEM firmware ruins Intel TPM ...
___________________________________________________________________
TPM GPIO fail: How bad OEM firmware ruins Intel TPM security
Author : osks
Score : 168 points
Date : 2024-06-06 04:34 UTC (18 hours ago)
(HTM) web link (mkukri.xyz)
(TXT) w3m dump (mkukri.xyz)
| michaelt wrote:
| _> If attacker have physical access, the discrete TPM is an
| attack surface anyway and even a known attack already._
|
| If you're wondering what they mean by this, [1] has been around
| since 2018. It's not unusual for a motherboard to put the TPM on
| a removable module, so you don't even have to desolder the chip
| to MITM the communications.
|
| The most recent Intel and AMD CPUs have "firmware TPMs" that run
| in the CPU's so-called "trusted execution environment" so there's
| no I2C to interpose. Of course, that doesn't mean you're
| protected against attackers who have physical access to the
| machine; they can simply install a keylogger.
|
| [1] https://github.com/nccgroup/TPMGenie
| p_l wrote:
| Funnily enough, in TPM 2.0 there's way around MITM attacks like
| that - you can establish encrypted connection between TPM and
| CPU, which outside first-time configuration (which should
| happen in controlled environment anyway) should provide
| reasonable roadblock to successful MITM attack.
|
| But CPU-side software needs to use it, and without default
| well-known keys...
| SSLy wrote:
| vast majority of fTPM 2.0's are chips placed on the CPU die
| anyway
| p_l wrote:
| it's a misnomer, a bit.
|
| _fTPM_ is a firmware-based TPM implemented, usually, by
| coprocessor (or trustzone style enclave) inside the CPU,
| yes. It 's not related to what TPM standard it implements
|
| You can also have external TPM 2.0 compliant devices
| (commonly referred to as dTPM, probably brought the naming
| from iGPU/dGPU), and in fact many options offered for
| making desktops fully compliant with windows 11 (which
| requires TPM 2.0) involve a dedicated TPM 2.0 chip.
|
| Ultimately, TPM standard does not care where the chip is,
| it just provides mechanisms for their use, which do include
| encrypted tamper protected interface... if one wants to use
| it.
| SSLy wrote:
| You're correct, but also I'm reasonably certain that, as
| much bullshit the list of Win 11 supported CPUs is, all
| the CPUs on it have fTPM 2.0 available.
| p_l wrote:
| In practice it's a matter of how the motherboard firmware
| is set up, so there's a lot of possible breakage.
| kukrimate wrote:
| Unfortunately encrypted sessions without an interactively
| provided secret like a PIN are no defence against attacker
| with physical access.
|
| You either need an interactively provided PIN, or a TPM
| integrated into the CPU/SoC to be secure in such a scenario.
| wtallis wrote:
| Why doesn't a key exchange in a secure environment before
| any attacker has physical access give the same security
| benefits of "an interactively provided secret like a PIN"?
| kukrimate wrote:
| Because where do you store the CPU side private key after
| the exchange for future sessions?
|
| The secure storage _is the TPM_ , but here you cannot
| obviously store the secret in the TPM, it's a chicken and
| egg problem.
|
| Thus your secret could only be on disk or in flash in and
| the attacker can just get it.
| Vogtinator wrote:
| Doesn't work either: To establish the secure connection, you
| need some way to verify the other end (through public keys,
| certificates). That verification happens before any
| measurements can be done securely, so it can be bypassed.
| IshKebab wrote:
| I think he's saying you can verify the other end by
| manufacturing the PC yourself and making the initial
| connection in your factory.
| izacus wrote:
| > Of course, that doesn't mean you're protected against
| attackers who have physical access to the machine; they can
| simply install a keylogger.
|
| How would that attack work if someone stole my Ryzen powered
| laptop with full disk encryption, TPM2.0 and secure boot with
| firmware password enabled?
| user_7832 wrote:
| There might be hardware "solutions" to that problem.
| contingencies wrote:
| I believe https://xkcd.com/538/ is the comic you're looking
| for.
| user_7832 wrote:
| Lol that's also true, though I was alluding to hardware
| sitting next to/after the keyboard. But whatever is
| easier I guess.
| wooosh wrote:
| Probably not the most practical attack, but it is very
| possible to MITM the connection between the keyboard itself
| and the motherboard.
| izacus wrote:
| And then return me my laptop and steal it again?
| rwmj wrote:
| Bluetooth keyloggers are a thing. The attacker would need
| to be nearby.
| xattt wrote:
| Not if there's some sort of cell bridging device nearby
| as well.
| HeatrayEnjoyer wrote:
| Relays can be prevented with a round-trip timeout. Limit
| to 8ft/ _c_ , should be plenty for a keyboard. You can't
| outpace light.
| izacus wrote:
| I'd have to use bluetooth keyboard then, right?
| xzjis wrote:
| You have to consider what kind of risk you are protecting
| yourself against.
|
| It's highly unlikely that you would be the target of such
| a highly sophisticated attack, but a hacker could get
| into a place where you left your computer without
| surveillance (such as your home or a hotel) for about 15
| minutes, and install it inside your computer.
|
| If you think you could be the target of such an attack,
| you could maybe enable an alert in the settings of your
| UEFI if your computer has been opened (I know that my
| ThinkPad has that option), or the better option is to
| always keep your laptop with you.
| izacus wrote:
| I'm mostly asking because the original poster was
| painting a process that can be sniffed off the bus (that
| is - buy a stolen laptop off ebay, try to boot it, sniff
| the key off the bus) with a process that requires active
| targeting and multiple breakins to work as equivalent.
|
| It seems like these security discussions always devolve
| into rather funny moving of goalposts without actually
| considering how much work each exploit requires.
| michaelt wrote:
| The goalposts haven't moved in my mind, but I suppose I
| didn't make them clear in my first post.
|
| Basically the TPM provides a set of features that are
| really useful for corporate Windows deployments. No more
| forgotten passwords, because the self-unlocking disk
| encryption sends the user straight to the Windows login
| screen, and helpdesk can reset forgotten Windows
| passwords remotely.
|
| And for casual home Windows users, it lets them log in
| with a 4-digit PIN or with biometrics, so it's got
| usability benefits for them too. If every OS now needs
| Microsoft's signature of approval, or a really fiddly
| setup process? Well they were running Windows anyway, so
| no problem.
|
| These usability/support benefits rely on self-unlocking
| disk encryption, which is vulnerable to sniffing if
| someone gets a stolen laptop on ebay.
|
| For the kind of technically sophisticated, security
| enthusiast users who comment on blog posts about TPMs?
| We're more than happy to key in a strong unique password
| at every boot, and if we forget the password and lose
| access to everything on that disk that's just the system
| working as it's supposed to.
|
| 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.
| Foxboron wrote:
| > 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.
| michaelt wrote:
| _> TPMs give you fine and adequate protections in many
| scenarios [...] my `ssh-tpm-agent` project_
|
| I agree that's adequate, in the sense that keeping the an
| SSH key as a password-protected file on disk is adequate,
| and having it be a password-protected secret in the TPM
| is no less secure than that.
|
| 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. 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.
|
| That's why Yubikeys and U2F keys and suchlike have a
| physical button.
|
| TPMs would be a lot more useful if the spec had mandated
| a physical button for user presence.
| Foxboron wrote:
| > 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.
| michaelt wrote:
| _> It protects against extraction, not usage on the
| machine itself. Of course they can use the secret on the
| compromised machine._
|
| Yes, this is why I was careful to say that the benefits
| are obscure, rather than saying they're entirely
| nonexistent.
|
| 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.
|
| 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.
| Foxboron wrote:
| > 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.
| michaelt wrote:
| _> None of this is needed to take advantage of TPMs._
|
| You're not binding the secret to PCR values? I thought
| TPM fans loved those things?
|
| 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.
| Foxboron wrote:
| > 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.
| AnthonyMouse wrote:
| > Basically the TPM provides a set of features that are
| really useful for corporate Windows deployments. No more
| forgotten passwords, because the self-unlocking disk
| encryption sends the user straight to the Windows login
| screen, and helpdesk can reset forgotten Windows
| passwords remotely.
|
| Unclear why this requires a TPM. Boot the system from a
| static unencrypted partition containing no sensitive
| data, display the login screen, when the user
| authenticates the system uses their credentials to get
| the FDE decryption key from the directory server. Bonus:
| Now the FDE keys are stored in the directory server and
| if the system board fails in the laptop you can remove
| the drive and recover the data.
|
| An attacker with physical access could modify the
| unencrypted partition to compromise the user's password
| the next time the user logs in, but they could do the
| same thing with a hardware keylogger.
|
| > And for casual home Windows users, it lets them log in
| with a 4-digit PIN or with biometrics, so it's got
| usability benefits for them too.
|
| This could be implemented the same way using Microsoft's
| servers, given that they seem to insist you create a
| Microsoft account these days anyway.
|
| It's not clear that unsophisticated users actually
| benefit from default-FDE though. They're more likely to
| lose their data to it than have it protect them from
| theft, and losing your family photos is generally more of
| a _harm_ than some third party getting access to your
| family photos.
| vel0city wrote:
| What happens when I try and login offline or unable to
| reach a directory server?
|
| FWIW, Bitlocker already can store recovery keys in AD. It
| has been a feature for a long time.
| michaelt wrote:
| A high grade hardware implant doesn't just capture your
| password, it'll also replay your password along with a
| _curl | sudo bash_ at 4am
| Foxboron wrote:
| Glitter nailpolish on your machine seams/screws and tamper
| detection. Keyboard sniffing is not as trivial as people
| make it out to be.
| fellerts wrote:
| I doubt your physical keyboard's connection to the
| motherboard is encrypted (I'd guess USB, I2C or maybe even
| PS/2 internally). I would also not be surprised if you can
| get small in-line sniffers that an attacker, with physical
| access for half an hour, could hide in your laptop.
|
| All bets are off if your attacker is determined and has
| physical access.
| izacus wrote:
| I mean, I wouldn't be there to type in my password because
| the laptop was stolen.
| atoav wrote:
| There have been papers about extracting key presses from
| acceleration sensors of a phone, or from the sounds of key
| clicking by statistical inference what feels like a decade
| ago. You probably don't even need to touch the laptop to do
| that.
| blueflow wrote:
| I'd buy you an replacement laptop of the same model and then
| install a rendering of your boot process and password prompt
| on it. Doing a switcheroo and waiting in my bunker until the
| fake sends me the password you entered.
|
| The screen/keyboard is not authenticated to the user, and TPM
| is not capable of fixing that.
|
| It doesn't require some state actor to do that. Just money.
| Foxboron wrote:
| `tpm2-totp` defeats the entire "replace the laptop" threat
| scenario.
|
| https://github.com/tpm2-software/tpm2-totp
| blueflow wrote:
| The "replaced laptop" scenario is a full MITM on the
| hardware. TOTP generally does not protect against MITM.
| The required TOTP code is, in this scenario, generated by
| the device in the attackers hand. So the fake could also
| display it.
| Foxboron wrote:
| 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.
| blueflow wrote:
| And what do you need to do to unseal it? And why cant the
| fake laptop relay that to the real laptop?
| Foxboron wrote:
| 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.)
| blueflow wrote:
| Yes and you can relay that authentication, too.
|
| 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. As tried to
| convey, the fake laptop is basically a full MITM on your
| screen/keyboard.
|
| Making a machine visuals non-reproducible helps that, but
| only if the attacker cannot easily switch the exterior
| parts (chassis, keyboard) between the two machines.
| Foxboron wrote:
| > 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.
| blueflow wrote:
| Why twice? You can keep the fake laptop.
|
| The OS does not matter? 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.
| Foxboron wrote:
| > 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?
| blueflow wrote:
| > You are replaying the logos and screens
|
| Which the real machine happily gives me via
| HDMI/DisplayPort.
|
| > You believe you can boot up an entire VNC client to
| display something that would take most machines under a
| second to display?
|
| 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.
| Foxboron wrote:
| > 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.
| blueflow wrote:
| Windows Fastboot (active per default) is suspend
| disguised as shutdown:
|
| https://www.windowscentral.com/how-disable-
| windows-10-fast-s...
| hedora wrote:
| I'd like to add that the VNC relay machine only has to
| fool the end user once. So, the attacker wins as long as
| they think "the bios is a bit janky this morning, and
| this is more kernel panicky than usual", and type their
| pin/password anyway.
|
| Of course, it's much easier to just pop the original
| laptop open and interpose on the keyboard. Even easier:
| use acoustics to snoop the keystrokes. The snooper could
| even be 5g/wifi/gps, assuming it's easy to steal some
| power from the mainboard. I guess fingerprint + camera ID
| make that attack harder. Still, the hypothetical device
| could stream HDMI at a few FPS if it was easy to splice
| into the display panel cable. (I haven't cracked a laptop
| recently, but those used to be socketed + unencrypted.)
|
| Miniaturization is weird. The latter attack is probably
| easier to pull off these days than the former. If you
| wanted to swap my laptop, you'd need to replicate the
| dents and stickers. Good luck doing that!
| orf wrote:
| OP is trying to say that this TPM TOTP approach doesn't
| help verify a machine is legitimate if there is a
| possibility that the machine you're using has been
| swapped with a malicious one.
|
| This doesn't really mesh well with what the TPM-TOTP idea
| is trying to solve: trust in the machine you're using.
|
| 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.
|
| That being said, using a TPM-based TOTP is pretty extreme
| sounding in and of itself.
| p_l wrote:
| Attestation closes this vulnerability, for example through
| tools like Ultrablue [1] which provides a self-hosted
| method of verifying that the TCB has not been modified
| through external tool (in this case, your phone running
| Ultrablue)
|
| [1] https://github.com/ANSSI-FR/ultrablue
| blueflow wrote:
| The TCB has _not_ been modified - that 's the point of
| that attack. Its just physically elsewhere. A high 24 dBi
| high gain antennae to close that gap costs 70 EUR and you
| would attest the device in the attackers hands, not the
| one in front of you.
| hedora wrote:
| I think some of those hardware attestation thingies use
| clocks and tight latency jitter bounds to make replay
| attacks harder. If it takes more than "2 x time light
| takes to move 10 ft + deterministic delay from the other
| side", or less than the deterministic delay, then they
| refuse to unlock.
|
| Some cars even get this right these days. Most don't.
| dist-epoch wrote:
| A solution would be to have two passwords, and display a
| secret security image between them.
|
| User is required to not enter the second password if the
| wrong security image is displayed.
|
| You can still attack it with a fancy radio transmitter
| which transmits the security image from the stolen laptop
| when it's displayed after you've entered the first password
| to the second laptop.
| fargle wrote:
| i like the way you think
| Foxboron wrote:
| 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
| kukrimate wrote:
| The PIN is the important part there, encrypted sessions
| (and/or EK cert verification) _without_ PIN are not much more
| then obfuscation, and defeated by both the interposer attack,
| and the tweezer attack. (Or the TPM hack to rule them all,
| e.g. desoldering the chip and connecting it to a
| microcontroller you control)
|
| I supposse a PIN is a slight improvement over a regular
| password, but a big appeal of TPM FDE in my opinion is
| unattended unlock.
|
| I think discrete TPMs don't really have a future in systems
| that need robust system state attestation (both local and
| remote) against attackers with physical access. TPMs should
| be integrated into the CPU/SoC to defend against such
| attacks.
| transpute wrote:
| _> discrete TPMs don 't really have a future in systems
| that need robust system state attestation (both local and
| remote) against attackers with physical access. TPMs should
| be integrated into the CPU/SoC_
|
| What are your thoughts on Microsoft Pluton and Google
| OpenTitan as TPM alternatives/emulators?
|
| Should system attestation roots of trust be based on open-
| source firmware?
|
| Recent AI/Copilot PCs based on Qualcomm SDXE/Oryon/Nuvia,
| AMD Zen5 and Intel Lunar Lake include Microsoft Pluton.
| kukrimate wrote:
| > What are your thoughts on Microsoft Pluton and Google
| OpenTitan as TPM alternatives/emulators?
|
| I am not familiar enough of the technical details of
| Pluton or OpenTitan to make a meaningful statement on
| their security.
|
| > Should system attestation roots of trust be based on
| open-source firmware?
|
| Yes, and not only root of trusts, I am strong believer in
| open source firmware in general. I have been developing
| coreboot as a hobby for a long time. I wish their was
| more industry support for such things, especially at the
| lowest levels of modern systems.
| transpute wrote:
| Microsoft has supported open firmware for OCP Caliptra
| RoT, https://news.ycombinator.com/context?id=40131126
|
| Hopefully we will see open firmware (Rust TockOS) on some
| version of Pluton,
| https://news.ycombinator.com/context?id=40557081
| logical_person wrote:
| > encrypted sessions (and/or EK cert verification) without
| PIN are not much more then obfuscation
|
| this is completely incorrect, encrypted sessions defeat TPM
| interposers when there is a factory burned-in processor
| side secret to use. lol at being just "obfuscation" because
| you can spend $5m to decap and fetch the key then put the
| processor back into working order for the attack.
|
| that just requires a vertically integrated device instead
| of a consumer part-swappable PC.
| kukrimate wrote:
| What you are saying is sound, and I agree it could be
| done.
|
| But there are multiple caveats: - How do you hide the
| secret so that only "legitimate" operating systems can
| use it for establishing their sessions and not "Mate's
| bootleg totally not malware live USB"? - And
| unfortunately current CPUs don't implement this. -
| Additionally don't be so smug to think you need to decap
| a CPU to extract on-die secrets. Fault injection attacks
| are very effective and hard to defend against.
|
| I agree the security of this can somewhat be somewhat
| improved, but if you are building a custom CPU anyhow,
| you might as well move the TPM on-die and avoid this
| problem entirely.
| cryptonector wrote:
| Problem is that the BCM and the BIOS/UEFI and every component
| talking to the TPM all need to store one (or more) public
| keys for it (and the corresponding templates and/or save
| files) in order to set up encrypted sessions to the TPM.
| zoeysmithe wrote:
| and by recent, TPM was external last in gen 8 of intels, so
| this attack works on cpus released last in October 2017. That's
| almost 7 years ago. Most organizations have a 3-5 year
| replacement schedule.
| rf15 wrote:
| > briefly grounding the reset pin of a discrete TPM device with a
| pair of tweezers
|
| Ah, the tweezers strike again, just not for Nintendo this time.
| Truly the most universal hardware hacking tool.
| bee_rider wrote:
| I have to believe there are hardware engineers out there who
| know locking people out of their devices is essentially bad,
| and so they leave in those tweezer based attacks on purpose.
|
| Although, designing against physical attacks is very difficult,
| so I guess there's no need to imagine a good-hearted conspiracy
| of conscientious hardware folks.
| LeifCarrotson wrote:
| The fundamental operation in hardware engineering is the
| digital signal, pulling a pin to one or zero - which is all
| the tweezer attack does. It's comparable to writing a byte of
| memory. Imagine how hard software security would be if your
| adversaries could write arbitrary data to your process:
| there's no ASLR or even an MMU to randomize trace layouts on
| physical circuit boards.
| hun3 wrote:
| You could scramble/authenticate the signals though, if you
| don't mind the huuuuuuuge performance penalty.
| kukrimate wrote:
| Well yes, but there is a difference between a signal being
| accessible on a PCB trace I can see with my eyes, vs it
| being accessible only on the inside of a 7nm silicon die.
|
| There is a reason why a lot of system integrate the
| security processor on the same piece of silicon whose state
| the security processor is meant to protect.
|
| The reason discrete TPMs exist is supposed compliance with
| crypto standards, and physical protection against key
| extraction, but they sort of miss the forest before the
| trees. What matters to users is the protection of _their
| data_ , not the TPM's secrets, and discrete TPMs arent very
| good at the former.
| II2II wrote:
| The problem with that approach is that it also weakens
| security for people who genuinely need it.
| bee_rider wrote:
| There's some value to being able to lock a device against
| somebody who physically has control of it. Like it is nice
| that stolen iPhones have reduced value.
|
| But there's a pretty big social harm to locking people out
| of their devices, like the generation of tech-illiterate
| kids growing up that haven't been allowed to break their
| computers well enough to learn anything about them.
| trebligdivad wrote:
| But this page is a no-tweezer hack; by reprogramming the GPIO
| pin that drives the reset; this is software only so more of a
| problem.
| RedShift1 wrote:
| TPM seems beyond useless to me. I wanted to protect a certificate
| and private key for a Java application, so that you can't just
| copy the pkcs12 file and use it elsewhere, but there is no decent
| API in Java to use a TPM 2 chip. So the road ends there... The
| only protection now is a hardcoded passphrase in the application
| but you don't have to be a genius to figure that out...
| sim7c00 wrote:
| its meant for secureboot, but i suppose the rest of the
| platform, built usually by other ppl than ones who designed the
| TPM, needs to also implement it correctly. an d as this article
| shows, this is not an easy feat. (this attack seems silly but
| it's really clever tbh. good inspired idea likely based in lots
| of domain expertise). - if you can protect the boot-chain with
| secureboot, what you can do for your private key, what for
| example AV vendors do, is have a (efi?)driver that contains the
| certificate, which is a boot-driver protected by secure-boot. -
| for windows this might require Microsoft cooperation to assign
| you a driver level so other stuff can't disable it (otherwise
| it's still tricky and possible to get around your protections
| likely). (windows -> process protection light / telam drivers).
| Optionally you could also have the certificate provided by an
| EFI applcation somehow that's signed / secured by secureboot.
| (could drop it on disk somewhere, efi partition is easily
| accessible...).
|
| If the chain is protected by the tpm, this method if
| implemented correctly through the whole chain should protect
| your cert and pkey.
|
| that being said _should_ is the keyword,. i dont think any
| platform really managed to escape all attacks, though a lot in
| this area do need hw access (the tweezers previously
| implemented by the author :)).
| RedShift1 wrote:
| Heh I always thought that TPM was there to secure anything.
| If it's only meant for secure boot then I understand the poor
| tooling and absence of APIs to use the thing properly inside
| applications.
| Foxboron wrote:
| 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.
| jnwatson wrote:
| It is absolutely used and designed for secure boot. There
| are now simpler mechanisms to accomplish the same thing,
| but if you want remote attestation, you need a TPM.
| patmorgan23 wrote:
| TPM isn't just for secure boot. Windows utilizes it for
| Bitlocker full disk encryption.
|
| It's just not widely used for other applications.
| cryptonector wrote:
| That's still essentially part of the boot process. You
| can't use dTPMs as HSMs for TLS or whatever because dTPMs
| are way too slow.
| klysm wrote:
| What about systemd credentials?
| RedShift1 wrote:
| App runs on Windows
| CodeArtisan wrote:
| Each TPM having an unique certificate, you may use that to
| trace a specific machine to a specific user. Game developers
| could use that to ban (toxic) players from an online service,
| for example.
| CivBase wrote:
| Couldn't they just reset their TPM to change their
| "identity"? Or use a different computer or VM?
|
| Also, I'd be pretty frustrated if I was sharing a PC with
| someone and they got me banned from a game.
| looperhacks wrote:
| I believe you can't "reset" a TPM, but you can buy a new
| one (if your CPU does not support fTPM). Or buy a new PC I
| guess. Both solutions are costly though, depending on how
| often the cheat is found.
| voxic11 wrote:
| If you are sharing a computer with a hacker then your
| account would be banned anyways. All the tpm does is ensure
| you can't just make another account and use it from that
| computer.
| marshray wrote:
| Apparently on some motherboards the TPM is on a pluggable
| module available for ~$15 on Amazon.
| immibis wrote:
| It's used to establish a root of trust. If your operating
| system is modified, it fails to validate and the TPM doesn't
| release the secrets. If your BIOS is modified, it fails to
| validate and the TPM doesn't release the secrets. If your CPU
| is modified, it can tell the TPM what it wants to hear and get
| the secrets even if the BIOS or OS is modified.
|
| For some people, this is a useful increase in security. Those
| people set up their own TPM according to their own rules. For
| the rest of us, who had one forced on us by Microsoft, it's
| just more anti-right-to-repair.
| jprete wrote:
| Totally off-topic: You could always write a JNI shim to a
| C/C++-compatible API, if you know what OS it's running on.
|
| I know it's awful, but probably not as awful as a hardcoded
| passphrase.
| cryptonector wrote:
| There are TPM 2.0 APIs for Java.
| RedShift1 wrote:
| No, they are all for TPM 1.2
| cryptonector wrote:
| Discrete (i.e., _chip_ ) TPMs (dTPMs) are _slow_. They are way
| too slow to use as HSMs.
|
| Firmware TPMs (fTPMs) are faster, but I doubt they're really
| fast enough to use as an HSM.
|
| There are TPM APIs for Java, so you _can_ do this, but it 's
| not surprising that the Java keystore providers lack builtin
| support because of the performance issues.
|
| Ideally fTPMs should come with EKcerts and platform
| certificates and they would be very fast and as secure as (more
| so than) dTPMs. Then using fTPMs as HSMs might take off.
| lowestdecks wrote:
| Real world example of a use of TPMs (outside of bootloaders)
| that has a positive effect on users:
| https://blog.chromium.org/2024/04/fighting-cookie-theft-usin...
| nottorp wrote:
| Can you use this to install linux on motherboards locked to
| windows boot loaders in firmware? :)
| kukrimate wrote:
| No.
|
| But on essentially all existing UEFI systems you can trivially
| overwrite the "db" keystore in flash and install anything you
| please.
|
| Also most (all?) UEFI systems are not locked to Windows and
| allow customizing the keystore via the firmware console
| interface anyhow.
| Foxboron wrote:
| > 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.
| userbinator wrote:
| Good. The only widespread uses of TPM are as user-hostile as any
| other DRM scheme.
|
| Stallman was right: https://www.gnu.org/philosophy/can-you-
| trust.en.html
|
| (Last few paragraphs.)
|
| See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-
| is-co...
| mindslight wrote:
| Not the only _uses_ , but certainly all of the widespread
| implementations of trusted hardware just haven't been able to
| avoid that temptation of privileging the manufacturer while
| securing against the user themselves. Every little hole is
| another setback that keeps the designers/implementers working
| on this layer instead of starting to tighten the noose on the
| next one.
| anthk wrote:
| There's full fdisk encryption under OpenBSD and forcing the user
| to boot from USB.
| StillBored wrote:
| Ok, I understand how a TPM gets attached to a muxable GPIO block.
|
| But, did no one stop and question whether a TPM should have been
| on a dedicated block that couldn't be reprogrammed rather than
| assuming there wouldn't be bugs or whatever in the GPIO pin
| muxing? Never mind all the additional complexity of assuming page
| permissions access/etc to shared purpose MMIO regions?
|
| So, IMHO this starts as a hardware bug.
| marshray wrote:
| The CPUs and OSs (other than Windows 11) support operation
| without any TPM.
|
| So either the pin is configurable, or you've wasted a pin that
| could otherwise be used for decorating the motherboard with RGB
| LEDs.
|
| Also, the pin layout has to be standardized by the socket
| specification (eg "LGA 2011"), which may have to retain
| compatibility for a decade or more. This strongly favors
| defining reconfigurable over fixed-function pins.
| jwells89 wrote:
| A bit tangential, but it's a bit shocking how consistently bad
| firmware for x86 motherboards and laptops is, as is most visible
| in the UEFI configuration screen. It makes me wonder if a new
| entrant in the motherboard/laptop space couldn't make a name for
| themselves by simply caring about the quality of their firmware
| and trying to make it good.
| justaj wrote:
| Such an entrant exists. It's called Libreboot.
___________________________________________________________________
(page generated 2024-06-06 23:01 UTC)