During remote attestation, the prover (here, Signal's server) create a "quote" that proves it is running a genuine enclave. The quote also includes the MRENCLAVE value.
It sends the quote to the verifier (here, Signal-Andriod), which in turn sends it to Intel Attestation Service (IAS). IAS verifies the quote, then signs the content of the quote, thus signing the MRENCLAVE value. The digital signature is sent back to the verifier.
Assuming that the verifier trusts IAS's public key (e.g., through a certificate), it can verify the digital signature, thus trust the MRENCLAVE value is valid.
The code where the verifier is verifying the IAS signature is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
The code where the MRENCLAVE value is checked is here: https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
Hope this helps!
[0]: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#r...
[1]: For other people interested in this matter: I've followed the path of the MRENCLAVE variable to the very end,
https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
where it gets injected by the build config. The build config, in turn, is available here:
https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
(The MRENCLAVE values can be found around line 120.)
https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
For completeness, let's also have a look at where the CA certificate(s) come(s) from. The PKIX parameters[1] are retrieved from the trustStore aka iasKeyStore which, as we follow the rabbit hole back up, gets instantiated here:
https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
As we can see, the input data comes from
https://github.com/signalapp/Signal-Android/blob/6ddfbcb9451...
`R.raw.ias` in line 20 refers to the file `app/src/main/res/raw/ias.store` in the repository and as we can see from line 25 it's encrypted with the password "whisper" (which seems weird but it looks like this a requirement[2] of the API). I don't have time to look at the file right now but it will probably (hopefully) contain only[3] Intel's CA certificate and not an even broader one. At least this is somewhat suggested by the link I posted earlier:
https://github.com/signalapp/Signal-Android/blob/master/libs...
In any case, it seems clear that the IAS's certificate itself doesn't get pinned. Not that it really matters at this point. Whether the certificate gets pinned or not, an attacker only needs access to the IAS server, anyway, to steal its private key. Then again, trusting a CA (and thus any certificate derived from it) obviously widens the attack vector. OTOH it might be that Intel is running a large array of IAS servers that come and go and there is no guarantee on Intel's part that a pinned certificate will still be valid tomorrow. In this case, the Signal developers obviously can't do anything about that.
[0]: https://twitter.com/matthew_d_green/status/13802817973139742...
[1]: https://docs.oracle.com/javase/8/docs/api/index.html?java/se...
[2]: https://stackoverflow.com/questions/4065379/how-to-create-a-...
[3]: If it contains multiple CA certificates, each one of them will be trusted, compare [1].