Hacker News new | ask | show | jobs
by junon 309 days ago
> Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past?

As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty.

I would love to be wrong.

2 comments

Intel audits configuration on system launch and verifies it runs something they know safe. That involves CPU, CPU microcode, BIOS version and a few other things (SGX may not work if you don't have the right RAM for example).

The final signature comes in the form of a x509 cerificate signed with ECDSA.

What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.

Depends on your threat model. You cannot, under any circumstance, prove (mathematically) that a peer is the only controller of a private key.

Again, I would love to know if I'm wrong.

The fact that no publicly disclosed threat actor has been identified says nothing.

Proving a negative that information has not been shared has been a challenge from the beginning of information.

Are you suggesting a solution for this situation?

In this case it's rather like trusting that a government issued private key has not been stored by the government for further use.
> Any network protocol can be spoofed, with varying degrees of difficulty.

Because of the cryptographic verifications, the communication cannot be spoofed.

Pray tell how a black box peer can validate its not had its private keys cloned?
Because the code doesn't have any code to clone private keys.

The trust chain ends with you trusting Intel to only make CPUs that do what they say they do, so that if the code doesn't say to clone a private key, it won't.

(You also have to trust the owners to not correlate your traffic from outside the enclave, which is the same as every VPN, so this adds nothing)

The first part is definitely true.

The second part in terms of correlations is untrue since we include a number of techniques to frustrate timing attacks among other things.

There's also the factor of why should we trust the person who destroyed Freenode while telling everyone he was actually saving it from the evil people who were trying to steal it from him? That's a liability. He might sell all our traffic logs to some evil entity while claiming he's just protecting us.
It would probably make sense to look into details before parroting false narratives.

Additionally, if you’re still talking about trust it means you don’t understand the technical implications of this.