We use SPIFFE/SPIRE at work. It works well for our use case, remote embedded workflows that need to phone home. It's very exacting: everything must be exactly right for the attestation to succeed. So it takes extra effort when you commit to that path.
>But what about attacks after boot? That’s your EDR’s problem. Trusted boot provides the bedrock to build a bunch of other primitives on top of. Including cryptographic proof your EDR is installed and running (at boot), immutable filesystems (verified at boot), signed upgrades, confidential computing, etc. Without it you can’t trust your hosts themselves and can’t make further security guarantees. Houses built on sand and all that.
Good take - remote attestation doesn't solve all problems on its own but it is a very powerful tool in the platform security toolbox (and very cool "to boot" :P)
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:
I mean, all tech can be used in different ways. My experience has been much more on the preventing root kits side, rather then vendor lock in.
Yes, there can be exploits, but hardware exploits over a restricted interface (TPM2) are significantly rarer then normal software vulns. Everything is about risk mitigation, there is no perfect security.
Make no mistake. Shoving user-hostile malware down people's throats is the primary use case for this in the consumer space. Bootloader malware is very esoteric right now. Enterprise might have valid use cases beyond screwing people but none of them make sense for a consumer device.
We use SPIFFE/SPIRE at work. It works well for our use case, remote embedded workflows that need to phone home. It's very exacting: everything must be exactly right for the attestation to succeed. So it takes extra effort when you commit to that path.
>But what about attacks after boot? That’s your EDR’s problem. Trusted boot provides the bedrock to build a bunch of other primitives on top of. Including cryptographic proof your EDR is installed and running (at boot), immutable filesystems (verified at boot), signed upgrades, confidential computing, etc. Without it you can’t trust your hosts themselves and can’t make further security guarantees. Houses built on sand and all that.
Good take - remote attestation doesn't solve all problems on its own but it is a very powerful tool in the platform security toolbox (and very cool "to boot" :P)
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..
I mean, all tech can be used in different ways. My experience has been much more on the preventing root kits side, rather then vendor lock in.
Yes, there can be exploits, but hardware exploits over a restricted interface (TPM2) are significantly rarer then normal software vulns. Everything is about risk mitigation, there is no perfect security.
Make no mistake. Shoving user-hostile malware down people's throats is the primary use case for this in the consumer space. Bootloader malware is very esoteric right now. Enterprise might have valid use cases beyond screwing people but none of them make sense for a consumer device.