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

71–80 of 113 posts

Re: Remote Attestation

#71

Post by realusername »

Gigachad wrote: post #20
Uptrenda wrote: post #16

It's a nice idea, but I wouldn't design any system on the assumption that a TPM needs to stay secure for the system to be safe. There's been so many exploits. We can consider the iphone as an R & D platform for doing blackbox computations. In that nothing is allowed to run that Apple doesn't want. Protecting that is apples bread and butter and they care about it enough to value critical exploits in the millions. Yet…

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…

> There has never been a widespread malware attack on the iphone

I had a calendar malware that I had to remove from my sister's iphone just last year.

There's been also (and still exists) fake apps pushed with appstore ads, not sure if you count this or not.

Re: Remote Attestation

#72

Post by whiatp »

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…

Yeah, if the CPU has a an embedded TPM that would be way better than the external ones. I'll admit that my experience comes from somewhat dated hardware.

The point I was making was about registering new EKs/certs into your set of trusted servers. While you can tell the TPMs apart from each other, knowing the EK/cert belongs to your hardware's TPM vs someone else's is the tricky part.

Re: Remote Attestation

#73

Post by bdangubic »

realusername wrote: post #71
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…

> There has never been a widespread malware attack on the iphone I had a calendar malware that I had to remove from my sister's iphone just last year. There's been also (and still exists) fake apps pushed with appstore ads, not sure if you count this or not.

your sister’s calendar does not really qualify as “widespread malware attack” :)

and neither do thousands of “fake apps” that no one installs

Re: Remote Attestation

#74

Post by realusername »

bdangubic wrote: post #73
realusername wrote: post #71

Earlier quoted context omitted.

> There has never been a widespread malware attack on the iphone I had a calendar malware that I had to remove from my sister's iphone just last year. There's been also (and still exists) fake apps pushed with appstore ads, not sure if you count this or not.

your sister’s calendar does not really qualify as “widespread malware attack” :) and neither do thousands of “fake apps” that no one installs

I don't think that you can find a definition of malware that those won't fit in.

The calendar malware pushes garbage ad notification in loops on the iphone and is triggered without user intent.

And then it's not just "fake apps" but apps designed to steal your credentials appearing at the top of the appstore.

Re: Remote Attestation

#75

Post by vaylian »

jeroenhd wrote: post #68
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, Googl…

> The APIs have been there for ages

True. But my impression is that the whole TPM ecosystem is poorly documented. Maybe I just don't know where to look. But to me TPMs are still mostly a black boxes that prevent me from installing Linux unless I disable secure boot.

To benefit the most from security, you need to understand what the security mechanisms can and cannot do. And I feel that there is no good explanation out there to get starting with playing around with TPMs. If you already work at a big tech company, then you can probably find a mentor who might even have contributed to the TPM standards. But if you don't, then it seems to be really hard to properly learn how TPMs can be used.

Re: Remote Attestation

#76

Post by Aachen »

solenoid0937 wrote: post #34
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.

Please stop bashing on things you don't understand. This is standard practice for workload authentication in corporate fleets. The article makes the target audience clear: > If your infra consistently enforces mTLS

Why make the assumption they don't understand? I understand how this tech works and I'm very wary about it being rolled out widely, even if I see the legitimate uses, so I can understand their point. It might not have to do with 'bashing things one doesn't understand'

For example mutual TLS enforcement is something that can happen on my phone to prevent me reading what an app is uploading. It prevents me from auditing things, at least as easily as it used to be: add your key to the trusted keys list and see if e.g. a claim about on-device processing is true. It isn't only the corporate world that uses it, or at least, not only on their own devices

Re: Remote Attestation

#77

Post by mschuster91 »

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.

> This is just standard infrastructure security practice at any tech company of meaningful size.

The problem is, the same features we want for infrastructure are automatically being abused to restrain our consumer hardware - and to make it worse, for barely a good reason at all.

Re: Remote Attestation

#78

Post by jeroenhd »

vaylian wrote: post #75
jeroenhd wrote: post #68

Earlier quoted context omitted.

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, Googl…

> The APIs have been there for ages True. But my impression is that the whole TPM ecosystem is poorly documented. Maybe I just don't know where to look. But to me TPMs are still mostly a black boxes that prevent me from installing Linux unless I disable secure boot. To benefit the most from security, you need to understand what the security mechanisms can and cannot do. And I feel that there is no good explanation ou…

> But to me TPMs are still mostly a black boxes that prevent me from installing Linux unless I disable secure boot.

Then I think you misunderstand what TPMs are. Secure boot works without TPMs and TPMs are usuable without secure boot. I have secure boot disabled on my laptop (until I have time to figure out how to generate my own keys reliably) but store my SSH keys on the TPM. You can also set up secure boot without ever initializing the TPM.

As for the documentation, the entire interface and the operations it can perform are well-documented: https://trustedcomputinggroup.org/resource/tpm-library-speci... Every command, response, and the logic behind the operation are written out. There's no need to write your own TPM driver, of course; software like https://tpm2-software.github.io/ makes the entire process quite easy. The project even has bash scripts explaining how to do things like storing secrets in the TPM using.

The TPM itself can do multiple things (storing secrets with or without a password ("PIN"), applying brute-force protection, using "measurements" submitted by the OS and firmware as a requirement for unlocking secrets, doing cryptographic operations, random number generation) but most often it's just used to store a key and then keep it locked away from the rest of the computer until you've proven that you're the user/OS that has put the key in there. Combine that with something like disk encryption, or managing a certificate, and you've got a way to protect against even some kernel-level malware.

Re: Remote Attestation

#79

Post by psd1 »

sfdlkj3jk342a wrote: post #51
solenoid0937 wrote: post #45

Earlier quoted context omitted.

I hope you put a lot more research into those debates than you did with this topic! I just don't understand why you'd have this overconfident hot take about a topic you clearly aren't familiar with. Like, try to understand the article subject and audience first?

I didn't claim to be an expert in this particular area of security, but I have enough common sense to know that remote attestation is not "critical" for a corporate network. Perhaps it has valuable use cases for very large companies that want complete control over their employee devices, but your claim is far too broad to hold.

I have enough common sense to know that the earth is flat and the sun revolves around it. That's why the sun comes up and why we don't fall off.

I don't claim to be an expert, i just know that the experts are wrong.

Re: Remote Attestation

#80

Post by [deleted] »

whiatp wrote: post #72
crote wrote: post #67

Earlier quoted context omitted.

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…

Yeah, if the CPU has a an embedded TPM that would be way better than the external ones. I'll admit that my experience comes from somewhat dated hardware. The point I was making was about registering new EKs/certs into your set of trusted servers. While you can tell the TPMs apart from each other, knowing the EK/cert belongs to your hardware's TPM vs someone else's is the tricky part.

[deleted]
Post reply on HN