Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote Attestation

liamcvw.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Remote Attestation

#101

Post by UltraSane »

crote wrote: post #67
whiatp wrote: post #61

Something worth calling out is that, as far as I've seen, most server TPM implementations are not great against physical access attacks. If servers might be physically compromised (eg. you are leaving a server unsupervised in a colo) shenanigans are still possible. The TPMs are on separate chips from the main processor. If something were to man-in-the-middle the communications with the TPM, the hash digests can be "c…

Don't most (all?) modern CPUs have an embedded TPM? Plug-in TPMs were indeed a thing early on, but I thought that was a thing of the past by now. You can't exactly get in between the CPU and another part of the same CPU. Also, isn't the EK (and therefore its cert) unique per-device, allowing you to tell it apart? The fact that the manufacturer used the same upstream key to sign both certs doesn't matter, just like a…

Newer AMD CPUs have TPMs in them.

Re: Remote Attestation

#102

Post by madduci »

lachiflippi wrote: post #81
madduci wrote: post #59

The German Healthcare System is moving to the TelematikInfrastruktur 2.0, which has foundations in Zero Trust security, which includes also remote attestation and proof with TPM. I had made a dummy client as example and I must say that on development perspectives, it is wild. There are some Go libraries, which support only RSA instead of EC for TPM Keys, on the C++ side you get most of results in Windows through the…

> you get most of results in Windows through the CryptoProvider Isn't that what you want on that platform? ADCS even supports issuing remote-attested TPM certs via EK, no need to reinvent the wheel. > on Linux and Mac exists own OS solutions/access. I'm not sure what the story is on MacOS, but on Linux the options are definitely lacking. From what I can tell, tpm2-openssl is the most mature solution, but that doesn't…

Exactly, how Windows exposes the TPM functionalities is a far better experience than in other platforms

Re: Remote Attestation

#103

Post by lurkerforawhile »

egorfine wrote: post #85

This is an incredibly nice technology that absolutely will be used to prevent you from using your computer as you wish.

this stuff should only be used for military and other high risk environments. it's an anti-consumer, anti-reuse, e-waste generating nightmare.

Re: Remote Attestation

#104

Post by Rohansi »

AnthonyMouse wrote: post #55
Rohansi wrote: post #15

Earlier quoted context omitted.

> none of them make sense for a consumer device. One of the valid use cases on consumer devices is video game anti-cheat software. Theoretically remote attestation can enable them to be less invasive.

That's the use case it can't really work for. With enterprise devices you can enroll a specific device and only allow its key. Someone who finds a vulnerability in a different device model, or even the same device model when they don't have one of your actual devices, can't use it because it's not enrolled. (That doesn't actually require remote attestation, the same works without any kind of TPM, but it mitigates a g…

Riot Games relaxed the requirements of their Vanguard anticheat by requiring TPM attestation among other things [1].

> It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device

Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself. You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).

[1] https://xcancel.com/riotgames/status/2069829543276216564

Re: Remote Attestation

#105

Post by Cider9986 »

matejdro wrote: post #91
Cider9986 wrote: post #64

GrapheneOS has an implementation of this with their Auditor app. You can use their service or you can use another Android. No freedom lost, just security gained. https://attestation.app/about There's also Android's hardware attestation API which apps can use to verify integrity in a more secure and privacy-respecting way than Google Play Integrity. An increasing number of apps are officially supporting GrapheneOS thr…

> No freedom lost, just security gained As far as I can tell, it flags unlocked bootloaders? So this is already huge freedom lost.

Auditor doesn't cause any issues with your system if there's a problem besides letting you know. It's just for informative purposes so you can determine your system is secure.

Re: Remote Attestation

#106

Post by AnthonyMouse »

Sayrus wrote: post #60
AnthonyMouse wrote: post #41

Earlier quoted context omitted.

> The most likely attacks on Signal involve trusted insiders or configuration errors, and SGX mostly prevents these, since to exploit it, you'd need to bribe insiders in both Signal and Intel, or find configuration errors in both of their software stacks. Since there have been multiple SGX key extraction vulnerabilities already, all you would have to do is compromise Signal and then use the key extracted from any of…

Since there have been multiple 0-day in kernels, we should drop all security boundaries in them because you'd only need execution on the machine and a known vulnerability. Since there have been with bypass on service X, we should remove auth because all you need is the vulnerability. Address space layout randomization wouldn't exist with this mindset, and yet it does and helps for many exploits. SGX is not fully secu…

When there is a 0-day in the kernel, you patch it. When there is a vulnerability in SGX, the attacker extracts the key from their own hardware from as many devices as they want and can permanently make whatever attestations they want with those keys.

Re: Remote Attestation

#107

Post by AnthonyMouse »

Gigachad wrote: post #63
AnthonyMouse wrote: post #38

Earlier quoted context omitted.

Now explain how any of that requires remote attestation.

The parent comment isn’t about remote attestation. It was a claim that since the iPhone isn’t bulletproof then all security must be pointless. When the reality is the iPhone is actually quite a good example that great security is possible with enough investment.

> It was a claim that since the iPhone isn’t bulletproof then all security must be pointless.

Nobody was ever claiming that. The claim is that because it isn't bulletproof, remote attestation is pointless, since it has a different failure mode where once keys can be extracted the attacker can't be deprived of them, so there is no way to return the installed base of existing devices to a state of being able to trust their attestations.

Re: Remote Attestation

#108

Post by AnthonyMouse »

strstr wrote: post #62
AnthonyMouse wrote: post #38

Earlier quoted context omitted.

Now explain how any of that requires remote attestation.

(I’ll bite and try to steelman) How does a typical user verify that they are running the intended secure software?

The best way to do it would make all persistent storage in the device modular so that the storage device can be attached to a device that isn't booting from it which can thereby verify its contents.

Notice also that remote attestation doesn't enable that. The device can never do that itself since if it was compromised it would just display "attestation passed" on the screen without actually doing it.

Re: Remote Attestation

#109

Post by UltraSane »

solenoid0937 wrote: post #33
zb3 wrote: post #2

It would be a nice addition if big tech didn't abuse this to shove user-hostile software into devices which the user has paid for (like smartphones).. thanks to this attitude, whenever I see "remote attestation" I associate this with "hostile".. > Using a TPM, we can remotely, cryptographically prove a couple of things: Unless there are exploits..

> whenever I see "remote attestation" I associate this with "hostile" HN is bizarre. This is just standard infrastructure security practice at any tech company of meaningful size. You are misunderstanding the target use case and audience of this article.

Exactly. Remote attestation is nothing more than an elaborate hashing and signing scheme using trusted hardware and is VERY useful.

Re: Remote Attestation

#110

Post by AnthonyMouse »

Rohansi wrote: post #104
AnthonyMouse wrote: post #55

Earlier quoted context omitted.

That's the use case it can't really work for. With enterprise devices you can enroll a specific device and only allow its key. Someone who finds a vulnerability in a different device model, or even the same device model when they don't have one of your actual devices, can't use it because it's not enrolled. (That doesn't actually require remote attestation, the same works without any kind of TPM, but it mitigates a g…

Riot Games relaxed the requirements of their Vanguard anticheat by requiring TPM attestation among other things [1]. > It's also the solution to yesterday's problem because cheaters are now using cheat hardware that acts as a user input device Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself. You can't see people through walls with cheat hardwa…

> Riot Games relaxed the requirements of their Vanguard anticheat by requiring TPM attestation among other things

Only on Windows, and then we're back to the thing being a net negative for the consumer again. Also not proven that it's actually effective, in which case we get the cost without the benefit.

> Cheats like these are not as devastating to the game as the ones that read or manipulate memory in the game process itself.

It allows aimbots and the like which are the most common form of cheating and more than enough to destroy the game for other players.

> You can't see people through walls with cheat hardware acting as a user input device (IOMMU should prevent DMA cheats but those aren't user input devices).

For which they can use different cheat hardware.

It's unclear how IOMMU is supposed to prevent this since many hardware devices actually need to access the relevant memory locations, e.g. your drive is going to write directly to the game's memory because that's how the game's code/data gets into memory to begin with or gets reloaded after being evicted when the user doesn't have unlimited RAM.

On top of that, the cheat hardware could attach to the memory slots. Consumer PCs often don't support memory encryption and it wouldn't work for this anyway, since memory encryption is meant for cold boot attacks or similar rather than live analysis/modification. The performance requirements of RAM require block modes like XTS which allow replay attacks (undo cheats) and data flow analysis. Or worse, they just use a replay attack to get ACE on the device that passes attestation.

Attempting to secure a device in the physical possession of the attacker is very challenging and in general should not be the basis of anything you intend to actually be secure.

Post reply on HN