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

61–70 of 113 posts

Re: Remote Attestation

#61

Post by whiatp »

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 "corrected" so the TPM thinks the boot artifacts were in the intended state. At least the ones I've worked with were SPI, but I've seen I2C ones as well. Either way, these are low speed, easy to mess with buses.

Also you want to pay real close attention to how you onboard new devices. The article states

> The EK comes with a x509 cert signed by the manufacture’s PKI. So the EK proves the TPM is legit.

This lets you know the TPM you are performing remote attestation of is made by a particular manufacturer, but an attacker can go buy a TPM chip from the right manufacturer off digikey, and feed it the intended hashes in pcr extend commands. For the attacks the TPM is supposed to prevent, you have to assume they could re-direct the tpm requests your remote validation service is trying to run to their own device by compromising the boot artifacts. You still have to figure out how to make sure your workflows are onboarding the TPM from _your_ hardware, not just a TPM from the same manufacturer.

Re: Remote Attestation

#62

Post by strstr »

AnthonyMouse wrote: post #38
Gigachad wrote: post #20

Earlier quoted context omitted.

The iPhone is actually working really well. There has never been a widespread malware attack on the iphone. Only highly targeted attacks on individuals. And Apple even has an answer for this as well with Lockdown mode which renders all of those previous exploits impossible. There's also Memory Integrity Enforcement on the iPhone 17 chips which makes all memory exploits detectable by the OS so it can trigger a reboot…

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?

Re: Remote Attestation

#63

Post by Gigachad »

AnthonyMouse wrote: post #38
Gigachad wrote: post #20

Earlier quoted context omitted.

The iPhone is actually working really well. There has never been a widespread malware attack on the iphone. Only highly targeted attacks on individuals. And Apple even has an answer for this as well with Lockdown mode which renders all of those previous exploits impossible. There's also Memory Integrity Enforcement on the iPhone 17 chips which makes all memory exploits detectable by the OS so it can trigger a reboot…

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.

Re: Remote Attestation

#64

Post by Cider9986 »

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 through this, and that number will only grow as GrapheneOS gains users.

https://grapheneos.org/articles/attestation-compatibility-gu...

Re: Remote Attestation

#65

Post by simonjgreen »

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…

I recall an event some years ago around Supermicro that was along these lines. Chips added during manufacturing by nation state that interfered with the operation of the BMC and TPM. Wasn't it the catalyst that pushed hardware supply chain concerns in to mainstream media?

Re: Remote Attestation

#66

Post by darkwater »

sfdlkj3jk342a wrote: post #36
solenoid0937 wrote: post #31

Earlier quoted context omitted.

You don't understand the use case or audience of this article: > If your infra consistently enforces mTLS This is for mutual authentication in corporate infrastructure. Attestation is a critical security property for these environments.

> Attestation is a critical security property for these environments. No it's not. Every corporate network to which I've connected worked just fine without it.

My spouse's local Linux account on my laptop works fine with their password set as their username as well. Is it technically secure, though?

Re: Remote Attestation

#67

Post by crote »

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 CA can sign multiple TLS certs with one root key.

Re: Remote Attestation

#68

Post by jeroenhd »

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..

The user is choosing to use apps that do remote attestation against the user's will. You can live a perfectly normal life without apps. It's quite annoying that I can't watch full-quality Netflix or use Google Pay on my rooted smartphone, but I'll survive.

TPM's, just like Secure Boot for that matter, can be an amazing security boon if used right. The APIs have been there for ages but only companies like Apple, Google, and Microsoft have started using them because every time someone from the open source community suggests using these technologies you get flooded with people raging on forums about how big tech is coming to subdue us and eat our babies.

You can use this technology to verify that nobody has inserted a Microsoft bootloader into your boot process, or to ensure that only your GrapheneOS smartphone is able to connect to your WiFi. You can make it so border control guards/airport security cannot dump your hard drive and connect to your VPN. The same technology that allows Microsoft to lock down employee laptops can be used to lock out the people that want to threaten your freedom.

> Unless there are exploits..

Everything with a computer in it is unusable if you accept "there may be exploits" as a counterargument. You cannot trust Signal's encryption because there may be exploits. You cannot trust your doctor's heart rate monitor because there may be exploits. You cannot trust your car's speedometer because there may be exploits. You cannot trust your browser to read HN, because there may be exploits.

Re: Remote Attestation

#69

Post by vaylian »

stingraycharles wrote: post #27
userbinator wrote: post #25

This is the dream of corporate authoritarians everywhere. The dystopian nightmare we all warned about because we saw it coming. "Security" is the "think of the children" fearmongering of the current environment. As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither." Remote Attestation: Just Say No.

Could you elaborate on why this is so evil? Ensuring our remote employees’ machines are secure is a serious problem for us, and it’s absolutely impossible to require employees to be diligent. We require attestation upon connection to our corporate VPN that checks for basic things such as latest security patches, certain tools installed, etc.

> Could you elaborate on why this is so evil?

I think you have a fair use-case when you think about corporate machines, that are not personal devices. However, the more this type of remote attestation is used, the more likely it is that politicians will also require it on private machines, because "we have the technology". And then you won't be able to run any software that you want, because it could potentially be used for serious crimes like pirating music.

Re: Remote Attestation

#70

Post by realusername »

stingraycharles wrote: post #27
userbinator wrote: post #25

This is the dream of corporate authoritarians everywhere. The dystopian nightmare we all warned about because we saw it coming. "Security" is the "think of the children" fearmongering of the current environment. As one of our Founding Fathers put it: "Those who give up freedom for security deserve neither." Remote Attestation: Just Say No.

Could you elaborate on why this is so evil? Ensuring our remote employees’ machines are secure is a serious problem for us, and it’s absolutely impossible to require employees to be diligent. We require attestation upon connection to our corporate VPN that checks for basic things such as latest security patches, certain tools installed, etc.

It's somewhat more acceptable for entreprise use cases but remember that attestation doesn't tell you that the machine is secure, just that the software wasn't modified.
Post reply on HN