Comment by Confiks | Hacker News Reader

Comment by Confiks | Hacker News Reader

Parent Full thread

I don't really understand why this is an improvement on the existing architecture.

In the current contact discovery implementation you need to fully trust the server, namely the open source component that is the contact discovery service.

In this proposed new implementation, you still have to trust the server; you need to trust closed source processor hardware offering the Software Guard Extensions.

Those extensions need necessarily be kept away from user control, because otherwise you could pretend to attest a particular program, while actually running a different program. So this encourages a centralization of trust into a private key managed by processor manufacturers, which with server hardware is primarily Intel.

(note that you fully need to trust the processor hardware in both cases; I'm only arguing that this scheme possibly isn't an improvement)

Could anyone shed some light onto why this is an improvement, assuming you don't trust the CPU manufacturer? This is kind of the premise of the article, which notes that "more fundamentally for us, we simply don’t want people to have to trust us", "that’s not what privacy is about".

I am by no means an SGX expert, but my understanding has been that it allows you to shorten the "trust stack."

What you're referring to as "the server" is really a technology stack that starts with the CPU hardware and extends to the service operator. Without SGX, the trust stack probably looks something like: Intel, the OS, the VM, the cloud provider (Amazon, Google, Microsoft), the server software, the server operator.

Any of those points on the trust stack can be compromised by their principals or by an attacker (for example, Amazon could choose to interfere with Signal, or someone could hack Amazon and do the same). This is true for the OS, the software, the service provider, and everything else in the stack. Users have to trust all of those points, and additionally trust them not to be compromised.

SGX shortens the trust stack all the way down to the CPU. It takes the OS, the VM, the cloud provider, the service operator, and everything else out of the equation. Clients no longer have to trust any of them, either to be honest or to avoid compromise.

If trusting the CPU isn't acceptable to you, then that might be a bigger problem than you realize, since all computing has to. If you'd rather put your trust in AES, the problem is that you still have to trust the CPU to perform AES the way you would like it to.

I understand that you will have to trust the CPU to do any computation. In a sense, it indeed shortens the 'trust stack', and as said in another comment "now, you need only trust that Intel hasn't backdoored their hardware".

Maybe the main point should have been that that this scheme "encourages a centralization of trust into a private key managed by processor manufacturers". You might say that by integrating SGX mechanisms into your security model, you create a set of 'feudal lords' [1] which can wield their power over you.

A manufacturer may legitimately establish an enclave in you most trusted hardware which you may not audit or even measure. And if that security model becomes commonplace, for example when only allowing Widevine DRM inside SGX, you eventually cannot use your self-chosen hardware, but will have to pick a feudal lord.

[1] https://www.schneier.com/blog/archives/2013/06/more_on_feuda...

There is a difference between trusting a local and a remote CPU. Selling compromised CPU's to end users is much riskier than colluding with a megacorp to create "altered" CPU's for their servers.

A problem I see a lot in this community when it comes to security is letting perfect be the enemy of good.

Yes, this is vulnerable to an effort by Intel, but that's still a significant increase in complexity and capital required to pull of an attack. Really, "still vulnerable to malicious insertion by the hardware vendor" is probably one of the most positive things you can say about a security system, as generally, especially when it comes to privacy, there are many attack vectors that are _so much easier_. For instance, OWS itself.

The improvement here is reducing the attack surface. Yes, that doesn't look like an improvement if you choose to look only at the particular part of the attack surface that this change doesn't address. But in real terms it is a substantial improvement.

SGX attestation involves a key burned into e-fuses on processors at manufacture; the process was designed to prevent Intel from being able to derive keys used for individual enclaves. Obviously, Intel could have a malicious manufacturing process --- but then, that's the case for any piece of merchant silicon you'd use to build any computer.

If I'm reading the documentation [1][2] correctly, you're overselling the security. Verifying an SGX attestation requires trusting not only the integrity of the per-processor secret keys, but the honesty of an Intel-provided online verification API.

The API allows you to POST an attestation report to Intel's verification web service, and get back a response saying "OK" or "not OK". You can use TLS to verify that the authentication was done by Intel rather than a MITM, but there seems to be no cryptographic way to prevent Intel from simply lying to you. They don't offer any way for third-parties to verify attestation reports themselves. [3]

Is there something I'm misunderstanding?

[1]: https://software.intel.com/en-us/articles/intel-software-gua...

[2]: https://software.intel.com/sites/default/files/managed/ac/40...

[3]: https://software.intel.com/en-us/forums/intel-software-guard...

Can you describe which API you're even talking about? This one?

    /attestation/sgx/v1/report

If so, perhaps you missed this:

> "The Attestation Service verifies the validity of the platform. It is the responsibility of the Service Provider to validate the ISV enclave identity."

This API gives back considerably more than just an "OK" or "not OK". It gives back an attestation verification report (see section 4.2.1 of https://software.intel.com/sites/default/files/managed/7e/3b...)

But beyond that, as noted in the document, this is Intel certifying that the attestation was created by genuine Intel hardware. It also carries a data-at-rest signature in addition to TLS:

> "The Attestation Verification Report is cryptographically signed by Report Signing Key (owned by the Attestation Service) using the RSA-SHA256 algorithm. The signature is calculated over the entire body of the HTTP response."

What Intel is providing here is not too far off from OCSP: the main things that can go wrong with "isvEnclaveQuoteStatus" beyond messages being malformed or signed by untrusted keys are the keys being revoked.

An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie.

I did see that document, and I don't see how it addresses the underlying trust issue. Again, I don't claim to be super-knowledgeable about this stuff, which is why I asked if I'm missing something.

> If so, perhaps you missed this: "The Attestation Service verifies the validity of the platform. ..."

No, I didn't miss it. The Attestation Service claims to "verify" the validity of the platform, but it provides no proof of that verification. And if the platform is not valid (i.e. not verified to be using an authentic Intel key) then it doesn't matter what other checks you do; the security of the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated.

> It also carries a data-at-rest signature in addition to TLS:

That's a signature generated by the Attestation Service, not by the original processor. It's generated using a "Report Signing Key" which has no cryptographic relationship with the processor's keys, or with the signature of the attestation; it just tells you that Intel claims to have checked that attestation and found it to be valid.

> An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie.

Right, this system seems as weak as OCSP, in the sense that it can be easily compromised by (for instance) a court order to modify the behavior of Intel's verification API. That's much weaker than the original claim, which was that it could be compromised only by tampering with the processors during manufacture. (Not to mention, the TLS certificate infrastructure would be vastly less secure if browsers had to rely entirely on OCSP and couldn't do any certificate validation of their own. OCSP can lie about revocation, but it can't lie about the signature itself.)

I'll add that v1 of the reporting API seems to have been even weaker than OCSP. In that version, the signed response didn't even include any identifying information about the request, so if Intel faked a response, you wouldn't even be able to prove it to a third party! Thankfully, v2 seems to have fixed this obvious oversight.

In the end this system is just a PKI, albeit one based on a "privacy preserving" scheme based on bilinear pairings. It has all of the same failings as any PKI. They aren't going to do any better than OCSP.

> the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated.

I'm not sure what else you're expecting? Even if the signatures were cryptographically verifiable end-to-end (which I believe is still on Intel's roadmap, but in the meantime they have centralized revocation) Intel could still issue an attestation certificate for a malicious enclave which is in fact a white box software emulation of an enclave, and you'd be none the wiser.

There is no magical way for Intel to provide a mathematical statement that a device is a genuine Intel CPU. You are trusting the hardware and the key management to do what Intel says on the box.

Of course the Intel could lie to you, but Intel is already in the TCB. If you don't trust Intel to correctly verify the attestation report, you probably never trusted any kind of SGX security guarantees in the first place, as they also depend on you trusting Intel to do the thing they claim to do.

There's certainly a difference of degree between, on the one hand, distributing to every customer hardware that doesn't do what they say it does, and on the other, providing a limited number of false attestations of a particular emulation of the SGX hardware.

Don't "trust us" is not the same thing as you don't have trust anyone.

Before this, you had to trust Open Whisper Systems was not coerced and that Intel had not been coerced into backdooring their hardware.

Now, you need only trust that Intel hasn't backdoored their hardware.

Its not perfect, but its better. Especially since its entirely plausible, from a legal perspective, that Open Whisper Systems might be compelled to record any contact data they get. It is comparatively less plausible that a court might compel Intel to backdoor their code in order to enable an order against Open Whisper Systems. And that is what would have to happen here.

And you still need to trust the client. There is nothing stoppting them from slipping you a compromized client via Android Play Store update.

The only way around this would be to have many implementations - but AFAIK they don't allow third party clients to connect.

Reply on news.ycombinator.com